Bug#943307: hurd: build-dependency unsatisfiable
Source: hurd Version: 1:0.9.git20190331-8 Tag: ftbfs User: trei...@debian.org Usertags: edos-uninstallable Severity: serious Hi, hurd build-depends on libc0.3-dev, which does not exist in the archive on any release architecture. -Ralf.
Bug#943306: rust-cargo-lichking: build-dependency not satisfiable
Source: rust-cargo-lichking Version: 0.7.0-1 Tags: ftbfs Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, rust-cargo-lichking build-depends on librust-cargo-0.32+default-dev, which doesn't exist in the archive. -Ralf.
Bug#943305: golang-github-bradfitz-http2: build-depends not satisfiable
Source: golang-github-bradfitz-http2 Version: 0.0~git20150509-2 Severity: serious Tags: ftbfs User: trei...@debian.org Usertags: edos-uninstallable Hi, golang-github-bradfitz-http2 build-depends on golang-go.crypto-dev, which only exists in old[old]stable. -Ralf.
Bug#942451: mirror submission for mirror.ufro.cl
Hello! I updated ftpsync and the trace file should have the required information now. Please check it out and tell me if there's still something else that needs to be fixed. About the nameservers, sadly, that's not in my hands, but I'll ask about that to the right people anyway. Kind regards, Jonathan. -- La información contenida en este correo electrónico y cualquier anexo o respuesta relacionada, puede contener datos e información confidencial y no puede ser usada o difundida por personas distintas a su(s) destinatario(s). Si usted no es el destinatario de esta comunicación, le informamos que cualquier divulgación, distribución o copia de esta información constituye un delito conforme a la ley chilena. Si lo ha recibido por error, por favor borre el mensaje y todos sus anexos y notifique al remitente.
Bug#942654: Bug#940872: KDE Frameworks 5.62 coming to unstable
I had already tried this approach for disable numlock but does not work. I solved it only by running numlockx in the auto-start directory (after the kde desktop was started).
Bug#933025: ldtp: Porting to python3, or removing?
On Fri, Jul 26, 2019 at 1:48 AM Paul Gevers wrote: > On 25-07-2019 21:49, Samuel Thibault wrote: > > python2 is being phased out, so something needs to be done for ldtp. The > > upstream mailing list has been very inactive for a long time. Will there > > really be interest in porting it to python3? Or should we just remove > > ldtp from Debian? (it has no rdep) > > While this is true, Debian will carry Python 2 in bullseye if needed, > see https://bugs.debian.org/931659#17. So don't remove it just yet (but > investigating if it's worth porting is very valuable of course). I have update. Upstream has no plan or time to port ldtp to Python3, so I just did request for removal. See: #943304 -- Kartik Mistry | કાર્તિક મિસ્ત્રી kartikm.wordpress.com
Bug#943146: orca: Python2 removal in sid/bullseye
Hello, mo...@debian.org, le mer. 23 oct. 2019 02:33:30 +, a ecrit: > Your package either build-depends, depends on Python2, or uses Python2 > in the autopkg tests (the specific reason can be found searching this > source package in > https://people.debian.org/~morph/mass-bug-py2removal_take2.txt ). orca 3.34.0-2 ['Build-Depends->python-gi-dev'] This looks like a false positive: $ dpkg -L python-gi-dev /. /usr /usr/include /usr/include/pygobject-3.0 /usr/include/pygobject-3.0/pygobject.h /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/pkgconfig /usr/lib/x86_64-linux-gnu/pkgconfig/pygobject-3.0.pc /usr/share /usr/share/doc /usr/share/doc/python-gi-dev /usr/share/doc/python-gi-dev/changelog.Debian.gz /usr/share/doc/python-gi-dev/changelog.gz /usr/share/doc/python-gi-dev/copyright There is nothing python2-specific here. Samuel
Bug#942768: lcl-units-2.0: file conflict with lazarus-src-2.0 (versin 2.0.2+dfsg-5)
Package: lazarus Version: 2.0.2+dfsg-6 Followup-For: Bug #942768 Hello, I was upgrading to 2.0.2+dfsg-6 and I am still getting the file conflict: dpkg: error processing archive /var/cache/apt/archives/lazarus- src-2.0_2.0.2+dfsg-6_all.deb (--unpack): trying to overwrite '/usr/lib/lazarus/2.0.2/components/IdeInspector/ideinspector.lpk', which is also in package lcl-units-2.0 2.0.2+dfsg-6 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/vlc/lazvlc.lpk to /usr/lib/lazarus/2.0.2/components/vlc/lazvlc.lpk.orig by lazarus-src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/externhelp/externhelp.lpk to /usr/lib/lazarus/2.0.2/components/externhelp/externhelp.lpk.orig by lazarus- src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/sparta/dockedformeditor/sparta_dockedformeditor.lpk to /usr/lib/lazarus/2.0.2/components/sparta/dockedformeditor/sparta_dockedformeditor.lpk.orig by lazarus-src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/sparta/mdi/sparta_mdi.lpk to /usr/lib/lazarus/2.0.2/components/sparta/mdi/sparta_mdi.lpk.orig by lazarus- src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/sparta/smartformeditor/sparta_smartformeditor.lpk to /usr/lib/lazarus/2.0.2/components/sparta/smartformeditor/sparta_smartformeditor.lpk.orig by lazarus-src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/sparta/toolsapi/sparta_toolsapi.lpk to /usr/lib/lazarus/2.0.2/components/sparta/toolsapi/sparta_toolsapi.lpk.orig by lazarus-src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/sparta/generics/sparta_generics.lpk to /usr/lib/lazarus/2.0.2/components/sparta/generics/sparta_generics.lpk.orig by lazarus-src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/lazdebuggergdbmi/lazdebuggergdbmi.lpk to /usr/lib/lazarus/2.0.2/components/lazdebuggergdbmi/lazdebuggergdbmi.lpk.orig by lazarus-src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/lazdebuggergdbmi/test/gdbmitestutils/gdbmitestutils.lpk to /usr/lib/lazarus/2.0.2/components/lazdebuggergdbmi/test/gdbmitestutils/gdbmitestutils.lpk.orig by lazarus-src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/mouseandkeyinput/lazmouseandkeyinput.lpk to /usr/lib/lazarus/2.0.2/components/mouseandkeyinput/lazmouseandkeyinput.lpk.orig by lazarus-src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/chmhelp/packages/idehelp/chmhelppkg.lpk to /usr/lib/lazarus/2.0.2/components/chmhelp/packages/idehelp/chmhelppkg.lpk.orig by lazarus-src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/chmhelp/packages/help/lhelpcontrolpkg.lpk to /usr/lib/lazarus/2.0.2/components/chmhelp/packages/help/lhelpcontrolpkg.lpk.orig by lazarus-src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/fppkg/src/fppkgpackagemanager.lpk to /usr/lib/lazarus/2.0.2/components/fppkg/src/fppkgpackagemanager.lpk.orig by lazarus-src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/anchordocking/design/anchordockingdsgn.lpk to /usr/lib/lazarus/2.0.2/components/anchordocking/design/anchordockingdsgn.lpk.orig by lazarus-src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/anchordocking/anchordocking.lpk to /usr/lib/lazarus/2.0.2/components/anchordocking/anchordocking.lpk.orig by lazarus-src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/pas2js/pas2jsdsgn.lpk to /usr/lib/lazarus/2.0.2/components/pas2js/pas2jsdsgn.lpk.orig by lazarus- src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/fpweb/lazwebextra.lpk to /usr/lib/lazarus/2.0.2/components/fpweb/lazwebextra.lpk.orig by lazarus- src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/fpweb/weblaz.lpk to /usr/lib/lazarus/2.0.2/components/fpweb/weblaz.lpk.orig by lazarus-src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/cairocanvas/cairocanvas_pkg.lpk to /usr/lib/lazarus/2.0.2/components/cairocanvas/cairocanvas_pkg.lpk.orig by lazarus-src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/projecttemplates/projtemplates.lpk to /usr/lib/lazarus/2.0.2/components/projecttemplates/projtemplates.lpk.orig by lazarus-src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/fpcunit/console/fpcunitconsolerunner.lpk to /usr/lib/lazarus/2.0.2/components/fpcunit/console/fpcunitconsolerunner.lpk.orig by lazarus-src-2.0', none removed. No diversion 'diversion of /usr/lib/lazarus/2.0.2/components/fpcunit/fpcunittestrunner.lpk to /usr/lib/lazarus/2.0.2/components/fpcunit/fpcunittestrunner.lpk.orig
Bug#943304: RM: ldtp -- ROM; Upstream has no plan to maintain, (Going to be) RC buggy
Package: ftp.debian.org Severity: normal ldtp is Python2 only and after discussing with upstream it turned out that they don't have any plan to port it to Python3. I don't have any time to maintain it as upstream. So, it is better to remove ldtop from Debian until someone ports. I can reintroduce package then. Thanks. -- Kartik Mistry | કાર્તિક મિસ્ત્રી kartikm.wordpress.com
Bug#943300: xpra: Python2 removal in sid/bullseye
On Wednesday, 23 October 2019 1:33:35 PM AEDT mo...@debian.org wrote: > Source: xpra > Usertags: py2removal > > Your package either build-depends, depends on Python2, or uses Python2 > in the autopkg tests Are you sure this is not a false-positive?? Xpra is already fully converted to Python3 and I can't find any references to Python2 whatsoever. -- All the best, Dmitry Smirnov. --- No snowflake in an avalanche ever feels responsible. -- Stanisław Jerzy Lec signature.asc Description: This is a digitally signed message part.
Bug#939091: ITP: libcore-java -- Core barcode encoding/decoding library
On Sun, Sep 01, 2019 at 10:06:31AM +0200, Mechtilde Stehmann wrote: > Package: wnpp > Severity: wishlist > * Package name: libzxing-core-java > Version : 3.4.0 > Upstream Author : Jeremias Maerki, ZXing authors > * URL : http://central.maven.org/maven2/com/google/zxing/core Hi Mechtilde, Instead of using the sources.jar from Maven Central, is there a reason that we shouldn't use this repo to build the core module? https://github.com/zxing/zxing The project is active which could be useful for support. Thanks, tony signature.asc Description: PGP signature
Bug#943051: closed by Nicholas Breen (Re: [Debichem-devel] Bug#943051: gromacs: Python2 removal in sid/bullseye)
On Tue, Oct 22, 2019 at 11:06:01PM -0400, Sandro Tosi wrote: > Hello Nicholas, > any specific reason to wait this long? it would be very helpful if > there's a chance for you to speed up the upload to unstable, so that > we can reduce the number of packages needing python2 in unstable soon, > and better assess the situation we are in, and if we can actually > remove py2 during bullseye development cycle. thanks for your > understanding! Hi Sandro, Only that the fixes are in the beta branch for the next upstream release, and it's scheduled for a stable release in January. Also, right now the experimental build fails on four release architectures (and 11 port architectures!), so it's not quite ready for an upload to unstable, if it can't later migrate to testing. I haven't looked into the upstream code changes yet, but there was only one specific part of the documentation build that relied on python2 in the earlier versions - I'll see if I can backport that more quickly. - Nicholas
Bug#940872: KDE Frameworks 5.62 coming to unstable
On donderdag 26 september 2019 22:56:08 CEST Bob Weber wrote: > Another trick that worked on 2 machines here is to set the numlock on in > /etc/sddm.conf. > > My general section of sddm.conf looks like this now: > > [General] > HaltCommand= > RebootCommand= > Numlock=on > > Hope this helps. This fixed the issue I had which I mentioned in the CC-ed bug reports. Thanks :-) signature.asc Description: This is a digitally signed message part.
Bug#943051: closed by Nicholas Breen (Re: [Debichem-devel] Bug#943051: gromacs: Python2 removal in sid/bullseye)
Hello Nicholas, any specific reason to wait this long? it would be very helpful if there's a chance for you to speed up the upload to unstable, so that we can reduce the number of packages needing python2 in unstable soon, and better assess the situation we are in, and if we can actually remove py2 during bullseye development cycle. thanks for your understanding! On Tue, Oct 22, 2019 at 10:59 PM Debian Bug Tracking System wrote: > > This is an automatic notification regarding your Bug report > which was filed against the src:gromacs package: > > #943051: gromacs: Python2 removal in sid/bullseye > > It has been closed by Nicholas Breen . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Nicholas Breen > by > replying to this email. > > > -- > 943051: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943051 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > > > -- Forwarded message -- > From: Nicholas Breen > To: 943051-d...@bugs.debian.org > Cc: > Bcc: > Date: Tue, 22 Oct 2019 19:48:26 -0700 > Subject: Re: [Debichem-devel] Bug#943051: gromacs: Python2 removal in > sid/bullseye > Version: 2020~beta1-1 > > On Wed, Oct 23, 2019 at 02:33:26AM +, mo...@debian.org wrote: > > Source: gromacs > > Version: 2019.4-1 > > Severity: normal > > Tags: sid bullseye > > User: debian-pyt...@lists.debian.org > > Usertags: py2removal > > > > Python2 becomes end-of-live upstream, and Debian aims to remove > > Python2 from the distribution, as discussed in > > https://lists.debian.org/debian-python/2019/07/msg00080.html > > Fixed in experimental, will probably move to unstable in January. > > > -- Forwarded message -- > From: mo...@debian.org > To: mainto...@bugs.debian.org > Cc: > Bcc: > Date: Wed, 23 Oct 2019 02:33:26 + > Subject: gromacs: Python2 removal in sid/bullseye > Source: gromacs > Version: 2019.4-1 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal > > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html > > Your package either build-depends, depends on Python2, or uses Python2 > in the autopkg tests (the specific reason can be found searching this > source package in > https://people.debian.org/~morph/mass-bug-py2removal_take2.txt ). > Please stop using Python2, and fix this issue by one of the following > actions. > > - Convert your Package to Python3. This is the preferred option. In > case you are providing a Python module foo, please consider dropping > the python-foo package, and only build a python3-foo package. Please > don't drop Python2 modules, which still have reverse dependencies, > just document them. > > This is the preferred option. > > - If the package is dead upstream, cannot be converted or maintained > in Debian, it should be removed from the distribution. If the > package still has reverse dependencies, raise the severity to > "serious" and document the reverse dependencies with the BTS affects > command. If the package has no reverse dependencies, confirm that > the package can be removed, reassign this issue to ftp.debian.org, > make sure that the bug priority is set to normal and retitle the > issue to "RM: PKG -- removal triggered by the Python2 removal". > > - If the package has still many users (popcon >= 300), or is needed to > build another package which cannot be removed, document that by > adding the "py2keep" user tag (not replacing the py2remove tag), > using the debian-pyt...@lists.debian.org user. Also any > dependencies on an unversioned python package (python, python-dev) > must not be used, same with the python shebang. These have to be > replaced by python2/python2.7 dependencies and shebang. > > This is the least preferred option. > > If there are questions, please refer to the wiki page for the removal: > https://wiki.debian.org/Python/2Removal, or ask for help on IRC > #debian-python, or the debian-pyt...@lists.debian.org mailing list. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Bug#942756: cme: please provide more description of the format of d/fix.scanned.copyright
Control: tags -1 patch On Mon, Oct 21, 2019 at 05:17:59PM +0200, Dominique Dumont wrote: > The data contained in debian/copyright is mapped to a tree structure inside > cme. You can have a view of this structure by running 'cme dump dpkg- > copyright' or get a graphical view with 'cme edit dpkg-copyright' > > The instructions specified in fix.scanned.copyright are steps to walk in that > tree and alter the values when specified. Aha, now this is coming together. > > Things that I'd find helpful: > > - what is the general form of these lines? If that's too complex, examples > > covering more use-cases would be helpful. > > In fact, I've found that tweaking debian/fill.copyright.blanks.yml often > provide better results. All in all, I've found very few cases where tweaking > d/fix.scanned.copyright provided better results than tweaking debian/ > fill.copyright.blanks.yml Makes sense - though am I correct to think that fix.scanned.copyright is for fixing extractions that include html entities, weird chars from upstream, etc? > I understand that Config::Model::Loader synopsis is for only for Perl > programmer. > > On the other hand, the "load string syntax" section was intended to provide > instructions usable for non-perl programmers. Was that section overwhelming > as well ? It was originally, but after your message, it's much more clear. There's not nearly as much to learn as it originally looked like. > In any case, I may need to split this man page... What do you think ? No, I don't think that's necessary anymore. Maybe a few more words of description, and some pointers to the Config::Model::Loader section. Possible patches are attached that use the explanations you sent me. Ross diff --git a/lib/App/Cme/Command/update.pm b/lib/App/Cme/Command/update.pm index b4a36ea..997cc3d 100644 --- a/lib/App/Cme/Command/update.pm +++ b/lib/App/Cme/Command/update.pm @@ -103,6 +103,13 @@ Update a configuration file. The update is done scanning external resource. For the update of dpkg-copyright is done by scanning the headers of source files. (Actually, only dpkg-copyright model currently supports updates) +The data contained in debian/copyright is mapped to a tree structure inside cme. You can have +a view of this structure by running 'cme dump dpkg-copyright' or get a graphical view with +'cme edit dpkg-copyright'. + +Sometimes the output will need adjusting. See the section "Tweak results" in +Config::Model::Dpkg::Copyright for ways to control cme's output. + Example: cme update dpkg-copyright diff --git a/lib/Config/Model/Dpkg/Copyright.pm b/lib/Config/Model/Dpkg/Copyright.pm index 961cc360..272734c0 100644 --- a/lib/Config/Model/Dpkg/Copyright.pm +++ b/lib/Config/Model/Dpkg/Copyright.pm @@ -423,8 +423,14 @@ based on comments, the result is sometimes lackluster. Your may specify instruction to alter or set specific copyright entries in C file (or C<< debian/.fix.scanned.copyright >>). -Each line of this file will be handled -by L to modify copyright information. + +cme stores the copyright information in a tree. Entries in +fix.scanned.copyright provide instructions for traversing the cme tree +and modifying entries. You can have a view of debian/copyright file +translated in this syntax by running 'cme dump --format cml +dpkg-copyright'. Each line of this file will be handled by +L to modify copyright information; the full +syntax is documented in the "load string syntax" section. =head2 Example @@ -464,6 +470,12 @@ Here's another more complex example: # and modify the copyright entry with a Perl substitution ! Files:~/^3rdparty/ Copyright=~s/@/(at)/ +Sometimes, you might want to find an entry that spans multiple lines. +You can do this by double quoting the whole value: + + ! Files:"uulib/crc32.h + uulib/uustring.h" Copyright="2019 John Doe" + =head1 Under the hood This section explains how cme merges the information from the existing
Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5
On Wed 2019-10-23 01:28:42 +0200, Thomas Schmitt wrote: > Daniel Kahn Gillmor wrote: >> but it's known to be relatively easy to find collisions in MD5. > > It is suspected that it is possible to construct byte strings which > produce a desired particular MD5 value. I think you're describing a preimage attack. I was talking about a collision attack, which is significantly easier to perform than a preimage attack. For MD5, it is not "suspected" to be a problem, it is closer to "can be done in less than a second on scavenged hardware". For more details, see https://eprint.iacr.org/2013/170.pdf > But when matching the lines of two tables by a key you have to consider > hash table theory and especially the birthday paradox. A short excursion > on wikipedia lets me estimate that the chance for a MD5 collision among > 1 billion .deb files is about 1 - e exp -1e-20. > Regrettably i found no calculator which would not say 0 as result. Sorry, i'm not following this argument. We're not talking about random chance -- we're talking about adversarial attack. > The cryptographic check is to be done on .jigdo and .template before > the run of jigdo-lite, and on .iso afterwards. If "cryptographic check" means "OpenPGP signature verification" then i agree that MD5 isn't relevant here. But i don't think that jigdo actually does that check, does it? If "cryptographic check" refers to verification of the MD5sum, then it's a mistake to use MD5 in 2019. If the idea is that MD5 is used for speed, full SHA256 is indeed a bit slower than MD5 ("openssl speed md5 sha256" suggests to me that SHA256 operations take roughly twice as long as MD5 operations). But unless you're on a blazing fast Internet connection, the delay of downloading is likely much much larger than the computational cost of sha256. (and if you're on a blazing fast Internet connection, you probably don't need jigdo anyway) > Steve. You should now face your critics. I did what i could as lowly user > of Debian and disorganized upstream of xorriso. I don't think you're "lowly" at all, Thomas! And i'm not a "critic" of Steve's. This discussion isn't meant to be personal in any way. I really appreciate the work you've done (and continue to do) on xorriso, and i appreciate the work Steve has done (and continues to do) across the entire Debian project :) But I'm concerned that jigdo's lack of maintenance has negative effects on the rest of the debian ecosystem, and i'd really like to get that cleaned up one way or another. If there are a lot of active users of jigdo, then there needs to be comparably active maintenance. If there aren't a lot of users (or if other techniques for mirroring optical media, like bittorrent, are better-maintained), then maybe it's time to retire jigdo and let people use their limited energies on other projects. Regards, --dkg signature.asc Description: PGP signature
Bug#942903: libbpf library is from kernel source
Package: libbpf-dev Version: 5.3.7-1 Severity: wishlist Hi, libbpf-dev is currently packaged from kernel sources. Please consider switching to GH mirror [1] so there are following advantages: - Versioning is consistent with ABI - GH mirror has CI tests - Be consistent w/ other distros, e.g. Fedora which has already switched to GH mirror in [2] The whole rationale is in [3] Thanks! [1] https://github.com/libbpf/libbpf [2] https://bugzilla.redhat.com/show_bug.cgi?id=1745478 [3] https://lore.kernel.org/netdev/3fbec3f8-5c3c-40f9-af6e-c355d8f62...@fb.com/
Bug#926896: sysvinit-utils: pidof is unreliable
We have also been experiencing this problem since moving to Buster. We never saw this with Jessie. I believe it comes down to the following code in readproc: if ( (strchr(process_status, 'D') != NULL) || (strchr(process_status, 'Z') != NULL) ){ /* Ignore zombie processes or processes in disk sleep, as attempts to access the stats of these will sometimes fail. */ if (p->argv0) free(p->argv0); if (p->argv1) free(p->argv1); if (p->statname) free(p->statname); free(p); continue; } Our scenario is similar although not with the same process that is described below.It seems like this makes pidof not as effective for finding the pid of a process if D states are skipped. Are there alternatives to pidof? (BTW the -z option does not appear to help since this code snippet will remove it from the process list). -Original Message- From: Thorsten Glaser Sent: Tuesday, October 22, 2019 6:26 PM To: jsm...@resonatingmedia.com; 926...@bugs.debian.org Subject: Bug#926896: sysvinit-utils: pidof is unreliable NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Tue, 22 Oct 2019, Jesse Smith wrote: > >any ideas how it could be possible for process to be discovered by > >ps(1), but not pidof(1)? > I can think of a few possibilities, though they seem unlikely. One is > that the process could be crashing and restarting, making it a zombie or in D state, doing disc I/O… more likely even. > for brief periods of time. Testing pidof with the "-z" flag would fill > in the "holes" in the test output if that theory is correct. Also: start-stop-daemon --status should probably be used ipv pidof. (Even its manpage says so.) bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- To unsubscribe, send mail to 926896-unsubscr...@bugs.debian.org.
Bug#942902: gwyddion: Depends on pygtk
Source: gwyddion Version: 2.52-1 Severity: serious User: pkg-gnome-maintain...@lists.alioth.debian.org Usertags: oldlibs pygtk Tags: sid bullseye pygtk is unmaintained upstream. It has not had a release since GNOME 3 was released in 2011. The way forward is to port your app to use GObject Introspection bindings. For more information on GObject Introspection see [1] and [2]. As part of the Python2 removal, it is our intent that pygtk will be removed from Testing before the release of Debian 11 "Bullseye". Therefore, I am bumping the severity of this bug to Serious to ensure that there is plenty of warning before the Debian 11 release and to make the eventual removal of pygtk as smooth as possible. If you have any questions don't hesitate to ask. [1] https://wiki.gnome.org/Projects/GObjectIntrospection [2] https://wiki.gnome.org/Projects/PyGObject On behalf of the Debian GNOME team, Jeremy Bicha
Bug#931540:
This bug seems to be fixed, in as much as 0.9.0 has been in unstable for a while. However, I think python 3.8 is going to require 0.10.1, as only numpy 1.17 is compatible with 3.8 and statsmodel 0.10.1 is the first release to support numpy 1.17 (as I read things anyway)
Bug#942901: torbrowser-launcher: Tor Browser 9.0 shows only black screens due to no write access to /dev/shm/org.mozilla.ipc.*.*
Package: torbrowser-launcher Version: 0.3.2-2 Severity: serious Tor Browser 9.0 shows only black screens because the default apparmor profile does not allow write access to /dev/shm/org.mozilla.ipc.*.* like it does for /dev/shm/org.chromium.* and I was able to fix this issue by adding this workaround: ==> /etc/apparmor.d/local/torbrowser.Browser.firefox <== owner /{dev,run}/shm/org.mozilla.*.* rw, Oct 23 09:32:00 kernel: audit: type=1400 audit(1571794320.416:1642): apparmor="DENIED" operation="mknod" profile="torbrowser_firefox" name="/dev/shm/org.mozilla.ipc.1935.0" pid=1935 comm="firefox.real" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 Oct 23 09:32:00 kernel: audit: type=1400 audit(1571794320.432:1643): apparmor="DENIED" operation="mknod" profile="torbrowser_firefox" name="/dev/shm/org.mozilla.ipc.1935.1" pid=1935 comm="firefox.real" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 Oct 23 09:32:00 kernel: audit: type=1400 audit(1571794320.588:1644): apparmor="DENIED" operation="mknod" profile="torbrowser_firefox" name="/dev/shm/org.mozilla.ipc.1935.2" pid=1935 comm="firefox.real" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 Oct 23 09:32:00 kernel: audit: type=1400 audit(1571794320.596:1645): apparmor="DENIED" operation="mknod" profile="torbrowser_firefox" name="/dev/shm/org.mozilla.ipc.1935.3" pid=1935 comm="firefox.real" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 Oct 23 09:32:00 kernel: audit: type=1400 audit(1571794320.600:1646): apparmor="DENIED" operation="mknod" profile="torbrowser_firefox" name="/dev/shm/org.mozilla.ipc.1935.4" pid=1935 comm="firefox.real" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 Oct 23 09:32:00 kernel: audit: type=1400 audit(1571794320.816:1647): apparmor="DENIED" operation="mknod" profile="torbrowser_firefox" name="/dev/shm/org.mozilla.ipc.1935.5" pid=1935 comm="firefox.real" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 Oct 23 09:32:01 kernel: audit: type=1400 audit(1571794321.296:1648): apparmor="DENIED" operation="mknod" profile="torbrowser_firefox" name="/dev/shm/org.mozilla.ipc.1935.6" pid=1935 comm="firefox.real" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 Oct 23 09:32:01 kernel: audit: type=1400 audit(1571794321.668:1649): apparmor="DENIED" operation="mknod" profile="torbrowser_firefox" name="/dev/shm/org.mozilla.ipc.1935.7" pid=1935 comm="firefox.real" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages torbrowser-launcher depends on: ii ca-certificates 20190110 ii libdbus-glib-1-2 0.110-4 ii python3 3.7.5-1 ii python3-gpg 1.13.1-1 ii python3-pyqt5 5.12.3+dfsg-2 ii python3-requests 2.21.0-1 ii python3-socks 1.6.8+dfsg-1 Versions of packages torbrowser-launcher recommends: ii tor 0.4.1.6-1 Versions of packages torbrowser-launcher suggests: ii apparmor 2.13.3-5+b1 -- Configuration Files: /etc/apparmor.d/local/torbrowser.Browser.firefox changed: owner /{dev,run}/shm/org.mozilla.* rw, -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#942900: python3-pluggy Depends: python3-importlib-metadata
Package: python3-pluggy Version: 0.13.0-1 Severity: normal Control: affects -1 python3-fiat pluggy does import importlib_metadata, at least with python3.7 python3-pluggy should therefore Depends: python3-importlib-metadata The bug can be seen in fiat tests, https://ci.debian.net/data/autopkgtest/unstable/amd64/f/fiat/3230794/log.gz autopkgtest [22:25:59]: test test-fiat: - - - - - - - - - - stderr - - - - - - - - - - Traceback (most recent call last): File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "/usr/lib/python3.7/runpy.py", line 85, in _run_code exec(code, run_globals) File "/usr/lib/python3/dist-packages/pytest.py", line 8, in from _pytest.assertion import register_assert_rewrite File "/usr/lib/python3/dist-packages/_pytest/assertion/__init__.py", line 13, in from _pytest.assertion import rewrite File "/usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py", line 24, in from _pytest.assertion import util File "/usr/lib/python3/dist-packages/_pytest/assertion/util.py", line 11, in import _pytest._code File "/usr/lib/python3/dist-packages/_pytest/_code/__init__.py", line 7, in from .code import Code # noqa File "/usr/lib/python3/dist-packages/_pytest/_code/code.py", line 15, in import pluggy File "/usr/lib/python3/dist-packages/pluggy/__init__.py", line 16, in from .manager import PluginManager, PluginValidationError File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 11, in import importlib_metadata ModuleNotFoundError: No module named 'importlib_metadata' -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-pluggy depends on: ii python3 3.7.5-1 python3-pluggy recommends no packages. python3-pluggy suggests no packages. -- no debconf information
Bug#942323: runit-helper: Use dot-symlinks to mark a service as disable
[2019-10-22 01:43] Lorenz > > Sorry, don't follow. Previously no link in /etc/service was created > > if dh-runit decides that service should not be enabled, now hidden > > link is created instead. How it is more confusing? > > OK, from existing users there are no visible consequences and a bug is > fixed. I just meant that probably should be documented somewhere that > runit uses .simlink to mark a service as disabled. No doubt, documentation would be good. I think the most apporiate medium would be introduction of README in bin:runit and short entry in debian/NEWS, like sysvinit does it. > > What buggy behaviour will this change cause for git-run users? > > git-daemon-run use 'update-service --remove' in its maint scripts, so > after #942320 patch is applied, it will set git daemon as disabled on > remove (as it was a user choice) and it will delete the setting on > install. As I remember, git still provides runscript in separate package and does not use dh-runit. How complicated would it be to create patch for src:git that would at least prevented regression due hidden link change? Also, see comments on #942320. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#942320: update-service: use .symlink to mark a service as disabled
[2019-10-14 16:40] Lorenzo Puliti > Hi, Hi! > this is to be consistent with a patch that I'm about to send > for dh-runit. > The attached patch here makes update-service create a .symlink > rather than just removing the symlink to disable a service. > This will help in preserving local admin choice to keep a service disabled. > I've added some detail in the man page but I hope to provide some more > detailed info in update-rc.d man page as runit support is merged there. Looks good to me, but does not apply: > ln -s /var/lib/runit/log/supervise/"$sv" "$svdir"/log/supervise this line of context >fi > fi > +if [ -d "$servicedir"/."$sv" ]; then > +rm "$servicedir"/."$sv" > +fi is nowhere to be found in "debian/contrib/update-service". I am looking at commit [dae57fa82797b673ca9116a81048dedd5ab523db]. I guess you based this your patch on pre-5d98b parent. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#885265: Bug#936299: chirp: Python2 removal in sid/bullseye
Please CC me on replies to the bug since it's not particularly easy for me to subscribe to all of these emails. Personally, I think porting away from pygtk (to GTK3 and GObject Introspection) is more urgent than porting to python3, but yes you'll ultimately need to do both. Thanks, Jeremy Bicha
Bug#938837: xapp: Python2 removal in sid/bullseye
Hi Nicolas, On Tue, 22 Oct 2019, Nicolas Braud-Santoni wrote: > How did you get rid of the B-D on Py2, given that python-gi-dev itself Depends > on it? Ok, the *indirect* B-D I cannot get rid off, but building the py2 version we did as follows: --- xapp.git.orig/pygobject/meson.build +++ xapp.git/pygobject/meson.build @@ -3,7 +3,7 @@ pygobject = dependency('pygobject-3.0', required: true, ) -foreach exec : ['python2', 'python3'] +foreach exec : ['python3'] r = run_command(exec, '-c', 'import gi;print(gi._overridesdir)') if r.returncode() == 0 That means as soon as python-gi-dev stops depending on py2, we don't need it anymore. Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#942899: joblib 0.14.0 is required for Python 3.8 support
Source: joblib Version: 0.13.0-2 Severity: important Dear Maintainer, joblib 0.13.0 does not support Python 3.8. 0.14.0 does and builds fine but for one wrinkle: some tests import threadpoolctl which is not (yet?) packaged. For Ubuntu I just patched things to skip those tests. Cheers, mwh -- System Information: Debian Release: buster/sid APT prefers eoan APT policy: (500, 'eoan'), (400, 'eoan-proposed') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-18-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled --- a/joblib/test/test_parallel.py +++ b/joblib/test/test_parallel.py @@ -1646,8 +1646,8 @@ @with_numpy @with_multiprocessing -@skipif(sys.version_info < (3, 5), -reason='threadpoolctl is a python3.5+ package') +@skipif(True, +reason='threadpoolctl is not yet packaged') @parametrize('n_jobs', [2, 4, -2, -1]) def test_threadpool_limitation_in_child(n_jobs): # Check that the protection against oversubscription in workers is working @@ -1670,8 +1670,8 @@ @with_numpy @with_multiprocessing -@skipif(sys.version_info < (3, 5), -reason='threadpoolctl is a python3.5+ package') +@skipif(True, +reason='threadpoolctl is not yet packaged') @parametrize('inner_max_num_threads', [1, 2, 4, None]) @parametrize('n_jobs', [2, -1]) def test_threadpool_limitation_in_child_context(n_jobs, inner_max_num_threads):
Bug#942898: debcargo: reduce the impact of debcargo-built crates on the package index, and facilitate debian packaging of crates
Package: debcargo Version: 2.4.0-1 Control: affects -1 ftp.debian.org Hi! I'm trying to summarize in this report the state of conversation i had today between members of the FTP team (and others on #debian-ftp) and members the debian Rust packaging team. We seem to be in a bit of an impasse, and i'm hoping that we can use this report to find a concrete way out of the impasse. This report explains my understanding of the problem and proposes one way forward. I'd be very happy for constructive engagement with this report. If you think i'm wrong, help explain what would be better, or why my proposed changes aren't acceptable. Background -- debcargo creates .deb packages corresponding to Rust crates. I'm going to focus here on the librust-* .deb binary packages, and ignore the packages that ship tools that have, for example, a command-line interface. Each source package corresponds to a Rust crate, but it might produce multiple librust-* binary packages -- one for each crate "flavor". the librust-*.deb files contain mainly a distribution of .rs source code in /usr/share/cargo/registry/… Most of the "+flavor" .debs basically have an additional source dependency on some other rust crate, and also ship a symlink back to the folder of .rs source code from the standard (non "+flavor") .deb. For each binary package shipped, it also defines a list of Provides: that include version numbers in the name. Problem Statement(s) From talking with the FTP team, the concern appears to be that the large number of packages, and the large number of Provides produced for some of the packages is seen as a potential problem for the apt Packages index. In particular, a larger Packages index: * increases the cost of data transfer for every debian system that does updates * means that apt has to do more complicated dependency resolution I have not yet gotten measurements of what kinds of costs we're talking about with respect to this shared resource. If someone could provide some numbers and a methodology for getting them, that would be useful in figuring out whether any proposed change contributes a substantial solution to the problem. Kinds of measurements that might make the risks a bit clearer for leaning on this shared resource too heavily: - size of Packages file - RAM needed by aptitude to ingest the Packages file - CPU time taken by aptitude to do dependency resolution Additionally, from the Rust team's perspective, when a crate upstream proposes a feature, this creates a new binary .deb, which triggers inclusion in the NEW queue. The delay in the NEW queue causes friction which makes packaging Rust-related projects harder to do. I've experienced this myself, where i spend about an hour or two on rust packaging, and then find myself waiting for weeks before i can do the next hour of work -- this isn't conducive to effective maintenance. Proposed Solutions -- AIUI, the FTP team thinks that debcargo could reduce the impact on the shared resource of the Packages index by adopting one or both of the tactics described below: 0) reduce the number of "+feature" .debs produced by each crate, perhaps by creating two base .debs for each package: one with no "features" and one that bundles together all of the features that are not mutually-exclusive. Any features that are mutually exclusive would still get their own separate "+feature" .deb. 1) drop version numbering from the Provides: entries for standard packages -- this should reduce the number of Provides: by a substantial fraction. Given that crates are expected to hew to semantic versioning, a generated version number range should be sufficient to declare an API-compatible version dependency. Concerns A concern I've heard about tactic (0) is that this approach might result in dependency loops, as in: https://github.com/sfackler/cargo-tree/issues/34#issuecomment-394266843 It's conceivable that apt could figure out how to deal with those loops, and given that these librust-*-dev .debs are basically just sourcecode, these loops will only affect Rust developers (who might be expected to have beefier machines than regular end users). Such a change would also reduce the number of packages A concern i've heard about tactic (1) is that it makes it harder to ship a two versions of a crate in a given debian distro. For example, we might want to ship librust-foo-dev version 1.x alongside librust-foo-dev version 2.x. If they have the same package name (librust-foo-dev) then they can't both be in the archive at once. We currently do ship librust-foo-dev (meaning "the latest version"), and we create a new package librust-foo-1-dev for when we intend to maintain a stable API for an older release. I don't think anyone wants that to change (many C library packages use the same pattern based on their SONAMEs). The use of Provides: makes it so that a p
Bug#942275: libmoox-options-perl: test failure
Quoting intrigeri (2019-10-14 11:29:02) > Control: retitle -1 libmoox-options-perl: test regression with > librole-tiny-perl 2.001003-1 > Control: forwarded -1 https://github.com/celogeek/MooX-Options/pull/69 > > Hi again, > > intrigeri: > >> Maybe yesterday's upload of libnamespace-autoclean-perl? > > > Hmm, AFAICT libmoox-options-perl does not depend (even transitively) > > on libnamespace-autoclean-perl, so I have a doubt. But who knows :) > > The test suite still passes after upgrading > libnamespace-autoclean-perl, but it starts failing once I upgrade > librole-tiny-perl from 2.001001-1 to 2.001003-1 (both with > libnamespace-autoclean-perl 0.28-1 and 0.29-1, so that one is > definitely not the culprit). > > I've implemented a workaround, sent it in a RFC PR upstream, and I'll > apply it to our package now in order to mitigate a bit the impact of > this bug. But I'm not convinced at all that it's the correct place to > fix this: I suspect this problem is merely a symptom of a regression > in librole-tiny-perl, but the codebase of that one is far outside of > my comfort zone. > > In passing, I see that this newer librole-tiny-perl also breaks the > test suite of libattean-perl: > https://ci.debian.net/data/autopkgtest/testing/amd64/liba/libattean-perl/3157349/log.gz > But that seems to be another problem and I did not dive into it. Seems there's now a fix for Attean upstream which might be enlightening for how to address same/similar issue in other modules: https://github.com/kasei/attean/pull/142 >From that fix: > Moo::Role and Role::Tiny shouldn't be 'use'd in the same package. > > Moo::Roles shouldn't be applied using Role::Tiny. > > Role::Tiny should be loaded explicitly in the locations using its > subs/methods directly. - 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
Bug#942897: antennavis: Outdated documentation references for nec2
Package: antennavis Version: 0.3.1-4+b1 Severity: minor Dear Maintainer, The documentation at /usr/share/doc/antennavis/README references no longer available nec2 binary sources: >> In case you can't meet these requirements, you can download a >> statically linked nec2 version from: >> http://www.qsl.net/pg4i/download/nec2bin-11.tar.gz >> or: http://pg4i.mattsnetwork.co.uk/download/nec2bin-11.tar.gz -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages antennavis depends on: ii dpkg1.19.7 ii libc6 2.29-2 ii libgl1 1.1.0-1+b1 ii libgl1-mesa-glx 19.2.1-1 ii libglu1-mesa [libglu1] 9.0.0-2.1+b3 ii libtcl8.6 8.6.9+dfsg-2+b1 ii libtk8.68.6.9-2+b1 ii libx11-62:1.6.8-1 ii libxmu6 2:1.1.2-2+b3 Versions of packages antennavis recommends: pn nec antennavis suggests no packages. -- no debconf information
Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5
Hi, Antoine Beaupré wrote: > I mean "broken" as in "DVD as are not available as normal ISOs over HTTP > or bittorrent but only jigdo". Afaik, that's because jigdo uses the package mirror servers as source of the bulk of its downloads. Those servers experience the same as with a generously sized installation of a Debian system. > jigdo is the reason MD5sums are still in the Packages files, according > to ftp-masters. It's not a theory I just came up with just for kicks. I really wonder where this dependency should come from. Is there any public background info to motivate this claim ? ... one only needs to wish: Ansgar writes in 942...@bugs.debian.org and on debian...@lists.debian.org: > From looking, I believe it is debian-cd's tools/grab_md5 that is using > the MD5sum from Packages (and Sources) to avoid having to compute all > these checksums itself. So it's about lazyness of debian-cd. That's an implementation detail. One should probably talk to Steve McIntyre directly. > - writing MD5sum in a separate file only used by debian-cd Why that ? debian-cd has copies of the .deb files to pack them up in the ISO. There is no jigdo production without seeing the packages. md5sum is not really slow, nowadays. > - using a (truncated) sha256sum; this requires that the jigdo client > only uses the "md5sum" as an opaque identifier for a file. It is used as opaque identifier, but this identifier is at some occasions also interpreted as MD5 which has to match the package file. Antoine Beaupré wrote: > In my experience, jigdo never worked, I tested the whole procedure shown in https://wiki.debian.org/JigdoOnLive with the non-standard situation to have an old Desktop with the filesystem of an inconscious Debian 6 host of the Debian Live system. Since i assume that you have a Debian system running, be invited to join in at https://wiki.debian.org/JigdoOnLive#If_needed.2C_work_around_a_shortcoming_of_older_jigdo-lite in order to download e.g. https://cdimage.debian.org/cdimage/release/current/amd64/jigdo-dvd/debian-10.1.0-amd64-DVD-4.jigdo https://cdimage.debian.org/cdimage/release/current/amd64/jigdo-dvd/debian-10.1.0-amd64-DVD-4.template Verify them properly and run jigdo-lite with URL https://cdimage.debian.org/cdimage/release/current/amd64/jigdo-dvd/debian-10.1.0-amd64-DVD-4.jigdo Finally verify the emerged debian-10.1.0-amd64-DVD-4.iso by the proposed means. > The CMU Software Engineering Institute considers MD5 essentially > "cryptographically broken and unsuitable for further use" Yes. But jigdo-lite does not use MD5 for cryptographical purposes except for an initial check of .template and a final check of .iso. Both are outdated. But both get re-assured by GPG and SHA512 if you follow the procedure which is outlined above. > The problem is *every* bug report (e.g. #772110) that tries to document > serious issues about jigdo *all* get downgraded to "normal", saying > "this is not a problem". But the diagnosis by Steve McIntyre tells why: > > Sorry, but this bug is hardly grave. Important, maybe... jigdo-lite > > works most of the time for most people. jigdo-lite even noticed the problem before the overall check of the .iso could be run to finally report a damaged ISO, too. Now what would you do if a directly downloaded ISO turns out to be damaged ? I'd advise download from a different source. In case of jigdo this is mainly a different package mirror. Daniel Kahn Gillmor wrote: > I'm unaware of the meaning of "cross-table key matching", You have one table with keys and values and another table with keys and values. Lines in both tables, where the keys are the same, are considered to be in relation. Like in a data base. > but it's known to be relatively easy to find collisions in MD5. It is suspected that it is possible to construct byte strings which produce a desired particular MD5 value. But when matching the lines of two tables by a key you have to consider hash table theory and especially the birthday paradox. A short excursion on wikipedia lets me estimate that the chance for a MD5 collision among 1 billion .deb files is about 1 - e exp -1e-20. Regrettably i found no calculator which would not say 0 as result. > If the adversary can convince any DD to upload an obviously harmless > package of the adversary's choice into the archive, then the adversary > can also craft another package with a matching MD5sum. The cryptographic check is to be done on .jigdo and .template before the run of jigdo-lite, and on .iso afterwards. What is a security risk is that you need much contact with debian-cd and its environment in order to know how to do it. The info is scattered on the Debian web appearance. > You probably don't mean it this way, but this sounds it will make what > should be the software author's problem into the user's problem. > [...] > Thanks for your attention to (and efforts on behalf of) jigdo, Steve. You should now face your critics. I did what i co
Bug#926896: sysvinit-utils: pidof is unreliable
On Tue, 22 Oct 2019, Jesse Smith wrote: > >any ideas how it could be possible for process to be discovered by > >ps(1), but not pidof(1)? > I can think of a few possibilities, though they seem unlikely. One is > that the process could be crashing and restarting, making it a zombie or in D state, doing disc I/O… more likely even. > for brief periods of time. Testing pidof with the "-z" flag would fill > in the "holes" in the test output if that theory is correct. Also: start-stop-daemon --status should probably be used ipv pidof. (Even its manpage says so.) bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5
On 2019-10-22 23:10:19, Julien Cristau wrote: > Control: severity -1 normal > > On Tue, Oct 22, 2019 at 03:29:54PM -0400, Antoine Beaupré wrote: >> Control: severity 887831 grave >> > That is entirely unjustified afaict, and doesn't help your case. I would have thought I made a pretty explicit justification, while you just said "entirely unjustified" without any sort of explanation. Not sure I understand what case you're bringing forward. I guess I should be thankful: without your intervention, I might have considered continuing to monitor that bug report and maybe get involved in trying to fix that problem in the long run, across the project. But now you're destroyed the last shred of motivation I had to ever work again on jigdo. So thanks, in a bizarre, unfortunately-so-typical-in-Debian, way. A. -- No animal has more liberty than the cat; but it buries the mess it makes. The cat is the best anarchist. Until they learn that from the cat I cannot respect them. - For whom the bell tolls, Ernest Hemingway
Bug#926896: sysvinit-utils: pidof is unreliable
> Jesse, >any ideas how it could be possible for process to be discovered by >ps(1), but not pidof(1)? > I can think of a few possibilities, though they seem unlikely. One is that the process could be crashing and restarting, making it a zombie for brief periods of time. Testing pidof with the "-z" flag would fill in the "holes" in the test output if that theory is correct. Alternatively, if the executable is on a remote network share, like NFS, that might explain the gaps. While it doesn't explain the gaps in output, I am curious if the gaps also appear if the pidof test is run without the "-s" flag. So instead of "pidof -s apcupsd" what happens if you run "pidof -z apcupsd"? - Jesse
Bug#942881: Confirming bug on Dell XPS 13 9360R
Can confirm that this bug affects more people. Same symptoms and same message in syslog Platform: Dell XPS 13 9360R running the same kernel Can be reverted by shutting down and booting in to an older kernel (5.2.17-1+b1)
Bug#937926: python-pbr has been removed
severity 937926 serious thanks The latest upload of src:python-pbr has now removed the python[2]-pbr binary package, thus making the build dependencies of src:python-mock uninstallable, and raising the urgency of dropping that build dependency. (Unless you install an older binary package of python-pbr from the archive; but in any case, either this will block python-pbr from migrating to testing, or else in testing the source package for python-mock will be truly unbuildable.) -- Daniel Schepler
Bug#942875: debootstrap does not overwrite existing files even if adviced to do
severity 942875 normal # thanks Hi, thanks for reporting this bug. however... > I suppose this a bug, since debootstrap did warn before it would > overwrite files! yes, it's a bug. but not even important one according to https://www.debian.org/Bugs/Developer#severities -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#932971: ITP: squashfs-tools-ng -- A new set of tools for working with SquashFS images
Hi László, Quoting László Böszörményi (GCS) (2019-10-22 21:15:19) > On Wed, Oct 16, 2019 at 9:45 PM Johannes Schauer wrote: > > On Thu, 25 Jul 2019 11:51:00 +0200 László Böszörményi (GCS) > > wrote: > > > * Package name: squashfs-tools-ng > > I see the package is still waiting in NEW. > > > > Where did you put the packaging VCS? I'd like to play around with it before > > ftp > > master manages to approve it. :) > You can get the updated, 0.7-1 release[1], thanks! > but please note that its > self-testing is constantly failing: > FAIL: test_fstree_init > == > > test_fstree_init: tests/fstree_init.c:32: main: Assertion > `fs.defaults.st_mtime == 0' failed. > FAIL test_fstree_init (exit status: 134) > > Can you check it David? I've tried it on three machines. Two of these > are running on amd64 and one is on i386 architecture. I can confirm that this test fails also over here. You might also want to update your packaging a bit. I get rather problematic Lintian warnings and errors here: W: squashfs-tools-ng: package-name-doesnt-match-sonames libsquashfs0 E: squashfs-tools-ng: non-empty-dependency_libs-in-la-file usr/lib/x86_64-linux-gnu/libsquashfs.la W: squashfs-tools-ng: non-dev-pkg-with-shlib-symlink usr/lib/x86_64-linux-gnu/libsquashfs.so.0.0.0 usr/lib/x86_64-linux-gnu/libsquashfs.so And sometimes ftp-master will not accept a package with Lintian errors. Thanks! cheers, josch signature.asc Description: signature
Bug#926896: sysvinit-utils: pidof is unreliable
control: tags -1 +help [ Adding to thread "apcupsd" Debian maintainer and "pidof" upstream maintainer. ] [2019-10-21 14:27] Martin von Wittich > Am 20.10.19 um 20:59 schrieb Dmitry Bogatov: > > > > That sounds explainable. pidof() scans /proc directory, and it takes some > > time for kernel to create entry there. > [...] > Even if there were, that wouldn't explain how ps is able to see the > process, while pidof is not. As far as I know, ps also gets this > information from /proc. True. > To verify my assumptions, I've adapted my test script as follows: I adjusted script slightly (added -d option to first ls and replaced "systectl" with "/etc/init.d" like following: #!/bin/bash set -eu /etc/init.d/apcupsd restart START=$SECONDS ps -f -C apcupsd PID="$(ps -o pid -C apcupsd --noheaders)" ls -d /proc/"$PID" while true do echo -n "pidof: " pidof -s apcupsd || echo echo -n "ls: " ls -d /proc/"$PID" [ $((SECONDS - START)) -ge 2 ] && break sleep 0.01 done ps -f -C apcupsd > So the /proc/26476 is there even when pidof doesn't see the process. > >> But there are almost always holes in the output further on, so it's > >> also slightly unreliabl afterwards. and wasn't able to reproduce holes in the middle, but I did observed hole at the beginning: Stopping UPS power management: apcupsd. Starting UPS power management: apcupsd. UIDPID PPID C STIME TTY TIME CMD root 24352 1 0 22:51 ?00:00:00 /sbin/apcupsd /proc/24352 pidof: ls: /proc/24352 pidof: 24352 [... all below is as expected ...] Hole in beginning happened reproducibly, 100% of time. > I had assumed that the problem should be easily reproducible with any > other recently-started process, but that is apparently not the case: > [...] > > Maybe systemd is somehow involved? I tried to replace apcupsd with another servers on my box (tor, apt-cacher-ng), but no holes happened with them. I can't exclude that systemd is somehow related to holes in the middle you observe, but hole in beginning is mysterious enough. Personally, I am out of ideas: as far as I know (and I just web-searched), there is only one way to get list of processes: scan /proc. Jesse, any ideas how it could be possible for process to be discovered by ps(1), but not pidof(1)? Dear apcupsd maintainer, any suggestions how "apcupsd" server process could be special, that it is not discovered by pidof(1) for some time after restart and, reportedly, even once in a while server is running? -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#942881: Audio on Lenovo X1 Carbon 5th generation stopped working after upgrade to linux-image-5.3.0-1-amd64 ("No response from codec")
Hi, On Tue, Oct 22, 2019 at 09:47:32PM +0300, Josh Triplett wrote: > After upgrading to linux-image-5.3.0-1-amd64, I get messages like those > seen in the log ("No response from codec, resetting bus" and "Unable to > sync register"), and eventually a WARN. The mixer doesn't show the audio > device at all. > > This didn't happen with the previous kernel, namely: > Oct 21 21:04:28 s kernel: Linux version 5.2.0-3-amd64 > (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-23)) #1 SMP > Debian 5.2.17-1 (2019-10-06) I can confirm the same behaviour with ThinkPad T25. There seems to be a workaround: options snd_hda_intel probe_mask=1 I'm not getting errors with this and audio works. I have a feeling that HDMI audio will not work, however, because there's no "input: HDA Intel PCH HDMI" in dmesg any more. :-( -- Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/
Bug#942883: closed by Alf Gaida (Re: libqt5xdgiconloader3: Dependency upon qtbase-abi-5-11-3 prevents installation)
On Tue, 22 Oct 2019 13:58:13 -0700 Felicia P wrote: > Thank you for the transition information Hi, when running sid the transition tracker is the best friend one can have. Second best friend is apt - i might sound old fashioned, but GUI tools don't give so much hints about not wanted package removals or reasons for not installing certain packages - so in case apt want to remove x packages - just hit and find out the reason - on my work horse currently 106 packages are to be removed :D - the key word is patience. And while waiting one can use the time to gather some additional knowledge. (I learned it the very hard way years ago :P) Cheers Alf
Bug#887837: jigdo-lite: Final statement about verified ISO is too affirmative
On Sat 2018-01-20 14:10:28 +0100, Thomas Schmitt wrote: > as described in > https://lists.debian.org/debian-cd/2018/01/msg00021.html > jigdo-file verifies the .template file and the resulting ISO image only > by MD5 checksums which stem from the .jigdo or from the .template file. > The .jigdo file is not verified at all. > > Both issues have own bug reports (#887831 and #887830). This one proposes > a preliminary fix by simply telling the user that it's not safe yet. > > The final message after the MD5 check of the finished ISO image is > overly affirmative: > "OK: Checksums match, image is good!" > It stems from jigdo-file and it might be used by automated callers of > jigdo-lite as indication of successful download. > > But after this message, jigdo-lite could point to the advised verification > by GPG and a more secure checksum type like SHA512. Please let's not ask the user to do something that the software can do automatically for them. If the user used jigdo, and the author(s) of jigdo know how to do the appropriate checks, then jigdo should just do the checks and report the result, not tell users how to do the checks and expect them to actually follow through. We know in practice that won't happen. Let's make our tools usable. --dkg signature.asc Description: PGP signature
Bug#942896: tellico test rely on the network
Package: src:tellico Version: 3.2.1-2 Severity: serious Tags: sid bullseye patch tellico access the network during the build. please don't do this. http://launchpadlibrarian.net/374519251/tellico_3.1.2-2ubuntu4_3.1.2-2ubuntu5.diff.gz
Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5
On Tue 2019-10-22 23:03:49 +0200, Thomas Schmitt wrote: > It does so for cross-table key matching, where MD5 suffices by all means > of hash table theory. I'm unaware of the meaning of "cross-table key matching", but it's known to be relatively easy to find collisions in MD5. If the adversary can convince any DD to upload an obviously harmless package of the adversary's choice into the archive, then the adversary can also craft another package with a matching MD5sum. As a DD, i don't want my signature authorizing a specific upload to be used to distribute some other file to our users. > There is bug #887837 where i propose to add a reminder message at the end > of the jigdo-lite run. You probably don't mean it this way, but this sounds it will make what should be the software author's problem into the user's problem. i think we should be more user-friendly than that. I've followed up on that bug report separately. > Debian could really need a end-user comprehensable description of the > credible verification from GPG to SHA512 to ISO. This is completely > independent of jigdo and applies to all download methods for ISOs. I agree that this kind of separate documentation would be great to have, and is independent of this bug report. Thanks for your attention to (and efforts on behalf of) jigdo, --dkg signature.asc Description: PGP signature
Bug#942893: ftp.debian.org: please drop MD5sum lines from Packages
Daniel Kahn Gillmor writes: > The Packages file is growing, and we would like to keep it smaller. > > The MD5sum lines are vestigial at this point. Anything that they do > can be done better with the data from the SHA256sum lines. I agree it would be nice to remove MD5sum from Packages; there are a few other fields that might also not be that useful (e.g. Maintainer). > #887831 suggests that jigdo may currently still be broken if MD5sum > goes away, but perhaps that's more of a reflection on the unmaintained > state of jigdo than it is on the state of the archive. >From looking, I believe it is debian-cd's tools/grab_md5 that is using the MD5sum from Packages (and Sources) to avoid having to compute all these checksums itself. We could look into either - writing MD5sum in a separate file only used by debian-cd (if present, otherwise debian-cd should fall back to using Packages), or - using a (truncated) sha256sum; this requires that the jigdo client only uses the "md5sum" as an opaque identifier for a file. I've CC'ed debian-cd@ for input. Ansgar
Bug#931737: kdepim-runtime: Imap session login cancelled
On woensdag 16 oktober 2019 03:54:45 CEST you wrote: > you can change the config of OpenSSL to allow lower TLS versions to work. > Better would be to urge that mail provider to upgrade their mail software as > TLS < 1.2 really isn't secure. >From https://lists.debian.org/debian-kde/2018/11/msg1.html : Changing back the defaults in /etc/ssl/openssl.cnf to previous system wide defaults can be done using: MinProtocol = None CipherString = DEFAULT It's recommended that you contact the remote site in case the defaults cause problems. signature.asc Description: This is a digitally signed message part.
Bug#942895: CVE-2019-18224
Source: libidn2 Severity: grave Tags: security This was assigned CVE-2019-18224: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12420 Patch: https://github.com/libidn/libidn2/commit/e4d1558aa2c1c04a05066ee8600f37603890ba8c Cheers, Moritz
Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5
On 2019-10-22 23:03:49, Thomas Schmitt wrote: > Hi, > > Antoine Beaupré wrote: >> Severity set to 'grave' from 'normal' > > This is really overdone. > > See jigdo as a peculiar way of downloading the ISO with a MD5 check > where e.g. wget has none at all. > And as said, for now jigdo seems indispensible for the fat ISO sets. > > >> If the ISO image generation is broken, it should be fixed. > > My bug report does not say that ISO production is broken or that jigdo > is the reason for any of the checksums in the package management. > I doubt both theories. I mean "broken" as in "DVD as are not available as normal ISOs over HTTP or bittorrent but only jigdo". jigdo is the reason MD5sums are still in the Packages files, according to ftp-masters. It's not a theory I just came up with just for kicks. >> In the meantime, I think it's perfectly acceptable to remove MD5sums >> from the archive, at the cost of breaking jigdo. > > I agree to this plan, if you afterwards verify that debian-cd still can > produce a pair of .jigdo and .template which jigdo-lite then can use > to create the identical ISO by help of a package mirror. In my experience, jigdo never worked, so I don't expect I will be able to do this after the removal, nor before. I have long given up on doing anything with jigdo. [...] >> Or, to put it another way, it's completely unacceptable that jigdo uses >> MD5 to authenticate checksums, > > It does so for cross-table key matching, where MD5 suffices by all means > of hash table theory. To quote wikipedia: > The CMU Software Engineering Institute considers MD5 essentially > "cryptographically broken and unsuitable for further use" I would consider using MD5 in any software a serious engineering mistake, in any case. It might still be useful as a hash table component, but I would suspect it is still a mistake. [...] It's really unfortunate that this bug has been downgraded. I was hoping to take this as an opportunity to remove jigdo from our workflows, but I guess we will need to tackle this (namely that jigdo is completely abandoned and broken) head on, in separate bug reports. The problem is *every* bug report (e.g. #772110) that tries to document serious issues about jigdo *all* get downgraded to "normal", saying "this is not a problem". I think this is an unfair way to treat your users. Sure, it will keep jigdo in Debian forever, but it will give a false sense of security (in case of this bug) and reliability (in the case of #772110), which will hurt Debian's adoption. Is anyone still seriously thinking that jigdo is a reliable and useful way to download Debian nowadays? A. -- A lot of people never use their initiative because no-one told them to. - Banksy
Bug#942894: CVE-2019-15587
Package: ruby-loofah Severity: important Tags: security Please see https://www.openwall.com/lists/oss-security/2019/10/22/1 Cheers, Moritz
Bug#942893: ftp.debian.org: please drop MD5sum lines from Packages
Package: ftp.debian.org Severity: normal The Packages file is growing, and we would like to keep it smaller. The MD5sum lines are vestigial at this point. Anything that they do can be done better with the data from the SHA256sum lines. Removal of the MD5sum lines would reduce the size of the gzip'ed Packages file by ~13%, a significant win for a frequently-downloaded file: $ grep -v ^MD5sum < /var/lib/apt/lists/ftp.debian.org_debian_dists_sid_main_binary-amd64_Packages | gzip -9 | wc -c 9541056 0 dkg@alice:~$ cat < /var/lib/apt/lists/ftp.debian.org_debian_dists_sid_main_binary-amd64_Packages | gzip -9 | wc -c 10913735 0 dkg@alice:~$ echo $(( 100 - 100 * 9541056 / 10913735 )) 13 0 dkg@alice:~$ This removal was attempted once before, as documented in #818463, and all of the subsequent blocking bugs appear to have been fixed in the archive for several years. #887831 suggests that jigdo may currently still be broken if MD5sum goes away, but perhaps that's more of a reflection on the unmaintained state of jigdo than it is on the state of the archive. --dkg
Bug#608023: (no subject)
This should be fixed in Aspell 0.60.8 as aspell 0.60.8 increased the score of suggestions with a ' ', '-' so they no longer appear near the start of the list. The first suggestion is now 'transferred'
Bug#942892: RM: neutron-lbaas -- ROM; Deprecated, replaced by Octavia
Package: ftp.debian.org Severity: normal Dear FTP masters, neutron-lbaas is deprecated upstream, and replaced by Octavia, which we have in Buster already (and which I've been using in production). Therefore, we should remove neutron-lbaas from Sid/Testing, as it's supposed to be completely gone from this last release of OpenStack I've uploaded this week and last week. Cheers, Thomas Goirand (zigo)
Bug#401120: fixed
This should be fixed in Aspell 0.60.8 as aspell 0.60.8 increased the score of suggestions with a ' ', '-' so they no longer appear near the start of the list.
Bug#942883: closed by Alf Gaida (Re: libqt5xdgiconloader3: Dependency upon qtbase-abi-5-11-3 prevents installation)
Thank you for the transition information On 10/22/19 1:12 PM, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the libqt5xdgiconloader3 package: > > #942883: libqt5xdgiconloader3: Dependency upon qtbase-abi-5-11-3 prevents > installation > > It has been closed by Alf Gaida . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Alf Gaida > by > replying to this email. > > 0xCEC1B8C7E51FC983.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Bug#942891: cracklib2: fails to build Python 3.8 extensions
Source: cracklib2 Version: 2.9.6-2 Severity: important Tags: patch Dear Maintainer, When Python 3.8 is supported, as in Ubuntu focal or Debian experimental, the 3.8 extensions are not built because of this error in the configure process: checking for python script directory... Traceback (most recent call last): File "", line 20, in File "/usr/lib/python3.8/sysconfig.py", line 512, in get_path return get_paths(scheme, vars, expand)[name] File "/usr/lib/python3.8/sysconfig.py", line 502, in get_paths return _expand_vars(scheme, vars) File "/usr/lib/python3.8/sysconfig.py", line 172, in _expand_vars _extend_dict(vars, get_config_vars()) File "/usr/lib/python3.8/sysconfig.py", line 550, in get_config_vars _init_posix(_CONFIG_VARS) File "/usr/lib/python3.8/sysconfig.py", line 421, in _init_posix _temp = __import__(name, globals(), locals(), ['build_time_vars'], 0) ModuleNotFoundError: No module named '_sysconfigdata_m_linux_x86_64-linux-gnu' Simply unsetting the _PYTHON_HOST_PLATFORM / _PYTHON_SYSCONFIGDATA_NAME variables in debian/rules as in this patch: http://launchpadlibrarian.net/447772089/cracklib2_2.9.6-2build1_2.9.6-2ubuntu1.diff.gz fixes this. It seems to me that dh-python itself now does a better job of setting these variables when needed. Cheers, mwh -- System Information: Debian Release: buster/sid APT prefers eoan APT policy: (500, 'eoan'), (400, 'eoan-proposed') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-18-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5
Control: severity -1 normal On Tue, Oct 22, 2019 at 03:29:54PM -0400, Antoine Beaupré wrote: > Control: severity 887831 grave > That is entirely unjustified afaict, and doesn't help your case. Cheers, Julien
Bug#942069: ITP: python-opentracing
retitle 942069 ITP: python-opentracing -- Python interface to the OpenTracing.io API owner 942069 ! thanks I think I'm ready to package it. -- Fabrice BAUZAC-STEHLY PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5
Hi, Antoine Beaupré wrote: > Severity set to 'grave' from 'normal' This is really overdone. See jigdo as a peculiar way of downloading the ISO with a MD5 check where e.g. wget has none at all. And as said, for now jigdo seems indispensible for the fat ISO sets. > If the ISO image generation is broken, it should be fixed. My bug report does not say that ISO production is broken or that jigdo is the reason for any of the checksums in the package management. I doubt both theories. > In the meantime, I think it's perfectly acceptable to remove MD5sums > from the archive, at the cost of breaking jigdo. I agree to this plan, if you afterwards verify that debian-cd still can produce a pair of .jigdo and .template which jigdo-lite then can use to create the identical ISO by help of a package mirror. I place my bet on no problems, but i may be wrong. > Or, to put it another way, it's completely unacceptable that jigdo uses > MD5 to authenticate checksums, It does so for cross-table key matching, where MD5 suffices by all means of hash table theory. It does so for verifying internally what can be verified externally by the best means which Debian offers for its ISOs. I advise to do the external check of .jigdo and .template before the run of jigdo-lite and the external check of .iso afterwards. There is bug #887837 where i propose to add a reminder message at the end of the jigdo-lite run. Debian could really need a end-user comprehensable description of the credible verification from GPG to SHA512 to ISO. This is completely independent of jigdo and applies to all download methods for ISOs. Have a nice day :) Thomas
Bug#942890: openssh-server: daemon slow to start
Package: openssh-server Version: 1:7.9p1-10+deb10u1 Severity: normal Dear Maintainer, After a fresh installation of Debian Buster stable on a HP Proliant Microserver Gen8, I found out that the ssh daemon was slow to start after a (re)boot. It manifests by the fact that the connection is refused by the server. I could take several minutes for the daemon to start and that I can connect to the server. Actually, it is always the slowest process to start ; when using systemd-analyze blame to monitor it, I discovered it was taken at least 60s. I think it might be a problem with minimal entropy needed; indeed, when I connect a keyboard to the machine and typing random characters without login in, the daemon would start after 10-20 characters typed. For the record, the OS is installed on an SSD. Regards, JB -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openssh-server depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.71 ii dpkg 1.19.7 ii libaudit1 1:2.8.4-3 ii libc6 2.28-10 ii libcom-err21.44.5-1+deb10u2 ii libgssapi-krb5-2 1.17-3 ii libkrb5-3 1.17-3 ii libpam-modules 1.3.1-5 ii libpam-runtime 1.3.1-5 ii libpam0g 1.3.1-5 ii libselinux12.8-1+b1 ii libssl1.1 1.1.1d-0+deb10u2 ii libsystemd0241-7~deb10u1 ii libwrap0 7.6.q-28 ii lsb-base 10.2019051400 ii openssh-client 1:7.9p1-10+deb10u1 ii openssh-sftp-server1:7.9p1-10+deb10u1 ii procps 2:3.3.15-2 ii ucf3.0038+nmu1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages openssh-server recommends: ii libpam-systemd [logind] 241-7~deb10u1 ii ncurses-term 6.1+20181013-2+deb10u1 ii xauth1:1.0.10-1 Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere pn rssh pn ssh-askpass pn ufw -- debconf information excluded
Bug#909223: libwxbase3.0-0v5: crash in wxFont::Create with gnuplot-qt: corrupted double-linked list
Control: tags -1 +unreproducible The original report says "This is not reproducible" so tagging as such. On Fri, Sep 21, 2018 at 01:20:37PM +0200, Vincent Lefevre wrote: > On 2018-09-21 05:49:19 +0100, Olly Betts wrote: > > If it's something that happens sporadically I'd suggest you try > > habitually running gnuplot under a malloc debugger (e.g. valgrind if the > > slowdown is tolerable), and hope that catches the corruption as it > > happens. > > I can see lots of "Conditional jump or move depends on uninitialised > value(s)", and also: > > ==32184== Invalid read of size 32 > ==32184==at 0x790FFD1: __wcsnlen_avx2 (strlen-avx2.S:62) > ==32184==by 0x78578C1: wcsrtombs (wcsrtombs.c:104) > ==32184==by 0x5B12FAF: wcsrtombs (wchar2.h:519) This looks like valgrind lacking a suppression for an optimised version of wcslen() for AVX-capable CPUs which deliberately overreads the string. I don't think it's connected to this bug report. Cheers, Olly
Bug#942889: tuxpaint: FTBFS on several architectures in experimental
Source: tuxpaint Version: 1:0.9.24~git20190922-f7d30d-1~exp2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi, tuxpaint/experimental FTBFS on several architectures where tuxpaint/sid builds: https://buildd.debian.org/status/package.php?p=tuxpaint&suite=experimental Andreas
Bug#939354: buster-pu: package capistrano/3.11.0-3+deb10u1
Thanks Julien, > Looks ok, go ahead. It would have been helpful to note that and when > this was fixed in sid, since there's no corresponding debian bug. I changed d/changelog to mention that this was fixed in upstream's 3.11.1 sid and testing currently have 3.11.2, I hope that helps clear it up. Uploaded. capistrano_3.11.0-3+deb10u1_source.changes ACCEPTED into proposed-updates->stable-new -- Samuel Henrique
Bug#906060: Coordinate overflow when rendering
Control: tags -1 +moreinfo On Mon, Aug 13, 2018 at 09:28:53PM +0200, Simon Richter wrote: > This is a major showstopper for linking KiCad 5 against GTK3, so this > requires us to keep GTK2 around longer. The debian kicad package has now using the GTK3 flavour of wxwidgets3.0 for many months, so has this bug been solved (at least as far as kicad and wxwidgets3.0 are concerned)? If so, I think we can at least unassign this from wx and kicad. If not, I'm very unclear what (as a maintainer of wxwidgets3.0) I'm expected to do given that the problem clearly seem to lie lower down the stack: > Quick debugging has shown that the coordinates given to Cairo still make > sense, even if the zoom level makes them numerically large. As I'd need > significant time to debug into optimized drawing routines, I'd like to pass > this on. I suspect that this is mostly an interaction between Cairo and > Pixman, with an overflow happening somewhere in a conversion from double to > an integer type. Cheers, Olly
Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5
Hi, Daniel Kahn Gillmor wrote: > If jigdo would use the SHA256sum entries instead of the MD5 entries when > it is doing ISO assembly, then everyone could still fetch full DVD sets > or BD sized installation ISOs I am kindof the second-last jigdo export, but not at all with .deb entrails. Are you sure that Debian package management is involved other than maybe with generating the input file for xorrisofs option -md5-list ? In the .jigdo file, which controls the package download operations of jigdo-lite, the MD5 is a key which connects the package file path with a matchable descriptor entry in the .template file bearing the same MD5. A gunzipped .jigdo file bears for example FexKzYyIVG2rRb1UjUKj8Q=Debian:pool/contrib/b/biomaj-watcher/biomaj-watcher_1.2.2-4_all.deb which is the MD5 as base64, "=Debian:" representing the individual part of the mirror URL chosen at download time, and "pool/.../...deb" to depict the invariant package path part on the mirror server. The matching descriptor entry in .template bears the same MD5 and by its position marks the place where to patch the .deb file into the .iso. Maybe Steve McIntyre can say more about how the -md5-list file gets created before xorrisofs is run. > AFAICT, jigdo's last maintenance release (debian version) was nearly two > years ago. Steve seems busy with other stuff. > The last upsteam release (0.7.3) was produced in 2006. This one is dead. At that time, the .jigdo and .template files were generated from existing .iso images by matching the submitted MD5 list against block sequences in the ISO. Steve then taught genisoimage how to produce .jigdo and .template on the fly while producing the .iso image. Before xorriso could take over the job, George Danchev and i extracted Steve's jigdo code into a library named libjte which is then used by xorriso to produce the desired companion files of the .iso. For restoring .iso from jigdo, only jigdo-lite from package jigdo-file is left. Because there is no supported tool for Mac or MS-Windows, i began to describe a jigdo download procedure via a Debian Live ISO: https://wiki.debian.org/JigdoOnLive Main open questions are about how to get a Debian Live connected to the internet if there is non-free firmware needed, and how to access the foreign OS'es filesystems for writing the .jigdo, .template, and .iso files. (I am neither sysadmin nor MS/Mac user.) > Do you have any suggestions to offer to make jigdo work using a modern > cryptographic digest? We would have to team up with Steve to fix the remaining moderate security concerns about the jigdo download process. There are no security concerns about the matching of .template block ranges with package paths, because no man-in-the-middle can alter this mapping, once .jigdo and .template files are verified. MD5 with its 128 bits should be very safe against false identifications if the file count in a .jigdo file stays well below 2 exp 30. The resolution of bug #887830 fixed the most dangerous security gap of using a totally untrusted .jigdo file and a then only MD5-checked .template file. A cautious user can now verify both files before running jigdo-lite. (jigdo-lite will not download again if it finds the files already in the current work directory.) This bug here, #887831, only tries to bring the internal checks of jigdo-lite on the downloaded .template and resulting .iso to the security standard which is recommended but not enforced for download of .jigdo or direct download of .iso. Steve once announced to publish a straightforward instruction of the verification steps from SHA512SUMS.sign, to SHA512SUMS and then to possibly .jigdo and always .iso. I hope he still knows where the draft for this is ... :)) Have a nice day :) Thomas
Bug#941093: ping!
Hi Dmitry, On 22-10-2019 22:19, Dmitry Shachnev wrote: > On Tue, Oct 22, 2019 at 09:57:16PM +0200, Paul Gevers wrote: >> I have scheduled those. First build failures are appearing. Can you >> please check? >> >> https://buildd.debian.org/status/package.php?p=deepin-qt5dxcb-plugin >> https://buildd.debian.org/status/package.php?p=xdg-desktop-portal-kde >> https://buildd.debian.org/status/package.php?p=libfm-qt >> https://buildd.debian.org/status/package.php?p=pyqt5 > > Oh! I will fix xdg-desktop-portal-kde and pyqt5 myself, and file bugs for > the other two. > > For deepin-qt5dxcb-plugin there was #935105 but the new failure is different, > so I think a new bug is better. Please make sure that all FTBFS bugs are tagged with the ftbfs tag. That will have them show up on the buildd pages and eases our review work. Paul signature.asc Description: OpenPGP digital signature
Bug#942768: lcl-units-2.0: file conflict with lazarus-src-2.0 (versin 2.0.2+dfsg-5)
Hi Jan, Hi Andreas, > both contains the same file, namely > /usr/lib/lazarus/2.0.2/components/IdeInspector/ideinspector.lpk > and removing it from one of them would fix the issue. That is not a bug, but rather a feature that is solving previous bugs [1] and [2] The issue is that I copied some code from the Debian policy manual [3] and that code was wrong: The given example is missing closing bracket. I should noticed it before, but for some obscure reason it is passing on my computer:if [ upgrade != "$1 || dpkg --compare-versions "$2" lt 1.0-2; then I've checked it again and I've fixed it. Will upload soon. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823706 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898310 [3] https://www.debian.org/doc/debian-policy/ap-pkg-diversions.html-- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#941093: ping!
On Tue, Oct 22, 2019 at 09:57:16PM +0200, Paul Gevers wrote: > I have scheduled those. First build failures are appearing. Can you > please check? > > https://buildd.debian.org/status/package.php?p=deepin-qt5dxcb-plugin > https://buildd.debian.org/status/package.php?p=xdg-desktop-portal-kde > https://buildd.debian.org/status/package.php?p=libfm-qt > https://buildd.debian.org/status/package.php?p=pyqt5 Oh! I will fix xdg-desktop-portal-kde and pyqt5 myself, and file bugs for the other two. For deepin-qt5dxcb-plugin there was #935105 but the new failure is different, so I think a new bug is better. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#942885: isdnactivecards: FTBFS in sid: icnctrl.c:75:10: fatal error: linux/isdn.h: No such file or directory
Control: tag 942885 confirmed wontfix Andreas Beckmann wrote... > Package: isdnactivecards > Version: 1:3.12.2007-11-27-1 > Severity: serious > Tags: sid bullseye ftbfs Haven't checked, but bullseye /should/ still build. Not for long, though. > isdnactivecards cannot be built in sid any longer: Jepp, isdn4linux is history. RM will follow in a few days, intent to remove is at #934358. Christoph PS: Same for isdnutils, no need to file a bug report. signature.asc Description: PGP signature
Bug#936585: gbirthday: Python2 removal in sid/bullseye
Hi. Last gbirthday maintainer speaking. The gbirthday package is more or less dead upstream, unless someone volunteers to take it over. I ported gbirthday to qt. Here is qbirthday: https://github.com/lafrech/qbirthday https://pypi.org/project/qbirthday/ There are a few changes from GBirthday but the idea and the look remain the same. I don't have time and knowledge to package it for Debian myself, but I'd be willing to help. The fact that I created a setup.py could help building the package. -- Jérôme
Bug#939259: webcheck: Python2 removal in sid/bullseye
On Mon, 2019-09-02 at 15:09 +0200, Stefano Rivera wrote: > Your package either build-depends, depends on Python2, or uses > Python2 in the autopkg tests. Please stop using Python2, and fix > this issue by one of the following actions. > > - Convert your Package to Python3. I would like to do this but it requires some time that I don't have a lot of available at the moment. Any help will we appreciated. The upstream repo has a lot of changes relative to the latest release because there was a plan to improve performance and make the tool a bit more lightweight (most of that was done). While the code in the repo should be reasonably stable it is not as nice as it could be and I would also like to switch to using requests and a few other things but it kind of lost focus on it :( Anyway, help is very welcome. I'm also not too adverse to removal from testing to help the Python 2 migration along. -- -- arthur - adej...@debian.org - https://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Bug#942415: transition: meta-kde
Control: tags -1 -moreinfo Hi Paul, > On 15-10-2019 23:53, Sandro Knauß wrote: > > I'm not sure, what ben rules you want, I can create ben rules for all > > 38 packages, but as the 57 packages are get a new upload anyways, > > those get recompiled anyways. > > This sounds like one transition, so I think we want *one* ben file. > Don't you want all is_affected/is_good/is_bad or-ed together? Well I can merge those is_affected/is_bad/is_good lines together, but from my point of view that means, that the status is not tracked correctly. As a reverse dependency may depend on two or more packages in KDEPIM and the is_good line would be true if the package get built against any of those packages. But maybe this is normal for transitions because in the end it is only a question of when to request the binnmu. > > So I decided to start with those 18 packages, that affects by the > > external packages, those are: > > blogilo (broken in sid anyways / upstream is dead) > > calligra > > calligraplan > > kio-gdrive > > kjots > > kmymoney > > kraft > > zanshin > > I'm not sure I understand what you meant. Let me rephrase what I think > you wanted to say. You created the ben files for 18 source packages. > Those 18 source packages provide the 8 listed source packages above with > (build) dependencies. The other KDEPIM source packages in this > transition don't have reverse dependencies that need rebuilding outside > of the KDEPIM packages? Right, all others don't have any (build) reverse dependencies outside KDEPIM. > > Paul signature.asc Description: This is a digitally signed message part.
Bug#942888: libsystemd-dev 243-3 depends on libsystemd0 = 242-7, not installable
Package: libsystemd-dev Version: 243-3 Severity: normal Dear Maintainer, libsystemd-dev 243-3 depends on libsystemd0 242-7 and cannot therefore install. $ sudo apt install libsystemd-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libsystemd-dev : Depends: libsystemd0 (= 242-7) E: Unable to correct problems, you have held broken packages. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libsystemd-dev depends on: ii libsystemd0 243~rc2-1 libsystemd-dev recommends no packages. libsystemd-dev suggests no packages.
Bug#941093: ping!
Hi Dmitry, On 22-10-2019 17:49, Dmitry Shachnev wrote: > You can start scheduling binNMUs already. An extra build-dependency on > qtbase5-dev (>= 5.12) is enough to make sure it builds against the new > version. For qtcreator, please also add qbs-dev (>= 1.13). I have scheduled those. First build failures are appearing. Can you please check? https://buildd.debian.org/status/package.php?p=deepin-qt5dxcb-plugin https://buildd.debian.org/status/package.php?p=xdg-desktop-portal-kde https://buildd.debian.org/status/package.php?p=libfm-qt https://buildd.debian.org/status/package.php?p=pyqt5 Paul signature.asc Description: OpenPGP digital signature
Bug#942887: python-fabio: autopkgtest failure.
Package: python-fabio Version: 0.9.0+dfsg-2 Severity: serious Python-fabio's autopkgtest is failing, == ERROR: testFullFormatName (fabio.test.testfabioconvert.TestFabioConvert) -- Traceback (most recent call last): File "/usr/lib/python3/dist-packages/fabio/test/testfabioconvert.py", line 135, in testFullFormatName image = fabio.open("output/03.npy") File "/usr/lib/python3/dist-packages/fabio/openimage.py", line 159, in openimage obj = obj.read(obj.filename, frame) File "/usr/lib/python3/dist-packages/fabio/numpyimage.py", line 161, in read self.dataset = numpy.load(infile) File "/usr/lib/python3/dist-packages/numpy/lib/npyio.py", line 447, in load pickle_kwargs=pickle_kwargs) File "/usr/lib/python3/dist-packages/numpy/lib/format.py", line 696, in read_array raise ValueError("Object arrays cannot be loaded when " ValueError: Object arrays cannot be loaded when allow_pickle=False -- This appears to be happening during both the unstable->testing migration tests and the pure unstable tests, but not during the pure testing tests.
Bug#942537: Please package newer version
On 2019-10-21 10:01:43, Sven Hoexter wrote: > On Sun, Oct 20, 2019 at 02:38:28PM +0200, Sven Hoexter wrote: > > Hi, > > > > 2) You can also update it to fio 3.16 and upload that. I would be okay > > > with an NMU. > > > > I currently look into this option. Since we set it up on Salsa in the > > Debian group, I can update the package. But let me see if it builds here. > > I just uploaded 3.16 and pushed everything to salsa. Had to add a small > oneline fix from upstream to get the gfio stuff to build. The patch can > be removed with 3.17+. > > Hope that helps for now, didn't do any polishing of typos. Thank you very much!
Bug#942886: linux-image-5.3.0-1-amd64: Can not modprobe "snd_hda_codec_hdmi"
Package: src:linux Version: 5.3.7-1 Severity: important Dear Maintainer, After upgrade kernel to linux-image-5.3.0-1-amd64, I can not modprobe "snd_hda_codec_hdmi" any more, it show the error message, modprobe: ERROR: could not insert 'snd_hda_codec_hdmi': Key was rejected by service and my monitor no sound output. Please help, thank you. *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- Package-specific info: ** Version: Linux version 5.3.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 20191008 (Debian 9.2.1-9)) #1 SMP Debian 5.3.7-1 (2019-10-19) ** Command line: BOOT_IMAGE=/vmlinuz-5.3.0-1-amd64 root=/dev/mapper/nvme0n1p1_crypt ro rootflags=subvol=rootfs apparmor=1 security=apparmor nosmt rootfstype=btrfs rootflags=subvol=rootfs quiet ** Not tainted ** Kernel log: [7.126154] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this. [7.127219] snd_hda_codec_generic hdaudioC0D0: autoconfig for Generic: line_outs=0 (0x0/0x0/0x0/0x0/0x0) type:line [7.127221] snd_hda_codec_generic hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [7.127222] snd_hda_codec_generic hdaudioC0D0:hp_outs=0 (0x0/0x0/0x0/0x0/0x0) [7.127222] snd_hda_codec_generic hdaudioC0D0:mono: mono_out=0x0 [7.127223] snd_hda_codec_generic hdaudioC0D0:dig-out=0x3/0x0 [7.127223] snd_hda_codec_generic hdaudioC0D0:inputs: [7.127667] input: HDA Intel HDMI HDMI as /devices/pci:00/:00:03.0/sound/card0/input17 [7.153862] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null) [7.181175] Rounding down aligned max_sectors from 4294967295 to 4294967288 [7.181662] db_root: cannot open: /etc/target [7.245336] Adding 1952764k swap on /dev/mapper/swap. Priority:-2 extents:1 across:1952764k SSFS [7.279906] bcache: bch_journal_replay() journal replay done, 177 keys in 12 entries, seq 6365286 [7.289114] bcache: bch_cached_dev_attach() Caching sda1 as bcache0 on set 3ec1b954-b969-438d-b264-91a36d2a1a4c [7.289136] bcache: register_cache() registered cache device dm-5 [7.298596] intel_rapl_common: Found RAPL domain package [7.298598] intel_rapl_common: Found RAPL domain core [7.298598] intel_rapl_common: Found RAPL domain uncore [7.298599] intel_rapl_common: Found RAPL domain dram [ 11.171939] BTRFS: device fsid b6b55d64-9811-4f26-9d77-f5af7750193f devid 1 transid 2690791 /dev/dm-8 [ 11.189503] BTRFS info (device dm-8): enabling ssd optimizations [ 11.189504] BTRFS info (device dm-8): turning on discard [ 11.189507] BTRFS info (device dm-8): use lzo compression, level 0 [ 11.189508] BTRFS info (device dm-8): disk space caching is enabled [ 11.189509] BTRFS info (device dm-8): has skinny extents [ 11.269858] audit: type=1400 audit(1571773003.787:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/tcpdump" pid=949 comm="apparmor_parser" [ 11.270455] audit: type=1400 audit(1571773003.787:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="transmission" pid=950 comm="apparmor_parser" [ 11.270943] audit: type=1400 audit(1571773003.787:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/gpicview" pid=948 comm="apparmor_parser" [ 11.272458] audit: type=1400 audit(1571773003.787:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="un-archiver" pid=951 comm="apparmor_parser" [ 11.272475] audit: type=1400 audit(1571773003.787:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/wget" pid=952 comm="apparmor_parser" [ 11.274990] audit: type=1400 audit(1571773003.791:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/xarchiver" pid=953 comm="apparmor_parser" [ 11.275621] audit: type=1400 audit(1571773003.791:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="rsyslogd" pid=954 comm="apparmor_parser" [ 11.276773] audit: type=1400 audit(1571773003.791:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/filezilla" pid=955 comm="apparmor_parser" [ 11.277188] audit: type=1400 audit(1571773003.795:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-oopslash" pid=956 comm="apparmor_parser" [ 11.278016] audit: type=1400 audit(1571773003.795:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/pavucontrol" pid=957 comm="apparmor_parser" [ 11.463897] new mount options do not match the existing superblock, will be
Bug#942885: isdnactivecards: FTBFS in sid: icnctrl.c:75:10: fatal error: linux/isdn.h: No such file or directory
Package: isdnactivecards Version: 1:3.12.2007-11-27-1 Severity: serious Tags: sid bullseye ftbfs Justification: fails to build from source (but built successfully in the past) Hi, isdnactivecards cannot be built in sid any longer: [...] make[3]: Entering directory '/build/isdnactivecards-3.12.2007-11-27/icn' gcc -g -O2 -fdebug-prefix-map=/build/isdnactivecards-3.12.2007-11-27=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -I. -c -o icnctrl.o icnctrl.c icnctrl.c:75:10: fatal error: linux/isdn.h: No such file or directory 75 | #include | ^~ compilation terminated. make[3]: *** [Makefile:34: icnctrl.o] Error 1 make[3]: Leaving directory '/build/isdnactivecards-3.12.2007-11-27/icn' [...] Andreas isdnactivecards_1:3.12.2007-11-27-1.log.gz Description: application/gzip
Bug#942415: transition: meta-kde
Control: tags -1 moreinfo Hi Sandro, On 15-10-2019 23:53, Sandro Knauß wrote: > I'm not sure, what ben rules you want, I can create ben rules for all > 38 packages, but as the 57 packages are get a new upload anyways, > those get recompiled anyways. This sounds like one transition, so I think we want *one* ben file. Don't you want all is_affected/is_good/is_bad or-ed together? > So I decided to start with those 18 packages, that affects by the > external packages, those are: > blogilo (broken in sid anyways / upstream is dead) > calligra > calligraplan > kio-gdrive > kjots > kmymoney > kraft > zanshin I'm not sure I understand what you meant. Let me rephrase what I think you wanted to say. You created the ben files for 18 source packages. Those 18 source packages provide the 8 listed source packages above with (build) dependencies. The other KDEPIM source packages in this transition don't have reverse dependencies that need rebuilding outside of the KDEPIM packages? Paul signature.asc Description: OpenPGP digital signature
Bug#942884: RFS: zipios/2.2.5.0-1 -- small C++ library for reading zip files (development)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "zipios" * Package name: zipios Version : 2.2.5.0-1 Upstream Author : Thomas Sondergaard * URL : http://zipios.sourceforge.net/ * License : LGPL-2+ * Vcs : https://salsa.debian.org/mzf-guest/zipios Section : devel It builds those binary packages: libzipios-dev - small C++ library for reading zip files (development) libzipios2 - small C++ library for reading zip files (library) libzipios-doc - small C++ library for reading zip files (documents) libzipios++0v5 - transitional package To access further information about this package, please visit the following URL: https://mentors.debian.net/package/zipios Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/z/zipios/zipios_2.2.5.0-1.dsc Changes since the last upload: * Import new upstream release (Closes: #834171) * Add watch file * Fix reproducible issue with doxygen documentation * Rename to Zipios from Zipios++ * Rename to libzipios2 from libzipios0v5 and create a transition package. * Add autopkgtest * Add upstream metadata * Bump standard version to 4.4.1 Regards,
Bug#935969: linux-image-5.2.0-2-amd64: Missing firmware for new driver rtwpci
Package: firmware-realtek Version: 20190717-2 Followup-For: Bug #935969 Hi, The cause of the bug is that the rules.gen file does not include the rtw88 firmware files. The attached patch solves the problem (at least for me). Kind regards, Andrea Palazzi -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-1-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-realtek depends on no packages. firmware-realtek recommends no packages. Versions of packages firmware-realtek suggests: ii initramfs-tools 0.135 -- no debconf information --- rules.gen.orig 2019-10-22 21:14:32.320024105 +0200 +++ rules.gen 2019-10-22 21:13:07.251925642 +0200 @@ -46,7 +46,7 @@ binary-indep:: $(MAKE) -f debian/rules.real binary-indep FILES='cbfw-3.2.3.0.bin:cbfw-3.2.3.0.bin cbfw-3.2.5.1.bin:cbfw-3.2.5.1.bin ct2fw-3.2.3.0.bin:ct2fw-3.2.3.0.bin ct2fw-3.2.5.1.bin:ct2fw-3.2.5.1.bin ctfw-3.2.3.0.bin:ctfw-3.2.3.0.bin ctfw-3.2.5.1.bin:ctfw-3.2.5.1.bin qed/qed_init_values_zipped-8.10.10.0.bin:qed/qed_init_values_zipped-8.10.10.0.bin qed/qed_init_values_zipped-8.33.1.0.bin:qed/qed_init_values_zipped-8.33.1.0.bin qed/qed_init_values_zipped-8.33.11.0.bin:qed/qed_init_values_zipped-8.33.11.0.bin qed/qed_init_values_zipped-8.37.2.0.bin:qed/qed_init_values_zipped-8.37.2.0.bin qlogic/1040.bin:qlogic/1040.bin qlogic/1280.bin:qlogic/1280.bin qlogic/12160.bin:qlogic/12160.bin qlogic/sd7220.fw:qlogic/sd7220.fw ql2100_fw.bin:ql2100_fw.bin ql2200_fw.bin:ql2200_fw.bin ql2300_fw.bin:ql2300_fw.bin ql2322_fw.bin:ql2322_fw.bin ql2400_fw.bin:ql2400_fw.bin ql2500_fw.bin:ql2500_fw.bin' LINKS='' PACKAGE='qlogic' binary-indep:: - $(MAKE) -f debian/rules.real binary-indep FILES='RTL8192E/boot.img:RTL8192E/boot.img RTL8192E/data.img:RTL8192E/data.img RTL8192E/main.img:RTL8192E/main.img rtl_bt/rtl8192ee_fw.bin:rtl_bt/rtl8192ee_fw.bin rtl_bt/rtl8812ae_fw.bin:rtl_bt/rtl8812ae_fw.bin rtl_bt/rtl8761a_fw.bin:rtl_bt/rtl8761a_fw.bin rtl_bt/rtl8821a_fw.bin:rtl_bt/rtl8821a_fw.bin rtl_bt/rtl8192eu_fw.bin:rtl_bt/rtl8192eu_fw.bin rtl_bt/rtl8723a_fw.bin:rtl_bt/rtl8723a_fw.bin rtl_bt/rtl8723b_fw.bin:rtl_bt/rtl8723b_fw.bin rtl_bt/rtl8723d_config.bin:rtl_bt/rtl8723d_config.bin rtl_bt/rtl8723d_fw.bin:rtl_bt/rtl8723d_fw.bin rtl_bt/rtl8821c_config.bin:rtl_bt/rtl8821c_config.bin rtl_bt/rtl8821c_fw.bin:rtl_bt/rtl8821c_fw.bin rtl_bt/rtl8822b_config.bin:rtl_bt/rtl8822b_config.bin rtl_bt/rtl8822b_fw.bin:rtl_bt/rtl8822b_fw.bin rtl_bt/rtl8822cu_fw.bin:rtl_bt/rtl8822cu_fw.bin rtl_nic/rtl8105e-1.fw:rtl_nic/rtl8105e-1.fw rtl_nic/rtl8106e-1.fw:rtl_nic/rtl8106e-1.fw rtl_nic/rtl8106e-2.fw:rtl_nic/rtl8106e-2.fw rtl_nic/rtl8107e-1.fw:rtl_nic/rtl8107e-1.fw rtl_nic/rtl8107e-2.fw:rtl_nic/rtl8107e-2.fw rtl_nic/rtl8168d-1.fw:rtl_nic/rtl8168d-1.fw rtl_nic/rtl8168d-2.fw:rtl_nic/rtl8168d-2.fw rtl_nic/rtl8168e-1.fw:rtl_nic/rtl8168e-1.fw rtl_nic/rtl8168e-2.fw:rtl_nic/rtl8168e-2.fw rtl_nic/rtl8168e-3.fw:rtl_nic/rtl8168e-3.fw rtl_nic/rtl8168f-1.fw:rtl_nic/rtl8168f-1.fw rtl_nic/rtl8168f-2.fw:rtl_nic/rtl8168f-2.fw rtl_nic/rtl8168g-1.fw:rtl_nic/rtl8168g-1.fw rtl_nic/rtl8168g-2.fw:rtl_nic/rtl8168g-2.fw rtl_nic/rtl8168g-3.fw:rtl_nic/rtl8168g-3.fw rtl_nic/rtl8168h-1.fw:rtl_nic/rtl8168h-1.fw rtl_nic/rtl8168h-2.fw:rtl_nic/rtl8168h-2.fw rtl_nic/rtl8402-1.fw:rtl_nic/rtl8402-1.fw rtl_nic/rtl8411-1.fw:rtl_nic/rtl8411-1.fw rtl_nic/rtl8411-2.fw:rtl_nic/rtl8411-2.fw rtlwifi/rtl8188efw.bin:rtlwifi/rtl8188efw.bin rtlwifi/rtl8188eufw.bin:rtlwifi/rtl8188eufw.bin rtlwifi/rtl8192cfw.bin:rtlwifi/rtl8192cfw.bin rtlwifi/rtl8192cfwU_B.bin:rtlwifi/rtl8192cfwU_B.bin rtlwifi/rtl8192cfwU.bin:rtlwifi/rtl8192cfwU.bin rtlwifi/rtl8192cufw_A.bin:rtlwifi/rtl8192cufw_A.bin rtlwifi/rtl8192cufw_B.bin:rtlwifi/rtl8192cufw_B.bin rtlwifi/rtl8192cufw_TMSC.bin:rtlwifi/rtl8192cufw_TMSC.bin rtlwifi/rtl8192cufw.bin:rtlwifi/rtl8192cufw.bin rtlwifi/rtl8192defw.bin:rtlwifi/rtl8192defw.bin rtlwifi/rtl8192eefw.bin:rtlwifi/rtl8192eefw.bin rtlwifi/rtl8192eu_nic.bin:rtlwifi/rtl8192eu_nic.bin rtlwifi/rtl8192eu_wowlan.bin:rtlwifi/rtl8192eu_wowlan.bin rtlwifi/rtl8192sefw.bin:rtlwifi/rtl8192sefw.bin rtlwifi/rtl8712u.bin:rtlwifi/rtl8712u.bin rtlwifi/rtl8723aufw_A.bin:rtlwifi/rtl8723aufw_A.bin rtlwifi/rtl8723aufw_B.bin:rtlwifi/rtl8723aufw_B.bin rtlwifi/rtl8723aufw_B_NoBT.bin:rtlwifi/rtl8723aufw_B_NoBT.bin rtlwifi/rtl8723befw_36.bin:rtlwifi/rtl8723befw_36.bin rtlwifi/rtl8723befw.bin:rtlwifi/rtl8723befw.bin rtlwifi/rtl8723bs_bt.bin:rtlwifi/rtl8723bs_bt.bin rtlwifi/rtl8723bs_nic.bin:rtlwifi/rtl8723bs_nic.bin rtlwifi/rtl8723bs_wowlan.bin:rtlwifi/rtl8723bs_wowlan.bin rtlwifi/rtl8723bu_nic.bin:rtlwifi/rtl8723bu_nic.bin rtlwifi/rtl8723bu_wo
Bug#942883: libqt5xdgiconloader3: Dependency upon qtbase-abi-5-11-3 prevents installation
Package: libqt5xdgiconloader3 Version: 3.3.1-2 Severity: important Dear Maintainer, A dependency issue is preventing installation of this package, causing lxqt-core components to uninstall, thus breaking existing lxqt installation. See output below: $ sudo apt install lxqt-core Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: lxqt-core : Depends: lxqt-config but it is not going to be installed Depends: lxqt-notificationd but it is not going to be installed Depends: lxqt-globalkeys but it is not going to be installed Depends: lxqt-panel but it is not going to be installed Depends: lxqt-policykit but it is not going to be installed Depends: lxqt-qtplugin but it is not going to be installed Depends: lxqt-runner but it is not going to be installed Depends: lxqt-session but it is not going to be installed Depends: pcmanfm-qt but it is not going to be installed $ sudo apt install lxqt-notificationd Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: lxqt-notificationd : Depends: liblxqt0 (>= 0.14.1~) but it is not going to be installed Depends: libqt5xdg3 (>= 1.0.0) but it is not going to be installed $ sudo apt install libqt5xdg3 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libqt5xdg3 : Depends: libqt5xdgiconloader3 (>= 3.0.0) but it is not going to be installed E: Unable to correct problems, you have held broken packages. $ sudo apt install libqt5xdgiconloader3 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libqt5xdgiconloader3 : Depends: qtbase-abi-5-11-3 but it is not installable E: Unable to correct problems, you have held broken packages. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libqt5xdgiconloader3 depends on: ii libc6 2.29-2 ii libqt5core5a 5.12.5+dfsg-2 ii libqt5gui5 5.12.5+dfsg-2 ii libstdc++6 9.2.1-9 pn qtbase-abi-5-11-3 Versions of packages libqt5xdgiconloader3 recommends: ii gtk-update-icon-cache 3.24.12-1 libqt5xdgiconloader3 suggests no packages.
Bug#941018: ibus 1.5.21-1 does not work with qt5 applications
On 2019-10-22 20:58, Simon McVittie wrote: On Tue, 22 Oct 2019 at 19:30:51 +0200, Gunnar Hjalmarsson wrote: @Simon: Any thoughts on the status of your glib MR? Is it safe enough to patch glib2.0 in Debian, and with that fix this bug? I don't think we should be applying changes this significant to code this important (it's at a security boundary) without proper review. If you consider my proposed code changes to be correct (apart from the memory leak that I just spotted, which I'll fix when I get a chance), please say so on the upstream merge request. Those changes are over my head, so I'm not able to tell whether they are "correct". But I added a comment with the purpose of encouraging reviews soon. :) -- Gunnar Hjalmarsson https://launchpad.net/~gunnarhj
Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5
Control: severity 887831 grave On 2019-10-22 12:39:47, Daniel Kahn Gillmor wrote: > I would even posit that temporarily breaking jigdo would be better than > keeping this additional bandwidth cost in play. Yes. In fact, right now, I can't think of any use case for Jigdo. It's been totally superseded by bittorrent, which is standardized, widely available and much more popular, with multiple client implementations. Fedora stopped shipping their releases with Jigdo in 2011, according to wikipedia: https://en.wikipedia.org/wiki/Jigdo WP also says development has stopped since 2006. On 2019-10-22 19:15:51, Thomas Schmitt wrote: > To my knowledge, jigdo is the only way to get full DVD sets or any BD sized > installation ISO from > https://cdimage.debian.org/cdimage/release/current/amd64/ > > bt-* seems t have what iso-* has. Biggest is the 5.3 GB > debian-edu-10.1.0-amd64-BD-1.iso which would fit on a DVD+R DL, too. > Only the first three DVDs are offered by iso-* and bt-*. If the ISO image generation is broken, it should be fixed. I don't see why we should depend on jigdo for anything anymore. In the meantime, I think it's perfectly acceptable to remove MD5sums from the archive, at the cost of breaking jigdo. Or, to put it another way, it's completely unacceptable that jigdo uses MD5 to authenticate checksums, and if it keeps doing so, we shouldn't ship Debian with it. That is a release-critical bug, severity "grave" with justification "introduces a security hole allowing access to the accounts of users who use the package". A. -- Gods don't like people not doing much work. People who aren't busy all the time might start to think. - Terry Pratchett, Small Gods signature.asc Description: PGP signature
Bug#407722: Job Offer For You.
We have a job offer for you. Reply to this email for more details. Wen Li Zhang
Bug#932971: ITP: squashfs-tools-ng -- A new set of tools for working with SquashFS images
On Wed, Oct 16, 2019 at 9:45 PM Johannes Schauer wrote: > On Thu, 25 Jul 2019 11:51:00 +0200 László Böszörményi (GCS) > wrote: > > * Package name: squashfs-tools-ng > I see the package is still waiting in NEW. > > Where did you put the packaging VCS? I'd like to play around with it before > ftp > master manages to approve it. :) You can get the updated, 0.7-1 release[1], but please note that its self-testing is constantly failing: FAIL: test_fstree_init == test_fstree_init: tests/fstree_init.c:32: main: Assertion `fs.defaults.st_mtime == 0' failed. FAIL test_fstree_init (exit status: 134) Can you check it David? I've tried it on three machines. Two of these are running on amd64 and one is on i386 architecture. Regards, Laszlo/GCS [1] http://www.barcikacomp.hu/gcs/squashfs-tools-ng_0.7-1.dsc
Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5
On Tue 2019-10-22 19:15:51 +0200, Thomas Schmitt wrote: > Daniel Kahn Gillmor wrote: >> I would even posit that temporarily breaking jigdo would be better than >> keeping this additional bandwidth cost in play. > > To my knowledge, jigdo is the only way to get full DVD sets or any BD sized > installation ISO from > https://cdimage.debian.org/cdimage/release/current/amd64/ I understand what you're saying (though i haven't used optical media to install debian in over a decade). If jigdo would use the SHA256sum entries instead of the MD5 entries when it is doing ISO assembly, then everyone could still fetch full DVD sets or BD sized installation ISOs, without every single debian user expending the extra 13% bandwidth on fetching the Packages file when they "apt get update". AFAICT, jigdo's last maintenance release (debian version) was nearly two years ago. The last upsteam release (0.7.3) was produced in 2006. Its homepage is http://atterer.org/jigdo/devel.html , which was last updated in 2010, and points to a CVS server i cannot access. Its debian packaging doesn't have a Vcs-* field (though i've just created https://salsa.debian.org/debian/jigdo and uploaded what i could get from "gbp import-dscs --pristine-tar --debsnap" to it). This looks like it might be a moribund software project, and it should not be holding back the rest of the project from making other improvements. Making the Packages file smaller is a concrete advantage for every debian user. Do you have any suggestions to offer to make jigdo work using a modern cryptographic digest? --dkg signature.asc Description: PGP signature
Bug#602788: read /sys/class/tty/console/active
Control: tag -1 +patch Hi, The attached patch should (I will test it tomorrow) fix the problem. -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics --- live-config-getty-generator.orig 2019-10-22 21:06:50.858966292 +0200 +++ live-config-getty-generator 2019-05-19 10:11:26.0 +0200 @@ -73,9 +73,9 @@ # Configure autologin if [ -n "${LIVE_USERNAME}" ] then - for TTY in tty1 tty2 tty3 tty4 tty5 tty6 $(cat /sys/class/tty/console/active) + for NUMBER in $(seq 1 6) do - GETTY_SERVICE_D=$SYSTEMD_DIR/getty@${TTY}.service.d + GETTY_SERVICE_D=$SYSTEMD_DIR/getty@tty${NUMBER}.service.d CONF=$GETTY_SERVICE_D/live-config_autologin.conf mkdir -p $GETTY_SERVICE_D
Bug#941018: ibus 1.5.21-1 does not work with qt5 applications
On Tue, 22 Oct 2019 at 19:30:51 +0200, Gunnar Hjalmarsson wrote: > Simon has prepared a fix of this issue via a glib merge request: > > https://gitlab.gnome.org/GNOME/glib/merge_requests/1176 > > I applied the diff from that MR on top of glib2.0 2.62.1-1, and based on my > limited tests it appears to fix the issue with IBus in Qt apps. > > @Simon: Any thoughts on the status of your glib MR? Is it safe enough to > patch glib2.0 in Debian, and with that fix this bug? I don't think we should be applying changes this significant to code this important (it's at a security boundary) without proper review. If you consider my proposed code changes to be correct (apart from the memory leak that I just spotted, which I'll fix when I get a chance), please say so on the upstream merge request. smcv
Bug#942882: moving things around with PYBUILD_EXT_DESTDIR_* doesn't seem to work
Package: dh-python Version: 4.20191017 The handling of the changed extension names in 3.8 is a little bit tricky, and you suggested to use PYBUILD_NAME and PYBUILD_EXT_DESTDIR_*. Here is a try to do that The changed packaging has other bugs, but it show that the extensions are not moved into the -lib packages. diff -Nru pytables-3.5.2/debian/changelog pytables-3.5.2/debian/changelog --- pytables-3.5.2/debian/changelog 2019-08-16 19:53:28.0 +0200 +++ pytables-3.5.2/debian/changelog 2019-10-22 13:04:06.0 +0200 @@ -1,3 +1,25 @@ +pytables (3.5.2-3ubuntu2) UNRELEASED; urgency=medium + + [ Michael Hudson-Doyle ] + * Fix build with Python 3.8 in a way that does not break Python 2.7. + + [ Matthias Klose ] + * Fix installation of Python 3.8 extensions. + + -- Matthias Klose Tue, 22 Oct 2019 13:04:06 +0200 + +pytables (3.5.2-3ubuntu1) focal; urgency=medium + + * Fix build with Python3.8. + + -- Matthias Klose Mon, 21 Oct 2019 11:25:19 +0200 + +pytables (3.5.2-3build1) focal; urgency=medium + + * No-change rebuild to build with python3.8. + + -- Matthias Klose Fri, 18 Oct 2019 18:33:41 + + pytables (3.5.2-3) unstable; urgency=medium * debian/rules: diff -Nru pytables-3.5.2/debian/control pytables-3.5.2/debian/control --- pytables-3.5.2/debian/control 2019-08-16 19:53:28.0 +0200 +++ pytables-3.5.2/debian/control 2019-10-22 13:04:06.0 +0200 @@ -1,5 +1,6 @@ Source: pytables -Maintainer: Debian Science Maintainers +Maintainer: Ubuntu Developers +XSBC-Original-Maintainer: Debian Science Maintainers Uploaders: Antonio Valentino , Yaroslav Halchenko Section: python diff -Nru pytables-3.5.2/debian/patches/python3.8-fix.diff pytables-3.5.2/debian/patches/python3.8-fix.diff --- pytables-3.5.2/debian/patches/python3.8-fix.diff 1970-01-01 01:00:00.0 +0100 +++ pytables-3.5.2/debian/patches/python3.8-fix.diff 2019-10-22 13:04:06.0 +0200 @@ -0,0 +1,51 @@ +--- a/tables/index.py b/tables/index.py +@@ -23,7 +23,11 @@ + import tempfile + import warnings + +-from time import time, clock ++from time import time ++try: ++from time import perf_counter ++except ImportError: ++from time import clock + + import numpy + +@@ -847,7 +851,7 @@ + + if self.verbose: + t1 = time() +-c1 = clock() ++c1 = perf_counter() + ss = self.slicesize + tmp = self.tmp + ranges = tmp.ranges[:] +@@ -953,7 +957,7 @@ + self.compute_overlaps(self.tmp, "do_complete_sort()", self.verbose) + if self.verbose: + t = round(time() - t1, 4) +-c = round(clock() - c1, 4) ++c = round(perf_counter() - c1, 4) + print("time: %s. clock: %s" % (t, c)) + + def swap(self, what, mode=None): +@@ -968,7 +972,7 @@ + + if self.verbose: + t1 = time() +-c1 = clock() ++c1 = perf_counter() + if what == "chunks": + self.swap_chunks(mode) + elif what == "slices": +@@ -982,7 +986,7 @@ + rmult = len(mult.nonzero()[0]) / float(len(mult)) + if self.verbose: + t = round(time() - t1, 4) +-c = round(clock() - c1, 4) ++c = round(perf_counter() - c1, 4) + print("time: %s. clock: %s" % (t, c)) + # Check that entropy is actually decreasing + if what == "chunks" and self.last_tover > 0. and self.last_nover > 0: diff -Nru pytables-3.5.2/debian/patches/series pytables-3.5.2/debian/patches/series --- pytables-3.5.2/debian/patches/series 2019-08-16 19:53:28.0 +0200 +++ pytables-3.5.2/debian/patches/series 2019-10-21 11:24:20.0 +0200 @@ -4,3 +4,4 @@ 0004-remove-gtags.patch 0005-Drop-mock-for-requirements.txt.patch 0006-Skip-index-backcompat-tests-on-bingendian.patch +python3.8-fix.diff diff -Nru pytables-3.5.2/debian/python3-tables-dbg.install pytables-3.5.2/debian/python3-tables-dbg.install --- pytables-3.5.2/debian/python3-tables-dbg.install 2019-08-16 19:53:28.0 +0200 +++ pytables-3.5.2/debian/python3-tables-dbg.install 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -usr/lib/python3*/*-packages/tables/*.cpython-3?dm*.so diff -Nru pytables-3.5.2/debian/python3-tables.install pytables-3.5.2/debian/python3-tables.install --- pytables-3.5.2/debian/python3-tables.install 2019-08-16 19:53:28.0 +0200 +++ pytables-3.5.2/debian/python3-tables.install 1970-01-01 01:00:00.0 +0100 @@ -1,8 +0,0 @@ -usr/lib/python3*/dist-packages/tables/*.py -usr/lib/python3*/dist-packages/tables/misc/*.py -usr/lib/python3*/dist-packages/tables/nodes/*.py -usr/lib/python3*/dist-packages/tables/nodes/tests/*.py -usr/lib/python3*/dist-packages/tables/scripts/*.py -usr/lib/python3*/dist-packages/tables/tests/*.py -usr/lib/python3*/dist-packages/tables*.egg-info -usr/bin/* diff -Nru pytables-3.5.2/debian/python3-tables-lib.install pytables-3.5.2/debian/python3-tables-lib.install --- pytables-3.5.2/debi
Bug#942881: Audio on Lenovo X1 Carbon 5th generation stopped working after upgrade to linux-image-5.3.0-1-amd64 ("No response from codec")
Package: src:linux Version: 5.3.7-1 Severity: normal After upgrading to linux-image-5.3.0-1-amd64, I get messages like those seen in the log ("No response from codec, resetting bus" and "Unable to sync register"), and eventually a WARN. The mixer doesn't show the audio device at all. This didn't happen with the previous kernel, namely: Oct 21 21:04:28 s kernel: Linux version 5.2.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-23)) #1 SMP Debian 5.2.17-1 (2019-10-06) -- Package-specific info: ** Version: Linux version 5.3.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 20191008 (Debian 9.2.1-9)) #1 SMP Debian 5.3.7-1 (2019-10-19) ** Command line: BOOT_IMAGE=/vmlinuz-5.3.0-1-amd64 root=UUID=121586a4-bf8c-49a4-9a72-ed70fcf72772 ro quiet ** Tainted: W (512) * Taint on warning. ** Kernel log: [ 59.442968] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20170500 [ 60.448988] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20270500 [ 61.454722] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20370500 [ 62.460306] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x201f0500 [ 63.493654] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20170500 [ 64.498615] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20270500 [ 65.507773] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20370500 [ 66.516498] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x201f0500 [ 67.557305] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20170500 [ 68.569978] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20270500 [ 69.578573] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20370500 [ 70.587072] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x201f0500 [ 71.627548] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20170500 [ 72.635462] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20270500 [ 73.639361] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20370500 [ 74.651383] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x201f0500 [ 75.687274] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20170500 [ 76.691051] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20270500 [ 77.694902] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20370500 [ 78.702874] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x201f0500 [ 79.734778] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20170500 [ 80.738684] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20270500 [ 81.742564] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20370500 [ 82.746472] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x201f0500 [ 83.786414] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20170500 [ 84.798403] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20270500 [ 85.810293] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20370500 [ 86.822260] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x201f0500 [ 87.862207] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20170500 [ 88.866163] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20270500 [ 89.874103] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20370500 [ 90.885985] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x201f0500 [ 91.926013] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20170500 [ 92.929911] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20270500 [ 93.938042] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20370500 [ 94.945841] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x201f0500 [ 95.981858] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20370740 [ 96.985920] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20370740 [ 97.997872] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20270d80 [ 97.997891] snd_hda_codec_generic hdaudioC0D2: Unable to sync register 0x2f0d00. -11 [ 99.009847] snd_hda_intel :00:1f.3
Bug#883194: please convert mountstats and nfsiostat scripts to Python3
On Thu, 30 Nov 2017 16:37:52 +0100 Matthias Klose wrote: > > the changelog reads: > > - nfs-common: Add Recommends python for mountstats and nfsiostat > > Please convert these scripts to python3, and recommend Python3 instead. > I think they should already be compatible with python3 since 1.2.9 (or 1.3.1) if I'm looking at upstream git repository: http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=9f9289efda1a7eff26cd046997efc56c2de40534 http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=1df82a36df74a59f55eea99d08612564fa22cbef So it's just a matter of changing the shebang and the dependency. Question, why is this a recommends? The executable is using python(3) without any fallback mechanism I can understand that this is a "not often use binary", but shouldn't that be changed to a Depends?
Bug#942880: mate-session-manager: A dialog box says at-spi-bus-launcher is 'not responding' on reboot/shutdown
Package: mate-session-manager Version: 1.22.2-1 Severity: normal Dear Maintainer, I'm running the MATE desktop on Sid and everytime I want to reboot or shutdown my laptop, a dialog box pops up saying the at-spi-bus-launcher is not responding. When clicking 'Reboot/Shutdown anyway' there's a timeout (around 30 sec) and only after that the system proceeds with the reboot/shutdown. This behavior has been already reported with some other distributions: https://bugs.launchpad.net/ubuntu/+source/mate-session-manager/+bug/1846987 https://bugs.archlinux.org/task/63995 The Arch Linux link then points to https://github.com/mate-desktop/mate-session-manager/pull/200 and https://github.com/mate-desktop/mate-session-manager/pull/223 Please could you re-build the package as the fix already seems to be in upstream? Thank you and have a great day! Regards, athmoss -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mate-session-manager depends on: ii dbus-x11 1.12.16-2 ii dconf-gsettings-backend [gsettings-backend] 0.34.0-1 ii debian-mate-default-settings 1.22.2-1 ii libc62.29-2 ii libcairo21.16.0-4 ii libdbus-1-3 1.12.16-2 ii libdbus-glib-1-2 0.110-4 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-1 ii libglib2.0-0 2.62.1-1 ii libgtk-3-0 3.24.12-1 ii libice6 2:1.0.9-2 ii libsm6 2:1.2.3-1 ii libsystemd0 242-7 ii libx11-6 2:1.6.8-1 ii libxau6 1:1.0.8-1+b2 ii libxext6 2:1.3.3-1+b2 ii libxrender1 1:0.9.10-1 ii libxtst6 2:1.2.3-1 ii mate-desktop-common 1.22.2-1 Versions of packages mate-session-manager recommends: ii caja 1.22.2-1 ii marco 1.22.3-1 ii mate-panel1.22.2-1 ii mate-polkit 1.22.0-1 ii mate-settings-daemon 1.22.1-1 mate-session-manager suggests no packages. -- no debconf information
Bug#942725: interimap: please support name to appear in log lines
Quoting Guilhem Moulin (2019-10-22 19:15:27) > On Mon, 21 Oct 2019 at 00:26:58 +0200, Jonas Smedegaard wrote: > > I syncronize multiple accounts into subdirs below ~/Maildir and > > track them as a whole using a single notmuch database. > > AFAIK notmuch doesn't speak IMAP so unfortunately that approach breaks > layering. I'm unsure how well IMAP servers cope with other processes > messing up with the storage backend. Yes. That's *exactly* why I don't elaborate further about my setup, but eagerly awaits your next release to hopefully get an epiphany on how to do it Properly(tm). - 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
Bug#922162: Fixed with v19.2.1-1
Dear maintainer, this bug seems to be fixed after updating mesa to v19.2.1-1.
Bug#942799: Stretch: Wrong startup under gdb
A few details about the error: when running "bash -x /usr/bin/thunderbird -g", the command trace ends as follows: - + output_info 'Starting Thunderbird with GDB ...' + echo 'INFO -> Starting Thunderbird with GDB ...' INFO -> Starting Thunderbird with GDB ... + output_info 'LANG= /usr/bin/gdb -ex handle SIG38 nostop -ex handle SIGPIPE nostop -ex run /usr/lib/thunderbird/thunderbird ' + echo 'INFO -> LANG= /usr/bin/gdb -ex handle SIG38 nostop -ex handle SIGPIPE nostop -ex run /usr/lib/thunderbird/thunderbird ' INFO -> LANG= /usr/bin/gdb -ex handle SIG38 nostop -ex handle SIGPIPE nostop -ex run /usr/lib/thunderbird/thunderbird + LANG= + exec '/usr/bin/gdb -ex handle SIG38 nostop -ex handle SIGPIPE nostop -ex run /usr/lib/thunderbird/thunderbird ' /usr/bin/thunderbird: line 249: /usr/bin/gdb -ex handle SIG38 nostop -ex handle SIGPIPE nostop -ex run /usr/lib/thunderbird/thunderbird : No such file or directory - It seems that the whole command line is interpreted as the filename to load. I did not recorded the shell exit status, but I believe that I saw 127, the usual code for "command not found". I also think that I experimented some problems with the "-ex" options when I tried to split this long exec argument into filename and arguments. Hence the proposed patch replaces this complex command line with a simple one and a temporary file containing the commands for Gdb. Note: the crash mentioned in the initial report is not the problem, only the motivation to run Thunderbird under Gdb. Regards.
Bug#942879: libbrotli-dev: Please add static version of libraries (.a)
Package: libbrotli-dev Version: 1.0.7-3 Severity: normal Dear Maintainer, I tried to build a static version of a binary (wget2). There is no static version of the brotli libraries. Regards, Tim -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libbrotli-dev depends on: ii libbrotli1 1.0.7-3 libbrotli-dev recommends no packages. libbrotli-dev suggests no packages. -- no debconf information
Bug#942593: b2backend: fails with "can only concatenate str (not "bytes") to str"
Package: duplicity Version: 0.8.05-1 Followup-For: Bug #942593 The bug still exists in the new version, although in a slightly different form: (during "duplicity full" command) Backtrace of previous error: Traceback (innermost last): File "/usr/lib/python3/dist-packages/duplicity/backend.py", line 371, in inner_retry return fn(self, *args) File "/usr/lib/python3/dist-packages/duplicity/backend.py", line 606, in _do_delete self.backend._delete(filename) File "/usr/lib/python3/dist-packages/duplicity/backends/b2backend.py", line 138, in _delete log.Log(u"Delete: %s" % self.path + filename, log.INFO) TypeError: can only concatenate str (not "bytes") to str In this case the problem is the use of filename in _delete. >From my earlier investigation (which may be wrong, of course, as I am no >expert on either Python or this code), I believe the following references also have to be "decoded", in addition to the changes already made: In _get: the use of local_path.name In _put: the use of source_path.name In _delete: the two uses of filename In _query: the two uses of filename -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.utf8), LANGUAGE=en_GB (charmap=UTF-8) (ignored: LC_ALL set to en_IE.utf8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages duplicity depends on: ii gnupg 2.2.17-3 ii libc6 2.29-2 ii librsync2 2.0.2-1 ii python33.7.5-1 ii python3-fasteners 0.12.0-5 ii python3-future 0.16.0-1 ii python3-lockfile 1:0.12.2-2 Versions of packages duplicity recommends: ii python3-oauthlib 2.1.0-2 ii python3-paramiko 2.6.0-1 ii python3-pexpect 4.6.0-1 ii python3-urllib3 1.24.1-1 ii rsync 3.1.3-8 Versions of packages duplicity suggests: pn lftp pn ncftp pn par2 pn python3-boto ii python3-pip 18.1-5 pn python3-swiftclient pn tahoe-lafs -- no debconf information
Bug#942878: /usr/bin/lwr: "Fails" to download some base packages (btrfs-progs)
Package: live-wrapper Version: 0.10 Severity: important File: /usr/bin/lwr Dear Maintainer, 019:10:22T17:27:38ZUTC Calculate some file system statistics ... 2019:10:22T17:27:39ZUTC Size before compression: 20357 MiB 2019:10:22T17:27:41ZUTC Number of files: 547743 2019:10:22T17:27:41ZUTC Number of directories: 47625 DEBUG vmdebootstrap completed, see vmdebootstrap.log for details INFO Downloading helper files from debian-installer team... DEBUG Starting new HTTPS connection (1): d-i.debian.org:443 DEBUG https://d-i.debian.org:443 "HEAD /daily-images/amd64/daily/cdrom/ HTTP/1.1" 200 0 DEBUG Starting new HTTPS connection (1): d-i.debian.org:443 DEBUG https://d-i.debian.org:443 "HEAD /daily-images/amd64/daily/cdrom/vmlinuz HTTP/1.1" 200 0 DEBUG Starting new HTTPS connection (1): d-i.debian.org:443 DEBUG https://d-i.debian.org:443 "HEAD /daily-images/amd64/daily/cdrom/initrd.gz HTTP/1.1" 200 0 INFO Created GRUB directory at /tmp/tmpCYuhyP/boot/grub DEBUG runcmd: ['mcopy', '-i', '/tmp/tmpCYuhyP/boot/grub/efi.img', '-s', '::/efi/*', '/tmp/tmpCYuhyP/EFI'] None {} INFO Downloading installer files from debian-installer team... DEBUG Created d-i kernel and ramdisk directory at /tmp/tmpCYuhyP/d-i DEBUG Created d-i GTK kernel and ramdisk directory at /tmp/tmpCYuhyP/d-i/gtk DEBUG Starting new HTTPS connection (1): d-i.debian.org:443 DEBUG https://d-i.debian.org:443 "HEAD /daily-images/amd64/daily/cdrom/ HTTP/1.1" 200 0 DEBUG Starting new HTTPS connection (1): d-i.debian.org:443 DEBUG https://d-i.debian.org:443 "HEAD /daily-images/amd64/daily/cdrom/vmlinuz HTTP/1.1" 200 0 DEBUG Starting new HTTPS connection (1): d-i.debian.org:443 DEBUG https://d-i.debian.org:443 "HEAD /daily-images/amd64/daily/cdrom/initrd.gz HTTP/1.1" 200 0 DEBUG Starting new HTTPS connection (1): d-i.debian.org:443 DEBUG https://d-i.debian.org:443 "HEAD /daily-images/amd64/daily/cdrom/gtk/ HTTP/1.1" 200 0 DEBUG Starting new HTTPS connection (1): d-i.debian.org:443 DEBUG https://d-i.debian.org:443 "HEAD /daily-images/amd64/daily/cdrom/gtk/vmlinuz HTTP/1.1" 200 0 DEBUG Starting new HTTPS connection (1): d-i.debian.org:443 DEBUG https://d-i.debian.org:443 "HEAD /daily-images/amd64/daily/cdrom/gtk/initrd.gz HTTP/1.1" 200 0 INFO Downloading udebs for Debian Installer... DEBUG Updating local cache... Fetching Debian Installer Downloading udebs for Debian Installer... Updating a local cache for amd64 bullseye ... Get:1 acpi-modules-5.2.0-3-amd64-di_5.2.17-1_amd64.udeb [5312 B] Fetched 5312 B in 0s (0 B/s) ... Get:1 btrfs-modules-5.2.0-3-amd64-di_5.2.17-1_amd64.udeb [594 kB] Fetched 594 kB in 0s (0 B/s) Get:1 btrfs-progs-udeb_5.2.1-1_amd64.udeb [378 kB] Fetched 378 kB in 0s (0 B/s) ... Get:1 partman-btrfs_49_all.udeb [15.3 kB] Fetched 15.3 kB in 0s (0 B/s) ... Get:1 wide-dhcpv6-client-udeb_20080615-22_amd64.udeb [63.0 kB] Fetched 63.0 kB in 0s (0 B/s) INFO ... completed udeb downloads CRITICAL Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/cliapp/app.py", line 193, in _run self.process_args(args) File "/usr/lib/python2.7/dist-packages/lwr/run.py", line 143, in process_args self.start_ops() File "/usr/lib/python2.7/dist-packages/lwr/run.py", line 304, in start_ops handler.download_base_debs(pkg_list) File "/usr/lib/python2.7/dist-packages/lwr/apt_udeb.py", line 164, in download_base_debs self.download_apt_file(pkg_name, pool_dir, True) File "/usr/lib/python2.7/dist-packages/lwr/apt_udeb.py", line 128, in download_apt_file raise cliapp.AppException('Not able to download %s' % pkg_name) AppException: Not able to download btrfs-progs ERROR: Not able to download btrfs-progs Get:1 wireless-tools-udeb_30~pre9-13+b1_amd64.udeb [12.2 kB] Fetched 12.2 kB in 0s (0 B/s) ... Get:1 zlib1g-udeb_1.2.11.dfsg-1+b1_amd64.udeb [50.1 kB] Fetched 50.1 kB in 0s (0 B/s) ... completed udeb downloads Command exited with non-zero status 1 14828.96user 401.94system 37:09.79elapsed 683%CPU (0avgtext+0avgdata 15040780maxresident)k 8294inputs+0outputs (57major+214336066minor)pagefaults 0swaps + ls -lh debian-live-testing-amd64-mate+tools+nonfree_2019-10-22T17:01:23.iso ls: cannot access 'debian-live-testing-amd64-mate+tools+nonfree_2019-10-22T17:01:23.iso': No such file or directory # Error message doesn't make much sense to me, but btrfs-progs and btrfs-progs-udeb do exist in testing, and should be downloaded just fine. Inspecting the code, it looks like it is finding versions, and newest version, but not URI to it? The error message is rea
Bug#941018: ibus 1.5.21-1 does not work with qt5 applications
Simon has prepared a fix of this issue via a glib merge request: https://gitlab.gnome.org/GNOME/glib/merge_requests/1176 I applied the diff from that MR on top of glib2.0 2.62.1-1, and based on my limited tests it appears to fix the issue with IBus in Qt apps. @Simon: Any thoughts on the status of your glib MR? Is it safe enough to patch glib2.0 in Debian, and with that fix this bug? -- Gunnar Hjalmarsson https://launchpad.net/~gunnarhj
Bug#942877: goattracker sliently quits wiht exit code 1 on Debian Bullseye
Package: goattracker Version: 2.75-3 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? Trying to start goattracker * What exactly did you do (or not do) that was effective (or ineffective)? run it under gdb. Goattracker quits with exit code 1 * What was the outcome of this action? Goattracker did not start * What outcome did you expect instead? An error message explaining to me why goattracker does not start (and preferably a working goattracker) -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages goattracker depends on: ii libc62.29-2 ii libgcc1 1:9.2.1-8 ii libsdl1.2debian 1.2.15+dfsg2-5 ii libstdc++6 9.2.1-8 goattracker recommends no packages. Versions of packages goattracker suggests: ii milkytracker 1.02.00+dfsg-1 pn opencubicplayer pn schism -- no debconf information