Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
Hi Pirate, On 13-01-17 08:46, Pirate Praveen wrote: > Similar to piuparts auto rejects, I think we should add auto reject when > autopkgtest of a reverse dependency or build dependency fails (which was > not failing earlier) or cause FTBFS to reverse dependencies. This will > help us prevent library updates without proper transitions breaking > other packages. One recent example is update on python-html5lib which > broke python-bleach even though build was failing [1]. > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844943 I'm working on that¹ and hope we can enable it soon after Stretch release. Paul ¹ https://lists.debian.org/debian-release/2016/12/msg00310.html signature.asc Description: OpenPGP digital signature
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
On വെള്ളി 13 ജനുവരി 2017 01:33 വൈകു, Paul Gevers wrote: > I'm working on that¹ and hope we can enable it soon after Stretch release. Thanks! I think it will help us in a great way in handling library transitions. signature.asc Description: OpenPGP digital signature
ITP: python-bx -- library to manage genomic data and its aligment
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: python-bx Version : 0.7.2 * URL : https://github.com/bxlab/bx-python * License : MIT Programming Lang: Python Description : library to manage genomic data and its aligment python-bx is a requirement for getting the Galaxy workflow suite closer to our distribution. The packaging is maintained by the Debian Med team and hosted on https://anonscm.debian.org/cgit/debian-med/python-bx.git/
Re: Converting to dgit
On Thu, 2017-01-12 at 21:46 +0100, Raphael Hertzog wrote: > Hi, > > On Fri, 06 Jan 2017, Ghislain Vaillant wrote: > > > I don't use it often enough to remember all the details either. I don't > > > recall the last time I had to do more than copy/paste a command from the > > > man > > > page (OK, git-dpm tag I can remember). > > > > Besides, git-dpm usually tells you what command to run next, like: > > > > git-dpm import-new-upstream -> git-dpm rebase-patched -> git-dpm > > update-patches > > > > It did not take me much time to adapt to the git-dpm workflow as a > > result. I should say that I have been a happy git-dpm user so far. > > And I have been a very unhappy user with python-django. If by mistake, you > use "gbp import-orig" instead of "git-dpm import-new-upstream" then you're > completely screwed because git-dpm relies on metadata it manually stores > in debian/.git-dpm, it does not rely on git's history to figure out the > appropriate data. Same if you change any patch outside with a third party > tool... Well, remember that `git-dpm import-new-upstream` only records the new upstream commit in the .git-dpm metadata and delays the actual import of the new upstream data until you have a properly rebased patch queue. This is to be contrasted with `gbp` where you may import the new upstream and leave the packaging repository in an inconsistent state (as far as the patch queue is concerned) until someone runs `gbp pq` or `quilt` to refresh. Then, no wonder that mixing `gbp import-orig` with git-dpm does not work. I admire your courage for trying to fixup the git-dpm metadata manually nonetheless. Same problem if you try to mix `git-dpm cherry- pick` with `gbp pq import` -> `git cherry-pick` -> `gbp pq export`. > So I have opened the manual page many times to read about the format of > that file and tried to fix up the inconsistent meta-data. > > Also it's really painful to use with multiple branches as you can't really > merge branches together: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801667 This is indeed a limitation. Based on the design of the tool, git-dpm works on a rather flat git history. Considering the workflow you described for django, git-dpm is unlikely to ever become suitable. > It produces a very verbose git history as soon as you have a significant > number of patches, even if most of them do not change at all across a > minor upstream release. Is that such a bad thing though, I wonder? Given that the price for it is a guaranteed consistent patch queue. > Also it's effectively orphaned, nobody is taking care of bugs. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801666 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801548 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795694 So was pristine-tar for a long time and people kept using it nonetheless. I also commented in #801666, so I am aware of your issues with git-dpm. I agree that integration with existing gbp configuration would be a plus and help support arbitrary repository layouts, such as those recommended in DEP-14. I don't necessarily disagree with you, as I keep using both gbp and git-dpm in a complementary way. I just wanted to contrast the perceived hate towards git-dpm in this thread with some positive feedback. Cheers, Ghis
Bug#851255: ITP: python-rediscluster -- Python interface to a cluster of Redis key-value stores
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: python-rediscluster Version : 0.5.3 Upstream Author : Salimane Adjao Moustapha * URL : https://github.com/salimane/rediscluster-py * License : MIT Programming Lang: Python Description : Python interface to a cluster of Redis key-value stores Redis is a key-value database in a similar vein to memcache but the dataset is non-volatile. Redis additionally provides native support for atomically manipulating and querying data structures such as lists and sets. . rediscluster is a Python library adapting the upstream Redis bindings to enable sharding among different Redis instances in a transparent, fast, and fault tolerant way. This package will be maintained under the umbrella of the Debian Python Modules Team. It is a dependency of python-limits, which in turn is a dependency of Flask-Limiter which I intend to package.
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
On Friday, January 13, 2017 09:03:51 AM Paul Gevers wrote: > Hi Pirate, > > On 13-01-17 08:46, Pirate Praveen wrote: > > Similar to piuparts auto rejects, I think we should add auto reject when > > autopkgtest of a reverse dependency or build dependency fails (which was > > not failing earlier) or cause FTBFS to reverse dependencies. This will > > help us prevent library updates without proper transitions breaking > > other packages. One recent example is update on python-html5lib which > > broke python-bleach even though build was failing [1]. > > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844943 > > I'm working on that¹ and hope we can enable it soon after Stretch release. > > Paul > ¹ https://lists.debian.org/debian-release/2016/12/msg00310.html For clarity, you're discussing this being a testing migration blocker, not a package accept auto-reject, right? Scott K signature.asc Description: This is a digitally signed message part.
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
Hi, 2017-01-13 8:46 GMT+01:00 Pirate Praveen : > Similar to piuparts auto rejects, I think we should add auto reject when > autopkgtest of a reverse dependency or build dependency fails (which was > not failing earlier) or cause FTBFS to reverse dependencies. > just be carefull, because there are some packages which FTBFS in debci (example: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/swift.html ) and it's bug in debci. Build works fine in buildd and in my local sbuild. Maybe we should fix this first? -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
how to mount /(dev|run)/shm properly? (was Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS)
On Fri, Jan 13, 2017 at 02:38:28PM +0100, Ondrej Novy wrote: > just be carefull, because there are some packages which FTBFS in debci > (example: > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/swift.html > ) > and it's bug in debci. Build works fine in buildd and in my local sbuild. while this is not related to debci, it brings up an interesting question: how should /dev/shm be mounted? and how /run/shm? i'm interesting in this question for Debian stable with 3.16 and 4.6-4-9 kernels and ubuntu 16.04 running 4.4 kernels… -- cheers, Holger signature.asc Description: Digital signature
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
Hi Scott, On 13-01-17 14:30, Scott Kitterman wrote: > On Friday, January 13, 2017 09:03:51 AM Paul Gevers wrote: >> On 13-01-17 08:46, Pirate Praveen wrote: >>> Similar to piuparts auto rejects, I think we should add auto reject when >>> autopkgtest of a reverse dependency or build dependency fails (which was >>> not failing earlier) or cause FTBFS to reverse dependencies. This will >>> help us prevent library updates without proper transitions breaking >>> other packages. One recent example is update on python-html5lib which >>> broke python-bleach even though build was failing [1]. >>> >>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844943 >> >> I'm working on that¹ and hope we can enable it soon after Stretch release. >> >> Paul >> ¹ https://lists.debian.org/debian-release/2016/12/msg00310.html > > For clarity, you're discussing this being a testing migration blocker, not a > package accept auto-reject, right? I am not sure if you are addressing me or Pirate, but indeed I am working on an implementation similar to what Ubuntu does (see the link above about the details) which will be used as unstable to testing migration blocker. debci is the worker, but all the policy logic will be with britney where it belongs. And of course I try to have a full release cycle to tune it. Paul signature.asc Description: OpenPGP digital signature
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
Paul Gevers writes: > I am not sure if you are addressing me or Pirate, but indeed I am > working on an implementation similar to what Ubuntu does (see the link > above about the details) which will be used as unstable to testing > migration blocker. debci is the worker, but all the policy logic will be > with britney where it belongs. And of course I try to have a full > release cycle to tune it. 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. Best regards Ole
Bug#851272: ITP: python-limits -- Rate limiting utilities for Python
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: python-limits Version : 1.2.1 Upstream Author : Ali-Akber Saifee * URL : https://limits.readthedocs.org * License : MIT Programming Lang: Python Description : Rate limiting utilities for Python limits is a Python module providing utilities to implement rate limiting using various strategies, such as fixed or moving windows, and various storage backends, such as in in-memory storage, Redis or memcached. limits is the back-end and base implementation of the rate-limiting algorithms provided by Flask-Limiter. The module will be maintained inside the Debian Python Modules Team
Re: how to mount /(dev|run)/shm properly? (was Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS)
On Fri, 13 Jan 2017 at 14:14:09 +, Holger Levsen wrote: > how should /dev/shm be mounted? and how /run/shm? I believe the "API" is that /dev/shm is either a tmpfs with /tmp-like permissions (01777), or a symlink to such a tmpfs. My understanding is that /run/shm is considered to be an implementation detail, rather than something that software should hard-code anywhere. Reference: glibc sysdeps/unix/sysv/linux/shm-directory.c (the original user of /dev/shm). systemd mounts a tmpfs on /dev/shm (it's hard-coded in as one of the "API filesystems"), and Debian's systemd packaging puts a symlink at /run/shm in case anything is relying on it (/usr/lib/tmpfiles.d/debian.conf). If I'm reading the initscripts code correctly, sysvinit does the reverse by default, for some reason (/run/shm is the mount point and /dev/shm the symlink). I think the motivation might have been to be able to use the same tmpfs for /run and /run/shm, but that's a bad idea if you want to prevent unprivileged users from performing a DoS attack on privileged system components by filling up /run (which is why systemd gives each user their own tmpfs at /run/user/$uid by default). The default schroot configuration mounts a tmpfs on /dev/shm and does not do anything special about /run/shm. Generalizing from those, I think it's reasonable to say that in a bare-metal system, init is responsible for arranging for /dev/shm to be as required, and in a container or chroot, the container manager is responsible. S
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
On Fri, 2017-01-13 at 15:57 +0100, Ole Streicher wrote: > Paul Gevers writes: > > I am not sure if you are addressing me or Pirate, but indeed I am > > working on an implementation similar to what Ubuntu does (see the link > > above about the details) which will be used as unstable to testing > > migration blocker. debci is the worker, but all the policy logic will be > > with britney where it belongs. And of course I try to have a full > > release cycle to tune it. > > 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. > > Best regards > > Ole I second Ole's concerns here. Strict autorejection would be assuming that all autopkgtest testsuites are solid, which has not always been the case in my experience. Ghis
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
On Fri, Jan 13, 2017 at 03:57:09PM +0100, Ole Streicher wrote: > Paul Gevers writes: > > I am not sure if you are addressing me or Pirate, but indeed I am > > working on an implementation similar to what Ubuntu does (see the link > > above about the details) which will be used as unstable to testing > > migration blocker. debci is the worker, but all the policy logic will be > > with britney where it belongs. And of course I try to have a full > > release cycle to tune it. > > 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. You can either fix the reverse dependency, or get it removed. signature.asc Description: PGP signature
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
On Fri, Jan 13, 2017 at 02:38:28PM +0100, Ondrej Novy wrote: > Hi, > > 2017-01-13 8:46 GMT+01:00 Pirate Praveen : > > > Similar to piuparts auto rejects, I think we should add auto reject when > > autopkgtest of a reverse dependency or build dependency fails (which was > > not failing earlier) or cause FTBFS to reverse dependencies. > > > > just be carefull, because there are some packages which FTBFS in debci > (example: > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/swift.html > ) > and it's bug in debci. Build works fine in buildd and in my local sbuild. I think you are a little confused. That links to reproducible builds, which has nothing to do with debci. signature.asc Description: PGP signature
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
Antonio Terceiro writes: > On Fri, Jan 13, 2017 at 03:57:09PM +0100, Ole Streicher wrote: >> Paul Gevers writes: >> > I am not sure if you are addressing me or Pirate, but indeed I am >> > working on an implementation similar to what Ubuntu does (see the link >> > above about the details) which will be used as unstable to testing >> > migration blocker. debci is the worker, but all the policy logic will be >> > with britney where it belongs. And of course I try to have a full >> > release cycle to tune it. >> >> 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. > > You can either fix the reverse dependency, or get it removed. Sorry, I don't understand this. How can I get a reverse dependency removed (from unstable)? And why should I get responsible for poorly maintained reverse dependencies? Also, at least up to now, CI test failures are not necessarily critical. It depends on the evaluation of the maintainer which severity the problem that popped up has: often CI tests are quite picky to serve as an early indicator for problems. For example, a new package could write a deprecation warning which brings the CI test of a reverse dependency to fail. The failure is in no way critical (since the package works). But I would also not like to ignore stderr -- I *want* to have these kinds of warnings so that I can react before the real change happens, but I also see no reason to hurry up here (usually, I contact upstream and wait until they have a solution). If you now make the first package dependent on the reverse dependency, it will not migrate because of the CI failure, but I would also (as maintainer of the reverse dependency) not accept to ignore stderr. Problems like these will create additional work for all parties and are likely to make people angry. IMO it would be much better if you would either auto-create bug reports (which may be re-assigned), or to have an "ignore" button somewhere. The idea of getting informed that a certain upload causes problems in other packages is however great. BTW, there were some discussions at debconf about getting an E-mail on CI test status changes; this would also be a nice thing. Best regards Ole
Bug#851290: ITP: flask-limiter -- Rate-limiting for Flask routes
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: flask-limiter Version : 0.9.3 Upstream Author : Ali-Akber Saifee * URL : http://flask-limiter.readthedocs.org/ | https://github.com/alisaifee/flask-limiter * License : MIT Programming Lang: Python Description : Rate-limiting for Flask routes Flask is a micro web framework for Python based on Werkzeug, Jinja 2 and good intentions. . Flask-Limiter provides rate limiting features to flask routes. It has support for a configurable backend for storage with current implementations for in-memory, redis and memcache. This package will be maintained under the umbrella of the Debian Python Modules Team
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
Hi, 2017-01-13 17:47 GMT+01:00 Antonio Terceiro : > I think you are a little confused. That links to reproducible builds, > which has nothing to do with debci. > yep, sorry for confusion. I assumed that FTBS migration check will use data from reproducible builds OR will use same system for running builds (Jenkins?). -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
Ole Streicher writes ("Re: Auto reject if autopkgtest of reverse dependencies
fail or cause FTBFS"):
> Sorry, I don't understand this. How can I get a reverse dependency
> removed (from unstable)?
You wouldn't. You would need to get it removed from testing.
> And why should I get responsible for poorly
> maintained reverse dependencies?
This is more of a sticking point. I don't know what proportion of CI
failures are going to be due to poorly maintained reverse
dependencies.
But the real answer to this is that "Debian testing should be kept
releaseable" and that means that if your rdepends are busted such that
your changes cause lossage, something has to give.
> The idea of getting informed that a certain upload causes problems in
> other packages is however great.
Maybe an intermediate position would be to respond to a CI failure by:
* Increasing the migration delay for the affecting package
* Notifying the affected package maintainers
> BTW, there were some discussions at debconf about getting an E-mail on
> CI test status changes; this would also be a nice thing.
Yes.
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
On Friday, January 13, 2017 05:46:41 PM Ole Streicher wrote: > Antonio Terceiro writes: > > On Fri, Jan 13, 2017 at 03:57:09PM +0100, Ole Streicher wrote: > >> Paul Gevers writes: > >> > I am not sure if you are addressing me or Pirate, but indeed I am > >> > working on an implementation similar to what Ubuntu does (see the link > >> > above about the details) which will be used as unstable to testing > >> > migration blocker. debci is the worker, but all the policy logic will > >> > be > >> > with britney where it belongs. And of course I try to have a full > >> > release cycle to tune it. > >> > >> 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. > > > > You can either fix the reverse dependency, or get it removed. > > Sorry, I don't understand this. How can I get a reverse dependency > removed (from unstable)? And why should I get responsible for poorly > maintained reverse dependencies? > > Also, at least up to now, CI test failures are not necessarily > critical. It depends on the evaluation of the maintainer which severity > the problem that popped up has: often CI tests are quite picky to serve > as an early indicator for problems. > > For example, a new package could write a deprecation warning which > brings the CI test of a reverse dependency to fail. The failure is in no > way critical (since the package works). But I would also not like to > ignore stderr -- I *want* to have these kinds of warnings so that I can > react before the real change happens, but I also see no reason to hurry > up here (usually, I contact upstream and wait until they have a > solution). > > If you now make the first package dependent on the reverse dependency, > it will not migrate because of the CI failure, but I would also (as > maintainer of the reverse dependency) not accept to ignore stderr. > > Problems like these will create additional work for all parties and are > likely to make people angry. IMO it would be much better if you would > either auto-create bug reports (which may be re-assigned), or to have an > "ignore" button somewhere. > > The idea of getting informed that a certain upload causes problems in > other packages is however great. > > BTW, there were some discussions at debconf about getting an E-mail on > CI test status changes; this would also be a nice thing. Probably the simplest way to avoid problems with systems like this is to remove any autopkg tests your packages are shipping. Scott K P.S. Perverse incentives FTW.
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
On Fri, 13 Jan 2017 at 18:22:53 +, Ian Jackson wrote: > Maybe an intermediate position would be to respond to a CI failure by: > * Increasing the migration delay for the affecting package > * Notifying the affected package maintainers I think this makes sense: it gives the maintainer and other interested developers some time to assess whether the failure is a showstopper (=> upload a fix/revert/workaround, or at worst file a RC bug) or not. Or, conversely, blocking migrations but letting the relevant maintainers remove that block might work. On Fri, 13 Jan 2017 at 13:54:26 -0500, Scott Kitterman wrote: > 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. This is my concern too. If you maintain a useful package with tests that are unstable but do not imply a release-critical issue, running those tests and recording-but-ignoring the failures seems considerably better for Debian than either disabling the tests or removing the software (more information is better than less information, and if the package is useful despite the test failure then it's better to have it than not). Possible autopkgtest extension: "Restrictions: unreliable"? S
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
Simon McVittie writes: > On Fri, 13 Jan 2017 at 18:22:53 +, Ian Jackson wrote: >> Maybe an intermediate position would be to respond to a CI failure by: >> * Increasing the migration delay for the affecting package >> * Notifying the affected package maintainers > > I think this makes sense: it gives the maintainer and other interested > developers some time to assess whether the failure is a showstopper > (=> upload a fix/revert/workaround, or at worst file a RC bug) or not. > > Or, conversely, blocking migrations but letting the relevant maintainers > remove that block might work. 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. > Possible autopkgtest extension: "Restrictions: unreliable"? This is not specific enough. Often you have some tests that are unreliable, and others that are important. Since one usually takes the upstream test suite (which may be huge), one has to look manually first to decide about the further processing. Best regards Ole
Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: freebayes Version : 1.0.2 Upstream Author : Erik Garrison * URL : https://github.com/ekg/freebayes * License : MIT Programming Lang: C++ Description : Bayesian haplotype-based polymorphism discovery and genotyping FreeBayes is a Bayesian genetic variant detector designed to find small polymorphisms, specifically SNPs (single-nucleotide polymorphisms), indels (insertions and deletions), MNPs (multi-nucleotide polymorphisms), and complex events (composite insertion and substitution events) smaller than the length of a short-read sequencing alignment. Remark: This package is maintained by the Debian Med team at https://anonscm.debian.org/git/debian-med/freebayes.git
Re: Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping
On Friday, January 13, 2017 10:00:13 PM Andreas Tille wrote: > Package: wnpp > Severity: wishlist > Owner: Andreas Tille > > * Package name: freebayes > Version : 1.0.2 > Upstream Author : Erik Garrison > * URL : https://github.com/ekg/freebayes > * License : MIT > Programming Lang: C++ > Description : Bayesian haplotype-based polymorphism discovery and > genotyping FreeBayes is a Bayesian genetic variant detector designed to > find small polymorphisms, specifically SNPs (single-nucleotide > polymorphisms), indels (insertions and deletions), MNPs > (multi-nucleotide polymorphisms), and complex events (composite > insertion and substitution events) smaller than the length of a > short-read sequencing alignment. > > > Remark: This package is maintained by the Debian Med team at >https://anonscm.debian.org/git/debian-med/freebayes.git "freebayes" seems like a very generic name for something specific to such a narrow field. Maybe freebayes-genetic-variance or some such instead. Scott K
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
Hi Ole, On 01/13/17 21:05, Ole Streicher wrote: > Simon McVittie writes: >> On Fri, 13 Jan 2017 at 18:22:53 +, Ian Jackson wrote: >>> Maybe an intermediate position would be to respond to a CI failure by: >>> * Increasing the migration delay for the affecting package I like this and will suggest it to the release team. Especially for the start up time. >>> * Notifying the affected package maintainers >> >> I think this makes sense: it gives the maintainer and other interested >> developers some time to assess whether the failure is a showstopper >> (=> upload a fix/revert/workaround, or at worst file a RC bug) or not. >> >> Or, conversely, blocking migrations but letting the relevant maintainers >> remove that block might work. One can always file bug reports against the release.debian.org pseudo package to ask for britney to ignore the autopkgtest result. One other thing that I can envision (but maybe to early to agree on or set in stone) is that we lower the NMU criteria for fixing (or temporarily disabling) autopkgtest in ones reverse dependencies. In the end, personally I don't think this is up to the "relevant maintainers" but up to the release team. And I assume that badly maintained autopkgtest will just be a good reason to kick a package out of testing. On the item of notifications, I would expect that as soon as we have this mechanism in place we would implement the notification on all the actively maintained notification places, such as tracker.debian.org and udd. This isn't much different than other migration criteria or auto-removals in that respect. > 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. The largest reason is that it didn't cross my mind yet and nobody else except you has raised the idea so far. One cravat that I see though is which system should hold the logic. The current idea is that it is britney that determines which combinations need to be tested and thus can use the result straight away for the migration decision. As Martin Pitt described in the thread I referenced in my first reply, Ubuntu already experimented with this and they came to the conclusion that it didn't really work if two entities have to try and keep the logic in sync. >> Possible autopkgtest extension: "Restrictions: unreliable"? > > This is not specific enough. Often you have some tests that are > unreliable, and others that are important. Since one usually takes the > upstream test suite (which may be huge), one has to look manually first > to decide about the further processing. Than maybe change the wording: not-blocking, for-info, too-sensitive, ignore or If you know your test suite needs investigation, you can have it not automatically block. But depending on the outcome of the investigation, you can still file (RC) bugs. Why I am so motivated on doing this is because I really believe this is going to improve the quality of the release and the release process. I really hope that more packages will be creating autopkgtests, as one now has an incentive: it helps guaranteeing that you package will not suddenly be kicked out of the release due to a change in your dependencies. Personally, one of my autopkgtest has triggered a change in MySQL (upstream even) to not suddenly drop some command line option, but implement a deprecation period. Software was relying on the behavior and in this case there wasn't a grace period. I am not sure that without this "stick" it would have happened (and definitely not in time for the specific Ubuntu release). Paul signature.asc Description: OpenPGP digital signature
Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
On Fri, Jan 13, 2017 at 07:35:10PM +, Simon McVittie wrote: > On Fri, 13 Jan 2017 at 18:22:53 +, Ian Jackson wrote: > > Maybe an intermediate position would be to respond to a CI failure by: > > * Increasing the migration delay for the affecting package > > * Notifying the affected package maintainers > > I think this makes sense: it gives the maintainer and other interested > developers some time to assess whether the failure is a showstopper > (=> upload a fix/revert/workaround, or at worst file a RC bug) or not. > > Or, conversely, blocking migrations but letting the relevant maintainers > remove that block might work. Agreed (if any of this is practical in britney). > On Fri, 13 Jan 2017 at 13:54:26 -0500, Scott Kitterman wrote: > > 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. > > This is my concern too. If you maintain a useful package with tests that > are unstable but do not imply a release-critical issue, running those > tests and recording-but-ignoring the failures seems considerably better > for Debian than either disabling the tests or removing the software > (more information is better than less information, and if the package > is useful despite the test failure then it's better to have it than not). > > Possible autopkgtest extension: "Restrictions: unreliable"? May as well just use "Restrictions: allow-stderr" and "... || true". That's easier to do on a more fine-grained level, too. -- Colin Watson [cjwat...@debian.org]
Bug#851333: ITP: git-annex-el -- Emacs integration for git-annex
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: git-annex-el Version : 1.0+git20160215.e61ef24 Upstream Author : John Wiegley * URL : https://github.com/jwiegley/git-annex-el/ * License : GPL-2+ Programming Lang: Emacs Lisp Description : Emacs integration for git-annex I intend to maintain this as part of the pkg-emacsen team. -- Sean Whitton signature.asc Description: PGP signature
Bug#851334: ITP: magit-annex -- git-annex subcommands for magit
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: magit-annex Version : 1.3.0 Upstream Author : Kyle Meyer , Rémi Vanicat * URL : https://github.com/magit/magit-annex * License : GPL-3+ Programming Lang: Emacs Lisp Description : git-annex subcommands for magit I intend to maintain this as part of the pkg-emacsen team. -- Sean Whitton signature.asc Description: PGP signature
Re: "not authorised" doing various desktoppy things
On 03/01/17 17:05, Ian Jackson wrote: > Recently, my nm-applet can no longer control my network-manager > daemon. I get a message saying[1]: Did you ever get to the root of this? I am having the same kind of problem (no way to control networking, removable media, power settings) and a similar set-up (sysvinit, lightdm, cinnamon). I have been experiencing these kind of problems for months, but usually they would go away after an apt-get upgrade. Not now, and I am afraid that we will ship stretch with this problem. -- Martín Ferrari (Tincho)
ITP: python-bd2k -- general utility library for bd2k python package
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: python-bd2k * URL : https://github.com/BD2KGenomics/bd2k-python-lib * License : Apache Programming Lang: Python Description : general utility library for bd2k python package The package is a 2nd degree dependency of the Toil workload distributor expected in Debian any time soon. It is about to be group-maintained at anonscm.debian.org/cgit/debian-med/python-bd2k
