Bug#938073: fssync marked for autoremoval due to python-pylibacl?
With this bug fixed, fssync has just been marked for autoremoval because it would depend (transitively) on python-pylibacl. I don't understand why. fssync only depends on python3-pylibacl.
Bug#908492: nat-rtsp-dkms: fails to build on new 4.18 kernels
Someone wrote a fix at: https://github.com/sforshee/rtsp-linux/commit/3a4a4866890e7daee96010291feb72396a99d9ed I didn't try yet. Julien
Bug#778151: Processed: tuxonice-userui: diff for NMU version 1.1+dfsg1.gc3bdd83-3.1
Hello, I am really sorry for wasting the time of everyone here. In fact, the job is already done but I have no upload right and my usual sponsor lacks time currently (well, I preferred we finished something about another RC-buggy package before asking him for this one). So, there are other important bugfixes for tuxonice-userui, as you can see on my own repository: http://jmuchemb.eu/tuxonice-userui.git [1] I only need to make this ready for release (write messages for the last 2 commits and update changelog). I'm available to finish if anyone agrees to sponsor all this. Regards, Julien -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778151: Processed: tuxonice-userui: diff for NMU version 1.1+dfsg1.gc3bdd83-3.1
Le 07/19/15 19:56, gregor herrmann a écrit : On Sun, 19 Jul 2015 18:50:53 +0200, Julien Muchembled wrote: I am really sorry for wasting the time of everyone here. In fact, the job is already done but I have no upload right and my usual sponsor lacks time currently (well, I preferred we finished something about another RC-buggy package before asking him for this one). No worries. For the future: please mention this in the bug report (and tag the bug pending). So, there are other important bugfixes for tuxonice-userui, as you can see on my own repository: http://jmuchemb.eu/tuxonice-userui.git [1] I only need to make this ready for release (write messages for the last 2 commits and update changelog). I'm available to finish if anyone agrees to sponsor all this. The other changes since -3 look good, so if you finish d/changelog I'm happy to sponsor the package. Just shout when you've pushed the final touches to your git repo. http://jmuchemb.eu/tuxonice-userui.git updated I'll push to collab-maint if everything's fine. signature.asc Description: OpenPGP digital signature
Bug#774393: fssync: possible data corruption on destination side
Package: fssync Severity: grave Tags: fixed-upstream Justification: causes non-serious data loss I fixed 2 serious bugs upstream. In some cases, the DB was wrongly updated, which would later cause useless resync or corruption. See http://jmuchemb.eu/fssync.git/commit/45a3425f48a42d415887333f67cb317b01df24da?js=1 and http://jmuchemb.eu/fssync.git/commit/5f98a3720f39d75d993051be80d928aedbeb305e?js=1 for more information. I also fixed another (non-RC) bug which required a small change in the protocol: http://jmuchemb.eu/fssync.git/commit/2e05ddbb78ba5f9a4d272a1fa5a2f05a3312c01e?js=1 If an upload is done only with the first 2 patches, the stable version would immediately get non-interoperable with the testing/sid when Jessie is released. I'd like to tag the current master branch as 1.5 and that this new version is part of Jessie. Otherwise, I prefer not to waste time and that fssync gets removed from testing. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760355: tuxonice-userui: FTBFS - missing include of stdio.h
Control: tags -1 upstream Control: tags 759856 upstream This was already reported by https://bugs.debian.org/759856 and reassigned to libmng. With the 'affects' BTS command, I expected that #759856 would still be visible on the tuxonice-userui PTS page. Anyway, unless stdio.h is included by upstream libmng or libjpeg, upstream tuxonice-userui will want to include it. signature.asc Description: OpenPGP digital signature
Bug#759856: tuxonice-userui: FTBFS: jpeglib.h:954:30: error: unknown type name 'FILE'
Control: retitle -1 stdio.h not included anymore before jpeglib.h (causes tuxonice-userui to FTBFS) Control: reassign -1 libmng-dev Control: affects -1 src:tuxonice-userui Control: found -1 1.0.10+dfsg-3.1 Control: notfound -1 1.0.10-3 Well, I prefer to first reassign to libmng for the moment because libjpeg explicitly documents that stdio.h must be included before jpeglib.h, and it's like this for years. But feel free to forward to libjpeg. I'm curious to know why libjpeg could not even do something like: #ifndef FILE #include stdio.h #endif For libmng, this is a recent regression. The include of stdio.h was removed by the backport of lcms2 support. For more information, see also https://bugs.launchpad.net/bugs/1342459 which is now the same bug. signature.asc Description: OpenPGP digital signature
Bug#759856: tuxonice-userui: FTBFS: jpeglib.h:954:30: error: unknown type name 'FILE'
Hello, Le 08/30/14 21:05, Lucas Nussbaum a écrit : Relevant part (hopefully): cc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -O3 -DUSE_FBSPLASH -Wall -O3 -g -I/usr/include/freetype2/ -I. -c mng_callbacks.c -o mng_callbacks.o In file included from /usr/include/libmng_types.h:210:0, from /usr/include/libmng.h:386, from mng_callbacks.c:12: /usr/include/jpeglib.h:954:30: error: unknown type name 'FILE' EXTERN(void) jpeg_stdio_dest JPP((j_compress_ptr cinfo, FILE * outfile)); ^ /usr/include/jpeglib.h:955:29: error: unknown type name 'FILE' EXTERN(void) jpeg_stdio_src JPP((j_decompress_ptr cinfo, FILE * infile)); ^ make[3]: *** [mng_callbacks.o] Error 1 I confirm the issue after upgrading libmng-dev from 1.0.10-3 to 1.0.10+dfsg-3.1 I'm ready to add a patch so that stdio.h is included at the beginning mng_callbacks.c But isn't it rather a bug in /usr/include/jpeglib.h if it does not include stdio.h before using FILE ? I am tempted to reassign to both libjpeg-turbo libjpeg8 Ah, just found https://bugs.debian.org/461602 and https://bugs.launchpad.net/bugs/1342459 So maybe reassign to libmng instead. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725344: python-nemu: incompatible with recent /bin/ip
Package: python-nemu Version: 0.1-1 Severity: grave Tags: patch upstream Justification: renders package unusable Nemu depends on /bin/ip to get addresses of interfaces: ip -o addr list But recent iproute/iproute2 does not show link information anymore, making Nemu fail with following traceback: Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/nemu/protocol.py, line 272, in run cmd[0](cmd[1], *cmd[2]) File /usr/lib/python2.7/dist-packages/nemu/protocol.py, line 480, in do_ADDR_ADD nemu.iproute.add_addr(ifnr, a) File /usr/lib/python2.7/dist-packages/nemu/iproute.py, line 461, in add_addr addresses = get_addr_data()[1][ifname] File /usr/lib/python2.7/dist-packages/nemu/iproute.py, line 440, in get_addr_data bynam[name].append(_parse_ip_addr(match.group(4))) KeyError: 'lo' iproute 20120521 is the latest version that lists addresses in expected format. So this bug does not affect Wheezy. Attached patch fixes parsing of /bin/ip output. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (900, 'unstable'), (400, 'testing'), (300, 'experimental'), (200, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10.10+ (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-nemu depends on: ii bridge-utils1.5-6 ii iproute 1:3.11.0-1 ii procps 1:3.3.4-2 ii python 2.7.3-5 ii python-passfd 0.2-1 ii python-unshare 0.1-2 python-nemu recommends no packages. Versions of packages python-nemu suggests: ii xauth 1:1.0.7-1 -- no debconf information --- src/nemu/iproute.py 2012-04-02 05:00:00.0 +0200 +++ src/nemu/iproute.py 2013-10-04 13:46:16.318263897 +0200 @@ -434,9 +434,10 @@ raise RuntimeError(Invalid `ip' command output) idx = int(match.group(1)) name = match.group(2) -if match.group(3): +if name not in bynam: bynam[name] = byidx[idx] = [] -continue # link info +if match.group(3): # BBB: old iproute also shows link info +continue bynam[name].append(_parse_ip_addr(match.group(4))) return byidx, bynam
Bug#466186: FTBFS on amd64: missing library libldap_r-2.4.so.2 (for wldap32.dll.so)
Ove Kaaven a écrit : but I still want to see your config.log to figure out what's wrong with the freetype in ia32-libs. oh of course build32/config.log attached wine-0.9.54-cfg2.bz2 Description: Binary data
Bug#466186: FTBFS on amd64: missing library libldap_r-2.4.so.2 (for wldap32.dll.so)
Hmm, looks like that one could be a missing build dependency, which means there's at least *one* thing I might be able to do something about... So, try installing lib32z1-dev, what happens then? (45min to build wine without -j2) It's better: # distribute files into debian/packagename # according to the packagename.install files dh_install -s # patch marlett.ttf due to fontforge bug #458234 mensis -script debian/marlett.mensis debian/libwine/usr/share/wine/fonts/marlett.ttf ... Next errors: Forcing extra dependencies... /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../libcapi20.so when searching for -lcapi20 /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../libcapi20.a when searching for -lcapi20 /usr/bin/ld: skipping incompatible /usr/bin/../lib/libcapi20.so when searching for -lcapi20 /usr/bin/ld: skipping incompatible /usr/bin/../lib/libcapi20.a when searching for -lcapi20 /usr/bin/ld: skipping incompatible /usr/lib/libcapi20.so when searching for -lcapi20 /usr/bin/ld: skipping incompatible /usr/lib/libcapi20.a when searching for -lcapi20 /usr/bin/ld: cannot find -lcapi20 collect2: ld returned 1 exit status /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../libpng.so when searching for -lpng /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../libpng.a when searching for -lpng /usr/bin/ld: skipping incompatible /usr/bin/../lib/libpng.so when searching for -lpng /usr/bin/ld: skipping incompatible /usr/bin/../lib/libpng.a when searching for -lpng /usr/bin/ld: skipping incompatible /usr/lib/libpng.so when searching for -lpng /usr/bin/ld: skipping incompatible /usr/lib/libpng.a when searching for -lpng /usr/bin/ld: cannot find -lpng collect2: ld returned 1 exit status /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../libjack.so when searching for -ljack /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../libjack.a when searching for -ljack /usr/bin/ld: skipping incompatible /usr/bin/../lib/libjack.so when searching for -ljack /usr/bin/ld: skipping incompatible /usr/bin/../lib/libjack.a when searching for -ljack /usr/bin/ld: skipping incompatible /usr/lib/libjack.so when searching for -ljack /usr/bin/ld: skipping incompatible /usr/lib/libjack.a when searching for -ljack /usr/bin/ld: cannot find -ljack collect2: ld returned 1 exit status /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../libcups.so when searching for -lcups /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../libcups.a when searching for -lcups /usr/bin/ld: skipping incompatible /usr/bin/../lib/libcups.so when searching for -lcups /usr/bin/ld: skipping incompatible /usr/bin/../lib/libcups.a when searching for -lcups /usr/bin/ld: skipping incompatible /usr/lib/libcups.so when searching for -lcups /usr/bin/ld: skipping incompatible /usr/lib/libcups.a when searching for -lcups /usr/bin/ld: cannot find -lcups collect2: ld returned 1 exit status And a fatal one: dpkg-shlibdeps: failure: no dependency information found for /emul/ia32-linux/usr/lib/libsane.so.1 (used by debian/libwine-sane/extradep32). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466186: FTBFS on amd64: missing library libldap_r-2.4.so.2 (for wldap32.dll.so)
So, when you fixed the shlibs issue in ia32-libs, did you also fix it for libsane? No. Only libxml2, as described by #456914. dpkg-shlibdeps: failure: no dependency information found for /usr/lib32/libxml2.so.2 (used by debian/libwine/usr/lib/wine/msxml3.dll.so). dpkg-shlibdeps: failure: no dependency information found for /emul/ia32-linux/usr/lib/libsane.so.1 (used by debian/libwine-sane/extradep32). Hmmm... I didn't notice that's the same kind of error. However, I wonder why the second one doesn't happen if I build from amd64.tar.lzma.uu I guess I should add : libsane 1 ia32-libs (= 1.6) to ia32-libs.shlibs. rebuilding... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466186: FTBFS on amd64: missing library libldap_r-2.4.so.2 (for wldap32.dll.so)
Package: libwine-ldap Version: 0.9.54-1 Severity: serious Justification: no longer builds from source I have libldap-2.4-2 (2.4.7-5) installed but I still get the following error: dpkg-shlibdeps: failure: couldn't find library libldap_r-2.4.so.2 needed by debian/libwine-ldap/usr/lib/wine/wldap32.dll.so (its RPATH is ''). I suppose the problem is in ia32-libs. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24.2-1 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466186: FTBFS on amd64: missing library libldap_r-2.4.so.2 (for wldap32.dll.so)
If it said No shlibs information, then *that* would be a known bug in ia32-libs, and known to be the current reason for Wine to FTBFS on the amd64 build daemons. (I'm not sure I understand what you say.) There isn't any amd64 build daemon for Wine at this time: Dep-Wait: ia32-libs ( 2.2) because of libxml2 (#458013 #456914). On my PC, I edited /var/lib/dpkg/info/ia32-libs.shlibs manually in order to build wine myself. But your error looks more like a problem that dpkg-shlibdeps used to only treat as a warning, not an error. Does the build actually stop there, and not because of some other error? Yes it stops there. Since I don't need libwine-ldap : 1. I added a 'bash -i' line before and after: dh_shlibdeps -s -Llibwine -ldebian/libwine/usr/lib' 2. before dh_shlibdeps, I did: $ mv debian/libwine-ldap/usr/lib/wine/wldap32.dll.so .. 3. after: $ mv ../wldap32.dll.so debian/libwine-ldap/usr/lib/wine/ (Finally, I got a libwine-ldap_0.9.54-1_amd64.deb package without any dependency.) If so, what if you delete debian/amd64.tar.lzma.uu from the unpacked sources before building? That would build a Wine that only uses the 32-bit libraries that are actually available in ia32-libs (but might still fail due to No shlibs information...) Oops. Not tried, and I should redownload the source package to test. I've already upgraded Wine to 0.9.54-1. Tell me if this test would be useful to you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457557: wine: FTBFS on amd64
block 457557 by 456914 found 457557 0.9.51-1 stop Hello, The missing dependency to gcc-multilib is not the only problem. dh_shlibdeps fails for 2 reasons : The 1st one might be related to #453885 : I could work around the issue by adding /emul/ia32-linux/lib and /emul/ia32-linux/usr/lib to the -l flag. It produced many warnings. The 2nd one is already reported at #456914 : ia32-libs: Missing shlibs entry for libxml2 JM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
