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
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 `main' 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 none pn asciidoctor-doc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#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 svenj...@gmx.de 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-rc-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 fsate...@gmail.com 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-rc-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-rc-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 a...@lrde.epita.fr 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-rc-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 fsate...@debian.org 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-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644200: Two unrelated liby-dev packages in the archive
On Mon, Oct 3, 2011 at 3:16 PM, Phil Brooke p...@debian.org wrote: My intent after the last release was to suggest that the yiff packages are removed from the archive. It's not needed in any other packages, IIRC. I'll try to check that soon. But it means that the bison version can be retained without fuss. My bad -- should have checked for package name conflict before introducing liby-dev as part of bison multi-arch support. Let me know if I should upload a new bison version without liby-dev. Thanks, Chuan-kai -- To UNSUBSCRIBE, email to debian-bugs-rc-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-rc-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-rc-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-rc-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-rc-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#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#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#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#347066: NMU for synergy uploaded to delayed Queue.
On Tue, Jan 17, 2006 at 09:15:07PM +0100, Cord Beermann wrote: I again state my interest to take over maintanance of this package, but Chuan-kai Lin [EMAIL PROTECTED] also said in March 05 that he wants it (cklin, do you still want to? then i'll withdraw my interest. Please respond, else i'll hijack the package in one or two months. (If Dan also keeps silence)) Hi Cord, I am still interested in synergy, but my hands are already pretty full with the packages currently under my care. So you are welcome to have the synergy package, and let me know if you need help with it. I would like to see you take over the package... I think we have been waiting too long already. -- Chuan-kai Lin http://www.cs.pdx.edu/~cklin/ signature.asc Description: Digital signature
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#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#316579: New fam package ready for sarge upload
Hi all, You have reported a bug on fam that prevents removable media from unmounting and causes other related problems. I have prepared a new fam package for the sarge (current stable) release that should address these issues. Please test, and let me know if the fix works for you. 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#296609: New fam package ready for sarge upload
Hi again, Oops. I forgot to give you the URL to the new packages. http://www.cs.pdx.edu/~cklin/fam-update/ -- 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: New fam package ready for sarge upload
On Fri, Aug 05, 2005 at 12:28:01PM -0600, Jamin W. Collins wrote: I'm sorry, but I do not have another compact flash that I'm willing to potentially destroy testing this. At this point I've completely removed FAM from my systems and plan to keep it that way. I can hardly fault you for your attitude. However there are known safe ways to test if the problem is fixed. Insert a CF card into your card reader while famd is running, do something with the CF card, and then unmount it from the Gnome desktop. Type df in the command line to see if the CF card has been unmounted (the correct behavior is that you should not see your CF card listed in the df output). Then, type # invoke-rc.d fam stop # umount /mnt/compactflash(replace with your CF card mount directory if it is still mounted) Verify with df that your CF card is indeed no longer mounted, and then you can remove the card with no danger whatsoever. If you are still unsure, you can remove the fam package, shutdown the computer, and then remove the CF card; this should be as safe as you can get. Of course, I would understand if you just do not wish to touch fam with a 10-foot pole for the rest of your life. But having confirmation from the original bug submitter is very important for our quality-assurance work, so I would really appreciate it if you could try this one. 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#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#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#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#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#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#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#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#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#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]
