Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Santiago Vila]

On Sun, 2 Oct 2016, Emilio Pozuelo Monfort wrote:

> > It is resolved in the sense it was agreed to make this RC,
> > but I still expected the release policy to be updated accordingly:
> > 
> > https://release.debian.org/stretch/rc_policy.txt
> > 
> > before closing this report.
> 
> I looked at that when I acked this, but I concluded that the policy already
> includes arch:all as there really is nothing arch:any specific. My attempts at
> mentioning arch:all only made the text too complicated.
> 
> I think things are fine as is.

Ok, I understand (and share) the goal of keeping the wording simple.

Now we "just" need to agree on the meaning of "packages must autobuild".

Some people still claim (even if it's not written anywhere) that it's
ok to downgrade FTBFS bugs when they didn't happen in buildd.debian.org.

My understanding of "packages must autobuild" is that the build should
succeed on any policy-compliant autobuilder which is sane and not
misconfigured.

Do I need another bug like this one so that Release Managers clarify
the meaning of "packages must autobuild"?

Thanks.

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Emilio Pozuelo Monfort]

On 11/09/16 14:50, Santiago Vila wrote:
> On Sun, 11 Sep 2016, Niels Thykier wrote:
> 
>> On Mon, 1 Aug 2016 23:23:14 +0200 (CEST) Santiago Vila 
>> wrote:
>>> Greetings.
>>>
>>> I've finally raised to "serious" all the known bugs regarding
>>> "dpkg-buildpackage -A" that were still open.
>>>
>>> Thanks.
>>
>> AFAICT, this bug is now resolved - closing accordingly. :)
> 
> It is resolved in the sense it was agreed to make this RC,
> but I still expected the release policy to be updated accordingly:
> 
> https://release.debian.org/stretch/rc_policy.txt
> 
> before closing this report.

I looked at that when I acked this, but I concluded that the policy already
includes arch:all as there really is nothing arch:any specific. My attempts at
mentioning arch:all only made the text too complicated.

I think things are fine as is.

Cheers,
Emilio

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Santiago Vila]

On Sun, 11 Sep 2016, Niels Thykier wrote:

> On Mon, 1 Aug 2016 23:23:14 +0200 (CEST) Santiago Vila 
> wrote:
> > Greetings.
> > 
> > I've finally raised to "serious" all the known bugs regarding
> > "dpkg-buildpackage -A" that were still open.
> > 
> > Thanks.
> 
> AFAICT, this bug is now resolved - closing accordingly. :)

It is resolved in the sense it was agreed to make this RC,
but I still expected the release policy to be updated accordingly:

https://release.debian.org/stretch/rc_policy.txt

before closing this report.

[ Not that updating the policy is particularly helpful. In fact,
  current policy already says "packages must autobuild" and there are
  still people who downgrade RC bugs about missing build-dependencies
  to "normal"... ].

Thanks.

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Santiago Vila]

Greetings.

I've finally raised to "serious" all the known bugs regarding
"dpkg-buildpackage -A" that were still open.

Thanks.

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Santiago Vila]

On Sun, 24 Jul 2016, Emilio Pozuelo Monfort wrote:

> On 23/07/16 19:20, Santiago Vila wrote:
>
> > Still ok to consider this as a release goal?
> 
> Absolutely.

Great, thanks!

On Wed, 20 Jul 2016, Lucas Nussbaum wrote:

> The additional bugs I filed are at:
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=qa-indep;users=debian...@lists.debian.org

To celebrate, I've created four tags to classify *all* the bugs:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=sanv...@debian.org;tag=arch-all-swapped-binary-targets
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=sanv...@debian.org;tag=arch-all-missing-build-indep
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=sanv...@debian.org;tag=arch-all-arch-any-missing-build-indep
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=sanv...@debian.org;tag=arch-all-arch-any-failing-binary-indep

This time it should be ok to add new bugs to those tags, because their
names are now clearly prefixed by either arch-all-arch-any or arch-all.

(The old tag, naively named "binary-indep" should be considered obsolete).

Thanks.

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Emilio Pozuelo Monfort]

On 23/07/16 19:20, Santiago Vila wrote:
> Kind Release Managers:
> 
> All the bugs reported by Lucas Nussbaum last week which have not been
> resolved yet are now either in "pending upload" state, or there is a
> patch available:
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=qa-indep;users=debian...@lists.debian.org
> 
> Because it was not expected that we would discover a lot more bugs of
> this type, I'd like this to be reconfirmed:
> 
> Still ok to consider this as a release goal?

Absolutely.

Thanks,
Emilio

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Santiago Vila]

Kind Release Managers:

All the bugs reported by Lucas Nussbaum last week which have not been
resolved yet are now either in "pending upload" state, or there is a
patch available:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=qa-indep;users=debian...@lists.debian.org

Because it was not expected that we would discover a lot more bugs of
this type, I'd like this to be reconfirmed:

Still ok to consider this as a release goal?

(If yes, I will probably wait one more week for the dust to settle
before raising severities, or maybe wait for some kind of official
announcement).


As a summary, this is what we aim for:

* Every package in stretch creating both Arch:all and Arch:any
packages should build ok when using "dpkg-buildpackage -A" or
"dpkg-buildpackage -B". The command "dpkg-buildpackage -A"
should work in the Arch:all autobuilder, which runs amd64.

* Every package in stretch creating only Arch:all packages should
build ok when using "dpkg-buildpackage -A". The command
"dpkg-buildpackage -A" should work in the Arch:all autobuilder,
which runs amd64.

* It was already a release goal that "dpkg-buildpackage -B" should
always work (on the archs it is expected to work), but the official
autobuilders have been testing this for a lot of years already.


The above conditions would guarantee that every package in stretch may
be uploaded in source-only form.

Thanks.

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Lucas Nussbaum]

On 21/07/16 at 16:40 +0200, Sven Joachim wrote:
> On 2016-07-21 16:18 +0200, Santiago Vila wrote:
> 
> > On Thu, Jul 21, 2016 at 02:21:02AM +0200, Santiago Vila wrote:
> >
> >> Some of the new bugs are like this:
> >> 
> >>   make: *** No rule to make target 'build-indep'. Stop.
> >> 
> >> Targets build-arch and build-indep are mandatory, and this was already
> >> decided by dpkg author. This is not new, so I would raise those bugs
> >> to serious now.
> >
> > A small clarification: What was decided by dpkg author is to drop a
> > hack which enabled those packages to build successfully.
> >
> > The mass bug filing was announced by Niels here:
> >
> > https://lists.debian.org/debian-devel/2016/04/msg00023.html
> >
> > Quoting Niels:
> >
> >> We intend to do another round of MBF for this problem once we have
> >> located a way to break down the remaining packages into smaller and more
> >> manageable sets.
> >
> > I think the second round of MBF did not take place yet.
> 
> It did, albeit a bit later than planned.  See Guillem's followup this
> month[1] and the list of bugs Niels has filed[2].

No, that's the list of bugs filed as part of the initial MBF (on 99
packages), as announced by Niels in April. Then later the severity was
upgraded from important to serious.

Lucas

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Lucas Nussbaum]

clone 830997 -1
reassign -1 lintian
retitle -1 lintian: fails to detect missing build-indep target in 9 packages
thanks

On 21/07/16 at 16:18 +0200, Santiago Vila wrote:
> On Thu, Jul 21, 2016 at 02:21:02AM +0200, Santiago Vila wrote:
> 
> > Some of the new bugs are like this:
> > 
> >   make: *** No rule to make target 'build-indep'. Stop.
> > 
> > Targets build-arch and build-indep are mandatory, and this was already
> > decided by dpkg author. This is not new, so I would raise those bugs
> > to serious now.
> 
> A small clarification: What was decided by dpkg author is to drop a
> hack which enabled those packages to build successfully.
> 
> The mass bug filing was announced by Niels here:
> 
> https://lists.debian.org/debian-devel/2016/04/msg00023.html
> 
> Quoting Niels:
> 
> > We intend to do another round of MBF for this problem once we have
> > located a way to break down the remaining packages into smaller and more
> > manageable sets.
> 
> I think the second round of MBF did not take place yet. So: How is it
> possible that you (Lucas) found so few packages that didn't build?

Hi,

I indeed ran into many bugs already filed by Niels, and only filed bugs
for the packages where bugs were missing.

It seems that, when bugs were missing, lintian was unable to detect the
missing targets. So that's a bug in lintian (it fails to detect that
those 9 packages are missing build-indep). Cloning accordingly.

Also, the lintian page[1] includes many packages that are missing build-indep,
but don't build any Architecture:all package. That's still a bug in the
packages (as build-indep is required even in that case) but I wouldn't detect
it as I restricted my test to packages building Arch:all binaries.
Maybe it could make sense for lintian to distinguish those two cases
(missing build-indep and building arch:all vs missing build-indep and
not building arch:all).

Finally, it seems that dpkg still has a workaround for missing build-indep for
packages building only Arch:all binaries. For example, see this log for 
libgtk2-ex-podviewer-perl_0.18-1:

> dpkg-buildpackage
> -
> 
> dpkg-buildpackage: info: source package libgtk2-ex-podviewer-perl
> dpkg-buildpackage: info: source version 0.18-1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Ryan Niebur 
>  dpkg-source --before-build libgtk2-ex-podviewer-perl-0.18
>  fakeroot debian/rules clean
> dh clean
>dh_testdir
>dh_auto_clean
>dh_clean
> dpkg-buildpackage: warning: debian/rules must be updated to support the 
> 'build-arch' and 'build-indep' targets (at least 'build-indep' seems to be 
> missing)
>  debian/rules build
> dh build
>dh_testdir
>dh_update_autotools_config
>dh_auto_configure

That's why I did not run into more failures.

[1] https://lintian.debian.org/tags/debian-rules-missing-recommended-target.html

Grepping my build logs for the above warning message, the following 540
packages are missing build-indep (and building only Arch:all):

abicheck abntex adzapper apf-firewall apsfilter apt-dpkg-ref apticron aptoncd
apt-show-source archmbox aspell-cs asql attal-themes autoconf2.59 autoconf2.64
autopsy babiloo bauble beancounter biabam bindgraph binstats biojava-live
bittornado bjsonrpc bum cadubi castle-combat cdlabelgen cffi cfortran cgvg
chaksem checksecurity childsplay-alphabet-sounds-bg
childsplay-alphabet-sounds-ca childsplay-alphabet-sounds-de
childsplay-alphabet-sounds-el childsplay-alphabet-sounds-en-gb
childsplay-alphabet-sounds-es childsplay-alphabet-sounds-fr
childsplay-alphabet-sounds-it childsplay-alphabet-sounds-nb
childsplay-alphabet-sounds-nl childsplay-alphabet-sounds-pt
childsplay-alphabet-sounds-ro childsplay-alphabet-sounds-ru
childsplay-alphabet-sounds-sl childsplay-alphabet-sounds-sv clamassassin
cl-babel cl-closer-mop cl-cluck cl-contextl cl-fftw3 cl-flexichain cl-getopt
cli-common clipf cl-irc cl-irc-logger cl-lml2 cl-lml cl-lw-compat cl-mcclim
cl-modlisp cl-pg cl-photo cl-pipes cl-portable-aserve cl-ppcre cl-ptester
cl-pubmed cl-rlc cl-rt cl-split-sequence cl-xlunit cl-xmls cl-xptest coco-doc
colorgcc command-not-found console-cyrillic controlaula creoleparser crip
ctn-doc culmus-fancy customdeb cvs-mailcommit darcsweb dbix-easy-perl
ddccontrol-db debget debian-builder debian-zh-faq debsecan deps dh-buildinfo
dict-bouvier dictclient dictdlib dict-gazetteer2k dict-moby-thesaurus
discover-data ditrack dkimproxy dlint dlocate dns323-firmware-tools dns-browse
docbook2odf docbook5-xml docbook-simple docbook-xml doc-linux-hr doctorj
drobo-utils efp elida elscreen emacs-jabber epic4-help erc essays1743 ewipe
extra-xdg-menus festival-czech festival-it festvox-czech-dita festvox-czech-krb
festvox-czech-machac festvox-czech-ph fig2ps file-rc filler flamethrower
flexbackup flexi-streams flowscan fluid-soundfont focalinux fofix-dfsg
fonts-jsmath fortunes-bg fortunes-bofh-excuses fortunes-es fortunes-fr
fortunes-ru freepats 

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Sven Joachim]

On 2016-07-21 16:18 +0200, Santiago Vila wrote:

> On Thu, Jul 21, 2016 at 02:21:02AM +0200, Santiago Vila wrote:
>
>> Some of the new bugs are like this:
>> 
>>   make: *** No rule to make target 'build-indep'. Stop.
>> 
>> Targets build-arch and build-indep are mandatory, and this was already
>> decided by dpkg author. This is not new, so I would raise those bugs
>> to serious now.
>
> A small clarification: What was decided by dpkg author is to drop a
> hack which enabled those packages to build successfully.
>
> The mass bug filing was announced by Niels here:
>
> https://lists.debian.org/debian-devel/2016/04/msg00023.html
>
> Quoting Niels:
>
>> We intend to do another round of MBF for this problem once we have
>> located a way to break down the remaining packages into smaller and more
>> manageable sets.
>
> I think the second round of MBF did not take place yet.

It did, albeit a bit later than planned.  See Guillem's followup this
month[1] and the list of bugs Niels has filed[2].

Cheers,
   Sven


1. https://lists.debian.org/debian-devel/2016/07/msg00130.html
2. 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=arch-all-and-any-missing-targets;users=ni...@thykier.net

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Santiago Vila]

On Thu, Jul 21, 2016 at 02:21:02AM +0200, Santiago Vila wrote:

> Some of the new bugs are like this:
> 
>   make: *** No rule to make target 'build-indep'. Stop.
> 
> Targets build-arch and build-indep are mandatory, and this was already
> decided by dpkg author. This is not new, so I would raise those bugs
> to serious now.

A small clarification: What was decided by dpkg author is to drop a
hack which enabled those packages to build successfully.

The mass bug filing was announced by Niels here:

https://lists.debian.org/debian-devel/2016/04/msg00023.html

Quoting Niels:

> We intend to do another round of MBF for this problem once we have
> located a way to break down the remaining packages into smaller and more
> manageable sets.

I think the second round of MBF did not take place yet. So: How is it
possible that you (Lucas) found so few packages that didn't build?

Thanks.

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Lucas Nussbaum]

On 21/07/16 at 02:21 +0200, Santiago Vila wrote:
> On Wed, Jul 20, 2016 at 09:47:52PM +0200, Lucas Nussbaum wrote:
> > On 15/07/16 at 00:23 +0200, Santiago Vila wrote:
> > 
> > I did some work to verify Santiago's list of affected packages, and
> > identified more affected packages. The additional bugs I filed are at:
> > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=qa-indep;users=debian...@lists.debian.org
> > 
> > (I didn't want to directly tag them using Santiago's tag in case some
> > manual screening was wanted.)
> > 
> > I only filed them as severity: important. Feel free to bump the severity
> > to serious when you see fit. I already mentioned in the bug reports that
> > severity will be set to serious at some point, and pointed to this bug.
> 
> Thanks a lot for double-checking.
> 
> 
> Some of the new bugs are like this:
> 
>   make: *** No rule to make target 'build-indep'. Stop.
> 
> Targets build-arch and build-indep are mandatory, and this was already
> decided by dpkg author. This is not new, so I would raise those bugs
> to serious now.

Hi,

Those bugs are:
 • #831918 [i|  |  ] [src:bglibs] bglibs: FTBFS with dpkg-buildpackage -A: 
make: *** No rule to make target 'build-indep'. Stop.
 • #831921 [i|  |  ] [src:daemontools] daemontools: FTBFS with 
dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop.
 • #831933 [i|  |  ] [src:mono] mono: FTBFS with dpkg-buildpackage -A: make: 
*** No rule to make target 'build-indep'. Stop.
 • #831944 [i|  |  ] [src:pyorbit] pyorbit: FTBFS with dpkg-buildpackage -A: 
make: *** No rule to make target 'build-indep'. Stop.
 • #831945 [i|  |  ] [src:pygtk] pygtk: FTBFS with dpkg-buildpackage -A: make: 
*** No rule to make target 'build-indep'. Stop.
 • #831950 [i|  |  ] [src:gnome-python] gnome-python: FTBFS with 
dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop.
 • #831960 [i|  |  ] [src:pygobject-2] pygobject-2: FTBFS with 
dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop.
 • #831961 [i|  |  ] [src:proftpd-dfsg] proftpd-dfsg: FTBFS with 
dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop.
 • #831963 [i|  |  ] [src:netqmail] netqmail: FTBFS with dpkg-buildpackage -A: 
make: *** No rule to make target 'build-indep'. Stop.

I've just raised their severity to serious.

> Also: Could you tag those bugs differently so that we can differentiate
> them from the remaining ones? We certainly don't want the Release Managers
> to think we want to add 61 more RC bugs for stretch when they are
> really less than that.

