* Adeodato Simó [Fri, 16 Jan 2009 11:32:12 +0100]:
> Hello,
And hi yet again...
> package|source | testing | unstable | ok
> ---+---+---+---+-
> libgcc1 | gcc-4.3 | 4.3.2-1.1 | 4
Adeodato Simó writes:
> Hello,
>
> this is a very late follow-up, but apparently just in time, to [1]. I'm
> very sorry about the delay (though I never got the follow-up Otavio
> promised). Here's a draft of what I think is needed, we'd appreciate if
> you (-boot) could go over it, both the gener
* Adeodato Simó [Fri, 16 Jan 2009 14:32:53 +0100]:
> As a third follow-up, here's a list of *all* d-i build-dependencies
Which uncovered a bug in the script; please find the latest version
here:
http://git.debian.org/?p=tools-release/release.git;a=blob;f=scripts/d-i_bdep-sync;hb=HEAD
And apo
* Adeodato Simó [Fri, 16 Jan 2009 11:32:12 +0100]:
> Regarding those packages not in sync, both arcboot and mkvmlinuz are a
> translation-only upload, so I'll unblock them. As for gcc-4.3, I think
> 4.3.2-2 is Lenny material, I'll check with doko.
As a third follow-up, here's a list of *all* d-i
* Adeodato Simó [2009-01-16 12:12]:
> Frans' original message [1] didn't mention anything about that. He did
> mention, though, stuff coming from udebs from testing. Can it be that
> qcontrol and micro-evtd are grabbed from testing when building the
> installer?
Yes, you're right. See my followi
* Mark Hymers [Fri, 16 Jan 2009 11:34:13 +]:
> The other option, which I've been thinking about for a while, would be
> to allow binary packages (deb or udeb) to declare a field such as:
> Source-Depends: foo (= 1.2-1)
> We could then teach dak to hang on to source packages for as long as
>
On Fri, 16, Jan, 2009 at 12:21:14PM +0100, Adeodato Simó spoke thus..
> Btw, I don't know if it'd be a viable approach or not, but I'll mention
> it nevertheless: I wonder if for squeeze we should do the debian-installer
> uploads to t-p-u instead of unstable. We would still have to ensure
> source
* Adeodato Simó [Fri, 16 Jan 2009 11:32:12 +0100]:
> The easy part is the handling of udeb-providing packages: we we'll just
> wait, as usual, for d-i RM ack/nack before unblocking. If an update
> *must* get through, and d-i RM acks it, we'll just copy the previous
> version to a special suite as
* Martin Michlmayr [Fri, 16 Jan 2009 12:07:06 +0100]:
> * Adeodato Simó [2009-01-16 11:32]:
> > Now, for the less easy part: code that gets embedded. Steve Langasek has
> > kindly provided us with an initial draft for the list of packages that
> > should be checked [2]. This is a subset of D-I's
* Martin Michlmayr [2009-01-16 12:07]:
> > Now, for the less easy part: code that gets embedded. Steve Langasek has
> > kindly provided us with an initial draft for the list of packages that
> > should be checked [2]. This is a subset of D-I's build-dependencies,
>
> Why are they a subset of d-i'
* Adeodato Simó [2009-01-16 11:32]:
> Now, for the less easy part: code that gets embedded. Steve Langasek has
> kindly provided us with an initial draft for the list of packages that
> should be checked [2]. This is a subset of D-I's build-dependencies,
Why are they a subset of d-i's build-deps?
Hello,
this is a very late follow-up, but apparently just in time, to [1]. I'm
very sorry about the delay (though I never got the follow-up Otavio
promised). Here's a draft of what I think is needed, we'd appreciate if
you (-boot) could go over it, both the general lines and the details,
and tell
12 matches
Mail list logo
