On Sat, 2020-01-18 at 08:25 -0500, Sam Hartman wrote:
> I don't care about the mechanism.
> What I care is that we not go through a period where invoking the
> mechanism involves adding a round trip with ftpmaster, with waiting for
> an upload to be accepted, or with the release team, or otherwis
On Sat, Jan 18, 2020 at 08:40:29AM +0800, Paul Wise wrote:
> On Fri, 2020-01-17 at 03:45 -0500, Sam Hartman wrote:
> > Bootstrap uploads of compilers etc are actually more common than I
> > thought before I started following debian-release.
> The important part of my statement is that they are spec
> "Paul" == Paul Wise writes:
>> If we throw away binaries by default, I do believe we need a mechanism
>> for maintainers to signal that this is a bootstrap upload.
Paul> My proposed mechanism is that when the buildds cannot do the job due
to
Paul> need for a bootstrap pro
On Fri, Jan 17, 2020 at 6:18 PM Richard Laager wrote:
> If I'm following correctly: The packager would use rustcc >= y+3 (in
> practice, likely rustcc y+5) to locally build rustcc y+5 and then do a
> binary upload. But if dak (or whatever, I'm not so familiar with the
> server side here) throws aw
On Fri, 2020-01-17 at 03:45 -0500, Sam Hartman wrote:
> Bootstrap uploads of compilers etc are actually more common than I
> thought before I started following debian-release.
The important part of my statement is that they are special, rather
than that they are rare.
> They are common enough th
On 1/17/20 6:55 AM, Sam Hartman wrote:
>> "Johannes" == Johannes Schauer writes:
>
> Johannes> or have a mechanism that allows maintainers to tell buildds
> "please build this
> Johannes> source package with build profiles X and Y enabled". That would
> then build the
> Johannes
> "Johannes" == Johannes Schauer writes:
Johannes> or have a mechanism that allows maintainers to tell buildds
"please build this
Johannes> source package with build profiles X and Y enabled". That would
then build the
Johannes> binary packages necessary to do a full build in a
Quoting Sam Hartman (2020-01-17 09:45:43)
> > "Paul" == Paul Wise writes:
>
> Paul> On Mon, Jan 13, 2020 at 4:11 PM Wouter Verhelst wrote:
> >> You'll make it unnecessarily harder to bootstrap environments that need
> >> themselves to build if you do that.
>
> Paul> The idea
> "Paul" == Paul Wise writes:
Paul> On Mon, Jan 13, 2020 at 4:11 PM Wouter Verhelst wrote:
>> You'll make it unnecessarily harder to bootstrap environments that need
>> themselves to build if you do that.
Paul> The idea here is that bootstrap builds are special and so they sh
On Mon, Jan 13, 2020 at 4:11 PM Wouter Verhelst wrote:
> You'll make it unnecessarily harder to bootstrap environments that need
> themselves to build if you do that.
The idea here is that bootstrap builds are special and so they should
be very explicit rather than happen as a side effect of regu
On Mon, Dec 30, 2019 at 02:47:45AM +, Paul Wise wrote:
> On Sun, Dec 29, 2019 at 11:32 AM Paul Gevers wrote:
>
> > [1] Source packages that build binaries unknown to the archive currently
> > need these binaries to be uploaded by the maintainers for reviewing by
> > ftp-master in NEW. IIRC the
On Mon, Dec 30, 2019 at 01:39:14PM +0100, Mattia Rizzolo wrote:
> On Mon, Dec 30, 2019 at 11:29:52AM +0100, Kurt Roeckx wrote:
> > Note that the name of the .changes file by the maintainer and the
> > buildd will be the same, and dak will reject it if that .changes
> > file already exists.
>
> Tha
On Mon, 2019-12-30 at 11:29 +0100, Kurt Roeckx wrote:
> Is it .deb and .changes file that you would move?
That would be the idea yeah.
> Note that the name of the .changes file by the maintainer and the
> buildd will be the same, and dak will reject it if that .changes
> file already exists.
I
On Mon, Dec 30, 2019 at 11:29:52AM +0100, Kurt Roeckx wrote:
> Note that the name of the .changes file by the maintainer and the
> buildd will be the same, and dak will reject it if that .changes
> file already exists.
That's true only in case of policy queues nowadays.
--
regards,
On 12/29/19 10:51 PM, Sebastiaan Couwenberg wrote:
> On 12/29/19 3:53 PM, Theodore Y. Ts'o wrote:
>> On Sun, Dec 29, 2019 at 09:52:44AM +0100, Enrico Zini wrote:
>>> some time ago I uploaded a new version of dballe, which went through NEW
>>> because of a change in binary package names (SONAME bump
On Mon, Dec 30, 2019 at 02:52:54AM +, Paul Wise wrote:
> On Sun, Dec 29, 2019 at 1:29 PM Roberto C. Sánchez wrote:
>
> > Would it not be possible to eliminate the need for the second
> > unnecessary upload by requiring two signed .changes files to go into
> > NEW? A signed binary changes whic
On Sun, Dec 29, 2019 at 10:51:36PM +0100, Sebastiaan Couwenberg wrote:
> > Wow, two weeks? I uploaded a new version of f2fs-tools back in July,
> > with the same issue (SONAME bump), and it's still not gotten through
> > NEW.
> >
> > I had assumed everyone was waiting 5-6+ months to get through N
On Sun, Dec 29, 2019 at 1:29 PM Roberto C. Sánchez wrote:
> Would it not be possible to eliminate the need for the second
> unnecessary upload by requiring two signed .changes files to go into
> NEW? A signed binary changes which would form the basis of the FTP
> master review and a signed source
On Sun, Dec 29, 2019 at 11:32 AM Paul Gevers wrote:
> [1] Source packages that build binaries unknown to the archive currently
> need these binaries to be uploaded by the maintainers for reviewing by
> ftp-master in NEW. IIRC there have been multiple proposals to avoid
> these binaries from either
On 12/29/19 3:53 PM, Theodore Y. Ts'o wrote:
> On Sun, Dec 29, 2019 at 09:52:44AM +0100, Enrico Zini wrote:
>> some time ago I uploaded a new version of dballe, which went through NEW
>> because of a change in binary package names (SONAME bump, IIRC). It took
>> two weeks to go through NEW and I tu
On Sun, Dec 29, 2019 at 12:32:24PM +0100, Paul Gevers wrote:
> > Now I see that things got stuck for the transition to testing, and I'm
> > asking for help figuring out what to do.
>
> I'm happy to help.
Thanks! <3
> The python3.8 transition is not a classical transition, so this normally
> hel
On Sun, Dec 29, 2019 at 09:52:44AM +0100, Enrico Zini wrote:
> Hello,
>
> some time ago I uploaded a new version of dballe, which went through NEW
> because of a change in binary package names (SONAME bump, IIRC). It took
> two weeks to go through NEW and I turned my energy towards other things
>
On Sun, Dec 29, 2019 at 12:32:24PM +0100, Paul Gevers wrote:
>
> [1] Source packages that build binaries unknown to the archive currently
> need these binaries to be uploaded by the maintainers for reviewing by
> ftp-master in NEW. IIRC there have been multiple proposals to avoid
> these binaries
Hi Enrico,
On 29-12-2019 09:52, Enrico Zini wrote:
> some time ago I uploaded a new version of dballe, which went through NEW
> because of a change in binary package names (SONAME bump, IIRC). It took
> two weeks to go through NEW and I turned my energy towards other things
> since then.
>
> Now
Hello,
some time ago I uploaded a new version of dballe, which went through NEW
because of a change in binary package names (SONAME bump, IIRC). It took
two weeks to go through NEW and I turned my energy towards other things
since then.
Now I see that things got stuck for the transition to testin
25 matches
Mail list logo
