Re: Lenny release plans
I "repackaged" glibc 2.5 as glibc-m68k_11+m68k1 as per our versioning
policy ;-). It's currently compiling, and once thats done and
uploaded, I'll work on getting debootstrap working against lenny so we
can setup the autobuilders.
Michael
On Tue, Aug 12, 2008 at 4:01 PM, Wouter Verhelst <w@uter.be> wrote:
> On Mon, Aug 11, 2008 at 09:42:01PM -0400, Michael Casadevall wrote:
>> By the unstable snapshot, I meant a snapshot of unstable from the day
>> lenny was frozen. As of now, I have the packages list setup imported,
>> but I'm having trouble with the dak import script. I'm mulling over
>> using mini-dak for the time being instead of its big brother (I'll
>> replace it with dak if/when we decide to run a normal testing).
>> Roughly 600-700ish packages need to be built since we don't have
>> matching lenny revisions, and we need to go through and determine what
>> packages we need to upgrade ourselves (known: gcc and friends, since
>> lenny has 4.3-2, and we're at 4.3-8 which has quite a few good fixes).
>>
>> For versioning, we should probably mark any m68k specific changes like
>> the way Ubuntu does it. Roughly speaking, if we're taking gcc-4.3-8
>> and replacing it with whats in lenny, make it gcc_4.3-8m68k1 or
>> something like that. This also
>
> This also... what? ;-)
>
>> I do know about d-ports (they'll be hosting our w-b database if
>> aurel32 made the changes to allow that), but they run mini-dak, which
>> will making having both an unstable and a stable hosted with them
>> somewhat difficult. If we ever want to have a "normal" testing
>> archive, we also need to switch to dak since it generates a LOT of
>> metadata britney needs to run (that, or someone needs to rip the
>> urgency and bugscanner code out of it, and extend mini-dak).
>>
>> We have some packaging tasks we need to do, anyone want to voluteer on
>> any of these?
>>
>> 1. glibc 2.5 needs to be repackaged as a separate package so we can
>> properly make fixes to it
>>
>> 2. The previously methoned changes to d-i.
>>
>> 3. gcc and friends need to be imported; we need to figure out some
>> sorta policy on how to handle these.
>>
>> 4. sbuild and buildd need to be extended to upload source packages so
>> I don't need to manually import every source package. (Ideally, we'll
>> have a crontab that runs quinn-diff against our lenny-m68k Packages
>> file, and the Sources file from Debian lenny, all the buildds will
>> have two deb-src lines, our mirrors, and the debian mirrors, and
>> simply upload the source package as they build things).
>>
>> sbuild already has an -s switch to include source, but it generates a
>> Debian native package. To fix this, someone needs to simply make sure
>> the original tarball gets copied to /build/buildd next to the source
>> directly. Its a simple change, but I suck with perl, so I'm not the
>> man for this task.
>
> I could look into this, I guess; but I'm not very wide on time these
> days.
>
>> 5. Someone needs to make sure debootstrap works right once the
>> glibc2.5 package is in place, and marked Essential: Yes.
>
> glibc should not be marked essential: yes, otherwise we won't be able to
> upgrade to glibc 2.7 afterwards. Think about it! :-)
>
> --
> <Lo-lan-do> Home is where you have to wash the dishes.
> -- #debian-devel, Freenode, 2004-09-22
>
Reply to: