Bug#876733: Licensing of jeuclid
On Tue, 14 Nov 2017 15:55:40 +0100 Julien Puydt wrote: > Hi, > > according to bug #876733, there is a licensing problem with jeuclid : > - the LICENSE.txt file [1] says Apache 2.0 ; LICENSE.txt showed up in revision b9d5f518ae61 (61) as a rename of LICENSE. LICENSE showed up in revision 7a11e25aacfa (0) during a CVS import. support/LICENSE.txt shows up in revision 472677a11fef (683).. and is Apache-2.0. > - the NOTICE file [2] looks like an Apache 1.0. NOTICE also showed up in revision 7a11e25aacfa (0). NOTICE seems to be Apache-1.1 with word replacements. (not Apache-1.0) > My interpretation of the issue is that if there are two licenses on the > code, then as long as the necessary DFSG-rights are given, there is no > problem. I would argue that the Author's clear intention was to license this work under Apache-2.0. This is where the full license text is correctly copied. A LICENSE file is typically the authority to a project, so much so that many tools ignore a NOTICE file when checking licenses if a LICENSE file is present. Additionally, Apache-2.0 invalidates a contradicting license by paragraph 4(d). What's in NOTICE violates the license terms of what's in LICENSE. > Notice that upstream seems unreactive since years now, so even though > I'm also opening a ticket there [3], moving forward not expecting an > answer seems the most reasonable course of action. Considering the last commit was in 2012, a lack of response is not in any way surprising. You opened that ticket less than a day ago. > What do you think about the matter? I'd start by making an attempt to contact maxberger directly, and then definitely have some patience. They may be on vacation, experiencing health/family/existential problems, or prefer checking email infrequently. If you don't get a response, I would argue that the author's clear intent was to license the work under the Apache-2.0 license and believed the NOTICE file was meant for a more brief form of the file. I would make that argument based on the assumption that they didn't read the license, or the portion where it tells you what the brief form looks like. IANAL -- Michael Lustfield
Bug#881756: swi-prolog: FTBFS on mips: Build killed with signal TERM
On Wed, Nov 15, 2017 at 12:55:12AM +0500, Lev Lamberov wrote: >... > The most strange thing is that 7.6.1-1 built successfully on mips. The > only difference between 7.6.1-1 and 7.6.1-2 is that java tests (only > tests) are disabled now (via debian/rules). 7.3.33+dfsg-1 failed the same way a year ago: https://buildd.debian.org/status/logs.php?pkg=swi-prolog&arch=mips I would not rule out that this might be an old bug causing random build failures, that either just happened twice in the row or became more likely due to some change somewhere. > Note that the 7.6.1-2 > version builds successfully on mipsel and mips64el (little-endian), but > fails on mips (big-endian). > The similar problem occures on powerpc [1][2], which also works in > big-endian mode: >... Same randomness on powerpcspe, and both have it already with 7.6.1+dfsg-1: https://buildd.debian.org/status/logs.php?pkg=swi-prolog&arch=powerpc https://buildd.debian.org/status/logs.php?pkg=swi-prolog&arch=powerpcspe cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#881789: libglvnd: missing libGLX_indirect.so, breaks GLX with remote X server
reassign 881789 mesa thanks On 15.11.2017 06:33, James Braid wrote: > Package: libglx0 > Version: 1.0.0-1 > Severity: important > > Dear Maintainer, > > I'm running testing on a headless system, and a recent change to use > libglxvnd has stopped GLX from working when displayed to a remote > machine. This was working fine before the migration to use glvnd for > libGL/libGLX. > > I'd provide a patch but I'm not sure what package should be taking care > of this Hi, thanks for the bug, this belongs to mesa and will be fixed in the next upload. -- t
Bug#881647: debian-faq: please add new Dutch translation
Hi Holger, Hallo Frans, This is really great, thanks a lot. I hope to find a timeslot soonish and apply this patch. Groeten, Bye, Joost On Mon, Nov 13, 2017 at 09:43:35PM +0100, Holger Wansing wrote: > Package: debian-faq > Severity: wishlist > Tags: patch,l10n > X-Debbugs-CC: frans.spiesscha...@yucom.be > > I got a fully translated po-based Dutch translation for the Debian FAQ from > Frans Spiesschaert (in X-Debbugs-CC), and added the additional files, which > are needed to build the translation, to add the 'debian-faq-nl' extra package > etc. > > I did check for formatting errors, and it builds fine (html and pdf). > > A complete patch is attached. > signature.asc Description: Digital signature
Bug#850753: fresh upstream (and ubuntu) is available (1.12.3)
Hi, Is it possible to have an updated version of docker.io in experimental? The multi-stage builds introduced in 17.05 are a very important improvement and working around this "missing" feature because Debian ships an outdated docker is getting really nasty. If there is something blocking a new release, I could also try to help. Or maybe adding a few more people to the maintainers list in general would be a good idea for such an important package? Cheers, Bastian On Thu, 28 Sep 2017 17:10:57 -0400 Balint Reczey wrote: Hi, On Tue, 26 Sep 2017 12:44:11 +0200 Bastian Venthur wrote: > Dear Maintainer, > > is there anything we can help to prepare a new upload to unstable? I have just updated runc to 1.0.0~rc4 thus updating docker.io became easier. I can't find time to update docker.io as well in the near future. :-( Cheers, Balint -- Dr. Bastian Venthur http://venthur.de Debian Developer venthur at debian org
Bug#842441: m17n-lib FTCBFS: uses build architecture pkg-config
2017-11-15 7:53 GMT+01:00 Harshula : > Hi Manuel, > Apologies! This fell off my radar. I'll make some time to look at this. That's great, thanks! -- Manuel A. Fernandez Montecelo
Bug#879196: patch attached
On Tue, 14 Nov 2017 22:35:47 + "Ana C. Custura" wrote: Hi Ghis, Thank you for the patches. I have merged this one (I thought the way you rewrote the rules file was very elegant), and the ones you sent separately with regards to enabling tests. Thanks, did you push your latest changes to the Alioth repository? FYI, #881765 should also be fixed. @anbe, once yapf 0.19.0-1 is cleared from new, you might want to use this version for the backports if that's possible. Cheers, Ghis
Bug#881798: ITP: ruby-notiffany -- Wrapper libray for most popular notification libraries
Package: wnpp Severity: wishlist Owner: "HIGUCHI Daisuke (VDR dai)" -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: ruby-notiffany Version : 0.1.1 Upstream Author : Cezary Baginski * URL : https://github.com/guard/notiffany * License : MIT Programming Lang: Ruby Description : Wrapper libray for most popular notification libraries Notification library supporting popular notifiers, such as: Growl, libnotify, TMux, Emacs, rb-notifu, notifysend, gntp, TerminalNotifier. - - most popular notification libraries supported - - easy to override options at any level (new(), notify()) - - using multiple notifiers simultaneously - - child processes reuse same configuration It is required by guard ( https://github.com/guard/guard ) -BEGIN PGP SIGNATURE- iQJDBAEBCAAtFiEECynYjkLmt2W42OpQeDlhndQ5Zo4FAloMB8wPHGRhaUBkZWJp YW4ub3JnAAoJEHg5YZ3UOWaOqOgP/jqzXtwzHk2xhax8aDbyYGKTx0VAYLNpXAKr UNJu8/zyihrIRwZavq/SHmgFNte5/zDMJy0Wr71UsxU9lgyX+l2O/PS7ogpYjTAp t95NHQw+sAVVytwh5ogCXhxv/q4sDjtkK5b+Djddz+Wvkky/yDPiWx+bwmTZbOlz 4O6UvqVBIrGsNgfYyCbNosos1abz+fJB6ffEc3kVdnAnLq45KrE3HIKZxrXAp6LU Z4F7Qqd2nUObO0DiZ+KHsmLAnOGqCL+mYoFjbWqhTGCGxX0qSiiSwh3PL5eg7A3O 2YYynEDAqvU+RS/1vK7rju4RMPUz1AQ8xWoeg5EH/I1QZ649wDpnEgMDlOUFtnDz Da9DYmjISwgda5bm6dfKVUMEmqVUVAySjin0Rk+quDTy1eMjWNXDlXSCXB7vL3Wd 33oQseMdBIMFbR4Y1xXr0SK5dHTvXtuZI02LM22banwI+hGC6f1L+WYK1UwkKfiQ sPK3uJO9ac2QZEGQ1wlSPnLRw2JMLbE37M825WM7FZXR06SdnSqia2vL0I5Y2kDo ViJwTr/n18XFPa2tc28G7MN43eQNk8qN46jG0OyED2KStqxLm+meTVP/olFRnLy9 dF88x1PsovdZrQrjYokbCUcOnOlj+JizoWnaZvuEEz4yg6SK5Ny3BBB1iEsOkv07 sA49kw1J =baJi -END PGP SIGNATURE-
Bug#881756: swi-prolog: FTBFS on mips: Build killed with signal TERM
Hi Adrian, Ср 15 ноя 2017 @ 08:06 Adrian Bunk : > On Wed, Nov 15, 2017 at 12:55:12AM +0500, Lev Lamberov wrote: >>... >> The most strange thing is that 7.6.1-1 built successfully on mips. The >> only difference between 7.6.1-1 and 7.6.1-2 is that java tests (only >> tests) are disabled now (via debian/rules). > > 7.3.33+dfsg-1 failed the same way a year ago: > https://buildd.debian.org/status/logs.php?pkg=swi-prolog&arch=mips > > I would not rule out that this might be an old bug causing random build > failures, that either just happened twice in the row or became more > likely due to some change somewhere. In the past there were some wierd build problems from time to time. You can find logs and build history in usual place. These build problems were unreproducible and were typically resolved with rebuilding. Not that time. >> Note that the 7.6.1-2 >> version builds successfully on mipsel and mips64el (little-endian), but >> fails on mips (big-endian). > >> The similar problem occures on powerpc [1][2], which also works in >> big-endian mode: >>... > > Same randomness on powerpcspe, and both have it already with 7.6.1+dfsg-1: > https://buildd.debian.org/status/logs.php?pkg=swi-prolog&arch=powerpc > https://buildd.debian.org/status/logs.php?pkg=swi-prolog&arch=powerpcspe True. And as I can see powerpcspe also works in big-endian mode. I've informed upstream about the issue. Their answer is as follows: > Interesting. I doubt this is due to big/little endian. The main issue > seems to be weaker read/write ordering constraints that break our > lock-free data structures, resulting in more or less random bugs. A > number of the tests stress these parts of the system. The test_cgc > is one of them, while I'm pretty sure there are no endian issues in > that code. > > Keri and I did a lot of stress-testing and code reviewing for this after > we discovered this was the reason for a crash on ARM. The same problem > easily reproduced on powerpc. After the fixes for 7.6.1, a couple of > runs of the test suite passed ok on powerpc. I only ran many iterations > for tests that causes problems before. Upstream will try to run these stress tests on powerpc and mips again, but they claim that they were not able to reproduce some issues with these tests in 7.6.1. Guess the issue may be related to Debian build environment. At least, I cannot think of any other reason that 7.6.1-1 was built successfully on mips and 7.6.1-2 failed, where the only one change is disabling Java tests (due to CVE-2017-1000364). I've uploaded 7.6.1-2 on the next day after 7.6.1-1 upload. Cheers! Lev
Bug#881799: ITP: ruby-shellany -- MRI+JRuby compatible command output capturing
Package: wnpp Severity: wishlist Owner: "HIGUCHI Daisuke (VDR dai)" -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: ruby-shellany Version : 0.0.1 Upstream Author : Cezary Baginski * URL : https://github.com/guard/shellany * License : MIT Programming Lang: Ruby Description : MRI+JRuby compatible command output capturing Shellany captures command output. - - portability (should work on recent JRuby versions) - - capturing stdout, stderr in a convenient way - - returning the result in a convenient way - - detecting if a shell is needed (though incomplete/primitive implementation) - - prevents running the same command multiple times It is required by guard ( https://github.com/guard/guard ). -BEGIN PGP SIGNATURE- iQJDBAEBCAAtFiEECynYjkLmt2W42OpQeDlhndQ5Zo4FAloMBngPHGRhaUBkZWJp YW4ub3JnAAoJEHg5YZ3UOWaOvrsQALpZG/Jj9cejPd1bT0ou4xOAb9tobN7/9Yhl Ka38gKVMTLBKRHv79QnNfubszUXFwmQNLIHFt3vw1LQBPecqAxNI8AIPv1ReZ5qj v1eKwnhwrzIqph7PqP126+P2ySnw03UGJM9hgs6a6MunZSdZgF5hs2BI1QdyCNuB YIPsPWPYIZAI6pqRkLO9I+RHsJGUAiTZIfUi1I5k6bK0++8PZzZW+T5LXXNPv4Lc NuIg5kXrnbB9U3X82woOzW9Y5JQJ2FDvsLUvAtCBEhrmQzZ5qSFNTyAFjgum0mNA uIr1DI9gRUYC6h6QVbIAYQTgvUKigZFyXxw4tm0kDFjaa6rR0bdnpi1vGh+cJ5zT 9tKqhWy6nQvLGiwmQD+ccT7TTNbCIcakmN/F+Ln1/2/1mWExDjqGzPWx1MnHa+Yw VzgHrRvo9okJjasYAoWVl749/UPpW1Bgi26wjSQK2xcbS0Wczeu9ZPbl8hwdi6Eq RHg1Ulr3V0qCDmzbHLE+xu78+d1KGZW6yW0lPILeXKnakESSNhX8vpW7AoBcdQGA 69jmPTEMdtuASZVC8RcZlvwMIFVhBJL37qFuATyr6lS6ehLHkdCeANFOy/eU6AOl XP+g6K4XY1kSHxW9dlm0aHDyXzCCPSH2YxtOTaHY+Lz1ApgRuS3EYlsbiz0F6bgJ NkBeytvE =ZIGL -END PGP SIGNATURE-
Bug#881711: Acknowledgement (libio-socket-ssl-perl: Segfault using malformed client certificates)
A proposed fix (works for me): https://github.com/noxxi/p5-io-socket-ssl/commit/a09f29f423859565bc0384dcfbbc75811d9e4e4a On Tue, Nov 14, 2017 at 4:45 PM, Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 881711: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881711. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > As you requested using X-Debbugs-CC, your message was also forwarded to > beld...@gmail.com > (after having been given a Bug report number, if it did not have one). > > Your message has been sent to the package maintainer(s): > Debian Perl Group > > If you wish to submit further information on this problem, please > send it to 881...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 881711: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881711 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > -- SY, Dmitry Belyavsky
Bug#854643: fix for this bug
This is the command for sending notifications from the battery monitor. notify-send "Battery low" --icon=battery-caution lxpanel should depend on libnotify-bin and notification-daemon for executing this properly. So the temporary fix is, sudo apt-get install libnotify-bin notification-daemon add the following line to $HOME/.config/lxsession/LXDE/autostart @/usr/lib/notification-daemon/notification-daemon logout and get back in for the notification-daemon to start. The permanent fix should be to add the necessary dependencies and make the notification daemon start as a session service.
Bug#879631: closed by Paulo Henrique de Lima Santana ()
Control: reopen -1 On Tue, Nov 14, 2017 at 12:42:04PM +, Debian Bug Tracking System wrote: > > Date: Tue, 14 Nov 2017 10:30:01 -0200 > From: Paulo Henrique de Lima Santana > To: 879631-d...@bugs.debian.org > > Hi, > > This package will be used as a dependency in a new package I'm doing as you > can see below. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858916 > > So, It is not useless and I need to keep it in Debian. The missing dependency is an RC bug in any case. > Best regards, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#849150: sagemath: FTBFS on arm64 and ppc64el: cannot allocate memory building docs
Just for the record, this was fixed by building the documentation only in the indep build. Building the documentation on these architectures will probably still fail, but I agree that the bug can be closed. Best, Tobias
Bug#849703: ITP: ansible-doc -- Documentation for Ansible
Hi Harlan, On Sat, Dec 31, 2016 at 01:07:44PM -0500, Harlan Lieberman-Berg wrote: > It's been a while since we made the decision not to pull from upstream's > git; Toni, I'd be happy to work with you on seeing if it's doable now. I think I have a suitable package now, being as cheap as possible, but it's off your git tree, which I took from https://anonscm.debian.org/git/collab-maint/ansible.git I had to change some things, though: * retrofit the docsite directory * adjust debian/control * adjust debian/rules It's for 2.4.1, and it's lintian clean. My changes build both packages. How can I best upload this stuff without disrupting yours, and without creating an entirely new repository? TIA! Cheers, --Toni++
Bug#881800: php-elisp: htmlizing PHP code fails with Invalid face: quote, font-lock-constant-face
Package: php-elisp Version: 1.13.5-3 Severity: normal Tags: upstream Dear Maintainer, Trying to htmlize annotations to PHP code (Symfony @Route() ) as part of org-mode HTML export, this fails on : "face-attribute: Invalid face: quote, font-lock-constant-face" It appears to be https://github.com/ejmr/php-mode/commit/2f78325aecff9673fe2cbb73b1c2584e4ca7405b but the package seems to lag a lot behind upstream... Maybe getting rid of it would be better than having a really old package ? Thanks anyaway. Best regards, -- System Information: Debian Release: buster/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages php-elisp depends on: ii emacs24 [emacsen] 24.5+1-11 ii emacs25 [emacsen] 25.2+1-6 Versions of packages php-elisp recommends: pn speedbar Versions of packages php-elisp suggests: pn php5 pn php5-cli
Bug#881756: swi-prolog: FTBFS on mips: Build killed with signal TERM
On Wed, Nov 15, 2017 at 02:30:54PM +0500, Lev Lamberov wrote: > Hi Adrian, Hi Lev, > Ср 15 ноя 2017 @ 08:06 Adrian Bunk : >... > > Same randomness on powerpcspe, and both have it already with 7.6.1+dfsg-1: > > https://buildd.debian.org/status/logs.php?pkg=swi-prolog&arch=powerpc > > https://buildd.debian.org/status/logs.php?pkg=swi-prolog&arch=powerpcspe >... > At least, I cannot think of any other reason that 7.6.1-1 > was built successfully on mips and 7.6.1-2 failed, where the only one > change is disabling Java tests (due to CVE-2017-1000364). I've uploaded > 7.6.1-2 on the next day after 7.6.1-1 upload. you already quoted the reason: > The main issue > seems to be weaker read/write ordering constraints that break our > lock-free data structures, resulting in more or less random bugs. Based on the mips/powerpc/powerpcspe results one could say that there is a 50% chance that a build attempt fails. That would give a 37.5% probability for 2 builds failing and one succeeding when trying 3 times. Considering the older mips failure and the more frequent powerpc/powerpcspe failures, the 7.6.1-1 success might just have been "luck". > Cheers! > Lev cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#881562: [Debichem-devel] Bug#881562: rdkit: Please migrate away from Epydoc if possible
[hopefully I got the "reply to" right here] Thanks for the pointer to a possible alternative to epydoc. Making this change is likely a non-trivial amount of work, but we'll have to do something anyway before we deprecate Python2 support in the RDKit. I've created an issue in the RDKit tracker. No promises on when it'll get done though. https://github.com/rdkit/rdkit/issues/1656 -greg On Mon, Nov 13, 2017 at 1:31 AM, Kenneth Pronovici wrote: > Source: rdkit > Severity: wishlist > > Hi, > > If possible, please consider moving away from the use of Epydoc in your > package. Epydoc is basically unmaintained upstream. Also, it is only > supported for Python 2, so it will reach its end of life along with > Python 2 sometime in 2020. > > I will continue to maintain the Epydoc packages in Debian as long as I > can, acting as de facto upstream. However, once Python 2 is unsupported > in Debian, I'm not sure that we'll have too many options to keep it > alive. Migrating it to Python 3 is a fairly large job that I don't > have the time or the expertise to take on right now. > > For my own Python code, I have recently converted to Sphinx using the > Napolean plugin. At [1], I can offer you (or your upstream) a hack-ish > script to convert common Epydoc markup to Google-style docstrings. It's > not perfect, but it would get you much of the way toward working code. > > Thanks, > > Ken (maintainer for python-epydoc) > > [1] https://bitbucket.org/cedarsolutions/cedar-backup3/ > src/73037a2/util/sphinx-convert > > ___ > Debichem-devel mailing list > debichem-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debichem-devel >
Bug#881802: Firefox gets unusable and with broken security after update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: firefox Version: 57.0-1 Severity: grave The new update of firefox render it completely unusable and unsafe to use as essential addons are disabled without asking the user. - - Foxproxy - In the setup where I use firefox, I need to configure proxy far behind the possibilities that firefox gives me. So without that addon, I am actually cut of from internet completely. On one hand, that is good as otherwise I would be endangered due to the following disabled addons. - - Noscript - Present internet is absolutely to dangerous to browse without Noscript. As a short term solution, JS could be completely disabled but it is needed to enable it on some trusted sites. - - HTTPS Everywhere - - Status-4-Evar - Without this addon, it is a blind flight without instruments to browse internet. Every link will be a surprise where it leads to. - - Y U no validate - Without that addon it is easily possible to accidentally accept an invalid TLS certificate forever. That opens up for many problems. - - DNSSEC/TLSA Validator - I need to be able to check the validity of TLSA entries. It is sad that firefox has no buildin check for that. But now it even disables the only addon that was able to verify them. - - Cookie Monster Beside that there are several addons that bring back some stuff that was dropped from firefox but without, browsing is impossible. - - Tabgruppen - Without that feature, I have about 1000 Tabs open at the same time. Firefox is unusable without that addon. - - Tab Mix Plus - The same, it makes Tabbed browsing even more usable. - - UAControl - Several sites require to set special UA to be able to access them. Including some embedded devices I need to use at work. "Funny" think ist that noscript was updated too but the update is incompatible to currect firefox. - -- System Information: The problem happened on a host without direct access to the internet so I deleted the informations from the host where I report that bug from. Note also, that the paging output of firefox prereportbug scripts break the further usage of reportbug. - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -BEGIN PGP SIGNATURE- Comment: Charset: ISO-8859-1 iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAloMGpAACgkQpnwKsYAZ 9qzMXgwAs2Bgn9+53ZSfMqNtOsD3olD4Luf/CUQh1KNVdlCiko+E22OLj0HAkuMO /JJsowwURhbQ8chHHBXMRtPkH6VPzjP8VqpGpyVFCwA9S/xob6tQ3tdfgIq57O48 uyQIy1u+V65KFdCXGFaM0LOa9+vaQXXIPQosJGk50RSXfuI1TutYRnksH2tsPtMp PhZLbj9dMPQ4s/UX3fxlx0XiI2Y6PTjpuf2NYa5VErtygI+7NWnz0p8Pyz/ioT7k rgs3Aq4LvPU5BHnxMYsXcfVohqrBRDzide8TbhSlgRCqJOQxV57lFVBEBecG0Wmi vdbDgErdklI+Ds9H6/8ifNXxsxEIIuqNKnQqy84thEsVF3n6YBjgGo2qG3cf/Npl POYLN1iG2meAR37HBjakgGaqqeDTGn36KiPg2kBQ7+L29BqwpO3RAerOMFSn9gLF /0PMEJgNX8MlJyo9ormPWpin6Z9LYd+/zXXu/dqfr9kix+mPNKLndQPnUhqrUzCc dchu7PuP =lJO8 -END PGP SIGNATURE-
Bug#881801: gkrelltop: Sometimes show invalid names
Package: gkrelltop Version: 2.2.13-1 Severity: normal Just noticed that it shows "firefox" in CPU minutes after it's been completely wiped off from the memory. I have suspected in the past that the names aren't proper (like showing a process which is 0% in top), but this one's quite obviously wrong. -- System Information: Debian Release: buster/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8), LANGUAGE=en_US.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages gkrelltop depends on: ii gkrellm 2.3.10-1 ii libc62.24-12 gkrelltop recommends no packages. Versions of packages gkrelltop suggests: ii gkrelltopd 2.2.13-1 -- no debconf information
Bug#881803: gkrelltop: iostat mode freezes gkrellm
Package: gkrelltop Version: 2.2.13-1 Severity: normal Clicking two times should bring up iostat mode, but it freezes gkrellm completely instead. The reason is that it tries to access /proc/1/io which gives ENOPERM, in an endless and continuous loop. CPU on 100%, gkrellm updates on 0%. :-) Killing it is the only cure. -- System Information: Debian Release: buster/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8), LANGUAGE=en_US.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages gkrelltop depends on: ii gkrellm 2.3.10-1 ii libc62.24-12 gkrelltop recommends no packages. Versions of packages gkrelltop suggests: ii gkrelltopd 2.2.13-1 -- no debconf information
Bug#876578: libykneomgr: diff for NMU version 0.1.8-2.2
Dear maintainer, I've uploaded another NMU for libykneomgr (versioned as 0.1.8-2.2) for adding a dblatex build dependency. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed diff -Nru libykneomgr-0.1.8/debian/changelog libykneomgr-0.1.8/debian/changelog --- libykneomgr-0.1.8/debian/changelog 2017-10-21 13:08:23.0 +0300 +++ libykneomgr-0.1.8/debian/changelog 2017-11-15 12:47:23.0 +0200 @@ -1,3 +1,10 @@ +libykneomgr (0.1.8-2.2) unstable; urgency=medium + + * Non-maintainer upload. + * Add the missing build dependency on dblatex. + + -- Adrian Bunk Wed, 15 Nov 2017 12:47:23 +0200 + libykneomgr (0.1.8-2.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru libykneomgr-0.1.8/debian/control libykneomgr-0.1.8/debian/control --- libykneomgr-0.1.8/debian/control 2016-07-25 11:26:06.0 +0300 +++ libykneomgr-0.1.8/debian/control 2017-11-15 12:46:50.0 +0200 @@ -5,7 +5,7 @@ Uploaders: Simon Josefsson Build-Depends: debhelper (>= 9), dh-autoreconf, libpcsclite-dev, libzip-dev, help2man, pkg-config, - gtk-doc-tools + gtk-doc-tools, dblatex Standards-Version: 3.9.8 Homepage: https://developers.yubico.com/libykneomgr/ Vcs-Git: https://github.com/Yubico/libykneomgr-dpkg.git
Bug#880235: NMU of the fix for this package
Hi,
Since this is an RC bug, and that it hasn't been addressed for the last
15 days, I've prepared an NMU. It simply removes that last one assert in
the failing test, which is enough to have everything working again.
Debdiff is attached. I've uploaded to the DELAYED/5 queue.
Cheers,
Thomas Goirand (zigo)
diff -Nru blockdiag-1.5.3+dfsg/debian/changelog
blockdiag-1.5.3+dfsg/debian/changelog
--- blockdiag-1.5.3+dfsg/debian/changelog 2017-06-04 03:08:49.0
+
+++ blockdiag-1.5.3+dfsg/debian/changelog 2017-11-15 10:44:08.0
+
@@ -1,3 +1,10 @@
+blockdiag (1.5.3+dfsg-5.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add patch to remove one assert in test_node_attribute() (Closes: #880235).
+
+ -- Thomas Goirand Wed, 15 Nov 2017 10:44:08 +
+
blockdiag (1.5.3+dfsg-5) unstable; urgency=medium
* debian/rules
diff -Nru
blockdiag-1.5.3+dfsg/debian/patches/remove-one-assert-in-test_node_attribute.patch
blockdiag-1.5.3+dfsg/debian/patches/remove-one-assert-in-test_node_attribute.patch
---
blockdiag-1.5.3+dfsg/debian/patches/remove-one-assert-in-test_node_attribute.patch
1970-01-01 00:00:00.0 +
+++
blockdiag-1.5.3+dfsg/debian/patches/remove-one-assert-in-test_node_attribute.patch
2017-11-15 10:43:45.0 +
@@ -0,0 +1,17 @@
+Description: Remove one assert in test_node_attribute
+Author: Thomas Goirand
+Bug-Debian: https://bugs.debian.org/880235
+Forwarded: no
+Last-Update: 2017-11-15
+
+--- blockdiag-1.5.3+dfsg.orig/src/blockdiag/tests/test_builder_node.py
blockdiag-1.5.3+dfsg/src/blockdiag/tests/test_builder_node.py
+@@ -95,7 +95,7 @@ class TestBuilderNode(BuilderTestCase):
+ self.assertNodeStacked(diagram, stacked)
+ self.assertNodeFontsize(diagram, fontsize)
+ self.assertNodeLabel_Orientation(diagram, orientations)
+-self.assertNodeBackground(diagram, backgrounds)
++#self.assertNodeBackground(diagram, backgrounds)
+
+ def test_node_height_diagram(self):
+ diagram = self.build('node_height.diag')
diff -Nru blockdiag-1.5.3+dfsg/debian/patches/series
blockdiag-1.5.3+dfsg/debian/patches/series
--- blockdiag-1.5.3+dfsg/debian/patches/series 2017-06-04 02:06:07.0
+
+++ blockdiag-1.5.3+dfsg/debian/patches/series 2017-11-15 10:42:59.0
+
@@ -4,3 +4,4 @@
fixes-test_node_attribute.patch
fixes_test_fontmap_duplicated_fontentry1.patch
848748-exception-ignored-in-Image-del.patch
+remove-one-assert-in-test_node_attribute.patch
Bug#879213: The bup FTBFS is fixed upstream
Control: tags -1 fixed-upstream Upstream fix: https://github.com/bup/bup/commit/292361d86d1cf0cc555681ae43371d66c8ebb366 cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#881597: krb5-multidev: Please make the package multi-arch installable
Hi all, Sorry for the delayed response to this thread. I ran out of time yesterday. On Mon, 13 Nov 2017 11:58:04 -0500, Sam Hartman wrote: > so, why don't you take this opportunity to try and sell me on how cool > multi-arch is for krb5 dev packages and why it provides Debian with neat > enough capabilities that I want to commit to supporting it. Off the top of my head: 1. Multi-arch support in krb5-multidev is primarily needed for cross-compiling packages without requiring the use of a chroot, lxc or similar method. A lack of multi-arch co-installability for krb5-multidev makes building packages such as 32-bit Wine on 64-bit systems more difficult. (Okay, so the libraries can be installed manually... but it's more of a hassle). This lack of support is also another build-dep that cannot be satisfied. 2. Debian is now making a concerted effort to provide multi-arch installable development packages, now that most of the binary packages are fully supported in this way. 3. Almost all of the krb5 set of packages are already multi-arch installable. Why not go the whole way and do this properly? On Mon, 13 Nov 2017 10:51:10 -0800, Russ Allbery wrote: > Removing this option will break krb5-multidev. Sorry about that. I didn't realise how krb5-multidev was installed to allow heimdal-multi-dev to be co-installed. On Mon, 13 Nov 2017 14:59:03 -0800, Russ Allbery wrote: > Sam Hartman writes: >> we do ship a pkg-config script and that handles this correctly. >> How does pkg-config figure out which arch you're building for? > pkg-config the command appears to have the same problem. It embeds a > compile-time path of pkgconfig directories to search for build options, >which is based on the architecture for which pkg-config is built: Developers need to use PKG_CONFIG_PATH or PKG_CONFIG_LIBDIR to tell pkg-config which arch is the target. There was also a push to add a --host option some while ago, but I'm not sure where that's up to. Looking forward, I think we're all agreed that pkg-config is the correct solution. That said, my preferred solution is to drop krb5-config.mit. (Packages such as icu and freetype are also removing their legacy -config interfaces.) However, as Russ pointed out, this approach is a breaking change (until maintainers update their packages, at least). So drawing on another of Russ' posts, I'd like to propose that we split krb5-config.mit into a separate package (krb5-multidev-bin or similar). This new package would only expose one architecture, but that would be sufficient for most people using the legacy interface. Splitting the package would avoid the multi-arch conflict caused by krb5-config.mit and allow krb5-multidev to become Multi-Arch: same. libkrb5-dev could also become M-A: same, if the krb-config symlink was moved to krb5-multidev-bin.
Bug#876901: QFINDTESTDATA uses __FILE__
Pino Toscano: > In data martedì 14 novembre 2017 11:14:00 CET, Ximin Luo ha scritto: >> You're using __FILE__ inappropriately, none of the documentation >> guarantees or implies that you can access __FILE__ as a real >> filesystem path. "Surely for relative paths" is your justification >> for your own broken behaviour. > > Again, this is your own echo chamber: "__FILE__ is broken, everybody > using it is broken no matter what". > It's not my "own echo chamber", I pointed you to lots of docs that confirm your usage of __FILE__ is not appropriate here. Adrian Bunk also mentioned the C89 to me on IRC yesterday. Again, the wording gives no guarantee that __FILE__ should represent a real filesystem path. If my previous words were a bit terse I am sorry for that, but I don't appreciate comments like "Any of your solutions get a big, fat, and giant nope" after trying to explain the problem and present you with no less than 4 alternative simple unintrusive solutions. >> You can either accept my one line patch suggestion, or fix it some >> other way. > > I am not interested in working around broken changes introduced blindly > for very doubtful reasons. > >> I'm not going to change the GCC patch, it does nothing wrong. > > Let me add also another POV to this approach: do you really expect > Debian to carry this important diversion for GCC upstream? I really > doubt GCC will accept this. > I'm in the process of getting the patch into GCC. We certainly don't intend to keep this as a Debian-specific thing. [1] If they don't accept it, you don't need to patch your package - but I'd say the use of __FILE__ is still not the best, since no documentation implies it can be used to find files, and all the examples only mention error messages. And to be clear, in case Holger's earlier messages were missed, the FTBFS is currently only on tests.r-b.org and not on the official Debian archive. X [1] Although interestingly, NetBSD have a GCC patch that was written by us (dkg specifically) for a related purpose, that was not accepted into GCC. But they use it for reproducibility purposes. -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Bug#881804: ruby2.3 FTBFS on i386: TestFloat#test_round_with_precision failure
Source: ruby2.3 Version: 2.3.5-1 Severity: serious Tags: patch https://buildd.debian.org/status/fetch.php?pkg=ruby2.3&arch=i386&ver=2.3.5-1&stamp=1510668050&raw=0 ... Finished tests in 490.087998s, 32.5941 tests/s, 4569.4386 assertions/s. 1) Failure: TestFloat#test_round_with_precision [/<>/test/ruby/test_float.rb:448]: <5.02> expected but was <5.01>. 15974 tests, 2239427 assertions, 1 failures, 0 errors, 78 skips ruby -v: ruby 2.3.5p376 (2017-09-14) [i386-linux-gnu] uncommon.mk:612: recipe for target 'yes-test-almost' failed make[2]: *** [yes-test-almost] Error 1 make[2]: Leaving directory '/<>' debian/rules:73: recipe for target 'override_dh_auto_test-arch' failed make[1]: *** [override_dh_auto_test-arch] Error 2 If the exact precision is required, the following fixes it: --- debian/rules.old2017-11-15 09:51:45.0 + +++ debian/rules2017-11-15 10:10:18.0 + @@ -11,6 +11,11 @@ export TESTOPTS DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) +DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) + +ifneq (,$(filter $(DEB_HOST_ARCH), i386)) +export DEB_CFLAGS_MAINT_APPEND=-ffloat-store +endif export SOURCE := $(shell dpkg-parsechangelog -SSource) export RUBY_VERSION := $(patsubst ruby%,%,$(SOURCE))
Bug#881062: NMU for this bug
Hi, This bug is blocking a bunch of package migration to Buster, so I've prepared an NMU. Debdiff is attached. I've uploaded the resulting package to DELAYED/5, to leave you enough time to upload it yourself if you prefer. I'm also available for sponsoring the package if you don't have enough rights in the Debian archive. Best regards, Thomas Goirand (zigo) diff -Nru flower-0.8.3+dfsg/debian/changelog flower-0.8.3+dfsg/debian/changelog --- flower-0.8.3+dfsg/debian/changelog 2017-05-22 12:30:55.0 + +++ flower-0.8.3+dfsg/debian/changelog 2017-11-15 11:04:06.0 + @@ -1,3 +1,11 @@ +flower (0.8.3+dfsg-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Using python-sphinxcontrib.httpdomain instead of the old transition +package with dash (Closes: #881062). + + -- Thomas Goirand Wed, 15 Nov 2017 11:04:06 + + flower (0.8.3+dfsg-2) unstable; urgency=medium * Use local objects.inv to avoid internet access (Closes: #862246) diff -Nru flower-0.8.3+dfsg/debian/control flower-0.8.3+dfsg/debian/control --- flower-0.8.3+dfsg/debian/control2017-05-22 12:30:01.0 + +++ flower-0.8.3+dfsg/debian/control2017-11-15 11:04:06.0 + @@ -16,7 +16,7 @@ python-mock, python-setuptools (>= 0.6b3), python-sphinx, - python-sphinxcontrib-httpdomain, + python-sphinxcontrib.httpdomain, python-tornado, python3-all, python3-doc,
Bug#872712: [Parl-devel] Bug#872712: debian-parl: please remove transitional packages myspell-{af, en-gb, en-za, it, ky, sl, sw, th} and use hunspell-* instead
On Mon, Sep 25, 2017 at 06:20:02PM +0200, Agustin Martin wrote: > On Mon, Aug 21, 2017 at 10:04:03AM +0200, Mattia Rizzolo wrote: > > On Mon, Aug 21, 2017 at 02:33:02AM +0200, Jonas Smedegaard wrote: > > > I will address this, but it may take time before I come around to it. > > > > > > Please do go ahead with removal of the reverse dependency (at least from > > > testing): debian-parl is currently kicked from testing for other > > > reasons. > > > > Ok, we will go ahead and remove them at the first occasion breaking > > debian-parl. > > Hi, > > Just to note that myspell-ca dependency should also be changed to > hunspell-ca. Andreas already changed bug title about this. Hi, Jonas, This part is still pending. > hunspell-ca package without myspell-ca has already been uploaded. However > it cannot migrate to testing because of debian-parl dependency on > myspell-ca (See #876732, myspell-ca cannot be removed from sid). Thanks in advance, -- Agustin
Bug#876934: openorienteering-mapper FTBFS: test failures
Kai Pastor, DG0YT: > Am 13.11.2017 um 20:15 schrieb Adrian Bunk: >>> I didn't find a recommendation how to solve the issue. I hope a custom macro >>> is okay. >> Based on the discussion in #876901 [1] it is still unclear how this >> should be resolved in general. >> > One more remark: > > Replacing __FILE__ with an individual macro makes it much harder to detect > embedded build paths in source code review. Proliferation of individual > macros could become worse than __FILE__ IMO. > > > I see the discussion on debian-qt-kde. The proposal in > https://lists.debian.org/debian-qt-kde/2017/11/msg00110.html: > >> If all the test files reside underneath the same directory, like tests/, you >> could: > >> 4. export >> BUILD_PATH_PREFIX_MAP="$BUILD_PATH_PREFIX_MAP=tests=$BASEDIR/tests". > > will probably worked for this package (old versions). But such information > needs to be in documentation, at the time such a change is introduced. In > addition, there needs to be much better correlation of changes in the > environment and changes in reproducibility build success. It seems there are > two variations tested, but __FILE__ vs. not __FILE__ is not included. > > I remember that I spent time studying changelogs of gcc and Qt packages in > Debian when this bug was opened, but I was unaware of the particularities of > the gcc in reproducible builds. The rbuild log that I find online does not > contain the exact c++ compiler package name and version. What an irony, the > reproducible-builds logs do not provide enough information to consider them > reproducible. Even Debian package build logs on build.opensuse.org offer more > details. We could have solved this much earlier, and without wasting CPU > cycles and developer time. > There was some mis-co-ordination, Adrian did not tell us he was filing the bug, we the reproducible-builds team were not intending to file a bug, and I missed the first few messages of the bug report so I assumed he already explained that the FTBFS is only a problem on tests.r-b.org and not the official Debian archive or buildds. The patch currently being used on tests.r-b.org is here: https://anonscm.debian.org/cgit/reproducible/debrepatch.git/tree/toolchain-patches/gcc-7_BPPM.patch The documentation for the variable seems to have been chopped off by mistake, but it is in the patch that I sent upstream to GCC, ctrl-F for "invoke.texi": https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01318.html Indeed, the exact version of the C++ compiler does not appear in the rbuild: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/openorienteering-mapper.html That is because schroots are installed with "build-essential" by default and so gcc doesn't get downloaded every single time for each package build. That's an unfortunate situation and I can see it's ironic, you could probably file a bug against jenkins.debian.org or perhaps pbuilder to have the builders dump this information into the log, even if the build fails. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Bug#881805: /usr/bin/xset: [xset] "xset +fp unix/:7101" doesn't work
Package: x11-xserver-utils Version: 7.7+7+b1 Severity: normal File: /usr/bin/xset Dear Maintainer, I wish to be able to use TTF fonts with ancient X programs that understand only XLFD, so I installed the packages "xfstt" and "x11-xfs-utils". Firstly I verified that the font server was running $ xfsinfo -server unix/:7101 name of server: unix/:7101 version number: 2 vendor string: HD vendor release number: 1 maximum request size: 1024 longwords (8192 bytes) number of catalogues: 0 Number of alternate servers: 0 number of extensions: 0 next I verified that the font server knew about (at least some of) my ttf fonts $ fslsfonts -server unix/:7101 ... -ttf-bitstream-vera-bitstream vera sans mono-medium-r-normal-roman-0-0-0-0-m-0-iso8859-1 ... and eventually I tried to add the fonts served on "unix/:7101" using the syntax that is documented in every place $ xset +fp unix/:7101 xset: bad font path element (#0), possible causes are: Directory does not exist or has wrong permissions Directory missing fonts.dir Incorrect font server address or syntax so I have a running font server but no way of using it. I know that I could use /etc/X11/Xconfig (?) but my system works w/o such a file and I'd prefer to use the xset alternative because I fear to introduce new problems. Thank you in advance for your attention, gb -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages x11-xserver-utils depends on: ii cpp 4:7.2.0-1d1 ii libc62.24-17 ii libice6 2:1.0.9-2 ii libx11-6 2:1.6.4-3 ii libxaw7 2:1.0.13-1+b2 ii libxcursor1 1:1.1.14-3 ii libxext6 2:1.3.3-1+b2 ii libxi6 2:1.7.9-1 ii libxmu6 2:1.1.2-2 ii libxmuu1 2:1.1.2-2 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxt6 1:1.1.5-1 ii libxxf86vm1 1:1.1.4-1+b2 x11-xserver-utils recommends no packages. Versions of packages x11-xserver-utils suggests: pn cairo-5c pn nickle ii xorg-docs-core 1:1.7.1-1.1 -- no debconf information
Bug#881806: fpart: Please update package
Package: fpart Version: 0.9.2-1+b1 Severity: normal Dear Maintainer, Fpart 1.0.0 has been released, see: https://github.com/martymac/fpart Is it possible to update Debian package (no new dependency needed) ? Thanks! -- System Information: Debian Release: 9.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/2 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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fpart depends on: ii libc6 2.24-11+deb9u1 ii rsync 3.1.2-1 ii sudo 1.8.19p1-2.1 fpart recommends no packages. fpart suggests no packages. -- no debconf information
Bug#881326: Processed: Re: Bug#881326: re: Bug#881326: mpv: The dependency of mpv should not be recommended, it must be sugerere
On Mon, 13 Nov 2017 17:34:56 -0200 =?utf-8?Q?Rog=C3=A9rio?= Brito wrote: > Control: tags + wontfix > > On Nov 13 2017, Debian Bug Tracking System wrote: > > Processing control commands: > > > > > retitle -1 "mpv" should be "Suggests" instead of "Recommends" > > Bug #881326 [youtube-dl] mpv: The dependency of mpv should not be > > recommended, it must be sugerere > > Changed Bug title to '"mpv" should be "Suggests" instead of "Recommends"' > > from 'mpv: The dependency of mpv should not be recommended, it must be > > sugerere'. > > Sorry, this won't be happening. > > youtube-dl needs mpv or mplayer to download RTSP videos. It is not listed as > a recommends for frivolous reasons of "hey, after you download the video, > watch it with with mpv". > > In the same manner, mpv needs youtube-dl to play videos directly from > youtube when fed a youtube URL (or any other site that youtube-dl supports). > > So, I'm marking this bug as wontfix. > maybe this could go into README.Debian and the bug could be closed? (i personally hate "wontfix" bugs that are kept open so people can actually find them). gfmdr IOhannes signature.asc Description: OpenPGP digital signature
Bug#881807: python-pypcap should provide a package for Python 3
Source: python-pypcap
Version: 1.1.5-1
We have a Python 3 project which uses pypcap
(https://github.com/pynetwork/pypcap)
Debian currently only provides packages for Python 2
(i.e. python-pypcap)
Is there a possibility to build this package for Python 3 too?
** Version 1.1.6 **
I wrote a patch which applies to 1.1.6-1 on Git:
https://anonscm.debian.org/git/pkg-netmeasure/python-pypcap.git/tag/?h=
debian/1.1.6-1
(see attachment)
It should follow the policy / style guide:
https://wiki.debian.org/Python/LibraryStyleGuide?action=show&redirect=P
ython%2FPackaging
** Version 1.1.5 **
I also have a similar fix for building 1.1.5 for Python 3
(based on http://httpredir.debian.org/debian/pool/main/p/python-pypcap/
python-pypcap_1.1.5-1.dsc)
Please note that this requires an extra patch to make setup.py work
with python3 too.
(see patches in 1.1.5-1.tar.gz)
It should follow the policy / style guide:
https://wiki.debian.org/Python/LibraryStyleGuide?action=show&redirect=P
ython%2FPackaging
Thank you in advance!
With best regards,
Tom.
--
Tom Ghyselinck
Senior Engineer
tom.ghyseli...@excentis.com
Excentis
Gildestraat 8 – 9000 Gent – Belgium
Tel +32 9 269 22 91
www.excentis.comdiff -Naur python-pypcap-1.1.6.orig/debian/compat python-pypcap-1.1.6/debian/compat
--- python-pypcap-1.1.6.orig/debian/compat 2017-11-15 07:52:09.469301112 +0100
+++ python-pypcap-1.1.6/debian/compat 2017-11-15 08:18:55.808938207 +0100
@@ -1 +1 @@
-9
+10
diff -Naur python-pypcap-1.1.6.orig/debian/control python-pypcap-1.1.6/debian/control
--- python-pypcap-1.1.6.orig/debian/control 2017-11-15 07:52:09.469301112 +0100
+++ python-pypcap-1.1.6/debian/control 2017-11-15 08:20:47.812413720 +0100
@@ -3,14 +3,24 @@
Uploaders: Iain R. Learmonth
Section: python
Priority: optional
-Build-Depends: debhelper (>= 9),
- python-all-dev,
- python-pyrex,
+Build-Depends: debhelper (>= 10),
libpcap0.8-dev,
quilt,
+ python-all-dev,
+ cython,
python-setuptools,
+ python3-all-dev,
+ cython3,
+ python3-setuptools,
dh-python
Standards-Version: 4.1.0
+# Define versions for Python 2:
+X-Python-Version: >= 2.6
+# Define versions for Python 3:
+# In the rules file, you can loop over `py3versions -vr` to select the Python versions to build for.
+# See also:
+# man dh_python3
+X-Python3-Version: >= 3.2
Vcs-Browser: https://anonscm.debian.org/cgit/pkg-netmeasure/python-pypcap.git
Vcs-Git: https://anonscm.debian.org/git/pkg-netmeasure/python-pypcap.git
Homepage: https://github.com/pynetwork/pypcap
@@ -22,6 +32,21 @@
${misc:Depends}
Conflicts: python-libpcap
Provides: ${python:Provides}
-Description: object-oriented Python interface for libpcap
+Description: object-oriented Python interface for libpcap (Python 2)
+ pypcap is an objected-oriented Python interface for libpcap which
+ supports packet injection and user callback functions.
+ .
+ This package installs the library for Python 2.
+
+Package: python3-pypcap
+Architecture: any
+Depends: ${python3:Depends},
+ ${shlibs:Depends},
+ ${misc:Depends}
+Conflicts: python-libpcap
+Provides: ${python3:Provides}
+Description: object-oriented Python interface for libpcap (Python 3)
pypcap is an objected-oriented Python interface for libpcap which
supports packet injection and user callback functions.
+ .
+ This package installs the library for Python 3.
diff -Naur python-pypcap-1.1.6.orig/debian/copyright python-pypcap-1.1.6/debian/copyright
--- python-pypcap-1.1.6.orig/debian/copyright 2017-11-15 07:52:09.469301112 +0100
+++ python-pypcap-1.1.6/debian/copyright 2017-11-15 08:18:55.809938238 +0100
@@ -1,5 +1,7 @@
This package was debianized by Robert S. Edmonds on
-Tue, 07 Aug 2007 23:47:14 -0400.
+Tue, 07 Aug 2007 23:47:14 -0400 and updated to support Python 3 by
+XRA-31 Development Team on
+Tue, 14 Nov 2017 17:10:00 +0100.
It was downloaded from
https://pypi.python.org/pypi/pypcap
diff -Naur python-pypcap-1.1.6.orig/debian/docs python-pypcap-1.1.6/debian/docs
--- python-pypcap-1.1.6.orig/debian/docs 2017-11-15 07:52:09.469301112 +0100
+++ python-pypcap-1.1.6/debian/docs 2017-11-15 09:01:51.595154956 +0100
@@ -1 +1 @@
-README
+README.rst
diff -Naur python-pypcap-1.1.6.orig/debian/rules python-pypcap-1.1.6/debian/rules
--- python-pypcap-1.1.6.orig/debian/rules 2017-11-15 07:52:09.469301112 +0100
+++ python-pypcap-1.1.6/debian/rules 2017-11-15 08:18:55.810938269 +0100
@@ -1,8 +1,11 @@
#!/usr/bin/make -f
+#export DH_VERBOSE = 1
+export PYBUILD_NAME = pypcap
+
%:
- dh $@ --with=python2
+ dh $@ --with=python2,python3 --buildsystem=pybuild
override_dh_auto_build:
- pyrexc pcap.pyx
+ cython3 pcap.pyx
dh_auto_build
diff -Naur python-pypcap-1.1.6.orig/debian/source/format python-pypcap-1.1.6/debian/source/format
--- python-pypcap-1.1.6.orig/debian/source/format 1970-01-01 01:00:00.0 +0100
++
Bug#881802: Firefox gets unusable and with broken security after update
severity 881802 normal thanks On 15/11/2017 11:44, Klaus Ethgen wrote: > Package: firefox > Version: 57.0-1 > Severity: grave > > The new update of firefox render it completely unusable and unsafe to > use as essential addons are disabled without asking the user. Lowering the severity as Firefox remains usable and safe. The features that you are mentioning are provided by extension and not by the Firefox package itself. In parallel, I guess some of them will be ported to 57 in the next few weeks. Last but not least, you can still use Firefox esr: https://tracker.debian.org/pkg/firefox-esr Where the extensions will probably work. Sylvestre
Bug#881808: varnish: CVE-2017-8807: Data leak - '-sfile' Stevedore transient objects
Source: varnish Version: 5.0.0-1 Severity: serious Tags: patch security upstream fixed-upstream Forwarded: https://github.com/varnishcache/varnish-cache/pull/2429 Control: fixed -1 5.0.0-7+deb9u2 Hi, the following vulnerability was published for varnish. CVE-2017-8807[0]: Data leak - '-sfile' Stevedore transient objects The fix for stretch-security has already been preared and will be released shortly, already marking the version as fixed accordingly since prepared before. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2017-8807 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8807 [1] https://github.com/varnishcache/varnish-cache/pull/2429 [2] https://varnish-cache.org/security/VSV2.html Regards, Salvatore
Bug#881762: ITA: gtkterm/0.99.7~rc1-1
On Tue, 2017-11-14 at 23:13 +0100, Adam Borowski wrote: > On Tue, Nov 14, 2017 at 10:19:27PM +0100, Willem van den Akker wrote: > > * Package name: gtkterm > > Version : 0.99.7~rc1-1 > > Upstream Author : [fill in name and email of upstream] > > * URL : [fill in URL of upstreams web site] > > * License : [fill in] > > Section : comm > > > > Changes since the last upload: > > > > * New maintainer upload (Closes: #857476). > > * debian/control > > - description updated conform Developer's Reference. > > * Bump standards version to 4.1.1.1. > > > Remarks: > > Homepage, watch file are not known yet. gtkterm has many, often > > inactive, respositories. I am in contact with a few owners to take > > over the most recent respository. After that a new release and > > homepage/watch file are filled in. > > Also one file serie.c is modified other then the 'quilt-way'. This will > > be corrected after a new version upload. > > I don't see any changes other than removal of an article from the short desc > and removal of the Homepage: field. > > Thus, this upload would serve no other purpose than to stake your claim. > This can be done just by mentioning in the ITA bug. > > I'd refrain from uploading until there are some actual changes. > > > Meow! Hi Adam, Clear. I am currently working on a new upstream version and will be back if it is ready for review. /Willem
Bug#881809: libgl1-mesa-dri: no more opengl2 in latest libgl1-mesa-dri
Package: libgl1-mesa-dri Version: 13.0.6-1+b2 Severity: wishlist Dear Maintainer, it looks like there is no more opengl2 in libgl1-mesa-dri. I know, my hardware does not support opengl2 (GPU is Intel I945) only opengl1.4, however, in mesa version 13.0.6 from debian/stable opengl2 is running very fine. No problems with any glitches or somnething, and the desktop is also running faster and more stable than with opengl1.4. I am running Plasma and activated lots of effects (except of blur) and all effects work like a charme. As I do not see the need to upgrade to version 17.2, I downgraded to 13.0.6. On the other hand, it would be nice, if opengl2 could be activated again in 17.2 and higher. If there is a chance, to get it back, please do. I know, this is not in my hardware implemented, but emulated by the software. Maybe it is possible, just to implement the code from 13.0.6 into the latest versions, if it is too difficult to improve it. This version is running fast and stable, as I mentioned above. In which version between 13.X and 17.X was the change? KI checked the changelog, but found no clue. Thanks for your help and any answers. Best regards Hans -- Package-specific info: glxinfo: name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_libglvnd, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, GLX_SGI_swap_control client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync GLX version: 1.4 GLX extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel Open Source Technology Center (0x8086) Device: Mesa DRI Intel(R) 945GME x86/MMX/SSE2 (0x27ae) Version: 13.0.6 Accelerated: yes Video memory: 192MB Unified memory: yes Preferred profile: compat (0x2) Max core profile version: 0.0 Max compat profile version: 2.1 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 2.0 OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) 945GME x86/MMX/SSE2 OpenGL version string: 2.1 Mesa 13.0.6 OpenGL shading language version string: 1.20 OpenGL extensions: GL_3DFX_texture_compression_FXT1, GL_AMD_shader_trinary_minmax, GL_ANGLE_texture_compression_dxt3, GL_ANGLE_texture_compression_dxt5, GL_APPLE_object_purgeable, GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, GL_ARB_ES2_compatibility, GL_ARB_clear_buffer_object, GL_ARB_compressed_texture_pixel_storage, GL_ARB_copy_buffer, GL_ARB_debug_output, GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_draw_elements_base_vertex, GL_ARB_explicit_attrib_location, GL_ARB_explicit_uniform_location, GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_frameb
Bug#881810: apt-transport-tor: Provide script to rewrite apt sources.list to use tor?
Package: apt-transport-tor Version: 0.3 It would be convenient if it was easier to switch APT to use package sources via Tor. What about providing a script in the apt-transport-tor package, rewriting all the current APT sources in /etc/apt/ to use the .onion addresses listed on https://onion.debian.org/ >? This would make the process into a simple three step solution: apt install apt-transport-tor /usr/share/apt-transport-tor/convert-apt-sources apt update The script could do simple sed tranformations, something like this to every sources.list file for each hostname: sed -i 's%http://ftp.debian.org%tor+http://vwakviie2ienjx6t.onion%' \ /etc/apt/sources.list What do you think of the idea? Would you like to maintain such script as part of the apt-transport-tor package? -- Happy hacking Petter Reinholdtsen
Bug#876901: QFINDTESTDATA uses __FILE__
Lisandro Damián Nicanor Pérez Meyer: > [..] > > Xi: you also mentioned that having to file hundreds of patchs seems > impossible. Well, it seems so, but it is actually not that necessary. Please > allow me to explain the idea. > Thanks for being less inflammatory than Pino. I agree that eventually all projects should move away from using __FILE__. This BUILD_PATH_PREFIX_MAP variable is only a stepping stone to that, just like SOURCE_DATE_EPOCH was a stepping stone to less projects using __DATE__ and __TIME__. It allows people to see the obvious benefit of a reproducible build, by actually achieving a large amount of reproductions, today. We did not need to file mass bug reports for __DATE__ and __TIME__ with SOURCE_DATE_EPOCH. > What you can do here is starting by documenting/blogging about bad use cases > so people have something to read when bugs arrive. > > [..] You're implying that QT's use of __FILE__ for tests, as being discussed in this thread, is a "good use case" - and that it is *other people* with "bad use cases" that we should be spending a lot of time and effort to reach out to. That's not how I see it. As I pointed out various times already, the use of __FILE__ here is *also not appropriate*. You can consider these emails from me now, as "documenting/blogging" about "bad use cases". In summary: in no document or standard, does it guarantee or imply that __FILE__ can be taken to represent a real filesystem path. Applications relying on this behaviour are broken and should not be upset when things don't work. As documented in multiple places, __FILE__ only has a very loose meaning, my patch fits within this loose meaning, and it is intended mostly for error messages. The BUILD_PATH_PREFIX_MAP variable works around a lot of "bad use cases", but it doesn't cover this particular case. Some minor tweaks are needed to cover it, and I suggested them already. But you guys continue to push the position "we're doing nothing wrong, it's other people doing stuff wrong, go talk to them instead". I'm sorry but it's not a convincing position for me to agree with. At the end of the day, all of these cases, including yours, ought to be fixed to not use __FILE__ at all. BUILD_PATH_PREFIX_MAP doesn't prevent the fix, it just means we can achieve many many real reproductions today without having to wait. That's a good thing. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Bug#881812: xul-ext-treestyletab: new version required for Firefox 57
Package: xul-ext-treestyletab Version: 0.19.2017061601-1 Severity: important The version of xul-ext-treestyletab currently available in Debian doesn't work with Firefox 57. Please consider uploading the current upstream release to either experimental (in case the new version no longer works with firefox-esr) or unstable. Ansgar
Bug#767013: ITP: mstpd -- A daemon implementing the RSTP (Rapid Spanning Tree Protocol) protocol for bridges
Hey, I'm one of the co-maintainers of mstpd. Initially the project was hosted here: https://sourceforge.net/projects/mstpd/ Now, it's moved here: http://github.com/mstpd/mstpd Even though mstpd's purpose is MSTP, it's not there yet [even today]. It is a good RSTP implementation though, and it is being used in production in several companies. We do have in the repo .deb pkg generation: https://github.com/mstpd/mstpd/tree/master/debian And our Travis CI script does run a script from travis.debian.net [ not sure if that's an official page of the Debian project ]. See: https://github.com/mstpd/mstpd/blob/master/.travis.yml As far as I can tell: * we would need a sponsor for some guidance to package mstpd ; I've never packaged anything for Debian officially * probably prepare a new release for mstpd that contains all stuff ready for making it a package in Debian [ compatibility with GCC 7, maybe force protocol level to RSTP, and let people experiment with MSTP, etc ] I'm willing to put in the effort to get this through, if anyone is willing to guide me through this. Thanks Alex
Bug#881813: linux-image-4.13.0-1-amd64: Linux 4.13.0 cannot run squeeze chroot environment
Package: src:linux Version: 4.13.10-1 Severity: important Current (2017-11-14 - 2017-11-15) sid with up-to-date kernel (4.13.0) cannot "chroot" into squeeze chroot environment. What I did? * I started qemu-system-x86_64 (debian package qemu-system-x86 1:2.8+dfsg-6+deb9u3) from my host system (debian stretch amd64) * 2017-11-14 I downloaded current buster installer from here: http://cdimage.debian.org/cdimage/buster_di_alpha1/amd64/iso-cd/debian-buster-DI-alpha1-amd64-netinst.iso * I installed it to the qemu virtual machine * I upgraded it to current sid (2017-11-14 - 2017-11-15) * I created (in this qemu virtual machine, of course) squeeze chroot environment using command (I use debootstrap 1.0.92): # debootstrap --variant=minbase --no-check-gpg squeeze /tmp/target http://archive.debian.org/debian * It failed: W: Failure trying to run: chroot /tmp/target dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.22_amd64.deb W: See /tmp/target/debootstrap/debootstrap.log for details * /tmp/target/debootstrap/debootstrap.log is here: warning, in file '/var/lib/dpkg/status' near line 4 package 'dpkg': missing description Segmentation fault * Then I tried to run "chroot /tmp/target /bin/bash" and got "Segmentation fault" So, it seems current sid simply cannot run squeeze chroot environment: it gots segmentation fault when triyng to run /bin/bash . * Then I removed /tmp/target and created it again using command: # debootstrap --variant=minbase --no-check-gpg --foreign squeeze /tmp/target http://archive.debian.org/debian * Now the command worked well. But then I tried "chroot /tmp/target /bin/bash" and got "Segmentation fault" again * Then I copied that /tmp/target to outside of my qemu virtual machine and run it on my host. My host is debian stretch with kernel linux-image-4.9.0-4-amd64 4.9.51-1. And /bin/bash worked successfully. So, squeeze chroot environment doesn't work on sid with kernel 4.13.0, but works with stretch with kernel 4.9.0 * Then I run my host OS in qemu using well known "qemu -snapshot /dev/sda" trick. And then I did run "chroot /tmp/target /bin/bash" in this qemu instance. /bin/bash worked well again. So, it seems qemu doesn't influence bug reproducebility. I. e. it seems the problem is not qemu-related. So, I am pretty sure problem is not in debootstrap. I also think the problem is not in qemu (I already wrote why I did so). I think problem is this: modern kernel cannot run old squeeze chroot environment. So I fill this bug to "linux-image" package. I think this is very important bug, so I give it "important" priority. Linux kernel is very conservative when we speak about API and ABI. Modern debian releases typically can run very old chroot environments. I can successfully create debian hamm chroot environment on my stretch host using my own script. Yes, hamm!!! Which is released 1998-07-24!!! And I can successfully run /bin/bash from it. So, debian (until recently) successfully did run very old chroot environments. And now you broke this tradition, this is very bad. This bug report is sent from mentioned sid qemu virtual machine. -- Package-specific info: ** Version: Linux version 4.13.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 6.4.0 20171026 (Debian 6.4.0-9)) #1 SMP Debian 4.13.10-1 (2017-10-30) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.13.0-1-amd64 root=UUID=8e27eccf-cc87-4c57-8bb6-7d3da96097e3 ro quiet ** Not tainted ** Kernel log: [0.606044] Write protecting the kernel read-only data: 12288k [0.606615] Freeing unused kernel memory: 1592K [0.608452] Freeing unused kernel memory: 1128K [0.609313] x86/mm: Checked W+X mappings: passed, no W+X pages found. [0.657316] SCSI subsystem initialized [0.658541] piix4_smbus :00:01.3: SMBus Host Controller at 0x700, revision 0 [0.659811] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI [0.659811] e1000: Copyright (c) 1999-2006 Intel Corporation. [0.668058] libata version 3.00 loaded. [0.671377] Floppy drive(s): fd0 is 2.88M AMI BIOS [0.674626] input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input3 [0.674745] input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input2 [0.690794] FDC 0 is a S82078B [0.698539] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 [1.025342] e1000 :00:03.0 eth0: (PCI:33MHz:32-bit) 52:54:00:12:34:56 [1.025348] e1000 :00:03.0 eth0: Intel(R) PRO/1000 Network Connection [1.025367] ata_piix :00:01.1: version 2.13 [1.026725] e1000 :00:03.0 ens3: renamed from eth0 [1.027495] scsi host0: ata_piix [1.027584] scsi host1: ata_piix [1.027608] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc040 irq 14 [1.027609] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc048 irq 15 [1.184305] ata1.01: NODEV after polling detection [1.184501] ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100 [1.18450
Bug#876901: QFINDTESTDATA uses __FILE__
El 15 nov. 2017 8:00 a.m., "Ximin Luo" escribió: Pino Toscano: > In data martedì 14 novembre 2017 11:14:00 CET, Ximin Luo ha scritto: >> You're using __FILE__ inappropriately, none of the documentation >> guarantees or implies that you can access __FILE__ as a real >> filesystem path. "Surely for relative paths" is your justification >> for your own broken behaviour. > > Again, this is your own echo chamber: "__FILE__ is broken, everybody > using it is broken no matter what". > It's not my "own echo chamber", I pointed you to lots of docs that confirm your usage of __FILE__ is not appropriate here. Adrian Bunk also mentioned the C89 to me on IRC yesterday. Again, the wording gives no guarantee that __FILE__ should represent a real filesystem path. If my previous words were a bit terse I am sorry for that, but I don't appreciate comments like "Any of your solutions get a big, fat, and giant nope" after trying to explain the problem and present you with no less than 4 alternative simple unintrusive solutions. >> You can either accept my one line patch suggestion, or fix it some >> other way. > > I am not interested in working around broken changes introduced blindly > for very doubtful reasons. > >> I'm not going to change the GCC patch, it does nothing wrong. > > Let me add also another POV to this approach: do you really expect > Debian to carry this important diversion for GCC upstream? I really > doubt GCC will accept this. > I'm in the process of getting the patch into GCC. We certainly don't intend to keep this as a Debian-specific thing. [1] If they don't accept it, you don't need to patch your package - but I'd say the use of __FILE__ is still not the best, since no documentation implies it can be used to find files, and all the examples only mention error messages. And to be clear, in case Holger's earlier messages were missed, the FTBFS is currently only on tests.r-b.org and not on the official Debian archive. I see your point here. I'm currently on the phone, please allow me some time to get into a proper keyboard and make a. Proposals that I think will work for both sides.
Bug#879196: patch attached
Hey Ghis, Will be pushing after dealing #877701. I've replied to Andreas directly with regards to #881765. Thanks for your concern! Thanks, Ana On Wed, Nov 15, 2017, at 09:11 AM, Ghislain Vaillant wrote: > On Tue, 14 Nov 2017 22:35:47 + "Ana C. Custura" > wrote: > > Hi Ghis, > > > > Thank you for the patches. I have merged this one (I thought the way you > > rewrote the rules file was very elegant), and the ones you sent > > separately with regards to enabling tests. > > Thanks, did you push your latest changes to the Alioth repository? > > FYI, #881765 should also be fixed. @anbe, once yapf 0.19.0-1 is cleared > from new, you might want to use this version for the backports if that's > possible. > > Cheers, > Ghis
Bug#849703: ITP: ansible-doc -- Documentation for Ansible
Hi Toni, On Wed, Nov 15, 2017 at 06:10:45PM +0800, Toni Mueller wrote: > On Sat, Dec 31, 2016 at 01:07:44PM -0500, Harlan Lieberman-Berg wrote: > > It's been a while since we made the decision not to pull from upstream's > > git; Toni, I'd be happy to work with you on seeing if it's doable now. > > I think I have a suitable package now, being as cheap as possible, but > it's off your git tree, which I took from > > https://anonscm.debian.org/git/collab-maint/ansible.git > > I had to change some things, though: > > * retrofit the docsite directory > * adjust debian/control > * adjust debian/rules > > It's for 2.4.1, and it's lintian clean. My changes build both packages. > > How can I best upload this stuff without disrupting yours, and without > creating an entirely new repository? Just push your stuff to a branch "toni/doc" or something, and we'll have a look? You should have push access to collab-maint anyways. Evgeni
Bug#881715: alsa-utils: High CPU usage on the default device
No...? Why would I do something silly like that?
Bug#877701: patch attached
Hi Ghis, Thank you for this. Unfortunately there has been some duplication of effort here, I have a patch (similar to yours) already. Held off pending investigation the state of documentation upstream. Thanks again for your efforts, Ana On Tue, Nov 14, 2017, at 09:41 AM, Ghislain Vaillant wrote: > Here is a patch removing the confusing section from the manpage. > Email had 1 attachment: > + 0001-Remove-confusing-SEE-ALSO-section-in-manpages.patch > 1k (text/x-patch)
Bug#880958: yapf3 explicitly depends on python3.5
Have replied to you from the respective bugs. Thank you, Ana On Tue, Nov 14, 2017, at 10:36 PM, Ghislain Vaillant wrote: > What about the patches fixing the other two bugs affecting yapf? > Please consider checking the BTS.> > Ghis > > > Le 14 nov. 2017 22:25, "Ana C. Custura" a écrit :>> Hi > Ghis, >> >> Thank you for the reply. There is a package on mentors that addresses>> both >> this bug (88958) and the split (879196) bug you raised. I am >> waiting for my mentor to review it before uploading. >> >> Ana >> >> On Tue, Nov 14, 2017, at 08:59 AM, Ghislain Vaillant wrote: >> > Thank you Matthias for raising this issue. CC'ing the maintainer >> > in case>> > she's not subscribed. >> > >> > On Mon, 6 Nov 2017 11:52:00 +0100 Matthias Klose >> > wrote:>> > > Package: yapf3 >> > > Version: 0.17.0-1 >> > > Severity: serious >> > > Tags: sid buster >> > > >> > > yapf3 explicitly depends on python3.5. One mistake certainly is >> > > the b-d on>> > > python3-all, which is wrong for an application-only >> > > package. >> > >> > The application is not compliant with the Python packaging >> > guidelines.>> > The public modules should be split from the application >> > package. See>> > #879196 for a discussion about it. >> > >> > I have proposed a patch offline but it has yet to be applied. >> > Fixing>> > #879196 will transitively fix the issue you just reported. >> > >> > > And if this package is application-only, why ship both Python2 >> > > and Python3 vesions?>> > >> > It is nether application-only, nor Python 3 specific. >> > >> > Cheers, >> > Ghis
Bug#880078: Re: Bug#880078: apparmor: Bump pinned feature set to Linux 4.14's
Vincas Dargis: > What do you believe would be deadline for enabling 4.14 features > (removing feature set limits / upgrading feature set file)? I say we could do that a few weeks after AppArmor is enabled by default and the first batch of reported bugs (using the 4.13 feature set) have been addressed. But it could very well wait a couple more months and it wouldn't be a problem IMO. > Is it possible that Buster could be released with old feature set, I would see absolutely no problem with that. > There are quite a few profiles to check (and progress is rather slow on my > part), > although if feature set pining is working fine on 4.14, we have still have > some time, > I guess..? Yes :) Cheers, -- intrigeri
Bug#874080: hdparm v9.51 please document how to restart
> >As the workaround for the absent init script one can use the following > >command to reset settings defined in the hdparm.conf: > >DEVNAME=/dev/ /lib/udev/hdparm Hope this helps. > > Yes, that does work, but must be executed for each drive. A little > cumbersome, but workable! You can call reset hdparm settings for all disks by calling /usr/lib/pm-utils/power.d/95hdparm-apm resume
Bug#881633: Creation of vim-python3 virtual package
Thanks for starting the discussion, Victor. One thing I'd like to note is that none of the vim-$lang virtual packages are currently listed in Policy's set of virtual packages. That was an oversight on the Vim maintainers side when the package names were introduced, but maybe now would be a good time to correct that. On Mon, Nov 13, 2017 at 09:04:55PM +0100, Víctor Cuadrado Juan wrote: > On Mon, 13 Nov 2017 19:34:44 +0100 Víctor Cuadrado Juan wrot > > It will allow vim python3 plugins to require on it. > > Expanding on the rationale: > > vim works with python2 and python3 plugins simultaneously. Neovim does, Vim does not. Due to the way Python is built on Debian, it's not possible for Vim's current language binding support to use both languages in the same Vim instance. When I switched the Vim packages from Python 2 to Python 3, I didn't change the virtual package name. This was purely due to Vim's limitations and not considering that Neovim could handle it better. > Those vim python > plugins depend on the vim-python virtual package. > > In the case of neovim, support for python2 and python3 plugins is achieved > by using python-neovim and python3-neovim respectively. > > As the maintainer of python-neovim, if I would do only `Provides: vim-python` > then some vim python plugins would be broken. > Eg: vim-python-jedi, a python3 package, depends on vim-python. vim-python-jedi > would not work with python-neovim that `Provides: vim-python`, buy would need > python3-neovim that `Provides: vim-python3` > > This means that packages that currently depend on vim-python need to be > checked > to depend on the correct vim-python and/or vim-python3. This sounds good to me, and I'll adapt Vim to Provide vim-python3 instead of vim-python. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#881814: libibverbs-dev no longer ships infiniband/driver.h
Source: rdma-core Version: 15-1 Severity: serious Control: affects -1 libibverbs-dev src:librdmacm src:libcxgb3 src:libmlx4 src:libipathverbs src:libmlx5 src:libibcm src:libmthca src:libnes src:libfabric Many packages FTBFS due to libibverbs-dev no longer shipping infiniband/driver.h, e.g.: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libipathverbs.html ... checking infiniband/driver.h usability... no checking infiniband/driver.h presence... no checking for infiniband/driver.h... no configure: error: not found. libipathverbs requires libibverbs.
Bug#685134: Bug#684909: Bug#685134: [s390-tools] please add patch from qemu
On 19 October 2017 at 20:53, Aurelien Jarno wrote:
> On 2017-10-19 16:31, Philipp Kern wrote:
>> On 10/19/2017 03:06 PM, Michael Tokarev wrote:
>> > Debian has much stricter policy wrt blobs (DFSG),
>> > and debian builds for more architectures (the firmware,
>> > if it is part of qemu-system-s390 package, needs to be
>> > built on all architectures where this binary package
>> > builts, or it needs to be a separate arch-all package).
>>
>> Note that the arch:all autobuilders are amd64. gcc-*-s390x-linux-gnu
>> exists in Debian, although only on i386 and amd64. I don't think there's
>> a policy today that precludes you from forcing users to build arch:all
>> on amd64 for technical reasons.
>
Well, depwait state is valid, no? E.g. i'm sure we have many arch:all
packages that cannot be built on some architectures if e.g. arch:all
source package has an arch:all build dependency that is not
installable on some architectures.
As long as arch:all is buildable on a few common architectures, that's
good enough, no?
> Indeed that's one option to build it, that's for example the solution
> chosen to build slof using gcc-powerpc64-linux-gnu. So far nobody
> complained it's buildable only on amd64, i386, ppc64el and x32.
>
Note there are now two s390 firmwares in qemu: ccw and netboot. The
netboot one needs SLOF sources.
> The other alternative is to build a cross-compiler using binutils-source
> and gcc-source (that requires that the none or elf os is supported for
> this architecture). This has the advantage of ignoring all the flags
> that debhelper tries to push that make a firmware to not build or break.
> That's the solution chosen for example for openbios.
>
Would the attached patch be acceptable for debian?
* It drops stripping roms/SLOF
* Adds Build-Depends-Indep: crossbuild-essential-s390x
(such that it is needed only on the arch:all debian builder, or when
building with -A, meaning it is not needed when doing arch builds,
tested that arch-only build doesn't require this)
(maybe we can add a build profile or like
for this too, to exclude this step, and thus enable people to manually
build arch-all & arch-any packages, without the crosstoolchainy bits)
* Adds code to compile s390 firmwares and install them into
qemu-s390-firmware arch:all package
(package name is arbitrary - it did not feel right to call it bios...
any better name suggestions are welcome)
Given that roms/SLOF code is needed by two firmwares, maybe we can
explore collapsing src:qemu-slof into src:qemu too, using strategy
similar to the above one.
Installing s390x cross toolchain, and compiling s390 firmware adds
trivial amount of extra build-time, given how long/big the full
src:qemu build already is.
--
Regards,
Dimitri.
diff -ru debian/qemu-2.10.0+dfsg/debian/changelog qemu-2.10.0+dfsg/debian/changelog
--- debian/qemu-2.10.0+dfsg/debian/changelog 2017-10-08 10:51:09.0 +0100
+++ qemu-2.10.0+dfsg/debian/changelog 2017-11-14 20:57:02.0 +
@@ -1,3 +1,10 @@
+qemu (1:2.10.0+dfsg-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Compile and provide s390 ccw & netboot firmware.
+
+ -- Dimitri John Ledkov Tue, 14 Nov 2017 20:56:50 +
+
qemu (1:2.10.0+dfsg-2) unstable; urgency=medium
* update to upstream 2.10.1 point release
diff -ru debian/qemu-2.10.0+dfsg/debian/control qemu-2.10.0+dfsg/debian/control
--- debian/qemu-2.10.0+dfsg/debian/control 2017-10-08 10:51:09.0 +0100
+++ qemu-2.10.0+dfsg/debian/control 2017-11-15 13:01:01.624664678 +
@@ -106,6 +106,7 @@
##--enable-netmap todo bsd
##--enable-quorum todo needs gcrypt
##--enable-xen-pci-passthrough todo
+Build-Depends-Indep: crossbuild-essential-s390x
Build-Conflicts: oss4-dev
Standards-Version: 3.9.8
Homepage: http://www.qemu.org/
@@ -482,3 +483,11 @@
Please note that old qemu-kvm configuration files (in /etc/kvm/) are
no longer used.
+Package: qemu-s390-firware
+Architecture: all
+Depends: ${misc:Depends}
+Enhances: qemu-system-misc
+Description: QEMU s390 ccw and pxeboot firmware images
+ QEMU is a fast processor emulator. This package provides ccw (virtio) and
+ netboot (pxeboot) firmware for the s390 system emulator.
+
diff -ru debian/qemu-2.10.0+dfsg/debian/control-in qemu-2.10.0+dfsg/debian/control-in
--- debian/qemu-2.10.0+dfsg/debian/control-in 2017-10-08 10:35:23.0 +0100
+++ qemu-2.10.0+dfsg/debian/control-in 2017-11-15 13:01:00.724667246 +
@@ -107,6 +107,7 @@
##--enable-netmap todo bsd
##--enable-quorum todo needs gcrypt
##--enable-xen-pci-passthrough todo
+Build-Depends-Indep: crossbuild-essential-s390x
Build-Conflicts: oss4-dev
Standards-Version: 3.9.8
Homepage: http://www.qemu.org/
@@ -529,6 +530,17 @@
Please note that old qemu-kvm configuration files (in /etc/kvm/) are
no longer used.
+Package: qemu-s390-firware
+Architecture: all
+Depends: ${misc:Depends}
+:ubuntu:Breaks: qemu-system-s390x (<< 1:2.10+dfsg-3~)
+:ubuntu:Replaces: qemu-system-s390x (<< 1:2.10+dfsg-3~)
+:ubunt
Bug#881815: wagon2: missing build dependency on libplexus-classworlds2-java
Source: wagon2 Version: 2.12-3 Severity: serious https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/wagon2.html ... [WARNING] The POM for org.codehaus.plexus:plexus-classworlds:jar:2.x is missing, no dependency information available [WARNING] The artifact org.codehaus.plexus:plexus-container-default:jar:1.5.5 has been relocated to org.codehaus.plexus:plexus-container-default:jar:debian [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Maven Wagon . SUCCESS [ 0.599 s] [INFO] Apache Maven Wagon :: API .. SUCCESS [ 3.703 s] [INFO] Apache Maven Wagon :: Provider Test SUCCESS [ 1.455 s] [INFO] Apache Maven Wagon :: Providers SUCCESS [ 0.027 s] [INFO] Apache Maven Wagon :: Providers :: File Provider ... SUCCESS [ 0.293 s] [INFO] Apache Maven Wagon :: Providers :: FTP Provider SUCCESS [ 0.430 s] [INFO] Apache Maven Wagon :: Providers :: HTTP Shared Library SUCCESS [ 0.228 s] [INFO] Apache Maven Wagon :: Test Compatibility Kits .. SUCCESS [ 0.006 s] [INFO] Apache Maven Wagon :: HTTP Test Compatibility Kit .. FAILURE [ 0.016 s] [INFO] Apache Maven Wagon :: Providers :: HTTP Provider ... SKIPPED [INFO] Apache Maven Wagon :: Providers :: Lightweight HTTP Provider SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 7.167 s [INFO] Finished at: 2018-12-17T19:20:44-12:00 [INFO] Final Memory: 25M/594M [INFO] [ERROR] Failed to execute goal on project wagon-tck-http: Could not resolve dependencies for project org.apache.maven.wagon:wagon-tck-http:jar:2.12: Cannot access central (https://repo.maven.apache.org/maven2) in offline mode and the artifact org.codehaus.plexus:plexus-classworlds:jar:2.x has not been downloaded from it before. -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :wagon-tck-http dh_auto_build: /usr/lib/jvm/default-java/bin/java -noverify -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/jvm/default-java/lib/tools.jar -Dmaven.home=/usr/share/maven -Dmaven.multiModuleProjectDirectory=/build/1st/wagon2-2.12 -Dclassworlds.conf=/etc/maven/m2-debian.conf -Dproperties.file.manual=/build/1st/wagon2-2.12/debian/maven.properties org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings-debian.xml -Ddebian.dir=/build/1st/wagon2-2.12/debian -Dmaven.repo.local=/build/1st/wagon2-2.12/debian/maven-repo --batch-mode package -DskipTests -Dnotimestamp=true -Dlocale=en_US returned exit code 1 debian/rules:9: recipe for target 'override_dh_auto_build' failed make[1]: *** [override_dh_auto_build] Error 1
Bug#871608: linux-image-4.9.0-3-amd64: Linux kernel should handle decreasing cpu steal clock counter gracefully
Hi, I ran into the same issue with 4.9.51-1 in the guest. My dom0 in this case is still Jessie with its xen 4.4 version. Users (rightfully) worry about what's suddenly wrong with their virtual machine, since the steal values mess up the cpu graphs. I see that all the discussions linked above have gone silent quickly without a solution. A post to the Xen mailing list on Aug 31th did not get any answer yet: https://lists.xen.org/archives/html/xen-users/2017-08/msg00092.html I see that the issue got fixed by replacing the code with a new implementation of the same functionality. I guess this is a scenario that sometimes happens, not having a ready to go fix available for the previous LTS kernel. So, what would be the best step forward here? Should we poke the Xen people a bit more to find out how to approach this, or get an opinion on the best and smallest patch to go with? I'm not an expert in the cpu time accounting area, but I can help testing etc... Thanks, -- Hans van Kranenburg
Bug#881816: openstack-dashboard: fails to install non-interactively: postinst debconfage fails
Package: openstack-dashboard Version: 3:12.0.0-3 Severity: serious Justification: fails to install, makes rbdeps FTBFS Hi! When installing openstack-dashboard non-interactively, it fails with: Setting up openstack-dashboard (3:12.0.0-3) ... dpkg: error processing package openstack-dashboard (--configure): installed openstack-dashboard package post-installation script subprocess returned error exit status 30 Interactively, it asks questions then succeeds. But as it's a build-dependency of several packages (ironic-ui, manila-ui, etc), it must be installable inside sbuild. Meow! -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: armhf (armv7l) Kernel: Linux 4.14.0-00115-g3d7c587c4c1b (SMP w/4 CPU cores; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages openstack-dashboard depends on: ii adduser3.116 ii debconf [debconf-2.0] 1.5.65 pn libjs-jquery pn libjs-jquery-cookie pn python pn python-django-horizon openstack-dashboard recommends no packages. Versions of packages openstack-dashboard suggests: pn memcached pn openstack-dashboard-apache
Bug#820641: This bug should be marked as obsolete
Debian stable is using Vala 0.34 and GTK+ 3.22, so this bug is obsolete.
Bug#881817: ferm: rpfilter example broken
Package: ferm Version: 2.3-2 Severity: minor The "rpfilter" example in the manpage is incomplete/broken. On non-default interfaces, this set of rules breaks neighbor discovery (which is done by multicast on IPv6). At the very least, a rule allowing multicasts should be inserted before the DROP. -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (700, 'stable'), (600, 'unstable'), (550, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/1 CPU core) 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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ferm depends on: ii debconf 1.5.61 ii init-system-helpers 1.48 ii iptables 1.6.0+snapshot20161117-6 ii lsb-base 9.20161125 ii perl 5.24.1-3+deb9u2 Versions of packages ferm recommends: ii libnet-dns-perl 1.07-1 ferm suggests no packages.
Bug#881425: Info received (Bug#881425: linux-image-4.13.0-1-amd64: "rm -rf " fails with ENOTEMPTY (Directory not empty))
Hmmm, using a VM I can't reproduce with 4.13.10-1... The "rm /*" is too fast, perhaps I need more background IO noise?
Bug#881813: linux-image-4.13.0-1-amd64: Linux 4.13.0 cannot run squeeze chroot environment
Same for buster. I. e. if I replace sid virtual machine with buster virtual machine, I got the same bug. I mean that I created buster from the same alpha 1 installer, but this time I didn't upgrade it to sid. == Askar Safin http://vk.com/safinaskar
Bug#881750: gbp --import-orig --merge-mode=replace behaves as --merge-mode=merge
On 14/11/17 22:47, Guido Günther wrote: > Hi, > > This wired and I wouldn't expect uncommitted changes but since I don't > know about your setup and what you're doing (the upstream repo > e.g. already has the version you're trying to import) you'd have to > provide better instructions to reproduce and tell me what you actually > think is wrong. With git-buildpackage 0.8.12.2 in Stretch, if I take Debian's guitarix up until 0.35.6, I can do gbp --import-orig --uscan --merge-mode=replace and it will correctly import the new 0.36.0 upstream version, merge it to master and preserve the already existing contents at debian/*. With git-buildpackage 0.9.2 (today in Testing and Unstable), doing the same will overwrite the contents at debian/* with upstream sources, contrary to what --merge-mode=replace should do. Sadly I wanted to keep working on guitarix and submit a new upload, so I already committed 0.36.0 to the guitarix repo at https://anonscm.debian.org/cgit/pkg-multimedia/guitarix.git/ . > Can you reproduce this with other packages? I tried to reproduce it with git-buildpackage 0.9.1 against python-pyo and lv2proc packages, and it worked fine. So if you see no problem on gbp output as said, feel free to close the bug. Maybe it was a fluke caused by several people working in guitarix's repo. -- Víctor Cuadrado Juan m...@viccuad.me PGP key ID: 4096R: 0xA2591E231E251F36 Key fingerprint: E3C5 114C 0C5B 4C49 BA03 0991 A259 1E23 1E25 1F36 My signed E-Mails are trustworthy. signature.asc Description: OpenPGP digital signature
Bug#881818: xsltproc: FTBFS on ia64
Package: xsltproc Version: 1.1.26-14.1 Severity: normal Tags: patch Dear Maintainer, When trying to build on ia64, the compiler complains that it cannot find INT_MAX for libxslt/transform.c. The attached patch #includes the appropriate system header file. -- System Information: Debian Release: 7.11 APT prefers oldoldstable APT policy: (500, 'oldoldstable') Architecture: ia64 Kernel: Linux 3.2.0-4-mckinley (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xsltproc depends on: ii libc6.1 2.13-38+deb7u10 ii libxml2 2.8.0+dfsg1-7+wheezy5 ii libxslt1.1 1.1.26-14.1 xsltproc recommends no packages. xsltproc suggests no packages. -- no debconf information --- libxslt/transform.c.orig 2017-11-15 09:21:22.240917554 -0500 +++ libxslt/transform.c 2017-11-15 09:21:33.780859781 -0500 @@ -21,6 +21,7 @@ #include #include +#include #include #include
Bug#845498: [Pkg-pascal-devel] Bug#845498: Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers
Hi Peter and All,
On Tue, 2017-11-14 at 23:32 +, peter green wrote:
> Going to experimental before unstable with aggressive changes certainly makes
> sense. IIRC experimental buildds only use build-depends from experimental when
> required to satisfy version constraints, so by changing version constraints
> one can choose whether to build a new version in experimental with the
> previous version from experimental or with the known-good version from
> unstable.
Yes, I think this is the way to go in order to avoid the need of re-uploading
binary packages in cas anything goes wrong.
> However I am skeptical as to whether such an aggressive change is really
> needed. IMO given the relatively small scale of this problem it makes more
> sense to leave most architectures alone and only deviate from upstream where
> we actually need to do so.
In fact, the biggest interest of MA for FPC is to build for arm and especially
to cross build for Android. So I fear that this is not a tiny goal. Otherwise we
drop MA support which will be a pity.
> I just ran a quick check and currently the only architectures with a conflict
> are armel and armhf. It seems likely ppc64el would also have a conflict but
> IMO we can cross that bridge when we come to it.
This is indeed the mail problem. People are asking for better MA support to be
able to use FPC for their phone development and here arm architectures are
important.
Upstream solves this by using a different base dir. We can for instance replace
/usr/lib/${DEB_PACKAGE_NAME}/${DEB_UPSTREAM_MAIN_VERSION}by/usr/lib/${FPCTARGET}-${FPCARCH}/${DEB_PACKAGE_NAME}/${DEB_UPSTREAM_MAIN_VERSION}This
is probably less intrusive, but have 2 levels of ${FPCTARGET}--
Cheers,
Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
Bug#881782: earlyoom: FTBFS on hurd-i386: PATH_MAX undeclared
Yangfl writes: > Sorry for having no non-Linux platform. But I think maybe I should > simply mark it as linux-any. That's fair; although (k)FreeBSD and the Hurd do both have Linux-ish /proc filesystems these days, I see no /proc/[pid]/oom_score_adj on either. Thanks, and sorry for not thinking my initial suggestion through more fully. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#881819: d/tests/control: Execution of dep8 tests requires python(3)-testscenarios
Package: python-testtools Version: 2.3.0-2 Severity: minor Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu bionic ubuntu-patch Dear Maintainer, In Ubuntu, the attached patch was applied to achieve the following: * d/tests/control: Execution of dep8 tests requires python(3)-testscenarios. Thanks for considering the patch. -- System Information: Debian Release: buster/sid APT prefers bionic APT policy: (500, 'bionic') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-16-generic (SMP w/4 CPU cores) 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 /bin/dash Init: systemd (via /run/systemd/system) diff -Nru python-testtools-2.3.0/debian/tests/control python-testtools-2.3.0/debian/tests/control --- python-testtools-2.3.0/debian/tests/control 2017-11-01 18:39:28.0 -0400 +++ python-testtools-2.3.0/debian/tests/control 2017-11-15 09:46:14.0 -0500 @@ -1,5 +1,5 @@ Tests: testsuite-py2 -Depends: python-testtools +Depends: python-testtools, python-testscenarios Tests: testsuite-py3 -Depends: python3-testtools +Depends: python3-testtools, python3-testscenarios
Bug#881750: gbp --import-orig --merge-mode=replace behaves as --merge-mode=merge
Hi, On Wed, Nov 15, 2017 at 03:02:33PM +0100, Víctor Cuadrado Juan wrote: > > > On 14/11/17 22:47, Guido Günther wrote: > > Hi, > > > > This wired and I wouldn't expect uncommitted changes but since I don't > > know about your setup and what you're doing (the upstream repo > > e.g. already has the version you're trying to import) you'd have to > > provide better instructions to reproduce and tell me what you actually > > think is wrong. > With git-buildpackage 0.8.12.2 in Stretch, if I take Debian's guitarix up > until 0.35.6, I can do > > gbp --import-orig --uscan --merge-mode=replace > > and it will correctly import the new 0.36.0 upstream version, merge it to > master > and preserve the already existing contents at debian/*. > > With git-buildpackage 0.9.2 (today in Testing and Unstable), doing the same > will overwrite the contents at debian/* with upstream sources, contrary to > what --merge-mode=replace should do. That would be a grave bug. Can you still reproduce it? If so please send me the refs of the branches (master and upstream) before you run uscn so I can try to reproduce. > Sadly I wanted to keep working on guitarix and submit a new upload, so I > already committed 0.36.0 to the guitarix repo at > https://anonscm.debian.org/cgit/pkg-multimedia/guitarix.git/ . > > > Can you reproduce this with other packages? > > I tried to reproduce it with git-buildpackage 0.9.1 against python-pyo and > lv2proc packages, and it worked fine. > > So if you see no problem on gbp output as said, feel free to close the bug. > Maybe it was a fluke caused by several people working in guitarix's > repo. See above. Can you try to pass me the commits (or even better prepare a repo in the exact state) that I need to run gbp import-orig against? I tried several variants here but it always worked (as it did with the test run on the rest of the archive on my last sweep). Even the debian/ tree from your logs (c4a8a211261fc53b556732b1b724f938060d0135) is the same one that my invocation uses as is the parent commit on upstream. If you could provide more information on how to reproduce this that'd be great. If not let's close this for the moment. Should you hit that again please tar the _whole_ git repo and send me link so I can infer things from the reflog. Cheers, -- Guido
Bug#881820: pkg-haskell-tools build depends on libghc-concurrent-output-dev (< 1.8) but 1.9.2-1 is to be installed
Source: pkg-haskell-tools Version: 0.11.0 Severity: serious The following packages have unmet dependencies: builddeps:pkg-haskell-tools : Depends: libghc-concurrent-output-dev (< 1.8) but 1.9.2-1 is to be installed
Bug#881821: stylish-haskell build depends on libghc-syb-dev (< 0.7) but 0.7-1 is to be installed
Source: stylish-haskell Version: 0.7.1.0-1 Severity: serious The following packages have unmet dependencies: builddeps:stylish-haskell : Depends: libghc-syb-dev (< 0.7) but 0.7-1 is to be installed
Bug#881822: pcp: pmatop binary segfault when ran as-is
Package: pcp Version: 3.12.1+b1 Severity: normal Dear Maintainer, pmatop binary segfault when ran as is # pmatop Segmentation fault (core dumped) -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.4.0-1002-fips (SMP w/8 CPU cores) 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 /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pcp depends on: ii gawk 1:4.1.4+dfsg-1 ii libc6 2.24-17 ii libncurses5 6.0+20170902-1 ii libpapi5 5.5.1-2 ii libpcp-gui2 3.12.1+b1 ii libpcp-mmv1 3.12.1+b1 ii libpcp-pmda-perl 3.12.1+b1 ii libpcp-pmda3 3.12.1+b1 ii libpcp-trace2 3.12.1+b1 ii libpcp-web1 3.12.1+b1 ii libpcp3 3.12.1+b1 ii libpfm4 4.8.0+git16-g8385268-1 ii libreadline7 7.0-3 ii libtinfo5 6.0+20170902-1 ii procps2:3.3.12-3 ii python3 3.6.3-2 ii python3-pcp 3.12.1+b1 pcp recommends no packages. Versions of packages pcp suggests: pn libpcp-import-perl pn pcp-gui -- no debconf information
Bug#881824: openjdk-7-jre-dcevm: FTBFS due to -Werror=format-overflow
Source: openjdk-7-jre-dcevm
Version: 7u79-4
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi,
openjdk-7-jre-dcevm FTBFS in a current sid+experimental environment:
Compiling /build/openjdk-7-jre-dcevm-7u79/src/share/vm/adlc/output_c.cpp
rm -f ../generated/adfiles/output_c.o
g++ -DLINUX -D_GNU_SOURCE -DIA32
-I/build/openjdk-7-jre-dcevm-7u79/src/share/vm/prims
-I/build/openjdk-7-jre-dcevm-7u79/src/share/vm
-I/build/openjdk-7-jre-dcevm-7u79/src/share/vm/precompiled -I/build/openjdk-7-jr
e-dcevm-7u79/src/cpu/x86/vm
-I/build/openjdk-7-jre-dcevm-7u79/src/os_cpu/linux_x86/vm
-I/build/openjdk-7-jre-dcevm-7u79/src/os/linux/vm
-I/build/openjdk-7-jre-dcevm-7u79/src/os/posix/vm -I/build/openjdk-7-jre-dcev
m-7u79/src/share/vm/adlc -I../generated -DASSERT -g -O2
-fdebug-prefix-map=/build/openjdk-7-jre-dcevm-7u79=. -fstack-protector-strong
-Wformat -Werror=format-security -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DT
ARGET_ARCH_MODEL_x86_32 -DTARGET_OS_ARCH_linux_x86
-DTARGET_OS_ARCH_MODEL_linux_x86_32 -DTARGET_COMPILER_gcc -DCOMPILER2
-DCOMPILER1 -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new
-fvisibility=hidden -m32 -ma
rch=i586 -pipe -g -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86
-DTARGET_ARCH_MODEL_x86_32 -DTARGET_OS_ARCH_linux_x86
-DTARGET_OS_ARCH_MODEL_linux_x86_32 -DTARGET_COMPILER_gcc -DCOMPILER2
-DCOMPILER1 -fno-rtti -fno-
exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m32 -march=i586 -pipe
-g -Werror -c -o ../generated/adfiles/output_c.o
/build/openjdk-7-jre-dcevm-7u79/src/share/vm/adlc/output_c.cpp
/build/openjdk-7-jre-dcevm-7u79/src/share/vm/adlc/output_c.cpp: In member
function 'void ArchDesc::build_pipe_classes(FILE*)':
/build/openjdk-7-jre-dcevm-7u79/src/share/vm/adlc/output_c.cpp:601:6: error:
'%*d' directive output between 1 and 2147483647 bytes may cause result to
exceed 'INT_MAX' [-Werror=format-overflow=]
void ArchDesc::build_pipe_classes(FILE *fp_cpp) {
^~~~
/build/openjdk-7-jre-dcevm-7u79/src/share/vm/adlc/output_c.cpp:601:6: note:
directive argument in the range [0, 2147483647]
cc1plus: all warnings being treated as errors
/build/openjdk-7-jre-dcevm-7u79/make/linux/makefiles/adlc.make:214: recipe for
target '../generated/adfiles/output_c.o' failed
make[6]: *** [../generated/adfiles/output_c.o] Error 1
This is likely a new warning in the current gcc.
Andreas
openjdk-7-jre-dcevm_7u79-4.log.gz
Description: application/gzip
Bug#846604: git-buildpackage: add a way to generate a RFS
Hi, On Fri, Dec 02, 2016 at 03:51:25PM +0100, Félix Sipma wrote: > Package: git-buildpackage > Version: 0.8.7 > Severity: wishlist > > It would be great to have a way to generate a RFS from gbp. Could you explain how this should look like. I think we can already do this via a postbuild hook. That said in recent gbp you might rather do this from gbp tag? Cheers, -- Guido
Bug#881823: systemd-networkd: Fails to start with 'Could not enumerate rules: Operation not supported'
Source: systemd Version: 235-3 Severity: normal Tags: upstream Hi! systemd-networkd fails to start on some machines with: Nov 15 15:13:37 pathfinder systemd[1]: Starting Network Service... Nov 15 15:13:37 pathfinder systemd-networkd[1799]: Could not enumerate rules: Operation not supported Nov 15 15:13:37 pathfinder systemd[1]: systemd-networkd.service: Main process exited, code=exited, status=1/FAILURE Nov 15 15:13:37 pathfinder systemd[1]: systemd-networkd.service: Failed with result 'exit-code'. Nov 15 15:13:37 pathfinder systemd[1]: Failed to start Network Service. Nov 15 15:13:37 pathfinder systemd[1]: systemd-networkd.service: Service has no hold-off time, scheduling restart. Nov 15 15:13:37 pathfinder systemd[1]: systemd-networkd.service: Scheduled restart job, restart counter is at 1. Nov 15 15:13:37 pathfinder systemd[1]: Stopped Network Service. This issue affects all my buildds which use systemd-networkd for networking. Upstream fixed this issue in [1]. Would it be possible to backport this fix? Thanks, Adrian > [1] https://github.com/systemd/systemd/pull/7030 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#881750: gbp --import-orig --merge-mode=replace behaves as --merge-mode=merge
On 15/11/17 15:53, Guido Günther wrote: > Hi, > On Wed, Nov 15, 2017 at 03:02:33PM +0100, Víctor Cuadrado Juan wrote: >> >> >> On 14/11/17 22:47, Guido Günther wrote: >>> Hi, >>> >>> This wired and I wouldn't expect uncommitted changes but since I don't >>> know about your setup and what you're doing (the upstream repo >>> e.g. already has the version you're trying to import) you'd have to >>> provide better instructions to reproduce and tell me what you actually >>> think is wrong. >> With git-buildpackage 0.8.12.2 in Stretch, if I take Debian's guitarix up >> until 0.35.6, I can do >> >> gbp --import-orig --uscan --merge-mode=replace >> >> and it will correctly import the new 0.36.0 upstream version, merge it to >> master >> and preserve the already existing contents at debian/*. >> >> With git-buildpackage 0.9.2 (today in Testing and Unstable), doing the same >> will overwrite the contents at debian/* with upstream sources, contrary to >> what --merge-mode=replace should do. > > That would be a grave bug. Can you still reproduce it? If so please send > me the refs of the branches (master and upstream) before you run uscn so > I can try to reproduce. > >> Sadly I wanted to keep working on guitarix and submit a new upload, so I >> already committed 0.36.0 to the guitarix repo at >> https://anonscm.debian.org/cgit/pkg-multimedia/guitarix.git/ . >> >>> Can you reproduce this with other packages? >> >> I tried to reproduce it with git-buildpackage 0.9.1 against python-pyo and >> lv2proc packages, and it worked fine. >> >> So if you see no problem on gbp output as said, feel free to close the bug. >> Maybe it was a fluke caused by several people working in guitarix's >> repo. > > See above. Can you try to pass me the commits (or even better prepare a > repo in the exact state) that I need to run gbp import-orig against? I > tried several variants here but it always worked (as it did with the > test run on the rest of the archive on my last sweep). Even the debian/ > tree from your logs (c4a8a211261fc53b556732b1b724f938060d0135) is the > same one that my invocation uses as is the parent commit on upstream. > > If you could provide more information on how to reproduce this that'd be > great. If not let's close this for the moment. Should you hit that again > please tar the _whole_ git repo and send me link so I can infer things > from the reflog. > > Cheers, > -- Guido > I have taken https://anonscm.debian.org/cgit/pkg-multimedia/guitarix.git/ and do `git reset --hard`, deleted tags and removed the debian remote to have it look as it was before importing upstream's 0.36.0, and I can reproduce the bug in it: git clone https://github.com/viccuad/example-bug-gbp && cd example-bug-gbp git fetch origin upstream:upstream pristine-tar:pristine-tar gbp import-orig --pristine-tar --uscan --merge-mode=replace # or auto, is the same # notice that debian/* has changes to be committed I will delete that repo once this bug is closed/fixed. Cheers, -- Víctor Cuadrado Juan m...@viccuad.me PGP key ID: 4096R: 0xA2591E231E251F36 Key fingerprint: E3C5 114C 0C5B 4C49 BA03 0991 A259 1E23 1E25 1F36 My signed E-Mails are trustworthy. signature.asc Description: OpenPGP digital signature
Bug#822683: maildrop: removal of courier-maildrop changed the behaviour
Hi Markus,
we are using courier-mta on Stretch too and actually we have
problems when using DEFAULTDELIVERY="| /usr/bin/maildrop -w90" in the
configuration. When using the following Workaround
DEFAULTDELIVERY='| /usr/bin/maildrop -w 90 -V 9 -d "${RECIPIENT}"'
it's working as expected.
It would great if there is a bugfix or something. :)
Thanks for working on the courier-mta package.
Regards
Steven
On Fri, 24 Mar 2017 16:17:05 +0100 Markus Wanner wrote:
Control: merge 822683 822446
I'm not quite sure how to fix this, yet, but I ran into the very same issue.
It seems the difference is not in Debian patches, but depends on the
HAVE_COURIER macro. I'll check with the maildrop maintainer.
Kind Regards
Markus Wanner
--
DigiOnline GmbH • Neusser Strasse 93 • 50670 Koeln
AG Koeln • HRB 27711 • St-Nr 521558110640 • USt-IdNr DE180751163
Geschaeftsfuehrer: Werner Grafenhain
https://www.digionline.de/impressum
Bug#881826: devscripts: sadt: does not parse debian/control with comments
Package: devscripts Version: 2.17.11 User: devscri...@packages.debian.org Usertags: sadt sadt fails to correctly parse debian/control files that include comments in their build-dependencies, for instance: $ mkdir -p debian/tests $ cat > debian/control << EOF Source: s Build-Depends: # some comment here sl EOF $ cat > debian/tests/control << EOF Tests: sl-exists Depends: @builddeps@ EOF $ cat > debian/tests/sl-exists << EOF #!/bin/sh dpkg -l sl EOF $ sadt Traceback (most recent call last): File "/usr/bin/sadt", line 476, in main() File "/usr/bin/sadt", line 378, in main for n, para in enumerate(deb822.Packages.iter_paragraphs(file)): File "/usr/lib/python3/dist-packages/debian/deb822.py", line 378, in iter_paragraphs for section in parser: apt_pkg.Error: E:Unable to parse package file (1) This is refused by libapt-pkg's deb822 format parser, but permitted by the pure-Python one in python-debian, as noted in a comment in python-debian: :param use_apt_pkg: if sequence is a file, apt_pkg can be used if available to parse the file, since it's much much faster. Set this parameter to True to enable use of apt_pkg. Note that the TagFile parser from apt_pkg is a much stricter parser of the Deb822 format, particularly with regards whitespace between paragraphs and comments within paragraphs. If these features are required (for example in debian/control files), ensure that this parameter is set to False. The "Packages" subclass (which is intended for parsing Packages files in apt repos, not deb822 files in general) sets use_apt_pkg to true. The simplest fix is to change sadt line 378 to pass use_apt_pkg=False, but in theory, python-debian should gain a new subclass for debian/control files that has the _PkgRelationMixin but uses the more lenient parser. If you would like me to commit this change to the collab-maint repo, let me know. I've confirmed that it does fix the problem. -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com
Bug#881825: devscripts: sadt: does not parse tests separated by commas
Package: devscripts
Version: 2.17.11
User: devscri...@packages.debian.org
Usertags: sadt
The autopkgtest spec says that test names can be separated by "comma
and/or whitespace" [1]. sadt only understands tests separated by
whitespace:
$ mkdir -p debian/tests
$ echo 'Source: foo' > debian/control
$ echo 'Tests: one, two' > debian/tests/control
$ ln -s /bin/true debian/tests/one
$ ln -s /bin/true debian/tests/two
$ sadt -v
one, ... SKIP (debian/tests/one, could not be made executable: [Errno 2] No
such file or directory: 'debian/tests/one,')
two ... ok
--
Ran 2 tests
OK (skipped=1)
autopkgtest itself implements this with .replace(',', ' ').split() [2],
which seems reasonable. Also the spec isn't clear but it looks like the
same should be done with restrictions and features.
If you would like me to commit this change to the collab-maint repo, let
me know. I've confirmed that it does fix the problem.
[1]
https://anonscm.debian.org/git/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst
[2]
https://anonscm.debian.org/git/autopkgtest/autopkgtest.git/tree/lib/testdesc.py?h=4.3#n413
--
Geoffrey Thomas
https://ldpreload.com
geo...@ldpreload.com
Bug#881647: debian-faq: please add new Dutch translation
Hi, Joost van Baal-Ilić wrote: > Hi Holger, Hallo Frans, > > This is really great, thanks a lot. I hope to find a timeslot soonish and > apply this patch. I could also apply it myself, if that's ok. I just don't wanted to do this changing witout an OK from maintainer, that's why this bugreport. Holger > On Mon, Nov 13, 2017 at 09:43:35PM +0100, Holger Wansing wrote: > > Package: debian-faq > > Severity: wishlist > > Tags: patch,l10n > > X-Debbugs-CC: frans.spiesscha...@yucom.be > > > > I got a fully translated po-based Dutch translation for the Debian FAQ from > > Frans Spiesschaert (in X-Debbugs-CC), and added the additional files, which > > are needed to build the translation, to add the 'debian-faq-nl' extra > > package > > etc. > > > > I did check for formatting errors, and it builds fine (html and pdf). > > > > A complete patch is attached. > > > > -- Created with Sylpheed 3.5.1 under D E B I A N L I N U X 9 " S T R E T C H " . Registered Linux User #311290 - https://linuxcounter.net/
Bug#881647: debian-faq: please add new Dutch translation
Hi, On Wed, Nov 15, 2017 at 04:38:08PM +0100, Holger Wansing wrote: > Joost van Baal-Ilić wrote: > > > > This is really great, thanks a lot. I hope to find a timeslot soonish and > > apply this patch. > > I could also apply it myself, if that's ok. > I just don't wanted to do this changing witout an OK from maintainer, that's > why this bugreport. O! Yes please, do apply. Thanks, Bye, Joost
Bug#881827: pykde4 FTBFS: sip: ::KFontChooser ctor argument 5 has an unsupported type for a Python signature
Source: pykde4 Version: 4:4.14.3-3 Severity: serious Some recent change in unstable makes pykde4 FTBFS: https://teshttps://tests.reproducible-builds.org/debian/history/pykde4.html ts.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pykde4.html ... sip: ::KFontChooser ctor argument 5 has an unsupported type for a Python signature - provide a valid type, %MethodCode and a C++ signature CMakeFiles/python_module_PyKDE4_kio.dir/build.make:185: recipe for target 'sip/kio/sipkiopart0.cpp' failed make[5]: *** [sip/kio/sipkiopart0.cpp] Error 1
Bug#881058: gwhois: diff for NMU version 20120626-1.2
Control: tags 881058 + patch
Control: tags 881058 + pending
Dear maintainer,
I've prepared an NMU for gwhois (versioned as 20120626-1.2) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.
Regards.
--
.''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
`- NP: Ostbahn-Kurti & Die Chefpartie: Da Joker
diff -Nru gwhois-20120626/debian/changelog gwhois-20120626/debian/changelog
--- gwhois-20120626/debian/changelog 2017-07-15 01:12:47.0 +0200
+++ gwhois-20120626/debian/changelog 2017-11-15 16:44:51.0 +0100
@@ -1,3 +1,12 @@
+gwhois (20120626-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix "please switch Depends from lynx-cur to lynx":
+do as the bug report requests.
+(Closes: #881058)
+
+ -- gregor herrmann Wed, 15 Nov 2017 16:44:51 +0100
+
gwhois (20120626-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru gwhois-20120626/debian/control gwhois-20120626/debian/control
--- gwhois-20120626/debian/control 2015-04-17 23:30:06.0 +0200
+++ gwhois-20120626/debian/control 2017-11-15 16:43:54.0 +0100
@@ -7,7 +7,7 @@
Package: gwhois
Architecture: all
-Depends: ${misc:Depends}, debconf | debconf-2.0, perl, libwww-perl, lynx-cur, curl, libnet-libidn-perl
+Depends: ${misc:Depends}, debconf | debconf-2.0, perl, libwww-perl, lynx, curl, libnet-libidn-perl
Suggests: openbsd-inetd | inet-superserver
Description: generic Whois Client / Server
gwhois is a generic whois client / server. This means that it know
signature.asc
Description: Digital Signature
Bug#842441: m17n-lib FTCBFS: uses build architecture pkg-config
Hi Manuel, Apologies! This fell off my radar. I'll make some time to look at this. cya, #
Bug#881731: rdma-core: FTBFS on armhf and mips*: missing providers that need coherent DMA
On 11/14/17 21:44, Leon Romanovsky wrote: On Tue, Nov 14, 2017 at 03:41:13PM -0500, Don Dutile wrote: Jason: Why am I being cc'd on this debian bug? I also received a notice about a bug fix in debian, and I had zip to do with it. Is my name tagged in Debian wrt rdma for some reason? by someone? other? Don, All of us received this email [1], because maintainer of rdma-core package is mailing list: "Package: src:rdma-core; Maintainer for src:rdma-core is Linux RDMA Mailing List ;" [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881731 Something that's very annoying is that "linux-rdma" is not in the Cc-list of the bug tracker e-mails so these e-mails escape from filter rules. I would appreciate it if either linux-rdma would be removed as a maintainer from the Debian bug tracker, if it would be made visible in the e-mail Cc-list. Thanks, Bart.
Bug#681726: Time to remove eclipse from Testing?
On Wed, Nov 15, 2017 at 12:08:10AM +0100, Markus Koschany wrote: >... > We should definitely try to avoid this sort of dependency mess in the > future by packaging important libraries like eclipse-rcp in a separate > source package. That would be similar to what we are doing whith > Netbeans and libnb-platform18-java at the moment. It simply ensures that > we can resolve such issues more easily by dropping the hard to maintain > IDE but keeping other important dependencies which don't require that > much effort in theory. I tried to sort out what I could find as required for getting the ancient eclipse out of testing in [1]: 1. src:bnd You fixed that already. 2. batik -> maven -> guice -> libspring-java -> aspectj -> eclipse-platform Is there some good way to break this dependency chain? 3. split libequinox-osgi-java out of src:eclise Or as a short-term hack, build only libequinox-osgi-java from src:eclipse. > Regards, > > Markus cu Adrian [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880470#10 -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#856959: libm17n-0: include patch to fix a foreign crash
Apologies for the delay. I'm checking with upstream the status of that patch.
Bug#881750: gbp --import-orig --merge-mode=replace behaves as --merge-mode=merge
Hi, On Wed, Nov 15, 2017 at 04:21:58PM +0100, Víctor Cuadrado Juan wrote: > > > On 15/11/17 15:53, Guido Günther wrote: > > Hi, > > On Wed, Nov 15, 2017 at 03:02:33PM +0100, Víctor Cuadrado Juan wrote: > >> > >> > >> On 14/11/17 22:47, Guido Günther wrote: > >>> Hi, > >>> > >>> This wired and I wouldn't expect uncommitted changes but since I don't > >>> know about your setup and what you're doing (the upstream repo > >>> e.g. already has the version you're trying to import) you'd have to > >>> provide better instructions to reproduce and tell me what you actually > >>> think is wrong. > >> With git-buildpackage 0.8.12.2 in Stretch, if I take Debian's guitarix up > >> until 0.35.6, I can do > >> > >> gbp --import-orig --uscan --merge-mode=replace > >> > >> and it will correctly import the new 0.36.0 upstream version, merge it to > >> master > >> and preserve the already existing contents at debian/*. > >> > >> With git-buildpackage 0.9.2 (today in Testing and Unstable), doing the same > >> will overwrite the contents at debian/* with upstream sources, contrary to > >> what --merge-mode=replace should do. > > > > That would be a grave bug. Can you still reproduce it? If so please send > > me the refs of the branches (master and upstream) before you run uscn so > > I can try to reproduce. > > > >> Sadly I wanted to keep working on guitarix and submit a new upload, so I > >> already committed 0.36.0 to the guitarix repo at > >> https://anonscm.debian.org/cgit/pkg-multimedia/guitarix.git/ . > >> > >>> Can you reproduce this with other packages? > >> > >> I tried to reproduce it with git-buildpackage 0.9.1 against python-pyo and > >> lv2proc packages, and it worked fine. > >> > >> So if you see no problem on gbp output as said, feel free to close the bug. > >> Maybe it was a fluke caused by several people working in guitarix's > >> repo. > > > > See above. Can you try to pass me the commits (or even better prepare a > > repo in the exact state) that I need to run gbp import-orig against? I > > tried several variants here but it always worked (as it did with the > > test run on the rest of the archive on my last sweep). Even the debian/ > > tree from your logs (c4a8a211261fc53b556732b1b724f938060d0135) is the > > same one that my invocation uses as is the parent commit on upstream. > > > > If you could provide more information on how to reproduce this that'd be > > great. If not let's close this for the moment. Should you hit that again > > please tar the _whole_ git repo and send me link so I can infer things > > from the reflog. > > > > Cheers, > > -- Guido > > > > I have taken https://anonscm.debian.org/cgit/pkg-multimedia/guitarix.git/ > and do `git reset --hard`, deleted tags and removed the debian remote to have > it look as it was before importing upstream's 0.36.0, and I can > reproduce That's what I did yesterday. > the bug in it: > > git clone https://github.com/viccuad/example-bug-gbp && cd example-bug-gbp > git fetch origin upstream:upstream pristine-tar:pristine-tar > gbp import-orig --pristine-tar --uscan --merge-mode=replace # or auto, is > the same > # notice that debian/* has changes to be committed > > I will delete that repo once this bug is closed/fixed. Thanks. But then again, same output as in my previous attempts. Everything looks fine. Is it possible that you're somehow picking old gbp code from a pip install or similar? What's in your gbp.conf? Can you make sure with "strace -e file -s2048 " that the right gbp and git are being used? Cheers, -- Guido
Bug#881828: sigrok-cli: Please include the firmware extractors as well
Package: sigrok-cli Version: 0.7.0-2 Severity: normal It's really great that the software is available as a default package in Debian! It would be even better if the firmware extractors are included as well, see https://sigrok.org/gitweb/?p=sigrok-util.git;a=tree;f=firmware Thank you very much! -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), LANGUAGE=de_AT:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages sigrok-cli depends on: ii libc6 2.24-17 ii libglib2.0-0 2.54.1-1 ii libsigrok40.5.0-3 ii libsigrokdecode4 0.5.0-4+b1 sigrok-cli recommends no packages. sigrok-cli suggests no packages. -- no debconf information --
Bug#881829: fai - Use tar --xattrs
Source: fai Version: 5.5 Severity: normal Please always use --xattrs for base tar operations. This allows the ping e.g. capability setting to remain. Bastian -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#881733: totem: Totem unable to play anything with any user but root
El 14/11/17 a las 20:12, Michael Biebl escribió: Am 14.11.2017 um 19:39 schrieb jEsuSdA 8): El 14/11/17 a las 17:41, Michael Biebl escribió: With a fresh user it works. I try to delete some .cache .dbus files and it works! I suspect it is ~/.cache/gstreamer-1.0/registry.x86_64.bin which got messed up. That's why I asked you to test with a fresh user account. I vaguely remember a few bug reports in that regard. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715529 is a rather old one but I think we had similar user reports just recently. What Jeremy said is true as well: Please don't run graphical applications as root! Regards, Michael Thank you so much, Michael. It was the ~/.cache/gstreamer-1.0/registry.x86_64.bin file!!! It works fine now! Thank you, thank you so much
Bug#881770: jbuilder
Has this been reported upstream ? https://github.com/janestreet/jbuilder/issues
Bug#881750: gbp --import-orig --merge-mode=replace behaves as --merge-mode=merge
On 15/11/17 17:00, Guido Günther wrote:
> Hi,
> On Wed, Nov 15, 2017 at 04:21:58PM +0100, Víctor Cuadrado Juan wrote:
>>
>>
>> On 15/11/17 15:53, Guido Günther wrote:
>>> Hi,
>>> On Wed, Nov 15, 2017 at 03:02:33PM +0100, Víctor Cuadrado Juan wrote:
On 14/11/17 22:47, Guido Günther wrote:
> Hi,
>
> This wired and I wouldn't expect uncommitted changes but since I don't
> know about your setup and what you're doing (the upstream repo
> e.g. already has the version you're trying to import) you'd have to
> provide better instructions to reproduce and tell me what you actually
> think is wrong.
With git-buildpackage 0.8.12.2 in Stretch, if I take Debian's guitarix up
until 0.35.6, I can do
gbp --import-orig --uscan --merge-mode=replace
and it will correctly import the new 0.36.0 upstream version, merge it to
master
and preserve the already existing contents at debian/*.
With git-buildpackage 0.9.2 (today in Testing and Unstable), doing the same
will overwrite the contents at debian/* with upstream sources, contrary to
what --merge-mode=replace should do.
>>>
>>> That would be a grave bug. Can you still reproduce it? If so please send
>>> me the refs of the branches (master and upstream) before you run uscn so
>>> I can try to reproduce.
>>>
Sadly I wanted to keep working on guitarix and submit a new upload, so I
already committed 0.36.0 to the guitarix repo at
https://anonscm.debian.org/cgit/pkg-multimedia/guitarix.git/ .
> Can you reproduce this with other packages?
I tried to reproduce it with git-buildpackage 0.9.1 against python-pyo and
lv2proc packages, and it worked fine.
So if you see no problem on gbp output as said, feel free to close the bug.
Maybe it was a fluke caused by several people working in guitarix's
repo.
>>>
>>> See above. Can you try to pass me the commits (or even better prepare a
>>> repo in the exact state) that I need to run gbp import-orig against? I
>>> tried several variants here but it always worked (as it did with the
>>> test run on the rest of the archive on my last sweep). Even the debian/
>>> tree from your logs (c4a8a211261fc53b556732b1b724f938060d0135) is the
>>> same one that my invocation uses as is the parent commit on upstream.
>>>
>>> If you could provide more information on how to reproduce this that'd be
>>> great. If not let's close this for the moment. Should you hit that again
>>> please tar the _whole_ git repo and send me link so I can infer things
>>> from the reflog.
>>>
>>> Cheers,
>>> -- Guido
>>>
>>
>> I have taken https://anonscm.debian.org/cgit/pkg-multimedia/guitarix.git/
>> and do `git reset --hard`, deleted tags and removed the debian remote to have
>> it look as it was before importing upstream's 0.36.0, and I can
>> reproduce
>
> That's what I did yesterday.
>
>> the bug in it:
>>
>> git clone https://github.com/viccuad/example-bug-gbp && cd
>> example-bug-gbp
>> git fetch origin upstream:upstream pristine-tar:pristine-tar
>> gbp import-orig --pristine-tar --uscan --merge-mode=replace # or auto,
>> is the same
>> # notice that debian/* has changes to be committed
>>
>> I will delete that repo once this bug is closed/fixed.
>
> Thanks. But then again, same output as in my previous
> attempts. Everything looks fine. Is it possible that you're somehow
> picking old gbp code from a pip install or similar? What's in your
> gbp.conf? Can you make sure with "strace -e file -s2048 " that
> the right gbp and git are being used?
>
> Cheers,
> -- Guido
>
Sadly I keep reproducing it in a fresh Sid VM, with no gbp.conf
(see attached file with strace output).
--
Víctor Cuadrado Juan m...@viccuad.me
PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03 0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.
vagrant@desktop:~$ git clone https://github.com/viccuad/example-bug-gbp && cd
example-bug-gbp
Cloning into 'example-bug-gbp'...
remote: Counting objects: 10959, done.
remote: Compressing objects: 100% (2843/2843), done.
remote: Total 10959 (delta 7949), reused 10959 (delta 7949), pack-reused 0
Receiving objects: 100% (10959/10959), 88.72 MiB | 1.28 MiB/s, done.
Resolving deltas: 100% (7949/7949), done.
vagrant@desktop:~/example-bug-gbp$ git fetch origin upstream:upstream
pristine-tar:pristine-tar
From https://github.com/viccuad/example-bug-gbp
* [new branch] upstream -> upstream
* [new branch] pristine-tar -> pristine-tar
vagrant@desktop:~/example-bug-gbp$ strace -e file -s2048 gbp import-orig
--pristine-tar --uscan --merge-mode=replace
execve("/usr/bin/gbp", ["gbp", "import-orig", "--pristine-tar", "--uscan",
"--merge-mode=replace"], 0x7ffc897c43c8 /* 24 vars */) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such fil
Bug#881828: [Pkg-electronics-devel] Bug#881828: sigrok-cli: Please include the firmware extractors as well
Control: reassign -1 wnpp Control: retitle -1 RFP: sigrok-util -- various sigrok related utilities On Wed, Nov 15, 2017 at 05:05:19PM +0100, Philipp Marek wrote: > Package: sigrok-cli > Version: 0.7.0-2 > Severity: normal > > It's really great that the software is available as a > default package in Debian! > > It would be even better if the firmware extractors are > included as well, see > https://sigrok.org/gitweb/?p=sigrok-util.git;a=tree;f=firmware This is more of a RFP rather than something that would be fixed in the sigrok-cli package. That said, the README states: | sigrok-util is in development and has not yet had official tarball releases. | | Distro packagers should NOT package this, yet. J. -- Revd Jonathan McDowell, ULC | Jealousy strikes again.
Bug#881830: linux: cherry-pick "security/keys: add CONFIG_KEYS_COMPAT to Kconfig" to stretch kernel
Source: linux Version: 4.9.51-1 Severity: wishlist Control: fixed -1 4.12.2-1~exp1 Hi, Is it possible to cherry-pick the following upstream commit into the stable kernel so it is available on the buildds? commit 47b2c3fff4932e6fc17ce13d51a43c6969714e20 Author: Bilal Amarni Date: Thu Jun 8 14:47:26 2017 +0100 security/keys: add CONFIG_KEYS_COMPAT to Kconfig This commit moves KEYS_COMPAT to an architecture independent location and enables it on all architectures where COMPAT is enabled. This should allow 64-bit MIPS kernels to handle 32-bit applications using the keyctl syscall (currently they fail with ENOSYS - see keyutils package). I think this will also help with compiling armhf on arm64 kernels. Thanks, James signature.asc Description: OpenPGP digital signature
Bug#881831: dgit-infrastructure: doesn't show anything on cgit when the only digt push hit only experimental
Package: dgit-infrastructure https://browse.dgit.debian.org/chicken.git/ currently shows an empty repository, because the only upload done through dgit only hit experimental. I think cgit has some thing where it won't display anything if there is no HEAD And the repos' HEAD is master by default The server updates master automatically if you upload to sid, but not when you upload to experimental right, I haven't yet uploaded to unstable (which I will soonish anyway), but I expected cgit it to show me exp now anyway I agree that it ought to. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#881832: python3-bitcoinlib,python3-bitcoin: duplicate packages?
Package: python3-bitcoinlib,python3-bitcoin Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Control: found -1 0.8.0-1 Control: found -1 1.1.42-1 Hi, automatic installation tests of packages that share a file and at the same time do not conflict by their package dependency relationships has detected the following problem: Selecting previously unselected package python3-bitcoin. Preparing to unpack .../python3-bitcoin_1.1.42-1_all.deb ... Unpacking python3-bitcoin (1.1.42-1) ... dpkg: error processing archive /var/cache/apt/archives/python3-bitcoin_1.1.42-1_all.deb (--unpack): trying to overwrite '/usr/lib/python3/dist-packages/bitcoin/__init__.py', which is also in package python3-bitcoinlib 0.8.0-1 Errors were encountered while processing: /var/cache/apt/archives/python3-bitcoin_1.1.42-1_all.deb This is a serious bug as it makes installation fail, and violates sections 7.6.1 and 10.1 of the policy. An optimal solution would consist in only one of the packages installing that file, and renaming or removing the file in the other package. Depending on the circumstances you might also consider Replace relations or file diversions. If the conflicting situation cannot be resolved then, as a last resort, the two packages have to declare a mutual Conflict. Please take into account that Replaces, Conflicts and diversions should only be used when packages provide different implementations for the same functionality. Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): usr/lib/python3/dist-packages/bitcoin/__init__.py This bug is assigned to both packages. If you, the maintainers of the two packages in question, have agreed on which of the packages will resolve the problem please reassign the bug to that package. You may also register in the BTS that the other package is affected by the bug. cheers, Andreas PS: for more information about the detection of file overwrite errors of this kind see https://qa.debian.org/dose/file-overwrites.html python3-bitcoinlib=0.8.0-1_python3-bitcoin=1.1.42-1.log.gz Description: application/gzip
Bug#874836: [bacula] Future Qt4 removal from Buster
Control: tag -1 - patch The upstream patch is incomplete and not yet useable.
Bug#849150: sagemath: FTBFS on arm64 and ppc64el: cannot allocate memory building docs
Control: notfixed -1 8.0-5 Control: reopen -1 Control: severity -1 minor You're right. I knew that we split the docbuild away (I did that, even) but I thought that the tests passing indicated that the bug was fixed. However I tried a full build on another ppc64el machine just now, and it seems that the problem is indeed specific to building the docs. [dochtml] ImportError: /usr/lib/powerpc64le-linux-gnu/libgomp.so.1: cannot allocate memory in static TLS block but the tests run OK, as they do on the buildds. In that case, I'll reopen the bug, but set the severity to minor. X Tobias Hansen: > Just for the record, this was fixed by building the documentation only in the > indep build. Building the documentation on these architectures will probably > still fail, but I agree that the bug can be closed. > > Best, Tobias > -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Bug#881772: ruby2.5: FTBFS on ppc64(el): stack level too deep
Hi, On Tue, Nov 14, 2017 at 06:16:22PM -0500, Aaron M. Ucko wrote: > Source: ruby2.5 > Version: 2.5.0~preview1-1 > Severity: important > Tags: upstream > Justification: fails to build from source > User: debian-powe...@lists.debian.org > Usertags: ppc64 ppc64el > > Builds of ruby2.5 for ppc64el and the non-release architecture ppc64 > have been failing per the below excerpt from > > https://buildd.debian.org/status/fetch.php?pkg=ruby2.5&arch=ppc64el&ver=2.5.0%7Epreview1-1&stamp=1510662722&raw=0 > > FTR, the ppc64 log, which exhibits the same error, is at > > https://buildd.debian.org/status/fetch.php?pkg=ruby2.5&arch=ppc64&ver=2.5.0%7Epreview1-1&stamp=1510663941&raw=0 > > Could you please take a look? Thanks for reporting. > Thanks! > > 1) Error: > TestBacktrace#test_caller_lev: > SystemStackError: stack level too deep > /<>/test/ruby/test_backtrace.rb:96:in `times' > /<>/test/ruby/test_backtrace.rb:96:in `block in > test_caller_lev' > /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in > test_caller_lev' > /<>/test/ruby/test_backtrace.rb:92:in `times' > /<>/test/ruby/test_backtrace.rb:92:in `block in > test_caller_lev' > /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in > test_caller_lev' > /<>/test/ruby/test_backtrace.rb:92:in `times' > /<>/test/ruby/test_backtrace.rb:92:in `block in > test_caller_lev' > /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in > test_caller_lev' > /<>/test/ruby/test_backtrace.rb:92:in `times' > /<>/test/ruby/test_backtrace.rb:92:in `block in > test_caller_lev' > /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in > test_caller_lev' > /<>/test/ruby/test_backtrace.rb:92:in `times' > /<>/test/ruby/test_backtrace.rb:92:in `block in > test_caller_lev' > /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in > test_caller_lev' > /<>/test/ruby/test_backtrace.rb:92:in `times' > /<>/test/ruby/test_backtrace.rb:92:in `block in > test_caller_lev' > /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in > test_caller_lev' > /<>/test/ruby/test_backtrace.rb:92:in `times' > /<>/test/ruby/test_backtrace.rb:92:in `block in > test_caller_lev' > /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in > test_caller_lev' > /<>/test/ruby/test_backtrace.rb:92:in `times' > /<>/test/ruby/test_backtrace.rb:92:in `block in > test_caller_lev' > /<>/test/ruby/test_backtrace.rb:106:in `block in > test_caller_lev' > > Finished tests in 517.516592s, 33.1661 tests/s, 4326.2574 assertions/s. > 17164 tests, 2238910 assertions, 0 failures, 1 errors, 85 skips > > ruby -v: ruby 2.5.0dev (2017-10-10) [powerpc64le-linux-gnu] > uncommon.mk:691: recipe for target 'yes-test-almost' failed Dear POWER porters, would you be able to help with this? I was able to reproduce this against current Ruby trunk. Here is a a minimal set of commands that will reproduce this failure: git clone https://github.com/ruby/ruby.git cd ruby autoreconf -i ./configure make ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems "./test/runner.rb" --ruby="./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems" --excludes-dir=./test/excludes --name=test_caller_lev test/ruby/test_backtrace.rb signature.asc Description: PGP signature
Bug#881831: dgit-infrastructure: doesn't show anything on cgit when the only digt push hit only experimental
reassign -1 cgit
retitle -1 Please display refs that do exist even if HEAD is missing
thanks
Hi, cgit maintainers. I have a request for a behavioural change:
Mattia Rizzolo writes ("Bug#881831: dgit-infrastructure: doesn't show anything
on cgit when the only digt push hit only experimental"):
> Package: dgit-infrastructure
>
> https://browse.dgit.debian.org/chicken.git/ currently shows an empty
> repository, because the only upload done through dgit only hit
> experimental.
>
> I think cgit has some thing where it won't display anything if there
> is no HEAD
> And the repos' HEAD is master by default
> The server updates master automatically if you upload to sid, but
> not when you upload to experimental
> right, I haven't yet uploaded to unstable (which I will soonish
> anyway), but I expected cgit it to show me exp now anyway
> I agree that it ought to.
The repository in question is in the following state:
iwj@gideon:/srv/dgit.debian.org/repos/chicken.git$ git for-each-ref
--format='%(refname)'
refs/dgit/experimental
refs/tags/archive/debian/4.12.0-0.2
refs/tags/debian/4.12.0-0.2
iwj@gideon:/srv/dgit.debian.org/repos/chicken.git$ git symbolic-ref HEAD
refs/heads/master
iwj@gideon:/srv/dgit.debian.org/repos/chicken.git$ git rev-parse HEAD
HEAD
iwj@gideon:/srv/dgit.debian.org/repos/chicken.git$
cgit just displays "Repository seems to be empty", even at
https://browse.dgit.debian.org/chicken.git/refs/
even though there are several refs, as you can see. (NB that cgit is
running on an rsync mirror of the repo, but I don't think that is
relevant.)
Compare
iwj@gideon:/srv/dgit.debian.org/repos/dgit.git$ git for-each-ref
--format='%(refname)' | grep -v refs/tags
refs/dgit/experimental
refs/dgit/jessie-backports
refs/dgit/sid
refs/dgit/stretch
refs/heads/master
iwj@gideon:/srv/dgit.debian.org/repos/dgit.git$ git symbolic-ref HEAD
refs/heads/master
iwj@gideon:/srv/dgit.debian.org/repos/dgit.git$ git rev-parse HEAD
b363aeb4b0228eff6ad85229946feeb3b4d92b77
iwj@gideon:/srv/dgit.debian.org/repos/dgit.git$
And see
https://browse.dgit.debian.org/dgit.git/
I think that this HEAD-less state is appropriate for Mattia's repo.
It would be better if cgit displayed its contents.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#881830: linux: cherry-pick "security/keys: add CONFIG_KEYS_COMPAT to Kconfig" to stretch kernel
Since I was a little puzzled as to why keyutils built previously on mips, I found this commit to 4.8 which caused the need for KEYS_COMPAT: commit 20f06ed9f61a185c6dabd662c310bed6189470df Author: David Howells Date: Wed Jul 27 11:43:37 2016 +0100 KEYS: 64-bit MIPS needs to use compat_sys_keyctl for 32-bit userspace MIPS64 needs to use compat_sys_keyctl for 32-bit userspace rather than calling sys_keyctl. The latter will work in a lot of cases, thereby hiding the issue. Now I'm thinking maybe this can be argued as a bugfix for the above commit and put in upstream 4.9? James signature.asc Description: OpenPGP digital signature
