Re: bonojour :)
On Thu, May 11, 2006 at 06:18:12PM +0200, [EMAIL PROTECTED] wrote : et n\'oublie surtout pas de visiter: www.tchatcheamour.com c\'est trois sites en un: site pour les rencontres amour, site pour les rencontres sexe, et un site pour les rencontres gays. Alors là les bras m'en tombent... Je m'étais plaint à leur précédent hébergeur, qui avait fermé leur compte, et ils recommencent. Là ils sont chez wistee, qui est chez OVH. Je me plaindrai à l'un avant de passer à l'autre si ça ne marche pas. Errare humanum est, perseverare diabolicum. Bonne journée -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bonojour :)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles Plessy a écrit : On Thu, May 11, 2006 at 06:18:12PM +0200, [EMAIL PROTECTED] wrote : et n\'oublie surtout pas de visiter: www.tchatcheamour.com c\'est trois sites en un: site pour les rencontres amour, site pour les rencontres sexe, et un site pour les rencontres gays. Alors là les bras m'en tombent... Je m'étais plaint à leur précédent hébergeur, qui avait fermé leur compte, et ils recommencent. Là ils sont chez wistee, qui est chez OVH. Je me plaindrai à l'un avant de passer à l'autre si ça ne marche pas. Errare humanum est, perseverare diabolicum. Bonne journée Je suis surpris : ils semblent toujours chez WHD-RS (power-heberg) comme avant (cf le résultat du ping). Comment as-tu l'information qu'ils ont changé d'hébergement ? PS : l'adresse en cas d'abus est [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEZA8i18/WetbTC/oRAgElAJ9KbDwPRCOijNTfveAxO1w2hXnROwCePnCD l8SzRu4VfAttOhkxzVibg1E= =B8dT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bonojour :)
Charles Plessy [EMAIL PROTECTED] wrote: Alors là les bras m'en tombent... Je m'étais plaint à leur précédent hébergeur, qui avait fermé leur compte, et ils recommencent. La prochaine fois, tu seras intelligent et tu éviteras de quoter en intégralité (et surtout avec l'url) le spam auquel tu réponds. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
* Andreas Barth [EMAIL PROTECTED] [2006-05-10 23:11]: there were some requests, e.g. by Martin Michlmayr to the release team whether we could switch gcc to 4.1 or not for etch. As we're heading to freeze etch rather soon and also the RC bug count doesn't look too good, and we want to be on time this time :), we think the switch to gcc 4.1 as default should only be made if not more than 20 packages become RC buggy by it. Also, the switch should happen latest 1.5 months prior to freeze, that is Jun 15th. I'm in favour of gcc 4.1 as it would provide our etch users with a fairly recent default gcc at the time of the release and avoids the rumor that debian releases badly outdated stuff as well. yours Martin -- [EMAIL PROTECTED] Debian GNU/Linux - The Universal Operating System Thought i am about to sell the oldest disks in the world :d Hoopy those 5 1/4 inch floppys moses saved the 10 command prompts on? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote: Hi, there were some requests, e.g. by Martin Michlmayr to the release team whether we could switch gcc to 4.1 or not for etch. As we're heading to freeze etch rather soon and also the RC bug count doesn't look too good, and we want to be on time this time :), we think the switch to gcc 4.1 as default should only be made if not more than 20 packages become RC buggy by it. Also, the switch should happen latest 1.5 months prior to freeze, that is Jun 15th. Additional data point: GCC 4.0 on m68k is mostly crap, and probably the reason why we haven't been able to make it back as a release candidate architecture yet. GCC 4.1 fixes a _lot_ of the GCC 4.0 bugs on m68k, and we'd really, _really_ love to see it become the default, at the very least on our architecture. So, I guess that means we'll have to help out there, doesn't it? ;-) The RC bug NMU policy also applies to such bugs, but please be aware: Do not upload package until you make sure you don't break anything. Please check also that you're not just disturbing a transition (e.g. don't NMU packages in sid the day before they go to testing :). Questions should go to debian-release also (though of course I read d-d also :). One: What's the easiest way to extract the list of gcc-4.1 related bugs from the BTS? -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
On Wed, 10 May 2006, Andreas Barth wrote: Hi, there were some requests, e.g. by Martin Michlmayr to the release team whether we could switch gcc to 4.1 or not for etch. As we're heading to freeze etch rather soon and also the RC bug count doesn't look too good, and we want to be on time this time :), we think the switch to gcc 4.1 as default should only be made if not more than 20 packages become RC buggy by it. Also, the switch should happen latest 1.5 months prior to freeze, that is Jun 15th. The RC bug NMU policy also applies to such bugs, but please be aware: Do not upload package until you make sure you don't break anything. Please check also that you're not just disturbing a transition (e.g. don't NMU packages in sid the day before they go to testing :). I didn't hit this problem myself yet, but it has been mentioned on sparclinux list that 4.1 currently miscompiles the sparc kernel. It's, of course, not such a big deal, if 4.0 will still be present as a non-default. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
On Thu, May 11, 2006 at 08:15:21AM +0200, Martin Wuertele wrote: * Andreas Barth [EMAIL PROTECTED] [2006-05-10 23:11]: there were some requests, e.g. by Martin Michlmayr to the release team whether we could switch gcc to 4.1 or not for etch. I'm in favour of gcc 4.1 as it would provide our etch users with a fairly recent default gcc at the time of the release and avoids the rumor that debian releases badly outdated stuff as well. I'd certainly prefer we shipped with the least bugs, rather than with fairly recent software; I don't know if these goals contradict or concur in this particular case. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the 2IC
On Thu, May 11, 2006 at 01:10:16AM +0100, Steve McIntyre wrote: Unfortunately, other mailing list discussions have been less happy. A somewhat acrimonious argument between Sven Luther and members of the d-i team spread out across various lists, starting at [3]. There has been quite lot of public discussion and more private attempts to repair the situation, but at this point things are not looking too hopeful. The situation is indeed not hopeful. The mediation attempt of the DPL failed, as he ranged himself basically with the opinion of the d-i team, and acted more like a judge delivering a sentence, than a mediator, sending his sentence to a public list, without even forewarning me. I guess Anthony doesn't know what mediation means. I am thankful for the effort Steve made to try a true mediation, altough there was absolutely no visibility and transparence of what discussions where going on with the other side of this argument, which i believe only foreshadowed the final sentence. It was more important to not hurt the feeling of the d-i team and to let them have their pride, than to search a real solution to this issue. Also, i do believe it sets a bad precedent, in that the DPL affirmed by this actions, that it is ok for people inside debian to chose moment of personal distress of other DDs to get revenge on them, and have no respect for the person behind the DD. This is i belive a failure of the electronic media we use for communication, people would generally not behave such in real life, and if they did, they would be scorned upon by their entourage, and not justified like it happens here. I guess this means that i will take a less active role in debian in the future, and to all those who are now saying good riddance, shame on you, you are not worthy of what debian represents, altough that sure seems to have changed since i first joined 8 years ago. Hurt, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote: Why would that not fly? Both versions of the arch-independent package could be installed at the same time. /usr/share/foo/bar can't point to two different files at the same time, so you can't install multiple package versions containing incompatible /usr/share/foo/bar files. The only way to support your proposal would be to kill the concept of arch-independent packages and make everything arch-dependent. But that would be a _HUGE_ waste of resources (/usr/share takes about half the size of the /usr partition here). It's not worth it. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
* Wouter Verhelst ([EMAIL PROTECTED]) [060511 08:59]: On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote: there were some requests, e.g. by Martin Michlmayr to the release team whether we could switch gcc to 4.1 or not for etch. As we're heading to freeze etch rather soon and also the RC bug count doesn't look too good, and we want to be on time this time :), we think the switch to gcc 4.1 as default should only be made if not more than 20 packages become RC buggy by it. Also, the switch should happen latest 1.5 months prior to freeze, that is Jun 15th. Additional data point: GCC 4.0 on m68k is mostly crap, and probably the reason why we haven't been able to make it back as a release candidate architecture yet. Yes, known. However, we have to consider what is worse - adding more RC bugginess on all arches, or being bad to one arch already having some (other) issues. And I think the number of 20 new RC bugs is fair to both sides (or that's at least what we thought when we discussed about the numbers). GCC 4.1 fixes a _lot_ of the GCC 4.0 bugs on m68k, and we'd really, _really_ love to see it become the default, at the very least on our architecture. So, I guess that means we'll have to help out there, doesn't it? ;-) Definitly. :) One: What's the easiest way to extract the list of gcc-4.1 related bugs from the BTS? There is none I know - I asked Martin already yesterday on IRC to provide such a way. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
On Thu, May 11, 2006 at 10:00:46AM +0200, Andreas Barth wrote: * Wouter Verhelst ([EMAIL PROTECTED]) [060511 08:59]: On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote: there were some requests, e.g. by Martin Michlmayr to the release team whether we could switch gcc to 4.1 or not for etch. As we're heading to freeze etch rather soon and also the RC bug count doesn't look too good, and we want to be on time this time :), we think the switch to gcc 4.1 as default should only be made if not more than 20 packages become RC buggy by it. Also, the switch should happen latest 1.5 months prior to freeze, that is Jun 15th. Additional data point: GCC 4.0 on m68k is mostly crap, and probably the reason why we haven't been able to make it back as a release candidate architecture yet. Yes, known. However, we have to consider what is worse - adding more RC bugginess on all arches, or being bad to one arch already having some (other) issues. Yes, I understand that; I just wanted to explain for people not familiar with the issues, that's all. And I think the number of 20 new RC bugs is fair to both sides (or that's at least what we thought when we discussed about the numbers). Sure. Which is mostly why I'm suggesting to help out. One: What's the easiest way to extract the list of gcc-4.1 related bugs from the BTS? There is none I know - I asked Martin already yesterday on IRC to provide such a way. Right. For now, I'll start off with suggesting upstream to have a look at #361396 :-) -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On 5/11/06, Gabor Gombas [EMAIL PROTECTED] wrote: On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote: Why would that not fly? Both versions of the arch-independent package could be installed at the same time. /usr/share/foo/bar can't point to two different files at the same time, so you can't install multiple package versions containing incompatible /usr/share/foo/bar files. The only way to support your proposal would be to kill the concept of I think there are much more ways to implement it. :) But indeed, having all packages put files in a single directory won't work. But that approach is resulting in some problems already today. arch-independent packages and make everything arch-dependent. But that would be a _HUGE_ waste of resources (/usr/share takes about half the size of the /usr partition here). It's not worth it.
Re: gcc 4.1 or not
On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote: Hi, hi, there were some requests, e.g. by Martin Michlmayr to the release team whether we could switch gcc to 4.1 or not for etch. As we're heading to what about the transition to python 2.4? is it going to start or etch is going to ship with 2.3? cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the 2IC
Sven Luther [EMAIL PROTECTED] writes: On Thu, May 11, 2006 at 01:10:16AM +0100, Steve McIntyre wrote: Unfortunately, other mailing list discussions have been less happy. A somewhat acrimonious argument between Sven Luther and members of the d-i team spread out across various lists, starting at [3]. There has been quite lot of public discussion and more private attempts to repair the situation, but at this point things are not looking too hopeful. The situation is indeed not hopeful. The mediation attempt of the DPL failed, as he ranged himself basically with the opinion of the d-i team, and acted more like a judge delivering a sentence, than a mediator, sending his sentence to a public list, without even forewarning me. I guess Anthony doesn't know what mediation means. A reason for the failing of mediation is that you seem to have no interest to work together with the people who have (not in a very nice way) removed your commit rights. You have kept flaming on public lists in the last few days, which is normally not a good way to get people to calm down. What you seem to want is some sort of decision that forces other developers to work together with you, not a mediation. Working together is not only based on technical stuff, but has also a social level. Your recent actions have shown that you do not understand about this, and I have to admit that it's probably better for the d-i team if they don't have to fight with you on a regular basis. The time and motivation lost in flamewars is more valuable than anything a single developer could contribute. Marc -- BOFH #448: vi needs to be upgraded to vii pgpm9RVGbvoGW.pgp Description: PGP signature
libgnutls (was: gcc 4.1 or not)
* Mike Hommey ([EMAIL PROTECTED]) [060511 11:00]: On Thu, May 11, 2006 at 10:09:11AM +0200, Domenico Andreoli [EMAIL PROTECTED] wrote: On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote: Hi, hi, there were some requests, e.g. by Martin Michlmayr to the release team whether we could switch gcc to 4.1 or not for etch. As we're heading to what about the transition to python 2.4? is it going to start or etch is going to ship with 2.3? what about the transition to libgnutls13 ? I noticed yesterday when debootstraping that we get libgnutls11, 12 AND 13 installed by default. Do we really need that many libgnutls ? Please see e.g. bug #363294, there are some discussions about that. Of course, as in all that issues, feel free to help with packages moving away from gnutls11, but that is as of now not an RC bug (and we speak of 68 packages in testing currently using libgnutls11, which are not too few). However, it would be quite more helpful to reduce the number of real RC bugs - we need to get down from the number of 400. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
Le jeudi 11 mai 2006 à 10:09 +0200, Domenico Andreoli a écrit : what about the transition to python 2.4? is it going to start or etch is going to ship with 2.3? An upload of python-defaults switching to 2.4 has been repeatedly asked during the last months, and it was ignored by the maintainer. I'm not aware of anything preventing this upload currently. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
python version? (was: gcc 4.1 or not)
* Josselin Mouette ([EMAIL PROTECTED]) [060511 10:48]: Le jeudi 11 mai 2006 à 10:09 +0200, Domenico Andreoli a écrit : what about the transition to python 2.4? is it going to start or etch is going to ship with 2.3? An upload of python-defaults switching to 2.4 has been repeatedly asked during the last months, and it was ignored by the maintainer. I'm not aware of anything preventing this upload currently. The maintainer is not ignoring it, but the transition needs to have some issues fixed first. (And if you want to discuss aboutt hat, please leave -release out of the discussion. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
On Thu, May 11, 2006 at 10:09:11AM +0200, Domenico Andreoli [EMAIL PROTECTED] wrote: On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote: Hi, hi, there were some requests, e.g. by Martin Michlmayr to the release team whether we could switch gcc to 4.1 or not for etch. As we're heading to what about the transition to python 2.4? is it going to start or etch is going to ship with 2.3? what about the transition to libgnutls13 ? I noticed yesterday when debootstraping that we get libgnutls11, 12 AND 13 installed by default. Do we really need that many libgnutls ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#366780: ITP: summain -- compute and verify file checksums
Hello Lars, On Thu, 2006-05-11 at 03:35 +0300, Lars Wirzenius wrote: A checksum is a number that identifies the contents of a file: if the contents change, so does the checksum. If you create a checksum before you burn a CD, when you know the files are correct, you can easily check the CD at any time: just compute the checksum again and see if they have changed. . summain computes and checks files against such checksums. It supports both MD5 and SHA-1 checksums, using formats compatible with the md5sum and sha1sum utilities, both for reading and writing. In addition, it can read and verify checksums from Debian .dsc, .changes, and Sources files. (This ITP is for a program not quite released yet. I hope to get some feedback on the description. The release and package upload to NEW will happen once Debcamp6 Internet access gets more usable, or when I return home.) I like the description, but I'd switch the two paragraphs. People reading the details for this package would in most cases already be familiar with what a checksum is. It's good to explain it for those not yet in the know, but it might be better to demote that information. Thijs signature.asc Description: This is a digitally signed message part
Intent to hijack Bacula
On Tue, 9 May 2006 11:07:27, John Goerzen wrote: : Hello, : : I intend to take over the Bacula package. I would first like to say : thanks to Jose Luis Tallon for initially packaging it for Debian and : maintaining it for these years. : : A brief history of why I intend to do this: : : * Bacula has had RC bugs open for more than a year. It was removed :from testing several months ago because of this. : : * Bacula's current maintainer is not a Debian Developer and has been :in NM since 2003. : : * Bacula as it currently exists in sid is unbuildable and :uninstallable. Bacula will not be present in etch unless significant :problems are fixed. : : * The last upload for Bacula was almost a year ago. : : * The maintainer has repeatedly, over the last year, said he's working :on this but hasn't made much real progress, and has made no upload to :Debian. : : * Several additional critical-level or grave-level unreported bugs :exist in the bacula Debian source tree (such as stopping database servers :without permission and deleting files un-owned by a particular :package) : : * There are various policy compliance issues with the current packages. : : * The current maintainer does respond to pings, but has a long record :of problems getting bugs (even RC bugs) fixed in a timely fashion. I don't agree, all those things are not in my opinion enough for the hijacking. The package has bugs, lots of them, and for that reason has been removed from testing, well done, unstable it is here for that. The lots of bugs had not been solved, and several upstream versions had delayed again and again the uploads Jose Luis has been working on. A lot of work have to be done to package a new version, and a new upstream version when the last one is not yet finished doesn't help to get the things done. Ok, the maintainer has not fixed the bugs, has not packaged the last version of it in time, etc, but he has done a great job anyway, and I still don't see the point of hijacking the package. If the maintainer still wants to maintain it, help him, do NMUs, whatever, but I'm still looking for one reason you can take over the package against the maintainer opinion. Regards, rover, Jose Luis's sponsor and uploader of many of his packages including bacula, you can blame me also if you want Salud, -- Roberto Lumbreras .''`. rover : :' : debian.org Debian Developer `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: System users and valid shells...
Uwe Hermann [EMAIL PROTECTED] writes: On Fri, May 05, 2006 at 11:12:35AM +0300, Jari Aalto wrote: The rest of the system accounts are happily running with /bin/false There is now /bin/nologin which is more secure I think you mean /usr/sbin/nologin, right? Please define more secure in this context. The /bin/nologin records the user who tried to log in. This helps auditing the system and provides more secure approach to system monitoring. /bin/nologin is straight replacement of /bin/false. It originates from BSD systems. Jari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
I didn't hit this problem myself yet, but it has been mentioned on sparclinux list that 4.1 currently miscompiles the sparc kernel. Do you know if this still happens, and if so, whether someone has tracked it down? -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
* Lionel Elie Mamane [EMAIL PROTECTED] [2006-05-11 09:13]: I'd certainly prefer we shipped with the least bugs, rather than with fairly recent software; I don't know if these goals contradict or concur in this particular case. FWIW, the GCC 4.0.3 Status Report (2006-01-15) says, It's interesting to note that there are 95 serious regressions against 4.0.3 and only 63 against 4.1.0; although 4.0.3 has surely had more usage, this does suggest that 4.1.0 is in reasonably good shape. Obviously, GCC 4.1 is not free of bugs though. A more recent report, GCC 4.1 Status Report (2006-04-16), says that there are 101 serious (P3 or higher) regressions against GCC 4.1, the vast majority of which also apply to 4.2 and moves the release date of 4.1.1 from April 28 to May 15. References: http://gcc.gnu.org/ml/gcc/2006-01/msg00477.html http://gcc.gnu.org/ml/gcc/2006-04/msg00269.html -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula
Roberto Lumbreras [EMAIL PROTECTED] writes: [...] Ok, the maintainer has not fixed the bugs, has not packaged the last version of it in time, etc, but he has done a great job anyway, and I still don't see the point of hijacking the package. So he has done not one of the things expected of a good package maintainer. *What* of that is a great job? Marc -- BOFH #337: the butane lighter causes the pincushioning pgpf9mE1B0VfX.pgp Description: PGP signature
Re: Intent to hijack Bacula
* Roberto Lumbreras ([EMAIL PROTECTED]) wrote: I don't agree, all those things are not in my opinion enough for the hijacking. Thankfully, you're wrong. The package has bugs, lots of them, and for that reason has been removed from testing, well done, unstable it is here for that. It's *not* ok for the package to have been removed from testing. It also had no real hope getting back into testing at the rate with which the bugs were being resolved by Jose. The lots of bugs had not been solved, and several upstream versions had delayed again and again the uploads Jose Luis has been working on. A lot of work have to be done to package a new version, and a new upstream version when the last one is not yet finished doesn't help to get the things done. That's not an excuse. At all. Ok, the maintainer has not fixed the bugs, has not packaged the last version of it in time, etc, but he has done a great job anyway, and I still don't see the point of hijacking the package. He *hasn't* done a great job.. That would be basically the *point*. If the maintainer still wants to maintain it, help him, do NMUs, whatever, but I'm still looking for one reason you can take over the package against the maintainer opinion. He wants to have his name on the package w/o doing the work (apparently). That's not maintaining it, regardless of what he'd like to claim. rover, Jose Luis's sponsor and uploader of many of his packages including bacula, you can blame me also if you want We do. Enjoy, Stephen signature.asc Description: Digital signature
Re: gcc 4.1 or not
Hi Andi, On Wednesday, 10 May 2006, you wrote: there were some requests, e.g. by Martin Michlmayr to the release team whether we could switch gcc to 4.1 or not for etch. As we're heading to I know, tbm tried to build all packages on mips*. It would be intersting to know, how other architectures behave. Also i have not seen any comments from doko yet. Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PDF files and dh_compress
I am strongly against compressing PDFs To add insult to injury, PDF 1.5 introduces ``object streams'' which allow compressing arbitrarily long chunks of a PDF file without giving up the random-access properties of PDF. All current Free PDF readers grok PDF 1.5, although as far as I know no Free software can produce PDF 1.5 object streams. Hence the right solution is to fix gs and pdftex to produce object streams, not to work around the limitations of current Free software by gzipping PDF files and thus giving up the (quite amazing) efficiency of the format. Juliusz pgpSAcwT7EVY5.pgp Description: PGP signature
Bug#366820: Transition to GCC 4.1 for etch
Package: general Severity: wishlist It would be great if we could move to GCC 4.1 for etch. The release managers have now given us a concrete target we have to achieve before this can happen: the majority of outstanding 4.1 specific bugs in packages have to be fixed by mid of June [1]. The RC bug NMU policy applies to such bugs as of now. This bug report will be used as a meta bug to track outstsanding GCC 4.1 bugs in packages. Some background information: In March, I built the whole archive with GCC 4.1 on several architectures and filed about 280 bugs related to the new compiler (mostly in package using C++) [2]. Many of those bugs had patches and now, roughly two months later, about half of them have been fixed. However, we need to get rid of the remaining bugs. Most of them should be trivial to fix anyway. Some information about common C++ errors can be found in [3]. [1] http://lists.debian.org/debian-devel/2006/05/msg00355.html [2] http://lists.debian.org/debian-gcc/2006/03/msg00405.html [3] http://womble.decadentplace.org.uk/c++/syntax-errors.html -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: net-tools maintenance status
On 3/9/06, Olaf van der Spek [EMAIL PROTECTED] wrote: On 1/6/06, Bernd Eckenfels [EMAIL PROTECTED] wrote: Thijs Kinkhorst [EMAIL PROTECTED] wrote: So I think you can tell pretty clearly that Bernd has no objection at all to NMU's. yes, but please not for wishlist bugs. Again: there are bugs open for net-tools where help is requested, I would love to have patches for those. Generally I am not aware of time critical bugs. The wishlist bugs will get fixed in the next upstream version, however that needs some sorting out of the upstream cvs which is not in sync with redhat, suse and debian. Hi Bernd, What's the status of the next upstream version? Do you think it'll be ready before Etch? Hi again, Bernd, Could you answer the question, please? I'd like netstat to have proper IPv4 support. Greetings, Olaf
Re: Intent to hijack Bacula
On Thu, May 11, 2006 at 01:09:11PM +0200, Roberto Lumbreras wrote: The package has bugs, lots of them, and for that reason has been removed from testing, well done, unstable it is here for that. Uh no. I find it scary that you share this same idea as the original bacula maintainer. Unstable is NOT a graveyard for packages with RC bugs years old! While it is not uncommon to people to upload broken packages unstable, it's still not something unstable is meant for. And it certainly isn't ok just leave broken packages there.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula
Roberto Lumbreras [EMAIL PROTECTED] wrote: The package has bugs, lots of them, and for that reason has been removed from testing, well done, unstable it is here for that. No, it isn't. Maybe experimental is for that; but unstable is for software that is targetted to be moved to etch and to be released. The lots of bugs had not been solved, and several upstream versions had delayed again and again the uploads Jose Luis has been working on. A lot of work have to be done to package a new version, and a new upstream version when the last one is not yet finished doesn't help to get the things done. If upstream versions come in too fast, that's no reason for not uploading a version that is better than the current one, even if it is still not the newest upstream version. If upstream versions change that much that each time the packaging needs to be rewritten, either the software is not stable enough for a release (which doesn't seem to be the case with bacula) or the packaging approaches are bad. Ok, the maintainer [...] has done a great job anyway, You don't give any reasons for this claim. John has given several against it. rover, Jose Luis's sponsor and uploader of many of his packages including bacula, you can blame me also if you want Indeed, if a package that a DD has sponsored into unstable has RC bugs, they should care about it and make sure those bugs are fixed in time. If you think you won't have time for this, don't sponsor the package. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: python version?
Andreas Barth [EMAIL PROTECTED] writes: An upload of python-defaults switching to 2.4 has been repeatedly asked during the last months, and it was ignored by the maintainer. I'm not aware of anything preventing this upload currently. The maintainer is not ignoring it, but the transition needs to have some issues fixed first. (And if you want to discuss aboutt hat, please leave -release out of the discussion. :) The last time this came up in, the majority view was to transition to 2.4 as default the old way rather than keeping it pending for so long. Ganesan -- Ganesan Rajagopal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula
On Thu, May 11, 2006 at 01:09:11PM +0200, Roberto Lumbreras wrote: rover, Jose Luis's sponsor and uploader of many of his packages including bacula, you can blame me also if you want Others have pretty well addressed the rest of your message already. I'd like to expand on this point. I've been aware that it was you that uploaded at least some of the bacula packages for a couple of days now. I didn't mention it, since it wasn't directly related to getting Bacula's problems fixed. Since you bring it up, though, I think there is an important lesson in this. The Bacula packages should never have been uploaded. As sponsor, it is your duty to make sure that they meet a certain minimum level of quality. That they don't install a trojan on somebody's machine, delete files from other packages, mess up other services, etc. Except for the trojan, Bacula actually does all of that (including messing with DB server configs **by keying off a comment!** and restarting a DB server without permission). Bacula should probably never have been accepted into unstable in the first place, and you are the person that should have prevented that. (I admit I haven't looked at the 2004 packages, but certainly the more recent ones that you uploaded had serious flaws.) DDs that sponsor uploads must ensure that the code they upload is decent. And no, unstable is not a dumping ground for everything that is crappy and broken. Unstable is for code that should eventually make it into stable but hasn't been proven with the wider community yet. If you believe code wouldn't be suitable for a stable release, you shouldn't upload it into unstable. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python version?
* Ganesan Rajagopal ([EMAIL PROTECTED]) [060511 14:12]: Andreas Barth [EMAIL PROTECTED] writes: An upload of python-defaults switching to 2.4 has been repeatedly asked during the last months, and it was ignored by the maintainer. I'm not aware of anything preventing this upload currently. The maintainer is not ignoring it, but the transition needs to have some issues fixed first. (And if you want to discuss aboutt hat, please leave -release out of the discussion. :) The last time this came up in, the majority view was to transition to 2.4 as default the old way rather than keeping it pending for so long. I'm not really aware of the python issues. Are there enough python people on Debconf to make an ad-hoc BoF about python? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
* Martin Zobel-Helas [EMAIL PROTECTED] [2006-05-11 13:38]: I know, tbm tried to build all packages on mips*. It would be intersting to know, how other architectures behave. Also i have not seen any comments from doko yet. I built mips and amd64, and in the mean time also powerpc and most of sparc. Apparently hppa has some problems but I don't know any details: 22:10 vorlon also, do you know about the hppa ABI skew issues? 22:12 vorlon libstdc++6 from gcc-4.1 source doesn't work with gcc-4.0 as a compiler, because of a libgcc_s soname change -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula
On Thu, May 11, 2006 at 07:46:33AM -0400, Stephen Frost wrote: : : Roberto, : : Your mailer is busted. You might want to fix it- it's setting an : invalid Reply-To address. Below is the bounce (including my reply, if : you don't see it on d-d). My fault, I misplaced the msgid of the mail from John Gorzen in Reply-to instead of In-Reply-to, argh. Speaking about your mail, I think it's your opinion, mine is different. Jose Luis doesn't want just his name in some place, he has worked a lot in bacula in the past, and I don't know why he can't remain as maintainer or co-maitainer if he is going to work on it again. Obviuosly if he is unable to maitain it or work on it, it should orphan the package, but it seems that things are different. Regards, rover : Enjoy, : : Stephen : : Content-Description: Undelivered Message : Date: Thu, 11 May 2006 07:44:19 -0400 : From: Stephen Frost [EMAIL PROTECTED] : To: [EMAIL PROTECTED], : John Goerzen [EMAIL PROTECTED], debian-devel@lists.debian.org, : José Luis Tallón [EMAIL PROTECTED] : User-Agent: Mutt/1.5.11+cvs20060403 : Subject: Re: Intent to hijack Bacula : : * Roberto Lumbreras ([EMAIL PROTECTED]) wrote: : I don't agree, all those things are not in my opinion enough for the : hijacking. : : Thankfully, you're wrong. : : The package has bugs, lots of them, and for that reason has been removed : from testing, well done, unstable it is here for that. : : It's *not* ok for the package to have been removed from testing. It : also had no real hope getting back into testing at the rate with which : the bugs were being resolved by Jose. : : The lots of bugs had not been solved, and several upstream versions had : delayed again and again the uploads Jose Luis has been working on. A lot of : work have to be done to package a new version, and a new upstream version : when the last one is not yet finished doesn't help to get the things done. : : That's not an excuse. At all. : : Ok, the maintainer has not fixed the bugs, has not packaged the last : version of it in time, etc, but he has done a great job anyway, and I : still don't see the point of hijacking the package. : : He *hasn't* done a great job.. That would be basically the *point*. : : If the maintainer still wants to maintain it, help him, do NMUs, whatever, : but I'm still looking for one reason you can take over the package against : the maintainer opinion. : : He wants to have his name on the package w/o doing the work : (apparently). That's not maintaining it, regardless of what he'd like : to claim. : : rover, Jose Luis's sponsor and uploader of many of his packages including : bacula, you can blame me also if you want : : We do. : : Enjoy, : : Stephen : : : : : - End forwarded message - Salud, -- Roberto Lumbreras .''`. rover : :' : debian.org Debian Developer `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
* Martin Michlmayr [EMAIL PROTECTED] [2006-05-11 14:20]: I know, tbm tried to build all packages on mips*. It would be intersting to know, how other architectures behave. Also i have not seen any comments from doko yet. I built mips and amd64, and in the mean time also powerpc and most of sparc. What still needs to be done (on all architectures) is to find packages that build-depend on a specifc version of GCC, find out why they do this and see if GCC 4.1 works. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula
* Roberto Lumbreras ([EMAIL PROTECTED]) wrote: Speaking about your mail, I think it's your opinion, mine is different. Sure, but you're looking through some very rosy glasses. Jose Luis doesn't want just his name in some place, he has worked a lot in bacula in the past, and I don't know why he can't remain as maintainer or co-maitainer if he is going to work on it again. You don't get to rest on your laurels in Debian. Especially when it's been over a year. Obviuosly if he is unable to maitain it or work on it, it should orphan the package, but it seems that things are different. That would be exactly the problem- he wants to remain as maintainer or co-maintainer yet has shown nothing to indicate that he's going to work on it again. Not only that but he's trying to refuse work done by others (John) which is clearly in the best interest of Debian and its users (like, I dunno, getting bacula into a state where it can get back into testing...). Besides, Jose Luis will still be able to help with bacula, if he really wants to, by doing bug triage, submitting patches, etc. I fully agree with John's statement though- based on the state which bacula was in and the things which were done in it that were *clearly* policy violations, Jose Luis' contributions need to be checked before being committed. This is something that anyone sponsoring anyone's packages *should* have been doing already. Unfortunately, that part seems to have been forgotten by some. Enjoy, Stephen signature.asc Description: Digital signature
Processed: track GCC 4.1 bugs; part 2/4
Processing commands for [EMAIL PROTECTED]: block 366820 by 357961 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 356304 356366 356370 356436 356439 356444 356455 356517 356522 356540 356564 356583 356597 356598 356636 356646 356679 356691 356878 356892 356968 356970 356971 356980 357056 357057 357084 357182 357317 357334 357339 357359 357380 357401 357408 357447 357455 357490 357552 357557 357566 357644 357656 357659 357687 357720 357748 357774 357863 361766 Blocking bugs added: 357961 block 366820 by 357962 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 356304 356366 356370 356436 356439 356444 356455 356517 356522 356540 356564 356583 356597 356598 356636 356646 356679 356691 356878 356892 356968 356970 356971 356980 357056 357057 357084 357182 357317 357334 357339 357359 357380 357401 357408 357447 357455 357490 357552 357557 357566 357644 357656 357659 357687 357720 357748 357774 357863 357961 361766 Blocking bugs added: 357962 block 366820 by 357964 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 356304 356366 356370 356436 356439 356444 356455 356517 356522 356540 356564 356583 356597 356598 356636 356646 356679 356691 356878 356892 356968 356970 356971 356980 357056 357057 357084 357182 357317 357334 357339 357359 357380 357401 357408 357447 357455 357490 357552 357557 357566 357644 357656 357659 357687 357720 357748 357774 357863 357961 357962 361766 Blocking bugs added: 357964 block 366820 by 357996 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 356304 356366 356370 356436 356439 356444 356455 356517 356522 356540 356564 356583 356597 356598 356636 356646 356679 356691 356878 356892 356968 356970 356971 356980 357056 357057 357084 357182 357317 357334 357339 357359 357380 357401 357408 357447 357455 357490 357552 357557 357566 357644 357656 357659 357687 357720 357748 357774 357863 357961 357962 357964 361766 Blocking bugs added: 357996 block 366820 by 358075 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 356304 356366 356370 356436 356439 356444 356455 356517 356522 356540 356564 356583 356597 356598 356636 356646 356679 356691 356878 356892 356968 356970 356971 356980 357056 357057 357084 357182 357317 357334 357339 357359 357380 357401 357408 357447 357455 357490 357552 357557 357566 357644 357656 357659 357687 357720 357748 357774 357863 357961 357962 357964 357996 361766 Blocking bugs added: 358075 block 366820 by 358207 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 356304 356366 356370 356436 356439 356444 356455 356517 356522 356540 356564 356583 356597 356598 356636 356646 356679 356691 356878 356892 356968 356970 356971 356980 357056 357057 357084 357182 357317 357334 357339 357359 357380 357401 357408 357447 357455 357490 357552 357557 357566 357644 357656 357659 357687 357720 357748 357774 357863 357961 357962 357964 357996 358075 361766 Blocking bugs added: 358207 block 366820 by 358212 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 356304 356366 356370 356436 356439 356444 356455 356517 356522 356540 356564 356583 356597 356598 356636 356646 356679 356691 356878 356892 356968 356970 356971 356980 357056 357057 357084 357182 357317 357334 357339 357359 357380 357401 357408 357447 357455 357490 357552 357557 357566 357644 357656 357659 357687 357720 357748 357774 357863 357961 357962 357964 357996 358075 358207 361766 Blocking bugs added: 358212 block 366820 by 358277 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 356304 356366 356370 356436 356439 356444 356455 356517 356522 356540 356564 356583 356597 356598 356636 356646 356679 356691 356878 356892 356968 356970 356971 356980 357056 357057 357084 357182 357317 357334 357339 357359 357380 357401 357408 357447 357455 357490 357552 357557 357566 357644 357656 357659 357687 357720
Processed: track GCC 4.1 bugs; part 1/4
Processing commands for [EMAIL PROTECTED]: block 366820 by 355163 Bug#366820: Transition to GCC 4.1 for etch Was not blocked by any bugs. Blocking bugs added: 355163 block 366820 by 355352 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 Blocking bugs added: 355352 block 366820 by 355396 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 Blocking bugs added: 355396 block 366820 by 355598 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 Blocking bugs added: 355598 block 366820 by 355841 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 Blocking bugs added: 355841 block 366820 by 355983 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 Blocking bugs added: 355983 block 366820 by 355989 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 Blocking bugs added: 355989 block 366820 by 355997 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 Blocking bugs added: 355997 block 366820 by 356004 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 Blocking bugs added: 356004 block 366820 by 356093 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 Blocking bugs added: 356093 block 366820 by 356109 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 Blocking bugs added: 356109 block 366820 by 361766 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 Blocking bugs added: 361766 block 366820 by 356110 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 361766 Blocking bugs added: 356110 block 366820 by 356116 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 361766 Blocking bugs added: 356116 block 366820 by 356160 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 361766 Blocking bugs added: 356160 block 366820 by 356228 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 356160 361766 Blocking bugs added: 356228 block 366820 by 356232 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 356160 356228 361766 Blocking bugs added: 356232 block 366820 by 356238 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 356160 356228 356232 361766 Blocking bugs added: 356238 block 366820 by 356246 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 356160 356228 356232 356238 361766 Blocking bugs added: 356246 block 366820 by 356248 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 356160 356228 356232 356238 356246 361766 Blocking bugs added: 356248 block 366820 by 356303 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 361766 Blocking bugs added: 356303 block 366820 by 356304 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 361766 Blocking bugs added: 356304 block 366820 by 356366 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 356304 361766 Blocking bugs added: 356366 block 366820 by 356370 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 356304 356366 361766 Blocking bugs added: 356370 block 366820 by 356436 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 356304 356366 356370 361766 Blocking bugs added: 356436 block 366820 by
Processed: gcc 4.1
Processing commands for [EMAIL PROTECTED]: block 366820 by 366821 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 275774 355163 355165 355189 355325 355326 355352 355396 355463 355598 355599 355663 355738 355739 355741 355744 355841 355980 355983 355986 355988 355989 355990 355992 355993 355996 355997 355998 356003 356004 356093 356098 356100 356109 356110 356111 356113 356115 356116 356121 356153 356155 356156 356157 356159 356160 356161 356163 356168 356169 356170 356171 356173 356174 356175 356176 356228 356229 356232 356233 356234 356238 356240 356241 356242 356244 356245 356246 356248 356303 356304 356305 356321 356322 356323 356324 356361 356362 356366 356367 356370 356374 356405 356422 356423 356424 356425 356428 356436 356439 356440 356442 356444 356445 356453 356455 356516 356517 356522 356540 356546 356549 356564 356570 356574 356579 356582 356583 356585 356590 356592 356597 356598 356601 356606 356611 356620 356634 356636 356646 356679 356684 356691 356767 356875 356878 356881 356892 356893 356964 356965 356967 356968 356970 356971 356972 356979 356980 357056 357057 357059 357061 357064 357070 357084 357096 357111 357112 357113 357117 357119 357182 357184 357186 357189 357190 357316 357317 357322 357324 357325 357328 357334 357335 357339 357340 357357 357358 357359 357360 357376 357380 357382 357383 357401 357402 357403 357404 357408 357447 357455 357467 357476 357478 357479 357481 357483 357490 357513 357552 357555 357556 357557 357558 357565 357566 357600 357601 357614 357640 357644 357648 357651 357656 357659 357687 357710 357711 357717 357720 357748 357750 357770 357774 357789 357810 357825 357849 357861 357863 357864 357866 357897 357901 357959 357960 357961 357962 357964 357967 357995 357996 358053 358062 358068 358069 358074 358075 358077 358087 358090 358096 358206 358207 358208 358212 358214 358218 358219 358221 358228 358240 358243 358259 358261 358263 358271 358277 358280 358281 358282 358284 358285 358286 358287 358289 358290 358291 358292 358293 358294 358298 358300 358301 358449 358542 358582 358591 358643 358644 358650 358881 358884 358886 361331 361333 361334 361335 361336 361389 361396 361766 364814 Blocking bugs added: 366821 block 366820 by 366753 Bug#366820: Transition to GCC 4.1 for etch Was blocked by: 275774 355163 355165 355189 355325 355326 355352 355396 355463 355598 355599 355663 355738 355739 355741 355744 355841 355980 355983 355986 355988 355989 355990 355992 355993 355996 355997 355998 356003 356004 356093 356098 356100 356109 356110 356111 356113 356115 356116 356121 356153 356155 356156 356157 356159 356160 356161 356163 356168 356169 356170 356171 356173 356174 356175 356176 356228 356229 356232 356233 356234 356238 356240 356241 356242 356244 356245 356246 356248 356303 356304 356305 356321 356322 356323 356324 356361 356362 356366 356367 356370 356374 356405 356422 356423 356424 356425 356428 356436 356439 356440 356442 356444 356445 356453 356455 356516 356517 356522 356540 356546 356549 356564 356570 356574 356579 356582 356583 356585 356590 356592 356597 356598 356601 356606 356611 356620 356634 356636 356646 356679 356684 356691 356767 356875 356878 356881 356892 356893 356964 356965 356967 356968 356970 356971 356972 356979 356980 357056 357057 357059 357061 357064 357070 357084 357096 357111 357112 357113 357117 357119 357182 357184 357186 357189 357190 357316 357317 357322 357324 357325 357328 357334 357335 357339 357340 357357 357358 357359 357360 357376 357380 357382 357383 357401 357402 357403 357404 357408 357447 357455 357467 357476 357478 357479 357481 357483 357490 357513 357552 357555 357556 357557 357558 357565 357566 357600 357601 357614 357640 357644 357648 357651 357656 357659 357687 357710 357711 357717 357720 357748 357750 357770 357774 357789 357810 357825 357849 357861 357863 357864 357866 357897 357901 357959 357960 357961 357962 357964 357967 357995 357996 358053 358062 358068 358069 358074 358075 358077 358087 358090 358096 358206 358207 358208 358212 358214 358218 358219 358221 358228 358240 358243 358259 358261 358263 358271 358277 358280 358281 358282 358284 358285 358286 358287 358289 358290 358291 358292 358293 358294 358298 358300 358301 358449 358542 358582 358591 358643 358644 358650 358881 358884 358886 361331 361333 361334 361335 361336 361389 361396 361766 364814 366821 Blocking bugs added: 366753 -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Auto-trace
Martin, Is this auto-trace program available for public use? Thanks, Stan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
* Andreas Barth [EMAIL PROTECTED] [2006-05-11 10:00]: One: What's the easiest way to extract the list of gcc-4.1 related bugs from the BTS? There is none I know - I asked Martin already yesterday on IRC to provide such a way. I've created the following meta bug: 366820 -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#366780: ITP: summain -- compute and verify file checksums
Lars Wirzenius [EMAIL PROTECTED] writes: A checksum is a number that identifies the contents of a file: if the contents change, so does the checksum. If you create a checksum before you burn a CD, when you know the files are correct, you can easily check the CD at any time: just compute the checksum again and see if they have changed. . summain computes and checks files against such checksums. It supports both MD5 and SHA-1 checksums, using formats compatible with the md5sum and sha1sum utilities, both for reading and writing. In addition, it can read and verify checksums from Debian .dsc, .changes, and Sources files. It's not clear to me, from the description, what the program does that the md5sum and sha1sum utilities do not. -- If a person keeps faithfully busy each hour of the working day, he can count on waking up some morning to find himself one of the competent ones of his generation. --William James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
On 5/11/06, Martin Michlmayr [EMAIL PROTECTED] wrote: * Andreas Barth [EMAIL PROTECTED] [2006-05-11 10:00]: One: What's the easiest way to extract the list of gcc-4.1 related bugs from the BTS? There is none I know - I asked Martin already yesterday on IRC to provide such a way. I've created the following meta bug: 366820 Hi Martin, Why you did this metabug thing, and not just usertagged the bugs ? The results seems to be similar, but i don't think that a metabug can be managed by email, usertags are. regards, -- stratus
Re: gcc 4.1 or not
* Gustavo Franco [EMAIL PROTECTED] [2006-05-11 11:20]: Why you did this metabug thing, and not just usertagged the bugs ? The results seems to be similar, but i don't think that a metabug can be managed by email, usertags are. What can not be managed by email? -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
Package: wnpp Severity: wishlist Owner: Kari Pahula [EMAIL PROTECTED] * Package name: cxxtools Version : 1.4.1pre2 Upstream Author : Tommi Mäkitalo [EMAIL PROTECTED] * URL : http://www.tntnet.org/ * License : GPL v2 or later Programming Lang: C++ Description : library of unrelated but useful C++ classes cxxtools contains an argument-parser, a base-64 encoder/decoder, a C++ interface to iconv, md5-stream for easy MD5 calculation, threading classes, socket classes, a dynamic exception-safe buffer, a wrapper for dlopen/dlsym, a pool template (e.g., for a connection pool in a multi-threaded application), query_params, and a class for easy parsing of CGI parameters (GET and POST) in a CGI program. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.6 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
also sprach Kari Pahula [EMAIL PROTECTED] [2006.05.11.1535 +0200]: * License : GPL v2 or later That will make it pretty useless for non-GPL applications. Why don't you choose (if possible) a less viral licence? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system women love us for our defects. if we have enough of them, they will forgive us everything, even our gigantic intellects. -- oscar wilde signature.asc Description: Digital signature (GPG/PGP)
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote: also sprach Kari Pahula [EMAIL PROTECTED] [2006.05.11.1535 +0200]: * License : GPL v2 or later That will make it pretty useless for non-GPL applications. Non-GPL compatible applications, you mean? Why don't you choose (if possible) a less viral licence? Wow. First off, Kari does not appear to be upstream, so who are you addressing? Seconds, since when do we consider the GPL to be viral? Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
Michael Banck [EMAIL PROTECTED] wrote: On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote: also sprach Kari Pahula [EMAIL PROTECTED] [2006.05.11.1535 +0200]: * License : GPL v2 or later That will make it pretty useless for non-GPL applications. Non-GPL compatible applications, you mean? Which non-GPL license can I choose for a software that uses this library? Seconds, since when do we consider the GPL to be viral? Don't know about you, but the FSF does - it has created the LGPL because of this. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
Frank Küster wrote: Michael Banck [EMAIL PROTECTED] wrote: On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote: also sprach Kari Pahula [EMAIL PROTECTED] [2006.05.11.1535 +0200]: * License : GPL v2 or later That will make it pretty useless for non-GPL applications. Non-GPL compatible applications, you mean? Which non-GPL license can I choose for a software that uses this library? BSD should be fine, for example. Seconds, since when do we consider the GPL to be viral? Don't know about you, but the FSF does - it has created the LGPL because of this. http://www.gnu.org/licenses/why-not-lgpl.html Thiemo
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
Simon Josefsson [EMAIL PROTECTED] wrote: Frank Küster [EMAIL PROTECTED] writes: Michael Banck [EMAIL PROTECTED] wrote: On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote: also sprach Kari Pahula [EMAIL PROTECTED] [2006.05.11.1535 +0200]: * License : GPL v2 or later That will make it pretty useless for non-GPL applications. Non-GPL compatible applications, you mean? Which non-GPL license can I choose for a software that uses this library? Any license that is compatible with the GPL, such as the revised BSD license. But the software is a derivative work of the GPL. Doesn't it need to be licensed under the GPL, too? I thought the question of GPL compatibility is the other way round: the BSD license is GPL-compatible because I can use BSD-licensed code in a GPL project. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
Frank Küster [EMAIL PROTECTED] writes: Michael Banck [EMAIL PROTECTED] wrote: On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote: also sprach Kari Pahula [EMAIL PROTECTED] [2006.05.11.1535 +0200]: * License : GPL v2 or later That will make it pretty useless for non-GPL applications. Non-GPL compatible applications, you mean? Which non-GPL license can I choose for a software that uses this library? Any license that is compatible with the GPL, such as the revised BSD license. Seconds, since when do we consider the GPL to be viral? Don't know about you, but the FSF does - it has created the LGPL because of this. That doesn't mean libraries shouldn't be licensed under the GPL, see http://www.gnu.org/licenses/why-not-lgpl.html. /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
Simon Josefsson [EMAIL PROTECTED] wrote: That will make it pretty useless for non-GPL applications. [...] As a derived work of a GPL'd work, the aggregate is covered by the GPL license. So the aggregate, in other words the *application* would be a GPL-application, right? Which makes the above sentence correct. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
Frank Küster wrote: Simon Josefsson [EMAIL PROTECTED] wrote: Frank Küster [EMAIL PROTECTED] writes: Michael Banck [EMAIL PROTECTED] wrote: On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote: also sprach Kari Pahula [EMAIL PROTECTED] [2006.05.11.1535 +0200]: * License : GPL v2 or later That will make it pretty useless for non-GPL applications. Non-GPL compatible applications, you mean? Which non-GPL license can I choose for a software that uses this library? Any license that is compatible with the GPL, such as the revised BSD license. But the software is a derivative work of the GPL. Doesn't it need to be licensed under the GPL, too? It likely is an aggregation of works. Distributing the whole will need to adhere to all licenses of all parts involved, and the license for the aggregate will need to be compatible to them as well (for example public domain). IANAL, Thiemo
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
Frank Küster [EMAIL PROTECTED] writes: Simon Josefsson [EMAIL PROTECTED] wrote: Frank Küster [EMAIL PROTECTED] writes: Michael Banck [EMAIL PROTECTED] wrote: On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote: also sprach Kari Pahula [EMAIL PROTECTED] [2006.05.11.1535 +0200]: * License : GPL v2 or later That will make it pretty useless for non-GPL applications. Non-GPL compatible applications, you mean? Which non-GPL license can I choose for a software that uses this library? Any license that is compatible with the GPL, such as the revised BSD license. But the software is a derivative work of the GPL. Doesn't it need to be licensed under the GPL, too? As a derived work of a GPL'd work, the aggregate is covered by the GPL license. But the source code files doesn't have to be licensed under the GPL. If someone replace the calls to the GPL'd library in the BSD code with calls to a BSD library, they don't have to distribute the new package under the GPL. /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: screenshot with package description
Sorry for the late answer... 3) How would synaptic (for instance) know which packages have which images? I suppose you would need a Packages-like file with this information... (This will not be incorporated in the main Packages file... not before this idea being proved as possible and usefull)... I am coding since around 4 years a X-ControllCenter (without the need of KDE or GNOME, ist better then Yast2 :-) ) and the integrated Package installer (using apt-get) use the same directory structure as the packages but while the packages are using for example ftp://ftp.debian.org/debian stable main this pics are using ftp://ftp.debian.org/debian-pics stable main Insteed of the DEB, there is a configfile with all required infos like 1) Larger description 2) link to logo 3) link to screenshoot1 + short description1 link to screenshoot2 + short description2 ... Which mean, no one need to download the whole stuff, only the files someone is interested. On the other hand, I have DEB's from each Debian Package, which can be installed seperatly in /var/lib/apt-pics/ and it create the Directory structure... Its like apt-get install package-aptpics And the idea to have 29 TAR-Archives with the PICS of immense size is not acceptable for me. Better to create 15.000 additional DEB's with pics and additonal descriptoons (per screenshoot) and make Meta packages to instal with apt-get install aptpics-all (for installing the whole pics-archive) or apt-get install aptpics-x (for installing per LETTER archive) Think about it... For this time it is just an idea. Greetings Michelle Konzack -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PDF files and dh_compress
On Thu, May 11, 2006 at 02:21:37AM +0200, Juliusz Chroboczek wrote: I am strongly against compressing PDFs To add insult to injury, PDF 1.5 introduces ``object streams'' which allow compressing arbitrarily long chunks of a PDF file without giving up the random-access properties of PDF. All current Free PDF readers grok PDF 1.5, although as far as I know no Free software can produce PDF 1.5 object streams. Usually, when I get problems with xpdf on a PDF, it is a PDF 1.5. Either it simply doesn't work, or very slowly, or text search doesn't work in the PDF. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
On 5/11/06, Martin Michlmayr [EMAIL PROTECTED] wrote: * Gustavo Franco [EMAIL PROTECTED] [2006-05-11 11:20]: Why you did this metabug thing, and not just usertagged the bugs ? The results seems to be similar, but i don't think that a metabug can be managed by email, usertags are. What can not be managed by email? The metabug itself, AFAIK just individual bugs can be managed, no? Thanks, -- stratus
Re: gcc 4.1 or not
* Gustavo Franco [EMAIL PROTECTED] [2006-05-11 14:39]: Why you did this metabug thing, and not just usertagged the bugs ? The results seems to be similar, but i don't think that a metabug can be managed by email, usertags are. What can not be managed by email? The metabug itself, AFAIK just individual bugs can be managed, no? Well, I've no idea what you mean by manage. You can add new blockers to the meta bug and remove them, which is all I want to do. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366859: ITP: libwiki-toolkit-perl -- A toolkit for building Wikis
Package: wnpp Severity: wishlist Owner: Dominic Hargreaves [EMAIL PROTECTED] * Package name: libwiki-toolkit-perl Version : 0.70 Upstream Author : The Wiki::Toolkit team [EMAIL PROTECTED] * URL : http://www.wiki-toolkit.org/ * License : Dual GPL/Artistic Description : A toolkit for building Wikis Helps you develop Wikis quickly by taking care of the boring bits for you. You will still need to write some code - this isn't an instant Wiki. This was previously CGI::Wiki and referred to in wnpp bug #280318. 0.70 hasn't yet been released but will be the next stable release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366862: ITP: libwiki-toolkit-formatter-usemod-perl -- UseModWiki-style formatting for Wiki::Toolkit
Package: wnpp Severity: wishlist Owner: Dominic Hargreaves [EMAIL PROTECTED] * Package name: libwiki-toolkit-formatter-usemod-perl Version : 0.19 Upstream Author : The Wiki::Toolkit project [EMAIL PROTECTED] * URL : http://www.wiki-toolkit.org/ * License : Dual GPL/Artistic Description : UseModWiki-style formatting for Wiki::Toolkit A formatter backend for CGI::Wiki that supports UseMod-style formatting. This used to be CGI::Wiki::Formatter::Usemod which was referred to in wnpp bug #280952. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
On 5/11/06, Martin Michlmayr [EMAIL PROTECTED] wrote: * Gustavo Franco [EMAIL PROTECTED] [2006-05-11 14:39]: Why you did this metabug thing, and not just usertagged the bugs ? The results seems to be similar, but i don't think that a metabug can be managed by email, usertags are. What can not be managed by email? The metabug itself, AFAIK just individual bugs can be managed, no? Well, I've no idea what you mean by manage. You can add new blockers to the meta bug and remove them, which is all I want to do. by mail, really ? Well, that's weird. Why we've usertags[0] too ? [0] = http://wiki.debian.org/bugs.debian.org/usertags thanks, -- stratus
Processed: closing dead old bugs
Processing commands for [EMAIL PROTECTED]: # This bug is from 2000, and the submitter failed to give the requested # followup information. Furthermore devfs is dead meat. close 78282 Bug#78282: DevFS incompatabilities 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug closed, send any further explanations to Eric Windisch [EMAIL PROTECTED] # This bug has been unreproducible since Nov. 2000 and was reported against # potato close 77570 Bug#77570: corrupted /var/lib/dpkg/status file 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug closed, send any further explanations to Roland Bauerschmidt [EMAIL PROTECTED] # Another bug on upgrade to potato, which means it will *never* be fixed. # Hasn't been reproducible in recent years close 60573 Bug#60573: upgrade to potato broke permissions on /dev/null and /tmp 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug closed, send any further explanations to der.hans [EMAIL PROTECTED] # Per-file md5sums are not mandated by policy and may be undesirable, # as per the bug discussion; this bug is invalid. close 223772 Bug#223772: general: no md5sums for many packages (e.g. bc) 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug closed, send any further explanations to [EMAIL PROTECTED] # No information from submitter since request in Sept. 2004 close 273936 Bug#273936: bug report bad monitor 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug closed, send any further explanations to [EMAIL PROTECTED] [EMAIL PROTECTED] thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
On Thu, May 11, 2006 at 02:20:29PM +0200, Martin Michlmayr wrote: * Martin Zobel-Helas [EMAIL PROTECTED] [2006-05-11 13:38]: I know, tbm tried to build all packages on mips*. It would be intersting to know, how other architectures behave. Also i have not seen any comments from doko yet. I built mips and amd64, and in the mean time also powerpc and most of sparc. Apparently hppa has some problems but I don't know any details: 22:10 vorlon also, do you know about the hppa ABI skew issues? 22:12 vorlon libstdc++6 from gcc-4.1 source doesn't work with gcc-4.0 as a compiler, because of a libgcc_s soname change This is a problem, caused by the *introduction* of gcc-4.1 into the archive, which will be fixed (well, fixable) when gcc-4.1 is the default compiler. So this is a reason for getting gcc-4.1 as default, not against it. (It's also another pool of porters you can tap to do NMUs for the switch, which is why I mentioned it to you :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
On Thu, May 11, 2006 at 10:59:27AM +0200, Mike Hommey wrote: On Thu, May 11, 2006 at 10:09:11AM +0200, Domenico Andreoli [EMAIL PROTECTED] wrote: On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote: there were some requests, e.g. by Martin Michlmayr to the release team whether we could switch gcc to 4.1 or not for etch. As we're heading to what about the transition to python 2.4? is it going to start or etch is going to ship with 2.3? what about the transition to libgnutls13 ? I noticed yesterday when debootstraping that we get libgnutls11, 12 AND 13 installed by default. Do we really need that many libgnutls ? I don't see anything at all in the reverse-deps that would explain libgnutls11 being pulled in by debootstrap. Is it still hard-coded in a package list somewhere in the version of debootstrap you're using? Anyway, it would be nice to get libgnutls11 out of etch completely, but AFAICT it should at least have been removed from the list of base libs already. If you wanted to file bugs and NMU (*not* 0-day NMUs) to take it the rest of the way, that'd be great. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
I have created a new page in the wiki to track info and status
http://wiki.debian.org/multiarch
I looked at the upstream standards proposal:
http://lackof.org/taggart/hacking/multiarch/
It's good.
I am particularly pleased by the specification:
The terms arch and os represent the Architecture and Operating System
as defined and provided by config.guess.
It is crucial that this naming be entirely standardized. This *should*
be sufficient. Is it sufficient? Cases where it would not be sufficient
would be the following:
(1) Cases where config.guess reports the same name for functionally different
systems, such as the two MIPS ABIs. This should be considered a bug in
config.guess, plain and simple.
(2) Cases where config.guess gives noncanonical results. This should not
happen, and if it does it's a bug in config.guess.
(3) Cases where the *manufacturer name* is the sole discriminator between
two functionally different systems. While this *is* the case for some legacy
UNIX systems, I believe it is not the case for any system which might consider
using the FHS or multiarch, or indeed for any common system, so this is
probably not important. However, it could be avoided by simply using the
full canonical system name. However, there are arguments against that,
notably the use of the 'manufacturer' slot in unreliable and inconsistent ways
by Linux distribution vendors, despite no real platform difference.
(4) There is an ambiguity in the specification. config.sub notes:
# The goal of this file is to map all the various variations of a given
# machine specification into a single specification in the form:
# CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
# or in some cases, the newer four-part form:
# CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
I believe that when it is the output of config.guess, the
KERNEL-OPERATING_SYSTEM should be considered the $os portion in a
multiarch implementation. This will be necessary to discriminate
between different systems. This would be the natural result of the
naive implementation (which doesn't consider the existence of four-part
canonical system names) anyway.
(5) config.guess has been known to vary its output from system to system
when perhaps it shouldn't. :-) It will be necessary to standardize the
canonical system names for multiarch in this case: it is crucial that we not
have (for instance) i486-linux and i486-linux-gnu directories floating around
separately. Accordingly, I suggest that the upstream proposals should
*specify* the expected $arch-$os results from config.guess for the common,
existing platforms.
-
There is yet another issue with the $arch portion of the canonical system
name: chips which are upgrades of other chips. For instance, Fedora will
give you 'i686', while Debian will give you 'i486'. This will (and should)
result in two different directories -- different multiarch variants.
However, programs compiled for i486 will run on i686.
This raises fairly complex program interpreter issues for the simplest case
(intercompatibility between Debian and RedHat on x86).
Software must expect to be able to install to the i486-linux-gnu directories
and function immediately, even on a natively i686-linux-gnu system.
Likewise software should be able to install to the i686-linux-gnu directories
and function immediately if the chip is actually an i686, even on an
i486-linux-gnu system.
Now, this is in fact trivial with the current non-multiarch situation. We
must be careful not to break it with multiarch! Perhaps an x86 annexe to
the specifications would help?
I *believe* that this can be handled as follows:
(1) Specify a list of arch-os pairs which are ABI-compatible
(i486-linux-gnu, i586-linux-gnu, i686-linux-gnu perhaps)
(2) Rework the program interpreter to search through all three arch-os pairs,
starting with the highest one which the actual chip supports.
However, this all seems to duplicate the existing functionality with
/usr/lib/tls/{i486, i586, i686}. But perhaps it should be considered
to be replacing that functionality? That seems like a wise way to go,
actually.
If not, it may be simpler to just specify outright that all x86 machines
should use i486-linux-gnu, NOT i686-linux-gnu, regardless of what
config.guess thinks, and that libraries compiled for the higher chips
should use the subdirectories.
Please consider the x86 intercompatibility case before making any final
proposals. It's very important. :-)
--Nathanael Nerode
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python version?
On Thu, 11 May 2006, Andreas Barth wrote: * Ganesan Rajagopal ([EMAIL PROTECTED]) [060511 14:12]: Andreas Barth [EMAIL PROTECTED] writes: An upload of python-defaults switching to 2.4 has been repeatedly asked during the last months, and it was ignored by the maintainer. I'm not aware of anything preventing this upload currently. The maintainer is not ignoring it, but the transition needs to have some issues fixed first. (And if you want to discuss aboutt hat, please leave -release out of the discussion. :) The last time this came up in, the majority view was to transition to 2.4 as default the old way rather than keeping it pending for so long. I'm not really aware of the python issues. Are there enough python people on Debconf to make an ad-hoc BoF about python? There are slots available for this; if someone wants to organize this, let me know, and I'll give you a slot. Don Armstrong -- You could say she lived on the edge... Well, maybe not exactly on the edge, just close enough to watch other people fall off. -- hugh macleod http://www.gapingvoid.com/batch8.htm http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
also sprach Michael Banck [EMAIL PROTECTED] [2006.05.11.1702 +0200]: That will make it pretty useless for non-GPL applications. Non-GPL compatible applications, you mean? Yeah well. IMHO that pretty much excludes all sensible licences. Why don't you choose (if possible) a less viral licence? Wow. First off, Kari does not appear to be upstream, so who are you addressing? Him. I think he's in the better position to talk to upstream about it. Or in fact not make the package. Seconds, since when do we consider the GPL to be viral? I have always done so and never used the GPL for any of my work. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system unix, because rebooting is for adding new hardware. signature.asc Description: Digital signature (GPG/PGP)
Re: gcc 4.1 or not
* Gustavo Franco [EMAIL PROTECTED] [2006-05-11 15:05]: Well, I've no idea what you mean by manage. You can add new blockers to the meta bug and remove them, which is all I want to do. by mail, really ? Yeah, block xx by foo. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula
On Thu, May 11, 2006 at 08:37:35AM -0400, Stephen Frost wrote: : * Roberto Lumbreras ([EMAIL PROTECTED]) wrote: : Speaking about your mail, I think it's your opinion, mine is different. : : Sure, but you're looking through some very rosy glasses. hey, I've tried to be fair... : Jose Luis doesn't want just his name in some place, he has worked a lot : in bacula in the past, and I don't know why he can't remain as : maintainer or co-maitainer if he is going to work on it again. : : You don't get to rest on your laurels in Debian. Especially when it's : been over a year. don't be so rude with Jose Luis, and it's not him the only person to blame, he is not the only person who can do an upload of a package (in fact, he can't) : Obviuosly if he is unable to maitain it or work on it, it should orphan : the package, but it seems that things are different. : : That would be exactly the problem- he wants to remain as maintainer or : co-maintainer yet has shown nothing to indicate that he's going to work : on it again. Not only that but he's trying to refuse work done by others : (John) which is clearly in the best interest of Debian and its users : (like, I dunno, getting bacula into a state where it can get back into : testing...). He has packaged the last version of bacula, and it is not uploaded because it's not ready, then a new version was showed up... he has a personal apt repository that users from bacula mailing list uses, and packages (not yet finished) in sourceforge... so is it clear for you that he is not going to work on it again? not for me, I think he was working, then the John started to do NMUs, and refusing to be co-maintainer with Jose Luis. After John has refused to do that, then Jose Luis has done the same. I think it's a kids game :-( : Besides, Jose Luis will still be able to help with bacula, if he really : wants to, by doing bug triage, submitting patches, etc. I fully agree : with John's statement though- based on the state which bacula was in and : the things which were done in it that were *clearly* policy violations, : Jose Luis' contributions need to be checked before being committed. : : This is something that anyone sponsoring anyone's packages *should* have : been doing already. Unfortunately, that part seems to have been : forgotten by some. Hey, again, don't be so rude... some of those serious policy violations are things like mistakes erasing logfiles and editing conffiles that couldn't be done in another way. I don't even remember if it was me who uploaded that version of bacula doing so evil things... but if it was me a year ago, it was because another version was supposed to come soon fixing that and then it didn't happen. And I've worked tons of hours even days reviewing Jose Luis packages, maybe I'm not god but please don't say things so easily. : Enjoy, : : Stephen Salud, -- Roberto Lumbreras .''`. rover : :' : debian.org Debian Developer `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On Thu, 11 May 2006, [EMAIL PROTECTED] wrote: The terms arch and os represent the Architecture and Operating System as defined and provided by config.guess. Well, config.sub is the one whose function is to provide canonical names, config.guess might not do so for one reason or another (but it usually does provide canonical names, at least when it can). I'd say config.sub $(config.guess) is better than just config.guess. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula
On Thu, May 11, 2006 at 09:30:40PM +0200, Roberto Lumbreras wrote: He has packaged the last version of bacula, and it is not uploaded because it's not ready, then a new version was showed up... he has a personal apt repository that users from bacula mailing list uses, and packages (not yet finished) in sourceforge... so is it clear for you that he is not going to work on it again? not for me, I think he was working, then the John started to do NMUs, and refusing to be co-maintainer with Jose Luis. After John has refused to do that, then Jose Luis has done the same. I think it's a kids game :-( John has managed to not only update to the latest upstream version in his upload, but he's also managed to fix 24 bugs by my count. It is notable that he has managed to achieve so much while Jose struggled just to update to the new version. Since John has said he's open to having an alioth group maintain bacula, with Jose on the team, I hope Jose chooses to actively work with everyone to get the help, and apparently training, that he needs to manage something this complicated. I got tons of help from people both in and out of Debian while working on Xorg, and I still get it almost daily. There's no shame in doing so, and Jose should take advantage of it to become a stronger maintainer. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
On Thu, May 11, 2006 at 11:34:50AM -0700, Steve Langasek [EMAIL PROTECTED] wrote: On Thu, May 11, 2006 at 10:59:27AM +0200, Mike Hommey wrote: On Thu, May 11, 2006 at 10:09:11AM +0200, Domenico Andreoli [EMAIL PROTECTED] wrote: On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote: there were some requests, e.g. by Martin Michlmayr to the release team whether we could switch gcc to 4.1 or not for etch. As we're heading to what about the transition to python 2.4? is it going to start or etch is going to ship with 2.3? what about the transition to libgnutls13 ? I noticed yesterday when debootstraping that we get libgnutls11, 12 AND 13 installed by default. Do we really need that many libgnutls ? I don't see anything at all in the reverse-deps that would explain libgnutls11 being pulled in by debootstrap. Is it still hard-coded in a package list somewhere in the version of debootstrap you're using? # grep-available -s Package -s Priority -P libgnutls (...) Package: libgnutls12 Priority: standard Package: libgnutls13 Priority: important Package: libgnutls11 Priority: important Anyway, it would be nice to get libgnutls11 out of etch completely, but AFAICT it should at least have been removed from the list of base libs already. If you wanted to file bugs and NMU (*not* 0-day NMUs) to take it the rest of the way, that'd be great. :) I promise I'll deal with that as soon as I'll have time. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
On Thu, May 11, 2006 at 09:56:04PM +0200, Mike Hommey wrote: On Thu, May 11, 2006 at 11:34:50AM -0700, Steve Langasek [EMAIL PROTECTED] wrote: On Thu, May 11, 2006 at 10:59:27AM +0200, Mike Hommey wrote: On Thu, May 11, 2006 at 10:09:11AM +0200, Domenico Andreoli [EMAIL PROTECTED] wrote: On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote: there were some requests, e.g. by Martin Michlmayr to the release team whether we could switch gcc to 4.1 or not for etch. As we're heading to what about the transition to python 2.4? is it going to start or etch is going to ship with 2.3? what about the transition to libgnutls13 ? I noticed yesterday when debootstraping that we get libgnutls11, 12 AND 13 installed by default. Do we really need that many libgnutls ? I don't see anything at all in the reverse-deps that would explain libgnutls11 being pulled in by debootstrap. Is it still hard-coded in a package list somewhere in the version of debootstrap you're using? # grep-available -s Package -s Priority -P libgnutls (...) Package: libgnutls12 Priority: standard Package: libgnutls13 Priority: important Package: libgnutls11 Priority: important Cool, even better: fixable just by filing a bug on ftp.d.o asking for the priority to be dropped. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Why isn't gnome in testing?
Does anyone know why the binary package gnome is no longer in testing? The source package meta-gnome2 is there Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
Le jeudi 11 mai 2006 à 16:46 +0200, martin f krafft a écrit : also sprach Kari Pahula [EMAIL PROTECTED] [2006.05.11.1535 +0200]: * License : GPL v2 or later That will make it pretty useless for non-GPL applications. Why don't you choose (if possible) a less viral licence? I think this is the whole point of licensing a library under the GPL. There's not much point in using a copyleft if you allow proprietary applications to use the library. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Why isn't gnome in testing?
* Julian Gilbey ([EMAIL PROTECTED]) [060511 22:17]: Does anyone know why the binary package gnome is no longer in testing? The source package meta-gnome2 is there Seems like an accident currently. We're researching the matter. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366879: ITP: libodbc++ -- C++ library for ODBC SQL database access
Package: wnpp
Severity: wishlist
Owner: OndÅej Surý [EMAIL PROTECTED]
* Package name: libodbc++
Version : 0.2.4pre3
Upstream Author : Manush Dodunekov [EMAIL PROTECTED]
* URL : http://libodbcxx.sourceforge.net
* License : LGPL
Programming Lang: C++
Description : C++ library for ODBC SQL database access
Source: libodbc++
Priority: optional
Maintainer: OndÅej Surý [EMAIL PROTECTED]
Build-Depends: debhelper (= 4.0.0), autotools-dev, cdbs, libiodbc2-dev,
doxygen
Standards-Version: 3.6.2
Section: libs
Package: libodbc++-dev
Section: libdevel
Architecture: any
Depends: libodbc++4 (= ${Source-Version})
Description: C++ library for ODBC SQL database access
libodbc++ is a C++ class library for accessing SQL databases.
It is designed with standards in mind, so it provides a subset
of the well-known JDBC 2.0(tm) and runs on top of ODBC on Windows
and Unix/Linux.
.
This package contains the header files and static libraries which is
needed for development.
Package: libodbc++4
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: C++ library for ODBC SQL database access
libodbc++ is a C++ class library for accessing SQL databases.
It is designed with standards in mind, so it provides a subset
of the well-known JDBC 2.0(tm) and runs on top of ODBC on Windows
and Unix/Linux.
.
This package contains the shared libraries.
Package: libodbc++-doc
Architecture: all
Section: doc
Description: C++ library for ODBC SQL database access
libodbc++ is a C++ class library for accessing SQL databases.
It is designed with standards in mind, so it provides a subset
of the well-known JDBC 2.0(tm) and runs on top of ODBC on Windows
and Unix/Linux.
.
This package contains documentation files for the ODBC++ library
functions.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-22-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Re: multiarch status update
Matt Taggart and others [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi debian-devel, For a couple years now a few of us have been talking about an idea called multiarch. This is a way to seamlessly allow support for multiple different binary targets on the same system, for example running both i386-linux-gnu and amd64-linux-gnu binaries on the same system (many other working combinations exist as well). I have created a new page in the wiki to track info and status My thoughts on a few multi-arch concepts. It is important to differentiate between the types of non-native files. There are files that are not native, but are intended to be used by native programs targeting the non-native arch. These include things like arch-specific header files. It almost seems like these should be put in /usr/share/include/$arch-$os/. (where $arch and $os represent the target arch) That is because headers for cross compiling are normally dependent on the target arch, but not the host arch. On the other hand, if we continue that thought process we could end up with all headers and libraries in /usr/share/, which is absurd. Indeed, the current proposal almost seems to be reversing this. Non-target specific libraries and header files remain in $prefix/lib and $prefix/include. It seems to me that libraries and headers that are not target specific are supposed to go in /usr/share. That is because if they are not target specific they are most certainly cross-platform. Hm... This entire concept seems messy. It seems that processors that support multiple architectures, as well as cross compilition are begining to blur the line between /usr and /usr/share. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
[EMAIL PROTECTED] wrote: I have created a new page in the wiki to track info and status http://wiki.debian.org/multiarch I looked at the upstream standards proposal: http://lackof.org/taggart/hacking/multiarch/ It's good. I am particularly pleased by the specification: The terms arch and os represent the Architecture and Operating System as defined and provided by config.guess. It is crucial that this naming be entirely standardized. This *should* be sufficient. Is it sufficient? Cases where it would not be sufficient would be the following: (1) Cases where config.guess reports the same name for functionally different systems, such as the two MIPS ABIs. This should be considered a bug in config.guess, plain and simple. To expand a bit on this, I don't think config.guess is sufficient to handle those cases. E.g. for a MIPS system with 64bit kernel, config.guess will return mips64el-unknown-linux-gnu even when there's only a (little endian) O32 userland installed, but for a 32bit kernel it will be mipsel-unknown-linux-gnu unless the call is prefixed with linux32, which changes the uname, and thus the config.guess output. The endianness is guessed from the defaults of the system compiler (the first cc in $PATH), which is a) not necessarily available, and b) supposed to be exchangable in a full multiarch environment. What's worse, mips64 is a rather entrenched term with inconsistent meanings which cover both the N32 and N64 ABI. A fix to config.guess would AFAICS require to specify a multiarch mode, which changes the output to, say, mipsn32el-unknown-linux-gnu for N32 and to mipsn64-unknown-linux-gnu for N64 (that still doesn't answer the question which ABI would be the native one). But in that case the config.guess can't be the canonical source of information any more. This is not only MIPS-specific, a similiar problem arises e.g. for a ILP32 ABI for x86_64. I think we need a canonical ABI-OS (or ABI-KERNEL-OS ?) table which provides mappings for multiarch-sensitive programs. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: screenshot with package description
On 5/10/06, Michelle Konzack [EMAIL PROTECTED] wrote: Better to create 15.000 additional DEB's with pics and additonal descriptoons (per screenshoot) and make Meta packages to instal with apt-get install aptpics-all (for installing the whole pics-archive) or apt-get install aptpics-x (for installing per LETTER archive) OUCH! This would mean that all of a sudden the 20-30 seconds it takes while 'Reading database...' would suddenly become 45-60 seconds. The TAR archives are a much better idea IMHO. -- Andrew Donnellan http://andrewdonnellan.com http://ajdlinux.blogspot.com Jabber - [EMAIL PROTECTED] --- Member of Linux Australia - http://linux.org.au Debian user - http://debian.org Get free rewards - http://ezyrewards.com/?id=23484 OpenNIC user - http://www.opennic.unrated.net
Re: Intent to hijack Bacula
David Nusinow wrote: On Thu, May 11, 2006 at 09:30:40PM +0200, Roberto Lumbreras wrote: He has packaged the last version of bacula, and it is not uploaded because it's not ready, then a new version was showed up... he has a personal apt repository that users from bacula mailing list uses, and packages (not yet finished) in sourceforge... so is it clear for you that he is not going to work on it again? not for me, I think he was working, then the John started to do NMUs, and refusing to be co-maintainer with Jose Luis. After John has refused to do that, then Jose Luis has done the same. I think it's a kids game :-( John has managed to not only update to the latest upstream version in his upload, but he's also managed to fix 24 bugs by my count. It is notable that he has managed to achieve so much while Jose struggled just to update to the new version. I have been away from home for 20 months; During the latest 3 I have had random hardware errors which I couldn't fix. I have myself fixed in excess of 40 bugs in my packages in the last 48h, when I have been back to speed. So what??? Since John has said he's open to having an alioth group maintain bacula, with Jose on the team, Hmm.. he chose to hijack my package instead. That is *not* collaborative maintenance. I hope Jose chooses to actively work with everyone to get the help, and apparently training, that he needs to manage something this complicated. Sorry, but I fail to see how well you know my work for Debian (three years so far) in order to be able to judge me. Please check your facts before joining a thread this harsh. I got tons of help from people both in and out of Debian while working on Xorg, and I still get it almost daily. There's no shame in doing so, and Jose should take advantage of it to become a stronger maintainer. Correct. That's why I appreciate patches (and even NMUs). This is completely different. Hijacking a package without contacting the maintainer first is against the Developers' Reference and can only be considered a personal attack. I still don't know what is John Goerzen trying to achieve with this. More on this later. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Em Qui, 2006-05-11 às 09:56 +0200, Gabor Gombas escreveu: On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote: Why would that not fly? Both versions of the arch-independent package could be installed at the same time. /usr/share/foo/bar can't point to two different files at the same time, so you can't install multiple package versions containing incompatible /usr/share/foo/bar files. The only way to support your proposal would be to kill the concept of arch-independent packages and make everything arch-dependent. And what if dpkg knows about it and handle arch-independant packages in a different way? In fact, if the system is multiarch, dpkg should have a centralized list of which packages are installed for each architecture and which packages are installed for arch: all... But there's still the problem of arch-independant files inside arch-dependant files (maybe an arch-dependant package should not include arch-indenpendant files at all)... daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula
On Thu, 2006-05-11 at 23:07 +0200, José Luis Tallón wrote: John has managed to not only update to the latest upstream version in his upload, but he's also managed to fix 24 bugs by my count. It is notable that he has managed to achieve so much while Jose struggled just to update to the new version. I have been away from home for 20 months; During the latest 3 I have had random hardware errors which I couldn't fix. Stick to the facts. Bacula was broken, was removed from testing and not updated for very long time. You were not able to do anything with it to get it to better shape. Sorry, but fact that you have been away from home and you have had broken hardware doesn't help our users. If you were not able to fullfill your maintainership duties for 20 months (or so), you should have stepped down much earlier and ask for help. And you started to work on bacula again only after John announced hijack...well, I don't believe in coincidences. Cool down please and come back only after you realize that our users are priority. Ondrej. -- Ondrej Sury [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Intent to hijack Bacula
Marc 'HE' Brockschmidt [EMAIL PROTECTED] writes: Roberto Lumbreras [EMAIL PROTECTED] writes: [...] Ok, the maintainer has not fixed the bugs, has not packaged the last version of it in time, etc, but he has done a great job anyway, and I still don't see the point of hijacking the package. So he has done not one of the things expected of a good package maintainer. *What* of that is a great job? Brownie, you're doing a great job! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc 4.1 or not
Domenico Andreoli [EMAIL PROTECTED] writes: On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote: Hi, hi, there were some requests, e.g. by Martin Michlmayr to the release team whether we could switch gcc to 4.1 or not for etch. As we're heading to what about the transition to python 2.4? is it going to start or etch is going to ship with 2.3? Yeah, what about it? There is an open bug, it's blocking lilypond which should have an updated version in etch, and the python team has been discussing it apparently but there is a deafening silence about telling me what the plan is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
python 2.4?
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [060511 23:54]: Domenico Andreoli [EMAIL PROTECTED] writes: what about the transition to python 2.4? is it going to start or etch is going to ship with 2.3? Yeah, what about it? There is an open bug, it's blocking lilypond which should have an updated version in etch, and the python team has been discussing it apparently but there is a deafening silence about telling me what the plan is. Ok, I'll make sure there is some information latest for the next relese update, which is due in May. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python version?
Andreas Barth [EMAIL PROTECTED] writes: * Josselin Mouette ([EMAIL PROTECTED]) [060511 10:48]: Le jeudi 11 mai 2006 à 10:09 +0200, Domenico Andreoli a écrit : what about the transition to python 2.4? is it going to start or etch is going to ship with 2.3? An upload of python-defaults switching to 2.4 has been repeatedly asked during the last months, and it was ignored by the maintainer. I'm not aware of anything preventing this upload currently. The maintainer is not ignoring it, but the transition needs to have some issues fixed first. (And if you want to discuss aboutt hat, please leave -release out of the discussion. :) How nice it would be to have the maintainer say this when people ask what's the status, please? So, what are the issues that need to be fixed? Currently #360851 doesn't say it's blocked by anything, and two packages are blocked waiting for it. Thomas
Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
also sprach Josselin Mouette [EMAIL PROTECTED] [2006.05.11.2219 +0200]: I think this is the whole point of licensing a library under the GPL. For me the point of a library is code reuse. Putting a library under the GPL is more of a political statement. There's not much point in using a copyleft if you allow proprietary applications to use the library. I still see a difference between cut-n-paste and link-to-library code reuse. From what I understand, if your product links to a GPL library, you have to make it GPL as well. We analysed the situation back when we wanted to make libhid Artistic and concluded that we cannnot do that because it links against hidparser, which is GPL'd. If our analysis was wrong, all the better... -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system stupidity management for the superuser is a user space issue in unix systems. -- alan cox signature.asc Description: Digital signature (GPG/PGP)
Re: python 2.4?
Andreas Barth [EMAIL PROTECTED] writes: * Thomas Bushnell BSG ([EMAIL PROTECTED]) [060511 23:54]: Domenico Andreoli [EMAIL PROTECTED] writes: what about the transition to python 2.4? is it going to start or etch is going to ship with 2.3? Yeah, what about it? There is an open bug, it's blocking lilypond which should have an updated version in etch, and the python team has been discussing it apparently but there is a deafening silence about telling me what the plan is. Ok, I'll make sure there is some information latest for the next relese update, which is due in May. How about, right now, just a statement this is what the issues are. Or even, this [URL here] is the mailing list post where the issues are outlined. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python version?
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [060511 23:56]: So, what are the issues that need to be fixed? Currently #360851 doesn't say it's blocked by anything, and two packages are blocked waiting for it. As said, I put it on my need to work on-list, and you'll get results in May (and hopefully already after the python BoF on debconf). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python 2.4?
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [060512 00:00]: Andreas Barth [EMAIL PROTECTED] writes: * Thomas Bushnell BSG ([EMAIL PROTECTED]) [060511 23:54]: Domenico Andreoli [EMAIL PROTECTED] writes: what about the transition to python 2.4? is it going to start or etch is going to ship with 2.3? Yeah, what about it? There is an open bug, it's blocking lilypond which should have an updated version in etch, and the python team has been discussing it apparently but there is a deafening silence about telling me what the plan is. Ok, I'll make sure there is some information latest for the next relese update, which is due in May. How about, right now, just a statement this is what the issues are. Or even, this [URL here] is the mailing list post where the issues are outlined. I forgot about them. So, I need to collect them again. Even release managers don't have a superhuman brain (though we sometimes pretend we do :). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python version?
* Don Armstrong ([EMAIL PROTECTED]) [060511 20:21]: On Thu, 11 May 2006, Andreas Barth wrote: * Ganesan Rajagopal ([EMAIL PROTECTED]) [060511 14:12]: Andreas Barth [EMAIL PROTECTED] writes: An upload of python-defaults switching to 2.4 has been repeatedly asked during the last months, and it was ignored by the maintainer. I'm not aware of anything preventing this upload currently. The maintainer is not ignoring it, but the transition needs to have some issues fixed first. (And if you want to discuss aboutt hat, please leave -release out of the discussion. :) The last time this came up in, the majority view was to transition to 2.4 as default the old way rather than keeping it pending for so long. I'm not really aware of the python issues. Are there enough python people on Debconf to make an ad-hoc BoF about python? There are slots available for this; if someone wants to organize this, let me know, and I'll give you a slot. I'd like to organize this, but it depends a bit on the python people - there is no sense organizing it w/o them. :) Well, perhaps give me a slot now, and we could still cancel it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula
On Thu, May 11, 2006 at 11:07:55PM +0200, José Luis Tallón wrote: [ snip ] I have myself fixed in excess of 40 bugs in my packages in the last 48h, when I have been back to speed. So what??? I had already checked the packages you posted on sf.net and have not been able to find bug fixes anywhere near that number. In fact, most of the bugs you listed as fixed were ones that my NMUs fixed. I hope Jose chooses to actively work with everyone to get the help, and apparently training, that he needs to manage something this complicated. Sorry, but I fail to see how well you know my work for Debian (three years so far) in order to be able to judge me. Your packages speak for themselves. Correct. That's why I appreciate patches (and even NMUs). This is completely different. Hijacking a package without contacting the maintainer first is against the Developers' Reference and can only be considered a personal attack. I did not do that. * On March 13, I submitted #356755 asking for a new version. You said you had it packaged already. * On April 27, I offered to adopt it for you. I received no reply prior to posting my message on debian-devel. I can provide logs and message copies if you need them. I still don't know what is John Goerzen trying to achieve with this. Working Bacula packages in Debian. Period. More on this later. I'm sure thousands of Debian developers around the world are waiting with eager anticipation for your latest theories on why I am fixing Bacula. -- John
Bug#366893: init.d stopping messages not standardized or even always logged
Package: general Severity: wishlist Looking at the myriad ways of starting messages in /var/log/boot, Starting X TrueType font server: xfstt. Starting /usr/sbin/chronyd... Starting anac(h)ronistic cron: anacron. Starting deferred execution scheduler: atd. Starting periodic command scheduler (especially that last mystery program one), got me looking at start/stop messages. Stop messages for example: We see poor convergence of start messages in /etc/init.d: $ cd /etc/init.d/ $ grep -i stopping * acpid: echo -n Stopping Advanced Configuration and Power Interface daemon: apache2:log_begin_msg Stopping apache 2.0 web server... atd:log_daemon_msg Stopping deferred execution scheduler atd bind: echo -n Stopping domain name service: named bootlogd: log_daemon_msg Stopping $DESC $NAME cpufreqd: log_daemon_msg Stopping $DESC $NAME cron:stop) log_begin_msg Stopping periodic command scheduler... cupsys: echo -n Stopping $DESC: $NAME cwdaemon:echo -n Stopping $DESC: $NAME dbus-1: echo -n Stopping $DESC: etc. Also even $ grep --files-without-match -i stopping [a-z]*|wc -l 66 Despite policy: When you stop or restart a daemon, you should issue a message identical to the startup message, except that `Starting' is replaced with `Stopping' or `Restarting' respectively. However, even policy's $ zgrep -i stopping policy.txt.gz echo -n Stopping domain name service: named isn't as systematic as echo -n Stopping $DESC: $NAME Therefore, policy should provide a better role model. However, I also notice that although there is a bootlogger to log all those starting messages, upon shutdown syslog or whatever is shutdown too early in the order of shutting things down, so that many of those stopping messages, or errors upon stopping, aren't logged at all! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why isn't gnome in testing?
On Thu, May 11, 2006 at 10:32:36PM +0200, Andreas Barth wrote: * Julian Gilbey ([EMAIL PROTECTED]) [060511 22:17]: Does anyone know why the binary package gnome is no longer in testing? The source package meta-gnome2 is there Seems like an accident currently. We're researching the matter. Cheers, Andi Cheers! Julian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula
On Thu, May 11, 2006 at 09:30:40PM +0200, Roberto Lumbreras wrote: On Thu, May 11, 2006 at 08:37:35AM -0400, Stephen Frost wrote: : Jose Luis doesn't want just his name in some place, he has worked a lot : in bacula in the past, and I don't know why he can't remain as : maintainer or co-maitainer if he is going to work on it again. : You don't get to rest on your laurels in Debian. Especially when it's : been over a year. don't be so rude with Jose Luis, and it's not him the only person to blame, he is not the only person who can do an upload of a package (in fact, he can't) It is the responsibility of a package maintainer to ensure that fixes for bugs are uploaded in a timely manner. If José Luis isn't able to do this, because he doesn't have a sponsor or for any other reason, then he is not an effective maintainer for the package. Actually, we've heard in this thread that Stephen (his AM) *did* offer to sponsor bacula uploads, and José Luis did not avail himself of this. So it's not at all clear to me why you think anyone other than José Luis should bear the responsibility of this package not being fixed. He has packaged the last version of bacula, and it is not uploaded because it's not ready, then a new version was showed up... he has a personal apt repository that users from bacula mailing list uses, and packages (not yet finished) in sourceforge... so is it clear for you that he is not going to work on it again? IME, making plans in Debian based on whether someone else has *promised* to do something does not give very good results. The bacula packages have been removed from testing *repeatedly* over the past year due to one RC bug or another being reported against it; and it seems that the only real movement towards getting them fixed has only come in response to John's takeover attempt. I can't say that I fault John for wishing to take over this package and fix it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#366780: ITP: summain -- compute and verify file checksums
to, 2006-05-11 kello 07:13 -0700, Ben Pfaff kirjoitti: It's not clear to me, from the description, what the program does that the md5sum and sha1sum utilities do not. It handles .dsc, .changes, and Sources files. But I also forgot to mention the main reason I wrote it: it gives progress feedback and has some convenience features. An updated suggestion for a long description, which also incorporates Thijs's suggestion to reorder paragraphs: summain computes and checks files against such checksums. It supports both MD5 and SHA-1 checksums, using formats compatible with the md5sum and sha1sum utilities, both for reading and writing. In addition, it can read and verify checksums from Debian .dsc, .changes, and Sources files. . Apart from supporting more file formats, summain differs from the traditional md5sum and sha1sum utilities by providing progress reporting, and via convenience features such as automatic recursion into directories, and looking up files relative to the location of the checksum file, rather than the current working directory. . A checksum is a number that identifies the contents of a file: if the contents change, so does the checksum. If you create a checksum before you burn a CD, when you know the files are correct, you can easily check the CD at any time: just compute the checksum again and see if they have changed. I hope this is better. -- RFC 1437 - yet another MIME specification Microsoft ignores -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Light Desktop - meta package
Hi, I'd add localepurge - witch save my 25 % disk space on 6-700 mb installation. Thanks! Eugen Paiuc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
