Bug#829310: systemd unit file breaks imapd
On 08/30/2016 06:35 PM, Mark - Syminet wrote: The systemd unit file, or something in this patch is causing imapproxy to randomly timeout and die, see following thread at upstream mailing list: https://sourceforge.net/p/squirrelmail/mailman/squirrelmail-imapproxy/thread/bf5ac0ec-e309-ee5c-70e1-1b2f187249e0%40txbweb.de/#msg35255782 for them, the solution is to change the following line in the unit file: Type=fork to: Type=simple I’ll also file a separate bug. Ok. Thank you very much. Gotta fold this into the pending set of fixes (due soon) after some testing. I can produce tentatively fixed packages and send them your way if you'd like to give it a try. Thanks, / J.L.
Bug#817550: Any news?
On 06/21/2016 12:34 PM, Michael Meskes wrote: Any news on this? I don't like seeing my packages removed from testing because of this. Obviously I'd be willing to sponsor (or NMU) if needed. Either is fine with me, to be honest. The changes needed are fairly minimal for libsieve, AFAIK. (thank you for the guidelines, Niels) Will try to follow up later today.
Bug#806946: Acknowledgement (bindgraph doesn't show any graphic)
On 12/03/2015 12:15 PM, Stéphane CHIRON wrote: I have found a strange directory related to bind graph : /var/cache/bindgraph/,cgi-bin,bindgraph.cgi Huh? Are those COMMAS ? Doesn't look like made by the package
Bug#597208: bindgraph: fails to install
Luca Falavigna wrote: Hi José, feel free to prepare the upload and ping me for sponsoring. It could be worth asking advance permission to Release Team, though. Since it is marked as RC and doesn't introduce any code changes, it shouldn't be necessary. I will send the diff to -release as soon as I have it (I intend to have a new version ready tonight, as soon as I get home) Assuming this goes well, would you mind sponsoring some other uploads, so that I can fix the RC bugs I have left? Thanks in advance, J.L. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597208: bindgraph: fails to install
Holger Levsen wrote: Package: bindgraph Version: 0.2a-5 Severity: serious User: debian...@lists.debian.org Usertags: piuparts piuparts.d.o Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. There has been a recent NMU (2010-08-18) covering this. 0.2a-5.1 Anyway, I would like to upload a better version. Anyone mind to sposor the upload ? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591601: bindgraph: diff for NMU version 0.2a-5.1
Georges Khaznadar wrote: tags 591601 + patch tags 591601 + pending thanks Dear maintainer, I've prepared an NMU for bindgraph (versioned as 0.2a-5.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Please sponsor an upload proper instead so that we can have a fixed version in Squeeze. Thank you for your interest in bindgraph. Regards, Jose Luis Tallon Bindgraph maintainer -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563786: fails to install due to incorrect dependencies in init.d LSB header
Petter Reinholdtsen wrote: Hi. Any progress with this upload/sponsoring? Would be nice to have this issue fixed in testing soon. :) Indeed. The upload is ready, but found no sponsors yet. Any upload-capable one reading this is welcome to sponsor. J.L. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505589: Availability of libsmbios in Debian ?
Olivier Berger wrote: On Fri, Dec 11, 2009 at 03:42:26PM +0100, José Luis Tallón wrote: usertags 505589 awaiting-sponsor A new version is being tested right now. Anyone cares to sponsor it ? It seems that libsmbios won't be in the next release... is it just still waiting for a sponsor ? Essentially, yes Have you tried and ask on mentors list ? Many times (for other packages), with no success so far. My packages with new revisions which are ready for upload are tagged with the awaiting-sponsor usertag. Thanks in advance. Thank you for your interest. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563786: bindgraph fails to install due to incorrect dependencies in init.d LSB header
Evgeni Golov wrote: Hi Jose, On Sun, Jan 24, 2010 at 12:01:44AM +0100, José Luis Tallón wrote: Evgeni Golov wrote: Hi, There is a fixed package awaiting sponsoring. Sent to -mentors more than a week ago, with no responses so far. Well, then it comes now: First of all -- thanks :) But, I think you got it slightly wrong with the format 3.0 (quilt) stuff. I for myself never touched this yet, but from reading, 3.0 (quilt) should work as follows: - you DON'T have to build-depend on quilt - you DON'T have to include /usr/share/quilt/quilt.make - it JUST works (tm) :) ... unless you are backporting to lenny, where dpkg-source is not that advanced. In fact, since recent dpkg-source interact so cleanly with quilt, the calls to quilt in debian/rules should effectively become no-ops. That is: it is in fact NOT needed to add quilt-related calls to files in the 3.0 format ... ... UNLESS you want to be kind to porters. On the other hand, I see two patches in your debian/patches, which were never applied and are not now either... It seems to be patched in your orig.tar.gz already. The problem being that upstream author, Marco D'Itri, does not agree with bindgraph being packaged for Debian. Some time ago, I had to repackage bindgraph source (that's where the 'a' suffix comes from) to include the changes with respect to the original ---which is unmodified since AFAIK --- The patches are there to document the deviations from pure upstream. ... which might mean a need for a README.Source, I agree Only options are, hence: - leave them as documentation of deviations from upstream (less bad) - revert to upstream source 0.2 + patches --- absurdly big debdiff for a trivial change, plus versioning paradox - publish a new completely unofficial 0.3 version, including all changes and/or upstream + patches applied at build-time but I might be missing some other option. Any suggestions are welcome, of course I'd be glad to sponsor your package if you do a little bit more cleanup ;) If you sponsored couriergraph too, I'd be more than glad, too ;) J.L. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563786: bindgraph fails to install due to incorrect dependencies in init.d LSB header
Julien Cristau wrote: On Sun, Jan 24, 2010 at 20:45:48 +0100, Evgeni Golov wrote: Mh, I thought Lenny's dpkg does support format 3.0 (quilt)? lenny's dpkg does (sort of, there were some bugs that should be fixed with the next point release afaik), but dak won't accept 3.0 packages for lenny, and the bpo archive doesn't accept 3.0 packages either. That was a misunderstanding on my part, then. Thanks for pointing it out, Julien. This might change my perception w.r.t. source format 3... however, Squeeze is so close to release that this point will be moot very soon now and the advantages of format 3 are many, indeed. Cheers, J.L. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563786: bindgraph fails to install due to incorrect dependencies in init.d LSB header
Evgeni Golov wrote: Hi, [snip] The problem being that upstream author, Marco D'Itri, does not agree with bindgraph being packaged for Debian. Some time ago, I had to repackage bindgraph source (that's where the 'a' suffix comes from) to include the changes with respect to the original ---which is unmodified since AFAIK --- The patches are there to document the deviations from pure upstream. ... which might mean a need for a README.Source, I agree Only options are, hence: - leave them as documentation of deviations from upstream (less bad) - revert to upstream source 0.2 + patches --- absurdly big debdiff for a trivial change, plus versioning paradox - publish a new completely unofficial 0.3 version, including all changes and/or upstream + patches applied at build-time but I might be missing some other option. Any suggestions are welcome, of course Well, I think option 2 isn't that bad when using format 3.0 ;) But on the other hand, you have it working like this now, and one should never change a running system. In general, unless I have a regular sponsor, I tend to minimize debdiff changes to make it easier for a sponsor to review the changes. I can of course prepare a version where we have the original 0.2 plus all changes as patches, but that would be quite paradoxical w.r.t. naming. However, 0.2+a might be a sane name, and indeed would sort later than 0.2a. I can prepare a version from that, and resubmit including the diff against vanilla 0.2. (in this case, source format 3 more than justifies itself :-D ) Thats also why I don't understand why you convert to 3.0 now, you don't have any patches to apply besides debian/, and here you do not gain anything over the old version. Thus I'd stay with 1.0, fix the stuff you want to fix, and upload that one then. But it's your package, so you are free to decide to go to 3.0. It was a huge gain for couriergraph, and I figured it would be best for bindgraph. In any case, I'm trying to convert all packages where it doesn't give problems to the new format: it is indeed the best way to document deviations from upstream, plus the added bonus of not having to repackage upstream bzipped tarballs. If you sponsored couriergraph too, I'd be more than glad, too ;) Not today, and most probably not tomorrow, but I can have a look on that if you don't find anyone in the meantime ;) Thanks in advance. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563786: bindgraph fails to install due to incorrect dependencies in init.d LSB header
Evgeni Golov wrote: Hi, There is a fixed package awaiting sponsoring. Sent to -mentors more than a week ago, with no responses so far. It also includes some needed enhancements / updates. I have looked at the issue, and it seems that the bind9 dependency is useless. We can start before bind9 (or with no bind9 at all on the host, and a remote bind9 with fetched logs, even if that sounds like a strange configuration) and nothing should prevent us from working correctly. Indeed that would be a less than minimally common situation, but supported. Jose, can you say anything about the dependency? Why was it added? In order to avoid starting without a bind9 working. I'd drop it from the LSB header... It has been downgraded, AFAICR (The other solution would be to promote bind9 from recommends to depends, which sounds crude to me). bind9 is of course not really a dependency. Regards, J.L. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566022: mysql-server: mysqld fails to start
stor...@club-internet.fr wrote: Package: mysql-server Version: 5.1.41 Severity: grave Justification: renders package unusable Please provide the output from the command below: $ objdump -T /usr/sbin/mysqld | grep sort_order_hebrew It might as well be some kind of problem during upgrade ... I assume this happened after upgrading and not on a new install, right? Else, it seems the build somehow got corrupted or maybe gcc is producing a damaged executable [cfr #554207] (I assume Norbert tested the build before uploading ) Since this release fixes a FTBFS with gcc-4.4, the symbol table might have got mangled ... the output from nm will confirm this. Regards, J.L. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505589: Processed: severity of 505589 is serious
tags 505589 + pending usertags 505589 awaiting-sponsor thanks Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: severity 505589 serious Bug #505589 [libsmbios] FTBFS with GCC 4.4: missing #include Severity set to 'serious' from 'normal' A new version is being tested right now. Anyone cares to sponsor it ? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554582: libsmbios_2.0.3.dfsg-1(ia64/unstable): FTBFS: matching constraint does not allow a register
lam...@debian.org wrote: Package: libsmbios Version: 2.0.3.dfsg-1 Severity: serious There was an error while trying to autobuild your package: A new version of libsmbios is in preparation. J.L. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536635: libconfig8: Various library packaging errors
Hi, Cyril Thank you for your report. Please see below. Cyril Brulebois wrote: Package: libconfig8 Version: 1.3.2-1 Severity: serious Justification: MEH. Various issues: - libconfig8 conflicts against libconfig6. Coinstallability is the whole point of changing package name… Well... this version does break ABI (and makes some changes at the API level, IIRC) ... and the conflicts is there to try and have dpkg replace the older package. You are right about co-installability being desirable, though. - the .la doesn't belong to this package. Rather to the corresponding -dev. This way, the conflicts can go away, too. Yup, you're right. I overlooked it. - why having a versioned -dev is you only support one version at a time? Best Current Practice That doesn't help your reverse dependencies that b-depend on libconfig6-dev (which you stop providing, so they need a sourceful upload). ... but you are right in that it is inconsistent with other aspects of the package - the same holds for the ++ parts. Of course Various random clues: - get rid of the .la, or put it in the -dev package. Make your libraries co-installable! Any recommendation here? Aren't we supposed to be all migrating to pkg-config anyway? - get rid of the version in the -dev package names. Eventually think of an upgrade path so that your reverse dependencies don't need a sourceful upload right now, but can be adjusted according to their maintainers' own schedule. -dev should depend on the latest soname, even though it is very nice that one can actually have two versions installable at the same time indeed. Filing against the “main” (?) library, but while writing the report, I realized that the source package might have been a better choice. No prob. Mind sponsoring the new version? Regards, J.L. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514103: picwiz: no bother to upload, removal or port to KDE 4
reassign #514103 ftp.debian.org retitle #514103 RM: picwiz -- RoM: does not work with KDE4 severity #514103 wishlist thanks Ana Guerrero wrote: Hi, Current picwiz is useless in KDE 4. The best here is ask for removal, so I will ask for removal in one week if the maintainer does not do it before. In case of being ported to KDE 4 in the future, it can be repackaged and reintroduced in the archive. It won't, surely. It hasn't seen any updates from upstream in years. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514103: picwiz: Build-depends on kdebase-dev but does not use anything from it
Sune Vuorela wrote: Package: picwiz Version: 0.3.1-2+b1 Severity: normal Please remove the build-depend on kdebase-dev, you don't use it. (This bug will become seriosu post lenny where kdebase-dev will be a kde4 thingie) FIXED. Please find the updated version at: http://devel.adv-solutions.net/debian/pool/main/kde/picwiz/picwiz_0.3.1-3.dsc Moreover, I also fixed all other outstanding bugs and lintian warnings. Or consider if this package is useful in a environment without kde3 and thus ask for removal when lenny is out. As soon as KDE4 is in unstable and fully working (updating to it from experimental doesn't fully work yet), we will have a chance to check it. Meanwhile, we could have this updated version in Debian 5.0.1 :-) Mvh / J.L. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510432: imapproxy
Niko Tyni wrote: On Tue, Jan 20, 2009 at 11:02:42AM +0200, Niko Tyni wrote: The attached new patch seems to work for me, but please verify. It uses ucf for config file handling, which simplifies things IMO. I'm attaching an improved version that handles listen_port better. Niko, I applied your patch and got a version which produces a corrupt config file... so that imapproxy won't start. I have reviewed the patch a couple times already, and it looks good however. I am scrambling right now to produce a fully working version so that it can be included. Thank you for your support. It is much appreciated. J.L. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510432: imapproxy
Niko Tyni wrote: On Wed, Feb 04, 2009 at 12:22:46AM +0100, José Luis Tallón wrote: I still don't see this new version anywhere. Are you aware that the release is scheduled eight days from now? FIXED. The enclosed patch (also available at my repo) is the latest version. It does work in my testing. i.e. it does not overwrite any changed configuration settings. Please, either Niko or Christian, upload this version ASAP so that we can have it included in Lenny. Thanks, J.L. up-imapproxy_1.2.6-5.diff.gz Description: GNU Zip compressed data
Bug#510432: imapproxy
Niko Tyni wrote: On Sat, Feb 07, 2009 at 05:32:52PM +0200, Niko Tyni wrote: Your change to the postrm script makes it fail at purge if ucf is not present any more. You shouldn't use '' with 'set -e' here: Uh, I'm wrong here. Sorry about that. It always seemed counterintuitive me that 'false true' will not exit with 'set -e'. :-) The debian/test thing is just cosmetic, so I'll look at uploading your version tonight unless someone else beats me to it. just remove it, of course :-) By the way, I have targetted it at unstable, since it doesn't look like we will actually have any testing-updates in this release cycle, and the fix is actually very relevant for unstable too. Thanks again -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510432: imapproxy
Niko Tyni wrote: Do you mean 1.2.6-5 at http://devel.adv-solutions.net/debian/pool/main/mail/imapproxy/ dated 19-Jan-2009? As I noted before, it still overwrites user configuration, particularly listen_port, without warning, so it's not an acceptable fix for this bug. Of course not. I'm testing a new version. Should be ready tonight. Sorry for the confusion. Regards, J.L. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510432: imapproxy
Niko Tyni wrote: On Tue, Jan 20, 2009 at 11:02:42AM +0200, Niko Tyni wrote: The attached new patch seems to work for me, but please verify. It uses ucf for config file handling, which simplifies things IMO. I'm attaching an improved version that handles listen_port better. I do intend to NMU this when I've had some sleep and can find the time for final tests. If somebody wants to take over, be my guest. I'd rather you uploaded my new version, based on the comments I got. Real Life Keeps Interferring, as usual :-( I'm a bit surprised the package is still a candidate for lenny at this point. that's an artifact of the freeze, I guess. But we should try to release with imapproxy ... a proper version, I mean Thanks, J.L. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510432: imapproxy
Christian Hammers wrote: Hello Any progress with this Release Critical bug? Ready to be uploaded, at: http://devel.adv-solutions.net/debian/pool/main/mail/imapproxy/up-imapproxy_1.2.6-5.dsc Thank you to Niko Tyni and other contributors. Thanks to Christian for the other to upload. Regards, J.L. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510432: imapproxy
Matthew Johnson wrote: We are BSPing in Cambridge this weekend, if you need this uploaded, let me know Thanks. I think I can have the package fixed (and tested!) tonight. Will send the package's URL to the bug's address. Have fun, and kill many bugs :-) Cheers, J.L. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510432: upgrade from etch to lenny overwrites existing /etc/imapproxy.conf file with no warning
This is release-critical (policy 10.7.3), raising the severity. Jose, the config script needs to read in the configuration file and parse debconf defaults from there. The debconf database must not be used as a registry. Patches welcome. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503713: Investigating Lenny release blocker bug: #503713
José Luis Tallón wrote: Christian Perrier wrote: Quoting Sebastiaan Couwenberg ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tags 503713 patch thanks José Luis Tallón wrote: I look forward to your suggestion and/or patch. Time did not allow me to finish this yesterday, but I managed to finish up testing the patch today. José Luis, any plans to prepare an upload? I'd be happy to sponsor it if needed as fixing two RC bugs during this week-end would continue my one RC bug per week-end series... http://devel.adv-solutions.net/debian/pool/main/admin/bindgraph/bindgraph_0.2a-4.dsc Includes fixes for the config file overwriting, dutch localization update, permissions on query log. Thanks, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503713: Investigating Lenny release blocker bug: #503713
Sebastiaan Couwenberg wrote: Christian Perrier wrote: Quoting José Luis Tallón ([EMAIL PROTECTED]): José Luis, any plans to prepare an upload? I'd be happy to sponsor it if needed as fixing two RC bugs during this week-end would continue my one RC bug per week-end series... Indeed. If real life allows me, I think I can have the patch ready and tested sometime tonight. Any news? People, I have been much overloaded since Friday (sorry 'bout that, Christian). There are some other issues which I would like to cover with this upload, so I'd rather prepare it myself. Thank you for your support J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503713: Investigating Lenny release blocker bug: #503713
Christian Perrier wrote: Quoting Sebastiaan Couwenberg ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tags 503713 patch thanks José Luis Tallón wrote: I look forward to your suggestion and/or patch. Time did not allow me to finish this yesterday, but I managed to finish up testing the patch today. José Luis, any plans to prepare an upload? I'd be happy to sponsor it if needed as fixing two RC bugs during this week-end would continue my one RC bug per week-end series... Indeed. If real life allows me, I think I can have the patch ready and tested sometime tonight. Thank you for your support, Christian. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503713: Investigating Lenny release blocker bug: #503713
Sebastiaan Couwenberg wrote: I've been looking in to this bug because I use this package myself too, and because it is among the RC bugs blocking lenny. As I wrote in my message to control@ [1], I merged this issue with #481103 because they report the same issue only for a different version of the package. Ok. Thank you for your efforts. I look forward to your suggestion and/or patch. Regards, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494316: Updated package
Michael Casadevall wrote: I've created a NMU to handle updating this package should the original maintainer need help with the update. The changelog is as follows: [snip] Thanks, the updated package was sent for upload about 10 days ago. Still waiting (I already poked the interested parties -- yesterday, to be precise) Notes: There are some other outstanding lintian issues with this package that were not addressed, but they are at best minor, and are not within the scope of the NMU. If the maintainer of this package however would like to see fixes for them in addition to everything else, then I'd be glad to help. Thanks many. Please feel free to send patches The watch file is currently broken (goes with above). I hate those, and they tend to break e.g.: imapproxy's watch file, while correct, never works since upstream likes to release X.YrcZ which uscan sorts as newer than X.Y. I have no intention to upload (nor ability, since I'm still a NM) welcome to the club :-) this package without either approval from the release team, or approval from the maintainer. I created this updated package as a convince to the former should it be necessary. Thanks again. Luk Claes requested an update on behalf of the Release Team, since libsmbios 0.x can't work with Linux = 2.6.26. Due to the rdepend you mention, it needs to go in. Thank you for your interest and support. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494316: libsmbios 2.0
Hi Luk Claes wrote: retitle 494316 libsmbios: version 2.0 needed for 2.6.26 kernel severity 494316 serious thanks Ok, title and severity of bug changed to match this. Please ask for a freeze exception once a new version is uploaded. Cheers Sorry for the delay -- I have been away. Should have the new version ready sometime today. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400066: Processed: found 400066 in lcdproc/0.5.2-1
Gerfried Fuchs wrote: [big snip] If you would sponsor it, we can certainly upload an architecture: any version of lcdproc --- please remember that I have no access to any porting machine and am thus unable to test compilation on other arches. That's what the buildd network is there for. If there is any other way than an upload to have a package be built on the buildds, please tell me. I honestly do not know of other way available to non-DDs. It just took me some three weeks to have some packages uploaded, since Amaya was too busy, and my other sponsors are basically MIA. Did you ask on the -mentors mailing list? On the -mentors IRC channel? On several occasions, I did. No answers for most packages (Thijs Kinkhorst did answer promptly, because he cared about the packages in question) It shouldn't be hard to really find someone willing to upload a package for a RC bug, and that includes myself. I'm willing to upload the package widening its Arch list to any. I'm in the middle of a short vacation. I will try and contact you on tuesday night to arrange for this to be done. Thanks in advance. I can prepare the updated package and have it ready in some hours, if you agree. Did you do that at some point in the past? There is no status for that in the bugreport, so I'm unsure. I think I did, but can't remember, and have no possibility to check it from now. Thank you for your interest. Have a nice weekend. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491795: libsmbios: Package does not use upstream's config.{sub,guess} or ltmain.sh
Package: libsmbios
severity #491795 important
tags #491795 + moreinfo
usertags #491795 + ubuntu
quit
Hi, Mario
Mario Limonciello wrote:
Package: libsmbios
Version: 0.13.13
Severity: serious
Justification: no longer builds from source
*** Please type your report below this line ***
There is no reason to use the config.{sub,guess} or ltmain.sh in the
libtool package. They are intentionally shipped with the upstream
tarball.
Please point me to where in the source it is stated that you depend on a
certain libtool version to build.
It is common practice to use Debian-supplied's config.{sub,guess} in the
package;
Moreover, I had to relibtoolize the package in order to fix a previous FTBFS
When upgrading to libtool 2.2.4, the current build system in
debian/rules that *removes* the upstream ltmain.sh causes breakage.
Then, the bug lies with upstream source, and not with packaging: if
upgrading to a newer libtool makes it FTBFS, then there is some
undocumented version dependency on libtool -- a newer version should
only fix things (unless this newer libtool version is reportedly broken)
-- System Information:
Debian Release: lenny/sid
APT prefers intrepid-updates
APT policy: (500, 'intrepid-updates'), (500, 'intrepid-security'),
(500, 'intrepid-proposed'), (500, 'intrepid-backports'), (500, 'intrepid')
Architecture: i386 (i686)
BTW, I just built from source with latest Sid as of yesterday.
In Debian systems, libsmbios builds JUST FINE.
If it fails in a pre-alpha version of ubuntu, it is *not* RC for
Debian... specially not during a freeze.
Kernel: Linux 2.6.24-19-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Thank you for the report, anyway. I'll take a look a it after the freeze.
Regards,
J.L.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488467: SEGFAULT in libtrash when using ls -l
Hi, Mike What you report here is indeed *grave* I am about to package version 3.2 per another user's request (otherwise, I would have requested this package's removal from the Archive in light of this) Mike Hommey wrote: severity 488467 grave retitle 488467 libtrash is dangerously broken on amd64 tag 488467 patch thanks On Sun, Jun 29, 2008 at 09:25:13AM +0200, Mike Hommey wrote: On Sun, Jun 29, 2008 at 09:10:00AM +0200, Mike Hommey wrote: Here is the culprit: real_fopen = dlvsym(RTLD_NEXT, fopen, GLIBC_2.1); There is no such version of the symbol: $ objdump -T /lib/libc.so.6 | grep ' fopen$' 00064840 gDF .text 000a GLIBC_2.2.5 fopen It's even worse than that. Anything using other f* functions (freopen, fopen64, etc.) will get a wrong return value because of bad declarations for the function pointers. This is very serious The attached patch should fix both issues. Looks very nice, thanks. It doesn't fix more of the brain damage in the code source itself (dlsym()ing at every call is stupid, indeed having only one function to do the whole thing is bad design, completely agreed and macros that are used only once don't help making the code readable) Although this patch makes things worse, I strongly advise to audit the code for other similar jokes. (Or, even better, a complete rewrite) I seem to remember that version 3 was mostly a rewrite ... we'll be able to tell very soon. Would you mind sponsoring an upload of version 3.2 ? I think I can have it ready pretty soon. I stopped using libtrash quite a while ago, and have only kept for some users' sake (I know what it feels when one maintainer decides to drop that package you have come to depend on). I was considering requesting its removal seeing that nobody seemed to use it anymore. Recently, an user has contacted me requesting a newer version and reporting some very active users, so I decided to package the latest version and then you came with this, definitively making it necessary. I will send you an e-mail as soon as I have the new package ready. Thank you for your interest and work, Mike. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487761: postinst overwrites /etc/imapproxy.conf with empty file
Sven Hartge wrote: Package: imapproxy Version: 1.2.6-3 Severity: critical The postinst overwrote my working /etc/imapproxy.conf with an empty file and thus causes the daemon to fail to start and consequentially all applications using the proxy. Which PERL version are you using? (i.e. what does perl -version say) Thanks, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487761: Re postinst overwrites /etc/imapproxy.conf with empty file
Sven Hartge wrote: Um 03:04 Uhr am 24.06.08 schrieb José Luis Tallón I have been unable to reproduce this bug in my preliminar testing. Would you mind giving me some more details ? Unfortunately, it seems that my test environment was flawed (stale configuration file left from testing) You are right w.r.t this bug: there was a typo in the postinst script. Any additional information you can provide to nail this bug down will be wellcome. Now I tried to install imapproxy on a server which never ever before had this package installed, so no leftover files or debconf entries are to be found. But: Yup. I have produced a fixed version. Please test it so that we can double-check before having this uploaded. The new version is available at: http://devel.adv-solutions.net/debian/pool/main/mail/imapproxy/imapproxy_1.2.6-4_i386.deb should you need to build it, the relevant files are available at that same folder. Sorry for the inconvenience. Looking forward to getting your feedback on the resolution of this bug. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487761: Re postinst overwrites /etc/imapproxy.conf with empty file
tags #487761 + moreinfo unreproducible thanks Hi, Sven I have been unable to reproduce this bug in my preliminar testing. Would you mind giving me some more details ? Does 1.2.6-2 exhibit this behaviour ? The -3 upgrade has been done to fix an annoying bug (non-grave, just cosmetic) with PERL 5.10. Systems with PERL 5.8 work perfectly with -2 AFAIK. Any additional information you can provide to nail this bug down will be wellcome. Thanks, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411070: libsieve2-1_ still tries to overwrite file owned by libmailutils1
Ralf Treinen wrote: Sorry but this isn't resolved yet: Unpacking libsieve2-1 (from .../libsieve2-1_2.2.6-1_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/libsieve2-1_2.2.6-1_amd64.deb (-- unpack): trying to overwrite `/usr/lib/libsieve.so.1', which is also in package libmailutils1 Of course :-( I don't know why, but the Conflicts: with libmailutils1 apparently slipped by. libsieve2 has to conflict with libmailutils1 until they split their library into another package. This is quite odd, since libmailutils1's libsieve.so implements a completely different API and ABI than what my package provides. Yet my upstream produces libsieve.so as opposed to libsieve2.so. Please note that I already call the binary package accordingly. I will re-add the conflicts and re-upload ASAP. Thanks, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400066: closed by Jose Luis Tallon [EMAIL PROTECTED] (Bug#400066: fixed in lcdproc 0.5.2-1)
Nicolas François wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 09 Mar 2008 00:25:50 +0100 Source: lcdproc Binary: lcdproc Architecture: source amd64 Version: 0.5.2-1 Distribution: unstable Urgency: medium Maintainer: Jose Luis Tallon [EMAIL PROTECTED] Changed-By: Jose Luis Tallon [EMAIL PROTECTED] Description: lcdproc- LCD display driver daemon and clients Closes: 400066 Changes: lcdproc (0.5.2-1) unstable; urgency=medium . * New upstream version . * Compilation issues - restrict building to just i386, amd64 (Closes: #400066) I don't think this fix is correct. You already did it before, and the bug was reopen. (just read the back log of the bug) This particular bug is indeed fixed. However, I do agree that there is another problem. A patch was also proposed and should be part of this new upstream release to at least support PPC (and probably all the other architectures without parallel port). I can not test it, since I only have i386 and amd64 machines (my macbook is recent enough to not be ppc) As you insist, and as I'm not a user on non i386 architectures, I won't play ping pong with you. If you report that this version does work with non-PC architectures, I will re-enable building for all other architectures. Unfortunately, I cannot risk an RC bug due to FTBFS; I'd rather support less architectures than that. Again, if you verify that this version does indeed work for you, I will upload another version. I apologize for the inconvenience, but I can't simply risk that bug. Please tell me if I can help you testing this. You should also contact the ftp-masters to request the removal of the binaries on the architectures that are no more supported Yes. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400066: Processed: found 400066 in lcdproc/0.5.2-1
Marc 'HE' Brockschmidt wrote: José Luis Tallón [EMAIL PROTECTED] writes: lcdproc 0.5.2-1 states Architecture: i386 amd64 in its control file. Yes, that's a bug. I don't understand why this package is marked as FTBFS on powerpc, when autobuilding for that arch is not supposed to be attempted. Could you please educate me on this? I would like to resolve this definitively, but I don't have the means to test in on other arches. Restricting a package to some architectures because you are neither able nor willing to fix the problem on other archs is not a fix for this bug. It's a workaround, nothing more. Indeed it is a workaround. However, I think having 0.5.2-1 in the archive (even though restricted to two arches) is better than having 0.5.1 which does FTBFS. The alternative would be (although we are probably too close to release to try it) to try and build it for all arches and await confirmation from users that it does work (or does not). And while you are setting an Architecture header restricted to the architectures *you* consider important, both users and the release team might have a different opionion. No, not at all. It is not that i386 and amd64 are important for me (they are not more than, say, alpha or mipsel). It happens that I only have confirmation of lcdproc working properly on these right now (for the current version). Also, setting the architecture header is not enough, someone would also need to remove the old binaries from unstable. Yes. I just agreed to this a couple hours ago at #400066. However, I am open to any other solution. If you would sponsor it, we can certainly upload an architecture: any version of lcdproc --- please remember that I have no access to any porting machine and am thus unable to test compilation on other arches. It just took me some three weeks to have some packages uploaded, since Amaya was too busy, and my other sponsors are basically MIA. I can prepare the updated package and have it ready in some hours, if you agree. While at it, I would check the source to ensure there are no obvious reasons to have it FTBFS on other arches. Regards, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474869: kchmviewer: diff for NMU version 3.1-1.1
Luk Claes wrote: José Luis Tallón wrote: The attached file is the diff for my kchmviewer 3.1-1.1 NMU. The associated changelog entry is: kchmviewer (3.1-1.1) unstable; urgency=medium * Non-maintainer upload. * Bump Standards-Version to 3.7.3. * Correct typographical error in package description (Gnome - GNOME) * Fix FTBFS with GCC 4.3 (Closes: #474869) * Correct debian/watch file to report upstream version correctly (Closes: #449696) Well, thanks, you just rendered my Maintainer Upload useless. It has been ready, and sent to an sponsor, for over two weeks now. It would have been better to mention this in the bug report instead of just tagging it pending... I know we are already at 0-day NMU, but this was impolite at the very least. I don't think that helping by doing an NMU is impolite, though this might just be a misunderstanding of your use of the pending tag... Thanks, Luk. I *do* appreciate NMUs (I have just thanked Christian Perrier for his), but even when not required I creatinly prefer to be notified and be able to answer. Unfortunately, it usually takes me a lot to find new sponsors (and my usual sponsors are all overloaded). Hence, I do not get that many opportunities to do it right. I have been yelling at -mentors for some sponsored uploads for about two months, and almost nobody responded --- I did get up-imapproxy uploaded, however. Cheers, J.L.
Bug#474869: kchmviewer: diff for NMU version 3.1-1.1
Chris Lamb wrote: Hi, The attached file is the diff for my kchmviewer 3.1-1.1 NMU. The associated changelog entry is: kchmviewer (3.1-1.1) unstable; urgency=medium * Non-maintainer upload. * Bump Standards-Version to 3.7.3. * Correct typographical error in package description (Gnome - GNOME) * Fix FTBFS with GCC 4.3 (Closes: #474869) * Correct debian/watch file to report upstream version correctly (Closes: #449696) Well, thanks, you just rendered my Maintainer Upload useless. It has been ready, and sent to an sponsor, for over two weeks now. I know we are already at 0-day NMU, but this was impolite at the very least. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474869: kchmviewer: FTBFS: libchmfileimpl.h:33: error: expected `)' before 't'
tags 474869 + pending thanks Chris Lamb wrote: tags 474869 + patch thanks Thank you, Chris :-) J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432404: bindgraph does not display any graphs
Uwe Storbeck wrote: Same behaviour here, bindgraph stopped displaying any graphs after the upgrade from sarge to etch. Thanks for the patch, it works for me too. I'm awaiting a sponsor for a new package fixing all known bugs for some days allready. Posted the RFS to [EMAIL PROTECTED] about two weeks ago. Thank you for confirming the patch works. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470431: imapproxy: postinst failure (daemon fails to start)
severity #470431 normal tags #470371 + moreinfo thanks Laurent Bonnaud wrote: Package: imapproxy Version: 1.2.6-1 Severity: grave Justification: renders package unusable Hi, here is the problem: # apt-get install imapproxy Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: imapproxy 0 upgraded, 1 newly installed, 0 to remove and 6 not upgraded. Need to get 53.7kB of archives. After this operation, 238kB of additional disk space will be used. Get:1 http://ftp.fr.debian.org sid/main imapproxy 1.2.6-1 [53.7kB] Fetched 53.7kB in 0s (261kB/s) database /var/lib/apt/listchanges.db failed to load. Preconfiguring packages ... Selecting previously deselected package imapproxy. (Reading database ... 1590210 files and directories currently installed.) Unpacking imapproxy (from .../imapproxy_1.2.6-1_i386.deb) ... Setting up imapproxy (1.2.6-1) ... Starting IMAP proxy: invoke-rc.d: initscript imapproxy, action start failed. dpkg: error processing imapproxy (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: imapproxy E: Sub-process /usr/bin/dpkg returned an error code (1) Do you have any IMAP server daemon running? There is actually an error in imapproxy's default config file -- imapproxy tries to bind to and listen to the same address with the config file shipped. This will be fixed by changing the default listen_port to another value for the cases where the user chooses localhost as the server. This issue is complicated to classify, since this behaviour is a result of recent changes in code upstream -- previously, it would start without complaining even if it couldn't bind. This behaviour is probably more sane. Regards, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470245: baghira: FTBFS: Xmd.h:137: error: conflicting declaration 'typedef long int INT32'
Lucas Nussbaum wrote: Package: baghira Version: 0.8-1 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20080308 qa-ftbfs Justification: FTBFS on i386 Hi, During a rebuild of all packages in sid, your package failed to build on i386. Relevant part: if /bin/sh ../libtool --silent --mode=compile --tag=CXX i486-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/kde -I/usr/include/qt3 -I. -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -MT libbaghirastarter_la.all_cpp.lo -MD -MP -MF .deps/libbaghirastarter_la.all_cpp.Tpo -c -o libbaghirastarter_la.all_cpp.lo libbaghirastarter_la.all_cpp.cpp; \ then mv -f .deps/libbaghirastarter_la.all_cpp.Tpo .deps/libbaghirastarter_la.all_cpp.Plo; else rm -f .deps/libbaghirastarter_la.all_cpp.Tpo; exit 1; fi In file included from /usr/include/X11/extensions/XI.h:55, from /usr/include/X11/extensions/XInput.h:56, from /usr/include/X11/extensions/XTest.h:50, from menu.cpp:42, from libbaghirastarter_la.all_cpp.cpp:3: /usr/include/X11/Xmd.h:137: error: conflicting declaration 'typedef long int INT32' /usr/include/qt3/qglobal.h:709: error: 'INT32' has a previous declaration as 'typedef int INT32' It looks like Qt3 broke with the latest X update. What do you suggest? Regards, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441970: kcheckgmail can't login to gmail due to new login procedure
severity #441970 normal quit Rasmus Bøg Hansen wrote: Package: kcheckgmail Version: 0.5.6-1 Severity: grave Justification: renders package unusable When checking mail, kcheckgmail says: An error occurred logging in to Gmail GMail's login procedure has changed, check for new version. For now I just have an idle unusable G-icon in my docking bar. Regards /Rasmus
Bug#432404: bindgraph: Does not display any graphs
severity #432404 wishlist thanks David J. M. Karlsen wrote: Package: bindgraph Version: 0.2-5 Severity: grave Justification: renders package unusable No graphs are generated. If run from the command line w/o any arguments it produces: BindGraph was never meant to be called directly from the command line. It is a CGI, and so it *needs* to be called from Apache (or other suitable webserver) Of course, the script itself could be tweaked to barf on a more appropriate way, but I see no reason why a CGI should work if invoked from command line, without the information it needs to work. Moreover, how it bindgraph supposed to generate graphs in this situation? Do you meant to have it echo the generated PNG on stdio? Write that into a randomly-generated filename? In either case, which of the different graphs that it is able to generate would be written? sunshine:~# /usr/lib/cgi-bin/bindgraph.cgi Use of uninitialized value in substitution (s///) at /usr/share/perl/5.8/File/Basename.pm line 338. fileparse(): need a valid pathname at /usr/lib/cgi-bin/bindgraph.cgi line 180 As said before, this is perfectly fine behaviour for a CGI script invoked directly. Friendly, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362032: Please remove 'progsreiserfs' from the Archive
Package: ftp.debian.org Severity: normal After a full release cycle, it is high time we did. Having nobody actually using 'progsreiserfs' ---the installations reported by popcon are certainly due to mistaken installations looking for 'reiserfsprogs'---, and given that upstream dissapeared quite some time ago, it is pointless to keep it in the Archive. Vorlon, this will additionally get rid of a source of RC bugs -- so much better for everybody :-) Regards, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400066: FTBFS: Error: Unrecognized opcode: `outb'
Steve Langasek wrote: reopen 400066 thanks - restrict building to just i386, amd64 (Closes: #400066) This is not an acceptable solution at all. There is nothing x86-specific about this package, and even up to *0.5.1-1*, the package was building successfully on alpha until you changed the architecture list. This is indeed a transient solution, suggested by upstream himself. Upstream version 0.4.5 of lcdproc was portable to all architectures. That 0.5.1 is not is a regression, and it's not ok to close the issue by declaring that only i386 and amd64 will be supported. It is the release policy that packages must be supported on all architectures where it is reasonable to do so, and it is most definitely reasonable to support architectures where the package was building fine before. But it is my fault that the newer 0.5.2 hasn't been packaged yet. Which I will do as soon as possible (I have to sort out a couple other packages before) The only architecture that should be dropped from the supported list for this package is s390, because s390 does not support serial, parallel, and USB devices; but all other archs must be supported I concur... even though I don't know how the different parallel devices should be supported across architectures. While the serial devices have always had good, uniform, support, I don't know how parallel ports are handled outside of the PC architecture. Even though it sounds a bit hack-ish, I think I might try a different set of configuration flags depending on the architecture (enable parallel drivers for i386/amd64, disable them for the remaining arches). Am I making some wrong assumption here, Jonathan? Thank you for your semi-constant attention and help, Steve. It is much appreciated. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418134: pommed-1.1
José Luis Tallón wrote: So I'll update and post 0.13.6 instead (now it has been released) Ooopss... it was 5am and I thought it was a release, not a beta :$ Looking forward to Thomas' test result for the EFI Macs :-) ETA: tonight This was for the package, sorry. It has just finished building (v0.13.5), and tested ok. J.L.
Bug#418425: libsmbios1: symbol lookup error: /usr/lib/libsmbios.so.1: undefined symbol: __cxa_pure_virtual
Julien BLACHE wrote: José Luis Tallón [EMAIL PROTECTED] wrote: Hi José, waiting for a fixed source package. Which I will send later today Any news on this ? Beside the fix for this bug, the new version also supports EFI machines which have a non-standard SMBIOS entry point, which is the case of the Apple machines when booted with an EFI-aware kernel. (btw I tested my fixed version of 0.13.5 and it works fine as far as pommed's usage of libsmbios goes ;) I have just sent the latest version to you. Let's test and have it uploaded :-)
Bug#418425: libsmbios1: symbol lookup error: /usr/lib/libsmbios.so.1: undefined symbol: __cxa_pure_virtual
Julien BLACHE wrote: José Luis Tallón [EMAIL PROTECTED] wrote: Hi, (btw I tested my fixed version of 0.13.5 and it works fine as far as pommed's usage of libsmbios goes ;) I have just sent the latest version to you. Let's test and have it uploaded :-) It's making its way to ftp-master right now :-) I've just removed the autom4te.cache directory from the source tarball, it saves more than 700 KB that way. Hmm... so I only removed it *once* :-O Otherwise nothing to notice, the build went just fine. Thanks, Thank you :-)
Bug#418134: pommed-1.1
Julien BLACHE wrote: Michael E Brown [EMAIL PROTECTED] wrote: Hi Michael, On Sun, Apr 15, 2007 at 10:53:11AM +0200, Julien BLACHE wrote: (BTW Michael, the libtool script used in 0.13.5 is very old and does not know how to build C++ shared libraries properly - updating to a modern libtool (1.5) is required) Thanks for the report. The 0.13.6 beta I posted also updates all the autotools stuff. Thanks, that's good news :) Indeed :-) So I'll update and post 0.13.6 instead (now it has been released) Looking forward to Thomas' test result for the EFI Macs :-) ETA: tonight JB. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418425: libsmbios1: symbol lookup error: /usr/lib/libsmbios.so.1: undefined symbol: __cxa_pure_virtual
Julien BLACHE wrote: José Luis Tallón [EMAIL PROTECTED] wrote: Hi José, waiting for a fixed source package. Which I will send later today Any news on this ? Sorry, had a busier end-of-week than expected. Beside the fix for this bug, the new version also supports EFI machines which have a non-standard SMBIOS entry point, which is the case of the Apple machines when booted with an EFI-aware kernel. :-) (btw I tested my fixed version of 0.13.5 and it works fine as far as pommed's usage of libsmbios goes ;) Thanks for checking. You have also provided the recipe, so I will try and get it ready ASAP (I have to finish just one thing before) Cheers, J.L.
Bug#418425: libsmbios1: symbol lookup error: /usr/lib/libsmbios.so.1: undefined symbol: __cxa_pure_virtual
Julien BLACHE wrote: José Luis Tallón [EMAIL PROTECTED] wrote: http://devel.adv-solutions.net/debian/pool/main/libs/libsmbios/libsmbios_0.13.5-1.dsc ( .orig.tar.gz .diff.gz are there ) Everything *seems* to be allright (can test it on a Dell until tomorrow at least) Note: package not uploaded because the source package was unclean and did not build; To be precise: - leftover autom4te.cache from autoconf - libtool placed symlinks instead of copying files over (missing -c switch) = FTBFS if libtool is not installed waiting for a fixed source package. Which I will send later today Thanks, J.L.
Bug#418425: libsmbios1: symbol lookup error: /usr/lib/libsmbios.so.1: undefined symbol: __cxa_pure_virtual
Julien BLACHE wrote: severity 418425 serious merge 418134 418425 thanks Noel Köthe [EMAIL PROTECTED] wrote: Hi, since the upgrade to 0.13.4 I get this: # /etc/init.d/pommed start Starting pommed: /usr/sbin/pommed: symbol lookup error: /usr/lib/libsmbios.so.1: undefined symbol: __cxa_pure_virtual Yep, that's #418134 and it's entirely libsmbios' fault :-P I guess I'm going to NMU libsmbios this week-end if the maintainer does not react by then. If you have serious desires to upload something, you could as well sponsor my upload of libsmbios 0.13.5-1 I am currently going over the package again, fixing the remaining bits, and expect to have a finished version tonight. Friendly, J.L.
Bug#418425: libsmbios1: symbol lookup error: /usr/lib/libsmbios.so.1: undefined symbol: __cxa_pure_virtual
Julien BLACHE wrote: José Luis Tallón [EMAIL PROTECTED] wrote: Hi, If you have serious desires to upload something, you could as well sponsor my upload of libsmbios 0.13.5-1 I am currently going over the package again, fixing the remaining bits, and expect to have a finished version tonight. I can upload it tomorrow if it's ready tonight, mail me a URL where I can grab the package. http://devel.adv-solutions.net/debian/pool/main/libs/libsmbios/libsmbios_0.13.5-1.dsc ( .orig.tar.gz .diff.gz are there ) Everything *seems* to be allright (can test it on a Dell until tomorrow at least) (could upload it tonight maybe, depends on whether I get a working connection tonight or not) Merci, Julien :-)
Bug#415954: Bug#416156: PID handling in init.d is fragile
Jeroen van Wolffelaar wrote: Can you please bounce this mail to the bug log? I didn't want to do so because this is private mail, but this really really should be part of the bug log. On Wed, Mar 28, 2007 at 12:13:39AM +0200, José Luis Tallón wrote: Jeroen van Wolffelaar wrote: On Tue, Mar 27, 2007 at 10:54:58PM +0200, José Luis Tallón wrote: Jeroen van Wolffelaar wrote: Package: imapproxy Version: 1.2.4-10 Severity: important The pid-handling of imapproxy is pretty fragile, as documented in #369020 amongst others. The current workaround of writing a new pidfile after start based on 'ps ax' output is, eh, fragile at best, and actually pretty bad. The proper solution would be to patch imapproxy so that it writes out a pidfile itself, like proper daemons should. Fixed. Will submit the patch ASAP Why didn't you attach it? I'm pretty busy tomorrow, and want to get this fixed ASAP. I mean, the plan is to release this weekend... I was finishing testing. Everything seems to be fine now :-) Please check and re-check as you wish. (Vorlon, if you possibly can, do that also) Uploaded as NMU, because I actually made some changes. Reviewed them. Gotta ACK, anyway. (You are right in the changes you made, I would have done it differently) Changes: - function Daemonize ( const char* pidfile ); Fine. I did put the function back where it was though, instead of moving it way below, because the stuff in between can hang (for example, when failing to connect, it'll indefinitely retry every 15 seconds, causing 'start' to hang). Yup. I noticed that. From my POV, it is related to a misconfiguration of the server --- being configured to connect to a nonexistent/malfunctioning IMAP server. However, I do realize it could hang the booting process, so it should be fixed. ACK to your solution Moving Daemonize to later on was not related to this RC bug. Putting it in its own function isn't either, but is pretty harmless, so ok. It does allow to move where Daemonize is called easily ;) - added support for the -p pidfile option Cool. There was a buglet here -- you didn't initialize the var and then only overwrote it with the default if it started with a nulbyte. I changed that to simply always initialize it to the default. Indeed. I know better than to have a variable unitialized, BUT I followed upstream's style here (the same pattern as with the configfile) -- I am aiming for inclusion of this by now HUGE patch, anyway... I also made pidfile creation predictable -- always create one when running in background mode, instead of only in some cases. OK - updated Usage() to reflect new option I updated the manpage too. Thanks. I missed that. - modified initscript. Vastly simplified logic. -- I also added a couple more cosmetic changes: DEFAULT - DEFAULTS; test -f - test -x; Reverted, not related to the RC bug. OK I have tested starting / restarting / stopping / re-stopping Added code to not actually fail on second start / fail on second stop that I had already prepared. It now should really work fine in all cases. I also removed dead code from checking the exit state of a 'true'. I removed the || true so that the script just fails right there when it eh, fails. ACK. I will re-check the Developer's Reference for mandated/recommended messages and initscript behaviour in those cases not covered by the Policy. The behaviour upon some, certain, connection failures is a bit annoying (upstream), but I can't change those. If you mean that start simply hangs indefinitely there, sorry, that's not just 'a bit annoying', but a showstopper, and actually introduced by your change to where to Daemonize(). ACK. I didn't notice the looping before daemonizing, or else I wouldn't have moved that. Attempting to reconnect once in the background does make sense, though Comments? I'll be up until late... This late :)? Wll... not today :-\ Thanks again, J.L.
Bug#415954: Bug#416156: PID handling in init.d is fragile
Jeroen van Wolffelaar wrote: [snip] Fine. I did put the function back where it was though, instead of moving it way below, because the stuff in between can hang (for example, when failing to connect, it'll indefinitely retry every 15 seconds, causing 'start' to hang). Yup. I noticed that. From my POV, it is related to a misconfiguration of the server --- being configured to connect to a nonexistent/malfunctioning IMAP server. However, I do realize it could hang the booting process, so it should be fixed. ACK to your solution It's a misconfiguration, sure, but one that happens on default install (out of the box imapproxy is misconfigured? Well, it was in my case, but probably related to the fact that I don't actually have any imap server running on my test machine :) Well, I do. But I did test that case (pointing to a non-existant server) Imapproxy's configuration process does ask you for a server, so a misconfiguration there is certainly due to the user. In any case, yeah, the problem is that start should simply never hang. Moving Daemonize to later on was not related to this RC bug. Putting it in its own function isn't either, but is pretty harmless, so ok. It does allow to move where Daemonize is called easily ;) - added support for the -p pidfile option Cool. There was a buglet here -- you didn't initialize the var and then only overwrote it with the default if it started with a nulbyte. I changed that to simply always initialize it to the default. Indeed. I know better than to have a variable unitialized, BUT I followed upstream's style here (the same pattern as with the configfile) -- I am aiming for inclusion of this by now HUGE patch, anyway... Yes, but in that case, you failed to properly copypaste the full thing -- upstream *does* set the first byte of ConfigFile to \0, you didn't copy that bit. :-\ Touché. You also didn't completely copy the logging to be analogous. This was on purpose. I have tested starting / restarting / stopping / re-stopping Added code to not actually fail on second start / fail on second stop that I had already prepared. It now should really work fine in all cases. I also removed dead code from checking the exit state of a 'true'. I removed the || true so that the script just fails right there when it eh, fails. ACK. I will re-check the Developer's Reference for mandated/recommended messages and initscript behaviour in those cases not covered by the Policy. I'm not so sure either dev-ref or policy are very verbose on this, it'd be good for someone to look into this at some point... But world peace would also be nice :). Ok. I will try and bug developers-reference for this :-) [snip] Anyway, thanks a lot for your work on the pidfile handling, it was convenient to only need to verify, and not really write it all. Thank you, Jeroen. It was a pleasure working with both of you (Thank you too, Steve) J.L.
Bug#415954: imapproxy: fails to start if already running
Jeroen van Wolffelaar wrote: On Fri, Mar 23, 2007 at 05:30:02PM -0700, Steve Langasek wrote: Frankly, though, the init script has a *lot* of bad code that's trying to second-guess start-stop-daemon in ways that it shouldn't. The right way to fix this is to kill off all of this extra code, let s-s-d what it's designed to, and fix imapproxyd to not bail out with an error *after* it's returned control to the parent process... Right, except that I tried that, and it failed. s-s-d's coverage is unfortunately not good enough: #416179 -- making the s-s-d --backround --pid-file workaround useless in this case :( I see three options, all of them suck: (1) fix s-s-d (no way one week before release), (2) fix pidfile-writing imapproxy (ugh, but doable, and arguably the best longtime solution), As in save the recycler thread's PID instead of any other ? I already have a version which daemonizes as late as possible (i.e. just before launching threads). It does help a bit in the sense that imapproxy will abort execution before dettaching from the parent (s-s-d in this case), but not more. (3) give up and revert to the sarge killall imapproxyd way of stopping the daemon The current way in this init.d script is worse than the killall imapproxyd thingy, it attempts to kill just one (random) instance of imapproxyd in a very special way (by first writing some found-via-ps PID to the pidfile and then using kill-by-pid...) But anyway it plainly fails at this too. Unfortunately, yes. This initscript has become a pile of patches one of top of the other. A rewrite I have done (reverting to the new LSB-compliant /etc/init.d/skeleton) doesn't work much better, either. In fact, it is unable to even start imapproxy as it is right now [launching 'manually' does work] As attachment, my NMU patch which would have fixed this whole mess if not for #416179. The biggest part of it is still applicable for the no-op behaviour of start stop when already started/stopped, and it fixes pid-file-removal. I think the best way forward would be to go for (2). If you elaborate a bit more on this, I can get it done tonight, I think. Otherwise, please feel free to contribute whatever you see fit. My current set of changes just move the daemonization code into a function of its own and call it just before pthread_create. Looking forward to your soon response, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415954: imapproxy: fails to start if already running
severity #415954 important thanks Peter Eisentraut wrote: Package: imapproxy Version: 1.2.4-10 Severity: serious This doesn't break unrelated software. This happened during an upgrade just now: Starting IMAP proxy: /etc/init.d/imapproxy: line 56: [: too many arguments Failed to start imapproxy. Check logs for details. invoke-rc.d: initscript imapproxy, action start failed. The problem is this code: psline=`ps ax | grep imapproxyd | grep -v grep` if [ -n $psline ]; then because psline will contain multiple shell words. After adding quotes, the start action of the script still fails (exist status 1) if the service is already running, which is a violation of required init script behavior. This did work some releases ago. Unfortunately, fixes for other problems seem to have introduced this bug. I will try to fix this as soon as possible, once I get rid of other, more serious, bugs. Thanks for reporting this bug, anyway. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415954: imapproxy: fails to start if already running
Steve Langasek wrote: severity 415954 serious quit On Sat, Mar 24, 2007 at 01:10:08AM +0100, José Luis Tallón wrote: Peter Eisentraut wrote: Package: imapproxy Version: 1.2.4-10 Severity: serious This doesn't break unrelated software. No, it breaks the package itself. ACK Let's make another release ASAP, then. J.L.
Bug#415234: kcheckgmail from etch is unable to check mail on gmail.com
Pierre Bauduin wrote: Package: kcheckgmail Version: 0.5.5-2 Severity: grave Tags: upstream Architecture: i386 Hi there, I think I have found a grave problem in the kcheckgmail that comes with Debian GNU/Linux 4.0 etch. Basically, it always fails to authenticate to gmail.com http://gmail.com, with the following error message: Erreur inconnue lors de la récupération des cookies which roughly translates to: Unknown error while retrieving cookies. [snip] Because of this bug kcheckgmail is completely unable to check mail in gmail. Can someone look into this ? Yup. This is unfortunately known. Upstream is preparing a new version, but nothing has been published. I am working from a CVS snapshot to try and produce a working version. However, upstream changed since last stable version (thanks, petrol_pumper) and hasn't released anything better. Will try to produce something during the weekend, and then we'll see what happens. J.L.
Bug#405704: closed by Jose Luis Tallon [EMAIL PROTECTED] (Bug#405704: fixed in up-imapproxy 1.2.4-8)
Ryan Sinn wrote: Please don't close this bug until the actual fix is available... I can't find it in the pool yet -- and it's still broken on my system. Please learn how to interact with the BTS. This was generated automatically upon the upload which closes this bug. That means that the package fixing it arrived at the Archive at that particular time, and was included in the pool along all others You should see it with this morning's mirror push. You have all details below. Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report #405704: imapproxy: fails to start - breaks install/upgrade, which was filed against the imapproxy package. It has been closed by Jose Luis Tallon [EMAIL PROTECTED]. Their explanation is attached below. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Jose Luis Tallon [EMAIL PROTECTED] by replying to this email. Debian bug tracking system administrator (administrator, Debian Bugs database) - Subject: Bug#405704: fixed in up-imapproxy 1.2.4-8 From: Jose Luis Tallon [EMAIL PROTECTED] Date: Mon, 12 Mar 2007 01:02:04 + To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Source: up-imapproxy Source-Version: 1.2.4-8 We believe that the bug you reported is fixed in the latest version of up-imapproxy, which is due to be installed in the Debian FTP archive: imapproxy_1.2.4-8_i386.deb to pool/main/u/up-imapproxy/imapproxy_1.2.4-8_i386.deb up-imapproxy_1.2.4-8.diff.gz to pool/main/u/up-imapproxy/up-imapproxy_1.2.4-8.diff.gz up-imapproxy_1.2.4-8.dsc to pool/main/u/up-imapproxy/up-imapproxy_1.2.4-8.dsc A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Jose Luis Tallon [EMAIL PROTECTED] (supplier of updated up-imapproxy package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) Format: 1.7 Date: Sat, 10 Mar 2007 21:59:37 +0100 Source: up-imapproxy Binary: imapproxy Architecture: source i386 Version: 1.2.4-8 Distribution: unstable Urgency: high Maintainer: Jose Luis Tallon [EMAIL PROTECTED] Changed-By: Jose Luis Tallon [EMAIL PROTECTED] Description: imapproxy - IMAP protocol proxy Closes: 352999 369020 405704 409861 412221 Changes: up-imapproxy (1.2.4-8) unstable; urgency=high . * Fixed crash on startup when IMAP server is not available (Closes: #405704) . * Security: backported possible DoS fix from 1.2.5rc2 (Closes: #409861) . * Enhance security: enable chroot by default (Closes: #352999) (Patch provided by Kees Cook [EMAIL PROTECTED]) . * Build process: fixed using files from current autotools-dev . * Made initscript a bit more intelligent, so that it won't fail so easily when imapproxyd is slower to start than expected (Closes: #369020) . * Localization - Updated DE translation (Closes: #412221) Files: 799d1ea0450b74da3e0e1fb8ac48fe54 671 mail optional up-imapproxy_1.2.4-8.dsc cbe938cc40ea584ccfd5e65b8c0c48ef 60135 mail optional up-imapproxy_1.2.4-8.diff.gz 125e6fa637b0551d401657c0c34c7283 53674 mail optional imapproxy_1.2.4-8_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405704:
Steve Langasek wrote: Hi Thijs, I really don't understand why this bug should be considered 'grave'. Thank you for your interest, Steve. The bug has been patched anyway :-) Seems to be working, so I will proceed to ask for an sponsored upload soon, along with some additional translations. Thijs, wanna sponsor that ? The explanation of the provided patch is that imapproxy segfaults /when the server isn't listening/; I've configured imapproxy here to test, and it starts fine for me when pointed at my imap server. Yes, it crashes for me if I instead configure it to look at a non-existent (or down) server, but does that make the package unusable? In fact not, but a SEGFAULT is always a severe thing, so we'd better fix it if possible. I will be forwarding this patch upstream, so that it can be merged and released along future releases. Meanwhile, let's make this the best release ever :-) Cheers, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400066: Closing bug
Nicolas François wrote: reopen 400066 ! found 400066 0.5.1-2 retitle 400066 lcdproc_0.5.1-2(powerpc/unstable): FTBFS: impossible constraint in asm thanks On Sat, Dec 02, 2006 at 12:23:12AM +0100, José Luis Tallón wrote: After discussion with upstream, it was agreed that lcdproc 0.5.1 should only be allowed to compile in i386/amd64/powerpc. Hence, all FTBFS bugs for this version are not relevant anymore. Even if it FTBFS on powerpc? Here is the build log: http://buildd.debian.org/fetch.cgi?pkg=lcdproc;ver=0.5.1-2;arch=powerpc;stamp=1164740084 Kind Regards, Hmmm... I had been told by upstream that it should work on i386, amd64 and powerpc. Not having the means to test it myself, I trusted them. I will therefore have to re-upload, restricting to just x86* architectures for the time being. Upstream will be notified, too. Merci, Nicolas. À bientôt. J.L.
Bug#399205: libsmbios-dev: where is libsmbios.so ?
Julien BLACHE wrote: GOTO Masanori [EMAIL PROTECTED] wrote: Hi, libsmbios-dev does not provide libsmbios.so, making it impossible to link against libsmbios. libsmbios1 has libsmbios.so - or do I misunderstand your bug report? Nope, it does not, and libsmbios-dev ships an empty /usr/lib directory. debian/dists/unstable% zgrep libsmbios.so Contents-amd64.gz usr/lib/libsmbios.so.1 libs/libsmbios1 usr/lib/libsmbios.so.1.12 libs/libsmbios1 debian/dists/unstable% zgrep libsmbios.so Contents-i386.gz usr/lib/libsmbios.so.1 libs/libsmbios1 usr/lib/libsmbios.so.1.12 libs/libsmbios1 ACK'ed. I have a fixed version ready. Just didn't have time to have it uploaded. Cheers, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389294: [Fwd: Bug#389294: lcdproc_0.5.0-1(hppa/unstable): FTBFS: bad compiler opts?]
Grant Grundler wrote: [snip] hppa-linux-gnu-gcc -fPIC -Wall -Wall -O3 -Wno-unused-function -b -o bayrad.sl bayrad.o hppa-linux-gnu-gcc: bayrad.sl: No such file or directory hppa-linux-gnu-gcc: unrecognized option '-b' gcc --help on hppa says: -b machine Run gcc for target machine, if installed My guess is -b parsing took -o as the machine type and barfed in a stupid way. Obviously bayrad.sl won't exist since we expect it to be an output but the compiler thinks it's an input. Figure out why -b is issued without a corresponding parameter that will likely solve the problem. Upstream fixed it meanwhile, or so it seems. Will take a look and see what happens. hth, Indeed. I learnt a bit more :-) Cheers, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391912: lcdproc - FTBFS: #error Can't find your mounted filesystem table file.
Steve Langasek wrote: Check for AC_FIND_MTAB_FILE in acinclude.m4. It tries to find the file but it is not there. Though lcdproc probably doesn't need to be built on s390 anyway... :) Not completely sure about this, but I might as well add a !s390 to the control file and be done with it. Any input on this would be appreciated. It was however very surprising to find that s390's buildd doesn't have a valid /etc/mtab while other arches do. I think I prefer to not add gratuituous exceptions. / J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391912: lcdproc - FTBFS: #error Can't find your mounted filesystem table file.
Bastian Blank wrote: Package: lcdproc Version: 0.5.0-1 Severity: serious There was an error while trying to autobuild your package: Automatic build of lcdproc_0.5.0-1 on debian-31 by sbuild/s390 85 [...] if s390-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -Wall -Wall -O3 -Wno-unused-function -MT machine_Linux.o -MD -MP -MF .deps/machine_Linux.Tpo \ -c -o machine_Linux.o `test -f 'machine_Linux.c' || echo './'`machine_Linux.c; \ then mv -f .deps/machine_Linux.Tpo .deps/machine_Linux.Po; \ else rm -f .deps/machine_Linux.Tpo; exit 1; \ fi machine_Linux.c:238:2: error: #error Can't find your mounted filesystem table file. make[4]: *** [machine_Linux.o] Error 1 make[4]: Leaving directory `/build/buildd/lcdproc-0.5.0/clients/lcdproc' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/build/buildd/lcdproc-0.5.0/clients' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/buildd/lcdproc-0.5.0' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd/lcdproc-0.5.0' make: *** [build-stamp] Error 2 ** Build finished at 20061008-2051 FAILED [dpkg-buildpackage died] No idea on how to handle this; Plus, I don't have access to any S390. Care to point me in the appropriate direction? Thanks in advance. Cheers, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345872: Raising severity
Sune Vuorela wrote: severity 345872 serious thank you bts A large chunk of the package is silently not build due to buggy auto* rules in upstream. I have just returned home, and a new release (in cooperation with upstream) is on its way (should hit NEW anytime soon). I'd appreciate it if you asked before sending NMUs... a lot of problems would be solved that way. a small adjustment to the patch is that the two configure.in.in files should be adjusted instead - and make -f Makefile.cvs should be rerun in the configure target of debian rules. (this needs to add autoconf and automake to build-dep) Your patches are welcome, however. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345872: debian nmu patch
Sune Vuorela wrote: Hi! I got a sponsor a bit faster than expected. Of course. John is trying to screw me. Here is the patch. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337250: Bug blocked
Christian Hammers wrote: block 343762 by 337250 thanks Bacula FTBFS which prevents me from doing an NMU upload :( The upload is coming, sorry. Just hadn't had the time to finish it. bye, -christian- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337250: bacula FTBFS
Steinar H. Gunderson wrote: On Sun, Nov 27, 2005 at 04:34:38PM +, Mark Hymers wrote: Attached is a patch which fixes this FTBFS. It turns out that for some reason, bscan and bcopy, when built against postgres, now need to have libdl explicitly added to the link line. The package then builds fine in a pbuilder sid chroot. There may be a neater solution but this one at least works. FWIW, it doesn't here (anymore?): Neither here anymore. I have had to disable static linking, which gives rise to a whole new lot of problems. make[1]: Entering directory `/build/build/bacula-1.36.3/src/stored' i486-linux-gnu-g++ -static -O -L../lib -L../cats -L../findlib -o bscan bscan.o block.o device.o dev.o label.o autochanger.o acquire.o mount.o record.o match_bsr.o parse_bsr.o butil.o read_record.o stored_conf.o spool.o -lsql -L/usr/lib -lpq -lssl -lcrypto -lcrypt -lkrb5 -lk5crypto -lcom_err -lresolv -lacl -lz -lfind -lbac -lm -lpthread -lwrap -ldl make[1]: Leaving directory `/build/build/bacula-1.36.3/src/stored' strip: 'src/stored/bscan': No such file strip: 'src/stored/bcopy': No such file /* Steinar */ J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#244169: Bugs should be closed when the bug has been proven to disappear
Enrico Zini wrote: Hello, Sorry, my fault, this one slipped when I checked the package. I'm reopening this bug which was closed by this changelog entry: * Updated to newer upstream version ... (Closes: #231304) - Will this work? (Closes: #244169) Of course a bug should be closed when the problem has been reported to be solved, not when one hopes that the new version will solve the problem :) We haven't got any feedback on this for ages (mostly my fault, i must admit). A possibility to check wether this works (a new upstream version supposedly fixes bugs, right?) is to let people test it, warning them before. Enrico: I thought that you agreed with this, after seeing your reply to my last e-mail... must have misunderstood, sorry. You will see that i have filed another RC bug against this, more clearly explaining this issue (i think). J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337250: bacula: FTBFS: 'src/stored/bscan': No such file
Daniel Schepler wrote: Package: bacula Severity: serious Version: 1.36.3-2 Hmm... sorry... are you a buildd admin?? or trying to build from source for whatever reason? AFAIK, the buildds are doing fine any more details you can give me to help diagnose the problem? From my pbuilder build log: ... i486-linux-gnu-g++ -DHAVE_POSTGRESQL -c -I. -I.. -g -O2 -Wall testls.c i486-linux-gnu-g++ -g -L. -L../lib -L../findlib -o testls testls.o \ -lfind -lbac -lm -lpthread -lwrap Make of tools is good make[1]: Leaving directory `/tmp/buildd/bacula-1.36.3/src/tools' + Renaming flavored binaries... - src/dird/bacula-dir - src/dird/bacula-dir.pgsql - src/tools/dbcheck - src/tools/dbcheck.pgsql make[1]: Entering directory `/tmp/buildd/bacula-1.36.3/src/stored' i486-linux-gnu-g++ -static -L../lib -L../cats -L../findlib -o bscan bscan.o block.o device.o dev.o label.o autochanger.o acquire.o mount.o record.o match_bsr.o parse_bsr.o butil.o read_record.o stored_conf.o spool.o -lsql -L/usr/lib -lpq -lssl -lcrypto -lcrypt -lkrb5 -lk5crypto -lcom_err -lresolv -lacl -lz -lfind -lbac -lm -lpthread -lwrap make[1]: Leaving directory `/tmp/buildd/bacula-1.36.3/src/stored' strip: 'src/stored/bscan': No such file strip: 'src/stored/bcopy': No such file mv: cannot stat `src/stored/bscan': No such file or directory mv: cannot stat `src/stored/bcopy': No such file or directory make: *** [build-arch-flavor-stamp] Error 1 Not enough info... works for me :-O Best, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334034: kcheckgmail_0.5.4-1(hppa/unstable):
[EMAIL PROTECTED] wrote: Package: kcheckgmail Version: 0.5.4-1 Severity: serious There was an error while trying to autobuild your package: Thank you, Lamont. Incorporating changes as soon as possible. Is there anything that upstream can do to help with this? i would forward the information and ensure that the fixes are there for the next version. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327991: NMU diff for this bug
Adeodato Simó wrote: Hi, Adeodato: Hello, I plan on uploading NMUs for the above bugs very soon. The packages are: [snip] kwirelessmonitor 0.5.91-1.1 [snip] I have had *enormous trouble* recompiling kwirelessmonitor with the new toolchain... any incantation to make it work? I would have uploaded a new version already otherwise (as i already did with my other packages) You can find a diff, plus the source and binary packages I'll upload, in: http://people.debian.org/~adeodato/tmp/2005-09-27/qt-kde-nmus I'll take a look and let you know. Thanks José Luis
Bug#325820: [Fwd: Re: [Fwd: Bug#325820: baghira: FTBFS: 'ResizeHandle' has not been declared]]
Original Message Subject:Re: [Fwd: Bug#325820: baghira: FTBFS: 'ResizeHandle' has not been declared] Date: Wed, 31 Aug 2005 18:32:04 +0200 From: Thomas Lübking [EMAIL PROTECTED] To: José Luis Tallón [EMAIL PROTECTED] CC: Andreas Jochens [EMAIL PROTECTED] References: [EMAIL PROTECTED] Hi José, Andreas the problem on this is that moc doesn't care for the preprocessor definitions. solutions: 1. use the cvs code ;) (has been fixed there short after 0.6e) 2. update to kde = 3.4 3. wait a few days to get bright shiny new 0.7 (with a LOOOT of new features and enhancements) Regards, Thomas -- Fear... Fear attracts the fearfull. The strong. The weak. The innocent. The corrupt. Fear... Fear is my ally!
Bug#323722: maintainer seems MIA, we should orphan this package.
Roberto Lumbreras wrote: Hi Sven... Jose Luis Tallon email is bouncing because he seems to be using some stupid RBL that bans every DSL user in the planet. Try sending mail from other account and it will work. Thanks, Rober... i'll have to remove that i think. Jose Luis is in the new maintainer process, and has been very active with his packages, as you can see: http://packages.qa.debian.org/b/bacula.html http://qa.debian.org/[EMAIL PROTECTED] I've been the sponsor for all these uploads, and definitely no, he is not MIA. Definitively NOT! Maybe you are right with progsreiserfs, it is not my favorite package to fsck my filesystem, it has lots of bugs, but if there are fixes we should let Jose Luis or someone to fix them. Well, in fact, there was a quite harsh discussion re: progsreiserfs, including upstream Hans Reiser himself. It was decided --with mediation from RM Steve Langasek-- that it shall be left in unstable with an RC bug for the time being until we could find some better solution... this might mean updating the packaged version, which i won't do until i can confirm *from upstream* that it is indeed stable. Thanks for your attention but i'm definitively *not* MIA. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323722: maintainer seems MIA, we should orphan this package.
Sven Luther wrote: On Thu, Aug 18, 2005 at 12:40:11PM +0200, Jos? Luis Tall?n wrote: Ok, but now that sarge is released, what are the plans for etch ? The question is if i keep parted without reiserfs support, or if i add it again ? If there really is interest in support for ReiserFS in PartEd, i will more actively maintain this package. It was left as it was just in case. Thanks for your attention but i'm definitively *not* MIA. Hehe, the bouncing email and the 1 year plus old changelog entry made me believe otherwise. But that said, have you looked at the patches in the bug-parted mailing list, do you want me to send them or something ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323722: maintainer seems MIA, we should orphan this package.
Sven Luther wrote: On Thu, Aug 18, 2005 at 05:37:48PM +0200, Jos? Luis Tall?n wrote: Sven Luther wrote: Well, i personally couldn't care less, since i don't use reiserfs, which is known to eat data for breakfast, Hmmm... that was *years* ago, when Linux2.4's VM was not stable enough. I've used it for ages, and never had any problems -- whereas ext3 gave more than a headache several times... ... but let us not make a flamewar of this. but i disabled reiserfs support only because progreiserfs was kicked out of testing. Correct, due to the -- yet unresolved problem with libreiserfs. Would you mind forwarding me the relevant patches? you seem to have them far more handy than me. Thanks. Friendly, VERY GOOD way to end a not-yet-started flamewar :-D Hopefully, you'll be able to re-enable ReiserFS soon (in a couple of weeks or so) J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289838: patch to 1.36.1-1
Jamie ffolliott wrote: Jose, I had some work done on this back in November, so I took some time to clean it up, finished off some more and tested a patch. I hope no one else has invested much time in these pgsql bugs yet, but I believe this will close both this one and 272191. Well, i have received some patches during the last week, and i'm currently integrating them. I noticed a few of the bugs were fixed already in 1.36.1-1, so I left those out of the patch. Ok This patch covers a bunch of things, but essentially makes the bacula-director-pgsql package very close to complete now, and handles remote pg hosts. Changelog included in the patch. Wonderful. Thanks!! At last you'll end up with a working bacula install with pgsql. Not me, but *we*. Thank you very much, again! Expect a Bacula-1.36.2 upload sometime early next week. Best, J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
