Bug#997889: bison: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by bison)
Hi, glibc 2.32-4 migrated to testing on 2021-09-22. Please upgrade your libc6 package to the latest version, and that should fix the issue. Thank you! Chuan-kai
Bug#979193: installation-reports: Bullseye Alpha 3 cannot configure HTTP mirror with preseed
Package: installation-reports Severity: normal Tags: d-i X-Debbugs-Cc: ck...@debian.org >From installation syslog: Jan 4 04:13:46 apt-setup: warning: /usr/lib/apt-setup/generators/50mirror returned error code 1; discarding output Jan 4 04:13:47 main-menu[354]: (process:25092): /usr/lib/apt-setup/generators/50mirror: line 32: is_ports_architecture: not found 50mirror references is_ports_architecture function, which was removed from library.sh in a later revert [1]. As a result the installer is unable to set up a package mirror from preseed. [1] https://salsa.debian.org/installer-team/base-installer/-/commit/3885175086542d3d3404bdb85700c7879b3c1e34 -- Package-specific info: Boot method: CD Image version: https://cdimage.debian.org/cdimage/bullseye_di_alpha3/amd64/iso-dvd/debian-bullseye-DI-alpha3-amd64-DVD-1.iso Date: Sun 03 Jan 2021 08:13:00 PM PST Machine: VMWare ESXi 7.0 Guest Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: >From installation syslog: Jan 4 04:13:46 apt-setup: warning: /usr/lib/apt-setup/generators/50mirror returned error code 1; discarding output Jan 4 04:13:47 main-menu[354]: (process:25092): /usr/lib/apt-setup/generators/50mirror: line 32: is_ports_architecture: not found 50mirror references is_ports_architecture function, which was removed from library.sh in a later revert [1]. As a result the installer is unable to set up a package mirror from preseed. [1] https://salsa.debian.org/installer-team/base-installer/-/commit/3885175086542d3d3404bdb85700c7879b3c1e34 -- 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="11 (bullseye) - installer build 20201202" X_INSTALLATION_MEDIUM=cdrom -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/1 CPU thread) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#966274: O: ident2 -- An advanced ident daemon
Package: wnpp Severity: normal I intend to orphan the ident2 package. The package no longer builds on gcc-10, and I realized that I cannot adequately maintain this package without an active upstream. Besides, there seems to be no shortage of ident servers in Debian. If you care deeply about ident2 specifically, please adopt this package. The package description is: ident2 is an advanced, configurable ident daemon. You can set it to lie, not lie, or not return any response at all, and it is per-user configurable (e.g. if user daniel was IRCing, it'd use ~daniel/.ident for its config, if user kim was IRCing, it'd use ~kim/.ident). The admin can specify whether users can configure the type of return they want or not.
Bug#966273: RFA: fam -- File Alteration Monitor
Package: wnpp Severity: normal I request an adopter for the fam package. I can no longer invest sufficient time to maintain this package. Upstream had disappeared a long time ago, and gamin is a better maintained alternative. The package description is: FAM monitors files and directories, notifying interested applications of changes. . This package provides a server that can monitor a given list of files and notify applications through a socket. If the kernel supports dnotify (kernels >= 2.4.x) FAM is notified directly by the kernel. Otherwise it has to poll the files' status. FAM can also provide an RPC service for monitoring remote files (such as on a mounted NFS filesystem).
Bug#960608: Bison 3.6.1 generates (internal) tokentype and (yyerror) function with same name: _error
Hi Akim,
I am forwarding a bug report that the libexplain and the fhist Debian
packages fail to build with Bison 3.6.1.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960608
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libexplain.html
I have also attached the build log with this email. Can you look into
this issue and see if it is a bug in Bison? Thanks!
Here is the explanation from Andreas Beckmann, who reported the bug:
At least two packages FTBFS with the latest bison with some yyerror related
error message. I had a short look into the libexplain failure and found the
following:
In libexplain/acl_grammar.yacc.c (generated from libexplain/acl_grammar.y),
these bits are new in 3.6.1 (they were not generated by 3.5.3):
...
enum acl_grammar_tokentype
{
acl_grammar_EMPTY = -2,
acl_grammar_EOF = 0, /* "end of file" */
acl_grammar_error = 256, /* error */
acl_grammar_UNDEF = 257, /* "invalid token" */
...
};
...
#define acl_grammar_EOF 0
#define acl_grammar_error 256
#define acl_grammar_UNDEF 257
...
and acl_grammar_error clashes with the existing (generated by 3.6.1 and
3.5.3, in acl_grammar.y this is yyerror())
...
static void
acl_grammar_error(const char *text)
{
...
}
which causes this error during compilation:
y.tab.c:152:27: error: expected identifier or '(' before numeric constant
libexplain/acl_grammar.y:128:1: note: in expansion of macro 'acl_grammar_error'
128 | yyerror(const char *text)
| ^
libexplain/acl_grammar.y: In function 'acl_grammar_errorf':
y.tab.c:152:27: error: called object is not a function or function pointer
libexplain/acl_grammar.y:155:5: note: in expansion of macro 'acl_grammar_error'
155 | yyerror(buf);
| ^
libexplain/acl_grammar.y: In function 'acl_grammar_parse':
y.tab.c:152:27: error: called object is not a function or function pointer
libexplain/acl_grammar.y:470:13: note: in expansion of macro 'acl_grammar_error'
470 | yyerror
| ^~~
y.tab.c:152:27: error: called object is not a function or function pointer
y.tab.c:1720:7: note: in expansion of macro 'acl_grammar_error'
y.tab.c:152:27: error: called object is not a function or function pointer
y.tab.c:1831:3: note: in expansion of macro 'acl_grammar_error'
At top level:
libexplain/acl_grammar.y:105:1: warning: 'result_append' defined but
not used [-Wunused-function]
105 | result_append(const char *text)
| ^
This does not look like it is an error in libexplain.
Mon May 11 13:28:49 UTC 2020 I: starting to build libexplain/unstable/amd64 on
jenkins on '2020-05-11 13:28'
Mon May 11 13:28:49 UTC 2020 I: The jenkins build log is/was available at
https://jenkins.debian.net/userContent/reproducible/debian/build_service/amd64_14/12752/console.log
Mon May 11 13:28:49 UTC 2020 I: Downloading source for
unstable/libexplain=1.4.D001-9
--2020-05-11 13:28:50--
http://deb.debian.org/debian/pool/main/libe/libexplain/libexplain_1.4.D001-9.dsc
Connecting to 78.137.99.97:3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: 2184 (2.1K)
Saving to: ‘libexplain_1.4.D001-9.dsc’
0K ..100% 190M=0s
2020-05-11 13:28:50 (190 MB/s) - ‘libexplain_1.4.D001-9.dsc’ saved [2184/2184]
Mon May 11 13:28:50 UTC 2020 I: libexplain_1.4.D001-9.dsc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 3.0 (quilt)
Source: libexplain
Binary: explain, libexplain-doc, libexplain51, libexplain-dev
Architecture: any all
Version: 1.4.D001-9
Maintainer: Debian QA Group
Homepage: http://libexplain.sourceforge.net/
Standards-Version: 4.4.0
Vcs-Browser: https://salsa.debian.org/debian/libexplain
Vcs-Git: https://salsa.debian.org/debian/libexplain.git
Build-Depends: bison, debhelper-compat (= 12), ghostscript, groff, libacl1-dev,
libcap-dev [linux-any], libtool-bin, linux-libc-dev [linux-any], lsof
[linux-any], netbase
Package-List:
explain deb devel optional arch=any
libexplain-dev deb libdevel optional arch=any
libexplain-doc deb doc optional arch=all
libexplain51 deb libs optional arch=any
Checksums-Sha1:
e191e1e7f066f8cefca8d05c846c3a38931d8410 4770006
libexplain_1.4.D001.orig.tar.gz
051e4be36c618b454657db790a7a7920704ee513 43992
libexplain_1.4.D001-9.debian.tar.xz
Checksums-Sha256:
28863b65eccc74934e237cac41364cb3c1802c36c9e2318ed0417460fee83f80 4770006
libexplain_1.4.D001.orig.tar.gz
4ac59e45f82811b8fd0cf519149d224467f25ea212f161a5ac004241f502d543 43992
libexplain_1.4.D001-9.debian.tar.xz
Files:
8fabd3de196bde3ca941cd27c029ff8b 4770006 libexplain_1.4.D001.orig.tar.gz
078b819d14486f28ebab03884dc6b658 43992 libexplain_1.4.D001-9.debian.tar.xz
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEfncpR22H1vEdkazLwpPntGGCWs4FAl1yplIACgkQwpPntGGC
Ws6jGg//ZreHxsvjOCNmKJ3RTjNwNEop3ml1HcRdd0YBVLB28zwOLTB6nAaxip6t
n/btsbm6azsLSRZd5c5WGN9rUPd9S9IZ1Kfln6lVZ3a6m6vg
Bug#930091: bison is wrongly marked Multi-Arch: foreign
I finished rebuilding all reverse build dependencies of bison. And I found that removing libbison-dev as a dependency of bison (option A) does not cause any additional FTBFS errors. All the build failures I observed were due to existing FTBFS bugs, or due to problems (such as tests hanging) that are very unlikely to be caused by missing liby.a, which should cause static linking errors. So I believe that we can proceed with option A without filing any bugs on reverse build dependencies of bison.
Bug#930091: bison is wrongly marked Multi-Arch: foreign
Status update. The ratt run is still in progress, having built 152 out of 547 reverse dependencies. Out of those 152 only 1 fails to build (libbonobo), and that package is already FTBFS for reasons entirely unrelated to bison. So I think A is the way to go, and it is likely that very few packages will need to manually add libbison-dev as build dependency.
Bug#930091: bison is wrongly marked Multi-Arch: foreign
On Thu, Jun 6, 2019 at 9:50 PM Helmut Grohne wrote: > And the question now is: Where to move that dependency? Either the > consumers must explicitly depend on libbison-dev (A) or bison is > restructured in a way that still provides the library for the right > architecture when issuing a dependency on bison (B). Personally I would go for A. The reason being the following paragraph from Bison documentation [1]: "The Yacc library contains default implementations of the yyerror and main functions. These default implementations are normally not useful, but POSIX requires them." I don't see too many applications being happy with the Yacc library main() function, so I suspect that most packages should continue to build without explicit dependency on libbison-dev. And letting the mostly useless Yacc library take the "bison" package name just feels wrong to me. I will see about setting up a ratt run to see how many packages would actually FTBFS with option A and report back. Though I will definitely take you up on your offer to take care of MBF, once we have the list of affected packages. [1] https://www.gnu.org/software/bison/manual/html_node/Yacc-Library.html#Yacc-Library
Bug#930091: bison is wrongly marked Multi-Arch: foreign
Hi Helmut, Thank you for the bug report! Let me see if I understand the situation correctly: 1. bison (the executable) being marked Multi-Arch: foreign is not inherently broken, since in a cross-build situation we are running the bison binary in the host (instead of the target) architecture. 2. The broken part is bison depending on libbison-dev, which cannot possibly be Multi-Arch: foreign (as it needs to be linked into the binary being built). 3. So the desired end state (for both options) is that bison (the executable binary, whatever its package name) remaining Multi-Arch: foreign but not depending on libbison-dev. Am I understanding this correctly? Chuan-kai
Bug#914163: lintian: False positive: source-only-upload-to-non-free-without-autobuild on source+binary upload
Package: lintian Version: 2.5.112 Severity: normal Dear Maintainer, lintian incorrectly reports source-only-upload-to-non-free-without-autobuild when the changes file includes both source and binary package files. $ lintian bison-doc_3.2.1-1_amd64.changes E: bison-doc source: source-only-upload-to-non-free-without-autobuild This bug is causing FTP master to reject the upload automatically. *** bison-doc_3.2.1-1_amd64.changes -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 18 Nov 2018 20:57:05 -0800 Source: bison-doc Binary: bison-doc Architecture: source all Version: 1:3.2.1-1 Distribution: experimental Urgency: medium Maintainer: Chuan-kai Lin Changed-By: Chuan-kai Lin Description: bison-doc - Documentation for the Bison parser generator Changes: bison-doc (1:3.2.1-1) experimental; urgency=medium . * New upstream version. * Update Standards-Version to 4.2.1.0 (no change required). Checksums-Sha1: a430d4bb439057d938ace11cb9fae45201bf822e 1804 bison-doc_3.2.1-1.dsc ed2eb78718e3d9a724a85daf08e9c3d5026a67f0 290016 bison-doc_3.2.1.orig.tar.xz 5b88a38d23093157a1a706a888400584068deee9 3640 bison-doc_3.2.1-1.debian.tar.xz 3f2611e14063d4c72b7d4dec7027db271387e427 1256504 bison-doc_3.2.1-1_all.deb 1cf855882baab7511c2606604a1ce8bc90458068 8010 bison-doc_3.2.1-1_amd64.buildinfo Checksums-Sha256: 9e1e9825d2f90668fe293c3814669059408dc1eb3a09711c1b5c42a1c603b402 1804 bison-doc_3.2.1-1.dsc 420699c64016402ed3bd369212c214314607042c41889f8fa48540fe0cb39339 290016 bison-doc_3.2.1.orig.tar.xz 7f8b682f87ea14dafc87abff69dbfc1c172aa8730cefa444806563afa5011b91 3640 bison-doc_3.2.1-1.debian.tar.xz d653e0f15db0248ee911607f641b783b889e984f333266e620c334790d43eef6 1256504 bison-doc_3.2.1-1_all.deb 8c03b1ef2d7fb0373afa3af973ef7eab0ecea4d693908e601c8f8072e9532c7c 8010 bison-doc_3.2.1-1_amd64.buildinfo Files: a159b86a790411cd1fb5bb9b898882de 1804 non-free/doc optional bison-doc_3.2.1-1.dsc ed73e1f22f8fb8f0189cacc82bc93d3b 290016 non-free/doc optional bison-doc_3.2.1.orig.tar.xz 5c8bff5a0c101db7847d8e579317670d 3640 non-free/doc optional bison-doc_3.2.1-1.debian.tar.xz 5dfe1ade63de4ebc62815b22039bb3c0 1256504 non-free/doc optional bison-doc_3.2.1-1_all.deb 407989dc30bf54d3e8271a2b0e5b2056 8010 non-free/doc optional bison-doc_3.2.1-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEpjo/UW6i/KKi+2ONAbOplSquRxMFAlvyRG4RHGNrbGluQGRl Ymlhbi5vcmcACgkQAbOplSquRxMRqBAA53gYlK4OeC/T+ZmpRDw+wsEAbrJgD7n9 RgCyxPPti/i2jhGyeb4fKoV8EArcmFWXAxiELirjVqDTuWnuYaxcnODiv+l/l9nE JW3ekBlyHG0mgu7E/NISk/QIi/bIvqiLkxeeuJBxo/KWgBR4G2WF++NhaDsqOKC/ gAnjxBBNNHXDo9KIiAh1HDMGvhJ21KQ5Wsjyop5+iWY0VKzmSvh6TAKD+jzLpdzt nio/vCD32udw96dMmWKV0IWbL2hsBOvTrsYDNesrMP5rLUeYdoQIVEmka5qYz/7W /yo1PGRRYdDC63pprHKJv8dz/r2QCm0eWJvvJP5uV9hBT5wfFPX+IyU925tw1Ohr CkT9+fRZpZAg+k8mhN9OHsg6pIgI1OZiTC19UI17Uj4H7kNwdC54xdYj/IY0cv8W pAU4YsETalwNQoXjEHosP1piMv0vJaB1g/AMraBXdrE8CY4LaWcieAOr29RklXbk xj/vMIUQFV8guxTlX5+QeEgJwJp+T3sIOdM4/HvnQAufMNLqSRcSumKgFKLi1d/y yQltoy6jCtvtkoc0kZJP1wlVNqAyE6oqmtxsR+q5W6DLw7EpTJmIh03aEO20RxK9 o6Zs4vbmetanpXcUWtqazDnAGcv6hwk69yac91xN8lTz1MsamFxJMBHQ63v59wwq s8uEmP5I+Cs= =YXGU -END PGP SIGNATURE- -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lintian depends on: ii binutils 2.31.1-7 ii bzip2 1.0.6-9 ii diffstat 1.61-1+b1 ii dpkg 1.19.2 ii dpkg-dev 1.19.2 ii file 1:5.34-2 ii gettext0.19.8.1-9 ii gpg2.2.10-3 ii intltool-debian0.35.0+20060710.4 ii libapt-pkg-perl0.1.34+b1 ii libarchive-zip-perl1.64-1 ii libcgi-pm-perl 4.40-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl 0.41-1+b1 ii libdpkg-perl 1.19.2 ii libemail-valid-perl1.202-1 ii libfile-basedir-perl 0.08-1 ii libipc-run-perl20180523.0-1 ii liblist-moreutils-perl 0.416-1+b4 ii libparse-debianchangelog-perl 1.2.0-13 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl1.74-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.75+repack-1 ii man-db 2.8.4-3 ii patchutils 0.3.4-2 ii perl [libdigest-sha-perl] 5.28.0-3 ii t1utils1.41-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: pn libperlio
Bug#788052: asciidoctor: broken html5 backend due to missing style file
Package: asciidoctor Version: 1.5.2-1 Severity: important Hi, The asciidoctor program (after manually fixing #788051) fails to generate html5 output due to the following error: No such file or directory @ rb_sysopen - /usr/lib/ruby/data/stylesheets/asciidoctor-default.css It appears that the package does not include the necessary style sheet needed by the html5 backend. Could you include necessary data files in the package? (I would like to respectfully point out that, prior to upload, it never hurts to manually test that the program can perform basic functionality, such as converting an input file with no options. Especially if you are packaging a new upstream version, as things may have shifted around.) Regards, -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages asciidoctor depends on: ii ruby1:2.1.5+z ii ruby2.1 [ruby-interpreter] 2.1.5-3 asciidoctor recommends no packages. Versions of packages asciidoctor suggests: pn asciidoc pn asciidoctor-doc -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#788051: asciidoctor: tries to load modules from non-existent directory on start-up
Package: asciidoctor Version: 1.5.2-1 Severity: grave Tags: patch Justification: renders package unusable Hi, The asciidoctor program aborts on start-up with the following error: /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- /usr/bin/../lib/asciidoctor (LoadError) from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require' from /usr/bin/asciidoctor:5:in `' It looks like the program tries to load the asciidoctor module from a directory that does not exist. The offending line in /usr/bin/asciidoctor is: require File.join File.dirname(__FILE__), '../lib/asciidoctor' Changing that line to the following fixes the problem: require 'asciidoctor' Thanks, -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages asciidoctor depends on: ii ruby1:2.1.5+z ii ruby2.1 [ruby-interpreter] 2.1.5-3 asciidoctor recommends no packages. Versions of packages asciidoctor suggests: pn asciidoc pn asciidoctor-doc -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732034: bison: FTBFS: mv: cannot stat 'examples/extracted.stamp.tmp': No such file or directory
On Thu, Dec 12, 2013 at 10:42 AM, Sven Joachim wrote: > It seems there is a problem with parallel builds, I could reproduce it > with "dpkg-buildpackage -j2", but not in a non-parallel build. The race condition seems to be triggered by the inability to extract program examples from the info file (because bison.info in the bison Debian package is empty - the actual file had been moved to bison-doc due to DFSG non-compliance). I created a patch to disable example code extraction in the makefile, which seem to have fixed parallel builds. The patch still needs some work, and I will try to upload a fixed package over the weekend. Thanks, -- Chuan-kai Lin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691928: Bison: Downgrade to version 2.4 until wheezy is released?
I am planning to downgrade bison in unstable by uploading an older bison package with a higher epoch number. This approach seems to be the path of least resistance, unless the release team wants to get involved. Felipe, is it really necessary to downgrade the unstable version all the way back to 2.4? Testing has bison 1:2.5.dfsg-2.1, which was uploaded about a year ago and not affected by #689700. Unless anyone objects, I will bump the version number of bison 1:2.5.dfsg-2.1 to 2:2.5.dfsg-3 and upload it to unstable tomorrow. Note that this downgrade is a temporary measure intended to accommodate the special circumstances of the freeze. Once wheezy is released and the freeze lifted, I will again upload the latest version of bison. The broken packages will have to support the new behavior (or alternatively convince bison upstream that they new behavior is broken). On Wed, Oct 31, 2012 at 7:03 AM, Felipe Sateler wrote: > Dear release team, > > I'd like to point you to this bug in bison. Certain new features of > Bison 2.6 have caused incompatibilities with 2.4. This has resulted in > at least one package failing to build. > > I have set the severity to serious, because it causes other packages > to FTBFS. Please advise with how to proceed for packages that > build-depend on bison (eg, see #689988). > > > Saludos, > Felipe Sateler -- Chuan-kai Lin http://sites.google.com/site/chklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689700: bison 2.6.2 generates incompatible header file
Bill, bison 2.6.4 is out at http://ftp.gnu.org/gnu/bison/ - can you check if the new version fixes this bug? Thanks, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689700: bison 2.6.2 generates incompatible header file
On Sun, Oct 21, 2012 at 9:24 AM, Akim Demaille wrote: > Hi, > > Maybe the following proposal went unnoticed. > > Le 19 oct. 2012 à 10:43, Akim Demaille a écrit : > >> Nevertheless (I don't know Debian's schedule), there are a >> few bugs in 2.6.2 that have been fixed, and are scheduled >> to be released in 2.7 (say a couple of weeks). Would Debian >> folks like a 2.6.3 with just the bug fixes part of 2.7? I >> can prepare this quickly if you wish. Yes, we would really like to have a 2.6.3 bug-fix release. > > Cheers! > > Akim > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689700:
On Sat, Oct 13, 2012 at 3:35 PM, Felipe Sateler wrote: > This causes unrelated packages to break. Please revert this change > until wheezy is released, since it makes fixing bugs in testing harder > than necessary for pacakges build-depending on bison. Do you happen to know what is the correct procedure to revert the introduction of a new upstream release? Is it something that the release team can handle through a bug to release.debian.org? -- Chuan-kai Lin http://sites.google.com/site/chklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688287: unblock: stow/2.2.0-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package stow
Since version 2.2.0-2 fixes an important bug that prevents package
installation (missing #! lines in maintainer scripts), I would like
to request allowing stow 2.2.0-2 into testing.
diff -Nru stow-2.2.0/debian/changelog stow-2.2.0/debian/changelog
--- stow-2.2.0/debian/changelog 2012-04-13 22:21:04.0 -0700
+++ stow-2.2.0/debian/changelog 2012-09-10 18:45:37.0 -0700
@@ -1,3 +1,12 @@
+stow (2.2.0-2) unstable; urgency=low
+
+ * Add shebang lines to maintainer scripts (Closes: #686434).
+ * Include patch by Kalle Olavi Niemitalo to process
+command-line arguments beyond '--' (Closes: #681752).
+ * Add 'set -e' to maintainer scripts per Policy section 10.4.
+
+ -- Chuan-kai Lin Mon, 10 Sep 2012 18:45:37 -0700
+
stow (2.2.0-1) unstable; urgency=low
* New upstream version 2.2.0 (closes: #650986).
diff -Nru stow-2.2.0/debian/patches/03_stow_getopt.patch
stow-2.2.0/debian/patches/03_stow_getopt.patch
--- stow-2.2.0/debian/patches/03_stow_getopt.patch 1969-12-31
16:00:00.0 -0800
+++ stow-2.2.0/debian/patches/03_stow_getopt.patch 2012-09-10
18:23:28.0 -0700
@@ -0,0 +1,55 @@
+Author: Kalle Olavi Niemitalo
+Description: Fix '--' getopt argument processing
+Origin: other, http://bugs.debian.org/681752
+Bug-Debian: http://bugs.debian.org/681752
+Reviewed-By: Chuan-kai Lin
+Last-Update: 2012-09-10
+
+--- stow-2.2.0.orig/bin/stow.in
stow-2.2.0/bin/stow.in
+@@ -473,6 +473,19 @@ sub process_options {
+ my @pkgs_to_stow = ();
+ my $action = 'stow';
+
++my $remember_package_action = sub {
++if ($action eq 'restow') {
++push @pkgs_to_unstow, $_[0];
++push @pkgs_to_stow, $_[0];
++}
++elsif ($action eq 'unstow') {
++push @pkgs_to_unstow, $_[0];
++}
++else {
++push @pkgs_to_stow, $_[0];
++}
++};
++
+ unshift @ARGV, get_config_file_options();
+ #$,="\n"; print @ARGV,"\n"; # for debugging rc file
+
+@@ -510,21 +523,12 @@ sub process_options {
+ 'R|restow' => sub { $action = 'restow' },
+
+ # Handler for non-option arguments
+-'<>' =>
+-sub {
+-if ($action eq 'restow') {
+-push @pkgs_to_unstow, $_[0];
+-push @pkgs_to_stow, $_[0];
+-}
+-elsif ($action eq 'unstow') {
+-push @pkgs_to_unstow, $_[0];
+-}
+-else {
+-push @pkgs_to_stow, $_[0];
+-}
+-},
++'<>' => $remember_package_action,
+ ) or usage();
+
++# If GetOptions stopped at "--", process any remaining arguments.
++$remember_package_action->($_) foreach @ARGV;
++
+ usage() if $options{help};
+ version() if $options{version};
+
diff -Nru stow-2.2.0/debian/patches/series stow-2.2.0/debian/patches/series
--- stow-2.2.0/debian/patches/series2012-04-13 22:21:04.0 -0700
+++ stow-2.2.0/debian/patches/series2012-09-10 18:28:53.0 -0700
@@ -1,2 +1,3 @@
01_gpl2_file_reference.patch
02_stow_manpage_section_8.patch
+03_stow_getopt.patch
diff -Nru stow-2.2.0/debian/postinst stow-2.2.0/debian/postinst
--- stow-2.2.0/debian/postinst 2012-04-13 22:21:04.0 -0700
+++ stow-2.2.0/debian/postinst 2012-09-10 18:42:10.0 -0700
@@ -1,3 +1,5 @@
+#!/bin/sh
+set -e
if [ ! -e /usr/local/stow ]; then
if mkdir /usr/local/stow 2>/dev/null; then
if chown root:staff /usr/local/stow; then
diff -Nru stow-2.2.0/debian/prerm stow-2.2.0/debian/prerm
--- stow-2.2.0/debian/prerm 2012-04-13 22:21:04.0 -0700
+++ stow-2.2.0/debian/prerm 2012-09-10 18:42:04.0 -0700
@@ -1,2 +1,4 @@
+#!/bin/sh
+set -e
#DEBHELPER#
rmdir /usr/local/stow 2>/dev/null || true
unblock stow/2.2.0-2
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688281: mercurial-buildpackage: mercurial-importorig leaves files that have been removed in new upstream version
Package: mercurial-buildpackage Version: 0.10 Severity: important When using mercurial-importorig to import a new upstream package, mercurial-importorig retains (in the default branch) files that were in the previous upstream package but removed in the new upstream package. These extra files now represent extra changes to the new upstream package that are not accounted for by quilt patches (for packages that uses the quilt 3.0 format). The bug is due to how mercurial-importorig uses merge to combine default branch and the (updated) upstream branch. While the merge would properly update all files that do exist in the new upstream package, it does not remove files that are missing from the new upstream package. mercurial-importorig needs to use a more complicated algorithm to incorporate new upstream packages. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mercurial-buildpackage depends on: ii devscripts2.12.2 ii libc6 2.13-35 ii libneko0 1.8.1-6+b1 ii mercurial 2.2.2-1 ii neko 1.8.1-6+b1 ii pristine-tar 1.25 Versions of packages mercurial-buildpackage recommends: ii pbuilder 0.211 ii sudo 1.8.5p2-1 Versions of packages mercurial-buildpackage suggests: ii quilt 0.60-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#438345: (no subject)
On Thu, Jul 29, 2010 at 06:02:06PM +0200, Olaf van der Spek wrote: > Great. Will you increase the array size to 100? I plan to apply Loïc's patch that came with the original bug report, which does increase the array size to 100. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#438345: (no subject)
On Thu, Jul 29, 2010 at 02:05:56PM +0200, Olaf van der Spek wrote: > Oops. I assumed gamin had less strings. Is the number of strings in > gamin stable? > Looks like Chuan-kai will have to work on this. Alright. Looks like I have to get off my arse and do some work. Expect an upload this weekend. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#438345: (no subject)
On Fri, Jul 09, 2010 at 04:03:33PM +0200, Olaf van der Spek wrote: > What's the status of this issue? > Has it been forwarded upstream? I have not done anything with the bug because I am not sure the warnings are worth addressing. Upstream appears to have ceased all activities about three years ago, which means: 1. There is no one to apply the patch at upstream, and 2. There will probably never be any new error messages. I will, of course, reconsider my position if you can think of a good reason why I should apply the patch. Thanks, -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568207: Test results with 2.6.34-rc6
I tested 2.6.34-rc6 yesterday (with xserver-xorg-video-intel 2:2.11.0-1 and xserver-xorg-core 2:1.7.6.901-3), and the new kernel showed some improvement. Even with an external monitor attached to my ThinkPad X30 laptop, the X server starts correctly and provides a stable graphics display on the internel LCD screen. In other words, with 2.6.34-rc6, I no longer need to unplug the external monitor before starting X to avoid the blank screen problem. Unfortunately, some problems remain: * Extensive rendering artifacts at 24bpp (16bpp is fine). * Flashing and jumping (horizontally) images on the external monitor. It looks like the kernel driver failed to properly configure the VGA output DAC. Switching the external monitor off-and-on with xrandr has no effect on the problem (i.e., it does not help). For now I am staying with 2.6.34-rc5. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#579189: python-moinmoin: incorrect whitespace escape in search result URL
Package: python-moinmoin Version: 1.9.2-3 Severity: normal When I search for a term using the MoinMoin built-in search functionality, and the search term matches exactly one document whose name contains a space, the search functionality redirects the user to a broken URL that does not exist. The redirected URL is broken due to incorrect white-space escape. For example, suppose the search functionality should redirect the user to the "Debian Rocks" page: http://wiki_host/Debian%20Rocks Instead, the bug causes MoinMoin to redirect the user to this page: http://wiki_host/Debian%2520Rocks So, instead of seeing the page that matches the search term, the user sees a "This page does not exist yet" empty page. Please investigate and fix this problem. Thank you! -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.34-rc5 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages python-moinmoin depends on: ii python 2.5.4-9 An interactive high-level object-o ii python-parsedatetime0.8.7-1 Python module to parse human-reada ii python-pygments 1.3.1+dfsg-1 syntax highlighting package writte ii python-support 1.0.7automated rebuilding support for P ii python-werkzeug 0.6-1collection of utilities for WSGI a Versions of packages python-moinmoin recommends: ii cherokee [httpd-cgi] 0.99.44-1 Very fast, flexible and easy to co ii exim4-daemon-light [mail-tran 4.71-4 lightweight Exim MTA (v4) daemon pn fckeditor (no description available) pn python-xapian (no description available) pn python-xappy (no description available) Versions of packages python-moinmoin suggests: pn antiword (no description available) pn catdoc (no description available) pn docbook-dsssl (no description available) ii poppler-utils [xpdf-utils]0.12.4-1 PDF utilitites (based on libpopple pn python-4suite-xml (no description available) pn python-docutils(no description available) pn python-flup(no description available) pn python-gdchart (no description available) pn python-ldap(no description available) pn python-mysqldb (no description available) pn python-openid (no description available) pn python-pyxmpp (no description available) pn python-tz (no description available) pn python-xml (no description available) pn smbfs (no description available) ii wamerican-large [wordlist]6-3American English dictionary words -- no debconf information -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568207: Bug still exists in latest versions
On Fri, Apr 23, 2010 at 05:53:10AM +0200, maximilian attems wrote: > did you report upstream bugzilla.kernel.org or freedesktop bz? > if yes which is the bug number so that we can track it. > if not please to do, so that upstream has awareness of this bug. I think the problem I am experiencing is the same as (or is very closely related to) Linux kernel bug #15070. Bug 15070 - kernel mode switching broken on i830 https://bugzilla.kernel.org/show_bug.cgi?id=15070 -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568207: Bug still exists in latest versions
This is a quick report: I just upgraded to xserver-xorg-video-intel 2:2.11.0-1 and Linux kernel 2.6.34-rc5 on my ThinkPad X30 laptop (830MG graphics adapter). X works fine if there is no external monitor attached to the laptop when I start the X server. If there is an external monitor attached to the laptop when I start the X server, X produces a blank black screen on both the laptop and the external monitors, and there are no kernel error messages: kernel: i915 :00:02.0: setting latency timer to 64 kernel: [drm] set up 15M of stolen space kernel: [drm] initialized overlay support kernel: fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver kernel: fb1: inteldrmfb frame buffer device kernel: registered panic notifier kernel: [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 The system still responds to SysRq keys after the X malfunction. Note that xserver-xorg-video-intel 2.11.0 *requires* kernel modesetting, so users who are still on 830MG may want to stick to 2:2.9.1-3 (which does not require KMS) until the problem is resolved. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#573594: chrony: new upstream version 1.24 available
Package: chrony Version: 1.23-7 Severity: wishlist Chrony 1.24 has been released a little over a month ago. The new version adds some useful features (IPv6, Linux capabilities, editline, to name a few), so please consider packaging it. I am happy to help if you are short on time. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#572964: chrony: RTC support is missing
Package: chrony Version: 1.23-7 Severity: normal I just upgraded from 1.23-6 to 1.23-7, and the new version no longer supports regulating hardware real-time clocks. I have the rtcfile directive set in /etc/chrony/chrony.conf, but after the upgrade, the "chronyc rtcdata" command returns: 513 No RTC driver Please re-enable RTC support in the next revision. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.33 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages chrony depends on: ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libreadline5 5.2-7 GNU readline and history libraries ii timelimit 1.5-1 Simple utility to limit a process' ii ucf 3.0025 Update Configuration File: preserv Versions of packages chrony recommends: ii udev 151-2 /dev/ and hotplug management daemo chrony suggests no packages. -- no debconf information -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#571790: Patch to Bug#571790: top: unknown argument 'K'
I traced the problem down to loop invariant violation in the username parsing code. At the end of each inner loop iteration in parse_args, the pointer cp should point to the last non-NULL character in the current argument. However, the 'u' case leaves cp pointing to the NULL character, so the loop walks right past the command arguments and into the environment variable part of the memory. The mysterious unknown argument characters come from the environment. The attached patch fixes the bug by reducing the cp increment in the 'u' case by one. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ diff -r 420447d7c7f0 top.c --- a/top.c Sun Feb 28 13:24:37 2010 -0800 +++ b/top.c Sun Feb 28 13:56:30 2010 -0800 @@ -1924,7 +1924,7 @@ errmsg = parse_uid(cp, &selection_uid); if (errmsg) std_err(errmsg); selection_type = 'u'; - cp += snprintf(Curwin->colusrnam, USRNAMSIZ-1, "%s", cp); // FIXME: junk + cp += snprintf(Curwin->colusrnam, USRNAMSIZ-1, "%s", cp)-1; // FIXME: junk } while(0); break; case 'U':
Bug#567264: Bug Confirmation
I have an IBM ThinkPad X24 laptop with Radeon Mobility M6 LY graphics chipset, and I see a similar problem. The entire screen (except the cursor) becomes washed out with a green cast at 16bpp; everything looks normal at 15bpp and 24bpp. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568207: Bug confirmation
I want to report that I also have a ThinkPad X30 laptop, and I am seeing exactly the same problem as Jack R. described. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552917: Patch to fix stow FTBFS
On Sat, Jan 30, 2010 at 02:03:57PM +0100, Michael Bienia wrote: > Hello, > > here is a patch to fix the FTBFS. Thanks for the patch and your NMU. Next time I would appreciate it more if you could (1) give me a heads up before NMU (with the interdiff attached), and (2) check your NMU with lintian before attempting upload. Thanks, -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546386: fam: diff for NMU version 2.7.0-16.1
On Fri, Dec 25, 2009 at 06:54:40PM +0100, gregor herrmann wrote: > I've prepared an NMU for fam (versioned as 2.7.0-16.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. The NMU is quite alright -- I like it when other people do good, clean, high-quality work on my packages. Happy holidays! Thanks, -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#252896: fixed in fam 2.7.0-14
On Tue, Nov 24, 2009 at 02:29:45PM +0100, Xavier Brochard wrote: > Any progress on backporting fam 2.7.0-14 ? I uploaded 2.7.0-13.3+lenny1 and 2.7.0-12+etch1 about 10 days ago. Both packages have been accepted by the Stable release team, and they are now pending processing. You can track their progress on the proposed-updates [1] and the oldstable-proposed-updates [2] pages, or follow the stable [3] and oldstable [4] update requests. [1] http://release.debian.org/proposed-updates/stable.html [2] http://release.debian.org/proposed-updates/oldstable.html [3] http://bugs.debian.org/555804 [4] http://bugs.debian.org/556777 -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555804: pu, opu: package fam/2.7.0-13.3, fam/2.7.0.12
On Wed, Nov 11, 2009 at 11:20:18PM +0100, Philipp Kern wrote: > wow, it didn't even make it into the bug tracker. Please, pretty please, > get that issue fixed in stable and oldstable. The argument in Wil's mail > seems convincing. I take that as a GO permission to upload, yes? -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555804: pu, opu: package fam/2.7.0-13.3, fam/2.7.0.12
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: pu, opu I propose updating the fam packages in stable (lenny) and oldstable (etch) to fix the long-standing bug of occasional 100% CPU usage. The fix is very simple: linking famd with librt and libpthread. I am not familiar with the inner workings of this fix, but it is proposed by Wil Evers on the fam mailing list [1]. Since I introduced this fix in fam 2.7.0-14 in July 2009, there have been no reports of either this bug reoccurring, or regressions caused by this fix. Since there are still some stable and oldstable users who would like to see this bug fixed [2], I would like the release team to consider accepting this fix in both stable and oldstable. Attached are the incremental patches from current fam sources in stable and oldstable; I have tested the patches in the appropriate chroot environments and they both build fine. Please let me know if you would like further information. [1] http://oss.sgi.com/projects/fam/mail_archive/200301/msg00011.html [2] http://bugs.debian.org/252896 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.31.5 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ diff -r 42c59b862004 debian/changelog --- a/debian/changelog Sun Jan 07 15:44:22 2007 -0800 +++ b/debian/changelog Wed Nov 11 11:07:07 2009 -0800 @@ -1,3 +1,12 @@ +fam (2.7.0-12+etch1) unstable; urgency=low + + * Link famd against librt and libpthread to solve 100% CPU usage +problem; suggested by Wil Evers on the fam mailing list +(http://oss.sgi.com/projects/fam/mail_archive/200301/msg00011.html). +Patch backported from 2.7.0-14 (Closes: #252896) + + -- Chuan-kai Lin Wed, 11 Nov 2009 09:57:21 -0800 + fam (2.7.0-12) unstable; urgency=low * Have libfam0 replace libfam0c102 without conflicts, to provide a diff -r 42c59b862004 debian/patches/01_dnotify.patch --- a/debian/patches/01_dnotify.patch Sun Jan 07 15:44:22 2007 -0800 +++ b/debian/patches/01_dnotify.patch Wed Nov 11 11:07:07 2009 -0800 @@ -274,7 +274,16 @@ diff -r e47191bdc76f -r 33ebdce115fd src/Makefile.am --- a/src/Makefile.am Wed Apr 12 13:49:10 2006 -0700 +++ b/src/Makefile.am Wed Apr 12 13:49:26 2006 -0700 -@@ -71,7 +71,11 @@ +@@ -2,6 +2,8 @@ + + sbin_PROGRAMS = famd + ++famd_LDADD = -lrt -lpthread ++ + famd_SOURCES = \ + Activity.c++ \ + Activity.h \ +@@ -71,7 +73,11 @@ main.c++ \ timeval.c++ \ timeval.h \ diff -r 94bfc99720cf -r 458e8bdd2b49 debian/changelog --- a/debian/changelog Wed Nov 11 11:14:24 2009 -0800 +++ b/debian/changelog Wed Nov 11 11:28:18 2009 -0800 @@ -1,3 +1,12 @@ +fam (2.7.0-13.3+lenny1) unstable; urgency=low + + * Link famd against librt and libpthread to solve 100% CPU usage +problem; suggested by Wil Evers on the fam mailing list +(http://oss.sgi.com/projects/fam/mail_archive/200301/msg00011.html). +Patch backported from 2.7.0-14 (Closes: #252896, #500387, #501081) + + -- Chuan-kai Lin Wed, 11 Nov 2009 11:18:08 -0800 + fam (2.7.0-13.3) unstable; urgency=low * Non-maintainer upload. diff -r 94bfc99720cf -r 458e8bdd2b49 debian/patches/01_dnotify.patch --- a/debian/patches/01_dnotify.patch Wed Nov 11 11:14:24 2009 -0800 +++ b/debian/patches/01_dnotify.patch Wed Nov 11 11:28:18 2009 -0800 @@ -274,7 +274,16 @@ diff -r e47191bdc76f -r 33ebdce115fd src/Makefile.am --- a/src/Makefile.am Wed Apr 12 13:49:10 2006 -0700 +++ b/src/Makefile.am Wed Apr 12 13:49:26 2006 -0700 -@@ -71,7 +71,11 @@ +@@ -2,6 +2,8 @@ + + sbin_PROGRAMS = famd + ++famd_LDADD = -lrt -lpthread ++ + famd_SOURCES = \ + Activity.c++ \ + Activity.h \ +@@ -71,7 +73,11 @@ main.c++ \ timeval.c++ \ timeval.h \
Bug#252896: fixed in fam 2.7.0-14
On Tue, Nov 03, 2009 at 09:50:19PM +0100, Xavier Brochard wrote: > You're perfectly right. > I'm sorry, I should have provided more iformations. That is alright. Since there has been no reports of regression and re-occurrences of the 100% CPU usage bug after the fix in -14, I will talk to Gerfried Fuchs and present a case to the release team for backporting this fix to stable (lenny) and old-stable (etch). -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#252896: fixed in fam 2.7.0-14
On Tue, Nov 03, 2009 at 03:49:42PM +0100, Xavier Brochard wrote: > > Once -14 enters testing and there are no > >reports of 100% CPU usage in a month or two, we can then talk to the > >stable release team... > > Hello > > On a Terminal Server Debian Lenny installation, famd suddenly start to uses > 100% of CPU. It start to happen around september. It never happened before > (at > least, none of the users reports problems). > Lenny is setup since august 2008 and regularly updated. If I understand you correctly, you are experiencing this problem in 2.7.0-13.3, and you are _not_ reporting that the 100% CPU usage bug reappears in a version beyond 2.7.0-14. Is this description accurate? -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548469: mdm: FTBFS: ncurses.h: No such file or directory
On Sat, Sep 26, 2009 at 04:26:03PM +0200, Kurt Roeckx wrote: > Source: mdm > Version: 0.1.3-1 > Severity: serious > > Hi, > > There was an error while trying to autobuild your package: Yeah, I forgot to add ncurses into Build-Depends. Thanks for the report; I will upload a fix soon. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544797: bison: invalid directive: `%no-parser'
On Thu, Sep 03, 2009 at 12:09:27AM +0100, Philip Ashmore wrote: > The code bison generates can't handle non-pod semantic values as it > uses C unions. I would like to write my own parser and use only the > tables bison generates. According to the documentation this is > accomplished with the "%no-parser" directive. The "%no-parser" directive has been removed in bison 2.3, but upstream forgot to document this change until version 2.3b (2008-05-27). I think you will have to live without the "%no-parser" directive. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547375: ITP: mdm -- Utilities for single-host parallel shell scripting
Package: wnpp Severity: wishlist Owner: "Chuan-kai Lin" * Package name: mdm Version : 0.1.2 Upstream Author : "Chuan-kai Lin" * URL : http://mdm.berlios.de/ * License : Apache License 2.0 Programming Lang: C Description : Utilities for single-host parallel shell scripting The Middleman System (mdm) is a set of utilities that help you parallelize your shell scripts. Simply label the commands to run in parallel, and the System automatically exploits every parallelization opportunity that arises at runtime. You can also specify dependency between commands so that they run in an appropriate order. Comes with an ncurses-based monitoring console. Compatible with xargs, find, make, any shell, together, in a script or interactively. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547348: RFA: apt-move -- Maintain Debian packages in a package pool
Package: wnpp Severity: normal I no longer use this package, and I have not spent any time on it for the past two years. If there is anyone who would like to take over its maintenance, feel free to claim it. The package description is: apt-move is used to move a collection of Debian package files into a proper archive hierarchy as is used in the official Debian archive. It is intended as a tool to help manage the apt-get(8) file cache, but could be configured to work with any collection of Debian packages. . Running apt-move periodically will assist in managing the resulting partial mirror by optionally removing obsolete packages, and creating valid local Packages.gz files. It can also build a partial or complete local mirror of a Debian binary distribution (including an ``installed-packages only'' mirror). -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546490: bison: alternatives warning during installation
On Sun, Sep 13, 2009 at 11:38:23AM -0400, Jerry Quinn wrote: > Package: bison > Version: 1:2.4.1.dfsg-2+b1 > Severity: normal > > > When installing, I get the following dpkg output: > > Selecting previously deselected package bison. > (Reading database ... 224595 files and directories currently installed.) > Unpacking bison (from .../bison_1%3a2.4.1.dfsg-2+b1_amd64.deb) ... > Processing triggers for man-db ... > Setting up bison (1:2.4.1.dfsg-2+b1) ... > update-alternatives: using /usr/bin/bison.yacc to provide /usr/bin/yacc > (yacc) in auto mode. > update-alternatives: warning: not replacing /usr/bin/yacc with a link. > Press return to continue. I am not sure how I should respond to this report. If memory serves, there was a major screw-up in an old bison package on the yacc alternative. One of the effects of that screw up was that removing bison leaves behind a dangling /usr/bin/yacc file, which I guess is what you are seeing. That bug had since been fixed. There is, unfortunately, no satisfactory way to clean up that problem, because there is no way to tell, reliably, whether the /usr/bin/yacc file was accidentally left behind (in which case it should be deleted) or installed by the user (in which case it should be left as-is). So the best the system can do is to warn you that there is a problem, which the messages you see did. If you have some concrete suggestions, please let me know. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544653: fam: build error by automake
On Wed, Sep 02, 2009 at 03:45:20PM +0900, Nobuhiro Iwamatsu wrote: > This pakcage failed to build on i386 in sid. > I checked this problem by cowbuilder. > Could you check and fix ? I cannot reproduce this problem. The packages builds fine on my system (i386 unstable/testing mix), and I cannot get cowbuilder to work (cowbuilder --create dies due to cdebootstrap internal error right after trying to configure libusb-0.1-4). Can you list the build-deps packages in your cowbuilder environment? -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#252896: fixed in fam 2.7.0-14
On Thu, Jul 09, 2009 at 02:16:05PM +0200, Gerfried Fuchs wrote: > * Chuan-kai Lin [2009-07-07 02:32:04 CEST]: > > Source: fam > > Version: 2.7.0-14 > > Distribution: unstable > > Changes: > > fam (2.7.0-14) unstable; urgency=low > > . > >* Link famd against librt and libpthread to solve 100% CPU usage problem; > > suggested by Wil Evers on the fam mailing list > > (http://oss.sgi.com/projects/fam/mail_archive/200301/msg00011.html) > > (Closes: #252896, #500387, #501081) > > Thanks for catching up! Do you plan to fix that also in stable (and ... > propably oldstable)? If you need any helping hands for that please let > me know, this really needs to get addressed in (old)stable, too. Thanks for prodding me into working on this long standing problem! There is a pretty stringent standard in place for uploads to stable and old-stable [1], and I am not sure we can get over that bar. There may be some debate whether this problem is a "truly critical functionality problem", and as of now there is little evidence whether the fix actually works as intended. Once -14 enters testing and there are no reports of 100% CPU usage in a month or two, we can then talk to the stable release team... [1] http://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#252896: fam: Maybe here a solution
On Fri, Jul 03, 2009 at 12:35:09PM +0200, Gerfried Fuchs wrote: > That message is perfect and sounds extremely convincing that this would > fix the bug - and it really makes me wonder if the maintainer of the > package is still around. Chuan-kai Lin, if you are still around please > give me a message. I will be doing an NMU to fix this long-standing > issue which is becoming a real PITA at my current work place too and it > will get linked against -lrt -lpthread. Yeah, I have been really bad at getting on top of this issue. Sorry about that. I promise I will look into it this weekend and make an upload if it seems to work. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518888: NMU patch for fam FTBFS bug
On Sat, May 02, 2009 at 09:47:07AM -0700, Daniel Schepler wrote: > I plan to upload an NMU with the attached patch within a couple days, unless > you reject it or do an upload yourself. I am a little overwhelmed with other things now, so please go ahead. Thank you for doing the NMU. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ signature.asc Description: Digital signature
Bug#400836: Status
On Tue, Mar 10, 2009 at 12:21:11AM +0100, Raúl Sánchez Siles wrote: > Once Lenny has been release, situation of kdelibs is almost the same: > inotify is generally preferred, but fam is usually installed, and therefore > used. This is because recommends are installed by default currently. > > I think a dependency level of "libfam0 suggests fam" should be enough for > this package. > > What do you think about it? That sounds like a good idea to me. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518696: #518696 ITP: parallel -- build and execute command lines from standard input in parallel]
On Mon, Mar 09, 2009 at 10:57:57PM +0100, Samuel Thibault wrote: > I thought at first "it's not particularly convenient", then "well, so > what". Now I'm thinking "Mmm, but people won't know they should do it > and blame xargs for being broken". Also annotate-output is not enough > when programs e.g. output Packages entries, which not only should be > line-atomic, but also paragraph-atomic... Below is what I had in mind when I mentioned adapting annotate-output to a different "atomic-output" script. This script is usefull not just with "xargs -P", but also with "make -j" and with standard background jobs (shell & operator), all of which produce mixed output. Similarly, about matching the number of parallel jobs with the number of processors/cores, we can write a script "ncpus" which returns the number of processors/cores/hyper-threads. You can use the ncpus script with xargs, with make, or with my new project mdm (mdm.berlios.de)... I consider separating these concerns (output management, processor thread detection) into small, separate, and reusable scripts a cleaner solution. Of course, doing it this way requires some user education, so a few manpage updates (for example, adding atomic-output and ncpus to the SEE ALSO section of xargs) may be in order. -- #! /bin/bash # Display stdout and stderr output after program termination # Adapted from annotate-output by Chuan-kai Lin # Original annotate-output author info and copyright notice as follows # this script was downloaded from: # http://jeroen.a-eskwadraat.nl/sw/annotate # and is part of devscripts 2.10.46 # Executes a program annotating the output linewise with time and stream # Version 1.2 # Copyright 2003, 2004 Jeroen van Wolffelaar # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; version 2 of the License # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA OUT=`mktemp /tmp/atomic.XX` || exit 1 ERR=`mktemp /tmp/atomic.XX` || exit 1 echo "-- `date +%H:%M:%S` Started $@" > $ERR echo "-- STDERR" >> $ERR echo "-- STDOUT" >> $OUT "$@" >> $OUT 2>> $ERR ; EXIT=$? cat $ERR cat $OUT echo "-- `date +%H:%M:%S` Finished with exitcode $EXIT" rm -f $OUT $ERR exit $EXIT -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518696: #518696 ITP: parallel -- build and execute command lines from standard input in parallel]
On Mon, Mar 09, 2009 at 11:40:51AM +0100, Samuel Thibault wrote: > A lot of applications (including md5sum) would not necessarily print > their output atomically and then you get mixed output. Either we add > the option to findutils, or we package parallel. It appears to me that you can get the same functionality by using xargs with an adapted version of annotate-output(1) which is a part of devscripts. Are there other reasons to use parallel? -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#512702: bison: New upstream version available
On Fri, Jan 23, 2009 at 12:43:12AM +0200, Adrian Bunk wrote: > Package: bison > Version: 1:2.3.dfsg-5 > Severity: wishlist > > bison-2.4.1 is available at > ftp://ftp.gnu.org/gnu/bison/ > > Could you package this version? Sure. I am getting ready for my thesis proposal, but I should be able to get to it in about a week. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#400836: Possible solution from fam packaging. Reassigning.
On Mon, Jul 07, 2008 at 12:58:44AM +0200, Raúl Sánchez Siles wrote: > I suggest any of these 2 approaches: > > a) Remove totally fam depends from libfam0 package > b) Suggest fam from libfam0 package. > > Any of these 2 options would solve this bug, and probably others. The current version of libfam0 (2.7.0-13.3) does not Depends: fam but instead Recommends: it. So if I understand you correctly, your recommendation has already been implemented, and it does not appear to have anything to do with #400836 (which is about kdelibs4c2a's dependency on libfam0). Please assign this bug back to kdelibs4c2a. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485499: famd: Lots of "connect: Connection refused" messages from LTSP clients
On Mon, Jun 09, 2008 at 11:46:55PM +0200, Petter Reinholdtsen wrote: > Package: fam > Version: 2.7.0-12 > > On a lab with several LTSP based diskless workstation clients, I see a > lot of messages like this in the syslog: > > famd[5807]: connect: Connection refused > > The message do not explain what the problem is. Please change it to > include more information about the failed connect, for example > addresses involved and the port number, to have a chance to figure out > what is causing such messages when reading the syslog. > > Any idea what the problem is? No idea at all. There are two ways to track down the problem: 1. You can do an ltrace on famd and look at the output. 2. I can patch famd as you suggested. I'll write a patch next week and send it to you, and then we'll try to figure out what the problem is. How's that? -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#451344: NMU for fam
On Sun, Jun 08, 2008 at 08:05:34AM +0200, Daniel Baumann wrote: > Without reaction from the maintainer, I intend to NMU fam next week, > the diff is attached. I have not been able to devote any time to Debian in the past few months, and I apologize for leaving the package in a bad shape. Feel free to NMU ASAP; there is no need to wait until next week. Thanks for your work, -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455191: tracker-utils: tracker-tag silently ignores tags in Chinese
Package: tracker-utils
Version: 0.6.3-3+b1
Severity: normal
Hi,
The tracker-tag utility has a bug which makes it ignore tags in Chinese
(Big5 encoding, as per LC_CTYPE). Here is how to reproduce the bug:
$ /usr/bin/tracker-tag -s
/usr/bin/tracker-tag: internal tracker error: No keywords supplied
$
Although not tested, I believe that the bug also affects tags in
non-ASCII, non-UTF8 encodings. I traced the bug to program segments
that (unnecessarily) attempt to convert tags from current locale to UTF8
using g_locale_to_utf8(). The conversions fail for non-ASCII, non-UTF8
strings (it looks like because some other glib function already
converted the strings to UTF8?), and because tracker-tag does not check
error returns from g_locale_to_utf8(), it silently ignores those tags.
I found that removing the conversion code segments eliminates the bug
and makes tracker-tag function correctly (tested adding, querying, and
removing tags). The attached patch implements this fix.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (900, 'testing'), (300, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.22.6 (PREEMPT)
Locale: LANG=C, LC_CTYPE=zh_TW.Big5 (charmap=BIG5)
Shell: /bin/sh linked to /bin/bash
Versions of packages tracker-utils depends on:
ii libc6 2.7-3 GNU C Library: Shared libraries
ii libglib2.0-0 2.14.3-1 The GLib library of C routines
ii libtrackerclient0 0.6.3-3+b1 metadata database, indexer and sea
ii tracker 0.6.3-3+b1 metadata database, indexer and sea
tracker-utils recommends no packages.
-- no debconf information
--
Chuan-kai Lin
http://web.cecs.pdx.edu/~cklin/
diff -r 1eb992409382 src/libtracker/tracker-tag.c
--- a/src/libtracker/tracker-tag.c Sat Dec 08 22:40:56 2007 -0800
+++ b/src/libtracker/tracker-tag.c Sat Dec 08 23:30:01 2007 -0800
@@ -155,21 +155,6 @@
}
if (add || delete || remove_all) {
-
- if (add)
- for (i = 0; add[i] != NULL; i++) {
-gchar *tmp = g_locale_to_utf8 (add[i], -1, NULL, NULL, NULL);
-g_free (add[i]);
-add[i] = tmp;
- }
-
- if (delete)
- for (i = 0; delete[i] != NULL; i++) {
-gchar *tmp = g_locale_to_utf8 (delete[i], -1, NULL, NULL, NULL);
-g_free (delete[i]);
-delete[i] = tmp;
- }
-
for (i = 0; files[i] != NULL; i++) {
@@ -249,15 +234,6 @@
}
if (search) {
-
- int i = 0;
-
- for (i = 0; search[i] != NULL; i++) {
- gchar *tmp = g_locale_to_utf8 (search[i], -1, NULL, NULL, NULL);
- g_free (search[i]);
- search[i] = tmp;
- }
-
gchar **results = tracker_keywords_search (client, -1, SERVICE_FILES, search, 0, 512, &error);
if (error)
Bug#423136: apt-move: built against experimental libgcc1 and libstdc++6
On Wed, May 09, 2007 at 10:05:04PM -0700, Kevin B. McCarty wrote: > apt-move is currently uninstallable in unstable (at least on i386) since > it depends on libgcc1 (>= 1:4.2-20070208) and libstdc++6 (>= > 4.2-20070208). Maybe it was by accident built against gcc 4.2 on the > maintainer's machine? If so, a bin-NMU should suffice to fix it, > assuming it's bin-NMU safe. Good catch -- it never occurred me to check that before uploading the i386 binary. I can probably whip up an unstable chroot environment and rebuild the package this weekend, but a bin-NMU is also quite welcome. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320827: is there any movement on getting apt-move working with signed debian mirrors?
On Mon, Apr 23, 2007 at 02:27:13PM +1000, Duncan Robertson wrote: > It looks like the patches have been made available, just weren't > included in the last release. My apologies -- I have totally forgotten about that. I will look at the patches and make an upload this weekend. Thanks, -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405165: Bug#404525: upgrade-reports: sarge->etch upgrade
On Sun, Jan 07, 2007 at 12:20:22AM -0800, Steve Langasek wrote: > Since this sev: important bug has a significant impact on sarge->etch > upgrades for desktop users, I've prepared an NMU of fam that drops the > Conflicts: as proposed here. The patch is attached, and the NMU has > been uploaded to DELAYED/7-day on gluck to give you an opportunity to > object/override. Hi Steve, Thanks for looking into this issue for me. I am uploading libfam0 2.7.0-12 to unstable right now which contains the same one-line fix you proposed. To the release team, I would like you to approve including the fam 2.7.0-12 packages in etch. The only change from -11, as Steve described, is removing conflict between libfam0 and previous libfam0c102 packages so that upgrade from sarge can proceed without running into dependency conflicts there. Thanks, -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398285: ion3: cannot start with LC_CTYPE=zh_TW.Big5
Package: ion3 Version: 20061029-3 Severity: normal ion3 exits immediately when I start it with the LC_CTYPE environment variable set to zh_TW.Big5. ion2 works fine in the same situation. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-mh1 Locale: LANG=C, LC_CTYPE=zh_TW.Big5 (charmap=BIG5) Versions of packages ion3 depends on: ii libc62.3.6.ds1-7 GNU C Library: Shared libraries ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library ii liblua5.1-0 5.1.1-2 Simple, extensible, embeddable pro ii libsm6 1:1.0.1-3 X11 Session Management library ii libx11-6 2:1.0.3-2 X11 client-side library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library ii rxvt [x-terminal-emulator] 1:2.6.4-10 VT102 terminal emulator for the X ii rxvt-ml [x-terminal-emulator 1:2.6.4-10 multi-lingual VT102 terminal emula Versions of packages ion3 recommends: ii xfonts-100dpi 1:1.0.0-3 100 dpi fonts for X ii xfonts-75dpi 1:1.0.0-3 75 dpi fonts for X -- no debconf information -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394600: apt-move has new upstream version for almost year
On Sat, Oct 21, 2006 at 09:33:57PM -0700, Petr Vandrovec wrote: > For almost year apt-move has upstream version 4.2.26. Would it be > possible to get that version to Debian? Besides other problems it > fixes apt-move behavior when retrieving source packages, which is half > of bug 327867. Sorry about the delay... I will get to that in the next few days. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#377039: error configuring fam in a Debian upgrade
On Thu, Jul 06, 2006 at 12:06:22PM +0200, Francesc Fernandez wrote: > So really my problem is related in the bug report 249131. This bug is > closed but I suffered it, that is the reason for this report. Do you remember (or can you find out) which version of the fam package did you upgrade from? The current stable version, 2.7.0-6sarge1, does have the correct prerm file and should (according to Section 6.6 of Debian Policy) stop famd before upgrade. If you can find out what the old version of the package was, it would help me tremendously in tracking down and fixing the problem. Thanks, -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381423: fam: Leaks memory
On Mon, Oct 02, 2006 at 02:50:05PM +0200, Martin Kos wrote: > i've had the problem that my server started crashing after too much > memory was used (swap was getting to large i think) and i applied your > patch and now everything works fine! thanks. > > chuan-kai, could you please include this patch so it gets perhaps to > etch? thanks! Sorry for the delay and thanks for the reminder. I will try to get a new version with the patch uploaded by Wednesday. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384567: bison: preinst breaks manually selected yacc alternative
On Fri, Aug 25, 2006 at 08:47:22PM +0200, Sven Joachim wrote: > Probably even better would be to just create the missing symlink > yourself, with > > [ -e /usr/bin/yacc ] || ln -s /etc/alternatives/yacc /usr/bin > > instead of > > [ -e /usr/bin/yacc ] || update-alternatives --auto yacc > > manual alternatives don't get destroyed on upgrade from 2.3.dfsg-1. I think we still need to switch the yacc alternative to auto because of the nature of the breakage in 2.3.dfsg-1. If the system contains a working, auto yacc alternative when you install 2.3.dfsg-1, the alternatives system will notice that the /usr/bin/yacc symlink is stomped on and switch the yacc alternative to manual. Manually creating the missing symlink fixes the problem for now, but unless someone switches the yacc alternative back to auto, the alternatives system will leave the yacc alternative alone and result in further breakage (for example, a dangling /usr/bin/yacc symlink after all yacc alternatives had been removed). -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384567: bison: preinst breaks manually selected yacc alternative
On Fri, Aug 25, 2006 at 08:28:20PM +0200, Sven Joachim wrote: > So you have to deal with that in the postinst, rather. I propose the > following solution: > > - Remove the call to update-alternatives from the preinst > - Put your fix in the postinst, after the call to > update-alternatives --install: Sounds good: I will give it a try over the weekend. -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384567: bison: preinst breaks manually selected yacc alternative
On Fri, Aug 25, 2006 at 09:05:26AM +0200, Sven Joachim wrote: > You are trying to fix #383971, but this is _not_ the way to do it! I agree that the current approach is quite awful. > If the user had set the `yacc' alternative to manual, the preinst > script breaks that. A better way to do this would be to test first > if the system is actually affected by #383971, which should only be > the case if /usr/bin/yacc is not a symlink: > > [ -L /usr/bin/yacc ] || update-alternatives --auto yacc Looks good. But what if /usr/bin/yacc is an admin-installed script? I propose the following variety: [ -e /usr/bin/yacc ] || update-alternatives --auto yacc If we are upgrading from 2.3.dfsg-2, by the time the preinst script runs, the /usr/bin/yacc script installed by -2 should have already been removed, so the update-alternatives command would still run. If the admin wishes to manage /usr/bin/yacc manually, he presumably would put something there, and update-alternatives would not run. Does that sound okay? -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#276221: fam doesn't build
On Tue, Oct 12, 2004 at 02:14:06PM -0400, Ari Pollak wrote: > I don't seem to be able to build fam from source, with the latest > packages from sid and all build-deps of fam installed. I don't know > if it's just me or if nobody can build fam, since the last version was > uploaded back in February. Hi Ari, It has been a long time since you reported this bug, and the package has been updated several times and built by myself and buildds all over. Are you still having this problem? Unless you provide a follow-up, I will consider this bug resolved and close it after some time. Thanks, -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301161: Manpage bugs
On Thu, Mar 24, 2005 at 05:43:55AM +0100, Siward de Groot wrote: > * functions FAMMonitor* take an argument 'void* userData', but it is >not described in this manpage. Hi Siward, Sorry that it took such a long time to get back to you. Here are some comments to your reports. The userData is described in the manpage. The second sentence in the "FAMMonitorDirectory, FAMMonitorFile" section says that "The parameters to this function are ... a user data pointer." > * manpage says that struct FAMEvent's member fr has type FAMRequest, > but the compiler disagrees (and it's not a pointer to a FAMRequest > either). I am not sure why you think fr does not have type FAMRequest because that is exactly what the definition in fam.h says. > * i noticed that famd can report multiple change events for a single > change, atleast that's what i saw when i saved a modified file with > xemacs, while simply touch-ing the file resulted in only one event; > maybe it repors changes in filesize and modificationtime separately? > In that case, it could be usefull to document that in the manpage. >From how I understand things, the behavior you observe should be a bug. See #239540 for another description of your behavior. > * manpage says, in description of FAMOpen/FAMClose, that "Variable > char* appName should be set to name of your application.", however, > there is no such variable (at least it is not described in this > manpage). Okay, a fix is forthcoming. > * if i can believe the description in the manpage, > FAMSuspend/ResumeMonitor are completely superfluous, as they have > identical result to simply not requesting events. I think you are right. > * error-reporting is completely broken, according to this manpage, > and there is no mention of what kind of errors could occur, > which makes it kinda difficult to decide how to work around it. I agree, but there is little I can do about that. > * it seems only way to get events in a non-blocking way is to set an > alarm ; but what if alarm goes off while app is receiving an event ? > does this break things or is it atomical ? This is a Unix programming problem not specific to fam. You can find discussions to this issue in the book "Advanced programming in the Unix environment" by Stevens. > * see also refers to fstat(1), which doesn't exist because man fstat > is in section 2; not really a big problem, but it makes my 'mkmyman' > script fail to find it's whatis. Good catch. Fix forthcoming. > * it doesnt include any examples ; if it had, i wouldn't have had to > write my testprogram, so i'm attaching that in case you would like > to include it. Thanks for supplying the example. However, I think it is not really suitable for the man page -- instead I can put it in the libfam-dev package documentation directory if you clean the file up (apply proper indentation and such) and put a DFSG-free license at the top of the source > thanks for maintaining fam, it does work :-) Thanks for submitting the bug report! -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332847: Not resolved yet
On Tue, Apr 04, 2006 at 11:38:04AM +0100, Ssebastia annonygmouse wrote: > I've installed sarge and tried to upgrade to > either testing or unstable and get the following > errror: > deslin1:~# LANG=C aptitude -f dist-upgrade > Reading Package Lists... Done > Building Dependency Tree > Reading extended state information > Initializing package states... Done > Reading task descriptions... Done > Some packages had unmet dependencies. This may mean > that you have > requested an impossible situation or if you are using > the unstable > distribution that some required packages have not yet > been created > or been moved out of Incoming. > > The following packages have unmet dependencies: > libfam0: Conflicts: libfam0c102 (< 2.7.0-9) but > 2.7.0-6sarge1 is installed and it is kept back. > libfam0c102: Conflicts: libfam0 but 2.7.0-9 is to be > installed. > > Any workaround? I have reopened the bug for the time being to prevent it from being archived, but I cannot reproduce your problem in my own experiments. I installed libfam-ruby on a sarge chroot environment, which automatically pulls libfam0c102 and fam (both 2.7.0-6sarge1) based on package dependencies. I then ran "aptitude dist-upgrade" to testing, everything went smoothly, and I ended up with fam, libfam0, and libfam0c102 (all 2.7.0-9). Can you provide me with a list of packages installed on your sarge system before dist-upgrade? Thanks, -- Chuan-kai Lin http://web.cecs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348563: fam: uninstallable in unstable
On Tue, Jan 17, 2006 at 07:23:18PM +0100, Andre 'ILF' Meister wrote: > Package: fam > Version: 2.7.0-8 > Severity: grave > Justification: renders package unusable The problem here is that: 1. Lots of packages Depend on libfam0 (and libgamin0 Provides libfam0) 2. Package libgamin0 Depends on gamin 3. Packages gamin and fam conflict with each other 4. Installing fam removes gamin and libgamin0, so lots of packages suddenly have unsatisfied dependencies. Workaround: Install libfam0 together with fam Possible package fix: The only thing I could do to help is to make fam Depend on libfam0. Such a dependency is artificial in that fam does not really need libfam0 to work, and I have not decided yet if making fam Depend on libfam0 is a good idea. For now I will downgrade this bug and merge it with #315591. -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338370: Intention to NMU
On Thu, Jan 05, 2006 at 06:56:05PM +0100, Luk Claes wrote: > Attached the patch for the version I intend to upload. Please respond > if you don't want this NMU to happen, if you are working yourself on a > patch or if you think that the attached patch won't work. Hi Luk, I have been busy lately, and I appreciate it if you could do the NMU for me. Thank you. Regards, -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ signature.asc Description: Digital signature
Bug#299153: Confirmation of the bug on unstable/testing system
Hi,
I run into this bug on the system as well. I am running Linux 2.6.12
with udev 0.068-2. Here is what I see:
$ /bin/fuser /var/log/mail.info
/dev/.static/dev: Permission denied
$
And performing strace on the process shows the following:
open("/proc/mounts", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
[ snip ]
stat64("/dev/.static/dev", 0xbfde7900) = -1 EACCES (Permission denied)
For some reason fuser is probing all mount points and insist that they
all be readable. Does anyone know why?
--
Chuan-kai Lin
http://www.cs.pdx.edu/~cklin/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327241: fam: May not be upgraded due to funky circular provides
On Fri, Sep 09, 2005 at 05:03:41PM -0700, Steve Langasek wrote: > Can be done, but I didn't offer that option because I don't really > like it. :-) At that point, I don't really see any reason to change > the package name from what it was in sarge. (There never was a good > reason, but it was done anyway because people didn't realize it was a > mistake, and the name change was allowed to stand because it didn't > seem to cause any problems.) Not that it matters, but I am curious: so it would make you much happier if I had suggested making libfam0 a transitional dummy package to libfam0c102 instead of the other way around? -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327241: fam: May not be upgraded due to funky circular provides
On Thu, Sep 08, 2005 at 09:42:28PM -0700, Steve Langasek wrote:
> > > This is an exceedingly odd situation. The only solution that seems
> > > satisfactory to me is to go back to the sarge-style packaging, meaning
> > > kill the libfam0 package and re-introduce libfam0c102.
>
> > The situation is indeed pretty odd. Suppose we kill libfam0 and then
> > re-introduce libfam0c102. What would happen to those people that has
> > libfam0 2.7.0-8 installed on their system?
>
> Same problem, but confined to unstable. I think this is the best
> solution, though, as sid users should be well accustomed to dealing with
> obsoleted packages on their system.
>
> The other option would probably be to keep the package name as libfam0
> in etch, but cause the shlibs to declare a versioned dependency on
> libfam0 (>> $some_value), since this dependency won't be satisfied by a
> Provides:.
How about making the fam source package provide both libfam0c102 and
libfam0, with the former as a transitional dummy package to the latter?
libfam0c102
Depends: libfam0 (=${Source-Version})
libfam0
Provides: libfam0c102
--
Chuan-kai Lin
http://www.cs.pdx.edu/~cklin/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327241: fam: May not be upgraded due to funky circular provides
On Thu, Sep 08, 2005 at 09:06:36AM -0700, Brian Nelson wrote: > The current libfam0 provides the previous libfam0c102, presumably > because libfam is a C++ lib but only exports a C interface, so the > transition for GCC 4 was unnecessary. Yes. > However, the libfam0c102 in sarge provides libfam0. This means that > that package completely satisfies any package in etch that depends on > libfam0 (with the exception of those that have a versioned dependency > on libfam0, like libfam-dev). The consequence is that an "apt-get > dist-upgrade" or equivalent will *not* install libfam0 but will keep > libfam0c102 around instead. If I understand things correctly, the dist-upgrade behavior will happen regardless of whether libfam0 provides libfam0c102 or not. Is that observation correct? So what would happen if (suppose) we do need the g++-4.0 transition and libfam0 does not provide libfam0c102? > This is an exceedingly odd situation. The only solution that seems > satisfactory to me is to go back to the sarge-style packaging, meaning > kill the libfam0 package and re-introduce libfam0c102. The situation is indeed pretty odd. Suppose we kill libfam0 and then re-introduce libfam0c102. What would happen to those people that has libfam0 2.7.0-8 installed on their system? -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319222: ghc6: Depends on non-existing package
On Mon, Jul 25, 2005 at 04:21:11PM -0700, Steve Langasek wrote: > Yes, libgmp is the only C++ lib that ghc6 depends on. I had already > talked to the maintainer about doing a rebuild NMU for this (he isn't > planning to work on these packages until the new upstream version > comes out), but if someone beats me to it, that's fine too. I just tried: ghc-6.4 fails to build on gcc-4.0. The Fedora people had also come to the same conclusion: http://haskell.org/fedora/haskell/4/x86_64/repodata/repoview/ghc-0-6.4.1.20050626-0.html So there we are. I would like to keep ghc-6.4 (the new features like GADT are really amazing), but making the source to build would likely be a major undertaking. -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296609: confirmed
On Wed, Aug 03, 2005 at 12:50:32PM -0400, Joey Hess wrote: > I can confirm that fam 2.7.0-7 fixes this problem. > It's a real pity sarge shipped with the broken version. Okay. I need to do an upload to sarge to fix #316579 anyway, which seems to be the same bug as this one. I will let you know when the upload is ready, so that you can test it before the actual upload to see if the problem is gone. How does that sound? -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316207: Apt Upload - Time for apt-move upload?
On Thu, Aug 04, 2005 at 12:37:13AM +1200, Nigel Jones wrote: > I was just talking in #debian-devel and it seems the path is clear for > a update for this bug to go in... You are right in that the g++ ABI transition path is now clear, but another semi-showstopper related to apt 0.6 transition turned up yesterday (see #320827). In my opinion doing a crippled upload is not well justified (the point of apt-move is that local cache should be used whenever possible), and I prefer delaying the upload until we solve #320827 as well. I have asked Herbert Xu (upstream) to evaluate the patch, and judging by his excellent track record, we should have a fix RSN. -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320827: apt-move should sign local archive...
On Mon, Aug 01, 2005 at 09:53:02PM +0200, Petr Vandrovec wrote: > although apt-move needs rebuild to work with updated apt, so it > is currently uninstallable in unstable, if you'll rebuild it, > you'll notice that all packages are downloaded from the network > again and again as 'apt-get' prefers trusted signed sources > over unsigned, and there is no option how to disable this > behavior (only way I've found is modifying apt-get to treat > all sources as untrusted). Hi Herbert, Could you have a look at the patch in the bug report and let me know what you think? If you like it, I can incorporate the patch into my next (g++ 4.0 transition) upload. Thanks, -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318836: libfam-dev: Package uninstallable
On Mon, Jul 18, 2005 at 09:17:33AM +0200, Christian Marillat wrote: > Package: libfam-dev > Severity: serious > > This package depends on libfam0 who doesn't exist. > Should depends on libfam0c102 Which version of libfam-dev are you using? Version 2.7.0-7 depends on libfam0c102. Due to the recent g++ 4.0 ABI change transition (see debian-announce mailing list archive), the new 2.7.0-7.2 upload of libfam package has been renamed from libfam0c102 to libfam0. It is correct for libfam-dev 2.7.0-7.2 to depend on libfam0, which had already entered unstable. See http://packages.debian.org/unstable/libs/libfam0. I am going to close this bug. -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316614: Bug #316614 and hibernate 1.09 upload
Hi, According to the QA package tracking system, 1.09 has not been accepted into the archive yet, which may be why the changelog annotations did not close the bug automatically. Can you confirm that the upload is good, or do another 1.09 upload? If for some reason 1.09 cannot get through, then we should probably reopen the bugs you closed manually. [1] http://packages.qa.debian.org/h/hibernate.html -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317839: fam upload
On Mon, Jul 11, 2005 at 07:13:29PM -0400, Mike Furr wrote: > Since libfam-dev is broken with gcc-4.0, it would be great if the > package was updated asap. If you are still busy, I would be happy to > upload a new version with the one line diff described in this bug. Ewww! This seems pretty bad. Please do another NMU for me. Thanks, -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317700: Rebuild for C++ transition
On Sun, Jul 10, 2005 at 03:57:22PM -0400, Mike Furr wrote: > fam needs to be rebuilt for the c++ transition. Today marks 5 days since > the new gcc packages were uploaded (the only c++ dep) and so I plan to > NMU into DELAYED/2-day. The new binary name will be libfam0 to match > what ubuntu has done. I have been a little busy lately, so you are welcome to do the NMU. Thanks, -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316579: fam: compact flash card destroyed
On Sat, Jul 09, 2005 at 04:12:29PM -0600, Jamin W. Collins wrote: > I'm fairly certain the version of fam that was installed was 2.7.0-6 > as that's the version that still has an entry in /var/lib/dpkg/status: That settles the question then. I will prepare an upload to sarge with the #234787 patch. -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316579: fam: compact flash card destroyed
On Thu, Jul 07, 2005 at 02:30:10AM -0700, Steve Langasek wrote: > AIUI, this bug is the same as bug #234787. Is that correct? If so, > this bug is now sarge-only. Are there any plans to apply that fix for > sarge? There seems to be at least two problems here: one is that fam did not stop monitoring the mounted CF card before the unmount, and the other is that Gnome desktop incorrectly reported the CF card as being unmounted. The first problem could be the same one as in #234787, but the second sounds really like a Gnome bug. There is no package version number in the bug report, but it does look like the submitter is using testing/unstable, which means his fam program has already been patched for #234787. fam is quite a mess with unresponsive upstream, and it would not surprise me that there are other bugs lurking in the program. Here is my take on what should happen: For the short term, getting the Gnome folks to migrate to gamin (a drop-in replacement of fam) may be the best choice. According to the author of gamin, not supporting FAMSuspendMonitor(), FAMResumeMonitor(), and FAMMonitorCollection() simplifies system design quite a bit, so gamin should be less buggy than fam. For the long term, we need to solve the "monitoring interferes with unmounting" problem at a more fundamental level; otherwise something will always go wrong and prevent unmounting. Unfortunately this interference is the result of limitations of the kernel dnotify API, and the problem can be completely solved only with the new ionotify API, which has not been accepted into the Linux kernel yet. gamin supports ionotify in patched kernels, but fam only understands dnotify. To summarize, we are kind of screwed, because there is not much we can do to help the poor users. In any case, I will start talking to the Gnome team about the migration to gamin. -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316207: Fixed packages waiting for APT g++ ABI upgrade
Hi all, This is a status update. The fixed apt-move package is ready, but we are now in g++-4.0 ABI change transition period (see devel-announce), so we need to wait until the new apt package compiled against g++-4.0 is accepted into unstable before uploading the fix. Regards, -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310391: apt-move: Please pick up upstream changes
On Mon, May 23, 2005 at 08:23:19PM +1000, [EMAIL PROTECTED] wrote: > I've made a new release (4.2.24) containing a number of changes > which I would like you to pick up. You can find it at > http://gondor.apana.org.au/~herbert/apt-move/files/ > If you upload this to Debian, please use the standard Debian > versioning scheme of 4.2.24-1. Thanks a lot for your work on this project! A quick question for you: I see that there is still a debian/ subdirectory in the tarball, and you still record upstream changes in the changelog file there. Do you have plans to create an upstream changelog file elsewhere, so that we can devote the one in debian/ to Debian packaging changes only? Regards, -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316207: Merge duplicate bug reports
package apt-move merge #316207 #316492 thanks Thanks for the reports; I will try to get this done this weekend. -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#307947: bison-doc replaces files in bison
On Fri, May 06, 2005 at 09:12:23PM +0200, Matthias Klose wrote: > bison-doc misses a: Replaces: bison (<< 2.0) Thanks for the report. I have fixed this problem in my svn repository, and the fix will appear in the next release of bison. -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303194: fam packages
On Mon, Apr 18, 2005 at 09:17:13AM +0200, Joerg Wendland wrote: > Hi Chuan-kai, > are you still interested in adopting fam? If not, I'll retitle this bug > to O and upload fam with maintainer set to QA. Yes, I am still working on that (want to fix some bugs with the new maintainer upload), and I probably need a few more days. But I will do the upload as soon as I can. Regards, -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303194: Offering to Adopt fam Package
Hi Joerg, I am interested in adopting the fam package. I know C and Unix system programming pretty well, so I do not imagine any troubles handling the package. Are there any gotcha's about the package that I need to know? Regards, -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303112: bhl: Upstream version 1.7.3 available
Package: bhl Version: 1.7.0a-1 Severity: wishlist Hi, http://www.nongnu.org/bhl/ I would be nice if we can have 1.7.3 packaged. Thanks. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11 Locale: LANG=C, LC_CTYPE=zh_TW.Big5 (charmap=BIG5) Versions of packages bhl depends on: ii emacs21 [emacsen] 21.4a-1The GNU Emacs editor -- no debconf information -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303056: Downgrading and merging 303056
severity 303056 wishlist merge 303056 297197 thanks Thanks for the reminder, and Bison 2.0 have already been uploaded to the experimental distribution a while ago. Since Bison is part of the build toolchain, the package is currently frozen, and it is my understanding that the release team does not wish to make changes to the build chain unless absolutely necessary. Not that anyone had found anything wrong with the 2.0 package yet -- but I am afraid we will be stuck with version 1.875d in sarge. To release team: do you want to have Bison 2.0 in unstable? -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301075: On #301075: bison and yacc alternatives
On Sat, Mar 26, 2005 at 11:25:42AM +0100, Michael Schmitz wrote:
> It's not about a dangling alternatives link - that you could detect, and
> rightly refuse to overwrite it ('the system administrator sure knows what
> he's doing'). I don't understand why, in the absence of any link, the
> alternative isn't installed without invoking --auto. On this, I'd like
> some input from the dpkg crew.
(Note: I trimmed m68k-build from the CC list)
Well, maybe "dangling alternative" is a better term than "dangling link"
(I use "dangling" to describe a reference whose destination does not
exist). I think dpkg maintains the alternatives database in
/var/lib/dpkg/alternatives, so merely removing the old byacc symlink in
/etc/alternatives or whatever does not do the trick. We need to do
"update-alternatives --remove" to completely remove the dangling
alternative.
What I was suggesting was that dpkg knows the following things:
1. bison is trying to set up an alternative for yacc
2. The yacc alternative is pointed to byacc
3. The byacc program does not exist, and does not belong to any
currently installed package
So in principle dpkg should be able to determine that the byacc
alternative for yacc is bogus and remove it automatically. This just
seems more elegant.
--
Chuan-kai Lin
http://www.cs.pdx.edu/~cklin/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#282076: O: pwgen -- Automatic Password generation
On Wed, Mar 30, 2005 at 07:34:34PM +0200, Jeroen van Wolffelaar wrote: > On Fri, Nov 19, 2004 at 05:40:18PM -0500, Theodore Ts'o wrote: > > Sure, I'll take this. > What's the status of this? Well, if all else fails, my offer to adopt the package is still open. -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301075: On #301075: bison and yacc alternatives
On Thu, Mar 24, 2005 at 09:14:11AM +0100, Michael Schmitz wrote: > > > 2. If you think that bison should work even under this specific > > > breakage (after all the byacc link is obviously stale), you need > > > to fix dpkg instead of bison. > I strongly doubt it's dpkg's fault. After all, handling compatibility > problems of that sort is supposed to happen in postinst (which is what > I suggested). [I cc'ed the dpkg developers in hope of getting some opinions.] If you think some package should take care of this problem, we need to figure out what is the best place to fix this problem. I agree it is not dpkg's fault, and I am only saying that the workaround should be in dpkg instead of in bison postinst. Correct me if I am wrong: the problem is caused by a dangling link in the alternatives system that refers to an uninstalled package. dpkg knows that byacc is not installed, so in principle update-alternatives should be able to remove the invalid alternative all by itself. Even if we fix the problem in bison properly (that means something other than "update-alternatives --auto yacc"), the same issue will bite us again when some other package forgets to remove alternatives on uninstall. If we fix the problem in dpkg, we are not going to run into the same issue again. That is why I think the fix (or rather, the workaround) should be in dpkg instead in bison postinst. > > > 1. Nothing needs to be done. We close the bug. > > > 2. Something needs to be done. We assign this bug to dpkg. > dpkg can't be expected to know everything of that sort. If the byacc > breakage is a known problem you should account for it. If byacc is not installed, then dpkg should be able to figure out that the alternative is invalid. Furthermore there is no good way to fix the issue in bison: "update-alternatives --auto yacc" overrides system admin configuration and will annoy a whole bunch of other people. How do you expect bison to "account for" the byacc breakage? > Thanks for demonstrating the power of RC bugs in making life easier > for us autobuild maintainers. Wow, take it easy, man. There is no need to be sarcastic. We do want to help make your life easy. But that does not mean we should go making the wrong changes where they do not belong. There are simpler ways to make your life easier. The fixed byacc is in testing, and if you clean up any invalid byacc alternatives in the chroot environments, they are not going to show up again. Much faster than waiting for fixed bison/dpkg/whatever to enter testing. -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301075: On #301075: bison and yacc alternatives
On Wed, Mar 23, 2005 at 06:41:09PM +0100, Michael Schmitz wrote: > > I think I ran into this a few months back. It had to do with > > alternatives -- very odd. > Odd indeed. I found a stale yacc alternatives file for bison (byacc) on > kullervo, that might have prevented proper alternatives installation. This is not the first time this had happened -- see #289139. > > It seems like I had to do something like > > update-alternatives --auto yacc > Which constitutes a bug in bison. I respectfully disagree. The bison package handles alternatives the way it is supposed to. There are two ways to look at the breakage: 1. Another package (an old version of byacc, see #283174) broke the alternatives system, and as a result bison installation fails to work as expected. You can always break the alternatives system one way or the other, and I do not consider it reasonable to blame the resulting malfunction to bison. 2. If you think that bison should work even under this specific breakage (after all the byacc link is obviously stale), you need to fix dpkg instead of bison. > Funny enough, after a single invocation of update-alternatives --auto, > it does. Hence, adding that to the postinst seems like a good idea. > Bug filed. This bug workaround overrides a system configuration option set by the administrator, thus I do not consider it a valid fix. As I explained, the right fix belongs in dpkg instead of bison anyway. So this bug can go in one of the two directions: 1. Nothing needs to be done. We close the bug. 2. Something needs to be done. We assign this bug to dpkg. Let me know your thoughts. -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295592: mondo: Error extracting partition name of filesystem
Package: mondo
Version: 2.04-2
Severity: normal
Tags: patch
Mondo tries to obtain the partition name of the filesystem that is going
to hold the ISO image with the following command:
"df %s | tail -n1 | cut -d' ' -f1"
But this fails when devfs is used, because the long device names causes
df to wrap lines, as shown here:
$ /bin/df /
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/ide/host0/bus0/target0/lun0/part2
2976432 1324852 1500380 47% /
Instead of getting /dev/ide/host0/bus0/target0/lun0/part2, the command
used by Mondo returns an empty string. To fix this problem, simply give
the -P option to df.
$ /bin/df -P /
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/ide/host0/bus0/target0/lun0/part2 2976432 1324848 1500384 47% /
I also attach a patch to libmondo-tools.c with this message.
-- Package-specific info:
/var/log/mindi.log and /var/log/mondo-archive.log not included as per user
request.
=
Fileystem information not included as per user request.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (900, 'testing'), (300, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: LANG=C, LC_CTYPE=zh_TW.Big5 (charmap=BIG5)
Versions of packages mondo depends on:
ii afio 2.5-3 archive file manipulation program
ii binutils 2.15-5 The GNU assembler, linker and bina
ii buffer1.19-7 Buffering/reblocking program for t
ii cdrecord 4:2.01+01a01-2 command line CD writing tool
ii dosfstools2.10-1 Utilities to create and check MS-D
ii gawk 1:3.1.4-2 GNU awk, a pattern scanning and pr
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii libnewt0.51 0.51.6-20 Not Erik's Windowing Toolkit - tex
ii lzop 1.01-3 fast compression program
ii mindi 1.04-2 creates boot/root disks based on y
Versions of packages mindi depends on:
ii bzip2 1.0.2-1A high-quality block-sorting file
ii file 4.12-1 Determines file type using "magic"
ii gawk 1:3.1.4-2 GNU awk, a pattern scanning and pr
ii mindi-busybox 1.00-3 busybox for mindi/mondo
ii mindi-kernel 2.4.27-1 Failsafe linux kernel for mindi
ii mindi-partimagehack 0.6.2-3mindi/mondo version of partimage,
ii mkisofs 4:2.01+01a01-2 Creates ISO-9660 CD-ROM filesystem
ii ms-sys1.1.3-1Write a Microsoft compatible boot
ii nano 1.2.4-3free Pico clone with some new feat
ii parted1.6.11-8 The GNU Parted disk partition resi
ii syslinux 2.11-0.1 Bootloader for Linux/i386 using MS
-- no debconf information
--
Chuan-kai Lin
http://www.cs.pdx.edu/~cklin/
--- mondo/common/libmondo-tools.c.orig 2005-02-16 13:12:04.0 -0800
+++ mondo/common/libmondo-tools.c 2005-02-16 13:12:31.0 -0800
@@ -825,7 +825,7 @@
*/
log_it("isodir = %s", bkpinfo->isodir);
- sprintf(command, "df %s | tail -n1 | cut -d' ' -f1", bkpinfo->isodir);
+ sprintf(command, "df -P %s | tail -n1 | cut -d' ' -f1", bkpinfo->isodir);
log_it("command = %s", command);
log_it("res of it = %s",
call_program_and_get_last_line_of_output(command));
sprintf(iso_dev, "%s",
call_program_and_get_last_line_of_output(command));
Bug#289964: grisbi: balance sometimes shows up as -0.00
Package: grisbi Version: 0.5.3-1 Severity: minor In some cases the balance of an account shows up as -0.00 when it is supposed to be 0.00. This happens when a debit transaction leads to a negative balance, and then a credit transaction brings the balance back to exactly zero. This does not influence the core functionality of the package, but -0.00 shows up in red instead of in black, and a liability account with -0.00 balance is not shown as closed. I would have submitted the bug to upstream myself, but I do not speak French... -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=C, LC_CTYPE=zh_TW.Big5 (charmap=BIG5) Versions of packages grisbi depends on: ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libglib2.0-02.4.8-1 The GLib library of C routines ii libgtk2.0-0 2.4.14-2 The GTK+ graphical user interface ii libofx0c102 0.6.6-2.1library to support Open Financial ii libpango1.0-0 1.6.0-3 Layout and rendering of internatio ii libxml2 2.6.11-5 GNOME XML library ii zlib1g 1:1.2.2-3compression library - runtime -- no debconf information -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
