-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 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. 5. Someone needs to make sure debootstrap works right once the glibc2.5 package is in place, and marked Essential: Yes. That's all I got for now, any suggestions, thoughts, and/or ideas?. Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: http://getfiregpg.org iEYEARECAAYFAkig6mgACgkQpblTBJ2i2psNwACeMpsrsqKmcI6PJrf45ZIs6RPu JvsAmgPUftbLMayx7z9qZdLS4pdtp+iw =Rwqq -----END PGP SIGNATURE----- On Mon, Aug 11, 2008 at 9:21 PM, Wouter Verhelst <[EMAIL PROTECTED]> wrote: > On Mon, Aug 11, 2008 at 10:50:09AM +0200, Michael Schmitz wrote: >> Hi, >> >>> On Wed, Aug 06, 2008 at 05:17:14PM -0400, Michael Casadevall wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> I figure since lenny is now frozen, its time to talk about our plans >>>> for a lenny-m68k release. Talking with Stephen, the current plan of >>>> attack is something as follows: >>>> >>>> 1. Install dak on a machine on nemesisnetworks (sorta done, still >>>> needs some configuration). >>>> 2. Import GPG keys of anyone who should have upload rights. (we can >>>> limit this to 68k buildd admins, or just dump the entire debian >>>> keyring here) >>> >>> I think it's best if we just dump the entire debian keyring, yeah. If >>> push comes to shove, we can always add our own keys. >> >> Yup - after all, anyone can build their own m68k packages on ARAnyM if >> they feel like it. > > Exactly. Or on live hardware, if they have any. > >>>> 3. Import the unstable snapshot from the day of the lenny freeze into dak >>> >>> I'd think a testing snapshot is better (or should at least also be part >>> of it). Unstable on the day testing is frozen is going to be extremely >>> different from testing... >> >> The testing snapshot is what we need, unless you talk about a separate >> unstable-m68k as well (are we being kicked out yet?) > > By the sound of what I hear here at Debconf, we probably will be after > Lenny is released (though we'll still have a chance of getting in again > if we can get our libc fixed and our unstable/testing into shape) > >>>> 4. Create a wanna-build tracking lenny-purposed-updates, and >>>> lenny-security (I have scripts that do this already) >>>> 5. Find voluteers to run autobuilders for both branches (we will >>>> likely also have a temporary tree lenny-transition or something >>>> handling the changes from the unstable snapshot until now). >>> >>> I can probably revive a few machines. >> >> I can add lenny-security and -p-u to hobbes' chroot list (or run ARAnyM >> for that purpose). > > Just for reference the "few machines" I was thinking about were ska (VME > box that I got as a donation a few years back, not sure we still have a > working kernel?) and jazz (Quadra 950 which I recently updated so that > it runs 2.6 now) > >>>> 6. Setup packages.nemesisnetworks.com again >>>> 7. Find people who can mirror off my server >>>> 8. Rebuild d-i with our mirrors list. >> >> Can we leave most of the mirrors in place, and just add dedicated m68k >> mirror / package list for the patched m68k packages? I.e. if we can use >> something from main, don't bother duplicating? > > Probably, but we'll need to rebuild d-i anyway if we want to use a > separate mirror list. > > [...] >>>> 10. Maybe offer the same services to other ports that are not >>>> releasing with lenny since the infrastructure will already be in >>>> place. >> >> Separate admins needed here? > > It's probably good to remember that debian-ports already exists... > > Something entirely different: Debconf is being followed by quite a few > people through the video streams (see http://video.debconf.org:8000/ if > you care to peek), and I was thinking that it could be a good idea to > set up a stream such as that one in Kiel, too. If we can get a camera > with Firewire-connection and a desktop that's powerful enough and has > enough diskspace to store the recording (13G per hour), and the network > connection is good enough (don't expect that to be a problem at a > university) then that would give us two benefits: > - videos for posterity (we'll probably be able to convince holger that > it's a good idea to host them on meetings-archive.debian.net) > - allowing those who can't make it to Kiel to join to some extent > through IRC and the video stream. > > What do other people think? > > -- > <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]
