On Thu, 07 Aug 2008, Goswin von Brederlow wrote:
> Petter Reinholdtsen <pere@hungry.com> writes:
> > [Matthew Johnson]
> >> Or at least didn't block testing migration. I'm happy if porters decide
> >> my package isn't for them, as long as it doesn't stop it being for
> >> anyone else either...
> >
> > I agree. Perhaps a new rule should be introduced, that when a porter
> > flag a package as NFU on a given architecture, he should be required
> > to file a removal request for the binaries on that architecture too,
> > and CC the package maintainer to let the maintainer know about the
> > decision.
> >
> > Silently flagging packages as NFU on a given architecture do not seem
> > like a good idea, and expecting the maintainer to ask for removal
> > without letting the maintainer know that the porter refuses to build a
> > given package can only lead to frustration and friction within the
> > project.
> >
> > I assume such removal requests can be scripted, to make it easy for
> > the porter/buildd maintainer to do.
> >
> > Happy hacking,
>
> Except that sometimes packages are flagges N-F-U because they break
> the buildd chroot during build. For example they pull in a package
> that has a broken maintainer script.
>
> Such N-F-Us would be temporary until the faulty package is fixed and
> should really not cause any removals.

Then, they should be special-cased, and the rest (that are not short-term
NFUs) should be made DD-friendly by doing what Pere suggested.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Henrique de Moraes Holschuh <hmh@debian.org> writes:

> On Thu, 07 Aug 2008, Goswin von Brederlow wrote:
>> Petter Reinholdtsen <pere@hungry.com> writes:
>> > [Matthew Johnson]
>> >> Or at least didn't block testing migration. I'm happy if porters decide
>> >> my package isn't for them, as long as it doesn't stop it being for
>> >> anyone else either...
>> >
>> > I agree. Perhaps a new rule should be introduced, that when a porter
>> > flag a package as NFU on a given architecture, he should be required
>> > to file a removal request for the binaries on that architecture too,
>> > and CC the package maintainer to let the maintainer know about the
>> > decision.
>> >
>> > Silently flagging packages as NFU on a given architecture do not seem
>> > like a good idea, and expecting the maintainer to ask for removal
>> > without letting the maintainer know that the porter refuses to build a
>> > given package can only lead to frustration and friction within the
>> > project.
>> >
>> > I assume such removal requests can be scripted, to make it easy for
>> > the porter/buildd maintainer to do.
>> >
>> > Happy hacking,
>>
>> Except that sometimes packages are flagges N-F-U because they break
>> the buildd chroot during build. For example they pull in a package
>> that has a broken maintainer script.
>>
>> Such N-F-Us would be temporary until the faulty package is fixed and
>> should really not cause any removals.
>
> Then, they should be special-cased, and the rest (that are not short-term
> NFUs) should be made DD-friendly by doing what Pere suggested.

The actual long term solution is the packages-arch-specific file.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Henrique de Moraes Holschuh wrote:

On Thu, 07 Aug 2008, Goswin von Brederlow wrote:

Petter Reinholdtsen <pere@hungry.com> writes:

[Matthew Johnson]

Or at least didn't block testing migration. I'm happy if porters decide
my package isn't for them, as long as it doesn't stop it being for
anyone else either...

I agree. Perhaps a new rule should be introduced, that when a porter
flag a package as NFU on a given architecture, he should be required
to file a removal request for the binaries on that architecture too,
and CC the package maintainer to let the maintainer know about the
decision.

Silently flagging packages as NFU on a given architecture do not seem
like a good idea, and expecting the maintainer to ask for removal
without letting the maintainer know that the porter refuses to build a
given package can only lead to frustration and friction within the
project.

I assume such removal requests can be scripted, to make it easy for
the porter/buildd maintainer to do.

Happy hacking,

Except that sometimes packages are flagges N-F-U because they break
the buildd chroot during build. For example they pull in a package
that has a broken maintainer script.

Such N-F-Us would be temporary until the faulty package is fixed and
should really not cause any removals.


Then, they should be special-cased, and the rest (that are not short-term
NFUs) should be made DD-friendly by doing what Pere suggested.


All NFUs are supposed to be short-term. Though some not as short-term as
others... Long term issues should be in Packages-arch-specific.


Some NFUs are used for long-term (non-)issues currently, though that's
not at all what it's supposed to be used for. It would be better if that
just changed...


Cheers

Luk


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

[Goswin von Brederlow]
> The actual long term solution is the packages-arch-specific file.

I assume you know something I do not, as I do not understand what you
mean by "the packages-arch-specific file", but I suspect a file is
unable to solve a problem with frustration and friction, as that
problem seem to originate in lack of communication, and not features
in a file.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

[Frank Lichtenheld]
> While I agree with the general sentiment, there is really nothing
> "mysterious" about checking buildd.debian.org (and calling it that
> is just finding excuses for maintainers that don't spend the time to
> check the status of their packages).

I would rather have maintainers spend time improving their packages
instead of wasting it trying to figure out why some architecture
fail/refuses to build their package.

I know I have wasted a lot of time trying to figure out why some
architecture suddenly fail to autobuild one of mine packages or the
packages my packages build depend on, I and really wish the person
responsible for the blockage would have told me about it and explained
why.

The problems

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Aug 07, 2008 at 09:57:49PM +0200, Petter Reinholdtsen wrote:
>
> [Frank Lichtenheld]
> > While I agree with the general sentiment, there is really nothing
> > "mysterious" about checking buildd.debian.org (and calling it that
> > is just finding excuses for maintainers that don't spend the time to
> > check the status of their packages).
>
> I would rather have maintainers spend time improving their packages
> instead of wasting it trying to figure out why some architecture
> fail/refuses to build their package.
>
In some (many?) cases that leads to direct improvement of the package.
I have had a package quit building on a particular architecture and it
ended revealing itself as a problem with something in the build system
parsing compiler output of all things (the shift from gcc 4.2 to 4.3 on
some arches triggered the failure). It would have eventually manifested
itself on the main architectures when they switched. As it was, I was
able to get upstream to fix the package will ahead of the switch in
Debian.

Regards,

-Roberto

--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

On Thu, Aug 07, 2008 at 04:06:50PM -0400, Roberto C. S?nchez wrote:
> On Thu, Aug 07, 2008 at 09:57:49PM +0200, Petter Reinholdtsen wrote:

> > I would rather have maintainers spend time improving their packages
> > instead of wasting it trying to figure out why some architecture
> > fail/refuses to build their package.

> In some (many?) cases that leads to direct improvement of the package.
> I have had a package quit building on a particular architecture and it
> ended revealing itself as a problem with something in the build system

All of which would go a lot better if the maintainer were told about
whatever issue caused the buildd to be configured not to build the
package rather than having to discover that this has happened and
infer the reasoning for the decision.

Also note that this discussion is about the buildds being configured to
not even try compiling a package, not about build failures encountered
on the buildds.

--
"You grabbed my hand and we fell into it, like a daydream - or a fever."


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org