Package web-sso
Bonsoir, je développe depuis pas mal de temps le websso Lemonldap::NG (récriture complète de Lemonldap). Les sources incluent le packaging Debian et j'aimerai savoir s'il y aurait une bonne âme DD pour estimer mon travail. Tout est là: deb http://lemonldap.objectweb.org/NG/debian testing/ deb-src http://lemonldap.objectweb.org/NG/debian testing/ @+ Xavier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
upgrade path for two releases now, with its Recommends: handling being a major reason for this. I'd be surprised if there weren't at least *some* users switching to it as a result. Developer users probably. The ones that resist are more non-developer users. I'm constantly being annoyed at work with so-called systems administrators pinging /me about my Debian box upgrades badly which is nearly always the consequence of the use of apt-get for upgrades. And I can definitely confitm that, when one just answers read the bloody release notes and learn about aptitude, the surprise is often very high when people discover that the recommended tool is aptitude and not apt-get. There are so many examples all around the web with various apt-get calls and pretty few with aptitude. In these days where googling becomes a synonym of read the documentation, it hurts badly. Another widely misunderstood feature of aptitude is the ability to handle packages installed as dependencies. It's pretty often badly understoood and leads to horror stories floating around of aptitude wants to remove half of the system while the issue is just the user not understanding the documentation that explains how to switch properly from apt-get to aptitude. signature.asc Description: Digital signature
Re: APT 0.7 for sid
Michael Vogt schrieb am Montag, den 11. Juni 2007: Hi, *snip* [..] - automatic installation of recommends like aptitude [..] This is currently turned off because of the concerns raised. its a matter of changing the default of APT::Install-Recommends to true. I want to turn it on by default in the near future, but with a reasonable warning time for the transition. Please never make it a default. Humans make errors and I never want packages installed by default. I consider this really a dangerous option (but maybe usefull on desktops) so just integrate some kind of button in synaptic co, but please don't make it a default. Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
Christian Perrier [EMAIL PROTECTED] wrote: Another widely misunderstood feature of aptitude is the ability to handle packages installed as dependencies. It's pretty often badly understoood and leads to horror stories floating around of aptitude wants to remove half of the system while the issue is just the user not understanding the documentation that explains how to switch properly from apt-get to aptitude. Where ist that part about switching? I couldn't find it in the TOC in html/en/index.html, nor by grepping for apt-get in those html files. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Large static datasets like genomes (Re: Reasonable maximum package size ?)
On 10 Jun 2007, at 6:38 pm, Steffen Moeller wrote: On Sunday 10 June 2007 17:20:54 you wrote: On 9 Jun 2007, at 11:27 am, Steffen Moeller wrote: Once a (computational) biologist starts a new project, (s)he wants the latest data no matter what and anything older than three months (or a week sometimes) is likely not to be acceptable. Actually, my experience is that they tend to want diametrically opposite things, at the same time. 1) When starting a new project, they usually want the very latest data. 2) But they usually then want to keep that data static for the lifetime of the project. :o) very true. For 1) I hink that Debian packages for databases do not work. They might well work for 2), though. ... except that they usually want several versions present at once, which would mean a completely separate package name for each release. Ick. But ... how can one directly access a feature on the genome that has no accession number because you have just found it across releases of Ensembl? * base pairs and chromosome ID does not work across (NCBI) releases * centiMorgans are too vague * distances in bp relative to the nearest genomic marker? Not too bad, probably. The easiest seems indeed to keep the data on which whatever results are computed which is diagnosed as behaviour 2). Oh, yes, I'm not saying the requirement isn't *reasonable*. It just makes life difficult! Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Mon, 11 Jun 2007, Alexander Wirt wrote: I want to turn it on by default in the near future, but with a reasonable warning time for the transition. Please never make it a default. Humans make errors and I never want packages installed by default. I consider this really a dangerous option (but maybe usefull on desktops) so just integrate some kind of button in synaptic co, but please don't make it a default. I disagree. Please make it the default. We need consistency and that's the intended meaning of that field. You really need to explain why it would be a dangerous option when the only problem could be that the user has installed more packages than really needed. Otherwise your disagreement is of no value. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#428256: ITP: ffrenzy -- Multiplayer platform with dwarfs fighting with/for food
On Sun, Jun 10, 2007 at 10:41:43AM +0200, Paul van Tilburg wrote: Package: wnpp Severity: wishlist Owner: Paul van Tilburg [EMAIL PROTECTED] * Package name: ffrenzy Version : 1.0.2 Upstream Authors: Bas Kloet [EMAIL PROTECTED], Christian Luijten [EMAIL PROTECTED], Emiel Neggers [EMAIL PROTECTED], Bram Senders [EMAIL PROTECTED], Sjoerd Simons [EMAIL PROTECTED], Paul van Tilburg [EMAIL PROTECTED] * URL : http://ffrenzy.luon.net/ * License : GPL Programming Lang: C mainly, Python for the menu and utils Description : Multiplayer platform with dwarfs fighting with/for food Dwarfs need to collect food as fast as possible to bring it back to their mushrooms to live. When a dwars leaves his home without providing it with ^ ? food too long, it dies from hunger. The collected food can be thrown at other dwarfs, making them unconscious when hit. When a power-up is picked up, thrown food will have special powers! -- Chris. == -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428381: ftp.debian.org: proposed-updates is not part of release a=stable
Package: ftp.debian.org Severity: normal Since proposed-updates contain only approved updates for the next stable release it make sense to add it to the sources.lists (at least for some users). I have done so and I'm discovering a little quirk related to its use. Until now I had etch + proposed-updates only in my sources.list. Recently I have added sid in my sources.list and added APT::Default-Release stable to make sure to follow etch. All packages which already got updated via proposed-updates are now candidates for upgrade to sid... that's because proposed-updates is not labelled as being part of release a=stable and as such is not pinned accordingly. It has: release v=4.0-updates,o=Debian,a=proposed-updates,l=Debian,c=main Whereas etch has: release v=4.0r0,o=Debian,a=stable,l=Debian,c=main I don't know how dak works but IMO it would make more sense to have proposed-updates be: release v=4.0-updates,o=Debian,a=stable,l=Debian,c=proposed-updates/main Of course, for an experienced APT user the problem is minor. It can be solved by adding this snippet to /etc/apt/preferences: Package: * Pin: release a=proposed-updates Pin-Priority: 990 But I really believe that APT::Default-Release stable should be enough and do the right thing with proposed-updates as well. Cheers, -- System Information: Debian Release: 4.0 APT prefers proposed-updates APT policy: (990, 'proposed-updates'), (990, 'stable'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Using standardized SI prefixes
Hi all, Please look at http://en.wikipedia.org/wiki/Binary_prefix . I put a bug up for it https://bugs.launchpad.net/ubuntu/+bug/119822 Aaron helpfully said it needs more discussion. I have had great support from libtorrent code.rasterbar.com as well as the guys at deluge http://dev.deluge-torrent.org . The difference is simply astonishing to put aside if let's say a download or an .ISO says 700 MB (700*1000) it becomes 683.59375 MiB (70/1024) . Please lemme know what you guys think about it ? It isn't just ubuntu or debian but this needs to be done everywhere. Have something accurate. -- Shirish Agarwal This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/ 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Using standardized SI prefixes
Ugh, The second example I wanted to give was of libburnia http://libburnia-project.org/changeset/877 . Sorry -- Shirish Agarwal This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/ 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Mon, 11 Jun 2007, Alexander Wirt wrote: Please never make it a default. Humans make errors and I never want packages Recommends *are* to be installed by default, unless you specifically tell the tool not to. This is the whole point, one that has been broken for a few *years* now and has caused problems to everyone for that long. It is high time to either remove apt-get, or to just damn fix it to actually do what it is supposed to do. apt-get can't continue living on as a mostly debug tool when it is used everywhere as a main admin tool. Heck, some misguided soul even made a slogan out of it (apt-get into it) to promote Debian. Let's fix the damn thing already. I am sick of telling users that you did not install a recommended package, that's why it is not working as you expect it to, because they use broken package managers. usefull on desktops) so just integrate some kind of button in synaptic co, synaptic co are also broken in a very bad way if they do not offer to install recommends by default (and broken in a very bad usability way if you can't tell them that no, you don't want that recommended package installed). Just fix them. dselect was fixed a long time ago, and aptitude does this right since day one (AFAIK anyway). -- 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 0.7 for sid
On Sun, Jun 10, 2007 at 06:08:44PM -0500, Steve Greenland wrote: Really? I'd have guessed that most people used aptitude. I can't imagine anyone preferring synaptic to aptitude. Of course, I don't really understand why anyone prefers [any graphical MUA] to mutt, or [any graphical newsreader] to trn. I mean, GUIs are nice for things you don't use every day, but for serious work, they're so damn slow and klutzy. My mum uses synaptic. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Fri, Jun 08, 2007 at 01:01:18PM +0200, Gabor Gombas wrote: On Fri, Jun 08, 2007 at 11:36:57AM +0100, Luis Matos wrote: i have 2 servers that i only login for apt-get update apt-get upgrade -y, they are running sarge (yet) and only install security upgrades. These 2 server will not be put in danger by making the update upgrade in an autonomous way. IIRC a security update in sarge changed sudo's behaviour and that broke many local scripts. We decided that the security threat addressed by the update was basically zero and went back to the old version - finding fixing all the broken scripts was simply not worth the effort. So an automatic security update _can_ break a working server. Yes, of course. *Any* change to the software might break a working system, either because it introduces or uncovers bugs, or because it changes something a script or third-party app relies on. Perhaps an automatic security update system could make use of additional info (local or remote exploit, etc) to offer more control over the balance of risks. Would such a system have saved you from unnecessary automated breakage ? Regards, Paddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
shirish wrote: Hi all, Please look at http://en.wikipedia.org/wiki/Binary_prefix . I put a bug up for it https://bugs.launchpad.net/ubuntu/+bug/119822 Aaron helpfully said it needs more discussion. I have had great support from libtorrent code.rasterbar.com as well as the guys at deluge http://dev.deluge-torrent.org . The difference is simply astonishing to put aside if let's say a download or an .ISO says 700 MB (700*1000) it becomes 683.59375 MiB (70/1024) . Please lemme know what you guys think about it ? It isn't just ubuntu or debian but this needs to be done everywhere. Have something accurate. I support your request. Although I think this isn't a big deal for the average user, it is pretty confusing from time to time since you can't be sure what a k actually means. This standard you're talking about exists for a while now but it seems that people (programmers) are adapting really slow. We could do the community a favor by doing what's in our possibility and push the adoption a bit further. Cheers, Bastian PS: Next time please use your real name when posting to Debian mailing lists. -- Bastian Venthur http://venthur.de Debian Developer venthur at debian org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Le lundi 11 juin 2007 à 18:27 +0530, shirish a écrit : Hi all, Please look at http://en.wikipedia.org/wiki/Binary_prefix . I put a bug up for it https://bugs.launchpad.net/ubuntu/+bug/119822 Aaron helpfully said it needs more discussion. I have had great support from libtorrent code.rasterbar.com as well as the guys at deluge http://dev.deluge-torrent.org . The difference is simply astonishing to put aside if let's say a download or an .ISO says 700 MB (700*1000) it becomes 683.59375 MiB (70/1024) . Please lemme know what you guys think about it ? It isn't just ubuntu or debian but this needs to be done everywhere. Have something accurate. FWIW, this is already the case in GNOME. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
ITP: pysycache-- Educational game to teach children to move the mouse
Package: wnpp Severity: wishlist Owner: José L. Redrejo Rodríguez [EMAIL PROTECTED] * Package name: pysycache Version : 3.0.1 Upstream Author : Vincent Deroo [EMAIL PROTECTED] * URL : http://www.pysycache.org/ * License : GPL Description : Educational game to teach children to move the mouse The application offers some activities based on simple objects, photographies, numbers and letters with their sounds in different languages. The activities make children practice on clicking, double-clicking, drag and drop, moving and identify the mouse buttons. From its website many packages can be downloaded to add new photos and text to the activities. signature.asc Description: Esta parte del mensaje está firmada digitalmente
The Shell: arithmetic comparison with void
If was time, where string comparisons with void were ... with features. |-*- if [ x$a = 'x|' ]; then |-*- Yet arithmetic ones are still with them: |-*- [EMAIL PROTECTED]:/tmp$ bash -c test '' -eq 0 ; echo \$? bash: line 0: test: : integer expression expected 2 [EMAIL PROTECTED]:/tmp$ dash -c test '' -eq 0 ; echo \$? 0 [EMAIL PROTECTED]:/tmp$ busybox sh -c test '' -eq 0 ; echo \$? 0 [EMAIL PROTECTED]:/tmp$ |-*- Ah, bash is clever? |-*- [EMAIL PROTECTED]:/tmp$ bash -c -v test \printf '\t'\ -eq 0 ; echo \$? test-eq 0 ; echo $? 0 [EMAIL PROTECTED]:/tmp$ bash -c -v test \printf ' '\ -eq 0 ; echo \$? test -eq 0 ; echo $? 0 [EMAIL PROTECTED]:/tmp$ bash -c -v test \printf 'a'\ -eq 0 ; echo \$? test a -eq 0 ; echo $? bash: line 0: test: a: integer expression expected 2 [EMAIL PROTECTED]:/tmp$ |-*- Nope? Are there bugs or features? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Monday 11 June 2007 14:57, shirish wrote: Please look at http://en.wikipedia.org/wiki/Binary_prefix . I put a bug up for it https://bugs.launchpad.net/ubuntu/+bug/119822 Aaron helpfully said it needs more discussion. I have had great support from libtorrent code.rasterbar.com as well as the guys at deluge http://dev.deluge-torrent.org . The difference is simply astonishing to put aside if let's say a download or an .ISO says 700 MB (700*1000) it becomes 683.59375 MiB (70/1024) . Please lemme know what you guys think about it ? It isn't just ubuntu or debian but this needs to be done everywhere. Have something accurate. I'm in favour! (But are you requesting that aptitude use SI prefixes correctly, or that it use IEC (binary) prefixes? -- Magnus Holmgren pgpaVIzYUqkyh.pgp Description: PGP signature
Re: Using standardized SI prefixes
Magnus Holmgren wrote: I'm in favour! (But are you requesting that aptitude use SI prefixes correctly, or that it use IEC (binary) prefixes? I think we should go for the binary prefixes. Users will be confused when they read 1k and notice that the package has 'just' 1000 bytes. Plus, the 2^n presentation is much more common in the IT world than the 10^n presentation. Cheers, Bastian -- Bastian Venthur http://venthur.de Debian Developer venthur at debian org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
Henrique de Moraes Holschuh wrote: On Mon, 11 Jun 2007, Alexander Wirt wrote: Please never make it a default. Humans make errors and I never want packages Recommends *are* to be installed by default, unless you specifically tell the tool not to. This is the whole point, one that has been broken for a few *years* now and has caused problems to everyone for that long. [..] synaptic co are also broken in a very bad way if they do not offer to install recommends by default (and broken in a very bad usability way if you can't tell them that no, you don't want that recommended package installed). Just fix them. dselect was fixed a long time ago, and aptitude does this right since day one (AFAIK anyway). FWIW, synaptic has an option in its preferences dialog called Consider recommended packages as dependencies, which is off by default. I completely agree, to treat Recommends as weak dependencies and install them by default and make that behaviour consistent among all package managers. The frontends imho just need a clear way of showing which packages are going to be installed because of a Depends and which because of a Recommends, so it would be easier to de-select a recommended package. Otherwise there would be no point having Suggests and Recommends, if they are basically treated the same by the package management tool. Just my 2¢, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
(no subject)
unsubscribe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (no subject)
- KRYPTIVA PACKAGED MESSAGE - PACKAGING TYPE: SIGNED Francois-Denis Gonthier wrote: unsubscribe mm... crap I'm really sorry. - KRYPTIVA SIGNED MESSAGE - This email claims to have been packaged by Kryptiva. To process this email and authenticate its origin, get the free plugin from: http://www.kryptiva.com/downloads - KRYPTIVA SIGNATURE START - AvWVqAIBTiACAQC3AQAIAwECABS3FuvxegTt63v7UWCF iSdtKgVqvAMAFNtYnPf/czq1EyEfvnKRBT4kXaMpBAAUDuTQouyueK8rYsc0K72n8XinFeoF ABTaOaPuXmtLDTJVv++VYBiQr9gHCQYAFBL7zffDNIBf5j18CuIdHHV6nHddBwAU+nHOBUjC gttJMc67xnzu+UGHwYwRABgAAABOIEZtcu0AAcu4EU4TAAQAggP8 DjLQGHZNcebX7OWD4kQ+Bh95Om++g1sMfnlMyZLu0Q1PB7ZyoYZPJEt203o0PBNJaeG8Fnwo sM4JShLe3ow7pdIUkp6X3/fr/kAOKXZgXAOT0q6tQpGMskFT5Gqsm/CL5XOwyMl/DJZzoFc1 z2zLlRvf4CY2ilKyd40tl2qOVDw= - KRYPTIVA SIGNATURE END - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
On Tue, Jun 05, 2007 at 11:31:37AM +0200, Pierre Habouzit wrote: On Tue, Jun 05, 2007 at 10:27:26AM +0200, Marco d'Itri wrote: Diskspace *is* a problem for mirrors, as is bandwidth in many countries. Also, you should think about this issue not just in the context of the single package you are interested in but as a general policy. Honnestly, no, this is not true anymore nowadays. With a 500Gb sata hard drive, you're able to have a full debian mirror (all archs). Such a disk is around 100€ nowadays. ... but it will break down in three months with the typical usage pattern of a public Debian mirror. A typical 300GB server-class hotpluggable SATA or SAS disk is quite a bit more expensive than a typical desktop-class 500GB hard disk, and for a RAID setup that will actually survive the breakdown of a number of moving parts parts, you'll need at least four or five of them. Disk space is *not* cheap, and using it as an argument to add more packages to the archive is stupid. Additionally, network bandwidth isn't cheap, either, and the update of a number of 400MB packages might disrupt the (twice-daily) mirror pulse. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Mon, Jun 11, 2007 at 05:14:18PM +0200, Bastian Venthur wrote: Magnus Holmgren wrote: I'm in favour! (But are you requesting that aptitude use SI prefixes correctly, or that it use IEC (binary) prefixes? I think we should go for the binary prefixes. Users will be confused when they read 1k and notice that the package has 'just' 1000 bytes. Plus, the 2^n presentation is much more common in the IT world than the 10^n presentation. Not for network bandwidth, and less and less for storage space (commercials do understand what a free 7.5% bonus means, i.e. selling something as 7.5% larger when it is in fact the same that it used to be). I do agree, that especially in the case of filesystem organisation, it makes much more sens to use the binary units. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
Raphael Hertzog schrieb am Montag, den 11. Juni 2007: On Mon, 11 Jun 2007, Alexander Wirt wrote: I want to turn it on by default in the near future, but with a reasonable warning time for the transition. Please never make it a default. Humans make errors and I never want packages installed by default. I consider this really a dangerous option (but maybe usefull on desktops) so just integrate some kind of button in synaptic co, but please don't make it a default. I disagree. Please make it the default. We need consistency and that's the intended meaning of that field. You really need to explain why it would be a dangerous option when the only problem could be that the user has installed more packages than really needed. Otherwise your disagreement is of no value. Args it was too early in the morning. Please forget my mail. I was at the install security updates automatically feature. Sorry the he mess. Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
shirish [EMAIL PROTECTED] writes: It isn't just ubuntu or debian but this needs to be done everywhere. No it doesn't. The SI binary prefixes are an abomination. Kibibytes? Christ... [Did they try pronouncing these horrid things when standarizing them?!?] -Miles -- We are all lying in the gutter, but some of us are looking at the stars. -Oscar Wilde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
Hi, On Mon, Jun 11, 2007 at 05:39:54PM +0200, Michael Biebl wrote: FWIW, synaptic has an option in its preferences dialog called Consider recommended packages as dependencies, which is off by default. I completely agree, to treat Recommends as weak dependencies and install them by default and make that behaviour consistent among all package managers. The frontends imho just need a clear way of showing which packages are going to be installed because of a Depends and which because of a Recommends, so it would be easier to de-select a recommended package. For synaptic, I think it would be fine if Recommends were marked as such in the window which pops up when you select a package; right now Depends and (if you select the above option) Recommends are just mentioned as Will be installed (at least in my outdated version of synaptic). Synaptic could mark them as Recommends there and offer a check-box for each, so people could easily unmark recommended packages they do not want installed at this point (though maybe it should be pointed out (once) that doing so might be unwise). Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Monday 11 June 2007 18:53, Miles Bader wrote: shirish [EMAIL PROTECTED] writes: It isn't just ubuntu or debian but this needs to be done everywhere. No it doesn't. The SI binary prefixes are an abomination. Why - besides pronunciation? -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpQQ5itw9oLY.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Mon, Jun 11, 2007 at 07:05:23PM +0200, Magnus Holmgren wrote: Why - besides pronunciation? Aren't the names enough? :) Maybe they could have called them Kilobin bytes and Megabin bytes or something somewhat less awful sounding that they came up with. Did they even talk to anyone that might actually use the units? -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
I prefer not to use these new prefixes, because the old ones only became confused due to the efforts of drive manufacturers. Who are perfectly capable (and equally financially motivated) of pulling the same trick with the new units, standards body or no. Also, the ib prefixes sound stupid. Furthermore, the KiB abbreviation wastes a lot more screen space than K, while actually converying no additional useful information. Many programs use every available character in a nominal 80 column screen and would have to drop information, precision, or significantly change their display to use the KiB unit. Debian has approximately as small of a chance standarising this throughout the distribution as we do standadising the spelling of colo[u]r or standardi[sz]e throughout the distribution. (On the other hand, I am one of the minority of people in the world who still prefer imperial measures, so apply salt to taste.) (On the third hand, I am a proponent of binary or decimal time and date representations. Down with bases 12, 60, and 30+-1 !) -- see shy jo signature.asc Description: Digital signature
Re: Reasonable maximum package size ?
On Sun, Jun 10, 2007 at 06:59:49PM +0100, Wouter Verhelst [EMAIL PROTECTED] wrote: On Tue, Jun 05, 2007 at 11:31:37AM +0200, Pierre Habouzit wrote: On Tue, Jun 05, 2007 at 10:27:26AM +0200, Marco d'Itri wrote: Diskspace *is* a problem for mirrors, as is bandwidth in many countries. Also, you should think about this issue not just in the context of the single package you are interested in but as a general policy. Honnestly, no, this is not true anymore nowadays. With a 500Gb sata hard drive, you're able to have a full debian mirror (all archs). Such a disk is around 100€ nowadays. ... but it will break down in three months with the typical usage pattern of a public Debian mirror. A typical 300GB server-class hotpluggable SATA or SAS disk is quite a bit more expensive than a typical desktop-class 500GB hard disk, and for a RAID setup that will actually survive the breakdown of a number of moving parts parts, you'll need at least four or five of them. Actual data seems to show the cheap desktop disks are not worse than so-called server-class disks. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Mon, Jun 11, 2007 at 07:03:47AM +0200, Christian Perrier [EMAIL PROTECTED] wrote: upgrade path for two releases now, with its Recommends: handling being a major reason for this. I'd be surprised if there weren't at least *some* users switching to it as a result. Developer users probably. The ones that resist are more non-developer users. I'm constantly being annoyed at work with so-called systems administrators pinging /me about my Debian box upgrades badly which is nearly always the consequence of the use of apt-get for upgrades. And I can definitely confitm that, when one just answers read the bloody release notes and learn about aptitude, the surprise is often very high when people discover that the recommended tool is aptitude and not apt-get. There are so many examples all around the web with various apt-get calls and pretty few with aptitude. In these days where googling becomes a synonym of read the documentation, it hurts badly. Another widely misunderstood feature of aptitude is the ability to handle packages installed as dependencies. It's pretty often badly understoood and leads to horror stories floating around of aptitude wants to remove half of the system while the issue is just the user not understanding the documentation that explains how to switch properly from apt-get to aptitude. The fact is : users don't read documentation. Software should be designed considering this fact. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Joey Hess wrote: I prefer not to use these new prefixes, because the old ones only became confused due to the efforts of drive manufacturers. Who are perfectly capable (and equally financially motivated) of pulling the same trick with the new units, standards body or no. Also, the ib prefixes sound stupid. Furthermore, the KiB abbreviation wastes a lot more screen space than K, while actually converying no additional useful information. Many programs use every available character in a nominal 80 column screen and would have to drop information, precision, or significantly change their display to use the KiB unit. Ok, sounds stupid and may not fit on 80 column screen. I agree with the sounds stupid part, although I don't belive this is a valid argument. What I don't believe is your 80 colums argument. Could you please name a few of the *many* programs which would have to drop information, precision, or significantly change their display to use the KiB unit? On the other hand, we have the chance to avoid user confusion and follow a standard that (according to the wikipedia article) many already adopted, like the GNU core utils, the linux kernel, ifconfig, launchpad and gparted and many standards bodies and technical organizations like IEEE, CIPM, NIST, and SAE. Debian has approximately as small of a chance standarising this throughout the distribution as we do standadising the spelling of colo[u]r or standardi[sz]e throughout the distribution. One is correct American- and the other correct British English spelling. I don't see the problem. I think there is already a l10n for package descriptions project going on to solve this problem, so we don't have to standardi[sz]e one of them ;) Cheers, Bastian -- Bastian Venthur http://venthur.de Debian Developer venthur at debian org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
On 06/11/07 12:28, Mike Hommey wrote: On Sun, Jun 10, 2007 at 06:59:49PM +0100, Wouter Verhelst [EMAIL PROTECTED] wrote: On Tue, Jun 05, 2007 at 11:31:37AM +0200, Pierre Habouzit wrote: On Tue, Jun 05, 2007 at 10:27:26AM +0200, Marco d'Itri wrote: Diskspace *is* a problem for mirrors, as is bandwidth in many countries. Also, you should think about this issue not just in the context of the single package you are interested in but as a general policy. Honnestly, no, this is not true anymore nowadays. With a 500Gb sata hard drive, you're able to have a full debian mirror (all archs). Such a disk is around 100€ nowadays. ... but it will break down in three months with the typical usage pattern of a public Debian mirror. A typical 300GB server-class hotpluggable SATA or SAS disk is quite a bit more expensive than a typical desktop-class 500GB hard disk, and for a RAID setup that will actually survive the breakdown of a number of moving parts parts, you'll need at least four or five of them. Actual data seems to show the cheap desktop disks are not worse than so-called server-class disks. If your data center infrastructure is based around SCSI or SAS, then it's irrelevant how much better or worse they are. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On 10-Jun-07, 20:16 (CDT), Hamish Moffatt [EMAIL PROTECTED] wrote: On Sun, Jun 10, 2007 at 06:08:44PM -0500, Steve Greenland wrote: On 10-Jun-07, 17:47 (CDT), Daniel Burrows [EMAIL PROTECTED] wrote: Since then, it seems like most users have switched to apt-get and synaptic, with hardly anyone using aptitude or dselect any more Really? I'd have guessed that most people used aptitude. I can't imagine anyone preferring synaptic to aptitude. Of course, I don't really [..] Steve the hopelessly out-of-date dselect still works, fwiw ;) Oh, I know. I used it extensively. One of the things I miss in aptitude is the ability to get alternate sorting via 'o' and 'O'. I never quite understood the distinction in dselect, but I knew that if I kept pounding 'o' (or 'O'), I'd eventually cyle around to the sorting order I wanted. 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: APT 0.7 for sid
On 11-Jun-07, 08:45 (CDT), Michael Banck [EMAIL PROTECTED] wrote: On Sun, Jun 10, 2007 at 06:08:44PM -0500, Steve Greenland wrote: Really? I'd have guessed that most people used aptitude. I can't imagine anyone preferring synaptic to aptitude. Of course, I don't really understand why anyone prefers [any graphical MUA] to mutt, or [any graphical newsreader] to trn. I mean, GUIs are nice for things you don't use every day, but for serious work, they're so damn slow and klutzy. My mum uses synaptic. Of course she does. If I was setting up a Debian box for my mother (or any other new convert from Windows or OSX), I'd show her synaptic, too. I'm not insane. Nor was my comment meant to bash synaptic (or GUI tool users); as I noted, for things that I use rarely, GUI frontends are nice. Actually, my comment was mostly meant to keep Daniel from getting depressed and dropping aptitude :-) 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: Using standardized SI prefixes
On Monday 11 June 2007 19:26, Joey Hess wrote: I prefer not to use these new prefixes, because the old ones only became confused due to the efforts of drive manufacturers. Who are perfectly capable (and equally financially motivated) of pulling the same trick with the new units, standards body or no. I don't believe that to be true. There are other computer-related contexts where SI prefixes aren't used for powers of two, although perhaps most of them don't involve bytes. For an average user, knowing two sets of prefixes should be easier than knowing exactly in which situations to interpret the SI prefixes as binary prefixes. Drive manufacturers used the SI prefixes in the correct, albeit unexpected way. The fact is that with the IEC prefixes, all ambiguity is removed, so if someone claims that a storage device is 32 GiB when it's in fact 32 GB, there can be no doubt as to the fact that they are lying. Or what kind of tricks did you have in mind? Also, the ib prefixes sound stupid. Furthermore, the KiB abbreviation wastes a lot more screen space than K, while actually converying no additional useful information. Many programs use every available character in a nominal 80 column screen and would have to drop information, precision, or significantly change their display to use the KiB unit. You seem to fancy the K-is-1024--k-is-1000 convention, which doesn't work with any higher power. But even if we accept that K unambiguously equals 1024, then to be consistent either K should be KB or KiB can be shortened to Ki. That's a single character, not a lot. Debian has approximately as small of a chance standarising this throughout the distribution as we do standadising the spelling of colo[u]r or standardi[sz]e throughout the distribution. If everybody waits for somebody else to change first, then no change can ever happen. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack) -- Dave Evans pgppwi26TZ4dd.pgp Description: PGP signature
Re: Using standardized SI prefixes
Hi, * Bastian Venthur [EMAIL PROTECTED] [2007-06-11 20:09]: [...] Ok, sounds stupid and may not fit on 80 column screen. I agree with the sounds stupid part, although I don't belive this is a valid argument. What I don't believe is your 80 colums argument. Could you please name a few of the *many* programs which would have to drop information, precision, or significantly change their display to use the KiB unit? Don't we have $COLUMNS? :) Kind regards Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. pgpLN6YNtsTE2.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Monday 11 June 2007 20:06, Bastian Venthur wrote: I agree with the sounds stupid part, although I don't belive this is a valid argument. What I don't believe is your 80 colums argument. Could you please name a few of the *many* programs which would have to drop information, precision, or significantly change their display to use the KiB unit? What I'm missing in this request is the practical use. The original example given at the start of this thread was: Package: filezilla State: not installed Version: 3.0.0~beta10-0ubuntu1 Priority: optional Section: universe/net Maintainer: Ubuntu MOTU Developers [EMAIL PROTECTED] Uncompressed Size: 2134k Can you tell me in which cases you would make a different decision if this was either 2134*1000 or 2134*1024 bytes? In either case, ~ 2 million bytes suits your requirement, or it doesn't. This sounds to me like solving a non-problem, unless you can of course tell me in which situations adding the B or iB in the field above would solve a real question. thanks, Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Bastian Venthur wrote: I agree with the sounds stupid part, although I don't belive this is a valid argument. It's a perfectly valid argument for me to use to ignore a bad standard. If the standard makes me talk funny, I will ignore it or make fun of it. (Bibibibibibibibibibib.) What I don't believe is your 80 colums argument. Could you please name a few of the *many* programs which would have to drop information, precision, or significantly change their display to use the KiB unit? iftop, top, ls, and df are the first few to come to mind. On the other hand, we have the chance to avoid user confusion and follow a standard that (according to the wikipedia article) many already adopted, like the GNU core utils, the linux kernel, ifconfig, launchpad and gparted and many standards bodies and technical organizations like IEEE, CIPM, NIST, and SAE. Note that wikipedia is rarely perfectly accurate on technical matters. And coreutils does not consistently use the SI prefixes. -- see shy jo signature.asc Description: Digital signature
Re: Using standardized SI prefixes
On Monday 11 June 2007 15:07, shirish wrote: Ugh, The second example I wanted to give was of libburnia http://libburnia-project.org/changeset/877 . Sorry Uh, tell them that kiB should be KiB. Don't ask me why. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpXOeIiuxsxj.pgp Description: PGP signature
Re: Reasonable maximum package size ?
On Mon, Jun 11, 2007 at 07:28:13PM +0200, Mike Hommey wrote: Actual data seems to show the cheap desktop disks are not worse than so-called server-class disks. My actual data does not back up your claim. Moreover, desktop-class hard disks never support hotplugging, which you really want for a publically-accessible mirror. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
On Monday 11 June 2007 13:09:40 Roberto C. Sánchez wrote: That may be true when it comes to breakdowns. However, I challenge you to show me a cheap desktop disk that is also SCSI or SAS *and* hotpluggable. While not SCSI or SAS, there are SATA controllers that support hotplugging drives. wt -- Warren Turkal
Re: Using standardized SI prefixes
Magnus Holmgren wrote: I don't believe that to be true. There are other computer-related contexts where SI prefixes aren't used for powers of two, although perhaps most of them don't involve bytes. For an average user, knowing two sets of prefixes should be easier than knowing exactly in which situations to interpret the SI prefixes as binary prefixes. Drive manufacturers used the SI prefixes in the correct, albeit unexpected way. The fact is that with the IEC prefixes, all ambiguity is removed, so if someone claims that a storage device is 32 GiB when it's in fact 32 GB, there can be no doubt as to the fact that they are lying. Or what kind of tricks did you have in mind? The kind of tricks that a company with a marketing department typically comes up with, not me. Also, the ib prefixes sound stupid. Furthermore, the KiB abbreviation wastes a lot more screen space than K, while actually converying no additional useful information. Many programs use every available character in a nominal 80 column screen and would have to drop information, precision, or significantly change their display to use the KiB unit. You seem to fancy the K-is-1024--k-is-1000 convention No, I hate that convention. K and k should only ever refer to 1024. -- see shy jo signature.asc Description: Digital signature
Re: Using standardized SI prefixes
Hallo, On 6/11/07, Joey Hess [EMAIL PROTECTED] wrote: No, I hate that convention. K and k should only ever refer to 1024. Like in kg or km? -- -alex http://www.ventonegro.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Alex Queiroz wrote: Hallo, On 6/11/07, Joey Hess [EMAIL PROTECTED] wrote: No, I hate that convention. K and k should only ever refer to 1024. Like in kg or km? This thread is about units of data. -- see shy jo signature.asc Description: Digital signature
Re: Using standardized SI prefixes
Hallo, On 6/11/07, Joey Hess [EMAIL PROTECTED] wrote: Alex Queiroz wrote: Hallo, On 6/11/07, Joey Hess [EMAIL PROTECTED] wrote: No, I hate that convention. K and k should only ever refer to 1024. Like in kg or km? This thread is about units of data. The prefix don't change according to the unit type. -- -alex http://www.ventonegro.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Monday 11 June 2007 21:25, Joey Hess wrote: Magnus Holmgren wrote: You seem to fancy the K-is-1024--k-is-1000 convention No, I hate that convention. K and k should only ever refer to 1024. In that case you're just sloppy. Prefixes and symbols for units are case sensitive. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpzpLOoR9VqR.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Monday 11 June 2007 21:41, Joey Hess wrote: Alex Queiroz wrote: On 6/11/07, Joey Hess [EMAIL PROTECTED] wrote: No, I hate that convention. K and k should only ever refer to 1024. Like in kg or km? This thread is about units of data. kbit? kbit/s? kB/s? -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpLBBfO2s64p.pgp Description: PGP signature
Re: Using standardized SI prefixes
Le lundi 11 juin 2007 à 15:25 -0400, Joey Hess a écrit : You seem to fancy the K-is-1024--k-is-1000 convention No, I hate that convention. K and k should only ever refer to 1024. /me waits for the day measuring jugs are graduated in powers of two, just to please a group of hackers who don't like SI units. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Reasonable maximum package size ?
On Mon, Jun 11, 2007 at 01:24:34PM -0600, Warren Turkal wrote: On Monday 11 June 2007 13:09:40 Roberto C. Sánchez wrote: That may be true when it comes to breakdowns. However, I challenge you to show me a cheap desktop disk that is also SCSI or SAS *and* hotpluggable. While not SCSI or SAS, there are SATA controllers that support hotplugging drives. Whatever. The point wasn't that you can't set up a professional RAID array using cheap desktop hard disks; you can, if you really want to, though I wouldn't recommend it. And yes, you're completely free to ignore that particular advise, so long as you don't expect me to become a customer of yours. The point was that a single 500G hard disk just doesn't cut it for a publically-accessible Debian mirror; that you need much more than that, both in terms of quality (hotpluggable controllers don't really help if your disks aren't ready for hotplugging--which is usually the case for cheap desktop-class hard disks--possibly other interfaces than the popular SATA connection, and preferably also disks that have had way more testing than desktop-class hardware) so that there is this set of cheap crappy hard disks that are large enough so that you can store an entire Debian archive on it is a ridiculous argument in favour of throwing every insanely large piece of junk into a Debian package and onto the Debian archive. Note that that also doesn't talk about *what* exactly defines the line between an insanely large piece of junk and a piece of interesting data large enough to be useful, but not so large as to become a problem. The borderline there would seem to be rather gray. Personally, I'd advice the OP to try to find the smallest data set that is still at least moderately useful for the package, and to package that (so that people not familiar with the software or the type of data it requires can still try it out), unless that would require a package larger than a few tens of megabytes. Additionally, it would be useful to point in the package description and/or its documentation to either a way to automatically generate debs out of a larger data set so that users can generate their own data debs and distribute them on their own network, or to a separate debian archive that they can add to their sources.list if they want. I don't think setting a hard limit (as in, with numbers) on maximum recommended package size is a very good thing to do; I'm tempted to think that this kind of limit is not really static over time, and thus that wording such as roughly two times the average package size at the time the package is created or so would be more appropriate. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
Le lundi 11 juin 2007 à 21:16 +0100, Wouter Verhelst a écrit : The point wasn't that you can't set up a professional RAID array using cheap desktop hard disks; you can, if you really want to, though I wouldn't recommend it. And yes, you're completely free to ignore that particular advise, so long as you don't expect me to become a customer of yours. You seem to strongly believe the cheap desktop hard disk is different from the server hard disk. This is entirely wrong. Apart from 10k and 15k rpm disks, these are all strictly the same. Only the electronics change. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Enter Postpone
Hi,
316 + 0,9K Jun 10 22:32 Debian Installe cb+myon=de
postpone_0.1_amd64.changes is NEW
320 + 0,4K Jun 11 12:30 Debian Installe cb+myon=de
postpone_0.1_amd64.changes ACCEPTED
looks like postpone got fast-tracked in the NEW queue (thanks Joerg!),
so here's what I posted in my blog yesterday again:
--- 8 ---
I just finished implementing postpone [1], a wrapper that is intended
to take an arbitrary command, fork into the background, wait until
some lockfile is freed, and then run the command. Of course the idea
is that the lockfile is /var/lib/dpkg/lock, and that postpone is used
in maintainer scripts. (Update-menus already does that, and I've
basically grabbed that code and generalized it as a separate program.)
As a test implementation, I modified the post{inst,rm} templates in
the tex-common package [2] and rebuilt texlive-lang-* using that. dpkg
-i texlive-lang-*.deb takes over 4 minutes in the old version, but
only a total of 60s with postpone used (35s for dpkg -i plus 25s for
the background jobs).
A Debian package is currently sitting in NEW, let's hope it will
actually get used in maintainer scripts.
[1] http://www.df7cb.de/projects/postpone/
[2] http://www.df7cb.de/projects/postpone/texlive/
--- 8 ---
NB, the .diff in [2] is meant as a test implementation and in fact,
I've probably missed some details in the way fmtutil-sys is called.
(And while looks like an NMU, I don't intend to upload it but will
leave the implementation of the maintainer scripts to the experts.)
There's a few other postinst/postrm jobs that could benefit from
postpone:
* python modules
* emacs
* ldconfig
* install-docs can probably factor out some parts
* update-dictcommon-aspell, aspell-autobuildhash, etc.
* defoma, other font stuff
* scrollkeeper
* anything re-starting some init script (though catching exit code
won't work anymore)
* maybe even update-menus
* ...
Of course, there are cases where running later is not always
appropriate (ldconfig is a candidate), so this need to be decided on a
case-by-case basis.
For good new, the maintainer scripts are most often generated by
debhelper or some other utility, so there's actually not much to
change to use postpone. (Otherwise, only few packages are affected so
there's not much to gain). And there's the question whether to depend
on postpone or have the maintainer script implement both cases
(postrm scripts might need to do this anyway).
Christoph
--
[EMAIL PROTECTED] | http://www.df7cb.de/
signature.asc
Description: Digital signature
SCSI drives for donation
I personally have 6 or 7 U320 73GB 10K RPM SCSI drives that I am not using for anything interesting. Can anyone tell me if these would be useful to Debian or recommend another free software group to donate them? Thanks, wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: arch-all-package shown with two versions on p.d.o
On Sun, Jun 10, 2007 at 06:46:48PM +0200, Frank Küster wrote: Michael Banck [EMAIL PROTECTED] wrote: http://packages.debian.org/cgi-bin/search_packages.pl?keywords=tex-commonsearchon=namessubword=1version=allrelease=all Any idea? I have none, is anyone able to help? Is this a problem in the script that generates packages.debian.org's information, or elsewhere? Will investigate. I'm not looking for an authoritative answer, but rather for useful information on the web, for users and for other developers. Who is responsible for p.d.o? Bugs should be filed against www.debian.org Most pdo pages also have the following footer which might have helped you: To report a problem with the web site, e-mail [EMAIL PROTECTED] Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: arch-all-package shown with two versions on p.d.o (was: Bug#427859: lmodern fails to configure on upgrade, dpkg error)
On Sun, Jun 10, 2007 at 02:17:49PM +0200, Frank Küster wrote: Florent noticed that for tex-common, two versions are listed as being available in testing although the package is Arch: all: Florent Rougon [EMAIL PROTECTED] wrote: BTW, I don't understand why both 1.0.1 and 1.7 are listed for testing at: http://packages.debian.org/cgi-bin/search_packages.pl?keywords=tex-commonsearchon=namessubword=1version=allrelease=all Any idea? I have none, is anyone able to help? Is this a problem in the script that generates packages.debian.org's information, or elsewhere? It was a stale m68k Packages file lying around plus the fact that I still had m68k in the testing architecture list. Should be fixed now. Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Enter Postpone
On Monday 11 June 2007 22:36, Christoph Berg wrote:
As a test implementation, I modified the post{inst,rm} templates in
the tex-common package [2] and rebuilt texlive-lang-* using that. dpkg
-i texlive-lang-*.deb takes over 4 minutes in the old version, but
only a total of 60s with postpone used (35s for dpkg -i plus 25s for
the background jobs).
To be honest, this is exactly an example where I would *NOT* want to see
this implemented.
A major downside of the mechanism supported by this package is that there
is absolutely no check is any errors occur during the running of these
postponed scripts!
In the case of texlive, failure in the script currently leaves the
package unconfigured, which is correct as it may not be usable [1].
Using the mechanism proposed here, the package would happily get the
status fully installed and the user would be none the wiser why he'd
get all these inexplicable errors while using the software.
There's a few other postinst/postrm jobs that could benefit from
postpone:
* [...]
The only case where IMO using this mechanism could be considered is if
failure of the scripts to run correctly has no or only extremely minor
consequences for the correct working of the software, as is I guess the
case for update-menu.
For all other potential use cases, maintainers should wait for the
implementation of triggers in dpkg [2], which is the only correct way to
deal with this issue.
Cheers,
FJP
[1] And that this is not purely theoretical can be shown with the recent
RC bugs (#419020 and friends) against jadetex, which caused failure in
the postinst for all texlive packages which call such scripts.
[2] http://lists.debian.org/debian-dpkg/2007/04/msg6.html
pgp27VaYadMXA.pgp
Description: PGP signature
Upgrade of the pam library?
Hi, As a maintainer of a pam module (pam-keyring), I would like to know if there is any plan to upgrade the version of the libpam in lenny. The current version is antique (0.79 vs 0.99) and doesn't have some features as syslog logging... Regards Laurent pgpd9XLNhRqvV.pgp Description: PGP signature
Re: Using standardized SI prefixes
Am Montag 11 Juni 2007 22:15 schrieb Josselin Mouette: Le lundi 11 juin 2007 à 15:25 -0400, Joey Hess a écrit : You seem to fancy the K-is-1024--k-is-1000 convention No, I hate that convention. K and k should only ever refer to 1024. /me waits for the day measuring jugs are graduated in powers of two, just to please a group of hackers who don't like SI units. And you have to change their world in an useless atempt? Abbreviations are ambiguous by design. Who actually says that KB means kilobyte? I don't like those Special Interest units in all situations ;) As yes, I favour the 1 MB = 1024 KB = 1048576 B HS pgp329bydJAxl.pgp Description: PGP signature
Re: Using standardized SI prefixes
On Mon, June 11, 2007 22:11, Eduard Bloch wrote: In either case, ~ 2 million bytes suits your requirement, or it doesn't. This sounds to me like solving a non-problem, unless you can of course tell me in which situations adding the B or iB in the field above would solve a real question. Excuse me? Pretty simple example: you have only 2.03 GB (real GB) remaining free space (seen in some disk info tool) on your harddisk and you are fetching a 2GB file (2 fake GB, 2GiB in fact). So what, it breaks about 99% and displays some very unexpected message. We are talking about tools like aptitude here, or at least, the OP does. Did you ever have 2 GB free and decided to install a package that would exactly fill that space in? I'm not quite convinced that real world situations exist where you'd use the installed-size parameter of a package in that amount of significance. Even more because the size of a package can grow a bit due to generated files and the like. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Two proposals for a better Lenny (testing related).
I would like to ask you interested in our next release to stop and look at 'testing' for a while. I believe that now, during the start of a development cycle and during debcamp/debconf we've a interesting opportunity to review pros and cons of our current approach. We believe that 'testing' means that things shouldn't break as badly as in unstable or experimental. That's important understand the automatic update concept of unstable and the experimental non-automatic nature. In other words use unstable means that upgrade is dangerous, use unstable and experimental means that you pick how much more of the danger you want from there (experimental). Let me outline the 'testing' pros and cons from my point of view: pros - * testing is under control of release team, it's supposed to be harder to a random developer break our next release * testing is our 'daily updated' release snapshot cons - * testing metric is too simple, packages are allowed to enter testing only after a certain period of time has passed no matter if much people tested it before that and just when they don't have release-critical bugs filed against them. * developers and most active contributors are pretty much using only stable or unstable and not testing. I've two different proposals to address the cons trying to avoid as much as possible create new cons, they are: 1) The 'remove experimental' proposal * Warn developers and contributors[0] * Remove experimental * Switch unstable (release) for not automatic updates [0] = This warning should contain the hint for contributors switch from unstable to testing and those who want to pick unstable stuff do like we do today with experimental. The benefit of the approach above from a RM point of view is that we will have more eyeballs over testing and it doesn't mean that we will have less people using unstable pieces. 2) The 'remove testing' proposal * Add enough experimental autobuilders for our target architectures * Warn developers and contributors that experimental is for transitions and adopt a sort of 'if in doubt upload to experimental' approach. It's really important The developers and contributors might keep using unstable and some pieces of experimental. Things will get harder during freeze, but I believe it's still better than we've today unless developers and contributors don't cooperate out of freeze and ignore the 'experimental if in doubt' approach. Note that it reduces RM team power during the development cycle, the first suggested approach doesn't. be cool, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
In article [EMAIL PROTECTED] you write: -=-=-=-=-=- Le lundi 11 juin 2007 à 21:16 +0100, Wouter Verhelst a écrit : The point wasn't that you can't set up a professional RAID array using cheap desktop hard disks; you can, if you really want to, though I wouldn't recommend it. And yes, you're completely free to ignore that particular advise, so long as you don't expect me to become a customer of yours. You seem to strongly believe the cheap desktop hard disk is different from the server hard disk. This is entirely wrong. Apart from 10k and 15k rpm disks, these are all strictly the same. Only the electronics change. Sorry, but you're utterly wrong. I've worked in the storage industry for several years and in that time I've spoken to engineers working on hard drive design and production. There can be significant physical differences between desktop and enterprise disks including (but not necessarily limited to) data layout, head assemblies, motors, physical damping, platter sizes and materials. The underlying principles are clearly the same, but desktop drives are designed down to a price using cheaper designs and components wherever possible. One of the most common mistakes is to make large arrays of cheap disks. As cheaper disks tend to be less well isolated, vibration and resonance between the different disks can be a major problem and can cause very rapid drive failure. Even worse, this is often provoked in groups such that RAID setups can still fail due to multiple failures. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Can't keep my eyes from the circling sky, Tongue-tied twisted, Just an earth-bound misfit, I... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Mon, Jun 11, 2007 at 10:15:25PM +0200, Josselin Mouette wrote: Le lundi 11 juin 2007 à 15:25 -0400, Joey Hess a écrit : You seem to fancy the K-is-1024--k-is-1000 convention No, I hate that convention. K and k should only ever refer to 1024. /me waits for the day measuring jugs are graduated in powers of two, just to please a group of hackers who don't like SI units. Shall I bring you a half gallon of milk to Scotland, then? Pff, base 10, the metric system is so archaic -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: arch-all-package shown with two versions on p.d.o
Frank Lichtenheld [EMAIL PROTECTED] wrote: It was a stale m68k Packages file lying around plus the fact that I still had m68k in the testing architecture list. Should be fixed now. Ah, many thanks! Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Enter Postpone
Frans Pop [EMAIL PROTECTED] wrote: To be honest, this is exactly an example where I would *NOT* want to see this implemented. A major downside of the mechanism supported by this package is that there is absolutely no check is any errors occur during the running of these postponed scripts! That's exactly the reason why we never did that ourselves. For all other potential use cases, maintainers should wait for the implementation of triggers in dpkg [2], which is the only correct way to deal with this issue. Seconded. Regards, Frank [1] And that this is not purely theoretical can be shown with the recent RC bugs (#419020 and friends) against jadetex, which caused failure in the postinst for all texlive packages which call such scripts. Well, this one is actually a bad example, because it wouldn't happen if the thing was postponed, it's kind of a timing issue. But there are other valid examples of failed TeX commands (by the dozen in the BTS). -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Qt4.3.0 in experimental
hi, Qt4.3.0 was uploaded in experimental. There's some API changes. Please, check your packages works with this new upstream release: Debian Java Maintainers [EMAIL PROTECTED] classpath Debian LyX Maintainers [EMAIL PROTECTED] lyx Jan Niehusmann [EMAIL PROTECTED] psi qca Utopia Maintenance Team [EMAIL PROTECTED] avahi Masami Ichikawa [EMAIL PROTECTED] bookmarkbridge René Mérou [EMAIL PROTECTED] bulmages Steffen Joeris [EMAIL PROTECTED] dc-qt marble Barak A. Pearlmutter [EMAIL PROTECTED] djview4 Florian Ragwitz [EMAIL PROTECTED] esperanza Arnaud Cornet [EMAIL PROTECTED] gnudoq Arnaud Kyheng [EMAIL PROTECTED] gnunet-qt Dmitry E. Oboukhov [EMAIL PROTECTED] hedgewars Steve M. Robbins [EMAIL PROTECTED] ipe Patrick Winnertz [EMAIL PROTECTED] italc Bart Martens [EMAIL PROTECTED] kcheckers marble speedcrunch Reinhard Tartler [EMAIL PROTECTED] keepassx Debian Kolab Maintainers [EMAIL PROTECTED] kolabadmin Juan Manuel Garcia Molina [EMAIL PROTECTED] ktoon John Stamp [EMAIL PROTECTED] lastfm Vincent Fourmond [EMAIL PROTECTED] libqt4-ruby Wesley J. Landaker [EMAIL PROTECTED] mimms Mattias Nordstrom [EMAIL PROTECTED] nzb Benjamin Mesing [EMAIL PROTECTED] packagesearch Mario Iseli [EMAIL PROTECTED] pokerth Ondřej Surý [EMAIL PROTECTED] poppler Torsten Marek [EMAIL PROTECTED] python-qt4 Joop Stakenborg [EMAIL PROTECTED] qantenna Tobias Toedter [EMAIL PROTECTED] qbrew Miguel Gea Milvaques [EMAIL PROTECTED] qdacco Debian GIS Project [EMAIL PROTECTED] qgis Frederic Daniel Luc Lehobey [EMAIL PROTECTED] qrfcview Debian KDE Extras Team [EMAIL PROTECTED] qtemu strigi Debian Multimedia Team [EMAIL PROTECTED] qtractor Gudjon I. Gudjonsson [EMAIL PROTECTED] qwt qwtplot3d Jeremy Lainé [EMAIL PROTECTED] sailcut Bjoern Erik Nilsen [EMAIL PROTECTED] stopmotion Joseph Smidt [EMAIL PROTECTED] texmaker Yann Dirson [EMAIL PROTECTED] tulip A. Maitland Bottoms [EMAIL PROTECTED] vtk Marco Nenciarini [EMAIL PROTECTED] wengophone Debian/Ubuntu wpasupplicant Maintainers [EMAIL PROTECTED] wpasupplicant cheers, Fathi Qt/KDE Team
Re: Using standardized SI prefixes
* Eduard Bloch [EMAIL PROTECTED] [070611 22:27]: Can you tell me in which cases you would make a different decision if this was either 2134*1000 or 2134*1024 bytes? In either case, ~ 2 million bytes suits your requirement, or it doesn't. This sounds to me like solving a non-problem, unless you can of course tell me in which situations adding the B or iB in the field above would solve a real question. Excuse me? Pretty simple example: you have only 2.03 GB (real GB) remaining free space (seen in some disk info tool) on your harddisk and you are fetching a 2GB file (2 fake GB, 2GiB in fact). So what, it breaks about 99% and displays some very unexpected message. Isn't uncompressed size filesystem dependent? (At least the space the package will need when being installed will be). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reasonable maximum package size ?
On Mon, Jun 11, 2007 at 10:11:25PM +0100, Steve McIntyre wrote: In article [EMAIL PROTECTED] you write: -=-=-=-=-=- Le lundi 11 juin 2007 à 21:16 +0100, Wouter Verhelst a écrit : The point wasn't that you can't set up a professional RAID array using cheap desktop hard disks; you can, if you really want to, though I wouldn't recommend it. And yes, you're completely free to ignore that particular advise, so long as you don't expect me to become a customer of yours. You seem to strongly believe the cheap desktop hard disk is different from the server hard disk. This is entirely wrong. Apart from 10k and 15k rpm disks, these are all strictly the same. Only the electronics change. Sorry, but you're utterly wrong. FWIW who is wrong does not matter. If you're not ftpmaster.debian.org or the primary debian mirror or let's say one of the 5 or 6 primary debian mirrors, you don't _need_ to be safe, you just need to be always online. You can achieve that with a simple array of usual desktop (sorry that works well) SATA drives (or even 10k desktop grades sata drives, yes that exists) in a sufficientely redundant raid array. If you choose your hardware properly: * it will be hotpluggable (yes even desktop sata drives supports this), * you will be able to monitor it. * you will be able to change the drives before they fail. Even if you burn 2 500Go disks every 6 months, it will still be cheaper in the end than the carrier-grade hardware that is sold. The really funny part here, is that when time passes, your replacement disks become bigger and bigger, and faster than the archive growth. Isn't it nice ? And even if all of that should fail, rebuilding a debian mirror is fast (I build my x86+amd64 in a few hours behind a dsl line), and costs a fragment of the bandwidth this mirror would consume in the long term anyway. My point is: disk space is expensive because people didn't realized that disks are expendable. Well, some people, google did realize. And would I need to build a very efficient mirror, I'd put my money on the RAM so that the very used parts of the mirror would stay in cache anyways. The other fun part was that my real point was that there is a real problem that is bandwidth, not really for the mirrors sync, but because of the downloads from the clients (I've no real data to backup that claim of course, but if a mirror uses more BW to be kept in sync that what his usual clients use, then its worthless). And yes, unlike disks, bandwidth is still a real real real constraint. Though, I'd say that we could work on distributed mirrors infrastructures, because disk is cheap for our users too, and even a smallish fragment of their bandwidth could be of use. As soon as such a distribution service exists, I've for sure some dozens of gigabyte and 10 to 20 Mbits on a server of mine to be part of the network. _that_ would be 100x more productive than to try to take shortcuts on the archive for bad reasons. PS: Oh and I don't say it's a good idea to see the archive grow just because we have space. I've 2 RM: bugs on old packages of mine that are worthless and uselessly bloat the archive. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpcF2VHIh7KB.pgp Description: PGP signature
Re: ITP: pysycache-- Educational game to teach children to move the mouse
José L. Redrejo wrote: The activities make children practice on clicking, double-clicking, drag and drop, moving and identify the mouse buttons. Since children probably learn this by age five or so with or without help, perhaps the author should focus on making a similar tool for adults instead. :-) Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Monday 11 June 2007 15:10:24 Hendrik Sattler wrote: Am Montag 11 Juni 2007 22:15 schrieb Josselin Mouette: Le lundi 11 juin 2007 à 15:25 -0400, Joey Hess a écrit : You seem to fancy the K-is-1024--k-is-1000 convention No, I hate that convention. K and k should only ever refer to 1024. /me waits for the day measuring jugs are graduated in powers of two, just to please a group of hackers who don't like SI units. And you have to change their world in an useless atempt? Abbreviations are ambiguous by design. Who actually says that KB means kilobyte? Well, in SI units, KB never means kilobyte, and is not ambiguous at all; it's a kelvin·bel. -- Wesley J. Landaker [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 signature.asc Description: This is a digitally signed message part.
Re: Two proposals for a better Lenny (testing related).
Gustavo Franco wrote: * testing metric is too simple, packages are allowed to enter testing only after a certain period of time has passed no matter if much people tested it before that and just when they don't have release-critical bugs filed against them. Of course we have a team of RMs who are able override that and apply as complex a metric as you'd like on a special-case basis. As well as urgency=high in the changelog. The tendency of dependency chains can block transitions, and keep RC bugs open unduely long in testing is a much worse problem with speed of testing migration. Testing also needs periodic snapshots and guaranteed upgradability to be useable by more users, amoung other points I discuss at http://kitenet.net/~joey/code/debian/cut/ * developers and most active contributors are pretty much using only stable or unstable and not testing. What's your data? A fun though not entirely reliable data source is the APT prefers lines inserted by reportbug in bug reports. A quick grep[1] of the BTS gives: 51988 APT prefers unstable 30351 APT prefers testing 2076 APT prefers stable 420 APT prefers experimental 373 APT prefers testing-proposed-updates 220 APT prefers oldstable 190 APT prefers proposed-updates 60 APT prefers dapper-updates 50 APT prefers dapper 30 APT prefers breezy-updates 24 APT prefers edgy-updates 17 APT prefers breezy 16 APT prefers feisty-updates 13 APT prefers edgy 10 APT prefers hoary-updates 10 APT prefers feisty 10 APT prefers breezy-security 7 APT prefers sarge 7 APT prefers etch 7 APT prefers dapper-security (For bonus fun, someone could graph how these change over time..) 1) The 'remove experimental' proposal * Warn developers and contributors[0] * Remove experimental * Switch unstable (release) for not automatic updates [0] = This warning should contain the hint for contributors switch from unstable to testing and those who want to pick unstable stuff do like we do today with experimental. The benefit of the approach above from a RM point of view is that we will have more eyeballs over testing and it doesn't mean that we will have less people using unstable pieces. This assumes that experimental is used by a lot of people, which I doubt, especially given the default apt pins and the numbers above. Experimental is already only rarely uploaded to -- 1 in 20 packages have a version in experimental (some of them outdated). I've seen plenty of cases of developers complaining that they uploaded to experimental and got too little additional testing from doing so. Moving the line between experimental and unstable might drive some people to testing, but I don't feel it will be many, especially as many developers upload even risky changes to unstable already. If you want more users to use testing, see CUT. If you want more developers to use testing, I firstly don't entirely see the point, but providing better tools for developers to develop for unstable while using testing might help. 2) The 'remove testing' proposal Amoung many other problems this postpones most work on the installer until the release it will install is frozen. -- see shy jo [1] [EMAIL PROTECTED]:/org/bugs.debian.org/spool/db-hfind -name \*.log | xargs grep 'APT prefers' | uniq | sed -e 's/.*: *//' -e 's/ *$//' | sort | uniq -c | sort -rn signature.asc Description: Digital signature
Bug#428467: ITP: balance -- Surprisingly successful load balancing solution and generic tcp proxy
Package: wnpp Severity: wishlist Owner: Rafael D'Leon [EMAIL PROTECTED] * Package name: balance Version : 3.35 Upstream Author : Thomas Obermair ([EMAIL PROTECTED]) * URL : http://www.inlab.de/balance.html * License : GPL Programming Lang: C Description : Surprisingly successful load balancing solution and generic tcp proxy Balance is a surprisingly successful load balancing solution being a simple but powerful generic tcp proxy with round robin load balancing and failover mechanisms. Its behaviour can be controlled at runtime using a simple command line syntax. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-ck2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Bastian Venthur [EMAIL PROTECTED] writes: I agree with the sounds stupid part, although I don't belive this is a valid argument. What I don't believe is your 80 colums argument. Could you please name a few of the *many* programs which would have to drop information, precision, or significantly change their display to use the KiB unit? E.g. all of the top-type programs, which display stuff in colums like memory sizes etc, and are _extremely_ starved for space. It would be ludicrous to change the memory size displays in such programs from 224K to 224KiB just to give some obsessive-compulsive types a warm fuzzy. On the other hand, we have the chance to avoid user confusion No one is actually confused. This standard doesn't actually solve a real problem. -Miles -- Whatever you do will be insignificant, but it is very important that you do it. Mahatma Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
Fine. Stick with Kilobytes, but strictly define it as 10^3 bytes. Just choose one over the other and be consistent. On Tue, 2007-06-12 at 01:53 +0900, Miles Bader wrote: shirish [EMAIL PROTECTED] writes: It isn't just ubuntu or debian but this needs to be done everywhere. No it doesn't. The SI binary prefixes are an abomination. Kibibytes? Christ... [Did they try pronouncing these horrid things when standarizing them?!?] -Miles -- We are all lying in the gutter, but some of us are looking at the stars. -Oscar Wilde -- Alex Jones http://alex.weej.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On 6/11/07, Alex Jones [EMAIL PROTECTED] wrote: Fine. Stick with Kilobytes, but strictly define it as 10^3 bytes. Just choose one over the other and be consistent. That's not consistent. Kilobyte has always meant 2^10 bytes. kilo in kilobyte is not an SI prefix. SI prefixes only apply to SI measurements, of which byte is not a member. There is no confusion; the only place where a kilobyte != 2^10 bytes is in hard drive manufacturer's advertising materials. This is the way it has been for decades, and it is a perfectly acceptable and desirable standard. On Tue, 2007-06-12 at 01:53 +0900, Miles Bader wrote: shirish [EMAIL PROTECTED] writes: It isn't just ubuntu or debian but this needs to be done everywhere. No it doesn't. The SI binary prefixes are an abomination. Kibibytes? Christ... [Did they try pronouncing these horrid things when standarizing them?!?] -Miles -- We are all lying in the gutter, but some of us are looking at the stars. -Oscar Wilde -- Alex Jones http://alex.weej.com/ -- Ubuntu-devel-discuss mailing list [EMAIL PROTECTED] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Mark Reitblatt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Mon, 2007-06-11 at 19:56 -0500, Mark Reitblatt wrote: On 6/11/07, Alex Jones [EMAIL PROTECTED] wrote: Fine. Stick with Kilobytes, but strictly define it as 10^3 bytes. Just choose one over the other and be consistent. That's not consistent. Kilobyte has always meant 2^10 bytes. kilo in kilobyte is not an SI prefix. SI prefixes only apply to SI measurements, of which byte is not a member. Then why bastardise an SI prefix? This surely serves only to confuse people. Why don't we invent a new word? Should we call it the thousandbyte? It is simply a convenient accident that 2^10 ~= 10^3. As I'm sure you're well aware, this approximation starts to become way off as you approach tera-. In fact, that's about 10% error, which is simply unacceptable. It's time to move on and accept that the approximation fails with big numbers. There is no confusion; the only place where a kilobyte != 2^10 bytes is in hard drive manufacturer's advertising materials. This is the way it has been for decades, and it is a perfectly acceptable and desirable standard. And I suppose you think that differences such as that between the American and the English ton are acceptable and desirable. Let it be known that I strongly disagree with you here. :) -- Alex Jones http://alex.weej.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Mon, Jun 11, 2007 at 05:39:54PM +0200, Michael Biebl wrote: The frontends imho just need a clear way of showing which packages are going to be installed because of a Depends and which because of a Recommends, so it would be easier to de-select a recommended package. Otherwise there would be no point having Suggests and Recommends, if they are basically treated the same by the package management tool. idea You could scrap the Suggests and Recommends tags all together and use the debtags to relate packages. /idea Just a thought. :-) Chris. == -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SCSI drives for donation
On Mon, Jun 11, 2007 at 02:46:08PM -0600, Warren Turkal wrote: I personally have 6 or 7 U320 73GB 10K RPM SCSI drives that I am not using for anything interesting. Can anyone tell me if these would be useful to Debian or recommend another free software group to donate them? As shipping may be a consideration, in the cost-benefit analysis, it may be useful to say where in the world you are, in a general way, so that someone in the area, who could use them, could reply. -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___| pgp2UP3scD5p8.pgp Description: PGP signature
Re: Two proposals for a better Lenny (testing related).
On Mon, Jun 11, 2007 at 06:20:17PM -0300, Gustavo Franco wrote: I would like to ask you interested in our next release to stop and look at 'testing' for a while. I believe that now, during the start of a development cycle and during debcamp/debconf we've a interesting opportunity to review pros and cons of our current approach. We believe that 'testing' means that things shouldn't break as badly as in unstable or experimental. That's important understand the automatic update concept of unstable and the experimental non-automatic nature. In other words use unstable means that upgrade is dangerous, use unstable and experimental means that you pick how much more of the danger you want from there (experimental). Let me outline the 'testing' pros and cons from my point of view: pros - * testing is under control of release team, it's supposed to be harder to a random developer break our next release * testing is our 'daily updated' release snapshot cons - * testing metric is too simple, packages are allowed to enter testing only after a certain period of time has passed no matter if much people tested it before that and just when they don't have release-critical bugs filed against them. * developers and most active contributors are pretty much using only stable or unstable and not testing. I've two different proposals to address the cons trying to avoid as much as possible create new cons, they are: 1) The 'remove experimental' proposal experimental is not a 'full' branch like stable, testing or unstable. It only has a handfull of package built for it (at least that is what I have seen from reading debian-devel-changes) Also, there is no transition from experimental to unstable. checkout my diagram at http://mysite.verizon.net/kevin.mark/ (there is an older,not updated dia source in spanish if that is helpful) -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___| pgpq8hVMq1eZy.pgp Description: PGP signature
Re: Using standardized SI prefixes
Miles Bader wrote: Bastian Venthur [EMAIL PROTECTED] writes: On the other hand, we have the chance to avoid user confusion No one is actually confused. can you say, in all the thousands of users, not a single one is ever confused? Not a single one ever wonders if it means 1000 or 1024? 1048576 or 100? 1073741824 or 10? This standard doesn't actually solve a real problem. http://physics.nist.gov/cuu/Units/binary.html It does solve a real problem. It solves an ambiguity. Does k mean 1000 or 1024? Does M mean 100 or 1048576? Answer: k mean 1 000 ki means 1 024 m means 1 000 000 mi means 1 048 576 No more ambiguity. Because you see no problem does not mean there is none. If you want to use the ``classical'' SI units as a basis, then look no further than deka: abbreviated da. http://physics.nist.gov/cuu/Units/prefixes.html -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SCSI drives for donation
On Monday 11 June 2007 21:52:09 Kevin Mark wrote: As shipping may be a consideration, in the cost-benefit analysis, it may be useful to say where in the world you are, in a general way, so that someone in the area, who could use them, could reply. I will ship anywhere in the US. Exporting them would have to be investigated. Thanks, wt -- Warren Turkal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SCSI drives for donation
On Mon, Jun 11, 2007 at 02:46:08PM -0600, Warren Turkal wrote: I personally have 6 or 7 U320 73GB 10K RPM SCSI drives that I am not using for anything interesting. Can anyone tell me if these would be useful to Debian or recommend another free software group to donate them? The m68k port is nearly always in need for SCSI replacement disks for their ~20 m68k buildds. Some boxes just have 9 GB drives for multiple chroots, which causes some build failures from time to time because the disks have no free space anymore. One buildd is currently down because of SCSI disk problems as well. So, the m68k port has the need for some larger disks, especially when those disks are usuable with a standard 50 pin SCSI cable. It would be nice if you could send us one or more disks. Stephen Marenka is located in the US while I'm located in Germany (as most m68k buildds as well). CC'ing him. -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using standardized SI prefixes
On Mon, Jun 11, 2007 at 02:32:35PM -0700, Steve Langasek wrote: On Mon, Jun 11, 2007 at 10:15:25PM +0200, Josselin Mouette wrote: Le lundi 11 juin 2007 à 15:25 -0400, Joey Hess a écrit : You seem to fancy the K-is-1024--k-is-1000 convention No, I hate that convention. K and k should only ever refer to 1024. /me waits for the day measuring jugs are graduated in powers of two, just to please a group of hackers who don't like SI units. Shall I bring you a half gallon of milk to Scotland, then? Pff, base 10, the metric system is so archaic The US gallon being the Queen Anne period wine gallon or 0.83 gallons? I'll stick to Imperial thanks - four pints will be fine in anywhere in Scotland/England/Ireland/Wales and I'll get slightly more :) Fuel consumption in UK is defined as relative to the (Imperial) gallon: the Spanish Empire,of course, did far better - in a good year they got several thousand miles to the galleon :) Andy K or k in a computer context, is, OF COURSE, 1024 :)
Re: SCSI drives for donation
On Mon, Jun 11, 2007 at 11:19:00PM -0600, Warren Turkal wrote: On Monday 11 June 2007 21:52:09 Kevin Mark wrote: As shipping may be a consideration, in the cost-benefit analysis, it may be useful to say where in the world you are, in a general way, so that someone in the area, who could use them, could reply. I will ship anywhere in the US. Exporting them would have to be investigated. Oddly enough if you had posted this a bit earlyer, one of the US folks who will attend Debconf (this year in the UK) could have brought it with them. This would make it easy to directly give it to many folks who are part of Debian. Although it may still be possible, if it is done in an extreamly timely manner, as Debconf is June 17th-23rd. Maybe There should be some announment a month or two before debconf so that hardware donations can be co-ordinated around it and the participants -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___| pgpMYDRHxE9kH.pgp Description: PGP signature
Accepted php-xajax 0.2.5-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 06 Jun 2007 11:00:17 +0200 Source: php-xajax Binary: php-xajax Architecture: source all Version: 0.2.5-2 Distribution: unstable Urgency: low Maintainer: David Gil [EMAIL PROTECTED] Changed-By: David Gil [EMAIL PROTECTED] Description: php-xajax - A library to develop Ajax applications Closes: 427686 Changes: php-xajax (0.2.5-2) unstable; urgency=low . * Fixed Undefined variable: sResponse notice (Closes: #427686) Files: eb4340bde825dc43b86c28899c5f32f3 628 web optional php-xajax_0.2.5-2.dsc 4f3b17ae43baed17a69e70e7804b38e7 3373 web optional php-xajax_0.2.5-2.diff.gz b3ce33375a2a7fbf018e762004c95f35 46712 web optional php-xajax_0.2.5-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGbOc7sandgtyBSwkRAkmqAJ0XxpHunp8Pb3bs+JhqKDMpify3+ACfRE34 MKZUHiBIdLfwmtp1OZgcjCU= =ZwSS -END PGP SIGNATURE- Accepted: php-xajax_0.2.5-2.diff.gz to pool/main/p/php-xajax/php-xajax_0.2.5-2.diff.gz php-xajax_0.2.5-2.dsc to pool/main/p/php-xajax/php-xajax_0.2.5-2.dsc php-xajax_0.2.5-2_all.deb to pool/main/p/php-xajax/php-xajax_0.2.5-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dmake 1:4.8~cvs20070706-1 (source powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 06 Jun 2007 18:02:28 +0200 Source: dmake Binary: dmake Architecture: source powerpc Version: 1:4.8~cvs20070706-1 Distribution: experimental Urgency: low Maintainer: Debian OpenOffice Team [EMAIL PROTECTED] Changed-By: Rene Engelhard [EMAIL PROTECTED] Description: dmake - make utility used to build OpenOffice.org Changes: dmake (1:4.8~cvs20070706-1) experimental; urgency=low . * new upstream snapshot (cws_src680_dmake48) Files: e2d560cadcea7ab6797cab15905f3450 708 devel extra dmake_4.8~cvs20070706-1.dsc 0b2642e300b63e3680a25459cba7b29e 709214 devel extra dmake_4.8~cvs20070706.orig.tar.gz 0ee981917fa3209c0bb24766cdf02949 9306 devel extra dmake_4.8~cvs20070706-1.diff.gz 96993dddbc0c05d7d279ad4700a42223 139136 devel extra dmake_4.8~cvs20070706-1_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGZt1B+FmQsCSK63MRApaEAJ9jDYS+yO/iij5YjgBWmn/H7MJJ/gCeMx61 A50UpZHsMlXdV2Py5YPsOyY= =TPij -END PGP SIGNATURE- Accepted: dmake_4.8~cvs20070706-1.diff.gz to pool/main/d/dmake/dmake_4.8~cvs20070706-1.diff.gz dmake_4.8~cvs20070706-1.dsc to pool/main/d/dmake/dmake_4.8~cvs20070706-1.dsc dmake_4.8~cvs20070706-1_powerpc.deb to pool/main/d/dmake/dmake_4.8~cvs20070706-1_powerpc.deb dmake_4.8~cvs20070706.orig.tar.gz to pool/main/d/dmake/dmake_4.8~cvs20070706.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libapache2-mod-fcgid 1:2.1-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 02 Jun 2007 18:01:15 +0900 Source: libapache2-mod-fcgid Binary: libapache2-mod-fcgid Architecture: source i386 Version: 1:2.1-2 Distribution: unstable Urgency: medium Maintainer: Taku YASUI [EMAIL PROTECTED] Changed-By: Tatsuki Sugiura [EMAIL PROTECTED] Description: libapache2-mod-fcgid - an alternative module compat with mod_fastcgi Closes: 427046 427120 Changes: libapache2-mod-fcgid (1:2.1-2) unstable; urgency=medium . * Add proper dependency by shlibs:Depends (Closes: #427046, #427120) Files: 50e03b7616a715807772e05c5f863ef3 724 web optional libapache2-mod-fcgid_2.1-2.dsc f8996d9a1ab951ea69dc386af166f57a 6526 web optional libapache2-mod-fcgid_2.1-2.diff.gz 13ab11c3879ac29a4bcb65b37be5e9a7 40180 web optional libapache2-mod-fcgid_2.1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGbPd7FwU5DuZsm7ARAj+IAKDJFaYGE9hA85HGDk1M1tQ6DvPoRgCZASnN 2WGibxNRmgxSSdDcKHbVvQ8= =v21i -END PGP SIGNATURE- Accepted: libapache2-mod-fcgid_2.1-2.diff.gz to pool/main/liba/libapache2-mod-fcgid/libapache2-mod-fcgid_2.1-2.diff.gz libapache2-mod-fcgid_2.1-2.dsc to pool/main/liba/libapache2-mod-fcgid/libapache2-mod-fcgid_2.1-2.dsc libapache2-mod-fcgid_2.1-2_i386.deb to pool/main/liba/libapache2-mod-fcgid/libapache2-mod-fcgid_2.1-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ckermit 211-8 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 09 Jun 2007 23:12:49 +0100 Source: ckermit Binary: ckermit Architecture: source i386 Version: 211-8 Distribution: unstable Urgency: low Maintainer: Ian Beckwith [EMAIL PROTECTED] Changed-By: Ian Beckwith [EMAIL PROTECTED] Description: ckermit- a serial and network communications package Changes: ckermit (211-8) unstable; urgency=low . * Change netbase dependency to openbsd-inetd | inet-superserver. * Tweak debconf templates to keep lintian happy. * Bumped debconf compatability level to 5. * Tidied debian/rules. Files: c408c11856341e293e4bb07894406702 617 non-free/comm extra ckermit_211-8.dsc 4018ebcbeb7ba76ba288682008dc4d9c 35257 non-free/comm extra ckermit_211-8.diff.gz 55a9426254e65a6f94f217261715d637 1621386 non-free/comm extra ckermit_211-8_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGbQZa+C5cwEsrK54RAvbFAJ0U/QUmXUP5uvcovJytifMD14NooQCg3V15 b7SDHgbW6TpPtl7RyN66VVg= =/w8P -END PGP SIGNATURE- Accepted: ckermit_211-8.diff.gz to pool/non-free/c/ckermit/ckermit_211-8.diff.gz ckermit_211-8.dsc to pool/non-free/c/ckermit/ckermit_211-8.dsc ckermit_211-8_i386.deb to pool/non-free/c/ckermit/ckermit_211-8_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tex-common 1.8 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 11 Jun 2007 10:14:14 +0200 Source: tex-common Binary: tex-common Architecture: source all Version: 1.8 Distribution: unstable Urgency: medium Maintainer: Debian TeX maintainers [EMAIL PROTECTED] Changed-By: Frank Küster [EMAIL PROTECTED] Description: tex-common - Common infrastructure for using and building TeX in Debian Closes: 409897 418983 426881 427562 Changes: tex-common (1.8) unstable; urgency=medium . * Bump urgency since this fixes a RC bug which hits anyone upgrading from lenny to sid and triggers a forkbomb. Urgency only medium because of the long list of unrelated other changes. [fk] * Add a workaround for the fork bomb problem in format generation: Ignore jadetex and xmltex if latex is not present (closes: #427562) [fk] * make proper ucfr checking in maintainer scripts (Closes: #409897) [np] * rework the code generated by dh_installtex in the postinst script. Now at postinst/configure time fmtutil-sys is called with --all --cnffile file where file are the fmt.d config files installed by the package. This way a dpkg-reconfigure will create *all* formats defined in the config file, even if the sysadm has defined additional formats. (Closes: #418983) [np] * Update snippets in texmf.d according to a reordering patch accepted upstream [fk] * (first) rework of Debian-on-TeX document for TeX Live only [np] * add a list of old files from teTeX which can be removed * Do not install unused 01tetex.cnf and its md5sum file [fk] * dh_installtex: rewrite $engine to metafont if $engine = mf|mf-nowin * Install a copy of mktex.cnf in /usr/share/tex-common, and advice in NEWS.Debian to reinstall it. [fk] * Debconf translations: Added Vietnamese translation, thanks to Clytie Siddall [EMAIL PROTECTED] (closes: #426881) * implement an opion --nosourcefiles for tpm2licenses to not check source files * Add symlinks README.Debian.$ext to the respective TeX-on-Debian formats. [fk] Files: 7220234260a555862e3c8f8a54e92505 794 tex optional tex-common_1.8.dsc c782db53a30ed4693c4b085f18ca50d4 802336 tex optional tex-common_1.8.tar.gz d05797984a0698ec63f7151d7f32bf4a 710646 tex optional tex-common_1.8_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGbQW1+xs9YyJS+hoRAlDqAKCgLgR8baOkPN7bQrMk/E4Tu7H5HgCeK9ex ncQvWYTtGe5TthnwSpJPZxI= =tc5k -END PGP SIGNATURE- Accepted: tex-common_1.8.dsc to pool/main/t/tex-common/tex-common_1.8.dsc tex-common_1.8.tar.gz to pool/main/t/tex-common/tex-common_1.8.tar.gz tex-common_1.8_all.deb to pool/main/t/tex-common/tex-common_1.8_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gst-plugins-good0.10 0.10.5-7 (source i386 all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sun, 10 Jun 2007 22:58:34 +0200
Source: gst-plugins-good0.10
Binary: gstreamer0.10-plugins-good-doc gstreamer0.10-plugins-good
gstreamer0.10-esd gstreamer0.10-plugins-good-dbg
Architecture: source i386 all
Version: 0.10.5-7
Distribution: unstable
Urgency: low
Maintainer: Maintainers of GStreamer packages [EMAIL PROTECTED]
Changed-By: Sebastian Dröge [EMAIL PROTECTED]
Description:
gstreamer0.10-esd - GStreamer plugin for ESD
gstreamer0.10-plugins-good - GStreamer plugins from the good set
gstreamer0.10-plugins-good-dbg - GStreamer plugins from the good set
gstreamer0.10-plugins-good-doc - GStreamer documentation for plugins from the
good set
Closes: 426647 427744
Changes:
gst-plugins-good0.10 (0.10.5-7) unstable; urgency=low
.
* debian/control.in:
+ Use ${binary:Version} instead of ${Source-Version} to make lintian happy.
* debian/patches/40_flac1.1.3.patch:
+ Patch from upstream CVS to work with flac = 1.1.3. (Closes: #427744,
#426647).
http://bugzilla.gnome.org/show_bug.cgi?id=385887
* debian/patches/99_autoreconf.patch:
+ Regenerate configure for the above change.
Files:
c42000de3747be3bc0a155ea2d476e07 1967 libs optional
gst-plugins-good0.10_0.10.5-7.dsc
27d93e8f9c872a95d69ac5dce9dd4c3d 48231 libs optional
gst-plugins-good0.10_0.10.5-7.diff.gz
5c434352a783c32109badccae5fc2e82 105966 doc optional
gstreamer0.10-plugins-good-doc_0.10.5-7_all.deb
1389b46113b10e8a50f3c6d493340ebf 37712 libs optional
gstreamer0.10-esd_0.10.5-7_i386.deb
aa031aaac836a9385eac15eacbc1 675022 libs optional
gstreamer0.10-plugins-good_0.10.5-7_i386.deb
2172a45e6b4b661bd99f4bde5d7f12d2 1850432 libdevel extra
gstreamer0.10-plugins-good-dbg_0.10.5-7_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGbGzeBsBdh1vkHyERAhllAKCpK/V5ZuovQgxStsAhABRNedcpSACfdOzH
lQz6+sXBzjBLhRWUSTHxV3g=
=FigM
-END PGP SIGNATURE-
Accepted:
gst-plugins-good0.10_0.10.5-7.diff.gz
to pool/main/g/gst-plugins-good0.10/gst-plugins-good0.10_0.10.5-7.diff.gz
gst-plugins-good0.10_0.10.5-7.dsc
to pool/main/g/gst-plugins-good0.10/gst-plugins-good0.10_0.10.5-7.dsc
gstreamer0.10-esd_0.10.5-7_i386.deb
to pool/main/g/gst-plugins-good0.10/gstreamer0.10-esd_0.10.5-7_i386.deb
gstreamer0.10-plugins-good-dbg_0.10.5-7_i386.deb
to
pool/main/g/gst-plugins-good0.10/gstreamer0.10-plugins-good-dbg_0.10.5-7_i386.deb
gstreamer0.10-plugins-good-doc_0.10.5-7_all.deb
to
pool/main/g/gst-plugins-good0.10/gstreamer0.10-plugins-good-doc_0.10.5-7_all.deb
gstreamer0.10-plugins-good_0.10.5-7_i386.deb
to
pool/main/g/gst-plugins-good0.10/gstreamer0.10-plugins-good_0.10.5-7_i386.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pcproxy 1.1.1-3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 11 Jun 2007 10:21:00 +0200 Source: pcproxy Binary: pcproxy Architecture: source all Version: 1.1.1-3 Distribution: unstable Urgency: low Maintainer: Debian QA Group [EMAIL PROTECTED] Changed-By: Michael Ablassmeier [EMAIL PROTECTED] Description: pcproxy- A masquerading proxy for flight simulation networks Closes: 246670 390251 Changes: pcproxy (1.1.1-3) unstable; urgency=low . * QA upload. * Set maintainer to QA Group; Orphaned: #425751 * Add |wish to dependencies, remove obsolete tk8.0 and tk8.2 (Closes: #246670) * Fix Spelling mistake in description (Closes: #390251) * Remove debian/conffiles - not necessary anymore * Update debian/copyright * Move debhelper from B-D-I to B-D * Conforms with latest Standards Version 3.7.2 Files: 4b4087690747099da6c8723f29081a7e 569 games optional pcproxy_1.1.1-3.dsc c3eb3dd6a43f89c96a527e9bcb64b926 18098 games optional pcproxy_1.1.1-3.diff.gz 7b8909032704225a883b73563d610757 38478 games optional pcproxy_1.1.1-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGbQe3EFV7g4B8rCURAsBqAKDgORppghEKC3mbS5/QdmKxs+0LEwCfZgCZ S1eNg7OlIyV5keMLzFHaJC4= =43XJ -END PGP SIGNATURE- Accepted: pcproxy_1.1.1-3.diff.gz to pool/main/p/pcproxy/pcproxy_1.1.1-3.diff.gz pcproxy_1.1.1-3.dsc to pool/main/p/pcproxy/pcproxy_1.1.1-3.dsc pcproxy_1.1.1-3_all.deb to pool/main/p/pcproxy/pcproxy_1.1.1-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linhdd 0.3-3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 10 Jun 2007 18:15:41 +0530 Source: linhdd Binary: linhdd Architecture: source all Version: 0.3-3 Distribution: unstable Urgency: low Maintainer: Kartik Mistry [EMAIL PROTECTED] Changed-By: Kartik Mistry [EMAIL PROTECTED] Description: linhdd - GTK frontend for cfdisk/df/hdparm/mkfs Changes: linhdd (0.3-3) unstable; urgency=low . * Added missing .desktop file * debian/rules: set build rule to build:indep as package is arch:all, minor cleanups * debian/README.Debian: corrected to standard README format Files: 1ef5b2d44f8aaf1b4b3585ac37b4bfcf 552 x11 optional linhdd_0.3-3.dsc a8e0733d73f2723a23290ca022fd55a3 5001 x11 optional linhdd_0.3-3.diff.gz 61cc1c7ec15233e6c9a43aa6bfb2259f 12928 x11 optional linhdd_0.3-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGbQWf+C5cwEsrK54RAm+KAJ0cy+8rJa0EE0ym3e99kQEihGV3/QCggLaK /OEQyUig3AtmZorGSdjbOQc= =DsFK -END PGP SIGNATURE- Accepted: linhdd_0.3-3.diff.gz to pool/main/l/linhdd/linhdd_0.3-3.diff.gz linhdd_0.3-3.dsc to pool/main/l/linhdd/linhdd_0.3-3.dsc linhdd_0.3-3_all.deb to pool/main/l/linhdd/linhdd_0.3-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnome-commander 1.2.4-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 11 Jun 2007 09:37:03 +0200 Source: gnome-commander Binary: gnome-commander Architecture: source i386 Version: 1.2.4-1 Distribution: unstable Urgency: low Maintainer: Michael Vogt [EMAIL PROTECTED] Changed-By: Michael Vogt [EMAIL PROTECTED] Description: gnome-commander - nice and fast file manager for the GNOME desktop Changes: gnome-commander (1.2.4-1) unstable; urgency=low . * New upstream release Files: 99cc4fe747ea4db4c51cf2da443e7d15 768 gnome optional gnome-commander_1.2.4-1.dsc ef3268294dfb5768fa931ac36bc7db0f 2711846 gnome optional gnome-commander_1.2.4.orig.tar.gz 2dc4b42531ca65cabc73ff69201d6d7a 2391 gnome optional gnome-commander_1.2.4-1.diff.gz 5b12baa4a554e1c37ae4e18848a05185 1589222 gnome optional gnome-commander_1.2.4-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGbP7cliSD4VZixzQRAruzAJ4hb/5r9/p4EdCHmTPq1TwFCT7BFgCfenYG d3QrxBzFb5NR/tzOgE3pTAM= =UvQc -END PGP SIGNATURE- Accepted: gnome-commander_1.2.4-1.diff.gz to pool/main/g/gnome-commander/gnome-commander_1.2.4-1.diff.gz gnome-commander_1.2.4-1.dsc to pool/main/g/gnome-commander/gnome-commander_1.2.4-1.dsc gnome-commander_1.2.4-1_i386.deb to pool/main/g/gnome-commander/gnome-commander_1.2.4-1_i386.deb gnome-commander_1.2.4.orig.tar.gz to pool/main/g/gnome-commander/gnome-commander_1.2.4.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mklibs 0.1.23 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 11 Jun 2007 07:56:06 + Source: mklibs Binary: mklibs mklibs-copy Architecture: source all i386 Version: 0.1.23 Distribution: unstable Urgency: low Maintainer: Debian Install System Team [EMAIL PROTECTED] Changed-By: Bastian Blank [EMAIL PROTECTED] Description: mklibs - Shared library reduction script mklibs-copy - Shared library reduction script Changes: mklibs (0.1.23) unstable; urgency=low . * Fix ld name detection. Files: 398e943f06ffad499aed2a88f3f2dee3 741 devel optional mklibs_0.1.23.dsc e7c66a4db3c25b8515a9aa9350262e26 111038 devel optional mklibs_0.1.23.tar.gz 99ba0f62e71c6c4e97bc147b674624d4 33020 devel optional mklibs-copy_0.1.23_i386.deb 4e2dfed3c7fff7caeba46ca2be0f3527 11436 devel optional mklibs_0.1.23_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iEYEARECAAYFAkZtARAACgkQLkAIIn9ODhE7fwCg1RcdfPFWouZecq3rCWgFQTCQ a6UAoK7U9ue4gyQtK4z8lzYqAFXhOKE6 =6IP9 -END PGP SIGNATURE- Accepted: mklibs-copy_0.1.23_i386.deb to pool/main/m/mklibs/mklibs-copy_0.1.23_i386.deb mklibs_0.1.23.dsc to pool/main/m/mklibs/mklibs_0.1.23.dsc mklibs_0.1.23.tar.gz to pool/main/m/mklibs/mklibs_0.1.23.tar.gz mklibs_0.1.23_all.deb to pool/main/m/mklibs/mklibs_0.1.23_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kde-style-qtcurve 0.51-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 11 Jun 2007 10:42:01 +0200 Source: kde-style-qtcurve Binary: qtcurve kde-style-qtcurve Architecture: source i386 Version: 0.51-1 Distribution: unstable Urgency: low Maintainer: Bastian Venthur [EMAIL PROTECTED] Changed-By: Bastian Venthur [EMAIL PROTECTED] Description: kde-style-qtcurve - This is a set of widget styles for KDE3 based apps qtcurve- This is a set of widget styles for KDE3 and Gtk2 based apps Closes: 427043 Changes: kde-style-qtcurve (0.51-1) unstable; urgency=low . * New upstream version (Closes: #427043) . * Changed shading to use HSL colour space. This can be altered by editing $XDG_CONFIG_HOME/qtcurvestylerc and setting 'shading=simple' for the previous method, or 'shading=hsv' to use HSV. * Add options: Border all of menu/toolbars. Darker borders. 'V' arrows. * Fix raised listview headers. * Fix glass style menuitem appearance. * Modifed look of dullglass, looks softer * Improve look of plastik mouse-over for non coloured scrollbars. * For disabled buttons, use standard fill but lighten border. * Use darker colours for mouse-over and default button - helps with light colour schemes. * Dont draw sunken panel around checked menuitems. * Fix karm (and others?) statusbar icon. * Fix for radio buttons in apps where QApplication::NormalColor!=QApplication::colorSpec() (e.g. designer) Files: a747c259562fe32830b762acac146098 648 kde extra kde-style-qtcurve_0.51-1.dsc 00b3d78efc530872f22256e24e31c852 607483 kde extra kde-style-qtcurve_0.51.orig.tar.gz f493835c714d6e9dfda76664efe4700d 2876 kde extra kde-style-qtcurve_0.51-1.diff.gz 32fc07298bce90d3628f414703dd0eb2 150496 kde extra kde-style-qtcurve_0.51-1_i386.deb f2ed18d648de4f7cd60e7cd9a0342a13 15696 kde extra qtcurve_0.51-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGbQwwmj66P/Yfc/gRArWNAJ9YSCUqVW7GFgK/cYpOMV5TmnM1zQCfcedB Nfw4FflHhhWG7jOSUyafr0I= =8Xce -END PGP SIGNATURE- Accepted: kde-style-qtcurve_0.51-1.diff.gz to pool/main/k/kde-style-qtcurve/kde-style-qtcurve_0.51-1.diff.gz kde-style-qtcurve_0.51-1.dsc to pool/main/k/kde-style-qtcurve/kde-style-qtcurve_0.51-1.dsc kde-style-qtcurve_0.51-1_i386.deb to pool/main/k/kde-style-qtcurve/kde-style-qtcurve_0.51-1_i386.deb kde-style-qtcurve_0.51.orig.tar.gz to pool/main/k/kde-style-qtcurve/kde-style-qtcurve_0.51.orig.tar.gz qtcurve_0.51-1_i386.deb to pool/main/k/kde-style-qtcurve/qtcurve_0.51-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gtk2-engines-qtcurve 0.51-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 11 Jun 2007 10:26:42 +0200 Source: gtk2-engines-qtcurve Binary: gtk2-engines-qtcurve Architecture: source i386 Version: 0.51-1 Distribution: unstable Urgency: low Maintainer: Bastian Venthur [EMAIL PROTECTED] Changed-By: Bastian Venthur [EMAIL PROTECTED] Description: gtk2-engines-qtcurve - This is a set of widget styles for Gtk2 based apps Closes: 427040 427873 427874 Changes: gtk2-engines-qtcurve (0.51-1) unstable; urgency=low . * New Upstream version (Closes: #427040) * Corrected recommends-field (Closes: #427873) * Removed debian/dirs (Closes: #427874) . * Changed shading to use HSL colour space. This can be altered by editing $XDG_CONFIG_HOME/qtcurvestylerc and setting 'shading=simple' for the previous method, or 'shading=hsv' to use HSV. * Add options: Border all of menu/toolbars. Darker borders. 'V' arrows. * Fix raised listview headers. * Fix glass style menuitem appearance. * Modifed look of dullglass, looks softer * Improve look of plastik mouse-over for non coloured scrollbars. * For disabled buttons, use standard fill but lighten border. * Use darker colours for mouse-over and default button - helps with light colour schemes. * Dont draw sunken panel around checked menuitems. * If the app is a Java app, and its g_get_application_name()!=unknown, then assume its a SWT java app - in which case treat as a standard app. For Swing apps some functionality is disabled. * Fix tabs in thunderbird. Files: fcc467a035efa1591da7fb9cfe85bda0 639 gnome extra gtk2-engines-qtcurve_0.51-1.dsc 634530a113b9c41834d27b79e9a3177c 395157 gnome extra gtk2-engines-qtcurve_0.51.orig.tar.gz 879780397d7b47c69b0462776e230a6e 2997 gnome extra gtk2-engines-qtcurve_0.51-1.diff.gz c5d6d67a8e8bba303c50ea5333d59a50 80470 gnome extra gtk2-engines-qtcurve_0.51-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGbQukmj66P/Yfc/gRArBTAJ95T4REVh0PCePTqCoc0fX+BxvK0gCePpLe blsE0wXNpep6e9WroB630Bw= =DgTO -END PGP SIGNATURE- Accepted: gtk2-engines-qtcurve_0.51-1.diff.gz to pool/main/g/gtk2-engines-qtcurve/gtk2-engines-qtcurve_0.51-1.diff.gz gtk2-engines-qtcurve_0.51-1.dsc to pool/main/g/gtk2-engines-qtcurve/gtk2-engines-qtcurve_0.51-1.dsc gtk2-engines-qtcurve_0.51-1_i386.deb to pool/main/g/gtk2-engines-qtcurve/gtk2-engines-qtcurve_0.51-1_i386.deb gtk2-engines-qtcurve_0.51.orig.tar.gz to pool/main/g/gtk2-engines-qtcurve/gtk2-engines-qtcurve_0.51.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted empathy 0.7-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 11 Jun 2007 10:31:19 +0200 Source: empathy Binary: empathy Architecture: source i386 Version: 0.7-1 Distribution: unstable Urgency: low Maintainer: Telepathy Maintaince Team [EMAIL PROTECTED] Changed-By: Sjoerd Simons [EMAIL PROTECTED] Description: empathy- High-level library and user-interface for Telepathy Changes: empathy (0.7-1) unstable; urgency=low . * New upstream release Files: 193e564cde497f0061e30c910158165b 973 gnome optional empathy_0.7-1.dsc e1582652a5fb7fb23570b0dab7d3a9bc 1160599 gnome optional empathy_0.7.orig.tar.gz 744c8b9cbc7d72c3519ecf14c4a18668 1920 gnome optional empathy_0.7-1.diff.gz 7569ff23d7f988e80d33cd8f1f975131 526078 gnome optional empathy_0.7-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGbRHRgTd+SodosdIRAiqsAKCI1WUR0+m/GWw8DG1xSlqjcXZO4ACeLd2L ou+PSqqS2ZQLiQg8jJg+WDc= =hBtX -END PGP SIGNATURE- Accepted: empathy_0.7-1.diff.gz to pool/main/e/empathy/empathy_0.7-1.diff.gz empathy_0.7-1.dsc to pool/main/e/empathy/empathy_0.7-1.dsc empathy_0.7-1_i386.deb to pool/main/e/empathy/empathy_0.7-1_i386.deb empathy_0.7.orig.tar.gz to pool/main/e/empathy/empathy_0.7.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kde-style-qtcurve 0.51-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 11 Jun 2007 11:21:00 +0200 Source: kde-style-qtcurve Binary: qtcurve kde-style-qtcurve Architecture: source i386 Version: 0.51-2 Distribution: unstable Urgency: low Maintainer: Bastian Venthur [EMAIL PROTECTED] Changed-By: Bastian Venthur [EMAIL PROTECTED] Description: kde-style-qtcurve - This is a set of widget styles for KDE3 based apps qtcurve- This is a set of widget styles for KDE3 and Gtk2 based apps Changes: kde-style-qtcurve (0.51-2) unstable; urgency=low . * Changed priority from extra to optional Files: 5fc901a2f18d3e215185d35f9b68b8a4 648 kde optional kde-style-qtcurve_0.51-2.dsc e80b3beb2abb033a84e595e22d286541 2904 kde optional kde-style-qtcurve_0.51-2.diff.gz 50ff152882358e0d84df3acf8feeced9 150544 kde optional kde-style-qtcurve_0.51-2_i386.deb 502e14bac3a6dcda2fdfe9c6762376fd 15728 kde optional qtcurve_0.51-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGbRUimj66P/Yfc/gRAiLgAJ4yFPRx2q6bIv0kStuQ43AhdxbQZQCfaHJO 0IFG6oX/lQS8QSwxRamsFc0= =SYl8 -END PGP SIGNATURE- Accepted: kde-style-qtcurve_0.51-2.diff.gz to pool/main/k/kde-style-qtcurve/kde-style-qtcurve_0.51-2.diff.gz kde-style-qtcurve_0.51-2.dsc to pool/main/k/kde-style-qtcurve/kde-style-qtcurve_0.51-2.dsc kde-style-qtcurve_0.51-2_i386.deb to pool/main/k/kde-style-qtcurve/kde-style-qtcurve_0.51-2_i386.deb qtcurve_0.51-2_i386.deb to pool/main/k/kde-style-qtcurve/qtcurve_0.51-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gtk2-engines-qtcurve 0.51-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 11 Jun 2007 11:20:11 +0200 Source: gtk2-engines-qtcurve Binary: gtk2-engines-qtcurve Architecture: source i386 Version: 0.51-2 Distribution: unstable Urgency: low Maintainer: Bastian Venthur [EMAIL PROTECTED] Changed-By: Bastian Venthur [EMAIL PROTECTED] Description: gtk2-engines-qtcurve - This is a set of widget styles for Gtk2 based apps Changes: gtk2-engines-qtcurve (0.51-2) unstable; urgency=low . * Changed priority from extra to optional Files: aee2e5165ed3285b43af1ea18d7098e2 639 gnome optional gtk2-engines-qtcurve_0.51-2.dsc d36d1d64a697701e0e718a4aaa18d55a 3027 gnome optional gtk2-engines-qtcurve_0.51-2.diff.gz 4d8d93414324111fd6be555ded83f82f 80512 gnome optional gtk2-engines-qtcurve_0.51-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGbRVSmj66P/Yfc/gRAvSIAJwKxq4mflV26/Eh2dWKBGTonxxQuwCgh4Rt o1Mv/3JWSeqrUXeR02IFhSE= =Oea2 -END PGP SIGNATURE- Accepted: gtk2-engines-qtcurve_0.51-2.diff.gz to pool/main/g/gtk2-engines-qtcurve/gtk2-engines-qtcurve_0.51-2.diff.gz gtk2-engines-qtcurve_0.51-2.dsc to pool/main/g/gtk2-engines-qtcurve/gtk2-engines-qtcurve_0.51-2.dsc gtk2-engines-qtcurve_0.51-2_i386.deb to pool/main/g/gtk2-engines-qtcurve/gtk2-engines-qtcurve_0.51-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted swh-plugins 0.4.15-0.1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 4 Jun 2007 23:42:38 +0200 Source: swh-plugins Binary: swh-plugins Architecture: source amd64 Version: 0.4.15-0.1 Distribution: unstable Urgency: low Maintainer: Anand Kumria [EMAIL PROTECTED] Changed-By: Free Ekanayaka [EMAIL PROTECTED] Description: swh-plugins - Steve Harris's LADSPA plugins Changes: swh-plugins (0.4.15-0.1) unstable; urgency=low . * Non-Maintainer Upload * New upstream release (Closes :#324188) * Bumped Standards-Version to 3.7.2 Files: c2fcf27c967bcd7249fb764258bc0b9c 662 sound optional swh-plugins_0.4.15-0.1.dsc 2fbdccef2462ea553901acd429fa3573 1051623 sound optional swh-plugins_0.4.15.orig.tar.gz d5d4ee59bceeaef7a01a4776d7766293 25469 sound optional swh-plugins_0.4.15-0.1.diff.gz 96775696f1e6e2764208f8e1bf76da0b 606952 sound optional swh-plugins_0.4.15-0.1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGbRu9canJGlcVnlkRAiMeAJ9t7s79Dk+HEuKKvTBLCOQCB9aqTwCfbWNX krr2bgfnUjv6QgjSgyS5O/U= =rU2r -END PGP SIGNATURE- Accepted: swh-plugins_0.4.15-0.1.diff.gz to pool/main/s/swh-plugins/swh-plugins_0.4.15-0.1.diff.gz swh-plugins_0.4.15-0.1.dsc to pool/main/s/swh-plugins/swh-plugins_0.4.15-0.1.dsc swh-plugins_0.4.15-0.1_amd64.deb to pool/main/s/swh-plugins/swh-plugins_0.4.15-0.1_amd64.deb swh-plugins_0.4.15.orig.tar.gz to pool/main/s/swh-plugins/swh-plugins_0.4.15.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
