GRIPE: A package is not FTBFS if the dependencies can't be installed

[Richard Shaw]

I received a FTBFS[1] on one of my packages for the F26 rebuild only to
find out the only reason it failed (that I know of thus far) is that not
all the dependencies could be installed.

The root cause seems to be that not all dependent packages were rebuilt
when boost was updated to 1.63. Since I maintain said package I'm taking
care of it now...

Is there an easy way to segregate failures in root.log (exit !=0) versus a
real build failure?

It may be a bit pedantic but I don't like getting assigned bugs saying the
package can't be built from source when in fact, compilation never started
to begin with because the dependencies could not be met.

Richard

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1423104

[Mamoru TASAKA]

----- 元のメッセージ -----
>  差出人: "Richard Shaw" <hobbes1069(a)gmail.com&gt;
>  宛先: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  送信済み: 2017年2月17日, 金曜日 12:21:07
>  件名: GRIPE: A package is not FTBFS if the dependencies can't be installed
>  
>  I received a FTBFS[1] on one of my packages for the F26 rebuild only to
>  find out the only reason it failed (that I know of thus far) is that not
>  all the dependencies could be installed.
>  
>  The root cause seems to be that not all dependent packages were rebuilt
>  when boost was updated to 1.63. Since I maintain said package I'm taking
>  care of it now... 
But in that case, such package is actually FTBFS (because BR cannot be installed).
You have to modify dependency package by yourself or urge maintainers of such
packages to modify them to resolve FTBFS on your package.

The correct way to show this is to make FTBFS bug on your package blocked by
("Depends on") bug reports for such depdendency package.

>  Is there an easy way to segregate failures in root.log (exit !=0)
> versus a
>  real build failure?
>  
>  It may be a bit pedantic but I don't like getting assigned bugs saying the
>  package can't be built from source when in fact, compilation never started
>  to begin with because the dependencies could not be met.
>  
>  Richard
>  
>  [1] https://bugzilla.redhat.com/show_bug.cgi?id=1423104
>   
Regards,
Mamoru

[Zbigniew Jędrzejewski-Szmek]

On Fri, Feb 17, 2017 at 12:32:54PM +0900, Mamoru TASAKA wrote:
>  
>  
>  ----- 元のメッセージ -----
>  > 差出人: "Richard Shaw" <hobbes1069(a)gmail.com&gt;
>  > 宛先: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  > 送信済み: 2017年2月17日, 金曜日 12:21:07
>  > 件名: GRIPE: A package is not FTBFS if the dependencies can't be installed
>  > 
>  > I received a FTBFS[1] on one of my packages for the F26 rebuild only to
>  > find out the only reason it failed (that I know of thus far) is that not
>  > all the dependencies could be installed.
>  > 
>  > The root cause seems to be that not all dependent packages were rebuilt
>  > when boost was updated to 1.63. Since I maintain said package I'm taking
>  > care of it now...
>  
>  But in that case, such package is actually FTBFS (because BR cannot be installed).
>  You have to modify dependency package by yourself or urge maintainers of such
>  packages to modify them to resolve FTBFS on your package.
>  
>  The correct way to show this is to make FTBFS bug on your package blocked by
>  ("Depends on") bug reports for such depdendency package. 
Filing bugs for transitive FTBFS during a mass rebuild isn't
particularly helpful as it is done now. Instead of the current generic
text, it'd be great if the bug could indicate that the failure was
because some dep is FTBFS.  If those bugs could be made to
depend on the FTBFS bugs of the deps, that'd be even nicer.

I think that's another case where we do the easy thing by opening bugs,
without taking into account the amount of wasted maintainer attention on an
issue that they cannot (without provenpackager privs) actually solve themselves.

Zbyszek

> > Is there an easy way to segregate failures in root.log (exit !=0) versus a
> > real build failure?
> > 
> > It may be a bit pedantic but I don't like getting assigned bugs saying the
> > package can't be built from source when in fact, compilation never started
> > to begin with because the dependencies could not be met.
> > 
> > Richard
> > 
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1423104
> > 
> 
> Regards,
> Mamoru
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

[Peter Robinson]

> > > I received a FTBFS[1] on one of my packages for the F26
> rebuild only to
> > > find out the only reason it failed (that I know of thus far) is that not
> > > all the dependencies could be installed.
> > >
> > > The root cause seems to be that not all dependent packages were rebuilt
> > > when boost was updated to 1.63. Since I maintain said package I'm taking
> > > care of it now...
> >
> > But in that case, such package is actually FTBFS (because BR cannot be installed).
> > You have to modify dependency package by yourself or urge maintainers of such
> > packages to modify them to resolve FTBFS on your package.
> >
> > The correct way to show this is to make FTBFS bug on your package blocked by
> > ("Depends on") bug reports for such depdendency package.
>
>  Filing bugs for transitive FTBFS during a mass rebuild isn't
>  particularly helpful as it is done now. Instead of the current generic
>  text, it'd be great if the bug could indicate that the failure was
>  because some dep is FTBFS.  If those bugs could be made to
>  depend on the FTBFS bugs of the deps, that'd be even nicer.
>
>  I think that's another case where we do the easy thing by opening bugs,
>  without taking into account the amount of wasted maintainer attention on an
>  issue that they cannot (without provenpackager privs) actually solve themselves. 
Basically to go from simple logic to something a lot more complex you
need to be able to query for and apply quite a bit of
power/api/understanding which the simple script used doesn't have, and
likely at the time of writing infomation and compute power wasn't
available so it's a means of highlighting there is an issue that needs
further investigation. rel-eng has limited resources and basically to
date it hasn't been seen as a priority over other more pressing needs
for resources. Like everything else in Fedora the code for the script
is public [1].

Peter

[1] https://pagure.io/releng

[Randy Barlow]

On Fri, 2017-02-17 at 05:08 +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  Filing bugs for transitive FTBFS during a mass rebuild isn't
>  particularly helpful as it is done now. 
I think it is helpful, because even if it is not the fault of the
package that failed to build, the package does still need to be rebuilt
once its dependencies are sorted out. The FTBFS bug report is a nice
way to track that the rebuild is still needed.

[Jonathan Wakely]

On 17/02/17 13:21 -0500, Randy Barlow wrote:
> On Fri, 2017-02-17 at 05:08 +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > Filing bugs for transitive FTBFS during a mass rebuild isn't
> > particularly helpful as it is done now.
>
> I think it is helpful, because even if it is not the fault of the
> package that failed to build, the package does still need to be rebuilt
> once its dependencies are sorted out. The FTBFS bug report is a nice
> way to track that the rebuild is still needed. 
Agreed. If your package can't build because a dependency is FTBFS then
set the "Depends on" field to the bug report for the dependency's
build failure.