Bug#319346: i386 upload built with experimental's libc6
Hi, 2005-07-24, v keltezéssel 21:43-kor Loïc Minier ezt írta: I think HE uploaded to the delayed queue. If you upload, it's ok, if you don't it's ok. The problem is that I can not upload it, as ftp-master is not reachable. So I think his upload is also a no-go. Have to look after why it is down, what else host I can use for uploading. Regards, Laszlo/GCS
Bug#339596: apt-{src,buid} segfaults
Hi all, As this bug hit me as well, but can not reproduce it anymore, I am curious if anyone still has this bug. Vorlon stated that it may have been due to #336114 , but it is already fixed. OK, gcc-4.0 (4.0.2-4) may not hit testing tomorrow, but can this bug be closed? I am going to close it next weekend if no one objects. Regards, Laszlo/GCS
Bug#705262: unsupportable
Hi Bastian, On Sat, Sep 7, 2013 at 9:47 PM, Bastian Blank wa...@debian.org wrote: The version 0.48 was removed from wheezy because it is unsupportable. In the meantime this is _twenty_ versions behind the last release. This means it is even less supportable. Sure, it's very old. Even if that was a long term support one. Btw, Ceph was not part of Wheezy. Do you mean Jessie? If you don't intend to actually maintain ceph, please orphan the package. Otherwise I may do a NMU with the latest version 0.68 in the next two weeks. Ceph is maintained in the background. There's a more fresh version online[1], a maintaince team formed[2] with the newest stable version in Git[3]. Please contact us before doing an actual NMU. Laszlo/GCS [1] http://www.barcikacomp.hu/gcs/ceph_0.61.7-1.dsc [2] https://alioth.debian.org/projects/pkg-ceph/ [3] http://anonscm.debian.org/gitweb/?p=pkg-ceph/pkg-ceph.git;a=summary -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728580: mongodb/1:2.4.8-2 build reschedule
Hi, Please reschedule autobuild of mongodb 1:2.4.8-2 on armhf, i386 and kfreebsd-i386. The previous build failure caused by a boost1.54 bug[1]. It was fixed and boost1.54 built and uploaded on these architectures. Now mongodb will build fine. Thanks, Laszlo/GCS [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727750 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705262: Please clarify NMU/Upload intentions
Hi Derek, On Thu, Sep 12, 2013 at 2:00 AM, Dererk der...@debian.org wrote: Since I think the essence of this Bug Report is clear for everyone and no objections has been made from any of the parts involved about the version and the status of the Ceph software present at the archive, I would like you to clarify what your intentions are surrounding the NMU request (#714881) or any possible duploads in the closest future. #714881 is already fixed with 0.48-2 , closed the bugreport. Bastian won't NMU Ceph, but started cooperating. He started working on the current pkg-ceph Git tree[1], which is version 0.67.2 . It's the latest stable version. Upstream released 0.68 meanwhile as a development version. Anyway, the current Git package version may not be 100% correct in QA view, but builds and ready for upload. Furthermore, If It's possible for you/pkg-ceph team to provide a time reference of what and when your plans would be taking place, it will be extremely appreciated. The plan is the following. Bastian made correct improvements to the Git tree. I only included only two of his commits as both are same with my previous but uncommitted changes. I may not agree that he joined the -dbg packages, will read policy about it. As far as I can remember, every library should have its -dbg counterpart and not one joined package. His other commits look fine, will merge them. Yesterday I didn't have time, but today will look into it again. Will upload 0.67.2-1 on Friday evening. I'm not sure we should upload development releases. At least not for Sid, but for experimental. Kind regards, Laszlo/GCS [1] http://anonscm.debian.org/gitweb/?p=pkg-ceph/pkg-ceph.git -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705262: Please clarify NMU/Upload intentions
On Fri, Sep 13, 2013 at 2:58 PM, Daniel Swarbrick daniel.swarbr...@profitbricks.com wrote: Actually, 0.67.3 is the latest stable release. It fixes some important performance regressions. http://ceph.com/releases/v0-67-3-dumpling-released/ Indeed. Merged with almost all changes from Bastian to http://anonscm.debian.org/gitweb/?p=pkg-ceph/pkg-ceph.git Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705262: ceph
On Sun, Sep 15, 2013 at 12:00 PM, Bastian Blank wa...@debian.org wrote: Thank you for not Cc-ing me. Can be my fault, I'd the thought as a bugreport owner, you'll get all mails. However there are several problems left: - ceph-common depends on python-flask and python-ceph. Why this is a problem? What I see is that python-flask should be moved to python-ceph . - ceph-common is not _arch-all_, why does it exist? Tools that used by other packages that can be installed independently. Should it be named like ceph-base or ceph-tools? - Why ceph-mds? Ceph has three independent blocks. Metadata servers (-mds) are one of them. Please see the overview[1]. - ceph depends on fdisk, parted and whole lot other crap it does not need. Agree on this. Don't know how it made there. - A lot of Replaces. There were package renames, users may have packages from upstream or Ubuntu. That's make it complex. - python-ceph needs stricter dependencies. Will check. - Split between -java and -jni for no apparent reason, it only add a package to the global index. James? About the debug packages: I can also ask ftp-team to kill it, because it ten packages that can't be used independently fills the package index. Still not sure they should be integrated. In a rush now, may write more later. Laszlo/GCS [1] http://ceph.com/docs/next/cephfs/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725629: vice: sometimes FTBFS making po/potfiles
Hi Steven, On Mon, Oct 7, 2013 at 2:16 AM, Steven Chamberlain ste...@pyro.eu.org wrote: I've been unable to reproduce the issue seen on the buildds despite many repetitions and different values for -j. It's obviously rare as it built on 12 arches first time around. Sure, tried to reproduce it myself as well but couldn't do it. So I have no way to test it, but the following might work: You mean the opposite? There's no Makefile dependency in the vanila source file. I bet you would like to add it. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725539: sqlite: FTBFS: /bin/sh: 1: aclocal-1.13: not found
Hi Hideki,
On Tue, Oct 15, 2013 at 11:54 AM, Hideki Yamane henr...@debian.or.jp wrote:
This FTBFS issue can be fixed easily as attached patch.
Sure, it's easy to fix the current state. However it's not a
solution. Every time aclocal or automake changes, sqlite will break
and only a new sourceful upload can fix it. Needs to drop the version
number from the auto{conf,make} call, maybe cdbs packaging altogether.
Anyway, sqlite is way too long unsupported and needs to be removed
from the archives.
/GCS
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727750: mongodb 1:2.4.6-1 FTBFS caused by boost1.54 bug
reassign 727750 boost1.54 retitle 727750 boost1.54: macro for int128 detection affects 727750 + mongodb thanks boost1.54 has a bug with BOOST_LCAST_HAS_INT128 and gcc 4.7 usage. This makes mongodb FTBFS on 32 bit archs. The attached patch comes from upstream and fixes the build problem (tested on i386). Please include it in the next upload. Thanks, Laszlo/GCS 85160.patch Description: application/mbox
Bug#728580: mongodb: FTBFS on i386
block 728580 by 727750 thanks On Sun, Nov 3, 2013 at 10:31 AM, Ivo De Decker ivo.dedec...@ugent.be wrote: package: mongodb version: 1:2.4.6-1 [...] The latest mongodb upload doesn't build on i386: Fails on all 32 bit archs, due to a bug in boost 1.54 . Please see #727750 [1]. Regards, Laszlo/GCS [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727750 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756582: new syntax error when invoking udevadm test breaks installing/ upgrading
On Thu, Jul 31, 2014 at 6:42 AM, Stefan Lippers-Hollmann s@gmx.de wrote: When upgrading (or installing) fuse 2.9.3-13 to 2.9.3-14, the new postinst fails with: Setting up fuse (2.9.3-14) ... dpkg: error processing package fuse (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: fuse E: Sub-process /usr/bin/dpkg returned an error code (1) [...] Reverting this to udevadm test -a -p fixes the problem again. Right, I shouldn't do after last minute small changes. Will fix it soon. Sorry for the inconvenience, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759956: possible graphicsmagick regression?
Hi Bob, I got a report that drawtiming can't build[1] with newer GraphicsMagick versions. The exact error is: caught Magick++ exception: Magick: Non-conforming drawing primitive definition (text) reported by magick/render.c:3022 (DrawImage) If the following change is made to memory.txt in drawimage then it works. -- cut -- -CS1 = 0, OE = 0, ADDR = . -OE -tOE DATA = ; +CS1 = 0, OE = 0, ADDR = . +OE -tOE DATA = ; -- cut -- Can it be a regression in GraphicsMagick or may be caused by something else? Regards, Laszlo/GCS [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759956 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764130: libdbi1 double free in dbi_shutdown_r
Hi Markus, Sebastian experiencing a double free in libdb1. You can read the details in the bug report[1], but I quote it here. -- cut -- I'm seeing a double-free in dbi_shutdown_r which happens after a connection attempt (using dbi_conn_connect) fails and dbi_conn_close was called. I don't have a full reproduction case yet but I think this is related to the fix for #745980. I *assume* that the following happens: - dbi_conn_open adds the new connection to an internal list (using _update_internal_conn_list) - dbi_conn_connect does not touch that list - when calling dbi_conn_close after connect failed (supposedly conn-connection == NULL), the connection is not removed since dbi_conn_close returns early but after freeing the connection object (_update_internal_conn_list would only happen when not returning early) - when calling dbi_shutdown_r, the connection is still in the internal list and another attempt to close the connection is done causing an invalid read and the double-free I think the right fix is to not return early at all in dbi_conn_close but instead guard each single operation by checking if the required fields are set (similar to how it's done in most cases already). Let me know if you need any other information -- I can then try to come up with a small test-case which reproduces the problem. -- cut -- Cheers, Laszlo/GCS [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764130 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751498: python-greenlet: FTBFS on arm* due to test failures
On Wed, Oct 8, 2014 at 7:33 PM, Matthias Klose d...@debian.org wrote: reproducible, no difference when building with -O0 or with gcc-4.8. The tests succeed for python3.4. Do you mean that I should tighten the python3 build dependency to 3.4? May you give more pointers why the build fails with other python3 versions? Thanks, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729132: patch: FTBFS due to ed check, with solution
On Mon, Jun 9, 2014 at 3:38 AM, Yunqiang Su wzss...@gmail.com wrote: Which arch are you test it? I have the same problem on mips64el. Tested it on four machines: 2x Sid/amd64, Jessie/amd64 and kFreeBSD/i386 . Please prove somehow this FTBFS first that set it to severity serious. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751878: FTBFS from source on i386 but successfully built in the past
On Tue, Jun 17, 2014 at 2:25 PM, Cyril Brulebois k...@debian.org wrote: Michael Biebl bi...@debian.org (2014-06-17): Source: sqlite3 Version: 3.8.5-1 Severity: serious The current version of sqlite3 FTBFS on i386. See https://buildd.debian.org/status/package.php?p=sqlite3suite=sid I'm aware of it and investigated already. It failed to build on all x86 architectures. tcl8.6 ships under /usr/lib/i386-linux-gnu/tcl8.6, rather than /usr/lib/i486-linux-gnu/tcl8.6; switching the --with-tcl path from DEB_HOST_GNU_TYPE to DEB_HOST_MULTIARCH makes the package build on i386. I'm not sure about the other settings; especially: passing --build and --host unconditionally was discouraged at some point because that enabled cross-compilation mode even when that wasn't needed. Yup, got the same here, just not uploaded. Now re-tested and will do it soon. Anyway, tclConfig.sh is available from /usr/lib/tcl8.6/ as well with the same trick above. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746887: Fix for the FTBFS
Hi Thomas, On Mon, Jun 16, 2014 at 6:25 PM, Thomas Goirand z...@debian.org wrote: FYI, the only thing that needs to be done is to add -Wno-unused-function in SConstruct, as per the attached patch. I'm uploading this fix to the DELAYED/7 queue, because otherwise the package may be removed from testing (in 13 days now...). Yes, I know that -Wno-unused-function solves this. I would better solved this with effectively disable the unused function(s) only than hiding everything. But well, that would need to check and alter the upstream source constantly. I accept this for now. Cheers, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746887: Fix for the FTBFS
On Mon, Jun 23, 2014 at 8:26 PM, Thomas Goirand z...@debian.org wrote: On 06/24/2014 01:50 AM, László Böszörményi (GCS) wrote: Yes, I know that -Wno-unused-function solves this. I would better solved this with effectively disable the unused function(s) only than hiding everything. But well, that would need to check and alter the upstream source constantly. I accept this for now. I of course would welcome a better fix as well. However, I do believe this should be the job of the upstream for mongodb. Maybe you could ping them (with a list of functions to remove)? Sure, upstream should track if a function is still in use or not. But there's no reason to ping them about this for the 2.4.10 release. They have a completely reworked new major production release 2.6.3 and the development release is 2.7.2 ATM. I don't think they care 2.4.x releases anymore. :-| Will upload the fixed 2.4.10 for Debian soon. Cheers, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736656: libdbi-drivers: drivers not found anymore, due to multi-arch
Hi, On Sat, Jan 25, 2014 at 8:46 PM, Gergely Nagy alger...@madhouse-project.org wrote: Source: libdbi-drivers Version: 0.9.0-1 Severity: grave Justification: renders package unusable libdbi1 0.9.0-1 is built with a multi-arch, and will search for drivers in a multi-arch directory, but the binaries produced from libdbi-drivers still produce packages that use the old, non-multiarch directory. This renders any software using libdbi unusable, as they will not be able to find drivers. I've multi-arched the package[1]. git.debian.org has problems again, it can't find the Git tree. :( Please test it and I'll upload if I get some reviews. I need to test it as well. Will add back Thomas as uploader if he agrees. Laszlo/GCS [1] dget -x http://www.barcikacomp.hu/gcs/libdbi-drivers_0.9.0-2.dsc -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736656: libdbi-drivers: drivers not found anymore, due to multi-arch
Hi Prach,
On Mon, Jan 27, 2014 at 12:37 PM, Prach Pongpanich prach...@gmail.com wrote:
On Mon, Jan 27, 2014 at 5:08 PM, László Böszörményi (GCS)
g...@debian.org wrote:
I've removed debian/*.dir files, which created an empty directory
(usr/lib/dbd ).
We don't want to run sqlite and sqlite3 tests[1] when cross-building,
I attached a patch for both issues.
[1] https://buildd.debian.org/status/package.php?p=libdbi-driverssuite=sid
You made the diff in the wrong, backward way. As such, it tries to
add the mentioned dir files. Btw thanks, those files indeed need to be
removed.
The mentioned page shows only the architectures that officially part
of Debian. They are _not_ cross-builds but native to those
architectures. I suppose you meant that don't run any tests when
DEB_BUILD_OPTIONS instructs so.
This is not the case for buildds. Those should run self-tests to early
reveal platform specific bugs.
P.S. please you set me as Maintainer to avoid missing an e-mail from the BTS.
Only one person can be the maintainer. You should get bugreports as
uploader or you may subscribe to the source packages of your
choice[2].
Thomas, are you in? Do you have experience with such Sqlite{,3} build
failures? Seems to be related to the 'long long' data type.
Cheers,
Laszlo/GCS
[2] http://packages.qa.debian.org/common/index.html
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736656: libdbi-drivers: drivers not found anymore, due to multi-arch
On Tue, Jan 28, 2014 at 2:33 PM, Prach Pongpanich prach...@gmail.com wrote: On Tue, Jan 28, 2014 at 1:30 PM, László Böszörményi (GCS) g...@debian.org wrote: I've discussed with Markus Hoenicka and he told me about a atoll() call which the sqlite3 driver uses to convert raw data into a long long number causes problems, he will work on this problem. drivers/sqlite3/dbd_sqlite3.c: 1719:data-d_longlong = (long long) atoll(raw); break; /* hah, wonder if that'll work */ No wonder, as GNU libc manual[1] on parsing integers states: Function: long long int atoll (const char *string) This function is similar to atol, except it returns a long long int. The atoll function was introduced in ISO C99. It too is obsolete (despite having just been added); use strtoll instead. Thus atoll is deprecated in favour of stroll. Hope if it this change will be made, then the compilation issue will be solved. Prach, if you have connection with Markus Hoenicka then may you send him the URL I've mentioned? Algernon, if I code a small converter, can you test it on Sparc (if you have any nearby at your workplace)? Regards, Laszlo/GCS [1] http://www.gnu.org/software/libc/manual/html_node/Parsing-of-Integers.html -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737126: Bug#736656: libdbi-drivers: drivers not found anymore, due to multi-arch
On Fri, Jan 31, 2014 at 9:04 AM, Markus Hoenicka
markus.hoeni...@mhoenicka.de wrote:
Problem is that I'm not aware of similar limits for floats. Do you
know where to get this info from at compile time?
Attached a sample. Basically those are: FLT_MAX, DBL_MAX and LDBL_MAX.
Laszlo/GCS
#include stdio.h
#include stdlib.h
#include float.h
int main(void) {
printf(float neg: %f\n, -FLT_MAX);
printf(float min: %f\n, FLT_MIN);
printf(float max: %f\n, FLT_MAX);
printf(double neg: %lf\n, -DBL_MAX);
printf(double min: %lf\n, DBL_MIN);
printf(double max: %lf\n, DBL_MAX);
printf(long double neg: %Lf\n, -LDBL_MAX);
printf(long double min: %Lf\n, LDBL_MIN);
printf(long double max: %Lf\n, LDBL_MAX);
return EXIT_SUCCESS;
}
Bug#737144: cvs2svn: FTBFS with rcs 5.9
Hi Michael, Stephen, On Mon, Feb 3, 2014 at 1:56 PM, Michael Haggerty mhag...@alum.mit.edu wrote: On 01/30/2014 05:01 PM, Stephen Oberholtzer wrote: Package: cvs2svn Version: 2.4.0 Severity: serious Tags: patch [...] The cvs2svn package fails to build from source with recent versions of rcs due to a failed internal test. This is caused by the rcs v5.9 'co' command deprecating '-V' in favor of '--version'. When cvs2svn executes 'co -V' to test for its existence, co outputs a warning on stderr, which cvs2svn mistakes for a failure. Attached is a patch that corrects this problem, so that the package builds. Maybe an other thing changed since then, but last time I tried your patch cvs2svn self-tests still failed. I am the upstream maintainer of cvs2svn. The change that you have proposed was made in cvs2svn trunk in December 2013. So I agree that it is OK. Do you have a list what's changed since 2.4.0 in the trunk? If it would be helpful, I could make an upstream release from the current trunk version (i.e., including this change). I'll retry building of cvs2svn with the proposed patch and report back if I get a test failure and its details or simply upload a fixed packaged with that change. You don't have to make a new upstream release if it's not the time yet. Ie not stable enough or just not really tested, etc. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737144: cvs2svn: FTBFS with rcs 5.9
On Tue, Feb 4, 2014 at 2:09 PM, Michael Haggerty mhag...@alum.mit.edu wrote: On 02/04/2014 01:44 PM, László Böszörményi (GCS) wrote: On Mon, Feb 3, 2014 at 1:56 PM, Michael Haggerty mhag...@alum.mit.edu wrote: On 01/30/2014 05:01 PM, Stephen Oberholtzer wrote: Attached is a patch that corrects this problem, so that the package builds. Maybe an other thing changed since then, but last time I tried your patch cvs2svn self-tests still failed. Just tried again. Version 2.4.0 with the patch applied still fails with: -- cut -- PASS: run-tests.py 3: generate a manpage for cvs2git SKIP: run-tests.py 4: generate a manpage for cvs2hg unexpected log output (missing changed paths) Line: ' ' EXCEPTION: SystemExit(1), skipping cleanup FAIL: run-tests.py 5: detection of the executable flag -- cut -- Installed versions: Subversion is 1.8.5 CVS is 1.12.13+real-11 rcs is 5.9.2 python is 2.7.6 There's not a lot of activity in the project so it is relatively arbitrary when to make a release. But if you don't need one then I'll gratefully spare myself the effort :-) May you check what can be the problem in the above mentioned configuration? Thanks, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737144: cvs2svn: FTBFS with rcs 5.9
On Wed, Feb 5, 2014 at 12:17 PM, Michael Haggerty mhag...@alum.mit.edu wrote: On 02/05/2014 11:44 AM, László Böszörményi (GCS) wrote: Just tried again. Version 2.4.0 with the patch applied still fails with: -- cut -- PASS: run-tests.py 3: generate a manpage for cvs2git SKIP: run-tests.py 4: generate a manpage for cvs2hg unexpected log output (missing changed paths) Line: ' ' EXCEPTION: SystemExit(1), skipping cleanup FAIL: run-tests.py 5: detection of the executable flag -- cut -- This test works for me. My guess is that either the package itself or the test's temporary files are on a filesystem that does not allow the executable bit to be set. Not the case. I've one partition for everything (this is a test environment). $ mount | grep ' / ' /dev/sdb1 on / type ext4 (rw,errors=remount-ro) $ mount | grep noexec [ shows the usual drill, /proc , /sys , /run and /dev/pts ] ~/test/cvs2svn-2.4.0 $ rm -f ./test.sh echo 'echo works!' test.sh chmod a+x ./test.sh ./test.sh works! In short, the fs has the executable bit allowed (otherwise my whole system would just break), and testing +x with a shell script in the cvs2svn build directory succedded. Will try to get a more verbose output of the python test, why it fails. So if indeed the Debian test infrastructure does not allow the executable bit to be set, the only alternative would be to skip this test on your setup. If the limitation is on the input then something like this should do the trick: [...] If the limitation is on the output directory, then we would probably have to try setting the executable bit on some file to see if it is allowed. None the case, see the tests above. Especially that the mentioned file is: ~/test/cvs2svn-2.4.0 # ls -l ./test-data/main-cvsrepos/single-files/attr-exec,v -rwxr-xr-x 1 1000 1000 424 Oct 8 2007 ./test-data/main-cvsrepos/single-files/attr-exec,v Thus it _has_ the a+x set. First I thought the missing go+w bits may cause problems. Then # chmod 0777 ./test-data/main-cvsrepos/single-files/attr-exec,v # rerun the build and test process, still fails the exact same way # ls -l ./test-data/main-cvsrepos/single-files/attr-exec,v -rwxrwxrwx 1 1000 1000 424 Oct 8 2007 ./test-data/main-cvsrepos/single-files/attr-exec,v Now it has all rights a normal user may have, but still can't get that the +x is indeed set on that file. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737144: cvs2svn: FTBFS with rcs 5.9
On Wed, Feb 5, 2014 at 12:17 PM, Michael Haggerty mhag...@alum.mit.edu wrote: On 02/05/2014 11:44 AM, László Böszörményi (GCS) wrote: Just tried again. Version 2.4.0 with the patch applied still fails with: -- cut -- PASS: run-tests.py 3: generate a manpage for cvs2git SKIP: run-tests.py 4: generate a manpage for cvs2hg unexpected log output (missing changed paths) Line: ' ' EXCEPTION: SystemExit(1), skipping cleanup FAIL: run-tests.py 5: detection of the executable flag -- cut -- Installed versions: Subversion is 1.8.5 CVS is 1.12.13+real-11 rcs is 5.9.2 python is 2.7.6 This test works for me. Did some debugging with: # ./run-tests.py --verbose 5 [ lots of normal looking output, but fails ] I've found out that it fails in run-tests.py line 360 as indeed, the output it checks doesn't contain any 'Changed paths:' line. So every 'rnumber | author | ...' line should be followed by a line 'Changed paths:' with the files changed in that particular revision. There's an exception. Maybe it's due to a newer Subversion release (as previously mentioned, I use 1.8.5). But r6 looks like this: -- cut -- r6 | jrandom | 1995-12-30 18:37:22 + (Sat, 30 Dec 1995) | 2 lines Remove the file 'first' again, which should have no effect. -- cut -- All other revisions are OK, like r7: -- cut -- r7 | jrandom | 1996-08-20 23:53:47 + (Tue, 20 Aug 1996) | 5 lines Changed paths: D /trunk/full-prune [...] -- cut -- I suspect r6 is right, as the note tells removing the same file named 'first' twice should have no output. Hence no 'Changed paths:' is mentioned in the output. The test itself has the fault. Hope this helps, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738507: src:sqlite3: Fix broken cross-compilation with multiarch Tcl
severity 738507 important thanks Hi Christian, On Mon, Feb 10, 2014 at 6:08 AM, Christian Svensson deb...@cmd.nu wrote: Package: src:sqlite3 Version: 3.8.2-1 Severity: serious Tags: patch Justification: fails to build from source With the new tcl8.5 in experimental the flags passed to configure must be updated. This patch does just that. Thanks for the heads-up. While experimental is integral part of Debian, please don't file serious bugs that related only to that. The version in unstable builds fine in an up-to-date environment. Also included is a small patch to remove chrpath usage on cross compilation. For the case x86_64 - or1k chrpath does not handle the ELF format and fails. Still, other cross compilations like x86_64 - armel should remove the rpath I guess. Never tested that way, but may try it this week. Any ETA when the new Tcl package will hit unstable? Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737126: Bug#736656: libdbi-drivers: drivers not found anymore, due to multi-arch
Hi Markus, On Fri, Jan 31, 2014 at 11:20 AM, Markus Hoenicka markus.hoeni...@mhoenicka.de wrote: Am 2014-01-31 10:48, schrieb László Böszörményi: On Fri, Jan 31, 2014 at 9:04 AM, Markus Hoenicka markus.hoeni...@mhoenicka.de wrote: Problem is that I'm not aware of similar limits for floats. Do you know where to get this info from at compile time? Attached a sample. Basically those are: FLT_MAX, DBL_MAX and LDBL_MAX. Ah, I see. I'll see if I can come up with a fixed testkit. Any progress? More than two weeks passed. I may just disable those problematic tests as libdbi-drivers itself works as expected. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745439: pyro4: doesn't include the actual pyro4 library files for python 2.x
severity 745439 normal thanks Hi Irmen, On Mon, Apr 21, 2014 at 8:19 PM, Irmen de Jong ir...@razorvine.net wrote: when installing the pyro4 package there won't be any actual pyro4 library files installed for python 2.7 I.e. dpkg-query -L pyro4 only lists a few things in /etc and /usr, and 'import Pyro4' will obviously fail under python (2.7) Sure, as pyro4 is only a meta-package. It depends either on python2-pyro4 or python3-pyro4 . I noticed that the python3-pyro4 package was installed as a dependency (not sure why) and that one does include the proper library files. dpkg-query -L python3-pyro4 does indeed list the pyro4 library under /usr/lib/python3. Yes, python3-pyro4 is the Python 3.x variant of your package. I expected the pyro4 library files to be installed somewhere in /usr/lib/python2.7 Please install python2-pyro4 for this. I didn't expect the python3-pyro4 package to be installed as a dependency I'll make more clear with the next upload that pyro4 is only a virtual package that depends on the actual version of Pyro 4.x . However you are right with the missing 'serpent' serializer. Will package that soon. Thanks for your reports, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749786: mongodb: FTBFS on kfreebsd-i386 (test failures)
Hi Julien, On Thu, May 29, 2014 at 9:36 PM, Julien Cristau jcris...@debian.org wrote: Source: mongodb Version: 1:2.4.10-1 Actually it's 1:2.4.10-1+b1 , the above mentioned version did compile successfully. mongodb failed to build on a kfreebsd-i386 buildd, see the log at https://buildd.debian.org/status/fetch.php?pkg=mongodbarch=kfreebsd-i386ver=1%3A2.4.10-1%2Bb1stamp=1401276241 The testsuite is not as robust as it should be and sometimes fails on kfreebsd-i386. I did some investigation on my amd64 and it seems the cause is the disk space is running out (it needs several gigabytes). Then the daemon for the test stops working and other processes trying to send data to it fail. The build is OK otherwise. What may be the best long term solution? Reschedule the build on kfreebsd-i386, do a local build with enough disk space and upload or just disable the testsuite on kfreebsd-i386? Cheers, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732406: graphicsmagick: FTBFS (test failure in t/ps/read.t)
On Tue, Dec 17, 2013 at 9:12 PM, Cyril Brulebois k...@debian.org wrote: another fallout from freetype's going crazy… Freetype support gets disabled, a different code path is hit, and kaboom; see changelog entry in the attached patch for a detailed explanation. Laszlo, I'll be uploading a fixed package to DELAYED/2. Please let me know if I should reschedule it to DELAYED/0 or DELAYED/some-more. Please give me two hours and I'll upload a fixed package. No need for an NMU. Thanks, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735501: Sourceless file
tags 735501 + confirmed thanks Hi, You are right, I've to delete it from the binary package and link it to the packaged jquery-ui.js if possible. Should I repack the source? Release 1.5.0 is _not_ DFSG free and should not be packaged. I'm waiting for upstream to release 1.5.1 for a while. I hope it will happen soon. May I wait for it or should I act promptly? Thanks, Laszlo/GCS On Wed, Jan 15, 2014 at 10:07 PM, bastien ROUCARIES roucaries.bast...@gmail.com wrote: I could not find the source of: share/www/script/jquery-ui-1.8.11.custom.min.js -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733496: Code copy of older Mozilla code
On Thu, Feb 27, 2014 at 8:17 AM, Vincent Cheng vch...@debian.org wrote: On Wed, Feb 26, 2014 at 11:09 PM, Emilio Pozuelo Monfort po...@debian.org wrote: Have you seen #739132 ? Do you have any plans to upload mozjs 24? Given mozjs17 hasn't entered testing and has very few rdeps, maybe we could go directly for mozjs24 and work towards getting rid of mozjs17 and mozjs185 (to avoid having several mozjs in testing / stable). I thought Mike would take mozjs24, but it seems I was wrong. I have no plans to upload mozjs 24 (I'd rather not maintain it by myself), but if the iceweasel and/or gnome maintainers would like a helping hand or even a co-maintainer, I'd be glad to help. If none wants to maintain it in the first place, I may upload it on Sunday. I'll need it anyway. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741020: mongodb-server: Does not install
Hi Mike, On Fri, Mar 7, 2014 at 2:45 PM, Mike Dupont jamesmikedup...@googlemail.com wrote: Subject: mongodb-server: Does not install Package: mongodb-server Version: 1:2.4.9-1 Justification: renders package unusable Severity: grave Please be more specific. Just purged - installed it on amd64. It works for me. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741020: mongodb-server: Does not install
retitle 741020 mongodb-server: dpkg fails with error when insufficent diskspace to start severity 741020 normal merge 741020 704778 thanks On Fri, Mar 7, 2014 at 3:11 PM, Mike Dupont jamesmikedup...@googlemail.com wrote: Ok, I see the error now : Fri Mar 7 07:43:07.964 [initandlisten] ERROR: Insufficient free space for journal files Fri Mar 7 07:43:07.964 [initandlisten] Please make at least 3379MB available in /var/lib/mongodb/journal or use --smallfiles It's an upstream thing. They need such amount of free space for proper working of mongodb-server. I don't think I can do much about this. :-| looks like a duplicate Yes, merging them. Cheers, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764493: python-eventlet 0.15.2-1 to Sid/Jessie
Hi, Thomas packaged v0.15.2 and uploaded to experimental. In my opinion it should be uploaded to Sid and let migrate to Jessie. The rationale behind is the following: - it handles connection socket timeouts and contains several bugfixes[1] without adding too much new code, - it doesn't have any bugreports against experimental, - it's part of Fedora 20 and 21, as well as RHEL7 as EPEL (extra package repository)[2] without any problem. The sslwrap.diff fix that Matthias adds in #764493 [3] still applies however. Should I upload it or do you have objections? Cheers, Laszlo/GCS [1] https://github.com/eventlet/eventlet/blob/master/NEWS [2] http://pkgs.fedoraproject.org/cgit/python-eventlet.git [3] https://bugs.debian.org/764493 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765812: GNOME Evolution SIGSEGV with SQLite3 3.8.7
Hi, On Sat, Oct 25, 2014 at 12:01 PM, Paul Menzel pm.deb...@googlemail.com wrote: Am Samstag, den 18.10.2014, 15:32 +0200 schrieb Pascal Obry: Package: evolution Version: 3.12.7-1 I'm on Debian/sid with all packages up-to-date. After upgrading SQLite3 this morning from 3.8.6-1 to 3.8.7-1 GNOME Evolution crashes with a segmentation violation. [...] The bug upstream was reported upstream in the GNOME bug tracker Bugzilla as #738965 [1], where it has been analyzed with the help of the SQLite developer Mr Hipp leading to a fix by Milan. I update the meta data of this (Debian) bug report accordingly. The severity was raised to critical to prevent the migration to testing Unfortunately applying this patch to Debian is not enough, I believe as the appropriate `Breaks` and `Conflicts` tags with `libsqlite3-0` have to be set. Quite the contrary. Evolution doesn't break SQLite3, but the latter may show that it breaks evolution-data-server without the fix. Please apply that to the package and do an upload. Then I can add the breaks field to libsqlite3-0. Laszlo, does the `libsqlite3-0` package also require changes to map these problems? In any case, libsqlite3-0 3.8.7 should not migrate to testing before this bug has been solved in Debian. As I read, SQLite3 itself is correct in every aspect. It's Evolution that doesn't use it correctly ATM. With the patch it should work as expected. Thanks for the heads-up, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766911: ntfs-3g: .
severity 766911 important tags 766911 + moreinfo unreproducible thanks Hi Eric, On Sun, Oct 26, 2014 at 8:40 PM, Eric Moors bugrep...@someren.nl.eu.org wrote: * What led up to the situation? a simple apt-get upgrade Do you know which was the previous version? * What exactly did you do (or not do) that was effective (or ineffective)? mount the drive (mount -t ntfs-3g /dev/sda1 /mnt ls /mnt (also other actions, mkdir, mv, and cp fail with an I/O error) Please try them separate and post what's the mount output. * What was the outcome of this action? this results in a a I/O error Can it be that the disk is failing or the NTFS is dirty in any way? What happens if you reboot into windows? Kernel: Linux 2.6.32-trunk-486 Do you still have a 486 CPU? How comes that you have such an old kernel? Please upgrade to a more modern one and report back. It can be that ntfs-3g does not support such old kernels. Thanks, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607969: sqlite: Still useful?
On Wed, Oct 29, 2014 at 10:33 AM, Balint Reczey bal...@balintreczey.hu wrote: On Mon, 4 Aug 2014 20:08:21 +0100 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: I stumbled upon this bug by chance when looking at why it did not compile in some new ports. It should compile on all of them by now. The buildd archive shows that arm64 and ppc64el are fine, even mips and sparc. I guess that it's better to just ask FTP masters to remove the package, but I'll leave that to other people, since they were interested in doing that in the past (all in copy now). Yes, I was about to ask its removal as upstream no longer supports it. But it works correctly and I got personal mails that they would still use it on low-end (embedded?) machines where sqlite3 would require more CPU and/or memory. Filing bugs against reverse dependencies to migrate to sqlite 3 would be a better start IMO. I've mailed all of them some years ago, but there are still some use it. Probably it is too late to convert everything for Jessie: It is late. Dear Release Team, should this package be released with Jessie? I'm open for everything, but please do note that the removal would mean removing the dependent packages as well. Cheers, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768393: sqlite3: segmentation fault in evolution caused by calling NULL xFetch method
On Fri, Nov 7, 2014 at 1:47 AM, Josh Triplett j...@joshtriplett.org wrote: Package: libsqlite3-0 Version: 3.8.7-1 Severity: grave Tags: patch Control: affects -1 evolution I have a massive email folder in Evolution. Recently, I started encountering segmentation faults every time I accessed that folder (opened it, tried to copy mail into it, etc). Running evolution under gdb turned up a backtrace leading to the call to xFetch in sqlite3OsFetch (by way of vdbeSorterExtendFile), with a NULL xFetch function pointer. It is already known and evolution itself[1] use the mentioned function call in a bad way. See their fix[2] for the issue. The evolution package needs update (as well). Regards, Laszlo/GCS [1] https://bugzilla.gnome.org/show_bug.cgi?id=738965 [2] https://git.gnome.org/browse/evolution-data-server/commit/?id=01cd4a6 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768393: sqlite3: segmentation fault in evolution caused by calling NULL xFetch method
severity 768393 important affects 768393 - evolution thanks On Fri, Nov 7, 2014 at 1:47 AM, Josh Triplett j...@joshtriplett.org wrote: I have a massive email folder in Evolution. Recently, I started encountering segmentation faults every time I accessed that folder (opened it, tried to copy mail into it, etc). Running evolution under gdb turned up a backtrace leading to the call to xFetch in sqlite3OsFetch (by way of vdbeSorterExtendFile), with a NULL xFetch function pointer. As noted, it's Evolution that didn't use correctly that function. Upstream patch exists and the fixed package just uploaded and accepted for Jessie. I'm going to apply the sqlite3 fix that don't let the misuse that function for Jessie. Until then, it's no longer affects Evolution and not an RC. Thanks, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767028: Bug#754789: ovirt-guest-agent: fails to install
retitle 767028 ovirt-guest-agent: doesn't work on hosts severity 767028 important thanks Resend as I used a wrong bug number. On Sun, Nov 16, 2014 at 8:10 AM, László Böszörményi (GCS) g...@debian.org wrote: On Mon, Jul 14, 2014 at 1:04 PM, Holger Levsen hol...@layer-acht.org wrote: during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. Sure, it doesn't install on hosts and it'll be fixed. As the package name reveals, it's an oVirt agent for _guests_ and not meant for hosts. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770330: [Android-tools-devel] Bug#770330: how to change UID_MIN, UID_MAX, FIRST_GID, LAST_GID, etc.?
On Tue, Nov 25, 2014 at 12:05 PM, Hans-Christoph Steiner h...@eds.org wrote: android-permissions integrates the Android permissions into a Debian chroot running on Android. This package should only ever run on a Debian chroot running with an Android kernel. It should modify things like GID_MAX or LAST_GID in /etc/login.defs and /etc/adduser.conf to reflect the hard-coded Android UIDs and GIDs, but it is a policy violation for a package to modify those files. Any suggestions as how to best tackle this issue? I need to investigate, but I think policy only forbids modification of the these files on a normal system. If you or the package create a chroot and modify these files in it, then it's normal if I ask me now. You can check if chrooted with the following code snippet (run as root): -- cut -- if [ $(stat -c %d:%i /) != $(stat -c %d:%i /proc/1/root/.) ]; then echo We are chrooted! else echo Business as usual fi -- cut -- I think if you run on an Android device, then 'getprop ro.build.version.release' should give you its version number, otherwise should be empty or getprop not even installed. These should help you, can't test it right now. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771341: segfaults in sqlite3_value_type while using from Python
On Fri, Nov 28, 2014 at 5:50 PM, Yaroslav Halchenko
deb...@onerussian.com wrote:
Package: libsqlite3-0
Version: 3.7.13-1+deb7u1
Severity: serious
Originally detected I believe on sid installation, but forgot to capture the
version, I will try to replicate/report later. But very consistent with
wheezy
(from which I am reporting now).
May you give me some details how it happened in Sid?
Triggered by the backport fail2ban 0.9.1-1~nd70+1 (available from
http://neuro.debian.net/debian-devel/ wheezy/main amd64 Packages apt repo) it
gets to
[...]
The problem is, I don't see the segfault in the mentioned gdb output.
unfortunately we haven't logged the sql queries so not sure on exact one, but
I
think it was this one, which if executed from the shell seems to not cause the
segfault...
n {1..100}; do sqlite3 -list fail2ban.sqlite3 'SELECT ip, timeofban, data
FROM bans WHERE 1 AND jail=sshd AND ip=111.74.239.35 ORDER BY ip,
timeofban' /dev/null echo success; done
Then how often do you get segfault? Do you have any additional
information if it happens in a given daytime, when there are several
bots try to get into your system or anything else?
Please help me to troubleshoot this one if more information is necessary
to point the issue
I'm the SQLite3 maintainer and not the fail2ban one. But please note
the changelog the version you use[1]:
- 0.9 series is quite a big leap in development, especially since 0.8.6
which made it to previous Debian stable wheezy. Please consult upstream
ChangeLog about changes
Did you check it, reviewed your configuration? Does a segfault happen
in other applications that link to SQLite3?
Regards,
Laszlo/GCS
[1] https://packages.qa.debian.org/f/fail2ban/news/20141028T041852Z.html
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734505: Can we close twitter-recess bug #734505?
On Mon, Dec 1, 2014 at 2:39 AM, Julian Taylor jtaylor.deb...@googlemail.com wrote: The package not working for one of its main purposes does qualify as severe to me. I agree. I was suprised that it was working for Martin, glad that you are confirmed that miracle didn't happen. I can accept lowering the severity when the compile option is removed from the debian package with a helpful error message. I don't think it's worth it. It's a dead project for two years[1]. Upstream confirms it works only with 1.3.3 = node-less 1.4 [2] and doesn't respond to bug reports asking for an update[3]. Last commits contain cosmetic changes like update the copyright year to 2013[4] when it's 2015 soon. In short, I don't feel we should carry it around. Ideas / opinions? Laszlo/GCS [1] https://github.com/twitter/recess/releases [2] https://github.com/twitter/recess/commit/b01e288507d1d924833d53475557bdc367abf5c1 [3] https://github.com/twitter/recess/issues/107 [4] https://github.com/twitter/recess/commit/ca8cb2a69d67eb4beb652a7b69581690ae7d -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771719: tcplay: does not support discs with 4k sectors
Hi Ralf, On Mon, Dec 1, 2014 at 10:10 PM, Ralf Jung p...@ralfj.de wrote: tcplay does not properly support discs with 4k sectors: They are opened, but reading from the disc produces wrong results, and writing to the discs results in data the official TrueCrypt cannot read. This can lead to irrecoverable data loss if any writes are performed on the disk. This was reported and fixed upstream a while ago already [1], so I assume version 2.0 (released more than half a year ago) fixed the problem. Yes, it seems it was fixed in 2.0, but it has a somewhat unclear license. I've backported the fix for 1.1. But don't have any 4k discs nearby, can you test it for me? You should build it for yourself[1] and only in the last chance use my own binary packages for amd64[2] or i386[3]. Thanks, Laszlo/GCS [1] dget -x http://www.barcikacomp.hu/gcs/tcplay_1.1-2.dsc [2] http://www.barcikacomp.hu/gcs/tcplay_1.1-2_amd64.deb [3] http://www.barcikacomp.hu/gcs/tcplay_1.1-2_i386.deb -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771341: segfaults in sqlite3_value_type while using from Python
On Sat, Nov 29, 2014 at 4:36 PM, Yaroslav Halchenko y...@debian.org wrote:
On Sat, 29 Nov 2014, László Böszörményi (GCS) wrote:
May you give me some details how it happened in Sid?
ok -- I will try to replicate again under sid (trickier since I have no sid on
publicly bombarded servers)
You may also backport the recent, SQLite3 3.8.7.2-1 upload to your box.
unfortunately we haven't logged the sql queries so not sure on exact one,
but I
think it was this one, which if executed from the shell seems to not cause
the
segfault...
n {1..100}; do sqlite3 -list fail2ban.sqlite3 'SELECT ip, timeofban, data
FROM bans WHERE 1 AND jail=sshd AND ip=111.74.239.35 ORDER BY ip,
timeofban' /dev/null echo success; done
You may try the same loop with a Python script doing the same SQLite3 query.
FWIW -- I am the Fail2ban maintainer... but fail2ban is just a 'trigger'
here -- it is a purely Python implementation so either it is sqlite3 or python
bindings which are at fault here
Then I do wonder why do you use an unofficial fail2ban backport
instead of doing it yourself.
Cheers,
Laszlo/GCS
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772794: qpid-cpp: Multiple security issues
Hi Moritz, On Thu, Dec 11, 2014 at 7:50 AM, Moritz Muehlenhoff j...@inutil.org wrote: The version in sid is fairly old and several security issues have piled up. The Red Hat bugs provides more information: You are right. Investigating. But as you mentioned, it's only in Sid and doesn't affect Jessie. Packaging the latest version should be the best path. Thanks, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751498: closed by Laszlo Boszormenyi (GCS) g...@debian.org (Bug#751498: fixed in python-greenlet 0.4.5-1)
Hi Bálint, On Fri, Dec 19, 2014 at 10:21 PM, Balint Reczey bal...@balintreczey.hu wrote: T-p-u sounds a bit better, do you plan going this way? If you don't have time now I would happily fix this in an NMU. I'm away from home, actually I'm at Budapest. Will leave tomorrow in the afternoon. Until then we may meet somewhere. But to answer your question, I'll arrive back home in the evening and will prepare the fixed package. Hopefully it will be allowed to t-p-u. Cheers, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751498: closed by Laszlo Boszormenyi (GCS) g...@debian.org (Bug#751498: fixed in python-greenlet 0.4.5-1)
Hi Bálint, On Fri, Dec 19, 2014 at 10:21 PM, Balint Reczey bal...@balintreczey.hu wrote: On Sat, 15 Nov 2014 13:49:10 +0100 Ivo De Decker iv...@debian.org wrote: The arm* build failure is fixed by this patch from ubuntu (tested on abel): http://patches.ubuntu.com/p/python-greenlet/python-greenlet_0.4.2-1ubuntu1.patch T-p-u sounds a bit better, do you plan going this way? If you don't have time now I would happily fix this in an NMU. I've updated the package[1]. Can someone test it on any ARM architecture to see if it builds correctly? Will ask the Release Team for a t-p-u upload. Thanks, Laszlo/GCS [1] dget -x http://www.barcikacomp.hu/gcs/python-greenlet_0.4.2-2.dsc -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764493: python-eventlet 0.15.2-1 to Sid/Jessie
Hi Ivo, On Wed, Dec 24, 2014 at 5:52 PM, Ivo De Decker iv...@debian.org wrote: On Fri, Nov 14, 2014 at 11:12:22PM -0500, Scott Kitterman wrote: Now that we are in Freeze, this is pretty unlikely. Any objection to just uploading the Ubuntu patch so we can close the RC bug? This looks like the obvious way to go. Laszlo, what do you think? Prepared the updated package. Final and clean build is in progress, when it's done I'll upload it to Sid. Then I can ask for a freeze exception and let it migrate to Jessie. Cheers, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775639: neon27: FTBFS in jessie: tests failed
Control: tag -1 unreproducible Hi Lucas, On Sun, Jan 18, 2015 at 1:47 AM, Lucas Nussbaum lu...@lucas-nussbaum.net wrote: Source: neon27 Version: 0.30.1-1 Severity: serious Tags: jessie sid During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): [...] redirect.. 6/ 6 FAIL - no_redirect (did not get NE_REDIRECT) redirect.. 6/ 6 redirect.. 5/ 6 passed, 1 failed [...] make[2]: *** [check] Error 1 Just updated my pbuilder Jessie chroot on amd64. Tried to reproduce it several times with and without network access. The package built fine every time. Then tried in a Sid chroot and it built fine there as well (again with and without network access). I don't know what the problem can be in your setup. About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. May you give me more details about it? When it was last updated, its full package list, if it has /proc mounted and CPUs allocated for your instance? Is there any way for me to manually log in and try the build? Did the build fail all the time or only at this, reported time? Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775689: Do NOT use unetbootin for Debian CD images
Control: tag -1 moreinfo Hi Steve, On Sun, Jan 18, 2015 at 7:06 PM, Steve McIntyre st...@einval.com wrote: Source: unetbootin Severity: serious Tags: d-i Justification: wasting massive amounts of developer and user time I've already added one wishlist bug for d-i to add code to detect unetbootin usage and complain about it, but I've not got there yet. unetbootin used to be a helpful tool for many people to create USB-bootable installer images, but these days seems responsible for lots of user problems and difficult-to-resolve bug reports. Using it for Debian CD images creates USB images that do not work correctly. It's not even needed any more - we've been making working iso-hybrid images for years now. Can you give me pointers where those bugreports exist? Do you have first hand experience that it's not working correctly? I made netboot images onto my USB sticks and they worked. Especially that it's not the same like copy the iso over the USB drive. Its non-destructive install doesn't format the device, you may use that for storage as well. Also please note it's not a Debian specific tool. But it may exists in Fedora as well for example. Those users may install a Debian boot to their USB sticks. Adding a warning for our users won't warn other users using UNetbootin. Kind regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776257: Fails to apply patch with dangling symlink
Control: tags -1 upstream Hi, On Wed, Jan 28, 2015 at 8:10 AM, Martin Pitt mar...@piware.de wrote: Michael Biebl [2015-01-26 1:55 +0100]: the latest update of patch broke the systemd package and causes it to FTBFS: BTW, at least glibc is also affected, and judging by the recent slew of autopkgtest failures in Ubuntu there's some more. We really need to get this fixed fast. There were several security flaws in patch recently. One of these is the possibility of writing arbitrary files via a symlink attack in a patch file _and_ directory traversal via symlinks. It is named as CVE-2015-1196[1]. Upstream fixed it and I've uploaded it. It seems upstream put too much restriction on symlinks, Cc-ing him. But will investigate this myself as well in the afternoon. Regards, Laszlo/GCS [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1196 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767028: ovirt-guest-agent: fails to install
On Wed, Jan 21, 2015 at 3:12 AM, Andreas Beckmann a...@debian.org wrote: On 2015-01-10 15:05, Holger Levsen wrote: packages may be in non working state, but I'd argue that installation itself must still not fail... after adding set -x to the postinst I get # dpkg --configure --pending Setting up ovirt-guest-agent (1.0.10.2.dfsg-1) ... + set -e + udevadm control --reload-rules dpkg: error processing package ovirt-guest-agent (--configure): subprocess installed post-installation script returned error exit status 2 [...] there is a ischroot utility (in debianutils) that could be used to guard the udevadm actions in your postinst: Will do that. Are you available for testing before the upload? Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775873: patch: directory traversal via file rename
On Sat, Jan 24, 2015 at 11:04 AM, Salvatore Bonaccorso car...@debian.org wrote: On Sat, Jan 24, 2015 at 10:50:11AM +0100, Salvatore Bonaccorso wrote: and the directory traversal via file rename does not seem to have a CVE yet? (retitling back this subject just to avoid confusion). I have requested a CVE for this one at http://www.openwall.com/lists/oss-security/2015/01/24/2 OK, but please note that there are three CVE number requests now[1][2][3]. Fixes are released and the packaging is ready. Should I wait for the CVE number assignment to note those in changelog or better if I upload the new version? Regards, Laszlo/GCS [1] https://security-tracker.debian.org/tracker/TEMP-000-064450 [2] https://security-tracker.debian.org/tracker/TEMP-0775873-B5D91A [3] https://security-tracker.debian.org/tracker/TEMP-0775901-CA9436 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774437: ovirt-guest-agent: fails in preinst due to hardcoded uid and gid values
On Fri, Jan 16, 2015 at 11:18 PM, Cameron Norman camerontnor...@gmail.com wrote: On Fri, 9 Jan 2015 12:47:28 -0800 Cameron Norman camerontnor...@gmail.com wrote: I actually did not experience #767028 on a system that does have /proc mounted, so it is likely. Again, I will double check later today. I said I would check but I never followed up on that :). I already deleted the group so I could not see who it was. I could not umount /proc in a container, and I ended up getting too lazy to set up a chroot (yes I know it is pretty easy, I am just kind of busy and tired). That said your hypothesis that it is a udevadm failure seems extremely likely. OK. Do you have ovirt-guest-agent installed, ie if I update it, would you test it on your system? Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767028: ovirt-guest-agent: fails to install
On Sun, Nov 16, 2014 at 5:13 PM, Holger Levsen hol...@layer-acht.org wrote: On Sonntag, 16. November 2014, László Böszörményi (GCS) wrote: Sure, it doesn't install on hosts and it'll be fixed. As the package name reveals, it's an oVirt agent for _guests_ and not meant for hosts. so what? I'm not raising the prio right now, but this aint a valid justification to downgrade the severity... apt-get install *must* not fail with any package. (If you want that package in a stable release... ;) Digging deep into this, it seems the problem lies in an other thing. Do you have /proc mounted in your piuparts test environment? This seems to be an udevadm 'bug' instead, it can't handle unreachable /proc/cmdline . Is there any policy that a package should install while /proc is unavailable? Cheers, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774437: ovirt-guest-agent: fails in preinst due to hardcoded uid and gid values
On Fri, Jan 2, 2015 at 8:33 PM, Cameron Norman camerontnor...@gmail.com wrote: It hardcodes them as 175. The uid was not taken, but the gid was so the package installation failed. Funnily enough, I was trying to fix #767028 at the time. Can you confirm that #767028 happens due to udevadm failure because /proc is not mounted? What has gid 175 on your system? Cheers, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777518: Bug#777520: patch: regression causes u-boot to FTBFS
Hi Vagrant, On Mon, Feb 9, 2015 at 4:27 AM, Vagrant Cascadian vagr...@debian.org wrote: Package: patch Version: 2.7.4-1 Severity: serious Justification: causes FTBFS in other packages Control: affects -1 u-boot $ dpkg-source -x u-boot_2014.10+dfsg1-2.dsc dpkg-source: warning: failed to verify signature on ./u-boot_2014.10+dfsg1-2.dsc [...] dpkg-source: info: restoring quilt backup files for cubox-i/cubox-i-support.diff dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -E -b -B .pc/cubox-i/cubox-i-support.diff/ --reject-file=- u-boot-2014.10+dfsg1/debian/patches/cubox-i/cubox-i-support.diff gave error exit status 1 [...] I may be able to work around the issue in u-boot by adjusting the patch, but this may affect other packages as well and result in FTBFS in security updates and binNMUs. Still, I think it's u-boot that should fix its Debian patch. The relevant part of 'cubox-i-support.diff': -- cut -- diff --git a/tools/logos/solidrun.bmp b/tools/logos/solidrun.bmp new file mode 100644 index 000..93db1f8 Binary files /dev/null and b/tools/logos/solidrun.bmp differ -- cut -- In this case patch is right, as tools/logos/solidrun.bmp is already exists while the patch file segment states the previous state should be a non-existent file (/dev/null). Please fix your patch file. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771341: segfaults in sqlite3_value_type while using from Python
On Mon, Mar 16, 2015 at 1:11 PM, Marc F. Clemente m...@mclemente.net wrote: For what it's worth, I am still getting segfaults in version 3.8.7.4-1. Multiple different computers, all amd64. What kind of CPU do you have? Intel or AMD? Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771241: Bug#782030: Mark the stunnel RC bugs as pending
On Thu, Apr 23, 2015 at 12:33 PM, intrigeri intrig...@debian.org wrote: Peter Pentchev wrote (08 Apr 2015 11:16:34 GMT) : I'm now about to ask the release team for a pre-approval for the new version of stunnel to migrate to Jessie. Just for the record, this was done: https://bugs.debian.org/782143 ? It was not even uploaded to Sid. :( I guess you mean the pre-unblock request can be closed as it's outdated. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751498: python-greenlet FTBFS on arm* is fixed in Sid as well
Control: fixed -1 0.4.6-1 On Sat, May 16, 2015 at 9:29 PM, Ivo De Decker iv...@debian.org wrote: On Sat, May 16, 2015 at 05:06:28PM +0200, László Böszörményi (GCS) wrote: It was fixed a while ago for Sid as well. If this bug is actually fixed in sid, you have to add the correct fixed version, because currently the BTS thinks the version in sid is still affected (as you can see in the version graph on the bug page). OK, just done. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751498: python-greenlet FTBFS on arm* is fixed in Sid as well
Control: tags -1 - sid stretch -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751498: python-greenlet FTBFS on arm* is fixed in Sid as well
Control: -1 - sid stretch Hi Ivo, It was fixed a while ago for Sid as well. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786475: ntfs-3g: CVE-2015-3202
Hi Salvatore, On Fri, May 22, 2015 at 6:48 AM, Salvatore Bonaccorso car...@debian.org wrote: ntfs-3g in jessie and above is similarly affected by CVE-2015-3202 since ntfs-3g since 1:2013.1.13AR.3-2 builds with internal fuse copy. Ouch. I plan to patch the Sid version and change the build system to use the system FUSE library. The patch I have used to prepare the updates for jessie is attached. I just got the DAK email for Jessie. Wheezy is not affected I guess, will check. ntfs-3g though should try to use the system fuse and not the embedded copy, could you check to switch this back? Sure thing. The internal copy may contain some fixes over the official source, but I'll check this as well. I'm away from home, but will be back in ten hours. Thanks, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786475: ntfs-3g: CVE-2015-3202
Hi Salvatore, On Fri, May 22, 2015 at 9:28 AM, Salvatore Bonaccorso car...@debian.org wrote: On Fri, May 22, 2015 at 08:14:16AM +0200, László Böszörményi (GCS) wrote: Ouch. I plan to patch the Sid version and change the build system to use the system FUSE library. Jep that would be great. i don't know the reason why it was switched back in 1:2013.1.13AR.3-2 so hopefully it can be done without problems for sid. The included FUSE library is quite different from the packaged version. I chose not to risk build or functionality and still use the patched embedded one. But to be extra safe, I put a version restriction on the FUSE build dependency to the security fixed one. Sure thing. The internal copy may contain some fixes over the official source, but I'll check this as well. I'm away from home, but will be back in ten hours. Thanks for your work on this then! The included version is a lite one to shrink the binary size, which is good for udeb. I think I should package both version of FUSE first, then build ntfs-3g with the packaged lite version. Cheers, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786439: squeeze update of fuse?
Hi Santiago, On Tue, May 26, 2015 at 6:42 PM, Santiago Ruano Rincón santiag...@riseup.net wrote: Please find the attached dpatch to prevent CVE-2015-3202 in squeeze. It makes lib/mount_util.c use execle instead of execl to run external helpers. Please, let me know if you want me to upload a patched package, or if you want to do it by yourself. I can do it myself, I've the build system for Squeeze as well. My only question if it should be an NMU or am I allowed to change the maintainer? At least the former would be a bit strange for me as I'm the actual maintainer, why should I NMU it? Thanks, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791169: libsidplayfp transition is in progress
Control: user release.debian@packages.debian.org Control: usertag 791169 + transition Control: block 791169 by 790756 Control: reassign 791169 release.debian.org Control: severity 791169 normal Hi, The package rename already happened and as the transition tracker[1] shows, sidplayfp already built with it. There was a confusion from one of the users[2], but as I see, audacious-plugins is still need a binNMU to be rebuilt with this libsidplayfp version. Cheers, Laszlo/GCS [1] https://release.debian.org/transitions/html/auto-libsidplayfp.html [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791169#19
Bug#791169: nmu diff for libsidplayfp 1.8.1-1.1
On Tue, Aug 18, 2015 at 10:32 AM, Julien Cristau jcris...@debian.org wrote: On Mon, Aug 17, 2015 at 23:28:55 +0200, László Böszörményi (GCS) wrote: On Mon, Aug 17, 2015 at 9:04 PM, Julien Cristau jcris...@debian.org wrote: I've prepared a NMU for libsidplayfp, to deal with the libstdc++ transition, and will shortly upload it to the 1-day delayed queue. Please find the debdiff below. Please withdraw it, as the rename already happened. It was libsidplayfp3 before and was renamed with the new upstream release to libsidplayfp4 for the GCC 5 transition (this also matches the new soname). If the rename already happened, why is #791169 then still open and assigned to libsidplayfp? I was waiting for an answer from Frédéric[1] what did he mean by the patch[2], if there's a source code fix or whatever to apply. As I didn't get an answer, I think he is just confused with something; I wanted to be extra safe. But just going to reassign the bug. Regards, Laszlo/GCS [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791169#24 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791169#19
Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI
On Fri, Aug 21, 2015 at 11:28 AM, Jakub Wilk jw...@debian.org wrote: Package: libgraphicsmagick3 Version: 1.3.20-4 Severity: serious Please either revert the QuantumDepth change, or change the SONAME. Of course, I'm going to fix it. Will change the SONAME as the QuantumDepth change is inevitable. Regards, Laszlo/GCS
Bug#791169: libsidplayfp: library transition may be needed when GCC 5 is the default
Hi Frédéric, On Sat, Aug 15, 2015 at 11:05 PM, Frédéric Brière fbri...@fbriere.net wrote: Thank you Julien (and Steve) for the patch; now audacious no longer segfaults on startup. Much appreciated. May I ask you what patch do you mean and what kind of segfault did you experience? I've uploaded a new upstream release for the GCC 5 transition and that contains the package rename. But audacious-plugins is not yet built with it[1]. I'm a bit confused now, if your package was segfaulting before, then it was not because of libsidplayfp - but I'd thank you if you check it again after it was binNMUed with the current libsidplayfp package version. Regards, Laszlo/GCS [1] https://release.debian.org/transitions/html/auto-libsidplayfp.html
Bug#791169: nmu diff for libsidplayfp 1.8.1-1.1
Hi Julien, On Mon, Aug 17, 2015 at 9:04 PM, Julien Cristau jcris...@debian.org wrote: I've prepared a NMU for libsidplayfp, to deal with the libstdc++ transition, and will shortly upload it to the 1-day delayed queue. Please find the debdiff below. Please withdraw it, as the rename already happened. It was libsidplayfp3 before and was renamed with the new upstream release to libsidplayfp4 [1] for the GCC 5 transition (this also matches the new soname). With your upload it would be renamed twice, from libsidplayfp3 through libsidplayfp4 to libsidplayfp4v5 . Please describe why is this necessary if needed. Also as I know we don't close transition bugs from changelog, but reassign it to release.debian.org and tag it transition. What may I miss? Thanks, Laszlo/GCS [1] https://packages.qa.debian.org/libs/libsidplayfp/news/20150812T213902Z.html
Bug#790684: FTBFS: configure: Qt demands position independent code
Hi, On Tue, Jun 30, 2015 at 10:13 PM, Chris West (Faux) solo-debianb...@goeswhere.com wrote: Source: libodb-qt Version: 2.4.0-1 Severity: serious Tags: sid Justification: fails to build from source User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs The package fails to build. First(?), Qt doesn't get found: configure:17847: g++ -c -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_REENTRANT -Wdate-time -D_FORTIFY_SOURCE=2 conftest.cpp 5 conftest.cpp:30:57: fatal error: QtCore/qconfig.h: No such file or directory #include QtCore/qconfig.h // QT_REDUCE_RELOCATIONS then other things go wrong: configure:17954: g++ -c -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_REENTRANT -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/include/x86_64-linux-gnu/qt5 -Wdate-time -D_FORTIFY_SOURCE=2 conftest.cpp 5 In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qchar.h:37:0, from /usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:37, from /usr/include/x86_64-linux-gnu/qt5/QtCore/QString:1, from conftest.cpp:36: /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1052:4: error: #error You must build your code with position independent code if Qt was built with -reduce-relocations. Compile your code with -fPIC (-fPIE is not enough). Yes, there's an ongoing Qt transition[1], its package version recently uploaded to Sid[2]. For the first look it seems the headers went a directory deeper: QtCore/qconfig.h to qt5/QtCore/qconfig.h . Then -fPIC should be specified, so this works: g++ -fPIC -I/usr/include/x86_64-linux-gnu/qt5/ conftest.cpp -lQt5Core Regards, Laszlo/GCS [1] https://release.debian.org/transitions/html/qtbase-abi-5-4-2.html [2] https://packages.qa.debian.org/q/qtbase-opensource-src/news/20150623T033622Z.html -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791072: icu: library transition may be needed when GCC 5 is the default
Control: tags -1 pending
Hi Matthias,
On Sat, Aug 1, 2015 at 11:23 PM, Matthias Klose d...@debian.org wrote:
Control: tags -1 + patch
You missed attaching the patch, but I think you mean the one I do attach.
this is exactly what should *not* be done. A simple rebuild changing the
symbols
without renaming the library or without bumping the soname.
The patch renames the library to libicu52v5 (adds breaks/replaces)
and should provide an easy transition.
Pretty please
upload the version from experimental to unstable.
It would be a bigger transition as the API changed. Needs testing if
all packages can be built with the new, 55.1 version. Will do that in
the morning. Midnight is passed here. :-|
Regards,
Laszlo/GCS
diff -Nru icu-52.1/debian/changelog icu-52.1/debian/changelog
--- icu-52.1/debian/changelog 2015-08-01 08:16:21.0 +0200
+++ icu-52.1/debian/changelog 2015-08-01 23:41:33.0 +0200
@@ -1,3 +1,9 @@
+icu (52.1-12) unstable; urgency=low
+
+ * Rename library for GCC-5 transition (closes: #791072).
+
+ -- Laszlo Boszormenyi (GCS) g...@debian.org Sat, 01 Aug 2015 19:39:05 +
+
icu (52.1-11) unstable; urgency=medium
* Build using GCC 5.
diff -Nru icu-52.1/debian/control icu-52.1/debian/control
--- icu-52.1/debian/control 2015-08-01 08:13:29.0 +0200
+++ icu-52.1/debian/control 2015-08-01 23:39:10.0 +0200
@@ -7,12 +7,14 @@
Build-Depends-Indep: doxygen (= 1.7.1)
Homepage: http://www.icu-project.org
-Package: libicu52
+Package: libicu52v5
Section: libs
Multi-Arch: same
Architecture: any
Pre-Depends: ${misc:Pre-Depends}
Depends: ${misc:Depends}, ${shlibs:Depends}
+Breaks: libicu52
+Replaces: libicu52
Description: International Components for Unicode
ICU is a C++ and C library that provides robust and full-featured
Unicode and locale support. This package contains the runtime
@@ -23,7 +25,7 @@
Priority: extra
Architecture: any
Pre-Depends: ${misc:Pre-Depends}
-Depends: ${misc:Depends}, libicu52 (= ${binary:Version})
+Depends: ${misc:Depends}, libicu52v5 (= ${binary:Version})
Description: International Components for Unicode
ICU is a C++ and C library that provides robust and full-featured
Unicode and locale support. This package contains debugging symbols
@@ -34,7 +36,7 @@
Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
-Depends: ${misc:Depends}, ${shlibs:Depends}, libicu52 (= ${binary:Version}), icu-devtools (= ${binary:Version}), libc6-dev | libc-dev, libstdc++-5-dev (= 5.2.1-10), g++ (= 4:5-0)
+Depends: ${misc:Depends}, ${shlibs:Depends}, libicu52v5 (= ${binary:Version}), icu-devtools (= ${binary:Version}), libc6-dev | libc-dev, libstdc++-5-dev (= 5.2.1-10), g++ (= 4:5-0)
Suggests: icu-doc
Description: Development files for International Components for Unicode
ICU is a C++ and C library that provides robust and full-featured
diff -Nru icu-52.1/debian/libicu52.install icu-52.1/debian/libicu52.install
--- icu-52.1/debian/libicu52.install 2015-02-16 03:35:11.0 +0100
+++ icu-52.1/debian/libicu52.install 1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-usr/lib/*/lib*.so.*
diff -Nru icu-52.1/debian/libicu52.lintian-overrides icu-52.1/debian/libicu52.lintian-overrides
--- icu-52.1/debian/libicu52.lintian-overrides 2015-02-16 03:35:11.0 +0100
+++ icu-52.1/debian/libicu52.lintian-overrides 1970-01-01 01:00:00.0 +0100
@@ -1,3 +0,0 @@
-# libicu52 installs multiple shared libraries, none of which is
-# actually called libicu.so.52, but all of which are libicu*.so.52.
-libicu52: package-name-doesnt-match-sonames
diff -Nru icu-52.1/debian/libicu52.shlibs icu-52.1/debian/libicu52.shlibs
--- icu-52.1/debian/libicu52.shlibs 2015-02-16 03:35:11.0 +0100
+++ icu-52.1/debian/libicu52.shlibs 1970-01-01 01:00:00.0 +0100
@@ -1,8 +0,0 @@
-libicudata 52 libicu52 (= 52~m1-1~)
-libicui18n 52 libicu52 (= 52~m1-1~)
-libicuio 52 libicu52 (= 52~m1-1~)
-libicule 52 libicu52 (= 52~m1-1~)
-libiculx 52 libicu52 (= 52~m1-1~)
-libicutest 52 libicu52 (= 52~m1-1~)
-libicutu 52 libicu52 (= 52~m1-1~)
-libicuuc 52 libicu52 (= 52~m1-1~)
diff -Nru icu-52.1/debian/libicu52v5.install icu-52.1/debian/libicu52v5.install
--- icu-52.1/debian/libicu52v5.install 1970-01-01 01:00:00.0 +0100
+++ icu-52.1/debian/libicu52v5.install 2015-02-16 03:35:11.0 +0100
@@ -0,0 +1 @@
+usr/lib/*/lib*.so.*
diff -Nru icu-52.1/debian/libicu52v5.lintian-overrides icu-52.1/debian/libicu52v5.lintian-overrides
--- icu-52.1/debian/libicu52v5.lintian-overrides 1970-01-01 01:00:00.0 +0100
+++ icu-52.1/debian/libicu52v5.lintian-overrides 2015-08-01 23:40:23.0 +0200
@@ -0,0 +1,3 @@
+# libicu52 installs multiple shared libraries, none of which is
+# actually called libicu.so.52, but all of which are libicu*.so.52.
+libicu52v5: package-name-doesnt-match-sonames
diff -Nru icu-52.1/debian/libicu52v5.shlibs icu-52.1/debian/libicu52v5.shlibs
--- icu-52.1/debian/libicu52v5.shlibs 1970-01-01 01:00:00.0 +0100
Bug#791072: icu: library transition may be needed when GCC 5 is the default
Control: tags -1 -help On Sun, Aug 2, 2015 at 1:59 PM, Matthias Klose d...@debian.org wrote: On 08/02/2015 01:44 PM, László Böszörményi (GCS) wrote: Then we can start the icu transition separately. sorry, you don't understand. all the libstdc++ follow-up transitions will depend on each other. I know this. Still it looked smoother if we do the GCC 5 transition and when things are settled then do the ICU one. your patch for icu 52 looks ok, but again, it will break all rdepends now, which could be avoided with icu 55. OK, 55.1 is in the building and last tests. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791072: icu: library transition may be needed when GCC 5 is the default
On Sun, Aug 2, 2015 at 4:16 PM, Matthias Klose d...@debian.org wrote: On 08/02/2015 03:32 PM, László Böszörményi (GCS) wrote: OK, 55.1 is in the building and last tests. ok, I uploaded an icu 52 built using g++-4.9 to undo the breakage in unstable. Please let this build and enter the archive, before you upload icu 55. I've uploaded icu/55.1-3 to Sid before your mail. While it's not yet accepted, it's not in the UploadQueue anymore and I can't remove it. I also sent a removal request for 52.1-11 and 52.1-11.1 to ftp-master. OK. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791072: icu: library transition may be needed when GCC 5 is the default
Control: tags -1 help Hi Matthias, On Sun, Aug 2, 2015 at 12:18 AM, László Böszörményi (GCS) g...@debian.org wrote: Pretty please upload the version from experimental to unstable. It would be a bigger transition as the API changed. Needs testing if all packages can be built with the new, 55.1 version. Will do that in the morning. Midnight is passed here. :-| I have building the dependency level 1 [1] and github-backup, hardinfo, haskell-hledger-web and icedove built fine with icu-55.1 . But ledger has build-dependency on libboost-date-time-dev which is transitively marked broken by libstdc++6 . Thus please check my previously attached patch[2] if it covers everything needed for the gcc-5 transition. Then we can start the icu transition separately. Thanks, Laszlo/GCS [1] https://release.debian.org/transitions/html/auto-icu.html [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791072#19 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794993: libsnappy1: library transition may be needed when GCC 5 is the default
On Sun, Aug 9, 2015 at 11:41 AM, Steinar H. Gunderson sgunder...@bigfoot.com wrote: On Sun, Aug 09, 2015 at 07:52:37AM +0200, László Böszörményi wrote: I can upload the patch given there now if you want. Please do. It would be nice if you switch to the 3.0 (quilt) source format as well. --- debian/libsnappy1.symbols 2015-08-08 23:54:52.415075073 + +++ debian/libsnappy1/DEBIAN/symbols 2015-08-08 23:59:25.046660564 + @@ -1,5 +1,5 @@ libsnappy.so.1 libsnappy1 #MINVER# - _ZN6snappy10UncompressEPKcmPSs@Base 1.1.3 + _ZN6snappy10UncompressEPKcmPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 1.1.3 _ZN6snappy10UncompressEPNS_6SourceEPNS_4SinkE@Base 1.1.3 _ZN6snappy11RawCompressEPKcmPcPm@Base 1.1.3 _ZN6snappy13RawUncompressEPKcmPc@Base 1.1.3 Surely you cannot patch things in DEBIAN/. Please read my mail again: see the attached symbols change, it's not a thing you need to apply - it's the evidence it needs the transition. The proposed NMU is in the other file, in snappy_1.1.3-1_to_1.1.3-1.1.patch (debdiff). Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791168: libsidplay: diff for NMU version 1.36.59-7.1
Hi Jonathan, On Sat, Aug 8, 2015 at 4:54 PM, Jonathan Wiltshire j...@debian.org wrote: I've prepared an NMU for libsidplay (versioned as 1.36.59-7.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Thanks! But I had other things to apply and -8 is uploaded and just accepted. Cheers, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795102: libgraphicsmagick1-dev: undefined reference to `Magick::Color::Color(unsigned short, unsigned short, unsigned short)'
On Mon, Aug 10, 2015 at 10:55 PM, Jakub Wilk jw...@debian.org wrote: $ pdf2djvu /usr/share/doc/quilt/quilt.pdf --fg-colors 42 -p1 -d72 -o tmp.djvu /usr/share/doc/quilt/quilt.pdf: - page #1 - #1 pdf2djvu: malloc.c:3695: _int_malloc: Assertion `(unsigned long) (size) = (unsigned long) (nb)' failed. Magick: abort due to signal 6 (SIGABRT) Abort... Aborted (I think pdf2djvu doesn't work correctly with high quantum depths anyway, but that's another story... I'll get it fixed upstream.) So there will be a new pdf2djvu release? Currently I've fixed all the bugs you are reported, thanks for them! Added a breaks for pdf2djvu v0.7.21-2 and earlier; the binNMU (+b1) solved this issue for me (the generation works). If you would like to have a look before I upload it, you can do that[1]. Regards, Laszlo/GCS [1] dget -x http://www.barcikacomp.hu/gcs/graphicsmagick_1.3.21-3.dsc -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795102: libgraphicsmagick1-dev: undefined reference to `Magick::Color::Color(unsigned short, unsigned short, unsigned short)'
On Mon, Aug 10, 2015 at 8:27 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Mon, 10 Aug 2015, Jakub Wilk wrote: Perhaps this issue is due to g++ defaulting to a newer version of the C++ standard and thus it requires a new C++ ABI? I don't think so. I'd rather blame: * Test build with QuantumDepth 16 (closes: #557879). But wait, isn't change of QuantumDepth an ABI breakage? SONAME of the non-C++ library didn't change; it's still /usr/lib/libGraphicsMagick.so.3. As I know it's only an internal precision change, but doesn't affect any method or function. If --enable-quantum-library-names was used as an option to the configure script, then the shared library name would become like libGraphicsMagick-Q16.so so the whole run-time library name is different. It was not used. Should I add this? It seems it would cause more trouble than win. If the QuantumDepth 8 build did not use this option, then it would be named as before and existing apps (compiled with QuantumDepth 8) should work with it. This allows the libraries to co-exist. It seems you also write that the quantum depth change shouldn't be a problem for applications. The package used for development needs to specify if it is for Q8 or Q16 since (barring other factors), it is only possible to develop for one at a time. As I know, GraphicsMagick will use roughly double the memory during image processing with the latter, but that's what the user can see (and that the output quality is better). Am I right? Regardless, if GCC 5.X is now being used (is this the case?), I would suspect that the C++ default ABI (and libraries) have changed (to C++ 11) and this results in different name mangling. Note that the linker did find the library but not the method. Yes, it's now compiled with GCC 5.2.x and the name mangling is changed for the C++ library. There are known regressions[1] between v4.9 and v5 , but I don't know too much details. While you are right in #795099 that the two libgraphicsmagick++ libraries are co-installable, but I fear that the two C++ ABIs would cause more problems. The reverse dependencies list is small, those can be re-compiled with the new library version. But to answer your question, the API for 1.3.21/QuantumDepth16 should be the same as previously. I attach the symbols change between 1.3.20 and 1.3.21 ; the additions are for WebP image support and two symbols (RegisterAVIImage, UnregisterAVIImage) are removed. As I see, a versioned breaks is the only thing I need to add. Regards, Laszlo/GCS [1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_c.2B-.2B-11_incompatibilities_.284.9_and_5.29 --- 1.3.20/debian/libgraphicsmagick3.symbols2015-02-12 20:08:51.0 +0100 +++ 1.3.21/debian/libgraphicsmagick3.symbols2015-08-08 17:48:44.521870457 +0200 @@ -75,6 +75,7 @@ ChannelThresholdImage@Base 1.3.5 ChannelTypeToString@Base 1.3.5 CharcoalImage@Base 1.3.5 + CheckImagePixelLimits@Base 1.3.21 ChopImage@Base 1.3.5 ClassTypeToString@Base 1.3.5 ClipImage@Base 1.3.5 @@ -504,6 +505,7 @@ LockSemaphoreInfo@Base 1.3.5 LogMagickEvent@Base 1.3.5 LogMagickEventList@Base 1.3.5 + LogPALMHeader@Base 1.3.21 MSBOrderLong@Base 1.3.5 MSBOrderShort@Base 1.3.5 MagickAllocFunctions@Base 1.3.5 @@ -570,6 +572,7 @@ MagickSetFileSystemBlockSize@Base 1.3.8 MagickSizeStrToInt64@Base 1.3.5 MagickSpawnVP@Base 1.3.5 + MagickStripSpacesFromString@Base 1.3.21 MagickStrlCat@Base 1.3.5 MagickStrlCpy@Base 1.3.5 MagickStrlCpyTrunc@Base 1.3.5 @@ -704,6 +707,7 @@ PSPageGeometry@Base 1.3.5 PackbitsEncode2Image@Base 1.3.5 PackbitsEncodeImage@Base 1.3.5 + PanicDestroyMagick@Base 1.3.21 PersistCache@Base 1.3.5 PingBlob@Base 1.3.5 PingImage@Base 1.3.5 @@ -719,6 +723,7 @@ PrependImageToList@Base 1.3.5 ProfileImage@Base 1.3.5 PurgeTemporaryFiles@Base 1.3.15 + PurgeTemporaryFilesAsyncSafe@Base 1.3.21 PushImagePixels@Base 1.3.5 QuantizeImage@Base 1.3.5 QuantizeImages@Base 1.3.5 @@ -764,7 +769,6 @@ ReferenceCache@Base 1.3.5 ReferenceImage@Base 1.3.5 RegisterARTImage@Base 1.3.5 - RegisterAVIImage@Base 1.3.5 RegisterAVSImage@Base 1.3.5 RegisterBMPImage@Base 1.3.5 RegisterCALSImage@Base 1.3.8 @@ -852,6 +856,7 @@ RegisterVIDImage@Base 1.3.5 RegisterVIFFImage@Base 1.3.5 RegisterWBMPImage@Base 1.3.5 + RegisterWEBPImage@Base 1.3.21 RegisterWMFImage@Base 1.3.5 RegisterWPGImage@Base 1.3.5 RegisterXBMImage@Base 1.3.5 @@ -899,6 +904,7 @@ SetImageColor@Base 1.3.15 SetImageColorRegion@Base 1.3.15 SetImageDepth@Base 1.3.5 + SetImageEx@Base 1.3.21 SetImageInfo@Base 1.3.5 SetImageOpacity@Base 1.3.5 SetImagePixels@Base 1.3.5 @@ -982,7 +988,6 @@ UnlockSemaphoreInfo@Base 1.3.5 UnmapBlob@Base 1.3.5 UnregisterARTImage@Base 1.3.5 - UnregisterAVIImage@Base 1.3.5 UnregisterAVSImage@Base 1.3.5 UnregisterBMPImage@Base 1.3.5 UnregisterCALSImage@Base 1.3.8 @@ -1070,6 +1075,7 @@ UnregisterVIDImage@Base 1.3.5 UnregisterVIFFImage@Base 1.3.5 UnregisterWBMPImage
Bug#791059: graphicsmagick: library transition may be needed when GCC 5 is the default
On Sat, Aug 8, 2015 at 12:55 PM, Julien Cristau jcris...@debian.org wrote:
On Fri, Jul 3, 2015 at 13:10:18 +, Matthias Klose wrote:
Background [1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
from checking libgraphicsmagick++1{,-dev}, there are public symbols
involving std::string, so the library package needs to be renamed.
+1, I'm in the process of updating it. Will upload it today in some hours.
Thanks,
Laszlo/GCS
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791059: graphicsmagick: library transition may be needed when GCC 5 is the default
Control: tag -1 + help pending
On Sat, Aug 8, 2015 at 12:55 PM, Julien Cristau jcris...@debian.org wrote:
On Fri, Jul 3, 2015 at 13:10:18 +, Matthias Klose wrote:
Background [1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
from checking libgraphicsmagick++1{,-dev}, there are public symbols
involving std::string, so the library package needs to be renamed.
I attach the proposed update. As I'm again a bit overloaded, I would
be glad if someone may take a look before I upload it.
Thanks,
Laszlo/GCS
graphicsmagick_1.3.20-3+deb8u1_to_1.3.20-4.patch.gz
Description: GNU Zip compressed data
Bug#791059: graphicsmagick: library transition may be needed when GCC 5 is the default
Control: tag -1 - help On Sat, Aug 8, 2015 at 2:17 PM, Julien Cristau jcris...@debian.org wrote: On Sat, Aug 8, 2015 at 14:12:09 +0200, László Böszörményi (GCS) wrote: I attach the proposed update. As I'm again a bit overloaded, I would be glad if someone may take a look before I upload it. There's also a diff at https://launchpad.net/ubuntu/+source/graphicsmagick/1.3.20-4ubuntu1 that may be helpful. +1, my changes are the same - with the same mistakes. Just fixing these and will upload soon. Thanks, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793465: libuser/1:0.60~dfsg-1.2 fix for CVE-2015-3245 and CVE-2015-3246
Hi Ghe, Tzafrir,
Do you still maintain libuser for Debian? Your last upload was more
than a year ago[1] and currently you have two security bugs
reported[2]. I'm going to NMU and fix these with the attached changes
if you don't respond in some days.
Regards,
Laszlo/GCS
[1] https://packages.qa.debian.org/libu/libuser/news/20140519T161907Z.html
[2] https://bugs.debian.org/793465
diff -Nru libuser-0.60~dfsg/debian/changelog libuser-0.60~dfsg/debian/changelog
--- libuser-0.60~dfsg/debian/changelog 2014-12-29 20:37:14.0 +
+++ libuser-0.60~dfsg/debian/changelog 2015-08-08 12:49:01.0 +
@@ -1,3 +1,13 @@
+libuser (1:0.60~dfsg-1.3) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix CVE-2015-3245 and CVE-2015-3246 (closes: #793465).
+
+ [ Bart Martens ba...@debian.org ]
+ * Add watch file.
+
+ -- Laszlo Boszormenyi (GCS) g...@debian.org Sat, 08 Aug 2015 12:26:38 +
+
libuser (1:0.60~dfsg-1.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru libuser-0.60~dfsg/debian/patches/0004-CVE-2015-3245_and_CVE-2015-3246.patch libuser-0.60~dfsg/debian/patches/0004-CVE-2015-3245_and_CVE-2015-3246.patch
--- libuser-0.60~dfsg/debian/patches/0004-CVE-2015-3245_and_CVE-2015-3246.patch 1970-01-01 00:00:00.0 +
+++ libuser-0.60~dfsg/debian/patches/0004-CVE-2015-3245_and_CVE-2015-3246.patch 2015-08-08 12:52:36.0 +
@@ -0,0 +1,1546 @@
+Description: fix CVE-2015-3245 and CVE-2015-3246
+ During a code audit by Qualys, multiple libuser-related vulnerabilities
+ were discovered that can allow local users to perform denial-of-service and
+ privilege-escalation attacks:
+ - Race condition in password file update (CVE-2015-3246, Important)
+ - Lack of validation of GECOS field contents (CVE-2015-3245, Moderate)
+Origin: upstream, https://fedorahosted.org/libuser/changeset/d73aa2a5a9ce5bdd349dff46e3e4885f2b194a95/
+Bug-Debian: https://bugs.debian.org/793465
+Author: Miloslav Trmač m...@redhat.com
+Last-Update: 2015-08-08
+
+---
+
+--- libuser-0.60~dfsg.orig/ChangeLog
libuser-0.60~dfsg/ChangeLog
+@@ -1,3 +1,30 @@
++2015-06-26 Miloslav Trmač m...@redhat.com
++
++ * modules/files.c (open_and_copy_file): Replace and heavily modify ...
++ (lu_files_create_backup): ... this.
++ (lock_file_handle_existing, lock_file_create, lock_file_remove)
++ (struct editing, editing_open, replace_file_or_symlink)
++ (editing_close): New functions.
++ (generic_lookup, generic_is_locked, lu_files_enumerate)
++ (lu_files_users_enumerate_by_group, lu_files_groups_enumerate_by_user)
++ (lu_files_enumerate_full): Remove locking on read-only operations.
++ (generic_add, generic_mod, generic_del, generic_lock)
++ (generic_setpass): Use struct editing instead of dealing with locking,
++ backups, SELinux individually.
++
++ * lib/user_private.h (lu_util_lock_obtain, lu_util_lock_free): Mark
++ as deprecated.
++
++ * lib/util.c (lu_util_field_write): Fail on an incomplete write().
++
++2015-06-25 Miloslav Trmač m...@redhat.com
++
++ * modules/files.c (format_generic, generic_setpass): Refuse to write
++ field values which contain \n.
++ * tests/files_test.py (Tests.testUserAdd9, Tests.testUserMod8)
++ (tests.testUserSetpass5, tests.testGroupAdd6, tests.testGroupMod7)
++ (tests.testGroupSetpass4): New tests.
++
+ 2013-10-12 Miloslav Trmač m...@redhat.com
+
+ * configure.ac: Release 0.60.
+--- libuser-0.60~dfsg.orig/lib/user_private.h
libuser-0.60~dfsg/lib/user_private.h
+@@ -330,9 +330,11 @@ typedef char lu_security_context_t; /*
+ ((void)(PATH), (void)(MODE), (void)(ERROR), TRUE)
+ #endif
+
+-/* Lock a file. */
++#ifndef LU_DISABLE_DEPRECATED
++/* Lock a file. Deprecated. */
+ gpointer lu_util_lock_obtain(int fd, struct lu_error **error);
+ void lu_util_lock_free(gpointer lock);
++#endif
+
+ /* Manipulate a colon-delimited flat text file. */
+ char *lu_util_line_get_matching1(int fd, const char *firstpart,
+--- libuser-0.60~dfsg.orig/lib/util.c
libuser-0.60~dfsg/lib/util.c
+@@ -632,7 +632,7 @@ lu_util_field_write(int fd, const char *
+ goto err;
+ }
+ len = strlen(buf);
+- if (write(fd, buf, len) == -1) {
++ if (write(fd, buf, len) != len) {
+ lu_error_new(error, lu_error_write, NULL);
+ ret = FALSE;
+ goto err;
+--- libuser-0.60~dfsg.orig/modules/files.c
libuser-0.60~dfsg/modules/files.c
+@@ -25,6 +25,7 @@
+ #include fcntl.h
+ #include fnmatch.h
+ #include limits.h
++#include shadow.h
+ #include stdio.h
+ #include stdlib.h
+ #include string.h
+@@ -101,82 +102,79 @@ module_filename(struct lu_module *module
+ return g_strconcat(dir, file_suffix, NULL);
+ }
+
+-/* Create a backup copy of filename named filename-. */
+-static gboolean
+-lu_files_create_backup(const char *filename,
+- struct lu_error **error)
++/* Copy contents of INPUT_FILENAME to OUTPUT_FILENAME, exclusively creating it
++ * if EXCLUSIVE.
++ * Return the file descriptor for OUTPUT_FILENAME, open for reading and writing,
++ * or -1 on error.
++ * Note that this does
Bug#794993: libsnappy1: library transition may be needed when GCC 5 is the default
Package: src:snappy
Version: 1.1.3-1
Severity: serious
Tags: sid stretch patch
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11
Control: block 794931 with -1
The short note.
Background [1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI. Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
and dropping other symbols. If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.
It seems Matthias missed this C++ library transition. Maybe due to the
old style packaging and that this package doesn't provide a symbols
file. But please see the attached symbols change when built with
gcc-4.9 and gcc-5.2 , thus __cxx11 symbols show up.
At the moment it breaks building of mongodb, but may break other
packages as well.
I propose the attached NMU if you don't have time for now - or I can
help update and maintain the packaging as co-maintainer if you want.
Regards,
Laszlo/GCS
[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
--- debian/libsnappy1.symbols 2015-08-08 23:54:52.415075073 +
+++ debian/libsnappy1/DEBIAN/symbols2015-08-08 23:59:25.046660564 +
@@ -1,5 +1,5 @@
libsnappy.so.1 libsnappy1 #MINVER#
- _ZN6snappy10UncompressEPKcmPSs@Base 1.1.3
+
_ZN6snappy10UncompressEPKcmPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
1.1.3
_ZN6snappy10UncompressEPNS_6SourceEPNS_4SinkE@Base 1.1.3
_ZN6snappy11RawCompressEPKcmPcPm@Base 1.1.3
_ZN6snappy13RawUncompressEPKcmPc@Base 1.1.3
@@ -38,8 +38,8 @@
_ZN6snappy6SourceD0Ev@Base 1.1.3
_ZN6snappy6SourceD1Ev@Base 1.1.3
_ZN6snappy6SourceD2Ev@Base 1.1.3
- _ZN6snappy6Varint8Append32EPSsj@Base 1.1.3
- _ZN6snappy8CompressEPKcmPSs@Base 1.1.3
+
_ZN6snappy6Varint8Append32EPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEj@Base
1.1.3
+
_ZN6snappy8CompressEPKcmPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
1.1.3
_ZN6snappy8CompressEPNS_6SourceEPNS_4SinkE@Base 1.1.3
_ZN6snappy8internal13WorkingMemory12GetHashTableEmPi@Base 1.1.3
_ZN6snappy8internal16CompressFragmentEPKcmPcPti@Base 1.1.3
diff -u snappy-1.1.3/debian/changelog snappy-1.1.3/debian/changelog
--- snappy-1.1.3/debian/changelog
+++ snappy-1.1.3/debian/changelog
@@ -1,3 +1,10 @@
+snappy (1.1.3-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Rename library to libsnappy1v5 for GCC 5 transition.
+
+ -- Laszlo Boszormenyi (GCS) g...@debian.org Sun, 09 Aug 2015 07:28:37 +0200
+
snappy (1.1.3-1) unstable; urgency=medium
* New upstream release.
diff -u snappy-1.1.3/debian/control snappy-1.1.3/debian/control
--- snappy-1.1.3/debian/control
+++ snappy-1.1.3/debian/control
@@ -10,7 +10,7 @@
Section: libdevel
Architecture: any
Multi-Arch: same
-Depends: libsnappy1 (= ${binary:Version}), ${misc:Depends}
+Depends: libsnappy1v5 (= ${binary:Version}), ${misc:Depends}
Description: fast compression/decompression library (development files)
Snappy is a compression/decompression library. It does not aim for
maximum compression, or compatibility with any other compression
@@ -26,12 +26,14 @@
This package contains the development files required to build programs
against Snappy.
-Package: libsnappy1
+Package: libsnappy1v5
Section: libs
Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}
+Conflicts: libsnappy1
+Replaces: libsnappy1
Description: fast compression/decompression library
Snappy is a compression/decompression library. It does not aim for
maximum compression, or compatibility with any other compression
reverted:
--- snappy-1.1.3/debian/libsnappy1.dirs
+++ snappy-1.1.3.orig/debian/libsnappy1.dirs
@@ -1 +0,0 @@
-usr/lib
reverted:
--- snappy-1.1.3/debian/libsnappy1.install
+++ snappy-1.1.3.orig/debian/libsnappy1.install
@@ -1 +0,0 @@
-usr/lib/*/lib*.so.*
only in patch2:
unchanged:
--- snappy-1.1.3.orig/debian/libsnappy1v5.dirs
+++ snappy-1.1.3/debian/libsnappy1v5.dirs
@@ -0,0 +1 @@
+usr/lib
only in patch2:
unchanged:
--- snappy-1.1.3.orig/debian/libsnappy1v5.install
+++ snappy-1.1.3/debian/libsnappy1v5.install
@@ -0,0 +1 @@
+usr/lib/*/lib*.so.*
Bug#794931: MongoDB FTBFS due to new GCC + snappy transition
Control: block 794931 with 794993 Control: tags 794931 + pending zigo, at least write the package name right please. The fix is pending, but it needs a GCC5 transitioned snappy version. Hope it will happen soon. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793484: expat CVE-2015-1283 affected versions
Control: found -1 2.0.1-7+squeeze1 Squeeze, Wheezy and Jessie versions are all affected by this security issue. :( -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778175: Unable to reproduce GCC-5 build issue
Control: fixed -1 3.2.1~dfsg1-1 On Mon, Jul 6, 2015 at 10:42 PM, Dall, Elizabeth J betty.d...@hp.com wrote: fixed 778175 3.2.1 thanks Corrected the version number which the FTBFS is fixed in. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#798888: ntfs-3g: pretends to be a library in a broken way
Hi, On Sun, Sep 13, 2015 at 10:14 PM, Jonathan Wiltshire <j...@debian.org> wrote: > ntfs-3g ships shared objects in a non-private location and these are used > by other packages. ntfs-3g does not have a proper shared library package. > > Currently ntfs-3g advertises its ABI through a virtual package. This makes it > difficult to detect breakage in other packages when that ABI changes. > > Upstream appears to want to bump ABI regularly. There's a new upstream version which starts an other transition. Created a separate library package with the actual SONAME naming. Tested that partclone and testdisk build fine with it and both picks up the correct (real) dependency (binNMUs will be fine). The libraries will be co-installable and I don't use conflicts with the old ones to help smooth transitions. Before I do the upload[1], I'm open for any critics. Regards, Laszlo/GCS [1] dget -x http://www.barcikacomp.hu/gcs/ntfs-3g_2015.3.14AR.2-1.dsc
Bug#771341: segfaults in sqlite3_value_type while using from Python
On Mon, Mar 16, 2015 at 3:10 PM, Marc F. Clemente <m...@mclemente.net> wrote: > One is an Intel i7. Four others are xen virtual machines running on an Intel > Xeon. On which computers do you get the segfaults? Can you try recent SQLite3 package uploads, especially 3.9.1? Do you have a minimal installation maybe where the crash happens? Laszlo/GCS
Bug#804604: [pkg-fetchmail-maint] Bug#804604: fetchmail: FTBFS: undefined reference to `SSLv3_client_method'
Hi Peter, On Sun, Nov 15, 2015 at 6:00 AM, peter green <plugw...@p10link.net> wrote: >> socket.o: In function `SSLOpen': >> /fetchmail-6.3.26/socket.c:917: undefined reference to >> `SSLv3_client_method' >> collect2: error: ld returned 1 exit status >> Makefile:699: recipe for target 'fetchmail' failed >> make[3]: *** [fetchmail] Error 1 > > > I just fixed this in raspbian, debdiff at > http://debdiffs.raspbian.org/main/f/fetchmail/fetchmail_6.3.26-1%2brpi1.debdiff Thanks, but it seems a quick and dirty solution; it doesn't offer any alternative to SSLv3. If you can, please test my proposed package[1] (offers TLSv1.2 support) and report back. Kind regards, Laszlo/GCS [1] dget -x http://www.barcikacomp.hu/gcs/fetchmail_6.3.26-2.dsc
Bug#805119: Acknowledgement (dar: Corrupted archives with dar ≥ 2.5.0)
Hi Peter, On Mon, Nov 16, 2015 at 6:41 AM, Peter Colberg <pe...@colberg.org> wrote: > This bug has been fixed in upstream commit 92cdf9c, which will be > included in version 2.5.2 to be released soon. I raised the severity > level to grave since the bug may result in data loss. Such archives still can be extracted if you use the '--sequential-read' switch. Still, going to upload a package version with the fix included. Laszlo/GCS
Bug#771341: fixed segfaults in sqlite3_value_type
fixed 771341 3.8.11.1-1 thanks On Sun, Oct 25, 2015 at 5:25 PM, László Böszörményi (GCS) <g...@debian.org> wrote: > Package: libsqlite3-0 > Version: 3.8.11.1-1 Set source package name for fixed version.
Bug#797961: ecryptfs-utils: encrypted swap fails
On Fri, Sep 4, 2015 at 1:24 AM, Richard Jasmin <frazzledj...@gmail.com> wrote: > one has to rely on ecryptfs. > > sudo ecryptfs-setup-swap > > to get encrypted swap in the first place. Does it work now on your machine? > When using it we are presented with another problem. > > On boot swap fails to properly encrypt.You get a nice "system service > cryptswapper" is busy (time remaining) notice, which does nothing but timeout. What does '/sbin/cryptdisks_start cryptswap1' outputs on your system when swap doesn't work? > Swap either never gets its random key, never gets written to disk, or never > bothers to properly mount itself. Can you check it's not active at all, 'free -m' shows it's not available? > Unfortunately I cannot tell you which happens as all I can tell is that swap > never gets mounted.There are no /dev/mapper entries for swap, even though > there > SHOULD BE. Can you do 'blkid /dev/[your swap partition' and its output matches the one set in '/etc/crypttab'? > I do not know yet how repeatable this issue is.This is the first occurrence > since swap has been encrypted. Do you have experience if it works sometimes when you reboot or constantly fails? Thanks, Laszlo/GCS
Bug#796298: tcplay: FTBFS: CMake Error at CMakeLists.txt:30 (message): Could not find the devmapper library
On Fri, Aug 21, 2015 at 10:10 AM, Chris Lamb la...@debian.org wrote: Source: tcplay Version: 1.1-2 Severity: serious Justification: fails to build from source CMake Error at CMakeLists.txt:30 (message): Could not find the devmapper library From a cursory glance, devmapper.pc specifies Requires.Private librt, which doesn't have a librt.pc (which is likely correct as it's meant to be linked statically? I'll leave it to you). You are right in the sense that without 'Requires.private:' the devmapper library is found correctly. On the other hand I don't think static linking is mandatory as libdevmapper.so.* exists and is under /lib (no need to have /usr mounted, can be used in emergency shells as well). Can be a cmake issue? Will investigate further. Laszlo/GCS
Bug#796297: libcrypto++: FTBFS on armel: DH validation suite: FAILED simple key agreement domain parameters invalid
On Fri, Aug 21, 2015 at 10:09 AM, Christian Hofstaedtler <christ...@hofstaedtler.name> wrote: > Package: libcrypto++ > Version: 5.6.1-8 > Severity: serious > Justification: fails to build from source > > libcrypto++ failed to build on armel. Hopefully relevant snippet: > > BlumBlumShub validation suite running... > > passed49ea2cfdb01064a0bbb92af101dac18a94f7b7ce > FAILED53171c6887956cea5d3b > FAILED49383dc6167a2638473fd4a183170f44d46d0c85 [...] Just for the record, I give a helping hand to upstream solving this. It happens on different architectures with different GCC versions (4.9 to 5.2 at least) - but with different optimization levels it does _not_. I suspect some GCC anomalies, but don't know more details yet. Regards, Laszlo/GCS
Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI
Hi Niels, Bob, others, On Fri, Sep 25, 2015 at 8:34 AM, Niels Thykier <ni...@thykier.net> wrote: > Thanks for getting it uploaded to NEW. > > I have prodded the FTP masters about fast tracking and will try to > finish the resulting transition as fast as possible. :) Now it's accepted, built fine on almost all architectures and the tracker seems to be correct. It fails on mipsel[1] with: -- cut -- Magick: abort due to signal 11 (SIGSEGV) "Segmentation Fault"... /«PKGBUILDDIR»/scripts/tap-functions.shi: line 58: 2290 Aborted ( "$@" ) EXEC: ./rwfile -stdio -filespec out_truecolor_stdio_%d /«PKGBUILDDIR»/tests/input_truecolor.miff PCDS not ok 244 - PCDS truecolor (stdio) FAIL: tests/rwfile.tap 244 - PCDS truecolor (stdio) -- cut -- It was failed previously a few times as well, but a rescheduled build solved it. To be honest the reasons were: signal 01 (SIGBUS) "Bus Error" But I suspect the cause may be the same, please reschedule the build of graphicsmagick on mipsel. The build is strange on mips just for the record. Sometimes (just like in the past) it builds in a hour. Nowadays it's over twelve hours sometimes, but it seems to be at lease six hours[2]. Bob, how may I help you to find the root cause of the slow building on mips at least? Thanks, Laszlo/GCS [1] https://buildd.debian.org/status/fetch.php?pkg=graphicsmagick=mipsel=1.3.21-4=1443407301 [2] https://buildd.debian.org/status/logs.php?pkg=graphicsmagick=mips
