Bug#679600: Info to make a ptach?
This bug was reported to CPAN about 2 weeks ago, with no response as of yet that I can see. The initial reporting suggests a patch, but does not contain a patch. https://rt.cpan.org/Public/Bug/Display.html?id=77836 Gord -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679600: Info received (Info to make a ptach?)
The sample program to demonstrate the bug at CPAN, has MMagic analyse a string containing the letter 'a' and this bug report has MMagic analysing the contents of the /etc/debian_version file. At the point in checktype_contents() where it is about to call itself again (hence the infinite recursion problem), the suggestion is that checktype_container() be called instead. In order for checktype_container to be of any use here, the $self object needs to have something useful in the chook component of the object. At this point, chook is empty, which is going to result in checktype_container returning an empty string to checktype_contents. Debugging in emacs/perldb, I tried calling checktype_data instead, and it would end up returning undef in trying to identify data for a string of 'a'. I made the suggested change in sub checktype_contents(). The subroutine checktype_container() doesn't return a type. Checktype_magic() is called next, it too fails. Checktype_data() also can't find a type. Which would result at the end, of a type of text/plain be assigned for the type, if that line of code wasn't commented out. So it returns undef. Trying a string of #!/usr/bin/perl\n, MMagic also returns undef. Trying a string of: 'htmlheadtitleTitle/title/headbodypBody/p/body/html' , MMagic returns text/html. To me, it sort of looks like this checktype_container() was added for some reason, but the changes were never completed. It kinds of looks like the user has to provide their own subroutines to check for the contents of containers (similar to checktype_*), but there doesn't seem to be documentatino on this. But I am just guessing. I never looked at this code before. Downloading the tarball from CPAN, the only function really tested is checktype_filename(), and the only types returned are text/plain and text/html in the tests. Gord -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676463: #676463 sysv-rc: complains incorrectly(?) about obsolete init.d scripts for fuse and others
On June 11, 2012, Paul Menzel wrote: Am Montag, den 11.06.2012, 16:11 +0300 schrieb Timo Juhani Lindfors: after changing add_problematic package $package left obsolete init.d script behind in /var/lib/dpkg/info/sysv-rc.postinst to add_problematic package $package left obsolete init.d script $initscript behind I get nice, the suggestion worked. ;-) The 3 scripts from initscripts this flags for me, all involved bootlogd. Bootlogd stuff with the same 3 file names was in the version of initscripts currently in stable. There are some bootlogd scripts in the version of initscripts in testing, but not all of them. The bootlogd package is available for unstable, with these same scripts in them (by name, not necessarily content). Manually deleting those files and then installing bootlogd got rid of the 3 initscript errors for sysv-rc. With fuse, the upgrade of fuse-utils was supposed to let people purge fuse-utils (its marked as transitional). The problem that I see, is that fuseiso still depends on fuse-utils. Purging fuse- utils and fuseiso, I still get the sysv-rc complaining about fuse (and smartmontools). Manually deleting /etc/init.d/fuse and any /etc/rc[0-6].d/*fuse symlinks, and then doing a reinstall of fuse got rid of the fuse problems for sysv-rc. Manually deleting smartmontools and smartd from /etc/init.d/ and any *smart* symlinks from /etc/rc[0-6].d/ and then doing a reinstall of smartmontools got rid of the smartmontools problems for sysv-rc. Which just leaves the LSB tags and overrides of scsi-idle and its symlink. Scsi-idle as a package was removed from Debian in 2007 (the file of mine is dated 2004). I still show scsi-idle-2.4.23-5 as being installed. Purging that package, allows dependency based booting to be set by sysv-rc for me. Gord -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676463: me too and more info
I have the same packages triggering init script warnings. In addition, I get a warning from insserv files about K20scsi-idle and scsi-idle missing LSB tags and overrides. Gord -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676463: me too and more info
On June 8, 2012, Paul Menzel wrote: Gordon, thank for the follow up. In the future please add the addresses of all people who responded in that bug thread to CC. Even better, import the messages from the mbox you get with bts show --mbox 676463 What mbox? I don't get any mboxen. I just sent an email with kmail to the bugs address for this bug. and reply to the appropriate message to keep the threading and ease the life of everyone. I'm sure if I do that all the time, someone will come along with something else I am doing wrong. Am Freitag, den 08.06.2012, 21:40 +0100 schrieb Roger Leigh: On Fri, Jun 08, 2012 at 02:16:58PM -0600, Gordon Haverland wrote: I have the same packages triggering init script warnings. In addition, I get a warning from insserv files about K20scsi-idle and scsi-idle missing LSB tags and overrides. Could you possibly attach a copy of each failing script? Please find the scripts attached. There seem to be also three scripts from the `initscripts` package which cause some problems. /etc/init.d /etc/init.d/rmnologin /etc/init.d/umountnfs.sh /etc/init.d/umountroot /etc/init.d/sendsigs /etc/init.d/single /etc/init.d/killprocs /etc/init.d/hostname.sh /etc/init.d/mountall.sh /etc/init.d/halt /etc/init.d/umountfs /etc/init.d/checkfs.sh /etc/init.d/mountall-bootclean.sh /etc/init.d/mountnfs.sh /etc/init.d/bootlogs /etc/init.d/mountdevsubfs.sh /etc/init.d/bootmisc.sh /etc/init.d/checkroot.sh /etc/init.d/mountnfs-bootclean.sh /etc/init.d/skeleton /etc/init.d/reboot /etc/init.d/mountoverflowtmp /etc/init.d/rc.local /etc/init.d/mtab.sh /etc/init.d/mountkernfs.sh /etc/init.d/urandom Okay, I forced dpkg to install the new initscripts package with -- force-depends. I now get 3 mystery files from initscripts causing problems. I looked at all the files from initscripts that install in init.d/ There are 6 files which do not have a last line which starts with a full colon. One that does has : exit 0 There are 6 files where the first executable line is not PATH= There are 6 files where the first non-empty line after ### END INIT INFO line is a comment line. There are 5 or 6 lines in the INIT INFO area, where there is no argument to the field, but there is whitespace after the full colon. I believe two of the files have a tab as the trailing whitespace, the remainder having a single space as the trailing whitespace. I think one file has both (one of each). Without knowing what your program is looking for, that is all I can guess at. Time to get back to writing a presentation on NORM. Gord -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676463: me too and more info
On June 8, 2012, Paul Menzel wrote: Am Freitag, den 08.06.2012, 16:34 -0600 schrieb Gordon Haverland: On June 8, 2012, Paul Menzel wrote: thank for the follow up. In the future please add the addresses of all people who responded in that bug thread to CC. Even better, import the messages from the mbox you get with bts show --mbox 676463 What mbox? I don't get any mboxen. Did you run the command? `bts` is in package `devscripts`. Normally mutt opens automatically, but you can exit with `q` right away. The downloaded mbox (mail box) files is stored under `~/.devscripts_cache/bts/`. I just sent an email with kmail to the bugs address for this bug. I know. And I did not receive your message. I had to check the Web page manually to see if there was an answer. Sorry, I am not a developer or a Debian maintainer. I've lived with UNIX since 1984 and computers since 1978. At heart, I am a FORTRAN programmer, but I've dabbled in lots of stuff. I have more than enough other stuff to keep me busy, I was just trying to help. Downloading other mbox to add to my kmail isn't on my list of things I want to do. and reply to the appropriate message to keep the threading and ease the life of everyone. I'm sure if I do that all the time, someone will come along with something else I am doing wrong. Nobody has said such things to me yet. I am pretty sure that is the preferred way. Over the years, I seldom reply to all. As a general principle, it seemed to cause more problems than it solved. I will try to do this with bugreports, but I suspect even there, I will find more people wondering why I wrote them, than people thanking me for writing them. Am Freitag, den 08.06.2012, 21:40 +0100 schrieb Roger Leigh: On Fri, Jun 08, 2012 at 02:16:58PM -0600, Gordon Haverland wrote: I have the same packages triggering init script warnings. In addition, I get a warning from insserv files about K20scsi-idle and scsi-idle missing LSB tags and overrides. Could you possibly attach a copy of each failing script? Please find the scripts attached. There seem to be also three scripts from the `initscripts` package which cause some problems. /etc/init.d /etc/init.d/rmnologin /etc/init.d/umountnfs.sh /etc/init.d/umountroot /etc/init.d/sendsigs /etc/init.d/single /etc/init.d/killprocs /etc/init.d/hostname.sh /etc/init.d/mountall.sh /etc/init.d/halt /etc/init.d/umountfs /etc/init.d/checkfs.sh /etc/init.d/mountall-bootclean.sh /etc/init.d/mountnfs.sh /etc/init.d/bootlogs /etc/init.d/mountdevsubfs.sh /etc/init.d/bootmisc.sh /etc/init.d/checkroot.sh /etc/init.d/mountnfs-bootclean.sh /etc/init.d/skeleton /etc/init.d/reboot /etc/init.d/mountoverflowtmp /etc/init.d/rc.local /etc/init.d/mtab.sh /etc/init.d/mountkernfs.sh /etc/init.d/urandom Okay, I forced dpkg to install the new initscripts package with -- force-depends. I now get 3 mystery files from initscripts causing problems. I also get these errors with `initscripts` 2.88dsf-22.1 installed. Only `sysv-rc` is currently not configured on this system. I looked at all the files from initscripts that install in init.d/ There are 6 files which do not have a last line which starts with a full colon. One that does has : exit 0 There are 6 files where the first executable line is not PATH= There are 6 files where the first non-empty line after ### END INIT INFO line is a comment line. This doesn't seem to matter. There are 5 or 6 lines in the INIT INFO area, where there is no argument to the field, but there is whitespace after the full colon. I believe two of the files have a tab as the trailing whitespace, the remainder having a single space as the trailing whitespace. I think one file has both (one of each). This doesn't seem to matter. Interesting. Did you fix these right away (and send patches)? :P No, I didn't send patches. There seemed to be lots of times where trailiing whitespace caused problems for people in Perl, so that is one thing I look at. But, it is easy enough in Perl (and other languages) to strip trailing whitespace. Without knowing what your program is looking for, that is all I can guess at. Guess we have to check what the package scripts actually check. I also looked at INFO areas where a Short-Description had content and a Description didn't, where X-interactive was present and a couple of other things. So far nothing I change alters the fact 3 scripts from initscripts are causing problems. Looking at the logfile that sysv-rc.postinst produces also doesn't show 3 errors
Bug#666691: A different occurrence
I should amend my previous note. Any new emacs session in text mode freezes. I had an existing emacs in text mode before something was upgraded, which still works normally. Gord -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666691: A different occurence
I've got a number of emacs sessions running, all normally. Today I cloned a GIT tree and went to explore the tree with emacs in a text session terminal, and had emacs start using 100% CPU. Emacs didn't respond to anything, but was killable in another session. Gord -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636303: Me too
I get this error for an ordinary user, and for root. I've tried printing to a local printer from emacs, and with a2ps. Same error (over USB). I'm running unstable. Gord -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577499: Me too
with the dfsg-2 update that came out, I seen LocalSocketGroup 20 thing with my computer. I set it to 125 (which is the group clamav is on this computer). Clamav started, but I started getting messages from freshclam (cron jobs) about some missing argument. Trying to fix things, I then got a message about freshclam not being able to contact clamd via /var/run/clamav/clamd.ctl. So, this morning, I purged all of clamav and reinstalled it. This message about clamd.ctl persists. Gord -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577499: [Pkg-clamav-devel] Bug#577499: Me too
On April 24, 2010, Stephen Gran wrote: This one time, at band camp, Gordon Haverland said: with the dfsg-2 update that came out, I seen LocalSocketGroup 20 thing with my computer. I set it to 125 (which is the group clamav is on this computer). Clamav started, but I started getting messages from freshclam (cron jobs) about some missing argument. Trying to fix things, I then got a message about freshclam not being able to contact clamd via /var/run/clamav/clamd.ctl. So, this morning, I purged all of clamav and reinstalled it. This message about clamd.ctl persists. Can you set LocalSocketGroup to clamav in the config file, run dpkg-reconfigure and see what it is in the file afterwards? LocalSocketGroup was already set to clamav, and the mode is 666. dpkg-reconfigure for clamav didn't appear to do anything, no files altered in /etc/clamav dpkg-reconfigure clamav-base asked questions, no files changed. dpkg-reconfigure clamav-daemon asked questions, no files changed. dpkg-reconfigure clamav-freshclam asked questions, no files changed. It appears that freshclam updated properly, and was able to contact the daemon as part of how dpkg-reconfigure finished for freshclam. It would seem that the reconfigures did something, but none of the changed were in /etc/clamav. Want me to purge, reinstall and check something else? Gord -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577499: [Pkg-clamav-devel] Bug#577499: Me too
On April 24, 2010, Michael Tautschnig wrote: On April 24, 2010, Stephen Gran wrote: This one time, at band camp, Gordon Haverland said: with the dfsg-2 update that came out, I seen LocalSocketGroup 20 thing with my computer. I set it to 125 (which is the group clamav is on this computer). Clamav started, but I started getting messages from freshclam (cron jobs) about some missing argument. Trying to fix things, I then got a message about freshclam not being able to contact clamd via /var/run/clamav/clamd.ctl. So, this morning, I purged all of clamav and reinstalled it. This message about clamd.ctl persists. Can you set LocalSocketGroup to clamav in the config file, run dpkg-reconfigure and see what it is in the file afterwards? LocalSocketGroup was already set to clamav, and the mode is 666. dpkg-reconfigure for clamav didn't appear to do anything, no files altered in /etc/clamav dpkg-reconfigure clamav-base asked questions, no files changed. dpkg-reconfigure clamav-daemon asked questions, no files changed. dpkg-reconfigure clamav-freshclam asked questions, no files changed. It appears that freshclam updated properly, and was able to contact the daemon as part of how dpkg-reconfigure finished for freshclam. It would seem that the reconfigures did something, but none of the changed were in /etc/clamav. Want me to purge, reinstall and check something else? Could you attach your (broken) config files? It should then be pretty easy for us to reproduce the problem. My problem, however, is that I'm not all that sure anymore what your actual problem is. Is it just that freshclam cannot use the socket? Which user are you running freshclam as? Is it the same user that is used for clamd? After the 4 dpkg-reconfigure runs, things seem to be working. That was the end result mentioned above. That nothing in /etc/clamav changed after the fresh re-install (after purging) was interesting. It is hard to see the config files as being broken, if they weren't changed by any of the dpkg-reconfigure runs. As I asked, I could easily purge them all again, and reinstall again, to check other things (/var/run ?). Something must have changed, in order for things to be working now, but not after the initial install. Gord #Automatically Generated by clamav-base postinst #To reconfigure clamd run #dpkg-reconfigure clamav-base #Please read /usr/share/doc/clamav-base/README.Debian.gz for details LocalSocket /var/run/clamav/clamd.ctl FixStaleSocket true LocalSocketGroup clamav LocalSocketMode 666 # TemporaryDirectory is not set to its default /tmp here to make overriding # the default with environment variables TMPDIR/TMP/TEMP possible User clamav AllowSupplementaryGroups true ScanMail true ScanArchive true ArchiveBlockEncrypted false MaxDirectoryRecursion 15 FollowDirectorySymlinks false FollowFileSymlinks false ReadTimeout 180 MaxThreads 12 MaxConnectionQueueLength 15 StreamMaxLength 10M LogSyslog false LogFacility LOG_LOCAL6 LogClean false LogVerbose false PidFile /var/run/clamav/clamd.pid DatabaseDirectory /var/lib/clamav SelfCheck 3600 Foreground false Debug false ScanPE true ScanOLE2 true ScanHTML true DetectBrokenExecutables false ExitOnOOM false LeaveTemporaryFiles false AlgorithmicDetection true ScanELF true IdleTimeout 30 PhishingSignatures true PhishingScanURLs true PhishingAlwaysBlockSSLMismatch false PhishingAlwaysBlockCloak false DetectPUA false ScanPartialMessages false HeuristicScanPrecedence false StructuredDataDetection false CommandReadTimeout 5 SendBufTimeout 200 MaxQueue 100 LogFile /var/log/clamav/clamav.log LogTime true LogFileUnlock false LogFileMaxSize 0 Bytecode true BytecodeSecurity TrustSigned BytecodeTimeout 6 OfficialDatabaseOnly false CrossFilesystems true # Automatically created by the clamav-freshclam postinst # Comments will get lost when you reconfigure the clamav-freshclam package DatabaseOwner clamav UpdateLogFile /var/log/clamav/freshclam.log LogVerbose false LogSyslog false LogFacility LOG_LOCAL6 LogFileMaxSize 0 LogTime true Foreground false Debug false MaxAttempts 5 DatabaseDirectory /var/lib/clamav/ DNSDatabaseInfo current.cvd.clamav.net AllowSupplementaryGroups false PidFile /var/run/clamav/freshclam.pid ConnectTimeout 30 ReceiveTimeout 30 ScriptedUpdates yes CompressLocalDatabase no Bytecode true NotifyClamd /etc/clamav/clamd.conf DatabaseMirror db.ca.clamav.net DatabaseMirror database.clamav.net
Bug#471865: Hello, is anything happening with this bug?
I've been holding off upgrades to DNS here for a week and a half on this bug, since I don't know if upgrading is going to cause me problems. Is anything happening on this? Gord -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375677: Bug marked as not found in version 1.9.33-0.1.0
On Tuesday 04 July 2006 03:00, Florian Weimer wrote: * Gordon Haverland: Bug marked as not found in version 1.9.33-0.1.0. Request was from Filipus Klutiero [EMAIL PROTECTED] to [EMAIL PROTECTED] Full text and rfc822 format available. I am seeing this as well, and I have 1.9.33-0.1 Note that 1.9.33-0.1 is not equal to 1.9.33-0.1.0. Filipus, did you intend to set a pending tag instead? 1.9.33-0.1.0 does net yet exist in the archive. I'm guessing you guys pick the most appropriate message from some small list of available messages. This message I can't remember seeing before, and wasn't sure how to interpret it. I think it would be nice if someone looked at that list of messages and made sure that they are meaningful and easily understood. I just looked again at all packages at debian.org, and there is nothing other than 1.9.33-0.1 (or older) listed in any archive (including experimental); and looking at incoming.debian.org, there are no apt-proxy or python-twisted* packages listed. Gordon Haverland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375677: Bug marked as not found in version 1.9.33-0.1.0
What does this statement mean? Bug marked as not found in version 1.9.33-0.1.0. Request was from Filipus Klutiero [EMAIL PROTECTED] to [EMAIL PROTECTED] Full text and rfc822 format available. I am seeing this as well, and I have 1.9.33-0.1 Does that statement imply that this isn't a bug and will be ignored? Or has this been transferred to some python package (likely python-twisted)? I looked around the python dependencies, and I don't see that anything has been added to their list of bugs. Gordon Haverland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361024: 361024: and lack of feedback
On Wednesday 12 April 2006 12:37, Some have written: There seems to be tons of feedback with that bug report. [ Or similar. ] I must get better at phrasing things then. There is a lot of feedback in the bug report. However, within the bug report there are still many questions which are never answered or commented upon. As far as feedback goes, a couple of people responding to issues in the bug report, did cc me a copy of the email they submitted. Most people responding to issues in the bug report, did not cc me anything. So, I might recieve an email which seemed to be related to what I had asked, didn't answer my questions. Thinking that my part of the questions had been solved and this being something more involved, I would look at the bug report to find that usually no, what I had asked still hadn't been answered, but someone elses related problem with this same bug had been answered or commented upon. For instance, someone had suggested running whatever troublesome program with LD_DEBUG=all in the environment. Fine, I did that with an apt-get upgrade. This produced a 36 MB file. I mentioned how big the file was, and where the error message was in that file. Nobody said anything about this file after that. I still have this file. I gather it is of no use, and that I can delete it. I am not necessarily in a hurry to upgrade to a 2.6 kernel. If there are things I can do here, to help get rid of this bug, I am probably willing to try. No, I have no experience at debugging things like libc. I do have more than 25 years experience at programming, mostly number crunching. But unless someone suggests an action plan, I am not going to try and find/solve this thing on my own. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361024: 361024: and lack of feedback
Occasionally I get an email from someone who is reporting back to many people, but in general I have gotten NO FEEDBACK on this bug report! It apparently wasn't reproducible to the person fielding the bug report, but it is reproducible here. I asked, what can I do to send you info to fix this? I get NOTHING! Someone else reports on setting LD_DEBUG=all and running things I try this, and get a HUGE output file. So, I send in a minimal report on this, and hear NOTHING! A series of patched debs at http://people.debian.org/~doko/tmp/ is suggested. I download and install those. I get an error about cpp dependence, which I report. No comment on this cpp dependence! And, if nothing else, my system is even less usable than before. Apt-proxy won't run (TLS errors), and so I try to bring things back to only using apt to get the various packages files and compare things. I still get tons of errors. AND STILL THERE IS NO RESPONSE TO ANYTHING I'VE SENT IN! Are you looking for me to give up on Debian? Can't I get some feedback as to what is happening? I am not expecting miracles. I would like to help, if I can. But it is just some bloody black hole that I report to! Is the only option to upgrade to a 2.6 kernel? Gord -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360776: Bug#361024: Bug#361221: libstdc++ test packages
On Saturday 08 April 2006 16:34, Aurelien Jarno wrote: On Sat, Apr 08, 2006 at 12:57:58AM +0200, Matthias Klose wrote: please check with the (i386) libstdc++6 test package at http://people.debian.org/~doko/tmp/ I have made some more tests. First the package looks ok, but it does not work because the /usr/lib/tls directory is used inconditionnaly. This is because ld.so actually does not actually check for TLS hwcap (which does not really exists), but only check the OS ABI. All libc6 libraries in this directory are tagged OS ABI: Linux 2.6.0. I will try to have a look for a patch to add this note to libstdc6++ This doesn't work here. libstdc++6_4.1.0-2_i386.deb gcc-4.1-base_4.1.0-2_i386.deb gcc-4.1-base_4.1.0-2_i386.deb libgcc1_4.1.0-2_i386.deb I dowloaded the above debs, and on install I get errors on cpp-4.1_4.1.0-2 being missing. If I try to restart my apt-proxy daemon (twistd), it fails on the TLS problem. With no apt-proxy running, I'm going to be downloading packages manually for upgrade. Gord -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361024: libstdc++6: cannot handle TLS data
Please find attached a patch to fix the problem. It disables TLS on all architectures but amd64, kfreebsd-i386 and kfreebsd-amd64. It may possible to build version of libstdc++6 and put the TLS version in /usr/lib/tls, but I think it could be done in a further step. I've been dragging my feet on changing to a 2.6 kernel, and actually got around to compiling one just a week ago. Then had to leave town for a while. Now I notice the source tree has some updates, so I need to recompile another kernel. But, if I install this patch for the currently running 2.4 kernel, I need to put back the old libstdc++6 package when I get around to installing the 2.6 kernel? Gord -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361024: Simple test case [Was: libstdc++.so.6: cannot handle TLS data]
On Thursday 06 April 2006 11:04, Matthias Klose wrote: Sheplyakov Alexei writes: On Wed, 05 Apr 2006 18:41:05 -0600, Gordon Haverland wrote: Traceback (most recent call last): File /usr/bin/apt-listchanges, line 30, in ? import apt_pkg ImportError: libstdc++.so.6: cannot handle TLS data I've seen many similar errors on my system too (I've got a bunch of home-brew Guile[1] modules written in C++). Such an error appears whenever a thread created by C code tries to dlopen(3) C++ shared library. I've managed to create (hopefully) simple test case (based on C++ dlopen mini-HOWTO), see the attached tarball (unpack and run `make'). I did not reported this before since I thought that's /me doing something wrong... thanks for the testcase, however I'm unable to reproduce the failure with a recent unstable archive, nor do I see the apt-listchanges failures. I know the last 3 apt-get upgrade's all did this, I am not sure how far back it happens. Is there something I can do on this end to get you more data? It seems consistent on this box (for now). Gord -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361024: Simple test case [Was: libstdc++.so.6: cannot handle TLS data]
I did another apt-get upgrade today, and as expected, this bug was present again (at least 4 in a row now). From suggestions in this thread, I ran it under LD_DEBUG=all, and captured stdout/stderr. This captured output is 481713 lines long, with the TLS error on line 26074 of that file. I really don't think submitting a 36 MB file is the thing to do, so I leave it to you guys as to whether this is of any use. Gord
Bug#308218: And 308219 and 308261
I also have tripped over this bug. It doesn't really effect anything here, but I noticed my most recent upgrade didn't go to completion. I am curious as to how this proposed fix of yours is going to work. All 3 reports of this bug in the bug system, are from people running i386 architecture (i686) on 2.6 kernels. Your latest version of autogen which is supposed to fix this, looks like it is powerpc only (*_5.7-2_powerpc.deb) and the description at packages.debian.org for libopts25 only lists packages for alpha and hppa, not even i386 (or the powerpc packages you suggest fix a i386 problem). You have uploaded a bunch of other packages as well, including i386 ones? Gord -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308218: And 308219 and 308261
On Monday 09 May 2005 07:32, Matt Kraai wrote: On Mon, May 09, 2005 at 06:16:45AM -0600, Gordon Haverland wrote: I also have tripped over this bug. It doesn't really effect anything here, but I noticed my most recent upgrade didn't go to completion. I am curious as to how this proposed fix of yours is going to work. All 3 reports of this bug in the bug system, are from people running i386 architecture (i686) on 2.6 kernels. Your latest version of autogen which is supposed to fix this, looks like it is powerpc only (*_5.7-2_powerpc.deb) and the description at packages.debian.org for libopts25 only lists packages for alpha and hppa, not even i386 (or the powerpc packages you suggest fix a i386 problem). You have uploaded a bunch of other packages as well, including i386 ones? No. I uploaded the PowerPC package, since the system that I use for development is an iBook2. The build daemons for the other architectures (including i386) will build packages for their respective architectures. For more information, see http://buildd.debian.org/ I still don't see how your uploading libopts25 for powerpc fixes a bug on i386. packages.debian.org is probably out of date, and I guess will soon have powerpc on its list of architectures that libopts25 is available for due to your upload. buildd.debian.org as near as I can tell, doesn't have libopts25 for unstable (or libopts or libopts9 or libopts*), or for any architecture. So for the 3 people who submitted bug reports on libopts25, and myself, there is currently nothing by the way of a fix for the installation problem in the works? Gord -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
