Bug#737376: texlive-extra-utils: Debian pythontex can't use python3
On Mon, Feb 03, 2014 at 11:21:17AM +0900, Norbert Preining wrote: > On So, 02 Feb 2014, Julian Gilbey wrote: > > That way, pythontex will use Python 2.7 and pythontex3 will use Python > > 3.x. > > And we should recommend/depend/suggest both python2 and python3, > or is there a different way? I would think that anyone actively trying to use pythontex3 would be knowingly using python3 and hence having python3 installed. The devscripts package is a good example of such a thing (lots of Suggests and explanation in the package description and README). Alternatively, if one wanted to be extra-careful, the /usr/bin/pythontex3 script could, instead of a symlink, be the following (untested): #!/bin/sh if which python3 >/dev/null 2>&1 then exec /usr/share/texlive/texmf-dist/scripts/pythontex3.py "$@" else echo "You need to have python3 installed to be able to use" >&2 echo "the Python 3 version of pythontex!" >&2 echo "Exiting." >&2 fi Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#718580: ITP: mayan -- Django-based Electronic Document Management System (EDMS)
Hi Mathias! On 2014-02-02 at 14:00, Mathias Behrle wrote: > I am just starting to use mayan and I want to ask, if there are already some > results for this ITP. This only to give feedback, that I am interested to have > this package in Debian as well. Actually, the packaging is in stall because some of the build dependencies aren't available as independent packages in Debian. There were a couple of Python modules that prevented me to start working seriously on Mayan. I discovered that Python environments are not allowed (or, at least, appreciated) in Debian packaging. So I need to understand even that part of the process. Given that, if you are in a hurry for using Mayan, then you'd better start breathing again and use the python-env system for now. I'll keep you updated on the progresses I may achieve with this package, if you are interested in this task. Cheers. -- Matteo F. Vescovi Debian Maintainer GnuPG KeyID: 0x83B2CF7A signature.asc Description: Digital signature
Bug#389591: ITP: freeswitch -- Modular Media Switching Software Library and Soft-Switch Application
Hello William, Ken. It's been more than 2 years ago when this debian bug #389591 has been update for the last time, changing its status from RFP to ITP (request for packaging into intention to package). Has anything changed since that time? I'm trying to run freeswitch on debian now, but it seems it is still in very far from acceptable state, because of the habit of embedding 3rd party libraries when needed or not. I can try to clean some of that up (for example, libtiff, pcre, ldns, curl, speex, opus, ldap - at least - should be easy to replace with system (debian-provided) libs), but if something is already done, maybe I may try to use that instead of re-doing things again. Or are there no plans to make the software within linux distributions exist anymore, or maybe that's a bad idea somehow? (Yes I've read recent (and not so recent) posts about embedding 3rd party libs into the distribution). Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737498: mercurial: "hg import" fails to decode encoded author name in Git format patches
Package: mercurial Version: 2.8.2-1 Severity: normal Mercurial's documentation tells that "hg import" is able to handle "git format diff" (as generated by git-format-patch) and effectively the import works with one notable exception in my case: it fails to decode my encoded-name (due to the accent on Raphaël) in the From field: From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= Date: Thu, 30 Jan 2014 12:23:25 +0100 Subject: [PATCH] Switch type of multiple 512* accounts to "disponibilites" After an import of a patch starting with this I got this: $ hg log changeset: 25:edc1b79d0089 tag: tip user:=?UTF-8?q?Rapha=C3=ABl=20Hertzog?= date:Mon Feb 03 08:12:57 2014 +0100 summary: Switch type of multiple 512* accounts to "disponibilites" When the correct import should have given this: $ hg log changeset: 25:391d8869e9fe tag: tip user:Raphaël Hertzog date:Mon Feb 03 08:12:57 2014 +0100 summary: Switch type of multiple 512* accounts to "disponibilites" Cheers, -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 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 mercurial depends on: ii libc6 2.17-97 ii mercurial-common 2.8.2-1 ii python2.7.5-5 ii ucf 3.0027+nmu1 Versions of packages mercurial recommends: ii openssh-client 1:6.4p1-2 ii tk8.5 [wish]8.5.14-2 ii tk8.6 [wish]8.6.0-1 Versions of packages mercurial suggests: ii meld 1.8.4-1 pn qct ii vim 2:7.4.052-1 ii vim-gnome [vim] 2:7.4.052-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#737499: pristine-tar: enable files >2GB by upgrading to xdelta3
Package: pristine-tar Severity: important Hi, a member did some investigation why pristine-tar is failing with some quite large upstream tarball. The full analysis can be seen here: https://lists.debian.org/debian-med/2014/02/msg00021.html It boils down that xdelta has a restriction which makes it incapable to deal with files > 2GB which is a known issue (#205112, may be same issue as #145370) which never got any response. According to Luis' analysis the issue is solved in xdelta3. I have no idea why more packages in Debian rdepend from the outdated xdelta than from xdelta3 but to me it seems to be advisable to either deprecate xdelta usage or fix the 2GB issue. Since the later does not seem to be the case I'd suggest to upgrading to xdelta3 or if possible enable an option to alternatively use xdelta3 when dealing with large archives. Kind regards and thanks for maintaining pristine-tar Andreas. -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.36-xenU-4814-i386 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737500: ITP: arbiterjs - client-side pub/sub JavaScript library
Package: wnpp Severity: wishlist Owner: Daniel Pocock Upstream: http://arbiterjs.com License: MIT or GPL Allows pub/sub interaction (loose coupling) between JavaScript modules in a web page. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737448: [src:orthanc ] Sourceless file (minified)
Dear Bastien, Please could you be more specific? I have just spotted 2 files without detailed copyright information: * jqtree.css: Part of "tree.jquery.js" by Marco Braak [1]. * slimbox2/slimbox2.css: Part of Slimbox by Christophe Beyls [2]. TIA, Sébastien- [1] http://mbraak.github.io/jqTree/ [2] http://www.digitalia.be/software/slimbox2 On 02/02/2014 10:06 PM, bastien ROUCARIES wrote: Package: src:orthanc Version: 0.7.2-1 Severity: serious User: debian...@lists.debian.org Usertags: source-contains-prebuilt-javascript-object X-Debbugs-CC: ftpmas...@debian.org I could not find the source of a few minified file under OrthancExplorer/libs/ Bastien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736873: [ftp.debian.org] Please clarify if how sourceless file could be corrected and how
Hi, bastien ROUCARIES writes: > For implementing automatic detection fo sourceless file particularly > minified javascript, I need some clarification about correcting > sourceless file. > > They are two schools on the archive: > - some repack the origin tarball adding the missing source to it > - some add it to debian patch on subdirectory debian/missing-source Either way satisfies the requirement that we ship the source. Personally I prefer adding missing sources to the upstream tarball: - Upstream can do it too! - If source and non-source are in different locations, it's easier to miss the source and (needlessly) reject the package. - The source isn't duplicated in every .diff.gz/.debian.tar.* (though this only really matters for larger sources). Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737501: glib2.0: [exp] FTBFS on i386: undefined reference to `g_win32_input_stream_get_type'
Source: glib2.0 Version: 2.38.2-2 Severity: serious Justification: fails to build from source (but built successfully in the past) https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=i386&ver=2.38.2-2&stamp=1391385937 > .libs/gio-scan.o: In function `get_object_types': > /«PKGBUILDDIR»/debian/build/deb/docs/reference/gio/gio-scan.c:306: undefined > reference to `g_win32_input_stream_get_type' > /«PKGBUILDDIR»/debian/build/deb/docs/reference/gio/gio-scan.c:307: undefined > reference to `g_win32_output_stream_get_type' > collect2: error: ld returned 1 exit status > Linking of scanner failed: My best guess is to blame DEB_BUILD_PARALLEL = 1, because I don't see how the other changes since 2.38.2-1 could affect the documentation build. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737502: bluez: conffiles not removed
Package: bluez
Version: 5.5-1~exp1+b1
Severity: normal
Usertags: conffile
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate
The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by dh_installdeb
to remove these obsolete conffiles on upgrade.
http://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
http://manpages.debian.net/man/1/dh_installdeb
This bug report brought to you by adequate:
http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/
$ pkg=bluez ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | grep
obsolete
bluez: obsolete-conffile /etc/bluetooth/rfcomm.conf
bluez: obsolete-conffile /etc/bluetooth/serial.conf
/etc/bluetooth/rfcomm.conf 0a87d3eddd29683c1456688907e67b4f obsolete
/etc/bluetooth/serial.conf 5dcc15dd1153ddebbd41612da9b642e5 obsolete
-- System Information:
Debian Release: jessie/sid
APT prefers experimental
APT policy: (1400, 'experimental'), (1300, 'unstable'), (1200, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: armel
i386
Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages bluez depends on:
ii dbus 1.8.0-1
ii kmod 16-2
ii libc6 2.18-0experimental1
ii libdbus-1-3 1.8.0-1
ii libglib2.0-0 2.38.2-1
ii libreadline6 6.2+dfsg-0.1
ii libudev1 204-6
ii libusb-0.1-4 2:0.1.12-23.3
ii lsb-base 4.1+Debian12
ii udev 204-6
--
bye,
pabs
http://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#721721: I confirm
this breaks osmosis # ls -l `dpkg -L libpostgis-java | grep jar` lrwxrwxrwx 1 root root22 jan 28 14:35 /usr/share/java/postgis.jar -> postgis-jdbc-2.1.1.jar -rw-r--r-- 1 root root 76822 jan 28 14:01 /usr/share/java/postgis- jdbc-2.1.0~rc1.jar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737504: plasma-widget-networkmanagement: WLAN connection not re-established after resume when using systemd
Package: plasma-widget-networkmanagement Version: 0.9.0.9-1 Severity: normal Dear Maintainer, when I use systemd as my init system, the Network Manager Applet fails to re-establish the WLAN connection when coming back from suspend to RAM. Steps to reproduce: * Connect to some wireless network * Suspend to RAM * Resume Expected Behaviour: It should ask for the password in order to re-connect to the wireless. Actual Behaviour: It just pretends the connection was still available. This may work out if the machine was suspended for a very short time only and not moved, but if I moved to another room where another AP serves the same SSID, or if the machine was suspended for more than just a few minutes, I have to manually disconnetc and reconnect to the wireless network. I do not know which part of the stack is responsible for this re-connection on resume, hence I reported this in the user-facing component. Kind regards Ralf -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages plasma-widget-networkmanagement depends on: ii kde-runtime 4:4.11.3-1 ii libc6 2.17-97 ii libgcc1 1:4.8.2-14 ii libkcmutils44:4.11.3-2 ii libkdecore5 4:4.11.3-2 ii libkdeui5 4:4.11.3-2 ii libkio5 4:4.11.3-2 ii libknotifyconfig4 4:4.11.3-2 ii libopenconnect2 5.02-1 ii libplasma3 4:4.11.3-2 ii libqt4-dbus 4:4.8.5+git209-g718fae5+dfsg-1 ii libqt4-network 4:4.8.5+git209-g718fae5+dfsg-1 ii libqt4-svg 4:4.8.5+git209-g718fae5+dfsg-1 ii libqt4-xml 4:4.8.5+git209-g718fae5+dfsg-1 ii libqtcore4 4:4.8.5+git209-g718fae5+dfsg-1 ii libqtgui4 4:4.8.5+git209-g718fae5+dfsg-1 ii libsolid4 4:4.11.3-2 ii libstdc++6 4.8.2-14 ii mobile-broadband-provider-info 20130915-1 ii network-manager 0.9.8.0-5 Versions of packages plasma-widget-networkmanagement recommends: ii kwalletmanager 4:4.11.3-1 ii network-manager-openvpn 0.9.8.4-1 ii network-manager-pptp 0.9.8.4-1 ii network-manager-vpnc 0.9.8.6-1 Versions of packages plasma-widget-networkmanagement suggests: ii kde-workspace-bin4:4.11.3-3 ii network-manager-openconnect 0.9.8.4-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#737503: ruby2.0: Switching to ruby2.0 as /usr/bin/ruby breaks rdoc and testrb man pages.
Package: ruby2.0 Version: 2.0.0.353-1 Severity: important Dear Maintainer, After installing ruby2.0 from unstable, I used `update-alternatives` to switch the default interpreter, with the following result. $ sudo update-alternatives --config ruby There are 3 choices for the alternative ruby (providing /usr/bin/ruby). SelectionPathPriority Status * 0/usr/bin/ruby1.9.1 51auto mode 1/usr/bin/ruby1.8 50manual mode 2/usr/bin/ruby1.9.1 51manual mode 3/usr/bin/ruby2.0 50manual mode Press enter to keep the current choice[*], or type selection number: 3 update-alternatives: using /usr/bin/ruby2.0 to provide /usr/bin/ruby (ruby) in manual mode update-alternatives: warning: skip creation of /usr/share/man/man1/rdoc.1.gz because associated file /usr/share/man/man1/rdoc2.0.1.gz (of link group ruby) doesn't exist update-alternatives: warning: skip creation of /usr/share/man/man1/testrb.1.gz because associated file /usr/share/man/man1/testrb2.0.1.gz (of link group ruby) doesn't exist Indeed, attempting to read the rdoc and testrb man pages doesn't work. `apt-file` also shows that the the 2.0.1 versions of the man pages don't appear to be in the archive: $ apt-file search man1/rdoc ruby1.8: /usr/share/man/man1/rdoc1.8.1.gz ruby1.9.1: /usr/share/man/man1/rdoc1.9.1.1.gz ruby1.9.3: /usr/share/man/man1/rdoc1.9.3.1.gz Thanks for your hard work bringing ruby 2 to Debian! Regards, Scott. -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ruby2.0 depends on: ii libc6 2.17-97 ii libruby2.02.0.0.353-1 ii rubygems-integration 1.4 ruby2.0 recommends no packages. ruby2.0 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#737505: lilypond-data: rmdir warning on upgrade
Package: lilypond-data Version: 2.16.2-3 Severity: minor The recent upgrade produced this output, including a warning from rmdir about the lilypond data directory being used. I would suggest using the --ignore-fail-on-non-empty argument to rmdir so that this warning doesn't show up. Setting up lilypond-data (2.16.2-3) ... Running mktexlsr /usr/share/texlive/texmf-dist... mktexlsr: Updating /var/lib/texmf/ls-R-TEXLIVEDIST... mktexlsr: Done. rmdir: failed to remove ‘/usr/share/lilypond’: Directory not empty Setting up lilypond (2.16.2-3) ... -- System Information: Debian Release: jessie/sid APT prefers experimental APT policy: (1400, 'experimental'), (1300, 'unstable'), (1200, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: armel i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lilypond-data depends on: ii texinfo 5.2.0.dfsg.1-2 ii texlive-binaries [texlive-base-bin] 2013.20130729.30972-2+b2 Versions of packages lilypond-data recommends: ii lilypond 2.16.2-3 -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#737506: supermin: fails to create the supermin appliance due to conflict between sysv-rc and openrc
Package: supermin Version: 4.1.6-1 Severity: important Severity important since the packages are only from experimental, but when they move to unstable this will become an issue. I'm not sure how supermin decides which package should provide /etc/init.d/rc but I don't think it should be installing openrc by default. Setting up libguestfs-tools (1:1.25.26-1) ... supermin -v -o supermin.d --names bsdmainutils btrfs-tools cryptsetup e2fsprogs extlinux genisoimage gfs-tools gfs2-tools grub-pc hfsplus iproute libaugeas0 libcap2 libhivex0 libpcre3 libyajl2 linux-image mtools nilfs-tools ntfs-3g openssh-client reiserfsprogs sysvinit ufsutils vim-tiny xz-utils zfs-fuse acl attr bash binutils bzip2 coreutils cpio diffutils dosfstools file findutils gawk gdisk grep gzip jfsutils kmod less libxml2 lsof lsscsi lvm2 lzop mdadm parted procps procps-ng psmisc rsync scrub sed strace syslinux tar udev util-linux util-linux-ng xfsprogs zerofree --exclude ^perl --exclude ^python --exclude ^plymouth --exclude ^linux-firmware --exclude ^kbd-misc --exclude ^file-rc supermin 4.1.6 selected package handler: debian packages already present: wanted packages to download: acl adduser attr augeas-lenses base-files base-passwd bash binutils bsdmainutils bsdutils btrfs-tools bzip2 cdebconf console-tools coreutils cpio cryptsetup cryptsetup-bin dash debconf debianutils diffutils dmsetup dosfstools dpkg dracut e2fslibs e2fsprogs extlinux file findutils fuse gawk gcc-4.9-base gdisk genisoimage gettext-base grep grub-common grub-pc grub-pc-bin grub2-common gzip hfsplus ifupdown init-system-helpers initramfs-tools initscripts insserv install-info iproute iproute2 jfsutils kbd kbd-compat klibc-utils kmod kpartx less libacl1 libaio1 libasprintf0c2 libattr1 libaudit-common libaudit1 libaugeas0 libblkid1 libbsd0 libbz2-1.0 libc6 libcap2 libcomerr2 libconsole libcryptsetup4 libdb5.1 libdbus-1-3 libdebconfclient0 libdebian-installer4 libdevmapper-event1.02.1 libdevmapper1.02.1 libedit2 libeinfo1 libffi6 libfreetype6 libfuse2 libgcc1 libgcrypt11 libgdbm3 libgnutls26 libgpg-error0 libgssapi-krb5-2 libhfsp0 libhivex0 libicu52 libjson-c2 libjson0 libk5crypto3 libkeyutils1 libklibc libkmod2 libkrb5-3 libkrb5support0 liblzma5 liblzo2-2 libmagic1 libmount1 libncurses5 libncursesw5 libnewt0.52 libnih-dbus1 libnih1 libp11-kit0 libpam-modules libpam-modules-bin libpam0g libparted0debian1 libpcre3 libperl4-corelibs-perl libpng12-0 libpopt0 libprocps3 librc1 libreadline5 libreadline6 libselinux1 libsemanage-common libsemanage1 libsepol1 libsigsegv2 libslang2 libss2 libssl1.0.0 libstdc++6 libsystemd-daemon0 libsystemd-journal0 libsystemd-login0 libtasn1-3 libtextwrap1 libtinfo5 libudev1 libustr-1.0-1 libuuid1 libwrap0 libxml2 libyajl2 lsb-base lsof lsscsi lvm2 lzop makedev mawk mdadm module-init-tools mount mountall mtools multiarch-support nilfs-tools ntfs-3g openrc openssh-client original-awk parted passwd procps psmisc readline-common reiserfsprogs rsync scrub sed sensible-utils strace syslinux systemd systemd-sysv sysv-rc sysvinit sysvinit-core sysvinit-utils tar tzdata ucf udev upstart util-linux vim-common vim-tiny xfsprogs xz-utils zerofree zfs-fuse zlib1g ... Get: 161 http://http.debian.net/debian/ experimental/main openrc amd64 0.12.4+20131230-8 [87.6 kB] ... Get: 178 http://http.debian.net/debian/ experimental/main sysv-rc all 2.88dsf-46 [79.7 kB] ... unpacking /tmp/supermin62087da1862d546ea2cc3b414ba9a630.tmp/openrc_0.12.4+20131230-8_amd64.deb ... ... supermin: error: /etc/init.d/rc is a config file which is listed in two packages (/tmp/supermin62087da1862d546ea2cc3b414ba9a630.tmp/openrc_0.12.4+20131230-8_amd64.deb, /tmp/supermin62087da1862d546ea2cc3b414ba9a630.tmp/sysv-rc_2.88dsf-46_all.deb) -- System Information: Debian Release: jessie/sid APT prefers experimental APT policy: (1400, 'experimental'), (1300, 'unstable'), (1200, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: armel i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages supermin depends on: ii aptitude0.6.8.4-1 ii cpio2.11+dfsg-1 ii e2fslibs1.42.9-2 ii libc6 2.18-0experimental1 ii libcomerr2 1.42.9-2 ii zlib1g 1:1.2.8.dfsg-1 -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#729289: transition: openscenegraph
Perhaps Alberto or Rebecca (who follow upstream mailing lists) have better guesses about the current state of mind of upstream. They recently released 3.2.1rc2, and said the release date of 3.2.1 final would depend on the test results from that; they did not give an estimate. Also, for the future, question to Niels: we know that multiple versions of the same library are discouraged, but maybe it would be useful in this case to accomodate to the pace of different rdeps? That wouldn't be as useful as it might look: openwalnut have long recommended using their own repository (in a VM if necessary) instead of their Debian-main packages (http://www.openwalnut.org/projects/openwalnut/wiki/Getting_OpenWalnut), and all the other problems that were actually due to openscenegraph changes (as opposed to other issues that would be RC bugs whether or not this transition existed) were fixed (at least upstream) months ago. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735134: perl: rename(1) is ancient
Hi Gregor, On Sun, Feb 02, 2014 at 07:31:02PM +0100, gregor herrmann wrote: > It's the package for the CPAN File::Rename distribution, and > therefore named accordingly to > https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-package_names > in Debian. Thanks for pointing me at that. It seems to me this makes sense for libraries but not for end-user binaries. > (Cf. also > http://pkg-perl.alioth.debian.org/policy.html#package_naming_policy ) This seems to agree since it suggests end-user binary packages should not follow the libfoo-bar-perl scheme. [ as a side-note, if the perl group are following the latter, then a minor-severity bug against policy to update the former to reflect that practise sounds like it might be in order. I'll do this unless anyone objects. ] I guess there are common situations where you have both an end-user binary and a perl module in the same source, and you might not want to split that into two binary packages (if they're very small or something), however that doesn't appear to be the case here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737507: libqt5qml5 depends on qtjsbackend-abi-5-1-0 which is provided by the dev package with many dependencies
Package: libqt5qml5 Version: 5.1.1-1 See http://packages.debian.org/jessie/libqt5qml5 libqt5qml5l requires qtjsbackend-abi-5-1-0 which is provided by libqt5v8-5-private-dev, and libqt5v8-5-private-dev requires tons of development packages. In Sid qtjsbackend-abi-5-1-0 is required only on armhf platform, see http://packages.debian.org/sid/libqt5qml5
Bug#737508: RM: postgis [hurd-i386] -- ROM; PostgreSQL on hurd doesn't work
Package: ftp.debian.org Severity: normal Hi, please remove the postgis binaries from hurd-i386. PostgreSQL doesn't work at all on that architecture, so the postgis testsuite won't ever succeed there. Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#720750: aptitude: search returns different numbers of packages depending on sort order
2014-02-03 Daniel Hartwig : > Control: tags -1 - pending > > On 3 February 2014 02:56, Manuel A. Fernandez Montecelo > wrote: >> Control: tags -1 + pending >> >> Fix commited, it will be included in the next release if no problem is >> found with the fix. >> >> http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=845a868dc3a7af063c586c2b6ebf5e97daa90491 >> > >> + >> +/* mafm: Disabled because it does not respect the 3 way comparison of >> the >> + * sort policies, so it removes from the result set any items with the >> same >> + * result for the given policy (package_results_eq with successful >> result, >> + * which means comparison result zero in policy). >> + * >> + * This is usually not noticeable in names (should be unique) or sizes >> of >> + * packages (very rare that the size is the same); but it does not work >> well >> + * on versions (repeated sometimes) and specially not in priorities, >> since >> + * they are only a few of them for all of the packages in the archive. >> + >> output.erase(std::unique(output.begin(), output.end(), >> >> aptitude::cmdline::package_results_eq(sort_policy)), >> output.end()); >> +*/ > > The search results will now include duplicate packages where there are > multiple search patterns matching the same package: > > $ ./aptitude search '?name(^emacs24)' '?name(^emacs24)' > p emacs24 - GNU Emacs editor (with GTK+ user > interface > p emacs24 - GNU Emacs editor (with GTK+ user > interface > [...] > > (That example is obviously contrived, but it is quite common for > multiple patterns to have overlapping matches.) Perhaps it has the intended effect then? ;-) > It is package_results_eq that must be corrected to properly address > this. That function should consider package equality, rather than > equality in sort_policy. > > Please revert. Note that package_results_eq no longer exists after > wip-cmdline as search results are collected in a pkgset [libapt] which > guarantees to contain only unique packages. Likewise for versions using > verset. > > If you like, feel free to submit a patch for consideration that > addresses the issue in package_results_eq. Though, as I mentioned, this > will otherwise be resolved by the pending merge of wip-cmdline. When is this going to be fixed more or less? Weeks or months? If it's weeks I can revert the one above and it's probably fine, the bug is minor and has been present since 2010 at least (feabf55d in 2010-04-16). > Also related to this is the earlier addition of installsizechange. This > is a 2-way comparison, inconsistent with the rest of the sorting module > which is 3-way. There is this comment: > >> + // mafm: if returning zero, the comparison stops for >> + // other packages > > Clearly this refers to bug #720750. Are there other areas you know > about where this is an issue? If there are, we can fix those instead of > hacking around them in the sorting module. > > Sorting module presently relies on 3-way comparisons for functionality > such as chaining (as with a sort policy of "priority, name"). At > present, installsizechange will fail to chain correctly and this should > be corrected. What do you mean? It's already fixed after I realised that the problem was elsewhere: http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=1583a5b2212ed22319b3a3b6d4d4b047c34cd71c I don't know more areas where this is an issue, no. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737509: problem with connection to some servers
Package: pidgin Version: 2.10.8-1 Severity: grave After upgrade it isn't possible to connect to some servers (e.g. jabber.org). The solution is upgrade to version 2.10.9 For more info see https://developer.pidgin.im/ticket/15879 Best regards, -- Milan Kocian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737492: glx-diversions: Leaves dangling diversions after uninstallation
Control: reassign -1 src:glx-alternatives On Lu, 03 feb 14, 17:48:20, Brendon Green wrote: > Source: glx-diversions > Severity: critical > Justification: breaks unrelated software > > Dear Maintainer, > > I am in the process of upgrading my system from mixed (preferring stable) > to mixed (preferring unstable), in order to take advantage of recent advances > in nouveau. > > In preparation for this, I removed all packages related to the nvidia binary > driver, including glx-diversions. I am not sure which version of > glx-diversions caused the problem, as I have been swapping between versions > in an attempt to improve graphics performance. Excerpt from aptitude.log is > below. > > When an attempt was made to upgrade libgl1-mesa-glx, it was discovered that > the following diversions were in effect, pointing to the nonexistant > directory /usr/lib/mesa-diverted/: > > sudo dpkg-divert --list | grep 'mesa\|glx' > > 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/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.2.0 to > /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions > diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to > /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions > diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to > /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions > diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to > /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions > diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 > by glx-diversions > > > Removing these erroneous diversions (using dpkg-divert --remove) then allowed > the upgrade of libgl1-mesa-glx to succeed. > > When installing the nvidia driver, I have used only packages in Debian. I > have not, at any time, used nvidia-installer on this system. > > zcat /var/log/aptitude.1.gz | cat - /var/log/aptitude | grep glx-diversions > > [INSTALL, DEPENDENCIES] glx-diversions:amd64 > [REMOVE] glx-diversions:amd64 > [INSTALL, DEPENDENCIES] glx-diversions:amd64 > [REMOVE] glx-diversions:amd64 > [INSTALL, DEPENDENCIES] glx-diversions:amd64 > [UPGRADE] glx-diversions:amd64 0.2.2 -> 0.4.0~bpo70+1 > [REMOVE] glx-diversions:amd64 > [INSTALL, DEPENDENCIES] glx-diversions:amd64 > [REMOVE] glx-diversions:amd64 > [INSTALL, DEPENDENCIES] glx-diversions:amd64 > [REINSTALL] glx-diversions:amd64 > [DOWNGRADE] glx-diversions:amd64 0.4.1 -> 0.2.2 > [REMOVE] glx-diversions:amd64 > > > -- System Information: > Debian Release: jessie/sid > APT prefers testing-updates > APT policy: (900, 'testing-updates'), (900, 'stable-updates'), (900, > 'unstable'), (900, 'testing'), (900, 'stable'), (500, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.12-1-amd64 (SMP w/1 CPU core) > Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Bug#736984: xserver-xorg-video-geode: FTBFS against xorg-server 1.15
2014-01-29 Julien Cristau : > Source: xserver-xorg-video-geode > Version: 2.11.15-1 > Severity: important > User: debia...@lists.debian.org > Usertags: xorg-1.15 > > Hi, > > the geode driver fails to build against xserver-xorg-dev 1.15 (in > experimental ATM). > >> geode_dcon.c: In function 'dcon_init': >> geode_dcon.c:149:5: error: implicit declaration of function >> 'xf86SetModeDefaultName' [-Werror=implicit-function-declaration] >> xf86SetModeDefaultName(pGeode->panelMode); >> ^ >> geode_dcon.c:149:5: warning: nested extern declaration of >> 'xf86SetModeDefaultName' [-Wnested-externs] >> cc1: some warnings being treated as errors >> make[3]: *** [geode_dcon.lo] Error 1 Acknowledged. Looking into this now. Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729289: transition: openscenegraph
Some additional notes: 1. Upstream's trunk (3.3.1) has currently a soname named "111". From the logs, it is just a version number bump, but it would make sense to make sure that the ABI is not broken again. Several weeks ago I used abi-compliance-checker on OSG, but it failed to finish the analysis. 2. The transition page (https://release.debian.org/transitions/html/osg.html) is titled "libopenscenegraph100", but actually it deals with the "80" to "99" transition. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737510: [trafficserver] Transistion of boost -- Boost 1.53 is going away
Source: trafficserver Found: 4.1.2-1 Severity: serious Control: block 730275 by -1 Dear Maintainer, The recent upload B-D on libboost1.53-dev. However, this package is supposed to be removed as there is currently the transistion to boost-1.54 Please check if you really need a versioned boost dependency -- in my experierence only depending on libboost-dev is sufficient for most package and will in the long run ease subsequent boost transistions. Thanks -- Tobias Frost -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737137: game-data-packager: patch to support hexdd
> Fabian Greffrath schrieb am 7:08 Montag, 3.Februar > 2014: > > Am Samstag, den 01.02.2014, 16:09 + schrieb Johey Shmit: >> Great! Thanks for including the patches! But please leave in the "Chex > Quest 3" >> support. It will still help people who compile and install zdoom by > themselves >> (like I do at the moment). > > I think, g-d-p can use every contribution that it gets. However, I > question the benefit of supporting game data for which there is no > matching engine in Debian. This would leave out Chex Quest 3, Hexen Demo > and Strife Demo. Yes, I agree. I just assumed that at least vavoom ist supporting all the shareware version. I however did not check that, sorry. Vavoom is failing to run on my kubuntu at the moment, I'll try to install sid on a different partition when i find the time. But I just did a quick check with doomsday and the shareware versions of heretic and hexen did run without any immediate errors (did not play long though). So I guess we can support them! However the hexdd addon did load but as soon as the first level starts doomsday crashes. Could you check that with vavoom? Otherwise we should leave that out for the moment. > Regarding the former, it is just one of countless ZDoom-specific add-ons > out there and I believe we should not start packaging them, because (a) > where should we stop once we started (b) why should we start with this > one and (c) we do not even have that engine in the archive. Regarding > the latter two, I am sure that chocolate-doom currently does not support > them, not sure about doomsday, though. > > Do you know for sure that Heretic Shareware is properly supported? I'd > consider it highly frustrating for our users to send them through a > packaging procedure for explicitely supported game data but without > providing a matching engine to actually play that game. You are absolutely right! I made the mistake of using zdoom for all my testing and was not thinking this through. >> Yes, that sounds better. But I do not see that category in my kde > configuration (running >> Kubuntu 13.10). Although some desktop files include > Categories=Game;ActionGame; those >> games (like Vavoom and wolf4sdl) still show up directly in 'Games'. > > AFAICT if a category is displayed as a separate sub-menu is decided by > the number of items in it. > >> Games that use 'Categories=Game;ArcadeGame;' are being placed in > the correct submenu. > > Maybe simply because there are more games in this category and it pays > off to display them in a separate menu. > >> ArcadeGame is included in /etc/xdg/kde4-applications.menu and > 'ActionGame' is not so I >> guessed that 'ActionGame' is not one of the allowed names. > > It is: > http://standards.freedesktop.org/menu-spec/latest/apas02.html Thanks for the link, I must have been blind, sorry. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720750: aptitude: search returns different numbers of packages depending on sort order
On 3 February 2014 17:46, Manuel A. Fernandez Montecelo wrote: > 2014-02-03 Daniel Hartwig : >> Control: tags -1 - pending >> >> On 3 February 2014 02:56, Manuel A. Fernandez Montecelo >> wrote: >>> Control: tags -1 + pending >>> >>> Fix commited, it will be included in the next release if no problem is >>> found with the fix. >>> >>> http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=845a868dc3a7af063c586c2b6ebf5e97daa90491 >>> >> >>> + >>> +/* mafm: Disabled because it does not respect the 3 way comparison of >>> the >>> + * sort policies, so it removes from the result set any items with the >>> same >>> + * result for the given policy (package_results_eq with successful >>> result, >>> + * which means comparison result zero in policy). >>> + * >>> + * This is usually not noticeable in names (should be unique) or sizes >>> of >>> + * packages (very rare that the size is the same); but it does not >>> work well >>> + * on versions (repeated sometimes) and specially not in priorities, >>> since >>> + * they are only a few of them for all of the packages in the archive. >>> + >>> output.erase(std::unique(output.begin(), output.end(), >>> >>> aptitude::cmdline::package_results_eq(sort_policy)), >>> output.end()); >>> +*/ >> >> The search results will now include duplicate packages where there are >> multiple search patterns matching the same package: >> >> $ ./aptitude search '?name(^emacs24)' '?name(^emacs24)' >> p emacs24 - GNU Emacs editor (with GTK+ user >> interface >> p emacs24 - GNU Emacs editor (with GTK+ user >> interface >> [...] >> >> (That example is obviously contrived, but it is quite common for >> multiple patterns to have overlapping matches.) > > Perhaps it has the intended effect then? ;-) > Duplicates are not desirable, even if it resolves the issue with missing packages. Anyway, lets just have it reverted and fixed on wip-cmdline (weeks now, see below). > >> It is package_results_eq that must be corrected to properly address >> this. That function should consider package equality, rather than >> equality in sort_policy. >> >> Please revert. Note that package_results_eq no longer exists after >> wip-cmdline as search results are collected in a pkgset [libapt] which >> guarantees to contain only unique packages. Likewise for versions using >> verset. >> >> If you like, feel free to submit a patch for consideration that >> addresses the issue in package_results_eq. Though, as I mentioned, this >> will otherwise be resolved by the pending merge of wip-cmdline. > > When is this going to be fixed more or less? Weeks or months? > I expect within two weeks. > If it's weeks I can revert the one above and it's probably fine, the > bug is minor and has been present since 2010 at least (feabf55d in > 2010-04-16). > > >> Also related to this is the earlier addition of installsizechange. This >> is a 2-way comparison, inconsistent with the rest of the sorting module >> which is 3-way. There is this comment: >> >>> + // mafm: if returning zero, the comparison stops for >>> + // other packages >> >> Clearly this refers to bug #720750. Are there other areas you know >> about where this is an issue? If there are, we can fix those instead of >> hacking around them in the sorting module. >> >> Sorting module presently relies on 3-way comparisons for functionality >> such as chaining (as with a sort policy of "priority, name"). At >> present, installsizechange will fail to chain correctly and this should >> be corrected. > > What do you mean? It's already fixed after I realised that the > problem was elsewhere: > Right, I did not see that earlier. > http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=1583a5b2212ed22319b3a3b6d4d4b047c34cd71c > > I don't know more areas where this is an issue, no. > Nor do I. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734763: Please update libjs-jquery-cookie and use upstream numbering
Hi Raphael, > $ dpkg -c galette_0.7.6.1-2_all.deb |grep cookie > lrwxrwxrwx root/root 0 2013-11-05 10:03 > ./usr/share/galette/includes/jquery/jquery.cookie.js -> > ../../../javascript/jquery-cookie/jquery.cookie.js > > So there's no bug here regarding jquery-cookie. Sorry, I did not realise that symlinks could be used for specific js libraries in this way. I thought they were handled at the webserver level, with an alias. > There might be other local packages with similar dependencies that you > should not ignore. Yes indeed, the packages that I hope will enter Debian one day are like this. One major problem that I have with convincing our upstream developers to support Debian is that they could not predict the specific library version available, so it is easier for them to bundle in the library. Jerome's patch addresses this issue for libjs-jquery-cookie. Thanks! Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737137: game-data-packager: patch to support hexdd
Am Montag, den 03.02.2014, 10:10 + schrieb Johey Shmit: > However the hexdd addon did load but as soon as the first level starts > doomsday > crashes. Please pass "-game hexen-dk" to doomsday. Yes, that's a pain in the ass, but doomsday does not support the "-iwad ... -file ..." combination of parameters. *sigh* > Could you check that with vavoom? Otherwise we should leave that out for > the moment. If you want to test Vavoom, make sure to use the version from experimental. However, it fails to run on my machine as soon as I rebuild the package. I believe it's time to kick it from the archive, upstream is dead anyway. BTW, chocolate-doom supports all three variants of Heretic (shareware, 3 Ep commercial and 5 Ep retail) but not Hexen demo and Strife demo. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735873:
On 2014-01-31 23:10:53, Lukasz Grabowski wrote: > I just installed zathura from testing, and I'm also affected by this > issue. Previous version (from stable) worked fine. Are you running testing or also backported it to stable? Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#731261: transition: Qt5 switching qreal == double for all platforms
On Sun, Feb 2, 2014 at 15:08:36 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > On Thursday 30 January 2014 23:07:27 Julien Cristau wrote: > > On Fri, Dec 20, 2013 at 00:57:06 -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: > > > As explained before, we are requesting a slot for this transition. > > > > Go ahead. Ping this bug if/when you need binNMUs. > > The needed parts of the Qt 5 stack to build the following packages are ready, > so we can binNMU the following: > > fcitx-qt5: amd64, armel, armhf, hurd-i386, i386, s390x and sparc (and ia64?) > transmission: amd64, armel, armhf, i386, s390x and sparc (and ia64?) > qgo: amd64, armhf and i386 > Scheduled. What about pokerth? Cheers, Julien signature.asc Description: Digital signature
Bug#737501: glib2.0: [exp] FTBFS on i386: undefined reference to `g_win32_input_stream_get_type'
retitle 737501 glib2.0/exp: FTBFS: undefined reference to `g_win32_input_stream_get_type' thanks On 03/02/14 08:51, Simon McVittie wrote: > https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=i386&ver=2.38.2-2&stamp=1391385937 Same bug, different architecture: https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=mips&ver=2.38.2-2&stamp=1391420157 S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737269: tex-gyre: should only (at most) recommend fonts-texgyre
Quoting Norbert Preining (2014-02-03 03:19:42) >> OpenType fonts cannot be embedded in PDF files prior to PDF 1.5. >> Unfortunately some of the most prominent of Free Software PDF >> producers for professional grade desktop publishing - Ghostscript and >> Scribus - > > You forget the ones that are really professional: xetex and luatex. Nope: Notice how I wrote "some of". :-) I use XeTeX myself for some things, and find it a higher quality producer than Scribus and Ghostscript, but that's besides the point (professional grade does not necessarily imply high quality). > These fonts are used by default on context etc, thus the dependency is > and will remain strict. If ConTexT always(!) need OpenType flavor of Tex Gyre, then package context should directly depend on package fonts-texgyre. If however (as it seems you describe the situation) - ConTexT only by default, but not for *all* uses of that tool, need OpenType flavor of Tex Gyre, then package context should directly *recommend* package fonts-texgyre. The example of ConTexT that you bring up is therefore an argument for - not against - relaxing from depends to recommends - and for a different package than this bugreport is about. > Closing this bug. I beg to disagree, and kindly request you to reopen this bugreport. Debian Policy explicitly describes "Recommends:" to be the correct relation to use when a package in unneeded for an an unusual installation: The `Recommends' field should list packages that would be found together with this one in all but unusual installations. >> I argue that this is a genuine use-case for having tex-gyre installed >> _without_ fonts-texgyre, and ask that the relation therefore should >> be relaxed to only recommend fonts-texgyre. > > Then you can disable the necessary fontconfig file, or report a bug to > the "professional" typesetting PDF producers that they should get > fixed. I am aware that there are other more complex solution to my problem. Do you not recognize this as an unusual installation, that do not need fonts-texgyre pulled in by tex-gyre? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#724176: kanif: diff for NMU version 1.2.2-1.1
tags 724176 + patch
tags 724176 + pending
thanks
Dear maintainer,
I've prepared an NMU for kanif (versioned as 1.2.2-1.1).
Since I'm no DD yet (this is part of my NM chores), I have uploaded
the package to
http://mentors.debian.net/package/kanif/
the NMU does
- close #724176
- fix a minor spelling error in the manpage
- switches the source-format to "3.0(quilt)" (so i can use quilt for the above
fixes)
- bumps standards to 3.9.5 (no changes needed)
If you are fine with an NMU, i will tell my application manager to sponsor an
upload to DELAY/0 (as you have indicated on wiki.d.o/LowThresholdNmu that this
is fine for you).
Please feel free to tell me if I should delay it longer.
mfgdsar
IOhannes
diff -Nru kanif-1.2.2/debian/changelog kanif-1.2.2/debian/changelog
--- kanif-1.2.2/debian/changelog 2014-02-03 11:45:30.0 +0100
+++ kanif-1.2.2/debian/changelog 2014-02-03 11:38:41.0 +0100
@@ -1,3 +1,14 @@
+kanif (1.2.2-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix POD-syntax (Closes:#724176)
+ * Fixed spelling errors
+ * Use source-format 3.0(quilt)
+ * Canonical Vcs-* stanzas
+ * Bumped standards to 3.9.5
+
+ -- IOhannes m zmölnig Mon, 03 Feb 2014 11:38:23 +0100
+
kanif (1.2.2-1) unstable; urgency=low
* New upstream release.
diff -Nru kanif-1.2.2/debian/control kanif-1.2.2/debian/control
--- kanif-1.2.2/debian/control 2014-02-03 11:45:30.0 +0100
+++ kanif-1.2.2/debian/control 2014-02-03 11:37:43.0 +0100
@@ -4,9 +4,9 @@
Maintainer: Lucas Nussbaum
Uploaders: Vincent Danjean
Build-Depends: cdbs, debhelper (>= 5)
-Standards-Version: 3.9.3
-Vcs-Browser: http://svn.debian.org/wsvn/collab-maint/deb-maint/kanif/trunk/
-Vcs-Svn: svn://svn.debian.org/collab-maint/deb-maint/kanif/trunk/
+Standards-Version: 3.9.5
+Vcs-Browser: http://anonscm.debian.org/viewvc/collab-maint/deb-maint/kanif/trunk/
+Vcs-Svn: svn://anonscm.debian.org/collab-main
Homepage: http://taktuk.gforge.inria.fr/kanif
Package: kanif
diff -Nru kanif-1.2.2/debian/patches/fix_pod_syntax.patch kanif-1.2.2/debian/patches/fix_pod_syntax.patch
--- kanif-1.2.2/debian/patches/fix_pod_syntax.patch 1970-01-01 01:00:00.0 +0100
+++ kanif-1.2.2/debian/patches/fix_pod_syntax.patch 2014-02-03 11:30:11.0 +0100
@@ -0,0 +1,43 @@
+Description: fix POD-syntax
+ enumeration must not consist of a single number ('=item 1'), so use
+ '=item C<1>' instead
+Author: IOhannes m zmölnig
+Last-Update: 2014-02-03
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- kanif.orig/kanif.pod
kanif/kanif.pod
+@@ -211,28 +211,28 @@
+
+ =over
+
+-=item 0
++=item C<0>
+
+ No processing at all: raw commands output is printed to stdout and raw commands
+ error is printed to stderr. Connections and executions errors are not reported.
+
+-=item 1
++=item C<1>
+
+ Same as 0 except that the name of the host which produced the output is
+ prepended before each line.
+
+-=item 2
++=item C<2>
+
+ Same as 1 except that the output is sorted by command (one complete command
+ execution is outputed entirely before another one). Connections and
+ executions errors are summarized at the end to stderr.
+
+-=item 3
++=item C<3>
+
+ Same as 2 except that the hostname is printed once, formatted as a title,
+ before its output.
+
+-=item 4
++=item C<4>
+
+ Same as 3 except that identical output produced by multiple nodes is printed
+ once with all the hosts summarized in the title.
diff -Nru kanif-1.2.2/debian/patches/fix_spelling.patch kanif-1.2.2/debian/patches/fix_spelling.patch
--- kanif-1.2.2/debian/patches/fix_spelling.patch 1970-01-01 01:00:00.0 +0100
+++ kanif-1.2.2/debian/patches/fix_spelling.patch 2014-02-03 11:30:11.0 +0100
@@ -0,0 +1,17 @@
+Description: Fix spelling
+ "informations" should read "information"
+Author: IOhannes m zmölnig
+Last-Update: 2014-02-03
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- kanif.orig/kanif.pod
kanif/kanif.pod
+@@ -54,7 +54,7 @@
+ clusters, B syntax is too complicated. The goal of B is
+ to provide an easier and familiar syntax to cluster administrators while still
+ taking advantage of B characteristics and features (adaptivity,
+-scalability, portability, autopropagation and informations redirection).
++scalability, portability, autopropagation and information redirection).
+
+ To work, B needs to find the C command (version 3.3 and
+ above) in the user path. The other requirements are the same as B: it
diff -Nru kanif-1.2.2/debian/patches/series kanif-1.2.2/debian/patches/series
--- kanif-1.2.2/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ kanif-1.2.2/debian/patches/series 2014-02-03 11:30:11.0 +0100
@@ -0,0 +1,2 @@
+fix_pod_syntax.patch
+fix_spelling.patch
diff -Nru kanif-1.2.2/debian/source/format kanif-1.2.2/debian/source/format
--- kanif-1.2.2/debian/source/format 1970-01-01 01:00:00.0 +0100
+++ kanif-1.2.2/debian/source/format 2014-02-03 11:
Bug#737492: glx-diversions: Leaves dangling diversions after uninstallation
Control: reassign -1 glx-diversions 0.4.1 Control: retitle -1 glx-diversions: Leaves dangling diversions after downgrade Control: severity -1 minor Control: tag -1 wontfix Control: close -1 On Monday, 3. February 2014 05:48:20 Brendon Green wrote: > [DOWNGRADE] glx-diversions:amd64 0.4.1 -> 0.2.2 Downgrades are not supported. This won't be changed. And this is not needed. Install again the latest version you had and remove it afterwards - it will clean up all the diversions it knows about. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737511: uwsgi-plugin-psgi - Ignores offset parameter in psgi.input->read
Package: uwsgi-plugin-psgi Version: 1.9.17.1-5 Severity: grave A PSGI application gets a input stream in the psgi.input element:[1] | psgi.input: the input stream. | The input stream in psgi.input is an IO::Handle-like object which | streams the raw HTTP POST or PUT data. The input stream MUST respond to | read and MAY implement seek. The read method is defined as:[2] | $io->read ( BUF, LEN, [OFFSET] ) The current function XS_input_read in plugins/psgi/psgi_loader.c retrieves only the first two parameters and ignores the third:[3] | SV *read_buf = ST(1); | unsigned long arg_len = SvIV(ST(2)); This leads to silent buffer corruption, because it always overrides the buffer from the beginning instead of using the offset. The offset parameter is for example used in CGI::PSGI->read_from_client, so in almost any PSGI application. Bastian [1]: https://metacpan.org/pod/PSGI [2]: https://metacpan.org/pod/IO::Handle [3]: https://github.com/unbit/uwsgi/blob/master/plugins/psgi/psgi_loader.c#L100 -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.13-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#707907: mplayer2: enable mpg123 at compilation?
On 2013-05-15 07:18:24, Reinhard Tartler wrote: > On Wed, May 15, 2013 at 1:43 AM, Bob Bib wrote: > > Sun, 12 May 2013, 22:52 +02:00 from Reinhard Tartler: > >> Did you perhaps enable the mpg123 backend in your mplayer.conf? > > > > No. > > > >> Do you have problems with the lavc decoder? > > > > No problems with lavc, I've just noticed that warning :) > > I see, > > I believe that this is because the codecs.conf prefers mpg123 over the > other e.g. ffmp3float, and this warning is purely cosmetical. > > Now, what can we do now: > a) make the warning appear only at higher debugging levels > b) compile against mpg123 (causes additional complexity for unknown benefits) > c) edit codecs.conf. > > right now, I'd prefer a>c>b, but I'm happy to hear other opinions. It looks like 2.0-665-gb5349bb-1 implemented b). Should we close this now? Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#737512: debmany(1) manpage: typo: /use/share/doc -> /usr/share/doc
Package: debian-goodies Version: 0.63 Severity: minor $ debmany | grep /use/ Optionally set a viewer for other files (/use/share/doc). -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733471: Replace debget with the more reliable and faster dget from devscripts
Since wheezy, apt-get has a "download" subcommand. How about reimplementing debget as a thin wrapper around "apt-get download"? Or maybe debget should be removed completely. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731261: transition: Qt5 switching qreal == double for all platforms
On Monday 03 February 2014 11:39:58 Julien Cristau wrote: [snip] > Scheduled. > > What about pokerth? It's safe to binNMU too, thanks for pointing it out. But on the other hand looking at it's B-D: qtbase5-dev [!kfreebsd-amd64 !kfreebsd-i386 !mips !mipsel !powerpc !hppa !ppc64 !x32], libqt4-dev [kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc hppa ppc64 x32], Games team/Pokerth maintainers: would you like to switch to Qt5 now that it builds on all archs, or at least on all except x32? It would require a prompt source full update to help with the transition. WRT the rest of the transition, I'll upload qtwebkit again in some minutes due to an RC bug filled yesterday. Thanks! -- 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#729289: transition: openscenegraph
2014-02-03 Rebecca N. Palmer : >> >> Also, for the future, question to Niels: we know that multiple >> versions of the same library are discouraged, but maybe it would be >> useful in this case to accomodate to the pace of different rdeps? > > That wouldn't be as useful as it might look: openwalnut have long > recommended using their own repository (in a VM if necessary) instead of > their Debian-main packages > (http://www.openwalnut.org/projects/openwalnut/wiki/Getting_OpenWalnut), and > all the other problems that were actually due to openscenegraph changes (as > opposed to other issues that would be RC bugs whether or not this transition > existed) were fixed (at least upstream) months ago. (This starts to be offtopic, so perhaps would be better to stop discussing it in the bug report). I don't understand why this would not be useful with my proposal. Having several versions is supposed to be discouraged, that's why we never tried to implement this, but at least I would be in favour of it. That means that we could have: - 3.3 or 3.4 (when available) for developers using the library directly, and stabilise that version in Debian before we ask rdeps to start to migrate, - 3.2.* for (most) debian rdeps, - and perhaps an older version 3.0.* while other rdepends (more conservative, or less actively maintained) don't migrate. So, if anything, it would help to not make rdeps to move so fast and allow them to stabilise, with larger time-frames to update their build-depends, while still providing the latest and greatest to developers and weeding out some problems before rdeps suffer them. This can only help OpenWalnut to be more stable in Debian, so I don't understand why you say that it would not be useful. If it's simply because "nobody uses OpenWalnut", well, in this case it could as well be removed from Debian. Its popcon is very low indeed (not only now, but even more so in the years before OSG was broken). But still, I don't think that low popcon is good reason to remove packages, specially when they are intended to be useful only for a relatively small population. http://qa.debian.org/popcon.php?package=openwalnut Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729289: transition: openscenegraph
Control: block -1 with 735891 On 2014-02-03 00:06, Rebecca N. Palmer wrote: > That means choreonoid needs to be fixed; the patch is in #735891. So all that is missing here is a sponsor for doing a NMU with a sane looking RC bugfix patch? Changelog entry should be something along [ Rebecca N. Palmer ] * Install files independently from cmake build type. (Closes: #735891) Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736360: lintian: do not warn about doxygen embedding jquery
* Helmut Grohne , 2014-01-22, 19:32: Please stop warning about jquery.js as embedded by Doxygen. I evaluated all options at fixing this issue in Doxygen and conclude that a fix is infeasible and its usefulness is limited. The issue and the problems about fixing it are documented in /usr/share/doc/doxygen/README.jquery (in the doxygen package >= jessie). Even if there were a security issue in jquery, it will likely not affect any user via Doxygen. Security is not the only issue here. jquery.js created by Doxygen is minified, so there's a risk that we ship it without source. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737264: /usr/share/man/man7/systemd.directives.7.gz: systemd.directives(7) is empty
Am 02.02.2014 23:23, schrieb Sam Morris: > Hm, I think we disagree on the desired results. :) I don't mean that the > man page is absolutely empty... I'm referring to the actaul list of each > directive along with the man page in which it is documented. Sorry for > being unclear. > > I'm attaching the man page from version 204-5 so you can see what I > mean. Ok, I understand now what you mean. Not quite sure yet. Seems to be a problem of using out-of-tree builds. At least I can *not* reproduce the issue with an in-tree build. When doing the oot build I'm getting a lot of those warnings: make[2]: Circular man/systemd.directives.xml <- man/bootup.xml dependency dropped. make[2]: Circular man/systemd.directives.xml <- man/daemon.xml dependency dropped. make[2]: Circular man/systemd.directives.xml <- man/halt.xml dependency dropped. ... See also the 204-6 build https://buildd.debian.org/status/fetch.php?pkg=systemd&arch=i386&ver=204-6&stamp=1388514325 In comparison from the 204-5 build, there are no such warnings about circular dependencies: https://buildd.debian.org/status/fetch.php?pkg=systemd&arch=i386&ver=204-5&stamp=1379939127 I wonder if something in our toolchain has changed which causes that regression. My bet would be changes in automake -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#727189: mplayer2: mencoder seems to loop when ending
Control: reassign -1 mencoder On 2013-10-23 10:06:19, Chantal Keller wrote: > Package: mplayer2 Did you want mencoder here? mplayer2 does not ship a mencoder binary. Reassigning to the mencoder package. Regards > Version: 2.0-701-gd4c5b7f-2 > Severity: normal > > Dear Maintainer, > > When executing the following command (sound encoding from a DVD): > > mencoder dvd://1 -aid 128 -nosub -oac mp3lame -lameopts > mode=2:cbr:br=128:vol=0 -ovc frameno -o frameno.avi > > everything runs as usual, saying: > > Pos: 297.2s 7434f (10%) 1449.97fps Trem: 0min 46mb A-V:0.070 [0:128] > > with percentage, number of frames, number of frames per second and > position increasing, except that it remains blocked when reaching 99%, > in which case it keeps repeating: > > Skipping frame! > Pos:3416.0s 980330f (99%) 13885.89fps Trem: 0min 54mb A-V:0.104 [0:128] > > The number of frames and number of frames per second still increase. > > Best regards. > > > > -- System Information: > Debian Release: jessie/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages mplayer2 depends on: > ii liba52-0.7.4 0.7.4-16 > ii libasound21.0.27.2-3 > ii libass4 0.10.1-3 > ii libavcodec54 6:9.10-1 > ii libavformat54 6:9.10-1 > ii libavresample16:9.10-1 > ii libavutil52 6:9.10-1 > ii libbluray11:0.4.0-1 > ii libbs2b0 3.1.0+dfsg-2 > ii libc6 2.17-93 > ii libcaca0 0.99.beta18-1 > ii libcdio-cdda1 0.83-4 > ii libcdio-paranoia1 0.83-4 > ii libcdio13 0.83-4 > ii libdca0 0.0.5-6 > ii libdirectfb-1.2-9 1.2.10.0-5 > ii libdv41.0.0-6 > ii libdvdnav44.2.0+20130225-3 > ii libdvdread4 4.2.0+20130219-2 > ii libenca0 1.15-1 > ii libfaad2 2.7-8 > ii libgif4 4.1.6-10 > ii libgl1-mesa-glx [libgl1] 9.2.2-1 > ii libjack-jackd2-0 [libjack-0.116] 1.9.9.5+20130622git7de15e7a-1 > ii libjpeg8 8d-1 > ii liblcms2-22.2+git20110628-2.3 > ii liblircclient00.9.0~pre1-1 > ii libmad0 0.15.1b-8 > ii libmng1 1.0.10-3 > ii libmpg123-0 1.16.0-1 > ii libncurses5 5.9+20130608-1 > ii libogg0 1.3.1-1 > ii libpng12-01.2.49-5 > ii libpostproc52 7:0.10.3-dmo1 > ii libpulse0 4.0-6+b1 > ii libquvi7 0.4.1-2 > ii libsdl1.2debian 1.2.15-7 > ii libsmbclient 2:4.0.10+dfsg-3 > ii libspeex1 1.2~rc1-7 > ii libswscale2 7:0.10.3-dmo1 > ii libtheora01.1.1+dfsg.1-3.1 > ii libtinfo5 5.9+20130608-1 > ii libvdpau1 0.7-1 > ii libvorbis0a 1.3.2-1.3 > ii libx11-6 2:1.6.2-1 > ii libxext6 2:1.3.2-1 > ii libxinerama1 2:1.1.3-1 > ii libxss1 1:1.2.2-1 > ii libxv12:1.0.9-1 > ii libxvidcore4 3:1.3.2-0.6 > ii libxxf86vm1 1:1.1.3-1 > ii zlib1g1:1.2.8.dfsg-1 > > mplayer2 recommends no packages. > > mplayer2 suggests no packages. > > -- no debconf information -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#737448: [src:orthanc ] Sourceless file (minified)
Hi Sebastien, On Mon, Feb 03, 2014 at 09:35:26AM +0100, Sebastien Jodogne wrote: > > * jqtree.css: Part of "tree.jquery.js" by Marco Braak [1]. > * slimbox2/slimbox2.css: Part of Slimbox by Christophe Beyls [2]. The problematic files are all *.js files since they are compressed and not to be considered as editable source files. Your task would be to verify, whether there are any *.js files just packaged for Debian (checkout files starting with libjs-* and apt-file search is your friend. You should strip these files from the upstream source. For this I'd recommend using "Files-Excluded" in debian/copyright (see `man uscan`). For those JS files that are not yet packaged I'd recommend to put the real uncompressed source into the dir debian/JS. To have some accepted example you might like to have a look into gnumed-client packaging: http://anonscm.debian.org/viewvc/debian-med/trunk/packages/gnumed-client/trunk/ It seems you are now facing the boring part of creating Debian packages... Hope this helps Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737513: debmany(1) manpage says /dev/shm is used as temp dir
Package: debian-goodies Version: 0.63 Severity: minor The debmany(1) manpage says: “The manpages are temporarily extracted to /dev/shm (if the directory exists)”. But this is no longer true: see bug #679457. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737105: [Pkg-fonts-devel] Bug#737105: Bug#737105: fonts-droid: missing some .ttf files
Quoting Fabian Greffrath (2014-02-03 06:52:11) > Am Sonntag, den 02.02.2014, 01:13 +0900 schrieb Hideki Yamane: >> Really? It seems that upstream still provides those droid fonts for >> Android 4.4.2r1 as >> >> https://android.googlesource.com/platform/frameworks/base/+/master/data/fonts/ >> >> (DroidSansArabic.ttf, DroidSansFallback.ttf, etc...) > > What I meant to say is: Please do not add font files to the > src:fonts-android source package that are not part of the Android GIT > checkout (anymore). It is currently not reproducible how our Debian > source package was composed and that already led to confusion in > #733077. I believe, on the other hand, that it is safe to install font > files into the fonts-droid binary package that are already part of the > source package and thus still part of the Android GIT checkout. If appropriate, please include Droid Sans Fallback, as that font is needed by recent releases of Ghostscript. If not appropriate please tell me, so that I can arrange for having that font packaged separately (and preferrably have that done before next packaging release of Ghostscript which is overdue). > So, sorry for all the confusion. I sure hope I do not confuse even further with this remark :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#737514: mplayer2: unused liblivemedia-dev build dependency
Source: mplayer2 Version: 2.0-701-gd4c5b7f-2 Severity: wishlist It seems like liblivemedia is not used in mplayer2. The resulting binary does not link against any of the libraries provided by liblivemedia. Also grepping through the source did not reveal anything. Could you please remove the unused build dependency? Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#737448: [src:orthanc ] Sourceless file (minified)
Hi Andreas, The problematic files are all *.js files since they are compressed and not to be considered as editable source files. Your task would be to verify, whether there are any *.js files just packaged for Debian (checkout files starting with libjs-* and apt-file search is your friend. You should strip these files from the upstream source. For this I'd recommend using "Files-Excluded" in debian/copyright (see `man uscan`). For those JS files that are not yet packaged I'd recommend to put the real uncompressed source into the dir debian/JS. To have some accepted example you might like to have a look into gnumed-client packaging: http://anonscm.debian.org/viewvc/debian-med/trunk/packages/gnumed-client/trunk/ Thanks for this very helpful clarification. I have however an additional question: During the build process, all the Javascript/HTML/CSS/... resources are integrated into the Orthanc binaries. Is this behavior OK wrt. Debian guidelines? Sincerely, Sébastien- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737515: dictionaries-common-dev: dh_aspell
Package: dictionaries-common-dev
Version: 1.20.5
Severity: normal
Tags: patch
Hi,
attached is my first attempt to turn installdeb-aspell into dh_aspell.
I'm not sure if the changes are sufficient for all aspell-xx packages,
this will require further evaluation. Also I'm not sure how this can be
integrated easily into installdeb.in
In addition to installdeb-aspell's work, it does the following:
* populate substvar aspell:Depends
* compress /usr/share/aspell/*.cwl
* remove /usr/lib/aspell/*.rws [files only, no symlinks]
* move /usr/lib/aspell/*.cwl /usr/share/spalell/ (is this needed at
all?)
and it also adds a debhelper sequence, so you can have this rules file:
= 8< =
#!/usr/bin/make -f
%:
dh $@ --with aspell
# this is not a GNU autoconf/automake build system
override_dh_auto_configure:
./configure
= >8 =
The dictionaries-common buildsystem could use a debhelper upgrade ...
I'm attaching three patches, two are only for preview (dico.diff, and
the split out dh_aspell.diff showing the differences from
installdeb-aspell).
The third I'd consider ready to apply
(use doit(ln -s ...) instead of symlink(...).
Andreas
diff -Nru dictionaries-common-1.20.5/debian/changelog dictionaries-common-1.20.5+nmu1/debian/changelog
--- dictionaries-common-1.20.5/debian/changelog 2014-01-14 11:27:40.0 +0100
+++ dictionaries-common-1.20.5+nmu1/debian/changelog 2014-02-02 23:55:52.0 +0100
@@ -1,3 +1,9 @@
+dictionaries-common (1.20.5+nmu1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+
+ -- Andreas Beckmann Sat, 01 Feb 2014 23:09:13 +0100
+
dictionaries-common (1.20.5) unstable; urgency=low
* Move default symlink creation to the common perl module.
diff -Nru dictionaries-common-1.20.5/debian/dictionaries-common-dev.install dictionaries-common-1.20.5+nmu1/debian/dictionaries-common-dev.install
--- dictionaries-common-1.20.5/debian/dictionaries-common-dev.install 1970-01-01 01:00:00.0 +0100
+++ dictionaries-common-1.20.5+nmu1/debian/dictionaries-common-dev.install 2014-02-02 23:55:52.0 +0100
@@ -0,0 +1,2 @@
+scripts/debhelper/dh_aspell usr/bin/
+scripts/debhelper/sequence/aspell.pm usr/share/perl5/Debian/Debhelper/Sequence/
diff -Nru dictionaries-common-1.20.5/debian/dictionaries-common.lintian-overrides dictionaries-common-1.20.5+nmu1/debian/dictionaries-common.lintian-overrides
--- dictionaries-common-1.20.5/debian/dictionaries-common.lintian-overrides 1970-01-01 01:00:00.0 +0100
+++ dictionaries-common-1.20.5+nmu1/debian/dictionaries-common.lintian-overrides 2014-02-02 23:55:52.0 +0100
@@ -0,0 +1 @@
+dictionaries-common: debconf-is-not-a-registry
diff -Nru dictionaries-common-1.20.5/debian/dictionaries-common.overrides dictionaries-common-1.20.5+nmu1/debian/dictionaries-common.overrides
--- dictionaries-common-1.20.5/debian/dictionaries-common.overrides 2008-07-01 13:42:00.0 +0200
+++ dictionaries-common-1.20.5+nmu1/debian/dictionaries-common.overrides 1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-dictionaries-common: debconf-is-not-a-registry
diff -Nru dictionaries-common-1.20.5/debian/rules dictionaries-common-1.20.5+nmu1/debian/rules
--- dictionaries-common-1.20.5/debian/rules 2014-01-14 11:27:05.0 +0100
+++ dictionaries-common-1.20.5+nmu1/debian/rules 2014-02-02 23:55:52.0 +0100
@@ -46,8 +46,6 @@
dh_installdirs
$(MAKE) install DESTDIR=$(debtmp)
- install -m 0644 debian/dictionaries-common.overrides \
- debian/dictionaries-common/usr/share/lintian/overrides/dictionaries-common
touch $(debtmp)/usr/share/dictionaries-common/elanguages
dh_movefiles -pdictionaries-common-dev
dh_movefiles -pdictionaries-common
@@ -57,11 +55,13 @@
binary-indep: build install
dh_testdir
dh_testroot
+ dh_install
dh_installdocs --all $(alldocs)
dh_installemacsen
dh_installman
dh_installchangelogs
dh_link
+ dh_lintian
dh_compress
dh_installdebconf
dh_fixperms
diff -Nru dictionaries-common-1.20.5/scripts/debhelper/dh_aspell dictionaries-common-1.20.5+nmu1/scripts/debhelper/dh_aspell
--- dictionaries-common-1.20.5/scripts/debhelper/dh_aspell 1970-01-01 01:00:00.0 +0100
+++ dictionaries-common-1.20.5+nmu1/scripts/debhelper/dh_aspell 2014-02-02 23:55:52.0 +0100
@@ -0,0 +1,331 @@
+#!/usr/bin/perl -w
+#
+# Registration with aspell dictionary
+#
+# PROMISE: DH NOOP WITHOUT info-aspell
+
+use strict;
+
+my $class = "aspell";
+my $no_pre_post;
+my $no_config;
+my $debug;
+#
+
+
+#
+
+# ---
+sub mydie {
+# ---
+ my $msg = shift;
+ my $see = shift;
+ die "$msg\nPlease see $see.\n";
+}
+
+# ---
+sub mywarn {
+# ---
+ my $msg = shift;
+ my $see = shift;
+ warn "$msg\nPlease see $see.\n";
+ exit 0;
+}
+
+# ===
+# M
Bug#737448: [src:orthanc ] Sourceless file (minified)
Hi Sebastien, On Mon, Feb 03, 2014 at 12:57:33PM +0100, Sebastien Jodogne wrote: > ... > >real uncompressed source into the dir debian/JS. To have some accepted > >example you might like to have a look into gnumed-client packaging: > > > > > > http://anonscm.debian.org/viewvc/debian-med/trunk/packages/gnumed-client/trunk/ > > Thanks for this very helpful clarification. > > I have however an additional question: During the build process, all > the Javascript/HTML/CSS/... resources are integrated into the > Orthanc binaries. > > Is this behavior OK wrt. Debian guidelines? Well, if you have the proper (=editable) source of the JS libraries I doubt that there is any problem with this. For sure you need no extra source for the Debian packaged JS libraries and can use them as you want (at least to my understanding of the issue). Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737448: [src:orthanc ] Sourceless file (minified)
On 02/03/2014 12:57 PM, Sebastien Jodogne wrote: Hi Andreas, The problematic files are all *.js files since they are compressed and not to be considered as editable source files. Your task would be to verify, whether there are any *.js files just packaged for Debian (checkout files starting with libjs-* and apt-file search is your friend. You should strip these files from the upstream source. For this I'd recommend using "Files-Excluded" in debian/copyright (see `man uscan`). For those JS files that are not yet packaged I'd recommend to put the real uncompressed source into the dir debian/JS. To have some accepted example you might like to have a look into gnumed-client packaging: http://anonscm.debian.org/viewvc/debian-med/trunk/packages/gnumed-client/trunk/ Thanks for this very helpful clarification. I have however an additional question: During the build process, all the Javascript/HTML/CSS/... resources are integrated into the Orthanc binaries. Is this behavior OK wrt. Debian guidelines? BTW, another related question: How can I bring back the *.js/*.css files into the build folder, where the CMake build script expects them? Am I allowed to create symbolic links in the "override_dh_auto_configure" sections? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737448: [src:orthanc ] Sourceless file (minified)
Hi Sebastien, On Mon, Feb 03, 2014 at 01:02:59PM +0100, Sebastien Jodogne wrote: > >Is this behavior OK wrt. Debian guidelines? > > BTW, another related question: How can I bring back the *.js/*.css I think *.css should be no problem. > files into the build folder, where the CMake build script expects > them? Am I allowed to create symbolic links in the > "override_dh_auto_configure" sections? Sure: override_dh_auto_configure # either do symlink or use some compression of the source # files to the place you need here dh_auto_configure ... Hope this helps ANdreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724176: kanif: diff for NMU version 1.2.2-1.1
Hi, On 03/02/14 at 11:50 +0100, IOhannes m zmölnig wrote: > tags 724176 + patch > tags 724176 + pending > thanks > > Dear maintainer, > > I've prepared an NMU for kanif (versioned as 1.2.2-1.1). > Since I'm no DD yet (this is part of my NM chores), I have uploaded > the package to > http://mentors.debian.net/package/kanif/ > > the NMU does > - close #724176 > - fix a minor spelling error in the manpage > - switches the source-format to "3.0(quilt)" (so i can use quilt for the > above >fixes) > - bumps standards to 3.9.5 (no changes needed) > > If you are fine with an NMU, i will tell my application manager to sponsor an > upload to DELAY/0 (as you have indicated on wiki.d.o/LowThresholdNmu that this > is fine for you). > Please feel free to tell me if I should delay it longer. fine with me, and I suspect that Vincent is also fine, so please just upload directly to unstable. Thanks a lot for your work! Lucas signature.asc Description: Digital signature
Bug#570623: reprepro: please add multiple version management
On So, 2014-02-02 at 14:06 +0100, Bernhard R. Link wrote:
> * Benjamin Drung [140108 15:51]:
>
> First sorry for my late reply. I must have totally missed your mail.
No problem. I have been kept busy with other projects. ;)
> > The first step is to agree on the database layout change. I came up with
> > two alternatives:
> >
> > 1) Allow duplicate entries in packages.db and sort duplicate entries by
> > their Debian version. They can be sorted a) upwards or b) downwards.
> > Depending on the request, we will either search for all versions of a
> > package, one specific version of the package, or for the latest version
> > of a package.
> >
> > 2) Rename the key of packages.db to also contain the version of the
> > package, e.g. "sl|3.03-17" or "hello_2.8-4" (which delimiter should we
> > use?). This would allow us to check directly for a specific version of a
> > package. We need to add a secondary table that allows us to access the
> > database as described in 1) through the secondary table. This secondary
> > table will allow duplicate entries and the values of the secondary table
> > point to the key in packages.db. Depending on the task, we either query
> > the first or secondary table. The secondary table will be kept in sync
> > by BerkeleyDB.
> >
> > In the first case, we need to add a function to iterate over the
> > duplicate packages to find a specific version. In the second case, we
> > need to create the secondary table and transform the database.
> >
> > Which layout do you prefer?
>
> I think that layout is better that better fits the code. Not yet having
> looked at the code, I cannot say. I guess 1 might be simpler. In the
> case of 2 I think "|" is fine, as it is already used elsewhere (though
> I guess one should make sure reprepro does not allow | in package
> names).
Okay. Attached the patch for my prototype. Be aware: It's just a
prototype that is just able to run the commands that I wanted to test,
but isn't near to be ready for mainlining. The prototype implements case
2 just because that was my initial idea, but now I tend to think that
case 1 might be easier/cleaner.
> > Another issue is the sorting of the packages in the database. We need
> > one function to sort all entries in the table. So we need one function
> > to sort binary packages and source packages, but we have
> > binaries_getversion() and source_getversion(). Here's the example code
> > (without the error handling) of the sorting function:
> >
> > static int debianversioncompare(UNUSED(DB *db), const DBT *a, const DBT *b)
> > {
> > char *a_version, *b_version;
> > int versioncmp;
> >
> > binaries_getversion(a->data, &a_version);
> > binaries_getversion(b->data, &b_version);
> > dpkgversions_cmp(a_version, b_version, &versioncmp);
> > return versioncmp;
> > }
> >
> > Do you have a suggestion how to improve this function?
>
> It sounds quite slow either way. Perhaps the way to go is instead
> changing the data format, like having the version first (perhaps even in
> preparsed format to speed things up).
Good idea, but is this function really time critical? It should be only
called when comparing duplicate keys (which shouldn't happen that often,
does it?). How do you want to preparse the version?
How would the data format change? Currently the database value contains
just the control junk. We could put the pair (version, control) as value
into the database. How should the pair separated? Maybe with a null
character? Then we could just use the pointer to the value as version
string (the null character from the pair separation would also be used
to terminate the string).
--
Benjamin Drung
System Developer
ProfitBricks GmbH - The IaaS-Company
Greifswalder Str. 207
D - 10405 Berlin
Mail: benjamin.dr...@profitbricks.com
Fax: +49 30 577 008 598
URL: http://www.profitbricks.com
Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B.
Geschäftsführer: Andreas Gauger, Achim Weiss.
diff --git a/binaries.c b/binaries.c
index e66803d..74b4224 100644
--- a/binaries.c
+++ b/binaries.c
@@ -216,6 +216,20 @@ static inline retvalue calcnewcontrol(const char *chunk, const char *packagename
return RET_OK;
}
+retvalue binaries_getpackage(const char *control, char **package) {
+ retvalue r;
+
+ r = chunk_getvalue(control, "Package", package);
+ if (RET_WAS_ERROR(r))
+ return r;
+ if (r == RET_NOTHING) {
+ fprintf(stderr, "Missing 'Package' field in chunk:'%s'\n",
+control);
+ return RET_ERROR;
+ }
+ return r;
+}
+
retvalue binaries_getversion(const char *control, char **version) {
retvalue r;
diff --git a/binaries.h b/binaries.h
index ff1a9e6..a44bfe1 100644
--- a/binaries.h
+++ b/binaries.h
@@ -14,6 +14,7 @@
/* Functions for the target.h-stuff: */
+get_package binaries_getpackage;
get_version binaries_getversion;
get_installdata binaries_getinstalldata;
get_architecture binaries_getarchitecture;
diff --git a/chunks.c b/chunks.c
index ca1fd
Bug#737383: maildrop: notmuch complains about maildrop delivered messages
control:severity 737383 wishlist control:tags 737383 wontfix control:retile 737383 "Remove mbox-style From_ line before the first header line" I checked this with the upstream. Short answer: This is the design decision by the upstream. Please use "reformail -f0" On Sun, Feb 02, 2014 at 12:36:25PM +0200, Andrei POPESCU wrote: > Package: maildrop > Version: 2.7.1-1 ... > I'm using maildrop to deliver to various Maildirs (which are then > indexed with notmuch and read with mutt). As of 2.7.1-1 maildrop adds on > top of any message a header like: > > From amp@sid.nuvreauspam Sun Feb 2 12:28:13 2014 First, in the new manpage of maildir under DESCRIPTION: maildrop does not accept an mbox-style From_ line before the first header line. maildrop does not accept leading empty lines before the first non-blank header line. If the message can possibly start with empty lines, and a From_ line, use reformail -f0 to remove any initial empty lines, and replace a From_ line with a proper “Return-Path:” header; then pipe it to maildrop. Here is a quoted message from the upstream: | The addition of this was announced but not included in upstream | changelog. | http://sourceforge.net/mailarchive/message.php?msg_id=31458904 | | Basically, if the mail server is giving maildrop a message with the | From_ line, maildrop no longer gets rid of it. The change is to either | reconfigure the mail server so that it no longer attaches a From_ line | to the message, or use reformail to get rid of it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737354: retext: Missing dependency on python3-markdown | python3-docutils.
Hi, On Sun, Feb 2, 2014 at 2:27 AM, Aleksej wrote: > The version of ReText in wheezy depends on > python-markdown | python-docutils, and also recommends them. > > The package in jessie/sid depends on python3-markups, but python3-markups > 0.4-1 only **recommends** python3-docutils and python3-markdown. ReText can work without any built-in markups (using only custom ones). Also it can be used in plain text mode. I think the current Recommends: field is right. Also I won't like the idea of hard-coding any markup names in ReText, as new markups may appear (such as Textile, which is now supported in PyMarkups). -- Dmitry Shachnev -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#512974: reprepro: please consider adding a timestamp to list output
On So, 2009-01-25 at 19:40 +0100, Bernhard R. Link wrote: > * Marc Haber [090125 16:24]: > > It would be nice to see in a list output when a package was included > > into the archive. This would greatly help cleaning up archives. > > I fear that information is not available, and changing the database to > add it would need incompatible changes to the database format. I second the request. It would be nice to have the date from the changes file in the database. Couldn't Date just be copied from the changes file into the control chunk? Bug #570623 requires a change in the database format which might be a good point to also implement this feature. -- Benjamin Drung System Developer ProfitBricks GmbH - The IaaS-Company Greifswalder Str. 207 D - 10405 Berlin Mail: benjamin.dr...@profitbricks.com Fax: +49 30 577 008 598 URL: http://www.profitbricks.com Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 125506 B. Geschäftsführer: Andreas Gauger, Achim Weiss. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736294: [pkg-php-pear] Bug#736294: fixed in pkg-php-tools 1.10
Hi Guys, On 02/01/2014 08:21 PM, David Prévot wrote: > Hi, > > Le 01/02/2014 12:07, Andreas Beckmann a écrit : >> On 2014-01-29 22:45, Mathieu Parent wrote: >>> It is the case for packages migrated from dh-make-php to pkg-php-tools. > >>> I don't really agree to put tests on /usr/share/doc (where they can be >>> compressed and thus unusable). >>> >>> There is a patch for pkg-php-tools to remove the tests completely >>> (#732641). This can be the solution. > >> Good to see this fixed. > >> How can we easily detect packages that need to be rebuilt against the >> updated helper? Will binNMUs be sufficient or will this affect arch:all >> packages? > >> The php packages listed in > >> https://piuparts.debian.org/testing2sid/installs_over_symlink_issue.html >> https://piuparts.debian.org/wheezy2jessie/installs_over_symlink_issue.html > >> may be a starting point. > > Among a few others, I notice some packages recently uploaded by Dario > (php-net-imap, php-net-ipv6, php-net-url2, php-net-whois, php-validate, > and php-xml-rpc2), CCed. Since most of those packages are probably > arch:all, they will require a sourceful upload anyway. > > Regards > > David > Please, confirm when clear, if it's necessary that I make a new upload of all the enumerated packages or any other step we want me to take in order to have this issue solved, ok? Thanks all for taking a look to this issue. Regards, -- Dario Minnucci Phone: +34 902884117 | Fax: +34 902024417 | Support: +34 80745 Key fingerprint = BAA1 7AAF B21D 6567 D457 D67D A82F BB83 F3D5 7033 signature.asc Description: OpenPGP digital signature
Bug#736360: lintian: do not warn about doxygen embedding jquery
On Mon, Feb 03, 2014 at 12:39:10PM +0100, Jakub Wilk wrote: > Security is not the only issue here. jquery.js created by Doxygen is > minified, so there's a risk that we ship it without source. Thanks for highlighting the issue. Fortunately we already have a tool to work around this issue. It is called Built-Using. Last time I checked whether (dh_)doxygen should be simplifying the process of adding the Built-Using headers, I achieved no consensus on the value of such a change and discussion on what Built-Using is supposed to mean was still ongoing. If there is consensus now, we can use that tool to address this particular issue. Do you think that this would adequately address the availability of source? Do you happen to have an alternative proposal in mind? Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735340: Non free w3m valid icons
I think that picture file is not used at all; I sent an email to the upstream-maintainer asking him to consider removing it. Christophe signature.asc Description: Digital signature
Bug#737516: reprepro: Please allow storing outdir in a configuration file
Package: reprepro Version: 4.13.1-1 Severity: wishlist I want to put the public readable dist and pool directories into a separate directory to not make the conf, db, and logs directories public. reprepro provides a --outdir option for that, but this requires to specify the directory for every reprepro call. I would like to store the output directory in a configuration file (maybe in conf/distributions?). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729759: New flex available on mentors
Hi Manoj and Guillem, I have packaged (since I didn't receive answers so far) the new flex release, that closes 3 or maybe more bugs. I made it available on mentors, I hope to have a feedback from you, since you are the maintainers and/or you have uploaded the last release. Also would be nice to merge the ubuntu multiarch work, but this I think is more than a NMU possibility, and moreover introduces a new package that needs to go to the new queue. What do you think about? Best regards, [1] https://mentors.debian.net/package/flex Gianfranco
Bug#737517: stunnel4: Should block OpenSSL 1.0.1f (needs new build)
Package: stunnel4 Version: 3:4.53-1.1 Severity: important Dear Maintainer, After the upgrade to openssl 1.0.1f-1, stunnel4 no longer starts: Starting SSL tunnels: Clients allowed=32000 stunnel 4.53 on x86_64-pc-linux-gnu platform Compiled with OpenSSL 1.0.1e 11 Feb 2013 Running with OpenSSL 1.0.1f 6 Jan 2014 Update OpenSSL shared libraries or rebuild stunnel Threading:PTHREAD SSL:+ENGINE+OCSP Auth:LIBWRAP Sockets:POLL+IPv6 Reading configuration from file /etc/stunnel/elasticsearch.conf Failed to initialize compression method str_stats: 9 block(s), 179 data byte(s), 522 control byte(s) Fix: - Downgrade OpenSSL to 1.0.1e-2 - Rebuild stunnel with OpenSSL 1.0.1f-1 I've resolved the issue manually on my end, but please have a look and provide a new build if necessary. Thanks for your time and work! - Michel -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable'), (550, 'experimental'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.11-2-686-pae (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages stunnel4 depends on: ii adduser 3.113+nmu3 ii libc6 2.17-97 ii libssl1.0.0 1.0.1f-1 ii libwrap0 7.6.q-25 ii netbase 5.2 ii openssl 1.0.1f-1 ii perl-modules 5.18.2-2 ii zlib1g1:1.2.8.dfsg-1 stunnel4 recommends no packages. Versions of packages stunnel4 suggests: ii logcheck-database 1.3.16 -- Configuration Files: /etc/default/stunnel4 changed [not included] /etc/ppp/ip-down.d/0stunnel4 [Errno 13] Permission denied: u'/etc/ppp/ip-down.d/0stunnel4' /etc/ppp/ip-up.d/0stunnel4 [Errno 13] Permission denied: u'/etc/ppp/ip-up.d/0stunnel4' /etc/stunnel/stunnel.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737144: cvs2svn: FTBFS with rcs 5.9
On 01/30/2014 05:01 PM, Stephen Oberholtzer wrote: > Package: cvs2svn > Version: 2.4.0 > Severity: serious > Tags: patch > Justification: fails to build from source (but built successfully in the past) > > Dear Maintainer, > > I hope I'm doing this correctly. > > The cvs2svn package fails to build from source with recent versions of rcs > due to a failed internal test. This is caused by the rcs v5.9 'co' command > deprecating '-V' in favor of '--version'. When cvs2svn executes 'co -V' to > test for its existence, co outputs a warning on stderr, which cvs2svn > mistakes for a failure. > > Attached is a patch that corrects this problem, so that the package builds. I am the upstream maintainer of cvs2svn. The change that you have proposed was made in cvs2svn "trunk" in December 2013. So I agree that it is OK. If it would be helpful, I could make an upstream release from the current trunk version (i.e., including this change). Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737518: ftp.debian.org: cruft report should mark broken B-D as arch-specific if they apply to some architectures only
Package: ftp.debian.org Severity: normal See the discussion starting here https://lists.debian.org/debian-release/2014/02/msg7.html The cruft-report contained the following broken build-depends for libunwind7-dev: gcc-3.3: libunwind7-dev (>= 0.98.5-1) gcc-4.4: libunwind7-dev (>= 0.98.5-6) gcc-4.6: libunwind7-dev (>= 0.98.5-6) gcc-4.7: libunwind7-dev (>= 0.98.5-6) gcc-4.8: libunwind7-dev (>= 0.98.5-6) ... but these are actually [ia64] only. Having them reported as gcc-3.3: libunwind7-dev (>= 0.98.5-1) [ia64] and so on would have avoided this confusion. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737519: ftp.debian.org: cruft report does not show source packages with no binary packages
Package: ftp.debian.org Severity: normal ifenslave-2.6 is now an empty source package, its binary package ifenslave-2.6 is now a transitional package built from src:ifenslave. Shouldn't such packages get cleaned up automatically? http://packages.qa.debian.org/i/ifenslave-2.6.html Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729942: RFS: crossroads/2.81-1 [ITA]
Hi all I'm still looking for a sponsor for this package. Axel Beckert provided me with very good feedback but is not responding anymore. I would appreciate if someone has time and would have a look at my package. Thanks Alexander On 18.11.2013 23:10, Alexander Bösch wrote: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "crossroads" * Package name: crossroads Version : 2.81-1 Upstream Author : Karel Kubat ka...@e-tunity.com * URL : http://crossroads.e-tunity.com * License : GPLv3 Section : net It builds those binary packages: crossroads - open source load balance and fail over utility for TCP based serv To access further information about this package, please visit the following URL: http://mentors.debian.net/package/crossroads Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/crossroads/crossroads_2.81-1.dsc More information about crossroads can be obtained from http://crossroads.e-tunity.com Changes since the last upload: * Based on crossroads version 2.81 * Package adopted (Closes: #607322) * Deamonized crossroads (Closes: #701210) * Watch file added * Eliminated various lintian errors Regards, Alexander Bösch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735832: wyrd: FTBFS: configure: error: Wyrd requires OCaml version 3.08 or greater.
control: tags -1 fixed-upstream Hi, This is apparently bug in configure(.in), and fixed in new upstream version 1.4.6. see http://pessimization.com/software/wyrd/ Please update package (or I'd update it) -- Hideki Yamane
Bug#735883: Bug fix commit for python-csb
Since I haven't been able to reproduce the bug locally yet and it's already been a couple of weeks, I went ahead and applied the fix that's been suggested by various developers so the package is not held back anymore. If anyone could check the package and upload, I'd be grateful. Best, Tomás -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737223: mumble: run time linker fails on new libprotobuf8
Hi all, > Okay, we've figured out that this is an issue with libprotobuf8. > mumble 1.2.4-0.1 works with libprotobuf8 2.5.0-3 and -5, but not -6 or -7. I just rebuilt mumble and that was enough to get it working. ii libprotobuf-dev:amd64 2.5.0-7 amd64protocol buffers C++ library (development files) ii libprotobuf-lite8:amd64 2.5.0-7 amd64protocol buffers C++ library (lite version) rc libprotobuf7 2.4.1-3 amd64protocol buffers C++ library ii libprotobuf8:amd642.5.0-7 amd64protocol buffers C++ library ii mumble1.2.4-0.1 amd64Low latency VoIP client To me, this is just an ABI breakage from libprotobuf8. A simple bin-NMU should be enough to resolve the situation. Best regards, -- Gonéri pgpt0DSGAESLQ.pgp Description: PGP signature
Bug#736294: [pkg-php-pear] Bug#736294: Bug#736294: fixed in pkg-php-tools 1.10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Dario, Le 03/02/2014 08:28, Dario Minnucci a écrit : > On 02/01/2014 08:21 PM, David Prévot wrote: >> Le 01/02/2014 12:07, Andreas Beckmann a écrit : It is the case for packages migrated from dh-make-php to pkg-php-tools. e php packages listed in >> >>> https://piuparts.debian.org/testing2sid/installs_over_symlink_issue.html >>> https://piuparts.debian.org/wheezy2jessie/installs_over_symlink_issue.html >> >>> may be a starting point. >> >> Among a few others, I notice some packages recently uploaded by Dario >> (php-net-imap, php-net-ipv6, php-net-url2, php-net-whois, php-validate, >> and php-xml-rpc2), CCed. Since most of those packages are probably >> arch:all, they will require a sourceful upload anyway. > Please, confirm when clear, if it's necessary that I make a new upload of all > the enumerated > packages Yes, please rebuild the affected packages with pkg-php-tools >= 1.10 (you can double check with the piupart lists that I didn’t miss any of your packages), and verify that the tests directory is gone. Sorry we didn’t spot this issue sooner (we manually removed the tests from most packages, hence the lack of this issue popping up too much). Thanks in advance. Regards David -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJS75qXAAoJEAWMHPlE9r08x/MIAI087n1bIiyjqSnFGrnTVJm6 jd8EzWK2RYEz9hCwuYKuKk9gC8n+Sko372r/6uIErrW+ZY/nhvhxwCyV+PYzPxwV W0KRaa3FK+JOokjWAWlk6QfChGELcx+u229E1RnT2twWACJfsN+2X6mJZHzxtIT+ hj/rnZqLiW02LUwrB/O+U6m34kwfcbSlkJ5QWqF7xRFZe2t6/udCB3bzWlRQr4hU 5TlwLMJ+K/3Sd6cR3zfRs9eIcm0QG+Td0BgIOy44BZoymgeGN2xOPn9F6tWlr0fO Hioc964oVKb25O5jI8H/jEKFET0T972Onxd0MsrTO6nn2feUZAyxlOD3TW6ZDW8= =Tvpc -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#737520: dh-make: Please update debian/rules for fortify options
Package: dh-make Version: 0.63 Severity: normal Tags: patch Please consider to replace debian/rules file templates: rules.dh7 with the attached one. This is taken from the template file for my new debmake package to enhance build fortification for the packages build by the dh-make program. License is MIT license if you ask. But I think such simple standard interface code without customization lacks claim for copyright protection (Just like no one claims copyright over the "#!/bin/sh" line.) Regards, Osamu PS: The multiarch feature back port to dh-make was not easy for me. The auto debug package generation addition may be do-able but introduces more command line choices. This command line UI is not designed for the combination such as -dbg + library + binary executable + -doc... so I gave up updating this part of dh-make. -- 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 Versions of packages dh-make depends on: ii debhelper 9.20131227 ii dpkg-dev 1.17.6 ii make 3.81-8.3 ii perl 5.18.2-2 dh-make recommends no packages. Versions of packages dh-make suggests: ii build-essential 11.6 -- no debconf information #!/usr/bin/make -f # See debhelper(7) (uncomment to enable) # output every command that modifies files on the build system. #DH_VERBOSE = 1 # exclude VCS paths if needed. #DH_ALWAYS_EXCLUDE=CVS:.svn:.git # see FEATURE AREAS in dpkg-buildflags(1)) #export DEB_BUILD_MAINT_OPTIONS = hardening=+all # see ENVIRONMENT in dpkg-buildflags(1)) # package maintainers to append CFLAGS #export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic # package maintainers to append LDFLAGS #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed %: dh $@ #DH7_ADDON#
Bug#737521: fcitx-mozc cannot be loaded
Package: fcitx-mozc Version: 1.13.1651.102-1+b1 Severity: grave Justification: renders package unusable Hi, fcitx suddenly stopped working and committed suicide ;-) (ERROR-7241 /build/fcitx-Z_BmR4/fcitx-4.2.8.3/src/lib/fcitx/ime.c:303) IM: open /usr/lib/x86_64-linux-gnu/fcitx/fcitx-mozc.so fail /usr/lib/x86_64-linux-gnu/fcitx/fcitx-mozc.so: undefined symbol: _ZN6google8protobuf18GoogleOnceInitImplEPlPNS0_7ClosureE Seems that some re-compilation or so is needed. Thanks for your work on this great piece! Norbert -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-rc8+ (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages fcitx-mozc depends on: ii fcitx-bin 1:4.2.8.3-2+b1 ii fcitx-data 1:4.2.8.3-2 ii fcitx-modules 1:4.2.8.3-2+b1 ii libc6 2.17-97 ii libprotobuf82.5.0-7 ii libstdc++6 4.8.2-14 ii mozc-data 1.13.1651.102-1 ii mozc-server 1.13.1651.102-1+b1 ii tegaki-zinnia-japanese 0.3-1 Versions of packages fcitx-mozc recommends: ii fcitx 1:4.2.8.3-2 ii mozc-utils-gui 1.13.1651.102-1+b1 fcitx-mozc 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#737522: RM: qtjsbackend-opensource-src -- ROM; Superseded by qtdeclarative on Qt 5.2.0
Package: ftp.debian.org Severity: normal Hi! src:qtjsbackend-opensource-src is no longer needed with Qt 5.2.0 already available in unstable. If I understand correctly, if removed from unstable, the source will be kept in testing until 5.2.0 migrates. If that's correct, please remove it form unstable. Thanks in advance, Lisandro. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737507: libqt5qml5 depends on qtjsbackend-abi-5-1-0 which is provided by the dev package with many dependencies
On Monday 03 February 2014 12:26:54 Dmitry Baryshev wrote: > Package: libqt5qml5 > Version: 5.1.1-1 > > See http://packages.debian.org/jessie/libqt5qml5 > > libqt5qml5l requires qtjsbackend-abi-5-1-0 which is provided by > libqt5v8-5-private-dev, and libqt5v8-5-private-dev requires tons of > development packages. In Sid qtjsbackend-abi-5-1-0 is required only on > armhf platform, see http://packages.debian.org/sid/libqt5qml5 This is not a bug but a glitch due to the ongoing transition. qtjsbackend is not needed anymore with 5.2.0. I'll ask for it's removal as soon as we get everything built. -- 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#737523: ITP: php5-msgpack -- PHP extension for interfacing with MessagePack
Package: wnpp Severity: wishlist Owner: Mathieu Parent Package name: msgpack Version : 0.5.5 Upstream Author : Advect, Xinchen Hui URL : http://pecl.php.net/ License : New BSD Programming Lang: PHP Description : PHP extension for interfacing with MessagePack This extension provide API for communicating with MessagePack serialization. I'm packaging this as part of Horde5 packaging. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737524: ITP: php5-igbinary -- igbinary extension
Package: wnpp Severity: wishlist Owner: Mathieu Parent Package name: igbinary Version : 1.1.1 Upstream Author : Pierre Joye, Teddy Grenman URL : http://pecl.php.net/ License : PHP like license Programming Lang: PHP Description : igbinary extension Igbinary is a drop in replacement for the standard php serializer. Instead of time and space consuming textual representation, igbinary stores php data structures in a compact binary form. Savings are significant when using memcached or similar memory based storages for serialized data. I'm packaging this as part of Horde5 packaging. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737525: Fatal: Initialization Error: Could not initialize applet. For more information click "more information button".
Package: icedtea-6-plugin Severity: important Version: 1.4-3~deb7u2 For some reason if I go to page: http://www.java.com/verify/ The java plugin loads but returns an exception: The folloing exception has occured. For more information, try to launch the browser from the command line and examine the output. For even more information you can visit http://icedtea.classpath.org/wiki/IcedTea-Web and follow the steps described there on how to obtain necessary information to file bug Another available info: IcedTea-Web Plugin version: 1.4 (1.4-3~deb7u2) 03/02/14 14:47 Exception was: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet. For more information click "more information button". at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:734) at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:662) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:914) Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Unknown Main-Class. Could not determine the main class for this application. at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:708) at net.sourceforge.jnlp.runtime.JNLPClassLoader. (JNLPClassLoader.java:249) at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:382) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:444) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:420) at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:700) ... 2 more This is the list of exceptions that occurred launching your applet. Please note, those exceptions can originate from multiple applets. For a helpful bug report, be sure to run only one applet. 1) at 03/02/14 14:46 net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Unknown Main-Class. Could not determine the main class for this application. at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:708) at net.sourceforge.jnlp.runtime.JNLPClassLoader. (JNLPClassLoader.java:249) at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:382) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:444) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:420) at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:700) at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:662) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:914) 2) at 03/02/14 14:46 net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet. For more information click "more information button". at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:734) at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:662) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:914) Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Unknown Main-Class. Could not determine the main class for this application. at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:708) at net.sourceforge.jnlp.runtime.JNLPClassLoader. (JNLPClassLoader.java:249) at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:382) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:444) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:420) at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:700) ... 2 more -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728059: RFS: gnome-shell-pomodoro/0.6.20131027-1 [ITA]
Dear Vincent, > One last nitpick (sorry!) is that other gnome-shell extensions > packaged in Debian seem to prefix their packages with > "gnome-shell-extension-" (e.g. gnome-shell-extension-weather, > gnome-shell-extension-autohidetopbar), so can you please do the same > for your binary package as well, i.e. rename it > gnome-shell-extension-pomodoro? On that point I'd like to double check with you. Indeed, the app is currently an gnome-shell extension. But in the latest version (using gnome-shell 10), it has been transformed to an independent app based on gnome-shell according to upstream site. So should I be renaming it later? Keep the new name once it has been transformed to an app with the 0.10.0? Best regards, Joseph -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737257: [pkg-horde] Bug#737257: php-horde-pack: recommends packages not in the archive
Control: block -1 by 737523 737524 hi Ansgar, I am currently packaging the 2 missing pieces. Regards -- Mathieu Parent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737264: /usr/share/man/man7/systemd.directives.7.gz: systemd.directives(7) is empty
Am 03.02.2014 12:42, schrieb Michael Biebl: > Am 02.02.2014 23:23, schrieb Sam Morris: > >> Hm, I think we disagree on the desired results. :) I don't mean that the >> man page is absolutely empty... I'm referring to the actaul list of each >> directive along with the man page in which it is documented. Sorry for >> being unclear. >> >> I'm attaching the man page from version 204-5 so you can see what I >> mean. > > Ok, I understand now what you mean. > > Not quite sure yet. Seems to be a problem of using out-of-tree builds. > At least I can *not* reproduce the issue with an in-tree build. > > When doing the oot build I'm getting a lot of those warnings: > > > make[2]: Circular man/systemd.directives.xml <- man/bootup.xml > dependency dropped. > make[2]: Circular man/systemd.directives.xml <- man/daemon.xml > dependency dropped. > make[2]: Circular man/systemd.directives.xml <- man/halt.xml dependency > dropped. > ... > > See also the 204-6 build > https://buildd.debian.org/status/fetch.php?pkg=systemd&arch=i386&ver=204-6&stamp=1388514325 > > In comparison from the 204-5 build, there are no such warnings about > circular dependencies: > https://buildd.debian.org/status/fetch.php?pkg=systemd&arch=i386&ver=204-5&stamp=1379939127 > > > I wonder if something in our toolchain has changed which causes that > regression. My bet would be changes in automake > Actually, the regression in 204-6 has a different reason: When Michael S. did the upload for 204-6, he mistakenly did not use the orig.tar.xz tarball from upstream, but instead an orig.tar.gz was created from the git clone. The upstream orig.tar.xz has a pregenerated man/systemd.directives.xml, while the git snapshot in 204-6 has not. Instead this file is generated during build. We use use out-of-tree builds (for the deb and udeb) and this is where the build goes wrong. Once we upload 204-7 using the correct orig.tar.xz again, this issue will go away. That said, we might actually look into fixing this out-of-tree build issue for man/systemd.directives.xml. Zbyszek, in case you want to reproduce the issue: - git clone the systemd repo - cleanup any pregenerated files: git -xdf, - ./autogen.sh - use out-of-tree build: mkdir build && cd build && ../configure && make -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#708697: not fixed (udev dependency now causing FTBFS)
On 01/02/2014 19:42, Steven Chamberlain wrote: > Control: forcemerge 708697 736608 > > Ah, I filed a duplicate bug for this by mistake, and already submitted a > patch: http://bugs.debian.org/736608 My bad... A. Maitland, please use Steven's patch, it is more complete than mine. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736958: [oss-security] Re: CVE request: temporary file issue in Passenger rubygem
On Thu, 30 Jan 2014 09:26:33 -0500 (EST) cve-ass...@mitre.org wrote: > > If a local attacker can predict this filename, and precreates a > > symlink with the same filename that points to an arbitrary directory > > with mode 755, owner root and group root, then the attacker will > > succeed in making Phusion Passenger write files and create > > subdirectories inside that target directory. > > > > It is fixed in upstream version 4.0.33. > > > > https://github.com/phusion/passenger/commit/34b1087870c2bf85ebfd72c30b78577e10ab9744 ... > Use CVE-2014-1831 for the vulnerability with the "before 4.0.33" > affected versions. > > Use CVE-2014-1832 for the vulnerability with the "4.0.33 and earlier" > affected versions. Note that while the original CVE request mentions version 4.0.33, that seems like a typo as upstream NEWS file indicates: Fixed versions: 4.0.37. Consequently, the above should be "before 4.0.37" and "4.0.37 and earlier" (or "before 4.0.38"). -- Tomas Hoger / Red Hat Security Response Team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737051: python-logilab-common: insecure use of /tmp
Thanks for the report, Jakub.
On Wed, Jan 29, 2014 at 20:27:58 +0100, Jakub Wilk wrote:
> Package: python-logilab-common
> Version: 0.60.1-1
> Severity: important
> Tags: security
>
> I saw these gems in logilab/common/pdf_ext.py:
>
> def extract_keys_from_pdf(filename):
> # what about using 'pdftk filename dump_data_fields' and parsing the
> output ?
> os.system('pdftk %s generate_fdf output /tmp/toto.fdf' % filename)
> lines = file('/tmp/toto.fdf').readlines()
> return extract_keys(lines)
>
> def fill_pdf(infile, outfile, fields):
> write_fields(file('/tmp/toto.fdf', 'w'), fields)
> os.system('pdftk %s fill_form /tmp/toto.fdf output %s flatten' % (infile,
> outfile))
>
Tracked upstream as http://www.logilab.org/ticket/207561
On Wed, Jan 29, 2014 at 21:21:49 +0100, Jakub Wilk wrote:
> More vulnerable code in logilab/common/shellutils.py:
>
> class Execute:
> """This is a deadlock safe version of popen2 (no stdin), that returns
> an object with errorlevel, out and err.
> """
>
> def __init__(self, command):
> outfile = tempfile.mktemp()
> errfile = tempfile.mktemp()
> self.status = os.system("( %s ) >%s 2>%s" %
> (command, outfile, errfile)) >> 8
> self.out = open(outfile, "r").read()
> self.err = open(errfile, "r").read()
> os.remove(outfile)
> os.remove(errfile)
>
> From the tempfile.mktemp() docstring: “This function is unsafe and
> should not be used. The file name refers to a file that did not
> exist at some point, but by the time you get around to creating it,
> someone else may have beaten you to the punch.”
>
Tracked as http://www.logilab.org/ticket/207562
Cheers,
Julien
--
Julien Cristau
Logilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737526: Vbulletin Chromium error
Package: Chromium Version:31.0.1650.63-1~deb7u1 Wysiwyg text editor doesn't work in Chromium. In other browsers it works. I'm usingDebian GNU/Linux 7.3, kernel 3.2.0-4-686-paeand libc6 2.13-38 + deb7u.
Bug#727708: Vote sysvinit 4 jessie
I'd like to make one last plea in support of sysvinit, since I see no compelling reason to rush to something else in time for jessie. Firstly, it is already much easier to use alternative init systems since the TC discussion really got going in December. init-select makes it super easy to swap between sysvinit and systemd. There is now less reason to change the default since the user can do so him or herself. Secondly, leaving sysvinit in place makes it possible to gauge the organic adoption of the newer init systems. In the future, when it really makes sense to change the default, concrete facts like popcon numbers the number of packages providing support can be used to support the decision, rather than smells and feels. Thirdly, it lets the project evolve its own meritocratic solution. Soon enough there will be a strong desire for gnome to drop support for all other inits, and slowly over time fewer packages will support the non-winning init systems, which can eventually be fully deprecated slowly over time. It also gives the alternatives more time to "catch up". openrc was easily discarded from the discussion since the packaging was not yet complete, but that isn't really fair from a technical viewpoint. upstart has some technical issues that might improve given more time and the possibility that it may still be under consideration. Finally, it is worth considering that there is very little chance for upstart to win this particular vote. Given the 4:4 systemd:upstart split and existing statements from the 4 on the systemd side, there is very little chance that they will vote upstart high. Hence those TC members that don't want to see its default should be trying to figure out how to get 1 of the 4 to vote something else above systemd. sysvinit is probably the only option that has any possibility of getting 5 or more votes over something else. For that reason, the upstart supporters should really be campaigning sysvinit to the 4 systemd supporters. At least if sysvinit wins, that gives upstart another cycle to get in better shape, rather than being disqualified now. So, is sysvinit the status quo? Yes and no. Yes its the same init system we've seen for a long time. No, because concurrently all of the other systems are becoming usable and more viable options that are easy enough to switch to. So, for all those reasons, please vote sysvinit for jessie. 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#737527: subversion: Replace GCJ by OpenJDK in Subversion JavaHL build
Package: subversion Version: 1.8.5-2 Severity: wishlist Dear Maintainer, subversion build still depends on GCJ. I think OpenJDK should be used instead, because GCJ is a very outdated compiler. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737528: varnish init script doesn't warn on already running instance, fails cryptically
Package: varnish Version: 3.0.2-2+deb7u1 Severity: wishlist When attempting to start varnish, using the init script, it 'fails' to start, with no useful error message, if there is already a varnish instance running; /etc/init.d/varnish start Starting HTTP accelerator: varnishd failed! I suggest that if possible, the init script be patched to detect this, and provide a useful error. -- All postal correspondence to: The Positive Internet Company, 24 Ganton Street, London. W1F 7QY *Follow us on Twitter* @posipeople The Positive Internet Company Limited is registered in England and Wales. Registered company number: 3673639. VAT no: 726 7072 28. Registered office: Northside House, Mount Pleasant, Barnet, Herts, EN4 9EE. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726871: gst-plugins-bad0.10: FTBFS -- stdafx.h in libalglib-dev conflicts with one in libmodplug-dev
> Source: gst-plugins-bad0.10 > Version: 0.10.23-7.1 > Severity: serious > Tags: patch > Justification: fails to build from source (but built successfully in the > past) > > Build fails here: > > This occurs in native build. In order to avoid conflict, gstmodplug.cc > should include . gst-plugins-bad0.10 also FTBFSes in stable. This is related to the libmodplug update in DSA 2751. Patch attached. Cheers, Moritz -- Moritz Mühlenhoff Open Source Software Engineer Univention GmbH be open. Mary-Somerville-Str.1 28359 Bremen Tel. : +49 421 22232-0 [.] Fax : +49 421 22232-99 muehlenh...@univention.de http://www.univention.de Geschäftsführer: Peter H. Ganten HRB 20755 Amtsgericht Bremen Steuer-Nr.: 71-597-02876 diff -Naur gst-plugins-bad0.10-0.10.23.orig/debian/patches/fix-compat-with-updated-libmodplug.patch gst-plugins-bad0.10-0.10.23/debian/patches/fix-compat-with-updated-libmodplug.patch --- gst-plugins-bad0.10-0.10.23.orig/debian/patches/fix-compat-with-updated-libmodplug.patch 1970-01-01 01:00:00.0 +0100 +++ gst-plugins-bad0.10-0.10.23/debian/patches/fix-compat-with-updated-libmodplug.patch 2014-02-03 12:56:52.522074970 +0100 @@ -0,0 +1,16 @@ +Description: Fix compatibility with current libmodplug + libmodplug was updated to a new upstream release in DSA 2751. This patch + fixes a FTBFS with that new version. +Bug-Debian: http://bugs.debian.org/726871 + +--- gst-plugins-bad0.10-0.10.23.orig/ext/modplug/gstmodplug.cc gst-plugins-bad0.10-0.10.23/ext/modplug/gstmodplug.cc +@@ -50,7 +50,7 @@ + #define WORDS_BIGENDIAN 0 + #endif + +-#include ++#include + #include + + #include "gstmodplug.h" diff -Naur gst-plugins-bad0.10-0.10.23.orig/debian/patches/series gst-plugins-bad0.10-0.10.23/debian/patches/series --- gst-plugins-bad0.10-0.10.23.orig/debian/patches/series 2012-12-31 20:43:40.0 +0100 +++ gst-plugins-bad0.10-0.10.23/debian/patches/series 2014-02-03 12:55:16.609064887 +0100 @@ -12,3 +12,4 @@ 0017-opusdec-read-gain-from-the-right-place-in-the-header.patch 0020-opusenc-add-missing-mutex-unlock-on-error-path.patch 0030-really-fix-h264-parsing.patch +fix-compat-with-updated-libmodplug.patch
Bug#737529: gcc-4.8: __builtin_frame_address not working on ARM
Package: gcc-4.8
Version: 4.8.2-14
Severity: normal
__builtin_frame_address does not work as documented on ARM. For a value
greater or equal to 1 it returns a non null value but the returned
pointer does not seem to match a frame. See the attached testcase. With
tcc and clang it displays "__builtin_frame_address" while with gcc it
first displays "bfa1: %s" and then segfaults if the #if is removed.
Best regards,
Thomas Preud'homme
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: armhf (armv7l)
Kernel: Linux 2.6.38-ac2-ac100 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages gcc-4.8 depends on:
ii binutils2.24-3
ii cpp-4.8 4.8.2-14
ii gcc-4.8-base4.8.2-14
ii libc6 2.17-97
ii libcloog-isl4 0.18.1-3
ii libgcc-4.8-dev 4.8.2-14
ii libgmp102:5.1.3+dfsg-1
ii libisl100.12.1-2
ii libmpc3 1.0.1-1
ii libmpfr43.1.2-1
ii zlib1g 1:1.2.8.dfsg-1
Versions of packages gcc-4.8 recommends:
ii libc6-dev 2.17-97
Versions of packages gcc-4.8 suggests:
ii binutils [binutils-gold] 2.24-3
pn gcc-4.8-doc
pn gcc-4.8-locales
pn libasan0-dbg
pn libatomic1-dbg
pn libbacktrace1-dbg
pn libgcc1-dbg
pn libgomp1-dbg
pn libitm1-dbg
pn libquadmath-dbg
pn libtsan0-dbg
-- no debconf information#include
#include
void bfa3(ptrdiff_t str_offset)
{
printf("bfa3: %s\n", (char *)__builtin_frame_address(3) + str_offset);
}
void bfa2(ptrdiff_t str_offset)
{
printf("bfa2: %s\n", (char *)__builtin_frame_address(2) + str_offset);
bfa3(str_offset);
}
void bfa1(ptrdiff_t str_offset)
{
printf("bfa1: %s\n", (char *)__builtin_frame_address(1) + str_offset);
#if defined(__arm__) && !defined(__GNUC__)
bfa2(str_offset);
#endif
}
void builtin_frame_address_test(void)
{
char str[] = "__builtin_frame_address";
char *fp0 = __builtin_frame_address(0);
printf("str: %s\n", str);
bfa1(str-fp0);
}
int main(void)
{
builtin_frame_address_test();
return 0;
}
Bug#737264: /usr/share/man/man7/systemd.directives.7.gz: systemd.directives(7) is empty
On Mon, Feb 03, 2014 at 02:55:41PM +0100, Michael Biebl wrote: > Am 03.02.2014 12:42, schrieb Michael Biebl: > > Am 02.02.2014 23:23, schrieb Sam Morris: > > > >> Hm, I think we disagree on the desired results. :) I don't mean that the > >> man page is absolutely empty... I'm referring to the actaul list of each > >> directive along with the man page in which it is documented. Sorry for > >> being unclear. > >> > >> I'm attaching the man page from version 204-5 so you can see what I > >> mean. > > > > Ok, I understand now what you mean. > > > > Not quite sure yet. Seems to be a problem of using out-of-tree builds. > > At least I can *not* reproduce the issue with an in-tree build. > > > > When doing the oot build I'm getting a lot of those warnings: > > > > > > make[2]: Circular man/systemd.directives.xml <- man/bootup.xml > > dependency dropped. > > make[2]: Circular man/systemd.directives.xml <- man/daemon.xml > > dependency dropped. > > make[2]: Circular man/systemd.directives.xml <- man/halt.xml dependency > > dropped. > > ... > > I've seen this too, but only on Debian. > Zbyszek, in case you want to reproduce the issue: > - git clone the systemd repo > - cleanup any pregenerated files: git -xdf, > - ./autogen.sh > - use out-of-tree build: > mkdir build && cd build && ../configure && make I do out-of-tree build most of the time, so and in general everything works well. I just run those instruction on Fedora and the issue is not there (automake-1.13.4-5.fc20.noarch, make-3.82-19.fc20.x86_64, autoconf-2.69-14.fc20.noarch). It would be good to look where exactly this circular dependency comes from. Zbyszek -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737503: ruby2.0: Switching to ruby2.0 as /usr/bin/ruby breaks rdoc and testrb man pages.
Control: retitle -1 ruby2.0: missing manpages for rdoc and testrb Control: severity -1 normal Hello Scott, Thanks for your bug report. On Mon, Feb 03, 2014 at 08:07:00PM +1100, Scott Leggett wrote: > Package: ruby2.0 > Version: 2.0.0.353-1 > Severity: important > > Dear Maintainer, > > After installing ruby2.0 from unstable, I used `update-alternatives` to > switch the default interpreter, with the following result. > > $ sudo update-alternatives --config ruby > There are 3 choices for the alternative ruby (providing /usr/bin/ruby). > > SelectionPathPriority Status > > * 0/usr/bin/ruby1.9.1 51auto mode > 1/usr/bin/ruby1.8 50manual mode > 2/usr/bin/ruby1.9.1 51manual mode > 3/usr/bin/ruby2.0 50manual mode > > Press enter to keep the current choice[*], or type selection number: 3 > update-alternatives: using /usr/bin/ruby2.0 to provide /usr/bin/ruby > (ruby) in manual mode > update-alternatives: warning: skip creation of > /usr/share/man/man1/rdoc.1.gz because associated file > /usr/share/man/man1/rdoc2.0.1.gz (of link group ruby) doesn't exist > update-alternatives: warning: skip creation of > /usr/share/man/man1/testrb.1.gz because associated file > /usr/share/man/man1/testrb2.0.1.gz (of link group ruby) doesn't exist > > > Indeed, attempting to read the rdoc and testrb man pages doesn't work. > > `apt-file` also shows that the the 2.0.1 versions of the man pages don't > appear to be in the archive: > > $ apt-file search man1/rdoc > ruby1.8: /usr/share/man/man1/rdoc1.8.1.gz > ruby1.9.1: /usr/share/man/man1/rdoc1.9.1.1.gz > ruby1.9.3: /usr/share/man/man1/rdoc1.9.3.1.gz > > Thanks for your hard work bringing ruby 2 to Debian! Support for switching Ruby versions using alternatives is being discontinued, so that specific bit will never be fixed. However, the fact that we are missing manpages for rdoc and testrb is indeed a bug that needs to be fixed, since we want to switch to Ruby 2 as the default Ruby pretty soon. -- Antonio Terceiro signature.asc Description: Digital signature
Bug#737530: New version gives error in netrw
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: vim Version: 2:7.4.161-1 Severity: normal With the newest version netrw at least for scp is broken. When opening a remote file I get the error: "/tmp/vMnWZwB/0.pl" 22L, 328C Fehler beim Ausführen von "function netrw#Nread..netrw#NetRead..79_NetrwOptionRestore": Zeile 69: E354: Ungültiger Register Name: '*' Maybe that is a regression of #732091, I am not sure about. - -- Package-specific info: - --- real paths of main Vim binaries --- /usr/bin/vi is /usr/bin/vim.nox /usr/bin/vim is /usr/bin/vim.nox /usr/bin/gvim is /usr/bin/vim.gtk - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (800, 'unstable'), (600, 'oldstable'), (110, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11.6 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) (ignored: LC_ALL set to de_DE) Shell: /bin/sh linked to /bin/dash Versions of packages vim depends on: ii libacl1 2.2.52-1 ii libc62.17-97 ii libgpm2 1.20.4-6.1 ii libselinux1 2.2.2-1 ii libtinfo55.9+20140118-1 ii vim-common 2:7.4.161-1 ii vim-runtime 2:7.4.161-1 vim recommends no packages. Versions of packages vim suggests: ii exuberant-ctags [ctags] 1:5.9~svn20110310-6 ii vim-doc 2:7.4.161-1 ii vim-scripts 20130814 - -- no debconf information - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJS76osAAoJEKZ8CrGAGfaslvAL/3ZfP7uaXbOUGe6YrD8b4+XH jjyg0Nu0zv5JtS/dTl4QEzhD8EIeYEQXw6nIT5HqAdgohfgm+NCwdnU8EjNjHbt4 j/pRvzDtcd1GJWfWTYc4Kw6w+w6Llgt4BYSSAjkJOpUkH3fSLU8eFcUnh7GUjvPu CdrfnT3HXC/ISAGEAi0EcQ8kaQoK0LisCyTOkkFR7sD0GwOASzFu2Bt2qBaG1RYJ rE6VVzXj9wwNZqzhbxNLNLm7dz1nQzy5nFhK4dyF5HHFaVBDDbBbehOI5tmJ6dOC YEmR0u9attc4QKRIQ16OR0qHHxhvqlBq8ZTPWo5HEFprFdQ/PRpnYfhS/1cqdJnO c6cKPw7i69UnM6MFIQl9T0e0BJpe1XwzlxS1FCTQGd6CMPvnHSeewMPYQK9kV6KW /LBAzN1UcX+tXLvCGKUSzNnIAu3+p0j1cM6BDBE3ROX73g5otkD02z/NgfVpcdgH ABuRYqtMt7AtnZoM+VUp2rs/guuB1TUc4a68cATujg== =vRYN -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#727708: package to change init systems
Ian Jackson writes: > Yes. I would still prefer to see something like that. I don't > remember exactly what the objections were and I'm very very tired now > but perhaps something like > > We expect that Debian will continue to support mkultiple init > systems for the foreseeable future. > > would be acceptable to everyone ? I can't remember what the > objections were to my previous wording. Or some other phrasing. I've been trying to avoid making decisions now about what happens beyond jessie, but I would not object to including that text since I think it's true for at least some values of "support". Bdale pgp7oe97dt3Jx.pgp Description: PGP signature
Bug#737531: texmacs: Fatal error, invalid base url
Package: texmacs
Version: 1:1.0.7.18-1
Severity: important
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these lines ***
$ texmacs
base= /home/porton/.TeXmacs/texts/AGT/{C:\nppdf32Log\debuglog.txt}
TeXmacs] Fatal error, invalid base url
TeXmacs] Fatal unrecoverable error, TeXmacs server not yet started
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (x86_64)
Kernel: Linux 3.10-2-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/bash
Versions of packages texmacs depends on:
ii findutils4.4.2-7
ii ghostscript-x9.05~dfsg-8+b1
ii groff1.22.2-5
ii guile-1.8-libs 1.8.8+1-8
ii libc62.17-97
ii libfreetype6 2.5.2-1
ii libgcc1 1:4.8.2-14
ii libgmp10 2:5.1.3+dfsg-1
ii libltdl7 2.4.2-1.6
ii libqtcore4 4:4.8.5+git209-g718fae5+dfsg-1
ii libqtgui44:4.8.5+git209-g718fae5+dfsg-1
ii libstdc++6 4.8.2-14
ii locate 4.4.2-7
ii mlocate 0.26-1
ii texlive-base 2013.20140123-1
ii texlive-extra-utils 2013.20131219-1
ii texlive-font-utils 2013.20131219-1
ii texlive-math-extra 2013.20131219-1
ii texmacs-common 1:1.0.7.18-1
ii x11-apps 7.7+2
ii x11-session-utils7.7+1
ii x11-utils7.7+1
ii zlib1g 1:1.2.8.dfsg-1
Versions of packages texmacs recommends:
ii imagemagick8:6.7.7.10-7
ii ispell 3.3.02-6
ii libjpeg-progs 8d-2
ii librsvg2-bin 2.40.0-1
ii libtiff-tools 4.0.3-7
ii netpbm 2:10.0-15+b2
ii xfig 1:3.2.5.c-1
Versions of packages texmacs suggests:
ii python 2.7.5-5
ii wget1.15-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#735558: package zbackup FTBFS on big endian architectures
Tags: patch
User: debian-mips-dev-disc...@lists.alioth.debian.org
Usertags: mips-patch
Hello,
I have attached patch which is obtained from upstream:
https://github.com/zbackup/zbackup/compare/1.2...master
Patch adds support for big endian architectures.
Patched package was successfully built and tested on mips.
Backups made on little endian were successfully restored on little and big
endian.
Backups made on big endian were successfully restored on little and big endian.
Thanks!
Juricadiff -upNr zbackup-1.2-orig/debian/patches/big-endian-support.patch zbackup-1.2/debian/patches/big-endian-support.patch
--- zbackup-1.2-orig/debian/patches/big-endian-support.patch 1970-01-01 00:00:00.0 +
+++ zbackup-1.2/debian/patches/big-endian-support.patch 2014-02-03 14:03:14.0 +
@@ -0,0 +1,38 @@
+--- zbackup-1.2.orig/endian.hh
zbackup-1.2/endian.hh
+@@ -12,9 +12,7 @@
+ #include
+ #endif
+
+-#if __BYTE_ORDER != __LITTLE_ENDIAN
+-#error Please add support for architectures different from little-endian.
+-#endif
++#if __BYTE_ORDER == __LITTLE_ENDIAN
+
+ /// Converts the given host-order value to big-endian value
+ inline uint32_t toBigEndian( uint32_t v ) { return htonl( v ); }
+@@ -25,4 +23,24 @@ inline uint64_t toLittleEndian( uint64_t
+ inline uint32_t fromLittleEndian( uint32_t v ) { return v; }
+ inline uint64_t fromLittleEndian( uint64_t v ) { return v; }
+
++#elif __BYTE_ORDER == __BIG_ENDIAN
++
++// Note: the functions used are non-standard. Add more ifdefs if needed
++
++/// Converts the given host-order value to big-endian value
++inline uint32_t toBigEndian( uint32_t v ) { return v; }
++/// Converts the given host-order value to little-endian value
++inline uint32_t toLittleEndian( uint32_t v ) { return htole32( v ); }
++inline uint64_t toLittleEndian( uint64_t v ) { return htole64( v ); }
++/// Converts the given little-endian value to host-order value
++inline uint32_t fromLittleEndian( uint32_t v ) { return le32toh( v ); }
++inline uint64_t fromLittleEndian( uint64_t v ) { return le64toh( v ); }
++
++#else
++
++#error Please add support for architectures different from little-endian and\
++big-endian.
++
++#endif
++
+ #endif
diff -upNr zbackup-1.2-orig/debian/patches/series zbackup-1.2/debian/patches/series
--- zbackup-1.2-orig/debian/patches/series 1970-01-01 00:00:00.0 +
+++ zbackup-1.2/debian/patches/series 2014-02-03 14:03:14.0 +
@@ -0,0 +1 @@
+big-endian-support.patch
--- zbackup-1.2.orig/endian.hh
+++ zbackup-1.2/endian.hh
@@ -12,9 +12,7 @@
#include
#endif
-#if __BYTE_ORDER != __LITTLE_ENDIAN
-#error Please add support for architectures different from little-endian.
-#endif
+#if __BYTE_ORDER == __LITTLE_ENDIAN
/// Converts the given host-order value to big-endian value
inline uint32_t toBigEndian( uint32_t v ) { return htonl( v ); }
@@ -25,4 +23,24 @@ inline uint64_t toLittleEndian( uint64_t
inline uint32_t fromLittleEndian( uint32_t v ) { return v; }
inline uint64_t fromLittleEndian( uint64_t v ) { return v; }
+#elif __BYTE_ORDER == __BIG_ENDIAN
+
+// Note: the functions used are non-standard. Add more ifdefs if needed
+
+/// Converts the given host-order value to big-endian value
+inline uint32_t toBigEndian( uint32_t v ) { return v; }
+/// Converts the given host-order value to little-endian value
+inline uint32_t toLittleEndian( uint32_t v ) { return htole32( v ); }
+inline uint64_t toLittleEndian( uint64_t v ) { return htole64( v ); }
+/// Converts the given little-endian value to host-order value
+inline uint32_t fromLittleEndian( uint32_t v ) { return le32toh( v ); }
+inline uint64_t fromLittleEndian( uint64_t v ) { return le64toh( v ); }
+
+#else
+
+#error Please add support for architectures different from little-endian and\
+big-endian.
+
+#endif
+
#endif
Bug#737264: /usr/share/man/man7/systemd.directives.7.gz: systemd.directives(7) is empty
Am 03.02.2014 15:34, schrieb Zbigniew Jędrzejewski-Szmek: >> - use out-of-tree build: >> mkdir build && cd build && ../configure && make > I do out-of-tree build most of the time, so and in general everything > works well. I just run those instruction on Fedora and the issue is > not there (automake-1.13.4-5.fc20.noarch, make-3.82-19.fc20.x86_64, > autoconf-2.69-14.fc20.noarch). It would be good to look where exactly > this circular dependency comes from. Let me try with make 3.82 from experimental. Unstable currently has 3.81 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#727708: Init should be simple, secure, and get out of the way. It should not take over the system. We should not be forced to use one that does.
On Sat, 1 Feb 2014 19:11:52 -0500 (EST) Thilos Rich wrote: > Init should be simple, secure, and get out of the way. It should not take > over the system. We should not be forced to use an init that does. > > This man said it best: > wizardofbits.tumblr.com/post/45232318557/systemd-more-like-shit-stemd > > " > Init has one other job, which is to keep the process tables clean. See, any > process can create a copy of itself (called “forking” (don’t laugh) in Unix > terminology); this is usually a precursor to loading some other program. Any > process that runs to completion can deliver a status code to the process that > created it; the creating (or parent) process is said to “wait” on the status > code of the created (or child) process. But what happens if the parent > process dies before the child does? What happens is that init is designated > to be the adoptive parent of the “orphaned” process, and it waits for, and > discards, any status code that may be returned by the orphan on exit. This is > to prevent “zombie processes” – process table slots that are filled with > status codes but have no running programs attached to them. They are > undesirable because they take up process table space that could be used by > actual, running programs. > > > So it is important that init run well and not crash. > > > Now, in Unix system design, it is a generally understood principle that a big > task not be handled by a big program, but rather a collection of small > programs, each tackling one specific, well-defined component of the larger > task. You often hear the phrase “do one thing, and do it well” as a guiding > principle for writing a Unix program. One major reason for this is that a > small program has fewer places for bugs to hide than a big program does. > " Real power is in communicability, not in monolithic software, not even in modular software. It's like 2^N. 2 is a small number, but if you have enough bits, you can represent enormous number of numbers: 0,1,2,...,2^N-1. Another example, in theory of approximation, a function f is represented by function g. And if you tend to approximate f with g on interval (a,b), then you your function g will start to diverge very rapidly as soon x gets out of (a,b). When one software wants to cover all cases, they can never achieve this goal. They can make it work perfectly for 99% of users, but then the remaining 1% will have big problems. Such an application not only do not provide infrastructure for satisfying remaining cases, it can even become useless, and the typical solution is replacing it with another software which is incomparably less powerful, but yet much more usable for a particular purpose. Moreover, they are bad psychologically, because the user is frustrated, he has all that power in his hands, but in spite of that he cannot achieve something he has in mind. -- https://en.wikipedia.org/wiki/Machiavellianism http://markorandjelovic.hopto.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
