Bug#754055: acpi-support: typo in /etc/default/acpi-support: has npt been possible
Package: acpi-support Version: 0.141-4 Severity: minor Dear Maintainer, there is a little typo in comments: $ grep has npt been possible /etc/default/acpi-support # Uncomment this to shutdown the system if ACPI sleep has npt been possible expected: «has not been possible» -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14.2-ygrex-mac (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/dash Versions of packages acpi-support depends on: ii acpi-support-base 0.141-4 ii acpid 1:2.0.22-2 ii lsb-base 4.1+Debian13 ii pm-utils 1.4.1-14 ii x11-xserver-utils 7.7+2 Versions of packages acpi-support recommends: ii acpi-fakekey 0.141-4 ii rfkill0.5-1 Versions of packages acpi-support suggests: pn radeontoolnone pn vbetool none pn xinputnone ii xscreensaver 5.26-1 -- Configuration Files: /etc/default/acpi-support 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#754056: mysql-server: When using file logging traps in mysqld_safe do not have an effect
Package: mysql-server
Version: 5.5.37-0+wheezy1
Severity: important
Hi!
This is a followup to bug #208364. #208364 added a patch which make mysqld_safe
respond to signals and nicely terminate mysqld. The issue is that it does not
cover the case when --skip-syslog --log-error is used to run mysqld_safe.
wait is missing in the command line in that code path. Adding it solves the
issue.
Mitar
-- System Information:
Debian Release: 7.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages mysql-server depends on:
ii mysql-server-5.5 5.5.37-0+wheezy1
mysql-server recommends no packages.
mysql-server suggests no packages.
-- no debconf information
--- mysqld_safe.orig 2014-07-06 23:05:31.378738591 -0700
+++ mysqld_safe 2014-07-06 23:05:12.158643283 -0700
@@ -143,7 +143,7 @@
eval_log_error () {
cmd=$1
case $logging in
-file) cmd=$cmd `shell_quote_string $err_log` 21 ;;
+file) cmd=$cmd `shell_quote_string $err_log` 21 wait ;;
syslog)
# mysqld often prefixes its messages with a timestamp, which is
# redundant when logging to syslog (which adds its own timestamp)
Bug#738460: macchanger: Random mac feature fails in all of the random mac assigning options
On Sun, 6 Jul 2014 21:23:25 -0400, Theodore Ts'o wrote: Do you have any objections if I upload this as a NMU? Or would you prefer to update the package? Please Ted, go ahead. :) Thanks! David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#754054: perl: FTBFS on mips: Bad mojo! at make_patchnum.pl line 111.
clone 754054 -1 retitle -1 perl: erroneous quoting in Makefile.SH submitter -1 Kristoffer Grundström kristoffer.grundstrom1...@gmail.com severity -1 minor thanks On Mon, Jul 07, 2014 at 07:28:24AM +0200, Kristoffer Grundström wrote: Isn't the LD_LIBRARY_PATH Line written somewhat wrong? Why /perl\-sdOt09/perl\-5.18.2 ? Yeah, thanks for noticing. It seems to be a bit overly quoted. I don't think that hurts, as it gets expanded by the shell. I see it's been that way since 5.17.6. http://perl5.git.perl.org/perl.git/commitdiff/937aac54e77dcd55bbcad956420c9f990fc0b4ea quote() in Makefile.SH looks like it's supposed to leave '-' unquoted (and quote '\'), there's probably a bug in the regexp. Cloning. I'm pretty sure that's not the problem here, though. echo $1 | sed 's/\([^a-zA-Z0-9.:_\-\/]\)/\\\1/g' ;; should possibly be echo $1 | sed 's/\([^a-zA-Z0-9.:_\/-]\)/\\\1/g' ;; -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753971: [Pkg-julia-devel] Bug#753971: julia: Please update the llvm dependency from 3.3 to 3.4 (or better, llvm-dev)
On 07/07/2014 00:12, Sébastien Villemot wrote: Le dimanche 06 juillet 2014 à 23:55 +0200, Sébastien Villemot a écrit : Le dimanche 06 juillet 2014 à 19:39 +0200, Sylvestre Ledru a écrit : Source: julia Severity: important I would like to remove llvm-toolchain-3.3 from the archive ASAP. Could you switch to llvm-3.4-dev? Unfortunately upstream does not officially support LLVM 3.4 yet, not even for the latest development sources (it seems to compile, but there are issues, like https://github.com/JuliaLang/julia/issues/6369 ). For the current stable release (0.2) that is in sid, it is even worse, since julia FTBFS due to LLVM API changes. So at the very least I have to package a development snapshot. I need to get several new build dependencies through NEW, so it will take some time. Hopefully that will be done before the jessie freeze. Looking at https://github.com/JuliaLang/julia/issues/6757, it seems that even the next major release of Julia (0.3) will still require LLVM 3.3 to be fully functional. Would that be acceptable for you to ship LLVM 3.3 in Jessie? Not really ... I am planning to ship with llvm 3.4 3.5. I don't want to third instance just for a single package. Sylvestre signature.asc Description: OpenPGP digital signature
Bug#751425: ERROR: install script from emacs-goodies-el package failed
Unfortunately, I can't reproduce this bug: , | # aptitude install emacs-goodies-el | The following NEW packages will be installed: | emacs-goodies-el | 0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded. | Need to get 0 B/686 kB of archives. After unpacking 3,572 kB will be used. | Selecting previously unselected package emacs-goodies-el. | (Reading database ... 202449 files and directories currently installed.) | Preparing to unpack .../emacs-goodies-el_35.11_all.deb ... | Unpacking emacs-goodies-el (35.11) ... | Processing triggers for install-info (5.2.0.dfsg.1-4) ... | Setting up emacs-goodies-el (35.11) ... | Install emacs-goodies-el for emacs23 | install/emacs-goodies-el: Handling emacs23, logged in /tmp/elc_xkuPKz.log | Building autoloads for emacs23 in /usr/share/emacs23/site-lisp/emacs-goodies-el | install/emacs-goodies-el: Deleting /tmp/elc_xkuPKz.log | Install emacs-goodies-el for emacs24 | install/emacs-goodies-el: Handling emacs24, logged in /tmp/elc_YlmN66.log | Building autoloads for emacs24 in /usr/share/emacs24/site-lisp/emacs-goodies-el | install/emacs-goodies-el: Deleting /tmp/elc_YlmN66.log ` From your log: maplev.el:127:1:Error: Symbol's function definition is void: function-put it's hitting an error with emacs24 at line 127 of maplev.el: (require 'abbrevlist) When I eval this, I get the message: Package abbrevlist is obsolete! But the file has no mention of function-put. I don't see where this is happening... Peter Manoj Srivastava sriva...@debian.org wrote: Package: emacs-goodies-el Version: 35.11 Severity: grave Hi, I debated the severity of this bug, and since it fails to install, or allow emacs24 to configure, I selected grave. This could be reduced if this is only affecting my machine, Setting up emacs-goodies-el (35.11) ... Install emacs-goodies-el for emacs24 install/emacs-goodies-el: Handling emacs24, logged in /tmp/elc_jd3obj.log Building autoloads for emacs24 in /usr/share/emacs24/site-lisp/emacs-goodies-el ERROR: install script from emacs-goodies-el package failed dpkg: error processing package emacs-goodies-el (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: emacs-goodies-el === The log file is quoted below. manoj /tmp/elc_jd3obj.log contains: - emacs24 -batch --no-site-file --multibyte --eval (setq load-path (cons . load-path)) -l autoload --eval (setq generated-autoload-file (expand-file-name emacs-goodies-loaddefs.el)) --eval (setq make-backup-files nil) -f batch-update-autoloads . Warning (initialization): Ignoring obsolete arg --multibyte Generating autoloads for align-string.el... Generating autoloads for align-string.el...done Generating autoloads for all.el... Generating autoloads for all.el...done Generating autoloads for apache-mode.el... Generating autoloads for apache-mode.el...done Generating autoloads for ascii.el... Generating autoloads for ascii.el...done Generating autoloads for auto-fill-inhibit.el... Generating autoloads for auto-fill-inhibit.el...done Generating autoloads for bar-cursor.el... Generating autoloads for bar-cursor.el...done Generating autoloads for bm.el... Generating autoloads for bm.el...done Generating autoloads for boxquote.el... Generating autoloads for boxquote.el...done Generating autoloads for browse-huge-tar.el... Generating autoloads for browse-huge-tar.el...done Generating autoloads for browse-kill-ring.el... Generating autoloads for browse-kill-ring.el...done Generating autoloads for clipper.el... Generating autoloads for clipper.el...done Generating autoloads for coffee.el... Generating autoloads for coffee.el...done Generating autoloads for color-theme-library.el... Generating autoloads for color-theme-library.el...done Generating autoloads for color-theme.el... Generating autoloads for color-theme.el...done Generating autoloads for color-theme_seldefcustom.el... Generating autoloads for color-theme_seldefcustom.el...done Generating autoloads for csv-mode.el... Generating autoloads for csv-mode.el...done Generating autoloads for ctypes.el... Generating autoloads for ctypes.el...done Generating autoloads for dedicated.el... Generating autoloads for dedicated.el...done Generating autoloads for df.el... Generating autoloads for df.el...done Generating autoloads for dict.el... Generating autoloads for dict.el...done Generating autoloads for diminish.el... Generating autoloads for diminish.el...done Generating autoloads for dir-locals.el... Generating autoloads for dir-locals.el...done Generating autoloads for edit-env.el... Generating autoloads for
Bug#751201: emacs-goodies-el: site-start files don't work
Hi, I can't reproduce this... The errors means that directories like /usr/share/emacs/site-lisp/emacs-goodies-el don't exist on your system... Can you purge the packages, retry, and if it fails again show me the screen output of the install? Thanks, Peter Samuel Bronson naes...@gmail.com wrote: Package: emacs-goodies-el Version: 35.11 Severity: serious Dear Maintainer, After upgrading emacs-goodies-el, devscripts-el, and dpkg-dev-el to this version, the files they place in site-start.d no longer pick them up as properly-configured: [...] Loading /etc/emacs/site-start.d/50debbugs-el.el (source)... Package debbugs-el removed but not purged. Skipping setup. Loading /etc/emacs/site-start.d/50debbugs-el.el (source)...done [...] Loading /etc/emacs/site-start.d/50dpkg-dev-el.el (source)... Package dpkg-dev-el not fully installed. Skipping setup. Loading /etc/emacs/site-start.d/50dpkg-dev-el.el (source)...done [...] Loading /etc/emacs/site-start.d/50emacs-goodies-el.el (source)... Package emacs-goodies-el not fully installed. Skipping setup. Loading /etc/emacs/site-start.d/50emacs-goodies-el.el (source)...done [...] Fortunately, debian-el still works fine, so I've not been much frustrated in reporting this bug :-). (Truthfully, I'd probably have loaded it more manually if it had broke too. Not so `boxquote' ;-) -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.14-1-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages emacs-goodies-el depends on: ii bash 4.2+dfsg-1 ii dpkg 1.17.9 ii emacs23-lucid [emacsen] 23.4+1-4.1+b1 ii emacs24-lucid [emacsen] 24.3+1-4 ii install-info 5.2.0.dfsg.1-2 Versions of packages emacs-goodies-el recommends: ii dict 1.12.1+dfsg-2 ii perl-doc 5.18.2-2 ii wget 1.15-1 emacs-goodies-el suggests no packages. -- no debconf information Versions of packages devscripts-el depends on: ii apel 10.8+0.20120427-5 ii bash 4.2+dfsg-1 ii devscripts 2.14.4 ii dpkg-dev-el 35.11 ii emacs23-lucid [emacsen] 23.4+1-4.1+b1 ii emacs24-lucid [emacsen] 24.3+1-4 Versions of packages devscripts-el recommends: ii elserv 0.4.0+0.20011203cvs-17.1 devscripts-el suggests no packages. -- no debconf information Versions of packages dpkg-dev-el depends on: ii debian-el35.11 ii emacs23-lucid [emacsen] 23.4+1-4.1+b1 ii emacs24-lucid [emacsen] 24.3+1-4 Versions of packages dpkg-dev-el recommends: ii wget 1.15-1 Versions of packages dpkg-dev-el suggests: ii dpkg-dev 1.17.9 -- no debconf information -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -- Peter S. Galbraith, Debian Developer p...@debian.org http://people.debian.org/~psg GPG key 4096/70D4A979 6309 28AE 8EB3 AB57 22F3 03BC 17DC 3CC4 70D4 A979 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744264: Not reproducible in Debian Testing anymore
With the latest updates systemd became the default init system in Debian Testing, so the issue isn't reproducible there anymore.
Bug#754059: [systemd-sysv] Conflicts with sysvinit-core
Package: systemd-sysv Version: 204-14 Severity: serious systemd-sysv conflicts with sysvinit-core, which is required. This is particularly problematic since libpam-systemd alternatively depends on systemd-sysv. On my testing install, APT's solution when asked to upgrade systemd is to remove sysvinit-core: # LANG=C apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... The following packages were automatically installed and are no longer required: libcolamd2.8.0 lp-solve xulrunner-29 Use 'apt-get autoremove' to remove them. Done The following packages will be REMOVED: sysvinit-core The following NEW packages will be installed: systemd-sysv The following packages will be upgraded: libpam-systemd libsystemd-daemon0 libsystemd-id128-0 libsystemd-journal0 libsystemd-login0 systemd 6 upgraded, 1 newly installed, 1 to remove and 0 not upgraded. Removing libpam-systemd isn't too tempting neither: # LANG=C apt-get remove libpam-systemd Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: libcolamd2.8.0 libmodemmanagerqt1 libnetworkmanagerqt1 lp-solve xulrunner-29 Use 'apt-get autoremove' to remove them. The following packages will be REMOVED: colord hplip kde-plasma-desktop libpam-systemd network-manager plasma-nm plasma-widget-networkmanagement policykit-1 policykit-1-gnome printer-driver-postscript-hp udisks2 0 upgraded, 0 newly installed, 11 to remove and 5 not upgraded. I managed to solve this safely by installing systemd-shim. I was surprised to see APT propose the removal of a required package. I didn't test how that would go, but if that's not a problem, something must be wrong with its priority field. I'll save my system from such an experimentation and let others decide if this needs to be reassigned. -- Filipus Klutiero http://www.philippecloutier.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753925: mps-youtube: no longer plays media streams after the latest mpv update
Hello, thanks for the report. It seems I can't reproduce the bug (using all the same). Can you please attach/cp your output of mpsyt --version? Cheers, zlatan On Sun, Jul 6, 2014 at 11:56 AM, xor x...@paranoici.org wrote: Package: mps-youtube Version: 0.01.44-4 Severity: important Dear Maintainer, all in the bug subject. mpv stopped playing media streams few days ago. As far as i can tell, this happened in conjunction with the latest mpv update: 0.3.11-1 - 0.4.0-1 When attempting to play a video/audio all i get is Getting content and error: retrying for three times, after which mpsyt gives up fetching the video and comes back to the interaction with the search results screen. Let me know if and how i can provide more details. Best regards! -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.14-1-686-pae (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mps-youtube depends on: ii mpv 0.4.0-1 ii python 2.7.6-2 ii python-pafy 0.3.41-2 mps-youtube recommends no packages. mps-youtube suggests no packages. -- no debconf information -- Its not the COST, its the VALUE!
Bug#751953: summary on upower transition, lets go?!
Hello! A summary on the state of reverse dependencies of the upower has been requested before starting the transition. I'll attach my summary below and at the same time asks for anyone who wishes for anything else before starting this transition to speak up about that! Except for razorqt and xfce, no replies from maintainers on either call for action on debian-devel or the bug reports filed on their packages. (Notable mention is that mate maintainers quickly uploaded new version of their packages to fix build against libupower-glib-dev . but didn't reply to dbus API bug report.) Removals: === wmbattery: remove from testing. sugar-session-0.96: others have suggested removal. Not checked. sugar-session-0.98: -- sucrose-0.96: -- sucrose-0.98: -- NOPs (or removal if you prefer): === razorqt-power: razorqt dead upstream (merged with LXDE), sounds like it's already not in shape for release. cinnamon-session: only in experimental. indicator-session: source seems to indicate suspend + hibernate only via upower, but looks like it disables menu entries when upower is not available. indicator-session-gtk2: -- (built from same source) Note: indicator-session* has no reverse dependencies. Sourceful uploads: === cairo-dock-plug-ins: NMU with upower disabled for now. Also tries both logind and ck besides upower interfaces. gnome-applets: sponsor new package revision once transition starts. xfce: response from maintainer Not sure what he's saying though and why he's not picking up the patches from fedora. Might need NMU. (xfce4-systemload-plugin: apparently fixed in svn) (xfce4-session, xfce4-power-manager) Remaining packages with open bug reports (NOPs?): === mate: api usage already fixed in mate, dbus-usage should hopefully not be a problem? Assume maintainer has tested his previous work. (mate-power-manager, mate-session-manager) gnome: not checked but IMO not interesting since it'll be replaced by gnome 3.12 components as soon as the upower transition has finished. (gnome-power-manager, gdm3, gnome-session-bin) lxsession: source seems to indicate support for both logind and upower. lightdm: source seems to indicate upower is only a fallback after logind. kde: not checked but KDE is generally a known user of logind interface... (kde-config-touchpad, libsolid4, kde-plasma-desktop, kde-plasma-netbook) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751706: [python-defaults] Allow bootstrapping without lsb-release and python-docutils
On Sunday, June 15, 2014 21:27:57 Peter Pentchev wrote: Source: python-defaults Version: 2.7.6-2 Severity: wishlist Tags: patch Hi, First of all, thanks for maintaining Python in Debian! As part of this year's Bootstrappable Debian Google Summer of Code project I took a look at python-defaults ... After this somewhat lengthy introduction, the point of my work on python-defaults was to remove two circular build dependencies: lsb-release and python-docutils, both of which require python to be already present. It was very easy to drop lsb-release, since dpkg-dev 1.15.1 and later provide the needed functionality in the dpkg-vendor utility. With python-docutils the result was a bit more... unconventional than I'd like. The usual way to resolve these circular build dependencies is to make sure all the files that need more tools for generating are moved to a separate package and this package is built conditionally. For documentation files, this is usually very easy, as with libtasn1-6 in #749854, autogen in #751470, flex in #749344 - in some cases it's as easy as moving some packages from Build-Depends to Build-Depends-Indep and slightly adjusting the rules file to only build the documentation in build-indep/binary-indep. Well, with python-docutils this led to two weird consequences: - the Python Policy and the Python FAQ had to be moved from the python binary package to the python-doc one, which meant that, to avoid replacing the /usr/share/doc/python/python-policy.html/ directory with a symlink to ../python-doc/python-policy.html/, I had to let python-doc install stuff into /usr/share/doc/python/. I know that this usually raises a few eyebrows, but it seems to be the cleanest way to do it (dpkg does not seem to handle very well a directory being replaced with a symlink during a package upgrade). - the manual pages for the executable tools in the python and python-minimal binary packages are also generated documentation, which means that there was a choice: go with statically-generated versions and make sure they are refreshed periodically, or move them to python-doc, too. Well, moving them to python-doc leads to it now installing manual pages for utilities in another package - another raise a few eyebrows situation. I added a Recommends: python-doc to both python and python-minimal, so that in the usual recommended packages are installed by default case both the Python Policy and the manual pages will be present on the system. Still, I realize that this is a bit fishy, and in the end you have the final say as actual maintainers of the Python packages in Debian, so... here are the proposed patches, let the critique begin! :) The change from lsb-release to dpkg-vendor is, as you suggest very uncontroversial and I've committed it to our repository for the next upload. The other changes require more consideration. I've cloned this bug into #754060 to continue that part of the issue. Scott K signature.asc Description: This is a digitally signed message part.
Bug#753971: [Pkg-julia-devel] Bug#753971: Bug#753971: julia: Please update the llvm dependency from 3.3 to 3.4 (or better, llvm-dev)
Julia support for LLVM 3.4 is only experimental and we will probably go directly to 3.5. Is it an option to include 3.3 in the Julia package in that case? -viral On 6 Jul 2014 23:49, Sylvestre Ledru sylves...@debian.org wrote: On 07/07/2014 00:12, Sébastien Villemot wrote: Le dimanche 06 juillet 2014 à 23:55 +0200, Sébastien Villemot a écrit : Le dimanche 06 juillet 2014 à 19:39 +0200, Sylvestre Ledru a écrit : Source: julia Severity: important I would like to remove llvm-toolchain-3.3 from the archive ASAP. Could you switch to llvm-3.4-dev? Unfortunately upstream does not officially support LLVM 3.4 yet, not even for the latest development sources (it seems to compile, but there are issues, like https://github.com/JuliaLang/julia/issues/6369 ). For the current stable release (0.2) that is in sid, it is even worse, since julia FTBFS due to LLVM API changes. So at the very least I have to package a development snapshot. I need to get several new build dependencies through NEW, so it will take some time. Hopefully that will be done before the jessie freeze. Looking at https://github.com/JuliaLang/julia/issues/6757, it seems that even the next major release of Julia (0.3) will still require LLVM 3.3 to be fully functional. Would that be acceptable for you to ship LLVM 3.3 in Jessie? Not really ... I am planning to ship with llvm 3.4 3.5. I don't want to third instance just for a single package. Sylvestre ___ Pkg-julia-devel mailing list pkg-julia-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-julia-devel
Bug#753444: Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Sat, Jul 05, 2014 at 07:15:56PM +0200, Emilio Pozuelo Monfort wrote: That said, feel free to upload perl now. It has been uploaded, and is now installed on all s390x buildds. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754061: qtdeclarative-opensource-src: Does not work with the RFC2822 datetime format
Source: qtdeclarative-opensource-src
Severity: normal
Tags: upstream
Dear Maintainer,
I tested that the https://bugreports.qt-project.org/browse/QTBUG-38011
still seems to apply to Debian's Qt 5.3.1, despite upstream's thoughts
that it would have been fixed in 5.3.0.
That is, running qmlscene date.qml with the attached QML file gives
me Invalid Date both on 5.3.0 (tested in Ubuntu) and Debian's 5.3.1.
There is a two-liner patch related to the upstream bug report that I
tested fixed the problem on Ubuntu's 5.3.0.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 3.14-1-686-pae (SMP w/1 CPU core)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
import QtQuick 2.0
Rectangle {
Component.onCompleted: {
var dateObj = new Date(Wed, 18 Sep 2013 07:00:51 -0700)
console.log(dateObj: , dateObj)
}
}
Bug#754060: [python-defaults] Allow bootstrapping without lsb-release and python-docutils
On Sunday, June 15, 2014 21:27:57 Peter Pentchev wrote: Source: python-defaults Version: 2.7.6-2 Severity: wishlist Tags: patch Hi, First of all, thanks for maintaining Python in Debian! As part of this year's Bootstrappable Debian Google Summer of Code project I took a look at python-defaults to break a circular build dependency as noted in the Feedback Arc Set section of http://bootstrap.debian.net/amd64/ and, more specifically, at http://bootstrap.debian.net/source/python-defaults.html and the version-specific pages linked from it. There are two primary goals to my work on this GSoC project: - The first goal is to modify some packages so that they may be built in some limited way (nocheck, binary-only, or build profiles like stage1) without some of their usual build dependencies. In most cases this is caused by one or more dependency loops between binary and source packages, so that a source package requires for its building, directly or indirectly, one of its own binary packages to be already built. The modifications make the source build in a limited fashion (not generating documentation, not running tests, not building some of the binary packages) so that this may happen with only the rest of the build dependencies, so Debian may be bootstrapped on a new architecture starting from a very few cross-built toolchain packages and then moving along, source package by source package. - The second goal, which is actually closely related to the first, is that in the process of modifications, any changes (some files not regenerated, others not built at all) can be made with binary package level granularity. This means that if a binary package is built at all during a limited build, then it must have the same contents as the same binary package resulting from a full build. The point here is to avoid breakage if other packages in the archive depend on some functionality provided by the omitted files; if so, it should be obvious that the functionality is missing, and the clearest way to do that is by omitting a full binary package or, rather, delaying its build until the rest of the build dependencies are present. After this somewhat lengthy introduction, the point of my work on python-defaults was to remove two circular build dependencies: lsb-release and python-docutils, both of which require python to be already present. It was very easy to drop lsb-release, since dpkg-dev 1.15.1 and later provide the needed functionality in the dpkg-vendor utility. With python-docutils the result was a bit more... unconventional than I'd like. The usual way to resolve these circular build dependencies is to make sure all the files that need more tools for generating are moved to a separate package and this package is built conditionally. For documentation files, this is usually very easy, as with libtasn1-6 in #749854, autogen in #751470, flex in #749344 - in some cases it's as easy as moving some packages from Build-Depends to Build-Depends-Indep and slightly adjusting the rules file to only build the documentation in build-indep/binary-indep. Well, with python-docutils this led to two weird consequences: - the Python Policy and the Python FAQ had to be moved from the python binary package to the python-doc one, which meant that, to avoid replacing the /usr/share/doc/python/python-policy.html/ directory with a symlink to ../python-doc/python-policy.html/, I had to let python-doc install stuff into /usr/share/doc/python/. I know that this usually raises a few eyebrows, but it seems to be the cleanest way to do it (dpkg does not seem to handle very well a directory being replaced with a symlink during a package upgrade). - the manual pages for the executable tools in the python and python-minimal binary packages are also generated documentation, which means that there was a choice: go with statically-generated versions and make sure they are refreshed periodically, or move them to python-doc, too. Well, moving them to python-doc leads to it now installing manual pages for utilities in another package - another raise a few eyebrows situation. I added a Recommends: python-doc to both python and python-minimal, so that in the usual recommended packages are installed by default case both the Python Policy and the manual pages will be present on the system. Still, I realize that this is a bit fishy, and in the end you have the final say as actual maintainers of the Python packages in Debian, so... here are the proposed patches, let the critique begin! :) This analysis does not seem to be entirely correct. Python policy is generated with debiandoc2text and debiandoc2html which come from debiandoc-sgml, so I think Python policy is irrelevant to this discussion. There are two kinds of man pages shipped in python-defaults: - idle.1 and pyversions.1. Neither of
Bug#673538: transition: gnustep-base, gnustep-gui
Yavor Doganov wrote: I'm waiting for gnustep-back to get ACCEPTed and built everywhere. Once done, we're basically ready (I only have to backport my gnustep-base patch for the gnutls transition). ACCEPTed and built on almost all release architectures (mipsen slightly lagging behind). Please let me know when it is OK to upload to unstable. I gather we must wait for the poppler transition to complete. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753785: [Python-modules-team] Bug#753785: flask-silk: please ship icons in a new package which does not depends on python
On 6 July 2014 22:47, Dustin Kirkland kirkl...@ubuntu.com wrote: On Sun, Jul 6, 2014 at 11:32 AM, Leo Iannacone l...@ubuntu.com wrote: On 6 July 2014 17:33, Sebastian Ramacher sramac...@debian.org wrote: It might make more sense to follow the Ubuntu approach, though. There is nothing special about the copy of the images in flask-silk. Would you be willing to maintain such a package in Debian? I'd be happy to sponsor the package for you. I'm CCing Dustin Kirkland, the Ubuntu developer who's maintaining that package in Ubuntu. Hi Dustin, could you be interested in move famfamfam-silk[0] into Debian? Hi Leo, et al- Sure, I'd be happy to see famfamfam-silk land in Debian, and enable Ubuntu to just sync it down. Are you happy with the package as-is, or do you need to see some changes in order for it to be sponsored into Debian? I'm happy to maintain the package in Debian, Sebastian. Hi Dustin! This is awesome! :) But right now I don't have permission to sponsor your package (I'm not DD actually). You have to talk directly with Sebastian. Cheers! [0] - https://launchpad.net/ubuntu/+source/famfamfam-silk -- Ubuntu Member - http://launchpad.net/~l3on Home Page - http://leoiannacone.com GPG Key Id - 0xD282FC25 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670614: Patch (wipefs still fails with liblinux-lvm-perl)
Hi!
Attached is a patch which fixes the wipefs problem.
It adds a /dev prefix to wipefs and lvremove commands
and reorders lvchange -a n to be executed after wiping
and removing the logical volumes.
Regards
Christian
--- Commands.pm.orig 2014-06-03 10:55:53.0 +0200
+++ Commands.pm 2014-07-02 14:31:10.0 +0200
@@ -647,7 +647,7 @@
# remove all volumes that do not exist anymore or need not be preserved
foreach my $lv (keys %{ $FAI::current_lvm_config{$vg}{volumes} }) {
my $pre_deps_cl = ;
-$pre_deps_cl = ,self_cleared_ .
+$pre_deps_cl = self_cleared_ .
join(,self_cleared_, @{ $FAI::current_dev_children{/dev/$vg/$lv} })
if (defined($FAI::current_dev_children{/dev/$vg/$lv})
scalar(@{ $FAI::current_dev_children{/dev/$vg/$lv} }));
@@ -655,16 +655,16 @@
if (defined ( $FAI::configs{VG_$vg}{volumes}{$lv})) {
if ($FAI::configs{VG_$vg}{volumes}{$lv}{size}{preserve} == 1 ||
$FAI::configs{VG_$vg}{volumes}{$lv}{size}{resize} == 1) {
-FAI::push_command(true, vgchange_a_n_VG_$vg$pre_deps_cl,
+FAI::push_command(true, vgchange_a_n_VG_$vg,$pre_deps_cl,
exist_/dev/$vg/$lv,self_cleared_/dev/$vg/$lv);
next;
}
}
-FAI::push_command( wipefs -a $vg/$lv,
- vgchange_a_n_VG_$vg$pre_deps_cl,
+FAI::push_command( wipefs -a /dev/$vg/$lv,
+ $pre_deps_cl,
wipefs_$vg/$lv);
-FAI::push_command( lvremove -f $vg/$lv,
+FAI::push_command( lvremove -f /dev/$vg/$lv,
wipefs_$vg/$lv,
lv_rm_$vg/$lv,self_cleared_/dev/$vg/$lv);
$vg_setup_pre .= ,lv_rm_$vg/$lv;
@@ -682,14 +682,14 @@
my $vg_destroy_pre = vgchange_a_n_VG_$vg;
foreach my $lv (keys %{ $FAI::current_lvm_config{$vg}{volumes} }) {
my $pre_deps_cl = ;
-$pre_deps_cl = ,self_cleared_ .
+$pre_deps_cl = self_cleared_ .
join(,self_cleared_, @{ $FAI::current_dev_children{/dev/$vg/$lv} })
if (defined($FAI::current_dev_children{/dev/$vg/$lv})
scalar(@{ $FAI::current_dev_children{/dev/$vg/$lv} }));
-FAI::push_command( wipefs -a $vg/$lv,
- vgchange_a_n_VG_$vg$pre_deps_cl,
+FAI::push_command( wipefs -a /dev/$vg/$lv,
+ $pre_deps_cl,
wipefs_$vg/$lv);
-FAI::push_command( lvremove -f $vg/$lv,
+FAI::push_command( lvremove -f /dev/$vg/$lv,
wipefs_$vg/$lv,
lv_rm_$vg/$lv,self_cleared_/dev/$vg/$lv);
$vg_destroy_pre .= ,lv_rm_$vg/$lv;
@@ -727,14 +727,12 @@
my $vg = $1;
my $vg_pre = vgchange_a_n_VG_$vg;
my $pre_deps_vgc = ;
-foreach my $c (@{ $FAI::current_dev_children{$d} }) {
- $pre_deps_vgc = ,self_cleared_ .
-join(,self_cleared_, @{ $FAI::current_dev_children{$c} })
-if (defined($FAI::current_dev_children{$c})
- scalar(@{ $FAI::current_dev_children{$c} }));
-}
+$pre_deps_vgc = ,self_cleared_ .
+ join(,self_cleared_, @{ $FAI::current_dev_children{$d} })
+ if (defined($FAI::current_dev_children{$d})
+ scalar(@{ $FAI::current_dev_children{$d} }));
$pre_deps_vgc =~ s/^,//;
-FAI::push_command(vgchange -a n $1, $pre_deps_vgc, $vg_pre);
+FAI::push_command(vgchange -a n $vg, $pre_deps_vgc, $vg_pre);
$vg_pre .= ,pv_sigs_removed_$vg if (FAI::cleanup_vg($vg));
my $pre_deps_cl = ;
$pre_deps_cl = ,self_cleared_ .
Bug#754060: [python-defaults] Allow bootstrapping without lsb-release and python-docutils
[Scott Kitterman, 2014-07-07] The latter set of manpages are unlikely to change. The copy of dh-python that is shipped in python-defaults is strictly legacy (development is now done in a separate dh-python package). As a result, I think it's perfectly acceptable for update of these man pages to be conditional on the availability of python- docutils. The man pages need to stay in the correct package even at some risk they might be slightly obsolete. agreed. IMHO we can replace .rst files with .1 ones in python-defaults and from now on use .1 as source files (another option would be to use python3-docutils) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754062: dracut: module-setup.sh for Plymouth fails due to wrong paths
Source: dracut
Severity: normal
Tags: patch
Dear Maintainer,
first let me thank you for providing dracut to debian! Replacing
initramfs-tools with dracut went amazingly smooth. There is only one little
problem with dracut and plymouth:
The current version of dracut (037-2) in Debian Jessie is not able to locate
Plymouth. It fails with something like
'.../usr/libexec/plymouth/plymouth-populate-initrd: No such file or
directory...' when running dracut. The reason can be found in file
'/usr/lib/dracut/modules.d/50plymouth/module-setup.sh'. This script is
expecting plymouth to be found at '/usr/libexec/...', but this path does not
exist in debian. Correct would be e.g. '/usr/lib/x86_64-linux-gnu/...' on
amd64. As dracut is not able to locate plymouth it falls back to its own
plymouth installation script
'/usr/lib/dracut/modules.d/50plymouth/plymouth-populate-initrd.sh'. But that
script is faulty too, because it expects a file
'/usr/share/pixmaps/system-logo-white.png', which again does not exist in
debian.
To fix the first error, i've attached a patch to this bug report. This patch
changes '.../50plymouth/module-setup.sh' in such a way, that the script first
extracts the current system architecture triplet (e.g. 'x86_64-linux-gnu' for
amd64) and then uses this information to locate plymouth. However, this
requires 'dpkg-architecture' which is part of the 'dpkg-dev' package. Thus the
package dependencies need an update, too. Until now i haven't found a
satisfying solution without 'dpkg-architecture' :-(
Cheers
Jakob
-- System Information:
Debian Release: jessie/sid
APT prefers testing-proposed-updates
APT policy: (500, 'testing-proposed-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- /usr/lib/dracut/modules.d/50plymouth/module-setup.sh.orig 2014-06-27 11:58:43.387775226 +0200
+++ /usr/lib/dracut/modules.d/50plymouth/module-setup.sh 2014-06-27 12:15:06.687493675 +0200
@@ -15,12 +15,13 @@
# called by dracut
install() {
-if grep -q nash /usr/libexec/plymouth/plymouth-populate-initrd \
-|| [ ! -x /usr/libexec/plymouth/plymouth-populate-initrd ]; then
+DEB_HOST_MULTIARCH=$(dpkg-architecture -qDEB_HOST_MULTIARCH)
+if grep -q nash /usr/lib/${DEB_HOST_MULTIARCH}/plymouth/plymouth-populate-initrd \
+|| [ ! -x /usr/lib/${DEB_HOST_MULTIARCH}/plymouth/plymouth-populate-initrd ]; then
. $moddir/plymouth-populate-initrd.sh
else
PLYMOUTH_POPULATE_SOURCE_FUNCTIONS=$dracutfunctions \
-/usr/libexec/plymouth/plymouth-populate-initrd -t $initdir
+/usr/lib/${DEB_HOST_MULTIARCH}/plymouth/plymouth-populate-initrd -t $initdir
fi
inst_hook emergency 50 $moddir/plymouth-emergency.sh
Bug#753971: [Pkg-julia-devel] Bug#753971: Bug#753971: julia: Please update the llvm dependency from 3.3 to 3.4 (or better, llvm-dev)
On 07/07/2014 09:10, Viral Shah wrote: Julia support for LLVM 3.4 is only experimental and we will probably go directly to 3.5. Do you have an eta on Julia-on-llvm-3.5 ? LLVM 3.5 branching is probably going to happen this week. Is it an option to include 3.3 in the Julia package in that case? No. It had a maintenance burden on Debian that we don't want. Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
Hello again, Am Mittwoch, den 02.07.2014, 16:32 +0200 schrieb Boguslaw Jackowski: Having thought the matter over and having looked into TG Linux packages, we would suggest to use, anyway, Type 1 TG as legacy fonts and to change appropriately the content of packages -- and maybe names? ;-) This won't be that easy, I am afraid. The aliasing of Times - Termes has already made it into fontconfig upstream (modulo a just recently added comment around these lines motivated by the very issue we are just discussing here): http://cgit.freedesktop.org/fontconfig/tree/conf.d/30-metric-aliases.conf#n80 This means, that every application using fontconfig (which shuold be close to 100% on the Linux desktop) that requests a font compatible to Times for rendering will get passed Termes instead by fontconfig. Please note that the font's names are written as e.g. TeX Gyre Termes which does only apply to the OpenType fonts and not to the Type 1 fonts, which are called like TeXGyreTermes, i.e. without the additional blanks. It will take at least one stable release cycle of each major distribution to get this mess cleaned up, I am afraid. * For the sake of compatibility -- even if it was not initially intended that way -- couldn't we simply add the two missing ligature glyphs under their old-style names for the time being and be done with it, please? * Hans: I think that for that embedding the times and so is kind of mandate nowadays. Isn't Times one of the fonts that are by definition of the PDF standard explicitely not required to get embedded? - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748935: Initial patch
Initial patch to compile against UPower = 0.99 --- upower.c +++ upower.c @@ -62,8 +62,10 @@ return 0; } + #if !UP_CHECK_VERSION(0, 9, 99) /* Allow a battery that was not present before to appear. */ up_client_enumerate_devices_sync(up, NULL, NULL); + #endif devices = up_client_get_devices(up);
Bug#754063: initscripts: no longer depends on ifupdown
Package: initscripts Version: 2.88dsf-53.2 Severity: grave Justification: renders package unusable Hello, I upgraded initscripts which no llonger depend on ifupdown. Hence I have no networking on next boot. IMHO this renders the initscripts unusable for 90% of users. Please fix. Thanks Michal -- System Information: Debian Release: 7.5 APT prefers testing APT policy: (910, 'testing'), (900, 'stable'), (500, 'testing'), (410, 'unstable'), (400, 'experimental'), (300, 'saucy-updates'), (300, 'saucy-security'), (300, 'saucy-proposed'), (300, 'saucy-backports'), (300, 'saucy') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.15-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages initscripts depends on: ii coreutils 8.13-3.5 ii debianutils 4.3.2 ii libc6 2.19-4 ii lsb-base4.1+Debian8+deb7u1 ii mount 2.22-1~test1 ii sysv-rc 2.88dsf-53.2 ii sysvinit-utils 2.88dsf-53.2 Versions of packages initscripts recommends: ii e2fsprogs 1.42.5-1.1 ii psmisc 22.19-1+deb7u1 initscripts 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#751525: transition: poppler 0.26
On 04/07/14 00:12, Pino Toscano wrote: On 2014-07-03 00:39, Emilio Pozuelo Monfort wrote: On 13/06/14 20:41, Pino Toscano wrote: Sources that currently FTBFS: * gdcm Compatibility with Poppler 0.26.x fixed upstream, asked to backport the patches in #751432. That's RC now. ... and NMU uploaded to DELAYED/2. gdcm failed on kfreebsd. Can you take a look? That's the last thing preventing testing migration. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754060: [python-defaults] Allow bootstrapping without lsb-release and python-docutils
On Monday, July 07, 2014 03:41:07 Scott Kitterman wrote: I don't personally have any objection to moving the FAQ to python-doc, but let's see if my co-maintainers have a different perspective. It looks like the update and regeneration process for the FAQ is currently broken due to an upstream web site reorganization. Perhaps you can come up with an alternative way to build the documentation that doesn't require python-docutils based on the way upstream has redone it. signature.asc Description: This is a digitally signed message part.
Bug#754064: procps: kernel paramaters not set
Package: procps Version: 1:3.3.9-6 Severity: important The /etc/init.d/procps script which is part of procps package no longer runs. If you rely on this script to set important system parameters because they are misconfigured in the Debian distribubtion kernels your system breaks. Thanks Michal -- System Information: Debian Release: 7.5 APT prefers testing APT policy: (910, 'testing'), (900, 'stable'), (500, 'testing'), (410, 'unstable'), (400, 'experimental'), (300, 'saucy-updates'), (300, 'saucy-security'), (300, 'saucy-proposed'), (300, 'saucy-backports'), (300, 'saucy') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.15-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages procps depends on: ii initscripts 2.88dsf-53.2 ii libc6 2.19-4 ii libncurses5 5.9-10 ii libncursesw5 5.9-10 ii libprocps31:3.3.9-5 ii libtinfo5 5.9-10 ii lsb-base 4.1+Debian13 Versions of packages procps recommends: ii psmisc 22.19-1+deb7u1 procps 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#753442: why do you blame systemd?
control: tags -1 - moreinfo Hi Daniel, thanks for providing more information! cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#753781: transition: xserver 1.16
On 06/07/14 22:22, Cyril Brulebois wrote: Emilio Pozuelo Monfort po...@debian.org (2014-07-05): Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/xserver1.16.html We'd like to ship Jessie with xserver 1.16. It is already available in experimental and built everywhere, and a few of us are already running it without any major issues. I have done a rebuild of all the drivers (input and video) and only xf86-video-glamo failed to build; all the others build fine against the new xserver. There are no conflicts for the transition, so we could start this right away, though since 1.16 final isn't out yet, it may be wise to wait for that. FWIW I've quickly toyed with: - the server udeb fetched from experimental; - the -input-evdev udeb built from the debian-experimental branch against current libevdev-dev package (see attached patch, not sure it's needed to apply it, your call) and experimental's server The patch looks good, feel free to apply it. development package; - the -video-fbdev udeb built from the debian-unstable branch against experimental's server development package. The resulting netboot-gtk amd64 image seems to work just fine. Great! Thanks for checking. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752609: r-base-dev: Please provide a method to run upstream unit tests at package build time
Hi Dirk, On Sun, Jul 06, 2014 at 10:27:53AM -0500, Dirk Eddelbuettel wrote: Yes, thanks -- it looks better now. I kept three tabs open on my desktop as reminder to come back to this 'at some point' (and I may still write a script to compare the CRAN status and what the Debian DB has -- mainly to finally learn about the Debian DB back end). This might be helpful. Right now, I see these packages as out-of-date (and I wasn't thorough, scanning mostly for r-* only) - debian-med: catools Need to check this. r-bioc-affy This was a quite recent release. r-bioc-biovizbase r-bioc-bsgenome r-bioc-cummerbund r-bioc-edger r-bioc-genomicfeatures r-bioc-gviz r-bioc-iranges r-bioc-limma r-bioc-rsamtools r-bioc-rtracklayer r-bioc-shortread All depend from r-bioc-biocparallel which is in new since several days. :-( r-cran-bbmisc I'm discussing with upstream about the test suite which showed some issues. r-cran-g.data r-cran-genabel Also problems with the test suite. - debian-science r-cran-colorspace - debichem r-cran-base64enc Need to check these. (and a bunch of packages with wrong policy as we aim for r-other-$AUTHOR-$PACKAGE but then I never really finished the Policy so shame on me) We could not only use a policy but also a mailing list for discussing this kind of issues rather than a random bug report. | I keep on thinking that there is a difference between testing a source | package on a Debian machine and testing a binary in the chroot it was | built in. You did not answer how the test is done if not even all the | preconditions needed for a test are packaged. Several years ago, R changed how it tests its packages. It used to work from either the source dir, or the a tarball. These days, it stronly prefers a tarball. I repeat: I was running the test suite manually and some packages had missing requirements and some had failed tests. It seems these will not show up in the test method you are mentioning. I feel it of topic to discuss the single pieces here in the bug report. But post-build is simply not supported by R itself, Well, I do not want to discuss whether it is suported by R itself. I just think that we should add this value to the Debian packages if possible and there are about 50% of packages I touched recently where it is possible. even though has a _very robust_ and _widely used_ test system. If we go for automated testing (and we should, of course, though I'd prefer to see it being optional) then we are simply better off using 'R CMD check someTarFile_1.2-3.tar.gz'. Several packages try the test post-build, but __it is not standardized or even documented__ within the R ecosystem whereas the approach of using But it is perfectly possible in the Debian ecosystem and this is what I'm talking about. R CMD check someTarFile_1.2-3.tar.gz is at the same time understood, documented and even mandated. Fine. So we can be save that this is just done and we can stop discussing this here. Please, pretty please, stick to what I'm discussing and what we also can approach. I just added autopkgtests to those packages which are featuring tests. We now need to do something to test at build time and as I suggested initially dh has hooks like override_dh_autotest which could be used for non standard tests. | I know that there are different testing frameworks - I just packaged one | of it (r-cran-testthat) to be able to do the testing. This is exactly | the point I want to make: We need to do the testing on a closed system | with Debian packaged code to be able to guarantee that the user gets a | package which was tested with the code we are delivering. See previous paragraphs. You think as a DD (which is normal) so you want to test post-build / post-install. That is __not generally supported by R__ so you are in for some work. Exactly. As usual a bug report is triggering some work and I wanted to trigger this work and I'm willing to test. | I would be really happy if you would stop trying to make this personal. I am not. But as you are the self-appointed emperor of these teams, I'd be really happy if you would try to avoid terms like this. We have no emperors in Debian teams and there is no such thing as self-appointment. Thanks. Please keep packaged software current. I try hard - but I also have other packages than R which are out of your focus, sorry. And please believe me that I have nothing against Andreas-the-person. I am in awe of all you have done for Debian; I am mostly sad about what I see as counterproductive outcomes (though I acknowledge happily that things are better now than a few months ago -- keep it up). I will try, but I can not promise. What you call self-appointed emperor is that I try to clean up behind others of the team and I show up
Bug#753444: Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On 07/07/14 09:31, Aurelien Jarno wrote: On Sat, Jul 05, 2014 at 07:15:56PM +0200, Emilio Pozuelo Monfort wrote: That said, feel free to upload perl now. It has been uploaded, and is now installed on all s390x buildds. Thanks. I have scheduled a bunch of binNMUs. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754066: libsasl2-dev: Variable prefix not defined in libsasl2.pc
Package: libsasl2-dev
Version: 2.1.26.dfsg1-10
Severity: normal
Dear Maintainer,
pkg-config in't happy wit this .pc file :
Variable 'prefix' not defined in '/usr/lib/i386-linux-gnu/pkgconfig/libsasl2.pc'
Must specify package names on the command line
$ cat /usr/lib/i386-linux-gnu/pkgconfig/libsasl2.pc
libdir = ${prefix}/lib/i386-linux-gnu
Name: Cyrus SASL
Description: Cyrus SASL implementation
URL: http://www.cyrussasl.org/
Version: 2.1.26
Libs: -L${libdir} -lsasl2
Libs.private: -ldl -lresolv -lresolv
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 3.15.2 (SMP w/8 CPU cores; PREEMPT)
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 libsasl2-dev depends on:
ii libc6-dev 2.19-4
ii libsasl2-2 2.1.26.dfsg1-10
libsasl2-dev recommends no packages.
libsasl2-dev 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#748935: Fwd: Initial patch
Hello Samuli Suominen. Thanks for the patch! Adding the correct bug number to CC to file it there. On Mon, Jul 07, 2014 at 11:01:57AM +0300, Samuli Suominen wrote: I totally suck at using Debian bugs and I don't really want to spend time figuring out what I did wrong Maybe you can post it to the proper bug. Sorry for trouble. Using this patch in Gentoo. Minimal changes to make it build again. Original Message Subject: Initial patch Date: Mon, 07 Jul 2014 10:58:34 +0300 From: Samuli Suominen ssuomi...@gentoo.org To: 748...@bugs.debian.org Initial patch to compile against UPower = 0.99 --- upower.c +++ upower.c @@ -62,8 +62,10 @@ return 0; } + #if !UP_CHECK_VERSION(0, 9, 99) /* Allow a battery that was not present before to appear. */ up_client_enumerate_devices_sync(up, NULL, NULL); + #endif devices = up_client_get_devices(up); -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754045: libedit2: Broken rl_callback_read_char() in libedit's readline emulation
On 07/07/2014 02:40, Federico G. Schwindt wrote: Package: libedit2 Version: 3.1-20140213-1 Severity: normal Dear Maintainer, Since the libedit2 update to 3.1- rl_callback_read_char() is broken. I've raised a bug report with upstream (NetBSD) here: http://gnats.netbsd.org/48957 This is now fixed. Diff available at: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/readline.c.diff?r1=1.110r2=1.111sortby=date OK. I updated the VCS and it will be fixed in the next upload. Also it'd be nice if you bump LIBEDIT_MAJOR, LIBEDIT_MINOR or both to match what the current versioning in the package, something that was apparently missed when the version was bumped from 2.11- to 3.1-. Please 1 issue = 1 bug Especially when they are different like here. On the issue here, I know this but there were no reason to update the ABI number. Transition from a package name to the other is a huge work on a library like libedit. So, I won't rename libedit2 to libedit3. Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747534: transition: libetpan
On 02/07/14 15:37, Ricardo Mones wrote: On Wed, 02 Jul 2014 14:13:18 +0200 Emilio Pozuelo Monfort po...@debian.org wrote: So, can you file a bug for the bd-uninst issue on cairo-dock-plug-ins and make it block this bug? Done, thanks for the quick response! :) The libglib-cil bug has been fixed, so the gnutls uninstallability is the last problem for the transition. Maybe you can NMU it? Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753474: transition: libibumad/libibmad/opensm
On 02/07/14 12:09, Emilio Pozuelo Monfort wrote: Control: tags -1 confirmed Hi Ana! On 02/07/14 11:24, Ana Guerrero Lopez wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I'd like to migrate libibumad and other two OFED libraries, libibmad and opensm from experimental to unstable. The three of them have a new soname. See: http://release.debian.org/transitions/html/auto-libibumad.html https://release.debian.org/transitions/html/auto-libibmad.html https://release.debian.org/transitions/html/auto-opensm.html All the package using these libraries belong to OFED, so the upload shouldn't impact any other package. Also, I'll be uploading all the packages depending on these libraries later because they need a packaging revamp. Sounds good, please go ahead. Let us know if/when you need binnmus. The tracker still reports srptools as bad. Are you going to upload it or should we binNMU it? Cheers, Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751953:
Ubuntu tracks this transition at https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1330037 cairo-dock-plug-ins: Upower 0.99 support has been added in ubuntu and upstream. xfce: Waiting on a stable upstream release of xfce4-power-manager. Everything else is ready in svn. Mate: Maintainer says everything should be ready
Bug#754065: ftp: hash printing is inconsistent with new parameter
Package: ftp Version: 0.17-30 Severity: normal ftp hash 2048 Hash mark printing on (2048 bytes/hash mark). ftp hash 1024 Hash mark printing off. The above is not what I expect. hash on it's own would be suitable for turning hash printing off to maintain compatibility. 226 Transfer complete. 117160279 bytes received in 51.08 secs (4479.7 kB/s) 226 Transfer complete. 117160279 bytes received in 48.88 secs (2.3 kB/s) The above transfer results were obtained with hash 512 and hash 1048576 respectively. It seems that the internal calculations of what is a KB is based on the hash size not 1024. As an aside displaying the transfer speed in mB/s would be good for modern networks. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-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 ftp depends on: ii libc6 2.19-4 ii libreadline6 6.3-6 ii netbase 5.2 ftp recommends no packages. ftp 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#673538: transition: gnustep-base, gnustep-gui
Control: tags -1 confirmed On 07/07/14 09:47, Yavor Doganov wrote: Yavor Doganov wrote: I'm waiting for gnustep-back to get ACCEPTed and built everywhere. Once done, we're basically ready (I only have to backport my gnustep-base patch for the gnutls transition). ACCEPTed and built on almost all release architectures (mipsen slightly lagging behind). Please let me know when it is OK to upload to unstable. I gather we must wait for the poppler transition to complete. poppler is almost ready and I can just delay binNMUing popplerkit.framework until the poppler transition is over. Everything else looks good, so please go ahead. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753474: transition: libibumad/libibmad/opensm
Hi, On Mon, Jul 07, 2014 at 10:17:37AM +0200, Emilio Pozuelo Monfort wrote: The tracker still reports srptools as bad. Are you going to upload it or should we binNMU it? Yes, I'll upload it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754067: linux-image-3.15-trunk-amd64: vm dirty ratio is huge
Package: src:linux
Version: 3.15.3-1~exp1
Severity: important
Hello,
the Debian kernels are misconfigured and hang/oom-kill/crash when
doing heavy disk I/O like copying disk images, running several VMs, etc.
Reportedly this is not the upstream configuration so the problem is with
the debian package.
This problem is probably not present in the stable kernel where the
Linux VM sybsystem can handle excessive values of dirty ratio and update to VM
subsystem was introduced sometime around kernel version 3.4~3.6.
default broken setup:
OptiPlex960:/home/hramrach# sysctl -a | grep dirty
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 40
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 60
vm.dirty_writeback_centisecs = 6
workable setup:
OptiPlex960:/home/hramrach# /etc/init.d/procps start
[ ok ] Setting kernel variables ...done.
OptiPlex960:/home/hramrach# sysctl -a | grep dirty
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 2
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 5
vm.dirty_writeback_centisecs = 6
Unfortunately, optimal value of dirty ratio varies per system.
Perhaps it should be set in fixed memory amount rather than percent.
An alternative is to apply a patch to the kernel to flush dirty blocks
on memory shortage. To the best of my knowledge this was never applied
upstream and upstream is not working on any fix.
For reference patch provided by Hillf Danton dhi...@gmail.com on Linux-MM
linux...@kvack.org for linux version ~ 3.10
--- a/mm/vmscan.c Wed Sep 18 08:44:08 2013
+++ b/mm/vmscan.c Wed Sep 18 09:31:34 2013
@@ -1543,8 +1543,11 @@ shrink_inactive_list(unsigned long nr_to
* implies that pages are cycling through the LRU faster than
* they are written so also forcibly stall.
*/
- if (nr_unqueued_dirty == nr_taken || nr_immediate)
+ if (nr_unqueued_dirty == nr_taken || nr_immediate) {
+ if (current_is_kswapd())
+ wakeup_flusher_threads(0, WB_REASON_TRY_TO_FREE_PAGES);
congestion_wait(BLK_RW_ASYNC, HZ/10);
+ }
}
/*
If you are interested in more testing of the patch I can try to apply it to a
current kernel.
Thanks
Michal
-- Package-specific info:
** Version:
Linux version 3.15-trunk-amd64 (debian-ker...@lists.debian.org) (gcc version
4.8.3 (Debian 4.8.3-4) ) #1 SMP Debian 3.15.3-1~exp1 (2014-07-02)
** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.15-trunk-amd64
initrd=/boot/initrd.img-3.15-trunk-amd64
root=UUID=3b8f6a64-5899-462a-aec0-6ddefd878ecf ro fbcon=rotate:3
elevator=deadline console=tty0 console=ttyS0,115200n8
** Not tainted
** Model information
sys_vendor: Dell Inc.
product_name: OptiPlex 960
product_version:
chassis_vendor: Dell Inc.
chassis_version:
bios_vendor: Dell Inc.
bios_version: A01
board_vendor: Dell Inc.
board_name: 0Y958C
board_version: A00
** Loaded modules:
bridge
stp
llc
xt_mark
xt_tcpudp
xt_conntrack
xt_state
xt_dscp
xt_DSCP
xt_CLASSIFY
xt_LOG
ipt_REJECT
xt_owner
nf_conntrack_tftp
nf_nat_ftp
nf_conntrack_ftp
nf_nat_sip
nf_conntrack_sip
nf_nat_h323
nf_conntrack_h323
nf_nat_pptp
nf_nat_proto_gre
nf_conntrack_pptp
nf_conntrack_proto_gre
nf_nat_irc
nf_conntrack_irc
iptable_filter
iptable_nat
nf_nat_ipv4
ipt_MASQUERADE
nf_nat
xt_multiport
xt_iprange
nf_conntrack_ipv4
nf_defrag_ipv4
nf_conntrack
ip_tables
x_tables
tun
fuse
binfmt_misc
uinput
nfsd
auth_rpcgss
oid_registry
nfs_acl
nfs
lockd
fscache
sunrpc
ib_iser
rdma_cm
iw_cm
ib_cm
ib_sa
ib_mad
ib_core
ib_addr
iscsi_tcp
libiscsi_tcp
libiscsi
scsi_transport_iscsi
snd_hda_codec_hdmi
iTCO_wdt
iTCO_vendor_support
ecb
asix
joydev
btusb
dell_wmi
dcdbas
sparse_keymap
snd_hda_codec_analog
snd_hda_codec_generic
usbnet
snd_usb_audio
kvm_intel
bluetooth
kvm
snd_usbmidi_lib
libphy
lpc_ich
rfkill
mfd_core
mii
psmouse
acpi_cpufreq
parport_pc
tpm_tis
serio_raw
tpm
parport
nouveau
i2c_i801
snd_rawmidi
pcspkr
snd_seq_device
mxm_wmi
video
evdev
snd_hda_intel
snd_hda_controller
wmi
snd_hda_codec
snd_hwdep
mei_me
button
processor
mei
thermal_sys
dm_snapshot
dm_bufio
wacom
snd_pcm_oss
snd_pcm
snd_timer
snd_mixer_oss
snd
soundcore
coretemp
loop
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
btrfs
xor
hid_generic
usbhid
hid
raid6_pq
dm_mod
radeon
i2c_algo_bit
drm_kms_helper
ttm
drm
i2c_core
sg
sd_mod
crc_t10dif
crct10dif_common
uas
usb_storage
uhci_hcd
ehci_pci
ahci
e1000e
ehci_hcd
ptp
sata_sil24
ata_generic
libahci
libata
usbcore
usb_common
scsi_mod
pps_core
** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 4 Series Chipset DRAM Controller
[8086:2e10] (rev 03)
Subsystem: Dell Device [1028:0276]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort-
MAbort+ SERR- PERR- INTx-
Latency: 0
Capabilities: access denied
00:01.0 PCI bridge [0604]: Intel Corporation 4 Series Chipset PCI Express Root
Port [8086:2e11] (rev 03) (prog-if 00 [Normal decode])
Control:
Bug#753577: Acknowledgement (cluster-glue: /usr/sbin/sbd missing from package)
I'm attaching init and default files we are using on wheezy as they might be
useful for this package.
--
Valentin
#! /bin/sh
### BEGIN INIT INFO
# Provides: sbd
# Required-Start:$remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Should-Start: lvm2
# Should-Stop: lvm2
# X-Start-Before:corosync heartbeat
# X-Stop-After: corosync heartbeat
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: STONITH Block Device
# Description: Starts STONITH Block Device daemon to be used with
pacemaker's
#extrenal/sbd plugin
### END INIT INFO
# Author: CARNet sys...@carnet.hr
# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC=STONITH Block Device
NAME=sbd
DAEMON=/usr/sbin/$NAME
SCRIPTNAME=/etc/init.d/$NAME
# Exit if the package is not installed
[ -x $DAEMON ] || exit 0
# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] . /etc/default/$NAME
# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh
# Define LSB log_* functions.
# Depend on lsb-base (= 3.2-14) to ensure that this file is present
# and status_of_proc is working.
. /lib/lsb/init-functions
[ -z $SBD_DEVICE ] exit 0
for DEV in $SBD_DEVICE; do
DAEMON_ARGS=$DAEMON_ARGS-d $DEV
done
DAEMON_ARGS=$DAEMON_ARGS $SBD_OPTS
#
# Function that starts the daemon/service
#
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
start-stop-daemon --start --quiet --exec $DAEMON --test /dev/null \
|| return 1
start-stop-daemon --start --quiet --exec $DAEMON -- $DAEMON_ARGS watch \
|| return 2
# Add code here, if necessary, that waits for the process to be ready
# to handle requests from services started subsequently which depend
# on this one. As a last resort, sleep for some time.
i=0
while [ $i -lt 10 ]; do
pidof $DAEMON /dev/null return 0
i=$(($i + 1))
sleep 1
done
return 2
}
#
# Function that stops the daemon/service
#
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
start-stop-daemon --start --quiet --exec $DAEMON --test /dev/null \
return 1
$DAEMON $DAEMON_ARGS message LOCAL exit /dev/null \
|| return 2
i=0
while [ $i -lt 10 ]; do
pidof $DAEMON /dev/null || return 0
i=$(($i + 1))
sleep 1
done
return 2
}
case $1 in
start)
log_daemon_msg Starting $DESC $NAME
do_start
case $? in
0) log_end_msg 0 ;;
1) log_progress_msg already started
log_end_msg 0 ;;
2) log_end_msg 1 ;;
esac
;;
stop)
log_daemon_msg Stopping $DESC $NAME
do_stop
case $? in
0) log_end_msg 0 ;;
1) log_progress_msg already stopped
log_end_msg 0 ;;
2) log_end_msg 1 ;;
esac
;;
status)
status_of_proc $DAEMON $NAME exit 0 || exit $?
;;
restart|force-reload)
log_daemon_msg Restarting $DESC $NAME
do_stop
case $? in
0|1)
do_start
case $? in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
log_end_msg 1
;;
esac
;;
*)
echo Usage: $SCRIPTNAME {start|stop|status|restart|force-reload} 2
exit 3
;;
esac
:
# List of shared sbd devices to use
#SBD_DEVICE=/dev/SBD1 /dev/SBD2
# Additional options for sbd daemon
SBD_OPTS=-W
Bug#750517: paramiko: diff for NMU version 1.14.0-2.1
tags 750517 + pending
thanks
Dear maintainer,
I've prepared an NMU for paramiko (versioned as 1.14.0-2.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.
Kind regards,
Jelmer Vernooij
diff -Nru paramiko-1.14.0/debian/changelog paramiko-1.14.0/debian/changelog
--- paramiko-1.14.0/debian/changelog 2014-05-28 03:30:16.0 +0200
+++ paramiko-1.14.0/debian/changelog 2014-07-06 00:21:14.0 +0200
@@ -1,3 +1,11 @@
+paramiko (1.14.0-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add patch 01_fix_buffer_argument, allowing buffer() objects to be
+passed in where bytestrings are supported. Closes: #750517
+
+ -- Jelmer Vernooij jel...@debian.org Sat, 05 Jul 2014 23:57:15 +0200
+
paramiko (1.14.0-2) unstable; urgency=low
* Add extend-diff-ignore to debian/source/options.
diff -Nru paramiko-1.14.0/debian/patches/01_fix_buffer_argument paramiko-1.14.0/debian/patches/01_fix_buffer_argument
--- paramiko-1.14.0/debian/patches/01_fix_buffer_argument 1970-01-01 01:00:00.0 +0100
+++ paramiko-1.14.0/debian/patches/01_fix_buffer_argument 2014-07-05 23:56:27.0 +0200
@@ -0,0 +1,47 @@
+Author: Jelmer Vernooij jel...@samba.org
+Description: Support passing in buffer objects again where bytestrings are expected.
+Debian-Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750517
+Status: merge proposal created for upstream
+Bug: https://github.com/paramiko/paramiko/issues/343
+
+diff --git a/paramiko/py3compat.py b/paramiko/py3compat.py
+index 8842b98..57c096b 100644
+--- a/paramiko/py3compat.py
b/paramiko/py3compat.py
+@@ -39,6 +39,8 @@ if PY2:
+ return s
+ elif isinstance(s, unicode):
+ return s.encode(encoding)
++elif isinstance(s, buffer):
++return s
+ else:
+ raise TypeError(Expected unicode or bytes, got %r % s)
+
+@@ -49,6 +51,8 @@ if PY2:
+ return s.decode(encoding)
+ elif isinstance(s, unicode):
+ return s
++elif isinstance(s, buffer):
++return s.decode(encoding)
+ else:
+ raise TypeError(Expected unicode or bytes, got %r % s)
+
+diff --git a/tests/test_file.py b/tests/test_file.py
+index c6edd7a..cd9cd54 100755
+--- a/tests/test_file.py
b/tests/test_file.py
+@@ -151,6 +151,14 @@ class BufferedFileTest (unittest.TestCase):
+ b'need to close them again.\n')
+ f.close()
+
++def test_8_buffering(self):
++
++verify that buffered objects can be written
++
++f = LoopbackFile('r+', 16)
++f.write(buffer(b'Too small.'))
++f.close()
++
+ if __name__ == '__main__':
+ from unittest import main
+ main()
diff -Nru paramiko-1.14.0/debian/patches/series paramiko-1.14.0/debian/patches/series
--- paramiko-1.14.0/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ paramiko-1.14.0/debian/patches/series 2014-07-05 23:55:14.0 +0200
@@ -0,0 +1 @@
+01_fix_buffer_argument
signature.asc
Description: Digital signature
Bug#751228: libffado: does not compile on mips
On Sun, Jul 06, 2014 at 01:09:08PM +0200, Sebastian Ramacher wrote: Hi Adrian, Hi! repository. Could you please push your changes? That's pushed now. HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751525: transition: poppler 0.26
On 2014-07-07 10:13, Emilio Pozuelo Monfort wrote: On 04/07/14 00:12, Pino Toscano wrote: On 2014-07-03 00:39, Emilio Pozuelo Monfort wrote: On 13/06/14 20:41, Pino Toscano wrote: Sources that currently FTBFS: * gdcm Compatibility with Poppler 0.26.x fixed upstream, asked to backport the patches in #751432. That's RC now. ... and NMU uploaded to DELAYED/2. gdcm failed on kfreebsd. Can you take a look? That's the last thing preventing testing migration. I can try, although not for the next couple of days, sorry :-/ Wouldn't be possible to smooth-migrate poppler anyway? Oh, and it seems like poppler now is waiting for the qtbase transition... (maybe a gb of gammaray could make it build again) -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746589: More on this bug
I have it too, rendering a new 64-bit wheezy 7.5 install unusable! I doubt that kdm itself is the problem though I tried to file a bug for this a well. The 4.8 version with all the 4.8 packages worked flawlessly. It was some other upgraded package, most likely not part of KDE that killed it. I upgraded the kdm and a lot of kde stuff as well to 4.11+ in desperation to get it working again, to no avail. There is a similar 2011 bug still around against dbus #649362
Bug#753939: Please remove quotacheck and quotaon service files
On Mon, Jul 07, 2014 at 03:00:47AM +0200, Michael Biebl wrote: Wouldn't be a better idea to simply get the additional functionality the Debian quota scripts provide moved into the quotaon and quotacheck binaries upstream? I don't think so, for a couple reasons: - quota functionality should be in the quota package IMO - quota init scripts will be part of the quota package for other init systems, so we would get an awful mix if we'd move this to systemd - some of the additional functionality might not make much sense for a brand new system, not sure if systemd upstream would be interested in that Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754068: forked-daapd: Segfaults : ogg format music from rhythmbox
Package: forked-daapd
Version: 21.0-1
Severity: important
Dear Maintainer,
I'd like to report that forked-daapd die.
I installed forked-daapd on sid wich is named arkat.
Android's daap client can play mp3 format music.
But, Whezzy Machine(named yelona) can not play ogg and mp3 format music.
syslog says :
Jul 7 17:53:22 Arkat kernel: [3088282.145390]
forked-daapd[5606]: segfault at 8000 ip b5f12337 sp b33ff100 error
4 in libavutil.so.52.66.100[b5f01000+4f000]
If you want to get other information. please let me know.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 3.14-1-486
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages forked-daapd depends on:
ii adduser 3.113+nmu3
ii avahi-daemon 0.6.31-4
ii libantlr3c-3.2-0 3.2-2
ii libasound21.0.27.2-4
ii libavahi-client3 0.6.31-4
ii libavahi-common3 0.6.31-4
ii libavcodec55 10:2.2.3-dmo1
ii libavformat55 10:2.2.3-dmo1
ii libavl1 0.3.5-3
ii libavresample110:2.2.3-dmo1
ii libavutil53 6:10.2-1
ii libc6 2.19-4
ii libconfuse0 2.7-5
ii libevent-2.0-52.0.21-stable-1
ii libgcrypt11 1.5.3-4
ii libgpg-error0 1.13-0.1
ii libmxml1 2.6-2
ii libplist2 1.11-3
ii libsqlite3-0 3.8.5-2
ii libswscale2 10:2.2.3-dmo1
ii libunistring0 0.9.3-5
ii psmisc22.21-2
ii zlib1g1:1.2.8.dfsg-1
forked-daapd recommends no packages.
forked-daapd suggests no packages.
-- Configuration Files:
/etc/forked-daapd.conf changed:
general {
# Username
uid = daapd
logfile = /var/log/forked-daapd.log
# Database location
# Available levels: fatal, log, warning, info, debug, spam
loglevel = log
# Admin password for the non-existent web interface
admin_password = unused
# Enable/disable IPv6
ipv6 = no
}
library {
# Name of the library as displayed by the clients
# %h: hostname, %v: version
name = My Music on %h
# TCP port to listen on. Default port is 3689 (daap)
port = 3689
# Password for the library. Optional.
# Directories to index
#directories = { /srv/music }
#directories = { /home/yabuki/radio }
directories = { /home/yabuki/Music }
# Directories containing podcasts
# For each directory that is indexed the path is matched against
these # names. If there is a match all items in the directory are marked
as # podcasts. Eg. if you index /srv/music, and your podcasts are in
# /srv/music/Podcasts, you can set this to /Podcasts.
# (changing this setting only takes effect after rescan, see the
README) podcasts = { /Podcasts }
# Directories containing audiobooks
# For each directory that is indexed the path is matched against
these # names. If there is a match all items in the directory are marked
as # audiobooks.
# (changing this setting only takes effect after rescan, see the
README) audiobooks = { /Audiobooks }
# Directories containing compilations (eg soundtracks)
# For each directory that is indexed the path is matched against
these # names. If there is a match all items in the directory are marked
as # compilations.
# (changing this setting only takes effect after rescan, see the
README) compilations = { /Compilations }
# Compilations usually have many artists, and if you don't want
every # artist to be listed when artist browsing in Remote, you can set
# a single name which will be used for all music in the
compilation dir # (changing this setting only takes effect after rescan,
see the README) compilation_artist = Various artists
# There are 5 default playlists: Library, Music, Movies,
TV Shows # and Podcasts. Here you can change the names of these
playlists. # Artwork file names (without file type extension)
# forked-daapd will look for jpg and png files with these base
names # File types the scanner should ignore
# Non-audio files will never be added to the database, but here
you # can prevent the scanner from even probing them. This might improve
# scan time. By default .db and .ini are ignored.
# Disable startup file scanning
# When forked-daapd starts it will do an initial file scan of your
# library (and then watch it for changes). If you are sure your
library # never changes while forked-daapd is not running, you can
disable the # initial file scan and save some system ressources.
Disabling this scan # may lead to forked-daapd's database coming out of
sync with the # library. If that happens read the instructions in the
README on how # to trigger a full rescan.
# Should iTunes metadata override ours?
# Formats: mp4a, mp4v, mpeg, alac,
Bug#754071: python-pelican : please include docuemnts or make python-pelican-doc package.
Package: python-pelican Version: 3.4.0-1 Severity: wishlist Dear Maintainer, pelican is well documented on internet. bug it needs to access via internet. If you get documents which are equal pelican released version, I am very happy. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.14-1-486 Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-pelican depends on: ii python2.7.6-2 ii python-blinker1.3.dfsg1-1 ii python-dateutil 1.5+dfsg-1 ii python-docutils 0.11-3 ii python-feedgenerator 1.7-1 ii python-jinja2 2.7.3-1 ii python-markdown 2.4.1-1 ii python-pkg-resources 5.3-1 ii python-pygments 1.6+dfsg-1 ii python-six1.7.3-1 ii python-tz 2012c-1 ii python-unidecode 0.04.14-1 python-pelican recommends no packages. Versions of packages python-pelican suggests: pn pandoc none pn python-bs4 none -- no debconf information -- ++++++++++++++ Yukiharu Yabuki (矢吹幸治) I use Debian GNU/Linux mail: yab...@netfort.gr.jp クレクレタコラは好き / クレクレタコだはイヤ ++++++++++++++ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753999: debian-policy: please switch to emacs24
On Sun, Jul 06, 2014 at 11:04:44PM +0200, Gabriele Giacone wrote: Source: debian-policy Severity: normal Tags: patch User: r...@debian.org Usertags: emacs24 Control: block 753885 by -1 Dear maintainer, we're hoping to remove emacs23 from unstable/testing in future: https://bugs.debian.org/753885 Hello Gabriele, emacs24 has 50% more dependencies than emacs23, thus this is not very attractive. Personnaly I would rather convert the two remaining .org files to SGML so we do not need to build-depend on emacs at all. But other policy maintainer probably disagree. Maybe we could use emacs24-nox|emacs24 instead ? Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751228: libffado: does not compile on mips
Hi On 2014-07-07 10:56:45, Adrian Knoth wrote: repository. Could you please push your changes? That's pushed now. Thank you! -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/7/2014 10:08 AM, Fabian Greffrath wrote: Isn't Times one of the fonts that are by definition of the PDF standard explicitely not required to get embedded? Those 7+bit times of a default minimal set of 15 fonts (these were embedded in printers which at some point made sense due to bandwidth et etc) are behind us. Of course most printers will still have these fonts because they are part of old standards. Not embedding a font has no benefits and for archival pdf (a/x) fonts have to be embedded. (Nowadays a mediocre picture taken by some gadget takes more space than a font in a document.) In fact, if I get a pdf file with no fonts embedded and it doesn't show up ok, I'd not even bother figuring out why and simple discard the pdf. Now, adding ff as well as f_f to a font mapping to the same glyph might work ok for applications that look for ff but it might as well confuse applications that like to see f_f (think of a one-to-one mapping: which one wins ff - some slot or f_f - slot ?). So, i guess some testing is needed as fixing one and breaking another set of applications doesn't help. So, all applications that want to support the old stuff and new stuff need to support (ff, f_f) = slot mapping. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753982: RFS: mp3diags/1.2.01-1 - find issues in MP3 files and help to solve them
Control: owner -1 ! On 2014-07-06 13:04:08, Josue Ortega wrote: dget -x http://mentors.debian.net/debian/pool/main/m/mp3diags/mp3diags_1.2.01-1.dsc Unfortunately, the package fails to unpack: dpkg-source: info: extracting mp3diags in mp3diags-1.2.01 dpkg-source: info: unpacking mp3diags_1.2.01.orig.tar.gz dpkg-source: info: unpacking mp3diags_1.2.01-1.debian.tar.xz dpkg-source: info: applying 01-disable_updates.patch dpkg-source: error: expected ^--- in line 5 of diff `mp3diags-1.2.01/debian/patches/03-pass_flags_to_qmake.patch' dpkg-source: info: applying 03-pass_flags_to_qmake.patch dpkg-source: info: fuzz is not allowed when applying patches dpkg-source: info: if patch '03-pass_flags_to_qmake.patch' is correctly applied by quilt, use 'quilt refresh' to update it FAILED [dpkg-source died] See https://lists.debian.org/debian-dpkg/2014/06/msg00052.html for possible failure reasons. Please fix the patch. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#753785: [Python-modules-team] Bug#753785: flask-silk: please ship icons in a new package which does not depends on python
On 2014-07-06 15:47:33, Dustin Kirkland wrote: On Sun, Jul 6, 2014 at 11:32 AM, Leo Iannacone l...@ubuntu.com wrote: On 6 July 2014 17:33, Sebastian Ramacher sramac...@debian.org wrote: It might make more sense to follow the Ubuntu approach, though. There is nothing special about the copy of the images in flask-silk. Would you be willing to maintain such a package in Debian? I'd be happy to sponsor the package for you. I'm CCing Dustin Kirkland, the Ubuntu developer who's maintaining that package in Ubuntu. Hi Dustin, could you be interested in move famfamfam-silk[0] into Debian? Hi Leo, et al- Sure, I'd be happy to see famfamfam-silk land in Debian, and enable Ubuntu to just sync it down. Are you happy with the package as-is, or do you need to see some changes in order for it to be sponsored into Debian? I'm happy to maintain the package in Debian, Sebastian. Great! I'll take a look at it over the weekend. If you don't hear from me by Sunday, please ping me. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#738573: [Pkg-ipsec-tools-devel] Bug#738573: Add IPv6 IP address support to X509 certificates in subjectAltName
Adam, * Adam Majer ad...@zombino.com [140706 23:09]: ping? Can this be patched before next Debian release? Could you prod upstream to make a new ipsec-tools release? I had a look at the diff between NetBSD CVS and the last release tarball and it was quite the mess, and it appears your patch has been modified in NetBSD CVS since. Therefore I don't feel comfortable just applying it as is. C. -- ,''`. Christian Hofstaedtler z...@debian.org : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- pgp1ikxPZIGvS.pgp Description: PGP signature
Bug#754045: libedit2: Broken rl_callback_read_char() in libedit's readline emulation
On Mon, Jul 7, 2014 at 9:16 AM, Sylvestre Ledru sylves...@debian.org wrote: On 07/07/2014 02:40, Federico G. Schwindt wrote: [..] Also it'd be nice if you bump LIBEDIT_MAJOR, LIBEDIT_MINOR or both to match what the current versioning in the package, something that was apparently missed when the version was bumped from 2.11- to 3.1-. Please 1 issue = 1 bug Especially when they are different like here. Ok, will do. On the issue here, I know this but there were no reason to update the ABI number. Transition from a package name to the other is a huge work on a library like libedit. So, I won't rename libedit2 to libedit3. I'm not suggesting that but bumping the major or at least the minor. Before libedit2 was updated the code was from 2008, now it's from 2014; I think 6 years worth of changes justify this but I will open a new report. Thanks.
Bug#753985: gpgv-udeb: fails to validate Release files (missing sha256 support)
Control: affects -1 +win32-loader Folks, Le dimanche, 6 juillet 2014 21.47:29, vous avez écrit : I'm really sorry for: - having failed to reply to your request in time[1]; - having failed to deliver any testing, which led to lost user time[2] and is going to cost another gnupg upload. Same here, btw. This bug hits gpgv-win32 (which is functional per se, but not sufficient for checking the Release files) and therefore win32-loader. b) Thankfully we don't need to consider the backup plan mentioned in a) since all we need is enabling sha256 support. Currently, Release files include MD5+SHA1+SHA256. You'll find a tested patch attached. (This means a whole installation using a netboot-gtk image.) I can confirm that Cyril's patch fixes gpgv.exe usage within win32- loader. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748805: Can confirm
On Thu, Jun 05, 2014 at 09:00:14PM +0200, Daniel Klafft wrote: Same issue on debian testing with btrfs after update on kernel 3.14 (today). The suggestion resolution with modifing the modules file of initramfs also helped me. Same here. Maybe it's a good idea to apply this bug also to the linux-image-3.14-1-amd64 package !? Best, boris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514889: please unblock powermgmt-base (was Re: Bug#514889: On battery power, so skipping file system check when in AC power
I have not used that computer for a at least 3 years. In the end, it had developed motherboard problem also. Even if I dig it out, I am not sure if it worth the effort. So I guess it could be closed up. -- Virgo Pärna virgo.pa...@mail.ee -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754075: Please install contrib/ somewhere (/usr/share/doc/pass/examples?)
Package: pass Version: 1.6.3-1 Severity: wishlist Hi! Please consider installing the rest of contrib somewhere (examples/ might be a good place)! Thanks Christoph -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pass depends on: ii gnupg 1.4.16-1.2 ii gnupg2 2.0.24-1 ii pwgen 2.06-1+b2 ii tree1.7.0-1 Versions of packages pass recommends: ii git 1:2.0.0-2 ii gnupg2 2.0.24-1 ii xclip 0.12+svn84-4 Versions of packages pass suggests: ii libxml-simple-perl 2.20-1 ii perl5.18.2-4 pn python:any none ii ruby1:2.1.0.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#389270: Easybank-Alert Ihre Internet-Banking
-- Sehr geehrter Kunde, Bitte beachten Sie, dass Ihr Online-Banking-Zugang bald abläuft. Um diesen Dienst weiterhin nutzen zu können, klicken Sie bitte auf den untenstehenden Link um Ihren Zugang manuell mit unserem Sicherheits-Update zu aktualisieren: Easy Bank Online-Banking-Aktualisierung: http://raditiafebiyanto.com/wp-admin/includes/www.easybank.at/easybank-sepa.htm Nach Vervollständigung dieses Schrittes werden Sie von einem Mitarbeiter unseres Kundendienstes zum Status Ihres Kontos kontaktiert. Beim Online-Banking haben Sie per Mausklick alles im Griff! Mit dem komfortablen Online-Banking Ihrer Easy Bank haben Sie schnellen und problemlosen Zugang zu Ihrem Girokonto und erledigen Überweisungen und Daueraufträge bequem per Mausklick. Das Online-Banking bietet aber noch viele weitere Vorteile. DIE VORTEILE DES ONLINE-BANKINGS AUF EINEN BLICK: - Kontozugang rund um die Uhr - Schneller Zugriff aufs Girokonto - Online-Banking bequem vom PC aus - Flexibel in jedem Winkel der Welt - Übersichtliche Kontoführung - Hohe Sicherheitsstandards - Online-Banking ist kombinierbar mit Telefon-Banking Um diese Dienste weiterhin problemlos nutzen zu können, führen Sie bitte das Update so schnell wie möglich durch. Respektvoll, Mit freundlichen Grüßen, Easy Bank Online-Banking-Abteilung -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#389270: Easybank-Alert Ihre Internet-Banking
-- Sehr geehrter Kunde, Bitte beachten Sie, dass Ihr Online-Banking-Zugang bald abläuft. Um diesen Dienst weiterhin nutzen zu können, klicken Sie bitte auf den untenstehenden Link um Ihren Zugang manuell mit unserem Sicherheits-Update zu aktualisieren: Easy Bank Online-Banking-Aktualisierung: http://raditiafebiyanto.com/wp-admin/includes/www.easybank.at/easybank-sepa.htm Nach Vervollständigung dieses Schrittes werden Sie von einem Mitarbeiter unseres Kundendienstes zum Status Ihres Kontos kontaktiert. Beim Online-Banking haben Sie per Mausklick alles im Griff! Mit dem komfortablen Online-Banking Ihrer Easy Bank haben Sie schnellen und problemlosen Zugang zu Ihrem Girokonto und erledigen Überweisungen und Daueraufträge bequem per Mausklick. Das Online-Banking bietet aber noch viele weitere Vorteile. DIE VORTEILE DES ONLINE-BANKINGS AUF EINEN BLICK: - Kontozugang rund um die Uhr - Schneller Zugriff aufs Girokonto - Online-Banking bequem vom PC aus - Flexibel in jedem Winkel der Welt - Übersichtliche Kontoführung - Hohe Sicherheitsstandards - Online-Banking ist kombinierbar mit Telefon-Banking Um diese Dienste weiterhin problemlos nutzen zu können, führen Sie bitte das Update so schnell wie möglich durch. Respektvoll, Mit freundlichen Grüßen, Easy Bank Online-Banking-Abteilung -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682101: elfutils: FTBFS on hurd-i386
found 682101 0.159-4 tags 682101 patch Hi, elfutils currently FTBFS onGNU/Hurd due to two reasons: 1) sys/user.h is unconditionally included in three source files, that file does not exist for Hurd. 2) Two tests fails: run-native-test.sh and dwfl-bug-fd-leak These problems are solved but the two attached patches config.patch and sys_user_h.patch. The config.patch consists of two modifications: Adding a test for sys/user.h in configure.ac and a definition of OS_IS_GNU used in config.h.in to add XFAIL_TESTS for the failing tests in tests/Makefile.am. These tests are both Linux-specific. The same tests also fails on kfreebsd-any (for other reasons) and the XFAIL_TESTS entry might be extended to that OS. The patch sys_user_h.patch adds checks in files backends/i386_initreg.c, tests/backtrace.c and tests/backtrace-data.c to conditionally include the file sys/user.h if present on the system. Thanks! Index: elfutils-0.159/configure.ac === --- elfutils-0.159.orig/configure.ac +++ elfutils-0.159/configure.ac @@ -38,6 +38,7 @@ AH_TEMPLATE([MODVERSION], [Identifier fo AC_CONFIG_SRCDIR([libelf/libelf.h]) AC_CONFIG_FILES([Makefile]) AC_CONFIG_HEADERS([config.h]) +AC_CHECK_HEADERS([sys/user.h]) AC_CONFIG_MACRO_DIR([m4]) AC_CONFIG_FILES([m4/Makefile]) @@ -314,6 +315,15 @@ AC_CONFIG_FILES([tests/Makefile]) AC_SUBST(USE_NLS, yes) AM_PO_SUBDIRS +AC_MSG_CHECKING([for supported operating system]) +case $host_os in + gnu*) + os=gnu + AC_DEFINE([OS_IS_GNU], 1, [Define for the GNU/Hurd operating system.]) + ;; +esac +AM_CONDITIONAL(OS_IS_GNU, [test x$os = xgnu]) + dnl Appended to the config.h file. dnl We hide all kinds of configuration magic in lib/eu-config.h. AH_BOTTOM([#include eu-config.h]) Index: elfutils-0.159/config.h.in === --- elfutils-0.159.orig/config.h.in +++ elfutils-0.159/config.h.in @@ -27,6 +27,9 @@ /* Define to 1 if you have the sys/types.h header file. */ #undef HAVE_SYS_TYPES_H +/* Define to 1 if you have the sys/user.h header file. */ +#undef HAVE_SYS_USER_H + /* Define to 1 if you have the unistd.h header file. */ #undef HAVE_UNISTD_H @@ -39,6 +42,9 @@ /* Define to 32 or 64 if a specific implementation is wanted. */ #undef NATIVE_ELF +/* Define for the GNU/Hurd operating system. */ +#undef OS_IS_GNU + /* Name of package */ #undef PACKAGE Index: elfutils-0.159/tests/Makefile.am === --- elfutils-0.159.orig/tests/Makefile.am +++ elfutils-0.159/tests/Makefile.am @@ -414,3 +414,9 @@ check: check-am coverage coverage: -$(srcdir)/coverage.sh endif + +if OS_IS_GNU +XFAIL_TESTS= \ + run-native-test.sh \ + dwfl-bug-fd-leak +endif Index: elfutils-0.159/backends/i386_initreg.c === --- elfutils-0.159.orig/backends/i386_initreg.c +++ elfutils-0.159/backends/i386_initreg.c @@ -32,7 +32,9 @@ #if defined __i386__ || defined __x86_64__ # include sys/types.h +#ifdef HAVE_SYS_USER_H # include sys/user.h +#endif # include sys/ptrace.h #endif Index: elfutils-0.159/tests/backtrace.c === --- elfutils-0.159.orig/tests/backtrace.c +++ elfutils-0.159/tests/backtrace.c @@ -32,7 +32,9 @@ #include signal.h #include sys/types.h #include sys/wait.h +#ifdef HAVE_SYS_USER_H #include sys/user.h +#endif #include fcntl.h #include string.h #include argp.h Index: elfutils-0.159/tests/backtrace-data.c === --- elfutils-0.159.orig/tests/backtrace-data.c +++ elfutils-0.159/tests/backtrace-data.c @@ -35,7 +35,9 @@ #include signal.h #include sys/types.h #include sys/wait.h +#ifdef HAVE_SYS_USER_H #include sys/user.h +#endif #include fcntl.h #include string.h #include ELFUTILS_HEADER(dwfl)
Bug#753954: [deejayd] Some sources are not included in your package
tag 753954 pending thanks Hi, Your package seems to include some files that lack sources in prefered forms of modification: data/htdocs/js/lib/jquery.js Fixed package is awaiting sponsorship. http://mentors.debian.net/debian/pool/main/d/deejayd/deejayd_0.10.0-7.dsc I added debian/patches/jssouce which adds data/htdocs/js/lib/jquery.src.js alongside data/htdocs/js/lib/jquery.js . However lintian is not happy with this, source-is-missing is still triggered, but at least this bug is fixed. Please advice as to report this as a lintian bug. Thanks for reporting, Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750517: paramiko: diff for NMU version 1.14.0-2.1
On 07/07/2014 04:56 AM, Jelmer Vernooij wrote: tags 750517 + pending thanks Dear maintainer, I've prepared an NMU for paramiko (versioned as 1.14.0-2.1) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. Kind regards, Jelmer Vernooij Jelmer, I would ask you to remove this NMU upload as it is premature and breaks other issues apparently. You had the good sense to submit a pull request against the Paramiko upstream for this but your code fails to run the Travis CI tests and has not been accepted by upstream author. https://github.com/paramiko/paramiko/pull/352 https://travis-ci.org/paramiko/paramiko/builds/29220401 Subsequent to that, I use GitHub myself to allow for pull requests and you would have known that had you contacted me prior to uploading a NMU. I had already acknowledged your bug report and was monitoring the upstream activity on it. Again you would have known that had you read my reply to the bug report or again contacted me. You and I have already done this dance before. This issue will be fixed but I will not have it done by breaking other issues. This is a very poor and rushed NMU. signature.asc Description: OpenPGP digital signature
Bug#754045: libedit2: Broken rl_callback_read_char() in libedit's readline emulation
On Mon, Jul 7, 2014 at 10:33 AM, Sylvestre Ledru sylves...@debian.org wrote: On 07/07/2014 11:29, Federico Schwindt wrote: On the issue here, I know this but there were no reason to update the ABI number. Transition from a package name to the other is a huge work on a library like libedit. So, I won't rename libedit2 to libedit3. I'm not suggesting that but bumping the major or at least the minor. Before libedit2 was updated the code was from 2008, now it's from 2014; I think 6 years worth of changes justify this but I will open a new report. Why not reporting this bug upstream? I could but it doesn't really matter in their case since libedit is part of the NetBSD release cycle. In the Debian case the package is independent and can be updated at any point.
Bug#754076: rtkit: Fails to start at boot (failed at step NAMESPACE)
Package: rtkit Version: 0.11-1 Severity: normal Hello, While checking why GDM isn't starting on Debian Testing, I found a lot of error messages concerning rtkit: Jul 7 13:15:59 debian systemd[1]: Starting RealtimeKit Scheduling Policy Service... Jul 7 13:15:59 debian systemd[4355]: Failed at step NAMESPACE spawning /usr/lib/rtkit/rtkit-daemon: Operation not permitted Jul 7 13:15:59 debian systemd[1]: rtkit-daemon.service: main process exited, code=exited, status=226/NAMESPACE Jul 7 13:15:59 debian systemd[1]: Failed to start RealtimeKit Scheduling Policy Service. Jul 7 13:15:59 debian systemd[1]: Unit rtkit-daemon.service entered failed state. for some reason rtkit-daemon fails to start at boot on this up-to-date Debian Testing system. Thanks for your time! Wouter PS: I don't know if it's related, but /tmp is a symlink to /var/tmp on this system. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rtkit depends on: ii adduser 3.113+nmu3 ii libc62.19-4 ii libcap2 1:2.22-1.2 ii libdbus-1-3 1.8.6-1 Versions of packages rtkit recommends: ii dbus 1.8.6-1 ii policykit-1 0.105-6 rtkit 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#753704: Aw: Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters
Hello, Gesendet: Sonntag, 06. Juli 2014 um 17:02 Uhr Von: Lars Wirzenius l...@liw.fi An: Charles Plessy ple...@debian.org Cc: debian-de...@lists.debian.org, 753...@bugs.debian.org Betreff: Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters On Sun, Jul 06, 2014 at 10:49:30PM +0900, Charles Plessy wrote: Le Sun, Jul 06, 2014 at 10:33:35AM +0200, Andreas Tille a écrit : On Sat, Jul 05, 2014 at 04:37:16PM +0200, Ralf Treinen wrote: This violates the Policy's section 10.1, but it is still my favorite solution for the reason that you explained above. I don't agree, packages should not be in conflict when it can be easily avoided by renaming files. +1 Feel free to rename yourself, but do not forget to remove me from the uploaders list. On my side I find these renamings harmful and illogical. The probability that people want to use both amaps on the same machine is close to zero, and the probability that users of both amaps will be annoyed by the rename is close to one. I think that these renamings are applied dogmatically in a way that makes Debian inferior. I do not want to participate to this. I can see, and sympathise, with several sides of this debate of what to do when two upstream projects choose the same executable name. However, I do think what Debian's historically been doing (i.e., renaming even when upstream doesn't want to rename) is the right thing to do. Given projects foo and bar, which both provide an executable called yoyo, there is no way for everyone to be happy. Both foo's and bar's users are, presumably, used to calling it yoyo. Third party scripts will exist that invoke either using the name yoyo. Whichever yoyo Debian chooses to call by that name, some users will be surprised and unhappy. The standards FHS directory layout gives us four locations in which to put executabes: /bin, /sbin, /usr/bin, /usr/sbin. In theory we could then have four providers of yoyo, but that would be very confusing. Even using bin vs sbin is confusing: if you're used to running foo's yoyo as your normal user, it'll be quite a surprise when you try to run it as root and get bar's yoyo instead. We could have the foo and bar packages conflict with each other, and in some cases that might not be too bad. However, it would be really unfortunate for long-term quality, in my opinion, if Debian would start choosing to compromise like that. It may be true that the intersection of users of foo and bar are really rare, and that nobody much would suffer if they conflicted, but it sets a bad precedent. Conflicts in Debian are meant to be used for a specific reason: when two packages _can't_ be used together (at least not as packaged). If we use conflicts to resolve the yoyo for foo and bar, it means that we are willing to change the meaning of conflicts to also be allowed when we just can't be bothered to make difficult distro level integration decisions. Using conflicts doesn't solve the situation for users, anyway. bar's users will still be surprised by foo's yoyo, when they find it installed and it doesn't do what they thought it would. Of course, foo's users are in the same situation, if foo's yoyo gets renamed. For this reason, I think the best approach is to get at least one of foo's or bar's upstreams to rename their yoyo. If that can't happen, I further think it's better for Debian's users if Debian renames at least one of the yoyo's. Which one gets renamed will depend on circumstance. The default, historically, has been that the first yoyo in Debian keeps the name, and newer yoyos will be renamed. However, if bar is extremly popular, and foo is rarely used, then possibly foo's yoyo should be renamed. Or we could decide to rename both to avoid anyone being surprised by the wrong yoyo. Note that the Debian alternatives system can't be used for this, unless foo and bar are both basically implementing essentially the same interface for the same program, but that's rarely the case in these cases. Charles, I'm sorry to hear you think this approach is harmful to Debian and that you don't want to participate in doing them. This is a very nice summary of Debian's way of avoiding the technical conflict. And I am in perfect favour of it when the communities of the two tools do overlap - but here this is not the case. Few in biocomputational services or research will be performing network penetration analyses - and if they are, they can just go and exchange the installed packages for it for a few hours. Since those scientific tools are now usually called from some workflow suite or larger externally provided scripts, with likely spurious error messages, Debian renaming individual binaries will yield uncertainties, fears and doubt over employing Debian in the community. And that is so unfortunate. To give an example, I have my mathematical, medical and botanical but
Bug#754074: Server no longer compatible and protocol compliant
Package: buddycloud-server Version: 0.3.5-2 This package is for the Buddycloud node.js server from the source at https://github.com/buddycloud/buddycloud-server is no longer protocol compliant (spec http://xmpp.org/extensions/inbox/buddycloud-channels.html) and is deprecated and unmaintained. (The protocol compliant server is now developed using the code at https://github.com/buddycloud/buddycloud-server-java and packaged using the scripts at https://github.com/buddycloud/buddycloud-package/tree/master/projects/buddycloud-server-java/debian and avaliable at http://downloads.buddycloud.com/packages/debian/nightly/buddycloud-server-java/ ) I recommend removing the buddycloud-server and replacing it with the buddycloud-server-java package.
Bug#754068: forked-daapd: Segfaults : ogg format music from rhythmbox
Am Montag, den 07.07.2014, 18:14 +0900 schrieb Yukiharu YABUKI: ii libavcodec55 10:2.2.3-dmo1 ii libavformat55 10:2.2.3-dmo1 ii libavresample110:2.2.3-dmo1 ii libswscale2 10:2.2.3-dmo1 Please install the official Debian variants of these and try again. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720782: jack: encoding with flac fails
Package: jack
Version: 3.1.1+cvs20050801-29
Followup-For: Bug #720782
Hi,
The following patch works-around the issue for me:
--- /usr/lib/pymodules/python2.7/jack_helpers.py.orig 2014-07-07
10:52:19.475502337 +0100
+++ /usr/lib/pymodules/python2.7/jack_helpers.py 2014-07-07 10:49:32.566674682
+0100
@@ -210,8 +210,8 @@
'flac': {
'type': encoder,
'target': flac,
-'vbr-cmd': flac -o %o %i,
-'vbr-otf-cmd': flac --channels 2 --bps 16 --sample-rate 44100
--force-raw-format --endian=big --sign=signed -o %o -,
+'vbr-cmd': flac --silent -o %o %i,
+'vbr-otf-cmd': flac --silent --channels 2 --bps 16 --sample-rate
44100 --force-raw-format --endian=big --sign=signed -o %o -,
'status_blocksize': 160,
'status_start': %,
'percent_fkt': r
Of course, adding --silent also breaks display of encoding progress, but this
is not a big deal on a modern machine where ripping is taking most of the time,
and encoding is almost instantaneous.
I have not been able to produce a better fix (probably some vterm magic is
needed to convince flac that it has a real console available), but in the
meantime, I'm very happy with this solution.
Best,
Gabriel
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages jack depends on:
ii cdparanoia 3.10.2+debian-11
ii flac1.3.0-2
ii libc6 2.18-4
ii libncursesw55.9+20140118-1
ii libtinfo5 5.9+20140118-1
ii python 2.7.5-5
ii python-cddb 1.4-5.1+b3
ii python-eyed30.6.18-1
ii python-mutagen 1.22-1
ii python-support 1.0.15
ii vorbis-tools1.4.0-1
jack recommends no packages.
jack 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#754069: gnat-gps-doc: invalid `Format' sections
Package: gnat-gps-doc Version: 5.3-1 Severity: minor When upgrading gnat-gps-doc: [...] Unpacking gnat-gps-doc (5.3-1) over (5.0-16) ... Processing triggers for mime-support (3.56) ... Processing triggers for desktop-file-utils (0.22-1) ... Processing triggers for gnome-menus (3.8.0-2) ... Processing triggers for menu (2.1.47) ... Processing triggers for man-db (2.6.7.1-1) ... Processing triggers for doc-base (0.10.5) ... Processing 3 changed doc-base files... Error in `/usr/share/doc-base/using-gnat-programming-studio', line 17: all `Format' sections are invalid. Error in `/usr/share/doc-base/gps-programmer-guide', line 16: all `Format' sections are invalid. Error in `/usr/share/doc-base/gnat-programming-studio-tutorial', line 17: all `Format' sections are invalid. Note: `install-docs --verbose --check file_name' may give more details about the above errors. Registering documents with scrollkeeper... Processing triggers for install-info (5.2.0.dfsg.1-4) ... [...] -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash gnat-gps-doc depends on no packages. Versions of packages gnat-gps-doc recommends: ii ada-reference-manual-2005 1:2012.2-3 ii gprbuild-doc 2013-1 gnat-gps-doc 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#754045: libedit2: Broken rl_callback_read_char() in libedit's readline emulation
On 07/07/2014 11:29, Federico Schwindt wrote: On the issue here, I know this but there were no reason to update the ABI number. Transition from a package name to the other is a huge work on a library like libedit. So, I won't rename libedit2 to libedit3. I'm not suggesting that but bumping the major or at least the minor. Before libedit2 was updated the code was from 2008, now it's from 2014; I think 6 years worth of changes justify this but I will open a new report. Why not reporting this bug upstream? Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754073: fetchmailconf: Fetchmail does not start -- libBLT.2.4.so.8.6
Package: fetchmailconf Version: 6.3.26-1 Severity: grave Justification: renders package unusable Dear Maintainer, when trying to start fetchmailconf, the following error is found: ~$ fetchmailconf Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/fetchmailconf.py, line 8, in module from Tkinter import * File /usr/lib/python2.7/lib-tk/Tkinter.py, line 42, in module raise ImportError, str(msg) + ', please install the python-tk package' ImportError: libBLT.2.4.so.8.6: cannot open shared object file: No such file or directory, please install the python-tk package Package python-tk is installed, and blt too. However the libBLT library present in the system is 2.5 instead of 2.4: ls: cannot access /usr/lib/libBLT.2.4.so.8.6: No such file or directory blt: /usr/lib/libBLT.2.5.so.8.6 If this bug should not be associated with fetchmailconf but with python-tk, please, change it accordingly (if possible), or I will re-open it there. Thank you very much in advance, Best Regards, Jonás. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.12-1-686-pae (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages fetchmailconf depends on: ii fetchmail 6.3.26-1 ii python 2.7.6-2 ii python-tk 2.7.7-2 fetchmailconf recommends no packages. fetchmailconf 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#729755: Sparkassen Kundenservice!!
Sehr geehrter Kunde, Bitte beachten Sie, dass Ihr Netbanking-Banking-Zugang bald abläuft. Um diesen Dienst weiterhin nutzen zu können, klicken Sie bitte auf den untenstehenden Link um Ihren Zugang manuell mit unserem Sicherheits-Update zu aktualisieren: klicken Sie hier Nach Vervollständigung dieses Schrittes werden Sie von einem Mitarbeiter unseres Kundendienstes zum Status Ihres Kontos kontaktiert. Beim Online-Banking haben Sie per Mausklick alles im Griff! Mit dem komfortablen Online-Banking Ihrer Sparkasse, haben Sie schnellen und problemlosen Zugang zu Ihrem Girokonto und erledigen Überweisungen und Daueraufträge bequem von zu Hause aus. Das Online -Banking bietet aber noch viele weitere Vorteile. DIE VORTEILE DES NET-BANKINGS AUF EINEN BLICK: - Kontozugang rund um die Uhr - SchnellerZugriff aufs Konto - Net-Banking bequem vom PC aus - Flexibel in jedem Winkel der Welt - Übersichtliche Kontoführung - Hohe Sicherheitsstandards - Net-Banking ist kombinierbar mit Telefon-Banking Um diese Dienste weiterhin problemlos nutzen zu können, führen Sie bitte das Update so schnell wie möglich durch. Mit freundlichen Grüßen, Sparkasse.de Sparkasse Kundendienst
Bug#754072: github-backup: support skipping certain repositories
Package: github-backup Version: 1.20131203+b1 Severity: wishlist It would be nice if there would be an option to skip certain repositories. It's useful if you don't want to download very large repositories or if a certain repository is known to cause problems. Thanks for github-backup! regards, -mika- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014-07-07t11-50...@devnull.michael-prokop.at
Bug#730600: [pkg-kolab] Bug#730600: [Kolab-devel] Bug#730600: Bug#730600: libkolab(xml): New upstream version available
Hi Jeroen,
On Fr 04 Jul 2014 02:35:50 CEST, Jeroen van Meeuwen (Kolab Systems) wrote:
On 2014-07-02 21:14, Mike Gabriel wrote:
On Mi 02 Jul 2014 14:09:10 CEST, Sune Vuorela wrote:
I want to ensure that neither of us gets to debug weird crashes if both
libraries are loaded into the same application.
@Sandro/Kolabsys: to me it feels as if Sune suggestions should be
implemented in libcalendaring (first there) by upstream and not by
some Debianic patch work. Do you see any chance that any coder at
kolabsys could get those namespace changes into libcalendaring?
Please note that libcalendaring's original purpose had been to
circumvent needing to provide a (near-)complete KDE stack = 4.9 to
older platforms such as RHEL 5, 6 and UCS (based on Squeeze).
As such, it has always been a very deliberate Frankenstein-baby and
we have the intention to burn it at the earliest opportunity.
If the Debian version you are seeking to package this for has KDE =
4.9 (not unlikely, I reckon), then technically you should have no
requirement for libcalendaring / to compile libkolab{,xml} against
libcalendaring.
That said, libcalendaring is the lighter weight version of what
libkolab needs from kdepimlibs. We are not experiencing the same
problems with ld / symbols on RPM-based systems where the
libcalendaring .so names are .0 and .0.1, while upstream's are .4
and .4.$x, and we're compiling libkolab{,-xml} against kdepimlibs.
We have two issues here:
1. installation of libkolab(xml) pulls in many packages from the KDE
desktop (tolerable, but awkward and prone to being a FUD target)
2. Last time I tested, half a plasma-desktop started up when accessing
my Kolab-prepped roundcube as user www-data
If 2. has been fixed (haven't got around to retest that with recent libkolab),
I guess we should attempt at living with 1.
Mike
--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
pgpTJtGfrAogK.pgp
Description: Digitale PGP-Signatur
Bug#750080: No .xmonad directory
Joachim Breitner nome...@debian.org writes: Dear Gonéri, can you provide the output of $ dpkg -l libghc-xmonad-dev ➜ ~ dpkg -l libghc-xmonad-dev Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=-===-===- ii libghc-xmonad-dev 0.11-8 amd64 Lightweight X11 window manager and $ ghc -v --make ~/.xmonad/xmonad.hs ➜ ~ ghc -v --make ~/.xmonad/xmonad.hs Glasgow Haskell Compiler, Version 7.6.3, stage 2 booted by GHC version 7.6.3 Using binary package database: /usr/lib/ghc/package.conf.d/package.cache Using binary package database: /home/goneri/.ghc/x86_64-linux-7.6.3/package.conf.d/package.cache package aeson-0.6.2.1-6178a38faa9735fae26b5e563fe82895 is unusable due to missing or recursive dependencies: dlist-0.5-6480552fbf191185cc86167748682e90 package authenticate-1.3.2.6-55b029ba74f9c51bff2e73bf8dcbd876 is unusable due to missing or recursive dependencies: aeson-0.6.2.1-6178a38faa9735fae26b5e563fe82895 http-conduit-2.0.0.3-be9eb463011a8f715fdf1a95f9864ba6 xml-conduit-1.1.0.9-ae1b1583f5928644306e44379fb505e9 package connection-0.1.3.1-c08026b56b19f2939da72172c28ecab1 is unusable due to missing or recursive dependencies: data-default-0.5.1-3dcf8b1e18d6ff182bcfe57129991c1d package cookie-0.4.0.1-fd1b8f6cf5b2294aeab4f3028702a98e is unusable due to missing or recursive dependencies: data-default-0.5.1-3dcf8b1e18d6ff182bcfe57129991c1d package http-client-0.2.0.3-b71d1c7f4acdd15439bb428c7978c961 is unusable due to missing or recursive dependencies: cookie-0.4.0.1-fd1b8f6cf5b2294aeab4f3028702a98e data-default-0.5.1-3dcf8b1e18d6ff182bcfe57129991c1d publicsuffixlist-0.1-b27f5dd856d7f4303d26fdc4a269c71c package http-client-conduit-0.2.0.1-33ac095f9751110692da1d80423b0668 is unusable due to missing or recursive dependencies: http-client-0.2.0.3-b71d1c7f4acdd15439bb428c7978c961 package http-client-tls-0.2.0.2-5364c695e59cebc66cfec7a23028de0e is unusable due to missing or recursive dependencies: connection-0.1.3.1-c08026b56b19f2939da72172c28ecab1 data-default-0.5.1-3dcf8b1e18d6ff182bcfe57129991c1d http-client-0.2.0.3-b71d1c7f4acdd15439bb428c7978c961 package http-conduit-2.0.0.3-be9eb463011a8f715fdf1a95f9864ba6 is unusable due to missing or recursive dependencies: http-client-0.2.0.3-b71d1c7f4acdd15439bb428c7978c961 http-client-conduit-0.2.0.1-33ac095f9751110692da1d80423b0668 http-client-tls-0.2.0.2-5364c695e59cebc66cfec7a23028de0e package markdown-0.1.7-bdd61f88bd38ebed07129ace03caf690 is unusable due to missing or recursive dependencies: data-default-0.5.1-3dcf8b1e18d6ff182bcfe57129991c1d package persistent-1.2.3.2-217121f9ec5395119dca535f37a5eb90 is unusable due to missing or recursive dependencies: aeson-0.6.2.1-6178a38faa9735fae26b5e563fe82895 package persistent-template-1.2.0.6-b4c5e3d33c25cf23dcfac27df2e39395 is unusable due to missing or recursive dependencies: aeson-0.6.2.1-6178a38faa9735fae26b5e563fe82895 persistent-1.2.3.2-217121f9ec5395119dca535f37a5eb90 package publicsuffixlist-0.1-b27f5dd856d7f4303d26fdc4a269c71c is unusable due to missing or recursive dependencies: data-default-0.5.1-3dcf8b1e18d6ff182bcfe57129991c1d package shakespeare-js-1.2.0.2-f7d0da24e0d1a67d7f3592a5cbefa923 is unusable due to missing or recursive dependencies: aeson-0.6.2.1-6178a38faa9735fae26b5e563fe82895 package wai-extra-2.0.1.1-585117381de6853749c59dde3b8d2076 is unusable due to missing or recursive dependencies: data-default-0.5.1-3dcf8b1e18d6ff182bcfe57129991c1d package xml-conduit-1.1.0.9-ae1b1583f5928644306e44379fb505e9 is unusable due to missing or recursive dependencies: data-default-0.5.1-3dcf8b1e18d6ff182bcfe57129991c1d package xmonad-0.11-a9ac62e182dbb0265cc10fb7343d9243 is unusable due to missing or recursive dependencies: X11-1.6.1.1-5abef677169538672254ee7c61191482 package xmonad-0.11-bd2b015bf0a8552a6b6b68a4e4e1d54f is shadowed by package xmonad-0.11-a9ac62e182dbb0265cc10fb7343d9243 package xmonad-contrib-0.11.2-dc0f19c6cf8c0f5382a3231bc871f978 is unusable due to missing or recursive dependencies: X11-1.6.1.1-5abef677169538672254ee7c61191482 X11-xft-0.3.1-3c10be71b4aefcf2267c0d2039f4a07d xmonad-0.11-a9ac62e182dbb0265cc10fb7343d9243 package xmonad-contrib-0.11.3-f30c687e67b4390cc1abca0dcf9a2be5 is unusable due to missing or recursive dependencies: xmonad-0.11-bd2b015bf0a8552a6b6b68a4e4e1d54f package yaml-0.8.5.2-f27ac4880de1184b357ad1a43343ae8e is unusable due to missing or recursive dependencies: aeson-0.6.2.1-6178a38faa9735fae26b5e563fe82895 package yesod-1.2.4-68d7b3c9aec0ee7925ed8acbfe568448 is
Bug#754070: include urgency in DSAs
package: security.debian.org severity: wishlist Hi, assuming not all DSAs are of urgency=high, I think it would be nice to include the urgency in the DSA text directly, so one can learn about the urgency before applying these updates. Does this seem like a reasonable idea? Background: support contracts which allow immediate deployment of urgent + critical updates. With those it's very useful to know the urgency easily+early. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#750080: User directories
.xmonad is empty .ghc doesn't exist .cabal doesn't exist either xmonad still tries to compile the non-existant xmonad.hs file
Bug#753954: [deejayd] Some sources are not included in your package
On Mon, Jul 7, 2014 at 12:39 PM, Alexandre Rossi alexandre.ro...@gmail.com wrote: tag 753954 pending thanks Hi, Your package seems to include some files that lack sources in prefered forms of modification: data/htdocs/js/lib/jquery.js Fixed package is awaiting sponsorship. http://mentors.debian.net/debian/pool/main/d/deejayd/deejayd_0.10.0-7.dsc I added debian/patches/jssouce which adds data/htdocs/js/lib/jquery.src.js alongside data/htdocs/js/lib/jquery.js . However lintian is not happy with this, source-is-missing is still triggered, but at least this bug is fixed. Please advice as to report this as a lintian bug. No it is perfect but you could add it under debian/missing-source . Lintian found it automatically Bastien Thanks for reporting, Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752384: HEAnet sourceforge mirror is outdated
Hi Paul, I just hit this same problem with one of my packages that ifs hosted on SF.net and the HEAnet mirror doesn't hold the latest source. I don't know whether this has been found/investigated before but the appears to be an RSS feed for each project containing the file downloads. So for my package VPCS, the RSS feed is at: https://sourceforge.net/projects/vpcs/rss It would seem this is a viable alternative as the links provided map to the SF mirror selector, so should always return a mirror with the correct files present. Regards Daniel Lintott signature.asc Description: OpenPGP digital signature
Bug#726706: Please package fpack and funpack
I wish to second the request to package CFITSIO's fpack and funpack utilities and can contribute man pages. Copies may be found at https://ttt.astro.su.se/~gelato/fpack.1.gz https://ttt.astro.su.se/~gelato/funpack.1.gz These man pages are based on the documentation provided in PDF format with the upstream sources; I cannot take full credit for their wording. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753110: RFS: mrrescue/1.02c-1 ITP
Tobias Frost writes: Hi Steven, Please note, I can only review, but I cannot sponsor as my NM process is not yet finished... On Sun, 2014-06-29 at 20:30 +1000, Steven Hamilton wrote: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package mrrescue * Package name: mrrescue Version : 1.02c-1 Upstream Author : [fill in name and email of upstream] * URL : http://www.tangramgames.com It should be http://tangramgames.dk/games/mrrescue/, shouldn't it? Yes, It's correct in the control file * License : zlib, MIT, BY-SA 3.0 Section : games It builds those binary packages: mrrescue - Mr Rescue is an arcade 2d action game To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mrrescue Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mrrescue/mrrescue_1.02c-1.dsc More information about hello can be obtained from http://www.example.com. - d/copyright: * Please adapt to the machine-readable format; You're already close, but at least some headers are missing: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ * License texts are missing * Filenames are wrong: There is no mrresuce.love directory in the source. * Also, please also use the same spelling for the licenses: ZLIB/zlib (Sugessted is to use the abbreviations as in http://spdx.org/licenses/) * s/BY-SA 3.0/CC-BY-SA-3.0 All fixed up. A license texts included. * d/docs README.txt ist not required to be installed, the information within are not needed on a Debian system Removed * d/mrrescue Is there are resson to use /bin/bash as shebang and not use /bin/sh? (then you would also need to depend on bash; but its not necessary to have bash, right?) Changed to /bin/sh * d/mrrsecue.1 It's great that you provide a manpage. IMHO writing manpages is one of the most tedious work to be done during packaging ... You should also forward it upstream, (when its ready :) However, I think it need a little overhaul. Please read man-pages(7) and man(7) - Shouldn't it be section 6, games? - in the NAME Section, should'nt be MRRESCUE in lowercase? - Synopsis should be mrrescue - Section Desctiption: The sentence This manual coveres ... is uncessary. Maybe the text you use for d/control would be more appropiate for an description? - mrrescue doesn't take options, right? All fixed up. Moved to section 6. * d/rules: I think you don't need to rm build_dir I think I do. The build process creates a mrrescue.love file which is basically a zipped file of all the source (this is how love works). Without the rm build_dir dh_clean won't clean up properly. * there are two pendantic lintian messages. What to do with this strongly depends on the sponsor, however I would override it as an sign that I've checked them (and maybe nag upstream to add an changelog and signature to their tarballs) Override added for no upstream changelog. So I would say the package is almost ready... Thanks for your contribution :) And thanks for the review. Updated package it now uploaded to mentors. -- Steven Hamilton I don't look like two zombies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753939: Please remove quotacheck and quotaon service files
Am 07.07.2014 11:20, schrieb Michael Meskes: On Mon, Jul 07, 2014 at 03:00:47AM +0200, Michael Biebl wrote: Wouldn't be a better idea to simply get the additional functionality the Debian quota scripts provide moved into the quotaon and quotacheck binaries upstream? I don't think so, for a couple reasons: - quota functionality should be in the quota package IMO I was talking about the quotaon and quotacheck *binaries*, which are part of the quota package. - quota init scripts will be part of the quota package for other init systems, so we would get an awful mix if we'd move this to systemd moving that functionality out of the init scripts and into the binaries but still keeping the sysv init scripts for non-systemd systems wouldn't create a mess. Actually, it would make the sysv init scripts much simpler - some of the additional functionality might not make much sense for a brand new system, not sure if systemd upstream would be interested in that I didn't mean systemd upstream here, but quota upstream. If it is useful functionality, I would at least try to get it upstream. Cheers, Michael -- 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#753303: avconv: in best video stream selection, please break resolution ties by bitrate
Control: -1 tags upstream Control: -1 forwarded https://bugzilla.libav.org/show_bug.cgi?id=714 On Mon, Jun 30, 2014 at 7:08 AM, Lionel Elie Mamane lio...@mamane.lu wrote: Package: libav-tools Version: 6:10.1-1 Severity: normal Hi, I have forwarded this upstream bug on your behalf. I would like to strongly suggest to create an account in the upstream bugzilla and add yourself to the CC list so that you receive follow-up questions immediately. Thanks, Reinhard -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750080: [Pkg-haskell-maintainers] Bug#750080: User directories
Control: reopen 750080 Am Montag, den 07.07.2014, 12:58 +0200 schrieb Jörg Plate: .xmonad is empty .ghc doesn't exist .cabal doesn't exist either xmonad still tries to compile the non-existant xmonad.hs file ah, right, Gonéri’s report was not the original one, and there still is an open issue here. Reopening the bug. Does it make a difference whether ~/.xmonad/ is present, but empty, or not present? Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#751503: fribidi: Parameter declarations of function fribidi_get_bidi_type differ in signedness
Hi, This build failed on which arch. ? This is on an amd64 system. In both files I see the declaration is the same: FRIBIDI_ENTRY FriBidiCharType fribidi_get_bidi_type ( FriBidiChar ch /* input character */ ) FRIBIDI_GNUC_CONST; FriBidiChar is defined in lib/fribidi-types.h: typedef FRIBIDI_UNICHAR FriBidiChar; in the same header file, FRIBIDI_UNICHAR is defined as follows: #ifndef FRIBIDI_UNICHAR # define FRIBIDI_UNICHAR FRIBIDI_UNICHAR_LOCAL #endif /* !FRIBIDI_UNICHAR */ FRIBIDI_UNICHAR_LOCAL is also defined in lib/fribidi-types.h (a 59 lines piece of code) Well, there are actually three possible definitions here (lines 52, 95, 98): http://sources.debian.net/src/fribidi/0.19.5-2/lib/fribidi-types.h?hl=52,95,98#L52 I will, however, investigate further to check which of the preprocessor macros kicks in. I will get back to you once this is done. Best, Michael pgpn9oSMPinf6.pgp Description: PGP signature
Bug#754077: fprintd: Can only register right index finger
Package: fprintd Version: 0.4.1-5-g73edad0-3 Severity: normal Dear Maintainer, fprintd-enroll refuses take the -f option into account, so only the right index finger can be scanned. Example run: $ fprintd-enroll -f right-middle-finger Using device /net/reactivated/Fprint/Device/0 Enrolling right index finger. The man page seems also inconsistent, as it does not list the -f argument in the SYNOPSYS section for fprintd-enrool, but it specifically mentions fprintd-enroll at the description of the -f argument. There may be a fix for this upstream, I think this is a pretty serious issue, if you really want to use fprintd for authentication, so in case of an upstream fix, a backport seems a viable option. -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-0.bpo.1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages fprintd depends on: ii dbus 1.6.8-1+deb7u3 ii libc6 2.13-38+deb7u1 ii libdbus-1-31.6.8-1+deb7u3 ii libdbus-glib-1-2 0.100.2-1 ii libfprint0 1:0.4.0-4-gdfff16f-4 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libpolkit-gobject-1-0 0.105-3 ii policykit-10.105-3 fprintd recommends no packages. fprintd 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#754078: crypt devices not brought online (backed by iscsi)
Package: systemd Version: 204-14 Severity: normal Hi, as discussed on IRC, systemd fails to bring up my iscsi-backed crypt devices. Before systemd-sysv hit testing and was installed, they worked. Also, it seems to spend an awful lot of time bringing them online (significantly longer than a minute or so). I booted with systemd.log_level=debug, and put the contents of /var/log/debug.log up at https://www.palfrader.org/volatile/2014-07-07-8CnmVmaPpZA/var-log-debug } weasel@valiant:~$ cat /etc/crypttab } sda3_crypt UUID=81402c7d-3819-4860-b71f-ff0f808f599e none luks } sda6_crypt UUID=4385f6be-9584-4fd9-a3b8-92a2826311a5 /etc/luks/sda6.key luks } } aux1 /dev/disk/by-path/ip-172.22.118.11\:3260-iscsi-iqn.1992-04.com.emc\:storage.storcenter.sbg.palfrader.org.aux1-lun-0 /etc/luks/aux1.key luks,noearly } mailbak /dev/disk/by-path/ip-172.22.118.11\:3260-iscsi-iqn.1992-04.com.emc\:storage.storcenter.sbg.palfrader.org.mailbak-lun-0 /etc/luks/mailbak.key luks,noearly sda* are online, aux1 and mailback are not. Their backing devices exist: ] lrwxrwxrwx 1 root root 9 Jul 7 13:11 /dev/disk/by-path/ip-172.22.118.11:3260-iscsi-iqn.1992-04.com.emc:storage.storcenter.sbg.palfrader.org.aux1-lun-0 - ../../sdi ] lrwxrwxrwx 1 root root 9 Jul 7 13:11 /dev/disk/by-path/ip-172.22.118.11:3260-iscsi-iqn.1992-04.com.emc:storage.storcenter.sbg.palfrader.org.mailbak-lun-0 - ../../sdh fstab does not reference aux1 and mailbak - they get included using autofs. Cheers, weasel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731340: lintian: [new check] Check if debian/upstream files are valid YAML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am 2014-07-05 11:03, schrieb Niels Thykier: On 2013-12-04 14:04, Simon Kainz wrote: Package: lintian Version: 2.5.10.4 Severity: wishlist Tags: patch After processing some debian/upstream whic hcontained broken/invalid YAML data, i created the following check together with ti...@debian.org: if debian/upstream is not avail - pedantic warning Invalid YAML - normal warning YAML with invalid field - normal warning Please see my attached file. Would be nice if this could be integrated into lintian. [...] Hi Simon, Thanks for taking the time to write a patch and sorry for the long delay in getting back to you. We already commented on your patch a while ago, but unfortunately, you were never added to the recipient list of those mails ... Our primary concern with your patch is that it relies on Test::YAML and Test::More, which are modules only used for testing code (e.g. build time tests). Beyond that, there are two additional improvements worth considering: * Adding a test case for your new checks / tags * Moving the (contents of) @allowed_fields into a data file. ~Niels Hi Nils, Thanks for your reply! I'll try to get rid of the Test::* dependencies. Test cases should be no problem, i'll dig my way though lintian source to copy/paste/learn from some bits. Concerning moving allowed_fields data into a data file: Is there some kind of infrastructure/guideline for this? I saw /usr/share/lintian/data and though about putting the allowd_fields data in there. Is the the right way? Regards, Simon - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTuoFMAAoJEBy08PeN7K/p4GIP/1wCsq3aALCH1TtbvWZiFP3O LTJfqyEcn43dFZFr73oJXzhbbIuf14pTNnVl8C5V73mVnPTC2vNdCmb3L7GrcmV0 1fUc3q5l6NbZtvFL9CKmWAoXyrIwmTTTAdm5Ol91JkT+6crjIc8Evp6rwUnUi4Ph TEruBgT2vCXaG4vRDfPrjEWDwp4X0xhebvmx7Q+D4SNYaJbKRPPBr1AvRTsqbJHu xFSU54qZBRijcyT6sHIt9xS97QN2PcOu39MI97bWutaqbJIG7OlR/WfqpATSjvMm vxATx2TfHzUGA/Dky9FsT7la3//tR2gEIORs09kcFtDDMi8Yn9AyC6d3hiJmIUSL 6O5vo7nuQzAkWapItZY0MIZrzWWL7tAT9b7wHEKAP2keplxfA2mI0hJh/KmsTyKh CXnFu+boje+2elkD+31SKnSeMF6QnxTMmMb9j8iHwHHl9a4Goq03ZSsqlfoZ1FcJ Am6Fes8JQOKsytBUmVlOigOd6qc3stgrcfWN4DkvnWnPkz2fUyydjcKN/m8G8pOd XPiPHGWNwlEOZm/Tjd9PWeSStvUTJDWJS8rdEV1E5RZWAbFluzhne0EVUjGBrslR RuvJhC34+Lep6dLAj3uqxsRkcOaH8tyUIkOwrapTNfCLvdUvoD1/jUgAFrjq6629 qlJLmEW7wQPLbGUEhFAZ =Mck9 -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#752384: HEAnet sourceforge mirror is outdated
On Mon, 2014-07-07 at 12:15 +0100, Daniel Lintott wrote: I don't know whether this has been found/investigated before but the appears to be an RSS feed for each project containing the file downloads. So for my package VPCS, the RSS feed is at: https://sourceforge.net/projects/vpcs/rss Thanks, I wasn't aware of that. It would seem this is a viable alternative as the links provided map to the SF mirror selector, so should always return a mirror with the correct files present. That isn't quite what we need for uscan but could be a good start, we would still need to process the RSS into HTML though. I have been in contact with the SourceForge people and they are in the evaluation process of creating a permanent fix for us: http://sourceforge.net/p/forge/site-support/8064/ -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#754070: include urgency in DSAs
Hi Holger, On Mon, Jul 07, 2014 at 11:32:40AM +0200, Holger Levsen wrote: assuming not all DSAs are of urgency=high, I think it would be nice to include the urgency in the DSA text directly, so one can learn about the urgency before applying these updates. Does this seem like a reasonable idea? Background: support contracts which allow immediate deployment of urgent + critical updates. With those it's very useful to know the urgency easily+early. Do you mean the urgency=high in debian/changelog? Historically urgency=high should always be set in debian/changelog for security-uploads[1], and there should be no DSA with urgency not high (I know this is not the case). This had previously probably also some technical background on archive/buildd side, but has no real meaning for the update itself. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security 5.8.5.4. Preparing packages to address security issues Regards, Salvatore -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751888: [Gluster-devel] Bug#751888: glusterfs-server: creating symlinks generates errors
thanks :) Am 02.07.2014 17:01, schrieb Thomas Goirand: Hi, I'm uploading a bugfix version in Debian with the patch available from here: http://review.gluster.org/#/c/8153/ I would usually do this kind of NMU using the delayed queue, but since Patrick Matthäi wrote he's on vacation, I don't see the point in delaying more. My upload is by the way very minimalistic, and only including the upstream patch. I wont send a debdiff, since that's really only the stripe.c patch added to the package (I'm not adding the new tests, I'll leave this work/decision to the maintainers of glusterfs). I hope this helps. Cheers, Thomas Goirand (zigo) -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer Blog: http://www.linux-dev.org/ E-Mail: pmatth...@debian.org patr...@linux-dev.org */ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753925: mps-youtube: no longer plays media streams after the latest mpv update
Hi Zlatan, i just noticed i was passing the --name parameter to mpv via mpsyt playerargs option, which i needed to position the window in my window manager. But according to [1], the --name parameter has been replaced by --x11-name in the latest 0.4.0 release, and indeed this change was breaking the whole thing. I should have checked it earlier, but i didn't rememer i configured it that way. So... this bug is not a bug, and mps-youtube is now working as expected :) Thanks anyways for your time. Keep up the good work! ;) [1] https://github.com/mpv-player/mpv/releases -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753362: libjpeg6b: build with dh-autoreconf
On 07/05/2014 01:36 PM, Bill Allombert wrote: On Tue, Jul 01, 2014 at 02:52:41PM -0300, Mauricio Faria de Oliveira wrote: [...] That's certainly understandable. Nonetheless, I'd think the problem is not tied to future versions only, but old ones too; 1.11.x seems old already (2009/2012). Anything = 1.11.2 would fail for de-ANSI-fication. It establishes that automake developers are willing to break the API in minor releases. This is a very bad sign. Yes. I think that change is a bit weird for minor releases too. [...] 3) libjpeg6 releases finished [...] 3) is wrong :) Thanks for correcting me :) I admit I may have not read enough about it, just some skimming over ijg.org and libjpeg.sf.net. But anyway, I have applied your patch since it is the best fix all-round. Thanks again for your effort, Glad to contribute. The package now builds properly on ppc64el: Package: libjpeg62 Source: libjpeg6b Version: 6b2-1 [..] -rw-r--r-- root/root170072 2014-07-05 22:09 ./usr/lib/powerpc64le-linux-gnu/libjpeg.so.62.0.0 Thank you. -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750517: paramiko: diff for NMU version 1.14.0-2.1
Hi Jeremy, On Mon, Jul 07, 2014 at 06:45:34AM -0400, Jeremy T. Bouse wrote: On 07/07/2014 04:56 AM, Jelmer Vernooij wrote: tags 750517 + pending thanks Dear maintainer, I've prepared an NMU for paramiko (versioned as 1.14.0-2.1) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. I would ask you to remove this NMU upload as it is premature and breaks other issues apparently. You had the good sense to submit a pull request against the Paramiko upstream for this but your code fails to run the Travis CI tests and has not been accepted by upstream author. https://github.com/paramiko/paramiko/pull/352 https://travis-ci.org/paramiko/paramiko/builds/29220401 The test I added breaks on Python3, so I'll need to add a change to skip it on Python 3 (since it doesn't have buffer). I don't see what is wrong with the fix itself. The paramiko Debian package also builds fine with this change, and it runs the testsuite (though presumably only part of the testsuite or only on python 2?). Subsequent to that, I use GitHub myself to allow for pull requests and you would have known that had you contacted me prior to uploading a NMU. I had already acknowledged your bug report and was monitoring the upstream activity on it. Again you would have known that had you read my reply to the bug report or again contacted me. You and I have already done this dance before. I submitted this patch to the bug report as well. It seems odd to me that a proprietary system like GitHub is the primary place for submitting changes to a Debian package. I'll cancel the delayed NMU per your request. This issue will be fixed but I will not have it done by breaking other issues. This is a very poor and rushed NMU. There are no other issues it introduces in the Debian package. This is causing a FTBFS for bzr, which will cause it to be removed from unstable in two weeks so I'm keen to get it fixed soon. Cheers, Jelmer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753939: Please remove quotacheck and quotaon service files
On Mon, Jul 07, 2014 at 01:04:49PM +0200, Michael Biebl wrote: - quota functionality should be in the quota package IMO I was talking about the quotaon and quotacheck *binaries*, which are part of the quota package. Ah, I thought you were talking about the two binaries as provided by the systemd package. - some of the additional functionality might not make much sense for a brand new system, not sure if systemd upstream would be interested in that I didn't mean systemd upstream here, but quota upstream. If it is useful functionality, I would at least try to get it upstream. It is, but it simply does not belong into these binaries. For instance out init script checks which FS it should run quotacheck on for a normal check but also for creating quota files. This could be another binary, but certainly does not belong into either one of these binaries. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754079: nmu: lightspark_0.7.2-3.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu lightspark_0.7.2-3.1 . ALL . -m Rebuild against the new version llvm-defaults (llvm 3.4) Thanks Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
