GR: Disambiguation of Section 4.1.5 of the constitution
Hi folks, Two years and 45 weeks ago, a pair of proposals were bruited on this mailing list; the details are available in the archives of debian-vote, and debian-project, circa October 2000. The proposals themselves are available at http://www.debian.org/vote/. This issue is the second of three major issues pending for the secretary to handle when I took office, and I suppose it is due time to start, now that debcamp and debconf are long over. I must confess I am not looking forward to this, since I am intimately involved in one of the proposals, and I am afraid that this issue is likely to invoke high passion from proponentns of either alternative (which is an attempt to explain, though not excuse, my foot dragging on this GR). Oh, and I haven't coded up the new vote counting protocol we agreed upon yet. Any, Please consider this issue reopened, and after a discussion period, when people have agreed upon any modifications that need be made to the proposals, we shall enter the formal two week discussion period, and then vote. manoj -- FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #21 A: Dr. Livingston I. Presume. Q: What's Dr. Presume's full name? 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 pgpz7dYvehxK2.pgp Description: PGP signature
Transition: new PAM config file handling in unstable
An NMU of the core PAM packages has just been uploaded to unstable with
the maintainer's permission, and is currently available at
http://incoming.debian.org. The upload addresses the longstanding issue
of central management of PAM authentication/password services in Debian.
This message is an appeal for further testing, and an attempt to
document what needs to be done in other PAM-using packages to take
advantage of these exciting new features.
From the changelog:
* Add three new config files (/etc/pam.d/common-{auth,account,session})
to libpam-runtime. Other packages which depend on libpam-runtime
can now @include these files from their own PAM configs.
* Convert /etc/pam.d/other from a conffile to a non-conffile config
file. Closes: #186011.
What this means:
- 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.
- As packages switch to this new config file scheme, administrators will
have a central set of files (four) they can edit to set a system-wide
policy for authentication to services, including services from
not-yet-installed packages; while packagers can continue shipping
their per-package default settings as conffiles.
- At a later date, it will be possible to support tools for
debconf-based management of the authentication subsystem so that
administrators can seamlessly integrate workstations into (e.g.)
Kerberos, LDAP, or Windows NT authentication realms. No work has been
done yet to develop these tools, and they are unlikely to be ready in
time for sarge; but this is a realistic goal for sarge+1, or for
customized installers based on sarge.
I believe that, with your help, we can convert most PAM-enabled packages
in Debian in time for Sarge's release, following the guidelines below.
- 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.
- 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.
- A versioned dependency on libpam-runtime (= 0.76-13.1) must be added
to each PAM-using package. In addition, packages that don't already
depend on the libpam-modules package must do so. (Transitive circular
dependencies prevent libpam-modules from being pulled in
automatically for you.)
- Essential packages which currently pre-depend on libpam0g (read:
login) will also need a versioned Pre-Depends on libpam-runtime
before adopting this scheme, so that they are usable in an
unconfigured state. Please consider this an introduction to the
debian-devel discussion as mandated by Policy section 3.5.
This concludes the roadmap for sane PAM handling in sarge. Should be
straightforward, right? It's only 100 packages or so...
One final comment: I know how excited everyone will be about this
revolutionary breakthrough, but owing to the newness of this change, I
would ask that you *not* avail yourselves of the 0-day policy to start
NMUing packages as part of this transition. A partial transition for
sarge is much better than locking users out of their systems, so there's
no need to be impatient with maintainers before we've even put the
code through its paces in unstable.
Happy Hacking,
--
Steve Langasek
postmodern programmer
pgp2ZJtPRfxv8.pgp
Description: PGP signature
Pb avec entrée de menu
Un souci pour mettre une entrée de menu pour Geneweb. Celui-ci est un démon qui écoute sur le port 2317 et sert, par le Web, des bases de données généalogiques. Je voudrais que mon paquet ajoute une zoulie entrée dans le système de menus Debian. Donc, je fais un debian/geneweb.menu avec ceci : ?package(geneweb):\ needs=text\ section=Apps/Tools\ title=Geneweb\ hints=Geneweb genealogy software\ command=/usr/bin/www-browser http://localhost:2317\ icon=/usr/share/pixmaps/geneweb.xpm L'icône est bien installée (et en plus elle a les couleurs qui ne font pas râler lintian) Mon debian/rules fait un dh_installmenu et, pas de pbs, l'entrée apparaît bien où il faut. Par contre, quand je l'utilise, j'ai ceci qui apparaît dans mon .xsession-errors : Argument invalide : « http://localhost:2317 » et rien ne se passe Par contre si j'utilise à la main cette commande, tout va bien : /usr/bin/www-browser http://localhost:2317 (www-browser est mozilla chez moi mais ça marche aussi si je change l'alternative pour lynx...) Une idée, quelqu'un ? --
Re: Pb avec entrée de menu
Christian Perrier wrote: Un souci pour mettre une entrée de menu pour Geneweb. Celui-ci est un démon qui écoute sur le port 2317 et sert, par le Web, des bases de données généalogiques. Je voudrais que mon paquet ajoute une zoulie entrée dans le système de menus Debian. Donc, je fais un debian/geneweb.menu avec ceci : ?package(geneweb):\ needs=text\ section=Apps/Tools\ title=Geneweb\ hints=Geneweb genealogy software\ command=/usr/bin/www-browser http://localhost:2317\ icon=/usr/share/pixmaps/geneweb.xpm L'icône est bien installée (et en plus elle a les couleurs qui ne font pas râler lintian) Mon debian/rules fait un dh_installmenu et, pas de pbs, l'entrée apparaît bien où il faut. Par contre, quand je l'utilise, j'ai ceci qui apparaît dans mon .xsession-errors : Argument invalide : « http://localhost:2317 » et rien ne se passe Par contre si j'utilise à la main cette commande, tout va bien : /usr/bin/www-browser http://localhost:2317 (www-browser est mozilla chez moi mais ça marche aussi si je change l'alternative pour lynx...) Une idée, quelqu'un ? /bin/sh -c \/usr/bin/www-browser http://localhost:2317\;
Re: Pb avec entrée de menu
Une idée, quelqu'un ? /bin/sh -c \/usr/bin/www-browser http://localhost:2317\; Argument invalide : « /usr/bin/www-browser http://localhost:2317 » :-)
Re: Pb avec entrée de menu
Le mer 20/08/2003 à 11:47, Christian Perrier a écrit : ?package(geneweb):\ needs=text\ section=Apps/Tools\ title=Geneweb\ hints=Geneweb genealogy software\ command=/usr/bin/www-browser http://localhost:2317\ icon=/usr/share/pixmaps/geneweb.xpm L'icône est bien installée (et en plus elle a les couleurs qui ne font pas râler lintian) lintian n'a pas été corrigé, mais maintenant menu n'exige plus ces couleurs. 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. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: lancement d'un daemon lors d'un upgrade
Benoit Friry a écrit : Bonjour, Lors de l'upgrade d'un paquet correspondant à un daemon[1], le script de pré-installation l'arrête[2] et le script de post-installation le relance[3] quel qu'est été l'état précédent. Je trouve ce comportement erroné, dans la mesure où l'upgrade ne remet pas le système dans l'état où il était avant, ni même dans l'état correspondant à son initlevel (system V). Oui, je suis d'accord avec toi... Ca m'est arrivé plusieurs fois, et si on upgrade beaucoup de paquets en même temps, c'est limite lourdingue :( Claude
Re: lancement d'un daemon lors d'un upgrade
Le Wed, Aug 20, 2003 at 05:06:53PM +0200, Benoit Friry écrivait: arrêté[5]. Mais si je mets ma machine à jour, et que zope est dans le lot d'upgrade, ce dernier sera lancé. Maintenant, je connais ce comportement et j'y fait attention. Mais je pense que c'est plutôt un « bug » qu'une « feature ». Et tu n'es pas le seul. C'est pour cela qu'on a inventé invoke-rc.d, cf sa page de manuel. Maintenant il faut que tous les paquets qui ont des /etc/init/monpaquet restart dans leur postinst soient modifiés pour utiliser invoke-rc.d. Je ne suis pas sûr par contre de l'état d'avancement d'une proposition cherchant à imposer son emploi au niveau de la Debian Policy. Il faudrait vérifier. Je note aussi que la page de manuel parle de policy-rc.d mais que ce programme n'existe dans aucun paquet de unstable. Aussi je ne suis pas sûr qeu tout soit prêt pour être imposé ... Mais le problème est connu, et il sera un jour résolu. :-) 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: Pb avec entrée de menu
Josselin Mouette [EMAIL PROTECTED] wrote: 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. Par ailleurs il me semble qu'il n'y a pas de pseudo-package x-www-browser alors que le www-browser existe, ce qui est un poil emmerdant pour les dépendances. J'ai déja songé à lancer la discussion pour ce pseudo-package... JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
Re: lancement d'un daemon lors d'un upgrade
On Wednesday 20 August 2003 20:30, Raphael Hertzog wrote: Je note aussi que la page de manuel parle de policy-rc.d mais que ce programme n'existe dans aucun paquet de unstable. Aussi je ne suis pas sûr qeu tout soit prêt pour être imposé ... Le policy-rc.d est prévu pour être personnalisé, aka écrit à la main ; il manque simplement les exemples. Y a eu un petit thread là dessus sur debian-devel y a ptêt un ou deux mois... -- I have sampled every language, french is my favorite. Fantastic language, especially to curse with. Nom de dieu de putain de bordel de merde de saloperie de connard d'enculé de ta mère. It's like wiping your ass with silk! I love it. -- The Merovingian, in the Matrix Reloaded
Re: lancement d'un daemon lors d'un upgrade
* Raphael Hertzog [EMAIL PROTECTED] [2003-08-20 20:30] : Le Wed, Aug 20, 2003 at 05:06:53PM +0200, Benoit Friry écrivait: arrêté[5]. Mais si je mets ma machine à jour, et que zope est dans le lot d'upgrade, ce dernier sera lancé. Maintenant, je connais ce comportement et j'y fait attention. Mais je pense que c'est plutôt un « bug » qu'une « feature ». Et tu n'es pas le seul. C'est pour cela qu'on a inventé invoke-rc.d, cf sa page de manuel. Maintenant il faut que tous les paquets qui ont des /etc/init/monpaquet restart dans leur postinst soient modifiés pour utiliser invoke-rc.d. Je ne suis pas sûr par contre de l'état d'avancement d'une proposition cherchant à imposer son emploi au niveau de la Debian Policy. Il faudrait vérifier. Section 9.3.3.2 de la Debian Policy : Running initscripts [...] The use of invoke-rc.d to invoke the /etc/init.d/* initscripts is strongly recommended[46], instead of calling them directly. De plus, la note 46 contient ceci : In the future, the use of invoke-rc.d to invoke initscripts shall be made mandatory. Maintainers are advised to switch to invoke-rc.d as soon as possible. Donc, un paquet utilisant un /etc/init.d/commande restart peut recevoir un bogue mineur ou même normal pour ce comportement. Fred
Re: python 2.2 - python 2.3 transition
On Sun, Aug 17, 2003 at 11:22:43AM +0200, Torsten Landschoff wrote: | On Wed, Aug 13, 2003 at 08:33:26AM -0500, John Goerzen wrote: | Now, I could do the dependency on python (= 2.2), python (2.3) thing. | But what would that gain me or users? I see no benefit there, other than | people tracking sid would find OfflineIMAP uninstallable until it gets | updated to depend on Python 2.3. | | There are plenty of OfflineIMAP users that don't use Python themselves, | don't care that it's written in Python -- and probably some that don't | *know* it's written in Python. | | (And yes, the bang path explicitly calls python2.2) If the program explicitly calls python2.2, then it should depend on python2.2, not python (2.2). The usefulness of depending on the default python is (IMO) geared for libraries. wxPython is just one example. This allows an admin to install the library for the default python and not have to worry about package name changes when the default python changes. (IMO the libraries _should_ also provide versions for the other currently available python versions, if possible/feasible) | The dependency on python (= 2.2), python ( 2.3) is for the case where | you have a module which loads into python and supports only a single | python version. | | After python changed you can't install that package (wxgtk-python or | whatever) anymore. The positive effect for the users is that you can't | upgrade python while wxgtk-python is installed so your system won't | break. 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. -D -- For society, it's probably a good thing that engineers value function over appearance. For example, you wouldn't want engineers to build nuclear power plants that only _look_ like they would keep all the radiation inside. (Scott Adams - The Dilbert principle) http://dman13.dyndns.org/~dman/ pgpiUSHgB0y5j.pgp Description: PGP signature
Your recent message to Topica.com
We're sorry, but the list that you have tried to post to is an announcement-only list and does not allow posts. All posts to the list come from the list owner exclusively, or from authorized subscribers. If you have questions regarding the posting policy of this list, please contact the list owner. Still have questions? Email Topica at [EMAIL PROTECTED] Please include the email address of the list you're inquiring about, and the email address you want to use to subscribe to the list. Sincerely, Topica Customer Support --- + Original Message --- Return-Path: debian-devel@lists.debian.org Delivered-To: [EMAIL PROTECTED] Received: (qmail 28203 invoked by uid 0); 20 Aug 2003 02:36:10 - Received: from unknown (HELO MYTOY) (68.160.164.223) by 0 with SMTP; 20 Aug 2003 02:36:10 - From: debian-devel@lists.debian.org To: [EMAIL PROTECTED] Subject: Re: Thank you! Date: Tue, 19 Aug 2003 22:36:12 --0400 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600. X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=_NextPart_000_00239942 This is a multipart message in MIME format --_NextPart_000_00239942 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_00239942--
away from my mail
I will be away from my office from Aug 20 to 27 and returning on Aug 28, 2003. Please contact Sharon Chan at 822-8007/[EMAIL PROTECTED] while I am away for co-op inquiries. .
[Javier Fernandez-Sanguino Pen~a jfs@computer.org] Accepted makepasswd 1.10-1.1 (all source)
Hello world, I had been hoping that I wouldn't have to resort to adding a stick to the various carrots, but evidently we have developers who aren't taking care to measure twice before cutting once. The 0-day NMU period has *not* started, and will not start until the 23rd. People who abuse this privlege by not applying a due amount of care to their NMUs will have their NMU privileges revoked in their entirety until the 0-day NMU period ends on 2003-09-15. Thankyou for your time. From: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] Subject: Accepted makepasswd 1.10-1.1 (all source) Date: Tue, 19 Aug 2003 21:32:06 -0400 To: debian-devel-changes@lists.debian.org Sender: Archive Administrator [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Format: 1.7 Date: Wed, 20 Aug 2003 02:40:37 +0200 Source: makepasswd Binary: makepasswd Architecture: source all Version: 1.10-1.1 Distribution: unstable Urgency: low Maintainer: Johnie Ingram [EMAIL PROTECTED] Changed-By: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] Description: makepasswd - Generate and encrypt passwords Closes: 44788 50885 147808 168492 190485 Changes: makepasswd (1.10-1.1) unstable; urgency=low . * Non-maintainer upload. Since the rules have changed and this package has not (since potato) I'm uploading to 0-delay. This upload will not fix any RC bugs but at least will (almost) remove all the bugs open for this package, and it didn't take me much time to figure these out... - Change program name so that the help text is displayed properly (Closes: #147808) - Now Build-Depends-Indep from debhelper (Closes: #190485) (I'm not bumping up the Standards Version since this should be revised by the maintainer) - Using --clear now exits with error warning the user that the option is no longer valid (Closes: #50885) - Added 'use bytes' as suggested by reporter to be UTF-8 clean (although I'm not sure if this bug applies any longer since I cannot reproduce it, in any case, using that module shouldn't, hopefully, break anything. (Closes: #168492) - Generate MD5 passwords with the --crypt-md5 option (Closes: #44788) Files: c3859e8823edde8a9b92cc2702fb178e 676 admin optional makepasswd_1.10-1.1.dsc 7bbe5bd187b9165b4a711c9e44ad6d6c 4172 admin optional makepasswd_1.10-1.1.diff.gz c443559fabba20d19947e1c91b4aef54 10176 admin optional makepasswd_1.10-1.1_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBP0LNMPtEPvakNq0lAQFmHAP9EC+gTZITLxCICHTEalu6SppIiI8ixil2 iJz8RVqwrVM/ApbXWAsoCDpQOVvViVYYWxjvUPFexMYB5pccF8wE3RfAdX7crU8i AGNXW5EBZ52g+0mhzSzPXiaqQihD8QPzBaDRgohq9PonUNtiUDfBVoXAFwW6l8UZ PXQhI9Ej6i4= =ZyXj -END PGP SIGNATURE- Accepted: makepasswd_1.10-1.1.diff.gz to pool/main/m/makepasswd/makepasswd_1.10-1.1.diff.gz makepasswd_1.10-1.1.dsc to pool/main/m/makepasswd/makepasswd_1.10-1.1.dsc makepasswd_1.10-1.1_all.deb to pool/main/m/makepasswd/makepasswd_1.10-1.1_all.deb 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?'' pgpAN3dzSyY5M.pgp Description: PGP signature
Re: Bits from the RM
On Tue, Aug 19, 2003 at 12:47:44PM -0500, Adam Heath wrote: On Tue, 19 Aug 2003, Anthony Towns wrote: Dateline! [snip] So, where does dpkg 2.0 fit into this? I can commit to a 1 month finish date(from now), for implementing the features we desire for it. If by dpkg 2.0 you mean rewritten dpkg and dpkg-dev, it doesn't. There is no chance that a package management system that hasn't seen the light of day, let alone reached beta test, will be ready for release in four months, let alone one. If by dpkg 2.0 you mean 1.10.11 (ie, minor changes from 1.10.10 only), then I'm not sure why you're asking. 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?'' pgpAtPPbUoFWN.pgp Description: PGP signature
Giant Recreation World Info Request
Thank You for your inquiry regarding one of our Recreational Vehicles. We are Currently processing your information request and will be responding shortly. Thanks Again, Dennis Charron General Manager Giant Recreation World 1-800-654-8475 http://www.grwrv.com [EMAIL PROTECTED]
Re: python 2.2 - python 2.3 transition
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. 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?'' pgpNhNMM7ahSe.pgp Description: PGP signature
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Tue, Aug 19, 2003 at 09:16:03AM +0100, Andrew Suffield wrote: On Mon, Aug 18, 2003 at 10:38:10PM -0600, Joel Baker wrote: If they get hit by a bus, reassigned by their job to Outer Mongolia, or just plain get bored with doing it, we lose that benefit entirely, as things stand today. I'm proposing that the function appears to be producing clear benefits, and that we should, in fact, adjust our expectations so that we retain those benefits in a more direct fashion. No, you are proposing something else entirely: that we require somebody like this to upload the binary-indep components before the packages enter testing. Just like the current system, which requires that uploads be made for all architectures that previously appeared, yes. Funny that. No, in fact, it doesn't. Which is the crux of the question. Argument by repeated assertion. Back at you. Which would imply that the entire issue can be resolved by demonstrating which of the two assertions is, in fact, correct. Are you attempting to suggest that the buildd arrangement uploads broken packages more often than maintainers do? Probably about as frequently. Okay; we're clear on that assertion, then. No, you can't. Or rather, you can swap it, and the wording is equally parseable - but no longer accurate. See above. And again. Which reduces to the same question. Fine. Note that it is much _more_ important for a maintainer workstation (where all the actually important stuff happens) to be working than it is for a buildd (which is largely automated, and thusly can be easily duplicated, replaced, or re-done). Where a failed workstation means someone else can build it, upload it, do an NMU; hell, you could even use the Debian machine farm (unless the workstation is your only access at all, which is quite a different question). Oh hey, just the same as a failed buildd, then. Except that one of these things is easy, and one is not. Agreed, but probably not in the way that you think. I'm going to assert that keeping things sane on a few dozen machines (the buildds) is easier than keeping them sane on 1000+ (assuming each developer has at least one machine to develop on; I have 3, myself). I suspect that's not the assertion you're trying to make, but it comes down, again, to a question of which assertion is *correct*. If you're going to assert that the buildds are breaking packages, please provide some backing to the assertion; showing that maintainers break packages is a trivial excercise in reading the BTS. So is showing that buildds break packages. Although a number of those issues don't go through the BTS. They're probably about as reliable as some random maintainer workstation - which makes sense, why should they be any better? Because they have folks who spend a lot of time trying to ensure that they *are* better, for one; for another, the design of the buildd setup guarantees that, barring a very significant bug, it *will* catch one of the primary forms of maintainer error, which was the origional point - that fewer packages would be broken *because of* going through a buildd than would be caught as broken by going through a buildd. But let us take one concrete example: webmin. Which, as the bug filed and the conversation on the list should indicate, would probably have been caught by the proposed change. Feel free to document at least one case of a situation where a buildd would have caused an otherwise-proper upload to become a bad upload, by replacing the maintainer's binary-indep results with those from the buildd. -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpOLt8j905pR.pgp Description: PGP signature
VIRUS IN YOUR MAIL
V I R U S A L E R T Our viruschecker found the W32/[EMAIL PROTECTED] virus(es) in your email to the following recipient(s): - [EMAIL PROTECTED] Please check your system for viruses, or ask your system administrator to do so. For your reference, here are the headers from your email: - BEGIN HEADERS - Received: from unknown (HELO WKWM030) (194.232.80.246) by host138-212.pool80183.interbusiness.it with SMTP; 20 Aug 2003 06:46:08 - From: debian-devel@lists.debian.org To: [EMAIL PROTECTED] Subject: Thank you! Date: Wed, 20 Aug 2003 8:46:34 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600. X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=_NextPart_000_035BC90C -- END HEADERS --
VIRUS IN YOUR MAIL
V I R U S A L E R T Our viruschecker found the W32/[EMAIL PROTECTED] virus(es) in your email to the following recipient(s): - [EMAIL PROTECTED] Please check your system for viruses, or ask your system administrator to do so. For your reference, here are the headers from your email: - BEGIN HEADERS - Received: from unknown (HELO WKWM030) (194.232.80.246) by host138-212.pool80183.interbusiness.it with SMTP; 20 Aug 2003 06:46:34 - From: debian-devel@lists.debian.org To: [EMAIL PROTECTED] Subject: Re: Thank you! Date: Wed, 20 Aug 2003 8:47:00 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600. X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=_NextPart_000_035C2DB3 -- END HEADERS --
VIRUS IN YOUR MAIL
V I R U S A L E R T Our viruschecker found the W32/[EMAIL PROTECTED] virus(es) in your email to the following recipient(s): - [EMAIL PROTECTED] Please check your system for viruses, or ask your system administrator to do so. For your reference, here are the headers from your email: - BEGIN HEADERS - Received: from unknown (HELO WKWM030) (194.232.80.246) by host130-212.pool80183.interbusiness.it with SMTP; 20 Aug 2003 06:46:38 - From: debian-devel@lists.debian.org To: [EMAIL PROTECTED] Subject: Re: Thank you! Date: Wed, 20 Aug 2003 8:47:04 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600. X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=_NextPart_000_035C3DF9 -- END HEADERS --
VIRUS IN YOUR MAIL
V I R U S A L E R T Our viruschecker found the W32/[EMAIL PROTECTED] virus(es) in your email to the following recipient(s): - [EMAIL PROTECTED] Please check your system for viruses, or ask your system administrator to do so. For your reference, here are the headers from your email: - BEGIN HEADERS - Received: from unknown (HELO WKWM030) (194.232.80.246) by host130-212.pool80183.interbusiness.it with SMTP; 20 Aug 2003 06:47:23 - From: debian-devel@lists.debian.org To: [EMAIL PROTECTED] Subject: Re: Thank you! Date: Wed, 20 Aug 2003 8:47:49 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600. X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=_NextPart_000_035CEE66 -- END HEADERS --
Re: Debian 10th birthday gear
Hi Steve, On Wed, Jul 30, 2003 at 08:02:44AM -0500, Steve Langasek wrote: On Wed, Jul 30, 2003 at 05:40:26PM +1000, Anand Kumria wrote: If you, or anyone else, is interested shipping those overseas could be arranged (with the caveat that glass might break in transit). I need to know by this Friday to get them in time for Aug 16th so if you'd like any of this stuff, let me know. What kind of shipping costs would be tacked on for overseas orders? It would really depend on how many you wanted, The steins are about 0.5kg and the bags about 250g but apparently the minimum shipping cost is AUD$18 (for 20kg) overseas. Which is actually more than the Steins (AUD$12) are, Bags are AUD$30. Photos are available at URL: http://www.progsoc.org/~wildfire/debian/ in the appropriate directory (the .jpg's). There wasn't that much interest so there are only a limited number (50 bags, 72 steins). If you are still interested, let me know. Cheers, Anand -- `` We are shaped by our thoughts, we become what we think. When the mind is pure, joy follows like a shadow that never leaves. '' -- Buddha, The Dhammapada
VIRUS IN YOUR MAIL
V I R U S A L E R T Our viruschecker found the W32/[EMAIL PROTECTED] virus(es) in your email to the following recipient(s): - [EMAIL PROTECTED] Please check your system for viruses, or ask your system administrator to do so. For your reference, here are the headers from your email: - BEGIN HEADERS - Received: from unknown (HELO WKWM030) (194.232.80.246) by host138-212.pool80183.interbusiness.it with SMTP; 20 Aug 2003 06:48:48 - From: debian-devel@lists.debian.org To: [EMAIL PROTECTED] Subject: Re: Re: My details Date: Wed, 20 Aug 2003 8:49:13 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600. X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=_NextPart_000_035E3821 -- END HEADERS --
Re: Debian Weekly News - August 19th, 2003
Quoting Josselin Mouette [EMAIL PROTECTED]: Le mar 19/08/2003 à 23:33, Mike Hommey a écrit : Ok, let's google a bit, and shazaam ! http://www.linex.org/sources/linex/debian/linex/nvidia-glx_1.0.4349-1_i386.deb Oh ! non-free software ! Thanks Richard for keeping me laughing. Bah, if RMS really didn't like non-free software, he would give up with that FDL stuff... No he wouldn't. FDL is about free documentation. :-) -- Jérôme Marant
Re: Debian Weekly News - August 19th, 2003
Great, the debian-legal discussions moved to debian-devel. Quoting Peter S Galbraith [EMAIL PROTECTED]: Now consider that most or all of the FSF documentation for their GPL'ed software is released under the GFDL. The licenses are incompatible so someone who forks a project cannot cut and paste text between the manual and the software that it documents. Why don't they use the GPL for the docs? What do they gain? They gain an invariant section about free software; very ironic isn't it. Pasting a piece of manual in a program doesn't magically turn the documentation into a program; so this is not about mixing too different codes. Just like, inserting a piece of code into a manual doesn't turn the piece of code into documentation where the documentation license applies. See John Goerzen's message Inconsistencies in our approach in debian-legal. -- Jérôme Marant
Re: Bits from the RM
On Tuesday 19 August 2003 08:49, Anthony Towns wrote: I'm all for aggressive goals, let's aim for sometime in December -- how about 2003-12-01 00:00:00 UTC? Do you have some Official Opinion(tm)[1] as the RM about what KDE, gcc, X, gnome versions will be in sarge? greetings -- vbi [1] avoiding the term release goals here -- featured product: SpamAssassin - http://spamassassin.org pgpIKnwS5gr2w.pgp Description: signature
Re: How to locate package uploader?
Colin Watson [EMAIL PROTECTED] wrote: On Tue, Aug 19, 2003 at 07:00:15PM -0600, Jamin W. Collins wrote: Is there any way to find out who uploaded a given package? [...] You need to find the .changes file. If the upload closes any bugs, you can extract it from the BTS, [...] Failing that, people with accounts on auric can get the .changes file from queue/done and use 'gpg --verify' to check the signature. [...] You can also fetch it from the package's Latest News section on packages.qa.d.o cu andreas
Re: non-DD contributors and the debian keyring
Andreas Metzler [EMAIL PROTECTED] writes: Martin Quinson [EMAIL PROTECTED] wrote: I just wondered if it would be possible for non-developper contributors to Debian to get their GPG key in the Debian keyserver. [...] This trust relationship would be eased if I could sign my mails and contribution with an easily available key. I mean, I do have a key signed by some DD, but since my key is not easily available, that's not easy for the DD I collaborate with. [...] No need to get Debian involved. Upload your key to the normal keyservers [1] and it *is* easily available. cu andreas You can also apply as a NM for translation work. You don't need to maintaine a package or know much about the packaging system for that. You get different taskskill tests. MfG Goswin
Re: future Date: field for Packages files
Dan Jacobson [EMAIL PROTECTED] writes: Regarding a future Date: field for each package in Packages files, * Should the field be called Date: or Time:? * Should it be like Mon, 18 Aug 2003 22:09:30 GMT or 1061315862? * Should it refer to the time the developer finished wrapping the package, or the time it entered the distribution? Those questions are for you implementers to decide. I merely look forward the day when one can tell apt-show-versions --upgradeable, or grep-available, that one is only interested in versions that have been around for more (or less) than X days. It shouldn't be changed after its signed, or will this not be included in the deb too? MfG Goswin
Re: non-DD contributors and the debian keyring
* Goswin von Brederlow [EMAIL PROTECTED] [2003-08-20 10:31]: Martin Quinson [EMAIL PROTECTED] wrote: I just wondered if it would be possible for non-developper contributors to Debian to get their GPG key in the Debian keyserver. You can also apply as a NM for translation work. You don't need to maintaine a package or know much about the packaging system for that. You get different taskskill tests. V I P Martin Quinson [EMAIL PROTECTED] -- Martin Michlmayr [EMAIL PROTECTED]
Re: Bits from the RM
On Wed, Aug 20, 2003 at 09:49:03AM +0200, Adrian von Bidder wrote: Content-Description: signed data On Tuesday 19 August 2003 08:49, Anthony Towns wrote: I'm all for aggressive goals, let's aim for sometime in December -- how about 2003-12-01 00:00:00 UTC? Do you have some Official Opinion(tm)[1] as the RM about what KDE, gcc, X, gnome versions will be in sarge? An educated guess would produce: GCC 3.3.1 Gnome 2.2 (2.4 will probably be out before freeze but whether it goes in is up to them...) [0] KDE 3.1.4 (KDE 2.2 _will not_ stay in sarge!) XFree 4.3.0 (Branden wants this to happen...) Chris Cheney [0] http://www.gnome.org/start/2.3/
Re: Debian Installation Goals (was: Happy Birthday)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2003-08-19 21:14, Goswin von Brederlow wrote: cobaco [EMAIL PROTECTED] writes: On 2003-08-17 09:02, Goswin von Brederlow wrote: As bad as it might be I would like to have a menu tree containing all packages that can be configured and when you select one item a menu would pop up with its configuration options. Package: configure-debian When is that used? At what stage? post-installation I'm talking about the selection of udebs and I certainly had no submenus with any images I managed to build. err, we were talking about package configuration, not package selection right? Let me guess. You first have to install the configure-debian.udeb? .oO( Which no newbie would ever find ) true, you do need to install the package to use it, and yes the existence op this package could(should?) be made clearer - -- Cheers, cobaco /\ ASCII Ribbon Campaign \ / No proprietary formats in attachments without request X i.e. *NO* WORD, POWERPOINT or EXCEL documents / \ Respect Open Standards http://www.fsf.org/philosophy/no-word-attachments.html http://www.goldmark.org/netrants/no-word/attach.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Qzk+5ihPJ4ZiSrsRArk2AJ95TerJvgHWYSWPQWYzBwJ3grleeQCgibaF fIBa8u6mxIlj4cJDgVkFpoc= =HDxX -END PGP SIGNATURE-
Re: Bits from the RM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2003-08-20 10:13, Chris Cheney wrote: On Wed, Aug 20, 2003 at 09:49:03AM +0200, Adrian von Bidder wrote: On Tuesday 19 August 2003 08:49, Anthony Towns wrote: I'm all for aggressive goals, let's aim for sometime in December -- how about 2003-12-01 00:00:00 UTC? Do you have some Official Opinion(tm)[1] as the RM about what KDE, gcc, X, gnome versions will be in sarge? KDE 3.1.4 (KDE 2.2 _will not_ stay in sarge!) kde 3.2 release is slated for 8th december[1], is there any chance we'll wait for it, just so the outdated kde label doesn't apply again immediately after release? [1] http://developer.kde.org/development-versions/kde-3.2-release-plan.html - -- Cheers, cobaco /\ ASCII Ribbon Campaign \ / No proprietary formats in attachments without request X i.e. *NO* WORD, POWERPOINT or EXCEL documents / \ Respect Open Standards http://www.fsf.org/philosophy/no-word-attachments.html http://www.goldmark.org/netrants/no-word/attach.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/QzqP5ihPJ4ZiSrsRAnebAJ9zijYLaXNXKFdZFKgCfGdqINnVeACfceHe sQC4GkY64v7uhA/rERL7PA4= =Leye -END PGP SIGNATURE-
Re: non-DD contributors and the debian keyring
On Wed, Aug 20, 2003 at 06:46:34PM +1000, Martin Michlmayr wrote: * Goswin von Brederlow [EMAIL PROTECTED] [2003-08-20 10:31]: Martin Quinson [EMAIL PROTECTED] wrote: I just wondered if it would be possible for non-developper contributors to Debian to get their GPG key in the Debian keyserver. You can also apply as a NM for translation work. You don't need to maintaine a package or know much about the packaging system for that. You get different taskskill tests. V I P Martin Quinson [EMAIL PROTECTED] Exact. I *did* apply. I'm even pretty well advanced in the process. $ LC_ALL=C gpg --keyserver keyring.debian.org --recv-keys E145F334 gpg: no valid OpenPGP data found. gpg: Total number processed: 0 This is the ID of my key, available from www.keyserver.net and signed by 2 DD. Did I mess something up ? Shouldn't Debian make sure that work submition from non-DD contributor are signed, just like it does for the work submition from DD ? Bye, Mt. -- Dans un pays d'extrême droite, On y parle beaucoup de Dieu, parce que ça fait longtemps, qu'il a quitté les lieux. -- Frères misère
Re: Bits from the RM
cobaco == cobaco [EMAIL PROTECTED] writes: cobaco kde 3.2 release is slated for 8th december[1], is there any cobaco chance we'll wait for it, just so the outdated kde label doesn't cobaco apply again immediately after release? But does the first few paragraphs of RM's original message exactly trying to convey the message that if it is not considered stable for long enough, don't make it into stable? If so, something to be released during the original target release date doesn't seem to stand even slight chance! Regards, Isaac.
Re: Bits from the RM
Am 20.08.03 um 11:08:28 schrieb cobaco: kde 3.2 release is slated for 8th december[1], is there any chance we'll wait for it, just so the outdated kde label doesn't apply again immediately after release? It's not KDE 4, so it doesn't really matter that much. And it probably won't be GNOME 2.4 either, so both desktops will be in there with their stable versions. Bye, Mike -- |=| Michael Piefel |=| Humboldt-Universität zu Berlin |=| Tel. (+49 30) 2093 3831
Re: Bits from the RM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2003-08-20 11:47, Isaac To wrote: cobaco == cobaco [EMAIL PROTECTED] writes: cobaco kde 3.2 release is slated for 8th december[1], is there any cobaco chance we'll wait for it, just so the outdated kde label doesn't cobaco apply again immediately after release? But does the first few paragraphs of RM's original message exactly trying to convey the message that if it is not considered stable for long enough, don't make it into stable? If so, something to be released during the original target release date doesn't seem to stand even slight chance! quoteBasically, it's the difference between having a sysadmin spending fifteen minutes every day or week tweaking your server to keep it running, or having a sysadmin come in for a week once a year to do a major upgrade./quote Note that the RM was talking about servers there, while kde is end-user software, big difference IMHO. Taking into account that kde isn't server-software and that kde won't do release if there are major bugs left I don't think stability should be a problem in this case. Anyhow, just think it would be nice to avoid all the reviews going kde not up to date for a change. - -- Cheers, cobaco /\ ASCII Ribbon Campaign \ / No proprietary formats in attachments without request X i.e. *NO* WORD, POWERPOINT or EXCEL documents / \ Respect Open Standards http://www.fsf.org/philosophy/no-word-attachments.html http://www.goldmark.org/netrants/no-word/attach.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q0lL5ihPJ4ZiSrsRAlPkAJ9rX5SIwtYaGORH6fBDc76CbqyD5QCgixHn NmN1H3kSNWFFz7L2EPYWblc= =QMK6 -END PGP SIGNATURE-
Norton AntiVirus detected and quarantined a virus in a message yo u sent.
Recipient of the infected attachment: Bradley, Leisa\Inbox Subject of the message: Re: Wicked screensaver One or more attachments were quarantined. Attachment movie0045.pif was Quarantined for the following reasons: Virus [EMAIL PROTECTED] was found. application/ms-tnef
Re: Bits from the RM
cobaco == cobaco [EMAIL PROTECTED] writes: cobaco quoteBasically, it's the difference between having a sysadmin cobaco spending fifteen minutes every day or week tweaking your server cobaco to keep it running, or having a sysadmin come in for a week once cobaco a year to do a major upgrade./quote cobaco Note that the RM was talking about servers there, while kde is cobaco end-user software, big difference IMHO. Taking into account that cobaco kde isn't server-software and that kde won't do release if there cobaco are major bugs left I don't think stability should be a problem cobaco in this case. Why KDE cannot be used on servers (how about a X terminal server? You don't have to set it up?), and why on stable you do not expect a stable KDE? What I perceived: if you want an updated KDE, go run testing or unstable. If many people like a really updated KDE, one of them should act up and package a CVS version in experimental. I really don't see the point to let in really new packages that we don't know whether other packages are broken by it. And I don't mind Debian stable being marked as always having an outdated KDE. It is supposed to work that way. Regards, Isaac.
Re: Bits from the RM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2003-08-20 12:10, Michael Piefel wrote: Am 20.08.03 um 11:08:28 schrieb cobaco: kde 3.2 release is slated for 8th december[1], is there any chance we'll wait for it, just so the outdated kde label doesn't apply again immediately after release? It's not KDE 4, so it doesn't really matter that much. there's no big architectural changes but there's considerable improvement, looking at the feature_plan I see: + merging of kroupware_branch, and inclusion of kontact + kdevelop 3.0., and umbrello, + new vim kpart, standalone kregexeditor + new apps kbrug, kig, kgpg, Juk Not stated explictly, so not sure, but I think the the remaining safari-patches to html will also be applied for 3.2 And it probably won't be GNOME 2.4 either so both desktops will be in there with their stable versions. actually that's just it, if we release on 1st december and KDE releases on 8th december, then 7 days after release we no longer have the stable KDE release in stable, which is a rather unfortunate timing, no? - -- Cheers, cobaco /\ ASCII Ribbon Campaign \ / No proprietary formats in attachments without request X i.e. *NO* WORD, POWERPOINT or EXCEL documents / \ Respect Open Standards http://www.fsf.org/philosophy/no-word-attachments.html http://www.goldmark.org/netrants/no-word/attach.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q0/D5ihPJ4ZiSrsRAtbpAJ4nsXOFCuoNu0vkLo9EBB4AM+ucJACfR6de VsOZiTWQ6syfmngdipjMExM= =9MwH -END PGP SIGNATURE-
Re: Bits from the RM
On Wed, Aug 20, 2003 at 12:10:18PM +0200, Michael Piefel wrote: | Am 20.08.03 um 11:08:28 schrieb cobaco: | kde 3.2 release is slated for 8th december[1], is there any chance we'll wait | for it, just so the outdated kde label doesn't apply again immediately after | release? | | It's not KDE 4, so it doesn't really matter that much. There were pretty major changes between KDE 3 and KDE 3.1. As a Debian user, I'd be rather miffed if a new version of KDE came out within a week of sarge being released ... on the other hand, if sarge is to be frozen in a couple of months' time, it seems unlikely that KDE 3.2 will be able to make it in. *grumble* :( Cameron.
Re: Locales in init scripts (about gdm bug #147091)
On Mon, Aug 18, 2003 at 12:19:03PM -0300, Daniel Ruoso wrote: Hi. (...) So, how to make the init scripts localized? What do you think? /etc/default/language? I believe this has been discussed previously, see for example [1] and debian-boot [2]. From briefly looking at redhat's redhat-config-language program (a GUI to setup precisely this) it seem they use /etc/sysconfig/i18n for this (is there also an /etc/sysconfig/language?) which gets sourced from scripts (lang.sh, lang.csh) in /etc/profile.d to setup the user's environment and by /etc/rc.d/init.d/functions which is incorporated by init.d programs. IMHO to get init scripts localized a similar (and policy mandated) set of functions (including i18n/l10n) should be implemented. Locale configuration (or boot-floopies/d-i for that matter) should then modify those on admin's request. Regards Javi [1] www.debian.org/News/weekly/1999/27/mail [2] lists.debian.org/debian-boot/2001/debian-boot-200105/msg00667.html - pgp5wuUv1dNSV.pgp Description: PGP signature
Re: Bits from the RM
On Wed, Aug 20, 2003 at 11:08:28AM +0200, cobaco wrote: On 2003-08-20 10:13, Chris Cheney wrote: On Wed, Aug 20, 2003 at 09:49:03AM +0200, Adrian von Bidder wrote: On Tuesday 19 August 2003 08:49, Anthony Towns wrote: I'm all for aggressive goals, let's aim for sometime in December -- how about 2003-12-01 00:00:00 UTC? Do you have some Official Opinion(tm)[1] as the RM about what KDE, gcc, X, gnome versions will be in sarge? KDE 3.1.4 (KDE 2.2 _will not_ stay in sarge!) kde 3.2 release is slated for 8th december[1], is there any chance we'll wait for it, just so the outdated kde label doesn't apply again immediately after release? There's a big difference between being out of date by a major version and by a minor version. We're never going to manage to release just after high-profile releases of all our major components, so let's not delay for this one unless we have to. -- Colin Watson [EMAIL PROTECTED]
Re: [Javier Fernandez-Sanguino Pen~a jfs@computer.org] Accepted makepasswd 1.10-1.1 (all source)
On Wed, Aug 20, 2003 at 03:16:06PM +1000, Anthony Towns wrote: I had been hoping that I wouldn't have to resort to adding a stick to the various carrots, but evidently we have developers who aren't taking care to measure twice before cutting once. The 0-day NMU period has *not* started, and will not start until the 23rd. People who abuse this privlege by not applying a due amount of care to their NMUs will have their NMU privileges revoked in their entirety until the 0-day NMU period ends on 2003-09-15. [...] From: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] Subject: Accepted makepasswd 1.10-1.1 (all source) Date: Tue, 19 Aug 2003 21:32:06 -0400 To: debian-devel-changes@lists.debian.org Sender: Archive Administrator [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Format: 1.7 Date: Wed, 20 Aug 2003 02:40:37 +0200 Source: makepasswd Binary: makepasswd Architecture: source all Version: 1.10-1.1 Distribution: unstable Urgency: low Maintainer: Johnie Ingram [EMAIL PROTECTED] Changed-By: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] Description: makepasswd - Generate and encrypt passwords Closes: 44788 50885 147808 168492 190485 Changes: makepasswd (1.10-1.1) unstable; urgency=low . * Non-maintainer upload. Since the rules have changed and this package has not (since potato) I'm uploading to 0-delay. This upload will not fix any RC bugs but at least will (almost) remove all the bugs open for this package, and it didn't take me much time to figure these out... In addition, you should probably check the WNPP before uploading apparently unmaintained packages. In this case, you would have found that (a) makepasswd has been orphaned, so all this NMU verbiage was unnecessary, and (b) I'd filed an ITA, and a mail to me would probably have kicked me into action enough to finish adopting it, since I'd fixed all these bugs locally already. (I'd been a bit slow to get round to uploading this, granted; sorry about that.) Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Bits from the RM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2003-08-20 12:36, Isaac To wrote: cobaco == cobaco [EMAIL PROTECTED] writes: Why KDE cannot be used on servers (how about a X terminal server? You don't have to set it up?) not what I meant: off course it can be used on a server, so can the gimp, this doesn't make the gimp server software does it? All I'm saying is that KDE, when installed on a server is not a mission-critical piece of software. Besides major bugs would've been filtered out by the kde release proces, and minor bugs would not interfere with functioning of a server. and why on stable you do not expect a stable KDE? kde 3.2. will be the stable kde release come 8 december What I perceived: if you want an updated KDE, go run testing or unstable. If many people like a really updated KDE, one of them should act up and package a CVS version in experimental. unless I'm completely mistaken the kde packagers commit there directly in kde cvs. I really don't see the point to let in really new packages that we don't know whether other packages are broken by it. last couple of kde releases there have been deb packages available for testing with the kde release candidates, which were used rather extensively, assuming this continues for kde 3.2 these packages would be tested And I don't mind Debian stable being marked as always having an outdated KDE. It is supposed to work that way. While I agree it wouldn't be the end of the world, and it has certainly been that way sofar, I most definately do _NOT_ agree that it is supposed to work that way. Stable having outdated software is an (undesired) side-effect from keeping the stable release stable. If we can have up-to-date software that is also reasonably stable (again this is end-user software, not server-software) this is better no? - -- Cheers, cobaco /\ ASCII Ribbon Campaign \ / No proprietary formats in attachments without request X i.e. *NO* WORD, POWERPOINT or EXCEL documents / \ Respect Open Standards http://www.fsf.org/philosophy/no-word-attachments.html h http://www.goldmark.org/netrants/no-word/attach.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q1rc5ihPJ4ZiSrsRAiRzAKCGaPLuFHiE7LddNSm7CB4OCI/8zQCeLVJK 82GN0gDu+/RuDyQZPaxuM6Q= =ZACu -END PGP SIGNATURE-
#206298 spip: prerm script blindly removes directories
Package: spip Version: 1.6.0-2 Severity: normal The prerm script blindly deletes the following directories and all subdirectories: /var/cache/spip /usr/share/spip/ecrire/upload /usr/share/spip/ecrire/data There is no guarantee that the files in these directories belong only to this package. While it is quite likely that they will, it can not be guaranteed and care should be taken on package removal to not remove any files that are not owned solely by the package. All right. I understand the problem. But the directories removed by the postrm/purge are normaly only used : - by user, to upload datas related to his spip installation, - by spip himself, to store cache informations, - by spip himself, for log or backups. So, I cannot have any informations on who and why there are files in tese directories. I just cannot imagine why people wuold store files not related to spip here. (notice that i only delete these files on a purge operation). -- Pianiste condamné à trois mois de prison, cherche musicien pour l'accompagner au violon. Gaétan RYCKEBOER Société Virtual-Net [Tous textes et propos tenus dans ce couriel sont sous license DMDZZ] pgpCro5bWa7CW.pgp Description: PGP signature
Re: Bits from the RM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2003-08-20 12:43, Colin Watson wrote: There's a big difference between being out of date by a major version and by a minor version. agreed, though IMHO kde 3.1.2 - 3.1.3 is a minor version upgrade and 3.1 - 3.2 is a major version upgrade We're never going to manage to release just after high-profile releases of all our major components, so let's not delay for this one unless we have to. true enough, still releasing a week before a high-profile release of KDE is rather unfortunate I think. - -- Cheers, cobaco /\ ASCII Ribbon Campaign \ / No proprietary formats in attachments without request X i.e. *NO* WORD, POWERPOINT or EXCEL documents / \ Respect Open Standards http://www.fsf.org/philosophy/no-word-attachments.html http://www.goldmark.org/netrants/no-word/attach.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q15K5ihPJ4ZiSrsRAuLHAJ9Th6EGqjDrn4PDiPeTqv3xc6pShQCdEJVw sr+5p1W6IDaE9RrCe3huC8c= =C40N -END PGP SIGNATURE-
KDE 3.1.3 from unstable...
I realise that running unstable I'm kind of sailing close to the wind, and don't want to put anyones back up, but kpackage really seems to be somewhat challenged when trying to install the latest KDE updates that are in unstable... Perhaps unstable should extend to 'it may beinstallable or not' as well as the stability of the software (Although I don't find many really big problems in it usually). However... trying to install the latest kde updates (3.1.3-1 while I currently have 3.1.2-1 installed), Which I really want, because I'd like konqueror to be usable... It's OK. but still has far too many pages it won't render... Better than stable though)... And the latest is it can't install because libvorbis0 isn't apparently there... Argh! What's the use of having a packaging system if we're getting into the RPM hell that I left redhat for... Anyone know where I can get an apt blessed version of libvorbis0? Or am I just missing a package URL in apt? TIA Hamish. -- I don't suffer from Insanity... | Linux User #16396 I enjoy every minute of it... | | http://www.travellingkiwi.com/ |
RE: Your application
I am currently out of the office. Please visit our web site: www.patchworkbydesign.com WHOLESALE PRICE LIST: Accessories: Crib Sheet: $19.00 Toile Crib Sheet:$34.00 3pc Sheet Set: $29.95 Diaper Stacker: $49.00 Valance: $25.00 Toile Valance: $40.00 Crib Skirt: $65.00 Bumpers: $65.00 Toile Crib Skirt:$80.00 Toile Crib Bumper: $80.00 54 Curtain $35.00 54 Toile Panel: $50.00 84 Curtain Panel$50.00 84 Toile Curtain Panel: $65.00 Lamp:$45.00 Lamp Shade: $20.00 Throw Pillow $20.00 Diaper Bag Set: $65.00 Chenille/Toile Bib: $15.00 Changing Pad Cover: $32.00 Wall Hanging:$40.00 Embroidered Hang Pillow: $17.00 Quilts/Sets Car Seat Blanket:$45.00 Crib Quilt: $75.00 Toddler Quilt: $80.00 Toddler Bed Set: $125.00 Moses Basket Set:$180.00 2pc Crib Set:$160.00 3pc Crib Set:$210.00 4pc Crib Set:$249.95 7pc Grow w/me Set: $300.00 Posh Upgrades Overstuffed Bumpers: $35.00 Chenille on Bumpers: $25.00 Ruffle on Bumpers: $17.00 Gathered Skirt: $37.00 Extra Long Skirt:$25.00
Re: Bits from the RM
On Wed, 20 Aug 2003, Anthony Towns wrote: If by dpkg 2.0 you mean rewritten dpkg and dpkg-dev, it doesn't. There is no chance that a package management system that hasn't seen the light of day, let alone reached beta test, will be ready for release in four months, let alone one. Just dpkg-deb, and dpkg-source. No other major changes are planned. The complex code in dpkg/dselect will just be interfaced to the new libary code. However, as I've been thinking, I'd rather take more time, and get more features in, then rush to have it completed in one month. If by dpkg 2.0 you mean 1.10.11 (ie, minor changes from 1.10.10 only), then I'm not sure why you're asking. So, I guess I'm looking for people who'd like to work on dpkg 1.10, and fix the important bugs it has.
Re: Bits from the RM
On Wed, 20 Aug 2003 20:48, Cameron Patrick wrote: There were pretty major changes between KDE 3 and KDE 3.1. As a Debian Anyone who wants to can establish their own repository for back-ported KDE packages. KDE has a good history of having people do that, at times there have been 3 or more back-port repositories of KDE. Just because something isn't in the main Debian distribution doesn't mean you can't use it! As long as a reasonably recent version of KDE is in stable you won't have any big problems as all the dependencies will be installed. user, I'd be rather miffed if a new version of KDE came out within a week of sarge being released ... on the other hand, if sarge is to be frozen in a couple of months' time, it seems unlikely that KDE 3.2 will be able to make it in. *grumble* :( Are there any big features you expect from KDE 3.2? If given a choice between a KDE release that's stable, solid, and reliable and a bleeding edge release that gives SEGV's on critical programs such as Konsole and has font problems I would choose the stable release every time. KDE 1.x was quite usable, while many of the beta releases in the 2.x and early 3.x series weren't... -- 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: KDE 3.1.3 from unstable...
On Wed, Aug 20, 2003 at 12:48:28PM +0100, Hamish Marson wrote: Anyone know where I can get an apt blessed version of libvorbis0? Or am I just missing a package URL in apt? As far as Sid is concerned I believe it's already libvorbis0a. There is no more libvorbis0 there. Perhaps the KDE packages that depend on libvorbis0 just need updating so they depend on libvorbis0a instead? -- Jijo -- Federico Sevilla III : http://jijo.free.net.ph : When we speak of free Network Administrator : The Leather Collection, Inc. : software we refer to GnuPG Key ID : 0x93B746BE : freedom, not price.
Re: Bits from the RM
On Wed, Aug 20, 2003 at 01:40:53PM +0200, cobaco wrote: We're never going to manage to release just after high-profile releases of all our major components, so let's not delay for this one unless we have to. true enough, still releasing a week before a high-profile release of KDE is rather unfortunate I think. Release one week before will not be a real target [1]. data [1] read: if we delay the release for one week to include kde3.2, we have to make sure the packages work, the upgrade path is not breaking anything,... which will mean delaying the release at least 3 weeks more. By that time a new major release of Harsecorp (TM) 9.x will be out... Solution: use backports, use Sid, form a team to release a stable debian version more often, say in 6 more months. data -- Jesus Climent | Unix SysAdm | Helsinki, Finland | pumuki.hispalinux.es GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 -- Registered Linux user #66350 proudly using Debian Sid Linux 2.4.21 - ... todos necesitamos creer en algo. - Si, yo también creo... Creo... que me voy a tomar una cerveza. --Sor Trini (Año Mariano)
Re: Bits from the RM
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. -- - mdz
Re: Bits from the RM
On Wed, Aug 20, 2003 at 01:26:17PM +0200, cobaco wrote: and why on stable you do not expect a stable KDE? kde 3.2. will be the stable kde release come 8 december The reality is that if KDE 3.2 is stable in KDE, and it entered testing on December 8th, it would probably delay the release of sarge by at least 6 weeks just so we can make sure the Debian build of KDE 3.2 was bug-free. And then in the meantime, no doubt some other significant package (GNOME, perhaps?) would become stable, and people would agitate for us to hold up the release for another 6 weeks, OR developers would take the opportunity to destablize the release further because they see the vast major, gaping exception to the freeze schedule set forth by the RM. AND this all assumes that KDE actually hits their release schedulate! Bad ju-ju. The real problem is that stable has a reputation of taking years and years before we manage to do a release, so people are always desperate to shove every last bit of functionality and new upstream release into it. What folks don't realize is that makes the problem worse, not better, by stretching out the release schedule. Better to have a hard freeze schedule, and then try to turn out new stable releases every 6-9 months. Then folks won't be so desperate to shove new things in and screw up the release. The problem, though, is the first such attempt take release schedules seriously and agressively (a) a really hardass RM, and (b) a certain amount of faith by the developers that we really can get our act together about short, regular, predictable releases. - Ted
Re: Bug#205471: [rene@debian.org: Bug#205471: devscripts: running debuild could lead to deleting _all_ backup dirs/files on the system]
On Tue, Aug 19, 2003 at 09:24:25PM +0200, Goswin von Brederlow wrote: [EMAIL PROTECTED] (Aaron M. Ucko) writes: How about requiring the debian directory to have an appropriately named parent (as determined by debian/changelog and debian/control, which should probably also have to agree...), unless the user runs debuild with some sort of --force option? But then its a question of what name to use? I do have the following four cases: package package-version package-version.debian_version package-cvs I really like this idea, thank you! I will accept directory names matching the regexp /^$package(-.*)?$/ - does that seem reasonable? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Bits from the RM
On Wed, Aug 20, 2003 at 12:38:57PM +0200, cobaco wrote: On 2003-08-20 12:10, Michael Piefel wrote: Am 20.08.03 um 11:08:28 schrieb cobaco: kde 3.2 release is slated for 8th december[1], is there any chance we'll wait for it, just so the outdated kde label doesn't apply again immediately after release? actually that's just it, if we release on 1st december and KDE releases on 8th december, then 7 days after release we no longer have the stable KDE release in stable, which is a rather unfortunate timing, no? No. This is the way stable releases work. You can't have the latest and greatest version of the software in the distribution the day it releases and expect the whole thing to actually be stable, and you shouldn't ask the RM to delay the release on account of an impending upstream release of one piece of software. There's *always* new software being released in the community, and KDE is probably very low on the priority list *of those who use stable*. KDE3.2 doesn't miss the deadline by 7 days, it misses the deadline by almost two months: * October 15th Final, last-minute, low-risk bug fixes only If we manage to release Sarge and it contains the current upstream KDE packages for a whole seven days, THAT is a noteworthy improvement all its own. -- Steve Langasek postmodern programmer pgpngD3xvmkzg.pgp Description: PGP signature
Re: Bits from the RM
On Wed, Aug 20, 2003 at 12:11:20PM +0200, cobaco wrote: Note that the RM was talking about servers there, while kde is end-user software, big difference IMHO. Taking into account that kde isn't server-software and that kde won't do release if there are major bugs left I don't think stability should be a problem in this case. That is both delusional and flat-out wrong. While I have been a happy KDE user for some time, I'll be the first to tell you that it has problems. For instance, Konqueror is almost completely unusable on Alpha because it frequently dies with SIGFPE and draws little black boxes instead of text on a number of webpages. That is not a bash against KDE; they probably do not have a large number of Alpha testers. Also, I find your argument that breaking desktops is somehow better than breaking servers to be rather naive. While the effects of breaking servers can likely be felt farther, tne pain of breaking desktops is no less when you consider how many more desktops we're talking about here. -- John
Bug#206387: ITP: DeFX -- Multi-effects processor plug-in for XMMS
Package: wnpp Version: unavailable; reported 2003-08-18 Severity: wishlist * Package name: DeFX Version : 0.1.0 Upstream Author : Franco Catrin [EMAIL PROTECTED] * URL : http://defx.sourceforge.net/ * License : (GPL.) Description : Multi-effects processor plug-in for XMMS DeFX is a plug-in module for XMMS. This is an audio player that supports many audio/multimedia formats (MP3, XM, S3M, IT, MIDI, MPG, AVI...) for the Linux plataform. DeFX belongs to the Effect Plugins. You can alter the sound that XMMS have processed, before it will be sent to your sound card. It has 4 different modules. - Karaoke: Removes the song's voices trying to preserve the bass and drums. - Panning: Smoothly selects between the two stereo channels. - Modulation: Three classical effects. Flange, phaser and chorus - Reverberation: You can simulate your songs as being player in a huge room. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux pegasus 2.4.20 #1 Sun Jun 8 17:33:19 CLT 2003 i686 Locale: LANG=C, LC_CTYPE=C
Re: KDE 3.1.3 from unstable...
On Wed, Aug 20, 2003 at 12:48:28PM +0100, Hamish Marson wrote: I realise that running unstable I'm kind of sailing close to the wind, and don't want to put anyones back up, but kpackage really seems to be somewhat challenged when trying to install the latest KDE updates that are in unstable... Perhaps unstable should extend to 'it may beinstallable or not' as well as the stability of the software (Although I don't find many really big problems in it usually). It already does extend to that: dependency problems are exactly the problem with unstable a lot of the time. Testing filters most of those problems out. However... trying to install the latest kde updates (3.1.3-1 while I currently have 3.1.2-1 installed), Which I really want, because I'd like konqueror to be usable... It's OK. but still has far too many pages it won't render... Better than stable though)... And the latest is it can't install because libvorbis0 isn't apparently there... Argh! What's the use of having a packaging system if we're getting into the RPM hell that I left redhat for... Anyone know where I can get an apt blessed version of libvorbis0? Or am I just missing a package URL in apt? I don't know the details here, but libvorbis0 is now libvorbis0a. I'd suggest that you start by tracking down what still depends on libvorbis0: as far as I can see the only culprit in unstable is libsnack2, which doesn't seem related to KDE. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#206393: ITP: DeFX -- Multi-effects processor plug-in for XMMS
Package: wnpp Version: unavailable; reported 2003-08-20 Severity: wishlist * Package name: DeFX Version : 0.1.0 Upstream Author : Franco Catrin [EMAIL PROTECTED] * URL : http://defx.sourceforge.net * License : (GPL.) Description : Multi-effects processor plug-in for XMMS DeFX is a plug-in module for XMMS. This is an audio player that supports many audio/multimedia formats (MP3, XM, S3M, IT, MIDI, MPG, AVI...) for the Linux plataform. DeFX belongs to the Effect Plugins. You can alter the sound that XMMS have processed, before it will be sent to the sound card. It has 4 different modules. - Karaoke: Removes the song's voices trying to preserve the bass and drums. - Panning: Smoothly selects between the two stereo channels. - Modulation: Three classical effects. Flange, phaser and chorus. - Reverberation: You can simulate your songs as being played in a huge room. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux pegasus 2.4.20 #3 Mon Aug 18 17:25:50 CLT 2003 i686 Locale: LANG=C, LC_CTYPE=C
Re: Bits from the RM
On Wed, 20 Aug 2003, 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. Will we some day consider seriously the idea of autobuilders compiling against testing those packages which do not need libraries from unstable to be built?
Re: Bits from the RM
On Wed, Aug 20, 2003 at 12:11:20PM +0200, cobaco wrote: quoteBasically, it's the difference between having a sysadmin spending fifteen minutes every day or week tweaking your server to keep it running, or having a sysadmin come in for a week once a year to do a major upgrade./quote Note that the RM was talking about servers there, [...] I'm sorry, that was a thinko. It should've read machine or system or similar. And the conclusions apply even moreso to desktop boxes than to servers, because there tend to be so many more of them, and because most of the time, sysadmins are geared towards managing servers rather than desktops, making changes to the latter harder, and less smooth. YMMV on the details, of course, but there wasn't intended to be any differentiation between servers and desktops in my mail. 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?'' pgputibltegHl.pgp Description: PGP signature
Re: KDE 3.1.3 from unstable...
Le mer 20/08/2003 à 13:48, Hamish Marson a écrit : Perhaps unstable should extend to 'it may beinstallable or not' as well as the stability of the software (Although I don't find many really big problems in it usually). That's exactly what unstable is meant to be. However... trying to install the latest kde updates (3.1.3-1 while I currently have 3.1.2-1 installed), Which I really want, because I'd like konqueror to be usable... It's OK. but still has far too many pages it won't render... Better than stable though)... And the latest is it can't install because libvorbis0 isn't apparently there... Argh! What's the use of having a packaging system if we're getting into the RPM hell that I left redhat for... Only one package still depends of libvorbis0 in unstable, and it has nothing to do with KDE. You are obviously installing from unofficial, buggy sources. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
.
! , ! , , 2, 2, . , , -: 2 8 - 14 2003 2 22 - 28 2003 , , . : () ( / ) / () 2/2 . , , , . , ,: (095) 258-51-85 , .
Re: Bits from the RM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2003-08-20 15:33, John Goerzen wrote: On Wed, Aug 20, 2003 at 12:11:20PM +0200, cobaco wrote: Note that the RM was talking about servers there, while kde is end-user software, big difference IMHO. Taking into account that kde isn't server-software and that kde won't do release if there are major bugs left I don't think stability should be a problem in this case. That is both delusional and flat-out wrong. While I have been a happy KDE user for some time, I'll be the first to tell you that it has problems. For instance, Konqueror is almost completely unusable on Alpha because it frequently dies with SIGFPE and draws little black boxes instead of text on a number of webpages. ok, so kde releases are not necessarely stable on the more exotic debian-supported architectures. But exactly how is staying with an older kde release going to help that? 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. Also, I find your argument that breaking desktops is somehow better than breaking servers to be rather naive. not better, breaking things is never good, but less serious: a crash of a server affects all users of that server, a crash of a desktop affects the one user using that desktop at that time. What's more when a server crashes the users affected are dependend on the server admin to fix things, while on a desktop they can take action themselves (like say restart whatever app that crashed). While the effects of breaking servers can likely be felt farther agreed 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? Out of curiosity (not relevant to the discussion) is it just individual apps like konquer that are buggy on alpha or is it also the kde-enviroment? - -- Cheers, cobaco /\ ASCII Ribbon Campaign \ / No proprietary formats in attachments without request X i.e. *NO* WORD, POWERPOINT or EXCEL documents / \ Respect Open Standards http://www.fsf.org/philosophy/no-word-attachments.html http://www.goldmark.org/netrants/no-word/attach.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q4BM5ihPJ4ZiSrsRAnxbAKCMYfBf4vhLnYJf+1erqtkiLK78DwCeOReu cXYTU8AYHxEEIWJuH2iyDYo= =dJ4V -END PGP SIGNATURE-
Re: #206298 spip: prerm script blindly removes directories
On Wed, Aug 20, 2003, Gaetan Ryckeboer wrote: /var/cache/spip /usr/share/spip/ecrire/upload /usr/share/spip/ecrire/data All right. I understand the problem. But the directories removed by the postrm/purge are normaly only used : - by user, to upload datas related to his spip installation, - by spip himself, to store cache informations, - by spip himself, for log or backups. Please use directories in /var for all this. /usr should only contain sharable, read-only data. As for the removal of whole directories, even in /var, see the various arguments in the previous debian-devel discussion about dosemu. Cheers, -- Sam.
Re: KDE 3.1.3 from unstable...
On Wed, Aug 20, 2003 at 08:25:01PM +0800, Federico Sevilla III wrote: On Wed, Aug 20, 2003 at 12:48:28PM +0100, Hamish Marson wrote: Anyone know where I can get an apt blessed version of libvorbis0? Or am I just missing a package URL in apt? As far as Sid is concerned I believe it's already libvorbis0a. There is no more libvorbis0 there. Perhaps the KDE packages that depend on libvorbis0 just need updating so they depend on libvorbis0a instead? As far as sid is concerned, KDE is, in fact, installable, and in fact depends on libvorbis0a. He's probably using a backport of some sort which is not installable on unstable. -- - mdz
Re: Debian 10th birthday gear
On Wed, Aug 20, 2003 at 04:48:15PM +1000, Anand Kumria wrote: Hi Steve, On Wed, Jul 30, 2003 at 08:02:44AM -0500, Steve Langasek wrote: On Wed, Jul 30, 2003 at 05:40:26PM +1000, Anand Kumria wrote: If you, or anyone else, is interested shipping those overseas could be arranged (with the caveat that glass might break in transit). I need to know by this Friday to get them in time for Aug 16th so if you'd like any of this stuff, let me know. What kind of shipping costs would be tacked on for overseas orders? It would really depend on how many you wanted, The steins are about 0.5kg and the bags about 250g but apparently the minimum shipping cost is AUD$18 (for 20kg) overseas. Which is actually more than the Steins (AUD$12) are, Bags are AUD$30. Photos are available at URL: http://www.progsoc.org/~wildfire/debian/ in the appropriate directory (the .jpg's). There wasn't that much interest so there are only a limited number (50 bags, 72 steins). If you are still interested, let me know. It was mainly a question for clarification's sake, actually -- you had offered overseas shipping, and I know from experience that it can be rather costly to ship to/from Australia. In any case, I could only find a home for at most one, so it doesn't seem cost-effective for me to partake. :) -- Steve Langasek postmodern programmer pgpY0aNKvL5zo.pgp Description: PGP signature
Re: Bits from the RM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2003-08-20 15:27, Steve Langasek wrote: On Wed, Aug 20, 2003 at 12:38:57PM +0200, cobaco wrote: On 2003-08-20 12:10, Michael Piefel wrote: Am 20.08.03 um 11:08:28 schrieb cobaco: kde 3.2 release is slated for 8th december[1], is there any chance we'll wait for it, just so the outdated kde label doesn't apply again immediately after release? actually that's just it, if we release on 1st december and KDE releases on 8th december, then 7 days after release we no longer have the stable KDE release in stable, which is a rather unfortunate timing, no? No. This is the way stable releases work. You can't have the latest and greatest version of the software in the distribution the day it releases and expect the whole thing to actually be stable, and you shouldn't ask the RM to delay the release on account of an impending upstream release of one piece of software. There's *always* new software being released in the community, and KDE is probably very low on the priority list *of those who use stable*. KDE3.2 doesn't miss the deadline by 7 days, it misses the deadline by almost two months: * October 15th Final, last-minute, low-risk bug fixes only Monday September 29th, 2003: Preparing Beta1 The HEAD branch is tagged as Beta 1 and is frozen for nonurgent commits[1] is there any reason why stabilization of kde and stabilization of kde-packaging can't be done in parallel? If we manage to release Sarge and it contains the current upstream KDE packages for a whole seven days, THAT is a noteworthy improvement all its own. true enough [1] http://developer.kde.org/development-versions/kde-3.2-release-plan.html - -- Cheers, cobaco /\ ASCII Ribbon Campaign \ / No proprietary formats in attachments without request X i.e. *NO* WORD, POWERPOINT or EXCEL documents / \ Respect Open Standards http://www.fsf.org/philosophy/no-word-attachments.html http://www.goldmark.org/netrants/no-word/attach.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q4bu5ihPJ4ZiSrsRArYgAJ9GKskZ/fHATn0ZziRJ+VjjlWNqLQCfTKqi 73qCpgKHv8uj3NHYVsYnSuk= =vTZJ -END PGP SIGNATURE-
Re: Bits from the RM
On Wednesday 20 August 2003 13:30, Russell Coker wrote: KDE 1.x was quite usable, while many of the beta releases in the 2.x and early 3.x series weren't... That's why they're called betas :) I don't think this whole discussion fits in here, for 2 reasons: - the KDE conference (which will produce Alpha 1) has yet to happen - the KDE release plan might be delayed (as well...) Josef -- Play for fun, win for freedom. Linux-Info-Tag Dresden 2003: http://www.linux-dresden.de
Re: Bits from the RM
Op wo 20-08-2003, om 13:26 schreef cobaco: On 2003-08-20 12:36, Isaac To wrote: cobaco == cobaco [EMAIL PROTECTED] writes: Why KDE cannot be used on servers (how about a X terminal server? You don't have to set it up?) not what I meant: off course it can be used on a server, so can the gimp, this doesn't make the gimp server software does it? All I'm saying is that KDE, when installed on a server is not a mission-critical piece of software. You're trying to say that it's impossible for an organization to install some thousands of X terminals that all run KDE (which, of course, is installed on the server)? Or do you just mean that in such a situation, the users' desktops aren't mission critical? Happy me, to not have to work where you work. Besides major bugs would've been filtered out by the kde release proces, and minor bugs would not interfere with functioning of a server. You can't know that. If the primary function of that server is 'to support X terminals or diskless clients that run KDE', then KDE probably is quite mission critical. and why on stable you do not expect a stable KDE? kde 3.2. will be the stable kde release come 8 december It's hardly relevant for Debian how KDE manages its stable releases, is it? What I perceived: if you want an updated KDE, go run testing or unstable. If many people like a really updated KDE, one of them should act up and package a CVS version in experimental. unless I'm completely mistaken the kde packagers commit there directly in kde cvs. That's not what's meant here. [...] And I don't mind Debian stable being marked as always having an outdated KDE. It is supposed to work that way. While I agree it wouldn't be the end of the world, and it has certainly been that way sofar, I most definately do _NOT_ agree that it is supposed to work that way. Then I suggest you start maintaining KDE backports for stable, because it most certainly is supposed to work that way. We don't provide updates for stable; as such, the logical result is that stable becomes outdated. Stable having outdated software is an (undesired) side-effect from keeping the stable release stable. If we can have up-to-date software that is also reasonably stable (again this is end-user software, not server-software) this is better no? It depends on what you find most important. If stability is most important, then no, it isn't. If being up-to-date is most important, we'd be wasting our time with all this freezing anyway. -- 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 Wed, Aug 20, 2003 at 03:52:42PM +0200, Santiago Vila wrote: On Wed, 20 Aug 2003, 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. Will we some day consider seriously the idea of autobuilders compiling against testing those packages which do not need libraries from unstable to be built? Do you foresee any reasons why using experimental for new library uploads wouldn't serve the same purpose? -- Steve Langasek postmodern programmer pgpO7yAYpLReB.pgp Description: PGP signature
Re: Bug#205471: [rene@debian.org: Bug#205471: devscripts: running debuild could lead to deleting _all_ backup dirs/files on the system]
Julian Gilbey [EMAIL PROTECTED] writes: I really like this idea, thank you! I will accept directory names Thanks. :-) matching the regexp /^$package(-.*)?$/ - does that seem reasonable? Yep, though I might change the * to a +. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: non-DD contributors and the debian keyring
* Martin Quinson ([EMAIL PROTECTED]) wrote: $ LC_ALL=C gpg --keyserver keyring.debian.org --recv-keys E145F334 gpg: no valid OpenPGP data found. gpg: Total number processed: 0 This is the ID of my key, available from www.keyserver.net and signed by 2 DD. Did I mess something up ? keyring.debian.org has only DDs in it. I think people were suggesting using the public keyservers. keyring.debian.org isn't a part of the public key servers. Shouldn't Debian make sure that work submition from non-DD contributor are signed, just like it does for the work submition from DD ? Interesting question. While it's not a bad idea I don't see it as entirely necessary either. At least when sponsoring a package the DD performing the sponsor must check everything regardless of if it was sent to them signed or not. They have to check that the tarball given matches that on the official site (or verify that it's clean and correct some other way), they have to very carefully look through the diff, they have to build the package themselves, they should compare the diff to the prior versions diff if there was one, etc, etc. It' s not as much work as doing the packaging themselves but it still is a fair bit of work. Once complete the sponsor should be completely confident with the package. DD's are expected to do this work for themselves too but there's no one who's going to double-check it before it's put into the system so there has to be a way to verify that it's been done- that's why DD's sign their packages before uploading (at least one reason anyway). DD's are trusted to have checked over their packages and whatnot and signing the packages basically says I've checked over it and it should be included. Since, at least at one point not sure if it's still true, packages could be uploaded via anonymous ftp so long as it was signed. I don't know much about the translation work. I would expect that this work is checked by some DD before being incorporated too, even if it's just to ensure the package builds correctly with it since we don't all know every language.. The same is kind of true for patches which change code the DD's might not be extremely familiar with, though there at least they could consult with upstream if they were unsure. I'm not sure what kind of double-check could be done on the translation work that's submitted, for example, via the BTS. I'm also not sure it's entirely necessary, I would find it pretty unlikely for someone to mount an attack by submitting patches which translate debconf questions to ask other things or something.. Stephen pgpocKWMMln0k.pgp Description: PGP signature
Re: Bits from the RM
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. It's certainly similar to other disasters of the past twelve months, and it's something to keep an eye on, and to randomly submit useful patches for, but we're in a substantially better position to handle it this time around. Besides, what fun would a release be if we didn't have key machines crashing, and chaos in important packages? 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?'' pgptEGDrU3foY.pgp Description: PGP signature
Re: Bits from the RM
On Wed, Aug 20, 2003 at 06:48:51PM +0800, Cameron Patrick wrote: There were pretty major changes between KDE 3 and KDE 3.1. As a Debian user, I'd be rather miffed if a new version of KDE came out within a week of sarge being released ... on the other hand, if sarge is to be frozen in a couple of months' time, it seems unlikely that KDE 3.2 will be able to make it in. *grumble* :( You are, of course, welcome to feel whatever you like. But if you're particularly interested in running the latest software, you shouldn't be remotely interested in running Debian stable releases. That's not what they're there for. You should expect any software in a Debian stable release to be somewhere between two months and two years out of date at any given time; with a bias towards less out of date just after a release, and more out of date just before a release. As a simple example, if we have releases on the 1st of December each year from now on, sarge's KDE should be between four and sixteen months old, during sarge's run as stable. By contrast, if we lived in a magical world where such things were feasible, and delayed sarge by a week to include KDE 3.2, during sarge's life, KDE would be between zero and twelve months old. [0] Now perhaps this really is the difference you're hoping for, but it sounds to me more like you're a bit disappointed that the version of KDE in stable will be even a few months out of date, ever. Which is fair enough: if you're not happy with running a version of KDE that's twelve months older than the current release, stable's not what you should be looking at; testing or unstable is. You should, of course, then be massively disappointed that testing's version of KDE is some 21-months old. But hey, win some, lose some. Cheers, aj [0] Maths break! The average out-of-dateness over the life of stable in the two cases is 10 months and 6 months respectively. The difference is noticable, but not particularly extreme. If you want to make it look a bit more extreme, you can start counting from major releases instead of minor releases: that gives you 16 and 6 months averages instead. For comparison, woody has KDE 2.2.2 which was out at the end of November, so was eight months out of date when woody released by that measure; and should we release Dec 1st, will have an average out of dateness of 16 months counting minor releases, or 19 months counting major releases. In general, the average out of dateness is u + p/2, where u is how out of date the package is when we release, and p is the period between releases. u is bounded below by however long it takes us to become confident with a new release, c, and has an upper limit of p_u + c + l_m + l_r, where p_u is the time between upstream releases, and l_m and l_r are lag factors -- l_m is the maximum amount of time after a package could've been included in Debian (p_u + c since the last new upstream version), that the maintainer can put up with user requests and general guilt, before doing an upload, and l_r is the release lag involved in getting the package settled into testing. c = up_u + c + l_m + l_r c + p/2 = u + p/2 p_u + c + l_m + l_r + p/2 c + p/2 = oldness p_u + c + l_m + l_r + p/2 We probably can't do anything about p_u, and there are definite lower limits on p -- probably somewhere around six months. In any event, we have: general delays: c -- how long it takes us to be confident a new upstream release is good, after it's released p -- release length variable delays: p_u -- how often upstream releases l_m -- how slack the maintainer can be l_r -- how broken the testing scripts are and/or how broken the rest of Debian is Plausible values for KDE core components at the moment are probably something like: c = 0.4 p_u = ~10 months for major releases, 2 months for minor releases l_m = 0 l_r = 10 months If we released right now, eg, we'd be releasing with the same version of KDE that's in woody -- that's the impact of the l_r factor. Given that we've been trying to get KDE into testing for literally twelve months, it's reasonably safe to say that general breakage in Debian is the biggest factor in out-of-dateness in stable. We've had numerous breakages in glibc and other libraries KDE depend on for extended periods. Adjusting the release date to be after KDE 3.2's release still needs to take in these other factors, in particular reducing l_r massively. It might be possible to do that by saying everything but KDE has to be ready for release on 1st December, KDE has to be ready for release by 31st December, however I'm not willing to make that much of a special case. Moving the release date in
Re: Bits from the RM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2003-08-20 15:17, Wouter Verhelst wrote: You're trying to say that it's impossible for an organization to install some thousands of X terminals that all run KDE (which, of course, is installed on the server)? not what I'm trying to say Or do you just mean that in such a situation, the users' desktops aren't mission critical? Besides major bugs would've been filtered out by the kde release proces, and minor bugs would not interfere with functioning of a server. You can't know that. If the primary function of that server is 'to support X terminals or diskless clients that run KDE', then KDE probably is quite mission critical. KDE is not mission critical in the sense that when a user's KDE-instance crashes the KDE-instances of the other users will continue to run. Just like when -in that same organization with some thousands of X terminals- 1 X terminal has a hardware problem this is not a mission critical problem (for the organization, it may be considered a mission critical problem for the user of that particular terminal). The mission critical software in this example would be the ltsp-server-software. And I don't mind Debian stable being marked as always having an outdated KDE. It is supposed to work that way. While I agree it wouldn't be the end of the world, and it has certainly been that way sofar, I most definately do _NOT_ agree that it is supposed to work that way. Then I suggest you start maintaining KDE backports for stable, because it most certainly is supposed to work that way. We don't provide updates for stable; as such, the logical result is that stable becomes outdated. I wasn't implying we should provide updates to stable, all I was saying is that at the moment a release becomes stable, then -if at all possible- this software should be up-to-date. I don't agree that 'software in stable is supposed to be out-dated', I do agree with 'software in stable tends to become outdated'. Stable having outdated software is an (undesired) side-effect from keeping the stable release stable. If we can have up-to-date software that is also reasonably stable (again this is end-user software, not server-software) this is better no? It depends on what you find most important. If stability is most important, then no, it isn't. If being up-to-date is most important, we'd be wasting our time with all this freezing anyway. It's not a question of either stability or either up-to-dateness but of the right balance between the two. IMHO that balance lies differently for server-sofware then for end-user software NOTE: by server-software I mean software providing some service to the network, not just software running on a server-machine. - -- Cheers, cobaco /\ ASCII Ribbon Campaign \ / No proprietary formats in attachments without request X i.e. *NO* WORD, POWERPOINT or EXCEL documents / \ Respect Open Standards http://www.fsf.org/philosophy/no-word-attachments.html http://www.goldmark.org/netrants/no-word/attach.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q4/s5ihPJ4ZiSrsRAq93AKCIHusZiafUHssWxE5t5KzNK3BdVQCfQkSv VHbpDTmGpH+eGTkb2Vj1acY= =mmjd -END PGP SIGNATURE-
UniteU's AntiVirus scan detected a virus in a message you sent to %2
Recipient of the infected attachment: DC3, UniteU\Mailbox Store (DC3), Paige Obrien/Inbox Subject of the message: Re: Details One or more attachments were intercepted and deleted Attachment document_9446.pif was Deleted for the following reasons: Virus [EMAIL PROTECTED] was found.
Re: #206298 spip: prerm script blindly removes directories
On Wed, Aug 20, 2003 at 01:45:09PM +0200, Gaetan Ryckeboer wrote: Package: spip Version: 1.6.0-2 Severity: normal The prerm script blindly deletes the following directories and all subdirectories: /var/cache/spip /usr/share/spip/ecrire/upload /usr/share/spip/ecrire/data There is no guarantee that the files in these directories belong only to this package. While it is quite likely that they will, it can not be guaranteed and care should be taken on package removal to not remove any files that are not owned solely by the package. All right. I understand the problem. But the directories removed by the postrm/purge are normaly only used : - by user, to upload datas related to his spip installation, Is this uploaded data recorded anywhere? In the MySQL database perhaps? If so, the file names can be retrieved from there for removal on purge. Additionally, you may upset users by simply deleting their uploaded files on purge. Some may see this as deletion of user data, which should not be done. - by spip himself, to store cache informations, Are the file names predictable in any way? If so, you can look for files fitting the pattern. - by spip himself, for log or backups. The file names of the logs or backups should be predictable, right? As someone else has already pointed out, /usr/share should be capable of being made read-only. Any runtime changing data for an application should be under /var/lib. For more information the following link may help: http://www.debian.org/doc/packaging-manuals/fhs/fhs-toc.html -- Jamin W. Collins This is the typical unix way of doing things: you string together lots of very specific tools to accomplish larger tasks. -- Vineet Kumar
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Wed, 20 Aug 2003, Brian May wrote: When Jaldhar takes about dependancies, I assume he means normal Depends, not Build-Depends??? Correct. [...] Source package has the following files (note: this is called a source package not a binary package): webmin_1.100.orig.tar.gz webmin_1.100-2.diff.gz webmin_1.100-2.dsc Extracting this source package and running debian/rules build would produce the following *binary packages*: webmin_1.100-2_all.deb webmin-core_1.100-2_all.deb webmin-apache_.100-2_all.deb webmin-squid_.100-2_all.deb [...list truncated...] Jaldhar, please tell me what the problem is with the above approach. 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. -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/
what about ip's
i've had cable connectivity with charter.net for more than 1 year. until yesterday i've never had need of an email acct there. i planned on using the address at charter when the spam at my top-10 acct became unbearable. when i finally got my log-in info for the charter acct. i logged in and to my surprise there were already more than 200 spams waiting for me. my first assumption is that charter sells their users email addresses. does anyone on this list know how an unused email address that has never been used can have spam without the ip giving the address out? thanksDavid Smith dsmith_sig1.GIF
Re: #206298 spip: prerm script blindly removes directories
Le Wed, Aug 20, 2003 at 09:26:14AM -0600, Jamin W. Collins a écrit : All right. I understand the problem. But the directories removed by the postrm/purge are normaly only used : - by user, to upload datas related to his spip installation, Is this uploaded data recorded anywhere? In the MySQL database perhaps? If so, the file names can be retrieved from there for removal on purge. Mmm... yes and no. Some of them could be. But a user may upload files without using them in the application. So, the files are available, but unused, and unreferenced. Additionally, you may upset users by simply deleting their uploaded files on purge. Some may see this as deletion of user data, which should not be done. Of course, I understand. But I wonder they won't upload personal files for another use than spip here... - by spip himself, to store cache informations, Are the file names predictable in any way? If so, you can look for files fitting the pattern. True. - by spip himself, for log or backups. The file names of the logs or backups should be predictable, right? True. As someone else has already pointed out, /usr/share should be capable of being made read-only. Any runtime changing data for an application True. But due to the implemntation of the application, which is written in php, datas are stored on the program dir. There is no real separation between datas and functions. And if i symlink some datas (for apache access AND direct file handler access), i'll will setup another alarm... and it won't be accepted. -- Il n'y a qu'un décolleté pour pousser un homme à rechercher la profondeur chez une femme. -- Zsa Zsa Gabor Gaétan RYCKEBOER Société Virtual-Net [Tous textes et propos tenus dans ce couriel sont sous license DMDZZ] pgpa40uOPwjAk.pgp Description: PGP signature
Re: What doing with an uncooperative maintainer ?
On Mon, Aug 18, 2003 at 04:32:03PM +0200, Thomas Hood wrote: I don't see why it would be idiotic to fork the package. If you can package this application better than the current maintainer then go ahead and do so. Forking packages outside of Debian might or might not achieve the goals you mention. Forking packages inside Debian is not only problematic but idiotic. Repeat after me: the package management system does not support package renames. Upgrades across packages with different names simply doesn't work. Going down that route for the little benefit of being elite^Wup to date for the sake of being up to date is not worth it. Talk with the maintainer. Or NMU. Or make noise on -devel. But don't fork packages. Marcelo
Re: non-DD contributors and the debian keyring
On Wed, Aug 20, 2003 at 11:23:47AM +0200, Martin Quinson wrote: On Wed, Aug 20, 2003 at 06:46:34PM +1000, Martin Michlmayr wrote: * Goswin von Brederlow [EMAIL PROTECTED] [2003-08-20 10:31]: Martin Quinson [EMAIL PROTECTED] wrote: I just wondered if it would be possible for non-developper contributors to Debian to get their GPG key in the Debian keyserver. You can also apply as a NM for translation work. You don't need to maintaine a package or know much about the packaging system for that. You get different taskskill tests. V I P Martin Quinson [EMAIL PROTECTED] Exact. I *did* apply. I'm even pretty well advanced in the process. $ LC_ALL=C gpg --keyserver keyring.debian.org --recv-keys E145F334 gpg: no valid OpenPGP data found. gpg: Total number processed: 0 This is the ID of my key, available from www.keyserver.net and signed by 2 DD. Did I mess something up ? Shouldn't Debian make sure that work submition from non-DD contributor are signed, just like it does for the work submition from DD ? The keyring on keyring.debian.org is used directly as a means of authorizing people to a number of Debian resources, including the package upload queue and d-d-a. Whether you agree with this design or not, it means that the Debian keyserver is not suitable for use as a general-purpose means of *authenticating* people. For authenticating PGP users to one another, you should use the usual Web of Trust to achieve this. -- Steve Langasek postmodern programmer pgpiZwGdLyHUr.pgp Description: PGP signature
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Tue, 19 Aug 2003, Steve Langasek wrote: Yep. And given that upstream offers webmin as an all-in-one solution to web-based management needs, I don't really see any reason why they shouldn't be kept lock-step with one another. As Debian developers our goal is to make an integrated OS which works according to our own internal logic. From that perspective some of the choices made by upstream maintainers are not optimal. For instance, one of the reasons all the webmin modules are distributed together is because there is no cross-platform dependency mechanism so the author doesn't know what you've got. So he just installs everything and its up to you to switch off the stuff you don't need. Thanks to dpkg, we don't need to do that. If e.g. I'm using postfix, there is absolutely no reason why I should need to have the webmin sendmail module installed. I particularly don't see why it's good that bugs in this group of packages themselves be ignored for testing processing of the others. Does webmin even provide any standard APIs that guarantee particular modules will work with particular versions of webmin? Version slip here seems like it could pose a serious problem, even *beyond* the usual partial upgrades question. No guarantee is given but so far backward compatability has been pretty good fwiw. -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/
Proposal: make kernel install easier
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. For example, quik could have debconf questions: Manage quik.conf using debconf? and Install new kernels automatically? and perhaps Global kernel option defaults (though perhaps this would be better outside of each individual bootloader). Then each kernel package would have a low- to med-priority debconf question asking with what options to boot the kernel starting from global defaults. It could also ask whether to make this image top priority in the .conf, and what name string to use for this image. Also, quik could Provide virtual package bootloader which kernel-image packages could Suggest. [A really fancy bootloader could also use debconf to prompt for info about other OSes on other partitions for its .conf, e.g. bye for MacOS in quik...] The kernel-image's postinst would run all of the scripts in /usr/lib/bootloaders/ with arguments like --add-index-entry --name 2.4.20-2-powermac --kernel /boot/vmlinuz-2.4.20-2-powermac --initrd /boot/initrd.img-2.4.20-2-powermac (or --noinitrd) --boot-options root=/dev/hdb6 video=offb --top-boot-priority . If quik's Manage quik.conf automatically answer is no, then /usr/lib/boot-loaders/quik with these options does nothing. Then the kernel-image's postinst runs the scripts with something like --make-bootable and /usr/lib/bootloaders/quik goes off and makes the first and second boot blocks, does its open firmware thing etc., and reports back success (or not). Again, if quik's Install new kernels automatically answer is no, this does nothing. The kernel prerms (or postrms?) would also have to run the scripts with --remove-index-entry --name 2.4.20-2-powermac and again with --make-bootable in order to clean up safely. The only trouble I can think of is what to do with already-installed kernels which don't have such postinst/prerm options. The .conf files can be generated automatically, but when a kernel is removed, they're not cleaned up. Any /usr/lib/bootloaders/quik --regenerate-index type thing would have to be run manually on each kernel removal, though a debconf info thing in the new quik package could let users know this. Also, on Alphas running ARC/AlphaBIOS, Netwinders, etc. there would still be manual configuration to do during the boot process, so this wouldn't cure everybody's ills. Aside from these bits of trouble, such a system would make a lot easier the process of installing and removing what are now some of the most annoying packages to deal with (for me at least), particularly given quirks on different arches. If there's interest (and no show-stoppers anyone can think of), I'll start writing patches to kernel-package, lilo, maybe even quik :-) -- that is, unless someone else wants to, e.g. their maintainers. [Please CC me in replies as I'm not subscribed. And apologies if this has been brought up before; searches on lists.debian.org didn't turn up anything.] Cheers, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Does anyone use barrendero, or know of an equivalent?
Hello, The package barrendero is a candidate for removal from testing. It has two RC bugs, no response from the maintainer, and the upstream website seems to have vanished (the maintainer is also upstream). It seems like a useful tool: Description: Deletes messages on the spool dir depending on their age. Barrendero is intended to limit the disk space wasted at the spool directory. It deletes mail messages depending on their age, and has the ability to send warnings and reports to the users, to make full and partial backups, and to have different allowed ages on a per-user basis. Warning and report messages are cusomizable and can be translated easely in order to make this package useful in any environment. This way of handling mail as an advantage over the traditional 'quota' system: quotas make the end user loose NEW mail, barrendero deletes OLD mail, so the new mail is always available. 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? Does anyone know of another package that provides similar functionality? Thanks, -- Steve Langasek postmodern programmer pgpy7v2KoqL8F.pgp Description: PGP signature
Re: Debian Weekly News - August 19th, 2003
On Wed, 2003-08-20 at 08:35, Jrme Marant wrote: Quoting Josselin Mouette [EMAIL PROTECTED]: Le mar 19/08/2003 23:33, Mike Hommey a crit : Ok, let's google a bit, and shazaam ! http://www.linex.org/sources/linex/debian/linex/nvidia-glx_1.0.4349-1_i386.deb Oh ! non-free software ! Thanks Richard for keeping me laughing. Bah, if RMS really didn't like non-free software, he would give up with that FDL stuff... No he wouldn't. FDL is about free documentation. :-) Except it isn't :-) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: ftp.gnu.org cracked
[ Moved to debian-devel, I don't think this is relevant to private as the GNU crack is well publicised ] On Mon, 2003-08-18 at 14:58, Matt Zimmerman wrote: On Mon, Aug 18, 2003 at 12:35:44PM +1000, Russell Coker wrote: On Mon, 18 Aug 2003 12:51, Robert Millan wrote: What do you suggest to do? First, can this dicussion be disclosed? (e.g: into debian-security). Then how can we deal with these two problems? Would an alert message to -devel-announce suffice? The hack of the GNU server is no secret, and neither is our reliance on GNU software. I think that anyone who knows anything about Debian can work out the issues for themselves. Therefore trying to keep this secret gains us nothing and only gives a risk of more concern. I suggest publicising everything. If we're going to make a statement about it, we should have some facts to release. For example, if someone would like to verify the validity of the GNU source tarballs that we ship against the checksums published by GNU, that would be great. No problem, this is only a quick run -- others may find ways to improve this script somewhat. 153 files were compared (out of 1624 available checksums), reasons for missing comparisons probably include changes in source package name compared to GNU tar name, or simply differing versions. 113 checked out OK. This means that the .orig.tar.gz in Debian has the same checksum as the equivalent GNU tar, and that the GNU checksum is considered valid by GNU. 40 did not check out. This doesn't mean we've got cracked versions, it just means that our .orig.tar.gz isn't identical to the GNU .tar.gz. Also note that I just checked what versions could be found in the pool, not necessarily the latest unstable version. Many of the latest versions are missing a GNU-valid md5sum anyway. The script I used is attached, it takes the before-2003-08-01.md5sums file from the GNU ftp site (run through gpg to remove signature) as either stdin or a command-line argument. Here's the (sorted) results. adns: adns_1.0.orig.tar.gz OK. anubis: anubis_3.6.2.orig.tar.gz OK. aspell: aspell_0.50.3.orig.tar.gz OK. autoconf: autoconf_2.13.orig.tar.gz OK. autoconf: autoconf_2.53.orig.tar.gz OK. autoconf: autoconf_2.57.orig.tar.gz OK. autogen: autogen_5.3.5.orig.tar.gz OK. barcode: barcode_0.98.orig.tar.gz OK. bc: bc_1.06.orig.tar.gz OK. bison: bison_1.28.orig.tar.gz OK. bison: bison_1.35.orig.tar.gz OK. !! cfengine: cfengine_1.5.3.orig.tar.gz NOT OK (2603cf1cd3225b06e5df725c866dc987 != b25c09e5d9ee55722771a3732c0b10ff) !! cfengine: cfengine_1.6.4.orig.tar.gz NOT OK (f1b94557fe01869eee9764e613efa0ee != 5bc50dbeb87e6edbd68526cfacff6fb3) !! clisp: clisp_2.28.orig.tar.gz NOT OK (d5f8acf2de0db2f5f53e7747d0d84503 != 7d245c446dd5cdeb263b5648bfb4fb76) clisp: clisp_2.27.orig.tar.gz OK. clisp: clisp_2.30.orig.tar.gz OK. !! coreutils: coreutils_5.0.orig.tar.gz NOT OK (d16b769d380a0492a4c5ee61d2619985 != a0ef2d8abd223aca757228590ded9e63) !! cpio: cpio_2.4.2.orig.tar.gz NOT OK (e651ca1e1ac53aaebfa7ad256b0fe4fc != 3e976db71229d52a8a135540698052df) !! cpio: cpio_2.4.2.orig.tar.gz NOT OK (e651ca1e1ac53aaebfa7ad256b0fe4fc != 3e976db71229d52a8a135540698052df) cpio: cpio_2.5.orig.tar.gz OK. ddd: ddd_3.3.1.orig.tar.gz OK. !! dejagnu: dejagnu_1.4.2.orig.tar.gz NOT OK (f8d9f36ea74fd56ad4a68d5cc2a14bba != a697e39c767a47aca9166fcd7420e4b8) dejagnu: dejagnu_1.4.3.orig.tar.gz OK. diction: diction_1.02.orig.tar.gz OK. !! doschk: doschk_1.1.orig.tar.gz NOT OK (38b9613f471667573956f0e02b9ff091 != 112565f30ef98595b363afb70cb6a835) !! doschk: doschk_1.1.orig.tar.gz NOT OK (38b9613f471667573956f0e02b9ff091 != 112565f30ef98595b363afb70cb6a835) ed: ed_0.2.orig.tar.gz OK. ed: ed_0.2.orig.tar.gz OK. electric: electric_6.05.orig.tar.gz OK. elib: elib_1.0.orig.tar.gz OK. emacs-lisp-intro: emacs-lisp-intro_2.04.orig.tar.gz OK. fileutils: fileutils_4.1.orig.tar.gz OK. gawk: gawk_3.1.0.orig.tar.gz OK. gawk: gawk_3.1.1.orig.tar.gz OK. gawk: gawk_3.1.3.orig.tar.gz OK. !! gcal: gcal_2.40.orig.tar.gz NOT OK (0a17026a3950847bb42206cfa03c1c98 != 6b6058fa80c2e95392ef1ca561e4800f) !! gcc: gcc_2.95.2.orig.tar.gz NOT OK (0e36957d734286e242e9697fd2806c4f != 110f1e5b3adfefc9d7be071e91c54f6a) gdb: gdb_5.3.orig.tar.gz OK. gdbm: gdbm_1.7.3.orig.tar.gz OK. gdbm: gdbm_1.8.3.orig.tar.gz OK. gengetopt: gengetopt_2.10.orig.tar.gz OK. gengetopt: gengetopt_2.6.orig.tar.gz OK. gengetopt: gengetopt_2.9.orig.tar.gz OK. gettext: gettext_0.10.35.orig.tar.gz OK. gettext: gettext_0.10.40.orig.tar.gz OK. gettext: gettext_0.11.5.orig.tar.gz OK. gettext: gettext_0.11.orig.tar.gz OK. gettext: gettext_0.12.1.orig.tar.gz OK. gfax: gfax_0.4.2.orig.tar.gz OK. !! gforth: gforth_0.5.0.orig.tar.gz NOT OK (db16b64e9d63934bc4455e9b2aebbe13 != 8aade0bf98bfc57d084beb3af3875c36) gforth: gforth_0.6.1.orig.tar.gz OK. !! ggradebook: ggradebook_0.91.orig.tar.gz
Re: Debian Weekly News - August 19th, 2003
Quoting Scott James Remnant [EMAIL PROTECTED]: No he wouldn't. FDL is about free documentation. :-) Except it isn't :-) According to you :-) -- Jérôme Marant [EMAIL PROTECTED]
Re: Binaryless uploads
On Tue, 19 Aug 2003 16:16:10 -0400 (EDT), Jaldhar H Vyas [EMAIL PROTECTED] said: On Tue, 19 Aug 2003, Goswin von Brederlow wrote: Then the source should be split in a way that the normal debian/rules files work and common files (like headers) stuffed into a -dev package you can build-depend on. Have you actually bothered looking at the webmin tarball? I repeat it is a set of independent modules only bundled together upstream for convenience. (And btw, it is a set of perl scripts.) As I understand it, there is an script that does the separation for you when you package the .debs. Is there a reason a similar script can't be invoked by debian/rules to create the multiple debs from the same source? debian/rules does work. It just doesn't produce what people expect it to. That's why barring any better ideas, I'm just going to reduce the size of the orig.tar.gz to the bits that actually make up the webmin binary package. Well, it is your package, and your decision, but retaining upstream packaging is generally desirable; and if you already have an automated means of separating out the irig.tar.gz for each binary .deb, doing so in ./debian/rules may be a better solution. manoj -- Our missions are peaceful -- not for conquest. When we do battle, it is only because we have no choice. Kirk, The Squire of Gothos, stardate 2124.5 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: Bits from the RM
Hi, Steve Langasek wrote:
KDE3.2 doesn't miss the deadline by 7 days, it misses the deadline by
almost two months:
Uh, you've got that turned around. October is not _missing_ the deadline,
that's _beating_ it.
* October 15th
Final, last-minute, low-risk bug fixes only
.. which means we have two+ months to fix any problems.
I do agree, however, that we shouldn't delay Sarge because of KDE.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
New York now leads the world's great cities in the number of people around
whom you shouldn't make a sudden move.
-- David Letterman
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
Jaldhar H. Vyas [EMAIL PROTECTED] writes: 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. The only problem with that is the current failure to comply to policy, i.e. build from source as they should. But now that you have seen the light :) keep on working. MfG Goswin
Re: non-DD contributors and the debian keyring
Martin Quinson [EMAIL PROTECTED] writes: On Wed, Aug 20, 2003 at 06:46:34PM +1000, Martin Michlmayr wrote: * Goswin von Brederlow [EMAIL PROTECTED] [2003-08-20 10:31]: Martin Quinson [EMAIL PROTECTED] wrote: I just wondered if it would be possible for non-developper contributors to Debian to get their GPG key in the Debian keyserver. You can also apply as a NM for translation work. You don't need to maintaine a package or know much about the packaging system for that. You get different taskskill tests. V I P Martin Quinson [EMAIL PROTECTED] Exact. I *did* apply. I'm even pretty well advanced in the process. There is the part before waiting for the DAM and while waiting for the DAM. :) $ LC_ALL=C gpg --keyserver keyring.debian.org --recv-keys E145F334 gpg: no valid OpenPGP data found. gpg: Total number processed: 0 This is the ID of my key, available from www.keyserver.net and signed by 2 DD. Did I mess something up ? Shouldn't Debian make sure that work submition from non-DD contributor are signed, just like it does for the work submition from DD ? Usually the sponsor looks everything over so signing is not realy neccessary. Of cause if you have the same sponsor repeatetly he might want to just check your signature and sponsor the changes blindly knowing you did good work in the past. But he would replace your signature with his for uploading purposes so its just for his sake so he knows it was you. MfG Goswin
Re: Bits from the RM
On Wed, 20 Aug 2003, Steve Langasek wrote: On Wed, Aug 20, 2003 at 03:52:42PM +0200, Santiago Vila wrote: Will we some day consider seriously the idea of autobuilders compiling against testing those packages which do not need libraries from unstable to be built? Do you foresee any reasons why using experimental for new library uploads wouldn't serve the same purpose? Yes, autobuilders do not build stuff from experimental, so it will hardly serve the same purpose as the current unstable, even if you convince a lot of users so that experimental is tested as much as unstable.
Re: what about ip's
On approximately Wed, Aug 20, 2003 at 10:06:15AM -0400, David Smith wrote: i've had cable connectivity with charter.net for more than 1 year. until yesterday i've never had need of an email acct there. i planned on using the address at charter when the spam at my top-10 acct became unbearable. when i finally got my log-in info for the charter acct. i logged in and to my surprise there were already more than 200 spams waiting for me. my first assumption is that charter sells their users email addresses. does anyone on this list know how an unused email address that has never been used can have spam without the ip giving the address out? From a lot of the spam I get at my charter.net account it seems to be that spammers just use some sort of dictionary and add that on the front of popular domain names. Somebody probably wrote a Perl script and sold it on Ebay! -- Josh McKinney| Webmaster: http://joshandangie.org -- | They that can give up essential liberty Linux, the choice -o) | to obtain a little temporary safety deserve of the GNU generation/\ | neither liberty or safety. _\_v | -Benjamin Franklin
Re: Bits from the RM
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 I think you are missing the point of stable, and Debian's users who don't would be more disappointed with just released software in stable than with somewhat out-dated software. Keep in mind that if this experiment works, testing will end up being what you wish stable was, at least that is how I see it. - Bruce
