Re: Lenny release plans
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
A few more notes:
http://ftp-master.nemesisnetworks.com/debian - our dak server is up
and running (I have to give import-archive a lobotomy, and remove
three packages which had invalid signatures in the archive (reported
to debian ftp-masters). Next step is getting the w-b database off the
ground. Please note that d-i will not work off this server just yet,
we are missing packages to allow debootstrap to work (these will
probably have to be built by hand, and the glibc 2.5 issue will have
to be worked out).
The FTP server is also running, but I don't have the crontab installed
for Incoming to work yet; I want to work out a policy before we start
allowing uploads to nn.
As for the actual policy, maybe something like this would be best,
with five repos on dak's side (this is also important since we might
be hosting other architectures)
lenny - Pure lenny, without any m68k or architecture specific changes
(exception: nn/dports signing keys)
lenny-security - tracks Debian-security specific fixes. We can also
place fixes here should any security issues that are
m68k/kfreebsd/hurd specifc are found.
lenny-proposed-updates - Used for anything that isn't architecture
specific. Any package here will use a revision number like follows
1dports1 (first numeral being Debian version, dports or
nemesisnetworks depending where/how this is all setup, and the last is
the version numeral for any site specific updates). Due to the
difficultly of tracking Debian's t-p-u, we'll simply track items as
they enter testing vs when the enter the t-p-u queue.
lenny-m68k-specific
lenny-kfreebsd-*-specific
lenny-hurd-*-specific
(and their proposed updates)
The name pretty much says it all. Any changes we do to deviate from
lenny goes into the arch-specific folder. We ship a d-i which adds
both entries to the sources.list file, and pin our -specifc arch
higher then the pure lenny. Versioning here follows 1m68k0/
1kfreebsd0, etc.
Finally:
lenny-backports/lenny-volatile
We should talk to the backports/volatile guys to see how they want to
handle m68k backports/volatile; we could simply track their repo and
host it ourselves, or something.
As for mirroring, I think the current idea is aurel32 is going to pull
from ftp-master.nn.com to ftp-master.d-ports.org, which will then get
pushed out along the dports mirrors. I need to talk to him to figure
out how we're going to handle this, this is the first time anyone's
ever done an out-of-Debian release like this.
Need to talk to Stephen in the morning about the buildd side of all of this.
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: http://getfiregpg.org
iEYEARECAAYFAkihYY0ACgkQpblTBJ2i2pvklQCeNbHjatJfEnJeWsQd8o5VRbsq
i1IAn1dKHGS3lpcqaXQPvZvIsZjlndhE
=6roa
-----END PGP SIGNATURE-----
On Mon, Aug 11, 2008 at 9:42 PM, Michael Casadevall
<sonicmctails@gmail.com> wrote:
> -----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: