Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Ole Streicher]

Sean Whitton  writes:
> I agree with the principle that test failures should be RC by default.

This is something which seems to have no disagreement here. My concern
is just that I want to have a simple way to override this, to assign
this to a different package etc. I want to have the same flexibility
here as for bugs.

> I think we need an additional field in d/tests/control to mark
> individual tests as non-critical (this wouldn't really help Ole's 9000
> tests package though).

While this is a really large test suite, it also wouldn't help for
others, since there are many packages with > 100 tests: aplpy has ~250
tests, astroml has ~210 tests, gnudatalanguage has ~170 tests etc. Even
when the package itself is rather "small", the test count is quite
nice -- the github ecosystem with test coverage tools (and badges) helps
here, as well as powerful Python test packages.

Especially modern packages with a highly motivated upstream come with a
large number of tests (and they care about failures). This makes
autokgtest to a very valuable tool, but it shouldn't become a
maintainer's nightmare. And if I would have to maintain test-specific
severities, that would be a nightmare, not only for me but also for
upstream, who would need to be involved as the knowledgable instance
here.

Best regards

Ole

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Lars Wirzenius]

On Mon, Jan 16, 2017 at 08:50:57AM +0100, Ole Streicher wrote:
> Sean Whitton  writes:
> > I agree with the principle that test failures should be RC by default.
> 
> This is something which seems to have no disagreement here. My concern
> is just that I want to have a simple way to override this, to assign
> this to a different package etc. I want to have the same flexibility
> here as for bugs.

A failing test means there's a bug. It might be in the test itself, or
in the code being tested. It might be a bug in the test environment.

Personally, I'd really rather have unreliable tests fixed. Unreliable
tests are like playing Russian roulette: mostly OK but sometimes you
get a really loud noise that makes your parents and loved ones be
ashamed of you.

Picture this: a cocktail party. Many people mingling around, dressed
up and engaging in smalltalk, sipping colourful drinks. A new couple
arrives and is immediately surrounded by old fiends. "Hi, Jack and
Joan, how are you? How is that lovely offspring of yours?" The couple
look down, and their faces get a careful, blank expression. "It's not
good. We don't know what we did wrong. We're so ashamed. We don't know
how such a thing could happen. We thought we were such good parents."
A shocked silence fall on the group, in the middle of the hubbub of
the greater party. "You see, our child, our child..." Jack sobs and
can't get the words out, so Joan takes a deep breath and speaks. "Our
child wrote a test that fails randomly, and released it." One by one
their friends leave the group, quietly, and without speaking a single
harsh syllable. But for months, they had to wait for an invitation to
a new party.

Apart from social exclusion, unreliable tests waste a lot of time,
effort, and mental energy. When a test fails, you have to find out
why. What caused the fail? Is it because the test it bad, or because
the code it tests is broken? If you let a test fail randomly, you have
to debug that test many times. It also kills confidence in the test
suite: if all tests pass, is that too also just a random fluke? Can
you actually make a release, or should you do some tedious manual
testing just to make sure flaky test success didn't cover up a bug
somewhere?

Until an unreliable test is fixed, in my opinion it'd be better if the
test suite didn't fail because of it. Run the test by all means, to
gather more information for debugging, but don't fail the whole test
suite.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#851542: ITP: jenkins-job-builder-pipelin -- pipeline job generation plugin for jenkins-job-builder

[李健秋]

Package: wnpp
Followup-For: Bug #851542
Owner: "Andrew Lee (李健秋)" 

Thanks for catching this typo. :)

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Simon McVittie]

On Mon, 16 Jan 2017 at 10:38:42 +0200, Lars Wirzenius wrote:
> A failing test means there's a bug. It might be in the test itself, or
> in the code being tested. It might be a bug in the test environment.

Nobody is disputing this, but we have bug severities for a reason:
not every bug is release-critical. If we gated packages on "has no
known bugs" we'd never release anything.

> Personally, I'd really rather have unreliable tests fixed.

Of course, but it isn't always feasible to drop everything and fix an
unreliable test, or the bug that the test illustrates - the cause of an
intermittent bug is often hard to determine. Until that can happen, I'd
rather have the test sometimes or always fail, ideally reported as
XFAIL or TODO or something (distinguishing it from "significant"
failures), so I can use the information that it produces.

For example, several of the ostree tests intermittently failed for a
long time, which turned out to be (we think) a libsoup thread-safety
bug. If I had disabled those tests on ci.debian.net altogether, then
I wouldn't have been able to tell upstream "those tests have stopped
failing since fixing libsoup, so that fix is probably all we need".

> Apart from social exclusion, unreliable tests waste a lot of time,
> effort, and mental energy.

Yes, and in an ideal world they wouldn't exist. This world is demonstrably
not ideal, and the code we release is not perfect (if it was, we wouldn't
need tests). Would you prefer it if packages whose tests are not fully
reliable just stopped running them altogether, or even deleted them?

I would very much prefer that we run tests, even the imperfect ones,
because CPU time is cheap and more information is better than less
information.

I've opened:

autopkgtest: define Restrictions for tests that aren't suitable for gating CI
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851556

and sent a patch to:

autopkgtest: should be possible to ignore test restrictions by request
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850494

in the hope that we can use those as a way to mark certain tests as
"failure is non-critical".

S

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Ole Streicher]

Hi Lars,

Lars Wirzenius  writes:
> On Mon, Jan 16, 2017 at 08:50:57AM +0100, Ole Streicher wrote:
>> Sean Whitton  writes:
>> > I agree with the principle that test failures should be RC by default.
>> 
>> This is something which seems to have no disagreement here. My concern
>> is just that I want to have a simple way to override this, to assign
>> this to a different package etc. I want to have the same flexibility
>> here as for bugs.
>
> A failing test means there's a bug. It might be in the test itself, or
> in the code being tested. It might be a bug in the test environment.
>
> Personally, I'd really rather have unreliable tests fixed. Unreliable
> tests are like playing Russian roulette: mostly OK but sometimes you
> get a really loud noise that makes your parents and loved ones be
> ashamed of you.

I fully agree with you. I just think that it is not necessarily RC that
a CI test is unfixed.

The point here is: the proposed plan is to make CI test failures in
reverse dependencies a direct migration excuse, which can only be
overwritten by the release team.

I find this too unflexible, and propose that instead the failing CI test
should create an RC bug assigned to the updated package, affecting the
failing package. This would 

* document the bug on the place where all bugs are documented, and keep
  it in our eternal bug database, allowing to search for it etc.

* enable all the possibilities an open bug has, like discussion,
  re-assignment, severity change etc.

* better link the d/changelog entry to the problem ("Increasing
  tolerance in picky test. Closes: #123456" instead of "... to fix a CI
  test failure with updated grampf package")

> Picture this: a cocktail party. Many people mingling around, dressed
> up and engaging in smalltalk, sipping colourful drinks.

Nice picture :-)

> But for months, they had to wait for an invitation to a new party.

At least, I would not like to go to a coctail party where the host
announces that he kicks out the people for that reason. This should be
on the decision of the parents äääh maintainers.

IMO, we should trust the maintainer and their decisions until there is
no experience that it doesn't work. Which means: keep the maintainer
fully responsible on the package, including the ability to lower
severity of a CI test or any other bug. Only if we experience that this
doesn't work, we need other measures.

Best regards

Ole

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Santiago Vila]

On Mon, Jan 16, 2017 at 10:38:42AM +0200, Lars Wirzenius wrote:

> Picture this: a cocktail party. Many people mingling around, dressed
> up and engaging in smalltalk, sipping colourful drinks. A new couple
> arrives and is immediately surrounded by old fiends. "Hi, Jack and
> Joan, how are you? How is that lovely offspring of yours?" The couple
> look down, and their faces get a careful, blank expression. "It's not
> good. We don't know what we did wrong. We're so ashamed. We don't know
> how such a thing could happen. We thought we were such good parents."
> A shocked silence fall on the group, in the middle of the hubbub of
> the greater party. "You see, our child, our child..." Jack sobs and
> can't get the words out, so Joan takes a deep breath and speaks. "Our
> child wrote a test that fails randomly, and released it." One by one
> their friends leave the group, quietly, and without speaking a single
> harsh syllable. But for months, they had to wait for an invitation to
> a new party.

LOL, but I don't see a lot of social exclusion here:

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

Sometimes I've seen maintainers downgrade FTBFS bugs to "wishlist"!

Surely I will not invite those maintainers to a party, but they are
still maintaining Debian packages.

Should I ask the Technical Committee to rule out that FTBFS bugs are RC,
even if they did not happen in buildd.debian.org yet?

Thanks.

Re: Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping

[Andreas Tille]

On Sun, Jan 15, 2017 at 05:46:54PM +, Scott Kitterman wrote:
> >> As long as a package search for freebayes returns this in the result
> >set, I don't think it's critical to have the package name match exactly
> >the upstream name.
> >
> >Do you care only about the *package* name or do you care as well about
> >the name binary /usr/bin/freebayes?
> 
> I think they are both important.

Agreed - but users scripts will contain the freebayes name and changing
the binary name has some effect on user experience while the package name
could be simply changed.

Kind regards

  Andreas. 

-- 
http://fam-tille.de

Re: Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping

[Andreas Tille]

On Sun, Jan 15, 2017 at 09:19:37PM -0600, Gunnar Wolf wrote:
> 
> I think the package name should indicate the field for which it is
> meant (freebayes-genetic-variance),

At least its good to know that ftpmaster is reading here to not accept
previously uploaded package wis unchanged name. ;-)

I'm fine with changing that one and will ask on Debian Med name whether
above suggestion sounds good.

> but I don't think the program name
> should deviate from upstream; we have had issues such as when node.js
> was introduced (that 'node' was a name already taken by another
> program), but I don't think 'freebayes' will be such a contentious
> program name.

As I wrote in my other mail I'd expect issues on user side when the
usual and expected name would be changed.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#851562: ITP: r-cran-triebeard -- GNU R radix trees in Rcpp

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-triebeard
  Version : 0.3.0
  Upstream Author : Oliver Keyes 
* URL : https://cran.r-project.org/package=triebeard
* License : MIT
  Programming Lang: GNU R
  Description : GNU R radix trees in Rcpp
 'Radix trees', or 'tries', are key-value data structures optimised for
 efficient lookups, similar in purpose to hash tables. 'triebeard'
 provides an implementation of 'radix trees' for use in R programming and
 in developing packages with 'Rcpp'.


Remark: This package is needed to package r-cran-crul (no misspelling, its
not curl) which in turn is needed to update the r-cran-rredlist package to
the latest upstream version.  It will be maintained by the Debian Med team
at
   svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-triebeard/

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Santiago Vila]

On Mon, Jan 16, 2017 at 10:24:59AM +0100, Ole Streicher wrote:

> IMO, we should trust the maintainer and their decisions until there is
> no experience that it doesn't work. Which means: keep the maintainer
> fully responsible on the package, including the ability to lower
> severity of a CI test or any other bug. Only if we experience that this
> doesn't work, we need other measures.

Well, it does not work:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843038#10
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841098#78

Thanks.

Bug#851563: ITP: r-cran-httpcode -- GNU R HTTP Status Code Helper

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-httpcode
  Version : 0.2.0
  Upstream Author : Scott Chamberlain 
* URL : https://cran.r-project.org/package=httpcode
* License : MIT
  Programming Lang: GNU R
  Description : GNU R HTTP Status Code Helper
 Find and explain the meaning of 'HTTP' status codes.
 Functions included for searching for codes by full or partial number,
 by message, and get appropriate dog and cat images for many
 status codes.


Remark: This package is a precondition to package r-cran-crul (no
misspelling its different than curl) which in turn will be needed to
upgrade r-cran-rredlist to its latest upstream version.  It will be
maintained by the Debian Med team at
   svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-httpcode/

Bug#851567: ITP: r-cran-crul -- simple HTTP Client for GNU R

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-crul
  Version : 0.2.0
  Upstream Author : Scott Chamberlain 
* URL : https://cran.r-project.org/package=crul
* License : MIT
  Programming Lang: GNU R
  Description : simple HTTP Client for GNU R
 A simple HTTP client, with tools for making HTTP requests,
 and mocking HTTP requests. The package is built on R6, and takes
 inspiration from Ruby's 'faraday' gem ().
 The package name is a play on curl, the widely used command line tool
 for HTTP, and this package is built on top of the R package 'curl', an
 interface to 'libcurl' ().


Remark: This package is needed to upgrade r-cran-rredlist to its latest
upstream version.  It will be maintained by the Debian Med team at
svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-crul/

Bug#851565: ITP: r-cran-urltools -- GNU R vectorised tools for URL handling and parsing

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-urltools
  Version : 1.6.0
  Upstream Author : Oliver Keyes 
* URL : https://cran.r-project.org/package=urltools
* License : MIT
  Programming Lang: GNU R
  Description : GNU R vectorised tools for URL handling and parsing
 A toolkit for all URL-handling needs, including encoding and decoding,
 parsing, parameter extraction and modification. All functions are
 designed to be both fast and entirely vectorised. It is intended to be
 useful for people dealing with web-related datasets, such as server-side
 logs, although may be useful for other situations involving large sets of
 URLs.


emark: This package is needed to package r-cran-crul (no misspelling, its
not curl) which in turn is needed to update the r-cran-rredlist package to
the latest upstream version.  It will be maintained by the Debian Med team
at
   svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-urltools/

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Jonas Smedegaard]

Quoting Santiago Vila (2017-01-16 11:07:11)
> Sometimes I've seen maintainers downgrade FTBFS bugs to "wishlist"!
> 
> Surely I will not invite those maintainers to a party, but they are
> still maintaining Debian packages.
> 
> Should I ask the Technical Committee to rule out that FTBFS bugs are RC,
> even if they did not happen in buildd.debian.org yet?

Yes, please do!

I believe, however, that Ole was talking about non-critical bugs being 
part of a testsuite - not criticial bugs wrongly downgraded.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Ole Streicher]

Santiago Vila  writes:
> On Mon, Jan 16, 2017 at 10:24:59AM +0100, Ole Streicher wrote:
>
>> IMO, we should trust the maintainer and their decisions until there is
>> no experience that it doesn't work. Which means: keep the maintainer
>> fully responsible on the package, including the ability to lower
>> severity of a CI test or any other bug. Only if we experience that this
>> doesn't work, we need other measures.
>
> Well, it does not work:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843038#10
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841098#78

This comes out of different interpretations of whether builds that
sometimes fail (but often not) are RC buggy. You know that also I have a
different opinion here.

So, if you really want to have your interpretation to be the commonly
accepted one, you should discuss it here and see whether you reach a
common acceptance with your interpretation.

Otherwise it is IMO OK if a package maintainer has her own idea of
whether an occaisonal build failure is RC.

Best regards

Ole

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Martin Pitt]

Hello all,

(I'm not subscribed, thus hand-crafting In-Reply-To:; please keep CC'ing me on
replies).

Ole Streicher [Fri, 13 Jan 2017 15:57:09 +0100]
> Will there be a way to override this for the maintainer? Otherwise I
> would see the danger that a buggy reverse dependency CI test can prevent
> an important update, for example if the reverse dependency uses a long
> deprecated function that is now removed.

If you upload a new version of a library that removes a symbol, then all
reverse dependences must get fixed in or removed from testing anyway. In this
scenario the new lib would already not propagate as the rdepends would FTBFS in
the binNMU against the new library SONAME (assuming that you did bump it).
OTOH, if you did not bump the SONAME, then this is an RC bug anyway which then
gets caught by the test.

For other scenarios which aren't already caught by britney's installability
checks (change in behaviour which doesn't reflect in changed ABI) we actually
do want the same: If we can catch a regression through a test, then it makes
zero sense to automatically land that regression in testing anyway -- the whole
point of this exercise is to allow us to land transitions with confidence and
sort out transitions in unstable *before* landing regressions in testing.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Martin Pitt]

Hello all,

Scott Kitterman [Fri, 13 Jan 2017 13:54:26 -0500]
> Probably the simplest way to avoid problems with systems like this is to 
> remove any autopkg tests your packages are shipping.
> 
> P.S. Perverse incentives FTW.

No, that won't work at all. If you upload libfoo which regresses a reverse
dependency bar and bar's tests now fail, then removing libfoo's autopkgtests
won't help you *at all* in landing the new libfoo in testing. You'd need to
convince bar's maintainer to change/drop the test.

The carrot for adding tests is that the better they are, the harder you make it
for *other people* (i. e. your dependencies) to break your software. The stick
is that you then of course need to make/keep your own tests running so that you
can upload new versions of libfoo yourself.

So IMHO the incentives are quite right here.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Adam Borowski]

On Mon, Jan 16, 2017 at 11:07:11AM +0100, Santiago Vila wrote:
> LOL, but I don't see a lot of social exclusion here:
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=sanv...@debian.org;tag=ftbfs-randomly
> 
> Sometimes I've seen maintainers downgrade FTBFS bugs to "wishlist"!
> 
> Surely I will not invite those maintainers to a party, but they are
> still maintaining Debian packages.
> 
> Should I ask the Technical Committee to rule out that FTBFS bugs are RC,
> even if they did not happen in buildd.debian.org yet?

I'd say that all FTBFS bugs should be RC -- the maintainer requested (even
if unintentionally) test failures to be fatal.  If that's not your intent,
write ||: after "make check".

-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Re: installing kernel debug symbols on stretch?

[Sebastian Andrzej Siewior]

On 2017-01-14 11:06:51 [+0100], Daniel Pocock wrote:
…
> deb http://debug.mirrors.debian.org/debian-debug/ stretch-debug main
> non-free contrib

not that this changes anything, but I assumed that
deb http://deb.debian.org/debian-debug stretch-debug main
was the way to use for stretch+. But this does not change a thing…

> # apt-get install -t stretch-debug linux-image-amd64-dbgsym
…
> The following packages have unmet dependencies:
>  linux-image-amd64-dbgsym : Depends: linux-image-4.8.0-2-amd64-dbgsym
> but it is not installable
> E: Unable to correct problems, you have held broken packages.

…

> so would the dbgsym package still be in Incoming?

No, it is still there:

http://deb.debian.org/debian-debug/pool/main/l/linux/linux-image-4.8.0-2-amd64-dbgsym_4.8.15-2_amd64.deb
it is just not listed in the Packages file where it should be.

I *think* the archive got confused by the various kernel package. So we
have linux-image-4.8.0-2-amd64-dbgsym which comes out of src:linux and
binary:linux-image-4.8.0-2-amd64-unsigned. Then we have the binary
package linux-image-4.8.0-2-amd64 which comes out of src:linux-signed
and has no dbgsym package but the one provided by
linux-image-4.8.0-2-amd64-unsigned is just fine. I would assume that if
nothing changes, we will miss the dbgsym package in testing for 4.9 in
approx 8 days. 
There is not such a problem for mips64el where we don't have
linux-signed and so linux-image-4.8.0-2-octeon-dbgsym is listed in
testing.
Could someone from ftp please confirm this?

> Regards,
> 
> Daniel

Sebastian

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Santiago Vila]

On Mon, Jan 16, 2017 at 12:17:48PM +0100, Ole Streicher wrote:
> Santiago Vila  writes:
> > On Mon, Jan 16, 2017 at 10:24:59AM +0100, Ole Streicher wrote:
> >
> >> IMO, we should trust the maintainer and their decisions until there is
> >> no experience that it doesn't work. Which means: keep the maintainer
> >> fully responsible on the package, including the ability to lower
> >> severity of a CI test or any other bug. Only if we experience that this
> >> doesn't work, we need other measures.
> >
> > Well, it does not work:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843038#10
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841098#78
> 
> This comes out of different interpretations of whether builds that
> sometimes fail (but often not) are RC buggy. You know that also I have a
> different opinion here.
> 
> So, if you really want to have your interpretation to be the commonly
> accepted one, you should discuss it here and see whether you reach a
> common acceptance with your interpretation.

I think it should be the other way around, because Release Policy
already says "Packages must autobuild from source" and it does
not say anything about failure thresholds.

In fact, I've seen maintainers downgrading FTBFS bugs that happen more
than 50% of the time.

With the lax interpretation, we could have policy reversed, as in
"packages must not build from source", and the package
would still be policy compliant!

Schrödinger paradox! Packages are simultaneosly compliant with Release
Policy and with the reverse of Relese Policy!

This is why I can't trust (all) maintainers to do the right thing
regarding random FTBFS failures.

So, if you people are considering to put a piuparts-like blocking to
testing migration, please consider what will happen when the failure
happens randomly.

BTW: Your idea of an automatic RC bug would be a good start indeed,
and it's probably the least we should do.

Thanks.

Bug#851574: ITP: clickhouse -- ClickHouse is an open-source column-oriented database management system

[Jean Baptiste Favre]

Package: wnpp
Severity: wishlist
Owner: Jean Baptiste Favre 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: clickhouse
  Version : 1.1.54133
  Upstream Author : Alexey Milovidov
* URL : https://clickhouse.yandex/
* License : Apache
  Programming Lang: C++
  Description : open-source column-oriented database management system

Yandex ClickHouse is an open-source column-oriented database management system
that allows generating analytical data reports in real time.

I use this package at work and am already packaging it internaly.
As far as I know, there're no free/open-source column-oriented DBMS in Debian
for now, and given the importance of data anlytics theses days, I think
this would be a great idea to have such software in the archive.

I'll need a sponsor as soon as the packaging work is finished which is, for
now, far to be true.

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEToRbojDLTUSJBphHtN1Tas99hzcFAlh8xk9fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDRF
ODQ1QkEyMzBDQjRENDQ4OTA2OTg0N0I0REQ1MzZBQ0Y3RDg3MzcACgkQtN1Tas99
hze1aw/9H+ErVF0vGJTQvG9/s3fxuL0C9sYMzMvOg4IswKMu4u1cNLo5gFnlkGRT
PBaFBSCWah+UsDWUUf+fYPgn2BYP4JawDw74dH+Gl02yU4b8KWJtkRAA5noY3vOT
Tz5XPMI/s0LjwlBWWyLp4I4IKAt4oM/wyiMLI0UTV0q3ocLmnOy0p1/XVRVDTOoB
1xHgFBqBPzpM5M+Nfjo+Pjg+Az/J6Xki1Hjw//ZGbVHGJVcizm09Fhhzt0nZwkGt
g5lCWhdhDfkAib9lK3/Sm/CpS7u6QOpprNbeXtixeOff36aVWZydDwdY80ze6fSF
uApI5wdhAlE1t7n23cAcUbLUrFNLB0I2QisDVNiG2g31TF+k7Yr/xoBTgme5spmH
M9gw9o2KLJx2e9t0zvxHSsw+fbxoDz+EvWcC/A9JIMFUTQe+tpEKK+ez1WSELQcr
7Ee1764nyyaOyNxpGEEl6+CD9XN9r0uytu/NsPTGvIjU+3TxizZduaM8Xu2fUiaS
a9Qd+g6BHjHNgw3ilUElqnMs+QEsrME0AQpeknDoAFpphDljDeGVg46lybdoGqo/
jejQRIJrDPIWNBQsUPaq9TSkQsNdj55/qc+u3YGsf4M5jYzp0vJHIYf8tPkjERf1
TKYjhIC9DT+R+XKuwJWKOddg59SQSqIeir6oG9N+FIti/Rwi8OQ=
=6WSv
-END PGP SIGNATURE-

