Bug#734134: kdebase-bin: Strange PolicyKit1-KDE message asks for root password
Hi, This authentication request actually comes from nepomuk's filewatch module, see http://quickgit.kde.org/?p=nepomuk-core.gita=commith=b0a49dab7 Cheers, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734248: qtxmlpatterns-opensource-src: Misleading Description of -doc packages
Package: qtxmlpatterns-opensource-src
Version: 5.1.1-1
Severity: minor
Tags: patch
Dear Maintainer,
The description of the two packages qtxmlpatterns5-doc and
qtxmlpatterns5-doc-html are
Qt 5 declarative documentation
Qt 5 declarative HTML documentation
shouldn't they be:
Qt 5 XML patterns documentation
Qt 5 XML patterns HTML documentation
?
a proposed patch:
diff -ru qtxmlpatterns-opensource-src-5.1.1/debian/control
my-qtxmlpatterns-opensource-src-5.1.1/debian/control
--- qtxmlpatterns-opensource-src-5.1.1/debian/control 2013-07-10
01:00:58.0 +0200
+++ my-qtxmlpatterns-opensource-src-5.1.1/debian/control2014-01-05
09:29:59.183921572 +0100
@@ -103,7 +103,7 @@
Architecture: all
Section: doc
Depends: ${misc:Depends}
-Description: Qt 5 declarative documentation
+Description: Qt 5 XML patterns documentation
Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.
.
@@ -114,7 +114,7 @@
Architecture: all
Section: doc
Depends: ${misc:Depends}
-Description: Qt 5 declarative HTML documentation
+Description: Qt 5 XML patterns HTML documentation
Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.
.
Regards,
m
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
http://bodrato.it/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734249: kino: List entry MimeType in Kino.desktop miss trailing semicolon
Package: kino Version: 1.3.4-1.4 Severity: minor Dear Maintainer, When I install any package, I read the warning: kbuildsycoca4() KConfigGroup::readXdgListEntry: List entry MimeType in /usr/share/applications/Kino.desktop is not compliant with XDG standard (missing trailing semicolon). Adding the a semicolon to the last line of the file solved. Regards, m -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kino depends on: ii libasound2 1.0.27.2-3 ii libatk1.0-0 2.10.0-2 ii libavc1394-0 0.5.4-2 ii libavcodec54 6:9.10-1 ii libavformat546:9.10-1 ii libavutil52 6:9.10-1 ii libc62.17-97 ii libcairo21.12.16-2 ii libdv4 1.0.0-6 ii libfontconfig1 2.11.0-2 ii libfreetype6 2.5.1-1 ii libgcc1 1:4.8.2-10 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libglade2-0 1:2.6.4-1 ii libglib2.0-0 2.36.4-1 ii libgtk2.0-0 2.24.22-1 ii libice6 2:1.0.8-2 ii libiec61883-01.2.0-0.1 ii libpango-1.0-0 1.36.0-1+b1 ii libpangocairo-1.0-0 1.36.0-1+b1 ii libpangoft2-1.0-01.36.0-1+b1 ii libquicktime22:1.2.4-4+b1 ii libraw1394-112.1.0-1 ii libsamplerate0 0.1.8-5 ii libsm6 2:1.2.1-2 ii libstdc++6 4.8.2-10 ii libswscale2 6:9.10-1 ii libx11-6 2:1.6.2-1 ii libxext6 2:1.3.2-1 ii libxml2 2.9.1+dfsg1-3 ii libxv1 2:1.0.9-1 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages kino recommends: ii curl7.34.0-1 ii ffmpeg 6:0.8.7-1 Versions of packages kino suggests: pn ffmpeg2theora none ii lame 3.99.5+repack1-3 pn mjpegtools none ii sox14.4.1-3 ii udev 204-5 pn vorbis-tools none -- no debconf information -- http://bodrato.it/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
On Sun, Jan 05, 2014 at 02:53:12PM +0900, Charles Plessy wrote: Dear all, Based on Josselin's contribution and the comments of Russ, I have written a patch for the Debian Policy, that documents the use of the FreeDesktop standards for the use of Desktop menus and media types (MIME). Thanks, Charles, this reads really nicely. Disclaimer: I admit to having no particular expertise in this area, nor do I have any specific affiliations. I do not feel in a position to meaningfully second this proposal. One suggested rewording: 9.7. Multimedia handlers [...] Packages which provide programs to view/show/play, compose, edit or print media types should register them using either the _FreeDesktop_ system or the _mailcap_ system. I suggest appending but not both to make it really explicit (I know it's mentioned later in one of the subsections, but there's no harm in repeating it): ... should register them using either the _FreeDesktop_ system or the _mailcap_ system, but not both. Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733385: Patch for #733385
Control: tags -1 + patch Dear maintainer, Here’s a patch I’ve created and tested. I’ve attached two files: “fix-freetype-includes.patch” is just the patch fixing the issues in code and “xft_nmu.debdiff” is a debdiff for a NMU which incorporates the patch into the package. After a short delay I’ll consider finding a sponsor for the NMU. The built source package will be available at mentors[1]. Thanks, -- Juhani Numminen [1] http://mentors.debian.net/package/xft xft_nmu.debdiff Description: Binary data Dscription: Fix build failure with freetype 2.5.1 Author: Juhani Numminen juhaninummin...@gmail.com Bug-Debian: http://bugs.debian.org/733385 --- a/src/xftglyphs.c +++ b/src/xftglyphs.c @@ -21,10 +21,11 @@ */ #include xftint.h -#include freetype/ftoutln.h -#include freetype/ftlcdfil.h +#include ft2build.h +#include FT_OUTLINE_H +#include FT_LCD_FILTER_H -#include freetype/ftsynth.h +#include FT_SYNTHESIS_H /* * Validate the memory info for a font
Bug#734250: gdm3: Please add brltty package to install together whith gdm3 because is used by gdm3
Package: gdm3 Version: 3.8.4-6 Severity: minor Make errors on $HOME/.cache/gdm/session.log Can't connect to brltty :0 -- System Information: Debian Release: jessie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gdm3 depends on: ii accountsservice 0.6.34-2 ii adduser 3.113+nmu3 ii dconf-cli0.18.0-1 ii dconf-gsettings-backend 0.18.0-1 ii debconf [debconf-2.0]1.5.52 ii gir1.2-gdm3 3.8.4-6 ii gnome-session [x-session-manager]3.8.4-3 ii gnome-session-bin3.8.4-3 ii gnome-session-flashback [x-session-manager] 3.8.0-1 ii gnome-settings-daemon3.8.5-2 ii gnome-shell 3.8.4-5 ii gnome-terminal [x-terminal-emulator] 3.10.1-1 ii gsettings-desktop-schemas3.8.2-2 ii kde-window-manager [x-window-manager]4:4.11.3-2 ii konsole [x-terminal-emulator]4:4.11.3-1 ii libaccountsservice0 0.6.34-2 ii libatk1.0-0 2.10.0-2 ii libaudit11:2.3.2-2 ii libc62.17-97 ii libcairo-gobject21.12.16-2 ii libcairo21.12.16-2 ii libcanberra-gtk3-0 0.30-2 ii libcanberra0 0.30-2 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libgdm1 3.8.4-6 ii libglib2.0-0 2.36.4-1 ii libglib2.0-bin 2.36.4-1 ii libgtk-3-0 3.8.6-1 ii libpam-modules 1.1.3-9 ii libpam-runtime 1.1.3-9 ii libpam-systemd 204-5 ii libpam0g 1.1.3-9 ii libpango-1.0-0 1.36.0-1+b1 ii libpangocairo-1.0-0 1.36.0-1+b1 ii librsvg2-common 2.40.0-1 ii libselinux1 2.2.1-1 ii libwrap0 7.6.q-24 ii libx11-6 2:1.6.2-1 ii libxau6 1:1.0.8-1 ii libxdmcp61:1.1.1-1 ii libxrandr2 2:1.4.1-1 ii lsb-base 4.1+Debian12 ii metacity [x-window-manager] 1:2.34.13-1 ii mutter [x-window-manager]3.8.4-2 ii upower 0.9.23-2+b1 ii x11-common 1:7.7+5 ii x11-xserver-utils7.7+1 ii xterm [x-terminal-emulator] 300-1 Versions of packages gdm3 recommends: ii at-spi2-core 2.10.2-1 ii desktop-base 7.0.3 ii gnome-icon-theme 3.10.0-1 ii gnome-icon-theme-symbolic 3.10.1-1 ii x11-xkb-utils 7.7+1 ii xserver-xephyr 2:1.14.5-1 ii xserver-xorg 1:7.7+5 ii zenity 3.8.0-1 Versions of packages gdm3 suggests: ii gnome-orca3.4.2-2 ii libpam-gnome-keyring 3.8.2-2 -- Configuration Files: /etc/gdm3/greeter.gsettings changed [not included] -- debconf information: * shared/default-x-display-manager: gdm3 gdm3/daemon_name: /usr/sbin/gdm3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
]] Dimitri John Ledkov Fedora/RPM based distributions are significantly different, thus it is inevitable that we'll have to maintain a fork of systemd for best integration into Debian. This does not seem evident from the current systemd maintainers, which file bugs to disable/remove/override debian functionality and components with inferior systemd counterparts. Can you provide bug numbers for those allegations, please? http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;bug=716812 Not sure why you mention this. It's filed by a user, not anybody who's maintaining systemd. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719738 - udev follow upstream change, granted, steps have later been taken back to preserve backwards compat. Not sure how «please enable upstream functionality so lvm2 doesn't hold up the boot» becomes «disable/remove/override debian functionality with inferior systemd counterparts». Josh explains this pretty adequately in his mail. I've downloaded systemd_204.orig.tar.gz from debian mirror - 3ba441b51a390c6afc21e9a8a4811698 And i've downloaded systemd-204.tar.xz from systemd upstream - a07619bb19f48164fbf0761d12fd39a8 Ah, it seems like the last upload was done wrongly somehow. I'll see what we can do to fix that. As you can see if you browse your local mirror, there's a .tar.xz there too with a hash that matches upstream. Thanks for noticing this. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734252: [wine32] wine32 overrides default wineprefix
Package: wine32 Version: 1.6.1-12 Severity: normal --- Please enter the report below this line. --- Dear maintainer, I've noticed that currently executing wine on any 32-bit package (or running wine32 - it's the same, since wine falls back to wine32) without setting the WINEPREFIX variable results in using $home/wine32 as default prefix, as determined by the line: test -z $WINEPREFIX export WINEPREFIX=$HOME/.wine32 This is in contrast with what the documentation says (and with the upstream behaviour): WINEPREFIX If set, the contents of this variable is taken as the name of the directory where Wine stores its data (the default is $HOME/.wine). I also find that using separate prefixes for 32 and 64 bit wine is not convenient, because you need to keep any program you use in both prefixes installed twice, update it in both profiles, update all symlinks to windows drives (D:,...) twice and so on, which can IMO easily lead to confusion. Since 32 bit applications can run flawlessly from a 64 bit profile, I would suggest to simply remove that line from /usr/bin/wine32, and rather let those who want to keep profiles separated do that on their own, since this is the default upstream behaviour. --- System information. --- Architecture: amd64 Kernel: Linux 3.11.8-desktop-f Debian Release: jessie/sid 900 testing ftp.nluug.nl 900 solydxk ftp.nluug.nl 900 solydxk community.solydxk.com 850 testing debian.fastweb.it 800 unstable debian.fastweb.it 750 experimental debian.fastweb.it 500 wheezy linux.dropbox.com 500 home:ksmanis download.opensuse.org 400 testing debian.linuxmint.com 400 debian packages.linuxmint.com --- Package information. --- Depends (Version) | Installed ===-+-== libc6 (= 2.3.6-6~) | libwine | x11-utils | libwine-gecko-1.4 | Package's Recommends field is empty. Package's Suggests field is empty. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734251: totem-plugins: Opensubtitles plugin: cannot be activated in totem 3.8
Package: totem-plugins Version: 3.8.2-3 Severity: normal Dear Maintainer, The opensubtitles plugin cannot be activated or loaded in totem 3.8. It is activated on my configuration, so I get the following messages every time I launch totem: (totem:14822): libpeas-WARNING **: Error initializing Python Plugin Loader: PyGObject initialization failed ImportError: could not import gobject (could not find _PyGObject_API object) (totem:14822): libpeas-WARNING **: Please check the installation of all the Python related packages required by libpeas and try again (totem:14822): libpeas-WARNING **: Loader 'python' is not a valid PeasPluginLoader instance (totem:14822): libpeas-WARNING **: Could not find loader 'python' for plugin 'opensubtitles' And if I check manually the plugin list in Editplugins, the plugin has a little red sign and cannot be activated. It seems this totem 3.8 uses python3, while the plugin is written in python 2. It seems a port for Python 3 was done upstream [1]. Regards, Bertrand Marc [1] https://git.gnome.org/browse/totem/commit/src/plugins/opensubtitles?id=6022536e085e65c086282c831f27000b13f3abfe -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages totem-plugins depends on: ii gir1.2-gdkpixbuf-2.0 2.28.2-1+b1 ii gir1.2-glib-2.0 1.36.0-2+b1 ii gir1.2-gtk-3.03.8.6-1 ii gir1.2-pango-1.0 1.36.0-1+b1 ii gir1.2-peas-1.0 1.8.1-1 ii gir1.2-totem-1.0 3.8.2-3 ii libatk1.0-0 2.10.0-2 ii libc6 2.17-97 ii libcairo-gobject2 1.12.16-2 ii libcairo2 1.12.16-2 ii libgdk-pixbuf2.0-02.28.2-1+b1 ii libglib2.0-0 2.36.4-1 ii libgrilo-0.2-10.2.7-1 ii libgtk-3-03.8.6-1 ii liblircclient00.9.0~pre1-1 ii libpango-1.0-01.36.0-1+b1 ii libpangocairo-1.0-0 1.36.0-1+b1 ii libtotem0 3.8.2-3 ii libxml2 2.9.1+dfsg1-3 ii python2.7.5-5 ii python-gi 3.10.2-1 ii python-xdg0.25-3 ii python2.7 2.7.6-4 ii totem 3.8.2-3 Versions of packages totem-plugins recommends: ii gnome-settings-daemon 3.8.5-2 Versions of packages totem-plugins suggests: pn gromit none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734253: winecfg, winepath, wineboot default to wine64 and fail with WINEARCH set
Package: wine Version: 1.6.1-12 Severity: normal Dear Maintainer, first of all, thanks for your recent work on wine. I've noticed that wine utils like winecfg etc now default to wine64. I'm not sure if this changed because I've installed wine64 or because of a recent update. A workaround for all problem described below is to start all commands with wine like wine command Here is a list of problems I noticed: * wine defaults to wine32 while winecfg defaults to wine64 unset WINEARCH rm -rf foo # fresh env export WINEPREFIX=`pwd`/foo wine wineboot -u # wine32 env created winecfg # fails with .../foo' is a 32-bit installation, it cannot support 64-bit applications. wine winecfg # works * setting WINEARCH to win32 makes winecfg fail and create a half finished wine32 env (drive_c is empty) rm -rf foo # fresh env export WINEPREFIX=`pwd`/foo export WINEARCH=win32 winecfg # fails with .../foo' is a 32-bit installation, it cannot support 64-bit applications. # this ends with a half created wine32 env (drive_c is empty) * Since a recent update msiexec is missing (wine msiexec still works) . regards -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (901, 'unstable'), (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages wine depends on: ii file1:5.14-2 ii wine32 1.6.1-12 ii wine64 1.6.1-12 wine recommends no packages. Versions of packages wine suggests: pn avscan | klamav | clamav none ii binfmt-support 2.1.1-1 ii ttf-mscorefonts-installer 3.5 ii winbind2:4.1.3+dfsg-2 pn wine-doc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734254: gwakeonlan: Show machine on/off status in list
Package: gwakeonlan Version: 0.5.1-1 Severity: wishlist Dear Maintainer, I'd like to see the on/off status of a/ll machine/s in the list (a column or different colors, etc.), maybe unsing some sort of ping (which does not require root prvileges). Thank you! -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12.6 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gwakeonlan depends on: ii librsvg2-common 2.40.0-1 ii python 2.7.5-5 ii python-gtk2 2.24.0-3+b1 gwakeonlan recommends no packages. gwakeonlan suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734233: apt-listbugs: Unable to start, debian_version load error
Control: tag -1 + moreinfo On Sun, 5 Jan 2014 09:37:03 +0700 Theppitak Karoonboonyanan wrote: [...] Dear Maintainer, Hello Theppitak, thanks for your bug report. When starting apt-listbugs on one of my machines: $ apt-listbugs /usr/lib/ruby/vendor_ruby/debian.rb:24:in `require': no such file to load -- debian_version (LoadError) from /usr/lib/ruby/vendor_ruby/debian.rb:24 from /usr/bin/apt-listbugs:289:in `require' from /usr/bin/apt-listbugs:289 Note that on other machines, it starts fine. I don't know ruby enough to find the difference. Please let me know if I can do more checks. [...] Versions of packages apt-listbugs depends on: [...] ii ruby-debian 0.3.8+b2 [...] ii ruby1.8 [ruby-interpreter] 1.8.7.358-9 I think the problem may be that you are still using ruby1.8 as Ruby interpreter, while package ruby-debian has been recently rebuilt (version 0.3.8+b2) with support for ruby1.9.1 and ruby2.0, dropping support for ruby1.8 (there's a transition going on to remove ruby1.8 from Debian)... Please switch to Ruby 1.9: installing package ruby1.9.1 should suffice (it should automatically set itself as the default Ruby interpreter and the command ruby -v should print ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux]). Please let me know whether this fixes the issue. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgphd996ph1oE.pgp Description: PGP signature
Bug#727708: init system discussion status
On Sun, 2014-01-05 at 02:18 +, Dimitri John Ledkov wrote: On 5 January 2014 01:46, Russ Allbery r...@debian.org wrote: Dimitri John Ledkov x...@debian.org writes: Imho that's a gross overstatement. Over more than a year, an Ubuntu GNOME team was established and became official ubuntu flavour with so goal and purpose of shipping GNOME3 in it's full glory. If distro watch is any indication they are fast growing ubuntu flavour, outpacing the more established ones like e.g. Xubuntu. The demand for such flavour is growing, with highly positive reviews from critics and general public. There is a group of volunteers who contribute to making it work. I've personally used it, and it's quite wonderful and capable desktop environment. I think there is some degree of heresy to claim that GNOME3 is only supported with systemd-init pid1. That was the case intermittently, until majority of pid1 checks were replaced by more correct ones. Insofar as this is evidence that it's possible to make GNOME work with option 2 (run logind without systemd), this is certainly valid information, but I think this is information that we already have. As I said in my original writeup, I believe the main challenge with option 2 for jessie is not in figuring out *how* to do the work, but in identifying *who* is going to do the work. (Beyond jessie, this will require ongoing resources to maintain if it's not purely a transitional issue, but that's a somewhat separate discussion.) And I'll note that Sjoerd said exactly the same thing. Saying that it's easy is fine, particularly if you have details as to why it's easy. What we're not going to do is say that therefore the existing GNOME maintainers in Debian must do it. That is not how we work as a project, and that is not how we're going to work as a project. If they don't want to do the work, no one is going to force them to do it. Please instead note Steve's comments on maintaining logind as a separate package, which is the productive way forward and is a way to get to the second solution in my original message. Volunteering to do the work and finding a way to do it in a minimally intrusive fashion is the way to show that it's straightforward. I see thanks. I guess the only relevant addition, is that there is a pool of self-selected developers that are working on the similar type of integration issues: GNOME3 with logind without systemd-init. The Ubuntu GNOME team (packaging team is 18 people at the moment, there are more in users/qa/documentation teams ~250+ people) https://launchpad.net/~ubuntu-gnome-packaging I think as the Debian gnome team we've got a pretty good working relationship with some developers in that team, (with some developers even contributing directly to both teams! Which is great). So I'm well aware of its existance. Maybe just to clarify a bit more, _most_ of my statement was about the case where we would _not_ have systemd-logind available at all unless the default init system is PID 1. If it is available in some form it's a quite different story from an integration point of view, which Ubuntu and the Ubuntu gnome team prove. That's why i started my earlier reply in this thread by saying that it boils down to whether we can rely on systemd-logind being available :) However there is a second important difference here, which i think is worth highlighting. In the Ubuntu Gnome team, the system configuration that team supports may not be what upstream Gnome supports but it is the default Ubuntu configuration which is what all Ubuntu Gnome users actually use. So that team can focus on polishing purely that one setup. In this case the question is not about supporting Debians defaults configuration, but _additionally_ supporting a fallback configuration which hopefully only a very very small amount of users are forced to use. In the case logind can be assumed, I'm reasonably confident we can provide an at least somewhat functionally Gnome 3 for these users. However, we most likely wouldn't go to the effort of making it fully functional simply because it's both a corner case and missing someone willing to do that job test it maintain it. -- Sjoerd Simons sjo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734255: [wine] winecfg now fails on 32 bit profiles
Package: wine Version: 1.6.1-12 Severity: important --- Please enter the report below this line. --- revision 11 indeed fixed the issue in #733648, but introduced the opposite problem When executing winecfg on a 32 bit wineprofile, it fails with $winecfg wine: '/home/francesco/.wine' is a 32-bit installation, it cannot support 64-bit applications. Moreover, winecfg also ignores the WINEARCH variable: $env WINEARCH=win32 winecfg wine: '/home/francesco/.wine' is a 32-bit installation, it cannot support 64-bit applications. and fails on the default 32 bit wineprofile (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734252 ): env WINEPREFIX=$HOME/.wine32 WINEARCH=win32 winecfg wine: '/home/francesco/.wine32' is a 32-bit installation, it cannot support 64-bit applications. I would suggest to read inside the profile whether it is 32 or 64 bit, for instance with test -z $WINEPREFIX WINEPREFIX=$HOME/.wine WINEARCH=$(cat $WINEPREFIX/system.reg|grep #arch|sed -e s/'#arch='/''/) and to call the 32 bit or 64 bit binary accordingly. Regards --- System information. --- Architecture: amd64 Kernel: Linux 3.11.8-desktop-f Debian Release: jessie/sid 900 testing ftp.nluug.nl 900 solydxk ftp.nluug.nl 900 solydxk community.solydxk.com 850 testing debian.fastweb.it 800 unstable debian.fastweb.it 750 experimental debian.fastweb.it 500 wheezy linux.dropbox.com 500 home:ksmanis download.opensuse.org 400 testing debian.linuxmint.com 400 debian packages.linuxmint.com --- Package information. --- Depends (Version) | Installed ==-+-=== file | 1:5.14-2 wine64 (= 1.6.1-12) | 1.6.1-12 OR wine32 (= 1.6.1-12) | 1.6.1-12 Package's Recommends field is empty. Suggests (Version) | Installed -+-=== wine-doc | 1.0.0-1 binfmt-support | 2.0.16 ttf-mscorefonts-installer | 3.5 winbind | 2:4.0.11+dfsg-1 avscan | OR klamav | OR clamav | 0.97.8+dfsg-1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730856: transition: libtasn1-6
On 2013-11-30 Andreas Metzler ametz...@bebt.de wrote: [...] I would like to finally (now that libimobiledevice builds again) get rid of libtasn1-3. [...] ping? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617349: Still can not reboot
Hi! I'm currently getting this in terminal from lxsession-logout when trying to reboot: (lxsession-logout:12545): GLib-GIO-CRITICAL **: g_dbus_proxy_call_sync_internal: assertion `error == NULL || *error == NULL' failed (lxsession-logout:12545): GLib-CRITICAL **: g_variant_unref: assertion `value != NULL' failed Although, lxsession-logout exits with 0. (current Debian testing, lxsession 0.4.9.2-1) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729074: gloox: Please upgrade to 1.0.9
Hi Jose, Would you like a helping hand with maintenance of gloox in Debian? I've noticed that #729074 has been open for roughly 2 months now, and it seems like you haven't had any time to reply to it, nor to any of the other currently open (and older) bugs against src:gloox in the BTS. If you're busy at the moment, I'd be glad to help prepare a new upstream release and address some of the open bugs in the BTS as well, as one of my packages (0ad) depends on this library. (MIA team: the last upload Jose made for gloox was back in 2010-01-22; there's been a NMU and 10 new upstream releases since then. It also looks like there's been a few MIA queries for Jose in the past, e.g. [1][2]; I'm not sure if this justifies cc-ing the MIA team off the bat though.) Cheers, Vincent [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521722#50 [2] https://lists.debian.org/debian-devel/2009/08/msg00962.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734256: ruby-debian broke apt-listbugs
Package: ruby-debian Version: 0.3.8+b2 apt-get upgrade fail with following message: peppe@Debian-giupino:~$ sudo apt-get upgrade Lettura elenco dei pacchetti... Fatto Generazione albero delle dipendenze Lettura informazioni sullo stato... Fatto Calcolo dell'aggiornamento... Eseguito I seguenti pacchetti sono stati installati automaticamente e non sono più richiesti: linux-image-3.11-1-686-pae linux-image-3.11-2-686-pae Usare apt-get autoremove per rimuoverli. I seguenti pacchetti saranno aggiornati: amule amule-common amule-utils at-spi2-core cups cups-client cups-common cups-daemon cups-ppdc cups-server-common gir1.2-atspi-2.0 libatk-adaptor libatk-bridge2.0-0 libatspi2.0-0 libav-tools libavcodec-extra-54 libavfilter3 libavformat54 libavresample1 libavutil52 libcups2 libcupscgi1 libcupsimage2 libcupsmime1 libcupsppdc1 libnss3 libnss3-1d libterm-ui-perl libxcb-composite0 libxcb-dri2-0 libxcb-glx0 libxcb-randr0 libxcb-render0 libxcb-shape0 libxcb-shm0 libxcb-xfixes0 libxcb-xv0 libxcb1 python-pycurl w3m 40 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati. È necessario scaricare 0 B/15,4 MB di archivi. Dopo quest'operazione, verranno occupati 18,4 kB di spazio su disco. Continuare? [S/n] s /usr/lib/ruby/vendor_ruby/debian.rb:24:in `require': no such file to load -- debian_version (LoadError) from /usr/lib/ruby/vendor_ruby/debian.rb:24 from /usr/sbin/apt-listbugs:289:in `require' from /usr/sbin/apt-listbugs:289 E: Il sottoprocesso /usr/sbin/apt-listbugs apt ha restituito un codice d'errore (1) E: Failure running script /usr/sbin/apt-listbugs apt peppe@Debian-giupino:~$ dpkg -S debian.rb ruby-debian: /usr/lib/ruby/vendor_ruby/debian.rb the error does not allow you to update the system anymore (with apt-listbugs installed) Debian version: Sid Kernel: 3.12-1-686-pae libc6: 2.17-97 Regards Giuseppe
Bug#729074: Jose Sogo (jsogo)'s email bounced [was: Re: gloox: Please upgrade to 1.0.9]
Hi MIA team, After sending the following message to Jose: On Sun, Jan 5, 2014 at 2:07 AM, Vincent Cheng vincentc1...@gmail.com wrote: Hi Jose, Would you like a helping hand with maintenance of gloox in Debian? I've noticed that #729074 has been open for roughly 2 months now, and it seems like you haven't had any time to reply to it, nor to any of the other currently open (and older) bugs against src:gloox in the BTS. If you're busy at the moment, I'd be glad to help prepare a new upstream release and address some of the open bugs in the BTS as well, as one of my packages (0ad) depends on this library. (MIA team: the last upload Jose made for gloox was back in 2010-01-22; there's been a NMU and 10 new upstream releases since then. It also looks like there's been a few MIA queries for Jose in the past, e.g. [1][2]; I'm not sure if this justifies cc-ing the MIA team off the bat though.) Cheers, Vincent [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521722#50 [2] https://lists.debian.org/debian-devel/2009/08/msg00962.html I got this in reply: This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: js...@arrakis.es mailbox is full: retry timeout exceeded Is there a way to confirm that js...@debian.org still forwards to js...@arrakis.es (which was the email I pulled off from his DD portfolio page)? If so, since he appears to be unreachable, would this qualify as a RC bug against gloox as per Policy 3.3? Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730856: transition: libtasn1-6
On 2013-11-30 11:59, Andreas Metzler wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello, I would like to finally (now that libimobiledevice builds again) get rid of libtasn1-3. This should a small painless transition, it will require sourceful uploads of 3 source packages which are up to date in testing. * gnutls26 * gcr * libimobiledevice All of these three can be built against libtasn1-6. cu Andreas Ben file: title = libtasn1-6; is_affected = .depends ~ libtasn1-3 | .depends ~ libtasn1-6; is_good = .depends ~ libtasn1-6; is_bad = .depends ~ libtasn1-3; Hi, Sorry for the late responds. Why will it require a sourceful upload of these packages (rather than a binNMU) and are the maintainers of the reverse dependencies ready to upload their packages? ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734203: debian-edu-ger...@lists.debian.org
Hello, I would like to have this mailinglist as well. Regards, Benedikt Wildenhain -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734203: Mailing list for German Debian Edu group
Hi it would be nice, to use the new list, the old one outdated. debian-edu-ger...@lists.debian.org So please install the new list as soon as possible. Thanks from Harold at Skolelinux in DE -- Harald Poppek harald.pop...@t-online.de GnuPG Key ID 0xFD636B8B signature.asc Description: OpenPGP digital signature
Bug#734256: duplicated bug
I did some check, I think the bug is a duplicate of #734233 but i think that is a ruby-debian bug if is correct what Francesco says: I think the problem may be that you are still using ruby1.8 as Ruby interpreter, while package ruby-debian has been recently rebuilt (version 0.3.8+b2) with support for ruby1.9.1 and ruby2.0, dropping support for ruby1.8 (there's a transition going on to remove ruby1.8 from Debian)... however, i'll try to go on ruby 1.9 and see if it fix the issue. Regards Giuseppe
Bug#734257: xdg-user-dirs-gtk: File /etc/xdg/autostart/user-dirs-update-gtk.desktop bugme on gdm error file
Package: xdg-user-dirs-gtk Version: 0.10-1 Severity: minor Here is content of $HOME/.cache/gdm/session.log: x-session-manager[3935]: WARNING: Could not parse desktop file user-dirs- update-gtk.desktop or it references a not found TryExec binary -- System Information: Debian Release: jessie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xdg-user-dirs-gtk depends on: ii libc6 2.17-97 ii libglib2.0-0 2.36.4-1 ii libgtk-3-0 3.8.6-1 ii xdg-user-dirs 0.15-1 xdg-user-dirs-gtk recommends no packages. xdg-user-dirs-gtk suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734257:
Please add this package to an gnome-session dependencies. After install xdg-user-dirs-gtk errors is missing.
Bug#734256: workaround
Dear Maintainer, Francesco suggestion is correct. I've installed ruby1.9 package, with apt-listbugs disabled, and now the issue is fixed. I don't know if my system has a specific configuration but i think that the version 0.3.8+b2 of ruby-debian must require the new ruby interpeter to not broke the system update. Thanks Regards Giuseppe
Bug#733496: Code copy of older Mozilla code
Hi, Package: mozjs17 Severity: serious This package forks a local copy of the Iceweasel Javascript engine which is no longer supported with security updates (currently only the ESR24 series is maintained) Out of curiosity, why is this a RC bug when there seems to be no issues from the security team with regards to src:mozjs (which is even older, based on Firefox 4 code AFAIU, and is currently in stable)? Why do we need a copy of the old version anyway? What are the expected applications using it and why can't they be migrated to the mozjs provided by the iceweasel source package. The following packages are currently depending against libmozjs185-1.0: 0ad cinnamon couchdb dehydra gnome-shell libgjs0b libgjs0c libmozjs185-dev libpeas-1.0-0 mediatomb-common oolite policykit-1 (taken from mozjs17's ITP bug report, #709434) GNOME Shell stands out in that list above as a major package that depends on mozjs/Spidermonkey. I myself am maintainer for 0ad, hence why I'm interested in this bug report as well. My understanding is that Spidermonkey, as a standalone release (snapshot?) of FF's javascript engine, is meant to be embedded in applications that use it. I can't answer for all the packages above, but I know that 0ad requires a very specific version of Spidermonkey, and that transitioning between different releases seems to be rather painful for upstream. I guess one possible way to deal with this is to dump mozjs and mozjs17 (and future Spidermonkey releases) in the same category as webkit, i.e. unsupported by the security team? Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733385: Patch for #733385
On Sun, Jan 5, 2014 at 10:50:00 +0200, Juhani Numminen wrote: After a short delay I’ll consider finding a sponsor for the NMU. NAK. Cheers, Julien signature.asc Description: Digital signature
Bug#734093: debian-installer: install plymouth by default
On Sun, Jan 5, 2014 at 08:29:24 +0100, Christian PERRIER wrote: reassign 734093 tasksel retitle 734093 Please include plymouth in task-desktop thanks (proposal to install plymouth, that provides an attractive boot animation in place of the text messages that normally get shown. Text messages are instead redirected to a logfile for viewing after boot. ...by default, with desktop environments, when installing Debian) Quoting Holger Levsen (hol...@layer-acht.org): On Samstag, 4. Januar 2014, Andreas Cadhalpun wrote: Maybe it is better to install plymouth only, if task-desktop is installed? this seems like a very reasonable approach to me. OK, then. Reassigning to tasksel (as we should have done for quite a while, indeed Apart from that, I have no strong advice about this. A nice and appealing (one taste may vary) boot screen for desktop computers can be seen as something to have by some people but others may hate that. I think that, at least, if plymouth is included in task-desktop, we should be certain that a Debian theme is cooked for it in a consistent manner with Debian themes for desktop environments. I think plymouth would have to be maintained in unstable, not just in experimental, before tasksel should touch it. Cheers, Julien signature.asc Description: Digital signature
Bug#734262: ITP: xmds2 -- eXtensible Multi-Dimensional Simulator
Package: wnpp Severity: wishlist Owner: Rafael Laboissiere raf...@laboissiere.net * Package name: xmds2 Version : 2.1.4 Upstream Author : Graham Dennis, Andy Ferris, Joe Hope, Michael Hush, Mattias Johnsson, and Gabriel McManus xmds-de...@lists.sourceforge.net * URL : http://www.xmds.org/ * License : GPL2 Programming Lang: Python Description : eXtensible Multi-Dimensional Simulator XMDS is a code generator that integrates equations, from Ordinary Differential Equations (ODEs) up to stochastic Partial Differential Equations (PDEs). You write them down in human readable form in an XML file, and it goes away and writes and compiles a C++ program that integrates those equations as fast as it can possibly be done in your architecture. XMDS 2 is a major upgrade rewritten in Python which is faster and far more versatile than previous versions, allowing the efficient integration of almost any initial value problem on regular domains. Note that a xmds package exists in Debian for version 1. The upstream authors renamed the program to xmds2 in order to allow the co-existence of both versions in the system. They did that because the format of the *.xmds files changed in version 2 and there still may be users around who need version 1. The issue of having both versions packaged in Debian has been discussed in the debian-science mailing list: https://lists.debian.org/debian-science/2014/01/msg5.html BTW, the maintainer of the xmds2 package will be the Debian Science Team. A preliminary version of the Debian package can be built with git-buildpackage from the Git repository at: git://anonscm.debian.org/debian-science/packages/xmds2.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)
Le samedi, 4 janvier 2014, 19.54:05 Stefano Rivera a écrit : Hi Jonathan (2014.01.02_19:22:33_+0200) * having to support remote signing It would be fair enough to stderr not supported, please use the older tool in devscripts and error 1 if such an argument was provided. That would be pragmatic if (as I suspect) -r is rarely used. Aww. I'm a frequent user of -r. I have better places to build big packages than on my lap, and I prefer to keep my GPG key in as few places as possible. I concur. I build my packages on a server's sbuild and then debsign -r from my laptop, then dput from the server. Please keep this workflow possible with in-archive tools. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#734263: cat: /etc/X11/fonts/misc/xfonts-wqy.alias: Is a directory
Package: xfonts-efont-unicode Setting up xfonts-efont-unicode (0.4.2-6) ... cat: /etc/X11/fonts/misc/xfonts-wqy.alias: Is a directory Setting up xfonts-efont-unicode-ib (0.4.2-6) ... cat: /etc/X11/fonts/misc/xfonts-wqy.alias: Is a directory -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734264: cat: /etc/X11/fonts/misc/xfonts-wqy.alias: Is a directory
Package: xfonts-efont-unicode-ib Setting up xfonts-efont-unicode (0.4.2-6) ... cat: /etc/X11/fonts/misc/xfonts-wqy.alias: Is a directory Setting up xfonts-efont-unicode-ib (0.4.2-6) ... cat: /etc/X11/fonts/misc/xfonts-wqy.alias: Is a directory -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734257: xdg-user-dirs-gtk: File /etc/xdg/autostart/user-dirs-update-gtk.desktop bugme on gdm error file
tag 734257 + moreinfo thanks Le Sun, 5 Jan 2014 12:43:54 +0200, Marian Corcodel corcodel.mar...@gmail.com a écrit : Please add this package to an gnome-session dependencies. After install xdg-user-dirs-gtk errors is missing. Hi, I think this might be a case of removed-but-not-purged package as the .desktop is installed in /etc. I'm seeing nothing in the archive (codesearch) that is explicitly trying to start this. Could you please check in the dpkg/apt logs what was the status of the package before you (re-)install it? Cheers, Laurent Bigonville -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734266: too chatty during install
Package: linux-image-3.12-1-686-pae Compared to other packages, this package makes many lines of output during installation. That is nice, but the admin must look at each line looking for errors, when in fact they are all not errors or warnings. There ought to be a Debian standard. Setting up linux-image-3.12-1-686-pae (3.12.6-2) ... Running depmod. Examining /etc/kernel/postinst.d. run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.12-1-686-pae /boot/vmlinuz-3.12-1-68 run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.12-1-686-pae /boot/vmlinuz-3.12-1-686 update-initramfs: Generating /boot/initrd.img-3.12-1-686-pae run-parts: executing /etc/kernel/postinst.d/zz-update-grub 3.12-1-686-pae /boot/vmlinuz-3.12-1-686- Generating grub configuration file ... Found linux image: /boot/vmlinuz-3.12-1-686-pae Found initrd image: /boot/initrd.img-3.12-1-686-pae Found linux image: /boot/vmlinuz-3.11-2-686-pae Found initrd image: /boot/initrd.img-3.11-2-686-pae Found linux image: /boot/vmlinuz-3.11-1-686-pae Found initrd image: /boot/initrd.img-3.11-1-686-pae done -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730856: transition: libtasn1-6
On 2014-01-05 Niels Thykier ni...@thykier.net wrote: On 2013-11-30 11:59, Andreas Metzler wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I would like to finally (now that libimobiledevice builds again) get rid of libtasn1-3. This should a small painless transition, it will require sourceful uploads of 3 source packages which are up to date in testing. * gnutls26 * gcr * libimobiledevice All of these three can be built against libtasn1-6. [...] Sorry for the late responds. Why will it require a sourceful upload of these packages (rather than a binNMU) Hello, It is because we have libtasn1-3/libtasn1-3-dev/libtasn1-3-dbg/libtasn1-3-bin libtasn1-6/libtasn1-6-dev/libtasn1-6-dbg/libtasn1-bin (where the versioned -dev packages conflict) and the three abovementioned packages have dependencies in the generated binary packages on libtasn1-3-dev: ametzler@argenau:~/TIN/TASN$ grep-dctrl -FDepends libtasn1-3- -sPackage /chroots/sid/var/lib/apt/lists/ftp.at.debian.org_debian_dists_sid_main_binary-i386_Packages Package: libgcr-3-dev Package: libgnutls-dev Package: libimobiledevice-dev Once libgnutls-dev moves to libtasn1-6 it stops being co-installable with the other two mentioned packages. The reason why we have versioned conflicting -dev packages is that I needed to have both available in sid for an extended period of time. - libtasn1-6 has minor API breakage and the respective changes to gnutls26 were not eligible for wheezy freeze. What I did not mention before is that shishi will also need a sourceful upload, as it b-d on libtasn1-3-dev, but that can be done in a second step, as the binary package is stil installable after libgnutls-dev has switched to tasn1-6. ametzler@argenau:~/TIN/TASN$ grep-dctrl -FBuild-Depends libtasn1-3- -sPackage /chroots/sid/var/lib/apt/lists/ftp.at.debian.org_debian_dists_sid_main_source_Sources Package: gcr Package: gnome-keyring Package: gnutls26 Package: libimobiledevice Package: shishi and are the maintainers of the reverse dependencies ready to upload their packages? I am ready for gnutls. The other two packages have outstanding bug-reports - libimobiledevice 2013-12-08 http://bugs.debian.org/731707 - gcr 2013-07-08 http://bugs.debian.org/715354 sadly both without maintainer feedback yet. All three packages are up to date in testing. If you want me to I can obviously make libtasn1-3-dev/libtasn1-3-bin empty transitional packages built from libtasn1-6 which would limit the actual transition to binNMUs. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733603: avr-libc: avr-man unable to work due to missing files/directories
OK, we'll rename them and move them again. On Fri, Jan 3, 2014 at 10:19 AM, Ivan Shmakov i...@siamics.net wrote: fixed 733603 1:1.8.0-4 thanks Hakan Ardo ha...@debian.org writes: On Mon, Dec 30, 2013 at 11:40 AM, Simon Kainz wrote: After inspecting avr-man, i see the line: exec man -M /usr/share/doc/avr-libc/man $@ But the path /usr/share/doc/avr-libc/man is not created by installing avr-libc nor is it by any other package. the manpages was moved there in version 1.8.0-4, currently in testing. I’m thus marking the bug as fixed there (so it would be archived when the current stable won’t be supported anymore.) In the version in stable they reside in /usr/lib/share/man/man3/ … However, I don’t seem to understand the choice of either location. Isn’t it customary to use /usr/share/man for everything in Debian, possibly adding appropriate suffixes to the filenames, as in: readline.3readline.gz, TIFFsize.3tiff.gz, Encode::Unicode.3perl.gz, and thus, presumably, floor.3avr.gz, random_r.3avr.gz, etc.? Going this way, there’s no need for any MANPATH tweaking, and even the manual page browsers that are not based on man(1) (such as Emacs’ woman.el) will just work “out of box.” -- FSF associate member #7257 -- Håkan Ardö -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Le samedi, 4 janvier 2014, 19.10:21 Josh Triplett a écrit : Dimitri John Ledkov wrote: Rejections on mailinglists and else where to split: /lib/systemd/systemd-multi-seat-x /lib/systemd/systemd-timedated /lib/systemd/systemd-localed /lib/systemd/systemd-logind /lib/systemd/systemd-hostnamed from systemd package to individual packages binary packages, or at least together but separate from systemd-init. Based on the most recent mailing list discussions, it sounds like the concern there is not whether to split but who will do the work of maintaining the patches needed to make these run without systemd, since there's no point in splitting them otherwise. I think splitting these in different binary packages would make some sense anyway, even without them being ready to work without systemd (given that the reverse is true; that systemd works without each of them): it would allow packages (functionally) depending on a particular systemd interface (such as -logind, or -hostnamed, etc) to (packaging- wise) depend on the exact packages providing these, bringing more granularity and clarity to the $package depends on systemd by expressing which interfaces are concretely needed for each package. ( Then, until these are made to work without systemd, they would of course depend on the systemd package. This would also only bring on people's systems the systemd sub-parts that are actually needed for their setup. ) What I don't know is whether systemd is ready (or can easily be made ready) to work without some of these services. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#734237: btrfs-tools: btrfs lockup with 3.12 RT kernel
control: retitle 734237 btrfs-tools lockup with 3.12 RT kernel Hi, Downgrading btrfs-tools:amd64 from 3.12-1 to 0.19+20130705-3 did not fix problem upon reboot with the same new linux-image-3.12-1-rt-amd64 kernel. Every lockup requires me to use power button to shutdown. So I checked more. Here are the results of these reboots and test runs of obnam: linux-imagebtrfs-tools:amd64 NG:,,-3.12-1-rt-amd64(3.12.6-2) (3.12-1) NG:,,-3.12-1-rt-amd64(3.12.6-2) (0.19+20130705-3) GOOD: ,,-3.11-2-amd64 (3.11.10-1) (0.19+20130705-3) GOOD: ,,-3.12-1-amd64 (3.12.6-2) (0.19+20130705-3) GOOD: ,,-3.12-1-amd64 (3.12.6-2) (3.12-1) NG means btrfs locked up when running obnam to backup. GOOD means btrfs is working fine even after running obnam to backup. So btrfs-tools may needs to be updated for RT version of 3.12 or the new RT kernel is buggy as it looks. For now, current btrfs-tools works with non-RT kernel 3.12 and that seems to be the easy workaround. (If you feel this is kernel 3.12 RT bug, please reassign.) FYI: I have /dev/sda* (SSD) ext4 for root filesystem etc. /dev/sdb1 (HDD) btrfs for /mnt/bckup/[@backup] 734237: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734237 Osamu $ mount |grep btrfs /dev/sdb1 on /mnt/backup_history type btrfs (rw,noatime,space_cache) /dev/sdb1 on /mnt/backup type btrfs (rw,noatime,space_cache) $ findmnt /mnt/backup TARGET SOURCE FSTYPE OPTIONS /mnt/backup /dev/sdb1[/@backup] btrfs rw,noatime,space_cache $ findmnt /mnt/backup_history TARGET SOURCEFSTYPE OPTIONS /mnt/backup_history /dev/sdb1 btrfs rw,noatime,space_cache $ mount |grep root /dev/mapper/goofy-root on / type ext4 (rw,noatime,discard,errors=remount-ro,commit=600,data=ordered) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733509: RFP: lubuntu-software-center -- Utility for browsing, installing, removing applications.
Bob Bib Well, it is Another light newbie-friendly app installer :P But in Debian I didn't find light (...) installers. Gnome-packagekit doesn't show icons (it is not a bug, it's feature), and software-center is not really light I testing Lubuntu-software-center od Debian Jessie and it works propertly on Debian Dependiences (dpkg install LSC and apt-get -f install) Without any problems, program works -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733966: Way forward
Given that the yui dependency is in a plugin (uicolor), I propose the following: - re-upload ckeditor without this plugin - file a bug upstream about migration to yui3 (mentioning CVE) Cheers -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726073: Bug#726116: Processed: Re: libcurl3-nss: tries to use libnsspem, which is not provided by libnss3
Hi Bastien, Bastien ROUCARIES wrote (04 Jan 2014 20:05:23 GMT) : I volontuer to package it Great! but I need mentoring (I am not a dd). I encourage you to clarify whether you need sponsoring only (someone checking and uploading packages you would prepare and take care of), or some sort of mentoring (someone who helps you learn to prepare and maintain good enough packages). I realize these areas are not disjoint, but making your needs clear is likely to help anyone, who considers satisfying them, know if they are in a position to do it properly :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734267: [Debian add-on] setting distribution only works when distro is known
Package: vim-common Version: 2:7.4.052-1 Severity: normal When I try to set the distribution via the Changelog menu in gvim, it fails when the head line looks like this: foo-pkg (0.7.25-1) UNRELEASED; urgency=low But it works when there is some known release branch like frozen instead of UNRELEASED. This looks like a regression, I remember having used this feature to change UNRELEASED many times in the last years. Regards, Eduard. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-rc6mini+ (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages vim-common depends on: ii libc6 2.17-97 Versions of packages vim-common recommends: ii vim2:7.4.052-1 ii vim-gtk [vim] 2:7.4.052-1 vim-common suggests no packages. -- no debconf information -- error compiling committee.c: too many arguments to function -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729713: libcups2: fails to fetch ppd of ipp:// device
Control: tags -1 +moreinfo Hi Lionel and Wolfgang, hi Till, thanks for your detailed bugreports and proposed patch. Le samedi, 16 novembre 2013, 05.34:09 Lionel Elie Mamane a écrit : Let FOO be a printer configured in CUPS with an ipp://foo.localdomain.tld/something device uri. Mine is a Konica Minolto C353. All cups clients fail to show printing options. lpoptions -d FOO -l says: lpoptions: Unable to get PPD file for FOO: Not Found A wireshark shows a request for http://device_ip:631/ipp.ppd, to which the printer replies by a 404. The attached patch disables that undesirable behaviour, which is new in 1.6 (did not happen in 1.5). Your proposed patch is functionally equivalent to disabling the get-ppd- file-for-statically-configured-ipp-shared-queues.patch , which was introduced in 1.6.1-1 as a backport from upstream's fix for http://cups.org/str.php?L4178 Till, as you wrote this patch, what do you think about this? Apparently, http://cups.org/str.php?L4159 was related to this problem and got solved differently in 1.6.2, and now cups/util.c appears to be redundant around this codeblock. Till, can we remove this patch on all versions 1.6.2 ? Le dimanche, 5 janvier 2014, 01.44:37 Wolfgang Walter a écrit : We modified libcups in the same way as Lionel. I don't know why this has been changed from 1.5 to 1.6 but it seems buggy. Most ipp-printers don't provide a PPD. And even if the do there is no guarantie the client is allowed to communicate directly with the printer. Lionel Wolfgang: can you try to rebuild and try unstable's cups (1.7.0-2) without the get-ppd-file-for-statically-configured-ipp-shared- queues patch and report back if this works as expected? Cheers, OdyX -- OdyX signature.asc Description: This is a digitally signed message part.
Bug#734244: testdisk (6.14-2) has unmet dependencies
On 05/01/14 07:41, Jos van Wolput wrote: When ntfs-3g version 1:2013.1.13AR.3-4 (experimental) is installed, testdisk (6.14-2) can't be installed because of unmet dependencies: apt-get install testdisk ntfs-3g Reading package lists... Done Building dependency tree Reading state information... Done ntfs-3g is already the newest version. Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: testdisk : Depends: libntfs-3g841 E: Unable to correct problems, you have held broken packages. Installing ntfs-3g 1:2013.1.13AR.1-2 (unstable) fixes this issue. Thanks for the report! This is caused by special handling of the libntfs-3g841 library in Debian, source package ntfs-3g. IMHO, this should be improved in ntfs-3g, since library handling in Debian is supposed to have a lib* binary package that can still be installed after a new ABI version is available. Having only ntfs-3g will always break things when new libntfs-3g* versions become available since only one of them is provided at a time by ntfs-3g. Therefore, reassigning to ntfs-3g. If this is intended, please just reassign back to testdisk and explain. AFAICS, the problem can't be solved in testdisk for the different experimental version of ntfs-3g, so we would need to wait for the new ntfs-3g in unstable at which point testdisk would need to be rebuilt against the new ABI. Thanks in advance, Roland -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726073: Bug#726116: Processed: Re: libcurl3-nss: tries to use libnsspem, which is not provided by libnss3
On Sat, Jan 4, 2014 at 10:31 PM, intrigeri intrig...@debian.org wrote: Hi Bastien, Bastien ROUCARIES wrote (04 Jan 2014 20:05:23 GMT) : I volontuer to package it Great! but I need mentoring (I am not a dd). I encourage you to clarify whether you need sponsoring only (someone checking and uploading packages you would prepare and take care of), or some sort of mentoring (someone who helps you learn to prepare and maintain good enough packages). I realize these areas are not disjoint, but making your needs clear is likely to help anyone, who considers satisfying them, know if they are in a position to do it properly :) I take every piece of advice needed. Nevertheless I suppose by maintaining imagemagick and patching lintian I am not a debutant. Bastien Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730856: transition: libtasn1-6
On 2014-01-05 12:11, Andreas Metzler wrote: On 2014-01-05 Niels Thykier ni...@thykier.net wrote: On 2013-11-30 11:59, Andreas Metzler wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I would like to finally (now that libimobiledevice builds again) get rid of libtasn1-3. This should a small painless transition, it will require sourceful uploads of 3 source packages which are up to date in testing. * gnutls26 * gcr * libimobiledevice All of these three can be built against libtasn1-6. [...] Sorry for the late responds. Why will it require a sourceful upload of these packages (rather than a binNMU) Hello, It is because we have libtasn1-3/libtasn1-3-dev/libtasn1-3-dbg/libtasn1-3-bin libtasn1-6/libtasn1-6-dev/libtasn1-6-dbg/libtasn1-bin (where the versioned -dev packages conflict) and the three abovementioned packages have dependencies in the generated binary packages on libtasn1-3-dev: ametzler@argenau:~/TIN/TASN$ grep-dctrl -FDepends libtasn1-3- -sPackage /chroots/sid/var/lib/apt/lists/ftp.at.debian.org_debian_dists_sid_main_binary-i386_Packages Package: libgcr-3-dev Package: libgnutls-dev Package: libimobiledevice-dev Once libgnutls-dev moves to libtasn1-6 it stops being co-installable with the other two mentioned packages. The reason why we have versioned conflicting -dev packages is that I needed to have both available in sid for an extended period of time. - libtasn1-6 has minor API breakage and the respective changes to gnutls26 were not eligible for wheezy freeze. Okay, would it be possible to use an unversioned -dev package from now on, so a future transition can be done with binNMUs (where API changes does not cause issues). What I did not mention before is that shishi will also need a sourceful upload, as it b-d on libtasn1-3-dev, but that can be done in a second step, as the binary package is stil installable after libgnutls-dev has switched to tasn1-6. Ok. ametzler@argenau:~/TIN/TASN$ grep-dctrl -FBuild-Depends libtasn1-3- -sPackage /chroots/sid/var/lib/apt/lists/ftp.at.debian.org_debian_dists_sid_main_source_Sources Package: gcr Package: gnome-keyring Package: gnutls26 Package: libimobiledevice Package: shishi and are the maintainers of the reverse dependencies ready to upload their packages? I am ready for gnutls. The other two packages have outstanding bug-reports - libimobiledevice 2013-12-08 http://bugs.debian.org/731707 - gcr 2013-07-08 http://bugs.debian.org/715354 sadly both without maintainer feedback yet. All three packages are up to date in testing. If you want me to I can obviously make libtasn1-3-dev/libtasn1-3-bin empty transitional packages built from libtasn1-6 which would limit the actual transition to binNMUs. cu Andreas That might be worth considering (at least the dev package). Is there any reason why the -bin package is also versioned? Are the libtasn1-X-bin binaries compatible with programs compiled against libtasn1-Y (or will mixing them explode)? ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734244: testdisk (6.14-2) has unmet dependencies
reassign 734244 testdisk thanks Roland Stigge wrote: If this is intended, please just reassign back to testdisk and explain. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700759 -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679162: Re: speech-dispatcher: No 'fancy' output init.d script
Control: tags -1 pending On 14-11-13 15:38, Dirk Sandbrink wrote: attached you find a patch for /etc/init.d/speech-dispatcher where the last two remaining echo commands have been replaced by appropriate lsb functions. If I read /usr/share/doc/lsb-base/README.Debian.gz I get the impression that log_success_msg is not the appropriate function (it also is no success. I rather use log_action_msg for the first item (although it is no action, but at least the info tag is correct). I believe the second item should only occur with manual usage and then the echo is still ok, so I rather leave that as is. Paul signature.asc Description: OpenPGP digital signature
Bug#729713: libcups2: fails to fetch ppd of ipp:// device
On 01/05/2014 12:45 PM, Didier 'OdyX' Raboud wrote: Control: tags -1 +moreinfo Hi Lionel and Wolfgang, hi Till, thanks for your detailed bugreports and proposed patch. Le samedi, 16 novembre 2013, 05.34:09 Lionel Elie Mamane a écrit : Let FOO be a printer configured in CUPS with an ipp://foo.localdomain.tld/something device uri. Mine is a Konica Minolto C353. All cups clients fail to show printing options. lpoptions -d FOO -l says: lpoptions: Unable to get PPD file for FOO: Not Found A wireshark shows a request for http://device_ip:631/ipp.ppd, to which the printer replies by a 404. The attached patch disables that undesirable behaviour, which is new in 1.6 (did not happen in 1.5). Your proposed patch is functionally equivalent to disabling the get-ppd- file-for-statically-configured-ipp-shared-queues.patch , which was introduced in 1.6.1-1 as a backport from upstream's fix for http://cups.org/str.php?L4178 Till, as you wrote this patch, what do you think about this? Apparently, http://cups.org/str.php?L4159 was related to this problem and got solved differently in 1.6.2, and now cups/util.c appears to be redundant around this codeblock. Till, can we remove this patch on all versions 1.6.2 ? Important is to check whether if you create a raw IPP queue pointing to a CUPS queue on a remote server that you get access to the options on the client (means that the client loads the PPD from the server). Please test this. You can test by creating an arbitrary print queue with PPD on one machine (the server) and sharing it. On another machine (the client) you either create a raw ipp: or ipps: queue pointing to the queue on the server or you run cups-browsed (which creates such a queue automatically). If you print out of a GUI app on the client using the ipp/ipps queue pointing to the CUPS server you should see the PPD options in the print dialog. You should also run lpoptions -p printer -l on the client and should see the options if printer is an ipp/ipps queue pointing to the server and no error message if printer is pointing to a native IPP printer. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734269: license of package is GPL and not LGPL
Package: qimhangul Severity: serious User: alteh...@debian.org Usertags: ftp X-Debbugs-CC: ftpmas...@ftp-master.debian.org thanks Dear Maintainer, according to debian/copyright the license of this software is LGPL-2.1+ According to the header in most of the files, the software is licensed under GPL-2+. Can you please update the information in debian/copyright? Thanks! Thorsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729713: libcups2: fails to fetch ppd of ipp:// device
Hi Till,
Le dimanche, 5 janvier 2014, 13.12:31 Till Kamppeter a écrit :
On 01/05/2014 12:45 PM, Didier 'OdyX' Raboud wrote:
Your proposed patch is functionally equivalent to disabling the
get-ppd- file-for-statically-configured-ipp-shared-queues.patch ,
which was introduced in 1.6.1-1 as a backport from upstream's fix
for http://cups.org/str.php?L4178
Till, as you wrote this patch, what do you think about this?
Apparently, http://cups.org/str.php?L4159 was related to this
problem
and got solved differently in 1.6.2, and now cups/util.c appears to
be redundant around this codeblock.
Till, can we remove this patch on all versions 1.6.2 ?
Important is to check whether if you create a raw IPP queue pointing
to a CUPS queue on a remote server that you get access to the options
on the client (means that the client loads the PPD from the server).
Please test this.
Actually, what I'm saying is that the patch adds a redundant block. See
the attached abstract from util.c. In my reading, lines 26 to 41 (added
by the patch) is redundant with lines 6 to 25 (upstream code).
From that, I tend to think the patch can be safely removed, no?
Cheers,
OdyX
if ((attr = ippFindAttribute(response, device-uri,
IPP_TAG_URI)) != NULL)
device_uri = attr-values[0].string.text;
if (device_uri
(!strncmp(device_uri, ipp://, 6) ||
!strncmp(device_uri, ipps://, 7) ||
((strstr(device_uri, ._ipp.) != NULL ||
strstr(device_uri, ._ipps.) != NULL)
!strcmp(device_uri + strlen(device_uri) - 5, /cups
{
/*
* Statically-configured shared printer.
*/
httpSeparateURI(HTTP_URI_CODING_ALL,
_httpResolveURI(device_uri, uri, sizeof(uri),
_HTTP_RESOLVE_DEFAULT, NULL, NULL),
scheme, sizeof(scheme), username, sizeof(username),
host, hostsize, port, resource, resourcesize);
ippDelete(response);
return (1);
}
else if (device_uri
(!strncmp(device_uri, ipp:, 4) != NULL ||
!strncmp(device_uri, ipps:, 5) != NULL))
{
/*
* Statically-configured IPP shared printer.
*/
httpSeparateURI(HTTP_URI_CODING_ALL,
device_uri,
scheme, sizeof(scheme), username, sizeof(username),
host, hostsize, port, resource, resourcesize);
ippDelete(response);
return (1);
}
else if ((attr = ippFindAttribute(response, member-uris,
IPP_TAG_URI)) != NULL)
{
/*
* Get the first actual printer name in the class...
*/
for (i = 0; i attr-num_values; i ++)
{
httpSeparateURI(HTTP_URI_CODING_ALL, attr-values[i].string.text,
scheme, sizeof(scheme), username, sizeof(username),
host, hostsize, port, resource, resourcesize);
if (!strncmp(resource, /printers/, 10))
{
signature.asc
Description: This is a digitally signed message part.
Bug#729713: libcups2: fails to fetch ppd of ipp:// device
On 01/05/2014 01:23 PM, Didier 'OdyX' Raboud wrote: Hi Till, Le dimanche, 5 janvier 2014, 13.12:31 Till Kamppeter a écrit : On 01/05/2014 12:45 PM, Didier 'OdyX' Raboud wrote: Your proposed patch is functionally equivalent to disabling the get-ppd- file-for-statically-configured-ipp-shared-queues.patch , which was introduced in 1.6.1-1 as a backport from upstream's fix for http://cups.org/str.php?L4178 Till, as you wrote this patch, what do you think about this? Apparently, http://cups.org/str.php?L4159 was related to this problem and got solved differently in 1.6.2, and now cups/util.c appears to be redundant around this codeblock. Till, can we remove this patch on all versions 1.6.2 ? Important is to check whether if you create a raw IPP queue pointing to a CUPS queue on a remote server that you get access to the options on the client (means that the client loads the PPD from the server). Please test this. Actually, what I'm saying is that the patch adds a redundant block. See the attached abstract from util.c. In my reading, lines 26 to 41 (added by the patch) is redundant with lines 6 to 25 (upstream code). From that, I tend to think the patch can be safely removed, no? Cheers, OdyX OK, you are right, patch can be removed. Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729765: fglrx-modules-dkms: fglrx module does not compile on recent x86 kernels
Unfortunately, the issue is still there. With version 1:13.12-2 I still get the same error output in /var/lib/dkms/fglrx/13.12/build/make.log as in my previous message. Cheers Ronny -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725714: Problem with firmware loading
Hi Heiko, On 05.01.2014 12:16, Heiko Ernst wrote: I have download the debian testing iso file from 05.01.20114. My laptop have a intel centrino 1000 wlan card. this card needs non-free firmware but the debian installer dont load the firmware from usb device. the usb device ist fromated with FAT and the firmware is on root. I have testing to load firmware with expert mode on the deian installer and then load firmware but the installer says : the failing step is: Load drivers from removable media. Sadly the firmware loading is currently broken in jessie/sid, see bug #725714 [1]. I hope this will get fixed soon. Best regards, Andreas 1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725714 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729713: libcups2: fails to fetch ppd of ipp:// device
On Sunday 05 January 2014 13:12:31 Till Kamppeter wrote: On 01/05/2014 12:45 PM, Didier 'OdyX' Raboud wrote: Control: tags -1 +moreinfo Hi Lionel and Wolfgang, hi Till, thanks for your detailed bugreports and proposed patch. Le samedi, 16 novembre 2013, 05.34:09 Lionel Elie Mamane a écrit : Let FOO be a printer configured in CUPS with an ipp://foo.localdomain.tld/something device uri. Mine is a Konica Minolto C353. All cups clients fail to show printing options. lpoptions -d FOO -l says: lpoptions: Unable to get PPD file for FOO: Not Found A wireshark shows a request for http://device_ip:631/ipp.ppd, to which the printer replies by a 404. The attached patch disables that undesirable behaviour, which is new in 1.6 (did not happen in 1.5). Your proposed patch is functionally equivalent to disabling the get-ppd- file-for-statically-configured-ipp-shared-queues.patch , which was introduced in 1.6.1-1 as a backport from upstream's fix for http://cups.org/str.php?L4178 Till, as you wrote this patch, what do you think about this? Apparently, http://cups.org/str.php?L4159 was related to this problem and got solved differently in 1.6.2, and now cups/util.c appears to be redundant around this codeblock. Till, can we remove this patch on all versions 1.6.2 ? Important is to check whether if you create a raw IPP queue pointing to a CUPS queue on a remote server that you get access to the options on the client (means that the client loads the PPD from the server). Please test this. You can test by creating an arbitrary print queue with PPD on one machine (the server) and sharing it. On another machine (the client) you either create a raw ipp: or ipps: queue pointing to the queue on the server or you run cups-browsed (which creates such a queue automatically). If you print out of a GUI app on the client using the ipp/ipps queue pointing to the CUPS server you should see the PPD options in the print dialog. You should also run lpoptions -p printer -l on the client and should see the options if printer is an ipp/ipps queue pointing to the server and no error message if printer is pointing to a native IPP printer. Till We do not have a cups-server running on the client. Our configuration is: client: only /etc/cups/client.conf with ServerName cups.localdomain.tld. On the print server cups.localdomain.tld. we have a lot of printers in printers.conf like that Printer Mehltau AuthInfoRequired none Info Mehltau Location Rosenstraße MakeModel MyFavoritePostscripPrinterModel DeviceURI ipp://mehltau.drucker.localdomain.tld/ipp State Idle StateTime 1387541234 Type 8425548 Filter application/vnd.cups-raw 0 - Filter application/vnd.cups-command 0 commandtops Filter application/vnd.cups-postscript 0 - Accepting Yes Shared Yes JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 OpPolicy default ErrorPolicy abort-job /Printer We do not wan't to mehltau to be a raw-printer as the printer server should e.g. handle pdfs etc. This setting breaks with cups 1.6. as now the client contacts cups.localdomain.tld but then tries to get the ppd from mehltau.drucker.localdomain.tld instead from cups.localdomain.tld But mehltau.drucker.localdomain.tld is a ipp postscript printer (e.g. from HP or any other vendor) and does not provide ppds (and in our case the client is not even allowed to communicate with Mehltau directly). Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729713: libcups2: fails to fetch ppd of ipp:// device
On 01/05/2014 01:36 PM, Wolfgang Walter wrote: On Sunday 05 January 2014 13:12:31 Till Kamppeter wrote: On 01/05/2014 12:45 PM, Didier 'OdyX' Raboud wrote: Control: tags -1 +moreinfo Hi Lionel and Wolfgang, hi Till, thanks for your detailed bugreports and proposed patch. Le samedi, 16 novembre 2013, 05.34:09 Lionel Elie Mamane a écrit : Let FOO be a printer configured in CUPS with an ipp://foo.localdomain.tld/something device uri. Mine is a Konica Minolto C353. All cups clients fail to show printing options. lpoptions -d FOO -l says: lpoptions: Unable to get PPD file for FOO: Not Found A wireshark shows a request for http://device_ip:631/ipp.ppd, to which the printer replies by a 404. The attached patch disables that undesirable behaviour, which is new in 1.6 (did not happen in 1.5). Your proposed patch is functionally equivalent to disabling the get-ppd- file-for-statically-configured-ipp-shared-queues.patch , which was introduced in 1.6.1-1 as a backport from upstream's fix for http://cups.org/str.php?L4178 Till, as you wrote this patch, what do you think about this? Apparently, http://cups.org/str.php?L4159 was related to this problem and got solved differently in 1.6.2, and now cups/util.c appears to be redundant around this codeblock. Till, can we remove this patch on all versions 1.6.2 ? Important is to check whether if you create a raw IPP queue pointing to a CUPS queue on a remote server that you get access to the options on the client (means that the client loads the PPD from the server). Please test this. You can test by creating an arbitrary print queue with PPD on one machine (the server) and sharing it. On another machine (the client) you either create a raw ipp: or ipps: queue pointing to the queue on the server or you run cups-browsed (which creates such a queue automatically). If you print out of a GUI app on the client using the ipp/ipps queue pointing to the CUPS server you should see the PPD options in the print dialog. You should also run lpoptions -p printer -l on the client and should see the options if printer is an ipp/ipps queue pointing to the server and no error message if printer is pointing to a native IPP printer. Till We do not have a cups-server running on the client. Our configuration is: client: only /etc/cups/client.conf with ServerName cups.localdomain.tld. On the print server cups.localdomain.tld. we have a lot of printers in printers.conf like that Printer Mehltau AuthInfoRequired none Info Mehltau Location Rosenstraße MakeModel MyFavoritePostscripPrinterModel DeviceURI ipp://mehltau.drucker.localdomain.tld/ipp State Idle StateTime 1387541234 Type 8425548 Filter application/vnd.cups-raw 0 - Filter application/vnd.cups-command 0 commandtops Filter application/vnd.cups-postscript 0 - Accepting Yes Shared Yes JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 OpPolicy default ErrorPolicy abort-job /Printer We do not wan't to mehltau to be a raw-printer as the printer server should e.g. handle pdfs etc. This setting breaks with cups 1.6. as now the client contacts cups.localdomain.tld but then tries to get the ppd from mehltau.drucker.localdomain.tld instead from cups.localdomain.tld But mehltau.drucker.localdomain.tld is a ipp postscript printer (e.g. from HP or any other vendor) and does not provide ppds (and in our case the client is not even allowed to communicate with Mehltau directly). Regards, My patch did httpSeparateURI(HTTP_URI_CODING_ALL, device_uri, scheme, sizeof(scheme), username,sizeof(username), host, hostsize, port, resource, resourcesize); whereas the final fix does httpSeparateURI(HTTP_URI_CODING_ALL, _httpResolveURI(device_uri, uri, sizeof(uri), _HTTP_RESOLVE_DEFAULT, NULL,NULL), scheme, sizeof(scheme), username,sizeof(username), host, hostsize, port, resource, resourcesize); Can it be that the _httpResolveURI() causes some problem here? Till -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731064: [Debichem-devel] Bug#731064: libpwiz: FTBFS on ia64 mips mipsel s390x
tag 731064 + fixed pending thanks Greetings, Aurélien and Julien. Thanks for helping in this matter. I have successfully rebuilt the package using the patch provided by Aurélien. I have also sent an email to upstream asking to check to which extent they still need to include the boost_aux convenience source code in the source tarball. Anyhow, I'll upload the package real soon now, *closing* this bug. If it is not advisable to do so, please tell. Thanks again. Ciao Filippo On Mon, Dec 30, 2013 at 12:07:08AM +0100, Aurelien Jarno wrote: tag 731064 + patch thanks On Sun, Dec 01, 2013 at 03:53:50PM +0100, Julien Cristau wrote: Source: libpwiz Version: 3.0.4624-4 Severity: serious Justification: fails to build from source Hi, your package fails to build on some architectures, see the build logs at https://buildd.debian.org/status/logs.php?pkg=libpwizver=3.0.4624-4suite=sid The problem is that libpwiz sources contains boost_aux, which have been partly integrated into recent version of boost. In the build failure case here, the atomic version in boost is slightly different, so mixing the two versions causes failure depending on how the atomics are implemented on the architecture. The patch below remove the atomic part of boost_aux, so that the one from boost is used instead. This way of doing also means we libpwiz will benefit from improvement from boost, especially the ones from boost 1.55 which implement atomics for all architectures, using the new gcc atomic builtins. With this patch libpwiz builds fine on at least amd64, s390x and mips. diff -Nru libpwiz-3.0.4624/debian/rules libpwiz-3.0.4624/debian/rules --- libpwiz-3.0.4624/debian/rules 2013-12-09 10:27:44.0 + +++ libpwiz-3.0.4624/debian/rules 2013-12-29 19:24:46.0 + @@ -82,6 +82,10 @@ # software in a separate build directory. cp -rpf autotools libraries pwiz pwiz_tools $(BUILD_DIR) + # Remove parts of boost_aux now integrated in boost + rm $(BUILD_DIR)/libraries/boost_aux/boost/atomic.hpp + rm -r $(BUILD_DIR)/libraries/boost_aux/boost/atomic + cd $(BUILD_DIR) autotools/configure --prefix=/usr \ VERBOSE=1 $(MAKE) \ VERBOSE=1 DESTDIR=$(INSTALL_DIR) $(MAKE) install -- Filippo Rusconi, PhD - public crypto key C78F687C @ pgp.mit.edu Researcher at CNRS and Debian Developer lopi...@debian.org Author of ``massXpert'' at http://www.massxpert.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614994: Ltrace Bug analysis
On Fri, Jan 03, 2014 at 02:38:48PM -0500, sri...@marirs.net.in wrote: /tmp$ ltrace -f -o /dev/null ./x ltrace: Can't open ELF file ./x [...] But if the program is run like this below, it works fine. $ ltrace -f -o /dev/null bash x $ ltrace -f -o /dev/null sh x Guess this is a wrong bug report filed No, it is a genuine bug. ltrace should see if the first characters of the file are #! and execute and trace the correct interpreter for the file. Thank you for your comment, -- Juan Cespedes Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730856: transition: libtasn1-6
On 2014-01-05 Niels Thykier ni...@thykier.net wrote:
On 2014-01-05 12:11, Andreas Metzler wrote:
[...]
The reason why we have versioned conflicting -dev packages is that I
needed to have both available in sid for an extended period of time. -
libtasn1-6 has minor API breakage and the respective changes to
gnutls26 were not eligible for wheezy freeze.
Okay, would it be possible to use an unversioned -dev package from now
on, so a future transition can be done with binNMUs (where API changes
does not cause issues).
Hello,
I would rather not introduce new binary packages now (going through
NEW) but can keep it in mind for the next soname bump, not that I
expect one soonish.
[...]
If you want me to I can obviously make libtasn1-3-dev/libtasn1-3-bin
empty transitional packages built from libtasn1-6 which would limit
the actual transition to binNMUs.
That might be worth considering (at least the dev package).
See attached proposed patch.
Is there
any reason why the -bin package is also versioned? Are the
libtasn1-X-bin binaries compatible with programs compiled against
libtasn1-Y (or will mixing them explode)?
The new -bin package is already unversioned (libtasn1-bin instead of
libtasn1-6-bin).
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
diff --git a/debian/control b/debian/control
index ca209aa..5ad6d3e 100644
--- a/debian/control
+++ b/debian/control
@@ -72,7 +72,7 @@ Priority: extra
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Replaces: libtasn1-3-bin
-Breaks: libtasn1-3-bin
+Breaks: libtasn1-3-bin ( 3)
Multi-Arch: foreign
Description: Manage ASN.1 structures (binaries)
Manage ASN1 (Abstract Syntax Notation One) structures.
@@ -86,3 +86,21 @@ Description: Manage ASN.1 structures (binaries)
.
This package contains programs to encode, decode and parse asn1 data
structures.
+
+Package: libtasn1-3-dev
+Section: oldlibs
+Priority: extra
+Architecture: all
+Depends: libtasn1-6-dev (= ${source:Version}), ${misc:Depends}
+Description: transitional libtasn1-3-dev package
+ This is a transitional dummy package to ease the migration from
+ libtasn1-3-dev to libtasn1-6-dev. You can safely remove this package.
+
+Package: libtasn1-3-bin
+Section: oldlibs
+Priority: extra
+Architecture: all
+Depends: libtasn1-bin (= ${source:Version}), ${misc:Depends}
+Description: transitional libtasn1-3-bin package
+ This is a transitional dummy package to ease the migration from
+ libtasn1-3-bin to libtasn1-bin. You can safely remove this package.
signature.asc
Description: Digital signature
Bug#732191: perl-base: separately packaged XS modules can break system upgrades
On Sun, Dec 15, 2013 at 04:59:02PM +0200, Niko Tyni wrote:
(I've cloned #721364 to track the more general problem as a separate
bug, #732191.)
On Tue, Dec 10, 2013 at 09:00:19PM +0100, gregor herrmann wrote:
On Sat, 31 Aug 2013 18:30:25 +0300, Niko Tyni wrote:
I think we need to remove libscalar-list-utils-perl altogether.
I'll file a separate bug on that soon.
Next one: CPAN-Meta 2.133380 now wants List::Util: 1.33 (which is in
core in 5.19.5).
I see that's for the new function List::Util::all(). It's unfortunate
that we've ended up with a still evolving interface in perl-base.
I see short and long term solutions.
A. carry on without List::Util 1.33, patch CPAN-Meta to not use the new
functionality before it gets in the Perl core
* this burden may grow in the future as more modules need patching
B. bundle List::Util 1.33 in perl-base
* what's the right thing to do with Module::Corelist ?
C. make the separate version install its files somewhere outside
the default @INC and make CPAN-Meta look there
* tempting but far from elegant
(D. add fallback pure Perl versions to all the XS functions as a Debian patch
* keeping these up to date would be a permanent burden)
I had a brief discussion with Brendan O'Dea about this, and he had a
couple of ideas:
1. Include a new /usr/{share,lib}/perl-base/ver directory pair early in
@INC
(before vendor), and install the perl-base modules there. This would
enforce
the policy of disallowing the packaging of modules in base by effectively
ignoring them.
2. A slight amendment to the above is also possible, but would require non-
trivial changes to potentially lots of maintainer scripts. The idea
being
that the /usr/bin/perl binary would have the perl-base directories
*after*
vendor in @INC, but there would additionally be a /usr/bin/perl-base in
the
perl-base package which *only* included the perl-base directories in
@INC.
This second option might well be a better option in the long term, as it
would
catch packages which were using perl incorrectly in maintainer script
(e.g. depending on modules which may not be available) but would
unfortunately
mean changes to potentially lots of maintainer scripts. A lintian check
could
probably look for maintainer scripts using perl in #! and explicit uses of
perl -e.
I think the /usr/bin/perl-base idea feels right, but it's a lot of work
and I'm not sure how feasible it is. I suppose postinst scripts can be
excluded. How about dpkg triggered actions?
At the very least, it would mean a wait of one release cycle before
the maintainer scripts could start relying on /usr/bin/perl-base in
all situations.
I'd welcome opinions and thoughts about this so we can decide if
we want to do it for jessie.
For the short term, I'd lean towards patching CPAN-Meta, perhaps to
use List::MoreUtils::all() from liblist-moreutils-perl instead. We can
revisit including the newer Scalar-List-Utils in perl-base once there
are more modules needing them.
Agreed - I don't think we need a heavyweight solution whilst the problem
only manifests in one place. I've uploaded a patched version of CPAN-Meta
now.
Cheers,
Dominic.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614994: Ltrace Bug analysis
Hi Juan Cespedes, Was learning ltrace, tried a few bugs on the debian bugs list. #614994 [n| | ] [ltrace] ltrace: Doesn't understand scripts with #! lines == /tmp$ cat x #!/bin/sh echo Hello /tmp$ ./x Hello /tmp$ strace -f -o /dev/null ./x Hello /tmp$ ltrace -f -o /dev/null ./x ltrace: Can't open ELF file ./x - Josh Triplett == The above is the snippet from the bug report log. If bash script is run like ./script_name only bash is understands and starts interpreting it as a script. other-wise the filesystem see's it as a collection of ASCII text. $ file x x: ASCII text And from the source code, === if (lte-elf == NULL || elf_kind(lte-elf) != ELF_K_ELF) /* is true*/ error(EXIT_FAILURE, 0, Can't open ELF file \%s\, filename); === But if the program is run like this below, it works fine. $ ltrace -f -o /dev/null bash x $ ltrace -f -o /dev/null sh x Guess this is a wrong bug report filed #606026 [i| | ] [ltrace] handle_event.c:565: handle_breakpoint: Assertion `sbp' failed. == This bug is not reproducible with the latest changes. But not closed yet. Verified it with the following packages. ii libc6:amd642.17-97 amd64Embedded GNU C Library: Shared li ii ltrace 0.5.3-2.1amd64Tracks runtime library calls in d ii libelfg0-dev 0.8.13-5 amd64an ELF object file access library M still a student, mistakes are possible in whatever mentioned above. Will learn from them, and Hope this helps. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733458: gajim: Additional dependency needed for sound playback
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, if it finds none of the players, it will cat the sound file to /dev/dsp (i.e., use OSS). I don't know what that does on systems without OSS - I do have osspd installed, so this actually works (but it results in clipping). Kind regards Ralf On 04/01/14 22:24, Tanguy Ortolo wrote: Ralf Jung, 2013-12-29 00:30+0100: to properly play notification sounds, gajim needs either aplay, play or ossplay. So the package should depend on either of these. Also see https://trac.gajim.org/ticket/7608. Correct, I shall add these dependencies. But do you know what Gajim does when none of them are available? Unless it always crash, I think I will add these as Recommends rather than Depends, since sound notification is only a secondary feature of Gajim, not a core one I think: without sound, its basic functionnality, which is XMPP chat, is still available. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSyVZpAAoJEEAdTZ0mjB1W0OgH/1Tp/RKt4zBckLUhTG4gRZfJ NuBuqOuJmbalGiEgQUz4lTbkBKqLc4WhleE3RvJd50deUQEgXBz/lrkeEpExlnLJ A80l69jw60sXf86o1RrFLYwtqe4JjRWAfTYmRicRK+TlF3bwEyT8ldB0tcgTRknZ asiAxak7HQOl78iHzEsremWwXmFIugnrh6Sv+sVgsSp6xBJ+LjoPjz4Zr1OpX15O vJn0G1s9v2yiY9Wf62+I0egOYzoPGlNV+bIVtIPbZWMqSAz6v7TTj3eTA0Tlu5U1 3EVef00gqWTczP1+UEs9UkYpaZCNhfS4hyZsQfTWoVFPnFCsWsjx2W5JyhmR8/M= =boY0 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#184979: base-passwd: patch to prompt with debconf
On Fri, Jan 03, 2014 at 11:57:42AM -0800, Russ Allbery wrote:
Here's a patch to teach update-passwd how to use debconf for
prompting.
Thanks! I have a number of review comments below, but in general I'm
happy with the approach taken here and will be happy to merge it after a
few fixes. I very much appreciate your work here.
* I'm not particularly proud of the code layout and repetition,
particularly how changes to user information are handled.
Unfortunately, this sort of thing is exactly what C is the worst
at, and the only alternative I came up with would have involved
passing a ton of parameters to a bunch of specialist functions.
Indeed. It's not ideal, but it's not as though update-passwd.c was a
model of clarity to begin with.
* I spot-tested this patch and ran through a few obvious scenarios,
but I didn't do exhaustive testing. It's possible that there are
some fiddly bugs remaining in some of the specific cases of data
changes for users.
I'll go through all the cases in detail once this is otherwise ready to
merge. Nothing jumped out at me upon skim-reading the code in question,
at least.
* This patch converts postinst to use debconf unconditionally. This
is more an artifact of how I tested it than an intentional decision.
Given that base-passwd is an essential package, I suspect there are
special considerations, but I've not done much work with essential
packages before. I was hoping you'd sort out the right thing. :)
Let me know if you need for me to make changes.
Yes, this will need a bit more work. Borrowing the approach from
libc6's postinst, I think the form should be:
# near top of postinst
if [ -f /usr/share/debconf/confmodule ]; then
. /usr/share/debconf/confmodule
fi
# later
if [ -f /usr/share/debconf/confmodule ]; then
# debconf style
else
# traditional style; maybe unset DEBIAN_HAS_FRONTEND for safety
fi
You could keep on redirecting update-passwd --dry-run's output to a
tempfile, and then just put the old cat/askyesno code in the else
branch.
(A long time ago, Santiago reported in #102395 that base-passwd may not
need to be Essential after all, but I have been very conservative about
changing anything here just in case ...)
Some additional changes that are unrelated, and therefore I didn't
include in this patch, but which I'd recommend making:
* Now that there's an xasprintf function, you may want to use it in
the few places where you're currently using asprintf. This would
also get rid of some build warnings.
* Since this is a native package and you're already running
dh_autoreconf, I would recommend just deleting configure and
config.h.in from the package.
I agree with both of these; I'd be happy to make these changes after we
land your patch (well, I might do the latter beforehand).
+if ! update-passwd --dry-run /dev/null ; then
+ . /usr/share/debconf/confmodule
In addition to my earlier comments, it's specifically inadvisable to
source /usr/share/debconf/confmodule anywhere other than very near the
top of a script, since it may re-exec the sourcing script. (libc6's
postinst is not the best example here, although in that case I think it
is only inefficient and a timebomb for future developers rather than
actually incorrect; in this case it appears to leak a tempfile.)
+ db_stop
db_stop doesn't generally do quite what people want; it's only necessary
at all when the script also starts a daemon, and it can have some weird
side-effects. You can probably just drop this.
diff --git a/debian/templates b/debian/templates
new file mode 100644
index 000..1185b05
--- /dev/null
+++ b/debian/templates
@@ -0,0 +1,229 @@
+Template: base-passwd/user-move
+Type: boolean
+Default: false
I'd be inclined to make the Default value for all these templates true
rather than false; it seems like a more reasonable default to ensure
that things are synced up with the master files, especially since these
questions are asked any time we change the master files regardless of
whether there are local customisations, and you're generally asking
things at medium so most users won't have the opportunity to answer yes
to these questions.
+_Description: Do you want to move the user ${name}?
+ update-passwd has found a difference between your system accounts and the
+ current Debian defaults. It is advisable to allow update-passwd to
+ change your system; without those changes some packages might not work
+ correctly. For more documentation on the Debian account policies please
+ see /usr/share/doc/base-passwd/README.
Nit: I think I'd prefer a comma before please here and in the other
similar templates.
+ Move user ${name} (${id}) to before the + entry
I wonder if it's worth saying something about NIS compat in this and in
base-passwd/group-move; not that this is original to your patch, but
it's worth thinking about since these strings will be translated.
---
Bug#726073: Processed: Re: libcurl3-nss: tries to use libnsspem, which is not provided by libnss3
On sab, gen 04, 2014 at 09:05:23 +0100, Bastien ROUCARIES wrote:
On Sat, Dec 28, 2013 at 2:09 PM, Alessandro Ghedini gh...@debian.org wrote:
On ven, dic 27, 2013 at 11:24:11 +, Debian Bug Tracking System wrote:
Processing commands for cont...@bugs.debian.org:
affects 726073 + git src:git
Bug #726073 [libcurl3-nss] libcurl3-nss: tries to use libnsspem, which is
not provided by libnss3
Added indication that 726073 affects git and src:git
Care to explain how this affects git, considering that it uses
libcurl3-gnutls?
Also, there's not much I can do about this (except maybe dropping
libcurl3-nss
altogether), and since we have #726116 tracking this now, I'm inclined to
close
this report.
Btw, Bastien ROUCARIES (CCed) mentioned something about what looks like the
libnsspem.so we are interested in [0] (that is [1]), though I'm afraid it'll
need NSS maintainers support to get packaged. Bastien, do you have any news
about this?
I volontuer to package it, but I need mentoring (I am not a dd).
That much I understood :) but, I just tried to build nss-pem and it seems to
require parts of libnss build system and some of its internal headers, so, do
you plan to maintain it as a separate package? If so, how?
I'd also be interested in sponsoring you, but I see Jonathan already beat me to
it.
Cheers
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
signature.asc
Description: Digital signature
Bug#734270: maint-guide: track dpkg-buildpackage default behavior
Package: maint-guide Version: 1.2.32 Severity: normal This is remonder to myself for upcoming dpkg-buildpackge default behavior change. -us -uc will be the default. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733029 https://lists.debian.org/debian-devel/2013/12/msg00590.html Osamu -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash maint-guide depends on no packages. maint-guide recommends no packages. Versions of packages maint-guide suggests: ii debian-policy 3.9.5.0 ii developers-reference 3.4.11 ii devscripts2.13.9 ii dh-make 0.63 ii doc-base 0.10.5 ii dput 0.9.6.4 ii fakeroot 1.20-3 ii lintian 2.5.20 ii pbuilder 0.215 ii quilt 0.61-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694941: Please provide an option to list all available input methods
Hi guys and sorry for not getting back sooner... On 2013-05-19 01:29, Osamu Aoki wrote: Hi, Now that freeze is over, let's think this change of -l option. On Mon, Dec 17, 2012 at 08:42:57AM +0100, Gunnar Hjalmarsson wrote: I decided to give the code reuse idea a shot, and the result is the attached patch. It's not much that can be done, really. Better than the first patch? I'm not sure. In my quick glange, it looks basically fine. Please let us talk about the third variant I submitted: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=im-config-installed-IMs-3.patch;att=1;bug=694941 It does the same thing, but the code is slightly neater. But before applying this, let's discuss the use case of this patch. Is this output used by external script? - some gui tools which try to set im-config via non interactive -n option. Yes, that's what the Language Support GUI in Ubuntu does. This is the function in the Language Support source that makes use of the -l option: def getAvailableInputMethods(self): inputMethods = subprocess.check_output(['im-config', '-l']).decode().split() return ['default'] + sorted(inputMethods) So the list presented to the user consists of: - default (i.e. auto mode) - xim (but it's labelled 'none' in the GUI) - the installed input method systems Maybe we need to expose priority, install state of required package, ... Not sure what you mean by that. But I can say that I think the current -l option serves the needs of Ubuntu. -- Gunnar Hjalmarsson https://launchpad.net/~gunnarhj -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)
On Sunday 05 January 2014 11:58:07 Didier 'OdyX' Raboud wrote: Le samedi, 4 janvier 2014, 19.54:05 Stefano Rivera a écrit : Hi Jonathan (2014.01.02_19:22:33_+0200) * having to support remote signing It would be fair enough to stderr not supported, please use the older tool in devscripts and error 1 if such an argument was provided. That would be pragmatic if (as I suspect) -r is rarely used. Aww. I'm a frequent user of -r. I have better places to build big packages than on my lap, and I prefer to keep my GPG key in as few places as possible. I concur. I build my packages on a server's sbuild and then debsign -r from my laptop, then dput from the server. Please keep this workflow possible with in-archive tools. Indeed, my case here too. -r is crucial for my workflow :-/ -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#734093: debian-installer: install plymouth by default
Hi, On 05.01.2014 11:51, Julien Cristau wrote: On Sun, Jan 5, 2014 at 08:29:24 +0100, Christian PERRIER wrote: OK, then. Reassigning to tasksel (as we should have done for quite a while, indeed It is probably best to include plymouth in tasksel, but still the installer would have to recognize, if plymouth is installed, and then add 'splash' to the kernel command line. Apart from that, I have no strong advice about this. A nice and appealing (one taste may vary) boot screen for desktop computers can be seen as something to have by some people but others may hate that. Therefore I think plymouth should only be recommended by task-desktop. I think that, at least, if plymouth is included in task-desktop, we should be certain that a Debian theme is cooked for it in a consistent manner with Debian themes for desktop environments. Currently this would be the joy theme [1]. I think plymouth would have to be maintained in unstable, not just in experimental, before tasksel should touch it. Daniel, can you upload the experimental version to unstable, or are there problems with this version? Best regards, Andreas 1: https://wiki.debian.org/DebianArt/Themes/Joy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734271: segfaults (often, but not always) after resume
Package: xserver-xorg
Version: 1:7.7+5
Severity: important
Dear Maintainer,
Since recently, Xorg often (but not always) segfaults when I suspend
my system, and resume it after several hours. This is the end of my
previous Xorg.0.log:
[...]
[161771.140] (II) NVIDIA(GPU-0): Display (Samsung SyncMaster (CRT-0)) does
not support NVIDIA
[161771.140] (II) NVIDIA(GPU-0): 3D Vision stereo.
[161771.140] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the EDID
for display
[161771.140] (**) NVIDIA(0): device Samsung SyncMaster (CRT-0) (Using
EDID frequencies
[161771.140] (**) NVIDIA(0): has been enabled on all display devices.)
[161771.320] (II) NVIDIA(GPU-0): Display (Samsung SyncMaster (CRT-0)) does
not support NVIDIA
[161771.320] (II) NVIDIA(GPU-0): 3D Vision stereo.
[161771.320] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the EDID
for display
[161771.320] (**) NVIDIA(0): device Samsung SyncMaster (CRT-0) (Using
EDID frequencies
[161771.320] (**) NVIDIA(0): has been enabled on all display devices.)
[225553.215] (II) Open ACPI successful (/var/run/acpid.socket)
[225560.627] (II) NVIDIA(0): Setting mode VGA-0: nvidia-auto-select
@1280x1024 +0+0 {ViewPortIn=1280x1024, ViewPortOut=1280x1024+0+0}
[225560.687] (EE) NVIDIA(0): Failed to allocate primary buffer: out of memory.
[225560.687] (EE) NVIDIA(0): *** Aborting ***
[225560.865] (II) NVIDIA(GPU-0): Display (Samsung SyncMaster (CRT-0)) does
not support NVIDIA
[225560.865] (II) NVIDIA(GPU-0): 3D Vision stereo.
[225560.865] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the EDID
for display
[225560.865] (**) NVIDIA(0): device Samsung SyncMaster (CRT-0) (Using
EDID frequencies
[225560.865] (**) NVIDIA(0): has been enabled on all display devices.)
[225560.890] (EE)
[225560.890] (EE) Backtrace:
[225561.027] (EE) 0: /usr/bin/Xorg (xorg_backtrace+0x3d) [0x7f8adf2eeccd]
[225561.032] (EE) 1: /usr/bin/Xorg (0x7f8adf14d000+0x1a5a29) [0x7f8adf2f2a29]
[225561.032] (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f8ade24c000+0xf210) [0x7f8ade25b210]
[225561.032] (EE) 3: /usr/lib/xorg/modules/drivers/nvidia_drv.so
(0x7f8ad7e25000+0x87066) [0x7f8ad7eac066]
[225561.033] (EE) 4: /usr/lib/xorg/modules/drivers/nvidia_drv.so
(0x7f8ad7e25000+0x4e3ce5) [0x7f8ad8308ce5]
[225561.033] (EE) 5: /usr/lib/xorg/modules/drivers/nvidia_drv.so
(0x7f8ad7e25000+0x4e90c4) [0x7f8ad830e0c4]
[225561.033] (EE) 6: /usr/lib/xorg/modules/drivers/nvidia_drv.so
(0x7f8ad7e25000+0x4f5ae2) [0x7f8ad831aae2]
[225561.033] (EE) 7: /usr/bin/Xorg (xf86Wakeup+0x55a) [0x7f8adf1df72a]
[225561.033] (EE) 8: /usr/bin/Xorg (WakeupHandler+0x6d) [0x7f8adf1a61fd]
[225561.033] (EE) 9: /usr/bin/Xorg (WaitForSomething+0x1af) [0x7f8adf2ec27f]
[225561.033] (EE) 10: /usr/bin/Xorg (0x7f8adf14d000+0x54d61) [0x7f8adf1a1d61]
[225561.033] (EE) 11: /usr/bin/Xorg (0x7f8adf14d000+0x4455a) [0x7f8adf19155a]
[225561.033] (EE) 12: /lib/x86_64-linux-gnu/libc.so.6
(__libc_start_main+0xf5) [0x7f8adcea3995]
[225561.033] (EE) 13: /usr/bin/Xorg (0x7f8adf14d000+0x4489f) [0x7f8adf19189f]
[225561.033] (EE)
[225561.033] (EE) Segmentation fault at address 0x25
[225561.034] (EE)
Fatal server error:
[225561.034] (EE) Caught signal 11 (Segmentation fault). Server aborting
[225561.034] (EE)
[225561.034] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[225561.034] (EE) Please also check the log file at /var/log/Xorg.0.log for
additional information.
[225561.034] (EE)
[225561.160] (EE) Server terminated with error (1). Closing log file.
Cheers,
--
Stéphane
-- Package-specific info:
X server symlink status:
lrwxrwxrwx 1 root root 13 Feb 22 2009 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 2290064 Dec 13 11:14 /usr/bin/Xorg
Diversions concerning libGL are in place
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by
glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so to
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by
Bug#734273: sphinxtrain: FTBFS on big endian: Bad use of SWAP_LE_32()
Package: sphinxtrain
Version: 1.0.8-1
Severity: important
Tags: patch
User: debian-powerpc...@breakpoint.cc
Usertags: powerpcspe
Hi,
on big endian architectures (powerpc, powerpcspe, ppc64, s390x, sparc),
sphinxtrain FTBFS like this:
...
Making all in mk_s2sendump
make[4]: Entering directory `/«PKGBUILDDIR»/src/programs/mk_s2sendump'
gcc -DPACKAGE_NAME=\SphinxTrain\ -DPACKAGE_TARNAME=\sphinxtrain\
-DPACKAGE_VERSION=\1.0.8\ -DPACKAGE_STRING=\SphinxTrain\ 1.0.8\
-DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -DWORDS_BIGENDIAN=1
-DHAVE_LIBM=1 -I. -I../../../include -I/usr/include/powerpc-linux-gnuspe
-I/usr/include/powerpc-linux-gnuspe/sphinxbase-g -O2 -c mk_s2sendump.c
mk_s2sendump.c: In function 'fwrite_int32':
mk_s2sendump.c:85:5: error: invalid type argument of unary '*' (have 'int32')
mk_s2sendump.c:85:5: error: invalid type argument of unary '*' (have 'int32')
mk_s2sendump.c:85:5: error: invalid type argument of unary '*' (have 'int32')
mk_s2sendump.c:85:5: error: invalid type argument of unary '*' (have 'int32')
mk_s2sendump.c:85:5: error: invalid type argument of unary '*' (have 'int32')
make[4]: *** [mk_s2sendump.o] Error 1
make[4]: Leaving directory `/«PKGBUILDDIR»/src/programs/mk_s2sendump'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/«PKGBUILDDIR»/src/programs'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/«PKGBUILDDIR»/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»'
dh_auto_build: make -j1 returned exit code 2
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
...
This is due to wrong (probably untested) use of SWAP_LE_32() conditionally
defined to be returning identity on little endian. However, on big endian
arches, it requires the pointer to the object, not the object itself. The
attached patch fixes this.
Roland
-- System Information:
Debian Release: 7.0
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: powerpcspe (ppc)
Kernel: Linux 3.9.0-dirty (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Index: sphinxtrain-1.0.8/src/programs/mk_s2sendump/mk_s2sendump.c
===
--- sphinxtrain-1.0.8.orig/src/programs/mk_s2sendump/mk_s2sendump.c 2014-01-05 14:25:43.0 +0100
+++ sphinxtrain-1.0.8/src/programs/mk_s2sendump/mk_s2sendump.c 2014-01-05 14:25:43.0 +0100
@@ -82,7 +82,7 @@
static void fwrite_int32 (FILE *fp, int32 val)
{
-SWAP_LE_32(val);
+SWAP_LE_32(val);
fwrite (val, sizeof(int), 1, fp);
}
Bug#734272: sweethome3d-furniture-editor: Fails while saving a new library
Package: sweethome3d-furniture-editor Version: 1.12-1 Severity: important Dear Maintainer, 1. run the program 2. load any piece of fourniture 3. try to save the new library and you get (and no saving is done): ~$ sweethome3d-furniture-editor java.lang.NoClassDefFoundError: com/eteks/sweethome3d/io/DefaultFurnitureCatalog at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:788) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:447) at java.net.URLClassLoader.access$100(URLClassLoader.java:71) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at com.eteks.furniturelibraryeditor.io.FurnitureLibraryFileRecorder.readFurnitureLibrary(Unknown Source) at com.eteks.furniturelibraryeditor.io.FurnitureLibraryFileRecorder.readFurnitureLibrary(Unknown Source) at com.eteks.furniturelibraryeditor.viewcontroller.EditorController$3.call(Unknown Source) at com.eteks.furniturelibraryeditor.viewcontroller.EditorController$3.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at com.eteks.sweethome3d.viewcontroller.ThreadedTaskController$1.run(Unknown Source) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) Caused by: java.lang.ClassNotFoundException: com.eteks.sweethome3d.io.DefaultFurnitureCatalog at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 25 more 4. the .jar that can be downloaded from the project works as expected -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.10-2-amd64 (SMP w/2 CPU cores) Locale: LANG=ca_ES.utf8, LC_CTYPE=ca_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages sweethome3d-furniture-editor depends on: ii default-jre 1:1.7-49 ii icedtea-netx-common 1.4.1-1 ii java-wrappers0.1.27 ii java3ds-fileloader 1.2+dfsg-1 ii libbatik-java1.7+dfsg-4 ii libjava3d-java 1.5.2+dfsg-9 ii libvecmath-java 1.5.2-4 sweethome3d-furniture-editor recommends no packages. sweethome3d-furniture-editor suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734274: project-history: Fix dead links to Debian counting site and typo
Package: project-history Severity: normal Tags: patch Dear Maintainer, the attached patch fixes two dead links in the text about Potato, namely http://libresoft.es/debian-counting/potato/index.php?menu=Statistics http://libresoft.es/debian-counting/ while the current links seem to be http://debian-counting.libresoft.es/potato/ http://debian-counting.libresoft.es/ The same line contains a typo: s/statitics/statistics/ -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.11-2-686-pae (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Index: project-history.sgml === --- project-history.sgml (revisione 10351) +++ project-history.sgml (copia locale) @@ -659,7 +659,7 @@ pAn interesting fact about Debian 2.2 is that it showed how an free software effort could lead to a modern operating system despite all the issues around it. This was studiedfootnotepThe -url id=http://libresoft.es/debian-counting/potato/index.php?menu=Statistics; name=raw statitics data for Potato are also available at url id=http://libresoft.es/debian-counting/; name=Debian counting site, as well +url id=http://debian-counting.libresoft.es/potato/; name=raw statistics data for Potato are also available at url id=http://debian-counting.libresoft.es/; name=Debian counting site, as well as papers analysing later releases./p/footnote thoroughly by a group of interested people in an article called url
Bug#727708: init system discussion status
Le dimanche 05 janvier 2014 à 01:37 +, Dimitri John Ledkov a écrit : Patching upstream unit files to change paths is trivial, but even better would be to convince upstream to substitute in the proper path when building the unit file. Oh that indeed would be wonderful, why did systemd upstream advocate for hardcoded paths in so many projects then, instead of atleast runtime detected?! How is this suppose to work with 3rd party recompiled packages and e.g. installed in opt? previously just adding opt to PATH, or droppings things into /usr/local/, enabled to use custom compiled ad-hoc replacements as desired by deployments. blah.service.in: ExecStart=@bindir@/blah --no-fork How complicated is that? -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734275: systemd: After thad remove follow directory from $HOME directory .cache .config .dbus
Package: systemd Version: 204-5 Severity: normal Remove alls content from /var/lib/gdm3 and restart -- Package-specific info: -- systemd-delta: -- 0 overridden configuration files found. -- Contents of /var/lib/systemd/deb-systemd-helper-enabled: -- == /var/lib/systemd/deb-systemd-helper-enabled/atd.service.dsh-also == /etc/systemd/system/multi-user.target.wants/atd.service == /var/lib/systemd/deb-systemd-helper-enabled/anacron.service.dsh-also == /etc/systemd/system/multi-user.target.wants/anacron.service == /var/lib/systemd/deb-systemd-helper-enabled/graphical.target.wants/accounts-daemon.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/atd.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/avahi-daemon.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/anacron.service == == /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/rsyslog.service == == /var/lib/systemd/deb-systemd-helper-enabled/syslog.service == == /var/lib/systemd/deb-systemd-helper-enabled/dbus-org.freedesktop.Avahi.service == == /var/lib/systemd/deb-systemd-helper-enabled/avahi-daemon.socket.dsh-also == /etc/systemd/system/sockets.target.wants/avahi-daemon.socket == /var/lib/systemd/deb-systemd-helper-enabled/accounts-daemon.service.dsh-also == /etc/systemd/system/graphical.target.wants/accounts-daemon.service == /var/lib/systemd/deb-systemd-helper-enabled/rsyslog.service.dsh-also == /etc/systemd/system/multi-user.target.wants/rsyslog.service /etc/systemd/system/syslog.service == /var/lib/systemd/deb-systemd-helper-enabled/avahi-daemon.service.dsh-also == /etc/systemd/system/multi-user.target.wants/avahi-daemon.service /etc/systemd/system/sockets.target.wants/avahi-daemon.socket /etc/systemd/system/dbus-org.freedesktop.Avahi.service == /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/avahi-daemon.socket == -- System Information: Debian Release: jessie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii initscripts 2.88dsf-43 ii libacl1 2.2.52-1 ii libaudit11:2.3.2-2 ii libc62.17-97 ii libcap2 1:2.22-1.2 ii libcryptsetup4 2:1.6.1-1 ii libdbus-1-3 1.6.18-2 ii libgcrypt11 1.5.3-3 ii libkmod2 9-3 ii liblzma5 5.1.1alpha+20120614-2 ii libpam0g 1.1.3-9 ii libselinux1 2.2.1-1 ii libsystemd-daemon0 204-5 ii libsystemd-journal0 204-5 ii libsystemd-login0204-5 ii libudev1 204-5 ii libwrap0 7.6.q-24 ii udev 204-5 ii util-linux 2.20.1-5.5 Versions of packages systemd recommends: ii libpam-systemd 204-5 Versions of packages systemd suggests: ii systemd-ui 2-2 -- Configuration Files: /etc/dbus-1/system.d/org.freedesktop.systemd1.conf [Errno 2] No such file or directory: u'/etc/dbus-1/system.d/org.freedesktop.systemd1.conf' /etc/systemd/logind.conf changed: [Login] NAutoVTs=6 ReserveVT=6 ResetControllers=cpu InhibitDelayMaxSec=5 /etc/systemd/system.conf changed: [Manager] CPUAffinity=1 2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, Jan 05, 2014 at 03:00:05PM +0900, Charles Plessy wrote: Hi Charles, + sect1 id=debian-menu + headingThe Debian menu system/heading + + p + The Debian menu unifies the menu systems of window managers. In + some desktop environments such as emGNOME/em and emKDE/em, + it has been superseded by the FreeDesktop menu and is hidden by + default. + /p You can add Xfce to the list. Regards, - -- Yves-Alexis Perez -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCgAGBQJSyWQ6AAoJEG3bU/KmdcClu/QIAKdFcoQSPtswsotH4Je1TPGI phzOYs3sy/Cn0vHkAnYioY73wUsKEY2hS5VP0viL3FIxGSp6yjDMcJgssPfqkk42 1N7X6wh00hZGpHSvjEinG91y0f7U5v5EqqhBR3D7l1Ppy+soFz3Dhwr8Zl/s20st 7szhIC9D/zmNWUaUYtiLzth8GtaClMzR0FszGQcasEh+WzjLoKNop4fSpySjY7oW bgs73erLh7+1FPKuAGlywj+UhFHxqiyJ75QYzXzxnAk013QrvSQL+eduwQRbiNLp fKPxaXXgpuyAGeyTluXP3gQWeLg4UdxBT72UA8kQeaCUFQr75+gTmanxQhbn7Qo= =8qc+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734276: [otrs2] Non free file
Package: otrs2 Severity: serious X-Debbugs-cc: ftpmas...@debian.org var/package seems not the prefered form of modification (base64 encoded file) They are a few fla (flash file) under your tree also. Bastien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734277: php5-cgi: Fatal Error Unable to allocate shared memory segment of XXX bytes: mmap: Cannot allocate memory (12)
Package: php5-cgi Version: 5.5.7+dfsg-2 Severity: important Dear Maintainer, I can't run cron.php from Magento. I can't run ./geoipUpdateRows.php from Piwik. http://piwik.org/faq/how-to/#faq_167 When I run the PHP script, it die with like the following: root@s15879177:/var/www/tools/piwik/misc/others# php-cgi ./geoipUpdateRows.php Sun Jan 5 15:01:06 2014 (2332): Fatal Error Unable to allocate shared memory segment of 67108864 bytes: mmap: Cannot allocate memory (12) This problem it's new from php-cgi 5.?.?. I don't remember the exact version number. -- Package-specific info: Additional PHP 5 information PHP 5 SAPI (php5query -S): cgi PHP 5 Extensions (php5query -M -v): pdo (Enabled for cgi by maintainer script) opcache (Enabled for cgi by maintainer script) xsl (Enabled for cgi by maintainer script) mcrypt (Enabled for cgi by maintainer script) gd (Enabled for cgi by maintainer script) tidy (Enabled for cgi by maintainer script) curl (Enabled for cgi by maintainer script) mysqlnd (Enabled for cgi by maintainer script) mysql (Enabled for cgi by maintainer script) mysqli (Enabled for cgi by maintainer script) pdo_mysql (Enabled for cgi by maintainer script) json (Enabled for cgi by maintainer script) Configuration files: [PHP] engine = On short_open_tag = Off asp_tags = Off precision = 14 output_buffering = 4096 zlib.output_compression = Off implicit_flush = Off unserialize_callback_func = serialize_precision = 17 disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority, disable_classes = zend.enable_gc = On expose_php = On max_execution_time = 30 max_input_time = 60 memory_limit = 128M error_reporting = E_ALL ~E_DEPRECATED ~E_STRICT display_errors = Off display_startup_errors = Off log_errors = On log_errors_max_len = 1024 ignore_repeated_errors = Off ignore_repeated_source = Off report_memleaks = On track_errors = Off html_errors = On variables_order = GPCS request_order = GP register_argc_argv = Off auto_globals_jit = On post_max_size = 8M auto_prepend_file = auto_append_file = default_mimetype = text/html doc_root = user_dir = enable_dl = Off file_uploads = On upload_max_filesize = 2M max_file_uploads = 20 allow_url_fopen = On allow_url_include = Off default_socket_timeout = 60 [CLI Server] cli_server.color = On [Date] [filter] [iconv] [intl] [sqlite] [sqlite3] [Pcre] [Pdo] [Pdo_mysql] pdo_mysql.cache_size = 2000 pdo_mysql.default_socket= [Phar] [mail function] SMTP = localhost smtp_port = 25 mail.add_x_header = On [SQL] sql.safe_mode = Off [ODBC] odbc.allow_persistent = On odbc.check_persistent = On odbc.max_persistent = -1 odbc.max_links = -1 odbc.defaultlrl = 4096 odbc.defaultbinmode = 1 [Interbase] ibase.allow_persistent = 1 ibase.max_persistent = -1 ibase.max_links = -1 ibase.timestampformat = %Y-%m-%d %H:%M:%S ibase.dateformat = %Y-%m-%d ibase.timeformat = %H:%M:%S [MySQL] mysql.allow_local_infile = On mysql.allow_persistent = On mysql.cache_size = 2000 mysql.max_persistent = -1 mysql.max_links = -1 mysql.default_port = mysql.default_socket = mysql.default_host = mysql.default_user = mysql.default_password = mysql.connect_timeout = 60 mysql.trace_mode = Off [MySQLi] mysqli.max_persistent = -1 mysqli.allow_persistent = On mysqli.max_links = -1 mysqli.cache_size = 2000 mysqli.default_port = 3306 mysqli.default_socket = mysqli.default_host = mysqli.default_user = mysqli.default_pw = mysqli.reconnect = Off [mysqlnd] mysqlnd.collect_statistics = On mysqlnd.collect_memory_statistics = Off [OCI8] [PostgreSQL] pgsql.allow_persistent = On pgsql.auto_reset_persistent = Off pgsql.max_persistent = -1 pgsql.max_links = -1 pgsql.ignore_notice = 0 pgsql.log_notice = 0 [Sybase-CT] sybct.allow_persistent = On sybct.max_persistent = -1 sybct.max_links = -1 sybct.min_server_severity = 10 sybct.min_client_severity = 10 [bcmath] bcmath.scale = 0 [browscap] [Session] session.save_handler = files session.use_strict_mode = 0 session.use_cookies = 1 session.use_only_cookies = 1 session.name = PHPSESSID session.auto_start = 0 session.cookie_lifetime = 0 session.cookie_path = / session.cookie_domain = session.cookie_httponly = session.serialize_handler = php session.gc_probability = 0 session.gc_divisor = 1000 session.gc_maxlifetime = 1440 session.bug_compat_42 = Off session.bug_compat_warn = Off session.referer_check = session.cache_limiter = nocache session.cache_expire = 180 session.use_trans_sid = 0 session.hash_function = 0 session.hash_bits_per_character = 5 url_rewriter.tags = a=href,area=href,frame=src,input=src,form=fakeentry [MSSQL] mssql.allow_persistent = On mssql.max_persistent = -1 mssql.max_links = -1 mssql.min_error_severity = 10 mssql.min_message_severity = 10
Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)
On Thu, 2014-01-02 at 17:22:33 +, Jonathan Dowland wrote: You raise some very valid points and §I appreciate your concerns and perhaps should rephrase my request so that I'm suggesting subsuming the most common used features of debsign and perhaps as part of a staged migration (compat symlink to debsign binary name in the phase 1, real name dpkg-sign or whatever), to try and avoid further complicating the debian package development universe. On Thu, Jan 02, 2014 at 11:03:04AM +0100, Guillem Jover wrote: IMO having debsign become a thiner wrapper around this new tool would be the goal, as it would simplify its code, (Obviously, assuming devscripts maintainers would agree, I was just inferring from previous interactions regarding debuild for example; in any case what happens with debsign would be their decision entirely.) people not wanting to use debsign could use the dpkg tool directly, and people not wanting to learn new stuff could keep using the wrapper w/o regressions. That would not address the concern I raise: the surface area of debian package development tools would continue to grow, meaning people would use the non-recommended tool if they did not know better (or relied on documentation which had not been updated). Honestly, I've been struggling a bit trying to understand this concern, because to me that reads as suggesting no new features, command-line options or tools should be added (to dpkg or devscripts or similar packages), to avoid increasing the packaging tools surface area, when in this case usage of this tool would be completely optional, and might make life easier for some people. I don't see either the problem of using one or the other, or one being more recommended than the other. If a new tool would get added to dpkg every second week, then I could see it, but not with the current pace. If it was just a “hey, please consider creating a single interfaces that can cover all current usages, and drop the old one if possible”, sure I'm all for integrating back stuff that has been developed or prototyped elsewhere, and trying to end up with a single interface by deprecating the old interface if necessary. In this case though, I think debsign (and debuild, and other similar wrappers) add value, and have features that I don't see fit in dpkg proper, or might serve as future playground to try out new stuff that could get merged back too. So in this case I don't see its deprecation as desirable (but again that's something for the devscripts maintainers to decide). [1] haven't checked whether they, in turn, rely on debsign. They do, as well as many tools that need to control the signing process, some mentioned in this thread. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733077: fonts-roboto: new upstream release of Roboto (1.2)
BTW with this new version now I got Thin that looks like Light, and Regular looks like Black. fc-query on those fonts to found the cause: style: Thin fullname: Roboto Thin weight: 50 style: Light fullname: Roboto Light weight: 50 style: Regular fullname: Roboto Regular weight: 80 style: Black fullname: Roboto Black weight: 80 Different styles but equal weights. I fixed the weights according to fontconfig standards with 80-roboto.conf and it works. Here's the file: ?xml version=1.0? !DOCTYPE fontconfig SYSTEM fonts.dtd fontconfig !-- Fix Roboto v1.2 weights -- match target=scan test name=fullname compare=eq stringRoboto Thin/string /test edit name=weight mode=assign int0/int /edit /match match target=scan test name=fullname compare=eq stringRoboto Thin Italic/string /test edit name=weight mode=assign int0/int /edit /match match target=scan test name=fullname compare=eq stringRoboto Black/string /test edit name=weight mode=assign int210/int /edit /match match target=scan test name=fullname compare=eq stringRoboto Black Italic/string /test edit name=weight mode=assign int210/int /edit /match /fontconfig 2014/1/5 BubuXP bub...@gmail.com: Fabian Greffrath wrote: Do you know if these fonts are part of Android 4.4.2? If yes, they could get upgraded to that version by merely upgrading the src:fonts-android package. I checked here: https://android.googlesource.com/platform/frameworks/base/+/android-4.4.2_r1/data/fonts/ and it is the same version of the .zip download (1.2), except that here Medium and Black variants aren't present. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734278: pocketsphinx: FTBFS on big endian architectures
Source: pocketsphinx Version: 0.8-3 Severity: normal Tags: patch User: debian-powerpc...@breakpoint.cc Usertags: powerpcspe Hi, pocketsphinx FTBFS on all big endian architectures: ... Error: Internal data flow error. FAIL: fgets(line, sizeof(line), fh) FAIL: test_gst make[4]: *** [check-TESTS] Error 1 ... Basically, same issue as #734215, with Ub*ntu already excluding big endian arch for some while. Possible fix in Debian via debian/rules: ifneq (,$(filter $(shell dpkg-architecture -qDEB_HOST_ARCH),mips powerpc powerpcspe ppc64 s390x sparc sparc64)) override_dh_auto_test: # disabled endif Roland -- System Information: Debian Release: 7.0 APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: powerpcspe (ppc) Kernel: Linux 3.9.0-dirty (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734279: jblas: FTBFS on most architectures since tests are enabled at build time
Source: jblas Version: 1.2.0-5 Severity: serious Hi, jblas FTBFS on most architectures since tests are enabled in 1.2.0-5. E.g., on powerpc: ... test: [junit] Running org.jblas.TestBlasDoubleComplex [junit] Testsuite: org.jblas.TestBlasDoubleComplex [junit] Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.049 sec [junit] Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.049 sec [junit] [junit] Testcase: testZCOPY took 0.021 sec [junit] Caused an ERROR [junit] Couldn't find the resource libjblas_arch_flavor.so. [junit] java.lang.UnsatisfiedLinkError: Couldn't find the resource libjblas_arch_flavor.so. [junit] at org.jblas.util.LibraryLoader.loadLibrary(LibraryLoader.java:94) [junit] at org.jblas.util.ArchFlavor.clinit(ArchFlavor.java:50) [junit] at org.jblas.util.LibraryLoader.loadLibrary(LibraryLoader.java:75) [junit] at org.jblas.NativeBlas.clinit(NativeBlas.java:84) [junit] at org.jblas.TestBlasDoubleComplex.testZCOPY(TestBlasDoubleComplex.java:45) [junit] [junit] Testcase: testZDOTU took 0 sec [junit] Caused an ERROR [junit] Could not initialize class org.jblas.NativeBlas [junit] java.lang.NoClassDefFoundError: Could not initialize class org.jblas.NativeBlas [junit] at org.jblas.TestBlasDoubleComplex.testZDOTU(TestBlasDoubleComplex.java:55) [junit] [junit] Testcase: testAxpy took 0.003 sec [junit] Caused an ERROR [junit] Could not initialize class org.jblas.NativeBlas [junit] java.lang.NoClassDefFoundError: Could not initialize class org.jblas.NativeBlas [junit] at org.jblas.TestBlasDoubleComplex.testAxpy(TestBlasDoubleComplex.java:65) [junit] BUILD FAILED /«PKGBUILDDIR»/build.xml:246: Test org.jblas.TestBlasDoubleComplex failed Total time: 34 seconds make: *** [debian/stamp-ant-check] Error 1 ... Roland -- System Information: Debian Release: 7.0 APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: powerpcspe (ppc) Kernel: Linux 3.9.0-dirty (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.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#734280: [lintian] Detect prebuilt source
Package: lintian Version: 2.5.20 Severity: normal Detect prebuilt binary: paultag aye paultag that'd be really nice paultag really really nice paultag same with fla, swf, etc paultag .min.js paultag uh, .pyc paultag .o, .a, .so, .out paultag : taffit .*… paultag hahaha pabs paultag: yeah contrib is fine for even .exe :) paultag right, back to documentation : pabs don't forget .pyo :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734233: apt-listbugs: Unable to start, debian_version load error
Package: apt-listbugs Version: 0.1.12 Followup-For: Bug #734233 Same problem. Upgrading to ruby 1.9 solved for me. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable-updates'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.11.10-mio (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apt-listbugs depends on: ii apt 0.9.14.2 ii ruby 1:1.9.3 ii ruby-debian 0.3.8+b2 ii ruby-gettext 3.0.3-1 ii ruby-httpclient 2.3.3-2 ii ruby-soap4r 2.0.5-2 ii ruby-xmlparser0.7.2-2 ii ruby1.9.1 [ruby-interpreter] 1.9.3.484-1 apt-listbugs recommends no packages. Versions of packages apt-listbugs suggests: ii chromium [www-browser] 31.0.1650.63-1 ii debianutils 4.4 ii elinks [www-browser] 0.12~pre6-4 ii konqueror [www-browser] 4:4.11.3-1 ii rekonq [www-browser] 0.9.2-1 ii reportbug6.4.4 ii w3m [www-browser]0.5.3-15 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734281: dgit: Poor error reporting for SSH access
Package: dgit Version: 0.20 Severity: normal When attempting to clone a package (having never used dgit before) I get: | $ dgit clone xemacs | Permission denied (publickey). | 65280 at /usr/bin/dgit line 679. This is very obscure; it doesn't provide information on what it was trying to do so doesn't give any hint as to what the problem is other than a reference to the source which is not as obvious as it might be. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dgit depends on: ii curl 7.34.0-1 ii devscripts 2.13.9 ii dpkg-dev 1.17.5 ii dput 0.9.6.4 ii git [git-core] 1:1.8.5.2-1 ii libdpkg-perl 1.17.5 ii libwww-perl6.05-2 ii perl [libdigest-sha-perl] 5.18.1-5 ii realpath 1.19 ii wget 1.14-5 Versions of packages dgit recommends: ii openssh-client [ssh-client] 1:6.4p1-2 Versions of packages dgit suggests: pn sbuild none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734282: ITP: linop -- Linear mathematical operators in Python
Package: wnpp Severity: wishlist Owner: Ghislain Vaillant ghisv...@gmail.com * Package name: linop Version : 0.8 Upstream Author : Ghislain Vaillant ghisv...@gmail.com * URL : https://pypi.python.org/pypi/linop * License : BSD Programming Lang: Python Description : Linear mathematical operators in Python Linop is a library providing a set of classes for abstracting the concept of linear operators to be used for development of various mathematical frameworks. Linop allows you to define a simple operator based on its shape, data type, forward and (optionally) adjoint transformations, or to stack a bunch of existing operators in blocks. Using linop, one can write a complicated series of functions in mathematically readable forms such as y = A.T * A * x or D = A * B + C. The library is written in Python and supports both Python 2 and 3. There is an extensive documentation for it available at http://pythonhosted.org//linop. This package should be maintained by the Debian Science Team. A preliminary version will soon be made available at http://anonscm.debian.org/gitweb/?p=debian-science/packages/linop.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734283: openrc: missing dependency on insserv (causes endless loops at shutdown and read-only root fs at boot)
Package: openrc
Severity: important
Version: 0.12.4+20131230-3
Hi,
[Writing this report from another machine, hence no meta data at the
end]
I've installed a Xen DomU with xen-tools 4.4 and xen-create-image
--dist sid --dhcp --pygrub --noaccounts --role minimal [some
host-specific parameters like disk size, memory size, hostname and
mirror settings].
--role minimal causes (beyond other things I wanted) busybox-syslogd
instead of rsyslog to be installed.
On the machine I then installed openrc, called the command being told
while openrc was set up (c.f. http://thomas.goirand.fr/blog/?p=153). It
only seemed to shutdown busybox-syslogd and then rebooted the box.
ssh didn't come up on boot, so I started it manually. Then I replaced
busybox-syslogd with rsyslog to get persistent syslogs.
apt-get suggested to remove insserv, as it was installed automatically,
so I purged it.
Then I tried to reboot the virtual machine with reboot.
While the ssh session where I typed reboot is still there, hence, the
system hasn't rebooted yet, I endlessly get the following messages on
the console, despite they rather look like bootup sequence than a
shutdown sequence (don't know where the start of the loop is, so I took
a random line as start):
[…]
[ ok ] Cleaning up temporary files
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
Usage: /lib/rc/sh/gendepends.sh start|stop
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
Usage: /etc/init.d/networking {start|stop|reload|restart|force-reload}
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
Usage: /etc/init.d/procps {start|stop|restart|reload|force-reload|status}
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
* Caching service dependencies ...
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
/lib/rc/sh/gendepends.sh: 91: /lib/rc/sh/gendepends.sh: shell_var: not found
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
/lib/rc/sh/gendepends.sh: 91: /lib/rc/sh/gendepends.sh: shell_var: not found
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
[ ok ] Activating lvm and md swap...done.
[] Checking file systems...fsck from util-linux 2.20.1
done.
/lib/rc/sh/gendepends.sh: 91: /lib/rc/sh/gendepends.sh: shell_var: not found
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
[ ok ] Cleaning up temporary files... /tmp /run /run/lock /run/shm.
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
[ ok ] Activating swap...done.
mount: you must specify the filesystem type
[FAIL] Cannot check root file system because it is not mounted read-only. ...
failed!
[ 2552.694335] EXT4-fs (xvda2): re-mounted. Opts: errors=remount-ro
/lib/rc/sh/gendepends.sh: 91: /lib/rc/sh/gendepends.sh: shell_var: not found
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
[info] Usage: /etc/init.d/cron {start|stop|status|restart|reload|force-reload}.
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
Usage: /lib/rc/sh/gendepends.sh start|stop
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
[ ok ] Usage: hwclock.sh {start|stop|reload|force-reload|show}.
[ ok ] start sets kernel (system) clock from hardware (RTC) clock.
[ ok ] stop and reload set hardware (RTC) clock from kernel (system) clock.
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
Usage: /lib/rc/sh/gendepends.sh start|stop
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
[ ok ] Usage: /lib/rc/sh/gendepends.sh start.
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
/lib/rc/sh/gendepends.sh: 91: /lib/rc/sh/gendepends.sh: shell_var: not found
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
[ ok ] Cleaning up temporary files
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
[ ok ] Mounting local filesystems...done.
[ ok ] Activating swapfile swap...done.
/lib/rc/sh/gendepends.sh: 91: /lib/rc/sh/gendepends.sh: shell_var: not found
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
Warning: mountdevsubfs should be called with the 'start' argument.
/lib/rc/sh/gendepends.sh: 91: /lib/rc/sh/gendepends.sh: shell_var: not found
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
Warning: mountkernfs should be called with the 'start' argument.
/lib/rc/sh/gendepends.sh: 91: /lib/rc/sh/gendepends.sh: shell_var: not found
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
[ ok ] Cleaning up temporary files
[…]
At least the following line suggests that there may be a hard dependency
on insserv missing:
error: unable to read /etc/insserv.conf at /lib/rc/bin/lsb.pl line 19.
On the still
Bug#727708: init system discussion status
Hello, On Sat, 04 Jan 2014 16:46:28 +0100 Josselin Mouette j...@debian.org wrote: I think systemd-ui is part of the systemd init system so falls into the exception. Of course that means that nothing else should depend (functionally or in package dependencies) on it. There is no way that, for example, some of the GNOME control center applets will work at all without systemd. Last time I tried GNOME 3 it worked without any systemd components at all. It is already hard enough to imagine that we would have to ship packages without the appropriate dependencies on systemd; expecting them to have the same functional coverage without it is simply insane. There's no bloody way it's true, claiming anything like that is actually insanity. -- Cheers, Andrew signature.asc Description: PGP signature
Bug#734284: git: mojibake in gitweb serving raw blobs
Package: git
Version: 1:1.7.10.4-1+wheezy1
Severity: normal
Tags: patch
Hi *,
gitweb uses p5-CGI which, according to its perldoc, defaults
to latin1 if no charset is given. This causes mojibake:
$ env GATEWAY_INTERFACE=CGI/1.1 REQUEST_METHOD=GET \
REQUEST_URI=/gitweb/ SERVER_PROTOCOL=HTTP/1.0 \
QUERY_STRING='p=verein;a=blob_plain;f=projects/assorted/skolelinux-neujahrstreffen-2014.md;hb=HEAD'
\
/usr/share/gitweb/index.cgi | head
Content-disposition: inline;
filename=projects/assorted/skolelinux-neujahrstreffen-2014.md
Content-Type: text/plain; charset=ISO-8859-1
Skolelinux-Neujahrstreffen 2014
[…]
The file itself contains correct UTF-8 plaintext (no encoding
errors in it) and is served octet-correct, but the HTTP response
header wrongly indicates latin1 encoding for it.
The correct fix here is to prevent p5-CGI from adding any charset
if none was already given (e.g. via guess_mimetype). Patch attached.
I’ve checked git 1:1.8.5.2-1 (sid), and it has the same bug.
-- System Information:
Debian Release: 7.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages git depends on:
ii git-man 1:1.7.10.4-1+wheezy1
ii libc62.13-38
ii libcurl3-gnutls 7.26.0-1+wheezy7
ii liberror-perl0.17-1
ii libexpat12.1.0-1+deb7u1
ii perl-modules 5.14.2-21+deb7u1
ii zlib1g 1:1.2.7.dfsg-13
Versions of packages git recommends:
ii less 444-4
ii openssh-client [ssh-client] 1:6.0p1-4
ii patch2.6.1-3
ii rsync3.0.9-4
Versions of packages git suggests:
ii gettext-base 0.18.1.1-9
pn git-arch none
pn git-cvs none
pn git-daemon-run | git-daemon-sysvinit none
pn git-doc none
pn git-elnone
pn git-email none
pn git-gui none
pn git-svn none
pn gitk none
ii gitweb1:1.7.10.4-1+wheezy1
-- no debconf information
--- /usr/share/gitweb/index.cgi 2012-11-24 08:03:07.0 +0100
+++ index.cgi 2014-01-05 16:26:34.049017232 +0100
@@ -6752,6 +6752,7 @@ sub git_blob_plain {
print $cgi-header(
-type = $type,
+ -charset = '',
-expires = $expires,
-content_disposition =
($sandbox ? 'attachment' : 'inline')
Bug#734275: [Pkg-systemd-maintainers] Bug#734275: systemd: After thad remove follow directory from $HOME directory .cache .config .dbus
Hi Marian, Marian corcodel.mar...@gmail.com writes: Remove alls content from /var/lib/gdm3 and restart I don’t get what you are trying to say. Can you be more verbose please? -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729765: [Pkg-fglrx-devel] Bug#729765: fglrx-modules-dkms: fglrx module does not compile on recent x86 kernels
On Sun, Jan 5, 2014 at 7:33 AM, Ronny Standtke wrote: Unfortunately, the issue is still there. With version 1:13.12-2 I still get the same error output in /var/lib/dkms/fglrx/13.12/build/make.log as in my previous message. Would you mind trying the linux 3.12 kernel? That is in jessie now and at least works for me. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734233: apt-listbugs: Unable to start, debian_version load error
On Sun, Jan 5, 2014 at 5:02 PM, Francesco Poli invernom...@paranoici.org wrote: I think the problem may be that you are still using ruby1.8 as Ruby interpreter, while package ruby-debian has been recently rebuilt (version 0.3.8+b2) with support for ruby1.9.1 and ruby2.0, dropping support for ruby1.8 (there's a transition going on to remove ruby1.8 from Debian)... Please switch to Ruby 1.9: installing package ruby1.9.1 should suffice (it should automatically set itself as the default Ruby interpreter and the command ruby -v should print ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux]). Please let me know whether this fixes the issue. Yes, it does. Thanks. I install the 'ruby' dependency package instead, to get the current default (ruby1.9.1), and apt-listbugs gets back to work again. Do you think declaring Break: against ruby1.8 a good idea? (Whether apt-listbugs or ruby-debian should do this is beyond my knowledge.) Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734233: apt-listbugs: Unable to start, debian_version load error
On Sun, 05 Jan 2014 15:39:46 +0100 Samuele Battarra wrote: [...] Same problem. Upgrading to ruby 1.9 solved for me. Hello Samuele, thanks a lot for your feedback. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpT_R8ypPPnG.pgp Description: PGP signature
Bug#733692: O: genisovh -- Make CD-ROMs bootable for SGI MIPS machines
Hi, On Tue, Dec 31, 2013 at 03:44:00AM +0100, Axel Beckert wrote: Package: wnpp Severity: normal Thiemo Seufer, the maintainer of the genisovh package, unfortunately died in 2008[1]. [1] http://www.debian.org/News/2008/20081229 Therefore I declare the genisovh package orphaned. If you want to be the new maintainer, please take it. See http://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about the package: Package: genisovh Version: 0.1-3 Installed-Size: 20 Depends: libc6 (= 2.3.2.ds1-4) Description: Make CD-ROMs bootable for SGI MIPS machines Genisovh creates a Disk Volume Header (dvh) on a CD image and records bootable images therein. This allows the SGI firmware to boot those images without needing knowledge about the filesystem on the CD image. Tag: admin::boot, hardware::storage, hardware::storage:cd, interface::commandline, role::program, scope::utility Section: utils Priority: optional Size: 5210 is this package still in use for building the mips/sgi ISOs? I am the original author of genisovh although i couldnt even remember it ;) The upstream link still points to my website and the original source is still there :) My packaging skills are a bit rusty since i gave up my last package approx. 7 years ago when my first child was born ;) Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
Bug#734233: apt-listbugs: Unable to start, debian_version load error
Control: tags -1 - moreinfo On Sun, 5 Jan 2014 22:40:58 +0700 Theppitak Karoonboonyanan wrote: On Sun, Jan 5, 2014 at 5:02 PM, Francesco Poli invernom...@paranoici.org wrote: [...] Please switch to Ruby 1.9: installing package ruby1.9.1 should suffice (it should automatically set itself as the default Ruby interpreter and the command ruby -v should print ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux]). Please let me know whether this fixes the issue. Yes, it does. Good, thanks for the feedback. Thanks. You're welcome! I install the 'ruby' dependency package instead, to get the current default (ruby1.9.1), and apt-listbugs gets back to work again. That's fine. Do you think declaring Break: against ruby1.8 a good idea? (Whether apt-listbugs or ruby-debian should do this is beyond my knowledge.) In my humble opinion, if a package should declare to break ruby1.8, it should be the one which dropped support for it (ruby-debian, in the present case). But I am not even convinced that Breaks is the correct relationship: after all, the problem was not that ruby1.8 was installed (some other packages may still specifically depend on ruby1.8, until the ruby1.8-removal transition is completed); the problem was that ruby1.8 was set as the system-wide default Ruby interpreter. This may be set automatically, but also manually decided by the sysadmin (root)... A hopefully general solution is currently being investigated on the debian-ruby mailing list: https://lists.debian.org/debian-ruby/2014/01/msg7.html I am keeping this bug report open for the time being, but I am under the impression that nothing should change on apt-listbugs side. As a consequence, I may decide to close it (or reassign it to ruby-debian), sooner or later. Bye and thanks again for reporting the issue. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpnVnQlN7_fT.pgp Description: PGP signature
Bug#717398: [PATCH] Improve acpi_fakekeyd
On Sat, Jan 04, 2014 at 11:36:13PM +0100, David Härdeman wrote: Add socket activation and lazy opening of /dev/uinput which makes acpi_fakekeyd both more robust and helps speed up boot (by avoiding sleeping in the init script). An added benefit of the systemd socket activation is that the daemon is never actually started on systems (like my laptop) where the extra keys don't actually generate ACPI events. --- debian/acpi-fakekey.init | 18 ++--- debian/acpi-fakekey.install |3 + debian/acpi-fakekey.modules.conf |3 + debian/acpi-fakekey.service |7 ++ debian/acpi-fakekey.socket |9 ++ debian/control |3 + debian/patches/acpi_fakekey.diff | 148 +++--- debian/rules |2 - 8 files changed, 121 insertions(+), 72 deletions(-) create mode 100644 debian/acpi-fakekey.modules.conf After a second look, I realize that this file (acpi-fakekey.modules.conf which was installed to /etc/modules-load.d/) is actually not necessary. udev in unstable already has the functionality to pre-create dev nodes such as /dev/uinput which, when opened, will trigger the kernel module autoloading functionality, triggering the modprobe of uinput. That means the module doesn't need to be explicitly loaded in the systemd *or* initscript scenario (unless the autoloading functionality is broken of course). I'd be happy to provide an updated patch of the acpi-support maintainer so wishes. //David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system discussion status
Josh Triplett writes (Bug#727708: init system discussion status): I don't subscribe to debian-ctte@; I read it via the list archives. I've been replying using the Reply to: links at the bottom of mails, and then manually copying and quoting the responses. Those links reply to debian-c...@lists.debian.org, so unless I manually edit the destination (which I've done in a few cases where the destination was a bug report), it ends up going to the list. It'd be nice if those links paid attention to the To/Cc/Reply-To/Mail-Followup-To addresses, and otherwise acted like hitting the reply key in a mail client. I'd also add my voice to the set of people who have requested mbox archives in the past. mbox archives of bugs are available, if that's any use. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734233: apt-listbugs: No solution here
Package: apt-listbugs Version: 0.1.11 Followup-For: Bug #734233 Dear Maintainer, unfortunately, in my case the situation is worse: I get === /usr/lib/ruby/vendor_ruby/debian.rb:24:in `require': no such file to load -- debian_version (LoadError) from /usr/lib/ruby/vendor_ruby/debian.rb:24 from /usr/sbin/apt-listbugs:289:in `require' from /usr/sbin/apt-listbugs:289 E: Sub-process /usr/sbin/apt-listbugs apt returned an error code (1) E: Failure running script /usr/sbin/apt-listbugs apt === and cannot install or uninstall any package. Thanks -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apt-listbugs depends on: ii apt 0.9.14.1 ii ruby-debian 0.3.8+b2 ii ruby-gettext3.0.3-1 ii ruby-httpclient 2.3.3-2 ii ruby-soap4r 2.0.5-2 ii ruby-xmlparser 0.7.2-2 ii ruby1.8 [ruby-interpreter] 1.8.7.358-9 apt-listbugs recommends no packages. Versions of packages apt-listbugs suggests: ii chromium [www-browser] 31.0.1650.63-1 ii debianutils 4.4 ii epiphany-browser [www-browser] 3.8.2-5 ii iceweasel [www-browser] 17.0.10esr-1~deb7u1 ii reportbug 6.4.4 ii w3m [www-browser] 0.5.3-13 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734233: apt-listbugs: No solution here
Dear Maintainer, unfortunately, in my case the situation is worse: I get === /usr/lib/ruby/vendor_ruby/debian.rb:24:in `require': no such file to load -- de$ from /usr/lib/ruby/vendor_ruby/debian.rb:24 from /usr/sbin/apt-listbugs:289:in `require' from /usr/sbin/apt-listbugs:289 E: Sub-process /usr/sbin/apt-listbugs apt returned an error code (1) E: Failure running script /usr/sbin/apt-listbugs apt === and cannot install or uninstall any package. Thanks -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734285: libjogl2-java: FTBFS on s390x (and ia64)
package: libjogl2-java version: 2.1.3-1 severity: serious Hi, It seems libjogl2-java fails to build on s390x (and ia64), but it built fine in the past: https://buildd.debian.org/status/package.php?p=libjogl2-java Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
