Re: Pb avec entrée de menu
Quoting Josselin Mouette ([EMAIL PROTECTED]): Par contre je me permets d'émettre des doutes quant à l'utilisation de /usr/bin/www-browser. Si c'est un navigateur texte, vu que tu ne requiers pas de terminal, ça ne marchera pas. Utiliser x-www-browser serait peut-être plus approprié, mais c'est une dépendance un peu lourde si le logiciel doit être installé sur un serveur. Bin si, ça marche. Si je ne mets pas l'argument, ça marche très bien.. :-) Le pb n'est pas le programme mais le fait que je ne puisse pas passer d'argument Or certaines entrées de menus utilisent bien des arguments Je sèche un peu... :-()
Re: lancement d'un daemon lors d'un upgrade
Quoting Raphael Hertzog ([EMAIL PROTECTED]): Et tu n'es pas le seul. C'est pour cela qu'on a inventé invoke-rc.d, cf sa page de manuel. Si je la comprends bien, invoke-rc.d regarde dans quel runlevel on est et n'exécute l'action start que si le lancement du processus est prévu dans ce runlevel là Par contre la page de manuel n'est pas bien claire sur le critère utilisé pour vérifier qu'un processus se lance ou pas. invoke-rc.d se contente-t-il de vérifier l'existence de /etc/rcX.d/Snntoto ou bien vérifie-t-il aussi que celui-ci est un lien sur /etc/init.d/toto ? Pour ma part, mes petits bricolages perso ont fait au fil du temps que pour les processus que je ne veux PAS démarrer, le laisse le /etc/rcX.d/Snntoto mais le fais pointer sur /etc/init.d/nop, un script vide à moi. Il faut que je me pense sur invoke-rc.dà mon avis mes noperies ne servent plus à rien.. :-)
Re: cles de non DD dans debian: Tout seul sur devel :)
Quoting Martin Quinson ([EMAIL PROTECTED]): Hello, J'ai fini par craquer entre deux seances de recheche bibliographique comme je les aime, j'ai fait un ptit mail sur devel pour demander pourquoi on pourrait pas avoir les cles des non DD sur les serveurs debian. Et je me sens un peu tout seul, la. Vous avez rien a dire et je suis le seul a avoir cette lubie ? Bin je pense qu'il va falloir que tu contres l'argument simple : why not use the public key servers ? Pour l'instant, je n'ai pas trouvé de contre-argument passionnant.. :-) Je sais bien que, pour toi, ce n'est qu'une étape dans une meilleure reconnaissance du statut de contributeur, mais il va falloir trouver autre chose que les clés GPG, j'en ai peur
Re: .*_hppa.changes ACCEPTED, sans mon intervention ?
On Thu, Aug 21, 2003 at 08:28:58AM +0200, Ludovic Rousseau wrote: Bonjour, Je viens de recevoir : From [EMAIL PROTECTED] Thu Aug 21 07:52:15 2003 Return-path: [EMAIL PROTECTED] [...] Received: (qmail 6583 invoked from network); 20 Aug 2003 22:53:02 - Received: from auric.debian.org (206.246.226.45) by mrelay4-1.free.fr with SMTP; 20 Aug 2003 22:53:02 - Received: from katie by auric.debian.org with local (Exim 3.35 1 (Debian)) id 19pbjM-0001hW-00; Wed, 20 Aug 2003 18:47:04 -0400 From: Debian Installer [EMAIL PROTECTED] To: Ludovic Rousseau [EMAIL PROTECTED] X-Katie: $Revision: 1.35 $ Precedence: bulk Subject: pilot-link_0.11.8-3_hppa.changes ACCEPTED Message-Id: [EMAIL PROTECTED] Sender: Archive Administrator [EMAIL PROTECTED] Date: Wed, 20 Aug 2003 18:47:04 -0400 Lines: 19 Accepted: libpda-pilot-perl_0.11.8-3_hppa.deb to pool/main/p/pilot-link/libpda-pilot-perl_0.11.8-3_hppa.deb libpisock++0_0.11.8-3_hppa.deb to pool/main/p/pilot-link/libpisock++0_0.11.8-3_hppa.deb libpisock-dev_0.11.8-3_hppa.deb to pool/main/p/pilot-link/libpisock-dev_0.11.8-3_hppa.deb libpisock8_0.11.8-3_hppa.deb to pool/main/p/pilot-link/libpisock8_0.11.8-3_hppa.deb libpisync0_0.11.8-3_hppa.deb to pool/main/p/pilot-link/libpisync0_0.11.8-3_hppa.deb pilot-link_0.11.8-3_hppa.deb to pool/main/p/pilot-link/pilot-link_0.11.8-3_hppa.deb python-pisock_0.11.8-3_hppa.deb to pool/main/p/pilot-link/python-pisock_0.11.8-3_hppa.deb Thank you for your contribution to Debian. C'est quoi ? Je ne fais des upload que pour i386. C'est un autobuilder qui cause ? C'est étrange puisque le paquet a été recompilé pour hppa le 14 août à 20:34 [1] et le mail date du 20 août. Tu remarquera que l'upload des autobuildersse fait de maniere manuelle, eventuellement un certain temps apres le build reel. C'est surement ce qui c'est passe ici. Je sais pas pourquoi tu a recu le mail cependant. Amicalement, Sven Luther
Re: Pb avec entrée de menu
Quoting Eric Heintzmann ([EMAIL PROTECTED]): Soyons precis : command=/bin/sh -c \/usr/bin/www-browser http://localhost:2317\; Ce qui est précisément ce que j'ai fait et : Argument invalide : « /usr/bin/www-browser http://localhost:2317 » Irritant, non ?
Re: .*_hppa.changes ACCEPTED, sans mon intervention ?
Le Thu, Aug 21, 2003 at 08:36:23AM +0200, Sven Luther écrivait: C'est quoi ? Je ne fais des upload que pour i386. Un upload d'une compilation pour hppa (il n'y a pas de sources mentionnées dans l'upload). C'est un autobuilder qui cause ? C'est étrange puisque le paquet a été recompilé pour hppa le 14 août à 20:34 [1] et le mail date du 20 août. La compilation est automatique mais la signature ne l'est pas puisqu'il faut la passphrase ... donc les recomils s'accumulent et à un moment, le porteur uploade tout en même temps. eventuellement un certain temps apres le build reel. C'est surement ce qui c'est passe ici. Je sais pas pourquoi tu a recu le mail cependant. Parce qu'il a sûrement mal utilisé dpkg-buildpackage ou debsign. L'option -e et -m sont similaires mais selon que l'on utilise l'une ou l'autre on change le champ Maintainer dans le .changes ou pas. Et donc le mail va à l'adresse de l'uploader ou du vrai mainteneur. A+ -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org
Re: Signature de cle en Alsace (was: Re: Bug#198987: Is something planned for this bug?)
On Tue, Aug 19, 2003 at 04:41:38PM +0200, Christian Perrier wrote:
Quoting Philipp Kern ([EMAIL PROTECTED]):
On Tue, 2003-08-19 at 15:33, Christian Perrier wrote:
{snip}
At least I'm not added as looking for keysigning.
If that helps.
I guess somebody listed from Haut Rhin would be the nearest to me.
Cyrille Chépélov [EMAIL PROTECTED] is listed in Haut-Rhin
I'm pretty sure there are other french developers in Strasbourg.
Let's ask french DD's.Les gars, quelqu'un pourrait signer la clé
de Philipp Kern dont j'ai sponsorisé le travail sur mydns
(précédemment géré par Igor Genibel puis repris par un mainteneur
plutôt fantôme maintenant) ?
Ok, c'est bon je viens de signer sa cle.
Amicalement,
Sven Luther
Re: Pb avec entrée de menu
Christian Perrier wrote: Quoting Eric Heintzmann ([EMAIL PROTECTED]): Soyons precis : command=/bin/sh -c \/usr/bin/www-browser http://localhost:2317\; Ce qui est précisément ce que j'ai fait et : Argument invalide : « /usr/bin/www-browser http://localhost:2317 » Irritant, non ? Etrange, chez moi ce genre de commande passe tres bien dans le menus sous WindowMaker. Avec quel menu as tu essayé ( GNOME,KDE, WindowMaker ... ?)
Re: Debian Birthday in Netcraft
Quoting Christian Surchi ([EMAIL PROTECTED]): From Netcraft newsletter and web site: Debian Linux distribution 10 years old today http://news.netcraft.com/archives/2003/08/16/debian_linux_distribution_10_years_old_today.html I'm not so sure about the value of their Debian geographical distribution, maybe... :-) Wow.According to this chart, about a third of hosts running Debian are in France.. :-) For sure, several major web hosting and Internet Access Providers run Debian hosts for their key servers herebut I think this graph is somewhat wrong anyway.. I like having a significant following in the former Iron Curtain countries. So the two major former Iron Curtain countries seem to be France and Germany.. :-)
Re: Debian Birthday in Netcraft
Christian Perrier dijo [Thu, Aug 21, 2003 at 01:36:02PM +0200]: Wow.According to this chart, about a third of hosts running Debian are in France.. :-) For sure, several major web hosting and Internet Access Providers run Debian hosts for their key servers herebut I think this graph is somewhat wrong anyway.. I like having a significant following in the former Iron Curtain countries. So the two major former Iron Curtain countries seem to be France and Germany.. :-) Isn't Netcraft CCCP-based? If so, I think it is right - The 'former Iron Curtain' countries (if I understand correctly, meaning 'the countries that were behind te Iron Curtain' include Germany(west), France, USA, UK and the Netherlands :-) -- 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
stack protection
Who is interested in stack protection? I think it would be good to have some experiments of stack protected packages for Debian. Probably the best way to do this would be to start with ssh-stack and sysklogd-stack being uploaded to experimental. I don't have time to do this, but I would like to help test it. Also is there any interest in uploading a kernel-image package with the grsec PaX support built in? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Simplicity Pattern Co. AutoReply
Hello, Thank you for contacting Simplicity Pattern Co. This Auto-Reply message is being sent to you as a convenience to let you know that we have received your email message. We will attempt to reply to your email as quickly as possible. EXTREMELY IMPORTANT WARNING: We DO NOT send out any spam mail or mass email mailings. If you have received spam email from SimpliCity please understand that this is not from us. We regret the inconvenience and are attempting to find a solution to this problem. Please note that our Consumer Relations Department Summer hours are Monday through Thursday 7:30 am to 4:45pm, and Friday 7:30 am to 12:00 pm. Our current waiting period for a reply is approximately 3-5 days. DO NOT REPLY to this message or send email to the address in the FROM field of this email. This email is generated by an email address that is NOT monitored. All correspondence must go to: [EMAIL PROTECTED] Thank you for being a Simplicity Pattern Co. customer! Consumer Relations Dept. Simplicity Pattern Co. http://www.simplicity.com
Re: Binaryless uploads
On Wed, 20 Aug 2003, Manoj Srivastava wrote: Since the source goes into Debian main, keeping the sources together means that we are distributing non-free material in Debian main, which not only violates the social contract, it may well be illegal (or have people who distribute debnian CD's indulge in illegal activity), depending on how non free the non free bits are. This needs be corrected ASAP, and a bug needs be filed on ftp.debian.org to have the old sources, containing the non-fee bits, be removed from main. Just to clarify, the current webmin.orig.tar.gz has the source to the non-free modules but binary packages are not built from them. -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/
Re: non-DD contributors and the debian keyring
On Wed, Aug 20, 2003 at 11:29:52PM +0200, Martin Quinson wrote: But the point is that without the key, anyone can forge mails which seem to come from me, and thus abuse the trust my work gained me in the mind of some DDs. I see this point as necessary even if not sufficient. Ok, a valid key gives trust that your work is really made by you. But what this key needs is signatures from trusted people (e.g. from other Debian developers) and for that it doesn't have to be in Debian's keyring at all. Just send the people you work with your public key with its signatures - you don't even have to go via any keyserver at all. Cheers, Peter -- Peter van Rossum, [EMAIL PROTECTED] | Universal law of linearity: for all Dept. of Mathematics, New Mexico | f : R - R and for all x, y in R: State University, Las Cruces, NM, USA. |f(x + y) = f(x) + f(y)
Re: python 2.2 - python 2.3 transition
On Thu, Aug 21, 2003 at 12:34:12PM +1000, Donovan Baarda wrote: On Wed, 2003-08-20 at 15:49, Anthony Towns wrote: On Tue, Aug 19, 2003 at 11:44:22PM -0400, Derrick 'dman' Hudson wrote: The negative effect for the users is that you can't upgrade python while wxgtk-python is installed so you can't try out the latest-and-greatest python in the meantime. This is the issue at hand. Sure you can: $ sudo apt-get install python2.3 The dependency stuff merely notes that upgrading python without also upgrading wxgtk-python may break stuff. actually, if the dependencies are right, you cannot upgrade to python (2.3) without also upgrading to wxgtk-python (2.3) or de-installing wxgtk-python (2.2). Sure you can. dpkg --force-depends -i python_*.deb will do it for you. If you want something bad enough, and don't mind breaking things, anything's possible. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgphsIYHZSBPS.pgp Description: PGP signature
Your message to Consume-thenet awaits moderator approval
Your mail to 'Consume-thenet' with the subject Re: Your application Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.consume.net/mailman/confirm/consume-thenet/1326fd42b88c751ef5720aed4caa3701f0758946
Your message to Consume-thenet awaits moderator approval
Your mail to 'Consume-thenet' with the subject Re: That movie Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.consume.net/mailman/confirm/consume-thenet/335f39b2d10f305cff9f45f36599cdb9c1a02240
ALERT: You may have sent a Virus
Dear debian-devel@lists.debian.org, JARING E-Mail Virus Scanner has detected virus(es) in your e-mail attachment(s) Original Date: Aug 21 12:57:10 Original Sender: debian-devel@lists.debian.org Original To: [EMAIL PROTECTED] Original Subject: Undeliverable: ALERT: You may have sent a Virus Virus info:- Attachname: h7L4v5mM00470 was infected with [EMAIL PROTECTED], and deleted Thank you, JARING E-Mail Virus Scanner ( http://www.jaring.my )
Re: stack protection
On Thu, Aug 21, 2003 at 12:57:06PM +1000, Russell Coker wrote: Who is interested in stack protection? I think it would be good to have some experiments of stack protected packages for Debian. Probably the best way to do this would be to start with ssh-stack and sysklogd-stack being uploaded to experimental. I don't have time to do this, but I would like to help test it. What stack protection are you talking about here? Any references? -- Brian May [EMAIL PROTECTED]
Re: ftp.gnu.org cracked
Scott James Remnant: If you read the script, I did, but I couldn't figure out what was the input. The only MD5 sums that GNU have provided are for 2.4, 2.4.1 and 2.4.2 Right. I sent them an update mail earlier this week, but I guess they're quite busy at the moment... -- \\// Peter - http://www.softwolves.pp.se/ I do not read or respond to mail with HTML attachments.
Re: Bits from the RM
On Wed, 20 Aug 2003, Colin Watson wrote: On Wed, Aug 20, 2003 at 11:18:24AM -0600, Bruce Sass wrote: On Wed, 20 Aug 2003, cobaco wrote: I'd agree if there had been a rewrite of kdelibs or something, but kde 3.1 - 3.2 is evolutionary without big changes to what was already there. It does not take a big change to break software... e.g., openssh changed a message and the sftp kioslave broke http://bugs.kde.org/show_bug.cgi?id=51359 Not that I disagree with you, but frankly, the sftp kioslave was already broken. It should never have been written to depend on 'ssh -v' output. Ya, and it didn't manifest until a minor release of ssh or a patch release of KDE came along. ;-) - Bruce
Re: stack protection
On Thu, 21 Aug 2003 14:56, Brian May wrote: On Thu, Aug 21, 2003 at 12:57:06PM +1000, Russell Coker wrote: Who is interested in stack protection? I think it would be good to have some experiments of stack protected packages for Debian. Probably the best way to do this would be to start with ssh-stack and sysklogd-stack being uploaded to experimental. I don't have time to do this, but I would like to help test it. What stack protection are you talking about here? Any references? Propolice sounds good: http://www.trl.ibm.com/projects/security/ssp/ From the GCC changelog: * Add the stack protector patch, but don't apply it by default. Edit debian/rules.patch to apply it (closes: #171699, #189494). It sounds like we need a propolice enabled GCC. There are other stack protection mechanisms too, but propolice seems the most popular. Some investigation would need to be done into the relative merits of the various options (propolice has much better support apparently which will be a major factor). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Proposal: make kernel install easier
On Wed, 20 Aug 2003 19:00:54 -0600, Jamin W Collins [EMAIL PROTECTED] said: On Wed, 2003-08-20 at 14:46, Manoj Srivastava wrote: On 20 Aug 2003 10:51:54 -0400, Adam C Powell IV said: Greetings, Installing a new kernel package can be a bit of a pain, especially for newbies, what with hand-editing lilo.conf or config Why on earth are you hand editing the lilo.conf file for every kernel image? Well, if they move from an installation kernel to a kernel-image package, they have to add an entry for an initrd file. After that, if they upgrade to another kernel-image package and want to be able to use both the new and the old they need to edit the old entry for an initrd too. If you are going to bounce back and forth between initrd and non initrd kernels, you should modify the sample postinst-hook script and maintain two sets of symlinks -- one for initrd ekrnels, and one for plain ones. Bingo. No need to edit the lilo.conf every time. manoj -- pediddel: A car with only one working headlight. Sniglets, Rich Hall Friends 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: Binaryless uploads
On Wed, 20 Aug 2003 23:40:18 -0400 (EDT), Jaldhar H Vyas [EMAIL PROTECTED] said: On Wed, 20 Aug 2003, Manoj Srivastava wrote: Since the source goes into Debian main, keeping the sources together means that we are distributing non-free material in Debian main, which not only violates the social contract, it may well be illegal (or have people who distribute debnian CD's indulge in illegal activity), depending on how non free the non free bits are. This needs be corrected ASAP, and a bug needs be filed on ftp.debian.org to have the old sources, containing the non-fee bits, be removed from main. Just to clarify, the current webmin.orig.tar.gz has the source to the non-free modules but binary packages are not built from them. I got that. I don't think I care. It is not relevant. If I have: deb-src http://ftp1.us.debian.org/debian sid main contrib in my souces.list, and I do apt-get webmin-blah; and non free junk lands on my machine, the social contract has been violated. You are aware that source code is part of debian, right? And sources in main are part of debian? Ad main should not contain non-free stuff, as per the social contract? manoj -- There may be said to be two classes of people in the world; those who constantly divide the people of the world into two classes and those who do not. Robert Benchley 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: Does anyone use barrendero, or know of an equivalent?
Quoting Steve Langasek ([EMAIL PROTECTED]): Hello, The package barrendero is a candidate for removal from testing. It has I had a quick look at the BTS and it seems that the two RC bugs may be easily fixed (one is a missing Build-Depends on debhelper, the other an error in debian/rules for which a patch has been provided) Even the minor bug may be easily fixed. So, we could maybe consider a NMU (consider this volunteering for doing the work) ? I have absolutely no interest in this software but would just feel too bad that it disappears whilc fixing it is easy. Well, of course, if it is completely useless, I could revise my judgement.. :-)
Re: Bits from the RM
On Wed, 20 Aug 2003 15:16:05 +0200, Josef Spillner [EMAIL PROTECTED] wrote: - the KDE release plan might be delayed (as well...) The sarge release plan _will_ be delayed. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
, , (8652) 995 850/1/2/3/4
Re: non-DD contributors and the debian keyring
Martin Quinson [EMAIL PROTECTED] wrote: [...] Of course, I could (and have) uploaded my key on public servers, meaning that other Debian member could check than a given mail with my address desserve the trust they habitually give me. But those guys would have to configure their email specifically on people like me[*]. [...] Most of us won't need to change the configuration of their MUA/gpg, having a MUA that tries to verify sigs automatically and a gnupg that automatically fetches GPG-keys from the nearest keyserver is a pretty standard, vanilla setup. cu andreas
Your message to suse-s390-announce awaits moderator approval
Your mail to 'suse-s390-announce' with the subject Re: Approved Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://mailman.suse.de/mailman/confirm/suse-s390-announce/df2513aface653cee5c29cc90c28618fe2dedd95
Re: Bits from the RM
On Thu, Aug 21, 2003 at 08:56:31AM +0200, Marc Haber wrote: On Wed, 20 Aug 2003 15:16:05 +0200, Josef Spillner [EMAIL PROTECTED] wrote: - the KDE release plan might be delayed (as well...) The sarge release plan _will_ be delayed. Quite confident, are we? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?''
Re: stack protection
On Thu, 21 Aug 2003, Russell Coker wrote:
Who is interested in stack protection?
I think it would be good to have some experiments of stack protected packages
for Debian.
Also is there any interest in uploading a kernel-image package with the grsec
PaX support built in?
grsec is IMHO a better idea, as it offers a global protection against
various exploit types (execution of code in stack, for example) and
related threats (restriction in /proc is really useful too, ulimit
enforcement, symlink/fifo/chroot restrictions .. )
Note that some options are sometimes incompatible with some packages:
restrictions on kmem ('Deny writing to /dev/kmem, /dev/mem, and
/dev/port') prevent lm_sensors from working properly with my server. But
with reasonnable settings grsecurity is working like a charm.
Ah, when dealing about security, it might be also a good idea to allow
more easily Debian to run with / in read-only. There was a thread in
-devel some time ago (see 'Update re: read-only root filesystem' thread
and http://panopticon.csustan.edu/thood/readonly-root.html)
A read-only / with grsecurity easily offers a good protection (even if not
absolute) [other details could be checked, like non-executable /var, and
so on.. but it depends on the system partitionning]
Major issues for a ro-/ are maybe:
- using devfs for /dev (kernel 2.4 and package devfsd installed)
- using tmpfs for /tmp (kernel 2.4?)
- transforming several /etc files as symlinks and moving them to some
other place (/var/etc ?)
I was wondering if a script-only-package could do that, with a 'Depends:
kernel-xx(2.4), devfsd' and proper install scripts? Might be difficult to
do, but maybe not impossible?
apt-get install read-only-root :)
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Wed, Aug 20, 2003 at 10:04:40AM -0400, Jaldhar H. Vyas wrote: Ok. Lets leave aside for a moment the .debs which would go into contrib or non-free so would have to be built seperately. What happens if webmin-squid has an RC bug? As Goswin said, all the webmin-* packages will be held back from testing. What happens if webmin-squid is ok but squid itself is not in testing? (or is removed from testing. This could happen if it has an RC bug at freeze time,) Again all the webmin packages would be affected. What if webmin-squid has one or two upstream bugfix releases in between major webmin versions? Every other webmin module would also have to be rebuilt too even though nothing changed. What you are suggesting was the way things were done before 0.98 and it caused all sorts of annoyance for me and the users. I'll make any changes necessary to be policy-compliant but I'm firm about the multiple-source package thing. Ok, so when you said split each module into a seperate binary package. What you really meant was: split each module into a seperate source package. I gather this is because otherwise webmin would not get into testing unless each of its binary packages gets into testing, right? Is this still an issue? Having lots of source files makes it less convenient to rebuild for woody. I am not going to argue this, now I understand your reason. Is there any reason why webmin and webmin-core need to be seperate source packages? Regardless, it should still be possible to have a working debian/rules for each source package, this just represents a limitation in your current build script. Ideally the build script needs to update debian/rules for each package, or create a script that is called by debian/rules, or ... Lots of options are available here. As for the problem with the source file containing non-free code, if you have prestine source code, this is something that really needs to get fixed upstream :-(, eg. split into two files. -- Brian May [EMAIL PROTECTED]
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Thu, Aug 21, 2003 at 05:20:42PM +1000, Brian May wrote: As for the problem with the source file containing non-free code, if you have prestine source code, this is something that really needs to get fixed upstream :-(, eg. split into two files. Looking at the other messages in the thread, webmin doesn't have prestine upstream source, so the above isn't relevant. I wonder now why a special build script is required at all, why not just treat each module as a totally seperate debian source package? -- Brian May [EMAIL PROTECTED]
Re: Debian Weekly News - August 19th, 2003
Quoting Peter S Galbraith [EMAIL PROTECTED]: Jérôme Marant [EMAIL PROTECTED] wrote: Quoting Scott James Remnant [EMAIL PROTECTED]: No he wouldn't. FDL is about free documentation. :-) Except it isn't :-) According to you :-) According to debian-legal consensus. Is there any? John's message proves that there isn't any yet, IMO. -- Jérôme Marant [EMAIL PROTECTED]
Re: stack protection
On Thu, 21 Aug 2003 17:39, Xavier Roche wrote: Major issues for a ro-/ are maybe: - using devfs for /dev (kernel 2.4 and package devfsd installed) Devfs is getting less support now, it might not be the best time to start depending on it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Norton AntiVirus failed to scan an attachment in a message you sent.
Recipient of the attachment: SEXCHANGE, RADIANT\RII, StellaHsieh()/ Subject of the message: Re: That movie No action was taken on the attachment. Attachment document_9446.pif was Logged Only for the following reasons: Scan Engine Failure (0x80004005)
Norton AntiVirus failed to scan an attachment in a message you sent.
Recipient of the attachment: SEXCHANGE, First Storage Group\Mailbox Store (SEXCHANGE), mailbackup/ Subject of the message: Re: That movie No action was taken on the attachment. Attachment document_9446.pif was Logged Only for the following reasons: Scan Engine Failure (0x80004005)
Re: Transition: new PAM config file handling in unstable
Hi Steve, thanks for the work. A couple of questions for clarity's sake (as sysadmin, not packager) On Wed, Aug 20, 2003 at 10:37:59PM -0500, Steve Langasek wrote: - Per-package /etc/pam.d/ configuration files should not include explicit 'password' blocks. Instead, services should use the builtin libpam fallback to /etc/pam.d/other for their password changing policy. Does this mean that other is read even if service exists? From the docs: There is a special service-name, reserved for defining a default authentication mechanism. It has the name `OTHER' and may be specified in either lower or upper case characters. Note, when there is a module specified for a named service, the `OTHER' entries are ignored. It doesn't mention password specifically, so I don't quite understand why password falls back to other while the other module-types need an extra include file (or the other way around: why doesn't password have an include file, too?) - Configuration files should be modified to no longer reference pam_unix directly. For auth, account, and session blocks, such references should be replaced with these lines: @include common-auth @include common-account @include common-session These @include lines are handled as literal includes by libpam, so packages that currently use other modules besides pam_unix (or offer commented-out examples) need only leave those surrounding module lines intact. You mean something like login's use of e.g. pam_motd? Should pam_time be in common-account or in login's own file? Rationale? -- Marcelo
Re: Bits from the RM
At Thu, 21 Aug 2003 00:17:27 +1000, Anthony Towns wrote: [1 text/plain; us-ascii (quoted-printable)] On Wed, Aug 20, 2003 at 08:49:33AM -0400, Matt Zimmerman wrote: On Tue, Aug 19, 2003 at 04:49:25PM +1000, Anthony Towns wrote: Also make sure to include some leg room if you depend on packages that have a tendency to be buggy (glibc, for example). The new glibc has already stalled the progress into testing of a large number of packages, and the number of RC bugs still seems to be going up. How are we going to manage to produce a release in 6 months the face of this obstacle? The last time there was this sort of breakage, it took many months just to get glibc itself it sorted out. Yup. The difference is that this time we have a Glibc maintenance team that's able to work together effectively, has some experience with the package, and has a better understanding how important it is to get it fixed quickly. AFAIK, the unresolved difficult bugs are: (1) hppa build (2) dpkg (setjmp/longjmp) on sparc (3) NIS (will be fixed?) (4) misterious apache on ia64 bug. Note that (3) becomes ok to revert patches, (4) may be non-glibc bug. Well, they are still something hard work. :-) My concern is (1) hppa build. If we can't get hppa glibc, we may need to drop it finally... Regards, -- gotom
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
Jaldhar H. Vyas [EMAIL PROTECTED] writes: On Wed, 20 Aug 2003, Goswin von Brederlow wrote: Jaldhar H. Vyas [EMAIL PROTECTED] writes: On Wed, 20 Aug 2003, Goswin von Brederlow wrote: The only problem with that is the current failure to comply to policy, i.e. build from source as they should. The question remains is simply removing all the extra source from webmin-n.orig.tar.gz except that which is necessary to build the webmin binary package (i.e not any of the modules which will have their own source and binary packages) an aceptable solution to the problem or not? From what I read in this thread webmin-n.orig.tar.gz also contains some non-free sources, right? It has source for all the modules including the non-free ones. However the binary packages for those modules are built from seperate source packages not this one. Then you have no choice but split it up to get the rest into main. And when you don't have a pristine upstream orig.tar.gz you can split it up as far as you like or need to. The only reason for having the webmin.orig.tar.gz as it is was to provide something approximating the upstream tarball. It sounds like I don't need to bother about that. The only way you could is to have the source in non-free and you certainly don't want that. MfG Goswin
Re: Debian Weekly News - August 19th, 2003
Jrme Marant [EMAIL PROTECTED] writes:
Quoting Peter S Galbraith [EMAIL PROTECTED]:
Jrme Marant [EMAIL PROTECTED] wrote:
Quoting Scott James Remnant [EMAIL PROTECTED]:
No he wouldn't. FDL is about free documentation. :-)
Except it isn't :-)
According to you :-)
According to debian-legal consensus.
Is there any? John's message proves that there isn't any yet, IMO.
consensus
n : agreement of the majority in sentiment or belief
[syn: {general agreement}]
unanimity
n : everyone being of one mind
A world of difference.
--
ilmari
Re: Proposal: make kernel install easier
Adam C Powell IV [EMAIL PROTECTED] writes: On Wed, 2003-08-20 at 15:02, Goswin von Brederlow wrote: Adam C Powell IV [EMAIL PROTECTED] writes: Greetings, Installing a new kernel package can be a bit of a pain, especially for newbies, what with hand-editing lilo.conf or config files for other bootloaders, from grub to yaboot/quik, aboot, palo, you name it. Yes, the kernel-image postinst runs lilo, but lilo.conf is invariably out of date, so this is relatively useless except for upgrades. So why not (optionally) automate the process a bit? Use a directory e.g. /usr/lib/bootloaders/ to put scripts for managing the .conf files and running the bootloaders. I believe lilo and grub already have that. From /boot/grub/menu.lst ### BEGIN AUTOMAGIC KERNELS LIST ## lines between the AUTOMAGIC KERNELS LIST markers will be modified ## by the debian update-grub script except for the default optons below There is also a mechanism in dpkg to install hooks now which is hopefully already used to run update-grub. Cool, did not know. I guess a hooks mechanism would be required for unmodified kernel-image packages... My proposed system would add user control of menu entry names/labels, and finer-grained control of boot options (without editing the .conf files), but these don't seem worth the overhead of such a system. Is this documented somewhere, or should I just look at the latest lilo and grub packages to see how to adapt this to other bootloaders? It would be nice if this were somewhat uniform (at least to the user) across loaders and architectures. Never look at the source, just seen the comments in the config. MfG Goswin
Re: non-DD contributors and the debian keyring
Quoting Martin Quinson ([EMAIL PROTECTED]): Of course, the signature is not sufficient to get the needed trust. But I'm coordinator of the french translation team since a few years, so my skills should be trustable, I guess. But the point is that without the key, anyone can forge mails which seem to come from me, and thus abuse the trust my work gained me in the mind of some DDs. I see this point as necessary even if not sufficient. Sure, this certainly is a good point. This leads this discussion elsewhere : the main point is again not the problem of GPG keysbut probably the status of contributors who are not DD's...(translators, documentation writers, web maintainers) A recent thread in debian-devel-french occurred when Patrice K.* 's application was dropped because he does not maintain any package As far as I can remember, this topic is periodically raised here or therewe're maybe always beating the same dead horse.but it seems that the horse is not suite dead.. :-)
Re: Does anyone use barrendero, or know of an equivalent?
On Wed, Aug 20, 2003, Steve Langasek wrote: But descriptions can be deceiving. Does anyone use this package who could comment on its reliability? Does the lack of other bugs indicate that the software is mature and stable, or unused? I am trying barrendero but don't trust it enough yet for production use. I had worked on an NMU that fixes all bugs and makes the package a bit more polished, I just reviewed it and uploaded it here: http://zoy.org/~sam/debian/barrendero_1.0-1.1.diff.gz I haven't contacted the maintainer yet because I was working on other bugs, but if he is MIA as you seem to be suggesting, I'll probably upload that NMU to DELAYED quite soon. Does anyone know of another package that provides similar functionality? mail-expire is very close to it. Cheers, -- Sam.
Re: what about ip's
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 20 August 2003 16:06, David Smith wrote: X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-Type: text/html; [ dsmith_sig1.GIF] people here tend to regard stuff like your mail as spam already ... Uli -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/RIbvwVdGSYi8Mq8RAkhUAJ0RhX2bE53lUc0x0kmYeA/NbJXmoACffuJw uiZRroGpURImW107NgWFAuE= =z8SS -END PGP SIGNATURE-
Automated reply
This is an automated response to your e-mail. Your e-mail has been received by the McCall Pattern Company: Butterick, McCall's and Vogue Patterns. E-mail is answered in the order it is received. Due to the high volume of e-mail we receive, there may be a delay in our response. Please be patient and e-mail only once as multiple messages will slow down the answering process. For the fastest service, please read the following information, and call* the number that pertains to your specific inquiry: *Monday through Friday 8:45 AM to 4:45 PM Eastern Time To purchase current or discontinued patterns, or check the status of patterns ordered through the magazine: (800) 255-2762 ext. 488 To check status of a Web site order: (800)255-2762 ext. 397 To Purchase current catalogs: (800) 255-2762 ext. 473 For Magazine subscriptions or change of address: (800) 255-2762 ext. 459 For Education Kits and Orders (Teachers Only): (800) 622-2557 To Purchase the Hookless Attachment System*: (800) 255-2762 ext. 397 *Qwik-Tach(tm) Tapes and Flex-On(tm) Loops To speak to a sewing expert concerning a construction problem with one of our pattern: (800) 782-0323. Please have the following information ready when you call: ?The pattern number and the brand name (example: McCall's 1234). ?The view you are making. ?The size you are making. ?If your questions concerns fit, please have bust, waist and hip measurements available.
Re: non-DD contributors and the debian keyring
Andreas Metzler [EMAIL PROTECTED] writes: Martin Quinson [EMAIL PROTECTED] wrote: [...] Of course, I could (and have) uploaded my key on public servers, meaning that other Debian member could check than a given mail with my address desserve the trust they habitually give me. But those guys would have to configure their email specifically on people like me[*]. [...] Most of us won't need to change the configuration of their MUA/gpg, having a MUA that tries to verify sigs automatically and a gnupg that automatically fetches GPG-keys from the nearest keyserver is a pretty standard, vanilla setup. cu andreas And even if the fetching fails one would just ask the sender for his key once and add that to the keyring (if its properly signed by some trustworthy soul). MfG Goswin
Re: stack protection
Russell Coker wrote: It sounds like we need a propolice enabled GCC. I have talked to Matthias Klose, one of the GCC maintainers, about this. He included the patch so he could built ProPolice-enables packages of gcc and g++ but he's currently too busy with other things. He might accept a patch that builds these packages but we really need to hurry if we want these compilers released with sarge. Maybe some of the Adamantix developers will help? However, ProPolice has not been ported to all architectures yet, see http://www.research.ibm.com/trl/projects/security/ssp/statuschart.html for details. There are other stack protection mechanisms too, but propolice seems the most popular. Some investigation would need to be done into the relative merits of the various options (propolice has much better support apparently which will be a major factor). I think ProPolice is the best choice, first because Adamantix has tested it for quite some time. Second, ProPolice offers the best protection according to http://www.research.ibm.com/trl/projects/security/ssp/node4.html#SECTION00045000 and finally it even offers the best performance (http://www.research.ibm.com/trl/projects/security/ssp/node5.html). IMHO innovations in Debian have been rare in the past 2 years (compared to other major distributions), so maybe this is a chance for Debian... Stefan
Re: FTBFS: architecture all packages
Adam Heath [EMAIL PROTECTED] writes: On Wed, 20 Aug 2003, Matthias Urlichs wrote: Why not? Just block binary uploads completely, and let everything get built by the buildds. I certainly plan to do that with my own uploads. (I've already set up my own buildds). I'd go one step farther and schedule a low-priority rebuild of everything that build-depends on a package which gets updated. How about this: * Maintainer does normal build, doing -all and -arch debs. Maintainer uploads. * dak verifies upload as normal. * dak adds new source to unstable, but not the debs. * buildds then proceed to build new source. one buildd is choosen to build the -all debs. Nearly perfect. The archive scripts might have problems with sources without debs. I also suggest building the -all debs by multiple buildds (all but one with low priority if you fear overworked buildds) and throw away maybe-successfull builds automatically (by all but the primary buildd). Doogie already said he wants to implement a smart comparator for deb in dpkg 2.0 which would then be used to compare that different builds of the binary-all even give the same result. I also like the idea of rebuilding packages with newer versions of their build-depends (or tool-chain) when a buildd is idle. That too would require a more automatic handling of maybe-successfull builds that won't be uploaded. MfG Goswin
Re: Bits from the RM
On Thu, 21 Aug 2003 17:22:38 +1000, Anthony Towns aj@azure.humbug.org.au wrote: On Thu, Aug 21, 2003 at 08:56:31AM +0200, Marc Haber wrote: On Wed, 20 Aug 2003 15:16:05 +0200, Josef Spillner [EMAIL PROTECTED] wrote: - the KDE release plan might be delayed (as well...) The sarge release plan _will_ be delayed. Quite confident, are we? I am only realistic. When in history did a non-trivial software product meet its release schedule? I am surely hoping for the best, but I seriously do expect sarge to be released in early 2004. Which is a pretty good track record if we actually reach that. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: stack protection
Xavier Roche [EMAIL PROTECTED] writes: On Thu, 21 Aug 2003, Russell Coker wrote: Major issues for a ro-/ are maybe: - using devfs for /dev (kernel 2.4 and package devfsd installed) Alternatively you can copy /dev to a ramdisk. And please don't use devfsd. That somewhat cancles out half of the merits of devfs. You also might want to look at udev since that looks like its replaing devfs in the future. - using tmpfs for /tmp (kernel 2.4?) Or your own /tmp partition as any good admin would have made. :) - transforming several /etc files as symlinks and moving them to some other place (/var/etc ?) Thats pending some year old patches on util-linux (for mount, /etc/mtab) unless you want to link to /proc/mounts. Anything else is already patched for this or has no reason to stay in /etc. I was wondering if a script-only-package could do that, with a 'Depends: kernel-xx(2.4), devfsd' and proper install scripts? Might be difficult to do, but maybe not impossible? apt-get install read-only-root :) Didn't someone package something up that will divert and link some files already? MfG Goswin
Re: Debian Weekly News - August 19th, 2003
Quoting Jamin W. Collins [EMAIL PROTECTED]: This has been covered to death already. There are a sufficient number of respondents that see it as non-free. The RM's recent post indicates that possibly the FSF has even come around to the idea that their license is less than Free. Can we please move along now? Just don't read the thread. -- Jérôme Marant
Re: python 2.2 - python 2.3 transition
On Thu, Aug 21, 2003 at 01:37:10PM +1000, Anthony Towns wrote: On Thu, Aug 21, 2003 at 12:34:12PM +1000, Donovan Baarda wrote: On Wed, 2003-08-20 at 15:49, Anthony Towns wrote: On Tue, Aug 19, 2003 at 11:44:22PM -0400, Derrick 'dman' Hudson wrote: The negative effect for the users is that you can't upgrade python while wxgtk-python is installed so you can't try out the latest-and-greatest python in the meantime. This is the issue at hand. Sure you can: $ sudo apt-get install python2.3 The dependency stuff merely notes that upgrading python without also upgrading wxgtk-python may break stuff. actually, if the dependencies are right, you cannot upgrade to python (2.3) without also upgrading to wxgtk-python (2.3) or de-installing wxgtk-python (2.2). Sure you can. dpkg --force-depends -i python_*.deb will do it for you. If you want something bad enough, and don't mind breaking things, anything's possible. Please, don't turn Debian into Red Hat ;-) Regards: David Weinehall -- /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Bits from the RM
* GOTO Masanori wrote: AFAIK, the unresolved difficult bugs are: (1) hppa build (2) dpkg (setjmp/longjmp) on sparc (3) NIS (will be fixed?) (4) misterious apache on ia64 bug. Note that (3) becomes ok to revert patches, (4) may be non-glibc bug. Well, they are still something hard work. :-) (5) Breakage of all d-i boot images created in an environment with new libc. Seems to be related to libc6-pic and mklibs, bug will be filed against libc6-pic. Sebastian -- PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key Fingerprint: A46A 753F AEDC 2C01 BE6E F6DB 97E0 3309 9FD6 E3E6
Re: stack protection
Russell Coker [EMAIL PROTECTED] writes: Devfs is getting less support now, it might not be the best time to start depending on it. Indeed, it's looking likely that GregKH's `udev' will replace devfs sometime in the future. [It was amusing to see Christoph Hellwig's recent patch on the lkml changing devfs from `EXPERIMENTAL' directly to `OBSOLETE' (and he has a fairly good record of getting devfs patches accepted by Linus). :-/ ] -Miles -- Is it true that nothing can be known? If so how do we know this? -Woody Allen
Re: Debian Weekly News - August 19th, 2003
Quoting Dagfinn Ilmari Mannsåker [EMAIL PROTECTED]:
consensus
n : agreement of the majority in sentiment or belief
[syn: {general agreement}]
unanimity
n : everyone being of one mind
A world of difference.
No, no, no! You don't get it. There may be a majority among the
debian-legal zealots, but we need a consensus among Debian as a
whole (which means voting of course).
We musn't let the bigots decide for us! ;-)
--
Jérôme Marant
Bug#206537: ITP: horde-sam -- Spamassassin module for Horde
Package: wnpp Version: N/A; reported 2003-08-21 Severity: wishlist * Package name: horde-sam Version : 0.0.1 Upstream Author : The Horde Team [EMAIL PROTECTED] * URL : http://cvs.horde.org/cvs.php/sam/ * License : GPL Description : Spamassassin module for Horde -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux rollcage 2.4.22-pre6 #3 Sat Jul 26 21:53:42 CEST 2003 i686 Locale: LANG=POSIX, LC_CTYPE=de_DE
Bug#206536: ITP: phpdocumentor -- php auto documentor
Package: wnpp Version: unavailable; reported 2003-08-21 Severity: wishlist * Package name: phpdocumentor Version : 1.2.2 Upstream Author : Joshua Eichorn [EMAIL PROTECTED] * URL : http://www.phpdocumentor.org/ * License : PHP Description : php auto documentor phpDocumentor is a JavaDoc-like automatic documentation generator for PHP written in PHP. It is a very versatile tool for documenting PHP. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux azuaga 2.4.21-ck3 #6 vie ago 1 18:24:01 CEST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to [EMAIL PROTECTED])
Debian Birthday in Netcraft
From Netcraft newsletter and web site: Debian Linux distribution 10 years old today http://news.netcraft.com/archives/2003/08/16/debian_linux_distribution_10_years_old_today.html I'm not so sure about the value of their Debian geographical distribution, maybe... :-) bye Christian -- Christian Surchi [EMAIL PROTECTED] signature.asc Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Bug#206536: correcting URL
Package: wnpp Version: unavailable; reported 2003-08-21 Followup-For: Bug #206536 As Thomas said, the right URL is http://www.phpdoc.org, not http://www.phpdocumentor.org. Thank you very much, Thomas. Regards. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux azuaga 2.4.21-ck3 #6 vie ago 1 18:24:01 CEST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to [EMAIL PROTECTED])
Re: Debian Birthday in Netcraft
Quoting Christian Surchi ([EMAIL PROTECTED]): From Netcraft newsletter and web site: Debian Linux distribution 10 years old today http://news.netcraft.com/archives/2003/08/16/debian_linux_distribution_10_years_old_today.html I'm not so sure about the value of their Debian geographical distribution, maybe... :-) Wow.According to this chart, about a third of hosts running Debian are in France.. :-) For sure, several major web hosting and Internet Access Providers run Debian hosts for their key servers herebut I think this graph is somewhat wrong anyway.. I like having a significant following in the former Iron Curtain countries. So the two major former Iron Curtain countries seem to be France and Germany.. :-)
Re: Debian Birthday in Netcraft
On Thu, Aug 21, 2003 at 11:59:30AM +0200, Christian Surchi wrote: From Netcraft newsletter and web site: Debian Linux distribution 10 years old today http://news.netcraft.com/archives/2003/08/16/debian_linux_distribution_10_years_old_today.html I'm not so sure about the value of their Debian geographical distribution, maybe... :-) I'm not even sure how they derive that information, Debian's Apache might provide it in the banner information (Since when? BTW, has this always been the case?) but many other web servers in Debian won't. This might not be completely relevant however (since the web server market is dominated by two products at the moment). But, of course, you (can?) always lie with statistics [1] Regards Javi [1] There are three kinds of lies: lies, damned lies and statistics. Attributed to: Benjamin Disraeli (1804-1881) For laughs, read http://www4.gvsu.edu/robbinsd/courses/pa611/readings/felbinger.PDF or http://www.statistics.com/content/lying/teresi.html (fresh from Google but reordered since I find the first one best) pgp4g8gSTJAeh.pgp Description: PGP signature
Re: stack protection
Hi On Thu, Aug 21, 2003 at 02:56:34PM +1000, Brian May wrote: On Thu, Aug 21, 2003 at 12:57:06PM +1000, Russell Coker wrote: Who is interested in stack protection? x86 only? Pro police is the most platform independent iirc. I think it would be good to have some experiments of stack protected packages for Debian. Probably the best way to do this would be to start with ssh-stack and sysklogd-stack being uploaded to experimental. I don't have time to do this, but I would like to help test it. What stack protection are you talking about here? If you need further reference the easiest way would be to check the bugtraq flamew^Wdiscussion archives right now, as there is quite a big thread with people who have programmed/used ProPolice, Stackguard, PaX and W^X (the stuff OpenBSD uses at the moment). If you filter out the 90% rant and the my-big-dick-software-is-best-at-protecting-your-stack noise, you will find some useful things about stack protection, and the features of each solution... Any references? damn. why didn't I write the above here... MfG/Regards, Alexander -- Alexander Reelsen http://tretmine.org [EMAIL PROTECTED]
Re: stack protection
On Thu, 21 Aug 2003 19:13, Stefan Gybas wrote: However, ProPolice has not been ported to all architectures yet, see http://www.research.ibm.com/trl/projects/security/ssp/statuschart.html for details. Not being ported to all architectures is not a problem IMHO. Such stack protection should not be relied on, it's just there to make automated attacks much more difficult. As i386 is the target for almost all of the automated attacks merely supporting i386 will do most of the good that such a tool can do. As for Adamantix people helping out, they haven't even posted to this mailing list yet, so I have no great expectations for them to help in future. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Bug#206544: ITP: nicotine -- feature complete client for the SoulSeek filesharing network
Package: wnpp Version: unavailable; reported 2003-08-21 Severity: wishlist * Package name: nicotine Version : 1.0.1 Upstream Author : Hyriand [EMAIL PROTECTED] * URL : http://nicotine.thegraveyard.org/ * License : GPL Description : feature complete client for the SoulSeek filesharing network Quoting upstream website: Nicotine is a SoulSeek client written in Python, based on the PySoulSeek project by Alexander Kanavin. It features, among other things, a completely rewritten graphical user interface which uses PyGTK-2 toolkit and a less strict user request policy. Features: Nicotine is a feature complete client for the SoulSeek filesharing network. You can use it to upload, download, search and chat. You can keep a buddy list and basically everything else a SoulSeek client is supposed to do. If you are familliar with PySoulSeek, you'll probably notice a striking resemblance in appearance. (I'll hack a better long description.) As nicotine is meant to completely supersede pyslsk, I will probably upload a dummy transitional pyslsk package installing nicotine and compatibility symlinks. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Debian Birthday in Netcraft
On Thursday 21 August 2003 13:36, Christian Perrier wrote: I like having a significant following in the former Iron Curtain countries. So the two major former Iron Curtain countries seem to be France and Germany.. :-) Well, part of Germany was on the far side of the Iron Curtain regardless of which side you are on. HTH -- vbi -- featured link: http://www.pool.ntp.org pgpBkU57BueYG.pgp Description: signature
Re: FTBFS: architecture all packages
* Goswin von Brederlow | There is also another reason, not mentioned before, for source only | uploads. It takes way less bandwith to upload a diff.gz+dsc file than | to upload a big binary package. Bandwidth has costs for buildds as well. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Bits from the RM
On Thu, Aug 21, 2003 at 05:52:32PM +0900, GOTO Masanori wrote: AFAIK, the unresolved difficult bugs are: (1) hppa build (2) dpkg (setjmp/longjmp) on sparc (3) NIS (will be fixed?) (4) misterious apache on ia64 bug. Is there a bug# for (2)? If not, could someone forward the appropriate mails to the BTS for tracking, please? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?''
RE: Bits from the RM
cobaco [EMAIL PROTECTED] wrote: On 2003-08-20 15:33, John Goerzen wrote: tne pain of breaking desktops is no less when you consider how many more desktops we're talking about here. that's assuming that all those desktops crash at the same time no? No, it's assuming that all those desktops crash with the same average frequency (probability) per duration. Consider one s = 1 company server serving c = 1000 clients (used by one user each). Let's assume any one instance of a server software (e.g. Apache) crashes with a probability p_crash = 1% at any given time (i.e. it's down 1% of the time assuming a zero recovery time), and any one instance of a client software (e.g. Mozilla) does the same. Now the expected number of users u_affected who can't use the company's intranet at any given time is... ...due to server failures: s * p_crash * u_aff,s = 1 * 0.01 * 1000 = 10 ...due to client failures: c * p_crash * u_aff,c = 1000 * 0.01 * 1 = 10 (Of course, these sets of users do overlap, but that's not relevant here.) So, assuming an equal crashing probability (AKA stability) of server and client software, the pain of breaking desktops is no less than the pain of breaking servers. qed.
Re: Debian Birthday in Netcraft
Citat Christian Perrier [EMAIL PROTECTED]: Quoting Christian Surchi ([EMAIL PROTECTED]): From Netcraft newsletter and web site: Debian Linux distribution 10 years old today http://news.netcraft.com/archives/2003/08/16/debian_linux_distribution_10_years_old_today.html I'm not so sure about the value of their Debian geographical distribution, maybe... :-) Wow.According to this chart, about a third of hosts running Debian are in France.. :-) I know that one of the major search site portals (and one of their major sites is in France) uses Debian Woody. Regards, Martin List-Petersen martin at list-petersen dot se -- BOFH excuse #260: We're upgrading /dev/null
Re: stack protection
Who is interested in stack protection? I am. I think it would be good to have some experiments of stack protected packages for Debian. Probably the best way to do this would be to start with ssh-stack and sysklogd-stack being uploaded to experimental. I don't have time to do this, but I would like to help test it. I think it would be good too, but I would rather speak about 'security enhanced packages' in general. Nowadays, we are able to achieve way better things than just stack protection (see end of message). Also is there any interest in uploading a kernel-image package with the grsec PaX support built in? Do you mean a grsec kernel with some security options (such as PaX) enabled by default? Yes, it would be a good thing, and it's even necessary to have kernel based stuff to achieve good protection. gsecurity is a good choice because it includes PaX and adds some nice tricks (chroot() hardening, /proc restritions..) and a full ACL system. Here's (basically) what PaX can provide: - A non-executable pages semantic for alpha, i386, parisc, ppc, sparc, sparc64, which means the ability to build readable/writeable but non executable pages on those architectures which is achieved by some nice tricks on i386 (because there is no hardware support). - Use of this new semantic in the kernel (this is called MPROTECT feature), this will ensure that memory is writable (x)or executable but not both. This is achieved as a modification to mmap() and mprotect() interface, and as a result, you cannot create non executable anonymous mapping, and file mapping are NEVER executable/writable at the same time. (This means that you have a non executable stack, non executable heap and much more). - Address space layout randomization: (to prevent return-to-libc attacks), this tries to randomize the base adresses of stack, heap, mmaped libraries. This require no userland modification. But it does more, it will even randomize the main ELF executable (like .text section) and this is where 'security hardened' packages could be usefull. Because this randomization, to be done the proper way (without any performance impact) needs relocation information which is not available in most ELF files (which are ET_EXEC), but is in ET_DYN ELF files. Without this relocation, PaX can do a kind of 'emulation' (called RANDEXEC) which has a performance impact. Those ET_DYN ELF executables can (rather) easily be produced using a propolice gcc with some modified specfiles. This hardened gcc is already available for gentoo (thanks to pappy/solar). Debian could have a hardened gcc package, and have some binary packages (such as sshd) compiled with it. Compatibility: first, not all architectures are supported by PaX' NOEXEC. Second there are a few applications relying on the fact that the heap is executable (X, java..), PaX features can be disabled 'per executable', but not (for now) 'disabled by default and enabled 'per executable'. The 'security hardened' packages are no use for NOEXEC anyway (which does'nt need anything userspace), so this could be let disabled by default in the secure kernel, and we could enable ASLR only in PaX. Anyway, imho, this kernel stuff should be treated separately, but grsecurity is a good choice for a secure kernel, because it's ACL are needed to prevent some attacks for which PaX cannot do anything. For the 'security hardened' binary packages: building ET_DYN executables will improve security if PaX ASLR is enabled in kernel, but it will work just like a good old ET_EXEC if it is not. So I think it would be a good idea to build ET_DYN executable in 'security enhanced' packages. So, a security enhanced package, built using propolice + beeing ET_DYN will have all the features of propolice, and, if PaX ASLR is loaded in kernel, it will achieve another good protection layer. Julien
Bug#206576: ITP: livejournal -- The code that runs livejournal
Package: wnpp Version: unavailable; reported 2003-08-19 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: livejournal Version : 2003042200 Upstream Author : Brad Fitzpatrick [EMAIL PROTECTED] * URL : http://www.livejournal.com/code * License : LGPL (possibly others, clarifying) Description : The code that runs livejournal Livejournal is the collection of scripts and templating technologies used to set up your own livejournal-like site. Note: The license isn't exactly specified everywhere, and I'm getting confirmation from brad on the rest of the individual items - -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux starlite 2.4.19-686 #1 Mon Nov 18 23:59:03 EST 2002 i686 Locale: LANG=C, LC_CTYPE=C -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/RObbZNh5D+C4st4RAtirAJ4v8z4wW3UYXzy4rdAuUQYszPcDtgCcCDXu YLjSMcM3P3U3iFhh5DfmDr0= =pYyR -END PGP SIGNATURE-
Re: stack protection
Russell Coker wrote: On Thu, 21 Aug 2003 19:13, Stefan Gybas wrote: However, ProPolice has not been ported to all architectures yet, see http://www.research.ibm.com/trl/projects/security/ssp/statuschart.html for details. Not being ported to all architectures is not a problem IMHO. Such stack protection should not be relied on, it's just there to make automated attacks much more difficult. As i386 is the target for almost all of the automated attacks merely supporting i386 will do most of the good that such a tool can do. As for Adamantix people helping out, they haven't even posted to this mailing list yet, so I have no great expectations for them to help in future. Please have a look at your email groetjes, Age Huisman
Latest gcc-3.3 and kernel compilation
Are we expecting the latest unstalble gcc compiler to correctly
compiler the kernel?
gcc --version
gcc (GCC) 3.3.2 20030812 (Debian prerelease)
I'm getting a new error when I compile the kernel. In the structure
below, it doesn't like the declaration for slot_tablen complaining
that
ide-cd.h:440: error: long, short, signed or unsigned used invalidly for
`slot_tablelen'
It looks like it doesn't like the obviously invalid use of short in
the declaration. How does this affect our wish to move to the new
compiler?
struct atapi_mechstat_header {
#if defined(__BIG_ENDIAN_BITFIELD)
__u8 fault : 1;
__u8 changer_state : 2;
__u8 curslot : 5;
#elif defined(__LITTLE_ENDIAN_BITFIELD)
__u8 curslot : 5;
__u8 changer_state : 2;
__u8 fault : 1;
#else
#error Please fix asm/byteorder.h
#endif
#if defined(__BIG_ENDIAN_BITFIELD)
__u8 mech_state: 3;
__u8 door_open : 1;
__u8 reserved1 : 4;
#elif defined(__LITTLE_ENDIAN_BITFIELD)
__u8 reserved1 : 4;
__u8 door_open : 1;
__u8 mech_state: 3;
#else
#error Please fix asm/byteorder.h
#endif
byte curlba[3];
byte nslots;
__u8 short slot_tablelen;
};
Re: Transition: new PAM config file handling in unstable
Steve Langasek wrote: - It will now be possible to choose md5 vs. crypt passwords at install time without violating policy. (Currently, a number of conffiles are being modified by maintainer scripts in order to enable md5 passwords.) Actually making this process policy-compliant will require changes to a number of other packages prior to release. It's great to finally have this. Have you considered doing something to ease upgrades of systems whose admins chose to enable md5 passwords via passwd's debconf questions? [EMAIL PROTECTED]:/home/joeydebconf-show passwd |grep md5 * passwd/md5: true If that is set then it would probably be a good idea if services continued to support md5 after the transition. I'm not a pam expert, but maybe /etc/pam.d/other would be changed to include md5 in this case? -- see shy jo pgpqMRnbiFZMH.pgp Description: PGP signature
Re: Latest gcc-3.3 and kernel compilation
On Thu, Aug 21, 2003 at 09:37:40AM -0700, Marc Singer wrote: gcc --version gcc (GCC) 3.3.2 20030812 (Debian prerelease) I'm getting a new error when I compile the kernel. In the structure below, it doesn't like the declaration for slot_tablen complaining that ide-cd.h:440: error: long, short, signed or unsigned used invalidly for `slot_tablelen' What version of the kernel? gcc 3.3 is known to not work with kernels less than 2.4.21, I think... Have a look in the gcc 3.3 or kernel-package docs. (I don't remember where I read that.) -- Paul TBBle Hampson [EMAIL PROTECTED]
Re: Latest gcc-3.3 and kernel compilation
__u8 short slot_tablelen; Isn't it just a plain error? Either it's a char, or it's a short. It can't be both, right? -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/
Re: stack protection
Op do 21-08-2003, om 09:49 schreef Russell Coker: On Thu, 21 Aug 2003 17:39, Xavier Roche wrote: Major issues for a ro-/ are maybe: - using devfs for /dev (kernel 2.4 and package devfsd installed) Devfs is getting less support now, it might not be the best time to start depending on it. Let's turn that into 'it might be a good time to stop depending on it'. Debian-installer heavily depends on devfs... -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: Bits from the RM
On Thu, Aug 21, 2003 at 11:39:35AM +0200, Marc Haber wrote: I am only realistic. When in history did a non-trivial software product meet its release schedule? I am surely hoping for the best, but I seriously do expect sarge to be released in early 2004. Which is a pretty good track record if we actually reach that. Well, FreeBSD hits their 6-month release targets more often than they miss them (yes, they do miss them sometimes, generally not by very far). True, they've had practice at it; I don't expect the first attempt to be pretty. I do expect that we could manage to match them, if it becomes a consistant release goal to set a date and then hit it. :) Even 'early 2004' is, frankly, not nearly enough time to ensure something as large as KDE goes from 'stable' upstream release (assuming *they* make a Dec 8th release) to 'bugs shaken out, stable enough to not need to turn around and do an r1 release a few weeks later because it blows up on user machines', for values of 'early 2004' that I would find most likely (to wit, right *after* the holidays, since slipping too much would put us into releasing during them; though the Debian Christmas Release would be mildly entertaining :) -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpE56YX0Cv4q.pgp Description: PGP signature
Re: stack protection
On Thu, Aug 21, 2003 at 07:16:46PM +0900, Miles Bader wrote: Russell Coker [EMAIL PROTECTED] writes: Devfs is getting less support now, it might not be the best time to start depending on it. Indeed, it's looking likely that GregKH's `udev' will replace devfs sometime in the future. Dare I ask the obvious question: what is udev? Why is it better then devfs? -- Brian May [EMAIL PROTECTED]
Re: Debian Weekly News - August 19th, 2003
We musn't let the bigots decide for us! ;-) Sorry, but that insult doesn't put a winksmiley on my face. Please don't try to start a useless flamewar. They break out so easily on their own. There is no need to discuss this matter here; it has already been thoroughly discussed in debian-legal and that is the best place to continue the discussion if you really can't let the subject drop. -- Thomas Hood
Re: FTBFS: architecture all packages
On 21 Aug 2003, Goswin von Brederlow wrote: Doogie already said he wants to implement a smart comparator for deb in dpkg 2.0 which would then be used to compare that different builds of the binary-all even give the same result. This means you give the 2 debs(which probably only differ by debian revision) to this new tool, and the output will be a differential deb, which will contain just the changes. However, this is really a minor feature, that may not even be part of 2.0; it may wait for a slightly later version.
Re: stack protection
On Thu, 21 Aug 2003 22:41, Brian May wrote: On Thu, Aug 21, 2003 at 07:16:46PM +0900, Miles Bader wrote: Russell Coker [EMAIL PROTECTED] writes: Devfs is getting less support now, it might not be the best time to start depending on it. Indeed, it's looking likely that GregKH's `udev' will replace devfs sometime in the future. Dare I ask the obvious question: what is udev? Why is it better then devfs? A paper on udev was presented at OLS this year, at the URL below you can find a copy in PDF format. Basically it is a way of providing some of the features of devfs but based around using hotplug to create device nodes using mknod under a regular directory. So there is no mountable /dev. http://archive.linuxsymposium.org/ols2003/Proceedings/ As for why it's better than udev. There have been bugs in devfs in the past related to race conditions. Also devfs requires that the kernel knows about all the device nodes, whether this is a bug or an excellent feature is a matter of opinion. I would prefer that devfs was kept as it's worked well for me. But that it seems that things are moving away from it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Bits from the RM
On Thu, 21 Aug 2003, Anthony Towns wrote: On Thu, Aug 21, 2003 at 05:52:32PM +0900, GOTO Masanori wrote: AFAIK, the unresolved difficult bugs are: (1) hppa build (2) dpkg (setjmp/longjmp) on sparc (3) NIS (will be fixed?) (4) misterious apache on ia64 bug. Is there a bug# for (2)? If not, could someone forward the appropriate mails to the BTS for tracking, please? I'd be interested too. Haven't seen anything on -dpkg about it.
Re: Latest gcc-3.3 and kernel compilation
On Thu, Aug 21, 2003 at 12:44:11PM -0400, Ben Collins wrote: __u8 short slot_tablelen; Isn't it just a plain error? Either it's a char, or it's a short. It can't be both, right? That's what I think, too. It looks, too, to be something added in a patch because the indentation is different. As Ben pointed out, it looks like I can only compile 2.4.21 with gcc-3.3. Working on it.
Re: What doing with an uncooperative maintainer ?
Marcelo E. Magallon [EMAIL PROTECTED] wrote: Talk with the maintainer. Or NMU. Or make noise on -devel. But don't fork packages. I agree and disagree. Talking with the maintainer works sometimes. Sometimes one is in a position to NMU. Sometimes it helps to make noise on debian-devel. But sometimes there are fundamental disagreements about how something should be packaged and then it must be possible for two competing packages to exist in Debian between which users can make a choice; otherwise you are giving maintainers the same rights as software proprietors: _they_ control the code; _you_ can't change it (while remaining within the Debian framework) even if you are willing to do the work. I say you should _not_ give maintainers that kind of power -- the power to stop others from doing a better job. That kind of power will inevitably be abused, and has already been abused. Every maintainer should face the threat of competition from someone else who thinks he or she can do a better job. That is an essential freedom in open source development. There are already many programs in Debian that are packaged in different flavors. Most of these are upstream-stable and upstream-developmental variants. These variants serve the needs of different sorts of users. From reading this thread it is my impression that gqview falls into this group: the gqview maintainer has a conservative packaging policy while his critics want to run the latest version. Unless one side gives in, this seems like adequate grounds for a fork. -- Thomas Hood
Re: [RFC] Debian ruby policy (Re: Fw: Re: Ruby 1.8 transition plan; debian-ruby)
On Thu, Aug 21, 2003 at 02:53:12AM +0900, Fumitoshi UKAI wrote: FU Dmitry Borodaenko [EMAIL PROTECTED] FU libyaml-ruby1.8 (- libyaml-ruby) I think that since whytheluckystiff is developing Syck/YAML right in the Ruby CVS, there is little chance for a separation of libyaml-ruby1.8 in the near future, and I'm quite happy with it being maintained by akira as part of ruby1.8. I am inclined to keep libyaml-ruby1.6 (renamed from current libyaml-ruby as soon as ruby-defaults is out), and make a libyaml-ruby metapackage that depends on libyaml-ruby1.6 | libyaml-ruby1.8, so that a program that doesn't care about Ruby version would pull in either 1.6 or 1.8 version, depending on the version of Ruby installed. -- Dmitry Borodaenko
Re: Does anyone use barrendero, or know of an equivalent?
On Thu, Aug 21, 2003 at 10:42:28AM +0200, Sam Hocevar wrote: On Wed, Aug 20, 2003, Steve Langasek wrote: But descriptions can be deceiving. Does anyone use this package who could comment on its reliability? Does the lack of other bugs indicate that the software is mature and stable, or unused? I am trying barrendero but don't trust it enough yet for production use. I had worked on an NMU that fixes all bugs and makes the package a bit more polished, I just reviewed it and uploaded it here: http://zoy.org/~sam/debian/barrendero_1.0-1.1.diff.gz I haven't contacted the maintainer yet because I was working on other bugs, but if he is MIA as you seem to be suggesting, I'll probably upload that NMU to DELAYED quite soon. Does anyone know of another package that provides similar functionality? mail-expire is very close to it. Ok, thanks for the info. Can you estimate when you think you'll NMU? -- Steve Langasek postmodern programmer pgp4QAtphkpu7.pgp Description: PGP signature
Re: Debian Weekly News - August 19th, 2003
Jérôme Marant dijo [Thu, Aug 21, 2003 at 12:18:10PM +0200]:
consensus
n : agreement of the majority in sentiment or belief
[syn: {general agreement}]
unanimity
n : everyone being of one mind
A world of difference.
No, no, no! You don't get it. There may be a majority among the
debian-legal zealots, but we need a consensus among Debian as a
whole (which means voting of course).
We musn't let the bigots decide for us! ;-)
Well... If you really disagree with the 'bigots' on this, please join
debian-legal and join the opposition. I do think that most of us
non-'bigots' will agree with the consensus reached in debian-devel - Me
not joining that list means I don't have all the background (and, yes,
the interest) to debate their decision - and they are mostly people who
most of us hold in quite a nice position.
Now, why am I insisting in quoting the 'bigots'? Because they care.
Because being involved in all those convoluted discussions in our
behalf, in subjects we all care about but don't want to fuss over too
much makes them respectable people in my eyes.
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: non-DD contributors and the debian keyring
* Martin Quinson ([EMAIL PROTECTED]) wrote: On Wed, Aug 20, 2003 at 05:03:17PM -0400, Stephen Frost wrote: I doubt a poor translation would make it into a released version. A lot of poor translation get into stable, mainly by lack of manwork, but you are right no offending translation gets into testing. At least in french. Sorry, I was, as you picked up, meaning 'offending' more than just 'poor'. Mmm. If so, I really cannot understand the big deal with IDs when signing the key. Knowing my ID is not enough to prove that I won't upload a rootkit, and it is not even needed... I must be perticulary dumb. It's more than just the ID, but the ID is a part of it. It's all about trust. A non-Debian example is the way I run some of my personal systems. I won't give out accounts to just anyone but if I've met someone face-to-face and had a chat with them I'm much more inclined to give them account if they have a need for one. If a friend of mine is willing to vouch for some people he/she has met and knows personally I'm more willing to give them an account. The ID comes into play when it's people who don't actually know each other all that well and don't really have much other communication. It's expected that while the person who actually checks your ID doesn't really know you all that well there are others who know you through online correspondence but just havn't met you. That's my general feeling on it anyway, it's probably different for other people. I don't beleive there's an 'official' statement about it really. What is harder for the DD and how could the existing Debian infrastructure fix that? Nothing in what you've said would lead me to believe that there's something we can change which would make things easier for the DD with regard to 'poor' translations. The whole story is about easing the technical issue in a trust relationship. At the moment there are two levels of 'trust'. There's the level where you can upload new packages and there's the level where you can submit patches and whatnot to the BTS. At least, those are the levels I perceive Debian having atm. Other people can have their own trust relationships if they feel they need them. I don't think there'd really be much advantage to putting another level in there. Of course, I could (and have) uploaded my key on public servers, meaning that other Debian member could check than a given mail with my address desserve the trust they habitually give me. But those guys would have to configure their email specifically on people like me[*]. I was wondering if could be avoided, that's all. As others have pointed out most people have their systems configured to grab keys from public keyservers already anyway. A really great improvement of this situation would be to make easily available the keys of people in the NM queue, since translators are supposed to become debian developer, too. Ok, if you think it'd be all that great then do it and see if anyone actually uses it. I'd be happy to host it on personal servers if you need someone to host it. I might even be willing to sponsor a new Debian package of it if it actually gets popular. But, ok, if the majority here says that there would not be sufficient benefit wrt the effort, I guess I'll have to deal with it. Easy :) I doubt it, but hey, if you want to spend your time doing it, go for it. Stephen pgpp72ZGiHk8D.pgp Description: PGP signature
Re: non-DD contributors and the debian keyring
* Martin Quinson ([EMAIL PROTECTED]) wrote: Judging from the amount of translation rotting in the BTS, I guess some of you guys react the same way, and I want to change this by easing this trust relationship, if possible. Eh. Personally I tend to doubt it's lack of trust that's causing translations to rot in the BTS. Stephen pgpXrUm9qmN9q.pgp Description: PGP signature
Re: Debian Birthday in Netcraft
Christian Perrier dijo [Thu, Aug 21, 2003 at 01:36:02PM +0200]: Wow.According to this chart, about a third of hosts running Debian are in France.. :-) For sure, several major web hosting and Internet Access Providers run Debian hosts for their key servers herebut I think this graph is somewhat wrong anyway.. I like having a significant following in the former Iron Curtain countries. So the two major former Iron Curtain countries seem to be France and Germany.. :-) Isn't Netcraft CCCP-based? If so, I think it is right - The 'former Iron Curtain' countries (if I understand correctly, meaning 'the countries that were behind te Iron Curtain' include Germany(west), France, USA, UK and the Netherlands :-) -- 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: stack protection
On Aug 21, Xavier Roche [EMAIL PROTECTED] wrote: - using devfs for /dev (kernel 2.4 and package devfsd installed) devfs will probably disappear. It's better to look at udev (which I'm packaging). - transforming several /etc files as symlinks and moving them to some other place (/var/etc ?) There have been long threads about this, a ro-root is almost possible with minimal local changes. -- ciao, | Marco | [1392 ug4klQcM3go0s]
Re: What doing with an uncooperative maintainer ?
On Thu, Aug 21, 2003 at 03:05:00PM +0200, Thomas Hood wrote: But sometimes there are fundamental disagreements about how something should be packaged and then it must be possible for two competing packages to exist in Debian Says who? Debian is not just a collection of packages, it's a tightly integrated operating system. This is a distribution. What we deem good development practices for/of free software doesn't have to apply here. As a distribution, we have different goals, we have to make desicions that fit into that picture. Along the years we have created a system that ensures that when you install something, it will get integrated into the system. For that we have had long and painful discussions regarding best practices and long and painful discussions to make stuff work together. We have (implicitly) agreed on the fact that the package maintainer is a person who knows what he's talking about when it comes to his packages. If the package maintainer deems it appropiate to upload a snapshot version of a package we have usually played along. If the maintainer thinks the lastest and greatest is not really such a good idea, we have played along: see the XFree86 packages. Every now and then packages of the most recent version of XFree86 pop up, but people usually give up when they gasp the swamp they are getting themselves into. For the small stuff, like gqview -- which I've not seen even once -- that proposition might work, but it's setting a bad precedent. If there's a newer bigger better faster upstream version and the maintainer won't upload it and won't say why, by all means, flame him in public if that's what it takes to get an answer from him. If it's obvious that the maintainer isn't paying attention to the package or just doesn't care, make a hostile takeover (and be ready to get flamed). But don't fork it. Forking it means: * There are two versions of the same thing in the distribution + Duplication at the BTS level + Duplication in the archive + Confusion for the users * No visible gain, except for those who have to have the CVS version from 2 seconds ago * More work for the future + What about upgrades? + What if the forked version isn't necessary anymore? + What about users of stable, who are stuck with a random CVS snapshot for good 24 months. otherwise you are giving maintainers the same rights as software proprietors: _they_ control the code; _you_ can't change it (while remaining within the Debian framework) even if you are willing to do the work. You don't really beleive that, do you? I know the control freak mantra has become trendy as of late, but that's stretching it a bit too far, isn't it? I hold that if you do a good work with a alternative yet not in the archive version, you can come up here and say I'll take over this without the maintainer's blessing and you won't face oppossition. My first package was uploaded like that: hi, I've been maintaining such and such for private use for a while, the maintainer doesn't show any signs of life, I'm going to take over it. Yes, gqview's case is a tad different, but try to see the big picture. I say you should _not_ give maintainers that kind of power -- the power to stop others from doing a better job. We don't. That kind of power will inevitably be abused, and has already been abused. Every maintainer should face the threat of competition from someone else who thinks he or she can do a better job. That is an essential freedom in open source development. Yes, in software development, but not in a distribution that tries to pass around as well integrated and stable. There are already many programs in Debian that are packaged in different flavors. I don't count that many: galeon, xnap, mozilla, irssi, gcc, gforge, everybuddy, busybox, lxr... These variants serve the needs of different sorts of users. From the above list, I can tell you that GCC's case is a good one: developers benefit from it, people using certain architectures benefit from it, GCC itself benefits from it to some degree. Mozilla is a good case too: their release policy is rather conservative (from my POV) and users in general might benefit from snapshot versions. Everybuddy? No idea. The CVS version in unstable is, oh... the same one in stable. Someone got bored it seems. See what I mean? Busybox, I can figure the installer people need (to test) this. From reading this thread it is my impression that gqview falls into this group: the gqview maintainer has a conservative packaging policy while his critics want to run the latest version. Unless one side gives in, this seems like adequate grounds for a fork. wget. tar. configure. make. The system won't explode, beleive me. Marcelo
When to call update-alternatives?
Well, I know that in postinst and prerm, but when which argument is passed? I thought that cd /var/lib/dpkg/info grep -10 update-alternatives *postinst|less -S would help me, but it did quite the contrary. There is a total mess! A quick summary of how it is called in different packages: - always ($1 is not tested at all), - if [ $1 = configure ] - if [ $1 != upgrade ] - if [ $1 = configure -o $1 = abort-upgrade ] - if [ $1 = configure -o $1 = upgrade ] They can't all be right? After rereading section 6 of the policy, I think that the right way is to call it in postinst if [ $1 = configure ], and in postrm, if [ $1 = remove ] Is this correct? regards, Marcin -- Marcin Owsiany [EMAIL PROTECTED] http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Re: Debian Weekly News - August 19th, 2003
On Thu, Aug 21, 2003 at 12:18:10PM +0200, Jérôme Marant wrote: We musn't let the bigots decide for us! ;-) Thanks for excusing yourself from the discussion thus. -- G. Branden Robinson| Software engineering: that part of Debian GNU/Linux | computer science which is too [EMAIL PROTECTED] | difficult for the computer http://people.debian.org/~branden/ | scientist. pgpPlwwt5ARnc.pgp Description: PGP signature
Hungarian DDTP on the Xth B'day
Hi all, The main goal of this party was to translate Debian package descriptions. Unfortunately Gluck, where the ddts server is, was down quite a long time and installing a local server was not so easy as it was the first time I did this. The local server was up only a few minutes before Gluck come back. Anyway, this experience let me find a bug in the server and so was quite interresting. I would like to thanks everyone at Budapest for the good time I spend there for the Debian 10th birthday last week-end. Regards Nicolas Bertolissio -- pgpFYJzwywa09.pgp Description: PGP signature
Re: Monitoring RC bugs
On Thu, Aug 21, 2003 at 08:05:01PM +0100, Colin Watson wrote: So, all mails sent to bugs with release-critical severities, including acknowledgements of control messages, will now be copied to a new list: [EMAIL PROTECTED] Very nice! -- Jamin W. Collins To be nobody but yourself when the whole world is trying it's best night and day to make you everybody else is to fight the hardest battle any human being will fight. -- E.E. Cummings
Re: stack protection
On Thu, Aug 21, 2003 at 10:41:16PM +1000, Brian May wrote: Indeed, it's looking likely that GregKH's `udev' will replace devfs sometime in the future. Dare I ask the obvious question: what is udev? Why is it better then devfs? It's mostly in user-space, lighter-weight, and more configurable. It relies on a clever use of other existing kernel features (ramfs, hotplug callouts, sysfs) rather than being a big chunk of special purpose code wired into kernel space. Also, the naming policy is entirely in user-space, there are no wacky device naming conventions in the kernel where they can cause big flamewars. -Miles -- `Suppose Korea goes to the World Cup final against Japan and wins,' Moon said. `All the past could be forgiven.' [NYT]
Re: better make a standard for /etc/*/*_not_to_be_run
I retain hope that this discussion can end in agreement on the issue raised in #156161. Toward that end I offer the following interpretation of what has been said and finally a proposal. The original question was about how to prevent services from being started. Some packages employ a mechanism (a flag file, or an environment variable set it in an /etc/default/ file) other than the standard rc mechanism for switching services on and off. The brief reply to this was: Don't do that. The standard mechanism for enabling and disabling services in runlevels is update-rc.d, so please use that. This answer is basically right. If I run /etc/init.d/foo start then foo should start. Period. We have to accept, however, that people want, in addition to the rc system, a simple way globally to enable and disable a given service. The reason is that if one decides to disable a service by setting all its rc?.d symlinks to K then he loses the infor- mation about what those symlinks should be named when the service is reënabled. Such a mechanism has been wished for in #67095 and #123446 among other places. Perhaps those wishes should be fulfilled and something should be written to make it easy for the admin to disable and enable a service without destroying the rc symlink farm information. Such a utility would use update-rc.d to make changes (as required by policy) but would remember how things were set up before the service was disabled so that that situation could easily be restored. Whether and how that wish is granted is not my main concern here. What I would like to know is whether we can agree to enhance the rc system by defining what happens when there is neither a start nor a stop symlink for a service in a given runlevel. Henrique de Moraes Holschuh and I discussed this point earlier but we didn't see eye to eye because we were approaching it with different assumptions about what the right behavior is. HdMH assumed that all services are supposed to be controlled by the rc system which requires that there be either an S or a K symlink for each service in every runlevel directory. If there is neither an S nor a K symlink for a service in a particular directory then this is operator error and the behavior of the system is undefined. It follows that it isn't a bug that invoke-rc.d starts the service. I was approaching the issue under the assumption that if there is neither an S nor a K symlink for a service in a particular runlevel directory then that means that the rc system should not change the state of the service but should leave a running service running and a stopped service stopped. #156161 was originally rated as a bug report based on this assumption. I am now willing to grant that HdMH is right and that _currently_ the behavior of the rc system is not defined if there is neither an S nor a K symlink for a service in a given runlevel directory. My proposal is that the behavior of the rc system _be_ defined such that it works the way I assumed it was supposed to work, i.e., such that if there is neither an S nor a K symlink for a service in a particular runlevel directory then that service is to be neither started nor stopped on entering that runlevel. The advantage this specification would have is that it would allow maintainers to install services and initscripts that are not by default under the control of the rc system but under the control of the administrator who can run the initscript with start and stop arguments. Changing runlevel would neither start nor stop these services unless the administrator chose to put the service under the control of the rc system by setting up symlinks in the runlevel directories. The absence of S and K symlinks would mean manual. I have downgraded #156161 to a wish for this enhancement. If a utility was written to make it more convenient to disable and enable a service, as discussed above, then one could add a manual state (no symlinks) to the disabled (all K symlinks) and enabled (not all K symlinks) states. Is this a good idea? If not, I would be interested to know where the problems lie. -- Thomas Hood