I'm not sure we should bother with that... they will all be RC soon anyway.

Lucas

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Santiago Vila]

On Wed, Jul 20, 2016 at 09:47:52PM +0200, Lucas Nussbaum wrote:
> On 15/07/16 at 00:23 +0200, Santiago Vila wrote:
> 
> I did some work to verify Santiago's list of affected packages, and
> identified more affected packages. The additional bugs I filed are at:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=qa-indep;users=debian...@lists.debian.org
> 
> (I didn't want to directly tag them using Santiago's tag in case some
> manual screening was wanted.)
> 
> I only filed them as severity: important. Feel free to bump the severity
> to serious when you see fit. I already mentioned in the bug reports that
> severity will be set to serious at some point, and pointed to this bug.

Thanks a lot for double-checking.


Some of the new bugs are like this:

  make: *** No rule to make target 'build-indep'. Stop.

Targets build-arch and build-indep are mandatory, and this was already
decided by dpkg author. This is not new, so I would raise those bugs
to serious now.

Also: Could you tag those bugs differently so that we can differentiate
them from the remaining ones? We certainly don't want the Release Managers
to think we want to add 61 more RC bugs for stretch when they are
really less than that.


I also see many bugs like this:

  binary build with no binary artifacts found; cannot distribute

They happen on packages generating only "Arch: all" packages
(which is why I didn't check them).

This fact, however, makes most (all?) of those bugs trivial to fix, as
it usually happens that binary-arch and binary-indep are just swapped.

Two random examples:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831911
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831971


I'll take a closer look at the new bugs you reported in the following
days.

Thanks.

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Lucas Nussbaum]

On 15/07/16 at 00:23 +0200, Santiago Vila wrote:
> On Wed, 13 Jul 2016, Emilio Pozuelo Monfort wrote:
> 
> > Great. We can handle that for Stretch. You can send a ping to the bug 
> > reports
> > saying that these are going to be RC for Stretch and that you will bump them
> > after a week, and then do that.
> 
> Hi. The pings have been sent. Bugs of type "pending upload" and "patch 
> available"
> yesterday, bugs of type "unclassified" today. Will probably bump severities
> during the weeking of next week.
> 
> Thanks a lot.

Hi,

I did some work to verify Santiago's list of affected packages, and
identified more affected packages. The additional bugs I filed are at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=qa-indep;users=debian...@lists.debian.org

(I didn't want to directly tag them using Santiago's tag in case some
manual screening was wanted.)

I only filed them as severity: important. Feel free to bump the severity
to serious when you see fit. I already mentioned in the bug reports that
severity will be set to serious at some point, and pointed to this bug.

Also, I ran into #805228 which causes build failures for many Java
packages (which Santiago already identified). That bug should probably
be set serious at the same time as the initial set. Once that bug is
fixed, the affected Java packages should be build-tested again. (list
available in #805228)

Lucas

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Manuel A. Fernandez Montecelo]

Hi,

2016-07-13 17:21 Santiago Vila:

[...]

Back in November I started to check and report each and every source
package for which "dpkg-buildpackage -A" fails.
[...]

Making this a release goal would mean that each and every package in
stretch (once it's stable) would be suitable to be uploaded in
source-only form. I think this feature would be particularly
interesting for the security team.


Just wanted to thank you for this effort, very nice work.

And even if I don't have any authority on the matter, to say that I
believe that it's a worthwhile release goal.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Santiago Vila]

On Wed, 13 Jul 2016, Emilio Pozuelo Monfort wrote:

> Great. We can handle that for Stretch. You can send a ping to the bug reports
> saying that these are going to be RC for Stretch and that you will bump them
> after a week, and then do that.

Hi. The pings have been sent. Bugs of type "pending upload" and "patch 
available"
yesterday, bugs of type "unclassified" today. Will probably bump severities
during the weeking of next week.

Thanks a lot.

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed pending

On 13/07/16 18:58, Santiago Vila wrote:
> On Wed, 13 Jul 2016, Emilio Pozuelo Monfort wrote:
> 
>> Thanks for working on this. I'm all for doing this. But before introducing 
>> ~100
>> RC bugs, can you give me the intersection of the remaining affected packages 
>> and
>> the key packages?
>>
>> https://udd.debian.org/cgi-bin/key_packages.cgi
>>
>> See the "Final list of 3345 key source packages"
> 
> Sure. There are 24 key packages affected:
> 
> accountsservice
> acpica-unix
> cmocka
> cython
> db5.3
> ecj
> eclipse
> fftw3
> gtkglext
> guile-2.0
> heimdal
> libconfig
> libmtp
> libnative-platform-java
> libtool
> libwps
> llvm-toolchain-3.8
> net-snmp
> ocaml
> python-scipy
> sane-backends
> sofia-sip
> taglib
> tiff
> 
> (From those 24, 8 of them have a patch, 15 do not, and 1 is pending upload).

Great. We can handle that for Stretch. You can send a ping to the bug reports
saying that these are going to be RC for Stretch and that you will bump them
after a week, and then do that. (And after that, file any new bugs at "serious"
severity, obviously.)

I'll take care of updating the freeze policy and sending an announcement.

Cheers,
Emilio

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Santiago Vila]

