Bug#1067782: Uses deprecated tooling to build package
It is unclear why tqdm (and tqdm specifically) is downloaded. The build log confirms that python3-tqdm (4.66.2-2) was installed as a build-dependency. That being said, the step that triggers the download is preceded with the message PYTHONPATH="bin:" python3 setup.py develop --install-dir bin running develop /usr/lib/python3/dist-packages/setuptools/command/develop.py:40: EasyInstallDeprecationWarning: easy_install command is deprecated. !! Please avoid running ``setup.py`` and ``easy_install``. Instead, use pypa/build, pypa/installer or other standards-based tools. See https://github.com/pypa/setuptools/issues/917 for details. !! easy_install.initialize_options(self) /usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py:66: SetuptoolsDeprecationWarning: setup.py install is deprecated. !! Please avoid running ``setup.py`` directly. Instead, use pypa/build, pypa/installer or other standards-based tools. See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html for details. !! Possibly the problem is caused by a toolchain that should no longer be used to begin with. -- Michael Hanke GPG: 4096R/C073D2287FFB9E9B http://psychoinformatics.de
Bug#1070186: New upstream fixed problem
The current 1.0.3 release no longer depends on boto and has moved to boto3. -- Michael Hanke GPG: 4096R/C073D2287FFB9E9B http://psychoinformatics.de
Bug#937490: pynifti: Python2 removal in sid/bullseye
Hi, On Sun, Aug 2, 2020, 23:47 Moritz Mühlenhoff wrote: > On Fri, Jul 10, 2020 at 01:08:44PM +0200, Andreas Tille wrote: > > On Mon, Jun 29, 2020 at 08:37:58PM +0200, Moritz Mühlenhoff wrote: > > > On Fri, Aug 30, 2019 at 07:34:39AM +, Matthias Klose wrote: > > > > > > The upstream homepage states > > > > > > | PyNIfTI is no longer actively developed. At has been > > > | superseded by NiBabel -- a pure-Python package that > > > | provides everything that PyNIfTI could do, and a lot more. > > > > > > Given that nibabel is packaged, let's simply remove pynifti? > > > > Same answer from my side as for mrtrix - from my point of > > view it can go. > > Michael/Yaroslav, ping. Ack to remove pynifti from your end? Yes, it can go. Thx. Michael > >
Bug#937490: pynifti: Python2 removal in sid/bullseye
Hi, yes, that sounds like to best course of action to me. Best, Michael On Mon, Jun 29, 2020, 20:38 Moritz Mühlenhoff wrote: > On Fri, Aug 30, 2019 at 07:34:39AM +, Matthias Klose wrote: > > Package: src:pynifti > > Version: 0.20100607.1-4.1 > > Severity: normal > > Tags: sid bullseye > > User: debian-pyt...@lists.debian.org > > Usertags: py2removal > > > > Python2 becomes end-of-live upstream, and Debian aims to remove > > Python2 from the distribution, as discussed in > > https://lists.debian.org/debian-python/2019/07/msg00080.html > > The upstream homepage states > > | PyNIfTI is no longer actively developed. At has been > | superseded by NiBabel -- a pure-Python package that > | provides everything that PyNIfTI could do, and a lot more. > > Given that nibabel is packaged, let's simply remove pynifti? > > Cheers, > Moritz >
Bug#879624: Similar issue, also X1 carbon
Looking into possible known issues for at-spi or gnome-terminal-server did not bring up anything useful for me. FTR: Installing xfce4 or kde both gives me a working desktop. So this might actually be a GNOME issue rather than an X issue, or an interaction of the two. On Sat, Nov 4, 2017 at 10:14 AM, Michael Hanke <michael.ha...@gmail.com> wrote: > Update: > > I stopped the gdm3 service and started a freshly installed slim login > manager. I comes right up, no issues. > > Starting the GNOME session from slim, however, results in immediate > failure. This is syslog from the last message of slim to the X server > shutdown: > > Nov 4 09:49:56 meiner slim[8940]: /usr/bin/X11/xauth: file > /home/mih/.Xauthority does not exist > Nov 4 09:49:56 meiner org.a11y.Bus[9347]: Activating service > name='org.a11y.atspi.Registry' > Nov 4 09:49:56 meiner org.a11y.Bus[9347]: Successfully activated > service 'org.a11y.atspi.Registry' > Nov 4 09:49:56 meiner org.a11y.atspi.Registry[9373]: SpiRegistry > daemon is running with well-known name - org.a11y.atspi.Registry > Nov 4 09:49:56 meiner gnome-terminal-[9379]: gnome-terminal-server: > Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. > Nov 4 09:49:56 meiner org.a11y.atspi.Registry[9373]: XIO: fatal IO > error 11 (Resource temporarily unavailable) on X server ":0.0" > Nov 4 09:49:56 meiner org.a11y.atspi.Registry[9373]: after 21 > requests (19 known processed) with 0 events remaining. > Nov 4 09:49:56 meiner org.gtk.vfs.Daemon[9347]: A connection to the > bus can't be made > Nov 4 09:49:58 meiner kernel: [ 249.268908] [drm] Reducing the > compressed framebuffer size. This may lead to less power savings than > a non-reduced-size. Try to increase stolen memory size if available in > BIOS. > Nov 4 09:49:58 meiner slim[8940]: (II) Server terminated successfully > (0). Closing log file. > > On Fri, Nov 3, 2017 at 5:02 PM, Michael Hanke <michael.ha...@gmail.com> wrote: >> Hi, >> >> same here, after upgrade to buster no X anymore. Normal start works, but >> ends at terminal login. Manual startx makes the screen flicker briefly, then >> back to terminal. X log contain no errors (EE). >> >> Downgrade to stretch didn't change the situation in any way. Going back from >> linux 4.13 to 4.8 had no effect either. >> >> During downgrade gconf2 choked (triggers hung and never completed). During >> upgrade I think I saw some gconf error message too, but I cannot find a >> trace of them anywhere. >> >> Any advice would be highly appreciated. >> >> Thanks in advance >> >> Michael >> > > > > -- > Michael Hanke > http://psychoinformatics.de -- Michael Hanke http://psychoinformatics.de
Bug#879624: Similar issue, also X1 carbon
Update: I stopped the gdm3 service and started a freshly installed slim login manager. I comes right up, no issues. Starting the GNOME session from slim, however, results in immediate failure. This is syslog from the last message of slim to the X server shutdown: Nov 4 09:49:56 meiner slim[8940]: /usr/bin/X11/xauth: file /home/mih/.Xauthority does not exist Nov 4 09:49:56 meiner org.a11y.Bus[9347]: Activating service name='org.a11y.atspi.Registry' Nov 4 09:49:56 meiner org.a11y.Bus[9347]: Successfully activated service 'org.a11y.atspi.Registry' Nov 4 09:49:56 meiner org.a11y.atspi.Registry[9373]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry Nov 4 09:49:56 meiner gnome-terminal-[9379]: gnome-terminal-server: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. Nov 4 09:49:56 meiner org.a11y.atspi.Registry[9373]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" Nov 4 09:49:56 meiner org.a11y.atspi.Registry[9373]: after 21 requests (19 known processed) with 0 events remaining. Nov 4 09:49:56 meiner org.gtk.vfs.Daemon[9347]: A connection to the bus can't be made Nov 4 09:49:58 meiner kernel: [ 249.268908] [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS. Nov 4 09:49:58 meiner slim[8940]: (II) Server terminated successfully (0). Closing log file. On Fri, Nov 3, 2017 at 5:02 PM, Michael Hanke <michael.ha...@gmail.com> wrote: > Hi, > > same here, after upgrade to buster no X anymore. Normal start works, but > ends at terminal login. Manual startx makes the screen flicker briefly, then > back to terminal. X log contain no errors (EE). > > Downgrade to stretch didn't change the situation in any way. Going back from > linux 4.13 to 4.8 had no effect either. > > During downgrade gconf2 choked (triggers hung and never completed). During > upgrade I think I saw some gconf error message too, but I cannot find a > trace of them anywhere. > > Any advice would be highly appreciated. > > Thanks in advance > > Michael > -- Michael Hanke http://psychoinformatics.de
Bug#879624: Similar issue, also X1 carbon
Hi, same here, after upgrade to buster no X anymore. Normal start works, but ends at terminal login. Manual startx makes the screen flicker briefly, then back to terminal. X log contain no errors (EE). Downgrade to stretch didn't change the situation in any way. Going back from linux 4.13 to 4.8 had no effect either. During downgrade gconf2 choked (triggers hung and never completed). During upgrade I think I saw some gconf error message too, but I cannot find a trace of them anywhere. Any advice would be highly appreciated. Thanks in advance Michael
Bug#835746: fixed in odin-2.0.3: FTBFS: seqgradspiral.cpp:30:71: error: no matching function for call to 'max(double, float)'
Hi Thies, I had a quick look at upgrading the package to 2.0.3. I am trying to build against Qt5 (all the bdeps seem to be there), but the AC setup does not acknowledge the presence of Qt5 in my test system. Should this be working? Thanks, Michael -- Michael Hanke GPG: 4096R/C073D2287FFB9E9B http://psychoinformatics.de
Bug#828269: Info from upstream
Hi Tim,
thanks for the patch. I did a test build and can confirm that it works.
I am now preparing an upload to Debian proper. Should come within the
next few hours.
Thanks for taking care of this issue!
Michael
On Sat, Nov 26, 2016 at 04:50:21PM -0600, Tim Theisen wrote:
> I have been working on getting HTCondor working with OpenSSL 1.1.
>
> Although we would prefer to compile with VOMS support, it is preferable
> to turn this off, rather than miss getting into stretch. I have a patch
> to turn off compilation with VOMS. (rules.patch) We should revert this
> patch when the VOMS folks fix up their OpenSSL issues.
>
> Once the VOMS dependency was eliminated, I found a few minor changes
> that needed to be addressed within HTCondor itself. I have included a
> patch to 8.4.9 (OpenSSL1.1.patch). This update will be released as part
> of the HTCondor 8.4.10 release, expected on December 1st.
>
> Let me know if you need anything more, ...Tim
>
> On 11/04/2016 06:31 AM, Michael Hanke wrote:
> > Relaying information from upstream's triaging:
> >
> >
> >
> > I concluded that the problem was not with HTCondor. It had to do with the
> > following packages: libglobus-gsi-proxy-core, libglobus-gsi-proxy-ssl and
> > voms. The Globus folks addressed the first two issues. However, the VOMS
> > issue
> > (#828595) is a blocker for us.
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828595
> > https://github.com/italiangrid/voms/issues/50
> >
> > ___
> > htcondor-debian mailing list
> > htcondor-deb...@cs.wisc.edu
> > https://lists.cs.wisc.edu/mailman/listinfo/htcondor-debian
>
> --
> Tim Theisen
> Release Manager
> HTCondor & Open Science Grid
> Center for High Throughput Computing
> Department of Computer Sciences
> University of Wisconsin - Madison
> 4261 Computer Sciences and Statistics
> 1210 W Dayton St
> Madison, WI 53706-1685
> +1 608 265 5736
>
> diff --git a/src/condor_includes/condor_crypt_3des.h
> b/src/condor_includes/condor_crypt_3des.h
> index e2967d8..dc29b6a 100644
> --- a/src/condor_includes/condor_crypt_3des.h
> +++ b/src/condor_includes/condor_crypt_3des.h
> @@ -61,7 +61,7 @@ class Condor_Crypt_3des : public Condor_Crypt_Base {
> //--
> // Private constructor
> //--
> -des_key_schedule keySchedule1_, keySchedule2_, keySchedule3_;
> +DES_key_schedule keySchedule1_, keySchedule2_, keySchedule3_;
> unsigned char ivec_[8];
> int num_;
> };
> diff --git a/src/condor_io/condor_auth_ssl.cpp
> b/src/condor_io/condor_auth_ssl.cpp
> index b8bb6cf..3c366b3 100644
> --- a/src/condor_io/condor_auth_ssl.cpp
> +++ b/src/condor_io/condor_auth_ssl.cpp
> @@ -36,7 +36,9 @@
> #endif
>
> // Symbols from libssl
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
> static long (*SSL_CTX_ctrl_ptr)(SSL_CTX *, int, long, void *) = NULL;
> +#endif
> static void (*SSL_CTX_free_ptr)(SSL_CTX *) = NULL;
> static int (*SSL_CTX_load_verify_locations_ptr)(SSL_CTX *, const char *,
> const char *) = NULL;
> #if OPENSSL_VERSION_NUMBER < 0x1000L
> @@ -55,8 +57,12 @@ static void (*SSL_free_ptr)(SSL *) = NULL;
> static int (*SSL_get_error_ptr)(const SSL *, int) = NULL;
> static X509 *(*SSL_get_peer_certificate_ptr)(const SSL *) = NULL;
> static long (*SSL_get_verify_result_ptr)(const SSL *) = NULL;
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
> static int (*SSL_library_init_ptr)() = NULL;
> static void (*SSL_load_error_strings_ptr)() = NULL;
> +#else
> +static int (*OPENSSL_init_ssl_ptr)(uint64_t, const OPENSSL_INIT_SETTINGS *)
> = NULL;
> +#endif
> static SSL *(*SSL_new_ptr)(SSL_CTX *) = NULL;
> static int (*SSL_read_ptr)(SSL *, void *, int) = NULL;
> static void (*SSL_set_bio_ptr)(SSL *, BIO *, BIO *) = NULL;
> @@ -79,7 +85,11 @@ Condor_Auth_SSL :: Condor_Auth_SSL(ReliSock * sock, int /*
> remote */)
>
> Condor_Auth_SSL :: ~Condor_Auth_SSL()
> {
> +#if OPENSSL_VERSION_NUMBER < 0x1000L
> ERR_remove_state( 0 );
> +#elif OPENSSL_VERSION_NUMBER < 0x1010L
> +ERR_remove_thread_state( 0 );
> +#endif
> if(m_crypto) delete(m_crypto);
> }
>
> @@ -96,7 +106,9 @@ bool Condor_Auth_SSL::Initialize()
>
> if ( Condor_Auth_Kerberos::Initialize() == false ||
>(dl_hdl = dlopen(LIBSSL_SO, RTLD_LAZY)) == NULL ||
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
>!(SSL_CTX_ctrl_ptr = (long (*)(SSL_CTX *, int, long, void
> *))dlsym(dl_hdl, "SSL_CTX_ctrl")) ||
>
Bug#837402: Thanks
Thanks Adrian! Will upload when #828269 has been dealt with. Michael -- Michael Hanke GPG: 4096R/C073D2287FFB9E9B http://psychoinformatics.de
Bug#828269: Info from upstream
Relaying information from upstream's triaging: I concluded that the problem was not with HTCondor. It had to do with the following packages: libglobus-gsi-proxy-core, libglobus-gsi-proxy-ssl and voms. The Globus folks addressed the first two issues. However, the VOMS issue (#828595) is a blocker for us. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828595 https://github.com/italiangrid/voms/issues/50
Bug#810165: closed by Yaroslav Halchenko <deb...@onerussian.com> (Bug#810165: fixed in ants 2.1.0-3)
Hi, out of curiosity: where is the harm in a "useless" alternative dependency that enables people to easily build backports without tinkering with the package? Michael On Sun, Jan 10, 2016 at 10:54 AM, Tobias Frost <t...@debian.org> wrote: > Am Samstag, den 09.01.2016, 22:55 -0500 schrieb Yaroslav Halchenko: > > > > > > but ok -- will list libpng-dev as the first and alternative libpng12 > > and will see how it goes > > > > *sigh* ok, even if the libpng12-dev is superficious. (It creates more > work, as I will file a bug to remove it once the transistion have > started and you'll need another sourceful upload.) > -- Michael Hanke http://mih.voxindeserto.de
Bug#798170: Almost done
FTR: I was able to build the latest upstream release (2.0.0) against the QWT package (6.1) in experimental. However, a linking problem (get's linked against Qt4 and Qt5) causes the main GUI to segfault. I contacted upstream to get this solved. Will upload to experimental once this is done.
Bug#798058: Info
FTR: The test fails, because the dtype of the metadata array in the test file changes during the read/write cycle in the test. The actual content is unchanges though. After initial write: array([['dt', '0.1'], ['first_id', '0'], ['first_index', '0'], ['label', 'population0'], ['last_id', '4'], ['last_index', '5'], ['n', '505'], ['size', '5'], ['units', 'mV'], ['variable', 'v']], dtype='|S11') and after the re-write: array([['dt', '0.1'], ['first_id', '0'], ['first_index', '0'], ['label', 'population0'], ['last_id', '4'], ['last_index', '5'], ['n', '505'], ['size', '5'], ['units', 'mV'], ['variable', 'v']], dtype='|S32') Not yet clear on how this happens. ttfn
Bug#792758: bwidget vs. fsl incompatibility
Hi, thanks for the report and sorry for the delay. I can reproduce it, as soon as I install bwidget -- which is not a dependency of FSL. I'll look into it. Michael
Bug#784778: FTBFS: no matching function for call to 'condor_sockaddr::condor_sockaddr(const soap::anonymous union*)'
Hi, On May 14, 2015 00:45, peter green peter.gree...@manchester.ac.uk wrote: Tags 784778 +patch thanks During a binNMU of condor for the gsoap transition, the following error was encountered on all architectures: /«PKGBUILDDIR»/src/condor_schedd.V6/soap_scheddStub.cpp: In function 'bool stub_prefix(const char*, const soap*, int, int, DCpermission, bool, soap_schedd::condor__Transaction*, soap_schedd::condor__Status, ScheddTransaction*)': /«PKGBUILDDIR»/src/condor_schedd.V6/soap_scheddStub.cpp:289:36: error: no matching function for call to 'condor_sockaddr::condor_sockaddr(const soap::anonymous union*)' condor_sockaddr addr(soap-peer); The attatched debdiff made the package build in my sid amd64 chroot. It has not been tested beyond that. It will be uploaded to raspbian soon after merging it with existing raspbian changes. I have no intent to NMU in Debian. Thanks a lot. I'll take a look and upload ASAP. Michael
Bug#772170: htcondor: New default configuration relocates spool dir - history lost
Package: htcondor Version: 8.2.3~dfsg.1-4 Severity: grave Justification: causes non-serious data loss With the update to 8.2.3~dfsg.1-4 the default condor config file included a modified location for the SPOOL directory. As a result the spool directory is now by default located at /var/lib/condor/spool instead of /var/spool/condor. This resets condors user priority and job logs (condor_history...). The hot fix is to configure SPOOL by modifying the relevant line in /etc/condor/condor_config to SPOOL = /var/spool/condor An update that fixes this in the installed default config file is pending. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages htcondor depends on: ii adduser 3.113+nmu3 ii debconf [debconf-2.0] 1.5.54 ii libc6 2.19-13 ii libcgroup10.41-6 pn libclassad7 none ii libcomerr21.42.12-1 ii libcurl3 7.38.0-3 ii libdate-manip-perl6.47-1 ii libexpat1 2.1.0-6+b3 ii libgcc1 1:4.9.1-19 ii libglobus-callout03.13-3 ii libglobus-common0 15.26-3 ii libglobus-ftp-client2 8.13-6 ii libglobus-gass-transfer2 8.8-3 ii libglobus-gram-client313.10-3 ii libglobus-gram-protocol3 12.12-3 ii libglobus-gsi-callback0 5.6-3 ii libglobus-gsi-cert-utils0 9.10-3 ii libglobus-gsi-credential1 7.7-3 ii libglobus-gsi-openssl-error0 3.5-3 ii libglobus-gsi-proxy-core0 7.7-3 ii libglobus-gsi-proxy-ssl1 5.7-3 ii libglobus-gsi-sysconfig1 6.8-3 ii libglobus-gss-assist3 10.12-3 ii libglobus-gssapi-error2 5.4-3 ii libglobus-gssapi-gsi4 11.13-3 ii libglobus-io3 10.11-1 ii libglobus-openssl-module0 4.6-3 ii libglobus-rsl210.9-3 ii libglobus-xio04.15-3 pn libgsoap4 none iu libgssapi-krb5-2 1.12.1+dfsg-15 iu libk5crypto3 1.12.1+dfsg-15 iu libkrb5-3 1.12.1+dfsg-15 iu libkrb5support0 1.12.1+dfsg-15 iu libldap-2.4-2 2.4.40-3 ii libltdl7 2.4.2-1.11 ii libpcre3 1:8.35-3.1 ii libssl1.0.0 1.0.1j-1 ii libstdc++64.9.1-19 ii libuuid1 2.25.2-3 iu libvirt0 1.2.9-6 ii libx11-6 2:1.6.2-3 iu perl 5.20.1-3 ii python2.7.8-2 iu zlib1g1:1.2.8.dfsg-2+b1 Versions of packages htcondor recommends: ii dmtcp 2.3.1-5 Versions of packages htcondor suggests: pn coop-computing-tools none -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772170: Patch
Here is a tentative patch. diff --git a/debian/patches/default_debian_config b/debian/patches/default_debian_config index 77ba593..9415fd3 100644 --- a/debian/patches/default_debian_config +++ b/debian/patches/default_debian_config @@ -90,3 +90,32 @@ Author: Michael Hanke m...@debian.org type=path review=? [CREDD_ARGS] +--- a/src/condor_examples/condor_config.generic.debian.patch b/src/condor_examples/condor_config.generic.debian.patch +@@ -29,7 +29,7 @@ + #LOCAL_CONFIG_DIR_EXCLUDE_REGEXP = ^((\..*)|(.*~)|(#.*)|(.*\.rpmsave)|(.*\.rpmnew))$ + + ## Use a host-based security policy. By default CONDOR_HOST and the local machine will be allowed +-@@ -50,5 +48,24 @@ ++@@ -50,5 +48,29 @@ + #FLOCK_TO = condor.cs.wisc.edu, cm.example.edu + + ## +@@ -45,7 +45,7 @@ + +RUN = $(LOCAL_DIR)/run/condor + +LOG = $(LOCAL_DIR)/log/condor + +LOCK= $(LOCAL_DIR)/lock/condor +-+SPOOL = $(LOCAL_DIR)/lib/condor/spool +++SPOOL = $(LOCAL_DIR)/spool/condor + +EXECUTE = $(LOCAL_DIR)/lib/condor/execute + +BIN = $(RELEASE_DIR)/bin + +LIB = $(RELEASE_DIR)/lib/condor +@@ -55,3 +55,8 @@ + +SHARE = $(RELEASE_DIR)/share/condor + + + +PROCD_ADDRESS = $(RUN)/procd_pipe +++ +++CONDOR_DEVELOPERS = NONE +++CONDOR_DEVELOPERS_COLLECTOR = NONE +++ +++SSH_TO_JOB_SSHD_CONFIG_TEMPLATE = /etc/condor/condor_ssh_to_job_sshd_config_template diff --git a/debian/rules b/debian/rules index df092db..74b2bb9 100755 --- a/debian/rules +++ b/debian/rules @@ -106,13 +106,6 @@ override_dh_install: chrpath -d debian/libclassad*/usr/lib/libclassad.so.*.* # kill the default local config -- debconf will handle that rm debian/htcondor/etc/condor/condor_config.local - # modify condor config file with default Debian config - # no default chatter to upstream - echo CONDOR_DEVELOPERS = NONE debian/htcondor/etc/condor/condor_config - echo CONDOR_DEVELOPERS_COLLECTOR = NONE debian/htcondor/etc/condor/condor_config - # SSH template is a config file - echo SSH_TO_JOB_SSHD_CONFIG_TEMPLATE = /etc/condor/condor_ssh_to_job_sshd_config_template \ - debian/htcondor/etc/condor/condor_config override_dh_auto_clean: dh_auto_clean
Bug#769100: Minimal vs. proper fix of #769100 (htcondor is marked for auto-removal from testing)
Thanks for the report. I am CC'ing the Debian release team to get feedback regarding an acceptable fix Debian testing. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769100 This bug is caused by the (now invalid) assumption of the Debian packaging to find all relevant config variables in the main condor_config file (see the various sed expressions in debian/rules). However, as explained in https://htcondor-wiki.cs.wisc.edu/index.cgi/tktview?tn=4325 the mechanism for specifying the default configuration changed leading up to the 8.2.x series. The proper way to fix this is to move all default configuration settings from debian/rules into a patch of src/condor_utils/param_info.in. Alternatively, a CRED_STORE_DIR variable could be reintroduced into the default config file shipped with the package, which would override this particular (broken) default. The changes to the source package would be minimal, but the general invalid approach to specifying a default configuration would be kept. While I have the attention of the release time, I'd like to ask for feedback on pushing an upstream update into jessie. HTCondor uses the odd/even version setup for stable and development releases. The 8.2.x series is the stable branch that only sees fixes and no feature additions. After the freeze of jessie, htcondor 8.2.4 has been released which contains numerous bug fixes. An exhaustive list to the respective tickets can be found here. http://research.cs.wisc.edu/htcondor/manual/v8.2.4/10_3Stable_Release.html If approved, I'd like to update the package to 8.2.4, change the default configuration handling to a generally valid approach, and include the new translation available from the bug tracker. Thanks in advance for your feedback. Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747794: condor: FTBFS: error: krb5.h: No such file or directory
Hi, thanks for the patch. I am working on an update to 8.0.6 and will include you patch in the new upload. Cheers, Michael On Sun, May 25, 2014 at 3:26 PM, Hideki Yamane henr...@debian.or.jp wrote: control: tags -1 +patch Hi, Attached patch would fix this FTBFS. Could you check and apply it, please? -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane -- Michael Hanke http://mih.voxindeserto.de
Bug#720821: voxbo: diff for NMU version 1.8.5~svn1246-1.1
Thanks for your work. I am currently traveling. Please go ahead with your upload. I'll try to do it myself around the end of the week if you did not manage it by then. cheers, michael On Feb 9, 2014 10:45 PM, Andreas Moog andreas.m...@warperbbs.de wrote: tags 662542 patch tags 720821 patch thanks Dear maintainer, I've prepared an NMU for voxbo (versioned as 1.8.5~svn1246-1.1) and will try to find a sponsor in the next week. Please feel free to tell me if I should wait longer or you want to upload yourself. Regards.
Bug#737187: fsl: depends on deprecaed Tcl/Tk 8.4
Please go ahead and NMU the package. An upload of FSL5 is overdue --
will hopefully happen over the next few weeks.
Thanks,
Michael
On Fri, Jan 31, 2014 at 11:18:20AM +0400, Sergei Golovan wrote:
Package: fsl
Version: 4.1.9-7
Severity: serious
Tags: patch
Dear Maintainer,
We are about to drop Tcl/Tk 8.4 from Debian, but your fsl package still
depends on tcl8.4 and tk8.4. The attached patch just replaces these
dependencies by tcl and tk, which are metapackages installing the default
Tcl/Tk version.
If you don't mind, I'll perform NMU with this patch.
-- System Information:
Debian Release: 7.3
APT prefers proposed-updates
APT policy: (500, 'proposed-updates'), (500, 'stable'), (100, 'unstable'),
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru fsl-4.1.9/debian/changelog fsl-4.1.9/debian/changelog
--- fsl-4.1.9/debian/changelog2012-10-22 13:00:27.0 +0400
+++ fsl-4.1.9/debian/changelog2014-01-31 10:47:47.0 +0400
@@ -1,3 +1,10 @@
+fsl (4.1.9-7.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Replaced tcl8.4 and tk8.4 by tcl and tk in the package dependencies.
+
+ -- Sergei Golovan sgolo...@debian.org Fri, 31 Jan 2014 10:47:41 +0400
+
fsl (4.1.9-7) unstable; urgency=low
* Stop regenerating tclIndex during postinst. This is no longer necessary
diff -Nru fsl-4.1.9/debian/control fsl-4.1.9/debian/control
--- fsl-4.1.9/debian/control 2012-10-22 13:04:59.0 +0400
+++ fsl-4.1.9/debian/control 2014-01-31 10:46:39.0 +0400
@@ -7,7 +7,7 @@
libboost-dev (= 1.32.0), libpng12-dev (= 1.2.8rel),
libgd2-noxpm-dev (= 2.0.33) | libgd2-xpm-dev (= 2.0.33), libnewmat10-dev,
libgdchart-gd2-noxpm-dev | libgdchart-gd2-xpm-dev,
- liboctave-dev | octave3.2-headers | octave3.0-headers, tcl8.4 (=8.4.7),
+ liboctave-dev | octave3.2-headers | octave3.0-headers, tcl,
imagemagick, libnifti-dev ( 1.1.0-1)
Standards-Version: 3.9.3
Homepage: http://www.fmrib.ox.ac.uk/fsl/
@@ -29,7 +29,7 @@
Package: fsl-4.1
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, mozilla-firefox | www-browser,
tcsh | c-shell, tk8.4 (=8.4.7), tcl8.4 (=8.4.7), bc, dc
+Depends: ${shlibs:Depends}, ${misc:Depends}, mozilla-firefox | www-browser,
tcsh | c-shell, tk, tcl, bc, dc
Recommends: fsl-doc-4.1 (= ${source:Version}), fsl-atlases, fslview
Suggests: fsl-feeds, octave | ${octave:Depends}, dicomnifti,
fsl-possum-data, fsl-first-data, gridengine-client
Conflicts: fsl-fslview, fsl-doc-4.1 ( 4.1.9-5~)
--
Michael Hanke
http://mih.voxindeserto.de
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731246: condor: Needs to adapt to Globus Toolkit multi-arch support
Hi Mattias, On Mon, Dec 16, 2013 at 07:17:24PM +0100, Mattias Ellert wrote: 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? Personally, it is likely that I won't be able to focus on this before the holidays. Maybe the condor devs can be quicker. 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. A quick NMU would be appreciated -- no need for a delayed-queue upload. If I can do it myself within the next few days, I'll let you know upfront so we do not duplicate work. Thanks, Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724021: e-mail validation for Debian via package
Hi Paul, thanks for bringing this to my intention. The maintainership was not transferred by accident, instead the goal had been to have one of the upstream developers take over the Debian packaging. However, that process has stalled. At this time, there is no point in keeping the package in Debian. Hence I filled a bug (#732129) asking ftp-masters to remove the package. This should be a practical alternative to a proper fix for now. If something requires via as a dependency in the future, we can bring it back. Sorry for the hassle, Michael On Sat, Dec 14, 2013 at 1:38 PM, Paul Gevers elb...@debian.org wrote: Hi Currently the via package in Debian is one of the last package to block the removal of lesstif2 [0]. This is due to a serious bug [1] in the package which prevents if from migrating to testing. This e-mail aims to recheck the use of the lip...@cbs.mpg.de address, which caused bug [1] to be reported. The bug is about violation of policy section 3.3, which says that the maintainer must be specified with a working e-mail address. @ Michael, do I understand the changelog correctly if I say that you often copy the upstream packaging? The debian packaging svn is not up-to-date, so I can't check if you intentionally moved the maintainer-ship to the Lipsia group. If so, could you fix bug 724021 by uploading a via package with your name and e-mail address as Maintainer again? Paul [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708462 [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724021 [2] http://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
Bug#731246: condor: Needs to adapt to Globus Toolkit multi-arch support
Hi, On Tue, Dec 03, 2013 at 04:07:20PM +0100, Mattias Ellert wrote: 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. Thanks for your report and the patch! 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 -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713514: Need help with lazarus-related bug
Hi Paul, thanks for the pointer! Unfortunately that did not solve the original issue: lazbuild --build-all --ws=gtk2 --pcp=/etc/lazarus mricron.lpi SetPrimaryConfigPath NewValue=/etc/lazarus - /etc/lazarus primary config path: /etc/lazarus/ TLazPackageGraph.OpenDependency: LazarusDir=/usr/lib/lazarus/1.0.10/ The lpl directory is missing. Check that the Lazarus (--lazarusdir) directory is correct. The lpk is missing for dependency=FCL (=1.0) ERROR: Broken dependency: FCL (=1.0) I'd be glad if you have another idea. Thanks, Michael On Sat, Sep 21, 2013 at 7:50 PM, Paul Gevers elb...@debian.org wrote: On 21-09-13 19:39, Michael Hanke wrote: It seems like a broken build-dependency spec is the reason -- it builds on my laptop, but I can't get it to work in a clean chroot. I wonder whether you could easily spot the problem and help me out? I had a very similar bug reported against my package winff. It has nothing to do with the version of lazarus, but with the way that specific rebuild is done. I fixed it in this [1] commit. Hope this helps. Paul [1] http://anonscm.debian.org/gitweb/?p=pkg-pascal/winff.git;a=commit;h=168a95092d1e3ad2785412b6c60223fa564a8aa7
Bug#713514: Need help with lazarus-related bug
Hi Paul, On Sun, Sep 22, 2013 at 10:47 AM, Paul Gevers elb...@debian.org wrote: On 22-09-13 09:36, Michael Hanke wrote: thanks for the pointer! Unfortunately that did not solve the original issue: So far, you didn't explain the original issue :). thanks again for your time! I was indeed sloppy explaining the problem. I am quite sure now it is a depedency issue. Once I install 'lazarus' in the chroot it works. Also thanks for the bug report regarding pristine-tar -- I have never pushed that indeed -- will do. I am now going to the list of packages that could have changed after wheezy. I'll update this bug once I have the solution, or come back aksing for more help. Thanks, Michael
Bug#713514: Need help with lazarus-related bug
Hi, I am the maintainer of the mricron package that build-depends on lazarus. With the transition to lazarus 1.0 it's builds broke: http://bugs.debian.org/713514 It seems like a broken build-dependency spec is the reason -- it builds on my laptop, but I can't get it to work in a clean chroot. I wonder whether you could easily spot the problem and help me out? Thanks, Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703946: general: OS freezes, but mouse and ping keeps working
On Mon, Mar 25, 2013 at 11:34:57PM -0600, Gunnar Wolf wrote: Felipe dijo [Tue, Mar 26, 2013 at 12:26:59AM -0300]: Another important thing: when freezed, the notebook keeps responding to pings. There's no packages lost. This can be related to an unstability problem I saw using the non-free nvidia drivers. We have three hardware-identical machines (Lenovo Think Centre) at work, all three running a more or less up-to-date wheezy -- all three Intel graphics.. Two of them running GNOME-shell, one KDE -- only the GNOME machines show this kind of behavior. Whenever I had a chance to get on the console (only the X-session froze) I wasn't able to figure out what component was responsible: no signififcant CPU-load, no obvious problems -- hard to figure out who is is at fault. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702832: matlab-support: source in main even though it depends on non-free matlab
Control: tag -1 + wontfix Control: severity -1 wishlist Hi Michael, On Mon, Mar 11, 2013 at 11:05:16PM -0400, Michael Gilbert wrote: That's a nice readme, but it isn't a license to circumvent debian policy. The right approach is to separate the matlab-support source package into matlab-support-free (providing your path-defining -dev package) and a matlab-support-contrib (providing the matlab wrappers) source packages. In principle you are, of course, right. However, in practical terms this would not change much. Right now, guaranteed freedoms in Debian main are not in danger. matlab-support-dev does not runtime-depend on anything outside main. Moreover, the matlab-support source package does not build-depend on anything outside main. Splitting the source package has the sole benefit of a cleaner separation, at the practical cost of another (virtually empty) source package, increasing the workload of all folks that need to touch it, size of the packages file, another tiny bit of mirror space... Two additional pointers that make me believe this view is shared by more DDs than just Yarik and me: 1. This setup has been outlined in the ITP already http://lists.debian.org/debian-devel/2011/01/msg00124.html Despite that fact that a few people commented, nobody objected this approach. 2. README file and package placement in main have been in effect from day 0. ftp-masters had no problem to accept this for inclusion. You are still correct, but without additional evidence that this move is unavoidable, I am not planing on doing the split. Michael -- Michael Hanke http://mih.voxindeserto.de signature.asc Description: Digital signature
Bug#702658: matlab-support: uninteruptable prompt on installation with readline
Control: tags -1 + moreinfo Hi, On Sat, Mar 9, 2013 at 5:32 PM, Julian Taylor jtaylor.deb...@googlemail.com wrote: entering an empty string does not cancel the prompt. Other frontends are probably ok, they offer a cancel option. I can't replicate this. I installed the package, the prompt comes up, I press Ctrl-C and I am back at the prompt. I don't think entering an empty string should cancel package installation. Michael -- Michael Hanke http://mih.voxindeserto.de
Bug#702637: matlab-support: fails to install in clean chroot
Hi, On Sat, Mar 9, 2013 at 2:57 PM, Sébastien Villemot sebast...@debian.orgwrote: The attached patch allows the package to install nicely even if MATLAB is not present. Otherwise people who install the package by accident end up with a dpkg error. Julian: please confirm that it fixes the issue for you. I see the problem, but I am not convinced this change is the solution. Installing this package is pointless without Matlab, it should not be pulled in as a dependency unless a package gets installed that requires matlab. If we make this package install successfully on a system without Matlab, we need to make any dependent package handle the situation of a missing matlab itself -- potentially multiplying the effort. At the moment, any package that depends on matlab-support can expect a functional matlab installation to be present at config time. To me the actual question is, why do people try to install this package when they do not have matlab? Consequently I see two approaches: 1) Improve the package description to avoid this kind of installations. 2) Improve the error messages. Any input for improvements is most welcome. I'd be happy to discuss this further, but at the moment I see no reason to change the current behavior. Michael -- Michael Hanke http://mih.voxindeserto.de
Bug#702637: matlab-support: fails to install in clean chroot
Am 09.03.2013 19:10 schrieb Adam D. Barratt a...@adam-barratt.org.uk: On Sat, 2013-03-09 at 18:45 +0100, Julian Taylor wrote: A problem with failing the installation if matlab is missing is that it prevents migration from Ubuntus proposed repository to the main one. Migration requires that it installs and does also not make other packages uninstallable. E.g. this right now affects dynare, it can't migrate because it depends on matlab-support which does not install. I though that the debian unstable - testing works the same way, but apparently not as e.g. dynare was allowed to go into testing. In the context of testing migration, installability is determined by computing package relationships, not by actually attempting to install the affected packages (which generally wouldn't add much and isn't feasible given the number of packages involved). This seems to indicate that Debian is not affected by this problem. I am not familiar with the way Ubuntu manages these things in detail, but if there is a way to solve this problem in Debian for Ubuntu I am all for it. Right now this package causes a problem with an automated transition rule checker. Making it install under any condition, will cause problems that affect users. If this is necessary, the patch should at least handle the situation where matlab-support is installed, but no matlab, and something/someone wants to use matlab. This could be a dependent package trying to compile a MEX file. It would need to install some executable that brings up a meaningful error message, especially when invoked via the desktop file in an X session. Maybe it is leaner to handle this package as an exception in the transition checker. This was done in Debian's piuparts, AFAIK. Michael
Bug#689166: fsl-4.1: should not ship /usr/share/fsl/4.1/tcl/tclIndex
Hi, On Sat, Sep 29, 2012 at 07:53:30PM +0200, Andreas Beckmann wrote: during a test with piuparts I noticed your package modifies shipped files. Since /usr/share/fsl/4.1/tcl/tclIndex is regenerated during the postinst, there is no need to ship this file. The postrm script needs to remove this generated file later on. Thanks for pointing this out! The actual bug is, however, that this file gets re-generated at all. This workaround dates back to a time where TCL files from other packages had to be assembled in this directory. This is no longer necessary, hence I'll address this by removing the postinst script. Will upload shortly... Thanks again, Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688210: condor: Multiple security issues
a bug that caused an invalid proxy to be delegated when refreshing the job's X.509 proxy when configuration variable DELEGATE_JOB_GSI_CREDENTIALS_LIFETIME was set to 0. (Ticket #3059). 13. Fixed a bug in which DAGMan did not account properly for jobs being suspended and then unsuspended. (Ticket #3108). 14. condor_dagman now takes note of job reconnect failed events (event code 24) in the user log, for counting idle jobs. (Ticket #3189). 15. Job IDs generated by NorduGrid ARC 12.05 and above are now properly recognized. (Ticket #3062). 16. Fixed a bug in which Condor would not mark grid-type nordugrid jobs as Running due to variation in the format of the job status value. NorduGrid ARC job statuses of the form INLRMS: ? are now properly recognized both with and without the space after the colon. (Ticket #3118). 17. The condor_gridmanager now properly handles X.509 proxy files that are specified in the job ClassAd with a relative path name. (Ticket #3027). 18. Fixed a bug that caused daemon names, as set in configuration variables such as STARTD_NAME, containing a period character to be ignored. (Ticket #3172). 19. Fixed a bug that prevented the condor_schedd from removing old execute directories for local universe jobs on start up. (Ticket #3176). 20. The condor_defrag daemon sometimes scheduled fewer draining attempts than specified. (Ticket #3199). 21. Fixed a bug that could cause the condor_gridmanager to crash if a grid universe job's X.509 user certificate did not contain an e-mail address. (Ticket #3203). 22. Fixed a bug introduced in Condor version 7.7.5 that caused multiple condor_schedd daemons running on the same machine to share the job queue with each other due to way in which the default value of configuration variable JOB_QUEUE_LOG was set. (Ticket #3196). 23. Fixed a bug that could cause condor_q to not print all jobs when it thought it was querying an old condor_schedd daemon. (Ticket #3206). 24. Fixed a bug that could cause a job's standard output and standard error files to be written in the job's initial working directory, despite the submit description file's specification to write them to a different directory. This would happen when the file transfer mechanism was used, the execution machine was running Condor version 7.7.1 or earlier, and either Condor's security negotiation was disabled or the configuration variable SEC_ENABLE_MATCH_PASSWORD_AUTHENTICATION was set to True. (Ticket #3208). 25. The log message generated when the EXECUTE directory is missing is now more helpful. (Ticket #3194). 26. The load average was incorrect for non-English versions on Windows platforms. This has been fixed for Windows Vista and more recent versions. (Ticket #3182). 27. The command condor_q -run now displays correct HOST field information for local universe jobs. (Ticket #3150). Given these facts, and unless someone convinces me otherwise, I'm inclined to upload Condor 7.8.4 with all the bugfixes to unstable. All the sites I have talked to that use the Debian Condor package have no interest in testing a version that has known but unfixed bugs. If the release team objects a transition of this package into wheezy, a security-fix-only version could go through proposed-updates. The reduction in testing exposure for this package from by-passing unstable is probably negligible anyway. Cheers, Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688210: [condor-debian] Bug#688210: condor: Multiple security issues
Hi Moritz, hi Jaime, On Thu, Sep 20, 2012 at 11:33:39AM -0500, Jaime Frey wrote: On Sep 20, 2012, at 5:50 AM, Moritz Muehlenhoff j...@inutil.org wrote: Package: condor Severity: grave Tags: security Justification: user security hole Please see here for details: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-3490 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-3491 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-3492 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-3493 These security issues have been fixed in the just-released Condor 7.8.4. Thanks for the notification -- I saw the release -- I'm on it. Michael, here are the commit hashes in the Condor git repo for the fixes: CVE-2012-3490: 94e84ce4 CVE-2012-3491: 1fff5d40 CVE-2012-3492: 1db67805 CVE-2012-3493: d2f33972 Perfect! Thanks. For Debian testing, I believe we want to create a new Condor 7.8.2 package with just these changes. Can you prepare that? I can offer whatever assistance you require. I'll see what I can do tonight -- if everything runs smooth, I'll upload in a few hours. If not, I'll come back to you. Thanks again, Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688210: condor: Multiple security issues
On Thu, Sep 20, 2012 at 11:33:39AM -0500, Jaime Frey wrote: These security issues have been fixed in the just-released Condor 7.8.4. Michael, here are the commit hashes in the Condor git repo for the fixes: CVE-2012-3491: 1fff5d40 CVE-2012-3493: d2f33972 These two do not apply cleanly against 7.8.2: Applying patch Remove-unused-KILL_FRGN_JOB-DEACTIVATE_CLAIM_FORIBLY.patch patching file src/condor_schedd.V6/schedd.cpp Hunk #1 succeeded at 2961 with fuzz 1 (offset 94 lines). Hunk #2 FAILED at 10251. 1 out of 2 hunks FAILED -- rejects in file src/condor_schedd.V6/schedd.cpp patching file src/condor_schedd.V6/scheduler.h Hunk #1 FAILED at 291. 1 out of 1 hunk FAILED -- rejects in file src/condor_schedd.V6/scheduler.h Patch Remove-unused-KILL_FRGN_JOB-DEACTIVATE_CLAIM_FORIBLY.patch does not apply (enforce with -f) Applying patch Remove-unused-GIVE_REQUEST_AD-command-from-the-start.patch patching file src/condor_startd.V6/command.cpp Hunk #1 succeeded at 624 (offset 79 lines). patching file src/condor_startd.V6/command.h Hunk #1 FAILED at 83. 1 out of 1 hunk FAILED -- rejects in file src/condor_startd.V6/command.h patching file src/condor_startd.V6/startd_main.cpp Hunk #1 succeeded at 267 (offset -6 lines). Patch Remove-unused-GIVE_REQUEST_AD-command-from-the-start.patch does not apply (enforce with -f) Before I dig deeper, could you please confirm that cherry-picking the four commits alone will fully address the security vulnerabilities? If that is the case, it seems that at least one more commit is missing. Looking into the 7.8 branch in the condor repo, it seems that quite a bit more has happened -- a long list of bug fixes. I wonder (7.8 being a stable maintenance branch) whether it wouldn't be a better idea to aim for an upload of 7.8.4 as a whole. Is there something in it that is not a bugfix of some kind? Cheers, Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684754: pysurfer: diff for NMU version 0.3+git15-gae6cbb1-1.1
Hey, On Aug 25, 2012 4:24 AM, David Prévot taf...@tilapin.org wrote: tags 684754 + patch thanks Dear maintainer, I've prepared an NMU for pysurfer (versioned as 0.3+git15-gae6cbb1-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Thanks for taking care of this. I wouldn't mind a zero-day NMU. Cheers, Michael
Bug#684463: [Neurodebian-devel] condor fails to install if condor user already exists
severity 684463 wishlist tag 684463 wontfix thanks Hi Tiziano, [Debian bug is in CC] On Fri, Aug 10, 2012 at 08:42:17PM +0200, Tiziano Zito wrote: I mistakenly posted a bug report about condor on debian BTS http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684463 which should have been posted here. Should I ask to close the bug and keep on discussing here? First of all: I consider it appropriate to file bugs like this in the Debian BTS. NeuroDebian binary packages are unmodified rebuilds and I upload binaries built from the same source packages to Debian proper also. Regarding the actual bug. This issue came up in the early days of this packaging. It essentially happens mostly for people upgrading from existing Condor deployments. While I can't say much about the necessity to have a Condor user in LDAP. I'm pretty sure that the Debian packages cannot work with a non-system user. There are all kinds of problems, but one of them is that the package can't assume that any user named 'condor' is also one that is available for Condor's operations. If a normal user 'condor' exists, IMHO failing is the only option. Otherwise that user would have access to Condor's runtime data (job payload, ...), but we would not know whether there is an actual (human) 'condor' user. The system user that the condor package creates is a dedicated one -- no login, no shell access. If you see a way that is both secure and satisfies your needs, please let me know. Otherwise, I think Evgeni is right: move 'condor' out of LDAP and solve email issues with alternative means. For now I am downgrading this bug to 'wishlist' and tag it with 'wontfix' until a more viable solution is found. Best, Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676749: odin: FTBFS: /bin/bash: line 5: 11294 Illegal instruction ${dir}$tst
severity 676749 important
tags 676749 + unreproducible moreinfo
thanks
Hi Lucas,
On Sat, Jun 09, 2012 at 10:17:37AM +0200, Lucas Nussbaum wrote:
During a rebuild of all packages in sid, your package failed to build on
amd64.
Relevant part:
UnitTest |check_all : Testing FunctionFit ...
/bin/bash: line 5: 11294 Illegal instruction ${dir}$tst
FAIL: cmdline-utils/odintestsuite
==
1 of 1 test failed
==
make[4]: *** [check-TESTS] Error 1
Both upstream and I can't reproduce this problem. I did a rebuild in a
clean sid chroot and everything works just fine. For now I'm lowering
the severity of this bug. If you think this has not just been a temporary
glitch, please feel free to raise it again. In that case any idea what
might have caused the issue would be highly appreciated.
Thanks,
Michael
--
Michael Hanke
http://mih.voxindeserto.de
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669466: pynn: FTBFS: tests failed
Hi,
I checked whether this issue is still present. I ran the tests in a
clean sid chroot and my results are a bit different from Lucas':
==
FAIL: unittests.test_basepopulation.test_get_with_no_get_array
--
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/nose/case.py, line 197, in runTest
self.test(*self.arg)
File /«PKGBUILDDIR»/test/unittests/test_basepopulation.py, line 172,
in test_get_with_no_get_array
assert_equal(values[0]._name, i_offset)
AssertionError: Mock name='mock.i_offset._name' id='55966672' !=
'i_offset'
==
FAIL: unittests.test_files.test_NumpyBinaryFile
--
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/nose/case.py, line 197, in runTest
self.test(*self.arg)
File /«PKGBUILDDIR»/test/unittests/test_files.py, line 92, in
test_NumpyBinaryFile
assert_equal(nbf.get_metadata(), metadata)
AssertionError: {'a': 1, 'b': 9} != {'a': 1, 'b': 9.99}
- {'a': 1, 'b': 9}
+ {'a': 1, 'b': 9.99}
? +++
==
ERROR: unittests.test_files.test_NumpyBinaryFile
--
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/nose/case.py, line 197, in runTest
self.test(*self.arg)
File /tmp/buildd/pynn-0.7.2/test/unittests/test_files.py, line 92, in
test_NumpyBinaryFile
assert_equal(nbf.get_metadata(), metadata)
File
/tmp/buildd/pynn-0.7.2/build/lib.linux-x86_64-2.7/pyNN/recording/files.py,
line 216, in get_metadata
self.fileobj.seek(0)
ValueError: I/O operation on closed file
==
FAIL: unittests.test_basepopulation.test_get_with_no_get_array
--
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/nose/case.py, line 197, in runTest
self.test(*self.arg)
File /tmp/buildd/pynn-0.7.2/test/unittests/test_basepopulation.py, line
172, in test_get_with_no_get_array
assert_equal(values[0]._name, i_offset)
AssertionError: Mock name='mock.i_offset._name' id='58536080' != 'i_offset'
--
Ran 294 tests in 0.597s
FAILED (SKIP=6, errors=1, failures=1)
--
Michael Hanke
http://mih.voxindeserto.de
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675936: E: Could not perform immediate configuration on 'libhdf5-serial-dev'
Source: libhdf5-serial-dev Version: 1.8.8-9 Severity: serious Justification: Package fails to install Hi, the likelihood of this bug being reported to the wrong package is quite high, but I'll do it nevertheless, as this is were I noticed the problem. Here is the commented log: (all done on a more or less up-to-date i386 wheezy) % sudo apt-get install python-h5py [sudo] password for michael: Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: python-scientific libgl2ps0 libgps19 libvo-aacenc0 dcmtk libxp-dev libvo-amrwbenc0 libhal1 libgl2ps-dev qt-assistant-compat libyajl1 libmysqlclient18 libarmadillo3 libexiv2-12 libfreexl1 libdapclient3 libdapserver7 libkml0 libspatialite3 Use 'apt-get autoremove' to remove them. The following extra packages will be installed: hdf5-helpers hdf5-tools libarmadillo3 libdapclient3 libdapserver7 libexiv2-12 libfreexl1 libgeos-3.3.1 libgeos-c1 libhdf5-7 libhdf5-dev libhdf5-serial-dev libkml0 libmysqlclient18 libspatialite3 mysql-common octave3.2 octave3.2-headers Suggested packages: libhdf5-doc octave3.2-info octave3.2-doc octave3.2-htmldoc octave3.2-emacsen The following packages will be REMOVED: caret gdal-bin itksnap libgdal1-1.7.0 libhdf5-openmpi-1.8.4 libhdf5-openmpi-dev libkwwidgets1-dev libkwwidgets1.0.1009 libminc-dev libminc2-1 libnetcdf-dev libnetcdf6 libshogun8 libvtk5-dev libvtk5-qt4-dev libvtk5.6 libvtk5.8 libvtk5.8-qt4 libvtkgdcm2.0 mayavi2 merkaartor mitools odin python-insighttoolkit3 python-netcdf python-surfer python-vtk python-vtkgdcm qlandkartegt tcl-vtk The following NEW packages will be installed: hdf5-helpers libarmadillo3 libdapclient3 libdapserver7 libexiv2-12 libfreexl1 libgeos-3.3.1 libhdf5-7 libhdf5-dev libhdf5-serial-dev libkml0 libmysqlclient18 libspatialite3 python-h5py The following packages will be upgraded: hdf5-tools libgeos-c1 mysql-common octave3.2 octave3.2-headers 5 upgraded, 14 newly installed, 31 to remove and 909 not upgraded. Need to get 20.3 MB of archives. After this operation, 770 MB disk space will be freed. Do you want to continue [Y/n]? Get:1 http://ftp2.de.debian.org/debian/ wheezy/main hdf5-tools i386 1.8.8-9 [629 kB] Get:2 http://ftp2.de.debian.org/debian/ wheezy/main hdf5-helpers i386 1.8.8-9 [32.8 kB] Get:3 http://ftp2.de.debian.org/debian/ wheezy/main libhdf5-dev i386 1.8.8-9 [2,492 kB] Get:4 http://ftp2.de.debian.org/debian/ wheezy/main libhdf5-serial-dev i386 1.8.8-9 [24.3 kB] Get:5 http://ftp2.de.debian.org/debian/ wheezy/main octave3.2-headers i386 3.2.4-12+b1 [596 kB] Get:6 http://ftp2.de.debian.org/debian/ wheezy/main octave3.2 i386 3.2.4-12+b1 [9,509 kB] Get:7 http://ftp2.de.debian.org/debian/ wheezy/main libhdf5-7 i386 1.8.8-9 [1,331 kB] Get:8 http://ftp2.de.debian.org/debian/ wheezy/main libdapclient3 i386 3.11.1-10 [165 kB] Get:9 http://ftp2.de.debian.org/debian/ wheezy/main libdapserver7 i386 3.11.1-10 [99.9 kB] Get:10 http://ftp2.de.debian.org/debian/ wheezy/main mysql-common all 5.5.23+dfsg-2 [74.4 kB] Get:11 http://ftp2.de.debian.org/debian/ wheezy/main libmysqlclient18 i386 5.5.23+dfsg-2 [1,026 kB] Get:12 http://ftp2.de.debian.org/debian/ wheezy/main libfreexl1 i386 1.0.0b-1 [22.0 kB] Get:13 http://ftp2.de.debian.org/debian/ wheezy/main libarmadillo3 i386 1:3.2.0+dfsg-2 [18.9 kB] Get:14 http://ftp2.de.debian.org/debian/ wheezy/main libexiv2-12 i386 0.23-1 [798 kB] Get:15 http://ftp2.de.debian.org/debian/ wheezy/main libgeos-3.3.1 i386 3.3.1-1 [667 kB] Get:16 http://ftp2.de.debian.org/debian/ wheezy/main libgeos-c1 i386 3.3.1-1 [173 kB] Get:17 http://ftp2.de.debian.org/debian/ wheezy/main python-h5py i386 2.0.1-2+b1 [1,276 kB] Get:18 http://ftp2.de.debian.org/debian/ wheezy/main libkml0 i386 1.3.0~r863-4 [496 kB] Get:19 http://ftp2.de.debian.org/debian/ wheezy/main libspatialite3 i386 3.0.0~beta20110817-3 [870 kB] Fetched 20.3 MB in 17s (1,135 kB/s) E: Could not perform immediate configuration on 'libhdf5-serial-dev'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) It looked like a dependency nightmare was causing this, and it needed the equivalent of the following to get it to work. In summary: Remove anything that is remotely netcdf/hdf-related and bring it back by hand. % sudo dpkg --remove libhdf5-openmpi-dev octave3.2-headers libminc-dev libminc2-1 libnetcdf6 hdf5-tools libshogun8 libgdal1-1.7.0 octave-optim octave-specfun octave-gsl octave-psychtoolbox-3 octave-image octave-control
Bug#671844: condor: Configure fails if condor user exists
On Mon, May 07, 2012 at 01:29:55PM +0100, Lars Kotthoff wrote: Setting up condor (7.7.6~dfsg.1-2) ... adduser: The user `condor' already exists. Exiting. dpkg: error processing condor (--configure): subprocess installed post-installation script returned error exit status 1 May I ask where this condor user came from? According to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621833#119 this could only happen when the condor user exists, but is not a system user. If that was the case, I'm not sure what the package should do. Failing like it did doesn't seem to be the worst of a possible scenarios. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671844: condor: Configure fails if condor user exists
On Mon, May 07, 2012 at 03:23:52PM +0100, Lars Kotthoff wrote: May I ask where this condor user came from? According to It's possible that I installed it manually in the days when I couldn't find a Debian package. I just checked that at least recent versions of the Condor package from UWCS also create a _system_ user for Condor. There should be no problem in this respect when upgrading to the official package. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671844: condor: Configure fails if condor user exists
On May 7, 2012 4:23 PM, Lars Kotthoff li...@larsko.org wrote: May I ask where this condor user came from? According to It's possible that I installed it manually in the days when I couldn't find a Debian package. I'm not migrating from this custom installation however -- I've been using the Debian package for some time now and the system is just upgrading it. Are you referring to the Debian package from experimental that you are upgrading from, or to the Debian package that the condor group is providing? If the former is the case, I have no clue how this can happen. If the latter is the case, we have a problem. Could you, in this case provide some details on your existing condor user, e.g. the /etc/passwd line (actual passwd strippef, if present). Michael
Bug#671844: condor: Configure fails if condor user exists
On Mon, May 07, 2012 at 04:47:27PM +0100, Lars Kotthoff wrote: The line is condor:x:1002:1002:,,,:/home/condor:/bin/bash Here we go. I guess I added the user myself at some point. The thing is that I'm pretty sure that I installed the package from the Debian repo earlier and it didn't complain (or at least didn't fail). Yes, indeed. Before I checked whether there is a user condor and did not create one in case there was. Now I leave this to adduser -- which _only_ fails in the case of non-system user being present on the system. Now you need to convince me that the bug is in the package and not on your system ;-) The package would create something like this: condor:x:107:110:Condor Daemons,,,:/var/lib/condor:/bin/false I'd say it looks like this: - your condor user has login permissions although not necessary - has a homedir that is wrong - it might refer to an actual human user -- I can't tell You could say that the package should not interfere with the admin's decisions and happily accept any condor user it finds on a system. However, I disagree that a non-system user should be used for a system service. Chances are that there is an actual user named condor, in this case there would be a valid problem that should not be silenced. Right now, I'm leaning towards downgrading the severity of this bug to normal and tag it WONTFIX. But I'm open to consider any argument that would justify not failing with your system setup. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670304: condor: DO NOT MIGRATE YET
Source: condor Version: 7.7.6~dfsg.1-1 Severity: serious This bug is only here to prevent migration of Condor to testing before a 7.8 series package has been uploaded. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661658: cctools: FTBFS on kfreebsd
On Tue, Mar 27, 2012 at 09:44:01PM +0200, Julien Cristau wrote: On Tue, Mar 27, 2012 at 09:50:14 +0200, Michael Hanke wrote: Maybe a simple rebuild attempt would fix it (CC'ing the wb-team)? gb cctools_3.4.2-1 . kfreebsd-amd64 kfreebsd-i386 Done. Error remains the same -- need to look more closely. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661658: cctools: FTBFS on kfreebsd
On Fri, Mar 30, 2012 at 10:52:53AM +0200, Michael Hanke wrote:
Error remains the same -- need to look more closely.
I found the issue causing #661658. The python sysconfig package behaves
different on kfreebsd -- I think one could call this a bug (CC'ing -bsd
list). This little script shows the difference:
--
from distutils import sysconfig
cflags = sysconfig.get_config_var('CFLAGS')
if cflags is None:
print 'No CFLAGS variable'
elif cflags:
print CFLAGS='%s' % cflags
else:
print 'Empty CFLAGS'
--
Running on linux-i386 does:
% python sysconfig_freebsd_demo.py
CFLAGS='-fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes'
% CFLAGS=obscure python sysconfig_freebsd_demo.py
CFLAGS='-fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes'
but on kfreebsd it does:
asdfasdf% python sysconfig_freebsd_demo.py
Empty CFLAGS
asdfasdf% CFLAGS='obscure' python sysconfig_freebsd_demo.py
No CFLAGS variable
as far as I understand what it is supposed to do, I'd say that both
calls should yield the same result (at least), I tend to think that both
times CFLAGS should be defined, but for sure having a runtime CFLAGS env
var should not change the return value.
Regarding the cctools FTBFS this is easy to work around -- I'll upload a
fix later today. Regarding the cause of this problem, it would be nice
if a BSD porter could take a look and judge this a bug or not.
Cheers,
Michael
--
Michael Hanke
http://mih.voxindeserto.de
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661658: cctools: FTBFS on kfreebsd
On Fri, Mar 30, 2012 at 01:30:16PM +0100, Steven Chamberlain wrote: On 30/03/12 10:43, Michael Hanke wrote: but on kfreebsd it does: asdfasdf% python sysconfig_freebsd_demo.py Empty CFLAGS asdfasdf% CFLAGS='obscure' python sysconfig_freebsd_demo.py No CFLAGS variable Hi, I'm not seeing that problem on kfreebsd-i386, at least? Interesting. I got the above output on asdfasdf.debian.net's unstable chroot (kfreebsd-amd64, AFAIK). Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663472: Update coming
Quick info: An upstream update is coming into unstable within the next few days. -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661658: cctools: FTBFS on kfreebsd
On Fri, Mar 30, 2012 at 02:19:24PM +0100, Steven Chamberlain wrote: On 30/03/12 14:19, Petr Salinger wrote: Inside sid chroot: python2.6 2.6.7-4 python2.7 2.7.2-11 Thanks. This was probably debian/patches/issue9189.diff, which was introduced in 2.7.2-10 and re-jigged for 2.7.3. Not sure there's any point reporting a bug. The python2.7 transition (to 2.7.3) seems nearly complete anyway; just waiting on a fix for a different NeuroDebian package: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631856 This is next on the list! Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661658: cctools: FTBFS on kfreebsd
Hi, [sorry for the delay] On Wed, Feb 29, 2012 at 12:13:17AM +0100, Julien Cristau wrote: Source: cctools Version: 3.4.2-1 Severity: serious Justification: fails to build from source (but built successfully in the past) The relevant parts seem to be: checking for /usr/include/python2.7/Python.h...yes found python development libraries Traceback (most recent call last): File stdin, line 4, in module AttributeError: 'NoneType' object has no attribute 'split' I ran the respective bit of python code on asdfasdf.d.n and cannot reproduce the failure with Python 2.7. Maybe this was a transient issue in the kfreebsd port that is no longer present in today's unstable. Maybe a simple rebuild attempt would fix it (CC'ing the wb-team)? gb cctools_3.4.2-1 . kfreebsd-amd64 kfreebsd-i386 thanks, Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662739: condor: fails to remove: find: `/var/run/condor': No such file or directory
Hi, On Tue, Mar 06, 2012 at 07:07:50AM +0100, Andreas Beckmann wrote: Removing condor ... invoke-rc.d: policy-rc.d denied execution of stop. find: `/var/run/condor': No such file or directory dpkg: error processing condor (--remove): subprocess installed pre-removal script returned error exit status 1 thanks for the report. I think I have addressed this in the coming upload of Condor 7.7.5. However, before uploading there are a couple of other issues the need to be addressed. Cheers, Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647030: closed by Michael Hanke m...@debian.org (Bug#647030: fixed in kbibtex 0.4-1)
Hi, On Thu, Dec 15, 2011 at 10:33:30AM +0100, Bastien ROUCARIES wrote: Hi, I strongly disagree about closing this bug. It is a can of worms. It _could_ indeed be one. At least you should open a bug for qt where this bug lie, and if it is a spurious bug report due to some gcc bug [1], you should open a bug on the debian pts linking to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43976 Do you have tested if the program run on arm and mips ? No, I didn't tests it -- to be honest I don't even know how I could exhaustively check whether this would work, other than simply starting the program and loading a bib. According to my understanding of the problem it is only one if memory is allocated for a structure the pointer refers to and the actual type after casting would result in misaligned data access. However, I do not see an indication that this is actually happening. It is not a problem to do this type of casting just to pass pointers around, as long as the get cast again into the proper types before data access. If you want to see this tracked down, I'd very much appreciate if you perform the actions that you suggested above. However, to make those bug reports useful it would need some sort of comprehensible test case that is a lot less compless than the autogenerated code in kbibtex that causes it. Once again, I'm not saying that this might not a be bug . But it seems to me that it is currently not worth investing a significant amount of time, or asking others to do so. Of course this should not prevent any volunteer from making an attempt. Michael PS: As you seem to have a long-standing interest in kbibtex, have you thought about participating in the maintenance of the package? I'd be happy add you. -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623509: npm and mricron: error when trying to install together
On Sun, Oct 16, 2011 at 11:07:35AM +0200, Jérémy Lal wrote: On Thu, Apr 21, 2011 at 11:08:25AM -0400, Michael Hanke wrote: Upstream will do the rename shortly. Next upload will fix it. Michael Ping ? Sorry, lost track of this one. upstream didn't do the rename yet, so I have done it for the Debian package. Upload will comes in the next few hours. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644024: [kbibtex] New kbibtex detroy localfile information
Hi, On Sun, Oct 02, 2011 at 12:27:56AM +0200, Bastien ROUCARIES wrote: Package: kbibtex Version: 0.3-1 Severity: grave Set up a localfile field. Save the entry. edit the entry. go to source an d see that /some/path/document.pdf is transformed to http;:.//document.pdf It destroy a big part of my bib file, and thus render this package unsable with dataloss Sorry to hear about your data loss. I was just preparing the new upstream release 0.4 beta1. I followed you instructions to replicate the bug and I don't see it happening with the new code. I will upload within the next couple of hours. Michael -- Michael Hanke http://mih.voxindeserto.de signature.asc Description: Digital signature
Bug#618135: fslview: uninstallable in sid
On Tue, Aug 30, 2011 at 01:13:21AM +0100, Colin Watson wrote: On Tue, Jun 07, 2011 at 03:05:33PM -0400, Michael Hanke wrote: On Tue, Jun 07, 2011 at 08:43:15PM +0200, Ralf Treinen wrote: This bug (#618135) makes fslview also uninstallable in sid, on any architecture, since: fslview (= 3.1.8+4.1.6-2) depends on missing: - libvtk5.4 Upstream informed me that a qt4 port is about to become available. This will also finally make qwt4 packages in Debian obsolete (libqwt4c2, libqwt-dev). I hope, a 618135-close is only days away... Is there any news on this? It's been quite a few days. :-) I wish there would be. It will come, but any ETA prediction I got so far turned out to be wrong. At this point there is little I can do. Sorry, Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618135: fslview: uninstallable in sid
Hi, On Tue, Jun 07, 2011 at 08:43:15PM +0200, Ralf Treinen wrote: This bug (#618135) makes fslview also uninstallable in sid, on any architecture, since: fslview (= 3.1.8+4.1.6-2) depends on missing: - libvtk5.4 Upstream informed me that a qt4 port is about to become available. This will also finally make qwt4 packages in Debian obsolete (libqwt4c2, libqwt-dev). I hope, a 618135-close is only days away... Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628363: mricron: FTBFS: interfaces.pas(13,17) Fatal: Can't find unit Interfaces used by mricron
On Sat, May 28, 2011 at 04:10:38PM +0200, Lucas Nussbaum wrote: PPU Loading /usr/lib/lazarus/0.9.30/lcl/units/x86_64-linux/gtk2/interfaces.ppu PPU Source: interfaces.pas not found Recompiling Interfaces, checksum changed for System interfaces.pas(13,17) Fatal: Can't find unit Interfaces used by mricron ERROR: failed compiling of project /build/user-mricron_0.20110413.1~dfsg.1-1-amd64-zQY4V2/mricron-0.20110413.1~dfsg.1/mricron.lpi make[1]: *** [override_dh_auto_build] Error 2 That is lazarus misbehaving, not mricron. This is the same as #628313. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623145: DCMTK 3.6 compatibility needs work
block 623145 by 628168 tag 623145 + upstream forwarded 623145 th...@jochimsen.de thanks I looked into building ODIN with DCMTK 3.6 and there are a couple of problems (e.g. #628153 and #628168). But also ODIN itself needs an update to work with it. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626160: cctools: FTBFS on kFreeBSD
Package: cctools Severity: serious Justification: FTBFS @Cyril: I saw the FTBFS and I'm looking into it. Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625143: pyoptical: FTBFS: ImportError: No module named serial
reassign 625143 python-serial thanks On Mon, May 02, 2011 at 02:45:56PM +0200, Lucas Nussbaum wrote: During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: /usr/bin/fakeroot debian/rules clean dh clean dh_testdir dh_auto_clean Traceback (most recent call last): File setup.py, line 4, in module import pyoptical File /build/user-pyoptical_0.3-1-amd64-SBroiP/pyoptical-0.3/pyoptical.py, line 173, in module import serial ImportError: No module named serial dh_auto_clean: python2.7 setup.py clean -a returned exit code 1 make: *** [clean] Error 1 The reason for that seems to be that the pyserial package version in unstable has not been built for python 2.7. In a clean sid chroot as of today: head2:/tmp/pyoptical-0.3# python2.7 setup.py clean Traceback (most recent call last): File setup.py, line 4, in module import pyoptical File /tmp/pyoptical-0.3/pyoptical.py, line 173, in module import serial ImportError: No module named serial head2:/tmp/pyoptical-0.3# python2.6 setup.py clean running clean Therefor I'm reassigning this bug to pyserial. Please enlighten me if this conclusion is invalid. Thanks, Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623509: npm and mricron: error when trying to install together
tags 623509 + pending upstream thanks On Thu, Apr 21, 2011 at 11:08:25AM -0400, Michael Hanke wrote: I tend to agree with him -- most users probably start NPM by selecting it from the menu and being a GUI-tool it shouldn't be used in 3rd-party scripts. Hence, I guess the easy way out of this would be to rename mricron's npm to something like 'mricron-npm'. Upstream will do the rename shortly. Next upload will fix it. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623509: npm and mricron: error when trying to install together
Hi Chris, I want to draw your attention to a bug that has been filed against mricron yesterday: http://bugs.debian.org/623509 Summary: there is a filename conflict between 'npm' provided by mricron, and a binary with the same name coming from the 'npm' package. http://packages.debian.org/sid/npm Here is what the npm maintainer wrote in response: On Thu, Apr 21, 2011 at 11:09:11AM +0200, Jérémy Lal wrote: Hi, users expect npm to provide npm, and is only invoked on the command line, so renaming will certainly deceive users. And the other hand, mricron's npm has a .desktop file and can be renamed without users losing track of it (being still listed in the Education's menu as NPM). A quick glance at mricron shows it does not rely on /usr/bin/npm so it wouldn't need a patch. I tend to agree with him -- most users probably start NPM by selecting it from the menu and being a GUI-tool it shouldn't be used in 3rd-party scripts. Hence, I guess the easy way out of this would be to rename mricron's npm to something like 'mricron-npm'. Would you support this? Are we missing something in this assessment of the situation? Thanks, Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623172: [condor-admin #22002] classad 1.0.10 unittest fails on i386
On Thu, Apr 21, 2011 at 02:53:14PM -0500, condor-admin response tracking system wrote: FYI: The problem has been dealt with by applying the patch below. Clearly a fix for the symptom and not the actual problem -- which may not even be related to the classads code. =20 Anyway, with this patch the package builds and the unit tests runs fine on i386. Please let me know if you have any concerns regarding this fix. I haven't been able to reproduce the failure. We don't have a 32-bit debian= box with gcc 4.5.2, but I've tried it on a 32-bit rhel5 machine with gcc 4= .5.2. I'll apply a modified form of your patch. It appears we can just replace !_= stream-eof() with _stream-good(). Thanks for the report. Thanks! Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623172: classads: FTBFS on i386: extra_tests(_ns) aborts when reading from ifstream
On Sun, Apr 17, 2011 at 11:12:21PM -0400, Aaron M. Ucko wrote: Builds of classads on i386 have started failing with two test suite errors: Thanks for the note. I was able to reproduce this in a local chroot -- will look into it. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623172: Problem is still unclear
The situation is a little confusing. The respective unit test only fails when it runs as part of 'make check'. When executed individually it runs and passes fine. Moreover, 'make check' passes when the package is built without optimization (i.e. -O0) That makes it a little difficult to debug. Valgrind reports: ==28928== 1 errors in context 1 of 60: ==28928== Conditional jump or move depends on uninitialised value(s) ==28928==at 0x494ABA0: Lexer::tokenizePunctOperator() (lexer.cpp:579) ==28928==by 0x4949F90: Lexer::PeekToken(Lexer::TokenValue*) (lexer.cpp:254) ==28928==by 0x495AC92: ClassAdParser::parseClassAd(ClassAd, bool) (source.cpp:1161) ==28928==by 0x4957D15: ClassAdParser::ParseClassAd(LexerSource*, ClassAd, bool) (source.cpp:211) ==28928==by 0x4957C97: ClassAdParser::ParseClassAd(std::istream, ClassAd, bool) (source.cpp:199) ==28928==by 0x804A928: read_from_stream_alt(ClassAd**, ClassAd**) (extra_tests.cpp:344) ==28928==by 0x8049E44: test_parsing() (extra_tests.cpp:135) ==28928==by 0x8049C33: main (extra_tests.cpp:89) ==28928== Uninitialised value was created by a stack allocation ==28928==at 0x494B56F: InputStreamLexerSource::ReadCharacter() (lexerSource.cpp:111) which might have something to do with the problem. ... -- Michael Hanke http://mih.voxindeserto.de:q -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623172: classad 1.0.10 unittest fails on i386
Dear Condor developers, I have recently updated the Debian package of classad to version 1.0.10. With this version one unit test (extra_tests) started to fail on i386. Here is the build log: https://buildd.debian.org/status/fetch.php?pkg=classadsarch=i386ver=1.0.10-1stamp=1302915198 Strangely, the test only fails when ran as part of 'make check', and only with enabled optimizations. It passes when ran separately, or when built with -O0. Here is the related bug report with a valgrind snippet that might be related to the problem. http://bugs.debian.org/623172 All eleven other architectures the package has been built for seem to be unaffected by this: https://buildd.debian.org/status/package.php?p=classads This might also be related to the GCC version used. I wasn't able to reproduce the behavior on a i386 system with GCC 4.4.5, but I can reliably reproduce this bug with GCC 4.5.2 (a different machine than the build machine that failed initially). I'd be glad if someone could look into this issue. Thanks in advance, Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618645: caret: FTBFS on kfreebsd-*: Basename.cxx:64:14: error: 'period' was not declared in this scope
Hi Cyril, On Thu, Mar 17, 2011 at 08:22:10AM +0100, Cyril Brulebois wrote: your package no longer builds on kfreebsd-*: | make[1]: Entering directory `/build/buildd-caret_5.6.2~dfsg.1-1-kfreebsd-amd64-B3QFJ6/caret-5.6.2~dfsg.1/caret_common' | g++ -c -pipe -fopenmp -DUBUNTU -Wno-deprecated -g -Wno-deprecated -Wall -g -O2 -DCARET_BUILDID=Debian_amd64 -D_REENTRANT -Wall -W -fPIC -DCARET_FLAG -DHAVE_MINC -DHAVE_QWT -DHAVE_VTK -DHAVE_VTK5 -DHAVE_MINC -DQT_NO_DEBUG -DQT_PLUGIN -DQT_XML_LIB -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtOpenGL -I/usr/include/qt4/QtXml -I/usr/include/qt4 -I. -I../caret_brain_set -I../caret_command_operations -I../caret_common -I../caret_statistics -I../caret_files -I../caret_uniformize -I../caret_widgets -I/usr/include -I/usr/include/qwt-qt4 -I/usr/include/vtk-5.6 -I/usr/include -I/usr/X11R6/include -I. -o Basename.o Basename.cxx | Basename.cxx: In function 'const char* Basename(char*)': | Basename.cxx:64:14: error: 'period' was not declared in this scope | Basename.cxx:68:14: error: 'period' was not declared in this scope | make[1]: *** [Basename.o] Error 1 I looked into this, but I cannot reproduce the error. I ran cpp on the asdfasdf porter box and the period symbol gets defined properly. This is the code -- and kfreebsd matches Q_OS_GLIBC: #if defined(Q_OS_LINUX) || defined(Q_OS_GLIBC) static const char *period = .; #endif Compiling the whole file with the exact same line also works fine on that box. Is there any chance that this could have been caused by a temporary issue on the kfreebsd buildd machines (both i386 and amd64 failed with the same error). Thanks, Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618645: caret: FTBFS on kfreebsd-*: Basename.cxx:64:14: error: 'period' was not declared in this scope
On Fri, Apr 15, 2011 at 04:11:59PM +0200, Cyril Brulebois wrote: Michael Hanke michael.ha...@gmail.com (15/04/2011): Is there any chance that this could have been caused by a temporary issue on the kfreebsd buildd machines (both i386 and amd64 failed with the same error). Giving back is easy enough, I just did that on both architectures. Thanks. However, it failed again. That leaves me a bit clueless. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554061: FTBFS with binutils-gold
On Wed, Mar 09, 2011 at 03:05:22PM -0500, Michael Hanke wrote: On Wed, Mar 09, 2011 at 07:32:58PM +0100, Julien Cristau wrote: Ping? This is now FTBFS in sid, see http://lists.debian.org/4d6a7520.2090...@debian.org. I am aware, and waiting for a new upstream release that was promised to arrive last week. it is supposed to fix this and a number of other issue that made any upstream release after 5.6.1 inferior to this one. I cannot give a better estimate of when a new upload will happen, but it is not forgotten. Fixing this particular issue in this outdated version is a bit of a waste of time as it looks like that upstream did major changes to the build-system. I have the new upstream code now and started working on a new package version. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554061: FTBFS with binutils-gold
On Wed, Mar 09, 2011 at 07:32:58PM +0100, Julien Cristau wrote: severity 554061 serious kthxbye On Mon, Nov 2, 2009 at 22:10:30 +0100, Peter Fritzsche wrote: Package: caret Version: 5.6.1~dfsg.1-4 Severity: minor User: peter.fritzs...@gmx.de Usertags: no-add-needed Tried to build your package and it fails to build with GNU binutils-gold. The important difference is that --no-add-needed is the default behavior of of GNU binutils-gold. Please provide all needed libraries to the linker when building your executables. Ping? This is now FTBFS in sid, see http://lists.debian.org/4d6a7520.2090...@debian.org. I am aware, and waiting for a new upstream release that was promised to arrive last week. it is supposed to fix this and a number of other issue that made any upstream release after 5.6.1 inferior to this one. I cannot give a better estimate of when a new upload will happen, but it is not forgotten. Fixing this particular issue in this outdated version is a bit of a waste of time as it looks like that upstream did major changes to the build-system. Sorry, Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604279: KDE4 port
An initial package for the KDE4 port is ready. However, it has significantly less features than the current KDE3 version in testing. ATM it looks like it would be best to wait a little longer before replacing the KDE package. But at least it can be done at any point now when the KDE3 libs are actually going to be removed. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605612: Patch
Attached is the tentative patch to fix this bug. It has been submitted
to upstream for review. An upload of a fixed version of 5.6.1.3 will
happen shortly.
A proper fix will be implemented in an upcoming upstream release that
will be uploaded after the release of squeeze.
Michael
--
Michael Hanke
http://mih.voxindeserto.de
diff --git a/caret_common/HttpFileDownload.cxx
b/caret_common/HttpFileDownload.cxx
index 365c29a..7f16fb5 100644
--- a/caret_common/HttpFileDownload.cxx
+++ b/caret_common/HttpFileDownload.cxx
@@ -199,11 +199,13 @@ HttpFileDownload::uploadFileToSums(const
std::vectorQString additionalTags,
}
//#endif // QT4_FILE_POS_BUG
QDataStream dataStream(file);
+ dataStream.setVersion(QDataStream::Qt_4_3);
// file contents
QFile inputFile(uploadFileName);
if (inputFile.open(QIODevice::ReadOnly)) {
QDataStream inputStream(inputFile);
+ inputStream.setVersion(QDataStream::Qt_4_3);
const int inputFileSize = inputFile.size();
const int bufferSize = 4096;
@@ -549,6 +551,7 @@ HttpFileDownload::slotDone(bool error)
QFile file(outputFileName);
if (file.open(QIODevice::WriteOnly)) {
QDataStream stream(file);
+ stream.setVersion(QDataStream::Qt_4_3);
stream.writeRawData(ba.data(), num);
file.close();
}
diff --git a/caret_files/AbstractFile.cxx b/caret_files/AbstractFile.cxx
index 696eaaf..b98e369 100644
--- a/caret_files/AbstractFile.cxx
+++ b/caret_files/AbstractFile.cxx
@@ -1028,6 +1028,7 @@ AbstractFile::readFileFromArray(const char* data,
throw FileException(, Unable to create temporary read/write file in
AbstractFile::readFile);
}
QDataStream stream(file);
+ stream.setVersion(QDataStream::Qt_4_3);
stream.writeRawData(data, dataLength);
//char newline[2] = { '\n', '\0' };
//stream.writeRawBytes(newline, 1);
@@ -1050,6 +1051,7 @@ AbstractFile::readFileContents(QFile file) throw
(FileException)
//
QTextStream stream(file);
QDataStream binStream(file);
+ binStream.setVersion(QDataStream::Qt_4_3);
//
// Determine if GIFTI node data file
@@ -2253,6 +2255,7 @@ AbstractFile::writeFileToArray(QByteArray ba) throw
(FileException)
{
QTextStream ts(ba, QIODevice::WriteOnly);
QDataStream ds(ba, QIODevice::WriteOnly);
+ ds.setVersion(QDataStream::Qt_4_3);
writeFileContents(ts, ds);
}
@@ -2463,6 +2466,7 @@ AbstractFile::writeFile(const QString filenameIn) throw
(FileException)
if (writingQFile-open(QFile::WriteOnly)) {
QTextStream stream(writingQFile);
QDataStream binStream(writingQFile);
+ binStream.setVersion(QDataStream::Qt_4_3);
try {
writeFileContents(stream, binStream);
@@ -3421,6 +3425,7 @@ AbstractFile::findBinaryDataOffsetQT4Bug(QFile file,
file.seek(0);
QDataStream dataStream(file);
+ dataStream.setVersion(QDataStream::Qt_4_3);
const int arraySize = 2048;
char buffer[arraySize];
diff --git a/caret_files/CommaSeparatedValueFile.cxx
b/caret_files/CommaSeparatedValueFile.cxx
index 85ec309..84de5d0 100644
--- a/caret_files/CommaSeparatedValueFile.cxx
+++ b/caret_files/CommaSeparatedValueFile.cxx
@@ -107,6 +107,7 @@ CommaSeparatedValueFile::readFromTextStream(QFile file,
QTextStream stream) throw
(FileException)
{
QDataStream dummyDataStream(file);
+ dummyDataStream.setVersion(QDataStream::Qt_4_3);
QDomElement dummyDomElement;
readFileData(file, stream, dummyDataStream, dummyDomElement);
}
@@ -118,6 +119,7 @@ void
CommaSeparatedValueFile::writeToTextStream(QTextStream stream) throw
(FileException)
{
QDataStream dummyDataStream;
+ dummyDataStream.setVersion(QDataStream::Qt_4_3);
QDomDocument dummyDomDocument;
QDomElement dummyDomElement;
diff --git a/caret_files/GiftiDataArray.cxx b/caret_files/GiftiDataArray.cxx
index 43e7dcb..11eacf2 100644
--- a/caret_files/GiftiDataArray.cxx
+++ b/caret_files/GiftiDataArray.cxx
@@ -929,6 +929,7 @@ GiftiDataArray::readFromText(QString text,
// Read the data
//
QDataStream stream(file);
+ stream.setVersion(QDataStream::Qt_4_3);
const int numBytesRead =
stream.readRawData((char*)pointerToForReadingData,
numberOfBytes);
if (numBytesRead != numberOfBytes) {
diff --git a/caret_files/GiftiDataArrayFile.cxx
b/caret_files/GiftiDataArrayFile.cxx
index 62372f7..5841942 100644
--- a/caret_files/GiftiDataArrayFile.cxx
+++ b/caret_files/GiftiDataArrayFile.cxx
@@ -947,6 +947,7 @@ GiftiDataArrayFile::readFileDataXML(QFile file) throw
(FileException)
// Create a data stream
//
QDataStream stream(file);
+ stream.setVersion(QDataStream::Qt_4_3
Bug#605612: Problem identified
Update: The problem is caused by a change in the behavior of QDataStream in Qt 4.6 compared to older versions. The solution seems to be to set the stream protocol version explicitly. We are working on having a clean/compact patch and hope to be able to tag this bugs as 'pending' shortly. Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605612: caret: Incompatibility with recent Qt versions causes surface IO to corrupt data
Package: caret Version: 5.6.1.3~dfsg.1-1 Severity: grave Tags: upstream Justification: renders package unusable When reading surface data files, Caret (when linked against recent Qt version, e.g. 4.6) fails to load the data properly. Consequently, it becomes impossible to use any functionality without producing corrupted results. An example of rendering of a corrupted brain surface can be seen here http://brainvis.wustl.edu/wiki/index.php/File:LinuxImageCorrupt.jpg Upstream is currently testing a fix. The Debian maintainer will try to backport this fix to the current version in squeeze, if possible. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages caret depends on: ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-4GCC support library ii libgl1-mesa-glx [li 7.7.1-4 A free implementation of the OpenG ii libglu1-mesa [libgl 7.7.1-4 The OpenGL utility library (GLU) ii libgomp14.4.5-4 GCC OpenMP (GOMP) support library ii libminc2-1 2.0.18+cvs20100518-1 MNI medical image format library ii libqt4-assistant4:4.6.3-4Qt 4 assistant module ii libqt4-network 4:4.6.3-4Qt 4 network module ii libqt4-opengl 4:4.6.3-4Qt 4 OpenGL module ii libqt4-xml 4:4.6.3-4Qt 4 XML module ii libqtcore4 4:4.6.3-4Qt 4 core module ii libqtgui4 4:4.6.3-4Qt 4 GUI module ii libqwt5-qt4 5.2.0-1 Qt4 widgets library for technical ii libstdc++6 4.4.5-4 The GNU Standard C++ Library v3 ii libvtk5.4 5.4.2-7+b2 Visualization Toolkit - A high lev ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime caret recommends no packages. Versions of packages caret suggests: ii caret-data 5.6~dfsg.1-1 common data files for Caret -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592242: Processed: reopening 592242
Hi, On Tue, Aug 10, 2010 at 05:16:30PM -0400, Michael Hanke wrote: I see the point in policy 10.1, but I believe the problem it tries to avoid doesn't exist in this case. After some more discussions on -devel I'm now convinced that there is no use in arguing about closing this bug without further action. As an attempt to finally fix this bug I'll make a new upload that: * removes all /usr/bin symlinks from the 'fsl' package and hence removes all file/package conflicts from this package -- allowing to close this bug * keep the 'fsl' package as a meta package that depends on the latest version of FSL and maintains the configuration setup of previous package, to allow people to keep their existing setup and not have to change a single thing if the only upgrade from fsl 4.1.6-3 * introduce /usr/bin symlinks (via a wrapper) in the 'fsl-4.1' package to address to configuration difficulty issue that was originally intended to be improved with the previous attempt. This time however, it will be version specific symlinks names that have very little chance of conflicting -- ever. One of the previously conflicting binaries 'immv' would now be 'fsl4.1-immv'. Rational: version specific names allow multiple versions to coexists. Symlinking to a wrapper script keep upstream script relying on a specific environment setup intact (and all users relying on it unaffected). Prefixing with 'fslMAJORVERSION-' instead of postfixing with '-MAJORVERSION' has a reduced potential for confusion and future conflicts. Think: 'slicer-4.1' (from FSL) and 'slicer3' (from slicer package) vs 'fsl4.1-slicer' and 'slicer3' If there are no fundamental objections to this approach, I'll upload sometime over the next days. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592242: Processed: reopening 592242
# conflicts are not appropriate for conflicts between executable names reopen 592242 Well, that has been mentioned before and my reasoning is at [0] -- got no comments. I'd be interested in advice what kind of resolution would allow me to close this bug. Renaming the relevant commands makes no sense, because it affects the behavior of the whole FSL toolkit. FYI we are not just talking about the 'imtest' command that caused this bug to be opened -- if one looks at the actual package more conflicts will be obvious. Not to speak about all documentation that is obsolete after a rename. Asking for a rename in the conflicting packages is totally inappropriate: 1. nothing is gained, 2. they are in main and fsl is in non-free, 3. probably breaks even more. IMHO that leaves exactly one solution - not having such a package at all. Which in turn means that FSL users may not have an out-of-the-box setup, because I cannot express a package conflict when there really is one? To reiterate: the 'fsl' package merely installs convenience symlinks of the FSL suite into /usr/bin. The actual commands are installed into a private namespace. FSL is fully usable without the symlinks, after following a documented setup procedure. The sole purpose of the 'fsl' package is to provide people with a working setup without having them to know about that setup. It is quite unlikely that any of the conflicting packages would appear on a real system that runs FSL -- they are typically built to run exactly this suite. I see the point in policy 10.1, but I believe the problem it tries to avoid doesn't exist in this case. I'd be very happy to get comments. Michael [0] http://lists.debian.org/debian-release/2010/08/msg00309.html -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590612: Same as #519006
This bug is essentially the same as #519006. The suggested workaround is to compile without -g, or wait for GCC4.5. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592242: fsl and cyrus-clients-2.2: error when trying to install together
reassign 592242 fsl 4.1.6-2 tags 592242 + pending thanks On Sun, Aug 08, 2010 at 06:02:43PM +0200, Ralf Treinen wrote: /usr/bin/imtest /usr/share/man/man1/imtest.1.gz This bug is assigned to both packages. If you, the maintainers of the two packages in question, have agreed on which of the packages will resolve the problem please reassign the bug to that package. That is my fault. 'fsl' is a convenience package that installs symlinks of a large suite of tools into /usr/bin. I went through the archive looking for conflict, found some and added conflicts, but must have missed this one. Bugfix-upload will come in the next few days... Thanks for detecting this. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589589: pynifti: nonexistent build-dependency: python-numpy-ext
hi, On Sun, Jul 18, 2010 at 11:22:45PM +0200, Jakub Wilk wrote: pynifti build-depends on python-numpy-ext, but this package is no longer available in unstable. That would have been easy to fix. However, the transition to numpy 1.4 revealed another bug (not sure if in pynifti or numpy) that causes a FTBFS of this package. Investigating... Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589881: xmedcon: Please adjust build-dep on libnifti-dev
Package: xmedcon Version: 0.10.5-1 Severity: serious Tags: patch Justification: would fail to build from source (but built successfully in the past) Hi Rudi, as announced previously the new nifticlibs package has been uploaded to unstable. It no longer provides the libnifti1-dev package. Please adjust the build-dependency to 'libnifti-dev'. A patch is attached. Thanks in advance, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de diff -rNu xmedcon-0.10.5/debian/control xmedcon-0.10.5.new/debian/control --- xmedcon-0.10.5/debian/control 2010-07-21 16:45:32.0 -0400 +++ xmedcon-0.10.5.new/debian/control 2010-07-21 16:34:23.0 -0400 @@ -2,7 +2,7 @@ Section: graphics Priority: optional Maintainer: Roland Marcus Rutschmann r...@debian.org -Build-Depends: debhelper (= 5.0.51~), libgtk2.0-dev, zlib1g-dev, libpng12-dev, libnifti1-dev +Build-Depends: debhelper (= 5.0.51~), libgtk2.0-dev, zlib1g-dev, libpng12-dev, libnifti-dev Standards-Version: 3.8.2 Package: libmdc2
Bug#583208: Problem ITK 3.16 - 3.18
Hi ITK experts,
I packaged ITK-snap for Debian and it just made it through NEW.
http://packages.debian.org/sid/itksnap
When it got uploaded it was built against ITK 3.16 and life was fun. Now
ITK 3.18 arrived and it FTBFS on all archs having it.
https://buildd.debian.org/fetch.cgi?pkg=itksnap;ver=2.0.0-1;arch=amd64;stamp=1274787431
I'd be glad if you could have a quick look at the error -- it is
related to (re)definition of types in ITK that seemed to have changed a
lot between these two releases, i.e.
/usr/include/InsightToolkit/Common/itkIntTypes.h
I cannot make sense of the error messages like:
/usr/include/inttypes.h:298: error: reference to 'intmax_t' is ambiguous
/usr/include/stdint.h:135: error: candidates are: typedef long int intmax_t
/usr/include/InsightToolkit/Common/itkIntTypes.h:140: error:
typedef intmax_t itk::intmax_t
The following error make me think that something more fundamental is
wrong:
In file included from /usr/include/GL/gl.h:2089,
from /usr/include/FL/gl.h:53,
from
/build/buildd-itksnap_2.0.0-1-amd64-Y0TyDz/itksnap-2.0.0/UserInterface/Window3D/Trackball.h:38,
from
/build/buildd-itksnap_2.0.0-1-amd64-Y0TyDz/itksnap-2.0.0/Common/SystemInterface.h:40,
from
/build/buildd-itksnap_2.0.0-1-amd64-Y0TyDz/itksnap-2.0.0/Logic/Framework/IRISApplication.h:41,
from
/build/buildd-itksnap_2.0.0-1-amd64-Y0TyDz/itksnap-2.0.0/UserInterface/MainComponents/PreprocessingUILogic.cxx:24:
/usr/include/GL/glext.h:5186: error: 'GLint64' has not been declared
It doesn't seem to be general bug in ITK. Something like this compiles
just fine:
#include InsightToolkit/Common/itkIntTypes.h
#include iostream
using namespace std;
int main()
{
cout Hello World! endl;
}
What change in ITK could cause this behavior. Any hints are very much
appreciated.
Thanks,
Michael
--
GPG key: 1024D/3144BE0F Michael Hanke
http://mih.voxindeserto.de
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583206: mrtrix: FTBFS on kfreebsd
Package: mrtrix Version: 0.2.8-1 Severity: serious Tags: upstream Justification: fails to build from source (but built successfully in the past) A syntax error (at least) prevents the package from building on kfreebsd: https://buildd.debian.org/fetch.cgi?pkg=mrtrix;ver=0.2.8-1;arch=kfreebsd-amd64;stamp=1274786175 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-3-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mrtrix depends on: ii libatk1.0-0 1.30.0-1The ATK accessibility toolkit ii libc62.10.2-6Embedded GNU C Library: Shared lib ii libcairo21.8.10-4The Cairo 2D vector graphics libra ii libcairomm-1.0-1 1.8.4-1 C++ wrappers for Cairo (shared lib ii libfontconfig1 2.8.0-2.1 generic font configuration library ii libfreetype6 2.3.11-1FreeType 2 font engine, shared lib ii libgcc1 1:4.4.2-9 GCC support library ii libgl1-mesa-glx [libgl1] 7.7.1-1 A free implementation of the OpenG ii libglib2.0-0 2.24.0-1The GLib library of C routines ii libglibmm-2.4-1c2a 2.24.1-1C++ wrapper for the GLib toolkit ( ii libglu1-mesa [libglu1] 7.7.1-1 The OpenGL utility library (GLU) ii libgsl0ldbl 1.14+dfsg-1 GNU Scientific Library (GSL) -- li ii libgtk2.0-0 2.20.0-3The GTK+ graphical user interface ii libgtkglext1 1.2.0-1 OpenGL Extension to GTK+ (shared l ii libgtkmm-2.4-1c2a1:2.20.2-1 C++ wrappers for GTK+ (shared libr ii libice6 2:1.0.6-1 X11 Inter-Client Exchange library ii libpango1.0-01.28.0-1Layout and rendering of internatio ii libpangomm-1.4-1 2.26.1-1C++ Wrapper for pango (shared libr ii libsigc++-2.0-0c2a 2.2.4.2-1 type-safe Signal Framework for C++ ii libsm6 2:1.1.1-1 X11 Session Management library ii libstdc++6 4.4.2-9 The GNU Standard C++ Library v3 ii libx11-6 2:1.3.3-3 X11 client-side library ii libxmu6 2:1.0.5-1 X11 miscellaneous utility library ii libxt6 1:1.0.7-1 X11 toolkit intrinsics library mrtrix recommends no packages. Versions of packages mrtrix suggests: ii mrtrix-doc0.2.8-1documentation for mrtrix -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583208: FTBFS: error: reference to 'intmax_t' is ambiguous
Package: itksnap Version: 2.0.0-1 Severity: serious Justification: fails to build from source (but built successfully in the past) Doesn't build on mips, kfreebsd*, amd64 -- potentially ITK version issue: https://buildd.debian.org/fetch.cgi?pkg=itksnap;ver=2.0.0-1;arch=amd64;stamp=1274787431 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-3-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages itksnap depends on: ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libfltk1.11.1.10-2 Fast Light Toolkit - shared librar ii libgcc1 1:4.4.2-9 GCC support library ii libgl1-mesa-glx [libgl1] 7.7.1-1A free implementation of the OpenG ii libglu1-mesa [libglu1]7.7.1-1The OpenGL utility library (GLU) ii libinsighttoolkit3.16 3.16.0-1 Image processing toolkit for regis ii libstdc++64.4.2-9The GNU Standard C++ Library v3 ii libvtk5.2 5.2.1-11 Visualization Toolkit - A high lev itksnap recommends no packages. itksnap suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583208: FTBFS: error: reference to 'intmax_t' is ambiguous
On Wed, May 26, 2010 at 07:34:46AM -0400, Michael Hanke wrote: Doesn't build on mips, kfreebsd*, amd64 -- potentially ITK version issue: My initial speculation seems to be correct -- it build fine with ITK 3.16.0 and fails with 3.18.0. Need to look what changed. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520701: Update
There hasn't been much progress on the upstream side regarding a major update to make Caret compatible with recent VTK versions. As a result Caret remains severely broken. The Debian maintainer's evaluation of the required patch made him conclude that it would not be resonable to patch it for VTK compatibility, since the patch would need to be quite intrusive and the potential for significant undesired side-effects is high. Information from the lab developing Caret indicates that upstream is evaluating ways how to get it in shape for the future (including major overhaul or reimplementation). Hope remains, but so far nothing happened. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520701: vtk dependencies are unresolvable
Hi, On Sun, Jan 31, 2010 at 03:30:10PM -0500, Lee Azzarello wrote: I tried to test building this against libvtk5.2 in sid and I noticed that this package doesn't even have a -dev. So I downloaded the source package and tried to figure out where libvtk5.2 comes from by building the source package. The build failed. It appears vtk is broken therefore caret will not build until that is fixed. Sid should have VTK 5.4 now. Anyway, yes Caret is broken. This is documented here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522486 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520701 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525789 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554061 All these bugreports are reflections of the same problem. Caret is outdated, and currently upstream refuses to update the code to be compatible with recent library versions (e.g. VTK). I tried starting a patch, but soon realized that it goes deep into the core, and I wouldn't have a clue what I would break. I'm hoping that at some point upstream agrees that it is time to move on -- let's hope. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562309: fslview: FTBFS: make[3]: *** No rule to make target `/usr/lib/openmpi/lib/libmpi_cxx.so', needed by `bin/fslview'. Stop.
Hi, [ sorry for the delay ] On Fri, Dec 25, 2009 at 06:27:05PM -0500, Michael Hanke wrote: Hi, On Thu, Dec 24, 2009 at 11:31:42AM +0100, Lucas Nussbaum wrote: Source: fslview Version: 3.1.2+4.1.4-2 Severity: serious User: debian...@lists.debian.org Usertags: qa-ftbfs-20091213 qa-ftbfs Justification: FTBFS on amd64 /build/user-fslview_3.1.2+4.1.4-2-amd64-imf6Ze/fslview-3.1.2+4.1.4/src/storage/image.h:42: warning: 'typedef' was ignored in this declaration make[3]: *** No rule to make target `/usr/lib/openmpi/lib/libmpi_cxx.so', needed by `bin/fslview'. Stop. make[2]: *** [src/fslview/CMakeFiles/fslview.dir/all] Error 2make[3]: Leaving directory `/build/user-fslview_3.1.2+4.1.4-2-amd64-imf6Ze/fslview-3.1.2+4.1.4/obj-x86_64-linux-gnu' Hmmm, fslview doesn't use openmpi. Don't know why this shows up, since the sources do not refer to any mpi-related stuff. I am somewhat inclined to blame some package that fslview build-depends on. It seems that I was right with my assumption. Fslview links against libvtkHybrid.so that is in turn linked against 74 other libraries. Here is a list of selected items (I might have missed other important ones, or added some false positive): libmysqlclient.so.16 = /usr/lib/libmysqlclient.so.16 (0xf6547000) libavcodec.so.52 = /usr/lib/i686/cmov/libavcodec.so.52 (0xf566e000) libavformat.so.52 = /usr/lib/i686/cmov/libavformat.so.52 (0xf5573000) libavutil.so.49 = /usr/lib/i686/cmov/libavutil.so.49 (0xf5561000) libswscale.so.0 = /usr/lib/i686/cmov/libswscale.so.0 (0xf5533000) libmpi_cxx.so.0 = /usr/lib/libmpi_cxx.so.0 (0xf54ec000) libmpi.so.0 = /usr/lib/libmpi.so.0 (0xf5455000) libopen-rte.so.0 = /usr/lib/libopen-rte.so.0 (0xf5413000) libopen-pal.so.0 = /usr/lib/libopen-pal.so.0 (0xf53ac000) libdirac_encoder.so.0 = /usr/lib/libdirac_encoder.so.0 (0xf4fdc000) To be able to build fslview on sid I would need to add the following build-dependencies libopenmpi-dev libavcodec-dev libavformat-dev libswscale-dev libgl2ps-dev However, none of them is required by fslview itself, but all are pulled in by VTK. I therefore think that the 'vtki5-dev' package should depend on these instead. On the other hand, I can remove all of the -l statements for the libraries above from the link command in question and linking still works -- so apparently these libs are no really critical. Yet, there are added is deps for linking (somehow). I'm not sure you who is to blame. cmake is identical in squeeze and sid and linking works on squeeze. OTOH VTK is more advanced in sid, but the complexity of the package makes it relatively difficult to get a clue what is going on. For now, I'm going to reassign this bug to vtk, since there seems to be little that I can do in fslview to fix that properly. For reference: The only relevant link config in the CMakeLists.txt of fslview is this src/fslview/CMakeLists.txt:TARGET_LINK_LIBRARIES( fslview vtkHybrid vtkWidgets QVTK ) (there is more linking: local libs, Qt, but nothing related to the problem above) Linking is attempted with this command (this is a single command, reformated for better readability): --- /usr/bin/g++ -g -O2 -I/tmp/fslview-3.1.2+4.1.4/fsl/libprob -I/usr/include/newmat -I/usr/include/qwt -I/usr/include/nifti -g -Wall -O2 -Wno-deprecated -Wl,--as-needed -Wl,--no-undefined CMakeFiles/fslview.dir/main.o CMakeFiles/fslview.dir/preferences.o CMakeFiles/fslview.dir/atlas.o CMakeFiles/fslview.dir/filemanager.o CMakeFiles/fslview.dir/logger.o CMakeFiles/fslview.dir/application.o CMakeFiles/fslview.dir/assistantclient.o CMakeFiles/fslview.dir/splashscreen.o CMakeFiles/fslview.dir/version.o CMakeFiles/fslview.dir/tracker.o CMakeFiles/fslview.dir/cursor.o CMakeFiles/fslview.dir/bricon.o CMakeFiles/fslview.dir/imagegroup.o CMakeFiles/fslview.dir/overlaylist.o CMakeFiles/fslview.dir/metaimage.o CMakeFiles/fslview.dir/imagedata.o CMakeFiles/fslview.dir/drawsettings.o CMakeFiles/fslview.dir/imagedisplaysetting.o CMakeFiles/fslview.dir/lookuptable.o CMakeFiles/fslview.dir/curvedatalist.o CMakeFiles/fslview.dir/imagedatastore.o CMakeFiles/fslview.dir/imagebuffer.o CMakeFiles/fslview.dir/graphmanager.o CMakeFiles/fslview.dir/briconwidget.o CMakeFiles/fslview.dir/cursorwidget.o CMakeFiles/fslview.dir/drawwidget.o CMakeFiles/fslview.dir/imagewidget.o CMakeFiles/fslview.dir/viewwidget.o CMakeFiles/fslview.dir/orthowidget.o CMakeFiles/fslview.dir/singlewidget.o CMakeFiles/fslview.dir/lightboxwidget.o CMakeFiles/fslview.dir/slicewidget.o CMakeFiles/fslview.dir/sliceview.o CMakeFiles/fslview.dir/timeserieswidget.o CMakeFiles/fslview.dir/singleserieswidget.o CMakeFiles/fslview.dir/overlaywidget.o CMakeFiles/fslview.dir/histogramwidget.o CMakeFiles/fslview.dir/clusterbrowser.o CMakeFiles/fslview.dir/histogramtoolbar.o CMakeFiles/fslview.dir/overlayinfodialog.o CMakeFiles/fslview.dir/meshoptionsdialog.o CMakeFiles/fslview.dir/atlasoptionsdialog.o CMakeFiles
Bug#562309: fslview: FTBFS: make[3]: *** No rule to make target `/usr/lib/openmpi/lib/libmpi_cxx.so', needed by `bin/fslview'. Stop.
Hi, On Thu, Dec 24, 2009 at 11:31:42AM +0100, Lucas Nussbaum wrote: Source: fslview Version: 3.1.2+4.1.4-2 Severity: serious User: debian...@lists.debian.org Usertags: qa-ftbfs-20091213 qa-ftbfs Justification: FTBFS on amd64 /build/user-fslview_3.1.2+4.1.4-2-amd64-imf6Ze/fslview-3.1.2+4.1.4/src/storage/image.h:42: warning: 'typedef' was ignored in this declaration make[3]: *** No rule to make target `/usr/lib/openmpi/lib/libmpi_cxx.so', needed by `bin/fslview'. Stop. make[2]: *** [src/fslview/CMakeFiles/fslview.dir/all] Error 2make[3]: Leaving directory `/build/user-fslview_3.1.2+4.1.4-2-amd64-imf6Ze/fslview-3.1.2+4.1.4/obj-x86_64-linux-gnu' Hmmm, fslview doesn't use openmpi. Don't know why this shows up, since the sources do not refer to any mpi-related stuff. I am somewhat inclined to blame some package that fslview build-depends on. Unfortunately, I cannot test it in a sid chroot right know, since I currently suffer from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562503 Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520701: Problems
Quick update: It seems to be a little tricky to patch Caret to work with VTK = 5.2. I reported the problem to upstream, but unfortunately they do not plan to support newer VTK releases any time soon :( I'll see what I can do, but it could take a while. Help would be very much appreciated! Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530465: Needs update for new Boost
Hi Steve, On Sun, May 24, 2009 at 08:40:48PM -0500, Steve M. Robbins wrote: Package: fslview Severity: serious Justification: no longer builds from source Due to the recently-introduced package boost-defaults [1], the unversioned Boost -dev packages changed from Boost version 1.34.1 to version 1.38.0. That is right. Upstream is aware of the issue and working on it -- the fix however is not trivial, so it might take a bit. Thanks, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520701: caret: FTBFS on 32bit archs -- incompatibility with VTK = 5.2
Note to myself: Problems on 32bit archs seem to originate in http://bugs.debian.org/521451 Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522486: caret: fails to start b/c of wrong libvtkFiltering library version
Hi, On Fri, Apr 03, 2009 at 11:02:31PM -0700, Rob Starling wrote: Package: caret Version: 5.6.1~dfsg.1-4 Severity: grave Justification: renders package unusable /usr/lib/caret/bin/caret5: error while loading shared libraries: libvtkFiltering.so.5.2: cannot open shared object file: No such file or directory Yeah, among others... Currently Caret is totally broken. There are some patches pending which are required to built it against VTK 5.2, but VTK5.2 itself is also seriously broken and hence I cannot really improve the situation now. I guess we have to be patient or fix VTK. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522484: fslview: fails to start - missing libfslio.so.1
Hi, On Fri, Apr 03, 2009 at 10:44:51PM -0700, Rob Starling wrote: Package: fslview Version: 3.0.2+4.1.0-3 Severity: grave Justification: renders package unusable Hi! fslview fails to start b/c it cannot find libfslio.so.1 -- $ fslview fslview: error while loading shared libraries: libfslio.so.1: cannot open shared object file: No such file or directory $ Right, this will be fixed with the next upload, or a transition of the current unstable version to testing. Thanks, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520906: libvtk5: SO name change, but no corresponding package name update
Package: libvtk5 Version: 5.2.1-2 Severity: serious Justification: Policy 8.1 Hi, the recent upload of VTK 5.2 bumped the SO version of the contained libs to 5.2. However, the package name does not reflect that change (stays libvtk5). For this reason rdepend package will be broken whenever VTK is updated, as the required library with SO version 5.0 are not available anymore (e.g. package fslview). IMHO, libvtk5 should become libvtk52, with the -dev package having a versioned dependency on it (see #520328) and allow to be installed alongside libvtk5. Michael -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libvtk5 depends on: ii libc6 2.7-18GNU C Library: Shared libraries ii libexpat1 2.0.1-4 XML parsing C library - runtime li ii libfreetype6 2.3.7-2 FreeType 2 font engine, shared lib ii libgcc11:4.3.2-1.1 GCC support library ii libgl1-mesa-glx [libgl 7.0.3-7 A free implementation of the OpenG ii libice62:1.0.4-1 X11 Inter-Client Exchange library ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libpng12-0 1.2.27-2 PNG library - runtime ii libsm6 2:1.0.3-2 X11 Session Management library ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3 ii libtiff4 3.8.2-11 Tag Image File Format (TIFF) libra ii libx11-6 2:1.1.5-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxft22.1.12-3 FreeType-based font drawing librar ii libxml22.6.32.dfsg-5 GNOME XML library ii libxss11:1.1.3-1 X11 Screen Saver extension library ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime libvtk5 recommends no packages. Versions of packages libvtk5 suggests: ii libvtk5-dev 5.2.1-2VTK header files for building C++ pn vtk-doc none (no description available) pn vtk-examples none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520701: caret: FTBFS on 32bit archs -- incompatibility with VTK = 5.2
Package: caret Version: 5.6.1~dfsg.1-4 Severity: serious Caret still seems to have incompatibilities with VTK = 5.2: .../caret_brain_set/libCaretBrainSet.so: undefined reference to `vtkDataArrayTemplatelong long::WritePointer(long long, long long)' .../caret_brain_set/libCaretBrainSet.so: undefined reference to `vtkCell::Initialize(int, long long*, vtkPoints*)' .../caret_files/libCaretFiles.so: undefined reference to `vtkDataArray::GetTuple3(long long)' collect2: ld returned 1 exit status It looks like this is related to a datatype issue, and maybe due to the use of int and long instead of vtkIdType. Investigating -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519270: caret - FTBFS: Conflicts against current libqt4-dev
Hi Bastian, On Wed, Mar 11, 2009 at 03:06:05PM +0100, Bastian Blank wrote: Package: caret Version: 5.6.1~dfsg.1-2 Severity: serious There was an error while trying to autobuild your package: Automatic build of caret_5.6.1~dfsg.1-2 on debian-31.osdl.marist.edu by sbuild/s390 98 [...] ** Using build dependencies supplied by package: Build-Depends: debhelper (= 5), libqt4-dev (= 4.3), libqt4-dev ( 4.4.0) | libqt4-opengl-dev, libqwt5-qt4-dev, libvtk5-dev, libminc-dev I have built caret 5.6.1~dfsg.1-2 hours ago in an up-to-date clean amd64 chroot -- with no problems at all. Moreover, I cannot see problems with the qt4 deps. We have libqt4-dev 4.4.3-2 in sid and libqt4-opengl-dev is also avialable. IMHO oppinion this is due to the broken vtk5 packages: -dev packages at version 5.2 and libraries still being 5.0, except for amd64. Or am I wrong? Thanks, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519270: caret - FTBFS: Conflicts against current libqt4-dev
On Wed, Mar 11, 2009 at 03:32:20PM +0100, Julien Cristau wrote: On Wed, 2009-03-11 at 15:22 +0100, Michael Hanke wrote: Or am I wrong? Indeed you are. Alternatives in build-dependencies aren't considered by sbuild, so you're effectively build-depending on a version of libqt4-dev that's no longer available. Ahh! Thanks for pointing that out -- will fix it. Thanks, Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
