Bug#824161: RFS: pyfr/1.4.0-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "pyfr" * Package name: pyfr Version : 1.4.0-2 Upstream Author : Imperial College London * URL : http://www.pyfr.org * License : BSD Section : science It builds those binary packages: pyfr - flux reconstruction in Python pyfr-doc - documentation for PyFR To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pyfr Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pyfr/pyfr_1.4.0-2.dsc Successful build log on debomatic: http://debomatic-amd64.debian.net/distribution#unstable/pyfr/1.4.0-2/buildlog Changes since the last upload: * Install pyfr module to private location. Thanks to Piotr Ozarowski * Drop unnecessary build dependencies. * Drop install dependency on mpi-default-bin. Regards, Ghislain Vaillant
Bug#823224: non-sense: Re: Bug#823224: ld: arch/powerpc/lib/crtsavres.o: No such file: No such file or directory
On Fri, May 13, 2016 at 8:39 AM, Mathieu Malaterre wrote: > Hi Ben ! > > On Mon, May 2, 2016 at 8:53 PM, Ben Hutchings wrote: >> Control: tag -1 upstream >> >> On Mon, 2016-05-02 at 15:07 +0200, Mathieu Malaterre wrote: >>> Package: src:linux >>> >>> On PPC: >>> >>> $ apt-get source linux-image-4.5.0-0.bpo.1-powerpc >>> $ cd linux-4.5.1 >>> $ make oldconfig >> >> That should fail as there is no .config file to start from. > > Well in my case, `make oldconfig` did copy the older configuration > properly for me. > >>> $ make modules_prepare >>> $ make modules SUBDIRS=drivers/gpu/drm/radeon >>> >>> or equivalent: >>> >>> $ make drivers/gpu/drm/radeon/radeon.ko >>> >>> both fails with: >>> >>> ld: arch/powerpc/lib/crtsavres.o: No such file: No such file or >>> directory >>> >>> Easy fix is obviously: >>> >>> $ make arch/powerpc/lib/crtsavres.o >>> >>> It would be nice to have proper deps setup. >> >> You should raise this upstream as it has nothing to do with the Debian >> packaging. > > Just to understand correctly, the Makefile currently reads as: > > $ grep -3 CONFIG_476FPE_ERR46 arch/powerpc/Makefile > > KBUILD_LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o > > ifeq ($(CONFIG_476FPE_ERR46),y) > KBUILD_LDFLAGS_MODULE += --ppc476-workaround \ > -T $(srctree)/arch/powerpc/platforms/44x/ppc476_modules.lds > endif > > > So `CONFIG_476FPE_ERR46` does not need to be explicitly set within > Debian setup, and must be a legacy variable that does not work anymore > nowadays (and thus is indeed a bug upstream). > > Thanks for clarification. Forget this non-sense. Sorry.
Bug#808276: [Pkg-ime-devel] Bug#808276: marisa: typo in package description (conteins -> contains)
Control: tags -1 newcomer On Fri, Dec 18, 2015 at 10:11:34AM +0100, Ansgar Burchardt wrote: > there's a small typo in the package description for marisa: "conteins" > should be "contains". Thanks for the report. I think this is suitable for newcomer. -- ChangZhuo Chen (陳昌倬) Debian Developer (https://nm.debian.org/public/person/czchen) Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B signature.asc Description: PGP signature
Bug#803423: #803423 libqt5gui5: Ugly GUI (no icons) / Weird interpretation of XDG_CURRENT_DESKTOP and GNOME_DESKTOP_SESSION_ID
On Thu, May 12, 2016 at 11:33:43PM +0300, Vladimir K wrote: > > In Qt 5.6, the GTK+ *style* was removed, and the rest of GTK+ integration > > (i.e. dialogs or icon theme settings) got ported to GTK+ 3. The recommended > > alternative for those who need the style is using third-party styles like > > Adwaita-Qt. > > So after version 5.6 Qt will mimic GTK 3 instead of GTK 2? The style is completely removed. The dialogs and settings will come from GTK+ 3.x, yes. > Just to be on the same page, if comparing GTK and QT ways of doing things, > Qt style is analogous to engine in GTK world, and Qt platform theme is > analogous to theme in GTK world, right? > Whey you choose theme in GTK, GTK selects appropriate engine to render that > theme. > Up until recently in Qt you had to choose style manually, and themes (if > particular style supported any) were > this style's personal matter. Has something changed recently? You are not right. A theme is a plugin that provides: icon theme settings, dialogs (file, color, font), platform menus, system tray icons, palette settings, font settings, standard keybindings, and more (the GTK+ theme only provides a subset of this). Everything related to look of widgets is style. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#823224: ld: arch/powerpc/lib/crtsavres.o: No such file: No such file or directory
Hi Ben ! On Mon, May 2, 2016 at 8:53 PM, Ben Hutchings wrote: > Control: tag -1 upstream > > On Mon, 2016-05-02 at 15:07 +0200, Mathieu Malaterre wrote: >> Package: src:linux >> >> On PPC: >> >> $ apt-get source linux-image-4.5.0-0.bpo.1-powerpc >> $ cd linux-4.5.1 >> $ make oldconfig > > That should fail as there is no .config file to start from. Well in my case, `make oldconfig` did copy the older configuration properly for me. >> $ make modules_prepare >> $ make modules SUBDIRS=drivers/gpu/drm/radeon >> >> or equivalent: >> >> $ make drivers/gpu/drm/radeon/radeon.ko >> >> both fails with: >> >> ld: arch/powerpc/lib/crtsavres.o: No such file: No such file or >> directory >> >> Easy fix is obviously: >> >> $ make arch/powerpc/lib/crtsavres.o >> >> It would be nice to have proper deps setup. > > You should raise this upstream as it has nothing to do with the Debian > packaging. Just to understand correctly, the Makefile currently reads as: $ grep -3 CONFIG_476FPE_ERR46 arch/powerpc/Makefile KBUILD_LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o ifeq ($(CONFIG_476FPE_ERR46),y) KBUILD_LDFLAGS_MODULE += --ppc476-workaround \ -T $(srctree)/arch/powerpc/platforms/44x/ppc476_modules.lds endif So `CONFIG_476FPE_ERR46` does not need to be explicitly set within Debian setup, and must be a legacy variable that does not work anymore nowadays (and thus is indeed a bug upstream). Thanks for clarification.
Bug#817852: Wrong package name used?
Hi, It seems the fix for this bug added the wrong package name to the Depends:. The package name that was added is libpeas-1.0-0-python2loader, whereas it should be libpeas-1.0-python2loader (with one less '0-'). Regards, -- Matijs signature.asc Description: OpenPGP digital signature
Bug#823832: ITP: python-mpd-parser -- MPEG-DASH MPD(Media Presentation Description) Parser
On Mon, 9 May 2016 17:45:08 +0100, Simon McVittie wrote: > Please talk to the upstream about a less colliding name, perhaps mpdesc. Upstream module name was changed to mpegdash. Changes: * Package name: python-mpegdash * URL : https://github.com/caststack/python-mpegdash OK
Bug#824142: mtr 0.86 uses suboptimal colours in curses (patch attached)
Hi Adam, I'm really busy right now. But if there is a patch out there that I need to apply "upstream", let me know. Roger. On Thu, May 12, 2016 at 01:40:04PM -0600, Adam Conrad wrote: > Package: mtr > Version: 0.86-1 > Severity: normal > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu yakkety ubuntu-patch > > > > In Ubuntu, the attached patch was applied to achieve the following: > > * Pull commits from upstream to fix terminal colours (LP: #1581186) > > As I note in the LP bug[1], this is hardly a critical issue, but it's > been driving me nuts since 0.86 landed. Stupidly, I went and learned > curses and fixed it locally, which only then gave me the right search > terms (mtr + use_default_colors) to get Google to point out that it > was already fixed in upstream git. So, I threw away my work, grabbed > the upstream commits, and here we are. > > Would be lovely for you to pick this up in the Debian package, so I > can delete my recently-added delta from Ubuntu (and so Debian users > can enjoy slightly less broken colours in mtr in unstable). > > ... Adam > > [1] https://bugs.launchpad.net/ubuntu/+source/mtr/+bug/1581186 > > -- System Information: > Debian Release: stretch/sid > APT prefers yakkety > APT policy: (500, 'yakkety') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.4.0-21-lowlatency (SMP w/4 CPU cores; PREEMPT) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > diff -Nru mtr-0.86/debian/patches/color1.patch > mtr-0.86/debian/patches/color1.patch > --- mtr-0.86/debian/patches/color1.patch 1969-12-31 17:00:00.0 > -0700 > +++ mtr-0.86/debian/patches/color1.patch 2016-05-12 12:58:21.0 > -0600 > @@ -0,0 +1,34 @@ > +commit 63a1f1493bfbaf7e55eb7e20b3791fc8b14cf92d > +Author: Rogier Wolff > +Date: Mon Dec 29 09:22:46 2014 +0100 > + > +added use-default-colors... > + > +diff --git a/configure.ac b/configure.ac > +index d5d1b0e..7199781 100644 > +--- a/configure.ac > b/configure.ac > +@@ -34,6 +34,9 @@ AC_CHECK_FUNC(initscr, , > + AC_DEFINE(NO_CURSES, 1, Define if you don't have the curses libraries > available.) > + CURSES_OBJ= > + > ++AC_CHECK_LIB(ncurses, use_default_colors, > ++ AC_DEFINE(HAVE_USE_DEFAULT_COLORS, 1, [Define this if your curses library > has the use_default_colors() command.])) > ++ > + AC_CHECK_FUNCS(attron fcntl) > + > + AC_CHECK_LIB(m, floor, , AC_MSG_ERROR(No math library found)) > +diff --git a/curses.c b/curses.c > +index 3904cb1..02b7937 100644 > +--- a/curses.c > b/curses.c > +@@ -701,6 +701,9 @@ void mtr_curses_open(void) > + raw(); > + noecho(); > + start_color(); > ++#ifdef HAVE_USE_DEFAULT_COLORS > ++ use_default_colors(); > ++#endif > + int i; > + for (i = 0; i < 8; i++) > + init_pair(i+1, i, 0); > diff -Nru mtr-0.86/debian/patches/color2.patch > mtr-0.86/debian/patches/color2.patch > --- mtr-0.86/debian/patches/color2.patch 1969-12-31 17:00:00.0 > -0700 > +++ mtr-0.86/debian/patches/color2.patch 2016-05-12 12:58:21.0 > -0600 > @@ -0,0 +1,30 @@ > +commit 7571201cf7a3394e0dcd2b037aba1836089cc084 > +Author: Narthorn > +Date: Mon Oct 12 13:24:57 2015 +0200 > + > +curses: Fix background transparency in terminal > + > +Patch comes from, and closes traviscross/mtr#72. > + > +diff --git a/curses.c b/curses.c > +index 02b7937..f95f5d1 100644 > +--- a/curses.c > b/curses.c > +@@ -700,13 +700,15 @@ void mtr_curses_open(void) > + initscr(); > + raw(); > + noecho(); > ++ int bg_col = 0; > + start_color(); > + #ifdef HAVE_USE_DEFAULT_COLORS > +- use_default_colors(); > ++ if (use_default_colors() == OK) > ++bg_col = -1; > + #endif > + int i; > + for (i = 0; i < 8; i++) > +- init_pair(i+1, i, 0); > ++ init_pair(i+1, i, bg_col); > + > + mtr_curses_init(); > + mtr_curses_redraw(); > diff -Nru mtr-0.86/debian/patches/series mtr-0.86/debian/patches/series > --- mtr-0.86/debian/patches/series2015-12-07 12:49:27.0 -0700 > +++ mtr-0.86/debian/patches/series2016-05-12 12:58:41.0 -0600 > @@ -0,0 +1,2 @@ > +color1.patch > +color2.patch -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work.
Bug#824160: p7zip: CVE-2016-2334 CVE-2016-2335
Hi Robert, One note though on this bugreport. Can you check it actually affects the port p7zip, and not only 7zip. Salvatore
Bug#824160: p7zip: CVE-2016-2334 CVE-2016-2335
Source: p7zip Version: 15.14.1+dfsg-1 Severity: grave Tags: security upstream fixed-upstream Hi, the following vulnerabilities were published for p7zip. CVE-2016-2334[0]: Heap-buffer-overflow vulnerability CVE-2016-2335[1]: Out-of-bounds read vuilerability If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2016-2334 [1] https://security-tracker.debian.org/tracker/CVE-2016-2335 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#800149: openjpeg2: Use-after-free in opj_j2k_write_mco
Control: retitle -1 openjpeg2: CVE-2015-8871: Use-after-free in opj_j2k_write_mco Hi, On Sun, Sep 27, 2015 at 01:54:25PM +0200, Salvatore Bonaccorso wrote: > Source: openjpeg2 > Version: 2.1.0-2 > Severity: important > Tags: security upstream patch fixed-upstream > Forwarded: https://github.com/uclouvain/openjpeg/issues/563 > > Hi > > A use-after-free vulnerability was found in openjpeg2, see > http://www.openwall.com/lists/oss-security/2015/09/15/4 for the > corresponding CVE request (no CVE assigned so far). > > Upstream issue: https://github.com/uclouvain/openjpeg/issues/563 This issue has been assigned CVE-2015-8871. Regards, Salvatore
Bug#817936: roger-router: Please add libpeas-1.0-0-python2loader to Depends
On 13.05.2016 12:26, Rolf Leggewie wrote: > there's been some talk in http://bugs.debian.org/620391 about Roger > Router and PEAS Python2 plugins. Make that http://bugs.debian.org/817936
Bug#817936: roger-router: Please add libpeas-1.0-0-python2loader to Depends
Jan-Michael, there's been some talk in http://bugs.debian.org/620391 about Roger Router and PEAS Python2 plugins. As upstream, are you actually aware of any Plugins for Roger that are Python 2? I'd rather see them ported to Python 3 or become deprecated than add a complicated web of additional dependencies to the Debian package. Would it be acceptable to do "sed s/python/python3/ ./libroutermanager/plugins.c" and require all python plugins to be ported to python3 from now on? FWIW, I'm not aware of any external, third-party plugins for Roger Router, irrespective of their programming language. Do they exist? Regards Rolf
Bug#817936: roger-router: Please add libpeas-1.0-0-python2loader to Depends
On 13.05.2016 08:51, Rolf Leggewie wrote: > Hello Barry, > > so, libpeas-1.0-0-python2loader has officially made it into Debian. I'm > now thinking how to deal with that for roger. > > On 03.04.2016 05:35, Barry Warsaw wrote: >> On Apr 02, 2016, at 10:33 PM, Rolf Leggewie wrote: >> >> Hi Rolf, >> >>> I'm still at a loss what it is you are asking of me. The title of this >>> bug requests me to add a run-time dependency that doesn't even exist in >>> Debian yet. In Ubuntu the change you advocate has been made, but >>> apparently there were no changes necessary for roger-router alongside. >>> In fact, roger-router in Ubuntu still depends on libpeas-1.0.0 and not >>> libpeas-1.0-0-python2loader even though the package does exist there. >> We should certainly fix roger-router in Ubuntu; I'm not sure how I missed >> that >> one over there. I'll file a bug and fix that early next week. > Ubuntu is still unchanged both in Xenial and Yakkety. > > The title of this ticket suggests I should add an explicit dependency on > libpeas-1.0-0-python2loader to Depends. I'm a bit reluctant to do that > since it would mean I need to maintain a fork since my main computer is > trusty. In any case, roger does not ship any python code at all. My > understanding is that it uses peas to allow third party plugins and > those could be written in python or other programming languages. I'm > actually not aware of any plugins and they could be written in either > python 2 or python 3. Adding a strong dependency to the python 2 loader > seems wrong to me. I feel like adding a Suggests for > "libpeas-1.0-0-python2loader|libpeas-1.0-0-python3loader" would be more > appropriate. Or should I be mistaken? If it really needs to be a > Depends wouldn't it be better to have debhelper and dh_shlibs take care > of doing the right thing? After further inspection of the peas packages in testing and unstable I have now learned that the new libpeas-1.0-0 includes what I thought was going to be carved out into libpeas-1.0-0-python3loader. Barry, I think that adding "libpeas-1.0-python2loader | libpeas-1.0-0 (<< 1.16.0-1ubuntu1)" to Depends for libroutermanager0 (all other roger binary packages depend on this one directly or indirectly) would fix this ticket as well as allow me to build from the same code base for trusty. Seeing that libpeas-1.0-0-python3loader was indeed added to Xenial (and Yakkety, so far, for that matter), I think that depending on "libpeas-1.0-python2loader | libpeas-1.0-0 (<< 1.16.0-1ubuntu1), libpeas-1.0-0 (>= 1.18.0-2) | libpeas-1.0-python3loader" would be needed to support all of trusty, xenial and unstable from the same roger code base. This assumes that Ubuntu will later during the Yakkety cycle go back to syncing libpeas from unstable and thus drop libpeas-1.0-python3loader. It would be appreciated if you confirmed this change for roger.
Bug#824152: ITP: ofxstatement -- Tool to convert proprietary bank statement to OFX format, suitable for importing to GnuCash.
Le vendredi 13 mai 2016, 01:18:03 Alexander GQ Gerasiov a écrit : > Package: wnpp > Severity: wishlist > Owner: Alexander GQ Gerasiov > > * Package name: ofxstatement > Version : 0.5.0 > Upstream Author : Andrey Lebedev > * URL : https://github.com/kedder/ofxstatement > * License : GPL > Programming Lang: Python > Description : Tool to convert proprietary bank statement to OFX format, > suitable for importing to GnuCash. > Hi, Do you also plan to ship all the 19 known plugins in the same package ? https://github.com/kedder/ofxstatement#known-plugins I'd personally use this one, but ITP'ing an extra package for only 70 lines of code doesn't seem like the right thing to do. https://github.com/TheoMarescaux/ofxstatement-be-ing/blob/master/src/ofxstatement/plugins/ingbe.py Greets, Alexandre
Bug#817936: roger-router: Please add libpeas-1.0-0-python2loader to Depends
On 13.05.2016 11:22, Rolf Leggewie wrote: > I think that depending on > "libpeas-1.0-python2loader | libpeas-1.0-0 (<< 1.16.0-1ubuntu1), > libpeas-1.0-0 (>= 1.18.0-2) | libpeas-1.0-python3loader" would be needed > to support all of trusty, xenial and unstable from the same roger code > base. Actually, that would need to be "libpeas-1.0-python2loader | libpeas-1.0-0 (<< 1.16.0-1ubuntu1), libpeas-1.0-0 (>= 1.18.0-2) | libpeas-1.0-0 (<< 1.16.0-1ubuntu1) | libpeas-1.0-python3loader" Puh, quite involved, but I think the above should cover all cases. It would be nice if Ubuntu merged libpeas-1.0-python3loader into libpeas-1.0-0 for Xenial LTS. Do you think such a thing has a chance to be SRU'd?
Bug#785696: 3.28 package
I have a working build for 3.28. I'm mostly an Arch Linux guy, so debuild is a bit new to me. If anybody would like to spend a couple hours cleaning things up, we could get this pushed upstream. Let me know, I can upload my dir somewhere if anyone has the time. Cheers -- adam eberlin +1 312 725 2757
Bug#620391: marked as done (scim keeps crashing)
Hi Rolf, Rolf Leggewie writes: > Benda, it would have been helpful if the closing mail had included a > mentioning of the missing information that had been requested from > Michal and without which there isn't anything we can do. Thanks for pointing this out. Will do next time. Cheers, Benda
Bug#812327: [Pkg-xen-devel] Bug#812327: xen: initrd booting with xen don't find any harddisks
Did you guys every find a solution for this?? Cheers, Thomas
Bug#824137: texlive-fonts-extra-doc: trying to overwrite '/usr/share/doc/texlive-doc/latex/mweights/README' from texlive-latex-extra-doc 2015.20160320-1
tag 824137 + pending thanks > dpkg: error processing archive > /var/cache/apt/archives/texlive-fonts-extra-doc_2016.20160512-1_all.deb > (--unpack): > trying to overwrite '/usr/share/doc/texlive-doc/latex/mweights/README', > which is also in package texlive-latex-extra-doc 2015.20160320-1 Indeed, thanks for the report, fixed in git for the next upload. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#824130: ITP: libgames-support -- Useful functionality shared among GNOME games
On Fri, 2016-05-13 at 09:39 +0800, Paul Wise wrote: > Is your reasoning here that renaming would be additional work and you > don't want to impose that work on downstreams? Basically yes. I don't really consider a name change to be imposing on downstreams, though, as I don't expect downstreams that have already packaged it would change their package names. But it is definitely an annoyance. I don't think putting gtk3 in the name is a great idea, since libgames- support will probably switch to GTK+ 4 eventually. Michael
Bug#482999: The behavior of `jobs -p` is definitely, without a doubt, a bug
Package: dash Version: build-from-git-HEAD--http://git.kernel.org/cgit/utils/dash/dash Severity: serious X-Debbugs-CC: herb...@gondor.apana.org.au --- To Whom It May Concern: I wrote most of this before I read through the Debian bug report process. I'm actually not sure whether this is supposed to go to Debian or to the kernel.org address; So I apologize if some of it is redundant or sounds a bit weird; I assumed I'd be "creating a new thread", so I refer to this thread as "that thread", etc. If I've made any other errors, again apologizes in advance; it's the first time I've worked with the Debian process, and I'm using dash on another platform, so I don't have access to "reportbug", etc. Also, if I come off a bit pissy, petulant, pedantic, or arrogant, it's only because I have so many, many times *been* "that guy" -- someone who takes the time and goes out of his way to write and file a bug report and send it through the proper channels -- only have it basically dismissed out of hand. So when I found myself in the position of not only reporting a bug, but having to refute the incorrect arguments made that led to the bug report being dismissed, and thinking about how this could have been fixed 8 years ago, it did irk me. So yes, I was a bit peeved as I wrote it, it is absolutely nothing personal (except in that it's some of my own emotional baggage). So, once again, apologies, I truly mean no disrespect. --- So I thought I was going to be reporting a "new" bug today. But it turns out, this came up way back in 2008: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482999 At at the time, the curt response and resolution seemed to be all of "no", and "you should just use $!". So I guess rather than a "bug report" per se, this is a vociferous argument questioning that conclusion, and a request that it be reconsidered. To me, this is definitely, absolutely, positively a bug. --- Let me start with a couple of corrections to that previous thread. 1. The line: jobs -p > /tmp/pids # this works Does *not*, in fact, work. Meaning there is *no* instance in which it works. Now (8 years later), to the assertions made in that thread. 2. This response: > Hi, I don't think that's a bug, the jobs builtin 'shall display the > status of jobs that were started in the current shell environment;'[0] > > When running jobs in a subshell, you change the shell environment for > the jobs builtin. > > Regards, Gerrit. > > [0] http://www.opengroup.org/onlinepubs/009695399/utilities/jobs.html Is just flat incorrect. In fact, it is almost the complete opposite of what the standard says. Perhaps we should refer back to (I'm intentionally using Issue 6 here, since that was the standard at the time of the original discussion, but nothing of relevance differs in Issue 7) http://pubs.opengroup.org/onlinepubs/009604499/utilities/xcu_chap02.html, "Shell Command Lanuage", in particular (all emphasis mine): 2.12. Shell Execution Environment - ... *The environment of the shell process shall not be changed by the utility unless explicitly specified by the utility description* (for example, cd and umask). A subshell environment *shall be created as a duplicate of the shell environment*, except that signal traps that are not being ignored shall be set to the default action. Changes made to the subshell environment shall not affect the shell environment. *Command substitution*, commands that are grouped with parentheses, and *asynchronous lists* shall be executed in a subshell environment. and 2.9.3 Lists --- ... Asynchronous Lists If a command is terminated by the control operator ampersand ( '&' ), the shell shall execute the command asynchronously in a subshell. ... When an element of an asynchronous list (the portion of the list ended by an ampersand ...), is started by the shell, the process ID of the last command in the asynchronous list element shall become known in the current shell execution environment; see Shell Execution Environment. In review, a subshell inherits a duplicate of the parent environment, which includes the asynchronous list of background tasks, and the shell environment is *explicitly* not to be changed, unless otherwise specified. Which it is not. Basically: `(this)`, `$(this)`, `this &`, a few other cases, are subshells. They inherit the environment of the parent shell. The other interpretation given describes something like that which occurs with an invocation of `sh -c '...'`, which is not the case here. 3. But let us return to the specification for "jobs". Since subshells are really not even the issue here at all. Indeed, the specification does says it 'shall display the status of jobs that were started in the current shell environment' as quoted. In the description, but if you read a bit futher, it goe
Bug#817936: roger-router: Please add libpeas-1.0-0-python2loader to Depends
Hello Barry, so, libpeas-1.0-0-python2loader has officially made it into Debian. I'm now thinking how to deal with that for roger. On 03.04.2016 05:35, Barry Warsaw wrote: > On Apr 02, 2016, at 10:33 PM, Rolf Leggewie wrote: > > Hi Rolf, > >> I'm still at a loss what it is you are asking of me. The title of this >> bug requests me to add a run-time dependency that doesn't even exist in >> Debian yet. In Ubuntu the change you advocate has been made, but >> apparently there were no changes necessary for roger-router alongside. >> In fact, roger-router in Ubuntu still depends on libpeas-1.0.0 and not >> libpeas-1.0-0-python2loader even though the package does exist there. > We should certainly fix roger-router in Ubuntu; I'm not sure how I missed that > one over there. I'll file a bug and fix that early next week. Ubuntu is still unchanged both in Xenial and Yakkety. The title of this ticket suggests I should add an explicit dependency on libpeas-1.0-0-python2loader to Depends. I'm a bit reluctant to do that since it would mean I need to maintain a fork since my main computer is trusty. In any case, roger does not ship any python code at all. My understanding is that it uses peas to allow third party plugins and those could be written in python or other programming languages. I'm actually not aware of any plugins and they could be written in either python 2 or python 3. Adding a strong dependency to the python 2 loader seems wrong to me. I feel like adding a Suggests for "libpeas-1.0-0-python2loader|libpeas-1.0-0-python3loader" would be more appropriate. Or should I be mistaken? If it really needs to be a Depends wouldn't it be better to have debhelper and dh_shlibs take care of doing the right thing? Regards Rolf
Bug#798053: Bug#824079: qgis: FTBFS on non-Linux: 'TCGETS' was not declared in this scope
Sebastiaan Couwenberg writes: > Adding " || defined(__FreeBSD_kernel__)" to the #elif statements in > kpty.cpp should be sufficient to not need the CMakeLists.txt changes. Indeed, that approach (my initial suggestion in #798053) also works, Alf Gaida's opening comment in https://github.com/lxde/qtermwidget/issues/50 notwithstanding. For that matter, so does simply testing whether TIOCGETA and TIOCSETA are defined -- although they're not technically required to be macros, they are in practice. -- 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#824130: ITP: libgames-support -- Useful functionality shared among GNOME games
On Thu, 2016-05-12 at 12:04 -0500, Michael Catanzaro wrote: > Hm, in retrospect, I absolutely agree with Paul, libgnome-games-support > or libgnome-games would indeed have been better names. I don't want to > change it at this point, though, because it's been packaged by several > other distros (Fedora, openSUSE, Arch) for roughly a year now, all of > which chose to name the package libgames-support. I'd prefer to keep > the upstream name in sync with these downstreams, and I think it's > unlikely that another project would want to use this name. Is your reasoning here that renaming would be additional work and you don't want to impose that work on downstreams? In Debian at least the renaming process is a fairly minimal amount of work so I'd be surprised if the same didn't also apply to the other distros. Or is it about the time needed to co-ordinate this change? I expect that would be minimal too, probably a thread of a few emails at worst. > I think it's reasonable for Debian to use a different package name if > it prefers, but do consider the value in matching all the other > distros. Also, although I don't expect non-GNOME games to use the > library, it might be a good option for non-GNOME games that use GTK+ 3. Perhaps libgtk3-games-support would be a better option if you intend it to be more GTK+ 3 oriented than GNOME oriented. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#823187: RFS: icdiff/1.7.3-1
On Thu, 2016-05-12 at 22:37 +0100, Sascha Steinbiss wrote: > Upstream is still unsure how to address this problem properly given > that he wants to retain a specific structure to his code. There have > been a few suggestions and PRs from myself and others, but they are > apparently not quite what upstream is going for. For more information > see https://github.com/jeffkaufman/icdiff/issues/68 and > https://github.com/jeffkaufman/icdiff/pull/79. > For simplicity’s sake in the meantime, I have skipped using > setuptools in the Debian package and just install the single stand- > alone script manually, an option that upstream explicitly wants to > support anyway. I hope that is acceptable for a first upload as it > does’t change much in the installed version — I will re-enable > support for setuptools again of course as soon as upstream has sorted > out these issues. Interesting. Personally if I were upstream I'd drop the curl method and go with pip but I understand it is a simple and thus useful hack. How about this? Rename icdiff to icdiff.py and make it a module. Put a bin/icdiff in the repo that just imports and runs the icdiff module. It can't be icdiff since people who run the same install instructions should get a file not found error instead of confusing import failure when trying to run the script. Add some code to icdiff.py so it can be run on the cmdline too. Update the web page curl install info to point at icdiff.py Have setup.py install bin/icdiff as a script and icdiff.py as a module. > New upload is here: > https://mentors.debian.net/debian/pool/main/i/icdiff/icdiff_1.8.1-1.dsc I'll take a look on the weekend. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#824074: gimp: Crashes (apparently) when Caps Lock key is pressed
Thanks; could you install libgtk2.0-0-dbg and libglib2.0-0-dbg and obtain a new backtrace?
Bug#678951: [Tts-project] Bug#678951: speech-dispatcher user should not have a valid shell
tag 678951 + pending thanks On Sat, Apr 02, 2016 at 10:41:43PM AEDT, Nicolas LE CAM wrote: > Package: speech-dispatcher > Followup-For: Bug #678951 > Control: found > > Dear Maintainer, > > I did saw the same exact problem while checking my passwd file on a fresh > install and was going to report it. > As it was marked resolved I've upgraded to 0.8.3-1/experimental but the > problem persists. > > Looking to the git repo, I saw that the useradd command is only executed if > the user doesn't exists. > Perhaps add a "usermod --shell /bin/false $USER_NAME" in the other case to > fix the problem for everyone. Thanks for the suggestion, added to git, will go in with the next upload. Luke
Bug#824159: vor: manpage tweaks
Package: vor Version: 0.5.6-1 Severity: minor Dear Maintainer, Thanks for writing a man page! I haven't gotten myself to learn how to do that yet. Couple tweaks: 1. Please include the last three letters in my last name 2. Please include the other author: Joshua Grams 3. Please mention the commandline flags: -s -f The -s flag is particularly useful since there's no key to mute. Might be nice to mention the keys too: arrows/numpad, space/p, f, q/esc if only so people won't get frustrated that they can't find the shoot key :) (there is no shooting) -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 4.5.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages vor depends on: ii libc62.22-7 ii libsdl-image1.2 1.2.12-5+b6 ii libsdl-mixer1.2 1.2.12-11+b1 ii libsdl1.2debian 1.2.15+dfsg1-4 vor recommends no packages. vor suggests no packages. -- no debconf information
Bug#806109: [Tts-project] Bug#806109: speech-dispatcher: FTBFS when built with dpkg-buildpackage -A (No such file or directory)
tags 806109 + pending thanks On Mon, May 09, 2016 at 03:34:54AM AEST, Santiago Vila wrote: > Explanation: We are creating arch-independent packages only, so > debian/speech-dispatcher/[...] does not exist because > "speech-dispatcher" is arch-dependent. > > The trivial fix is to override dh_fixperms only for arch-dependent > packages. > > Patch attached. Thanks for the patch, its in git. I don't have upload privileges so will require a DD to take care of it. Luke
Bug#823987: systemd: after upgrading some libs, login takes much longer until systemd-logind is restarted
There were some updates just before,... First I didn't restart any service (via needrestart). Login still succeeded in a timely manner then. Afterwards I restarted dbus.service, and then the issue occurs. So, Michael, your assumption seems to be confirmed. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#824158: allegro5: liballegro5-dev unnecessarily conflicts with liballegro4-dev
Source: allegro5 Severity: normal Hi, The liballegro5-dev package conflicts with liballegro4-dev, which as far as we can tell is not needed. The packages do not have any files of the same name, and the upstream developers have the intention of keeping the two libraries separately namespaced and not conflicting. The closest thing to a conflict is Allegro 4 providing liballeg.so, and Allegro 5 providing the similarly names liballegro.so. All other files are clearly separate (e.g. /usr/include/allegro/ vs /usr/include/allegro5/). It would be great if the conflict could be removed to allow developers to work on both Allegro 4 and Allegro 5 projects on the same system. I've made a mirror report on allegro4.4 as the conflict is specified both ways. Thanks, Julian Smythe
Bug#824157: allegro4.4: liballegro4-dev unnecessarily conflicts with liballegro5-dev
Source: allegro4.4 Severity: normal Hi, The liballegro4-dev package conflicts with liballegro5-dev, which as far as we can tell is not needed. The packages do not have any files of the same name, and the upstream developers have the intention of keeping the two libraries separately namespaced and not conflicting. The closest thing to a conflict is Allegro 4 providing liballeg.so, and Allegro 5 providing the similarly names liballegro.so. All other files are clearly separate (e.g. /usr/include/allegro/ vs /usr/include/allegro5/). It would be great if the conflict could be removed to allow developers to work on both Allegro 4 and Allegro 5 projects on the same system. I'll make a mirror report on allegro5 as the conflict is specified both ways. Thanks, Julian Smythe
Bug#821484: freedombox-setup: PHP 7.0 Transition
On Wed, 11 May 2016 20:20:05 +0530 Sunil Mohan Adapa wrote: > Attached is patch I prepared as discussed. This patch to the postinst > script will disable php5 and enable php7.0 module. This rule is applied > when upgrading from version less than or equal to 0.9. It is not > applied when doing a fresh install. I've applied this patch. signature.asc Description: OpenPGP digital signature
Bug#824156: vor: Segfaults on startup if you have a high score file
Package: vor Version: 0.5.6-1 Severity: important Dear Maintainer, Firstly, I'm so excited that this package has a new maintainer. Thanks for stepping up! It seems that the patch you added (01-string-formatting.diff) makes the game segfault immediately on startup if you have a high score file. This is the change/line that's problematic: fscanf(f, "%s", titles[j]); I think this says to read a string into titles[j] but titles[j] is not writeable, it's two string constants. The original code (before your patch) does the correct thing: it scans (not saving the characters anywhere) past the title of the score file section. The other change introduced by this patch looks harmless enough, though unnecessary, since titles[] are static strings that don't have percents in them. I'm attaching a score file, to save you the trouble of surviving for 31 seconds and entering your name. To reproduce: 1. rename this attachment to ~/.vor-scores, or don't do that, and survive for over 30 seconds, and enter your name into the high score list, and quit. 2. run the game Result: segfault Thanks! -- Jason -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 4.5.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages vor depends on: ii libc62.22-7 ii libsdl-image1.2 1.2.12-5+b6 ii libsdl-mixer1.2 1.2.12-11+b1 ii libsdl1.2debian 1.2.15+dfsg1-4 vor recommends no packages. vor suggests no packages. -- debconf-show failed Normal 12 - 105000 - 9 - 75000 - 6 - 5 - 4 - 34108 JasonTesting Easy 12 - 105000 - 9 - 75000 - 6 - 5 - 4 - 3 -
Bug#824086: libqwt-qt5-dev: qt creator doesn't load qwt plugin
Package: libqwt-qt5-dev Version: 6.1.2-5 Severity: important Dear Maintainer, I have the package qtcreator 3.6.1-1 installed. I wanted to use qwt, so installed libqwt-qt5-dev 6.1.2-5. Since this package is for use with qt5, I expected qt creator to be able to load the plugin and show the various qwt widgets that are available. However qt creator doesn't seem to recognize the plugin. I suspect there some version incompatibilities. Is there a different package that has the qwt plugin for qt creator? -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libqwt-qt5-dev depends on: pn libc6 ii libgcc1 1:6.1.1-1 pn libqt5core5a pn libqt5designer5 pn libqt5gui5 pn libqt5widgets5 ii libqwt-headers 6.1.2-5 ii libqwt-qt5-6 6.1.2-5 ii libstdc++6 6.1.1-1 libqwt-qt5-dev recommends no packages. libqwt-qt5-dev suggests no packages. -- no debconf information
Bug#824155: RFP: iotivity -- Seamless device-to-device connectivity IoT framework
Package: wnpp Severity: wishlist * Package name: iotivity Version : 1.1.0 Upstream Author : Open Connectivity Foundation * URL : http://iotivity.org * License : Apache-2.0 Programming Lang: C++ Description : Seamless device-to-device connectivity IoT framework An open source reference implementation of the OCF standard specifications IoTivity Base Libraries are included. Status : I started to package a Quick and Dirty version, and it is building on Ubuntu PPA (x86) https://github.com/rzr/iotivity/commits/debian Now To move on, I'd like to find a team that could share the effort. Can you suggest one who is experienced with scons build system ? https://wiki.debian.org/Teams If none I will probably use pkg-collab-maint. I might switch this bug to ITP, unless a scons wizard wants to take of it his own. Sponsorship will be also welcome. For updates check : https://wiki.iotivity.org/community Regards
Bug#823184: umount mounts /proc as a side effect
reassign 823184 libselinux1 2.5-1 affects 823184 mount thanks On Sun, 1 May 2016 23:06:54 +0200 Yuri D'Elia wrote: > > Amusing, right? But not too much. > > It does actually happen due to a new behavior in libselinux, which mount links against. > The same is true for any binary in util-linux and coreutils (and so on) > > See bug #822679 > > I consider this behavior unexpected. > [and yes, I'm doing this to raise some awareness. Close the report if needed] libselinux mounts /proc, check is the machine supports SELinux and then unmounts it. This is supposed to happen at early boot. I would be interested to know what this behavior is breaking. As I said on the other bugreport, please bring this upstream if you want this to change. Laurent Bigonville
Bug#824154: mupen64plus-qt: Crash when useing: File → Open ROM directly after clicking
Package: mupen64plus-qt Version: 1.8-2 Severity: normal Dear Maintainer, I freshly installed mupen64plus-qt but I am unable to open a ROM file. I start mupen64plus-qt via my console. Directly after clicking File → Open ROM... in the menu the programm ended with following message: zsh: segmentation fault mupen64plus-qt I started gdb and got the following backtrace: Program received signal SIGSEGV, Segmentation fault. 0x76cddc6a in QUrl::fromLocalFile(QString const&) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 (gdb) bt #0 0x76cddc6a in QUrl::fromLocalFile(QString const&) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #1 0x7788479e in QFileDialog::getOpenFileName(QWidget*, QString const&, QString const&, QString const&, QString*, QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #2 0x004162ea in ?? () #3 0x0045980d in ?? () #4 0x76db2f8a in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7766d3b2 in QAction::triggered(bool) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #6 0x7766f838 in QAction::activate(QAction::ActionEvent) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #7 0x777f1cd2 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #8 0x777f7f6c in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #9 0x777fbee0 in QMenu::mouseReleaseEvent(QMouseEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #10 0x776b9f28 in QWidget::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #11 0x777fc933 in QMenu::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #12 0x77676ffc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #13 0x7767cbb9 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #14 0x76d845ab in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #15 0x7767bad2 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #16 0x776d47dd in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #17 0x776d6a3b in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #18 0x77676ffc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #19 0x7767c4b6 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #20 0x76d845ab in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #21 0x770c6171 in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 #22 0x770c7e35 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 #23 0x770abe68 in QWindowSystemInterface::sendWindowSystemEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 #24 0x7fffee8fe0b0 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #25 0x755741a7 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #26 0x75574400 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #27 0x755744ac in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #28 0x76ddaa3f in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #29 0x76d81d6a in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #30 0x76d89e0c in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #31 0x004102ea in ?? () #32 0x761e45f0 in __libc_start_main (main=0x40ff50, argc=1, argv=0x7fffe068, init=, fini=, rtld_fini=, stack_end=0x7fffe058) at libc-start.c:291 #33 0x00410af9 in ?? () Regards Kevin -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mupen64plus-qt depends on: ii libc6 2.22-9 ii libgcc1 1:6.1.1-3 ii libqt5core5a5.5.1+dfsg-16+b1 ii libqt5gui5 5.5.1+dfsg-16+b1 ii libqt5network5 5.5.1+dfsg-16+b1 ii libqt5sql5 5.5.1+dfsg-16+b1 ii libqt5widgets5 5.5.1+dfsg-16+b1 ii libqt5xml5
Bug#824042: [Pkg-clamav-devel] Bug#824042: gets into kill/restart loop
On 12 May 2016 at 19:43, Felipe Sateler wrote: > On 12 May 2016 at 18:55, Sebastian Andrzej Siewior > wrote: >> On 2016-05-11 12:12:42 [-0400], Joey Hess wrote: >>> Looks like it was being killed each time by the OOM killer. Which makes >>> sense; clamav uses 18% of the system's 2 gb of ram and so will be the >>> top target. >>> >>> I think there should be something to prevent this runaway scenario. >>> Maybe a delay, or maybe avoid restarting repeatedly. >>> >>> May 8 13:58:14 kite kernel: [12577316.169029] Out of memory: Kill >>> process 14646 (clamd) score 115 or sacrifice child >>> May 8 13:58:14 kite kernel: [12577316.169043] Killed process 14646 >>> (clamd) total-vm:425680kB, anon-rss:264680kB, file-rss:0kB >>> May 8 13:58:29 kite kernel: [12577330.925647] Out of memory: Kill >>> process 14662 (clamd) score 115 or sacrifice child >>> May 8 13:58:29 kite kernel: [12577330.925663] Killed process 14662 >>> (clamd) total-vm:425936kB, anon-rss:264684kB, file-rss:12kB >> >> This does not look like multiple times per seond. >> If I 'kill -9 `pidif clamd`' then it does not come back. The service >> file does not say to restart it: >> >> |systemctl show clamav-daemon.service | grep Restart >> |Restart=no >> |RestartUSec=100ms >> >> So it remains offs. However we have socket activation for clamd. So >> assuming that you have a mailserver poking at the socket then it will >> bring clamd back from the death. >> >> I have no idea how to limit / disable the restart or make it >> configurable in this case. Maybe someone with systemfoo has an idea :) > > This functionality will come with systemd 230: > https://github.com/systemd/systemd/pull/3148 , so nothing out of the > box yet. > > A more involved solution (but working right now) would be to have > OnFailure=clamav-failed.service and have clamav-failed.service stop > the socket. For clarification: this would stop the socket only on failure. A simpler solution that would stop the socket always would be to have ExecStopPost=/bin/systemctl --no-block stop clamav-daemon.socket On the service. If clamav-daemon never exits on its own, then this might be a better solution -- Saludos, Felipe Sateler
Bug#824042: [Pkg-clamav-devel] Bug#824042: gets into kill/restart loop
On 12 May 2016 at 18:55, Sebastian Andrzej Siewior wrote: > On 2016-05-11 12:12:42 [-0400], Joey Hess wrote: >> Looks like it was being killed each time by the OOM killer. Which makes >> sense; clamav uses 18% of the system's 2 gb of ram and so will be the >> top target. >> >> I think there should be something to prevent this runaway scenario. >> Maybe a delay, or maybe avoid restarting repeatedly. >> >> May 8 13:58:14 kite kernel: [12577316.169029] Out of memory: Kill >> process 14646 (clamd) score 115 or sacrifice child >> May 8 13:58:14 kite kernel: [12577316.169043] Killed process 14646 >> (clamd) total-vm:425680kB, anon-rss:264680kB, file-rss:0kB >> May 8 13:58:29 kite kernel: [12577330.925647] Out of memory: Kill >> process 14662 (clamd) score 115 or sacrifice child >> May 8 13:58:29 kite kernel: [12577330.925663] Killed process 14662 >> (clamd) total-vm:425936kB, anon-rss:264684kB, file-rss:12kB > > This does not look like multiple times per seond. > If I 'kill -9 `pidif clamd`' then it does not come back. The service > file does not say to restart it: > > |systemctl show clamav-daemon.service | grep Restart > |Restart=no > |RestartUSec=100ms > > So it remains offs. However we have socket activation for clamd. So > assuming that you have a mailserver poking at the socket then it will > bring clamd back from the death. > > I have no idea how to limit / disable the restart or make it > configurable in this case. Maybe someone with systemfoo has an idea :) This functionality will come with systemd 230: https://github.com/systemd/systemd/pull/3148 , so nothing out of the box yet. A more involved solution (but working right now) would be to have OnFailure=clamav-failed.service and have clamav-failed.service stop the socket. -- Saludos, Felipe Sateler
Bug#824153: 08_hlogin_paging.patch breaks all (?) ProCurve logins
Package: rancid Version: 3.4.1-3 Severity: grave Hi, Since upgrading to 3.4.x (from an upstream 2.3.9), HP ProCurve logins have been completely broken for me. It turns out 08_hlogin_paging.patch breaks this; it makes hlogin send “no page\r” and then wait for first a partial prompt (the switch's name alone) and then a full prompt (the switch's name followed by [#>]) without sending any commands in-between. Example session: rancid@pannekake:~$ /usr/lib/rancid/bin/hlogin -t 90 -c "show version;show flash" james.wlan.samfundet.no < /dev/null james.wlan.samfundet.no spawn hpuifilter -- ssh -c 3des-cbc -x -l admin james.wlan.samfundet.no ad...@james.wlan.samfundet.no's password: ProCurve J9087A Switch 2610-24-PWR Software revision R.11.112 Copyright (C) 1991-2015 Hewlett-Packard Co. All Rights Reserved. RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subdivision (b) (3) (ii) of the Rights in Technical Data and Computer Software clause at 52.227-7013. HEWLETT-PACKARD COMPANY, 3000 Hanover St., Palo Alto, CA 94303 Press any key to continuejames# james# no page james# Error: TIMEOUT reached Looking at the code, I doubt it works in any ProCurve device; I've tested it on 2650, 2824, 2840 and 2610, and it works on neither. (Thus the RC severity; if it breaks all of HP, it's pretty bad.) My guess is that the patch got borked in a merge at some point, because the patch in 2.3.8-6 seems good in comparison (it has a send "terminal length 0\r" that is now lost). -- System Information: Debian Release: 8.4 APT prefers stable APT policy: (750, 'stable'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0 (SMP w/40 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages rancid depends on: ii adduser 3.113+nmu3 ii cvs 2:1.12.13+real-15 ii debconf [debconf-2.0] 1.5.56 ii expect 5.45-6 ii git 1:2.8.0~rc3+next.20160316-1 ii iputils-ping [ping] 3:20121221-5+b2 ii libc6 2.19-18+deb8u4 ii libperl4-corelibs-perl 0.003-1 ii openssh-client 1:6.7p1-5+deb8u2 ii passwd 1:4.2-3+deb8u1 ii perl5.20.2-3+deb8u4 ii ssh 1:6.7p1-5+deb8u2 rancid recommends no packages. Versions of packages rancid suggests: ii diffstat 1.58-1 -- Configuration Files: /etc/rancid/rancid.conf changed [not included] -- debconf information: * rancid/warning: * rancid/go_on: true
Bug#824149: smartmontools: curl's --location option should be used in update-smart-drivedb
On Fri, 13 May 2016 00:00:40 +0200 Christoph Anton Mitterer wrote: > On Fri, 2016-05-13 at 00:54 +0300, Mert Dirik wrote: > > update-smart-drivedb > > Has been dropped in 6.4+svn4214-1, amongst others for security reasons. > Sorry to hear that, it was a nice feature. Manual updates will still work, right?
Bug#824152: ITP: ofxstatement -- Tool to convert proprietary bank statement to OFX format, suitable for importing to GnuCash.
Package: wnpp Severity: wishlist Owner: Alexander GQ Gerasiov * Package name: ofxstatement Version : 0.5.0 Upstream Author : Andrey Lebedev * URL : https://github.com/kedder/ofxstatement * License : GPL Programming Lang: Python Description : Tool to convert proprietary bank statement to OFX format, suitable for importing to GnuCash. Most internet banking systems are capable of exporting account transactions to some sort of computer readable formats, but few supports standard data formats, like OFX. On the other hand, personal accounting tools, such as GnuCash support standard formats only, and will probably never support proprietary statement formats of online banking systems. To bridge the gap between them, ofxstatement tool was created.
Bug#824151: autotrash: No upstream release
Package: autotrash Version: autotrash Severity: normal Tags: upstream New upstream release available since 06.12.2015: https://github.com/bneijt/autotrash -- System Information: Debian Release: 8.0 APT prefers experimental APT policy: (200, 'experimental'), (200, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-rc3-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#824150: Please package latest upstream release 0.8.0
Source: librest Version: 0.7.93-1 Severity: wishlist Hi, there is a new upstream release 0.8.0 available at [1] which is part of the GNOME 3.20 stack [2]. Would be great if you can update the package accordingly. Thanks a lot for maintaining librest. Michael [1] https://download.gnome.org/sources/rest/0.8/rest-0.8.0.tar.xz [2] https://www.0d.be/debian/debian-gnome-3.20-status.html -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#790385: [Pkg-zfsonlinux-devel] Bug#790385: initramfs-tools: breaks building initramfs for zfs over (mirrored) LUKS - "can't find root device"
On May 12, 2016, at 10:40 PM, Petter Reinholdtsen wrote: > As zfs-linux finally entered unstable yesterday, I guess it is > time to look at this issue again. I'm pretty sure it's fixed in one of my PRs that haven't been accepted. I've seen this issue on the ZoL trackers, but I can't remember if we got confirmation. I include a patch for that in my ZoL packages. https://github.com/zfsonlinux/pkg-zfs/tree/master/debian/wheezy/debian/patches Now that ZFS have finally been accepted, we need to find a way to merge my packages with the official Debian GNU/Linux ones. And the Ubuntu ones. My suggestion have been to include the debian directory into upstream spl/zfs directly. With a little glue, we should be able to provide ONE directory that works on everything. My packages all work on Wheezy, Jessie, Sid as well as a few Ubuntu versions.
Bug#824149: smartmontools: curl's --location option should be used in update-smart-drivedb
On Fri, 2016-05-13 at 00:54 +0300, Mert Dirik wrote: > update-smart-drivedb Has been dropped in 6.4+svn4214-1, amongst others for security reasons. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#824042: [Pkg-clamav-devel] Bug#824042: gets into kill/restart loop
On 2016-05-11 12:12:42 [-0400], Joey Hess wrote: > Looks like it was being killed each time by the OOM killer. Which makes > sense; clamav uses 18% of the system's 2 gb of ram and so will be the > top target. > > I think there should be something to prevent this runaway scenario. > Maybe a delay, or maybe avoid restarting repeatedly. > > May 8 13:58:14 kite kernel: [12577316.169029] Out of memory: Kill > process 14646 (clamd) score 115 or sacrifice child > May 8 13:58:14 kite kernel: [12577316.169043] Killed process 14646 > (clamd) total-vm:425680kB, anon-rss:264680kB, file-rss:0kB > May 8 13:58:29 kite kernel: [12577330.925647] Out of memory: Kill > process 14662 (clamd) score 115 or sacrifice child > May 8 13:58:29 kite kernel: [12577330.925663] Killed process 14662 > (clamd) total-vm:425936kB, anon-rss:264684kB, file-rss:12kB This does not look like multiple times per seond. If I 'kill -9 `pidif clamd`' then it does not come back. The service file does not say to restart it: |systemctl show clamav-daemon.service | grep Restart |Restart=no |RestartUSec=100ms So it remains offs. However we have socket activation for clamd. So assuming that you have a mailserver poking at the socket then it will bring clamd back from the death. I have no idea how to limit / disable the restart or make it configurable in this case. Maybe someone with systemfoo has an idea :) Sebastian
Bug#824143: Pending fixes for bugs in the libperinci-sub-normalize-perl package
tag 824143 + pending thanks Some bugs in the libperinci-sub-normalize-perl package are closed in revision ea647e922f7466d5e352a5e99841e595843c9f59 in branch 'master' by gregor herrmann The full diff can be seen at https://anonscm.debian.org/cgit/pkg-perl/packages/libperinci-sub-normalize-perl.git/commit/?id=ea647e9 Commit message: Bump (build) dependency on librinci-perl to 1.1.80-1. Closes: #824143
Bug#824149: smartmontools: curl's --location option should be used in update-smart-drivedb
Package: smartmontools
Version: 6.3+svn4002-2+b2
Severity: normal
Update page has been moved and now update-smart-drivedb command fails
when curl is installed on the system.
$ which curl
/usr/bin/curl
$ sudo update-smart-drivedb
/var/lib/smartmontools/drivedb/drivedb.h.error: rejected by /usr/sbin/smartctl,
probably no longer compatible
$ cat /var/lib/smartmontools/drivedb/drivedb.h.error
302 Found
302 Found
The resource was found at https://sourceforge.net/p/smartmontools/code/HEAD/tree/branches/RELEASE_6_4_DRIVEDB/smartmontools/drivedb.h?format=raw";>https://sourceforge.net/p/smartmontools/code/HEAD/tree/branches/RELEASE_6_4_DRIVEDB/smartmontools/drivedb.h?format=raw;
you should be redirected automatically.
After adding -L option to curl command in update-smart-drivedb:
$ diff -u /usr/sbin/update-smart-drivedb{,.org}
--- /usr/sbin/update-smart-drivedb 2016-05-13 00:42:15.831879006 +0300
+++ /usr/sbin/update-smart-drivedb.org 2016-05-13 00:41:26.215632972 +0300
@@ -77,7 +77,7 @@
for t in $os_dltools; do
if which $t >/dev/null 2>/dev/null; then
case $t in
- curl) DOWNLOAD="curl ${q:+-s }"'-L -f -o "$DEST.new" "$SRC"' ;;
+ curl) DOWNLOAD="curl ${q:+-s }"'-f -o "$DEST.new" "$SRC"' ;;
lynx) DOWNLOAD='lynx -source "$SRC" >"$DEST.new"' ;;
wget) DOWNLOAD="wget $q"'-O "$DEST.new" "$SRC"' ;;
fetch) DOWNLOAD='fetch -o "$DEST.new" "$SRC"' ;; # FreeBSD
$ sudo update-smart-drivedb
/var/lib/smartmontools/drivedb/drivedb.h updated from
branches/RELEASE_6_4_DRIVEDB
$ fgrep '$Id' /var/lib/smartmontools/drivedb/drivedb.h
{ "$Id: drivedb.h 4317 2016-05-06 20:17:21Z chrfranke $",
-- System Information:
Debian Release: 8.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64, armhf
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages smartmontools depends on:
ii debianutils 4.4+b1
ii init-system-helpers 1.22
ii libc62.19-18+deb8u4
ii libcap-ng0 0.7.4-2
ii libgcc1 1:4.9.2-10
ii libselinux1 2.3-2
ii libstdc++6 4.9.2-10
ii lsb-base 4.1+Debian13+nmu1
Versions of packages smartmontools recommends:
ii heirloom-mailx [mailx] 12.5-4
Versions of packages smartmontools suggests:
pn gsmartcontrol
ii smart-notifier 0.28-5
-- Configuration Files:
/etc/default/smartmontools changed [not included]
/etc/smartd.conf changed [not included]
Bug#823972: denemo: Soundfont path needs to be changed
El 12/05/16 a las 12:24, Dr. Tobias Quathamer escribió: > Am 10.05.2016 um 22:50 schrieb Dhionel Díaz: >> Dear Maintainer, >> >> A fresh install of denemo was not playing sounds because it was >> expecting the soundfonts to be located in /usr/share/denemo/soundfonts. >> With the attached patch the problem is solved changing the soundfont >> path to /usr/share/sounds/sf2. I hope it can be useful. > > Hi Dhionel, > > thanks a lot for spotting this and reporting the bug with a patch. I've > just applied it and prepare a new release. > > Unfortunately, denemo will be removed from testing by the end of May, > because lilypond gets removed. This is because of an old and unsupported > guile. However, the current stable version of lilypond does not work > with the current version of guile. > > See https://bugs.debian.org/746005 for more information. > > Regards, > Tobias > > Glad to help. I hope the migration to guile 2.x can be successfully completed as soon as possible. Regards, -- Dhionel Díaz Centro Nacional de Desarrollo e Investigación en Tecnologías Libres Ministerio del Poder Popular para Educación Universitaria, Ciencia y Tecnología signature.asc Description: OpenPGP digital signature
Bug#790385: initramfs-tools: breaks building initramfs for zfs over (mirrored) LUKS - "can't find root device"
[Ben Hutchings] > So far as I know, booting from zfs has never been supported in > initramfs-tools. It would in any case require some support from one of > the zfs packages. As zfs-linux finally entered unstable yesterday, I guess it is time to look at this issue again. Is this still a problem with the packages in unstable? What exactly is needed to reproduce it? Should booting from zfs work, or is there something out of reach on Linux at the moment? -- Happy hacking Petter Reinholdtsen
Bug#823187: RFS: icdiff/1.7.3-1
Hi Paul, some quick news regarding icdiff... […] >>> AFAICS icdiff is currently compatible with both Python 2 and Python 3. >> >> Excellent. In case upstream doesn't want to switch to using Python 3 in >> the script, I would recommend the Debian version do that. > > OK, I have already done that in my version here and will push it with the > next upload. Done. >>> Please let me know what you think. >> >> How about packaging 1.8.1 and then I'll upload it? > > 1.8.1 currently FTBFS due to a setuptools-related change that was also > introduced in this version. Currently discussing this with upstream to > sort it out. I will ping the list again if there has been progress. Upstream is still unsure how to address this problem properly given that he wants to retain a specific structure to his code. There have been a few suggestions and PRs from myself and others, but they are apparently not quite what upstream is going for. For more information see https://github.com/jeffkaufman/icdiff/issues/68 and https://github.com/jeffkaufman/icdiff/pull/79. For simplicity’s sake in the meantime, I have skipped using setuptools in the Debian package and just install the single stand-alone script manually, an option that upstream explicitly wants to support anyway. I hope that is acceptable for a first upload as it does’t change much in the installed version — I will re-enable support for setuptools again of course as soon as upstream has sorted out these issues. New upload is here: https://mentors.debian.net/debian/pool/main/i/icdiff/icdiff_1.8.1-1.dsc Cheers Sascha
Bug#824148: RM: php5-symfony-debug -- NBS; cruft
Package: ftp.debian.org Severity: normal Hi, The last symfony uploads got rid of php5-symfony-debug (arch:any), so only arch:all packages are build now. Version 2.8.4+dfsg-1 [3.0.4+dfsg-1 in experimental] of php5-symfony-debug seems to prevent version 2.8.6+dfsg-1 [3.0.6+dfsg-1 in experimental] of php-symfony* packages to be available in the archive, and also prevents symfony to migrate into testing. Thanks in advance for your prompt action: version 2.8.6+dfsg-1 [3.0.6+dfsg-1 in experimental] contains security fixes. Regards David signature.asc Description: PGP signature
Bug#824146: Pending fixes for bugs in the libdatetime-event-sunrise-perl package
tag 824146 + pending thanks Some bugs in the libdatetime-event-sunrise-perl package are closed in revision 5f557469e9879cd3101ded2d4ecdb1c6d01006ff in branch 'master' by gregor herrmann The full diff can be seen at https://anonscm.debian.org/cgit/pkg-perl/packages/libdatetime-event-sunrise-perl.git/commit/?id=5f55746 Commit message: Fix typo in short description. Thanks: Alberto Luaces for the bug report. Closes: #824146
Bug#824147: RM: php5-twig -- NBS; cruft
Package: ftp.debian.org Severity: normal Hi, The last twig upload got rid of php5-twig (arch:any), so it only builds arch:all packages now. Version 1.24.0-1 of php5-twig seems to prevent version 1.24.0-2 of php-twig* to be available in the archive, and also prevents twig to migrate into testing. Thanks in advance. Regards David signature.asc Description: PGP signature
Bug#824079: qgis: FTBFS on non-Linux: 'TCGETS' was not declared in this scope
On 05/12/2016 10:58 PM, Aaron M. Ucko wrote: > Sebastiaan Couwenberg writes: > >> https://quickgit.kde.org/?p=kpty.git&a=commitdiff&h=35ea45b588db9afcbd796576833ac338c6b4b8e8 >> >> Is this your suggested patch? And if so, can you test it on kfreebsd-*? > > That's a fair question. > > The code change works if I hardcode -DHAVE_TCGETATTR -DHAVE_TCSETATTR on > line 13 of src/plugins/grass/CMakeLists.txt. I initially tried adding > corresponding check_function_exists calls to that block, but they proved > ineffective; CMake evidently doesn't fall back on adding definitions to > the command line in the absence of a config header. Adding " || defined(__FreeBSD_kernel__)" to the #elif statements in kpty.cpp should be sufficient to not need the CMakeLists.txt changes. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#798053: Bug#824079: qgis: FTBFS on non-Linux: 'TCGETS' was not declared in this scope
Sebastiaan Couwenberg writes: > https://quickgit.kde.org/?p=kpty.git&a=commitdiff&h=35ea45b588db9afcbd796576833ac338c6b4b8e8 > > Is this your suggested patch? And if so, can you test it on kfreebsd-*? That's a fair question. The code change works if I hardcode -DHAVE_TCGETATTR -DHAVE_TCSETATTR on line 13 of src/plugins/grass/CMakeLists.txt. I initially tried adding corresponding check_function_exists calls to that block, but they proved ineffective; CMake evidently doesn't fall back on adding definitions to the command line in the absence of a config header. Likewise, #798053 is still an issue because there was no build system change to complement the code change. Thanks for checking! -- 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#824146: libdatetime-event-sunrise-perl: Description has a typo: "calucalating"
Package: libdatetime-event-sunrise-perl Severity: minor Dear Maintainer, the description of the package has a typo, "calucalating". -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#752512: corosync: Corosync doesn't start at reboot
Control: retitle -1 drbd-utils: initscript may wait forever (wfc-timeout unset) Hi, On 10:45 Thu 12 May , Ferenc Wágner wrote: > Christoph Berg writes: > > > Is that something we can or should fix on the corosync side? > > Without further information I can't see anything to fix in corosync. > > > Or reassign to drbd-utils to change the default for wfc-timeout? > > Sounds like a good idea, the original report shows S03drbd S04corosync. > The DRBD maintainers will be able to judge whether changing the default > wfc-timeout makes sense. This is clearly something that should be working by default. DRBD upstream strongly recommends using a cluster manager to control DRBD resources, so it really doesn't make any sense for DRBD to block corosync. I'll have a look and try to figure out a working solution. Regards, Apollon
Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
Wookey wrote: > +++ Christian Seiler [2016-05-07 16:14 +0200]: > > On 05/07/2016 03:59 PM, Geert Stappers wrote: > > > I now have a better idea _why_ a sse-suport package. > > I do think that this sort of ISA-level checking would be best done via > dpkg and package metadata, although this sse-support mechanism will > obviously work. i.e the cpontrol file says what ISA features are > wanted and dpkg can not install it if those HWCAPS are not available > (or indeed install alternate versions that will work if they are > available). > > We worked up a prototype spec for this a couple of years ago (at the > bootstrap sprint), but it needs the namespace and granularity fleshing > out: what is the set of HWCAPS listed in each package, what is > presumed to be 'base' that we don't list individually, and so on. I'd love to see this integrated with dpkg multiarch support. That way, for instance, specific packages could provide optimized versions for specific target CPU features. I think we'd need three things to make that happen: 1) Support in dpkg multiarch to understand "compatible" architectures that can satisfy each others' dependencies (e.g. a dependency on libfoo1:amd64 is satisfied by libfoo1:amd64+avx2, and vice versa). 2) Support for synthesizing such architectures in a canonical way from a set of CPU features, so that every combination of CPU features doesn't need its own unique architecture name (we don't want architecture names like "amd64+sse4+avx2+rdrand", even though a package might need that set of features). 3) Support for detecting available CPU features, as you mentioned above, to not even attempt to install a package that requires unavailable CPU features. Optionally, we could also detect if the set of CPU features has changed incompatibly. For instance, if you move your Debian filesystem to a system without some features that you have installed packages depending on, it'd be nice to handle that as gracefully as possible. - Josh Triplett
Bug#824145: debian-security-support: [INTL:pt] Updated Portuguese translation for debconf messages
Package: debian-security-support version: 2016.05.11 Tags: l10n, patch Severity: wishlist Updated Portuguese translation for debian-security-support's debconf messages. Translator: Américo Monteiro Feel free to use it. For translation updates please contact 'Last Translator' or the Portuguese Translation Team . -- Melhores cumprimentos/Best regards, Américo Monteiro debian-security-support_2016.05.11_pt.po.gz Description: GNU Zip compressed data
Bug#803423: #803423 libqt5gui5: Ugly GUI (no icons) / Weird interpretation of XDG_CURRENT_DESKTOP and GNOME_DESKTOP_SESSION_ID
> @Lisandro >> But that doesn't seems to solve the ssh problem, right? For example one >> could >> run wireshark trough X port forwarding without a DE. > > If you're running some xsettings daemon on your local system, any X client > using this X server should > get these xsettings. If theme files are present on X client's machine, it > should in theory apply the theme. Although in case the client is Qt app, it still needs to be told to mimic GTK (by variable), and then it will get specific GTK and Icon themes from xsettings.
Bug#824142: patch works for me
As the original author of color support in mtr, I've just tested the patch, and it works for me. Fixes heretical setups like transparent or black-on-white while not regressing The Only Proper white-on-black. +1. -- How to exploit the Bible for weight loss: Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.
Bug#823195: evince-common: Mouse Inverted Reversed Scrolling Does not Function
On Thu, May 12, 2016 at 01:05:10AM -0400, Carl N wrote: > I tried your recommendation *how you figured this out I will never > understand* it worked on GTK3 examples and reversed the scroll direction > for evince but now any other non GTK3 program the reverse scrolling > direction feature *as set in the mouse settings panel in xfce* is not > obeyed. If you use that xinput workaround, I recommend turning off Xfce's reverse scrolling option. I think the xinput command reverses scrolling for everything so if you use it with Xfce's option, some programs will be doubly reversed. Since it looks like this is the same problem as https://bugzilla.xfce.org/show_bug.cgi?id=11193, I'll reassign this bug to xfce4-settings. I think Xfce will have to change their mouse settings to support GTK3.
Bug#803423: #803423 libqt5gui5: Ugly GUI (no icons) / Weird interpretation of XDG_CURRENT_DESKTOP and GNOME_DESKTOP_SESSION_ID
> In Qt 5.6, the GTK+ *style* was removed, and the rest of GTK+ integration > (i.e. dialogs or icon theme settings) got ported to GTK+ 3. The recommended > alternative for those who need the style is using third-party styles like > Adwaita-Qt. So after version 5.6 Qt will mimic GTK 3 instead of GTK 2? > A theme can set one or more style names, but it is not a "must". Just to be on the same page, if comparing GTK and QT ways of doing things, Qt style is analogous to engine in GTK world, and Qt platform theme is analogous to theme in GTK world, right? Whey you choose theme in GTK, GTK selects appropriate engine to render that theme. Up until recently in Qt you had to choose style manually, and themes (if particular style supported any) were this style's personal matter. Has something changed recently? @Lisandro > But that doesn't seems to solve the ssh problem, right? For example one could > run wireshark trough X port forwarding without a DE. If you're running some xsettings daemon on your local system, any X client using this X server should get these xsettings. If theme files are present on X client's machine, it should in theory apply the theme.
Bug#821225: disk/memory corruption inside VM, VM crashes on KVM on amd64
severity 821225 normal retitle 821225 transparent huge pages cause disk/memory corruption inside VM, VM crashes on KVM on AMD CPUs thanks On Sat, Apr 16, 2016 at 09:45:52PM +0200, Marc Haber wrote: > I have a desktop PC running with an AMD Phenom II X6 1090T processor, > cpu family 16, model 10. This is as far as I know not subject to the > recent AMD microcode issues, but the amd64-microcode package is > installed nevertheless. > > The host is running a few KVM VMs, also Debian. As soon as the host > runs a kernel of 4.5.0 or later, VMs fail through disk-intensive > operations, such as running aide --update multiple times in a row. > This is independent of the kernel version runing in the guest. > > Failures can manifest themselves in processes in the guest > segfaulting, the guest detecting a journal abort of its ext4 > filesystems and remounting the filesystem r/o or the guest stopping > dead in its tracks. Neither the logs of the guest nor of the host show > anything more conclusive. The system can run for up to six hours > before the VM begins to show the errativ behavior, but usually the > issue surfaces in the first ten minutes of the system running. A workaround is disabling transparent huge pages at runtime. With this setting, all VMs are fine again. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#824144: pluxml: [INTL:de] German debconf translation update
Package: pluxml Version: 5.5-1 Severity: wishlist Tags: l10n patch Hi, please find attached the newest german debconf translation of pluxml. Kind regards, Chris de.po.gz Description: application/gzip
Bug#824141: [Aptitude-devel] Bug#824141: Pressing 'q' to quit shouldn't require hitting [enter] afterward
Control: tag -1 + confirmed Hi Josh, Josh Triplett wrote: > I like the new option to quit after installation, rather than returning > to the UI. However, I don't think doing so should require hitting q > followed by [enter]; just hitting q should suffice. Sure, that's what we want, too. But it's far less trivial than it sounds. The current solution is more or less a compromise. Manuel knows more details about this issue. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#803423: #803423 libqt5gui5: Ugly GUI (no icons) / Weird interpretation of XDG_CURRENT_DESKTOP and GNOME_DESKTOP_SESSION_ID
On Thu, May 12, 2016 at 10:49:10PM +0300, Vladimir K wrote: > Did you mean in Qt >= 5.6? or they are going to change something to break > this after 5.6? Oh, sorry, I thought I explained it on this bug, however it turns it was on another bug. In Qt 5.6, the GTK+ *style* was removed, and the rest of GTK+ integration (i.e. dialogs or icon theme settings) got ported to GTK+ 3. The recommended alternative for those who need the style is using third-party styles like Adwaita-Qt. > If former, does this mean that generally if Qt theme is explicitly selected, > then style (engine) would be chosen by Qt automatically (as it happens in > GTK world)? A theme can set one or more style names, but it is not a "must". -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#822560: aptitude: Pressing "q" to quit after installation leaves a black terminal
Package: aptitude Followup-For: Bug #822560 I understand that aptitude needs to save some state information when quitting. However, why does aptitude need to re-open the full UI just to close it, rather than printing an indication about saving state and then quitting directly from the text output back to the shell? aptitude already needs to properly transition from curses mode back to text mode when invoking dpkg. - Josh Triplett -- Package-specific info: Terminal: xterm-256color $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.1 Compiler: g++ 5.3.1 20160429 Compiled against: apt version 5.0.0 NCurses version 6.0 libsigc++ version: 2.8.0 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.0.20160319 cwidget version: 0.5.17 Apt version: 5.0.0 aptitude linkage: linux-vdso.so.1 (0x7ffd007df000) libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 (0x7fcf854e3000) libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7fcf852b3000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7fcf85088000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7fcf84e81000) libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7fcf84b84000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7fcf84889000) libboost_iostreams.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.58.0 (0x7fcf8466f000) libboost_filesystem.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0 (0x7fcf84456000) libboost_system.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0 (0x7fcf84251000) libxapian.so.22 => /usr/lib/x86_64-linux-gnu/libxapian.so.22 (0x7fcf83e4d000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fcf83c3) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fcf838af000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fcf835b1000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fcf8339b000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fcf82ff6000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7fcf82df3000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fcf82bef000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7fcf829d7000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fcf827bc000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7fcf825ac000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fcf82388000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7fcf82176000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fcf81f6d000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fcf81d68000) /lib64/ld-linux-x86-64.so.2 (0x56018a6dc000) -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aptitude depends on: ii aptitude-common0.8.1-1 ii libapt-pkg5.0 1.2.12 ii libboost-filesystem1.58.0 1.58.0+dfsg-5+b1 ii libboost-iostreams1.58.0 1.58.0+dfsg-5+b1 ii libboost-system1.58.0 1.58.0+dfsg-5+b1 ii libc6 2.22-9 ii libcwidget3v5 0.5.17-4+b1 ii libgcc11:6.1.1-3 ii libncursesw5 6.0+20160319-1 ii libsigc++-2.0-0v5 2.8.0-1 ii libsqlite3-0 3.12.2-1 ii libstdc++6 6.1.1-3 ii libtinfo5 6.0+20160319-1 ii libxapian22v5 1.2.23-1 Versions of packages aptitude recommends: ii libparse-debianchangelog-perl 1.2.0-8 ii sensible-utils 0.0.9 Versions of packages aptitude suggests: pn apt-xapian-index pn aptitude-doc-en | aptitude-doc pn debtags pn tasksel -- no debconf information
Bug#824111: ExpatError: syntax error
On Thu, May 12, 2016 at 10:21:46PM +0530, Ritesh Raj Sarraf wrote: > On Thu, 2016-05-12 at 18:41 +0200, Gaetano Guerriero wrote: > > > > Hi, > > > > do you have the command line and the uris file I can use to reproduce the > > problem ? > > Yes. Please find the uris file attached. And below is the exact command run. > You can clone the current apt-offline from github, the current master that I'm > testing. > > https://github.com/rickysarraf/apt-offline > > > rrs@learner:~/.rrs-home/devel/apt-offline/apt-offline (master)$ ./apt-offline > get /var/tmp/upgrade.uris --cache-dir /var/cache/apt/archives/ --threads 5 -- > bundle /var/tmp/upgrade.zip --bug-reports > > > If you need more information, please let me know. > > -- > Ritesh Raj Sarraf | http://people.debian.org/~rrs Could you please add bug log number to your own logging of exception in debianbts (line ~180 in AptOfflineCoreLib.py) and repeat tests. I suspect this is not aleatory and the same bug numbers are failing server side. For instance debianbts.get_bug_log(818360) is always failing since server is responding 500. Gaetano
Bug#803423: #803423 libqt5gui5: Ugly GUI (no icons) / Weird interpretation of XDG_CURRENT_DESKTOP and GNOME_DESKTOP_SESSION_ID
> As explained earlier in this bug, style ≠ theme. Though the gtk2 theme will > (in Qt ≤ 5.6) set the correct style for you too (so only the second variable > should be enough). > > Also if Qt could detect your desktop as GTK+-based, then even that variable > would not be needed. Did you mean in Qt >= 5.6? or they are going to change something to break this after 5.6? If former, does this mean that generally if Qt theme is explicitly selected, then style (engine) would be chosen by Qt automatically (as it happens in GTK world)?
Bug#824143: libperinci-sub-normalize-perl: FTBFS: Can't locate Sah/Schema/Rinci.pm in @INC
Package: libperinci-sub-normalize-perl Version: 0.16-1 Severity: serious Tags: fixed-upstream User: debian-p...@lists.debian.org Usertags: autopkgtest As noticed by ci.debian.net, this package fails its test suite on current sid, making it also build from source. The librinci-perl package recently made incompatible changes. >From its NEWS.Debian: librinci-perl (1.1.80-1) unstable; urgency=medium From the upstream Changes file for the 1.1.80 release: [Incompatible change] Follow Sah::Schemas spec (each individual schema is put in a separate Sah::Schema::* package). Sah::Schema::Rinci is now replaced with Sah::Schema::rinci::* packages. This breaks the libperinci-sub-normalize-perl test suite: t/00-compile.t . 1..1 ok 1 - Perinci/Sub/Normalize.pm loaded ok ok Can't locate Sah/Schema/Rinci.pm in @INC (you may need to install the Sah::Schema::Rinci module) (@INC contains: /<>/blib/lib /<>/blib/arch /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.22.2 /usr/local/share/perl/5.22.2 /usr/lib/x86_64-linux-gnu/perl5/5.22 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.22 /usr/share/perl/5.22 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at /<>/blib/lib/Perinci/Sub/Normalize.pm line 144. [...] This seems to be fixed upstream. From the Changes file: 0.172016-05-10 (PERLANCAR) - Update to Sah::Schema::rinci::function_meta which replaces Sah::Schema::Rinci. Whoever fixes this: please also make librinci-perl Break libperinci-sub-normalize-perl (<< 0.17~) or something like that to make sure partial upgrades work. -- Niko Tyni nt...@debian.org
Bug#806815: Thursday
Work for us and earn 3,500monthly.2hrs/week.Reply for info
Bug#824142: mtr 0.86 uses suboptimal colours in curses (patch attached)
Package: mtr Version: 0.86-1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu yakkety ubuntu-patch In Ubuntu, the attached patch was applied to achieve the following: * Pull commits from upstream to fix terminal colours (LP: #1581186) As I note in the LP bug[1], this is hardly a critical issue, but it's been driving me nuts since 0.86 landed. Stupidly, I went and learned curses and fixed it locally, which only then gave me the right search terms (mtr + use_default_colors) to get Google to point out that it was already fixed in upstream git. So, I threw away my work, grabbed the upstream commits, and here we are. Would be lovely for you to pick this up in the Debian package, so I can delete my recently-added delta from Ubuntu (and so Debian users can enjoy slightly less broken colours in mtr in unstable). ... Adam [1] https://bugs.launchpad.net/ubuntu/+source/mtr/+bug/1581186 -- System Information: Debian Release: stretch/sid APT prefers yakkety APT policy: (500, 'yakkety') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-21-lowlatency (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) diff -Nru mtr-0.86/debian/patches/color1.patch mtr-0.86/debian/patches/color1.patch --- mtr-0.86/debian/patches/color1.patch 1969-12-31 17:00:00.0 -0700 +++ mtr-0.86/debian/patches/color1.patch 2016-05-12 12:58:21.0 -0600 @@ -0,0 +1,34 @@ +commit 63a1f1493bfbaf7e55eb7e20b3791fc8b14cf92d +Author: Rogier Wolff +Date: Mon Dec 29 09:22:46 2014 +0100 + +added use-default-colors... + +diff --git a/configure.ac b/configure.ac +index d5d1b0e..7199781 100644 +--- a/configure.ac b/configure.ac +@@ -34,6 +34,9 @@ AC_CHECK_FUNC(initscr, , + AC_DEFINE(NO_CURSES, 1, Define if you don't have the curses libraries available.) + CURSES_OBJ= + ++AC_CHECK_LIB(ncurses, use_default_colors, ++ AC_DEFINE(HAVE_USE_DEFAULT_COLORS, 1, [Define this if your curses library has the use_default_colors() command.])) ++ + AC_CHECK_FUNCS(attron fcntl) + + AC_CHECK_LIB(m, floor, , AC_MSG_ERROR(No math library found)) +diff --git a/curses.c b/curses.c +index 3904cb1..02b7937 100644 +--- a/curses.c b/curses.c +@@ -701,6 +701,9 @@ void mtr_curses_open(void) + raw(); + noecho(); + start_color(); ++#ifdef HAVE_USE_DEFAULT_COLORS ++ use_default_colors(); ++#endif + int i; + for (i = 0; i < 8; i++) + init_pair(i+1, i, 0); diff -Nru mtr-0.86/debian/patches/color2.patch mtr-0.86/debian/patches/color2.patch --- mtr-0.86/debian/patches/color2.patch 1969-12-31 17:00:00.0 -0700 +++ mtr-0.86/debian/patches/color2.patch 2016-05-12 12:58:21.0 -0600 @@ -0,0 +1,30 @@ +commit 7571201cf7a3394e0dcd2b037aba1836089cc084 +Author: Narthorn +Date: Mon Oct 12 13:24:57 2015 +0200 + +curses: Fix background transparency in terminal + +Patch comes from, and closes traviscross/mtr#72. + +diff --git a/curses.c b/curses.c +index 02b7937..f95f5d1 100644 +--- a/curses.c b/curses.c +@@ -700,13 +700,15 @@ void mtr_curses_open(void) + initscr(); + raw(); + noecho(); ++ int bg_col = 0; + start_color(); + #ifdef HAVE_USE_DEFAULT_COLORS +- use_default_colors(); ++ if (use_default_colors() == OK) ++bg_col = -1; + #endif + int i; + for (i = 0; i < 8; i++) +- init_pair(i+1, i, 0); ++ init_pair(i+1, i, bg_col); + + mtr_curses_init(); + mtr_curses_redraw(); diff -Nru mtr-0.86/debian/patches/series mtr-0.86/debian/patches/series --- mtr-0.86/debian/patches/series 2015-12-07 12:49:27.0 -0700 +++ mtr-0.86/debian/patches/series 2016-05-12 12:58:41.0 -0600 @@ -0,0 +1,2 @@ +color1.patch +color2.patch
Bug#818115: turn python-sphinx into an arch:any package
Hi Helmut, On Thu, May 12, 2016 at 08:40:00PM +0200, Helmut Grohne wrote: >> 161 is many packages, though in my opinion splitting the documentation into >> arch:all packages is something that should be done independently of this bug. >> Maybe we can have some kind of DD list whose packages are affected by this? >> (Or a Lintian warning, see below.) > > Computing this list in an automated way is difficult, because > build-rdeps has no way of ignoring Build-Depends-Indep (even though the > underlying dose can do that, though not in unstable as Johannes just > told me). reverse-depends -b src:sphinx [1] returns multiple lists for B-D and B-D-I, but a *huge* part of the B-D group is packages that don't have arch-dep stuff at all (i.e. pure Python packages). [1] where reverse-depends is from ubuntu-dev-tools > This is not as clear cut. Sometimes documentation is small. We tend to > not split out every single bit of documentation into arch:all packages. > To the contrary, manual pages tend to be included with the main package. > I do not see consensus for this increase in the number of binary > packages. Right, but we were talking about the solutions to cross issues... > If the dh addon is not to be used, you should deprecate it. I actually > find the addon useful, because it removes complexity (unless you do > [1]). In an ideal world, we would maybe say "dh $@ --with-indep sphinx"? I won't deprecate it because Sphinx was developed for Python and most Python packages don't have any arch-specific stuff at all, so for them --with sphinxdoc works fine. A --with-indep option would be nice indeed :) > > Alternatively, as you suggest, such packages may build-depend on > > sphinx-common > > and I may mark sphinx-common as Muili-Arch: foreign. If it helps then I will > > do that. > > It's the simplest workaround that I see. Of course, people need to > remember to Build-Depend on sphinx-common to use the addon, which is > complexity of its own. If we pursue that road, we should document it > precisely (e.g. README.Debian?). So should I go ahead and add M-A: foreign attribute to sphinx-common? I can also document it in README.Debian but I am not sure I will find proper wording to describe the problem. Maybe you can help me with that? If you could do that, then I'll be able to describe the solution myself. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#824141: Pressing 'q' to quit shouldn't require hitting [enter] afterward
Package: aptitude Version: 0.8.1-1 Severity: wishlist I like the new option to quit after installation, rather than returning to the UI. However, I don't think doing so should require hitting q followed by [enter]; just hitting q should suffice. -- Package-specific info: Terminal: xterm-256color $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.1 Compiler: g++ 5.3.1 20160429 Compiled against: apt version 5.0.0 NCurses version 6.0 libsigc++ version: 2.8.0 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.0.20160319 cwidget version: 0.5.17 Apt version: 5.0.0 aptitude linkage: linux-vdso.so.1 (0x7ffc26575000) libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 (0x7f82080f3000) libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7f8207ec3000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f8207c98000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7f8207a91000) libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7f8207794000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f8207499000) libboost_iostreams.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.58.0 (0x7f820727f000) libboost_filesystem.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0 (0x7f8207066000) libboost_system.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0 (0x7f8206e61000) libxapian.so.22 => /usr/lib/x86_64-linux-gnu/libxapian.so.22 (0x7f8206a5d000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f820684) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f82064bf000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f82061c1000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f8205fab000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8205c06000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f8205a03000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f82057ff000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f82055e7000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f82053cc000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f82051bc000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f8204f98000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7f8204d86000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f8204b7d000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f8204978000) /lib64/ld-linux-x86-64.so.2 (0x5562e4185000) -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aptitude depends on: ii aptitude-common0.8.1-1 ii libapt-pkg5.0 1.2.12 ii libboost-filesystem1.58.0 1.58.0+dfsg-5+b1 ii libboost-iostreams1.58.0 1.58.0+dfsg-5+b1 ii libboost-system1.58.0 1.58.0+dfsg-5+b1 ii libc6 2.22-9 ii libcwidget3v5 0.5.17-4+b1 ii libgcc11:6.1.1-3 ii libncursesw5 6.0+20160319-1 ii libsigc++-2.0-0v5 2.8.0-1 ii libsqlite3-0 3.12.2-1 ii libstdc++6 6.1.1-3 ii libtinfo5 6.0+20160319-1 ii libxapian22v5 1.2.23-1 Versions of packages aptitude recommends: ii libparse-debianchangelog-perl 1.2.0-8 ii sensible-utils 0.0.9 Versions of packages aptitude suggests: pn apt-xapian-index pn aptitude-doc-en | aptitude-doc pn debtags pn tasksel -- no debconf information
Bug#803423: #803423 libqt5gui5: Ugly GUI (no icons) / Weird interpretation of XDG_CURRENT_DESKTOP and GNOME_DESKTOP_SESSION_ID
Hi Vladimir, On Thu, May 12, 2016 at 06:32:29PM +0300, Vladimir K wrote: > After some digging, I've added this var to session environment, and icons > appeared in qt5 apps: > QT_QPA_PLATFORMTHEME=gtk2 > > Can someone explain what is the difference between QT_STYLE_OVERRIDE and > QT_QPA_PLATFORMTHEME, and why the former affects theme and the latter > affects icons? As explained earlier in this bug, style ≠ theme. Though the gtk2 theme will (in Qt ≤ 5.6) set the correct style for you too (so only the second variable should be enough). Also if Qt could detect your desktop as GTK+-based, then even that variable would not be needed. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#727651: keepass2: need of debug output?
Package: keepass2 Version: 2.28+dfsg-1 Followup-For: Bug #727651 Dear Maintainer, I am experiencing what seems to be the same bug: unnecessary debug ouput, and an unhandled exception upon quitting: $ keepass2 & $ SendMessage (33554474, 0x112c, 0x4, 0x4) SendMessage (33554468, 0x101f, (nil), (nil)) SendMessage (0, 0x1203, (nil), 0xbff79650) SendMessage (0, 0x1204, (nil), 0xbff79650) SendMessage (0, 0x1203, 0x1, 0xbff79650) SendMessage (0, 0x1204, 0x1, 0xbff79650) SendMessage (0, 0x1203, 0x2, 0xbff79650) SendMessage (0, 0x1204, 0x2, 0xbff79650) SendMessage (0, 0x1203, 0x3, 0xbff79650) SendMessage (0, 0x1204, 0x3, 0xbff79650) SendMessage (0, 0x1203, 0x4, 0xbff79650) SendMessage (0, 0x1204, 0x4, 0xbff79650) SendMessage (33554468, 0x101f, (nil), (nil)) SendMessage (0, 0x1203, (nil), 0xbff79610) SendMessage (0, 0x1204, (nil), 0xbff79610) SendMessage (0, 0x1203, 0x1, 0xbff79610) SendMessage (0, 0x1204, 0x1, 0xbff79610) SendMessage (0, 0x1203, 0x2, 0xbff79610) SendMessage (0, 0x1204, 0x2, 0xbff79610) SendMessage (0, 0x1203, 0x3, 0xbff79610) SendMessage (0, 0x1204, 0x3, 0xbff79610) SendMessage (0, 0x1203, 0x4, 0xbff79610) SendMessage (0, 0x1204, 0x4, 0xbff79610) SendMessage (33554468, 0x101f, (nil), (nil)) SendMessage (0, 0x1203, (nil), 0xbff7a2a0) SendMessage (0, 0x1204, (nil), 0xbff7a2a0) SendMessage (0, 0x1203, 0x1, 0xbff7a2a0) SendMessage (0, 0x1204, 0x1, 0xbff7a2a0) SendMessage (0, 0x1203, 0x2, 0xbff7a2a0) SendMessage (0, 0x1204, 0x2, 0xbff7a2a0) SendMessage (0, 0x1203, 0x3, 0xbff7a2a0) SendMessage (0, 0x1204, 0x3, 0xbff7a2a0) SendMessage (0, 0x1203, 0x4, 0xbff7a2a0) SendMessage (0, 0x1204, 0x4, 0xbff7a2a0) SendMessage (33554460, 0x444, 0x1, 0x9b9ffa0) SendMessage (33554460, 0x444, 0x1, 0x9bcb780) SendMessage (33554460, 0x444, 0x1, 0x9bb9c50) SendMessage (33554460, 0x444, 0x1, 0x9bb9c50) SendMessage (33554460, 0x444, 0x1, 0x9c0ae58) SendMessage (33554460, 0x444, 0x1, 0x9c0ae58) SendMessage (33554460, 0x444, 0x1, 0x9c2cd90) SendMessage (33554460, 0x444, 0x1, 0x9c2cd90) Unhandled Exception: System.ArgumentException: A null reference or invalid value was found [GDI+ status: InvalidParameter] at System.Drawing.GDIPlus.CheckStatus (Status status) [0x0] in :0 at System.Drawing.Graphics.GdipMeasureString (IntPtr graphics, System.String text, System.Drawing.Font font, System.Drawing.RectangleF& layoutRect, IntPtr stringFormat) [0x0] in :0 at System.Drawing.Graphics.MeasureString (System.String text, System.Drawing.Font font, Int32 width, System.Drawing.StringFormat format) [0x0] in :0 at (wrapper remoting-invoke-with-check) System.Drawing.Graphics:MeasureString (string,System.Drawing.Font,int,System.Drawing.StringFormat) at System.Windows.Forms.TextRenderer.MeasureTextInternal (IDeviceContext dc, System.String text, System.Drawing.Font font, Size proposedSize, TextFormatFlags flags, Boolean useMeasureString) [0x0] in :0 at System.Windows.Forms.TextRenderer.MeasureText (System.String text, System.Drawing.Font font) [0x0] in :0 at System.Windows.Forms.ToolStripMenuItem.CalculatePreferredSize (Size constrainingSize) [0x0] in :0 at System.Windows.Forms.ToolStripItem.GetPreferredSize (Size constrainingSize) [0x0] in :0 at System.Windows.Forms.ToolStripDropDownMenu.OnLayout (System.Windows.Forms.LayoutEventArgs e) [0x0] in :0 at System.Windows.Forms.Control.PerformLayout (System.Windows.Forms.Control affectedControl, System.String affectedProperty) [0x0] in :0 at System.Windows.Forms.Control.PerformLayout () [0x0] in :0 at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control:PerformLayout () at System.Windows.Forms.ToolStripItem.OnParentChanged (System.Windows.Forms.ToolStrip oldParent, System.Windows.Forms.ToolStrip newParent) [0x0] in :0 at System.Windows.Forms.ToolStripItem.set_Parent (System.Windows.Forms.ToolStrip value) [0x0] in :0 at (wrapper remoting-invoke-with-check) System.Windows.Forms.ToolStripItem:set_Parent (System.Windows.Forms.ToolStrip) at System.Windows.Forms.ToolStripItemCollection.Remove (System.Windows.Forms.ToolStripItem value) [0x0] in :0 at System.Windows.Forms.ToolStripItem.Dispose (Boolean disposing) [0x0] in :0 at System.Windows.Forms.ToolStripDropDownItem.Dispose (Boolean disposing) [0x0] in :0 at System.Windows.Forms.ToolStripMenuItem.Dispose (Boolean disposing) [0x0] in :0 at System.ComponentModel.Component.Finalize () [0x0] in :0 ^C [1]+ Exit 255keepass2 -- System Information: Debian Release: 8.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages keepass2 depends on: ii libmono-corlib4.5-cil3.2.8+dfsg-10 ii libmono-system-drawing4.0-cil3
Bug#824140: allegro4.4: please make the build reproducible
Source: allegro4.4
Version: 2:4.4.2-8
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Hi!
While working on the "reproducible builds" effort [1], we have noticed
that allegro4.4 could not be built reproducibly.
Two lists of files are not sorted in tools/CMakeLists.txt.
One list is used for determining the order in which source files are
linked, and the other list is used for generating a header file (which
would also be unsorted).
The attached patch fixes this by sorting those two lists.
Regards,
Reiner
[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/series b/debian/patches/series
index 97b0f63..aa2284c 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -9,3 +9,4 @@ asm_fixes.patch
fix_ftbfs_nonlinux.patch
fix_ftbfs_with_sbuild.patch
customize_allegro-config.patch
+sort_source_files.patch
diff --git a/debian/patches/sort_source_files.patch b/debian/patches/sort_source_files.patch
new file mode 100644
index 000..6ce0533
--- /dev/null
+++ b/debian/patches/sort_source_files.patch
@@ -0,0 +1,15 @@
+Author: Reiner Herrmann
+Description: Sort list of source files for reproducible build
+
+--- a/tools/CMakeLists.txt
b/tools/CMakeLists.txt
+@@ -4,7 +4,9 @@
+ #
+
+ file(GLOB PLUGIN_SRCS ${CMAKE_CURRENT_SOURCE_DIR}/plugins/*.c)
++list(SORT PLUGIN_SRCS)
+ file(GLOB PLUGIN_INCS ${CMAKE_CURRENT_SOURCE_DIR}/plugins/*.inc)
++list(SORT PLUGIN_INCS)
+
+ # XXX support plugin "scripts", i.e. linker arguments.
+ # With CMake it should just be the name of a target to link with.
signature.asc
Description: PGP signature
Bug#824091: linux-image-4.4.0-0.bpo.1-amd64: GPF on hot drive removal
Well, on my first attempt to reproduce it with no ZFS modules loaded, I got a nice "BUG: unable to handle kernel paging request at 000168a0" out instead of a GPF. Is this sufficient, or would you like me to repeat until I produce a GPF again? - Rich On Thu, May 12, 2016 at 9:38 AM, Ben Hutchings wrote: > Control: tag -1 moreinfo > > On Thu, 2016-05-12 at 03:37 -0400, Rich wrote: > > Package: src:linux > > Version: 4.4.6-1~bpo8+1 > > Severity: normal > > > > Dear Maintainer, > > > > I'm going through old hard drives, ddrescuing the old contents off, > > zeroing the drives, and recycling them. > > > > I had one drive which refused to read any sectors - if I let the > > drive eventually time out, or unplug the drive, I either get a GPF or > > an Oops in my kernel log. > > > > The GPF follows - I could be mistaken, but I don't expect an IO error > > to trigger a GPF in the kernel. > > > > Please let me know if I can report any additional information to help > > with this. > [...] > > Can you reproduce this without ZFS modules loaded? > > Ben. > > -- > Ben Hutchings > If you seem to know what you are doing, you'll be given more to do. > [ 377.451606] BUG: unable to handle kernel paging request at 000168a0 [ 377.451683] IP: [] native_queued_spin_lock_slowpath+0xf9/0x170 [ 377.451757] PGD 0 [ 377.451781] Oops: 0002 [#1] SMP [ 377.451817] Modules linked in: bluetooth rfkill msr 8021q binfmt_misc garp mrp stp llc tcm_loop tcm_qla2xxx qla2xxx ib_srpt iscsi_target_mod vhost_scsi vhost tcm_fc libfc scsi_transport_fc target_core_file target_core_iblock target_core_pscsi target_core_mod configfs cpufreq_stats cpufreq_powersave cpufreq_conservative cpufreq_userspace nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi intel_rapl iosf_mbi x86_pkg_temp_thermal intel_po werclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul tcp_htcp iTCO_wdt iTCO_vendor_support mxm_wmi sha256_ssse3 sha256_generic hmac drbg ansi_cprng ast ttm hwmon_vid drm_kms_helper drm aesni_intel aes_x86_64 loop lrw gf128mul [ 377.452659] ioatdma glue_helper joydev evdev sb_edac ablk_helper mei_me lpc_ich cryptd pcspkr edac_core ipmi_watchdog i2c_i801 mfd_core mei shpchp 8250_fintek wmi acpi_pad tpm_tis tpm button processor ipmi_si ipmi_poweroff ipmi_devintf ipmi_msghandler fuse parport_pc ppdev lp parp ort autofs4 ext4 crc16 mbcache jbd2 btrfs xor raid6_pq md_mod dm_mirror dm_region_hash dm_log dm_mod ses enclosure sg sd_mod hid_generic usbhid hid uas usb_storage ahci libahci mpt3sas raid_class libata scsi_transport_sas ehci_pci crc32c_intel xhci_pci ixgbe ehci_hcd igb xhci_hcd vxla n i2c_algo_bit ip6_udp_tunnel dca udp_tunnel usbcore ptp scsi_mod pps_core usb_common mdio fjes [ 377.453393] CPU: 2 PID: 436 Comm: systemd-udevd Not tainted 4.4.0-0.bpo.1-amd64 #1 Debian 4.4.6-1~bpo8+1 [ 377.453471] Hardware name: Supermicro Super Server/X10SDV-TLN4F, BIOS 1.0b 09/09/2015 [ 377.453536] task: 8808567a5200 ti: 88085679c000 task.ti: 88085679c000 [ 377.453597] RIP: 0010:[] [] native_queued_spin_lock_slowpath+0xf9/0x170 [ 377.453686] RSP: 0018:88085679fbe0 EFLAGS: 00010006 [ 377.453730] RAX: 168e RBX: 0286 RCX: 000c [ 377.453789] RDX: 88087fc56880 RSI: 000168a0 RDI: 8808547a27c0 [ 377.453849] RBP: 0001 R08: 0001 R09: 0001a258 [ 377.453945] R10: 00d3 R11: 8808567a R12: 0001 [ 377.454042] R13: 00c3 R14: 00fb R15: 00fb [ 377.454120] FS: 7f68d3665880() GS:88087fc4() knlGS: [ 377.454186] CS: 0010 DS: ES: CR0: 80050033 [ 377.454234] CR2: 000168a0 CR3: 000855c8c000 CR4: 003406e0 [ 377.454293] DR0: DR1: DR2: [ 377.454355] DR3: DR6: fffe0ff0 DR7: 0400 [ 377.454412] Stack: [ 377.454432] 81592512 8808547a27c0 810b7092 880074fd1000 [ 377.456824] 880856aa3800 880856aa3800 00fb [ 377.459235] 81481166 880074fd1000 814c7a76 880074fd1000 [ 377.461646] Call Trace: [ 377.464026] [] ? _raw_spin_lock_irqsave+0x32/0x40 [ 377.466427] [] ? __wake_up_sync_key+0x22/0x60 [ 377.468795] [] ? sock_def_readable+0x36/0x60 [ 377.471067] [] ? __netlink_sendskb+0x156/0x230 [ 377.473167] [] ? netlink_unicast+0x17e/0x1a0 [ 377.475253] [] ? netlink_sendmsg+0x4f9/0x610 [ 377.477330] [] ? rw_copy_check_uvector+0x68/0x110 [ 377.479442] [] ? sock_sendmsg+0x30/0x40 [ 377.481557] [] ? ___sys_sendmsg+0x27f/0x290 [ 377.483669] [] ? unix_dgram_recvmsg+0x277/0x440 [ 377.485767] [] ? SYSC_recvfrom+0xc0/0x130 [ 377.487854] [] ? __sys_sendmsg+0x4e/0x90 [ 377.4899
Bug#804079: [src:linux] Xen randomly crashing server
Package: src:linux --- Please enter the report below this line. --- Hi! I think I'm facing the same problem as Jan. My server with Xen (running Debian stable with uptodate linux kernel 3.16.0) is sometimes crashing several times a day, but then again it is running for weeks without a problem. I've blogged twice about the problem: - https://blog.windfluechter.net/content/blog/2016/03/23/1721-xen-randomly-crashing-server - https://blog.windfluechter.net/content/blog/2016/05/12/1723-xen-randomly-crashing-server-part-2 with some more information I'm attaching the file from my blog entry here as well. Regards, Ingo --- System information. --- Architecture: amd64 Kernel: Linux 4.4.0-1-amd64 Debian Release: stretch/sid 500 unstablewww.deb-multimedia.org 500 unstableftp.de.debian.org 500 unstabledownload.jitsi.org --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty. -- Ciao...// Fon: 0381-2744150 Ingo \X/ http://blog.windfluechter.net Please don't share this address with Facebook or Google! gpg pubkey: http://www.juergensmann.de/ij_public_key.asc # # # crash #1 # # May 12 11:56:39 31.172.31.251 [829681.039478] BUG: unable to handle kernel May 12 11:56:39 31.172.31.251 at 88006cd1f000 May 12 11:56:39 31.172.31.251 [829681.039530] IP: May 12 11:56:39 31.172.31.251 [] memcpy+0x6/0x110 May 12 11:56:39 31.172.31.251 [829681.039572] PGD 1814067 May 12 11:56:39 31.172.31.251 May 12 11:56:39 31.172.31.251 [829681.039618] Oops: [#1] May 12 11:56:39 31.172.31.251 May 12 11:56:39 31.172.31.251 [829681.039654] Modules linked in: May 12 11:56:39 31.172.31.251 xt_policy May 12 11:56:39 31.172.31.251 authenc May 12 11:56:39 31.172.31.251 xfrm6_mode_tunnel May 12 11:56:39 31.172.31.251 xfrm4_mode_tunnel May 12 11:56:39 31.172.31.251 hmac May 12 11:56:39 31.172.31.251 cpuid May 12 11:56:39 31.172.31.251 msr May 12 11:56:39 31.172.31.251 xt_physdev May 12 11:56:39 31.172.31.251 xen_netback May 12 11:56:39 31.172.31.251 tun May 12 11:56:39 31.172.31.251 xen_blkback May 12 11:56:39 31.172.31.251 xen_gntdev May 12 11:56:39 31.172.31.251 xen_evtchn May 12 11:56:39 31.172.31.251 xenfs May 12 11:56:39 31.172.31.251 xen_privcmd May 12 11:56:39 31.172.31.251 ipt_ULOG May 12 11:56:39 31.172.31.251 ipmi_poweroff May 12 11:56:39 31.172.31.251 xt_multiport May 12 11:56:39 31.172.31.251 video May 12 11:56:39 31.172.31.251 thermal May 12 11:56:39 31.172.31.251 fan May 12 11:56:39 31.172.31.251 ac May 12 11:56:39 31.172.31.251 battery May 12 11:56:39 31.172.31.251 xfrm_user May 12 11:56:39 31.172.31.251 xfrm4_tunnel May 12 11:56:39 31.172.31.251 tunnel4 May 12 11:56:39 31.172.31.251 ipcomp May 12 11:56:39 31.172.31.251 xfrm_ipcomp May 12 11:56:39 31.172.31.251 esp4 May 12 11:56:39 31.172.31.251 ah4 May 12 11:56:39 31.172.31.251 af_key May 12 11:56:39 31.172.31.251 xfrm_algo May 12 11:56:39 31.172.31.251 ip6t_REJECT May 12 11:56:39 31.172.31.251 ip6table_filter May 12 11:56:39 31.172.31.251 ip6_tables May 12 11:56:39 31.172.31.251 bridge May 12 11:56:39 31.172.31.251 stp May 12 11:56:39 31.172.31.251 llc May 12 11:56:39 31.172.31.251 ipt_REJECT May 12 11:56:39 31.172.31.251 xt_tcpudp May 12 11:56:39 31.172.31.251 iptable_filter May 12 11:56:39 31.172.31.251 ip_tables May 12 11:56:39 31.172.31.251 x_tables May 12 11:56:39 31.172.31.251 ext4 May 12 11:56:39 31.172.31.251 crc16 May 12 11:56:39 31.172.31.251 mbcache May 12 11:56:39 31.172.31.251 jbd2 May 12 11:56:39 31.172.31.251 ipmi_devintf May 12 11:56:39 31.172.31.251 ipmi_watchdog May 12 11:56:39 31.172.31.251 w83627ehf May 12 11:56:39 31.172.31.251 hwmon_vid May 12 11:56:39 31.172.31.251 nf_conntrack_ipv4 May 12 11:56:39 31.172.31.251 nf_defrag_ipv4 May 12 11:56:39 31.172.31.251 nf_conntrack May 12 11:56:39 31.172.31.251 loop May 12 11:56:39 31.172.31.251 fuse May 12 11:56:39 31.172.31.251 x86_pkg_temp_thermal May 12 11:56:39 31.172.31.251 intel_powerclamp May 12 11:56:39 31.172.31.251 coretemp May 12 11:56:39 31.172.31.251 crc32_pclmul May 12 11:56:39 31.172.31.251 aesni_intel May 12 11:56:39 31.172.31.251 aes_x86_64 May 12 11:56:39 31.172.31.251 lrw May 12 11:56:39 31.172.31.251 gf128mul May 12 11:56:39 31.172.31.251 glue_helper May 12 11:56:39 31.172.31.251 iTCO_wdt May 12 11:56:39 31.172.31.251 iTCO_vendor_support May 12 11:56:39 31.172.31.251 ablk_helper May 12 11:56:39 31.172.31.251 cryptd May 12 11:56:39 31.172.31.251 pcspkr May 12 11:56:39 31.172.31.251 serio_raw May 12 11:56:39 31.172.31.251 sb_edac May 12 11:56:39 31.172.31.251 joydev May 12 11:56:39 31.172.31.251 evdev May 12 11:56:39 31.172.31.251 edac_core May 12 11:56:39 31.172.31.251 ttm May 12 11:56:39 31.172.31.251 drm
Bug#824134: [libtachyon-serial-0] OpenMPI in the description of libtachyon-serial
Dear Katsuhiko, thanks for your report. Jerome On 12/05/16 18:46, Katsuhiko Nishimra wrote: > Package: libtachyon-serial-0 > Version: 0.99~b6+dsx-4 > Severity: minor > Tags: patch > > Dear maintainer, > > I'm afraid that the description of this package is little bit wrong. > (OpenMPI in libtachyon-serial-0) > > Here I attach a patch to fix it. > I hope it helps you. > > Regards, > Katsuhiko > > >
Bug#824139: ocaml: CVE-2015-8869
Source: ocaml Version: 3.12.1-4 Severity: important Tags: security upstream patch fixed-upstream Forwarded: http://caml.inria.fr/mantis/view.php?id=7003 Control: fixed -1 3.12.1-4+deb7u1 Hi, the following vulnerability was published for ocaml. CVE-2015-8869[0]: buffer overflow and information leak 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-2015-8869 [1] http://caml.inria.fr/mantis/view.php?id=7003 Regards, Salvatore
Bug#824138: [ftp.debian.org] override: irstlm/section
Package: ftp.debian.org Severity: normal Hi to all, is it possible to move irstlm package from section text to section science? The section science seems more appropriate for the package and Section field has thus be changed accordingly with latest upload. Thank you, Giulio signature.asc Description: OpenPGP digital signature
Bug#824136: ITP: libjaylink -- library for interacting with J-Link programmers
the current state of things can be fetched from [1]. upstream still expects some changes before the api is stable, so there is no sense in aiming for an upload. consequently, there is no symbols file yet. the lack of releases so far leads to non-existent watch files and changelogs. lintian currently complains about the experimental debhelper version that's not properly mapped to a dependency, but that might almost resolve itself by the time the package is needed. hardening-no-bindnow affects too many packages right now to fix it locally, didn't investigate further. local installation of the resulting packages has enabled me to build what might just as well be called libjaylink-tools[2], which depend on pkg-config to automatically find libjaylink. [1]: https://anonscm.debian.org/git/collab-maint/libjaylink.git -b debian [2]: http://git.zapb.de/libjaylink-snippets.git/ -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature
Bug#815444: RFS: lzd/0.8-1
Hi Daniel, You're welcome. Have a nice day! Regards, Eriberto 2016-05-12 12:39 GMT-03:00 Daniel Baumann : > close 815444 > thanks > > Hi Eriberto, > > sorry for my late answer.. yes, of course I remember you. > > Regarding lzd, I've decided to wait a bit with the dbg->dbgsym transition a > bit more (and have thus have uploaded 0.8-1 already, as it now doesn't have > to go through NEW that way and so I don't need a sponsor). > > I don't think it's a good idea to have watch files in the package, this > should be a seperate metadata, so I prefer not using them as they're > conceptionally outdated and require uploads just for keeping them working > (circumventing this by having overrides at some location is cheating - since > that mechanism already exists it's imho simpler/easier to just maintain that > part of meta information there). > > I've fixed the https links, thanks for spotting it. > > Regarding hardening, I'll do that with the next upload. > > Closing the bug for now, thanks again for your offer and help. > > Regards, > Daniel
Bug#756354: regina-rexx FTBFS on arm64. Outdated config,sub/guess
user debian-powe...@lists.debian.org usertags 756354 + ppc64el thanks This also affects ppc64el. Peter's patch works but does not clean well. I have applied his patch and added a minor change to do so. The debdiff is attached. Regards. diff -Nru regina-rexx-3.6/debian/changelog regina-rexx-3.6/debian/changelog --- regina-rexx-3.6/debian/changelog 2012-06-30 12:24:40.0 -0400 +++ regina-rexx-3.6/debian/changelog 2016-05-12 12:32:30.0 -0400 @@ -1,3 +1,10 @@ +regina-rexx (3.6-3) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Applied patch from #756354 with some changes to clean properly. + + -- Fernando Seiti Furusato Thu, 12 May 2016 12:31:59 -0400 + regina-rexx (3.6-2) unstable; urgency=low * Fixed debian/rules build target. diff -Nru regina-rexx-3.6/debian/control regina-rexx-3.6/debian/control --- regina-rexx-3.6/debian/control 2012-06-30 06:09:52.0 -0400 +++ regina-rexx-3.6/debian/control 2016-05-12 12:31:55.0 -0400 @@ -2,7 +2,7 @@ Section: libs Priority: optional Maintainer: Alen Zekulic -Build-Depends: binutils, libncurses5-dev +Build-Depends: binutils, libncurses5-dev, autotools-dev Standards-Version: 3.9.3 Homepage: http://regina-rexx.sourceforge.net/ diff -Nru regina-rexx-3.6/debian/rules regina-rexx-3.6/debian/rules --- regina-rexx-3.6/debian/rules 2012-06-30 12:20:43.0 -0400 +++ regina-rexx-3.6/debian/rules 2016-05-12 12:29:43.0 -0400 @@ -45,11 +45,19 @@ configure: stamp-configure stamp-configure: $(checkdir) + cp -f common/config.guess common/config.guess.old + cp -f common/config.sub common/config.sub.old + cp -f /usr/share/misc/config.sub common/ + cp -f /usr/share/misc/config.guess common/ LDFLAGS="$(LDFLAGS)" ./configure $(confflags) touch stamp-configure clean: $(checkdir) + if [ -f common/config.sub.old -a -f common/config.guess.old ]; then \ + mv common/config.sub.old common/config.sub; \ + mv common/config.guess.old common/config.guess; \ + fi -rm -f stamp-build stamp-configure config.cache config.log config.guess config.sub [ ! -f Makefile ] || $(MAKE) distclean -chmod 644 debian/md5_sums
Bug#818115: turn python-sphinx into an arch:any package
Hi Dmitry, On Thu, May 12, 2016 at 01:34:04PM +0300, Dmitry Shachnev wrote: > As you can see, I don't always reply quickly. Sorry for the delay this time. Things go slowly in cross-land anyway. Thanks for your continued interest. :) > > Cross building only applied to arch-dep packages. So in jansson's case, > > it is not about libjansson-doc, but about the other packages. The only > > part of sphinx that is actually used during a cross build of jansson > > actually is the debhelper addon, which actually lives in sphinx-common > > and is exposed by python-sphinx. In a very similar case, Tomasz Buchert > > was able to move python-sphinx from Build-Depends to Build-Depends-Indep > > in nghttp2[1]. So looking at this closer again, a potential solution for > > sphinx could be: > > > > * Mark sphinx-common Multi-Arch: foreign. > > * Move python-sphinx from jansson's Build-Depends to > >Build-Depends-Indep. > > * Add sphinx-common to jansson's Build-Depends. > > > > I didn't verify whether these changes are correct. We can try this to > > put urgency out of the loop. > > I like the plan, though the third point can be avoided if dh_sphinxdoc is > called only during arch-indep build. Correct. In jansson's case, the dh addon is used. In the mean time, we fixed jansson with a wicked patch[1] that only enables the addon for arch-indep builds. While it works, it looks fragile to me. So whenever the dh addon is used, adding sphinx-common to Build-Depends is the easy way. > 161 is many packages, though in my opinion splitting the documentation into > arch:all packages is something that should be done independently of this bug. > Maybe we can have some kind of DD list whose packages are affected by this? > (Or a Lintian warning, see below.) Computing this list in an automated way is difficult, because build-rdeps has no way of ignoring Build-Depends-Indep (even though the underlying dose can do that, though not in unstable as Johannes just told me). > > Do you have any preferences on the approaches sketched above keeping in > > mind that we will apply it to hundreds of packages? > > In an ideal world, the solution looks this way: > > 1) Packages shipping Sphinx documentation in arch:any packages should > split it into arch:all packages. > > 2) All packages using Sphinx should make sure dh_sphinxdoc is only called > during arch-indep build. > > For 1), maybe we can have a Lintian warning for that? > (i.e. sphinx-documentation-in-architecture-dependent-package) This is not as clear cut. Sometimes documentation is small. We tend to not split out every single bit of documentation into arch:all packages. To the contrary, manual pages tend to be included with the main package. I do not see consensus for this increase in the number of binary packages. > For 2), this means packages having both arch-dep and arch-indep packages won't > be able to use --with sphinxdoc because sphinxdoc.pm sequence won't be present > during arch:indep build. We can recommend packages to insert it manually then, > like: > > override_dh_installdocs-indep: > dh_installdocs -i > dh_sphinxdoc -i If the dh addon is not to be used, you should deprecate it. I actually find the addon useful, because it removes complexity (unless you do [1]). In an ideal world, we would maybe say "dh $@ --with-indep sphinx"? > Alternatively, as you suggest, such packages may build-depend on sphinx-common > and I may mark sphinx-common as Muili-Arch: foreign. If it helps then I will > do that. It's the simplest workaround that I see. Of course, people need to remember to Build-Depend on sphinx-common to use the addon, which is complexity of its own. If we pursue that road, we should document it precisely (e.g. README.Debian?). Helmut [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=807848;filename=jansson_2.7-3.1.debdiff;msg=29
Bug#824137: texlive-fonts-extra-doc: trying to overwrite '/usr/share/doc/texlive-doc/latex/mweights/README' from texlive-latex-extra-doc 2015.20160320-1
Package: texlive-fonts-extra-doc Version: 2016.20160512-1 Severity: serious When upgrading texlive-fonts-extra-doc: Preparing to unpack .../texlive-fonts-extra-doc_2016.20160512-1_all.deb ... Unpacking texlive-fonts-extra-doc (2016.20160512-1) over (2015.20160320-1) ... dpkg: error processing archive /var/cache/apt/archives/texlive-fonts-extra-doc_2016.20160512-1_all.deb (--unpack): trying to overwrite '/usr/share/doc/texlive-doc/latex/mweights/README', which is also in package texlive-latex-extra-doc 2015.20160320-1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Sami -- Package-specific info: IMPORTANT INFORMATION: We will only consider bug reports concerning the packaging of TeX Live as relevant. If you have problems with combination of packages in a LaTeX document, please consult your local TeX User Group, the comp.text.tex user group, the author of the original .sty file, or any other help resource. In particular, bugs that are related to up-upstream, i.e., neither Debian nor TeX Live (upstream), but the original package authors, will be closed immediately. *** The Debian TeX Team is *not* a LaTeX Help Desk *** If you report an error when running one of the TeX-related binaries (latex, pdftex, metafont,...), or if the bug is related to bad or wrong output, please include a MINIMAL example input file that produces the error in your report. Please run your example with (pdf)latex -recorder ... (or any other program that supports -recorder) and send us the generated file with the extension .fls, it lists all the files loaded during the run and can easily explain problems induced by outdated files in your home directory. Don't forget to also include minimal examples of other files that are needed, e.g. bibtex databases. Often it also helps to include the logfile. Please, never send included pictures! If your example file isn't short or produces more than one page of output (except when multiple pages are needed to show the problem), you can probably minimize it further. Instructions on how to do that can be found at http://www.minimalbeispiel.de/mini-en.html (english) or http://www.minimalbeispiel.de/mini.html (german) ## minimal input file ## other files ## List of ls-R files lrwxrwxrwx 1 root root 31 Mar 20 07:32 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST ## Config files Warning: texmf.cnf cannot be found with kpsewhich! Warning: fmtutil.cnf cannot be found with kpsewhich! Warning: updmap.cfg cannot be found with kpsewhich! Warning: language.dat cannot be found with kpsewhich! ## Files in /etc/texmf/web2c/ total 8 -rw-r--r-- 1 root root 283 Jun 9 2009 mktex.cnf -rw-r--r-- 1 root root 1464 Apr 26 23:39 texmf.cnf ## md5sums of texmf.d ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf 055e06548bac99958d8ab2dd1248f2b4 /etc/texmf/texmf.d/80tex4ht.cnf 1df66bc319cec731e202eaf39f5d85e1 /etc/texmf/texmf.d/96JadeTeX.cnf -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.2 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages texlive-fonts-extra-doc depends on: ii tex-common6.05 ii texlive-base 2015.20160320-1 texlive-fonts-extra-doc recommends no packages. texlive-fonts-extra-doc suggests no packages. Versions of packages tex-common depends on: ii dpkg 1.18.7 ii ucf 3.0036 Versions of packages tex-common suggests: ii debhelper 9.20160403 Versions of packages texlive-fonts-extra-doc is related to: ii tex-common6.05 pn texlive-binaries -- debconf information: tex-common/check_texmf_wrong: tex-common/check_texmf_missing:
Bug#824136: ITP: libjaylink -- library for interacting with J-Link programmers
Package: wnpp Severity: wishlist * Package name: libjaylink Version : no releases yet Upstream Author : Marc Schink * URL : http://git.zapb.de/libjaylink.git * License : GPL-2+ Programming Lang: C Description : library for interacting with J-Link programmers libjaylink provides functions for interacting with Segger J-Link USB devices, which are used for programming and debugging ARM chips. The library is primarily used by OpenOCD, which provides a practical interface for using the devices. -- the library is already in use by the upcoming openocd version, the dependency was merged in after the current 0.9.0 release. while openocd is prepared to build this as a submodule in-tree, this should be maintained in its own library package. so far, there have not been releases of libjaylink, and soversion is at 0.0.0, but upstream is planning on doing regular releases. cc'ing openocd maintainers because you might want to take interest in this; i'll happily hand it over to you or otherwise collaborate if you want to maintain this tightly with openocd. signature.asc Description: PGP signature
Bug#824135: [ftp.debian.org] override: opengrm-ngram/section
Package: ftp.debian.org Severity: normal Hi to all, is it possible to move opengrm-ngram package from section text to section science? The section science seems more appropriate for the package and Section field has thus be changed accordingly with latest upload. Thank you, Giulio signature.asc Description: OpenPGP digital signature
Bug#824134: [libtachyon-serial-0] OpenMPI in the description of libtachyon-serial
Package: libtachyon-serial-0 Version: 0.99~b6+dsx-4 Severity: minor Tags: patch Dear maintainer, I'm afraid that the description of this package is little bit wrong. (OpenMPI in libtachyon-serial-0) Here I attach a patch to fix it. I hope it helps you. Regards, Katsuhiko --- a/debian/control 09:56:42.0 +0900 +++ b/debian/control 02:24:12.824988151 +0900 @@ -46,7 +46,7 @@ animation and scientific visualization tasks. . This package provides the shared library required to run third party - program compiled against the tachyon C library built against OpenMPI. + program compiled against the tachyon C library built for serial platforms. To compile your own programs you also need to install the concomitant libtachyon-serial-0-dev package. signature.asc Description: PGP signature
Bug#823898: Pending fixes for bugs in the libconfig-model-systemd-perl package
tag 823898 + pending thanks Some bugs in the libconfig-model-systemd-perl package are closed in revision f2bd6b8d389ebf7e1467e4fb9c59c5695b620689 in branch 'master' by Dominique Dumont The full diff can be seen at https://anonscm.debian.org/cgit/pkg-perl/packages/libconfig-model-systemd-perl.git/commit/?id=f2bd6b8 Commit message: control: improved description (Closes: #823898) Thanks to Beatrice and Justin for the suggestions
Bug#824133: No longer works at all. Cannot type one single word of Chinese any more
Package: scim-chewing Version: 0.5.0-1 Severity: grave CTRL-SPACE no longer brings up the box that shows what characters I am typing. Had to downgrade to 0.3.5-2 . config Description: my config -- System Information: Debian Release: stretch/sid APT prefers experimental APT policy: (990, 'experimental'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 4.5.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages scim-chewing depends on: ii libatk1.0-0 2.20.0-1 ii libc62.23-0experimental2 ii libcairo-gobject21.14.6-1+b1 ii libcairo21.14.6-1+b1 ii libchewing3 0.5.0-1 ii libgcc1 1:6.1.1-3 ii libgdk-pixbuf2.0-0 2.34.0-1 ii libglib2.0-0 2.48.1-1 ii libgtk-3-0 3.20.4-1 ii libpango-1.0-0 1.40.1-1 ii libpangocairo-1.0-0 1.40.1-1 ii libscim8v5 1.4.16-1 ii libstdc++6 6.1.1-3 ii scim 1.4.16-1 Versions of packages scim-chewing recommends: pn ttf-arphic-uming scim-chewing suggests no packages. -- no debconf information
Bug#823377: New upstream release in SVN
Hello Osamu, Thanks for the bug report and the notification that the SVN repo is actually being updated, I must confess that I had not noticed. As you've observed, there's really not much that needs to be done to this package, although of course I should take a look at some of the old tickets against it. I welcome careful NMUs, but please do not try to hijack the package. I will try to make some time to look at it, but as I say, you're welcome to help out with NMUs. Rene On Wed, May 04, 2016 at 12:54:42PM +0900, Osamu Aoki wrote: > This upstream has not released the tarball recently from 2008 but he is still > actively updating code in the SVN repo. > > In his svn repo started 2009 as r1, now it is r334 in 2016. > svn checkout svn://svn.code.sf.net/p/mapivi/code/ mapivi-code (SF web site > info) > git svn clone svn://svn.code.sf.net/p/mapivi/code/ mapivi-code (This works > better) > https://sourceforge.net/projects/mapivi/ > https://sourceforge.net/p/mapivi/code/commit_browser > > This is one of a few GUI interface tool to batch adjust the internal > EXIF time stamp with fixed time difference which is quite convenient > when you realize your picture files have wrong time stamp inside. This > is important if you have multiple camera and if you want to match > time line properly. > > (FYI: phatch was suppose to have similar capability but it is not > working in Debian now and I tried to port FEDORA patches but there were > still some problems. Also its real upstream is non-active. So I think > it is not worth spending time on my time. Writing script with jhread > etc., is a bit cumbersome.) > > So it is a good idea to bring this tool up to date by packaging the > updated upstream code. > > If no one objects, I may hijack this when I find some time :-) > The maintainer is not touching this package for 8 years. > > It's amazing how stable this software is with just one NMU to fix a Perl > oddity change. > > There are only 3 bugs which are easy to be addressed: > > #592945 mapivi: the add coment and edit comment windows do not have any > buttons > --> "Add comment" seems OK > --> "Edit comment" does not open .. ??? > --> Probably fixed in upstream by now ??? > #796376 mapivi: please make the build reproducible > --> patch available in BTS > #675948 mapivi: Doesn't appear in the XFCE menu > --> Its problem for Gnome/KDE too > --> Just add a desktop file if upstream has not > > #NOT_REPORTED > --> Probably fixed in upstream by now ??? > --> Upstream comment says v1.1 so naming upstream version like 1.0.r??? > should be OK > --> Does not return to the shell prompt upon exit sometimes ??? (needs to be > checked) > --> Missing usable watch file > --> Strange console outputs: > --- > | $ mapivi > | > | Mapivi 0.9.7 - Martin's Picture Viewer and Organizer > | Copyright (C) 2002 - 2008 Martin Herrmann > | Mapivi comes with ABSOLUTELY NO WARRANTY. > | This is free software, and you are welcome to redistribute > | it under certain conditions. > | > | XS_Tk__Callback_Call error:not a Tk object > | Tk::die_with_trace at > /usr/lib/x86_64-linux-gnu/perl5/5.22/Tk/ProgressBar.pm line 101 > | Tk::ProgressBar::_arrange at > /usr/lib/x86_64-linux-gnu/perl5/5.22/Tk/After.pm line 90 > | (eval) at /usr/lib/x86_64-linux-gnu/perl5/5.22/Tk/After.pm line 90 > | Tk::After::once at /usr/lib/x86_64-linux-gnu/perl5/5.22/Tk/Widget.pm line > 1006 > | (eval) at /usr/lib/x86_64-linux-gnu/perl5/5.22/Tk/Widget.pm line 1006 > | Tk::Widget::waitVariable at /usr/bin/mapivi line 12836 > | main::checkDialog at /usr/bin/mapivi line 5023 > | main::makeDir at /usr/bin/mapivi line 3068 > | main::generateThumbs at /usr/bin/mapivi line 15552 > | main::updateThumbs at /usr/bin/mapivi line 2096 > | main::startup at /usr/bin/mapivi line 1606 > | > | XS_Tk__Callback_Call error:not a Tk object > | Tk::die_with_trace at > /usr/lib/x86_64-linux-gnu/perl5/5.22/Tk/ProgressBar.pm line 101 > | Tk::ProgressBar::_arrange at > /usr/lib/x86_64-linux-gnu/perl5/5.22/Tk/After.pm line 90 > | (eval) at /usr/lib/x86_64-linux-gnu/perl5/5.22/Tk/After.pm line 90 > | Tk::After::once at /usr/lib/x86_64-linux-gnu/perl5/5.22/Tk/Widget.pm line > 1006 > | (eval) at /usr/lib/x86_64-linux-gnu/perl5/5.22/Tk/Widget.pm line 1006 > | Tk::Widget::waitVariable at /usr/bin/mapivi line 12836 > | main::checkDialog at /usr/bin/mapivi line 5023 > | main::makeDir at /usr/bin/mapivi line 3068 > | main::generateThumbs at /usr/bin/mapivi line 15552 > | main::updateThumbs at /usr/bin/mapivi line 2096 > | main::startup at /usr/bin/mapivi line 1606 > | > | ^C > | $ mapivi > | > | Mapivi 0.9.7 - Martin's Picture Viewer and Organizer > | Copyright (C) 2002 - 2008 Martin Herrmann > | Mapivi comes with ABSOLUTELY NO WARRANTY. > | This is free software, and you are welcome to redistribute > | it under certain conditions. > | > | Use of uninitialized value $
Bug#799227: Block 799227 by 800163
block 799227 by 800163 thanks -- "Le mieux est l'ennemi du bien" - Voltaire
Bug#787424: emacs24: improve reproducibility: please order hashes when generating .el files
Control: tags -1 + patch
Hi.
On Mon, 01 Jun 2015 11:44:06 -0400 Daniel Kahn Gillmor
wrote:
> One example can be seen in the difference in
> /usr/share/emacs/24.4/lisp/finder-inf.el from here:
>
> https://reproducible.debian.net/dbd/unstable/amd64/emacs24_24.4+1-5.debbindiff.html
>
> compare the list after "convenience" here, which sorts the first 13
> items differently on each build:
This difference is coming from the Makefile, which passes file names in
a non-reproducible order to finder-compile-keywords-make-dist, which
itself seem to me reproducible.
The attached patch sorts the filenames before passing them to
finder-compile-keywords-make-dist, and fixes this non-reproductible
behavior in my experimental toolchain [1].
Regards,
Alexis Bienvenüe.
[1] https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
Description: Sort files in $wins
lisp/Makefile.in: sort files in the $wins variable, to make the build
reproducible.
Author: Alexis Bienvenüe
Bug-Debian: https://bugs.debian.org/787424
Index: emacs24-24.5+1/lisp/Makefile.in
===
--- emacs24-24.5+1.orig/lisp/Makefile.in
+++ emacs24-24.5+1/lisp/Makefile.in
@@ -110,14 +110,14 @@ COMPILE_FIRST = \
emacs = EMACSLOADPATH= '$(EMACS)' $(EMACSOPT)
# Common command to find subdirectories
-setwins=for file in `find . -type d -print`; do \
+setwins=for file in `find . -type d -print | LC_ALL=C sort`; do \
case $$file in */.* ) ;; \
*) wins="$$wins$${wins:+ }$$file" ;; \
esac; \
done
# Find all subdirectories except `obsolete' and `term'.
-setwins_almost=for file in `find ${srcdir} -type d -print`; do \
+setwins_almost=for file in `find ${srcdir} -type d -print | LC_ALL=C sort`; do \
case $$file in ${srcdir}*/obsolete | ${srcdir}*/term ) ;; \
*) wins="$$wins$${wins:+ }$$file" ;; \
esac; \
@@ -126,14 +126,14 @@ setwins_almost=for file in `find ${srcdi
# Find all subdirectories except `obsolete', `term', and `leim' (and subdirs).
# We don't want the leim files listed as packages, especially
# since many share basenames with files in language/.
-setwins_finder=for file in `find ${srcdir} -type d -print`; do \
+setwins_finder=for file in `find ${srcdir} -type d -print | LC_ALL=C sort`; do \
case $$file in ${srcdir}*/obsolete | ${srcdir}*/term | ${srcdir}*/leim* ) ;; \
*) wins="$$wins$${wins:+ }$$file" ;; \
esac; \
done
# Find all subdirectories in which we might want to create subdirs.el.
-setwins_for_subdirs=for file in `find ${srcdir} -type d -print`; do \
+setwins_for_subdirs=for file in `find ${srcdir} -type d -print | LC_ALL=C sort`; do \
case $$file in \
${srcdir}*/cedet* | ${srcdir}*/leim* ) ;; \
*) wins="$$wins$${wins:+ }$$file" ;; \
