Re: problema driver flash memory card
On Thu, Sep 04, 2003 at 04:29:11PM +0200, [EMAIL PROTECTED] wrote: Qualcuno mi potrebbe cortesemente spiegare perchè alcuni driver per la gestione di flash memory card in PCMCIA sviluppati in kernel-image-2.2.20 non sono più presenti nei kernel successivi? Sul mio portatile ho installato il kernel 2.4.18-686 ed ora 2.4.20-686, con relativi pacchetti moduli PCMCIA, ma i driver di cui necessito (iflash2+ ed iflash 2) non sono più presenti. Credevo che i kernel successivi contemplassero tutto il precedente. Devo pensare che non posso gestire flash memory card con i pacchetti .deb con i nuovi kernel? Non sono uno sviluppatore, ma un banale utente che non si spiega la mancanza. In generale puo' essere benissimo. Se le card in questione diventano obsolete e/o non si trova gente disponibile a mantenere il tutto up-to-date, i moduli vengono rimossi dai source (se non sono proprio compilabili). Sicuro che il supporto non sia fornito adesso da altri moduli? -- Francesco P. Lovergine
Re: debian/ et upstream
Bonjour On Monday 08 September 2003 09:57, Georges Mariano wrote: On Mon, 8 Sep 2003 09:57:40 +0200 Xavier Roche [EMAIL PROTECTED] wrote: Autre argument: votre application n'est pas specifique a Debian, donc mettre le repertoire debian/ ne va pas aider les empaqueteurs d'autres distributions (mandrake, etc.) ça va pas les déranger non plus! cf les .spec pour rpm qui sont maintenant dans beaucoup de sources. Et qui sont inutiles, car souvent prévus pour une autre distribution et donc ne respectant pas les conventions et les macros mises en places. Sans compter que je doute fortement de la qualité d'un rpm fait par un développeur qui n'a pas l'habitude et qui fait souvent ça comme un goret. Jusqu'à preuve du contraire, les méthodes d'empaquetage sont indépendantes, elles peuvent donc cohabiter dans les mêmes sources ... (au passage : ça facilite bien la tâche d'un utilisateur rpm qui reçoit ces sources alors pourquoi pas aider l'utilisateur debian ?) Ça ne facilite que dalle. En général, il y a un .spec, qui correspond a RH quand on est chanceux et a rien dans la plupart des cas. Ce genre de rpm ne prends pas en compte les conventions pour les menus, ou pour le placement des fichiers. Et je ne parle même pas de la politique de nommage des paquets ou des dépendances qui se retrouve totalement ignoré. si le but est d'installer des rpms crades pour polluer le système, oui, ça permet d'arriver plus vite à ses fins. A mon sens, il faut s'en tenir aux paquets officiels des distribs, sur debian comme sur les autres. Enfin, un projet libre est souvent le résultat d'efforts conjoints (développement, documentation, test,...). De nos jours, l'empaquetage (pour k distributions) devient une tâche intégrée au développement... La séparation n'est donc certainement pas une nécessité. Non. Chacun fait son boulot. La mise en paquet est géré par le distributeur, au niveau de la distribution. Je ne voit donc pas l'intérét de placer les mêmes fichiers à 2 endroits différents. Chacun distribution posséde sa politique de gestion des versions des paquets, et ne pas la suivre ne peut qu'ajouter une confusion inutile. Pour terminer, un truc bien rageant que chacun ici a probablement vécu... quand on achète un magazine/CD avec des _tonnes_ de sources gentiment fournis (sympa quand on a(vait) pas l'ADSL ;-) alors qu'il n'y a bien souvent pas de .deb, ni de debian/, en revanche il y souvent le rpm et le .spec :-(( Et ça conduit les gens à installer des rpms venant de n'importe ou sur leur distribution, et à la foutre en l'air à petit feu. Pour ma part, je ne voit pas pourquoi on devrait favoriser tel distro par rapport a tel autre, et inciter les gens à ne pas prendre des paquets officiels. Il est peut être facile pour nous de voir si un paquet est de qualité par rapport à un autre, mais c'est pas le cas de tout le monde. Et même si ça semble facilité la vie sur le court terme, les effets secondaires sur le long terme risque d'être plus que nuisible. -- Michaël Scherer
Re: apache2 php4 and all folk
J'ai réalisé quelques paquets php4 avec apache2 sous debian woody. J'ai utilisé un retroportage du paquet apache2 et j'ai inclus une dépendance sur mpm-prefork en raison d'extensions PHP ne supportant pas les threads. A noter qu'APXS est configuré en support thread. Pour lever cela, il faut refaire le paquet apache2. B. On Mon, 2003-09-08 at 16:07, Georges Roux wrote: Bonjour, Je fabrique un paquet de php-4.3.3 pour apache2 pour mon serveur apt, vu qu'il n'y a rien de dispo sur apt-cache Le paquet fonctionne deja bien sans les dependances, mon probleme et que j'utilise apache2-mpm-prefork et que celui-ci ne fourni rien du tout, du coup ma question est que faut il mettre dans mon fichier debian/control a la ligne Depends pour realiser une dependance avec apache2? ou faut t'il que je reface aussi le paquet apache? -- Georges Roux URL : http://georgesroux.pacageek.org Key fingerprint = D337 5884 2821 9B59 A02D B4DF 728D F440 E2E7 4EA9
Re: debian/ et upstream
Tous ça pour dire que même entre fichiers .deb il peut y avoir des problèmes si ils ne font pas parti de la même distribution, homogène et suivant des règles communes. Ben c'est quand même prévisible, non ? du temps où j'utilisais du Ximian, ça marchait bien. Évidemmment, je _savais_ qu'en faisant des mixtures je prenais des risques... et donc, à un moment donné j'ai fais la bascule. Point. Et même si l'upstream avait inclu un debian/ rien ne dit que Debian et/ou Ximian ne le modifiront pas en fonction de règles différentes. Euh, dans mon esprit, en supposant qu'upstream fasse correctement les choses (c'est souvent le cas non ?;-), je supposais qu'a priori le debian/ était celui de la debian oficielle, éventuellement maintenu par le DD officiel... Et je suppose qu'il ne serait pas difficile de trouver un exemple où le paquet fait par upstream serait plus correct que celui fait par un DD... ;-) Mais bon tous ça c'est des suppositions et quasiment des procès d'intention (bonnes ou mauvaises), ça n'explique toujours pas en quoi _techniquement_ (i.e objectivement == sans *pré*juger la qualité du résultat) ce serait un problème... Que certains utilisent cela à mauvais escient, c'est une fatalité (on peut obtenir les mêmes bétises à partir d'un apt-get source !) En cas de divergence entre upstream et debian, où est le problème ? actuellement un DD récupère les sources et y place son debian/, pourquoi cela serait soudain impossible (il existe des ajustements plus lourds que 'mv debian debian.upstram')? A+ -- mailto:[EMAIL PROTECTED] debfr-faq http://savannah.nongnu.org/download/debfr-faq/html/
Re: debian/ et upstream
Selon Sven Luther [EMAIL PROTECTED]: soudain impossible (il existe des ajustements plus lourds que 'mv debian debian.upstram')? Ca pollue le .diff.gz et rend les choses plus difficile pour le mainteneur. hmm, oui, tiens... à quel moment le diff.gz entre-t-il dans la danse ? il n'est généré qu'à la construction du paquet n'est-ce pas ? (inutile de le stocker?) Si upstream souhaite maintenir un repertoire debian, il faut souvent mieux qu'il le maintienne directement sous un autre nom (deb par exemple) que le mainteneur peut utiliser ou pas. i.e le nom est indifférent donc ... (tiens, est-ce paramétrable dans les outils ?) Ou encore, on peut arriver a une situation ou upstream devienne co-mainteneur du package, et que le mainteneur deviennent son sponsor. oui, c'est un scenario sain (et préférable évidemment). Mais nous sommes bien d'accord(?), c'est pas une difficulté technique... A+ -- mailto:[EMAIL PROTECTED] debfr-faq http://savannah.nongnu.org/download/debfr-faq/html/
Re: debian/ et upstream
On Mon, Sep 08, 2003 at 08:33:30PM +0200, Georges Mariano wrote: Tous ça pour dire que même entre fichiers .deb il peut y avoir des problèmes si ils ne font pas parti de la même distribution, homogène et suivant des règles communes. Ben c'est quand même prévisible, non ? du temps où j'utilisais du Ximian, ça marchait bien. Évidemmment, je _savais_ qu'en faisant des mixtures je prenais des risques... et donc, à un moment donné j'ai fais la bascule. Point. Et même si l'upstream avait inclu un debian/ rien ne dit que Debian et/ou Ximian ne le modifiront pas en fonction de règles différentes. Euh, dans mon esprit, en supposant qu'upstream fasse correctement les choses (c'est souvent le cas non ?;-), je supposais qu'a priori le debian/ était celui de la debian oficielle, éventuellement maintenu par le DD officiel... Et je suppose qu'il ne serait pas difficile de trouver un exemple où le paquet fait par upstream serait plus correct que celui fait par un DD... ;-) Mais bon tous ça c'est des suppositions et quasiment des procès d'intention (bonnes ou mauvaises), ça n'explique toujours pas en quoi _techniquement_ (i.e objectivement == sans *pré*juger la qualité du résultat) ce serait un problème... Que certains utilisent cela à mauvais escient, c'est une fatalité (on peut obtenir les mêmes bétises à partir d'un apt-get source !) En cas de divergence entre upstream et debian, où est le problème ? actuellement un DD récupère les sources et y place son debian/, pourquoi cela serait soudain impossible (il existe des ajustements plus lourds que 'mv debian debian.upstram')? Ca pollue le .diff.gz et rend les choses plus difficile pour le mainteneur. Si upstream souhaite maintenir un repertoire debian, il faut souvent mieux qu'il le maintienne directement sous un autre nom (deb par exemple) que le mainteneur peut utiliser ou pas. Ou encore, on peut arriver a une situation ou upstream devienne co-mainteneur du package, et que le mainteneur deviennent son sponsor. Amicalement, Sven Luther
Re: IMPORTANT: your message to html-tidy
On Sat, Sep 06, 2003 at 04:26:57PM -0700, Joshua Kwan wrote: On Sat, Sep 06, 2003 at 06:40:46PM -0400, W3C List Manager wrote: This is a response to a message apparently sent from your address to [EMAIL PROTECTED]: Subject: Re: Thank you! From:debian-devel@lists.debian.org Date:Sat, 6 Sep 2003 18:40:45 --0400 Your message has NOT been distributed to the list; before we distribute it, we need your permission to include your message in our Web archive of all messages distributed to this list. How ironic... C-R system at work :) This one's a bit different. It's only asking for permission to archive posts to the list - I guess W3C's just trying, as hard as possible, to avoid any possible legal problems. The best way for this would be that the e-mail sent goes immediately to the list, and lives in a holding pen for archiving. Future e-mails just get sent straight to the holding pen until OK'd for archival, without bothering the sender. That way, if you don't want your messages archived, you just ignore the first e-mail and continue on your way. Of course, if it's not done this way (eg you send a please OK to archive for each message) then sending a message to one of these lists, purporting to be from another similarly configured list, would cause quite a stir... g Still, if you don't want it put on the web, don't send it. *Especially* to a mailing list of (potentially) thousands of people. - Matt
[no subject]
hay u suck u faget u lick dick suck yr mu
is your /usr/share/info/dir in perfect shape?
Gentlemen, the Info dir on my system is not in tip top shape, and may not be also on yours. Try this simple test for duplicate entries: $ sort /usr/share/info/dir|uniq -d|fgrep \* * patch: (diff)Invoking patch. Apply a patch to a file. * sdiff: (diff)Invoking sdiff. Merge 2 files * testsuite: (autoconf)testsuite Invocation. Running an Autotest test So some packages are using install-info imperfectly. Maybe instead of relying on perfect use of install-info by each package, perhaps just remaking /usr/share/info/dir from whatever info files are on the system might be less error prone? $ sed -n 's/:.*//p' dir|sort|uniq -d * Gnus * Info * Message * patch * sdiff * testsuite * true * tty * uname * users * who * whoami * yes for me reveals that I need to do $ install-info --remove /usr/share/info/sh-utils.info as apparently that wasn't done when those tools were moved to a different package. Same with fileutils...
Single point of entry for translation work?
Is there a page somewhere that I can point people to for all translation work relating to Debian (DDTS, po-debconf, etc)? Just trying to make the debian-mentors FAQ as useful as possible... - Matt
Re: IMPORTANT: your message to html-tidy
on Mon, Sep 08, 2003 at 01:57:54PM +1000, Matthew Palmer ([EMAIL PROTECTED]) wrote: On Sat, Sep 06, 2003 at 04:26:57PM -0700, Joshua Kwan wrote: On Sat, Sep 06, 2003 at 06:40:46PM -0400, W3C List Manager wrote: This is a response to a message apparently sent from your address to [EMAIL PROTECTED]: Subject: Re: Thank you! From:debian-devel@lists.debian.org Date:Sat, 6 Sep 2003 18:40:45 --0400 Your message has NOT been distributed to the list; before we distribute it, we need your permission to include your message in our Web archive of all messages distributed to this list. How ironic... C-R system at work :) This one's a bit different. It's only asking for permission to archive posts to the list - I guess W3C's just trying, as hard as possible, to avoid any possible legal problems. It's still an instance in which the autoresponse would not have been triggered had any half-decent AV/AS system been used to filter out spam and viruses. This was a response to the SoBig.F worm. I'm coming to the view that we're approaching the era where all mail is going to have to be subject to filtering, at the MTA level. Peace. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What Part of Gestalt don't you understand? In his dream he was walking late at night along the East Side, beside the river which had become so extravagantly polluted that new lifeforms were now emerging from it spontaneously, demanding welfare and voting rights. -- HHGTG pgpA3Jo4khB6Y.pgp Description: PGP signature
Re: IMPORTANT: your message to html-tidy
On Mon, Sep 08, 2003 at 06:04:39AM +0100, Karsten M. Self wrote: on Mon, Sep 08, 2003 at 01:57:54PM +1000, Matthew Palmer ([EMAIL PROTECTED]) wrote: [W3C's autoresponder] This one's a bit different. It's only asking for permission to archive posts to the list - I guess W3C's just trying, as hard as possible, to avoid any possible legal problems. It's still an instance in which the autoresponse would not have been triggered had any half-decent AV/AS system been used to filter out spam and viruses. This was a response to the SoBig.F worm. Sorry, I didn't make my position sufficiently clear. This system is as broken as every other Challenge-Response, in that it has the potential to annoy the shit out of a lot of people very easily, and become a nice anonymous harassing agent. I was just making the point that it isn't the same as a regular C-R system, in that the intent wasn't so much to say I want to make sure you're not a spammer and more I want to make sure you agree to your posts being publically archived - at the very least it's a little less offensive than normal (it's not saying You're a spammer - prove me wrong!). I'm coming to the view that we're approaching the era where all mail is going to have to be subject to filtering, at the MTA level. Depends on how useful you want your e-mail box to be. g - Matt
Re: IMPORTANT: your message to html-tidy
On Mon, 8 Sep 2003 15:40:15 +1000 Matthew Palmer [EMAIL PROTECTED] wrote: On Mon, Sep 08, 2003 at 06:04:39AM +0100, Karsten M. Self wrote: I'm coming to the view that we're approaching the era where all mail is going to have to be subject to filtering, at the MTA level. Depends on how useful you want your e-mail box to be. g It has been my experience that filtering at the MTA level has increased the usefulness of my mailbox considerably. Something that C-R will never be able to claim. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpLIChFdsqlH.pgp Description: PGP signature
Re: ruby-defaults 1.8.0
Fumitoshi UKAI writes: Hi, ruby package maintainers! I've upload new ruby-defaults that make ruby 1.8.0 the debault version of ruby. I contains some new binary package so it takes time to get into unstable. You can get the new ruby-defaults from deb http://pkg-ruby.alioth.debian.org/deb/ ./ deb-src http://pkg-ruby.alioth.debian.org/deb/ ./ Note that - packages that depends on ruby ( 1.7) will be removed by dist-upgrade. It must be fixed to depend on ruby1.6, or to change dependency version if it works with ruby 1.8. - I don't recommend that package depends on libruby. Instead, ruby module package should depend on libruby1.8 or libruby1.6. - module packages that build-depends on ruby-dev MUST be fixed to use ruby1.8-dev (or ruby1.6-dev) instead of ruby-dev. I did a NMU for swig1.3 (depending on ruby). I'm wondering why make a version the default, if it does not build on all archs (powerpc). How are package maintainers supposed to handle this? what will the ruby-defaults package default to on the powerpc architecture? Thanks, Matthias
installer for non-free packages in contrib
Hi, I did not noticed clear answer about my proposal about the non-free software installer in contrib. Would it be acceptable to fill a bug against each installer that do not build a proper debian package when installing non-free software? If so, which severity is appropriate? I do not think that the issue is so trivial, so I do not think it can be considered as only a wish. Regards, -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Bug#209178: ITP: jamin -- Audio mastering from a mixed down multitrack source with JACK
Package: wnpp Version: unavailable; reported 2003-09-08 Severity: wishlist * Package name: jamin Version : 0.5.12+cvs030908 Upstream Author : Steve Harris [EMAIL PROTECTED] * URL : http://jamin.sourceforge.net * License : GPL Description : Audio mastering from a mixed down multitrack source with JACK JAM is a tool for producing audio masters from a mixed down multitrack source. It runs in the JACK Audio Connection Kit, and uses LADSPA for its backend DSP work, specifically the swh plugins created by Steve Harris, JAM's main author. Features: * Linear filters (though this seems to be going out of fashion, oh well) * JACK i/o * 30band graphic EQ * 1023band graphic EQ * Spectrum analyser * 3band peak compressor * Lookahead brickwall limiter Planned features (in rough order of difficulty): * Multiband stereo processing * Parametric EQ * Loudness maximiser * Presets and scenes
Re: Single point of entry for translation work?
W licie z pon, 08-09-2003, godz. 06:41, Matthew Palmer pisze: Is there a page somewhere that I can point people to for all translation work relating to Debian (DDTS, po-debconf, etc)? Just trying to make the debian-mentors FAQ as useful as possible... Take look at http://ddtp.debian.org/ eloy -- [EMAIL PROTECTED]
Re: tmda: Challenge-response is fundamentally broken (RAPNAP)
On Sat, Sep 06, 2003 at 11:32:04PM +1000, Russell Coker wrote: DNSBL's and spamassasin seem quite good at dealing with spam and are much less annoying. That combined with some new laws that are being enacted to combat spam should keep it to a managable level. oh, please tell me that these new laws are going to be the replacement of Duck Season with Spammer Season (Jan to Dec in any year). that'll work. i sometimes think that it's the ONLY thing that will really work. craig
translations and the ddtp
On Fri, Sep 05, 2003 at 11:21:18AM +0200, Wouter Verhelst wrote: Op vr 05-09-2003, om 09:16 schreef Martin Quinson: On Thu, Sep 04, 2003 at 10:44:08PM -0700, Joshua Kwan wrote: On Fri, Sep 05, 2003 at 07:15:57AM +0200, Martin Godisch wrote: Are these actually used somewhere? If I switch my browser language I see packages.d.o still in English, if I switch my environment, dselect and apt-cache show package descriptions still in English... What are these translations good for? Oh, also debconf templates are translated there for use in po-debconf, but those usually get to the BTS anyway. Err, AFAIK, the ddtp translates the old-style debconf templates. Well, your knowledge is outdated, then. Please check your facts next time :-) It's not so often that I'm so happy to be wrong ;) Are you sure that the templates are stored under the po format during their whole lifetime? Since when is it so? Where did I oversee the announcement? Are the templates extracted from the source package now, or still from the binaries? Thanks for correcting me, Mt. -- Und auch jetzt ist ein Mensch mehr Affe als irgend ein Affe. --- F. Nietzsche
Re: /etc/shells management
On Sun, Sep 07, 2003 at 06:59:18PM +0100, Colin Watson wrote: On Sun, Sep 07, 2003 at 11:58:03AM -0500, Steve Langasek wrote: On Sun, Sep 07, 2003 at 06:08:06PM +0200, Thomas Hood wrote: On Sun, 2003-09-07 at 17:23, Branden Robinson wrote: Man, that's ugly. I use: if [ -n $var ]; then fi I have been using if [ $var ]; then fi I hope that's kosher too; otherwise I have a few scripts to fix. In general, no. If the contents of $var are a test operator, you'll get a syntax error. POSIX requires this not to be the case, because of the argument-counting algorithm that 'test' is supposed to follow. See http://www.opengroup.org/onlinepubs/007904975/utilities/test.html. But if $var contains more than one shell word... You might get different results dependening on whether you remember to quote the shell variable or not. My own preliminary tests leave this unclear. :) Probably not worth leaving to the vagaries of shell implementations, anyway. It's just too unpredictable to rely upon. Especially if $var can be a variable that is derived from user input without Stalinistic validation. I personally stongly advocate -n and -z over [ $var ] and really horrible tests like: if [ x$var = x ] and if [ x$var != x ] Those just strike me as obscurantist (which might explain why they feature prominently in shell scripts by Ian Jackson, heh). test -n and -z exist for a reason, even if one has to come up with pretty dodgy mnemonics for remembering them. The other benefit to using test flags instead of a hand-rolled string test is that they're *documented in the manpage*. -- G. Branden Robinson|It may be difficult to to determine Debian GNU/Linux |where religious beliefs end and [EMAIL PROTECTED] |mental illness begins. http://people.debian.org/~branden/ |-- Elaine Cassel pgpbPx4cRVLaJ.pgp Description: PGP signature
Re: Single point of entry for translation work?
On Mon, Sep 08, 2003 at 10:17:45AM +0200, Krzysztof Krzyzaniak wrote: W li?cie z pon, 08-09-2003, godz. 06:41, Matthew Palmer pisze: Is there a page somewhere that I can point people to for all translation work relating to Debian (DDTS, po-debconf, etc)? Just trying to make the debian-mentors FAQ as useful as possible... Take look at http://ddtp.debian.org/ Although note that not all translators work with or through the DDTP - I'd guess that I get more translations directly than via the DDTP. When I've asked people have generally said that they're the only persont they know of working on a given language so there's nobody else to coordinate with. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: /etc/shells management
Sorry to give offense, Manoj. I should have grepped the whole chapter
before wondering about unknown, and I should have mentioned that I
really just use section 6.4 most of the time (because I *think* I
remember what each of the cases are for).
The fact that a non-version-number string literal with shell redirection
operators in it was a valid value of old-version, new-version,
most-recently-configured-version, and so forth, did not occur to me.
I'd propose a Policy amendment dropping support for this long-obsolete
dpkg behavior, but I reckon I've lost my Policy-amendment-proposing
credentials in your eyes.
I do continue to think that:
if [ -n $var ]
is more readable than
if [ ${var+set} = set ]
...but I remain open to being directed to a section of the Policy manual
that firmly establishes my wrongness on that front as well. :)
--
G. Branden Robinson|Men use thought only to justify
Debian GNU/Linux |their wrong doings, and speech only
[EMAIL PROTECTED] |to conceal their thoughts.
http://people.debian.org/~branden/ |-- Voltaire
pgpz9zExvGGrY.pgp
Description: PGP signature
Re: /etc/shells management
On Sun, Sep 07, 2003 at 09:42:40PM +0200, Josip Rodin wrote: On Sun, Sep 07, 2003 at 10:23:15AM -0500, Branden Robinson wrote: Where did you come by this, and if it's something we should worry about, why isn't it documented in Policy? It is, but you shouldn't worry about it anyhow because nobody's crazy enough to try doing anything with a dpkg that old and current packages. It would likely fail in way much more spectacular than this, and we caution against it in the Release Notes. Do you think it would be a good idea to drop that clause from section 6.6 of Policy? I mean, in theory, Policy is supposed to document current practice, and until Manoj posted his snippet I'd never seen a Debian postinst script or portion there of that bothered to see if $2 could be 'unknown'. -- G. Branden Robinson| The National Security Agency is Debian GNU/Linux | working on the Fourth Amendment [EMAIL PROTECTED] | thing. http://people.debian.org/~branden/ | -- Phil Lago, Deputy XD, CIA pgpzyVLEYMQbW.pgp Description: PGP signature
Re: installer for non-free packages in contrib
On Mon, Sep 08, 2003 at 09:35:45AM +0200, Mathieu Roy wrote: I did not noticed clear answer about my proposal about the non-free software installer in contrib. It might help if you posted a summary of the thread. Would it be acceptable to fill a bug against each installer that do not build a proper debian package when installing non-free software? Not until after the summary has been evaluated. If so, which severity is appropriate? I do not think that the issue is so trivial, so I do not think it can be considered as only a wish. When in doubt, use severity normal, and let the package maintainer decide which severity might be more appropriate. But do no filing at all on this issue until after a consensus has been reached on this mailing list. -- G. Branden Robinson| Yesterday upon the stair, Debian GNU/Linux | I met a man who wasn't there. [EMAIL PROTECTED] | He wasn't there again today, http://people.debian.org/~branden/ | I think he's from the CIA. pgpIBvTotBxHG.pgp Description: PGP signature
Re: Single point of entry for translation work?
On Mon, Sep 08, 2003 at 10:17:45AM +0200, Krzysztof Krzyzaniak wrote: W li?cie z pon, 08-09-2003, godz. 06:41, Matthew Palmer pisze: Is there a page somewhere that I can point people to for all translation work relating to Debian (DDTS, po-debconf, etc)? Just trying to make the debian-mentors FAQ as useful as possible... Take look at http://ddtp.debian.org/ AFAICT, that site only covers descriptions. I'm looking for somewhere (if it exists, even as a link farm) to the DDTP, Debconf, and documentation translation efforts. - Matt
Re: Single point of entry for translation work?
On Mon, Sep 08, 2003 at 02:41:14PM +1000, Matthew Palmer wrote: Is there a page somewhere that I can point people to for all translation work relating to Debian (DDTS, po-debconf, etc)? Just trying to make the debian-mentors FAQ as useful as possible... Normally the contact persons and translation procedures for each language should be listed at www.debian.org/international/ Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/
Re: /etc/shells management
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Branden Robinson [EMAIL PROTECTED] wrote:
[...]
The fact that a non-version-number string literal with shell redirection
operators in it was a valid value of old-version, new-version,
most-recently-configured-version, and so forth, did not occur to me.
I'd propose a Policy amendment dropping support for this long-obsolete
dpkg behavior, but I reckon I've lost my Policy-amendment-proposing
credentials in your eyes.
I would support it.
I do continue to think that:
if [ -n $var ]
is more readable than
if [ ${var+set} = set ]
I agree, but usually use »[ x${var} != x ]« for no particular
reason but the fact that when reading it later I can discern its
purpose much faster than test -n or just [ $var ].
...but I remain open to being directed to a section of the Policy manual
that firmly establishes my wrongness on that front as well. :)
I don't think it should.
cu andreas
- --
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/XEfDHTOcZYuNdmMRApQzAJ90YSr5WW2NJZ8AuLtYtFaDyoiLDwCfW/jN
+YKZa6yx6JwJdllPjQfbCXg=
=hKAf
-END PGP SIGNATURE-
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.2.2 (GNU/Linux)
mQGiBDgv4FIRBAC65xFoxM2TVvnrfgqU8sh7XcT/N1ifZOAmCVQb/mMmqCc4S9j5
qFL++Pa6tkH8A+SRORTSgziW565R3PborVFM7WbIjhXKPCbJ2FjcpK61n2d1Sg3B
pPefS0++nyd9HhJSK2RrAFeAfipdsPe4pd9F+traM4TmHWGDK4aJnCPYDwCgsRQk
wZqU4kmsxlM7VNevWcMlb8ED/R3F+yOe5Q9LO5zjvOj2uFCnIanZ+bdWCIWBO9po
EqhBQPettVTFqJjIIIGZyV2irBg+vQlYnDL/n4SBCPvmCsNhceuobUSTk4DNC1qL
0B+raRgGPMd2qizaFMnmVuT/JsGoh4gu0zsoyYhnODO8Sfp7oPy1VVCbRdz7m8ZU
DztxBACYjmLwqKKp5pF4z1s/1J2u0V/LBgthQ6Vu1LARS8JZzu2jjv97eKqC2v1L
5GmhM2Hi+hW2l5zhNQAe9It2uFAikwp8WRP7lQUQiuo05hyGZpSW2NeBRU/REYRt
57GOZ/Jv0ixJfVk4YTgzwbOUSxs5NhhufwmzLC36PA2K4LQSYbQ7QW5kcmVhcyBN
ZXR6bGVyIChwcml2YXRlIGtleSkgPGFtZXR6bGVyQGRvd25oaWxsLmF0LmV1Lm9y
Zz6IWAQTEQIAGAMLCgMDFQMCAxYCAQIXgAIZAQUCOC/gUwAKCRAdM5xli412Y9Bg
AJ9ZaCCY+CWFxtHeuni2YWApJ8ZsLACgoEPpM+h596oHH0WbSUbxG0KQWaOInAQQ
AQEABgUCOecRWQAKCRD175d9nvVQ4TSPBADDfppOzFhCsSvCfVcT1fiYY/0Uv+vw
hwsFpECBZXmEdVDvwzikwifDyNdA+kB2DP8hDi+eL/zRuFhXSpn/2lnzq/93mcZU
M1O/sUx7zVWoc4YSs3elCNL2vym9/1th8QuRL8OgTkEg/MV3FRznLktGx89kmj1F
ZznOAWFyrIcJ+4kAlQMFEDvYqYczdR0edTxGXQEByDkD/07XHDswLJMi1nZbQ7wD
yDQGFF1I4rj+bKOoExcqPCHmNBuqf5GurY752aFGaQnJshORkcl3yWFuaxJ/VRfz
ynf5ox5UjyMyhelwZgPbewogSWPKan/JVTsrKsy9QKsmn1DUf3IhOCB3X2fXK/g3
O8o3hE5QsHjGhEeBcDoy5BGViEYEEBECAAYFAjvYqYkACgkQfFYn/kwM9E9VtgCe
K/Y862yp4VWZ6PN2DFUqZgy/suUAoKXxvylXkkJ0qIGQFiPqX8NCqDxFiEYEEBEC
AAYFAjvYqY4ACgkQizJGFvc6Ki8WLgCgvCigBa7dLbKQrQWduLNZ5EcHeYgAniSs
+/lCbbl3zJih//kzS8pFAzpRiEYEEBECAAYFAjvYjCgACgkQipm9iJAT39/TdACe
OEwH1KhO/Y7lu+PsH4zVSqhasZoAmwVUaC7VbAhijFHAaeVtFgwmXpmuiEYEEBEC
AAYFAjvZBhAACgkQDF8aVkjSn7EU0ACfStWK92wLrZCDUGP2Zmn9vSIE620AoLWE
Z9QhsBWNZIONszc/xc73/R15iQEcBBABAgAGBQI72TBJAAoJEBbilLMFONd4HuwH
/ic7c+lt1QyQ4GAR3k6hSPeAzt/kU6y3zHvdo76Zxl6BqdZP3xBmmm8Vwqypst3H
dTEO8xgGtf8Doamh5ihzAQqD/m/vsYsJk9ZcsUFocdOZrByzCQ0hLIW2muFkPHyf
6QDXjFia7RNCMaNsmbIOC0WpGGDJ1TJi6IeWInG+gFFyMM0aOdrg2cbxTHtiEZgn
o/nCEUy5iKK3hOdNuYL+Zqym24hrnLrcJbyLmn1B0UdEJNpw6yHBou4nXZkxOsQX
EslXAsbgqeaXjS++dO3BImI/NX1wlyv9C/A0ulMxYSUEJMxJippje5y7h5ceVG6o
VDhi0ImFwNEA6pSEygEaFT+IRgQQEQIABgUCO9lXVAAKCRATQ3NImvnegrBOAJsH
R/pju3ps0S89OrVG16NQyaCfzQCeL9dFPiKnBdROwM+7rIMmGLI9MAmIRgQQEQIA
BgUCO9lXkwAKCRBqlnUR0RRTwnUSAKCRMEgSneGP2qcHHoYsCMlO2eMztgCg+n9m
UF5DfBaKNwkvWmfFCE8rcmSIRgQQEQIABgUCO9ms1AAKCRCp2TuhBdA56w8HAJ40
5lTDunwkvEw/ZEldGoBgEODVCwCfTIMpg/KB4dbk4HYHwHVuLexKdHWIRgQQEQIA
BgUCO9mPhQAKCRCI6X93R3r7kKHLAKCRqZYiD0iaJoslLYfK21STOieeRQCg/zh3
tEc3cJNCFTs8ImsR0A/7qIWIRgQQEQIABgUCO9sgpwAKCRB9n5GQbyq7LejsAJ0c
76k3DJ2PZhuVrK8KJ65snnQ4FgCfYroRQPdYgT31SwlUkauQO+5FiPGJAJUCBRA7
2ynBxZlFMVEPYUEBAQmRA/4/BgxsD4dUN/gFP64sovMUhrDGxbsfAqsCD6PtMfBx
/uzkWEN/VnLQdeoxH0Qd+VDmPeOIJIGvysF+WxeBZa+1Xm3zPafpLvDgjDCFJczu
+KDy4LgbqEa5sUbNLhdQnTC8rx2rVcsGBWFef7y3be+LjveH4rsxaOqj3vz6XAlh
34kA0AMFEDvbL7VS43pmszriqQEBsa4F1ArHZgR2vQLKATlGANBuz1u3KRGIB1QB
kzod6g5xvhJJV0onccetvBsSMCUcf84+CiWLC+9OAWZQ4cfBK6reQ8yBDnlOEwuy
J15dcjxzvAvmqYy+8GwDmPNRRIKfCxFM5prv5/U7Bgwv6HsbIaQxRiRUBkRDBDrm
6hNhUoro0lavCi8eSsfVkHQBtbWZOWXqstZ/nBkGxaq4AKaLBKaMhNc4EPj7RCOH
L41D9crbovtnzSU3PROecAnczsOJAJUCBRA72z7xVkrK5voTYfkBAe7ZBAC0jKyd
0K96mTU9dZyCqQgiG0kpfb12dPG49QtoKU/1EHLkEwChV37EK+DUy51LZK7sReqj
9sxA21TyNKfHEhds35Uqu9kxhFLux5Xyg6M69J46U0F1RFHFzHVtcYgAwEySCaHc
0Zc2jYMGduKkpDH7v3Zn3N69xrEtNPygqzvC8IhGBBARAgAGBQI72/hCAAoJENnm
PzGqUp1YFIMAoIJjalpdNgu2YIbalCDZqWBiW8SFAJ4uf9FhvC75I68zIrO+vRYk
Xky3RYhGBBARAgAGBQI729tjAAoJEISP81DRy1cGCjYAoINC23j2yuF3tEpQ6jDz
semB4JIzAKCrHfFczhnVPBiwAvh6Z7dhWxNqbIhGBBARAgAGBQI73CM9AAoJEAM9
TnY4KpMFioIAn3eeGPRscJgrxJg9i0HrNF1F2KYaAKC0qcVyXhof+zIXyZMEzgGF
g+AuM4g/AwUQO9xFcVbmlud7DA+mEQKwCwCdGFBKsR+CIrUtyeJSSpGixzt99nUA
oLdg2kYkwssmgZnv0NdOdZXIvGYDiQCVAgUQO9xGAMRGkei8OaXNAQEHYAQAosIP
Re: Single point of entry for translation work?
Matthew Palmer [EMAIL PROTECTED] wrote: On Mon, Sep 08, 2003 at 10:17:45AM +0200, Krzysztof Krzyzaniak wrote: W li?cie z pon, 08-09-2003, godz. 06:41, Matthew Palmer pisze: Is there a page somewhere that I can point people to for all translation work relating to Debian (DDTS, po-debconf, etc)? Just trying to make the debian-mentors FAQ as useful as possible... Take look at http://ddtp.debian.org/ AFAICT, that site only covers descriptions. I'm looking for somewhere (if it exists, even as a link farm) to the DDTP, Debconf, and documentation translation efforts. Check the left column, it does cover debconf. Stats [...] debconf · Anyone · Translators · Reviewers · Pkg Maintain cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: /etc/shells management
On Mon, Sep 08, 2003 at 03:42:06AM -0500, Branden Robinson wrote: On Sun, Sep 07, 2003 at 06:59:18PM +0100, Colin Watson wrote: On Sun, Sep 07, 2003 at 11:58:03AM -0500, Steve Langasek wrote: In general, no. If the contents of $var are a test operator, you'll get a syntax error. POSIX requires this not to be the case, because of the argument-counting algorithm that 'test' is supposed to follow. See http://www.opengroup.org/onlinepubs/007904975/utilities/test.html. But if $var contains more than one shell word... You might get different results dependening on whether you remember to quote the shell variable or not. Whoa. You don't reflexively quote shell variables and have to think about when *not* to quote them? :) Certainly, if you leave the variables unquoted, 'test -n $var' is hardly any more reliable than just 'test $var', and I would trust neither against hostile input. -- Colin Watson [EMAIL PROTECTED]
Re: installer for non-free packages in contrib
On Mon, Sep 08, 2003 at 09:35:45AM +0200, Mathieu Roy wrote: Would it be acceptable to fill a bug against each installer that do not build a proper debian package when installing non-free software? How can they do so? Installing a package with 'dpkg -i' in the postinst of another package isn't possible, since dpkg's status area is locked. -- Colin Watson [EMAIL PROTECTED]
Re: Single point of entry for translation work?
On Mon, Sep 08, 2003 at 11:21:00AM +0200, Andreas Metzler wrote: Matthew Palmer [EMAIL PROTECTED] wrote: On Mon, Sep 08, 2003 at 10:17:45AM +0200, Krzysztof Krzyzaniak wrote: W li?cie z pon, 08-09-2003, godz. 06:41, Matthew Palmer pisze: Is there a page somewhere that I can point people to for all translation work relating to Debian (DDTS, po-debconf, etc)? Just trying to make the debian-mentors FAQ as useful as possible... Take look at http://ddtp.debian.org/ AFAICT, that site only covers descriptions. I'm looking for somewhere (if it exists, even as a link farm) to the DDTP, Debconf, and documentation translation efforts. Check the left column, it does cover debconf. Stats [...] debconf OK, that looks good. Is there a similar coordination page or site for documentation translations? - Matt
Re: installer for non-free packages in contrib
Colin Watson [EMAIL PROTECTED] a tapoté : On Mon, Sep 08, 2003 at 09:35:45AM +0200, Mathieu Roy wrote: Would it be acceptable to fill a bug against each installer that do not build a proper debian package when installing non-free software? How can they do so? Installing a package with 'dpkg -i' in the postinst of another package isn't possible, since dpkg's status area is locked. At this point, the question is not how to do it (anyway, I think there are several way to do it, it's not a big deal). -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: installer for non-free packages in contrib
On Mon, Sep 08, 2003 at 01:08:34PM +0200, Mathieu Roy wrote: Colin Watson [EMAIL PROTECTED] a tapot? : On Mon, Sep 08, 2003 at 09:35:45AM +0200, Mathieu Roy wrote: Would it be acceptable to fill a bug against each installer that do not build a proper debian package when installing non-free software? How can they do so? Installing a package with 'dpkg -i' in the postinst of another package isn't possible, since dpkg's status area is locked. At this point, the question is not how to do it I think it absolutely is. If something is impossible to do correctly then filing [1] bugs against packages claiming that they don't do it is rather unfair. [1] P.S. When talking about bugs the verb is file, not fill, and filing, not filling. This seems to be a common mistake. (anyway, I think there are several way to do it, it's not a big deal). OK. How does one create an installer package which correctly does the following: * creates a Debian package for the thing it's installing * installs that package in such a way that it's registered in dpkg's database * doesn't rely on internal implementation details of dpkg such as /var/lib/dpkg/status and /var/lib/dpkg/info/*.list files * when the installer package is considered by dpkg as fully configured, the package it's installing is also fully configured * if some error happens when installing the created package, the installer package will throw an error during configuration ? I think that's a minimal specification for a correct installer package which does its work by creating Debian packages; unless you think that it's better for the installer package to spit out a .deb somewhere which you then have to install separately, which seems to me like a step backwards in convenience. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: /etc/shells management
On Mon, Sep 08, 2003 at 03:48:37AM -0500, Branden Robinson wrote:
I do continue to think that:
if [ -n $var ]
is more readable than
if [ ${var+set} = set ]
both are not equivalent:
the first one test if var is empty or unset
the second one test if var is unset
with bash:
$ a=1 ; [ -n $a ] echo a is not empty
a is not empty
$ a=; [ -n $a ] echo a is not empty
$ unset a ; [ -n $a ] echo a is not empty
and:
$ unset a ; [ ${a+set} = set ] echo a is set
$ a=; [ ${a+set} = set ] echo a is set
a is set
$ a=1 ; [ ${a+set} = set ] echo a is set
a is set
IMO, [ -n $var ] is equivalent to [ ${var:+set} = set ].
The first form seems to be more readable and less error prone :)
PS: what is the simplest way to test if a variable is set?
--
Nekral
Re: /etc/shells management
On Mon, Sep 08, 2003 at 03:50:38AM -0500, Branden Robinson wrote: Where did you come by this, and if it's something we should worry about, why isn't it documented in Policy? It is, but you shouldn't worry about it anyhow because nobody's crazy enough to try doing anything with a dpkg that old and current packages. It would likely fail in way much more spectacular than this, and we caution against it in the Release Notes. Do you think it would be a good idea to drop that clause from section 6.6 of Policy? I mean, in theory, Policy is supposed to document current practice, and until Manoj posted his snippet I'd never seen a Debian postinst script or portion there of that bothered to see if $2 could be 'unknown'. It should probably be demoted to a historic footnote. -- 2. That which causes joy or happiness.
Mesajiniz Alinmistir...
Merhabalar, Mesajiniz bize ulasmistir. En kisa zamanda geregi yapilacaktir. Saygilar, www.KralFerdiTayfur.com
Draw font with different size
Hello,
could you help me, please. I wrote X aplication which draw text into
window. How could I draw text with different font size? I`m able only
use fonts which are in font.aliases. And I want to draw text with size
50, 54, 60,...
// this way I do it now.
// init font
font1 = XLoadQueryFont(display,*-helvetica-*-12-*);
font2 = XLoadQueryFont(display,*-helvetica-*-18-*);
font3 = XLoadQueryFont(display,*-helvetica-*-24-*);
// draw text
void Win::DrawText(int x, int y, char *text, char *col, int fnt)
{
XFontStruct *ft;
if (fnt==FONT_SMALL) ft = font1; else
if (fnt==FONT_MEDIUM) ft = font2; else ft = font3;
XSetForeground(display, gc, get_color(col));
XSetFont(display, gc, ft-fid);
XDrawString(display, buffer, gc, x, y+ft-ascent, text, strlen(text));
}
Regards,
Tomas
debian menu system and capital letters
Hi all, A small annoyance I have with debian's menu system is an inconsistency in the naming of programs on the menus: Apps/Tools ASclock EditRes Oclock ... bbpager docker ... The ordering of the menu is dictated by the menu system rather than my window manager. I would like the menu to be alphabetical, but the existing ordering (alphanumerical I presume) would suffice if the packages all agreed on starting either with a capital or a lower-case letter. Do you think that there should be a menu policy as to the capitalisation (or general presentation) of entries? Where should the responsibility for ordering menus lie, in the menu system, or the program which exhibits a menu (E.g., the window manager)? If anyone could point me at an existing discussion of this topic I would be very grateful. -- Jon Dowland http://jon.dowland.name/
Re: unrebuildable ruby packages (Re: ruby-defaults 1.8.0)
At Sun, 7 Sep 2003 15:20:09 -0400,
Joey Hess wrote:
I'm probably the only ruby package maintainer who doesn't speak ruby.. :-)
Luckily I have eager ruby minions to take care of that part of mooix.
However, we were a bit suprised to have to make the configure script
check for libruby.so.$VERSION. Are you sure that's a good idea? Some
reason you cannot provide a libruby.so for the default version of ruby,
so that non-debian software that just links -lruby can work?
I just look into mooix source. Hmm, I think mood/Makefile should be fixed as:
ifeq (${EMBED_RUBY},yes)
SOURCES += ruby.c
CFLAGS += -DEMBED_RUBY -I`ruby -rrbconfig -e puts Config::CONFIG['archdir']`
RUBY_LINK=`ruby -rrbconfig -e 'puts Config::CONFIG[LIBRUBYARG_SHARED]n'`
endif
Here, Config::CONFIG[LIBRUBYARG_SHARED] is the appropriate linker option
to link with ruby library.
Note that -rrbconfig option is the same meaning of require 'rbconfig'
(rbconfig.rb is in /usr/lib/ruby/version/arch/rbconfig.rb)
So, once ruby-defaults becomes 1.8.x, /usr/bin/ruby will be ruby 1.8.x and
configuration parameters will be changed for ruby 1.8.x.
If it build-depends on ruby1.8 instead of ruby (and ruby1.8-dev of course),
and use /usr/bin/ruby1.8 instead of /usr/bin/ruby, you can build your
package for ruby1.8 before ruby-defaults becomes 1.8.x.
I plan to submit bug reports and/or NMU to fix this issue within a few
weeks.
I plan to release a new mooix with the ruby changes in somewhere in the
neighborhood of three weeks. If you need the changes before then I can
try to backport them.
Ok.
Regards,
Fumitoshi UKAI
pgps3RZOiRrhF.pgp
Description: PGP signature
Bug#209214: ITP: hbf -- A 3D real time strategy game based in an Heroic Fantasy realm with different races
Package: wnpp Version: unavailable; reported 2003-09-08 Severity: wishlist * Package name: hbf Version : Not yet released (CVS only) Upstream Author : Boris Lesner [EMAIL PROTECTED] * URL : http://hbf.tuxfamily.org * License : GPL Description : A 3D real time strategy game based in an Heroic Fantasy realm with different races Heroic BattleField is a 3D real time strategy game written with OpenGL and SDL. The game is based in an Heroic Fantasy realm with different races who are Good and Evil. The different races are : Humans (good), Elves, Dwarves, Humans (evil), Orcs and Undead. This is a pre-ITP since the game is not yet released. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux selmak 2.4.21 #1 Tue Aug 12 20:42:49 CEST 2003 i686 Locale: LANG=fr_FR, LC_CTYPE=fr_FR
Re: ruby-defaults 1.8.0
At Mon, 8 Sep 2003 08:19:14 +0200, Matthias Klose wrote: I've upload new ruby-defaults that make ruby 1.8.0 the debault version of ruby. I contains some new binary package so it takes time to get into unstable. You can get the new ruby-defaults from deb http://pkg-ruby.alioth.debian.org/deb/ ./ deb-src http://pkg-ruby.alioth.debian.org/deb/ ./ Note that - packages that depends on ruby ( 1.7) will be removed by dist-upgrade. It must be fixed to depend on ruby1.6, or to change dependency version if it works with ruby 1.8. - I don't recommend that package depends on libruby. Instead, ruby module package should depend on libruby1.8 or libruby1.6. - module packages that build-depends on ruby-dev MUST be fixed to use ruby1.8-dev (or ruby1.6-dev) instead of ruby-dev. I did a NMU for swig1.3 (depending on ruby). I'm wondering why make a version the default, if it does not build on all archs (powerpc). How are package maintainers supposed to handle this? what will the ruby-defaults package default to on the powerpc architecture? Oh, I didn't notice that powerpc buildd failed to build ruby1.8. However, I've successfully build ruby1.8 in pure sid environment on my friend's powerpc machine. I suspect the reason why ruby1.8 failed to be built is that powerpc buildd uses old toolchains gcc-3.3_1:3.3.2-0pre1. I use 1:3.3.2-0pre2 and ruby1.8 works fine. # dpkg -l gcc gcc-3.3 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii gcc3.3.1-2The GNU C compiler. ii gcc-3.33.3.2-0pre2The GNU C compiler Anyway, I'll upload ruby1.8_1.8.0-2_powerpc.changes, so all architectures are ready to go ruby1.8. Regards, Fumitoshi UKAI pgpmqvynVFzbH.pgp Description: PGP signature
erratic autoconf emacsen-common bug
Greetings! This turned up recently in autobuilding gcl: Setting up autoconf (2.57-10) ... ERROR: emacsen-common being used before being configured. ERROR: This is likely a bug in the autoconf package, which needs to ERROR: add one of the appropriate dependencies. ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz ERROR: for details. Funny thing is, its quite erratic. I suppose the autobuilders might leave emacsen-common configured in some circumstances? Anyway, I've filed a bug with autoconf -- is there a way I can work around this temporarily to ensure that gcl build everywhere? Pre-depending on emacsen-common comes to mind, but I think policy states that 'permission' is needed first. Advice appreciated, -- Camm Maguire[EMAIL PROTECTED] == The earth is but one country, and mankind its citizens. -- Baha'u'llah
Re: /etc/shells management
On 08-Sep-03, 03:42 (CDT), Branden Robinson [EMAIL PROTECTED] wrote: I personally stongly advocate -n and -z over [ $var ] and really horrible tests like: if [ x$var = x ] and if [ x$var != x ] Those just strike me as obscurantist (which might explain why they feature prominently in shell scripts by Ian Jackson, heh). Probably because Ian learned shell scripting in the days (or from scripts written in those days) when [ $var = foo ] was likely to cause problems when $var was undefined. So we learned to do [ X$var = Xfoo ] which leads to using '[ X$foo = X ]' to test for empty. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Single point of entry for translation work?
On Mon, Sep 08, 2003 at 07:29:27PM +1000, Matthew Palmer wrote: On Mon, Sep 08, 2003 at 11:21:00AM +0200, Andreas Metzler wrote: Matthew Palmer [EMAIL PROTECTED] wrote: On Mon, Sep 08, 2003 at 10:17:45AM +0200, Krzysztof Krzyzaniak wrote: W li?cie z pon, 08-09-2003, godz. 06:41, Matthew Palmer pisze: Is there a page somewhere that I can point people to for all translation work relating to Debian (DDTS, po-debconf, etc)? Just trying to make the debian-mentors FAQ as useful as possible... Take look at http://ddtp.debian.org/ AFAICT, that site only covers descriptions. I'm looking for somewhere (if it exists, even as a link farm) to the DDTP, Debconf, and documentation translation efforts. Check the left column, it does cover debconf. Stats [...] debconf OK, that looks good. Is there a similar coordination page or site for documentation translations? Please don't use the ddtp as entry point to translation. Use w.d.o/intl. Thanks, Mt. -- The nice thing about standards is that there are so many to choose from. And if you really don't like all the standards you just have to wait another year until the one arises you are looking for -- Tannenbaum, 'Introduction to Computer Networks'
Re: debian menu system and capital letters
On Mon, Sep 08, 2003 at 02:45:49PM +0100, Jonathan Dowland wrote: Hi all, A small annoyance I have with debian's menu system is an inconsistency in the naming of programs on the menus: Apps/Tools ASclock EditRes Oclock ... bbpager docker ... The ordering of the menu is dictated by the menu system rather than my window manager. I would like the menu to be alphabetical, but the existing ordering (alphanumerical I presume) would suffice if the packages all agreed on starting either with a capital or a lower-case letter. You can get the case ignored when ordering by adding the following to /etc/menu-methods/menu.h. sort=tolower($title) Then run update-menus to regenerate them. -- .''`. Jason Chambers [EMAIL PROTECTED] : :' : Registered linux user #271693 `. `'` `-http://www.debian.org/ - The Universal Operating System pgpgZGGaw1dj5.pgp Description: PGP signature
Re: /etc/shells management
On Mon, Sep 08, 2003 at 10:10:34AM +0100, Colin Watson wrote: On Mon, Sep 08, 2003 at 03:42:06AM -0500, Branden Robinson wrote: But if $var contains more than one shell word... You might get different results dependening on whether you remember to quote the shell variable or not. Whoa. You don't reflexively quote shell variables and have to think about when *not* to quote them? :) Certainly, if you leave the variables unquoted, 'test -n $var' is hardly any more reliable than just 'test $var', and I would trust neither against hostile input. People *should* quote their shell variables in general, yes. But this subthread is both about recommended practices and the Policy manual. It's not a Policy violation for someone to say if [ $var ], it's just a bad idea. :) -- G. Branden Robinson| Communism is just one step on the Debian GNU/Linux | long road from capitalism to [EMAIL PROTECTED] | capitalism. http://people.debian.org/~branden/ | -- Russian saying pgpifysPlySmf.pgp Description: PGP signature
Re: /etc/shells management
On Mon, Sep 08, 2003 at 11:11:34AM +0200, Andreas Metzler wrote:
I do continue to think that:
if [ -n $var ]
is more readable than
if [ ${var+set} = set ]
I agree, but usually use »[ x${var} != x ]« for no particular
reason but the fact that when reading it later I can discern its
purpose much faster than test -n or just [ $var ].
By readable, I mean exactly ease of discerning purpose.
My proposed method *is* the idiomatic way of using test(1) to check for
a non-null value. I don't defend test(1) as a miracle of clarity,
though. -h is a synonym for -L. Go figure. :-/
--
G. Branden Robinson|To Republicans, limited government
Debian GNU/Linux |means not assisting people they
[EMAIL PROTECTED] |would sooner see shoveled into mass
http://people.debian.org/~branden/ |graves. -- Kenneth R. Kahn
pgp5a35kAyv9u.pgp
Description: PGP signature
Re: ruby-defaults 1.8.0
On Mon, Sep 08, 2003 at 11:16:51PM +0900, Fumitoshi UKAI wrote: Oh, I didn't notice that powerpc buildd failed to build ruby1.8. However, I've successfully build ruby1.8 in pure sid environment on my friend's powerpc machine. I suspect the reason why ruby1.8 failed to be built is that powerpc buildd uses old toolchains gcc-3.3_1:3.3.2-0pre1. I use 1:3.3.2-0pre2 and ruby1.8 works fine. Declare a Build-Conflict on broken versions of the compiler, as I did recently with XFree86. Build-Conflicts: gcc-3.3 ( 1:3.3.2-0pre1) (Looks like the GCC regression that bit you got fixed a little later than the one that bit me.) -- G. Branden Robinson| That's the saving grace of humor: Debian GNU/Linux | if you fail, no one is laughing at [EMAIL PROTECTED] | you. http://people.debian.org/~branden/ | -- A. Whitney Brown pgpNCFEDO9MG9.pgp Description: PGP signature
Security Reseller Application - Invitation
Secure IT Systems are a leading UK based manufacturer of Physical Computer Security systems. You are invited you to become an approved reseller of the popular Proline range ( see link below ) of computer security systems. As a reseller you have... High margins - from up to 35% with a short sales cycle. No commitment to stock holding or sales targets. A proven product line to help generate new business from your existing customers. Click here to see the products: www.securewall.co.uk/[EMAIL PROTECTED]pg=prdcc=rs1txt Click here to find out more: www.securewall.co.uk/[EMAIL PROTECTED]pg=rescc=rs1txt Click here for the reseller application form: www.securewall.co.uk/[EMAIL PROTECTED]pg=formcc=rs1txt
Re: /etc/shells management
Branden Robinson wrote: test -n and -z exist for a reason, even if one has to come up with pretty dodgy mnemonics for remembering them. -n Nonzero size string -z Zero size string Dodgy mnemonics? I find them very mnemonic! Bob pgpJpoX4Xwb2h.pgp Description: PGP signature
Re: /etc/shells management
Branden Robinson wrote: I don't defend test(1) as a miracle of clarity, though. -h is a synonym for -L. Go figure. :-/ I think you can blame BSD for that one. IIRC test -h was the original option used to test for a symlink. Whoever wrote that test probably did not like upper case letters for options. The transition to -L did not come until much later. But by then all of the code that used BSD had implemented -h but never heard of -L. The implementation of -L has been playing catchup ever since. Today I can't find a system that does not implement 'test -L'. But I did find at least one commercial system that had not gotten around to documenting it that they had done it. So by reading the man page there you would still be thinking that it had not. Bob pgpHxmUdat8B0.pgp Description: PGP signature
Re: /etc/shells management
On Mon, 8 Sep 2003 03:48:37 -0500, Branden Robinson [EMAIL PROTECTED] said:
I do continue to think that:
if [ -n $var ]
is more readable than
if [ ${var+set} = set ]
...but I remain open to being directed to a section of the Policy
manual that firmly establishes my wrongness on that front as well.
:)
Now you are talking style issues.
I still code reflextively from days when the only portable way
was
if [ X$var != X ]; then foo; fi
Readability lies in the eye of the beholder; for me this is idiomatic
and eminently readable. I confess that I rarely use the ${var+set}
idiom, I don't remember why I used it in favour of the X$2 idiom
there.
manoj
--
The finest eloquence is that which gets things done.
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: installer for non-free packages in contrib
Colin Watson [EMAIL PROTECTED] a tapoté : On Mon, Sep 08, 2003 at 01:08:34PM +0200, Mathieu Roy wrote: Colin Watson [EMAIL PROTECTED] a tapot? : On Mon, Sep 08, 2003 at 09:35:45AM +0200, Mathieu Roy wrote: Would it be acceptable to fill a bug against each installer that do not build a proper debian package when installing non-free software? How can they do so? Installing a package with 'dpkg -i' in the postinst of another package isn't possible, since dpkg's status area is locked. At this point, the question is not how to do it I think it absolutely is. If something is impossible to do correctly then filing [1] bugs against packages claiming that they don't do it is rather unfair. At this point, the question is not how to do it. I can think about 30 ways to do it, while I'm surely not the expert here. So I'll rephrase my question to avoid having you being obstructive. Would it be acceptable to fill a bug against each installer that do not build a proper debian package when installing non-free software, as long as a technical solution is provided? -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: /etc/shells management
On Mon, 08 Sep 2003 11:11:34 +0200, Andreas Metzler [EMAIL PROTECTED] said: Branden Robinson [EMAIL PROTECTED] wrote: [...] The fact that a non-version-number string literal with shell redirection operators in it was a valid value of old-version, new-version, most-recently-configured-version, and so forth, did not occur to me. I'd propose a Policy amendment dropping support for this long-obsolete dpkg behavior, but I reckon I've lost my Policy-amendment-proposing credentials in your eyes. I would support it. Why? Policy does not ask you to cater to ancient versions of dpkg; it merely mentions historical behaviour, and you can't retroactively go back and change dpkg implementations from way back when. manoj who can see no reason to go back and edit working postinst scripts just to remove compatibility with improbably old versions of dpkg -- Knowledge, sir, should be free to all! Harry Mudd, I, Mudd, stardate 4513.3 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: /etc/shells management
On Mon, Sep 08, 2003 at 10:14:46AM -0600, Bob Proulx wrote: Today I can't find a system that does not implement 'test -L'. Solaris' /bin/sh didn't do so at least up to 2.9. Of course, it's not a POSIX shell in other ways anyway: for example, the lack of 'test -e' is far more annoying and harder to work around. -- Colin Watson [EMAIL PROTECTED]
Re: /etc/shells management
Hi,
[I apologize for following up to this mail a second time;; I
should not post before I have had coffee]
On Mon, 8 Sep 2003 03:48:37 -0500, Branden Robinson [EMAIL PROTECTED] said:
I do continue to think that:
if [ -n $var ]
is more readable than
if [ ${var+set} = set ]
...but I remain open to being directed to a section of the Policy
manual that firmly establishes my wrongness on that front as well.
:)
As Nicolas François pointed out, the difference is between an
empty, but set, variable, and an unset variable. (so, an empty $2
means no recently configured version, an unset $2 means this is an
ancient dpkg. Not that most people care for these distinctions
anymore).
manoj
glad to have reconstituted the logic behind the odd construct
--
Truth is the most valuable thing we have -- so let us economize
it. Mark Twain
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Bug 70132 (on atari-fdisk)
This is a very old FTBFS bug (28 Aug 2000), which was closed in 23 Aug 2003 and reopened in 3 Sep 2003. After this, Frank Lichtenheld comments: Hi. I verified that it builds correctly with an added Build-Depends to debhelper. But before producing a NMU patch I wonder if this package should be orphaned. Last upload 2 years ago was a NMU, a few simple to fix, long outstanding bugs... I agree with Frank. This is quite an old bug, I also managed to build it correctly with debhelper. I think this should be brought to debian-devel. Does anyone object orphaning this package? Is anyone willing to adopt it? It is a base package, priority required for m68k, and otherosfs priority: extra for all other architectures. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: installer for non-free packages in contrib
On Mon, Sep 08, 2003 at 06:42:46PM +0200, Mathieu Roy wrote: [Please stop sending me private copies of list mail.] Colin Watson [EMAIL PROTECTED] a tapot? : On Mon, Sep 08, 2003 at 01:08:34PM +0200, Mathieu Roy wrote: Colin Watson [EMAIL PROTECTED] a tapot? : On Mon, Sep 08, 2003 at 09:35:45AM +0200, Mathieu Roy wrote: Would it be acceptable to fill a bug against each installer that do not build a proper debian package when installing non-free software? How can they do so? Installing a package with 'dpkg -i' in the postinst of another package isn't possible, since dpkg's status area is locked. At this point, the question is not how to do it I think it absolutely is. If something is impossible to do correctly then filing [1] bugs against packages claiming that they don't do it is rather unfair. At this point, the question is not how to do it. I can think about 30 ways to do it, while I'm surely not the expert here. I asked you a question which could be answered quite simply by producing one of those ways. Go on. It's my honest belief that it can't be done correctly; I'm open to hearing ways in which I'm wrong. So I'll rephrase my question to avoid having you being obstructive. Er, I'm not being obstructive! I'm trying to figure out if there's any point to your proposed mass-bug-filing. Would it be acceptable to fill a bug against each installer that do not build a proper debian package when installing non-free software, as long as a technical solution is provided? I guess so, if the technical solution is correct. Severity something less than release-critical, though. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: debian menu system and capital letters
On Mon, Sep 08, 2003 at 04:10:20PM +0100, Jason Chambers wrote: You can get the case ignored when ordering by adding the following to /etc/menu-methods/menu.h. sort=tolower($title) Then run update-menus to regenerate them. I've had a play around with this, and found that putting a custom menu.h in ~/.menu-methods works for a user. However, I then need to keep up-to-date copies of anything from /etc/menu-methods/ in this directory too, if I want a menu generated. Is it currently impossible to override some, but not all of the /etc/menu-methods folder, on a user-by-user basis? Thanks for your help, -- Jon Dowland http://jon.dowland.name/
Re: Bug 70132 (on atari-fdisk)
On Mon, Sep 08, 2003 at 12:01:39PM -0500, Gunnar Wolf wrote: This is a very old FTBFS bug (28 Aug 2000), which was closed in 23 Aug 2003 and reopened in 3 Sep 2003. After this, Frank Lichtenheld comments: I verified that it builds correctly with an added Build-Depends to debhelper. But before producing a NMU patch I wonder if this package should be orphaned. Last upload 2 years ago was a NMU, a few simple to fix, long outstanding bugs... I agree with Frank. This is quite an old bug, I also managed to build it correctly with debhelper. I think this should be brought to debian-devel. Does anyone object orphaning this package? Is anyone willing to adopt it? It is a base package, priority required for m68k, and otherosfs priority: extra for all other architectures. It seems clear that the package has already been orphaned; filing a bug against wnpp for it is merely a formality. ISTR that Roman is not actively involved in m68k development anymore, so it wouldn't surprise me that he's not taking an interest in this package. -- Steve Langasek postmodern programmer pgpfmNHydF7OV.pgp Description: PGP signature
Re: /etc/shells management
On Sun, 7 Sep 2003, Guido Guenther wrote: On Sun, Sep 07, 2003 at 10:23:15AM -0500, Branden Robinson wrote: if [ -n $var ]; then fi Just of out curiosity, is this in any way different from the shorter: if [ $var ]; then fi var=-f
Bug#209257: debian menu system and capital letters
Package: menu Severity: normal On Mon, Sep 08, 2003 at 04:10:20PM +0100, Jason Chambers [EMAIL PROTECTED] was heard to say: On Mon, Sep 08, 2003 at 02:45:49PM +0100, Jonathan Dowland wrote: Hi all, A small annoyance I have with debian's menu system is an inconsistency in the naming of programs on the menus: Apps/Tools ASclock EditRes Oclock ... bbpager docker ... The ordering of the menu is dictated by the menu system rather than my window manager. I would like the menu to be alphabetical, but the existing ordering (alphanumerical I presume) would suffice if the packages all agreed on starting either with a capital or a lower-case letter. You can get the case ignored when ordering by adding the following to /etc/menu-methods/menu.h. sort=tolower($title) This should be the default. Filing a severity 'normal' bug because case-sensitive sorting here is absolutely terrible UI. [when case has an agreed-upon meaning, as in Unix filenames, there may be some justification, but when it's just haphazard, as in menu files, it should be ignored] There is probably an argument for consistent capitalization on aesthetic grounds, but I'll let someone else make it. Daniel -- / Daniel Burrows [EMAIL PROTECTED] ---\ |Do you know why the prisoner in the | | tower watches the flight of birds? | | -- Terry Pratchett, _Reaper_Man_ | \ Be like the kid in the movie! Play chess! -- http://www.uschess.org ---/
Re: imformation leakage in debian binaries
On Sat, 23 Aug 2003, Joey Hess wrote: It's interesting to examine what information about maintainers' build environments slips into binary packages, and consider the possible consequences and what, if anything, we can do about it. Here's an annotated and edited version of the output of the command strings -f /usr/bin/* /usr/sbin/* /bin/* /usr/lib/* /lib/* /sbin/* | \ egrep '/home/.*/' | sort | uniq If you're only interested in checking your own packages, I suggest instead, for d in *.deb; do dpkg-deb --fsys-tarfile $d | zgrep -a $HOME ; done /sbin/start-stop-daemon: /mount/md0/home/adam/debian/mine/dpkg/v1_10/dpkg-1.10.10/utils/start-stop-daemon.c # Given the __assert_fail in the symbol table, this is probably # displayed as part of an assertian. One of the more common cases. # # Of course this leaves the user wondering why the program is # complaining about this adam person and his nonexistent home # directory. Hmm, raid0? # # Note that assert only puts the full path to a file in if you give that # full path to gcc. A minor modification to dpkg's Makefiles would # convert this into just utils/start-stop-daemon.c and save us all a # few bytes. I'll skip the other ~50 copies in dpkg, dselect, etc. I've thought about doing this for dpkg's build system, before, because of the long path that is encoded. I'll probably be part of dpkg 2.0.
Re: imformation leakage in debian binaries
On Mon, 8 Sep 2003, Adam Heath wrote: On Sat, 23 Aug 2003, Joey Hess wrote: It's interesting to examine what information about maintainers' build environments slips into binary packages, and consider the possible consequences and what, if anything, we can do about it. Here's an annotated and edited version of the output of the command strings -f /usr/bin/* /usr/sbin/* /bin/* /usr/lib/* /lib/* /sbin/* | \ egrep '/home/.*/' | sort | uniq If you're only interested in checking your own packages, I suggest instead, for d in *.deb; do dpkg-deb --fsys-tarfile $d | zgrep -a $HOME ; done /sbin/start-stop-daemon: /mount/md0/home/adam/debian/mine/dpkg/v1_10/dpkg-1.10.10/utils/start-stop-daemon.c # Given the __assert_fail in the symbol table, this is probably # displayed as part of an assertian. One of the more common cases. # # Of course this leaves the user wondering why the program is # complaining about this adam person and his nonexistent home # directory. Hmm, raid0? # # Note that assert only puts the full path to a file in if you give that # full path to gcc. A minor modification to dpkg's Makefiles would # convert this into just utils/start-stop-daemon.c and save us all a # few bytes. I'll skip the other ~50 copies in dpkg, dselect, etc. I've thought about doing this for dpkg's build system, before, because of the long path that is encoded. I'll probably be part of dpkg 2.0. Ok. I have it fixed. bash-2.05b$ strings build/src/lib/tests/hashtable-test |grep hashtable-test.c ../../../src/lib/tests/hashtable-test.c I might be able to fix it even better, by overriding __FILE__ myself(with -D) on the cmdline, instead of letting it be filled in by cpp from -c.
Re: debian menu system and capital letters
On Mon, Sep 08, 2003 at 05:57:16PM +0100, Jonathan Dowland wrote: On Mon, Sep 08, 2003 at 04:10:20PM +0100, Jason Chambers wrote: You can get the case ignored when ordering by adding the following to /etc/menu-methods/menu.h. sort=tolower($title) Then run update-menus to regenerate them. I've had a play around with this, and found that putting a custom menu.h in ~/.menu-methods works for a user. However, I then need to keep up-to-date copies of anything from /etc/menu-methods/ in this directory too, if I want a menu generated. Is it currently impossible to override some, but not all of the /etc/menu-methods folder, on a user-by-user basis? No. According to section 5.1 in the menu documentation /etc/menu-methods is ignored if the user has a ~/.menu-methods. -- .''`. Jason Chambers [EMAIL PROTECTED] : :' : Registered linux user #271693 `. `'` `-http://www.debian.org/ - The Universal Operating System pgpZGbMeljhRN.pgp Description: PGP signature
Re: installer for non-free packages in contrib
Colin Watson wrote: ? I think that's a minimal specification for a correct installer package which does its work by creating Debian packages; unless you think that it's better for the installer package to spit out a .deb somewhere which you then have to install separately, which seems to me like a step backwards in convenience. Cheers, As a user, it always is my expectation that an installer package won't actually install the package in its postinst, but rather just install a script that needs to be run separately in order to fetch the binary, build a deb, and install the deb(perhaps just put a 'su -c dpkg -i created.deb' at the end of the script) or make you then install the deb[like the nvidia drivers used to work]. Fetching the binary takes a significant amount of bandwidth and would be annoying during the install of the installer when you may be installing other packages as well and are not necessarily connected to the internet. pgp18TYXBVMLq.pgp Description: PGP signature
Re: unrebuildable ruby packages (Re: ruby-defaults 1.8.0)
On Mon, Sep 08, 2003 at 04:01:31AM +0900, Fumitoshi UKAI wrote: As Marcelo pointed out on Bug#209052, ruby-dev has been obsoleted, so packages that build-depend on ruby-dev can't be built now. We have ruby1.6-dev (for ruby1.6) and ruby1.8-dev (for ruby1.8), so please rebuild your packages to use ruby1.6-dev and/or ruby1.8-dev. I've uploaded libyaml-ruby_0.49.1-2 and libdbd-ruby_0.0.20-3 which follow the Debian Ruby Policy. I see no point in uploading new libjttui-ruby, since I've orphaned this package (see #206718) and it should not go into Debian/stable in its current form anyway (it is unused and its upstream is inactive for well over a year). Four of new Ruby/DBI packages, libdbd-pg-ruby1.6, libdbd-pg-ruby1.8, libdbd-mysql-ruby1.6, and libdbd-mysql-ruby1.8 depend on libpgsql-ruby and libmysql-ruby, respectively. This is required for these packages to be installable right now, but is obviously not correct: current versions of libpgsql-ruby and libmysql-ruby provide modules only for Ruby 1.6, and upcoming versions will expectedly depend on -ruby1.6 variants, and later on -ruby1.8 variants. Hence: Taku, Christian, Please let me know when you upload new modules for both Ruby 1.6 and Ruby 1.8, so that I can upload DBDs with correct dependencies. Or let me know if you don't have time to do it and approve someone to NMU it for you; beware that adopting these packages to the Ruby policy will require major changes to their build system, thus it's better that you do it yourselves. -- Dmitry Borodaenko
bitmap vectorizers
[ note: I have no interests in denying any of those packages, there is ] [ a result of digging through wnpp bugs] Hello, There are two packages looking similar: #206859: O: autotrace -- Bitmap to vector graphics converter #208508: ITP: potrace -- utility to transform bitmaps into vector graphics Maybe them should be compared and better one schould be choosed? Cheers Artur -- http://hell.pl/arturcz/
python (parted) question
[no response from debian-python, trying my luck here] I've been banging my head against a python problem in a package I'm interested in for quite a while trying to fix a bug. I'm certainly not a python expert, so maybe someone here can help... I have python + python-parted + libparted1.6, all current versions from unstable. Given the above, I need to generate a simple partitioning script. It should be something like: - init parted - get probed Device - get Disk from Device - create Partition on Disk - create Filesystem on Partition - :wq! Assuming I dont need any error-checking at this point, the above should be fairly straight forward. I've studied pgi and some other python tools and I'm still up against a road block. Whenever I try to create a Partition it returns an error that it is unable to do so. Any help or pointers to basic, easy to understand, examples would be much appreciated. Thanks, -- Paul Telford | 1024D/431B38BA | [EMAIL PROTECTED] | [EMAIL PROTECTED] C903 0E85 9AF5 1B80 6A5F F169 D7E9 4363 431B 38BA
[ruby] SURVEY: which ruby module packages should support both ruby1.6 and ruby1.8?
Hi, I'd like to ask you which ruby module packages should support both ruby1.6 and ruby1.8 until ruby1.6 is removed from archive. Some ruby module packages are used for specific ruby applications. In such case, we can safely remove ruby1.6 support from these ruby module packages. However, some ruby module packages, such as xml parsers, are widely used for several ruby applications and other ruby modules. I think it is nice that such ruby modules are built for both ruby1.6 and ruby1.8. Which ruby packages do you want to keep ruby1.6 support? Regards, Fumitoshi UKAI pgpANoi638zZj.pgp Description: PGP signature
Re: [Fwd: False Representation at Google.com]
I demand that Branden Robinson may or may not have written... On Sun, Sep 07, 2003 at 11:02:09AM +1000, Russell Coker wrote: It wan't asking for help, it was asking that we change the way we do things for their minor benefit. Thinking that the world revolves around yourself is a serious attitude problem, and not something that we want to pander to. Precisely. As all right-thinking people know, the world revolves around *me*. Not possible. You'd have to be made of compact matter, and I'm quite sure that somebody would have noticed the gravitational effects by now... ;-) -- | Darren Salt | nr. Ashington, | linux (or ds) at | woody, sarge, | Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | Oh, sarge too... As the dyslexic Jedi said, Sith happens.
Re: python (parted) question
On Mon, Sep 08, 2003 at 11:52:35AM -0700, Paul Telford wrote: [no response from debian-python, trying my luck here] [...snip vague problem report...] You probably didn't get a response because you didn't provide any information about 1) the code you are running, or 2) what actually happens when you run it (no, it returns an error is not sufficient). -- - mdz
Jemand hat Dir eine Nachricht geschickt! ID Xscaadsvlv
Hi und Hallo, Ihnen wurde eine Einladung (Kennung Japdwrdq) über unser Online Kontakt System zugesendet! Um Ihre Einladung anzunehmen, klicken Sie auf folgende Webseite: Webseite: http://www.topfreespace.com/KontaktBox/ Viel Spass Erfolg Service Team Online Kontakt Systeme HINWEISE: Sie erhalten diese E-Mail nicht direkt von uns, sondern ein Bekannter oder Freund hat Ihnen diese über unser System geschickt! Da viele Nachrichten auch erotisches Material beinhalten, müssen Sie mind. 18 Jahre alt sein um unseren Service nutzen zu dürfen!
Re: Bug 70132 (on atari-fdisk)
Op ma 08-09-2003, om 19:46 schreef Steve Langasek: It seems clear that the package has already been orphaned; filing a bug against wnpp for it is merely a formality. ISTR that Roman is not actively involved in m68k development anymore, so it wouldn't surprise me that he's not taking an interest in this package. Actually, Roman is still the buildd admin for kullervo. That doesn't mean he's terribly active, but he's still involved. I would pick up the package if I had an atari, which I don't. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: /etc/shells management
Manoj Srivastava [EMAIL PROTECTED] wrote: On Mon, 08 Sep 2003 11:11:34 +0200, Andreas Metzler [EMAIL PROTECTED] said: Branden Robinson [EMAIL PROTECTED] wrote: [...] The fact that a non-version-number string literal with shell redirection operators in it was a valid value of old-version, new-version, most-recently-configured-version, and so forth, did not occur to me. I'd propose a Policy amendment dropping support for this long-obsolete dpkg behavior, but I reckon I've lost my Policy-amendment-proposing credentials in your eyes. I would support it. Why? Hello, It is cruft and policy has over 300KB. Afaik policy's purpose is not to document historical behaviour in dpkg but technical requirements for packages in Debian. Policy does not ask you to cater to ancient versions of dpkg; it merely mentions historical behaviour, and you can't retroactively go back and change dpkg implementations from way back when. The simple fact that it is documented in policy without big fat markers Don't implement today, this is *ancient* dpkg, it is useless today makes it a suggestion. I recently modified some postinst and (following policy) added the nowadays completely useless test for 'unknown' because I did not check dpkg's changelog ATM. [o] Stupid [o] Overzealous [o] Avoidable who can see no reason to go back and edit working postinst scripts just to remove compatibility with improbably old versions of dpkg Removing the paragraph from policy would not force you to edit working postinst scripts. cu andreas
Re: imformation leakage in debian binaries
On Mon, 8 Sep 2003, Adam Heath wrote: Ok. I have it fixed. bash-2.05b$ strings build/src/lib/tests/hashtable-test |grep hashtable-test.c ../../../src/lib/tests/hashtable-test.c I might be able to fix it even better, by overriding __FILE__ myself(with -D) on the cmdline, instead of letting it be filled in by cpp from -c. Btw, for those who want to fix this in their own source, when making the build directory, and then calling configure, use a relative path to the location of configure. The relative path will then be used in the encoding of $srcdir, and standard rules should be able to cope with it.
Re: python (parted) question
On Mon, 8 Sep 2003, Matt Zimmerman wrote: You probably didn't get a response because you didn't provide any information about 1) the code you are running, or 2) what actually happens when you run it (no, it returns an error is not sufficient). Fair enough. I should have been more descriptive... The code in question is autoinstall. I'm trying to get it working with the latest version of libparted as 1.4 doesn't exist in unstable anymore. Upon trying to create a partition, the return code is 'None'. Unfortunately, there doesn't seem to be any more verbose output available. I'm using the exact same syntax as with libparted1.4, so maybe the library upgrade requires a change in my script? If so, its not obvious from any documentation or changelogs that I have found. Regards, -- Paul Telford | 1024D/431B38BA | [EMAIL PROTECTED] | [EMAIL PROTECTED] C903 0E85 9AF5 1B80 6A5F F169 D7E9 4363 431B 38BA
Re: Bug#209116: exim daemon does not restart after last two security upgrades
Zygo Blaxell wrote: I have exim configured in daemon mode and I use xinetd instead of inetd. The last two security updates left me with no running exim daemon and nothing listening in port 25. The latest one was nice enough to create an /etc/inetd.conf that was empty except for this line: smtpstream tcp nowait mail/usr/sbin/exim exim -bs That is expected behaviour. The postinst runs update-inetd to install in inetd.conf if it isn't there already. It can't tell that you've deliberately deleted it, so helpfully creates one for you. The startup script for the daemon only runs it if it isn't running from inetd, in order that you don't get both trying to run. I suppose I could check that inetd is running, though that would only work if exim starts before inetd (which by default it will, but I wouldn't want to rely on that always being the case, especially since there's no obvious reason why it should matter). Had you left an inetd.conf file with a commented-out exim entry, all would be well. Having said that the behaviour is expected, that doesn't mean that it's nice. Partly this is due to what I would consider to be flaws in the design of update-inetd, partly due to an inevitable result of using inetd, and probably also partly my fault. I wish I had never supported using inetd, but it's a bit late to change that now. The exim package is nearing the end of its life (it will remain in the next debian release, but will no longer be the default mailer, as exim4 will replace it), This means that a) I'm not inclined to put a lot of effort into changes to the package, and b) I don't want to do anything that increases the risks of upgrade. So I don't want to force people to run as a daemon or any other major change like that. However, I am open to suggestions for minor changes that will make things easier for users like this, which is why I've copied this to debian-devel. One I am considering is only running update-inetd --add on a new install, and just update-inetd --enable on an upgade. I think this should solve this particular problem; what do people think of it? The other common problem, which it wouldn't solve, is people who think that using update-inetd to disable something is a good idea - update-inetd should only be used by maintainer scripts, but this isn't made clear enough to users. So they disable something using it, and then are surprised when it comes back on an upgade. [Debian-devel: note that this is also copied to the bug report. Leave this in or take it out of your replies as appropriate. Please leave me in anyway as I don't normally read debian-devel. Oh, and thanks in advance for your help]
Re: python (parted) question
On Mon, Sep 08, 2003 at 01:15:03PM -0700, Paul Telford wrote: On Mon, 8 Sep 2003, Matt Zimmerman wrote: You probably didn't get a response because you didn't provide any information about 1) the code you are running, or 2) what actually happens when you run it (no, it returns an error is not sufficient). Fair enough. I should have been more descriptive... I should have been more specific. If you expect the members of the list to understand your problem, you need to send a copy of the actual code which has the problem, and the exact result when you run it. The real thing is far more useful than a description of it in your own words. The code in question is autoinstall. I'm trying to get it working with the latest version of libparted as 1.4 doesn't exist in unstable anymore. I don't know what autoinstall is, and am not motivated to go out and find it just to be able to answer your question. Upon trying to create a partition, the return code is 'None'. The return code from what? What function did you call, and what parameters did you pass to it? -- - mdz
Re: Mcrypt maintainer.
On Fri, Sep 05, 2003 at 03:53:58PM -0500, Andrés Roldán wrote: Is the mcrypt maintainer MIA? The last mcrypt package was released the last year (November) and there are newer mcrypt and libmcrypt upstream releases. Ask [EMAIL PROTECTED] -- Francesco P. Lovergine
Re: Bug#209116: exim daemon does not restart after last two security upgrades
On Mon, Sep 08, 2003 at 09:04:29PM +0100, Mark Baker wrote: The startup script for the daemon only runs it if it isn't running from inetd, in order that you don't get both trying to run. I suppose I could check that inetd is running, though that would only work if exim starts before inetd (which by default it will, but I wouldn't want to rely on that always being the case, especially since there's no obvious reason why it should matter). I don't much like the way the exim init script tries to do this, and prefer to leave the decision firmly in the hands of the system administrator. I'm currently testing a patched init script (patch attached FYI) and some defaults in /etc/default/exim: RUN_DAEMON=YES LISTEN_ARGS=-bd QUEUE_ARGS=-q30m Of course, if you're using this and running inetd, you have to make sure the exim maintainer scripts don't try to start exim from inetd, and might also want to disable the queue-runner cron jobs. Ideally, these choices would be managed by debconf, and the package postinst obey the debconf settings. I haven't looked at the exim4 packages, so apologies if you've already thoguht through these issues and come up with a cunning solution! -- Ray Miller, Unix Systems Programmer Team Leader Systems Development Support, Oxford University Computing Services --- /etc/init.d/exim.ORI Mon Mar 4 23:05:40 2002 +++ /etc/init.d/eximMon Sep 8 15:31:39 2003 @@ -1,27 +1,32 @@ #! /bin/sh # /etc/init.d/exim # # Written by Miquel van Smoorenburg [EMAIL PROTECTED]. # Modified for Debian GNU/Linux by Ian Murdock [EMAIL PROTECTED]. # Modified for exim by Tim Cutts [EMAIL PROTECTED] set -e -# Exit if exim runs from /etc/inetd.conf -if [ -f /etc/inetd.conf ] grep -q ^ *smtp /etc/inetd.conf; then -exit 0 -fi - +DEFAULTS=/etc/default/exim DAEMON=/usr/sbin/exim NAME=exim -test -x $DAEMON || exit 0 +# Read in some defaults +if [ -f $DEFAULTS ] +then +. $DEFAULTS +fi + +[ -x $DAEMON ] [ $RUN_DAEMON = YES ] || exit 0 case $1 in start) echo -n Starting MTA: start-stop-daemon --start --pidfile /var/run/exim/exim.pid \ - --exec $DAEMON -- -bd -q30m + --exec $DAEMON -- $LISTEN_ARGS $QUEUE_ARGS echo exim. ;; stop) @@ -35,7 +40,7 @@ start-stop-daemon --stop --pidfile /var/run/exim/exim.pid \ --oknodo --retry 30 --exec $DAEMON start-stop-daemon --start --pidfile /var/run/exim/exim.pid \ - --exec $DAEMON -- -bd -q30m + --exec $DAEMON -- $LISTEN_ARGS $QUEUE_ARGS echo exim. ;; reload|force-reload)
music sheet
Do you have the sheet music for dueling banjos? I would like to get it if possible. db
Re: Bug#209116: exim daemon does not restart after last two security upgrades
Ray Miller [EMAIL PROTECTED] wrote: On Mon, Sep 08, 2003 at 09:04:29PM +0100, Mark Baker wrote: The startup script for the daemon only runs it if it isn't running from inetd, in order that you don't get both trying to run. I suppose I could check that inetd is running, though that would only work if exim starts before inetd (which by default it will, but I wouldn't want to rely on that always being the case, especially since there's no obvious reason why it should matter). I don't much like the way the exim init script tries to do this, and prefer to leave the decision firmly in the hands of the system administrator. I'm currently testing a patched init script (patch attached FYI) and some defaults in /etc/default/exim: RUN_DAEMON=YES LISTEN_ARGS=-bd QUEUE_ARGS=-q30m Of course, if you're using this and running inetd, you have to make sure the exim maintainer scripts don't try to start exim from inetd, and might also want to disable the queue-runner cron jobs. Ideally, these choices would be managed by debconf, and the package postinst obey the debconf settings. I don't see any bonus in managing these little details with debconf. I haven't looked at the exim4 packages, so apologies if you've already thoguht through these issues and come up with a cunning solution! The exim4 init-script contains a similar test as exim3 for inetd, which might have been a good or bad idea - I don't know for sure but changing it now would require all the brave souls who had hand-edited inetd.conf to make exim4 run with inetd to also edit the init-script. The init-script supports a default file, supporting your options and more (actually it is that complicated to prepare for mailfilter interaction). There is nothing cunning about it, though. ;-) cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: music sheet
On Mon, Sep 08, 2003 at 03:50:25PM -0600, Brown, Darryl JU0 wrote: Do you have the sheet music for dueling banjos? I would like to get it if possible. If you spelt it differently - Duelling Banjos - you'd get some nice hits at Google for Duelling Banjos sheet music. - Matt
bug report #208857 disappeard ?
I don't understand why but I am unable to find a bug report I filled 3 days ago. Can someone explain me what happen? http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=208857 See below the ack from bugs.debian.org. I even submitted more info (a full trace that took me a long time to get). Christophe -Message suivi- From: Debian Bug Tracking System [EMAIL PROTECTED] To: christophe barbe [EMAIL PROTECTED] Subject: Bug#208857: Acknowledgement (gimp1.3: Segfault on Layer Mask in Layer Dialog on PowerPC) Date: 05 Sep 2003 12:33:06 -0500 Thank you for the problem report you have sent regarding Debian. This is an automatically generated reply, to let you know your message has been received. It is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Ari Pollak [EMAIL PROTECTED] If you wish to submit further information on your problem, please send it to [EMAIL PROTECTED] (and *not* to [EMAIL PROTECTED]). Please do not reply to the address at the top of this message, unless you wish to report a problem with the Bug-tracking system. Debian bug tracking system administrator (administrator, Debian Bugs database) -- Christophe Barbe [EMAIL PROTECTED] GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: music sheet
On Tue, 9 Sep 2003 08:14:59 +1000 Matthew Palmer [EMAIL PROTECTED] wrote: Do you have the sheet music for dueling banjos? I would like to get it if possible. If you spelt it differently - Duelling Banjos - you'd get some nice hits at Google for Duelling Banjos sheet music. - Matt The problem, amazingly enough, is that he did google for dueling banjos sheet music, and Debian is the number one and number two hit! This has become a self-perpetuating google-flop. People google, google points them to Debian to get this sheet music, and the act of asking reinforces google's notion that debian is a good place to get the music! Jim Penny
Re: unrebuildable ruby packages (Re: ruby-defaults 1.8.0)
Fumitoshi UKAI wrote: I just look into mooix source. The released source that is. RUBY_LINK=`ruby -rrbconfig -e 'puts Config::CONFIG[LIBRUBYARG_SHARED]n'` [EMAIL PROTECTED]:~ruby -rrbconfig -e 'puts Config::CONFIG[LIBRUBYARG_SHARED]' nil [EMAIL PROTECTED]:~ruby -v ruby 1.6.8 (2003-07-09) [i386-linux] -- see shy jo pgppUJsVdAAeJ.pgp Description: PGP signature
Re: music sheet
On Mon, Sep 08, 2003 at 06:55:31PM -0400, Jim Penny wrote: Do you have the sheet music for dueling banjos? I would like to get it if possible. If you spelt it differently - Duelling Banjos - you'd get some nice hits at Google for Duelling Banjos sheet music. The problem, amazingly enough, is that he did google for dueling banjos sheet music, You missed the spelling detail -- one l vs two. With the latter, Debian list archives aren't in the top ten. Of course, Matthew's post with the other spelling will now probably muddy that distinction, too. :) -- 2. That which causes joy or happiness.
Re: bug report #208857 disappeard ?
On Mon, Sep 08, 2003 at 06:26:27PM -0400, Christophe Barbe wrote: I don't understand why but I am unable to find a bug report I filled 3 days ago. Can someone explain me what happen? http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=208857 ~~~ ~~~ s/pkg/bug/g; -- 2. That which causes joy or happiness.
Re: music sheet
On Mon, Sep 08, 2003 at 06:55:31PM -0400, Jim Penny wrote: On Tue, 9 Sep 2003 08:14:59 +1000 Matthew Palmer [EMAIL PROTECTED] wrote: Do you have the sheet music for dueling banjos? I would like to get it if possible. If you spelt it differently - Duelling Banjos - you'd get some nice hits at Google for Duelling Banjos sheet music. - Matt The problem, amazingly enough, is that he did google for dueling banjos sheet music, and Debian is the number one and number two hit! Thanks for that, but you're speaking to a man well steeped in Duelling Banjos/Debian lore, having been around for many iterations of the famous banjos. I just decided this time to give the poor sod a bit of help - and maybe, just maybe, get this thread to the top of the list instead. - Matt
Re: music sheet
On Tue, Sep 09, 2003 at 01:00:11AM +0200, Josip Rodin wrote: On Mon, Sep 08, 2003 at 06:55:31PM -0400, Jim Penny wrote: Do you have the sheet music for dueling banjos? I would like to get it if possible. If you spelt it differently - Duelling Banjos - you'd get some nice hits at Google for Duelling Banjos sheet music. The problem, amazingly enough, is that he did google for dueling banjos sheet music, You missed the spelling detail -- one l vs two. With the latter, Debian list archives aren't in the top ten. Of course, Matthew's post with the other spelling will now probably muddy that distinction, too. :) Aaaah crap, didn't think of that. Of course, with all the quoting, we're pushing it ever higher... - Matt
Re: /etc/shells management
On Mon, Sep 08, 2003 at 12:59:24PM -0500, Adam Heath wrote: On Sun, 7 Sep 2003, Guido Guenther wrote: On Sun, Sep 07, 2003 at 10:23:15AM -0500, Branden Robinson wrote: if [ -n $var ]; then fi Just of out curiosity, is this in any way different from the shorter: if [ $var ]; then fi var=-f Have you tried that? No POSIX shell will have a problem. -- Colin Watson [EMAIL PROTECTED]
Re: bug report #208857 disappeard ?
On Tue, Sep 09, 2003 at 01:01:11AM +0200, Josip Rodin wrote: On Mon, Sep 08, 2003 at 06:26:27PM -0400, Christophe Barbe wrote: I don't understand why but I am unable to find a bug report I filled 3 days ago. Can someone explain me what happen? http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=208857 ~~~ ~~~ s/pkg/bug/g; Or just use the short URL (http://bugs.debian.org/208857) if you can't remember the full forms. -- Colin Watson [EMAIL PROTECTED]
Re: IMPORTANT: your message to html-tidy
on Mon, Sep 08, 2003 at 03:40:15PM +1000, Matthew Palmer ([EMAIL PROTECTED]) wrote: On Mon, Sep 08, 2003 at 06:04:39AM +0100, Karsten M. Self wrote: on Mon, Sep 08, 2003 at 01:57:54PM +1000, Matthew Palmer ([EMAIL PROTECTED]) wrote: [W3C's autoresponder] This one's a bit different. It's only asking for permission to archive posts to the list - I guess W3C's just trying, as hard as possible, to avoid any possible legal problems. It's still an instance in which the autoresponse would not have been triggered had any half-decent AV/AS system been used to filter out spam and viruses. This was a response to the SoBig.F worm. Sorry, I didn't make my position sufficiently clear. This system is as broken as every other Challenge-Response, in that it has the potential to annoy the shit out of a lot of people very easily, and become a nice anonymous harassing agent. I was just making the point that it isn't the same as a regular C-R system, in that the intent wasn't so much to say I want to make sure you're not a spammer and more I want to make sure you agree to your posts being publically archived - at the very least it's a little less offensive than normal (it's not saying You're a spammer - prove me wrong!). Agreed. This is the difference between broken-by-configuration, and broken-by-design. I wasn't saying that the problem was identical to that of C-R, only that _any_ autoresponder should make reasonable efforts not to do Joe-Jobs. MTA behavior can be fixed (or at least greatly remedied) by filtering. C-R cannot as it assumes the solution to the problem is to offload the authentication on a third party, itself unverified, unknown, unauthenticated, and untrusted. Peace. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What Part of Gestalt don't you understand? The truth behind the H-1B IT indentured servant scam: http://heather.cs.ucdavis.edu/itaa.real.html pgpWSd5psg75u.pgp Description: PGP signature
Re: music sheet
On Tue, Sep 09, 2003 at 09:11:09AM +1000, Matthew Palmer wrote: On Tue, Sep 09, 2003 at 01:00:11AM +0200, Josip Rodin wrote: On Mon, Sep 08, 2003 at 06:55:31PM -0400, Jim Penny wrote: Do you have the sheet music for dueling banjos? I would like to get it if possible. If you spelt it differently - Duelling Banjos - you'd get some nice hits at Google for Duelling Banjos sheet music. The problem, amazingly enough, is that he did google for dueling banjos sheet music, You missed the spelling detail -- one l vs two. With the latter, Debian list archives aren't in the top ten. Of course, Matthew's post with the other spelling will now probably muddy that distinction, too. :) Aaaah crap, didn't think of that. Of course, with all the quoting, we're pushing it ever higher... why dont we just put up a page on www.debian.org with the requested sheet music (or, if it's copyrighted then appropriate links to sites where it can be found). we could also put the tale of Google and The Dueling Banjos on the same page. then make sure that there are enough links to this page that it gets the highest rank on google (perhaps by editing the archives to include a link in every page that mentions the song). craig ps: i just searched google for it myself and debian is down to 6th 7th place.
autoconf and setting prefix
Hi, I don't know if this has been asked before or not, but I couldn't
find anything using google.
I'm trying to build a gcc 3.3.1 cross compiler package for woody, so I
use the following line in debian/rules
(cd build ../configure --target=arm-linux --enable-target-optspace
--enable-languages=c,c++,java --disable-multilib --disable-threads
--with-gnu-ld --disable-nls --disable-shared --host=$(DEB_HOST_GNU_TYPE)
--build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr
--includedir=\$${prefix}/arm-linux/include
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info )
from debian/rules install line
(cd build $(MAKE) install prefix=$(CURDIR)/debian/gcc4arm/usr)
When I get to this install line, it tries to install includes to
/usr/arm-linux/include, instead of
$(CURDIR)/debian/gcc4arm/usr/arm-linux/include
Is this a problem with autoconf/automake? Has anyone run into this
before?
I've already made cross compiling packages for binutils, kernel headers,
and a C library, which all use /usr/arm-linux as the base for arm
libraries headers, and I'm currently trying to get the c++ and java
cross compilers built.
--
David Meggy
Engineering
Technical Solutions Inc.
Unit #1 7157 Honeyman St
Delta BC Canada, V4G 1E2
www.techsol.ca
eMail: [EMAIL PROTECTED]
Tel: 604 946 TECH (8324)
Fax: 604 946 6445
Re: autoconf and setting prefix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On September 08, 2003 20:28, David Meggy wrote: from debian/rules install line (cd build $(MAKE) install prefix=$(CURDIR)/debian/gcc4arm/usr) Hi David, Dunno about 'prefix=' ... I've always used 'DESTDIR='? - -James - -- James Michael Greenhalgh [EMAIL PROTECTED] https://opendoorsoftware.com open minds providing open source solutions -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/XSRPgZMynI5GLOURAtWOAJwLcoZ6UWXE5UKchRQRkEeaRdj99wCgi/ZI z75tRs1yiOjMbQgZji9W3ac= =/iOM -END PGP SIGNATURE-
Re: autoconf and setting prefix
Actually after saying that, I had an epiphany. Why don't I just look at the gcc debian package source. Everyone can ignore that last message David -- David Meggy Engineering Technical Solutions Inc. Unit #1 7157 Honeyman St Delta BC Canada, V4G 1E2 www.techsol.ca eMail: [EMAIL PROTECTED] Tel: 604 946 TECH (8324) Fax: 604 946 6445
Re: IMPORTANT: your message to html-tidy
On Sun, Sep 07, 2003 at 11:09:57PM -0700, Steve Lamb wrote: On Mon, 8 Sep 2003 15:40:15 +1000 Matthew Palmer [EMAIL PROTECTED] wrote: On Mon, Sep 08, 2003 at 06:04:39AM +0100, Karsten M. Self wrote: I'm coming to the view that we're approaching the era where all mail is going to have to be subject to filtering, at the MTA level. Depends on how useful you want your e-mail box to be. g It has been my experience that filtering at the MTA level has increased the usefulness of my mailbox considerably. aol me too /aol stats from last week's mail.log (from my home mail server which handles mail for about half a dozen people): 1 Bad HELO 10 RBL proxies.relays.monkeys.com 11 Recipient Domain Not Found 22 RBL relays.ordb.org 25 strict 7-bit headers 31 Relay access denied 32 RBL taiwan.blackholes.us 34 Sobig.F Virus 42 body checks 49 RBL spamdomains.blackholes.easynet.nl 56 header checks 61 RBL dnsbl.sorbs.net 182 IP Address in HELO 193 RBL brazil.blackholes.us 218 RBL blackholes.easynet.nl 271 Local access rule: Helo command rejected 342 RBL hongkong.blackholes.us 492 RBL dynablock.easynet.nl 924 RBL sbl.spamhaus.org 1080 Local address forgery 1099 Recipient address rejected 1133 Sender Domain Not Found 1771 RBL list.dsbl.org 1825 Dynamic IP Trespass 1902 RBL cn-kr.blackholes.us 2471 Local access rule: Client host rejected 3005 Need FQDN address 3581 Local access rule: Sender address rejected 4267 User unknown 25130 TOTAL Spamassassin stats: 382 spam 4093 clean 4475 TOTAL Percentages: spam:non-spam (25512/29605) 86.17% accepted spam (382/4475) 8.54% rejected spam (25130/25512) 98.50% i'm reasonably happy with that. 98.5% of all spam was rejected outright. only 382 spams (1.5%) made it through my postfix access lists, RBLs, etc to be tagged by spamassassin. these stats also demonstrate just how bad the spam problem has become. 86% of all attempts to deliver mail to my server were spam, ~25500 spams and ~4100 legit messages. if i wasn't blocking spam at the MTA, then at least half of those spams would have ended up in MY personal mailbox (or, more likely, tagged by spamassassin and saved into my spam.incoming folder)about 13000 more spams than i currently receive. craig ps: i love postfix. it has the best anti-spam features of any MTA. pps: anyone who wants my simple spam-stats.pl script can get it from http://taz.net.au/postfix/scripts/
Re: bug report #208857 disappeard ?
Sorry for this. Let's say it was Monday. Christophe On Mon, Sep 08, 2003 at 06:26:27PM -0400, Christophe Barbe wrote: I don't understand why but I am unable to find a bug report I filled 3 days ago. Can someone explain me what happen? http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=208857 See below the ack from bugs.debian.org. I even submitted more info (a full trace that took me a long time to get). Christophe -Message suivi- From: Debian Bug Tracking System [EMAIL PROTECTED] To: christophe barbe [EMAIL PROTECTED] Subject: Bug#208857: Acknowledgement (gimp1.3: Segfault on Layer Mask in Layer Dialog on PowerPC) Date: 05 Sep 2003 12:33:06 -0500 Thank you for the problem report you have sent regarding Debian. This is an automatically generated reply, to let you know your message has been received. It is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Ari Pollak [EMAIL PROTECTED] If you wish to submit further information on your problem, please send it to [EMAIL PROTECTED] (and *not* to [EMAIL PROTECTED]). Please do not reply to the address at the top of this message, unless you wish to report a problem with the Bug-tracking system. Debian bug tracking system administrator (administrator, Debian Bugs database) -- Christophe Barbe [EMAIL PROTECTED] GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E -- Christophe Barbé [EMAIL PROTECTED] GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E Dogs believe they are human. Cats believe they are God.
