Re: APT public key updates?
Anthony Towns writes: > 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. Lol, and we've seen that this week. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
Anthony Towns writes: > No, a key is only as good as (a) how hard it is to break; and (b) how > easy it is to trust. Key rotation helps make it harder to break (since > the 2004 key won't do you much good now); and also forces us to consider > how to make new keys easy to trust, which we otherwise might neglect. Looking at the parenthesis: the 2004 key would have been quite valuable a week ago. It could have been used to sign a fake 2005 key. Oh wait: *it still can be*. And once the 2004 key expires, that should mean that now I have no reason to trust the 2005 key. (Except for the fact that it's signed by AJT. But then, why not just use that as the archive key directly?) > So you need something more than just "I trust AJ". No one's worked out > exactly what that should be yet. Yeah. I don't mean that rotation is bad, just that it seems at best only one small part of the puzzle, and it's not clear to me what the other parts should look like. Still, we can only put the puzzle together one piece at a time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
init scripts and the "reload" target
heyo, a while back, i noticed that there seems to be some rather inconsistent behaviour wrt doing "/etc/init.d/foo reload". typically this results in a HUP or something similar sent to the daemon in question, causing it to reload configuration, but in some cases the init script's actions are identical to what would happen with the "restart" target. as a result, there is an interesting variety of results observed when the service in question is not running. sometimes reload will fail with a non-zero value (lsb-compliant packages, i believe), sometimes it will exit normally without performing any action (apache 1.x for example), and in other cases it will start the inactive service (apache 2.x, for example). so sayeth policy 9.3.2: restart stop and restart the service if it's already running, otherwise start the service reload cause the configuration of the service to be reloaded without actually stopping and restarting the service, force-reload cause the configuration to be reloaded if the service supports this, otherwise restart the service. The start, stop, restart, and force-reload options should be supported by all scripts in /etc/init.d, the reload option is optional. my take on this is that, while optional, the reload target must not stop and start a service if implemented in an init script. it would then logically follow that reload must not start a service which is not running. is my interpretation of this correct, or am i over-analyzing things? thanks, sean -- signature.asc Description: Digital signature
Re: Bug#345977: ITP: polld -- Polling demon
On Wed, Jan 04, 2006 at 11:29:07AM -0600, Nathan Poznick wrote: > Thus spake Roger Leigh: > > What is the problem this is trying to solve? > > > > If the partition table is being changed, the tool that changed it > > should issue a BLKRRPART ioctl, like fdisk does for example (see > > ). > > I have a USB card reader which has 5 different slots for various media. > If I plug in the card reader and then later insert a CF card, the CF > card slot's device does not have the partition device created when using > udev (I have to insert the CF card and then plug in the card reader). I Works fine here... /dev/sdc is created when the card reader is plugged in, and /dev/sdc1 is created when I plug in a card. No ugliness required. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- 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 12:12:50AM -0800, Thomas Bushnell BSG wrote:
> Anthony Towns writes:
> > No, a key is only as good as (a) how hard it is to break; and (b) how
> > easy it is to trust. Key rotation helps make it harder to break (since
> > the 2004 key won't do you much good now); and also forces us to consider
> > how to make new keys easy to trust, which we otherwise might neglect.
> Looking at the parenthesis: the 2004 key would have been quite
> valuable a week ago. It could have been used to sign a fake 2005 key.
> Oh wait: *it still can be*.
It shouldn't be, since the 2004 key expired almost a year ago. Maybe we
should be revoking expired keys as well.
> And once the 2004 key expires, that
> should mean that now I have no reason to trust the 2005 key.
Sure you do: it's already on your disk.
> (Except
> for the fact that it's signed by AJT. But then, why not just use that
> as the archive key directly?)
Because the archive key signs things automatically, and I'm not uploading
my secret key to ftp-master and putting the passphrase into a script.
Perhaps there are five phases we need to consider:
(a) key is published, available for signing by developers, but unused
(b) key is used to sign archive, along with previous key
(c) key is used to sign archive alone
(d) key is used to sign archive, along with next key
(e) key is expired and/or revoked
Any of those could be zero length. (a) might be useful for out of band
authentication ("I trust AJ", "my book says the fingerprint should
be..."); (b)/(d) is useful for transitioning to new keys. At the moment
(b) and (d) are around one month windows, maybe they should be longer.
Cheers,
aj
signature.asc
Description: Digital signature
Re: init scripts and the "reload" target
On Fri, Jan 06, 2006 at 03:19:58AM -0500, sean finney wrote: > a while back, i noticed that there seems to be some rather inconsistent > behaviour wrt doing "/etc/init.d/foo reload". > > typically this results in a HUP or something similar sent to the daemon in > question, causing it to reload configuration, but in some cases the > init script's actions are identical to what would happen with the > "restart" target. [..] > reload > > cause the configuration of the service to be reloaded without > actually stopping and restarting the service, [..] > my take on this is that, while optional, the reload target must not > stop and start a service if implemented in an init script. it would > then logically follow that reload must not start a service which is > not running. > > is my interpretation of this correct, or am i over-analyzing things? I agree with your interpretation... and believe that most init.d scripts behave this way. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get search?
hello, what is database searching apt package ? #apt-cache search packet +-+-+-+ BEGIN PGP SIGNATURE +-+-+-+ Version: GnuPG v1.4.2 (GNU/Linux) .-. .-._ : : : : :_; .-' : .--. : `-. .-. .--. ,-.,-. ' .; :' '_.'' .; :: :' .; ; : ,. : `.__.'`.__.'`.__.':_;`.__,_;:_;:_; Kai "Ozgur" Geek Network Engineer PGP ID: B1B63B6E +-+-+-+ END PGP SIGNATURE +-+-+-+ -- ___ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze
Re: What's the best directory to put a local Debian repository?
Maurits van Rees wrote: > I'm wondering what the best place is to put a local Debian package > repository. Directories that spring to mind are: > > - /var/www/debian > > This eases access via e.g. Apache (though a soft link here to > another dir would work fine as well of course) > > - /srv/debian > > According to the Filesystem Hierarchy Standard the /srv dir is for > Data for services provided by this system, which seems to fit the > bill. > Since I'm using reprepro for local repositories, I'm using /srv/reprepro/ (And I also symlinked /var/www to /srv/www ...) Regards, Stan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Experimental or unstable.
On Fri, Jan 06, 2006 at 10:11:55AM +1000, Anthony Towns wrote: > On Thu, Jan 05, 2006 at 02:03:37PM +, Simon Huggins wrote: > > Is there any better way I can get snapshots/betas tested by the > > majority of users? Do people think that this is the sort of thing > > that should just be uploaded to unstable and allowed to flow into > > testing? > Provided you're willing/able to fix bugs that are found directly, not > just by reverting to the previous version, yeah, pretty much... Yeah. I suspect in the case I'm thinking of (xfce) that they aren't really close enough to the end of their dev cycle for this to be justified and I'm not just talking about one package so it gets harder still to support. (Anyone wanting to help in general with xfce.*plugin is most welcome over on the pkg-xfce alioth project... :)) I suppose it'll have to be experimental and then suffer the bug reports when it finally hits unstable when it's in a usable state. But yeah, I take the point that in general if it's only one package and you're going to stick with it then unstable is better as long as you are responsive. Simon -- ... Granny sighed. "Gytha, Greebo would like Norris the Eyeball-Eating Maniac of Quirm if he knew how to put food in a bowl." signature.asc Description: Digital signature
Re: APT public key updates?
* Michael Vogt: > Sorry for the delay. I'm preparing a new upload that adds the 2006 > archive key to the default keyring. Please try to get a new self-signature without an expiration data first. If they key is compromised, it has to be (manually) revoked anyway. Rotating it once per year doesn't make sense. At the very least, change the expiration data so that it doesn't fall into the holiday season. For stable, an offline key could be used. Maybe for stable-security, too. However, I don't think it's worth the trouble. If the key material is compromised because it is only, the attacker has already reached very central piece of Debian's infrastructure, and we lose even if the actual key material is stored off-line. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
* 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
* Steve Langasek: > For a user with a compromised local network, the only safe solution is to > validate the new key via some web of trust. No, the web of trust doesn't solve the problem. I'm pretty sure most DDs don't even know who is authorized to issue a new archive key. A user has no way to judge which developers have sufficient knowledge to recognize a new, legitimate archive signing key. And so on, it's quite messy. The only reasonable answer at this stage is SSH-style "leap of faith" authentication. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Bug#344758: init.d script should create /var/run/dirmngr
On Thu, 05 Jan 2006, Steve Langasek wrote: > > > > BUT, if you do, don't ship /var/run inside the deb. > > > Why? > > > Because: > > > 1. It will go away on reboot and if your service isn't enabled, it won't > > be re-created. dpkg will still think it should be there, however. > > And what does that break? AFAIK, dpkg will ignore a missing directory on > package removal without incident. Well, it is not good form. If you want to ship it there, be my guest. But don't expect me to tell others to ship it _unless_ there is a real reason to do so, and so far there isn't (there might be one in the future). > > 2. We may deploy some auto-create-stuff-in-/var/run solution, and it WILL > > clash with packages that ship /var/run and recreate it (not that I'd > > expect that clash to do anything other than mkdir -p be a waste of > > time -- but better safe than sorry). > The /var/run directory itself *must* always exist; it has to be on the > filesystem which holds /var. Yes. But that has nothing to do with packages shipping stuff inside /var/run (plus /var/run itself), does it? > > Also, it makes life easier for us to track down packages that need to be > > examined for lack of ephemeral /var/run support. > > I think you're going to need a more reliable test than this. Probably. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: init scripts and the "reload" target
On Fri, 06 Jan 2006, sean finney wrote: > fail with a non-zero value (lsb-compliant packages, i believe), sometimes > it will exit normally without performing any action (apache 1.x for > example), and in other cases it will start the inactive service (apache 2.x, > for example). Please file bugs, severity serious. These packages are broken if they are doing what you describe. In fact, restarting an inactive service on reload is so utterly broken it ain't funny. > my take on this is that, while optional, the reload target must not > stop and start a service if implemented in an init script. it would Correct. That's why many services do _not_ implement reload (because they don't support the functionality, really). And if you don't implement it, you bang out with an error so that whomever called knows you didn't grok what they told you to do in the initscript. > then logically follow that reload must not start a service which is > not running. Also correct. Force-reload is muddy waters, and it will often restart services (truth to be told, it shouldn't but I doubt it will be fixed), but anything restarting or starting services on reload is buggy, and non-compliant to Debian policy. > is my interpretation of this correct, or am i over-analyzing things? It is correct, AFAIK. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Thu, Jan 05, 2006 at 11:15:08PM -0800, Thomas Bushnell BSG wrote: > >> If the key is compromised, which is the only way the non-expiring key > >> method can be broken, then the expiring key doesn't seem to be > >> offering all that much additional security. > > Indeed it doesn't. Ideally, if the previous key has been compromised, users > > would be verifying the integrity of the new key using other signatures; but > > in the worst case, verifying using the signature from the previous key (if > > they're disconnected from the web of trust) is no worse than not being able > > to verify it at all. > I think I now understand better, and I can better express the > uncertainty I was groping at. A key is only as good as the keys that > sign it. The reason for rotating the key is that there is some > non-zero risk that it will be compromised, and this limits exposure. > But in order to validate the new key, which is only as good as its > signatures, I must rely on whatever signs the new key. > I trust AJ. So I trust AJ to sign the new key correctly. Surely, it > seems to me, the risk of AJ allowing his own key to be compromised is > just about the same as the risk of his allowing the archive key to be > compromised. What am I missing? 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. You should *only* do this if you're satisfied that the presence of this file in the mirror on merkel is adequate evidence that it's the same key in use on ftp-master. So trusting that the ssh host key of merkel is authentic, trusting that someone hasn't compromised both merkel and your network (pushing matching, invalid keys to you via merkel and a MITM of http://ftp-master.debian.org), and trusting that the propagation from ftp-master to merkel is secure. -- 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: Fwd: Bug#344758: init.d script should create /var/run/dirmngr
On Fri, Jan 06, 2006 at 09:44:35AM -0200, Henrique de Moraes Holschuh wrote: > On Thu, 05 Jan 2006, Steve Langasek wrote: > > > > > BUT, if you do, don't ship /var/run inside the deb. > > > > Why? > > > Because: > > > 1. It will go away on reboot and if your service isn't enabled, it won't > > > be re-created. dpkg will still think it should be there, however. > > And what does that break? AFAIK, dpkg will ignore a missing directory on > > package removal without incident. > Well, it is not good form. If you want to ship it there, be my guest. But > don't expect me to tell others to ship it _unless_ there is a real reason to > do so, and so far there isn't (there might be one in the future). That's fine; I'm just saying that there's not much point in telling people to *not* ship /var/run (or subdirectories thereof) in their package. 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: Fwd: Bug#344758: init.d script should create /var/run/dirmngr
[Steve Langasek] > That's fine; I'm just saying that there's not much point in telling > people to *not* ship /var/run (or subdirectories thereof) in their > package. Hmm, it should be noted that if you do remove /var/run/foo from your package, you need to make sure the postrm deletes the directory in 'purge'. (Though in the glorious future when /var/run can be *completely* cleared at boot time, this won't be so important.) Then again, I guess packages already have to make sure to delete stuff inside /var/run/foo, on purge, lest dpkg declare itself unwilling to remove the non-empty directory. signature.asc Description: Digital signature
Re: APT public key updates?
* Steve Langasek: > 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. Or publish a statement, maybe signed with your OpenPGP key, that the key 1024D/2D230C5F, fingerprint 084750FC01A6D388A643D869010908312D230C5F is the 2006 Debian archive key. This conveys more information than a certifying signature, and avoids the problem how you got physical ID for "Debian Archive Automatic Signing Key (2006) <[EMAIL PROTECTED]>", or a verification that the keyholder actually reads the mailbox mentioned in the user ID. 8-) -- 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 02:04:49PM +0100, Florian Weimer wrote: > * Steve Langasek: > > 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. > Or publish a statement, maybe signed with your OpenPGP key, that the key > 1024D/2D230C5F, fingerprint 084750FC01A6D388A643D869010908312D230C5F > is the 2006 Debian archive key. > This conveys more information than a certifying signature, and avoids > the problem how you got physical ID for "Debian Archive Automatic > Signing Key (2006) <[EMAIL PROTECTED]>", or a verification that the > keyholder actually reads the mailbox mentioned in the user ID. 8-) Yes, that's also reasonable, although the downside is a lack of good distribution channel for such a signed statement -- key signatures you can throw at any keyserver and they'll stick. :) -- 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:
Hello, Mary Helen schrieb: > Please remove me from Call Wave. I now have a cable connection and no > longer require the service. You have reached the Debian project, which is in no way in the business of selling Internet services. I presume you reached us because you searched for the words "callwave remove" or similar. This is one of the cases where combining two fairly useful technologies (search engines and publically archived mailing lists) combined yield unwanted behaviour, namely our mailing list archives being in the #1 spot due to postings, and new postings because we're in the #1 spot. You can find a summary of instructions at http://lists.debian.org/debian-devel/2005/01/msg01444.html Simon signature.asc Description: OpenPGP digital signature
Re: APT public key updates?
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? -- see shy jo [1] As is, for example, supposed to happen a month or so after etch is released. signature.asc Description: Digital signature
Re: bits from the release team
On Thu, Jan 05, 2006 at 10:59:45AM -0500, David Nusinow wrote: > On Thu, Jan 05, 2006 at 02:40:45PM +0100, Marc Haber wrote: >> On Wed, 04 Jan 2006 14:25:17 +0100, Josselin Mouette <[EMAIL PROTECTED]> >> wrote: > >>Unstable means dependencies can be broken, not that packages themselves > >>can always broken. Each and every single package uploaded to unstable > >>should be of release quality. Otherwise, it should go to experimental. >> >> Experience with adduser shows that no-one besides the maintainers >> themselves and their closest environment uses experimental packages. > I got a fairly large number of testers of Xorg 6.9 while it was in > experimental. Not enough to catch all the bugs by any means, but I got at > least some feedback. Then again, Xorg is special in that people with newer > hardware often need the updates. I think this (like OpenOffice and tetex) are good examples of where experimental works well. Large, important packages which have a group of users who want to try the latest (pre-release or pre-packaging) of the software. Because I've been futzing with r300 dri and bcm43xx support on my powerbook, I've been playing with X.org and linux-2.6 from experimental, although the requisite versions of both have now filtered into unstable as it happens. If I was doing any tex work at the time, I'd prolly have pulled the tetex 3 beta from experimental too. I did fetch OpenOffice 1.9, but never actually ran it. ^_^ The big advantage of experimental over external apt repositories is it shows up on packages.debian.org and apt-cache (without having to add anything more than experimental). I don't futz with experimental on my server, since its also my build machine and I don't want to accidentally drag in a library or something from experimental... Although this is mitigated by using pbuilder-uml for my actual archive-upload builds. If and when I achieve DD-status, I intend to put snapshots of FreeRADIUS 2.0's CVS into experimental for people to try out, and so I can see if the autobuilders will wear it. This way the parallel FreeRADIUS 1.1 series can keep going into unstable and migrating to testing until 2.x is actually ready to ship. I don't mind so much if no one actually downloads it, since it does provide a low-priority buildd setup, and a place to point people who _do_ ask about that sort of thing. -- --- 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/ --- pgp5ffkov4xRo.pgp Description: PGP signature
Re: APT public key updates?
On Fri, 06 Jan 2006, Steve Langasek wrote: > Yes, that's also reasonable, although the downside is a lack of good > distribution channel for such a signed statement -- key signatures you can > throw at any keyserver and they'll stick. :) [EMAIL PROTECTED] is a proper channel for such announcements as far as humans go. And I don't mean [EMAIL PROTECTED], I mean [EMAIL PROTECTED] OTOH, it would be nice to have automated key rollover working :) But I understand it is being worked on. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Fri, Jan 06, 2006 at 08:21:14AM -0500, Joey Hess wrote: > 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]? On January 1 (or whenever a new key is issued) do a security update for stable on the package that has the keyring. > [1] As is, for example, supposed to happen a month or so after etch is > released. In this case we (well, not me...) can issue a new key that is valid from november 2006 (a month before etch is released) till october 2007. Use that key to sign the packages. Then the first year there will be no problems, unless the key is compromised. -- Maurits van Rees | http://maurits.vanrees.org/ [NL] Work | http://zestsoftware.nl/ GnuPG key | http://maurits.vanrees.org/var/gpgkey.asc "Do only what only you can do." --- Edsger Wybe Dijkstra signature.asc Description: Digital signature
Bug#346216: ITP: ussp-push -- OBEX PUSH file transfer program
Package: wnpp Severity: wishlist Owner: Simon Richter <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: ussp-push Version : 0.5 Upstream Author : Davide Libenzi * URL : http://www.xmailserver.org/ussp-push.html * License : GPL Description : OBEX PUSH file transfer program This program allows you to send objects using the OBEX PUSH protocol. The OBEX PUSH protocol is used to transfer files to a mobile device, generally via Bluetooth or IrDA. THe protocol does not allow any other action than sending and generally requires less strict authentication, which is why it is sometimes preferred to the OBEX FTP protocol (which allows full filesystem access and is provided by the obexftp package). - -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (50, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-powerpc Locale: LANG=de_DE.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iQCVAwUBQ75yJ1Yr4CN7gCINAQLQZAP/f3iLEGngFviV91AAy97uO3lhOXBHqxCp iTbYnVHByWSp0Q1+IcecPYveMbOTwrc7pd2iaQnoPeOakfKXbJl0pXiC6VYFbQNO 1iimuLlSOWwrFGhVEn3eigCoYEDqQq1CXx15ZRm+HK10/l++x+SzyyqmKxEAYYZP A3SP8rZ5UcQ= =4DGe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Experiment: poll on "switching to vim-tiny for standard vi?"
On 05-Jan-06, 14:20 (CST), paddy <[EMAIL PROTECTED]> wrote: > > Maybe I have the wrong end of the stick. > > I was thinking that if you wanted another possible behaviour: > say that optional packages don't overide important ones unless explicitly > set that way, then you could set that policy globally. Then the whole update-alternatives priority system is made pointless. Part of our job as maintainers and distributors is to make choices, so that *most* of our users don't have to. Then we generally provide a way to override those choices, for the remainder, who disagree with a particular choice or have a particular situation that is not covered by our choice. The choice we made many years ago for alternative priorities was based on these presumptions: A. Most people wouldn't care which of the alternative packages was installed so long as it provided the basic funtionality. B. Of those who cared to install on of the variants, most would want to use the variant by default; after all, that's why they installed the variant. C. The 1% not covered by A and B can use update-alternatives to set their preferred version. Remember that people in class C are probably in class C *only* for one particular alternative, and are perfectly happy with the all the others. This is really a corner case, and while one should provide for corner cases, one probably shouldn't design around corner cases. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345977: ITP: polld -- Polling demon
On Fri, 2006-01-06 at 19:24 +1100, Hamish Moffatt wrote: > On Wed, Jan 04, 2006 at 11:29:07AM -0600, Nathan Poznick wrote: > > Thus spake Roger Leigh: > > > What is the problem this is trying to solve? > > > > > > If the partition table is being changed, the tool that changed it > > > should issue a BLKRRPART ioctl, like fdisk does for example (see > > > ). > > > > I have a USB card reader which has 5 different slots for various media. > > If I plug in the card reader and then later insert a CF card, the CF > > card slot's device does not have the partition device created when using > > udev (I have to insert the CF card and then plug in the card reader). I > > Works fine here... /dev/sdc is created when the card reader is plugged > in, and /dev/sdc1 is created when I plug in a card. No ugliness > required. But when you remove that (SD, for example) card, and plug in a different type of card (CF, for example), does the kernel notice? -- - Ron Johnson, Jr. Jefferson, LA USA "If you don't know how to do something, you don't know how to do it with a computer." Anonymous -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Clogs on packages going into etch cleared!
Amazing! ghc6 is now the top blocker for packages entering testing, and it's only keeping 15 packages out of testing! Hooray! Now to fix those ~= 400 RC bugs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
Maurits van Rees wrote: > On Fri, Jan 06, 2006 at 08:21:14AM -0500, Joey Hess wrote: > > 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]? > > On January 1 (or whenever a new key is issued) do a security update > for stable on the package that has the keyring. That doesn't address most of the issues I raised. Just for example, debootstrap in d-i would not see the new key. -- see shy jo signature.asc Description: Digital signature
Re: apt-get search?
Kai Geek wrote: > hello, > what is database searching apt package ? > #apt-cache search packet Judging by the output of "strace apt-cache search packet", one or more of the following: /var/cache/apt/pkgcache.bin /var/lib/apt/lists/* /var/lib/dpkg/status regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Experiment: poll on "switching to vim-tiny for standard vi?"
On Fri, Jan 06, 2006 at 07:43:07AM -0600, Steve Greenland wrote: > On 05-Jan-06, 14:20 (CST), paddy <[EMAIL PROTECTED]> wrote: > > > > Maybe I have the wrong end of the stick. > > > > I was thinking that if you wanted another possible behaviour: > > say that optional packages don't overide important ones unless explicitly > > set that way, then you could set that policy globally. > > Then the whole update-alternatives priority system is made pointless. s/pointless/better/ ;) > Part of our job as maintainers and distributors is to make choices, so > that *most* of our users don't have to. Then we generally provide a > way to override those choices, for the remainder, who disagree with a > particular choice or have a particular situation that is not covered by > our choice. and this would be just such an override, surely ? > The choice we made many years ago for alternative priorities was based > on these presumptions: > > A. Most people wouldn't care which of the alternative packages was > installed so long as it provided the basic funtionality. > > B. Of those who cared to install on of the variants, most would want to > use the variant by default; after all, that's why they installed the > variant. > > C. The 1% not covered by A and B can use update-alternatives to set > their preferred version. Understood, but it doesn't seem to answer my questions. > Remember that people in class C are probably in class C *only* for one > particular alternative, and are perfectly happy with the all the others. okay so this is "noone ever wants to do that" what about the delegated package installation example ? Is that similarly flawed ? I'm sorry to keep asking so many dumb questions, but would such a facility make things any harder for maintainers ? (I have no trouble imagining that it might, but I'm not familiar with the details) > This is really a corner case, and while one should provide for corner > cases, one probably shouldn't design around corner cases. As I've tried very hard to indicate, I'm not clear on what the implications would be, but I was kinda hoping that it might be a no-brainer, rather than a design decision. I'm still no clearer on that :( Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is mesa actually maintained?
Hello! This is one of 5 RC bugs, apparently with no maintainer response. Apparently the list which is listed as the maintainer is rejecting messages (336752), which probably contributes to the problem. Hence the Cc: to debian-devel. This bug is trivial to fix, and because it prevents mesa from building, it's preventing tulip from being built at all. 341479 prevents tulip from being built too. I only noticed this because I'm trying to get the C++ allocator transition finished, which tulip is involved in. So, um, any chance of any progress? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Experimental or unstable.
[ Please CC me: I have problems keeping up with debian-devel's traffic ] On 05/01/06 at 17:29 +0100, Nicolas François wrote: > Is there a command that can display the list of packages I'm using with a > version on experimental higher than the current version on unstable? You can use MultiDistroTools[0] for this. I just generated a report[1] with all of experimental (other reports[2] might be of interest too, but are more Ubuntu-specific). It's quite easy to filter the list with your installed packages by modifying the script. Note that MultiDistroTools is not in Debian yet , and I'll be looking for a sponsor shortly. If somebody is interested, drop me a note ;) [0] https://wiki.ubuntu.com/MultiDistroTools [1] http://tiber.tauware.de/~lucas/versions/unstable-experimental.html [2] http://tiber.tauware.de/~lucas/versions/ -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[344032] bugfix for: bbdb: File error: "Cannot open load file", "bbdb-autoloads"
Hi all,
1.
The installation of bbdb fails due to a bug in
/usr/share/emacs/site-lisp/bbdb/lisp/Makefile
The single quotes make the ending backslashes show up in the lisp code passed
to emacs.
2.
The real problem is, that the install continues after throwing an error.
fix for 1.
debian:/usr/share/emacs/site-lisp/bbdb/lisp# diff -u Makefile.dist Makefile
--- Makefile.dist 2006-01-06 15:47:30.0 +0100
+++ Makefile2006-01-06 15:48:09.0 +0100
@@ -154,10 +154,10 @@
bbdb-hooks.elc: bbdb.elc bbdb-hooks.el
@$(EMACS_PROG) -batch -q $(PUSHPATH) -l ./bbdb.elc \
- -eval '(and (not (string= "$(VMDIR)" "")) \
- (setq load-path (cons "$(VMDIR)" load-path)) \
- (load "vm" t t) \
- (load "vm-vars" t t))' \
+ -eval "(and (not (string= \"$(VMDIR)\" \"\")) \
+ (setq load-path (cons \"$(VMDIR)\" load-path)) \
+ (load \"vm\" t t) \
+ (load \"vm-vars\" t t))" \
-f batch-byte-compile $(@:.elc=.el)
autoloads: bbdb-autoloads.el
This probably closes #345186 and #345297, too.
For 2. I don't have an answer, but look at this excerpt from
/usr/share/${FLAVOUR}/site-lisp/bbdb/CompilationLog.gz
indented and edited for readability
Generating bbdb-autoloads
cd lisp; make autoloads
make[1]: Entering directory `/usr/share/emacs-snapshot/site-lisp/bbdb/lisp'
...
Generating autoloads for bbdb.el...
Generating autoloads for bbdb.el...done
Wrote /usr/share/emacs-snapshot/site-lisp/bbdb/lisp/bbdb-autoloads.el
make[1]: Leaving directory `/usr/share/emacs-snapshot/site-lisp/bbdb/lisp'
cd lisp; make rmail
make[1]: Entering directory `/usr/share/emacs-snapshot/site-lisp/bbdb/lisp'
Loading 00debian-vars...
...
Loading 50bbdb (source)...
...
Wrote /usr/share/emacs-snapshot/site-lisp/bbdb/lisp/bbdb.elc
...
Loading 50bbdb (source)...
...
Wrote /usr/share/emacs-snapshot/site-lisp/bbdb/lisp/bbdb-com.elc
...
Loading 50bbdb (source)...
...
Symbol's value as variable is void: \
make[1]: *** [bbdb-hooks.elc] Error 255
make[1]: Leaving directory `/usr/share/emacs-snapshot/site-lisp/bbdb/lisp'
make: *** [rmail] Error 2
At this point an error occured, bbdb-hooks.elc is not created, however:
make in this directory stops, but the install-script (? or make) continues ...
...
Loading 50bbdb (source)...
Error while loading 50bbdb
Here the above error shows itself again ? ...
...
Wrote /usr/share/emacs-snapshot/site-lisp/bbdb/bbdb-213-310.elc
Wrote /usr/share/emacs-snapshot/site-lisp/bbdb/bbdb-415-510.elc
In end of data:
bbdb-pilot-jwz.el:584:1:Warning: the following functions are not known to be
defined: bbdb-address-street1, bbdb-address-street2,
bbdb-address-street3,
bbdb-parse-phone-number, bbdb-parse-zip-string,
bbdb-address-set-street1,
bbdb-address-set-street2, bbdb-address-set-street3
Wrote /usr/share/emacs-snapshot/site-lisp/bbdb/bbdb-pilot-jwz.elc
In bbdb-to-netscape:
bbdb-to-netscape.el:80:24:Warning: reference to free variable
`bbdb-define-all-aliases-field'
In end of data:
bbdb-to-netscape.el:213:1:Warning: the following functions are not known to
be
defined: bbdb-search, bbdb-address-street1, bbdb-address-street2,
bbdb-address-street3
Wrote /usr/share/emacs-snapshot/site-lisp/bbdb/bbdb-to-netscape.elc
*** installing not-compiled bbdb-gnus.el ***
install -m 644 /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-gnus.el
/usr/share/emacs-snapshot/site-lisp/bbdb
At this point the Logfile ends, but is it complete?
Cheers,
Erich
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
Florian Weimer <[EMAIL PROTECTED]> wrote: >> 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. Thats right, I was not refering to the usage as archive key, it was a general comment about trust concepts for key validation. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Experiment: poll on "switching to vim-tiny for standard vi?"
On 06-Jan-06, 08:28 (CST), paddy <[EMAIL PROTECTED]> wrote: > On Fri, Jan 06, 2006 at 07:43:07AM -0600, Steve Greenland wrote: > > Then the whole update-alternatives priority system is made pointless. > > s/pointless/better/ How? If you provide the ability to determine alternative selection based on package priority (Important/Standard/Optional/Extra), why do you need alternative priorities (numerical, set in in package maintainer scripts, locally overridable)? (The fact that we are using the word "priority" to mean two different things is perhaps confusing, which is why I've been trying to distinguish "package priority" and "alternative priority".) > > Part of our job as maintainers and distributors is to make choices, so > > that *most* of our users don't have to. Then we generally provide a > > way to override those choices, for the remainder, who disagree with a > > particular choice or have a particular situation that is not covered by > > our choice. > > and this would be just such an override, surely ? We *already* have an override: it's called 'update-alternative'. Why do we need two? > > Remember that people in class C are probably in class C *only* for one > > particular alternative, and are perfectly happy with the all the others. > > okay so this is "noone ever wants to do that" Sigh. No, it's "most of the time, for most people, our current system defaults in an appropriate manner, and for those rare occasions when it doesn't, we have the tool to override." > I'm sorry to keep asking so many dumb questions, but would such a facility > make things any harder for maintainers ? (I have no trouble imagining that > it might, but I'm not familiar with the details) It makes it harder for maintainers, and it makes it harder for users, because there would then be two completely different ways of overriding default alternative priorities. Which would be dominant? Which is preferred? How do you test all the interactions? > As I've tried very hard to indicate, I'm not clear on what the implications > would be, but I was kinda hoping that it might be a no-brainer, rather > than a design decision. I'm still no clearer on that :( We have a straightforward system that provides a) reasonable default behaviour, and b) a standard way to override the default. I don't see the point in complicating that to provide a solution to a "problem" that has been invented just for this thread, and has *no* outstanding wishlist bug reports. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: net-tools maintenance status
On 12/30/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote: > On 12/22/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote: > > On 12/16/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote: > > > On 12/16/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote: > > > > On Fri, Dec 16, 2005 at 08:03:47PM +0100, Olaf van der Spek wrote: > > > > > Bernd? > > > > > > > > I dont like the prposed solution, i am looking for a more generic one. > > > > The > > > > > > Thanks for the response. > > > In what way would you like it to be more generic? > > > > > > > pressing problem is to display IPV6 netstat on 80char widt correctly > > > > without > > > > truncation (#254243). > > > > > > That's not possible without dropping entire columns. > > > > > > > I guess this will require some changes to the output formatter, anyway. > > > > > > > > I think i will add a non-formatting/non-truncating scritable output > > > > instead > > > > of the wide switch, and make netstat on tty observ cols. The question > > > > is, > > > > what size to use on non-tty output. > > > > Bernd? > > Bernd? Hi Bernd, Could you please respond to this issue? Thanks Olaf
Re: net-tools maintenance status
On 1/6/06, Bernd Eckenfels <[EMAIL PROTECTED]> wrote: > On Fri, Jan 06, 2006 at 05:03:39PM +0100, Olaf van der Spek wrote: > > On 12/30/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote: > > > On 12/22/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote: > > > > On 12/16/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote: > > > > > On 12/16/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote: > > > > > > On Fri, Dec 16, 2005 at 08:03:47PM +0100, Olaf van der Spek wrote: > > > > > > > Bernd? > > > > > > > > > > > > I dont like the prposed solution, i am looking for a more generic > > > > > > one. The > > > > > > > > > > Thanks for the response. > > > > > In what way would you like it to be more generic? > > > > > > > > > > > pressing problem is to display IPV6 netstat on 80char widt > > > > > > correctly without > > > > > > truncation (#254243). > > > > > > > > > > That's not possible without dropping entire columns. > > > > > > > > > > > I guess this will require some changes to the output formatter, > > > > > > anyway. > > > > > > > > > > > > I think i will add a non-formatting/non-truncating scritable output > > > > > > instead > > > > > > of the wide switch, and make netstat on tty observ cols. The > > > > > > question is, > > > > > > what size to use on non-tty output. > > > > > > > > Bernd? > > > > > > Bernd? > > > > Hi Bernd, > > > > Could you please respond to this issue? > > the last question in this thread was from me. Really? > > > > > Thanks for the response. > > > > > In what way would you like it to be more generic? > > > > > That's not possible without dropping entire columns.
Re: APT public key updates?
Joey Hess wrote: > 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? Given that stable is stable, wouldn't it be possible to sign each stable release with a special key kept offline without causing too much trouble? That doesn't solve security updates though, so the key for that would need to be updated as necessary. Alternatively, a two link process with a role key kept offline signing the archive key might be OK as well, but that leaves the question how not to have that key compromised. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: net-tools maintenance status
On Fri, Jan 06, 2006 at 05:03:39PM +0100, Olaf van der Spek wrote: > On 12/30/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote: > > On 12/22/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote: > > > On 12/16/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote: > > > > On 12/16/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote: > > > > > On Fri, Dec 16, 2005 at 08:03:47PM +0100, Olaf van der Spek wrote: > > > > > > Bernd? > > > > > > > > > > I dont like the prposed solution, i am looking for a more generic > > > > > one. The > > > > > > > > Thanks for the response. > > > > In what way would you like it to be more generic? > > > > > > > > > pressing problem is to display IPV6 netstat on 80char widt correctly > > > > > without > > > > > truncation (#254243). > > > > > > > > That's not possible without dropping entire columns. > > > > > > > > > I guess this will require some changes to the output formatter, > > > > > anyway. > > > > > > > > > > I think i will add a non-formatting/non-truncating scritable output > > > > > instead > > > > > of the wide switch, and make netstat on tty observ cols. The question > > > > > is, > > > > > what size to use on non-tty output. > > > > > > Bernd? > > > > Bernd? > > Hi Bernd, > > Could you please respond to this issue? the last question in this thread was from me. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is mesa actually maintained?
On Fri, Jan 06, 2006 at 09:26:33AM -0500, Nathanael Nerode wrote: > Hello! This is one of 5 RC bugs, apparently with no maintainer response. > Apparently the list which is listed as the maintainer is rejecting messages > (336752), which probably contributes to the problem. Hence the Cc: to > debian-devel. > > This bug is trivial to fix, and because it prevents mesa from building, it's > preventing tulip from being built at all. 341479 prevents tulip from being > built too. > > I only noticed this because I'm trying to get the C++ allocator transition > finished, which tulip is involved in. > > So, um, any chance of any progress? Marcelo has pretty much vanished lately, so I'm going to be doing an NMU of mesa soon to bring it up to the point where it can be used for Xorg 7.0. Once that's done, I can start to look at the buglist. I'm not really all that thrilled about the possibility of becoming the mesa maintainer, but right now it looks like my only option if I want to move on modular xorg. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: net-tools maintenance status
On Fri, January 6, 2006 17:03, Olaf van der Spek wrote: > Hi Bernd, > > Could you please respond to this issue? Hello Olaf, Could you please stop this? You've been asking about this for many times now and appearently with no result, so it should occur to you that this stragegy does not work. If you look at Bernd's packages overview (http://qa.debian.org/developer.php?login=ecki) you can see that many of his packages are NMU'ed very regularly. So appearently he doesn't mind that. You could prepare an NMU for the bugs you deem important and upload it to the delayed queue. bye, Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: net-tools maintenance status
On 1/6/06, Thijs Kinkhorst <[EMAIL PROTECTED]> wrote: > On Fri, January 6, 2006 17:03, Olaf van der Spek wrote: > > Hi Bernd, > > > > Could you please respond to this issue? > > Hello Olaf, > > Could you please stop this? You've been asking about this for many times I'd prefer to, but that doesn't look like a solution. > now and appearently with no result, so it should occur to you that this > stragegy does not work. It does appear to result in some response, but with weeks/months separation between each one it's a bit 'slow'. > If you look at Bernd's packages overview > (http://qa.debian.org/developer.php?login=ecki) you can see that many of Which column shows that? > his packages are NMU'ed very regularly. So appearently he doesn't mind > that. You could prepare an NMU for the bugs you deem important and upload > it to the delayed queue. It's a significant change and I'd prefer the maintainer to support the change. I also have no idea how to do an NMU and I think NMUs are not the right solution to this problem.
Re: net-tools maintenance status
On Fri, January 6, 2006 18:25, Olaf van der Spek wrote: >> If you look at Bernd's packages overview >> (http://qa.debian.org/developer.php?login=ecki) you can see that many of > > Which column shows that? It isn't one specific column, but from the overview and with some clicking around I can make the following observations about Bernd's packages. adns - from 2002 until last December no MU's and a couple of NMU's cadaver - current version in testing is NMU from last July ircii - no NMU's libnetwork-ipv4addr-perl - no mu's since the nmu from 2003, no MU's since 2000 memstat - no NMU's (no uploads at all since 2002) mkrboot - sarge contains NMU from 2003 mmv - no MU since 2001, 2 unacked NMU's in August net-acct - no NMU's (no uploads at all since 2004) net-tools - had an occasional NMU symlinks - last MU in 2000, NMU's in 2003 and 2005 unacked transproxy - no NMU's (no uploads at all since 2003) So I think you can tell pretty clearly that Bernd has no objection at all to NMU's. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Rising Stars Equity Report
Sto ck Al ert for Friday JAn 6th iPackets International, Inc. Global Developer and Provider of a Wide Range of Wireless and Communications Solutions for Selected Enterprises Including Mine-Safety (Source: News 1/3/06) OTC: IPKL Price: .36 Huge PR For Friday is Underway on IPKL..Radar it Rite Now! Is It Going To Blow Higher From Here? Select Sm all Cap s can Add to Your Portfolio. Recent News: Go Read the Full Stories Now! 1)iPackets International Comments on iPMine's Value in Light of Recent Mining Disasters in the U.S. and China 2)iPackets International Receives US$85,000 Down Payment for Its First iPMine Deployment in China Watch This One Tr ade on Friday! Radar it Right Now.. ___ bbb1BBbbbB1bB11Bbb11 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Advices, comments? Bug#345651: passwd package should be essential?
I tend to agree with Kurt opinions below and thus, I'm tempted to make passwd "Essential: yes". The opinions in the shadow package maintenance team slightly vary. However, given that this is an important decision, I think it is a good idea to get the advice of fellow developers. So, please comment (asking the -ctte is probably not worth it unless the discussion shows that nothing really clear shows up). - Forwarded message from Kurt Roeckx <[EMAIL PROTECTED]> - Date: Mon, 2 Jan 2006 16:09:04 +0100 From: Kurt Roeckx <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [Pkg-shadow-devel] Bug#345651: passwd package should be essential? Reply-To: Kurt Roeckx <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Package: passwd Version: 1:4.0.13-7 Severity: important Hi, I'm wondering if the passwd package should be essential or not. And I want to start with quoting some relevant portions of the policy: 3.5. Dependencies [...] Packages are not required to declare any dependencies they have on other packages which are marked `Essential' (see below), and should not do so unless they depend on a particular version of that package. [...] 3.9.1. Prompting in maintainer scripts [...] Packages which use the Debian Configuration management specification may contain an additional `config' script and a `templates' file in their control archive[2]. The `config' script might be run before the `preinst' script, and before the package is unpacked or any of its dependencies or pre-dependencies are satisfied. Therefore it must work using only the tools present in _essential_ packages.[3] [...] 7.2. Binary Dependencies [...] `Depends' [...] The `Depends' field should also be used if the `postinst', `prerm' or `postrm' scripts require the package to be present in order to run. Note, however, that the `postrm' cannot rely on any non-essential packages to be present during the `purge' phase. = Currently, you can perfectly remove passwd since it's not essential, and nothing essential has a dependency on it. Bash used to have a dependency on passwd, but this was removed in 3.1-1, and was replaced by one on debianutils because of #208514. And debianutils is essential. I believe a better packages for that would have been base-passwd. 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, ... Kurt ___ Pkg-shadow-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-shadow-devel - End forwarded message - -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Bug#344758: init.d script should create /var/run/dirmngr
Would it be useful if the initscript that clears /var/run also created a directory hierarchy under /var/run? (There are different ways of implementing thus, but we can talk about details if this feature is deemed worthwhile.) -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt PARALLELISM
Am 2005-12-27 16:25:10, schrieb Bernd Eckenfels: > In article <[EMAIL PROTECTED]> you wrote: > >apt-get update && apt-get --download-only upgrade > > It would make more sense to send out the DIFFs to the packages.gz, so you > dont actually need to download the packages file every five minutes. But if the Packages.gz has not changed, 'apt-get update' does not download it. OK, diff's would be better. > Gruss > Bernd Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Am 2005-12-27 16:04:42, schrieb Florian Weimer: > * Michelle Konzack: > > > Because we do not get 34 MBit and we have not a netload > > of 100% 24/7 the price per GByte is around 50 US$/GByte. > > This means you still have plenty capacity you've already paid for, > supporting Steinar's claim that bandwidth is cheap. > > Just think about it. 8-) If you need to pay 450.000 DHs (42.000 €) for an E3 of 34 MBit which give you maximum 20-24 MBit because the Infrastructure is to bad in Morocco then it IS expensive. Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: net-tools maintenance status
Thijs Kinkhorst <[EMAIL PROTECTED]> wrote: > So I think you can tell pretty clearly that Bernd has no objection at all > to NMU's. yes, but please not for wishlist bugs. Again: there are bugs open for net-tools where help is requested, I would love to have patches for those. Generally I am not aware of time critical bugs. The wishlist bugs will get fixed in the next upstream version, however that needs some sorting out of the upstream cvs which is not in sync with redhat, suse and debian. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Michelle Konzack <[EMAIL PROTECTED]> wrote: > If you need to pay 450.000 DHs (42.000 ¤) for an E3 of 34 MBit > which give you maximum 20-24 MBit because the Infrastructure is > to bad in Morocco then it IS expensive. No. Based on what you've said, the price is the same regardless of whether you download 1GB or 20GB in a month. Therefore, as long as the increase in traffic doesn't saturate your line, the cost per GB is 0. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advices, comments? Bug#345651: passwd package should be essential?
On Fri, Jan 06, 2006 at 06:38:47PM +0100, Christian Perrier wrote: > I tend to agree with Kurt opinions below and thus, I'm tempted to make > passwd "Essential: yes". The opinions in the shadow package > maintenance team slightly vary. > However, given that this is an important decision, I think it is a > good idea to get the advice of fellow developers. So, please > comment It's not just a good idea, it's the Policy (3.8). For my part, I think this sounds like a bad idea. We should be very sparing in our use of the Essential: yes flag; I think we really should not be using it *except* for packages that we require to be functional when in an unconfigured state. The passwd package certainly doesn't qualify in this regard. Making the package Essential just to cover other packages' failure to depend on it while it was virtually-essential also seems dodgy; btw, it wasn't virtually-essential in woody, so packages really shouldn't have had a chance to get too buggily accustomed to having it around. > 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, ... First, I can't see any reason why you would want to call these commands from a *config* script; that smells of abuse to me. Second, assuming there is a reason to ever call one of these commands from the debconf script, standard procedure for any non-essential .config dependency is to check for the executable and defer configuration to the postinst if it's not yet unpacked. -- 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
Request for Replacement Packager for Ampache
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. Before I orphan it I was wondering if there is anyone who is interested in creating and maintaining the package. No need to spam the list, please e-mail me directly if you are interested. Thanks, -Karl Vollmer vollmer AT ampache.org http://www.ampache.org
Re: Advices, comments? Bug#345651: passwd package should be essential?
pe, 2006-01-06 kello 18:38 +0100, Christian Perrier kirjoitti: > From: Kurt Roeckx <[EMAIL PROTECTED]> > > 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, ... Is there a problem with packages that need stuff from passwd simply depending on passwd? -- Fundamental truth #4: Typing URLs always introduces errors. Always copy +paste. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: net-tools maintenance status
On 1/6/06, Bernd Eckenfels <[EMAIL PROTECTED]> wrote: > Thijs Kinkhorst <[EMAIL PROTECTED]> wrote: > > So I think you can tell pretty clearly that Bernd has no objection at all > > to NMU's. > > yes, but please not for wishlist bugs. Again: there are bugs open for > net-tools where help is requested, I would love to have patches for those. > Generally I am not aware of time critical bugs. > > The wishlist bugs will get fixed in the next upstream version, however that Some? All? And when can that next upstream version be expected (as far as I know the last one is more than four years old). > needs some sorting out of the upstream cvs which is not in sync with redhat, > suse and debian.
Re: APT public key updates?
Anthony Towns writes: > On Fri, Jan 06, 2006 at 12:12:50AM -0800, Thomas Bushnell BSG wrote: >> Anthony Towns writes: >> > No, a key is only as good as (a) how hard it is to break; and (b) how >> > easy it is to trust. Key rotation helps make it harder to break (since >> > the 2004 key won't do you much good now); and also forces us to consider >> > how to make new keys easy to trust, which we otherwise might neglect. >> Looking at the parenthesis: the 2004 key would have been quite >> valuable a week ago. It could have been used to sign a fake 2005 key. >> Oh wait: *it still can be*. > > It shouldn't be, since the 2004 key expired almost a year ago. Maybe we > should be revoking expired keys as well. Sorry, I meant 2005. I forgot the new year; now I see the point you were making, and that makes sense to me. Thomas -- 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 09:21:32AM -0500, Joey Hess wrote: > Maurits van Rees wrote: > > On Fri, Jan 06, 2006 at 08:21:14AM -0500, Joey Hess wrote: > > > 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]? > > > > On January 1 (or whenever a new key is issued) do a security update > > for stable on the package that has the keyring. > > That doesn't address most of the issues I raised. Just for example, > debootstrap in d-i would not see the new key. I thought I saw a reaction from someone else in a different part of the thread who thought that for people who install from an already burned CD set this wouldn't give problems, or only minor. I can't find that post though. Now I think about it more you are right that an expired key would give problems for people downloading a CD image that was originally signed with that key. In fact I think the same problem arises for a single package when the key of the developer of that package expires. Any package signed with the old key becomes untrusted, and should be regenerated, including the cd images. That would not be nice. Mind you, I am still using sarge at the moment, so I hardly have experience with signed packages. I'll go back to lurking now. ;) -- Maurits van Rees | http://maurits.vanrees.org/ [NL] Work | http://zestsoftware.nl/ GnuPG key | http://maurits.vanrees.org/var/gpgkey.asc "Do only what only you can do." --- Edsger Wybe Dijkstra signature.asc Description: Digital signature
Re: Fwd: Bug#344758: init.d script should create /var/run/dirmngr
[Thomas Hood] > Would it be useful if the initscript that clears /var/run also > created a directory hierarchy under /var/run? I cannot fathom how telling someone else to do a particular 'mkdir -p' and 'chown' could possibly be simpler than putting the 'mkdir -p' and 'chown' into your init script. Thus from a complexity standpoint it doesn't seem useful at all. signature.asc Description: Digital signature
Need for launchpad
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. Cheers, Frans _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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. What the difference between this and alioth.debian.org? Regards, Neil -- __ .` `. [EMAIL PROTECTED] | Application Manager : :' ! | Secure-Testing Team member '. `- gpg: B345BDD3| Webapps Team member `- Please don't cc, I'm subscribed to the list signature.asc Description: Digital signature
Re: Need for launchpad
Frans Jessop <[EMAIL PROTECTED]> 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. Launchpad is currently non-free, so it doesn't seem terribly likely. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
* Frans Jessop ([EMAIL PROTECTED]) 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. > Cheers, > Frans AFAIK Launchpad is not free software, so it's not going to happen. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: [no subject]
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. Thank you,
gconf transition
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. I don't have any special scripts, I just use some PAM for the FingerPrint reader. Still, ignoring the fingerprint authentication, it fails. /home/abonilla/.xsession-errors /etc/gdm/PreSession/Default: Registering your session with wtmp and utmp /etc/gdm/PreSession/Default: running: /usr/X11R6/bin/sessreg -a -w /var/log/wtmp -u /var/run/utmp -x "/var/lib/gdm/:0.Xservers" -h "" -l ":0" "abonilla" /etc/gdm/Xsession: Beginning session setup... /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 Which package gets the bug report? .Alejandro -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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. I refuse to tie any part of Debian that I work on to a system where the code isn't Free. We can't reproduce launchpad ourselves without coding it up from scratch. If you want it in Debian, get hacking. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Fri, Jan 06, 2006 at 08:23:13PM +, Neil McGovern wrote: > 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. > > What the difference between this and alioth.debian.org? It's quite different in fact, in some ways more encompassing (incorporating archive management, software translation, bug tracking, support, etc.) and in some ways less (no mailing lists or file distribution). That said, it isn't very fruitful to discuss "all DDs" using Launchpad, any more than Alioth or vim or zsh. They're tools which software developers can choose to use or not, and Debian isn't in the habit of mandating the use of certain tools on the part of its developers. Where Debian developers have chosen to standardize on certain tools, it's because a subset have found that those tools help them to work more efficiently, and Alioth and Launchpad are no different in this respect. Developers will choose to use them when and where it makes sense for them to do so. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How the kernel firmware loader works
Gated from my blog. (#104) How the kernel firmware loader works fEnIo[0] learnt an important lesson about the kernel firmware loader: it (usually) does not work as expected for non-modular drivers. The reason is that the request_firmware()[1] interface is synchronous. Since it's usually called in the initialisation section of drivers, the userspace firmware loader is not available yet if the calling driver is built-in in the kernel. The request_firmware_nowait()[2] asynchronous interface was designed to replace it, but most drivers have not been ported yet. When a driver calls request_firmware(), a uevent[3] is sent by the kernel to udev over a netlink(7) socket, requesting that a specific file is uploaded. udevd runs /lib/udev/firmware.agent, a simple shell script which will look for the $FIRMWARE file in a few directories and then copy it to the designated place in the driver $DEVPATH in sysfs. If the driver is initialised before userspace is started then the loader will not be available, and the request will fail. A possible solution is to run udev in the early userspace environment (initramfs), but just compiling the driver as a module is usually simpler. [0] http://jabba.uaznia.net/fEnIo/id/8689 [1] http://lxr.linux.no/ident?i=request_firmware [2] http://lxr.linux.no/ident?i=request_firmware_nowait [3] http://lxr.linux.no/ident?i=kobject_uevent Posted at 23:57:34. [http://blog.bofh.it/id_104] - -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gconf transition
"Alejandro Bonilla" <[EMAIL PROTECTED]> writes: > /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 Fun! :-/ > Which package gets the bug report? Looks like libgconf2-4, for lacking proper dependencies (on libpango1.0-0, at the very least). -- 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Aptitude question
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. If you don't quite understand the exact situation I'm talking about, I've created a testcase. Download http://www.ms.mff.cuni.cz/~palej3am/testbed.tar.bz2 unpack it, and run APT_CONFIG=path_to_hte_enclosed_apt.conf aptitude 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". I was only asking if it will/can/should install dependencies so as no packages are broken, because it could be quite difficult. Also, there could be more solutions to the problem (in my example, removing "D" also solves the problem -- it is up to the user to decide). Another option would be interactively ask offering the possibilities of satisfiying valuations, or prefering breaking only "new" packages and leaving "old" packages alone (i.e. don't even try satisfy the dependency on "A", when it leads to breaking a package already installed). Anyway, installing vtk-tcl (that depends on xlibmesa-gl | libgl1 and libglu1-xorg | libglu1) on my box did not break anything. 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.
Re: Fwd: Bug#344758: init.d script should create /var/run/dirmngr
Steve Langasek wrote: > That's fine; I'm just saying that there's not much point in telling people > to *not* ship /var/run (or subdirectories thereof) in their package. Well, there is the slight point that if you ship /var/run/foo in your package, you (a) probably use /var/run/foo just assuming it exists because, after all, you shipped in in your package; (b) if you actually mkdir -p it, you have two different ways that /var/run/foo could be created, and possibly with two different sets of permissions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346324: ITP: libfile-flat-perl -- Implements a flat filesystem in perl
Package: wnpp Severity: wishlist Owner: Jonas Genannt <[EMAIL PROTECTED]> * Package name: libfile-flat-perl Version : 0.95 Upstream Author : Adam Kennedy <[EMAIL PROTECTED]> * URL : http://search.cpan.org/~adamk/ * License : GPL Description : Implements a flat filesystem in perl File::Flat implements a flat filesystem. A flat filesystem is a filesystem in which directories do not exist. It provides an abstraction over any normal filesystem which makes it appear as if directories do not exist. . In effect, it will automatically create directories as needed. This is create for things like install scripts and such, as you never need to worry about the existance of directories, just write to a file, no matter where it is. New Build depend for #329990 -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686-smp Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346336: ITP: cereal -- a simulator for the Intel 8051 microcontroller
Package: wnpp Severity: wishlist Owner: Timo Schneider <[EMAIL PROTECTED]> * Package name: cereal Version : 0.9.35 Upstream Author : Miloslav Trmac <[EMAIL PROTECTED]> * URL : http://carolina.mff.cuni.cz/~trmac/blog/cereal/ * License : GPL Description : a simulator for the Intel 8051 microcontroller cereal is an emulation framework designed to allow easy emulation of interconnected modules. Its main component is an 8051 emulator module, so it can be used as an 8051 emulator which offers breakpoints, watches, evaluate/modify dialog (which can solve 2 * x + 1 = 5). The KDE GUI also can be extended using KParts (the 8051 interface is provided as a KParts plugin). Also included is a command interface usable for creating testsuites for your programs and a simple 8051 disassembler. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- 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 wrote: > 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 aptitude in unstable and testing has a feature that lists suggested ways to fix broken packages. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> pgpRb0wCUy8Xl.pgp Description: PGP signature
ITP vexim2
hi my name is Daniel Knabl, i am from Austria, so please excuse my poor English ;) first of all i have to say "thank you" for your great work. there is a nice little application called vexim [1], it is used for managing a virtual mailing system based on exim4 and mysql, and it is fully compatible to the programms in courier-suite (pop,imap + SSL). this application is basically a set of php-scripts. also there is a simple but working configfile for exim4 and both courier pop and imap. i found this solution at http://debainhowto.de [2]. there are some things to be changed within the mysql.sql dump and within the php files. therefor i can NOT package this useful software. 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)??? [1] http://silverwraith.com/vexim/features.html [2] http://debianhowto.de/de:howtos:sarge:exim4_vexim2_courier_mailman -- mfg Daniel Knabl http://www.tirolinux.net PGP Fingerprint [EMAIL PROTECTED] A069 671B 39F2 E9B9 FB34 68BB 4BEC 1344 C8A4 3F0B pgprYwGwrc4la.pgp Description: PGP signature
Re: Bug#345977: ITP: polld -- Polling demon
On Fri, Jan 06, 2006 at 08:15:14AM -0600, Ron Johnson wrote: > On Fri, 2006-01-06 at 19:24 +1100, Hamish Moffatt wrote: > > On Wed, Jan 04, 2006 at 11:29:07AM -0600, Nathan Poznick wrote: > > > Thus spake Roger Leigh: > > > > What is the problem this is trying to solve? > > > > > > > > If the partition table is being changed, the tool that changed it > > > > should issue a BLKRRPART ioctl, like fdisk does for example (see > > > > ). > > > > > > I have a USB card reader which has 5 different slots for various media. > > > If I plug in the card reader and then later insert a CF card, the CF > > > card slot's device does not have the partition device created when using > > > udev (I have to insert the CF card and then plug in the card reader). I > > > > Works fine here... /dev/sdc is created when the card reader is plugged > > in, and /dev/sdc1 is created when I plug in a card. No ugliness > > required. > > But when you remove that (SD, for example) card, and plug in a > different type of card (CF, for example), does the kernel notice? I don't have any other card types to test with. However, the card reader has been allocated sdc, sdd, sde and sdf (one for each of its four card slots), so I would expect it to work. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
