Bug#886679: ITA: coccinelle -- semantic patching tool for C
Hi, I didn't see this error. I guess you've tried debhelper compat level 12 that runs dh_dwz. Both dwz and debhelper packages seem to have some bug reports related to dh_dwz failures. Regards, Eugeniy Meshcheryakov 20 05 2019 о 14:37 -0300 eamanu15 . написав(-ла): > Hello Євгеній, > > I am working on the ITA coccinelle. > I will need permission on salsa to work on the package. I will write to the > team. > I am having some problems building the package : > > dwz: Error mmapping multi-file temporary files > dh_dwz: dwz -q > -mdebian/coccinelle/usr/lib/debug/.dwz/x86_64-linux-gnu/coccinelle.debug > -M/usr/lib/debug/.dwz/x86_64-linux-gnu/coccinelle.debug -- > debian/coccinelle/usr/bin/spatch debian/coccinelle/usr/bin/spgen returned > exit code 1 > make: *** [debian/rules:20: binary] Error 2 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit > status 2 > debuild: fatal error at line 1182: > dpkg-buildpackage -us -uc -ui -i -I -i.git/ -I.git failed > gbp:error: 'env QUILT_PATCHES=debian/patches quilt push -a; debuild > -i\.git/ -I.git' failed: it exited with 29 > > Do you had this problem? > > Regards > > -- > Arias Emmanuel > http://eamanu.com > Github/Gitlab; @eamanu > Debian: @eamanu-guest signature.asc Description: PGP signature
Bug#886714: make[8]: no: Command not found
Hi, 9 січня 2018 о 21:02 +0100 Ralf Treinen написав(-ла): > Hello, > > On Tue, Jan 09, 2018 at 08:45:42AM +0100, Mathieu Malaterre wrote: > > > For some reason coccinelle FTBFS on mips*, it fails with: > > > > make[8]: Entering directory '/<>/commons' > > /usr/bin/ocamlc -unsafe -I ocamlextra -c ocamlextra/dumper.mli > > no -unsafe -I ocamlextra -c commands.ml > > make[8]: no: Command not found > > mips and mipsel are the two architectures among the release architectures > for which ocaml only provides compilation to bytecode. Without having > looked into the makefile this smells a lot like a mistake in a test > of existence of native-code compilation or not. You are right, the configure option name was changed so compiler selection was not working correctly. > > -Ralf. > signature.asc Description: PGP signature
Bug#803195: RFA: spark -- SPARK programming language toolset
I know about the new version, I also tried to compile it for Debian, but it was alsways failing either because of internal compiler error or other reasons. And now I just have no time for packaing it. 28 жовтня 2015 о 09:47 + Florian Schanda написав(-ла): > Hi, > > I am one of the SPARK developers. These days there are two revisions of SPARK > - a legacy version and the new ada-2012 based one. I would recommend to only > package the newer one (spark 2014 -- http://spark-2014.org). > > If there is anything I can do to help with this, please let me know. > > Florian > signature.asc Description: PGP signature
Bug#793211: swi-prolog 7.2 breaks the ppl prolog bindings
Hi Jan, The test suite was disabled in ppl so swi-prolog did migrate to testing. I see Ubuntu also got this version. So it is not so bad anymore. It would be good to fix this some time anyway. I may look at it this weekend. Regards, Eugeniy 14 серп. 2015 09:55 Jan Wielemaker j.wielema...@vu.nl пише: Dear all, I've returned from holidays. This issue seems a show stopper getting SWI-Prolog 7.2 into Debian and its offspring. What is the status? Can I help? Concerning the build fails on amd64, I guess I can reproduce this. Cheers -- Jan On 07/23/2015 09:18 PM, Eugeniy Meshcheryakov wrote: Hello Jan, I've got the following bug report from a Debian developer. Do you have any idea how to fix it? This issue prevents swi-prolog from migrating to Debian testing. The original bug report for PPL is available here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787486 This bug report is archived here (also contains the log file): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793211 Regards, Eugeniy Meshcheryakov 22 липня 2015 о 15:09 +0200 Matthias Klose написав(-ла): Package: src:swi-prolog Version: 7.2.0-2 Severity: important swi-prolog 7.2 breaks the ppl prolog bindings, such that ppl has to be built with -fpermissive. However running the tests reveals that these are then broken. swi-prolog 6 works fine. See #787486 for the ppl issue. [...] Making check in Prolog make[4]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog' /usr/bin/make check-recursive make[5]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog' Making check in . make[6]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog' make[6]: Nothing to be done for 'check-am'. make[6]: Leaving directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog' Making check in tests make[6]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests' /usr/bin/make check-local make[7]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests' /usr/bin/m4 --prefix-builtin -I../.. \ -I. -I./.. -I./../.. \ ./ppl_interface_generator_prolog_generated_test_pl.m4 \ ppl_prolog_generated_test_blob ../../../utils/cm_cleaner.sh ./ppl_prolog_generated_test_blob ../../../utils/cm_splitter.sh ./ppl_prolog_generated_test_blob rm -f ppl_prolog_generated_test_blob echo timestamp ppl_prolog_generated_test.stamp make[7]: Leaving directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests' make[6]: Leaving directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests' Making check in SWI make[6]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/SWI' /usr/bin/make ppl_pl pl_clpq pl_clpq2 make[7]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/SWI' x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../interfaces -I../../../interfaces/Prolog -I/interfaces/Prolog -I../../../src -I/usr/lib/swi-prolog/include -I/usr/include/pl -D_FORTIFY_SOURCE=2 -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall -MT ppl_pl.o -MD -MP -MF .deps/ppl_pl.Tpo -c -o ppl_pl.o ppl_pl.cc x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../interfaces -I../../../interfaces/Prolog -I/interfaces/Prolog -I../../../src -I/usr/lib/swi-prolog/include -I/usr/include/pl -D_FORTIFY_SOURCE=2 -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall -MT pl_clpq.o -MD -MP -MF .deps/pl_clpq.Tpo -c -o pl_clpq.o pl_clpq.cc mv -f .deps/ppl_pl.Tpo .deps/ppl_pl.Po mv -f .deps/pl_clpq.Tpo .deps/pl_clpq.Po /usr/bin/swipl-ld -pl /usr/bin/swipl -cc x86_64-linux-gnu-gcc -c++ x86_64-linux-gnu-g++ -ld x86_64-linux-gnu-g++ \ -ld-options`echo '' -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall | tr /` \ -o ppl_pl .libs/libppl_swiprolog.a ppl_pl.o \ -L../../../src/.libs \ -lppl -lgmpxx -lgmp /usr/bin/swipl-ld -pl /usr/bin/swipl -cc x86_64-linux-gnu-gcc -c++ x86_64-linux-gnu-g++ -ld x86_64-linux-gnu-g++ \ -ld-options`echo '' -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall | tr /` \ -o pl_clpq .libs/libppl_swiprolog.a pl_clpq.o \ ./pl_clpq.pl ./../tests/clpq.pl \ -L../../../src/.libs \ -lppl -lgmpxx -lgmp /usr/bin/swipl-ld -pl /usr/bin/swipl -cc x86_64-linux-gnu-gcc -c++ x86_64-linux-gnu-g++ -ld x86_64-linux-gnu-g++ \ -ld-options`echo '' -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall | tr /` \ -o pl_clpq2 .libs/libppl_swiprolog.a pl_clpq.o \ ./pl_clpq.pl
Bug#793211: swi-prolog 7.2 breaks the ppl prolog bindings
Hello Jan, I've got the following bug report from a Debian developer. Do you have any idea how to fix it? This issue prevents swi-prolog from migrating to Debian testing. The original bug report for PPL is available here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787486 This bug report is archived here (also contains the log file): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793211 Regards, Eugeniy Meshcheryakov 22 липня 2015 о 15:09 +0200 Matthias Klose написав(-ла): Package: src:swi-prolog Version: 7.2.0-2 Severity: important swi-prolog 7.2 breaks the ppl prolog bindings, such that ppl has to be built with -fpermissive. However running the tests reveals that these are then broken. swi-prolog 6 works fine. See #787486 for the ppl issue. [...] Making check in Prolog make[4]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog' /usr/bin/make check-recursive make[5]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog' Making check in . make[6]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog' make[6]: Nothing to be done for 'check-am'. make[6]: Leaving directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog' Making check in tests make[6]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests' /usr/bin/make check-local make[7]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests' /usr/bin/m4 --prefix-builtin -I../.. \ -I. -I./.. -I./../.. \ ./ppl_interface_generator_prolog_generated_test_pl.m4 \ ppl_prolog_generated_test_blob ../../../utils/cm_cleaner.sh ./ppl_prolog_generated_test_blob ../../../utils/cm_splitter.sh ./ppl_prolog_generated_test_blob rm -f ppl_prolog_generated_test_blob echo timestamp ppl_prolog_generated_test.stamp make[7]: Leaving directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests' make[6]: Leaving directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests' Making check in SWI make[6]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/SWI' /usr/bin/make ppl_pl pl_clpq pl_clpq2 make[7]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/SWI' x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../interfaces -I../../../interfaces/Prolog -I/interfaces/Prolog -I../../../src -I/usr/lib/swi-prolog/include -I/usr/include/pl -D_FORTIFY_SOURCE=2 -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall -MT ppl_pl.o -MD -MP -MF .deps/ppl_pl.Tpo -c -o ppl_pl.o ppl_pl.cc x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../interfaces -I../../../interfaces/Prolog -I/interfaces/Prolog -I../../../src -I/usr/lib/swi-prolog/include -I/usr/include/pl -D_FORTIFY_SOURCE=2 -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall -MT pl_clpq.o -MD -MP -MF .deps/pl_clpq.Tpo -c -o pl_clpq.o pl_clpq.cc mv -f .deps/ppl_pl.Tpo .deps/ppl_pl.Po mv -f .deps/pl_clpq.Tpo .deps/pl_clpq.Po /usr/bin/swipl-ld -pl /usr/bin/swipl -cc x86_64-linux-gnu-gcc -c++ x86_64-linux-gnu-g++ -ld x86_64-linux-gnu-g++ \ -ld-options`echo '' -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall | tr /` \ -o ppl_pl .libs/libppl_swiprolog.a ppl_pl.o \ -L../../../src/.libs \ -lppl -lgmpxx -lgmp /usr/bin/swipl-ld -pl /usr/bin/swipl -cc x86_64-linux-gnu-gcc -c++ x86_64-linux-gnu-g++ -ld x86_64-linux-gnu-g++ \ -ld-options`echo '' -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall | tr /` \ -o pl_clpq .libs/libppl_swiprolog.a pl_clpq.o \ ./pl_clpq.pl ./../tests/clpq.pl \ -L../../../src/.libs \ -lppl -lgmpxx -lgmp /usr/bin/swipl-ld -pl /usr/bin/swipl -cc x86_64-linux-gnu-gcc -c++ x86_64-linux-gnu-g++ -ld x86_64-linux-gnu-g++ \ -ld-options`echo '' -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall | tr /` \ -o pl_clpq2 .libs/libppl_swiprolog.a pl_clpq.o \ ./pl_clpq.pl ./../tests/clpq2.pl \ -L../../../src/.libs \ -lppl -lgmpxx -lgmp Warning: /scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests/clpq.pl:208: Singleton variable in branch: File_Name Warning: /scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests/clpq2.pl:293: Singleton variable in branch: File_Name Warning: /scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests/clpq.pl:486:10: Deprecated ... \newlinewhite*. Use \c Warning: /scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests/clpq.pl:487:49: Deprecated ... \newlinewhite*. Use \c Warning: /scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests
Bug#790619: swi-prolog: v7 is a development release and breaks some predicates
Hi, I was asked by the swi-prolog upstream maintainer to package this version as stable. The downloads page on www.swi-prolog.org also describes 7.2.x as stable release. Maybe you are looking at wrong (old) website? I'm not sure if modifications are intentional or not, but either you can ask upstream, or give me an example, so I can ask. Regards, Eugeniy Meshcheryakov 30 черв. 2015 2:24 пп Olivier Sallou olivier.sal...@irisa.fr пише: Package: swi-prolog Version: 7.2.0-2 Severity: normal Dear Maintainer, swi-prolog in unstable is in v7, however, in swi-prolog wbe site, this is a development branch. Stable release is still 6.x. Is it an intended behavior ? It happens that some modifications in predicates (print), changes the output from 6.x. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/1 CPU core) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages swi-prolog depends on: ii swi-prolog-nox 7.2.0-2 ii swi-prolog-x7.2.0-2 swi-prolog recommends no packages. Versions of packages swi-prolog suggests: pn prolog-el none -- no debconf information
Bug#767740: FTBFS: mips: segmentation fault in check_pl
severity important 767740 thanks Hello, This happens sometimes on mips buildds, but it is hard to reproduce on gabrielli.debian.org. I've uploaded a manualy built package for now. I'm lowering the bug sevirity to allow the package to migrate to testing. Regards, Eugeniy Meshcheryakov 2 листопада 2014 о 11:25 +0100 Ondřej Surý написав(-ла): Package: src:swi-prolog Version: 6.6.6-5 Severity: serious Justification: fails to build from source (but built successfully in the past) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer(s), your package FTBFS on mips with: make[3]: Entering directory '/«PKGBUILDDIR»/packages/jpl/src/java' javac -source 1.4 -target 1.4 -classpath ../../jpl.jar:/usr/share/java/junit.jar jpl/test/Family.java jpl/test/FetchBigTree.java jpl/test/FetchLongList.java jpl/test/Ga2.java jpl/test/Ga.java jpl/test/Garbo.java jpl/test/Masstest.java jpl/test/MaxObjects.java jpl/test/ShadowA.java jpl/test/ShadowB.java jpl/test/SyntaxError.java jpl/test/Test.java jpl/test/TestJUnit.java jpl/test/TestOLD.java warning: [options] bootstrap class path not set in conjunction with -source 1.4 1 warning jar cf ../../jpltest.jar jpl/test/Family.class jpl/test/FetchBigTree.class jpl/test/FetchLongList.class jpl/test/Ga2.class jpl/test/Ga.class jpl/test/Garbo.class jpl/test/Masstest.class jpl/test/MaxObjects.class jpl/test/ShadowA.class jpl/test/ShadowB.class jpl/test/SyntaxError.class jpl/test/Test.class jpl/test/TestJUnit.class jpl/test/TestOLD.class make[3]: Leaving directory '/«PKGBUILDDIR»/packages/jpl/src/java' if [ -r jpltest.jar ]; then \ LD_LIBRARY_PATH=/usr/lib/jvm/java-7-openjdk-mips/jre/lib/mips/server:/usr/lib/jvm/java-7-openjdk-mips/jre/lib/mips ../swipl.sh --traditional -q -f test_jpl.pl -g run_tests,halt -t 'halt(1)' ; \ else \ echo No jpltest.jar; maybe junit is not installed? ; \ fi JUNIT=/usr/share/java/junit.jar JAVA=java JAVA_PRELOAD=/usr/lib/jvm/java-7-openjdk-mips/jre/lib/mips/server/libjsig.so ./test-java.sh Welcome to SWI-Prolog (Multi-threaded, 32 bits, Version 6.6.6) Copyright (c) 1990-2013 University of Amsterdam, VU Amsterdam SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. Please visit http://www.swi-prolog.org for details. For help, use ?- help(Topic). or ?- apropos(Word). % halt Segmentation fault make[2]: *** [check_pl] Error 139 make[2]: *** Waiting for unfinished jobs Makefile:59: recipe for target 'check_pl' failed . . .. Time: 34.758 OK (104 tests) make[1]: *** [override_dh_auto_test] Error 2 Full build log can be found here: https://buildd.debian.org/status/fetch.php?pkg=swi-prologarch=mipsver=6.6.6-5stamp=1414864478 (Perhaps you can skip the tests on mips for now to allow swi-prolog to migrate to testing?) Cheers, Ondrej - -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (700, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJUVgaPXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMEI5MzNEODBGQ0UzRDk4MUEyRDM4RkIw Qzk5QjcwRUY0RkNCQjA3AAoJEAyZtw70/LsHhU0P/07lxetp24EnMzh/G+WBhICj 2acZcLYoG7iojeE/4k6OKFNYnnRM6MlnVYeOSjNLRWeR4Ei3y71Kf1FiPUtiFi1l XGR59jjbaZkJcqoQAhIrQdunKGiAJU/mmzxbDQDjZehwnZeCWTeprn0DtWJBRpSl X1R1VT6jW0xkuGBD69+7I2OUhMRdXeBjK2sBvQls+sRlWCG7Fx8VxUSBRiTSr9Ex yB9DZGUDTxOGnamvan/KwMXRJw9Vcyh/AILz52E89r//PGXMbNF/rLIfuAWAGPkj IzMDOFtdK+e1nYwixmpfGNJiIX4KjYlX/KV6oaqbhSz5DAEhOnvYnq4jXusNK0C+ h1wg7aoADiXuUYenQnONZ+7/uhZM0pM+yHS9ZDZyozH76LpO+1xyhCIiyVJoqJZd CSkQ9BkLOOrs4q/vNi/4q8E8vfw9fRAHlAzbTd/licN/2zBhR1c5Cse98IW5MZa3 Sw4i8LAAvkFBtneFYfS2yUAxbOFZH5XxH52GxOYxUJx4U0DAQGgDNnhuDuZ4EfjW KKh8gux7aXnGM2yRUYPzd++YJEjTuGahYPviSQDH2t2G6Y5rbIqyFWRra91I6ciT ASp5PaKBufe2iVS5CGyAnfCZYokqW4dpPLlx40OULypSTPuSlNxWhYXfeM90uHH6 DDeJiEaG59gPqkIFqWI0 =C7Vr -END PGP SIGNATURE- signature.asc Description: Digital signature
Bug#756812: nfs-common: rpc.gssd crashes while mounting an encrypted nfs4 filesystem
3 серпня 2014 о 13:17 +1000 Aníbal Monsalve Salazar написав(-ла): Hello, Could you please help me testing: · libtirpc1 0.2.4-2 · rpcbind 0.2.1-5 · nfs-common 1:1.2.8-7 · nfs-kernel-server 1:1.2.8-7 You will find them in experimental. The packages work for me on client. I didn't test on server yet. Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#752948: swi-prolog: FTBFS - test_singleton.pl: Exported procedure is not defined
tags 752948 + moreinfo unreproducible thanks The log looks really strange. No prolog packages are built at all. It just prints the header and stops: ** * Configuring packages swi-prolog ** I can't reproduce this bug in current sid chroot with cowbuilder (amd64). Do you have any idea why it ignores all packages in your build? Was the source archive unpacked correctly? Regards, Eugeniy Meshcheryakov 28 червня 2014 о 01:05 +0100 Michael Tautschnig написав(-ла): Package: swi-prolog Version: 6.6.6-1 Severity: serious Usertags: goto-cc During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder and pbuilder) the build failed with the following error. [...] Exported procedure memory_file:atom_to_memory_file/2 is not defined ERROR: /srv/jenkins-slave/workspace/sid-goto-cc-swi-prolog/swi-prolog-6.6.6/src/Tests/core/test_singleton.pl:10: Exported procedure memory_file:free_memory_file/1 is not defined ERROR: /srv/jenkins-slave/workspace/sid-goto-cc-swi-prolog/swi-prolog-6.6.6/src/Tests/core/test_singleton.pl:10: Exported procedure memory_file:memory_file_to_atom/2 is not defined ERROR: /srv/jenkins-slave/workspace/sid-goto-cc-swi-prolog/swi-prolog-6.6.6/src/Tests/core/test_singleton.pl:10: Exported procedure memory_file:open_memory_file/4 is not defined ERROR: /srv/jenkins-slave/workspace/sid-goto-cc-swi-prolog/swi-prolog-6.6.6/src/Tests/core/test_singleton.pl:10: Exported procedure memory_file:new_memory_file/1 is not defined Script /srv/jenkins-slave/workspace/sid-goto-cc-swi-prolog/swi-prolog-6.6.6/src/Tests/core/test_singleton.pl failed: test_singleton:copied_singletons/2: Undefined procedure: memory_file:new_memory_file/1 . done Running scripts from attvar .. done Running scripts from library done Running scripts from charset . done Running scripts from clp . done Running scripts from GC .. done Running scripts from thread done 22.875 seconds cpu time for 45,269,518 inferences 7,503 atoms, 4,919 functors, 5,805 predicates, 308 modules, 267,385 VM-codes LimitAllocated In use Local stack : 268,439,552 126,9761,488 Bytes Global stack : 268,443,648 126,960 144 Bytes Trail stack : 268,435,456 129,0168 Bytes 1,678 garbage collections gained 206,696,512 bytes in 2.071 seconds. 5,212 atom garbage collections gained 280,206 atoms in 6.930 seconds. Stack shifts: 742 local, 918 global, 443 trail in 0.151 seconds. 2 threads, 3,321 finished threads used 2.829 seconds. *** 1 tests failed *** Makefile:416: recipe for target 'check' failed make[2]: *** [check] Error 1 make[2]: Leaving directory '/srv/jenkins-slave/workspace/sid-goto-cc-swi-prolog/swi-prolog-6.6.6/src' debian/rules:125: recipe for target 'override_dh_auto_test' failed The full build log is attached; please do let me know if the problem is unreproducible, in which case I shall try to investigate further. Best, Michael signature.asc Description: Digital signature
Bug#743552: swi-prolog: package 7.x
Hi Ross, 3 квітня 2014 о 11:24 -0700 Ross Boylan написав(-ла): Dear Maintainer, swi-prolog 7.x has been out for awhile and it might be good to package it. My immediate interest is that it has picked up some fixes for problems I've encountered; these fixes may be backported to the 6.x series. 6.x is still having releases. The 7.x release was somewhat controversial; I think it has some significant new features but also significant departures from the standard. The 7.1.x is a development branch and new releases come quite often compared to 6.6.x. I already need to ask the release team to recompile packages that depend on swi-prolog after each release, it will be harder to do this even more often. I think this have to wait till there will be a stable release 7.0.x, or I may package 7.1.x for experimental, but it is unlikely that I'll have enough free time to support two branches any time soon. Regards, Eugeniy signature.asc Description: Digital signature
Bug#742779: coccinelle introduces spurious whitespace changes
forwarded 742779 co...@systeme.lip6.fr
thanks
Hello,
I've got the following bug report from a Debian user. It can be easily
reproduced with RC20. Note that there is no space before equals signs in
the generated patch.
Regards,
Eugeniy Meshcheryakov
27 березня 2014 о 12:37 +0100 Justus Winter написав(-ла):
Package: coccinelle
Version: 1.0.0~rc20.deb-1
Severity: normal
Dear Maintainer,
coccinelle recently (since I upgraded to jessie I guess) began to
introduce spurious whitespace changes for a certain semantic patch. I
made a minimal test case:
% tail test.*
== test.c ==
int main () {
int a = 4;
a = 2;
return a;
}
== test.cocci ==
@@
@@
+ char *f = %lu;
main (...) {
...
}
Curiously, the string %lu seems to trigger this. Bad, e.g. the
current sid version:
% spatch --version
spatch version 1.0.0-rc20 with Python support and with PCRE support
% spatch --sp-file test.cocci test.c
init_defs_builtins: /usr/share/coccinelle/standard.h
HANDLING: test.c
diff =
--- test.c
+++ /tmp/cocci-output-14372-7762e6-test.c
@@ -1,5 +1,6 @@
-int main () {
- int a = 4;
- a = 2;
+char *f= %lu;
+int main() {
+ int a= 4;
+ a= 2;
return a;
}
Good, e.g. the version from wheezy:
% spatch --version
spatch version 1.0.0-rc12 with Python support and with PCRE support
% spatch --sp-file test.cocci test.c
init_defs_builtins: /usr/share/coccinelle/standard.h
HANDLING: test.c
diff =
--- test.c
+++ /tmp/cocci-output-17254-5327d1-test.c
@@ -1,3 +1,4 @@
+char *f = %lu;
int main () {
int a = 4;
a = 2;
Thanks for your attention :)
-- System Information:
Distributor ID: Debian
Description: Debian GNU/Linux testing (jessie)
Release: testing
Codename: jessie
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages coccinelle depends on:
ii libc6 2.18-4
ii libpcre-ocaml [libpcre-ocaml-36gi0] 7.0.4-1
ii libpcre31:8.31-2
ii libpycaml-ocaml 0.82-14+b3
ii libpython2.72.7.6-7
ii ocaml-base-nox [ocaml-base-nox-4.01.0] 4.01.0-3
ii ocaml-findlib 1.4-2
ii python-glade2 2.24.0-3+b1
ii python-gobject 3.10.2-2
ii python-gtk2 2.24.0-3+b1
pn python:any none
coccinelle recommends no packages.
Versions of packages coccinelle suggests:
pn coccinelle-doc none
pn vim-addon-manager none
-- no debconf information
signature.asc
Description: Digital signature
Bug#742279: implicitly converted to pointer warnings on 64bit architectures
Hi, I need more info about this. Is this about version 6.6.3-1? Version 6.3.3-1 was not packaged. Also don't see those warnings when compiling on my machine (amd64). Are you using sid? Regards, Eugeniy Meshcheryakov 21 березня 2014 о 16:28 +0100 Matthias Klose написав(-ла): Package: swi-prolog Version: 6.3.3-1 Severity: serious Seen at least on amd64: Function `tgetstr' implicitly converted to pointer at pl-term.c:192 Function `tgoto' implicitly converted to pointer at pl-term.c:262 Our automated build log filter detected the problem(s) above that will likely cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. This is often due to a missing function prototype definition. Since use of implicitly converted pointers is always fatal to the application on ia64, they are errors. Please correct them for your next upload. More information can be found at: http://wiki.debian.org/ImplicitPointerConversions signature.asc Description: Digital signature
Bug#735015: swi-prolog: debums reports /usr/lib/swi-prolog/library/INDEX.pl does not match package md5sum
forcemerge 689121 735015 thanks Hello, swi-prolog updates that file during installation. This is already fixed in testing. Regards, Eugeniy Meshcheryakov 11 січня 2014 о 15:37 -0500 Daniel Dickinson написав(-ла): Package: swi-prolog Version: 5.10.4-5 Severity: normal /usr/lib/swi-prolog/library/INDEX.pl calculated md5sum does not match md5sum in package. Either this file is inappropriately modified (no files unser /usr/lib should get modified from package) or there is a packaging error. -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages swi-prolog depends on: ii swi-prolog-nox 5.10.4-5 ii swi-prolog-x5.10.4-5 swi-prolog recommends no packages. Versions of packages swi-prolog suggests: ii prolog-el 1.23-1 ii swi-prolog-doc 5.6.59-1 -- no debconf information signature.asc Description: Digital signature
Bug#719079: swi-prolog: pldoc generate tex not supported by pdf2latex
Hi,
11 серпня 2013 о 16:14 +0200 Eugeniy Meshcheryakov написав(-ла):
8 серпня 2013 о 13:30 +0200 Olivier Sallou написав(-ла):
Dear Maintainer,
the documentation generated by pldoc to convert from pl to tex generate
errors
when executing pdflatex since recent textlive and/or swi-prolog updates.
I had to apply the following update to my generated tex file to be valid:
sed -i
's/makeindex/makeindex\n\\newenvironment{arguments}{\\textbf{Arguments}
\\newline}{\\vspace*{0.5\\baselineskip}}/' logol.tex
sed -i 's/} /}/g' logol.tex
I need to defined *arguments* and remove the ** character added after
arguments in tex file.
The problem here is not that pldoc generates incorrect text file, but
that logol uses bundled pldoc.sty file that does not contain definitions
expected by pldoc. When compiling with pldoc.sty supplied with
swi-prolog-nox package (/usr/lib/swi-prolog/library/pldoc/pldoc.sty)
your patch is not needed. Now I just to have to find out where to
install that file so latex finds it by default...
I've fixed this bug in 6.4.1-3. But if you want to use pldoc.sty from
swi-prolog-nox package you'll have to remove this file from logol
package.
Regards,
Eugeniy Meshcheryakov
signature.asc
Description: Digital signature
Bug#719079: swi-prolog: pldoc generate tex not supported by pdf2latex
Hi,
8 серпня 2013 о 13:30 +0200 Olivier Sallou написав(-ла):
Dear Maintainer,
the documentation generated by pldoc to convert from pl to tex generate errors
when executing pdflatex since recent textlive and/or swi-prolog updates.
I had to apply the following update to my generated tex file to be valid:
sed -i
's/makeindex/makeindex\n\\newenvironment{arguments}{\\textbf{Arguments}
\\newline}{\\vspace*{0.5\\baselineskip}}/' logol.tex
sed -i 's/} /}/g' logol.tex
I need to defined *arguments* and remove the ** character added after
arguments in tex file.
The problem here is not that pldoc generates incorrect text file, but
that logol uses bundled pldoc.sty file that does not contain definitions
expected by pldoc. When compiling with pldoc.sty supplied with
swi-prolog-nox package (/usr/lib/swi-prolog/library/pldoc/pldoc.sty)
your patch is not needed. Now I just to have to find out where to
install that file so latex finds it by default...
Regards,
Eugeniy Meshcheryakov
signature.asc
Description: Digital signature
Bug#718956: ITP: printrun -- 3D-printing host software
Hi, There is already a wnpp bug here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695336 7 серп. 2013 09:45, Nicolas Dandrimont ol...@debian.org напис. Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont ol...@debian.org * Package name: printrun Version : 20130711 Upstream Author : Kliment Yanev * URL : https://github.com/kliment/Printrun * License : GPLv3+ Programming Lang: Python Description : 3D-printing host software Printrun is a set of G-Code sending applications for 3D-printers. . It consists of printcore (a dumb G-Code sender), pronsole (a full-fledged command-line G-Code sender), pronterface (a G-Code sender with a graphical interface), and a collection of related scripts. . Combined with a slicing program, it allows the user to operate a 3D printer such as a RepRap from scratch. I'd be glad to hear feedback on the long description, as I'm a bit in a bubble (and I'm sure there's room for improvement). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130807074035.ga3...@hilbert.home.olasd.eu
Bug#695336: ITP: printrun -- Graphical host package to control 3d printers such as RepRap's.
Hello Richard, Are you still planning to package printrun? I'm also interested to see it in Debian. Regards, Eugeniy Meshcheryakov 7 грудня 2012 о 10:36 +0100 Richard Ulrich написав(-ла): Package: wnpp Owner: Richard Ulrich ri...@paraeasy.ch Severity: wishlist * Package name: printrun Version : 2012 Upstream Author : Kliment * URL : http://reprap.org/wiki/Printrun * License : GPL-3+ Programming Lang: python Description : Graphical host package to control 3d printers such as RepRap's.. Printrun consists of printcore, pronsole and pronterface, and a small collection of helpful scripts. * printcore.py is a library that makes writing reprap hosts easy * pronsole.py is an interactive command-line host software with tabcompletion goodness * pronterface.py is a graphical host software with the same functionality as pronsole * webinterface.py is a browser-usable remote control function for Pronterface signature.asc Description: Digital signature
Bug#709606: swi-prolog: Executable generation fails
Hi, This was because linking was done with a static library. Linking with dynamic library does not have the problem. This should be fixed in version 6.2.6-3 where static library was moved to /usr/lib. This has disadvantage of linking with a library that doesn't have stable ABI. I set shlibs dependencies to this: libswipl 6.2.6 swi-prolog-nox (= 6.2.6~), swi-prolog-nox ( 6.2.6.0~) So logol will require bin-NMU after next upstream release, but I think it is better then using a static library. In the later case I think logol will be silently broken. In any case I still cannot compile logol, it fails during checks. I have no idea what is broken there. Regards, Eugeniy Meshcheryakov 24 травня 2013 о 14:02 +0200 Olivier Sallou написав(-ла): I could make a successful compilation by manually adding paths to libraries and installing required dependency libunwind and libunwind-dev: swipl-ld -L/lib/x86_64-linux-gnu/ -L/usr/lib/x86_64-linux-gnu -lgmp -ldl -lquadmath -lcurses -lunwind -v -o test test.c test.pl Swipl seems to need libunwind, it should be added to Deps. Compilation should not require system deps. Olivier -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 signature.asc Description: Digital signature
Bug#709605: random/1 is not available anymore instead of random/3
Hi, 24 травня 2013 о 13:04 +0200 olivier sallou написав(-ла): Executing directly in swi-prolog: random(Test) works fine so it means that random/1 is available in API. But using an application compiled in previous version with random/1 fails I cannot reproduce this. The only LogolExec command line that I was able to construct did not show this problem. What command did you use to run tests? In any case I added Breaks: logol ( 1.6.1-2~) to swi-prolog-nox, so broken combinations will not be installable for now. Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#697416: swi-prolog: Buffer overflows in path canonisation code and when expanding file-names with long paths
Hi, thanks for the bug report. Should I also prepare fix for stable? Regards, Eugeniy Meshcheryakov 5 січня 2013 о 00:47 +0100 Salvatore Bonaccorso написав(-ла): Package: swi-prolog Severity: important Tags: security Control: found -1 5.10.1-1 Control: found -1 5.10.4-4 Control: fixed -1 6.2.5-1 Hi, the following vulnerabilities were published for swi-prolog. CVE-2012-6089[0]: pl: Possible buffer overrun in patch canonisation code CVE-2012-6090[1]: pl: Possible buffer overflows when expanding file-names with long paths signature.asc Description: Digital signature
Bug#690734: Perhaps wider distribution of this info...?
retitle 690734 swi-prolog-java: package misconfigured thanks Hello, I think I fixed most of the problems in version 6.2.5-2 (in experimental). I also added the following README.Debian to the swi-prolog-java package. Good news that LD_PRELOAD should not be required anymore. LD_LIBRARY_PATH is still required sometimes though. Any additions/corrections are welcome. Regards, Eugeniy Meshcheryakov Using JPL Package in Debian === Using Prolog from Java Programs --- Compiling or running Java programs requires adding jpl.jar to Java class path, for example by using -classpath command line argument or CLASSPATH environment variable: $ javac -classpath /usr/share/java/jpl.jar Class.java $ java -classpath /usr/share/java/jpl.jar:. Class Using Java from Prolog Programs --- Prolog programs that use Java require additional settings in order to load various Java libraries. LD_LIBRARY_PATH should be modified so that it contains directories that contain libjava.so, libjni.so, libjsig.so, and maybe some other Java libraries. The command line for the prolog interpreter could look like this (on amd64 system, using OpenJDK): $ LD_LIBRARY_PATH=/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64 swipl Other architectures and JDK versions require different settings. A typical error message with incorrect library path setting could look like this: $ swipl ... ?- use_module(library(jpl)). ERROR: /usr/lib/swi-prolog/library/jpl.pl:4637: '$open_shared_object'/3: libjsig.so: cannot open shared object file: No such file or directory ERROR: /usr/lib/swi-prolog/library/jpl.pl:4637: library `java' does not exist (Please add directory holding libjava.so to $LD_LIBRARY_PATH) The error messages indicate that directories that contain libjsig.so and libjava.so should be added to LD_LIBRARY_PATH. You then can use the following command to find out location of those files: $ dpkg --search libjsig.so libjava.so Choose directories that belong to your preferred Java runtime version. Please report any other encountered problems or possible fixes for described problems to Debian BTS. Bug #690734 [1] tracks current state of Java support in swi-prolog. 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690734 signature.asc Description: Digital signature
Bug#680116: swi-prolog: seg fault on Sparc and IA64
Hello Olivier, Could you try to build logol with swi-prolog = 6.2.2-13 (in experimental). There are quite a lot of fixes for various crashes and data corruption in this version. Regards, Eugeniy Meshcheryakov 1 серпня 2012 о 12:16 +0200 olivier sallou написав(-ла): I have uploaded logol to experimental, but it still fails the same way on IA64 (same issue). New release introduced an errorin my build, I had to patch my code (an error that was supported at prolog code load, but now raising an error). signature.asc Description: Digital signature
Bug#684310: swi-prolog: Transition package to use default java implementation
Hello, 8 серпня 2012 о 16:58 +0100 James Page написав(-ла): Package: swi-prolog Version: 5.10.4-3 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu quantal ubuntu-patch openjdk-7-transition -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, In Ubuntu, the attached patch was applied to achieve the following: * Transition package to use default java implementation: - d/control: BD on default-jdk instead of openjdk-6-jdk, switch primary runtime dependency to default-jre-headless. - d/p/java-compat.patch: Set source/target = 1.5 to ensure that backwards compatible bytecode is built. New version of swi-prolog passes these flags to javac: -source 1.4 -target 1.4 Is this enough for backward compatibility? Ubuntu quantal is transitioning from openjdk-6 to openjdk-7 as default java; this patch eases the transition and ensures that bytecode built with later versions of java is backwards compatible. Note that this is not a release goal for wheezy. Thanks for considering the patch. signature.asc Description: Digital signature
Bug#689583: swi-prolog-nox depends on libncursesw5 on amd64, but not on proper -dev package
It seems I've sent this message to an incorrect address first time. Resending now. 4 жовтня 2012 о 20:55 +0200 Eugeniy Meshcheryakov написав(-ла): 4 жовтня 2012 о 09:39 +0100 Michael Tautschnig написав(-ла): Package: swi-prolog-nox Version: 5.10.4-3 Severity: serious Justification: breaks build of other packages swi-prolog-nox lists as dependencies: libncursesw5 (= 5.6+20070908) [amd64] libncurses5 (= 5.5-5~) [not amd64] libncurses5-dev This breaks any build using swipl-ld on *amd64* as libncursesw5.so will not be available. The problem is caused by swi-prolog autodetecting libraries and trying ncursesw first, and it was installed on my machine when I was building the package. The least intrusive solution IMHO would be to just Build-Conflict with libncursesw5-dev. Will release team accept unblock request for package with such change? Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#689583: swi-prolog-nox depends on libncursesw5 on amd64, but not on proper -dev package
Hi, 4 жовтня 2012 о 09:39 +0100 Michael Tautschnig написав(-ла): Package: swi-prolog-nox Version: 5.10.4-3 Severity: serious Justification: breaks build of other packages swi-prolog-nox lists as dependencies: libncursesw5 (= 5.6+20070908) [amd64] libncurses5 (= 5.5-5~) [not amd64] libncurses5-dev This breaks any build using swipl-ld on *amd64* as libncursesw5.so will not be available. The problem is caused by swi-prolog autodetecting libraries and trying ncursesw first, and it was installed on my machine when I was building the package. The least intrusive solution IMHO would be to just Build-Conflict with libncursesw5-dev. Will release team accept unblock request for package with such change? Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#687212: Processed: reassign 687212 to localechooser, found 687212 in 2.44
Hi,
I attached patch to one of the previous messages for detecting network-console
installs.
Regards,
Eugeniy Meshcheryakov
--- Оригінальне повідомлення ---
Quoting Debian Bug Tracking System (ow...@bugs.debian.org):
Processing commands for cont...@bugs.debian.org:
reassign 687212 localechooser
Bug #687212 [installation-reports] localechooser: should use higher
languagelevel with network-console Bug reassigned from package
'installation-reports' to 'localechooser'. No longer marked as found
in versions 2.44 and 2.46. Ignoring request to alter fixed versions of
bug #687212 to the same values previously set
found 687212 2.44
Bug #687212 [localechooser] localechooser: should use higher
languagelevel with network-console Marked as found in versions 2.44/.
The list of languages was very short because of this code:
# Determine the display level
language_display_level() {
local level
#log Frontend in use: $DEBIAN_FRONTEND
case $DEBIAN_FRONTEND in
gtk)
level=4 ;;
*)
# Keep only Latin1 languages if we don't have a framebuffer
if [ $TERM_FRAMEBUFFER ]; then
level=3
else
level=1
fi
# The hurd text-mode console has decent charset support
if [ $TERM = hurd ]; then
level=3
fi
# ASCII only if we are on serial console, dumb, or Mach terminal
# Both variables should already be set at init time
if [ $TERM_TYPE = serial ] || [ $TERM = dumb ] || [ $TERM =
mach-color ] ; then level=0
fi
;;
esac
#log Language display level is $level
echo $level
}
If, in the situation you describe, there is a way to recognize that
the terminal can display non Latin languages, then we can adapt that
code.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677931: installation-report: testing image does not boot on QNAP TS-212 (armel) / stable works
Well, those pure ascii languages still use UTF-8. Look at French for example. I was using UTF-8 locale and everything was looking correctly. I think many languages in the list will not be shown correctly if one uses ssh on a latin1 console. --- Оригінальне повідомлення --- Eugeniy Meshcheryakov, le Mon 10 Sep 2012 23:42:45 +0200, a écrit : Currently localechooser detects network-console as a terminal without framebuffer and uses languagelevel 1 for such installs. It should use higher level, because most modern ssh clients support unicode, and in any case d-i is running in UTF-8 locale (not latin1). Most modern ssh clients support unicode indeed, but the current ssh daemon does not take the LANG parameter from the ssh client, so d-i can not know whether it should emit utf-8 or ascii. That is why the list is restricted to pure ascii languages. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677931: installation-report: testing image does not boot on QNAP TS-212 (armel) / stable works
--- Оригінальне повідомлення --- Eugeniy Meshcheryakov, le Tue 11 Sep 2012 11:03:59 +0200, a écrit : Well, those pure ascii languages still use UTF-8. Look at French for example. French is not a pure ascii language, precisely. I was using UTF-8 locale and everything was looking correctly. Because you happened to use a UTF-8 locale. If you connect from a latin1 terminal, accents will go wrong. Exactly my point. I think many languages in the list will not be shown correctly if one uses ssh on a latin1 console. That's precisely the problem and the reason why we can't assume non-ascii languages will render correctly. The state now is that d-i is using UTF-8 for all languages. So non-UTF clients already have broken display, probably even for English with all those pseudographical characters. I think it is safe to assume that UTF-8 ssh client is available in 2012. The UTF-8 transition was done 6 years ago. Another clean solution would be disable all languages except C. I do not think that this is acceptable. Regards, Eugeniy Meshcheryakov -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677931: installation-report: testing image does not boot on QNAP TS-212 (armel) / stable works
10 вересня 2012 о 14:08 +0100 Martin Michlmayr написав(-ла): Yes, it requires a complete installation. This is because a) we have to bring SSH up and b) network configuration is currently in one step, so we cannot configure a basic config and later ask for more details, such as DNS. How common is it for DHCP servers not to send gateway and DNS information? I don't know about that, but in my case I had a DHCP server that could not be configured to supply next-server option (modem). So I had to disconnect that and configure isc-dhcp-server. Minimal required configuration does not supply DNS info. Confusingly it was enough to flash the image, and d-i also obtained address after reboot. And there were no indication of any problem. But using rescue mode in not official way of installation, so if it is possible to use d-i first time without problems that's not so bad. Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#677931: installation-report: testing image does not boot on QNAP TS-212 (armel) / stable works
clone 677931 -1
reassing -1 localechooser
found -1 2.44
retitle -1 localechooser: should use higher languagelevel with network-console
tag -1 + patch
thanks
Hi,
Currently localechooser detects network-console as a terminal without
framebuffer and uses languagelevel 1 for such installs. It should use
higher level, because most modern ssh clients support unicode, and
in any case d-i is running in UTF-8 locale (not latin1).
The attached patch changes languagelevel for network-console installs to
the same value as used for framebuffer based installs.
Regards,
Eugeniy Meshcheryakov
10 вересня 2012 о 14:08 +0100 Martin Michlmayr написав(-ла):
After I connected to QNAP via ssh and downloaded installer components, I
was presented with a list of languages to choose from. The list was
quite small (screenshot: http://people.debian.org/~eugen/di-languages.png ).
For example, Ukrainian was not in the list. There were no non-latin
languages
in the list. Some languages using Latin scripts were missing too. Why?
I cannot remember the reason for this; maybe someone else can comment.
From be7383de324551218354a9863f4bdf9f54d2cd17 Mon Sep 17 00:00:00 2001
From: Eugeniy Meshcheryakov eu...@debian.org
Date: Mon, 10 Sep 2012 23:29:59 +0200
Subject: [PATCH] Use language level 3 with network-console installs
---
localechooser |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/localechooser b/localechooser
index 7f5eb60..0db279d 100644
--- a/localechooser
+++ b/localechooser
@@ -62,7 +62,8 @@ language_display_level() {
level=4 ;;
*)
# Keep only Latin1 languages if we don't have a framebuffer
- if [ $TERM_FRAMEBUFFER ]; then
+ # and not using network-console
+ if [ $TERM_FRAMEBUFFER -o $SSH_CLIENT ]; then
level=3
else
level=1
--
1.7.10.4
signature.asc
Description: Digital signature
Bug#677931: installation-report: testing image does not boot on QNAP TS-212 (armel) / stable works
10 вересня 2012 о 20:17 +0100 Martin Michlmayr написав(-ла): * Eugeniy Meshcheryakov eu...@debian.org [2012-09-10 21:07]: I don't know about that, but in my case I had a DHCP server that could not be configured to supply next-server option (modem). So I had to disconnect that and configure isc-dhcp-server. Minimal required configuration does not supply DNS info. Confusingly it was enough to flash the image, and d-i also obtained address after reboot. And there were no indication of any problem. The problem is that we don't really have any mechanism at this point to show that there is a problem. The QNAP doesn't have an LCD after all. If you have any ideas on how this could be improved, let me know. The fix was as easy as adding this preseed file and rebuilding the recovery image: d-i netcfg/no_default_route boolean true After this QNAP booted successfully and I was able to login and fix the network configuration from command line. D-I does not seem to require DNS setup. Is there any reason not to use this setting for all network-console installs? I didn't found yet how to change this setting not using pressed file. Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#677931: installation-report: testing image does not boot on QNAP TS-212 (armel) / stable works
Hi, 8 вересня 2012 о 17:16 +0100 Martin Michlmayr написав(-ла): The testing installer boots fine on my TS-219. Can you try again on your TS-212? I tried to use testing d-i again, and it went better. First I set up a DHCP server and TFTP server on my laptop and disconnected the modem that also has built-in DHCP server from the network. With this configuration QNAP obtained an IP address, downloaded d-i image, rebooted into d-i, obtained the IP address again, and did nothing for several minutes, till I rebooted it. After reboot - the same problem, I can ping QNAP, but it does not start the ssh server. So I stopped the laptop's DHCP server and connected my modem to network. After I rebooted QNAP ssh worked fine, and it took around a minute to boot. Can it be that D-I requires full network configuration, with gateway, DNS, and so on via DHCP? That the only difference I can think about. After I connected to QNAP via ssh and downloaded installer components, I was presented with a list of languages to choose from. The list was quite small (screenshot: http://people.debian.org/~eugen/di-languages.png ). For example, Ukrainian was not in the list. There were no non-latin languages in the list. Some languages using Latin scripts were missing too. Why? I tested the installer only till I was able to mount the hard drive and reflash the kernel from the working system. There were no other problems. Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#684801: Double ZU
reassing 684801 kanadic tags 684801 + confirmed thanks Hi, 14 серпня 2012 о 11:15 +0900 Philipp Klaus Krause написав(-ла): At one time (see screenshot at http://colecovision.eu/stuff/zubug.png), kdrill did present me te option ZU twice. Interestingly, the upper ZU was considered incorrect, while the lower ZU was considered correct by kdrill. The problem is that in kanadic ズ = ヅ = ZU and ず = づ = zu. I'm thinking to rename second glyph to DU or DU(ZU). Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#680116: swi-prolog: seg fault on Sparc and IA64
forwarded 680116 http://www.swi-prolog.org/bugzilla/show_bug.cgi?id=45 thanks Hello, Thanks for the backtrace. I forwarded your bug report to the above address. Please add any missing details there. BTW you could try to upload logol to experimental and set build-deps to require swi-prolog 6.0.2. I cannot upload swi-prolog to unstable now, because it does not build on sparc and mipsel. Regards, Eugeniy Meshcheryakov 4 липня 2012 о 16:40 +0200 olivier sallou написав(-ла): Here are gdb logs: Program received signal SIGSEGV, Segmentation fault. 0x4007ce21 in into_relocation_chain () (gdb) backtrace #0 0x4007ce21 in into_relocation_chain () #1 0x40088370 in garbageCollect () #2 0x4008a3a0 in ensureGlobalSpace () #3 0x40046170 in PL_next_solution () #4 0x40010360 in main () I also attach strace log. Standard output: [c,c,c] getchars gotchars [c,c,c] getchars gotchars [c,c,c] getchars gotchars Segmentation fault For debug I have put a write before and in predicate call, with a sleep(1) to be sure to print the statement in output. The seg fault occured before putting those write/sleep and always occurs at the same time in the present test. -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 signature.asc Description: Digital signature
Bug#680116: swi-prolog: seg fault on Sparc and IA64
24 липня 2012 о 00:17 +0200 Eugeniy Meshcheryakov написав(-ла): forwarded 680116 http://www.swi-prolog.org/bugzilla/show_bug.cgi?id=45 thanks Hello, Thanks for the backtrace. I forwarded your bug report to the above address. Please add any missing details there. BTW you could try to upload logol to experimental and set build-deps to require swi-prolog 6.0.2. I cannot upload swi-prolog to unstable now, because it does not build on sparc and mipsel. I also tried to install swi-prolog in my home directory and then build logol, but got a lot of errors (or something that looked like errors) and have no idea how to interpret the output of that build system. Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#680116: swi-prolog: seg fault on Sparc and IA64
Hello, Could you please try to reproduce the bug with swi-prolog 6.0.2 from experimental? A gdb backtrace and/or last lines of output from ltrace and/or strace would also be useful. Regards, Eugeniy Meshcheryakov 3 липня 2012 о 19:44 +0200 Olivier Sallou написав(-ла): Package: swi-prolog Version: 5.10.4-3 Severity: important Dear Maintainer, * What led up to the situation? My package logol fails to build on IA64 and Sparc, some tests are failing while ok on other archs * What exactly did you do (or not do) that was effective (or ineffective)? I analysed the reason of failing tests and found that a seg fault occurs during the treatment * What was the outcome of this action? Basically, I parse a file, extract some chars at a position and do some treatment. On those archs, I end with a segmentation fault always at the same time. I added some logs and it appears it occurs when calling a predicate. I added a write as first instruction of the predicate and it is not executed. Could be a memory allocation issue? See sample log below * What outcome did you expect instead? Treatment should be as on other archs A sample exec output below, the search at is the position in file. It fails at 24, which is not the end of file. search ccc at 2 [c,c,c] getchars gotchars search ccc at 3 [c,c,c] getchars gotchars search ccc at 4 [c,c,c] getchars gotchars search ccc at 5 [c,c,c] getchars gotchars search ccc at 6 [c,c,c] getchars gotchars search ccc at 21 [c,c,c] getchars gotchars search ccc at 22 [c,c,c] getchars gotchars search ccc at 23 [c,c,c] getchars gotchars search ccc at 24 Segmentation fault Memory usage is low, this is not an out of memory issue. I have no core file to give more info. The executed prolog is an executable file, compiled to get a full exe with embedded prolog libs. Compiled with: swipl-ld -initfile swi-logol.pl -o logol.exe -v logolSwiMain.c sicstus.pl logol.pl Again, it works fine with i386, powerpc and amd64. I can reproduce the issue with my exe and test files, but I can't reproduce with a single/easy pl file. Olivier -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages swi-prolog depends on: ii swi-prolog-nox 5.10.4-3 ii swi-prolog-x5.10.4-3 swi-prolog recommends no packages. Versions of packages swi-prolog suggests: pn prolog-el none ii swi-prolog-doc 5.6.59-1 -- no debconf information signature.asc Description: Digital signature
Bug#677931: installation-report: testing image does not boot on QNAP TS-212 (armel) / stable works
Package: installation-reports Version: 2.46 Severity: normal Boot method: flash Image version: testing/stable Date: night 16.06.2012-17.06.2012 Machine: QNAP TS-212 Partitions: df -Tl will do; the raw partition table is preferred Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [E] Detect network card:[ ] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: I was trying to install Debian on TS-212 using instructions here: http://www.cyrius.com/debian/kirkwood/qnap/ts-219/ First I tried to use installer image from testing, but the device did not boot: both disk LEDs were constantly on, there was some disk activity, but absolutely no network activity. I tried several times wating 10-20 minutes each time. I also tried to remove disks but this did not help. After this I used stable installer image with testing repository. The installation was sucessfull, with small problems: had to remove RAID devices manually, partman did not align partition correctly. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=6.0 (squeeze) - installer build 20110106+squeeze4+b1 X_INSTALLATION_MEDIUM=network-console == Installer hardware-summary: == uname -a: Linux debian 2.6.32-5-kirkwood #1 Sun May 6 16:57:51 UTC 2012 armv5tel GNU/Linux usb-list: usb-list: Bus 01 Device 01: Marvell Orion EHCI [1d6b:0002] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 01 usb-list:Manufacturer: Linux 2.6.32-5-kirkwood ehci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 01 Device 02: USB2.0 Hub [05e3:0608] usb-list:Level 01 Parent 01 Port 00 Class 09(hub ) Subclass 00 Protocol 01 usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub lsmod: Module Size Used by lsmod: raid1 19757 3 lsmod: dm_mod 56891 0 lsmod: md_mod 80506 3 raid1 lsmod: jfs 157227 0 lsmod: ext4 288593 1 lsmod: jbd2 64351 1 ext4 lsmod: ext3 111204 0 lsmod: jbd37738 1 ext3 lsmod: btrfs 539502 0 lsmod: crc32c 2562 1 lsmod: libcrc32c896 1 btrfs lsmod: vfat8152 0 lsmod: fat43613 1 vfat lsmod: ext2 55323 0 lsmod: mbcache 4860 3 ext4,ext3,ext2 lsmod: sd_mod 31344 8 lsmod: crc_t10dif 1106 1 sd_mod lsmod: sata_mv24398 6 lsmod: ehci_hcd 36525 0 lsmod: evdev 6582 0 lsmod: libata137914 1 sata_mv lsmod: usbcore 123103 2 ehci_hcd lsmod: scsi_mod 124484 2 sd_mod,libata lsmod: gpio_keys 3066 0 lsmod: mv643xx_eth22558 0 lsmod: nls_base5367 4 jfs,vfat,fat,usbcore lsmod: libphy 14836 1 mv643xx_eth lsmod: inet_lro5060 1 mv643xx_eth df: Filesystem 1K-blocks Used Available Use% Mounted on df: tmpfs 12783660127776 0% /dev df: /dev/md0 1031052504120474556 52% /target df: /dev/md0 1031052504120474556 52% /dev/.static/dev df: tmpfs 12783660127776 0% /target/dev free: total used free shared buffers free: Mem: 255676 18290472772017392 free: Swap: 524212 1124 523088 free: Total: 779888 184028 595860 /proc/cmdline: console=ttyS0,115200 root=/dev/ram initrd=0xa0,0x90 ramdisk=34816 /proc/cpuinfo: Processor: Feroceon 88FR131 rev 1 (v5l) /proc/cpuinfo: BogoMIPS : 1199.30 /proc/cpuinfo: Features : swp half thumb fastmult edsp /proc/cpuinfo: CPU implementer : 0x56 /proc/cpuinfo: CPU architecture: 5TE /proc/cpuinfo: CPU variant : 0x2 /proc/cpuinfo: CPU part : 0x131 /proc/cpuinfo: CPU revision : 1 /proc/cpuinfo: /proc/cpuinfo: Hardware : QNAP TS-119/TS-219
Bug#675385: spark gets SIGKILL when started on armhf
Hello, 31 травня 2012 о 18:33 + Tero Koskinen написав(-ла): Executable /usr/bin/spark dies to SIGKILL when one Err... SIGKILL? Any idea what sends SIGKILL to it? I would expect SIGSEGV or SIGBUS, but why SIGKILL? Reading symbols from /usr/bin/spark...(no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/spark During startup program terminated with signal SIGKILL, Killed. Could you provide the backtrace? (gdb) start Function main not defined. Make breakpoint pending on future shared library load? (y or [n]) y Temporary breakpoint 1 (main) pending. Starting program: /usr/bin/spark During startup program terminated with signal SIGKILL, Killed. (gdb) exit Undefined command: exit. Try help. (gdb) quit % Executable '/usr/bin/checker' from the same package works: That one is wiriten in Prolog, the spark executable is writen in Ada. Did you try to run any other Ada programs on this system? Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#675385: spark gets SIGKILL when started on armhf
Machine is Gumstix Overo (OMAP3) with 256MB ram and 200MB swap, 16GB filesystem on microsd card. I think SIGKILL is sent by the kernel because of memory exhaustion. % /usr/bin/time spark 0.99user 0.39system 0:01.55elapsed 89%CPU (0avgtext+0avgdata 1669200maxresident)k 0inputs+0outputs (0major+104408minor)pagefaults 0swaps It seems that spark users too large static buffers somewhere (it cannot use dynamic memory allocation because it is writen mostly in SPARK). Cold you try to run spark with a large swap file, just to see if this fixes it? signature.asc Description: Digital signature
Bug#675385: spark gets SIGKILL when started on armhf
31 травня 2012 о 22:34 +0200 Eugeniy Meshcheryakov написав(-ла): Machine is Gumstix Overo (OMAP3) with 256MB ram and 200MB swap, 16GB filesystem on microsd card. I think SIGKILL is sent by the kernel because of memory exhaustion. % /usr/bin/time spark 0.99user 0.39system 0:01.55elapsed 89%CPU (0avgtext+0avgdata 1669200maxresident)k 0inputs+0outputs (0major+104408minor)pagefaults 0swaps It seems that spark users too large static buffers somewhere (it cannot use dynamic memory allocation because it is writen mostly in SPARK). Cold you try to run spark with a large swap file, just to see if this fixes it? The largest data structure in the examiner is contextmanager__ops__file_heap. Setting ContextManagerMaxFiles and ContextManagerMaxUnits in examinerconstants.aps to 1024 reduces memory consumption. I think the other posibility is to tune the values dependant on ExaminerSize in this file. The question is what values to use and on which architectures... signature.asc Description: Digital signature
Bug#646590: coccinelle: version outdate and incompatible with patterns in linux source
Hi, 25 жовтня 2011 о 15:04 +0200 Christoph Egger написав(-ла): Seems the coccinelle in unstable can't work with the pattern files e.g. found in the linux tree. Would it be possible to get a more recent version uploaded to unstable. I uploaded 1.0.0-rc7 to experimental today. Unfortunately it seems that some features (like new regular expressions) do not work correctly and may require changes in other packages. I'll investigate later. Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#646590: coccinelle: version outdate and incompatible with patterns in linux source
Hi, 25 жовтня 2011 о 15:04 +0200 Christoph Egger написав(-ла): Seems the coccinelle in unstable can't work with the pattern files e.g. found in the linux tree. Would it be possible to get a more recent version uploaded to unstable. The version of coccinelle in unstable is not really outdated, it is latest non-rc release. But I'll try to package last rc in coming days, perhaps targeting experimental. Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#640326: makedic package description
Hello, Thanks for your suggestions. 4 вересня 2011 о 15:14 +0100 Justin B Rye написав(-ла): It's debatable. I was taught *not* to capitalise script-names (ogham, devanagari, hieratic) unless they're named after things that are themselves capitalised in English (Braille, Greek, Old Persian). On the other hand, some official sources (such as (http://unicode.org/iso15924/iso15924-codes.html;) seem to treat individual writing systems as automatically capitalised in English. These two conventions collide most obviously for Japanese [Kk]anji, [Hh]iragana, and [Kk]atakana, with the added twist that it's not clear whether [Kk]ana gets to count as a script in its own right or whether it's just a general category like hieroglyphs. I'll keep all those names lowercase then. Package: kdrill [...] -Description: kanji drill and dictionary program - Offers lot of options like guessing kanji, guessing meaning, by grade - or even from a selected kanji list. You can even practice your kana. - A kanjidic is essential to run this program although you can specify your - own dictionary on the command line. +Description: Kanji drill and dictionary program + Offers lot of options like guessing Kanji, guessing meaning, by grade + or even from a selected Kanji list. You can even practice your Kana. + A Kanji dictionary is essential to run this program although you can + specify your own dictionary on the command line. The first sentence isn't a sentence, but more importantly this is extremely unclear about what the software is *for*. Without that context, the list of options is borderline gibberish. Frankly I'd suggest throwing the whole thing out and replacing it with some basic introductory text stolen from http://www.bolthole.com/kdrill/: This package provides a graphical program for learning Japanese characters, which also doubles as a dictionary lookup program. It requires a kanji dictionary, although you can specify a custom one on the command line. Yes, this looks better. But original description suggests to install kanjidic package because kdrill only recommends kanjidic | kanadic. What about something like this: This package provides a graphical program for learning Japanese characters, which also doubles as a dictionary lookup program. It requires a dictionary package, such as kanjidic (for learning kanji) or kanadic (for learning hiragana or katakana), although you can specify a custom dictionary file on the command line. Package: makedic [...] Description: dictionary compiler for KDrill makeedict is the program to help you make custom dictionary file for - KDrill. In particular, this is the program use to create the kanadic - drill files. + KDrill. In particular, this is the program use to create the Kana + dictionary drill files. This still has grammar errors, but more importantly it's unclear what it's trying to say. Does makedict create dictionary files (meaning wordlists), drill files, or both, or what? I would guess: It converts text files with pairs symboltranslation to kanjidic format. It is also used to compile dictionaries for kanadic package. This package provides a program to create custom dictionary files for KDrill. It can also generate kana dictionary drill files. I think this description is ok. Package: kanadic [...] Description: katakana and hiragana drill files for KDrill - Those files let you practice your basics katakana and hiragana with kdrill. - It includes both the basic version and the extended versions. + These files let you practice your katakana and hiragana basics with KDrill. + It includes both the basic and the extended version. This package provides files for practicing katakana and hiragana with KDrill. It includes basic and extended versions of each list. This is also ok. Thanks, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#638740: debsums reports that some aspell-uk files have changed
tags 638740 + confirmed thanks Hi, That was required for older version of dictionaries-common. It seems it should not be required with newer versions. I'll try to fix it ASAP. Regards, Eugeniy Meshcheryakov 21 серпня 2011 о 15:38 +0200 Francois Gouget написав(-ла): Install aspell-uk and immediately run 'debsums -s aspell-uk'. The output is: debsums: changed file /var/lib/aspell/uk.compat (from aspell-uk package) debsums: changed file /var/lib/aspell/uk.rws (from aspell-uk package) This means these files were changed by aspell-uk itself, thus making it impossible to check for tampering (or file corruption), and casting doubt on the entire system for administrators who depend on the output of debsums. signature.asc Description: Digital signature
Bug#566234: this bug also present in gnat-4.6 (undefined reference to `__gnat_alternate_stack')
Hello, This bug is still not fixed in gnat-4.6, as shown by a failed build of spark on mips: https://buildd.debian.org/status/architecture.php?a=mipssuite=experimental I think the fix can be as easy as applying the attached patch. It makes list of source files for mips close to one for mipsel. I did not try to compile this, because it would take ages in qemu. Regards, Eugeniy Meshcheryakov --- a/src/gcc/ada/gcc-interface/Makefile.in +++ b/src/gcc/ada/gcc-interface/Makefile.in @@ -1666,7 +1666,7 @@ s-taprop.adbs-taprop-linux.adb \ s-tasinf.adss-tasinf-linux.ads \ s-tasinf.adbs-tasinf-linux.adb \ - s-taspri.adss-taspri-posix.ads \ + s-taspri.adss-taspri-posix-noaltstack.ads \ s-tpopsp.adbs-tpopsp-posix-foreign.adb \ system.adssystem-linux-mips.ads signature.asc Description: Digital signature
Bug#618555: spatch: exception Failure(More that one variable in decl. Have to split to transform.)
severity 618555 wishlist
forwarded 618555 co...@diku.dk
tags 618555 + upstream
thanks
Hello, this bug was reported to Debian BTS. I hope coccinelle developers
have more info on it.
16 березня 2011 о 05:20 -0500 Jonathan Nieder написав(-ла):
Package: coccinelle
Version: 0.2.4.deb-3
Hi,
Given the uninitialized.cocci and fast-import.c as below[1], we
find:
$ spatch -sp_file uninitialized.cocci fast-import.c
init_defs_builtins: /usr/share/coccinelle/standard.h
HANDLING: fast-import.c
Fatal error: exception Failure(More that one variable in decl. Have to
split to transform.)
I see two problems:
1. The message is unclear. I suppose the intent is something like
fatal: cannot transform a line with multiple declarations in it
It looks so to me, but I do not undertand the source code in that palce.
And I agree that the error message is not clear.
2. The limitation is unfortunate.
And this can be a future request for spatch.
Known problem? Do I understand correctly?
Thanks for spatch. :) It's a great tool.
Jonathan
[1]
-- 8 -- uninitialized.cocci -- 8 --
@@
identifier x;
type T;
@@
- T x = x;
+ T x;
-- 8 -- snipsnip -- 8 --
-- 8 -- fast-import.c -- 8 --
static void parse_merge(void)
{
int *list = NULL, *n, *e = e;
}
-- 8 -- snipsnip -- 8 --
Regards,
Eugeniy Meshcheryakov
signature.asc
Description: Digital signature
Bug#617551: ITP: spark -- SPARK programming language tools
9 березня 2011 о 18:49 + Florian Schanda написав(-ла): I would say This package contains the tools necessary for checking if programs adhere to the SPARK rules and the tools to show freedom of runtime exceptions in those programs. And then also say: To compile SPARK programs use any standards-compliant Ada compiler, such as GNAT. Thanks, I'll use this description. signature.asc Description: Digital signature
Bug#612879: ImportError: cannot import name HttpResponse
severity 612879 grave
thanks
This was caused by restkit changes. There is a new upstream version that
should fix this. I'll package it ASAP.
Regards,
Eugeniy Meshcheryakov
11 лютого 2011 о 04:23 -0500 Jason Woofenden написав(-ла):
Now when I say couchapp push I get this:
Traceback (most recent call last):
File /usr/bin/couchapp, line 9, in module
load_entry_point('Couchapp==0.7.2', 'console_scripts', 'couchapp')()
File /usr/lib/python2.6/dist-packages/pkg_resources.py, line 305, in
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File /usr/lib/python2.6/dist-packages/pkg_resources.py, line 2244, in
load_entry_point
return ep.load()
File /usr/lib/python2.6/dist-packages/pkg_resources.py, line 1954, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
File /usr/lib/pymodules/python2.6/couchapp/dispatch.py, line 10, in
module
import couchapp.commands as commands
File /usr/lib/pymodules/python2.6/couchapp/commands.py, line 15, in
module
from couchapp import clone_app
File /usr/lib/pymodules/python2.6/couchapp/clone_app.py, line 16, in
module
from couchapp import client
File /usr/lib/pymodules/python2.6/couchapp/client.py, line 17, in module
from restkit import Resource, HttpResponse, ResourceError, request
ImportError: cannot import name HttpResponse
zsh: exit 1 couchapp push
signature.asc
Description: Digital signature
Bug#603902: ITP: couchapp -- Standalone CouchDB Application Development Made Simple
retitle 603902 ITP: couchapp -- Standalone CouchDB Application Development Made Simple thanks Changing package name back to couchapp because it seems there are many packages that do not use name python-* and have files under pyshared. 20 листопада 2010 о 01:27 +0100 Eugeniy Meshcheryakov написав(-ла): This package contains some non-free parts (jsmin). I contacted authors. Let's see what they think about this... Upstream maintainers will look for free solution. jsmin is optional and will be removed in the Debian package. signature.asc Description: Digital signature
Bug#603902: ITP: couchapp -- Standalone CouchDB Application Development Made Simple
This package contains some non-free parts (jsmin). I contacted authors. Let's see what they think about this... signature.asc Description: Digital signature
Bug#603902: ITP: couchapp -- Standalone CouchDB Application Development Made Simple
retitle 603902 ITP: python-couchapp -- Standalone CouchDB Application Development Made Simple thanks This package provides some public python modules, so to comply with python policy binary package name will be python-couchapp. 18 листопада 2010 о 10:41 +0100 Євгеній Мещеряков написав(-ла): Package: wnpp Severity: wishlist Owner: Євгеній Мещеряков eu...@debian.org * Package name: couchapp Version : 0.7.1 Upstream Author : Benoit Chesneau beno...@e-engura.com * URL : http://couchapp.org * License : Apache Programming Lang: Python, JavaScript Description : Standalone CouchDB Application Development Made Simple CouchApp is a set of helpers and a jQuery plugin that conspire to get you up and running on CouchDB quickly and correctly. It brings clarity and order to the freedom of CouchDB's document-based approach. signature.asc Description: Digital signature
Bug#579786: RFA: w3-recs -- Recommendations of the World Wide Web Consortium (W3C)
Hello, 18 жовтня 2010 о 03:03 +0200 Colin Darie написав(-ла): I worked on it some months ago. Since the last upload two years ago, there have been many changes required to update the package with the new and updated recommendations. I don't have a lot of time right now, but I worked tonight on it and I'll try to upload a new version ASAP. However if you want, you too can work on it of course. I migrated the repo from svn to git : http://git.debian.org/?p=collab-maint/w3-recs.git Thanks for updating the package. It builds fine for me. But getting all those files from internet takes a lot of time, probably because wget opens a new connection for every file. Sounds like a bug in wget, or is it only on my system? Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#579786: RFA: w3-recs -- Recommendations of the World Wide Web Consortium (W3C)
Hello Colin, Are you still interested in adopting w3-recs? If not, then I'm interested in doing so. Regards, Eugeniy Meshcheryakov 7 травня 2010 о 18:46 +0200 Colin Darie написав(-ла): retitle 579786 ITA: w3-recs -- Recommendations of the World Wide Web Consortium (W3C) owner 579786 ! thanks signature.asc Description: Digital signature
Bug#599299: coccinelle: should use dh-ocaml = 0.9
Hello, 6 жовтня 2010 о 15:55 +0200 Stéphane Glondu написав(-ла): coccinelle should be migrated to dh-ocaml = 0.9. What is special in this version? Anything that should be changed in the package or just build-depends? Should I upload to unstable or experimental? Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#595674: chromium-browser: Number formating in cssText property of CSSRule is locale-dependent
6 вересня 2010 о 09:01 +0200 Mike Hommey написав(-ла): Except that fixing in webkit won't fix it in chromium, since chromium uses its own webkit. Yeah, but I guess fixing the bug in chromium will not happen before fixing it in webkit :/. signature.asc Description: Digital signature
Bug#595674: chromium-browser: Number formating in cssText property of CSSRule is locale-dependent
block 595674 by 535780 forwarded 535780 https://bugs.webkit.org/show_bug.cgi?id=18994 thanks This is actually bug in webkit (but not in Qt version). Also reported in Debian BTS as #535780. 5 вересня 2010 о 19:27 +0200 Євгеній Мещеряков написав(-ла): Package: chromium-browser Version: 6.0.472.53~r57914-2 Severity: normal Forwarded: https://code.google.com/p/chromium/issues/detail?id=54553 I reported this bug as Issue 54553 here is the copy. Attachements are available here: https://code.google.com/p/chromium/issues/detail?id=54553 Chrome Version (from the about:version page): 6.0.472.53 Is this the most recent version: most recent in Debian/experimental OS + version: Debian unstable+experimental CPU architecture (32-bit / 64-bit): amd64 Window manager: KDE URLs (if relevant): Behavior in Linux Firefox: bug is not reproducible Behavior in Windows Chrome (if you have access to it): What steps will reproduce the problem? 1. Open attached test.html in chrome running under uk_UA.UTF-8 locale (or de_DE, or other where comma is used for decimal separator). 2. Observe that value 0.5em is printed as 0,5em. 3. Notice that it is not a valid CSS fragment. What is the expected result? Value printed as 0.5em (with decimal dot). And entire text should be valid CSS. What happens instead? Number printed with comma and text fragment is not a valid CSS. Please provide any additional information below. Attach a screenshot and backtrace if possible. The bug does not happen with chrome run in en_US.UTF-8 locale (only because decimal separator is dot there). It also does not happen in Arora, Iceweasel and Konqueror, independent of locale. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.36-rc3 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages chromium-browser depends on: ii chromium-browser-ins 6.0.472.53~r57914-2 page inspector for the chromium-br ii libasound2 1.0.23-1shared library for ALSA applicatio ii libatk1.0-0 1.30.0-1The ATK accessibility toolkit ii libbz2-1.0 1.0.5-5 high-quality block-sorting file co ii libc62.11.2-5Embedded GNU C Library: Shared lib ii libcairo21.9.14-1The Cairo 2D vector graphics libra ii libcups2 1.4.4-3 Common UNIX Printing System(tm) - ii libdbus-1-3 1.2.24-3simple interprocess messaging syst ii libdbus-glib-1-2 0.88-2 simple interprocess messaging syst ii libevent-1.4-2 1.4.13-stable-1 An asynchronous event notification ii libexpat12.0.1-7 XML parsing C library - runtime li ii libfontconfig1 2.8.0-2.1 generic font configuration library ii libfreetype6 2.4.2-2 FreeType 2 font engine, shared lib ii libgcc1 1:4.5.1-2 GCC support library ii libgconf2-4 2.28.1-3GNOME configuration database syste ii libgcrypt11 1.4.5-2 LGPL Crypto library - runtime libr ii libgl1-mesa-glx [lib 7.8.2-2 A free implementation of the OpenG ii libglewmx1.5 1.5.4-1 The OpenGL Extension Wrangler - ru ii libglib2.0-0 2.24.1-1The GLib library of C routines ii libgtk2.0-0 2.20.1-1+b1 The GTK+ graphical user interface ii libicu44 4.4.1-6 International Components for Unico ii libjpeg626b1-1 The Independent JPEG Group's JPEG ii libnspr4-0d 4.8.6-1 NetScape Portable Runtime Library ii libnss3-1d 3.12.7-1Network Security Service libraries ii libpango1.0-01.28.1-1Layout and rendering of internatio ii libpng12-0 1.2.44-1PNG library - runtime ii libstdc++6 4.5.1-2 The GNU Standard C++ Library v3 ii libv8-2.2.24 2.2.24-5V8 JavaScript Engine ii libvpx0 0.9.1-1 VP8 video codec (shared library) ii libx11-6 2:1.3.3-3 X11 client-side library ii libxext6 2:1.1.2-1 X11 miscellaneous extension librar ii libxml2 2.7.7.dfsg-4GNOME XML library ii libxrender1 1:0.9.6-1 X Rendering Extension client libra ii libxslt1.1 1.1.26-6XSLT 1.0 processing library - runt ii libxss1 1:1.2.0-2 X11 Screen Saver extension library ii xdg-utils1.0.2+cvs20100307-1 desktop integration utilities from ii zlib1g 1:1.2.3.4.dfsg-3
Bug#591325: initramfs-tools: kernel does not boot without network connection
reassign 591325 nbd-client thanks 2 серпня 2010 о 20:50 +0200 Michael Prokop написав(-ла): Recently during boot initramfs started to send DHCP RARP request to all network interfaces. This behaviour was not observed before and I changed nothing in initramfs-tools configuration for long time. This can be because I started to use dhcp for network configuration (using NetworkManager, and not for network boot boot) or just because I installed new kernel. The result is that kernel fail to boot if there is no network connection, so severity is grave. initramfs just displays repeatedly messages about timeout and giving up, but does not really give up. Does it work for you if you downgrade klibc-utils from 1.5.18-1 to 1.5.12 (available in stable + snapshots)? Does booting with ip=off work around this issue? Thanks, ip=off helped, there was also some error from nbd visible. Uninstalling nbd-client fixed the problem completely. So I guess this is a bug in nbd-client. Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#588931: libqtassistantclient4: shoud provide libqt4-assistant
Hmm, just provides does not work. Maybe it is possible to provide transitional dummy package? 13 липня 2010 о 16:10 +0200 Євгеній Мещеряков написав(-ла): Package: libqtassistantclient4 Severity: wishlist It will be great if libqtassistantclient4 would provide libqt4-assistant so some packages from unstable that require libqt4-assistant can be used with qt from experimental. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.35-rc4+ (SMP w/2 CPU cores; PREEMPT) Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash signature.asc Description: Digital signature
Bug#585497: systemtap-doc: error messages from dhelp while indexing langref.pdf
I tried to debug this, but it looks very strange.
The cmap looks like this:
311 0 obj
/Length 294stream
/CIDInit /ProcSet findresource begin
12 dict begin
begincmap
/CMapType 2 def
/CMapName/R857 def
1 begincodespacerange
endcodespacerange
3 beginbfrange
000f000f2022
00660066007b
00670067007d
endbfrange
endcmap
CMapName currentdict /CMap defineresource pop
end end
endstream
endobj
From reading of pdf spec I can say that bfrange syntax is valid.
parseCMap1() function that calls error() is in poppler. The code there
looks like this:
if (!strcmp(tok3, [)) {
} else if (tok3[0] == '' tok3[n3 - 1] == '') {
} else {
error(-1, Illegal entry in bfrange block in ToUnicode CMap);
}
On call to error gdb shows:
(gdb) print (char *)tok3
$15 = 0x7fffda543fc0 007d
(gdb) print n3
$16 = 6
(gdb) print tok3[n3-1]
$18 = 62 ''
(gdb) print (tok3[0] == '' tok3[n3 - 1] == '')
$19 = true
Now if anyone can tell me why branch with call to error() is executed
instead of previous one...
22 червня 2010 о 12:52 -0400 Frank Ch. Eigler написав(-ла):
#0 error (pos=-1,
msg=0x351ad4bbf8 Illegal entry in bfrange block in ToUnicode CMap)
at Error.cc:56
#1 0x00351aca2f8a in CharCodeToUnicode::parseCMap1 (
this=value optimized out, getCharFunc=value optimized out,
data=value optimized out, nBits=value optimized out)
at CharCodeToUnicode.cc:343
signature.asc
Description: Digital signature
Bug#585497: systemtap-doc: error messages from dhelp while indexing langref.pdf
clone 585497 -1
reassign -1 libpoppler5
forcemerge 578050 -1
block 585497 by -1
thanks
It is actually a known bug in poppler. Let's clone it there.
This bug can be reproduced with langref.pdf file from systemtap-doc
package.
22 червня 2010 о 20:50 +0200 Eugeniy Meshcheryakov написав(-ла):
I tried to debug this, but it looks very strange.
The cmap looks like this:
311 0 obj
/Length 294stream
/CIDInit /ProcSet findresource begin
12 dict begin
begincmap
/CMapType 2 def
/CMapName/R857 def
1 begincodespacerange
endcodespacerange
3 beginbfrange
000f000f2022
00660066007b
00670067007d
endbfrange
endcmap
CMapName currentdict /CMap defineresource pop
end end
endstream
endobj
From reading of pdf spec I can say that bfrange syntax is valid.
parseCMap1() function that calls error() is in poppler. The code there
looks like this:
if (!strcmp(tok3, [)) {
} else if (tok3[0] == '' tok3[n3 - 1] == '') {
} else {
error(-1, Illegal entry in bfrange block in ToUnicode CMap);
}
On call to error gdb shows:
(gdb) print (char *)tok3
$15 = 0x7fffda543fc0 007d
(gdb) print n3
$16 = 6
(gdb) print tok3[n3-1]
$18 = 62 ''
(gdb) print (tok3[0] == '' tok3[n3 - 1] == '')
$19 = true
Now if anyone can tell me why branch with call to error() is executed
instead of previous one...
22 червня 2010 о 12:52 -0400 Frank Ch. Eigler написав(-ла):
#0 error (pos=-1,
msg=0x351ad4bbf8 Illegal entry in bfrange block in ToUnicode CMap)
at Error.cc:56
#1 0x00351aca2f8a in CharCodeToUnicode::parseCMap1 (
this=value optimized out, getCharFunc=value optimized out,
data=value optimized out, nBits=value optimized out)
at CharCodeToUnicode.cc:343
signature.asc
Description: Digital signature
Bug#585497: systemtap-doc: error messages from dhelp while indexing langref.pdf
22 червня 2010 о 21:01 +0200 Eugeniy Meshcheryakov написав(-ла): 1 begincodespacerange endcodespacerange 3 beginbfrange 000f000f2022 00660066007b 00670067007d endbfrange I recompiled poppler without optimization and now gdb shows that error() is called from line 312 in CharCodeToUnicode.cc. There code expects that ranges will contain only 2 digits. This is strange because cmap specifies 2-byte codespace. PDF 1.7 spec contains (5.9.2): The CMap file must contain begincodespacerange and endcodespacerange operators that are consistent with the encoding that the font uses. In particular, for a simple font, the codespace must be one byte long. And font that references this ToUnicode cmap also references encoding that has WinAnsiEncoding as base. And this is I guess 1-byte encoding, so maybe this ToUnicode cmap is inconsistent with the font. If this is true then this is not a bug in poppler and pdflatex should be fixed. signature.asc Description: Digital signature
Bug#567942: coccinelle: preparation for python 2.6 transition
Hi Steve, I'll upload fixed version of coccinelle later today. I think no build-dependency on python*-dev is needed. Regards, Eugeniy Meshcheryakov 20 червня 2010 о 16:00 -0700 Steve Langasek написав(-ла): Hi Eugeniy, pycaml has been transitioned now to python2.6 in unstable. Is there anything else holding up the fix for this bug? I realize it's only been RC for three days, so apologies if I'm jumping the gun here. Is the correct fix to drop the python2.5-dev build-dependency altogether, or to replace it with python-dev? A build-dep on python2.6-dev definitely looks wrong to me. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#586656: libpycaml-ocaml-dev: package cannot be installed with aptitude
21 червня 2010 о 14:18 +0200 Євгеній Мещеряков написав(-ла): Conflict on pycaml should be versioned. Also IMHO those package should Replace pycaml. Sorry, i missed that those packages already replace pycaml. signature.asc Description: Digital signature
Bug#567942: coccinelle: preparation for python 2.6 transition
tags 567942 - patch thanks This package only needs change in build-dependency, but only after compiling pycaml with python 2.6. The patch from Ubuntu is not needed. 12 червня 2010 о 12:35 +0200 Jakub Wilk написав(-ла): severity 567942 important thanks * Bhavani Shankar right2bh...@gmail.com, 2010-02-01, 17:28: In Ubuntu, we've applied the attached patch to achieve the following: * Merge from debian testing. Remaining changes: - debian/control: build-depend on python2.6-dev, set XB-Python-Version to 2.6 We would prefer a patch that does not hardcode any Python versions. -- Jakub Wilk signature.asc Description: Digital signature
Bug#529826: xserver-xorg-video-intel: excessive memory usage with okular
Hello, I don't have a computer with intel graphics anymore, so I cannot reproduce the bug. Regards, Eugeniy Meshcheryakov 10 квітня 2010 о 18:57 +0200 Julien Cristau написав(-ла): Євгеній, can you still reproduce this with the current X stack (and kernel) in sid? If so, please report the bug upstream to bugs.freedesktop.org, following the instructions at http://intellinuxgraphics.org/how_to_report_bug.html Thanks for your report! Cheers, Julien signature.asc Description: Digital signature
Bug#572493: qtcreator: starts very slowly with qt 4.6.2-1 from experimental
Hello, I did some testing and I think that this delay is related to rebuilding of help index (probably triggered by qt update). I can easily reproduce this bug by removing file ~/.config/Nokia/qtcreator/helpcollection.qhc and running qtcreator. Then I have to wait several minutes for the main window. strace also showed that qtcreator writes to this file at that time (at leas some threads). I do not know why qtcreator also terminates very slowly after that. Passing -noload Help makes startup fast, but then there is no help :(. I cannot yet find a good way to make it start fast again. I did this once (by removing some files under ~/.config several times in different order) but cannot do this now :(. 4 березня 2010 о 18:30 -0600 Adam Majer написав(-ла): On Thu, Mar 04, 2010 at 03:31:02PM +0100, Євгеній Мещеряков wrote: Package: qtcreator Version: 1.3.1-1 Severity: normal After upgrading to qt 4.6.2-1 qtcreator takes long time (several minutes) to start. Usually it took only 1-2 seconds to start. I *think* I've seen something about this in some changes. I suspect this may have something to do with DNS resolution and/or RSS feed. Can you try how long it takes to startup if you stop your network connection? Nothing changes if the computer has no network connection. Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#568866: RFA: systemtap -- instrumentation system for Linux 2.6
retitle 568866 O: systemtap -- instrumentation system for Linux 2.6 thanks Hello, I'm orphaning this package now. If you want to maintain it, it's yours. If you have questions about packaging I can help, but I don't have time to co-maintain it. Git repository is available in collab-main group on git.debian.org. I packaged latest version only for experimental because I had no time to make sure that -client and -server packages work correctly and have correct dependencies. Everything else there should be ok. 8 лютого 2010 о 15:32 +0100 Lucas Nussbaum написав(-ла): I would be interested in co-maintaining systemtap. However, I'm not sure that we should continue to try to provide a systemtap package, given that it doesn't work out of the box because of #365349. (summary: systemtap requires kernel built with debug info, which can be split into a seperate package, but still requires quite a lot of archive space (~300MiB per arch), and space on the buildd while building ( 2GiB)) Yes, that's all true. Additionally building the kernel with debuginfo requires a lot of time, at least on my system. IIRC some people proposed/tried to implement debuginfo subsetting/compression in gcc, but I'm not sure about present status. Anyway even without support for official kernel systemtap can be useful for kernel development. It's pretty sad, because Debian is currently the only major distro where systemtap doesn't work out of the box. Yes, that is sad. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Bug#568809: CVE-2010-0411 systemtap: Crash with systemtap script using __get_argv()
found 568809 0.0.20061028-2 found 568809 0.0.20080705-1+lenny1 found 568809 1.0-2 found 568809 1.1-1 thanks Hello, I can confirm that this bug is present in all version currently in archive (not a security bug for oldstable because it did not handle stapusr group). 7 лютого 2010 о 22:33 +0100 Moritz Muehlenhoff написав(-ла): Package: systemtap Severity: important Tags: security Hi Evgeniij, please see https://bugzilla.redhat.com/show_bug.cgi?id=559719 for details. This issue doesn't warrant a DSA. If the affected code is present in Lenny, if would be nice if you could fix it through a stable point update. Cheers, Moritz -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/1 CPU core) Locale: LANG=C, lc_ctype=de_de.iso-8859...@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages systemtap depends on: ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib ii libelf1 0.143-1library to read and write ELF file ii libgcc1 1:4.4.3-2 GCC support library ii libsqlite3-0 3.6.22-1 SQLite 3 shared library ii libstdc++64.4.3-2The GNU Standard C++ Library v3 pn systemtap-runtime none (no description available) systemtap recommends no packages. Versions of packages systemtap suggests: pn systemtap-doc none (no description available) pn vim-addon-manager none (no description available) signature.asc Description: Digital signature
Bug#568866: RFA: systemtap -- instrumentation system for Linux 2.6
It seems that this bug was not forwarded to debian-devel automatically. Let's try to do this now. 8 лютого 2010 о 14:06 +0100 Євгеній Мещеряков написав(-ла): Package: wnpp Severity: normal I request an adopter for the systemtap package. I have no time to properly support this package anymore. The package has two open security bugs. One of them should be fixed in version from experimental, but systemtap-server in this version does not work in Debian. Patch for the other bug is available. Otherwise package is bugs-clean (but it is ifluenced by some bugs in elfutils, new version should fix some of them). The package description is: SystemTap provides infrastructure to simplify the gathering of information about the running Linux system. This assists diagnosis of a performance or functional problem. SystemTap eliminates the need for the developer to go through the tedious and disruptive instrument, recompile, install, and reboot sequence that may be otherwise required to collect data. . SystemTap provides a simple command line interface and scripting language for writing instrumentation for a live running system. signature.asc Description: Digital signature
Bug#556133: Segfault when reading a debug-only file.
Hello Kurt, Could you fix this bug, it seems that it causes problems to more systemtap users (http://sourceware.org/ml/systemtap/2010-q1/msg00254.html). 3 грудня 2009 о 11:53 +0100 Eugeniy Meshcheryakov написав(-ла): Hello Kurt, I tried this patch and systemtap works fine with it. There are no segfaults and at least with simple tests result is correct. Regards, Eugeniy Meshcheryakov 17 листопада 2009 о 19:21 +0100 Kurt Roeckx написав(-ла): On Mon, Nov 16, 2009 at 08:39:04PM -0800, Roland McGrath wrote: I fixed the remaining crash. Can you try the attached patch? It fixes the segfault for me, but it also seems to produce weird output in eu-readelf. Kurt diff --git a/libdwfl/relocate.c b/libdwfl/relocate.c index a31fe15..2e37c64 100644 --- a/libdwfl/relocate.c +++ b/libdwfl/relocate.c @@ -302,6 +302,10 @@ relocate_section (Dwfl_Module *mod, Elf *relocated, const GElf_Ehdr *ehdr, if (tname == NULL) return DWFL_E_LIBELF; + if (unlikely (tshdr-sh_type == SHT_NOBITS) || unlikely (tshdr-sh_size == 0)) +/* No contents to relocate. */ +return DWFL_E_NOERROR; + if (debugscn ! ebl_debugscn_p (mod-ebl, tname)) /* This relocation section is not for a debugging section. Nothing to do here. */ signature.asc Description: Digital signature
Bug#541351: RFP: xfoil -- Interactive program for the design and analysis of subsonic airfoils
tags 541351 + pending thanks Hello Mauro, 29 грудня 2009 о 21:47 +0100 Eugeniy Meshcheryakov написав(-ла): package it. One problem with this program is that it does not contain license information in the source package (only on the web page). I'll try to contact authors after checking whether everything else is ok. I was looking in wrong place, some files have headers that say that program is distributed under GPL. It only files under orrs dont have them. Hopefully this is ok. I uploaded debian package, while it is in new queue it is also available here: http://people.debian.org/~eugen/xfoil/ I was not able to build working osmap.dat (generated file contains a lot of NaN's), so it is not included in debian package for now. Were you able to build it? Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#541351: RFP: xfoil -- Interactive program for the design and analysis of subsonic airfoils
retitle 541351 ITP: xfoil -- Interactive program for the design and analysis of subsonic airfoils owner 541351 ! thanks Hello, I was able to compile all programs with current gfortran and I'll try to package it. One problem with this program is that it does not contain license information in the source package (only on the web page). I'll try to contact authors after checking whether everything else is ok. 13 серпня 2009 о 18:08 +0200 Mauro Darida написав(-ла): Package: wnpp Severity: wishlist * Package name: xfoil Version : 6.97 Upstream Author : Mark Drela and Harold Youngren * URL : http://web.mit.edu/drela/Public/web/xfoil * License : GPL Programming Lang: Fortran Description : Interactive program for the design and analysis of subsonic airfoils (Include the long description here.) It consists of a collection of menu-driven routines which perform various useful functions such as: Viscous (or inviscid) analysis of an existing airfoil, allowing forced or free transition transitional separation bubbles limited trailing edge separation lift and drag predictions just beyond CLmax Karman-Tsien compressibility correction fixed or varying Reynolds and/or Mach numbers Airfoil design and redesign by interactive modification of surface speed distributions, in two methods: Full-Inverse method, based on a complex-mapping formulation Mixed-Inverse method, an extension of XFOIL's basic panel method Airfoil redesign by interactive modification of geometric parameters such as max thickness and camber, highpoint position LE radius, TE thickness camber line via geometry specification camber line via loading change specification flap deflection explicit contour geometry (via screen cursor) Blending of airfoils Writing and reading of airfoil coordinates and polar save files Plotting of geometry, pressure distributions, and multiple polars NOTE: The program consists of 3 source codes: xfoil, pplot and px_plot. I have successfully compiled xfoil and pplot with the Fortran GNU compiler; it gives an error with px_plot and I was unable to contact the upstream author (I am no expert, maybe it needs a simple fix). I am aware of a very old debian unofficial package of this software, no longer maintained. It would be nice to see it in debian. -- System Information: Debian Release: 4.0 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19.1 Locale: lang=en...@euro, lc_ctype=en...@euro (charmap=ISO-8859-15) signature.asc Description: Digital signature
Bug#556133: Segfault when reading a debug-only file.
Hello Kurt, I tried this patch and systemtap works fine with it. There are no segfaults and at least with simple tests result is correct. Regards, Eugeniy Meshcheryakov 17 листопада 2009 о 19:21 +0100 Kurt Roeckx написав(-ла): On Mon, Nov 16, 2009 at 08:39:04PM -0800, Roland McGrath wrote: I fixed the remaining crash. Can you try the attached patch? It fixes the segfault for me, but it also seems to produce weird output in eu-readelf. Kurt diff --git a/libdwfl/relocate.c b/libdwfl/relocate.c index a31fe15..2e37c64 100644 --- a/libdwfl/relocate.c +++ b/libdwfl/relocate.c @@ -302,6 +302,10 @@ relocate_section (Dwfl_Module *mod, Elf *relocated, const GElf_Ehdr *ehdr, if (tname == NULL) return DWFL_E_LIBELF; + if (unlikely (tshdr-sh_type == SHT_NOBITS) || unlikely (tshdr-sh_size == 0)) +/* No contents to relocate. */ +return DWFL_E_NOERROR; + if (debugscn ! ebl_debugscn_p (mod-ebl, tname)) /* This relocation section is not for a debugging section. Nothing to do here. */ signature.asc Description: Digital signature
Bug#549861: ....
Hello, Thanks for reply. This option will probably fix problem with systems with clock set to local timezone, but not for systems like FreeRunner where clock content is lost when battery is removed. It will be good to have option that disables mount time in the future check entirely. 14 листопада 2009 о 15:57 -0500 Theodore Tso написав(-ла): There are a number of workarounds. One is to take the kernel patch (or upgrading to 2.6.32, which will have the fix). Or you can fix your system clock to tick GMT, as opposed to localtime, which is fraught with all sorts of problems, especially around the transition in and out of summer-time/daylight savings time. Or you add the following stanza to /etc/e2fsck.conf: [options] buggy_init_scripts = 1 One could just as easily argue that the real bug is having the hardware CMOS time tick in localtime. Granted we should make the system more robust against people who incorrectly set their system clock to be bug-for-bug compatible with Microsoft, but in no way does this justify increasing the severity to grave. In fact we do have changes pending in e2fsprogs and in the kernel to make things more robust against brain-damaged configurations. See commit ba5131f6 in the e2fsprogs maint branch. Until these changes find their way into Debian packages, my recommendation is to either (a) fix your hardware clock to tick UTC time, or (b) apply the buggy_init_scripts workaround to /etc/e2fsck.conf. - Ted signature.asc Description: Digital signature
Bug#549861: ....
15 листопада 2009 о 16:58 -0500 Theodore Tso написав(-ла):
Note that the file system isn't the only place that might assume that
time is correct. For example, the UUID generation algorithm derives
its uniqueness guarantees from the fact that time is correctly set.
If you don't have an accurate clock, you may have all sorts of strange
behavior as a result.
It easy to set time after boot, so this is not so big problem.
As far as the FreeRunner is concerned, it currently takes me under 8
seconds to check a 70gig SSD drive. If you put 8GB SD card into the
FreeRunner smartphone, the first check after a failed battery should
take at most a second. Hardly worth people going into hysterics and
calling this a grave bug.
The problem is not the check itself, but that e2fsck asks for root
password to continue, and this device has no keyboard...
If you really want to disable the future check, you can do this:
[problems]
0x31 = {
preen_ok = true
}
0x32 = {
preen_ok = true
}
Thanks, I'll try this.
I consider this a botch to work around broken hardware, though...
- Ted
signature.asc
Description: Digital signature
Bug#549861: ....
15 листопада 2009 о 17:13 -0500 Theodore Tso написав(-ла): Just to set the record straight, that's not e2fsck, but the init scripts. E2fsck never prompts for any passwords. Oh, now I found what I wanted. I think adding FSCKFIX=yes into /etc/default/rcS should fix problem for FreeRunner. Thanks signature.asc Description: Digital signature
Bug#555549: libdw1: should not require .debug extension for kernel modules debug info
13 листопада 2009 о 15:21 +0100 Kurt Roeckx написав(-ла): So my understanding of the code is that it gets a list of path's to look at. It does: const Dwfl_Callbacks *const cb = mod-dwfl-callbacks; char *path = strdupa ((cb-debuginfo_path ? *cb-debuginfo_path : NULL) ?: DEFAULT_DEBUGINFO_PATH); And the default is: libdwflP.h:#define DEFAULT_DEBUGINFO_PATH :.debug:/usr/lib/debug systemtap seems to be changing the debuginfo_path. Yes, it changes it to +:.debug:/usr/lib/debug:build or to $SYSTEMTAP_DEBUGINFO_PATH if it is set. I tried to set SYSTEMTAP_DEBUGINFO_PATH to different values and found that libdw stops trying to open files after empty directory. For example it finds debuginfo (and crashes systemtap) if i remove first colon. Or move it to the end. Comment in find-debuginfo.c says: /* An empty entry says to try the main file's directory. */ So systemtap's debuginfo_path looks correct. signature.asc Description: Digital signature
Bug#555549: libdw1: should not require .debug extension for kernel modules debug info
13 листопада 2009 о 19:03 +0100 Kurt Roeckx написав(-ла): So I'm guessing that it opens the file in /lib/modules/ calls the validate() function which says it was succesful, while the file actually doesn't have any debug info? It looks so. It it possible for validate() to actualy check if there is debuginfo in the file? Another solution is not to use empty path in systemtap, but I guess this will be broken if modules under /lib/modules already have debug info... I assume that systemtap crashing is some other (non-related) problem? I guess so, this only happens when file with only debuginfo is found. signature.asc Description: Digital signature
Bug#555549: libdw1: should not require .debug extension for kernel modules debug info
13 листопада 2009 о 19:03 +0100 Kurt Roeckx написав(-ла): So I'm guessing that it opens the file in /lib/modules/ calls the validate() function which says it was succesful, while the file actually doesn't have any debug info? Also it is strange that validate() is successful because as I understand .gnu_debuglink aslo contains checksum, and it should be different that one of the original .ko. signature.asc Description: Digital signature
Bug#555549: libdw1: should not require .debug extension for kernel modules debug info
13 листопада 2009 о 21:00 +0100 Kurt Roeckx написав(-ла): On Fri, Nov 13, 2009 at 08:33:59PM +0100, Eugeniy Meshcheryakov wrote: 13 ? 2009 ? 19:03 +0100 Kurt Roeckx ???(-??): So I'm guessing that it opens the file in /lib/modules/ calls the validate() function which says it was succesful, while the file actually doesn't have any debug info? Also it is strange that validate() is successful because as I understand .gnu_debuglink aslo contains checksum, and it should be different that one of the original .ko. As I understand it that's in the .note.gnu.build-id, and they should be identical. It's how you can be sure they are about the same binary. In the log files you show, it's also trying /usr/lib/debug/.build-id/8d/19f404d7db2242e69c87419b8fd32f67fca584.debug That 19f404d7db2242e69c87419b8fd32f67fca584 is the build-id stored in the .note.gnu.build-id. Yes, but checking also crc for modules found using gnu_debuglink (unlike those that found under .build_id) should fix the bug... And break not stripped modules :/ signature.asc Description: Digital signature
Bug#549861: ....
13 листопада 2009 о 19:43 -0500 Theodore Tso написав(-ла): (1) I'm the maintainer. (2) The bug doesn't even vaguely fit the definition of grave: makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package This bug however makes some systems unusable for no good reason. And it does not look like a hard to fix bug at all. You are being abusive by trying to yank up the severity of the bug. Go away. signature.asc Description: Digital signature
Bug#555549: libdw1: should not require .debug extension for kernel modules debug info
Hello, 11 листопада 2009 о 22:23 +0100 Kurt Roeckx написав(-ла): Are you sure this is libdw's problem? The name of the file should be stored in the .gnu_debuglink section of the elf file. Maybe you are right... This name can be set using objcopy's --add-gnu-debuglink, and that is what things like dh_strip do. I tried to do this: objcopy \ --add-gnu-debuglink=/usr/lib/debug/lib/modules/2.6.32-rc6/kernel/sound/core/snd.ko \ /lib/modules/2.6.32-rc6/kernel/sound/core/snd.ko But it looks like it only adds snd.ko to the .gnu_debuglink section: # objdump -s -j .gnu_debuglink /lib/modules/2.6.32-rc6/kernel/sound/core/snd.ko ... Contents of section .gnu_debuglink: 736e642e 6b6f 944978ab snd.ko...Ix. And then systemtap looks only at file under /lib/modules: open(/lib/modules/2.6.32-rc6/kernel/sound/core/snd.ko, O_RDONLY) = 3 open(/usr/lib/../lib/elfutils/libebl_x86_64.so, O_RDONLY) = 3 open(/usr/lib/debug/.build-id/8d/19f404d7db2242e69c87419b8fd32f67fca584.debug, O_RDONLY) = -1 ENOENT (No such file or directory) open(/lib/modules/2.6.32-rc6/kernel/sound/core/snd.ko, O_RDONLY) = 3 WARNING: cannot find module snd debuginfo: No DWARF information found As I understand the code, find-debuginfo.c:find_debuginfo_in_path() uses a default with .debug if no debuglink is set. It looks like it does not try to look under /usr/lib/debug... signature.asc Description: Digital signature
Bug#555549: libdw1: should not require .debug extension for kernel modules debug info
By the way, this was started here: http://sourceware.org/ml/systemtap/2009-q4/msg00478.html It seems that there is probably one more bug in libdw that causes systemtap to segfault. But I did not check yet, this can also be bug in systemtap itself. signature.asc Description: Digital signature
Bug#555549: libdw1: should not require .debug extension for kernel modules debug info
10 листопада 2009 о 10:49 +0100 Євгеній Мещеряков написав(-ла): but it can be found here: /lib/modules/2.6.32-rc6/kernel/sound/core/snd.ko /usr/lib/debug/lib/modules/2.6.32-rc6/kernel/sound/core/snd.ko signature.asc Description: Digital signature
Bug#554694: FTBFS with binutils-gold
Hello, 6 листопада 2009 о 09:32 +0300 Dmitry E. Oboukhov написав(-ла): Goldendict are built by qt4-qmake. I think that You should report about such projects in qt4-qmake package, because just qt4-qmake generates linker call command. I think that it is the same as packages which are under automake/autoconf. It looks like your package uses Xlib directly and does not links with it. IMHO it is not qmakes fault, it cannot know what libraries your package needs, its work is to link with Qt. Other libraries should be specified additionaly. You buried me with the same bugs, but only one really touched my package. I think You should find out which specific a package has a bug before submit bugreports. For example: fluxbox is built with autotools. goldendict is built with qt4-qmake. Do You suggest me to patch all these packages? IMHO that is the right thing to do. Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#552375: readahead-fedora: machine fails to boot after installation
Hello, 25 жовтня 2009 о 22:37 -0600 Raphael Geissert написав(-ла): The init script is supposed to warn and exit if it detects that the kernel was not built with the necessary options. This check relies on the existance of /boot/config-$(uname -r), do you by some reason not have it? If the options are not enabled and the config file exists you should see a message similar to: Profiling on a kernel without audit subsystem...failed! I have /boot/config-2.6.32-rc5 but there was no error message. It is probably because I have separate /boot to be able to install grub (root is ext4), and I guess /boot is not mounted by then. Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#552375: readahead-fedora: machine fails to boot after installation
25 жовтня 2009 о 22:37 -0600 Raphael Geissert написав(-ла): The init script is supposed to warn and exit if it detects that the kernel was not built with the necessary options. This check relies on the existance of /boot/config-$(uname -r), do you by some reason not have it? After looking into kernel source, maybe it is better to check for /proc/1/loginuid (or sessionid), if proc is mounted at that time? signature.asc Description: Digital signature
Bug#552375: readahead-fedora: machine fails to boot after installation
26 жовтня 2009 о 13:39 -0600 Raphael Geissert написав(-ла): 2009/10/26 Eugeniy Meshcheryakov eu...@debian.org: 25 жовтня 2009 о 22:37 -0600 Raphael Geissert написав(-ла): The init script is supposed to warn and exit if it detects that the kernel was not built with the necessary options. This check relies on the existance of /boot/config-$(uname -r), do you by some reason not have it? After looking into kernel source, maybe it is better to check for /proc/1/loginuid (or sessionid), if proc is mounted at that time? Right, I can add a check for that, but am not quite sure /proc will be available by then (should be there if you use an initrd by initramfs-utils). And that still doesn't guarantee that AUDITSYSCALL is enabled. Well, at least in latest kernel from git code in fs/proc/base.c reads: #ifdef CONFIG_AUDITSYSCALL REG(loginuid, S_IWUSR|S_IRUGO, proc_loginuid_operations), REG(sessionid, S_IRUGO, proc_sessionid_operations), #endif So, those two files are there only if CONFIG_AUDITSYSCALL is defined. Anyway, even if the audit subsystem is not enabled the collector should fail and the boot continue as usually. There was recently a That will be even better. signature.asc Description: Digital signature
Bug#552375: readahead-fedora: machine fails to boot after installation
severity 552375 important thanks Thanks for reply, I'll try to enable audit, but is it possible for readahead-fedora to just fail, if audit is not enabled and give an error message? 25 жовтня 2009 о 23:37 +0100 Michael Biebl написав(-ла): Євгеній Мещеряков wrote: After installtion of readahead-fedora package machine fails to boot. Last messages are: Kernel: Linux 2.6.32-rc5 (SMP w/2 CPU cores; PREEMPT) readahead-fedora relies on the audit kernel subsystem and you are using a self-compiled kernel. I bet you haven't enabled AUDIT, as the default Debian kernels do. signature.asc Description: Digital signature
Bug#552375: readahead-fedora: machine fails to boot after installation
25 жовтня 2009 о 23:37 +0100 Michael Biebl написав(-ла): readahead-fedora relies on the audit kernel subsystem and you are using a self-compiled kernel. I bet you haven't enabled AUDIT, as the default Debian kernels do. This helped. After enabling AUDIT and AUDITSYSCALL machine boots. signature.asc Description: Digital signature
Bug#552150: systemtap: whete's the linux-debug-2.6 suggested package?
Hello, This package can be built using make-kpkg from kernel-package package. There is no debug info packages in the archive, see #492677 and merged and blocking bugs. 23 жовтня 2009 о 20:47 +0200 Cristian Ionescu-Idbohrn написав(-ла): Package: systemtap Version: 1.0-1 Severity: minor Can't find linux-debug-2.6 anywhere :( -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.30-2-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages systemtap depends on: ii libc6 2.10.1-1 GNU C Library: Shared libraries ii libdw10.143-1library that provides access to th ii libelf1 0.143-1library to read and write ELF file ii libgcc1 1:4.4.2-1 GCC support library ii libsqlite3-0 3.6.19-1 SQLite 3 shared library ii libstdc++64.4.2-1The GNU Standard C++ Library v3 ii systemtap-runtime 1.0-1 instrumentation system for Linux 2 systemtap recommends no packages. Versions of packages systemtap suggests: pn linux-debug-2.6 none (no description available) ii linux-headers-2.6-686 [linux- 2.6.30+21 Header files for Linux 2.6-686 ii linux-headers-2.6.24-1-686 [l 2.6.24-6 Header files for Linux 2.6.24 on P ii linux-headers-2.6.26-1-686 [l 2.6.26-13 Header files for Linux 2.6.26-1-68 ii linux-headers-2.6.26-2-686 [l 2.6.26-17 Header files for Linux 2.6.26-2-68 ii linux-headers-2.6.29-2-686 [l 2.6.29-5 Header files for Linux 2.6.29-2-68 ii linux-headers-2.6.30-1-686 [l 2.6.30-6 Header files for Linux 2.6.30-1-68 ii linux-headers-2.6.30-2-686 [l 2.6.30-8 Header files for Linux 2.6.30-2-68 ii linux-image-2.6.24-1-686 [lin 2.6.24-4 Linux 2.6.24 image on PPro/Celeron ii linux-image-2.6.26-1-686 [lin 2.6.26-13 Linux 2.6.26 image on PPro/Celeron ii linux-image-2.6.26-2-686 [lin 2.6.26-17 Linux 2.6.26 image on PPro/Celeron ii linux-image-2.6.29-2-686 [lin 2.6.29-5 Linux 2.6.29 image on PPro/Celeron ii linux-image-2.6.30-1-686 [lin 2.6.30-6 Linux 2.6.30 image on PPro/Celeron ii linux-image-2.6.30-2-686 [lin 2.6.30-8 Linux 2.6.30 image on PPro/Celeron pn systemtap-doc none (no description available) pn vim-addon-manager none (no description available) -- no debconf information Cheers, -- Cristian signature.asc Description: Digital signature
Bug#549861: same problem
Hello, I have the same problem with my laptop, but more importantly also with freerunner mobile phone, where date can be reset to year 2000 (probably hardware bug) and there is no keyboard to run fsck non-interactively. This even happens with clean shutdowns. I think this is also a big (RC) problem for other devices without keyboard. Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#289632: RFP: BrlCAD -- A Combinatorial/Constructive Solid Geometry, solid modeling system
title 289632 RFP: BrlCAD -- A Combinatorial/Constructive Solid Geometry, solid modeling system noowner 289632 thanks Packaging of brlcad requires more time then I have and code quality is worse then I expected. So renaming this bug back to RFP. signature.asc Description: Digital signature
Bug#544224: Git repo
For now git repository for opennurbs is available here: http://git.debian.org/?p=users/eugen/opennurbs.git;a=summary signature.asc Description: Digital signature
Bug#528657: Still works for me
Hello, This one does not segfault, but it also does not print name of the month (and year): % LANG=shs_CA.utf-8 ./cal 5 2009 Sx Sp Se Ke Me Ts Tq 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 If called as ncal it works fine (as before): % LANG=shs_CA.utf-8 ./ncal 5 2009 Pell7ell7e'7llqten 2009 Sp 4 11 18 25 Se 5 12 19 26 Ke 6 13 20 27 Me 7 14 21 28 Ts 1 8 15 22 29 Tq 2 9 16 23 30 Sx 3 10 17 24 31 It also works fine for months with shorter name: LANG=shs_CA.utf-8 ./cal 6 2009 Pelltspe'ntsk 2009 Sx Sp Se Ke Me Ts Tq 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 23 вересня 2009 о 12:28 +0200 Michael Meskes написав(-ла): I wasn't able so far to make cal print this kind of stuff. Could you please try attached ncal binary instead of the one provided by the package? This uses the latest sources taken from FreeBSD with some patches from me. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: mes...@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! signature.asc Description: Digital signature
Bug#528657: closed by Michael Meskes mes...@debian.org (Seems to be fixed)
reopen 528657 thanks % LC_ALL=shs_CA.UTF-8 cal 05 2009 �)����)��� �)��� Sx Sp Se Ke Me Ts Tq 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 zsh: segmentation fault LC_ALL=shs_CA.UTF-8 cal 05 2009 22 вересня 2009 о 13:03 + Debian Bug Tracking System написав(-ла): This is an automatic notification regarding your Bug report which was filed against the bsdmainutils package: #528657: locales: shs_CA locale causes segfault while running cal It has been closed by Michael Meskes mes...@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 Michael Meskes mes...@debian.org by replying to this email. -- 528657: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528657 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems Received: (at 528657-done) by bugs.debian.org; 22 Sep 2009 12:55:49 + X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rietz.debian.org X-Spam-Level: X-Spam-Bayes: score:0. Tokens: new, 27; hammy, 105; neutral, 48; spammy, 0. spammytokens: hammytokens:0.000-+--H*u:1.5.20, 0.000-+--H*UA:1.5.20, 0.000-+--H*u:2009-06-14, 0.000-+--H*UA:2009-06-14, 0.000-+--UD:UTF-8 X-Spam-Status: No, score=-7.1 required=4.0 tests=AWL,BAYES_00,FROMDEVELOPER, FVGT_m_MULTI_ODD autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Return-path: mich...@fam-meskes.de Received: from gauss.credativ.com ([91.190.177.186]) by rietz.debian.org with esmtp (Exim 4.63) (envelope-from mich...@fam-meskes.de) id 1Mq4uL-0001mF-EJ for 528657-d...@bugs.debian.org; Tue, 22 Sep 2009 12:55:49 + Received: from feivel (p54BBEC88.dip.t-dialin.net [84.187.236.136]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: m...@gauss.credativ.com) by gauss.credativ.com (Postfix) with ESMTP id 09DF39941D9 for 528657-d...@bugs.debian.org; Tue, 22 Sep 2009 14:55:46 +0200 (CEST) Received: by feivel (Postfix, from userid 1000) id A748B4DFF8; Tue, 22 Sep 2009 14:55:46 +0200 (CEST) Date: Tue, 22 Sep 2009 14:55:46 +0200 From: Michael Meskes mes...@debian.org To: 528657-d...@bugs.debian.org Subject: Seems to be fixed Message-ID: 20090922125546.ga24...@feivel.credativ.lan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) It seems this has been fixed at some point: mich...@feivel:~$ LC_ALL=shs_CA.UTF-8 cal Pesqelqle'lten 2009 Sx Sp Se Ke Me Ts Tq 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 mich...@feivel:~$ LC_ALL=shs_CA.UTF-8 ncal Pesqelqle'lten 2009 Sp 7 14 21 28 Se 1 8 15 22 29 Ke 2 9 16 23 30 Me 3 10 17 24 Ts 4 11 18 25 Tq 5 12 19 26 Sx 6 13 20 27 Feel free to re-open if I missed something preferably with an example to reproduce. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: mes...@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! Received: (at submit) by bugs.debian.org; 14 May 2009 12:29:38 + X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rietz.debian.org X-Spam-Level: X-Spam-Bayes: score:0. Tokens: new, 34; hammy, 145; neutral, 35; spammy, 5. spammytokens:0.987-1--H*MI:3029, 0.987-1--H*M:3029, 0.923-+--H*M:localdomain, 0.909-+--H*MI:localdomain, 0.904-+--H*M:localhost hammytokens:0.000-+--H*M:reportbug, 0.000-+--H*MI:reportbug, 0.000-+--x86_64, 0.000-+--H*x:reportbug, 0.000-+--H*UA:reportbug X-Spam-Status: No, score=-11.7 required=4.0 tests=AWL,BAYES_00,FOURLA, FROMDEVELOPER,FVGT_m_MULTI_ODD,HAS_PACKAGE,SPF_HELO_PASS,XMAILER_REPORTBUG autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Return-path: eu...@debian.org Received: from smtp1.tu-cottbus.de ([141.43.99.247]) by rietz.debian.org with esmtp (Exim 4.63) (envelope-from eu...@debian.org) id 1M4a4A-0004KQ-8W for sub...@bugs.debian.org; Thu, 14 May 2009 12:29:38 + Received: from localhost (localhost [127.0.0.1]) by smtp1.tu-cottbus.de (Postfix) with ESMTP id 93D0E678083; Thu, 14 May 2009 14:29:24 +0200 (CEST) X-Virus-Scanned: by AMaViS (at smtp1.TU-Cottbus.De) Received: from
Bug#528657: closed by Michael Meskes mes...@debian.org (Seems to be fixed)
It is not my system. It is length of the month name. It is longer for May. 22 вересня 2009 о 16:40 +0200 Michael Meskes написав(-ла): Strange, what is different on your system? I will dig into it some as soon as I find time. Thanks for the note. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: mes...@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! signature.asc Description: Digital signature
Bug#545429: systemtap: warnings at startup
tags 545429 + confirmed thanks Hello, Those two binaries are in -server package now. For the next release upstream .spec file contains them in every systemtap, -client and -server packages. I dont think it is good for Debian, so I'll probably make a -common package (or maybe some other name). If it does not affect functionality, I'll fix it for the next upstream release. 7 вересня 2009 о 07:49 +0200 Lucas Nussbaum написав(-ла): Package: systemtap Version: 0.9.9-4 Severity: minor Hi, When starting systemtap, I get the following warnings: lu...@star:~$ sudo ./forktracker.stp sh: /usr/bin/stap-gen-cert: No such file or directory sh: /usr/bin/stap-authorize-signing-cert: No such file or directory Copy failed (/tmp/stapDk1TWx/stap_3835b78b63112f155923ffab0cc0cfd1_6702.ko.sgn to /home/lucas/.systemtap/cache/38/stap_3835b78b63112f155923ffab0cc0cfd1_6702.ko.sgn): No such file or directory Mon Sep 7 05:48:05 2009 : udevd (1055) created 4445 [..] It doesn't seem to affect functionality: systemtap works fine. - Lucas -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (800, 'stable'), (700, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.31-rc8 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages systemtap depends on: ii libc6 2.9-25 GNU C Library: Shared libraries ii libdw10.142-1library that provides access to th ii libelf1 0.142-1library to read and write ELF file ii libgcc1 1:4.4.1-1 GCC support library ii libnspr4-0d 4.8-1 NetScape Portable Runtime Library ii libnss3-1d3.12.3.1-1 Network Security Service libraries ii libsqlite3-0 3.6.17-2 SQLite 3 shared library ii libstdc++64.4.1-1The GNU Standard C++ Library v3 ii systemtap-runtime 0.9.9-4instrumentation system for Linux 2 systemtap recommends no packages. Versions of packages systemtap suggests: ii linux-headers-2.6.24-1-686 [l 2.6.24-7 Header files for Linux 2.6.24 on P ii linux-headers-2.6.31-rc8 [lin 1 Header files related to Linux kern ii linux-image-2.6.24-1-686 [lin 2.6.24-7 Linux 2.6.24 image on PPro/Celeron ii linux-image-2.6.30-1-686 [lin 2.6.30-6 Linux 2.6.30 image on PPro/Celeron ii linux-image-2.6.31-rc8 [linux 1 Linux kernel binary image for vers ii linux-image-2.6.31-rc8-dbg [l 1 Linux kernel debug image for versi ii systemtap-doc 0.9.9-4documentation and examples for Sys pn vim-addon-manager none (no description available) -- no debconf information signature.asc Description: Digital signature
Bug#545279: unclear split between packages
Hello, 6 вересня 2009 о 10:21 +0200 Lucas Nussbaum написав(-ла): It would be great to improve the description of systemtap-client/-server to explain when they are useful. With systemtap it is possible to compile probes locally using systemtap package and locally installed debuginfo and headers packages. It is also possible to compile probes on some other host that has systemtap-server running and matching debuginfo and headers. This way one does not need locally installed debuginfo and headers package, one also does not need gcc co. and systemtap (only smaller -client and -runtime). So a lot of saved disk space, less installed packages. Server also signs modules and staprun can check those signatures. -client and -server can be used to run scripts on slow machines or ones with small amount of memory. One installs -client on the slow machine and -server on more powerful one (or emulator, for example for arm). Now, any ideas on how to integrate this into package descriptions are welcome. I'm not very good on writing descriptions, especially in English. Upstream .spec file uses these descriptions: Instrumentation System Client SystemTap client is the client component of an instrumentation system for systems running Linux 2.6. Developers can write instrumentation to collect data on the operation of the system. Instrumentation System Server SystemTap server is the server component of an instrumentation system for systems running Linux 2.6. Developers can write instrumentation to collect data on the operation of the system. Regards, Eugeniy Meshcheryakov signature.asc Description: Digital signature
Bug#545429: systemtap: warnings at startup
7 вересня 2009 о 07:49 +0200 Lucas Nussbaum написав(-ла): lu...@star:~$ sudo ./forktracker.stp or you can add yourself to 'stapdev' group. sh: /usr/bin/stap-gen-cert: No such file or directory sh: /usr/bin/stap-authorize-signing-cert: No such file or directory Copy failed (/tmp/stapDk1TWx/stap_3835b78b63112f155923ffab0cc0cfd1_6702.ko.sgn to /home/lucas/.systemtap/cache/38/stap_3835b78b63112f155923ffab0cc0cfd1_6702.ko.sgn): Hmm, I also wonder why it tries to copy into /home/lucas/.systemtap if you run it as root... And those files have root as owner... This probably should be fixed too. signature.asc Description: Digital signature
