Bug#897672: ITP: python-pyfftw -- a pythonic wrapper around FFTW, the speedy FFT library
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: python-pyfftw Version : 10.2 Upstream Author : Henry Gomersall * URL : http://hgomersall.github.io/pyFFTW/ * License : BSD Programming Lang: Python Description : a pythonic wrapper around FFTW, the speedy FFT library pyFFTW is a pythonic wrapper around FFTW, the speedy FFT library. The ultimate aim is to present a unified interface for all the possible transforms that FFTW can perform. Both the complex DFT and the real DFT are supported, as well as on arbitrary axes of abitrary shaped and strided arrays, which makes it almost feature equivalent to standard and real FFT functions of numpy.fft (indeed, it supports the clongdouble dtype which numpy.fft does not). Operating FFTW in multithreaded mode is supported. pyFFTW is BSD-licensed and should not be confused with python-fftw, a GPL-licensed python module with the same aim of provider python bindings to FFTW3. Or python-gpyfft, which provides bindings to the OpenCL FFT library clFFT. This package will be maintained by the Debian Science maintainers (who also maintain FFTW3 itself and python-gpyfft)
Re: Firefox 60esr on Stretch ?
在 2018年5月4日星期五 CST 上午3:56:30，Jeremy Bicha 写道：
> On Thu, May 3, 2018 at 3:32 PM, Adam Borowski wrote:
> > On Thu, May 03, 2018 at 02:29:59PM +0200, Julien Cristau wrote:
> >> I expect nothing much different from previous ESR cycles: stretch will
> >> move
> >> to 60 after 52 goes EOL in September.
> >
> > That's really, really out of what would be reasonable for a stable update.
>
> Updating to the latest Firefox ESR is specifically promised (or
> "planned" at least) in the release notes for Jessie and Stretch. [1]
>
> > At this point, it'd be probably better to look into one of forks that
> > claim
> > security support, of those the only candidate is Waterfox: version >= that
> > of Firefox in stable, the project has been going for awhile.
> >
> > Any of possible options, though, make me really sorry for anyone who
> > maintains a browser... :(
>
> It sounds like you're requesting that somebody other than you maintain
> yet another web browser.
>
> [1]
> https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.
> html#browser-security
>
> Jeremy Bicha
(Sidenote: I found that pkg-mozilla-maintainers Alioth maillist got archived
and is inavailable now; that might have driven this discussion onto debian-
devel).
Firefox 60 ESR would indeed be largely different from 52 ESR; as Adam Borowski
said, "We'd need backports to stretch of multiple compilers (I would
specifically point out the compiler of Rust, 'rustc'), plenty of libraries. It
would also break the entire XUL ecosystem."
However as a user, I found myself largely expecting 60 ESR into Stretch
(regardless of what technology Debian might use). Switching to another Firefox
fork would certainly break Debian's reputation or even drive more people onto
Chromium ("yes, Chromium in Debian (stable) is following upstream version
closely and why couldn't Debian follow Firefox or even follow Firefox ESR?"),
which would be unacceptable.
My personal suggestion is some sort of joint efforts and a exception to push
all reverse depdendencies back to Stretch before 52 ESR got EOL. If that
breaks the whole XUL system, just remove 'em all in next point release. The
time window is limited (Augest 21, 2018, according to [2]).
Besides, it would be great if current firefox maintainers (and Rust
maintainers) could step up and speak out their thoughts.
--
Regards,
Boyuan Yang
[2] https://www.mozilla.org/en-US/firefox/organizations/
signature.asc
Description: This is a digitally signed message part.
Work-needing packages report for May 4, 2018
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1285 (new: 22) Total number of packages offered up for adoption: 162 (new: 1) Total number of packages requested help for: 54 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: anacron (#897138), orphaned 5 days ago Description: cron-like program that doesn't go by time Reverse Depends: checksecurity clamtk exim4-base gnumed-server kde-config-cron logrotate parl-desktop task-laptop Installations reported by Popcon: 108135 Bug Report URL: http://bugs.debian.org/897138 antigrav (#897285), orphaned 2 days ago Description: Multiplayer flying saucer racing game Installations reported by Popcon: 288 Bug Report URL: http://bugs.debian.org/897285 ctioga2 (#897286), orphaned 2 days ago Installations reported by Popcon: 234 Bug Report URL: http://bugs.debian.org/897286 file-kanji (#897562), orphaned yesterday Description: kanji code checker Installations reported by Popcon: 30 Bug Report URL: http://bugs.debian.org/897562 gimp-dds (#897290), orphaned 2 days ago Installations reported by Popcon: 710 Bug Report URL: http://bugs.debian.org/897290 gitstats (#897291), orphaned 2 days ago Description: statistics generator for git repositories Installations reported by Popcon: 377 Bug Report URL: http://bugs.debian.org/897291 jalview (#897294), orphaned 2 days ago Installations reported by Popcon: 71 Bug Report URL: http://bugs.debian.org/897294 java-wrappers (#897295), orphaned 2 days ago Description: wrappers for java executables Reverse Depends: basex bnd checkstyle clirr closure-compiler derby-tools dtdinst electric felix-main findbugs (34 more omitted) Installations reported by Popcon: 16780 Bug Report URL: http://bugs.debian.org/897295 jclassinfo (#897296), orphaned 2 days ago Installations reported by Popcon: 45 Bug Report URL: http://bugs.debian.org/897296 libjaba-client-java (#897297), orphaned 2 days ago Reverse Depends: jalview Installations reported by Popcon: 95 Bug Report URL: http://bugs.debian.org/897297 libjfreechart-java (#897298), orphaned 2 days ago Reverse Depends: altos androidsdk-uiautomatorviewer cronometer igv jajuk libandroid-ddms-ui-java libandroidsdk-common-java libandroidsdk-ddmlib-java libandroidsdk-ddmuilib-java libandroidsdk-hierarchyviewerlib-java (7 more omitted) Installations reported by Popcon: 3510 Bug Report URL: http://bugs.debian.org/897298 libjswingreader-java (#897299), orphaned 2 days ago Reverse Depends: jalview Installations reported by Popcon: 100 Bug Report URL: http://bugs.debian.org/897299 libvamsas-client-java (#897300), orphaned 2 days ago Reverse Depends: jalview Installations reported by Popcon: 97 Bug Report URL: http://bugs.debian.org/897300 ruby-maruku (#897306), orphaned 2 days ago Reverse Depends: coquelicot ruby-github-markup Installations reported by Popcon: 141 Bug Report URL: http://bugs.debian.org/897306 ruby-rmagick (#897307), orphaned 2 days ago Description: ImageMagick API for Ruby Reverse Depends: asciiart ifetch-tools imagetooth redmine ruby-gruff samizdat Installations reported by Popcon: 806 Bug Report URL: http://bugs.debian.org/897307 ruby-setup (#897308), orphaned 2 days ago Description: the setup.rb install tool for Ruby Reverse Depends: gem2deb Installations reported by Popcon: 332 Bug Report URL: http://bugs.debian.org/897308 ruby-tioga (#897309), orphaned 2 days ago Description: Ruby library for scientific graphs Reverse Depends: ctioga2 Installations reported by Popcon: 251 Bug Report URL: http://bugs.debian.org/897309 scalc (#897310), orphaned 2 days ago Description: simple/symbolic calculation library (development files) Reverse Depends: libscalc-dev Installations reported by Popcon: 6 Bug Report URL: http://bugs.debian.org/897310 statcvs (#897311), orphaned 2 days ago Reverse Depends: statsvn Installations reported by Popcon: 90 Bug Report URL: http://bugs.debian.org/897311 statsvn (#897312), orphaned 2 days ago Installations reported by Popcon: 83 Bug Report URL: http://bugs.debian.org/897312 xml-commons-external (#897313), orphaned 2 days ago Description: XML Commons external code - DOM, SAX, and JAXP, etc Reverse Depends: ditaa freeplane igv libbatik-java libfop-java libjaxe-java libxerces2-java pki-base-java pki-server Installations reported by Popcon: 75571
Re: Dealing with ci.d.n for package regressions
Hi Paul, > > ie. 75 out of "top" 100 packages according to popcon are missing > > autopkgtests. > > Yes, go provide patches to add them ;) But let's make them smart. Well, you're pushing at an open door with me with the "patches welcome" call to arms :) But is there not value to even the smallest test here? I've caught a ludicrous number of idiotic mistakes in my packages and code in general with even the dumbest of "smoke" tests. Indeed, the return-on-investment versus clever tests is often scary and that's before we start trading clichés such as "the perfect is the enemy of the good" etc. etc. > https://ci.debian.net/status/ (I note that these are statistics about packages that actually have tests.) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Re: Announce: docker-buildpackage
On 2018-05-03 23:18:44 +0200 (+0200), Thomas Goirand wrote: [...] > Still, this kind of setup (ie: patch proposal and review through a > review system) was super nice, and I wish we could generalize it by > plugging Salsa to something like this. [...] I agree, it's really nice (I'm probably biased though) and would love to see Debian be able to take advantage of similar functionality. I wish my hands weren't already too full to help maintain something along those lines. That said, the Zuul maintainers have seen some interest expressed for adding a Gitlab driver similar to its Gerrit and GitHub drivers, so could eventually be added as an opt-in solution for Salsa repos if someone has the bandwidth to run an instance (and sooner if someone actually volunteers for writing the Gitlab driver!). -- Jeremy Stanley signature.asc Description: PGP signature
Re: Announce: docker-buildpackage
On 05/02/2018 02:02 PM, Ian Jackson wrote: > And it is for those same reasons that libvirt and openstack are not > good alternatives. No-one wants `sbuild-update -udcar unstable' to > have to involve a libvirt driver for sbuild chroots. Well, it all depends. If one has to setup an OpenStack deployment to be able to build packages, then yes, it's too complicated. But if everyone is using a single access to many public clouds, with a pool of ready-to-be-used VMs for building, then it's a whole different thing. That's what I've been doing to release OpenStack Newton for Stretch. The experiment was very nice. We unfortunately decided to stop it because dealing with the way upstream OpenStack is maintained was too demanding. Still, this kind of setup (ie: patch proposal and review through a review system) was super nice, and I wish we could generalize it by plugging Salsa to something like this. Having thousands of pre-built VMs in a pool for gating the build of packages was kind of cool. Having packages already built with a temporary repository when someone does a patch proposal is also super nice. It doesn't mater if it's made with OpenStack or another virtualization layer. The nice thing was using something like nodepool and zuul for scheduling jobs, and having it the default way to submit patches. Cheers, Thomas Goirand (zigo)
Re: Dealing with ci.d.n for package regressions
Hi Chris,
On 03-05-18 20:13, Chris Lamb wrote:
> Secondly, I was just wondering if you are collecting statistics
> over what percentage of packages have autopkgtests, or, perhaps
> more usefully which special/important packages have such tests?
https://ci.debian.net/status/ has a bit. Regarding important packages: I
personally don't mind special/important packages not having such tests
as long as loads of their reverse dependencies have them. E.g. perl is
very well tested (> 1000 tests).
In the end what count is not the quantity of autopkgtests but the
quality. I rather have fewer tests if the tests we have are smarter.
> I can hack together quick things like:
>
> import psycopg2
> import fileinput
>
> NUM = 100
>
> missing = set()
> for x in fileinput.input():
> xs = x.strip().split(' ', 6)
> if xs[-1] == 'testsuite-autopkgtest-missing':
> missing.add(xs[1])
>
> conn = psycopg2.connect(
> user='udd-mirror',
> dbname='udd',
> password='udd-mirror',
> host='udd-mirror.debian.net',
> )
>
> cur = conn.cursor()
> cur.execute('SELECT source FROM popcon_src '
> 'ORDER BY insts DESC LIMIT {}'.format(NUM))
>
> print(' '.join(sorted({x[0] for x in cur} & missing)))
>
> This returns:
>
> $ wget -Olintian.gz
> https://lintian.debian.org/resources/4b0282b7cc918d444724c9a7f1985bf486a39ab5c0a2793f7cddc7113a475cad.gz
> $ gunzip lintian.gz
> $ python3 script.py lintian
> acl attr base-files base-passwd bash bsdmainutils busybox bzip2
> coreutils cpio cron cyrus-sasl2 debconf debian-archive-keyring
> debianutils dmidecode dpkg e2fsprogs expat file findutils
> freetype gcc-6 gcc-7 gcc-8 gdbm gettext groff gzip hostname
> initramfs-tools iputils klibc libedit libidn libselinux libsepol
> libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl
> libusb libx11 libxau libxdmcp libxext logrotate lsb lvm2 mawk
> mime-support ncurses netbase newt openldap openssl pam pciutils
> pcre3 perl popt popularity-contest procps python-defaults
> readline sed shadow slang2 sqlite3 sysvinit tar tcp-wrappers
> tzdata ucf wget zlib
>
> ie. 75 out of "top" 100 packages according to popcon are missing
> autopkgtests.
Yes, go provide patches to add them ;) But let's make them smart.
Paul
signature.asc
Description: OpenPGP digital signature
Re: Dealing with ci.d.n for package regressions
On Thu, May 03, 2018 at 10:38:45PM +0200, Paul Gevers wrote: > > 4. Can we have a way to trigger tests from updates of non-direct > > rdepends ? At some point in the future maybe we will run tests of > > whole batches of updates and then have some algorithm to chop out > > what the failures are caused by, but for now it would be useful to > > be able to declare a specific indirect dependency for test trigger. > > Maybe an XS- header field ? > > Just add it as a test dependency in one of your tests? Just to share a bit that doesn't seem to be of public knowledge: .dsc have a Testsuite-Triggers field that is autopoulated from the d/tests/control file (IIRC). I believe you are looking exactly for this field. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Dealing with ci.d.n for package regressions
Hi Ian, On 03-05-18 14:12, Ian Jackson wrote: > Skipped two point that Niels already covered. > 3. "Required age increased by 10 days because of autopkgtest" > seems to appear when either (i) when there are tests that should be > run but which haven't completed and (ii) when some tests newly failed ? > I wasn't able to see any examples of the latter. I gave an example link to python3.6 which worked at the time of writing, but of course (that how it goes) changed by an new upload. python2.7 seems to show one: libgnatcoll (bug filed: 895235) > 4. Can we have a way to trigger tests from updates of non-direct > rdepends ? At some point in the future maybe we will run tests of > whole batches of updates and then have some algorithm to chop out > what the failures are caused by, but for now it would be useful to > be able to declare a specific indirect dependency for test trigger. > Maybe an XS- header field ? Just add it as a test dependency in one of your tests? > 5. AIUI there is no automatic way for the maintainers of the > rdependency to be notified of a test failure which is blocking > migration of one of their dependencies. Is that right ? The result > is probably that if the maintainers of the dependency don't follow it > up, the regression will migrate and the rdepenency maintainers will be > left to fix it up. No, it's all manual and currently I am doing most triaging (bunk and ginggs have contributed multiple bugs as well). The last couple of weeks I was able to file most bugs before the short expiry of 5 days, now with 15 days the task gets easier. If error messages and output are clean, this isn't so difficult. However, quite often output is hopeless for a bystander and difficult to judge the root cause and the severity. I hope we can improve this in the future by pointing people to the right tools (do they exist (for all languages)?) such that output gets standardized a bit more than currently. > 6. This is really one for the wider project: as the blocking time > increases, we are going to want some more relaxed rules for NMUing one > of your rdependencies. (Right now that would be pointless since you'd > upload it to DELAYED/10 and it would hardly migrate before your own > timeout anyway.) ... Paul signature.asc Description: OpenPGP digital signature
Re: autopkgtest results influencing migration from unstable to testing
Hi Colin, Ian,
On 03-05-18 14:19, Ian Jackson wrote:
> Colin Watson writes ("Re: autopkgtest results influencing migration from
> unstable to testing"):
>> On Thu, May 03, 2018 at 07:14:16AM +0200, Paul Gevers wrote:
>>> In my perception, the biggest reason is a social one. The is resistance
>>> to the fact that issues with autopkgtests out of one's control can block
>>> one's package (this is quite different than in Ubuntu).
>>
>> Can you elaborate on how this is different than in Ubuntu? It sounds
>> pretty similar to me, except for being a delay instead of a block. Or
>> did you mean that the social consequences are different?
> > The key difference is in Paul's sentence "out of one's control".
Right.
> In Ubuntu, any developer may go and fix any package, without
> formality. In Debian fixing "someone else's" package is often hedged
> about with bureaucracy or even discouraged.
Exactly.
Paul
signature.asc
Description: OpenPGP digital signature
Re: Firefox 60esr on Stretch ?
On Thu, May 3, 2018 at 3:32 PM, Adam Borowski wrote: > On Thu, May 03, 2018 at 02:29:59PM +0200, Julien Cristau wrote: >> I expect nothing much different from previous ESR cycles: stretch will move >> to 60 after 52 goes EOL in September. > > That's really, really out of what would be reasonable for a stable update. Updating to the latest Firefox ESR is specifically promised (or "planned" at least) in the release notes for Jessie and Stretch. [1] > At this point, it'd be probably better to look into one of forks that claim > security support, of those the only candidate is Waterfox: version >= that > of Firefox in stable, the project has been going for awhile. > > Any of possible options, though, make me really sorry for anyone who > maintains a browser... :( It sounds like you're requesting that somebody other than you maintain yet another web browser. [1] https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.html#browser-security Jeremy Bicha
Re: Firefox 60esr on Stretch ?
On Thu, May 03, 2018 at 02:29:59PM +0200, Julien Cristau wrote: > On 05/03/2018 02:09 PM, Julien Aubin wrote: > > Firefox 60esr is due for next week. > > > > As of now Debian Stretch is bound to Firefox ESR 52 which reaches EOL > > soon. The problem is that it becomes less and less usable as more and > > more extensions are becoming incompatible with it. > > > > So what's the future of Firefox in stable ? Can we expect to have the > > 60esr release and if so, when, or will we stick w/ 52esr ? If needed I > > can test it alongside upgraded xul-ext packages if you put it in > > proposed-updates or on mozilla.debian.net. > > I expect nothing much different from previous ESR cycles: stretch will move > to 60 after 52 goes EOL in September. That's really, really out of what would be reasonable for a stable update. We'd need backports to stretch of multiple compilers, plenty of libraries. It would also break the entire XUL ecosystem. At this point, it'd be probably better to look into one of forks that claim security support, of those the only candidate is Waterfox: version >= that of Firefox in stable, the project has been going for awhile. Any of possible options, though, make me really sorry for anyone who maintains a browser... :( Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Certified airhead; got the CT scan to prove that! ⠈⠳⣄
Bug#897648: ITP: networking-bagpipe -- OpenStack virtual network service - BGP-based VPN
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: networking-bagpipe Version : 8.0.0 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/networking-bagpipe * License : Apache-2.0 Programming Lang: Python Description : OpenStack virtual network service - BGP-based VPN Neutron provides an API to dynamically request and configure virtual networks. These networks connect "interfaces" from other OpenStack services (such as vNICs from Nova VMs). The Neutron API supports extensions to provide advanced network capabilities, including QoS, ACLs, and network monitoring. . Driver and agent code to use BaGPipe lightweight implementation of BGP-based VPNs as a backend for Neutron. Note: This package is a build-dependency for networking-bgpvpn, itself needed to do gating in puppet-openstack upstream.
Re: Dealing with ci.d.n for package regressions
Hi Paul,
> And finally, thanks to all the people that helped and contributed to
> make this possible, 5 years after the initial announcement⁷.
First, thank you for pushing this!
Secondly, I was just wondering if you are collecting statistics
over what percentage of packages have autopkgtests, or, perhaps
more usefully which special/important packages have such tests?
I can hack together quick things like:
import psycopg2
import fileinput
NUM = 100
missing = set()
for x in fileinput.input():
xs = x.strip().split(' ', 6)
if xs[-1] == 'testsuite-autopkgtest-missing':
missing.add(xs[1])
conn = psycopg2.connect(
user='udd-mirror',
dbname='udd',
password='udd-mirror',
host='udd-mirror.debian.net',
)
cur = conn.cursor()
cur.execute('SELECT source FROM popcon_src '
'ORDER BY insts DESC LIMIT {}'.format(NUM))
print(' '.join(sorted({x[0] for x in cur} & missing)))
This returns:
$ wget -Olintian.gz
https://lintian.debian.org/resources/4b0282b7cc918d444724c9a7f1985bf486a39ab5c0a2793f7cddc7113a475cad.gz
$ gunzip lintian.gz
$ python3 script.py lintian
acl attr base-files base-passwd bash bsdmainutils busybox bzip2
coreutils cpio cron cyrus-sasl2 debconf debian-archive-keyring
debianutils dmidecode dpkg e2fsprogs expat file findutils
freetype gcc-6 gcc-7 gcc-8 gdbm gettext groff gzip hostname
initramfs-tools iputils klibc libedit libidn libselinux libsepol
libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl
libusb libx11 libxau libxdmcp libxext logrotate lsb lvm2 mawk
mime-support ncurses netbase newt openldap openssl pam pciutils
pcre3 perl popt popularity-contest procps python-defaults
readline sed shadow slang2 sqlite3 sysvinit tar tcp-wrappers
tzdata ucf wget zlib
ie. 75 out of "top" 100 packages according to popcon are missing
autopkgtests.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
Bug#897637: ITP: networking-bgpvpn -- OpenStack virtual network service - BGP VPN
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: networking-bgpvpn Version : 8.0.0 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/networking-bgpvpn * License : Apache-2.0 Programming Lang: Python Description : OpenStack virtual network service - BGP VPN Neutron provides an API to dynamically request and configure virtual networks. These networks connect "interfaces" from other OpenStack services (such as vNICs from Nova VMs). The Neutron API supports extensions to provide advanced network capabilities, including QoS, ACLs, and network monitoring. . This package provides an API and Framework to interconnect BGP/MPLS VPNs to Openstack Neutron networks, routers and ports. . The Border Gateway Protocol and Multi-Protocol Label Switching are widely used Wide Area Networking technologies. The primary purpose of this project is to allow attachment of Neutron networks and/or routers to VPNs built in carrier provided WANs using these standard protocols. An additional purpose of this project is to enable the use of these technologies within the Neutron networking environment. . A vendor-neutral API and data model are provided such that multiple SDN controllers may be used as backends, while offering the same tenant facing API. A reference implementation working along with Neutron reference drivers is also provided. Note: this package is being used in puppet-openstack, and therefore, I must make it available in Debian so that puppet-openstack CI can gate with it.
Bug#897633: ITP: bolt -- system daemon to manage thunderbolt 3 devices
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Owner: jbi...@debian.org Package Name: bolt Version: 0.3 Upstream Authors: Christian Kellner, Red Hat License : LGPL-2.1+ Programming Lang: C Homepage: https://gitlab.freedesktop.org/bolt/bolt Description: system daemon to manage thunderbolt 3 devices Thunderbolt 3 features different security modes that require devices to be authorized before they can be used. The D-Bus API can be used to list devices, enroll them (authorize and store them in the local database) and forget them again (remove previously enrolled devices). It also emits signals if new devices are connected (or removed). During enrollment devices can be set to be automatically authorized as soon as they are connected. A command line tool, called boltctl, can be used to control the daemon and perform all the above mentioned tasks. Other Info -- Required for GNOME integration with Thunderbolt. Initial GNOME Shell support is in GNOME 3.28 (in Buster). The GNOME Settings (gnome-control-center) integration will be in GNOME 3.30 which is scheduled for release in September. See https://christian.kellner.me/2018/04/23/the-state-of-thunderbolt-3-in-fedora-28/ Not many people have Thunderbolt 3 devices yet, so if you do, please let us know how well this feature works. Initial packaging was done by Sebastien Bacher in Ubuntu 18.04 LTS. I intend to help maintain this package under the Debian freedesktop.org team. Packaging is at https://salsa.debian.org/freedesktop-team/bolt Thanks, Jeremy Bicha
Re: Dealing with ci.d.n for package regressions
Ian Jackson:
> Paul Gevers writes ("Dealing with ci.d.n for package regressions"):
>> As I just announced on d-d-a¹, we have enabled autopkgtest usage for
>> unstable-to-testing migration.
>
> This is great.
>
> I have some suggestions/observations, looking particularly at
> https://release.debian.org/britney/update_excuses.html
>
Thanks for having a look at this. I will answer the two first items as
they are fairly "generic britney" questions.
Side note: We have some documentation at
https://release.debian.org/doc/britney/, which we are happy to receive
patches for.
The source code is: https://salsa.debian.org/release-team/britney2
(See the doc directory)
> 1. Often the heading says
>
> Migration status: BLOCKED: Rejected/introduces a regression (please
> see below)
>
> I think that here "regression" does not mean an autopkgtest
> regression, but rather a new bug regression ? That couldwording coudl
> perhaps be clarified.
>
This is a line summary of the over-all migration status, i.e. the
"worst" status across all policy decisions and rules applied to the package.
The particular case means that *a* policy has concluded that there was a
regression that will require manual fixing. This could be any of:
* RC bugs
* Piuparts
* autopkgtests (once it is in enforcing)
* ...
These messages come from:
https://salsa.debian.org/release-team/britney2/blob/master/britney2/excuse.py#L22
Suggestions for improvements are welcome.
Also, please note that the YAML variant of the excuses have a status per
policy besides the over-all status. (Details: Not every check has its
own policy, so the over-all status can in some cases be distinct from
the status of individual policies.)
Example from https://release.debian.org/britney/excuses.yaml:
> - excuses:
> [...]
> migration-policy-verdict: REJECTED_PERMANENTLY
> [...]
> policy_info:
> age:
> age-requirement: 5
> current-age: 8
> verdict: PASS
> autopkgtest:
> verdict: PASS
> build-depends:
> verdict: PASS
> piuparts:
> [...]
> verdict: REJECTED_PERMANENTLY
> rc-bugs:
> [...]
> verdict: PASS
> [...]
> source: gcc-8-cross
In this case, gcc-8-cross obtains the REJECT_PERMANENTLY status via the
piuparts policy (rather than the rc-bugs policy). Said status is the
one triggering the message "BLOCKED: Rejected/introduces a regression
..." (which you mentioned above).
> 2. "Not considered" has always been a bit opaque for me. It often
> appears when many things have obviously been considered. What things
> are not considered ?
>
I think it might make sense to sunset this phrase now that we have more
detailed status messages (the ones above). Basically, you get "Valid
Candidate" when the over all verdict is "OK" (PASS/PASS_* in the .yaml
file) and "Not considered" otherwise.
Thanks,
~Niels
Bug#897628: ITP: gobuster -- Directory/file & DNS busting tool written in Go
Package: wnpp Owner: Hilko Bengen Severity: wishlist * Package name: gobuster Version : 1.4.1 Upstream Author : OJ Reeves * URL or Web page : https://github.com/OJ/gobuster * License : Go Description : Directory/file & DNS busting tool written in Go The packaging work will be done by Alexander Fischer and I will sponsor the upload.
Re: Firefox 60esr on Stretch ?
On 2018-05-03 14:09:51 +0200 (+0200), Julien Aubin wrote: > As of now Debian Stretch is bound to Firefox ESR 52 which reaches > EOL soon. The problem is that it becomes less and less usable as > more and more extensions are becoming incompatible with it. > > On the other hand team mozilla.debian.net clearly states that > Firefox > 52 is not available on Stretch and all the xul-ext-* > packages will have to be upgraded. > > So what's the future of Firefox in stable ? Can we expect to have > the 60esr release and if so, when, or will we stick w/ 52esr ? If > needed I can test it alongside upgraded xul-ext packages if you > put it in proposed-updates or on mozilla.debian.net. There's also an inverse problem: a number of extensions haven't gotten around to porting (or can't be ported) from XUL to WebExtensions. Since support for "legacy" XUL-based extensions was entirely dropped between 52 and 60, users who were relying on any of them will cease to be able to do so and the corresponding packaged versions of them likely need to be dropped from the archive. https://blog.mozilla.org/addons/2017/10/03/legacy-add-on-support-on-firefox-esr/ -- Jeremy Stanley signature.asc Description: PGP signature
Re: filing bug reports for GCC 8 build failures
On 03/05/2018 09:51, Matthias Klose wrote: > On 03.05.2018 09:03, Alastair McKinstry wrote: >> On 03/05/2018 08:43, Matthias Klose wrote: >> >>> On 03.05.2018 07:29, Alastair McKinstry wrote: Hi, FTBFS bugs haveveen filed for packages that fail under gcc8. >>> I didn't file any, and I didn't see any being filed. Which ones do you mean? >> They were filed by Lucas Nussbaum, e.g. #897518, #897507, >> these use grib_api.mod from libeccodes-dev. >> These fail because they need eccodes-dev to be built with gfortran8. >> >> Others will use netcdf.mod , etc. > I can't see any gfortran-8 involvement for these issues. My error, sorry (but we still need to plan the gfortran-8 transition). What happened here is that I moved the .mod file in libeccodes-dev to /usr/include/$ARCH, to make the package multi-arch capable. While gcc looks there for header files, gfortran does _not_, which is inconsistent and a challenge. Is this deliberate, or will a patch to multiarch-enable gfortran be accepted ? -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Re: Firefox 60esr on Stretch ?
El jue., 3 de may. de 2018 a la(s) 11:06, Julien Aubin < julien.au...@gmail.com> escribió: > > > Le jeu. 3 mai 2018 à 14:41, eamanu15 a écrit : > >> Hello Julien, >> >> Maybe this question need to be made on debian-metors or >> pkg-mozilla-maintainer list. >> >> I think will be good wait until EOL before change to 60. I think that >> the first months of 60ers will be a little unstable. >> >> Regards! >> > > I tried but mozilla maintainers ML looks dead. :'( > > Anyway I'm available for testing ! > Great. Let me know if you need help never test mozilla, and I want to learn about it. Thanks > > > >> >> El jue., 3 de may. de 2018 a la(s) 10:30, Julien Cristau < >> jcris...@debian.org> escribió: >> >>> On 05/03/2018 02:09 PM, Julien Aubin wrote: >>> > Hi >>> > >>> > Firefox 60esr is due for next week. >>> > >>> > As of now Debian Stretch is bound to Firefox ESR 52 which reaches EOL >>> > soon. The problem is that it becomes less and less usable as more and >>> > more extensions are becoming incompatible with it. >>> > >>> > On the other hand team mozilla.debian.net clearly states that Firefox >>> >> 52 is not available on Stretch and all the xul-ext-* packages will >>> > have to be upgraded. >>> > >>> > So what's the future of Firefox in stable ? Can we expect to have the >>> > 60esr release and if so, when, or will we stick w/ 52esr ? If needed I >>> > can test it alongside upgraded xul-ext packages if you put it in >>> > proposed-updates or on mozilla.debian.net. >>> > >>> debian-devel is the wrong place for your questions. >>> >>> I expect nothing much different from previous ESR cycles: stretch will >>> move to 60 after 52 goes EOL in September. >>> >>> Cheers, >>> Julien >>> >>> -- >> Arias Emmanuel >> https://www.linkedin.com/in/emmanuel-arias-437a6a8a >> http://eamanu.com >> > -- Arias Emmanuel https://www.linkedin.com/in/emmanuel-arias-437a6a8a http://eamanu.com
Re: Firefox 60esr on Stretch ?
On Thu, May 03, 2018 at 02:29:59PM +0200, Julien Cristau wrote: > On 05/03/2018 02:09 PM, Julien Aubin wrote: > > Hi > > > > Firefox 60esr is due for next week. > > > > As of now Debian Stretch is bound to Firefox ESR 52 which reaches EOL > > soon. The problem is that it becomes less and less usable as more and > > more extensions are becoming incompatible with it. > > > > On the other hand team mozilla.debian.net clearly states that Firefox > > > 52 is not available on Stretch and all the xul-ext-* packages will > > have to be upgraded. > > > > So what's the future of Firefox in stable ? Can we expect to have the > > 60esr release and if so, when, or will we stick w/ 52esr ? If needed I > > can test it alongside upgraded xul-ext packages if you put it in > > proposed-updates or on mozilla.debian.net. > > > debian-devel is the wrong place for your questions. > > I expect nothing much different from previous ESR cycles: stretch will move > to 60 after 52 goes EOL in September. ... as long as we get the required compilers in stretch in time... Mike
Re: Firefox 60esr on Stretch ?
Hello Julien, Maybe this question need to be made on debian-metors or pkg-mozilla-maintainer list. I think will be good wait until EOL before change to 60. I think that the first months of 60ers will be a little unstable. Regards! El jue., 3 de may. de 2018 a la(s) 10:30, Julien Cristau < jcris...@debian.org> escribió: > On 05/03/2018 02:09 PM, Julien Aubin wrote: > > Hi > > > > Firefox 60esr is due for next week. > > > > As of now Debian Stretch is bound to Firefox ESR 52 which reaches EOL > > soon. The problem is that it becomes less and less usable as more and > > more extensions are becoming incompatible with it. > > > > On the other hand team mozilla.debian.net clearly states that Firefox > >> 52 is not available on Stretch and all the xul-ext-* packages will > > have to be upgraded. > > > > So what's the future of Firefox in stable ? Can we expect to have the > > 60esr release and if so, when, or will we stick w/ 52esr ? If needed I > > can test it alongside upgraded xul-ext packages if you put it in > > proposed-updates or on mozilla.debian.net. > > > debian-devel is the wrong place for your questions. > > I expect nothing much different from previous ESR cycles: stretch will > move to 60 after 52 goes EOL in September. > > Cheers, > Julien > > -- Arias Emmanuel https://www.linkedin.com/in/emmanuel-arias-437a6a8a http://eamanu.com
Re: Firefox 60esr on Stretch ?
On 05/03/2018 02:09 PM, Julien Aubin wrote: Hi Firefox 60esr is due for next week. As of now Debian Stretch is bound to Firefox ESR 52 which reaches EOL soon. The problem is that it becomes less and less usable as more and more extensions are becoming incompatible with it. On the other hand team mozilla.debian.net clearly states that Firefox 52 is not available on Stretch and all the xul-ext-* packages will have to be upgraded. So what's the future of Firefox in stable ? Can we expect to have the 60esr release and if so, when, or will we stick w/ 52esr ? If needed I can test it alongside upgraded xul-ext packages if you put it in proposed-updates or on mozilla.debian.net. debian-devel is the wrong place for your questions. I expect nothing much different from previous ESR cycles: stretch will move to 60 after 52 goes EOL in September. Cheers, Julien
Firefox 60esr on Stretch ?
Hi Firefox 60esr is due for next week. As of now Debian Stretch is bound to Firefox ESR 52 which reaches EOL soon. The problem is that it becomes less and less usable as more and more extensions are becoming incompatible with it. On the other hand team mozilla.debian.net clearly states that Firefox > 52 is not available on Stretch and all the xul-ext-* packages will have to be upgraded. So what's the future of Firefox in stable ? Can we expect to have the 60esr release and if so, when, or will we stick w/ 52esr ? If needed I can test it alongside upgraded xul-ext packages if you put it in proposed-updates or on mozilla.debian.net. Thanks and rgds, Julien.
Re: autopkgtest results influencing migration from unstable to testing
Colin Watson writes ("Re: autopkgtest results influencing migration from
unstable to testing"):
> On Thu, May 03, 2018 at 07:14:16AM +0200, Paul Gevers wrote:
> > In my perception, the biggest reason is a social one. The is resistance
> > to the fact that issues with autopkgtests out of one's control can block
> > one's package (this is quite different than in Ubuntu).
>
> Can you elaborate on how this is different than in Ubuntu? It sounds
> pretty similar to me, except for being a delay instead of a block. Or
> did you mean that the social consequences are different?
The key difference is in Paul's sentence "out of one's control".
In Ubuntu, any developer may go and fix any package, without
formality. In Debian fixing "someone else's" package is often hedged
about with bureaucracy or even discouraged.
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: autopkgtest results influencing migration from unstable to testing
Paul Gevers writes ("Re: autopkgtest results influencing migration from
unstable to testing"):
> On 03-05-18 04:32, Simon Quigley wrote:
> > opinion, passing autopkgtests should be a release migration requirement,
> > and not just with my Ubuntu hat on (because it has a correlation to
> > higher quality packages).
>
> In my perception, the biggest reason is a social one. The is resistance
> to the fact that issues with autopkgtests out of one's control can block
> one's package (this is quite different than in Ubuntu). There is some
> fear that buggy autopkgtests in reverse dependencies of major packages
> will just mean more work for the maintainers of those packages. We'll
> need to iron those out (the buggy autopktests and the fear) and show
> that we can robustly handle it as a project.
Yes. I very much want this to be blocking, but this has been a decade
in the making. We can wait a little longer. There is absolutely no
need to make a big and disruptive change right away.
One change that will have to come soon is that I think that *flaky*
(rather than merely always-failing) autopkgtests are going to have to
be treated as an RC bug.
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: Dealing with ci.d.n for package regressions
Paul Gevers writes ("Dealing with ci.d.n for package regressions"):
> As I just announced on d-d-a¹, we have enabled autopkgtest usage for
> unstable-to-testing migration.
This is great.
I have some suggestions/observations, looking particularly at
https://release.debian.org/britney/update_excuses.html
1. Often the heading says
Migration status: BLOCKED: Rejected/introduces a regression (please
see below)
I think that here "regression" does not mean an autopkgtest
regression, but rather a new bug regression ? That couldwording coudl
perhaps be clarified.
2. "Not considered" has always been a bit opaque for me. It often
appears when many things have obviously been considered. What things
are not considered ?
3. "Required age increased by 10 days because of autopkgtest"
seems to appear when either (i) when there are tests that should be
run but which haven't completed and (ii) when some tests newly failed ?
I wasn't able to see any examples of the latter.
4. Can we have a way to trigger tests from updates of non-direct
rdepends ? At some point in the future maybe we will run tests of
whole batches of updates and then have some algorithm to chop out
what the failures are caused by, but for now it would be useful to
be able to declare a specific indirect dependency for test trigger.
Maybe an XS- header field ?
5. AIUI there is no automatic way for the maintainers of the
rdependency to be notified of a test failure which is blocking
migration of one of their dependencies. Is that right ? The result
is probably that if the maintainers of the dependency don't follow it
up, the regression will migrate and the rdepenency maintainers will be
left to fix it up.
6. This is really one for the wider project: as the blocking time
increases, we are going to want some more relaxed rules for NMUing one
of your rdependencies. (Right now that would be pointless since you'd
upload it to DELAYED/10 and it would hardly migrate before your own
timeout anyway.)
Ian.
Re: autopkgtest results influencing migration from unstable to testing
Paul Gevers writes ("autopkgtest results influencing migration from unstable to
testing"):
> tl;dr: migration from unstable to testing is influenced by the results
> of autopkgtest tests of your own package as well as those of your
> reverse dependencies.
AWESOME
Thank you to everone who worked on this!
Ian.
Re: autopkgtest results influencing migration from unstable to testing
On 3 May 2018 at 11:21, Colin Watson wrote: > > (I echo Simon's thanks for doing this, though!) > Yeah, thanks for this! I would say, yeah, please wait a couple of stable releases before going full blocker. I (and others) may not have the time to polish our autopkgtest tests. If we end with less autopkgtests tests because of this, then the result of this push would be the opposite of what we intended :-P
Re: autopkgtest results influencing migration from unstable to testing
On Thu, May 03, 2018 at 07:14:16AM +0200, Paul Gevers wrote: > On 03-05-18 04:32, Simon Quigley wrote: > > What is the reasoning for not making these blocking sooner? In my honest > > opinion, passing autopkgtests should be a release migration requirement, > > and not just with my Ubuntu hat on (because it has a correlation to > > higher quality packages). > > In my perception, the biggest reason is a social one. The is resistance > to the fact that issues with autopkgtests out of one's control can block > one's package (this is quite different than in Ubuntu). Can you elaborate on how this is different than in Ubuntu? It sounds pretty similar to me, except for being a delay instead of a block. Or did you mean that the social consequences are different? (I echo Simon's thanks for doing this, though!) -- Colin Watson [cjwat...@debian.org]
Re: filing bug reports for GCC 8 build failures
On 03.05.2018 09:03, Alastair McKinstry wrote: > On 03/05/2018 08:43, Matthias Klose wrote: > >> On 03.05.2018 07:29, Alastair McKinstry wrote: >>> Hi, >>> >>> FTBFS bugs haveveen filed for packages that fail under gcc8. >> I didn't file any, and I didn't see any being filed. Which ones do you mean? > They were filed by Lucas Nussbaum, e.g. #897518, #897507, > these use grib_api.mod from libeccodes-dev. > These fail because they need eccodes-dev to be built with gfortran8. > > Others will use netcdf.mod , etc. I can't see any gfortran-8 involvement for these issues.
Bug#897584: ITP: ruby-marcel -- Simple mime type detection
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: ruby-marcel Version : 0.3.2 Upstream Author : 2017 Tom Ward * URL : https://github.com/basecamp/marcel * License : Expat Description : Simple mime type detection Marcel attempts to choose the most appropriate content type for a given file by looking at the binary data, the filename, and any declared type (perhaps passed as a request header). . By preference, the magic number data in any passed in file is used to determine the type. If this doesn't work, it uses the type gleaned from the filename, extension, and finally the declared type. If no valid type is found in any of these, "application/octet-stream" is returned. . Some types aren't easily recognised solely by magic number data. For example Adobe Illustrator files have the same magic number as PDFs (and can usually even be viewed in PDF viewers!). For these types, Marcel uses both the magic number data and the file name to work out the type. signature.asc Description: OpenPGP digital signature
Re: filing bug reports for GCC 8 build failures
On 03/05/2018 08:43, Matthias Klose wrote: > On 03.05.2018 07:29, Alastair McKinstry wrote: >> Hi, >> >> FTBFS bugs haveveen filed for packages that fail under gcc8. > I didn't file any, and I didn't see any being filed. Which ones do you mean? They were filed by Lucas Nussbaum, e.g. #897518, #897507, these use grib_api.mod from libeccodes-dev. These fail because they need eccodes-dev to be built with gfortran8. Others will use netcdf.mod , etc. -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Re: Announce: docker-buildpackage
Chow Loong Jin [2018-05-03 12:27 +0800]: > On Wed, May 02, 2018 at 11:23:56AM +0200, Thomas Goirand wrote: > > [...] > > Frankly, I don't see the point in writing this kind of software. Sbuild > > works super well with the overlay backend, and already has throw-able > > chroots in tmpfs. Adding docker into this doesn't add any new feature, > > and in some way, is less flexible than the already existing sbuild. > > Something that comes to mind is network isolation, which sbuild still > doesn't seem to have proper support[1] for: > > [1] > https://wiki.debian.org/sbuild#Disabling_network_access_for_dpkg-buildpackage Not just network, but also process isolation and reducing privileges. schroot would be way too "leaky" for a production CI system like ci.debian.net or autopkgtest.ubuntu.com. The existing backend that compare much better to that are -lxc and -lxd, and IMHO they are superior to docker. lxc and lxd are "full OS" containers while docker is optimized for application containers and thus needs some special treatment (like --privileged, which makes the whole thing rather unsafe and often causes crashes if you try to start udev in the docker container) to allow really booting a full OS. Usability wise, they are just as simple as docker too, as linuxcontainers.org has a lot of pre-built OS images for all kinds of OSes. So I agree that there is very little point about adding a docker backend other than "it's possible" (albeit inferior). As long as someone wants to maintain it, there is little harm in including it. Martin signature.asc Description: PGP signature