Re: Trademark issues (Was: kronatools_2.7+dfsg-1_amd64.changes REJECTED)

[Ian Jackson]

Andreas Tille writes ("Re: Trademark issues (Was: 
kronatools_2.7+dfsg-1_amd64.changes REJECTED)"):
> I admit I feel a bit blocked.  Should I simply upload with another
> possibly improperly choosen name and wait for ftpmaster comments to the
> upload in new?  It seems this topic does not deserve any additional
> input and thus I might take this potential detour without further
> discussion. :-(

Earlier you wrote this:

> On Fri, Dec 16, 2016 at 09:21:06PM +0100, Andreas Tille wrote:
> > I think radiant-graphs might come closer even if I doubt that there is
> > much confusion between the CMS and this tool and if its not packaged
> > there should be no clash.
> >  
> > I'd like to hear a word from ftpmaster if I rename the source and binary
> > package as well as the Git archive - would this be accepted for the next
> > upload.  Some kind of confirmation in advance would be helpful to do
> > more negotions right now and not after another round in the new queue.

Debian is supposedly a do-ocracy.  You have consulted.  In the absence
of objections you should carry on.

IMO you should upload with the name `radiant-graphs'.  If that is
rejected by ftpmaster you should involve the DPL and/or the TC.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Ian Jackson]

Steve Langasek writes ("Re: Auto reject if autopkgtest of reverse dependencies 
fail or cause FTBFS"):
> If the failure of the test is not critical, then it should not be used as a
> gate for CI.  Which means you, as the package maintainer who knows that this
> test failure is not critical, should fix your autopkgtest to not fail when
> the non-critical test case fails.

You seem to be suggesting that in the case of
 * tests which expose non-RC bugs in the main code or its dependencies
 * broken tests, but not the most important test cases
the test should be suppressed: ie, that it should not be run (or, it
should be nobbled to exit "successfully" despite actually failing).

I disagree.  Information from such tests is useful and should be
properly recorded and handled.

I also disagree with the proposition that the information, that test X
in package Y is caused by a non-RC bug and should not impede
migration, should be recorded inside the source package Y.

We need to be able to adjust the blockness of tests without uploading
new versions of packages.  It should be in the bug system.

> Quite to the contrary of the claims in this thread that gating on
> autopkgtests will create a bottleneck in the release team for overriding
> test failures, this will have the effect of holding maintainers accountable
> for the state of their autopkgtest results.  CI tests are only useful if you
> have a known good baseline.  If your tests are flaky, or otherwise produce
> failures that you think don't matter, then those test results are not useful
> than anyone but yourself.  Please help us make the autopkgtests useful for
> the whole project.

CI tests are useful for purposes other than controlling testing
migration.

> The result of the autopkgtest should be whatever you as the maintainer think
> is the appropriate level for gating.  Frankly, I think it's sophistry to
> argue both that you care about seeing the results of the tests, and that you
> don't want a failure of those tests to gate because they only apply to
> "special cases".

This is IMO a silly argument.  We always release Debian with bugs.

CI failures that represent non-RC bugs are useful information.  Such
failures should be brought to the attention of a human so that the
human can decide whether te failure is RC (or take other appropriate
action).

You are getting dangerously close to the notion that in a
well-functioning organisation the test suite will nearly always
completely pass.

> Why would you mark them non-blocking /before/ you know that the tests are
> flaky enough for this to matter?  Upstream put them in the test suite for a
> reason.  I'd suggest that it's much better to block by default, and if you
> find that a particular test is becoming a problem (for you or for another
> maintainer), you can upload to make that test non-blocking.

I don't think anyone is arguing the reverse.

The question is whether marking a test non-blocking should involve the
release team.  I think it should not.  It should involve the package
maintainer (unless there is disagreement).

We want to incentivise people to provide tests.  If they cannot
control what action is taken (by automation) in response to the tests,
they will remove or disable (or not provide) tests.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Ian Jackson]

Santiago Vila writes ("Re: Auto reject if autopkgtest of reverse dependencies 
fail or cause FTBFS"):
> Well, it does not work:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843038#10
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841098#78

I agree that there are sometimes problems with people wanting to
"defend" their packages by unjustifiably downgrading bugs.

Better testing amounts to better discovery of bugs.  Better automatic
handling of test results does indeed depend on getting the human
judgements right.

I don't think Paul's proposal going to help solve this, but that just
means that Paul's proposal does not solve all problems.

The alternatives: eg, preventing maintainers from overriding test
failures, is worse: the tests will simply be removed.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Ian Jackson]

Lars Wirzenius writes ("Re: Auto reject if autopkgtest of reverse dependencies 
fail or cause FTBFS"):
> Until an unreliable test is fixed, in my opinion it'd be better if the
> test suite didn't fail because of it. Run the test by all means, to
> gather more information for debugging, but don't fail the whole test
> suite.

autopkgtest can report individual test failures without "failing the
whole test suite".

There is new functionality needed to be able to do this in cases where
there are many test results run by one upstream script.

An override mechanism ought to operate on individual autopkgtest
tests, at least by default.  (Maybe it ought to operate on glob
patterns.)

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Ian Jackson]

Ole Streicher writes ("Re: Auto reject if autopkgtest of reverse dependencies 
fail or cause FTBFS"):
> Ian Jackson  writes:
> >  * It eliminates a timing problem, where the testing migration
> >infrastructure[1] needs to somehow decide whether the test have
>^^^ reference/footnote not found
> >been run.  (This is needed because in the future we may want to
> >accelerate migration, perhaps dramatically when there are lots of
> >tests; and then, the testing queue may be longer than the minimum
> >migration delay.)
> 
> I would not see this a big problem: the bug can also be filed against a
> migrated package.

That should not be the default.  I think you have missed my point.  If
the migration delay for a particular upload is less than the waiting
time to get the tests run, then somehow we will need to delay the
migration on the grounds that the tests have not been run.

Obviously this could be done but it involves a new data exchange (and
new protocol) between the testing migration decision tools[1] and the
CI system, which are supposed to be arms-length.

There are other intertwinings: typically batches of packages need to
be tested together, and it's the testing migration system that knows
which packages to test.

So it would be simpler to do the CI as part of the testing migration.

Ultimately this is a decision for Paul I think.

[1] is the same missing footnote as before, which was:
 [1] The name "britney" is IMO not cool.  I wish it would be renamed.

> Just copying from your other mail:
> > The difficulty with automated bug reports is this: how do you tell
> > whether something is the same bug or not ?
> >
> > If you're not careful, a test which fails 50% of the time will result
> > in an endless stream of new bugs from the CI system which then get
> > auto-closed...
> 
> Just allow only one bug report per version pair, report only changes,
> and don't report is another bug for the package pair is still
> open. Either have a local database with the required information, of
> store this as metadata in the bug reports. and query the BTS before
> sending.
> 
> Basically the same procedure as one would do manually.

No, it isn't.  What you propose produces one bug report per uploaded
version of each dependency.  What one would do manually is have one
report that describes the scope of the problem.

Also a manual bug report can have a better introduction.

> > You should help enhance autopkgtest so that a single test script can
> > report results of multiple test.  This will involve some new protocol
> > for those test scripts.
> 
> Sorry, but I can't evaluate all 9000 tests and categorize them which are
> RC and which are not -- this will not work. It is also not realistic to
> force upstream to do so. The only thing I can do is reactively tag a
> certain failure being RC or not.

You have misunderstood my proposal, I think.

I am suggesting that you should arrange that your 9000 tests each
show up as one test case as far as autopkgtest is concerned.  That can
probably be done wholesale: these kind of systems already produce
systematic (or nearly-systematic) output.  So you don't need to
categorise them up-front.

Then when you get a test failure you would look at (only) the failing
tests, and perhaps file a bug

 To: sub...@bugs.debian.org
 Subject: gnomovision monochrome gnomes are pink and blue

 Package: gnomovision
 Version: 1.2-3
 Severity: minor
 Control: user ci.debian.net
 Control: usertags -1 + nonblock-G32-PINK nonblock-G33-BLUE

 The gnomes in these tests should be black and white.  This is caught
 by the autopkgtests which check the colour configuration.

 The bug is cosmetic - even on a monochrome display, you can tell the
 gnomes apart.

Doing things this way also means that you fix the bug in the changelog
in the usual way.  If you're wrong, the CI will nag you until you
reopen the bug.

FWIW: in my day job I maintain osstest, the Xen Project's CI system,
so I have a lot of experience of how CI blocking workflows should be
managed.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Scott Kitterman]

On Monday, January 16, 2017 01:06:19 PM Martin Pitt wrote:
> Hello all,
> 
> Scott Kitterman [Fri, 13 Jan 2017 13:54:26 -0500]
> 
> > Probably the simplest way to avoid problems with systems like this is to
> > remove any autopkg tests your packages are shipping.
> > 
> > P.S. Perverse incentives FTW.
> 
> No, that won't work at all. If you upload libfoo which regresses a reverse
> dependency bar and bar's tests now fail, then removing libfoo's autopkgtests
> won't help you *at all* in landing the new libfoo in testing. You'd need to
> convince bar's maintainer to change/drop the test.
> 
> The carrot for adding tests is that the better they are, the harder you make
> it for *other people* (i. e. your dependencies) to break your software. The
> stick is that you then of course need to make/keep your own tests running
> so that you can upload new versions of libfoo yourself.
> 
> So IMHO the incentives are quite right here.

Of course if we just never allow anything into Testing, there's no risk of bad 
software migrating.

This is going to take a lot of work.  I see random failures routinely block 
migrations in Ubuntu (postfix is a current example - there's two alleged 
regressions that to the extent they are valid are completely unrelated to 
anything that changed in the package).  

The question is who's going to do the work?  I don't see the release team 
having tons of spare cycles to dive into the details of individual test 
results and package failures and decide what's RC and what's not.  The only 
thing that scales to something the size of the Debian archive is to let the 
maintainers decide.

Yes, some of them will abuse that authority, but that's true of anything.

Scott K

Re: Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping

[Andreas Tille]

On Mon, Jan 16, 2017 at 11:44:45AM +0100, Andreas Tille wrote:
> > I think the package name should indicate the field for which it is
> > meant (freebayes-genetic-variance),
> 
> At least its good to know that ftpmaster is reading here to not accept
> previously uploaded package wis unchanged name. ;-)
> 
> I'm fine with changing that one and will ask on Debian Med name whether
> above suggestion sounds good.

When discussing the issue with a Debian Med sprint member I've got other
good reasons to even keep the package name despite the fact that its
quite generic.  When looking outside the Debian box other distributions
might package the same software at best under the original name since
they are not that picky about generic names and at worst under different
names which would add more confusion than a less generic name might
avoid.

Furthermore there is some effort called bio.tools[1] (members of this
effort regularly joining Debian Med sprints) who are very keen on all
the metadata that are assembled with Debian packages and can be easily
fetched from UDD.  They consider taking the Debian Source package name
as a key in their database.  While I'm personally not convinced that
this is the best idea we probably should not artificially diverge from
names that would be expceted by potential consumers of our data.

Finally when doing a websearch for freebayes the said project is the
first hit which might be a further arguent to stick to the name that was
choosen by upstream.

Kind regards

Andreas.


[1] https://bio.tools/

-- 
http://fam-tille.de

Re: Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping

[Scott Kitterman]

On Monday, January 16, 2017 05:37:45 PM Andreas Tille wrote:
> On Mon, Jan 16, 2017 at 11:44:45AM +0100, Andreas Tille wrote:
> > > I think the package name should indicate the field for which it is
> > > meant (freebayes-genetic-variance),
> > 
> > At least its good to know that ftpmaster is reading here to not accept
> > previously uploaded package wis unchanged name. ;-)
> > 
> > I'm fine with changing that one and will ask on Debian Med name whether
> > above suggestion sounds good.
> 
> When discussing the issue with a Debian Med sprint member I've got other
> good reasons to even keep the package name despite the fact that its
> quite generic.  When looking outside the Debian box other distributions
> might package the same software at best under the original name since
> they are not that picky about generic names and at worst under different
> names which would add more confusion than a less generic name might
> avoid.
> 
> Furthermore there is some effort called bio.tools[1] (members of this
> effort regularly joining Debian Med sprints) who are very keen on all
> the metadata that are assembled with Debian packages and can be easily
> fetched from UDD.  They consider taking the Debian Source package name
> as a key in their database.  While I'm personally not convinced that
> this is the best idea we probably should not artificially diverge from
> names that would be expceted by potential consumers of our data.
> 
> Finally when doing a websearch for freebayes the said project is the
> first hit which might be a further arguent to stick to the name that was
> choosen by upstream.

OK.  Would you at least discuss it with upstream?

Scott K

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Barry Warsaw]

On Jan 16, 2017, at 10:52 AM, Scott Kitterman wrote:

>This is going to take a lot of work.  I see random failures routinely block
>migrations in Ubuntu (postfix is a current example - there's two alleged
>regressions that to the extent they are valid are completely unrelated to
>anything that changed in the package).
>
>The question is who's going to do the work?  I don't see the release team
>having tons of spare cycles to dive into the details of individual test
>results and package failures and decide what's RC and what's not.  The only
>thing that scales to something the size of the Debian archive is to let the
>maintainers decide.

Speaking only about our experiences in Ubuntu, I can anecdotally but
emphatically claim that gating promotions on passing autopkgtests has
dramatically improved the quality of the running end user systems.

It used to be that you had to be very careful about running and especially
dist-upgrading the current devel series.  You never knew if something major
like the kernel or X would break, or even when minor breakages would be highly
inconvenient.  It just wasn't safe without a lot of precaution.

But now I don't hesitate to run devel almost as soon as the new series opens.
That's not to say that serious breakage never happens; not everything is
tested of course, and stuff happens.  But it's rare, maybe once or twice a
cycle for boot-to-desktop to break, or a package regression sneaks through.  I
just have way way more confidence in the distro now that these tests block
promotion.

Yes, it can be more work at times, and it's not always easy to diagnose or
reproduce promotion problems.  (I'm currently flummoxed by a systemd
regression triggered by a network-manager fix.)  But I'd much rather have the
luxury of debugging these problems on a still-functioning system and without
also-frustrated users hammering me on IRC, with deadlines looming.

I think it does mean that maintainers will have to step up and take more
responsibility for nursing their packages through to promotion, but I also
think they are in a much better position to do so than J Random User who runs
an upgrade only to be left with a broken system or application.

One other point.  I don't know how many folks run unstable (or in Ubuntu's
case, devel), but for most software I work on, few users really test
pre-release versions.  As much as you plead with them, "hey, beta 3 is out,
please test!" they just won't for totally understandable reasons.  So problems
arise *after* the final release because that's when people start to really
hammer on it, and integrate it with their own software, environments, and
workflows.  That means day-to-day user testing just can't be all that reliable
because there are so few data points, and it's another reason why I think
automated testing/CI is so important.  (It's also an investment over time; you
don't have to have 100% coverage from day one, but every new test can improve
overall quality just a little bit.)  It's also why I feel it's important for
*me* to run unstable/devel.  True, it's my day job, but I also feel a
responsibility to help ensure the little corner of stuff I use, care about,
and know about is in as good a shape as possible before it gets into the hands
of our users.  I *want* to feel the pain before they do.

Cheers,
-Barry


pgpkRsW_JvKiI.pgp
Description: OpenPGP digital signature

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Scott Kitterman]

On Monday, January 16, 2017 12:09:02 PM Barry Warsaw wrote:
> On Jan 16, 2017, at 10:52 AM, Scott Kitterman wrote:
> >This is going to take a lot of work.  I see random failures routinely block
> >migrations in Ubuntu (postfix is a current example - there's two alleged
> >regressions that to the extent they are valid are completely unrelated to
> >anything that changed in the package).
> >
> >The question is who's going to do the work?  I don't see the release team
> >having tons of spare cycles to dive into the details of individual test
> >results and package failures and decide what's RC and what's not.  The only
> >thing that scales to something the size of the Debian archive is to let the
> >maintainers decide.
> 
> Speaking only about our experiences in Ubuntu, I can anecdotally but
> emphatically claim that gating promotions on passing autopkgtests has
> dramatically improved the quality of the running end user systems.
> 
> It used to be that you had to be very careful about running and especially
> dist-upgrading the current devel series.  You never knew if something major
> like the kernel or X would break, or even when minor breakages would be
> highly inconvenient.  It just wasn't safe without a lot of precaution.
> 
> But now I don't hesitate to run devel almost as soon as the new series
> opens. That's not to say that serious breakage never happens; not
> everything is tested of course, and stuff happens.  But it's rare, maybe
> once or twice a cycle for boot-to-desktop to break, or a package regression
> sneaks through.  I just have way way more confidence in the distro now that
> these tests block promotion.
> 
> Yes, it can be more work at times, and it's not always easy to diagnose or
> reproduce promotion problems.  (I'm currently flummoxed by a systemd
> regression triggered by a network-manager fix.)  But I'd much rather have
> the luxury of debugging these problems on a still-functioning system and
> without also-frustrated users hammering me on IRC, with deadlines looming.
> 
> I think it does mean that maintainers will have to step up and take more
> responsibility for nursing their packages through to promotion, but I also
> think they are in a much better position to do so than J Random User who
> runs an upgrade only to be left with a broken system or application.
> 
> One other point.  I don't know how many folks run unstable (or in Ubuntu's
> case, devel), but for most software I work on, few users really test
> pre-release versions.  As much as you plead with them, "hey, beta 3 is out,
> please test!" they just won't for totally understandable reasons.  So
> problems arise *after* the final release because that's when people start
> to really hammer on it, and integrate it with their own software,
> environments, and workflows.  That means day-to-day user testing just can't
> be all that reliable because there are so few data points, and it's another
> reason why I think automated testing/CI is so important.  (It's also an
> investment over time; you don't have to have 100% coverage from day one,
> but every new test can improve overall quality just a little bit.)  It's
> also why I feel it's important for *me* to run unstable/devel.  True, it's
> my day job, but I also feel a responsibility to help ensure the little
> corner of stuff I use, care about, and know about is in as good a shape as
> possible before it gets into the hands of our users.  I *want* to feel the
> pain before they do.

The before/after comparison for Debian and Ubuntu is apples and oranges.  
Before Ubuntu had the auto package test migration there we nothing other than 
installability blocking migration, it had (and still doesn't AFAIK) any notion 
of blocking due to RC bugs.

Back to my experience with postfix: I don't recall the auto package test 
catching anything.  When I upload it broken to unstable (and via autosync to 
the Ubuntu devel release) people notice pretty much right away.

I'm sure it's generally helped, but so far, I've found it mostly a nuisance.  
If Debian started enforcing auto package test pass for Testing migration, the 
first thing I'd do is remove the postfix tests (it's never worked on Debian as 
far as I've noticed, despite intermittently working on Ubuntu, and I've no 
idea why).  Postfix doesn't have rdepends, so at least for that package, I can 
side step the problem.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Niels Thykier]

Ian Jackson:
> Steve Langasek writes ("Re: Auto reject if autopkgtest of reverse 
> dependencies fail or cause FTBFS"):
>> [...]
> 
> The question is whether marking a test non-blocking should involve the
> release team.  I think it should not.  It should involve the package
> maintainer (unless there is disagreement).
> 
> We want to incentivise people to provide tests.  If they cannot
> control what action is taken (by automation) in response to the tests,
> they will remove or disable (or not provide) tests.
> 
> Ian.
> 

The autopkgtests gating testing migration comes with a promise from the
release teams side of reducing the age delay for migrations[1].  I.e.
packages with passing tests that do not cause regressions[2] in reverse
dependencies would be entitled to a shorter migration delay.

Personally, I think autopkgtests gating should eventually replace the
age delay in general.  Notably, I remember Bdale saying at DC13 that the
age delay is basically only really useful for finding brown-paper-bag
bugs[3] and I am inclined to agree with that.
  Mind you, it will probably be several releases before we are at a
stage where we are ready for completely eliminating age delays for
autopktests-enabled packages.

I would prefer setting it up as we decided 3-4 years ago in a
non-enforcing mode to see how it all works out.  Once we have ironed out
the early implementation bugs and have seen how it works in practise, we
can look at enabling the "blocking" feature of this proposal.

In summary:

 * We will introduce it in a non-enforcing mode to see how it works
   (and weed out any "early-implementation bugs")
 * Passing tests will be grounds for reduced age requirements (once it
   has been tested)
 * Only regressions will be blockers; if the tests also fail in testing
   the migration will not be stalled (but it will be subject to full
   age delay)

Thanks,
~Niels

[1] https://lists.debian.org/debian-devel-announce/2013/08/msg6.html

[2] The original mail says "failures" would be blockers but in practise,
Britney has always blocked on "regressions" rather than "failured like
it does in testing".

[3] It is in one of the video talks from DC13 - I /think/ it was the
release team talk/bits, where we were debating reducing the default age
requirement from 10 to 5 days.

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Niels Thykier]

Ole Streicher:
>>> >> What is the reason not to use automated bug reports here? This would
>>> >> allow to use all the tools the bug system has: severities, reassigning
>>> >> closing etc.
>> >
>> > [...]
> I already don't understand this with the piuparts blocker: we have an
> established workflow for problems with packages that need some
> intervention, and this is bugs.d.o. This has a lot of very nice
> features, like:
> 
>  * discussion of the problem attached to the problem itself and stored
>for reference
>  * formal documentation of problem solving in the changelog (Closes: #)
>  * severities, tags, re-assignments, affects etc.
>  * maintainer notifications, migration blocks, autoremovals etc.
>  * documented manual intervention possible
> 
> I don't see a feature that one would need for piuparts complaints or for
> CI test failures that is not in our bug system. And (I am not sure)
> aren't already package conflict bugs autogenerated?
> 
> I would really prefer to use the bug system instead of something else.
> 

There exists no "auto-bug-filing" tool that people approve of for this
kind of purpose.  You are very welcome to introduce such a tool - I
would be happy to see it for FTBFS regressions on buildds.
  In the absence of such a tool, existing and future QA checks for
gating will be implemented directly in Britney.  Mind you, even if such
a auto-bug-filing tool were created, there will always be control checks
in Britney that will only be overridable by the release team.

Personally, I do not have the capacity to create such a tool.  Instead,
I have been working on making Britney's migration policy decisions
available in a machine-parsable format (available from [1]).
  It is still WIP[2], but it does include piuparts, aging and RC bugs
blockers.  Plus it would also include autopkgtests information once we
add that.
  Ideally, I would finish that up and have it integrated into
tracker.d.o or/and UDD (related dep: DEP-2?).

Thanks,
~Niels

[1] https://release.debian.org/britney/excuses.yaml

[2] If you are considering to import this data set, please let me know.
We still tweak the format/values now and then, so it is better if I can
notify you in advance, rather than break your importer without knowing it.

Related note: Feedback from prospective importers welcome (please follow
up in a separate thread).

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Ian Jackson]

Niels Thykier writes ("Re: Auto reject if autopkgtest of reverse dependencies 
fail or cause FTBFS"):
> In summary:
> 
>  * We will introduce it in a non-enforcing mode to see how it works
>(and weed out any "early-implementation bugs")
>  * Passing tests will be grounds for reduced age requirements (once it
>has been tested)
>  * Only regressions will be blockers; if the tests also fail in testing
>the migration will not be stalled (but it will be subject to full
>age delay)

This would be good.

But I do think maintainer control, by way of filing bugs (RC or
otherwise) which they explicitly declare to be the cause of individual
test failures, would be a good addition.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Ian Jackson]

Scott Kitterman writes ("Re: Auto reject if autopkgtest of reverse dependencies 
fail or cause FTBFS"):
> I'm sure it's generally helped, but so far, I've found it mostly a
> nuisance.  If Debian started enforcing auto package test pass for
> Testing migration,

Right now the plan is to have _passing tests_ (well, regressionless
ones) _reduce_ the migration delay.  Failing tests would be the same
as no tests.

I do agree that there would be a temptation to remove troublesome
tests, rather than fix or debug them.  That's why I'm suggesting that
fairly soon the maintainer should get to override the tests, so that
the test is not considered a blocker.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Colin Watson]

On Mon, Jan 16, 2017 at 12:24:08PM -0500, Scott Kitterman wrote:
> The before/after comparison for Debian and Ubuntu is apples and oranges.  
> Before Ubuntu had the auto package test migration there we nothing other than 
> installability blocking migration, it had (and still doesn't AFAIK) any 
> notion 
> of blocking due to RC bugs.

That's not quite true: I added support for considering bugs with a
"block-proposed" tag in October 2013.  I agree that that's after
autopkgtest handling was added (June 2013), and that the block-proposed
tag is not as widely used as RC bugs.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#851603: ITP: ruby-rails-assets-underscore -- underscore.js for rails applications

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: ruby-rails-assets-underscore
  Version : 1.8.3
  Upstream Author : 2009-2015 Jeremy Ashkenas, DocumentCloud and
Investigative Reporters & Editors
* URL : https://github.com/jashkenas/underscore
* License : Expat
  Description : underscore.js for rails applications
   Underscore.js is a utility-belt library for JavaScript that provides
support for the usual functional suspects (each, map, reduce, filter...)
without extending any core JavaScript objects.
 .
 Rails Assets is the frictionless proxy between Bundler and Bower.
 .
 It automatically converts the packaged components into gems that are
easily droppable into your asset pipeline and stay up to date.




signature.asc
Description: OpenPGP digital signature

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Barry Warsaw]

On Jan 16, 2017, at 06:01 PM, Ian Jackson wrote:

>Right now the plan is to have _passing tests_ (well, regressionless
>ones) _reduce_ the migration delay.  Failing tests would be the same
>as no tests.

One other important point for the Ubuntu infrastructure is that the
autopkgtests are a ratchet.  IOW, if a test has *never* passed, its continued
failure won't block promotion.  It's only once a test starts passing and then
regresses will it block.

We have an "excuses" page that shows you what things look like.  It could be
prettied-up, but it provides lots of useful information.  It also includes a
retry button (the little three-arrow triangle) for people with the proper
permissions.

http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html

Cheers,
-Barry


pgpLCUAxhyn7m.pgp
Description: OpenPGP digital signature

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Russ Allbery]

Santiago Vila  writes:

> Should I ask the Technical Committee to rule out that FTBFS bugs are RC,
> even if they did not happen in buildd.debian.org yet?

This seems excessively aggressive.  I've had FTBFS bugs in my packages
that were due to specific configurations for archive mass rebuilds that
were not reproducible on buildds, and while those are certainly bugs that
I wanted to fix, I think making them RC is questionable.

See, for instance:

https://bugs.debian.org/830452 (which I shouldn't have closed)
https://bugs.debian.org/835677

I understand the frustration -- for instance, I closed that first bug when
I absolutely should have left it open, since it represented a fragile
test.  (It's now fixed properly.)  But I think making them RC instead is
an overreaction.

Remember, making a bug RC says that we're going to remove the package from
the archive if the bug isn't fixed.  Suppose either of those had been
reported near the release freeze and I was, say, in the hospital or
something and simply couldn't look at them.  Would the appropriate
reaction to either of the above bugs be to remove the software from the
release?

Note that I'm not arguing that these aren't bugs, or that they shouldn't
be a priority, just that FTBFS bugs that aren't reproducible on buildds
don't interfere with the release or with security support and therefore
I'm not sure the RC severity is justified.  (Now, that said, flaky
failures that sometimes do fail on buildds *may* interfere with security
support, and therefore are, to my mind, much more serious.)

-- 
Russ Allbery (r...@debian.org)   

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Santiago Vila]

On Mon, Jan 16, 2017 at 12:02:32PM -0800, Russ Allbery wrote:
> Santiago Vila  writes:
> 
> > Should I ask the Technical Committee to rule out that FTBFS bugs are RC,
> > even if they did not happen in buildd.debian.org yet?
> 
> This seems excessively aggressive.

No, really it's not. It's already current practice:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=lamby%40debian.org
https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=lucas%40debian.org
https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=sanvila%40debian.org

Are you suggesting that we should refrain from reporting FTBFS bugs as
serious unless we have a build log from buildd.debian.org in our hands?

I'm sure you are not, but I've seen people downgrade bugs "because
they do not happen in buildd.debian.org" and at the same time nobody
of them realize what would happen if we followed such silly
(and wrong) rule in a consistent way.

> I've had FTBFS bugs in my packages
> that were due to specific configurations for archive mass rebuilds that
> were not reproducible on buildds, and while those are certainly bugs that
> I wanted to fix, I think making them RC is questionable.

Well, maybe what it's excessively aggressive or questionable is to run
the tests at build time and making the package build as a whole
to fail when any test fails.

I have the feeling that this autopkgtest things should be used (among
other things) to de-couple package builds from package testing.

Then people who test that packages build ok would have one thing less
to worry about.

> [...]
> 
> Remember, making a bug RC says that we're going to remove the package from
> the archive if the bug isn't fixed.  Suppose either of those had been
> reported near the release freeze and I was, say, in the hospital or
> something and simply couldn't look at them.  Would the appropriate
> reaction to either of the above bugs be to remove the software from the
> release?

No, the appropriate reaction would be to disable the failing tests via
NMU until the maintainer exits the hospital and can investigate.

Thanks.

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Markus Koschany]

On 16.01.2017 22:00, Santiago Vila wrote:
> On Mon, Jan 16, 2017 at 12:02:32PM -0800, Russ Allbery wrote:
>> Santiago Vila  writes:
>>
>>> Should I ask the Technical Committee to rule out that FTBFS bugs are RC,
>>> even if they did not happen in buildd.debian.org yet?
>>
>> This seems excessively aggressive.
> 
> No, really it's not. It's already current practice:
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=lamby%40debian.org
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=lucas%40debian.org
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=sanvila%40debian.org
> 
> Are you suggesting that we should refrain from reporting FTBFS bugs as
> serious unless we have a build log from buildd.debian.org in our hands?
> 
> I'm sure you are not, but I've seen people downgrade bugs "because
> they do not happen in buildd.debian.org" and at the same time nobody
> of them realize what would happen if we followed such silly
> (and wrong) rule in a consistent way.

[...]

No, this is not current practice. But you are obviously trying to force
it this way by all means necessary. Nobody asks you from refraining to
report those kind of bugs but what I and other people are seriously
questioning is your handling of severity levels. You always assume RC
severity even when it is proven that the package works and builds fine
for the majority of people. You don't care what maintainers think about
the issue. Many people, me included, get annoyed and then resolve this
"issue" by disabling the responsible test and focus on more pressing
matters. There is nothing wrong with tests per se which try to catch
_real life_ issues though.

How can this be in the best interest of users and developers? First of
all I think your test environment is fundamentally flawed. It is
possible to make every package in the archive fail to build from source
by choosing extremely unusual parameters. Tests and packages require a
certain amount of memory and a certain amount of disk space. Tests make
assumptions about what is to be expected in a real life environment.
Nobody in his right mind would agree with me that a build failure due to
low memory on a user's machine is RC when the buildds and 99,9 % of all
standard computers are able to compile the package.

Should this become the standard in Debian, then I would at least expect
that we define some sort of reference system (in terms of hardware
specs) against which these rebuilds are run. In my opinion the buildd
network is a reasonable candidate. A randomly emulated environment is not.





signature.asc
Description: OpenPGP digital signature

Re: "not authorised" doing various desktoppy things [and 1 more messages]

[Martín Ferrari]

On 15/01/17 13:43, Ian Jackson wrote:
> Ian Jackson writes ("Re: "not authorised" doing various desktoppy things [and 
> 1 more messages]"):
>> More news later today.
> 
> I have just uploaded systemd-shim 10-3~exp1 to experimental.  I seems
> to fix the problem for me.  Depending on feedback, I will upload this
> to sid in the next few days.

This seems to solve the problem for me, thank you very much! (And I hope
you can get this in for stretch!)


-- 
Martín Ferrari (Tincho)

Your best source for personal finance knowledge

[SUPERMONEY]

 Your best source for personal finance knowledge 

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Michael Biebl]

Am 16.01.2017 um 23:45 schrieb Markus Koschany:

> No, this is not current practice. But you are obviously trying to force
> it this way by all means necessary. Nobody asks you from refraining to
> report those kind of bugs but what I and other people are seriously
> questioning is your handling of severity levels.

Yup, I'm definitely annoyed by how aggressively Santiago is handling
this. He's not helping anyone with this even if he has well-meaning
intentions.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Santiago Vila]

On Mon, Jan 16, 2017 at 11:45:42PM +0100, Markus Koschany wrote:

> No, this is not current practice. But you are obviously trying to force
> it this way by all means necessary. Nobody asks you from refraining to
> report those kind of bugs but what I and other people are seriously
> questioning is your handling of severity levels.

Sorry, no. You downgraded "missing build-depends"-type bugs several
times, and somebody else had to tell you that they were RC.

Example: gnupg. You did not believe that gnupg was not essential and
argued and argued and argued until a Release Manager told you clearly
that missing build-depends are RC.

There was also a missing build-conflicts bug that you downgraded and
somebody else had to tell you that it was wrong as well.

So it's not me who is handling severities wrong.

> You always assume RC
> severity even when it is proven that the package works and builds fine
> for the majority of people.

No. I assume RC when it is a FTBFS bug and I can reproduce it in
several different computers.

There is no such thing as a "majority of people" when your single and
only source for "buildability" is buildd.debian.org.

A successful build in buildd.debian.org means *nothing*.

Buildds may have packages installed which are not build-essential.

Buildds may be running jessie while I am already running stretch.

Etc.

> You don't care what maintainers think about
> the issue. Many people, me included, get annoyed and then resolve this
> "issue" by disabling the responsible test and focus on more pressing
> matters. There is nothing wrong with tests per se which try to catch
> _real life_ issues though.

Sorry, it is not responsible at all to have a flaky test make the
whole build to fail.

If you get annoyed by flaky tests making the build to fail, do not let
the test to make the build to fail, but don't blame me for the annoyance
that the test fails.

Thanks.

Upcoming changes to APT architecture restriction list (wildcards) support

[Julian Andres Klode]

Hi,

as a lot of people are already aware, APT and dpkg have disagreed
on architecture wildcards for quite some time, because the approach
taken in apt was "weird".

I have just committed a change that makes APT uses dpkg's triplet
or tuplettables, depending on how new your dpkg is:

https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=6ede895

I expect the change to land in unstable tomorrow.

A wildcard like any-armel won't work anymore. This wildcard was
understodd by apt, but not by dpkg. In dpkg, armel matches any-arm
instead. As these wildcards have been interpreted differently
before, it is assumed that they are not used yet in critical
places.

The approach taken to implement this is slightly weird, I want
to thank James Clarke  for providing an
initial patch in http://bugs.debian.org/748936.

It does however validate against all architecture and wildcard
combinations known by dpkg, producing no false positives and
no false negatives.

Having one understanding of wildcards allows us to finally use
these wildcards properly. So for example, any-arm can now be
used for armel and armhf building.

There is one caveat however: Ubuntu still ships a dpkg
1.18.10 which uses triplets, whereas Debian ships a newer
dpkg that uses quadruplets. As an example, to match an architecture
like armhf (arm with glibc and eabihf ABI) for all kernels:

gnueabihf-any-arm   on Ubuntu
eabihf-gnu-any-armon Debian

If you want to use patterns that combine a special ABI variant with
a libc variant, it is best to just include both variants in the
list IMO so it works with old and current dpkg versions.

Thanks,

Julian

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

[Russ Allbery]

Santiago Vila  writes:

> No, really it's not. It's already current practice:

> https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=lamby%40debian.org
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=lucas%40debian.org
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=sanvila%40debian.org

> Are you suggesting that we should refrain from reporting FTBFS bugs as
> serious unless we have a build log from buildd.debian.org in our hands?

No, I'm suggesting that you should continue to report FTBFS as serious,
but if the maintainer downgrades the bug to important because it's not
reproducible on the buildds and seems to be an artifact of the test
rebuild environment and they don't have time to fix it immediately, you
should at least consider whether that's possibly a legitimate response
depending on the specific situation.  And that one should at least take a
look at such bugs, ideally, before letting them auto-remove packages from
testing (although I understand that no one really has much time to do
that).

I cannot over-stress how demoralizing it is to have your packages removed
from the archive right before a release because you didn't have time to
fix a bug like this due to life reasons.  I am all in favor of continually
ratcheting up the quality expectations that we have for Debian packages,
but please be sensitive to whether the specific bug you've discovered is
*really* release-critical, in the sense that the package is going to cause
some problem or not be maintainable in a stable release.

For many, many FTBFS bugs, the answer is yes, it's release-critical.  But
I don't think that's true for every instance of someone attempting to
build a Debian source package and having it fail.

> I'm sure you are not, but I've seen people downgrade bugs "because they
> do not happen in buildd.debian.org" and at the same time nobody of them
> realize what would happen if we followed such silly (and wrong) rule in
> a consistent way.

I have sometimes downgraded such bugs because, as it turns out, the person
who reported the FTBFS bug was building in an unclean environment (stray
bad configuration files, stray partly-removed conflicting packages, etc.).
I want my packages to build everywhere, and I don't think there's been a
case of this where I've not managed to fix it, but I don't consider
ensuring that the package builds in absolutely any environment to be
release-critical.

> Well, maybe what it's excessively aggressive or questionable is to run
> the tests at build time and making the package build as a whole to fail
> when any test fails.

*blink*.

I'm quite surprised that you would advocate not failing a build if tests
fail during the package build?  I think that would be an awful way to
proceed.  My packages have test suites for a reason.  I do not want
packages to appear to successfully build if their tests are failing.  That
may mean that the resulting binaries are nonfunctional or even dangerous.

> I have the feeling that this autopkgtest things should be used (among
> other things) to de-couple package builds from package testing.

autopkgtest is useful for adding additional tests of the built binaries,
but I don't believe it's intended as a replacement for build-time testing.
Maybe I've missed something?

> No, the appropriate reaction would be to disable the failing tests via
> NMU until the maintainer exits the hospital and can investigate.

That would certainly be fine, and I'm signed up for every "please NMU my
packages" list I can find, but we both know that time to do this for all
packages is pretty short in the run-up to the release.

-- 
Russ Allbery (r...@debian.org)   

Bug#851639: ITP: alacritty -- A cross-platform, GPU-accelerated terminal emulator

[Eric Dorland]

Package: wnpp
Severity: wishlist
Owner: Eric Dorland 

* Package name: alacritty
  Upstream Author : Joe Wilm  
* URL : https://github.com/jwilm/alacritty
* License : Apache 2.0
  Programming Lang: Rust
  Description : A cross-platform, GPU-accelerated terminal emulator

Alacritty is the fastest terminal emulator in existence. Using the GPU for
rendering enables optimizations that simply aren't possible in other emulators.