Bug#804521: Undefined Behavior in libstdc++ with GCC 5.2.1 in ios_base.h
Package: libstdc++6
Version: 5.2.1-20
Severity: normal
Control: tags jessie sid
**
On Linux, the distros often use libstdc++ (GNU) rather than libc++
(LLVM) for Clang. Building libcxx is an art that I have never been
able to untangle, and I think the maintainers have discovered the same
(libc++ was not installed with Clang).
Below, I'm catching a UB finding when using Clang and libstdc++ (GNU).
This one has been around for some time. I first encountered it on
Apple platforms. I regularly encounter it on Debian and Ubuntu.
The fix is fairly easy, and I usually just do it: a couple of casts
among unsigned and the flags. Also see
http://lists.llvm.org/pipermail/cfe-dev/2015-January/040753.html.
**
$ cat ub.cxx
#include
int main(int argc, char* argv[])
{
std::cout << std::hex << argc << std::endl;
std::cout << std::dec << argc << std::endl;
return 0;
}
$ clang++ -fsanitize=undefined ub.cxx -o ub.exe
$ ./ub.exe
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/bits/ios_base.h:102:24:
runtime error: load of value 4294967221, which is not a valid value
for type 'std::_Ios_Fmtflags'
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/bits/ios_base.h:82:67:
runtime error: load of value 4294967221, which is not a valid value
for type 'std::_Ios_Fmtflags'
1
1
**
$ g++ --version
g++ (Debian 5.2.1-20) 5.2.1 20151002
Copyright (C) 2015 Free Software Foundation, Inc.
$ uname -a
Linux debian-8-x64 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5
(2015-10-09) x86_64 GNU/Linux
$ lsb_release
No LSB modules are available.
**
$ apt-cache show libstdc++
Package: libstdc++6
Status: install ok installed
Priority: important
Section: libs
Installed-Size: 1959
Maintainer: Debian GCC Maintainers
Architecture: amd64
Multi-Arch: same
Source: gcc-5
Version: 5.2.1-20
Replaces: libstdc++6-5-dbg (<< 4.9.0-3)
Depends: gcc-5-base (= 5.2.1-20), libc6 (>= 2.18), libgcc1 (>= 1:4.1.1)
Breaks: blockattack (<= 1.4.1+ds1-2.1+b2), boo (<=
0.9.5~git20110729.r1.202a430-2), c++-annotations (<= 10.2.0-1),
clustalx (<= 2.1+lgpl-3), dff (<= 1.3.0+dfsg.1-4.1+b3),
digikam-private-libs (<= 4:4.4.0-1.1+b2), emscripten (<= 1.22.1-1),
ergo (<= 3.4.0-1), fceux (<= 2.2.2+dfsg0-1), fiona (<= 1.5.1-2), flush
(<= 0.9.12-3.1), freeorion (<= 0.4.4+git20150327-2), fslview (<=
4.0.1-4), fwbuilder (<= 5.1.0-4), gcc-4.3 (<< 4.3.6-1), gcc-4.4 (<<
4.4.6-4), gcc-4.5 (<< 4.5.3-2), gnote (<= 3.16.2-1), gnudatalanguage
(<= 0.9.5-2+b2), innoextract (<= 1.4-1+b1), libantlr-dev (<=
2.7.7+dfsg-6), libapache2-mod-passenger (<= 5.0.7-1), libaqsis1 (<=
1.8.2-1), libassimp3 (<= 3.0~dfsg-4), libboost-date-time1.54.0,
libboost-date-time1.55.0, libchemps2-1 (<= 1.5-1), libcpprest2.4 (<=
2.4.0-2), libdap17 (<= 3.14.0-2), libdapclient6 (<= 3.14.0-2),
libdapserver7 (<= 3.14.0-2), libdavix0 (<= 0.4.0-1+b1), libdballe6 (<=
6.8-1), libdiet-admin2.8 (<= 2.8.0-1+b3), libdiet-client2.8 (<=
2.8.0-1+b3), libdiet-sed2.8 (<= 2.8.0-1+b3), libfreefem++ (<=
3.37.1-1), libgazebo5 (<= 5.0.1+dfsg-2.1), libgetfem4++ (<=
4.2.1~beta1~svn4635~dfsg-3+b1), libgmsh2 (<= 2.9.3+dfsg1-1),
libinsighttoolkit4.7 (<= 4.7.2-2), libkolabxml1 (<= 1.1.0-3),
libmarisa0 (<= 0.2.4-8), libogre-1.8.0 (<= 1.8.0+dfsg1-7+b1),
libogre-1.9.0 (<= 1.9.0+dfsg1-4), libopenwalnut1 (<=
1.4.0~rc1+hg3a3147463ee2-1+b1), libpqxx-4.0 (<= 4.0.1+dfsg-3),
libreoffice-core (<= 1:4.4.5-2), librime1 (<= 1.2+dfsg-2),
libwibble-dev (<= 1.1-1), libwreport2 (<= 2.14-1), libxmltooling6 (<=
1.5.3-2.1), lightspark (<= 0.7.2+git20150512-2+b1), mira-assembler (<=
4.9.5-1), mongodb (<= 1:2.4.14-2), mongodb-server (<= 1:2.4.14-2),
ncbi-blast+ (<= 2.2.30-4), openscad (<= 2014.03+dfsg-1+b1),
passepartout (<= 0.7.1-1.1), pdf2djvu (<= 0.7.21-2), photoprint (<=
0.4.2~pre2-2.3+b2), plastimatch (<= 1.6.2+dfsg-1), plee-the-bear (<=
0.6.0-3.1), povray (<= 1:3.7.0.0-8), powertop (<= 2.6.1-1),
printer-driver-brlaser (<= 3-3), psi4 (<= 4.0~beta5+dfsg-2+b1),
python-fiona (<= 1.5.1-2), python-guiqwt (<= 2.3.1-1), python-healpy
(<= 1.8.1-1+b1), python-htseq (<= 0.5.4p3-2), python-imposm (<=
2.5.0-3+b2), python-pysph (<= 0~20150606.gitfa26de9-5),
python-rasterio (<= 0.24.0-1), python-scipy (<= 0.14.1-1), python-sfml
(<= 2.2~git20150611.196c88+dfsg-1+b1), python3-fiona (<= 1.5.1-2),
python3-scipy (<= 0.14.1-1), python3-sfml (<=
2.2~git20150611.196c88+dfsg-1+b1), python3-taglib (<=
0.3.6+dfsg-2+b2), realtimebattle (<= 1.0.8-14), ruby-passenger (<=
5.0.7-1), schroot (<= 1.6.10-1+b1), sqlitebrowser (<= 3.5.1-3),
tecnoballz (<= 0.93.1-6), wesnoth-1.12-core (<= 1:1.12.4-1), widelands
(<= 1:18-3+b1), xflr5 (<= 6.09.06-2)
Conflicts: scim (<< 1.4.2-1)
Description-en: GNU Standard C++ Library v3
This package contains an additional runtime library for C++ programs
built with the GNU compiler.
.
libstdc++-v3 is a complete rewrite from the previous libstdc++-v2, which
was included up to g++-2.95. The first version of libstdc++-v3 appeared
in g++-3.0.
Description-md5: 724ab84919e0e220af
Bug#782641: initramfs-tools: nfs booting requires /usr to be present on the nfs root filesystem
Control: tags -1 + patch
Hi,
On Fri, Nov 06, 2015 at 01:27:58PM +0100, Salvatore Bonaccorso wrote:
> Hi,
>
> On Wed, Apr 15, 2015 at 03:01:44PM +0100, fc3452-00 wrote:
> > Package: initramfs-tools
> > Version: 0.120
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > Problem occurs when attempting to do an nfs network boot with no /usr
> > directory
> > present on the nfs root partition.
> >
> > At https://www.debian.org/releases/jessie/i386/apcs02.html.en it says that
> > /etc, /bin, /sbin, /lib & /dev must be present on the root partition in
> > order
> > to boot.
> >
> > But in the script /usr/share/initramfs-tools/scripts/nfs there is:
> >
> > # loop until nfsmount succeeds
> > nfs_mount_root_impl
> > nfs_retry_count=0
> > while [ ${nfs_retry_count} -lt ${delay} ] \
> > && ! chroot "${rootmnt}" test -x "${init}" ; do
> > [ "$quiet" != "y" ] && log_begin_msg "Retrying nfs mount"
> > /bin/sleep 1
> > nfs_mount_root_impl
> > nfs_retry_count=$(( ${nfs_retry_count} + 1 ))
> > [ "$quiet" != "y" ] && log_end_msg
> > done
> >
> > which attempts to execute /usr/bin/test immediately after mounting the root
> > partition and before mounting any of the filesystems in /etc/fstab. This
> > fails
> > if your are trying to mount /usr from another filesystem by using an entry
> > in
> > /etc/fstab. The script could be modified to use the shell built-in "test"
> > command by changing the line
> >
> > && ! chroot "${rootmnt}" test -x "${init}" ; do
> >
> > to
> >
> > && ! chroot "${rootmnt}" sh -c "[ -x \"${init}\" ]" ; do
> >
> > which enables the system to boot when /usr is not present.
>
> Untested: One other option might be to move the validate_init()
> wrapper from init to scripts/functions and use that from there as well
> in scripts/nfs.
After thinking a bit more on it, maybe doing the file check to test if
the rootfs mount was successful could be better replaced by a return
value check. The init is validated aftwards.
Attached is proposed patch for #782641 . Does it looks good to go
ahead?
Regards,
Salvatore
From be2122fb1368697870ded2b2495c1265086e5ddd Mon Sep 17 00:00:00 2001
From: Salvatore Bonaccorso
Date: Fri, 6 Nov 2015 14:12:44 +0100
Subject: [PATCH] scripts/nfs: Check return value from nfs_mount_root_impl
Check if mount of rootfs was successful. This avoids doing a file test
within the mount.
Closes: #782641
---
scripts/nfs | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/scripts/nfs b/scripts/nfs
index 1c29850..359bd46 100644
--- a/scripts/nfs
+++ b/scripts/nfs
@@ -90,12 +90,14 @@ nfs_mount_root()
# loop until nfsmount succeeds
nfs_mount_root_impl
+ ret=$?
nfs_retry_count=0
while [ ${nfs_retry_count} -lt ${delay} ] \
- && ! chroot "${rootmnt}" test -x "${init}" ; do
+ && [ $ret -ne 0 ] ; do
[ "$quiet" != "y" ] && log_begin_msg "Retrying nfs mount"
/bin/sleep 1
nfs_mount_root_impl
+ ret=$?
nfs_retry_count=$(( ${nfs_retry_count} + 1 ))
[ "$quiet" != "y" ] && log_end_msg
done
--
2.6.2
signature.asc
Description: PGP signature
Bug#804522: jenkins: Unauthenticated remote code execution 0-day in Jenkins CLI
Package: jenkins Severity: grave Tags: security Justification: user security hole Hi, please see https://jenkins-ci.org/content/mitigating-unauthenticated-remote-code-execution-0-day-jenkins-cli Cheers, Moritz
Bug#804315: [Vmdebootstrap-devel] Namespace issues
On Mon, Nov 9, 2015 at 12:45 AM, Iain R. Learmonth wrote: > Hi, > > It is worth noting that live-build is not a Debian project, it is an > external project that claims to be an official Debian project. This is > something that needs to be fixed. > > There is no namespace issue, we are building on the existing live-config and > live-boot packages that are maintained and bringing these into Debian as > native projects. If necessary, these will be forks, but I'm hoping that > won't have to happen and that we can integrate these packages into Debian > and continue development in a collaborative manner. > > live-build has been deprecated by debian-cd, and live-build-ng is > replacing it. In a purely Debian context at least, live-build is deprecated. > live-build-ng is being developed in collaboration with debian-cd and D-I. > > I'm aware that I'm going to be upsetting people, but this has been a long > time coming and I'm not going to spend time bikeshedding over naming. I > would rather spend that time on integration of live image creation into > official Debian infrastructure and building the best system for live image > creation possible. > Hi, Reading what you say, and I beg your pardon before going on, I can tell that you absolutely have no idea about what the debian live project is or about its history. But well, I have to admit that if what you say is true, then you have a point. You say "I'm aware that I'm going to be upsetting people, but this has been a long time coming" Yes you are absolutely right, you are upsetting people, people like me who have contributed to debian for years and spent hours of effort to make things better. "A long time coming"? Excuse me, but the first thing I've ever heard in all these years is that you and I mean you (not the debian cd team, who supposedly is responsible for this upheaval) shows up from out of the blue claiming that you have the right to do as you please and decide about the future of the debian live team. This is, from my point of view, an act of dictatorship and with my authority as a debian user and contributor for years I demand you step down from your position and ask for forgiveness to the debian live team for being so rude, impolite and not worthy of any more of my priceless words and time. Sorry for being so rude and impolite but you can only fight fire with fire. > Consider this thread marked as wontfix. > Consider the same from my point of view. -- chals www.chalsattack.com ch...@chalsattack.com
Bug#804315: [Vmdebootstrap-devel] Namespace issues
On Sat, Nov 7, 2015 at 1:32 PM, Daniel Baumann wrote: > > but given the situation, i understand that argueing about this hijack is > futile then. > > it would have been more honest to actually talk to us (we're doing this > since almost 10 years now), and take over live-* packages directly, > rathern than to uploading -ng versions of them. > > So long and thanks for all the fish, > Daniel > I agree with Daniel, it is not worth arguing with dictators. So I won't. I would only like to say that I have been actively contributing to the debian live project since January, 2011 pushing hundreds, if not thousands, of commits. And I, hereby, publicly declare that I refuse to contribute anymore with all this people who are trying to take over everything we've been working for and take advantage of our efforts. Down with dictators!!! Daniel and all the other people contributing to the debian live project have all my support and commitment for whatever action you want to take. But as Daniel seemed to imply there is no use fighting a lost battle. dixit -- chals www.chalsattack.com ch...@chalsattack.com
Bug#801749: gdm3: Does not start anymore
Hi, Just to complement my previous message: - all of the local users were in the 'video' group for long, - using lightdm works with no problem; I can even use the xfswitch-plugin applet overriding gdmflexiserver as indicated in the Ubuntu documentation (https://wiki.ubuntuusers.de/Xfce_Panel_Plugins for example). HTH, phep
Bug#804503: [Pkg-sysvinit-devel] Bug#804503: startpar: Please add Multi-Arch: foreign
[Elrond] > Hi, > > startpar AFAIK offers an architecture independent (process level) > interface to its users. Would you mind setting it to Multi-Arch: > foreign? Not at all. Do you have time to provide a tested patch? -- Happy hacking Petter Reinholdtsen
Bug#799369: swift update for jessie
On 11/06/2015 03:17 PM, Moritz Muehlenhoff wrote: > Hi, > could you prepare a jessie update for CVE-2015-5223 ? > http://www.openwall.com/lists/oss-security/2015/08/26/5 > > Cheers, > Moritz Hi Moritz, Thanks for taking care of it. This patch has been prepared a long time ago. I've been waiting for the release team's approval since the 18th of September. This is more than a month and a half. I'm by the way disappointed to see no reply at all from the release team for so long, though I know they've been quite busy with transitions, so I understand, however maybe security fixes should get a higher priority. If the security team agrees to push it through security-updates (which would be nice since the release team isn't taking care of it), please see the debdiff attached to #799369. Cheers, Thomas Goirand (zigo)
Bug#804522: jenkins: Unauthenticated remote code execution 0-day in Jenkins CLI
Hi Moritz, If I'm not mistaken this vulnerability is actually linked to a dangerous deserialization in commons-collections if the input isn't properly sanitized. I intend to upload a modification of commons-collections to address this issue in Jenkins and the other applications potentially affected. Emmanuel Bourg
Bug#804484: nginx-extras: libvpx.so.2 vs libvpx2.so.2
Control: tags -1 moreinfo On Sun, Nov 08, 2015 at 04:27:50PM -0500, Andrew Siplas wrote: Package: nginx-extras Version: 1.9.6-1 Severity: grave Justification: renders package unusable Upon upgrade to nginx, it did not restart successfully due to the following: /usr/sbin/nginx: error while loading shared libraries: libvpx.so.2: cannot open shared object file: No such file or directory $ dpkg -S /usr/lib/x86_64-linux-gnu/libvpx.so.2 libvpx2:amd64: /usr/lib/x86_64-linux-gnu/libvpx.so.2 libvpx.so.2 gets pulled in by the libgd3 nginx dependency. So I cannot see a way that nginx-extras is installed and libvpx.so.2 is not in place. Could you send us the output of `dpkg -l libvpx*`? libvpx shared library is present as libvpx2.so.2, installed by package libvpx2. libvpx**2***.so.2 library should not exist, as it doesn't belong to any package. Was that a typo? What does `dpkg -S /usr/lib/x86_64-linux-gnu/libvpx2.so.2` return?
Bug#799369: swift update for jessie
On 2015-11-09 8:20, Thomas Goirand wrote: This patch has been prepared a long time ago. I've been waiting for the release team's approval since the 18th of September. This is more than a month and a half. I'm by the way disappointed to see no reply at all from the release team for so long If we're in a grumbling and disappointed mood, #750010 has been waiting for you to reply since September *last year*. #719632 also has questions to you from Moritz dated December 2013 that don't appear to have ever received a response. Regards, Adam
Bug#804343: RFS: libsvm/3.20-1 [NMU] -- library implementing support vector machines
Hi, On 2015-11-07 18:21, Gianfranco Costamagna wrote: >>libsvm (3.20-1) unstable; urgency=medium >> >> * Non-maintainer upload. [...] > >> * Import new upstream version. > > > this is really out of an NMU scope, do you have any evidence about the > maintainer > being MIA/not interested anymore, or acking you to upload a new release? I'm the maintainer of LIBLINEAR, a package related to LIBSVM. I pinged the maintainer of LIBSVM a while ago. He indicated that he's still interested in maintaining it, but had to schedule the time. I'll ping the maintainer again, and see whether he can make the time soon. In any case, LIBSVM's structure is very similar to LIBLINEAR, so an up to date packaging could be taken from the latter and adapted to the former. Regards, Christian
Bug#804522: jenkins: Unauthenticated remote code execution 0-day in Jenkins CLI
On Mon, Nov 09, 2015 at 09:25:20AM +0100, Emmanuel Bourg wrote: > Hi Moritz, > > If I'm not mistaken this vulnerability is actually linked to a dangerous > deserialization in commons-collections if the input isn't properly > sanitized. Indeed, I intended to file a separate bug for those (but I was unsure whether jenkins used the system-wide lib as opposed to the released versions from jenkins upstream) Cheers, Moritz
Bug#804315: [Vmdebootstrap-devel] Namespace issues
To further cloud the issue, the Debian website still links to the Debian Live project's website as the source of their live images. Is there more than this one rude individual saying the Debian Live project is being replaced? On Mon, Nov 9, 2015 at 12:59 AM, chals wrote: > On Mon, Nov 9, 2015 at 12:45 AM, Iain R. Learmonth wrote: > > Hi, > > > > It is worth noting that live-build is not a Debian project, it is an > > external project that claims to be an official Debian project. This is > > something that needs to be fixed. > > > > There is no namespace issue, we are building on the existing live-config > and > > live-boot packages that are maintained and bringing these into Debian as > > native projects. If necessary, these will be forks, but I'm hoping that > > won't have to happen and that we can integrate these packages into Debian > > and continue development in a collaborative manner. > > > > live-build has been deprecated by debian-cd, and live-build-ng is > > replacing it. In a purely Debian context at least, live-build is > deprecated. > > live-build-ng is being developed in collaboration with debian-cd and D-I. > > > > I'm aware that I'm going to be upsetting people, but this has been a long > > time coming and I'm not going to spend time bikeshedding over naming. I > > would rather spend that time on integration of live image creation into > > official Debian infrastructure and building the best system for live > image > > creation possible. > > > > Hi, > > Reading what you say, and I beg your pardon before going on, I can > tell that you absolutely have no idea about what the debian live > project is or about its history. But well, I have to admit that if > what you say is true, then you have a point. > > You say "I'm aware that I'm going to be upsetting people, but this has > been a long time coming" > > Yes you are absolutely right, you are upsetting people, people like me > who have contributed to debian for years and spent hours of effort to > make things better. > > "A long time coming"? Excuse me, but the first thing I've ever heard > in all these years is that you and I mean you (not the debian cd team, > who supposedly is responsible for this upheaval) shows up from out of > the blue claiming that you have the right to do as you please and > decide about the future of the debian live team. > > This is, from my point of view, an act of dictatorship and with my > authority as a debian user and contributor for years I demand you step > down from your position and ask for forgiveness to the debian live > team for being so rude, impolite and not worthy of any more of my > priceless words and time. > > Sorry for being so rude and impolite but you can only fight fire with fire. > > > Consider this thread marked as wontfix. > > > > Consider the same from my point of view. > > > > -- > chals > www.chalsattack.com > ch...@chalsattack.com > >
Bug#804351: Kirkwood / Qnap HS-210, kernel 3.16->4.2/ udev 215->227 upgrade issue
On Mon, 2015-11-09 at 15:38 +1300, m...@wiimail.com wrote: > Hi all. > > I have been happily running debian on a Qnap HS-210 for about a year > now. > > It was a sid install onto a USB drive, last updated just before the > jessie release. > So it was running on kernel 3.16+63 and udev 215-9 from around that > time. > > Today I ran the first dist-upgrade after such long time, > and that brought in kernel 4.2+68 and udev 227-2. > > But now it is no longer bringing up the network interface on boot > ups, > so I can't ssh in anymore. It might be the same issue as this recent installation report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804351 I've not had a chance to dig into what is going on there. Often this kind of thing turns out to be an upstream change to the modules (different config options, splitting modules into more fine grained parts) which requires tweaks to the kernel config, or initramfs-tools or to the kernel udebs for the installer. > I am not sure if the problem is the kernel not finding the usb drive, > hence not completing boot, > or perhaps the udev rules changes brought by the newer version screwing > with the net config? > > The log files inside /var/log don't seem to get touched on boot > attempts, so it would seem that the kernel is not finding the USB drive? That would be consistent with #804351 at least. > I've also come across this link: > http://forum.doozan.com/read.php?2,12096 > But I don't really understand FDT or what it all means to my install? This is a third possibility. The version of flash-installer in Stretch onwards should know enough to append a DTB when required, so I think it is less likely. Which version of flash-kernel do you have installed and what is the contents of /proc/hardware (in whatever rescue environment I suppose you are using to check the logs). Ian.
Bug#804522: jenkins: Unauthenticated remote code execution 0-day in Jenkins CLI
Le 09/11/2015 09:26, Moritz Muehlenhoff a écrit : > Indeed, I intended to file a separate bug for those (but I was unsure > whether > jenkins used the system-wide lib as opposed to the released versions from > jenkins upstream) libjenkins-java depends on libcommons-collections3-java, but jenkins-common has jenkins.war which contains commons-collections.jar. So uploading a new version of libcommons-collections3-java isn't enough, jenkins has to be rebuilt.
Bug#804523: libtorrent19: SIGBUS for magnet links when filesystem is full
Package: libtorrent19 Version: 0.13.6-1+b1 Severity: normal Download a magnet link to a file system with no space triggers a SIGBUS in libtorrent. Here is an example: $ rtorrent 'magnet:?xt=urn:btih:bc84cb84010074094dba7bb55eebf68c6b3934a2&dn=debian-8.2.0-amd64-CD-1.iso&tr=udp://bttracker.debian.org:6969&tr=http://bttracker.debian.org:6969/announce' Caught SIGBUS, dumping stack: rtorrent() [0x415f4b] /lib/x86_64-linux-gnu/libpthread.so.0(+0x10760) [0x7fe76c57f760] /lib/x86_64-linux-gnu/libc.so.6(+0x90759) [0x7fe76c25c759] /usr/lib/x86_64-linux-gnu/libtorrent.so.19(+0x7f8f2) [0x7fe76daec8f2] /usr/lib/x86_64-linux-gnu/libtorrent.so.19(+0xc8ceb) [0x7fe76db35ceb] /usr/lib/x86_64-linux-gnu/libtorrent.so.19(+0xd3524) [0x7fe76db40524] /usr/lib/x86_64-linux-gnu/libtorrent.so.19(+0xbf1de) [0x7fe76db2c1de] /usr/lib/x86_64-linux-gnu/libtorrent.so.19(+0xc098d) [0x7fe76db2d98d] /usr/lib/x86_64-linux-gnu/libtorrent.so.19(+0xc9223) [0x7fe76db36223] /usr/lib/x86_64-linux-gnu/libtorrent.so.19(+0xd4240) [0x7fe76db41240] /usr/lib/x86_64-linux-gnu/libtorrent.so.19(_ZN7torrent9PollEPoll7performEv+0x14a) [0x7fe76daafd6a] /usr/lib/x86_64-linux-gnu/libtorrent.so.19(_ZN7torrent9PollEPoll7do_pollEli+0x61) [0x7fe76daafe11] /usr/lib/x86_64-linux-gnu/libtorrent.so.19(_ZN7torrent11thread_base10event_loopEPS0_+0x124) [0x7fe76daeb334] rtorrent() [0x412094] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7fe76c1ec850] rtorrent() [0x415356] Error: Success Signal code '2': Non-existent physical address. Fault address: 0x7fe76e65f000 The fault address is not part of any chunk. Aborted (core dumped) $ df -h ~/mnt Filesystem Size Used Avail Use% Mounted on /dev/loop0 8.7M 8.5M 0 100% /home/edward/mnt $ -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libtorrent19 depends on: ii libc62.21-0experimental1 ii libgcc1 1:5.2.1-23 ii libssl1.0.2 1.0.2d-3 ii libstdc++6 5.2.1-23 ii zlib1g 1:1.2.8.dfsg-2+b1 libtorrent19 recommends no packages. libtorrent19 suggests no packages. -- no debconf information -- Edward.
Bug#804055: transition: graphicsmagick
On Sun, Nov 8, 2015 at 12:13 PM, Emilio Pozuelo Monfort wrote: > On 08/11/15 11:57, László Böszörményi (GCS) wrote: >> Only python-pgmagick needs a sourceful upload of its new release. >> I've contacted the maintainer but can do the update myself if needed. > > Yes, that needs fixing, otherwise it'll get removed from testing. OK, 0.5.12 was uploaded and built on all supported architectures, but fails on mips64el due to an ICE. Otherwise the transition is all green now. Thanks, Laszlo/GCS
Bug#804465: dolfin: FTBFS: wants ufc 1.5.0
dolfin version 1.6.0 will fix this problem. It is currently sitting in the new queue. Johannes On Sun, Nov 8, 2015 at 8:09 PM Chris West (Faux) < solo-debianb...@goeswhere.com> wrote: > Source: dolfin > Version: 1.5.0-4 > Severity: serious > Justification: fails to build from source > Tags: sid > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > The package fails to build: > > -- Boost version: 1.58.0 > -- Found the following Boost libraries: > -- filesystem > -- program_options > -- system > -- thread > -- iostreams > CMake Error at CMakeLists.txt:322 (message): > Could not find a configuration file for package UFC that is compatible > with > requested version 1.5.0. > > Set UFC_DIR to the directory containing a CMake configuration file for > UFC. > > > -- Configuring incomplete, errors occurred! > See also "/dolfin-1.5.0/debian/build-python2.7/CMakeFiles/CMakeOutput.log". > "tail -v -n +0 CMakeCache.txt" > > Full build log: > https://reproducible.debian.net/rb-pkg/unstable/amd64/dolfin.html > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > -- > debian-science-maintainers mailing list > debian-science-maintain...@lists.alioth.debian.org > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers >
Bug#804524: RFS: node-es6-shim/0.33.10+ds-1 (already in Debian: new version)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "node-es6-shim", which is already in Debian -- upstream released a newer version. * Package name: node-es6-shim Version : 0.33.10+ds-1 Upstream Author : Paul Miller and contributors * URL : https://github.com/paulmillr/es6-shim/ * License : Expat Section : web It builds those binary packages: libjs-es6-shim - ECMAScript 6 compat. shims for legacy JavaScript engines (library node-es6-shim - ECMAScript 6 compat. shims for legacy JavaScript engines (Node.js To access further information about this package, please visit the following URL: http://mentors.debian.net/package/node-es6-shim Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/n/node-es6-shim/node-es6-shim_0.33.10+ds-1.dsc Changes since the last upload: * New upstream release. * Stop shipping node_modules/* as we don't need it. Thanks, Snark on #debian-javascript
Bug#804342: H264: Frame missing
Am 07.11.2015 um 16:37 schrieb mathieu: Subject: H264: Frame missing Package: libmlt6 Version: 0.9.2-2 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? A bug in MLT results in missing frames at start of a H264 video. The bug has been fixed, see https://github.com/mltframework/mlt/issues/89 Is it possible to integrate the fix in Debian stable ? Thanks Hello, could you verifiy if the packages from [0] are working for you and fix your issue? [0]: http://misc.linux-dev.org/.804342/ -- /* 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 */
Bug#804246: transition: gsl
On Sun, 8 Nov 2015 19:38:36 -0600 Dirk Eddelbuettel wrote: > > On 9 November 2015 at 01:12, Emilio Pozuelo Monfort wrote: > | > edd@max:~$ bts block 802246 by 804495 804496 804497 804498 804499 804500 > 804501 804502 > | > edd@max:~$ > | > > | > Thanks *so much* for your very timely and very lucid help. Much > appreciated. > | > | It doesn't look like that worked. Maybe you don't have a MTA configured. > Adding > | the blocks now. > > Hmpf. > > Shouldn't bts talk to the default MTA on my box? Works for all other apps... It worked fine, just went to the wrong bug :-) (a closed one in my packages) Andreas
Bug#804315: [Vmdebootstrap-devel] Bug#804315: Namespace issues
On Mon, 9 Nov 2015 08:59:41 +0100 chals wrote: > On Mon, Nov 9, 2015 at 12:45 AM, Iain R. Learmonth > wrote: > > Hi, > > > > It is worth noting that live-build is not a Debian project, it is an > > external project that claims to be an official Debian project. This > > is something that needs to be fixed. > > > > There is no namespace issue, we are building on the existing > > live-config and live-boot packages that are maintained and bringing > > these into Debian as native projects. If necessary, these will be > > forks, but I'm hoping that won't have to happen and that we can > > integrate these packages into Debian and continue development in a > > collaborative manner. > > > > live-build has been deprecated by debian-cd, and live-build-ng is > > replacing it. In a purely Debian context at least, live-build is > > deprecated. live-build-ng is being developed in collaboration with > > debian-cd and D-I. > > > > I'm aware that I'm going to be upsetting people, but this has been > > a long time coming and I'm not going to spend time bikeshedding > > over naming. I would rather spend that time on integration of live > > image creation into official Debian infrastructure and building the > > best system for live image creation possible. > > Apologies for making it look like Iain was the only voice on this. I've been unwell this weekend and Steve has been busy with the miniDebConf and is now (presumably) catching up on the sleep he lost whilst organising it. > Hi, > > Reading what you say, and I beg your pardon before going on, I can > tell that you absolutely have no idea about what the debian live > project is or about its history. But well, I have to admit that if > what you say is true, then you have a point. I've been involved with debian-live before. I remember a meeting with the live team at a previous debconf (Argentina?) where one of my previous rootfs build tools [multistrap] was being considered for a role within live but we didn't find a good match. > You say "I'm aware that I'm going to be upsetting people, but this has > been a long time coming" > > Yes you are absolutely right, you are upsetting people, people like me > who have contributed to debian for years and spent hours of effort to > make things better. Sorry, but I'm assuming you don't mean that Iain, Steve or I haven't spent years contributing and uploading to Debian and years and years of effort to make Debian better. > "A long time coming"? Excuse me, but the first thing I've ever heard > in all these years is that you and I mean you (not the debian cd team, > who supposedly is responsible for this upheaval) It is the team. Steve has been asking me for this support in vmdebootstrap for months and months. Every time there is a release or a point release, I get more nagging because he has to struggle with fixing live-*. > shows up from out of > the blue claiming that you have the right to do as you please and > decide about the future of the debian live team. Iain is not on his own. This comes from the debian-cd team. Steve has been nagging me for vmdebootstrap support to replace live-build since about a week after vmdebootstrap arrived in Debian, certainly before the Jessie release. > This is, from my point of view, an act of dictatorship and with my > authority as a debian user and contributor for years I demand you step > down from your position and ask for forgiveness to the debian live > team for being so rude, impolite and not worthy of any more of my > priceless words and time. Not going to happen. Just what "authority" is a user meant to have? Those who do the work in Debian earn the right to make the decisions on how that work is done in Debian. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpXfaLZWlDhK.pgp Description: OpenPGP digital signature
Bug#803363: [PATCH] notmuch: workaround for FTBFS
Hi David, > I tested with gdb 7.10-1 on amd64, and that seems not to be the case. > All of the tests end up exiting 255 instead of 0 or 1. I didn't have time > to dig deeper than that yet. I didn't remember the return codes, but on amd64, those tests passed. In the meantime, I found the patch for gdb that we need and proposed it to gdb debian maintainers : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803440 Fred
Bug#804315: [Vmdebootstrap-devel] Bug#804315: Namespace issues
On Mon, 9 Nov 2015 11:18:32 +1100 "Michael ." wrote: > >There is no namespace issue, we are building on the existing > >live-config > and > >live-boot packages that are maintained and bringing these into > >Debian as native projects. If necessary, these will be forks, but > >I'm hoping that won't have to happen and that we can integrate these > >packages into Debian and continue development in a collaborative > >manner. > > Actually there is and I think any person who works in a legal capacity > would verify that. No, in the Debian project, no team has exclusive rights over package namespaces - filename conflicts are different. Namespacing should be consistent with the purpose of the package to avoid confusion. live-build-ng is the next generation of build tool for live images. The name is appropriate. > With regards to collaboration, considering this is the first many > people have heard of this it seems to me you have not gone out of > your way to integrate people who have been working on these packages > into your project. As I said in my previous response to the Debian > Live list (which btw last time someone used the word Debian in a > unofficial capacity (Debian-Mulitmedia) they were asked to stop I > haven't seen any requests like this to the Debian Live mailing list > as yet) it would have been good if "instead of starting a new project > the group from the new project would be much better off assisting > with an already well established project > > >live-build has been deprecated by debian-cd, and live-build-ng is > >replacing it. In a purely Debian context at least, live-build is > deprecated. > >live-build-ng is being developed in collaboration with debian-cd and > >D-I. > > Just out of interests sake can you provide proof of this? He just did. Iain speaks as part of the debian-cd team. The debian-cd team deprecated live-build and have been looking for a replacement since before the Jessie release. I made a set of changes which underpin that support at DebConf15. Iain developed the code based upon that to deliver the missing support which is required by the debian-cd team. Job done. Well done, Iain. > You seem to be very intractable. No discussion, no change of heart, Correct. What has happened here is that the debian-cd team have finally found a solution to the provision of necessary support which has been lacking from the debian-live project for an inordinate amount of time. > not willing to discuss anything with people like Daniel who have been > doing this for years. If there has been correspondence from any part > of Debian and the team who are working on Debian-Live that shows this > is not something new and out of the blue I'll be very surprised. It's taken long enough already. There is no point waiting when the code is now working. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpvwP231NoHb.pgp Description: OpenPGP digital signature
Bug#760849: transition: glew
Dear Release Team, FYI, the 1.13.0 stable version has been released meanwhile by upstream on October 15, 2015. On October 25, 2015 a first testing-purpose package has been uploaded to experimental and with the huge help (as usual) from Luca Falavigna (dktrkranz) and his Deb-O-Matic infrastructure (on amd64 architecture) it was tested building with all its 63 reverse dependencies again. Most conditions for the package building haven't changed in this period. A couple of packages are become new reverse dependencies of GLEW. Almost all the r-deps are doing file on test rebuilds and those failing are not caused by GLEW. Extensive list of the packages and their state of rebuilding following: * avogadro_1.0.3-13 => OK * ball_1.4.2+20140406-1.1 => FTBFS (no glew-related) * bino_1.6.0-1 => FTBFS (no glew-related) * blender_2.74+dfsg0-4 => OK * bzflag_2.4.2+ds1-5 => OK * calligra_1:2.8.5+dfsg-1.2 => FTBFS (no glew-related) * cegui-mk2_0.7.6-3.3 => FTBFS (no glew-related) * colobot_0.1.6-1 => OK * darkradiant_2.0.2-2 => OK * dolphin-emu_4.0.2+dfsg2-1 => OK * enblend-enfuse_4.1.4+dfsg-2 => OK * freeorion_0.4.5-1 => OK * frogatto_1.3.1+dfsg-2 => OK * fs-uae_2.6.1+dfsg-2 => OK * gambas3_3.5.4-2 => FTBFS (no glew-related) * gem_1:0.93.3-9 => OK * gemrb_0.8.2-1 => OK * gimp-plugin-registry_7.20140602 => OK * gource_0.43-1 => OK * hedgewars_0.9.21.1-5 => OK * hugin_2015.0.0~rc3+dfsg-1 => FTBFS (no glew-related) * imagevis3d_3.1.0-4 => OK * info-beamer_1.0~pre3-1 => OK * k3d_0.8.0.3-8 => FTBFS (no glew-related) * kodi_15.2~rc3+dfsg1-1 => OK * libgltf_0.0.2-4 => OK * libreoffice_1:5.0.3~rc1-2 => CHECK * lightspark_0.7.2+git20150512-2 => OK * linphone_3.6.1-2.4 => OK * logstalgia_1.0.6-1 => OK * megaglest_3.11.1-2 => OK * mesa-demos_8.2.0-1 => FTBFS (no glew-related) * meshlab_1.3.2+dfsg1-2 => OK * mupen64plus-video-z64_2.0.0+13+g72af4f0-2 => OK * mygui_3.2.2-4 => OK * openclonk_6.1-1 => OK * opencsg_1.4.0-1 => OK * openctm_1.0.3+dfsg1-1.1 => OK * openimageio_1.5.20~dfsg0-1 => FTBFS (no glew-related) * openmsx_0.12.0-1 => OK * openscad_2015.03-1+dfsg-2 => FTBFS (no glew-related) * performous_1.0+git150721-1 => OK * phlipple_0.8.5-2 => OK * projectm_2.1.0+dfsg-3 => OK * pymol_1.7.2.1-2.1 => OK * quesoglc_0.7.2-5 => OK * qutemol_0.4.1~cvs2008-3.2 => OK * rbdoom3bfg_1.0.3+repack1+git20150806-1 => OK * renpy_6.17.6-1.1 => OK * rlvm_0.14-1 => OK * root-system_5.34.19+dfsg-1.2 => FTBFS (no glew-related) * rss-glx_0.9.1-6 => OK * scorched3d_43.3.d+dfsg-1.1 => OK * sofa-framework_1.0~beta4-10 => OK * soya_0.15~rc1-10 => OK * spring_100.0+dfsg-2 => OK * supertux_0.3.5a-2 => OK * trigger-rally_0.6.1-0.1 => OK * tulip_4.7.0dfsg-2 => FTBFS * utopia-documents_2.4.4-2.1 => FTBFS (no glew-related) * warzone2100_3.1.1-2 => OK * widelands_1:18-3 => OK * witty_3.3.4+dfsg-5 => FTBFS (no glew-related) What am I supposed to do now? Is it a good time for uploading it to unstable? Thanks for your time and patience. -- Matteo F. Vescovi || Debian Developer GnuPG KeyID: 4096R/0x8062398983B2CF7A
Bug#804525: rsyslog: does not clean TLS contexts on connection loss
Package: rsyslog Version: 8.4.2-1 Severity: important Tags: security -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 We are using rsyslog to send logs from machine A to machine B through a TLS-authenticated TCP connection. Sometimes, the network between the two machines becomes unreliable. If the TCP connections breaks without proper indication, the server side does not seem to clean some context or state. This results in the connection not being re-established after the network comes back, which breaks logging on the client because the log buffers run over and Syslog is designed to block in that case. I could imagine this is security-relevant. *If* an admin sees need to use TLS on Syslog, then they obviously have an untrusted network between machines, so deliberately breaking the TLS connection and thus causing a Denial of Service on the server becomes an attack vector. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJOBAEBCAA4BQJWQGVJMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pZQmxAAs07EusSEu0ZGw07m1g9d wcMkiPKmE3rpzjPTFQkTGwP26l7x+1qKcOgPRQ5gaFWxHHUmVDpgCdU+RN5b2Yih A8KAaoccKzwONhCecHFMLLbmjZFh6ZqI0OI1i4DUnfLb/zKWmcNMjh8LWBGdDC3T rApopmBIGeOcnhvdHMIiSlkRl1av560eyEwrUW5A6p4OqS6CeWX8Kl5olMPtTnhO 0RsNqXCnQluQOO0oQA5G7WcNl9DHVj4VvUte8nbm+tN+3D1fTrGywQ65gIi9nPWQ AHQ6lM2FPFLVv4QBejI9VT262u2BelrFMB5JGWZr2YsW7Jzzspq+s4Wn1PQqEJm2 i9t0A/4pTGBeJWs1wrVqVMGhNfWOZQczrtyYoE658flXv4fR2HalW2aoy9SWTtxs i3//zQmMaEgKzmG8EI8PW8T/pVuBjuXOKCsV+CJkpLimIlwHt1+VClqUBtV0UVYp zQsC+qeeHwWfLjpBhQ8lIfJQqsblR14hwESaXrcPV7wnsFjQx6ViIhQLn+b/ktOg O9ihZ79n4xMPZjAhpDBvO8WYZT7nZnvjUbTXr86bf9eU7IJF7jcrlq80JnCfARR5 +DFSwgYY2cfGuPyuP4pYYc5HdKNPFiuF7SmodIwTndKBfbMSeLrJF+tlWNa7qT+Y U+ZCTX3RsqS9Q6dgXcn3Nao= =dy+L -END PGP SIGNATURE-
Bug#789077: ruby2.2 transition: about to switch the default in unstable
On 08/11/15 23:44, Christian Hofstaedtler wrote: > FTR, we're now down to just subversion, uwsgi and zeroc-ice. > > James and Antonio are making some progress with subversion in > #803589, but it appears to be more tricky (and upstream has no fix > yet). > > zeroc-ice has an upstream fix, but the delta is too large for me to > backport it as part of an NMU. > > Haven't heard back yet from the uwsgi team. Thanks for the update. You can make those bugs serious now as this is imminent. Let us know once subversion is fixed. Cheers, Emilio
Bug#804055: transition: graphicsmagick
On 09/11/15 09:59, László Böszörményi (GCS) wrote: > On Sun, Nov 8, 2015 at 12:13 PM, Emilio Pozuelo Monfort > wrote: >> On 08/11/15 11:57, László Böszörményi (GCS) wrote: >>> Only python-pgmagick needs a sourceful upload of its new release. >>> I've contacted the maintainer but can do the update myself if needed. >> >> Yes, that needs fixing, otherwise it'll get removed from testing. > OK, 0.5.12 was uploaded and built on all supported architectures, but > fails on mips64el due to an ICE. Otherwise the transition is all green > now. You can ignore mips64el for now. It's not in testing so that won't block the transition. Cheers, Emilio
Bug#804526: isc-dhcp-client: Does not restart dhclient on upgrade
Package: isc-dhcp-client Version: 4.3.3-5 Severity: normal Dear Maintainer, I upgraded to the reported version on 2015-10-16 but it took until a reboot yesterday (2015-11-08) before dhclient was restarted. I only noticed because logcheck tripped over the log message format changes for DHCPACK and DHCPREQUEST. I had expected that an upgrade would restart any running dhclient processes. I am aware that *most* dhclient users will trigger restarts as a side effect of frequently changing interfaces and/or daily reboots. I just happen to run a bulky 24/7 workstation on DHCP via a fixed cable where these things are rather infrequent. It would be nice if upgrading the package restarts running instances. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-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 Init: sysvinit (via /sbin/init) Versions of packages isc-dhcp-client depends on: ii debianutils 4.5.1 ii iproute2 4.1.1-1 ii libc6 2.19-22 ii libdns-export100 1:9.9.5.dfsg-12 ii libisc-export95 1:9.9.5.dfsg-12 Versions of packages isc-dhcp-client recommends: ii isc-dhcp-common 4.3.3-5 Versions of packages isc-dhcp-client suggests: pn avahi-autoipd pn isc-dhcp-client-ddns pn resolvconf -- no debconf information Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 Support Free Software Support the Free Software Foundation https://my.fsf.org/donatehttps://my.fsf.org/join GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Bug#803159: linux: Enable DT support for armel/orion5x arch
On Sat, 2015-11-07 at 11:45 +0900, Roger Shimizu wrote: > Patch appended, to avoid any misunderstanding. > - 0001 is both OK for sid and jessie > - 0002 is only necessary for sid, or other 4.x kernel series (e.g. > jessie-backport) Thanks, I'd already set a build going with your first patch and my variant of your second patch for the UART thing. The build went fine and I have now pushed the result to our git tree so it will be in the next upload. I don't have any orion5x to test on. My version of the UART change is below, with your variant (without the "ICEDCC is not set") I would expect CONFIG_DEBUG_ICEDCC to be on by default and according to the Kconfig help text for things to not work without a debugger attached. Did you try your version and find it worked? Ian. @@ -16,6 +16,14 @@ CONFIG_ATAGS_PROC=y CONFIG_VFP=y ## +## file: arch/arm/Kconfig.debug +## +## choice: Kernel low-level debugging port +# CONFIG_DEBUG_ICEDCC is not set +CONFIG_DEBUG_LL_UART_8250=y +## end choice + +## ## file: arch/arm/mach-imx/Kconfig ## # CONFIG_ARCH_MXC is not set
Bug#683848: pbuilder: revised binNMU patches for git am
On 2015-07-22 14:48, Andreas Beckmann wrote: > I attach revised and rebased patches for adding binNMU support that > should apply cleanly with git am. The patches still apply fine to current git, although there is a minor issue: A binNMU with --distribution experimental ends up in sid due to a distribution override for experimental in pbuilder-checkparams which is "required for raw pbuilder (create/update) only" but applied always . Andreas
Bug#804527: postfix: systemd notification error: Postfix sends notify, systemd does not expect it
Package: postfix Version: 2.11.3-1 Severity: normal Dear Maintainer, I am seeing the following error in my logfiles: postfix.service: Got notification message from PID 7097, but reception is disabled. If I understand correctly, this means postfix is using the SD_NOTIFY protocol to tell systemd that it is ready, but systemd is not configured to actually expect this message. Kind regards, Ralf -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (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/dash Init: systemd (via /run/systemd/system) Versions of packages postfix depends on: ii adduser3.113+nmu3 ii cpio 2.11+dfsg-4.1 ii debconf [debconf-2.0] 1.5.56 ii dpkg 1.17.25 ii libc6 2.19-18+deb8u1 ii libdb5.3 5.3.28-9 ii libsasl2-2 2.1.26.dfsg1-13+deb8u1 ii libsqlite3-0 3.8.7.1-1+deb8u1 ii libssl1.0.01.0.1k-3+deb8u1 ii lsb-base 4.1+Debian13+nmu1 ii netbase5.3 ii ssl-cert 1.0.35 Versions of packages postfix recommends: ii python 2.7.9-1 Versions of packages postfix suggests: ii bsd-mailx [mail-reader]8.1.2-0.20141216cvs-2 pn dovecot-common ii emacs24-nox [mail-reader] 24.4+1-5 ii libsasl2-modules 2.1.26.dfsg1-13+deb8u1 ii mutt [mail-reader] 1.5.23-3 pn postfix-cdb pn postfix-doc pn postfix-ldap pn postfix-mysql pn postfix-pcre pn postfix-pgsql ii procmail 3.22-24 pn resolvconf pn sasl2-bin pn ufw -- debconf information: postfix/chattr: false postfix/mydomain_warning: postfix/relay_restrictions_warning: postfix/sqlite_warning: * postfix/main_mailer_type: Local only postfix/destinations: hacksaar.kdmz1.iku-systems.de, localhost.kdmz1.iku-systems.de, localhost postfix/bad_recipient_delimiter: postfix/mailbox_limit: 0 postfix/tlsmgr_upgrade_warning: postfix/recipient_delim: + postfix/relayhost: postfix/rfc1035_violation: false postfix/root_address: postfix/not_configured: postfix/kernel_version_warning: * postfix/mailname: hacksaar.kdmz1.iku-systems.de postfix/protocols: all postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 postfix/procmail: true postfix/retry_upgrade_warning:
Bug#804528: review Chromium bug 501318 status, warning on rtc.debian.org page
package: rtc.debian.org severity: important Problems were discovered in Chromium, no audio or video with WebRTC https://code.google.com/p/chromium/issues/detail?id=501318 There is a patch for libsrtp here that resolves the issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770659#124 Need to: a) look at making some solution widely available (e.g. an upstream chromium fix or getting a fixed libsrtp into jessie and wheezy) b) update the warning about this issue on https://rtc.debian.org
Bug#804529: ejabberd: HTTP upload fails with 'bad argument in call to erlang:list_to_binary()'
Package: ejabberd
Version: 15.10-2
Severity: important
Dear Maintainer,
when trying to share file via HTTP upload method (mod_http_upload) the
upload fails with following error in log. The uploaded photo was small
PNG. Both Gajim and Conversations clients failed.
2015-11-09 10:20:51.788 [info] <0.675.0>@mod_http_upload:create_slot:580 Got
HTTP upload slot for u...@.com/Gajim (file: coffe-sophie-copy.jpg)
2015-11-09 10:20:51.797 [info] <0.990.0>@ejabberd_listener:accept:299
(#Port<0.16013>) Accepted connection 192.168.xx.xx:34830 -> xx.xx.xx.xx:5444
2015-11-09 10:20:51.798 [info] <0.1165.0>@ejabberd_http:init:157 started:
{p1_tls,{tlssock,#Port<0.16013>,#Port<0.16014>}}
2015-11-09 10:20:52.232 [error] <0.1165.0> CRASH REPORT Process <0.1165.0> with
0 neighbours crashed with reason: bad argument in call to
erlang:list_to_binary(<<"/srv/jabber/upload/6bc534cbxxxef80b/vdbh473UMwcCfte1O...">>)
in mod_http_upload:thumb_el/2 line 891
2015-11-09 10:20:52.232 [error] <0.428.0> Supervisor ejabberd_http_sup had
child undefined started with {ejabberd_http,start_link,undefined} at <0.1165.0>
exit with reason badarg in context ch
ild_terminated
-- System Information:
Debian Release: 8.2
APT prefers stable
APT policy: (750, 'stable'), (600, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 4.2.0-rc6-686-pae (SMP w/4 CPU cores)
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages ejabberd depends on:
ii adduser 3.113+nmu3
ii debconf [debconf-2.0] 1.5.56
ii erlang-asn1 1:18.1-dfsg-1
ii erlang-base-hipe [erlang-abi-17.0] 1:18.1-dfsg-1
ii erlang-crypto 1:18.1-dfsg-1
ii erlang-inets1:18.1-dfsg-1
ii erlang-lager3.0.1-1
ii erlang-mnesia 1:18.1-dfsg-1
ii erlang-odbc 1:18.1-dfsg-1
ii erlang-p1-cache-tab 0.2015.07.28-1
ii erlang-p1-iconv 0.2015.06.24-1
ii erlang-p1-stringprep0.2015.02.04-1
ii erlang-p1-tls 0.2015.08.03-1+b1
ii erlang-p1-utils 0.2015.10.16-1
ii erlang-p1-xml 0.2015.10.23-1
ii erlang-p1-yaml 0.2015.10.07-1
ii erlang-p1-zlib 0.2015.02.23-2
ii erlang-public-key 1:18.1-dfsg-1
ii erlang-ssl 1:18.1-dfsg-1
ii erlang-syntax-tools 1:18.1-dfsg-1
ii init-system-helpers 1.24
ii openssl 1.0.2d-3
ii ucf 3.0030
ejabberd recommends no packages.
Versions of packages ejabberd suggests:
pn apparmor
pn apparmor-utils
ii ejabberd-contrib 0.2015.10.26~dfsg0-1
ii erlang-oauth20.2015.09.28-1
ii erlang-p1-mysql 0.2015.09.29-1
ii erlang-p1-pam0.2015.02.23-1
ii erlang-p1-pgsql 0.2015.04.28-2
ii erlang-p1-sip0.2015.07.22-1
ii erlang-p1-stun 0.2015.09.16-1
ii erlang-redis-client 1.0.8-1
ii erlang-sqlite3 1.1.4~dfsg0-1
ii imagemagick 8:6.8.9.9-5
ii libunix-syslog-perl 1.1-2+b4
-- debconf information excluded
Bug#804315: [Vmdebootstrap-devel] Bug#804315: Namespace issues
>No, in the Debian project, no team has exclusive rights over package >namespaces - filename conflicts are different. Namespacing should be >consistent with the purpose of the package to avoid confusion. >live-build-ng is the next generation of build tool for live images. The >name is appropriate. Based on the so called fact, that has yet to be proven, that Debian Live is not an official Debian project you do not have the right to take a name and use it. Namespace is an identifier, if you use a namespace already in use and claim it as your own you are adding to confusion. >He just did. Iain speaks as part of the debian-cd team. The debian-cd >team deprecated live-build and have been looking for a replacement since >before the Jessie release. I made a set of changes which underpin that >support at DebConf15. Iain developed the code based upon that to >deliver the missing support which is required by the debian-cd team. >Job done. Well done, Iain. I'm sorry I don't see a link to any list or meeting minutes that even remotely indicate this is an official Debian directive. All I see is a couple of people who have been rude, uncompromising, post something they cannot or will not show evidence for when asked. Good job Iain and Neil, how to win friends and influence people, job well done. >Correct. So you admit to being intractable! >What has happened here is that the debian-cd team have finally found a >solution to the provision of necessary support which has been lacking >from the debian-live project for an inordinate amount of time. Yet the Debian CD webpage points directly to Debian Live iso images as official images even though you or Iain have said they are not official. You haven't found a solution, you haven't even got a Live iso image listed on the official Debian cd site. If the Debian CD team truly believe that things have been lacking in Debian Live "for an inordinate amount of time" one would think the people involved in the Debian CD team would have communicated with the Debian Live team and collaboratively worked with them to fix the issues. This brings me back to a previous point, if their has been communication between Debian and Debian Live about any of this where is it? If it is not available for public viewing, as is all other Debian correspondence and decision making as far as I am aware the only conclusion that can reasonably be made is that a small number of people have deliberately taken it upon themselves to hijack Debian Live without the Debian Live team even knowing it is happening. All I have asked for is proof, it is very telling that you have been unable to show it. Is this because it doesn't exist? This is just another problem that is making me consider Devuan as a viable alternative to Debian. Debian's decision making processes used to be open and public, this most certainly appears to be behind closed doors. On 9 November 2015 at 20:17, Neil Williams wrote: > On Mon, 9 Nov 2015 11:18:32 +1100 > "Michael ." wrote: > > > >There is no namespace issue, we are building on the existing > > >live-config > > and > > >live-boot packages that are maintained and bringing these into > > >Debian as native projects. If necessary, these will be forks, but > > >I'm hoping that won't have to happen and that we can integrate these > > >packages into Debian and continue development in a collaborative > > >manner. > > > > Actually there is and I think any person who works in a legal capacity > > would verify that. > > No, in the Debian project, no team has exclusive rights over package > namespaces - filename conflicts are different. Namespacing should be > consistent with the purpose of the package to avoid confusion. > live-build-ng is the next generation of build tool for live images. The > name is appropriate. > > > With regards to collaboration, considering this is the first many > > people have heard of this it seems to me you have not gone out of > > your way to integrate people who have been working on these packages > > into your project. As I said in my previous response to the Debian > > Live list (which btw last time someone used the word Debian in a > > unofficial capacity (Debian-Mulitmedia) they were asked to stop I > > haven't seen any requests like this to the Debian Live mailing list > > as yet) it would have been good if "instead of starting a new project > > the group from the new project would be much better off assisting > > with an already well established project > > > > >live-build has been deprecated by debian-cd, and live-build-ng is > > >replacing it. In a purely Debian context at least, live-build is > > deprecated. > > >live-build-ng is being developed in collaboration with debian-cd and > > >D-I. > > > > Just out of interests sake can you provide proof of this? > > He just did. Iain speaks as part of the debian-cd team. The debian-cd > team deprecated live-build and have been looking for a replacement since > before the Jessie release. I made a set of change
Bug#804530: haproxy: Ensure stop action works on pre-systemd versions of Debian (and Ubuntu)
Package: haproxy Version: 1.6.2-2 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu xenial ubuntu-patch Dear Maintainer, In Ubuntu, the attached patch was applied to achieve the following: [ Jorge Niedbalski ] * debian/haproxy.init: + Pass the pidfile to the --pidfile argument instead of the PID number, easing backports to pre-systemd versions of Ubuntu and Debian (LP: #1477198). On older Ubuntu versions (pre systemd), the stop action was not working correctly in the init script; this patch resolves that issue. Thanks for considering the patch. -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-16-generic (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) diff -Nru haproxy-1.6.2/debian/haproxy.init haproxy-1.6.2/debian/haproxy.init --- haproxy-1.6.2/debian/haproxy.init 2015-11-03 20:21:36.0 + +++ haproxy-1.6.2/debian/haproxy.init 2015-11-09 09:39:47.0 + @@ -61,10 +61,8 @@ fi ret=0 - for pid in $(cat $PIDFILE); do - start-stop-daemon --quiet --oknodo --stop \ - --retry 5 --pid $pid --exec $HAPROXY || ret=$? - done + start-stop-daemon --quiet --oknodo --stop \ + --retry 5 --pidfile $PIDFILE --exec $HAPROXY || ret=$? [ $ret -eq 0 ] && rm -f $PIDFILE
Bug#803402: nmh: bad interaction with mime-support
On Sun, 08 Nov 2015 15:18:22 +0100, Harald Geyer writes: >"run-mailcap --action=view" is meant to start a pager, which is not >what mhshow wants to do. why not? where does it say that? view is meant to do whatever is necessary to present the material to the user. >mhshow wants formatted output that can be >passed on to it's own pager (moreproc). not necessarily; look at the examples in man mhshow for, say, audio or image/*: mhshow-show-audio/basic: raw2audio 2>/dev/null | play mhshow-show-image: xv %f mhshow-show-application/PostScript: lpr -Pps there is no paging by nmh involved in any of these. there is nothing in the mhshow docs that indicates that a pager supplied by mhshow must be used. >x/console/whatever use, but nmh (and sensible-tools) are messing >things up, because they try to do part of the job themselfs. I think >the easy way to fix this is to dump run-mailcap down so it doesn't >interfere with what nmh is doing. to be honest i have not yet seen any of the interference problems you're having. with the default mhn.defaults, no special .mh_profile entries whatsoever, and a pure html email (yuck), for me mhshow a) fires up my real browser if i have a $DISPLAY, b) falls back to showing me the transmogrified text (via w3m) and paged by less if there is no $DISPLAY. if i switch the mhn.defaults to --action=cat, then case a) never happens anymore, because action cat ignores all mailcap entries but the ones with 'copiousoutput' and not many have that set, and in the remaining case b) no paging whatsoever is performed. i find this latter setup highly undesirable. >I think your explanation in the News.Debian is a good one. ok, then i'll expand that in the next upload to mention that people should also consider run-mailcap --action=cat as alternative to the defaults... >configuration probably works on many sytems - but only by chance, not >by being right. ...because i disagree with your opinion that there is anything wrong with delegating show actions to run-mailcap --action=view. so, shall we agree to disagree? i just don't think there's a single setup that'll match everybody's preferences. regards az -- Alexander Zangerl + GPG Key 0xB963BD5F + http://snafu.priv.at/ On two occasions I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. -- Charles Babbage signature.asc Description: Digital Signature
Bug#804529: ejabberd: HTTP upload fails with 'bad argument in call to erlang:list_to_binary()'
* Josef Kufner [2015-11-09 10:30]:
> when trying to share file via HTTP upload method (mod_http_upload) the
> upload fails with following error in log. The uploaded photo was small
> PNG. Both Gajim and Conversations clients failed.
>
> 2015-11-09 10:20:51.788 [info] <0.675.0>@mod_http_upload:create_slot:580 Got
> HTTP upload slot for u...@.com/Gajim (file: coffe-sophie-copy.jpg)
> 2015-11-09 10:20:51.797 [info] <0.990.0>@ejabberd_listener:accept:299
> (#Port<0.16013>) Accepted connection 192.168.xx.xx:34830 -> xx.xx.xx.xx:5444
> 2015-11-09 10:20:51.798 [info] <0.1165.0>@ejabberd_http:init:157 started:
> {p1_tls,{tlssock,#Port<0.16013>,#Port<0.16014>}}
> 2015-11-09 10:20:52.232 [error] <0.1165.0> CRASH REPORT Process <0.1165.0>
> with 0 neighbours crashed with reason: bad argument in call to
> erlang:list_to_binary(<<"/srv/jabber/upload/6bc534cbxxxef80b/vdbh473UMwcCfte1O...">>)
> in mod_http_upload:thumb_el/2 line 891
> 2015-11-09 10:20:52.232 [error] <0.428.0> Supervisor ejabberd_http_sup had
> child undefined started with {ejabberd_http,start_link,undefined} at
> <0.1165.0> exit with reason badarg in context child_terminated
This is fixed upstream[*] and can be worked around by disabling
thumbnail creation (Gajim and Conversations currently don't use that
feature anyway):
modules:
# [...]
mod_http_upload:
thumbnail: false
# [...]
[*]:
https://github.com/processone/ejabberd/commit/1b368a86b709053ded0ebdfa0499cbd78712fce6
Bug#803589: FTBFS with ruby2.2 (only)
On Sun, Nov 08, 2015 at 11:39:07PM -0500, James McCoy wrote:
> On Sun, Nov 08, 2015 at 11:25:00AM -0200, Antonio Terceiro wrote:
> > On Sat, Nov 07, 2015 at 08:46:10PM -0500, James McCoy wrote:
> > > Except there's another test that still fails when ruby 2.2 is actually
> > > used (unlike in the build log you provided or any of the testing I had
> > > done recently), due to code trying to modify nil which is now frozen,
> > > along with true/false.
> >
> > do you have the log? nil is actually always frozen, so this is likely
> > something that used to return a String, but now returns nil.
>
> No, this part of the test suite hasn't changed in years. It was passing
> nil into a function, eventually causing nil to be passed in as "self" to
> rb_set_pool:
>
> VALUE
> rb_set_pool(VALUE self, VALUE pool)
> {
> if (NIL_P(pool)) {
> VALUE old_pool = rb_ivar_get(self, id___pool__);
> rb_hash_aset(rb_pools(self), rb_obj_id(old_pool), old_pool);
> rb_ivar_set(self, id___pool__, Qnil);
> } else {
> if (NIL_P(rb_ivar_get(self, id___pool__))) {
> rb_ivar_set(self, id___pool__, pool);
> } else {
> rb_hash_aset(rb_pools(self), rb_obj_id(pool), pool);
> }
> }
>
> return Qnil;
> }
>
> I sent a patch[0] which appears to be the fix for it, but I'd like to
> wait a day for feedback.
>
> http://mid.gmane.org/20151109042607.ga13...@freya.jamessan.com
right. Indeed, I just realized that on 2.1 nil, true and false are *not*
frozen, which seems crazy when you think about it :)
> > > I'm sending a patch upstream for the general test-unit problem, but I
> > > still don't have a solution for the frozen nil problem.
> >
> > subversion is the one pending package with enough reverse dependencies
> > to stop the ruby transition from going on. How important is that one
> > test, and the Ruby bindings in general? Can we have a temporary
> > workaround to allow us to go on with the transition?
>
> If I don't get any push back from upstream, I should have an upload
> ready for subversion in the next day or so. Starting a test build with
> the test-unit and frozen-nil patches now.
Thanks!
--
Antonio Terceiro
signature.asc
Description: PGP signature
Bug#804399: bugs.debian.org: Incorrect link (Upercasing) to dpkg
On Sun, Nov 08, 2015 at 07:26:51PM +0100, Helge Kreutzmann wrote: > On Sun, Nov 08, 2015 at 11:11:26AM +, Colin Watson wrote: > > While this is true and perhaps debbugs should force that to lower case > > in more places (displaying the maintainer also doesn't work, for > > instance), isn't the problem that you visited pkg=Dpkg in the first > > place rather than pkg=dpkg? How did you end up at the first link? > > I ran: > links bugs.debian.org/Dpkg > in the console. Which worked, except that the link to the package page > no longer works. Right, so debbugs does case-insensitive comparisons internally but doesn't force to lower-case for external links. I think it's always been that way. Visiting http://bugs.debian.org/dpkg will of course behave more sensibly. -- Colin Watson [cjwat...@debian.org]
Bug#713937: ITP: libsamsung-ipc -- library to communicate with modems present in Samsung smartphones
On Sat, 05 Oct 2013 17:20:59 +0800 Paul Wise wrote: > I hope that someone else who has a Samsung based phone ... will package it In case it helps anyone, I've attached the preliminary packaging I made. All the patches I had have been merged upstream now: http://git.replicant.us/gitweb/?p=replicant/external/libsamsung-ipc.git;a=summary -- bye, pabs https://wiki.debian.org/PaulWise libsamsung-ipc-debian-packaging.tar.gz Description: application/compressed-tar signature.asc Description: This is a digitally signed message part
Bug#804531: eagle: cannot be rebuilt against libssl1.0.2
Package: eagle Version: 6.6.0-2 Severity: serious Tags: sid stretch Justification: fails to build from source Hi, eagle cannot be rebuilt agaiunst libssl1.0.2 since the blob binary is linked against libssl.so.1.0.0: dh_shlibdeps -a dpkg-shlibdeps: error: couldn't find library libssl.so.1.0.0 needed by debian/eagle/usr/lib/eagle/bin/eagle (ELF format: 'elf32-i386'; RPATH: '') dpkg-shlibdeps: error: couldn't find library libcrypto.so.1.0.0 needed by debian/eagle/usr/lib/eagle/bin/eagle (ELF format: 'elf32-i386'; RPATH: '') dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/eagle/usr/lib/eagle/bin/eagle was not linked against libXrandr.so.2 (it uses none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/eagle/usr/lib/eagle/bin/eagle was not linked against libXcursor.so.1 (it uses none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/eagle/usr/lib/eagle/bin/eagle was not linked against libXi.so.6 (it uses none of the library's symbols) dpkg-shlibdeps: error: cannot continue due to the errors listed above Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file. To help dpkg-shlibdeps find private libraries, you might need to use -l. dh_shlibdeps: dpkg-shlibdeps -Tdebian/eagle.substvars debian/eagle/usr/lib/eagle/bin/eagle returned exit code 2 debian/rules:5: recipe for target 'binary-arch' failed make: *** [binary-arch] Error 2 Andreas
Bug#804315: [Vmdebootstrap-devel] Bug#804315: Namespace issues
Hi, On Mon, Nov 09, 2015 at 08:47:53PM +1100, Michael . wrote: >Yet the Debian CD webpage points directly to Debian Live iso images as >official images even though you or Iain have said they are not >official. You haven't found a solution, you haven't even got a Live iso >image listed on the official Debian cd site. See http://cdimage.debian.org/cdimage/experimental-live/. These are far too experimental currently for public consumption and so not listed on the website. >If the Debian CD team >truly believe that things have been lacking in Debian Live "for an >inordinate amount of time" one would think the people involved in the >Debian CD team would have communicated with the Debian Live team and >collaboratively worked with them to fix the issues. Communication was attempted and failed. Serious problems include: #718225: live-build should authenticate files it downloads (from 2013) #731709: support uefi (from 2013) Neither of these issues have been fixed. >This brings me back >to a previous point, if their has been communication between Debian and >Debian Live about any of this where is it? In person at DebConf meetings and on the BTS. >If it is not available for >public viewing, as is all other Debian correspondence and decision >making as far as I am aware the only conclusion that can reasonably be >made is that a small number of people have deliberately taken it upon >themselves to hijack Debian Live without the Debian Live team even >knowing it is happening. vmdebootstrap has been a work in progress for a good while now, and Daniel at least was aware of this. It would appear this was not communicated to the team. >All I have asked for is proof, it is very >telling that you have been unable to show it. Is this because it >doesn't exist? Updates on the Debian Trademark Policy will also be available soon to help clarify what is and is not "Official Debian". >This is just another problem that is making me consider Devuan as a >viable alternative to Debian. Debian's decision making processes used >to be open and public, this most certainly appears to be behind closed >doors. This is by no means normal for Debian, the problem here is that communication was one sided where we did not see any progress on the issues that were affecting the official live images and so we've ended up here. Thanks, Iain. --
Bug#804506: RFS: attic 0.16-1
Control: tags -1 moreinfo Control: owner -1 ! Hi, please use this watch file 1) http://pypi.debian.net/attic/watch I tried a uscan --debug --force-download and the current watch file in git just doesn't work 2) control: priority should be extra 3) (this is a showstopper) - python3-msgpack (>= 0.1.10), libssl1.0.2 + python3-msgpack (>= 0.1.10) please remove libssl1.0.2 from runtime dependencies. it is automagically added by shlibs:Depends (please double check the built deb file without that dependency inside DEBIAN/control) cheers, G. Il Lunedì 9 Novembre 2015 1:39, Caitlin Matos ha scritto: Package: sponsorship-requests Severity: normal I am looking for a sponsor for my package. I am already the package maintainer and have had previous releases sponsored, but require a new sponsor. The latest changes can be found in the git repo at: http://anonscm.debian.org/gitweb/?p=collab-maint/attic.git Release 0.16-1 closes several bugs, which I have marked as pending on BTS. Unfortunately, it does not close the RC bug, as the upstream fix has not yet been released. * Package name: attic Version : 0.16-1 Upstream Author : https://github.com/jborg/attic * URL : https://attic-backup.org/ * License : BSD-3-clause Thanks, Caitlin
Bug#804529: ejabberd: HTTP upload fails with 'bad argument in call to erlang:list_to_binary()'
Holger Weiß wrote, on 9.11.2015 10:52: > modules: > # [...] > mod_http_upload: > thumbnail: false > # [...] Thank you, this workaround works! signature.asc Description: OpenPGP digital signature
Bug#756090: ITA: irker -- submission tools for IRC notifications
Has anything further happened here? I'm interested in seeing irker stay in debian, and would be willing to help maintain the package. -- Neil Muller
Bug#797926: transition: openssl: remove SSLv3 methods
On Sat, 7 Nov 2015 12:30:11 +0100 Emilio Pozuelo Monfort wrote: > All the rdeps have been binNMUed at this stage. What about experimental? Is there a "apt-cache rdepends libssl1.0.0" equivalent command that only reports packages from experimental? Anyway, here we have a list: atheme-services bind9 bobcat burp clamav dnsval freeipa gambas3 ginkgocadx isdnutils isync libevent libpam-ssh nodejs omniorb-dfsg pacemaker php7.0 poco postgresql-9.5 psqlodbc ptlib simutrans socat srtp sslscan syslog-ng thrift tinc tor unbound generated with perl -n -e '$p = $1 if /^Package: (.*)$/; $p = $1 if /^Source: (\S+)/; print "$p\n" if /Depends:.*libssl1.0.0/;' /var/lib/apt/lists/ftp.de.debian.org_debian_dists_experimental_*_Packages | sort -u from amd64+i386 Packages Andreas
Bug#804532: Support for default alias sets
Package: vmm Version: 0.6.2-1 Severity: wishlist The idea of a default alias set is that each domain gets bootstrapped to handle these aliases without any additional configuration. For instance, a site might want to ensure that all hosted domains know how to handle mail to postmaster@ and abuse@ for RFC-compliance. Or a company might want to ensure that sales@ reaches the right people no matter what domain name was used. Using alias domains for this would mean that the domains would be treated strictly identical and it would not be possible to add disjunct sets of users to different domains. Please find attached the SQL-side of things. I have not even thought about the UI yet, as for now I just need the functionality. The table alias_set establishes the m:n link between the domain_data table (with a new asid field), and the common_alias table that defines the common aliases for the different alias sets (identified by asid). In addition, the postfix_virtual_alias_maps function was completely rewritten so as to now scan the different map sources in series. The order of precedence is: alias > user/relocated > alias sets > catchall Hence, an explicit alias or a user account overrides a default alias. Finally, I introduce yet another column to domain_data called 'owner', which should be a mandatory datum for each domain to hold the e-mail address of its main owner. This address will be used when a default alias sets its destination to 'OWNER'. Initially, I conceived there to be another m:n table domain_alias_set, to allow multiple alias sets to be associated with each domain. However, this would increase complexity quite a lot (especially of the UI that needs yet to be written), and I couldn't really imagine a serious use case, so I opted for 1:n instead. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- .''`. martin f. krafft @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems CREATE OR REPLACE FUNCTION postfix_virtual_alias_map(localpart character varying, the_domain character varying) RETURNS SETOF recipient_destination LANGUAGE plpgsql STABLE STRICT AS $$ DECLARE recipient varchar(320) := localpart || '@' || the_domain; did bigint := (SELECT gid FROM domain_name WHERE domainname=the_domain); BEGIN -- ALIASES RETURN QUERY SELECT recipient, _interpolate_destination(destination, localpart, the_domain)::text FROM alias WHERE gid = did AND address = localpart; IF FOUND THEN RETURN; END IF; -- RAISE NOTICE 'No matching aliases found, looking up users/relocated: %', recipient; -- USERS AND RELOCATED RETURN QUERY SELECT recipient, recipient::text as destination FROM users WHERE gid = did AND local_part = localpart UNION SELECT recipient, recipient::text as destination FROM relocated WHERE gid = did AND address = localpart; IF FOUND THEN RETURN; END IF; -- RAISE NOTICE 'No matching users/relocated found, looking up default aliases: %', recipient; -- DEFAULT ALIASES RETURN QUERY SELECT recipient, CASE WHEN destination = 'OWNER' THEN _interpolate_destination(owner, localpart, the_domain)::text ELSE _interpolate_destination(destination, localpart, the_domain)::text END as destination FROM common_alias a JOIN domain_data d ON (a.asid = d.asid) WHERE d.gid = did AND local_part = localpart; IF FOUND THEN RETURN; END IF; -- RAISE NOTICE 'No matching default alias found, looking up catchall: %', recipient; -- CATCHALL RETURN QUERY SELECT recipient, _interpolate_destination(destination, localpart, the_domain)::text FROM catchall c WHERE c.gid = did; IF FOUND THEN RETURN; END IF; -- RAISE NOTICE 'No matching catchalls found, returning empty set: %', recipient; RETURN; END; $$; -- Opted for 1:n instead of a domain_alias_set n:m link for simplicity: alter table domain_data add column asid bigint not null default 1; -- We need the concept of a domain "owner" to make alias sets universal. -- If a default alias sets its destination to 'OWNER', this address will -- be used. alter table domain_data add colu
Bug#804533: chromium: Stopped sending intermediate certs for client certificates, auth fails
Package: chromium Version: 46.0.2490.71-1 Severity: important Dear Maintainer, Client certificate based authentication suddenly stopped working with this release for multiple servers. Upon investigation with Wireshark it shows that, when a client certificates is requested by the server, Chromium now only sends the client certificate itself without any intermediate certificates. Version before also sent the intermediate certificates. This leads to authentication failure at least against nginx and lighttpd servers. Authentication is working with other browser and older chromium versions. Based on my understanding of rfc5246 section 7.4.6 and section and 7.4.2 the intermediates must be sent with the certificate. Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages chromium depends on: ii libasound21.0.29-1 ii libatk1.0-0 2.18.0-1 ii libavcodec-ffmpeg56 7:2.8.1-1 ii libavformat-ffmpeg56 7:2.8.1-1 ii libavutil-ffmpeg547:2.8.1-1 ii libc6 2.19-22 ii libcairo2 1.14.4-1 ii libcups2 2.1.0-5 ii libdbus-1-3 1.10.2-1 ii libexpat1 2.1.0-7 ii libfontconfig12.11.0-6.3 ii libfreetype6 2.6-2 ii libgcc1 1:5.2.1-23 ii libgdk-pixbuf2.0-02.32.1-1 ii libglib2.0-0 2.46.1-1 ii libgnome-keyring0 3.12.0-1+b1 ii libgtk2.0-0 2.24.28-1 ii libjpeg62-turbo 1:1.4.1-2 ii libnspr4 2:4.10.9-2 ii libnspr4-0d 2:4.10.9-2 ii libnss3 2:3.20-1 ii libnss3-1d2:3.20-1 ii libpango-1.0-01.38.1-1 ii libpangocairo-1.0-0 1.38.1-1 ii libpci3 1:3.3.1-1 ii libspeechd2 0.8-7 ii libsrtp0 1.4.5~20130609~dfsg-1.1 ii libstdc++65.2.1-23 ii libx11-6 2:1.6.3-1 ii libxcomposite11:0.4.4-1 ii libxcursor1 1:1.1.14-1+b1 ii libxdamage1 1:1.1.4-2+b1 ii libxext6 2:1.3.3-1 ii libxfixes31:5.0.1-2+b2 ii libxi62:1.7.5-1 ii libxml2 2.9.2+zdfsg1-4 ii libxrandr22:1.5.0-1 ii libxrender1 1:0.9.9-2 ii libxslt1.11.1.28-2+b2 ii libxss1 1:1.2.2-1 ii libxtst6 2:1.2.2-1+b1 ii x11-utils 7.7+3 ii xdg-utils 1.1.1-1 chromium recommends no packages. Versions of packages chromium suggests: pn chromium-l10n -- no debconf information
Bug#804530: [Pkg-haproxy-maintainers] Bug#804530: haproxy: Ensure stop action works on pre-systemd versions of Debian (and Ubuntu)
❦ 9 novembre 2015 09:47 GMT, James Page : > In Ubuntu, the attached patch was applied to achieve the following: > > [ Jorge Niedbalski ] > * debian/haproxy.init: > + Pass the pidfile to the --pidfile argument instead of the PID > number, easing backports to pre-systemd versions of Ubuntu > and Debian (LP: #1477198). > > On older Ubuntu versions (pre systemd), the stop action was not > working correctly in the init script; this patch resolves that issue. I don't think this is compatible with multiple HAProxy processes (nbproc > 1). See how we do that when start-stop-daemon doesn't support --pid: https://anonscm.debian.org/cgit/pkg-haproxy/haproxy.git/tree/debian/haproxy.init?h=debian/1.6.2-2ppa1_precise#n64 -- Don't patch bad code - rewrite it. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#804315: [Vmdebootstrap-devel] Bug#804315: Namespace issues
On Mon, Nov 9, 2015 at 11:06 AM, Neil Williams wrote: > On Mon, 9 Nov 2015 08:59:41 +0100 > chals wrote: > >> On Mon, Nov 9, 2015 at 12:45 AM, Iain R. Learmonth >> wrote: >> > Hi, >> > >> > It is worth noting that live-build is not a Debian project, it is an >> > external project that claims to be an official Debian project. This >> > is something that needs to be fixed. >> > >> > There is no namespace issue, we are building on the existing >> > live-config and live-boot packages that are maintained and bringing >> > these into Debian as native projects. If necessary, these will be >> > forks, but I'm hoping that won't have to happen and that we can >> > integrate these packages into Debian and continue development in a >> > collaborative manner. >> > >> > live-build has been deprecated by debian-cd, and live-build-ng is >> > replacing it. In a purely Debian context at least, live-build is >> > deprecated. live-build-ng is being developed in collaboration with >> > debian-cd and D-I. >> > >> > I'm aware that I'm going to be upsetting people, but this has been >> > a long time coming and I'm not going to spend time bikeshedding >> > over naming. I would rather spend that time on integration of live >> > image creation into official Debian infrastructure and building the >> > best system for live image creation possible. >> > > > Apologies for making it look like Iain was the only voice on this. I've > been unwell this weekend and Steve has been busy with the miniDebConf > and is now (presumably) catching up on the sleep he lost whilst > organising it. > >> Hi, >> >> Reading what you say, and I beg your pardon before going on, I can >> tell that you absolutely have no idea about what the debian live >> project is or about its history. But well, I have to admit that if >> what you say is true, then you have a point. > > I've been involved with debian-live before. I remember a meeting with > the live team at a previous debconf (Argentina?) where one of my > previous rootfs build tools [multistrap] was being considered for a > role within live but we didn't find a good match. > >> You say "I'm aware that I'm going to be upsetting people, but this has >> been a long time coming" >> >> Yes you are absolutely right, you are upsetting people, people like me >> who have contributed to debian for years and spent hours of effort to >> make things better. > > Sorry, but I'm assuming you don't mean that Iain, Steve or I haven't > spent years contributing and uploading to Debian and years and years of > effort to make Debian better. > >> "A long time coming"? Excuse me, but the first thing I've ever heard >> in all these years is that you and I mean you (not the debian cd team, >> who supposedly is responsible for this upheaval) > > It is the team. Steve has been asking me for this support in > vmdebootstrap for months and months. Every time there is a release or a > point release, I get more nagging because he has to struggle with > fixing live-*. Would you (or Steve or the Debian CD team) please point to actual real bugs that affected you? You claim it as a reason of debian cd team switch to vmdebootsrap. As a live-build user, I'm interested by these. >> shows up from out of >> the blue claiming that you have the right to do as you please and >> decide about the future of the debian live team. > > Iain is not on his own. This comes from the debian-cd team. Steve has > been nagging me for vmdebootstrap support to replace live-build since > about a week after vmdebootstrap arrived in Debian, certainly before > the Jessie release. > >> This is, from my point of view, an act of dictatorship and with my >> authority as a debian user and contributor for years I demand you step >> down from your position and ask for forgiveness to the debian live >> team for being so rude, impolite and not worthy of any more of my >> priceless words and time. > > Not going to happen. Just what "authority" is a user meant to have? > Those who do the work in Debian earn the right to make the decisions on > how that work is done in Debian.
Bug#804530: [Pkg-haproxy-maintainers] Bug#804530: haproxy: Ensure stop action works on pre-systemd versions of Debian (and Ubuntu)
Hi Vincent On Mon, Nov 9, 2015 at 10:32 AM, Vincent Bernat wrote: > ❦ 9 novembre 2015 09:47 GMT, James Page : > > > In Ubuntu, the attached patch was applied to achieve the following: > > > > [ Jorge Niedbalski ] > > * debian/haproxy.init: > > + Pass the pidfile to the --pidfile argument instead of the PID > > number, easing backports to pre-systemd versions of Ubuntu > > and Debian (LP: #1477198). > > > > On older Ubuntu versions (pre systemd), the stop action was not > > working correctly in the init script; this patch resolves that issue. > > I don't think this is compatible with multiple HAProxy processes > (nbproc > 1). See how we do that when start-stop-daemon doesn't > support --pid: > Hmm - so start-stop-daemon will generate multiple pids into the pidfile when nbproc > 1? If so I agree that the patch is incomplete (and also broken in Ubuntu 14.04 right now).
Bug#804351: Kirkwood / Qnap HS-210, kernel 3.16->4.2/ udev 215->227 upgradeissue
All, I have had to add the following to /etc/modules to get the network and usb controller to come up mvmdio mv643xx_eth ehci-orion Don't expect usb hotplug to work... AND if you were using UUIDs for disk mounts then you will need to change that back to devices as well none of disk/by-uuid, disk\by-path etc are generated. I have compared the rules.d to an independent one on a working armhf platform and there are no differences. I am running on the 3.16.0-4-kirkwood kernel which appears not to use DTBs so it is not related Iain
Bug#804534: xournal: Export to PDf window frozen
Package: xournal Version: 1:0.4.8-1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** After annotating a pdf file and opening the Export to PDF window (to save the annotation in pdf) the window opens but: (i) I cannot enter a different output file name than the pre-defined value and (ii) pushing any button produces no result (in particular, the pdf file is not generated). -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (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 Init: systemd (via /run/systemd/system) Versions of packages xournal depends on: ii ghostscript-x9.06~dfsg-2+deb8u1 ii libart-2.0-2 2.3.21-2 ii libatk1.0-0 2.14.0-1 ii libc62.19-18+deb8u1 ii libcairo21.14.0-2.1 ii libfontconfig1 2.11.0-6.3 ii libfreetype6 2.5.2-3+deb8u1 ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u3 ii libglib2.0-0 2.42.1-1 ii libgnomecanvas2-02.30.3-2 ii libgtk2.0-0 2.24.25-3 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-01.36.8-3 ii libpoppler-glib8 0.26.5-2 ii libx11-6 2:1.6.2-3 ii zlib1g 1:1.2.8.dfsg-2+b1 xournal recommends no packages. xournal suggests no packages. -- no debconf information
Bug#804315: [Vmdebootstrap-devel] Bug#804315: Namespace issues
Hi, On Mon, Nov 09, 2015 at 12:41:16PM +0200, Fathi Boudra wrote: > Would you (or Steve or the Debian CD team) please point to actual real > bugs that affected you? > You claim it as a reason of debian cd team switch to vmdebootsrap. As > a live-build user, I'm interested by these. As in my previous email: #718225: live-build should authenticate files it downloads (from 2013) #731709: support uefi (from 2013) I am a member of the debian-cd team. These are just two of the major bugs, the real problem we had is that live-build is very fragile and did not produce much in the way of useful output when things broke. This is why there was a delay in the release of live images after the release of jessie. Thanks, Iain. --
Bug#804530: [Pkg-haproxy-maintainers] Bug#804530: haproxy: Ensure stop action works on pre-systemd versions of Debian (and Ubuntu)
❦ 9 novembre 2015 10:42 GMT, James Page : > ❦ 9 novembre 2015 09:47 GMT, James Page : > > > In Ubuntu, the attached patch was applied to achieve the > following: > > > > [ Jorge Niedbalski ] > > * debian/haproxy.init: > > + Pass the pidfile to the --pidfile argument instead of the PID > > number, easing backports to pre-systemd versions of Ubuntu > > and Debian (LP: #1477198). > > > > On older Ubuntu versions (pre systemd), the stop action was not > > working correctly in the init script; this patch resolves that > > issue. > > I don't think this is compatible with multiple HAProxy processes > (nbproc > 1). See how we do that when start-stop-daemon doesn't > support --pid: > > > Hmm - so start-stop-daemon will generate multiple pids into the > pidfile when nbproc > 1? No, haproxy will write multiple PID to the pidfile when nbproc > 1 (in haproxy.cfg). I don't think that start-stop-daemon is able to handle multiple PID in pidfile, hence the loop. -- My only love sprung from my only hate! Too early seen unknown, and known too late! -- William Shakespeare, "Romeo and Juliet" signature.asc Description: PGP signature
Bug#804239: marked as pending
Hi Osamu, Thank you for the quick update. Did you intend to commit this to the "multitar" branch? I have managed to get uscan to work with your recent commits. Thank you! For the record, this is what works for me: version=3 opts=\ downloadurlmangle=s/\/downloads\/gpg\/?\?file=(mysql-([\d\.]*).tar.gz)/\/get\/Downloads\/MySQL-5.6\/$1/,pgpsigurlmangle=s/\/get\/Downloads\/MySQL-5.6\/(mysql-([\d\.]*).tar.gz)/\/downloads\/gpg\/?file=$1/,filenamemangle=s/\/downloads\/gpg\/?\?file=mysql\-([\d\.]*)\.tar\.gz/mysql-$1.tar.gz/ \ http://dev.mysql.com/downloads/mysql/5.6.html?os=src /downloads/gpg/\?file=mysql-([\d\.]*).tar.gz Robie signature.asc Description: Digital signature
Bug#804315: [Vmdebootstrap-devel] Bug#804315: Namespace issues
On Mon, Nov 9, 2015 at 11:17 AM, Neil Williams wrote: > On Mon, 9 Nov 2015 11:18:32 +1100 > "Michael ." wrote: > >> >There is no namespace issue, we are building on the existing >> >live-config >> and >> >live-boot packages that are maintained and bringing these into >> >Debian as native projects. If necessary, these will be forks, but >> >I'm hoping that won't have to happen and that we can integrate these >> >packages into Debian and continue development in a collaborative >> >manner. >> >> Actually there is and I think any person who works in a legal capacity >> would verify that. > > No, in the Debian project, no team has exclusive rights over package > namespaces - filename conflicts are different. Namespacing should be > consistent with the purpose of the package to avoid confusion. > live-build-ng is the next generation of build tool for live images. The > name is appropriate. Obviously, several users don't agree with you. There's a conflict of interest in the naming of your new package, which confuse established users base of live-build. live-build-ng isn't a drop in replacement of live-build, or live-build deprecated in any way (except its usage by Debian CD team).
Bug#804530: [Pkg-haproxy-maintainers] Bug#804530: haproxy: Ensure stop action works on pre-systemd versions of Debian (and Ubuntu)
On Mon, Nov 9, 2015 at 10:50 AM, Vincent Bernat wrote: > > > > > I don't think this is compatible with multiple HAProxy processes > > (nbproc > 1). See how we do that when start-stop-daemon doesn't > > support --pid: > > > > > > Hmm - so start-stop-daemon will generate multiple pids into the > > pidfile when nbproc > 1? > > No, haproxy will write multiple PID to the pidfile when nbproc > 1 (in > haproxy.cfg). I don't think that start-stop-daemon is able to handle > multiple PID in pidfile, hence the loop. > Right - I see; I guess the benefit of using start-stop-daemon is that it will only kill haproxy processes, whereas the kill loop is indiscriminate.
Bug#804535: httrack FTBFS on hppa architecture
Package: httrack Version: 3.48.21-1+b1 On hppa the compiler was switched to gcc-5. Since then, httrack fails to build like this (fails in the testcases): https://buildd.debian.org/status/fetch.php?pkg=httrack&arch=hppa&ver=3.48.21-1%2Bb1&stamp=1447032250 In debian/rules you have this: # *** Patch for s390, mips, hppa.. # It seems that htscore.c can not compile on several archs, due to compiler # capacity limits. These lines shall be removed when gcc is upgraded. # See discussions on 'Assembler messages: Branch out of range' # Addition (04/2004): gcc-3.3 on arm fcks up with htscoremain.c and -O3 (..) ifeq ($(DEB_HOST_ARCH),$(findstring $(DEB_HOST_ARCH),s390 hppa mips mipsel m68k arm)) CFLAGS += -DNOSTRDEBUG endif Removing "hppa" from this list (and maybe the comment) fixes the build and the testcases for me. Can you please remove "hppa" from this list in the next upload? Thanks, Helge
Bug#804473: [Pkg-ime-devel] Bug#804473: libzhuyin: FTBFS: stderr.. recompile with -fPIC
Control: tags -1 pending On Sun, Nov 08, 2015 at 07:23:29PM +, Chris West (Faux) wrote: > Source: libzhuyin > Version: 1.0.2-1 > Severity: serious > Justification: fails to build from source > Tags: sid stretch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > The package fails to build: This issued is fixed in experimental [0]. However, due to opencc dependency, I cannot migrate it to sid. [0] http://anonscm.debian.org/cgit/pkg-ime/libzhuyin.git/commit/?id=f2a9732e7762f391c0390dc316154a8ab9ff2d48 to All, Can we start the opencc transition? > > /usr/bin/ld: storage/.libs/libstorage.a(libstorage_la-phrase_index.o): > relocation R_X86_64_PC32 against undefined symbol `stderr@@GLIBC_2.2.5' can > not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: Bad value > collect2: error: ld returned 1 exit status > Makefile:486: recipe for target 'libzhuyin.la' failed > make[4]: *** [libzhuyin.la] Error 1 > make[4]: Leaving directory '/libzhuyin-1.0.2/src' > > Full build log: > https://reproducible.debian.net/rb-pkg/unstable/amd64/libzhuyin.html > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > ___ > Pkg-ime-devel mailing list > pkg-ime-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-ime-devel -- ChangZhuo Chen (陳昌倬) Debian Developer Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D signature.asc Description: PGP signature
Bug#803846: opal: FTBFS with FFmpeg 2.9
On 02/11/15 22:07, Andreas Cadhalpun wrote: your package fails to build with the upcoming ffmpeg 2.9. This bug will become release-critical at some point when the ffmpeg2.9 transition gets closer. Attached is a patch replacing the deprecated functionality. It also works with ffmpeg 2.8. Please apply this patch and forward it upstream, if necessary. These changes have little regression potential. Hi Andreas, Thank you for the patch. We hope to upload a new release of opal in 2 months (very very approximately), which includes most if not all of your changes, so I prefer to wait a bit. If ffmpeg 2.9 appears in unstable (much) before that, I will test your patch and do an upload with only your patch. Feel free to answer me if that poses problems. Kind regards, -- Eugen
Bug#804536: gcc-5: [mips,mipsel] regression in optimization causes FTBFS for gsoap
Package: gcc-5 Version: 5.2.1-23 Severity: serious Justification: causes gsoap to FTBFS Control: affects -1 gsoap Control: block 804455 by -1 X-Debbugs-Cc: debian-m...@lists.debian.org Hi! The binnmu of gsoap 2.8.22-1 due to the openssl transition failed on mips and mipsel, but succeeded on the other architectures. https://buildd.debian.org/status/package.php?p=gsoap (It also succeeded on mip64le - but the mips64el build used gcc-5 5.2.1-21 while mips and mipsel used 5.2.1-23. I am not sure if this is relevant information.) The failure is a segmentation fault when running the soapcpp2 binary that has been compiled as part of the build. The soapcpp2 binary is not linked to openssl, so the issue is not due to the new openssl library that triggered the binnmu rebuild. I can reproduce the failure on the eder.debian.org porterbox. However, if I on the porterbox reduce the optimization from -O2 to -O1, the build succeeds. This therefore looks like a regression in mips/mipsel optimization. Mattias Ellert signature.asc Description: This is a digitally signed message part
Bug#804530: [Pkg-haproxy-maintainers] Bug#804530: Bug#804530: haproxy: Ensure stop action works on pre-systemd versions of Debian (and Ubuntu)
❦ 9 novembre 2015 10:57 GMT, James Page : > > I don't think this is compatible with multiple HAProxy processes > > (nbproc > 1). See how we do that when start-stop-daemon doesn't > > support --pid: > > > > > > Hmm - so start-stop-daemon will generate multiple pids into the > > pidfile when nbproc > 1? > > No, haproxy will write multiple PID to the pidfile when nbproc > 1 > (in > haproxy.cfg). I don't think that start-stop-daemon is able to > handle > multiple PID in pidfile, hence the loop. > > > Right - I see; I guess the benefit of using start-stop-daemon is that > it will only kill haproxy processes, whereas the kill loop is > indiscriminate. Yes. This is error-prone (and I just noticed that I have the same problem in my backport of 1.6 for Trusty) but I think that the best for now is to stay as is. We could create PID files for each PID, but this won't look clean. -- Make sure comments and code agree. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#803402: nmh: bad interaction with mime-support
Alexander Zangerl writes: > On Sun, 08 Nov 2015 15:18:22 +0100, Harald Geyer writes: > >"run-mailcap --action=view" is meant to start a pager, which is not > >what mhshow wants to do. > > why not? where does it say that? I don't know if this is written down anywhere, but it can be infered from the fact that mhshow does start a pager of its own. > view is meant to do whatever is necessary to present the material to > the user. Agreed. > >mhshow wants formatted output that can be > >passed on to it's own pager (moreproc). > > not necessarily; look at the examples in man mhshow for, say, audio > or image/*: > > mhshow-show-audio/basic: raw2audio 2>/dev/null | play > mhshow-show-image: xv %f > mhshow-show-application/PostScript: lpr -Pps Well, these of course can not be displayed in a pager in the first place ... > there is no paging by nmh involved in any of these. there is nothing > in the mhshow docs that indicates that a pager supplied by mhshow must > be used. I haven't read the source of mhshow, but from what I have seen with strace (yes, actually needed strace to figure out what's wrong) it looks to me like mhshow always fires up moreproc to display the headers *and* any text/* parts after they have been filtered by the respective command from mhn.defaults - I think this implies that mhshow expects the entries in mhn.defaults to behave as filters - at least if X is not available. > >x/console/whatever use, but nmh (and sensible-tools) are messing > >things up, because they try to do part of the job themselfs. I think > >the easy way to fix this is to dump run-mailcap down so it doesn't > >interfere with what nmh is doing. > > to be honest i have not yet seen any of the interference problems > you're having. with the default mhn.defaults, no special .mh_profile entries > whatsoever, and a pure html email (yuck), for me mhshow > > a) fires up my real browser if i have a $DISPLAY, Yes. > b) falls back to showing me the transmogrified text (via w3m) > and paged by less if there is no $DISPLAY. Looks like w3m is smarter than links2 and doing the right thing when stdout is not a terminal. > if i switch the mhn.defaults to --action=cat, then case a) never > happens anymore, because action cat ignores all mailcap entries but the > ones with 'copiousoutput' and not many have that set, Yes, but I have proposed a solution to that in my original message, in case you acutally think this is desired. > and in the remaining case b) no paging whatsoever is performed. This is not true. The paging is done by moreproc (less on my system). If this is not the case on your system, then I see where your opposition is coming from. However I belive something else must be broken in that case. > i find this latter setup highly undesirable. > > >I think your explanation in the News.Debian is a good one. > > ok, then i'll expand that in the next upload to mention that people > should also consider run-mailcap --action=cat as alternative to > the defaults... > > >configuration probably works on many sytems - but only by chance, not > >by being right. > > ...because i disagree with your opinion that there is > anything wrong with delegating show actions to run-mailcap --action=view. I think we are not yet disagreeing about opinion, we are still disagreeing about facts (ie when is moreproc fired up). Let's first sort out the facts, then move on to opinions. > so, shall we agree to disagree? i just don't think there's a single > setup that'll match everybody's preferences. I believe this is not about my preferences (that's what config files are for) but about software compatibility. And software compatibility is a matter of debian packaging. Obviously I had a bad start at explaining what the issue is - it's your decision if the issue is worth fixing (ie tag the bug report wontfix), but I want you to actually see the issue first. (Once we are there, maybe you can tell me how I could have presented the issue better.) HTE, Harald
Bug#804537: cairo-dock-dbus-plug-in-interface-mono: Please rebuild against dbus-sharp
Package: cairo-dock-dbus-plug-in-interface-mono Version: 3.4.0-1.1 Severity: normal Dear Maintainer, ndesk-dbus is very very dead upstream, and we would like to remove it from the archive at the earliest opportunity. It has been superceded by dbus-sharp, which should be API-compatible. Please make the switch as soon as possible, as ndesk-dbus removal is required for part of a packaging transition. -- System Information: Debian Release: jessie/sid APT prefers wily-updates APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), (100, 'wily-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-16-generic (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#804530: [Pkg-haproxy-maintainers] Bug#804530: Bug#804530: haproxy: Ensure stop action works on pre-systemd versions of Debian (and Ubuntu)
On Mon, Nov 9, 2015 at 11:06 AM, Vincent Bernat wrote: > > Right - I see; I guess the benefit of using start-stop-daemon is that > > it will only kill haproxy processes, whereas the kill loop is > > indiscriminate. > > Yes. This is error-prone (and I just noticed that I have the same > problem in my backport of 1.6 for Trusty) but I think that the best for > now is to stay as is. We could create PID files for each PID, but this > won't look clean. > Agreed - I think your kill based approach is OK and avoids such complexity.
Bug#804473: [Pkg-ime-devel] Bug#804473: Bug#804473: libzhuyin: FTBFS: stderr.. recompile with -fPIC
On Mon, Nov 9, 2015 at 7:01 PM, ChangZhuo Chen wrote: > Control: tags -1 pending > > On Sun, Nov 08, 2015 at 07:23:29PM +, Chris West (Faux) wrote: >> Source: libzhuyin >> Version: 1.0.2-1 >> Severity: serious >> Justification: fails to build from source >> Tags: sid stretch >> User: reproducible-bui...@lists.alioth.debian.org >> Usertags: ftbfs >> X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org >> >> Dear Maintainer, >> >> The package fails to build: > > This issued is fixed in experimental [0]. However, due to opencc > dependency, I cannot migrate it to sid. > > [0] > http://anonscm.debian.org/cgit/pkg-ime/libzhuyin.git/commit/?id=f2a9732e7762f391c0390dc316154a8ab9ff2d48 > > to All, > > Can we start the opencc transition? > I guess yes. Previously I wanted to do libpinyin transition first, but it appears fcitx-libpinyin has a build hang when generating additional database... Regards, Aron
Bug#803363: [PATCH] notmuch: workaround for FTBFS
Frederic Bonnard writes:
> Hi David,
>
>> I tested with gdb 7.10-1 on amd64, and that seems not to be the case.
>> All of the tests end up exiting 255 instead of 0 or 1. I didn't have time
>> to dig deeper than that yet.
>
> I didn't remember the return codes, but on amd64, those tests passed.
> In the meantime, I found the patch for gdb that we need and proposed it to
> gdb debian maintainers :
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803440
>
> Fred
Here is the output for the last part of T070-insert.sh. I've replaced
--batch-quiet with --batch here. I don't know why the tests would pass
for you and fail here; perhaps it has something to do with the fact that
I am testing in Stretch.
FAIL error exit when add_message returns OUT_OF_MEMORY
--- T070-insert.26.expected 2015-11-09 11:24:00.862180256 +
+++ T070-insert.26.output 2015-11-09 11:24:00.862180256 +
@@ -1 +1 @@
-1
+255
Breakpoint 1 at 0x41e9f0: file lib/database.cc, line 2390.
Breakpoint 2 at 0x41e9f8: file lib/database.cc, line 2390.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, notmuch_database_add_message (notmuch=notmuch@entry=0x677100,
filename=filename@entry=0x699350
"/home/bremner/software/upstream/notmuch/test/tmp.T070-insert/mail/new/1447068240.M825612P17810.zancas",
message_ret=message_ret@entry=0x7fffd040) at lib/database.cc:2390
2390{
FAIL success exit with --keep when add_message returns OUT_OF_MEMORY
--- T070-insert.27.expected 2015-11-09 11:24:01.254179033 +
+++ T070-insert.27.output 2015-11-09 11:24:01.258179021 +
@@ -1 +1 @@
-0
+255
Breakpoint 1 at 0x41e9f0: file lib/database.cc, line 2390.
Breakpoint 2 at 0x41e9f8: file lib/database.cc, line 2390.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, notmuch_database_add_message (notmuch=notmuch@entry=0x677100,
filename=filename@entry=0x699350
"/home/bremner/software/upstream/notmuch/test/tmp.T070-insert/mail/new/1447068241.M227729P17820.zancas",
message_ret=message_ret@entry=0x7fffd030) at lib/database.cc:2390
2390{
FAIL error exit when add_message returns XAPIAN_EXCEPTION
--- T070-insert.28.expected 2015-11-09 11:24:01.65813 +
+++ T070-insert.28.output 2015-11-09 11:24:01.65813 +
@@ -1 +1 @@
-1
+255
Breakpoint 1 at 0x41e9f0: file lib/database.cc, line 2390.
Breakpoint 2 at 0x41e9f8: file lib/database.cc, line 2390.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, notmuch_database_add_message (notmuch=notmuch@entry=0x677100,
filename=filename@entry=0x699350
"/home/bremner/software/upstream/notmuch/test/tmp.T070-insert/mail/new/1447068241.M631592P17833.zancas",
message_ret=message_ret@entry=0x7fffd040) at lib/database.cc:2390
2390{
FAIL success exit with --keep when add_message returns XAPIAN_EXCEPTION
--- T070-insert.29.expected 2015-11-09 11:24:02.050176550 +
+++ T070-insert.29.output 2015-11-09 11:24:02.050176550 +
@@ -1 +1 @@
-0
+255
Breakpoint 1 at 0x41e9f0: file lib/database.cc, line 2390.
Breakpoint 2 at 0x41e9f8: file lib/database.cc, line 2390.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, notmuch_database_add_message (notmuch=notmuch@entry=0x677100,
filename=filename@entry=0x699350
"/home/bremner/software/upstream/notmuch/test/tmp.T070-insert/mail/new/1447068242.M23434P17843.zancas",
message_ret=message_ret@entry=0x7fffd030) at lib/database.cc:2390
2390{
FAIL error exit when add_message returns FILE_NOT_EMAIL
--- T070-insert.30.expected 2015-11-09 11:24:02.450175302 +
+++ T070-insert.30.output 2015-11-09 11:24:02.450175302 +
@@ -1 +1 @@
-1
+255
Breakpoint 1 at 0x41e9f0: file lib/database.cc, line 2390.
Breakpoint 2 at 0x41e9f8: file lib/database.cc, line 2390.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, notmuch_database_add_message (notmuch=notmuch@entry=0x677100,
filename=filename@entry=0x699350
"/home/bremner/software/upstream/notmuch/test/tmp.T070-insert/mail/new/1447068242.M420963P17856.zancas",
message_ret=message_ret@entry=0x7fffd040) at lib/database.cc:2390
2390{
FAIL success exit with --keep when add_message returns FILE_NOT_EMAIL
--- T070-insert.31.expected 2015-11-09 11:24:02.842174079 +
+++ T070-insert.31.output 2015-11-09 11:24:02.842174079 +
@@ -1 +1 @@
-0
+255
Breakpoint 1 at 0x41e9f0: file
Bug#804297: graphviz: dot on mipsel fails with emit.c:3873: bezier_bb: Assertion `bz.size > 0' failed
Control: notfound -1 2.38.0-10
Control: found -1 2.38.0-11
Hi,
On Sat, 2015-11-07 at 03:52 +0100, Johannes Schauer wrote:
> Package: graphviz
> Version: 2.38.0-10
> Severity: important
> Control: block 804296 by -1
>
> Hi,
>
> I ran into this problem when building my package botch on mipsel:
[...]
> The problem can be trigged by the most minimal input:
>
> > $ echo -ne 'digraph G {A -> B}' | dot
> > dot: emit.c:3873: bezier_bb: Assertion `bz.size > 0' failed.
> Aborted
I can reproduce this using graphviz 2.38.0-11, but not 2.38.0-10.
The most obvious difference between them is that -11 is compiled with
gcc-5 and -10 is not. That could be related (I havn't done much
investigation so far)?
James
signature.asc
Description: This is a digitally signed message part
Bug#804538: RM: liblouis2 -- RoQA; NBS; obsolete pre-transition library
Package: ftp.debian.org Severity: normal please decruft src:louis, the only dependency problems are in arch:all packages built from the crufty version of src:liblouis * source package liblouis version 2.6.4-2 no longer builds binary package(s): liblouis2 on amd64,arm64,armel,armhf,hurd-i386,i386,kfreebsd-amd64,kfreebsd-i386,mips,mips64el,mipsel,powerpc,ppc64el,s390x - suggested command: dak rm -m "[auto-cruft] NBS (no longer built by liblouis)" -s unstable -a amd64,arm64,armel,armhf,hurd-i386,i386,kfreebsd-amd64,kfreebsd-i386,mips,mips64el,mipsel,powerpc,ppc64el,s390x -p -R -b liblouis2 - broken Depends: liblouis: python-louis python3-louis Andreas
Bug#804530: [Pkg-haproxy-maintainers] Bug#804530: Bug#804530: haproxy: Ensure stop action works on pre-systemd versions of Debian (and Ubuntu)
On Mon, Nov 9, 2015 at 11:21 AM, James Page wrote: > On Mon, Nov 9, 2015 at 11:06 AM, Vincent Bernat wrote: > >> > Right - I see; I guess the benefit of using start-stop-daemon is that >> > it will only kill haproxy processes, whereas the kill loop is >> > indiscriminate. >> >> Yes. This is error-prone (and I just noticed that I have the same >> problem in my backport of 1.6 for Trusty) but I think that the best for >> now is to stay as is. We could create PID files for each PID, but this >> won't look clean. >> > > Agreed - I think your kill based approach is OK and avoids such > complexity. > How would you feel about using: for pid in $(cat $PIDFILE); do if start-stop-daemon --help | grep -q "\-\-pid "; then start-stop-daemon --quiet --oknodo --stop \ --retry 5 --pid $pid --exec $HAPROXY || ret=$? else if kill -0 $pid 2> /dev/null; then /bin/kill $pid || ret=4 fi fi done This would preserve use of stop-start-daemon if the version installed supported --pid, and drop back to the kill approach if not. Would ease backporting to older Debian/Ubuntu versions.
Bug#804482: [Pkg-opennebula-devel] Bug#804482: ruby-opennebula: please migrate to ruby-mysql2
I have sent request to upstream [0] [0] https://forum.opennebula.org/t/please-switch-to-ruby-mysql2/1446 Olivier Le dim. 8 nov. 2015 à 22:21, Christian Hofstaedtler a écrit : > Package: ruby-opennebula > Severity: normal > > Dear OpenNebula packaging team, > > your ruby-opennebula package depends on ruby-mysql, which itself is > considered deprecated upstream, and maintenance has ceased about a > year ago [1]. > > Please persuade upstream into switching to ruby-mysql2 or a similar > gem. > > ruby-mysql (and ruby-dbd-mysql) should be going away from testing > soon, and I don't expect somebody to fix it for stretch; rather it > should just go away completely. > > Thanks, > Christian > > [1] https://github.com/luislavena/mysql-gem > > -- > ,''`. Christian Hofstaedtler > : :' : Debian Developer > `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 > `- > > ___ > Pkg-opennebula-devel mailing list > pkg-opennebula-de...@lists.alioth.debian.org > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-opennebula-devel >
Bug#804539: libcgal-qt5-dev required when using libcgal-dev with cmake
Package: libcgal-qt5-dev Version: 4.7-3 Severity: minor Hello, since around 4.7, when using cmake to build software based on CGAL, libcgal-qt5-dev needs to be installed, even if the software doesn't use Qt5 or does but doesn't need CGAL-Qt5. This can be most easily verified using the demos: | $ tar xzf /usr/share/doc/libcgal-demo/demo.tar.gz | $ cd demo/Surface_modeling | $ cmake . | [...] | CMake Error at /usr/lib/x86_64-linux-gnu/cmake/CGAL/CGALExports.cmake:83 (message): | The imported target "CGAL::CGAL_Qt5" references the file | | "/usr/lib/x86_64-linux-gnu/libCGAL_Qt5.so.11.0.1" | | but this file does not exist. Possible reasons include: As a workaround, I have added libcgal-qt5-dev to the build dependencies of openscad; judging from shlibdeps results, this does not lead to overlinking and is thus just an additional build dependency. It appears to me that the dependency on CGAL-Qt is hardcoded in the CGAL_Exports.cmake file generated at CGAL build time, I'm not versed enough in CMake to make useful suggestions on how this issue can be resolved cleanly. Best regards chrysn signature.asc Description: PGP signature
Bug#775850: timblserver: FTBFS in unstable: error: 'class Timbl::GetOptClass' has no member named 'getLogFile'
Hi Joost, On Mon, 14 Sep 2015 14:11:40 +0200 Joost van =?utf-8?Q?Baal-Ili=C4=87?= wrote: > On Mon, Sep 14, 2015 at 12:21:34PM +0100, Peter Green wrote: > > > > > > timblserver (1.8-1) experimental; urgency=low > > > . > > >* New upstream release. > > > - Fixes "timblserver: FTBFS in unstable: error: 'class > > > Timbl::GetOptClass' > > How come this was uploaded to experimental and not unstable? > > > > I'm not quite sure if uploading to unstable wouldn't introduce even more RC > bugs. Don't have the time to find out about that now. I'll likely be able to > allocate more time to it within about one month. Did you find some time to look at this issue? > btw: you're welcome to nmu if you're convinced that will fix bugs. In unstable currently the whole reverse-build-deps set of timblserver is unbuildable and uninstallable. Andreas (doing QA, having no other interest in these packages)
Bug#804530: [Pkg-haproxy-maintainers] Bug#804530: Bug#804530: haproxy: Ensure stop action works on pre-systemd versions of Debian (and Ubuntu)
❦ 9 novembre 2015 11:51 GMT, James Page : > How would you feel about using: > > for pid in $(cat $PIDFILE); do > if start-stop-daemon --help | grep -q "\-\-pid "; then > start-stop-daemon --quiet --oknodo --stop \ > --retry 5 --pid $pid --exec $HAPROXY || ret=$? > else > if kill -0 $pid 2> /dev/null; then > /bin/kill $pid || ret=4 > fi > fi > done > > This would preserve use of stop-start-daemon if the version installed > supported --pid, and drop back to the kill approach if not. Personally, I find this too hacky and not worth it. For example, if start-stop-daemon sends its output to stderr (unlikely, but...), this will break. Or if start-stop-daemon reduces its help message to only a mention of the manual page. Apollon, what do you think? -- If one cannot enjoy reading a book over and over again, there is no use in reading it at all. -- Oscar Wilde signature.asc Description: PGP signature
Bug#681884: are there any workarounds for schroot+systemd in jessie?
Are there any workarounds available for this bug for schroot+systemd in jessie? Or the only workaround is "don't use systemd"? -- Alexandra N. Kossovsky OKTET Labs (http://www.oktetlabs.ru/)
Bug#798213: [Pkg-monitoring-maintainers] Bug#798213: ganglia-web: CVE-2015-6816: auth bypass
On 08/11/15 18:11, Salvatore Bonaccorso wrote: > Hi, > > On Sun, Sep 06, 2015 at 10:45:29PM +0200, Salvatore Bonaccorso wrote: >> Source: ganglia-web >> Version: 3.6.1-1 >> Severity: important >> Tags: security patch upstream >> >> Hi, >> >> the following vulnerability was published for ganglia-web. >> >> CVE-2015-6816[0]: >> ganglia-web auth bypass >> >> If you fix the vulnerability please also make sure to include the >> CVE (Common Vulnerabilities & Exposures) id in your changelog entry. >> >> For further information see: >> >> [0] https://security-tracker.debian.org/tracker/CVE-2015-6816 >> [1] https://github.com/ganglia/ganglia-web/issues/267 > *ping*? I did a review of the latest upstream releases (both ganglia-web and the ganglia agent) and there are some new JavaScript dependencies that need to be packaged https://cdnjs.cloudflare.com/ajax/libs/cubism/1.6.0/cubism.v1.min.js https://cdnjs.cloudflare.com/ajax/libs/protovis/3.3.1/protovis.min.js https://cdnjs.cloudflare.com/ajax/libs/jstree/3.2.1/jstree.min.js Given that we have given users of this package a disclaimer[1] about security support and advised them to protect the web interface with an ACL or HTTP authentication, how urgent is resolving this bug? Regards, Daniel 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702775
Bug#775850: timblserver: FTBFS in unstable: error: 'class Timbl::GetOptClass' has no member named 'getLogFile'
Hi Andreas e.a., On Mon, Nov 09, 2015 at 01:07:44PM +0100, Andreas Beckmann wrote: > On Mon, 14 Sep 2015 14:11:40 +0200 Joost van =?utf-8?Q?Baal-Ili=C4=87?= > wrote: > > On Mon, Sep 14, 2015 at 12:21:34PM +0100, Peter Green wrote: > > > > > > > > timblserver (1.8-1) experimental; urgency=low > > > > . > > > >* New upstream release. > > > > - Fixes "timblserver: FTBFS in unstable: error: 'class > > > > Timbl::GetOptClass' > > > How come this was uploaded to experimental and not unstable? > > > > > > > I'm not quite sure if uploading to unstable wouldn't introduce even more RC > > bugs. Don't have the time to find out about that now. I'll likely be able > > to > > allocate more time to it within about one month. > > Did you find some time to look at this issue? Nope. Hrm, I guess I can state: if there hasn't been done done any substantial work on this by february 1, 2016; feel free to remove this stuff from the archive. I expect I'll have been able to allocate some time on this before that date. > > btw: you're welcome to nmu if you're convinced that will fix bugs. > > In unstable currently the whole reverse-build-deps set of timblserver is > unbuildable and uninstallable. Yes... :( Thanks for pinging me. Bye, Joost
Bug#804246: transition: gsl
On 9 November 2015 at 10:02, Andreas Beckmann wrote: | On Sun, 8 Nov 2015 19:38:36 -0600 Dirk Eddelbuettel wrote: | > | > On 9 November 2015 at 01:12, Emilio Pozuelo Monfort wrote: | > | > edd@max:~$ bts block 802246 by 804495 804496 804497 804498 804499 804500 804501 804502 | > | > edd@max:~$ | > | > | > | > Thanks *so much* for your very timely and very lucid help. Much appreciated. | > | | > | It doesn't look like that worked. Maybe you don't have a MTA configured. Adding | > | the blocks now. | > | > Hmpf. | > | > Shouldn't bts talk to the default MTA on my box? Works for all other apps... | | It worked fine, just went to the wrong bug :-) (a closed one in my packages) Of course. Now I see the command-line. Correctly copying six digits is apparently above my cognitive threshold. :-/ Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#804412: libwebkit2gtk-4.0-37: Please avoid dependency on GTK+ 2
On Sun, Nov 08, 2015 at 11:35:47AM +0300, Dmitry Shachnev wrote: > I currently cannot remove GTK+ 2 from my system because of the following > dependency chain: > > mutter → zenity → libwebkit2gtk-4.0-37 → libgtk2.0-0 > > I see that libwebkit2gtk-4.0-37 ships a binary named > WebKitPluginProcess2, which which is linked against > libgtk-x11-2.0.so. That file is necessary in order to load plugins that depend on GTK+ 2, for example the Adobe Flash Player or the Google Talk / Hangouts plugin. But it's true that the GTK+2 dependency is otherwise not essential, so I think we can remove it. Thanks for the report, Berto
Bug#804540: bzr: obsolete conffile /etc/bash_completion.d/bzr
Package: bzr Version: 2.6.0+bzr6606-1 User: debian...@lists.debian.org Usertags: adequate obsolete-conffile The package left obsolete conffile after upgrade: /etc/bash_completion.d/bzr Please consult http://wiki.debian.org/DpkgConffileHandling for instructions on how to remove conffiles properly. This bug was brought to you by adequate: https://packages.debian.org/unstable/main/adequate -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 4.2.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages bzr depends on: ii python-bzrlib 2.6.0+bzr6606-1 pn python:any -- Jakub Wilk
Bug#804541: lvm2 Build-depends on obsolete package libcorosync-dev
Package: lvm2 Version: 2.02.133-1 Severity: serious Tags: patch Your package build-depends on libcorosync-dev which is no longer built by the corosync source package. I replaced the build-depends on libcorosync-dev with libcorosync-core-dev and tried a build in a raspbian stretch-staging environment. Through build-testing I found I also needed to add libquorum-dev, libcmap-dev and libcpg-dev to get a sucessful build. I have uploaded this to raspbian, a debdiff is available at http://debdiffs.raspbian.org/main/l/lvm2/lvm2_2.02.133-1%2brpi1.debdiff no intent to NMU in Debian.
Bug#804523: Patch available
control: tag -1 patch I sent a github pull request with a fix to upstream. https://github.com/rakshasa/libtorrent/pull/93 https://github.com/EdwardBetts/libtorrent/commit/8f3f1a794903bcf3ddc755462d0b38106f4b5d1f -- Edward.
Bug#804503: [Pkg-sysvinit-devel] Bug#804503: startpar: Please add Multi-Arch: foreign
tags 804503 patch end Hi, On Mon, Nov 09, 2015 at 09:13:49 +0100, Petter Reinholdtsen wrote: > [Elrond] > > Hi, > > > > startpar AFAIK offers an architecture independent (process level) > > interface to its users. Would you mind setting it to Multi-Arch: > > foreign? > > Not at all. Do you have time to provide a tested patch? Patch is straight forward (attached). I have build a fresh .deb on an amd64 lxc and installed it into an i386 lxc and rebooted that. Still seems to work for me. Cheers Elrond --- debian/control~ 2014-04-11 19:14:31.0 +0200 +++ debian/control 2015-11-09 13:00:41.191097992 +0100 @@ -24,6 +24,7 @@ Suggests: insserv, sysv-rc Breaks: sysvinit-utils (<< 2.88dsf-52) Replaces: sysvinit-utils (<< 2.88dsf-52) +Multi-Arch: foreign Description: run processes in parallel and multiplex their output Used by the sysv-rc boot system executor to run init.d scripts in parallel while making sure the script output is not completely messed up.
Bug#804530: [Pkg-haproxy-maintainers] Bug#804530: Bug#804530: Bug#804530: haproxy: Ensure stop action works on pre-systemd versions of Debian (and Ubuntu)
Hi James, Vincent, On 13:13 Mon 09 Nov , Vincent Bernat wrote: > ❦ 9 novembre 2015 11:51 GMT, James Page : > > > How would you feel about using: > > > > for pid in $(cat $PIDFILE); do > > if start-stop-daemon --help | grep -q "\-\-pid "; then > > start-stop-daemon --quiet --oknodo --stop \ > > --retry 5 --pid $pid --exec $HAPROXY || ret=$? > > else > > if kill -0 $pid 2> /dev/null; then > > /bin/kill $pid || ret=4 > > fi > > fi > > done > > > > This would preserve use of stop-start-daemon if the version installed > > supported --pid, and drop back to the kill approach if not. > > Personally, I find this too hacky and not worth it. For example, if > start-stop-daemon sends its output to stderr (unlikely, but...), this > will break. Or if start-stop-daemon reduces its help message to only a > mention of the manual page. > > Apollon, what do you think? The reason for using start-stop-daemon is two-fold: first of all, it reliably matches the PID with the executable and won't kill unrelated processes. Second, it waits until the process exits, making the initscripts behavior more reliable. IMHO, both reasons are important enough to not revert to the kill loop. If we're going to support this, I would like to avoid parsing program output. We could check the dpkg version (e.g. using dpkg --compare-versions) and fall back to the kill loop if dpkg is older than 1.17.6, or we could keep the loop as is but create a temporary pidfile for each PID and pass the temporary pidfile to start-stop-daemon with `--pidfile` instead of `--pid`. Both approaches sound a bit hackish, but the second is probably less so. Cheers, Apollon
Bug#804530: [Pkg-haproxy-maintainers] Bug#804530: Bug#804530: Bug#804530: haproxy: Ensure stop action works on pre-systemd versions of Debian (and Ubuntu)
On 15:01 Mon 09 Nov , Apollon Oikonomopoulos wrote: > If we're going to support this, I would like to avoid parsing program > output. We could check the dpkg version (e.g. using dpkg > --compare-versions) and fall back to the kill loop if dpkg is older > than 1.17.6, or we could keep the loop as is but create a temporary > pidfile for each PID and pass the temporary pidfile to > start-stop-daemon with `--pidfile` instead of `--pid`. Both approaches > sound a bit hackish, but the second is probably less so. IOW, something along these lines: diff --git a/debian/haproxy.init b/debian/haproxy.init index 35af505..2852efa 100644 --- a/debian/haproxy.init +++ b/debian/haproxy.init @@ -62,8 +62,10 @@ haproxy_stop() ret=0 for pid in $(cat $PIDFILE); do + tmppid="$(mktemp)" start-stop-daemon --quiet --oknodo --stop \ - --retry 5 --pid $pid --exec $HAPROXY || ret=$? + --retry 5 --pidfile "$tmppid" --exec $HAPROXY || ret=$? + rm -f "$tmppid" done [ $ret -eq 0 ] && rm -f $PIDFILE Note that s-s-d has a '--remove-pidfile' option, but this is again too new (>= 1.17.19).
Bug#570623: reprepro: please add multiple version management
we would really like to have this. any updates?
Bug#804542: Use apt-ftparchive instead of dpkg-scansources
Package: local-apt-repository Version: 0.3 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi myself, Felipe Sateler writes in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796549#43 how to use ftp-aptarchive here, which is supposedly better. I should look into this the next time I work on the code. Thanks Felipe, Joachim - -- System Information: Debian Release: stretch/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages local-apt-repository depends on: ii dpkg-dev 1.18.3 ii init-system-helpers 1.24 ii systemd 227-2 local-apt-repository recommends no packages. local-apt-repository suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlZAnzIACgkQ9ijrk0dDIGweKwCfeaGVGaf96vsN8hrDuMqXUR62 5sYAnRHw2Zfa4KKDCrvqRI/xVcd77WZa =Orml -END PGP SIGNATURE-
Bug#790120: praat: sound playback delay, random freeze after about 10-20 playbacks
Control: tags -1 moreinfo Hi Jakob, Could you please check whether the bug persists in version 6.0.4-2 of the package? Thanks, Rafael * Jakob Wiedner [2015-06-27 14:04]: Package: praat Version: 5.4.0-1 Severity: important Dear Maintainer, when playing back a sound file (i tried wav and mp3) in the View/Edit window there is a considerable delay of several seconds. After 2nd or 3rd time the delay disappears and it works fine for several times. Rondomly after 10-20 times, praat freezes entirely and can just be closed by killing it. Terminal output as follows: FIRST PLAYBACK: ALSA lib pcm_dsnoop.c:618:(snd_pcm_dsnoop_open) unable to open slave ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred SECOND PLAYBACK: ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred After that no more delays when playback immediately after. -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages praat depends on: ii libasound2 1.0.28-1 ii libatk1.0-0 2.14.0-1 ii libc62.19-18 ii libcairo21.14.0-2.1 ii libfontconfig1 2.11.0-6.3 ii libfreetype6 2.5.2-3 ii libgcc1 1:4.9.2-10 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-0 2.42.1-1 ii libgtk2.0-0 2.24.25-3 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-01.36.8-3 ii libstdc++6 4.9.2-10 ii oss-compat 6 ii python 2.7.9-1 Versions of packages praat recommends: ii xfonts-100dpi 1:1.0.3 ii xfonts-100dpi-transcoded 1:1.0.3 ii xfonts-75dpi 1:1.0.3 ii xfonts-75dpi-transcoded 1:1.0.3 praat suggests no packages. -- no debconf information
Bug#804543: rkhunter: unhide.rb moved to new pathname, and the whitelist entry should be adapted
Package: rkhunter Version: 1.4.2-4 Severity: normal Hi. Apparently unhide.rb moved from /usr/bin to /usr/sbin, even though its changelog doesn't tell this (CCing Giovani therefore, so he can tell whether this is permanent or just by accident). Therefore rkhunter's previous SCRIPTWHITELIST entry won't work anymore and should be adapted. Cheers, Chris.
Bug#804544: please document the --no-dereference option in the man page
Package: diffutils Version: 1:3.3-2 Severity: minor The --no-dereference option is documented in the info docn and in the --help output, but not in the man page. Perhaps help2man was not run recently enough? Thanks...Marvin -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (200, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages diffutils depends on: ii libc6 2.19-22 diffutils recommends no packages. Versions of packages diffutils suggests: pn diffutils-doc ii wdiff 1.2.2-1 -- no debconf information
Bug#804545: patch jessie version for use with Chromium
Package: libsrtp0 Version: 1.4.5~20130609~dfsg-1.1 Severity: important Tags: security As described in #770659, Chromium is having problems with the standard version of libsrtp0 on jessie. Chromium upstream uses a bundled and patched version of libsrtp0. Chromium packages uploaded to jessie as security updates are not built with the bundled version from upstream though. There is a patch[2] for libsrtp0 that could be adapted for a stable update. Users have been disabling the sandbox in Chromium to work around this issue, hence the security tag has been used. 1. http://anonscm.debian.org/cgit/pkg-chromium/pkg-chromium.git/tree/debian/rules#n61 2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770659#124
Bug#642458: libfarstream-0.2-2 continues with this
reassign 642458 libfarstream-0.2-2 0.2.4-1 reopen 642458 thanks
Bug#804546: piuparts.debian.org: piu-slave-bm-a's stunnel4 process dies (or gets killed) regularly
Package: piuparts.debian.org Severity: normal $ grep -c piu-slave-bm-a.*stunnel4.*CRITICAL.*0.processes irclogs/debian/#debian-admin-bots/2015-* irclogs/debian/#debian-admin-bots/2015-02.log:0 irclogs/debian/#debian-admin-bots/2015-03.log:0 irclogs/debian/#debian-admin-bots/2015-04.log:0 irclogs/debian/#debian-admin-bots/2015-05.log:0 irclogs/debian/#debian-admin-bots/2015-06.log:0 irclogs/debian/#debian-admin-bots/2015-07.log:0 irclogs/debian/#debian-admin-bots/2015-08.log:20 irclogs/debian/#debian-admin-bots/2015-09.log:8 irclogs/debian/#debian-admin-bots/2015-10.log:75 irclogs/debian/#debian-admin-bots/2015-11.log:25 No idea why it dies like that, but this seems to be the only host where it happens. Cheers, Julien signature.asc Description: PGP signature
Bug#804547: [nvidia-driver] Alien: Isolation needs driver version 355.11
Package: nvidia-driver Version: 340.93-7 Severity: normal Dear maintainer(s), Alien: Isolation was released, but sadly it needs nvidia driver version 355.11 or better which is not available yet on Debian. I'm using debian's nvidia packages instead of official nvidia one, because it just works (you've done and still doing a GREAT job!) and I'd like to keep using yours ;-). So, I humbly request you to update nvidia driver (push it to experimental?). Thank you! Yours, BogDan.
Bug#756090: ITA: irker -- submission tools for IRC notifications
On 2015-11-09 05:25:35, Neil Muller wrote: > Has anything further happened here? > > I'm interested in seeing irker stay in debian, and would be willing to > help maintain the package. You're welcome to take over this ITP! A. -- Si l'image donne l'illusion de savoir C'est que l'adage pretend que pour croire, L'important ne serait que de voir - Lofofora
Bug#804542: Use apt-ftparchive instead of dpkg-scansources
On Mon, 09 Nov 2015 14:27:16 +0100 Joachim Breitner wrote:
> Package: local-apt-repository
> Version: 0.3
> Severity: wishlist
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi myself,
>
> Felipe Sateler writes in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796549#43
> how to use ftp-aptarchive here, which is supposedly better. I should
> look into this the next time I work on the code.
Attaching full patch here for completeness.
Saludos
From d3d993e3fc23510ceddc352ae1ee15f0b7ca8cf4 Mon Sep 17 00:00:00 2001
From: Felipe Sateler
Date: Mon, 9 Nov 2015 10:37:02 -0300
Subject: [PATCH] Use apt-ftparchive from apt-utils
The generated Release file was not valid. Use apt-ftparchive to
offload the responsibility to apt itself.
Since we are now using apt-ftparchive, also use it to generate
both Packages and Sources.
Drop dependency on dpkg-dev as we no longer use anything from there.
Closes: #804542
---
debian/control | 2 +-
rebuild| 16 ++--
2 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/debian/control b/debian/control
index 4234139..d82e98e 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,7 @@ Package: local-apt-repository
Architecture: all
Depends:
systemd,
- dpkg-dev,
+ apt-utils,
${misc:Depends},
Description: Ready to use local apt repository
With this package installed, every Debian package (i.e. a *.deb file) dropped
diff --git a/rebuild b/rebuild
index 9878c47..966a417 100755
--- a/rebuild
+++ b/rebuild
@@ -39,8 +39,8 @@ else
# Relative paths work better than absolute
(cd $REPO
- dpkg-scanpackages -m ../../../$DEBS > $REPO/Packages
- dpkg-scansources ../../../$DEBS > $REPO/Sources
+ apt-ftparchive packages ../../../$DEBS > $REPO/Packages
+ apt-ftparchive sources ../../../$DEBS > $REPO/Sources
) || true
# ^ this can fail during a partial write to the directory (which
# would be detected by the loop), so ignore errors here
@@ -51,12 +51,8 @@ else
fi
-cat > $REPO/Release <<__END__
-Description: Local repository created by local-apt-repository
-Origin: local-apt-repository
-Components: .
-MD5Sum:
- $(md5sum $REPO/Packages|cut -d\ -f1) $(wc -c $REPO/Packages|cut -d\ -f1) Packages
- $(md5sum $REPO/Sources|cut -d\ -f1) $(wc -c $REPO/Sources|cut -d\ -f1) Sources
-__END__
+apt-ftparchive \
+ -o "APT::FTPArchive::Release::Origin=local-apt-repository" \
+ -o "APT::FTPArchive::Release::Description=Local repository created by local-apt-repository" \
+ release $REPO > $REPO/Release
--
2.6.2
Bug#804530: [Pkg-haproxy-maintainers] Bug#804530: Bug#804530: Bug#804530: haproxy: Ensure stop action works on pre-systemd versions of Debian (and Ubuntu)
❦ 9 novembre 2015 15:09 +0200, Apollon Oikonomopoulos : >> If we're going to support this, I would like to avoid parsing program >> output. We could check the dpkg version (e.g. using dpkg >> --compare-versions) and fall back to the kill loop if dpkg is older >> than 1.17.6, or we could keep the loop as is but create a temporary >> pidfile for each PID and pass the temporary pidfile to >> start-stop-daemon with `--pidfile` instead of `--pid`. Both approaches >> sound a bit hackish, but the second is probably less so. > > IOW, something along these lines: > > diff --git a/debian/haproxy.init b/debian/haproxy.init > index 35af505..2852efa 100644 > --- a/debian/haproxy.init > +++ b/debian/haproxy.init > @@ -62,8 +62,10 @@ haproxy_stop() > > ret=0 > for pid in $(cat $PIDFILE); do > + tmppid="$(mktemp)" > start-stop-daemon --quiet --oknodo --stop \ > - --retry 5 --pid $pid --exec $HAPROXY || ret=$? > + --retry 5 --pidfile "$tmppid" --exec $HAPROXY || > ret=$? > + rm -f "$tmppid" > done > > [ $ret -eq 0 ] && rm -f $PIDFILE > > > Note that s-s-d has a '--remove-pidfile' option, but this is again too > new (>= 1.17.19). This one seems good for me too. -- Make your program read from top to bottom. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
