Bug#1065110: ypbind-mt: FTBFS: missing build-dep on libnsl-dev
On Thu, Feb 29, 2024 at 10:03:53PM +0100, Aurelien Jarno wrote: This could be fixed by adding an explicit Build-Depends on libnsl-dev. The glibc change will likely be reverted in the short term, but given its a change we want to do for Trixie, this will only lower the severity of the bug. Regards Aurelien Thanks, this seems the less impacting solution. -- ⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61 ⠈⠳⣄ ED02 0F02 A5E1 1636 86A4
Bug#997430: xaw3d: FTBFS: -q: invalid option -- '.'
tags 997430 + help
thanks
On Sat, Oct 23, 2021 at 10:36:29PM +0200, Lucas Nussbaum wrote:
Source: xaw3d
Version: 1.5+F-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20211023 ftbfs-bookworm
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Relevant part (hopefully):
[...]
This seems more a breakage in binutils and/or xmkmf generated Makefile, than a
problem in the problem in the Imakefile per se, which does not define anything
related to the static library linkage.
Any ideas would be appreciated about this issue.
rm -f libXaw3d.so.6.1~
+ cd .
+ gcc -o ./libXaw3d.so.6.1~ -shared -Wl,-soname,libXaw3d.so.6 AllWidgets.o
AsciiSink.o AsciiSrc.o AsciiText.o Box.o Command.o Dialog.o Form.o Grip.o
Label.o Layout.o List.o MenuButton.o Paned.o Panner.o Porthole.o Repeater.o
Scrollbar.o Simple.o SimpleMenu.o Sme.o SmeBSB.o SmeLine.o SmeThreeD.o
StripChart.o Text.o TextSink.o TextSrc.o TextAction.o TextPop.o TextTr.o
ThreeD.o Tip.o Toggle.o Tree.o Vendor.o Viewport.o Xaw3dP.o XawInit.o laygram.o
laylex.o MultiSrc.o MultiSink.o XawIm.o XawI18n.o -lXmu -lXt -lSM -lICE -lXext
-lX11 -lXt -lSM -lICE -lXpm -lXext -lX11 -lc
/usr/bin/ld: AsciiSrc.o: in function `InitStringOrFile':
/<>/xc/lib/Xaw3d/AsciiSrc.c:1067: warning: the use of `tmpnam' is
dangerous, better use `mkstemp'
+ rm -f libXaw3d.so.6
+ ln -s libXaw3d.so.6.1 libXaw3d.so.6
rm -f libXaw3d.so.6.1
mv -f libXaw3d.so.6.1~ libXaw3d.so.6.1
+ rm -f libXaw3d.so
+ ln -s libXaw3d.so.6.1 libXaw3d.so
rm -f libXaw3d.a
+ cd unshared
+ ar clq ../libXaw3d.a AllWidgets.o AsciiSink.o AsciiSrc.o AsciiText.o Box.o
Command.o Dialog.o Form.o Grip.o Label.o Layout.o List.o MenuButton.o Paned.o
Panner.o Porthole.o Repeater.o Scrollbar.o Simple.o SimpleMenu.o Sme.o SmeBSB.o
SmeLine.o SmeThreeD.o StripChart.o Text.o TextSink.o TextSrc.o TextAction.o
TextPop.o TextTr.o ThreeD.o Tip.o Toggle.o Tree.o Vendor.o Viewport.o Xaw3dP.o
XawInit.o laygram.o laylex.o MultiSrc.o MultiSink.o XawIm.o XawI18n.o
-q: invalid option -- '.'
Usage: ar [emulation options] [-]{dmpqrstx}[abcDfilMNoOPsSTuvV] [--plugin
] [member-name] [count] archive-file file...
ar -M [ ] - specify the dependencies of this library
[S] - do not build a symbol table
[T] - make a thin archive
[v] - be verbose
[V] - display the version number
@ - read options from
--target=BFDNAME - specify the target object format as BFDNAME
--output=DIRNAME - specify the output directory for extraction operations
--record-libdeps= - specify the dependencies of this library
optional:
--plugin - load the specified plugin
emulation options:
No emulation specific options
ar: supported targets: elf64-x86-64 elf32-i386 elf32-iamcu elf32-x86-64
pei-i386 pe-x86-64 pei-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big
elf32-little elf32-big pe-bigobj-x86-64 pe-i386 srec symbolsrec verilog tekhex
binary ihex plugin
make[2]: *** [Makefile:1158: libXaw3d.a] Error 1
--
Francesco P. Lovergine
Bug#989929: Suddenly restarting fetchmail started to fail with error about its global pidfile
On Thu, Jun 24, 2021 at 07:11:02PM +0200, László Böszörményi (GCS) wrote: Control: tags -1 +pending moreinfo On Wed, Jun 16, 2021 at 10:00 AM Francesco P. Lovergine wrote: This is currently run on testing since ages. I had to restart due to a changed fingerprint and the global service started to fail with: [...] giu 16 08:07:28 klecker fetchmail[846499]: fetchmail: lock creation failed, pidfile "/run/fetchmail/fetchmail.pid": File o directory non esistente Thanks for the report and the proposed fix! Can you please check if the updated package[1] is fine for you now? Cheers, Laszlo/GCS [1] dget -x https://people.debian.org/~gcs/fetchmail_6.4.16-2.dsc Yes it is working. -- Francesco P. Lovergine
Bug#989929: Suddenly restarting fetchmail started to fail with error about its global pidfile
Package: fetchmail Version: 6.4.16-1 Severity: grave This is currently run on testing since ages. I had to restart due to a changed fingerprint and the global service started to fail with: $ systemctl status fetchmail.service ● fetchmail.service - LSB: init-Script for system wide fetchmail daemon Loaded: loaded (/etc/init.d/fetchmail; generated) Active: active (exited) since Wed 2021-06-16 08:07:28 CEST; 1h 23min ago Docs: man:systemd-sysv-generator(8) Tasks: 0 (limit: 9313) Memory: 0B CPU: 0 CGroup: /system.slice/fetchmail.service giu 16 08:07:28 klecker systemd[1]: Starting LSB: init-Script for system wide fetchmail daemon... giu 16 08:07:28 klecker fetchmail[846490]: Starting mail retriever agent: fetchmail. giu 16 08:07:28 klecker systemd[1]: Started LSB: init-Script for system wide fetchmail daemon. giu 16 08:07:28 klecker fetchmail[846499]: starting fetchmail 6.4.16 daemon giu 16 08:07:28 klecker fetchmail[846499]: fetchmail: lock creation failed, pidfile "/run/fetchmail/fetchmail.pid": File o directory non esistente The /run/fetchmail directory ownership is correct (fetchmail:nogroup) and if I start the process by hand with: sudo -u fetchmail -- fetchmail --pidfile /run/fetchmail/fetchmail.pid --nosslcertck -f /etc/fetchmailrc --syslog it works regularly. So the problem is with the init script, still used by systemd. Here: start-stop-daemon -S -o -q -p $PIDFILE -x $DAEMON -u $USER -c $USER -- $OPTIONS; I think the problem resides. I see that the pidfile is passed at the same time to start-stop-daemon and the daemon (-p and $OPTIONS) which run in unprivileged mode. I changed the instruction into: start-stop-daemon -S -o -q -x $DAEMON -u $USER -c $USER -- $OPTIONS; and now it works. Note that currently man page reports: Warning: Using this match option with a world-writable pidfile or using it alone with a daemon that writes the pidfile as an unprivileged (non-root) user will be refused with an error (since version 1.19.3) as this is a security risk, because either any user can write to it, or if the daemon gets compromised, the contents of the pidfile cannot be trusted, and then a privileged runner (such as an init script executed as root) would end up acting on any system process. Using /dev/null is exempt from these checks. and bullseye runs dpkg v1.20.9 currently. I'm tagging this bug as grave because even if fetchmail is not always used in daemon mode, it breaks for sure existing configurations in an unexpected way (and the reason is quite obscure for the casual user) - cheers -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fetchmail depends on: ii adduser 3.118 ii debianutils 4.11.2 ii libc6 2.31-12 ii libcom-err2 1.46.2-1 ii libgssapi-krb5-2 1.18.3-5 ii libkrb5-3 1.18.3-5 ii libssl1.1 1.1.1k-1 ii lsb-base 11.1.0 Versions of packages fetchmail recommends: ii ca-certificates 20210119 Versions of packages fetchmail suggests: ii exim4-daemon-heavy [mail-transport-agent] 4.94.2-5 pn fetchmailconf pn resolvconf -- Configuration Files: /etc/default/fetchmail changed: OPTIONS=--nosslcertck START_DAEMON=yes PIDFILE=/run/fetchmail/fetchmail.pid -- no debconf information -- Francesco P. Lovergine
Bug#984616: nis: prompting due to modified conffiles which were not modified by the user: /etc/default/nis
On Fri, Mar 05, 2021 at 09:57:27PM +0100, Andreas Beckmann wrote: during a test with piuparts I noticed your package failed the piuparts upgrade test because dpkg detected a conffile as being modified and then prompted the user for an action. As there is no user input, this fails. But this is not the real problem, the real problem is that this prompt shows up in the first place, as there was nobody modifying this conffile at all, the package has just been installed and upgraded... This is a violation of policy 10.7.3, see https://www.debian.org/doc/debian-policy/ch-files.html#behavior, which says "[These scripts handling conffiles] must not ask unnecessary questions (particularly during upgrades), and must otherwise be good citizens." This is a non sense, the 4 series is proposing a relevant change to the system, that is having all services off in that stupid file (the previous insane default was having the system in client+broadcast mode). The simple mechanism of conffiles can only undestand if the new default is different from the current file, not if the user maintained that on purpose or not. So a the question IS relevant. The whole wide changes are explained in the NEWS file and a sane admin will prefer to have all services stopped and act for the better. -- Francesco P. Lovergine
Bug#978340: proftpd-mod-dnsbl: FTBFS: Cannot compile mod_dnsbl using prxs
Oh well, proftpd-mod-dnsbl is now obsoleted by proftpd-core who also Provides it in sid, and the source package should be removed in testing/sid to allow migration of current proftpd. I have a lapsus about that, should I ask an explicit remove to d-release? On Sat, Dec 26, 2020 at 11:08:09PM +0100, Lucas Nussbaum wrote: Source: proftpd-mod-dnsbl Version: 0.1.5-5 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20201226 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): make[1]: Entering directory '/<>' DESTDIR=/<>/debian/proftpd-mod-dnsbl prxs -c mod_dnsbl.c Cannot compile mod_dnsbl using prxs; use existing ./configure script instead: ./configure make make install make[1]: *** [debian/rules:15: override_dh_auto_build] Error 1 The full build log is available from: http://qa-logs.debian.net/2020/12/26/proftpd-mod-dnsbl_0.1.5-5_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please marking it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with me so that we can identify if something relevant changed in the meantime. About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. ___ Pkg-proftpd-maintainers mailing list pkg-proftpd-maintain...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-proftpd-maintainers -- Francesco P. Lovergine
Bug#977349: Current package does not ensure a smooth upgrade from stable due to breakage of past config and new binary modules.
On Tue, Dec 15, 2020 at 09:01:51PM +0100, Hilmar Preuße wrote: Am 14.12.2020 um 11:02 teilte Francesco Paolo Lovergine mit: Hi Paolo, After upgrade: $ sudo proftpd -t Checking syntax of configuration file 2020-12-14 09:59:09,942 legolas proftpd[5444]: mod_dso/0.5: unable to load 'mod_tls.c'; check to see if '/usr/lib/proftpd/mod_tls.la' exists Please note that put the new packages into the Recommend line of proftp-basic. So people using a default apt config would get both new packages. At least on one of my installations this worked fine. Not in general, the default policy of installing Recommends could be relaxed by users for all packages in /etc/apt/apt.conf or even for single upgrades by options in apt-get/aptitude. So it would be a policy violation in any case. Not sure if this is the correct migration path according to policy. I'm sorry for the work I've caused! Well, there were in any case other details to manage. -- Francesco P. Lovergine
Bug#977090: The 1.3.7a original tarball includes IETF RFCs documents
Source: proftpd-dfsg Version: 1.3.7a-1 Severity: serious Justification: Policy 2.2.1 As in subject, the RFCs need to be stripped before uploading a new upstream tarball, because not compliant to DFSG. That step was missed at the time of upload. -- Francesco P. Lovergine
Bug#923926: proftpd has memory leaks, allows Denial-Of-Service attack
On Fri, Apr 05, 2019 at 01:46:23PM +0200, Markus Koschany wrote: Hi, Am 29.03.19 um 16:44 schrieb Francesco P. Lovergine: On Thu, Mar 28, 2019 at 01:49:51PM +0100, Markus Koschany wrote: Hello Francesco, I intend to upgrade proftpd in Jessie to fix the memory leaks and another unrelated issue. I think it would be best to backport the version in testing. If you agree, I could also update proftpd in stable. Please let me know if I can proceed. A conservative approach would be using latest 1.3.5 version, instead of 1.3.6. I have backported version 1.3.5e to Stretch. I don't have access to the Git repository but I have uploaded the new package to people.debian.org. https://people.debian.org/~apo/proftpd/ where you can grab the sources. There were at least three different memory leak issues that were fixed. Two of them are related to the mod_sftp module and this bug report, another one was in mod_facl. I intend to contact the release team next week for a stretch-pu. Regards, Markus That should be definitively the easiest solutions. Of course 1.3.5e does not strictly fix only those three leaks, so that update could be non acceptable for a secteam upload. -- Francesco P. Lovergine
Bug#923926: proftpd has memory leaks, allows Denial-Of-Service attack
On Thu, Mar 28, 2019 at 01:49:51PM +0100, Markus Koschany wrote: Hello Francesco, I intend to upgrade proftpd in Jessie to fix the memory leaks and another unrelated issue. I think it would be best to backport the version in testing. If you agree, I could also update proftpd in stable. Please let me know if I can proceed. A conservative approach would be using latest 1.3.5 version, instead of 1.3.6. -- Francesco P. Lovergine
Bug#892372: [INFO] Bug#892372: proftpd-mod-msg FTBFS with proftpd 1.3.6-1
On Thu, Mar 08, 2018 at 05:27:10PM +0200, Adrian Bunk wrote: Source: proftpd-mod-msg Version: 0.4.1-1.1 Severity: serious Tags: buster sid https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/proftpd-mod-msg.html ... mod_msg.c:56:3: error: #error "mod_msg requires Controls support (--enable-ctrls)" # error "mod_msg requires Controls support (--enable-ctrls)" ^ This is another trivial fix, just s/USE_CTRLS/PR_USE_CTRLS/ in source. -- Francesco P. Lovergine
Bug#892468: proftp: Prevent migration to testing
On Fri, Mar 09, 2018 at 12:13:55PM +0100, Hilmar Preuße wrote: Package: proftpd-basic Version: 1.3.6-1 Severity: critical Justification: breaks unrelated software Dear Maintainer, for now we want to prevent the package from migrating to testing until we are sure all bugs are fixed. For now already three bugs were reported telling that some modules do not build any more: - Bug#892371: proftpd-mod-vroot FTBFS with proftpd 1.3.6-1 - Bug#892372: proftpd-mod-msg FTBFS with proftpd 1.3.6-1 - Bug#892373: proftpd-mod-fsync FTBFS with proftpd 1.3.6-1 Hilmar, I just followed up error reports with hints for fixing. Do you mind to work on them? -- Francesco P. Lovergine
Bug#892371: [INFO] Bug#892371: proftpd-mod-vroot FTBFS with proftpd 1.3.6-1
On Thu, Mar 08, 2018 at 05:25:20PM +0200, Adrian Bunk wrote:
Source: proftpd-mod-vroot
Version: 0.9.4-1
Severity: serious
Tags: buster sid
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/proftpd-mod-vroot.html
...
mod_vroot.c:1518:19: error: void value not ignored as it ought to be
if (cmd->argv[1][pathlen - 1] != '/') {
^
...
mod_vroot.c: In function 'vroot_pre_pass':
mod_vroot.c:1651:7: error: 'pr_fs_t {aka struct fs_rec}' has no member named
'creat'; did you mean 'read'?
fs->creat = vroot_creat;
^
This is fixed in 0.9.7, better upgrading.
--
Francesco P. Lovergine
Bug#892373: [INFO] Bug#892373: proftpd-mod-fsync FTBFS with proftpd 1.3.6-1
On Thu, Mar 08, 2018 at 05:28:49PM +0200, Adrian Bunk wrote: Source: proftpd-mod-fsync Version: 0.2-1 Severity: serious Tags: buster sid https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/proftpd-mod-fsync.html ... mod_fsync.c:184:10: error: implicit declaration of function 'HANDLED'; did you mean 'PR_HANDLED'? [-Werror=implicit-function-declaration] return HANDLED(cmd); ^~~ ... mod_fsync.c: In function 'fsync_postparse_ev': mod_fsync.c:269:12: error: 'LOG_SYMLINK' undeclared (first use in this function); did you mean 'PR_LOG_SYMLINK'? case LOG_SYMLINK: ^~~ PR_LOG_SYMLINK mod_fsync.c:269:12: note: each undeclared identifier is reported only once for each function it appears in mod_fsync.c:274:12: error: 'LOG_WRITEABLE_DIR' undeclared (first use in this function); did you mean 'PR_LOG_WRITABLE_DIR'? case LOG_WRITEABLE_DIR: ^ Here the fix is trivial as suggested. Even in this case it is better upgrading to current upstream version. -- Francesco P. Lovergine
Bug#886742: [INFO] Bug#886742: postgresql-9.4-postgis-2.1 missing in stretch
On Tue, Jan 09, 2018 at 02:37:44PM +0100, Jürgen Fuchsberger wrote: > >> What did you try, and what didn't work? > > > > Probably pg_upgradecluster, and that is not supported for databases with > > the postgis extension. > > > Exactly. Just wanted to point out that upgrading was no possibility > either, the actual problem was that the database could not be accessed > or dumped after the upgrade. While ideally one could use hook scripts to manage such kind of extensions I would not try that approach in any case. A Postgis hard upgrade is generally a trial-and-error nightmare^Wexperience and it depends on languages, extensions, encodings. Last time, I had to perform a series of ad hoc setups before trying the restore. I strongly suggest to run both servers and extensions on the host in order to run a successfully shop upgrade later. That is definitively possible, I have at least one server still running both 8.4 and 9.4 with required Postgis extensions. -- Francesco P. Lovergine
Bug#864924: virtualbox GUI not more working
Package: virtualbox Version: 5.1.22-dfsg-1 Severity: grave Dear Maintainer, the program fails to start with the following message: $ LANG=C virtualbox Qt FATAL: This application failed to start because it could not find or load the Qt platform plugin "xcb" in "". Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, xcb. Reinstalling the application may fix this problem. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages virtualbox depends on: ii adduser 3.115 ii init-system-helpers 1.48 ii libc6 2.24-11 ii libcurl3-gnutls 7.52.1-5 ii libdevmapper1.02.12:1.02.137-2 ii libgcc1 1:6.3.0-18 ii libgsoap102.8.35-4 ii libpng16-16 1.6.28-1 ii libpython3.5 3.5.3-3 ii libsdl1.2debian 1.2.15+dfsg1-4 ii libssl1.1 1.1.0f-3 ii libstdc++66.3.0-18 ii libvncserver1 0.9.11+dfsg-1 ii libvpx4 1.6.1-3 ii libx11-6 2:1.6.4-3 ii libxcursor1 1:1.1.14-1+b4 ii libxext6 2:1.3.3-1+b2 ii libxml2 2.9.4+dfsg1-2.2 ii libxmu6 2:1.1.2-2 ii libxt61:1.1.5-1 ii procps2:3.3.12-3 ii python3 3.5.3-1 ii python3.5 3.5.3-3 ii virtualbox-dkms [virtualbox-modules] 5.1.22-dfsg-1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages virtualbox recommends: ii libgl1-mesa-glx [libgl1] 13.0.6-1+b2 ii libqt5core5a 5.7.1+dfsg-3+b1 ii libqt5opengl5 5.7.1+dfsg-3+b1 ii libqt5widgets55.7.1+dfsg-3+b1 ii virtualbox-qt 5.1.22-dfsg-1 Versions of packages virtualbox suggests: pn vde2 ii virtualbox-guest-additions-iso 5.1.22-1 -- no debconf information
Bug#772623: imapfilter: Fails to connect to imap mailboxes
severity 772623 important tag 772623 + moreinfo thanks It seems a problem due to your specific configuration. Please provide config.lua and a verbose session. On Tue, Dec 09, 2014 at 10:04:40AM +0100, Johannes Fichtinger wrote: Package: imapfilter Version: 1:2.5.2-2 Severity: grave Justification: renders package unusable Dear Maintainer, After a recent update of Debian testing, imapfilter fails to login into mailboxes. The following error message is shown: imapfilter: error while initiating connection to IMAPSERVER at port 993 imapfilter: login request to MYACCOUNT failed Before the most recent system updates in testing, i.e. before the 8/12/2014 3:00 CET, everything worked well. Please note that login to the very same mailboxes from other emailclients on the same machine works flawlessly. There is a new version available upstream - maybe packaging that one could help for this issue? I am more than happy to provide you with additional info if requested. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages imapfilter depends on: ii libc62.19-13 ii liblua5.2-0 5.2.3-1.1 ii libpcre3 1:8.35-3.1 ii libssl1.0.0 1.0.1j-1 imapfilter recommends no packages. imapfilter suggests no packages. -- no debconf information -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757308: grass: Please update to use wxpython3.0
On Wed, Aug 20, 2014 at 05:53:18PM +1200, Hamish wrote: Hamish wrote: grass 6.4.4.packaging is currently (basically) ready in DebianGIS git. Sebastiaan: But not by using git-import-orig. The upstream branch hasn't been updated with the grass_6.4.4.orig.tar.gz contents. it was done in the master branch, http://git.linuxminded.nl/?p=pkg-grass/grass;a=commit;h=d183a32b883dbad88e0d751d030e177dd90926a0 tagging is currently incomplete, but known todo and discussed privately. ... Do you mind to discuss NOT privately? You should run lintian showing all tags after your build to get an idea of what is left to fix before I would consider an upload. er, you really think we don't do that and know exactly what they are? We've been busy packaging this software for more than a dozen years! Not masking false positives and real but won't-fix in this major version lintian issues is not a bug IMHO. Bas, the grass package has a long list of lintian issues due mainly to specific choices of upstream team and historical reasons. It is quite pointless trying to respect the full policy by patching at every new release, and it would be also an heavy job (with no hopes of being accepted upstream for merging). This is well expected for such a scientific program born in the 80s and having a very conservative and tiny development team. No doubt the main rules file could use a bit of a refresh here and there (supporting 'make -j' would be nice), but let's continue this conversation on the DebainGIS list, not in a ticket about transitioning to wxpython3.0. I don't understand *why* the d-gis repo is not already up-to-date with an appropriate branching and tagging for the proper support. It is quite annoying working with yet-another-git-archive. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746167: FTBFS in sid/Tcl 8.6
On Sun, Apr 27, 2014 at 05:15:43PM +0100, Michael Tautschnig wrote: Package: aolserver4-nsopenssl Version: 3.0beta26-4 Severity: serious Usertags: goto-cc While compiling the package using our research compiler infrastructure the build failed with the following error: [...] gcc -g -I/usr/include/openssl -I/usr/kerberos/include -O2 -Wall -fPIC -I/usr/include/aolserver4 -I/usr/include/tcl8.6 -DNO_CONST -DUSE_INTERP_ERRORLINE -DPACKAGE_NAME=\tcl\ -DPACKAGE_TARNAME=\tcl\ -DPACKAGE_VERSION=\8.6\ -DPACKAGE_STRING=\tcl\ 8.6\ -DPACKAGE_BUGREPORT=\\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DHAVE_PTHREAD_ATFORK=1 -DTCL_THREADS=1 -DTCL_CFGVAL_ENCODING=\iso8859-1\ -DHAVE_ZLIB=1 -DMODULE_SCOPE=extern -DHAVE_CAST_TO_UNION=1 -DTCL_SHLIB_EXT=\.so\ -DNDEBUG=1 -DTCL_CFG_OPTIMIZED=1 -DTCL_TOMMATH=1 -DMP_PREC=4 -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_IS_LONG=1 -DHAVE_GETCWD=1 -DHAVE_MKSTEMP=1 -DHAVE_OPENDIR=1 -DHAVE_STRTOL=1 -DHAVE_WAITPID=1 -DHAVE_GETNAMEINFO=1 -DHAVE_GETADDRINFO=1 -DHAVE_FREEADDRINFO=1 -DHAVE_GAI_STRERROR=1 -DHAVE_STRUCT_ADDRINFO=1 -DHAVE_STRUCT_IN6_ADDR=1 -DHAVE_STRUCT_SOCKADDR_IN6=1 -DHAVE_STRUCT_SOCKADDR_STORAGE=1 -DHAVE_GETPWUID_R_5=1 -DHAVE_GETPWUID_R=1 -DHAVE_GETPWNAM_R_5=1 -DHAVE_GETPWNAM_R=1 -DHAVE_GETGRGID_R_5=1 -DHAVE_GETGRGID_R=1 -DHAVE_GETGRNAM_R_5=1 -DHAVE_GETGRNAM_R=1 -DHAVE_GETHOSTBYNAME_R_6=1 -DHAVE_GETHOSTBYNAME_R=1 -DHAVE_GETHOSTBYADDR_R_8=1 -DHAVE_GETHOSTBYADDR_R=1 -DHAVE_TERMIOS_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 -DHAVE_MKTIME=1 -DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_BLKCNT_T=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_LANGINFO=1 -DHAVE_MKSTEMPS=1 -DHAVE_FTS=1 -DHAVE_SYS_IOCTL_H=1 -DTCL_UNLOAD_DLLS=1 -DHAVE_CPUID=1 -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DTCL_CFG_OPTIMIZED=1 -DTCL_CFG_DEBUG=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_TIMEGM=1 -DHAVE_DRAND48=1 -DHAVE_RANDOM=1 -DHAVE_POLL=1 -DHAVE_GETADDRINFO=1 -DHAVE_GETNAMEINFO=1-c -o tclcmds.o tclcmds.c command-line:0:0: warning: PACKAGE_NAME redefined [enabled by default] command-line:0:0: note: this is the location of the previous definition command-line:0:0: warning: PACKAGE_TARNAME redefined [enabled by default] command-line:0:0: note: this is the location of the previous definition command-line:0:0: warning: PACKAGE_VERSION redefined [enabled by default] command-line:0:0: note: this is the location of the previous definition command-line:0:0: warning: PACKAGE_STRING redefined [enabled by default] command-line:0:0: note: this is the location of the previous definition tclcmds.c: In function 'NsTclOpenSSLObjCmd': tclcmds.c:338:31: error: 'Tcl_Interp' has no member named 'result' sprintf(interp-result, %d, sslconn-peerport); ^ Thanks, legacy code requires -DUSE_INTERP_RESULT definition to build under 8.6, the fix will be applied ASAP. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746168: FTBFS in sid/Tcl 8.6
The same fix of #746167 is required, thanks.
On Sun, Apr 27, 2014 at 05:18:51PM +0100, Michael Tautschnig wrote:
Package: aolserver4-nspostgres
Version: 4.5+20110709-1
Severity: serious
Usertags: goto-cc
While compiling the package using our research compiler infrastructure the
build
failed with the following error:
[...]
gcc -Wall -g -Wl,--no-as-needed -O2 -DBIND_EMULATION
-I/usr/include/postgresql -DFOR_ACS_USE -O2 -Wall -fPIC
-I/usr/include/aolserver4 -I/usr/include/tcl8.6 -DNO_CONST
-DUSE_INTERP_ERRORLINE -DPACKAGE_NAME=\tcl\ -DPACKAGE_TARNAME=\tcl\
-DPACKAGE_VERSION=\8.6\ -DPACKAGE_STRING=\tcl\ 8.6\
-DPACKAGE_BUGREPORT=\\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1
-D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DHAVE_PTHREAD_ATFORK=1
-DTCL_THREADS=1 -DTCL_CFGVAL_ENCODING=\iso8859-1\ -DHAVE_ZLIB=1
-DMODULE_SCOPE=extern -DHAVE_CAST_TO_UNION=1 -DTCL_SHLIB_EXT=\.so\
-DNDEBUG=1 -DTCL_CFG_OPTIMIZED=1 -DTCL_TOMMATH=1 -DMP_PREC=4
-D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_IS_LONG=1 -DHAVE_GETCWD=1
-DHAVE_MKSTEMP=1 -DHAVE_OPENDIR=1 -DHAVE_STRTOL=1 -DHAVE_WAITPID=1
-DHAVE_GETNAMEINFO=1 -DHAVE_GETADDRINFO=1 -DHAVE_FREEADDRINFO=1
-DHAVE_GAI_STRERROR=1 -DHAVE_STRUCT_ADDRINFO=1 -DHAVE_STRUCT_IN6_ADDR=1
-DHAVE_STRUCT_SOCKADDR_IN6=1 -DHAVE_STRUCT_SOCKADDR_STORAGE=1
-DHAVE_GETPWUID_R_5=1 -DHAVE_GETPWUID_R=1 -DHAVE_GETPWNAM_R_5=1
-DHAVE_GETPWNAM_R=1 -DHAVE_GETGRGID_R_5=1 -DHAVE_GETGRGID_R=1
-DHAVE_GETGRNAM_R_5=1 -DHAVE_GETGRNAM_R=1 -DHAVE_GETHOSTBYNAME_R_6=1
-DHAVE_GETHOSTBYNAME_R=1 -DHAVE_GETHOSTBYADDR_R_8=1 -DHAVE_GETHOSTBYADDR_R=1
-DHAVE_TERMIOS_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_TIME_H=1
-DTIME_WITH_SYS_TIME=1 -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 -DHAVE_MKTIME=1
-DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1
-DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_BLKCNT_T=1 -DHAVE_INTPTR_T=1
-DHAVE_UINTPTR_T=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_LANGINFO=1 -DHAVE_MKSTEMPS=1
-DHAVE_FTS=1 -DHAVE_SYS_IOCTL_H=1 -DTCL_UNLOAD_DLLS=1 -DHAVE_CPUID=1
-DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\
-DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DTCL_CFG_OPTIMIZED=1
-DTCL_CFG_DEBUG=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_TIMEGM=1 -DHAVE_DRAND48=1 -DHAVE_RANDOM=1 -DHAVE_POLL=1
-DHAVE_GETADDRINFO=1 -DHAVE_GETNAMEINFO=1-c -o nspostgres.o nspostgres.c
command-line:0:0: warning: PACKAGE_NAME redefined [enabled by default]
command-line:0:0: note: this is the location of the previous definition
command-line:0:0: warning: PACKAGE_TARNAME redefined [enabled by default]
command-line:0:0: note: this is the location of the previous definition
command-line:0:0: warning: PACKAGE_VERSION redefined [enabled by default]
command-line:0:0: note: this is the location of the previous definition
command-line:0:0: warning: PACKAGE_STRING redefined [enabled by default]
command-line:0:0: note: this is the location of the previous definition
nspostgres.c: In function 'Ns_PgSetErrorstate':
nspostgres.c:246:5: warning: enumeration value 'PGRES_COPY_BOTH' not handled
in switch [-Wswitch]
switch (PQresultStatus(nsConn-res)) {
^
nspostgres.c:246:5: warning: enumeration value 'PGRES_SINGLE_TUPLE' not
handled in switch [-Wswitch]
nspostgres.c: In function 'PgCmd':
nspostgres.c:1772:23: error: 'Tcl_Interp' has no member named 'result'
sprintf(interp-result, %u, nspgConn-cNum);
^
nspostgres.c:1778:19: error: 'Tcl_Interp' has no member named 'result'
interp-result = ok;
^
nspostgres.c:1780:19: error: 'Tcl_Interp' has no member named 'result'
interp-result = bad;
^
nspostgres.c: In function 'pg_column_command':
nspostgres.c:1985:17: error: 'Tcl_Interp' has no member named 'result'
sprintf (interp-result, %d, tinfo-ncolumns);
^
make[1]: *** [nspostgres.o] Error 1
Looking at the latest build logs for the package, this may be caused by the
updates to Tcl (the latest build was against Tcl 8.5, but sid now has 8.6).
The full build log is attached.
Best,
Michael
--
Francesco P. Lovergine
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742148: shapelib: FTBFS on powerpc (Both BIG_ENDIAN and LITTLE_ENDIAN defined!
://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742148: shapelib: FTBFS on powerpc (Both BIG_ENDIAN and LITTLE_ENDIAN defined!
On Wed, Mar 26, 2014 at 02:17:50PM +0100, Cyril Brulebois wrote: Francesco P. Lovergine fran...@debian.org (2014-03-26): While I accepted the patch a few minutes ago, indeed I seriously now doubt that the fix is correct. It seems to me that in the original program the LITTLE_ENDIAN should be intended as a static build-time definition for the host where the program is built. So the NAN definition should be intended instead as nan(). That's because the shapefile format is endianess-independent and shapelib reads/writes fields on the basis of the host platform to respect the format. So the NAN should be intended as the *host* NaN format, indeed (to be translated in the shp format NaN, i.e. little endian). That poses a problem on the pcc architecture for instance: __nan_bytes will be not the correct NaN value and will result as a big endian in the file. See http://dl.maptools.org/dl/shapelib/shapefile.pdf for format. Do you agree? To be frank I didn't quite get why it was considered a good idea to hardcode setting -Dfoo in contrib/Makefile unconditionally instead of looking at the relevant arch-specific bits. So I assumed this was deliberate and that this setting was orthogonal to what's in system headers, that's why I proposed the patch you saw. (From a quick look between last two upstream releases, this part didn't change; I guess this issue popped up due to updated system headers, but I didn't look into it to see what exactly triggered it.) I guess the contrib stuff is not so well maintained and probably not too much coherent. I guess looking at __BYTE_ORDER would be a better way to actually check a system's endianness, #error-ing if it's neither __LITTLE_ENDIAN or __BIG_ENDIAN; I have no idea how much that is portable, but upstream should probably now a bit about msvc and advise whether that's a viable option. Well, I would avoid to upset the upstream code that much, a simple use of nan() instead of NAN could propagate correctly. My only doubt is about the possible inclusion of special IEEE values within the final shapefile, a condition that should not be admitted on the basis of the specs. But this is bread for upstream's teeth. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742273: osgearth: unsatisfiable libv8-dev build-dep
On Fri, Mar 21, 2014 at 03:26:04PM +0100, Sebastiaan Couwenberg wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/21/2014 02:53 PM, Julien Cristau wrote: osgearth added an unconditional build-dep on libv8-dev, however that package is only built on little endian archs by the looks of it (it's missing on mips, powerpc, s390x and sparc). Because libv8 is not available on all architectures, I've filed an RM request for osgearth on the architectures where it cannot be built. (#742261) The point is: is it possible to build without libv8-dev on those archs and still having a working product? In that case we could change the b-d chain appropriately. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735814: ossim: FTBFS: configure: error: libtiff support required!
On Sun, Feb 16, 2014 at 12:23:31AM -0800, Hamish wrote: Hi, I thought I'd do an info drop. So in the past years Frankie maintained the package from DebianGIS git on Alioth (now the git repo on spawn-of-Alioth). http://anonscm.debian.org/gitweb/?p=pkg-grass/ossim.git;a=summary and you'll see there that he started on packaging the newer 1.8 version, with libtiff updated, but I think he found the build system too much of a mess so stopped working on it in favour of letting someone else on the DebianGIS team try. Yep, I can confirm that. Also, my main interest at the time was about packaging orfeotoolbox, which still has issues (currently almost solved) in using external stuff. So I stopped the upgrading of the ossim library and tools. Since then OSSIM has moved to cmake and the build system is much improved. A fine Google of Code student named M. Rashad worked on OSSIM last summer, and after the summer was over started on new-generation OSSIM deb packages. Hopefully me Massimo can convince him to join DebianGIS and continue the work there. :-) Anyway it is his packages you'll find in UbuntuGIS's ppa, and yes, they'll be a good starting point for the Mk III version of the OSSIM package in Debian. (see also ancient ossim-old/ in alioth pkg-grass svn repo for MkI) That could be possibily a good target for next orfeo package. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699647: proftpd-mod-geoip: /usr/lib/proftpd/mod_geoip.so missing after upgrade from sid
On Mon, Jan 27, 2014 at 08:35:02PM +0100, Andreas Beckmann wrote: Won't work. Even if you ensure via Conflicts/Pre-Depends that the buggy package gets removed, the postrm script will stay around. You cannot force a package to be purged. (Changing the module filename would work.) which seems to me much better than a ugly hack such as the proposed one. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699647: proftpd-mod-geoip: /usr/lib/proftpd/mod_geoip.so missing after upgrade from sid
On Sun, Jan 26, 2014 at 02:02:30PM +0100, Guillem Jover wrote: Hi! On Sun, 2014-01-26 at 13:06:47 +0100, Andreas Beckmann wrote: what are your deprecation plans for dpkg-query --control-path? This is an actual use-case that requires --control-path in wheezy and jessie. Or is there a better way to achieve this with dpkg? Old postrm is broken and will play havoc after the new package was unpacked. Therefore we have to delete it in the new preinst. I wonder if the correct fix would be simply moving the Breaks/Replaces in the proftpd-basic binary section instead of the proftpd-mod-geoip pkg. That would force removing of the old package before proceeding with the installation of both -basic and the new package. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736334: Sqlite3 backend not more working
On Wed, Jan 22, 2014 at 07:53:47AM -0600, Sébastien Villemot wrote: Le mercredi 22 janvier 2014 à 12:34 +0100, Francesco Paolo Lovergine a écrit : I use gnucash daily, with the sqlite3 backend for all my stuff. Today after updating my this sid box, gnucash is not more able to load any sqlite3 gnucash file (with a message like: no suitable backend found for file .gnucash). All worked perfectly and my files are still usable on other sid boxes. Even cleaning the guile cache gave no results. Curiously the list of today upgrades on this box seem unrelated: [...] 2014-01-22 09:42:28 upgrade libdbd-sqlite3:i386 0.8.3-1+s-5+b1 0.9.0-1 No so unrelated, since you upgraded libdbd-sqlite3 (see above). Does downgrading solve the issue? As written, no. It is still broken after downgrading and cleaned the guile cache. Any other suggestion? -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736334: Sqlite3 backend not more working
On Wed, Jan 22, 2014 at 10:18:59AM -0600, Sébastien Villemot wrote: downgrading solve the issue? As written, no. It is still broken after downgrading and cleaned the guile cache. Any other suggestion? Sorry, I had read your message too quickly, and was confused by your statement that the bug was unrelated to upgrades. What about downgrading libdbi1 ? Ah right, it works by downgrading both libdbd-sqlite3 AND libdbi1. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730754: include/liblas/detail/sha1.hpp is non-free
tags 730754 + patch pending fixed-upstream thanks -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730754: include/liblas/detail/sha1.hpp is non-free
On Mon, Dec 23, 2013 at 01:51:42PM -0600, Howard Butler wrote: This header wasn't used at all, and I have removed it from the tree. https://github.com/libLAS/libLAS/commit/ff7cb669bea35b6129b2ef634c47a4daf9d6951d Sorry it took so long to get on this, Howard Isn't SHA1 used in create_name_based() in guid.hpp? At least in 1.7 -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730754: include/liblas/detail/sha1.hpp is non-free
On Fri, Nov 29, 2013 at 09:37:52AM +0100, Luca Falavigna wrote: Source: liblas Version: 1.2.1-5.1 Severity: serious include/liblas/detail/sha1.hpp is licensed under these terms: // sha1.h // // Copyright (C) 1998 // Paul E. Jones pau...@arid.us // All Rights Reserved. // // This software is licensed as freeware. Permission to distribute // this software in source and binary forms is hereby granted without // a fee. THIS SOFTWARE IS PROVIDED 'AS IS' AND WITHOUT ANY EXPRESSED // OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED // WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. // THE AUTHOR SHALL NOT BE HELD LIABLE FOR ANY DAMAGES RESULTING // FROM THE USE OF THIS SOFTWARE, EITHER DIRECTLY OR INDIRECTLY, INCLUDING, // BUT NOT LIMITED TO, LOSS OF DATA OR DATA BEING RENDERED INACCURATE. Thus, this portion of code is non-free. This issue still appears in the 1.7 (latest) version. A proper way to fix this is adopting/adapting a license-compatible implementation such as: http://tamale.net/sha1 It is not complicated at all and I could provide a patch if Howard had not time to fix this issue upstream. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730755: Missing license information
On Fri, Nov 29, 2013 at 09:37:53AM +0100, Luca Falavigna wrote: Source: liblas Version: 1.2.1-5.1 Severity: serious Some portion of code contain works licensed under different terms than those mentioned in copyright file: * src/gt_wkt_srs.cpp * src/Verson.rc This file is Windows related. I don't think it should be considered in the copyright file. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711650: manpages-it: Please remove dpkg-related man pages now managed directly in the dpkg po4a documentation - see bug #711647
On Sat, Jul 27, 2013 at 08:18:45PM +0200, Beatrice Torracca wrote: I was told that if a package had its own translated man pages (dpkg in this case) those would have taken precedence over the ones on manpages-it, so it would not have been a great problem to have double translated versions. Anyway I did ask for the removal of those man pages from manpages-it, to make things clearer. Beatrice, when moving around translated material, if you know of this kind of situation, it might be pretty helpful to mention it on the submitted bug report. :) Until today, the fix you mentioned is the only viable. If had a look to the package will see that there's a long list of dropped mangpages. That's because properly the manpage and its translations are often seen as a per-project matter. I see no other solution to this issues. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704484: Upgrading from Squeeze to Wheezy breaks proftpd
mod_vroot used to be in proftpd-basic in squeeze, it's moved to a separate package in wheezy. and to be honest I would avoid to add proftpd-mod-vroot as a strict dependency. It is an optional (and experimental) module and the problem would be simply resolved by installing it by hand after a dist-upgrade. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684433: gdal: diff for NMU version 1.9.0-3.1
On Tue, Sep 18, 2012 at 05:50:40PM +0200, gregor herrmann wrote: tags 684433 + pending thanks Dear maintainer, I've prepared an NMU for gdal (versioned as 1.9.0-3.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. Ok, even if I'm starting to think that in jassie we should simply drop ruby support in gdal, because it is simply unmaintained upstream AFAIK. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664547: [volke...@gmx.at: Re: [SpatiaLite-Users] PPC64 builds]
Dear all, that implies that we need to split up quite a lot of source modules. I would hope that it is ok for RMs. Many thanks for the useful suggestion by upstream. - Forwarded message from Volker Froehlich volke...@gmx.at - Date: Sun, 29 Jul 2012 23:15:58 +0200 From: Volker Froehlich volke...@gmx.at To: a.furi...@lqt.it Cc: Francesco P. Lovergine fran...@debian.org Subject: Re: [SpatiaLite-Users] PPC64 builds X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) On Sun, 2012-07-29 at 21:28 +0200, a.furi...@lqt.it wrote: On Thu, 26 Jul 2012 19:38:03 +0200, Volker Froehlich wrote: There's no urgency in this request, but it'd be great if libspatialite would build on PPC64. https://bugzilla.redhat.com/show_bug.cgi?id=663938 On Sat, 28 Jul 2012 17:54:16 +0200, Francesco P. Lovergine wrote: Current version 3.1.0~rc2-1 seems ok on all archs, but for ppc where it fails to build with something that looks like a compiler issue. Based on https://bugs.launchpad.net/ubuntu/+source/spatialite/+bug/1012976 and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28904 it would appear that the issue is that gcc chokes on building massive files on powerpc with PIC (your file compiles sucessfully if -fPIC is removed) and the gcc developers don't consider this a bug. The ubuntu guys suggested soloution is to modify the program that generates the massive C files to generate a collection of smaller C files instead. BINGO :-D I suppose that failing to build on Debian, Ubuntu and Fedora at the same time scores a new record ;-) all right, I've followed the suggestion coming from Ubuntu guys; there is no more a single huge monolithic source. now there are about 40+ reasonably sized sources instead. You'll find attached the latest -RC3 tarball; quite obviously you can download the same identical base code directly from the Fossil repository, if you wish. I've personally tested on Win32 and Fedora 17 amd64, and it works like a charm ;-) let me know if this mega-patch effectively resolves any PPC oddity. bye Sandro Great, it built fine and all tests passed (PPC64 on F17). Just for reference -- the build log: http://ppc.koji.fedoraproject.org/koji/getfile?taskID=641073name=build.log Notice, it's just a scratch build. Thank you two! Volker - End forwarded message - -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664547: spatialite: FTBFS on some archs (test failures)
On Sat, Jul 28, 2012 at 01:54:50PM +0100, peter green wrote: 01234567890123456789012345678901234567890123456789012345678901234567890123456789 Current version 3.1.0~rc2-1 seems ok on all archs, but for ppc where it fails to build with something that looks like a compiler issue. Based on https://bugs.launchpad.net/ubuntu/+source/spatialite/+bug/1012976 and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28904 it would appear that the issue is that gcc chokes on building massive files on powerpc with PIC (your file compiles sucessfully if -fPIC is removed) and the gcc developers don't consider this a bug. The ubuntu guys suggested soloution is to modify the program that generates the massive C files to generate a collection of smaller C files instead. Spatialte and sqlite traditionally use a compact (amalgamation) flavor with all files collated together before building. Maybe that's due to limits in optimization capability? -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682637: qgis: FTBFS: /bin/sh: 1: /usr/bin/pyuic4: not found
reassign 682637 pyqt4-dev-tools thanks This is a problem of current pyuic4 which is trying to use python3 On Tue, Jul 24, 2012 at 11:40:38AM +0200, Lucas Nussbaum wrote: Source: qgis Version: 1.7.4+1.7.5~20120320-1.1 Severity: serious Tags: wheezy sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20120724 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: make[3]: Entering directory `/«BUILDDIR»/qgis-1.7.4+1.7.5~20120320/debian/build' Scanning dependencies of target pluginstaller make[3]: Leaving directory `/«BUILDDIR»/qgis-1.7.4+1.7.5~20120320/debian/build' make[3]: Entering directory `/«BUILDDIR»/qgis-1.7.4+1.7.5~20120320/debian/build' [ 95%] Generating ui_qgsplugininstallerbase.py /bin/sh: 1: /usr/bin/pyuic4: not found make[3]: *** [python/plugins/plugin_installer/ui_qgsplugininstallerbase.py] Error 127 The full build log is available from: http://people.debian.org/~lucas/logs/2012/07/24/qgis_1.7.4+1.7.5~20120320-1.1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. ___ Pkg-grass-devel mailing list pkg-grass-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671063: an update on this bug?
On Sat, Jun 02, 2012 at 06:45:33PM +0200, Thijs Kinkhorst wrote: Hi Francesco, I agree with the submitter that it would be good to update the dh params before the wheezy release. It seems a relatively easy thing to fix and it would resolve this RC bug. This should be done by the administrator on demand with his own choice of parameters. An automatic generation can be done at each new installation (better) or at each upgrade, but anyway that would imply having the same set for years in many cases. A patch for the postinst is welcome anyway. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664282: Processed: Re: Bug#664282: liblas-dev: uninstallable due to changes in libgeotiff-dfsg
On Sun, Apr 22, 2012 at 06:03:20PM +0100, Adam D. Barratt wrote: On Sat, 2012-03-17 at 16:57 +, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: tags 664282 + pending Bug #664282 [liblas-dev] liblas-dev: uninstallable due to changes in libgeotiff-dfsg Added tag(s) pending. That was over a month ago now; is there an ETA for an upload? It is almost ready on the git repository, needs some final checks. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669468: saga: FTBFS: build-dependency not installable: libvigraimpex-dev
On Thu, Apr 19, 2012 at 09:39:19PM +0200, Lucas Nussbaum wrote: The following packages have unmet dependencies: sbuild-build-depends-saga-dummy : Depends: libvigraimpex-dev but it is not going to be installed E: Unable to correct problems, you have held broken packages. apt-get failed. It seems to me that both libtiff4-dev and libtiff5-dev are requested for building which leads to a failure. I think that a simple or dependency would be enough to avoid problems. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664547: spatialite: FTBFS on some archs (test failures)
On Sun, Mar 18, 2012 at 09:14:32PM +0100, Julien Cristau wrote: Source: spatialite Version: 3.0.2~20120302-1 Severity: serious Justification: fails to build from source (but built successfully in the past) See the build logs at https://buildd.debian.org/status/package.php?p=spatialite, failures on armel, armhf, mips, mipsel and powerpc. Cheers, Julien Current version 3.1.0~rc2-1 seems ok on all archs, but for ppc where it fails to build with something that looks like a compiler issue. https://buildd.debian.org/status/fetch.php?pkg=spatialitearch=powerpcver=3.1.0~rc2-1stamp=1333461565 I'm CC d-ppc for suggestions by porters possibly. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663403: FTBFS: cannot find -lgeos
Package: basemap Version: 1.0.2-1 Followup-For: Bug #663403 This is a patch for the problem of re-linking the c++ geos lib: Index: basemap-1.0.2/setup.py === --- basemap-1.0.2.orig/setup.py 2012-03-17 00:04:45.0 +0100 +++ basemap-1.0.2/setup.py 2012-03-17 00:13:03.0 +0100 @@ -77,14 +77,14 @@ extensions.append(Extension(_geoslib,['src/_geoslib.c'], library_dirs=geos_library_dirs, include_dirs=geos_include_dirs, -libraries=['geos_c','geos'])) +libraries=['geos_c'])) else: #extensions.append(Extension(mpl_toolkits.basemap._geoslib,['src/_geoslib.c'], extensions.append(Extension(_geoslib,['src/_geoslib.c'], library_dirs=geos_library_dirs, runtime_library_dirs=geos_library_dirs, include_dirs=geos_include_dirs, -libraries=['geos_c','geos'])) +libraries=['geos_c'])) # Specify all the required mpl data # create pyproj binary datum shift grid files. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663646: spatialite-gui: FTBS due to geos relinking
Package: spatialite-gui Version: 1.2.1-2+b2 Severity: serious Justification: fails to build from source (but built successfully in the past) On all archs spatialite-gui links both geos and geos_c (it does not use geos-config even): Exif.cpp:88:8: warning: variable 'ok_gpsSatellites' set but not used [-Wunused-but-set-variable] g++ -c TextCsv.cpp -I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -Wall -Wextra -Wno-ctor-dtor-privacy -fno-strict-aliasing -I/usr/include -D_LARGE_FILE=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 TextCsv.cpp: In function 'text_buffer* text_parse(const char*, const char*, bool, char, char, char)': TextCsv.cpp:296:7: warning: variable 'errs' set but not used [-Wunused-but-set-variable] g++ -c Objects.cpp -I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -Wall -Wextra -Wno-ctor-dtor-privacy -fno-strict-aliasing -I/usr/include -D_LARGE_FILE=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 g++ -c MetadataInit.cpp -I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -Wall -Wextra -Wno-ctor-dtor-privacy -fno-strict-aliasing -I/usr/include -D_LARGE_FILE=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 g++ Main.o TableTree.o QueryView.o ResultSetView.o BlobExplorer.o Dialogs.o Shapefiles.o Network.o Exif.o TextCsv.o Objects.o MetadataInit.o -o spatialite-gui -L/usr/lib/x86_64-linux-gnu -pthread -L/usr/lib/x86_64-linux-gnu -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8 -lspatialite -lgeos_c -lgeos -lproj -lrasterlite -lsqlite3 /usr/bin/ld: cannot find -lgeos collect2: ld returned 1 exit status make[2]: *** [spatialite-gui] Error 1 make[2]: Leaving directory `/build/buildd-spatialite-gui_1.2.1-2+b2-amd64-byVBA0/spatialite-gui-1.2.1' dh_auto_build: make -j1 -f Makefile-linux returned exit code 2 make[1]: *** [override_dh_auto_build] Error 2 make[1]: Leaving directory `/build/buildd-spatialite-gui_1.2.1-2+b2-amd64-byVBA0/spatialite-gui-1.2.1' make: *** [build] Error 2 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640819: Fix jpeg library detection for multiarch location
On Mon, Mar 05, 2012 at 10:43:27AM +0100, Moritz Mühlenhoff wrote: checking for dlfcn.h... yes checking malloc.h usability... yes checking malloc.h presence... yes checking for malloc.h... yes checking getopt.h usability... yes checking getopt.h presence... yes checking for getopt.h... yes checking dirent.h usability... yes checking dirent.h presence... yes checking for dirent.h... yes checking libtar.h usability... yes checking libtar.h presence... yes checking for libtar.h... yes checking zlib.h usability... yes checking zlib.h presence... yes checking for zlib.h... yes HAVE ZLIB = LIBTIFF_INCLUDE_PATH= -I/usr/include LIBTIFF_LIB_PATH= -L/usr LIBTIFF_LIBS= -ltiff JPEG_TOP: /usr ERROR: libjpeg not found! configure: error: jpeg support required! make: *** [debian/stamp-autotools] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 I know, a few programs are all sharing the same code snippet that tries to find the library location automagically within a few well-known dirs. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661914: FTBFS
On Fri, Mar 02, 2012 at 03:55:13PM +0100, Moritz Muehlenhoff wrote: Package: mapserver Version: 6.0.1-2 Severity: serious Your package fails to build from source: checking for vsnprintf... yes MapServer Version from mapserver.h: '6.0.1' checking if pkg-config path is provided... checking for pkg-config... /usr/bin/pkg-config checking for Freetype2.x in /usr... checking for FT_Init_FreeType in -lfreetype... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking ft2build.h usability... yes checking ft2build.h presence... yes checking for ft2build.h... yes configure: checking where Zlib is installed... checking for zlibVersion in -lz... yes using libz from system libs (-DUSE_ZLIB). configure: checking where PNG is installed... checking for png_init_io in -lpng... yes checking png.h usability... yes checking png.h presence... yes checking for png.h... yes using libpng from system libs. checking setjmp.h usability... yes checking setjmp.h presence... yes checking for setjmp.h... yes configure: checking where GIF is installed... checking for DGifOpenFileHandle in -lgif... yes checking gif_lib.h usability... yes checking gif_lib.h presence... yes checking for gif_lib.h... yes using libgif from system libs. configure: checking whether we should include JPEG support... configure: error: Could not find jpeglib.h or libjpeg.a/libjpeg.so/libjpeg.dylib in /usr. make: *** [configure-stamp] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Note that while it is straighforward fixing this specific issue, and also building correctly with current GEOS C library, current mapserver has another issue due to recent Php 5.4 migration. This is the fix, which could be useful for other programs too: https://bugs.php.net/bug.php?id=59731 to be included ASAP. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661839: gmt: rebuild against new libnetcdf
reassign 661839 netcdf found 661839 4.1.3-2 notfound 661839 4.1.3-3 thanks -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661717: libnetcdf6 doesn't provide libnetcdf.so.6
On Wed, Feb 29, 2012 at 11:05:29PM +0600, Andrey Rahmatullin wrote: Package: libnetcdf6 Version: 1:4.1.3-2 Severity: serious Packages such as libgdal1-1.7.0 contain binaries linked against libnetcdf.so.6 and depend on libnetcdf6. But as libnetcdf.so.6 is now contained in libnetcdfc6 and libnetcdf6 doesn't depend on it, that packages break. Workaround: install libnetcdfc6 manually. Sorry the true fix is dropping the linetcdf6 dummy package provided in the new 4.1.3 version and waiting for the usual set of bNMUs for migrating to the new soname and libraries set. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661553: trying to overwrite '/usr/lib/libnetcdf_c++.so.4', which is also in package libnetcdf4 1:3.6.3-1
On Mon, Feb 27, 2012 at 10:32:53PM +0100, Soeren Sonnenburg wrote: Package: libnetcdfc++5 Version: 1:4.1.1-8+b1 Severity: grave on upgrade I get Preparing to replace libnetcdfc++5 1:4.1.1-8+b1 (using .../libnetcdfc++5_1%3a4.1.3-1_amd64.deb) ... Unpacking replacement libnetcdfc++5 ... dpkg: error processing /var/cache/apt/archives/libnetcdfc++5_1%3a4.1.3-1_amd64.deb (--unpack): trying to overwrite '/usr/lib/libnetcdf_c++.so.4', which is also in package libnetcdf4 1:3.6.3-1 Uhm, I'm supposing you put on hold the old 3.6.3 libraries, don't you? -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586149: Please consider the usage of update-alternatives for hdf5 libraries
On Sun, Feb 26, 2012 at 12:34:54AM -0500, Adam C Powell IV wrote: There's a better way to do this by just having different shared library file names and sonames for each of the shared library packages. Then the -dev packages can conflict, while one can install multiple packages using the different shared libraries simultaneously, not one-at-a-time as update-alternatives would do. Note this would also allow simultaneous install of hdf5-tools and libhdf5-mpi-dev which is required to build several HDF5 reverse-depends, such as med-fichier. This represents a major regression vs. 1.8.6 and should be fixed as soon as possible. Are you proposing to install conflicting -dev packages with identical symlinks for ensuring transparent building in serial/parallel? I'm not sure that would not break in a very odd and tricky way intricated dependencies (e.g. building using headers of third parties that depend on and include different hdf5 flavors). I would avoid that. It is much more sane diverging headers names too and patch what ever is needed to be patched to use the right flavor. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658310: FTBFS: Header hdfeos5.h or the compiled hdfeos5 library is not found
On Sat, Feb 11, 2012 at 06:35:31PM +, peter green wrote:
The real problem is revealed by mkmf.log
have_library: checking for main() in
-lhe5_hdfeos... no gcc -o conftest -I.
-I/usr/lib/ruby/1.8/x86_64-linux -I. -I/usr/include/hdf-eos5
-I/usr/lib/include -I/usr/lib/ruby/1.8/x86_64-linux
-I/usr/lib/ruby/vendor_ruby/1.8/x86_64-linux -fno-strict-aliasing
-g -g -O2 -fPIC conftest.c -L. -L/usr/lib -L/usr/lib/lib
-L/usr/lib/ruby/1.8/x86_64-linux
-L/usr/lib/ruby/vendor_ruby/1.8/x86_64-linux -L. -rdynamic
-Wl,-export-dynamic -lgctp -lruby1.8-static -lhe5_hdfeos -lgctp
-lpthread -lrt -ldl -lcrypt -lm -lc
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libhe5_hdfeos.so:
undefined reference to `H5DSis_attached'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libhe5_hdfeos.so:
undefined reference to `H5DSset_scale'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libhe5_hdfeos.so:
undefined reference to `H5DSattach_scale'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libhe5_hdfeos.so:
undefined reference to `H5DSis_scale' collect2: ld returned 1 exit
status checked program was: /* begin */ 1: /*top*/ 2: int main() {
return 0; } 3: int t() { void ((*volatile p)()); p = (void
((*)()))main; return 0; } /* end */ gcc -o conftest -I.
-I/usr/lib/ruby/1.8/x86_64-linux -I. -I/usr/include/hdf-eos5
-I/usr/lib/include -I/usr/lib/ruby/1.8/x86_64-linux
-I/usr/lib/ruby/vendor_ruby/1.8/x86_64-linux -fno-strict-aliasing
-g -g -O2 -fPIC conftest.c -L. -L/usr/lib -L/usr/lib/lib
-L/usr/lib/ruby/1.8/x86_64-linux
-L/usr/lib/ruby/vendor_ruby/1.8/x86_64-linux -L. -rdynamic
-Wl,-export-dynamic -lgctp -lruby1.8-static -lhe5_hdfeos -lgctp
-lpthread -lrt -ldl -lcrypt -lm -lc
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libhe5_hdfeos.so:
undefined reference to `H5DSis_attached'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libhe5_hdfeos.so:
undefined reference to `H5DSset_scale'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libhe5_hdfeos.so:
undefined reference to `H5DSattach_scale'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libhe5_hdfeos.so:
undefined reference to `H5DSis_scale' collect2: ld returned 1 exit
status checked program was: /* begin */ 1: /*top*/ 2: int main() {
return 0; } 3: int t() { main(); return 0; } /* end */
It seems it is no longer possible to link against libhe5_hdfeos without
including some other library (or possiblly at all)
Alastair McKinstry please advise if this is a bug in ruby-hdfeos5 or in
hdf-eos5
It is evident that libhe5_hdfeos is using hdf5 high-level library, but not
linking it:
$ objdump -T /usr/lib/i386-linux-gnu/libhe5_hdfeos.so.0 |grep H5D
DF *UND* H5Dcreate1
DF *UND* H5Dread
D *UND* H5DSis_attached
DF *UND* H5Dget_type
DF *UND* H5Dvlen_reclaim
DF *UND* H5Dclose
DF *UND* H5Dwrite
D *UND* H5DSset_scale
D *UND* H5DSattach_scale
D *UND* H5DSis_scale
DF *UND* H5Dget_space
DF *UND* H5Dget_create_plist
DF *UND* H5Dextend
DF *UND* H5Dopen1
So it is an issue in hdf-eos5.
--
Francesco P. Lovergine
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658281: Bug#657949: Cannot install libhdf5-mpi-dev and libnetcdf-dev
On Wed, Feb 08, 2012 at 02:32:07PM +, Alastair McKinstry wrote: Hi Francesco, Do you recommend that we build the next NetCDF from 4.1.1 or should we use the 4.1.3 from experimental as the base? Regards Alastair AFAIK Sylvestre is going to reset the dependencies chain in hdf5 to avoid that kind of problem. About 4.1.3 in experimental, it still needs a bit of work, and I'm going to split in separate packages current netcdf 4.1.1 before, in order to have a decent organization of all solibs to have a smooth migration to 4.1.3. You have free access to the git repository, so a branch can be prepared for having a parallel flavor too. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658281: Bug#657949: Cannot install libhdf5-mpi-dev and libnetcdf-dev
On Tue, Feb 07, 2012 at 09:28:00AM +, Alastair McKinstry wrote: On 2012-02-02 01:43, Steve M. Robbins wrote: Hi, I'd like to contribute towards a solution for this. I'm forwarding to debian-devel to get some others' ideas. Naively, I don't understand why netcdf can't offer multiple variants, just as hdf5 does. Or, at least, one package libnetcdf-mpi-dev that links with the default MPI implementation. I am not involved in the netcdf. You should report a bug on this package. I'm prepared to do so, but I'd first like to get agreement that netcdf is where the problem lies. Netcdf maintainers, please chime in! I think we can no longer live in the status quo (see all the blockers of #631019), so something has to give. Even if it is painful, perhaps Debian could pioneer something and pass patches back to upstream? Thoughts? -Steve As of now, I have several packages (eg ADIOS, CDO) that used to build against netcdf and libhdf5-mpi-dev that don't. Without fixes to netCDF (I appreciate what Francesco says about netcdf upstream not giving the libraries proper names), there needs to be a regression: either the packages build with netcdf but no MPI, or MPI but no netcdf. The problem is the following: with latest update to hdf5, the chain of dependencies changed, so that now libnetcdf6 depends on the pure serial version of hdf5, while the previous one depended on serial or parallel: Version: 1:4.1.1-6+b1 Depends: libc6 (= 2.7), libcurl3-gnutls (= 7.16.2), libgcc1 (= 1:4.1.1), libgfortran3 (= 4.3), libhdf5-7 (= 1.8.7), libquadmath0 (= 4.6), libstdc++6 (= 4.4.0) Version: 1:4.1.1-6 Depends: libc6 (= 2.7), libcurl3-gnutls (= 7.16.2-1), libgcc1 (= 1:4.1.1), libgfortran3 (= 4.3), libhdf5-serial-1.8.4 | libhdf5-1.8.4, libquadmath0 (= 4.6), libstdc++6 (= 4.4.0) So at least at packaging level, that should be fixed to follow the previous criteria. That said, indeed NetCDF provides nc_create_par and nc_open_par in both serial and parallel versions, but needs to be built with --enable-parallel to take advantage of parallel I/O in HDF5, else it works in pure serial mode. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658307: Bug#657949: Cannot install libhdf5-mpi-dev and libnetcdf-dev
On Wed, Feb 01, 2012 at 07:43:31PM -0600, Steve M. Robbins wrote: The solution is having upstream adopting a sane naming scheme for mpi-enabled flavor libraries instead of using always the same names for all. Francesco, please clarify: are you speaking of the hdf5 upstream or the netcdf upstream? (Both?) I mean first of all hdf5 upstream. Note that anyway both them use different APIs for serial and parallel programming models. So having the same library names for completely different things IMHO is defective by design and confusing. As a principle we could install only mpi-enabled libraries (the serial model and API could be anyway used) but that would imply that people should coexist with such kind of stuff installed always, if used or not. Also some serial-only supports could be missed and anomalies appearing here and there: both them are quite complicated beasts. I would avoid to take such kind of decision without a deep analysis. What problem are you trying to solve with that: co-installable -dev packages or just coinstallable lib packages? Unfortunately they were still not available for that at the time of my last poking. Diverging from upstream is not a good idea, so we still have to live in a non perfect world... I think we can no longer live in the status quo (see all the blockers of #631019), so something has to give. Even if it is painful, perhaps Debian could pioneer something and pass patches back to upstream? Thoughts? I'm afraid it is quite difficult having such kind of proposal accepted by upstreams. It implies changes for both them in library use, that they could be not ready to introduce. In 2009 I asked about that in hdf-forum without a positive answer. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642566: saga: diff for NMU version 2.0.7+dfsg-2.1
On Tue, Feb 07, 2012 at 12:51:36AM +0100, gregor herrmann wrote: tags 642566 + pending thanks Dear maintainer, I've prepared an NMU for saga (versioned as 2.0.7+dfsg-2.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. Interestingly enough, I'm not currently able to build it by git-buildpackage due to an error at patching time. The main co-maintainer is currently unavailable, so feel free to upload your NMU which is straight enough and already applied on the git repo since ages. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642566: saga: diff for NMU version 2.0.7+dfsg-2.1
On Tue, Feb 07, 2012 at 05:21:30PM +0100, gregor herrmann wrote: The main co-maintainer is currently unavailable, so feel free to upload your NMU which is straight enough and already applied on the git repo since ages. Ok, thanks. Cheers, gregor I finally get rid of the problem with the git archive, so I'm going to upload that fix and the upgrade to 2.0.8 upstream version too along with some other pending changes. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656103: libnetcdf7: fails to upgrade from 'sid' - trying to overwrite ...
On Sun, Feb 05, 2012 at 03:19:56PM +0100, Andreas Beckmann wrote: Followup-For: Bug #656103 Hi, during a test with piuparts I noticed your package fails to upgrade from 'sid' to 'experimental'. It installed fine in 'sid', then the upgrade to 'experimental' fails because it tries to overwrite other packages files without declaring a replaces relation. See policy 7.6 at http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces From the attached log (scroll to the bottom...): Selecting previously unselected package libnetcdf7. (Reading database ... 6801 files and directories currently installed.) Unpacking libnetcdf7 (from .../libnetcdf7_1%3a4.1.3-1~exp1_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/libnetcdf7_1%3a4.1.3-1~exp1_amd64.deb (--unpack): trying to overwrite '/usr/lib/libnetcdff.so.5', which is also in package libnetcdf6 1:4.1.1-6+b1 Library packages should not ship multiple shared libraries, especially if they have different sonames. So you should move libnetcdff.so.* into its own libnetcdff5 package. Yep, it is well known. It still needs major revision before a definite release in unstable. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658491: closed by Francesco P. Lovergine fran...@debian.org (Re: Bug#658491: hdf5-tools programs cannot find libhdf5.so.7)
On Sat, Feb 04, 2012 at 11:25:29AM +0100, Giuseppe Bilotta wrote: Thanks for the reply. However, I do believe this is still a bug in the dependency specification, since if the hdf5-tools package depends on the *latest* version of the libhdf5-1.8 package, then it should explicitly do so, to prevent installation when the correct version cannot be installed because e.g. it is being held back automatically by some other package (paraview in my case). This is an issue already raised. My own opinion is that any upgrade should be done in a smooth way, allowing more than a version to cohexist at the same time, until all rdepends are rebuilt. After that the old one could be dropped. Sylvestre managed that differently by requiring explicit rebuilding and conflicts, for a good reason, I think (but I did not have time to understand what that reason is, and now it is anyway done, so it is quite pointless understanding why and if a better approach was available). The result is what you are experiencing: all rdepends need to be rebuilt and in sync, else you need to keep packages on hold until rebuilding completed for all of them. The dependencies specification per se is correct (and note that the packaging changed in 1.8.4 - 1.8.8) -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646446: gpsdrive: FTBFS: mapnik.cpp:33:15: error: 'mapnik::Image32' has not,
On Sat, Dec 03, 2011 at 01:42:05PM -0800, Hamish wrote: Hamish wrote: by the way, updated 2.11 packages for GpsDrive are available from www.gpsdrive.de for debian releases, and http://download.osgeo.org/livedvd/data/gpsdrive/ for Ubuntu releases. If anyone wants a copy built for Squeeze with full Mapnik+PostGIS OSM support just send me an email. Francesco wrote: I did not check lately but it seems packages there are missing source which is a pity: we need to provide a source package in main from scratch currently. I guess you mean Joerg's repo + build cluster: http://www.gpsdrive.de/debian/ http://www.gpsdrive.de/build_cluster/results.shtml official source for version 2.11 is here: http://www.gpsdrive.de/packages/gpsdrive-2.11.tar.gz No I meant that .deb source of 2.11 is missing, only a binary version is available. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646446: gpsdrive: FTBFS: mapnik.cpp:33:15: error: 'mapnik::Image32' has not,
On Thu, Dec 01, 2011 at 08:37:38PM -0800, Hamish wrote: by the way, updated 2.11 packages for GpsDrive are available from www.gpsdrive.de for debian releases, and http://download.osgeo.org/livedvd/data/gpsdrive/ for Ubuntu releases. If anyone wants a copy built for Squeeze with full Mapnik+PostGIS OSM support just send me an email. I did not check lately but it seems packages there are missing source which is a pity: we need to provide a source package in main from scratch currently. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648373: [CVE-2011-4130] Use-after-free issue
tag 648373 + pending tag 648373 + patch thanks On Thu, Nov 10, 2011 at 09:31:17PM +0100, Florian Weimer wrote: Package: proftpd-dfsg Version: 1.3.3a-6squeeze1 Severity: grave Tags: security A use-after-free issue has been discovered in ProFTPd: http://bugs.proftpd.org/show_bug.cgi?id=3711 It seems that squeeze is vulnerable, too. I haven't checked the code in lenny yet. I have 1.3.3a-6squeeze3 ready for squeeze with the required fix. Waiting for a secteam go signal, just in case. -- Francesco P. Lovergine #! /bin/sh /usr/share/dpatch/dpatch-run ## 3711.dpatch by Francesco Paolo Lovergine fran...@debian.org ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: No description. @DPATCH@ diff -urNad '--exclude=CVS' '--exclude=.svn' '--exclude=.git' '--exclude=.arch' '--exclude=.hg' '--exclude=_darcs' '--exclude=.bzr' proftpd-dfsg~/src/main.c proftpd-dfsg/src/main.c --- proftpd-dfsg~/src/main.c2011-11-11 12:23:30.0 +0100 +++ proftpd-dfsg/src/main.c 2011-11-11 12:39:53.0 +0100 @@ -706,6 +706,10 @@ _dispatch(cmd, LOG_CMD_ERR, FALSE, NULL); pr_response_flush(resp_err_list); + + /* Restore any previous pool to the Response API. */ + pr_response_set_pool(resp_pool); + return success; } @@ -761,6 +765,9 @@ break; default: +/* Restore any previous pool to the Response API. */ +pr_response_set_pool(resp_pool); + errno = EINVAL; return -1; } signature.asc Description: Digital signature
Bug#648373: [CVE-2011-4130] Use-after-free issue
On Fri, Nov 11, 2011 at 07:56:02PM +0100, Florian Weimer wrote: * Francesco P. Lovergine: A use-after-free issue has been discovered in ProFTPd: http://bugs.proftpd.org/show_bug.cgi?id=3711 It seems that squeeze is vulnerable, too. I haven't checked the code in lenny yet. I have 1.3.3a-6squeeze3 ready for squeeze with the required fix. Waiting for a secteam go signal, just in case. Thanks. I trust that the call is at the right place, I find the code somewhat confusing. Please upload with the usual caveats (1.3.3a-6squeeze2 as version number, squeeze-security suite, host security-master). About lenny, it appears the 1.3.1 version still had not the feature of dispatching control commands while data transfers are going on. So the whole pool mechanism is not operational and the issue does not apply at all. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638294: Blocked upgrade of libdap11
On Tue, Aug 30, 2011 at 11:56:48AM +0200, Francesco P. Lovergine wrote: On Tue, Aug 30, 2011 at 11:39:40AM +0200, Julien Cristau wrote: So what? Some reverse build-deps like gdal are still waiting in the dark for a rebuild ... Last I checked the API change in new libdap makes gdal 1.7 unbuildable anyway, so that will need a source upload. Thanks, let me check about that. Alastair, should I consider the current libdap version in unstable or the experimental one to prepare a fix? Folks, gdal is now fixed for libdap 3.10+, would you please upload a definitive version for libdap ASAP in sid ? -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638294: Blocked upgrade of libdap11
On Fri, Aug 26, 2011 at 08:08:06PM +0200, Julien Cristau wrote: On Fri, Aug 26, 2011 at 11:43:10 +0100, Alastair McKinstry wrote: Hi, I have an experimental libdap11 package to fix this in Experimental. Can the release team please review this ? Package: libdap11 Conflicts: libdap10 Breaks: libdap10 Replaces: libdap10 Why? None of this seems necessary unless I'm missing something. Package: libdapclient3 Conflicts: libdap10 I think this should have Replaces (and possibly Breaks instead of Conflicts). Same with libdapserver7. Cheers, Julien So what? Some reverse build-deps like gdal are still waiting in the dark for a rebuild ... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638294: Blocked upgrade of libdap11
On Tue, Aug 30, 2011 at 11:39:40AM +0200, Julien Cristau wrote: So what? Some reverse build-deps like gdal are still waiting in the dark for a rebuild ... Last I checked the API change in new libdap makes gdal 1.7 unbuildable anyway, so that will need a source upload. Thanks, let me check about that. Alastair, should I consider the current libdap version in unstable or the experimental one to prepare a fix? -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628275: librasterlite: FTBFS: rasterlite_wavelet.c:183:45: error: 'eps_block_header' has no member named 'gs'
On Sat, May 28, 2011 at 01:57:59PM +0200, Lucas Nussbaum wrote: Source: librasterlite Version: 1.0-2 Severity: serious Tags: wheezy sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20110528 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. This is the same error recently fixed in gdal due to 0.9.1 migration. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618888: This report is questionable
0m30.7s ERROR: FAIL: Package purging left files on system: /home/ftp/welcome.msg not owned /var/log/proftpd owned by: proftpd-basic /var/log/proftpd/controls.log not owned /var/log/proftpd/proftpd.log not owned I do not agree about this report. The /home/ftp location is the home of the traditional 'ftp' anonymous user and removing it or any of the (possibly) custom files there is out of question, even at purge time IMHO. That said, I could simply remove completely the management of a generic anonymous account, leaving to admin all duties about that. That would render piuparts happy, and some admins too possibly. Maybe some other admins won't appreciate the change, who knows? Note also that indeed creating a system user for that is not always something that works, due to possibly exotic auth schemes. PS: I think you are pointing only about that, and not the log files of course. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617240: The same error is present in other packages too
severity 619060 grave severity 619085 grave merge 619060 617240 merge 619085 617240 thanks Hi all all those packages present the same error. The common denominator seems libmsqlclient. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615528: [sylves...@debian.org: HDF5 Transition]
FYI, it impacts a few packages. Note also that current gdal and tcltk transitions impact as well a few packages. I'm expecting long times before most of our core packages will enter testing and also simply being installable all together. Please DON'T open superfluous reports about uninstallable stuff, it is is perfectly known and expected. They will only take time to developers for closing and create confusion. This is unstable, not squeeze. - Forwarded message from Sylvestre Ledru sylves...@debian.org - Date: Sun, 27 Feb 2011 21:15:04 +0100 From: Sylvestre Ledru sylves...@debian.org To: debian-rele...@lists.debian.org Cc: fran...@debian.org Subject: HDF5 Transition X-Mailer: Evolution 2.30.3 Hello guys, Just to let you know that we are planning to upload a new upstream release of the hdf5 libraries (1.8.4 = 1.8.6). We will switch the API to the version 1.8 (from the 1.6). It might break some packages but the fix is easy (just a #define). We will also change the package name because it is very likely that the API/ABI changed... We are not in an hurry but it is a pretty important package [1] [2]. How do you want to processed ? Cheers, Sylvestre [1] $ apt-cache rdepends libhdf5-serial-1.8.4 libhdf5-serial-1.8.4 Reverse Depends: |code-saturne-bin |udav |paraview |octave-ann |libmgl5 |libjhdf5-jni |python-h5py |grads |dynare |cdo |shogun-r |shogun-python |shogun-python-modular |shogun-octave |shogun-octave-modular |shogun-elwms |shogun-cmdline |libshogunui6 |libshogun9 |scilab-minimal-bin |scilab-full-bin |octave-communications |libmgl5 |libcgns2 |cgns-convert |gnudatalanguage |libgdal1-1.7.0 |libgdal-ruby1.8 |libgdal-perl |yorick-hdf5 |udav |tessa |tessa-mpi |python-silo |libsilo0 |libsilo-bin |shogun-r |shogun-python |shogun-python-modular |shogun-octave |shogun-octave-modular |shogun-elwms |shogun-cmdline |libshogunui5 |libshogun8 |octave-sp |sdpam |scilab-minimal-bin |scilab-full-bin |r-cran-hdf5 |python-tables |python-gpiv |octave-plplot |octave-pfstools |paraview |octave3.2 |octave-xraylib |octave-symband |octave-sockets |octave-secs2d |octave-secs1d |octave-pdb |octave-optiminterp |octave-octgpr |octave-nlwing2 |octave-multicore |octave-miscellaneous |octave-linear-algebra |octave-gsl |octave-ftp |octave-fixed |octave-econometrics |octave-communications |octave-combinatorics |octave-audio |octave-ad |netcdf-bin |libnetcdf6 |mpb |mpb-mpi |meep |meep-mpi |libmeep6 |libmeep-mpi6 |libmgl5 |python-mapscript |php5-mapscript |perl-mapscript |mapserver-bin |libmapscript-ruby1.9.1 |libmapscript-ruby1.8 |cgi-mapserver |python-vigra |libvigraimpex2 |libpdl-io-hdf5-perl |libgpiv3 |libgpiv-mpi3 |libcgns2 |cgns-convert |labplot |libjhdf5-jni libhdf5-serial-dev |hdf5-tools |libhe5-hdfeos0 |h5utils |python-h5py |grads |gnudatalanguage |libgdal1-1.6.0 |libgdal-ruby1.8 |libgdal-perl |dynare |cdo [2] $ apt-cache rdepends libhdf5-openmpi-1.8.4 libhdf5-openmpi-1.8.4 Reverse Depends: libmedc1 libmed1 libslepc3.0.0 minc-tools libminc2-1 libluminate7 illuminator-demo libslepc3.1 salome salome-test salome-extras salome-examples libpetsc3.1 getdp ecs code-saturne-bin libslepc3.0.0 python-petsc4py libpetsc3.1 minc-tools libminc2-1 meep-openmpi libmeep-openmpi6 meep-mpich libmeep-mpich6 libmedimportcxx0 libmedimport0 libmedc1 libmed1 libmed-tools libluminate7 illuminator-demo libhdf5-openmpi-dev getdp ecs python-dolfin libdolfin0 code-sat - End forwarded message - -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612264: [Pkg-tcltk-devel] Bug#612264: tk-tile and tk colliding dir
severity 612264 normal thanks I'm reducing the severity of this bug because I tried to install/remove/reinstall in various order tk-tile and tk-dev without problems. So the issue could be due to some odd setup on the original box. While investigating the problem there, it is better changing the severity, indeed. On Mon, Feb 07, 2011 at 10:41:11AM +0100, Francesco P. Lovergine wrote: On Mon, Feb 07, 2011 at 12:01:40PM +0300, Sergei Golovan wrote: On Mon, Feb 7, 2011 at 11:48 AM, Francesco Paolo Lovergine fran...@debian.org wrote: Package: tcl-dev Version: 8.4.16-2 Severity: serious Unpacking replacement tcl-dev ... dpkg: error processing /var/cache/apt/archives/tcl-dev_8.5.0-2_all.deb (--unpack): trying to overwrite '/usr/include/tcl', which is also in package tk-tile 0.8.2-2.1 configured to not write apport reports Processing triggers for man-db ... /usr/include/tcl in tcl-dev is a symlink to /usr/include/tcl8.5 currently. I think that it's better to keep it this way. So, I'd treat this bug as a tk-tile bug. Uhm, one would not expect tk-tile or any other non-core tcl package has to manage /usr/include/tcl. Instead it is expected the default tcltk package is able to cope with transitioning without glitches. So I'm not sure if some counter-measure should be instead adopted there... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612264: [Pkg-tcltk-devel] Bug#612264: tk-tile and tk colliding dir
On Mon, Feb 07, 2011 at 12:01:40PM +0300, Sergei Golovan wrote: On Mon, Feb 7, 2011 at 11:48 AM, Francesco Paolo Lovergine fran...@debian.org wrote: Package: tcl-dev Version: 8.4.16-2 Severity: serious Unpacking replacement tcl-dev ... dpkg: error processing /var/cache/apt/archives/tcl-dev_8.5.0-2_all.deb (--unpack): trying to overwrite '/usr/include/tcl', which is also in package tk-tile 0.8.2-2.1 configured to not write apport reports Processing triggers for man-db ... /usr/include/tcl in tcl-dev is a symlink to /usr/include/tcl8.5 currently. I think that it's better to keep it this way. So, I'd treat this bug as a tk-tile bug. Uhm, one would not expect tk-tile or any other non-core tcl package has to manage /usr/include/tcl. Instead it is expected the default tcltk package is able to cope with transitioning without glitches. So I'm not sure if some counter-measure should be instead adopted there... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611492: python-qgis: missing dependency on python-central
On Sat, Jan 29, 2011 at 09:38:42PM -0800, Hamish wrote: Hi, I see the control files have moved out of DebianGIS's alioth svn[1]. where has it gone? moved to git or is the upstream svn repo[1] being used directly? [0] http://svn.debian.org/wsvn/pkg-grass/packages/ [1] http://trac.osgeo.org/qgis/browser/trunk/qgis/debian http://pkg-grass.alioth.debian.org/qgis/qgis.git Currently it is a fork of the 1.4 qgis tree, managed by git-svn. Due to known limitations in git-svn, it is not possible merging from other repos, but I will move to a better repo organization soon, in order to merge with the upstream 1.6 version. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611492: [DebianGIS-dev] Bug#611492: python-qgis: missing dependency on python-central
tag 611492 pending thanks On Sat, Jan 29, 2011 at 11:47:05PM +0100, Jakub Wilk wrote: Package: python-qgis Version: 1.4.0+12730-4 Severity: serious Justification: Policy 3.5 In a clean sid chroot: $ python -c 'import qgis' Traceback (most recent call last): File string, line 1, in module ImportError: No module named qgis -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609255: KDE upgrading
On Thu, Jan 13, 2011 at 08:37:53PM +0100, Julien Cristau wrote: (Non-exhaustive) testing shows that this allows the upgrade to proceed and get an acceptable (or even good) result, even when kwin styles are installed. These style packages are left installed after the upgrade, but that shouldn't hurt anything since they're basically cruft which can be cleaned up afterwards. Uhm I don't know if the following is expected. Shouldn't kwin dist-upgrade directly at this point? frankie@klecker:~$ LANG=C sudo apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages have been kept back: bitlbee kwin 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded. frankie@klecker:~$ LANG=C sudo apt-get install kwin Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: kwin : Depends: kde-window-manager but it is not going to be installed E: Broken packages frankie@klecker:~$ LANG=C sudo apt-get install kde-window-manager Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libkdecorations4 libkwineffects1a The following packages will be REMOVED: kwin The following NEW packages will be installed: kde-window-manager libkdecorations4 libkwineffects1a 0 upgraded, 3 newly installed, 1 to remove and 1 not upgraded. Need to get 2615 kB of archives. After this operation, 3777 kB of additional disk space will be used. Do you want to continue [Y/n]? -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609703: proftpd-basic: sql_prepare_where() buffer overflow (Bug#3536)
severity 609703 normal thanks On Tue, Jan 11, 2011 at 07:18:23PM +0100, Sebastian Scheible wrote: Package: proftpd-basic Version: 1.3.1-17lenny4 Severity: critical Tags: security Justification: root security hole As described in http://www.h-online.com/open/news/item/Phrack-hole-closed-in-ProFTPD-1156782.html upstream version 1.3.3d fixes a remote root exploit in previous versions (proftpd bug Bug#3536). Quote: A buffer overflow in the function sql_prepare_where() allows attackers to remotely execute arbitrary code on the server. Also note that in order to exploit the sql_prepare_where() bug, you need an unfixed CVE-2009-0542, which is fixed since ages in Lenny. So the gravity of this problem is greatly reduced. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609255: KDE upgrading
On Wed, Jan 12, 2011 at 03:44:31PM +0100, Julien Cristau wrote: On Wed, Jan 12, 2011 at 14:34:12 +0100, Francesco P. Lovergine wrote: I'm afraid I'm a bit concerned about this metapackage stuff. Why weren't the metapackages from lenny kept around to help upgrades, with kde and kde-core depending e.g. on the new kde-standard metapackage? Francesco, care to share details of your upgrade? What packages were installed pre-upgrade, log from apt, …? I could provide a long dpkg log, but I upgraded with more rounds of apt-get due to some intermediate failures (not kde related), the whole workflow is quite not easy to be understood. /me too does not understand why a clean upgrade path has not been provided for the required meta-package. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603986: [DebianGIS-dev] Bug#603986: qgis crashes on startup on PowerPC
On Mon, Dec 20, 2010 at 11:16:25AM +0100, Michel Dänzer wrote: I think a good next step would be to resolve why rebuilding packages locally seems to work around the problem for Steve but not for you. Which package(s) exactly are you each rebuilding locally and installing from the local build? In particular, the *_all.deb ones as well or only the *_powerpc.deb ones? If the answer is 'both' for Steve and 'only the latter' for Hideki-san, the problem is most likely an endianness issue related to the database it's trying to load when it crashes. That was also my initial guess, due to reported log and different endianess. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603986: [DebianGIS-dev] Bug#603986: qgis crashes on startup on PowerPC
tags 603986 + help thanks I personally have not access to a PPC to do any trial, and using qgis in remote would be a pain, I guess. It seems Heisenbug Principle in this case applies, too. Maybe we should remove qgis for this arch and wait some porters have time and will to help? On Thu, Dec 09, 2010 at 10:38:46PM +0900, Hideki Yamane wrote: On Sat, 4 Dec 2010 12:47:20 -0500 Steve ssinger...@sympatico.ca wrote: If I build the qgis .deb files from source on my machine I don't get the crash but the debs from the repository always crash. Is it possible to force a rebuild of the .debs in testing? Interesting, I cannot reproduce it, always crash with - packages from repository - packages built with pbuilder (sid) - packages built with pbuilder (squeeze) - source from git, built with pbuilder (sid) - source from git, built with pbuilder (squeeze) Steve, how do you build your deb files? -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606554: aolserver4: affected by privilege escalation vulnerability in logrotate
On Fri, Dec 10, 2010 at 03:10:19AM +0100, Florian Zumbiehl wrote: Package: aolserver4 Version: 4.5.0-16.1 Severity: grave Justification: privilege escalation vulnerability Tags: security --- chown -R www-data:www-data $LOGDIR chmod 755 $LOGDIR --- Indeed, this code snippet potentially expose to easy file linking abuse (not necessarily symlinking) by evil scripts. Of course, in order to do that one has to abuse some tcl adp scripts too before. I think the right thing to do is avoiding changing the ownership of the files, and simply restart the server after rotating. chown www-data:www-data $LOGDIR chmod 755 $LOGDIR If the new log file linked a system file, aolserver would fail to log, plain and clean, else it would create a new file and proceed (that would be the same with sym or hard links). Other apps, such as openacs or dotlrn should do the same in their own dirs. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603511: proftpd: cve-2010-4221 remote code execution vulnerability
notfound 603511 1.3.1-17lenny4 found 603511 1.3.3a-4 fixed 603511 1.3.3a-5 close 603511 1.3.3a-5 thanks Would you please read the changelog before submitting unuseful bugs? Thanks. On Sun, Nov 14, 2010 at 03:46:09PM -0500, Michael Gilbert wrote: Package: proftpd-dfsg Version: 1.3.1-17lenny4 Severity: grave Tags: security , patch Hi, the following CVE (Common Vulnerabilities Exposures) id was published for proftpd-dfsg. CVE-2010-4221[0]: | Multiple stack-based buffer overflows in the pr_netio_telnet_gets | function in netio.c in ProFTPD before 1.3.3c allow remote attackers to | execute arbitrary code via vectors involving a TELNET IAC escape | character to a (1) FTP or (2) FTPS server. Patch available: http://bugs.proftpd.org/show_bug.cgi?id=3521 If you fix the vulnerability please also make sure to include the CVE id in your changelog entry. For further information see: [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4221 http://security-tracker.debian.org/tracker/CVE-2010-4221 -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599054: [Pkg-virtualbox-devel] Bug#599054: After kernel upgrading vbox is no more usable
On Mon, Oct 04, 2010 at 12:54:59PM +0200, Michael Meskes wrote: reassign 599054 linux-image-2.6.32-5-686 thanks /etc/init.d/virtualbox-ose start fails with: Oct 4 09:27:38 blegrez kernel: [ 247.934129] supdrvGipCreate: failed to allocate the GIP page. rc=-8 This is for sure true on i386 and does not allow rebuilding of modules too. I don't know what you mean with does not allow rebuilding of modules. A simple module rebuild fixed the problem for me which leads me to believe that the kernel ABI has changed. module-assistant fails as well: Done with /usr/src/virtualbox-ose-modules-2.6.32-5-686_3.2.8-dfsg-2+2.6.32-24_i386.deb . dpkg -Ei /usr/src/virtualbox-ose-modules-2.6.32-5-686_3.2.8-dfsg-2+2.6.32-24_i386.deb Selezionato il pacchetto virtualbox-ose-modules-2.6.32-5-686. (Lettura del database... 309581 file e directory attualmente installati.) Estrazione di virtualbox-ose-modules-2.6.32-5-686 (da .../virtualbox-ose-modules-2.6.32-5-686_3.2.8-dfsg-2+2.6.32-24_i386.deb)... Configurazione di virtualbox-ose-modules-2.6.32-5-686 (3.2.8-dfsg-2+2.6.32-24)... Stopping VirtualBox kernel modules. Starting VirtualBox kernel modulesmodprobe vboxdrv failed. Please use 'dmesg' to find out why ... failed! failed! invoke-rc.d: initscript virtualbox-ose, action restart failed. (sorry for localized information) -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599054: [Pkg-virtualbox-devel] Bug#599054: After kernel upgrading vbox is no more usable
On Mon, Oct 04, 2010 at 12:55:38PM +0100, Ben Hutchings wrote: On Mon, 2010-10-04 at 13:18 +0200, Francesco P. Lovergine wrote: On Mon, Oct 04, 2010 at 12:54:59PM +0200, Michael Meskes wrote: reassign 599054 linux-image-2.6.32-5-686 thanks /etc/init.d/virtualbox-ose start fails with: Oct 4 09:27:38 blegrez kernel: [ 247.934129] supdrvGipCreate: failed to allocate the GIP page. rc=-8 This is for sure true on i386 and does not allow rebuilding of modules too. I don't know what you mean with does not allow rebuilding of modules. A simple module rebuild fixed the problem for me which leads me to believe that the kernel ABI has changed. module-assistant fails as well: Done with /usr/src/virtualbox-ose-modules-2.6.32-5-686_3.2.8-dfsg-2+2.6.32-24_i386.deb . dpkg -Ei /usr/src/virtualbox-ose-modules-2.6.32-5-686_3.2.8-dfsg-2+2.6.32-24_i386.deb Selezionato il pacchetto virtualbox-ose-modules-2.6.32-5-686. (Lettura del database... 309581 file e directory attualmente installati.) Estrazione di virtualbox-ose-modules-2.6.32-5-686 (da .../virtualbox-ose-modules-2.6.32-5-686_3.2.8-dfsg-2+2.6.32-24_i386.deb)... Configurazione di virtualbox-ose-modules-2.6.32-5-686 (3.2.8-dfsg-2+2.6.32-24)... Stopping VirtualBox kernel modules. Starting VirtualBox kernel modulesmodprobe vboxdrv failed. Please use 'dmesg' to find out why ... failed! failed! [...] So are you going to run dmesg or just make us guess? Ben. An easy guess: it is exactly the same error already pointed in the report. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595603: [DebianGIS-dev] Bug#595608: Bug#595603: python-liblas: OSError: liblas.so: cannot open shared object file: No such file or directory
On Sun, Sep 05, 2010 at 07:35:07PM +0200, David Paleino wrote:
tags 595603 confirmed patch
tags 595608 confirmed patch
thanks
Hello Jakub,
On Sun, 5 Sep 2010 13:02:04 +0200, Jakub Wilk wrote:
Package: python-liblas
Version: 1.2.1-1
Severity: serious
Justification: Policy 3.5 [0]
liblas cannot be imported in a clean chroot:
$ python -c 'import liblas'
Traceback (most recent call last):
File string, line 1, in module
File /usr/lib/pymodules/python2.6/liblas/__init__.py, line 1, in
module
from core import *
File /usr/lib/pymodules/python2.6/liblas/core.py, line 136, in module
las = ctypes.CDLL(lib_name)
File /usr/lib/python2.6/ctypes/__init__.py, line 353, in __init__
self._handle = _dlopen(self._name, mode)
OSError: liblas.so: cannot open shared object file: No such file or
directory
[..]
[0] Well, while the bug might be fixed by adding a dependency on liblas-dev,
there are better ways to fix it.
On Sun, 5 Sep 2010 13:12:00 +0200, Jakub Wilk wrote:
Source: python-liblas
Version: 1.2.1-1
Severity: minor
liblas/core.py contains the following line:
free = ctypes.CDLL(find_library('libc.so.6')).free
This is not how find_library() is supposed to be called (it should be:
find_library('c')), and as a consequence find_library() always returns
None here.
Thanks for your reports.
I prepared a patch that fixes both these bugs (they're both caused by a wrong
usage of find_library(), as you already found out), but unfortunately I'm not
able to commit it (and consequently to do an upload), even though I'm part of
the DebianGIS team:
$ LANG=C svn commit
svn: Commit failed (details follow):
svn: Authorization failed
[..]
I suspect this happens because the (Unix) group doesn't have write permission.
Therefore, I'm attaching the patch to this mail, hoping that frankie reads
this
and acts accordingly (he's away for a couple of days).
Have a nice Sunday,
David
I'd upload the change and ask RMs about testing migration.
--
Francesco P. Lovergine
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559604: limit source to osm2pgsql, tagging 559604
On Thu, Aug 05, 2010 at 08:33:57AM +0200, David Paleino wrote: On Thu, 5 Aug 2010 00:15:50 -0400, Adam D. Barratt wrote: On Sat, March 6, 2010 07:31, David Paleino wrote: #osm2pgsql (0.69+r20104-3) UNRELEASED; urgency=low # # * Now recommends both postgis and last available postgresql-postgis revision. #(closes: #559604) # limit source osm2pgsql tags 559604 + pending confirmed afaics, an upload fixing this bug has not occurred yet, although it has now been marked as pending for a few months; do you have any plans to do so in the near future? Being VAC, I don't have the necessary bandwidth. I'm full-quoting you to frankie@, who is the real maintainer (I just made a tagpending run as teamwork, I didn't fix that bug myself). Kindly, David The same for me until today, let me have a view to my backlog... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591346: [DebianGIS-dev] Bug#591346: Allow the installation of libhdf5-serial and libhdf5-openmpi at the same time
On Mon, Aug 02, 2010 at 09:37:14AM -0400, Lucas Nussbaum wrote: severity 591346 serious thanks On 02/08/10 at 13:55 +0200, Sylvestre Ledru wrote: Package: hdf5 Severity: important Hello, More and more packages are using hdf5 packages. Some of them (for example, Code Saturne) are using hdf5 mpi by default while others, like Scilab, needs the serial one. This is causing also some issues at build time. See bug #591164. To reproduce it: aptitude install libhdf5-openmpi-1.8.4 libhdf5-serial-1.8.4 By the way, if the ABI are compatible, #586149 might be the solution. Thanks for considering this. If you need help on this, don't hesitate to ask. Sylvestre This bug blocks 2 RC bugs, and I don't see any other resolution path for those RC than fixing this bug. So I'm upgrading this bug to severity:serious too, to make sure it stays on the radar. WTF is the reason to both depend on serial and parallel flavors at building time instead of the parallel version libhdf5-mpi-dev? Note that *if the ABI are compatible* is a wrong guess AFAIK: serial and parallel versions have different shlib sub-dependendecies. There are also many limitations in parallel edition: e.g. parallel edition does not support pluggable compression in writing and does not support variable length records, cannot coexists with threadsafe and C++, and so on. I think the only safe and clean approach would be having different lib names for MPI flavors, but upstream think differently at the moment. I'm not intentioned to diverge about that, which would require rdepends changing their building snippets forever in Debian, and adopt other dirty tricks. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586273: flashplugin-nonfree: Note also that 32 bit plugins is not able to work
(0xf5f16000) libuuid.so.1 = /lib32/libuuid.so.1 (0xf5f12000) libselinux.so.1 = /lib32/libselinux.so.1 (0xf5ef7000) Packages containing libraries used by libflashplayer.so: ia32-libs 20090808 ia32-libs-gtk 20090804 lib32z1 1:1.2.3.4.dfsg-3 libc6-i386 2.11.2-2 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages flashplugin-nonfree depends on: ii debconf [debconf-2.0] 1.5.32 Debian configuration management sy ii gnupg 1.4.10-4 GNU privacy guard - a free PGP rep ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libcairo2 1.8.10-4 The Cairo 2D vector graphics libra ii libcurl3-gnutls 7.21.0-1 Multi-protocol file transfer libra ii libfontconfig12.8.0-2.1 generic font configuration library ii libfreetype6 2.3.11-1 FreeType 2 font engine, shared lib ii libgcc1 1:4.4.4-6 GCC support library ii libglib2.0-0 2.24.1-1 The GLib library of C routines ii libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface ii libnspr4-0d 4.8.4-1NetScape Portable Runtime Library ii libnss3-1d3.12.6-2 Network Security Service libraries ii libpango1.0-0 1.28.1-1 Layout and rendering of internatio ii libstdc++64.4.4-6The GNU Standard C++ Library v3 ii libx11-6 2:1.3.3-3 X11 client-side library ii libxext6 2:1.1.1-3 X11 miscellaneous extension librar ii libxt61:1.0.7-1 X11 toolkit intrinsics library ii wget 1.12-2 retrieves files from the web flashplugin-nonfree recommends no packages. Versions of packages flashplugin-nonfree suggests: pn flashplugin-nonfree-extrasoun none (no description available) hi iceweasel 3.5.10-1 Web browser based on Firefox pn konqueror-nsplugins none (no description available) ii msttcorefonts 2.7transitional dummy package ii ttf-dejavu2.31-1 Metapackage to pull in ttf-dejavu- ii ttf-mscorefonts-installer [ms 3.2Installer for Microsoft TrueType c pn ttf-xfree86-nonfree none (no description available) ii x-ttcidfont-conf 32 TrueType and CID fonts configurati -- no debconf information -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586652: Cannot configure
Package: python-cssutils Version: 0.9.7~b2-1 Severity: serious At configuration time, the new package fails and upgrade cannot be completed: Compiling /usr/lib/python2.4/site-packages/cssutils/sac.py ... File /usr/lib/python2.4/site-packages/cssutils/sac.py, line 133 u'%s ' % media if media else u'', -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-cssutils depends on: ii python 2.6.5-3 An interactive high-level object-o ii python-central 0.6.14+nmu2 register and build utility for Pyt ii python-encutils 0.9.7~b2-1 Encoding detection collection for python-cssutils recommends no packages. python-cssutils suggests no packages. -- no debconf information -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577715: FTBFS: 7 of 7 tests failed
On Wed, Apr 14, 2010 at 03:03:51PM +0200, Francesco P. Lovergine wrote: On Tue, Apr 13, 2010 at 10:47:37PM +0200, Cyril Brulebois wrote: Source: netcdf Version: 1:4.1.1-2 Severity: serious Justification: FTBFS Hi, your package FTBFS on all architectures in experimental due to testsuite issues: | 7 of 7 tests failed Previous lines talk about various segmentation faults. Full build logs: https://buildd.debian.org/status/package.php?p=netcdfsuite=experimental It seems due to remotes site availability missing: some tests work using a remote dap server... That's *very* strange. It fails at testing time even for amd64 where I can successfully complete the build and check in a clean evironment. Of course, I disabled remote tests, but those misterious segfaults appear anyway... PS: CC to d-d for possible suggestions... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577743: autodir loads wrong autofs module
severity 577743 grave retitle 577743 autodir: autodir fails to load autofs4 module due to an obsolete option clone 577743 -1 reassign -1 autofs retitle -1 autofs: autofs fails to load autofs4 module due to an obsolete option thanks On Wed, Apr 14, 2010 at 12:04:26PM +0600, Sergey Fedoseev wrote: Package: autodir Version: 0.99.9-4 Hi! Autodir loads autofs instead of autofs4 module. So I get message localhost autodir: [autohome] fatal: incorrect autofs module loaded? mount /home: Invalid argument in logs. I believe there is error in initscript function 'load_autofs': modprobe is runned with '-k' option, though modprobe knows nothing about it. Maybe you mean '-q' option? That piece of code was stolen shamelessly from autofs and indeed it is historical. So at least the same bug has to be reported for autofs (doing so with this email). That said -k or --autoclean option has been recently (ehm) obsoleted (in 3.10 I think): commit 9b9e45c5c4d4b6938dc44d1f6b1f57bc8c8a3524 Author: Michal Marek mma...@suse.cz Date: Tue Mar 3 19:06:32 2009 -0500 modprobe: remove obsolete -k, --autoclean option This is a leftover from 2.4 times. Signed-off-by: Michal Marek mma...@suse.cz Signed-off-by: Jon Masters j...@jonmasters.org -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577715: [DebianGIS-dev] Bug#577715: netcdf: FTBFS: 7 of 7 tests failed
On Tue, Apr 13, 2010 at 10:47:37PM +0200, Cyril Brulebois wrote: Source: netcdf Version: 1:4.1.1-2 Severity: serious Justification: FTBFS Hi, your package FTBFS on all architectures in experimental due to testsuite issues: | 7 of 7 tests failed Previous lines talk about various segmentation faults. Full build logs: https://buildd.debian.org/status/package.php?p=netcdfsuite=experimental It seems due to remotes site availability missing: some tests work using a remote dap server... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577060: FTBS due to MPI related problem.
On Sat, Apr 10, 2010 at 02:11:12PM -0500, Steve M. Robbins wrote:
tags 577060 + help unreproducible moreinfo
thanks
Hi,
I just built minc in a clean sid chroot (using pbuilder) and found
no problem on my and64 system.
On Fri, Apr 09, 2010 at 11:29:48AM +0200, Francesco P. Lovergine wrote:
make[3]: Entering directory `/tmp/buildd/minc-2.0.18'
/bin/bash ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I.
-I./libsrc -I./volume_io/Include -I./volume_io/Include -I./progs/Proglib
-I./conversion/Acr_nema -I./libsrc2-I/usr/include/mpi -c -o
libsrc/ParseArgv.lo libsrc/ParseArgv.c
libtool: compile: cc -DHAVE_CONFIG_H -I. -I./libsrc -I./volume_io/Include
-I./volume_io/Include -I./progs/Proglib -I./conversion/Acr_nema -I./libsrc2
-I/usr/include/mpi -c libsrc/ParseArgv.c -fPIC -DPIC -o
libsrc/.libs/ParseArgv.o
In file included from /usr/include/H5public.h:57,
from /usr/include/hdf5.h:24,
from libsrc/minc.h:588,
from libsrc/minc_private.h:84,
from libsrc/ParseArgv.c:23:
/usr/include/mpi/mpi.h:221: error: expected identifier or '(' before 'int'
/usr/include/mpi/mpi.h:228: error: expected identifier or '(' before 'int'
I need some help:
1) What version of hdf5 are you using? I'm using libhdf5-opennmpi-dev
(1.8.4-patch1-1).
2) What version of MPI? I'm using libopenmpi-dev (1.4.1-3).
3) line 221 of mpi.h doesn't have 'int'; here it reads:
typedef struct ompi_communicator_t *MPI_Comm;
4) line 228 of mpi.h doesn't have 'int'; here it reads:
typedef struct ompi_info_t *MPI_Info;
Regards,
-Steve
Sorry it seemed independent, but indeed it is related to the netcdf v4.
If you tried to build using libnetcdf-dev (= 1:4.0.0) (available in
experimental) you got this result. Note that no other package gives
this problem, so I suspect it is due to some oddities with
macros/defines. Note that new netcdf 4 depends on HDF5 now.
--
Francesco P. Lovergine
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577060: FTBS due to MPI related problem.
Package: minc
Severity: serious
Justification: no longer builds from source
make[3]: Entering directory `/tmp/buildd/minc-2.0.18'
/bin/bash ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I./libsrc
-I./volume_io/Include -I./volume_io/Include -I./progs/Proglib
-I./conversion/Acr_nema -I./libsrc2-I/usr/include/mpi -c -o
libsrc/ParseArgv.lo libsrc/ParseArgv.c
libtool: compile: cc -DHAVE_CONFIG_H -I. -I./libsrc -I./volume_io/Include
-I./volume_io/Include -I./progs/Proglib -I./conversion/Acr_nema -I./libsrc2
-I/usr/include/mpi -c libsrc/ParseArgv.c -fPIC -DPIC -o
libsrc/.libs/ParseArgv.o
In file included from /usr/include/H5public.h:57,
from /usr/include/hdf5.h:24,
from libsrc/minc.h:588,
from libsrc/minc_private.h:84,
from libsrc/ParseArgv.c:23:
/usr/include/mpi/mpi.h:221: error: expected identifier or '(' before 'int'
/usr/include/mpi/mpi.h:228: error: expected identifier or '(' before 'int'
make[3]: *** [libsrc/ParseArgv.lo] Error 1
make[3]: Leaving directory `/tmp/buildd/minc-2.0.18'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/buildd/minc-2.0.18'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/tmp/buildd/minc-2.0.18'
make: *** [debian/stamp-makefile-build] Error 2
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-3-686 (SMP w/1 CPU core)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
Francesco P. Lovergine
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576705: SIGSEGV due to NULL pointer dereference in handle_ldap_getgroups()
severity 576705 important forwarded 576705 bugs.proftpd.org thanks Forwarded as #3424 This is not grave, because it does not render the module unusable at all. Anyway, good catch, it needs to be better managed in mod_ldap. On Tue, Apr 06, 2010 at 06:27:00PM +0200, Arnaud Fontaine wrote: Package: proftpd-mod-ldap Severity: grave Tags: patch Hello, When LDAPDoAuth specifies an invalid filter which leads to no results being returned, mod_ldap SIGSEGV with the following backtrace: -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552864: NMU on DELAYED/2
Hi maintainer
I uploaded the 0.41-2.1 NMU with fix for this RC bug as shown in the
attached debdiff.
Cheers.
--
Francesco P. Lovergine
diff -u gpstrans-0.41/debian/changelog gpstrans-0.41/debian/changelog
--- gpstrans-0.41/debian/changelog
+++ gpstrans-0.41/debian/changelog
@@ -1,3 +1,11 @@
+gpstrans (0.41-2.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Changed getline() in my_getline() to avoid eglibc colliding names in getline.c.
+(closes: #552864)
+
+ -- Francesco Paolo Lovergine fran...@debian.org Wed, 27 Jan 2010 17:18:46 +0100
+
gpstrans (0.41-2) unstable; urgency=low
* suggest setserial (thanks to Joerg Schuetter jo...@schuetter.org,
only in patch2:
unchanged:
--- gpstrans-0.41.orig/src/prefs.c
+++ gpstrans-0.41/src/prefs.c
@@ -268,7 +268,7 @@
do
{
- p = getline (Please select datum: );
+ p = my_getline (Please select datum: );
sscanf (p, %d, value);
printf (\n);
}
@@ -288,7 +288,7 @@
do
{
- p = getline (Please select format: );
+ p = my_getline (Please select format: );
sscanf (p, %d, value);
printf (\n);
}
@@ -298,7 +298,7 @@
printf (\n);
do
{
- p = getline (Please select time offset (-12 to +12): );
+ p = my_getline (Please select time offset (-12 to +12): );
sscanf (p, %f, floatval);
printf (\n);
}
@@ -308,7 +308,7 @@
printf (\n);
do
{
- p = getline (Please enter serial device name: );
+ p = my_getline (Please enter serial device name: );
sprintf (gPrefs.Device, %s, p);
printf (\n);
}
@@ -317,7 +317,7 @@
printf (\n);
do
{
- p = getline (Is your model etrex (or other similar model) (y/n)?);
+ p = my_getline (Is your model etrex (or other similar model) (y/n)?);
/* Add support to several models.Thats why we put the y as char */
/* In practical terms,answer means BYTE not model. */
only in patch2:
unchanged:
--- gpstrans-0.41.orig/src/getline/getline.c
+++ gpstrans-0.41/src/getline/getline.c
@@ -37,7 +37,7 @@
/* exported interface /
-char *getline (); /* read a line of input */
+char *my_getline (); /* read a line of input */
void gl_setwidth (); /* specify width of screen */
void gl_histadd (); /* adds entries to hist */
void gl_strwidth (); /* to bind gl_strlen */
@@ -392,7 +392,7 @@
hist_init ();
}
if (isatty (0) == 0 || isatty (1) == 0)
-gl_error (\n*** Error: getline(): not interactive, use stdio.\n);
+gl_error (\n*** Error: my_getline(): not interactive, use stdio.\n);
gl_char_init ();
gl_init_done = 1;
}
@@ -422,7 +422,7 @@
}
char *
-getline (prompt)
+my_getline (prompt)
char *prompt;
{
int c, loc, tmp;
@@ -634,7 +634,7 @@
int i;
if (gl_cnt = BUF_SIZE - 1)
-gl_error (\n*** Error: getline(): input buffer overflow\n);
+gl_error (\n*** Error: my_getline(): input buffer overflow\n);
if (gl_overwrite == 0 || gl_pos == gl_cnt)
{
for (i = gl_cnt; i = gl_pos; i--)
@@ -662,7 +662,7 @@
if (gl_overwrite == 0)
{
if (gl_cnt + len = BUF_SIZE - 1)
- gl_error (\n*** Error: getline(): input buffer overflow\n);
+ gl_error (\n*** Error: my_getline(): input buffer overflow\n);
for (i = gl_cnt; i = gl_pos; i--)
gl_buf[i + len] = gl_buf[i];
for (i = 0; i len; i++)
@@ -674,7 +674,7 @@
if (gl_pos + len gl_cnt)
{
if (gl_pos + len = BUF_SIZE - 1)
- gl_error (\n*** Error: getline(): input buffer overflow\n);
+ gl_error (\n*** Error: my_getline(): input buffer overflow\n);
gl_buf[gl_pos + len] = 0;
}
for (i = 0; i len; i++)
@@ -717,7 +717,7 @@
int loc = gl_width - 5; /* shifts line back to start position */
if (gl_cnt = BUF_SIZE - 1)
-gl_error (\n*** Error: getline(): input buffer overflow\n);
+gl_error (\n*** Error: my_getline(): input buffer overflow\n);
if (gl_out_hook)
{
change = gl_out_hook (gl_buf);
@@ -1025,7 +1025,7 @@
char *p = buf;
int len;
- /* in case we call gl_histadd() before we call getline() */
+ /* in case we call gl_histadd() before we call my_getline() */
if (gl_init_done 0)
{/* -1 only on startup */
hist_init ();
@@ -1316,7 +1316,7 @@
char *p;
echo = (1 == 0);
- p = getline (prompt);
+ p = my_getline (prompt);
echo = (1 == 1);
return p;
only in patch2:
unchanged:
--- gpstrans-0.41.orig/src/getline/getline.h
+++ gpstrans-0.41/src/getline/getline.h
@@ -10,7 +10,7 @@
typedef size_t (*gl_strwidth_proc) (char *);
-char *getline (char *); /* read a line of input */
+char *my_getline (char *); /* read a line of input */
char *getlinenoecho (char *); /* read a line of input */
void gl_setwidth (int); /* specify width of screen */
void gl_histadd (char *); /* adds entries to hist */
@@ -22,7 +22,7 @@
#else /* not __STDC__ */
-char *getline ();
+char *my_getline ();
char
Bug#566540: some explanation
Hi Sylvestre and all HDF5 has a long history of API violations even for minor revisions. That motivated AFAIK use of a versioned library name in the past. In 1.8 series HDF Group finally added an official SONAME to the libraries (C/C++/Fortran with and without MPI). I adopted it instead of the Debian specific SONAME and library naming. The current package (but for latest oversight about 1.8.3-1.8.4 migration with the same SONAME) tries to be defensive on that regards, without sacrificing name consistency. In fact the current HDF5 roadmap will change library source package names at every minor/major release (also considering that the C++ ABI interface could be easily broken at each update without notice) and will use virtuals such as libhdf5-1.8 and libhdf5-1.8.x to manage multiple MPI/serial packages and colliding sonames. That should suffice to ensure consistency among upgrades. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566540: some explanation
On Mon, Jan 25, 2010 at 03:02:09PM +0100, Sylvestre Ledru wrote: Hello Francesco, Thanks for the feedback. Could you just processed with the migration practices when you update it [1] ? I am maintaining three packages (Scilab, cgns and jhdf) which are based on this library. Thanks Sylvestre Hi, I already asked for a binNMU for all r-dependencies, which is - but for the now fixed problem - the only requirement for a proper migration. I generally call for migration all interested maintainers, but this time I was too optimistic. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564243: More information and reassigning.
instead of a textual one. GRAPHICAL_HIERARCHY= YES # The DOT_IMAGE_FORMAT tag can be used to set the image format of the images # generated by dot. Possible values are png, jpg, or gif # If left blank png will be used. DOT_IMAGE_FORMAT = png # The tag DOT_PATH can be used to specify the path where the dot tool can be # found. If left blank, it is assumed the dot tool can be found in the path. DOT_PATH = # The DOTFILE_DIRS tag can be used to specify one or more directories that # contain dot files that are included in the documentation (see the # \dotfile command). DOTFILE_DIRS = # The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width # (in pixels) of the graphs generated by dot. If a graph becomes larger than # this value, doxygen will try to truncate the graph, so that it fits within # the specified constraint. Beware that most browsers cannot cope with very # large images. MAX_DOT_GRAPH_WIDTH= 1024 # The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows height # (in pixels) of the graphs generated by dot. If a graph becomes larger than # this value, doxygen will try to truncate the graph, so that it fits within # the specified constraint. Beware that most browsers cannot cope with very # large images. MAX_DOT_GRAPH_HEIGHT = 1024 # The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the # graphs generated by dot. A depth value of 3 means that only nodes reachable # from the root by following a path via at most 3 edges will be shown. Nodes # that lay further from the root node will be omitted. Note that setting this # option to 1 or 2 may greatly reduce the computation time needed for large # code bases. Also note that a graph may be further truncated if the graph's # image dimensions are not sufficient to fit the graph (see MAX_DOT_GRAPH_WIDTH # and MAX_DOT_GRAPH_HEIGHT). If 0 is used for the depth value (the default), # the graph is not depth-constrained. MAX_DOT_GRAPH_DEPTH= 0 # If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will # generate a legend page explaining the meaning of the various boxes and # arrows in the dot generated graphs. GENERATE_LEGEND= YES # If the DOT_CLEANUP tag is set to YES (the default) Doxygen will # remove the intermediate dot files that are used to generate # the various graphs. DOT_CLEANUP= YES #--- # Configuration::additions related to the search engine #--- # The SEARCHENGINE tag specifies whether or not a search engine should be # used. If set to NO the values of all tags below this one will be ignored. SEARCHENGINE = NO -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564243: found in 1.6.2-1
found 564243 1.6.2-1 thanks Note that it works with version in testing. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564243: [fran...@debian.org: More information and reassigning.]
# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images # generated by dot. Possible values are png, jpg, or gif # If left blank png will be used. DOT_IMAGE_FORMAT = png # The tag DOT_PATH can be used to specify the path where the dot tool can be # found. If left blank, it is assumed the dot tool can be found in the path. DOT_PATH = # The DOTFILE_DIRS tag can be used to specify one or more directories that # contain dot files that are included in the documentation (see the # \dotfile command). DOTFILE_DIRS = # The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width # (in pixels) of the graphs generated by dot. If a graph becomes larger than # this value, doxygen will try to truncate the graph, so that it fits within # the specified constraint. Beware that most browsers cannot cope with very # large images. MAX_DOT_GRAPH_WIDTH= 1024 # The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows height # (in pixels) of the graphs generated by dot. If a graph becomes larger than # this value, doxygen will try to truncate the graph, so that it fits within # the specified constraint. Beware that most browsers cannot cope with very # large images. MAX_DOT_GRAPH_HEIGHT = 1024 # The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the # graphs generated by dot. A depth value of 3 means that only nodes reachable # from the root by following a path via at most 3 edges will be shown. Nodes # that lay further from the root node will be omitted. Note that setting this # option to 1 or 2 may greatly reduce the computation time needed for large # code bases. Also note that a graph may be further truncated if the graph's # image dimensions are not sufficient to fit the graph (see MAX_DOT_GRAPH_WIDTH # and MAX_DOT_GRAPH_HEIGHT). If 0 is used for the depth value (the default), # the graph is not depth-constrained. MAX_DOT_GRAPH_DEPTH= 0 # If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will # generate a legend page explaining the meaning of the various boxes and # arrows in the dot generated graphs. GENERATE_LEGEND= YES # If the DOT_CLEANUP tag is set to YES (the default) Doxygen will # remove the intermediate dot files that are used to generate # the various graphs. DOT_CLEANUP= YES #--- # Configuration::additions related to the search engine #--- # The SEARCHENGINE tag specifies whether or not a search engine should be # used. If set to NO the values of all tags below this one will be ignored. SEARCHENGINE = NO -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546207: cannot reproduce python-gdal failure
severity 546207 normal tag 546207 + moreinfo thanks Sorry but I cannot reproduce the problem with current 1.6.2 version. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
