Re: Need for launchpad
On Fri, Jan 06, 2006, Frans Jessop wrote: > Ubuntu's launchpad is amazing. Do you think it would be helpful if all > DD's worked through it on their projects? Wouldn't that keep things more > organized and efficient? Or perhaps Debian could build its own version of > launchpad which is better. Again, I think it would do a good job keeping > everything organized an efficient. In my experience of last week, some parts are still buggy; the software needs to mature a bit. I dream of the day I'll see patches from Fedora or Ubuntu one click away from the list of bugs of Debian packages. (I don't think the "non-free" argument is here of importance considering it's a web service, in the same way as Google or buildd.net. I shall get flamed for these remarks.) -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Fri, Jan 06, 2006 at 08:21:14AM -0500, Joey Hess wrote: > Anthony Towns wrote: >> Oh, the explanation for current practice is that if the key doesn't >> change in practice, apps that look at the keys won't cope well with the >> key changing, and when that becomes important, such as in the event of >> a compromise, we'll have major difficulties in coping. > In that case I suggest you rotate it every month for a few cycles. > BTW, has anyone thought about what will happen when we have a stable > release that has the 200n key in it and 200n+1 rolls around[1]? Will stable > even be installable anymore? How will the updated key be pushed out to > stable quickly enough? Will we have to rebuild CDs and obsolete all the > old ones then too? Is the current scheme of having overlapping > signatures for 1 month long enough, given that stable users might well > only update their machines quarterly or so? We're already doing security rX updates to Sarge anyway, surely we just need to synchronise the key rollover with those releases? And maybe an rX release if the current archive key becomes compromised? And yes, this means old rX release CD images are obsoleted. >_< Maybe the one-true-stable-key idea is the way to go after all... Or maybe an option to apt-key that auto-traces from the key on the CD to the current key, in a sort of certificate chain thingy... But that just reeks of "places to break the chain of trust". -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpIXxXSFa03Y.pgp Description: PGP signature
Re: APT public key updates?
On Sat, Jan 07, 2006 at 09:14:50PM +1100, Paul TBBle Hampson wrote: > We're already doing security rX updates to Sarge anyway, surely we just > need to synchronise the key rollover with those releases? And maybe an > rX release if the current archive key becomes compromised? This is inconsistent with Debian's past policies wrt stable releases, namely, that it should be possible for a user to skip all point releases and security updates (at the peril of their system's security...) and still be able to upgrade when a new stable release comes out. This is necessary if we're to accomodate the many Debian deployments which don't have a reliable network connection and are only updated when a new stable release is published. Please keep this use case in mind while designing solutions for the apt key update problem. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: APT public key updates?
also sprach Steve Langasek <[EMAIL PROTECTED]> [2006.01.07.1132 +0100]: > This is inconsistent with Debian's past policies wrt stable releases, > namely, that it should be possible for a user to skip all point releases and > security updates (at the peril of their system's security...) and still be > able to upgrade when a new stable release comes out. This is necessary if > we're to accomodate the many Debian deployments which don't have a reliable > network connection and are only updated when a new stable release is > published. Please keep this use case in mind while designing solutions for > the apt key update problem. As JoeyH suggests on http://wiki.debian.org/SecureApt, a debian-archive-key package, which contains all keys up until the current one, would do. Then, whenever a new key comes along, a new package is distributed via security.d.o. If we do this, I strongly suggest to move to one-key-per-release cycles. There is no reason to have a new key each January. As a matter of fact, if etch comes out in Decembre 2006, the archive keys it distributes will be usable only for a little more than a month. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! "never try to explain computers to a layman. it's easier to explain sex to a virgin." -- robert heinlein (note, however, that virgins tend to know a lot about computers.) signature.asc Description: Digital signature (GPG/PGP)
Re: gconf transition
Alejandro Bonilla wrote: I just upgraded Sid and rebooted, after that, logging into Gnome told me if I wanted to migrate to a Single file that will give me better performance, so of course I said yes. It logged me off and everytime that I need to log back in, it kicks me out. I don't have any special scripts, I just use some PAM for the FingerPrint reader. Still, ignoring the fingerprint authentication, it fails. [errors] Which package gets the bug report? Well, it does say it will break some things (did not break anything for me though), so I am sure developers are well aware. If you are not terribly concerned about loosing some of your settings, I suggest you delete your .gconf and let it be regenerated. By the way, you are much more likely to receive answers to such questions if you post in debian-user. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Quoting Loïc Minier ([EMAIL PROTECTED]): > (I don't think the "non-free" argument is here of importance > considering it's a web service, in the same way as Google or > buildd.net. I shall get flamed for these remarks.) As long as Debian doesn't want to build its own launchpad, sure. But the non freeness prevents us building such infrastructure on our ownn machines. This is especially true for Rosetta, the i18n infrastructure even though many translators would really love having a Rosetta-style infrastructure for Debian work. This topic will be discussed and probably worked on during the i18n Extremadura meeting we will have in September: http://wiki.debian.org/WorkSessionExtremadura2006i18n -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
Paul TBBle Hampson <[EMAIL PROTECTED]> wrote: > Maybe the one-true-stable-key idea is the way to go after all... One key by distribution? Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for Replacement Packager for Ampache
On Friday 06 January 2006 19.47, Karl Vollmer wrote: > Hello All, > > I apologize if this is the incorrect list to use for this purpose, > however a few months back I posted an ITP as I thought I would > actually have time to package up Ampache (http://www.ampache.org) > However that hasn't happened. What you should do is resend this message to the ITP and retitle the ITP to RFP (request for package) when you think it's worth it. I think someobdy wrote some script that weeds out very old ITP and RFP bugs every once in a while, so you don't have to worry aobut leaving cruft lying around - when nobody reacts to that RFP after some time (what? 1 year?) it will be removed. cheers -- vbi -- Beware of the FUD - know your enemies. This week * Patent Law, and how it is currently abused. * http://fortytwo.ch/opinion pgprHjcp80E7q.pgp Description: PGP signature
Re: APT public key updates?
* Bernd Eckenfels: > Paul TBBle Hampson <[EMAIL PROTECTED]> wrote: >> Maybe the one-true-stable-key idea is the way to go after all... > > One key by distribution? If this means one key per suite (sarge, etch, ...), and no yearly key rollover, I agree. 8-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP vexim2
Daniel: > is there anybody - preferred German speakers - who is willing and able > to package this OR to give assistance to me (i would try packaging when > there is somone helping me)??? Hi Daniel! An 'ITP' is supposed to be filed in the Debian bug tracking system. Best just use the 'reportbug' command, like 'reportbug wnpp' and follow the instructions on how to properly do this. cheers -- vbi -- Love may laugh at locksmiths, but he has a profound respect for money bags. -- Sidney Paternoster, "The Folly of the Wise" pgpaoiWeDCFYy.pgp Description: PGP signature
Bug#346373: ITP: tioga -- tioga : a powerful plotting system in ruby
Package: wnpp Severity: wishlist Owner: Vincent Fourmond <[EMAIL PROTECTED]> * Package name: tioga Version : 1.0.i Upstream Author : Bill Paxton (email omitted) * URL : http://theory.kitp.ucsb.edu/~paxton/tioga.html * License : LGPL Description : tioga : a powerful plotting system in ruby Tioga is a ruby library providing a way to make high quality graphes. Native output format is PDF, processing text using pdflatex. It can be used to plot functions and any kind of scientific data. Tioga is quite easy to use and very easy to script, for repetitive plottings, or for making animated plots. PS: the packaging is actually nearly done ;-) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gconf transition
Hi, On Fri, Jan 06, 2006, Alejandro Bonilla wrote: > /usr/lib/libgconf2-4/gconf-sanity-check-2: error while loading shared > libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such > file or dir > gconf-sanity-check-2 did not pass, logging back out I've filed a serious bug on gconf for now, but this might not be a _gconf_ bug. Thanks for your report, -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gconf transition
Le vendredi 06 janvier 2006 à 14:28 -0600, Alejandro Bonilla a écrit : > Hi, > > I just upgraded Sid and rebooted, after that, logging into Gnome told me if I > wanted to migrate to a Single file that will give me better performance, so of > course I said yes. It logged me off and everytime that I need to log back in, > it kicks me out. In fact it has nothing to do with the schema migration. > /usr/lib/libgconf2-4/gconf-sanity-check-2: error while loading shared > libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such > file or dir Ladies and gentlemen, this is a perfect example of why linking indirect dependencies is a very bad thing. Let me explain. Of all binaries shipped with GConf, gconf-sanity-check is the only one using GTK+. The only application using gconf-sanity-check is gnome-session. On first sight, it looks safe to exclude gconf-sanity-check for the computation of gconf dependencies, as gnome-session will always require libgtk2.0-0, and gconf-sanity-check isn't susceptible to use any symbols that could be added to GTK+. Now, let's have a look at gconf-sanity-check: NEEDED libgtk-x11-2.0.so.0 NEEDED libgdk-x11-2.0.so.0 NEEDED libXrandr.so.2 NEEDED libXi.so.6 NEEDED libXinerama.so.1 NEEDED libXext.so.6 NEEDED libatk-1.0.so.0 NEEDED libgdk_pixbuf-2.0.so.0 NEEDED libpangocairo-1.0.so.0 NEEDED libpangoft2-1.0.so.0 NEEDED libXcursor.so.1 NEEDED libpango-1.0.so.0 NEEDED libcairo.so.2 NEEDED libpng12.so.0 NEEDED libfontconfig.so.1 NEEDED libfreetype.so.6 NEEDED libXrender.so.1 NEEDED libX11.so.6 NEEDED libxml2.so.2 NEEDED libz.so.1 NEEDED libgconf-2.so.4 NEEDED libORBit-2.so.0 NEEDED libpopt.so.0 NEEDED libgobject-2.0.so.0 NEEDED libm.so.6 NEEDED libgmodule-2.0.so.0 NEEDED libdl.so.2 NEEDED libgthread-2.0.so.0 NEEDED libpthread.so.0 NEEDED libglib-2.0.so.0 NEEDED libc.so.6 The only libraries from which it actually uses symbols are libgconf2, libgtk-x11, libglib and libc. Now, as the dependencies of libgtk2.0-0 change, when the GTK+ backend changes, they're still required while not being really needed, but the program will nevertheless crash upon startup when not finding them. You can now thank pkg-config and libtool. I'm going to fix this right away, thanks for the report. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: [no subject]
Le vendredi 06 janvier 2006 à 15:11 -0500, Gillings, Marcus a écrit : > Hello, > > My name is Marcus Gillings. There was an email sent from me > on your website. Can you please delete it and the contents in it, > please. No, as explained on http://www.debian.org/MailingLists/ we don't remove emails from our archives. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Advices, comments? Bug#345651: passwd package should be essential?
Christian Perrier <[EMAIL PROTECTED]> wrote: [...] > I'm wondering if the passwd package should be essential or not. [...] > So, passwd was virtually essential because bash had a > dependency on it, but now it doesn't anymore. > So why do I think passwd needs to be essential? > There are several things in the package that one might > want to run from one of the maintainer scripts from > debconf, like useradd, groupadd, userdel, ... [...] Actually maintainer script shouldn't run these commands, they should use (and depend on) adduser. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Thu, Jan 05, 2006 at 04:32:29PM -0800, Matt Zimmerman wrote: > On Fri, Jan 06, 2006 at 01:22:50AM +0100, Petter Reinholdtsen wrote: > > [Michael Vogt] > > > Sorry for the delay. I'm preparing a new upload that adds the 2006 > > > archive key to the default keyring. > > > > Sounds good. Will this automatically take care of the key update and > > make sure no manual intervention is needed to get packages upgraded? > > > > Isn't Ubuntu using the signed apt stuff? How are they handling the > > new archive keys? > > Ubuntu's apt package ships only the Ubuntu archive keyring, not the Debian > archive keyring, so no update is needed when Debian keys change. That doesn't mean we (Ubuntu) have solved the problem of how to rotate *our* keys in the event of a key compromise. (To my knowledge, we haven't.) -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Aptitude question
James Vega <[EMAIL PROTECTED]> writes: > The aptitude in unstable and testing has a feature that lists suggested > ways to fix broken packages. Unfortunately, the feature doesn't work very well. Frequently I say "aptitude remove XXX" and the first several suggestions that aptitude comes up with is not removing XXX and the things that depend on it, but rather various contortions of trying to keep XXX in the system. Likewise, I have said "aptitude install XXX" and had the first several suggestions include removals of XXX. Seems to me that aptitude should assume that the request the user explicitly made has priority over other things. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Aptitude question
On Sat, Jan 07, 2006 at 12:51:55AM +0100, Jiří Paleček <[EMAIL PROTECTED]> was heard to say: > On Wed, 04 Jan 2006 19:50:14 +0100, Linas Zvirblis <[EMAIL PROTECTED]> > wrote: > > >Jiri Palecek wrote: > >>How does aptitude decide which one to choose? Shouldn't it > >>prefer to do something that won't break other packages? Or should > >>it ask the user for help? > > >As for your problem, you must provide way more information than just "it > >does not work" in order to get help. There are at least five different > >versions of aptitude you could be using on whatever version of Debian > >you use. Most of us cannot read minds, especially over the Internet. > > If you had read (at least the written protion of) my mind more carefully, > you would realize that I have never said "it does not work". I thought it > more as a feature request (or idea) than bug report. I was asking about > how is aptitude supposed to solve such situations, beacuse it isn't clear > if it really should try to guess the correct packages to install. The problem is that of the five versions Linas referred to, there are at least two separate ways of resolving such situations, which are likely to behave differently in your case. > Then, try to install "A". This will, in my version of aptitude > (0.2.15.9-7), > breaks package "D". However, the constraints are satisfiable by downgrading > package "B". The version in unstable (0.4.*) can calculate every (interesting) solution to a given dependency problem [0] and will show as many as you ask for. > As you had already noted, it greatly depends on the particular system (you > don't wanna read my /var/lib/dpkg/available and status, do you?). I thought > it more as an illustrative example. Actually, I often end up loading other people's system state files in the course of bug-hunting. Daniel [0] alert readers will note that the caveat "if the user waits for a sufficient amount of time" has to be added here; however, this is typically much less than one second per solution on my hardware. signature.asc Description: Digital signature
Re: APT public key updates?
* Florian Weimer ([EMAIL PROTECTED]) [060106 11:56]: > * Bernd Eckenfels: > > >> IOW using the old key to sign the new key only requires that the old > >> key be "good" at one point during the new year, whereas continuing to > >> use the old key requires that it be "good" all year. > > > > Yes, but it breaks a long term usage like web of trust. > > The Debian archive key does not take part in the web of trust. > Anybody who has passed the OpenPGP NM checks should not sign that key. I disagree. There are people who have first-hand knowledge that this key is used for the usage written in the key id, i.e. sign the debian archive. These people can IMHO sign the key. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
* Steve Langasek ([EMAIL PROTECTED]) [060106 13:05]: > The exposure of the archive key is higher, because it sits on an > Internet-connected, ssh-accessible server. Also, you don't have to trust > AJ's key; in contrast with Florian's assessment of the NM-suitability of the > three ftpmasters, one ftp assistant, and one RM who have signed this key so > far :), I would encourage you to log into merkel and verify, directly and > securely, the key at /org/ftp.debian.org/web/ziyi_key_2006.asc; sign it; and > upload your signature to the public keyservers as well, if you are satisfied > that this is the key that is being used on ftp-master.debian.org to sign the > archive. I disagree with that - having this key sitting on merkel means nothing. Checking the configuration on /org/ftp.d.o/katie/katie.conf and the keyring ziyi uses on ftp-master (i.e. spohr) means something. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Powerfulness (was: tioga : a powerful plotting system in ruby)
* Vincent Fourmond <[EMAIL PROTECTED]> [060107 14:13]: > Description : tioga : a powerful plotting system in ruby First of all: This is not against you, Vincent. :-) I am just wondering if we shouldn't be more chary of using meaningless (or soliciting) phrases like "powerful" in package descriptions in general. According to their package descriptions, we seem to have exactly six powerful text editors in Debian. These are elvis, jove, mined, ne, nedit and zed. Emacs, vim and many others do not belong to them. Does that mean these are less powerful than the powerful ones? Best regards - Juergen -- GPG A997BA7A | 87FC DA31 5F00 C885 0DC3 E28F BD0D 4B33 A997 BA7A signature.asc Description: Digital signature
Bug#346443: ITP: cue2toc -- converts CUE files to cdrdao's TOC format
Package: wnpp Severity: wishlist Owner: Asheesh Laroia <[EMAIL PROTECTED]> * Package name: cue2toc Version : 0.4 Upstream Author : Matthias Czapla <[EMAIL PROTECTED]> * URL : http://cue2toc.sourceforge.net/ * License : GPL Description : converts CUE files to cdrdao's TOC format cue2toc from http://cue2toc.sourceforge.net/ has features that include support for complete set of CUE commands (e.g. catalog number, data and audio tracks, ISRC codes, CD-Text, Pre-/Postgaps (with zero data or data from file), subindexes etc.), automatic determination of session type and conversion of data files by user configurable commands based on file name extension matching. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-386 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Sat, Jan 07, 2006 at 12:16:36PM +0100, Bernd Eckenfels wrote:
> Paul TBBle Hampson <[EMAIL PROTECTED]> wrote:
>> Maybe the one-true-stable-key idea is the way to go after all...
> One key by distribution?
Well, I meant a different one for each stable, which I guess logically
becomes "yes"...
Although as Steve Langasek has pointed out, the Sarge->Etch upgrade will
be hard unless the etch key becomes available to Sarge users who've not
touched their system since Sarge r0a... I guess this comes down to
making the etch key available in some kind of Sarge-signed repository,
that you have to add as part of the Etch upgrade, and after which
apt-key update will bring you up to Etch key currentness.
Assuming apt-key is supposed to be updating from a file in
debian-keyring, maybe a new dist ("oldstable-upgrade") which really only
contains debian-keyring from (new)stable, but which is signed with the
oldstable key. Then the online upgrade procedure becomes:
Add oldstable-upgrade to your apt-sources
apt-get update
apt-get install -t oldstable-upgrade debian-keyring
apt-key update
apt-get update <== To recheck signatures... I dunno if this is needed?
apt-get dist-upgrade
... time passes
echo "Welcome to etch!"
(Or maybe using aptitude, if that's the recommended upgrade method for
Etch as well...)
I dunno exactly how apt-cdrom works, but maybe it could automatically
pick up that an etch CD has both oldstable-upgrade and stable dists, and
therefore the process for CD upgrades becomes:
apt-cdrom
apt-get install -t oldstable-upgrade debian-keyring
apt-key update
apt-get update <== To recheck signatures... I dunno if this is needed?
apt-get dist-upgrade
... time passes
echo "Welcome to etch!"
You'll still get complaints during apt-get update the first time, but
the apt-get install at least won't try to reject debian-keyring for
being unsigned, because _it_ is signed with a known signature.
For the intervening time, security updates and rX releases thereof allow
for stable key rollover as needed, either yearly or when compromised.
This way oldstable-upgrade gets rolled-away with the rest of oldstable,
and isn't part of oldstable per se and so doesn't complicate security
updates or whatnot, and is easy to include on the first CD of the new
release for upgraders.
And the (new) stable key is therefore (transitively) signed with the
oldstable key, maintaining the chain of trust, without actually having
to muck about with gpg signatures.
--
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]
"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"
License: http://creativecommons.org/licenses/by/2.1/au/
---
pgpmtyYZ9NeHj.pgp
Description: PGP signature
Re: APT public key updates?
[Paul TBBle Hampson] > Although as Steve Langasek has pointed out, the Sarge->Etch upgrade > will be hard unless the etch key becomes available to Sarge users > who've not touched their system since Sarge r0a... I guess this comes > down to making the etch key available in some kind of Sarge-signed > repository Do sarge systems verify the archive key anyway? I thought apt 0.5.28 didn't. But for etch moving forward, I like the ideas I've heard so far about release keys: 1) One key per stable release. The key is generated a month or so before the release, however long is needed to ensure that it be shipped in d-i. This key is then used for the entire length that that release is supported (thus the archive is signed by the keys from both stable and oldstable) - in practice I guess the overlap goes a year or so. 2) The per-release key obviously can't expire exactly when it should, since the release cycle isn't completely predictable, to put it mildly. It might be set to live 4 years or so, and can be revoked later as "superceded". 3) Separate keys for other archives - all of the above applies to security, volatile, and amd64 as well. (Unless amd64 makes it to ftp.debian.org before etch.) signature.asc Description: Digital signature
Re: Need for launchpad
On Fri, Jan 06, 2006 at 03:19:42PM -0500, Frans Jessop wrote: > Ubuntu's launchpad is amazing. Do you think it would be helpful if all > DD's worked through it on their projects? Wouldn't that keep things more > organized and efficient? Or perhaps Debian could build its own version of > launchpad which is better. Again, I think it would do a good job keeping > everything organized an efficient. The day when working on Debian requires the use of a web interface will be the day that I hunt down and painfully kill the person responsible for doing it. Removing the ability to manage things from the shell would not be more organised and efficient unless you're a complete fricking moron who can't operate a unix host. Which appears to be the target audience of launchpad. We're working with the real stuff here, not kids toys. Web interfaces don't scale to the level at which we have to work *all the time*. Just ask the BTS admins what happens when somebody scans http://bugs.debian.org/ to collect data. Oh, and hey - when SuSE are doing better than you at publishing the tools they use, it's a hint that maybe you suck. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Powerfulness (was: tioga : a powerful plotting system in ruby)
On Sat, 2006-01-07 at 23:52 +0100, Juergen Salk wrote: > I am just wondering if we shouldn't be more chary of using > meaningless (or soliciting) phrases like "powerful" in > package descriptions in general. Sounds like something that should be added to lintian. I suggest filing a wishlist bug with a patch. I recently made a lintian patch to check for best-practice homepages in the description field, which was easy, just modify checks/description and checks/description.desc. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: APT public key updates?
Paul TBBle Hampson <[EMAIL PROTECTED]> wrote: > Although as Steve Langasek has pointed out, the Sarge->Etch upgrade will > be hard unless the etch key becomes available to Sarge users who've not > touched their system since Sarge r0a... I guess this comes down to > making the etch key available in some kind of Sarge-signed repository, > that you have to add as part of the Etch upgrade, and after which > apt-key update will bring you up to Etch key currentness. I dont see a problem in requiring the user to get the key from the debian homepage whenever they want to verify a different distribution. What you can du is to have a Debian CA key, if you want to ship a trust anchor with the archives, but I dont see a need for it, since you need to verify it with other means anyway. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
