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). mini-dak is also already available on d-ports. > 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 Those versions may still be available from snapshots or from me. > 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). Yes. > 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 FWIW, ftpmaster wanted us to use the +m68k1 extension for etch-m68k. I think we should continue for this. > 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). I wonder if the latter might not be better. ;) > 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 Seems like we discussed a fairly minor change that would prevent the linking errors as seen in gnome-python for instance. | /tmp/ccplXqGA.s: Assembler messages: | /tmp/ccplXqGA.s:1305: Error: symbol `fstatat64' is already defined | /tmp/ccplXqGA.s:1327: Error: symbol `fstat64' is already defined | /tmp/ccplXqGA.s:1347: Error: symbol `lstat64' is already defined | /tmp/ccplXqGA.s:1367: Error: symbol `stat64' is already defined > 2. The previously methoned changes to d-i. Has to wait until we actually have lenny. I'll take this one. Also, major changes seem to still be ongoing for lenny d-i, so it's not worth spending too much time on atm. > 3. gcc and friends need to be imported; we need to figure out some > sorta policy on how to handle these. I think for gcc-4.3, at least, we should go with the current sid. -8 is way better than -2. binutils, gcj-4.3, gcc-4.2, gcc-4.1 are all the same. (I better see if the latest binutils buildds now.) I don't much care about gcj-4.2 either way, I've got both versions on my mirror. > 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. Then it has to copy the files back so buildd-mail can find them. Then buildd-mail has to know what to do with them (maybe the sid version does). I'd also like to see the buildd configuration extended a bit so we can have different w-b databases on different servers for sid, lenny, and security, for instance. This would be a good way to handle the difference in sbuild calls between sid and lenny-m68k. It'd also be handy if there was an easy way to make sbuild do an nmu with an appended +m68k1 to the version. BTW, the sid versions look quite a bit different than the db.d.o versions we currently run. I guess if no one wants this, we could at least file wishlist bugs. ;) > 5. Someone needs to make sure debootstrap works right once the > glibc2.5 package is in place, and marked Essential: Yes. I'm fine with taking this one too, since it's right up my d-i alley. > That's all I got for now, any suggestions, thoughts, and/or ideas?. If anybody could figure out the udev vs. nfblock problem, it would certainly make d-i work easier. Right now booting any d-i initrd with the sid atari/aranym kernel will fault very quickly. One we get past this, I'm about ready to do daily regression tests for d-i on m68k. We need to decide whether to package the old perl or skip the thread test failure for 5.10. I'm in favoring of skipping the test failure and seeing what kind of trouble we get into. I suspect the same thread packages will continue to fail and everything else will be fine. I hate to make this kind of decision myself though. ;) ruby1.9 also needs fixing. I'd be interested in finding out what changed such that ghc6 and gcl now take forever to link. They use to be builddable on real hardware. OTOH, maybe we don't care. Peace, Stephen -- Stephen R. Marenka If life's not fun, you're not doing it right! <stephen@marenka.net>
Attachment:
signature.asc
Description: Digital signature