Re: Lenny release plans
-----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 <w@uter.be> 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
>
Reply to: