Bug#551142: python-kde4-dev: /usr/bin/pykdeuic4 symlink broken
+ Sune Vuorela (Fri, 16 Oct 2009 09:27:55 +0100): Hi dato Hello! I'm not completely sure how pykdeuic is supposed to be used. it seems like for users it doesn't matter. I use it in the same way the regular uic-qt4 is used: you call it at compile time to generate the code that builds up the interface. Since it's Python code, at compile time means when generating the tarball to be released, so that the tarball includes directly the python code in addition to the source. Or it could be at package build time, so that the Debian package surely does. System-config-printer-kde seems to just dynamically load the .ui files on demand by using some from PyQt4 import uic and a bit later class MyClass def __init__() uic.loadUI(path/to/ui/file.ui,self) I see. Well, that requires that uic is installed of the user's machine. Which is normally not the case with C++ uic, but seems to be the case with uic for Qt in Python. (But not for KDE, since it's in the python-kde4-dev package.) I guess there is two possibilities. either remove teh symlink completely or make it point to where pykdeuic4.py now resides. Please the latter. It is supposed to be an executable on the system AFAIK. and does changing the symlink to point to /usr/share/pyshared/PyQt4/uic/pykdeuic4.py fix it for you ? Yes, if I make the file exectuable as well. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551142: python-kde4-dev: /usr/bin/pykdeuic4 symlink broken
Package: python-kde4-dev Version: 4:4.3.2-1 Severity: serious /usr/bin/pykdeuic4 points to ../lib/python2.5/site-packages/PyQt4/uic/pykdeuic4.py but that file does not exist. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548570: minirok segfaults
+ Jonas Meurer (Sun, 27 Sep 2009 12:30:28 +0200): Package: minirok Version: 2.0-1 Severity: grave Justification: renders package unusable hello, minirok segfaults on my up-to-date debian/unstable system: Hello Jonas, this was caused by an incompatibility in PyQt 4.6. I believe I have fixed the problem. Before doing an upload, would you mind testing the packages at [1] (they are sort of 2.1~rc1)? Thanks! [1]: http://chistera.yi.org/~adeodato/tmp/2009-10-15/minirok_2.1~r768-1_all.deb -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540057: python-qt4: needs to Break: python-kde4 ( 4:4.2.4)
Package: python-qt4 Version: 4.5.1-1.1 Severity: serious Apparently, python-qt4 4.5.1 breaks python-kde4 4.2.2: % dpkg -l python-kde4 python-qt4 ii python-kde44:4.2.2-3 ii python-qt4 4.5.1-1.1 % python from PyKDE4 import kdecore zsh: segmentation fault (core dumped) python So, I think a Breaks: python-kde4 ( 4:4.2.4) is in order. Additionally, the versioning of python-qt4 in unstable has left python-kde4 4.2.4 uninstallable (though that's arguably a bug in python-kde4 itself that'll get fixed in the next upload). Despite this, I've verified python-kde 4.2.4 works fine with python-qt4 4.5.1-1.1. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515274: RM: gbuffy -- RoM; uses GTK+1.2
Package: ftp.debian.org I'm Bcc'ing #515274, the serious bug regarding gbuffy depending on GTK+1.2, in case anybody following that bug can be aware of the removal request. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531219: Bug#530345: bitlbee-dev currently uninstallable due to binNMUs
Hey, Wilmer.
forcemerge 530345 531219
ASAP. (And by the way there are currently two other RC bugs open, both
uncommented since three months.)
Best of all, the one you're reporting is a dupe. :-)
Well, techincally they're different issues: you can fix #530345 just by
doing a sourceful upload with no changes, but source changes are needed
to fix #531219. But it seems you're interested in fixing #531219 already,
which is excellent. :-)
Depends: bitlbee (= ${binary:Version})
The dependency seems right already, it's a binary dep, not a source dep.
I see other programs just make the dependency less tight by doing
something like
Depends: foo (= ${source:Version})
Is that the best I can get? :-/
Well. The problem is that bitlbee-dev is an arch:all package. So, when
you want strict dependencies among binaries from a same source package,
you use:
arch:any Depends arch:any = ${binary:Version}
arch:any Depends arch:all = ${source:Version}
arch:all Depends arch:all = ${source:Version}
arch:all Depends arch:any = not possible*
So with not possible I mean that you need, normally:
Depends: foo (= ${source:Version}), foo ( ${source:Version}.)
or something similar.
HTH,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515274: gbuffy: Depends on GTK 1.2
+ Kelvin Ku (Thu, 21 May 2009 12:08:39 -0400): Thanks for the gtk2 patch. We are not using debian so we're not sure what your build environment is, but we encountered a few hitches building it after patching: Hello, Kelvin. Thanks for providing these fixes for the GTK2 patch. If I'm not mistaken, the upstream of GBuffy is not really active any more, so I think if somebody feels up to maintaining it as upstream, they should go for it. Is this something any of you would be interested in? Personally, I don't use GBuffy anymore myself, so I also need to find another person to become its Debian maintainer. Thanks! - the original configure was built with autoconf 2.13, but the patched configure.in uses gtk2 m4 macros which seem to require autoconf 2.61 - the Makefile.in does not work with configure generated by autoconf 2.61; the resulting Makefile has some un-substituted $expressions - fix: hack configure to make it work Also, the patched gbuffy itself had some problems: - segfaults when opening the configuration dialog or displaying headers (both operations try to draw a pixmap) - fix: remove the gdk_draw_bitmap function in gbuffy.c so that the internal gdk_draw_drawable function is used instead - window resets position when gbuffy_display is called again, e.g., after closing configuration dialog - fix: use a configure_event callback instead of using the timeout callback to update internal window state after a position/dimension change - mailbox button and main window don't grow and shrink immediately/correctly in response to changes in button label lengths (mailbox: count) - fix: still working on it; button and window sizes are correct when gbuffy is initially launched now, but not while it is running We're not sure who exactly to contact about patching gbuffy, since the gtk2 patches seem to be pending only for the debian package. The gendiff output for our patches is below, if you're interested. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528405: new pulseaudio with uncomplete dependencies
+ Steve Langasek (Sun, 17 May 2009 13:10:01 -0700): On Sun, May 17, 2009 at 04:11:20PM +0200, Adeodato Simó wrote: + Adeodato Simó (Sun, 17 May 2009 11:21:06 +0200): The problem is a bug in the packaging of pulseaudio itself, which doesn't specify in its Depends field that it needs the latest version of libpulse0 to run, despite linking to libpulsecommon-0.9.15.so. According to the Debian Policy, this is a serious bug. (Assuming, of course, that libpulsecommon-0.9.15.so is some kind of private library that only packages from the same source depend on/link against, and that for this reason is okay to ship in libpulse0 and bump its SONAME without a package rename.) It's a new library; I guess (hope) that it's a new API and therefore there are no backwards-incompatibilities that would require a package name change. Oh, I see. Good. Still, perhaps it should be assesed how many apps are going to use this library (is it a private one?), and if it's going to see its SONAME bumped more often than libpulse.so.0 (which one would say is going to be the case by looking at its name), as to avoid having to unnecessarily rename libpulse0. Or, if only a couple packages from the same source package depend on this library, maybe we could do away with Breaks. Thoughts? -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528405: new pulseaudio with uncomplete dependencies
reassign 528405 pulseaudio retitle 528405 pulseaudio: dependency on libpulse0 should be versioned severity 528405 serious thanks + Moritz Molle (Tue, 12 May 2009 20:10:01 +0200): Hello, Moritz. Thanks for reporting this bug Package: pulseaudio Version: 0.9.15-1 Severity: critical Justification: breaks unrelated software Said pulseaudio-package doesn't enforce the installation of a package with libpulsecommon-0.9.15.so in it, so now executing pulseaudio just delivers following message: pulseaudio: error while loading shared libraries: libpulsecommon-0.9.15.so: cannot open shared object file: No such file or directory If I try to install libpulse0 which, according to apt-file, contains said library, it says that it has to remove pavucontrol. I don't want that. I have marked this bug as critical, because it breaks all programs which try to load the pulseaudio-sound-libraries as well. (I have set FLASH_FORCE_PULSEAUDIO=1, and now my iceweasel doesn't start anymore, that's not acceptable) apt-get should have refused to update pulseaudio in the first place. The problem is a bug in the packaging of pulseaudio itself, which doesn't specify in its Depends field that it needs the latest version of libpulse0 to run, despite linking to libpulsecommon-0.9.15.so. According to the Debian Policy, this is a serious bug. Regarding your trying to upgrade libpulse0 and apt wanting to remove pavucontrol, it is just unfortunate that pulseaudio was allowed to migrate to testing without the newer pavucontrol migrating as well, since libpulse0 clearly specifies they should go in together (but the migration script does not support this field, Breaks, yet). And pavucontrol has not migrated yet because it's not built on mipsel, and it's going to be a while until it can be built there due to a toolchain bug. I've added a hint that will hopefully allow pavucontrol to migrate to testing without mipsel in the next britney run. In the meantime, you should be able to install pavucontrol from unstable, if you haven't done so already. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527838: smart: FTBFS: debian/tmp does not exist
+ Daniel Schepler (Fri, 08 May 2009 14:11:21 -0700): Package: smart Version: 1.2-1 Severity: serious Hello, From my pbuilder build log: ... fakeroot debian/rules binary test -x debian/rules dh_clean -k dh_installdirs -A mkdir -p . mkdir -p debian/python-module-stampdir if test -e /usr/share/misc/config.guess ; then \ for i in ./contrib/ksmarttray/admin/config.guess ; do \ if ! test -e $i.cdbs-orig ; then \ mv $i $i.cdbs-orig ; \ cp --remove-destination /usr/share/misc/config.guess $i ; \ fi ; \ done ; \ fi if test -e /usr/share/misc/config.sub ; then \ for i in ./contrib/ksmarttray/admin/config.sub ; do \ if ! test -e $i.cdbs-orig ; then \ mv $i $i.cdbs-orig ; \ cp --remove-destination /usr/share/misc/config.sub $i ; \ fi ; \ done ; \ fi dh_installdirs -psmartpm dh_movefiles -psmartpm dh_movefiles: debian/tmp does not exist. make: *** [install/smartpm] Error 1 dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status 2 I'll note that this failure is not reproducible in the buildds. All recent uploads of smart have managed to get built in all architectures. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528405: new pulseaudio with uncomplete dependencies
+ Adeodato Simó (Sun, 17 May 2009 11:21:06 +0200): The problem is a bug in the packaging of pulseaudio itself, which doesn't specify in its Depends field that it needs the latest version of libpulse0 to run, despite linking to libpulsecommon-0.9.15.so. According to the Debian Policy, this is a serious bug. (Assuming, of course, that libpulsecommon-0.9.15.so is some kind of private library that only packages from the same source depend on/link against, and that for this reason is okay to ship in libpulse0 and bump its SONAME without a package rename.) Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528527: Package candidate for removal for GNOME transition
+ Arnaud Fontaine (Wed, 13 May 2009 15:48:38 +0200): I am quite busy at the moment with my exams but I think I can upload version 1.0.1 of gwget before the end of the week-end (I hope that would be ok this way?). This new upstream version ships support for epiphany 2.26, thus fixing this RC bug. That's excellent, Arnaud. Thank you for your effort, and good luck with your exams! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528525: evolution-jescs: uninstallable
Package: evolution-jescs Version: 2.24.0-1 Severity: serious Your package Conflicts: evolution (= 2.25.0), but 2.26 is in unstable. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528527: epiphany-extension-gwget: uninstallable
Package: epiphany-extension-gwget Version: 0.99-3 Severity: serious Your package Depends: epiphany-gecko ( 2.23), but 2.26 is in unstable. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528525: Package candidate for removal for GNOME transition
Hello, gwget2, evolution-rss, evolution-jescs and icewm are all RC buggy and are being considered for removal in order to get GNOME 2.24/26 migrate to testing. I note that the RC bugs of gwget2 and evolution-jescs have only been filed minutes ago, so if the maintainers express they intend to upload very soon, effort will be put in getting it built quickly and in time in order for it not to be removed. However, the RC bugs have existed unfiled for more than a week, so we'll also take that into account if everything else gets ready. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522584: Dependency going away
+ Leopold Palomo Avellaneda (Tue, 14 Apr 2009 13:24:25 +0200): A Diumenge 05 Abril 2009, Ana Guerrero va escriure: bulmages-common depends on kpdf that is going away RSN with kde3 being replaced with kde4. Your package will become uninstallable then. Bulmages upstream is doing a big restructuring. So, the package in sid will be non operative soon. When upstream stabilizes their code (I hope soon) I will try to commit a new package, erasing (and adding) the dependency correctly, I leave this bug as pending. Thanks to report it. This is your choice, but not fixing it means your package will have to be removed from testing as soon as KDE4 is ready to migrate without further notice. If you prefer, you can make an upload just changing the dependency, that should suffice. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524452: Bug#523596: problem of 523596 is in graphicsmagick
+ Thomas Viehmann (Fri, 08 May 2009 08:39:41 +0200): tag 524452 + patch thanks Thanks Daniel for the update. Unfortunately, psiconv still fails to build with this version because it apparently makes use of a prehistoric and long deprecated API function. It doesn't really make sense to schedule another bin-NMU until this is problem fixed with a psiconv upload. Then lets move the conversation to #524452. Tested with the Clipart file in tarball's examples directory. I will not comment on the nature of that file, though. Ah, great, thanks Thomas. Daniel, do you think you could make an upload? Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527462: gnunet: uninstallable
Package: gnunet Version: 0.8.0b-5 Severity: serious Hello, gnunet was recently Bin-NMUed for the libltdl7 transition. Because of #527453 (gnunet: not Bin-NMU safe), this rendered the gnunet metapackage uninstallable. I'm filing this as a separate report to #527453 because a simple sourceful upload will fix this bug, whereas #527453 needs source changes. Ideally, #527453 will be addressed at the same time as that sourceful upload happens, but it's not strictly necessary. (Hence, also, the differing severities of both bug reports.) Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527461: please binNMU monotone for botan transition
+ Zack Weinberg (Wed, 06 May 2009 12:55:20 -0700): Hello, Zack (and keysafe maintainers). Hi, per the appended bug report, monotone needs to be recompiled to pick up the new libbotan soname. Please schedule: nmu monotone_0.43-3 . ALL . -m Recompile with botan-devel 1.8.2 dw monotone_0.43-3 . ia64 mips mipsel sparc . -m 'libbotan1.8-dev (= 1.8.2-1)' This closes bug #527314. I have verified that the package builds with the new library. monotone and keysafe certainly need to be rebuilt against the new version of botan, since the SONAME has changed. However, the libbotan1.8 binary package name should have been renamed in the process of bumping the SONAME (Bug#527461), and I won't be scheduling Bin-NMUs of either package until that has happened. The reason for not scheduling the Bin-NMUs is that they would be freely migrating to testing, which still has Botan 1.8.1, and then the bug would happen there in addition to unstable (not only botan 1.8.2 didn't rename the binary package, it also has a bogus shlibs file!). However, I realize having this situation in unstable is inconvenient, so you may make sourceful uploads of monotone and keyfile in order to get them rebuilt. The point is that, independently of you taking up on this offer or not, I'll block migration of these pacakges to testing until the issue is fixed in botan, just in case; so you may as well upload. (New source versions can easily be blocked from migration, Bin-NMUs can't be.) Cheers, -- Forwarded message -- Package: monotone Version: 0.43-3 Severity: grave Justification: renders package unusable libbotan1.8 was recently upgraded from 1.8.1 to 1.8.2. $ mtn mtn: error while loading shared libraries: libbotan-1.8.1.so: cannot open shared object file: No such file or directory $ ldd /usr/bin/mtn ... libbotan-1.8.1.so = not found ... $ ls -l /usr/lib/libbotan*.so -rw-r--r-- 1 root root 2905232 2009-05-04 03:58 /usr/lib/libbotan-1.8.2.so lrwxrwxrwx 1 root root 17 2009-05-06 13:07 /usr/lib/libbotan.so - libbotan-1.8.2.so Monotone needs to be rebuilt against the new Botan 1.8.2. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527461: libbotan1.8: SONAME bumped without package rename
Package: libbotan1.8 Version: 1.8.2-1 Severity: serious Hello, libbotan1.8/1.8.2-1 introduces a new SONAME with respect to 1.8.1-1, but the binary package has not been renamed. That's not a supported workflow in Debian. I recommend you start naming the binary packages according to the actual SONAME. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523596: problem of 523596 is in graphicsmagick
+ Daniel Kobras (Thu, 07 May 2009 20:44:16 +0200): Hi Dato! Hello! On Thu, May 07, 2009 at 08:59:33AM +0200, Adeodato Simó wrote: Do you have an estimation of when you'll be able to address this issue? It seems to be the last bit needed for the graphicsmagick transition to become a candidate to be tried for migration (in particular, the fix is needed so that psiconv can be rebuilt, and it's the last reverse dependency needing to be built). I've just uploaded graphicsmagick 1.3.5-5 with a sanitised GraphicsMagick-config. Great, thanks Daniel. Unfortunately, psiconv still fails to build with this version because it apparently makes use of a prehistoric and long deprecated API function. It doesn't really make sense to schedule another bin-NMU until this is problem fixed with a psiconv upload. Ah, good thing that you tried to build it, then. Thomas, is this something you could tackle? As I said elsewhere, I'd rather not remove psiconv from testing since it provides a library with a reverse dependency. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523596: problem of 523596 is in graphicsmagick
Hey, Daniel. reassign 523596 libgraphicsmagick1-dev retitle 523596 Bogus cflags returned by GraphicsMagick-config $ GraphicsMagick-config --cflags -fopenmp -Wall -g -fno-strict-aliasing -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector -fPIE -O2 -Wall -pthread Not good. Here it is -fPIE causing trouble (FTBFS), but I do not think that it has any business specifying any of the above. Similar considerations probably apply to other options and other -config. Do you have an estimation of when you'll be able to address this issue? It seems to be the last bit needed for the graphicsmagick transition to become a candidate to be tried for migration (in particular, the fix is needed so that psiconv can be rebuilt, and it's the last reverse dependency needing to be built). If not, Thomas has offered to prepare a fix to be uploaded. I'm told he could prepare an upload that would just provide under debian/ -config executables that completely substitute upstream's, or a patch that fixes the upstream code itself. Please let us know what you prefer: upload yourself, and in this case let us know an approximate ETA, or a NMU, and in this case let us know your preferred approach. Thanks! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527224: Please binNMU ocsigen/1.1.0-2
+ Stéphane Glondu (Wed, 06 May 2009 13:08:08 +0200): Hello, nmu ocsigen_1.1.0-2 . ALL . -m 'Recompile with ocaml-sqlite3 1.4.0' This would close #527224. Scheduled. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524585: libept_0.5.26+b1(mips/unstable): FTBFS on mips
close 524585 thanks + Peter De Schrijver (Sat, 18 Apr 2009 12:44:51 +0300): dh_install -plibept0 dh_install: libept0 missing files (debian/tmp/usr/lib/lib*.so.*), aborting make: *** [binary-install/libept0] Error 1 dpkg-buildpackage: failure: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2 I'm closing this bug because libept managed to build successfully on mips recently: https://buildd.debian.org/fetch.cgi?pkg=libept;ver=0.5.26+b1;arch=mips;stamp=1241331185 The failure was most probably caused by the kernel/glibc problem that's been aflicted to the mipsen buildds. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526792: vsftpd: some libraries are linked to with hard-coded SONAMEs
Package: vsftpd Version: 2.1.1~pre1-1 Severity: serious From vsftpd-2.1.1~pre1-1/vsf_findlibs.sh: # Look for libcap (capabilities) if locate_library /lib/libcap.so.1; then echo /lib/libcap.so.1; else locate_library /usr/lib/libcap.so echo -lcap; locate_library /lib/libcap.so echo -lcap; fi That's wrong, as it prevents rebuilding against a newer version of libcap unless the old version is purged from the system first. Please patch that script to just execute the else part, which will do the right thing in every Debian installation with the correct development packages installed. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525071: Update
The maintainer of libcrypto++ can reproduce the problem and is taking a look. However, it may take a while. In the meantime, amule will be unable to migrate to testing. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525071: Regarding the amule segfault bug
Hello all. Thanks for your report about the current segfault in Debian. I've asked the libcrypto++ maintiner to help with the issue, since the crash seems to happen in libcrypto++ code, and he's taking a look at the issue. I'll keep you updated about any progress. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523502: Could somebody upload this? TIA. (was RFS: quick-lounge-applet (updated package))
Uhm, thanks for trying to sponsor, and I’m sorry it failed. I’m CC'ing the maintainer (Diego Fernández) so that he can take a look at fixing. Diego, according to Josselin Mouette, the problem is that the GnomeDItemEdit API has been removed in GNOME 2.26, and quick-lounge-applet should be ported to use GKeyFile instead. Fortunately, Joss said there’s a new upstream version of q-l-a that does this. Could you prepare an upload? Thanks both! + LI Daobing (Wed, 22 Apr 2009 20:39:42 +0800): Hello, On Wed, Apr 22, 2009 at 20:34, LI Daobing lidaob...@gmail.com wrote: Hello, On Wed, Apr 22, 2009 at 15:42, Adeodato Simó d...@net.com.org.es wrote: It’d be great if somebody would take a look into uploading this package, since it’s needed for the gnome-desktop transition. Many thanks in advance! + Diego Fernández Durán (Fri, 10 Apr 2009 23:36:17 +0200): Dear mentors, I am looking for a sponsor for the new version 2.12.5-6 of my package quick-lounge-applet. It builds these binary packages: quick-lounge-applet - GNOME panel applet to organise preferred applications The package appears to be lintian clean. The upload would fix these bugs: 523502 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/quick-lounge-applet - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/quick-lounge-applet/quick-lounge-applet_2.12.5-6.dsc I would be glad if someone uploaded this package for me. I'll take a look on this. build failed with cowbuilder cc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -DPREFIX=\/usr\ -DSYSCONFDIR=\/etc\ -DDATADIR=\/usr/share\ -DLIBDIR=\/usr/lib\ -DGNOMELOCALEDIR=\/usr/share/locale\ -DGLADEDIR=\/usr/share/quick-lounge-applet/glade\ -DGMENU_I_KNOW_THIS_IS_UNSTABLE -pthread -D_REENTRANT -DORBIT2=1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/libgnome-2.0 -I/usr/include/orbit-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libbonobo-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/include/libart-2.0 -I/usr/include/gnome-keyring-1 -I/usr/include/libbonoboui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libxml2 -I/usr/include/gail-1.0 -I/usr/include/gnome-vfs-module-2.0 -I/usr/include/gnome-desktop-2.0 -I/usr/include/startup-notification-1.0 -I/usr/include/libglade-2.0 -I/usr/include/panel-2.0 -I/usr/include/gnome-menus -g -O2 -g -Wall -O2 -c dlg-properties.c dlg-properties.c:31:41: error: libgnomeui/gnome-ditem-edit.h: No such file or directory dlg-properties.c: In function 'update_list': dlg-properties.c:422: warning: unused variable 'box' dlg-properties.c: In function 'get_button_from_uri': dlg-properties.c:712: warning: unused variable 'box' make[3]: *** [dlg-properties.o] Error 1 make[3]: Leaving directory `/tmp/buildd/quick-lounge-applet-2.12.5/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/buildd/quick-lounge-applet-2.12.5' make[1]: *** [all] Error 2 make[1]: Leaving directory `/tmp/buildd/quick-lounge-applet-2.12.5' make: *** [debian/stamp-makefile-build] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 E: Failed autobuilding of package I: unmounting dev/pts filesystem I: unmounting proc filesystem - Cleaning COW directory forking: rm -rf /var/cache/pbuilder/build//cow.13401 -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523502: Could somebody upload this? TIA. (was RFS: quick-lounge-applet (updated package))
+ Diego Fernández Durán (Fri, 24 Apr 2009 13:28:39 +0200): About the cowbuilder error, I successfully compiled 2.12.5-6 package with pdebuild. I don't know exactly what is failing. When you sent your initial RFS, gnome-desktop 2.26 hadn’t been uploaded to unstable yet, that’s why succeeded. Then, when gnome-desktop 2.26 hit unstable, it started failing. I hope the new upstream version works better with the new libraries. I think it will. :-) Ciao, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523502: Could somebody upload this? TIA. (was RFS: quick-lounge-applet (updated package))
It’d be great if somebody would take a look into uploading this package, since it’s needed for the gnome-desktop transition. Many thanks in advance! + Diego Fernández Durán (Fri, 10 Apr 2009 23:36:17 +0200): Dear mentors, I am looking for a sponsor for the new version 2.12.5-6 of my package quick-lounge-applet. It builds these binary packages: quick-lounge-applet - GNOME panel applet to organise preferred applications The package appears to be lintian clean. The upload would fix these bugs: 523502 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/quick-lounge-applet - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/quick-lounge-applet/quick-lounge-applet_2.12.5-6.dsc I would be glad if someone uploaded this package for me. Kind regards Diego Fernández Durán -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#456133: qiv imlib
+ Bart Martens (Sat, 18 Apr 2009 13:01:46 +0200): On Fri, 2009-04-17 at 10:09 +0200, Adeodato Simó wrote: I suggest somebody packages pqiv, we let it migrate to testing, and then we remove imlib11 and qiv from testing once icewm has stopped using it. I don’t mind that we leave qiv around in unstable for users who may not be happy with pqiv, and to “wait and see” if upstream moves and ends up upgrading to imlib2. But if Squeeze comes and this has not happened, we should remove qiv from unstable as well I think. Bart, thanks for the pointer to pqiv: would you be up to packaging it? I’m a qiv user myself, and after compiling it here, it seems to fill the niche gracefully. If not, I’ll file a RFP. Thoughts on this plan? Good plan. I just uploaded pqiv Aha. I’m CCing Andreas Metzler, though he problably read your mail via -release or something: he managed to file ITP #524569 roughly an hour before you filed #524578, but since he said “I am not stuck on maintaining this myself”, he’ll hopefully not mind you having prepared and uploaded your own as well. I chose to package pqiv without Conflicts/Provides/Replaces qiv. At least for now. Yes, I think not going Conflict/Provides/Replaces for now is a good choice (people can try it without uninstalling qiv, etc.). Just remember to do the dance if qiv doesn’t make it to Squeeze after all. I see that qiv upstream has a new developer, so maybe the imlib problem in qiv gets solved before squeeze freeze. http://www.klografx.net/qiv/ Qiv is not longer supported by me (Adam Kopacz), please visit the new Homepage: spiegl.de/qiv http://spiegl.de/qiv/ qiv.a...@spiegl.de Ah, that’s great; ideally both maintainers of qiv and pqiv should be made aware one of another if it hasn’t happened already. :-) Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522716: Pulseaudio upload to unstable
Hey, Sjoerd. Any plans to make an upload of pulseaudio to unstable (either 0.9.14-2, or a 0.9.15 version), addressing some of its RC bugs? Particularly the FTBFSes on hppa (#520378) and with new libtool (#522716), and seeing what’s up with #521282 would be nice too. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520378: Pulseaudio upload to unstable
+ Sjoerd Simons (Sat, 18 Apr 2009 18:46:02 +0100): On Sat, Apr 18, 2009 at 07:12:30PM +0200, Adeodato Sim? wrote: Hey, Sjoerd. Any plans to make an upload of pulseaudio to unstable (either 0.9.14-2, or a 0.9.15 version), addressing some of its RC bugs? Particularly the FTBFSes on hppa (#520378) and with new libtool (#522716), and seeing what???s up with #521282 would be nice too. An upload of 0.9.15 will happen soon (either today or tomorrow), which should fix the HPPA FTBS and seems to build fine with current libtool on my machine. #521282 will probably not be fixed in that upload (it seems to be at least two different bugs and need some investigation) Great, thanks for the status update! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518673: libidn_1.12-2(hppa/experimental): FTBFS: java not available on hppa
+ Simon Josefsson (Fri, 17 Apr 2009 00:29:51 +0200): The sparc experimental buildd has failed to build the latest upload, since the buildd doesn't seem to have gcj. As far as I can tell, that would be a problem with the sparc buildd. There are gcj packages for sparc in the archive. This is a problem with them being temporarily uninstallable. I’ve set for libidn to be retried when they go back to being installable. I’ve looked at what you did. It indeed does the job, and that’s the basic idea to use, debhelper’s -N. A bit more idiomatic code is: | NO_JAVA_ARCHES := arm hppa hurd-i386 | DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) | | ifeq (,$(filter $(DEB_HOST_ARCH),$(NO_JAVA_ARCHES))) | ENABLE_JAVA := --enable-java | else | export DH_OPTIONS=-Nlibidn11-java | endif And then, you can lose all the $(DH_NO_JAVA) part when calling the dh_ commands, because debhelper picks it up via DH_OPTIONS from the environment. Oh, much nicer, thank you. I'm using it now. :-) I'm going to wait some days to see if any experimental buildd's fail unexpectedly, but then I'll upload to unstable. Sounds good, thanks. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518673: libidn_1.12-2(hppa/experimental): FTBFS: java not available on hppa
+ Simon Josefsson (Fri, 17 Apr 2009 09:26:00 +0200): Before uploading to unstable, I also need to sort out the lib vs java section override for libidn11-java. And there seems to be an old build-dependency on autotools-dev in libidn which should probably be removed, it doesn't seem to do anything useful. I’m not sure about the section business, the best you can do is reply to the override email and ask ftpmaster what’s the correct section. Regarding autotools-dev, it is used by debian/rules and does useful stuff: cp -f /usr/share/misc/config.sub config.sub cp -f /usr/share/misc/config.guess config.guess You can read /usr/share/doc/autotools-dev/README.Debian.gz for some information. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#456133: qiv imlib
+ Bart Martens (Mon, 13 Apr 2009 11:20:05 +0200): At this point, the most recent upstream version of qiv still needs the old imlib. Where to go from here ? Possible options: 1. Barry is working with upstream to get qiv updated to no longer need the old imlib. Let's appreciate Barry's efforts by giving Barry some more time to finish this effort. 2. We could replace qiv by pqiv, which is a program that more or less behaves like qiv. 3. Removal from Debian, although popcon reveals that there are still quite some users. I suggest somebody packages pqiv, we let it migrate to testing, and then we remove imlib11 and qiv from testing once icewm has stopped using it. I don’t mind that we leave qiv around in unstable for users who may not be happy with pqiv, and to “wait and see” if upstream moves and ends up upgrading to imlib2. But if Squeeze comes and this has not happened, we should remove qiv from unstable as well I think. Bart, thanks for the pointer to pqiv: would you be up to packaging it? I’m a qiv user myself, and after compiling it here, it seems to fill the niche gracefully. If not, I’ll file a RFP. Thoughts on this plan? -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518673: libidn_1.12-2(hppa/experimental): FTBFS: java not available on hppa
+ Simon Josefsson (Fri, 17 Apr 2009 09:58:15 +0200): Regarding autotools-dev, it is used by debian/rules and does useful stuff: cp -f /usr/share/misc/config.sub config.sub cp -f /usr/share/misc/config.guess config.guess Those files will never be used during the build, upstream libidn uses these files from build-aux/ since many release ago. Then maybe they should be copied to build-aux? Or ensure they’re copied to the appropriate place. You can read /usr/share/doc/autotools-dev/README.Debian.gz for some information. I've read it, but I think it is based on old understanding of autoconf/automake/libtool. For example, it doesn't discuss autoconf 2.6x and libtool 2.x at all. The files shipped in the autotools-dev file are older than what libidn ships. So I think autotools-dev does more harm than good in this case. Hm, then it sounds like a bug in autotools-dev, rather than a motive to ditch it completely. Anyway, it’s your choice, and my job here is done. :-) Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518673: libidn_1.12-2(hppa/experimental): FTBFS: java not available on hppa
Hello, Right, I have made this change in the 1.14-2 upload. I ended up using: Build-Depends: debhelper (= 6), autotools-dev, gcj [!arm !hppa !hurd-i386], fastjar Because only arm, hppa, and hurd-i386 are official debian architectures that lack gcj packages in unstable. Okay. If you creates -java packages that are arch:any, in addition to debian/control, you must modify your debian/rules to handle gracefully being built on a system without gcj. The result should be that the libidn11-java is not built at all; you can do that with the -N switch of debhelper. You should be able to find example code. I didn't find any example code, but I worked out something that worked on local testing. I’ve looked at what you did. It indeed does the job, and that’s the basic idea to use, debhelper’s -N. A bit more idiomatic code is: | NO_JAVA_ARCHES := arm hppa hurd-i386 | DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) | | ifeq (,$(filter $(DEB_HOST_ARCH),$(NO_JAVA_ARCHES))) | ENABLE_JAVA := --enable-java | else | export DH_OPTIONS=-Nlibidn11-java | endif And then, you can lose all the $(DH_NO_JAVA) part when calling the dh_ commands, because debhelper picks it up via DH_OPTIONS from the environment. Anyway, your version worked, as you can see in: http://buildd.ayous.org/fetch.php?pkg=libidnver=1.14-2arch=hppastamp=1239910858file=logas=raw You can see in the resulting .changes file that the libidn11-java package was not built. P-a-s would be relevant here if libidn11-java was arch:any, and only because libidn provides some non-java packages. I didn't understand the purpose of that file -- is it still something that we should consider? If we can solve things in the local debian/ directory, that seems preferable to me. No, you don’t need P-a-s. I hope this mail cleared things for you. Yes thank you! Hopefully it will work better with this upload, but if it doesn't I hope you still have some patience to help me make it work. Sure. :-) Thanks for your work, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524161: network-manager: FTBFS on alpha: nm-serial-device.c:366: error: array subscript is above array bounds
Package: network-manager Version: 0.7.0.100-1 Severity: serious Hello, there was an error while trying to autobuild network-manager on alpha: | cc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../marshallers -I../src/named-manager -I../src/vpn-manager -I../src/dhcp-manager -I../src/supplicant-manager -I../src/dnsmasq-manager -I../libnm-util -I../callouts -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -DDBUS_API_SUBJECT_TO_CHANGE -DG_DISABLE_DEPRECATED -DBINDIR=\/usr/bin\ -DSBINDIR=\/usr/sbin\ -DLIBEXECDIR=\/usr/lib/NetworkManager\ -DDATADIR=\/usr/share\ -DSYSCONFDIR=\/etc\ -DLOCALSTATEDIR=\/var\ -DNM_RUN_DIR=\/var/run/NetworkManager\ -DNMLOCALEDIR=\/usr/share/locale\ -DARP_DEBUG -Wall -Werror -std=gnu89 -g -O2 -g -Wall -O2 -Wshadow -Wmissing-declarations -Wmissing-prototypes -Wdeclaration-after-statement -Wfloat-equal -Wno-unused-parameter -Wno-sign-compare -fno-strict-aliasing -c -o NetworkManager-nm-serial-device.o `test -f 'nm-serial-device.c' || echo './'`nm-serial-device.c | cc1: warnings being treated as errors | nm-serial-device.c: In function 'nm_serial_device_open': | nm-serial-device.c:366: error: array subscript is above array bounds | nm-serial-device.c:367: error: array subscript is above array bounds | make[5]: *** [NetworkManager-nm-serial-device.o] Error 1 | make[5]: Leaving directory `/build/buildd-network-manager_0.7.0.100-1-alpha-QRYpUb/network-manager-0.7.0.100/src' The full log can be read at [1]. I wanted to migrate network-manager to testing already, playing some tricks with gnome-main-menu, but this failure is preventing me from doing so, and I won’t be able to hold gnome-main-menu for much longer. Cheers, [1]: https://buildd.debian.org/fetch.cgi?pkg=network-managerver=0.7.0.100-1arch=alphastamp=1239731697file=log -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#476376: Reverting the libmpc 0.1~r435-1 upload
+ Sebastian Dröge (Sat, 21 Mar 2009 09:26:20 +0100): Hello, I'll take a look at some packages in the next days and send an status update to those bugs, maybe raising the severity to important now... Sure, important sounds fine to me, thanks. Ok, done... the affected packages are: cmus Bug #476382 cynthiune.app Bug #476381 gst-plugins-bad0.10 Ported k3b Bug #476379 libtunepimp Bug #476378 moc Ported (FTBFS atm because of other issues) mpc123 Bug #476372 mpd Bug #476377 mplayer Bug #476384 qmmp Bug #520596 quodlibet Unnecessary dependency, bug #476376 vlc Bug #476375 xine-lib Bug #476374 xine-lib-1.2 Bug #520600 xmms2 Bug #476373 Some of them might actually be ported already but they don't build their musepack support with the experimental package right now. This might be because the header location has changed after I've filed those bugs, now it's final though :) Well, none of those bugs has been fixed in experimental by now (nor have a patch), and the one marked as pending (the one that is not quodlibet), has a comment by the maintainer stating that he intends to disable musepack support while upstream gets around to fixing the issue. The picture doesn’t look very promising: http://bit.ly/libmpcdec6-transition I’m all for getting this transition done without leaving the old API around, but at the same time I don’t want packages unbuildable in unstable, with failures that are not straightforward to fix, for a long period of time. As I said in one of my earlier mails, I won’t feel comfortable with going forward with this transition until all (or most) of the packages have tested patches. The thing is that for this to happen, we’re going to need either time, quite a lot of it, or for somebody to step up and start “driving” the transition, filling the gaps the maintainers may leave. So the question is whether you have the time and inclination to do the latter yourself, if you want the transition done sooner rather than later, working with maintainers on a solution for each particular package (a solution that does not entail, preferably, dropping Musepack support from the application). For example, Rafael Laboissiere, the maintainer of libmtp, did exactly this for the recent libmtp7 - libmtp8 transition: he filed bugs, provided patches, and did a bunch of NMUs, which allowed us to do the transition in a timely manner. So, do we have a plan, or do we just opt for waiting? I’m Bcc'ing all of the involved bugs so that maintainers can send an update on the status of their bug (to the debian-release mailing list and *your* bug, please). If a fix exists, please send it to the BTS with an appropriate “patch” tag or, preferably, make an upload to experimental. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522764: petsc-dev: uninstallable on many arches
Package: petsc-dev Version: 3.0.0.dfsg-1 Severity: serious Hello, there is a problem with petsc-dev that is making all packages build-depending on it FTBFS on several architectures. petsc-dev is an arch:all package that depends on libpetsc3.0.0-dev. However, as you are undoubtedly aware, libpetsc3.0.0-dev is not available on all architectures, and in many of them only libpetsc3.0.0-lam-dev is. The libpetsc3.0.0-lam-dev package Provides: petsc3.0.0-dev, but this is not enough to make petsc-dev installable on those architectures, hence rendering reverse build-dependencies unbuildable. Please make libpetsc3.0.0-lam-dev Provide: libpetsc3.0.0-dev, or (preferable IMHO) make petsc-dev an arch:any package that Depends: on libpetsc3.0.0-dev or libpetsc3.0.0-lam-dev as appropriate. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521726: python-pymtp: needs upating of depends fromlibmtp7 to libmtp8
* Rafael Laboissiere [Tue, 31 Mar 2009 03:03:29 +0200]: The following seems to work for users of MTP devices so far (see the attachment to that bug): http://bugs.gpodder.org/show_bug.cgi?id=307 Thanks for the info. The changes to pymtp.py are different from those that I proposed before. I will test both versions eventually and will let you know. My version was not working properly, so forget about the previous patch. I merged both version for pymtp.py and the resulting debdiff is attached below. I tested it with a Zen Creative device and creation of a track from file worked using the modified sendtrack.py script in the package (notice that this script is patched to work with python-id3 instead of using the pyid3lib module, which does not seem to be available in Debian). I am Cc:ing this reply to the upstream author. Let us see what he thinks. Although it would need more tests, I would go ahead and upload this changed version of the package to unstable, otherwise the libmtp transiton will be blocked. Indeed python-pymtp is the last blocker for the transition (Cc:ing also to debian-release, accordingly). Indeed. I’d like to push this transition sooner rather than latter, so I’m considering a temporary removal of pymtp from testing, or maybe leaving libmtp7 around for a bit in testing, but I like that less. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521726: python-pymtp: needs upating of depends fromlibmtp7 to libmtp8
* Rafael Laboissiere [Thu, 02 Apr 2009 16:50:53 +0200]: * Thomas Perl t...@thpinfo.com [2009-04-02 14:37]: I am fine with you NMUing pymtp. I can test your modifications locally with an MTP device here before you upload, if you want (or tell me if the debdiff you posted above is already what you intend to upload). Please, test my changes. Yes, it is what I intend to upload. Notice that the debdiff contains the changes to the upstream files in the .diff.gz. file. It would be better to use quilt for that. Great, I’ll be waiting for the upload and then do the migration. Thomas, you accidentally dropped debian-release from the discussion; readding it now. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521767: inkscape_0.46-6 fails to build on alpha
* Wolfram Quester [Tue, 31 Mar 2009 21:15:23 +0200]: Hi Barry! On Mon, Mar 30, 2009 at 11:29:05AM -0400, Barry deFreese wrote: Hi, I forgot to CC the bug report initially. I have e-mailed the maintainer and will be happy to sponsor an upload. If he does not respond in a timely manner I will be NMUing with the proposed fix from Arthur. My plan is to prepare a new inkscape package and send it to my sponsor on friday, so he can upload over the weekend. I wanted to have a look at some more bugs in the package than only this one. If this is too long for you, then feell free to do the NMU. Having it by the end of the week would be great, thank you. Let’s do that. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522103: libsqlite3-0: ABI breakage: xCheckReservedLock method in sqlite3_io_methods changed prototype
Package: libsqlite3-0 Version: 3.6.11-4 Severity: serious The sqlite3_io_methods struct, which just contains pointers to different functions, changed in an incompatible way, by making one of these methods (xCheckReservedLock) accept two parameters instead of one. We had a long chat about this on #debian-release today, because evolution-data-server makes use of the VFS layer in sqlite3, and broke when compiled against 3.5 and run against 3.6 (see #519428). It is unclear to us what is SQLite’s compromises regarding this API, since it is true it’s a very low-level functionality, and possibly the SQLite authors are expecting for code using it to be compiled together with SQLite itself. But, alas, it gets exported via sqlite.h, so... We are going to rebuild evolution-data-server in unstable as to give a temporary fix to the issue. We don’t know if other applications are affected, and we should assess what permanent solution to give to this problem. We’ll get back to you on this; I’ve filed this bug for tracking purposes. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520328: caret: FTBFS: /usr/bin/ld: cannot find -lvtkRendering
* peter green [Thu, 19 Mar 2009 01:54:28 +]: reassign 520328 libvtk5-dev retitle 520328 libvtk5-dev should have a versioned dependency on libvtk5 If libvtk5-dev is 5.2.1 but libvtk is only 5.0.4 (as seemed to happen with all the buildd builds of caret 5.6.1~dfsg.1-3 http://packages.debian.org/source/unstable/caret) then a broken symlink results. Such a broken situation should not be allowed by package dependencies. release team: please requeue caret with a dep-wait on libvtk5 = 5.2.1 Done, sorry for the delay. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521726: python-pymtp: needs upating of depends from libmtp7 to libmtp8
Package: python-pymtp Version: 0.0.4-1 Severity: serious X-Debbugs-CC: Rafael Laboissiere raf...@debian.org pymtp hardcodes a dependency on libmtp7, which has been dropped in favour of libmtp8. Please take a look into uploading a package with an updated dependency, with source changes to adjust to the new library if needed. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521296: tp-smapi-source: FTBFSes with 2.6.29, something akin to VDIR used
* Evgeni Golov [Fri, 27 Mar 2009 14:11:01 +0100]: On Thu, 26 Mar 2009 15:26:55 +0100 Adeodato Simó wrote: tp-smapi-source does not build against linux-headers-2.6.29. The problem is that the Makefile checks for the presence of an include header, but if you check /usr/src/linux-headers-2.6.29-FLAVOUR against the 2.6.28 counterpart, you’ll see that all the symlinks towards ../*-common are missing, and the toplevel Makefile does some magic to forward build requests to the ‘-common’ directory. I suggest you consider dropping the check, since Debian stable already has a kernel 2.6.19, and I guess the build would fail anyway. You can find a new patched version in Git: http://git.debian.org/?p=users/sargentd-guest/tp-smapi.git;a=summary But that will still fail to build: # Build the module /usr/bin/make modules KSRC=/lib/modules/2.6.29-1-686/build KVER=2.6.29-1-686 HDAPS=1 make[2]: Entering directory `/usr/src/modules/tp-smapi' /usr/bin/make -C /lib/modules/2.6.29-1-686/build M=/usr/src/modules/tp-smapi O=/lib/modules/2.6.29-1-686/build modules make[3]: Entering directory `/usr/src/linux-headers-2.6.29-1-686' /usr/src/linux-headers-2.6.29-1-common/arch/x86/Makefile:41: /usr/src/linux-headers-2.6.29-1-common/arch/x86/Makefile_32.cpu: No such file or directory make[5]: *** No rule to make target `/usr/src/linux-headers-2.6.29-1-common/arch/x86/Makefile_32.cpu'. Stop. make[4]: *** [sub-make] Error 2 make[3]: *** [all] Error 2 And Makefile_32.cpu is really missing from the .29 headers (but present in the .26 ones) Ideas? No idea, I’m putting -kernel on CC. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521296: tp-smapi-source: FTBFSes with 2.6.29, something akin to VDIR used
Package: tp-smapi-source Version: 0.40-2 Severity: serious X-Debbugs-CC: debian-ker...@lists.debian.org Hello, tp-smapi-source does not build against linux-headers-2.6.29. The problem is that the Makefile checks for the presence of an include header, but if you check /usr/src/linux-headers-2.6.29-FLAVOUR against the 2.6.28 counterpart, you’ll see that all the symlinks towards ../*-common are missing, and the toplevel Makefile does some magic to forward build requests to the ‘-common’ directory. I suggest you consider dropping the check, since Debian stable already has a kernel 2.6.19, and I guess the build would fail anyway. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520646: #520646: binNMU oprofile
Hello, Looks like oprofile needs a rebuild . $ opreport opreport: error while loading shared libraries: libbfd-2.18.0.20080103.so: cannot open shared object file: No such file or directory $ dpkg -L binutils | grep libbfd- /usr/lib/libbfd-2.19.1.so I’m told libbfd.so is a private/internal library of binutils that should not be dynamically linked against. A static version exists (libbfd.a), and packages should be using that AFAIK. Cc'ing -devel in case there’s a reason it should not be that way. If, on the contrary, nobody objects, I’ll file a wishlist against lintian so that an error (warning?) is emitted for packages that DT_NEED that library (and libopcodes/libiberty as well?) Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510417: links2: silently accepts bad SSL certificates
* Neil Moore [Thu, 01 Jan 2009 11:57:35 -0500]: Package: links2 Version: 2.2-1 Severity: grave Tags: security Justification: user security hole Hello, Neil. I’m sorry I’m not mailing you to help solve this bug, since I’m not the maintainer of links2. I do release management in Debian, and I’m interested in knowing whether this bug affects 2.1pre37-1.1, which is currently in stable (and testing). Do you know if that is the case? Could you perhaps check? Thanks, Links2 does not validate certificates it receives; as a result, there is no warning that one is visiting a page with an expired certificate, a certificate not signed by a trusted authority, or a certificate for the wrong hostname. As a result, an attacker capable of intercepting one's packets can launch a man-in-the-middle attack to obtain account numbers, passwords, etc. At the very least, the documentation should prominently warn that links2's HTTPS support is not to be relied upon for sensitive information. This is the same issue reported in bug 510348 for the (unrelated) browser 'dillo'. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-openvz-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages links2 depends on: ii libc6 2.7-16GNU C Library: Shared libraries ii libdirectfb-1.0-0 1.0.1-11 direct frame buffer graphics - sha ii libgpm21.20.4-3.1General Purpose Mouse - shared lib ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libpng12-0 1.2.27-2 PNG library - runtime ii libssl0.9.80.9.8g-14 SSL shared libraries ii libsvga1 1:1.4.3-27console SVGA display libraries ii libtiff4 3.8.2-11 Tag Image File Format (TIFF) libra ii libx11-6 2:1.1.5-2 X11 client-side library ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime links2 recommends no packages. links2 suggests no packages. -- no debconf information -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519312: Removing dfb++ and fusionsound?
reassign 465403 ftp.debian.org reassign 465404 ftp.debian.org retitle 465404 RM: dfb++ -- RoQA; orphaned 1y+, no reverse deps, tiny popcon retitle 465403 RM: fusionsound -- RoQA; orphaned 1y+, no reverse deps, tiny popcon thanks --- Adeodato Simó [Mon, 16 Mar 2009 14:40:22 +0100]: Hello, dfb++ and fusionsound have been orphaned for more than a year now without nobody picking them up. They are both libraries, said to be part of the directfb suite. However, they’ve not been adopted by the DirectFB Maintainers, and additionally they have no reverse dependencies in Debian. Both are failing to build against directfb 1.2.0 (#519307, #519312). I’d like to hear the opinion of the DirectFB Maintainers about the relevance of these packages, and their willingness to adopt them. But since they have no reverse dependencies, maybe a plain removal is a better option? I’ll do that in a week unless somebody objects or an offer for maintenance is received. FWIW, I received [1] from the directfb maintainer, but it seems it never arrived to -qa despite being CC'ed there. [1]: http://lists.alioth.debian.org/pipermail/pkg-directfb-devel/2009-March/93.html Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519949: Please binNMU mp3gain in lenny because of gcc bug
* Stefan Fritsch [Mon, 23 Mar 2009 12:24:22 +0100]: Hi, I received bug #519949 about mp3gain 1.4.6-7 calculating wrong results on i386. This is probably due to my build chroot not being up-to-date and gcc 4.1 having bug #429657 at the time of the upload. I have checked one arch per gcc version used by the buildd's, and all work fine (and all buildds used gcc 4.2 already, which was not affected by #429657). Therefore, a binNMU on i386 should be enough. I have also uploaded 1.4.6-8 to unstable with urgency medium. If you’ve made a sourceful upload, I don’t think there’s a need for a Bin-NMU? -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519949: Please binNMU mp3gain in lenny because of gcc bug
* Adeodato Simó [Tue, 24 Mar 2009 23:50:41 +0100]: If you’ve made a sourceful upload, I don’t think there’s a need for a Bin-NMU? Sorry, I failed to notice “lenny” in the subject. It is normally better to make the body self-contained. ;-) Anyway, Bin-NMU in Lenny scheduled. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520642: gtk2-engines-udeb: depends on non-udeb packages on hppa, among other things
* Josselin Mouette [Sat, 21 Mar 2009 16:57:46 +0100]: Le samedi 21 mars 2009 à 15:34 +0100, Adeodato Simó a écrit : gtk2-engines-udeb exhibits two problems on hppa, though the second of them may be applicable to other arches as well. In the first place, gtk2-engines-udeb 2.14.3-2 and 2.16.1-2 depend on libdirectfb-1.0-0-udeb, but only on hppa. This dependency is, additionally, spurious: the files shipped in gtk2-engines-udeb are linked against libdirectfb-1.0, but do not use any of its symbols as far as I can see. The fact that this linkage is only present on hppa is probably symptomatic that something is going wrong there. This looks like a binutils bug on hppa to me. In both 2.16.1-2 and 2.16.1-2+b1, the engines end up with a NEEDED on directfb, while the link line is: cc -shared .libs/clearlooks_rc_style.o .libs/clearlooks_style.o .libs/clearlooks_theme_main.o .libs/support.o .libs/animation.o .libs/clearlooks_draw.o .libs/clearlooks_draw_glossy.o .libs/clearlooks_draw_inverted.o .libs/clearlooks_draw_gummy.o -Wl,--whole-archive ../../engines/support/.libs/libsupport.a -Wl,--no-whole-archive -Wl,--as-needed -lgtk-directfb-2.0 -lgdk-directfb-2.0 -ldirectfb -lfusion -ldirect -lpthread /usr/lib/libatk-1.0.so /usr/lib/libgdk_pixbuf-2.0.so -lm /usr/lib/libpangocairo-1.0.so /usr/lib/libgio-2.0.so /usr/lib/libpango-1.0.so /usr/lib/libcairo.so /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so /usr/lib/libglib-2.0.so -Wl,-z -Wl,defs -Wl,-O1 -Wl,-Bsymbolic -Wl,-soname -Wl,libclearlooks.so -o .libs/libclearlooks.so So this is a problem with --as-needed. Not a trivial one, since it works with a trivial test case – just checked on paer which has the same binutils version (2.19.1-1). Okay. Well, not a big deal I guess, just a spurious dependency. This dependency on directfb caused us to schedule a Bin-NMU of gtk2-engines on hppa in order to rebuild it against the new directfb. Which brings us to the second problem: the resulting gtk2-engines-udeb 2.16.1-2+b1 has completely fucked up dependencies! It depends on libcairo2, libglib2.0-0 and libgtk2.0-0 instead of their -udeb counterparts! The explanation is simple: these packages have fscked up shlibs files on hppa, without udeb lines. This is caused by #518706. dh_makeshlibs -plibgtk2.0-0 \ -Xusr/lib/gtk-2.0/2.10.0 \ -Vlibgtk2.0-0 (= 2.14.0) \ --add-udeb=libgtk-directfb-2.0-0-udeb Option add-udeb does not take an argument My take on it is: binNMU *in order* glib2.0, directfb, cairo, gtk+2.0 and gtk2-engines on hppa. Uhm, this is very problematic. Thanks for the heads up, Joss. Let’s work together with -boot now, because their input is going to be indispensable in order to ensure we completely fix the problem. There are two parts to the problem: (a) packages with buggy shlibs files, and (b) packages with buggy dependencies. (Some packages are in both groups.) Let’s take group (b) first; Joss, you can skip this part and go for group (a) below. So, for group (b), I tried to guess which packages need a rebuild. My lack of knowledge about d-i internals made me believe that all udebs should be depending on other udebs only, but this seems not to be the case. So I went for a list of udebs in unstable that depend on non-udebs, except those dependencies already in stable. The results are mostly in hppa, and mostly related to the directfb transition. So, on hppa: package| dependency -+--- cdebconf-gtk-udeb | libcairo2 | libdirectfb-1.2-0 | libglib2.0-0 | libgtk2.0-0 | libgtk-directfb-2.0-0 | cdebconf-gtk-entropy| libcairo2 | libdirectfb-1.2-0 | libglib2.0-0 | libgtk2.0-0 | libgtk-directfb-2.0-0 | cdebconf-gtk-terminal | libcairo2 | libdirectfb-1.2-0 | libglib2.0-0 | libgtk2.0-0 | libgtk-directfb-2.0-0 | gtk2-engines-udeb | libcairo2 | libdirectfb-1.2-0 | libglib2.0-0 | libgtk2.0-0 | libgtk-directfb-2.0-0 | libdirectfb-bin-udeb| libdirectfb-1.2-0 | libcairo-directfb2-udeb | libdirectfb-1.2-0 | libgtk-directfb-2.0-0-udeb | libcairo2 | libdirectfb-1.2-0 libsdl1.2debian-udeb| libdirectfb-1.2-0
Bug#496137: Package is (will be?) orphaned, and we wish to take over maintainership
Hello, Thomas. Thanks for your interest in adopting yum. Your plan sounds good. Since the former co-maintainer explicitly suggested handing it over to some interested party, and the main maintainer recently retired from Debian, I think you can go forward immediately with this adoption. Also, please note it would have sufficed to CC debian-qa. The debian-release list did not need to be in the loop for this. Cheers, * Thomas Goirand [Sat, 21 Mar 2009 02:27:35 +0800]: Hi, I hope that sending this as copy to debian...@lists.debian.org and debian-rele...@lists.debian.org is the way to go and that this is not disturbing some already busy lists. Forgive me if that is too much. It seems that the maintainer of the package has not been seen since 2005, and that the co-maintainer is not interested in the package anymore, as per: http://lists.debian.org/debian-release/2009/02/msg00413.html In this, he wrote: I was only working on it on behalf of OLPC. Since I'm no longer with them, I don't really have any interest in working on it. I would suggest giving it to someone who has a use for it. Barry deFreese told me on #debian-mentors that he will orphan it shortly. As the package is very important to us (we use it to bootstrap CentOS VMs from a Xen dom0 and resell it to our customers), we wish to take over maintainership. I am comfortable with Debian packaging, while my employee, Manuel Amador, is comfortable with python and RPM things. Together as a team, we will (hopefully) be able to maintain yum correctly in Debian. We have created a specific email address for communicating about the package, this forwards to rud...@rudd-o.com (Manuel Amador's address) and tho...@goirand.fr (myself): yumpack...@gplhost.com Please write to it for any concerns about the yum package in Debian. I'll feel an ITA as soon as I see that the package is orphaned. Last thing: we have prepared a new package with the latest version from upstream (as the current one was really not working well, with lot's of bad printing, and sometimes hanging for minutes doing nothing) in here: ftp://ftp.gplhost.com/debian/dists/lenny/main/source/yum_3.2.21-1~gplhost1.dsc Of course, we will change the version number, but as this is in our repository for the moment, the version above is ok. Anyway, we would need to close the ITA number, so we would need to update the package whatever happens. Thomas Goirand -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510845: mpi-defaults: FTBFS/not available on alpha
* Manuel Prinz [Tue, 17 Mar 2009 23:06:24 +0100]: Am Dienstag, den 17.03.2009, 18:32 +0100 schrieb Adeodato Simó: Okay; I think it’s reasonable to wait, as long as we make sure it gets addressed at some point. Maybe we should open a separate bug report for it? Feel free to do so if you like; usually, they're very responsive and I expect an answer before the weekend. If the SONAME is not changed but faked by a package name change, this is not mission-critical, is it? I meant a bug in the Debian BTS to track the fact that we need to do something about this issue at some point. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520457: pyode: needs to change Build-Dependency from libode0-dev to libode-dev
Package: pyode Version: 1.2.0-3 Severity: serious libode0-dev has been renamed to libode-dev in unstable. Please make an upload to update your build-depends. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520141: mpi-defaults: wrong arch constraints in Build-Depends
* Manuel Prinz [Wed, 18 Mar 2009 00:08:16 +0100]: Am Dienstag, den 17.03.2009, 23:21 +0100 schrieb Adeodato Simó: If, as you say, the sparc failure is expected to be fixed soon, I don’t understand if there would be any problem with uploading with the alpha/LAM change now, keeping sparc with openmpi. If you are concerned that mpi-defaults will fail to build on sparc, that should not be a concern: can get built when openmpi is built on sparc, but in the meantime it will give us mpi-default-dev on alpha. Or is something else to take into account that I overlooked? No, I just read your email as the upload was kind of urgent. If it is, I'd propose we go for alpha and sparc using LAM. If it's not, I can fix alpha and sparc in openmpi and upload mpi-defaults with alpha and sparc using Open MPI. I'd prefer this, though I do not know if it's reasonable since we could also go back to Open MPI with a later upload. What is your preferred option? Well, my preference would be to get a working mpi-defaults-dev in all architectures as soon as possible, but if you have grounds to believe openmi will be available on alpha and again on sparc soon, I don’t have any inconvenient to wait a few days. Let’s do that. Thanks, and sorry for all the hassle. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520113: mplayer: FTBFS: non-dynamic relocations refer to dynamic symbol free@@GLIBC_2.0
Package: mplayer Version: 1.0~rc2+svn20090303-2 Severity: serious User: debian-rele...@lists.debian.org Usertag: transition-blocker Hello, from: https://buildd.debian.org/fetch.cgi?pkg=mplayerarch=mipsver=1.0%7Erc2%2Bsvn20090303-2stamp=1237257849file=logas=raw | cc -o mplayer mplayer.o m_property.o mp_fifo.o mp_msg.o mixer.o parser-mpcmd.o command.o input/input.o libao2/audio_out.o libao2/ao_mpegpes.o libao2/ao_null.o libao2/ao_pcm.o libvo/aspect.o libvo/geometry.o libvo/spuenc.o libvo/video_out.o libvo/vo_mpegpes.o libvo/vo_null.o libvo/vo_3dfx.o libao2/ao_alsa.o libvo/vo_caca.o libvo/vo_dfbmga.o libvo/vo_dga.o libvo/vo_directfb2.o libao2/ao_esd.o libvo/vo_fbdev.o libvo/vo_fbdev2.o libvo/vo_gif89a.o libvo/gl_common.o libvo/vo_gl.o libvo/vo_gl2.o gui/bitmap.o gui/app.o gui/cfg.o gui/interface.o gui/mplayer/gui_common.o gui/mplayer/menu.o gui/mplayer/mw.o gui/mplayer/pb.o gui/mplayer/play.o gui/mplayer/sw.o gui/mplayer/widgets.o gui/mplayer/gtk/about.o gui/mplayer/gtk/eq.o gui/mplayer/gtk/fs.o gui/mplayer/gtk/gtk_common.o gui/mplayer/gtk/gtk_url.o gui/mplayer/gtk/mb.o gui/mplayer/gtk/menu.o gui/mplayer/gtk/opts.o gui/mplayer/gtk/pl.o gui/mplayer/gtk/sb.o gui/skin/cut.o gui/skin/font.o gui/skin/skin.o gui/wm/ws.o gui/wm/wsxdnd.o libao2/ao_jack.o libvo/vo_jpeg.o libmenu/menu.o libmenu/menu_chapsel.o libmenu/menu_cmdlist.o libmenu/menu_console.o libmenu/menu_filesel.o libmenu/menu_list.o libmenu/menu_param.o libmenu/menu_pt.o libmenu/menu_txt.o libmenu/vf_menu.o libmenu/menu_dvbin.o input/lirc.o libvo/vo_md5sum.o libvo/vo_mga.o libao2/ao_nas.o libao2/ao_openal.o libao2/ao_oss.o libvo/vo_png.o libvo/vo_pnm.o libao2/ao_pulse.o libao2/ao_sdl.o libvo/vo_sdl.o libvo/vo_tdfxfb.o libvo/vo_tga.o libvo/vo_v4l2.o libao2/ao_v4l2.o libvo/vo_x11.o libvo/vo_xover.o libvo/x11_common.o libvo/vo_xmga.o libvo/vo_xv.o libvo/vo_xvmc.o libvo/vo_yuv4mpeg.o asxparser.o codec-cfg.o cpudetect.o edl.o find_sub.o fmt-conversion.o get_path.o m_config.o m_option.o m_struct.o mpcommon.o parser-cfg.o playtree.o playtreeparser.o spudec.o sub_cc.o subopt-helper.o subreader.o vobsub.o libaf/af.o libaf/af_center.o libaf/af_channels.o libaf/af_comp.o libaf/af_delay.o libaf/af_dummy.o libaf/af_equalizer.o libaf/af_extrastereo.o libaf/af_format.o libaf/af_gate.o libaf/af_hrtf.o libaf/af_karaoke.o libaf/af_pan.o libaf/af_resample.o libaf/af_scaletempo.o libaf/af_sinesuppress.o libaf/af_stats.o libaf/af_sub.o libaf/af_surround.o libaf/af_sweep.o libaf/af_tools.o libaf/af_volnorm.o libaf/af_volume.o libaf/filter.o libaf/format.o libaf/reorder_ch.o libaf/window.o libmpcodecs/ad.o libmpcodecs/ad_alaw.o libmpcodecs/ad_dk3adpcm.o libmpcodecs/ad_dvdpcm.o libmpcodecs/ad_hwmpa.o libmpcodecs/ad_imaadpcm.o libmpcodecs/ad_msadpcm.o libmpcodecs/ad_msgsm.o libmpcodecs/ad_pcm.o libmpcodecs/dec_audio.o libmpcodecs/dec_video.o libmpcodecs/img_format.o libmpcodecs/mp_image.o libmpcodecs/native/nuppelvideo.o libmpcodecs/native/rtjpegn.o libmpcodecs/native/xa_gsm.o libmpcodecs/pullup.o libmpcodecs/vd.o libmpcodecs/vd_hmblck.o libmpcodecs/vd_lzo.o libmpcodecs/vd_mpegpes.o libmpcodecs/vd_mtga.o libmpcodecs/vd_null.o libmpcodecs/vd_nuv.o libmpcodecs/vd_raw.o libmpcodecs/vd_sgi.o libmpcodecs/vf.o libmpcodecs/vf_1bpp.o libmpcodecs/vf_2xsai.o libmpcodecs/vf_blackframe.o libmpcodecs/vf_boxblur.o libmpcodecs/vf_crop.o libmpcodecs/vf_cropdetect.o libmpcodecs/vf_decimate.o libmpcodecs/vf_delogo.o libmpcodecs/vf_denoise3d.o libmpcodecs/vf_detc.o libmpcodecs/vf_dint.o libmpcodecs/vf_divtc.o libmpcodecs/vf_down3dright.o libmpcodecs/vf_dsize.o libmpcodecs/vf_dvbscale.o libmpcodecs/vf_eq.o libmpcodecs/vf_eq2.o libmpcodecs/vf_expand.o libmpcodecs/vf_field.o libmpcodecs/vf_fil.o libmpcodecs/vf_filmdint.o libmpcodecs/vf_flip.o libmpcodecs/vf_format.o libmpcodecs/vf_framestep.o libmpcodecs/vf_halfpack.o libmpcodecs/vf_harddup.o libmpcodecs/vf_hqdn3d.o libmpcodecs/vf_hue.o libmpcodecs/vf_il.o libmpcodecs/vf_ilpack.o libmpcodecs/vf_ivtc.o libmpcodecs/vf_kerndeint.o libmpcodecs/vf_mirror.o libmpcodecs/vf_noformat.o libmpcodecs/vf_noise.o libmpcodecs/vf_ow.o libmpcodecs/vf_palette.o libmpcodecs/vf_perspective.o libmpcodecs/vf_phase.o libmpcodecs/vf_pp7.o libmpcodecs/vf_pullup.o libmpcodecs/vf_rectangle.o libmpcodecs/vf_remove_logo.o libmpcodecs/vf_rgb2bgr.o libmpcodecs/vf_rgbtest.o libmpcodecs/vf_rotate.o libmpcodecs/vf_sab.o libmpcodecs/vf_scale.o libmpcodecs/vf_smartblur.o libmpcodecs/vf_softpulldown.o libmpcodecs/vf_softskip.o libmpcodecs/vf_swapuv.o libmpcodecs/vf_telecine.o libmpcodecs/vf_test.o libmpcodecs/vf_tfields.o libmpcodecs/vf_tile.o libmpcodecs/vf_tinterlace.o libmpcodecs/vf_unsharp.o libmpcodecs/vf_vo.o libmpcodecs/vf_yadif.o libmpcodecs/vf_yuvcsp.o libmpcodecs/vf_yuy2.o libmpcodecs/vf_yvu9.o libmpdemux/aac_hdr.o libmpdemux/asfheader.o libmpdemux/aviheader.o libmpdemux/aviprint.o libmpdemux/demuxer.o libmpdemux/demux_aac.o libmpdemux/demux_asf.o libmpdemux/demux_audio.o libmpdemux/demux_avi.o
Bug#520133: linphone: spurious build-dependency on gnome-applets
Package: linphone Version: 3.0.0-2 Severity: serious Hello, linphone build-depends on gnome-applets, but this build-dependency (as confirmed with the GNOME maintainers) does not make any sense: with libpanel-applet2-dev (which is already in linphone’s build-dependency list) should be enough. This is particularly grave since linphone is now failing to build due to uninstallability of gnome-applets. It’d be great if you could do a quick upload doing the build-dependency. I’ve verified that linphone builds fine without gnome-applets installed. Please let me know if you need a NMU. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510845: mpi-defaults: FTBFS/not available on alpha
* Manuel Prinz [Mon, 16 Mar 2009 21:49:23 +0100]: Am Sonntag, den 15.03.2009, 16:14 +0100 schrieb Adeodato Simó: Indeed, bumping the SONAME in 1.3.1 would be great if indeed ABI compatibility has been broken. Thanks for pursuing this. Upstream discusses the plans for future releases and dealing with SONAMEs on their development list. We'll see where they end up, there is no definite plan yet. Okay; I think it’s reasonable to wait, as long as we make sure it gets addressed at some point. Maybe we should open a separate bug report for it? So, to get the issue fixed, my current plan is as follows: 1.) Fix the build issues. 2.) Fake the SONAME change by changing the library package name. [*] Ok. 3.) Patch and build all dependant software. 4.) File bugs for all packages, including patches. 5.) NMU if no response in a reasonable time frame. Uhm, what kind of patches are needed? Has the API changed as well between 1.2 and 1.3? I do not know if this plan is reasonable and the release-team is OK with it. I will of course let them know about this before I take any action. (Or is it OK to coordinate just with you?) Feedback is welcome and appreciated, since this is the first time I need to do that. It is better to coordinate with the debian-rele...@lists.d.o list, I’ll be reading that anyway. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520141: mpi-defaults: wrong arch constraints in Build-Depends
Package: mpi-defaults Version: 0.3 Severity: serious User: debian-rele...@lists.debian.org Usertags: transition-blocker Hello, let’s file this as a bug so that we have a place to track it. Sorry if you already had an upload ready! From #510845: | Manuel Prinz writes: | | As you may have noticed, I uploaded a fixed mpi-defaults earlier. I | discussed the alpha issue with Adam and we agreed on falling back to LAM | here. I did not know that sparc also fails then, so the fix will not | work; but because of sparc this time. | | I hadn’t noticed, thanks for telling me. There is an unfortunate problem | with it, though: you can’t use an architecture restriction like [arch1 | !arch2] in Build-Depends. That is, you can’t mix ! and non-!; if you | stop to think about it, it doesn’t make sense. | | Just removing “alpha” completely from the Build-Depends line will just | do the right thing as far as I can see. Could you make another upload? Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520113: mplayer: FTBFS: non-dynamic relocations refer to dynamic symbol free@@GLIBC_2.0
| cc -o mplayer mplayer.o m_property.o mp_fifo.o mp_msg.o mixer.o parser-mpcmd.o command.o input/input.o libao2/audio_out.o libao2/ao_mpegpes.o libao2/ao_null.o libao2/ao_pcm.o libvo/aspect.o libvo/geometry.o libvo/spuenc.o libvo/video_out.o libvo/vo_mpegpes.o libvo/vo_null.o libvo/vo_3dfx.o libao2/ao_alsa.o libvo/vo_caca.o libvo/vo_dfbmga.o libvo/vo_dga.o libvo/vo_directfb2.o libao2/ao_esd.o libvo/vo_fbdev.o libvo/vo_fbdev2.o libvo/vo_gif89a.o libvo/gl_common.o libvo/vo_gl.o libvo/vo_gl2.o gui/bitmap.o gui/app.o gui/cfg.o gui/interface.o gui/mplayer/gui_common.o gui/mplayer/menu.o gui/mplayer/mw.o gui/mplayer/pb.o gui/mplayer/play.o gui/mplayer/sw.o gui/mplayer/widgets.o gui/mplayer/gtk/about.o gui/mplayer/gtk/eq.o gui/mplayer/gtk/fs.o gui/mplayer/gtk/gtk_common.o gui/mplayer/gtk/gtk_url.o gui/mplayer/gtk/mb.o gui/mplayer/gtk/menu.o gui/mplayer/gtk/opts.o gui/mplayer/gtk/pl.o gui/mplayer/gtk/sb.o gui/skin/cut.o gui/skin/font.o gui/skin/skin.o gui/wm/ws.o gui/wm/wsxdnd.o libao2/ao_jack.o libvo/vo_jpeg.o libmenu/menu.o libmenu/menu_chapsel.o libmenu/menu_cmdlist.o libmenu/menu_console.o libmenu/menu_filesel.o libmenu/menu_list.o libmenu/menu_param.o libmenu/menu_pt.o libmenu/menu_txt.o libmenu/vf_menu.o libmenu/menu_dvbin.o input/lirc.o libvo/vo_md5sum.o libvo/vo_mga.o libao2/ao_nas.o libao2/ao_openal.o libao2/ao_oss.o libvo/vo_png.o libvo/vo_pnm.o libao2/ao_pulse.o libao2/ao_sdl.o libvo/vo_sdl.o libvo/vo_tdfxfb.o libvo/vo_tga.o libvo/vo_v4l2.o libao2/ao_v4l2.o libvo/vo_x11.o libvo/vo_xover.o libvo/x11_common.o libvo/vo_xmga.o libvo/vo_xv.o libvo/vo_xvmc.o libvo/vo_yuv4mpeg.o asxparser.o codec-cfg.o cpudetect.o edl.o find_sub.o fmt-conversion.o get_path.o m_config.o m_option.o m_struct.o mpcommon.o parser-cfg.o playtree.o playtreeparser.o spudec.o sub_cc.o subopt-helper.o subreader.o vobsub.o libaf/af.o libaf/af_center.o libaf/af_channels.o libaf/af_comp.o libaf/af_delay.o libaf/af_dummy.o libaf/af_equalizer.o libaf/af_extrastereo.o libaf/af_format.o libaf/af_gate.o libaf/af_hrtf.o libaf/af_karaoke.o libaf/af_pan.o libaf/af_resample.o libaf/af_scaletempo.o libaf/af_sinesuppress.o libaf/af_stats.o libaf/af_sub.o libaf/af_surround.o libaf/af_sweep.o libaf/af_tools.o libaf/af_volnorm.o libaf/af_volume.o libaf/filter.o libaf/format.o libaf/reorder_ch.o libaf/window.o libmpcodecs/ad.o libmpcodecs/ad_alaw.o libmpcodecs/ad_dk3adpcm.o libmpcodecs/ad_dvdpcm.o libmpcodecs/ad_hwmpa.o libmpcodecs/ad_imaadpcm.o libmpcodecs/ad_msadpcm.o libmpcodecs/ad_msgsm.o libmpcodecs/ad_pcm.o libmpcodecs/dec_audio.o libmpcodecs/dec_video.o libmpcodecs/img_format.o libmpcodecs/mp_image.o libmpcodecs/native/nuppelvideo.o libmpcodecs/native/rtjpegn.o libmpcodecs/native/xa_gsm.o libmpcodecs/pullup.o libmpcodecs/vd.o libmpcodecs/vd_hmblck.o libmpcodecs/vd_lzo.o libmpcodecs/vd_mpegpes.o libmpcodecs/vd_mtga.o libmpcodecs/vd_null.o libmpcodecs/vd_nuv.o libmpcodecs/vd_raw.o libmpcodecs/vd_sgi.o libmpcodecs/vf.o libmpcodecs/vf_1bpp.o libmpcodecs/vf_2xsai.o libmpcodecs/vf_blackframe.o libmpcodecs/vf_boxblur.o libmpcodecs/vf_crop.o libmpcodecs/vf_cropdetect.o libmpcodecs/vf_decimate.o libmpcodecs/vf_delogo.o libmpcodecs/vf_denoise3d.o libmpcodecs/vf_detc.o libmpcodecs/vf_dint.o libmpcodecs/vf_divtc.o libmpcodecs/vf_down3dright.o libmpcodecs/vf_dsize.o libmpcodecs/vf_dvbscale.o libmpcodecs/vf_eq.o libmpcodecs/vf_eq2.o libmpcodecs/vf_expand.o libmpcodecs/vf_field.o libmpcodecs/vf_fil.o libmpcodecs/vf_filmdint.o libmpcodecs/vf_flip.o libmpcodecs/vf_format.o libmpcodecs/vf_framestep.o libmpcodecs/vf_halfpack.o libmpcodecs/vf_harddup.o libmpcodecs/vf_hqdn3d.o libmpcodecs/vf_hue.o libmpcodecs/vf_il.o libmpcodecs/vf_ilpack.o libmpcodecs/vf_ivtc.o libmpcodecs/vf_kerndeint.o libmpcodecs/vf_mirror.o libmpcodecs/vf_noformat.o libmpcodecs/vf_noise.o libmpcodecs/vf_ow.o libmpcodecs/vf_palette.o libmpcodecs/vf_perspective.o libmpcodecs/vf_phase.o libmpcodecs/vf_pp7.o libmpcodecs/vf_pullup.o libmpcodecs/vf_rectangle.o libmpcodecs/vf_remove_logo.o libmpcodecs/vf_rgb2bgr.o libmpcodecs/vf_rgbtest.o libmpcodecs/vf_rotate.o libmpcodecs/vf_sab.o libmpcodecs/vf_scale.o libmpcodecs/vf_smartblur.o libmpcodecs/vf_softpulldown.o libmpcodecs/vf_softskip.o libmpcodecs/vf_swapuv.o libmpcodecs/vf_telecine.o libmpcodecs/vf_test.o libmpcodecs/vf_tfields.o libmpcodecs/vf_tile.o libmpcodecs/vf_tinterlace.o libmpcodecs/vf_unsharp.o libmpcodecs/vf_vo.o libmpcodecs/vf_yadif.o libmpcodecs/vf_yuvcsp.o libmpcodecs/vf_yuy2.o libmpcodecs/vf_yvu9.o libmpdemux/aac_hdr.o libmpdemux/asfheader.o libmpdemux/aviheader.o libmpdemux/aviprint.o libmpdemux/demuxer.o libmpdemux/demux_aac.o libmpdemux/demux_asf.o libmpdemux/demux_audio.o libmpdemux/demux_avi.o libmpdemux/demux_demuxers.o libmpdemux/demux_film.o libmpdemux/demux_fli.o libmpdemux/demux_lmlm4.o libmpdemux/demux_mf.o libmpdemux/demux_mkv.o libmpdemux/demux_mov.o libmpdemux/demux_mpg.o
Bug#520141: mpi-defaults: wrong arch constraints in Build-Depends
* Manuel Prinz [Tue, 17 Mar 2009 23:15:03 +0100]: Hi Adeodato! Hey, I fixed it in the Git repository already but did not upload, as Open MPI currently is not building at the moment. I hope to have a patch soon. If you think it's preferable to upload with sparc using LAM, I can do so. I do not really mind. If, as you say, the sparc failure is expected to be fixed soon, I don’t understand if there would be any problem with uploading with the alpha/LAM change now, keeping sparc with openmpi. If you are concerned that mpi-defaults will fail to build on sparc, that should not be a concern: can get built when openmpi is built on sparc, but in the meantime it will give us mpi-default-dev on alpha. Or is something else to take into account that I overlooked? Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520113: mplayer: FTBFS: non-dynamic relocations refer to dynamic symbol free@@GLIBC_2.0
* A Mennucc [Tue, 17 Mar 2009 22:36:19 +0100]: I am puzzled... how come that this happens only on MIPS? I don’t know, really. Aurelien Jarno offered his assitance to try to reproduce the problem, though he’s busy and may take a bit until he gets around to it. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519312: Removing dfb++ and fusionsound?
Hello, dfb++ and fusionsound have been orphaned for more than a year now without nobody picking them up. They are both libraries, said to be part of the directfb suite. However, they’ve not been adopted by the DirectFB Maintainers, and additionally they have no reverse dependencies in Debian. Both are failing to build against directfb 1.2.0 (#519307, #519312). I’d like to hear the opinion of the DirectFB Maintainers about the relevance of these packages, and their willingness to adopt them. But since they have no reverse dependencies, maybe a plain removal is a better option? I’ll do that in a week unless somebody objects or an offer for maintenance is received. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519711: splashy: hard-coded dependency on libdirectfb-1.0-0
This is a bit complicated. We will work on it. I’m curious. Why is it complicated? Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519595: gnome-phone-manager: FTBFS: No package 'libglade-2.0' found
user debian-rele...@lists.debian.org usertags 519595 + transition-blocker thanks Hello, Francesco. It seems you're missing a build dependency on atleast libglade2-dev, and it looks like you don't have build depedencies for some of the other the source package requires. This bug is very easy to fix (I’ve verified myself that adding a build-dependency on libglade2-dev fixes the problem), so it’d be great if you could make an upload soon. Feel free to merge your changes from 0.60-2 from experimental, but note that you will have to build-depend on libgnokii-dev instead of libgnokii4-dev. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519595: gnome-phone-manager: FTBFS: No package 'libglade-2.0' found
Hi Adeodato, I'm sorry if this bug is blocking something, I've already fixed the problem, I'm only waiting a review and the upload from my sponsor... Ah, perfect! It’s not very urgent, I just wanted to know it was progressing at some pace. And it’s better that it gets registered in the bug report, as to not duplicate efforts from you and eg. prospective NMUers. (It is good practice to always mention you have package ready in the bug log for RC bugs.) Thanks for your quick fix, please let me know if after a week you still need sponsoring. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519711: splashy: hard-coded dependency on libdirectfb-1.0-0
* Luis Mondesi [Mon, 16 Mar 2009 09:56:22 -0400]: Splashy has not been tested against newer version of libdirectfb. I know for sure that libdirectfb 1.2 makes it segfault. We will need to work on the transition anyway. I just have not have time lately to work on this. Maybe this summer. Okay. We’ll probably need to remove splashy from testing in the meantime. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518633: inkscape: FTBFS: error: 'GtkCList' does not name a type
* Wolfram Quester [Sat, 14 Mar 2009 21:48:10 +0100]: Hi Adeodato, Hello! Could that upload happen rather sooner than later? It’s a prerequisite for the poppler transition, so I’d be nice to get it uploading during the next days. Ah, my timeframe would be in the next two weeks. For the poppler transition I'd have to change the dependencies, is that right? You don’t need to change anything explicitly. Just by rebuilding the package, it will use already the new poppler libraries. In case I get a package ready in a few days, would you sponsor the upload? Please prepare a package and send a link to me CC’ing this bug report. I will upload it, or find somebody to upload it. If there are no big changes other than the fix for this FTBFS, that’d be appreciated. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510845: mpi-defaults: FTBFS/not available on alpha
* Manuel Prinz [Sat, 14 Mar 2009 22:31:45 +0100]: Hi Adeodato! Hello! Am Freitag, den 13.03.2009, 21:41 +0100 schrieb Adeodato Simó: Open MPI used to build fine on alpha, so this is probably a problem with the new upstream release. Reassigning to Open MPI maintainers. It’s been 2 months, and this issue has not been addressed. In the meantime, I’m starting to smell packages build-depending on mpi-default-dev that will prevent transitions from happening. Yes, I know about that. As a result of the recent breakage, Dirk left the team since he does a lot of stuff in Debian already, so the team is actually me. I had not much time lately but took this weekend of and am working on the problems this very moment. I'm sorry that it took so long. Okay, no worries. We all get busy, it’s just appropriate that the task gets done at some point. :-) You were right in reassigning, since openmpi should have a bug of its own for this failure. However, mpi-defaults is buggy as well, because it’s failing to provide packages for alpha. I also see #517543 now. IMO, either that patch is correct and can be applied soon, or mpi-defaults needs to start thinking about using an alternative implementation on alpha. Thoughts? I'm trying the patch but it does not fix the issue completely, as it seems. I hope I can give an update in a few hours. Once this is fixed, the build issue on Sparc can be probably fixed in a similar way. But I have to investigate that on a porter machine since I do not own this arch. (Well, same for alpha, but DSA kindly installed everything needed on albeniz.) Good, thanks! As you may have noticed, I uploaded a fixed mpi-defaults earlier. I discussed the alpha issue with Adam and we agreed on falling back to LAM here. I did not know that sparc also fails then, so the fix will not work; but because of sparc this time. I hadn’t noticed, thanks for telling me. There is an unfortunate problem with it, though: you can’t use an architecture restriction like [arch1 !arch2] in Build-Depends. That is, you can’t mix ! and non-!; if you stop to think about it, it doesn’t make sense. Just removing “alpha” completely from the Build-Depends line will just do the right thing as far as I can see. Could you make another upload? As for Open MPI, there are more than just build issues. I will fix these first, but there is also the problem of an ABI change. The upload was done a little hasty and the change not recognized, so the build-depending packages are effected. Most of them (if not all) will still run, but with a warning. The obviously needs to be fixed. Dirk came up with the idea of binNMUing but that that was not very welcomed by the maintainers of build-depending packages. I do not know what the right approach is. Upstream is now aware of that and will be ABI compatible starting from 1.3.2. I wanted to change the library package name and maybe bump the SONAME, and upload that package to experimantal. Of course, I wanted to mail the release team to coordinate that, but I wanted to fix one issue at a time. I have not made my mind up what is the best solution yet; just recompiling dependant packages would do the trick; users of Open MPI are used to recompile their software anyway, since upstream clearly stated that they never cared about ABI changes between releases. Any input is welcome. But I'll first try to get the package build again, collecting the broken pieces is second on my list. Hm. Well, a warning is one thing, and the applications not working is another. libopenmpi1 is in lenny, with packages depending on it. Partial upgrades ought to work, so if applications stop working, seems like a SONAME bump is in order. If it’s only a warning, it can be fixed with Bin-NMUs, but it should be assessed with care. I guess that when you say, “Upstream [...] will be ABI compatible starting from 1.3.2”, you mean that they don’t intend to bump the SONAME themselves for the breakage introduced earlier? That’d be a good start if you want to show you care about ABI compatibility... Finally, what’s this business about maintainers not being happy about Bin-NMUs of their packages? Thanks for caring! And sorry for the f***-up! As said above, no worries. Thanks for your work, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510845: mpi-defaults: FTBFS/not available on alpha
* Manuel Prinz [Sun, 15 Mar 2009 15:47:26 +0100]: Am Sonntag, den 15.03.2009, 12:23 +0100 schrieb Adeodato Simó: There is an unfortunate problem with it, though: you can’t use an architecture restriction like [arch1 !arch2] in Build-Depends. That is, you can’t mix ! and non-!; if you stop to think about it, it doesn’t make sense. Just removing “alpha” completely from the Build-Depends line will just do the right thing as far as I can see. Could you make another upload? Should have noticed myself, rookie mistake! Sure, will upload again. Thanks for spotting this! Great, thank you. Hm. Well, a warning is one thing, and the applications not working is another. libopenmpi1 is in lenny, with packages depending on it. Partial upgrades ought to work, so if applications stop working, seems like a SONAME bump is in order. If it’s only a warning, it can be fixed with Bin-NMUs, but it should be assessed with care. As for Lenny, we're good. Lenny has a 1.2 series version, which is fine with all software depending on it as of now. The breakage is only in the 1.3 series which is in Sid. The problem is that 1.2 in Lenny and 1.3 in unstable share the same SONAME/package name, libopenmpi1, so it is expected that applications in Lenny will be able to work against any version of libopenmpi1 (provided that its dependencies are met, of course). I guess that when you say, “Upstream [...] will be ABI compatible starting from 1.3.2”, you mean that they don’t intend to bump the SONAME themselves for the breakage introduced earlier? That’d be a good start if you want to show you care about ABI compatibility... I'm in contact with upstrean about that. The current situation is that 1.3 has the same SONAME as 1.2, though it should have been bumped. I'll hope they'll bump the SONAME in 1.3.1 but that is not settled yet, as I understand. I generally think that uploading 1.3.1 would be desireable since it includes quite a few fixes and would make most of our current patches obsolete, but they have no idea of a release date yet, so I'll try to fix 1.3 for now. Indeed, bumping the SONAME in 1.3.1 would be great if indeed ABI compatibility has been broken. Thanks for pursuing this. Finally, what’s this business about maintainers not being happy about Bin-NMUs of their packages? Not sure if this was rethorical question or if you'd like to have more information on that. No, it was not rethoric. You said the idea of Bin-NMUing was not welcome by the maintainers of reverse build-dependencies, and I’m curious as to why. It’s one thing if it was because they didn’t think it was an appropriate solution; but maintainers should never mind their packages getting rebuilt if that’s actually the correct solution. I was just wondering which was the case. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518633: inkscape: FTBFS: error: 'GtkCList' does not name a type
user debian-rele...@lists.debian.org usertags 518633 + transition-blocker thanks Hey Wolfram, Hi, the bug you reported is also known upstream under the link given above. There is a patch already, which I'll include in the next upload. Could that upload happen rather sooner than later? It’s a prerequisite for the poppler transition, so I’d be nice to get it uploading during the next days. Thanks! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516240: brltty: diff for NMU version 3.10~r3724-1.1
Hi,
Attached is the diff for my brltty 3.10~r3724-1.1 NMU.
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
diff -u brltty-3.10~r3724/debian/changelog brltty-3.10~r3724/debian/changelog
--- brltty-3.10~r3724/debian/changelog
+++ brltty-3.10~r3724/debian/changelog
@@ -1,3 +1,11 @@
+brltty (3.10~r3724-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Apply patch from Samuel Thibault to fix FTBFS in unstable.
+(Closes: #516240)
+
+ -- Adeodato Simó d...@net.com.org.es Sat, 14 Mar 2009 11:09:53 +0100
+
brltty (3.10~r3724-1) unstable; urgency=low
* New subversion snapshot, fixing FTBFS (Closes: Bug#482205).
only in patch2:
unchanged:
--- brltty-3.10~r3724.orig/configure.ac
+++ brltty-3.10~r3724/configure.ac
@@ -688,7 +688,7 @@
case ${host_os}
in
linux*|gnu*|kfreebsd*)
- brltty_cv_prog_cc_sysflags=-D_POSIX_C_SOURCE=2 -D_BSD_SOURCE -D_XOPEN_SOURCE=500 -D_XOPEN_SOURCE_EXTENDED
+ brltty_cv_prog_cc_sysflags=-D_POSIX_C_SOURCE=2 -D_BSD_SOURCE -D_XOPEN_SOURCE=500 -D_XOPEN_SOURCE_EXTENDED -D_GNU_SOURCE
;;
solaris*)
brltty_cv_prog_cc_sysflags=-D_XOPEN_SOURCE=500 -D__EXTENSIONS__
only in patch2:
unchanged:
--- brltty-3.10~r3724.orig/configure
+++ brltty-3.10~r3724/configure
@@ -14856,7 +14856,7 @@
case ${host_os}
in
linux*|gnu*|kfreebsd*)
- brltty_cv_prog_cc_sysflags=-D_POSIX_C_SOURCE=2 -D_BSD_SOURCE -D_XOPEN_SOURCE=500 -D_XOPEN_SOURCE_EXTENDED
+ brltty_cv_prog_cc_sysflags=-D_POSIX_C_SOURCE=2 -D_BSD_SOURCE -D_XOPEN_SOURCE=500 -D_XOPEN_SOURCE_EXTENDED -D_GNU_SOURCE
;;
solaris*)
brltty_cv_prog_cc_sysflags=-D_XOPEN_SOURCE=500 -D__EXTENSIONS__
Bug#519711: splashy: hard-coded dependency on libdirectfb-1.0-0
Package: splashy Version: 0.3.13-3 Severity: serious I guess it’s time to drop the hard coded dependency on libdirectfb-1.0-0. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510845: mpi-defaults: FTBFS/not available on alpha
* Manuel Prinz [Mon, 05 Jan 2009 12:48:10 +0100]: reassign 510845 openmpi 1.2.8-3 thanks Hello, Manuel. Am Montag, den 05.01.2009, 12:05 +0100 schrieb Adeodato Simó: Package: mpi-defaults Version: 0.2 Severity: serious The latest version of openmpi failed to build from source on alpha, hence mpi-defaults can't be built there, because libopenmpi-dev is not installabe. If mpi-defaults intends to provide packages for other packages to build-depend on, it should do that robustly. If you think the alpha FTBFS of openmpi can be fixed soon, please reassign this bug there and ask for a retry of mpi-defaults once it's available. Open MPI used to build fine on alpha, so this is probably a problem with the new upstream release. Reassigning to Open MPI maintainers. It’s been 2 months, and this issue has not been addressed. In the meantime, I’m starting to smell packages build-depending on mpi-default-dev that will prevent transitions from happening. You were right in reassigning, since openmpi should have a bug of its own for this failure. However, mpi-defaults is buggy as well, because it’s failing to provide packages for alpha. I also see #517543 now. IMO, either that patch is correct and can be applied soon, or mpi-defaults needs to start thinking about using an alternative implementation on alpha. Thoughts? Additionally, Manuel, what can you tell us about the openmpi FTBFS on sparc [1]? That’s sort of important too, because the way openmpi is packaged has rendered the old libopenmpi-dev uninstallable on sparc. Many thanks in advance, [1]: https://buildd.debian.org/fetch.cgi?pkg=openmpiarch=sparcver=1.3-2stamp=1236974238file=logas=raw -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517749: kino: diff for NMU version 1.3.0-2.2
Hi,
Attached is the diff for my kino 1.3.0-2.2 NMU.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
When all is summed up, a man never speaks of himself without loss; his
accusations of himself are always believed; his praises never.
-- Michel de Montaigne
diff -u kino-1.3.0/debian/changelog kino-1.3.0/debian/changelog
--- kino-1.3.0/debian/changelog
+++ kino-1.3.0/debian/changelog
@@ -1,3 +1,11 @@
+kino (1.3.0-2.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Ajust src/frame.h for the new location of ffmpeg includes.
+(Closes: #517749)
+
+ -- Adeodato Simó d...@net.com.org.es Tue, 10 Mar 2009 12:23:47 +
+
kino (1.3.0-2.1) unstable; urgency=low
* Removed myself from Uploaders, which makes this a non-maintainer upload.
diff -u kino-1.3.0/debian/patches/00list kino-1.3.0/debian/patches/00list
--- kino-1.3.0/debian/patches/00list
+++ kino-1.3.0/debian/patches/00list
@@ -1,2 +1,3 @@
10_playlist_algorithm
+20_fix_FTBFS_with_new_ffmpeg
80_move_doc
only in patch2:
unchanged:
--- kino-1.3.0.orig/debian/patches/20_fix_FTBFS_with_new_ffmpeg.dpatch
+++ kino-1.3.0/debian/patches/20_fix_FTBFS_with_new_ffmpeg.dpatch
@@ -0,0 +1,23 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## 20_fix_FTBFS_with_new_ffmpeg.dpatch by Adeodato Simó
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: Fix source for new location of ffmpeg includes.
+
+...@dpatch@
+--- a/src/frame.h
b/src/frame.h
+@@ -48,10 +48,10 @@
+ #if defined(HAVE_LIBAVCODEC)
+ extern C
+ {
+-# include avcodec.h
+-# include avformat.h
++# include libavcodec/avcodec.h
++# include libavformat/avformat.h
+ #ifdef HAVE_SWSCALE
+-# include swscale.h
++# include libswscale/swscale.h
+ #endif
+ }
+ #endif
Bug#519099: pyicu: FTBFS: needs adjustments for new handling of platforms in python
Package: pyicu Version: 0.8.1-2 Severity: serious https://buildd.debian.org/fetch.cgi?pkg=pyicuarch=alphaver=0.8.1-2%2Bb2stamp=1236650453file=logas=raw https://buildd.debian.org/fetch.cgi?pkg=pyicuarch=mipsver=0.8.1-2%2Bb2stamp=1236658490file=logas=raw http://packages.qa.debian.org/p/python2.5/news/20080929T010206Z.html Thanks, and apologies for being terse. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org «Ara que ets la meva dona, te la fotré fins a la melsa, bacona!» -- Terenci Moix, “Chulas y famosas” -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517464: xmms2: diff for NMU version 0.5DrLecter-2.1
Hi,
Attached is the diff for my xmms2 0.5DrLecter-2.1 NMU.
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
diff -u xmms2-0.5DrLecter/debian/changelog xmms2-0.5DrLecter/debian/changelog
--- xmms2-0.5DrLecter/debian/changelog
+++ xmms2-0.5DrLecter/debian/changelog
@@ -1,3 +1,11 @@
+xmms2 (0.5DrLecter-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS due to missing includes and changed location of ffmpeg headers.
+Patch by peter green and Cyril Brulebois. (Closes: #517464)
+
+ -- Adeodato Simó d...@net.com.org.es Tue, 10 Mar 2009 15:02:58 +
+
xmms2 (0.5DrLecter-2) unstable; urgency=medium
* Make wma playback work with the latest libavcodec.
diff -u xmms2-0.5DrLecter/src/plugins/avcodec/avcodec.c xmms2-0.5DrLecter/src/plugins/avcodec/avcodec.c
--- xmms2-0.5DrLecter/src/plugins/avcodec/avcodec.c
+++ xmms2-0.5DrLecter/src/plugins/avcodec/avcodec.c
@@ -24,7 +24,7 @@
#include glib.h
#undef ABS
-#include avcodec.h
+#include libavcodec/avcodec.h
#define AVCODEC_BUFFER_SIZE 16384
@@ -173,7 +173,7 @@
data-codecctx-sample_rate = data-samplerate;
data-codecctx-channels = data-channels;
data-codecctx-bit_rate = data-bitrate;
- data-codecctx-bits_per_sample = data-samplebits;
+ data-codecctx-bits_per_coded_sample = data-samplebits;
data-codecctx-block_align = data-block_align;
data-codecctx-extradata = data-extradata;
data-codecctx-extradata_size = data-extradata_size;
only in patch2:
unchanged:
--- xmms2-0.5DrLecter.orig/src/include/xmmsclient/xmmsclient++/helpers.h
+++ xmms2-0.5DrLecter/src/include/xmmsclient/xmmsclient++/helpers.h
@@ -32,6 +32,7 @@
#include string
#include list
#include vector
+#include climits
namespace Xmms
{
Bug#518673: libidn_1.12-2(hppa/experimental): FTBFS: java not available on hppa
* Simon Josefsson [Mon, 09 Mar 2009 10:39:48 +0100]: Hi. Thanks for the report. This patch may help: -Build-Depends: debhelper (= 6), autotools-dev, gcj, fastjar +Build-Depends: debhelper (= 6), autotools-dev, gcj [!alpha !arm !hppa !hurd-i386 !sh3 !sh4], fastjar Yes, that patch should help. In the common case, Build-Depending on gcj will just prevent the package from being tried on arches that do not have java/gcj. But TTBOMK the experimental autobuilders don't include the patch that manages to do that, hence it was tried. AFAICS, libidn provides other binaries than java package, so you really need to apply your patch above. Otherwise, those other parts won't be built on arches without java (and would be eternally out-of-date). The libidn11-java package is Architecture: all, so the libidn11-java package built on hppa will never be installed in the archive, right? If you creates -java packages that are arch:any, in addition to debian/control, you must modify your debian/rules to handle gracefully being built on a system without gcj. The result should be that the libidn11-java is not built at all; you can do that with the -N switch of debhelper. You should be able to find example code. However, if the java package is arch:all, no modification is strictly required. However, if you want to be pedantic, you should ensure binary-indep fails if the package is built on a system without gcj. I'm not sure how to test whether the above patch is enough, other than to upload a new package. Rebuilding the package on my i386 machine will likely just work fine. Ideas? I suggest that you do the following test. Apply the following version of the patch in a test package: - Build-Depends: debhelper (= 6), autotools-dev, gcj, fastjar + Build-Depends: debhelper (= 6), autotools-dev, xxx [!i386], fastjar And then build your package on pbuilder passing -B. That should simulate what the hppa buildd is going to do. Do you see it? Anibal, what do you think? https://buildd.debian.org/quinn-diff/Packages-arch-specific Maybe list libidn11-java in Packages-arch-specific to only exclude hppa? P-a-s would be relevant here if libidn11-java was arch:any, and only because libidn provides some non-java packages. Maybe a better solution is to Build-Depend on 'default-jdk' rather than depending on 'gcj' explicitly? I believe the libidn java port should build with any compliant java compiler. I have no idea about this, and you should ask debian-java. But I'll note that there is no default-jdk on hppa either. I hope this mail cleared things for you. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Victoria Abril - Le jazz et la java -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#487641: GNUstep libraries soname bump
* Hubert Chathi [Mon, 02 Mar 2009 22:49:09 -0500]: Hola, Hubert. Please read all of this mail carefully until the end. As it is shortly after a stable release, it seems to be a popular time now to break packages, and the GNUstep team wants in on the action. The new GNUstep core packages bump the soname, which means that all GNUstep packages need to be rebuilt. They should all be able to be handled by binNMUs. Is there anything that we should be aware of and/or wait for before uploading the new packages? (I know that it will be block by the libraw1394 transition because one of the build-depends tries to pull in that package.) Or can we go ahead with the transition? P.S. The GNUstep packages can be downloaded from: http://debian.uhoreg.ca/experimental/gnustep/ Okay, let's see. From that URL, I get that the set of disappeared binaries (which is what matters to us) is: gnustep-back0.14 gnustep-back0.14-art gnustep-back0.14-cairo libgnustep-gui0.14 libgnustep-base1.16 libgnustep-base1.16-libffi Please correct me if I've left anything out, it is very important for transition planning. This transition is tied to the ffmpeg-debian transition via lynkeos.app. I think it's a pity you can't start working on an otherwise very isolated transition because of that, but at the same time I don't want to make ffmpeg wait on GNUstep. So, what I'm going to propose, is that you go forward with this transition, but only once lynkeos.app has been rebuilt against the new ffmpeg in all architectures. At the moment, it is failing everywhere because of #487641. Once a fix for #487641 is in unstable, and built in all architectures, you may go forward with this transition. However, when scheduling Bin-NMUs, I will skip lynkeos.app until the ffmpeg transition is done (as to not tie them together). However, and as to not leave lynkeos.app broken in unstable too long, if the ffmpeg transition looks far from ready when scheduling GNUstep Bin-NMUs, I will not skip it, and solve it some other way. Does this sound acceptable to you? Please do not upload new GNUstep components to unstable until we've cleared up together that lynkeos.app is fixed everywhere. Uploading to experimental is fine, of course, and that will allow you clearing NEW while lynkeos.app sorts itself out. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Hay quien sueña con la alquimia que haga del vicio virtud -- Luis Eduardo Aute, Giraluna -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#487641: GNUstep libraries soname bump
* Yavor Doganov [Sun, 08 Mar 2009 16:34:09 +0200]: Adeodato Simó wrote: This transition is tied to the ffmpeg-debian transition via lynkeos.app. I think it's a pity you can't start working on an otherwise very isolated transition because of that, I have a fixed package ready, but would like to do more testing. I'll send a plea for sponsorship to -mentors tomorrow or latest on Tuesday. Ah, great to hear, thanks. (BTW, the GNUstep transition is also tied to the libpoppler3-libpoppler4 transition via popplerkit.framework.) No, it is not, at least not as far as my SQL-fu can see. libpopplerkit0 does not depend in any of the renamed libraries in the GNUstep transition, so it's free to migrate at will. Or do you know more about this than the Packages.gz files do? :-) Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org - I love you, Shirley, I'm not ashamed to say. - If you love me, then you'll want me to be happy. Even if I'm not with you. - I don't love you that much. -- Denny Crane and Shirley Schmidt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#487641: [Debian GNUstep maintainers] GNUstep libraries soname bump
* Yavor Doganov [Sun, 08 Mar 2009 18:13:47 +0200]: Adeodato Simó wrote: (BTW, the GNUstep transition is also tied to the libpoppler3-libpoppler4 transition via popplerkit.framework.) No, it is not, at least not as far as my SQL-fu can see. libpopplerkit0 does not depend in any of the renamed libraries in the GNUstep transition, so it's free to migrate at will. You are right that it doesn't depend on the GNUstep core libraries, but it should. See http://lists.debian.org/debian-release/2008/07/msg00068.html for some explanation. (Yes, these are bugs, IMVHO RC as per Policy 8.6.) Or do you know more about this than the Packages.gz files do? :-) The other packages in this situation are gnustep-netclasses and pantomime1.2. If they don't get rebuilt, their reverse dependencies (gnumail.app, lusernet.app, talksoup.app, viewpdf.app, etc.) will fail miserably. Ah, I see, thanks for the pointer, unfortunately I couldn't follow very close the GNUstep transition in Lenny. So, now my question is: what happens if you rebuild those three packages against the new GNUstep libraries, and they migrate to testing on their own, before said base libraries and the rest of the migrated packages? Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Truth is the most valuable thing we have, so let's economize it. -- Mark Twain -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#487641: [Debian GNUstep maintainers] GNUstep libraries soname bump
* Yavor Doganov [Sun, 08 Mar 2009 19:23:28 +0200]: Adeodato Simó wrote: So, now my question is: what happens if you rebuild those three packages against the new GNUstep libraries, and they migrate to testing on their own, before said base libraries and the rest of the migrated packages? This has happened before (i.e. they almost always migrate first on their own because there is a bug or two in the rest of the GNUstep packages that we discover during the transition). It depends. If the new GNUstep libraries are compatible [1], everything is working properly. If they are not, some packages are temporarily broken in testing until the rest of the GNUstep stack migrates. Okay. So, two things. First, that I'm sure you're aware that's a serious bug that ought to be fixed. I don't want to put pressure on you, since I realize the potential for breakage is slow. But it'd be nice to solve it some time. Isn't just linking to the GNUstep libraries as a Debian patch an option? [Insert here sentence about how I'm obsessed with XKCD #276.] Second, the above means we have to either to skip poppler.framework from the initial set of Bin-NMUs, but that's messy since other packages depend on it; or to allow it to migrate to testing and possibly break GNUstep in testing; or to temporarily break it in testing, and rebuild it against the new poppler there; or to reconsider whether GNUstep should wait that the poppler transition finishes, but I don't want to do that. Could you check if a popplerkit.framework rebuilt against the new libraries breaks when used against the current set of packages in testing and unstable? Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517148: potamus: diff for NMU version 0.9-1.1
tags 517148 + patch thanks Hi, Attached is the diff for my potamus 0.9-1.1 NMU. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Alanis Morissette - Versions Of Violence diff -u potamus-0.9/debian/control potamus-0.9/debian/control --- potamus-0.9/debian/control +++ potamus-0.9/debian/control @@ -2,7 +2,7 @@ Section: gnome Priority: optional Maintainer: Anibal Avelar (Fixxxer) aave...@cofradia.org -Build-Depends: debhelper (= 5), libbio2jack0-dev, libglib2.0-dev, libgtk2.0-dev,libglade2-dev, libsamplerate0-dev, libvorbisfile3, libmad0-dev, libao-dev, libmodplug-dev, libavcodec-dev, libavformat-dev, libaudiofile-dev, libflac-dev +Build-Depends: debhelper (= 5), libbio2jack0-dev, libglib2.0-dev, libgtk2.0-dev,libglade2-dev, libsamplerate0-dev, libvorbis-dev, libmad0-dev, libao-dev, libmodplug-dev, libavcodec-dev, libavformat-dev, libaudiofile-dev, libflac-dev Homepage: http://offog.org/code/potamus.html Standards-Version: 3.7.3 diff -u potamus-0.9/debian/changelog potamus-0.9/debian/changelog --- potamus-0.9/debian/changelog +++ potamus-0.9/debian/changelog @@ -1,3 +1,13 @@ +potamus (0.9-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Change build-dependency on libvorbisfile3 into libvorbis-dev, to fix +FTBFS. (Closes: #517148) + * Additionally, fix libavcodec and libavformat includes to their new +location. + + -- Adeodato Simó d...@net.com.org.es Sat, 07 Mar 2009 11:19:44 +0100 + potamus (0.9-1) unstable; urgency=low * First upload to Debian (Closes: #454384) only in patch2: unchanged: --- potamus-0.9.orig/src/input-avcodec.c +++ potamus-0.9/src/input-avcodec.c @@ -19,8 +19,8 @@ #include glib.h #include stdlib.h -#include avcodec.h -#include avformat.h +#include libavcodec/avcodec.h +#include libavformat/avformat.h #include buffer.h #include format.h #include input.h
Bug#518611: python-poppler: FTBFS against new poppler (new upstream version needed)
Package: python-poppler Version: 0.8.1-1 Severity: serious User: debian-rele...@lists.debian.org Usertag: transition-blocker From https://buildd.debian.org/fetch.cgi?pkg=python-popplerarch=amd64ver=0.8.1-1%2Bb1stamp=1236431658file=logas=raw: | gcc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/python2.4 -D_REENTRANT -I/usr/include/pygtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/atk-1.0 -I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pycairo -g -O2 -Wall -std=c9x -fno-strict-aliasing -MT poppler_la-poppler.lo -MD -MP -MF .deps/poppler_la-poppler.Tpo -c poppler.c -fPIC -DPIC -o .libs/poppler_la-poppler.o | poppler.c: In function '_wrap_poppler_annot_text_get_icon': | poppler.c:1705: warning: assignment makes integer from pointer without a cast | poppler.c:1707: error: 'POPPLER_TYPE_ANNOT_TEXT_ICON' undeclared (first use in this function) | poppler.c:1707: error: (Each undeclared identifier is reported only once | poppler.c:1707: error: for each function it appears in.) | poppler.c: In function 'py_poppler_add_constants': | poppler.c:3373: error: 'POPPLER_TYPE_ANNOT_TEXT_ICON' undeclared (first use in this function) I'm guessing pypoppler just needs an update to its latest upstream version in order to build fine against the latest poppler. I'd be grateful if somebody could do that soon. Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Alanis Morissette - Joining you -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516834: ogle - FTBFS: undefined reference to `ifoPrint_VTS_TMAPT'
tag 516834 pending thanks * peter green [Tue, 03 Mar 2009 01:23:02 +]: tags 516834 +patch thanks I tried to apply the patch I found at http://mail-index.netbsd.org/pkgsrc-bugs/2009/01/26/msg030603.html . Two hunks succeeded two hunks failed and so I applied the changes in them manually (I suspect that the failure to apply was caused by whitespace issues in the patch caused by netbsds mail archive but I didn't bother to check) The result is attatched in dpatch form ready to be added to the end of the series. Thanks for digging up this, peter. I'm about to upload a NMU. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org — Oh, George, you didn't jump into the river. How sensible of you! -- Mrs Banks in “Mary Poppins” -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516834: ogle: diff for NMU version 0.9.2-5.3
tags 516834 + patch
thanks
Hi,
Attached is the diff for my ogle 0.9.2-5.3 NMU.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Truth is the most valuable thing we have, so let's economize it.
-- Mark Twain
diff -u ogle-0.9.2/debian/changelog ogle-0.9.2/debian/changelog
--- ogle-0.9.2/debian/changelog
+++ ogle-0.9.2/debian/changelog
@@ -1,3 +1,11 @@
+ogle (0.9.2-5.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS when building against libdvdread 4.1.3. Patch sent in by peter
+green and obtained from the NetBSD project. (Closes: #516834)
+
+ -- Adeodato Simó d...@net.com.org.es Wed, 04 Mar 2009 09:52:16 +
+
ogle (0.9.2-5.2) unstable; urgency=low
* Non-maintainer upload.
diff -u ogle-0.9.2/debian/patches/00list ogle-0.9.2/debian/patches/00list
--- ogle-0.9.2/debian/patches/00list
+++ ogle-0.9.2/debian/patches/00list
@@ -3,0 +4 @@
+70-fix_ftbfs_with_new_libdvdread
only in patch2:
unchanged:
--- ogle-0.9.2.orig/config.log
+++ ogle-0.9.2/config.log
@@ -0,0 +1,339 @@
+This file contains any messages produced by compilers while
+running configure, to aid debugging if configure makes a mistake.
+
+It was created by configure, which was
+generated by GNU Autoconf 2.59. Invocation command line was
+
+ $ ./configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --prefix=/usr --mandir=${prefix}/share/man --sysconfdir=${prefix}/etc
+
+## - ##
+## Platform. ##
+## - ##
+
+hostname = justin
+uname -m = x86_64
+uname -r = 2.6.28-1-amd64
+uname -s = Linux
+uname -v = #1 SMP Wed Feb 18 17:16:12 UTC 2009
+
+/usr/bin/uname -p = unknown
+/bin/uname -X = unknown
+
+/bin/arch = unknown
+/usr/bin/arch -k = unknown
+/usr/convex/getsysinfo = unknown
+hostinfo = unknown
+/bin/machine = unknown
+/usr/bin/oslevel = unknown
+/bin/universe = unknown
+
+PATH: /usr/lib/ccache
+PATH: /usr/sbin
+PATH: /usr/bin
+PATH: /sbin
+PATH: /bin
+
+
+## --- ##
+## Core tests. ##
+## --- ##
+
+configure:1578: checking for a BSD-compatible install
+configure:1633: result: /usr/bin/install -c
+configure:1644: checking whether build environment is sane
+configure:1687: result: yes
+configure:1752: checking for gawk
+configure:1781: result: no
+configure:1752: checking for mawk
+configure:1768: found /usr/bin/mawk
+configure:1778: result: mawk
+configure:1788: checking whether make sets $(MAKE)
+configure:1808: result: yes
+configure:1976: checking whetherconfigure:1976: checking whether to enable maintainer-specific portions of Makefiles
+configure:1985: result: no
+configure:2configure:2024: result: x86_64-pc-linux-gnu
+configure:2032: checking host system type
+configure:2046: result: x86_64-pc-linux-gnu
+configure:2063: checking for x86_64-linux-gnu-gcc
+configure:2079: found /usr/lib/ccache/x86_64-linux-gnu-gcc
+configure:2089: result: x86_64-linux-gnu-gcc
+configure:2371: checking for C compiler version
+configure:2374: x86_64-linux-gnu-gcc --version /dev/null 5
+x86_64-linux-gnu-gcc (Debian 4.3.3-4) 4.3.3
+Copyright (C) 2008 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions. There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
+configure:2377: $? = 0
+configure:2379: x86_64-linux-gnu-gcc -v /dev/null 5
+Using built-in specs.
+Target: x86_64-linux-gnu
+Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
+Thread model: posix
+gcc version 4.3.3 (Debian 4.3.3-4)
+configure:2382: $? = 0
+configure:2384: x86_64-linux-gnu-gcc -V /dev/null 5
+x86_64-linux-gnu-gcc: '-V' option must have argument
+configure:2387: $? = 1
+configure:2410: checking for C compiler default output file name
+configure:2413: x86_64-linux-gnu-gcc -g -O2 conftest.c 5
+configure:2416: $? = 0
+configure:2462: result: a.out
+coconfigure:2462: result: a.out
+configure:2467: checkiconfigure:2473: ./a.out
+configure:2476: $? = 0
+configure:2493: result: yes
+configure:2500: checking whether we are cross compiling
+configure:2502: result: no
+configure:2505: checking for sufconfigure:2505: checonfigure:2507: x86_64-linux-gnuconfigure:2507: x86_64-linux-gnu-gcc -o coconfigure:2510: $? = 0
+configure:2535: result:
+configuconfigure:2535: result:
+configure:2541: checconfigure:2562: x86_64-linux-gnuconfigure:2562: x86_64-linux-gnconftest.c:34
Bug#516825: dvdbackup - FTBFS: error: 'dvd_stat_t' undeclared
* Stephen Gran [Mon, 02 Mar 2009 22:50:43 +]: I'm not sure, which is why I was asking. I can see two arguments - one that we should just move on from the broken version(s) of the library, and another that the packaging should be made robust enough that it doesn't try to accidentally build against a known broken version of the library (i.e., fixing Build-Depends to be more strictly versioned). Both arguments make sense to me, but I'll leave it up to RMs to decide which is better for the archive. Library bugs in unstable are transient, so I don't think such information belongs in the Build-Depends line of reverse dependencies, no, at least not in the common case. If, say, a library bug doesn't cause packages to FTBFS, but introduces buggy code in the resulting binary that does rm -rf /, then a Build-Conflicts or an updated Build-Depends may be in order, yes. ;-) Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org - Why are you whispering? - Because I just think that no matter where she is, my mom can hear this conversation. -- Rory and Lane -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516825: dvdbackup - FTBFS: error: 'dvd_stat_t' undeclared
* Benjamin Drung [Mon, 02 Mar 2009 01:40:26 +0100]: libdvdread 4.1.3-4 is now in Debian unstable. dvdbackup 0.2-2 builds now without changes. Could someone trigger a binNMU? Done, thanks for the heads-up. Could you close the bug once it's built everywhere? TIA. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org - You look beaten. - I just caught Tara laughing with another man. - Are you sure they weren't just... kissing or something? - No, they were laughing. -- Denny Crane and Alan Shore -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516825: dvdbackup - FTBFS: error: 'dvd_stat_t' undeclared
* Stephen Gran [Mon, 02 Mar 2009 22:26:51 +]: This one time, at band camp, Adeodato Simó said: * Benjamin Drung [Mon, 02 Mar 2009 01:40:26 +0100]: libdvdread 4.1.3-4 is now in Debian unstable. dvdbackup 0.2-2 builds now without changes. Could someone trigger a binNMU? Done, thanks for the heads-up. Could you close the bug once it's built everywhere? TIA. It's built everywhere but alpha and sparc now, but it looks like I didn't realize that the dep-wait should have been more specific. It needs to be built against 4.1.3-4 or higher (or 4). This sounds to me like the right things might be a sourceful upload? Hm, a sourceful upload of what? I'm afraid I'm not getting it. If a library has a bug which makes other packages FTBFS, then these packages wait to get rebuilt once a fixed library is available. No? -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Love in your heart wasn't put there to stay. Love isn't love 'til you give it away. -- Oscar Hammerstein II -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517749: kino: FTBFS: needs adjusting for new ffmpeg include location
Package: kino Version: 1.3.0-2.1 Severity: serious https://buildd.debian.org/fetch.cgi?pkg=kinoarch=mipselver=1.3.0-2.1%2Bb1stamp=1235925752file=logas=raw g++ -DHAVE_CONFIG_H -I. -I../.. -Wall -pthread -D_REENTRANT -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libglade-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libxml2 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/lqt -D_FILE_OFFSET_BITS=64 -DKINO_PLUGINDIR=\/usr/lib/kino-gtk2/kino-gtk2\ -DDATADIR=\/usr/share\ -D__STDC_CONSTANT_MACROS -g -O2 -MT dvtitler.lo -MD -MP -MF .deps/dvtitler.Tpo -c dvtitler.cc -fPIC -DPIC -o .libs/dvtitler.o In file included from dvtitler.cc:32: ../frame.h:51:24: error: avcodec.h: No such file or directory ../frame.h:52:25: error: avformat.h: No such file or directory ../frame.h:54:24: error: swscale.h: No such file or directory -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Love in your heart wasn't put there to stay. Love isn't love 'til you give it away. -- Oscar Hammerstein II -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517763: paraview: FTBFS: 'class vtkFFMPEGWriterInternal' has no member named 'rgbInput'
Package: paraview Version: 3.4.0-2 Severity: serious https://buildd.debian.org/fetch.cgi?pkg=paraviewarch=amd64ver=3.4.0-2%2Bb1stamp=1235490379file=logas=raw /build/buildd/paraview-3.4.0/VTK/IO/vtkFFMPEGWriter.cxx:326: error: 'class vtkFFMPEGWriterInternal' has no member named 'rgbInput' /build/buildd/paraview-3.4.0/VTK/IO/vtkFFMPEGWriter.cxx:331: error: 'av_free' was not declared in this scope /build/buildd/paraview-3.4.0/VTK/IO/vtkFFMPEGWriter.cxx:335: error: 'class vtkFFMPEGWriterInternal' has no member named 'avStream' /build/buildd/paraview-3.4.0/VTK/IO/vtkFFMPEGWriter.cxx:337: error: 'class vtkFFMPEGWriterInternal' has no member named 'avStream' /build/buildd/paraview-3.4.0/VTK/IO/vtkFFMPEGWriter.cxx:337: error: 'av_free' was not declared in this scope /build/buildd/paraview-3.4.0/VTK/IO/vtkFFMPEGWriter.cxx:338: error: 'class vtkFFMPEGWriterInternal' has no member named 'avStream' /build/buildd/paraview-3.4.0/VTK/IO/vtkFFMPEGWriter.cxx:341: error: 'class vtkFFMPEGWriterInternal' has no member named 'avFormatContext' /build/buildd/paraview-3.4.0/VTK/IO/vtkFFMPEGWriter.cxx:345: error: 'class vtkFFMPEGWriterInternal' has no member named 'avFormatContext' /build/buildd/paraview-3.4.0/VTK/IO/vtkFFMPEGWriter.cxx:345: error: 'av_write_trailer' was not declared in this scope /build/buildd/paraview-3.4.0/VTK/IO/vtkFFMPEGWriter.cxx:346: error: 'class vtkFFMPEGWriterInternal' has no member named 'avFormatContext' /build/buildd/paraview-3.4.0/VTK/IO/vtkFFMPEGWriter.cxx:346: error: 'url_fclose' was not declared in this scope /build/buildd/paraview-3.4.0/VTK/IO/vtkFFMPEGWriter.cxx:350: error: 'class vtkFFMPEGWriterInternal' has no member named 'avFormatContext' /build/buildd/paraview-3.4.0/VTK/IO/vtkFFMPEGWriter.cxx:350: error: 'av_free' was not declared in this scope /build/buildd/paraview-3.4.0/VTK/IO/vtkFFMPEGWriter.cxx:351: error: 'class vtkFFMPEGWriterInternal' has no member named 'avFormatContext' /build/buildd/paraview-3.4.0/VTK/IO/vtkFFMPEGWriter.cxx:354: error: 'class vtkFFMPEGWriterInternal' has no member named 'avOutputFormat' /build/buildd/paraview-3.4.0/VTK/IO/vtkFFMPEGWriter.cxx:359: error: 'class vtkFFMPEGWriterInternal' has no member named 'avOutputFormat' make[3]: *** [VTK/IO/CMakeFiles/vtkIO.dir/vtkFFMPEGWriter.o] Error 1 make[3]: Leaving directory `/build/buildd/paraview-3.4.0/obj-x86_64-linux-gnu' make[2]: *** [VTK/IO/CMakeFiles/vtkIO.dir/all] Error 2 make[2]: Leaving directory `/build/buildd/paraview-3.4.0/obj-x86_64-linux-gnu' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd/paraview-3.4.0/obj-x86_64-linux-gnu' make: *** [debian/stamp-makefile-build] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Carlos Berlanga - El ángel exterminador -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516921: libtaoframework-ffmpeg0.4-cil: needs updating dependency from libavcodec51 to libavcodec52
Package: libtaoframework-ffmpeg0.4-cil Version: 2.0.0.svn20071027-5 Severity: serious This package is arch:all, and can't be binNMUed for this transition. Please somebody take care of a sourceful upload. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org - I love you, Shirley, I'm not ashamed to say. - If you love me, then you'll want me to be happy. Even if I'm not with you. - I don't love you that much. -- Denny Crane and Shirley Schmidt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516933: mplayer: FTBFS: build-conflicts against libavcodec-dev in unstable
Package: mplayer Version: 1.0~rc2-20 Severity: serious TIA. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#385209: Old bug in ppmtofb is quite important
* Jaap Boender [Thu, 19 Feb 2009 13:47:01 +0100]: Hello, Jaap. The explanation: since ppmtofb conflicts with any python version strictly higher than 2.4, any package that depends on python-2.4 will not be installable together with ppmtofb, hence the 1591 packages (a full list, with for every package the dependency path that links it to python is available at http://www.pps.jussieu.fr/~boender/ppmtofb_conflicts.txt ). Thanks for this information. The package just needs to drop the conflict, it's buggy anyway. Additionally, maybe the package should be removed altogether (CC'ing -qa). It has popcon 5, and hasn't seen a real upload for 6 years. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Don't be irreplaceable, if you can't be replaced, you can't be promoted. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515708: please remove liblocale-ruby from testing
* Antonio Terceiro [Tue, 17 Feb 2009 11:20:31 -0300]: Hi there, Please remove the liblocale-ruby package from testing. The maintainers (pkg-ruby-extras team) didn't find yet a good sollution for problems introduced by the use of this library. See #515708 for details. The package is also dead upstream. (I'not on the list, so I'd like to be copied on eventual replies) Removal hint added. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Man is certainly stark mad; he cannot make a flea, yet he makes gods by the dozens. -- Michel de Montaigne -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515132: debian-installer: source for version of dhcp3-client-udeb used in D-I not in archive
* Joerg Jaspert [Sat, 14 Feb 2009 00:48:40 +0100]: I tried rmadison, but that is/was broken: $ rmadison dhcp3 Traceback (most recent call last): File /usr/local/bin/dak, line 248, in ? main() File /usr/local/bin/dak, line 243, in main module.main() File /srv/ftp.debian.org/dak/dak/ls.py, line 90, in main projectB = pg.connect(Cnf[DB::Name], Cnf[DB::Host], int(Cnf[DB::Port])) pg.InternalError: FATAL: database projectb does not exist Uhm, do you get that consistently? It works just fine here. Maybe you tried exactly when projectb in merkel gets reconstructed from the dumps, which *maybe* makes the database not exist for a small period of time. s/maybe//. It gets dropped and re-created. Unfortunately postgres currently can't do any real (and working) replication, so the merkel copy is handled in a rather ugly way... I just submitted http://bugs.debian.org/515173. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Mankind are very odd creatures: one half censure what they practice, the other half practice what they censure; the rest always say and do as they ought. -- Michel de Montaigne -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
