Bug#580172: libgdal-doc suggests libgdal1-1.6.0 when libgdal1-1.6.0 already installed
Package: libgdal-doc Version: 1.6.3-3 Severity: minor Tags: squeeze A very minor error, though a bit puzzling. Breaks nothing - just letting you know libgdal-doc suggests libgdal1-1.6.0 (=1.6.3-3) but: a. this is already installed b. choosing libgdal1-1.6.0 via the 'mark suggetsted in synaptic and get informed that it cannot be installed due to unresolvable dependencies 'libgdal1-1.6.0:' (same for aptitude) I had a look at the control file but I cannot tell what is happening as it uses subsitution tvars. Cheers adrian -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_NZ.utf8, LC_CTYPE=en_NZ.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash libgdal-doc depends on no packages. libgdal-doc recommends no packages. Versions of packages libgdal-doc suggests: ii libgdal1-1.6.01.6.3-3+b1 Geospatial Data Abstraction Librar -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579990: custom atlas build fails
Package: atlas Version: 3.8.3-21 Hi The cpufrequtils test loop that is part of the 'custom' rule fails due to the bash-tastic for-loop syntax. I have replaced it with a while loop in the attached patch. I've tested it and it works fine. A less important 'gotcha' is that running the custom rule means that build dependency checks are bypassed. If the uninstalled dependency is say lapack-dev, then a 20+ minute compile is a long time to waitto discover it is borked. (I am sighing from personal experience). The following test works ($$deps would be the list of build-dep packages). I am, however, unsure how one would get $$deps from within the rules makefile. if test -n $$(dpkg-query -W $$deps 21 /dev/null); then\ echo build dependencies are not fully installed;\ echo aborting;\ exit 1;\ fi --- debian/rules 2010-05-03 09:02:33.624063782 +1200 +++ debian/rules.edit 2010-05-03 09:00:41.570399790 +1200 @@ -110,14 +110,17 @@ custom-stamp: rm -f configure-stamp - ncpu=$$(LANG=C cpufreq-info | grep analyzing CPU -c); \ - for (( cpu=0 ; cpu $$ncpu ; cpu++)); do \ - if test $$(cpufreq-info -p 21 /dev/null; echo $$?) -eq 0 -a -z $$(LANG=C cpufreq-info -p -c $$cpu | grep performance) ; then \ - echo frequency governor on cpu=$$cpu is not set to 'performance'; \ + ncpu=$$(LANG=C cpufreq-info | grep analyzing CPU -c);\ + cpu=0;\ + while test $$cpu -lt $$ncpu ; do\ + if test $$(cpufreq-info -p 21 /dev/null; echo $$?) \ + -eq 0 -a -z $$(LANG=C cpufreq-info -p -c $$cpu | grep performance) ; then \ + echo frequency governor on cpu=$$ncpu is not set to 'performance'; \ echo run: 'sudo cpufreq-set -g performance -c cpu#' for each cpu; \ echo aborting atlas build; \ exit 1; \ fi; \ + cpu=$$((cpu+1)) ;\ done # Here, the trick is pretty simple:
Bug#573901: [latexdraw] choice of jre in wrapper script
Package: latexdraw Version: 2.0.6+1-1 Severity: minor The wrapper script /usr/bin/latexdraw is set up to ignore alternatives settings and serach for jre's. At present the script sequentially checks sun-java then openjdk, so if both are installed the openjdk will always be chosen. The speed and rendering performance of latexdraw are far superior when run under sun-java. i.e sun-java should really be the default choice when available. The fix is to simply reverse the order they are searched in the wrapper script change: t=/usr/lib/jvm/java-6-sun test -d $t JAVA_HOME=$t t=/usr/lib/jvm/java-6-openjdk test -d $t JAVA_HOME=$t to: t=/usr/lib/jvm/java-6-openjdk test -d $t JAVA_HOME=$t t=/usr/lib/jvm/java-6-sun test -d $t JAVA_HOME=$t Cheers Adrian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571322: closed by Sylvestre Ledru sylves...@debian.org (Bug#571322: fixed in atlas 3.8.3-10)
Hi Sylvestre Had issues with the cpufreqtest * sh didn't like the for loop syntax - too bashtastic I am guessing. In the attached patch I have changed it to a while loop which works * the test for cupfrequitils failed because the command output got in the way test $$(cpufreq-info -p; echo $$?) ... changed it to: test $$(cpufreq-info -p /dev/null; echo $$?) ... I had a think about how you could skip the test if necessary. I added a couple of new rules so that it works a such: custom: custom-cpufreq custom-stamp test then build custom-nocpufreqtest: custom-stamp bypass test and build custom-cpufreqtest: moved the test here custom-stamp: run build Do you need me to put this through as a bug report? Adrian On 03/03/10 20:39, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the atlas package: #571322: [atlas] custom build improvements It has been closed by Sylvestre Ledrusylves...@debian.org. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Sylvestre Ledrusylves...@debian.org by replying to this email. --- atlas-3.8.3/debian/rules 2010-03-04 14:44:42.0 +1300 +++ atlas-3.8.3_edit/debian/rules 2010-03-04 15:01:41.787916163 +1300 @@ -85,22 +85,46 @@ -v 2 \ -Si cputhrchk 0 -custom: custom-stamp +#build custom with cpu frequency test to ensure +custom: custom-cpufreqtest custom-stamp -# Build a custom package optimized for the current arch -custom-stamp: - rm -f configure-stamp +#build custom without cpu frequency test +custom-nocpufreqtest: custom-stamp +# run cpufreq-utils test +custom-cpufreqtest: + # Ensure that cpu frequency scaling is switched off and cpu(s) are running + # at max clock speed (i.e. governor=performance) + # This is required for ATLAS auto-tuning to work correctly + # and produce the most highly optimised libraries - the entire point + # of building a custom package. + # + # If cpufreq-utils causes problems or is unavailable for a given + # architecture/hardware then run 'custom-nocpufreqtest' to skip this test + ncpu=$$(LANG=C cpufreq-info | grep analyzing CPU -c); \ - for (( cpu=0 ; cpu $$ncpu ; cpu++)); do \ - if test $$(cpufreq-info -p; echo $$?) -eq 0 -a -z $$(LANG=C cpufreq-info -p -c $$cpu | grep performance) ; then \ + cpu=0; \ + while test $$cpu -lt $$ncpu; do \ + if test $$(cpufreq-info -p /dev/null; echo $$?) -eq 0 -a -z $$(LANG=C cpufreq-info -p -c $$cpu | grep performance) ; then \ + echo ###; \ echo frequency governor on cpu=$$cpu is not set to 'performance'; \ + echo ATLAS auto-tuning requires the cpu clock speed(s) to be set at maximum; \ + echo ; \ echo run: 'sudo cpufreq-set -g governor -c cpu#' for each cpu; \ + echo ; \ + echo If you wish to skip the cpu frequency test, then use the; \ + echo make rule 'custom-nocpufreq' instead of 'custom'; \ + echo ; \ echo aborting atlas build; \ exit 1; \ fi; \ + cpu=$$(expr $$cpu + 1); \ done +# Build a custom package optimized for the current arch +custom-stamp: + rm -f configure-stamp + # Here, the trick is pretty simple: # * We don't want to build all the optimized version of Atlas. Just the # one for the current CPU @@ -111,7 +135,7 @@ # therefor, leaving the choice of the optimization to Atlas # * After that, we fall back to the normal build procedure by calling # debian/rules itself (yep, recursively) - + # Remove all the other archs in this case sed '/AFTER THAT/q' $(CURDIR)/debian/control.in $(CURDIR)/debian/control dch --local='+custom' custom build on: `uname -a` @@ -247,7 +271,7 @@ dh_installdeb -a dh_shlibdeps -a -l $$(pwd) -.PHONY: build build-indep build-indep-stamp build-arch build-arch-stamp check clean binary binary-indep binary-arch configure-stamp configure custom custom-stamp +.PHONY: build build-indep build-indep-stamp build-arch build-arch-stamp check clean binary binary-indep binary-arch configure-stamp configure custom custom-stamp custom-nocpufreqtest custom-cpufreqtest get-orig-source:
Bug#571322: [atlas] custom build improvements
Package: atlas Version: 3.8.3-9 Hi Sylvestre Sorry about the delay in submitting these. 1. There needs to be a way of incrementing the version for custom builds otherwise the custom build will be superseded by the generic versions in the repo. I changed debian/rules:|custom-stamp| and it seems to work. | custom-stamp: rm -f configure-stamp # Here, the trick is pretty simple: # * We don't want to build all the optimized version of Atlas. Just the # one for the current CPU # * We override ARCHS by base__ # * Base is the name of the package (libatlas3gf-base) # * __ is provided to have the right expression # * the regexp will consider that atlasArch and atlasISA are empty # therefor, leaving the choice of the optimization to Atlas # * After that, we fall back to the normal build procedure by calling # debian/rules itself (yep, recursively) # incerment version with a local suffix to prevent custom package being # superseded and clobbered by the generic pre-built atlas packages that dch -U --local='+custom' custom build on `uname -a` # Remove all the other archs in this case sed '/AFTER THAT/q' $(CURDIR)/debian/control.in $(CURDIR)/debian/control debian/rules ARCHS=base__ binary touch $@| 2. Atlas timing needs th cpu clock to be set to the maximum - dynamic frequency mechanisms should be disabled. So you need to add 'cpufrequtils' as a build dependency for custom builds. There should then be a check using 'cpufreq-info' to make sure the cpu governer is set to 'performance'. Not much of a makefile programmer, but a bash style test would be: |ncpu=$(cpufreq-info | grep analyzing CPU -c) ||for (( cpu=0 ; cpu $ncpu ; cpu++)); do if [ -z $(cpufreq-info -p -c $cpu | grep performance) ]; then echo frequency governor on cpu=$cpu is not set to 'performance' echo run: 'sudo cpufreq-set -g governor -c cpu#' for each cpu echo aborting atlas build exit (1) |fi done Adrian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568945: [netcdf] dev libraries built without PIC support
Package: netcdf Version: 4.1~beta2 Built the latest ver of netcdf from experimental on testing because I need to build python-netcdf4 which depends on latest netcdf. Pkgs build fine, however compiling python-netcdf4 fails due to non-relocatable symbols in libnetcdf (i.e. the usual pic errors) Tried correcting the problem by specifying --enable-pic flag in debian/rules (i.e. DEB_CONFIGURE_EXTRA_FLAGS := . --enable-pic) python-netcdf4 still fails. I have since built netcdf 4.1 from upstream source (under /usr/local) using the same configure flags as specified in debian/rules (+--enable-pic). python-netcdf4 now compiles without error. Appears to be a packaging error somewhere Adrian Squeeze 2.6.32-trunk-amd64 P.S. python-netcdf4 fails when linking to libs fromm libnetcdf-dev: = gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -fPIC build/temp.linux-x86_64-2.5/netCDF4.o -lnetcdf -lhdf5 -lhdf5_hl -lz -o build/lib.linux-x86_64-2.5/netCDF4.so /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libnetcdf.a(nc4attr.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libnetcdf.a: could not read symbols: Bad value collect2: ld returned 1 exit status /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libnetcdf.a(nc4attr.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libnetcdf.a: could not read symbols: Bad value collect2: ld returned 1 exit status error: Command gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -fPIC build/temp.linux-x86_64-2.5/netCDF4.o -lnetcdf -lhdf5 -lhdf5_hl -lz -o build/lib.linux-x86_64-2.5/netCDF4.so failed with exit status 1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555462: This bug should be fixed
Well its been 1-1/2 months and there is no sign of 3.4.4 in sid or experimental. This bug renders samba share browsing unusable. I have no stats to back this up, but I am pretty sure that share browsing is one of the most widely used aspects of samba. I encountered this bug just yesterday. Apart from being really annoying, the repeated login failures caused my account to be locked which meant no server access, no internet, no email. Its a good thing it didn't happen today otherwise I would have been without any of these services until 5 January. I understand that this is testing, however if you distribute broken packages and won't fix them when the fix is trivial (took me 1 minute + build time), then you will find that users will avoid using testing. Then how will any testing be done? Adrian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561299: custom build creates empty /etc/ld.so.conf.d/atlas.conf
Subject: custom build creates empty /etc/ld.so.conf.d/atlas.conf Package: atlas Version: 3.8.3 Justification: breaks unrelated software Severity: critical -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash I am backporting latest atlas to testing. Build completes without error, however install creates an empty /etc/ld.so.conf.d/atlas.conf. Atlas is then not in linker cache and all dependent packages fail. Manually inserting appropriate path plus running ldconfig resolves issues. Since no package explicitly owns /etc/ld.so.conf.d/atlas.conf i am guessing this is an install script bug. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551689: atlas (experimental) - packaging error
Package: atlas Version: 3.8.3 (experimental) There is a packaging error for amd64 builds in debian/control libatlas3gf-amd64sse3-dev and libatlas-corei7sse3-dev erroneously depend on libatlas-core2sse3. should be libatlas3gf-amd64sse3 and libatlas-corei7sse3 respectively editing control fixes issue Also in debian/rules we have # see what do we do with the amd64 / intel 64 ifeq ($(DEB_HOST_ARCH_CPU),amd64) # 64 bits MODE_BITWIDTH = 64 ARCHS += amd64sse3_20_28 core2sse3_17_28 corei7sse3_18_28 endif however core2sse3_17_28 is explicitly a 386 package in debian/control -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
