Bug#762464: RFS: fyba/4.1.1-1 [ITP]
Hi, I'm attaching this thread to the bug report for future reference. Thanks to both you. I'm still a bit puzzled about the shlibs/symbols issue, though. 1. d/control: - Change DH level from 9.0.0 to 9. I must have done this by mistake on auto-pilot! I've changed it to 9.0.0 now. No, no... 9! :-) Ooops, the worst thing is that I did not do it on purpose this time either! There must be some kind of automatic spelling correction haunting me. :) Regards, Ruben 2014-09-26 1:29 GMT+02:00 Eriberto eribe...@eriberto.pro.br: 2014-09-25 17:40 GMT-03:00 Ruben Undheim ruben.undh...@gmail.com: Hi Eriberto, Hi Ruben! Thank you very much for spending your valuable time and reviewing yet another package! I am glad to help you. 1. d/control: - Change DH level from 9.0.0 to 9. I must have done this by mistake on auto-pilot! I've changed it to 9.0.0 now. No, no... 9! :-) 2. You have Lintian messages: I: libfyba0: no-symbols-control-file usr/lib/x86_64-linux-gnu/libfygm.so.0.0.0 I: libfyba0: no-symbols-control-file usr/lib/x86_64-linux-gnu/libfyut.so.0.0.0 I: libfyba0: no-symbols-control-file usr/lib/x86_64-linux-gnu/libfyba.so.0.0.0 After the debuild command you need generate symbols[1] using this command in upstream place: dpkg-gensymbols -v4.1.1 -plibfyba0 -Odebian/libfyba0.symbols [1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-providing-symbols Actually I did generate a symbol file first, but when I tried to build it on another computer, I got into trouble, and then I found something online that for C++ libraries (which FYBA is), shlibs files are recommended instead and I added an shlibs file instead - and then removed the symbols file. There is something wrong because we have a valid Lintian message. 3. The blhc command show some issues: blhc --all fyba_4.1.1-1_amd64.build To fix it, in d/rules, change from export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed to export DEB_BUILD_MAINT_OPTIONS = hardening=+all Hardening seems to have been applied correctly afterwards: ruben@debianmaskin:~/devel/deb_fyba@ hardening-check /usr/lib/x86_64-linux-gnu/libfyba.so.0.0.0 /usr/lib/x86_64-linux-gnu/libfyba.so.0.0.0: Position Independent Executable: no, regular shared library (ignored) Stack protected: yes Fortify Source functions: yes (some protected functions found) Read-only relocations: yes Immediate binding: no, not found! and I believe this is because debhelper version 9 does this automatically as long as CPPFLAGS, CFLAGS and LDFLAGS are passed down correctly. Let me know if I've misunderstood. DH9 passes the basic flags only. It seems like Steffen Möller already uploaded the package, so probably you don't have to do so much more this time! It was strange for me but I think that was a little mistake. No problem. At least I managed to do it with much less issues this time than with gnuais! (the last package you sponsored for me) Good! You will improve your skill package by package. Congratulations! I really appreciate that you gave the package some attention. You are welcome. Thanks for your work. Cheers, Eriberto -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762863: when using systemd laptop-mode-tools causes read-only root and system is unusable
Control: severity -1 normal Control: tag -1 +moreinfo Wow... A bug with severity serious and no information at all. On Friday 26 September 2014 12:25 AM, Gianluigi Tiesi wrote: Package: laptop-mode-tools Severity: serious Hi, if I use systemd and I'm on battery, my system starts with a read only root and half of the services are not working. I am using systemd along with laptop-mode-tools for some time now, with no issues so far. Please provide more information -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention.
Bug#762890: [Pkg-anonymity-tools] Bug#762890: onionshare: use the default Tor control settings
On 09/26/2014 12:06 AM, Paul Wise wrote: OnionShare should use the default control settings for the Debian tor: Unfortunately OnionShare doesn't work with the system tor without changing a bunch of stuff around, due to limitations in tor. Instead it's recommended that you install Tor Browser Bundle (perhaps using the torbrowser-launcher Debian package) and run it before running OnionShare. When you connect to the control port, you start a hidden service by setting the values HiddenServiceDir and HiddenServicePort. The control port doesn't respond with the .onion address, which is an important thing to know. The only way to learn that is to look in HiddenServiceDir for a file called hostname and read its contents. If you're using a system tor, that file is only readable by the debian-tor user, which means an unprivileged user can't learn the .onion address. Also (at least I believe) in the default Debian torrc file the control port isn't enabled. So users would have to edit their torrc before being able to use OnionShare. If the user has Tor Browser open, it will be running its own separate Tor process as the current user. So when it writes a hostname file to HiddenServiceDir, that file is readable by the current user. One potential option to help this problem would be to make tor a dependency of onionshare, and have OnionShare launch its own tor process (independent of the system tor process) for starting a hidden service. -- Micah Lee -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762902: python-lldb-3.4 and lldb-3.3: error when trying to install together
Package: lldb-3.3,python-lldb-3.4 Version: lldb-3.3/1:3.3-16 Version: python-lldb-3.4/1:3.4.2-9 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Date: 2014-09-26 Architecture: amd64 Distribution: sid Hi, automatic installation tests of packages that share a file and at the same time do not conflict by their package dependency relationships has detected the following problem: Selecting previously unselected package libdb5.3:amd64. (Reading database ... 10877 files and directories currently installed.) Preparing to unpack .../libdb5.3_5.3.28-6_amd64.deb ... Unpacking libdb5.3:amd64 (5.3.28-6) ... Selecting previously unselected package libbsd0:amd64. Preparing to unpack .../libbsd0_0.7.0-2_amd64.deb ... Unpacking libbsd0:amd64 (0.7.0-2) ... Selecting previously unselected package libedit2:amd64. Preparing to unpack .../libedit2_3.1-20140620-2_amd64.deb ... Unpacking libedit2:amd64 (3.1-20140620-2) ... Selecting previously unselected package libgmp10:amd64. Preparing to unpack .../libgmp10_2%3a6.0.0+dfsg-6_amd64.deb ... Unpacking libgmp10:amd64 (2:6.0.0+dfsg-6) ... Selecting previously unselected package libisl10:amd64. Preparing to unpack .../libisl10_0.12.2-2_amd64.deb ... Unpacking libisl10:amd64 (0.12.2-2) ... Selecting previously unselected package libcloog-isl4:amd64. Preparing to unpack .../libcloog-isl4_0.18.2-1_amd64.deb ... Unpacking libcloog-isl4:amd64 (0.18.2-1) ... Selecting previously unselected package libexpat1:amd64. Preparing to unpack .../libexpat1_2.1.0-6_amd64.deb ... Unpacking libexpat1:amd64 (2.1.0-6) ... Selecting previously unselected package libffi6:amd64. Preparing to unpack .../libffi6_3.1-2_amd64.deb ... Unpacking libffi6:amd64 (3.1-2) ... Selecting previously unselected package libllvm3.3:amd64. Preparing to unpack .../libllvm3.3_1%3a3.3-16_amd64.deb ... Unpacking libllvm3.3:amd64 (1:3.3-16) ... Selecting previously unselected package libpython2.7-minimal:amd64. Preparing to unpack .../libpython2.7-minimal_2.7.8-7_amd64.deb ... Unpacking libpython2.7-minimal:amd64 (2.7.8-7) ... Selecting previously unselected package mime-support. Preparing to unpack .../mime-support_3.56_all.deb ... Unpacking mime-support (3.56) ... Selecting previously unselected package libpython2.7-stdlib:amd64. Preparing to unpack .../libpython2.7-stdlib_2.7.8-7_amd64.deb ... Unpacking libpython2.7-stdlib:amd64 (2.7.8-7) ... Selecting previously unselected package libpython2.7:amd64. Preparing to unpack .../libpython2.7_2.7.8-7_amd64.deb ... Unpacking libpython2.7:amd64 (2.7.8-7) ... Selecting previously unselected package python2.7-minimal. Preparing to unpack .../python2.7-minimal_2.7.8-7_amd64.deb ... Unpacking python2.7-minimal (2.7.8-7) ... Selecting previously unselected package python2.7. Preparing to unpack .../python2.7_2.7.8-7_amd64.deb ... Unpacking python2.7 (2.7.8-7) ... Selecting previously unselected package python-minimal. Preparing to unpack .../python-minimal_2.7.8-1_amd64.deb ... Unpacking python-minimal (2.7.8-1) ... Selecting previously unselected package libpython-stdlib:amd64. Preparing to unpack .../libpython-stdlib_2.7.8-1_amd64.deb ... Unpacking libpython-stdlib:amd64 (2.7.8-1) ... Selecting previously unselected package python. Preparing to unpack .../python_2.7.8-1_amd64.deb ... Unpacking python (2.7.8-1) ... Selecting previously unselected package libjsoncpp0. Preparing to unpack .../libjsoncpp0_0.6.0~rc2-3_amd64.deb ... Unpacking libjsoncpp0 (0.6.0~rc2-3) ... Selecting previously unselected package libffi-dev:amd64. Preparing to unpack .../libffi-dev_3.1-2_amd64.deb ... Unpacking libffi-dev:amd64 (3.1-2) ... Selecting previously unselected package binfmt-support. Preparing to unpack .../binfmt-support_2.1.5-1_amd64.deb ... Unpacking binfmt-support (2.1.5-1) ... Selecting previously unselected package llvm-3.3-runtime. Preparing to unpack .../llvm-3.3-runtime_1%3a3.3-16_amd64.deb ... Unpacking llvm-3.3-runtime (1:3.3-16) ... Selecting previously unselected package llvm-3.3. Preparing to unpack .../llvm-3.3_1%3a3.3-16_amd64.deb ... Unpacking llvm-3.3 (1:3.3-16) ... Selecting previously unselected package llvm-3.3-dev. Preparing to unpack .../llvm-3.3-dev_1%3a3.3-16_amd64.deb ... Unpacking llvm-3.3-dev (1:3.3-16) ... Selecting previously unselected package lldb-3.3. Preparing to unpack .../lldb-3.3_1%3a3.3-16_amd64.deb ... Unpacking lldb-3.3 (1:3.3-16) ... Selecting previously unselected package python-lldb-3.4. Preparing to unpack .../python-lldb-3.4_1%3a3.4.2-9_amd64.deb ... Unpacking python-lldb-3.4 (1:3.4.2-9) ... dpkg: error processing archive /var/cache/apt/archives/python-lldb-3.4_1%3a3.4.2-9_amd64.deb (--unpack): trying to overwrite '/usr/lib/python2.7/dist-packages/lldb/utils/symbolication.py', which is also in package lldb-3.3 1:3.3-16 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Processing triggers for man-db (2.7.0.1-1) ... Processing triggers for install-info (5.2.0.dfsg.1-4) ... Errors were encountered while
Bug#762901: python-clang-3.6 and python-clang-3.5: error when trying to install together
Package: python-clang-3.5,python-clang-3.6 Version: python-clang-3.5/1:3.5-2 Version: python-clang-3.6/1:3.6~svn218446-1 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Date: 2014-09-26 Architecture: amd64 Distribution: sid Hi, automatic installation tests of packages that share a file and at the same time do not conflict by their package dependency relationships has detected the following problem: Selecting previously unselected package libdb5.3:amd64. (Reading database ... 10877 files and directories currently installed.) Preparing to unpack .../libdb5.3_5.3.28-6_amd64.deb ... Unpacking libdb5.3:amd64 (5.3.28-6) ... Selecting previously unselected package libexpat1:amd64. Preparing to unpack .../libexpat1_2.1.0-6_amd64.deb ... Unpacking libexpat1:amd64 (2.1.0-6) ... Selecting previously unselected package libffi6:amd64. Preparing to unpack .../libffi6_3.1-2_amd64.deb ... Unpacking libffi6:amd64 (3.1-2) ... Selecting previously unselected package libpython2.7-minimal:amd64. Preparing to unpack .../libpython2.7-minimal_2.7.8-7_amd64.deb ... Unpacking libpython2.7-minimal:amd64 (2.7.8-7) ... Selecting previously unselected package python2.7-minimal. Preparing to unpack .../python2.7-minimal_2.7.8-7_amd64.deb ... Unpacking python2.7-minimal (2.7.8-7) ... Selecting previously unselected package mime-support. Preparing to unpack .../mime-support_3.56_all.deb ... Unpacking mime-support (3.56) ... Selecting previously unselected package libpython2.7-stdlib:amd64. Preparing to unpack .../libpython2.7-stdlib_2.7.8-7_amd64.deb ... Unpacking libpython2.7-stdlib:amd64 (2.7.8-7) ... Selecting previously unselected package python2.7. Preparing to unpack .../python2.7_2.7.8-7_amd64.deb ... Unpacking python2.7 (2.7.8-7) ... Selecting previously unselected package python-minimal. Preparing to unpack .../python-minimal_2.7.8-1_amd64.deb ... Unpacking python-minimal (2.7.8-1) ... Selecting previously unselected package libpython-stdlib:amd64. Preparing to unpack .../libpython-stdlib_2.7.8-1_amd64.deb ... Unpacking libpython-stdlib:amd64 (2.7.8-1) ... Selecting previously unselected package python. Preparing to unpack .../python_2.7.8-1_amd64.deb ... Unpacking python (2.7.8-1) ... Selecting previously unselected package python-clang-3.5. Preparing to unpack .../python-clang-3.5_1%3a3.5-2_amd64.deb ... Unpacking python-clang-3.5 (1:3.5-2) ... Selecting previously unselected package python-clang-3.6. Preparing to unpack .../python-clang-3.6_1%3a3.6~svn218446-1_amd64.deb ... Unpacking python-clang-3.6 (1:3.6~svn218446-1) ... dpkg: error processing archive /var/cache/apt/archives/python-clang-3.6_1%3a3.6~svn218446-1_amd64.deb (--unpack): trying to overwrite '/usr/lib/python2.7/dist-packages/clang/enumerations.py', which is also in package python-clang-3.5 1:3.5-2 Processing triggers for man-db (2.7.0.1-1) ... Errors were encountered while processing: /var/cache/apt/archives/python-clang-3.6_1%3a3.6~svn218446-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) This is a serious bug as it makes installation fail, and violates sections 7.6.1 and 10.1 of the policy. An optimal solution would consist in only one of the packages installing that file, and renaming or removing the file in the other package. Depending on the circumstances you might also consider Replace relations or file diversions. If the conflicting situation cannot be resolved then, as a last resort, the two packages have to declare a mutual Conflict. Please take into account that Replaces, Conflicts and diversions should only be used when packages provide different implementations for the same functionality. Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): /usr/lib/python2.7/dist-packages/clang/__init__.py /usr/lib/python2.7/dist-packages/clang/cindex.py /usr/lib/python2.7/dist-packages/clang/enumerations.py This bug has been filed against both packages. If you, the maintainers of the two packages in question, have agreed on which of the packages will resolve the problem please reassign the bug to that package. You may then also register in the BTS that the other package is affected by the bug. -Ralf. PS: for more information about the detection of file overwrite errors of this kind see http://edos.debian.net/file-overwrites/. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762903: icedove: self-signed certificate accept modal dialog opens many time
Package: icedove Version: 31.0-3 Severity: minor Dear Maintainer, * What led up to the situation? imap server certificate was replaced with new one (self-signed) * What exactly did you do (or not do) that was effective (or ineffective)? icedove was running some time without being used, trying to fetch new messages. Every attempt caused new request to confirm certificate acceptance. Subsequent requests were not cancelled after first (with accept permanently). * What was the outcome of this action? Modal dialog window blocks application and every accept or cancel just started those fancy gnome close- and open-window animations. With modal, application was blocked. I had to press button (ok, ESC works too but that's irrelevant) on every dialog even that certificate was already accepted. * What outcome did you expect instead? Show this dialog only once, in this case probably cancel fetch attempt is request for user action with same parameters is already started. Probably also cancel started request(s) if it becomes invalid (eg: two certificate changes - invalidate first request and replace it with new, if necessary) -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-686-pae (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages icedove depends on: ii debianutils 4.4 ii fontconfig2.11.0-6.1 ii libasound21.0.28-1 ii libatk1.0-0 2.12.0-1 ii libc6 2.19-11 ii libcairo2 1.12.16-5 ii libdbus-1-3 1.8.6-2 ii libdbus-glib-1-2 0.102-1 ii libevent-2.0-52.0.21-stable-1.1 ii libffi6 3.1-2 ii libfontconfig12.11.0-6.1 ii libfreetype6 2.5.2-2 ii libgcc1 1:4.9.1-14 ii libgdk-pixbuf2.0-02.30.8-1 ii libglib2.0-0 2.40.0-5 ii libgtk2.0-0 2.24.24-1 ii libhunspell-1.3-0 1.3.3-2 ii libnspr4 2:4.10.7-1 ii libnss3 2:3.17-1 ii libpango-1.0-01.36.7-1 ii libpangocairo-1.0-0 1.36.7-1 ii libpangoft2-1.0-0 1.36.7-1 ii libpixman-1-0 0.32.6-3 ii libsqlite3-0 3.8.6-1 ii libstartup-notification0 0.12-4 ii libstdc++64.9.1-14 ii libvpx1 1.3.0-2.1 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.2-1 ii libxrender1 1:0.9.8-1 ii libxt61:1.1.4-1 ii psmisc22.21-2 ii zlib1g1:1.2.8.dfsg-2 Versions of packages icedove recommends: ii myspell-en-us [myspell-dictionary] 1:3.3.0-4 Versions of packages icedove suggests: ii fonts-lyx 2.0.6-1 ii libgssapi-krb5-2 1.12.1+dfsg-9 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759956: possible graphicsmagick regression?
Hi Bob, I got a report that drawtiming can't build[1] with newer GraphicsMagick versions. The exact error is: caught Magick++ exception: Magick: Non-conforming drawing primitive definition (text) reported by magick/render.c:3022 (DrawImage) If the following change is made to memory.txt in drawimage then it works. -- cut -- -CS1 = 0, OE = 0, ADDR = . -OE -tOE DATA = ; +CS1 = 0, OE = 0, ADDR = . +OE -tOE DATA = ; -- cut -- Can it be a regression in GraphicsMagick or may be caused by something else? Regards, Laszlo/GCS [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759956 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762890: [Pkg-anonymity-tools] Bug#762890: onionshare: use the default Tor control settings
On Fri, 2014-09-26 at 06:33 +, Micah Lee wrote: Unfortunately OnionShare doesn't work with the system tor without changing a bunch of stuff around, due to limitations in tor. Instead it's recommended that you install Tor Browser Bundle (perhaps using the torbrowser-launcher Debian package) and run it before running OnionShare. torbrowser-launcher is not working right now (#758935) so I can't do that but it sounds like OnionShare needs moving to contrib if it relies on torbrowser-launcher. When you connect to the control port, you start a hidden service by setting the values HiddenServiceDir and HiddenServicePort. The control port doesn't respond with the .onion address, which is an important thing to know. The only way to learn that is to look in HiddenServiceDir for a file called hostname and read its contents. If you're using a system tor, that file is only readable by the debian-tor user, which means an unprivileged user can't learn the .onion address. My user is in the debian-tor group so it should be able to read that. Also (at least I believe) in the default Debian torrc file the control port isn't enabled. So users would have to edit their torrc before being able to use OnionShare. The control socket is enabled, is the control port different to that? One potential option to help this problem would be to make tor a dependency of onionshare, and have OnionShare launch its own tor process (independent of the system tor process) for starting a hidden service. That sounds like a reasonable idea to me. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#540785: claws-mail: Cache problems with folders whose names are purely numeric
Control: tags -1 fixed-upstream On Thu, Sep 25, 2014 at 02:45:53AM +0200, Paul Sommer wrote: Another two years later: The error still exists at my claws-mail Ver. 3.9.3 64 bit. That's pretty poor. Think it's time to change my mail client if an error stays unfixed for five years :( I wonder that nobody else encountered that problem. Well, seems this has been fixed recently in git :-) Can you try with debian packages built from git? See http://hydra.debian.net Thanks in advance, -- Ricardo Mones ~ RTFM - Read The Manual (The 'F' is silent). Usually a very good idea. Bjarne Stroustrup signature.asc Description: Digital signature
Bug#762839: bash without importing shell functions from the environment
Nikolaus Rath, le Thu 25 Sep 2014 17:26:40 -0700, a écrit : Samuel Thibault sthiba...@debian.org writes: Matthias Urlichs, le Thu 25 Sep 2014 21:17:58 +0200, a écrit : Samuel Thibault: Sounds crazy to me. Definitely. This is now out in the wild; exploits which simply replace echo or cat-without-/bin are going to happen. :-/ That's not so easy to exploit. You have to manage to inject those precise variable names. Wasn't there some web server that used to put query script variables into the environment of the CGI script? Well, that ought to have been fixed a long time ago already, otherwise you could have injected all sorts of LD_*. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762904: munin-plugins-core: Postgresql plugin fails to find version and exits
Package: munin-plugins-core Version: 2.0.21-2 Severity: normal Dear Maintainer, All Postgresql graphs generate an error since a recent upgrade of PostgreSQL. The munin-nonde.log file reads: 2014/09/26-08:50:09 [29076] Error output from postgres_autovacuum: 2014/09/26-08:50:09 [29076] Unable to detect PostgreSQL version 2014/09/26-08:50:09 [29076] Service 'postgres_autovacuum' exited with status 255/0. 2014/09/26-08:50:10 [29076] Error output from postgres_autovacuum: 2014/09/26-08:50:10 [29076] Unable to detect PostgreSQL version 2014/09/26-08:50:10 [29076] Service 'postgres_autovacuum' exited with status 255/0. 2014/09/26-08:50:12 [29076] Error output from postgres_locks_ALL: 2014/09/26-08:50:12 [29076] Unable to detect PostgreSQL version 2014/09/26-08:50:12 [29076] Service 'postgres_locks_ALL' exited with status 255/0. 2014/09/26-08:50:13 [29076] Error output from postgres_locks_ALL: 2014/09/26-08:50:13 [29076] Unable to detect PostgreSQL version 2014/09/26-08:50:13 [29076] Service 'postgres_locks_ALL' exited with status 255/0. 2014/09/26-08:50:30 [29076] Error output from postgres_xlog: 2014/09/26-08:50:30 [29076] Unable to detect PostgreSQL version 2014/09/26-08:50:30 [29076] Service 'postgres_xlog' exited with status 255/0. 2014/09/26-08:50:31 [29076] Error output from postgres_xlog: 2014/09/26-08:50:31 [29076] Unable to detect PostgreSQL version 2014/09/26-08:50:31 [29076] Service 'postgres_xlog' exited with status 255/0. [snip] The blog entry http://cosmicb.no/2013/02/ provided the solution, which is that the plugin fails to detect PostgreSQL version. I checked the output directly for psql and got this: postgres@b3:~$ psql psql (9.4beta2) Type help for help. postgres=# select version(); version - PostgreSQL 9.4beta2 on armv7l-unknown-linux-gnueabi, compiled by gcc (Debian 4.9.1-5) 4.9.1, 32-bit (1 row) postgres=# Looking in /usr/share/perl5/Munin/Plugin/Pgsql.pm, the regexp for the version number extraction is /^PostgreSQL (\d+)\.(\d+)(\.\d+|devel)\b/. This implies that regular numbers or even an added devel would be recognized versions, but 9.4beta2 is not, due to the beta. Fixing the regular expression by adding an thris alternative with beta and some numbers afterwards solves the problem (see patch). -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (980, 'stable-updates'), (980, 'stable'), (90, 'experimental') Architecture: armel (armv5tel) Kernel: Linux 3.2.62-1 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages munin-plugins-core depends on: ii munin-common 2.0.21-2 ii perl 5.20.0-6 Versions of packages munin-plugins-core recommends: ii libnet-snmp-perl 6.0.1-2 Versions of packages munin-plugins-core suggests: pn conntracknone pn libnet-netmask-perl none pn libnet-telnet-perl none ii libxml-parser-perl 2.41-3 ii python 2.7.8-1 pn ruby | ruby-interpreter none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734599: Please help with Java lib
On 09/25/2014 10:19 PM, Andreas Tille wrote: Hi Debian Java folks, it seems there is no real progress in this issue. Do you have any hint what to do. BTW (as in other cases): if you prefer maintaining libsnappy-java in Debian Java team I'd happily move the packaging into your Git repository. From my last post, I think that issue is (after patch is applied) that snappy lib is too old. Seems that Java lib is using a more recent version: SnappyTests Exception in thread main java.lang.UnsatisfiedLinkError: org.xerial.snappy.SnappyNative.maxCompressedLength(I)I at org.xerial.snappy.SnappyNative.maxCompressedLength(Native Method) at org.xerial.snappy.Snappy.maxCompressedLength(Snappy.java:316) at org.xerial.snappy.Snappy.rawCompress(Snappy.java:329) at org.xerial.snappy.Snappy.compress(Snappy.java:88) at SnappyTests.main(SnappyTests.java:12) Tje maxCompressedLength sould be available in a new version Olivier Kind regards Andreas. -- Olivier Sallou IRISA / University of Rennes 1 Campus de Beaulieu, 35000 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#762905: transition: openjpeg2 2.1.0
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I am reading the cruft report: https://ftp-master.debian.org/cruft-report-daily.txt [...] * source package openjpeg2 version 2.1.0-1 no longer builds binary package(s): libopenjp3d6 libopenjpeg6 libopenjpeg6-dbg libopenjpeg6-dev libopenjpip6 openjp3d-tools on amd64,armel,armhf,i386,kfreebsd-amd64,kfreebsd-i386,mipsel,powerpc,ppc64el,s390x,sparc - suggested command: dak rm -m [auto-cruft] NBS (no longer built by openjpeg2) -s unstable -a amd64,armel,armhf,i386,kfreebsd-amd64,kfreebsd-i386,mipsel,powerpc,ppc64el,s390x,sparc -p -R -b libopenjp3d6 libopenjpeg6 libopenjpeg6-dbg libopenjpeg6-dev libopenjpip6 openjp3d-tools - broken Depends: openjpeg2: openjpeg-tools openjpip-dec-server - broken Build-Depends: leptonlib: libopenjpeg6-dev [...] The broken Build-Depends (leptonlib) is now fixed in sid. The broken Depends is a mistake, src:openjpeg2 was building binary packages using the same name as binaries from src:openjpeg. Please run the suggested dak rm command. In case that is of any use : title = openjpeg2; is_affected = .depends ~ libopenjpeg6-dev; is_bad = .depends ~ libopenjpeg6; Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735047: [Pkg-fglrx-devel] Bug#735047: Possible solution
reassign #735047 glx-alternative-fglrx thanks Am 25.09.2014 um 21:31 schrieb Alexander Kudrevatykh: I retested this patch with latest jessie updates and it helps -- Alexander Kudrevatykh alexan...@kudrevatykh.com В Срд, 24/09/2014 в 22:02 +0200, Patrick Matthäi пишет: Am 04.05.2014 um 13:19 schrieb Drill Main: I suffered from the same bug too, but I think the solution is such that: when we switch to igpu mode, original libglx.so must be restored too. At least I understood it this way after inspecting switchlibglx script from original amd driver installator. Thus the bug occured only in dpkg alternatives file /var/lib/dpkg/alternatives/glx.Thus i propose such patch: diff -ruPN a/var/lib/dpkg/alternatives/glx b/var/lib/dpkg/alternatives/glx --- a/var/lib/dpkg/alternatives/glx 2014-05-04 12:26:36.0 +0400 +++ b/var/lib/dpkg/alternatives/glx 2014-05-04 15:15:00.258850761 +0400 @@ -24,7 +24,7 @@ /usr/lib/fglrx/fglrx_drv.so /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 -/usr/lib/fglrx/fglrx-libglx.so + /usr/lib/mesa-diverted 5 After that igpu mode seems to be working properly (at least as far as I can say). Could you please retest it with the current release in jessie/sid? -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer Blog: http://www.linux-dev.org/ E-Mail: pmatth...@debian.org patr...@linux-dev.org */
Bug#762907: base-installer: Kernel version selection does not exclucde -dbg packages
Source: base-installer Severity: normal Dear Maintainer, I got asked this while working on the arm64 installer: Install the base system --- The list shows the available kernels. Please choose one of them in order to make the system bootable from the hard drive. Kernel to install: 1: linux-image-3.14-2-arm64 [*], 3: none, 2: linux-image-3.14-2-arm64-dbg, Prompt: '?' for help, default=1 And adding a simple case to the test suite shows the issue for amd64 too, I suspect all arches have this issue: diff --git a/kernel/tests/amd64/cittagazze.test b/kernel/tests/amd64/cittagazze.test index c45d9fc..90d8780 100644 --- a/kernel/tests/amd64/cittagazze.test +++ b/kernel/tests/amd64/cittagazze.test @@ -6,3 +6,5 @@ kernel-2.6 \ usable \ linux-image-amd64 \ linux-image-2.6.18-4-amd64 +unusable \ + linux-image-2.6.18-4-amd64-dbg diff --git a/kernel/tests/arm64/mustang.test b/kernel/tests/arm64/mustang.test index 330f259..80ab19f 100644 --- a/kernel/tests/arm64/mustang.test +++ b/kernel/tests/arm64/mustang.test @@ -8,3 +8,5 @@ kernel-3.10 \ usable \ linux-image-arm64 \ linux-image-3.14-1-arm64 +unusable \ + linux-image-3.14-1-arm64-dbg Leading to: $ ./runtests amd64 FAIL amd64/cittagazze.test arch_check_usable_kernel 2.6 linux-image-2.6.18-4-amd64-dbg should be unusable amd64: 8 passes, 1 failures. It seems this has been the case since -dbg packages were introduced (at least Wheezy if not sooner) so this apparently isn't causing issues in the real world (not sure why arm64 asked me that question...), so not a huge worry I don't think but filing so it doesn't get lost. Ian. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf armel Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758935: torbrowser-launcher: fails to start: exit code 127
On Thu, 2014-09-25 at 10:28 +0800, Paul Wise wrote: I'm having this issue too. I ran it with sh -x and it seems to be something to do with directory layouts. It was failing to find Tor/tor, which was causing the architecture issue. After that it couldn't find where firefox was. Anyway, I deleted these directories and it works again: /home/pabs/.local/share/torbrowser /home/pabs/.config/torbrowser /home/pabs/.cache/torbrowser -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#762906: krb5-auth-dialog: Popup show incorrect princial name (without username)
Package: krb5-auth-dialog Version: 3.12.0-1 In Debian Edu Jessie, after logging into KDE using kdm, the krb5-auth-dialog popup I get when clicking on the panel icon, show the wrong principal name. The dialog look like this: [Cancel] [Renew Ticket] @UIO.NO's Passoword: [ ] Your credentials expire in X minutes The problem is the '@UIO.NO' part, which really should read p...@uio.no. This is the output from klist for the same login: Ticket cache: FILE:/tmp/krb5cc_43502_HJgpfY Default principal: p...@uio.no Valid starting Expires Service principal 01/01/1970 01:00:00 01/01/1970 01:00:00 krbtgt/uio...@uio.no What is wrong? Could this be related to the use of libpam-tmpfile, which ensure per user temp directories? This is the output from 'env|grep tmp/|sort' in the same session, to give you an idea about the current values: DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-yh1cDIMJZP,guid=41369c362754688c12c3edb7542516b6 KRB5CCNAME=FILE:/tmp/krb5cc_43502_HJgpfY SESSION_MANAGER=local/pxe-test6-pre.uio.no:@/tmp/.ICE-unix/3827,unix/pxe-test6-pre.uio.no:/tmp/.ICE-unix/3827 SSH_AUTH_SOCK=/tmp/ssh-tO3jWoC4jygs/agent.2827 TEMPDIR=/tmp/user/43502 TEMP=/tmp/user/43502 TMPDIR=/tmp/user/43502 TMP=/tmp/user/43502 It is a bit surprising to notice that KRB5CCNAME point to /tmp/ and not /tmp/user/43502/, but I have not investigated why it is so. Please let me know if there is anything I can do to assist in debugging this issue. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762908: apache2-bin: Enable and include mod_authnz_fcgi module
Package: apache2 Version: 2.4.10-1 Severity: wishlist Dear Maintainer, I was busy preparing some of our authorization logic from Debian Wheezy's Apache 2.2 to Debian Jessie's Apache 2.4 and ran in to some problems with the fastcgi based access checker. When reading the Apache documentation for 2.4 on their site they now have a built-in mod_authnz_fcgi for this. But this module is currently not enabled in the Debian build. I couldn't find any indication whether or not this module is experimental, though nothing in the Apache documentation and configure help suggests it is. And it ties in better with the new Apache 2.4 authorization logic than mod_fcgid does. So could this module please be enabled in apache2 builds? Regards, Justin -- Package-specific info: -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages apache2 depends on: ii apache2-bin 2.4.10-1 ii apache2-data 2.4.10-1 ii lsb-base 4.1+Debian13 ii mime-support 3.56 ii perl 5.20.0-6 ii procps1:3.3.9-7 Versions of packages apache2 recommends: pn ssl-cert none Versions of packages apache2 suggests: pn apache2-doc none pn apache2-suexec-pristine | apache2-suexec-custom none pn apache2-utilsnone ii w3m [www-browser]0.5.3-17 Versions of packages apache2-bin depends on: ii libapr1 1.5.1-2+b1 ii libaprutil1 1.5.3-3 ii libaprutil1-dbd-sqlite3 1.5.3-3 ii libaprutil1-ldap 1.5.3-3 ii libc62.19-11 ii libldap-2.4-22.4.39-1.1+b1 ii liblua5.1-0 5.1.5-7 ii libpcre3 1:8.35-3 ii libssl1.0.0 1.0.1i-2 ii libxml2 2.9.1+dfsg1-4 ii perl 5.20.0-6 ii zlib1g 1:1.2.8.dfsg-2 Versions of packages apache2-bin suggests: pn apache2-doc none pn apache2-suexec-pristine | apache2-suexec-custom none ii w3m [www-browser]0.5.3-17 Versions of packages apache2 is related to: ii apache2 2.4.10-1 ii apache2-bin 2.4.10-1 -- no debconf information Binary files apache2-2.4.10.orig/.git/index and apache2-2.4.10/.git/index differ diff -urBN apache2-2.4.10.orig/debian/config-dir/mods-available/authnz_fcgi.load apache2-2.4.10/debian/config-dir/mods-available/authnz_fcgi.load --- apache2-2.4.10.orig/debian/config-dir/mods-available/authnz_fcgi.load 1970-01-01 01:00:00.0 +0100 +++ apache2-2.4.10/debian/config-dir/mods-available/authnz_fcgi.load 2014-09-26 09:02:39.190581344 +0200 @@ -0,0 +1,2 @@ +# Depends: proxy_fcgi +LoadModule authnz_fcgi_module /usr/lib/apache2/modules/mod_authnz_fcgi.so diff -urBN apache2-2.4.10.orig/debian/rules apache2-2.4.10/debian/rules --- apache2-2.4.10.orig/debian/rules 2014-09-26 09:22:31.226230405 +0200 +++ apache2-2.4.10/debian/rules 2014-09-26 09:00:21.934621283 +0200 @@ -86,7 +86,7 @@ --with-pcre=yes \ --enable-pie \ --enable-mpms-shared=all \ - --enable-mods-shared=all cgi \ + --enable-mods-shared=all cgi authnz-fcgi \ --enable-mods-static=unixd logio watchdog version \ CFLAGS=$(AP2_CFLAGS) CPPFLAGS=$(AP2_CPPFLAGS) LDFLAGS=$(AP2_LDFLAGS) \ LTFLAGS=$(AP2_LTFLAGS)
Bug#762904: patch for bug 762904
Here is a patch fixing the problem.
best regards,
Luc
--- Pgsql.pm.orig 2014-09-26 08:52:32.0 +0200
+++ Pgsql.pm 2014-09-26 08:53:09.0 +0200
@@ -478,7 +478,7 @@
my $r = $self-runquery(SELECT version());
my $v = $r-[0]-[0];
die Unable to detect PostgreSQL version\n
-unless ($v =~ /^PostgreSQL (\d+)\.(\d+)(\.\d+|devel)\b/);
+unless ($v =~ /^PostgreSQL (\d+)\.(\d+)(\.\d+|devel|beta\d+)\b/);
$self-{detected_version} = $1.$2;
}
Bug#734599: Please help with Java lib
Hi Olivier, On Fri, Sep 26, 2014 at 09:23:47AM +0200, Olivier Sallou wrote: On 09/25/2014 10:19 PM, Andreas Tille wrote: Hi Debian Java folks, it seems there is no real progress in this issue. Do you have any hint what to do. BTW (as in other cases): if you prefer maintaining libsnappy-java in Debian Java team I'd happily move the packaging into your Git repository. From my last post, I think that issue is (after patch is applied) that snappy lib is too old. Seems that Java lib is using a more recent version: SnappyTests Exception in thread main java.lang.UnsatisfiedLinkError: org.xerial.snappy.SnappyNative.maxCompressedLength(I)I at org.xerial.snappy.SnappyNative.maxCompressedLength(Native Method) at org.xerial.snappy.Snappy.maxCompressedLength(Snappy.java:316) at org.xerial.snappy.Snappy.rawCompress(Snappy.java:329) at org.xerial.snappy.Snappy.compress(Snappy.java:88) at SnappyTests.main(SnappyTests.java:12) Tje maxCompressedLength sould be available in a new version Sorry, I might miss the point of your mail. This means exactly what for the package? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762904: [Packaging] Bug#762904: munin-plugins-core: Postgresql plugin fails to find version and exits
Hi Luc, On Freitag, 26. September 2014, Luc Maisonobe wrote: All Postgresql graphs generate an error since a recent upgrade of PostgreSQL. The munin-nonde.log file reads: [...] Fixing the regular expression by adding an thris alternative with beta and some numbers afterwards solves the problem (see patch). thanks for your bug report with patch, much appreciated! Just that it seems you forgot to attach the patch... :) Could you please send it to the bug? cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#761225: subsurface is marked for autoremoval from testing
On Fri, 26 Sep 2014, Debian testing autoremoval watch wrote: subsurface 4.0.3-2.1 is marked for autoremoval from testing on 2014-10-11 It is affected by these RC bugs: 761225: subsurface: something is not right :( I do confirm that unstable: subsurface 4.2-3 libgit2-21 0.21.1-1 install and run on testing. So the bug is solved when those unstable packages migrate to testing. Cheers, -- Cristian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762904: [Packaging] Bug#762904: patch for bug 762904
control: tags -1 + patch On Freitag, 26. September 2014, Luc Maisonobe wrote: Here is a patch fixing the problem. thanks! signature.asc Description: This is a digitally signed message part.
Bug#762791: laptop-mode-tools: At boot eth0 fails
Il gio, set 25, 2014 at 04:53:13 +0530, Ritesh Raj Sarraf scrisse: On Thursday 25 September 2014 04:40 PM, Stefano Callegari wrote: If it is set to 1, you need to set it to 0, and then re-test your scenario. I think to remember to have tested it with 0 but not has seemed the solution. I'll try again but I'll say you if it's ok tomorrow morning. Thanks. I'll wait for your results. The other suspicion I have with this card family, is that they are more flaky when compared to Intel card. Previously, the other laptop had an Intel card, that used the e1000e driver. With that card, the issues were none to the best of my knowledge. Let's see what you results are. Accordingly we'll act further. No... Again this morning, the eth0 has gone up and down until I done the log in into kde. Below an example from the log: Sep 26 09:27:04 hpdv5 systemd-udevd[184]: Network interface NamePolicy= disabled on kernel commandline, ignoring. Sep 26 09:27:04 hpdv5 kernel: [ 339.688970] r8169 :03:00.0 eth0: link up Sep 26 09:27:05 hpdv5 laptop-mode: Laptop mode Sep 26 09:27:05 hpdv5 laptop-mode: enabled, active Sep 26 09:27:05 hpdv5 laptop-mode: (Data-loss sensitive features disabled.) Sep 26 09:27:05 hpdv5 systemd[1]: Starting Session c67 of user stefano. Sep 26 09:27:05 hpdv5 systemd[1]: Started Session c67 of user stefano. Sep 26 09:27:05 hpdv5 kernel: [ 340.601747] r8169 :03:00.0 eth0: link down [cut] Sep 26 09:27:08 hpdv5 kernel: [ 343.780266] r8169 :03:00.0 eth0: link up Sep 26 09:27:09 hpdv5 laptop-mode: Laptop mode Sep 26 09:27:09 hpdv5 laptop-mode: enabled, active [unchanged] Sep 26 09:27:09 hpdv5 laptop-mode: (Data-loss sensitive features disabled.) Sep 26 09:27:09 hpdv5 laptop-mode: Laptop mode Sep 26 09:27:09 hpdv5 laptop-mode: enabled, active [unchanged] Sep 26 09:27:09 hpdv5 laptop-mode: (Data-loss sensitive features disabled.) Sep 26 09:27:09 hpdv5 laptop-mode: Laptop mode Sep 26 09:27:09 hpdv5 laptop-mode: enabled, active [unchanged] Sep 26 09:27:09 hpdv5 laptop-mode: (Data-loss sensitive features disabled.) Sep 26 09:27:09 hpdv5 laptop-mode: Laptop mode Sep 26 09:27:09 hpdv5 laptop-mode: enabled, active [unchanged] Sep 26 09:27:09 hpdv5 laptop-mode: (Data-loss sensitive features disabled.) Sep 26 09:27:09 hpdv5 laptop-mode: Laptop mode Sep 26 09:27:09 hpdv5 laptop-mode: enabled, not active Sep 26 09:27:09 hpdv5 systemd[1]: Starting Session c70 of user stefano. Sep 26 09:27:09 hpdv5 systemd[1]: Started Session c70 of user stefano. Sep 26 09:27:09 hpdv5 kernel: [ 344.957705] r8169 :03:00.0 eth0: link down and ~ bash $ grep -e ^\w /etc/laptop-mode/conf.d/ethernet.conf DEBUG=0 CONTROL_ETHERNET=1 BATT_THROTTLE_ETHERNET=0 LM_AC_THROTTLE_ETHERNET=0 NOLM_AC_THROTTLE_ETHERNET=0 THROTTLE_SPEED=slowest DISABLE_WAKEUP_ON_LAN=1 ETHERNET_DEVICES=eth0 DISABLE_ETHERNET_ON_BATTERY=0 Again the LAN led on the router blinks. p.s.: The router has also Gbit and when I power on the laptop the led shows me the link at 100Mbit. PS: I intend to do a new Laptop Mode Tools release soon, to ensure it makes it before the Debian freeze. A quick turnaround will be highly appreciated. As I have say you yesterday, in a day if I reboot the laptop the eth0 hasn't this behavior anymore, so I can show the tests only tomorrow. Sorry.. Thanks -- Stefano Callegari ste...@infinito.it -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762791: laptop-mode-tools: At boot eth0 fails
Then I don't have much ideas. Perhaps you could set DEBUG=1 for this module, and then try to see what changes occur. On Fri, Sep 26, 2014 at 1:40 PM, Stefano Callegari ste...@infinito.it wrote: Il gio, set 25, 2014 at 04:53:13 +0530, Ritesh Raj Sarraf scrisse: On Thursday 25 September 2014 04:40 PM, Stefano Callegari wrote: If it is set to 1, you need to set it to 0, and then re-test your scenario. I think to remember to have tested it with 0 but not has seemed the solution. I'll try again but I'll say you if it's ok tomorrow morning. Thanks. I'll wait for your results. The other suspicion I have with this card family, is that they are more flaky when compared to Intel card. Previously, the other laptop had an Intel card, that used the e1000e driver. With that card, the issues were none to the best of my knowledge. Let's see what you results are. Accordingly we'll act further. No... Again this morning, the eth0 has gone up and down until I done the log in into kde. Below an example from the log: Sep 26 09:27:04 hpdv5 systemd-udevd[184]: Network interface NamePolicy= disabled on kernel commandline, ignoring. Sep 26 09:27:04 hpdv5 kernel: [ 339.688970] r8169 :03:00.0 eth0: link up Sep 26 09:27:05 hpdv5 laptop-mode: Laptop mode Sep 26 09:27:05 hpdv5 laptop-mode: enabled, active Sep 26 09:27:05 hpdv5 laptop-mode: (Data-loss sensitive features disabled.) Sep 26 09:27:05 hpdv5 systemd[1]: Starting Session c67 of user stefano. Sep 26 09:27:05 hpdv5 systemd[1]: Started Session c67 of user stefano. Sep 26 09:27:05 hpdv5 kernel: [ 340.601747] r8169 :03:00.0 eth0: link down [cut] Sep 26 09:27:08 hpdv5 kernel: [ 343.780266] r8169 :03:00.0 eth0: link up Sep 26 09:27:09 hpdv5 laptop-mode: Laptop mode Sep 26 09:27:09 hpdv5 laptop-mode: enabled, active [unchanged] Sep 26 09:27:09 hpdv5 laptop-mode: (Data-loss sensitive features disabled.) Sep 26 09:27:09 hpdv5 laptop-mode: Laptop mode Sep 26 09:27:09 hpdv5 laptop-mode: enabled, active [unchanged] Sep 26 09:27:09 hpdv5 laptop-mode: (Data-loss sensitive features disabled.) Sep 26 09:27:09 hpdv5 laptop-mode: Laptop mode Sep 26 09:27:09 hpdv5 laptop-mode: enabled, active [unchanged] Sep 26 09:27:09 hpdv5 laptop-mode: (Data-loss sensitive features disabled.) Sep 26 09:27:09 hpdv5 laptop-mode: Laptop mode Sep 26 09:27:09 hpdv5 laptop-mode: enabled, active [unchanged] Sep 26 09:27:09 hpdv5 laptop-mode: (Data-loss sensitive features disabled.) Sep 26 09:27:09 hpdv5 laptop-mode: Laptop mode Sep 26 09:27:09 hpdv5 laptop-mode: enabled, not active Sep 26 09:27:09 hpdv5 systemd[1]: Starting Session c70 of user stefano. Sep 26 09:27:09 hpdv5 systemd[1]: Started Session c70 of user stefano. Sep 26 09:27:09 hpdv5 kernel: [ 344.957705] r8169 :03:00.0 eth0: link down and ~ bash $ grep -e ^\w /etc/laptop-mode/conf.d/ethernet.conf DEBUG=0 CONTROL_ETHERNET=1 BATT_THROTTLE_ETHERNET=0 LM_AC_THROTTLE_ETHERNET=0 NOLM_AC_THROTTLE_ETHERNET=0 THROTTLE_SPEED=slowest DISABLE_WAKEUP_ON_LAN=1 ETHERNET_DEVICES=eth0 DISABLE_ETHERNET_ON_BATTERY=0 Again the LAN led on the router blinks. p.s.: The router has also Gbit and when I power on the laptop the led shows me the link at 100Mbit. PS: I intend to do a new Laptop Mode Tools release soon, to ensure it makes it before the Debian freeze. A quick turnaround will be highly appreciated. As I have say you yesterday, in a day if I reboot the laptop the eth0 hasn't this behavior anymore, so I can show the tests only tomorrow. Sorry.. Thanks -- Stefano Callegari ste...@infinito.it -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention.
Bug#762909: /usr/bin/apt-show-versions: Multiple upgrades available, apt-show-versions shows none
Package: apt-show-versions Version: 0.17 Severity: normal File: /usr/bin/apt-show-versions Dear Maintainer, I have a server where 'apt-show-versions -u' displays NO upgrades although 'apt-get upgrade' shows 7. ~~ # apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: grub-common grub-pc grub-pc-bin grub2-common libudev0 linux-firmware udev 7 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. ~~ Running 'apt-show-versions -i' doesn't resolv the problem. Please considder looking into this. Thank you, - Hansa -- System Information: Debian Release: wheezy/sid APT prefers precise-updates APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 'precise'), (100, 'precise-backports') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-69-generic (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apt-show-versions depends on: ii apt 0.8.16~exp12ubuntu10.20.1 ii libapt-pkg-perl 0.1.25build2 ii perl [libstorable-perl] 5.14.2-6ubuntu2.4 apt-show-versions recommends no packages. apt-show-versions suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660163: three versions, and three and a half years, out of date
PoDoFo 0.9.3 has been released. http://podofo.sourceforge.net/download.html Version 0.9.0 is the latest available in the Debian archive. This is now three versions, and three and a half years, out of date. Please upgrade to the current release. -- Ian Bruce -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762905: transition: openjpeg2 2.1.0
Control: reassign -1 ftp.debian.org On Fri, 2014-09-26 at 09:36 +0200, Mathieu Malaterre wrote: I am reading the cruft report: https://ftp-master.debian.org/cruft-report-daily.txt [...] * source package openjpeg2 version 2.1.0-1 no longer builds [...] The broken Build-Depends (leptonlib) is now fixed in sid. The broken Depends is a mistake, src:openjpeg2 was building binary packages using the same name as binaries from src:openjpeg. Please run the suggested dak rm command. That won't help, given that dak wouldn't let us (and quite rightly too). I don't know why you're asking the release team to perform removals from unstable. There's a reason that the cruft report lives in ftp-master's space. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762910: lines longer than 39 characters are mishandled in /proc/acpi/wakeup
Package: acpitool
Version: 0.5.1-3
Tags: patch
While parsing /proc/acpi/wakeup, src/acpitool.cpp assumes that lines are
maximum 39 char long (40 including the terminating NUL character at the
end of C strings).
Since I have a line in /proc/acpi/wakeup that is exactly 40 char long,
the tool doesn't work (it hangs up when it hits that line, consuming
100% CPU forever).
The attached patch changes this behavior to assume maximum 79 char long
lines by increasing the buffer size to 80.
diff -ur acpitool-0.5.1/debian/patches/wakeup.patch acpitool-0.5.1.patched/debian/patches/wakeup.patch
--- acpitool-0.5.1/debian/patches/wakeup.patch 2014-09-26 10:20:52.0 +0200
+++ acpitool-0.5.1.patched/debian/patches/wakeup.patch 2014-09-26 10:16:07.163701983 +0200
@@ -13,15 +13,44 @@
have a device called LID which is 3 characters long.
Instead of using a fixed size for the device we split the line
on the first tab (\t) and use the first part.
+
+ * The length of lines in /proc/acpi/wakeup can have more than 39
+ characters, I have one with exactly 40. So let's increase the
+ reading buffer to 80 characters.
---
src/acpitool.cpp | 23 +++
1 files changed, 11 insertions(+), 12 deletions(-)
-diff --git a/src/acpitool.cpp b/src/acpitool.cpp
-index 2a610a5..71e01d7 100644
a/src/acpitool.cpp
-+++ b/src/acpitool.cpp
-@@ -460,16 +460,14 @@ int Show_WakeUp_Devices(int verbose)
+Index: acpitool-0.5.1/src/acpitool.cpp
+===
+--- acpitool-0.5.1.orig/src/acpitool.cpp
acpitool-0.5.1/src/acpitool.cpp
+@@ -416,7 +416,7 @@ int Do_Fan_Info(int verbose)
+ int Show_WakeUp_Devices(int verbose)
+ {
+ ifstream file_in;
+-char *filename, str[40];
++char *filename, str[80];
+
+ filename = /proc/acpi/wakeup;
+
+@@ -437,13 +437,13 @@ int Show_WakeUp_Devices(int verbose)
+ }
+ else
+ {
+- file_in.getline(str, 40); // first line are just headers //
++ file_in.getline(str, 80); // first line are just headers //
+ cout strendl;
+ cout ---endl;
+ int t = 1;
+ while(!file_in.eof())
+ {
+- file_in.getline(str, 40);
++ file_in.getline(str, 80);
+ if (strlen(str)!=0) // avoid printing last empty line //
+ {
+ cout t. strendl;
+@@ -459,16 +459,14 @@ int Show_WakeUp_Devices(int verbose)
int Toggle_WakeUp_Device(const int Device, int verbose)
{
@@ -43,7 +72,7 @@
{
if(!verbose)
{
-@@ -484,14 +482,15 @@ int Toggle_WakeUp_Device(const int Device, int verbose)
+@@ -483,14 +481,15 @@ int Toggle_WakeUp_Device(const int Devic
}
}
@@ -64,7 +93,3 @@
index++;
}
}
---
-1.7.5.4
-
-
Bug#762839: bash without importing shell functions from the environment
On 2014-09-26 09:19:17 +0200, Samuel Thibault wrote: Nikolaus Rath, le Thu 25 Sep 2014 17:26:40 -0700, a écrit : Wasn't there some web server that used to put query script variables into the environment of the CGI script? Well, that ought to have been fixed a long time ago already, otherwise you could have injected all sorts of LD_*. It depends on the environment variable names. Names with lowercase characters, such as exec, are safe, since for application usage only[*]. Well... actually not with bash! [*] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762911: highlight: new upstream version 3.19
Source: highlight Severity: wishlist Dear Maintainers, There's a new upstream version of highlight, so it would be nice to have it packaged for Debian before the freeze. Also, are you updating the git repo of the package? Because it seems there's no changes there since a year ago, but there's new uploads in last month… Thanks in advance, -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: armel (armv5tel) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762912: polipo: /etc/cron.daily/polipo exits with return code 1 when polipo is not startet
Package: polipo Version: 1.0.4.1-1.2 Severity: minor Tags: patch I use polipo in a scenario where it is started only when my notebook is connected to certain network environments. Most of the time the daemon is not started. The daily cron job exits with return code 1 when polipo is not running. This results in the cron daemon sending a mail to root stating run-parts: /etc/cron.daily/polipo exited with return code 1 This is a bit annoying. The reason is simple as is the fix: The last line of the script is [ -f $PIDFILE ] kill -USR2 $(cat $PIDFILE) When polipo is not running then the PIDFILE does not exist and the test fails. As it es the last command in the script this failure determines the exit code of the script. A simple exit 0 as last line would fix that issue. (The attached /etc/cron.daily/polipo already contains this fix.) -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages polipo depends on: ii dpkg 1.16.15 ii install-info 4.13a.dfsg.1-10 ii libc6 2.13-38+deb7u4 polipo recommends no packages. polipo suggests no packages. -- Configuration Files: /etc/cron.daily/polipo changed: set -e FORBIDDEN_FILE=/etc/polipo/forbidden CONFIG_FILE=/etc/polipo/config if [ ! -x /usr/bin/polipo ]; then exit 0 fi if [ ! -f $FORBIDDEN_FILE ]; then FORBIDDEN_FILE=/dev/null fi PIDFILE=/var/run/polipo/polipo.pid [ -f $PIDFILE ] kill -USR1 $(cat $PIDFILE) su -c \ nice polipo -x -c $CONFIG_FILE forbiddenFile=$FORBIDDEN_FILE /dev/null \ proxy [ -f $PIDFILE ] kill -USR2 $(cat $PIDFILE) exit 0 /etc/polipo/config changed: tunnelAllowedPorts = 443, 1533, 16316, 8333, 5222 socksParentProxy = localhost:1081 socksProxyType = socks5 chunkHighMark = 819200 objectHighMark = 128 diskCacheRoot = -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762796: munin: Undefined subroutine main::header
This bug has been reported to Munin team by another user: http://sourceforge.net/p/munin/mailman/message/32853053/ Sébastien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762913: gnome-maps: depends on gjs from experimental
Package: gnome-maps Version: 3.12.2-1 Severity: serious Dear Maintainer, gnome-maps in sid depends on gjs = 1.41 which is not available in sid. The requested version is only in experimental available. Regards Noël -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-maps depends on: ii dconf-gsettings-backend [gsettings-backend] 0.22.0-1 ii geoclue-2.0 2.1.8-1 ii gir1.2-champlain-0.120.12.9-1 ii gir1.2-clutter-1.0 1.18.4-2+b1 ii gir1.2-cogl-1.0 1.18.2-2 ii gir1.2-gdkpixbuf-2.0 2.30.8-1 ii gir1.2-geocodeglib-1.0 3.14.0-1 ii gir1.2-glib-2.0 1.42.0-1 ii gir1.2-gtk-3.0 3.14.0-1 ii gir1.2-gtkchamplain-0.12 0.12.9-1 ii gir1.2-gtkclutter-1.01.6.0-1 ii gjs 1.40.1-4 ii libc62.19-11 ii libgirepository-1.0-11.42.0-1 ii libgjs0e [libgjs0-libmozjs-24-0] 1.40.1-4 ii libglib2.0-0 2.42.0-1 gnome-maps recommends no packages. gnome-maps suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762839: bash without importing shell functions from the environment
On Sep 25, 2014 3:18 PM, Matthias Urlichs matth...@urlichs.de wrote: Hi, Samuel Thibault: Sounds crazy to me. Definitely. This is now out in the wild; exploits which simply replace echo or cat-without-/bin are going to happen. :-/ Actually, what I've seen reported in the wild have been wget and run an irc cnc script.a Maybe we should add the patched version, with an appropriate NEWS entry, to backports? Maybe?
Bug#762791: laptop-mode-tools: At boot eth0 fails
Il ven, set 26, 2014 at 01:50:22 +0530, Ritesh Raj Sarraf scrisse: Then I don't have much ideas. Perhaps you could set DEBUG=1 for this module, and then try to see what changes occur. Ok, I'll try with debug=1. See you tomorrow [cut] Ciao -- Stefano Callegari ste...@infinito.it -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761172: Verified problem in new version of itext5
[please CC me I'm not a member of pkg-java-maintainers] Hi, since this package has two reverse dependencies in Debian Med (figtree, biojava3-live) I had a look into this. I tried the latest version (5.5.3) and realised, that the problem exists also there plus another one. Results : Tests in error: testExtraXObjects(com.itextpdf.text.pdf.PdfCopyTest): Can't connect to X11 window server using 'localhost:11.0' as the value of the DISPLAY variable. remoteGifTest(com.itextpdf.text.RemoteGifImageTest): itextpdf.com Tests run: 246, Failures: 0, Errors: 2, Skipped: 4 I think in principle it should be quite easy to simply exclude these tests from the test suite. Please keep in touch if any help might be needed and whether you consider upgrading to the latest version. Remark: I'd recommend using a Git repository layout including pristine-tar since the tarball will not be downloaded but created from SVN and thus it matters regarding md5sum what tarball is used. Keeping it as pristine tar would bring all maintainers on the same base. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762914: abinit-data is not a documentation package, but shows up in that category
Source: abinit-data Version: Data package is classified as a documentation package Severity: minor Dear Maintainer, I see the new abinit-data package in the Documentation category, where it surely does not belong. Did someone just copy the control file from abinit-doc when creating the new one, and forget to edit that line ? *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762466: ebumeter: package lists download page as homepage
On 09/22/14 17:59, Jonas Smedegaard wrote: Package: ebumeter Version: 0.2.0~dfsg0-3 Severity: minor This project has a proper homepage, different from and richer than the download page: http://kokkinizita.linuxaudio.org/linuxaudio/ebumeter-doc/quickguide.html I've pushed this new URL to git. Since I'm not the maintainer, I leave it to Mira to include it in the next upstream. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756174: New jackd2 upload
On 09/18/14 11:24, Adrian Knoth wrote: Hi Jonas! Do you have any spare cycles to work on that bug, specifically the clean waf-CDBS integration? Apparently not. If not, I'd probably just use Steve's minimal patch for the time being and upload in a couple of days, let's say some time next week. I'm now starting to upload a new jackd2 package with Steve's minimal patch. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685298: Impossible to simultaneously install libtomcat7-java and libtomcat6-java
tags -1 wontfix close -1 stop Tomcat 6 is going to be removed, so we won't fix this specific issue between Tomcat 6 and 7, but we took care to use different paths for Tomcat 8 and libtomcat7-java can be installed simultaneously with libtomcat8-java. Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757499: [INTL:tr] Turkish debconf template translation for wireshark
Control: tags -1 pending confirmed Hi Mert, 2014-08-08 21:50 GMT+02:00 Mert Dirik mertdi...@gmail.com: Package: wireshark Severity: wishlist Tags: l10n patch Please find the attached Turkish translation of wireshark debconf messages. This file should be put as debian/po/tr.po in your build tree. Thank you. It will be included in the next upload. Cheers, Balint -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756174: New jackd2 upload
Quoting Adrian Knoth (2014-09-26 11:24:50) On 09/18/14 11:24, Adrian Knoth wrote: Do you have any spare cycles to work on that bug, specifically the clean waf-CDBS integration? Apparently not. If not, I'd probably just use Steve's minimal patch for the time being and upload in a couple of days, let's say some time next week. I'm now starting to upload a new jackd2 package with Steve's minimal patch. Sorry - also for my silence :-( Thanks for looking into it! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#710362: ldap2zone generates corrupted A statements
Package: ldap2zone Version: 0.1-7 Followup-For: Bug #710362 Dear Maintainer, recently ldap2zone generated a corrupted line in the db.intern database putting in a serioud trouble the whole Skolelinux network. The tjener accepted only root/terminal login and no regular account logins since LDAP was not reachable for the other services (DHCP, nss, etc). In particular an A statement was added at the end of db.intern with a blank hostname field. Kind Regards Giorgio Pioda -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=it_CH.UTF-8, LC_CTYPE=it_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690973: ITP: pgmodeler -- PostgreSQL Database Modeler
Hi Olivier, On Mo, 2014-09-22 at 17:56 +0200, Olivier Berger wrote: Regarding you old ITP for pgmodeler, I'm wondering: had you made any work on packaging it, that could be reused eventually ? Nothing usable at least. Last time I checked the app was not able to be run from a LSB environment, with user home settings, and so one. I fiddled with a few wrapper scripts, but failed miserably to offer a clean way to use the app. Cheers Markus -- Markus Frosch mar...@lazyfrosch.de http://www.lazyfrosch.de signature.asc Description: This is a digitally signed message part
Bug#761172: Verified problem in new version of itext5
Hi,
the attached quilt patch disables both failing tests in version 5.5.3.
Hope this helps
Andreas.
On Fri, Sep 26, 2014 at 11:07:46AM +0200, Andreas Tille wrote:
[please CC me I'm not a member of pkg-java-maintainers]
Hi,
since this package has two reverse dependencies in Debian Med (figtree,
biojava3-live) I had a look into this. I tried the latest version
(5.5.3) and realised, that the problem exists also there plus another
one.
Results :
Tests in error:
testExtraXObjects(com.itextpdf.text.pdf.PdfCopyTest): Can't connect to X11
window server using 'localhost:11.0' as the value of the DISPLAY variable.
remoteGifTest(com.itextpdf.text.RemoteGifImageTest): itextpdf.com
Tests run: 246, Failures: 0, Errors: 2, Skipped: 4
I think in principle it should be quite easy to simply exclude these
tests from the test suite. Please keep in touch if any help might
be needed and whether you consider upgrading to the latest version.
Remark: I'd recommend using a Git repository layout including
pristine-tar since the tarball will not be downloaded but created from
SVN and thus it matters regarding md5sum what tarball is used. Keeping
it as pristine tar would bring all maintainers on the same base.
Kind regards
Andreas.
--
http://fam-tille.de
--
http://fam-tille.de
Author: Andreas Tille ti...@debian.org
Last-Changed: Fri, 26 Sep 2014 09:33:15 +0200
Bug-Debian: http://bugs.debian.org/761172
Description: Skip tests by removing the according test files
RemoteGifImageTest: requires online connection
PdfCopyTest: Requires X server
--- a/src/test/java/com/itextpdf/text/RemoteGifImageTest.java
+++ /dev/null
@@ -1,39 +0,0 @@
-package com.itextpdf.text;
-
-import com.itextpdf.text.pdf.PdfWriter;
-import org.junit.Before;
-import org.junit.Test;
-
-import java.io.File;
-import java.io.FileOutputStream;
-import java.io.IOException;
-
-public class RemoteGifImageTest {
-
-private final String[] GIF_LOCATION = {
-http://itextpdf.com/img/logo.gif;,
-http://itextsupport.com/files/testresources/img/remote_gif_test.gif;,
-./src/test/resources/com/itextpdf/text/Chunk/logo.gif // non-remote gif
-};
-
-private final String OUTPUTFOLDER = ./target/com/itextpdf/test/image/;
-
-@Before
-public void before() {
-new File(OUTPUTFOLDER).mkdirs();
-}
-
-@Test
-public void remoteGifTest() throws IOException, DocumentException {
-for (int i = 0; i GIF_LOCATION.length; i++) {
-Document document = new Document();
-PdfWriter.getInstance(document, new FileOutputStream(OUTPUTFOLDER + gif_remote[ + i + ].pdf));
-document.open();
-
-Image img = Image.getInstance(GIF_LOCATION[i]);
-document.add(img);
-
-document.close();
-}
-}
-}
--- a/src/test/java/com/itextpdf/text/pdf/PdfCopyTest.java
+++ /dev/null
@@ -1,379 +0,0 @@
-/*
- * $Id: $
- *
- * This file is part of the iText (R) project.
- * Copyright (c) 1998-2014 iText Group NV
- * Authors: Bruno Lowagie, Paulo Soares, Kevin Day, et al.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU Affero General Public License version 3
- * as published by the Free Software Foundation with the addition of the
- * following permission added to Section 15 as permitted in Section 7(a):
- * FOR ANY PART OF THE COVERED WORK IN WHICH THE COPYRIGHT IS OWNED BY
- * ITEXT GROUP. ITEXT GROUP DISCLAIMS THE WARRANTY OF NON INFRINGEMENT
- * OF THIRD PARTY RIGHTS
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
- * or FITNESS FOR A PARTICULAR PURPOSE.
- * See the GNU Affero General Public License for more details.
- * You should have received a copy of the GNU Affero General Public License
- * along with this program; if not, see http://www.gnu.org/licenses or write to
- * the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
- * Boston, MA, 02110-1301 USA, or download the license from the following URL:
- * http://itextpdf.com/terms-of-use/
- *
- * The interactive user interfaces in modified source and object code versions
- * of this program must display Appropriate Legal Notices, as required under
- * Section 5 of the GNU Affero General Public License.
- *
- * In accordance with Section 7(b) of the GNU Affero General Public License,
- * a covered work must retain the producer line in every PDF that is created
- * or manipulated using iText.
- *
- * You can be released from the requirements of the license by purchasing
- * a commercial license. Buying such a license is mandatory as soon as you
- * develop commercial activities involving the iText software without
- * disclosing the source code of your own applications.
- * These activities include: offering paid services to customers as an ASP,
- *
Bug#762914: abinit-data is not a documentation package, but shows up in that category
Control: reassign -1 abinit-data On Vi, 26 sep 14, 09:12:43, Edward Welbourne wrote: Source: abinit-data Version: Data package is classified as a documentation package Severity: minor Dear Maintainer, I see the new abinit-data package in the Documentation category, where it surely does not belong. Did someone just copy the control file from abinit-doc when creating the new one, and forget to edit that line ? *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Bug#760853: on mentors, work in progress
on Thu, 25 Sep 2014 18:48:56 +0300, Damian Minkov wrote: On Thu, Sep 25, 2014 at 5:18 PM, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: severity 760853 grave Bug #760853 [jitsi] jitsi is bound/dependant on libavfilter4 instead of libavfilter5 Severity set to 'grave' from 'important' retitle 760853 jitsi uninstallable in sid Bug #760853 [jitsi] jitsi is bound/dependant on libavfilter4 instead of libavfilter5 Changed Bug title to 'jitsi uninstallable in sid' from 'jitsi is bound/dependant on libavfilter4 instead of libavfilter5' stop Stopping processing here. Hi, we have updated the package to newer version and it is uploaded on mentors. The new version will fix this one. Regards damencho FWIW the upload to mentors announce is http://lists.jitsi.org/pipermail/dev/2014-September/022040.html It did trigger a new upload of package 'strophejs' ( migration status is at https://packages.qa.debian.org/s/strophejs.html ) That is all fine. But what is needed for an upload to 'unstable' or 'exprimental'? Cheers Geert Stappers -- Leven en laten leven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755518: laptop-mode-tools: USB Autosuspend + LVM2 filesystems = failed boot
Hi, I have applied your patch changing the last line of /lib/udev/lmt-udev and my system still boots with / in read only mode. running: systemd 215 udevd 215 I have the same symptoms as you describe: # systemctl status systemd-remount-fs.service ● systemd-remount-fs.service - Remount Root and Kernel File Systems Loaded: loaded (/lib/systemd/system/systemd-remount-fs.service; static) Active: failed (Result: exit-code) since Fri 2014-09-26 12:54:16 IDT; 1min 32s ago Docs: man:systemd-remount-fs.service(8) http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems Process: 510 ExecStart=/lib/systemd/systemd-remount-fs (code=exited, status=1/FAILURE) Main PID: 510 (code=exited, status=1/FAILURE) Sep 26 12:54:16 thinkpad systemd-remount-fs[510]: mount: /usr not mounted or bad option Sep 26 12:54:16 thinkpad systemd-remount-fs[510]: /bin/mount for /usr exited with exit status 32. Sep 26 12:54:16 thinkpad systemd[1]: systemd-remount-fs.service: main process exited, code=exited, status=1/FAILURE Sep 26 12:54:16 thinkpad systemd[1]: Failed to start Remount Root and Kernel File Systems. Sep 26 12:54:16 thinkpad systemd[1]: Unit systemd-remount-fs.service entered failed state. and in syslog from boot: [2.345523] systemd[1]: /usr appears to be on its own filesytem and is not already mounted. This is not a supported setup. Some things will probably break (sometimes even silently) in mysterious ways. Consult http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken for more information. -- Ilan Cohen
Bug#762870: can't boot!
Hello, downgrade initramfs-tools package from 0.117 on 0.116 could help. Mirek On Fri, 26 Sep 2014 12:07:09 +0800 =?utf-8?B?56mN5Li55bC8?= Dan Jacobson jida...@jidanni.org wrote: All I know is I couldn't boot with that thing at the top of # ls /boot/ -ltog -rw-r--r-- 1 2907647 09-26 08:46 initrd.img-3.16-2-686-pae drwxr-xr-x 54096 09-23 00:39 grub -rw-r--r-- 1 2726738 09-22 23:00 initrd.img-3.16-1-686-pae -rw-r--r-- 1 2089608 09-21 01:56 System.map-3.16-2-686-pae -rw-r--r-- 1 159970 09-21 01:56 config-3.16-2-686-pae -rw-r--r-- 1 3006608 09-21 01:54 vmlinuz-3.16-2-686-pae -rw-r--r-- 1 2087689 09-13 14:27 System.map-3.16-1-686-pae -rw-r--r-- 1 159879 09-13 14:27 config-3.16-1-686-pae -rw-r--r-- 1 3003440 09-13 14:25 vmlinuz-3.16-1-686-pae -rw-r--r-- 1 2750492 09-11 10:37 initrd.img-3.14-2-686-pae -rw-r--r-- 1 1933464 08-09 16:44 System.map-3.14-2-686-pae -rw-r--r-- 1 157566 08-09 16:44 config-3.14-2-686-pae -rw-r--r-- 1 2833376 08-09 16:42 vmlinuz-3.14-2-686-pae so I chose the oldest one from the grub menu and was able to boot. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762915: Please convert all scripts to not use bash
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: gzip Version: 1.6-3 Severity: grave Please convert all scripts (zcat, zless, ...) to use /bin/sh as shell and not /bin/bash. Most of them (as I checked) do not use any special bash syntax anyway so there is no need to use bash. I made this a grave bug as it is security relevant due the current bash bugs and against the debian policy to use /bin/sh if possible. - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (800, 'unstable'), (110, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.15.10 (SMP w/8 CPU cores) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) (ignored: LC_ALL set to de_DE) Shell: /bin/sh linked to /bin/dash Versions of packages gzip depends on: ii dpkg 1.17.13 ii install-info 5.2.0.dfsg.1-4 ii libc6 2.19-11 gzip recommends no packages. Versions of packages gzip suggests: ii less 458-3 - -- no debconf information - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen kl...@ethgen.de Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJUJTtXAAoJEKZ8CrGAGfasq4YL/iRi/gmLpx1wGHYrj96C1x3W jb5qUzPxE9kXnSQCyNf5qMmfxsX/Fix+dHzJEQZjsirRrN1SR2/fev9h1pFx8UkJ gM2I+n6DnfpRZQOCHKWHwt4mDL7NFCMBA36UPhWywG0+u72iNr78rte1uJb4g1SH p/uySmpJN2syedyQxlryiNMAwNKcffHUu6xoHlf07LWvHpFKcBMLX3LBhy5LA6zq Rsd1EociXM0Am/IzYImA/Dz765VUA5Am+HTTLzFVCwopQcTudIUsn2V0O9B27D71 TG39yYBFfxME+x9zDHWg7dVZujqS1QkmCTQJcMGULrXXkspgl68Wa8ADgocPq+5e fLiDkOAlDw/Wv51KV9642HwBLmzhYwAmPA/z8ipdbWNrBPCy0txTuPUBZ5tfa5BE yUDYA3YwwM6bgvQwOAUckudPWwdPhzh3H0xKFcnMatx3WlY4DHKtDwBg6NcIIA8Y efESeKC8Rqn1Dwgl6KhXvjaLaFAdn3P99LXSvhQ57g== =X2IY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718946: Allow for parallel installation of tomcat7 and tomcat6
Tomcat 6 is going to be removed, so we won't fix this specific issue between Tomcat 6 and 7, but we took care to use different paths when packaging Tomcat 8, so this issue won't appear again. Emmanuel Bourg signature.asc Description: OpenPGP digital signature
Bug#762917: Please convert all scripts to not use bash
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: grep Version: 2.20-3 Severity: grave Please convert all scripts (egrep, fgrep) to use /bin/sh as shell and not /bin/bash. None of them do not use any special bash syntax anyway so there is no need to use bash. I made this a grave bug as it is security relevant due the current bash bugs and against the debian policy to use /bin/sh if possible. - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (800, 'unstable'), (110, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.15.10 (SMP w/8 CPU cores) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) (ignored: LC_ALL set to de_DE) Shell: /bin/sh linked to /bin/dash Versions of packages grep depends on: ii dpkg 1.17.13 ii install-info 5.2.0.dfsg.1-4 ii libc6 2.19-11 ii libpcre3 1:8.35-3 grep recommends no packages. grep suggests no packages. - -- no debconf information - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen kl...@ethgen.de Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJUJTxQAAoJEKZ8CrGAGfas0eYL/3BxpxSzvf+xtNs3pRePNQS7 443pCOv2nyGgmAjQiVOlhrHw2v1BlWOg0cGUySVPZY2t9SG0Nwgy3McOk3S9Ifh4 TR11iERKvT/HaledzCetm4G/DObHszoWadcllpZ7JlEdL2Q2NrCPgROyZgdPvPap ox022+l8qSGNhcZfQBqvWstp1qPdhvbHbx61cU0ghjSPEfzhwuZ3+HRY1qDhqdGw WBI93u851PP4YUDOz8apR3uTxNdetTRUgtebQGNGJXP2a7Wg+WAkqn4FZaZYYvN5 vnJB/SCoWu7cLTSCs1ghx/HGcOYoy/xIlHN2A/NwbUuAx4mwvCcciVQu58nb63fr Gv1Vi7YQ8NTTR6Tzksf3E1ACnFR1u1FGcY0rXSfvhndvrRArvGhcbq5GFpmkOLRp 2WkSa13GOPPKW87LdTisy+Lprh7Czsn7pmBImjlEB5x1U6URGffRiPVBHLiDkmuo yXvQPFbYy6LI4kClWYg9HhSsxvq9fpTVP92g2eQPjQ== =AG5B -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762918: Please convert all scripts to not use bash
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: xz-utils Version: 5.1.1alpha+20120614-2 Severity: grave Please convert all scripts (xzdiff, xzless, ...) to use /bin/sh as shell and not /bin/bash. Most of them (as I checked) do not use any special bash syntax anyway so there is no need to use bash. I made this a grave bug as it is security relevant due the current bash bugs and against the debian policy to use /bin/sh if possible. - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (800, 'unstable'), (110, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.15.10 (SMP w/8 CPU cores) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) (ignored: LC_ALL set to de_DE) Shell: /bin/sh linked to /bin/dash Versions of packages xz-utils depends on: ii libc6 2.19-11 ii liblzma5 5.1.1alpha+20120614-2 xz-utils recommends no packages. xz-utils suggests no packages. - -- no debconf information - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen kl...@ethgen.de Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJUJT0eAAoJEKZ8CrGAGfasOQkL/3+GmsUyz05FfCth5fUojLXI 3BerfHYf2OP2a6oIWUIRbWva6AD7mHXNqY4P4/862zy6csJ+nQg6KjiZ4le+zUVz hG3WubKxdcFZfv9loCCznT6b+VvedpV8kP0xDsleusnSl0Ud4ZIgvtyS1Fkt6AT3 Em3VIrN++LCH6Uq5o9lj5EbXMPd0GQkv5xx2fW9gjUykR3iYPOagUrZ63Fi/wP2F P1IIB8WmUDXRQEhr7oGquhrCZvPjEGDgC8vloAoAYwuNvTUfoeDQ3N597koaoMiz AbRtw16LzZyCuWDbXA9DL7Uq2bBPKWpA5EBWLjE/+IBU1Ms5Vh4Ag1JiRZPRxN7o 19Jec+mOspiyd1v6TY66+4wv3tOMOZkDEgFru0cn57XQzi+vjXqe2/ulg3JW3j1h qtZfBbZTXB1n1cWeJZ5FFGsZbYVr5mIZOXOLQHoMKTXv4NbgBKilgiJu+6oTOe3j 3km5DyBZnGWaJ9HKlDz6CoMSXJiIaE2dLlNeOxE+Pg== =YYRl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758097: portabase: fix mips64el build
On Thu, 14 Aug 2014 17:06:29 +0800 YunQiang Su wzss...@gmail.com wrote: Package: portabase Version: 2.1+git20120910-1 Portabase ftbfs on mips64el, and with this tiny patch it can build now. Index: portabase-2.1+git20120910/metakit/include/mk4.h === --- portabase-2.1+git20120910.orig/metakit/include/mk4.h 2012-09-17 08:56:23.0 + +++ portabase-2.1+git20120910/metakit/include/mk4.h 2014-08-14 08:25:45.727508267 + @@ -102,7 +102,8 @@ #if !defined (_WIN32) !defined (q4_LONG64) #if defined (_PA_RISC2_0) || defined (__powerpc64__) || defined(__sparcv9) || \ defined(__x86_64__) || defined(__s390x__) || defined(__alpha) || \ - (defined(__ia64) (!defined(__HP_aCC) || defined(__LP64__))) + (defined(__ia64) (!defined(__HP_aCC) || defined(__LP64__))) || \ + defined(__mips64) #define q4_LONG64 1 #endif #endif I NMUed this package with the attached patch. It should fix FTBFS for mips64(el), arm64, sparc64 and x32. -- YunQiang Su diff -Nru portabase-2.1+git20120910/debian/changelog portabase-2.1+git20120910/debian/changelog --- portabase-2.1+git20120910/debian/changelog 2012-09-18 12:44:42.0 +0800 +++ portabase-2.1+git20120910/debian/changelog 2014-09-26 17:34:02.0 +0800 @@ -1,3 +1,10 @@ +portabase (2.1+git20120910-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Fix FTBFS on mips64(el), x32, arm64, sparc64. + + -- YunQiang Su s...@debian.org Fri, 26 Sep 2014 17:32:10 +0800 + portabase (2.1+git20120910-1) unstable; urgency=low * New upstream version [September 2012]. diff -Nru portabase-2.1+git20120910/debian/patches/64bit.patch portabase-2.1+git20120910/debian/patches/64bit.patch --- portabase-2.1+git20120910/debian/patches/64bit.patch1970-01-01 08:00:00.0 +0800 +++ portabase-2.1+git20120910/debian/patches/64bit.patch2014-09-26 17:31:21.0 +0800 @@ -0,0 +1,17 @@ +Index: portabase-2.1+git20120910/metakit/include/mk4.h +=== +--- portabase-2.1+git20120910.orig/metakit/include/mk4.h 2012-09-17 16:56:23.0 +0800 portabase-2.1+git20120910/metakit/include/mk4.h2014-09-26 17:31:16.503415273 +0800 +@@ -101,8 +101,10 @@ + // and here's the other end of the scale... + #if !defined (_WIN32) !defined (q4_LONG64) + #if defined (_PA_RISC2_0) || defined (__powerpc64__) || defined(__sparcv9) || \ +-defined(__x86_64__) || defined(__s390x__) || defined(__alpha) || \ +- (defined(__ia64) (!defined(__HP_aCC) || defined(__LP64__))) ++ (defined(__x86_64__) defined(__LP64__)) || defined(__s390x__) || defined(__alpha) || \ ++ (defined(__ia64) (!defined(__HP_aCC) || defined(__LP64__))) || \ ++ (defined(__mips64) defined(__LP64__)) || defined(__aarch64__) || \ ++ (defined(__sparc__) defined(__LP64__)) + #define q4_LONG64 1 + #endif + #endif diff -Nru portabase-2.1+git20120910/debian/patches/series portabase-2.1+git20120910/debian/patches/series --- portabase-2.1+git20120910/debian/patches/series 2012-09-17 22:14:29.0 +0800 +++ portabase-2.1+git20120910/debian/patches/series 2014-09-26 17:17:17.0 +0800 @@ -1 +1,2 @@ build.patch +64bit.patch
Bug#762919: reportbug: Can't use reportbug with non root user
Package: reportbug Version: 6.5.1 Severity: normal Dear Maintainer, When I try to use reportbug with a non-root user I get the folloawing message : reportbug Attempt to unlock mutex that was not locked Aborted Can still use it with root, which is stated as unsecure. Ragards JP P -- Package-specific info: ** Environment settings: INTERFACE=text ** /root/.reportbugrc: reportbug_version 4.10 mode novice ui text realname stor...@club-internet.fr email jp.po...@izzop.net no-check-uid -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (600, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.17.0-rc5 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages reportbug depends on: ii apt 1.0.9.1 ii python2.7.8-1 ii python-reportbug 6.5.1 pn python:anynone reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail none pn debconf-utilsnone pn debsums none pn dlocate none pn emacs22-bin-common | emacs23-bin-common none ii file 1:5.19-2 ii gnupg1.4.18-4 ii postfix [mail-transport-agent] 2.11.1-1 ii python-gtk2 2.24.0-4 pn python-gtkspell none pn python-urwid none ii python-vte 1:0.28.2-5 ii xdg-utils1.1.0~rc1+git20111210-7.1 Versions of packages python-reportbug depends on: ii apt 1.0.9.1 ii python-debian 0.1.23 ii python-debianbts 1.12 pn python:anynone python-reportbug suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742409: [Sereal] 2.06 fails to build on some architectures: (#47)
tag 742409 patch
thanks
On Wed, Sep 17, 2014 at 03:57:24PM +0200, demerphq wrote:
On 17 September 2014 07:52, Niko Tyni nt...@debian.org wrote:
So I suspect it's a general 64-bit big-endian problem.
I was under the impression that Jarkko got Sereal to work on big-endian 64
bit HPUX. But maybe I am wrong. Jarkko can you speak to that?
Finally found it. Can't see how it could have worked on big endian
64 bit HPUX either as csnappy_internal_userspace.h seems to define
__LITTLE_ENDIAN there too. But never mind.
Patch attached. This passes for me on both x86_64 and s390x. I can test
run it on the Debian buildds if you like but it seems straightforward?
--
Niko Tyni nt...@debian.org
From f3466c76541f66213ad04f1a14ee07c343d2d0d5 Mon Sep 17 00:00:00 2001
From: Niko Tyni nt...@debian.org
Date: Fri, 26 Sep 2014 13:25:36 +0300
Subject: [PATCH] Fix snappy roundtrip failures on big-endian 64-bit
architectures
Bug: https://github.com/Sereal/Sereal/issues/47
Bug-Debian: https://bugs.debian.org/742409
csnappy_compress_fragment() was returning nonsense because
GetUint32AtOffset() would always take the little endian code path.
---
snappy/csnappy_compress.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/snappy/csnappy_compress.c b/snappy/csnappy_compress.c
index abc103b..007bb82 100644
--- a/snappy/csnappy_compress.c
+++ b/snappy/csnappy_compress.c
@@ -441,7 +441,7 @@ static INLINE EightBytesReference GetEightBytesAt(const char* ptr) {
static INLINE uint32_t GetUint32AtOffset(uint64_t v, int offset) {
DCHECK_GE(offset, 0);
DCHECK_LE(offset, 4);
-#ifdef __LITTLE_ENDIAN
+#if __BYTE_ORDER == __LITTLE_ENDIAN
return v (8 * offset);
#else
return v (32 - 8 * offset);
--
2.1.1
Bug#742409: [Sereal] 2.06 fails to build on some architectures: (#47)
On 26 September 2014 12:33, Niko Tyni nt...@debian.org wrote: tag 742409 patch thanks You are definitely my favourite person of the week. Thank you SO MUCH. I stared at that source for hours looking for this, and I missed it every time. On Wed, Sep 17, 2014 at 03:57:24PM +0200, demerphq wrote: On 17 September 2014 07:52, Niko Tyni nt...@debian.org wrote: So I suspect it's a general 64-bit big-endian problem. I was under the impression that Jarkko got Sereal to work on big-endian 64 bit HPUX. But maybe I am wrong. Jarkko can you speak to that? Finally found it. Can't see how it could have worked on big endian 64 bit HPUX either as csnappy_internal_userspace.h seems to define __LITTLE_ENDIAN there too. But never mind. Jarkko wasn't certain if we had made a 64 bit or 32 bit hpux big-endian work, so I bet I was just wrong there. But, does this mean there is something else we need to fix? Patch attached. This passes for me on both x86_64 and s390x. I can test run it on the Debian buildds if you like but it seems straightforward? Let me roll a new release and we can celebrate together a debian clean build list. This is really really awesome. Thank you again. I can't tell you how pleased I am that this works on everything. Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Bug#762923: dhclient-script uses bash, allowing remote bash exploits
Package: isc-dhcp-client
Version: 4.2.4-7
Severity: normal
File: /sbin/dhclient-script
Tags: security
dhclient puts unchecked strings into environment variables for the
dhclient-script and dhclient-script uses #!/bin/bash. This allows the
recently found bash bugs to be exploited from remote.
There seem to be 2 places where dhclient-script uses bashism:
% checkbashisms /sbin/dhclient-script
possible bashism in /sbin/dhclient-script line 58 (sourced script with
arguments):
. $script $@
possible bashism in /sbin/dhclient-script line 181 (should be 'b = a'):
if [ $new_subnet_mask == 255.255.255.255 ]; then
The second one is trivial to fix leaving a single bashism.
Would it be possible to rewrite that in a POSIX sh compatible way?
That would leave the dhclient hook scripts to worry about:
possible bashism in /etc/dhcp3/dhclient-enter-hooks.d/debug line 24 (${!name}):
echo $i=\'${!i}\' /tmp/dhclient-script.debug
possible bashism in /etc/dhcp3/dhclient-exit-hooks.d/debug line 23 (${!name}):
echo $i=\'${!i}\' /tmp/dhclient-script.debug
possible bashism in /etc/dhcp3/dhclient-exit-hooks.d/rfc3442-classless-routes
line 8 (should be 'b = a'):
if [ x$reason == xBOUND ]; then
possible bashism in /etc/dhcp3/dhclient-exit-hooks.d/rfc3442-classless-routes
line 11 (bash arrays, ${name[0|*|@]}):
for(( i=0; i ${#rfc_routes[@]}; )); do
+10 more array uses
Given the many eyes now turning towards findings bugs in bash and
building exploits with them it might be safer to fix those bashisms
and switch dhclient-script over to #!/bin/sh.
What do you think?
MfG
Goswin
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages isc-dhcp-client depends on:
ii debianutils 4.4
ii iproute 1:3.14.0-1
ii isc-dhcp-common 4.2.4-7
ii libc62.19-1
isc-dhcp-client recommends no packages.
Versions of packages isc-dhcp-client suggests:
pn avahi-autoipd none
pn resolvconf none
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762921: linux-image-3.17-rc5-amd64: Kernel netfilter modules lack NAT support
Package: src:linux Version: 3.17~rc5-1~exp1 Severity: important Dear Maintainer, This kernel does not have IP NAT support configured, making it useles for most home router setups. # iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables v1.4.21: can't initialize iptables table `nat': Table does not exist # grep CONFIG_IP_NF_NAT /boot/config-3.17-rc5-amd64 # CONFIG_IP_NF_NAT is not set This enables the `nat' table in iptables. This allows masquerading, port forwarding and other forms of full Network Address Port Translation. It seems that the required .config options for NAT have shifted around recently in the kernel. -- Package-specific info: ** Version: Linux version 3.17-rc5-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-11) ) #1 SMP Debian 3.17~rc5-1~exp1 (2014-09-18) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.17-rc5-amd64 root=UUID=cb97baf6-acb1-4535-b2d8-dc9d3eb47f64 ro quiet ** Not tainted ** Kernel log: [2.943586] usb 3-10: reset high-speed USB device number 5 using xhci_hcd [2.943634] xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 5. [2.943635] usb 3-10: hub failed to enable device, error -22 [2.948205] sdb: sdb1 [2.959479] sd 4:0:0:0: [sdb] Attached SCSI disk [3.01] usb 3-10: reset high-speed USB device number 5 using xhci_hcd [3.071949] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 880214bb7300 [3.071950] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 880214bb7348 [3.071951] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 880214bb7390 [3.075607] r8152 3-10:1.0 eth1: v1.06.0 (2014/03/03) [3.075677] usbcore: registered new interface driver r8152 [3.078218] usbcore: registered new interface driver cdc_ether [3.081795] random: nonblocking pool is initialized [3.143784] usb 3-9.2: new full-speed USB device number 7 using xhci_hcd [3.231717] Console: switching to colour frame buffer device 240x67 [3.235252] i915 :00:02.0: fb0: inteldrmfb frame buffer device [3.235253] i915 :00:02.0: registered panic notifier [3.243430] usb 3-9.2: New USB device found, idVendor=05f3, idProduct=0007 [3.243433] usb 3-9.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [3.247368] input: HID 05f3:0007 as /devices/pci:00/:00:14.0/usb3/3-9/3-9.2/3-9.2:1.0/0003:05F3:0007.0002/input/input8 [3.247421] hid-generic 0003:05F3:0007.0002: input,hidraw1: USB HID v1.00 Keyboard [HID 05f3:0007] on usb-:00:14.0-9.2/input0 [3.253294] input: HID 05f3:0007 as /devices/pci:00/:00:14.0/usb3/3-9/3-9.2/3-9.2:1.1/0003:05F3:0007.0003/input/input9 [3.253348] hid-generic 0003:05F3:0007.0003: input,hidraw2: USB HID v1.00 Device [HID 05f3:0007] on usb-:00:14.0-9.2/input1 [3.261173] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [3.261232] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input10 [3.261282] [drm] Initialized i915 1.6.0 20140725 for :00:02.0 on minor 0 [3.261306] snd_hda_intel :00:03.0: enabling device ( - 0002) [3.261396] snd_hda_intel :00:1b.0: enabling device ( - 0002) [3.261722] snd_hda_intel :00:03.0: irq 31 for MSI/MSI-X [3.261772] snd_hda_intel :00:1b.0: irq 32 for MSI/MSI-X [3.274888] sound hdaudioC1D0: autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line [3.274891] sound hdaudioC1D0:speaker_outs=1 (0x1a/0x0/0x0/0x0/0x0) [3.274892] sound hdaudioC1D0:hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) [3.274893] sound hdaudioC1D0:mono: mono_out=0x0 [3.274894] sound hdaudioC1D0:inputs: [3.274895] sound hdaudioC1D0: Rear Mic=0x18 [3.274896] sound hdaudioC1D0: Front Mic=0x19 [3.274898] sound hdaudioC1D0: Internal Mic=0x12 [3.282002] input: HDA Intel HDMI HDMI/DP,pcm=3 as /devices/pci:00/:00:03.0/sound/card0/input11 [3.282077] input: HDA Intel HDMI HDMI/DP,pcm=7 as /devices/pci:00/:00:03.0/sound/card0/input12 [3.282284] input: HDA Intel PCH Rear Mic as /devices/pci:00/:00:1b.0/sound/card1/input13 [3.282350] input: HDA Intel PCH Front Mic as /devices/pci:00/:00:1b.0/sound/card1/input14 [3.282417] input: HDA Intel PCH Line Out as /devices/pci:00/:00:1b.0/sound/card1/input15 [3.282483] input: HDA Intel PCH Front Headphone as /devices/pci:00/:00:1b.0/sound/card1/input16 [3.467962] usb 3-9.3: new full-speed USB device number 8 using xhci_hcd [3.535093] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: errors=remount-ro [3.538379] systemd-journald[160]: Received request to flush runtime journal from PID 1 [3.558009] usb 3-9.3: New USB device found, idVendor=046d, idProduct=c52b [3.558013] usb 3-9.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [3.558015]
Bug#762920: ITP: python-hidapi -- cython interface to hidapi
Package: wnpp Owner: Richard Ulrich ri...@paraeasy.ch Severity: wishlist * Package name: python-hidapi Version : 0.7.99.4 Upstream Author : Pavol Rusnak st...@gk2.sk * URL : https://github.com/trezor/cython-hidapi * License : custom Programming Lang: Description : cython interface to hidapi This has been tested with: . * the PIC18F4550 on the development board from CCS with their example program. * the Fine Offset WH3081 Weather Station. . It works on Linux, Windows XP and OS X. . HIDAPI is a multi-platform library which allows an application to interface with USB and Bluetooth HID-Class devices on Windows, Linux, FreeBSD, and Mac OS X. HIDAPI can be either built as a shared library (.so or .dll) or can be embedded directly into a target application by adding a single source file (per platform) and a single header. signature.asc Description: This is a digitally signed message part
Bug#762922: Selective dereferencing
Package: coreutils Version: 8.23-2 Severity: wishlist File: /bin/ls I would like to use --dereference on a certain type of file (git annex symlinks). Adding it to an ls alias also hides all other symlinks. Instead, I would love to be able to say ls --dereference-if-reference-matches=*.git/annex/objects/* … is this something worth considering or would this functionality never make it into coreutils? Thank you, -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages coreutils depends on: ii libacl1 2.2.52-2 ii libattr1 1:2.4.47-2 ii libc62.19-11 ii libselinux1 2.3-2 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#760219: close use of --name in … failure to stop in certain virtualized environments and its dupes
Hi, hereby I close this bug (and its dupes). Almost three weeks passed with a little feedback from the bug reported. The discussion is documented in #760219. The problem, as I understand it, is that certain kFreeBSD jails do not expose the name of process matching a certain PID. The reporter claims that he did the setup wrong (he didn't use linprocfs) and once this was fixed he said Given that linprocfs exists and things work properly when using it …. I doubt that using --name is something that can considered as a bug in clamav's initscripts (with the history of #580188). This problem also exists in other packages like unbound. If this is a real problem it should be addressed in dpkg if at all (giving the fact that the reported did not use linprocfs in the first place). Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762392: Publish self-contained debootstrapped tarballs
On Mon, Sep 22, 2014 at 10:12:20PM +0300, Eduard - Gabriel Munteanu wrote:
Hi,
On Sun, 2014-09-21 at 21:46 +0100, Philip Hands wrote:
[snip]
Anyone that can deal with those issues after installing a tarball should
have no trouble at all running {c}debootstrap themselves.
What if {c}debootstrap isn't available in their environment? That's
specifically the case I was talking about.
I suppose we may consider distributing {c}debootstrap in a
distro-neutral, self-contained package, but I'm unsure how difficult
that is.
debootstrap was specifically written to not require anything from a
Debian system; it should work on just about any POSIX system.
At least that was the case a decade ago; I must admit I haven't been
following along very well.
If that's still the case, then all you really need is to do something
like alien --to-tgz debootstrap*deb
--
It is easy to love a country that is famous for chocolate and beer
-- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742409: [Sereal] 2.06 fails to build on some architectures: (#47)
On Fri, Sep 26, 2014 at 12:40:12PM +0200, demerphq wrote: You are definitely my favourite person of the week. Thank you SO MUCH. I stared at that source for hours looking for this, and I missed it every time. Yeah, I needed quite a few hours with gdb to find it. Code glaring wasn't working for me either :) On Wed, Sep 17, 2014 at 03:57:24PM +0200, demerphq wrote: On 17 September 2014 07:52, Niko Tyni nt...@debian.org wrote: Finally found it. Can't see how it could have worked on big endian 64 bit HPUX either as csnappy_internal_userspace.h seems to define __LITTLE_ENDIAN there too. But never mind. Jarkko wasn't certain if we had made a 64 bit or 32 bit hpux big-endian work, so I bet I was just wrong there. But, does this mean there is something else we need to fix? No, I expect it's fine now. The __hpux branch in csnappy_internal_userspace.h looks perfectly compatible with this to me. Let me roll a new release and we can celebrate together a debian clean build list. OK; I expect I or somebody else from the Debian Perl group will pull it in Debian quite quickly :) This is really really awesome. Thank you again. I can't tell you how pleased I am that this works on everything. Thank you for all your work on this stuff! -- Niko -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762307: grub2: FTBFS on mipsel: objcopy:none_decompress.img[.text]: File truncated
Hello, I have attached a new patch. It is tested on mipsel and i386. --- grub2-2.02~beta2.orig/gentpl.py +++ grub2-2.02~beta2/gentpl.py @@ -753,7 +753,7 @@ def image(defn, platform): if test x$(TARGET_APPLE_LINKER) = x1; then \ $(MACHO2IMG) $ $@; \ else \ - $(TARGET_OBJCOPY) $( + cname(defn) + _OBJCOPYFLAGS) --strip-unneeded -R .note -R .comment -R .note.gnu.build-id -R .reginfo -R .rel.dyn -R .note.gnu.gold-version $ $@; \ + $(TARGET_OBJCOPY) $( + cname(defn) + _OBJCOPYFLAGS) --strip-unneeded -R .MIPS.abiflags -R .note -R .comment -R .note.gnu.build-id -R .reginfo -R .rel.dyn -R .note.gnu.gold-version $ $@; \ fi ) Thank you! Jurica --- grub2-2.02~beta2.orig/gentpl.py +++ grub2-2.02~beta2/gentpl.py @@ -753,7 +753,7 @@ def image(defn, platform): if test x$(TARGET_APPLE_LINKER) = x1; then \ $(MACHO2IMG) $ $@; \ else \ - $(TARGET_OBJCOPY) $( + cname(defn) + _OBJCOPYFLAGS) --strip-unneeded -R .note -R .comment -R .note.gnu.build-id -R .reginfo -R .rel.dyn -R .note.gnu.gold-version $ $@; \ + $(TARGET_OBJCOPY) $( + cname(defn) + _OBJCOPYFLAGS) --strip-unneeded -R .MIPS.abiflags -R .note -R .comment -R .note.gnu.build-id -R .reginfo -R .rel.dyn -R .note.gnu.gold-version $ $@; \ fi )
Bug#747535: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On 11/09/14 14:36, Ben Hutchings wrote: On Wed, 2014-09-10 at 21:36 +, Nick Phillips wrote: [...] Debian has a good and hard-earned reputation for not messing up sysadmins' changes; upgrading to systemd - however wonderful it is (and I confess to having no opinion on that) - without at least a debconf prompt of a reasonable priority telling them what is about to happen and offering a bailout, is guaranteed to lose us reputation and users. [...] I do agree that at least some kind of high-priority notice is needed. Ben. Unfortunately systemd maintainers don't agree on this. (#747535) signature.asc Description: OpenPGP digital signature
Bug#751886: [debdiff] rebuild against curl-openssl
Hi, On 12:49 Tue 23 Sep , Joachim Breitner wrote: Am Dienstag, den 23.09.2014, 13:47 +0300 schrieb Apollon Oikonomopoulos: I did a rebuild of ganeti against the modified package and it seems to work fine. But let's be a bit conservative: I can also test the new ganeti minor version (2.12) that has more haskell+SSL code and we can upload the fixed version early next week. Sounds sensible. I did some more testing and I confirm that ganeti works as expected. Note that I didn't test any of the other packages build-depending on libghc-curl-dev, but I'll try to do so in the meantime. That’d be great! Note that the only non-lib package build-depending on libghc-curl-dev, is twidge (via libghc-hoauth-dev), which I rebuilt and tested and it works fine. Furthermore, it is quite likely that the current version of twidge in the archive also suffers from the same issue, which caused it to be removed from testing, see #752734[1]. [1] https://bugs.debian.org/752734 I assume it is safe to go ahead with the upload then. Thanks, Apollon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762364: gnome-panel-data: doesn't clean up old config file :
Hi, Control: close -1 On Wed, Sep 24, 2014 at 9:26 PM, Christoph Anton Mitterer cales...@scientia.net wrote: Even if that's a long while ago, why does it mean that it can't be cleaned up anymore? Yes. We keep transitional stuff only for one Debian release. I mean it happens every now and then that maintainers forget to properly handle old config files, which they do then in on of the next releases - what's the difference if there is two weeks in between or 4 years? There should be dh helper routines to mark such file obsolete, and if its there it's removed and if not nothing happens. Otherwise all people who ever had gnome-panel-data installed will live with stale: /etc/dbus-1/system.d/org.gnome.ClockApplet.Mechanism.conf /etc/dbus-1/system.d/ /etc/dbus-1/ I checked Svn and found out that on Debian side that directory was dropped in revision 27005. That probably means that you had that configuration file modified, and thus it was not removed. (Also, apt should have warned you in any case, about not removing directory /etc/dbus-1/system.d/ which has modified files). There is really nothing I can do *now* to remove that file from your system. -- Dmitry Shachnev -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738760: libav: Add proper raspberry pi CPU detection
On 2014-09-05 00:17:15 +0200, Florian Will wrote: Hi, Please note that I'm not the bug submitter. Can you provide a patch, please? As of now, I can't. :/ I don't have the hardware to reproduce this or to verify the correctness of a patch. So I can only give a few hints about the background of this bug report. Anyone not planning to come up with a patch can probably skip it. :-) I don't know much about raspbian, and don't understand what you actually want to be changed here. I've used raspbian some time ago. The issue with some packages is that they enable ARM NEON instructions (and other illegal instructions?) during compilation, either generally for the armhf architecture, or based on what the build machine supports. The Raspberry Pi is armhf, but does not support NEON. Raspbian buildds *do* probably support NEON though. The Raspbian toolchain is configured to disable NEON. However, libav apparently still ends up with NEON instructions in the binary. That is not a problem. If NEON is disabled in the toolchain there will be still NEON specific asm included which will be only used if a CPU with NEON is detected at runtime. I'm quite certain that this works as intended. Surprisingly, NEON is supposed to get enabled for libav only if the debian/confflag script detects that the toolchain supports NEON. Still, for the libav package in Raspbian, this line was changed: #RPI -- don't build neon flavour #FLAVORS += neon That's now how I read the debian/confflags in http://security.debian.org/debian-security/pool/updates/main/liba/libav/libav_0.8.16-1.debian.tar.gz It checks if the toolchain supports NEON and other things by default. If it does *not* support NEON, the debian package will build a additional NEON flavor of the package. Building that flavor is quite pointless if a single CPU without NEON is targeted. So disabling that in raspbian makes sense. Building a NEON flavor makes sense for general distribution like Debian that will run on different CPUs with different supported instruction set extensions. That is the only relevant change I see in debian/ for the libav src package. So unless the original patch reported specifies what he wants exactly I'd say everything is fine and working as expected. The only minor issue is that if the toolchain uses NEON by default and one uses '-mfpu=' to disable it, the check will be wrong. I don;t think any of the debian toolchains are configured this way though. Janne -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762015: Subject: RFS: s3fs-fuse/1.78-1 [ITP #601789] -- FUSE-based file system backed by Amazon S3
[I don't intend to sponsor this package. Sorry!] * Andriy Senkovych jolly_ro...@itblog.org.ua, 2014-09-17, 22:00: http://mentors.debian.net/debian/pool/main/s/s3fs-fuse/s3fs-fuse_1.78-1.dsc .orig.tar.gz is not bitwise-identical to the one uscan downloads. Why? Current standards version is 3.9.6. (But beware that Lintian doesn't know about it yet!) nitpicking mode=extreme You don't have to specify full debian-policy version in the Standards-Version field. Only the first three components (that is, 3.9.5 or 3.9.6) have to be specified. (Policy §5.6.11) I think it's customary not to put any space between ( and = in relationship fields. /nitpicking There are some stray(?) 0x81 bytes in doc/man/s3fs.1 (line 74) and src/s3fs_util.cpp (line 878). codespell(1) finds a bunch of typos: README:64: happend == happened src/s3fs_util.cpp:499: infomation == information src/s3fs_util.cpp:501: infomation == information src/s3fs_util.cpp:535: infomation == information src/s3fs_util.cpp:537: infomation == information src/openssl_auth.cpp:134: destory == destroy src/curl.cpp:532: existance == existence src/curl.cpp:1908: occured == occurred src/curl.cpp:3475: charactor == character src/curl.cpp:3479: charactor == character src/curl.cpp:3514: charactor == character src/curl.cpp:3516: Charactor == Character src/s3fs.cpp:2043: responce == response src/s3fs.cpp:2565: occured == occurred src/s3fs.cpp:2691: Destory == Destroy src/s3fs.cpp:2947: occured == occurred src/s3fs.cpp:2955: Destory == Destroy src/s3fs.cpp:3903: compatability == compatibility spellintian[0] finds a few more: src/fdcache.h: ressize - resize src/fdcache.cpp: ressize - resize src/s3fs.cpp: ressize - resize src/curl.h: failuer - failure [0] https://bitbucket.org/jwilk/spellintian -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755518: laptop-mode-tools: USB Autosuspend + LVM2 filesystems = failed boot
Hi, Thank you for reporting this. On Friday 26 September 2014 03:31 PM, Ilan Cohen wrote: Hi, I have applied your patch changing the last line of /lib/udev/lmt-udev and my system still boots with / in read only mode. Matthew: Can you please confirm your results ?? running: systemd 215 udevd 215 I have the same symptoms as you describe: # systemctl status systemd-remount-fs.service ● systemd-remount-fs.service - Remount Root and Kernel File Systems Loaded: loaded (/lib/systemd/system/systemd-remount-fs.service; static) Active: failed (Result: exit-code) since Fri 2014-09-26 12:54:16 IDT; 1min 32s ago Docs: man:systemd-remount-fs.service(8) http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems Process: 510 ExecStart=/lib/systemd/systemd-remount-fs (code=exited, status=1/FAILURE) Main PID: 510 (code=exited, status=1/FAILURE) Sep 26 12:54:16 thinkpad systemd-remount-fs[510]: mount: /usr not mounted or bad option Sep 26 12:54:16 thinkpad systemd-remount-fs[510]: /bin/mount for /usr exited with exit status 32. Sep 26 12:54:16 thinkpad systemd[1]: systemd-remount-fs.service: main process exited, code=exited, status=1/FAILURE Sep 26 12:54:16 thinkpad systemd[1]: Failed to start Remount Root and Kernel File Systems. Sep 26 12:54:16 thinkpad systemd[1]: Unit systemd-remount-fs.service entered failed state. and in syslog from boot: [2.345523] systemd[1]: /usr appears to be on its own filesytem and is not already mounted. This is not a supported setup. Some things will probably break (sometimes even silently) in mysterious ways. Consult http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken for more information. -- Ilan Cohen I don't know how I should interpret this last statement. When systemd itself reports it as a setup not supported, what should we expect out of it ? What lmt-udev currently does, and with Matt's patch, it should work. Can you capture the output from the initial boot to confirm _if_ it is an LMT problem ? I do not have a setup where /usr is on a separate partition. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention.
Bug#742409: [Sereal] 2.06 fails to build on some architectures: (#47)
On 26 September 2014 12:53, Niko Tyni nt...@debian.org wrote: On Fri, Sep 26, 2014 at 12:40:12PM +0200, demerphq wrote: You are definitely my favourite person of the week. Thank you SO MUCH. I stared at that source for hours looking for this, and I missed it every time. Yeah, I needed quite a few hours with gdb to find it. Code glaring wasn't working for me either :) Well thanks a ton for your efforts. We will push your patch upstream to the Snappy project we forked from so others can benefit from your effort as well. On Wed, Sep 17, 2014 at 03:57:24PM +0200, demerphq wrote: On 17 September 2014 07:52, Niko Tyni nt...@debian.org wrote: Finally found it. Can't see how it could have worked on big endian 64 bit HPUX either as csnappy_internal_userspace.h seems to define __LITTLE_ENDIAN there too. But never mind. Jarkko wasn't certain if we had made a 64 bit or 32 bit hpux big-endian work, so I bet I was just wrong there. But, does this mean there is something else we need to fix? No, I expect it's fine now. The __hpux branch in csnappy_internal_userspace.h looks perfectly compatible with this to me. Great. Let me roll a new release and we can celebrate together a debian clean build list. OK; I expect I or somebody else from the Debian Perl group will pull it in Debian quite quickly :) I just pushed 3.002_001 out to CPAN. This is really really awesome. Thank you again. I can't tell you how pleased I am that this works on everything. Thank you for all your work on this stuff! Ditto. Its been nice working with you Debian folks, a real pleasure to get this taken care of. Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Bug#762924: tinyproxy: Not using alternate configuration file correctly
Package: tinyproxy Version: 1.8.3-3 Severity: normal Dear Maintainer, the init script suggests that you can use a file in /etc/default/tinyproxy to set another configuration file. This new configuration file is used to read the user and group under which the program should run and the pidfile from the new configuration file, yet it starts the daemon with the original configuration from /etc/tinyproxy. To get it to work, you need to change the start flags % --- --- /tmp/tinyproxy 2014-09-26 13:15:17.755239178 +0200 +++ /etc/init.d/tinyproxy 2014-09-26 13:10:57.187235206 +0200 @@ -23,6 +23,8 @@ . /etc/default/tinyproxy fi +FLAGS=-c $CONFIG + test -f $DAEMON || exit 0 set -e --- % Afterwards the configuration will be used on startup of tinyproxy. -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-0.bpo.1-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 Best regards, Andreas Steinel M.Sc. mult. IT Project Coordinator (IHK) -- eXirius IT Dienstleistungen GmbH Hochstr. 59 66115 Saarbrücken Tel.: +49 681 76157 0 Fax:+49 681 76157 77 E-Mail: i...@exirius.de WWW:http://www.exirius.de/ Geschäftsführer: Dipl.-Math. oec. Michael Royar Amtsgericht Saarbrücken HR B - 12124 UST-IdNr. DE 813085837 Steuernummer 040 108 016 19 signature.asc Description: Digital signature
Bug#755518: laptop-mode-tools: USB Autosuspend + LVM2 filesystems = failed boot
Hi,
I have found the problem, and a solution.
The problem is not lmt, nor systemd. It's initramfs-tools not properly
mounting /usr (if LVM).
In initramfs-tools version 0.117 an option has been added to mount usr if
in fstab.
The initramfs init scripts are in /usr/share/initramfs-tools. The file
responsible for activating volume groups
is scripts/local-top/lvm2
It activates the root and optionally the resume volume group only, which
means the usr volume stays inactive
and can't be mounted.
I fixed this with a quick patch, adding lvm vgchange -ay (patch attached)
Ilan
On Fri, Sep 26, 2014 at 2:36 PM, Ritesh Raj Sarraf r...@researchut.com
wrote:
Hi,
Thank you for reporting this.
On Friday 26 September 2014 03:31 PM, Ilan Cohen wrote:
Hi,
I have applied your patch changing the last line of /lib/udev/lmt-udev
and my system still boots with / in read only mode.
Matthew: Can you please confirm your results ??
running:
systemd 215
udevd 215
I have the same symptoms as you describe:
# systemctl status systemd-remount-fs.service
● systemd-remount-fs.service - Remount Root and Kernel File Systems
Loaded: loaded (/lib/systemd/system/systemd-remount-fs.service; static)
Active: failed (Result: exit-code) since Fri 2014-09-26 12:54:16 IDT;
1min 32s ago
Docs: man:systemd-remount-fs.service(8)
http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
Process: 510 ExecStart=/lib/systemd/systemd-remount-fs (code=exited,
status=1/FAILURE)
Main PID: 510 (code=exited, status=1/FAILURE)
Sep 26 12:54:16 thinkpad systemd-remount-fs[510]: mount: /usr not
mounted or bad option
Sep 26 12:54:16 thinkpad systemd-remount-fs[510]: /bin/mount for /usr
exited with exit status 32.
Sep 26 12:54:16 thinkpad systemd[1]: systemd-remount-fs.service: main
process exited, code=exited, status=1/FAILURE
Sep 26 12:54:16 thinkpad systemd[1]: Failed to start Remount Root and
Kernel File Systems.
Sep 26 12:54:16 thinkpad systemd[1]: Unit systemd-remount-fs.service
entered failed state.
and in syslog from boot:
[2.345523] systemd[1]: /usr appears to be on its own filesytem and
is not already mounted. This is not a supported setup. Some things will
probably break (sometimes even silently) in mysterious ways. Consult
http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken for
more information.
--
Ilan Cohen
I don't know how I should interpret this last statement. When systemd
itself reports it as a setup not supported, what should we expect out of it
?
What lmt-udev currently does, and with Matt's patch, it should work. Can
you capture the output from the initial boot to confirm _if_ it is an LMT
problem ? I do not have a setup where /usr is on a separate partition.
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
Necessity is the mother of invention.
--
Ilan Cohen
--- lvm2 2014-09-26 14:53:20.648542077 +0300
+++ lvm2.patch 2014-09-26 14:55:00.736539886 +0300
@@ -1,66 +0,0 @@
-#!/bin/sh
-
-PREREQ=mdadm mdrun multipath
-
-prereqs()
-{
- echo $PREREQ
-}
-
-case $1 in
-# get pre-requisites
-prereqs)
- prereqs
- exit 0
- ;;
-esac
-
-activate_vg()
-{
- local dev=$1
-
- # Make sure that we have a non-empty argument
- if [ -z $dev ]; then
- return 1
- fi
-
- # Take care of lilo boot arg, risky activating of all vg
- case $dev in
- fe[0-9]*)
- lvm vgchange -aly --ignorelockingfailure
- exit 0
- ;;
- # FIXME: check major
- /dev/root)
- lvm vgchange -aly --ignorelockingfailure
- exit 0
- ;;
- esac
-
- # Make sure that we have a d-m path
- dev=${dev#/dev/mapper/}
- if [ $dev = $1 ]; then
- return 1
- fi
-
- eval $(dmsetup splitname --nameprefixes --noheadings --rows $dev)
-
- if [ $DM_VG_NAME ] [ $DM_LV_NAME ]; then
- lvm lvchange -aly --ignorelockingfailure $DM_VG_NAME/$DM_LV_NAME
- rc=$?
- if [ $rc = 5 ]; then
- echo Unable to find LVM volume $DM_VG_NAME/$DM_LV_NAME
- fi
- fi
-}
-
-if [ ! -e /sbin/lvm ]; then
- exit 0
-fi
-
-modprobe -q dm-mod
-
-activate_vg $ROOT
-activate_vg $resume
-
-exit 0
Bug#762307: grub2: FTBFS on mipsel: objcopy:none_decompress.img[.text]: File truncated
On Fri, Sep 26, 2014 at 10:55:43AM +, Jurica Stanojkovic wrote: I have attached a new patch. It is tested on mipsel and i386. --- grub2-2.02~beta2.orig/gentpl.py +++ grub2-2.02~beta2/gentpl.py @@ -753,7 +753,7 @@ def image(defn, platform): if test x$(TARGET_APPLE_LINKER) = x1; then \ $(MACHO2IMG) $ $@; \ else \ - $(TARGET_OBJCOPY) $( + cname(defn) + _OBJCOPYFLAGS) --strip-unneeded -R .note -R .comment -R .note.gnu.build-id -R .reginfo -R .rel.dyn -R .note.gnu.gold-version $ $@; \ + $(TARGET_OBJCOPY) $( + cname(defn) + _OBJCOPYFLAGS) --strip-unneeded -R .MIPS.abiflags -R .note -R .comment -R .note.gnu.build-id -R .reginfo -R .rel.dyn -R .note.gnu.gold-version $ $@; \ fi ) Thanks for testing. I committed a similar version this morning (when I tagged this bug pending). Regards, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747535: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On Fri, 2014-09-26 at 13:04 +0200, Carlos Alberto Lopez Perez wrote: On 11/09/14 14:36, Ben Hutchings wrote: On Wed, 2014-09-10 at 21:36 +, Nick Phillips wrote: [...] Debian has a good and hard-earned reputation for not messing up sysadmins' changes; upgrading to systemd - however wonderful it is (and I confess to having no opinion on that) - without at least a debconf prompt of a reasonable priority telling them what is about to happen and offering a bailout, is guaranteed to lose us reputation and users. [...] I do agree that at least some kind of high-priority notice is needed. Ben. Unfortunately systemd maintainers don't agree on this. (#747535) As you can see from that bug report the systemd maintainers overrides every attempt to change severity of that bug to wishlist and wontfix. Is it possible to reassign this bug to the CTTE, as the systemd-shim | systemd-sysv debate was in #762194 as a follow-up of the libpam-systemd bug #746578. Do you have to be a member of the CTTE to do this? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762835: error exit on dafileserver (segfault)
Hello, Am 25.09.2014 um 22:25 schrieb Benjamin Kaduk: On Thu, 25 Sep 2014, Thomas Otto wrote: Package: openafs-fileserver Version: 1.6.1-3+deb7u2 Severity: serious ... Unfortunately, the core file is not particularly helpful, as the stack trace for the faulting thread is garbage. It looks like OPENAFS-SA-2014-002 is fixed in wheezy-backports but not in wheezy itself. I have no particular reason to think that that use of uninitialized memory is responsible for your crash, of course, but can ask if you are willing to run the newer package from -backports. Now i updated the packages with wheezy-backports. For the last 4 hours the daemon works fine :) That the issues started just a week or two ago is rather odd, as I don't see any changelog entries in any relevant-seeming packages on my VM from around that time. Do you have apt logs that might indicate whether a particular package update was correlated with the onset of the crashes? I didn't see anything relevant, but attached the log. Are you in a position to say anything about the usage patterns of your AFS clients, in case it becomes necessary to try to reproduce the crash locally? Unfortunately i don't had an idea, what occurs the problem. So i can't reproduce this. I installed this as a new openafs-fileserver to migrate all volumes from our very old (hardware) other servers. So this server has SAN-Storage and a high number of volumes (most of them are unused). best regards Thomas -- Thomas Otto, Dipl.-Inf. Friedrich-Schiller-Universität Jena Rechenzentrum Am Johannisfriedhof 2 D-07743 Jena Tel.: 03641/9-40530 Fax.: 03641/9-40630 Aptitude 0.6.8.2: log report Tue, Sep 2 2014 08:18:05 +0200 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 1 packages, and remove 0 packages. === [UPGRADE] liblua5.1-0:amd64 5.1.5-4 - 5.1.5-4+deb7u1 === Log complete. Aptitude 0.6.8.2: log report Wed, Sep 3 2014 14:09:08 +0200 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 1 packages, and remove 0 packages. 609 kB of disk space will be used === [INSTALL] iptraf:amd64 === Log complete. Aptitude 0.6.8.2: log report Wed, Sep 3 2014 15:03:55 +0200 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 2 packages, and remove 0 packages. 1,371 kB of disk space will be used === [INSTALL, DEPENDENCIES] libpcap0.8:amd64 [INSTALL] tcpdump:amd64 === Log complete. Aptitude 0.6.8.2: log report Wed, Sep 3 2014 15:04:45 +0200 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 14 packages, and remove 0 packages. 71.6 MB of disk space will be used === [INSTALL, DEPENDENCIES] libasound2:amd64 [INSTALL, DEPENDENCIES] libc-ares2:amd64 [INSTALL, DEPENDENCIES] libcap2-bin:amd64 [INSTALL, DEPENDENCIES] libjack-jackd2-0:amd64 [INSTALL, DEPENDENCIES] libpam-cap:amd64 [INSTALL, DEPENDENCIES] libportaudio2:amd64 [INSTALL, DEPENDENCIES] libsamplerate0:amd64 [INSTALL, DEPENDENCIES] libsmi2ldbl:amd64 [INSTALL, DEPENDENCIES] libwireshark-data:amd64 [INSTALL, DEPENDENCIES] libwireshark2:amd64 [INSTALL, DEPENDENCIES] libwiretap2:amd64 [INSTALL, DEPENDENCIES] libwsutil2:amd64 [INSTALL, DEPENDENCIES] wireshark-common:amd64 [INSTALL] wireshark:amd64 === Log complete. Aptitude 0.6.8.2: log report Fri, Sep 5 2014 09:03:14 +0200 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 1 packages, and remove 0 packages. 1,024 B of disk space will be used === [UPGRADE] procmail:amd64 3.22-20 - 3.22-20+deb7u1 === Log complete. Aptitude 0.6.8.2: log report Wed, Sep 10 2014 08:09:34 +0200 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 2 packages, and remove 0 packages. 1,024 B of disk space will be used === [UPGRADE] file:amd64 5.11-2+deb7u3 - 5.11-2+deb7u4 [UPGRADE] libmagic1:amd64 5.11-2+deb7u3 - 5.11-2+deb7u4
Bug#762925: RM: rakudo [mipsel] -- ANAIS; depends on nqp package that FTBS on mipsel
Package: ftp.debian.org Severity: normal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756464: upgrade-reports: [kfreebsd] dist-upgrade to jessie removes the kernel
Hi, On 23:11, Michael Gilbert wrote: Wouldn't this be fixed somewhat simply if freebsd-net-tools had a depends: kfreebsd-image-10? So even though freebsd-image-9 gets removed due the breaks, the user will at least have the newer kernel and a bootable system. That would work, except any chroot or jail would install a kernel. I think, even sbuild running on the buildds would then install a kernel image and modules inside the build chroot, and that's obviously wrong. APT understands it should remove kfreebsd-image-9 but just doesn't know to install kfreebsd-image-10; I wonder if a Linux dist-upgrade from squeeze to wheezy pulls in linux-image-3.2 automatically, and how it does that? I know Linux packaging does show a prompt if you try to remove the last kernel image from the system; something similar would at least alert users if a dist-upgrade is going wrong, although there must be a way to fix this to do it right. Perhaps kfreebsd-image-10 needs to 'Provide' a newer kfreebsd-image-9 version (and adjust the Breaks to that version), or something ugly like that? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762364: gnome-panel-data: doesn't clean up old config file :
Control: reopen -1 On 26/09/14 13:07, Dmitry Shachnev wrote: Hi, Control: close -1 On Wed, Sep 24, 2014 at 9:26 PM, Christoph Anton Mitterer cales...@scientia.net wrote: Even if that's a long while ago, why does it mean that it can't be cleaned up anymore? Yes. We keep transitional stuff only for one Debian release. I mean it happens every now and then that maintainers forget to properly handle old config files, which they do then in on of the next releases - what's the difference if there is two weeks in between or 4 years? There should be dh helper routines to mark such file obsolete, and if its there it's removed and if not nothing happens. Otherwise all people who ever had gnome-panel-data installed will live with stale: /etc/dbus-1/system.d/org.gnome.ClockApplet.Mechanism.conf /etc/dbus-1/system.d/ /etc/dbus-1/ I checked Svn and found out that on Debian side that directory was dropped in revision 27005. That probably means that you had that configuration file modified, and thus it was not removed. (Also, apt should have warned you in any case, about not removing directory /etc/dbus-1/system.d/ which has modified files). There is really nothing I can do *now* to remove that file from your system. There's dpkg-maintscript-helper's rm_conffile. That won't help in cases where the user has *already* removed the package, but for those that still have it, it will work, and is the right thing to do. So we should do it. You can find examples of this in other GNOME packages, e.g. gnome-settings-daemon. In many cases, this was only noticed after the file had been removed, but that doesn't mean we can't fix it after the fact, as Christoph suggests. Regards, Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762926: RM: nqp [mipsel] -- ANAIS; FTBS on mipsel
Package: ftp.debian.org Severity: normal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734599: Please help with Java lib
On 09/26/2014 09:48 AM, Andreas Tille wrote: Hi Olivier, On Fri, Sep 26, 2014 at 09:23:47AM +0200, Olivier Sallou wrote: On 09/25/2014 10:19 PM, Andreas Tille wrote: Hi Debian Java folks, it seems there is no real progress in this issue. Do you have any hint what to do. BTW (as in other cases): if you prefer maintaining libsnappy-java in Debian Java team I'd happily move the packaging into your Git repository. From my last post, I think that issue is (after patch is applied) that snappy lib is too old. Seems that Java lib is using a more recent version: SnappyTests Exception in thread main java.lang.UnsatisfiedLinkError: org.xerial.snappy.SnappyNative.maxCompressedLength(I)I at org.xerial.snappy.SnappyNative.maxCompressedLength(Native Method) at org.xerial.snappy.Snappy.maxCompressedLength(Snappy.java:316) at org.xerial.snappy.Snappy.rawCompress(Snappy.java:329) at org.xerial.snappy.Snappy.compress(Snappy.java:88) at SnappyTests.main(SnappyTests.java:12) Tje maxCompressedLength sould be available in a new version Sorry, I might miss the point of your mail. This means exactly what for the package? In a post in the bug, I provided a patch to fix the Native library loading. The problem is at execution, where the Java lib tries to use some methods in the native lib. Those methods are not available in the native lib currently in Debian. I think there is a newer upstream release for the native library that integrates them. But I do not know if the Java lib upstream team uses official releases. For what I understood, once patch is applied, is that the Java lib version needs to match a specific version (newer?) of the native lib. Olivier Kind regards Andreas. -- Olivier Sallou IRISA / University of Rennes 1 Campus de Beaulieu, 35000 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755518: laptop-mode-tools: USB Autosuspend + LVM2 filesystems = failed boot
sorry the attached patch earlier was the wrong file. Reattaching correct patch. On Fri, Sep 26, 2014 at 2:36 PM, Ritesh Raj Sarraf r...@researchut.com wrote: Hi, Thank you for reporting this. On Friday 26 September 2014 03:31 PM, Ilan Cohen wrote: Hi, I have applied your patch changing the last line of /lib/udev/lmt-udev and my system still boots with / in read only mode. Matthew: Can you please confirm your results ?? running: systemd 215 udevd 215 I have the same symptoms as you describe: # systemctl status systemd-remount-fs.service ● systemd-remount-fs.service - Remount Root and Kernel File Systems Loaded: loaded (/lib/systemd/system/systemd-remount-fs.service; static) Active: failed (Result: exit-code) since Fri 2014-09-26 12:54:16 IDT; 1min 32s ago Docs: man:systemd-remount-fs.service(8) http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems Process: 510 ExecStart=/lib/systemd/systemd-remount-fs (code=exited, status=1/FAILURE) Main PID: 510 (code=exited, status=1/FAILURE) Sep 26 12:54:16 thinkpad systemd-remount-fs[510]: mount: /usr not mounted or bad option Sep 26 12:54:16 thinkpad systemd-remount-fs[510]: /bin/mount for /usr exited with exit status 32. Sep 26 12:54:16 thinkpad systemd[1]: systemd-remount-fs.service: main process exited, code=exited, status=1/FAILURE Sep 26 12:54:16 thinkpad systemd[1]: Failed to start Remount Root and Kernel File Systems. Sep 26 12:54:16 thinkpad systemd[1]: Unit systemd-remount-fs.service entered failed state. and in syslog from boot: [2.345523] systemd[1]: /usr appears to be on its own filesytem and is not already mounted. This is not a supported setup. Some things will probably break (sometimes even silently) in mysterious ways. Consult http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken for more information. -- Ilan Cohen I don't know how I should interpret this last statement. When systemd itself reports it as a setup not supported, what should we expect out of it ? What lmt-udev currently does, and with Matt's patch, it should work. Can you capture the output from the initial boot to confirm _if_ it is an LMT problem ? I do not have a setup where /usr is on a separate partition. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. -- Ilan Cohen --- /usr/share/initramfs-tools/scripts/local-top/lvm2 2014-09-26 14:53:20.648542077 +0300 +++ /usr/share/initramfs-tools/scripts/local-top/lvm2.new 2014-09-26 15:00:22.752532840 +0300 @@ -62,5 +62,6 @@ activate_vg $ROOT activate_vg $resume +lvm vgchange -ay exit 0
Bug#762927: debian-security-support: [INTL:nl] Dutch debconf template translation for debian-security-support
Package: debian-security-support Version: 2014.09.07 Severity: wishlist Tags: patch l10n -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Please find attached the Dutch translation of the debconf strings for debian-security-support. The translation has been reviewed by the debian-l10n-dutch team and future request can be targetted at that team. Paul - -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (500, 'stable'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUJVaUAAoJEJxcmesFvXUK3z0IAMWo9B9e80xUrGbxUHWhG4Bn ItN1zR7MRv4ECK2DtXKE8QWvRi2yu3S7u0sXZqs1EeFzNpp3n0Kuy1axN6odRkIW +/AIwmdI82PvnTPdq758ceDTimZN56xZTB3uz5ypxlcZ8W47sfC4zO3ahFTYXCuA oNu8RVXR8l5R+OlA95n3y7p+OprGboCXcCly6wQ/EB+TD8i1P6/EhYHxs4zrVvBN OofM6MC2P0DAK19yffFMgEfOJc9qDkAlmONCtg44BmBDh19tfYt2cycu9xnTBVoM dZKrbq9S6rzmWJjzwnxnKeJztZexbPedd8r6ILs6FEoKhKG6zXp0F5DGPwwSODs= =3ahz -END PGP SIGNATURE- # The debian-security-support debconf templates # Copyright (C) 2014 Debian Security Team # This file is distributed under the same license as the debian-security-support package. # Paul Gevers elb...@debian.org, 2014. # msgid msgstr Project-Id-Version: debian-security-support\n Report-Msgid-Bugs-To: debian-security-supp...@packages.debian.org\n POT-Creation-Date: 2014-06-05 06:50+0200\n PO-Revision-Date: 2014-09-20 17:32+0100\n Last-Translator: Paul Gevers elb...@debian.org\n Language-Team: Debian Dutch l10n Team debian-l10n-du...@lists.debian.org\n Language: nl\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n #. Type: text #. Description #: ../debian-security-support.templates:2001 msgid Ended security support for one or more packages msgstr Beëindigde beveiligingsondersteuning voor één of meerdere pakketten #. Type: text #. Description #: ../debian-security-support.templates:2001 msgid Unfortunately, it has been necessary to end security support for some packages before the end of the regular security maintenance life cycle. msgstr Helaas is het noodzakelijk om de beveiligingsondersteuning voor enkele pakketten te beëindigen vóór het einde van de reguliere periode voor beveiligingsupdates. #. Type: text #. Description #. Type: text #. Description #: ../debian-security-support.templates:2001 #: ../debian-security-support.templates:3001 msgid The following packages found on this system are affected by this: msgstr Het betreft de volgende pakketten op dit systeem: #. Type: text #. Description #: ../debian-security-support.templates:3001 msgid Limited security support for one or more packages msgstr Gereduceerde beveiligingsondersteuning voor één of meerdere pakketten #. Type: text #. Description #: ../debian-security-support.templates:3001 msgid Unfortunately, it has been necessary to limit security support for some packages. msgstr Helaas is het noodzakelijk om de beveiligingsondersteuning voor enkele pakketten in te perken.
Bug#761172: [Debian-med-packaging] Verified problem in new version of itext5
On 09/26/2014 11:49 AM, Andreas Tille wrote: Hi, the attached quilt patch disables both failing tests in version 5.5.3. This would help making tests pass, but are we sure there is no side effect at runtime on applications? Hope this helps Andreas. On Fri, Sep 26, 2014 at 11:07:46AM +0200, Andreas Tille wrote: [please CC me I'm not a member of pkg-java-maintainers] Hi, since this package has two reverse dependencies in Debian Med (figtree, biojava3-live) I had a look into this. I tried the latest version (5.5.3) and realised, that the problem exists also there plus another one. Results : Tests in error: testExtraXObjects(com.itextpdf.text.pdf.PdfCopyTest): Can't connect to X11 window server using 'localhost:11.0' as the value of the DISPLAY variable. remoteGifTest(com.itextpdf.text.RemoteGifImageTest): itextpdf.com Tests run: 246, Failures: 0, Errors: 2, Skipped: 4 I think in principle it should be quite easy to simply exclude these tests from the test suite. Please keep in touch if any help might be needed and whether you consider upgrading to the latest version. Remark: I'd recommend using a Git repository layout including pristine-tar since the tarball will not be downloaded but created from SVN and thus it matters regarding md5sum what tarball is used. Keeping it as pristine tar would bring all maintainers on the same base. Kind regards Andreas. -- http://fam-tille.de ___ Debian-med-packaging mailing list debian-med-packag...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging -- Olivier Sallou IRISA / University of Rennes 1 Campus de Beaulieu, 35000 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#762928: procps: top changed output, removed information
Package: procps Version: 1:3.3.10-1 Severity: normal Hi, I’ve got a .toprc I share across all systems with GNU top (procps). The output normally looks like: top - 14:10:02 up 29 days, 48 min, 1 user, load average: 9.62, 9.66, 9.29 Tasks: 239 total, 6 running, 233 sleeping, 0 stopped, 0 zombie %Cpu(s): 13.1 us, 0.4 sy, 75.3 ni, 11.2 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st KiB Mem: 20604360 total, 18451700 used, 2152660 free, 263416 buffers KiB Swap: 7811068 total,0 used, 7811068 free. 2104604 cached Mem PID USER NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND […] But in sid, it now looks like: top - 14:10:01 up 10 days, 3:11, 2 users, load average: 9.62, 9.12, 8.83 Tasks: 317 total, 10 running, 306 sleeping, 0 stopped, 1 zombie %Cpu(s): 98.5/1.5 100[|] GiB Mem : 31.0/15.706 [ ] GiB Swap: 0.0/2.000[ ] PID USER NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND Please make it so that my attached /etc/skel/.toprc will retain existing behaviour, and that the new… whatever those pipes are… will not be triggered by it – maybe it can be the default if no old-format .toprc is found, but… -- System Information: Debian Release: jessie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: x32 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Versions of packages procps depends on: ii initscripts 2.88dsf-53.4 ii libc6 2.19-11 ii libncurses5 5.9+20140913-1 ii libncursesw5 5.9+20140913-1 ii libprocps41:3.3.10-1 ii libtinfo5 5.9+20140913-1 ii lsb-base 4.1+Debian13 Versions of packages procps recommends: ii psmisc 22.21-2 procps suggests no packages. -- no debconf information RCfile for top with windows # shameless braggin' Id:a, Mode_altscr=0, Mode_irixps=0, Delay_time=3.000, Curwin=0 Def fieldscur=AEhIOQTrspvuWbcdfgjyzlKNMX winflags=65208, sortindx=10, maxtasks=0 summclr=6, msgsclr=6, headclr=7, taskclr=7 Job fieldscur=ABcefgjlrstuvyzMKNHIWOPQDX winflags=62776, sortindx=0, maxtasks=0 summclr=6, msgsclr=6, headclr=7, taskclr=6 Mem fieldscur=ANOPQRSTUVbcdefgjlmyzWHIKX winflags=62776, sortindx=13, maxtasks=0 summclr=5, msgsclr=5, headclr=4, taskclr=5 Usr fieldscur=ABDECGfhijlopqrstuvyzMKNWX winflags=62776, sortindx=4, maxtasks=0 summclr=3, msgsclr=3, headclr=2, taskclr=3
Bug#762876: named assertion failure in bind9 1:9.9.5.dfsg-4.1 in mem.c
Same here: 25-Sep-2014 07:25:13.497 general: critical: mem.c:1321: REQUIRE(ptr != ((void *)0)) failed, back trace later again: 26-Sep-2014 03:11:41.432 general: critical: mem.c:1321: REQUIRE(ptr != ((void *)0)) failed, back trace 26-Sep-2014 03:11:41.432 general: critical: #0 0x7f6a7776722d in ?? 26-Sep-2014 03:11:41.432 general: critical: #1 0x7f6a759547ba in ?? 26-Sep-2014 03:11:41.432 general: critical: #2 0x7f6a7596502c in ?? 26-Sep-2014 03:11:41.432 general: critical: #3 0x7f6a77016694 in ?? 26-Sep-2014 03:11:41.432 general: critical: #4 0x7f6a76fc216a in ?? 26-Sep-2014 03:11:41.432 general: critical: #5 0x7f6a76fa9c29 in ?? 26-Sep-2014 03:11:41.432 general: critical: #6 0x7f6a76fa9d99 in ?? 26-Sep-2014 03:11:41.432 general: critical: #7 0x7f6a7701d7fd in ?? 26-Sep-2014 03:11:41.432 general: critical: #8 0x7f6a7702926b in ?? 26-Sep-2014 03:11:41.432 general: critical: #9 0x7f6a75975eeb in ?? 26-Sep-2014 03:11:41.432 general: critical: #10 0x7f6a753270a4 in ?? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#762929: radicale: Please document new features
Package: radicale Version: 0.9-1 Severity: normal Radicale 0.9 brings a few new and interesting features, like multifilesystem storage, and the git backend, but they completely lack documentation, please add some information on how to use them. As part of that, information on how to migrate to these formats is desperately needed, I would want to use them, but I don't know how! Thanks. -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (900, 'stable'), (500, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages radicale depends on: ii adduser 3.113+nmu3 ii python 2.7.3-4+deb7u1 ii python-radicale 0.9-1 radicale recommends no packages. Versions of packages radicale suggests: ii apache2-utils 2.2.22-13+deb7u3 pn courier-authdaemon none pn python-ldap none pn python-pampynone pn python-requests none pn python-sqlalchemy none -- Configuration Files: /etc/default/radicale changed [not included] /etc/radicale/config changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762930: radicale: The multifilesystem storage backend takes too much CPU
Package: radicale Version: 0.9-1 Severity: important While trying to migrate to the new multifilesystem storage backend, I naively copied all the contacts using icedove. I noticed it was taking too long, so I checked the server and found that it consumed 100% CPU for more than an hour to write about 600 records. A quick strace revealed that for every new record, it was re-creating dozens of unrelated files (probably all of them?). I have not debugged this issue, but it is clearly a problem. Also, I don't know if this is also present in the other backends, as I haven't tried doing such a bulk import. -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (900, 'stable'), (500, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages radicale depends on: ii adduser 3.113+nmu3 ii python 2.7.3-4+deb7u1 ii python-radicale 0.9-1 radicale recommends no packages. Versions of packages radicale suggests: ii apache2-utils 2.2.22-13+deb7u3 pn courier-authdaemon none pn python-ldap none pn python-pampynone pn python-requests none pn python-sqlalchemy none -- Configuration Files: /etc/default/radicale changed [not included] /etc/radicale/config changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742409: Pending fixes for bugs in the libsereal-encoder-perl package
tag 742409 + pending thanks Some bugs in the libsereal-encoder-perl package are closed in revision 9596846a36df7408d70df02a7a4884db1734e885 in branch 'master' by gregor herrmann The full diff can be seen at https://anonscm.debian.org/cgit/pkg-perl/packages/libsereal-encoder-perl.git/commit/?id=9596846 Commit message: New upstream release. Fixes FTBFS on some architectures with Niko Tyni's patch for 64-bit big-endian architectures. (Closes: #742409) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742409: [Sereal] 2.06 fails to build on some architectures: (#47)
On Fri, 26 Sep 2014 13:41:40 +0200, demerphq wrote: You are definitely my favourite person of the week. Thank you SO MUCH. I stared at that source for hours looking for this, and I missed it every time. Yay! Let me roll a new release and we can celebrate together a debian clean build list. OK; I expect I or somebody else from the Debian Perl group will pull it in Debian quite quickly :) I just pushed 3.002_001 out to CPAN. I'm working on them, will upload after a last rebuild. Then we can stare at the build logs page soon :) BTW: There's a typo in the POD: I: libsereal-encoder-perl: spelling-error-in-manpage usr/share/man/man3/Sereal::Encoder.3pm.gz overriden overridden Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Nguyên Lê: Domus De Janas signature.asc Description: Digital Signature
Bug#762931: debsources: flake8 compliance
Package: qa.debian.org Severity: minor User: qa.debian@packages.debian.org Usertags: debsources At present: /srv/debsources$ flake8 debsources/ | wc -l 228 We would like to make all Python source files flake8 (i.e. PEP8 + pyflakes) compliant, modulo justified (and documented) exceptions. Cheers. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762933: debsources: webapp should not require python-matplotlib
Package: qa.debian.org Severity: normal User: qa.debian@packages.debian.org Usertags: debsources Since the refactoring with the top-level debsources/ module, the webapp requires python-matplotlib to be installed to run properly. That is unfortunate, as matplotlib is needed only by the updater, and induces weird requirements on the webserver user (e.g., a writable /var/www/.matplotlib ?!!). We should track down and remove this dependency. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762932: aptitude: in an upgrade with 'U', aptitude chose to downgrade a package
Package: aptitude Version: 0.6.11-1 Severity: normal In my latest upgrade with 'U' from the curses interface, aptitude chose to downgrade gir1.2-evince-3.0 from 3.12.2-1 to 3.4.0-3.1. Downgrading should never be the default choice. I've attached the dpkg log excerpt corresponding to this upgrade. Note that I use the following option: Aptitude::ProblemResolver::SolutionCost removals; so that packages don't get removed. -- Package-specific info: Terminal: xterm-debian $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.6.11 compiled at Jun 9 2014 20:46:57 Compiler: g++ 4.8.3 Compiled against: apt version 4.12.0 NCurses version 5.9 libsigc++ version: 2.2.11 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 5.9.20140913 cwidget version: 0.5.17 Apt version: 4.12.0 aptitude linkage: linux-vdso.so.1 (0x7fff0fdfc000) libapt-pkg.so.4.12 = /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 (0x7f20447e4000) libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7f20445ae000) libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f2044383000) libsigc-2.0.so.0 = /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7f204417e000) libcwidget.so.3 = /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7f2043e77000) libsqlite3.so.0 = /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f2043bb1000) libboost_iostreams.so.1.55.0 = /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x7f2043999000) libxapian.so.22 = /usr/lib/libxapian.so.22 (0x7f2043584000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f2043366000) libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f204305b000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f2042d5a000) libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f2042b43000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f204279b000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f2042598000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f2042393000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7f2042178000) libbz2.so.1.0 = /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f2041f68000) liblzma.so.5 = /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f2041d44000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f2041b3c000) libuuid.so.1 = /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f2041936000) /lib64/ld-linux-x86-64.so.2 (0x7f204518e000) -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages aptitude depends on: ii aptitude-common 0.6.11-1 ii libapt-pkg4.121.0.9.1 ii libboost-iostreams1.55.0 1.55.0+dfsg-3 ii libc6 2.19-11 ii libcwidget3 0.5.17-1 ii libgcc1 1:4.9.1-15 ii libncursesw5 5.9+20140913-1 ii libsigc++-2.0-0c2a2.2.11-4 ii libsqlite3-0 3.8.6-1 ii libstdc++64.9.1-15 ii libtinfo5 5.9+20140913-1 ii libxapian22 1.2.18-1.1 Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-doc] 0.6.11-1 ii libparse-debianchangelog-perl 1.2.0-1.1 ii sensible-utils 0.0.9 Versions of packages aptitude suggests: ii apt-xapian-index 0.47 pn debtags none ii tasksel 3.27 -- no debconf information dpkg.log.xz Description: Binary data
Bug#762934: debsources: refactoring - move queries out of models.py
Package: qa.debian.org Severity: normal User: qa.debian@packages.debian.org Usertags: debsources models.py contains several classes which are used only by the web app and that have nothing to do with the ORM layer, e.g. Location, Directory, SourceFile. Similarly, models.py also contains static methods (e.g. PackageName.list_versions_from_name) that should better be moved to a query-specific module. We should refactor the code so that models.py contains only the ORM abstraction, and move query code to separate modules. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742409: [Sereal] 2.06 fails to build on some architectures: (#47)
On 26 September 2014 14:21, gregor herrmann gre...@debian.org wrote: On Fri, 26 Sep 2014 13:41:40 +0200, demerphq wrote: You are definitely my favourite person of the week. Thank you SO MUCH. I stared at that source for hours looking for this, and I missed it every time. Yay! Let me roll a new release and we can celebrate together a debian clean build list. OK; I expect I or somebody else from the Debian Perl group will pull it in Debian quite quickly :) I just pushed 3.002_001 out to CPAN. I'm working on them, will upload after a last rebuild. Then we can stare at the build logs page soon :) Looking forward to a line of green! BTW: There's a typo in the POD: I: libsereal-encoder-perl: spelling-error-in-manpage usr/share/man/man3/Sereal::Encoder.3pm.gz overriden overridden Fixed in bd00266bed177035a5621c4df9dffc9f39efd4ad and will be included in 3.003 when it is released. Also, Niko, I have pushed your fix upstream: See: https://github.com/zeevt/csnappy/pull/17 And while I was writing this mail it was applied to the upstream repo. (So fast to apply, so long to find the fix :-) thanks a lot! Yves -- perl -Mre=debug -e /just|another|perl|hacker/
Bug#762935: debsources: namespace qualified ctags
Package: qa.debian.org Severity: minor User: qa.debian@packages.debian.org Usertags: debsources [ originally reported by Olly Betts on #debian-devel ] Ctags indexing is currently non-qualified, so indexing on OO langauges will not contain class names, namespaces, etc. To fix this we should add --extra=+q to ctags invocation. About this, the ctags documentation says: However, that this could potentially more than double the size of the tag file. Micro benchmarks: - computation time is ~10-15% slower with +q - size - libreoffice (C++) zack@tytso:~/ctags-bench/libreoffice-4.1.5$ wc ../libreoffice*ctags 561396 3872260 61123731 ../libreoffice-4.1.5.ctags 972942 6799455 117133590 ../libreoffice-4.1.5.extra+q.ctags - chromium-browser (C/C++) zack@tytso:~/ctags-bench/chromium-browser-32.0.1700.123$ wc ../chromium-browser*ctags 1618199 10931585 205005488 ../chromium-browser-32.0.1700.123.ctags 2472627 17064351 342772532 ../chromium-browser-32.0.1700.123.extra+q.ctags - linux (C) zack@tytso:~/ctags-bench/linux-3.12.9$ wc ../linux*ctags 2146431 14340875 208057034 ../linux-3.12.9.ctags 2610525 17780208 269391932 ../linux-3.12.9.extra+q.ctags Bottom line: it's doable. (But will need to rerun all ctags indexing after having changed the ctags plugin code.) -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762936: gtk3 themes broken to unusability with recent gtk versions
Package: gtk3-engines-xfce Version: 3.0.1-2 Severity: normal the Xfce-basic theme, when configured in gtk3 3.14, produces a black editor window with light gray buttons and white texts -- overall probably not the intended look and barely usable when it comes to reading buttons without hovering them. other themes are less affected (eg -cadmium, -dusk and others show uniformly colored gray rectangles under texts on buttons with gradients). steps to reproduce: * blank user * create ~/.config/gtk-3.0/settings.ini: [Settings] gtk-theme-name = * Xfce-basic * launch gedit -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-trunk-amd64 (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 Versions of packages gtk3-engines-xfce depends on: ii libatk1.0-0 2.12.0-1 ii libc6 2.19-11 ii libcairo-gobject2 1.12.16-5 ii libcairo2 1.12.16-5 ii libgdk-pixbuf2.0-0 2.30.8-1 ii libglib2.0-02.42.0-1 ii libgtk-3-0 3.14.0-1 ii libpango1.0-0 1.36.7-1 gtk3-engines-xfce recommends no packages. gtk3-engines-xfce suggests no packages. -- no debconf information -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
Bug#762938: bluebird gtk3 theme does not display checkboxes
Package: murrine-themes Version: 0.98.6 Severity: important the gtk3 version of bluebird does not render checkboxes any more at all since around gtk 3.14. similar to bug #762936, it also shows gray rectangles under buttons with gradients, which might or not be related. steps to reproduce: * blank user * create ~/.config/gtk-3.0/settings.ini: [Settings] gtk-theme-name = * Xfce-basic * launch gedit * select three-bars-button, preferences * no checkboxes show (when you clock on their labels, while the mouse is down, the checkbox tick shows, but neither on nor off state is visible) -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-trunk-amd64 (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 Versions of packages murrine-themes depends on: ii gtk2-engines-murrine 0.98.1.1-5 murrine-themes recommends no packages. murrine-themes suggests no packages. -- no debconf information -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
