Bug#745130: apt should tell if updates are available
at bottom :-
On 4/22/14, James McCoy james...@debian.org wrote:
On Tue, Apr 22, 2014 at 09:38:16AM +0530, shirish शिरीष wrote:
On 4/22/14, James McCoy james...@debian.org wrote:
On Fri, Apr 18, 2014 at 05:13:46PM +0200, David Kalnischkies wrote:
You could also use a hook script with APT::Update::Post-Invoke to
do/display whatever you might want to.
Something like the daptup package?
I just saw the dataup package. It seems to do the thing I want but
don't know how to use the 'hook script with APT::Update:Post-Invoke to
do/display whatever you might want to' .
daptup provides an apt config file which defines APT::Update::Pre-Invoke
and APT::Update::Post-Invoke hooks. Those hooks determine what packages
are new/changed and display them to you.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org
Hi all,
I have used and am using apt-listchanges and apt-listbugs to let me
know before-hand if there are any issues when doing an aptitude
upgrade or an aptitude install (upgrading one or more binaries by
name).
I don't have any idea if apt-listchanges would have any conflicts with
apt-listchanges.conf
This is my /etc/apt/listchanges.conf :-
$ cat /etc/apt/listchanges.conf
[apt]
frontend=gtk
email_address=root
confirm=1
save_seen=/var/lib/apt/listchanges.db
which=both
I installed dataup package. I saw that /etc/apt/apt.conf.d/11daptup is
of two lines only :-
$ cat /etc/apt/apt.conf.d/11daptup
APT::Update::Pre-Invoke { if [ -x /usr/bin/daptup ]; then
/usr/bin/daptup --pre; fi; };
APT::Update::Post-Invoke { if [ -x /usr/bin/daptup ]; then
/usr/bin/daptup --post; fi; };
I don't know what changes (if any) have to be made to those two lines.
I also there is an /etc/daptup.conf file which has too many options,
some of which I'm confused about.
# Daptup has the ability to find installed packages that have version prepared
# by package maintainer a lot of time ago and have more recent install
# candidate (outdated packages). Enable this check?
# Possible values: n - no, y - yes.
DAPTUP_CHECK_FOR_OUTDATED_PACKAGES=y
# If we check for outdated packages, what minimal age (in days) must
package to have
# to be treated as outdated?
DAPTUP_MINIMAL_DAY_COUNT_TREATING_OUTDATED=90
I don't think we can say 90 days are enough for packages to be
considered outdated.
The only packages I would say outdated are those which are orphaned.
It would be good to see what you think of them.
I have no idea what this one means :-
DAPTUP_NEW_DISPLAY_FORMAT=%10p - %80d
Looking forward to know.
The best scenario would be being able to use apt-listchanges with
aptitude and daptup with apt (if it's possible).
--
Regards,
Shirish Agarwal शिरीष अग्रवाल
My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745302: RFS: fcitx-skk/0.1.0-1 [ITP]
Hi,
I can sponsor your package.
If you can not find a sponsor, let me know.
Best regards,
Nobuhiro
2014-04-21 23:40 GMT+09:00 Yusuke YATSUO yyat...@debian.or.jp:
Hi,
On Sun, Apr 20, 2014 at 03:34:51AM -0700, Vincent Cheng wrote:
Would you consider maintaining this within the Debian IME Packaging
team (you can find more info, including how to contact the team, at
[1])? You'll likely be able to find more sponsors for your package as
well as for future uploads.
[1] https://wiki.debian.org/Teams/IMEPackagingTeam
Thanks for the tip.
I'll talk to the IME Packaging team.
In the meantime, I would appriciate any comments or feedback with regard
to the package.
Regards,
Yusuke YATSUO
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745472: pam-pythong: might include obfuscated javascript file searchindex.js without source
Package: pam-python Version: 1.0.2-1 Lintian report about a possible RC problem with this package: source-is-missing doc/html/searchindex.js Please have a look and check if this is a problem or not. Would hate to loose this package from Jessie, as it is used on my systems, by libpam-mklocaluser and in Debian Edu. -- 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#745473: icedove: status bar doesn't work as expected
Package: icedove Version: 24.4.0-1 Severity: important The stauts bar only shows the count of mails in the directory at the left side. I miss the Information of getting new mails from different mail accounts. I can't move this part withount any influence to the whole window. Kind regards -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (700, 'testing'), (600, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-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 icedove depends on: ii debianutils 4.4 ii fontconfig2.11.0-5 ii libasound21.0.27.2-3 ii libatk1.0-0 2.12.0-1 ii libc6 2.18-4 ii libcairo2 1.12.16-2 ii libdbus-1-3 1.8.0-3 ii libdbus-glib-1-2 0.102-1 ii libevent-2.0-52.0.21-stable-1 ii libffi6 3.1~rc1+r3.0.13-12 ii libfontconfig12.11.0-5 ii libfreetype6 2.5.2-1 ii libgcc1 1:4.8.2-16 ii libgdk-pixbuf2.0-02.30.6-1 ii libglib2.0-0 2.40.0-2 ii libgtk2.0-0 2.24.23-1 ii libhunspell-1.3-0 1.3.2-7 ii libnspr4 2:4.10.4-1 ii libnss3 2:3.16-1 ii libpango-1.0-01.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii libpangoft2-1.0-0 1.36.3-1 ii libpixman-1-0 0.32.4-1 ii libsqlite3-0 3.8.4.3-1 ii libstartup-notification0 0.12-3 ii libstdc++64.8.2-16 ii libvpx1 1.3.0-2 ii libx11-6 2:1.6.2-1 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-1 Versions of packages icedove recommends: ii hunspell-en-us [hunspell-dictionary] 20070829-6 ii myspell-de-de [myspell-dictionary]20120607-1 Versions of packages icedove suggests: ii fonts-lyx 2.0.6-1 ii libgssapi-krb5-2 1.12.1+dfsg-1 -- 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#727179: Please update symbol table to support mips64(el) and mipsn32(el)
Hey, any progress of the bug? Please consider include it. -- Yunqiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745474: mirror submission for ftp.agh.edu.pl
Package: mirrors Severity: wishlist Submission-Type: new Site: ftp.agh.edu.pl Type: leaf Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc Archive-ftp: /debian/ Archive-http: /debian/ IPv6: yes Archive-upstream: ftp.pl.debian.org Updates: once Maintainer: Boguslaw Juza bog...@uci.agh.edu.pl Country: PL Poland Location: AGH Kraków Sponsor: AGH University of Science and Technology http://www.agh.edu.pl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745302: RFS: fcitx-skk/0.1.0-1 [ITP]
Hi,
I checked your package.
debian/changelog:
fcitx-skk (0.1.0-1) UNRELEASED; urgency=low
* Initial release (Closes: #733316)
-- Yusuke YATSUO yyat...@debian.or.jp Thu, 3 Apr 2014 00:10:43 +0900
Please set distribution.
debian/control:
Source: fcitx-skk
Section: utils
Priority: optional
Maintainer: Yusuke YATSUO yyat...@debian.or.jp
Build-Depends: debhelper (= 9), cmake, fcitx-libs-dev (= 1:4.2.8),
fcitx-bin (= 1:4.2.8), libskk-dev, libqt4-dev
Standards-Version: 3.9.5
Homepage: https://github.com/fcitx/fcitx-skk
#Vcs-Git: git://git.debian.org/collab-maint/fcitx-skk.git
#Vcs-Browser: http://git.debian.org/?p=collab-maint/fcitx-skk.git;a=summary
Package: fcitx-skk
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, fcitx-bin, fcitx-data (=
1:4.2.6), fcitx-modules, skk
Recommends: fcitx (= 1:4.2.6)
Why do you set = 1:4.2.6 ? You set to = 1:4.2.8 in Build-Depends.
I think to match the version is good in order to avoid the confusion.
Breaks: fcitx ( 1:4.2.6)
Why do you set Breaks? Could you explain about this?
And your package FTBFS with pbuilder/unstable.
Could you check your environment?
I think you forgot adding libqt4-dev to Build-Depends.
-
-- found libskk, version 1.0.0
qmake: could not exec '/usr/lib/x86_64-linux-gnu/qt4/bin/qmake': No
such file or directory
qmake: could not exec '/usr/lib/x86_64-linux-gnu/qt4/bin/qmake': No
such file or directory
qmake: could not exec '/usr/lib/x86_64-linux-gnu/qt4/bin/qmake': No
such file or directory
CMake Warning at /usr/share/cmake-2.8/Modules/FindQt4.cmake:659 (message):
/usr/bin/qmake reported QT_INSTALL_LIBS as but QtCore could not be found
there. Qt is NOT installed correctly for the target build environment.
Call Stack (most recent call first):
/usr/share/cmake-2.8/Modules/FindQt.cmake:155 (include)
CMakeLists.txt:30 (find_package)
CMake Error at /usr/share/cmake-2.8/Modules/FindQt4.cmake:664 (message):
Could NOT find QtCore. Check
/tmp/buildd/fcitx-skk-0.1.0/obj-x86_64-linux-gnu/CMakeFiles/CMakeError.log
for more details.
Call Stack (most recent call first):
/usr/share/cmake-2.8/Modules/FindQt.cmake:155 (include)
CMakeLists.txt:30 (find_package)
-
Best regards,
Nobuhiro
2014-04-20 19:27 GMT+09:00 yusuke YATSUO yyat...@debian.or.jp:
Package: sponsorship-requests
Severity: wishlist
Dear mentors,
I am looking for a sponsor for my package fcitx-skk
* Package name: fcitx-skk
Version : 0.1.0-1
Upstream Author : Yichao Yu yyc1...@gmail.com
* URL : https://github.com/fcitx/fcitx-skk
* License : GPL-2+
Section : utils
It builds those binary packages:
fcitx-skk - Japanese SKK input engine for Fcitx
To access further information about this package, please visit the
following URL:
http://mentors.debian.net/package/fcitx-skk
Alternatively, one can download the package with dget using this command:
dget -x
http://mentors.debian.net/debian/pool/main/f/fcitx-skk/fcitx-skk_0.1.0-1.dsc
Regards,
Yusuke YATSUO
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745475: broken auto-removal logic
Package: release.debian.org
Severity: serious
This autoremoval appears to be incorrect - the dependency on nagios3 can
also be satisfied by icinga
This dependency was changed in the most recent upload
On 22/04/14 06:39, Debian testing autoremoval watch wrote:
ganglia-nagios-bridge 1.1.0-2 is marked for autoremoval from testing on
2014-05-10
It (build-)depends on packages with these RC bugs:
737441: nagios3: [src:nagios3] Sourceless file (minified) (jquery)
http://anonscm.debian.org/gitweb/?p=pkg-monitoring/ganglia-nagios-bridge.git;a=blob;f=debian/control;h=bdaf436511e7f0897fb812249a94d65c2b748448;hb=HEAD
Depends: ${misc:Depends}, python, nagios3 | icinga
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688816: crash: corrupted double-linked list
Package: rtorrent Version: 0.9.2-1 Followup-For: Bug #688816 I have another bit of information about the crash. It appears to be related to the network interface going down. The host that runs rtorrent uses DHCP to get its IP. When it fails to renew its IP address lease, rtorrent seems to crash some 5-15 minutes after the network interface is deconfigured. This sounds related to https://bugs.debian.org/721995 -- rtorrent segfaults when IP address changes after a sleep. -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to bg_BG.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages rtorrent depends on: ii libc6 2.13-38+deb7u1 ii libcurl37.26.0-1+wheezy9 ii libgcc1 1:4.7.2-5 ii libncursesw55.9-10 ii libsigc++-2.0-0c2a 2.2.10-0.2 ii libstdc++6 4.7.2-5 ii libtinfo5 5.9-10 ii libtorrent140.13.2-1 ii libxmlrpc-core-c3 1.16.33-3.2 rtorrent recommends no packages. Versions of packages rtorrent suggests: ii screen 4.1.0~20120320gitdb59704-7 -- 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#744781: please remove ubuntu from dashboard or at least provide an option to hide it
On Tue, Apr 22, 2014 at 4:37 AM, Steve Langasek wrote: I don't have a particularly strong opinion on whether Ubuntu bugs should be displayed in the dashboard by default; but I don't have the impression that people who are objecting to it are doing so out of a desire to improve Debian, only out of a dislike of Ubuntu. And I think that's a shame. I have found the bugs reported by Ubuntu users often also apply to Debian packages and found that the Ubuntu links in the PTS and DDPO are quite useful. Ubuntu has way more users than Debian and we should welcome their input in improving Debian. I feel that staying closed and ignoring other distributions, especially Debian derivatives, is both against the spirit of the social contract and a quite bad idea for the Debian distribution and project. I personally pay attention to bugs reported on my Debian packages in various distributions (everything from RPM distros to Debian derivatives) by using the whohas tool. If there were other derivatives with similar sources of bug data that could be imported into the dashboard, and someone wanted to do the work to integrate those sources with the PTS etc., I would be in favor of them also being shown by default (though we'd probably want to aggregate all of them in the default view to not wind up with an endless set of columns each reporting zero bugs for the common case). It's always easier for someone to hide the information they decide they don't need, than to discover the information they don't know is available. Based on a survey of the bug links in the Debian derivatives census, only Ubuntu and UltimediaOS assign bugs to individual packages. The latter doesn't appear to have an easy way to link to bugs for individual packages. https://lists.debian.org/debian-derivatives/2012/09/msg7.html One thing that we can link to is patches for many derivatives. Due to snapshot.d.o hardware outages and disk space issues on alioth that effort is stalled but I'm hoping to revive it soon. http://dex.alioth.debian.org/census/patches/ -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728049: adt-virt-schroot: avoid debconf prompts on running tests
Hey Arthur, Martin Pitt [2013-11-19 19:05 +0100]: Could you perhaps do the following: Configure your schroot to use readline, and then run adt-run nss-pam-ldapd_0.9.2-1.dsc -d --log-file=/tmp/log --- adt-virt-schroot sid-snap and then attach /tmp/log? This should show me at which point the prompt occurs (test/build/binary/etc. dependency), and also include debugging information from adt-run. Do you have a chance to do this? I'm still unable to reproduce this behaviour. We've been running autopkgtest in production for a long time now, in both Debian and Ubuntu, and never ran into debconf prompts. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#648779: [Pkg-fonts-devel] Bug#648779: ttf-ecolier-court: Wrong upstream homepage.
Quoting Francesca Ciceri (madame...@debian.org): Hi, after a bit of googling I came to this page: http://douteau.ecolier.perso.sfr.fr/ My french is almost non-existant, but seems to me that this is the new (?) homepage for this font. Christian, can you confirm this? Or have you any news from upstream about his webpage? Yes, this is the new home page for the Ecolier font. It's also a page for another font named Odumo (http://douteau.ecolier.perso.sfr.fr/page_odumo.htm) where the font is designed to allow partial display of words in order to challenge children with some exercises during the learning of readingby reading partial words. Both these fonts are indeed designed for teaching, mostly. signature.asc Description: Digital signature
Bug#745476: s3ql: automatic self test is failing
Package: s3ql Version: 2.8.1+dfsg-1 On URL: http://ci.debian.net/#package/s3ql I discovered that the automatic self test of s3ql is failing. This is the reported fail at the end of the log: tests/t2_block_cache.py:114: cache_tests.test_destroy_deadlock FAILED === FAILURES === __ cache_tests.test_destroy_deadlock ___ Traceback (most recent call last): File /tmp/adt-run.0493J4/apt0-build/s3ql-2.8.1+dfsg/tests/t2_block_cache.py, line 163, in test_destroy_deadlock self.cache.destroy() File /usr/lib/python3/dist-packages/_pytest/python.py, line 1009, in __exit__ pytest.fail(DID NOT RAISE) File /usr/lib/python3/dist-packages/_pytest/runner.py, line 456, in fail raise Failed(msg=msg, pytrace=pytrace) Failed: DID NOT RAISE Interrupted: stopping after 1 failures === 1 failed, 104 passed, 97 skipped in 4.65 seconds === adt-run: tests done. Is there perhaps something wrong with s3ql as installed? -- 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#745444: [Pkg-running-devel] Bug#745444: antpm: FTBFS: antpm-downloader.1: No such file or directory
Quoting Aaron M. Ucko (u...@debian.org): Source: antpm Version: 1.16-2 Severity: serious Justification: fails to build from source Builds of antpm explicitly targetting only its architecture-dependent binary packages (as on the autobuilders, or with debuild -B or the like) have been failing, even though those are in fact its only binary packages: dh_installman -a debian/antpm-downloader.1: No such file or directory at /usr/bin/dh_installman line 130. make: *** [binary-arch] Error 2 The problem appears to be that a handful of important commands appear only in the build target, which such builds skip. I'd suggest either moving those commands to the override_dh_install target, which should run in time, or renaming build to build-arch and having build depend on build-arch. Thanks for the report and analysis, Aaron. Kristof, can you check this? My suggestion would be using the first option (moving to override_dh_install) which makes more sense than renaming buildas the commands run in the build target are not exactly build commands. signature.asc Description: Digital signature
Bug#744877: Pending fixes for bugs in the shadow package
tag 744877 + pending thanks Some bugs in the shadow package are closed in revision 25cba03d2dac565fab667884bf711439f9a70544 in branch 'master' by Christian Perrier The full diff can be seen at http://anonscm.debian.org/gitweb/?p=pkg-fonts/shadow.git;a=commitdiff;h=25cba03 Commit message: Fix 1000_configure_userns to avoid dropping a needed #endif Closes: #744877 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745477: RM: libplrpc-perl -- RoM; unresponsive upstream, security issues
Package: ftp.debian.org Severity: normal https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734789 Bug#734789: [CVE-2013-7284] Remote pre-authentication code execution in PlRPC The RC bug above hasn't been fixed upstream for a long time. Please remove libplrpc-perl. signature.asc Description: Digital signature
Bug#745478: ITP: distkeys -- Distkeys - upload SSH keys to servers and more
Package: wnpp Severity: wishlist Owner: Martin Steigerwald m...@teamix.de * Package name: distkeys Version : 1.0 Upstream Author : teamix GmbH, Martin Steigerwald m...@teamix.de * URL : https://github.com/teamix/distkeys * License : GPL-2 Programming Lang: Ruby Description : Distkeys - upload SSH keys to servers and more Distkeys distributes a list of public SSH keys to a list of servers. It reaches servers behind a firewall as well by using SSH port forwarding. Furthermore it can execute a command or a script on a list of hosts or copy a file to them. We use this package to distribute our own public keys to our own and customer machines. I plan to maintain upstream and Debian packaging. In comparison with other solutions I see the following specifics: - It is mainly targetted at distribution of SSH keys. - It can access servers behind a firewall via port forwarding. - It downloads authorized_keys, does all changes and uploads them in one go, and thus is quite fast. - It tries to play it safe by backuping of authorized_keys intelligently. We would like to share distkeys in the hope it is useful to others. Current state of packaging is almost ready to review. TODO: - Review adaptions to make it run with Ruby 1.9. - Get it reviewed by a sponsor (see RFS bug below). The packaging is using git-buildpackage with separate upstream and debian packaging branches. It is already lintian clean, except for a debian/watch file which I consider to be unnecessary in this case. See also: RFS: distkeys/1.0 -- distribute SSH keys https://bugs.debian.org/712787 Which I will update in a moment with some actual information. (Please excuse long signature, it is centrally managed.) -- Martin Steigerwald Consultant / Trainer teamix GmbH Südwestpark 43 90449 Nürnberg fon: +49 911 30999 55 fax: +49 911 30999 99 mail: martin.steigerw...@teamix.de web: http://www.teamix.de blog: http://blog.teamix.de Amtsgericht Nürnberg, HRB 18320 Geschäftsführer: Oliver Kügow, Richard Müller ** Wissenstag Spezial „Datacenter Networking“ – 21.05.2014 ** http://www.teamix.de/spezial -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744938: nmap: manual page missing text
On Wed, Apr 16, 2014 at 6:15 AM, Oskar Liljeblad os...@osk.mine.nu wrote: Package: nmap Version: 6.40-0.2 Severity: minor In the PORT SCANNING BASICS The six port states recognized by Nmap section of the Nmap manual page, the actual state names are missing. Thanks for the report. This happens on my Fedora box too with our Nroff man page (which is generated from Docbook XML, just like our HTML rendering you reference is). I don't know what the problem is. I've added this to our todo file (which doesn't mean anyone will actually fix it, but hopefully someone will figure it out). Cheers, Fyodor
Bug#745479: Move ncurses*5-config to -dev?
Package: ncurses-bin Version: 5.9+20140118-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi! Shouldn't ncursesw5-config and ncurses5-config be shipped with their respective -dev packages? Otherwise, a configure script may succeed while the appropriate files are not present. Thanks. - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ncurses-bin depends on: ii libc6 2.18-4 ii libtinfo5 5.9+20140118-1 ncurses-bin recommends no packages. ncurses-bin suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJTVh5mAAoJEJWkL+g1NSX5M/sP/A1JaH8iCTKMgH6cjik0P3Kt y24ZNm0o37RjPOeW6R0xnett0MrWz54AtDiu01a+l//LM9D0x7S8PZs+MbHFdQSi uhda3mEmhaIxVNTrh5x1cgD75yfdqNJFIp8faH/TB1nEYMeq9bZOq7md1DCY8KZy FKD0mwJm48SNd90ubxdoYqV9Tffz8IjGDqUfiz2oSnatKMg8WC9rBc03PeIExV/9 L3wES7TwIlwQFjMI//L/7tfzF4XhEgl6YUsJ/OcO8YIraZvErI1RvnrTUcnm/Et2 Fi7JqOfkm9BzLes0x8EjDqMTArqBUk5/e0LwuY9nMVfal9QICqwQR5hkgvYiQVjf 1Vf1P2SCc9YjqoLGbU/TzNwdU4ec8NE/F1pQpEEo55AplYQcbJTmro+sgg8I01Pb Us/+AJmKnm2cQQnaH3yFUE0kwE/rPK5a48eFhGVac7PK6EIEL2LuKVbWUnPdQqlD 2zJ5PlQ0f0jDOGBtBBzeMgrQ34hDrBc3jZn7WJCGRBuGKM6U6uEHcO+0SzPOOxbp AWiN0PqWvNI2i8Ida5Ucmz9tGvPGvyGMBhINcDoIePLaOvNikWhM4s1C0jzWDJEe 1l3XEw9+/enaMbDO8RdyagbCD+QOEr6dQJBMtHdE2zkKNTpSO2xEMcVGC4Z0+Lq6 XgLyVdi/yxLTaIQ6nBbt =j+E9 -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#717131: I volunteer for testing too
Hello, is there any progress on this topic? I volunteer for testing too. :) Kind regards, Aiko Barz -- :wq ✉ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734789: [CVE-2013-7284] Remote pre-authentication code execution in PlRPC
On Sun, 2014-04-06 11:12:17 +0200, Moritz Mühlenhoff wrote: On Sat, Mar 29, 2014 at 09:07:11AM +1100, Aníbal Monsalve Salazar wrote: On Fri, 2014-03-28 16:22:14 +0100, Moritz Muehlenhoff wrote: On Thu, Jan 09, 2014 at 09:01:53PM +0100, Florian Weimer wrote: Package: libplrpc-perl Severity: grave Version: 0.2020-2 Tags: security upstream The PlRPC module uses Storable in an unsafe way, leading to a remote code execution vulnerability (in both the client and the server). Upstream bug report: https://rt.cpan.org/Public/Bug/Display.html?id=90474 A fix (which is not yet available) requires a protocol change. I think we should remove the package from the distribution instead. Anibal, what's the status? Do you agree with the removal? Yes, I agree. I was waiting to get it fixed upstream. Please file a removal bug against ftp.debian.org. Done! https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745477 Cheers! signature.asc Description: Digital signature
Bug#745436: RFP: libdaemon-generic-perl -- framework for starting, stopping, reconfiguring daemon-like programs
Control: retitle -1 ITP: libdaemon-generic-perl -- framework for starting, stopping, reconfiguring daemon-like programs Control: owner -1 ! -=| Thorsten Glaser, 21.04.2014 19:15:30 +0200 |=- Package: wnpp Severity: wishlist * Package name: libdaemon-generic-perl Version : 0.82 Upstream Author : David Muir Sharnoff m...@idiom.com * URL : CPAN Daemon-Generic * License : Perl (GPL/Artistic) Programming Lang: Perl Description : framework for starting, stopping, reconfiguring daemon-like programs The framework provides for standard commands that work for as init.d files and as apachectl-like commands. . Programs that use Daemon::Generic subclass Daemon::Generic to override its behavior. Almost everything that Genric::Daemon does can be overridden as needed. Hello Debian Perl Group, please consider uploading libdaemon-generic-perl which is already packaged in Ubuntu; it is needed as a dependency of Kivitendo, which I am currently in the process of packaging. Alright. Packaging under way. signature.asc Description: Digital signature
Bug#713943: Not fixed for me
Hi Rick, for you so much for your quick answer. I had tried the same in /etc/modules. I've just removed it and tried your local.conf setting. No success. I have still the same message in dmesg : [0.961200] PowerMac i2c bus pmu 2 registered [0.961236] PowerMac i2c bus pmu 1 registered [0.961272] PowerMac i2c bus mac-io 0 registered [0.961667] PowerMac i2c bus u3 1 registered [0.961725] i2c i2c-3: i2c-powermac: modalias failure on /u3@0,f800/i2c@f8001000/cereal@1c0 [0.961764] PowerMac i2c bus u3 0 registered and [1.361462] Detected fan controls: [1.361467] 0: PWM fan, id 1, location: BACKSIDE,SYS CTRLR FAN [1.361472] 1: RPM fan, id 2, location: DRIVE BAY [1.361477] 2: PWM fan, id 2, location: SLOT,PCI FAN [1.361482] 3: RPM fan, id 3, location: CPU A INTAKE [1.361488] 4: RPM fan, id 4, location: CPU A EXHAUST [1.361493] 5: RPM fan, id 5, location: CPU B INTAKE [1.361498] 6: RPM fan, id 6, location: CPU B EXHAUST [1.361538] i2c i2c-0: therm_pm72: attach_adapter method is deprecated [1.361545] i2c i2c-0: Please use another way to instantiate your i2c_client [1.361553] i2c i2c-1: therm_pm72: attach_adapter method is deprecated [1.361558] i2c i2c-1: Please use another way to instantiate your i2c_client [1.361566] i2c i2c-2: therm_pm72: attach_adapter method is deprecated [1.361572] i2c i2c-2: Please use another way to instantiate your i2c_client [1.361580] i2c i2c-3: therm_pm72: attach_adapter method is deprecated [1.361585] i2c i2c-3: Please use another way to instantiate your i2c_client [1.361596] i2c i2c-3: Failed to register i2c client therm_pm72 at 0x2f (-16) [1.361602] therm_pm72: Failed to attach to i2c ID 0x15e [1.361609] i2c i2c-4: therm_pm72: attach_adapter method is deprecated [1.361615] i2c i2c-4: Please use another way to instantiate your i2c_client [1.361671] i2c i2c-4: Failed to register i2c client therm_pm72 at 0x2c (-16) [1.361677] therm_pm72: Failed to attach to i2c ID 0x58 Not all fans seem to be registered. I also have random kernel panics, but i think it is unrelated to this bug : something about radeon-kms (and I only have a software rasterizer for opengl, even if I boot with the video=offb:off video=radeonfb:off kernel argument.). Thank you again. Le 22/04/2014 05:18, Rick Thomas a écrit : On Apr 21, 2014, at 1:49 PM, Bertrand Dekoninck bdekoni...@free.fr wrote: I've installed jessie with linux-3.13.7-1 last night on my powermac7,3 (2x2.0 ghz). The fans are still crazy, even if i2c-powermac is build-in (and not a module anymore). Hi Bertrand, Have you tried echo 'i2c-powermac' /etc/modules-load.d/local.conf then reboot? I know it's supposed to be compiled-in with this version of the kernel, but maybe it just needs a little push? Rick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745436: RFP: libdaemon-generic-perl -- framework for starting, stopping, reconfiguring daemon-like programs
Control: owner -1 gre...@debian.org -=| Damyan Ivanov, 22.04.2014 11:09:09 +0300 |=- Alright. Packaging under way. Ehm, Gregor already uploaded the package, sorry for the noise. signature.asc Description: Digital signature
Bug#745480: [python2.7] Add support for lzma compressed tarballs
Package: python2.7
Severity: wishlist
Tags: patch
Currently Debian patch tracker uses python 2 and fails to open
*.debian.tar.xz, see for example:
http://patch-tracker.debian.org/package/sbcl/2:1.1.15-1
I've made quick and dirty backport of tarfile from python3.
Tested only with patch tracker:
http://patches.osdyson.org/package/sbcl/2:1.1.15-1+dyson1
--- System information. ---
Architecture: amd64
Kernel: Linux 3.10-2-amd64
Debian Release: jessie/sid
500 unstablemirror.yandex.ru
500 testing security.debian.org
500 testing mirror.yandex.ru
500 stable sdkrepo.atlassian.com
--- Package information. ---
Depends (Version) | Installed
===-+-
python2.7-minimal (= 2.7.6-5) | 2.7.6-5
libpython2.7-stdlib (= 2.7.6-5) | 2.7.6-5
mime-support| 3.54
Package's Recommends field is empty.
Suggests (Version) | Installed
-+-===
python2.7-doc|
binutils | 2.24-5
--- /usr/lib/python2.7/tarfile.py.orig 2014-04-22 09:04:41.0 +0100
+++ /usr/lib/python2.7/tarfile.py 2014-04-22 09:10:53.0 +0100
@@ -440,6 +440,19 @@
else:
self.cmp = bz2.BZ2Compressor()
+if comptype == xz:
+try:
+import lzma
+except ImportError:
+raise CompressionError(lzma module is not available)
+if mode == r:
+self.dbuf = b
+self.cmp = lzma.LZMADecompressor()
+self.exception = lzma.LZMAError
+else:
+self.cmp = lzma.LZMACompressor()
+
+
def __del__(self):
if hasattr(self, closed) and not self.closed:
self.close()
@@ -1759,11 +1772,37 @@
t._extfileobj = False
return t
+@classmethod
+def xzopen(cls, name, mode=r, fileobj=None, compresslevel=9, **kwargs):
+Open lzma compressed tar archive name for reading or writing.
+ Appending is not allowed.
+
+if mode not in (r, w):
+raise ValueError(mode must be 'r' or 'w')
+
+try:
+import lzma
+except ImportError:
+raise CompressionError(lzma module is not available)
+
+fileobj = lzma.LZMAFile(fileobj or name, mode)
+
+try:
+t = cls.taropen(name, mode, fileobj, **kwargs)
+except (lzma.LZMAError, EOFError):
+fileobj.close()
+raise ReadError(not an lzma file)
+t._extfileobj = False
+return t
+
+
# All *open() methods are registered here.
OPEN_METH = {
tar: taropen, # uncompressed tar
gz: gzopen,# gzip compressed tar
-bz2: bz2open# bzip2 compressed tar
+bz2: bz2open, # bzip2 compressed tar
+xz: xzopen # lzma compressed tar
+
}
#--
Bug#732087: status
Confirmed. Package is not in testing anymore. signature.asc Description: Digital signature
Bug#745481: Fwd: system-config-printer-udev: Upstart support
Package: system-config-printer-udev Severity: wishlist I have attached a patch with a simple, four line Upstart job that performs the same action as the udev rule + systemd service. I would be very appreciative if this was included in the next upload of your package. Best Regards, -- Cameron Norman Index: debian/rules === --- debian/rules (revisión: 41347) +++ debian/rules (copia de trabajo) @@ -28,3 +28,6 @@ cleanbuilddir/python-cupshelpers:: rm -rf cupshelpers/debug.py cupshelpers/smburi.py + +override_dh_installinit: + dh_installinit --name=configure-printer Index: debian/system-config-printer-udev.configure-printer.upstart === --- debian/system-config-printer-udev.configure-printer.upstart (revisión: 0) +++ debian/system-config-printer-udev.configure-printer.upstart (copia de trabajo) @@ -0,0 +1,9 @@ +description configure-printer - use udev to configure printers that are added + +start on usb-device-added ID_USB_INTERFACES=*:0701??:* + +instance $SUBSYSTEM-$BUSNUM-$DEVNUM + +task + +exec /lib/udev/udev-configure-printer add $UPSTART_INSTANCE
Bug#600547: python-scipy: Scipy Documentation not in Debian
Package: python-scipy Version: 0.13.3-2 Followup-For: Bug #600547 I'd also vouch for having a proper python-scipy-doc package, pretty-please :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712787: ITP for Distkeys
ITP finally went through after Don added some additional stripping to the mail parsing. ITP: distkeys -- Distkeys - upload SSH keys to servers and more http://bugs.debian.org/745478 Thanks, -- Martin Steigerwald Consultant / Trainer teamix GmbH Südwestpark 43 90449 Nürnberg fon: +49 911 30999 55 fax: +49 911 30999 99 mail: martin.steigerw...@teamix.de web: http://www.teamix.de blog: http://blog.teamix.de Amtsgericht Nürnberg, HRB 18320 Geschäftsführer: Oliver Kügow, Richard Müller ** Wissenstag Spezial „Datacenter Networking“ – 21.05.2014 ** http://www.teamix.de/spezial -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745322: Please ship krb5-config in krb5-multidev
On April 22, 2014 4:51:52 AM GMT+01:00, Russ Allbery r...@debian.org wrote: Benjamin Kaduk ka...@mit.edu writes: On Mon, 21 Apr 2014, Jelmer Vernooij wrote: That's orthogonal to this. Does that mean .pc files are preferred over krb5-config ? My understanding is that the .pc files give a much richer description of the package, and as such are preferred over krb5-config. This is particularly true when they use Libs vs. Libs.private properly (and Requires vs. Requires.private), since then they also prevent overlinking the resulting binaries. The MIT ones seem reasonably okay, although I would argue with inclusion of -lcom_err in Libs given that krb5_get_error_message is a thing that's existed for years. The Heimdal ones currently put everything in Libs, which makes them much less useful. Jelmer, let me know if you'd like me to file a bug about that. Please do, I agree that is a bug. Cheers, Jelmer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745482: daptup: the daptup manpage does not tell/explain about the options in /etc/daptup.conf
Package: daptup Version: 0.12.6 Severity: normal Dear Maintainer, I was looking at the manpage and found it wanting. While there is some explanation in /etc/daptup.conf the manpage even doesn't tell its existence. Also it would have been better to share some of the rationale for e.g. for :- # Daptup has the ability to find installed packages that have version prepared # by package maintainer a lot of time ago and have more recent install # candidate (outdated packages). Enable this check? # Possible values: n - no, y - yes. DAPTUP_CHECK_FOR_OUTDATED_PACKAGES=y # If we check for outdated packages, what minimal age (in days) must package to have # to be treated as outdated? DAPTUP_MINIMAL_DAY_COUNT_TREATING_OUTDATED=90 Guessing this is for sid/experimental but would not be so great in testing/stable. Also daptup doesn't seem to check for orphaned packages because in the whole /etc/daptup.conf there has been no mention of 'orphaned packages' or for 'removed/autoremoved packages' as well. Lastly the README.Debian is outdated as far as on Debian testing is concerned, as it happens when an aptitude index update is run. Looking for more info. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (600, 'testing'), (500, 'testing-updates'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages daptup depends on: ii apt 1.0.1 ii coreutils 8.21-1.1 ii liblocale-gettext-perl 1.05-8 ii perl5.18.2-2+b1 daptup recommends no packages. Versions of packages daptup suggests: ii aptitude 0.6.10-1 -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745483: nginx Upstart job
Package: nginx-common
Severity: wishlist
I have attached an Upstart job for the nginx-common package. This does
not include a replacement for the nginx-naxsi-ui init script.
The inclusion of this Upstart job will offer many benefits to those
using Upstart on Debian (e.g. me!) as well as Ubuntu users.
I would be very appreciative if this change was included in the next
upload of your package.
Cheers,
--
Cameron Norman
diff --git a/debian/nginx-common.nginx.upstart b/debian/nginx-common.nginx.upstart
new file mode 100644
index 000..0b71d57
--- /dev/null
+++ b/debian/nginx-common.nginx.upstart
@@ -0,0 +1,16 @@
+description nginx - small, powerful, scalable web/proxy server
+
+start on filesystem and static-network-up
+stop on runlevel [016]
+
+expect fork
+respawn
+
+pre-start script
+[ -x /usr/sbin/nginx ] || { stop; exit 0; }
+/usr/sbin/nginx -q -t -g 'daemon on; master_process on;' || { stop; exit 0; }
+end script
+
+exec /usr/sbin/nginx -g 'daemon on; master_process on;'
+
+pre-stop exec /usr/sbin/nginx -s quit
Bug#745480: Updated patch
Updated patch
Previous version breaks openning gzipped files :-) due to uncaught exception
--- /usr/lib/python2.7/tarfile.py.orig 2014-04-22 09:04:41.0 +0100
+++ /usr/lib/python2.7/tarfile.py 2014-04-22 09:55:48.0 +0100
@@ -440,6 +440,18 @@
else:
self.cmp = bz2.BZ2Compressor()
+if comptype == xz:
+try:
+import lzma
+except ImportError:
+raise CompressionError(lzma module is not available)
+if mode == r:
+self.dbuf = b
+self.cmp = lzma.LZMADecompressor()
+else:
+self.cmp = lzma.LZMACompressor()
+
+
def __del__(self):
if hasattr(self, closed) and not self.closed:
self.close()
@@ -630,6 +642,8 @@
return gz
if self.buf[0:3] == BZh and self.buf[4:10] == 1AYSY:
return bz2
+if self.buf.startswith((b\x5d\x00\x00\x80, b\xfd7zXZ)):
+return xz
return tar
def close(self):
@@ -1653,6 +1667,7 @@
if mode in (r, r:*):
# Find out which *open() is appropriate for opening the file.
for comptype in cls.OPEN_METH:
+print comptype
func = getattr(cls, cls.OPEN_METH[comptype])
if fileobj is not None:
saved_pos = fileobj.tell()
@@ -1759,11 +1774,37 @@
t._extfileobj = False
return t
+@classmethod
+def xzopen(cls, name, mode=r, fileobj=None, compresslevel=9, **kwargs):
+Open lzma compressed tar archive name for reading or writing.
+ Appending is not allowed.
+
+if mode not in (r, w):
+raise ValueError(mode must be 'r' or 'w')
+
+try:
+import lzma
+except ImportError:
+raise CompressionError(lzma module is not available)
+
+fileobj = lzma.LZMAFile(fileobj or name, mode)
+
+try:
+t = cls.taropen(name, mode, fileobj, **kwargs)
+except:
+fileobj.close()
+raise ReadError(not an lzma file)
+t._extfileobj = False
+return t
+
+
# All *open() methods are registered here.
OPEN_METH = {
tar: taropen, # uncompressed tar
gz: gzopen,# gzip compressed tar
-bz2: bz2open# bzip2 compressed tar
+bz2: bz2open, # bzip2 compressed tar
+xz: xzopen # lzma compressed tar
+
}
#--
Bug#713943: Not fixed for me
H... I'm planning to try it on my G5 soon. I'll let you know what I find out. It may be that we need a parameter on the module load line? Rick On Apr 22, 2014, at 1:10 AM, Bertrand Dekoninck bdekoni...@free.fr wrote: Hi Rick, for you so much for your quick answer. I had tried the same in /etc/modules. I've just removed it and tried your local.conf setting. No success. I have still the same message in dmesg : [0.961200] PowerMac i2c bus pmu 2 registered [0.961236] PowerMac i2c bus pmu 1 registered [0.961272] PowerMac i2c bus mac-io 0 registered [0.961667] PowerMac i2c bus u3 1 registered [0.961725] i2c i2c-3: i2c-powermac: modalias failure on /u3@0,f800/i2c@f8001000/cereal@1c0 [0.961764] PowerMac i2c bus u3 0 registered and [1.361462] Detected fan controls: [1.361467] 0: PWM fan, id 1, location: BACKSIDE,SYS CTRLR FAN [1.361472] 1: RPM fan, id 2, location: DRIVE BAY [1.361477] 2: PWM fan, id 2, location: SLOT,PCI FAN [1.361482] 3: RPM fan, id 3, location: CPU A INTAKE [1.361488] 4: RPM fan, id 4, location: CPU A EXHAUST [1.361493] 5: RPM fan, id 5, location: CPU B INTAKE [1.361498] 6: RPM fan, id 6, location: CPU B EXHAUST [1.361538] i2c i2c-0: therm_pm72: attach_adapter method is deprecated [1.361545] i2c i2c-0: Please use another way to instantiate your i2c_client [1.361553] i2c i2c-1: therm_pm72: attach_adapter method is deprecated [1.361558] i2c i2c-1: Please use another way to instantiate your i2c_client [1.361566] i2c i2c-2: therm_pm72: attach_adapter method is deprecated [1.361572] i2c i2c-2: Please use another way to instantiate your i2c_client [1.361580] i2c i2c-3: therm_pm72: attach_adapter method is deprecated [1.361585] i2c i2c-3: Please use another way to instantiate your i2c_client [1.361596] i2c i2c-3: Failed to register i2c client therm_pm72 at 0x2f (-16) [1.361602] therm_pm72: Failed to attach to i2c ID 0x15e [1.361609] i2c i2c-4: therm_pm72: attach_adapter method is deprecated [1.361615] i2c i2c-4: Please use another way to instantiate your i2c_client [1.361671] i2c i2c-4: Failed to register i2c client therm_pm72 at 0x2c (-16) [1.361677] therm_pm72: Failed to attach to i2c ID 0x58 Not all fans seem to be registered. I also have random kernel panics, but i think it is unrelated to this bug : something about radeon-kms (and I only have a software rasterizer for opengl, even if I boot with the video=offb:off video=radeonfb:off kernel argument.). Thank you again. Le 22/04/2014 05:18, Rick Thomas a écrit : On Apr 21, 2014, at 1:49 PM, Bertrand Dekoninck bdekoni...@free.fr wrote: I've installed jessie with linux-3.13.7-1 last night on my powermac7,3 (2x2.0 ghz). The fans are still crazy, even if i2c-powermac is build-in (and not a module anymore). Hi Bertrand, Have you tried echo 'i2c-powermac' /etc/modules-load.d/local.conf then reboot? I know it's supposed to be compiled-in with this version of the kernel, but maybe it just needs a little push? Rick -- To unsubscribe, send mail to 713943-unsubscr...@bugs.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#745420: openttd: please package new version 1.4
Hey Eugene, It would be nice to have latest and greatest openttd 1.4.0 which features, among other things, merged CargoDist. Good point! I was busy when 1.4.0 was released and then forgot about it afterwards. I'll have a look right now, thanks for the reminder! Gr. Matthijs signature.asc Description: Digital signature
Bug#745484: getmail4: Please package getmail4 4.46.0 for improved SSL certificate checking in POP3
Package: getmail4 Version: 4.44.0-1 Severity: wishlist Hi, upstream getmail4 4.46.0 adds extended SSL options for the POP3 retriever, allowing users to configure the kind of strict server certificate checking that is needed to protect against active network attackers (MitM + sslsniff). It would be great to see this in Debian. Thanks in advance, and thank you for maintaining getmail4 in Debian! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745485: xdebug: FTBFS on hurd-i386
Source: xdebug
Version: 2.2.4-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hi,
Currently xdebug fails to build from source due to PATH_MAX being used,
and that constant is not defined on GNU/Hurd. The attached patch avoid
using PATH_MAX by allocating the string dfp with xdstrdup() and free it
when not needed any longer.
Thanks!
--- a/xdebug-2.2.4/usefulstuff.c
+++ b/xdebug-2.2.4/usefulstuff.c
@@ -284,16 +284,16 @@ char *xdebug_raw_url_encode(char const *
char *xdebug_path_from_url(const char *fileurl TSRMLS_DC)
{
/* deal with file: url's */
- char dfp[PATH_MAX * 2];
- const char *fp = dfp, *efp = fileurl;
+ char *dfp = NULL;
+ const char *fp = NULL, *efp = fileurl;
#ifdef PHP_WIN32
int l = 0;
int i;
#endif
- char *tmp = NULL, *ret = NULL;;
+ char *tmp = NULL, *ret = NULL;
- memset(dfp, 0, sizeof(dfp));
- strncpy(dfp, efp, sizeof(dfp) - 1);
+ dfp = xdstrdup(efp);
+ fp = dfp;
xdebug_raw_url_decode(dfp, strlen(dfp));
tmp = strstr(fp, file://);
@@ -316,6 +316,7 @@ char *xdebug_path_from_url(const char *f
ret = xdstrdup(fileurl);
}
+ free(dfp);
return ret;
}
Bug#745396: (no subject)
Hi Nathan, as i specified, this is happening to the default testing-repo version of dwb too. I attach a file containing some outputs to show you the situation: the system is up to date, the dwb version is the default one, the libglib2 is the 2.40 and the error is always there. (sorry for the italian localization, but i guess it's understandable). About the glib2 library, the dwb guys told the issue was related to the upgrade 2.38 - 2.40. Anyways i got it automatically updated, i don't think i could have a different version of it available on the system... this is all i can say about that. If more details are needed, please let me know. Thanks. dwberr Description: Binary data
Bug#745486: lightdm-gtk-greeter: cannot always shutdown or restart
Package: lightdm-gtk-greeter Version: 1.8.3-1 Severity: normal The Shutdown and Restart actions do not always work. I get no error messages (well, a box appears for a fraction of second, but I don't know what it is supposed to contain). And I don't get much in the logs: lightdm.log: [+1178502.60s] DEBUG: Session pid=3975: Exited with return value 0 [+1178502.65s] DEBUG: Seat: Session stopped [+1178502.65s] DEBUG: Seat: Stopping display server, no sessions require it [+1178502.65s] DEBUG: Sending signal 15 to process 3080 [+1178507.65s] DEBUG: Sending signal 9 to process 3080 [+1178507.74s] DEBUG: Process 3080 terminated with signal 9 [+1178507.74s] DEBUG: DisplayServer x-0: X server stopped [+1178507.74s] DEBUG: Releasing VT 7 [+1178507.74s] DEBUG: DisplayServer x-0: Removing X server authority /var/run/lightdm/root/:0 [+1178507.90s] DEBUG: Seat: Display server stopped [+1178507.90s] DEBUG: Seat: Active display server stopped, starting greeter [+1178507.90s] DEBUG: Seat: Creating greeter session [+1178507.99s] DEBUG: Seat: Setting XDG_SEAT=seat0 [+1178507.99s] DEBUG: Seat: Creating display server of type x [+1178507.99s] DEBUG: Seat: Starting local X display [+1178508.01s] DEBUG: Using VT 7 [+1178508.01s] DEBUG: DisplayServer x-0: Logging to /var/log/lightdm/x-0.log [+1178508.01s] DEBUG: DisplayServer x-0: Writing X server authority to /var/run/lightdm/root/:0 [+1178508.01s] DEBUG: DisplayServer x-0: Launching X Server [+1178508.01s] DEBUG: Launching process 21449: /usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch [+1178508.01s] DEBUG: DisplayServer x-0: Waiting for ready signal from X server :0 [+1178512.30s] DEBUG: Got signal 10 from process 21449 [+1178512.30s] DEBUG: DisplayServer x-0: Got signal from X server :0 [+1178512.30s] DEBUG: DisplayServer x-0: Connecting to XServer :0 [+1178512.31s] DEBUG: Seat: Display server ready, starting session authentication [+1178512.31s] DEBUG: Session: Setting XDG_VTNR=7 [+1178512.31s] DEBUG: Session pid=21464: Started with service 'lightdm-greeter', username 'lightdm' [+1178512.52s] DEBUG: Session pid=21464: Authentication complete with return value 0: Success [+1178512.52s] DEBUG: Seat: Session authenticated, running command [+1178512.52s] DEBUG: Session pid=21464: Setting XDG_VTNR=7 [+1178512.52s] DEBUG: Session pid=21464: Running command /usr/sbin/lightdm-gtk-greeter [+1178512.52s] DEBUG: Session pid=21464: Logging to /var/log/lightdm/x-0-greeter.log [+1178512.73s] DEBUG: Activating VT 7 [+1178515.26s] DEBUG: Session pid=21464: Greeter connected version=1.8.8 [+1178520.07s] DEBUG: Session pid=21464: Greeter start authentication for vinc17 [+1178520.09s] DEBUG: Seat: Setting XDG_SEAT=seat0 [+1178520.09s] DEBUG: Session: Setting XDG_VTNR=7 [+1178520.09s] DEBUG: Session pid=21493: Started with service 'lightdm', username 'vinc17' [+1178520.28s] DEBUG: Session pid=21493: Got 1 message(s) from PAM [+1178520.28s] DEBUG: Session pid=21464: Prompt greeter with 1 message(s) The Suspend action worked, but after resuming, the mouse pointer was no longer visible and the display got frozen (bug 735928 for this particular problem?), and I had to shutdown via SSH. -- 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.11-2-amd64 (SMP w/2 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lightdm-gtk-greeter depends on: ii libc6 2.18-4 ii libcairo2 1.12.16-2 ii libgdk-pixbuf2.0-0 2.30.6-1 ii libglib2.0-02.40.0-2 ii libgtk-3-0 3.12.0-4 ii liblightdm-gobject-1-0 1.8.8-1 ii libx11-62:1.6.2-1 Versions of packages lightdm-gtk-greeter recommends: ii desktop-base 7.0.3 ii gnome-icon-theme-symbolic 3.12.0-1 ii gnome-themes-standard 3.12.0-1 ii policykit-10.105-4 lightdm-gtk-greeter suggests no packages. -- Configuration Files: /etc/lightdm/lightdm-gtk-greeter.conf changed: [greeter] background=/usr/share/images/desktop-base/login-background.svg theme-name=Adwaita xft-antialias=true xft-hintstyle=hintfull xft-rgba=rgb show-indicators=~language;~session;~power show-clock=true clock-format=%F %T -- 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#745487: apt python library leak memory and file descriptors
Package: python-apt Version: 0.8.8.2 Severity: important Since I wrote the isenkram package, it have been plagued with a nasty resourse leak. It leak memory and file descriptors every time some hardware is inserted. The amount of leaked memory varies, but seem to be 30-40 MiB every time. The amount of file descriptors depend on the number of APT sources listed in /etc/apt/. URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730704 is an example on what happen when the process run out of file descriptors, and URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719837 is the initial report about leaking memory. I've been able to track down the problem to the python-apt library, and the following test program demonstrate the leak: #!/usr/bin/python import apt while True: cache = apt.Cache() cache.open(None) When left alone running for a while, it crashes like this: % ./apt-leak.py Traceback (most recent call last): File ./apt-leak.py, line 6, in module cache.open(None) File /usr/lib/python2.7/dist-packages/apt/cache.py, line 147, in open self._records = apt_pkg.PackageRecords(self._cache) SystemError: E:Could not open file /var/lib/apt/lists/security.debian.org_dists_wheezy_updates_contrib_binary-amd64_Packages - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/security.debian.org_dists_wheezy_updates_main_binary-amd64_Packages - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/ftp.skolelinux.org_skolelinux_dists_wheezy-test_local_binary-amd64_Packages - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/http.debian.net_debian_dists_wheezy-backports_main_i18n_Translation-en - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/http.debian.net_debian_dists_wheezy-backports_main_binary-amd64_Packages - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/http.debian.net_debian_dists_wheezy_non-free_i18n_Translation-en - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/http.debian.net_debian_dists_wheezy_main_i18n_Translation-en - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/http.debian.net_debian_dists_wheezy_contrib_i18n_Translation-en - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/http.debian.net_debian_dists_wheezy_contrib_binary-amd64_Packages - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/http.debian.net_debian_dists_wheezy_non-free_binary-amd64_Packages - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/http.debian.net_debian_dists_wheezy_main_binary-amd64_Packages - open (24: Too many open files) % Am I using the library wrong (ie should I do something to release the resources when I am done with the cache), or is it a bug in the library leaking memory and file descriptors? Setting severity to important. I guess one could argue that it should be critical because it causes isenkram to fail, but that severity seemed a bit high when I do not know if I am using the library wrong or not. -- 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#742581: openttd; FTBFS with libpng 1.6
Hi Nobuhiro, Hmm, are you saying that libpng-config is in the -tools package? Isn't it customary to put it in -dev? libpng-config is available in libpng16-devtools package. # Perhaps, it will be fixed this so that it can be used as libpng-devtools virtual package. This is provided by libpng12-dev in libpng (version 1.2 ), but because of multiarch support, it has been separated. Ah, that makes sense. So you're saying that libpng12-dev will provide libpng-devtools in a future upload? IIUC, until that happens, I can't start depending on it though (though I could of course depend on libpng12-dev | libpng-devtools, of course). In any case, upstream has committed a change to their buildsystem to use pkg-config instead of libpng-config, which would remove the need for depending on libpng16-devtools alltogether. I've backported that change to the new openttd 1.4.0 version I'm packaging now, so if that works I'll just use that approach. deb http://www.nigauri.org/~iwamatsu /debian/libpng ./ This repository has been signed with my key. Thanks, using that now. Note that there was a typo in this line, there shouldn't be a space before /debian. Gr. Matthijs signature.asc Description: Digital signature
Bug#745488: python-dogpile.cache: please package version 0.5.3
Package: python-dogpile.cache Version: 0.5.0-1 Severity: wishlist Hello, I am in the process of packaging subliminal (ITP - #729781), which requires at least version 0.5.2 (pypi version is 0.5.3 ATM). Can you please consider updating it? Thanks! -- Etienne Millon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745489: RFS: linop/0.8.2-2 -- linear operators
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package linop: * Package name: linop Version : 0.8.2 Upstream Author : Ghislain Vaillant ghisv...@gmail.com * URL : https://pypi.python.org/pypi/linop * License : BSD Programming Lang: Python Description : Linear mathematical operators in Python This upload include a FTBFS bug fix. This package is maintained by the Debian Science Team and can be checked out at http://anonscm.debian.org/gitweb/?p=debian-science/packages/linop.git. Best regards, Ghislain
Bug#745490: qemu-system-x86: Guests fail to start with Linunz 3.13 (3.12 is fine)
Package: qemu-system-x86
Version: 1.7.0+dfsg-9
Severity: grave
Justification: renders package unusable
Dear Maintainer,
Since kernel 3.13 migrated into jessie, I cannot start KVM guests
anymore.
If I boot on the last jessie 3.12 kernel (3.12.9-1), I can start the
guests with no problem.
I hoped some newer kernel and qemu would fix it and waited both
have a new version in jessie which is now the case; unfortunately the
result is the same: after starting the guest with a command-line such
as:
kvm -net nic,model=virtio -net tap,script=no,downscript=no,ifname=tap0 -drive
file=/var/local/kvm/taz-test.img,if=virtio -usbdevice tablet -k fr -vnc
localhost:2 -daemonize -name taz-test
The cpu goes 100% for a while and then the kernel is spouting messages
on all terminals.
This is what I get in syslog:
Apr 22 10:56:39 ataz kernel: [ 9050.996004] INFO: rcu_sched self-detected stall
on CPU { 1} (t=5250 jiffies g=194196 c=194195 q=1118)
Apr 22 10:56:39 ataz kernel: [ 9050.996004] sending NMI to all CPUs:
Apr 22 10:56:39 ataz kernel: [ 9050.996004] NMI backtrace for cpu 1
Apr 22 10:56:39 ataz kernel: [ 9050.996004] CPU: 1 PID: 19798 Comm:
qemu-system-x86 Not tainted 3.13-1-686-pae #1 Debian 3.13.10-1
Apr 22 10:56:39 ataz kernel: [ 9050.996004] Hardware name: Dell Inc. Latitude
D630 / , BIOS A13 07/28/2008
Apr 22 10:56:39 ataz kernel: [ 9050.996004] task: f6a8e920 ti: f64ac000
task.ti: f64ac000
Apr 22 10:56:39 ataz kernel: [ 9050.996004] EIP: 0060:[c1221a8a] EFLAGS:
0006 CPU: 1
Apr 22 10:56:39 ataz kernel: [ 9050.996004] EIP is at __const_udelay+0xa/0x20
Apr 22 10:56:39 ataz kernel: [ 9050.996004] EAX: 01062560 EBX: 2710 ECX:
f000 EDX: 00982914
Apr 22 10:56:39 ataz kernel: [ 9050.996004] ESI: c1578440 EDI: c1578440 EBP:
0001 ESP: f64adccc
Apr 22 10:56:39 ataz kernel: [ 9050.996004] DS: 007b ES: 007b FS: 00d8 GS:
00e0 SS: 0068
Apr 22 10:56:39 ataz kernel: [ 9050.996004] CR0: 8005003b CR2: CR3:
16cb8000 CR4: 27f0
Apr 22 10:56:39 ataz kernel: [ 9050.996004] Stack:
Apr 22 10:56:39 ataz kernel: [ 9050.996004] c103932d c14cdc87 f79e1840
c109a3ea c14dbde0 1482 0002f694 0002f693
Apr 22 10:56:39 ataz kernel: [ 9050.996004] 045e 083b f79e1840
c1578440 c15b51ac 0086
Apr 22 10:56:39 ataz kernel: [ 9050.996004] f6a8e920 0001
083b c1059084 f64addf0 f64addf0 5966cdf2
Apr 22 10:56:39 ataz kernel: [ 9050.996004] Call Trace:
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c103932d] ?
arch_trigger_all_cpu_backtrace+0x4d/0x70
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c109a3ea] ?
rcu_check_callbacks+0x37a/0x5b0
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c1059084] ?
update_process_times+0x34/0x60
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c10a492c] ?
tick_sched_handle.isra.12+0x1c/0x50
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c10a498f] ?
tick_sched_timer+0x2f/0x60
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c106b4f7] ?
__remove_hrtimer+0x27/0x80
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c106b6fb] ?
__run_hrtimer+0x6b/0x190
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c10a4960] ?
tick_sched_handle.isra.12+0x50/0x50
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c106c311] ?
hrtimer_interrupt+0x201/0x2c0
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c106c259] ?
hrtimer_interrupt+0x149/0x2c0
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c10374a7] ?
local_apic_timer_interrupt+0x27/0x50
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c1051e9d] ? irq_enter+0xd/0x60
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c103763b] ?
smp_apic_timer_interrupt+0x2b/0x50
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c14108fc] ?
apic_timer_interrupt+0x34/0x3c
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [f8ac1901] ?
apic_has_pending_timer+0x21/0x70 [kvm]
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [f8aa8c8b] ?
kvm_arch_vcpu_ioctl_run+0x28b/0x10a0 [kvm]
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [f8aa5bec] ?
kvm_arch_vcpu_load+0x18c/0x1f0 [kvm]
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [f8a97ead] ?
kvm_vcpu_ioctl+0x3fd/0x4a0 [kvm]
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c10a81a5] ? do_futex+0xf5/0xb20
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c100e170] ?
__switch_to+0xb0/0x340
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [f8a97ab0] ? vcpu_put+0x20/0x20
[kvm]
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c1151dc7] ?
do_vfs_ioctl+0x307/0x500
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c140d5ac] ?
__schedule+0x23c/0x6e0
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c10a8c5c] ? SyS_futex+0x8c/0x160
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c1152020] ? SyS_ioctl+0x60/0x80
Apr 22 10:56:39 ataz kernel: [ 9050.996004] [c1416fcd] ?
sysenter_do_call+0x12/0x28
Apr 22 10:56:39 ataz kernel: [ 9050.996004] Code: 00 48 75 fd 48 c3 8d 74 26 00
8d bc 27 00 00 00 00 ff 15 30 2c 59 c1 f3 c3 90 8d b4 26 00 00 00 00 c1 e0 02
64 8b 15 9c de 63 c1 6b d2 3e f7 e2 8d 42 01 ff 15 30 2c 59 c1 f3 c3 8d
Bug#745135: Aw: Bug#745135: RFS: mariadb-10.0/10.0.10-1 [ITP] -- Latest version of worlds most popular non-Oracle database
Hello, Firstly, many thanks to Tobias for his review. I will upload tonight - to experimental, not unstable, though. Many smallish technical bits aside, this shall help with checking compatibility with existing installations. Once there are positive vibrations fed back to the maintainer, I think we should then fix a few more of those lintian overrides and then go to unstable. [ Tobies replied to Otto]: W outdated-autotools-helper-file -- looks like that dh-autoreconf or autotools-dev would like to be your friends. Autotools is not used. These files seems to be just upstream cruft left over, so I added a override with this comment. I suggest to just remove from the source tree upfront what is not used. It would be very nice to have man pages for everything in /usr/bin. If this is too far from what upstream is providing, I suggest looking into help2man and a summary man page for all those binaries that do not have a man page. Many greetings Steffen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745491: ITP: ruby-omniauth-github -- GitHub strategy for the Ruby OmniAuth library
Package: wnpp Severity: wishlist Owner: Cédric Boutillier bou...@debian.org * Package name: ruby-omniauth-github Version : 1.1.2 Upstream Author : Michael Bleigh mich...@intridea.com * URL : https://github.com/intridea/omniauth-github * License : Expat Programming Lang: Ruby Description : GitHub strategy for the Ruby OmniAuth library OmniAuth is a Ruby library that standardizes multi-provider authentication for web applications. It was created to be powerful, flexible, and do as little as possible. Any developer can create strategies for OmniAuth that can authenticate users via disparate systems. OmniAuth strategies have been created for everything from Facebook to LDAP. . This package contains the official OmniAuth strategy for GitHub. This package is a dependency of gitlab. Cheers, Cédric signature.asc Description: Digital signature
Bug#745493: proftpd-dfsg: FTBFS on hurd-i386
Source: proftpd-dfsg
Version: 1.3.5~rc4-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hi,
Currently proftpd-dfsg fails to build from source due to PIPE_BUF being
used, and that constant is not defined on GNU/Hurd. The attached patch
avoid using PIPE_BUF by deriving file descriptor buffer sizes with
fpathconf(), allocating buffers by malloc and free them when not needed
any longer.
Thanks!
--- a/contrib/mod_exec.c
+++ b/contrib/mod_exec.c
@@ -735,14 +735,20 @@ static int exec_ssystem(cmd_rec *cmd, co
if (fds = 0) {
int buflen;
- char buf[PIPE_BUF];
+
+ size_t len = fpathconf(exec_stdout_pipe[0], _PC_PIPE_BUF);
+ char *buf = malloc(len);
+ if (buf == NULL) {
+exec_log(malloc failed: %s, strerror(errno));
+return errno;
+ }
/* The child sent us something. How thoughtful. */
if (FD_ISSET(exec_stdout_pipe[0], readfds)) {
-memset(buf, '\0', sizeof(buf));
+memset(buf, '\0', len);
-buflen = read(exec_stdout_pipe[0], buf, sizeof(buf)-1);
+buflen = read(exec_stdout_pipe[0], buf, len - 1);
if (buflen 0) {
if (exec_opts EXEC_OPT_SEND_STDOUT) {
@@ -789,9 +795,9 @@ static int exec_ssystem(cmd_rec *cmd, co
}
if (FD_ISSET(exec_stderr_pipe[0], readfds)) {
-memset(buf, '\0', sizeof(buf));
+memset(buf, '\0', len);
-buflen = read(exec_stderr_pipe[0], buf, sizeof(buf)-1);
+buflen = read(exec_stdout_pipe[0], buf, len - 1);
if (buflen 0) {
/* Trim trailing CRs and LFs. */
@@ -821,6 +827,7 @@ static int exec_ssystem(cmd_rec *cmd, co
}
}
}
+ free(buf);
}
res = waitpid(pid, status, WNOHANG);
--- a/contrib/mod_tls.c
+++ b/contrib/mod_tls.c
@@ -1765,10 +1765,15 @@ static int tls_exec_passphrase_provider(
if (FD_ISSET(stderr_pipe[0], readfds)) {
int stderrlen;
- char stderrbuf[PIPE_BUF];
- memset(stderrbuf, '\0', sizeof(stderrbuf));
- stderrlen = read(stderr_pipe[0], stderrbuf, sizeof(stderrbuf)-1);
+ size_t len = fpathconf(stderr_pipe[0], _PC_PIPE_BUF);
+ char *stderrbuf = malloc(len);
+ if (stderrbuf == NULL) {
+tls_log(malloc failed: %s, strerror(errno));
+return -1;
+ }
+ memset(stderrbuf, '\0', len + 1);
+ stderrlen = read(stderr_pipe[0], stderrbuf, len - 1);
if (stderrlen 0) {
while (stderrlen
(stderrbuf[stderrlen-1] == '\r' ||
@@ -1785,6 +1790,7 @@ static int tls_exec_passphrase_provider(
: error reading stderr from '%s': %s,
tls_passphrase_provider, strerror(errno));
}
+ free(stderrbuf);
}
}
--- a/contrib/mod_sftp/keys.c
+++ b/contrib/mod_sftp/keys.c
@@ -413,10 +413,15 @@ static int exec_passphrase_provider(serv
if (FD_ISSET(stderr_pipe[0], readfds)) {
int stderrlen;
- char stderrbuf[PIPE_BUF];
- memset(stderrbuf, '\0', sizeof(stderrbuf));
- stderrlen = read(stderr_pipe[0], stderrbuf, sizeof(stderrbuf)-1);
+ size_t len = fpathconf(stderr_pipe[0], _PC_PIPE_BUF);
+ char *stderrbuf = malloc(len);
+ if (stderrbuf == NULL) {
+pr_log_pri(PR_LOG_ALERT, MOD_SFTP_VERSION : Out of memory!);
+return -1;
+ }
+ memset(stderrbuf, '\0', len);
+ stderrlen = read(stderr_pipe[0], stderrbuf, len - 1);
if (stderrlen 0) {
while (stderrlen
(stderrbuf[stderrlen-1] == '\r' ||
@@ -433,6 +438,7 @@ static int exec_passphrase_provider(serv
: error reading stderr from '%s': %s,
passphrase_provider, strerror(errno));
}
+ free(stderrbuf);
}
}
Bug#745490: qemu-system-x86: Guests fail to start with Linunz 3.13 (3.12 is fine)
22.04.2014 13:19, Patrice Pillot wrote: Package: qemu-system-x86 Version: 1.7.0+dfsg-9 Severity: grave Justification: renders package unusable Dear Maintainer, Since kernel 3.13 migrated into jessie, I cannot start KVM guests anymore. If I boot on the last jessie 3.12 kernel (3.12.9-1), I can start the guests with no problem. Well. In that case, why are you filing a bug report against qemu? As far as I can see, in your case the HOST kernel breaks, receiving an NMI for all CPUs. This is something which no user-space program should be able to achieve, no matter what. And you state that previous kernel version worked fine, so it is the kernel which broke when updating to 3.13 version. How it is a qemu problem? Note also that you're running a 32bit kernel - this is something which has not been tested for a very long time. No developers run qemu/kvm on 32bit kernels. No testing environment has 32bit kernels. We in Debian have a few bugreports against qemu involving 32bit kernels, and those stays unfixed forever because it is an environment which has very little value nowadays, and which bitrots slowly because no one tests it anymore. Does the same problem occurs when you run it with 64bit kernel instead? Do you know whenever it worked with older version(s) of qemu but with the current kernel? Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742184: linux-image-3.13-0.bpo.1-686-pae: qemu-kvm unusable with 3.13.7 kernel, oops appears
I think I'm seeing this bug too, need to check the logs later. Its definitely some kind of oops using KVM on 3.13. CPU: Athlon64 X2, 4Gb RAM Kernel: linux-image-3.13-1-686-pae (3.13.10-1 and 3.13.7-1) in Jessie/i386 Bug can be avoided by booting the old 3.12 kernel. Symptoms: Works normally, but if I start a VM, the VM freezes quickly, usually within in BIOS or GRUB. Can be killed regularly. Kernel messages after a while. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745467: weird Usage: .%V volume ... (#913) messages
On Tue, Apr 22, 2014 at 07:46:40AM +0800, 積丹尼 Dan Jacobson wrote: X-Debbugs-Cc: man...@packages.debian.org Package: feh Version: 2.10-1 Severity: wishlist File: /usr/share/man/man1/feh.1.gz # su - nobody #pristine environment $ man feh 21 /dev/null Usage: .%V volume ... (#913) Please do not CC man-db@packages on this kind of bug. This has nothing to do with man-db; the error message is emitted by the groff mdoc macros, and indicates an incorrect use of the .%V macro in the feh manual page. -- 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#706633: Scala 2.11.0 is now available
New upstream version has been released. Details can be found at [1]. [1] http://www.scala-lang.org/news/2014/04/21/release-notes-2.11.0.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641146: openttd: Swapped colors on sparc64
Hi Joël, Could you test the OpenTTD version in experimental and report if it fixes the problems you were seeing? I will try as soon as possible. I have halted my sparc due to some kernel instabilities (3.2 is not stable on all sun4u I have). Did you get a chance to have another look at this, or do you expect to do so in the near future? If not, I'll go ahead and close this bug for now. Note that the fix in experimental I referred to above has since been migrated to testing (it is in OpenTTD 1.3.0 and above). The stable version doesn't include the fix yet, though. Thanks, Matthijs signature.asc Description: Digital signature
Bug#745494: installation-report: Wheezy/stable on IGEL M300c thin-client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: installation-reports Version: 2.49 Severity: wishlist Dear Maintainer, this installation went fine, not quite as expected. - -- Package-specific info: Boot method: USB Image version: http://cdimage.debian.org/debian-cd/7.4.0/i386/iso-cd/debian-7.4.0-i386-netinst.iso, 2014-02-08 Date: 2014-04-22, about 8.00 h to 12.00 h Machine: IGEL M300c thin-client Partitions: Filesystem Type 1K-blocks Used Available Use% Mounted on rootfs rootfs 6824960 3549024 3275936 53% / udev devtmpfs 10240 0 10240 0% /dev tmpfs tmpfs 101684 644101040 1% /run /dev/disk/by-uuid/ba6003d8-9e96-4ae4-9f2b-9ba81ae33999 xfs6824960 3549024 3275936 53% / tmpfs tmpfs 5120 0 5120 0% /run/lock tmpfs tmpfs 496840 72496768 1% /run/shm /dev/sdb5 ext4 6727856 146148 6239948 3% /home Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [o] Detect network card:[o] Configure network: [o] Detect CD: [o] Load installer modules: [o] Clock/timezone setup: [o] User/password setup:[o] Detect hard drives: [o] Partition hard drives: [o] Install base system:[o] Install tasks: [o] Install boot loader:[o] Overall install:[o] Comments/Problems: Because my installation-attempts of Jessie/testing failed yesterday, I tried Wheezy today, which actually works, so I do report the success now. About my problems with Testing see there: 745...@bugs.debian.org - -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=7 (wheezy) - installer build 20130613+deb7u1+b2 X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux debian 3.2.0-4-486 #1 Debian 3.2.54-2 i686 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge [1106:0314] lspci -knn: Subsystem: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge [1106:0314] lspci -knn:Kernel driver in use: agpgart-via lspci -knn: 00:00.1 Host bridge [0600]: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge [1106:1314] lspci -knn: 00:00.2 Host bridge [0600]: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge [1106:2314] lspci -knn: 00:00.3 Host bridge [0600]: VIA Technologies, Inc. PT890 Host Bridge [1106:3208] lspci - -knn: 00:00.4 Host bridge [0600]: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge [1106:4314] lspci -knn: 00:00.7 Host bridge [0600]: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge [1106:7314] lspci -knn: 00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT8237/VX700 PCI Bridge [1106:b198] lspci -knn: 00:0f.0 IDE interface [0101]: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] (rev 06) lspci -knn: Subsystem: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] lspci -knn: Kernel driver in use: pata_via lspci -knn: 00:10.0 USB controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 81) lspci -knn: Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:10.1 USB controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 81) lspci -knn: Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:10.2 USB controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 81) lspci -knn:Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:10.3 USB controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 81) lspci -knn:Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] lspci -knn: Kernel driver in use: uhci_hcd lspci - -knn: 00:10.4 USB controller [0c03]: VIA Technologies, Inc. USB 2.0
Bug#743870: Re: Bug#743870: Excessive dependencies required on upgrade
[ re-sent because I forgot to cc the BTS ] On Thursday 10 April 2014 13:22:45 you wrote: I consider this a problem because it's a lot of packages that simply are not going to be used on these systems. Yes. A few MB of disks are wasted. Even on ARM system running on a SD card, this is no longer a problem. A number of drivers are split into the lcdproc-extra-drivers package to avoid all users having to install large parts of X11, In this case, the large part of X11 are some X libraries which also weight a few MB (no more than 10). This package split made sense a few years ago on enbedded system where 32MB flash was a big deal. Thanks to your mail, I've realised it's not worth the effort. I'll remove this split the next time there's a problem around this hack. I think it would be kind to users to allow them not to install a large number of optional packages. It's also kind to user not to offer them a choice when the 2 alternatives have no significant differences. Can this functionality please be made optional at the very least? It is. You will be asked whether to allow automatic upgrade or not. Could the config model packages be turned into a Recommends rather than a Depends, so that they don't have to be installed at all? Technically, yes. But this dependency is injected by dh_cme_upgrade. This would mean adding yet another option to the configuration file of dh_cme_upgrade, adding documentation and explaining pro and cons of the choice. This would make automatic config upgrade more complex for no real added value. Then, some documentation would need to be written for the end user so he can make an informed decision, and recover from a wrong choice. All this work for what ? saving a few MB not worth a cent on an SD card ? It's really helpful to those of us who would like to maintain as minimal a system as possible. For example, I'd like to use lcdproc on a firewall system, and keeping the attack surface as small as possible is a common goal for this type of system. None of these package will leave a running process. I don't see the relation between the installed files and having a more vulnerable system. All the best signature.asc Description: This is a digitally signed message part.
Bug#722465: qtsmbstatus-server: fails to install due to insserv rejecting the script header
[Ivo De Decker] Hi Petter, Hi. Thank you for the quick reply. The samba init script only exists for backward compatibility. The services are started by the snmd and nmbd init scripts (when running in 'old' mode), or by the samba-ad-dc init script (when running in samba AD DC mode). Depending on smbd isn't really a solution, because that will not have the right result when running in samba AD DC mode (the smbd init script will exit successfully, but won't do anything in that case). Depending on both smbd and samba-ad-dc might be an option (this will ensure that the smbd functionality is available, whatever the mode samba is running in). Right. Then I suspect adding this header might be the solution for qtsmbstatus-server, but I do not really know the service and am unsure if it give a working qtsmbstatus-server. # Should-Start:smbd samba-ad-dc Anyone know if that is enough to get qtsmbstatus-server working? It will get it installing again, but I fear it will not work. I do not know nor use it myself, just trying to fix a RC boot system related bug discovered by piuparts. :) This package is the only one with complete broken boot dependencies at the moment. :) -- Happy hacking Petter Reinhioldtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745495: gdebi: Crashes when reading the deb-file
Package: gdebi Version: 0.9.4 Severity: important Dear Maintainer, Crashes when trying to read the deb-file Did the following from the commandline: gdebi-gtk hardinfo_0.5.1-1.2+b1_i386.deb and the result was: Traceback (most recent call last): File /usr/bin/gdebi-gtk, line 79, in module app = GDebiGtk(datadir=data,options=options,file=afile) File /usr/share/gdebi/GDebi/GDebiGtk.py, line 151, in __init__ self.open(file) File /usr/share/gdebi/GDebi/GDebiGtk.py, line 330, in open if not self._deb.check(): File /usr/lib/python2.7/dist-packages/apt/debfile.py, line 518, in check if not self.check_breaks_existing_packages(): File /usr/lib/python2.7/dist-packages/apt/debfile.py, line 447, in check_breaks_existing_packages self._cache.op_progress.done() AttributeError: 'dict' object has no attribute 'op_progress' and crash!!! -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (700, 'testing') Architecture: i386 (i686) Kernel: Linux 3.13-1-686-pae (SMP w/4 CPU cores) Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gdebi depends on: ii gdebi-core0.9.4 ii gir1.2-gtk-3.03.12.0-4 ii gir1.2-vte-2.90 1:0.34.9-1 ii gksu 2.0.2-6 ii gnome-icon-theme 3.12.0-1 ii python-gi 3.12.1-1 pn python:anynone Versions of packages gdebi recommends: ii libgtk2-perl 2:1.249-2 ii shared-mime-info 1.2-1 gdebi 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#705111: Please enable the --enable-rdb option when building
22.04.2014 03:21, Dmitry Smirnov wrote: Dear Michael, I just want to let you know that Ceph_0.72.2-3 introduced library versioning mechanism and it already migrated to testing. Ceph_0.79 in experimental now provides symbols (starting from 0.72.2) for all its libraries. I built qemu/1.7.0+dfsg-8 with ceph_0.79/experimental and (as expected) generated dependencies were conservative: librados2 (= 0.72.2), librbd1 (= 0.72.2). I looked at what's currently in 0.72.2-3 and 0.79 in experimental, and I think this is a very good start. Just one thing - maybe you can remove -V option of dh_makeshlibs in 0.79, since you have good .symbols files already. Now I hope you can safely enable RBD support in Qemu. Please let me know if you need anything else to re-introduce RBD support. I'm eagerly looking forward to have it back. ;) I think that's all what needed, I will re-enable rbd/ceph on the next qemu upload. BTW, I found another link which might be useful for this: http://pkg-kde.alioth.debian.org/symbolfiles.html Thank you for taking care of this! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745467: weird Usage: .%V volume ... (#913) messages
Hi, On Tue, Apr 22, 2014 at 07:46:40AM +0800, 積丹尼 Dan Jacobson wrote: $ man feh 21 /dev/null Usage: .%V volume ... (#913) This is a bug in the feh manual, a fix will be included in the next release. Patch: http://git.finalrewind.org/feh/commit/?id=c07a9474ed54fb7eda17b801770cf65acda9ba7f --Daniel signature.asc Description: Digital signature
Bug#745101: libreoffice-mysql-connector: does not work over SSH tunnel
Hi, I tried installing AOO and trying the extensions I cited with it (I solved somehow the problem I cited in my previous comment), and I found out that: 1) maybe the problem is not related to the SSH tunnel, but rather to the connection from outside the LAN, as opposed to inside it. In fact, I was able to connect directly and over SSH from inside the LAN, but I was not able to do the same, nor over SSH neither directly, when I tried connecting from outside my LAN. Of course I had port forwarding enabled, and the SSH connection/tunnel was working. 2) The extension for OpenOffice, both the one found at http://extensions.openoffice.org/en/project/mysql-connector-openofficeorg and the one at http://extensions.openoffice.org/en/node/5644 do not seem to solve the problem. Of course I have tested them with AOO. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745496: vim-youcompleteme: YcmRestartServer says ENOENT
Package: vim-youcompleteme Version: 0+20140207+git18be5c2-1 Severity: normal :YcmRestartServer Traceback (most recent call last): File string, line 1, in module File /usr/lib/vim-youcompleteme/ycm/youcompleteme.py, line 169, in RestartServer self._SetupServer() File /usr/lib/vim-youcompleteme/ycm/youcompleteme.py, line 117, in _SetupServer with open( self._server_stderr, 'w' ) as fstderr: IOError: [Errno 2] File not found: '/tmp/ycm_tempprnw3G/server_50148_stderr.log' My handlers.py is changed because bottle.Request.MEMFILE_MAX is too small, I'm using 16MB; see http://stackoverflow.com/questions/16865997/python-bottle- module-causes-error-413-request-entity-too-large. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vim-youcompleteme depends on: ii libboost-filesystem1.54.0 1.54.0-5 ii libboost-python1.54.0 1.54.0-5 ii libboost-regex1.54.01.54.0-5 ii libboost-system1.54.0 1.54.0-5 ii libc6 2.18-4 ii libclang1-3.3 1:3.3-16 ii libgcc1 1:4.8.2-16 ii libstdc++6 4.8.2-16 ii python-bottle 0.12.5-1 ii python-concurrent.futures [python-futures] 2.1.6-3 ii python-jedi 0.7.0-1 ii python-requests 2.2.1-1 ii python-waitress 0.8.8-1 ii python2.7 2.7.6-8 pn python:any none ii vim-athena [vim-python] 2:7.4.253-1 ii vim-gnome [vim-python] 2:7.4.253-1 ii vim-nox [vim-python]2:7.4.253-1 Versions of packages vim-youcompleteme recommends: ii vim-addon-manager 0.5.3 vim-youcompleteme suggests no packages. -- no debconf information -- debsums errors found: debsums: changed file /usr/lib/vim-youcompleteme/ycm/server/handlers.py (from vim-youcompleteme package) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745487: apt python library leak memory and file descriptors
Hm, look like this issue is and old and known problem, at least to some. I found it mentioned in URL: http://stackoverflow.com/questions/17624114/how-to-diagnose-potential-memory-leak-in-python-program from 2013-07-12. To me, the issue seem similar to URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=151489 which was supposed to have been fixed in 2002, but perhaps the CVS commit was reverted? Version 0.5.4.4 should have the fix, according to BTS. -- 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#745259: ITP: apt-transport-tor -- APT transport for anonymous package downloads via Tor
Hi, By using curl you are basically allowing the mirror (or anyone who can intercept the clear text) to tell normal and tor users apart. Think of targeted attacks. Just saying... Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719837: Block bugs
Control: block -1 by 745487 I believe this problem is caused by a resource leak in python-apt, reported as URL: http://bugs.debian.org/745487 . Not sure until I get some feedback from the python-apt maintainers. -- 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#745487: apt python library leak memory and file descriptors
On Tue, Apr 22, 2014 at 11:23:24AM +0200, Petter Reinholdtsen wrote: Package: python-apt Version: 0.8.8.2 Severity: important Since I wrote the isenkram package, it have been plagued with a nasty resourse leak. It leak memory and file descriptors every time some hardware is inserted. The amount of leaked memory varies, but seem to be 30-40 MiB every time. The amount of file descriptors depend on the number of APT sources listed in /etc/apt/. URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730704 is an example on what happen when the process run out of file descriptors, and URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719837 is the initial report about leaking memory. I've been able to track down the problem to the python-apt library, and the following test program demonstrate the leak: #!/usr/bin/python import apt while True: cache = apt.Cache() cache.open(None) When left alone running for a while, it crashes like this: % ./apt-leak.py Traceback (most recent call last): File ./apt-leak.py, line 6, in module cache.open(None) File /usr/lib/python2.7/dist-packages/apt/cache.py, line 147, in open self._records = apt_pkg.PackageRecords(self._cache) SystemError: E:Could not open file /var/lib/apt/lists/security.debian.org_dists_wheezy_updates_contrib_binary-amd64_Packages - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/security.debian.org_dists_wheezy_updates_main_binary-amd64_Packages - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/ftp.skolelinux.org_skolelinux_dists_wheezy-test_local_binary-amd64_Packages - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/http.debian.net_debian_dists_wheezy-backports_main_i18n_Translation-en - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/http.debian.net_debian_dists_wheezy-backports_main_binary-amd64_Packages - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/http.debian.net_debian_dists_wheezy_non-free_i18n_Translation-en - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/http.debian.net_debian_dists_wheezy_main_i18n_Translation-en - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/http.debian.net_debian_dists_wheezy_contrib_i18n_Translation-en - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/http.debian.net_debian_dists_wheezy_contrib_binary-amd64_Packages - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/http.debian.net_debian_dists_wheezy_non-free_binary-amd64_Packages - open (24: Too many open files), E:Could not open file /var/lib/apt/lists/http.debian.net_debian_dists_wheezy_main_binary-amd64_Packages - open (24: Too many open files) % Am I using the library wrong (ie should I do something to release the resources when I am done with the cache), or is it a bug in the library leaking memory and file descriptors? There are indeed multiple leaks in python-apt, some even cannot be fixed (IIRC for both parts of the sentences). I'll take a closer look at this soon, unless someone else does first. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Please do not top-post if possible. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745497: ITP: python-geventhttpclient -- High performance, concurrent http client library for python with gevent
Package: wnpp Severity: wishlist Owner: Sebastien Badia s...@sebian.fr * Package name: python-geventhttpclient Version : 1.1.0 Upstream Author : Antonin Amand antonin.am...@gmail.com * URL : https://github.com/gwik/geventhttpclient * License : MIT Programming Lang: Python Description : High performance, concurrent http client library for python with gevent geventhttpclient is a high performance, concurrent HTTP client library for python using gevent. .. geventhttpclient use a fast http parser, written in C, originating from nginx, extracted and modified by Joyent. .. geventhttpclient has been specifically designed for high concurrency, streaming and support HTTP 1.1 persistent connections. More generally it is designed for efficiently pulling from REST APIs and streaming API's like Twitter's. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651170: PyXB package status
Hi, Any progress on the packaging of pyxb ? Where is it at, at the moment ? Just asking because one of the packages I am working on could later have an optional dependency on it. Cheers, Ghis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741584: booting T440p with Debian testing - problems
Hi, My workaround was to (boot in recovery mode and) blacklist nouveau, as in: # echo 'blacklist nouveau' /etc/modprobe.d/blacklist-nouveau.conf After that, reboot in normal mode. It seems that the 3.13.x kernel is trying to load drivers for both the Intel and NVIDIA cards, and there's a BIOS-related bug that makes the NVIDIA card misbehave when on Linux. Previous versions of the kernel didn't do that. I hope that helps. -- John. On Tue, 2014-04-22 at 14:13 +0300, Mr Smith wrote: I found that you had a very similar problem as myself: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741584 I have bought new Thinkpad T440p and aimed to install dualboot Win7/Debian testing. I have tried the Debian alpha-installer amd64 from 19 March 2014 but the system does not boot correctly (no GUI; login not reacting etc) Is there any workaround? Any help would be appreciated very much! MS
Bug#745453: [libgcrypt20] Non free RFC
Two comments: 1) Looking at crc.c, I don't think the code in question is big enough to be copyrightable. The FSF usually uses a 10-line limit, and my impression is that they are intentionally conservative here. The code is a couple of lines only. 2) Code from some RFCs is available under the BSD license or for smaller snippets, under fair use, via the IETF Trust. See http://trustee.ietf.org/faq.html /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745498: ITP: libzhuyin -- Zhuyin input method library
Package: wnpp Severity: wishlist Owner: IME Packaging Team pkg-ime-de...@lists.alioth.debian.org * Package name: libzhuyin Version : 0.9.93 Upstream Author : Peng Wu alexep...@gmail.com * URL : https://github.com/libzhuyin/libzhuyin * License : GPL2 Programming Lang: C++ Description : Zhuyin input method library The libzhuyin project aims to provide the algorithms core for intelligent sentence-based Chinese zhuyin input methods. libzhuyin can be integrated with input method framework likes ibus, fcitx, ... to provide a zhuyin based input method for Traditional Chinese user. -- ChangZhuo Chen (陳昌倬) czc...@gmail.com http://czchen.info/ Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D signature.asc Description: Digital signature
Bug#742013: ALBERTA: old license in demo/COPYING and a small patch
Hi, I just wanted to confirm if my mail arrived. Besides a missing feature in Debian's pkg-config package[1] this is the only thing blocking me from updating the ALBERTA package for Debian. Regards, Ansgar [1] Which should be addressed soon. On 04/11/2014 09:02, Ansgar Burchardt wrote: I'm working on preparing Debian packages for the new ALBERTA 3.0.0 release (thanks for that). While taking a quick look I noticed that there is still a reference to an (old?) license in demo/COPYING: ALBERTA is freely distributed for research and education, but you have to sign a license agreement; download the license agreement from Is this only a left-over from some older version or does this apply anywhere, for example for the demo package? I also found another small problem: alberta-utilities.pc.in contains -lalberta-utilities!SUFFIX!, but the shared library itself uses an underscore instead of a dash (patch attached). signature.asc Description: OpenPGP digital signature
Bug#741584: booting T440p with Debian testing - problems
Thanks John for your prompt response! you are the HERO! your suggestion worked instantly!!! being quite new with Linux I have almost given up after several rounds of installation... I assume this bug will not change even with the stable Debian 7 release (?) - where to find out if this problem will be solved and how? best greetings and Many thanks again!!! MS 2014-04-22 14:30 GMT+03:00 John M. jwmwal...@gmail.com: Hi, My workaround was to (boot in recovery mode and) blacklist nouveau, as in: # echo 'blacklist nouveau' /etc/modprobe.d/blacklist-nouveau.conf After that, reboot in normal mode. It seems that the 3.13.x kernel is trying to load drivers for both the Intel and NVIDIA cards, and there's a BIOS-related bug that makes the NVIDIA card misbehave when on Linux. Previous versions of the kernel didn't do that. I hope that helps. -- John. On Tue, 2014-04-22 at 14:13 +0300, Mr Smith wrote: I found that you had a very similar problem as myself: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741584 I have bought new Thinkpad T440p and aimed to install dualboot Win7/Debian testing. I have tried the Debian alpha-installer amd64 from 19 March 2014 but the system does not boot correctly (no GUI; login not reacting etc) Is there any workaround? Any help would be appreciated very much! MS
Bug#745499: nvidia-settings: CVE-2013-6401 Jansson hash collision issue
Package: nvidia-settings Version: 319.17-1 Severity: serious Tags: security Just saw this in the upstream changelog for 331.67: - Updated nvidia-settings to use libjansson commit 88aa6a9e30e7465196a737bd0f82eb17f393a120 from the repository at: git://github.com/akheron/jansson.git This commit contains the relevant fixes for CVE-2013-6401. Looks like the nvidia-settings 319 series introduced an embedded code copy of jansson (whatever that is). http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6401 Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745500: nvidia-settings: embedded copy of jansson
Package: nvidia-settings Version: 319.17-1 Severity: important Tags: help src:nvidia-settings (since 319.xx) contains an embedded copy of jansson, a C library for encoding, decoding and manipulating JSON data that is packaged separately as src:jansson in Debian. nvidia-settings should be built against the system library instead of the embedded copy (hoping that is an unmodified copy) to avoid having to patch issues like CVE-2013-6401 in more than one place. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711404: reportbug's GTK interface crashes if spelling dictionaries for the current locale are missing
Package: reportbug Version: 6.5.0 Followup-For: Bug #711404 This also happends here. The log: $ reportbug Traceback (most recent call last): File /usr/bin/reportbug, line 2209, in module main() File /usr/bin/reportbug, line 1079, in main return iface.user_interface() File /usr/bin/reportbug, line 2126, in user_interface package, severity, mode, charset=charset, tags=tags) File /usr/bin/reportbug, line 169, in handle_editing editor, charset) File /usr/lib/pymodules/python2.7/reportbug/ui/gtk2_ui.py, line 1496, in func op = klass (parent) File /usr/lib/pymodules/python2.7/reportbug/ui/gtk2_ui.py, line 506, in __init__ self.widget = self.create_widget () File /usr/lib/pymodules/python2.7/reportbug/ui/gtk2_ui.py, line 1118, in create_widget gtkspell.Spell (self.view) glib.GError: ������������������������zh_CN.utf8 -- Package-specific info: ** Environment settings: EDITOR=vim INTERFACE=gtk2 ** /home/fermat/.reportbugrc: reportbug_version 6.4.3 mode novice ui gtk2 email fermat...@gmail.com -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Versions of packages reportbug depends on: ii apt 1.0.1 ii python2.7.5-5 ii python-reportbug 6.5.0 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail none pn debconf-utils none pn debsumsnone pn dlocatenone ii emacs23-bin-common 23.4+1-4.1+b1 ii exim4 4.82-8 ii exim4-daemon-light [mail-transport-agent] 4.82-8 ii file 1:5.17-1 ii gnupg 1.4.16-1.1 ii python-gtk22.24.0-3+b1 ii python-gtkspell2.25.3-13 pn python-urwid none ii python-vte 1:0.28.2-5 ii xdg-utils 1.1.0~rc1+git20111210-7 Versions of packages python-reportbug depends on: ii apt 1.0.1 ii python2.7.5-5 ii python-debian 0.1.21+nmu2 ii python-debianbts 1.11 ii python-support1.0.15 python-reportbug suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745501: f-spot: F-Spot crash at startup
Package: f-spot Version: 0.8.2-5.1 Severity: grave Justification: renders package unusable Dear Maintainer, At startup, F-Spot shows an emty windows and closes. Starting F-Spot from terminal, there is the folowing error message: user@workstation:~$ f-spot [Info 11:57:07.022] Initializing Mono.Addins (f-spot:6371): GLib-GObject-WARNING **: Attempt to add property __gtksharp_8_FSpot_Widgets_CellRendererTextProgress::value after class was initialised (f-spot:6371): GLib-GObject-WARNING **: Attempt to add property __gtksharp_8_FSpot_Widgets_CellRendererTextProgress::text after class was initialised Exception in Gtk# callback delegate Note: Applications can use GLib.ExceptionManager.UnhandledException to handle the exception. System.ArgumentNullException: Argument cannot be null. Parameter name: key at System.Collections.Generic.Dictionary`2[System.String,Cms.Profile].Add (System.String key, Cms.Profile value) [0x0] in filename unknown:0 at FSpot.ColorManagement.AddProfiles (System.String path, IDictionary`2 profs) [0x0] in filename unknown:0 at FSpot.ColorManagement.AddProfiles (System.String path, IDictionary`2 profs) [0x0] in filename unknown:0 at FSpot.ColorManagement.get_Profiles () [0x0] in filename unknown:0 at FSpot.TagSelectionWidget.IconDataFunc (Gtk.TreeViewColumn column, Gtk.CellRenderer renderer, TreeModel model, TreeIter iter) [0x0] in filename unknown:0 at GtkSharp.TreeCellDataFuncWrapper.NativeCallback (IntPtr tree_column, IntPtr cell, IntPtr tree_model, IntPtr iter, IntPtr data) [0x0] in filename unknown:0 at GLib.ExceptionManager.RaiseUnhandledException(System.Exception e, Boolean is_terminal) at GtkSharp.TreeCellDataFuncWrapper.NativeCallback(IntPtr tree_column, IntPtr cell, IntPtr tree_model, IntPtr iter, IntPtr data) at Gtk.Application.gtk_main() at Gtk.Application.Run() at FSpot.Driver.Startup() at Hyena.Gui.CleanRoomStartup.Startup(Hyena.Gui.StartupInvocationHandler startup) at FSpot.Driver.Main(System.String[] args) (f-spot:6371): GLib-CRITICAL **: Source ID 83 was not found when attempting to remove it (f-spot:6371): GLib-CRITICAL **: Source ID 44 was not found when attempting to remove it (f-spot:6371): GLib-CRITICAL **: Source ID 43 was not found when attempting to remove it (f-spot:6371): GLib-CRITICAL **: Source ID 45 was not found when attempting to remove it (f-spot:6371): GLib-CRITICAL **: Source ID 46 was not found when attempting to remove it (f-spot:6371): GLib-CRITICAL **: Source ID 47 was not found when attempting to remove it user@workstation:~$ Sometimes, F-Spot starts normal, but about one in then times. Regards, Hannes Diethelm -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/6 CPU cores) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages f-spot depends on: iu dbus1.8.0-3 ii gconf2 3.2.6-2 iu gvfs-bin1.20.1-1 ii libc6 2.18-4 ii libcairo2 1.12.16-2 ii libflickrnet2.2-cil 1:2.2.0-4 ii libgconf2.0-cil 2.24.2-3 ii libgdk-pixbuf2.0-0 2.30.6-1 ii libglib2.0-02.40.0-2 ii libglib2.0-cil 2.12.10-5 ii libgnome-keyring1.0-cil 1.0.0-4 ii libgnome2.24-cil2.24.2-3 ii libgnomeui-02.24.5-3 iu libgtk2.0-0 2.24.23-1 ii libgtk2.0-cil 2.12.10-5 iu liblcms11.19.dfsg1-1.3 ii libmono-addins-gui0.2-cil 1.0+git20130406.adcd75b-3 ii libmono-addins0.2-cil 1.0+git20130406.adcd75b-3 ii libmono-cairo4.0-cil3.0.6+dfsg2-11 ii libmono-corlib4.5-cil 3.0.6+dfsg2-11 ii libmono-posix4.0-cil3.0.6+dfsg2-11 ii libmono-sharpzip4.84-cil3.0.6+dfsg2-11 ii libmono-simd4.0-cil 3.0.6+dfsg2-11 ii libmono-system-core4.0-cil 3.0.6+dfsg2-11 ii libmono-system-web4.0-cil 3.0.6+dfsg2-11 ii libmono-system-xml4.0-cil 3.0.6+dfsg2-11 ii libmono-system4.0-cil 3.0.6+dfsg2-11 ii libndesk-dbus1.0-cil0.6.0-6 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 iu libsqlite3-03.8.4.3-1 ii libunique-1.0-0 1.1.6-4 ii libx11-62:1.6.2-1 ii libxcomposite1 1:0.4.4-1 ii mono-runtime3.0.6+dfsg2-11 Versions of packages f-spot recommends: iu dbus-x11 1.8.0-3 ii dcraw 9.19-1.1 f-spot 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#745270: needrestart: suggest a reboot when the kernel has been upgraded
Hi Paul, On 04/20/2014 08:05 AM, Paul Wise wrote: Please detect when the kernel on disk has been upgraded and offer to reboot but make it not reboot by default, for the same reason as login managers are blacklisted; user sessions are still open. I've no idea how to detect outdated kernels in a generic way. In apt-dater-host I'd tried to implement such detection... but it is only a fragile heuristic. It is distri specific (needrestart should work on any GNU/Linux). On Debian based system you could install update-notifier-common. This ships /etc/kernel/postinst.d/update-notifier which creates /var/run/reboot-required after kernel installation. This is Debian's way for kernel-package based kernel installations... but no generic solution. Looking for ideas/comments. Cheers, Thomas -- :: WWW: http://fiasko-nw.net/~thomas/ :: ::: Jabber: xmpp:tho...@jabber.fiasko-nw.net ::: :: flickr: http://www.flickr.com/photos/laugufe/ :: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745259: ITP: apt-transport-tor -- APT transport for anonymous package downloads via Tor
On Sat, Apr 19, 2014 at 11:50:32PM +0100, Tim Retout wrote: This software works! It was forked from the apt HTTPS transport. It doesn't yet have a build system or any packaging, but hopefully that's the easy part. It is also such a trivial modification¹ that I wonder why a fork is needed as the required metadata will easily exceed the code changes. Just provide a patch which does those settings based on the name of the binary called, like apt is handling it for its gzip/bzip2/lzma/xz methods and be done with it forever instead of maintaining a fork. Or even better just add SOCKS proxy support to the existing methods… Where does it lead us to, when DDs prefer to do forks of Debian native packages? I am bit scared of the answer… (it explains though why my apt3 in brainfuck is going nowhere. ;) ) Best regards David Kalnischkies ¹ 1 file changed, 23 insertions(+), 37 deletions(-) before s/https/tor/ was done yesterday. I wonder why curl is forbidden to redirect from http to https in this commit btw. At least we have a bigger diff this way, I guess… signature.asc Description: Digital signature
Bug#744785: freetuxtv: fails to build with clang instead of gcc
This might be fixed in the developpement version of FreetuxTV. I will check this soon. Thank you for the patch. On Mon, Apr 14, 2014 at 6:54 PM, Nicolas Sévelin-Radiguet nic...@free.frwrote: Package: freetuxtv Version: 0.6.5~dfsg1-1 Severity: minor Tags: patch User: pkg-llvm-t...@lists.alioth.debian.org Usertags: clang-ftbfs Dear Maintainer, Your package fails to build with clang instead of gcc. [-Wreturn-type] The attached patch fixes it. Buildlogs and patch are here: https://github.com/nonas/debian-clang/tree/master/buildlogs/freetuxtv Regards, Nicolas -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (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
Bug#732360: sponsorship status
Hi Andreas, Are you still interested in sponsoring this package ? Cheers, Ghislain -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745502: ITP: ruby-em-redis -- an eventmachine-based implementation of the Redis protocol
Package: wnpp Severity: wishlist Owner: Praveen Arimbrathodiyil prav...@debian.org * Package name: ruby-em-redis Version : 0.3.0 Upstream Author : Jonathan Broad, Eugene Pimenov * URL : https://rubygems.org/gems/em-redis * License : Expat Programming Lang: Ruby Description : an eventmachine-based implementation of the Redis protocol -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742213: status
Is this package still actively maintained? Is there a plan to update this package to 0.6.0 in the foreseeable future? Thank you: csillag -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745492: rsyslogd-2007: action 'action 18' suspended messages in syslog
Am 22.04.2014 11:35, schrieb Antti Kultanen: Package: rsyslog Version: 7.6.3-1 Severity: minor Hello, rsyslog keeps repeating the message rsyslogd-2007: action 'action 18' suspended to syslog. Everything seems to work, the message is just an annoyance. The remote logger at 10.0.0.1 is a Debian Sid AMD64 running inetutils-syslogd. Remote logging works fine. -8- Apr 22 09:10:03 raspberrypi rsyslogd-2007: action 'action 18' suspended, next retry is Tue Apr 22 09:11:33 2014 [try http://www.rsyslog.com/e/2007 ] Apr 22 09:17:01 raspberrypi rsyslogd-2007: action 'action 18' suspended, next retry is Tue Apr 22 09:18:31 2014 [try http://www.rsyslog.com/e/2007 ] Apr 22 10:17:01 raspberrypi rsyslogd-2007: action 'action 18' suspended, next retry is Tue Apr 22 10:18:31 2014 [try http://www.rsyslog.com/e/2007 ] Apr 22 10:35:04 raspberrypi rsyslogd-2007: action 'action 18' suspended, next retry is Tue Apr 22 10:36:34 2014 [try http://www.rsyslog.com/e/2007 ] Apr 22 11:17:01 raspberrypi rsyslogd-2007: action 'action 18' suspended, next retry is Tue Apr 22 11:18:31 2014 [try http://www.rsyslog.com/e/2007 ] Apr 22 11:57:59 raspberrypi rsyslogd-2007: action 'action 18' suspended, next retry is Tue Apr 22 11:59:29 2014 [try http://www.rsyslog.com/e/2007 ] Apr 22 12:00:04 raspberrypi rsyslogd-2007: action 'action 18' suspended, next retry is Tue Apr 22 12:01:34 2014 [try http://www.rsyslog.com/e/2007 ] Apr 22 12:01:59 raspberrypi rsyslogd-2007: action 'action 18' suspended, next retry is Tue Apr 22 12:03:29 2014 [try http://www.rsyslog.com/e/2007 ] -8- Let me know what further info you need in order to fix the problem. See the discussion in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742113 The problem basically is, that no program is reading from /dev/xconsole, so the pipe runs full and rsyslog (correctly) logs this issue. So this is expected behaviour. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#745503: sysv-rc: check that jobs are known to upstart
Package: sysv-rc
Version: 2.88dsf-53
Severity: normal
Tags: patch
Dear Maintainer,
When integrating with upstart, just checking that /etc/init/$job.conf
exists is not enough. One should also query, via initctl status if
upstart indeed knows about the job. For example, newly introduced job
file (stable/testing) may contain stanzas which will be known to newer
upstart (stable/testing), but not the currently running one (old-stable)
and thus initd script should be used instead.
Regards,
Dimitri.
From 524722835e7a9c87e8ffda1a3c936233bb50c076 Mon Sep 17 00:00:00 2001
From: Dimitri John Ledkov x...@ubuntu.com
Date: Sun, 20 Apr 2014 18:55:14 +0100
Subject: [PATCH 1/2] service invoke-rc.d: check that jobs are known to
upstart.
service invoke-rc.d: in upstart interfacing code, check that the job
is actually known to upstart. This is because during upgrades, pid 1
might still be an older upstart which may not yet support syntax of
the newly unpacked jobs, thus sysv-init script should be continued to
be used instead.
---
debian/changelog| 8
debian/service/service | 3 ++-
debian/src/sysv-rc/sbin/invoke-rc.d | 3 +--
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index da2aa18..01540bf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,10 +1,18 @@
sysvinit (2.88dsf-55) UNRELEASED; urgency=medium
+ [ Gabriele Giacone ]
* sysv-rc:
- On hurd, fix hurd-console addition to inittab if inittab is already
existent and fix getty pathnames in commented out lines as well
(Closes: #745260).
+ [ Dimitri John Ledkov ]
+ * service invoke-rc.d: in upstart interfacing code, check that the job
+is actually known to upstart. This is because during upgrades, pid 1
+might still be an older upstart which may not yet support syntax of
+the newly unpacked jobs, thus sysv-init script should be continued to
+be used instead.
+
-- Gabriele Giacone 1o5g4...@gmail.com Mon, 07 Apr 2014 12:59:55 +0200
sysvinit (2.88dsf-54) experimental; urgency=medium
diff --git a/debian/service/service b/debian/service/service
index a9776e0..feef474 100755
--- a/debian/service/service
+++ b/debian/service/service
@@ -130,7 +130,8 @@ while [ $# -gt 0 ]; do
done
if [ -r /etc/init/${SERVICE}.conf ] which initctl /dev/null \
-initctl version 2/dev/null | grep -q upstart
+initctl version 2/dev/null | grep -q upstart \
+initctl status ${SERVICE} 2/dev/null 1/dev/null
then
# Upstart configuration exists for this job and we're running on upstart
case ${ACTION} in
diff --git a/debian/src/sysv-rc/sbin/invoke-rc.d b/debian/src/sysv-rc/sbin/invoke-rc.d
index f03bf5d..88b178e 100644
--- a/debian/src/sysv-rc/sbin/invoke-rc.d
+++ b/debian/src/sysv-rc/sbin/invoke-rc.d
@@ -24,7 +24,6 @@
RUNLEVELHELPER=/sbin/runlevel
POLICYHELPER=/usr/sbin/policy-rc.d
INITDPREFIX=/etc/init.d/
-UPSTARTDIR=/etc/init/
RCDPREFIX=/etc/rc
# Options
@@ -271,7 +270,7 @@ esac
# If we're running on upstart and there's an upstart job of this name, do
# the rest with upstart instead of calling the init script.
if which initctl /dev/null initctl version 2/dev/null | grep -q upstart \
-[ -e $UPSTARTDIR/${INITSCRIPTID}.conf ]
+inictl status ${INITSCRIPTID} 1/dev/null 2/dev/null
then
is_upstart=1
elif test -d /run/systemd/system ; then
--
1.9.1
Bug#745502: Bacon::Error when running tests
Running tests for ruby2.0 using debian/ruby-tests.rake ... /usr/bin/ruby2.0 -S rspec ./spec/live_redis_protocol_spec.rb ./spec/redis_commands_spec.rb ./spec/redis_protocol_spec.rb /usr/lib/ruby/vendor_ruby/bacon.rb:326:in `satisfy': false.==(true) failed (Bacon::Error) from /usr/lib/ruby/vendor_ruby/bacon.rb:340:in `method_missing' from /home/pravi/forge/debian/git/pkg-ruby-extras/ruby-em-redis/spec/redis_commands_spec.rb:567:in `block (4 levels) in top (required)' from /home/pravi/forge/debian/git/pkg-ruby-extras/ruby-em-redis/spec/redis_commands_spec.rb:566:in `each' from /home/pravi/forge/debian/git/pkg-ruby-extras/ruby-em-redis/spec/redis_commands_spec.rb:566:in `block (3 levels) in top (required)' from /home/pravi/forge/debian/git/pkg-ruby-extras/ruby-em-redis/lib/em-redis/redis_protocol.rb:443:in `call' from /home/pravi/forge/debian/git/pkg-ruby-extras/ruby-em-redis/lib/em-redis/redis_protocol.rb:443:in `dispatch_response' from /home/pravi/forge/debian/git/pkg-ruby-extras/ruby-em-redis/lib/em-redis/redis_protocol.rb:396:in `process_cmd' from /home/pravi/forge/debian/git/pkg-ruby-extras/ruby-em-redis/lib/em-redis/redis_protocol.rb:367:in `receive_data' from /usr/lib/ruby/vendor_ruby/eventmachine.rb:187:in `run_machine' from /usr/lib/ruby/vendor_ruby/eventmachine.rb:187:in `run' from /usr/lib/ruby/vendor_ruby/em-spec/bacon.rb:39:in `spec' from /usr/lib/ruby/vendor_ruby/em-spec/bacon.rb:22:in `spec' from /home/pravi/forge/debian/git/pkg-ruby-extras/ruby-em-redis/spec/redis_commands_spec.rb:5:in `top (required)' from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:896:in `load' from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:896:in `block in load_spec_files' from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:896:in `each' from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:896:in `load_spec_files' from /usr/lib/ruby/vendor_ruby/rspec/core/command_line.rb:22:in `run' from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:80:in `run' from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:17:in `block in autorun' /usr/lib/ruby/vendor_ruby/bacon.rb:326:in `satisfy': false.==(true) failed (Bacon::Error) from /usr/lib/ruby/vendor_ruby/bacon.rb:340:in `method_missing' from /home/pravi/forge/debian/git/pkg-ruby-extras/ruby-em-redis/spec/redis_commands_spec.rb:567:in `block (4 levels) in top (required)' from /home/pravi/forge/debian/git/pkg-ruby-extras/ruby-em-redis/spec/redis_commands_spec.rb:566:in `each' from /home/pravi/forge/debian/git/pkg-ruby-extras/ruby-em-redis/spec/redis_commands_spec.rb:566:in `block (3 levels) in top (required)' from /home/pravi/forge/debian/git/pkg-ruby-extras/ruby-em-redis/lib/em-redis/redis_protocol.rb:443:in `call' from /home/pravi/forge/debian/git/pkg-ruby-extras/ruby-em-redis/lib/em-redis/redis_protocol.rb:443:in `dispatch_response' from /home/pravi/forge/debian/git/pkg-ruby-extras/ruby-em-redis/lib/em-redis/redis_protocol.rb:396:in `process_cmd' from /home/pravi/forge/debian/git/pkg-ruby-extras/ruby-em-redis/lib/em-redis/redis_protocol.rb:367:in `receive_data' from /usr/lib/ruby/vendor_ruby/eventmachine.rb:187:in `run_machine' from /usr/lib/ruby/vendor_ruby/eventmachine.rb:187:in `run' from /usr/lib/ruby/vendor_ruby/em-spec/bacon.rb:39:in `spec' from /usr/lib/ruby/vendor_ruby/em-spec/bacon.rb:22:in `spec' from /home/pravi/forge/debian/git/pkg-ruby-extras/ruby-em-redis/spec/redis_commands_spec.rb:5:in `top (required)' from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:896:in `load' from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:896:in `block in load_spec_files' from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:896:in `each' from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:896:in `load_spec_files' from /usr/lib/ruby/vendor_ruby/rspec/core/command_line.rb:22:in `run' from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:80:in `run' from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:17:in `block in autorun' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745504: debconf: skip paging on terminals with 2 rows or less
Package: debconf
Version: 1.5.52
Severity: normal
Dear Maintainer,
The code in Debconf::FrontEnd::Teletype's display_nowrap silently
assumes that the display has more than 2 rows. On a terminal with 2 rows
or less, display_nowrap enters an endless loop, since no actual text
line is ever displayed, only the prompt itself.
I admit this is an extreme corner-case, but the following scenario can bring a
whole system down:
1. Launch a debconf-using application in a two-row terminal
2. Kill the parent process while debconf is paging
On the next input or signal, the debconf process will spin
uncontrollably; reading from STDIN will return immediately due to the
broken pipe and as prompt() does not check for errors while reading the
response, it will try to display_nowrap(\n) unconditionally, which in
turn will call prompt() recursively ad infinitum (or until the system's
memory is exhausted).
The attached patch fixes the issue.
Regards,
Apollon
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable'), (90, 'unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages debconf depends on:
ii perl-base 5.18.2-2+b1
Versions of packages debconf recommends:
ii apt-utils 1.0.1
ii debconf-i18n 1.5.52
Versions of packages debconf suggests:
ii debconf-doc1.5.52
ii debconf-utils 1.5.52
ii libgtk2-perl 2:1.249-2
ii libnet-ldap-perl 1:0.6200+dfsg-1
pn libqtcore4-perlnone
pn libqtgui4-perl none
ii libterm-readline-gnu-perl 1.24-1
ii perl 5.18.2-2+b1
ii whiptail 0.52.15-3+b1
-- debconf-show failed
--
Apollon Oikonomopoulos apol...@skroutz.gr
Skroutz S.A. http://skroutz.gr
From d597bd4e8b5de0811be7658d57fe4e1086af69a6 Mon Sep 17 00:00:00 2001
From: Apollon Oikonomopoulos apoi...@debian.org
Date: Tue, 22 Apr 2014 14:44:38 +0300
Subject: [PATCH] Teletype: page only if screen has more than two rows
The code in Debconf::FrontEnd::Teletype's display_nowrap silently
assumes that the display has more than 2 rows. On a terminal with 2 rows
or less, display_nowrap enters an endless loop, since no actual text
line is ever displayed, only the prompt itself. Since there is no point to try
paging, we completely skip it for 2-or-less-row-terminals.
---
Debconf/FrontEnd/Teletype.pm | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Debconf/FrontEnd/Teletype.pm b/Debconf/FrontEnd/Teletype.pm
index df311e7..f8c76c6 100644
--- a/Debconf/FrontEnd/Teletype.pm
+++ b/Debconf/FrontEnd/Teletype.pm
@@ -90,7 +90,10 @@ sub display_nowrap {
# If we had to guess at the screenheight, don't bother
# ever pausing; for all I know this is some real teletype
# with an infinite height screen of fan-fold paper..
- if (! $this-screenheight_guessed
+ # Also don't bother pausing if the screenheight is 2 rows or
+ # less, since that would leave no space to display the actual
+ # text.
+ if (! $this-screenheight_guessed $this-screenheight 2
$this-linecount($this-linecount+1) $this-screenheight - 2) {
my $resp=$this-prompt(
prompt = '['.gettext(More).']',
--
1.9.2
Bug#745505: sysv-rc: Operate against system-upstart only
Package: sysv-rc
Version: 2.88dsf-53
Severity: normal
Tags: patch
Dear Maintainer,
When using initctl utilities, they default to executing against system
upstart (typically pid 1), however if UPSTART_SESSION environment
variable is set, initctl defaults to operating against user-session
upstart (not very common on Debian desktops, but very common on ubuntu
desktops). Under such conditions, invoke-rc.d and service command should
operate against system upstart. With recent initctl one can use
'--system' command line option, but to stay compatible with initctl in
stable, i'm instead opting to unseting UPSTART_SESSION variable to
guarantee default execution against system upstart.
Regards,
Dimitri.
From 8873e8eb1c569079d0e68de729cb1c2fd959aa91 Mon Sep 17 00:00:00 2001
From: Dimitri John Ledkov x...@ubuntu.com
Date: Sun, 20 Apr 2014 19:02:39 +0100
Subject: [PATCH 2/2] service invoke-rc.d: use system upstart only.
service invoke-rc.d: unset UPSTART_SESSION environment variable to
make sure all upstart initctl commands are executed against system
init and not the session one.
---
debian/changelog| 3 +++
debian/service/service | 2 ++
debian/src/sysv-rc/sbin/invoke-rc.d | 2 ++
3 files changed, 7 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index 01540bf..485cbd3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -12,6 +12,9 @@ sysvinit (2.88dsf-55) UNRELEASED; urgency=medium
might still be an older upstart which may not yet support syntax of
the newly unpacked jobs, thus sysv-init script should be continued to
be used instead.
+ * service invoke-rc.d: unset UPSTART_SESSION environment variable to
+make sure all upstart initctl commands are executed against system
+init and not the session one.
-- Gabriele Giacone 1o5g4...@gmail.com Mon, 07 Apr 2014 12:59:55 +0200
diff --git a/debian/service/service b/debian/service/service
index feef474..387420a 100755
--- a/debian/service/service
+++ b/debian/service/service
@@ -129,6 +129,8 @@ while [ $# -gt 0 ]; do
esac
done
+# Operate against system upstart, not session
+unset UPSTART_SESSION
if [ -r /etc/init/${SERVICE}.conf ] which initctl /dev/null \
initctl version 2/dev/null | grep -q upstart \
initctl status ${SERVICE} 2/dev/null 1/dev/null
diff --git a/debian/src/sysv-rc/sbin/invoke-rc.d b/debian/src/sysv-rc/sbin/invoke-rc.d
index 88b178e..cdfc8d8 100644
--- a/debian/src/sysv-rc/sbin/invoke-rc.d
+++ b/debian/src/sysv-rc/sbin/invoke-rc.d
@@ -267,6 +267,8 @@ case ${ACTION} in
;;
esac
+# Operate against system upstart, not session
+unset UPSTART_SESSION
# If we're running on upstart and there's an upstart job of this name, do
# the rest with upstart instead of calling the init script.
if which initctl /dev/null initctl version 2/dev/null | grep -q upstart \
--
1.9.1
Bug#745505: sysv-rc: Operate against system-upstart only
[John Ledkov Dimitri] Package: sysv-rc Version: 2.88dsf-53 Severity: normal Tags: patch Dear Maintainer, Look good to me. Feel free to commit to git. :) Btw, can you confirm that the current startpar package is working well with upstart? -- 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#745506: nsd3: nsdc running no longer returns correct exit status
Package: nsd3 Version: 3.2.12-3+deb7u1 Severity: important Tags: patch Dear Maintainer, nsdc running is supposed to return 0 only if nsd is currently running. This is the behaviour defined in the man page and we rely on it especially now nsd3 is failing to restart. The Debian-specific patch 0001-Update-nsdc.patch breaks this behaviour. If nsd is not running, the pid file does not exist and so it will fall through the end of the signal function and return 0, which in turn is used as the exit status of the script. The correct fix is to restore the deleted line return 1 at the end of the signal function. Regards, David -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nsd3 depends on: ii adduser 3.113+nmu3 ii libc62.13-38+deb7u1 ii libssl1.0.0 1.0.1e-2+deb7u6 ii lsb-base 4.1+Debian8+deb7u1 nsd3 recommends no packages. nsd3 suggests no packages. -- Configuration Files: /etc/nsd3/nsd.conf.sample [Errno 13] Permission denied: u'/etc/nsd3/nsd.conf.sample' -- 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#745503: sysv-rc: check that jobs are known to upstart
[John Ledkov Dimitri] Package: sysv-rc Version: 2.88dsf-53 Severity: normal Tags: patch Dear Maintainer, Look good to me. Feel free to commit it to git. -- 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#745453: [libgcrypt20] Non free RFC
On Tue, Apr 22, 2014 at 1:30 PM, Simon Josefsson si...@josefsson.org wrote: Two comments: 1) Looking at crc.c, I don't think the code in question is big enough to be copyrightable. The FSF usually uses a 10-line limit, and my impression is that they are intentionally conservative here. The code is a couple of lines only. 2) Code from some RFCs is available under the BSD license or for smaller snippets, under fair use, via the IETF Trust. See http://trustee.ietf.org/faq.html Ok this could be thus documented under your COPYING File and reflected back in debian/copyright. Bastien /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743215: write: you are uid ???, but your login is as uid 0
Package: bsdmainutils Version: 9.0.5 Followup-For: Bug #743215 I'd like to point out this is actually Debian-specific behavior (the original source doesn't have this restriction). Could somebody address as to why this check was put in place? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745471: lcms2: CVE-2014-0459
Control: tags -1 fixed-upstream Control: forwarded -1 https://github.com/mm2/Little-CMS/issues/29 thanks I intend to upload a fixed version soon, using the upstream patch. Thanks Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732360: sponsorship status
Hi Ghislain, On Tue, Apr 22, 2014 at 01:16:13PM +0100, Ghislain Vaillant wrote: Are you still interested in sponsoring this package ? I have no specific wish to sponsor this package and if somebody else wants to step in I'd be more than happy. However, I just went the SoB route and uploaded to keep your motivation high to provide Debian Science packages. :-) Thanks for your preparation 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#727536: liferea: crash when clicking on last unread item
On Thu, Oct 24, 2013 at 12:21 AM, Paul Wise p...@debian.org wrote: Package: liferea Version: 1.10.3-1 Severity: important I got a crash when clicking on the last unread item in the Unread items folder. I have included a backtrace from this crash below. I will have the core file for the next 7 days and then it will be automatically removed by corekeeper, please let me know if you need any more details. If the backtrace isn't useful please just close this bug. Paul, are you still getting this with 1.10.8? Upstream just responded that they haven't been able to reproduce and also said that 1.10.4 contained a fix for problems related to the selection of the last item. A trace from 1.10.8 would be useful to upstream if you're still getting this crash. -David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745453: [libgcrypt20] Non free RFC
You wrote: On Tue, Apr 22, 2014 at 1:30 PM, Simon Josefsson si...@josefsson.org wrote: Two comments: 1) Looking at crc.c, I don't think the code in question is big enough to be copyrightable. The FSF usually uses a 10-line limit, and my impression is that they are intentionally conservative here. The code is a couple of lines only. 2) Code from some RFCs is available under the BSD license or for smaller snippets, under fair use, via the IETF Trust. See http://trustee.ietf.org/faq.html Ok this could be thus documented under your COPYING File and reflected back in debian/copyright. Feel free to forward it upstream to Werner. I think COPYING reflect the correct licensing status of the package though, so I'm not sure what should be added there? /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744297: apt: doesn't reset colors after Ctrl+C
On Sat, Apr 12, 2014 at 05:48:55PM +0200, Jakub Wilk wrote: Package: apt Version: 1.0.1 Severity: minor Thanks for your bugreport. When I press Ctrl+C when apt is working, it doesn't reset colors, leaving my shell prompt yellowish. See the attached screenshot. This is fixed in the git tree and it will be part of the next upload. Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745507: ITP: golang-go-systemd-dev -- Go client bindings for systemd
Package: wnpp Severity: wishlist URL: https://github.com/coreos/go-systemd License: Apache-2.0 ♥, - Tianon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651170: PyXB package status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2014-04-22 13:30, Ghislain Vaillant wrote: Any progress on the packaging of pyxb ? Where is it at, at the moment ? Just asking because one of the packages I am working on could later have an optional dependency on it. Nobody wanted to sponsor this package at the time I asked for it. I'm polishing up its packaging right now and I will ask my NM advocate if he wants to sponsor it... Cheers, - -- Michael Fladischer Fladi.at -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJTVmTbAAoJEGlMre9Rx7W2MuEP/3YEoqO8Gs5aJfcv4N8VrDZP pUvbKQhUSARpexQGN1TTs9hrnk4OdQp8W5AjyoGnNdTEGIxC0wwzHI2OnEJhlWFa wnu3HgNqNQGbtDfuFdzV26IMdE6PjkbB8trGG4f+doAD+ZjDXqH0LdC51GBh6dC7 jcqCk4XH/5swbkJkZLWo8eIawbT3y66s4/DRk+bhawokN7TyHVD5BKotmiPIsMBN CfxMqpjK5zrAx1g3r9chQkydo9SaAPZtZL5XOv6L3lWpizM/NKDEc7AF7UaBV+zY 84mO1/EkY72NUYBKfi1wJdHz7tJ01QCQeNe8+/yvTQWb/tZYPLSfqPqois5vU/Uj KdkSlkA8rTSR9KVCleKSyOcgzRc7mfRJqkoAyN5KEr5oMUEIsPLjaX9cJZdKOsZt tJz2ctsw8GkPsuRV8uaC+vxlvGUPoe/n+hm81YVpeeAWUhooraYvQqTkuD3rC1zk eUwUfiRnlBDo2vEmyxesuEzVY89ifoyqkzauk6I41+FWw+35tPFOQ3pkGTb5ELgW QeHaSRk2sN5n4d4Ec91MRSxm8Xn4MID5geYWAUOzsGF8xuh6W9odvhq3AhD+5Vim f9pjeg9nGTQyWoeggMansZfDDN99KWj/N3HVoFE6vfTStST8UvBZB/Q0eYIlwPlN uH4a1+K5ucACVqm4BNrT =Zojq -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#745508: heimdal: Enable parallel build
Source: heimdal Severity: wishlist Tags: patch Dear Maintainer, Please consider enabling parallel build on your package, it does save at least 4 minutes of build time on my machine. Regards, Dimitri. diff -Nru heimdal-1.6~rc2+dfsg/debian/rules heimdal-1.6~rc2+dfsg/debian/rules --- heimdal-1.6~rc2+dfsg/debian/rules 2014-04-21 16:52:33.0 +0100 +++ heimdal-1.6~rc2+dfsg/debian/rules 2014-04-22 13:32:36.0 +0100 @@ -4,7 +4,7 @@ DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) %: - dh $* --with autoreconf + dh $* --with autoreconf --parallel override_dh_strip: dh_strip --dbg-package=heimdal-dbg
Bug#735660: ruby-filesystem: diff for NMU version 0.5-5.1
tags 735660 + patch tags 735660 + pending thanks Dear maintainer, I've prepared an NMU for ruby-filesystem (versioned as 0.5-5.1) and uploaded it to DELAYED/0. Please feel free to tell me if I should delay it longer. Regards. Cédric diff -Nru ruby-filesystem-0.5/debian/changelog ruby-filesystem-0.5/debian/changelog --- ruby-filesystem-0.5/debian/changelog 2012-11-24 14:29:39.0 +0100 +++ ruby-filesystem-0.5/debian/changelog 2014-04-22 14:57:03.0 +0200 @@ -1,3 +1,19 @@ +ruby-filesystem (0.5-5.1) unstable; urgency=medium + + * Non-maintainer upload. + * Upload to unstable. + * Do not depend explicitly on a version of ruby (Closes: #735660) +- XS-Ruby-Versions is now set to all + * Drop DM-Upload-Allowed flag + * Drop quilt from Build-Depends (the 3.0 (quilt) source format is used) + * Rely on gem2deb magic to build and install +- erase upstream outdated Makefile, regenerated from extconf +- move files to ext/filesystem instead of build to use gem convention +- don't override dh_auto_build and dh_auto_install targets +- drop the --with quilt option to dh, add --buildsystem=ruby + + -- Cédric Boutillier bou...@debian.org Tue, 22 Apr 2014 14:13:14 +0200 + ruby-filesystem (0.5-5) experimental; urgency=low * Fix segfault on 64bit environment (use NULL (!=0) for termination for diff -Nru ruby-filesystem-0.5/debian/control ruby-filesystem-0.5/debian/control --- ruby-filesystem-0.5/debian/control 2012-11-24 14:29:39.0 +0100 +++ ruby-filesystem-0.5/debian/control 2014-04-22 14:56:19.0 +0200 @@ -2,10 +2,9 @@ Section: ruby Priority: extra Maintainer: Tatsuki Sugiura s...@nemui.org -Build-Depends: debhelper (= 8.0.0), quilt, gem2deb (= 0.2.7~), ruby1.8, ruby1.8-dev, ruby1.9.1, ruby1.9.1-dev +Build-Depends: debhelper (= 8.0.0), gem2deb (= 0.2.7~) Standards-Version: 3.9.3 -DM-Upload-Allowed: yes -XS-Ruby-Versions: 1.8 1.9.1 +XS-Ruby-Versions: all Uploaders: Taku YASUI t...@debian.org Package: ruby-filesystem diff -Nru ruby-filesystem-0.5/debian/rules ruby-filesystem-0.5/debian/rules --- ruby-filesystem-0.5/debian/rules 2012-11-24 14:29:39.0 +0100 +++ ruby-filesystem-0.5/debian/rules 2014-04-22 14:39:25.0 +0200 @@ -1,23 +1,12 @@ #!/usr/bin/make -f -TARGETDIR=$(CURDIR)/debian/ruby-filesystem -RBCONFIG=ruby -rrbconfig -e 'print RbConfig::CONFIG[ARGV[0]]' - %: - dh $@ --with ruby --with quilt + dh $@ --buildsystem=ruby --with ruby override_dh_auto_configure: - mkdir -p build - cp -a *.rb *.c build - -override_dh_auto_build: - -override_dh_auto_install: - cd build ruby1.8 -Ku extconf.rb - make -C build install DESTDIR=$(TARGETDIR) sitedir=$(TARGETDIR)/usr/lib/ruby/vendor_ruby - make -C build clean - cd build ruby1.9.1 -Ku extconf.rb - make -C build install DESTDIR=$(TARGETDIR) sitedir=$(TARGETDIR)/usr/lib/ruby/vendor_ruby + mkdir -p ext/filesystem + cp -a *.rb *.c ext/filesystem override_dh_auto_clean: - rm -rf build + rm -f Makefile + rm -rf ext/ signature.asc Description: Digital signature
