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 <[EMAIL PROTECTED]> 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 > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