On Wed, 13 Jul 2016, Emilio Pozuelo Monfort wrote:

> Thanks for working on this. I'm all for doing this. But before introducing 
> ~100
> RC bugs, can you give me the intersection of the remaining affected packages 
> and
> the key packages?
> 
> https://udd.debian.org/cgi-bin/key_packages.cgi
> 
> See the "Final list of 3345 key source packages"

Sure. There are 24 key packages affected:

accountsservice
acpica-unix
cmocka
cython
db5.3
ecj
eclipse
fftw3
gtkglext
guile-2.0
heimdal
libconfig
libmtp
libnative-platform-java
libtool
libwps
llvm-toolchain-3.8
net-snmp
ocaml
python-scipy
sane-backends
sofia-sip
taglib
tiff

(From those 24, 8 of them have a patch, 15 do not, and 1 is pending upload).

Thanks.

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Emilio Pozuelo Monfort]

Hi Santiago,

On 13/07/16 18:21, Santiago Vila wrote:
> Package: release.debian.org
> Severity: wishlist
> 
> Dear Release Managers:
> 
> Back in November I started to check and report each and every source
> package for which "dpkg-buildpackage -A" fails.
> 
> Approximately 293 bugs so far have been filed about this issue:
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=binary-indep;users=sanv...@debian.org
> 
> Most of them (182) are already fixed and a bunch of the remaining ones
> have patches available.
> 
> 
> With this report I'd like to ask for permission to consider this as a
> release goal for stretch. This way the bugs would be raised to serious
> and they would be treated like any other FTBFS bug.
> 
> Making this a release goal would mean that each and every package in
> stretch (once it's stable) would be suitable to be uploaded in
> source-only form. I think this feature would be particularly
> interesting for the security team.

Thanks for working on this. I'm all for doing this. But before introducing ~100
RC bugs, can you give me the intersection of the remaining affected packages and
the key packages?

https://udd.debian.org/cgi-bin/key_packages.cgi

See the "Final list of 3345 key source packages"

Cheers,
Emilio

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Santiago Vila]

Package: release.debian.org
Severity: wishlist

Dear Release Managers:

Back in November I started to check and report each and every source
package for which "dpkg-buildpackage -A" fails.

Approximately 293 bugs so far have been filed about this issue:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=binary-indep;users=sanv...@debian.org

Most of them (182) are already fixed and a bunch of the remaining ones
have patches available.


With this report I'd like to ask for permission to consider this as a
release goal for stretch. This way the bugs would be raised to serious
and they would be treated like any other FTBFS bug.

Making this a release goal would mean that each and every package in
stretch (once it's stable) would be suitable to be uploaded in
source-only form. I think this feature would be particularly
interesting for the security team.


If you agree on making this a release goal, I can think of two ways of
doing this:

1) The wording in this page could be modified:

https://release.debian.org/stretch/rc_policy.txt

Currently it says:

  Packages must autobuild without failure on all architectures on
  which they are supported.

Maybe adding "This requirement includes the traditional
architecture-specific autobuilders and also the "Arch: all" autobuilder".
or something alike.

2) Or maybe we could just state that "Packages must autobuild" implicitly
refers to all available autobuilders, but in such case an official
statement from you clarifying how the paragraph should be interpreted
would help.


In case this release goal is accepted, I'm open for suggestions about
how to proceed (for example, if a last warning mail should be sent to
the bug reports before raising severities, waiting for a week or two,
etc. things like that).

Thanks.