Bug#910448: mgetty: CVE-2018-16741
* Salvatore Bonaccorso (car...@debian.org) [181006 21:21]: > FTR, I think if feasible best would be to go for unstable (and thus > buster) directly to 1.2.1, which will adress as well the other CVEs > (which were no-dsa or unimportant). That's the plan, yes. Andi
Bug#769791: wine32 doesn't work after fresh install
Package: wine32 Version: 1.6.2-16 Severity: serious Hi, wine32 doesn't start anymore after upgrade with a clean directory. This is a duplicate of #739863 which had been closed in wine-unstable which had been removed from unstable afterwards, so this bug is present in testing. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742140: libpam-oath: PAM module does not check whether strdup allocations succeeded
Hi,
we have the following debian bug report about an security isuse in
libpam-oath (source oath-toolkit, upstream web page
http://www.nongnu.org/oath-toolkit/ ).
What is the appropriate process to get an CVE number on it? This issue
is already public, as it is documented in the debian bug tracking
system.
Andi
* Eero Häkkinen (eer...@bigfoot.com) [141106 14:31]:
Package: libpam-oath
Version: 2.0.2-2
Severity: grave
Tags: security upstream patch
The OATH Toolkit PAM module does not check whether strdup allocations
succeeded. This may result in null pointer dereference and application
crash.
Depending on the use of the PAM module, this may be remotely exploitable.
diff --git a/pam_oath/pam_oath.c b/pam_oath/pam_oath.c
index 8379358..e2d3363 100644
--- a/pam_oath/pam_oath.c
+++ b/pam_oath/pam_oath.c
@@ -146,6 +146,12 @@ pam_sm_authenticate (pam_handle_t * pamh,
char *query_prompt = NULL;
char *onlypasswd = strdup ();/* empty passwords never match */
+ if (!onlypasswd)
+{
+ retval = PAM_BUF_ERR;
+ goto done;
+}
+
parse_cfg (flags, argc, argv, cfg);
retval = pam_get_user (pamh, user, NULL);
@@ -265,6 +271,11 @@ pam_sm_authenticate (pam_handle_t * pamh,
{
free (onlypasswd);
onlypasswd = strdup (password);
+ if (!onlypasswd)
+{
+ retval = PAM_BUF_ERR;
+ goto done;
+}
/* user entered their system password followed by generated OTP? */
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766484: FTBFS in a cowbuilder: Error: listen EADDRNOTAVAIL
Hi,
just trying on an i386 buildd, it fails by:
ln -fs out/Release/node node
/usr/bin/python tools/test.py --arch=ia32 simple
=== release test-crypto-stream ===
Path: simple/test-crypto-stream
assert.js:92
throw new assert.AssertionError({
^
AssertionError: false == true
at Decipheriv.end (/«PKGBUILDDIR»/test/simple/test-crypto-stream.js:74:5)
at Decipheriv.anonymous (/«PKGBUILDDIR»/test/common.js:198:15)
at Decipheriv.emit (events.js:117:20)
at done (_stream_transform.js:190:19)
at _stream_transform.js:131:9
at Decipheriv.Cipher._flush (crypto.js:269:5)
at Decipheriv.anonymous (_stream_transform.js:130:12)
at Decipheriv.g (events.js:180:16)
at Decipheriv.emit (events.js:117:20)
at finishMaybe (_stream_writable.js:360:12)
Command: out/Release/node /«PKGBUILDDIR»/test/simple/test-crypto-stream.js
[03:34|% 100|+ 607|- 1]: Done
make[1]: *** [test-simple] Error 1
Makefile:114: recipe for target 'test-simple' failed
make[1]: Leaving directory '/«PKGBUILDDIR»'
make: *** [debian/stamp-makefile-check] Error 2
/usr/share/cdbs/1/class/makefile.mk:67: recipe for target
'debian/stamp-makefile-check' failed
Andi
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763148: Prevent migration to jessie
* Andreas Cadhalpun (andreas.cadhal...@googlemail.com) [141005 22:36]: That's because the last message from a release team member in this bug said [1]: 'However (and please note that I'm not a member of the security team and just speak for myself here as always when not otherwise marked) if As I said, I was just speaking for myself. That I might be at other times speaking as a member of the release team doesn't make it an opinion of the release team. For the release team opinion on this topic seen Cyrils mails. Also, the re-evaluation happened. It however didn't had the outcome you wanted (basically because the web browser needs so many security updates which only could be done by backporting all of it that the embedded copy doesn't make any difference - this is an exceptional thing which does happen but not very often. I can understand it, and of course it's the call of the security team how to ensure that Debian has security updates. I hadn't know that at the time I though about the possibility, otherwise I would have already achived at that moment at the conclusion). Conclusion: Though I'm usually an optimistic person how to get things achived, I don't see any way left how at this late time it's possible to ship with ffmpeg in jessie. I'm sorry but we have to face the facts. Independend if we like them or not (and I can fully understand that you don't like them, but it's no good pretending facts are different than they are). Sorry. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764161: yc-el: emacs23 likley to be removed
Package: yc-el Version: 5.0.0-5 Severity: serious Hi, please see bug #753885, emacs23 is going to be removed. So please update the dependencies of yc-el accordingly. Regards, Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763855: xchat FTBFS on ppc64el, hurd, kfreebsd
Control: tag -1 + patch * Andreas Barth (a...@ayous.org) [141003 10:48]: Even though the non-working one is longer, it misses -lm -lgmodule-2.0 -ldl. Of those the -lgmodule-2.0 is the relevant one. To add this lib I hardcoded the following into configure.in: GUI_LIBS=$GUI_LIBS $COMMON_LIBS `$pkgconfigpath --libs gmodule-2.0` (instead of GUI_LIBS=$GUI_LIBS $COMMON_LIBS ). I'm sure it's not nice, but it at least works. A better solution would be appreciated though, but for Debian purposes it might even be good enough already. (To use that, I run autoreconf by dh_autoreconf with the usual patches, and to get that working, I needed to add to configure.in AM_GNU_GETTEXT_VERSION(0.19) (after the AUTOTEXT-macros). But from here on, that's only regular auto-reconfing.) Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763855: xchat FTBFS on ppc64el, hurd, kfreebsd
Package: xchat Version: 2.8.8-7.1 Severity: serious Hi, xchat FTBFS on three different architectures, one of them being a release architecture it built before. The error is the same everywhere: /usr/bin/ld: plugin-tray.o: undefined reference to symbol 'g_module_symbol' while linking xchat That seems to come from linktool not using the right DSOs. If I copy the linking command from the x86-build and do that by hand, I could continue to build the binary packages. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763855: xchat FTBFS on ppc64el, hurd, kfreebsd
* Andreas Barth (a...@ayous.org) [141003 10:35]: That seems to come from linktool not using the right DSOs. If I copy the linking command from the x86-build and do that by hand, I could continue to build the binary packages. Further investigation shows that replacing GUI_LIBS with the value from x86 is enough to build correctly. Working is (... is same on both arches): ... -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 ... Not working: ... -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype ... Even though the non-working one is longer, it misses -lm -lgmodule-2.0 -ldl. Of those the -lgmodule-2.0 is the relevant one. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763855: xchat FTBFS on ppc64el, hurd, kfreebsd
* Andreas Barth (a...@ayous.org) [141003 10:48]: Even though the non-working one is longer, it misses -lm -lgmodule-2.0 -ldl. Of those the -lgmodule-2.0 is the relevant one. And the reason for that is that pkg-config --libs libsexy = 0.1.8 gives different output. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763855: xchat FTBFS on ppc64el, hurd, kfreebsd
* Andreas Barth (a...@ayous.org) [141003 11:00]:
* Andreas Barth (a...@ayous.org) [141003 10:48]:
Even though the non-working one is longer, it misses -lm -lgmodule-2.0
-ldl. Of those the -lgmodule-2.0 is the relevant one.
And the reason for that is that
pkg-config --libs libsexy = 0.1.8
gives different output.
And then again, that's
#561260 [n| | ] [libsexy-dev] libsexy-dev: libsexy uses libs and cflags
directly in pkg-config file
I intend to upload an NMU to libsexy soon which fixes this bug, and
also the following bugs:
#751289 [n|+| ] [libsexy] libsexy: run dh-autoreconf to update config.{sub,
guess} and {libtool, aclocal}.m4
#615290 [m| | ] [libsexy-dev] libsexy-dev: please use Homepage field to point
to upstream homepage
Andi
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763360: Bug#754988: Bug#763360: libjpeg-turbo is hijacking binaries from other source packages
Hi, looking a bit from the outside it looks to me as different questions discussed in parallel. The one question is how we came here. * Bill Allombert (ballo...@debian.org) [141003 12:15]: On Fri, Oct 03, 2014 at 01:41:02AM +0200, Emilio Pozuelo Monfort wrote: On 30/09/14 11:32, Bill Allombert wrote: On Mon, Sep 29, 2014 at 08:55:16PM +0200, Ondřej Surý wrote: Bill, I am very sorry that I have not Cced everything related to the libjpeg-transition to you. I have honestly believed that you and everyone else involved was following the transition plan as mentioned in #717076#225. As for the takover of the libjpeg62* packages it was discussed in the transition plan bug #754988. Bad faith ? No I do not think so. [...] ... and neither of you bothered to ask me. Ondřej already said he thought while uploading that you were involved, and notices now that you weren't and is sorry that he didn't CC you to all mails. I can understand that you are angry about the uploaded packages. I'm not going to argue about what the tech ctte resolution was, and what could or should be interpreted into it or not, because that is not helpful. Uploading the package as happend and without proper discussion before was a mistake, and Ondřej already accepted his responsibility for it. So while an mistake is never good, mistakes can happen, and I personally always consider it a good thing if people stand to their actions and apologize if appropriate. I hope we could leave it as that for the upload - nobody has a time machine to undo the upload, but we could try to make it better now and discuss where we should go. The other question is: Where from here? What should be the appropriate state of packages within Debian for the release? It's a pity that we lost time, but we still could adjust things so they are best for Debian, based on the (spirit of the) initial decision of the tech ctte (and in case the relevant people cannot agree, of course another decision of the tech ctte would be possible, but I really hope we could avoid that and conclude on something acceptable for all). (And of course, any question not already decided by the tech ctte could be discussed and hopefully also answered here - which source package will build libjpeg62* is part of that.) Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761650: llvm-toolchain-3.5 still FTBFSing on kbsd
Control: user debian-...@lists.debian.org Control: usertags -1 kfreebsd Hi, this package still FTBFS on kbsd: llvm[5]: Linking Release Shared Library liblldb.so g++-4.9 -std=c++0x -g -O2 -Wl,-R -Wl,'$ORIGIN' -Wl,--gc-sections -rdynamic -L/«PKGBUILDDIR»/build-llvm/Release/lib -L/«PKGBUILDDIR»/build-llvm/Release/lib -shared -o /«PKGBUILDDIR»/build-llvm/Release/lib/liblldb.so \ -Wl,--whole-archive -llldbAPI -llldbBreakpoint -llldbCommands -llldbCore -llldbDataFormatters -llldbExpression -llldbHostCommon -llldbInitAndLog -llldbInterpreter -llldbPluginABIMacOSX_arm -llldbPluginABIMacOSX_arm64 -llldbPluginABIMacOSX_i386 -llldbPluginABISysV_x86_64 -llldbPluginABISysV_hexagon -llldbPluginDisassemblerLLVM -llldbPluginDynamicLoaderStatic -llldbPluginDynamicLoaderPOSIX -llldbPluginDynamicLoaderHexagon -llldbPluginEmulateInstructionARM -llldbPluginEmulateInstructionARM64 -llldbPluginLanguageRuntimeCPlusPlusItaniumABI -llldbPluginLanguageRuntimeObjCAppleObjCRuntime -llldbPluginObjectContainerBSDArchive -llldbPluginObjectFileELF -llldbPluginObjectFileJIT -llldbPluginSymbolVendorELF -llldbPluginObjectFilePECOFF -llldbPluginOperatingSystemPython -llldbPluginPlatformGDBServer -llldbPluginProcessGDBRemote -llldbPluginSymbolFileDWARF -llldbPluginSymbolFileSymtab -llldbPluginUnwindAssemblyInstEmulation -llldbPluginUnwindAssemblyx86 -llldbPluginUtility -llldbSymbol -llldbTarget -llldbUtility -lclangAnalysis -lclangAST -lclangBasic -lclangCodeGen -lclangFrontend -lclangDriver -lclangEdit -lclangLex -lclangParse -lclangSema -lclangSerialization -lLLVMMCDisassembler -lLLVMObjCARCOpts -lLLVMProfileData -llldbPluginPlatformMacOSX -llldbPluginPlatformLinux -llldbPluginPlatformWindows -llldbPluginPlatformFreeBSD -llldbPluginPlatformPOSIX -llldbPluginPlatformKalimba -llldbHostFreeBSD -llldbPluginProcessPOSIX -llldbPluginProcessFreeBSD -llldbPluginProcessElfCore -llldbPluginJITLoaderGDB -Wl,--no-whole-archive -lLLVM-3.5 -Wl,--no-undefined -L/usr/lib/python2.7/config-x86_64-kfreebsd-gnu -L/usr/lib -lpthread -ldl -lutil -lm -lpython2.7 -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions -lrt -ledit -lncurses -lpanel -Wl,--soname,liblldb.so.1 -lz -lpthread -lffi -ledit -ltinfo -ldl -lm /«PKGBUILDDIR»/build-llvm/Release/lib/liblldbExpression.a(ClangExpressionParser.o): In function `lldb_private::ClangExpressionParser::Parse(lldb_private::Stream)': /«PKGBUILDDIR»/tools/lldb/source/Expression/ClangExpressionParser.cpp:324: warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp' /usr/bin/ld: .eh_frame_hdr refers to overlapping FDEs. /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status make[5]: *** [/«PKGBUILDDIR»/build-llvm/Release/lib/liblldb.so] Error 1 The error .eh_frame_hdr had already be seen elsewhere and on other architectures for example llvm-3.4 on s390x so I'm not sure what the real cause is, and how kbsd specific it is. I assume we will see it more and more often on more architectures when more chroots are updated. The error message had been introduced with http://permalink.gmane.org/gmane.comp.gnu.binutils/66759 to detect an error, so we seem to need a fix for the underlying error. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763801: dico FTBFS on several arches
Package: dico Version: 2.2-6 Severity: serious Hi, this package fails to build on several architectures. For arm64, I'd recommend using dh_autoreconf (which would be good for all arches in future). For s390x and mips*, the build fails with the following errors: ## ## ## GNU dico 2.2 test suite. ## ## ## Match 1: exact FAILED (exact.at:19) 2: prefix FAILED (prefix.at:19) 3: suffix FAILED (suffix.at:19) 4: Levenshtein FAILED (lev.at:19) Define 5: define FAILED (define.at:19) Show 6: show db FAILED (showdb.at:19) 7: show info FAILED (showinfo.at:19) 8: show lang info FAILED (showlang.at:19) ## - ## ## Test results. ## ## - ## ERROR: All 8 tests were run, 8 failed unexpectedly. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763802: guile-cairo FTBFS on armhf / armel because of broken guile-??-dev
Package: guile-cairo
Version: 1.4.0-3.1
Severity: serious
Hi,
this package FTBFS on armhf / armel with
guile-snarf -I/usr/include/cairo -I/usr/include/glib-2.0
-I/usr/lib/arm-linux-gnueabi/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng12 -I. -Wall -Werror -pthread
-I/usr/include/guile/2.0 guile-cairo.c guile-cairo.x \
|| { rm guile-cairo.x; false; }
/usr/bin/guile-snarf: 54: /usr/bin/guile-snarf: gcc-4.8: not found
make[3]: *** [guile-cairo.x] Error 1
Andi
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745969: guile-1.8: FTBFS: conflicting types for 'yyget_leng'
* Rob Browning (r...@defaultvalue.org) [141002 18:59]: Daniel Schepler dschep...@gmail.com writes: Well, I was actually just pulling it into my bootstrapping process as a build dependency of swig2.0 and autogen. OK, I've filed migration bugs against both. I'm guessing that perhaps once they migrate, you can migrate? I'm not sure if this will actually happen in time for jessie, because looking at the current packages in testing using guile-1.8: anubis: anubis [amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x] not yet updated, no explizit patch dico: dico-module-guile [amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x] FTBFS on three arches since the update, bug just filed drgeo: drgeo [amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x] Bug closed by package still depends on guile-1.8 gnubik: gnubik [amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x] waiting for migration (3 of 5 days) guile-cairo: guile-cairo [amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x] guile-cairo-dev [amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x] FTBFS on two arches since the update, because guile-snarf depends on gcc-4.8 without an package dependency (at least on armhf / armel), bug just filed guile-lib: guile-library Still depends on guile-1.8 in spite of the NMU lilypond: lilypond [amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x] waiting on upstream mailutils: mailutils-guile not fixed trackballs: trackballs [amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x] nothing yet Especially as the freeze is in about a month, I don't think this will be acomplished unless someone is pushing really hard right now. So I think it would be helpful to fix the guile-1.8-bug now. Of course, individual packages could still migrate to guile-2.0 as they consider fit, until the freeze date. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763593: openjpegs binaries are taken over
Package: openjpeg Version: 1.5.2-2 Severity: serious Hi, the following packages from openjpeg are taken over by another package: openjpeg-tools, openjpip-dec-server, openjpip-server, openjpip-viewer Amongst others that leads to the fact that openjpeg can't be uploaded anymore because any upload would be rejected because there are too new packages in the archive. This is also true after openjpeg2 dropped those packages because they are uploaded to unstable, and new uploads need a higher version number. As it is planned to get rid of openjpeg (see #761356 ) I would recommend to just drop the packages from openjpeg. As this is required for testing migration of the new architectures I'd intend to upload this fix to unstable in about a week unless there is a reason why not. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763593: openjpegs binaries are taken over
* Andreas Barth (a...@ayous.org) [141001 20:23]: As it is planned to get rid of openjpeg (see #761356 ) I would recommend to just drop the packages from openjpeg. We had some discussion on this on #-ftp today. One is that it seems that jessie will release with openjpeg, not openjpeg2. The other is that Adam D. Barratt had given the recommendation to upload openjpeg with an epoch to take back the packages. As both are connected and fit to each other, this is what I plan to do. I'm happy to support you by uploading an appropriate NMU. Please just indicate if that would help you. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708716: mame: ftbfs with eglibc-2.17
* Cesare Falco (cesare.fa...@gmail.com) [141002 05:36]: Hello Jeremy, I have made a short patch on my git development branch to be committed ASAP and fowarded the issue upstream. I guess it will be fixed in 0.149. Would be nice if you could upload the fixed version soon. The freeze is upcoming. I tried to build on top of git, it fails with No package 'gtk+-2.0' found Package gconf-2.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `gconf-2.0.pc' to the PKG_CONFIG_PATH environment variable No package 'gconf-2.0' found In file included from src/osd/sdl/dview.c:2:0: src/osd/sdl/dview.h:4:21: fatal error: gtk/gtk.h: No such file or directory #include gtk/gtk.h ^ compilation terminated. Installing of libgtk2.0-dev and libgconf2-dev helped compiling the package, so they should be added to build-dependencies (or configuration options tweaked so that they are no longer needed). Even git fails to build with Linking mame... /usr/bin/ld: obj/sdl64/libocore.a(sdlsync_tc.o): undefined reference to symbol 'pthread_join@@GLIBC_2.17' //lib/powerpc64le-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status makefile:762: recipe for target 'mame' failed Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763148: Prevent migration to jessie
* Andreas Cadhalpun (andreas.cadhal...@googlemail.com) [140928 11:27]: On 28.09.2014 10:24, Moritz Muehlenhoff wrote: Package: ffmpeg Severity: serious As written before we can have only libav or ffmpeg in jessie. I'm filing this blocker bug to prevent testing migration until this is sorted out. As I have explained [1], I see no security problem with having FFmpeg and Libav in Jessie, in particular because this is already the case for Wheezy, as chromium embeds a copy of FFmpeg. First of all, I think it is very good news that we now have FFmpeg available in Debian. Thank you for your work on it, it's appreciated. However, the open question is (especially with the upcoming release), do we want to have it in jessie? (That we probably want FFmpeg in testing in the long run is something else, but the current discussion is especially about jessie.) I also think it's good that you actively raised this discussion, even if it is perhaps not working as you would have like it. Please continue this good style. Another remark, we are already quite late in the cycle. At this point it is too late to have greater changes to jessie. So even if jessie is not officially frozen, larger changes are not possible anymore (without disturbing the time plan). So would you please explain why you see a problem? I hope we end this discussion on an agreement about the jessie plans. However, to avoid misunderstandings at a later moment, I need to point out that the final decision of what is part of jessie is taken by the release team (or ultimatly the release managers). All of RC-bugs, testing migration scripts etc are very valuable helpers because it wouldn't be possible to manage it otherwise, but in the end they are helpers. The release policy does say Packages must be security-supportable. I would be surprised if a statement from the security team (assuming that Moritz raised that bug report with his security team-hat on and not privately) that they would like to have only one of libav and ffmpeg in jessie would be overruled by the release team. Now seeing the statements from the libav maintainers (which of course, as this is an overlaping jurisdiction, could be escalated to the tech ctte), that we already have transition freeze and the time planings for jessie, makes it quite unlikely (or rather: impossible) to switch from libav to FFmpeg in time for jessie. (Of course, for jessie+1 there is enough time for the transition. And for jessie+1 we will have enough experience with FFmpeg in Debian to perhaps see things in a different light.) So from my experience I assume the final answer would look similar to It's too late for jessie, sorry. Which might be a pity but, well, that's how it is. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763148: Prevent migration to jessie
* Andreas Cadhalpun (andreas.cadhal...@googlemail.com) [140928 14:36]: On 28.09.2014 12:47, Andreas Barth wrote: The release policy does say Packages must be security-supportable. I would be surprised if a statement from the security team (assuming that Moritz raised that bug report with his security team-hat on and not privately) that they would like to have only one of libav and ffmpeg in jessie would be overruled by the release team. Nonetheless both are in wheezy and will be in jessie, unless chromium gets removed from testing. There is a distinction between an old and a new package. However (and please note that I'm not a member of the security team and just speak for myself here as always when not otherwise marked) if it would be possible to replace the internal code copy in chromium by a reference to ffmpeg (but it's not possible with libav), that will probably lead to a re-evalutation. (That doesn't necessarily mean sucess guranteed, but it looks to me as it will not make things worse.) Perhaps you always intended that, but at least I didn't understand it that way yet. I absolutely cannot understand why the security team would prefer to have an embedded code copy instead of a properly packaged library. I don't think they do that. However, I can understand why one embedded code copy is better than one embedded code copy plus a library in addition to it. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762959: ABI break: missing libclang.so.1
Hi, * Sylvestre Ledru (sylves...@debian.org) [140927 20:10]: On 26/09/2014 17:52, Helmut Grohne wrote: Package: libclang1-3.5 Version: 1:3.5-2 Severity: serious Control: affects -1 doxygen Dear clang maintainers, I noticed that installing doxygen in a fresh sid chroot results in an unusable binary: $ doxygen doxygen: error while loading shared libraries: libclang.so.1: cannot open shared object file: No such file or directory $ I am sorry about that. I have a build running which should fix that. I will let you know later today. Helmut pointed out on IRC that the symlink from from libclang-3.5.so.1 to /usr/lib/`dpkg-architecture -qDEB_BUILD_MULTIARCH`/libclang.so.1 is missing if the package libclang1 is installed. My investigation pointed to the fact that the file installed in /usr/lib/(arch)/libclang-3.5.so.1 has now the soname libclang-3.5.so and not anymore libclang.so.1. So the ldconfig-call in postinst doesn't create the symlink from libclang.so.1 to libclang-3.5.so.1 anymore. The probably best fix for that would be to go back to the previous soname if there is no strong reason against. Otherwise changing soname means that a new library package should be created, but as we are already past transition time for the next release, that would be better early in the next cycle. (If a new library package is created, binNMUs are possible to replace the binary packages with links to the new library package. As it is now, any package built against libclang1 will become unusable in testing if it migrates on its own, and has wrong and broken dependencies.) Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763115: guile-2.0 FTBFS on armhf
Package: guile-2.0
Version: 2.0.11+1-5
Severity: serious
Hi,
guile-2.0 now FTBFS on armhf:
CC libguile_2.0_la-regex-posix.lo
In file included from vm.c:668:0:
vm-engine.c: In function 'vm_regular_engine':
vm-engine.c:168:1: error: r7 cannot be used in asm here
}
^
CC guile-guile.o
flex -t ./c-tokenize.lex c-tokenize.c || { rm c-tokenize.c; false; }
GEN c-tokenize.o
GEN guile_filter_doc_snarfage
make[4]: *** [libguile_2.0_la-vm.lo] Error 1
make[4]: *** Waiting for unfinished jobs
Makefile:3190: recipe for target 'libguile_2.0_la-vm.lo' failed
(I thought we already had a bit of discussion about that last weekend,
but failing to find the bug report I submit this one now.)
Andi
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761650: closed by Sylvestre Ledru sylves...@debian.org (Bug#761650: fixed in llvm-toolchain-3.5 1:3.5-2~exp1)
Hi, * Debian Bug Tracking System (ow...@bugs.debian.org) [140921 20:09]: Source: llvm-toolchain-3.5 Source-Version: 1:3.5-2~exp1 We believe that the bug you reported is fixed in the latest version of llvm-toolchain-3.5, which is due to be installed in the Debian FTP archive. would it be possible to upload that to unstable as well soon? Currently llvm-toolchain-3.5 blocks the testing-migration of doxygen. Thanks, Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761316: printer-driver-splix depends on ghostscript-cups, which is not built anymore by src:ghostscript
* Luca Niccoli (lultimou...@gmail.com) [140918 08:25]: Hi, I will look into this in the next few days. The dependency should be on the gstoraster executable which is now indeed in cups-filter. Sorry for pressing on that, but this blocks the testing migration of ghostscript, which in turn is necessary for getting the number of uninstallabilities down for the new arches. So there are two options, either getting this fixed asap, or remove splix from testing. I'd be happy if I could help getting this fixed, and if it would be useful I'd be happy to sponsor an upload, or to do an NMU. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756908: [Debichem-devel] Bug#756908: ergo: FTBFS on mips, mipsel, powerpc, s390x: test suite failures
* Michael Banck (mba...@debian.org) [140915 01:49]: CCing the powerpc and mipsel buildd maintainers for that. given back ergo on both architectures. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759595: libgraphicsmagick1-dev uninstallable (once sid cleaned up by ftp-masters)
Package: libgraphicsmagick1-dev Version: 1.3.20-1 Severity: serious Hi, libgraphicsmagick1-dev still has a dependency on libtiff4-dev, but this package had been removed from tiff since the 4.0.3-10 upload (and will disappear from sid with the next cleanup cycle by ftp-masters). The (trivial) fix is to adjust to libtiff-dev. Tiffs changelog says: Remove libtiff4-dev, completing the tiff transition. Packages that still declare build dependencies on libtiff4-dev must now build depend on libtiff-dev instead, or if a versioned dependency is required, libtiff5-dev with a specific version. This is blocking build of inkscape on ppc64el, so it would be nice if you could upload a fix soon. If it would help, I'd be willing to upload an NMU with the fix included (and if there is no reason not to, I'd do so within the next days). Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759100: openjade FTBFS now
Package: openjade Version: 1.4devel1-21 Severity: serious Hi, while bootstrapping on ppc64el I found that openjade FTBFS now. I retried on the amd64 porterbox, and the result is as follows. Andi g++ -g --pipe -fpermissive -O2 -o .libs/openjade jade.o SgmlFOTBuilder.o RtfFOTBuilder.o HtmlFOTBuilder.o TeXFOTBuilder.o TransformFOTBuilder.o MifFOTBuilder.o MessageModule.o ../style/.libs/libostyle.so ../spgrove/.libs/libospgrove.so ../grove/.libs/libogrove.so -losp -lpthread creating openjade make[4]: Leaving directory '/home/aba/openjade-1.4devel1/jade' make[3]: Leaving directory '/home/aba/openjade-1.4devel1/jade' Making all in intl make[3]: Entering directory '/home/aba/openjade-1.4devel1/intl' Makefile:210: *** missing separator (did you mean TAB instead of 8 spaces?). Stop. make[3]: Leaving directory '/home/aba/openjade-1.4devel1/intl' Makefile:308: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/home/aba/openjade-1.4devel1' Makefile:212: recipe for target 'all' failed make[1]: *** [all] Error 2 make[1]: Leaving directory '/home/aba/openjade-1.4devel1' debian/rules:116: recipe for target 'build-stamp' failed make: *** [build-stamp] Error 2 dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748626: openjade FTBFS Makefile:210: *** missing separator (did you mean TAB instead of 8 spaces?).
* Wookey (woo...@wookware.org) [140824 13:34]: or just use dh_autoreconf which I think does exactly the same thing. So with the attached patch the configure goes OK and the build proceeds but eventually stops with: make[3]: Entering directory '/home/buildd/packages/modified/openjade-1.4devel1/po' make[3]: *** No rule to make target 'Makevars', needed by 'Makefile'. Stop. One could create a Makevars from Makevars.template (or rather, I copied the template to Makevars and ran sed -e 's,COPYRIGHT_HOLDER.*,COPYRIGHT_HOLDER = see po-files,' -i po/Makevars ). After doing so, the build fails at a later stage, because the PACKAGE-variable is now used as openjade but should be OpenJade (as also seen in configure.in). (One could adjust the installation paths of course or move files around, but that doesn't seem to be the right solution.) Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748626: openjade FTBFS Makefile:210: *** missing separator (did you mean TAB instead of 8 spaces?).
* Andreas Barth (a...@ayous.org) [140824 15:37]: * Wookey (woo...@wookware.org) [140824 13:34]: or just use dh_autoreconf which I think does exactly the same thing. So with the attached patch the configure goes OK and the build proceeds but eventually stops with: make[3]: Entering directory '/home/buildd/packages/modified/openjade-1.4devel1/po' make[3]: *** No rule to make target 'Makevars', needed by 'Makefile'. Stop. One could create a Makevars from Makevars.template (or rather, I copied the template to Makevars and ran sed -e 's,COPYRIGHT_HOLDER.*,COPYRIGHT_HOLDER = see po-files,' -i po/Makevars ). After doing so, the build fails at a later stage, because the PACKAGE-variable is now used as openjade but should be OpenJade (as also seen in configure.in). (One could adjust the installation paths of course or move files around, but that doesn't seem to be the right solution.) With these changes everything builds as it should: --- configure.in~ 2014-08-24 12:52:22.667482046 + +++ configure.in2014-08-24 13:55:47.737475362 + @@ -11,7 +11,7 @@ dnl dnl Initialization -AC_INIT([OpenJade], [1.4devel], []) +AC_INIT([OpenJade], [1.4devel], [], [OpenJade]) AC_CONFIG_SRCDIR(dsssl) AM_INIT_AUTOMAKE([foreign]) AM_CONFIG_HEADER([config.h]) --- po/Makevars.template2014-08-24 13:52:30.699437001 + +++ po/Makevars 2014-08-24 13:08:04.215437344 + @@ -18,7 +18,7 @@ # or entity, or to disclaim their copyright. The empty string stands for # the public domain; in this case the translators are expected to disclaim # their copyright. -COPYRIGHT_HOLDER = Free Software Foundation, Inc. +COPYRIGHT_HOLDER = see po-files # This tells whether or not to prepend GNU prefix to the package # name that gets inserted into the header of the $(DOMAIN).pot file. The libos*-packages are as they should. However, the programm misses the jade.mo-files, so something still needs to be done. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748626: openjade FTBFS Makefile:210: *** missing separator (did you mean TAB instead of 8 spaces?).
* Andreas Barth (a...@ayous.org) [140824 16:07]: The libos*-packages are as they should. However, the programm misses the jade.mo-files, so something still needs to be done. This is fixed by setting the domain in Makevars. I intend to upload the NMU as below later today (generated files removed from the diff). (I'll probably also add some more rm to debian/rules clean target to remove generated files which are not there currently.) Andi diff -Nru openjade-1.4devel1/configure.in openjade-1.4devel1/configure.in --- openjade-1.4devel1/configure.in 2014-08-24 14:17:28.0 + +++ openjade-1.4devel1/configure.in 2014-08-24 14:17:28.0 + @@ -11,11 +11,13 @@ dnl dnl Initialization -AC_INIT(dsssl) -AM_INIT_AUTOMAKE(OpenJade, 1.4devel, no-define) -AM_CONFIG_HEADER(config.h) +AC_INIT([OpenJade], [1.4devel], [], [OpenJade]) +AC_CONFIG_SRCDIR(dsssl) +AM_INIT_AUTOMAKE([foreign]) +AM_CONFIG_HEADER([config.h]) AM_SANITY_CHECK AM_MAINTAINER_MODE +AC_USE_SYSTEM_EXTENSIONS dnl Use different names than usually to avoid conflicts. AC_DEFINE_UNQUOTED(OPENJADE_PACKAGE, $PACKAGE, [Package name]) @@ -36,8 +38,8 @@ dnl Checks for libraries. AC_CHECK_LIB(pthread,pthread_create,,AC_CHECK_LIB(threads,cthread_fork)) AM_GNU_GETTEXT -AM_GNU_GETTEXT_VERSION -AC_CHECK_HEADERS(locale.h) +AM_GNU_GETTEXT_VERSION([0.19.2]) +AC_CHECK_HEADERS([locale.h]) AC_DEFINE_DIR(OPENJADE_LOCALE_DIR, datadir/locale, [location of message catalogs]) OPENJADE_MESSAGE_DOMAIN=jade AC_DEFINE_UNQUOTED(OPENJADE_MESSAGE_DOMAIN, $OPENJADE_MESSAGE_DOMAIN, [message domain]) @@ -46,13 +48,13 @@ dnl Checks for header files. AC_HEADER_STDC -AC_CHECK_HEADERS(limits.h) -AC_LANG_CPLUSPLUS +AC_CHECK_HEADERS([limits.h]) +AC_LANG([C++]) AC_CHECK_HEADERS(new cassert) dnl Checks for typedefs, structures and compiler characteristics. AC_TYPE_SIZE_T -AC_STRUCT_ST_BLKSIZE +AC_CHECK_MEMBERS([struct stat.st_blksize]) AC_CACHE_CHECK(for sig_atomic_t in signal.h, ac_cv_have_sig_atomic_t, AC_TRY_LINK([#include signal.h],sig_atomic_t x;, diff -Nru openjade-1.4devel1/debian/changelog openjade-1.4devel1/debian/changelog --- openjade-1.4devel1/debian/changelog 2014-08-24 14:17:28.0 + +++ openjade-1.4devel1/debian/changelog 2014-08-24 14:17:28.0 + @@ -1,3 +1,19 @@ +openjade (1.4devel1-21.1) unstable; urgency=medium + + [ Wookey ] + * Add acinclude.m4 macro to find correct intlh header whether or +not gettext is present (Closes: #748626, ##759100) + * Update rules file to use dh-autoreconf rather than manual commands +and update configure.in enough for autoreconf to work + + [ Andreas Barth ] + * Non-maintainer upload. + * Update configure.in to set PACKAGE_TARNAME to mixed case. + * Create po/Makevars with copyright hint to individual pot files +and DOMAIN=jade + + -- Andreas Barth a...@ayous.org Sun, 24 Aug 2014 12:47:55 + + openjade (1.4devel1-21) unstable; urgency=low * Added dependency on libperl4-corelibs-perl for getopts.pl. (Closes: diff -Nru openjade-1.4devel1/debian/control openjade-1.4devel1/debian/control --- openjade-1.4devel1/debian/control 2014-08-24 14:17:28.0 + +++ openjade-1.4devel1/debian/control 2014-08-24 14:17:28.0 + @@ -4,7 +4,7 @@ Maintainer: Neil Roeth n...@debian.org Homepage: http://openjade.sourceforge.net/ Standards-Version: 3.9.2.0 -Build-Depends: libosp-dev (= 1.5.1.0-2.1), debhelper (= 4.1.75), autotools-dev, gettext, dh-buildinfo, libperl4-corelibs-perl +Build-Depends: libosp-dev (= 1.5.1.0-2.1), debhelper (= 4.1.75), dh-autoreconf, gettext, dh-buildinfo, libperl4-corelibs-perl Package: openjade Architecture: any diff -Nru openjade-1.4devel1/debian/rules openjade-1.4devel1/debian/rules --- openjade-1.4devel1/debian/rules 2014-08-24 14:17:28.0 + +++ openjade-1.4devel1/debian/rules 2014-08-24 14:17:28.0 + @@ -77,13 +77,6 @@ mv OpenJade-1.4devel/ChangeLog . rm -r OpenJade-1.4devel -autoinit: - aclocal - autoheader - libtoolize --force --copy - automake --add-missing --force-missing --copy - autoconf - clean: dh_testdir rm -f debian/buildinfo @@ -96,14 +89,11 @@ style/DssslAppMessages.h jade/JadeMessages.h \ jade/RtfMessages.h jade/HtmlMessages.h jade/TeXMessages.h \ jade/MifMessages.h - # See /usr/share/doc/autotools-dev/README.Debian.gz - -test -r /usr/share/misc/config.sub \ - cp -f /usr/share/misc/config.sub config.sub - -test -r /usr/share/misc/config.guess \ - cp -f /usr/share/misc/config.guess config.guess + dh_autoreconf_clean configure: configure-stamp configure-stamp: + dh_autoreconf dh_buildinfo generate cat ./configure --prefix=/usr --enable-http --enable-shared --enable-static touch $@ diff -Nru openjade-1.4devel1/po/Makevars openjade-1.4devel1/po/Makevars --- openjade
Bug#748626: openjade FTBFS Makefile:210: *** missing separator (did you mean TAB instead of 8 spaces?).
* Andreas Barth (a...@ayous.org) [140824 16:31]: I intend to upload the NMU as below later today (generated files removed from the diff). (I'll probably also add some more rm to debian/rules clean target to remove generated files which are not there currently.) Final diff, upload will happen in ~2 hours if nobody yells at me. Andi diff -u openjade-1.4devel1/debian/changelog openjade-1.4devel1/debian/changelog --- openjade-1.4devel1/debian/changelog +++ openjade-1.4devel1/debian/changelog @@ -1,3 +1,19 @@ +openjade (1.4devel1-21.1) unstable; urgency=medium + + [ Wookey ] + * Add acinclude.m4 macro to find correct intlh header whether or +not gettext is present (Closes: #748626, ##759100) + * Update rules file to use dh-autoreconf rather than manual commands +and update configure.in enough for autoreconf to work + + [ Andreas Barth ] + * Non-maintainer upload. + * Update configure.in to set PACKAGE_TARNAME to mixed case. + * Create po/Makevars with copyright hint to individual pot files. +and DOMAIN=jade + + -- Andreas Barth a...@ayous.org Sun, 24 Aug 2014 12:47:55 + + openjade (1.4devel1-21) unstable; urgency=low * Added dependency on libperl4-corelibs-perl for getopts.pl. (Closes: diff -u openjade-1.4devel1/debian/control openjade-1.4devel1/debian/control --- openjade-1.4devel1/debian/control +++ openjade-1.4devel1/debian/control @@ -4,7 +4,7 @@ Maintainer: Neil Roeth n...@debian.org Homepage: http://openjade.sourceforge.net/ Standards-Version: 3.9.2.0 -Build-Depends: libosp-dev (= 1.5.1.0-2.1), debhelper (= 4.1.75), autotools-dev, gettext, dh-buildinfo, libperl4-corelibs-perl +Build-Depends: libosp-dev (= 1.5.1.0-2.1), debhelper (= 4.1.75), dh-autoreconf, gettext, dh-buildinfo, libperl4-corelibs-perl Package: openjade Architecture: any diff -u openjade-1.4devel1/debian/rules openjade-1.4devel1/debian/rules --- openjade-1.4devel1/debian/rules +++ openjade-1.4devel1/debian/rules @@ -77,13 +77,6 @@ mv OpenJade-1.4devel/ChangeLog . rm -r OpenJade-1.4devel -autoinit: - aclocal - autoheader - libtoolize --force --copy - automake --add-missing --force-missing --copy - autoconf - clean: dh_testdir rm -f debian/buildinfo @@ -96,14 +89,12 @@ style/DssslAppMessages.h jade/JadeMessages.h \ jade/RtfMessages.h jade/HtmlMessages.h jade/TeXMessages.h \ jade/MifMessages.h - # See /usr/share/doc/autotools-dev/README.Debian.gz - -test -r /usr/share/misc/config.sub \ - cp -f /usr/share/misc/config.sub config.sub - -test -r /usr/share/misc/config.guess \ - cp -f /usr/share/misc/config.guess config.guess + dh_autoreconf_clean + rm -f debian/*.debhelper.log configure: configure-stamp configure-stamp: + dh_autoreconf dh_buildinfo generate cat ./configure --prefix=/usr --enable-http --enable-shared --enable-static touch $@ --- openjade-1.4devel1.orig/po/Makevars +++ openjade-1.4devel1/po/Makevars @@ -0,0 +1,72 @@ +# Makefile variables for PO directory in any package using GNU gettext. + +# Usually the message domain is the same as the package name. +DOMAIN = jade + +# These two variables depend on the location of this directory. +subdir = po +top_builddir = .. + +# These options get passed to xgettext. +XGETTEXT_OPTIONS = --keyword=_ --keyword=N_ + +# This is the copyright holder that gets inserted into the header of the +# $(DOMAIN).pot file. Set this to the copyright holder of the surrounding +# package. (Note that the msgstr strings, extracted from the package's +# sources, belong to the copyright holder of the package.) Translators are +# expected to transfer the copyright for their translations to this person +# or entity, or to disclaim their copyright. The empty string stands for +# the public domain; in this case the translators are expected to disclaim +# their copyright. +COPYRIGHT_HOLDER = see po-files + +# This tells whether or not to prepend GNU prefix to the package +# name that gets inserted into the header of the $(DOMAIN).pot file. +# Possible values are yes, no, or empty. If it is empty, try to +# detect it automatically by scanning the files in $(top_srcdir) for +# GNU packagename string. +PACKAGE_GNU = + +# This is the email address or URL to which the translators shall report +# bugs in the untranslated strings: +# - Strings which are not entire sentences, see the maintainer guidelines +# in the GNU gettext documentation, section 'Preparing Strings'. +# - Strings which use unclear terms or require additional context to be +# understood. +# - Strings which make invalid assumptions about notation of date, time or +# money. +# - Pluralisation problems. +# - Incorrect English spelling. +# - Incorrect formatting. +# It can be your email address, or a mailing list address where translators +# can write to without being subscribed, or the URL of a web page through
Bug#748584: ardour3 builds with too many parallel processes
Package: ardour3 Version: 3.5.380~dfsg-1 Severity: serious Hi, the package ardour3 doesn't respect parallel in DEB_BUILD_OPTIONS and builds with as many parallel processes as there are CPUs. This is not so helpful on a 16-core-machine which by purpose runs two buildds in parallel with 6 core per buildd. aba@lucatelli:~$ ps -fu buildd2 | grep cc1plus | wc -l 16 aba@lucatelli:~$ ps -fu buildd2 | grep sbuild buildd2 4534 3316 0 15:28 ?00:00:07 /usr/bin/perl /usr/bin/sbuild --apt-update --no-apt-upgrade --no-apt-distupgrade [...] ardour3_3.5.380~dfsg-1 ba@lucatelli:~$ grep DEB_BUILD ~buildd2/build/current-sid DEB_BUILD_OPTIONS=parallel=6 As per policy, package should not build parallel unless indicated by DEB_BUILD_OPTIONS, and then use that setting (or still not build parallel). Please fix this, this hurts the buildd infrastructure. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689899: Ships a folder in /var/run or /var/lock (Policy Manual section 9.3.2)
* Marco Balmer (ma...@balmer.name) [140115 21:26]: Le vendredi, 3 janvier 2014, 23.53:48 Andreas Barth a écrit : * Didier 'OdyX' Raboud (o...@debian.org) [140103 23:43]: Considering you've had your chance to respond to this (and given that you managed to respond in less than a half-hour last time), I have uploaded the proposed debdiff to DELAYED/5 as announced. Sorry, this is not acceptable. I am maintainer of couriergrey, which depends on courier, which depends on mgetty. My package was removed because of #689899 and #719501. Sorry for that, and thanks for the reminder. I now uploaded a fix for those bugs to unstable. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689899: Ships a folder in /var/run or /var/lock (Policy Manual section 9.3.2)
* Didier 'OdyX' Raboud (o...@debian.org) [140103 23:43]: Le jeudi, 2 janvier 2014, 19.08:14 Didier '' Raboud a écrit : Le jeudi, 2 janvier 2014, 18.49:31 Andreas Barth a écrit : So please remove your upload until I can review the situation again. It hasn't been uploaded yet, as it was building on my slow server. But unless you oppose the patch _content_ (and not the belief that I would upload a variation of rmdir -f) which I'm attaching to this mail for your convenience, I will upload this NMU to DELAYED/5. Considering you've had your chance to respond to this (and given that you managed to respond in less than a half-hour last time), I have uploaded the proposed debdiff to DELAYED/5 as announced. Sorry, this is not acceptable. Please remove it immediatly. I made a statement as maintainer I do not want this upload at this time and asked you for a little bit of time to review the change. You are not authorized to behave the way you did. Also, if it is that urgent, why did you not e.g. ping me on IRC? Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689899: Ships a folder in /var/run or /var/lock (Policy Manual section 9.3.2)
* Didier 'OdyX' Raboud (o...@debian.org) [140102 18:39]: Hi Andreas, This opposition of yours was more than one year ago: Le dimanche, 7 octobre 2012, 19.26:08 Andreas Barth a écrit : With my mgetty maintainer hat on, I refuse any NMU with this (or a similar) patch applied, unless otherwise authorized by me (as exception of my easy NMU policy I usually use for all packages). … and this new proposal was more than six months ago: I opposed having an upload of rmdir -rf /var/run/mgetty || true I think that is still legitimite to not want to have that done. Le mercredi, 21 août 2013, 15.41:53 gregor herrmann a écrit : I will therefore upload a new 1.1.36-1.7 with the fixes for both #719501 and #689899 to DELAYED/5 (although devref §5.11.1 would allow a direct upload). This is not correct. If you don't like my decisions, you need to have them overwritten by the tech ctte. The dev ref doesn't allow (and: cannot allow) overruling maintainers, because the constitution defines otherwise. So please remove your upload until I can review the situation again. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733343: reconserver FTBFS on all architectures
Package: reconserver Version: 0.9.1-1 Severity: serious Hi, your package FTBFS on all architectures where it had been tried: | configure: WARNING: unrecognized options: --disable-maintainer-mode |dh_auto_build -a -O--builddirectory=. | make[1]: Entering directory `/«PKGBUILDDIR»' | g++ -DPACKAGE_NAME=\reConServer\ -DPACKAGE_TARNAME=\reconserver\ -DPACKAGE_VERSION=\0.9.1\ -DPACKAGE_STRING=\reConServer\ 0.9.1\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\reconserver\ -DVERSION=\0.9.1\ -I. -D_FORTIFY_SOURCE=2 -DRESIP_FIXED_POINT -I/usr/include/sipxtapi -D__pingtel_on_posix__ -D_linux_ -D_REENTRANT -D_FILE_OFFS -DDEFAULT_BRIDGE_MAX_IN_OUTPUTS=20 -DRESIP_TOOLCHAIN_GNU -DUSE_CARES -DUSE_SSL -DUSE_IPV6 -g -O2 -Wformat -Werror=format-security -fpermissive -c -o reConServer.o reConServer.cxx | In file included from /usr/include/recon/UserAgent.hxx:4:0, | from reConServer.cxx:41: | /usr/include/recon/ConversationManager.hxx:12:31: fatal error: resip/stack/Uri.hxx: No such file or directory | #include resip/stack/Uri.hxx |^ | compilation terminated. | make[1]: *** [reConServer.o] Error 1 | make[1]: Leaving directory `/«PKGBUILDDIR»' | dh_auto_build: make -j1 returned exit code 2 | make: *** [build-arch] Error 2 | dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 Can you please build your package in a clean chroot before upload (i.e. in a chroot where nothing except build-essential and build-dependencies are installed)? Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727751: enblend-enfuse: FTBFS on mipsel but built there in the past
* Niels Thykier (ni...@thykier.net) [131103 09:50]: On 2013-10-28 22:27, Andreas Barth wrote: * Andreas Metzler (ametz...@bebt.de) [131028 19:24]: On 2013-10-26 Niels Thykier ni...@thykier.net wrote: Your package FTBFS on mipsel but built there in the past. It looks like it is an ICE, so you may have to reassign the bug to the relevant compiler/part of the toolchain. is it possible that the mipsel *buildd* machines are hosed? e.g. 4.1.2+dfsg-1 in experimental) failed to build on mayer [buildd] yesterday but worked on eder [porterbox]. Afaict both were using the same up to date toolchain. I dist-upgraded the chroots this morning. For this reason I just rescheduled a build, we will see if it works or not. It still FTBFS, but it looks like it timed out this time? Yes. The source file with the ICE was successfully built, and the timeout was later. Blacklisted it on mayer and re-scheduling. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727751: enblend-enfuse: FTBFS on mipsel but built there in the past
* Andreas Metzler (ametz...@bebt.de) [131028 19:24]: On 2013-10-26 Niels Thykier ni...@thykier.net wrote: Your package FTBFS on mipsel but built there in the past. It looks like it is an ICE, so you may have to reassign the bug to the relevant compiler/part of the toolchain. is it possible that the mipsel *buildd* machines are hosed? e.g. 4.1.2+dfsg-1 in experimental) failed to build on mayer [buildd] yesterday but worked on eder [porterbox]. Afaict both were using the same up to date toolchain. I dist-upgraded the chroots this morning. For this reason I just rescheduled a build, we will see if it works or not. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719501: mgetty: diff for NMU version 1.1.36-1.7
* gregor herrmann (gre...@debian.org) [130820 15:54]: I've prepared an NMU for mgetty (versioned as 1.1.36-1.7) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Feel free to push it directly into incoming (as always - as long as you are sure it works). Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708812: [Aptitude-devel] Bug#708812: [aptitude] aptitude segfaults upon being called.
* Andreas Barth (a...@ayous.org) [130816 15:11]:
* Andreas Barth (a...@ayous.org) [130816 11:27]:
* Axel Beckert (a...@debian.org) [130815 17:55]:
Andreas Barth wrote:
* Andreas Barth (a...@ayous.org) [130815 13:18]:
As google-mock is now uploaded (and should be built on all
architectures within the next hours - already built on most), could
you please upload a new version of aptitude to unstable soon (the
current version plus the gcc-4.8-patches worked for me, and produced a
working aptitude on mipsel)?
can you please upload a new aptitude version? Or should I just NMU
aptitude with the required patches for gcc-4.8?
You are aware of that it needs more than just the patches for gcc-4.8
to get aptitude build again properly?
I built (and installed and run) aptitude successfully on mipsel prior
to my NMU of google-mock. Might be that I had luck or whatever - I
will try this built now in a current chroot and see what happens.
Just rebuilt and it works fine. I will make proper packages from that,
plus provide the patches I used somewhere, so you could review what I
did.
Works. I put up the source package for inspection on
http://alius.ayous.org/~aba/.aptitude/
If wanted, I could upload the full package into unstable (or if I
don't get a no, I will upload it in a week).
The relevant patch is below.
Andi
diff -Nru aptitude-0.6.8.2/debian/changelog aptitude-0.6.8.2/debian/changelog
--- aptitude-0.6.8.2/debian/changelog 2012-11-05 01:52:16.0 +
+++ aptitude-0.6.8.2/debian/changelog 2013-08-16 13:25:14.0 +
@@ -1,3 +1,13 @@
+aptitude (0.6.8.2-1.1) unstable; urgency=low
+
+ * cherrypick from git:
++ 794b91 fix FTBFS with g++-4.8
++ c142a7 task_list is not extern
+ * re-upload to unstable to have again a working package on mips*.
+Closes: #708812, #714186
+
+ -- Andreas Barth a...@ayous.org Fri, 16 Aug 2013 13:19:40 +
+
aptitude (0.6.8.2-1) unstable; urgency=low
* [all]: Support for matching architectures using specification
diff -Nru aptitude-0.6.8.2/debian/patches/aptitude-0.6.8.2-1.1
aptitude-0.6.8.2/debian/patches/aptitude-0.6.8.2-1.1
--- aptitude-0.6.8.2/debian/patches/aptitude-0.6.8.2-1.11970-01-01
00:00:00.0 +
+++ aptitude-0.6.8.2/debian/patches/aptitude-0.6.8.2-1.12013-08-17
11:39:40.0 +
@@ -0,0 +1,63 @@
+Description: necessary change to make aptitude buildable in sid again
+ * cherrypick from git:
+ + 794b91 fix FTBFS with g++-4.8
+ + c142a7 task_list is not extern
+Author: Andreas Barth a...@ayous.org
+Bug-Debian: http://bugs.debian.org/708812
+Bug-Debian: http://bugs.debian.org/714186
+
+--- aptitude-0.6.8.2.orig/src/generic/apt/aptitude_resolver_universe.cc
aptitude-0.6.8.2/src/generic/apt/aptitude_resolver_universe.cc
+@@ -822,7 +822,6 @@ std::ostream operator(std::ostream o
+
+ cfg_level aptitude_universe::parse_level(const std::string s)
+ {
+- typedef generic_problem_resolveraptitude_universe aptitude_resolver;
+ if(s == maximum)
+ return cfg_level::make_level(cost_limits::maximum_level);
+ else if(s == minimum || s == )
+--- aptitude-0.6.8.2.orig/src/generic/apt/resolver_manager.cc
aptitude-0.6.8.2/src/generic/apt/resolver_manager.cc
+@@ -384,7 +384,7 @@ void resolver_manager::write_test_contro
+
+ typedef generic_choice_setaptitude_universe choice_set;
+ typedef generic_choiceaptitude_universe choice;
+- typedef aptitude_resolver_package package;
++ // typedef aptitude_resolver_package package;
+ typedef aptitude_resolver_version version;
+ typedef aptitude_resolver_dep dep;
+ const choice_set choices = sol.get_choices();
+--- aptitude-0.6.8.2.orig/src/generic/apt/tasks.h
aptitude-0.6.8.2/src/generic/apt/tasks.h
+@@ -63,9 +63,6 @@ public:
+ int relevance;
+ };
+
+-// Stores the various tasks.
+-extern std::mapstd::string, task *task_list;
+-
+ task *find_task(const std::string name);
+
+ /** \brief Get the set of tasks associated with the given package.
+--- aptitude-0.6.8.2.orig/src/generic/problemresolver/choice.h
aptitude-0.6.8.2/src/generic/problemresolver/choice.h
+@@ -405,8 +405,6 @@ struct generic_compare_choices_by_effect
+ {
+ int operator()(const generic_choicePackageUniverse c1, const
generic_choicePackageUniverse c2) const
+ {
+-typedef typename PackageUniverse::version version;
+-typedef typename PackageUniverse::dep dep;
+ using aptitude::util::compare3;
+
+ if(c1.get_type() c2.get_type())
+--- aptitude-0.6.8.2.orig/src/pkg_grouppolicy.cc
aptitude-0.6.8.2/src/pkg_grouppolicy.cc
+@@ -1096,8 +1096,6 @@ public:
+ void pkg_grouppolicy_task::add_package(const pkgCache::PkgIterator pkg,
+ pkg_subtree *root)
+ {
+- using aptitude::apt::task_list;
+-
+ setstring *tasks = aptitude::apt::get_tasks(pkg);
+
+ eassert(tasks);
diff -Nru aptitude-0.6.8.2/debian/patches/series
Bug#708812: [Aptitude-devel] Bug#708812: [aptitude] aptitude segfaults upon being called.
* Axel Beckert (a...@debian.org) [130815 17:55]: Hi Andi, Andreas Barth wrote: * Andreas Barth (a...@ayous.org) [130815 13:18]: As google-mock is now uploaded (and should be built on all architectures within the next hours - already built on most), could you please upload a new version of aptitude to unstable soon (the current version plus the gcc-4.8-patches worked for me, and produced a working aptitude on mipsel)? can you please upload a new aptitude version? Or should I just NMU aptitude with the required patches for gcc-4.8? You are aware of that it needs more than just the patches for gcc-4.8 to get aptitude build again properly? I built (and installed and run) aptitude successfully on mipsel prior to my NMU of google-mock. Might be that I had luck or whatever - I will try this built now in a current chroot and see what happens. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708812: [Aptitude-devel] Bug#708812: [aptitude] aptitude segfaults upon being called.
* Andreas Barth (a...@ayous.org) [130816 11:27]: * Axel Beckert (a...@debian.org) [130815 17:55]: Andreas Barth wrote: * Andreas Barth (a...@ayous.org) [130815 13:18]: As google-mock is now uploaded (and should be built on all architectures within the next hours - already built on most), could you please upload a new version of aptitude to unstable soon (the current version plus the gcc-4.8-patches worked for me, and produced a working aptitude on mipsel)? can you please upload a new aptitude version? Or should I just NMU aptitude with the required patches for gcc-4.8? You are aware of that it needs more than just the patches for gcc-4.8 to get aptitude build again properly? I built (and installed and run) aptitude successfully on mipsel prior to my NMU of google-mock. Might be that I had luck or whatever - I will try this built now in a current chroot and see what happens. Just rebuilt and it works fine. I will make proper packages from that, plus provide the patches I used somewhere, so you could review what I did. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708812: [aptitude] aptitude segfaults upon being called.
* Andreas Barth (a...@ayous.org) [130815 13:18]: As google-mock is now uploaded (and should be built on all architectures within the next hours - already built on most), could you please upload a new version of aptitude to unstable soon (the current version plus the gcc-4.8-patches worked for me, and produced a working aptitude on mipsel)? Hi Daniel, can you please upload a new aptitude version? Or should I just NMU aptitude with the required patches for gcc-4.8? Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719498: ruby-god doesn't end building
Package: ruby-god
Version: 0.13.2-3
Severity: serious
Hi,
the package ruby-god doesn't end building because there is still a
process after the package ended building:
16697 ?Sl 0:01 ruby1.9.1 -ryaml -e
YAML.load_file(debian/ruby-test-files.yaml).each { |f| require f }
This can e.g. be seen on mips.
Please make sure whatever happens that all processes you start are
also ended. Otherwise you are blocking an buildd until manual
intervention.
Regards,
Andi
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708812: Bug#716944: google-mock: please upload r437 snapshot to syncronize with recent gtest snapshot
severity 716944 serious tag 716828 + patch tag 708812 + patch thanks * Daniel Hartwig (mand...@gmail.com) [130727 15:34]: gtest is recently bumped to 1.7.0~svn20130629-2 [1]. The 1.6.0 release of googlemock is incompatible with this, though r437 [2] is. Please upload that version to keep the packages functional. I appreciate that you do not use the embedded copy of gtest, so let us keep these syncronized. I built a package of google-mock based on the current svn snapshot. Using that, I can confirm that aptitude builds again (with patches from head to build with gcc-4.8, which is the default now on most arches), and in turn this resolves the issue that aptitude segfaults on mips* (see #708812). Resolving that would allow us to re-enable building experimental on mips*. Because of that, I adjusted the severity of this bug report. Also, if you want I could upload the fixed google-mock package now (or if you don't disagree, I would upload it next weekend to allow us to get our infrastructure back working again). Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708812: Bug#716944: google-mock: please upload r437 snapshot to syncronize with recent gtest snapshot
* Fredrik Hallenberg (megahal...@gmail.com) [130727 17:47]: Sorry for not responding on this, I had planned to take a look at it next week. Feel free to upload your fixed package. Thanks for your fast answer and for your permission to upload. I however would like to ask you to check I didn't mess up anything when you have time - especially as there are different patches in debian/patches/ which are according to series not applied (same in 1.6.0, so it doesn't stop me from uploading, but these patches should IMHO either be removed or applied, whatever makes sense). Thanks, Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708812: [aptitude] aptitude segfaults upon being called.
Hi Daniel, * Daniel Hartwig (mand...@gmail.com) [130727 21:38]: On 24 July 2013 19:03, Lifeng Sun lifong...@gmail.com wrote: [aptitude] suffers another FTBFS bug [6]. The current versions of google-mock and gtest in unstable are incompatible with each other. As google-mock relies on gtest, aptitude will continue to FTBFS until that situation is resolved. See http://bugs.debian.org/716944. There are also issues with gcc4.8 and boost that are fixed in git, but waiting for boost1.54 to become the default (or patched boost1.49 and boost1.53). http://bugs.debian.org/701243. Is there any plan to fix these bugs? I can help to fix it on mipsel. Once the blocking issues are resolved it will be no problem to get aptitude building again. As google-mock is now uploaded (and should be built on all architectures within the next hours - already built on most), could you please upload a new version of aptitude to unstable soon (the current version plus the gcc-4.8-patches worked for me, and produced a working aptitude on mipsel)? Thanks, Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#716828: aptitude FTBFS with missing google-mock
Package: aptitude
Version: 0.6.8.2-1
Severity: serious
Hi,
re-building aptitude in plain sid (both on mipsel and amd64) ends
with:
checking for boost/weak_ptr.hpp... yes
checking for boostlib = 1.20.0... yes
checking whether the Boost::IOStreams library is available... yes
checking for main in -lboost_iostreams-mt... yes
checking the calling convertion of boost::fusion::fold... State first, then
value
checking the name of the runtime library for Boost.Test...
-lboost_unit_test_framework
configure: error: Can't figure out where Google Mock lives; either install the
google-mock package or place the library in the link path
dh_auto_configure: ../configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=${prefix}/include --mandir=${prefix}/share/man
--infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--libdir=${prefix}/lib/x86_64-linux-gnu
--libexecdir=${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode
--disable-dependency-tracking --htmldir=${docdir}/html
--program-transform=saptitude$aptitude-curses returned exit code 1
make[1]: *** [override_dh_auto_configure] Error 2
checking how to link gmock... make[1]: Leaving directory `/«PKGBUILDDIR»'
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
Build finished at 20130713-0931
Andi
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668740: 668740 not release critical
severity 668740 important thanks Hi, checking with http://release.debian.org/wheezy/rc_policy.txt I still don't see why this bug is serious or above. Please note that the mentioned document is the canoncial definition of release critical bugs. Setting the bug to important only means I don't think it is serious or above. Otherwise, as always it is the maintainers decision to set the bug to an appropriate severity (and of course, the maintainer is free to set the bug to serious again, if he thinks the package is unfit for release). Anyone disagreeing with the maintainer may try to convince him, search for other people convincing the maintainer, or escalate the topic to the tech ctte - as always. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678333: fails to terminate it's own testcode
Package: sslh Version: 1.13b-2 Severity: serious Hi, this packages fails to terminate it's testcode properly (at least on mipsel) and therefore requires the buildd to timeout the build (and wastes endless time): buildd 18416 1 0 21:27 ?00:00:00 sh -c ./echosrv --listen ip6-localhost:9000 --prefix 'ssh: ' buildd 18417 1 0 21:27 ?00:00:00 sh -c ./echosrv --listen ip6-localhost:9001 --prefix 'ssl: ' buildd 18419 18416 0 21:27 ?00:00:00 ./echosrv --listen ip6-localhost 9000 --prefix ssh: buildd 18420 18417 0 21:27 ?00:00:00 ./echosrv --listen ip6-localhost 9001 --prefix ssl: buildd 18421 18419 0 21:27 ?00:00:00 ./echosrv --listen ip6-localhost 9000 --prefix ssh: buildd 18422 18420 0 21:27 ?00:00:00 ./echosrv --listen ip6-localhost 9001 --prefix ssl: Please make sure whatever happens that the testcode is terminated. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676817: systemd and dovecot
* Nicholas Bamber (nicho...@periapt.co.uk) [120617 08:59]: We really need to get dovecot compiled on the non-linux platforms to progress with the mysql migration. The systemd dependency puzzles me somewhat as systemd is not available on non-linux platforms and dovecot has previously compiled on those platforms. Why is systemd used at all during build time? I don't think it's usually appropriate to depend on daemons installed during package building. If you need something to link again, then it should be part of a -dev-package (which still might or might not be available on !linux, but that's something else). Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676686: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
* Guillem Jover (guil...@debian.org) [120610 10:08]: As I mentioned in the long ref-counting thread, I strongly disagree this is a correct solution, it just seems like a hack to me. Instead I think we should consider changelog (and copyright as long as it's in machine parseable format) as dpkg metadata (something dpkg misses compared to rpm or other package managers for example) and as such they should go into the .deb control member, which would end up in the dpkg database w/o any kind of file conflict, and very minor packaging effort as for most that would be handled by helpers. I'm fully happy to see that solved in whatever way. However, getting it sorted out for binNMUs seems like some kind of priority to me. Perhaps we could add the binNMU entry for the moment and fix the rest later? Or whatever would make you more happy. Just I'd like to be able to schedule binNMUs again on ma-packages. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676686: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
* Henrique de Moraes Holschuh (h...@debian.org) [120609 02:31]: We'd just have to teach the tool to binNMU all arches when the target package would need it due to multiarch. Release team requests a binNMU of a package for some arch, the tool notices it has to do them all because of multi-arch constraints, and replicates the request for all other arches. Just that this won't do it, because the changelogs for the different arches will be binary different, so no win. However, we discussed that during the multi-arch bof last Debconf, and came to the conclusion that it would be better to not modify the changelog as we do now, but instead create a new file changelog.$arch.$version with the binNMU. This is a bit more complicated because it can't be done as of now just within the source package. Anyone implementing this is warmly welcome. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674942: ruby blocks buildd for a day (or more)
Package: ruby1.8 Version: 1.8.7.358-3 Severity: serious Hi, auto-building ruby1.8 takes a buildd offline for quite some time. E.g. on ia64 the build only ended after I killed a 20+-hours running part of the test suite. Please make sure that all programms started by ruby1.8 are terminated if they are no longer needed (and/or the build fails for any reason). Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673297: libxml2 and gzopen64@ZLIB_1.2.3.3 (Was: Please reschedule tagua 1.0~alpha2-10 on armel)
* Julien Cristau (jcris...@debian.org) [120528 20:52]: No, the buildds (rem and alkman) have an old broken version of zlib1g. Andreas, please upgrade those chroots. all mips* and ia64 buildds dist-upgraded (except mayer which has an old-style chroot and cannot be upgraded for the next 60 hours while gcc is built - but it won't break other builds during that time). Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673292: scilab hangs forever on buildds
Package: scilab Version: 5.4.0-alpha-20120903-33206a8-1~exp2 Severity: serious Hi, in case scilab doesn't work the selected mechanismn to just spit out things every 10 minutes prevents the build from terminating by itself. E.g. from today: buildd2 28179 28152 99 May05 ?11-21:20:09 /build/buildd2-scilab_5.4.0-alpha-20120903-33206a8-1~exp2-mips-9DAA9u/scilab-5.4.0-alpha-20120903-33206a8/.libs/lt-scilab-cli-bin -ns -noatomsautoload -f The timeout mechanismn is there to terminate builds which don't behave and don't terminate. You must not write code which just outputs the process list every 10 minutes, so that it blocks a buildd for more than 10 days by just being broken! Please fix that, and fix that also in unstable. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614907: tech-ctte: please help maintainers of packages with a node command to have a reasonable conversation
* Russ Allbery (r...@debian.org) [120503 01:33]: Ian Jackson ijack...@chiark.greenend.org.uk writes: I'm disappointed to see this is still rumbling on. There is only one correct solution, and it is this: In the long term, I would be happiest if both were renamed. I won't reiterate the arguments that I've already made on debian-devel, but will mention here for those who haven't been following that discussion that I think I disagree. Based on the information that I currently have (and this has been changing over the course of the discussion), I think Node.js should (eventually, with a suitable transition) have the name node, since the use of it in the ham radio package is as an inetd-invoked daemon and the renaming there doesn't have much impact. (It's a system interface, but not really a user interface.) It's interesting that Fedora has nodejs, and I think we should also provide nodejs and encourage people to use that name, but I think it would be best for our users to also provide node. In this case, I think the name the binary is installed as should be nodejs, not node. (A symlink is a different topic, see below.) Also, as you said, the ham radio package is (AFAICUI) only used internally (considering a binary run by inittab, inetd etc as internally), so a step-by-step-transition to a different name shouldn't be too hard. Independend of whether the nodejs-package contains a symlink in the end, I think that change should be done because node is a generic name. Regarding the symlink: I'm currently not convinced how hard it would be to not set the symlink. Whoever wants it can set it in /usr/local/bin or ~/bin/ (or via an alias). Especially as this is also the case in Fedora, I'd tend to also not using an symlink. I also think the current Policy suggestion to rename both programs in the event of an unreconciled naming conflict is not a very good idea, and think it should change to instead list the Technical Committee as the decision-maker of last resort. Renaming both programs is likely to be the right move only in cases where both programs are pretty obscure and fairly new. Agreed. Perhaps something like usually, newcomers should respect the namespace wouldn't sound wrong to me (but not as an absolute rule of course). Also, the policy should prevent using too generic names (if both packages rename, the name node is free again to be used, and I don't think that's proper). Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640874: leave: debian/rules is not a Makefile
* Russ Allbery (r...@debian.org) [120326 20:58]: Russ Allbery r...@debian.org writes: Based on Ian's last response, I think the ballot has two options plus further discussion, since I'm quite sure that we're not going to outlaw dh: A. debian/rules is not required to be a makefile, only to implement the same interface as a debian/rules file implemented as a makefile (including handling of arguments and exit status). Debian Policy should be updated to change the requirement to a recommendation, and new versions of the leave package should be permitted to be uploaded to the archive without changing debian/rules to be a makefile. B. The Technical Committee affirms the Debian Policy requirement that debian/rules must be a makefile. All packages in the archive, including leave, are required to follow this requirement. This makefile may, as is common practice, delegate implementation of its targets to a script. C. Further discussion. Reminder: there is a vote currently in progress on this ballot. So far, only Ian and I have voted. Please take a look at the cited bug and register an opinion when you have a chance. Thanks for the reminder. Voting BAC. (I'm not convinced that we gain anything by changing the status quo to the proposed solution A - even though with the current makefiles consisting of just %: dh $@ the degault mechanismn seems a bit too complicated; but changing that to variant A doesn't seem to be too useful. Also, the tech ctte isn't the place to develop new solutions; in other words, if someone comes up with a good solution which has shown through the usual ways that it gains something for debian at large, I'm happy to support changing the default but we're not there (yet).) Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607368: Call for Vote: Kernel ABI numbering policy
* Don Armstrong (d...@debian.org) [120224 21:09]: I call for a vote on the kernel ABI numbering policy bug with the following ballot: A) The technical committee declines to override the kernel maintenance team's ABI numbering policy. B) Further discussion Voting AB Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658341: Call for Vote: upload of multi-arch enabled dpkg (in time for wheezy)
* Andreas Barth (a...@ayous.org) [120205 10:34]: * Bdale Garbee (bd...@gag.com) [120202 15:16]: A. While recognizing the substantial benefits of thorough code review, the Technical Committee believes the goal of multiarch support in the Debian wheezy release is sufficiently important as to warrant accepting the current draft implementation into the archive, even if code review by the primary dpkg C maintainer cannot be completed in time. However, as much review as possible is strongly desired. The Technical Committee therefore overrides the decision of the dpkg maintainer to require complete code review before upload of the multiarch implementation in dpkg to the Debian archive and sets the following upload dates: February 6th: upload to experimental for general testing February 20th: upload to unstable For each of those deadlines, if no implementation of dpkg with multiarch support has been uploaded to the archive for that distribution by that date, Raphaël Hertzog is empowered by the Technical Committee to upload a version of dpkg with multiarch support to that distribution. The upload may be done on or after that date, when, in his judgement, the dpkg implementation meets the quality standards expected for a Debian core package in those archive distributions. The Technical Committee strongly encourages anyone with the required knowledge to review the multiarch implementation proposed for upload and provide the results of that review to the debian-dpkg list as soon as possible so that the code can receive as much review as possible and the results of that review can be incorporated into the code by those dates. Similarly, the Technical Committee encourages as broad testing and review of the experimental implementation as possible so that as many bugs as possible can be resolved prior to uploading it to unstable. This option requires a 3:1 majority. And with my vote (and Steves in http://lists.debian.org/20120205092246.gb15...@virgil.dodds.net ) the outcome is no longer in doubt, so A is the decision. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658341: Call for Vote: upload of multi-arch enabled dpkg (in time for wheezy)
* Bdale Garbee (bd...@gag.com) [120202 15:16]: A. While recognizing the substantial benefits of thorough code review, the Technical Committee believes the goal of multiarch support in the Debian wheezy release is sufficiently important as to warrant accepting the current draft implementation into the archive, even if code review by the primary dpkg C maintainer cannot be completed in time. However, as much review as possible is strongly desired. The Technical Committee therefore overrides the decision of the dpkg maintainer to require complete code review before upload of the multiarch implementation in dpkg to the Debian archive and sets the following upload dates: February 6th: upload to experimental for general testing February 20th: upload to unstable For each of those deadlines, if no implementation of dpkg with multiarch support has been uploaded to the archive for that distribution by that date, Raphaël Hertzog is empowered by the Technical Committee to upload a version of dpkg with multiarch support to that distribution. The upload may be done on or after that date, when, in his judgement, the dpkg implementation meets the quality standards expected for a Debian core package in those archive distributions. The Technical Committee strongly encourages anyone with the required knowledge to review the multiarch implementation proposed for upload and provide the results of that review to the debian-dpkg list as soon as possible so that the code can receive as much review as possible and the results of that review can be incorporated into the code by those dates. Similarly, the Technical Committee encourages as broad testing and review of the experimental implementation as possible so that as many bugs as possible can be resolved prior to uploading it to unstable. This option requires a 3:1 majority. B. The Technical Committee declines to override the decision of the dpkg maintainer to hold the dpkg multiarch implementation until he can finish code review. C. Further discussion. Voting ABC Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546416: #546416 - do_fancy_upsampling or do_fancy_downsampling?
* Bill Allombert (bill.allomb...@math.u-bordeaux1.fr) [110730 01:00]: On Sat, Jul 30, 2011 at 12:21:32AM +0200, Andreas Barth wrote: Hi Bill, are you sure it's do_fancy_downsampling? This FTBFS, but do_fancy_upsampling does. Ah sorry. This is indeed do_fancy_upsampling. Thanks for confirmation. Uploading. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635886: FTBFS with current ocaml
Package: approx Version: 5.0-1 Severity: serious Hi, this package FTBFS now. It could be reproduced on amd64. The tail of the build log is: /usr/bin/ocamlc -c -warn-error A -o url.cmi url.mli /usr/bin/ocamlc -c -warn-error A -o util.cmi util.mli /usr/bin/ocamlc -c -warn-error A -I +pcre -I +netstring -I +netcgi2 -I +nethttpd-for-netcgi2 -o approx.cmo approx.ml + /usr/bin/ocamlc -c -warn-error A -I +pcre -I +netstring -I +netcgi2 -I +nethttpd-for-netcgi2 -o approx.cmo approx.ml File approx.ml, line 52, characters 12-48: Error: Unbound module Nethttpd_types Command exited with code 2. make[1]: *** [approx] Error 10 make[1]: Leaving directory `/build/buildd-approx_5.0-1-amd64-OS8aj4/approx-5.0' dh_auto_build: make -j1 returned exit code 2 Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546416: #546416 - do_fancy_upsampling or do_fancy_downsampling?
Hi Bill, are you sure it's do_fancy_downsampling? This FTBFS, but do_fancy_upsampling does. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624776: different g++-, gcj-versions break pdftk
Package: gcc-defaults Version: 4.6.0-5 Severity: serious Hi, that g++ and gcj have different versions breaks the build of pdftk, see e.g. https://buildd.debian.org/fetch.cgi?pkg=pdftkver=1.41%2Bdfsg-11%2Bb1arch=powerpcstamp=1304254757file=log If fixing pdftk to just use the default version, it builds, but after startup the following error happens: $ pdftk libgcj failure: gcj linkage error. Incorrect library ABI version detected. Aborting. So it seems to me this can either only be avoided with having g++ and gcj pointing to the same version, and/or explicitly depending on one version in the build-dependencies of pdftk (which I would consider more ugly - but YMMV). Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624776: different g++-, gcj-versions break pdftk
* Matthias Klose (d...@debian.org) [110501 18:31]: On 05/01/2011 04:31 PM, Andreas Barth wrote: If fixing pdftk to just use the default version, it builds, but after startup the following error happens: $ pdftk libgcj failure: gcj linkage error. Incorrect library ABI version detected. Aborting. So it seems to me this can either only be avoided with having g++ and gcj pointing to the same version, and/or explicitly depending on one version in the build-dependencies of pdftk (which I would consider more ugly - but YMMV). please fix pdftk to build-depend on default-jdk, and don't use gcj explicitly. so, how should the calls be then? Build-depend on default-jdk, and use g++ for building the c++-part, and what for building the jdk-part? Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624776: different g++-, gcj-versions break pdftk
* Johann Felix Soden (joh...@gmx.de) [110501 21:52]: 3. Currently, the compiler version check is done at build time by calling g++-4.x explicitly if default gcj has version 4.x.y. But if gcc-defaults (or any other package) does not guarantee that g++-4.x is available, FTBFS can happen - better than frustrated users due to unusable pdftk but anything than optimal. Of course, the current situation is better than silent package corruption. But still not ok, because that leads to hidden new bugs jumping out at the wrong moment. However, we (in sum) have two choices: 1. have meta package(s) that make sure we have consistent compilers. This could be gcc-defaults. It could also be e.g. some gcj-g++-package. Or whatever else. 2. hardcode certain versions into this package. In case there is a third choice please say so. Otherwise, we need to decide for one of them. Whichever is the best in the end. (That I wouldn't like 2. is obvious. That 1. has also some drawbacks as well.) Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599979: Request for building stockfish package or wrong gcc/g++ versions g++_4:4.4.4-2 g++-4.4_4.4.4-6 gcc_4:4.4.4-2
* Oliver Korff (o...@xynyx.de) [101104 23:04]: a little more than a week ago I requested a new build of my package on the sparc and ia64 buildds. scheduled on ia64. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599974: mips(se) experimental autobuilder still uses rc buggy binutils
* Andreas Metzler (ametz...@downhill.at.eu.org) [101013 19:11]: On 2010-10-12 Cyril Brulebois k...@debian.org wrote: Source: findutils Version: 4.5.9-1 [...] | /usr/bin/ld: non-dynamic relocations refer to dynamic symbol chown@@GLIBC_2.0 [...] https://buildd.debian.org/status/package.php?p=findutilssuite=experimental Hello, The respective autobuilder is still running binutils 2.20.1-7, suffering from #519006. Please upgrade. The buildd is already upgraded for some time, however this bug was reported only recently. I gave back binutils for another try. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569120: partial-patch exists upstream
severity 569120 important thanks * gregor herrmann (gre...@debian.org) [100717 11:48]: On Wed, 12 May 2010 23:04:27 +0200, Andreas Barth wrote: I read the commits it got better but not fully fixed. If that is true, I'd be happy to see the changes uploaded to Debian (it really annoys if the system aborts one to two times per week). Are you still seeing this problem with recent versions (3.4.6-1 at the moment)? It seems to be resolved for me. However, according to the maintainers comments the problem isn't fully resolved, so I'm setting the severity back to important. Thanks for your reminder. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576720: [ia64] gdb FTBFS and freezes / reboots the machine
clone 576720 -1 reassign -1 linux-2.6 thanks * Daniel Jacobowitz (d...@false.org) [100412 13:01]: On Tue, Apr 06, 2010 at 08:44:13PM +0200, Andreas Barth wrote: on trying to build gdb, the buildd freezes (mundy) or gets rebooted (alkman). This package was tried 3 times on mundy and 1 time on alkman. The log files ends with (please note that this may not be the last real line - the machine gets rebooted): Do you think this is a bug in GDB? It sounds like the kernel is broken. As the try to rebuild gdb 7.0 in testing now successfully proved to freeze mundy, I assume that's not something done by an change in gdb. I'll still leave a copy of this bug with gdb, so that we're reminded why this package doesn't build and doesn't get any build logs. re linux: once mundy is running again, I'll provide you with details which kernel is running there currently. Alkman (also affected) currently runs Linux alkman 2.6.32-bpo.5-mckinley #1 SMP Tue Jun 15 01:27:44 UTC 2010 ia64 GNU/Linux Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586197: uploading NMU
Hi, I'm uploading this patch as NMU. Sorry for the urgency, but this is one of the few packages that is blocking the testing migration right now, and I'd like to get rid of it. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586824: Uploading this NMU
Hi, I'm uploading this fix as NMU now. Sorry for the urgency, but this needs to be fixed to allow python 2.6 to go to testing. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560238: tech-ctte: Default value for net.ipv6.bindv6only sysctl
* Guus Sliepen (g...@debian.org) [100621 22:57]: There has been an extensive discussion about the proper default value of the net.ipv6.bindv6only sysctl, both on the debian-devel mailing list and in bugreport 560238. Since people are clearly divided on the issue, and it is unlikely a compromise can be found, I have forwarded it to you for a decision. Please read the past discussion, but to summarise the arguments for both possible default values: Thanks for bringing that to our attention. After reading the bug log, I don't think there is much which isn't said yet, so I'll try to avoid repeating. I need to admit that I consider the reasons to stay with the previous default, i.e. an value of 0 to be more convincing. It might had been an error a few years ago to set 0 as the default, but well - now we are here. I don't see why we should break otherwise working software. I would however welcome to have some bugfixing campaign (release goals for anyone?) which gets rid of the old interfaces in our code base. We should also think if we want to get the default changed on kbsd - basically kbsd is the new kid, so I don't think it warrants that we do strange stuff on Debian. Also, perhaps just an appropriate warning for ksbd in the release notes might be enough (at least for squeeze). Having said this, I would like to call for an vote with the options A set net.ipv6.bindv6only to 0 B set net.ipv6.bindv6only to 1 C further discussion unless someone from the tech ctte sees the need for further discussions (or options) right now. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560238: tech-ctte: Default value for net.ipv6.bindv6only sysctl
* Russ Allbery (r...@debian.org) [100622 01:21]: Andreas Barth a...@not.so.argh.org writes: I would however welcome to have some bugfixing campaign (release goals for anyone?) which gets rid of the old interfaces in our code base. We should also think if we want to get the default changed on kbsd - basically kbsd is the new kid, so I don't think it warrants that we do strange stuff on Debian. Also, perhaps just an appropriate warning for ksbd in the release notes might be enough (at least for squeeze). Having a different default on BSD than on other platforms strikes me as asking for trouble (in particular, asking for obscure portability issues to BSD systems that most developers don't test on). I agree with you. However, I currently view the BSD platforms as addon, i.e. I don't think we should do for our linux platforms a different decision just because kBSD exists. Of course, this calls for changing the default on kBSD - but this is the second step IMHO, not the first step. And I would like to keep that decision with the kBSD porters unless someone puts that question in front of us (i.e. I don't believe we need or should answer that question within this request). Having said this, I would like to call for an vote with the options A set net.ipv6.bindv6only to 0 B set net.ipv6.bindv6only to 1 C further discussion unless someone from the tech ctte sees the need for further discussions (or options) right now. There's also the meta-question of whether we need to make a decision at all. Marco's last message on this topic to debian-devel said basically that he thinks the default should be set back to 0, so possibly this is happening without our involvement? Hm. As it currently looks to me, the decision was delegated to us. If Marco removes that delegation, that'd be fine with me. If not, we need to make a decision (at least I believe it's sensible to not wait until someone just does it for us). Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585403: emacs22 22.3+1-1.2 fails to install on mipsel
Package: emacs22 Version: 22.3+1-1.2 Severity: critical Hi, this package cannot be installed on mipsel: | Setting up emacs22 (22.3+1-1.2) ... | update-alternatives: using /usr/bin/emacs22-x to provide /usr/bin/emacs (emacs) in auto mode. | update-alternatives: using /usr/bin/emacs22 to provide /usr/bin/editor (editor) in auto mode. | emacs-install emacs22 | emacsen-common: Handling install of emacsen flavor emacs22 | emacsen-common: byte-compiling for emacs22 | emacs22: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) ((av)-bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd old_size == 0) || | ((unsigned long) (old_size) = (unsigned long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) ~((2 * (sizeof(size_t))) - 1))) ((old_top) | -size 0x1) ((unsigned long)old_end pagemask) == 0)' failed. | Aborted | emacs-install: /usr/lib/emacsen-common/packages/install/emacsen-common emacs22 failed at /usr/lib/emacsen-common/emacs-install line 28, TSORT line 2. This makes other packages FTBFS, e.g. acl2. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585405: acl2 depends on old / broken emacs22 package
Package: acl2 Version: 3.6.1-1 Severity: serious Hi, the emacs22 package refuses to get installed on mipsel, so your package is failing to build. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584628: axiom: package builds way too long
Package: axiom Version: 20100301-1 Severity: grave Hi, this package builds way too long. Currently it needs more than 15 days on ia64 (and still building!). and it needed more than 88 hours on mips but only 2 on mipsel. This strongly indicates something in your test suite is buggy (especially as you send out ticks, which are near to an abuse of our buildd infrastructure). Please adjust your program so that it ends within a more limited time periode and failures are recognized as such. Otherwise, I would need to blacklist axiom on the buildds in order to allow other packages to build. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582952: dash / LINENO-support lets many package FTBFS
* Raphael Geissert (geiss...@debian.org) [100527 06:47]: On Tuesday 25 May 2010 11:36:22 Andreas Barth wrote: * Lucas Nussbaum (lu...@lucas-nussbaum.net) [100525 18:16]: I have downgraded to important the bugs I filed about those packages. Great. That's the severity I wanted to ask you. I disagree. Those bugs are policy violations and make those packages FTBFS when using dash from testing or experimental, or posh. Tag them squeeze-ignore if you want, but their severity is 'serious.' That's not your call to make. The release team decided that these bugs are not release critical. We intend to change that decision if only an acceptable number of such bugs is left. If you disagree, you can try to either convince us, or call the tech ctte. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582952: dash / LINENO-support lets many package FTBFS
* Raphael Geissert (geiss...@debian.org) [100527 16:52]: On Thursday 27 May 2010 03:08:58 Andreas Barth wrote: * Raphael Geissert (geiss...@debian.org) [100527 06:47]: Those bugs are policy violations and make those packages FTBFS when using dash from testing or experimental, or posh. Tag them squeeze-ignore if you want, but their severity is 'serious.' That's not your call to make. The release team decided that these bugs are not release critical. Hence my suggestion to mark them squeeze-ignore. They might not be release critical but their severity, in terms of the BTS, _is_ serious. Do we agree on that? No. The release team defines when a bug is a severe violation of Debian policy (see http://release.debian.org/squeeze/rc_policy.txt). We decided that these bugs are not fullfiling the criteria at the current moment. (Basically, if we'd say well, we ignore these build errors for the release of squeeze then it'd be -ignore. But if we say this are too many bugs right now, so please first try to minimize the number, then these are important only - instead of reverting the change in dash we could have used /bin/bash on the buildds and avoid further build failures as well. Same as we did e.g. for the introduction of gcc-4.4. Or any other toolchain change which would lead to many build failures.) Of course, feel free to use the usual NMU rules for these bugs (technically, I see this as part of get rid of bashimns, which are part of several release goals, but others might disagree). We intend to change that decision if only an acceptable number of such bugs is left. I'm going to try to find time to work on those bugs so that LINENO can be reintroduced for squeeze. I'd appreciate that. Thanks. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582952: Are FTBFS really caused by LINENO-support?
* Raphael Geissert (geiss...@debian.org) [100527 18:47]: The difficult part of the switch is not fixing the bashisms, but educating people about them. It might actually be nice to write up an summary of what happened, why, what the bugs are and how to fix that, and send it to d-d-da? Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582952: dash / LINENO-support lets many package FTBFS
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [100525 18:16]: Indeed. Attached is the list of the 124 packages that FTBFS with dash 0.5.5.1-5 but do not fail with dash 0.5.5.1-3. I have downgraded to important the bugs I filed about those packages. Great. That's the severity I wanted to ask you. Gerrit, can you please remove the patch from unstable again, and upload it instead to experimental? Thanks. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582952: dash / LINENO-support lets many package FTBFS
Package: dash Version: 0.5.5.1-5 Severity: serious Hi, recently dash gained support for LINENO (see #540685). This made many other package FTBFS, see e.g. #582037, #582876, #581884 and #582565. A change that makes so many packages FTBFS makes release management hard (or rather impossible), so we need to find a way how these package don't FTBFS at the current point in time. Of course, technically spoken, these packages are all buggy. However, as sort of work around, I would like to ask you to remove this feature from dash in unstable again. Re the long term perspectives, Jakub Wilk has contacted Lucas Nussbaum about testing all our packages in unstable and see which are affected by this bug, and then filling bugs as appropriate. Once we know how many packages are affected, we then can encourage people to fix the bugs with their next uploads. As soon as the number of affected packages is acceptable, we then can turn on LINENO on dash again. Otherwise this is now directly negativly affecting all of our ongoing and planned transitions. Of course, uploading an version of dash with LINENO to experimental would be appreciated, so that we can continue to check the affected packages. The other alternative to removing LINENO-support would be to make sure that /bin/sh points to bash in the buildd chroots - nothing I would like to. (This bug is serious, because this needs the release team attention. If you disagree with the proposal above, please don't lower the severity but instead reassign it to buildd.d.o so that we can change /bin/sh in the buildd chroots to bash. Thanks.) Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582952: dash / LINENO-support lets many package FTBFS
* Raphael Geissert (geiss...@debian.org) [100524 23:13]: I probably won't have time to process the results myself in the next two-three weeks. Sorry, but we need something working within one week. I have lots of cool ideas how the world should be, but this is not about how should it look like, but how can we continue with our transitions, e.g. the ongoing ones and the upcoming ones like python 2.6. And no is not an answer. If we can't revert the patch, we have to change the buildd chroots. Just consider what is better. I'd think reverting the patch is better, but I'll accept an maintainers decision to not. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579926: incompatibility reduced
severity 579926 important thanks Hi, with version 0.60.0-1+buildd20100520.1 the new schroot can be used, but the chroot create scripts produces options schroot doesn't like (and which don't seem to be necessary). The last part remains to be fixed, but looks way better now. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579917: mkhomedir segfaults within ld.so on startup
clone 579917 -1 reassign -1 libpam-modules severity 579917 important thanks * Aurelien Jarno (aurel...@aurel32.net) [100519 23:56]: The problem is that the mkhomedir_helper is built as a library, using a version-script. This lead to: 0x7016 (MIPS_RLD_MAP) 0 Removing --version-script while linking the binary fixes the problem: 0x7016 (MIPS_RLD_MAP) 0x413a50 I agree that ld.so should not segfault in that case, I'll try to write a patch for that, but I don't think the bug is still serious anymore on the eglibc side. Right. Cloning the RC-grade part to libpam-modules, and lowering the severity on eglibc. Thanks for your support. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581606: pinball-dev uninstallable in unstable
Package: pinball-dev Version: 0.3.1-12 Severity: grave Hi, this package is now uninstallable in unstable, as gcc-4.1 dropped libstdc++6-4.1-dev. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581662: build-depends on libgudev-1.0-dev which doesn't exist on kbsd
Package: shotwell Version: 0.5.0+dfsg-1.1 Severity: serious Hi, this package build-depends on libgudev-1.0-dev which however doesn't exist on kbsd. Also this package doesn't sound linux-only, so please get this fixed. Thanks. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581579: util-linux fails to configure / debootstrapping sid doesn't work anymore
Package: util-linux Version: 2.17.2-1 Severity: grave Hi, on trying to debootstrap sid right now an amd64 sid-system, I get the following errors. On an i386 system (which has the older util-linux still installed on ftp-master), debootstrapping works (for this reason, I file this bug against the util-linux package). Unpacking util-linux (from .../util-linux_2.17.2-1_amd64.deb) ... [...] update-alternatives: using /bin/more to provide /usr/bin/pager (pager) in auto mode. insserv: Service checkroot has to be enabled to start service hwclock insserv: exiting now! update-rc.d: error: insserv rejected the script header dpkg: error processing util-linux (--configure): subprocess installed post-installation script returned error exit status 1 Setting up mount (2.17.2-1) ... Setting up initscripts (2.87dsf-10) ... Setting up sysvinit (2.87dsf-10) ... sysvinit: creating /dev/initctl init: timeout opening/writing control channel /dev/initctl dpkg: e2fsprogs: dependency problems, but configuring anyway as you requested: e2fsprogs depends on util-linux (= 2.15~rc1-1); however: Package util-linux is not configured yet. Setting up e2fsprogs (1.41.11-1) ... Errors were encountered while processing: util-linux Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569120: partial-patch exists upstream
* Julien Danjou (a...@debian.org) [100512 09:35]: Andreas Barth a...@not.so.argh.org writes: there is an partial patch in: http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=701 There is not. Sorry, then I read it wrong. I read the commits it got better but not fully fixed. If that is true, I'd be happy to see the changes uploaded to Debian (it really annoys if the system aborts one to two times per week). Anyways, great windowmanager. But it would give an better user experience if it wouldn't crash. :) Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579917: mkhomedir segfaults within ld.so on startup
Package: libc6 Version: 2.7-18lenny2 Severity: grave Hi, the following happens when trying to run mkhomedir_helper. This happens with any glibc version, i.e. also in testing and unstable (that's how I found out). mkhomedir_helper is only available in testing and unstable, but well. a...@swarm:/home/buildd$ LD_LIBRARY_PATH=/usr/lib/debug: gdb ./mkhomedir_helper GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as mipsel-linux-gnu... (gdb) run Starting program: /home/buildd/mkhomedir_helper Program received signal SIGSEGV, Segmentation fault. 0x2aaab614 in dl_main () from /lib/ld.so.1 (gdb) bt #0 0x2aaab614 in dl_main () from /lib/ld.so.1 #1 0x2aac05f4 in _dl_sysdep_start () from /lib/ld.so.1 #2 0x2aaa8c98 in _dl_start_final () from /lib/ld.so.1 #3 0x2aaa8f20 in _dl_start () from /lib/ld.so.1 #4 0x2aaa in __start () from /lib/ld.so.1 Backtrace stopped: frame did not save the PC (gdb) within squeeze: Reading symbols from /tmp/mkhomedir_helper...done. (gdb) run Starting program: /tmp/mkhomedir_helper Program received signal SIGSEGV, Segmentation fault. 0x2aaab734 in dl_main (phdr=value optimized out, phnum=9, user_entry=value optimized out) at rtld.c:1617 1617rtld.c: No such file or directory. in rtld.c (gdb) bt #0 0x2aaab734 in dl_main (phdr=value optimized out, phnum=9, user_entry=value optimized out) at rtld.c:1617 #1 0x2aac21b8 in _dl_sysdep_start (start_argptr=value optimized out, dl_main=0x29d4 dl_main) at ../elf/dl-sysdep.c:243 #2 0x2aaa8ef4 in _dl_start_final (arg=0x7fbe2820, info=value optimized out) at rtld.c:333 #3 0x2aaa91a0 in _dl_start (arg=0x7fbe2820) at rtld.c:561 #4 0x2aaa88e8 in __start () from /lib/ld.so.1 Backtrace stopped: frame did not save the PC (gdb) on an squeeze machine: LD_DEBUG=all /lib/ld-2.10.2.so ./mkhomedir_helper 6625: file=/tmp/mkhomedir_helper [0]; generating link map 6625: dynamic: 0x004001c0 base: 0x size: 0x000139e0 6625: entry: 0x004008f0 phdr: 0x00400034 phnum: 9 6625: Segmentation fault I'm not convinced if the libc6 is the correct place to report this bug to, but having this bug will prevent the release of Debian on mips* (as DSA needs to have mkhomedir available). Please also note that this programm wasn't part of lenny, as the pam module was restructred recently. It however does work on i386. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579926: schroot and sbuild incompatible
Package: schroot Version: 1.4.1-2 Severity: serious Hi, after installing the recent version of sbuild from build.d.o plus schroot from testing (instead of stable), I got a lot of issues: schroot -c unstable-mipsel-sbuild W: line 6 [sid-experimental-mipsel-sbuild]: Deprecated key 'run-setup-scripts' used I: This option will be removed in the future; please update your configuration W: line 7 [sid-experimental-mipsel-sbuild]: Deprecated key 'run-exec-scripts' used I: This option will be removed in the future; please update your configuration W: line 11 [sid-experimental-mipsel-sbuild]: Unknown key 'source-users' used I: This option may be present in a newer version W: line 6 [sid-mipsel-sbuild]: Deprecated key 'run-setup-scripts' used I: This option will be removed in the future; please update your configuration W: line 7 [sid-mipsel-sbuild]: Deprecated key 'run-exec-scripts' used I: This option will be removed in the future; please update your configuration W: line 11 [sid-mipsel-sbuild]: Unknown key 'source-users' used I: This option may be present in a newer version E: 25nssdatabases: Unknown database: # System databases to copy into the chroot from the host system. E: sid-mipsel-sbuild-ffc6bdd2-a649-4cff-90c3-2385eaeaaf11: Chroot setup failed: stage=setup-start The exactly same configuration used to work prior to the upgrade to the squeeze schroot version. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575254: openjdk-6 build fails on at least one i386 build due to long command lines
* Giovanni Mascellani (mascell...@poisson.phc.unipi.it) [100502 19:09]: Il 02/05/2010 13:43, Kurt Roeckx ha scritto: $ getconf ARG_MAX 2097152 Which is just the same as in my laptop. Then I can't understand why OpenJDK builds finely on it, but doesn't on buildd. I'll have a few more experiments this night. You have to remove a bit of environment from it. It really differes only a few bytes. And then of course the directory names could be choose a bit shorter. See e.g. http://www.in-ulm.de/~mascheck/various/argmax/ Anyways, I really think the build system shouldn't even get near that limit, or something is seriously broken. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578255: phonon: must not depend on alsa on kbsd
Package: phonon Version: 4:4.6.0really4.4.0-2 Severity: serious Hi, + phonon-backend-gstreamer/kfreebsd-amd64 unsatisfiable Depends: gstreamer0.10-alsa + phonon-backend-gstreamer/kfreebsd-i386 unsatisfiable Depends: gstreamer0.10-alsa however, there is no gstreamer0.10-alsa on kbsd. This needs to be fixed prior to the release of squeeze. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578255: phonon: must not depend on alsa on kbsd
* Fathi Boudra (f...@debian.org) [100418 12:44]: it's fixed in svn since yesterday. Thanks. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558999: Build still fails ( Bug#558999: FTBFS [hppa] - recompile with -ffunction-sections )
* Torsten Werner (twer...@debian.org) [100124 14:46]: I am reassigning the bug to the gcc-4.4 package because the compiler suggest using -ffunction-sections when that argument is specified on the command line: any news on this bug? I'd appreciate if someone with more hppa / ELF knowledge than I have could take a deeper look at what is going wrong (especially as it still fails with -ffunction-sections). Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576720: [ia64] gdb FTBFS and freezes / reboots the machine
* Daniel Jacobowitz (d...@false.org) [100412 15:01]: On Tue, Apr 06, 2010 at 08:44:13PM +0200, Andreas Barth wrote: on trying to build gdb, the buildd freezes (mundy) or gets rebooted (alkman). This package was tried 3 times on mundy and 1 time on alkman. The log files ends with (please note that this may not be the last real line - the machine gets rebooted): Do you think this is a bug in GDB? It sounds like the kernel is broken. It could be any combination of it, that's why I added debian-i...@lists.debian.org as X-Debbugs-Cc initially (and also to this mail). The main reason why I filed a bug report is so that we know / are reminded that this is an issue that we need to resolve before we can release (or have to release with an older version). This bug report won't stop the testing migration of gdb, as gdb can't migrate without ia64 anyways. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576720: [ia64] gdb FTBFS and freezes / reboots the machine
Package: gdb Version: 7.1-1 Severity: serious Hi, on trying to build gdb, the buildd freezes (mundy) or gets rebooted (alkman). This package was tried 3 times on mundy and 1 time on alkman. The log files ends with (please note that this may not be the last real line - the machine gets rebooted): mundy (1/2): === gdb tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /build/buildd-gdb_7.1-1-ia64-PTRyyn/gdb-7.1/gdb/testsuite/config/unix.exp as tool-and-target-specific interface file. Running /build/buildd-gdb_7.1-1-ia64-PTRyyn/gdb-7.1/gdb/testsuite/gdb.base/watchpoint-cond-gone.exp ... Running /build/buildd-gdb_7.1-1-ia64-PTRyyn/gdb-7.1/gdb/testsuite/gdb.base/gcore.exp ... mundy3: cc -c -Wall -g -O2-I. -I/build/buildd-gdb_7.1-1-ia64-WHhGC1/gdb-7.1/gdb/gdbserver -I/build/buildd-gdb_7.1-1-ia64-WHhGC1/gdb-7.1/gdb/gdbserver/../common -I/build/buildd-gdb_7.1-1-ia64-WHhGC1/gdb-7.1/gdb/gdbserver/../regformats -I/build/buildd-gdb_7.1-1-ia64-WHhGC1/gdb-7.1/gdb/gdbserver/../../include reg-ia64.c rm -f gdbreplay cc -Wall -g -O2-I. -I/build/buildd-gdb_7.1-1-ia64-WHhGC1/gdb-7.1/gdb/gdbserver -I/build/buildd-gdb_7.1-1-ia64-WHhGC1/gdb-7.1/gdb/gdbserver/../common -I/build/buildd-gdb_7.1-1-ia64-WHhGC1/gdb-7.1/gdb/gdbserver/../regformats -I/build/buildd-gdb_7.1-1-ia64-WHhGC1/gdb-7.1/gdb/gdbserver/../../include -o gdbreplay gdbreplay.o version.o \ rm -f gdbserver cc -Wall -g -O2-I. -I/build/buildd-gdb_7.1-1-ia64-WHhGC1/gdb-7.1/gdb/gdbserver -I/build/buildd-gdb_7.1-1-ia64-WHhGC1/gdb-7.1/gdb/gdbserver/../common -I/build/buildd-gdb_7.1-1-ia64-WHhGC1/gdb-7.1/gdb/gdbserver/../regformats -I/build/buildd-gdb_7.1-1-ia64-WHhGC1/gdb-7.1/gdb/gdbserver/../../include -o gdbserver inferiors.o regcache.o remote-utils.o server.o signals.o target.o utils.o version.o mem-break.o hostio.o event-loop.o reg-ia64.o linux-low.o linux-ia64-low.o hostio-errno.o \ make[5]: Leaving directory `/build/buildd-gdb_7.1-1-ia64-WHhGC1/gdb-7.1/build/objdir/gdb/gdbserver' alkman: touch debian/stamp-makefile-build DEB_MAKE_CHECK_TARGET unset, not running checks ulimit -c unlimited; \ /usr/bin/make -j 2 -C /build/buildd-gdb_7.1-1-ia64-H3FplI/gdb-7.1/build/objdir/gdb check Both machines run an 2.6.32-bpo.2-mckinley kernel. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576768: gnarwl 3.6.dfsg-1 (ia64) FTBFS: depends on libc6-dev
Package: gnarwl Version: 3.6.dfsg-1 Architecture: ia64 Severity: serious Hi, this package has wrong build depends: Build-Depends: debhelper (= 7), libldap2-dev, libgdbm-dev, libc6-dev (= 2.10), po-debconf, quilt However, libc6-dev doesn't exist on ia64. Andi -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
