Bug#1055649: linux: Microphone does not work on ThinPad P14s AMD (Zen4/Phoenix), fixed by enabling 2 SOC DSP modules
Package: linux
Version: 6.5.3-1~bpo12+1
Severity: normal
Tags: patch
The amd64 debian kernels miss the driver for Zen4 ("Phoenix", "Pink
Sardine") Audio Coprocessor/DSP.
So affects microphone support in recent laptops such as the ThinkPad P14s
Gen4 AMD.
Simple fix:
--- .config.old 2023-11-08 18:59:51.375718658 +0100
+++ .config 2023-11-08 19:08:38.271156846 +0100
@@ -6812,7 +6812,8 @@
CONFIG_SND_AMD_ACP_CONFIG=m
# CONFIG_SND_SOC_AMD_ACP_COMMON is not set
# CONFIG_SND_SOC_AMD_RPL_ACP6x is not set
-# CONFIG_SND_SOC_AMD_PS is not set
+CONFIG_SND_SOC_AMD_PS=m
+CONFIG_SND_SOC_AMD_PS_MACH=m
# CONFIG_SND_ATMEL_SOC is not set
# CONFIG_SND_BCM63XX_I2S_WHISTLER is not set
# CONFIG_SND_DESIGNWARE_I2S is not set
-- System Information:
Debian Release: 11.8
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500,
'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-0.deb11.11-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
c u
henning
Bug#946389: opensm: calls non-existing 'rm_conffile' in debian/preinst
Package: opensm Version: 3.3.20-1 Severity: normal When installing opensm on debian stretch, I get: root@mpsd-ib-node:~# apt-get install opensm Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: postfix-sqlite ssl-cert Use 'apt autoremove' to remove them. The following NEW packages will be installed: opensm 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 571 kB of archives. After this operation, 1,314 kB of additional disk space will be used. Get:1 http://mpsdfai.desy.de/debian stretch/main amd64 opensm amd64 3.3.20-1 [571 kB] Fetched 571 kB in 0s (36.9 MB/s) Selecting previously unselected package opensm. (Reading database ... 81595 files and directories currently installed.) Preparing to unpack .../opensm_3.3.20-1_amd64.deb ... /var/lib/dpkg/tmp.ci/preinst: 7: /var/lib/dpkg/tmp.ci/preinst: rm_conffile: not found Unpacking opensm (3.3.20-1) ... Setting up opensm (3.3.20-1) ... Processing triggers for systemd (232-25+deb9u12) ... Processing triggers for man-db (2.7.6.1-2) ... So the 'debian/preinst' calls 'rm_conffile', which does not exist. I think the package should use 'dpkg-maintscript-helper rm_conffile' instead. And looking at the debian buster version of the debian/preinst, the same issue persists also there. -- System Information: Debian Release: 9.11 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-11-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages opensm depends on: pn infiniband-diags ii libc6 2.24-11+deb9u4 pn libibumad3 pn libopensm5a pn libosmcomp3 pn libosmvendor4 ii libwrap0 7.6.q-26 opensm recommends no packages. opensm suggests no packages. -- c u henning
Bug#805824: Team maintenance in Debian Science for pdl? (Was: pdl: Fails to build with GSL 2)
On Tue, Jan 12, 2016 at 08:27:44AM +0100, Andreas Tille wrote: > since it would be great to fix #805824 soon which seems pretty easy > considering the patch I would like to offer an NMU. However, it would > be even more sensible to move the package under Debian Science team > maintenance and maintain it in Debian Science Git since it is part of > several Debian Science tasks (astronomy, numericalcomputation and > viewing). If I do not hear anything from you until end of this week > I would go on to move pdl in Debian Science Git, add you as Uploader > and do a team upload (rather than an NMU). > > What do you think? I'm fine with putting PDL under science-team-maintianance. Go forward and I'll join the team ASAP. -- c u henning
Bug#784160: transition: proj
On Fri, May 08, 2015 at 03:21:33PM +0200, Sebastiaan Couwenberg wrote: On 05/08/2015 02:56 PM, Henning Glawe wrote: t/proj_transform.t .. skipped: PDL::Transform::Proj4 module not compiled. t/proj_transform2.t . skipped: PDL::Transform::Proj4 module not compiled. E: Caught signal ‘Terminated’: terminating immediately make[1]: *** [test_dynamic] Terminated I opened a PDL bug report [1] for this issue and will look into it as soon as I start working on a released 2.008 From what I understand of the upstream discussion the library ordering changes fix the projection initialization issue that currently disables the Proj support in PDL. Skipping the tests on i386 may be sufficient for a successful build, that would at least allow the proj transition to continue. Proj support in PDL can be restored in the new upstream release. Just found out why the build was killed on i386: Build killed with signal TERM after 150 minutes of inactivity this happend after 160 minutes, while a typical build of PDL on i386 should take about 10 minutes... the really interesting question is why the build hangs somewhere for 150minutes; on all other platforms, the test suite directly continues with t/pthread.t -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784160: transition: proj
On Fri, May 08, 2015 at 01:47:28PM +0200, Sebastiaan Couwenberg wrote: That got accepted. The current blockers are the cdo/ppc64el build failure (#763691) and the pdl/i386 one. For PDL some patches from the upcoming release are required, see the discussion on their list [1] and Proj commits in their git repository [2]. There are several Proj related commits, so it may make more sense to update to PDL-2.007_17. Henning, what do you think? PDL-2.007_17 is a release candidate for the upcoming PDL-2.008, so I suggest we wait up to the official release of 2.008. BTW: In your build logs, PDL proj bindings are actually not built on any architecture, search the logs for PROJ4 library found but cannot initialize projection The error you observe on i386 is an independent problem, the package build is interrupted by a SIGTERM; where did that one come from? excessive resource usage on the buildd? t/proj_transform.t .. skipped: PDL::Transform::Proj4 module not compiled. t/proj_transform2.t . skipped: PDL::Transform::Proj4 module not compiled. E: Caught signal ‘Terminated’: terminating immediately make[1]: *** [test_dynamic] Terminated I opened a PDL bug report [1] for this issue and will look into it as soon as I start working on a released 2.008 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784748 -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784748: pdl: PROJ4 bindings are not built when building against new libproj
Package: pdl Version: 1:2.007-4+b1 Severity: normal Tags: upstream In the 1:2.007-4+b1 build logs, PDL proj bindings are actually not built on any architecture, search the logs for PROJ4 library found but cannot initialize projection PDL-2.007_17 is a release candidate for the upcoming PDL-2.008, so I suggest we wait up to the official release of 2.008. The error you observe on i386 is an independent problem, the package build is interrupted by a SIGTERM; where did that one come from? excessive resource usage on the buildd? t/proj_transform.t .. skipped: PDL::Transform::Proj4 module not compiled. t/proj_transform2.t . skipped: PDL::Transform::Proj4 module not compiled. E: Caught signal ‘Terminated’: terminating immediately make[1]: *** [test_dynamic] Terminated -- System Information: Debian Release: 7.8 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773323: perl: Wheezy-Jessie upgrade breaks wheezy pdl
On Fri, Dec 19, 2014 at 11:19:17AM +0200, Niko Tyni wrote: all the earlier ones, right? Also, AIUI the actual source change that fixes the breakage going forward is in 1:2.007-4 so it seems using that would be the most robust (think downstream distributions that might be upgrading their perl versions in a different schedule.) So is ( 1:2.007-4) OK with you? Agreed. - which perl packages need this? The minimal recipe I could come up for this is # wheezy base chroot apt-get install libpdl-stats-perl dpkg --unpack perl-modules_5.20.1-3_all.deb # from jessie dpkg --remove libpdl-stats-perl or, alternatively, # wheezy base chroot apt-get install libpdl-stats-perl dpkg -i libc6_2.19-13_amd64.deb dpkg --unpack perl-base_5.20.1-3_amd64.deb dpkg --remove libpdl-stats-perl Interestingly, unpacking the new 'perl' package alone doesn't trigger the failure. the 'guilty' dpkg-trigger is called whenever files are changed within /usr/lib/perl5/PDL, which happens on installation/update/removal of optional PDL submodules (in the reports, it was either hdf5 or stats). The trigger itself relies on having the pdl main distribution modules accessible from /usr/bin/perl (which is not the case if /usr/bin/perl has been replaced by 5.20 packages, while installed pdl modules are only in the searchpath of 5.14. So it looks like we need the Breaks in both perl-base and perl-modules. That would be a safe choice, yes. - is Breaks sufficient, or do we need Conflicts? Dependency guarantees around 'postinst triggered' are not quite clear to me. I assume 'postinst triggered' will not be called before the package is configured, in which case I expect Breaks should be enough (as it will guarantee that the old pdl package gets deconfigured, and the new pdl package won't be configured before its dependencies are installed.) My knowledge of triggers is also rather limited... while writing the offending code, I assumed that the same rules would apply for triggers as for postinst configure, i.e. they could be only called if all dependencies are fulfilled (and configured). Will test this, but any advice is appreciated. I hope to be able to upload a fix this weekend, assuming the version number thing above is confirmed one way or another. thanks a lot, this one really costed me some nerves... -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729220: pdl: problems upgrading from wheezy due to triggers
Control: clone 729220 -1 Control: reassign -1 perl Control: retitle -1 perl: Wheezy-Jessie upgrade breaks wheezy pdl There is a problem in wheezy's version of pdl, showing during the wheezy - jessie update. Could you please add a 'Breaks: pdl (1:2.007)' to jessies perl packages ? background: the pdl package installs a dpkg-trigger to update the online documentation index whenever new pdl addon-modules are installed the trigger may fail during the wheezy-jessie dist-upgrade, whenever perl is update before pdl, stopping the whole upgrade process. the reason for this is that wheezy-pdl's trigger assumes correctly installed PDL modules for the present /usr/bin/perl, and that a trigger could only be called when this condition is fullfilled. original bug number was #729220 -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729220: pdl: problems upgrading from wheezy due to triggers
On Mon, Dec 15, 2014 at 08:50:07PM +0100, gregor herrmann wrote: On Mon, 15 Dec 2014 01:11:05 +0100, Andreas Beckmann wrote: raising the severity again since this is still occurring in the altree package. As it looks, altree removed the dependency on libpdl-stats-perl. Ack (on the latter). actually, libpdl-stats-perl seems not to have been rebuilt for jessie's PDL version... Maybe the proper fix is in altree (or even perl?) to add a versioned Breaks against the problematic pdl versions. This sounds reasonable (mire the altree than the perl option, IMO), but before I could play around with it ... The real problem seems to be my assumption that triggers get only called when all dependencies have been fulfilled... wheezy's pdl packages' triggers (in pdl.postinst) call perl scripts, which in turn use pdl modules. during the dist-upgrade, perl has been updated to jessie's version, while pdl is still at wheezy. perl API and module paths have been changed between wheezy and jessie, so the perl/pdl scripts used in pdl's triggers (used for updating documentation indices) fail, as they depend on the availability of PDL matching the presently installed perl. From the attached log: Preparing to replace perl 5.14.2-21+deb7u2 (using .../perl_5.20.1-3_amd64.deb) ... Unpacking replacement perl ... Preparing to replace altree 1.2.1-1 (using .../altree_1.3.1-2+b1_amd64.deb) ... Unpacking replacement altree ... (Reading database ... 9728 files and directories currently installed.) Removing libpdl-stats-perl ... Processing triggers for pdl ... dpkg: error processing pdl (--remove): subprocess installed post-installation script returned error exit status 2 Errors were encountered while processing: pdl The pdl package has not been touched, yet, so it is still the old one from wheezy. ... I couldn't reproduce the bug (in 3 tries), rebuilding your scenario manually (i.e.: wheezy chroot, install altree, dist-upgrade). libpdl-stats-perl gets removed for me, Processing triggers for pdl never shows up. Excerpts from the dist-upgrade (full log attached): I could reproduce the issues (via pbuilder/cowbuilder chroot): - build wheezy chroot (having the default pbuilder deps, i.e. build-essential installed) - install altree (which pulls in pdl) - replace wheezy by jessie in /etc/apt/sources.list two upgrade paths run into different errors: 1. 'apt-get dist-upgrade' runs into the above mentioned error 2.a 'apt-get install dpkg apt' (works fine) 2.b 'apt-get dist-upgrade' fails with an apparently unrelated dpkg-trigger related issue: (Reading database ... 15387 files and directories currently installed.) Preparing to unpack .../libaudit1_1%3a2.4-1+b1_amd64.deb ... Unpacking libaudit1:amd64 (1:2.4-1+b1) ... dpkg: cycle found while processing triggers: chain of packages whose triggers are or may be responsible: man-db - man-db packages' pending triggers which are or may be unresolvable: man-db: /usr/share/man dpkg: error processing package man-db (--configure): triggers looping, abandoned Setting up libaudit1:amd64 (1:2.4-1+b1) ... Errors were encountered while processing: man-db E: Sub-process /usr/bin/dpkg returned an error code (1) Preparing to replace pdl 1:2.4.11-4 (using .../pdl_1%3a2.007-3_amd64.deb) ... Unpacking replacement pdl ... Preparing to replace perl 5.14.2-21+deb7u2 (using .../perl_5.20.1-3_amd64.deb) ... Unpacking replacement perl ... Removing libpdl-stats-perl ... Preparing to replace perl-base 5.14.2-21+deb7u2 (using .../perl-base_5.20.1-3_amd64.deb) ... Unpacking replacement perl-base ... Setting up perl-base (5.20.1-3) ... Preparing to replace perl-modules 5.14.2-21+deb7u2 (using .../perl-modules_5.20.1-3_all.deb) ... Unpacking replacement perl-modules ... [..] Setting up perl-modules (5.20.1-3) ... Setting up perl (5.20.1-3) ... [..] Setting up pdl (1:2.007-3) ... So for whatever reason, the order is different for me ... No idea what this tells us. I think it tells us that my assumption (made already in wheezy), that a trigger gets only called when PDL is usable with the presently installed perl was wrong. some facts: - wheezy-pdl depends on perlapi-5.14.2 - nevertheless pdl's documentation-update trigger gets called, while perl has been already been replaced by the jessie version: (Reading database ... 15234 files and directories currently installed.) [...] Unpacking replacement perl-modules ... Selecting previously unselected package libdb5.3:amd64. Unpacking libdb5.3:amd64 (from .../libdb5.3_5.3.28-6_amd64.deb) ... Processing triggers for man-db ... Setting up libdb5.3:amd64 (5.3.28-6) ... Processing triggers for libc-bin ... (Reading database ... 15361 files and directories currently installed.) Preparing to replace perl 5.14.2-21+deb7u2 (using
Bug#729220: pdl: problems upgrading from wheezy due to triggers
On Mon, Dec 15, 2014 at 09:58:41PM +0100, gregor herrmann wrote: On Mon, 15 Dec 2014 21:39:26 +0100, Henning Glawe wrote: actually, libpdl-stats-perl seems not to have been rebuilt for jessie's PDL version... Oh :/ Also an interesting detail. well, due to PhD-thesis related distractions I was quite late to upload new PDL versions for jessie, so blame it on me :( during the dist-upgrade, perl has been updated to jessie's version, while pdl is still at wheezy. Interestingly this happens for both Andreas and you but not for me. lucky you ;) I hate bugs which are not easily reproducible... perl API and module paths have been changed between wheezy and jessie, so the perl/pdl scripts used in pdl's triggers (used for updating documentation indices) fail, as they depend on the availability of PDL matching the presently installed perl. I also thought about interest vs. interest-noawait but this probably doesn't help if the wheezy postinst/triggers gets called :/ pdl (both wheezy and jessie) declares in 'pdl.triggers': interest /usr/lib/perl5/PDL ... I couldn't reproduce the bug (in 3 tries), rebuilding your scenario manually (i.e.: wheezy chroot, install altree, dist-upgrade). libpdl-stats-perl gets removed for me, Processing triggers for pdl never shows up. Excerpts from the dist-upgrade (full log attached): I could reproduce the issues (via pbuilder/cowbuilder chroot): - build wheezy chroot (having the default pbuilder deps, i.e. build-essential installed) - install altree (which pulls in pdl) - replace wheezy by jessie in /etc/apt/sources.list two upgrade paths run into different errors: 1. 'apt-get dist-upgrade' runs into the above mentioned error That's exactly what I did as well. (With an apt-get update before the dist-upgrade but I assume you ran this too.) yup. otherwise apt, of course, would not know about any updated packages... 2.a 'apt-get install dpkg apt' (works fine) 2.b 'apt-get dist-upgrade' fails with an apparently unrelated dpkg-trigger related issue: (Reading database ... 15387 files and directories currently installed.) Preparing to unpack .../libaudit1_1%3a2.4-1+b1_amd64.deb ... Unpacking libaudit1:amd64 (1:2.4-1+b1) ... dpkg: cycle found while processing triggers: chain of packages whose triggers are or may be responsible: man-db - man-db packages' pending triggers which are or may be unresolvable: man-db: /usr/share/man dpkg: error processing package man-db (--configure): triggers looping, abandoned Setting up libaudit1:amd64 (1:2.4-1+b1) ... Errors were encountered while processing: man-db E: Sub-process /usr/bin/dpkg returned an error code (1) Hm, is this still not fixed? Anyway, different problem. the more I look at it, the more f0rked up the present triggers implementation (or my very limited knowledge of it) seems to me... at least there should be at least one straight-forward mechanism to override bad decisions made in (old-)stable regarding maintainer-scripts So for whatever reason, the order is different for me ... No idea what this tells us. I think it tells us that my assumption (made already in wheezy), that a trigger gets only called when PDL is usable with the presently installed perl was wrong. some facts: - wheezy-pdl depends on perlapi-5.14.2 - nevertheless pdl's documentation-update trigger gets called, while perl has been already been replaced by the jessie version: Ack. The question is how to get pdl to be updated earlier, I guess. or in a more general sense provide do not care about failure during dist-upgrade info to apt-get If I could reproduce the problem, I'd probably try Andreas' suggestion to add a versioned Breaks against older pdl versions to altree. although it may sound more invasive, I think that also altree is not to 'blame' for this problem... so the breaks should go to the perl packages... -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763199: ITP: libpdl-fftw-perl -- PDL::FFTW - PDL interface to the Fastest Fourier Transform in the West v2.x
Package: wnpp
Severity: wishlist
Owner: Henning Glawe gla...@debian.org
* Package name: libpdl-fftw-perl
Version : 2.022
Upstream Author : Chris Marshall c...@cpan.org
* URL : http://search.cpan.org/dist/PDL-FFTW/
* License : GPL, Artistic, available at *
/usr/share/common-licenses/{GPL,Artistic}
Programming Lang: C, Perl, PDL
Description : PDL::FFTW - PDL interface to the Fastest Fourier Transform
in the West v2.x
This is a means to interface PDL with the FFTW library. It's similar to the
standard FFT
routine but it's usually faster and has support for real transforms. It
works well for
the types of PDLs for which was the library was compiled (otherwise it
must do conversions).
.
Formerly, this was part of the main PDL distribution, but has been split
off in recent releases.
--
c u
henning
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763203: ITP: libpdl-graphics-plplot-perl -- PDL::Graphics::PLplot - Object-oriented interface from perl/PDL to the PLPLOT plotting library
Package: wnpp
Severity: wishlist
Owner: Henning Glawe gla...@debian.org
* Package name: libpdl-graphics-plplot-perl
Version : 0.67
Upstream Author : Doug Hunt dh...@ucar.edu
* URL : http://search.cpan.org/dist/PDL-Graphics-PLplot/
* License : GPL, Artistic, available at
/usr/share/common-licenses/{GPL,Artistic}
Programming Lang: C, Perl, PDL
Description : PDL::Graphics::PLplot - Object-oriented interface from
perl/PDL to the PLPLOT plotting library
This is the PDL interface to the PLplot graphics library. It provides
a familiar 'perlish' Object Oriented interface as well as access to
the low-level PLplot commands from the C-API.
.
Formerly, this was part of the main PDL distribution, but has been split off
in recent releases.
--
c u
henning
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752351: pdl: hardcodes /usr/lib/perl5
On Sun, Jun 22, 2014 at 11:14:44PM +0300, Niko Tyni wrote:
Source: pdl
Version: 1:2.007-2
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.20-transition
Starting with version 5.20.0 (currently in experimental), the Debian
perl package is changing the vendorarch library path (currently
/usr/lib/perl5) to include the multiarch triplet and the perl version. See
#748380 for details.
For this to work, packages containing binary perl modules need to migrate
from using the hardcoded /usr/lib/perl5 directory to the value of the
$Config{vendorarch} variable, as defined in the 'Config' module.
This package builds successfully with perl_5.20.0-1 from experimental,
but still installs the Perl files into /usr/lib/perl5 so they won't be
on the Perl search path anymore.
Please ask on the debian-perl list if you want help with this.
drwxr-xr-x root/root 0 2014-06-17 14:19 ./usr/lib/perl5/
drwxr-xr-x root/root 0 2014-06-17 14:19 ./usr/lib/perl5/PDL/
drwxr-xr-x root/root 0 2014-06-17 14:19 ./usr/lib/perl5/PDL/Doc/
-rw-r--r-- root/root 8640 2013-05-12 23:09
./usr/lib/perl5/PDL/Doc/mkhtmldoc.pl
-rw-r--r-- root/root 2770 2014-06-17 14:11
./usr/lib/perl5/PDL/Doc/scantree.pl
THX, will fix it in the next upload.
p.s.:
These scripts are only used during the autogeneration of docs and doc
indices, AFAIR my maintainer scripts install and use them via triggers,
so it should not affect the functionality of the package
--
Mit freundlichen Grüßen
Henning Glawe
Max-Planck-Institut für Mikrostrukturphysik
Weinberg 2, 06120 Halle (Saale), Germany http://www.mpi-halle.de/~theory
Phone: +49-345-5582-613 Fax: +49-345-5511223 Email: gl...@mpi-halle.de
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752351: pdl: hardcodes /usr/lib/perl5
On Tue, Jun 24, 2014 at 06:30:38PM +0300, Niko Tyni wrote: p.s.: These scripts are only used during the autogeneration of docs and doc indices, AFAIR my maintainer scripts install and use them via triggers, so it should not affect the functionality of the package OK. There's also lrwxrwxrwx root/root 0 2014-06-17 14:19 ./usr/lib/perl5/PDL/Index.pod - /var/lib/pdl/Index.pod lrwxrwxrwx root/root 0 2014-06-17 14:19 ./usr/lib/perl5/PDL/pdldoc.db - /var/lib/pdl/pdldoc.db I stand corrected. There is actually a problem in PDL: I generate all the documentation (essentially, PODs generated from the installed modules) at installation time in /var/lib. pdldoc and the interactive shells 'pdl' and 'pdl2' expect finding docs via the files symlinked away by my package, this issue may be a major problem to the users. Did you, by any means, check the documentation system after the perl update? I suspect that (on the command line), 'pdldoc -a slice' would give you an empty list... and it looks like those break libpdl-stats-perl_0.6.5-1 because its add_doc.pl looks for pdldoc.db on @INC: Updating PDL documentation database ... Unable to find docs database! Not updating docs database. make[1]: *** [install] Error 2 Makefile:971: recipe for target 'install' failed make[1]: Leaving directory '/«PKGBUILDDIR»' my PDL package has a trigger installed for doc/doc-index rebuild if any package installs sth into its namespace, so no explicite action on the side of a dependee pkg should be necessary. I suspect that, besides PDL being possibly broken by the transition, the dependee libpdl-stats-perl is doing something explicitely that it shouldn't... -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752351: pdl: hardcodes /usr/lib/perl5
On Tue, Jun 24, 2014 at 10:41:00PM +0300, Niko Tyni wrote: Did you, by any means, check the documentation system after the perl update? I suspect that (on the command line), 'pdldoc -a slice' would give you an empty list... It seems to be worse than that: # pdldoc -a slice Unable to find PDL/pdldoc.db in /etc/perl:/usr/local/lib/x86_64-linux-gnu/perl/5.20.0:/usr/local/share/perl/5.20.0:/usr/lib/x86_64-linux-gnu/perl5/5.20:/usr/share/perl5:/usr/lib/x86_64-linux-gnu/perl/5.20:/usr/share/perl/5.20:/usr/local/lib/site_perl:. can't open database 1, scan docs first at /usr/lib/x86_64-linux-gnu/perl5/5.20/PDL/Doc.pm line 465. PDL::Doc::ensuredb(PDL::Doc=HASH(0x2836698)) called at /usr/lib/x86_64-linux-gnu/perl5/5.20/PDL/Doc.pm line 583 PDL::Doc::search(PDL::Doc=HASH(0x2836698), m/slice/, ARRAY(0x2009968), 1) called at /usr/lib/x86_64-linux-gnu/perl5/5.20/PDL/Doc/Perldl.pm line 188 PDL::Doc::Perldl::search_docs(m/slice/, ARRAY(0x2009968), 1) called at /usr/lib/x86_64-linux-gnu/perl5/5.20/PDL/Doc/Perldl.pm line 165 PDL::Doc::Perldl::aproposover(slice) called at /usr/lib/x86_64-linux-gnu/perl5/5.20/PDL/Doc/Perldl.pm line 173 PDL::Doc::Perldl::apropos(slice) called at /usr/bin/pdldoc line 57 essentially, it is not far worse than expected. It just implies that the whole PDL documentation is lost to the user. oh well... have to fix that one. my PDL package has a trigger installed for doc/doc-index rebuild if any package installs sth into its namespace, so no explicite action on the side of a dependee pkg should be necessary. I suspect that, besides PDL being possibly broken by the transition, the dependee libpdl-stats-perl is doing something explicitely that it shouldn't... The PDL-Stats upstream Makefile.PL has this postamble: install :: @echo Updating PDL documentation database ... @$(PERL) add_doc.pl and add_doc.pl uses PDL::Doc methods to update the doc database it finds on @INC. So should the libpdl-stats-perl Debian package be disabling that and relying on the trigger instead? I definitely think so: why should any package at build time do something that is related to the system that it may be installed into... Background: pdl, as perl's equivalent to numpy/scipy/matlab, comes with an integrated documentation system, allowing to search for documentation of all the installed packages related to it. the documentation index, searched by tools like pdldoc or the interactive shells, should always be consistent with what is actually installed on a system. -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735623: Any Progress about This bug?
On Thu, Jun 12, 2014 at 07:33:43PM +0800, xuhaida wrote: Hi: I'm playing pdl,but can't find this package in testing distribution .After this post ,I know the reason but don't see any progress about it . Is there any progress about this bug? Upstream is still working on this one; I don't have time to personally dig into it, as the original problem is deep inside PDL's core, and I have to finish writing up my PhD thesis :( Will join the effort as soon as I'm done ;) -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735623: pdl: FTBFS on mips, powerpc, s390x, sparc, (ia64): testsuite failures
On Fri, Jan 17, 2014 at 03:30:49AM +0100, Andreas Beckmann wrote: pdl FTBFS with testsuite failures on several architectures These testsuite failures were actually there before, but I only now made a successful testsuite run _mandatory_ in the build process... (are they all big-endian architectures?): powerpc, mips, s390x, sparc are indeed big-endian. debian's ia64 port AFAIK uses little-endian mode. Besides the potential endianness issues, there is a bug hidden in the depths of PDL. To summarize [1]: In a couple of locations within the core, there is an assumption that double is the largest datatype and some return values are casted/converted to double. long long int is indeed longer than the mantissa of a double, so when the conversion happens and the value of the longlong is large, the least significant bits are lost. The address space layout on ia64 leads to large pointer addresses, leading to segfaults during the test suite run. In some sense, it is just by luck that the same does not happen to pointers on other 64bit architectures. And, as PDL is a language used in the context of numerical computation (think of it like MatLab/NumPy for perl), this implicit precision loss may also affect real calculations performed with it. [1] http://thread.gmane.org/gmane.comp.lang.perl.pdl.devel/5637/focus=5641 -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729372: libextutils-f77-perl: fails to work on kfreebsd* architectures
Package: libextutils-f77-perl Version: 1.17-1 Severity: normal Tags: upstream Moin, I discovered during the autobuild of pdl some testsuite failures caused by ExtUtils::F77. Seems like it cannot setup the compiler options on kfreebsd*, as it is confused by the the system name Gnukfreebsd. Error message: (sid_kfreebsd-i386-dchroot)glaweh@fischer:~/pdl-2.007$ perl -Mblib t/flexraw_fortran.t ExtUtils::F77: Version 1.17 Loaded ExtUtils::F77 version 1.17 Found compiler gfortran ExtUtils::F77: Using system=Gnukfreebsd compiler=undefined ExtUtils::F77: Unable to guess and/or validate system/compiler configuration ExtUtils::F77: Will try system=Generic Compiler=G77 ExtUtils::F77: Well that didn't appear to validate. Well I will try it anyway. ExtUtils::F77: There does not appear to be any configuration info about ExtUtils::F77: names with trailing underscores for system Generic. Will assume ExtUtils::F77: F77 names have trailing underscores. ExtUtils::F77: There does not appear to be any configuration info about ExtUtils::F77: the F77 compiler name. Will assume 'f77'. ExtUtils::F77: Compiler: f77 ExtUtils::F77: There does not appear to be any configuration info about ExtUtils::F77: the options for the F77 compiler. Will assume none ExtUtils::F77: necessary. ExtUtils::F77: Cflags: 1..29 ERROR: code did not create data file /tmp/rawJ599_data # Looks like your test exited with 2 before it could output anything. -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libextutils-f77-perl depends on: ii perl 5.14.2-21+deb7u1 libextutils-f77-perl recommends no packages. libextutils-f77-perl suggests no packages. -- no debconf information -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729220: pdl: problems upgrading from wheezy due to triggers
On Sun, Nov 10, 2013 at 02:23:49PM +0100, Andreas Beckmann wrote: Preparing to replace libpdl-io-hdf5-perl 0.63-3 (using .../libpdl-io-hdf5-perl_0.63-3+b1_amd64.deb) ... Unpacking replacement libpdl-io-hdf5-perl ... This binary-NMU seems to be broken: the dependency-field is empty, but should depend on the particular pdlapi virtual package. When looking at http://packages.debian.org/unstable/libpdl-io-hdf5-perl , the binary-nmu'd package is empty (except for the documentation) for all architectures. I will look into this as soon as the new PDL package works correctly on all architectures. Preparing to replace perl-base 5.14.2-21+deb7u1 (using .../perl-base_5.18.1-4_amd64.deb) ... Unpacking replacement perl-base ... Processing triggers for pdl ... dpkg: error processing pdl (--unpack): subprocess installed post-installation script returned error exit status 2 Errors were encountered while processing: pdl At this point the old pdl (built against perl 5.14) is still installed, but is no longer runnable, so the trigger fails. This could be a known dpkg problem (running a trigger for a package that is not properly configured), but this needs to be worked around as the dpkg in wheezy is not going to be fixed. Maybe adding libpdl-io-hdf5-perl: Breaks: pdl ( 1:2.007) helps (as long as this version does not go into backports at some point) problem is unrelated to libpdl-io-hdf5-perl, as the binNMU'd package is empty and has apparently empty dependencies. In your log, it seems like perl-base is not configured while pdl is updated. perl-base is Essential: yes, so this seems a bit strange to me. Will play around with upgrades as soon as possible... -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701335: pdl: ftbfs with GCC-4.8
On Tue, Feb 26, 2013 at 05:17:08PM +0100, Matthias Klose wrote:
this works when setting CFLAGS to -O0:
include /usr/share/dpkg/buildflags.mk
CFLAGS := $(subst -O2,-O0,$(CFLAGS))
export CFLAGS
-Og works too for GCC 4.8.
I will look into this as soon as I have a bit of spare time and a gcc-4.8
setup ready.
but given all the ignored warnings, this rather smells like buggy code.
Most of PDL's C code is autogenerated, resulting into (superfluous) declartions
of then unused variables, which lead to most of the warnings in the build
process.
maybe not related, but pdl.PL looks wrong too ...
yep, this is clearly an out-of-bounds access. Thanks for reporting :)
the 'pdl' wrapper itself is not widely used; basically, it is just there so a
user can directly use 'pdl' as an interpreter for a script. Most people I
know use /usr/bin/perl and load PDL via 'use' into perl, leading to this
issue not having come up in the past.
main(int argc, char **argv) {
char perldl[BUFSIZ];
int pipes[2];
[...]
if(pid==0) {
dup2(pipes[1],1);
dup2(pipes[2],2);
--
c u
henning
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629195: libopengl-perl: Please package new upstream version 0.64
Package: libopengl-perl Version: 0.62+dfsg-1 Severity: normal Tags: upstream I am currently updating PDL to its newest upstream version, which in turn requires a libopengl-perl (=0.63). -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libopengl-perl depends on: ii freeglut3 2.6.0-1OpenGL Utility Toolkit ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libgl1-mesa-glx [libgl1] 7.7.1-4A free implementation of the OpenG ii libglu1-mesa [libglu1]7.7.1-4The OpenGL utility library (GLU) ii libice6 2:1.0.6-2 X11 Inter-Client Exchange library ii libx11-6 2:1.3.3-4 X11 client-side library ii libxext6 2:1.1.2-1 X11 miscellaneous extension librar ii libxi62:1.3-6X11 Input extension library ii libxmu6 2:1.0.5-2 X11 miscellaneous utility library ii perl 5.10.1-17 Larry Wall's Practical Extraction ii perl-base [perlapi-5.10.1]5.10.1-17 minimal Perl system libopengl-perl recommends no packages. libopengl-perl suggests no packages. -- no debconf information -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594336: unblock: pdl/1:2.4.7+dfsg-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package pdl The new upstream release 2.4.7 brings: - strongly improved documentation - a lot of bugfixes related to bugs tracked in upstreams BTSs (cpan and sf.net), but not present in Debian's BTS - a new interactive shell (optional), which allows proper scoping (my/our) of variables and works also in perl strict mode. - a much more reliable test suite On the debian packaging side: - testsuite results are a lot easier to extract from the buildd logs now unblock pdl/1:2.4.7+dfsg-2 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587504: paraview: On-Line help broken
Package: paraview Version: 3.6.2-4+b1 Severity: normal Moin, selecting 'Help:Help' in the menu makes a messagebox show up: 'Couldn't find pqClient.adp. Try setting the PARAVIEW_HELP environment variable which points to that file' dlocate shows that this file can be found in /usr/share/doc/paraview/ starting paraview with PARAVIEW_HELP in env from a terminal and selecting the help option yields: gl...@ford:~ export PARAVIEW_HELP=/usr/share/doc/paraview/pqClient.adp gl...@ford:~ paraview QFileInfo::absolutePath: Constructed with empty filename Unknown option: -server Usage: assistant [Options] -collectionFile file Uses the specified collection file instead of the default one -showUrl url Shows the document with the url. -enableRemoteControl Enables Assistant to be remotely controlled. -show widget Shows the specified dockwidget which can be contents, index, bookmarks or search. -activate widget Activates the specified dockwidget which can be contents, index, bookmarks or search. -hide widget Hides the specified dockwidget which can be contents, index bookmarks or search. -register helpFile Registers the specified help file (.qch) in the given collection file. -unregister helpFile Unregisters the specified help file (.qch) from the give collection file. -setCurrentFilter filter Set the filter as the active filter. -remove-search-index Removes the full text search index. -quiet Does not display any error or status message. -help Displays this help. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages paraview depends on: ii libavcodec52 5:0.6~svn20100603-0.0 library to encode decode multimedi ii libavformat52 5:0.6~svn20100603-0.0 ffmpeg file format library ii libavutil494:0.5.2-1 ffmpeg utility library ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libexpat1 2.0.1-7 XML parsing C library - runtime li ii libfreetype6 2.3.11-1 FreeType 2 font engine, shared lib ii libgcc11:4.4.4-6 GCC support library ii libgl1-mesa-glx [l 7.7.1-3 A free implementation of the OpenG ii libglu1-mesa [libg 7.7.1-3 The OpenGL utility library (GLU) ii libhdf5-serial-1.8 1.8.4-patch1-2Hierarchical Data Format 5 (HDF5) ii libice62:1.0.6-1 X11 Inter-Client Exchange library ii libjpeg62 6b-16.1 The Independent JPEG Group's JPEG ii libopenmpi1.3 1.4.1-3 high performance message passing l ii libpng12-0 1.2.44-1 PNG library - runtime ii libpython2.6 2.6.5+20100626-1 Shared Python runtime library (ver ii libqt4-assistant 4:4.6.3-1 Qt 4 assistant module ii libqt4-network 4:4.6.3-1 Qt 4 network module ii libqt4-sql 4:4.6.3-1 Qt 4 SQL module ii libqt4-xml 4:4.6.3-1 Qt 4 XML module ii libqtcore4 4:4.6.3-1 Qt 4 core module ii libqtgui4 4:4.6.3-1 Qt 4 GUI module ii libsm6 2:1.1.1-1 X11 Session Management library ii libstdc++6 4.4.4-6 The GNU Standard C++ Library v3 ii libswscale05:0.6~svn20100603-0.0 ffmpeg video scaling library ii libtiff4 3.9.4-1 Tag Image File Format (TIFF) libra ii libx11-6 2:1.3.3-3 X11 client-side library ii libxext6 2:1.1.1-3 X11 miscellaneous extension librar ii libxml22.7.7.dfsg-3 GNOME XML library ii libxt6 1:1.0.7-1 X11 toolkit intrinsics library ii python 2.6.5-5 An interactive high-level object-o ii python-support 1.0.9 automated rebuilding support for P ii qt4-dev-tools 4:4.6.3-1 Qt 4 development tools ii tcl8.4 [tclsh] 8.4.19-4 Tcl (the Tool Command Language) v8 ii tcl8.5 [tclsh] 8.5.8-2 Tcl (the Tool Command Language) v8 ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages paraview recommends: ii mpi-default-bin 0.6Standard MPI runtime programs ii qt4-dev-tools 4:4.6.3-1 Qt 4 development tools Versions of packages paraview suggests: pn h5utils none (no description available) pn hdf5-toolsnone (no description available) -- no debconf information -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580696: ITP: libpdl-io-hdf5-perl -- PDL Interface to the HDF5 Data Format
Package: wnpp Severity: wishlist Owner: Henning Glawe gla...@debian.org Owner: Henning Glawe gla...@debian.org * Package name: libpdl-io-hdf5-perl Version : 0.6 Upstream Author : John Cerney j-cern...@raytheon.com * URL : http://cpansearch.perl.org/src/CERNEY/PDL-IO-HDF5-0.6/ * License : same as Perl Programming Lang: Perl, PDL Description : PDL Interface to the HDF5 Data Format This package provides an object-oriented interface for the PDL package to the HDF5 data-format. Information on the HDF5 Format can be found at the NCSA's web site at http://hdf.ncsa.uiuc.edu/ . . LIMITATIONS . Currently this interface only provides a subset of the total HDF5 library's capability. . * Only HDF5 Simple datatypes are supported. No HDF5 Compound datatypes are supported since PDL doesn't support them. . * Only HDF5 Simple dataspaces are supported. -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559476: ITP: libpdl-netcdf-perl -- netcdf IO support for pdl (perl data language)
Package: wnpp Severity: wishlist Owner: Henning Glawe gla...@debian.org * Package name: libpdl-netcdf-perl Version : 4.02 Upstream Author : Doug Hunt dh...@ucar.edu * URL : http://search.cpan.org/~dhunt/PDL-NetCDF-4.02/ * License : Same terms as Perl Programming Lang: Perl Description : netcdf IO support for PDL (Perl Data Language) This is the PDL interface to the Unidata NetCDF library. It uses the netCDF version 3 library to make a subset of netCDF functionality available to PDL users in a clean, object-oriented interface. Another NetCDF perl interface, which allows access to the entire range of netCDF functionality (but in a non-object-oriented style which uses perl arrays instead of PDLs) is available through Unidata at http://www.unidata.ucar.edu/packages/netcdf/index.html). The NetCDF standard allows N-dimensional binary data to be efficiently stored, annotated and exchanged between many platforms. When one creates a new netCDF object, this object is associated with one netCDF file. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552458: libopengl-perl: Freeglut support not working
Package: libopengl-perl
Version: 0.60+dfsg-1
Severity: important
Tags: patch
Moin,
due to a problem in upstreams build system, freeglut as installed by
freeglut3-dev is not recognized as freeglut, but only as glut (which
breaks event handling as used in PDL: windows are not properly
mapped/unmapped, mouse interaction non-working; this is partly
also observable in libopengl-perl's examples).
the reason for this is that the build system does not look for the
freeglut headers, but for the library -lfreeglut. in freeglut3-dev, the
library is called only -lglut, therefore freeglut is mistaken for the
basic 'glut'.
the patch attached to this report (already submitted upstream) solves
this by checking for the headers in addition.
it should apply on top of your quilt stack.
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30-bpo.2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libopengl-perl depends on:
ii freeglut32.4.0-6.1 OpenGL Utility Toolkit
ii libc62.7-18 GNU C Library: Shared libraries
ii libgl1-mesa-glx [libgl1] 7.0.3-7 A free implementation of the OpenG
ii libglu1-mesa [libglu1] 7.0.3-7 The OpenGL utility library (GLU)
ii libx11-6 2:1.1.5-2 X11 client-side library
ii perl 5.10.0-19lenny2 Larry Wall's Practical Extraction
ii perl-base [perlapi-5.10. 5.10.0-19lenny2 minimal Perl system
libopengl-perl recommends no packages.
libopengl-perl suggests no packages.
-- no debconf information
--
c u
henning
Index: libopengl-perl-0.60+dfsg/Makefile.PL
===
--- libopengl-perl-0.60+dfsg.orig/Makefile.PL 2009-10-26 11:25:15.529290305
+0100
+++ libopengl-perl-0.60+dfsg/Makefile.PL2009-10-26 11:38:18.692290542
+0100
@@ -476,6 +476,19 @@
print GLX not found (neither library, nor headers).;
}
+ # Test for obfuscated Freeglut
+ # quite often Freeglut is in -lglut... Test for GL/freeglut.h instead...
+ my $out = cfile_text('GL/freeglut.h');
+
+ # The cpp would not let this macro through. Check for something else
+ # that still exists after the cpp pass. a typedef, or type would work
+ my $has_freeglut = ($out =~ m|glutMainLoopEvent|);
+
+ if ($has_freeglut)
+ {
+$DEFS .= -DHAVE_FREEGLUT_H -DHAVE_FREEGLUT;
+$found_libs-{FREEGLUT}=glut unless ($found_libs-{FREEGLUT});
+ }
# Marshall libs
my $libs = ' -l'.join(' -l',values(%$found_libs));
Bug#547891: fai-client: fcopy -r descends recursively into the target filesystem, not just the config space
On Tue, Sep 22, 2009 at 04:19:38PM +0200, Henning Sprang wrote:
On Tue, Sep 22, 2009 at 2:59 PM, Andreas Schuldei andr...@debian.org wrote:
it would be better it fcopy ignored parts of the filesystem it
had no buisness with.
Actually, if I understand this description right, I see no reason at
all why fcopy should do anything but placing a file from the files
directory in the right location on the target. No need to search or
walk through target directories at all.
it is only calling File::Find::find with subdirectories of $FAI/files:
-
foreach (@ARGV) { $_=$source/$_; }
File::Find::find(...,@ARGV)
-
unless File::Find::find is implemented in a buggy way, this should never be
influenced by the target fs.
--
c u
henning
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543690: fai-client: make fai softupdate less verbose; better: make it quiet
On Wed, Aug 26, 2009 at 04:35:38PM +0200, Eymen Alyaz wrote: We use the command 'fai softupdate' in a daily cronjob to keep our systems up to date. Right now for every softupdate run, fai prints out alot of messages although it ran without errors. Well, I consider these messages simply as status messages, like in every command you run on the command line. We modified files in our local site. I attach a patch including the dirty/quick modifications. Regard this patch as a starting point for a proper implementation please. Maybe the best way would be to implement a '-q' switch for people running softupdates from cron. -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517420: fcopy: -r and -m don't work well together
On Fri, Feb 27, 2009 at 04:29:14PM +0100, Michael Goetze wrote: It would be nice if fcopy could also set the user/permission of directories in recursive mode. For instance, if I write a script such as fcopy -m nagios,nagios,755 -ri /usr/local/nagios then /usr/local/nagios/.ssh/authorized_keys would have the right owner but /usr/local/nagios/.ssh would not. this is a general feature of fcopy: every directory created by it is root:root:0755, so this is unrelated to the -r option. a definitive solution would be to modify fcopy to support reading file-modes also for dirs. -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517420: Info received (Bug#517420: fcopy: -r and -m don't work well together)
Some more info: basic problem is that fcopy calls mkpath from the File::Path module (equivalent to mkdir -p). this function only accepts mode, but not owner/group as arguments in order to achieve your goal, this should be replaced with an explicite loop (mkdir, chmod) to create the hierarchy of dirs -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513208: fglrx-driver: low default resolution after updating from 8-10 to 8-12
Package: fglrx-driver Version: 1:8-12-4 Severity: important The screen of my Lenovo Thinkpad T60, native resolution 1400x1050, driven by a mobility radeon x1400, came up after the update to 8-12 with a default resolution of 1024x768. The other modes are still there and selectable by xrandr, but the default is 1024x768. looking at the Xorg.0.log, I saw the message: [...] (WW) AIGLX: 3D driver claims to not support visual 0x72 (II) AIGLX: Loaded and initialized /usr/lib/dri/fglrx_dri.so (II) GLX: Initialized DRI GL provider for screen 0 (II) fglrx(0): Restoring recent mode: 1024x...@60hz (**) Option CoreKeyboard (**) Generic Keyboard: always reports core events (**) Option Protocol standard [...] how to change that back to 1400x1050? -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages fglrx-driver depends on: ii fglrx-glx 1:8-12-4 proprietary libGL for the non-free ii libc6 2.7-18 GNU C Library: Shared libraries ii libdrm2 2.3.1-2Userspace interface to kernel DRM ii libgl1-mesa-glx [libgl1] 7.0.3-7A free implementation of the OpenG ii libx11-6 2:1.1.5-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxrandr22:1.2.3-1 X11 RandR extension library ii libxrender1 1:0.9.4-2 X Rendering Extension client libra ii xserver-xorg 1:7.3+18 the X.Org X server Versions of packages fglrx-driver recommends: ii fglrx-atieventsd 1:8-12-4 external events daemon for the non ii fglrx-glx 1:8-12-4 proprietary libGL for the non-free ii fglrx-glx-ia321:8-12-4 proprietary libGL for the non-free ii fglrx-kernel-2.6.26-1 1:8-12-4+2.6.26-13 ATI binary kernel module for Linux ii fglrx-source 1:8-12-4 kernel module source for the non-f Versions of packages fglrx-driver suggests: ii fglrx-control 1:8-12-4 control panel for the non-free AMD -- no debconf information -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513208: [Pkg-fglrx-devel] Bug#513208: fglrx-driver: low default resolution after updating from 8-10 to 8-12
On Tue, Jan 27, 2009 at 06:21:40PM +0100, Patrick Matthäi wrote: modelines from the xorg.conf are more and more ignored, that's the big plan of ATI/AMD. :-) yukk. why do they do this? xorg.conf is a standard and _working_ solution for this... Could you try it out with aticonfig (command line application) and amdcccle (gui) please? It has it own prop. config for such things.. - switched to 1400x1050 using xrender - ran amdcccle, 1400x1050 was listed there as desktop area - logout, xserver restarted (as setup in gdm) - server came up with 1024x768 - cursed a lot, shutdown the laptop, unplugged power - some hours of work in the office - returned home, replugged power, switched on laptop - server came up with 1400x1050 - WTF?! Xorg.0.log showed: (II) fglrx(0): Restoring recent mode: 1400x1...@60hz where does fglrx take this information from? and: I am pretty sure that before the update, the screen was running at its native resolution. is 1024x768 some default hardcoded in fglrx? -- c u henning -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505314: the expermental version fixes the gl-distortions for me
Moin, just tried the version from experimental, this fixes the distorted-3d-problems I observe in wine. can't you ask for a freeze exception for this version? one of the primary uses of fglrx is 3d stuff, and this is broken in many cases in lenny... -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502394: fai-client: Softupdates hang during update of config files
On Thu, Oct 16, 2008 at 10:46:58AM +0200, Thomas Lange wrote: Another approach could be, that the admin is resposible for setting his prefered options in /etc/apt/apt.conf.d, when doing softupdtes. If this is at least the way I do it. FAI forces the options that you proposed, it's not possible for others to change them or use other options. So, is it really a good idea to force those options for every softupdate? I would say that the best way is to document this by including the appropriate configuration in the simple example... -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475007: This also happens on etch-lenny dist-upgrades
Moin, just hit this one in an etch-lenny dist-upgrade: Unpacking fglrx-glx (from .../fglrx-glx_1%3a8-7-2_amd64.deb) ... Removing `diversion of /usr/lib/libGL.so.1.2 to /usr/lib/fglrx/diversions/libGL.so.1.2 by fglrx-driver' dpkg-divert: `diversion of /usr/lib/libGL.so.1.2 to /usr/lib/fglrx/diversions/libGL.so.1.2 by fglrx-glx' clashes with `diversion of /usr/lib/libGL.so.1.2 to /usr/lib/fglrx/diversions/libGL.so.1.2 by fglrx-driver' dpkg: error processing /var/cache/apt/archives/fglrx-glx_1%3a8-7-2_amd64.deb (--unpack): subprocess pre-installation script returned error exit status 2 seems like there is a properly versioned Conflicts: missing to force the upgrade of fglrx-driver before fglrx-glx. -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499758: Redundancy
On Sun, Sep 21, 2008 at 09:46:46PM -0700, Daniel Moerner wrote: I just noticed that you are both maintainer of pdl and submitter of this bug, so you probably already had a copy of the upstream CVS. Sorry for the chaff--at least the link is here for posterity's sake! yup; I am even working in upstream cvs ;) well, I included the patch in 2.4.3-8, which I will upload in a minute... -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499758: pdldoc apropos documentation search broken
Package: pdl Version: 1:2.4.3-6+b1 Severity: important Tags: patch pdldoc -a ceased to work with perl 5.10; upstream cvs contains a fix for this. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages pdl depends on: ii fftw2 2.1.3-22 library for computing Fast Fourier ii libc6 2.7-13GNU C Library: Shared libraries ii libgd2-xpm 2.0.36~rc1~dfsg-3 GD Graphics Library version 2 ii libgl1-mesa-glx [libgl 7.0.3-5 A free implementation of the OpenG ii libglu1-mesa [libglu1] 7.0.3-5 The OpenGL utility library (GLU) ii libgsl0ldbl1.11+dfsg-1 GNU Scientific Library (GSL) -- li ii libhdf4g 4.1r4-22 The Hierarchical Data Format libra ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libplplot9 5.9.0-8 Scientific plotting library ii libterm-readkey-perl 2.30-4A perl module for simple terminal ii libx11-6 2:1.1.4-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii perl 5.10.0-13 Larry Wall's Practical Extraction ii perl-base [perlapi-5.1 5.10.0-13 minimal Perl system ii proj 4.6.0-2 Cartographic projection filter and ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime pdl recommends no packages. Versions of packages pdl suggests: ii imagemagick 7:6.3.7.9.dfsg1-2+b2 image manipulation programs pn libastro-fits-heade none (no description available) ii libgl1-mesa-glx [li 7.0.3-5 A free implementation of the OpenG pn libinline-perl none (no description available) pn libplplot-dev none (no description available) pn libterm-readline-gn none (no description available) ii netpbm 2:10.0-12Graphics conversion tools pn pgperl none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496883: fai-client: get-config-dir-svn doesn't support password
On Thu, Aug 28, 2008 at 10:39:16AM +0200, Jonathan Beckman wrote: To have a secure method to get the configuration space with subversion you should have a password. I have patched the get-config-dir-svn file to enable support for this. well, I was doing it the same way as with cvs: simply copy the authentication data to the nfsroot by copying recursively a properly setup .subversion directory ;) -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495359: perl is in an unusable state during etch-lenny dist-upgrade and breaks the upgrade process
On Sat, Aug 16, 2008 at 09:21:54PM +0300, Niko Tyni wrote: First, what happens here is that the 'old-prerm upgrade' invocation of gs-common invokes /usr/bin/defoma-app, which needs File::Copy from perl-modules. The new perl-modules and perl packages have been unpacked but not configured yet, so their dependencies are not guaranteed to be satisfied (and indeed, the critical perl - perl-base dependency isn't.) well, there are some other cases related to debsums in other maintainer scripts (in one of my experiments, i simply disabled the error in gs-common by letting the prerm in /var/lib/dpkg/config directly exit with exitcode 0. Quoting Brendan O'Dea in #479711, in the Locale::Gettext problem context: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479711#120 One issue which should be highlighted is that no such guarantees are made *during* the upgrade process. In fact Debian policy is pretty explicit as to what is valid for maintainer scripts to invoke: either the package providing the binary must be flagged as Essential (in which case there are additional requirements placed on the package such that it is functional even when not configured) or a Pre-Dependency must be declared (ensuring that dpkg with not only unpack, but will configure said dependency package before attempting to configure the dependant). (The perl-base package is the only Essential:yes one built from the perl source.) That said, I can't find this explicit explanation in the policy myself. Section 7.2 looks like the place, but these come closest: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps The Depends field should also be used if the postinst, prerm or postrm scripts require the package to be present in order to run. [...] Pre-Depends should be used sparingly, preferably only by packages whose premature upgrade or installation would hamper the ability of the system to continue with any upgrade that might be in progress. Pre-Depends are also required if the preinst script depends on the named package. It is best to avoid this situation if possible. well, then how to solve the problems of maintainer scripts using the more complex debian helpers like defoma/debsums? make each package pre-depend on the corresponding package and them in turn on perl? this is AFAIK impossible and clutters the archive by big amounts... so one idea would be to change the maintainer script interface of defoma/debsums/whatever to only use modules contained in perl-base. but then, in turn: do we now need release notes to manually update half of the system before running aptitude dist-upgrade? i think this is most easily solved with proper dependencies of the perl packages, maybe by introducing a conflicts with a too-old perl-base package. Even if this is deemed to be a policy violation by the gs-common package, I suspect it's not the only one, and finding them all is non-trivial. and AFAIK this has to be solved before the lenny release. I'll have to think a bit about any possibilities of solving this with Pre-Dependencies. I also wonder if using Conflicts: perl-base ( 5.10.0) or something like that might work. Pre-Dependency together with conflicts worked a few years ago when updating a a huge amount of machines from woody to sarge; for this, I prepared locally patched perl packages with the following changes: * perl-base: - Conflicts: perl ( 5.8.0-1), perl-modules ( 5.8.0-1) * perl-modules: - unchanged * perl: - moved from Depends: to Pre-Depends: perl-base (= 5.8.4-5.1) this combination forced apt to update the perl packages in the right order, meaning the order to keep all three packages consistent which fixed similar problems at that time. p.s.: this change was rejected at that time with the argument you quoted from Brendan O'Dea, i.e. that it is basically the mainainer scripts' fault and not perls. I know that a pre-depends is a quite strong measure, but in this case it is AFAIK justified... Merging perl-base, perl and perl-modules seems like a very intrusive change at this stage of the release cycle. yes, and also quite improbable to be accepted by the embedded crowd... difficulty is, that this problem is seen very rarely during the normal testing cycle and it can be observed most often when it is too late: when people are already upgrading from old-/stable to testing/stable. Please send the result of 'dpkg -l list' (it chops off long columns if outputting to the terminal) in the initial state with Etch installed, so I can set up a similar chroot and try to reproduce it. should be attached to this mail :) you may have problems finding some of the packages, i have backported and packaged from scratch a lot of stuff on my own... -- c u henning ruprecht-backup-20080813-2.dpkg-l.gz Description: Binary data
Bug#495359: perl is in an unusable state during etch-lenny dist-upgrade and breaks the upgrade process
Subject: perl is in an unusable state during etch-lenny dist-upgrade and breaks the upgrade process Package: perl Version: 5.10.0-13 Severity: critical Justification: breaks unrelated software Scenario: - etch system with latest security updates (August 16th 2008) - replaced etch by lenny in /etc/apt/sources.list - first run successfully aptitude install dpkg aptitude (as stated in http://www.mail-archive.com/[EMAIL PROTECTED]/msg11612.html) - now the real thing: aptitude dist-upgrade after installing and unpacking a lot of stuff, maintainer scripts start to fail with messages like: Can't locate File/Copy.pm in @INC (@INC contains: /home/glaweh/bin/perl5 /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /u BEGIN failed--compilation aborted at /usr/bin/defoma-app line 7. dpkg: error processing gs-common (--remove): subprocess pre-removal script returned error exit status 2 Errors were encountered while processing: gs-common State of the perl packages at this time: n033:/# dpkg -l perl perl-base perl-modules Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version +++-=- iU perl 5.10.0-11.1 ii perl-base 5.8.8-7etch3 iU perl-modules 5.10.0-11.1 and the whole upgrade-process stops. I think I encountered the same bug already in previous debian releases and proposed at that time to make one of the depedencies in the perl dependency loop a pre-depends instead... this worked for me at that time. an easier solution may be to merge all three packages into 1 package to avoid inconsistencies completely. The impact on the mirror network is neglegible, it would add 3.2M per architecture, the size of the only arch:all package perl-modules. I have a backup of the etch system, so in case you want me to check for something specific i can reproduce this in a chroot. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages perl depends on: ii libc6 2.7-13 GNU C Library: Shared libraries ii libdb4.6 4.6.21-8 Berkeley v4.6 Database Libraries [ ii libgdbm3 1.8.3-3GNU dbm database routines (runtime ii perl-base 5.10.0-13 minimal Perl system ii perl-modules 5.10.0-13 Core Perl modules Versions of packages perl recommends: ii netbase 4.32Basic TCP/IP networking system ii perl-doc 5.10.0-11.1 Perl documentation Versions of packages perl suggests: ii libterm-readline-gnu-perl 1.17a-2+b1 Perl extension for the GNU Readlin -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495379: PDL::Graphics::TriD is broken by perl 5.10
Subject: pdl: PDL::Graphics::TriD is broken by perl 5.10 Package: pdl Version: 1:2.4.3-6+b1 Severity: normal demo 3d fails after perl 5.8.8 - perl 5.10.0 #31817: PDL-2.4.3: Not a HASH reference at /usr/local/lib/perl5/site_perl/5.10.0/mach/PDL/Graphics/TriD/Objects.pm line 53, line 29. #33367: Re: PDL-2.4.3: Not a HASH reference at /usr/local/lib/perl5/site_perl/5.10.0/mach/PDL/Graphics/TriD/Objects.pm line 53, line 29. This is an upstream issue and has been reported to their bugtracker: http://rt.cpan.org/Ticket/Display.html?id=31817 http://rt.cpan.org/Ticket/Display.html?id=33367 http://sourceforge.net/tracker/index.php?func=detailaid=1994617group_id=612atid=100612 -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages pdl depends on: ii fftw2 2.1.3-22 library for computing Fast Fourier ii libc6 2.7-13GNU C Library: Shared libraries ii libgd2-xpm 2.0.36~rc1~dfsg-3 GD Graphics Library version 2 ii libgl1-mesa-glx [libgl 7.0.3-5 A free implementation of the OpenG ii libglu1-mesa [libglu1] 7.0.3-5 The OpenGL utility library (GLU) ii libgsl0ldbl1.11-2GNU Scientific Library (GSL) -- li ii libhdf4g 4.1r4-22 The Hierarchical Data Format libra ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libplplot9 5.9.0-8 Scientific plotting library ii libterm-readkey-perl 2.30-4A perl module for simple terminal ii libx11-6 2:1.1.4-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii perl 5.10.0-13 Larry Wall's Practical Extraction ii perl-base [perlapi-5.1 5.10.0-13 minimal Perl system ii proj 4.6.0-1 Cartographic projection filter and ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime pdl recommends no packages. Versions of packages pdl suggests: ii imagemagick 7:6.3.7.9.dfsg1-2+b2 image manipulation programs pn libastro-fits-heade none (no description available) ii libgl1-mesa-glx [li 7.0.3-5 A free implementation of the OpenG ii libinline-perl 0.44-5 Write Perl subroutines in other pr pn libplplot-dev none (no description available) ii libterm-readline-gn 1.17a-2+b1 Perl extension for the GNU Readlin pn pgperl none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477564: works for me
Moin, I was not able to reproduce this one on fai 3.2.8 with a working aufs overlay mount. could the error in your case be related to a non-working unionfs/aufs? in newer fai versions, this mechanism is used to make the nfsroot writable, so the problem you reported should never occur. -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466690: by-uuid does only work for partitions
it is only possible to use UUIDs on partions (more explicitely: it is a filesystem property). however, it is possible to use disk ids (vendor/model/serial numbers) to identify a disk: [EMAIL PROTECTED]:/dev/disk/by-id ls ata-FUJITSU_MHV2120B-NW9ST6B25S2M ata-FUJITSU_MHV2120B-NW9ST6B25S2M-part1 ata-FUJITSU_MHV2120B-NW9ST6B25S2M-part2 ata-FUJITSU_MHV2120B-NW9ST6B25S2M-part3 ata-FUJITSU_MHV2120B-NW9ST6B25S2M-part4 ata-FUJITSU_MHV2120B-NW9ST6B25S2M-part5 ata-FUJITSU_MHV2120B-NW9ST6B25S2M-part6 scsi-SATA_FUJITSU_MHV2120_NW9ST6B25S2M scsi-SATA_FUJITSU_MHV2120_NW9ST6B25S2M-part1 scsi-SATA_FUJITSU_MHV2120_NW9ST6B25S2M-part2 scsi-SATA_FUJITSU_MHV2120_NW9ST6B25S2M-part3 scsi-SATA_FUJITSU_MHV2120_NW9ST6B25S2M-part4 scsi-SATA_FUJITSU_MHV2120_NW9ST6B25S2M-part5 scsi-SATA_FUJITSU_MHV2120_NW9ST6B25S2M-part6 -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491683: Please add HTML-Docs to Doc-base
On Mon, Jul 21, 2008 at 12:09:55PM +0200, Tobias Spranger wrote: Package: pdl Version: 1:2.4.3-3 Severity: wishlist Please add HTML-Documentation to Doc-base. This was already proposed in #60191 and since closing this bug, the html-docs are registered with doc base, section math. This Report is for Debian GNU/Linux 4.0 (etch), but it also applies to the current (20.07.2008) Version of unstable. well, in my tests I did find the docs; maybe sth is wron on your system? -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488092: pdl: pct() returns wrong result
On Thu, Jun 26, 2008 at 07:11:11PM +0900, Nils Christian wrote: Running the code use PDL; use PDL::Ufunc; my $piddle=pdl(0,0,6,3,5,0,7,14,94,5,5,8,7,7,1,6,7,13,10,2,101,19,7,7,5); print(pct($piddle,.9).\n); gives -11 which is obviously completely wrong. For some other piddles the percentile was calculated correctly. Ok, just forwarded this one to the upstream BTS; It will be fixed in the next release, which is scheduled for this summer. -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487866: fai: Not properly licensed
Package: fai Version: 2.2.3 Severity: serious Tags: patch Justification: Policy 2.3 I have contributed major changes to FAI since 2001, however the copyright information in the source files only mention some of my contributions I made in the form of from-scratch implementations. in order to finally solve these licensing issues, a branch /people/eartoast/fix-copyright has been created in the fai svn containing the copyright header fixes for the contributions I could reconstruct from my patch/mail archives. IMPORTANT NOTE for NMUers: Do not resolve this bug by NMU! Thomas Lange wants to check this against his personal archive before uploading! @Thomas: I filed this with the appropriate priority (serious), but set the version to the first version containing my contributions. therefore, this should not influence the testing migration for lenny, as this bug applies both to testing and unstable. this should be fairly trivial to resolve, I attach a diff with the updated copyright info to this report. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.25.8-desktop-1 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Index: doc/fai-guide.sgml === --- doc/fai-guide.sgml (revision 4929) +++ doc/fai-guide.sgml (working copy) @@ -36,6 +36,9 @@ copyrightsummary Copyright copy; 2000-2008 Thomas Lange /copyrightsummary +copyrightsummary +Copyright copy; 2005 Henning Glawe +/copyrightsummary p This manual is free software; you may redistribute it and/or modify it under the terms of the GNU General Public License as published by the Index: lib/subroutines-linux === --- lib/subroutines-linux (revision 4929) +++ lib/subroutines-linux (working copy) @@ -7,6 +7,8 @@ # This script is part of FAI (Fully Automatic Installation) # (c) 2005-2008 by Thomas Lange, [EMAIL PROTECTED] # Universitaet zu Koeln +# (c) 2001-2005 by Henning Glawe, [EMAIL PROTECTED] +# Freie Universitaet Berlin # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ### BEGIN SUBROUTINE INFO # Provides-Var:$device_size $disklist Index: lib/subroutines === --- lib/subroutines (revision 4929) +++ lib/subroutines (working copy) @@ -8,6 +8,8 @@ # This script is part of FAI (Fully Automatic Installation) # (c) 2000-2008 by Thomas Lange, [EMAIL PROTECTED] # Universitaet zu Koeln +# (c) 2001-2005 by Henning Glawe, [EMAIL PROTECTED] +# Freie Universitaet Berlin # #* # This program is free software; you can redistribute it and/or modify Index: bin/fcopy === --- bin/fcopy (revision 4929) +++ bin/fcopy (working copy) @@ -8,6 +8,8 @@ # This script is part of FAI (Fully Automatic Installation) # Copyright (C) 2000-2007 Thomas Lange, [EMAIL PROTECTED] # Universitaet zu Koeln +# Copyright (C) 2001-2005 Henning Glawe, [EMAIL PROTECTED] +# Freie Univeritaet Berlin # #* # This program is free software; you can redistribute it and/or modify Index: bin/fai === --- bin/fai (revision 4929) +++ bin/fai (working copy) @@ -7,6 +7,8 @@ # This script is part of FAI (Fully Automatic Installation) # (c) 1999-2008 by Thomas Lange, [EMAIL PROTECTED] # Universitaet zu Koeln +# (c) 2001-2005 by Henning Glawe, [EMAIL PROTECTED] +# Freie Universitaet Berlin # #* # This program is free software; you can redistribute it and/or modify Index: bin/make-fai-nfsroot === --- bin/make-fai-nfsroot(revision 4929) +++ bin/make-fai-nfsroot(working copy) @@ -8,6 +8,8 @@ # This script is part of FAI (Fully Automatic Installation) # (c) 2000-2008 by Thomas Lange, [EMAIL PROTECTED] # Universitaet zu Koeln +# (c) 2004 by Henning Glawe, [EMAIL PROTECTED] +# Freie Universitaet Berlin # #* # This program is free software; you can redistribute it and/or modify Index: bin/install_packages === --- bin/install_packages(revision 4929) +++ bin/install_packages(working copy) @@ -7,6 +7,8 @@ # # This script is part of FAI (Fully Automatic Installation) # (c) 2000-2007, Thomas Lange, [EMAIL PROTECTED] +# (c) 2003-2004, Henning Glawe, [EMAIL PROTECTED] +# (c) 2004 , Jonas Hoffmann, [EMAIL PROTECTED
Bug#405810: actually, debug info is also necessary for systemtap
Moin, as can be seen in #365349, debug info is also useful in other contexts, such as kexec/kdump. in my case, I would like to use the system tap interface; however, without debug info, this is impossible [1]. BTW: the ubuntu kernel guys already have built-in support for debug packages, so in case their packages are related to yours, adding support may be trivial (and quite helpful for the users). [1] http://sourceware.org/systemtap/wiki/SystemtapOnDebian -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415426: Can you push this bugfix to stable please
On Fri, Apr 25, 2008 at 07:18:41PM +0200, Klaus Ethgen wrote: can you please raise the severity to push this easy fix to stable? I reasonably trapped into this bug and it took me many time to find that the error was not done by me than by pdl. I understand that this is an annoying bug, however uploads to debian stable are _strongly_ restricted. Basically, a package should only be uploaded to stable if one of the following happens: * a truly critical functionality problem * the package becomes uninstallable * a released architecture lacks the package from http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-distribution so I do not think that this bug qualifies for s-p-u :S -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452437: Please enable NAN support...
On Thu, Nov 22, 2007 at 09:23:40PM +, Marco Rodrigues wrote: Please enable NAN support... well, this is actually not NAN support... this patch merely changes the representation of 'bad values' to NAN (not a number). according to the pdl docs, there is no performance advantage and it would not work on per-pdl bad values; so what is the reason for ubuntu to change this? -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474751: `pdl does not contain PDL::IO::Dicom module
On Mon, Apr 07, 2008 at 11:21:56AM -0400, mlaks wrote: pdl package does not include the Dicom.pm module. ie PDL::IO::Dicom. which is in pdl upstream. Can it be included. I am playing with medical images. I am aware of its limitations, but it is useful for me. thanks for reporting; seems like there is a bug in an upstream Makefile.PL, which keeps Dicom from beeing installed. I will make an upload changing this. BTW: Did you test this module? does it work well? I am asking just because there might be a reason it is not installed by default in upstream. -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409059: fai-client: using ifclass in $FAI/scripts/ kills shell.log if $debug is set
Package: fai-client
Version: 3.1.6
Severity: important
Tags: patch
if $debug is set, shell.log is overwritten every time ifclass is called
in $FAI/scripts. problem: stderr is redirected (in append mode) to a
file, but ifclass redirects its debug messages (in overwrite mode) to
stderr.
the attached patch solves this problem for me.
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Versions of packages fai-client depends on:
ii cfengine2 2.1.20-1 Tool for configuring and maintaini
ii file 4.19-1 Determines file type using magic
ii libapt-pkg-perl 0.1.20 Perl interface to libapt-pkg
ii perl 5.8.8-7Larry Wall's Practical Extraction
fai-client recommends no packages.
-- no debconf information
Index: subroutines
===
--- subroutines (revision 4227)
+++ subroutines (working copy)
@@ -61,7 +61,7 @@
ifclass() {
-[ $debug ] echo Test if class $1 is in $classes /dev/stderr
+[ $debug ] echo Test if class $1 is in $classes /dev/stderr
# test if a class is defined
local cl
local ret=1
@@ -69,7 +69,7 @@
for cl in $classes; do
[ x$cl = x$1 ] ret=0 break
done
-[ $debug ] echo ifclass returns $ret /dev/stderr
+[ $debug ] echo ifclass returns $ret /dev/stderr
return $ret
}
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Bug#407463: pdl: PDL::Graphics::PGPLOT is broken
On Thu, Jan 18, 2007 at 11:20:16AM -0500, Diab Jerius wrote: pdl no longer depends upon pgperl, which means that PDL::Graphics::PGPLOT won't work. Unfortunately I've got some 8+ years of scripts which depend upon PDL::Graphics::PGPLOT, so this is a major breakage. Switching to PLplot isn't an option. Any chance of getting support for PGPLOT back in? It looks like pgperl (the vital missing ingredient) is no longer a supported package. you're right, that last point is the cause of that problem. However, the pdl PGPLOT interface is still in the PDL debian package; so you can build and install pgperl manually and P::G::PGPLOT should be able to run on your machine. -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406683: pdl: remove docs from /usr/lib/perl5/PDL
On Fri, Jan 12, 2007 at 11:24:19PM +0100, A Mennucc wrote: I found many HTML docs inside /usr/lib/perl5/PDL the html docs are generated at install time, but not inside /usr/lib/perl5/PDL; they are generated in /usr/share/doc/pdl. did you call /usr/lib/perl5/PDL/Doc/mkhtmldoc.pl manually? it seems that, when I remove the pdl package, they were not deleted could you try to reproduce this by installing and removing the version of pdl in testing/unstable after removing the remaining files by hand? -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406336: fai-client: fai-debconf leaves tmpfile behind
Package: fai-client
Version: 3.1.3
Severity: normal
Tags: patch
two small problems in fai-debconf:
1) debconf-copydb moves $tmpdb to $tmpdb-old before writing, which
left behind one /tmp/tmp.X-old for each softupdate run on
the machine
2) mktemp is called without a filename-pattern, which made finding
that fai-debconf is the script to blame for the left-behind tmpfile a
very hard job
Index: fai-debconf
===
--- fai-debconf (revision 4210)
+++ fai-debconf (working copy)
@@ -69,7 +69,7 @@
fi
packages=$(awk '{print $1}' $LOGDIR/debconf.data | sort | uniq)
# backup database
- tmpdb=$($ROOTCMD mktemp)
+ tmpdb=$($ROOTCMD mktemp -t fai-debconf.XX)
$ROOTCMD debconf-copydb configdb faidb --config=Name:faidb
--config=Driver:File --config=Filename:$tmpdb
for p in $packages; do
# test if package is installed
@@ -82,7 +82,7 @@
# echo Package $p is not yet installed. Skipping reconfiguration.
fi
done
- rm $target/$tmpdb
+ rm -f $target/$tmpdb $target/$tmpdb-old
}
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
usage() {
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Versions of packages fai-client depends on:
ii cfengine2 2.1.20-1 Tool for configuring and maintaini
ii file 4.17-5 Determines file type using magic
ii libapt-pkg-perl 0.1.20 Perl interface to libapt-pkg
ii perl 5.8.8-7Larry Wall's Practical Extraction
fai-client recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406334: fai-client: make-fai-nfsroot should not try to copy the .ssh/*.pub files
Package: fai-client
Version: 3.1.3
Severity: normal
Tags: patch
make-fai-nfsroot fails if $loguserhome/*.pub does not exist. However, as
these files have no immediate meaning (.ssh/authorized_keys contains the
pubkeys of the users allowed to log in), it would be better not to copy
these files at all (and avoid failing, as the shell runs in
exit-on-error mode).
--- make-fai-nfsroot(revision 4210)
+++ make-fai-nfsroot(working copy)
@@ -159,14 +159,12 @@
mkdir -p -m 700 $NFSROOT/root/.ssh
if [ -n $LOGUSER ] ; then
loguserhome=`eval cd ~$LOGUSER 2/dev/null pwd;true`
-# is copying of *.pub important?
[ -f $loguserhome/.ssh/known_hosts ] cp
$loguserhome/.ssh/known_hosts $NFSROOT/root/.ssh/known_hosts
[ -d $loguserhome/.ssh ] {
[ -f $loguserhome/.ssh/id_dsa ]
cp -p $loguserhome/.ssh/id_dsa* $NFSROOT/root/.ssh/
[ -f $loguserhome/.ssh/id_rsa ]
cp -p $loguserhome/.ssh/id_rsa* $NFSROOT/root/.ssh/
- cp -p $loguserhome/.ssh/*.pub $NFSROOT/root/.ssh/
}
fi
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Versions of packages fai-client depends on:
ii cfengine2 2.1.20-1 Tool for configuring and maintaini
ii file 4.17-5 Determines file type using magic
ii libapt-pkg-perl 0.1.20 Perl interface to libapt-pkg
ii perl 5.8.8-7Larry Wall's Practical Extraction
fai-client recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403045: [pkg-wpa-devel] Bug#403045: wpasupplicant: race condition in wpa_action disconnect between ifdown and if_post_down_up
On Fri, Dec 15, 2006 at 01:33:12PM +1000, Kel Modderman wrote: the problem is, at least in my case, that the link is _down_ afterwards, so wpasupplicant is not able to scan further. This seems to be caused by the interface not being completely downed yet when ifdown finishes; putting a 'sleep 1' into functions.sh::ifdown immediately after the call to /sbin/ifdown solves this problem. Yeah, I'm not a fan of unconditional sleeps though. me neither, thats why I set the word solves in doublequotes ;) Do you have iproute installed? That slighly changes behaviour of if_post_down_up, causing the interface to be flushed before 'upping' it again. iproute was installed when I discovered the race. In any case, ifdown should not exit until it has fully completed what it had to do with the interface, at least in my opinion. I fully agree; I was also quite surprized about this fact when I did the research for this report. -- c u henning signature.asc Description: Digital signature
Bug#403045: wpasupplicant: race condition in wpa_action disconnect between ifdown and if_post_down_up
Package: wpasupplicant Version: 0.5.5-3 Severity: normal Tags: patch I have configured a roaming wpa configuration on my laptop using allow-hotplug wlan0 iface wlan0 inet manual wpa-driver wext wpa-roam /etc/wpa_supplicant.conf in /etc/network/interfaces. If a disconnect event occurs, wpa_action is called with the action DISCONNECTED, which ifdowns the interface and then should immediately re-enable the scanning mode by calling /etc/wpa_supplicant/functions.sh::if_post_down_up the problem is, at least in my case, that the link is _down_ afterwards, so wpasupplicant is not able to scan further. This seems to be caused by the interface not being completely downed yet when ifdown finishes; putting a 'sleep 1' into functions.sh::ifdown immediately after the call to /sbin/ifdown solves this problem. Furter system configuration info: - madwifi-ng wlan, using wpa_supplicants 'wext' driver - dhcpcd dhcp client -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages wpasupplicant depends on: ii libc62.3.6.ds1-9 GNU C Library: Shared libraries ii libdbus-1-3 1.0.1-2 simple interprocess messaging syst ii libncurses5 5.5-5 Shared libraries for terminal hand ii libreadline5 5.2-1 GNU readline and history libraries ii libssl0.9.8 0.9.8c-4SSL shared libraries ii lsb-base 3.1-22 Linux Standard Base 3.1 init scrip Versions of packages wpasupplicant recommends: pn dhcp3-client none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402059: module-assistant: KMAINT and KEMAIL should be in the Change-By field of the changes file, not in the Maintainer field
Package: module-assistant
Version: 0.10.8
Severity: normal
Tags: patch
If one signs a package using debsign, it uses the Changed-By field to
determine the gpg key to be used.
in the module-assistant makefile snippet
/usr/share/modass/include/generic.make (target 'genchanges'), which is
used by newer module source packages there is an error which overrides
the Maintainer field and not the Changed-By field of the generated
changes file. The attached patch solves this issue.
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Versions of packages module-assistant depends on:
ii libtext-wrapi18n-perl 0.06-5 internationalized substitute of Te
ii perl 5.8.8-6.1 Larry Wall's Practical Extraction
Versions of packages module-assistant recommends:
ii liblocale-gettext-perl1.05-1 Using libc functions for internati
-- no debconf information
--- module-assistant-0.10.8/modass/include/generic.make.orig2006-12-07
20:03:27.0 +0100
+++ module-assistant-0.10.8/modass/include/generic.make 2006-12-07
20:04:00.0 +0100
@@ -304,7 +304,7 @@
genchanges:
(head -2 debian/changelog ; echo * Built for kernel-image-$(KVERS).
; \
echo ; sed -ne '/^ -- / { p; q; }' debian/changelog )
debian/changelog.tmp
- dpkg-genchanges -b -m'$(MAINT)' -u'$(DEB_DESTDIR)'
-ldebian/changelog.tmp $(CHFILE)
+ dpkg-genchanges -b -e'$(MAINT)' -u'$(DEB_DESTDIR)'
-ldebian/changelog.tmp $(CHFILE)
- if [ $$SIGNCHANGES ] ; then \
if test -e `which $${DEBSIGNCOMMAND:-debsign}` ; then
\
$${DEBSIGNCOMMAND:-debsign} $(CHFILE) ; else \
Bug#390122: pdl: FTBFS: No OUTPUT definition for type 'GLvoid', typekind 'T_VOID'
On Fri, Sep 29, 2006 at 11:46:00AM +0200, Daniel Schepler wrote: From my pbuilder build log (on i386): ... /usr/bin/perl /usr/share/perl/5.8.8/ExtUtils/xsubpp -typemap /usr/share/perl/5.8/ExtUtils/typemap -typemap /tmp/buildd/pdl-2.4.3/Basic/Core/typemap.pdl OpenGL.xs OpenGL.xsc mv OpenGL.xsc OpenGL.c Error: No OUTPUT definition for type 'GLvoid', typekind 'T_VOID' found in OpenGL.xs, line 7546 which debian release are you trying this on? on my SID pbuilder, this ran without problems before the upload. -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379932: pdl: PDL::Fit::Gaussian fitgauss1d() causes perl to segfault
On Wed, Jul 26, 2006 at 03:40:51PM +0300, Timo Lindfors wrote: Steps to reproduce: 1) perl -e 'use strict;use PDL::Fit::Gaussian;fitgauss1d(0, 0);' the problem with your example is that you did not 'use PDL;' Expected results: 1) not sure but nothing should segfault Actual results: 1) perl segfaults [...] Please let me know if you can't reproduce this bug. well, I can reproduce the segfault with your unmodified program. however, if you 'use PDL', the segfault disappears, as then the arguments are converted to a piddle implicitely. IMHO this is a problem in the documentation of the PDL::Fit::Gaussian synopsis, which should include 'use PDL;'. I'll fix this in the next upload. -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369849: pdl does not build on amd64 due to missing -fPIC
On Thu, Jun 01, 2006 at 03:58:49PM -0300, Michel Loos wrote: Package: pdl Version: 1:2.4.2-2 Severity: grave Justification: renders package unusable Even without the BAD2_demo/BAD_demo problem, pdl does not build on AMD64 due to 1) the lack of the -fPIC option while compiling slatec/*.f how did you try to compile it? using debian/rules it should work, as there PDLs build-script is tweaked to use debian/f77conf.pl, which in turn contains the -fPIC. can you confirm this error occurs though you are using debian/rules to build PDL? 2) a segfault while compiling Slices.xs can you please send me a build log, so I can get a deeper insight into that issue? -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347308: xterm: problem does not exist in sarge
Package: xterm Version: 210-3 Followup-For: Bug #347308 I am observing the same problem, using ion2 as a window manager. As I am working both under sarge and sid, I observed that this problem does not show up in sarge's xterm version. A second observation I made is that in sid that the misdetection of size occurs with greater probability when the system load is higher. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages xterm depends on: ii libc6 2.3.6-9GNU C Library: Shared libraries ii libfontconfig12.3.2-5.1 generic font configuration library ii libice6 1:1.0.0-3 X11 Inter-Client Exchange library ii libncurses5 5.5-2 Shared libraries for terminal hand ii libsm61:1.0.0-4 X11 Session Management library ii libx11-6 2:1.0.0-6 X11 client-side library ii libxaw7 1:1.0.1-5 X11 Athena Widget library ii libxext6 1:1.0.0-4 X11 miscellaneous extension librar ii libxft2 2.1.8.2-8 FreeType-based font drawing librar ii libxmu6 1:1.0.1-3 X11 miscellaneous utility library ii libxt61:1.0.0-5 X11 toolkit intrinsics library ii xbitmaps 1.0.1-2Base X bitmaps Versions of packages xterm recommends: ii xutils1:7.0.0-3 X Window System utility programs -- debconf information: xterm/clobber_xresource_file: * xterm/xterm_needs_devpts: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361197: linux-image-2.6.16-1-686: snd-cs4281 stopped working when updating from 2.6.15-8 to 2.6.16-5, 686 flavour
Package: linux-image-2.6.16-1-686 Version: 2.6.16-5 Severity: important when booting linux-image-2.6.16-1-686, version 2.6.16-5, the alsa driver snd-cs4281 fails to probe the sound chip: PCI: Found IRQ 5 for device :00:0b.0 ... never read ISV3 and ISV4 from AC'97 CS4281: probe of :00:0b.0 failed with error -5 With linux-image-2.6.15-1-686, version 2.6.15-8, it is working perfectly. Hardware is a IBM ThinkPad 240x, lspci -vv for the sound chip: :00:0b.0 Multimedia audio controller: Cirrus Logic Crystal CS4281 PCI Audio (rev 01) Subsystem: IBM: Unknown device 01a9 Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Interrupt: pin A routed to IRQ 5 Region 0: Memory at fc01 (32-bit, non-prefetchable) [size=4K] Region 1: Memory at fc00 (32-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D3 PME-Enable- DSel=0 DScale=0 PME- lspci -n: :00:0b.0 0401: 1013:6005 (rev 01) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.16-1-686 depends on: ii initramfs-tools [linux-initra 0.59b tools for generating an initramfs ii module-init-tools 3.2.2-2tools for managing Linux kernel mo ii yaird [linux-initramfs-tool] 0.0.12-9 Yet Another mkInitRD Versions of packages linux-image-2.6.16-1-686 recommends: ii libc6-i6862.3.6-5GNU C Library: Shared libraries [i -- debconf information: linux-image-2.6.16-1-686/preinst/initrd-2.6.16-1-686: linux-image-2.6.16-1-686/postinst/old-system-map-link-2.6.16-1-686: true linux-image-2.6.16-1-686/preinst/already-running-this-2.6.16-1-686: linux-image-2.6.16-1-686/preinst/overwriting-modules-2.6.16-1-686: true linux-image-2.6.16-1-686/postinst/old-initrd-link-2.6.16-1-686: true linux-image-2.6.16-1-686/preinst/abort-overwrite-2.6.16-1-686: linux-image-2.6.16-1-686/preinst/elilo-initrd-2.6.16-1-686: true linux-image-2.6.16-1-686/prerm/would-invalidate-boot-loader-2.6.16-1-686: true linux-image-2.6.16-1-686/postinst/bootloader-error-2.6.16-1-686: linux-image-2.6.16-1-686/postinst/create-kimage-link-2.6.16-1-686: true linux-image-2.6.16-1-686/preinst/lilo-has-ramdisk: linux-image-2.6.16-1-686/prerm/removing-running-kernel-2.6.16-1-686: true linux-image-2.6.16-1-686/postinst/old-dir-initrd-link-2.6.16-1-686: true linux-image-2.6.16-1-686/postinst/depmod-error-initrd-2.6.16-1-686: false linux-image-2.6.16-1-686/preinst/lilo-initrd-2.6.16-1-686: true linux-image-2.6.16-1-686/postinst/kimage-is-a-directory: linux-image-2.6.16-1-686/preinst/bootloader-initrd-2.6.16-1-686: true linux-image-2.6.16-1-686/postinst/depmod-error-2.6.16-1-686: false linux-image-2.6.16-1-686/preinst/failed-to-move-modules-2.6.16-1-686: linux-image-2.6.16-1-686/preinst/abort-install-2.6.16-1-686: linux-image-2.6.16-1-686/postinst/bootloader-test-error-2.6.16-1-686: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360183: Preserving a file is no error in my opinion
Moin, I don't think preserving a file could be an error; at the end of the day, the on-disk file is the file we want to have there. -- c u henning signature.asc Description: Digital signature
Bug#360056: fcopy -P does not detect changes in variables
On Fri, Mar 31, 2006 at 09:13:02AM +0200, Michael Tautschnig wrote:
[...]
The -P option of fcopy can not detect changes of the value of a
variables, that is used in a preinst or postinst script. Therefore, if
you use some sort of variable substitution in the {pre,post}inst
script, but neither the template itself nor these scripts had changed,
but only the value of a variable, fcopy will not update this file when
using the -P option.
I recommend to remove this flag. fcopy can always detect if something
has changed without using the -P flag. IMO it also does not save time
calling fcopy with -P. Calling fcopy in the default manner will not
take much more time.
If templates are used, as described above, fcopy will copy the file each time,
even if nothing has changed. The only way to do it correctly would be copying
the template to some temporary file, then running {pre,post}inst on this file,
then do the diff ... However, the scripts might have sideeffects, such as
well, this is why I have implemented preinst:
preinst acts on a temporary copy, which is then compared to the installed
file by fcopy. the installed file is only overwritten and postinst is only
called if fcopy detects a difference.
restarting a service. And, IMHO, it is this particular effect why one would
not
want fcopy to do its job again and again, if the template had not been
changed.
well, _if_ you use preinst and postinst, only preinst should fill in the
template. postinst is there for restarting the daemons.
Still, I see no reason why this option has to be removed - using templates and
the -P option is probably the most advanced use of fcopy today, and those
using
it should be aware of the fact that changes to variables are not detected by
fcopy.
I am currently using a mixture: -P is ignored for the files where a preinst
exists, while for most of the files I am still using the -P logic and a
postinst (I just don't have enough time to change the configuration).
but anyways: abolishing -P in case of my configuration would have quite an
impact on the runtime of a softupdate ;)
shortly speaking: -P should stay in, but maybe a warning should be added
somewhere about the template substitution...
--
c u
henning
signature.asc
Description: Digital signature
Bug#359061: openobex-apps: versioned conflicts on ircp does not work
Package: openobex-apps Version: 1.2-1 Severity: serious Justification: Policy 7.5.2 Moin, your current versioned conflict on ircp does not catch updates within unstable: [EMAIL PROTECTED]:~dpkg --compare-versions '1.1-1' '=' '1.1' || echo false false so it is not enough to replace the package you provided earlier. either use unversioned Conflicts/Replaces, or increase the version to conflict with to 1.2. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages openobex-apps depends on: ii libbluetooth1 2.25-1 Library to use the BlueZ Linux Blu ii libc6 2.3.6-4GNU C Library: Shared libraries an ii libopenobex1 1.2-1 OBEX protocol library ii libusb-0.1-4 2:0.1.11-7 userspace USB programming library openobex-apps recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356975: FTBFS: Can't locate PDL/Config.pm
On Wed, Mar 15, 2006 at 09:14:34PM +, Martin Michlmayr wrote: * Henning Glawe [EMAIL PROTECTED] [2006-03-15 15:28]: strange, as it got build on the mips autobuilder (mayr) on the 9th of january without problems, at least according to But that was in January. Now it fails, and not only on mips but on i386 too. ok, did a bit of research in this; seems like it is a bug in ExtUtils::MakeMaker 6.30, which is part of perl 5.8.8, see http://rt.cpan.org/Public/Bug/Display.html?id=17224 for details; let's see how to get around this. Which version of perl are you using? The one from unstable (5.8.8-3). Actually, it was 5.8.8-2 when I built, it seems. But I guess -3 has the same problem. unless someone has incorporated the EE:MM fix into that version; I'll try to reproduce this pass this bug on to perl... Could you send me a (gziped) complete buildlog of your try? On the first view, the @INC path looks incomplete... You can find the full log at http://people.debian.org/~tbm/logs/gcc-4.1/pdl_1:2.4.2-4_20060314-2149 ok, thanks. -- c u henning signature.asc Description: Digital signature
Bug#356975: FTBFS: Can't locate PDL/Config.pm
On Wed, Mar 15, 2006 at 03:32:39AM +, Martin Michlmayr wrote: Package: pdl Version: 1:2.4.2-4 Severity: serious pdl fails to build because it cannot find PDL/Config.pm: Automatic build of pdl_1:2.4.2-4 on bigsur by sbuild/mips 1.94 ... Manifying ../blib/man3/PDL.3pm make[2]: Leaving directory `/build/tbm/pdl-2.4.2/Basic' make[2]: Entering directory `/build/tbm/pdl-2.4.2/Demos' /usr/bin/perl BAD2_demo.pm.PL BAD2_demo.pm Can't locate PDL/Config.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at BAD2_demo.pm.PL line 12. BEGIN failed--compilation aborted at BAD2_demo.pm.PL line 12. make[2]: *** [BAD2_demo.pm] Error 2 make[2]: Leaving directory `/build/tbm/pdl-2.4.2/Demos' make[1]: *** [subdirs] Error 2 make[1]: Leaving directory `/build/tbm/pdl-2.4.2' make: *** [build-stamp] Error 2 strange, as it got build on the mips autobuilder (mayr) on the 9th of january without problems, at least according to http://buildd.debian.org/fetch.php?pkg=pdlver=1%3A2.4.2-4arch=mipsstamp=1136812302file=logas=raw Which version of perl are you using? Could you send me a (gziped) complete buildlog of your try? On the first view, the @INC path looks incomplete... -- c u henning signature.asc Description: Digital signature
Bug#347877: Reversion of lspci -m changes
On Mon, Mar 13, 2006 at 08:09:30AM -0700, Matthew Wilcox wrote: I have to say I really, really wish remco hadn't accepted this patch. Changing the *machine readable* option of lspci makes Debian incompatible with every other distro. This one is definitely being reverted before we get to 2.2.1-1. Sorry, no discussion on this one. It actually makes it *IMPOSSIBLE* to machine-parse, unless you use -n as well. Look: $ lspci -m 00:00.0 Host bridge Intel Corporation 82855PM Processor to I/O Controller 03 00 Hewlett-Packard Company Unknown device 08b0 I mean, wtf? well, actually I developed this only with -n in mind. I don't mind if it is removed now, as I thought of that change mainly as a starting point for further discussions and was a bit surprised it was applied as-is so quickly. -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356379: remove flag -P from fcopy
On Sat, Mar 11, 2006 at 05:02:17PM +0100, Thomas Lange wrote: Package: fai-client Version: 2.9.1 severity: wishlist I like to remove flag -P from the command fcopy. Is somebody really using it? Me. and with great success. -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348849: fai: loopback device not up
This is a duplicate of #312128, the patch I sent to this should fix this. -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346227: libxvmc-dev: no symlinks for libXvMCW and libviaXvMC* in package
Package: libxvmc-dev Version: 6.9.0.dfsg.1-1 Severity: important ld does link libXvMCW statically at the moment, because the versionless symlink is missing in the xvmc development package. the same problem exists for the via XvMC shared libraries. p.s.: severity is important due to the fact it is a violation of a 'should' statement in policy, section 8.4 -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.14-desktop-2 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#281572: libxine1: xvmcw in unstable
On Thu, Jan 05, 2006 at 05:32:18PM +0100, Henning Glawe wrote: Package: libxine1 Followup-For: Bug #281572 Hi folks, you can rebuild xinelib now with xvmc wrapper support against unstable now; the extra libxvmcw1 packages I put under http://www.physik.fu-berlin.de/~glaweh/debian should not be needed anymore, as libxvmc1 (=6.9.0.dfsg.1-1), which is now in unstable, contains the wrapper; it should be enough to build-depend on libxvmc-dev (=6.9.0.dfsg.1-1) and add '--with-xxmc-lib=XvMCW' to the configure call in the xinelib package. cu henning ok, just realized there's a packaging error in libxvmc-dev: the versionless so symlinks are missing, so -lXvMCW links in the static version; this issue is already reported to the bts... -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#281572: libxine1: xvmcw in unstable
Package: libxine1 Followup-For: Bug #281572 Hi folks, you can rebuild xinelib now with xvmc wrapper support against unstable now; the extra libxvmcw1 packages I put under http://www.physik.fu-berlin.de/~glaweh/debian should not be needed anymore, as libxvmc1 (=6.9.0.dfsg.1-1), which is now in unstable, contains the wrapper; it should be enough to build-depend on libxvmc-dev (=6.9.0.dfsg.1-1) and add '--with-xxmc-lib=XvMCW' to the configure call in the xinelib package. cu henning -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-686 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337271: patch can't work
On Mon, Nov 21, 2005 at 10:58:22PM +0100, Thomas Lange wrote: I like to include this patch, but it can't work. The function getopt is not extended, so the new option -I will not be recognized. you're right; fixed in the corresponding svn branch... but in a certain sense it worked as intended: as the default interface set on the kernel cmdline is now eth0 (and this field is not empty as before), the kernel-level-dhcp failures on the other interfaces disappear ;) -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337271: fai: boot from floppy gets stalled in dhcp queries when there is more than one network interface
Package: fai Severity: normal Prerequisits: - system with two network cards - floppy created with make-fai-bootfloppy Symptoms: - boot gets stalled in dhcp queries, even if a static ip configuration is chosen Cause: - the kernel-commandline's ip configuration isn't bound to a certain interface Cure: - make-fai-bootfloppy should insert an interface as second-last argument in the ip= statement (patch will follow) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337271: [patch] BUGFIX:337271 include an interface name in the kernel-ip configuration
* BUGFIX:337271 include an interface name in the kernel-ip configuration
the interface defaults to eth0, but can be changed using make-fai-bootfloppy's
-I option
--
c u
henning
Thu Nov 3 17:13:32 CET 2005 [EMAIL PROTECTED]
* BUGFIX:337271 include an interface name in the kernel-ip configuration
the interface defaults to eth0, but can be changed using make-fai-bootfloppy's
-I option
diff -rN -u old-pfai/man/make-fai-bootfloppy.8
new-pfai/man/make-fai-bootfloppy.8
--- old-pfai/man/make-fai-bootfloppy.8 2005-11-03 17:31:37.156437000 +0100
+++ new-pfai/man/make-fai-bootfloppy.8 2005-11-03 17:30:00.0 +0100
@@ -66,6 +66,9 @@
.B \-i FILE
Make a 1440k iso9660 image in FILE (requires also -f FILE).
.TP
+.B \-I CLIF
+Use CLIF as client interface (default: eth0).
+.TP
.B \-g
Use GRUB as boot loader (default).
.TP
diff -rN -u old-pfai/scripts/make-fai-bootfloppy
new-pfai/scripts/make-fai-bootfloppy
--- old-pfai/scripts/make-fai-bootfloppy2005-11-03 17:31:37.146437000
+0100
+++ new-pfai/scripts/make-fai-bootfloppy2005-11-03 17:30:00.0
+0100
@@ -34,6 +34,7 @@
floppydev=/dev/fd0
[ -d /floppy ] mountpoint=/floppy
[ -d /media ] mountpoint=/media/floppy
+CLIENTINTERFACE=eth0
mountopts=-t ext2
sd=savedefault
BTYPE=d # default boot protocol is DHCP
@@ -74,6 +75,7 @@
-f FILEmake a 1440k floppy image in FILE
-g use GRUB loader on bootfloppy (default)
-i FILEmake a 1440k iso9660 image in FILE
+ -I CLIFuse CLIF as the client's network interface
-l use LILO loader on bootfloppy
-m DIR use DIR as mountpoint [/floppy or /media/floppy]
-s HOSTuse this static ip for FAI client; try to get all info from DNS
@@ -141,7 +143,7 @@
BROADCAST=`LC_ALL=C ifconfig $SERVERINTERFACE | perl -ne
'/Bcast:([0-9\.]+)/ print $1'`
NETMASK=`LC_ALL=C ifconfig $SERVERINTERFACE | perl -ne
'/Mask:([0-9\.]+)/ print $1'`
GATEWAY=`LC_ALL=C route -n | grep '^0\.0\.0\.0' | awk '{ print $2 }'`
-
fixedparams=ip=${TARGETIP}:${SERVERIP}:${GATEWAY}:${NETMASK}:${TARGETHOST}::off
+
fixedparams=ip=${TARGETIP}:${SERVERIP}:${GATEWAY}:${NETMASK}:${TARGETHOST}:${CLIENTINTERFACE}:off
fi
}
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
@@ -186,15 +188,15 @@
menu-title=FAI $KERNELVERSION
image=$mountpoint/vmlinuz
-append=ip=::any root=/dev/nfs $params
+append=ip=:$CLIENTINTERFACE:any root=/dev/nfs $params
label=FAI-ANY
image=$mountpoint/vmlinuz
-append=ip=::bootp root=/dev/nfs $params
+append=ip=:$CLIENTINTERFACE:bootp root=/dev/nfs $params
label=FAI-BOOTP
image=$mountpoint/vmlinuz
-append=ip=::dhcp root=/dev/nfs $params
+append=ip=:$CLIENTINTERFACE:dhcp root=/dev/nfs $params
label=FAI-DHCP
image=$mountpoint/vmlinuz
@@ -202,7 +204,7 @@
append=root=/dev/nfs nfsroot=$SERVERIP:$NFSROOT $fixedparams $params
image=$mountpoint/vmlinuz
-append=ip=::rarp root=/dev/nfs $params
+append=ip=:$CLIENTINTERFACE:rarp root=/dev/nfs $params
label=FAI-RARP
EOF
$NFSROOT/sbin/lilo -C $mountpoint/etc/lilo.conf || die lilo failed.
@@ -285,6 +287,7 @@
g) grub=1 ;;
h) usage ;;
i) mkcd=1; cddev=$OPTARG ; sd='';;
+I) CLIENTINTERFACE=$OPTARG ;;
f) mkimage=1; floppydev=$OPTARG ;;
m) mountpoint=$OPTARG ;;
s) TARGETHOST=$OPTARG ;;
Bug#334333: fai-cd installs systems lacking a grub bootloader when using simple examples
On Tue, Oct 18, 2005 at 12:15:12AM +0200, Thomas Lange wrote: install_packages should bepatched to download-only also package names ending with a minus when install_packages is called from fai-mirror. I will try to write a patch. this is definitely not the right solution for the problem; there could be just any reason to have a uninstalled in the package lists (especially, if your $FAI for fai-cd and installations/softupdates is the same). packages should be only pulled onto the fai-cd if there is any positive occurrence of a package... -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329417: please also ignore (no)quota on nfs mounts
Package: mount Version: 2.12p-4 Severity: wishlist Tags: patch please do also silently ignore the quota boolean options for nfs mounts. the attached patch implements this and does also update the manpage to reflect that change. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.12.6-nfsall-xen0 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages mount depends on: ii libblkid1 1.37-2sarge1 block device id library ii libc6 2.3.2.ds1-22.xen.2 GNU C Library: Shared libraries an ii libuuid1 1.37-2sarge1 universally unique id library -- no debconf information 70_nfs_ignore_quota.dpatch Description: application/shellscript
Bug#318258: Dependency problem: pdl requires xlibmesa-glu to install though libglu1-xorg
On Thu, Jul 14, 2005 at 01:42:54PM +0200, Latévi Max LAWSON DAKU wrote: I have recently updated my system, passing from the xserver-xfree86 environment to the one provided by xserver-xorg. This led to the deinstallation of many packages among which the pdl package which I heavily use but which I cannot install no more without getting into trouble for the whole system. Indeed, pdl depends on xlibmesa-glu but this package conflicts with the installed libglu1-xorg whose desinstallation would trigger the desinstallation of the xbase-clients package... I guess that making pdl depends on xlibmesa-glu | libglu1-xorg would solve the problem; my 2 cents.. well, this dependency is generated by dpkg-shlibdeps, so this will be fixed by my next pdl upload to debian, which I am preparing now. -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317279: fai: dpkg --force-confdef in apt.conf
On Thu, Jul 07, 2005 at 01:52:09PM +0200, Roland Rosenfeld wrote: The --force-confdef caused heavy trouble on many systems when locally modified conffiles are overwritten (without any question) by Debian security updates. IMHO the default configuration should always ask me what I want or should at least keep the old (modified) configuration but should never overwrite my changes without asking me! this must be a dpkg bug; in case of locally modified conffiles, --force-confdef should keep the modified file. could you send some log output of this misbehaviour? -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315080: fai uses /fai directory
On Mon, Jun 20, 2005 at 03:44:32PM +0200, Holger Levsen wrote: during installs (and softupdates and...) fai uses /fai to store/mount the fai configdir on the fai client. This clearly violates the FHS (and is similar to #309554). in fact FAI bind-mounts a temporary copy of the configuration, which lives in /tmp/fai-config.XX, to /fai. IMHO Thomas introduced that to be able to store a packages repository within $FAI/files/packages... I suggest using /var/lib/fai/config instead. (On the fai _clients_. And /srv on the server.) my opinion is to remove this mount once and for all. FAI-internal we have $FAI pointing to the configuration space; and storing a package repository within it is a bad hack: in the end, the configuration space is for configuration and not for packages. -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315000: don't run prepareapt on softupdates
On Mon, Jun 20, 2005 at 01:34:32AM +0200, Holger Levsen wrote:
task_prepareapt is (IMO) unneccessarily run during softupdates.
it is necassairy, if you are (ab-)using softupdates for dist-upgrades. But I
agree the current implementation in FAI not ideal, but my proposed changes
were not accepted into FAI ;(
This is bad, as it overwrites (and corrupts) /etc/hosts, /etc/resolv.conf is
only overwritten.
fcopy could really allow more control here.
you're right, that's why I hooked task_prepareapt in the following way:
$FAI/hooks/prepareapt.DEFAULT
#!/bin/bash
# $Id: prepareapt.DEFAULT,v 1.1 2005/05/03 14:16:51 glaweh Exp $
#
# HG: use fcopy for apt preparation
fcopy -i etc/{hosts,hostname,resolv.conf}
fcopy -ri etc/apt
fcopy -ri etc/dpkg
skiptask prepareapt
--
c u
henning
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315000: don't run prepareapt on softupdates
On Mon, Jun 20, 2005 at 12:55:54PM +0200, Holger Levsen wrote: it is necassairy, if you are (ab-)using softupdates for dist-upgrades. Why ? If you do softupdates, your machine has been set up allready. ?! prepareapt copies the dpkg and apt conffiles _before_ messing around with apt; if an updated sources.list points to sarge while it pointed before at woody, you are able to pull your box from woody to sarge without reinstallation. But I agree the current implementation in FAI not ideal, but my proposed changes were not accepted into FAI ;( You proposed this hook or something else ? yup. but as a real replacement to the current task_prepareapt $FAI/hooks/prepareapt.DEFAULT please not as DEFAULT. Maybe in FAIBASE which I propose not to use in default softupdates ;-) that's what _I_ use in the config for my machines here, which is quite different from the fai simple-example. -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315000: don't run prepareapt on softupdates
On Mon, Jun 20, 2005 at 02:53:06PM +0200, Holger Levsen wrote: On Monday 20 June 2005 14:29, you wrote: Why ? If you do softupdates, your machine has been set up allready. ?! prepareapt copies the dpkg and apt conffiles _before_ messing around with apt; if an updated sources.list points to sarge while it pointed before at woody, you are able to pull your box from woody to sarge without reinstallation. Even though this is nice and fancy, it's a bad hack. IMHO you should provide/use classes WOODY and SARGE and use scripts/SARGE to change that's exactly what I'm doing. sources.list on that machine. In task_configure not in task_prepareapt. not really: all software updates/installation takes place _before_ task_configure; re-calling apt-get dist-update and install_packages in task_configure would be a bad hack. task_prepareapt is the place where all package manager configuration should take place; just imagine you add/remove repositories from the sources.list for different classes. I'm aware that your approach is slightly more effective/faster, but I do believe it's to hackish. On softupdates apt is set up allready. No need (and no sane way) of updating it _as_default_. 'correctly' in terms of the state of the last install/softupdate. in terms of the current run it is not. please not as DEFAULT. Maybe in FAIBASE which I propose not to use in default softupdates ;-) that's what _I_ use in the config for my machines here, which is quite different from the fai simple-example. Please keep in mind the scope of the simple examples... (which in a lot of peoples opinion should become part of a default config some day.) this hook is not intended to be merged into the simple examples; it is simply what _I_ am using to circumvent the missing fcopy in task_prepareapt. -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312296: fai: this is more a cosmetic problem than a real one
Package: fai Followup-For: Bug #312296 * BUGFIX:312296 don't fail if $diskvar isn't copied during softupdates, $diskvar isn't written. this is nothing critical, but scripts/FAIBASE/20-save_diskvar fails. this patch makes it even return 0 if $diskvar isn't copied (as it is always the case when softupdate is run) -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Tue Jun 7 10:33:14 CEST 2005 [EMAIL PROTECTED] * BUGFIX:312296 don't fail if $diskvar isn't copied during softupdates, $diskvar isn't written. this is nothing critical, but scripts/FAIBASE/20-save_diskvar fails. this patch makes it even return 0 if $diskvar isn't copied (as it is always the case when softupdate is run) diff -rN -u old-pfai/examples/simple/scripts/FAIBASE/20-save_diskvar new-pfai/examples/simple/scripts/FAIBASE/20-save_diskvar --- old-pfai/examples/simple/scripts/FAIBASE/20-save_diskvar2005-06-07 10:37:12.0 +0200 +++ new-pfai/examples/simple/scripts/FAIBASE/20-save_diskvar2005-06-07 10:32:39.0 +0200 @@ -2,4 +2,4 @@ # save values of boot device and boot partition [ -d $target/etc/fai ] || mkdir -p $target/etc/fai -[ -s $diskvar ] cp $diskvar $target/etc/fai +[ -s $diskvar ] cp $diskvar $target/etc/fai || true
Bug#312128: caused by changed ifupdown
Package: fai Version: 2.8.4 Followup-For: Bug #312128 * BUGFIX: #312128, work around changed ifupdown ifupdown was changed: instead of the file /etc/network/ifstate it uses /etc/network/run/ifstate, while /etc/network/run is a symlink to /dev/shm/network. this fails, of cause, in the FAI nfsroot. quick workaround: bind-mount /tmp to /dev/shm and create the directory /dev/shm/network/ in lib/create_ramdisk -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.11.10-xen0 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages fai depends on: ii libapt-pkg-perl 0.1.13 Perl interface to libapt-pkg ii perl 5.8.4-8Larry Wall's Practical Extraction Mon Jun 6 18:29:58 CEST 2005 [EMAIL PROTECTED] * BUGFIX: #312128, work around changed ifupdown ifupdown was changed: instead of the file /etc/network/ifstate it uses /etc/network/run/ifstate, while /etc/network/run is a symlink to /dev/shm/network. this fails, of cause, in the FAI nfsroot. quick workaround: bind-mount /tmp to /dev/shm and create the directory /dev/shm/network/ in lib/create_ramdisk diff -rN -u old-pfai/lib/create_ramdisk new-pfai/lib/create_ramdisk --- old-pfai/lib/create_ramdisk 2005-06-06 18:42:17.752878000 +0200 +++ new-pfai/lib/create_ramdisk 2005-06-06 18:26:51.0 +0200 @@ -16,6 +16,7 @@ mke2fs -q -m 0 $ramdevice echo ramdisk $ramdevice created mount -n $ramdevice /tmp } +mount --bind /tmp /dev/shm # now create the required subdirectories -mkdir -p /tmp/etc /tmp/target /tmp/var/run/sshd /tmp/var/run/fai /tmp/var/state/discover /tmp/var/lib/discover +mkdir -p /tmp/etc /tmp/target /tmp/var/run/sshd /tmp/var/run/fai /tmp/var/state/discover /tmp/var/lib/discover /dev/shm/network cd/tmp/var mkdir tmp log lock spool
Bug#307631: clutters /tmp and leaves bind mounts
Package: fai Version: 2.8.1 Severity: important Tags: patch * BUGFIX: don't mount $FAI on itself when doing softupdates when $FAI_ROOT is /, $FAI was bind-mounted on itself, so the cleanup at the end of the fai-run failed -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages fai depends on: ii debconf 1.4.30.13 Debian configuration management sy ii libapt-pkg-perl 0.1.13 Perl interface to libapt-pkg ii perl 5.8.4-8Larry Wall's Practical Extraction Tue May 3 18:11:51 CEST 2005 [EMAIL PROTECTED] * BUGFIX: don't mount $FAI on itself when doing softupdates when $FAI_ROOT is /, $FAI was bind-mounted on itself, so the cleanup at the end of the fai-run failed diff -rN -u old-pfai/share/subroutines-linux new-pfai/share/subroutines-linux --- old-pfai/share/subroutines-linux2005-05-03 18:32:25.557839000 +0200 +++ new-pfai/share/subroutines-linux2005-05-03 18:11:19.0 +0200 @@ -143,7 +143,7 @@ echo Updating base # try to mount the config space, since it can also contain Debian Packages # in /fai/files/packages -mount --bind $FAI $FAI_ROOT/$FAI +[ $FAI_ACTION = install ] mount --bind $FAI $FAI_ROOT/$FAI if [ $debug ]; then updatebase | tee -a $LOGDIR/updatebase.log 21 else
Bug#307632: creates /tmp/fai directory unconditionally (insecure tempfile)
Package: fai Version: 2.8.1 Severity: serious Tags: patch * BUGFIX: create /tmp/fai only when DO_INIT_TASKS /tmp/fai was created, but not used when performing softupdates and not removed afterwards basically, this violates policy 10.4, because: Any scripts which create files in world-writeable directories (e.g., in `/tmp') must use a mechanism which will fail if a file with the same name already exists. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages fai depends on: ii debconf 1.4.30.13 Debian configuration management sy ii libapt-pkg-perl 0.1.13 Perl interface to libapt-pkg ii perl 5.8.4-8Larry Wall's Practical Extraction Tue May 3 19:43:52 CEST 2005 [EMAIL PROTECTED] * BUGFIX: create /tmp/fai only when DO_INIT_TASKS /tmp/fai was created, but not used when performing softupdates and not removed afterwards diff -rN -u old-pfai/scripts/fai new-pfai/scripts/fai --- old-pfai/scripts/fai2005-05-03 19:46:32.577839000 +0200 +++ new-pfai/scripts/fai2005-05-03 19:40:47.0 +0200 @@ -111,7 +111,7 @@ # directory where temporary log files are stored # set default value if nothing is set in fai.conf -if [ -z $LOGDIR ]; then +if [ -z $LOGDIR -a $DO_INIT_TASKS -eq 1 ]; then LOGDIR=/tmp/fai mkdir -p $LOGDIR fi
Bug#279232: What about perl-bug #279232?
On Wed, May 04, 2005 at 09:25:06PM +1000, Brendan O'Dea wrote: it could be fixed by introducing a versioned pre-dependency of perl-modules on perl-base while letting perl-base conflict with too old perl-modules, which forces apt to update both packages together; this combination may be highly unstable (conflicts+pre-depends is a loop-like construct), but results in the right behaviour. Given an alternate option I'd really rather not do this. It seems fragile at best, disasterous at worst. thats what I also said in the comments... Given the recent freeze announcement, I'd suggest that regardless of what other fixes are made, a good first step would be to get a fixed doc-base (i.e. one that works with the current stable perl-base only) package into stable-proposed-updates *now*. won't help: Message-ID: [EMAIL PROTECTED] Date: Fri, 29 Apr 2005 19:48:00 +0200 To: debian-devel@lists.debian.org Subject: woody-to-sarge test upgrade From: Bill Allombert [EMAIL PROTECTED] seems like he's been bitten by this bug in connection with defoma If nothing else, this reduces the size of the problem if there's a point release prior to sarge. maybe, maybe not: perl itself is in an unusable state during the update... -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297550: Bugfix
Moin,
sorry for the big diff, but the problem was sitting a lot deeper in the
recursion codel. The attached patch should both clean up the code to make it
actually understandable and fix the aforementioned bug.
--
c u
henning
Wed Apr 13 14:03:50 CEST 2005 [EMAIL PROTECTED]
* BUGFIX:297550 clean up the fcopy recursion code
the File::Find code used in recursive fcopy descended into the ignored
directories and their subdirectories. this failed when a revision control
system keeps subdirectories there (in this case: subversion).
while fixing this bug, the whole File::Find code was brought to a more
readable/debuggable form.
this version differs from the first version sent to [EMAIL PROTECTED]
because it moves the newly introduced %ingnoredirs out of global scope.
diff -rN -u old-pfai/scripts/fcopy new-pfai/scripts/fcopy
--- old-pfai/scripts/fcopy 2005-04-30 09:59:41.815144432 +0200
+++ new-pfai/scripts/fcopy 2005-04-30 09:59:43.104948352 +0200
@@ -342,20 +342,6 @@
exit 0;
}
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-sub rfilter {
-
- # Filter for recursive copying
-
- # are we in a directory ? should we ignore it ?
- my $location=$_;
- (-d and (! grep $location eq $_,@ignoredirs )) or return 0;
- # a directory without subdirs has two hard links
- # don't count @ignoredirs as subdirs
- my $subdirs=(lstat($_))[3] - 2 - grep(-d,@ignoredirs);
- # push leaf
- push @rlist,$File::Find::name unless $subdirs;
-}
-# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# main program
$|=1;
@@ -396,8 +382,20 @@
if ($opt_r) {
foreach (@ARGV) { $_=$source/$_; } # add prefix to list of directories
- File::Find::find(\rfilter,@ARGV);
- foreach (@rlist) { $_=~ s#^$source/##; } # remove prefix from all fines
found
+ my %has_subdirs;
+ my %ignoredirs;
+ map $ignoredirs{$_}=1,@ignoredirs;
+ File::Find::find({
+wanted=sub{ $has_subdirs{$File::Find::dir} |= -d},
+preprocess=sub{grep ! (-d and exists($ignoredirs{$_})),@_}},
+@ARGV);
+ foreach (keys %has_subdirs) {
+unless ($has_subdirs{$_}) {
+ # remove prefix from all files found
+ s#^$source/##;
+ push @rlist,$_;
+}
+ }
warn List of all files found by File::Find::find: @rlist if $debug;
@ARGV = @rlist;
}
Bug#302185: breaks noninteractive installations
On Wed, Apr 06, 2005 at 10:28:03PM +0100, Mark Baker wrote: automatic installations fail because read -p is called after displaying the 'exim 3.x is obsolete' message in postinst _without_ checking for DEBIAN_FRONTEND=noninteractive. this makes the whole machine wait during the installation and thus renders the system unusable It's not just that one, there were many other places where it did this. However, they were all on upgrades, so perhaps weren't much of a problem as people don't tend to do non-interactive upgrades (don't they? I'd have thought it was a fairly common thing to do from a cron job or the like). people do noninteractive updates. at least the ones having more than 2 machines ;) -- c u henning -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302185: breaks noninteractive installations
Package: exim Version: 3.36-14 Severity: critical automatic installations fail because read -p is called after displaying the 'exim 3.x is obsolete' message in postinst _without_ checking for DEBIAN_FRONTEND=noninteractive. this makes the whole machine wait during the installation and thus renders the system unusable -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages exim depends on: ii cron3.0pl1-87management of regular background p ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libdb3 3.2.9-22 Berkeley v3 Database Libraries [ru ii libident0.22-3 simple RFC1413 client library - ru ii libldap22.1.30-3 OpenLDAP libraries ii libpam0g0.76-22 Pluggable Authentication Modules l ii libpcre35.0-1Perl 5 Compatible Regular Expressi -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279232: Perl related upgrade problems woody - sarge
Moin, sorry, didn't send this to the bts last time. My patched packages are since then working on about 50 computers at work. Another thought about this: this problem will re-appear if perl is upgraded to 6.0 (or whatever will be the next upstream release). - Forwarded message from Henning Glawe [EMAIL PROTECTED] - Date: Mon, 13 Dec 2004 18:55:03 +0100 To: Frank Lichtenheld [EMAIL PROTECTED] Subject: Re: Bug#279232: Perl related upgrade problems woody - sarge From: Henning Glawe [EMAIL PROTECTED] X-Bogosity: No, tests=bogofilter, spamicity=0.00, version=0.17.5, scanned=2004-12-13T17:54:44Z, spam_cutoff=9.90e-01 On Mon, Dec 13, 2004 at 05:55:10PM +0100, Frank Lichtenheld wrote: On Mon, Dec 13, 2004 at 05:07:15PM +0100, Henning Glawe wrote: What seems to be working around the problem somehow is the following change: - perl-base: Conflicts: perl-modules ( 5.8.4) (so perl-modules is forced to be updated in the next steps) - perl-modules: Pre-Depends: perl-base (= 5.8.4) with these changes, apt-get dist-upgrade is forced into the following order, which fixes the problem of not-matching perl-base and perl-modules during batch updates: Remove perl-modules 5.6.1 Replace perl-base5.6.1 with 5.8.4 Setupperl-base5.8.4 Unpack perl-modules 5.8.4 Sorry, but that can't be. Remove perl-modules 5.6.1 and Unpack perl-modules 5.8.4 are one step, that can't be distinct, du you mean Replace and Setup instead? no. my patched perl-base 5.8 conflicts with the old perl-modules. apt-get dist-upgrade resolves the situation exacly like shown. Here is the log output (stdout and stderr combined): apt-get dist-upgrade -- [...] Removing libi18n-langtags-perl ... dpkg: perl-modules: dependency problems, but removing anyway as you request: dpkg-dev depends on perl-modules; however: Package perl-modules is to be removed. mrtg depends on perl-modules (= 5.6.0). dh-make-perl depends on libpod-parser-perl; however: Package libpod-parser-perl is not installed. Package perl-modules which provides libpod-parser-perl is to be removed. Removing perl-modules ... tar: ./control: time stamp 2004-12-13 15:03:59 is 4351 s in the future (Reading database ... 138752 files and directories currently installed.) Preparing to replace perl-base 5.6.1-8.7 (using .../perl-base_5.8.4-5.1_i386.deb) ... Unpacking replacement perl-base ... Setting up perl-base (5.8.4-5.1) ... tar: ./control: time stamp 2004-12-13 16:15:15 is 8620 s in the future Selecting previously deselected package perl-modules. (Reading database ... 138741 files and directories currently installed.) Unpacking perl-modules (from .../perl-modules_5.8.4-5.1_all.deb) ... Selecting previously deselected package liblocale-gettext-perl. [...] My modified packages are the ones with the above changes: --- apt-cache show perl-base perl-modules -- [...] Package: perl-base Essential: yes Priority: required Section: base Installed-Size: 1902 Maintainer: Brendan O'Dea [EMAIL PROTECTED] Architecture: i386 Source: perl Version: 5.8.4-5.1 Replaces: perl-5.005-base ( 6), perl-5.6-base ( 6), perl ( 5.8.0-9), perl-modules ( 5.8.4-5), libperl5.8 ( 5.8.0-20), libscalar-list-utils-perl, libclass-multimethods-perl ( 1.70-4) Provides: perl5-base, perlapi-5.8.0, perlapi-5.8.1, perlapi-5.8.2, perlapi-5.8.3, perlapi-5.8.4, data-dumper, libscalar-list-utils-perl Pre-Depends: libc6 (= 2.3.2.ds1-4) Suggests: perl Conflicts: perl-5.004-base ( 6), perl-5.005-base ( 6), perl-5.6-base ( 6), data-dumper, autoconf2.13 ( 2.13-45), libscalar-list-utils-perl ( 1:1.13-1), perl-modules ( 5.8.4-1) Filename: sarge-workarounds/perl-base_5.8.4-5.1_i386.deb Size: 751834 MD5sum: 7efbb33a7b57cf60b8d29340668113d9 Description: The Pathologically Eclectic Rubbish Lister A scripting language with delusions of full language-hood, Perl is used in many system scripts and utilities. . This is a stripped down Perl with only essential libraries. To make full use of Perl, you'll want to install the `perl', `perl-modules' and optionally `perl-doc' packages which supplement this one. Package: perl-modules Priority: standard Section: perl Installed-Size: 10317 Maintainer: Brendan O'Dea [EMAIL PROTECTED] Architecture: all Source: perl Version: 5.8.4-5.1 Replaces: libpod-parser-perl, libansicolor-perl, libfile-temp-perl, libnet-perl, libattribute-handlers-perl, libcgi-pm-perl, libi18n-langtags-perl, liblocale-maketext-perl, libmath-bigint-perl, libnet-ping-perl, libtest-harness-perl, libtest-simple-perl, liblocale-codes-perl Provides: libpod-parser-perl, libansicolor-perl, libfile-temp-perl, libnet-perl, libattribute-handlers-perl, libcgi-pm-perl, libi18n-langtags-perl, liblocale-maketext-perl, libmath-bigint-perl, libnet-ping-perl, libtest-harness-perl, libtest-simple-perl, liblocale-codes-perl Depends: perl (= 5.8.4-1) Pre-Depends: perl-base (= 5.8.4-1
Bug#291721: if autofs stop is called on apm suspend, it should be restarted when resuming
Package: autofs Version: 4.1.3-8 Severity: normal Tags: patch After suspending my laptop, autofs didn't work any more. thats because it was explicitly stopped in /etc/apm/event.d/autofs when a suspend event occurs. shouldn't it be restarted when resuming ? I modified the offending script and now it does the right thing: -- /etc/apm/event.d/autofs with start-on-resume #!/bin/sh set -e if [ $1 = suspend ]; then # unmount any automounted filesystems when suspending invoke-rc.d autofs stop fi if [ $1 = resume ]; then # unmount any automounted filesystems when suspending invoke-rc.d autofs start fi -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9-2-686 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages autofs depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
