Re: Debconf 5
On Mon, Jan 03, 2005 at 07:50:11PM +0100, Christian Perrier wrote: La Debconf 5 se déroulera, pour ceux qui ne le savent pas, à Helsinki. Les dates sont arrêtées, d'après ce que m'a indiqué Andreas Schuldei. Ce sera du 10 au 17 juillet 2005 (pratique pour les français). Il n'y a pas encore de site officiel (tout est encore en train de s'organiser) mais j'ai personnellement déjà réservé mes dateset mes vols..:-) C'est bizzare, moi j'ai aussi regardé les vols pour aller là bas cet après midi. De Paris, le plus économique semble être de loin GermanWings : il faut passer par leur hub de Cologne/Bonn. Les prix sont actuellement très attractifs : ainsi, l'aller (celui dont je suis moins sûr pour la date) me coute 38EUR (taxes comprises!) et le retour 132 EUR (c'est un dimanche...donc il peut être plus économique de revenir en fait deux jours après). Pour ceux qui viennent de Lyon, le moins cher, c'est de prendre le TGV jusqu'à CDG et de prendre les mêmes vols. Passer par Ryanair via St Etienne revient plus cher. Je ne peux qu'engager ceux qui sont à peu près surs de participer à réserver dès maintenant (j'ai regretté de ne pas l'avoir fait avant Noel, j'en aurais eu pour moins de 60EUR aller-retour!). Les dates et le lieu étant plus favorables, ce serait bien qu'il y ait cette année quelques contributeurs français de plus (nous étions 3 l'an dernier). Ben moi c'est quasiment sûr que je viens, par contre, j'ai pas encore décidé combien de jour avant et après je resterai là bas. -- .''`. Aurelien Jarno GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net
Re: origins of the Debian logo
On Thu, 2004-12-30 at 18:01 +0100, martin f krafft wrote: In the process of completion of my book (http://debianbook.info), I have one more question. Unfortunately, I am on a shitty GSM link right now and the available (crippled) means of research have not been able to produce an answer to the following: Where does the Debian Swirl come from? What does it try to symbolise? Sorry for the delayed response, but here is a possible answer to the second part of the question from a semiotic perspective. Although the question was what the swirl /tries/ to symbolize, it may be of some interest what it actually might have ended up symbolizing for some people. Fasten seatbelts, please. The mirror image, or inversion, of the above entry [clockwise spiral] symbolizes, like that ideogram, /rotation/. It stands first and foremost for a /counterclockwise rotation/ and is therefore related to [counterclockwise swastika]. This sign appeared in the Euphrates cultures as early as around 2000 B.C., and [counterclockwise spiral] is an Egyptian hieroglyph for /thread/ or /measurement/. [Angled counterclockwise spiral] was used in the earliest Chinese ideography with the probable meaning /return/ or /homecoming/. The Hopi Indians seem to have given it the same meaning. [...] The sign was used by the Phenicians and as a pattern on Bronze Age jewelry found in Scania, Sweden, dating back to about 1300 B.C. Compare with the hieroglyph [straight-line spiral with four angles], representing /Egypt/, i.e., that country that one /returns to/, the /homeland/. There is a similar usage in the English system of hobo signs: a /good house for work/, i.e., a place that is worth returning to when one needs food and money. The sign [somewhat straightened spiral] is found painted on the walls of houses in Tibet [...] and has perhaps the meaning /home/, the place one returns to. It can also signify /whirlpool/ or /eddy/ on nautical charts. (Liungman, Carl G.: Dictionary of Symbols, W. W. Norton Company Ltd, 1991 (English translation of original from 1974)) Had the spiral been a clockwise spiral, it would have signified water, power, independent movement and outgoing migration of tribes, as well as potential power, potential movement, or, in a more modern setting, spin drying. Both the clockwise and anticlockwise spirals share some common meanings. The nautical signs mentioned above are one example. In comic strips, they signify rage, pain and curses and are often accompanied by swastikas, exclamation marks, and other symbols of wrath and surprise. Finally, both [clockwise spiral] and [anticlockwise spiral] have been used by alchemists for /horse dung/. Go figure. All quotes from Liungman (see above) and apologies for the missing pictures, but honestly you do not want me to try these in ASCII... -- Fabian Fagerholm [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Bug#288497: ITP: libsnowball-swedish-perl -- Stemming algorithm for Swedish
#include hallo.h * Dominic Hargreaves [Tue, Jan 04 2005, 01:10:05AM]: Package: wnpp Severity: wishlist * Package name: libsnowball-swedish-perl Version : 1.01 Upstream Author : Ask Solem Hoel [EMAIL PROTECTED] * URL : http://search.cpan.org/dist/Snowball-Swedish/ * License : Dual GPL/Artistic Description : Stemming algorithm for Swedish I would not accept all your libsnowball* packages in Debian and hope your sponsor will see it the same way. Reason: poisoning the package pool. Background: most of them (compressed) need about 5kB size. This is rudicuolous... a package of ~5kB that about ~5kB meta data to be included in the archive. For what reason? 0.001 percent of our users that may need it somewhen in the far future? I do not see a real/good/successful/promising application that makes use of this stuff. Looks like a nice demo for one-shot wow effect but should we distribute that metadata to hundred thousands of users (wasting _their_ diskspace/bandwith) just to make few ones happy? Think about it. There is the dh-make-perl, every admin can create such packages if needed _and_ wished. Debian is not playground for just making your fingertipps on a great distribution. Do you really speak all that languages? Somehow I doubt. Regards, Eduard. -- CHS argl bin i deppert
For people more knowledgeable about buildds...
Hi, Is there a webpage that shows the current queue of packages in Needs-Build state? igloo's pages are great, but they only let you know the position in the queue of a package, not what's before or after it (out of curiosity). Also, what is involved with putting a package back into the Needs-Build state (i.e. requeueing it)? With complaints about the lack of response/response times from emails to [EMAIL PROTECTED], I was just wondering if it was feasible to have an email gateway like db.debian.org has for rescheduling failed builds? I presume the majority of emails sent to [EMAIL PROTECTED] are requests for requeuing? regards Andrew -- linux.conf.au 2005 - http://lca2005.linux.org.au/ - Birthplace of Tux April 18th to 23rd - http://lca2005.linux.org.au/ - LINUX Canberra, Australia - http://lca2005.linux.org.au/ -Get bitten! signature.asc Description: Digital signature
Re: Print Alternative
On Mon, Jan 03, 2005 at 01:05:18AM -0200, Fernanda Giroleti Weiden wrote: So, here goes my suggestion and a request: what do you think of using the alternatives system for printing? We could do. I'm not sure how it would all work together though, alternatives work fine with binaries but with daemons it gets tricky. My suggestion to the name of this alternative is print which should point to the command used to print (ex.: /usr/bin/lpr) Most of the packages conflict with each other and supply lpr and other similiar binaries. You probably need to go and check what the configuration thing actually needs. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/ MIEE Debian developer csmall at : enc.com.au ieee.org debian.org
Re: For people more knowledgeable about buildds...
On Tue, Jan 04, 2005 at 10:13:11PM +1100, Andrew Pollock wrote: Hi, Is there a webpage that shows the current queue of packages in Needs-Build state? igloo's pages are great, but they only let you know the position in the queue of a package, not what's before or after it (out of curiosity). buildd.debian.org/stats Kurt
Re: For people more knowledgeable about buildds...
On Tue, Jan 04, 2005 at 10:13:11PM +1100, Andrew Pollock wrote: Is there a webpage that shows the current queue of packages in Needs-Build state? igloo's pages are great, but they only let you know the position in the queue of a package, not what's before or after it (out of curiosity). http://buildd.debian.org/stats/?arch=ia64state=Needs-Build Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#288497: ITP: libsnowball-swedish-perl -- Stemming algorithm for Swedish
[To/CC set as this was also a personal mail to me; I suggest replies just go to debian-devel] On Tue, Jan 04, 2005 at 10:26:36AM +0100, Eduard Bloch wrote: I would not accept all your libsnowball* packages in Debian and hope your sponsor will see it the same way. Reason: poisoning the package pool. Background: most of them (compressed) need about 5kB size. This is rudicuolous... a package of ~5kB that about ~5kB meta data to be included in the archive. I can see that this is suboptimal. Given that this is how the modules are distributed upstream ie. individually, how should I avoid this? Would it be acceptable to package them all as one debian package somehow, and thus lose the transparency that orig.tar.gz brings? Or is there some other solution to this that I haven't spotted? For what reason? 0.001 percent of our users that may need it somewhen in the far future? I do not see a real/good/successful/promising application that makes use of this stuff. I should probably have been more clear in the ITPs: these packages are depended on by the perl module Lingua::Stem, which Plucene http://search.cpan.org/dist/Plucene/ in turn depends on. Plucene is a Perl port of the Lucene search engine http://jakarta.apache.org/lucene/docs/index.html. It was RFP'd a few months ago http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276439 and is used by OpenGuides http://openguides.org/page/software which I have packaged for Debian (and propose to upload when it is more mature). Looks like a nice demo for one-shot wow effect but should we distribute that metadata to hundred thousands of users (wasting _their_ diskspace/bandwith) just to make few ones happy? Think about it. Perhaps the cost/benefit tradeoff is now acceptable given the explanation above. Clearly it is a value judgement. There is the dh-make-perl, every admin can create such packages if needed _and_ wished. But when some other useful package depends on such packages, that is not an acceptable solution. Debian is not playground for just making your fingertipps on a great distribution. Do you really speak all that languages? Somehow I doubt. No. As should be apparent it was not my intention to use Debian as any sort of playground. Cheers, Dominic.
Bug#288576: ITP: yate -- YATE - Yet Another Telephony Engine
Package: wnpp Severity: wishlist * Package name: yate Version : 0.8.5 Upstream Author : Paul Chitescu [EMAIL PROTECTED], Diana Cionoiu [EMAIL PROTECTED] * URL : http://yate.null.ro/ * License : GPL Description : YATE - Yet Another Telephony Engine YATE is a telephony engine aimed at creating a telephony server that performs well enough to deal with PBX requirements and also flexible enough for complex Gateway and IVR solutions.
New stable version after Sarge
Hello, One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. What about saying something like: the next stable release comes in the beginning of 2006? I can understand something like Debian releases when it's ready, but many people have to work together. Maybe it's better to say: a package releases when it's ready, but the deadline for the next Debian release is a fixed date. You will understand that my most important point is security-support. With regards, Paul van der Vlis.
Re: LCC and blobs
Brian Thomas Sniffen [EMAIL PROTECTED] wrote: Hamish Moffatt [EMAIL PROTECTED] writes: So if EEPROMs contain software, why don't [you] get to distribute any drivers? I don't understand. You can get software out of an firmware-EEPROM on a hardware device. I don't think it's appropriate to call that software as is, or in general. This line *could* be drawn in lots of places, but if you say that the contents of an EEPROM are software, then how about a one-shot PROM? How about a book with a print-out of the source code? A PROM generally contains software (unless you're going to argue that executable code is not always software, in which case I'm going to ignore you). A book is a representation of software but not software itself, since the book exists outside the digital domain. The only reasonable place to draw the line, for Debian, is this: can Debian physically ship it in a useful way? For files on disk, the answer is yes. We are constrained only by the license. For the book or the PROM, the answer is no. For an EEPROM, in general, the answer is no. For any such correctly operating device, the firmware is already there. Debian can't usefully ship it. It would be interesting to try supporting an architecture to run on those devices instead of Wind River or whatever, but there isn't one now. Ignoring license constraints, I can find you any number of cases of eeproms where Debian could ship the contents. I can probably find you several that would run on hardware you currently own. Again, drawing the distinction at this point results in the solution that provides more practical freedom to the user being penalised. This implies very strongly that we're doing something wrong. When the firmware has to be uploaded, it's a dependency. If it were just a magic initialization sequence, that would be OK -- such a sequence is presumably too short to copyright. But this is long and non-free, clearly software, and clearly a dependency. The dependency is not on the specific firmware in question - the dependency is on code that will cause the general purpose device to behave in the way that the driver expects. In the vast majority of cases, the only code that currently satisfies that constraint is non-free, but there's no intrinsic reason why it has to be so. We can compare this to other hardware. The orinoco wireless driver depends on the hardware acting in a specific way, and does this by communicating with the firmware in the device. In doing so, it is communicating (and hence depending) upon non-free executable code - ie, software. But, again, there's no intrinsic reason why it has to be so. You could write free firmware, or you could reimplement the device in such a way that it doesn't actually have any firmware (for sufficiently simple cases, you might be able to reimplement it in a fairly large quantity of clockwork), and hence remove the dependency. But these are hypotheticals. Drivers that require loaded firmware tend to use non-free code, and drivers that require hardware to respond in certain ways tend to use non-free firmware on that hardware. In both cases, we could reimplement something in order to remove that non-free dependency (either free firmware or hardware that doesn't use firmware), but *nobody has done so*. A hypothetical implementation of something without non-free code doesn't satisfy us. You have argued that drivers don't really depend on firmware, but instead depend on the hardware expressing the correct interface. As an example, we can compare maria-vis, which depends on the graphviz package. maria-vis is in contrib, because it depends on graphviz, which is in non-free. But by your argument, it doesn't actually depend on graphviz - it merely depends on something that presents a correctly functioning graphviz interface. This could be a piece of non-free code, but it could also be a piece of free code, an interface to a remote application server, or a userspace application to drive hardware that kicks intelligent rodents until they draw the correct graph. There's no intrinsic dependency on the non-free code. But since the non-free code is currently the only solution that /does/ express the correct interface, there exists a dependency on non-free code. If you can find me a piece of hardware that can be driven by the kernel's orinoco driver and which contains no non-free executable code, I will agree that the driver does not require the use of non-free executable code. But not until then. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Print Alternative
Em Ter, 2005-01-04 s 22:04 +1100, Craig Small escreveu: On Mon, Jan 03, 2005 at 01:05:18AM -0200, Fernanda Giroleti Weiden wrote: So, here goes my suggestion and a request: what do you think of using the alternatives system for printing? We could do. I'm not sure how it would all work together though, alternatives work fine with binaries but with daemons it gets tricky. The alternative would not be for the daemons, but for the 'spooler clients'. My suggestion to the name of this alternative is print which should point to the command used to print (ex.: /usr/bin/lpr) Most of the packages conflict with each other and supply lpr and other similiar binaries. You probably need to go and check what the configuration thing actually needs. Having seen the code for the beast, I don't know if it does the Right Thing. It uses the 'print' alternative to find out what spooling system is being used. So if /usr/bin/print points to /usr/bin/lpr, the currently used daemon is lprng, if it points to /usr/bin/lp, it is using cups (I'm not very familiar with printing systems, though, so I may be wrong with the names and all that). It would not be a problem if we could only have one spooling daemon at a time, but that does not seem to be the case for Debian. I see cupsys conflicts with newer versions of lprng, but it will allow lpr to be installed. How would xprint and kdeprint enter the mix? Are there any other printing servers and clients on Debian? I know gtklp, but I guess it uses /usr/bin/lp? Thanks, -- [EMAIL PROTECTED]: Gustavo Noronha http://people.debian.org/~kov Debian: http://www.debian.org * http://www.debian-br.org
Re: New stable version after Sarge
On Jan 04, Paul van der Vlis [EMAIL PROTECTED] wrote: What about saying something like: the next stable release comes in the beginning of 2006? Sure, here it is: the next stable release comes in the beginning of 2006. Do you feel better now? HTH, HAND. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#288497: ITP: libsnowball-swedish-perl -- Stemming algorithm for Swedish
On Tue, Jan 04, 2005 at 01:07:42PM +, Dominic Hargreaves wrote: I can see that this is suboptimal. Given that this is how the modules are distributed upstream ie. individually, how should I avoid this? Would it be acceptable to package them all as one debian package somehow, and thus lose the transparency that orig.tar.gz brings? Or is there some other solution to this that I haven't spotted? I agree, the code should come in one big package. I have no idea how the Perl policy handles this case, though. You should check whether the big package needs to Provide: libsnowball-swedish-perl for all languages. If it is important for you that the original tarballs are preserved, you can put them inside an orig.tar.gz that you make. The tar.gz-inside-tar.gz approach looks a bit unclean, though... at the end of the day, this decision is up to you as the maintainer, the package pool contains examples of both re-tarred sources and tar.gz-inside-tar.gz. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
Re: New stable version after Sarge
Paul van der Vlis wrote: Hello, One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. What about saying something like: the next stable release comes in the beginning of 2006? The release date for a Debian release is not set by a calendar but by quality. At least that's been the case including sarge. Hence, such a sentence would not mean anything. I can understand something like Debian releases when it's ready, but many people have to work together. Maybe it's better to say: a package releases when it's ready, but the deadline for the next Debian release is a fixed date. What if the installer is broken at that time? What if the buildd network is busted at that time? What if n library transitions are in progress at that time? What if our archive suite lacks an important improvement which is a requirement for being able to maintain the new stable release? Sure, you could still release, but would you really like to have such a release? You will understand that my most important point is security-support. Oh I forgot: What if security support for a new release cannot be guaranteed at that time? Regards, Joey -- Life is a lot easier when you have someone to share it with. -- Sean Perry Please always Cc to me when replying to me on the lists.
Re: New stable version after Sarge
Re: Paul van der Vlis in [EMAIL PROTECTED] You will understand that my most important point is security-support. ...which Debian provides for its stable distribution at any time, even if the last stable release was ages ago. How does a fixed release date help there? Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: New stable version after Sarge
* Christoph Berg: Re: Paul van der Vlis in [EMAIL PROTECTED] You will understand that my most important point is security-support. ...which Debian provides for its stable distribution at any time, even if the last stable release was ages ago. Where is the security support for woody's version of Mozilla, Samba and PHP?
Re: murphy is listed on spamcop
On Friday 31 December 2004 06:22, Marc Haber [EMAIL PROTECTED] wrote: On Wed, 29 Dec 2004 08:43:32 +1100, Russell Coker Everyone who has a legitimate cause to send me email knows to use English. Your arrogance is remarkable. Why is it arrogant? If you see anything I have written then it will be written in English. Why would you expect that I know some language other than the one that I demonstrate in all my communication? It's generally considered arrogant when English speaking people expect the rest of the world to speak English. Shouldn't the same presumption of arrogance be applied when people who don't speak English expect me to speak their language? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: murphy is listed on spamcop
On Sunday 02 January 2005 18:32, Don Armstrong [EMAIL PROTECTED] wrote: [Way OT, but what the heck. If you must, flame me privately:] On Sun, 02 Jan 2005, Russell Coker wrote: On Sunday 02 January 2005 16:34, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: What is this, you go to war with the army you have, not the army you want? Coker's law: As a mailing-list discussion grows longer, the probability of a comparison involving Bush or bin Laden approaches one. Save for the fact that it was Rumsfeld who said this, not Bush or bin Laden: It's the same thing. References to Goebbels will invoke Godwin's law... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: New stable version after Sarge
Martin Schulze schreef: Paul van der Vlis wrote: Hello, One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. What about saying something like: the next stable release comes in the beginning of 2006? The release date for a Debian release is not set by a calendar but by quality. OK, I understand that. And it's good. At least that's been the case including sarge. Hence, such a sentence would not mean anything. I can understand something like Debian releases when it's ready, but many people have to work together. Maybe it's better to say: a package releases when it's ready, but the deadline for the next Debian release is a fixed date. What if the installer is broken at that time? Normally a broken installer does not come into testing (ehm, I don't know for sure the installer is a normal package). For me, installing was never a big problem. You can use an old installer and update. And a special installation (e.g. on soft-raid) you can install first somewhere else and then copy it. What if the buildd network is busted at that time? What if n library transitions are in progress at that time? What if our archive suite lacks an important improvement which is a requirement for being able to maintain the new stable release? When there is a fixed deadline you can plan such things better to be ready for the new release. Sure, you could still release, but would you really like to have such a release? I agree, quality is more important then the release date. You will understand that my most important point is security-support. Oh I forgot: What if security support for a new release cannot be guaranteed at that time? Same answer. With regards, Paul van der Vlis.
Re: New stable version after Sarge
Paul van der Vlis wrote: At least that's been the case including sarge. Hence, such a sentence would not mean anything. I can understand something like Debian releases when it's ready, but many people have to work together. Maybe it's better to say: a package releases when it's ready, but the deadline for the next Debian release is a fixed date. What if the installer is broken at that time? Normally a broken installer does not come into testing (ehm, I don't know for sure the installer is a normal package). During the preparation of sarge there was a long time where the installer didn't work as it should have. Go read the archives. For me, installing was never a big problem. You can use an old installer and update. And a special installation (e.g. on soft-raid) you can install first somewhere else and then copy it. Installing an old version and upgrading to the current one is completely out of discussion for a release. You can always do that with stable and testing. If you can't install a stable release, it's broken. (Not to compare this with a failed installation of a super-mega-new piece of hardware that isn't supported by the kernel yet). What if the buildd network is busted at that time? What if n library transitions are in progress at that time? What if our archive suite lacks an important improvement which is a requirement for being able to maintain the new stable release? When there is a fixed deadline you can plan such things better to be ready for the new release. Go read the archives. All three issues have happened during the last 12 months altough sarge was supposed to be released in December. Oh I forgot: What if security support for a new release cannot be guaranteed at that time? Same answer. Go read the archives. That's something that has delayed the woody release and is delaying the release of sarge. Regards, Joey -- Life is a lot easier when you have someone to share it with. -- Sean Perry Please always Cc to me when replying to me on the lists.
Re: New stable version after Sarge
Martin Schulze schreef: Paul van der Vlis wrote: At least that's been the case including sarge. Hence, such a sentence would not mean anything. I can understand something like Debian releases when it's ready, but many people have to work together. Maybe it's better to say: a package releases when it's ready, but the deadline for the next Debian release is a fixed date. What if the installer is broken at that time? Normally a broken installer does not come into testing (ehm, I don't know for sure the installer is a normal package). During the preparation of sarge there was a long time where the installer didn't work as it should have. Go read the archives. What I saw was different: the new super-mega-new-installer was not ready. For me, installing was never a big problem. You can use an old installer and update. And a special installation (e.g. on soft-raid) you can install first somewhere else and then copy it. Installing an old version and upgrading to the current one is completely out of discussion for a release. You can always do that with stable and testing. If you can't install a stable release, it's broken. Or the feature is missing in the installer. (Not to compare this with a failed installation of a super-mega-new piece of hardware that isn't supported by the kernel yet). Some of these hardware is not super-mega-new anymore... What if the buildd network is busted at that time? What if n library transitions are in progress at that time? What if our archive suite lacks an important improvement which is a requirement for being able to maintain the new stable release? When there is a fixed deadline you can plan such things better to be ready for the new release. Go read the archives. All three issues have happened during the last 12 months altough sarge was supposed to be released in December. Maybe a little bit of planning would help? Oh I forgot: What if security support for a new release cannot be guaranteed at that time? Same answer. Go read the archives. That's something that has delayed the woody release and is delaying the release of sarge. Same answer. With regards, Paul van de Vlis.
Re: New stable version after Sarge
On 04-Jan-05, 07:40 (CST), Paul van der Vlis [EMAIL PROTECTED] wrote: One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. If you want Ubuntu or Progeny, you know where[1] to find them. :-) Seriously. There's just no way you're going to change the way Debian makes releases, or rather, doesn't. It's too big, and there are just too damn many people involved, many of whom simply don't care about releases. As long as we maintain our current release criteria (which I don't necessarily think we should change) we will get slower and slower as we get bigger and bigger. Steve [1] Okay, just in case you don't: http://www.ubuntu.com/, http://www.progeny.com -- 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
Re: New stable version after Sarge
On 4 Jan 2005, at 3:45 pm, Steve Greenland wrote: On 04-Jan-05, 07:40 (CST), Paul van der Vlis [EMAIL PROTECTED] wrote: One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. If you want Ubuntu or Progeny, you know where[1] to find them. :-) Seriously. There's just no way you're going to change the way Debian makes releases, or rather, doesn't. It's too big, and there are just too damn many people involved, many of whom simply don't care about releases. As long as we maintain our current release criteria (which I don't necessarily think we should change) we will get slower and slower as we get bigger and bigger. Which could be seen as a problem by some; but in some ways it's probably the way to go. As far as my own use of Debian goes, almost every machine I install runs testing, and has done for years. There's a level of protection in there thanks to the rules that are in place, and I rather like the incremental improvement approach as opposed to release-based. With the trend as it is at the moment, the endpoint is that Debian will eventually stop releasing altogether (some end users probably think this has already happened!) and will essentially become an upstream, developer-oriented, steadily evolving distribution from which the likes of Ubuntu take regular snapshots for the masses to use. The downside of this is that it will essentially bar Debian systems from being formally supported by independent software vendors, since stable releases are what they depend on. Tim -- Dr Tim Cutts GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638 C066 16E2 F4F5 FC81 E159 PGP.sig Description: This is a digitally signed message part
Re: New stable version after Sarge
Paul van der Vlis wrote: Hello, One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. What about saying something like: the next stable release comes in the beginning of 2006? I can understand something like Debian releases when it's ready, but many people have to work together. Maybe it's better to say: a package releases when it's ready, but the deadline for the next Debian release is a fixed date. You will understand that my most important point is security-support. With regards, Paul van der Vlis. Well, you could argue that debian branches are not perfectly named but: stable is best if you need *absolute* failsafety for critical jobs testing is best if you want a stable system with new(ish) software unstable is for everybody who needs the newest software, like me. honestly, I have never had problems (yet) with using sid for day-to-day stuff. If I needed something more production-ready, I'd use testing because you have (almost) garantee that the software will work and you will have security updates, too. (But not in the same quality as stable, as I understand it. If I needed to run a always-needed very-important server on the internet, I would use stable. Regards, Thomas Jollans
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 05:31:26PM +0100, Thomas Jollans wrote: stuff. If I needed something more production-ready, I'd use testing because you have (almost) garantee that the software will work and you will have security updates, too. (But not in the same quality as Unfortunately, testing does not guarantee security updates. Sure, one day the updates will promote from unstable to testing. But this can take a long time, if, for example, some dependencies block the new version from testing. This may change with a testing-security upload queue. Jan
Re: New stable version after Sarge
[Jan Niehusmann] Unfortunately, testing does not guarantee security updates. Sure, one day the updates will promote from unstable to testing. But this can take a long time, if, for example, some dependencies block the new version from testing. This may change with a testing-security upload queue. Yes. The testing security team might help here too. URL:https://alioth.debian.org/projects/secure-testing/.
Re: New stable version after Sarge
On Tue, 2005-01-04 at 16:17 +0100, Paul van der Vlis wrote: Martin Schulze schreef: Paul van der Vlis wrote: [...] At least that's been the case including sarge. Hence, such a sentence would not mean anything. I can understand something like Debian releases when it's ready, but many people have to work together. Maybe it's better to say: a package releases when it's ready, but the deadline for the next Debian release is a fixed date. What if the installer is broken at that time? Normally a broken installer does not come into testing (ehm, I don't know for sure the installer is a normal package). For me, installing was never a big problem. You can use an old installer and update. And a special installation (e.g. on soft-raid) you can install first somewhere else and then copy it. No, this not good enough. How many MORE e-mails do you want on both Debian User and Debian Devel? It would hugely magnify the amount. What if the buildd network is busted at that time? What if n library transitions are in progress at that time? What if our archive suite lacks an important improvement which is a requirement for being able to maintain the new stable release? When there is a fixed deadline you can plan such things better to be ready for the new release. What part of Volunteers don't you understand? We can't force ANYONE to do anything at anytime. Sure, you could still release, but would you really like to have such a release? I agree, quality is more important then the release date. So, then if quality is what Debian is all about, why bother proposing a fixed date. We are progressing through stages already, just that to fix everything... well there's that Volunteers word again. You will understand that my most important point is security-support. Oh I forgot: What if security support for a new release cannot be guaranteed at that time? Same answer. This is only an incremental problem of the whole release staging design, control and planning . Quality and Security are by far Debian MOST important end-user needed features. We provide this by complying with the Debian Social Contract and the Debian Free Software Guide, both of which are the definition of Debian. You should read them. Debian: the Install once and update from there distro. So really why does it matter? If you want a distro that is based on timely releases, there are quite a few out there. The only one I would use is Ubuntu. Being Debian based, there are quite a few things to be said about its quality, perfect is not one, way ahead of most others IS one. But, still they demand a 6 month release schedule. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: murphy is listed on spamcop
I demand that Jose Carlos Garcia Sogo may or may not have written... El lun, 03-01-2005 a las 21:35 +1100, Russell Coker escribió: [snip] Human lives are much more important than email. The discussion is over. Of course, but in each field, a bad equipped army is as bad as a bad equipped mail server. Thus, Rumsfeld's words are applicable here, as Thomas want to do. No. I think that his words were about a badly equipped army (relatively speaking), not a bad, equipped army... [snip] -- | Darren Salt | linux (or ds) at | nr. Ashington, | woody, sarge, | youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | Let's keep the pound sterling Write all adverbial forms correct.
Re: Status of Kernel 2.4.28 packages?
I demand that Stephan Niemz may or may not have written... On Sun, Jan 02, 2005 at 20:02:25 -0600, Steve Greenland wrote: Converting to udev is an additional step, and caused me a lot more work than the basic 2.6 upgrade (mostly getting my head around it, and converting from usbmgr). Yes, converting from devfs to udev is one thing that doesn't seem to be easy. ISTM that whether it's easy depends on whether your devices are adequately represented in sysfs and the udev rules files. (I'm still using a script to create /dev/dvb/*, although if I upgrade to drivers in a newer kernel or CVS, I won't need that.) Another one is the ISDN support. Hasn't that changed significantly, too? No idea. And what's going to happen with /etc/modutils/*, how much manual tweaking would be needed there? [...] None at all, but you may want to tweak things in /etc/modprobe.d/ instead. ;-) -- | Darren Salt | linux (or ds) at | nr. Ashington, | woody, sarge, | youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | I don't ask for much, just untold riches... rm -rf /
Maintainer needed
Hi, I have created a package for the MyServer web server. MyServer is a fast, lightweight, and full featured web server. It can be remotely configured via the GUI. It is distributed under the terms of the GPL. The package can be found here: http://people.myserverproject.net/~rocky10balboa/debian/i386 While sources for the package are here: http://people.myserverproject.net/~rocky10balboa/debian/ If you know a debian maintainer willing to adopt the package and upload it, please let me know his/her contact info. Best Regards, Giuseppe scrivano
RunDinstallHourly
http://wiki.debian.net/?RunDinstallHourly (part of the ReleaseProposals topic on wiki.debian.net) discusses the concept of speeding up the release process by running dinstall hourly instead of once per day. This seems (to my amateur eyes) like a technically simple change to make even before we release Sarge (barring any unforseen consequences). Would it be possible to start testing this proposal out now by increasing the frequency of dinstall, perhaps to once every 6 hours until release? --Ken Bloom -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures.
Re: New stable version after Sarge
Tim Cutts [EMAIL PROTECTED] wrote: Seriously. There's just no way you're going to change the way Debian makes releases, or rather, doesn't. It's too big, and there are just too damn many people involved, many of whom simply don't care about releases. As long as we maintain our current release criteria (which I don't necessarily think we should change) we will get slower and slower as we get bigger and bigger. Which is a rather clear sign that the way Debian makes releases has outgrown its usefulness. Which could be seen as a problem by some; but in some ways it's probably the way to go. As far as my own use of Debian goes, almost every machine I install runs testing, and has done for years. There's a level of protection in there thanks to the rules that are in place, and I rather like the incremental improvement approach as opposed to release-based. Me too, but it might be completely different if you do it for business critical systems. With the trend as it is at the moment, the endpoint is that Debian will eventually stop releasing altogether (some end users probably think this has already happened!) and will essentially become an upstream, developer-oriented, steadily evolving distribution from which the likes of Ubuntu take regular snapshots for the masses to use. Stopping releasing might be a good idea but there should be a better way. IMO the problem is the stable release isn't updated on a regulare basis. It might be a better idea to divide Debian into subsystems which could be released much faster when needed. O. Wyss -- Development of frame buffer drivers: http://linux-fbdev.sf.net Sample code snippets for wxWidgets: http://wxcode.sf.net How to build well-designed applications: http://wxguide.sf.net Desktop with a consistent look and feel: http://wyodesktop.sf.net
Re: LCC and blobs
I demand that Glenn Maynard may or may not have written... On Tue, Jan 04, 2005 at 01:48:12AM +, Darren Salt wrote: [fetching firmware on finding hardware which needs it: wget or packaged?] Fetch every time and fetch once. That looks like a difference to me... How could fetch every time possibly be acceptable to the SC when fetch once is not? Are you saying that the rancid-installer package could go in main, if it re-downloaded and reinstalled the program every time it was used? Of course not--there is no difference to the SC. I don't believe that I've made any comments about freeness of the firmware installer package (though I've definitely said things about kernel modules for devices which, to be useful, require firmware uploads). I merely consider fetch-every-time to be broken (and you can add firmware no longer available for download to the list of reasons). This could be as simple as mounting a tmpfs on /lib/firmware, and wgetting [my comments about network availability removed - RELEVANT CONTEXT] The removed quotes were superfluous to my response, so no, they weren't relevant. Stop yelling. They were relevant to the text which you *didn't* snip. You should have summarised them or left them in place. And you've not marked where you've removed text :-\ -- | Darren Salt | linux (or ds) at | nr. Ashington, | woody, sarge, | youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | URL:http://www.youmustbejoking.demon.co.uk/ (PGP 2.6, GPG keys) Answers on a postcard please to 10 Downing Street, London SW1.
Re: Maintainer needed
Am Dienstag, den 04.01.2005, 18:47 +0100 schrieb Giuseppe Scrivano: Hi, I have created a package for the MyServer web server. MyServer is a fast, lightweight, and full featured web server. It can be remotely configured via the GUI. It is distributed under the terms of the GPL. The package can be found here: http://people.myserverproject.net/~rocky10balboa/debian/i386 While sources for the package are here: http://people.myserverproject.net/~rocky10balboa/debian/ If you know a debian maintainer willing to adopt the package and upload it, please let me know his/her contact info. Are you not intrested to maintain it by yourself? On intrest ask at the debian-mentor mailinglist regards Daniel Best Regards, Giuseppe scrivano signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 06:15:30PM +0100, Petter Reinholdtsen wrote: This may change with a testing-security upload queue. Yes. The testing security team might help here too. URL:https://alioth.debian.org/projects/secure-testing/. Ooh... This is arguably the most exciting Debian-related thing I've heard of in some time! A security team for Sarge. Dreamy! -- Mason Loring Bliss [EMAIL PROTECTED] They also surf who awake ? sleep : dream; http://blisses.org/ only stand on waves. pgpCLOxakqDxb.pgp Description: PGP signature
Re: New stable version after Sarge
[Mason Loring Bliss] Ooh... This is arguably the most exciting Debian-related thing I've heard of in some time! A security team for Sarge. Dreamy! Thank you. But it is not for sarge. It is for testing. When sarge is released, the team will move on to sarge+1. :) Joey Hess is the coordinator of the effort, funded by Debian Edu. We would hire more people if we had the funds. :)
gaim-dev packages heading to experimental
I've just uploaded gaim 1:1.1.1-2 to experimental, which introduces a new arch-independent gaim-data package containing all of the /usr/share stuff, and more interestingly to those who have been waiting and ITPing various Gaim plugins, a gaim-dev package containing the includes and .pc file necessary to compile them on a Debian system. The gaim-dev package includes a dh_gaim utility which (thanks to Gaim's new upstream versioning policy) plugin maintainers should use to add correctly versioned dependencies on the Gaim package. Please read /usr/share/doc/gaim-dev/README.Debian.dev for more details on this. Also appearing for the first time is the gevolution plugin which synchronises your Gaim buddy list to your Evolution address book. Huge thanks go to my trusty co-maintainer Ari Pollak for doing most of the legwork on this split up, and to Tollef Fog Heen for writing the dh_gaim utility for us. While they're being pondered upon by the FTP masters, the source and i386 packages are available here: deb http://people.debian.org/~robot101/gaim experimental main deb-src http://people.debian.org/~robot101/gaim experimental main If any DDs would like to do builds on other architectures, or publish plugin packages which they have produced whilst they await FTP master attention, I can also add these to this repository upon request. Regards, Rob
Re: Status of Kernel 2.4.28 packages?
Quoting Darren Salt [EMAIL PROTECTED]: I demand that Stephan Niemz may or may not have written... On Sun, Jan 02, 2005 at 20:02:25 -0600, Steve Greenland wrote: Converting to udev is an additional step, and caused me a lot more work than the basic 2.6 upgrade (mostly getting my head around it, and converting from usbmgr). Yes, converting from devfs to udev is one thing that doesn't seem to be easy. ISTM that whether it's easy depends on whether your devices are adequately represented in sysfs and the udev rules files. (I'm still using a script to create /dev/dvb/*, although if I upgrade to drivers in a newer kernel or CVS, I won't need that.) I don't have any special devices, and a recent attempt to switch to udev ended in going right back to devfs. I am running 2.6.8 and don't have anything strange in my setup. It just didn't work. I was also unable to find any decent documentation about making such a switch. Maybe it's just been too long since I looked, but I am not really interested in spending the time again unless I am certain it will work. -Roberto Sanchez This message was sent using IMP, the Internet Messaging Program.
Re: Maintainer needed
Hi, First of all I am not a debian developer, so I always need a sponsor to upload it, and I think that the package is not yet perfect. Maybe an expert person can handle it better. Thanks for the fast answer, Giuseppe
Re: New stable version after Sarge
Quoting Thomas Jollans [EMAIL PROTECTED]: Paul van der Vlis wrote: Hello, One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. What about saying something like: the next stable release comes in the beginning of 2006? I can understand something like Debian releases when it's ready, but many people have to work together. Maybe it's better to say: a package releases when it's ready, but the deadline for the next Debian release is a fixed date. You will understand that my most important point is security-support. With regards, Paul van der Vlis. Well, you could argue that debian branches are not perfectly named but: stable is best if you need *absolute* failsafety for critical jobs testing is best if you want a stable system with new(ish) software unstable is for everybody who needs the newest software, like me. honestly, I have never had problems (yet) with using sid for day-to-day stuff. If I needed something more production-ready, I'd use testing because you have (almost) garantee that the software will work and you will have security updates, too. (But not in the same quality as stable, as I understand it. If I needed to run a always-needed very-important server on the internet, I would use stable. I would strongly caution against using Sarge for a production system until there is security team support. See this message I posted to d-u when someone pointed out that they were running sarge on some servers: http://lists.debian.org/debian-user/2004/12/msg03846.html -Roberto Sanchez This message was sent using IMP, the Internet Messaging Program.
Re: New stable version after Sarge
On Tue, 2005-01-04 at 14:58 -0500, [EMAIL PROTECTED] wrote: Quoting Thomas Jollans [EMAIL PROTECTED]: Well, you could argue that debian branches are not perfectly named but: stable is best if you need *absolute* failsafety for critical jobs testing is best if you want a stable system with new(ish) software unstable is for everybody who needs the newest software, like me. honestly, I have never had problems (yet) with using sid for day-to-day stuff. If I needed something more production-ready, I'd use testing because you have (almost) garantee that the software will work and you will have security updates, too. (But not in the same quality as stable, as I understand it. If I needed to run a always-needed very-important server on the internet, I would use stable. I would strongly caution against using Sarge for a production system until there is security team support. See this message I posted to d-u when someone pointed out that they were running sarge on some servers: http://lists.debian.org/debian-user/2004/12/msg03846.html I also commented in the thread, if you recall. I stated I run SID/experimental for certain things, Testing with updates from SID if need be... etc. The thing is, that unless you *really* know how and what you are doing with pinning and preferences and the mighty good reasons for doing them, you should stick with Stable for servers. People that think ahhh, what could happen or Bah, I'm only one IP addr or even the penultimate Dude, I am running SID with Experimental Preferred that is SOOO 31337! Are just asking for their machine to be ummm... cracked/whacked or put out of its misery. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: murphy is listed on spamcop
Russell Coker [EMAIL PROTECTED] writes: Save for the fact that it was Rumsfeld who said this, not Bush or bin Laden: It's the same thing. References to Goebbels will invoke Godwin's law... But I didn't reference Goebbel's or Hitler. You seem to have a serious problem with reality here.
Re: Maintainer needed
Giuseppe Scrivano wrote: If you know a debian maintainer willing to adopt the package and upload it, please let me know his/her contact info. Maybe consider to file a RFP. For a start go: http://www.debian.org/devel/wnpp/index.en.html -- GPG messages preferred. | .''`. ** Debian GNU/Linux ** Alexander Sack | : :' : The universal [EMAIL PROTECTED] | `. `' Operating System http://www.jwsdot.com/ | `-http://www.debian.org/
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
Le mardi 21 décembre 2004 à 12:18 +0100, Ingo Juergensmann a écrit : FWIW: With your attitude and persistent accusations you're driving away even those who partially agree with you. Sure, that's a risk. That's not a risk, that's a reality. Now that you spat your flames on this thread, I cannot hope to have any answer to the questions raised. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: handling bugs of udev
Nico == Nico Golde [EMAIL PROTECTED] writes: Nico i think this should be created be default, but thats the Nico decision of the maintainer. Looking at the script, I was under the impression it is created by default. -- Brian May [EMAIL PROTECTED]
Re: LCC and blobs
On Tue, Jan 04, 2005 at 06:22:20PM +, Darren Salt wrote: On Tue, Jan 04, 2005 at 01:48:12AM +, Darren Salt wrote: [fetching firmware on finding hardware which needs it: wget or packaged?] Fetch every time and fetch once. That looks like a difference to me... How could fetch every time possibly be acceptable to the SC when fetch once is not? Are you saying that the rancid-installer package could go in main, if it re-downloaded and reinstalled the program every time it was used? Of course not--there is no difference to the SC. I don't believe that I've made any comments about freeness of the firmware installer package (though I've definitely said things about kernel modules for devices which, to be useful, require firmware uploads). I merely consider fetch-every-time to be broken (and you can add firmware no longer available for download to the list of reasons). Since this is a discussion of freeness and SC#1, it's differences in freeness that are relevant here. In response to no difference: contrib at best, you said that looks like a difference, which certainly looks like a comment on freeness. (Unless you do have something to say about freeness, let's let this subthread die; my response said who cares about implementation details for something which clearly doesn't help the software get out of contrib, and this isn't going anywhere.) They were relevant to the text which you *didn't* snip. You should have summarised them or left them in place. And you've not marked where you've removed text :-\ When I think some indication of removal is useful, I mark it with a blank line between quotes, instead of ; this is clear enough, since the full text is always available. All text in all messages is relevant to other text; not removing text which is relevant to some other quote would mean never removing anything. (As your complaints about my quoting are both frivilous and in a somewhat demanding tone, I doubt I'll respond to them any further.) -- Glenn Maynard
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Tue, Jan 04, 2005 at 10:22:41PM +0100, Josselin Mouette wrote: Le mardi 21 décembre 2004 à 12:18 +0100, Ingo Juergensmann a écrit : FWIW: With your attitude and persistent accusations you're driving away even those who partially agree with you. Sure, that's a risk. That's not a risk, that's a reality. Now that you spat your flames on this thread, I cannot hope to have any answer to the questions raised. This thread is dead. If you want answers, mail me your questions privately. BTW: the questions I asked within the thread are still unanswered as well. :) -- Ciao... // Ingo \X/ Please note that year 2005 has come to an end and the year 2005 is now - even in my mail address!
ClanLib 0.7 branch.
Hello. ClanLib 0.7.8+svn20041230 has been uploaded to experimental. If someone wants to test these packages before ftp-master approval, fell free to fetch them from http://people.debian.org/~fenio/clanlib/ Any comments appreciated. regards fEnIo -- _ Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | IRC:fEnIo _|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska (0 0)phone:+48602383548 | proud Debian developer and user ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001 signature.asc Description: Digital signature
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
Ingo Juergensmann [EMAIL PROTECTED] wrote: If you want answers, mail me your questions privately. BTW: the questions I asked within the thread are still unanswered as well. :) If you can't play politely, other people will not be inclined to play with you. Your continued abuse of volunteers, accusations of conspiracies and generally nasty attitude is a good combination of tactics to ensure that your questions are never answered, no matter how good they are. If you have any desire to help Debian, then lose the attitude. If you don't, then please stop wasting our time. -- Matthew Garrett | [EMAIL PROTECTED]
Re: DDTP problems
A few days ago, Daniel Batista has posted about a problem with an automatic email system on a ddtp.debian.org which is stuffing up the Debian Descriptions Translation Project: On Mon, Dec 27, 2004 at 11:02:29PM -0300, Daniel Mac?do Batista wrote: The replies depend of the subject in the email. For example: If I send an email to [EMAIL PROTECTED] with subject STATUS, the reply must be an email with the body like this: Stats from new db: Descriptions: 10692 up-to-date Descriptions: 7909 Translated Descriptions: 2672 snip In http://ddtp.debian.org/new/how_it_works/translators.en.html#faq-1 there is more examples. I try a lot of subjects but don't get reply. 1-) What's the relevance of the DDTP to the Debian? The work must continue? I was not aware of the Debian Description Translation Project, but it sounds very much essential to make Debian accessible to people who don't speak English. 2-) How and when the problem related by Michael Bramer (I write some mails to debian-admin (for cvs access etc.) and never get a reply) can be solved? Perhaps several of you could write again. Can you help us? Sorry for the delay, Daniel. Can someone else please comment on this? What should we do - post to debian-admin again? Sam
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Tue, Jan 04, 2005 at 09:55:21PM +, Matthew Garrett wrote: If you want answers, mail me your questions privately. BTW: the questions I asked within the thread are still unanswered as well. :) If you can't play politely, other people will not be inclined to play with you. Your continued abuse of volunteers, accusations of conspiracies and generally nasty attitude is a good combination of tactics to ensure that your questions are never answered, no matter how good they are. Abusing volunteers? How can that be? *wonders* :) -- Ciao... // Ingo \X/ Please note that year 2005 has come to an end and the year 2005 is now - even in my mail address!
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 04:25:00PM +0100, Martin Schulze wrote: Paul van der Vlis wrote: At least that's been the case including sarge. Hence, such a sentence would not mean anything. I can understand something like Debian releases when it's ready, but many people have to work together. Maybe it's better to say: a package releases when it's ready, but the deadline for the next Debian release is a fixed date. What if the installer is broken at that time? Normally a broken installer does not come into testing (ehm, I don't know for sure the installer is a normal package). During the preparation of sarge there was a long time where the installer didn't work as it should have. Go read the archives. That said, this (rather large) blocker shouldn't be the issue it has been for this release for the next one. The two biggest blockers to releasing any time soon have been the installer and the security infrastructure. I'm actually not abreast of what the issue is with the security infrastructure, so I don't know if it's likely to be a blocker all over again come etch release time. I'd like to think it's going to easier to release etch sooner. regards Andrew -- linux.conf.au 2005 - http://lca2005.linux.org.au/ - Birthplace of Tux April 18th to 23rd - http://lca2005.linux.org.au/ - LINUX Canberra, Australia - http://lca2005.linux.org.au/ -Get bitten! signature.asc Description: Digital signature
Re: RunDinstallHourly
On Tue, Jan 04, 2005 at 10:16:27AM -0800, Ken Bloom wrote: http://wiki.debian.net/?RunDinstallHourly (part of the ReleaseProposals topic on wiki.debian.net) discusses the concept of speeding up the release process by running dinstall hourly instead of once per day. This seems (to my amateur eyes) like a technically simple change to make even before we release Sarge (barring any unforseen consequences). Would it be possible to start testing this proposal out now by increasing the frequency of dinstall, perhaps to once every 6 hours until release? Wouldn't this have a flow on effect on our mirrors (or is the mirror pulse independent of the dinstall run)? Either way, if the mirror pulse only happens once a day, running dinstall more than once is going to be largely ineffective for most users isn't it? regards Andrew -- linux.conf.au 2005 - http://lca2005.linux.org.au/ - Birthplace of Tux April 18th to 23rd - http://lca2005.linux.org.au/ - LINUX Canberra, Australia - http://lca2005.linux.org.au/ -Get bitten! signature.asc Description: Digital signature
Re: RunDinstallHourly
On Wed, 05 Jan 2005 09:36:11 +1100, Andrew Pollock wrote: On Tue, Jan 04, 2005 at 10:16:27AM -0800, Ken Bloom wrote: http://wiki.debian.net/?RunDinstallHourly (part of the ReleaseProposals topic on wiki.debian.net) discusses the concept of speeding up the release process by running dinstall hourly instead of once per day. This seems (to my amateur eyes) like a technically simple change to make even before we release Sarge (barring any unforseen consequences). Would it be possible to start testing this proposal out now by increasing the frequency of dinstall, perhaps to once every 6 hours until release? Wouldn't this have a flow on effect on our mirrors (or is the mirror pulse independent of the dinstall run)? Either way, if the mirror pulse only happens once a day, running dinstall more than once is going to be largely ineffective for most users isn't it? Part of this proposal would be speed up the mirror pulse to occur as frequently as dinstall. --Ken Bloom -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures.
Re: New stable version after Sarge
Andrew Pollock [EMAIL PROTECTED] wrote: That said, this (rather large) blocker shouldn't be the issue it has been for this release for the next one. The two biggest blockers to releasing any time soon have been the installer and the security infrastructure. I'm actually not abreast of what the issue is with the security infrastructure, so I don't know if it's likely to be a blocker all over again come etch release time. I'd like to think it's going to easier to release etch sooner. It shouldn't be forgotten that the biggest blocker after these things is probably a general failure to actually care all that much. How many people are actually behaving as if a release is just around the corner? How can we fix this? -- Matthew Garrett | [EMAIL PROTECTED]
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx at buildd.debian.org sent to /dev/null ?)
On Tue, Jan 04, 2005 at 10:38:03PM +0100, Ingo Juergensmann wrote: Please note that year 2005 has come to an end and the year 2005 is now - even in my mail address! Does the new address bring with it a more constructive attitude towards volunteers who have contributed countless hours over the years to keeping this project running, or should I plan to killfile this one as well? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: LCC and blobs
I demand that Glenn Maynard may or may not have written... On Tue, Jan 04, 2005 at 06:22:20PM +, Darren Salt wrote: On Tue, Jan 04, 2005 at 01:48:12AM +, Darren Salt wrote: [fetching firmware on finding hardware which needs it: wget or packaged?] Fetch every time and fetch once. That looks like a difference to me... How could fetch every time possibly be acceptable to the SC when fetch once is not? Are you saying that the rancid-installer package could go in main, if it re-downloaded and reinstalled the program every time it was used? Of course not--there is no difference to the SC. I don't believe that I've made any comments about freeness of the firmware installer package (though I've definitely said things about kernel modules for devices which, to be useful, require firmware uploads). I merely consider fetch-every-time to be broken (and you can add firmware no longer available for download to the list of reasons). Since this is a discussion of freeness and SC#1, it's differences in freeness that are relevant here. In response to no difference: contrib at best, you said that looks like a difference, which certainly looks like a comment on freeness. It looked to me like you were saying that there was no difference between fetching always and fetching once. ISTM (now) that you've removed too much and I've removed not enough. (Unless you do have something to say about freeness, let's let this subthread die; [...]) I could say something, but I think that in the general case, it wouldn't add to what has already been said. In the specific cases, well, let's wait for them to be mentioned :-) They were relevant to the text which you *didn't* snip. You should have summarised them or left them in place. And you've not marked where you've removed text :-\ When I think some indication of removal is useful, I mark it with a blank line between quotes, instead of ; this is clear enough, since the full text is always available. ... but said full text may not have been received locally, and the reader may be offline - in which case, how is he meant to distinguish between your blank line and a blank line left by the original author and possibly devoid of quote indication due to its having been removed because the line was otherwise blank? All text in all messages is relevant to other text; not removing text which is relevant to some other quote would mean never removing anything. [...] Degrees of relevance? (Probably best to let that lie.) -- | Darren Salt | linux (or ds) at | nr. Ashington, | woody, sarge, | youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | Let's keep the pound sterling If I send this, does that mean that you'll read it?
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 02:58:42PM -0500, [EMAIL PROTECTED] wrote: I would strongly caution against using Sarge for a production system until there is security team support. See this message I posted to d-u when someone pointed out that they were running sarge on some servers: http://lists.debian.org/debian-user/2004/12/msg03846.html Interesting. Recently, I've started using testing on production servers. I subscribe to debian-security (+ d-s-announce) and get reports whenever there's anything released. I know what is installed on my boxes, so I know if this announcement affects me. If it's been put into unstable, I'll backport the change myself. If it's not, Then I'll have a look at upstream's solution, and patch as required. Recently, I did have a box rooted. This was due to a user running phpbb on the system, without me knowing, despite the policy of no software without clearance from me. There's also not necesarrily a 10 day waiting period if the urgency is set high. Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li B345BDD3
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 10:35:37PM +, Matthew Garrett wrote: Andrew Pollock [EMAIL PROTECTED] wrote: That said, this (rather large) blocker shouldn't be the issue it has been for this release for the next one. The two biggest blockers to releasing any time soon have been the installer and the security infrastructure. I'm actually not abreast of what the issue is with the security infrastructure, so I don't know if it's likely to be a blocker all over again come etch release time. I'd like to think it's going to easier to release etch sooner. It shouldn't be forgotten that the biggest blocker after these things is probably a general failure to actually care all that much. How many people are actually behaving as if a release is just around the corner? How can we fix this? We've spent most of the past year thinking a release might be just round the corner. We can only cry wolf so many times before the world stops believing us and finds an option that actually works. J. -- She's the one for me. She's all I really need, oh yeah. Bring some pragmatism back to Debian - mjg59 for DPL!
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 11:25:29PM +, Jonathan McDowell wrote: We've spent most of the past year thinking a release might be just round the corner. We can only cry wolf so many times before the world stops believing us and finds an option that actually works. I started using Linux (and Debian) a couple months after Woody came out. Was woody due any day now for a year like this? For what it's worth Microsoft goes into feature freeze about a year before an OS ships. They fork the kernel then. About the only thing that changes after that is the icons and desktop colors.
Re: Maintainer needed
Hi, I submitted a RFP(bug #288655). Thanks for the suggestion, Giuseppe
package up for grabs - xmms-xmmplayer
Package: xmms-xmmplayer Description: XMMS plugin that uses MPlayer to play video files CC me I am not on the list I know longer use this package so if someone wants to maintain it that uses it let me know. Its had two bugs in the year since I packaged it and one new upstream release 8 months ago. I would say there are not very many people using it, If no one wants it I will probably consider removing it. Its major problem is that it depends on mplayer. Which is not in debian. Unofficial packages of mplayer are available from http://debian.video.free.fr/ xmms-xmmplayer currently has one bug, which is about no mplayer: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286256 -- Jason I hope you learn speaking English proper I hope speak I me you. -- Branden Robinson, 2001
Re: murphy is listed on spamcop
On Wednesday 05 January 2005 07:58, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Russell Coker [EMAIL PROTECTED] writes: Save for the fact that it was Rumsfeld who said this, not Bush or bin Laden: It's the same thing. References to Goebbels will invoke Godwin's law... But I didn't reference Goebbel's or Hitler. You seem to have a serious problem with reality here. You invoked Rumsfeld who is one of Bush's flunkeys. I invented what I call Coker's law because the same issues that led to the creation of Godwin's law are in place now but with Bush, Osama and friends. If you have any serious point to make then it can be made without reference to such people. However all your messages recently have been ad-hominem attacks, trying to compare me to Rumsfeld and now claiming that I have a problem with reality. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: New stable version after Sarge
Neil McGovern wrote: On Tue, Jan 04, 2005 at 02:58:42PM -0500, [EMAIL PROTECTED] wrote: I would strongly caution against using Sarge for a production system until there is security team support. See this message I posted to d-u when someone pointed out that they were running sarge on some servers: http://lists.debian.org/debian-user/2004/12/msg03846.html Interesting. Recently, I've started using testing on production servers. I subscribe to debian-security (+ d-s-announce) and get reports whenever there's anything released. I know what is installed on my boxes, so I know if this announcement affects me. You are probably in the minority, then. If it's been put into unstable, I'll backport the change myself. If it's not, Then I'll have a look at upstream's solution, and patch as required. This is good. Recently, I did have a box rooted. This was due to a user running phpbb on the system, without me knowing, despite the policy of no software without clearance from me. That really sucks. There's also not necesarrily a 10 day waiting period if the urgency is set high. Neil The only you did not address is when there is a security fix for which there is not an announcement. If a package is not already in Woody, then it is not receiving security team support and will go under the radar. Additionally, some maintainers work closely with upstream and fix the problems almost immediately. In both of those cases, you would need to be monitoring the changelog for each of your packages and watching for security-related changes to packages. That makes me wonder. I know that there are tools like cron-apt that will perform apt-related tasks through cron jobs. Is there a way to make it (or another tool) download the changelogs and email you any new ones? -Roberto Sanchez signature.asc Description: OpenPGP digital signature
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 07:45:12PM -0500, Roberto Sanchez wrote: I subscribe to debian-security (+ d-s-announce) and get reports whenever there's anything released. I know what is installed on my boxes, so I know if this announcement affects me. You are probably in the minority, then. Yes, probably, but I'm using testing, which isn't supported by the standard security team. Therefore, it's now my sole reponsibility to look at security changes. Recently, I did have a box rooted. This was due to a user running phpbb on the system, without me knowing, despite the policy of no software without clearance from me. That really sucks. Yup. It's annoying to have to travel down to London because of it. The user was suitably 'chastised' :) The only you did not address is when there is a security fix for which there is not an announcement. If a package is not already in Woody, then it is not receiving security team support and will go under the radar. Additionally, some maintainers work closely with upstream and fix the problems almost immediately. In both of those cases, you would need to be monitoring the changelog for each of your packages and watching for security-related changes to packages. These normally crop up in either: * security list and/or * various irc channels However, it's not something that I would expect a normal user to do. But I woudn't be expecting a normal user to be using testing for a production system. That makes me wonder. I know that there are tools like cron-apt that will perform apt-related tasks through cron jobs. Is there a way to make it (or another tool) download the changelogs and email you any new ones? Would be worth writing, but IMO a list with various people looking at different changelogs is just as reliable. Like various lists already out there :) Warm regards, Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li B345BDD3 signature.asc Description: Digital signature
Re: Bug#288497: ITP: libsnowball-swedish-perl -- Stemming algorithm for Swedish
On Tue, 04 Jan 2005, Dominic Hargreaves wrote: On Tue, Jan 04, 2005 at 10:26:36AM +0100, Eduard Bloch wrote: Background: most of them (compressed) need about 5kB size. This is rudicuolous... a package of ~5kB that about ~5kB meta data to be included in the archive. I can see that this is suboptimal. Given that this is how the modules are distributed upstream ie. individually, how should I avoid this? Would it be acceptable to package them all as one debian package somehow, and thus lose the transparency that orig.tar.gz brings? That's usually the best idea if the package is small enough or reasonably useless without the other parts of the package. See, for example, libimage-base-bundle-perl, or any of the other packages which have been bundled together in units of usefulness to avoid the problems if having 8 billion teeny perl modules. [You probably should also let upstream know that they should consider bundling these together on CPAN, or even distributing them as a single module.] Don Armstrong -- If you wish to strive for peace of soul, then believe; if you wish to be a devotee of truth, then inquire. -- Friedrich Nietzsche http://www.donarmstrong.com http://rzlab.ucr.edu
Re: RunDinstallHourly
Ken Bloom wrote: http://wiki.debian.net/?RunDinstallHourly (part of the ReleaseProposals topic on wiki.debian.net) discusses the concept of speeding up the release process by running dinstall hourly instead of once per day. This seems (to my amateur eyes) like a technically simple change to make even before we release Sarge (barring any unforseen consequences). Would it be possible to start testing this proposal out now by increasing the frequency of dinstall, perhaps to once every 6 hours until release? I've talked about this with James Troup before. He seemed pretty receptive to speeding it up to something like twice a day, didn't seem to feel it would hit the mirrors much worse. It's possible he may still be waiting on SCC splitting up the base set of arches or the like before revisiting this. (BTW, please note that when I or this proposal talks about the dinstall run, we're using the circa 1998 definition that includes mirror sync. The dinstall program itself aready runs every 15 minutes.) -- see shy jo signature.asc Description: Digital signature
Re: RunDinstallHourly
On Tue, Jan 04, 2005 at 08:08:47PM -0500, Joey Hess wrote: Ken Bloom wrote: http://wiki.debian.net/?RunDinstallHourly (part of the ReleaseProposals topic on wiki.debian.net) discusses the concept of speeding up the release process by running dinstall hourly instead of once per day. This seems (to my amateur eyes) like a technically simple change to make even before we release Sarge (barring any unforseen consequences). Would it be possible to start testing this proposal out now by increasing the frequency of dinstall, perhaps to once every 6 hours until release? I've talked about this with James Troup before. He seemed pretty receptive to speeding it up to something like twice a day, didn't seem to feel it would hit the mirrors much worse. It's possible he may still be waiting on SCC splitting up the base set of arches or the like before revisiting this. (BTW, please note that when I or this proposal talks about the dinstall run, we're using the circa 1998 definition that includes mirror sync. The dinstall program itself aready runs every 15 minutes.) Twice daily seems more reasonable to me than hourly; for release purposes, another factor is how often britney runs, since that's what triggers changes in the testing suite. Doubling the frequency of britney runs seems reasonable to me, but hourly would surely be overkill considering we would still want to keep the waiting periods as they are now. Anthony Towns has been playing with the testing scripts this week, giving the release team the ability to do by-hand runs of britney now. This gives us more flexibility in catching our own oversights that would otherwise push bits of testing improvements back by 24 hours at a time. This has already directly contributed to getting KDE 3.3 into testing as soon as we did -- if the dip in the sarge RC bug count is any indication, this looks like a step in the right direction. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 03:41:41PM +0100, Christoph Berg wrote: ...which Debian provides for its stable distribution at any time, even if the last stable release was ages ago. How does a fixed release date help there? Besides Florian's point, you have to consider that Debian needs people actually testing what's going to be released. And many of the people doing the testing, are doing it because they want to have something reliable that they can use at their workplace (however work is defined here). But at some point they just can't take that let's use a Desktop environment which is two years old and has significant usability bugs which were fixed a year ago anymore and they go away. So Debian hurts itself at the end of the day. So, no, a fixed date doesn't help. A release schedule does. (And no we will release in two years time is not a release schedule in this context). Marcelo
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 10:35:37PM +, Matthew Garrett wrote: It shouldn't be forgotten that the biggest blocker after these things is probably a general failure to actually care all that much. How many people are actually behaving as if a release is just around the corner? How can we fix this? Talk to your leader. He's a persons person (I recall some talk about motivating people and stuff like like during the elections). No, I don't really mean that seriously. At least not the part about going to talk to Martin. It's a motivation problem. Simple as that. There's no cohesion. I have the feeling there's too much behind the scenes talking taking place. This mailing list is not even the shadow of what it used to be. There are hardly any really technical discussions taking place here. I doubt someone can actually *learn* something from following d-d anymore[0]. That means this mailing list has become somewhat a burden, not something you can enjoy, which is the cornerstone of volunteer work. A release is a big motivation boost: it's something you can see, something you can point people to. Ride on that wave. Debian's problem, seen from the inside (you don't have to give a damn about what the Slashdot crowd says), is that we let that wave break, and there isn't another one coming behind it. Marcelo [0] Besides learning that there is still people in this world who seem to think that feminism is actually a solution to something. I am still amazed by that one.
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 03:34:20PM +0100, Martin Schulze wrote: One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. What about saying something like: the next stable release comes in the beginning of 2006? The release date for a Debian release is not set by a calendar but by quality. At least that's been the case including sarge. Hence, such a sentence would not mean anything. Then let's accept the premise behind the whole testing idea and target Sarge+1 for Sarge+6 months. Or does the foo team have plan that will stall that release for another year? What if the installer is broken at that time? debian-installer is good as it is now. Sarge+6 months should be able to use more or less the same installer, plus new drivers. And a cursory look at the debian installer code gives me the impression that adding new drivers should be relatively easy. What if the buildd network is busted at that time? Well, I surely hope the buildd network won't be busted for x time (where x is much larger than a couple of weeks). Do you have something concrete in mind (like, say, one half of an arch builders bailing out because people can't seem to talk to each other or something like that?) What if n library transitions are in progress at that time? Well... according to the testing delus^Widea, this should not happen. Or, if it happens, it should be not so difficult to handle... Oh... hi, reality... nice to make your acquaintance. What if our archive suite lacks an important improvement which is a requirement for being able to maintain the new stable release? Come on. This one really feels like a cheap excuse. First, are any such important-can't-wait-a-second-longer improvements scheduled? Second, there's such a thing as testing. No, not that part of the archive. Real testing. Calling for people to upload real packages to a testing archive. Doing real work with the testing archive. Bouncing real uploads from the real archive to the testing archive. Such things. Third, there's also planning ahead. If Bar wants to absolutely have that important improvement before sarge+1, Bar should allot something like 3-4 *months* before the target release date for the in-archive testing phase and be ready to commit some time for urgent fixes. If that can't be done because all this is volunteer work and all those things (that I can fully relate to and I'm not downplaying one iota!), then sorry, we can't have that important improvement. IOW, don't stall the whole project because of your pet peeve. Sure, you could still release, but would you really like to have such a release? I would like to get rid of the Debian can't make timely releases and Debian stable is a bunch of out-of-date software stigmas. In fewer words: I want to have the cake and eat it, too. Debian stable without the 2 year lapsus in between. What if security support for a new release cannot be guaranteed at that time? That is a show stopper. We did our best, but we can't release Debian Sarge+1 at this time. New target date for release: ... If you give people a target to work with, with enough time (and enough has to take into consideration that Debian is still mostly put together by volunteers), people can plan ahead. The current chaos does not give *developers* this. And users get frustrated each time they see a Debian 3.0rX come out, but no sarge in sight. I do get your point and I'm not saying that it is easy (or even possible!) to stick to a faster release schedule, but refusing it upfromt without trying does not help. Marcelo
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 11:25:29PM +, Jonathan McDowell wrote: We've spent most of the past year thinking a release might be just round the corner. We can only cry wolf so many times before the world stops believing us and finds an option that actually works. You ought to hear the jokes I get to hear once a month on the local LUG meetings. Oh dear, next meeting is this saturday. Marcelo
Mail System (fons.spaan@central-europe.basf.org) ScanMail has blocked your mail due a mail policy. It is not allowed to send executables for security reasons. ScanMail hat Ihre Mail geblockt. Das Versenden von ausführbaren Anhängen ist auf Grund von Sicherheitsrisiken nicht erlaubt.
[EMAIL PROTECTED] BASF's virusscanner has blocked your mail since it contains executable files which may contain viruses and which are therefore blocked in general! If you need to send important files please put them into a zip archive. Der Virenschutz-Scanner der BASF hat die Nachricht geblockt da diese ausführbare Datei(en) enthält die Viren enthalten können und daher grundsätzlich nicht zugelassen werden! Wenn Sie wichtige Dateien versenden müssen so packen Sie diese bitte in ein zip-Archiv. Scanned by ScanMail for Lotus Notes 2.6 SP1 with scanengine 7.000-1011 and pattern version 2.333.00
Re: murphy is listed on spamcop
Russell Coker [EMAIL PROTECTED] writes: If you have any serious point to make then it can be made without reference to such people. However all your messages recently have been ad-hominem attacks, trying to compare me to Rumsfeld and now claiming that I have a problem with reality. Um, no. He tried to make a point by quoting somebody, and you (apparently) went off the deep end claiming he was comparing you to hitler, and have continued trying to defend this absurd contention. Now I guess you're trying to shift the blame for this stupid subthread onto Thomas's head. Anyway, it's clear that trying to discuss thing swith you is a pointless excercise in frustration, so I guess it doesn't matter one way or another if you stop; hopefully others can continue the discussion in a more thoughtful manner. -Miles -- Quidquid latine dictum sit, altum viditur.
Re: Orphaning some packages
hi thorsten, On Sat, Jan 01, 2005 at 04:14:03PM +0100, Thorsten Sauter wrote: I plan to orphan some of my packages. At the moment I have not enough time for those packages. cacti - Frontend to rrdtool for monitoring systems and services i'm a cacti user myself and would be happy to take this one over. at some point i even wrote up some code to help transition people from the version in woody, which i could probably dig up. sean -- signature.asc Description: Digital signature
Bug#288686: ITP: cssed -- a CSS editor
Package: wnpp Severity: wishlist * Package name: cssed Version : 0.3.0 Upstream Author : Iago Rubio [EMAIL PROTECTED] * URL : http://cssed.sf.net/ * License : GPL Description : a CSS editor Application to help create and maintain CSS style sheets for web developing.
Re: murphy is listed on spamcop
On Wed, Jan 05, 2005 at 11:36:45AM +1100, Russell Coker wrote: If you have any serious point to make then it can be made without reference to such people. However all your messages recently have been ad-hominem attacks, trying to compare me to Rumsfeld and now claiming that I have a problem with reality. Do you think that this nonsense is going to make people forget TB's point[1]? You can scream Godwin all you like; but nobody is convinced, and the end result is that his point stands: you've failed to provide a real justification. As everyone understood his point, it has not been lost--regardless of how many times you assert that is has. [1] You cannot justify the bad things that happen as a result of your actions by saying that your goals *require* bad things to happen. -- Glenn Maynard
Accepted abcmidi 20050101-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 4 Jan 2005 08:37:05 +0100 Source: abcmidi Binary: abcmidi abcmidi-yaps Architecture: source i386 Version: 20050101-1 Distribution: unstable Urgency: low Maintainer: Anselm Lingnau [EMAIL PROTECTED] Changed-By: Anselm Lingnau [EMAIL PROTECTED] Description: abcmidi- converter from ABC to MIDI format and back abcmidi-yaps - yet another ABC to PostScript converter Closes: 287050 Changes: abcmidi (20050101-1) unstable; urgency=low . * New upstream release * In particular, the DJB security bugs are now fixed (closes: #287050). * Fixed another very similar bug five lines above the other ones. Looks as if DJB's students aren't as hot as all that, after all ... Files: e801dc782362d5b1ab716f9c63842c0b 586 sound optional abcmidi_20050101-1.dsc fc1c31f21787e9af297bc6f4c6f6c4c9 258937 sound optional abcmidi_20050101.orig.tar.gz 5232bc1b6f649760ad6868656ffbddb0 4385 sound optional abcmidi_20050101-1.diff.gz 24c7e1fe962127ad3e58f8e789dafa42 173714 sound optional abcmidi_20050101-1_i386.deb 5cb6fbd4d551e0227d84f6b52f4686bd 107864 sound optional abcmidi-yaps_20050101-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB2lbxtQIutYLqZT4RAktQAKCsPyIqx89B0tvA2BnQphpsY1U7UgCdFmCu 3sS3ZDS+Etqm9KBKihsUfp8= =4l6e -END PGP SIGNATURE- Accepted: abcmidi-yaps_20050101-1_i386.deb to pool/main/a/abcmidi/abcmidi-yaps_20050101-1_i386.deb abcmidi_20050101-1.diff.gz to pool/main/a/abcmidi/abcmidi_20050101-1.diff.gz abcmidi_20050101-1.dsc to pool/main/a/abcmidi/abcmidi_20050101-1.dsc abcmidi_20050101-1_i386.deb to pool/main/a/abcmidi/abcmidi_20050101-1_i386.deb abcmidi_20050101.orig.tar.gz to pool/main/a/abcmidi/abcmidi_20050101.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted rezound 0.11.1beta-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 26 Nov 2004 15:39:05 +0100 Source: rezound Binary: rezound Architecture: source i386 Version: 0.11.1beta-3 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] Description: rezound- Audio file editor Changes: rezound (0.11.1beta-3) unstable; urgency=low . * removed xfs dependency, the problems with fonts are most likely X server configuration mistakes and are not related to rezound. Files: ee92ab7464134b48026c32ae19a025b8 802 sound optional rezound_0.11.1beta-3.dsc a71ead7f205592abb52be074bd8e765b 129066 sound optional rezound_0.11.1beta-3.diff.gz 844a3334cefcca889cbbfd828e051ade 1389004 sound optional rezound_0.11.1beta-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB2lp21pbKhmC2uVgRAkwaAJ9oZrhzUQRvZBbkfuBRc2UEdIqAtACdGeXx e4Gma7AyCDxTQvEheh4V6I8= =E5gO -END PGP SIGNATURE- Accepted: rezound_0.11.1beta-3.diff.gz to pool/main/r/rezound/rezound_0.11.1beta-3.diff.gz rezound_0.11.1beta-3.dsc to pool/main/r/rezound/rezound_0.11.1beta-3.dsc rezound_0.11.1beta-3_i386.deb to pool/main/r/rezound/rezound_0.11.1beta-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tor 0.0.9.2-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 4 Jan 2005 11:14:03 +0100 Source: tor Binary: tor Architecture: source i386 Version: 0.0.9.2-1 Distribution: unstable Urgency: low Maintainer: Peter Palfrader [EMAIL PROTECTED] Changed-By: Peter Palfrader [EMAIL PROTECTED] Description: tor- anonymizing overlay network for TCP Changes: tor (0.0.9.2-1) unstable; urgency=low . * New upstream version. * Update debian/copyright (it's 2005). * Add sharedscripts tor logrotate.d/tor. Files: fafdf0811405a3877828ff7296bc2be1 625 comm optional tor_0.0.9.2-1.dsc 65fe27324904c350be555e4eb0ae9fcd 539296 comm optional tor_0.0.9.2.orig.tar.gz 609916ce82c6ce1fc1c00ebf9ee64fe3 11572 comm optional tor_0.0.9.2-1.diff.gz 5ebffd49031d68731098ad3277ee8668 763830 comm optional tor_0.0.9.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB2nO+z/ccs6+kS90RAqg3AJ95hly6Ih6bRznX9sgRypDkgZtb+gCcDBZk f4FZn/8charl5rPBJnJimME= =Y5dU -END PGP SIGNATURE- Accepted: tor_0.0.9.2-1.diff.gz to pool/main/t/tor/tor_0.0.9.2-1.diff.gz tor_0.0.9.2-1.dsc to pool/main/t/tor/tor_0.0.9.2-1.dsc tor_0.0.9.2-1_i386.deb to pool/main/t/tor/tor_0.0.9.2-1_i386.deb tor_0.0.9.2.orig.tar.gz to pool/main/t/tor/tor_0.0.9.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cupsys 1.1.23-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 4 Jan 2005 19:32:16 +0900 Source: cupsys Binary: cupsys-bsd libcupsys2-dev libcupsys2 cupsys libcupsys2-gnutls10 libcupsimage2-dev libcupsimage2 cupsys-client Architecture: source i386 all Version: 1.1.23-1 Distribution: unstable Urgency: low Maintainer: Kenshi Muto [EMAIL PROTECTED] Changed-By: Kenshi Muto [EMAIL PROTECTED] Description: cupsys - Common UNIX Printing System(tm) - server cupsys-bsd - Common UNIX Printing System(tm) - BSD commands cupsys-client - Common UNIX Printing System(tm) - client programs (SysV) libcupsimage2 - Common UNIX Printing System(tm) - image libs libcupsimage2-dev - Common UNIX Printing System(tm) - image development files libcupsys2 - Common UNIX Printing System(tm) - dummy libs for transition libcupsys2-dev - Common UNIX Printing System(tm) - development files libcupsys2-gnutls10 - Common UNIX Printing System(tm) - libs Closes: 288531 Changes: cupsys (1.1.23-1) unstable; urgency=low . * New upstream release * lprng disabled ipp feature since 3.8.26-1. Remove conflicts: lprng of cupsys. (closes: #288531) Files: 38fc4ffdf8ceb416b6a875d509ede186 819 net optional cupsys_1.1.23-1.dsc d6995f493129e9637581f3a717c8345e 10071818 net optional cupsys_1.1.23.orig.tar.gz a2f8b6c46fbdcf4bca0f11464d57a10f 1270046 net optional cupsys_1.1.23-1.diff.gz 7e9a42fe01b8acb29184e33aece2e575 966 libs optional libcupsys2_1.1.23-1_all.deb 2788e59e252bf7b33da9f36d5342af23 8935472 net optional cupsys_1.1.23-1_i386.deb 32b1d9605e65a3ac6333ad45592d1f64 91416 net optional cupsys-client_1.1.23-1_i386.deb d1f721af348d7c441bec0bf063fd065c 74038 libs optional libcupsys2-gnutls10_1.1.23-1_i386.deb bb5859d362f423abff5d407b5568768b 85214 libdevel optional libcupsys2-dev_1.1.23-1_i386.deb a1f02832ec67dcc37d6ffe397ae32642 35498 libs optional libcupsimage2_1.1.23-1_i386.deb 2b34b80af34bbef17168454d884e1b9e 45888 libdevel optional libcupsimage2-dev_1.1.23-1_i386.deb 38b64b518485e8d1d12a3f34879091b4 40890 net extra cupsys-bsd_1.1.23-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iEYEARECAAYFAkHadI4ACgkQQKW+7XLQPLHDNwCgpE1ylBPkzDSHd6fXnHefhV3J InMAnAonZt/WZtZcsK1lHagt5JOYzgMt =DeRk -END PGP SIGNATURE- Accepted: cupsys-bsd_1.1.23-1_i386.deb to pool/main/c/cupsys/cupsys-bsd_1.1.23-1_i386.deb cupsys-client_1.1.23-1_i386.deb to pool/main/c/cupsys/cupsys-client_1.1.23-1_i386.deb cupsys_1.1.23-1.diff.gz to pool/main/c/cupsys/cupsys_1.1.23-1.diff.gz cupsys_1.1.23-1.dsc to pool/main/c/cupsys/cupsys_1.1.23-1.dsc cupsys_1.1.23-1_i386.deb to pool/main/c/cupsys/cupsys_1.1.23-1_i386.deb cupsys_1.1.23.orig.tar.gz to pool/main/c/cupsys/cupsys_1.1.23.orig.tar.gz libcupsimage2-dev_1.1.23-1_i386.deb to pool/main/c/cupsys/libcupsimage2-dev_1.1.23-1_i386.deb libcupsimage2_1.1.23-1_i386.deb to pool/main/c/cupsys/libcupsimage2_1.1.23-1_i386.deb libcupsys2-dev_1.1.23-1_i386.deb to pool/main/c/cupsys/libcupsys2-dev_1.1.23-1_i386.deb libcupsys2-gnutls10_1.1.23-1_i386.deb to pool/main/c/cupsys/libcupsys2-gnutls10_1.1.23-1_i386.deb libcupsys2_1.1.23-1_all.deb to pool/main/c/cupsys/libcupsys2_1.1.23-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ttthreeparser 1.4-5 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 03 Jan 2005 15:02:23 + Source: ttthreeparser Binary: ttthreeparser Architecture: source all Version: 1.4-5 Distribution: unstable Urgency: low Maintainer: W. Borgert [EMAIL PROTECTED] Changed-By: W. Borgert [EMAIL PROTECTED] Description: ttthreeparser - Parser for the TTCN-3 test specification language Changes: ttthreeparser (1.4-5) unstable; urgency=low . * Fix lintians. * Use CDBS. Files: f140564fe4f7f5b86f4ab5ca3ab0adfd 678 devel extra ttthreeparser_1.4-5.dsc 5f23c3502c07b0ec13a22df380c49778 3142 devel extra ttthreeparser_1.4-5.diff.gz 7e5a098ae33c9d5cadd0f7384130aa9f 192110 devel extra ttthreeparser_1.4-5_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB2nJk+xM0OFfj6IgRAmCUAKCCzi8wEN4yvh3Qg51O9hD2pdbIVQCgj+tq gT+SQyWLtfLmBizBseGqQZk= =oB41 -END PGP SIGNATURE- Accepted: ttthreeparser_1.4-5.diff.gz to pool/main/t/ttthreeparser/ttthreeparser_1.4-5.diff.gz ttthreeparser_1.4-5.dsc to pool/main/t/ttthreeparser/ttthreeparser_1.4-5.dsc ttthreeparser_1.4-5_all.deb to pool/main/t/ttthreeparser/ttthreeparser_1.4-5_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted wavesurfer 1.7.3-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 4 Jan 2005 10:56:12 +0100 Source: wavesurfer Binary: wavesurfer Architecture: source all Version: 1.7.3-2 Distribution: unstable Urgency: low Maintainer: Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] Changed-By: Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] Description: wavesurfer - Sound Manipulation Program Closes: 285667 Changes: wavesurfer (1.7.3-2) unstable; urgency=low . * Fixed wrong index in doc-base (closes: 285667) Files: 83b84a7ac7d6767d368bd07772e74092 599 sound optional wavesurfer_1.7.3-2.dsc da43430ea7cd316a6a3b9c7ce57f6baf 4469 sound optional wavesurfer_1.7.3-2.diff.gz b435eaaae5aa464d85a75f132e084b12 247274 sound optional wavesurfer_1.7.3-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB2mpb1pbKhmC2uVgRAk02AJ40+OjE1gPizX1+bHbqbrEGfSyvTwCfY3Fp g8V8yda9D8OZMi5xPjy5YnY= =b+L1 -END PGP SIGNATURE- Accepted: wavesurfer_1.7.3-2.diff.gz to pool/main/w/wavesurfer/wavesurfer_1.7.3-2.diff.gz wavesurfer_1.7.3-2.dsc to pool/main/w/wavesurfer/wavesurfer_1.7.3-2.dsc wavesurfer_1.7.3-2_all.deb to pool/main/w/wavesurfer/wavesurfer_1.7.3-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted puredata 0.38.0+amidi-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 4 Jan 2005 10:18:03 +0100 Source: puredata Binary: puredata Architecture: source i386 Version: 0.38.0+amidi-1 Distribution: unstable Urgency: low Maintainer: Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] Changed-By: Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] Description: puredata - realtime computer music and graphics system Closes: 265452 283988 Changes: puredata (0.38.0+amidi-1) unstable; urgency=low . * New upstream version * removed the -mcpu flag for alpha (closes: 265452) * preinst now removes the doc/1.manual directory so it can be properly linked by dh_link (closes: 283988) Files: fe91fd3aaf3befb299aeab923d95701a 651 sound optional puredata_0.38.0+amidi-1.dsc db7c8233748cff1c0791fb71fafd41d7 2044661 sound optional puredata_0.38.0+amidi.orig.tar.gz 66b56f20867a8aa783c4d273140b3ba0 12103 sound optional puredata_0.38.0+amidi-1.diff.gz 0c3871f7a652f1ad5f9cc2332014f7dd 1467840 sound optional puredata_0.38.0+amidi-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB2mtL1pbKhmC2uVgRAtG1AKCOMGctTENPKBqNOTojdA3ySqSMSwCdEhOY NMXDkzWcjs6PI3Z6cxT/0xM= =o8g8 -END PGP SIGNATURE- Accepted: puredata_0.38.0+amidi-1.diff.gz to pool/main/p/puredata/puredata_0.38.0+amidi-1.diff.gz puredata_0.38.0+amidi-1.dsc to pool/main/p/puredata/puredata_0.38.0+amidi-1.dsc puredata_0.38.0+amidi-1_i386.deb to pool/main/p/puredata/puredata_0.38.0+amidi-1_i386.deb puredata_0.38.0+amidi.orig.tar.gz to pool/main/p/puredata/puredata_0.38.0+amidi.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted specimen 0.4.5-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 28 Dec 2004 14:58:39 -0200 Source: specimen Binary: specimen Architecture: source i386 Version: 0.4.5-1 Distribution: unstable Urgency: low Maintainer: Eduardo Marcel Macan [EMAIL PROTECTED] Changed-By: Eduardo Marcel Macan [EMAIL PROTECTED] Description: specimen - MIDI controllable audio sampler for GNU/Linux systems Changes: specimen (0.4.5-1) unstable; urgency=low . * New upstream release. Files: e0333a410f0d0cb49caafbae95972af0 665 sound optional specimen_0.4.5-1.dsc 384f4fc32f50ede70a3ecceb070ee51a 205510 sound optional specimen_0.4.5.orig.tar.gz 1f23db4c57d929c675e66760a848e027 5975 sound optional specimen_0.4.5-1.diff.gz 44950bc154946b75a0a6458a9f645061 85768 sound optional specimen_0.4.5-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB2e2goUSye+uc2tURAmxuAJ9XElGsI/SBFzNb+bNYA3q0lpH45QCghHYw rkOJ3LOoCQ/2AsPUOhOLTpg= =874R -END PGP SIGNATURE- Accepted: specimen_0.4.5-1.diff.gz to pool/main/s/specimen/specimen_0.4.5-1.diff.gz specimen_0.4.5-1.dsc to pool/main/s/specimen/specimen_0.4.5-1.dsc specimen_0.4.5-1_i386.deb to pool/main/s/specimen/specimen_0.4.5-1_i386.deb specimen_0.4.5.orig.tar.gz to pool/main/s/specimen/specimen_0.4.5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted snd 7.8-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 4 Jan 2005 11:26:19 +0100 Source: snd Binary: snd snd-gtk-alsa snd-doc snd-gtk Architecture: source i386 all Version: 7.8-1 Distribution: unstable Urgency: low Maintainer: Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] Changed-By: Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] Description: snd- Sound file editor snd-doc- Sound file editor (documentation) snd-gtk- Sound file editor (GTK+ user interface) snd-gtk-alsa - Sound file editor (GTK+ user interface) Closes: 284668 Changes: snd (7.8-1) unstable; urgency=low . * New upstream version (closes: 284668) Files: a43dcc55f51c2357d886a99d8ac3877e 788 sound optional snd_7.8-1.dsc 3a2ba6cda90382df6967203501207b28 5733403 sound optional snd_7.8.orig.tar.gz a796304483cd30a59b46e10c45a6dcf0 11219 sound optional snd_7.8-1.diff.gz 9c311bfefddf478006a0430dc1ac0188 1010772 sound optional snd_7.8-1_all.deb d0f7a4a590fc34779ac27459dce7897e 2042462 doc optional snd-doc_7.8-1_all.deb 55497d6fcc7206841efeb395b1bd4632 976112 sound optional snd-gtk_7.8-1_i386.deb a339e4dae744ceb6764a917ee8361827 977500 sound optional snd-gtk-alsa_7.8-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB2neP1pbKhmC2uVgRAvd9AJ9kFPkq2hN13UywJvijGsYEFON4TACfRMTh WITXLRaDQIZiZgMpsjtmx+c= =JZLx -END PGP SIGNATURE- Accepted: snd-doc_7.8-1_all.deb to pool/main/s/snd/snd-doc_7.8-1_all.deb snd-gtk-alsa_7.8-1_i386.deb to pool/main/s/snd/snd-gtk-alsa_7.8-1_i386.deb snd-gtk_7.8-1_i386.deb to pool/main/s/snd/snd-gtk_7.8-1_i386.deb snd_7.8-1.diff.gz to pool/main/s/snd/snd_7.8-1.diff.gz snd_7.8-1.dsc to pool/main/s/snd/snd_7.8-1.dsc snd_7.8-1_all.deb to pool/main/s/snd/snd_7.8-1_all.deb snd_7.8.orig.tar.gz to pool/main/s/snd/snd_7.8.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python-crypto 2.0+dp1-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 1 Jan 2005 14:47:12 +0100 Source: python-crypto Binary: python2.1-crypto python-crypto python2.3-crypto python2.2-crypto Architecture: source i386 Version: 2.0+dp1-1 Distribution: unstable Urgency: medium Maintainer: Andreas Rottmann [EMAIL PROTECTED] Changed-By: Andreas Rottmann [EMAIL PROTECTED] Description: python-crypto - cryptographic algorithms and protocols for Python python2.1-crypto - cryptographic algorithms and protocols for Python python2.2-crypto - cryptographic algorithms and protocols for Python python2.3-crypto - cryptographic algorithms and protocols for Python Closes: 273622 Changes: python-crypto (2.0+dp1-1) unstable; urgency=medium . * Again remove problematic code from orig tarball, which the NMU did miss (not to mention that the orig tarball from the NMU wasn't pristine and contained .pyc files). Urgency medium, so sarge won't end up with problematic code. * Include the manual in binary packages (closes: #273622). * Switch to CDBS. * Lowercase description synopsis, as suggested by lintian/developer's reference. * Advertice the newly-included (since 2.0) SHA256 module in the description. Files: a31b47d140cb2e049967ecd401ff2bf5 711 python optional python-crypto_2.0+dp1-1.dsc e475c8f75442e43bfd932f815ab23bea 158649 python optional python-crypto_2.0+dp1.orig.tar.gz 774773e5e43797c5eef33c8cd8f8b63b 3837 python optional python-crypto_2.0+dp1-1.diff.gz 1ccd91ffefff28443d821b1f240c0991 10460 python optional python-crypto_2.0+dp1-1_i386.deb 26c117bb143d9492168fc5de4ad01545 158684 python optional python2.1-crypto_2.0+dp1-1_i386.deb ad5beecde149ad7279fba42b37e5aaa5 177170 python optional python2.2-crypto_2.0+dp1-1_i386.deb a2d05fef0d9b20a0d8a430c3e4410a66 177232 python optional python2.3-crypto_2.0+dp1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB2piu+S/PxQH9W2IRAh/kAKCOcLWDlQBEOiV/9RB9CM2SX1BVVACfSI8t LOVb9in2qNGWcqx96myM744= =A94U -END PGP SIGNATURE- Accepted: python-crypto_2.0+dp1-1.diff.gz to pool/main/p/python-crypto/python-crypto_2.0+dp1-1.diff.gz python-crypto_2.0+dp1-1.dsc to pool/main/p/python-crypto/python-crypto_2.0+dp1-1.dsc python-crypto_2.0+dp1-1_i386.deb to pool/main/p/python-crypto/python-crypto_2.0+dp1-1_i386.deb python-crypto_2.0+dp1.orig.tar.gz to pool/main/p/python-crypto/python-crypto_2.0+dp1.orig.tar.gz python2.1-crypto_2.0+dp1-1_i386.deb to pool/main/p/python-crypto/python2.1-crypto_2.0+dp1-1_i386.deb python2.2-crypto_2.0+dp1-1_i386.deb to pool/main/p/python-crypto/python2.2-crypto_2.0+dp1-1_i386.deb python2.3-crypto_2.0+dp1-1_i386.deb to pool/main/p/python-crypto/python2.3-crypto_2.0+dp1-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python-gtk2-tutorial 2.3-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 4 Jan 2005 12:30:11 +0100 Source: python-gtk2-tutorial Binary: python-gtk2-tutorial Architecture: source all Version: 2.3-1 Distribution: unstable Urgency: low Maintainer: Igor Stroh [EMAIL PROTECTED] Changed-By: Igor Stroh [EMAIL PROTECTED] Description: python-gtk2-tutorial - tutorial for the GTK2 python library Closes: 271050 275062 Changes: python-gtk2-tutorial (2.3-1) unstable; urgency=low . * New upstream version * Suggest only python-gtk2 and python-gtk2-doc, thanks to Floris Bruynooghe (Closes: #271050) * Added README.Debian with a brief warning about pygtk2 versions in Debian, thanks to Picca Frederic (Closes: #275062) * Fixed short description to satisfy lintian Files: 96d610f9a5e6f6f1edd2ca7f37794664 613 doc optional python-gtk2-tutorial_2.3-1.dsc a5f0f048e36c80527cd53a46f5453d89 1456937 doc optional python-gtk2-tutorial_2.3.orig.tar.gz c5f5b7c79e03810b982114d657ae8de1 1925 doc optional python-gtk2-tutorial_2.3-1.diff.gz 56f3a87674c45fa068326f2d7bd42dd6 1473918 doc optional python-gtk2-tutorial_2.3-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB2p3vNfye6peqM9YRApanAJ4lJsbRLchPJm/z/ms8qaQJSVQ5UQCgshvL 8OdSor03etIOAdcy/JLKNoE= =qU9L -END PGP SIGNATURE- Accepted: python-gtk2-tutorial_2.3-1.diff.gz to pool/main/p/python-gtk2-tutorial/python-gtk2-tutorial_2.3-1.diff.gz python-gtk2-tutorial_2.3-1.dsc to pool/main/p/python-gtk2-tutorial/python-gtk2-tutorial_2.3-1.dsc python-gtk2-tutorial_2.3-1_all.deb to pool/main/p/python-gtk2-tutorial/python-gtk2-tutorial_2.3-1_all.deb python-gtk2-tutorial_2.3.orig.tar.gz to pool/main/p/python-gtk2-tutorial/python-gtk2-tutorial_2.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python-gtk2-doc 2.5.1-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 4 Jan 2005 12:30:11 +0100 Source: python-gtk2-doc Binary: python-gtk2-doc Architecture: source all Version: 2.5.1-1 Distribution: unstable Urgency: low Maintainer: Igor Stroh [EMAIL PROTECTED] Changed-By: Igor Stroh [EMAIL PROTECTED] Description: python-gtk2-doc - documentation and API reference of GTK2 bindings for python Changes: python-gtk2-doc (2.5.1-1) unstable; urgency=low . * New upstream version * Fixed short description to satisfy lintian Files: b295514be26eaf29dd40990772456219 598 doc optional python-gtk2-doc_2.5.1-1.dsc 4c7317d271c6465cb9ff6ee97b6ceaf2 873774 doc optional python-gtk2-doc_2.5.1.orig.tar.gz b99b7685d1b888e163f26e9b09d4b92b 1931 doc optional python-gtk2-doc_2.5.1-1.diff.gz 8625b3ab708686cd6e9812672cc1777f 874080 doc optional python-gtk2-doc_2.5.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB2p0dNfye6peqM9YRAi2YAJ4qg+eJ0l0jhoHxbc5JTnrLELF5fACfeZlJ QSSr2xy6/OSFtvoy2RWellc= =o3Zs -END PGP SIGNATURE- Accepted: python-gtk2-doc_2.5.1-1.diff.gz to pool/main/p/python-gtk2-doc/python-gtk2-doc_2.5.1-1.diff.gz python-gtk2-doc_2.5.1-1.dsc to pool/main/p/python-gtk2-doc/python-gtk2-doc_2.5.1-1.dsc python-gtk2-doc_2.5.1-1_all.deb to pool/main/p/python-gtk2-doc/python-gtk2-doc_2.5.1-1_all.deb python-gtk2-doc_2.5.1.orig.tar.gz to pool/main/p/python-gtk2-doc/python-gtk2-doc_2.5.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted drgeo 1.0.0-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 1 Jan 2005 16:39:07 +0100 Source: drgeo Binary: drgeo Architecture: source i386 Version: 1.0.0-1 Distribution: unstable Urgency: high Maintainer: Stephen Quinney [EMAIL PROTECTED] Changed-By: Hilaire Fernandes [EMAIL PROTECTED] Description: drgeo - An interactive geometry software Closes: 253356 254230 273411 277786 284075 285644 Changes: drgeo (1.0.0-1) unstable; urgency=high . * New upstream release. Closes: #273411, #253356, #254230, #277786, #284075, #285644 Files: 4b55edaaa154ec24befe6ee846e90b96 660 math extra drgeo_1.0.0-1.dsc 397158a710f9437b463739e1d008ee12 1527984 math extra drgeo_1.0.0.orig.tar.gz 5d4503981b00bb0d22cb74489adf7cca 24390 math extra drgeo_1.0.0-1.diff.gz eaf2954c4846361ea517c890a57e8b46 772890 math extra drgeo_1.0.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB2pwXITGblEwaW+URAj9zAKC7wNK48VBMNwGfGWLMZhu1LQU1WQCeNa/8 b+AmUFVh5TYDdcSy0Lu0q/Y= =3Imz -END PGP SIGNATURE- Accepted: drgeo_1.0.0-1.diff.gz to pool/main/d/drgeo/drgeo_1.0.0-1.diff.gz drgeo_1.0.0-1.dsc to pool/main/d/drgeo/drgeo_1.0.0-1.dsc drgeo_1.0.0-1_i386.deb to pool/main/d/drgeo/drgeo_1.0.0-1_i386.deb drgeo_1.0.0.orig.tar.gz to pool/main/d/drgeo/drgeo_1.0.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted roundup 0.7.10-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 4 Jan 2005 11:30:05 +0100 Source: roundup Binary: roundup Architecture: source all Version: 0.7.10-1 Distribution: unstable Urgency: low Maintainer: Bastian Kleineidam [EMAIL PROTECTED] Changed-By: Bastian Kleineidam [EMAIL PROTECTED] Description: roundup- issue-tracking system Closes: 286727 Changes: roundup (0.7.10-1) unstable; urgency=low . * New upstream release. - the orig.tar.gz is repacked without the superfluous CVS file roundup/backends/.#rdbms_common.py.1.98.2.29 * patch 06_roundup_typo: dropped - applied upstream * patch 07_send_file_fix: new - catch NotModified exception when try to send files Thanks to Alexander Goldstein for the patch. (Closes: #286727) * patch 08_update_manpages: new - updated man pages for roundup-* commands Files: 7997d5686076da13e8c661f72f0906ea 622 web optional roundup_0.7.10-1.dsc 033d8ad048af10b0b367a08d28ae2971 732653 web optional roundup_0.7.10.orig.tar.gz afa044c8b43488643b70deabd297a9bc 15520 web optional roundup_0.7.10-1.diff.gz a22ee234f57a4ca6a05e84584528966e 690896 web optional roundup_0.7.10-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB2p0veBwlBDLsbz4RAu+pAJ4xEVMb22KI/KLmklXXtxKTfRCRTwCbBHAv Z4jQQRWnQ9yZJcpNlSt+vpE= =Le2w -END PGP SIGNATURE- Accepted: roundup_0.7.10-1.diff.gz to pool/main/r/roundup/roundup_0.7.10-1.diff.gz roundup_0.7.10-1.dsc to pool/main/r/roundup/roundup_0.7.10-1.dsc roundup_0.7.10-1_all.deb to pool/main/r/roundup/roundup_0.7.10-1_all.deb roundup_0.7.10.orig.tar.gz to pool/main/r/roundup/roundup_0.7.10.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted nvram-wakeup 0.97-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 29 Dec 2004 23:52:04 +0100 Source: nvram-wakeup Binary: nvram-wakeup Architecture: source i386 Version: 0.97-5 Distribution: unstable Urgency: low Maintainer: Debian VDR Team [EMAIL PROTECTED] Changed-By: Debian VDR Team [EMAIL PROTECTED] Description: nvram-wakeup - A tool to read/write the WakeUp time from/to the BIOS Changes: nvram-wakeup (0.97-5) unstable; urgency=low . * Thomas Schmidt [EMAIL PROTECTED] - Added nvram-wakeup-mb.c rev 1.245 from cvs to have the newest mainboard list Files: 3076386ff7df3b64e9c447d977fc3ea0 720 misc optional nvram-wakeup_0.97-5.dsc 1c06522168358d1439cd1c3fc4e83221 19672 misc optional nvram-wakeup_0.97-5.diff.gz b514f0e9b019439968c729c49489ee6b 87154 misc optional nvram-wakeup_0.97-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB2qWIgeVih7XOVJcRAj/qAJ9e/lX0mCjgXpKHzY7Z8qjODI7l6wCfR3LF 0pPMGpl96iT3eGA4J4VEah4= =Mm1x -END PGP SIGNATURE- Accepted: nvram-wakeup_0.97-5.diff.gz to pool/main/n/nvram-wakeup/nvram-wakeup_0.97-5.diff.gz nvram-wakeup_0.97-5.dsc to pool/main/n/nvram-wakeup/nvram-wakeup_0.97-5.dsc nvram-wakeup_0.97-5_i386.deb to pool/main/n/nvram-wakeup/nvram-wakeup_0.97-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnome-themes 2.8.2-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 4 Jan 2005 15:09:03 +0100 Source: gnome-themes Binary: gtk2-engines-thinice gnome-accessibility-themes gnome-themes gtk2-engines-crux gtk2-engines-mist gtk2-engines-lighthouseblue gtk2-engines-highcontrast Architecture: source i386 all Version: 2.8.2-1 Distribution: unstable Urgency: low Maintainer: Josselin Mouette [EMAIL PROTECTED] Changed-By: Josselin Mouette [EMAIL PROTECTED] Description: gnome-accessibility-themes - accessibility themes for the GNOME 2 desktop gnome-themes - official themes for the GNOME 2 desktop gtk2-engines-crux - the Crux theme engine for GTK+ 2.x gtk2-engines-highcontrast - High contrast GTK+ 2.x theme engine gtk2-engines-lighthouseblue - LighthouseBlue theme for GTK+ 2.x gtk2-engines-mist - flat theme for GTK+ 2.x gtk2-engines-thinice - the ThinIce theme engine for GTK+ 2.x Changes: gnome-themes (2.8.2-1) unstable; urgency=low . * New upstream release. * 00_relibtoolize.patch: updated. Files: f00b2bf58c5de5c5ebc55b8b6249a7bf 1609 gnome optional gnome-themes_2.8.2-1.dsc 9f1cef7e4567667b8141dfadffa3e5c3 3128290 gnome optional gnome-themes_2.8.2.orig.tar.gz 478ec6228c98eb9accb9769489a174bd 15804 gnome optional gnome-themes_2.8.2-1.diff.gz 87e09d05aaa471b2393421a83f6c64d5 265352 gnome optional gnome-themes_2.8.2-1_all.deb faf0315caafcd5faf37749172d4756dc 1830052 gnome optional gnome-accessibility-themes_2.8.2-1_all.deb 89f8d496c1fbb5e4cb66af54433c5b59 42338 gnome optional gtk2-engines-highcontrast_2.8.2-1_i386.deb 9faff46952489a83d97db9f450a3515e 197560 gnome optional gtk2-engines-crux_2.8.2-1_i386.deb 000daa1480ea0997e8a8b7588979fa90 25726 gnome optional gtk2-engines-lighthouseblue_2.8.2-1_i386.deb 899ae2c1362c6f7fc3c4096522dea369 196922 gnome optional gtk2-engines-mist_2.8.2-1_i386.deb fe5f2bcaf40089c5fe4138927a05cb4a 42202 gnome optional gtk2-engines-thinice_2.8.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB2qf2rSla4ddfhTMRAi82AJ991YlCxK7S6bNVN5Z6M0iCwLCMmwCfYk88 0TaSARljRKFROqDzwKT9AWQ= =9ipX -END PGP SIGNATURE- Accepted: gnome-accessibility-themes_2.8.2-1_all.deb to pool/main/g/gnome-themes/gnome-accessibility-themes_2.8.2-1_all.deb gnome-themes_2.8.2-1.diff.gz to pool/main/g/gnome-themes/gnome-themes_2.8.2-1.diff.gz gnome-themes_2.8.2-1.dsc to pool/main/g/gnome-themes/gnome-themes_2.8.2-1.dsc gnome-themes_2.8.2-1_all.deb to pool/main/g/gnome-themes/gnome-themes_2.8.2-1_all.deb gnome-themes_2.8.2.orig.tar.gz to pool/main/g/gnome-themes/gnome-themes_2.8.2.orig.tar.gz gtk2-engines-crux_2.8.2-1_i386.deb to pool/main/g/gnome-themes/gtk2-engines-crux_2.8.2-1_i386.deb gtk2-engines-highcontrast_2.8.2-1_i386.deb to pool/main/g/gnome-themes/gtk2-engines-highcontrast_2.8.2-1_i386.deb gtk2-engines-lighthouseblue_2.8.2-1_i386.deb to pool/main/g/gnome-themes/gtk2-engines-lighthouseblue_2.8.2-1_i386.deb gtk2-engines-mist_2.8.2-1_i386.deb to pool/main/g/gnome-themes/gtk2-engines-mist_2.8.2-1_i386.deb gtk2-engines-thinice_2.8.2-1_i386.deb to pool/main/g/gnome-themes/gtk2-engines-thinice_2.8.2-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mime-support 3.29-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Format: 1.7 Date: Tue, 4 Jan 2005 09:30:14 -0500 Source: mime-support Binary: mime-support Architecture: source all Version: 3.29-1 Distribution: unstable Urgency: medium Maintainer: Brian White [EMAIL PROTECTED] Changed-By: Brian White [EMAIL PROTECTED] Description: mime-support - MIME files 'mime.types' 'mailcap', and support programs Closes: 264536 281083 284830 Changes: mime-support (3.29-1) unstable; urgency=medium . * added more mime types (closes: #284830) * made common extensions first (closes: #264536) * removed duplicate application/x-sh (closes: #281083) Files: 650b3226ba48719b8da1e3c6e38c7de6 578 net standard mime-support_3.29-1.dsc 7af417741e30fe9f38e37dee90c9d377 35708 net standard mime-support_3.29-1.tar.gz 9b4baa31352eabeeb373f56d12374ded 29600 net standard mime-support_3.29-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iQCVAwUBQdqol/IOJCznesg1AQG0mAQAiuESL+2fxRz/9Flx5oOiAiVg4NJYOfg7 n/gUGhUmtrhOkpaOiLRqCN39eGKA6d7PHIN5FKAPxiK1Nt4R47CkvbIltU91AWSs vQaB54+FCjYznjCa78ZLNSfogc5pHYh9lQPItCkpf3VnvZMTFl8wsYBChYnpaYo+ /aRBNfufCYw= =TUtT -END PGP SIGNATURE- Accepted: mime-support_3.29-1.dsc to pool/main/m/mime-support/mime-support_3.29-1.dsc mime-support_3.29-1.tar.gz to pool/main/m/mime-support/mime-support_3.29-1.tar.gz mime-support_3.29-1_all.deb to pool/main/m/mime-support/mime-support_3.29-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted openssh 1:3.9p1-1 (powerpc all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 4 Jan 2005 14:18:31 + Source: openssh Binary: ssh-askpass-gnome openssh-client-udeb ssh openssh-server openssh-client openssh-server-udeb Architecture: source powerpc all Version: 1:3.9p1-1 Distribution: experimental Urgency: low Maintainer: Matthew Vernon [EMAIL PROTECTED] Changed-By: Colin Watson [EMAIL PROTECTED] Description: openssh-client - Secure shell client, an rlogin/rsh/rcp replacement openssh-client-udeb - Secure shell client for the Debian installer (udeb) openssh-server - Secure shell server, an rshd replacement openssh-server-udeb - Secure shell server for the Debian installer (udeb) ssh- Secure shell client and server (transitional package) ssh-askpass-gnome - under X, asks user for a passphrase for ssh-add Closes: 228828 238699 242119 242462 264024 265627 273831 Changes: openssh (1:3.9p1-1) experimental; urgency=low . * New upstream release. - PAM password authentication implemented again (closes: #238699, #242119). - Implemented the ability to pass selected environment variables between the client and the server. - Fix ssh-keyscan breakage when remote server doesn't speak SSH protocol (closes: #228828). - Fix res_query detection (closes: #242462). - 'ssh -c' documentation improved (closes: #265627). * Pass LANG and LC_* environment variables from the client by default, and accept them to the server by default in new installs, although not on upgrade (closes: #264024). * Build ssh in binary-indep, not binary-arch (thanks, LaMont Jones). * Expand on openssh-client package description (closes: #273831). Files: d3cc887508ec2ffbace8b173a2c5d784 912 net standard openssh_3.9p1-1.dsc 530b1dcbfe7a4a4ce4959c0775b85a5a 832804 net standard openssh_3.9p1.orig.tar.gz 575cd6f93343d887a8397dbf5e7f4a6b 139755 net standard openssh_3.9p1-1.diff.gz 9c44450630f66dd5ef72d9f412d5bfc4 30168 net optional ssh_3.9p1-1_all.deb 2bb0f90f04bb1e590bda4c3ddaca762f 537276 net standard openssh-client_3.9p1-1_powerpc.deb 59a1a9e363bbb0547b463c6b1986ce68 272054 net optional openssh-server_3.9p1-1_powerpc.deb 051956c380df82d1a5fee859255afbfa 63146 gnome optional ssh-askpass-gnome_3.9p1-1_powerpc.deb 241447fc56c145fdbd0bc413cd218999 157986 debian-installer optional openssh-client-udeb_3.9p1-1_powerpc.udeb cfb379b6b80af072ef23d7b6b2b9f0e7 163128 debian-installer optional openssh-server-udeb_3.9p1-1_powerpc.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Colin Watson [EMAIL PROTECTED] -- Debian developer iD8DBQFB2qfV9t0zAhD6TNERAiUTAJ9aZdADM2YURTa0hwiMS1hBsexzYwCaA5Ev YpghpbXKqWjTYRO+Bi52bA8= =H+Lu -END PGP SIGNATURE- Accepted: openssh-client-udeb_3.9p1-1_powerpc.udeb to pool/main/o/openssh/openssh-client-udeb_3.9p1-1_powerpc.udeb openssh-client_3.9p1-1_powerpc.deb to pool/main/o/openssh/openssh-client_3.9p1-1_powerpc.deb openssh-server-udeb_3.9p1-1_powerpc.udeb to pool/main/o/openssh/openssh-server-udeb_3.9p1-1_powerpc.udeb openssh-server_3.9p1-1_powerpc.deb to pool/main/o/openssh/openssh-server_3.9p1-1_powerpc.deb openssh_3.9p1-1.diff.gz to pool/main/o/openssh/openssh_3.9p1-1.diff.gz openssh_3.9p1-1.dsc to pool/main/o/openssh/openssh_3.9p1-1.dsc openssh_3.9p1.orig.tar.gz to pool/main/o/openssh/openssh_3.9p1.orig.tar.gz ssh-askpass-gnome_3.9p1-1_powerpc.deb to pool/main/o/openssh/ssh-askpass-gnome_3.9p1-1_powerpc.deb ssh_3.9p1-1_all.deb to pool/main/o/openssh/ssh_3.9p1-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted vdradmin 0.96-3 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 29 Dec 2004 12:32:10 +0100 Source: vdradmin Binary: vdradmin Architecture: source all Version: 0.96-3 Distribution: unstable Urgency: high Maintainer: Debian VDR Team [EMAIL PROTECTED] Changed-By: Debian VDR Team [EMAIL PROTECTED] Description: vdradmin - Web-based administration tool for vdr Closes: 287601 Changes: vdradmin (0.96-3) unstable; urgency=high . * Thomas Schmidt [EMAIL PROTECTED] - Urgency high, because it fixes a security issue - Added 02_sectmpfiles.dpatch: use File::Temp to create temporary files, to prevent possible symlink-attacks (Closes: #287601) - Set permissions of /etc/vdradmin/vdradmind.conf to 600 on new installations (users with an existing installation should ensure that the cfg-file has a permission of 600) - Changed Maintainer to Debian VDR Team [EMAIL PROTECTED] - Added myself as uploader - Build-depend on dpatch (= 2.0.9) - Converted 01_dist-var.dpatch to the new short format Files: 4b9bf72dc5aea1893f1fb0a75a058eb2 715 web optional vdradmin_0.96-3.dsc 4dd78d3e30110eb9b036fbc2cffd8cfe 5478 web optional vdradmin_0.96-3.diff.gz a1b27fb6538bacf6941be64084f4739e 318064 web optional vdradmin_0.96-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB2qljgeVih7XOVJcRAggdAJwJHlzD6eooaQwyk0T0VjvFh3reegCePaY+ Z0QbRFnstnt+895EJf+K2bQ= =QmlV -END PGP SIGNATURE- Accepted: vdradmin_0.96-3.diff.gz to pool/main/v/vdradmin/vdradmin_0.96-3.diff.gz vdradmin_0.96-3.dsc to pool/main/v/vdradmin/vdradmin_0.96-3.dsc vdradmin_0.96-3_all.deb to pool/main/v/vdradmin/vdradmin_0.96-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted i2c 1:2.9.0-6 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 4 Jan 2005 15:45:06 +0100 Source: i2c Binary: i2c-source i2c-2.4.27-1-k6 kernel-patch-2.4-i2c i2c-2.4.27-1-k7-smp i2c-2.4.27-1-586tsc i2c-2.4.27-1-686-smp i2c-2.4.27-1-386 i2c-2.4.27-1-k7 i2c-2.4.27-1-686 Architecture: source i386 all Version: 1:2.9.0-6 Distribution: unstable Urgency: high Maintainer: Aurelien Jarno [EMAIL PROTECTED] Changed-By: Aurelien Jarno [EMAIL PROTECTED] Description: i2c-2.4.27-1-386 - drivers for the i2c bus i2c-2.4.27-1-586tsc - drivers for the i2c bus i2c-2.4.27-1-686 - drivers for the i2c bus i2c-2.4.27-1-686-smp - drivers for the i2c bus i2c-2.4.27-1-k6 - drivers for the i2c bus i2c-2.4.27-1-k7 - drivers for the i2c bus i2c-2.4.27-1-k7-smp - drivers for the i2c bus i2c-source - sources for drivers for the i2c bus kernel-patch-2.4-i2c - Drivers for the i2c bus Closes: 288489 Changes: i2c (1:2.9.0-6) unstable; urgency=high . * If need, remove old diversions of the package before adding the new the ones (closes: bug#288489). Files: 4f26310816d737cb8fd314345a23355e 838 misc extra i2c_2.9.0-6.dsc 237673d778e855e57c4acd99b8aee797 9159 misc extra i2c_2.9.0-6.diff.gz 07ff1c99ede010b4805a446dd7531512 103566 misc extra kernel-patch-2.4-i2c_2.9.0-6_all.deb 604f9f6a2de1dfd5c14ef3b6bd1fb20a 153242 misc extra i2c-source_2.9.0-6_all.deb 9e079efbc1aaa85280e84d98526f6cdf 76064 misc extra i2c-2.4.27-1-386_2.9.0-6_i386.deb 6492ab4dd99fc0384a2011f3419f819f 75848 misc extra i2c-2.4.27-1-586tsc_2.9.0-6_i386.deb 4ee26e0b6089327f76f84f8387a3421a 75848 misc extra i2c-2.4.27-1-686_2.9.0-6_i386.deb 51d235f16659dfefbc9e0885ae69599d 75890 misc extra i2c-2.4.27-1-686-smp_2.9.0-6_i386.deb c42a7bd2b6b4d68454ac9520d91f793c 75844 misc extra i2c-2.4.27-1-k6_2.9.0-6_i386.deb 3e6ac2c20658222e2b781ca430d618f0 75880 misc extra i2c-2.4.27-1-k7_2.9.0-6_i386.deb fc68f2c44f4b718428a2eb998f0534ae 75938 misc extra i2c-2.4.27-1-k7-smp_2.9.0-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB2qzFw3ao2vG823MRAh7OAJ4tmiR1hh/L6Iu1XAI/+7vl69h4fwCghEfP SD0oNaKTM7Avz4PGfx8A9dc= =eEbF -END PGP SIGNATURE- Accepted: i2c-2.4.27-1-386_2.9.0-6_i386.deb to pool/main/i/i2c/i2c-2.4.27-1-386_2.9.0-6_i386.deb i2c-2.4.27-1-586tsc_2.9.0-6_i386.deb to pool/main/i/i2c/i2c-2.4.27-1-586tsc_2.9.0-6_i386.deb i2c-2.4.27-1-686-smp_2.9.0-6_i386.deb to pool/main/i/i2c/i2c-2.4.27-1-686-smp_2.9.0-6_i386.deb i2c-2.4.27-1-686_2.9.0-6_i386.deb to pool/main/i/i2c/i2c-2.4.27-1-686_2.9.0-6_i386.deb i2c-2.4.27-1-k6_2.9.0-6_i386.deb to pool/main/i/i2c/i2c-2.4.27-1-k6_2.9.0-6_i386.deb i2c-2.4.27-1-k7-smp_2.9.0-6_i386.deb to pool/main/i/i2c/i2c-2.4.27-1-k7-smp_2.9.0-6_i386.deb i2c-2.4.27-1-k7_2.9.0-6_i386.deb to pool/main/i/i2c/i2c-2.4.27-1-k7_2.9.0-6_i386.deb i2c-source_2.9.0-6_all.deb to pool/main/i/i2c/i2c-source_2.9.0-6_all.deb i2c_2.9.0-6.diff.gz to pool/main/i/i2c/i2c_2.9.0-6.diff.gz i2c_2.9.0-6.dsc to pool/main/i/i2c/i2c_2.9.0-6.dsc kernel-patch-2.4-i2c_2.9.0-6_all.deb to pool/main/i/i2c/kernel-patch-2.4-i2c_2.9.0-6_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted squid-prefetch 1.0-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Format: 1.7 Date: Tue, 4 Jan 2005 09:39:52 -0500 Source: squid-prefetch Binary: squid-prefetch Architecture: source all Version: 1.0-1 Distribution: unstable Urgency: medium Maintainer: Brian White [EMAIL PROTECTED] Changed-By: Brian White [EMAIL PROTECTED] Description: squid-prefetch - Simple page-prefetch for Squid web proxy Closes: 234441 234693 267737 Changes: squid-prefetch (1.0-1) unstable; urgency=medium . * fixed problem locating squid config file (closes: #267737) * fixed (I think) URL looping problem (closes: #234441) * fixed problem with invalid-url error on prefetch (closes: #234693) Files: b20f796a35a6458fa8df7d9521964825 579 web optional squid-prefetch_1.0-1.dsc b3e555bcfef918d2176628a477505811 6842 web optional squid-prefetch_1.0-1.tar.gz a632afbe3fcbe1364c630a463f08b547 6878 web optional squid-prefetch_1.0-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iQCVAwUBQdqq3PIOJCznesg1AQFdDgP+NZGYulOUAz/c6Jfrz5V4Rqom2KeEiWGp 7p4ZkBrHlVHSon6hF0fvBZ9+hJGIkLnmRd/Dv791UfdiNxWbqjN/AOeNMSBe41al 7dQNnNMFjAvU968yR/2XdzvB03U5rH4G4IsB/dFwJYTJ48+SjPMdJ2uNlsfD5Fjq wOv7RlG+VJ0= =7mau -END PGP SIGNATURE- Accepted: squid-prefetch_1.0-1.dsc to pool/main/s/squid-prefetch/squid-prefetch_1.0-1.dsc squid-prefetch_1.0-1.tar.gz to pool/main/s/squid-prefetch/squid-prefetch_1.0-1.tar.gz squid-prefetch_1.0-1_all.deb to pool/main/s/squid-prefetch/squid-prefetch_1.0-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted yaboot-installer 1.0.3 (powerpc source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 4 Jan 2005 14:41:21 + Source: yaboot-installer Binary: yaboot-installer Architecture: source powerpc Version: 1.0.3 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Colin Watson [EMAIL PROTECTED] Description: yaboot-installer - Install yaboot on a hard disk (udeb) Changes: yaboot-installer (1.0.3) unstable; urgency=low . * Colin Watson - Add chrp_rs6k support, matching chrp. * Updated translations: - Spanish (Castilian) (es.po) by Javier Fernandez-Sanguino Peña Files: 4c90eda9a0454d53be7e513c308657fd 781 debian-installer standard yaboot-installer_1.0.3.dsc 551daca905245f9c27279398ebcd4807 53438 debian-installer standard yaboot-installer_1.0.3.tar.gz 54a11abe56c05adb7ff493b0f925673a 36322 debian-installer standard yaboot-installer_1.0.3_powerpc.udeb package-type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Colin Watson [EMAIL PROTECTED] -- Debian developer iD8DBQFB2qte9t0zAhD6TNERAqoVAJ0UcHrFqvcMROKswjWC+ivFT946JACfQNvO ldxM8pUYQS/OIsUfDxiOwY8= =95AY -END PGP SIGNATURE- Accepted: yaboot-installer_1.0.3.dsc to pool/main/y/yaboot-installer/yaboot-installer_1.0.3.dsc yaboot-installer_1.0.3.tar.gz to pool/main/y/yaboot-installer/yaboot-installer_1.0.3.tar.gz yaboot-installer_1.0.3_powerpc.udeb to pool/main/y/yaboot-installer/yaboot-installer_1.0.3_powerpc.udeb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
