Bug#712118: marked as done (RFS: splix/2.0.0+svn308-1)
Hi Luca, Le mercredi, 1 janvier 2014, 20.58:02 Luca Niccoli a écrit : Hi Didier and Till, I'm reopening the RFS bug for splix. I'm awfully sorry to have failed to answer you earlier, let's correct that now. I've uploaded a new version of splix that merges the last upstream changes (mainly dropping patches that have been accepted upstream), sets the maintainer as the Debian Printing Team and moves the packaging to a git workflow. Great! Could you make your git repository available somewhere so that I could review the git workflow itself too? You can find the dsc at http://mentors.debian.net/debian/pool/main/s/splix/splix_2.0.0+svn315- 1.dsc If you are too busy I can ask my usual sponsor if he is available to upload it, but I think moving the package under the Debian Printing Team umbrella should be done by a member. I'll make sure to make myself available enough to get that uploaded. Now for the review: * I find the debian/changelog entry quite messy and I do prefer to hand- edit it after git-dch to make it less redundant and more useful to users and other developers. In your case, at least two Standards-Version updates are redundant, same goes for upstream imports; I would write it that way for example: splix (2.0.0+svn315-1) unstable; urgency=medium * New svn upstream snapshot (revision 315) - Add support for Samsung ML-2160 (Closes: #696240). - Add support for Samsung ML-2165. * Drop patches that have been merged upstream * Add get-orig-source target to fetch recreate the tarball from upstream SVN. * Set debian build flags during build. * Make build verbose to have more informative buildd logs. * Imported existing quilt patches into gbp-pq and refreshed them for the new upstream version. * Fixed splix.ppd-updater, thanks to Till Kamppeter. * Add apport hook on Ubuntu and derivatives (reduces the package delta). * Move package under the Debian Printing Team umbrella. * Bump Standards-Version to 3.9.5 (no changes needed) That's arguably a minor nitpick, but a good changelog really helps identifying potential problems. * Otherwise, I only see the Vcs-Git and Vcs-Browser fields missing, but it's arguably not possible to set them before the git repository is available. :-) * In short; it is mostly uploadable! :-) Also, not being a DD I can not upload my local git repo on Alioth; it would be nice if someone from the team could create it for me and add me to the project. Cheers, Your alioth account is lultimouomo-guest, right ? Can you request to get added to the collab-maint alioth project as documented on https://lists.debian.org/debian-devel-announce/2012/01/msg6.html ? I will then request your inclusion in this (lightweight and general- purpose) project, so that you can maintain splix as a collab-maint git repository. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#730817: cups: Cups doesnt have support to Epson L355
Le vendredi, 3 janvier 2014, 23.29:42 Didier '' Raboud a écrit : The Epson L355 is only supported by the non-free epson-inkjet- printer-201207w driver, which you can download in .deb form from the Epson drivers download site: http://download.ebz.epson.net/ (type in L355, and follow the Download links. See: http://www.openprinting.org/printer/Epson/Epson-L355_Series Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689899: Ships a folder in /var/run or /var/lock (Policy Manual section 9.3.2)
Le jeudi, 2 janvier 2014, 19.08:14 Didier '' Raboud a écrit : Le jeudi, 2 janvier 2014, 18.49:31 Andreas Barth a écrit : So please remove your upload until I can review the situation again. It hasn't been uploaded yet, as it was building on my slow server. But unless you oppose the patch _content_ (and not the belief that I would upload a variation of rmdir -f) which I'm attaching to this mail for your convenience, I will upload this NMU to DELAYED/5. Considering you've had your chance to respond to this (and given that you managed to respond in less than a half-hour last time), I have uploaded the proposed debdiff to DELAYED/5 as announced. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#733599: cups: Should not load parallel port modules if there are none
Le jeudi, 2 janvier 2014, 16.05:06 Brian Potkin a écrit : May I suggest that there is no bug at all here and setting LOAD_LP_MODULE=no is the intended way to achieve what Benoît wants to do. Thanks for pointing that, indeed! (Don't hesitate to do further suggestions, I value them highly, for what is worth!) Unfortunately your mail got caught in my mail fetching delay and I independently discovered that too… Yay. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#689899: Ships a folder in /var/run or /var/lock (Policy Manual section 9.3.2)
Hi Andreas, This opposition of yours was more than one year ago: Le dimanche, 7 octobre 2012, 19.26:08 Andreas Barth a écrit : With my mgetty maintainer hat on, I refuse any NMU with this (or a similar) patch applied, unless otherwise authorized by me (as exception of my easy NMU policy I usually use for all packages). … and this new proposal was more than six months ago: Le mercredi, 21 août 2013, 15.41:53 gregor herrmann a écrit : E: mgetty-fax: dir-or-file-in-var-lock var/lock/fax/ E: mgetty-fax: dir-or-file-in-var-run var/run/mgetty-fax/ This is now in the ftp-master autoreject list, thus no further upload of mgetty is possible (cf. #719501). Raising the severity. I'm attaching a proposed patch; reviews welcome. + * Fix Ships a folder in /var/run or /var/lock (Policy Manual section +9.3.2): +- don't create the directories in mgetty-fax.dirs +- don't change their permissions in mgetty-fax.postinst +- they are already created at runtime in mgetty-fax.init.d + including setting permissions +- remove them in mgetty-fax.postrm during purge +(Closes: #689899) As mgetty got removed from testing some days ago along with some of its reverse-dependencies, this has become more important now. I will therefore upload a new 1.1.36-1.7 with the fixes for both #719501 and #689899 to DELAYED/5 (although devref §5.11.1 would allow a direct upload). Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#689899: Ships a folder in /var/run or /var/lock (Policy Manual section 9.3.2)
Hi Andreas, Le jeudi, 2 janvier 2014, 18.49:31 Andreas Barth a écrit : … and this new proposal was more than six months ago: I opposed having an upload of rmdir -rf /var/run/mgetty || true Sure; I read that. That said, gregoa's patch is significantly different from that, as it does the following: - don't create the directories in mgetty-fax.dirs --- mgetty-1.1.36/debian/mgetty-fax.dirs +++ mgetty-1.1.36/debian/mgetty-fax.dirs @@ -9,3 +9 @@ -var/lock/fax var/log/mgetty/fax -var/run/mgetty-fax - don't change their permissions in mgetty-fax.postinst - they are already created at runtime in mgetty-fax.init.d including setting permissions --- mgetty-1.1.36/debian/mgetty-fax.postinst +++ mgetty-1.1.36/debian/mgetty-fax.postinst @@ -54,8 +54,7 @@ dpkg-statoverride --update --add $FAX_USER $FAX_GROUP 4755 /usr/lib/mgetty-fax/faxq-helper; fi -for i in /var/spool/fax/outgoing /var/log/mgetty/fax \ - /var/run/mgetty-fax /var/lock/fax; do +for i in /var/spool/fax/outgoing /var/log/mgetty/fax; do if ! dpkg-statoverride --list $i /dev/null; then dpkg-statoverride --update --add $FAX_USER root 0755 $i; fi and - remove them in mgetty-fax.postrm during purge --- mgetty-1.1.36/debian/mgetty-fax.postrm +++ mgetty-1.1.36/debian/mgetty-fax.postrm @@ -17,6 +17,7 @@ rmdir /etc/mgetty || true; rm -f /var/spool/fax/outgoing/faxqueue_done rmdir /var/spool/fax/outgoing /var/spool/fax || true; +rm -rf /var/lock/fax /var/run/mgetty-fax ;; *) ;; I think that is still legitimite to not want to have that done. Sure; I didn't challenge that. Le mercredi, 21 août 2013, 15.41:53 gregor herrmann a écrit : I will therefore upload a new 1.1.36-1.7 with the fixes for both #719501 and #689899 to DELAYED/5 (although devref §5.11.1 would allow a direct upload). This is not correct. If you don't like my decisions, you need to have them overwritten by the tech ctte. According to the buglog, you opposed rmdir -rf /var/run/mgetty || true or similar. gregoa proposed something different back in august 2013 to which you didn't respond (or even apparently read). That was four months ago (the bug itself is now 14 months old. I'm proposing to upload this proposal which, in my reading, doesn't fit what you opposed. So please remove your upload until I can review the situation again. It hasn't been uploaded yet, as it was building on my slow server. But unless you oppose the patch _content_ (and not the belief that I would upload a variation of rmdir -f) which I'm attaching to this mail for your convenience, I will upload this NMU to DELAYED/5. Cheers, OdyXdiff -u mgetty-1.1.36/debian/changelog mgetty-1.1.36/debian/changelog --- mgetty-1.1.36/debian/changelog +++ mgetty-1.1.36/debian/changelog @@ -1,3 +1,23 @@ +mgetty (1.1.36-1.7) unstable; urgency=low + + * Non-maintainer upload. + * Include the two proposed patches from gregor herrmann, thank you! + + [ gregor herrmann ] + * Fix FTBFS with perl 5.18: POD errors: +apply patch from from brian m. carlson to debian/vm.pod. +(Closes: #719501) + * Fix Ships a folder in /var/run or /var/lock (Policy Manual section +9.3.2): +- don't create the directories in mgetty-fax.dirs +- don't change their permissions in mgetty-fax.postinst +- they are already created at runtime in mgetty-fax.init.d + including setting permissions +- remove them in mgetty-fax.postrm during purge +(Closes: #689899) + + -- Didier Raboud o...@debian.org Thu, 02 Jan 2014 18:20:26 +0100 + mgetty (1.1.36-1.6) unstable; urgency=low * Non-maintainer upload. diff -u mgetty-1.1.36/debian/mgetty-fax.postinst mgetty-1.1.36/debian/mgetty-fax.postinst --- mgetty-1.1.36/debian/mgetty-fax.postinst +++ mgetty-1.1.36/debian/mgetty-fax.postinst @@ -54,8 +54,7 @@ dpkg-statoverride --update --add $FAX_USER $FAX_GROUP 4755 /usr/lib/mgetty-fax/faxq-helper; fi -for i in /var/spool/fax/outgoing /var/log/mgetty/fax \ - /var/run/mgetty-fax /var/lock/fax; do +for i in /var/spool/fax/outgoing /var/log/mgetty/fax; do if ! dpkg-statoverride --list $i /dev/null; then dpkg-statoverride --update --add $FAX_USER root 0755 $i; fi diff -u mgetty-1.1.36/debian/vm.pod mgetty-1.1.36/debian/vm.pod --- mgetty-1.1.36/debian/vm.pod +++ mgetty-1.1.36/debian/vm.pod @@ -26,9 +26,12 @@ =item devicetest +=back =head1 OPTIONS +=over 4 + =item B-c n use compression type Bn @@ -68,6 +71,8 @@ =item B-V n set silence threshold to n (0-100%%) +=back + =head1 SEE ALSO Lvgetty(1) diff -u mgetty-1.1.36/debian/mgetty-fax.postrm mgetty-1.1.36/debian/mgetty-fax.postrm --- mgetty-1.1.36/debian/mgetty-fax.postrm +++ mgetty-1.1.36/debian/mgetty-fax.postrm @@ -17,6 +17,7 @@ rmdir /etc/mgetty || true; rm -f /var/spool/fax/outgoing/faxqueue_done rmdir /var/spool/fax/outgoing
Bug#733981: [cups-filters] cups-filters (1.0.39-1) UNRELEASED in changelog
Control: tags -1 +pending Le jeudi, 2 janvier 2014, 15.03:31 Filipus Klutiero a écrit : The changelog contain an entry for 1.0.39-1, which never entered Debian. The change descriptions are duplicated in 1.0.41-1's changelog. Indeed, thanks, I've committed the removal of that changelog entry: http://anonscm.debian.org/gitweb/?p=pkg-cups/cups-filters.git;a=commitdiff;h=2348418b613dcad0c874ac119c9d3f7238db9d36 I didn't change the typo though; that'll live up in history. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#732435: cups: please shit systemd service file
Control: retitle -1 cups: please ship systemd support Control: tags -1 +upstream Control: forwarded -1 http://cups.org/str.php?L3917 Control: tags -1 +patch Le mardi, 17 décembre 2013, 16.27:30 Shawn Landden a écrit : Cups supports systemd socket activation so it only starts when needed. https://github.com/ash211/systemd-arch-units/blob/master/service/cups. service https://github.com/rookus/systemd-arch-units/blob/master/socket/cups. socket https://wiki.archlinux.org/index.php/CUPS#CUPS.27_systemd_service_doe s_not_start_even_though_it.27s_enabled etc upstream should really deal with this... Indeed. This has been reported in 2011 on the upstream bugtracker. The most up-to-date systemd support patches seem to be Fedora's: http://pkgs.fedoraproject.org/cgit/cups.git/tree/cups-systemd-socket.patch That said, I am very likely to wait on both the resolution of the init system choice decision by the technical committee (#727708) and/or the inclusion of this patchset by upstream. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#678147: fixed in wpa 1.0-3.1
Hi Daniel, Le mardi, 10 décembre 2013, 21.50:23 Daniel Kahn Gillmor a écrit : Changes: wpa (1.0-3.1) unstable; urgency=low . * Non-Maintainer Upload * enable IBSS RSN, thanks to Nicolas Cavallari batch...@free.fr (Closes: #678147). Apparently this upload of yours failed to successfully compile [0] on the kFreeBSDs with the following error: /usr/bin/ld: ../src/eap_peer/tncc.o: undefined reference to symbol 'dlsym@@GLIBC_2.3' /lib/x86_64-kfreebsd-gnu/libdl.so.2: error adding symbols: DSO missing from command line [0] https://buildd.debian.org/status/logs.php?pkg=wpaver=1.0-3.1 It'd be nice to make sure your NMU (which I support btw :) ) can migrate to Jessie. TIA, cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690536: wpasupplicant does not enable AP mode at compile time
Le vendredi, 10 mai 2013, 00.57:54 Vlad Orlov a écrit : Hello, This creates an untimely problem though, this may not be a category of bug which qualifies for release team exception at this very late time in the release cycle. Now that wheezy is released, can this patch be applied? This has also been applied in Ubuntu trusty along with CONFIG_P2P (Wi-Fi Direct support): http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/wpa/trusty/revision/9 The fact that CONFIG_AP_MODE is not enabled is confusing for users of NetworkManager as creating a shared WiFi connection will fail without a clear reason besides a wpa_supplicant[]: wlan0: AP mode support not included in the build line in syslog. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731838: colobot: missing menu file Jessie Release Goal
Control: tags -1 +pending Le mardi, 10 décembre 2013, 11.37:44 Markus Koschany a écrit : colobot does not supply a menu file hence the game is not well integrated into the user's desktop environment. Please add an icon entry to your menu file too. Indeed; thanks for the report. I have committed the attached patch. Cheers, OdyXFrom a59d1606c3592fad39194c0bc6b49e555acf9f6f Mon Sep 17 00:00:00 2001 From: Didier Raboud o...@debian.org Date: Tue, 17 Dec 2013 13:49:01 +0100 Subject: [PATCH] Add menu file and xpm icon Therefore add imagemagick to Build-Depends to convert the icon from the 32x32 png Closes: #731838 --- debian/colobot.install | 1 + debian/colobot.menu| 6 ++ debian/control | 3 ++- debian/rules | 6 ++ 4 files changed, 15 insertions(+), 1 deletion(-) create mode 100644 debian/colobot.menu diff --git a/debian/colobot.install b/debian/colobot.install index 6d594f1..ecd08f8 100644 --- a/debian/colobot.install +++ b/debian/colobot.install @@ -4,6 +4,7 @@ usr/share/applications/colobot.desktop usr/share/icons/hicolor/scalable/apps/colobot.svg usr/share/icons/hicolor/48x48/apps/colobot.png usr/share/icons/hicolor/32x32/apps/colobot.png +debian/colobot.xpm usr/share/pixmaps/ usr/share/icons/hicolor/16x16/apps/colobot.png usr/share/man/man6/colobot.6 usr/share/man/*/man6/colobot.6 diff --git a/debian/colobot.menu b/debian/colobot.menu new file mode 100644 index 000..6b8e812 --- /dev/null +++ b/debian/colobot.menu @@ -0,0 +1,6 @@ +?package(colobot):needs=X11 \ + section=Games/Adventure \ + title=Colobot \ + longtitle=Colobot - Colonize with bots - Game to learn programming \ + icon=/usr/share/pixmaps/colobot.xpm \ + command=/usr/games/colobot diff --git a/debian/control b/debian/control index 4102536..064d3f7 100644 --- a/debian/control +++ b/debian/control @@ -22,7 +22,8 @@ Build-Depends: po4a, perl, google-mock, - libgtest-dev + libgtest-dev, + imagemagick Build-Depends-Indep: doxygen, graphviz Vcs-Git: git://anonscm.debian.org/collab-maint/colobot.git -b debian Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/colobot.git diff --git a/debian/rules b/debian/rules index 171cbb8..67410d6 100755 --- a/debian/rules +++ b/debian/rules @@ -14,3 +14,9 @@ override_dh_auto_configure: override_dh_auto_build: dh_auto_build -a dh_auto_build -i -- doc + # obj-* is the default builddirectory in debhelper + convert obj-$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)/desktop/32/colobot.png debian/colobot.xpm + +override_dh_auto_clean: + dh_auto_clean + rm -f debian/colobot.xpm -- 1.8.4.rc3 signature.asc Description: This is a digitally signed message part.
Bug#610014: /usr/bin/pdftops: pdftops doesn't rotate landscape pages
Control: affects -1 src:cups-filters Le vendredi, 14 janvier 2011, 21.05:30 Emil a écrit : A landscape PDF was produced and then printed with lpr. The print was incorect because it was not rotated. I'm using magicfilter on my system for printing (this is not relevant though) and my printer filter calls pdftops and then the PostScript file is passed to ghostscript for printing. If I add the paper parameter to pdftops like this 0 %PDF fpipe /usr/bin/pdftops -paper A4 $FILE - then the printing is correct and the created PS file is properly marked/rotated This bug also affects printing from xpdf but there is no workaround for xpdf because xpdf uses common libraries with pdftops and when it sends the file to the printer it is already converted to PS and setting the psPaperSize to A4 in /etc/xpdf/xpdfrc has no effect. This bug appeared in the last 3-4 months, before that both pdftops and xpdf were printing properly. As Till mentionned on the debian-printing list [0], there is a patch available on the upstream bug tracker that addresses this bug [1]. Please backport it to poppler so that the workaround in cups-filters can be dropped. [0] http://lists.debian.org/debian-printing/2013/12/msg5.html [1] https://bugs.freedesktop.org/show_bug.cgi?id=72312 Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#479397: [Gimp-print-devel] Removing myself from the project
Hi Till, Le vendredi, 8 novembre 2013, 15.54:09 Till Kamppeter a écrit : On 11/08/2013 02:34 PM, Roger Leigh wrote: I'm still looking for someone to maintain the packages in Debian, should anyone have an interest in picking this up. The gutenprint packages would certainly benefit from having a maintainer who uses them on a regular basis, which is not something I can claim nowadays, I'm afraid. OdyX, would you continue maintaining the Debian package of Gutenprint? I would rather not, frankly. I'm not using it and have my share of printing-related packages already. But there's light! There's a Intent To Adopt bug filed for gutenprint: http://bugs.debian.org/479397 , where Willem van den Akker volunteered to maintain gutenprint in Debian. Willem: are you still up for it? Do you need assistance of any kind? I'd be much happier to ramp you up to maintain gutenprint than maintaining it myself, so please ask! Roger, also thank you very much for all the work on Gutenprint. Indeed, many thanks Roger! Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#725876: CVE assigned
Control: severity -1 serious Le jeudi, 28 novembre 2013, 07.06:24 Salvatore Bonaccorso a écrit : CVE-2013-6402 was now assigned to this issue. No severity was apparently assigned to this bugreport. I think that's RC, hereby making this serious. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#731016: Can't mount external USB HD Asus AN300
Control: reassign -1 linux-image-3.11-2-amd64 3.11.8-1 Le mercredi, 4 décembre 2013, 11.01:14 Josua Dietze a écrit : It's clear now that usb_modeswitch can't do anything here. Please reassign - my guess is that it's a kernel driver thing, either USB 3.0 host or usb-storage (or both). Hereby reassigning to the originally reported kernel version. Ben: if there's something we (as usb-modeswitch upstream and maintainer) can do to help here, please ask. Cheers, OdyX -- OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730819: Help file for Ruin does not exist
Control: forwarded -1 https://github.com/colobot/colobot/issues/255 Control: tags -1 +confirmed Le vendredi, 29 novembre 2013, 21.34:05 Artur R. Czechowski a écrit : Run help with CBOT reference (F2 key), select Categories, then in section Miscellaneous select Ruin. Nothing happens after clickin. There is no file with Ruin help in colobot-common. Indeed, thanks for reporting the bug both here and on the upstream tracker. Hereby tagging as confirmed and forwarded. Cheers, OdyX -- OdyX signature.asc Description: This is a digitally signed message part.
Bug#659606: apsfilter suggests a dummy pnm2ppa
Control: severity -1 important Control: retitle -1 apsfilter suggests inexistant pnm2ppa Le dimanche, 12 février 2012, 18.14:57 jaa...@ro.ru a écrit : apsfilter suggests the transitional pnm2ppa, which has been superseeded by printer-driver-pnm2ppa. It is strange, perhaps even useless, to suggest a transitional package. The pnm2ppa package has now been dropped from the unstable version of pnm2ppa and made the apsfilter suggestion moot (hereby rising severity and retitling). Please rewrite the suggestion to be towards printer-driver-pnm2ppa. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727758: Bug #727758: cups segfaults in libdbus - Fixed in 1.6.4-2 ?
Hi all, sorry for my delay in answering this bug… I have cherry-picked a set of patches from Fedora into cups 1.6.4-2 including two dbus related ones: - Avoid stale lockfile in dbus notifier - Stop accessing avahi through D-Bus using two threads It would be nice if you could attempt reproducing this bug with 1.6.4-2 and report back to the bugreport. Thanks in advance, cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#730725: ghostscript-cups break cups/sid
Hi Alf, Le jeudi, 28 novembre 2013, 19.52:10 Alf Gaida a écrit : Package: ghostscript-cups Version: ghostscript-9.05~dfsg Severity: important Dear Maintainer, try apt-get install ghostscript-cups with cups installed LANG=C apt-get install ghostscript-cups Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: cups cups-filters The following NEW packages will be installed: ghostscript-cups 0 upgraded, 1 newly installed, 2 to remove and 0 not upgraded. Need to get 0 B/60.7 kB of archives. After this operation, 1503 kB disk space will be freed. Do you want to continue? [Y/n] n Expected: Cups should not be removed. From the cups-filters 1.0.41 changelog: * debian/control: Added Conflicts/Provides/Replaces: ghostscript-cups to the cups-filters binary package as all files from ghostscript-cups moved to cups-filters. So this is expected and ghostscript-cups should be removed automatically instead. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729752: Acknowledgement (pyside: Fontconfig warning multiple values in test not supported)
Control: reassign -1 fonts-android 1:4.3-1 Control: retitle -1 Spits multiple fontconfig warnings for many programs Le samedi, 16 novembre 2013 20.53:33 xiscu a écrit : Dear Developers, I've just noticed that it cannot be a pyside issue as just starting idle triggers the issue: $ idle Fontconfig warning: /etc/fonts/conf.d/65-andika.conf, line 16: Having multiple values in test isn't supported and may not work as expected This bug is http://bugs.debian.org/687172 Fontconfig warning: /etc/fonts/conf.d/65-droid-sans-fonts.conf, line 103: Having multiple values in test isn't supported and may not work as expected This bug is not reported, let's reassign this one against fonts-android. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725967: pnm2ppa: diff for NMU version 1.13-4.1
Le jeudi, 14 novembre 2013 11.53:04 Colin Watson a écrit : I've prepared an NMU for pnm2ppa (versioned as 1.13-4.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Hi Colin, thanks for this NMU, it's OKay for me, please let it proceed immediately, and sorry for my un-reactiveness these days. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#695966: kde-workspace-bin: KDE powerdevil sometimes incorrectly attempts to hibernate when resuming from suspend
Control: forwarded -1 http://bugs.kde.org/show_bug.cgi?id=326017 Le jeudi, 14 novembre 2013 10.26:03 Maximiliano Curia a écrit : Yes, please report it upstream. The only bug related I could find about this is: https://bugs.kde.org/show_bug.cgi?id=326017 Also, if possible, add the forwarded tag with bts-link once submitted. Done, thanks for the search, cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#722890: any progress?
Le vendredi, 1 novembre 2013 10.24:52 Enrico Tassi a écrit : Any progress? Do you want me to prepare an upload and nmu it do a delayed queue? Thanks for the ping. And for the patch ! I will upload 1.0.1-2 shortly, with your patch. Cheers, OdyX -- OdyX signature.asc Description: This is a digitally signed message part.
Bug#695500: d-i-n-i: #695500 is apparently a grub-mkimage (or debian-installer) bug
Control: reassign -1 src:debian-installer 20120828 , grub-common 1.99-27 Control: tags -1 -moreinfo Control: affects -1 +debian-installer-7.0-netboot-kfreebsd-i386 Control: affects -1 +debian-installer-7.0-netboot-kfreebsd-amd64 Hi all, I spent some more time debugging this RC bug by setting up my server and testing the PXE boot of kfreebsd-i386 on two different laptops; the results are: * the error: prefix is not set error always appears when using the wheezy grub2pxe; it also happens with the current sid grub2pxe [0]; * the resistance to this error apparently depends on the PXE implementation: - my acer Aspire One displays the error and then proceeds to displaying grub, then allowing the boot of the kfreebsd-i386 installer; - my ThinkPad X220 displays the error and stops; - kvm launched locally with [1] proceeds to grub; [0] http://http.debian.net/debian/dists/sid/main/installer-kfreebsd-i386/20130430/images/netboot/grub2pxe [1] kvm -m 256 -net nic -net - user,bootfile=/grub2pxe,tftp=/usr/lib/debian-installer/images/7.0/kfreebsd-amd64/gtk/ As debian-installer-netboot-images is only copying these files from the mirrors, I don't think it is the correct source package to track this bug. The above tests now make me think that this is either a problem of debian-installer calling grub-mkimage wrongly in build/config/kfreebsd.cfg or a bug in grub-mkimage not incorporating the prefix correctly when creating a PXE image. I'm therefore hereby reassigning this bug to both these packages (in their wheezy versions) and marking it as affecting the correct d-i-n-i binary packages. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#722886: cups: Cannot print on DNSSD-shared jessie printers with wheezy client
Hi Joss, thanks for this bugreport. Le samedi, 14 septembre 2013 11.07:59 Josselin Mouette a écrit : when browsing a printer shared with DNS-SD on a jessie (CUPS 1.6) server, wheezy’s /usr/lib/cups/backend/dnssd crashes with a failed assertion: avahi_string_list_get_pair: Assertion `l' failed. This looks exactly like https://bugzilla.redhat.com/show_bug.cgi?id=927040 which points to a patch: http://pkgs.fedoraproject.org/cgit/cups.git/commit/?h=f18id=131a54ac1 c30223ea487893490898360e3cca608 Please consider a stable update for this bug. I can test the packages if needed. I have pushed this patch to the git packaging repository [0] and pushed and amd64 build (+ source) on [1] I will proceed with a pu bug but would appreciate if you could test the build in between. Cheers, OdyX [0] http://anonscm.debian.org/gitweb/?p=pkg-cups/cups.git;a=commit;h=f66442acd3eb82162f870faf0d3c192b866af8cf [1] http://alioth.debian.org/~odyx-guest/debian/stable/ signature.asc Description: This is a digitally signed message part.
Bug#724815: pu: package cups/1.5.3-5+deb7u1
Version: 1.6.1-1 Le samedi, 28 septembre 2013 12.00:40 Cyril Brulebois a écrit : Control: tag -1 wheezy confirmed Didier Raboud o...@debian.org (2013-09-28): This bug is already fixed (or rather, doesn't apply in cups 1.6 as shipped in jessie+ as the cups avahi backend has been rewritten. Please tell the BTS that, then. Hereby doing that, marking as fixed in 1.6.1-1: cups (1.6.1-1) experimental; urgency=low * New upstream release - Avahi-based Bonjour/DNS-SD/mDNS support Looks good to me, please upload. Uploaded, thanks for the fast review! Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#718416: general: tty1 is cleared at boot, obscuring a screenfull of important boot messages
Le mercredi, 31 juillet 2013 15.17:57, Holger Levsen a écrit : reassign 718416 sysvinit thanks $ grep etc/inittab /var/lib/dpkg/info/* /var/lib/dpkg/info/sysvinit.postinst:if [ ! -f /etc/inittab ] /var/lib/dpkg/info/sysvinit.postinst: cp -p /usr/share/sysvinit/inittab /etc/inittab sysvinit didn't change in that regard for a long time. I think the bug belongs to util-linux which changed the getty implementation: util-linux (2.17.2-4) unstable; urgency=low (…) * Deliver agetty as both agetty and getty, preferring agetty. Closes: #117596 (…) -- LaMont Jones lam...@debian.org Fri, 24 Dec 2010 14:06:47 -0700 Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717833: plasma-widget-networkmanagement: VPN connections can't be established anymore
Package: plasma-widget-networkmanagement Version: 0.9.0.9-1 Severity: important Dear Maintainer, Since I upgraded to 0.9.0.9-1, my VPN connections don't establish anymore (in particular, with openconnect). Downgrading to 0.9.0.8-3 fixes that problem. Apparently, the password doesn't get transmitted to the VPN backend properly as I was getting openconnect[7566]: Got inappropriate HTTP CONNECT response: HTTP/1.1 401 Unauthorized lines in syslog with 0.9.0.9-1. I'm happy to provide more logs and help debug that if needed. Cheers, OdyX -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717377: libcups2: A correction for README.Debian
Hi Brian, Le samedi, 20 juillet 2013 01.34:41, Brian Potkin a écrit : Package: libcups2 Version: 1.5.3-5 I think you meant 1.6.3-1 :) When describing printer sharing under the heading 'Advertising your local queues' README.Debian claims: If you do not want it to do so you have to stop avahi-daemon running. The author of this statement is under a misapprehension and probably confused printer discovery with printer sharing. This might have been because he has been exposed to CUPS browsing for too long and has some difficulty in adjusting to the new DNS-SD world. A diff is attached. It expands a little on printer sharing (but not unnecessarily, I hope). I should really make sure you can get commit access, thanks for the update! :-) Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717273: printer-driver-postscript-hp: HP LaserJet 1200: User can choose between two identical PS drivers
Le jeudi, 18 juillet 2013 19.21:28, Stefan Nagy a écrit : when I install printer-driver-postscript-hp I get two new drivers for my printer model HP LaserJet 1200 in CUPS (I use the web-based administration interface) to choose from: HP LaserJet 1200 Postscript (recommended) (en) HP LaserJet 1200 Postscript (recommended) (en) These two drivers don't just sound identical, as far as I can tell they are (I compared the PPD files). When I uninstall printer-driver-postscript-hp both entries are gone. I think this is https://github.com/vitorbaptista/pyppd/issues/1 What do you think? OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714852: libcups2: Jessie needs a revised README.Debian?
Control: tags -1 +pending Le mercredi, 3 juillet 2013 14.53:02, Brian Potkin a écrit : The present README.Debian has worn well over the years but perhaps now is the time to consider whether tinkering round its edges fits all the changes which have taken place over 10+ years. I've opted for more or less a rewrite, attempting to keep the essence of the original but altering and adding sections to reflect what is in 1.6.x. Any errors, inaccuracies and imprecisions are mine. I've attached a new README for consideration and also the notes made in its preparation. Awesome, thanks! I'll include your rewrite in the next upload. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#716843: Workaround
Control: tags -1 +pending +patch
Hi Michael and Mark,
Le lundi, 15 juillet 2013 16.00:47, Mark J. Small a écrit :
Okay, so I've found a workaround for my printing problem.
If enter the following:
lpadmin -p MY_PRINTER_NAME -o usb-no-reattach-default=true
and restart the printer, then printing seems to work properly.
Great, thanks for trying this.
So I guess the Lexmark E238 needs to be added to the printer quirks
list in usb-libusb.c. I'm guessing that many other similar lexmark
printers will need to be added (E230, E232, E234, E240n, are all
similar vintages), but I don't have those ones to test.
Here is my lsusb output:
ID 043d:00d7 Lexmark International, Inc.
I will include the patch for this printer only as I'd rather not break
not-broken printers:
+ { 0x043d, 0x00d7, USBLP_QUIRK_NO_REATTACH }, /* Lexmark International,
+Inc. (E238), http://bugs.debian.org/716843 */
Michael: the full usb-libusb.c patch on top of CUPS 1.6.2 is attached,
please include it in 1.6.3.
Would it be possible to add this to the quirk list and backport the
full quirk list to the next update of Wheezy? This is a rather
frustrating regression.
I'll consider that, sure, but this will depend on the stable release
team (and on my ability to allocate time for this update).
Cheers,
OdyX
Description: USB backend quirk rule for Epson Stylus Photo 750 (and maybe others)
Author: Didier Raboud o...@debian.org
Bugs-Debian: http://bugs.debian.org/697970
Bugs-Debian: http://bugs.debian.org/716843
Last-Update: 2013-03-16
--- a/backend/usb-libusb.c
+++ b/backend/usb-libusb.c
@@ -142,8 +142,14 @@
{ 0x0409, 0xbef4, USBLP_QUIRK_BIDIR }, /* NEC Picty760 (HP OEM) */
{ 0x0409, 0xf0be, USBLP_QUIRK_BIDIR }, /* NEC Picty920 (HP OEM) */
{ 0x0409, 0xf1be, USBLP_QUIRK_BIDIR }, /* NEC Picty800 (HP OEM) */
+ { 0x043d, 0x00d7, USBLP_QUIRK_NO_REATTACH }, /* Lexmark International,
+ Inc. (E238), http://bugs.debian.org/716843 */
+ { 0x043d, 0x00f3, USBLP_QUIRK_NO_REATTACH }, /* Lexmark International,
+ Inc. (e250d), https://bugs.launchpad.net/bugs/1084164 */
{ 0x0482, 0x0010, USBLP_QUIRK_BIDIR }, /* Kyocera Mita FS 820,
by zut ker...@zut.de */
+ { 0x04a9, 0x1095, USBLP_QUIRK_BIDIR }, /* Canon, Inc. PIXMA iP6000D
+ Printer, https://bugs.launchpad.net/bugs/1160638 */
{ 0x04a9, 0x10a2, USBLP_QUIRK_BIDIR }, /* Canon, Inc. PIXMA iP4200
Printer, http://www.cups.org/str.php?L4155 */
{ 0x04a9, 0x10b6, USBLP_QUIRK_BIDIR }, /* Canon, Inc. PIXMA iP4300
@@ -158,6 +164,8 @@
Printer, http://www.cups.org/str.php?L4155 */
{ 0x04a9, 0x173e, USBLP_QUIRK_BIDIR }, /* Canon, Inc. MP560
Printer, http://www.cups.org/str.php?L4155 */
+ { 0x04a9, 0x26a3, USBLP_QUIRK_NO_REATTACH }, /* Canon, Inc. MF4150
+ Printer, https://bugs.launchpad.net/bugs/1160638 */
{ 0x04f9, 0x001a, USBLP_QUIRK_NO_REATTACH }, /* Brother Industries, Ltd
HL-1430 Laser Printer,
https://bugs.launchpad.net/bugs/1038695 */
@@ -165,24 +173,33 @@
USBLP_QUIRK_NO_REATTACH }, /* Brother Industries, Ltd
HL-1440 Laser Printer,
https://bugs.launchpad.net/bugs/1000253 */
+ { 0x04f9, 0x000e, USBLP_QUIRK_BIDIR |
+ USBLP_QUIRK_NO_REATTACH }, /* Brother Industries, Ltd
+ HL-1450 Laser Printer,
+ https://bugs.launchpad.net/bugs/1000253 */
{ 0x06bc, 0x000b, USBLP_QUIRK_NO_REATTACH }, /* Oki Data Corp.
Okipage 14ex Printer,
https://bugs.launchpad.net/bugs/872483 */
{ 0x06bc, 0x01c7, USBLP_QUIRK_NO_REATTACH }, /* Oki Data Corp. B410d,
https://bugs.launchpad.net/bugs/872483 */
- { 0x04b8, 0x0001, USBLP_QUIRK_BIDIR }, /* Seiko Epson Corp. Stylus Color 740 / Photo 750,
+ { 0x04b8, 0x0001, USBLP_QUIRK_BIDIR |
+ USBLP_QUIRK_NO_REATTACH }, /* Seiko Epson Corp. Stylus Color 740 / Photo 750,
http://bugs.debian.org/697970 */
+ { 0x04b8, 0x0005, USBLP_QUIRK_NO_REATTACH }, /* Seiko Epson Corp. Stylus Color 670,
+ https://bugs.launchpad.net/bugs/872483 */
{ 0x04b8, 0x0202, USBLP_QUIRK_BAD_CLASS }, /* Seiko Epson Receipt
Printer M129C */
{ 0x067b, 0x2305, USBLP_QUIRK_BIDIR |
USBLP_QUIRK_NO_REATTACH |
USBLP_QUIRK_RESET },
+ /* Prolific Technology, Inc. PL2305 Parallel Port
+ (USB - Parallel adapter), https://bugs.launchpad.net/bugs/987485 */
{ 0x0924, 0x3ce9, USBLP_QUIRK_NO_REATTACH }, /* Xerox Phaser 3124
https://bugzilla.redhat.com/show_bug.cgi?id=867392 */
{ 0x0924, 0x4293, USBLP_QUIRK_NO_REATTACH }, /* Xerox WorkCentre 3210
https://bugs.launchpad.net/bugs/1102470 */
- /* Prolific Technology, Inc. PL2305 Parallel Port
- (USB - Parallel adapter), https://bugs.launchpad.net/bugs/987485 */
+ { 0x1a86, 0x7584, USBLP_QUIRK_NO_REATTACH }, /* QinHeng Electronics
+ CH340S (USB - Parallel adapter), https://bugs.launchpad.net/bugs/1000253 */
{ 0x04e8, 0x, USBLP_QUIRK_RESET }, /* All Samsung devices,
Bug#714634: [lsb-discuss] Clarification of general LSB requirements
Le jeudi, 11 juillet 2013 02.27:52, Russ Allbery a écrit : Steve Langasek vor...@debian.org writes: If lsb-core is going to pull in default-mta as the preferred option, then arguably lsb-invalid-mta shouldn't exist at all (or at least, there's no reason to label it an 'lsb' package). I think the purpose of the package is to let lsb-core be installed without automatically pulling in an MTA that has to be configured, and default-mta | mail-transport-agent | lsb-invalid-mta wouldn't achieve that. But I think dropping the Provides: from lsb-invalid-mta would. Ah, I see. Hm. I do think that the behavior a user most likely expects, when installing lsb-core, is to pull in a functional MTA. In other words, I think it's fine to provide a way for a sysadmin to select to not configure an MTA, but I do think that installing lsb-core should result in configuring an MTA by default. I am of the opposite opinion: if an administrator decided to uninstall the default-mta as installed by Debian, then the installation of lsb- core should respect that choice and not impose the configuration of an MTA, especially because lsb-* is meant as a compliance layer, not a functional layer (in my understanding). As argued before in this bug, LSB only formally requires the presence of a compliant sendmail command, not that this one does anything useful. I think I quite like Steve's line: make lsb-invalid-mta stop providing mail-transport-agent. In all but unusual Debian installations (in which the administrator decided to remove all MTAs), the installation of lsb- core will result in the re-use of the installed MTA. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714634: [lsb-discuss] Clarification of general LSB requirements
Le mercredi, 10 juillet 2013 20.20:21, Steve Langasek a écrit : On Wed, Jul 10, 2013 at 02:10:22AM -0700, Russ Allbery wrote: (It's probably also worth noting that Debian does not claim LSB compliance and the description of that Debian package states, rather prominently: The intent of this package is to provide a best current practice way of installing and running LSB packages on Debian GNU/Linux. Its presence does not imply that Debian fully complies with the Linux Standard Base, and should not be construed as a statement that Debian is LSB-compliant. So, really, it's kind of hard to see what's notably egregious about this.) Well, I think that package description is silly in its lawyeresque weaselness. The raison d'être of the package is to provide an LSB-compliant layer, which is what it means to support installing and running LSB packages. I don't see any reason the package description should have this long disclaimer about the possibility of bugs in the implementation. The core of what this phrasing [0] conveys is this package doesn't imply that Debian is LSB-compliant but is our best-effort at it; I would welcome any patch in that direction, if possible acked by Jeff/LSB. Cheers, OdyX [0] Which apparently has been that was at least since 2002 for the LSB 1.1.0-11 package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715448: cups-filters: pdftopdf segfaults
Control: reassign -1 libqpdf10 4.1.0-2 Le mercredi, 10 juillet 2013 08.09:46, Johannes Stezenbach a écrit : On Wed, Jul 10, 2013 at 12:08:11AM +0100, Brian Potkin wrote: On Tue 09 Jul 2013 at 20:43:09 +0100, Brian Potkin wrote: snapshot.debian.org has the previous versions of libqpdf10 and qpdf. So I installed them (i386). Printing now takes place. Whether the bug lies with one of those packages or not, I do not know. I suppose pdftopdf could still be at fault if it does not use them correctly. Ah, the packages you built and which worked for you were (I suppose) built using libqpdf10 version 4.2.0-1, which entered unstable on 8th July. The present cups-filters was built with version 4.1.0-2. I can confirm that downgrading libqpdf10 to 4.1.0-2 (from testing) fixes the issue (on another machine at home which still has the unchanged cups-filter package). Thanks for investigating; that makes this bug a regression in libqpdf10 then, hereby re-assigning. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715448: cups-filters: pdftopdf segfaults
Le mercredi, 10 juillet 2013 10.03:23, Till Kamppeter a écrit : Could perhaps a no-change rebuild of cups-filters help? That might be, but if that's the case, that's of the responsibility of the libqpdf maintainer; if the ABI changed, it's a transition and binNMUs should have been requested. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715448: cups-filters: pdftopdf segfaults
Control: affects -1 cups-filters Le mercredi, 10 juillet 2013 16.57:52, Jay Berkenbilt a écrit : Well, it does look like it must be an ABI change, though I can't yet figure out how as I'm looking very carefully at the bad commit and don't see anything that should constitute an ABI change. However, I can reproduce it now using only qpdf by doing a trivial operation, linking with the old library and then running with the new one. If I can't figure it out fast, I'll bump the soname and do a new release. I will also add a stronger check for ABI changes as part of my release checklist since I apparently don't have as complete a picture in my mind as I thought I did about what constitutes an ABI change. Making the Debian build use the .symbols file would be of great help to track these symbols changes, at least. Ask if you need help for setting these, I have struggled with several of those in the past. Cheers OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714634: lsb-core: Remove lsb-invalid-mta as a dependency of lsb-core; require an actual MTA instead
Hi both, Le samedi, 6 juillet 2013 20.58:15, Jeff Licquia a écrit : hat type=lsb-spec-author The LSB is, first and foremost, about compatibility for apps. If apps expect something to be there, and for it to act in a certain way, then that's our top priority. Everything else is secondary. (…) To the extent that lsb-invalid-mta preserves app compatibility, therefore, it's OK by us; not ideal, or even recommended, but a valid option. (…) /hat Thanks Jeff for confirming that lsb-invalid-mta is a LSB-valid sendmail implementation. That confirms the initial evaluation I had done when merging lsb-invalid-mta in the first place. Le samedi, 6 juillet 2013 20.58:15, Jeff Licquia a écrit : hat type=debian-developer Since we install an MTA by default, I expect that there are very few installations of lsb-invalid-mta (perhaps none). Popcon [0] reports 251 installations (0.17%). [0] http://qa.debian.org/popcon-graph.php?packages=lsb-invalid-mta Le samedi, 6 juillet 2013 20.58:15, Jeff Licquia a écrit : I will say that I enthusiastically support this part of the change, and would advocate that it happen: That's probably where I'd be open to changes: making lsb-core depend on default-mta | mail-transport-agent on Debian (and still lsb-invalid- mta | mail-transport-agent on Ubuntu) might be a worthwhile change. Le samedi, 6 juillet 2013 14.39:03, Aaron Sowry a écrit : Agreed. But let's focus on Debian and let downstream deal with their own problems. Please let me focus on where I see fit; I have put quite some effort in joining forces between Debian and Ubuntu for several packages and think it's a worthwhile effort, mind you. For this change though, it's probably useful to make it unconditional and see how Ubuntu imports it. Anyway, as Jeff is uploader on src:lsb, and my mind is not completely settled on this issue, I'm happy to let you implement these changes; I won't push them, but won't stand in their way either. Le samedi, 6 juillet 2013 20.58:15, Jeff Licquia a écrit : I'd even support this as a bug-fix for wheezy, not just in jessie. I would be _very_ surprised if the stable release team accepted such a change in Wheezy, but I guess you don't risk much by asking. That said, we released Wheezy with both lsb-invalid-mta and the dependency on it from lsb-core so we would need to respect the choice of admins that actually _want_ a non-working sendmail in their lsb dependencies across upgrades. This isn't really an administrator's problem, it's a problem for developers of applications designed to be run on LSB-compliant systems. I can't think of any reason an administrator would ever want a non-functional sendmail command on their system. I believe this ship has sailed for wheezy, certainly. But for jessie, I tend to agree with Aaron. Too much stuff on a Debian system assumes a working MTA to make lsb-invalid-mta an interesting choice for Debian users. So dropping it wouldn't necessarily be bad for our users. Frankly, I think there are good reasons to use a non-functional sendmail; and installing lsb-invalid-mta is easier than configuring exim or postfix to always error out. That said, I'm not dogmatic about it. If we want to make the choice available, cool. Just as long as the choice isn't the default (i.e. Depends: default-mta | mail-transport-agent). As mentionned above, I'm not dogmatic about lsb-invalid-mta either. I think it does serve a purpose (it's not installed on my machines fwiw) but won't fight for it, or against it's removal. So Jeff, if you want to fix this bug, stand bold for these changes and just do it! :-) Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714634: lsb-core: Remove lsb-invalid-mta as a dependency of lsb-core; require an actual MTA instead
Hi, Le lundi, 8 juillet 2013 09.38:21, Aaron Sowry a écrit : BTW, if you feel strongly about this, I'd encourage you to file the appropriate bugs and have this discussion over there. No one here needs convincing, I think, that lsb-invalid-mta is a bad idea. I do feel strongly about this, as the outcome of this discussion will determine whether or not the LSB is something we can refer to when designing applications which need to work across distributions. I obviously can't argue that lsb-invalid-mta *is* in violation of the LSB, but I would like to argue that it *should* be. Please note that the default-mta as shipped by Debian (exim4) in its default configuration is not sending mails to the internet at all. If your LSB-based assumption is that you can invoke sendmail to send mails to anyone, then it is not fulfilled by default-mta either. So, taking a step back, sendmail, as currently shipped by default-mta, only ensures that mails are sent to local users. In that context, I see many uses for a sendmail erroring out instead of an working sendmail piling mails in local mboxes never read by anyone. (But I wrote I wouldn't stand in the way, hereby shutting up. :-p ) Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714634: lsb-core: Remove lsb-invalid-mta as a dependency of lsb-core; require an actual MTA instead
Control: tags -1 +moreinfo Hi Aaron, and thanks for your bugreport, Le lundi, 1 juillet 2013 14.54:35, Aaron Sowry a écrit : This bug report is a continuation of the following thread: http://debian.2.n7.nabble.com/Questions-regarding-lsb-invalid-mta-td2 980123.html To summarize, lsb-invalid-mta does not fulfil the requirements of the LSB specification, and as such should not be installed as a dependency of lsb-core. I think the summary is not the above statement, but that your _opinion_ is that lsb-invalid-mta does not fulfil the requirements of the LSB specification. I don't agree, fwiw. Can you point to a specific LSB requirement not fulfilled by lsb-invalid-mta, please? * [15.1] wants the sendmail command, it's there. * [15.2-sendmail] describes the sendmail command, all options of which are supported by lsb-invalid-mta's sendmail. A valid point would be that the sendmail command setup by lsb-invalid-mta is not working properly (as it always errors out). I would tag such a bug as +wontfix as the purpose of lsb-invalid-mta is well explained by its name. [15.1] http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB- Core-generic/command.html#CMDUTIL [15.2] http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB- Core-generic/baselib-sendmail-1.html Rather, an actual MTA should be installed, That's not what the LSB requires; It requires a valid sendmail command. and the lsb-invalid-mta package preferably removed from the Debian repositories altogether (as I understand this was a downstream initiative, and does not appear to be appropriate in Debain). I don't see the existance of lsb-invalid-mta as a problem, why should it be removed? I think it _is_ useful for some users of the lsb-* packages and therefore don't understand why we should take it off them. example, lsb-core could instead depend on default-mta | mail-transport-agent. That's probably where I'd be open to changes: making lsb-core depend on default-mta | mail-transport-agent on Debian (and still lsb-invalid- mta | mail-transport-agent on Ubuntu) might be a worthwhile change. That said, we released Wheezy with both lsb-invalid-mta and the dependency on it from lsb-core so we would need to respect the choice of admins that actually _want_ a non-working sendmail in their lsb dependencies across upgrades. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714492: cups: Please allow cups to be build against libgnutls28-dev.
Control: tags -1 +moreinfo Hi Nicolas, and thanks for your bugreport, Le dimanche, 30 juin 2013 00.07:21, Nicolas Le Cam a écrit : Please find attached a patch that allows cups to be build against libgnutls28-dev. I have choosed to use the virtual package gnutls-dev to let libcups2-dev be coinstallable with both of them. You have attached a patch, for the how?, but why? isn't answered as far as I'm concerned; so why would that be useful? Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712559: Logrotate do not restart cups
Control: reassign -1 logrotate 3.8.5-1 Paul; this bug is apparently caused by logrotate 3.8.5-1, please see the #712559 buglog for details. Le jeudi, 27 juin 2013 15.47:41, Klaus Ethgen a écrit : Hi, Am Do den 20. Jun 2013 um 17:16 schrieb Didier 'OdyX' Raboud: Le jeudi, 20 juin 2013 12.35:44, Klaus Ethgen a écrit : ~ dpkg -l logrotate ii logrotate 3.8.3-5 amd64 Log rotation utility And they seems to change the pre- and post- stuff in version 3.8.3-4. Maybe that was a wrong change. Can you try with logrotate from Jessie then? I'm leaning towards thinking it's not a bug in cups; no evidence in that direction has been demonstrated so far. I did downgrade to logrotate version 3.8.3-3 and the bug is gone. So please feel free to reassign the bug to logrotate. Hereby doing so; thanks for your investigation. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711697: libcupsfilters1 has circular Depends on libcupsimage2
Hi, Le vendredi, 21 juin 2013 13.40:16, Bill Allombert a écrit : No, but you can do it by adding an extra package: Rename the current libcupsimage2 to e.g. libcupsimage2s then add a dummy package libcupsimage2 that depend on libcupsimage2s and libcupsfilters1. and change the shlibdeps accordingly, and rebuild libcupsfilters1 so that it now depends on libcupsimage2s. I'm really not convinced that is worth the effort. What about having libcupsimage2 stop depending on libcupsfilters1 and Breaks: printer-driver-c2esp ( 26) ? OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712559: Logrotate do not restart cups
Hi again Klaus, Le jeudi, 20 juin 2013 11.10:39, Klaus Ethgen a écrit : Seen it. I can confirm, that that two bugs are closed now. But this bug (712559) still exists after upgrading to the current version in sid. ~ lsof -n G cups This command spits an error here; what is the exact command that you are running to test for this bug ? Also, note that the logrotate script is now /etc/logrotate.d/cups-daemon and that it properly stops the daemon, rotates the logs, and starts the daemon. I don't really see what is failing on your side. Did you maybe change the cups and/or logrotate configuration? In what way? And what breaks again? Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712872: cups: [RFE] Modifying authentication data for a job in the queue
Control: tags -1 +upstream Hi Sam, and thanks for your bugreport, I'm hereby CC'ing Michael Sweet, Cups upstream author. Le jeudi, 20 juin 2013 13.59:37, Sam Morris a écrit : Some programs (such as Libreoffice) do not provide a way to specify a username and password when printing to a printer that has AuthInfoRequired username,password in its printers.conf entry. A job created by such a program will sit in the queue until an administrator removes it. I'd like a way for the administrator to specify authentication values for such a job that has been created without them. Something like: # lpmodify -o username=foo,password 7 Enter value for 'password': *** Here the given value was used for username, and since no password was specified it was prompted so that it is not visible in the process's command line arguments, nor is it recorded in the user's shell history. So you are asking for a feature to modify cups jobs to add missing credentials to them so that they can succeed on restricted printers, right? Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712559: Logrotate do not restart cups
Hi again, Le jeudi, 20 juin 2013 12.35:44, Klaus Ethgen a écrit : ~ dpkg -l logrotate ii logrotate 3.8.3-5 amd64 Log rotation utility And they seems to change the pre- and post- stuff in version 3.8.3-4. Maybe that was a wrong change. Can you try with logrotate from Jessie then? I'm leaning towards thinking it's not a bug in cups; no evidence in that direction has been demonstrated so far. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712719: cups: CUPS printing broken in Wheezy (Unable to get printer status)
Control: tags -1 +moreinfo Le mardi, 18 juin 2013 21.05:56, Adrian a écrit : Package: cups Version: 1.5.3-5 Severity: grave Justification: renders package unusable (…) * What led up to the situation? Squeeze-Wheezy upgrade. Done on 2 machines - both have the same problem now * What exactly did you do (or not do) that was effective (or ineffective)? Recreated printer, reinstalled CUPS, connected locally (instead over ipp) * What was the outcome of this action? Nope. Get-Printer-Attributes returned server-error-internal-error Unable to get printer status. Please follow the procedure outlined in https://wiki.ubuntu.com/DebuggingPrintingProblems [0] and attach the /var/log/cups/error_log file to the bugreport. Please also detail your exact setup with more details: what file did you try to print, on which cups server (local, distant), towards which printer (manufacturer, model), connected how (USB, Parallel, network, …), using which driver? Thanks in advance. OdyX [0] That we should really adapt to Debian and push to the Debian wiki, but that's another story. signature.asc Description: This is a digitally signed message part.
Bug#711697: libcupsfilters1 has circular Depends on libcupsimage2
Le dimanche, 9 juin 2013 15.08:12, Bill Allombert a écrit : On Sun, Jun 09, 2013 at 02:19:51PM +0200, Didier 'OdyX' Raboud wrote: Control: tags -1 +moreinfo Hi Bill, and thanks for your bugreport, Le samedi, 8 juin 2013 21.31:32, Bill Allombert a écrit : There is a circular dependency between libcupsfilters1 and libcupsimage2: libcupsfilters1 :Depends: libcupsimage2 (= 1.4.0) libcupsimage2 :Depends: libcupsfilters1 (= 1.0~b1) Indeed. Good catch, thanks. Circular dependencies involving shared libraries are known to cause problems during upgrade between stable releases, so we should try to get rid of them. The problem here is that the ABI provided by libcupsimage2 has been split at version 1.6 between libcupsimage2 and libcupsfilters1, hence the depends of libcupsimage2 on libcupsfilters1. But libcupsfilters1 already exist in wheezy, so this more a transfer than a split ? A split would be more easily dealt with. Indeed, it's a transfer of symbols without SOVERSION bump. I don't particularily like it, but it's there… This could probably be downgraded to a Recommends, but brings in the risk that package A, depending on libcupsimage2 1.5 stops to work if libcupsimage2 is upgraded to 1.6 and libcupsfilters1 is not installed (aka partial upgrade). I'd like to be convinced the dependency is actually sufficient to fix partial upgrade, especially since dpkg will have to break the circular dependency anyway. Fair enough, but the dependencies ensure that dpkg is only happy with the two libraries installed at the same time, so the window of brokenness opportunity is quite small. It might be necessary to introduce an extra package. What package do you have in mind? Is there packages in wheezy that use the libcupsimage2 symbols that are now in libcupsfilters1 but do not depend on libcupsfilters1 ? As for the symbols I don't know (but could probably given more work), but these reverse dependencies (from other source packages) are in place in Wheezy: libcupsimage2-dev ← libgs-dev libcupsimage2 ← cups-filters, depends on libcupsfilters1 libcupsimage2 ← libcupsfilters1 (shlibs dependency, can't be removed) libcupsimage2 ← ghostscript-cups, doesn't depend on libcupsfilters1 libcupsimage2 ← libescpr1 (dropped in Jessie) libcupsimage2 ← libgs9, doesn't depend on libcupsfilters1 libcupsimage2 ← lsb-printing, doesn't depend on libcupsfilters1 [0] libcupsimage2 ← printer-driver-c2esp, doesn't depend on libcupsfilters1 libcupsimage2 ← printer-driver-escpr, doesn't depend on libcupsfilters1 libcupsimage2 ← printer-driver-gutenprint, doesn't depend on libcupsfilters1 libcupsimage2 ← printer-driver-hpcups, doesn't depend on libcupsfilters1 libcupsimage2 ← printer-driver-ptouch, doesn't depend on libcupsfilters1 libcupsimage2 ← printer-driver-splix, doesn't depend on libcupsfilters1 So only cups-filters seems fine, for good reasons. How can I check which symbols are used by each package without rebuilding with a special set of packages? Cheers, OdyX [0] LSB only mandates these symbols, all in libcupsimage2: http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Printing/LSB- Printing/libcupsimage.html signature.asc Description: This is a digitally signed message part.
Bug#711697: libcupsfilters1 has circular Depends on libcupsimage2
Le mardi, 18 juin 2013 10.17:15, Didier 'OdyX' Raboud a écrit : Is there packages in wheezy that use the libcupsimage2 symbols that are now in libcupsfilters1 but do not depend on libcupsfilters1 ? Grepping the output of 'nm -D' in a wheezy chroot showed that the following packages in Wheezy use symbols that move to libcupsfilters1 in unstable (cups- filters does use most of them, not listed here): printer-driver-c2esp: /usr/lib/cups/filter/c2esp 'cupsDitherDelete' 'cupsDitherLine' 'cupsDitherNew' 'cupsLutDelete' 'cupsLutNew' So printer-driver-c2esp uses some symbols from libcupsfilters1, but only depends on libcupsimage2 in Wheezy. I does depend on libcupsfilters1 in both Jessie and Sid. What do you think? Is there a way to untangle this circular depends by adding a breaks somewhere? Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#693658: bugs.debian.org: unable to print some pdf files freshly downloaded old pdf ok
Hi Frank, Please provide the complementary informations asked below: Le mercredi, 21 novembre 2012 08.02:01, Don Armstrong a écrit : You seem to be reporting a bug in cups, but I'm not quite sure. You'll have to provide quite a bit more information before anyone can help you, though. 1) What pdf are you printing? 2) What are you using to print it? 3) Does it display properly? Can you try with a recent cups too (up-to-date Wheezy would be nice)? Thanks in advance, cheers, OdyX -- OdyX signature.asc Description: This is a digitally signed message part.
Bug#520786: Localicing error
Le mardi, 18 juin 2013 14.10:38, Klaus Ethgen a écrit : Am Di den 18. Jun 2013 um 12:56 schrieb Didier 'OdyX' Raboud: I don't intend to patch cups to support non-UTF8 locales, hereby closing this bug. Well, it is common sense to use iconv to produce output for every locale. Non-UTF-8 systems are not that uncommon. Common-sense is still not the same as just review and apply the patch that someone provided in the bugreport. Apparently it's not that easy common- sense: noone produced a patch for this issue yet. So, no, UTF-8 is no solution for all problems. And just the fact that it works doesn't mean that it works good. Sure. But it works. I am yet to see a bug _in_cups_, that was due to UTF-8. But I cannot force you to solve the bug. But I think, it would be sad if you ignore the fact that there are other encodings around. You're putting words in my mouth: I don't ignore that there are other encodings around, and didn't write that at all, please re-read my quote above. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706888: cups: Could not print to server after upgrade: Failed to add Avahi entry
Hi, First, please don't mail me directly, but always the bug, so that others can also assist you. For now I have bounced your query to the bug, don't worry. Le dimanche, 16 juin 2013 21.46:53, NetCat a écrit : Thanks for your light-speed response. I have Intel Core 2 Duo Quad, which packages should I install from http://alioth.debian.org/~odyx-guest/debian/wheezy/ and in which order? It doesn't depend on your CPU, but on the architecture of your Debian installation, which you can see by running the following command: dpkg --print-architecture If that outputs amd64, then you can install the above packages with the following commands: cd $(mktemp -d) wget -r -l1 -nH --cut-dirs=3 -A *1.5.3-5+706888~attempt0_*.deb http://alioth.debian.org/~odyx-guest/debian/wheezy/ Then, as root: dpkg -i *1.5.3-5+706888~attempt0_*.deb apt-get install -f Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712559: Logrotate do not restart cups
Control: tags -1 +moreinfo Hi Klaus, Le lundi, 17 juin 2013 09.43:39, vous avez écrit : Package: cups Version: 1.5.0-16 Severity: normal You run an ancient version of cups, and a curious mix of cups dependencies (cups-filters from unstable, not all cups dependencies installed, etc). Since some days cups fails to restart when the log gets rotated. So the daemon is logging to deleted files. (…) I did some tests with the postrotate section and found out that if I redirect the output of 'invoke-rc.d --quiet cups force-reload' to mail everything worked well. If I don't, it will not run properly. That different behaviour makes it difficult to debug. What output do you get in said mail? However, as you can see, I did not update for a long time now due to bug 638521 (that was closed without getting noticed by me) and 660852 that really stops me from using newer versions. These two bugs are fixed in Wheezy; please test cups 1.5.3-5 from Wheezy, including its dependencies; I wouldn't be surprised if some things would be fixed for you, including this. In any case, I will not fix bugs for versions not in the Debian suites, so please really make sure to reproduce your bug with a cups version as shipped in a Debian suite. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712559: Logrotate do not restart cups
Le lundi, 17 juin 2013 12.03:25, Klaus Ethgen a écrit : However, as you can see, I did not update for a long time now due to bug 638521 (that was closed without getting noticed by me) and 660852 that really stops me from using newer versions. These two bugs are fixed in Wheezy; Oh, The bug 660852 is still open in bugtracker. I just closed it after further investigation: it is fixed in 1.5.3 by upstream. OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706888: cups: Could not print to server after upgrade: Failed to add Avahi entry
Hi all, Le dimanche, 16 juin 2013 15.21:15, Julian Gilbey a écrit : I have hit the same problem, as cups has just migrated to testing. My error log (/var/log/cups/error_log) says: cups 1.6 didn't migrate to testing yet. E [16/Jun/2013:14:18:49 +0100] Failed to add Avahi entry for Samsung ML-1610 @ erdos: -8 E [16/Jun/2013:14:18:49 +0100] Failed to add Avahi entry for Samsung ML-1610 @ erdos: -8 Oh dear :-( I have avahi-daemon installed and running: erdos:~ # /etc/init.d/avahi-daemon status Avahi mDNS/DNS-SD Daemon is running Do you both have cups-browsed installed and running ? TIA, cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712237: cups-server-common: The cost factor for pstops
Le vendredi, 14 juin 2013 19.17:36, Didier 'OdyX' Raboud a écrit : So apparently the IPP interface only answers 72 bytes without some of the mandatory attributes with this patch enabled. The full HTML log is attached if one of you wants to take a look. I don't have an immediate clue right now but I suspect that pstops might be at fault somewhere, but I can't say where. FYI, I just tried with filter/pstops.c from 1.5.3 and it doesn't help. OdyX signature.asc Description: This is a digitally signed message part.
Bug#708212: Please upload latest SVN snapshot
Control: clone -1 -2 Control: reassign -2 sponsorship-requests Control: retitle -2 RFS: splix/2.0.0+svn308-1 Control: owner -2 o...@debian.org Control: affects -2 src:splix Control: block -1 by -2 Hi Luca, thanks for your answer to this bugreport. I'm hereby cloning this bug to a Request for Sponsorship on the sponsorship- requests pseudo-package, to track the comments on your package there. Le mardi, 4 juin 2013 01.18:21, Luca Niccoli a écrit : Here's the link to the dsc: http://mentors.debian.net/debian/pool/main/s/splix/splix_2.0.0+svn308-1.dsc Le dimanche, 2 juin 2013 13.03:04, Luca Niccoli a écrit : I've uploaded to mentors a new version of splix. The changes are: - move to the lates svn snapshot Ack, great. One comment though: the Ubuntu package [0] closed one Launchpad (LP:) bug in that changelog entry (LP: #898986). It's good practice to include these when possible as that makes Ubuntu's job easier too at synchronisation time (and costs the Debian package nothing more than some bits in the changelog). - copy fixed splix.ppd-updater from Ubuntu Ack, great. - add conditional apport hook for Ubuntu and derivatives This doesn't work as the derives_from_ubuntu Make variable hasn't been defined. You need to add it's definition in debian/rules (on one line of course): derives_from_ubuntu := $(shell (dpkg-vendor --derives-from Ubuntu echo yes) || echo no) - add get-orig-source target Good. - used dpkg-buildflags to import hardening flags I see that you applied these using a Debian-specific quilt patch. Although I would initially have written that these flags are modifiable without a quilt patch, apparently the LDFLAGS variables can't inheritate from debian/rules. That said, it would be good to: a) set V=1 to get a verbose build (that allows one to verify that the flags are correctly set); b) define the flags from dpkg at make execution time instead of executing dpkg-buildflags at every CC invocation, with: $(shell dpkg-buildflags --get CXXFLAGS) - bumped Standards-Version Just to make that clear: did you check the upgrading-checklist from the debian-policy package while doing so? I'd be glad if you could review the upload and give me some comments. See above. Didier, I'd be glad to move splix packaging under team maintenance, possibly under git. Cool. These are two different things though: - putting the packaging under team maintenance means setting Debian Printing Team debian-print...@lists.debian.org as Maintainer and yourself in the list of Uploaders. This implies that your package might get enhancements of fixes from other members of the printing team. Such changes are not supposed to happen without coordination with the main Uploaders though, don't worry. - moving the packaging in git. I invite you to read [PackagingWithGit] on the wiki, if possible using the pristine-tar option. Get started and ask if you have questions! For the initial git'ification, I suggest that you use the git- import-dscs tool to fetch all past releases from Debian Snapshots. [PackagingWithGit] http://wiki.debian.org/PackagingWithGit Maybe we can talk about it in private mail or on a list, so we do not fill this bug with unrelated stuff? Please answer to the cloned bug (once we know it's number). There's no (and almost never) reason to handle things in private when it's possible to handle them in public: the comments on your package can be helpful to others. P.S. mentors seems a bit slow in accepting my upload, but I'm hopeful that it will appear in the next few hours. That's apparently solved, great. Cheers, OdyX [0] https://launchpad.net/ubuntu/+source/splix/2.0.0+svn308-0ubuntu1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634325: cups-polld does not properly handle network errors, uses 100%
Control: tags -1 +moreinfo Le lundi, 15 octobre 2012 18.20:13, Samuel Wolf a écrit : Still have this problem with Debian Wheezy. /etc/cups/cupsd.conf [...] # Show shared printers on the local network. Browsing On BrowsePoll printserver.local [...] comment out BrowsePoll fix it, but should it not resolved in this version? Hi Samuel, Wheezy has now been released as stable, can confirm (or preferably, infirm) that you still encounter this bug? Thanks in advance, cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645436: cups: Useless error message in http-support.c
Control: severity -1 wishlist Hi ael, I can confirm this patch would still apply in cups 1.6.2. Le samedi, 15 octobre 2011 23.32:13, ael a écrit : I am trying to locate a bug in cups which currently looks like a broken pipe. After attempts to write to a socket, an http status of HTTP_ERROR is returned which does not have a case in the relevant switch statement in cups/http-support.c. As a result, the unhelpful default message Unknown is passed back to the user who is none the wiser. The attached patch improves the default message, and adds an extra branch for HTTP_ERROR. There should perhaps be further cases for other values in http.h which are not covered explicitly. Michael: this patch [0] could be of interest to you. Cheers, Didier [0] http://bugs.debian.org/cgi- bin/bugreport.cgi?msg=5;filename=http_errormsg.patch;att=1;bug=645436 signature.asc Description: This is a digitally signed message part.
Bug#703424: Regression: CUPS Web interface fails to authenticate Kerberos access to IPP information
Control: tags -1 +moreinfo Hi Timothy, and thanks for your bugreport, Le mardi, 19 mars 2013 14.32:33, Timothy Pearson a écrit : When using the Web interface to CUPS in a Kerberized environment, CUPS fails to pass Kerberos authentication information to the local IPP socket. This manifests as access being denied to any pages which access printer information, even though the user logged in via Kerberos has been granted access to both the pages and printers in question. The CUPS error log shows that it has rejected unauthenticated access to the printers in question, even though the prior access to the Web printer list page was successfully authenticated. This appears to be a regression introduced when resolving Bug 640939, specifically this patch removes the ability for CUPS to pass Kerberos login credentials to the local IPP socket: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=105;filename=cups-1.5.3-2. 14-nmu.diff;att=1;bug=640939 Can you confirm that this still applies to CUPS 1.6.2 (as uploaded to unstable)? Thanks in advance, cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711848: cups-client: lp and lpr print the document on a wrong printer
Control: severity -1 important Control: tags -1 +moreinfo +unreproducible Hi Vincent, and thanks for your bugreport, Le lundi, 10 juin 2013 11.25:57, Vincent Lefevre a écrit : I have the following options in .cups/lpoptions: Dest lip-multi-3 ColorModel=Gray Resolution=1200dpi Default lipucb-mono-1 I did lpoptions -d new-default-printer and got that Default line in .cups/lpoptions too. The lpq command gives as expected: lipucb-mono-1 is ready no entries Same here. But when I print a document with lpr file.pdf, I get nothing on this printer. Then I tried: lp file.pdf, and I get nothing either on this printer, but the following line was output in the terminal: When trying here with either lpr or lp, I get the file printed on the correct new-default-printer (which is obviously not the same printer as the system's default printer) as defined above, so I can't reproduce your problem here. What are the access rights and contents of /etc/cups/lpoptions and .cups/lpoptions ? CUPS 1.5.x didn't have such a problem. This is a big security problem when one wants to print documents with confidential information... Granted, that's a bug, but it doesn't fit my reading of serious [0], it's at most important, hereby downgrading. Cheers, OdyX [0] http://www.debian.org/Bugs/Developer.en.html#severities -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711848: cups-client: lp and lpr print the document on a wrong printer
Hi again Vincent, Le lundi, 10 juin 2013 12.56:33, Vincent Lefevre a écrit : Well, this may be server dependent. I suspect a bug related to the authentication mechanism. When I do lpq, authentication is not required, so that its output is OK. However some printers need authentication (the user's password). Perhaps lp and lpr ignore the default printer when it requires authentication, or something like that? The printer to which the files had been sent doesn't require a password. Note that the -P lpr option works as expected (and the password must be typed). Thanks for the followup. What are the access rights and contents of /etc/cups/lpoptions and .cups/lpoptions ? ypig:~ cat /etc/cups/lpoptions cat: /etc/cups/lpoptions: No such file or directory ypig:~ cat .cups/lpoptions Dest lip-multi-3 ColorModel=Gray Resolution=1200dpi Default lipucb-mono-1 Can you provide the access rights of .cups/lpoptions? $ ls -l ~/.cups/lpoptions CUPS 1.5.x didn't have such a problem. This is a big security problem when one wants to print documents with confidential information... Granted, that's a bug, but it doesn't fit my reading of serious [0], it's at most important, hereby downgrading. I disagree. I see [0] as giving a non-exhaustive list of grave/critical problems. For instance, a bug that would make a mail server an open relay by default should also be seen as a grave/critical bug, even though such a problem isn't listed in [0]. It should include problems like private data disclosure. It's fine for you to disagree, but the list [0] is considered as authoritative on bugs severities. If you think this list should be changed, please start a discussion on a proper forum; probably a bug on debian-policy as it's 1.1 chapter defines what bug corresponds to a serious severity, which is completed by the Release Team's RC policy [1]. Under the current rules, this bug doesn't fit the defintion of serious in my reading. (Please also take a look at the Developers' Reference, §5.8.3, alinea 3 [2]). Cheers, OdyX [0] http://www.debian.org/Bugs/Developer.en.html#severities [1] http://release.debian.org/jessie/rc_policy.txt [2] http://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug- housekeeping -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698284: usb-modeswitch-data: ttyUSB* rule should have SYMLINK+= not SYMLINK=
Hi Josua,
I have now uploaded your latest usb-modeswitch-data source package to Debian
and stumbled upon this bug while housekeeping the remnant bugs lying around.
:)
Apparently you forgot to include this change in the new rules file (also in
the gen_rules.tcl) apparently; was that intentional?
Keep us posted, cheers,
OdyX
Le mercredi, 16 janvier 2013 20.39:30, Josua Dietze a écrit :
Am 16.01.2013 10:57, schrieb Didier 'OdyX' Raboud:
Le mercredi, 16 janvier 2013 09.53:26, John Hedges a écrit :
Symlinks created by local rules for ttyUSB devices are lost because of
the following rule in /lib/udev/rules.d/40-usb_modeswitch.rules
KERNEL==ttyUSB*, ATTRS{bNumConfigurations}==*,
PROGRAM=usb_modeswitch --symlink-name %p %s{idVendor} %s{idProduct}
%E{PRODUCT}, SYMLINK=%c
Chould it be changed to SYMLINK+=%c ?
As I don't have a definite opinion on that, let's see what upstream
thinks.
Josh: what's your opinion ?
Yes, this definitely should be changed. There is no disadvantage.
I will do so in the next release, but that is not scheduled yet - so you
might want to correct this prior to my update.
OdyX
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711848: cups-client: lp and lpr print the document on a wrong printer
Hi again, Le lundi, 10 juin 2013 13.27:47, Didier 'OdyX' Raboud a écrit : Under the current rules, this bug doesn't fit the defintion of serious in my reading. As you brought this bug to debian-devel@ [0], let me explain in little more details (which I thought were obvious) why I think this bug is neither a security or a serious problem: * it doesn't happen for everyone (it works as expected here); * not all printed documents carry sensitive information and failing to print to the correct printer is not a security problem in all cases. I never wrote that I wouldn't try to get this bug (which I agree it is) fixed, but just corrected the inflated bug severity. That useless debate on severities just distracted me from working on the bug itself. OdyX [0] http://lists.debian.org/%3c20130610111552.ga17...@ypig.lip.ens-lyon.fr%3E -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711848: cups-client: lp and lpr print the document on a wrong printer
Hi Michael, Could you eventually take a look at http://bugs.debian.org/711848 ? It's apparently a bug introduced with the enumerated destinations API in CUPS 1.6; it would be great if you could chime in. Vincent's analysis is below. Cheers, Didier Raboud, Debian CUPS co-maintainer P.S. If you'd prefer other means of contacts regarding the CUPS bugs, feel free to point me towards them. Le lundi, 10 juin 2013 16.07:46, Vincent Lefevre a écrit : If I understand correctly, there may be actually 2 problems: 1. _cupsGetDests(http, op, name, dest, 0, 0) failed while it shouldn't. 2. In case of failure due to specified[*] but inexistent printer, another printer is tried. This is a *wrong* behavior. The correct behavior is to report an error in such a case. Otherwise, for instance, if a document is sent to a private printer but something goes wrong like here, it may end up on a public printer! [*] by either a lpoptions config file or an environment variable. The -P lpr option is handled directly in lpr, and cupsGetNamedDest is not involved if this option is used; that's why everything is fine with it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711868: Regression: icc profiles not registered in colord
Control: tags -1 +pending +confirmed Hi Alexey, and thanks for your bugreport, Le lundi, 10 juin 2013 16.37:42, Alexey Galakhov a écrit : A new version of cups daemon (1.6.2) does not register printer icc profiles in colord anymore. Instead, the following error message appears: org.freedesktop.DBus.Error.UnknownMethod:No such interface `org.freedesktop.ColorManager' on object at path /org/freedesktop/ColorManager/devices/cups_printername Indeed, I see the same error messages in my error_log. This was caused by misspelled name in dbus access: org.freedesktop.ColorManager instead of org.freedesktop.ColorManager.Device. The attached patch fixes it. Many thanks for hunting this bug and providing a patch, that's very appreciated. I have now committed it and it will be part of the next upload: http://anonscm.debian.org/gitweb/?p=pkg- cups/cups.git;a=commitdiff;h=53aac566b84c8454c2528ba6cdee3a88c12b948d Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#711849: cups-browsed depends on avahi-daemon, unnecessarily
Control: tags -1 +wontfix Hi Stephan, and thanks for your bugreport, Le lundi, 10 juin 2013 12.25:31, Stephan Boettcher a écrit : cups-browsed works nicely without avahi when instructed to BrowsePoll a specific server. The avahi-daemon is pulled in unnecessaily and needs to be disabled in our setup. Although I agree it is inconvenient to have that dependency when you don't _need_ to use it, cups-browsed is currently built by default with --with- browseremoteprotocols=dnssd, which means that the cups protocol is not enabled by default [0]. In setups with only CUPS = 1.6 client and servers, dnssd is the protocol of choice and cups is only available for retro- compatibility with older CUPS 1.6 instances; it will eventually get dropped in a future release. By having dnssd in the default BrowseRemoteProtocols entry, starting cups- browsed doesn't work if avahi-daemon is not already launched (and hence, installed), as is expressed through the initscript LSB headers. So while I agree that having avahi-daemon as a dependency is unfortunate, I don't really see another way to have cups-browsed work straight after (minimal) installation. I'm therefore hereby tagging this bugreport as 'wontfix'. Cheers, OdyX [0] Although the postinst tries to enable it on upgrades from cups 1.6. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698141: cups-browsed: Package description does not explain where to install the package
Control: tags -1 +patch +pending Hi Axel, and thanks for your bugreport, Le lundi, 14 janvier 2013 12.31:37, Axel Beckert a écrit : I guess that many people are happy about the existence of this package, so am I. :-) Glad you like it. To be honest, we'd be in a better situation if it wasn't needed, but ohwell. But from the long description it is unclear to me and my coworkers at which point in the common CUPS 1.6 vs CUPS 1.6 scenarios this package can or should be installed: 1) On the CUPS = 1.6 server so that CUPS 1.6 clients can browse his printer list? Yes, by using the old 'cups' protocol in BrowseLocalProtocols. 2) On the CUPS = 1.6 client so that it can browse the printer list of CUPS 1.6 printer servers? Yes, by using the old 'cups' protocol in BrowseRemoteProtocols. 3) On the CUPS 1.6 server so that CUPS = 1.6 clients can browse his printer list? No. The configuration has to happen on the CUPS = 1.6 client, see 2) above. 4) On the CUPS 1.6 client so that it can browse the printer list of CUPS = 1.6 printer servers? As I understand it, no, see 1) above. Or even a completely different setup like some proxy machine which queries the = 1.6 server and broadcasts its printers to 1.6 clients? No no, not that I know. The cups-browsed daemon works by managing raw queues on the cups instance that it has access to locally depending on network events. So please update the long descrption of that package accordingly to make clear where the package should be installed and where not. The next upload will have something along these lines: . cups-browsed is also useful with a CUPS = 1.6 client to allow the latter to browse the printer list of CUPS 1.6 servers (by using the old 'cups' protocol in BrowseRemoteProtocols). . cups-browsed is also useful with a CUPS = 1.6 server to allow CUPS 1.6 clients to browse its printer list (by using the old 'cups' protocol in BrowseLocalProtocols). Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#711697: libcupsfilters1 has circular Depends on libcupsimage2
Control: tags -1 +moreinfo Hi Bill, and thanks for your bugreport, Le samedi, 8 juin 2013 21.31:32, Bill Allombert a écrit : There is a circular dependency between libcupsfilters1 and libcupsimage2: libcupsfilters1 :Depends: libcupsimage2 (= 1.4.0) libcupsimage2 :Depends: libcupsfilters1 (= 1.0~b1) Indeed. Good catch, thanks. Circular dependencies involving shared libraries are known to cause problems during upgrade between stable releases, so we should try to get rid of them. The problem here is that the ABI provided by libcupsimage2 has been split at version 1.6 between libcupsimage2 and libcupsfilters1, hence the depends of libcupsimage2 on libcupsfilters1. This could probably be downgraded to a Recommends, but brings in the risk that package A, depending on libcupsimage2 1.5 stops to work if libcupsimage2 is upgraded to 1.6 and libcupsfilters1 is not installed (aka partial upgrade). Dropping symbols without bumping the SOVERSION (although they have been re- implemented in libcupsfilters1) is a very unfortunate move by upstream but none that we can reasonably fix. The other side of the circular-dependency coin is libcupsfilters1 depending on libcupsimage2, but that's brought in by shlibdeps. So unless there's a good way to ensure partial upgrades keep working, I think that this circular dependency, as unfortunate as it might seem, is probably necessary. (Hence tagging moreinfo to see whether I can be convinced otherwise, might turn that into wontfix later.) Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#711709: cups-client: Unclear description in ipptoolfile(5)
Hi Helge, and thanks for your bugreport, Le samedi, 8 juin 2013 21.53:40, Helge Kreutzmann a écrit : While translating I had trouble understanding if attribute names in ipptoolfile(5) are free form (i.e. like variable names) or are to be taken from a fixed set. E.g. at the beginning, in ATTR charset attributes-charset utf-8 Is »attributes-charset« a variable (could be foobar) or a fixed name. I assumed the former, while other German translators pointed me to the latter. I agree that the manpage is not overly clear. That said, I have just found that the IPP variable, values, etc, are all defined in [RFC2911]. This particular Request Operation Attribute, attributes-charset is defined in section-3.1.4.1 of that RFC document, so it's definitely both a variable (because there are other possible values) and a fixed name (because it's not fully free-form, the list of possible values being RFC2911). Does that make it clearer? How would you like this bug to be fixed in the cups source package? Cheers, OdyX [RFC2911] http://tools.ietf.org/html/rfc2911 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711709: cups-client: Unclear description in ipptoolfile(5)
Control: tags -1 +pending +patch Le dimanche, 9 juin 2013 19.04:21, Helge Kreutzmann a écrit : The following pseudo patch should do the trick: ATTR tag attribute-name value(s) - Adds an attribute to the test request. Values are separated by the comma (,) character - escape commas using the + Adds an attribute to the test request. Values are separated by the comma (,) character - escape commas using the . Possible attribute-name are defined in RFC2911. SEE ALSO ipptool(1), http://localhost:631/help + RFC2911 http://tools.ietf.org/html/rfc2911 I have pushed that now, it will be part of the next upload: http://anonscm.debian.org/gitweb/?p=pkg-cups/cups.git;a=commitdiff;h=5959bb8885c9d96943ca3af8e42824868215208e Thanks! OdyX signature.asc Description: This is a digitally signed message part.
Bug#706598: tpu: win32-loader/0.7.4.7
Le jeudi, 6 juin 2013 23.21:52, Adam D. Barratt a écrit : On Mon, 2013-06-03 at 21:41 +0200, Didier 'OdyX' Raboud wrote: win32-loader (0.7.4.7+deb7u1) stable; urgency=low * Post-Wheezy release rebuild to update the embedded dependencies. Please go ahead; thanks. Uploaded, thanks. OdyX signature.asc Description: This is a digitally signed message part.
Bug#704238: Need to document the CUPS client's new server-version option
forcemerge 704238 711192 severity 704238 important tags 704238 +patch -moreinfo thanks Hi Daniel, and thanks for your bugreport, Vincent: I'm hereby merging both 704238 and 711192 as the latter is and occurence of the first. Also, thanks for testing the four possibilities, it confirms Daniel's documentation below. CC'ing Michael as cups's STR bug tracker is not online yet. Le samedi, 30 mars 2013 07.17:23, Daniel Richard G. a écrit : The CUPS client recently gained new configuration logic to allow the IPP version of a CUPS server to be specified, whether on the command line (-h option), in the CUPS_SERVER environment variable, or in the /etc/cups/client.conf config file. Some examples of the syntax: $ lpr -h cups.example.com/version=1.1 foo.ps $ CUPS_SERVER=cups.example.com/version=1.1 lpr foo.ps ServerName cups.example.com/version=1.1 Indeed. That's confirmed to address Vincent's issue. Although it's kinda surprising that it's impossible to detect that at runtime, but that's an upstream decision… This information should be of interest to anyone using CUPS in a client- only configuration, because the IPP version default changed for the new 1.6.x series and thus client-only users upgrading from 1.5.x may find that they mysteriously can't print anymore. (Indeed, this happened to me, and the problem was *not* easy to diagnose.) I can't disagree. ;) The new server-version option needs to be documented in the cups-client package's example client.conf file. Mention of it should probably be added to README.Debian. Furthermore, because of the potential for breakage when upgrading from 1.5.x, I believe a notice in a package maintainer script would be warranted (perhaps limited to systems that do not have the cups server package installed). Maintainer script prompt for a remote server incompatibility is probably overkill (and we usually try very hard to avoid these prompts), but I propose the attached patch which mentions this /version= possibility in two places upstream: man client.conf and doc/help/ref-client-conf.html. On the Debian packaging side, I propose to add a cups-client NEWS entry (which one is _really_ supposed to read across upgrades), and amend the client.conf example file shipped in the source as debian/client.conf (which I'm not sure is installed or used anywhere, but that at least makes the source consistent). Opinions ? Cheers, OdyX Description: Mention the possibility to add /version=1.1 to the ServerName configuration in various places: - man client.conf - doc/help/ref-client-conf.html Bug-Debian: http://bugs.debian.org/704238 Bug-Debian: http://bugs.debian.org/711192 Author: Didier Raboud o...@debian.org Last-Update: 2013-06-06 --- a/man/client.conf.man.in +++ b/man/client.conf.man.in @@ -40,12 +40,12 @@ (n...@server.example.com) for you. The default name is @CUPS_DEFAULT_GSSSERVICENAME@. .TP 5 -ServerName hostname-or-ip-address[:port] +ServerName hostname-or-ip-address[:port][/version=1.1] .TP 5 ServerName /domain/socket .br Specifies the address and optionally the port to use when connecting to the -server. \fBNote: Not supported on OS X 10.7 or later.\fR +server. The IPP version (2.0 by default, can be 1.1 or 1.0) can be specified to access older servers. \fBNote: Not supported on OS X 10.7 or later.\fR .TP 5 User name .br --- a/doc/help/ref-client-conf.html +++ b/doc/help/ref-client-conf.html @@ -56,6 +56,7 @@ ServerName foo.bar.com ServerName 11.22.33.44 ServerName foo.bar.com:8631 +ServerName foo.bar.com/version=1.1 /PRE H3Description/H3 @@ -64,6 +65,8 @@ PThe default port number is 631 but can be overridden by adding a colon followed by the desired port number to the value./P +PThe default IPP version is 2.0 but can be overriden by adding a slash followed by CODE/version=/CODE and the desired IPP version (can be 1.0 or 1.1)./P + PThe default is to use the local server (VARlocalhost/VAR) or domain socket, if so configured./P BLOCKQUOTEBNote:/B From 536b50b891942b300ed1247fab9789a6504e8085 Mon Sep 17 00:00:00 2001 From: Didier Raboud o...@debian.org Date: Thu, 6 Jun 2013 08:10:48 +0200 Subject: [PATCH] Add a cups-client.NEWS notice, a cups-client manpage patch and amend the client.conf example file to inform about IPP default version change to 2.0 and circumvention measures. Closes: #704238 Closes: #711192 Thanks: Daniel Richard G. Thanks: Vincent Lefevre --- debian/client.conf | 6 ++- debian/cups-client.NEWS| 11 ++ ...tion-ipp-version-specifier-in-man-and-ref.patch | 45 ++ debian/patches/series | 2 + 4 files changed, 62 insertions(+), 2 deletions(-) create mode 100644 debian/cups-client.NEWS create mode 100644 debian/patches/mention-ipp-version-specifier-in-man-and-ref.patch diff --git a/debian/client.conf b/debian/client.conf index 754c71a..5081ade 100644 ---
Bug#704238: Bug#711192: Bug#704238: Need to document the CUPS client's new server-version option
Control: tags -1 +pending Hi all, I have pushed the proposed patch with Brian and Vincent's fixes, thank you! It'll be part of the next upload. Commit: http://anonscm.debian.org/gitweb/?p=pkg- cups/cups.git;a=commit;h=123306535e3fade1a0f26699b72dde18437a4d6e Upstream patch: http://anonscm.debian.org/gitweb/?p=pkg- cups/cups.git;a=blob;f=debian/patches/mention-ipp-version-specifier-in-man-and- ref.patch;h=47f465699030da04cd716501963c78ed321cb05b;hb=123306535e3fade1a0f26699b72dde18437a4d6e Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#711327: cups-client: the -h option has no effect
Hi Vincent, Le jeudi, 6 juin 2013 17.22:24, Vincent Lefevre a écrit : On 2013-06-06 15:30:13 +0100, Brian Potkin wrote: 3. The -h option takes precedance over a user/system client.conf file and the CUPS_SERVER environment variable. Using an alternative server we would execute lpstat -h hostname[:port] -a -v This doesn't work either. For instance, lpstat -h localhost -a gives me the remote printers (only). What do the following commands give? $ lpstat -H $ lpstat -h localhost -H $ lpstat -h localhost:631 -H And if the order of options matters (which is rather unusual), this should be documented. Indeed, but we can't realistically correct all (quite minor) upstream documentation issues; and unfortunately, the upstream bugtracker is down these days. Patches are welcome of course. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711192: cups-client: clients (lpstat, lpq...) no longer work via http
Hi Vincent, and thanks for your bugreport, Le mercredi, 5 juin 2013 12.29:24, Vincent Lefevre a écrit : The CUPS clients no longer work via http: ypig:~ lpq -P lipucb-mono-1 lpq: Unknown destination lipucb-mono-1. ypig:~ lpstat -a lpstat: Bad Request I don't know what information is needed. Unfortunately I don't have access to the server's logs (I can ask them if need be). But this bug may look like one I got two years ago on the same network: Do you have cups-browsed and avahi-daemon installed ? Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711211: pu: package lsb/4.1+Debian8+deb7u1
Le mercredi, 5 juin 2013 16.09:43, Didier Raboud a écrit :
The proposed changelog is the following:
lsb (4.1+Debian8+deb7u1) stable; urgency=low
* Fix lsb_release to correctly work with stable release updates
incrementing the second digit from Wheezy on. (Closes: #711174)
* Add jessie to the release codenames lookup table
-- Didier Raboud o...@debian.org Wed, 05 Jun 2013 12:38:11 +0200
The full debdiff is attached. I'm sorry for it being a little noisy
because of the changes needed in the test-suite.
Of course, I forgot to attach the debdiff… Meh.
OdyX
diff -Nru lsb-4.1+Debian8/debian/changelog lsb-4.1+Debian8+deb7u1/debian/changelog
--- lsb-4.1+Debian8/debian/changelog 2012-11-05 12:08:22.0 +0100
+++ lsb-4.1+Debian8+deb7u1/debian/changelog 2013-06-05 12:39:20.0 +0200
@@ -1,3 +1,11 @@
+lsb (4.1+Debian8+deb7u1) stable; urgency=low
+
+ * Fix lsb_release to correctly work with stable release updates
+incrementing the second digit from Wheezy on. (Closes: #711174)
+ * Add jessie to the release codenames lookup table
+
+ -- Didier Raboud o...@debian.org Wed, 05 Jun 2013 12:38:11 +0200
+
lsb (4.1+Debian8) unstable; urgency=low
* Fix libqt3-mt missing epoch.
diff -Nru lsb-4.1+Debian8/lsb_release.py lsb-4.1+Debian8+deb7u1/lsb_release.py
--- lsb-4.1+Debian8/lsb_release.py 2012-11-02 10:49:48.0 +0100
+++ lsb-4.1+Debian8+deb7u1/lsb_release.py 2013-06-05 12:38:05.0 +0200
@@ -41,7 +41,8 @@
'4.0' : 'etch',
'5.0' : 'lenny',
'6.0' : 'squeeze',
-'7.0' : 'wheezy',
+'7' : 'wheezy',
+'8' : 'jessie',
}
TESTING_CODENAME = 'unknown.new.testing'
@@ -56,7 +57,10 @@
if not m:
return unknown
-shortrelease = '%s.%s' % m.group(1,2)
+if int(m.group(1)) 7:
+shortrelease = '%s.%s' % m.group(1,2)
+else:
+shortrelease = '%s' % m.group(1)
return RELEASE_CODENAME_LOOKUP.get(shortrelease, unknown)
# LSB compliance packages... may grow eventually
diff -Nru lsb-4.1+Debian8/test/test_lsb_release.py lsb-4.1+Debian8+deb7u1/test/test_lsb_release.py
--- lsb-4.1+Debian8/test/test_lsb_release.py 2012-11-02 10:49:48.0 +0100
+++ lsb-4.1+Debian8+deb7u1/test/test_lsb_release.py 2013-06-05 12:38:05.0 +0200
@@ -40,6 +40,9 @@
cdn = lr.RELEASE_CODENAME_LOOKUP[rno]
# Test that 1.1, 1.1r0 and 1.1.8 lead to buzz. Default is picked randomly and is not supposed to go trough
badDefault = rnd_string(0,9)
+ # From Wheezy on, the codename is defined by the first number but a dot-revision is mandatory
+ if float(rno) = 7:
+rno = rno + '.' + str(random.randint(0,9))
self.assertEqual(lr.lookup_codename(rno,badDefault),cdn,'Release name `' + rno + '` is not recognized.')
self.assertEqual(lr.lookup_codename(rno + 'r' + str(random.randint(0,9)),badDefault),cdn,'Release name `' + rno + 'r*` is not recognized.')
self.assertEqual(lr.lookup_codename(rno + '.' + str(random.randint(0,9)),badDefault),cdn,'Release name `' + rno + '.*` is not recognized.')
@@ -220,7 +223,11 @@
# Test stable releases with numeric debian_versions
for rno in lr.RELEASE_CODENAME_LOOKUP:
- distinfo['RELEASE'] = rno + random.choice('.r') + str(random.randint(0,9))
+ # From Wheezy on, the codename is defined by the first number but a dot-revision is mandatory
+ if float(rno) = 7:
+distinfo['RELEASE'] = rno + '.' + str(random.randint(0,9))
+ else:
+distinfo['RELEASE'] = rno + random.choice('.r') + str(random.randint(0,9))
distinfo['CODENAME'] = lr.RELEASE_CODENAME_LOOKUP[rno]
distinfo['DESCRIPTION'] = '%(ID)s %(OS)s %(RELEASE)s (%(CODENAME)s)' % distinfo
fn = 'test/debian_version_' + rnd_string(5,5)
Bug#711192: cups-client: clients (lpstat, lpq...) no longer work via http
Control: tags -1 +moreinfo Hi Vincent, Le mercredi, 5 juin 2013 15.44:50, Vincent Lefevre a écrit : BTW, if I understand correctly, cups-browsed isn't necessary since in my case, the server name is fixed in /etc/cups/client.conf and the connection is done to this server as expected. The problem is at the protocol level, possibly related to the encryption. What is the content of /etc/cups/client.conf and does it work if you replace the hostname by its IP? Also what version of CUPS is the server running? Note that according to the changelog, The default IPP version for requests is now 2.0 (STR #3929), so you need a recent-enough cups server. You can also try to add '?version=1.0' to the device URI to use legacy compatibility mode. Looking forward to your findings, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711136: cups: clean up of old files
Hi Christoph, and thanks for your bugreport,
Le mercredi, 5 juin 2013 01.25:50, Christoph Anton Mitterer a écrit :
On upgrade from 1.5, several old config files seem to not be properly
removed, including:
1) /etc/cups/pdftops.conf and /etc/cups/acroread.conf
You mention in the changelog that these were dropped.
btw: The changelog misses the leading / for each of them.
That's really weird; cups.maintscripts has the following lines:
rm_conffile /etc/cups/acroread.conf 1.4.4-2~
rm_conffile /etc/cups/pdftops.conf 1.4.4-2~
That lead to these in the maintainer scripts:
dpkg-maintscript-helper rm_conffile /etc/cups/acroread.conf 1.4.4-2~ -- $@
dpkg-maintscript-helper rm_conffile /etc/cups/pdftops.conf 1.4.4-2~ -- $@
I could bump that version to 1.6.2-9~ to make sure they are cleaned in the
Jessie upgrade, according to dpkg-maintscript-helper manpage:
If the conffile has not been shipped for several versions, and you are now
modifying the maintainer scripts to clean up the obsolete file, prior-
version should be based on the version of the package that you are now
preparing, not the first version of the package that lacked the conffile.
Le mercredi, 5 juin 2013 01.25:50, Christoph Anton Mitterer a écrit :
2) dpkg: warning: unable to delete old directory '/etc/cups/ssl': Directory
not empty Contains:
lrwxrwxrwx 1 root root 36 Nov 14 2009 server.crt -
/etc/ssl/certs/ssl-cert-snakeoil.pem lrwxrwxrwx 1 root root 38 Nov 14
2009 server.key - /etc/ssl/private/ssl-cert-snakeoil.key Which was likely
added by cups... at least not by me ;)
That's kinda-expected, the directory (and it's contents) is now shipped by
cups-daemon instead, I think the warning is harmless (and actually a sign of
an intended action across upgrades).
dpkg: warning: unable to delete old directory '/var/spool/cups/tmp':
Directory not empty dpkg: warning: unable to delete old directory
'/var/spool/cups': Directory not empty dpkg: warning: unable to delete old
directory '/var/cache/cups': Directory not empty I'd guess these can be rm
-rf'ed when cups was stopped before?
Same situation here, these files changed owner from cups to cups-daemon. And
rm -rf'ing under the feet of cups{,-daemon} is a bad idea I think.
Opinions ?
Cheers,
OdyX
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711211: pu: package lsb/4.1+Debian8+deb7u1
Le mercredi, 5 juin 2013 20.58:25, Adam D. Barratt a écrit : Control: tags -1 + wheezy confirmed On Wed, 2013-06-05 at 18:08 +0200, Didier 'OdyX' Raboud wrote: Le mercredi, 5 juin 2013 16.09:43, Didier Raboud a écrit : The proposed changelog is the following: lsb (4.1+Debian8+deb7u1) stable; urgency=low * Fix lsb_release to correctly work with stable release updates incrementing the second digit from Wheezy on. (Closes: #711174) * Add jessie to the release codenames lookup table [...] Of course, I forgot to attach the debdiff… Meh. Please go ahead; thanks. Uploaded, thanks! Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#711192: cups-client: clients (lpstat, lpq...) no longer work via http
Le mercredi, 5 juin 2013 20.35:09, Vincent Lefevre a écrit : Note that according to the changelog, The default IPP version for requests is now 2.0 (STR #3929), so you need a recent-enough cups server. You can also try to add '?version=1.0' to the device URI to use legacy compatibility mode. How can I do this? It doesn't appear to be wildly documented; can you try the following versions? ServerName lip-printserver1.lip.ens-lyon.fr/version=1.1 ServerName lip-printserver1.lip.ens-lyon.fr/version=1.1 ServerName lip-printserver1.lip.ens-lyon.fr?version=1.0 ServerName lip-printserver1.lip.ens-lyon.fr?version=1.0 Which one, if any, does work ? Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#710514: tools/win32-loader stable package not updated for Wheezy
Hi Ansgar,
Le lundi, 3 juin 2013 20.59:55, Ansgar Burchardt a écrit :
I move tools/win32-loader/stable to oldstable and copied the contents of
unstable to stable and testing.
Great thanks.
Le lundi, 3 juin 2013 20.59:55, Ansgar Burchardt a écrit :
Didier Raboud o...@debian.org writes:
it seems that the debian/tools/win32-loader/{testing,stable}/ copy has
been forgotten during the Wheezy release week-end.
Sorry to nitpick, but is there some sort of release checklist on which this
action point could be put to make sure it happens at release time for Jessie?
Thanks in advance, cheers,
OdyX
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706598: tpu: win32-loader/0.7.4.7
Control: retitle -1 pu: win32-loader/0.7.4.7+deb7u1 Hi Julien, Le jeudi, 2 mai 2013 17.38:03, Didier 'OdyX' Raboud a écrit : Le jeudi, 2 mai 2013 15.08:05, Julien Cristau a écrit : I think come back for r1. Fair enough. An upload to unstable would be good to have anyway, no? People could then test it with pre-release-almost-wheezy material before the stream of updates to unstable starts to flow. I have now uploaded 0.7.4.8 to unstable and would like to get win32-loader 0.7.4.7+deb7u1 with the following changelog (no other change to source) as follows: win32-loader (0.7.4.7+deb7u1) stable; urgency=low * Post-Wheezy release rebuild to update the embedded dependencies. -- Didier Raboud o...@debian.org Mon, 03 Jun 2013 21:31:52 +0200 Can I go ahead with the upload? Thanks in advance, cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710514: tools/win32-loader stable package not updated for Wheezy
Le lundi, 3 juin 2013 21.41:01, Adam D. Barratt a écrit : On Mon, 2013-06-03 at 21:27 +0200, Didier 'OdyX' Raboud wrote: Sorry to nitpick, but is there some sort of release checklist on which this action point could be put to make sure it happens at release time for Jessie? I've added it to https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList (which assumes whoever releases Jessie follows the list and spots the item, but it's the best we've got). Super, thanks! OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710571: Patch for /lib/lsb/init-functions
Control: severity -1 minor Control: merge 683654 -1 Control: tag 683654 +wontfix -moreinfo Hi Josh, hi Teodor, Le samedi, 1 juin 2013 09.41:00, Teodor MICU a écrit : This topic was discussed with LSB maintainers on #683654. Maybe these two bugs should be merged, but I don't know if the discussion will be preserved. Indeed, hereby merging. Le samedi, 1 juin 2013 02.28:24, vous avez écrit : The attached git patch makes the log_* functions in /lib/lsb/init-functions check $VERBOSE before outputting anything. As I wrote in #683654: I think that the fact that a call to log_*_msg always leads to having a message printed is actually a feature and a characteristic of these shell functions. Changing this interface to start printing messages conditionally is a quite intrusive change IMHO. I have now also re-read the #683654 bugreport and got more convinced that changing these logging functions is a really bad idea. The biggest blocker that I see is the output that one gets when managing services by hand: if one setups VERBOSE=no in /etc/default/rcS, then any service action (such as # service cups restart) will log exactly no output to the console, while now you get a useful message. So I currently stand to my initial appreciation of this bug (hence untagging moreinfo and tagging wontfix): it is in my (current) opinion of the daemon's initscripts responsibility to define what messages should be logged and which not, so the VERBOSE environment variable should be handled by these and not globally by init-functions. As for boot splashs (or whatever software is annoyed by init scripts' outputs), they have multiple solutions readily available: I/O multiplexing [0] (by doing filtering, or even discarding of the outputs of the initscripts), diversion of the lsb init functions by dropping a file in /lib/lsb/init-functions.d/, etc. Cheers, OdyX [0] http://web.dodds.net/~vorlon/wiki/blog/Plymouth_is_not_a_bootsplash/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710356: [nagios3-core] No scheduled downtime retention
Control: tags -1 +patch +upstream
Hi Cédric, hi Nagios maintainers,
Le jeudi, 30 mai 2013 09.29:54, Cédric Jeanneret a écrit :
I just installed the latest nagios3* on a debian Wheezy, and stumbled
on a bad bug: the scheduled downtime event aren't kept when a restart or
reload occurs.
(…)
After some researches, I stumbled on this nagios resolved bug:
http://tracker.nagios.org/view.php?id=338
It seems there's a patch available since October 2012 on the SVN:
Fixed in svn with the supplied patch and will ship with the first
version after 3.4.1 - it may be good to have a look at 3.4.2 (or
something like that), as a major feature is currently broken.
The dpatch'ed backport of the (git-)svn commit from upstream is attached.
I have built nagios3-core targetted at stable with the above patch (debdiff
attached), the built files are available there:
http://alioth.debian.org/~odyx-guest/debian/wheezy/
Cédric; it would be useful if you could test these.
Cheers,
OdyX
999_daemon-downtime-Handle-loading-effective-downtime-fr.dpatch
Description: application/shellscript
diff -u nagios3-3.4.1/debian/changelog nagios3-3.4.1/debian/changelog
--- nagios3-3.4.1/debian/changelog
+++ nagios3-3.4.1/debian/changelog
@@ -1,3 +1,11 @@
+nagios3 (3.4.1-3+deb7u1~710356) stable; urgency=low
+
+ * Non-maintainer upload.
+ * Backport upstream r1953 to fix downtime retention across restarts
+(Closes: #710356)
+
+ -- Didier Raboud o...@debian.org Thu, 30 May 2013 10:22:45 +0200
+
nagios3 (3.4.1-3) unstable; urgency=low
* Fix several overflows in getcgi.cgi and history.cgi
diff -u nagios3-3.4.1/debian/patches/00list nagios3-3.4.1/debian/patches/00list
--- nagios3-3.4.1/debian/patches/00list
+++ nagios3-3.4.1/debian/patches/00list
@@ -11,0 +12 @@
+999_daemon-downtime-Handle-loading-effective-downtime-fr.dpatch
only in patch2:
unchanged:
--- nagios3-3.4.1.orig/debian/patches/999_daemon-downtime-Handle-loading-effective-downtime-fr.dpatch
+++ nagios3-3.4.1/debian/patches/999_daemon-downtime-Handle-loading-effective-downtime-fr.dpatch
@@ -0,0 +1,86 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## daemon downtime: Handle loading effective downtime from retention
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: From 9f18395268dda948265722984097735d48d72197 Mon Sep 17 00:00:00 2001
+## DP: From: Andreas Ericsson a...@op5.se
+## DP: Date: Wed, 6 Jun 2012 09:38:06 +
+## DP: Subject: [PATCH] daemon downtime: Handle loading effective downtime from
+## DP: retention
+## DP:
+## DP: Without this patch, Nagios would forget about downtime that starts
+## DP: before the core is stopped and ends after the core is restarted.
+## DP:
+## DP: According to testers, the original problem with notifications being
+## DP: re-sent does not crop up again when this patch is applied.
+## DP:
+## DP: Tested-by: Mark Elsen mark.el...@gmail.com
+## DP: Tested-by: Phil Randal phil.ran...@hoopleltd.co.uk
+## DP: Patched-by: Carlos Velasco carlos.vela...@nimastelecom.com
+## DP: Signed-off-by: Andreas Ericsson a...@op5.se
+## DP:
+## DP: git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@1953 5f96b256-904b-4d8d-8c98-d829582c6739
+## DP: ---
+## DP: THANKS| 1 +
+## DP: common/downtime.c | 31 +++
+## DP: 2 files changed, 28 insertions(+), 4 deletions(-)
+
+@DPATCH@
+diff --git a/THANKS b/THANKS
+index d2f759a..b7c666e 100644
+--- a/THANKS
b/THANKS
+@@ -277,6 +277,7 @@ since 1999. If I missed your name, let me know.
+ * Nikola Vassilev
+ * Esteban Manchado Velazquez
+ * Geert Vanderkelen
++* Carlos Velasco
+ * Jan Vejvalka
+ * Robert August Vincent II
+ * Dave Viner
+diff --git a/common/downtime.c b/common/downtime.c
+index 09a0333..0193c50 100644
+--- a/common/downtime.c
b/common/downtime.c
+@@ -401,11 +401,34 @@ int handle_scheduled_downtime(scheduled_downtime *temp_downtime) {
+ }
+
+ /* if downtime handler gets triggerd in between then there seems to be a restart */
+- /* Don't do anything just return */
+- time( current_time);
+- if( temp_downtime-start_time current_time current_time temp_downtime-end_time temp_downtime-is_in_effect == TRUE)
+- return OK;
++ time(current_time);
++ if(temp_downtime-start_time current_time current_time temp_downtime-end_time temp_downtime-is_in_effect == TRUE) {
++#ifdef USE_EVENT_BROKER
++ /* send data to event broker */
++ broker_downtime_data(NEBTYPE_DOWNTIME_START, NEBFLAG_NONE, NEBATTR_NONE, temp_downtime-type, temp_downtime-host_name, temp_downtime-service_description, temp_downtime-entry_time, temp_downtime-author, temp_downtime-comment, temp_downtime-start_time, temp_downtime-end_time, temp_downtime-fixed, temp_downtime-triggered_by, temp_downtime-duration, temp_downtime-downtime_id, NULL);
++#endif
++
++ /* increment the downtime depth variable */
++ if(temp_downtime-type == HOST_DOWNTIME) {
++ hst-scheduled_downtime_depth++;
++
Bug#710079: [Fingerforce-devel] Bug#710079: libfprint0: Upek Biometric Touchchip/Touchstrip Fingerprint Sensor no longer work
Hi Nobuhiro, and thanks for your bugreport, Le mardi, 28 mai 2013 06.43:03, Nobuhiro IMAI a écrit : with libfprint0 (1:0.5.0-5), Upek Biometric Touchchip/Touchstrip Fingerprint Sensor no longer work. $ (…) Indeed, your log confirms that. Can you try to install libfprint 0.5.0-4 from Debian snapshots [0] ? [0] http://snapshot.debian.org/package/libfprint/1%3A0.5.0-4/ I have backported an upstream patch [1] to the -5 revision, which might conflict with your device, so confirming that it works with libfprint 0.5.0-4 would confirm that this patch is at fault. [1] http://patch- tracker.debian.org/patch/series/view/libfprint/1:0.5.0-5/u3b3679c-upeke2-Add- support-for-147e-2020-ID.patch. Thanks in advance, cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710079: [Fingerforce-devel] Bug#710079: libfprint0: Upek Biometric Touchchip/Touchstrip Fingerprint Sensor no longer work
Hi again, Le mardi, 28 mai 2013 08.51:45, Nobuhiro IMAI a écrit : From: Didier 'OdyX' Raboud odyx_at_debian.org Le mardi, 28 mai 2013 06.43:03, Nobuhiro IMAI a écrit : with libfprint0 (1:0.5.0-5), Upek Biometric Touchchip/Touchstrip Fingerprint Sensor no longer work. $ (…) Indeed, your log confirms that. Can you try to install libfprint 0.5.0-4 from Debian snapshots [0] ? I tried as follow: (…) Could not locate any suitable fingerprints matched with available hardware. [sudo] password for nov: uid=0(root) gid=0(root) groups=0(root) Hmm, it was the same result with 1:0.5.0-5. What happens if you try to reboot between your attempts ? Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709584: cups-filters: outdated embedded data copy: aglfn
Control: tags -1 +upstream Control: forwarded -1 https://bugs.linuxfoundation.org/show_bug.cgi?id=1135 Hi Paul, and thanks for your bugreport; good catch indeed! Le vendredi, 24 mai 2013 09.26:33, Paul Wise a écrit : The cups-filters source package contains an embedded data copy that is also outdated (aglfn13.c). This file is shipped in the cups-filters source package and compiled into libfontembed1 binary package. Please ask upstream to remove aglfn13.c from source package and instead build-depend on the aglfn binary package, convert the aglfn.txt shipped in the aglfn binary package into a C file at build time and possibly add a Built-Using field. I have now reported it on the upstream bugtracker, see forwarded header. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709078: libgs-dev / cups: please rebuild with libtiff5-dev
Le mardi, 21 mai 2013 10.35:51, Roland Stigge a écrit : Hi, a precondition for rebuilding ghostscript w/ libtiff5-dev is rebuilding cups w/ libtiff5-dev since libcupsimage2-dev also depends on it. Why is libtiff-dev not provided by libtiff5-dev ? cups build-depends on libtiff-dev and I'm surprised to have to change cups's source when we explicitely depend on the non-versionned -dev package. If there's a libtiff transition happening, the libtiff-dev should be provided by libtiff5-dev (and not by libtiff4-dev anymore) (and cups would be just binNMU'ed). What am I missing here? OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709078: libgs-dev / cups: please rebuild with libtiff5-dev
Le mardi, 21 mai 2013 11.22:46, Roland Stigge a écrit : You are not missing anything. :-) Since other packages are migrating to libtiff5-dev also, maybe it's time for libtiff-dev to be provided by the newer tiff? In that case, it might be time to start discussing the 4-5 libtiff transition with the release team. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696332: lsb-release: release/codename depend on a successful apt-get
Control: tags -1 +moreinfo Hi varacanero, and thanks for your bugreport, Le mercredi, 19 décembre 2012 18.20:27, varacanero a écrit : Subject: lsb-release: release/codename depend on a successful apt-get update Package: lsb-release Version: 4.1+Debian8 Severity: normal If an apt-get update fails (i.e. no internet connection), the lsb codename will change to n/a, which shouldn't happen. Release changes to testing/unstable. Even if your log confirms that, I can't reproduce this behaviour on jessie. root@wheezy:~# lsb_release -a Release:testing Codename:wheezy root@wheezy:~# iptables -A OUTPUT -p tcp --dport 80 -j REJECT root@wheezy:~# apt-get update root@wheezy:~# lsb_release -a No LSB modules are available. Distributor ID:Debian Description:Debian GNU/Linux testing/unstable Release:testing/unstable Codename:n/a How does your /etc/debian_version look like ? And what is the output of `apt- cache policy` ? Thanks in advance, cheers, OdyX -- OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706888: cups: Could not print to server after upgrade: Failed to add Avahi entry
Control: tags -1 +moreinfo Hi Luc, and thanks for your bugreport, Le dimanche, 5 mai 2013 21.52:37, Luc Castermans a écrit : After a normal upgrade of Wheezy I could not print anymore from a CUPS client to the CUPS server. On the server I found below entry in /var/log/cups/error_log E [05/May/2013:08:28:43 +0200] Failed to add Avahi entry for HP LaserJet 1320 @ emael: -8 E [05/May/2013:08:28:43 +0200] Failed to update TXT record for HP LaserJet 1320 @ emael: -2 E [05/May/2013:08:28:43 +0200] Failed to add Avahi entry for HP LaserJet 1320 @ emael: -8 What I did to fix it? Install avahi-discover on the client and run it as normal user. Was avahi-daemon installed (it is Recommended by cups) and running? Avahi is needed in a way or another for automated printers discovery and bonjour-based printer queues. Thanks in advance, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709207: cups: Duplex printing from ios6 via airprint doesn't work
Hi Jonas, and thanks for your bugreport, .oO(Putting Till in copy) Le mardi, 21 mai 2013 19.31:20, Jonas Meyer a écrit : I set up a OKI B430dn printer, using OKIs PPD. The printer is connected via Ethernet to the LAN. I enabled sharing of the printer an Internet sharing and the printer popped up in the Print Menu of my iPod running the latest version of iOS6. Single Sided Printing works exactly as expected. But if I enable double Sided Printing I get the very sam output, but the paper takes the extra route through the duplexer. Printing to the PDF file Printer shows, that no empty pages get inserted in the filtering. Looking at the ps file that is to be sent to the printer doesn't show any problems,either. This seems to be true with the latest versions of cups and cups-filters, too. This makes me think either the printer itself or the PPD files are at fault here. Does the same happen on other printers that you could eventually test? If I send duplex jobs any other way than from iOS everything works as expected. What any other way are you referring to here? Duplex-printing from non-iOS devices? So when I print a duplex job from IOS the duplexer gets activated and the paper travels the extra way through the printer. Instead I'd expect the printer to actually print on both sides. That's a reasonable expectation indeed. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708960: fprintd: Lost enrolled fingerprint after upgrade
Hi Michele, and thanks for your bugreport, Le dimanche, 19 mai 2013 21.03:58, Michele Cane a écrit : After upgrading to the latest version of fprintd: fprintd-list michele found 1 devices Device at /net/reactivated/Fprint/Device/0 Using device /net/reactivated/Fprint/Device/0 User michele has no fingers enrolled for UPEK Eikon 2. I had then to run fprintd-enroll. That's puzzling indeed. Did you update both libfprint and fprintd at the same time? Would it be possible for you to test whether this also happens if you 1) upgrade; 2) reboot; 3) test ? Meilleures salutations, OdyX -- OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708342: glibc_2.14 and glibc_2.15 not found
Control: severity -1 normal Control: tags -1 +moreinfo Le mercredi, 15 mai 2013 11.48:54, Adam Conrad a écrit : On Wed, May 15, 2013 at 10:37:19AM +0200, Dávid Grochal wrote: Package: glibc-doc Severity: critical glibc_2.14 and glibc_2.15 not found I'm not sure, precisely, what this is a bug report about. Could you elaborate on what the problem is that you're seeing? In the meantime, this certainly doesn't fit the definition of critical. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#708356: cups: Unable to set options, Broken pipe
Hi WforumW, Le mercredi, 15 mai 2013 12.20:55, WforumW a écrit : When I update the 'Default Options' over the Cups Web Interface I always get this error Unable to set options, Broken pipe It is not possible to change 'Default Options' for a printer over the Web Interface I can't reproduce this behaviour over localhost:631 on 1.6.2. As I can see from the logs you sent, you are accessing the cups webinterface from a remote machine using the root user, right? Does it work if you try to do the same with a non-root user member of the lpadmin group ? Thanks in advance, cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707986: prints too small on Samsung CLP-310
Hi Martin, thanks for your bugreport. Le dimanche, 12 mai 2013 14.32:22, W. Martin Borgert a écrit : Package: printer-driver-foo2zjs Version: 20120510dfsg0-1 Severity: normal A rectangle of 100 mm x 100 mm is printed as 97 mm x 97 mm. For documentation, letters etc. it doesn't matter, but printing labels and covers becomes difficult. Workaround: If possible, use a scale of ~1.031 or ~103.1%. Does this printer work correctly with the splix driver ? Thanks in advance, cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706598: tpu: win32-loader/0.7.4.7
Le jeudi, 2 mai 2013 15.08:05, Julien Cristau a écrit : Usertags: tpu There's no such usertag. Damn. Trying to get inspiration from existing requests doesn't work well apparently. What do you think ? I think come back for r1. Fair enough. An upload to unstable would be good to have anyway, no? People could then test it with pre-release-almost-wheezy material before the stream of updates to unstable starts to flow. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#697868: Gnome installability vs. GNU/kFreeBSD
Hi all, Le jeudi, 18 avril 2013 12.55:09, Steven Chamberlain a écrit : On 09/04/13 19:15, Didier 'OdyX' Raboud wrote: - gdm3 … doesn't finish loading. It fullscreen-says Oops, an error occured. - lightdm + Gnome: same. - lightdm + Gnome classic: same. Many thanks for testing that. It would be really helpful if you are able to test again with pulseaudio (+ libpulse0) patched with: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=kfreebsd-bug70 5435.patch;att=1;bug=705435 For me, it fixes all of the issues above. Indeed; compiled pulseaudio with that patch and could then successfully start gdm3 and then Gnome. Couldn't reliably test the audio though. It's in any case an improvement over what's now in kFreeBSD, I suggest to NMU pulseaudio with it soon. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
