Bug#630033: manpage-has-bad-whatis-entry
Package: libcgsi-gsoap-dev Version: 1.3.4.0-1 Severity: minor Lintian warning: manpage-has-bad-whatis-entry Misplaced brief description. smime.p7s Description: S/MIME cryptographic signature
Bug#630034: globus-gram-job-manager-doc
Package: globus-gram-job-manager-doc Version: 10.70-1 Severity: minor Lintian warning: manpage-has-errors-from-man Full stop in column 1 needs escaping. smime.p7s Description: S/MIME cryptographic signature
Bug#630035: manpage-has-errors-from-man
Package: libglobus-ftp-client-doc Version: 6.0-3 Severity: minor Lintian warning: manpage-has-errors-from-man Long typedefs. smime.p7s Description: S/MIME cryptographic signature
Bug#630036: manpage-has-errors-from-man
Package: libglobus-common-doc Version: 11.6-4 Severity: minor Lintian warning: manpage-has-errors-from-man Long defines. smime.p7s Description: S/MIME cryptographic signature
Bug#630037: manpage-has-bad-whatis-entry
Package: libglobus-authz-doc Version: 0.7-5 Severity: minor Lintian warning: manpage-has-bad-whatis-entry Bad @defgroup output. smime.p7s Description: S/MIME cryptographic signature
Bug#621719: globus-gssapi-gsi: library/import_sec_context.c:204: undefined reference to `ssl3_setup_buffers'
forwarded 621719 http://bugzilla.globus.org/globus/show_bug.cgi?id=7159 thanks fre 2011-04-08 klockan 14:02 +0900 skrev Nobuhiro Iwamatsu: Source: globus-gssapi-gsi Version: 7.6-1 Severity: serious Justification: FTBFS Hi, globus-gssapi-gsi FTBFS with the following error,presumably for the openssl transition: The problem is that the code uses some symbols from the openssl library that are not part of the API published in the headers. The new openssl library no longer exports symbols that are not part of the published API, so the compilation now fails. This problem has already been reported upstream: http://bugzilla.globus.org/globus/show_bug.cgi?id=7159 Mattias signature.asc Description: This is a digitally signed message part
Bug#612524: globus-core: globus-gpt2pkg-config should write Requires.private instead of Requires
forwarded 612524 http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=7173 tag 612524 + upstream thanks Since this change would influence a lot of packages at build time, it is better to make this change at a time most of the packages would be rebuilt anyway, like at the time of a new upstream release. The next upstream release of the Globus Toolkit (5.2) had an alpha release in December, so it will hopefully be released soon. In the new release, the globus-gpt2pkg-config script - which was part of the Debian packaging additions in the past - has been integrated by upstream into the new version of grid-packaging-tools (3.3). I have therefore forwarded this feature request upstream. Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#632402: bdii: Fails to start on upgrade from 5.1.13-1
block 632402 by 628237 thanks lör 2011-07-02 klockan 11:21 +1000 skrev Ben Finney: slap_sasl_init: auxprop add plugin failed This is a bug in slapd or libsasl2, that prevents bdii's slapd instance to start. This bug is already reported to the slapd package. Registering block on the slapd bug. Mattias signature.asc Description: This is a digitally signed message part
Bug#636878: libcgsi-gsoap-dev: cgsi-plugin fails to register correctly within gSOAP
lör 2011-08-06 klockan 19:26 +0200 skrev Paul Millar: /* * How to compile: * * gcc -Wall -o cgsi_plugin_test cgsi_plugin_test.c -lgsoap -lcgsi_plugin */ Please note that in order to work correctly you must use the cflags from gsoap's pkg-config: $ gcc -Wall `pkg-config --cflags gsoap` -o cgsi-plugin-test cgsi-plugin-test.c -lgsoap -lcgsi_plugin $ ./cgsi-plugin-test Before registering plugin: fopen: 0x7ffcc001fa20 Registring cgsi_plugin gSOAP plugin. After registering plugin: fopen: 0x7ffcbfdfd910 Check for plugin-specific data: data: 0x13114a0 Without them you get a segmentation fault. $ gcc -Wall -o cgsi-plugin-test cgsi-plugin-test.c -lgsoap -lcgsi_plugin $ ./cgsi-plugin-test Before registering plugin: fopen: 0x7fb2591eba20 Registring cgsi_plugin gSOAP plugin. After registering plugin: fopen: 0x7fb258fc9910 Check for plugin-specific data: data: 0x17ec4a0 Segmenteringsfel (minnesutskrift skapad) Mattias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641686: ITP: myproxy -- Manage X.509 Public Key Infrastructure (PKI) security credentials
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: myproxy Version : 5.4 * URL : http://grid.ncsa.illinois.edu/myproxy/ * License : NCSA and BSD and Apache 2 Description : Manage X.509 Public Key Infrastructure (PKI) security credentials MyProxy is open source software for managing X.509 Public Key Infrastructure (PKI) security credentials (certificates and private keys). MyProxy combines an online credential repository with an online certificate authority to allow users to securely obtain credentials when and where needed. Users run myproxy-logon to authenticate and obtain credentials, including trusted CA certificates and Certificate Revocation Lists (CRLs). smime.p7s Description: S/MIME cryptographic signature
Bug#644214: RM: lfc -- ROM; has been merged into common lcgdm package
Package: ftp.debian.org Severity: normal The lfc source package has been merged into a common lcgdm source package together with lfc-postgres, dpm and dpm-postgres. The binary packages provided by the lfc source package have been taken over by or are provided by binary packages in lcdgm. Mattias Maintainer of lcgdm signature.asc Description: This is a digitally signed message part
Bug#644215: RM: lfc-postgres -- ROM; has been merged into common lcgdm package
Package: ftp.debian.org Severity: normal The lfc-postgres source package has been merged into a common lcgdm source package together with lfc, dpm and dpm-postgres. The binary packages provided by the lfc-postgres source package have been taken over by or are provided by binary packages in lcdgm. Mattias Maintainer of lcgdm signature.asc Description: This is a digitally signed message part
Bug#644216: RM: dpm -- ROM; has been merged into common lcgdm package
Package: ftp.debian.org Severity: normal The dpm source package has been merged into a common lcgdm source package together with lfc, lfc-postgres and dpm-postgres. The binary packages provided by the dpm source package have been taken over by or are provided by binary packages in lcdgm. Mattias Maintainer of lcgdm signature.asc Description: This is a digitally signed message part
Bug#644217: RM: dpm-postgres -- ROM; has been merged into common lcgdm package
Package: ftp.debian.org Severity: normal The dpm-postgres source package has been merged into a common lcgdm source package together with lfc, lfc-postgres and dpm. The binary packages provided by the dpm-postgres source package have been taken over by or are provided by binary packages in lcdgm. Mattias Maintainer of lcgdm signature.asc Description: This is a digitally signed message part
Bug#628237: 628...@bugs.debian.org
Sat, 9 Jul 2011 06:52:05 +0200 Thomas Krichel kric...@openlib.org wrote: | Setting up slapd (2.4.25-1+b1) ... | Creating initial configuration... mkdir: cannot create directory `/etc/ldap/slapd.d': File exists | dpkg: error processing slapd (--configure): | subprocess installed post-installation script returned error exit status 1 | configured to not write apport reports | Errors were encountered while processing: | slapd | You are reinstalling version 2.4.25-1+b1 which is the one that is broken. The claim earlier in this bug report was that the bug is fixed in 2.4.25-1.1. Did you try that version? Installing 2.4.25-1.1 solved the issues for me. There is a minor glitch if you first install the broken 2.4.25-1+b1 and then try to update to 2.4.25-1.1. In this case the configuration of the broken 2.4.25-1+b1 fails and leaves the package in a bad state so that the upgrade fails. But deleting the empty /etc/ldap/slapd.d directory created by the half-configuration of the broken package was enough to work around that problem. But this is a different problem. The bug reported in THIS bug report is solved for me by updating to 2.4.25-1.1. Mattias signature.asc Description: This is a digitally signed message part
Bug#675746: Problem building openldap on armel
Package: buildd.debian.org Severity: normal Hi! The package openldap version 2.4.28-1.3 has failed to build for armel three times on the buildd servers: https://buildd.debian.org/status/logs.php?pkg=openldaparch=armelver=2.4.28-1.3 In all three cases the build fails during the make check. The failure is not in the same test in all cases. The changes from the -1.1 version which built without problems and the present -1.3 are very small and would not have any impact on either of the tests that failed. The package builds without problem on the armel porterbox abel.debian.org. There is no error message in the logs prior to the failure that explains why the build fails on the buildd servers. It just looks that something killed the build before it was expected to complete. Can anyone explain the build failures and do something to prevent them? Mattias signature.asc Description: This is a digitally signed message part
Bug#677856: dcap: FTBFS[kfreebsd-amd64 linux-i386]: error: inlining failed in call to always_inline 'vasprintf': function not inlinable
notfound 677856 dcap/2.47.6-2 reassign 677856 gcc-4.7 found 677856 gcc-4.7/4.7.0-11 fixed 677856 gcc-4.7/4.7.0-12 forcemerge 672411 677856 thanks This is not a bug in dcap This is a bug in gcc This bug is already fixed Please update the gcc version in your buildd build environments. Mattias signature.asc Description: This is a digitally signed message part
Bug#673523: ITP: voms-api-java -- Virtual Organization Membership Service Java API
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: voms-api-java Version : 2.0.7 * URL : http://glite.web.cern.ch/glite/ * License : Apache 2 Description : Virtual Organization Membership Service Java API With release 2.0.7 the Java API from the VOMS package has been split off to a separate source package upstream. smime.p7s Description: S/MIME cryptographic signature
Bug#673525: mvn-debian script fails when more than one binary package is defined
Package: maven-debian-helper
Version: 1.5.1
Severity: normal
The mvn-debian script fails when more than one binary package is defined
in debian/control. The reason is the following line:
JAR_PACKAGE=$(dh_listpackages | awk '{ print $1 }')
Which should be:
JAR_PACKAGE=$(dh_listpackages | head -1)
as in the other maven helper scripts.
smime.p7s
Description: S/MIME cryptographic signature
Bug#667575: Name space conflict '/usr/bin/dccp'
mån 2012-05-14 klockan 14:29 +0200 skrev Mathieu Malaterre: tags 667575 moreinfo thanks Mattias, any comments ? I have been using dccp for a while now. dccp is already known since squeeze. You only introduced dccp recently. Would it be possible to rename it to something else ? I do not believe we can use alternatives in this case, since dccp are fundamentally different applications. Thanks Hi! Is the dccp binary supposed to be present in the dicom3tools or not? The reason I ask is that it is currently only present in the binary package for amd64, and not on any other architecture. The dccp binary seems to never be present in dicom3tools packages built on the buildd builders. It is sometimes present in the binary package for the uploaded architecture not built on the buildd builders, but not always. This file conflict was reported once before (bug #640914) and that tine it was resolved by an update to the dicom3tools package that didn't contain the dccp binary also on amd64. As far as I can tell, the dicom3tools package did not contain the dccp binary at the time the dcap package was accepted in Debian (2009-12-30). The file conflict was first reported 2011-09-08, following an update to dicom3tools on 2011-09-03 (version 1.0~20110901-1) that introduced the dccp binary - but for amd64 only. As mentioned above, this was resolved later by a new dicom3tools update that didn't contain the dccp binary. Now the same situation has occurred again due to a new update of dicom3tools containing the dccp binary for amd64 only. Mattias signature.asc Description: This is a digitally signed message part
Bug#654376: ITP: globus-gram-job-manager-fork -- Fork Job Manager Support
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: globus-gram-job-manager-fork Version : 1.0 * URL : http://www.globus.org/ * License : Apache 2 Description : Fork Job Manager Support This new package in Globus Toolkit 5.2.0 replaces the globus-gram-job-manager-setup-fork package in earlier versions. signature.asc Description: This is a digitally signed message part
Bug#654377: ITP: globus-gram-job-manager-condor -- Condor Job Manager Support
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: globus-gram-job-manager-condor Version : 1.0 * URL : http://www.globus.org/ * License : Apache 2 Description : Condor Job Manager Support This new package in Globus Toolkit 5.2.0 replaces the globus-gram-job-manager-setup-condor package in earlier versions. signature.asc Description: This is a digitally signed message part
Bug#654378: ITP: globus-gram-job-manager-pbs -- PBS Job Manager Support
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: globus-gram-job-manager-pbs Version : 1.0 * URL : http://www.globus.org/ * License : Apache 2 Description : PBS Job Manager Support This new package in Globus Toolkit 5.2.0 replaces the globus-gram-job-manager-setup-pbs package in earlier versions. signature.asc Description: This is a digitally signed message part
Bug#654379: ITP: globus-gram-job-manager-sge -- Grid Engine Job Manager Support
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: globus-gram-job-manager-sge Version : 1.0 * URL : http://www.globus.org/ * License : Apache 2 Description : Grid Engine Job Manager Support This new package in Globus Toolkit 5.2.0 replaces the globus-gram-job-manager-setup-sge package in earlier versions. signature.asc Description: This is a digitally signed message part
Bug#654386: ITP: globus-gram-audit -- GRAM Jobmanager Auditing
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: globus-gram-audit Version : 3.1 * URL : http://www.globus.org/ * License : Apache 2 Description : GRAM Jobmanager Auditing The Globus Toolkit is an open source software toolkit used for building Grid systems and applications. It is being developed by the Globus Alliance and many others all over the world. A growing number of projects and companies are using the Globus Toolkit to unlock the potential of grids for their cause. The globus-gram-audit package contains: GRAM Jobmanager Auditing signature.asc Description: This is a digitally signed message part
Bug#654389: ITP: globus-simple-ca -- Simple CA Utility
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: globus-simple-ca Version : 3.0 * URL : http://www.globus.org/ * License : Apache 2 Description : Simple CA Utility The Globus Toolkit is an open source software toolkit used for building Grid systems and applications. It is being developed by the Globus Alliance and many others all over the world. A growing number of projects and companies are using the Globus Toolkit to unlock the potential of grids for their cause. The globus-simple-ca package contains: Simple CA Utility signature.asc Description: This is a digitally signed message part
Bug#654390: ITP: globus-xioperf -- XIO Performance Tool
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: globus-xioperf Version : 3.0 * URL : http://www.globus.org/ * License : Apache 2 Description : XIO Performance Tool The Globus Toolkit is an open source software toolkit used for building Grid systems and applications. It is being developed by the Globus Alliance and many others all over the world. A growing number of projects and companies are using the Globus Toolkit to unlock the potential of grids for their cause. The globus-xioperf package contains: XIO Performance Tool signature.asc Description: This is a digitally signed message part
Bug#690862: ITP: jglobus -- Globus Java client libraries
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: jglobus Version : 2.0.4 * URL : http://www.globus.org/toolkit/jglobus/ * License : Apache 2.0 Description : Globus Java client libraries jglobus is a collection of Java client libraries for Globus Toolkit security, GRAM and GridFTP. smime.p7s Description: S/MIME cryptographic signature
Bug#690863: ITP: jglobus-myproxy -- Globus MyProxy Java client libraries
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se Control: block -1 by 690862 * Package name: jglobus-myproxy Version : 2.0 * URL : http://grid.ncsa.illinois.edu/myproxy/jglobus/ * License : Apache 2.0 Description : Java MyProxy client libraries The JGlobus MyProxy client provides a full-featured Java client API for MyProxy. smime.p7s Description: S/MIME cryptographic signature
Bug#685663: unblock nordugrid-arc/2.0.0-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Control: block -1 by 683142 unblock nordugrid-arc/2.0.0-3 The nordugrid-arc 2.0.0-3 package had already migrated to testing before the freeze, but was kicked out because a dependency of one of its binary packages was removed due to an RC classified bug. That package (bdii) has since been fixed and an unblock request for the fix has been filed. This is a request to unblock this package so that it can get back in when its currently blocked dependency (bdii) is unblocked. Mattias signature.asc Description: This is a digitally signed message part
Bug#683142: Proposed backport
tor 2012-08-23 klockan 17:54 +0200 skrev Cyril Brulebois: Hi Mattias, I'm not sure we're going to consider unblocking bdii, at least in its current form. It looks like a package which pretty much fails to comply with the freeze policy, so unless you come up with minimal changes to only fix actual bugs… (Hint: new upstream release, changing configuration, adding features, fixing lintian warnings, rewriting copyright, etc. are *not* things to do in unstable when you have RC bug fixes you want to get into testing.) Mraw, KiBi. Thank you for your feedback. I here attach a debdiff for a proposed backport of the fix to the RC bug only. Is this an acceptable change? diff -Nru bdii-5.2.5/debian/bdii.lintian-overrides bdii-5.2.5/debian/bdii.lintian-overrides --- bdii-5.2.5/debian/bdii.lintian-overrides 2011-06-14 11:58:13.0 +0200 +++ bdii-5.2.5/debian/bdii.lintian-overrides 2012-08-24 09:09:48.0 +0200 @@ -1,2 +1,2 @@ -bdii: non-standard-file-perm *etc/bdii/bdii-slapd.conf 0640 != 0644 -bdii: non-standard-file-perm *etc/bdii/bdii-top-slapd.conf 0640 != 0644 +bdii: non-standard-file-perm *usr/share/bdii/bdii-slapd.conf 0640 != 0644 +bdii: non-standard-file-perm *usr/share/bdii/bdii-top-slapd.conf 0640 != 0644 diff -Nru bdii-5.2.5/debian/bdii.postinst bdii-5.2.5/debian/bdii.postinst --- bdii-5.2.5/debian/bdii.postinst 2011-09-27 07:49:57.0 +0200 +++ bdii-5.2.5/debian/bdii.postinst 2012-08-24 11:00:12.0 +0200 @@ -3,14 +3,21 @@ set -e sed s/\(rootpw *\)secret/\1$(mkpasswd -s 0 | tr '/' 'x')/ \ --i /etc/bdii/bdii-slapd.conf /etc/bdii/bdii-top-slapd.conf +-i /usr/share/bdii/bdii-slapd.conf /usr/share/bdii/bdii-top-slapd.conf -chown openldap:openldap /etc/bdii/bdii-slapd.conf -chown openldap:openldap /etc/bdii/bdii-top-slapd.conf +chown openldap:openldap /usr/share/bdii/bdii-slapd.conf +chown openldap:openldap /usr/share/bdii/bdii-top-slapd.conf chown -R openldap:openldap /var/lib/bdii chown -R openldap:openldap /var/log/bdii +# Old versions with slapd configs listed in conffiles +dpkg-maintscript-helper rm_conffile \ +/etc/bdii/bdii-slapd.conf 5.2.5-2+wheezy1~ bdii -- $@ +dpkg-maintscript-helper rm_conffile \ +/etc/bdii/bdii-top-slapd.conf 5.2.5-2+wheezy1~ bdii -- $@ + # Remove obsolete cron script left behind by dpkg -rm -f /etc/cron.d/bdii-proxy +dpkg-maintscript-helper rm_conffile \ +/etc/cron.d/bdii-proxy 5.2.5-2+wheezy1~ bdii -- $@ #DEBHELPER# diff -Nru bdii-5.2.5/debian/bdii.postrm bdii-5.2.5/debian/bdii.postrm --- bdii-5.2.5/debian/bdii.postrm 1970-01-01 01:00:00.0 +0100 +++ bdii-5.2.5/debian/bdii.postrm 2012-08-24 11:00:12.0 +0200 @@ -0,0 +1,15 @@ +#!/bin/sh + +set -e + +# Old versions with slapd configs listed in conffiles +dpkg-maintscript-helper rm_conffile \ +/etc/bdii/bdii-slapd.conf 5.2.5-2+wheezy1~ bdii -- $@ +dpkg-maintscript-helper rm_conffile \ +/etc/bdii/bdii-top-slapd.conf 5.2.5-2+wheezy1~ bdii -- $@ + +# Remove obsolete cron script left behind by dpkg +dpkg-maintscript-helper rm_conffile \ +/etc/cron.d/bdii-proxy 5.2.5-2+wheezy1~ bdii -- $@ + +#DEBHELPER# diff -Nru bdii-5.2.5/debian/bdii.preinst bdii-5.2.5/debian/bdii.preinst --- bdii-5.2.5/debian/bdii.preinst 1970-01-01 01:00:00.0 +0100 +++ bdii-5.2.5/debian/bdii.preinst 2012-08-24 11:00:12.0 +0200 @@ -0,0 +1,15 @@ +#!/bin/sh + +set -e + +# Old versions with slapd configs listed in conffiles +dpkg-maintscript-helper rm_conffile \ +/etc/bdii/bdii-slapd.conf 5.2.5-2+wheezy1~ bdii -- $@ +dpkg-maintscript-helper rm_conffile \ +/etc/bdii/bdii-top-slapd.conf 5.2.5-2+wheezy1~ bdii -- $@ + +# Remove obsolete cron script left behind by dpkg +dpkg-maintscript-helper rm_conffile \ +/etc/cron.d/bdii-proxy 5.2.5-2+wheezy1~ bdii -- $@ + +#DEBHELPER# diff -Nru bdii-5.2.5/debian/changelog bdii-5.2.5/debian/changelog --- bdii-5.2.5/debian/changelog 2011-09-27 07:58:08.0 +0200 +++ bdii-5.2.5/debian/changelog 2012-08-24 09:08:29.0 +0200 @@ -1,3 +1,9 @@ +bdii (5.2.5-2+wheezy1) testing; urgency=low + + * Backport RC bug fix to wheezy (Closes: #663444) + + -- Mattias Ellert mattias.ell...@fysast.uu.se Fri, 24 Aug 2012 09:00:09 +0200 + bdii (5.2.5-2) unstable; urgency=low * Remove obsolete cron script left behind by dpkg (Closes: #642589) diff -Nru bdii-5.2.5/debian/rules bdii-5.2.5/debian/rules --- bdii-5.2.5/debian/rules 2011-09-04 20:21:31.0 +0200 +++ bdii-5.2.5/debian/rules 2012-08-24 10:49:27.0 +0200 @@ -45,6 +45,13 @@ sed s/BDII_USER=.*/BDII_USER=openldap/ \ -i debian/bdii/etc/bdii/bdii.conf + # Move bdii slapd config files out of /etc + mkdir debian/bdii/usr/share/bdii + mv debian/bdii/etc/bdii/bdii-slapd.conf debian/bdii/usr/share/bdii + mv debian/bdii/etc/bdii/bdii-top-slapd.conf debian/bdii/usr/share/bdii + ln -s ../../usr/share/bdii/bdii-slapd.conf debian/bdii/etc/bdii + ln -s ../../usr/share/bdii/bdii-top-slapd.conf debian/bdii/etc/bdii + binary-arch: # : @@ -60,6
Bug#683142: unblock: bdii/5.2.12-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception unblock bdii/5.2.12-1 Hi! The bdii package was removed from testing due to an RC bug, together with the packages that depends on it. The 5.2.12-1 update fixes the RC bug (bug #663444). I would like to request a freeze exception for this update to allow the bdii package and the packages depending on it to be part of the release. Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#683142: unblock: bdii/5.2.12-1
sön 2012-07-29 klockan 12:46 +0200 skrev Niels Thykier: On 2012-07-29 06:47, Mattias Ellert wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception unblock bdii/5.2.12-1 Hi! The bdii package was removed from testing due to an RC bug, together with the packages that depends on it. The 5.2.12-1 update fixes the RC bug (bug #663444). I would like to request a freeze exception for this update to allow the bdii package and the packages depending on it to be part of the release. Mattias Why did you include a new upstream release in this? It makes it harder for us to review and reduces the chance for you to get the unblock? Does this upstream release have important bug fixes, if so what are they? I had been preparing an update to a new upstream release for a long time before finally making the upload. On several occasions I have completed a potential update and then looked at the BTS and thought that I should fix that RC bug before doing the upload. Since fixing the RC bug was not trivial this always ment that I held off doing the upload. I finally did fix the RC bug. The fixed package compared to the last package I prepared and did not upload was really just fixing the RC bug. The changes in the package between the previous upload and the new one are very minor. It is true that if you list the files changed the list is not short, but most of the changed files are in the debian directory. These changes are there to do the fix of the RC bug, fix some lintian warnings and update the copyright file to the new recommended format. The changes to the patches are just dropping the parts of the patches that were accepted upstream and rebasing the remaining parts. For the changes to the upstream itself, i.e. the files outside the debian directory. These are mainly changes to the default configuration to reduce the memory consumption and to add support for IPv6. --- bdii-5.2.5/debian/bdii.preinst +++ bdii-5.2.12/debian/bdii.preinst @@ -0,0 +1,16 @@ +#!/bin/sh + +set -e + +if [ $1 = upgrade ] ; then +if dpkg --compare-versions $2 lt 5.2.12 ; then +# Old versions with slapd configs listed in conffiles + if [ -w /var/lib/dpkg/info/bdii.conffiles ] ; then + sed -e /bdii-slapd.conf/d -e /bdii-top-slapd.conf/d \ + -i /var/lib/dpkg/info/bdii.conffiles + fi + rm -f /etc/bdii/bdii-slapd.conf /etc/bdii/bdii-top-slapd.conf +fi +fi + +#DEBHELPER# I think dpkg-maintscript-helper rm_conffile is what you want to be policy compliant, but I could be wrong. Yes this is probably a better idea. I was very happy when I managed to write a maintainer script that solved the RC bug. But looking at the code in the dpkg-maintscript-helper script I realize that there are corner cases that are not properly handled by by script. I haven't read the full diff, so there are possibly more issues lurking in it. In its current state, I am not inclined to grant an exception. ~Niels PS: urgency=high is no effect when the package is not in testing (in case you weren't aware of it) I was not aware. However, the package was in testing until 2 days before I did the upload. The fact the package was removed made the update very urgent - and then the urgency is ignored because it was removed Well... I don't make the rules. I can make another update using the dpkg-maintscript-helper script instead of my own not-so-great fix. If you truly do not want to take advantage of the fixes for memory usage and IPv6 support I could also upload a version where I backport the fix for the RC bug to the 5.2.5 version. But I personally think using the new version would be better. Let me know what you think is petter. Mattias signature.asc Description: This is a digitally signed message part
Bug#687517: ITP: gsi-openssh -- secure shell client and server with GSI authentication
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: gsi-openssh Version : 6.0p1 * URL : * License : Description : secure shell client and server with GSI authentication The gsi-openssh package provides a modified openssh client and server that supports Globus Security Infrastruction (GSI) authentication. Since the GSI library, like kerberos, is implemented using the GSSAPI interface, and linking to more than one GSSAPI implementation in the same binary is not possible, this modified version does not support kerberos authentication. This is also the reason why the GSI support can not be added to the standard Debian openssh package. If you need kerberos authentication the standard openssh client and server packages should be used instead of this modified version. smime.p7s Description: S/MIME cryptographic signature
Bug#687680: ITP: srm-ifce -- SRM client side library
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: srm-ifce Version : 1.33.0 * URL : https://svnweb.cern.ch/trac/lcgutil * License : Apache 2.0 Description : SRM client side library srm-ifce is a client side implementation of the SRMv1 and SRMv2 specification for GFAL1/2 and FTS. SRM means Storage Resource Manager Interface, it is a specification of a SOAP interface providing a generic way to manage distributed storage systems. signature.asc Description: This is a digitally signed message part
Bug#687682: ITP: gfal2 -- Grid file access library 2.0
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se Control: block -1 by 687680 * Package name: gfal2 Version : 2.0.0 * URL : https://svnweb.cern.ch/trac/lcgutil/wiki/gfal2 * License : Apache 2.0 Description : Grid file access library 2.0 GFAL 2.0 offers an a single and simple POSIX-like API for the file operations in grids and cloud environments. The set of supported protocols depends of the gfal2 plugin install. signature.asc Description: This is a digitally signed message part
Bug#688092: ITP: arc-gui-clients -- ARC Graphical Clients
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: arc-gui-clients Version : 1.3.1 * URL : http://sourceforge.net/projects/arc-gui-clients/ * License : Apache 2.0 Description : ARC Graphical Clients Provides graphical clients to the NorduGrid ARC middleware. smime.p7s Description: S/MIME cryptographic signature
Bug#687517: ITP: gsi-openssh -- secure shell client and server with GSI authentication
ons 2012-09-19 klockan 16:38 +0200 skrev Christoph Anton Mitterer: Hi Mattias. Why isn't it possible to link against more then one GSSAPI mechanism? There's even a patch https://bugzilla.mindrot.org/show_bug.cgi?id=958 which seem to just do this (and was just not accepted yet for other reasons). I just ask, cause this is quite some heavy duplication of software in Debian. Cheers, Chris. The patch attached to the bugzilla report mentioned above is an older version of the same NCSA patch which is the base for the patch used in the proposed package. With the older version it is not possible to build with both kerberos and gsi support either. The two different gssapi implementations define the same function names (as defined in the gssapi standard). You can not link a binary to two different libraries each providing a function X, and have some calls to X in the binary execute function X in one library and have other calls to the same function X in the same binary execute function X in the other library. The linker will choose the version provided by the first library in the link command and ignore the second. Mattias signature.asc Description: This is a digitally signed message part
Bug#687517: ITP: gsi-openssh -- secure shell client and server with GSI authentication
fre 2012-09-21 klockan 01:05 +0200 skrev Christoph Anton Mitterer: Can't one just dynamically load the desired library? It is not so easy to do. There exist some instructions on the net for using a modified version of the mechglue library to implement support for both kerberos and gsi in the same openssh binary, but this approach is far less tested than the proposed solution of having two different binaries. The mechglue solution is also much more complicated to configure - and it introduces additional configuration that is currently not needed also in order to support the already available kerberos authentication. The instructions for the mechglue solution explicitly advises against using it for client installations but instead use separate binaries for kerberos and gsi. Using two different binaries is far more simpler, more well tested and less invasive to existing installations. Having two different packages is also the solution implemented in Fedora. Mattias signature.asc Description: This is a digitally signed message part
Bug#685663: unblock nordugrid-arc/2.0.0-3
tor 2012-08-23 klockan 17:54 +0200 skrev Cyril Brulebois: Hi Mattias, Mattias Ellert mattias.ell...@fysast.uu.se (23/08/2012): The nordugrid-arc 2.0.0-3 package had already migrated to testing before the freeze, but was kicked out because a dependency of one of its binary packages was removed due to an RC classified bug. That package (bdii) has since been fixed and an unblock request for the fix has been filed. I'm not sure we're going to consider unblocking bdii, at least in its current form. It looks like a package which pretty much fails to comply with the freeze policy, so unless you come up with minimal changes to only fix actual bugs… (Hint: new upstream release, changing configuration, adding features, fixing lintian warnings, rewriting copyright, etc. are *not* things to do in unstable when you have RC bug fixes you want to get into testing.) Mraw, KiBi. Hi! bdii 5.2.5-2+wheezy3 was accepted into testing proposed updates on Nov 2. So the missing dependency of nordugrid-arc is back. Could nordugrid-arc be added to testing proposed updates too? Mattias signature.asc Description: This is a digitally signed message part
Bug#693971: openldap FTBFS on hurd-i386
Package: src:openldap Version: 2.4.31-1 Severity: serious Openldap fails to build on hurd-i386. The build has been tried in buildd three times and failed. The compilation itself completes and the build then fails during make check. Running ../../../tests/scripts/all for bdb... Executing all LDAP tests for bdb Starting test000-rootdse for bdb... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ../../../tests/scripts/test000-rootdse: 66: kill: No such process ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Test failed test000-rootdse failed for bdb make[3]: *** [bdb-mod] Error 255 make[2]: *** [test] Error 2 make[1]: *** [test] Error 2 dh_auto_test: make -j1 test returned exit code 2 make: *** [build-arch] Error 29 Mattias signature.asc Description: This is a digitally signed message part
Bug#683142: Updated version
retitle 683142 unblock: bdii/5.2.12-2 thanks An updated package using the dpkg-maintscript-helper script as requested is now available in unstable. Mattias signature.asc Description: This is a digitally signed message part
Bug#684747: RM: arcjobtool -- ROM; Code has not been ported to nordugrid-arc 2.x
Package: ftp.debian.org Severity: normal This package no longer works with version 2.x of nordugrid-arc. Mattias signature.asc Description: This is a digitally signed message part
Bug#656048: RM: globus-libtool -- ROM; GPT glue packages no longer needed in Globus Toolkit 5.2
Package: ftp.debian.org Severity: normal Upstream is no longer using a bundled version of libtool, so The GPT glue package is no longer needed in Globus Toolkit 5.2 Mattias signature.asc Description: This is a digitally signed message part
Bug#656047: RM: globus-openssl -- ROM; GPT glue packages no longer needed in Globus Toolkit 5.2
Package: ftp.debian.org Severity: normal Upstream is no longer using a bundled version of openssl, so The GPT glue package is no longer needed in Globus Toolkit 5.2 Mattias signature.asc Description: This is a digitally signed message part
Bug#656049: RM: globus-libxml2 -- ROM; GPT glue packages no longer needed in Globus Toolkit 5.2
Package: ftp.debian.org Severity: normal Upstream is no longer using a bundled version of libxml2, so The GPT glue package is no longer needed in Globus Toolkit 5.2 Mattias signature.asc Description: This is a digitally signed message part
Bug#656050: RM: globus-rsl-assist -- ROM; the package was merged with the globus-rsl in Globus Toolkit 5.2
Package: ftp.debian.org Severity: normal The files previously provided by the globus-rsl-assist package are now provided by the globus-rsl package in Globus Toolkit 5.2 Mattias signature.asc Description: This is a digitally signed message part
Bug#656051: RM: globus-gram-job-manager-setup-fork -- ROM; renamed to globus-gram-job-manager-fork in Globus Toolkit 5.2
Package: ftp.debian.org Severity: normal This package was renamed in Globus Toolkit 5.2 Mattias signature.asc Description: This is a digitally signed message part
Bug#656052: RM: globus-gram-job-manager-setup-condor -- ROM; renamed to globus-gram-job-manager-condor in Globus Toolkit 5.2
Package: ftp.debian.org Severity: normal This package was renamed in Globus Toolkit 5.2 Mattias signature.asc Description: This is a digitally signed message part
Bug#656053: RM: globus-gram-job-manager-setup-pbs -- ROM; renamed to globus-gram-job-manager-pbs in Globus Toolkit 5.2
Package: ftp.debian.org Severity: normal This package was renamed in Globus Toolkit 5.2 Mattias signature.asc Description: This is a digitally signed message part
Bug#656054: RM: globus-gram-job-manager-setup-sge -- ROM; renamed to globus-gram-job-manager-sge in Globus Toolkit 5.2
Package: ftp.debian.org Severity: normal This package was renamed in Globus Toolkit 5.2 Mattias signature.asc Description: This is a digitally signed message part
Bug#656055: RM: globus-gram-job-manager-setup-lsf -- ROM; package dropped in Globus Toolkit 5.2
Package: ftp.debian.org Severity: normal This package was dropped in Globus Toolkit 5.2 Mattias signature.asc Description: This is a digitally signed message part
Bug#662940: [Pkg-openldap-devel] Bug#662940: Bug#662940: slapd gives assertions for valid configuration
fre 2012-03-09 klockan 11:16 -0800 skrev Quanah Gibson-Mount: Fixed upstream with git commit 6143aa0c18c8e0f73f4855b884b30405adabfc99 Please test. --Quanah Rebuilding the openldap source package with the commit added as an additional patch results in a working slapd server. Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#662940: slapd gives assertions for valid configuration
Package: slapd Version: 2.4.28-1.1 Severity: normal When configuring the shell backend in slapd.conf the syntax is (see man slapd-shell): add pathname argument... bind pathname argument... compare pathname argument... and so on. That is the path to the script followed by its arguments. This has worked fine in the past. However, the current version 2.4.28-1.1 of the slapd server refuses to start if any arguments are given after the path name in the configuration file, with the following assertion: slapd: ../../../../servers/slapd/config.c:198: config_check_vals: Assertion `c-argc == 2' failed. For the configuration of the shell backend the assertion condition means that it is not possible to pass arguments to the script in the slapd.conf. The man pages documents that this should still be possible, and it has been working with earlier versions. Mattias signature.asc Description: This is a digitally signed message part
Bug#659739: lcgdm: FTBFS: undefined reference to `soap_init'
mån 2012-02-13 klockan 15:33 +0100 skrev Christoph Egger: Package: src:lcgdm Version: 1.8.2-1 Severity: serious Tags: sid wheezy Justification: fails to build from source (but built successfully in the past) Hi! I think the source package is good, it is just that the bin-nmu of lcgdm has to happen after the bin-nmu of cgsi-gsoap. On kfreebsd-amd64, mips and sparc the bin-nmu build succeeded. These all picked up libcgsi-gsoap-dev 1.3.4.2-4+b1, the others picked up libcgsi-gsoap-dev 1.3.4.2-4 and failed. If the build on the failed architectures are tried again when the libcgsi-gsoap-dev 1.3.4.2-4+b1 is available on these as well, I think they should succeed. Mattias Hi! Your package failed to build on the buildds: LD_LIBRARY_PATH=../shlib cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -fno-strict-aliasing -fPIC -D_LARGEFILE64_SOURCE -Dlinux -o dpmcopyd -Wl,-z,relro -Wl,-z,defs dpmcopy_main.odpmcopy_local.o dpmcopy_pull.o dpmcopy_push.o srmv2_ifce.o dpm_mysql_ifce.odpm_copyfile.o ../dpm/dpm_util.o ../dpm/dpmlogit.o ../dpm/sendrep.o srmv2C.osrmv2Client.o -lgsoap -lglobus_gass_copy -lglobus_ftp_client -lglobus_common -L../shlib -ldpm -llcgdm -lcgsi_plugin_voms -L/usr/lib/mysql -lmysqlclient /usr/lib/gcc/i486-kfreebsd-gnu/4.6/../../../libcgsi_plugin_voms.so: undefined reference to `soap_init' /usr/lib/gcc/i486-kfreebsd-gnu/4.6/../../../libcgsi_plugin_voms.so: undefined reference to `soap_init2' collect2: ld returned 1 exit status make[2]: *** [dpmcopyd] Error 1 Full build log at https://buildd.debian.org/status/fetch.php?pkg=lcgdmarch=kfreebsd-i386ver=1.8.2-1%2Bb1stamp=1329134614 Regards Christoph smime.p7s Description: S/MIME cryptographic signature
Bug#664930: FTBFS
Hi! Is any of the maintainers of the package looking into fixing this? The cause of the problem is that a function declared in a header file in the heimdal package has changed its signature. The old header said: krb5_error_code hdb_generate_key_set_password ( krb5_context /*context*/, krb5_principal /*principal*/, const char */*password*/, Key **/*keys*/, size_t */*num_keys*/); The new version says: krb5_error_code hdb_generate_key_set_password ( krb5_context /*context*/, krb5_principal /*principal*/, const char */*password*/, krb5_key_salt_tuple */*ks_tuple*/, int /*n_ks_tuple*/, Key **/*keys*/, size_t */*num_keys*/); So there are two new arguments added in the middle at positions 4 and 5. The openldap code calls this function in one location in the file contrib/slapd-modules/smbk5pwd/smbk5pwd.c on line 470-471: ret = hdb_generate_key_set_password(context, ent.principal, qpw-rs_new.bv_val, ent.keys.val, nkeys); Without any knowledge about what this function does and what the smbk5pwd module is, the best I can do is to add a NULL and a 0 for the two new arguments: ret = hdb_generate_key_set_password(context, ent.principal, qpw-rs_new.bv_val, NULL, 0, ent.keys.val, nkeys); Adding a patch implementing this change makes the package compile. But since I have no idea what the module does, I also can not test if works with this patch. A package that builds at all is better than a package that is FTBFS though. Does anyone have a better idea? Mattias --- openldap-2.4.28.orig/contrib/slapd-modules/smbk5pwd/smbk5pwd.c 2011-11-25 19:52:29.0 +0100 +++ openldap-2.4.28/contrib/slapd-modules/smbk5pwd/smbk5pwd.c 2012-03-30 10:03:14.035984880 +0200 @@ -468,7 +468,7 @@ } ret = hdb_generate_key_set_password(context, ent.principal, - qpw-rs_new.bv_val, ent.keys.val, nkeys); + qpw-rs_new.bv_val, NULL, 0, ent.keys.val, nkeys); ent.keys.len = nkeys; hdb_seal_keys(context, db, ent); krb5_free_principal( context, ent.principal ); signature.asc Description: This is a digitally signed message part
Bug#664930: Info received (FTBFS)
Hi! No other suggestion put forward. I will do a bin NMU in a few days unless there are other solutions proposed. Mattias signature.asc Description: This is a digitally signed message part
Bug#715063: Reopen
reopen 715063 found 715063 2.7.5-7 notfixed 715063 2.7.5-7 thanks Hi! Unfortunately this doesn't seem to be fixed in version 2.7.5-7. See the build log at: http://buildd.debian-ports.org/status/fetch.php?pkg=lcgdmarch=sparc64ver=1.8.7-1stamp=1376397826 As can be seen from the log python version 2.7.5-7 is used: Selecting previously unselected package libpython2.7-minimal. Unpacking libpython2.7-minimal (from .../libpython2.7-minimal_2.7.5-7_sparc64.deb) ... Selecting previously unselected package libpython2.7-stdlib. Unpacking libpython2.7-stdlib (from .../libpython2.7-stdlib_2.7.5-7_sparc64.deb) ... Selecting previously unselected package libpython2.7. Unpacking libpython2.7 (from .../libpython2.7_2.7.5-7_sparc64.deb) ... Selecting previously unselected package libpython2.7-dev. Unpacking libpython2.7-dev (from .../libpython2.7-dev_2.7.5-7_sparc64.deb) ... Selecting previously unselected package python2.7-minimal. Unpacking python2.7-minimal (from .../python2.7-minimal_2.7.5-7_sparc64.deb) ... Selecting previously unselected package python2.7. Unpacking python2.7 (from .../python2.7_2.7.5-7_sparc64.deb) ... Selecting previously unselected package python2.7-dev. Unpacking python2.7-dev (from .../python2.7-dev_2.7.5-7_sparc64.deb) ... But the build still fails with: In file included from /usr/include/python2.7/Python.h:8:0, /usr/include/python2.7/pyconfig.h:57:50: fatal error: sparc-linux-gnu/python2.7/pyconfig.h: No such file or directory # include sparc-linux-gnu/python2.7/pyconfig.h So also version 2.7.5-7 tries to include sparc-linux-gnu/python2.7/pyconfig.h instead of sparc64-linux-gnu/python2.7/pyconfig.h It doesn't look like #elif defined(__sparc64__) works. Maybe the following will work better - it is from /usr/include/nspr/prcpucfg.h: #elif defined(__sparc__) defined (__arch64__) Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#714802: Reopen
reopen 714802 found 714802 2.7.5-7 notfixed 714802 2.7.5-7 thanks The wrong file is still included on sparc64. Use the conditional suggested in the original report: # elif defined(__sparc__) defined(__arch64__) Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#719947: ITP: davix -- Toolkit for http based file management
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: davix Version : 0.2.2 * URL : https://svnweb.cern.ch/trac/lcgutil/wiki/davix/ * License : LGPL-2.1+ Description : Toolkit for http based file management Davix is a toolkit designed for file operations with http based protocols (WebDav, Amazon S3, ...). Davix provides an API and a set of command line tools. smime.p7s Description: S/MIME cryptographic signature
Bug#709312: nmu: Packages depending on gsoap
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu The update of gsoap from version 2.8.7 to 2.8.12 has changed to package name for the gsoap libraries from libgsoap2 to libgsoap3. Depending packages therefore needs to be rebuilt. The cgsi-gsoap package required changes to the source package and has been updated. The voms package was updated because of a new upstream release (2.0.10-1) and was then rebuilt with the new gsoap version. The remaining packages should be binnmu'ed srm-ifce (1.15.2-2) gfal2 (2.2.1-2) - preferably built after srm-ifce due to build dep on srm-ifce-dev lcgdm (1.8.6-3) condor (7.8.2~dfsg.1-1+deb7u1 [unstable] and 7.8.7~dfsg.1-1 [exp]) virtualbox (4.2.10-dfsg-1 [contrib]) - only amd64 needs nmu, i386 was built with newer deps. Mattias signature.asc Description: This is a digitally signed message part
Bug#662940: slapd gives assertions for valid configuration
tor 2012-03-15 klockan 09:54 -0700 skrev Quanah Gibson-Mount: Thanks for the verification! --Quanah If there are no objections I can upload an NMU to fix this issue. Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#714427: Regex special characters need escaping in dbg-package-missing-depends test
Package: lintian
Version: 2.5.13
Severity: normal
The dbg-package-missing-depends test is broken for packages that contain
characters that have special meaning in regular expressions. Of the
characters that have special meaning in regular expressions, the full
stop (.) and the plus sign (+) are allowed in package names. These must
be escaped when the regular expression in the lintian test is created.
Proposed patch attached.
--- /usr/share/lintian/checks/fields.orig 2013-05-19 23:35:42.0 +0200
+++ /usr/share/lintian/checks/fields 2013-06-29 06:53:02.578878761 +0200
@@ -921,6 +921,7 @@
}
}
my $dstr = join ('|', @arch_dep_pkgs);
+$dstr =~ s/([.+])/\\$1/g;
my $depregex = qr/^(?:$dstr)$/;
foreach (@dbg_pkgs) {
my $deps = Lintian::Relation-and ($info-binary_relation ($_, 'pre-depends'),
signature.asc
Description: This is a digitally signed message part
Bug#714733: Inside a schroot environment renaming directories inside /tmp fails in GNU/Hurd
Package: schroot Version: 1.6.5-1 Severity: important User: debian-h...@lists.debian.org Usertags: hurd Inside a schroot environment renaming directories inside /tmp fails with Resource temporarily unavailable. This true not only for directories directly under /tmp, but also for directories further down a hierarchy within /tmp. Renaming directories in /tmp outside the schroot works fine. Renaming ordinary files in /tmp works fine also inside the schroot. Renaming directories outside of /tmp (e.g. in $HOME) works fine also inside the schroot. Here are some examples from the gnu/hurd debian porterbox exodar: ellert@exodar:~$ schroot -c sid (sid)ellert@exodar:~$ mkdir /tmp/A (sid)ellert@exodar:~$ mv /tmp/A /tmp/B mv: cannot move `/tmp/A' to `/tmp/B': Resource temporarily unavailable (sid)ellert@exodar:~$ exit logout ellert@exodar:~$ mv /tmp/A /tmp/B ellert@exodar:~$ schroot -c sid (sid)ellert@exodar:~$ mkdir -p /tmp/x/y/z/A (sid)ellert@exodar:~$ mv /tmp/x/y/z/A /tmp/x/y/z/B mv: cannot move `/tmp/x/y/z/A' to `/tmp/x/y/z/B': Resource temporarily unavailable (sid)ellert@exodar:~$ touch /tmp/C (sid)ellert@exodar:~$ mv /tmp/C /tmp/D (sid)ellert@exodar:~$ mkdir ~/A (sid)ellert@exodar:~$ mv ~/A ~/B (sid)ellert@exodar:~$ This problem causes build failures for one of my packages on gnu/hurd because the test suit run as part of the build fails due to this issue. Mattias signature.asc Description: This is a digitally signed message part
Bug#714733: [buildd-tools-devel] Bug#714733: Inside a schroot environment renaming directories inside /tmp fails in GNU/Hurd
tis 2013-07-02 klockan 11:43 +0100 skrev Roger Leigh: What's different about /tmp inside the chroot? Is it bind mounted (or the hurd equivalent) inside the chroot? What is the configuration you are using for this chroot; did you make any particular customisations? If you want to know details about how the schroot is configured on the porterbox, only the administrators of that machine can tell you. I was using the porterbox to figure out why one of my packages fails to build in the Debian build system for gnu/hurd. I did not do any tweaking of the configuration myself, but I have no idea if the porterbox admin has done something. Can you reproduce this manually without involving schroot? As mentioned in the bug report, outside the schroot there is no problem renaming directories in /tmp. I strongly suspect that this is a hurd-specific bug or configuration issue; while we might be able to work around such issues by avoiding it in the default hurd configuration, it would be good to know to start with what is actually causing the failure here. Yes it is hurd specific. The package that fails to build on gnu/hurd due to this issue builds without problem on all other architectures. This was the reason I added User: debian-h...@lists.debian.org Usertags: hurd to the bug report. Regarding the default configuration: The schroot source code contains system-specific configuration templates (etc/profile-templates) for linux and freebsd. There are currently no hurd templates, and if anyone wanted to create them that might give a better default experience for hurd users. This issue is the cause of failed package builds, see e.g. https://buildd.debian.org/status/fetch.php?pkg=myproxyarch=hurd-i386ver=5.9-1stamp=1358177698 This issue can be seen on both a gnu/hurd debian porter box and four different gnu/hurd sbuild hosts, so it seems to be a general problem affecting all gnu/hurd machines. I am sorry I can not provide more information, but I am no expert in gnu/hurd. I hope there is some gnu/hurd expert that can provide input. Thanks, Roger Mattias signature.asc Description: This is a digitally signed message part
Bug#664930: [Pkg-openldap-devel] Bug#664930: Bug#664930: Info received (FTBFS)
mån 2012-04-16 klockan 10:41 -0700 skrev Quanah Gibson-Mount: --On Monday, April 16, 2012 10:17 AM -0700 Quanah Gibson-Mount qua...@zimbra.com wrote: Hi Mattias, I've filed a bug with upstream (http://www.openldap.org/its/index.cgi/?findid=7247) on this issue. That would be the correct place for this to be fixed. What version of Heimdal was Debian using previously? What version of Heimdal is Debian using that you encountered this error against? Hi Mattias, I looked at the latest source for Heimdal (1.5.2) that is available. This header change does not exist there. What version of Heimdal is Debian using? --Quanah The version in debian is: heimdal 1.6~git20120311.dfsg.1-2 which looks like a prerelease version. The version the heimdal webpage offers for download is 1.5.2, as you say. Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#683142: unblock: bdii/5.2.12-1
fre 2012-08-31 klockan 14:01 +0200 skrev Niels Thykier: I believe the RC bug fix on 5.2.5-2 should be reasonable sane and lets take that as a starting point. ~Niels bdii_5.2.5-2+wheezy1 was uploaded to testing-proposed-updates. Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#687409: voms-api-java: FTBFS: cp: cannot stat `target/site/javadoc/apidocs': No such file or directory
block 687409 by 684963 thanks Hi! The reason why this source package does not build in wheezy is that bug #632183 (missing maven repo info in the bouncycastle package) is not fixed in wheezy. Wheezy has bouncycastle 1.44+dfsg-2 and the bug was fixed in bouncycastle 1.44+dfsg-3 already in July of 2011. This issue affects other packages too and an unblock request for bouncycastle 1.44+dfsg-3.1 exists (bug 684963). Mattias signature.asc Description: This is a digitally signed message part
Bug#705585: ITP: canl-c++ -- EMI Common Authentication Library - Bindings for C++
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: canl-c++ Version : 1.0.0 * URL : http://www.nordugrid.org/ * License : Apache 2 Description : EMI Common Authentication Library - Bindings for C++ EMI Common Authentication Library (caNl) - C++ bindings signature.asc Description: This is a digitally signed message part
Bug#685663: Upload to t-p-u
Hi! Since there was an RC bug reported against version 2.0.0-3 (some missing Replaces/Breaks), allowing this version back in to testing again would not be a good idea. I created a 2.0.0-3+wheezy1 version with the same fix that is in 2.0.0-5 and uploaded it to testing-proposed-updates. Mattias signature.asc Description: This is a digitally signed message part
Bug#695768: unblock globus-common/14.7-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception unblock globus-common/14.7-2 globus-common 14.7-2 implements a fix for an RC bug (#694392) that also affects the current version in testing (14.6-1). The changes between the 14.6 and 14.7 upstream source versions - ignoring the autotools generated files (aclocal.m4, Makefile.in, config.guess, config.sub, configure, install-sh, ltmain.sh, missing) - only consist of the addition of doxygen documentation to some previously undocumented functions and changing the version number. So no actual code changes. Mattias signature.asc Description: This is a digitally signed message part
Bug#696104: ITP: globus-gram-job-manager-lsf -- Globus Toolkit - LSF Job Manager Support
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: globus-gram-job-manager-lsf Version : 1.1 * URL : http://www.globus.org/ * License : Apache 2 Description : Globus Toolkit - LSF Job Manager Support This new package in Globus Toolkit 5.2.3 replaces the globus-gram-job-manager-setup-lsf package in earlier versions. signature.asc Description: This is a digitally signed message part
Bug#696118: ITP: globus-gridmap-verify-myproxy-callout -- Globus Toolkit - Globus gridmap myproxy callout
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: globus-gridmap-verify-myproxy-callout Version : 3.1 * URL : http://www.globus.org/ * License : Apache 2 Description : Globus Toolkit - Globus gridmap myproxy callout The Globus Toolkit is an open source software toolkit used for building Grid systems and applications. It is being developed by the Globus Alliance and many others all over the world. A growing number of projects and companies are using the Globus Toolkit to unlock the potential of grids for their cause. The globus-gram-audit package contains: Globus gridmap myproxy callout smime.p7s Description: S/MIME cryptographic signature
Bug#699515: RM: jglobus-myproxy -- ROM; This package has been merged into the jglobus package in the upstream sources
Package: ftp.debian.org Severity: normal The jglobus-myproxy sources have been integrated into the main jglobus sources upstream. The libjglobus-myproxy-java package is now built from the jglobus source package (version 2.0.5~rc2-1 - currently in the new queue). The separate jglobus-myproxy source package is obsolete. Mattias signature.asc Description: This is a digitally signed message part
Bug#715063: pyconfig.h wrapper tries to include the wrong file on sparc64
Package: libpython2.7-dev Version: 2.7.5-6 Severity: normal See buildd build log http://buildd.debian-ports.org/status/fetch.php?pkg=lcgdmarch=sparc64ver=1.8.6-4stamp=1372696760 /usr/include/python2.7/pyconfig.h:55:50: fatal error: sparc-linux-gnu/python2.7/pyconfig.h: No such file or directory This is a sparc64 build so sparc64-linux-gnu/python2.7/pyconfig.h should be included. But sparc-linux-gnu/python2.7/pyconfig.h is used instead, which is not installed, so the inclusion fails. signature.asc Description: This is a digitally signed message part
Bug#728179: transition: libgsoap4, libgridsite2, canl-c
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi! There are currently three packages that are somewhat tangled. 1) canl-c 2.1.2-1 This package is in the NEW queue - it is a new dependency for gridsite 2.0.4 below. 2) gridsite 2.0.4-2 Updated version of the gridsite package. Accepted in testing, but not buildable due to the missing canl-c. This update means a transition from libgridsite1.7 to libgridsite2. 3) gsoap 1.8.16-1 Updated gsoap package. This is in the NEW queue and means a transition for libgsoap3 to libgsoap4. The gridsite package above depends on gsoap. Packages needing rebuild: canl-c (in NEW queue) gsoap (in NEW queue) gridsite (depends canl-c, gsoap) voms (depends gsoap) cgsi-gsoap (depends gsoap, voms) lcgdm (depends gsoap, cgsi-gsoap, voms) srm-ifce (depends cgsi-gsoap) gfal2 (depends gsoap, gridsite, lcgdm, srm-ifce) nordugrid-arc (depends gridsite) condor (depends gsoap) virtualbox [contrib] (depends gsoap) Mattias signature.asc Description: This is a digitally signed message part
Bug#728636: lcgdm: FTBFS: libcgsi_plugin_voms.so: undefined reference to `soap_init_LIBRARY_VERSION_REQUIRED_20812'
block 728636 by 728179 thanks sön 2013-11-03 klockan 18:00 +0100 skrev David Suárez: Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): cc -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fno-strict-aliasing -fPIC -D_LARGEFILE64_SOURCE -Dlinux -g -I../h -I/usr/include -I/usr/include -pthread -DCTHREAD_LINUX -D_THREAD_SAFE -D_REENTRANT -DDPMCONFIG=\/etc/DPMCONFIG\ -DLOGFILE=\/usr/../var/log/srmv1/log\ -DUSE_MYSQL -DCSEC -DVIRTUAL_ID -DUSE_VOMS -DWITH_IPV6 -DWITH_NO_IPV6_V6ONLY -DWITH_DOM -I/usr/include/mysql-c -o srmv1Server.o srmv1Server.c LD_LIBRARY_PATH=../shlib cc -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fno-strict-aliasing -fPIC -D_LARGEFILE64_SOURCE -Dlinux -o srmv1 -Wl,-z,relro -Wl,-z,defs srmv1.o srmv1_procreq.o srm_util.o srmlogit.o ../dpm/dpm_mysql_ifce.o ../dpm/dpm_util.o ../dpm/dpmlogit.o srmv1C.osrmv1Server.o -pthread -lgsoap -L../shlib -ldpm -llcgdm -luuid -lcgsi_plugin_voms -L/usr/lib/mysql -lmysqlclient /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/libcgsi_plugin_voms.so: undefined reference to `soap_init_LIBRARY_VERSION_REQUIRED_20812' collect2: error: ld returned 1 exit status Hi! The rebuild has happened in the middle of a transition of some of the packages the lcgdm package build requires. lcgdm build requires gsoap. Gsoap has recently been updated from version 2.8.12 to version 2.8.16, which has caused a transition form libgsoap3 to libgsoap4. lcgdm also build requires cgsi-gsoap-dev, which in turn depends on gsoap. cgsi-gsoap has not yet been binnmued due to the gsoap transition. The lcgdm rebuild drags in both libgsoap4 (from the gsoap build requirement) and the old libgsoap3 (from the cgsi-gsoap-dev requirement) and then tries to link the cgsi-gsoap (built for libgsoap3) and libgsoap4 together and fails - which is the correct thing to do. Please retry again once the cgsi-gsoap binnmu due to the gsoap transition has been competed. Setting blocked-by the transition bug. Mattias signature.asc Description: This is a digitally signed message part
Bug#728636: Reduce severity
severity 728636 important thanks Since no changes are needed to the source package to fix this issue the severity of this bug is reduced. The issue should be fixed by binmnus of the broken dependencies. Mattias signature.asc Description: This is a digitally signed message part
Bug#728179: Is anyone handling this?
Is anyone receiving this bug report? It was filed a month ago and I have not received any response so far. Since my last mail nordugrid-arc was updated to a new version and was built with the new gridsite, so it no longer needs a binnmu. nmu gridsite . amd64 i386 powerpc sparc . -m Rebuild against libgsoap4 nmu voms . ALL . -m Rebuild against libgsoap4 nmu cgsi-gsoap . ALL . -m Rebuild against libgsoap4 nmu lcgdm . ALL . -m Rebuild against libgsoap4 dw lcgdm . ALL . -m libcgsi-gsoap-dev ( 1.3.5-2+b1) nmu srm-ifce . ALL . -m Rebuild against libgsoap4 dw srm-ifce . ALL . -m libcgsi-gsoap-dev ( 1.3.5-2+b1) nmu gfal2 . ALL . -m Rebuild against libgsoap4 and libgridsite2 dw gfal2 . ALL . -m srm-ifce-dev ( 1.18.0-1+b1) nmu condor . ALL . -m Rebuild against libgsoap4 nmu virtualbox . amd64 i386 . -m Rebuild against libgsoap4 signature.asc Description: This is a digitally signed message part
Bug#728179: Is anyone handling this?
Due to changes in other build dependencies unrelated to the gsoap update the cgsi-gsoap and lcgdm packages needed changes to the source package. The need for binnmu of these packages therefore no longer exists. The following is still needed: nmu gridsite . amd64 i386 powerpc sparc . -m Rebuild against libgsoap4 nmu voms . ALL . -m Rebuild against libgsoap4 nmu srm-ifce . ALL . -m Rebuild against libgsoap4 nmu gfal2 . ALL . -m Rebuild against libgsoap4 and libgridsite2 dw gfal2 . ALL . -m srm-ifce-dev ( 1.18.0-1+b1) nmu condor . ALL . -m Rebuild against libgsoap4 nmu virtualbox . amd64 i386 . -m Rebuild against libgsoap4 Mattias signature.asc Description: This is a digitally signed message part
Bug#728179: Thanks
sön 2013-12-01 klockan 19:02 +0100 skrev Mattias Ellert: dw gfal2 . ALL . -m srm-ifce-dev ( 1.18.0-1+b1) That should have been = 1.18.0-1+b1 - sorry for screwing up. And many thanks for executing the nmus. Mattias signature.asc Description: This is a digitally signed message part
Bug#723913: latex2html causes condor not to build
block 728179 by 723913 thanks The condor binnmu due to the gsoap update failed during documentation generation due to a recent problem with latex2html. If \captions are removed from all \tables and \figures in the documentation the build succeeds, but that is clearly not the right thing to do... Mattias signature.asc Description: This is a digitally signed message part
Bug#731246: condor: Needs to adapt to Globus Toolkit multi-arch support
Source: condor
Version: 7.8.8~dfsg.1-2
Severity: serious
With the recent update of Globus Toolkit to version 5.2.5, the debian
packages implements Multi-Arch support. For this reason the install
location for the architecture dependent header files had to be changed.
For packages that depend on Globus Toolkit and use pkg-config to find
the location of the headers, this change is seamless. The condor package
however, hardcodes the install location in its cmake files and will fail
to build if a rebuild is attempted.
The attached patch adds the new install location to the build
configuration. (An alternative approach would be to convert the build
configuration to use pkg-config instead, but that might be more
invasive.)
Mattias
PS. At the moment the condor build also fails due to a broken latex2html
that goes into an endless loop during generation of the documentation
files. (See BTS #723913)
diff -ur condor-7.8.8~dfsg.1.orig/externals/bundles/globus/5.0.1-p1/CMakeLists.txt condor-7.8.8~dfsg.1/externals/bundles/globus/5.0.1-p1/CMakeLists.txt
--- condor-7.8.8~dfsg.1.orig/externals/bundles/globus/5.0.1-p1/CMakeLists.txt 2013-07-18 08:25:54.0 +0200
+++ condor-7.8.8~dfsg.1/externals/bundles/globus/5.0.1-p1/CMakeLists.txt 2013-12-03 14:46:49.921645208 +0100
@@ -227,7 +227,16 @@
find_multiple( globus_gass_transfer;globus_gram_client;globus_gram_protocol GLOBUS_GRID_UNIVERSE_GT2 )
find_multiple( globus_ftp_control GLOBUS_GRID_UNIVERSE_NORDUGRID)
if (GLOBUS_FOUND)
- append_var (CONDOR_EXTERNAL_INCLUDE_DIRS /usr/include/globus;/usr/lib64/globus/include;/usr/lib/globus/include;/usr/local/globus/include/globus)
+ find_program(DPKG_ARCHITECTURE dpkg-architecture)
+ if (DPKG_ARCHITECTURE)
+ execute_process(
+ COMMAND ${DPKG_ARCHITECTURE} -qDEB_HOST_MULTIARCH
+ OUTPUT_VARIABLE DEB_HOST_MULTIARCH
+ OUTPUT_STRIP_TRAILING_WHITESPACE)
+ else()
+ set (DEB_HOST_MULTIARCH no-deb-multiarch)
+ endif()
+ append_var (CONDOR_EXTERNAL_INCLUDE_DIRS /usr/include/globus;/usr/lib64/globus/include;/usr/lib/globus/include;/usr/include/${DEB_HOST_MULTIARCH}/globus;/usr/local/globus/include/globus)
endif(GLOBUS_FOUND)
endif(NOT PROPER)
signature.asc
Description: This is a digitally signed message part
Bug#731547: Regression in hurd threading
Package: hurd Severity: important The nordugrid-arc 4.0.0 update failed to build on hurd on 2013-11-30. The build itself succeeds but the test suite fails. I can reproduce this on the hurd porter box. The previous version nordugrid-arc 3.0.3 did build on hurd. That build happened on 2013-08-07. If I now try to rebuild nordugrid-arc 3.0.3, i.e. the build that previously succeeded, on the porter box, also this version now fails with the same error as the new 4.0.0 version. So some change to the hurd system, between 2013-08-07 and now, has caused a regression that causes the nordugrid-arc build that used to succeed to now fail. I have not been able to find where the problem is, but from a backtrace it looks like it is related to threading issues. But if it is the hurd base system, the libc or the glib/glibmm/sigc++ that is at fault I am not sure. If anyone that is familiar with hurd could have a look? Mattias (gdb) bt #0 g_thread_create_full (func=0x15af7e0, data=0x8061ec8, stack_size=16777216, joinable=0, bound=0, priority=G_THREAD_PRIORITY_NORMAL, error=0x1dff74c) at /build/buildd-glib2.0_2.36.4-1-hurd-i386-XxEnQA/glib2.0-2.36.4/./glib/deprecated/gthread-deprecated.c:379 #1 0x015b005c in Glib::Thread::create(sigc::slotvoid, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil const, unsigned long, bool, bool, Glib::ThreadPriority) () from /usr/lib/i386-gnu/libglibmm-2.4.so.1 #2 0x0107681c in Arc::ThreadPool::CheckQueue (this=this@entry=0x805b338) at Thread.cpp:190 #3 0x01076aa8 in Arc::ThreadPool::PushQueue (this=0x805b338, arg=arg@entry=0x8061940) at Thread.cpp:208 #4 0x01077aff in Arc::CreateThreadFunction ( func=func@entry=0x804e830 LoggerTest::thread(void*), arg=arg@entry=0x8060dd0, count=count@entry=0x0) at Thread.cpp:263 #5 0x0804db55 in LoggerTest::TestLoggerTHREAD (this=0x8060dd0) at LoggerTest.cpp:90 #6 0x012a0fb0 in CppUnit::TestCaseMethodFunctor::operator()() const () from /usr/lib/i386-gnu/libcppunit-1.13.so.0 #7 0x012978b9 in CppUnit::DefaultProtector::protect(CppUnit::Functor const, CppUnit::ProtectorContext const) () from /usr/lib/i386-gnu/libcppunit-1.13.so.0 #8 0x0129e5e1 in CppUnit::ProtectorChain::ProtectFunctor::operator()() const () from /usr/lib/i386-gnu/libcppunit-1.13.so.0 #9 0x0129e2c1 in CppUnit::ProtectorChain::protect(CppUnit::Functor const, CppUnit::ProtectorContext const) () from /usr/lib/i386-gnu/libcppunit-1.13.so.0 #10 0x012a750d in CppUnit::TestResult::protect(CppUnit::Functor const, CppUnit::Test*, std::string const) () from /usr/lib/i386-gnu/libcppunit-1.13.so.0 #11 0x012a0cdf in CppUnit::TestCase::run(CppUnit::TestResult*) () from /usr/lib/i386-gnu/libcppunit-1.13.so.0 #12 0x012a13c4 in CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) () from /usr/lib/i386-gnu/libcppunit-1.13.so.0 #13 0x012a12eb in CppUnit::TestComposite::run(CppUnit::TestResult*) () from /usr/lib/i386-gnu/libcppunit-1.13.so.0 #14 0x012a13c4 in CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) () from /usr/lib/i386-gnu/libcppunit-1.13.so.0 #15 0x012a12eb in CppUnit::TestComposite::run(CppUnit::TestResult*) () from /usr/lib/i386-gnu/libcppunit-1.13.so.0 #16 0x012a92e0 in CppUnit::TestRunner::WrappingSuite::run(CppUnit::TestResult*) () from /usr/lib/i386-gnu/libcppunit-1.13.so.0 #17 0x012a6e0b in CppUnit::TestResult::runTest(CppUnit::Test*) () from /usr/lib/i386-gnu/libcppunit-1.13.so.0 #18 0x012a9114 in CppUnit::TestRunner::run(CppUnit::TestResult, std::string const) () from /usr/lib/i386-gnu/libcppunit-1.13.so.0 #19 0x012ab61b in CppUnit::TextTestRunner::run(CppUnit::TestResult, std::string const) () from /usr/lib/i386-gnu/libcppunit-1.13.so.0 #20 0x012ab921 in CppUnit::TextTestRunner::run(std::string, bool, bool, bool) () from /usr/lib/i386-gnu/libcppunit-1.13.so.0 #21 0x0804b4b2 in main (argc=1, argv=0x1dffdc4) at ../../../../../src/Test.cpp:33 signature.asc Description: This is a digitally signed message part
Bug#731246: condor: Needs to adapt to Globus Toolkit multi-arch support
tis 2013-12-03 klockan 19:04 +0100 skrev Michael Hanke: PS. At the moment the condor build also fails due to a broken latex2html that goes into an endless loop during generation of the documentation files. (See BTS #723913) Ah, thanks for the pointer! This is the issue that is currently holding up an upload of condor 8.x. Cheers, Michael The perl regression that was identified as the cause of the broken latex2html has been resolved in perl 5.18.1-5. Mattias signature.asc Description: This is a digitally signed message part
Bug#720300: gridsite: some shipped files are not included in md5sums
tis 2013-08-20 klockan 10:40 +0200 skrev Andreas Beckmann: Hi, during a test with piuparts I noticed your package does not include md5sums for all the files it ships: gridsite: FILE WITHOUT MD5SUM /var/lib/gridsite/.gacl gridsite: FILE WITHOUT MD5SUM /var/lib/gridsite/gridsitefoot.txt gridsite: FILE WITHOUT MD5SUM /var/lib/gridsite/gridsitehead.txt If these files are intended to be modified, they should be managed by maintainer scripts instead of being shipped. Currently they will be overwritten on every upgrade. These files are properly listed as configuration files in the dpkg metadata of the package: $ cat /var/lib/dpkg/info/gridsite.conffiles /var/lib/gridsite/.gacl /var/lib/gridsite/gridsitefoot.txt /var/lib/gridsite/gridsitehead.txt /etc/apache2/sites-available/gridsite.conf /etc/apache2/mods-available/zgridsite.load /etc/apache2/mods-available/zgridsite.conf They are handled by the normal configure file mechanism in dpkg, and the md5sums are tracked in the package status, the same way it is for other configuration files. $ dpkg --status gridsite Package: gridsite Status: install ok installed [ ... ] Conffiles: /var/lib/gridsite/.gacl 88f4b45b6569fac47298439f2c911db5 /var/lib/gridsite/gridsitefoot.txt 45ae35fb1a24a05bfbea36c3500ed5ba /var/lib/gridsite/gridsitehead.txt 80aaad7a677d7bd24c8e7e7594befa06 /etc/apache2/sites-available/gridsite.conf a7a43c456129084c6fb1c538e01ed0ae /etc/apache2/mods-available/zgridsite.load 8841babc5836a6b0264cffd6b4be1582 /etc/apache2/mods-available/zgridsite.conf 500abc73c2856aa23af9bf3a33f45caf [ ... ] On package upgrade the files are managed correctly by dpkg. There is no need for any additional managing using maintainer scripts. If the file in the new package differs from the file in the old package the file is replaced if the installed file has not been changed and otherwise not. Which is the expected behaviour. I don't see where the bug is here. Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#720611: nmu: cgsi-gsoap on sh4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, libcgsi-gsoap1_1.3.5-2 was built against libgsoap3 on all architectures except sh4, where it was built against libgsoap2. nmu libcgsi-gsoap1_1.3.5-2 . sh4 . -m Rebuild for libgsoap3 smime.p7s Description: S/MIME cryptographic signature
Bug#687694: Close?
Isn't it time to close this now? Mattias signature.asc Description: This is a digitally signed message part
Bug#729487: ITP: globus-xio-gridftp-driver -- Globus Toolkit - Globus XIO GridFTP Driver
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: globus-xio-gridftp-driver Version : 1.1 * URL : http://www.globus.org/ * License : Apache 2 Description : Globus Toolkit - Globus XIO GridFTP Driver This is a new package in Globus Toolkit 5.2.5. smime.p7s Description: S/MIME cryptographic signature
Bug#729486: ITP: globus-gram-job-manager-slurm -- Globus Toolkit - SLURM Job Manager Support
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: globus-gram-job-manager-slurm Version : 1.2 * URL : http://www.globus.org/ * License : Apache 2 Description : Globus Toolkit - SLURM Job Manager Support This new package in Globus Toolkit 5.2.5 provides support for the SLURM LRMS in the Globus GRAM job manager. smime.p7s Description: S/MIME cryptographic signature
Bug#729681: globus-core: should not migrate yet
Source: globus-core Version: 8.16-1 Severity: serious The full Globus Toolkit 5.2.5 should migrate to testing together. However many of the updated packages got diverted to the new queue due to package splits/renames done in order to support Multi-Arch. This bug is filed to prevent the migration of globus-core before the packages diverted to the new queue are ready to migrate. Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#728179: Status
Current status: canl-c (accepted - built for all primary archs) gsoap (update accepted - built for all primary archs. libgsoap3 needs removal - replaced with libgsoap4) gridsite (amd64, i386, powerpc and sparc need binnmu for libgsoap3 → libgsoap4 transition. libgridsite1.7 needs removal - replaced with libgridsite2) voms (all primary archs need binnmu for libgsoap3 → libgsoap4 transition) cgsi-gsoap (all primary archs need binnmu for libgsoap3 → libgsoap4 transition) lcgdm (all primary archs need binnmu for libgsoap3 → libgsoap4 transition - must be done after the cgsi-gsoap binnmu) srm-ifce (all primary archs need binnmu for libgsoap3 → libgsoap4 transition - must be done after the cgsi-gsoap binnmu) gfal2 (all primary archs need binnmu for libgsoap3 → libgsoap4 and libgridsite1.7 → libgridsite2 transitions - must be done after the srm-ifce binnmu) nordugrid-arc (all primary archs need binnmu for libgridsite1.7 → libgridsite2 transition) condor (all primary archs need binnmu for libgsoap3 → libgsoap4 transition) virtualbox [contrib] (amd64 and i386 need binnmu for libgsoap3 → libgsoap4 transition) Mattias signature.asc Description: This is a digitally signed message part
Bug#724665: ITP: canl-c -- EMI Common Authentication Library - Bindings for C
Package: wnpp Severity: wishlist Owner: Mattias Ellert mattias.ell...@fysast.uu.se * Package name: canl-c Version : 2.1.2 * URL : http://www.eu-emi.eu/ * License : Apache 2 Description : EMI Common Authentication Library - Bindings for C EMI Common Authentication Library (caNl) - C bindings smime.p7s Description: S/MIME cryptographic signature
Bug#728179: migration?
As far as I can see the migration should be able to happen now. There are no longer any packages in unstable that depends on libgsoap3. https://ftp-master.debian.org/cruft-report-daily.txt says: * source package gsoap version 2.8.16-2 no longer builds binary package(s): libgsoap3 on armel,armhf,i386,ia64,mips,mipsel,powerpc,sparc - suggested command: dak rm -m [auto-cruft] NBS (no longer built by gsoap) -s unstable -a armel,armhf,i386,ia64,mips,mipsel,powerpc,sparc -p -R -b libgsoap3 - No dependency problem found Maybe some hinting is needed? Mattias signature.asc Description: This is a digitally signed message part
Bug#736522: RM: condor-doc [kfreebsd-amd64 kfreebsd-i386] -- NBS
Package: ftp.debian.org Severity: normal The condor source package has never successfully built on kfreebsd-amd64 and kfreebsd-i386. However, the arch-indep documentation package condor-doc is available there. This is currently causing problems for the migration. Mattias Ellert (NMU uploader of the previous version that the new version is trying to replace) signature.asc Description: This is a digitally signed message part
Bug#731246: condor: Needs to adapt to Globus Toolkit multi-arch support
Hi! Is there an estimate from the maintainers when this might be fixed? I know that there is some ongoing work to update condor to version 8, and that this issue might get fixed in the process. Will that happen soon? If such an update is still some time away, are there plans to provide a minor update to the current version to fix this issue? If you so desire, I can offer to make an nmu that only adds the patch proposed to the current version so that this issue can be fixed. The condor package is currently blocking the libgsoap4 transition and a successful build is needed to complete it. Let me know if you think an nmu is a good idea or if this will disrupt your planned work. Mattias signature.asc Description: This is a digitally signed message part
Bug#753963: [gsoap] Some sources are not included in your package
sön 2014-07-06 klockan 19:14 + skrev bastien ROUCARIES: Package: gsoap Version: 2.8.16-3 user: lintian-ma...@debian.org usertags: source-is-missing severity: serious X-Debbugs-CC: ftpmas...@debian.org Hi, Your package seems to include some files that lack sources in prefered forms of modification: gsoap/bin/linux386/soapcpp2 gsoap/bin/linux386/wsdl2h gsoap/doc/dom/html/jquery.js gsoap/doc/httpda/html/jquery.js gsoap/doc/wsa/html/jquery.js gsoap/doc/wsdd/html/jquery.js gsoap/doc/wsrm/html/jquery.js gsoap/doc/wsse/html/jquery.js gsoap/doc/xml-rpc-json/html/jquery.js gsoap/samples/databinding/html/jquery.js You override this warning using this file: # These binaries are not used during the build nor are they packaged source-is-missing gsoap/bin/linux386/* # These bundled copies of jquery.js are replaced by symlinks during the build source-is-missing gsoap/doc/*/html/jquery.js source-is-missing gsoap/samples/databinding/html/jquery.js The code for precompiled binaries in upstream's distribution are in the sources. If they were not it would not be possible to compile the version of the binaries that are installed from the sources. The source for soapcpp2 is ./gsoap/src The source for wsdl2h is ./gsoap/wsdl So the sources are not missing. Regarding the jquery.js files I am not sure what to say. These jquery.js files are part of doxygen generated documentation that is pre-generated by upstream and included in their source distribution. When lintian started to complain about the presence of the jquery.js files in the documentation I made lintian no longer complain about that by replacing them with symlinks to debian's system version. This of course only works if the debian system jquery.js is compatible with the jquery.js that doxygen provides as part if the documentation it generates. I have since then found that this is not the case and that replacing the doxygen jquery.js with debian's version is a broken solution to the problem. The /usr/share/doc/doxygen/README.jquery file says a lot of things, but ends with: It is not considered a problem for Doxygen or packages using Doxygen to embed jquery. In fact replacing the `jquery.js` file created by Doxygen likely results in broken documentation. Packages doing that are buggy. Lintian will have to learn that a `jquery.js` embedded by Doxygen is a normal thing. So in order to implement the recommendations from the doxygen maintainer I should revert my attempt to make lintian happy by replacing the jquery.js with a symlink. The jquery.js that is part of the documentation is the one that is embedded in the doxygen binary on the computer that is generating the documentation. So this will either be the copy of doxygen that is installed on the upstream developer's machine when the documentation is generated (in case the doxygen generated documentation is pre-generated and part of the sources) or the copy of doxygen in the package build root (in case the doxygen documentation is generated or regenerated as part of the build). The source of this jquery.js file will never be part of the source package of the package that installs it. It will always come from an embedded copy inside doxygen which, at least at present, can not be replaced by the debian system version. Do the ftp-masters as a collective have a consensus point of view on doxygen generated documentation? Is packaging of pre-generated documentation that is part of upstream's sources acceptable, or must all doxygen generated documentation be regenerated as part of the package build? If packaging of pre-generated documentation is allowed, then having jsquery.js files in the source tarball must be allowed. If all copies of jquery.js must be purged from all source tarballs this means the all pre-generated doxygen documentation is banned. Mattias smime.p7s Description: S/MIME cryptographic signature
Bug#750446: LaTeX Error: Unknown float option `H'
Package: texlive
Version: 2014.20140528-3
Severity: serious
\begin{figure}[H] fails with:
LaTeX Error: Unknown float option `H'
This causes build failures for packages that generate documentation
using Doxygen. See e.g.:
http://aws-logs.debian.net/ftbfs-logs/2014/06/01/globus-common_14.10-2_unstable.log
http://aws-logs.debian.net/ftbfs-logs/2014/06/01/globus-ftp-client_7.6-1_unstable.log
This is a regression from earlier versions.
Mattias
signature.asc
Description: This is a digitally signed message part
Bug#750446: LaTeX Error: Unknown float option `H'
ons 2014-06-04 klockan 10:11 +0900 skrev Norbert Preining:
Hi Mattias,
\begin{figure}[H] fails with:
LaTeX Error: Unknown float option `H'
Yes, which is correct, the document is simply wrong. H is not
a proper float option.
This is incorrect. The default float command does bot provide an H
placement specifier. However, if the float package is loaded the
default float command is overridden with a float command that does have
such a specifier.
As can be seen from the log, this document uses the float package:
(/usr/share/texlive/texmf-dist/tex/latex/float/float.sty)
http://ctan.uib.no/macros/latex/contrib/float/README says:
The float package
=
This package improves the interface for defining floating objects such
as figures and tables in LaTeX. It adds the notion of a `float style'
that governs appearance of floats. New kinds of floats may be defined
using a \newfloat command analogous to \newtheorem. This style option
also incorporates the functionality of David Carlisle's style option
`here', giving floating environments a [H] option which means `PUT IT
HERE' (as opposed to the standard [h] option which means `You may put
it here if you like').
This is a regression from earlier versions.
No and yes.
No, because if you just use LaTeX2e as is, then unknown specifiers
are still ignored.
But the document under discussion used
fixltx2e.sty
as seen from this line
(/usr/share/texlive/texmf-dist/tex/latex/base/fixltx2e.sty)
And that means that *bugs* in the latex code will be fixed.
That also means, that with LaTeX from 2014/05/01 you get errors:
See ltnews.pdf, available in
/usr/share/doc/texlive-doc/latex/base/ltnews.pdf
Which states:
--
There are a number of bugs and faulty design decisions
in LaTeX2e that should have been corrected long ago in
the kernel code. However, such corrections cannot be
done as this would break backwards compatibility in
^^^
the following sense. A large number of documents exist
by now that have worked around the bug or have even
made use of a particular misfeature. Thus changing the
kernel code would break too many existing documents.
The corrections for these types of bug have therefore
been collected together in a package that can be loaded
only when needed; its name is fixltx2e. For this release
we made the following changes to this package:
• Misspelled float placement specifiers such as
\begin{figure}[tv] instead of tb are silently
ignored by the kernel code. Now we test for such
letters and issue an error message.
...
Adding syntax checks is all well and good. But if you add syntax checks
for a command and still apply them when the command is overridden and
no longer has the same syntax as the original command, then your syntax
checks are causing the breakage.
When a command is overridden you must either modify your check
accordingly, or not apply the check.
Enjoy. I am closing this bug. This has to be fixed in the
original documents.
As explained above the original documents are not wrong, they just use a
different version of the float command than the one you are checking the
syntax for. In my experience the use of the H placement options for
floats is very widespread.
PS. You failed to close the bug by misspelling the email address. If you
had closed it I would have reopened it due to the reasons stated above.
Norbert
Mattias
smime.p7s
Description: S/MIME cryptographic signature
Bug#750536: LaTeX Error: Unknown float option `H'
Package: doxygen
Version: 1.8.7-1
Severity: serious
Generation documentation from the doxygen generated latex source fails
with:
\begin{figure}[H] fails with:
LaTeX Error: Unknown float option `H'
See e.g.:
http://aws-logs.debian.net/ftbfs-logs/2014/06/01/globus-common_14.10-2_unstable.log
http://aws-logs.debian.net/ftbfs-logs/2014/06/01/globus-ftp-client_7.6-1_unstable.log
The reason for this is an updated version of the fixltx2e package in the
latest texlive version that adds syntax checking to the float command.
This check is confused if the float package is included before the
fixltx2e package, as is done in the doxygen generated sources.
Fix available as a github pull request:
https://github.com/doxygen/doxygen/pull/178
Also attached as a patch.
diff --git a/src/latexgen.cpp b/src/latexgen.cpp
index 40ad877..10e50de 100644
--- a/src/latexgen.cpp
+++ b/src/latexgen.cpp
@@ -290,6 +290,7 @@ static void writeDefaultHeaderPart1(FTextStream t)
// Load required packages
t % Packages required by doxygen\n
+ \\usepackage{fixltx2e}\n // for \textsubscript
\\usepackage{calc}\n
\\usepackage{doxygen}\n
\\usepackage{graphicx}\n
@@ -297,7 +298,6 @@ static void writeDefaultHeaderPart1(FTextStream t)
\\usepackage{makeidx}\n
\\usepackage{multicol}\n
\\usepackage{multirow}\n
- \\usepackage{fixltx2e}\n // for \textsubscript
\\PassOptionsToPackage{warn}{textcomp}\n
\\usepackage{textcomp}\n
\\usepackage[nointegrals]{wasysym}\n
signature.asc
Description: This is a digitally signed message part
