Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
On Tue, May 03, 2005 at 07:06:36PM -0700, Steve Langasek wrote: The license of the GNUTLS OpenSSL shim is GPL, causing possible license problems in the other direction with GPL-incompatible apps. It's also not a very complete compatibility layer. So dynamically link against _an_ SSL library, using dlopen(), and this completely trumps the issue. The fact that there are multiple libraries, implementing the OpenSSL interface, means that as long as the application calls the *interface* it can't be derived from *either* library, and it escapes the license incompatibility issues. (Remember, license compatibility can only be an issue if the program can be shown to be a derived work of a particular library. If it is calling an interface which is implemented by more than one library, then clearly it can't be a derived work, and once it is not a derived work, copyright law by definition can't apply.) Example: The libss library searches for the readline, editline, and libedit libraries via a search path, and dlopen()'s the first one it can find. It the calls those interfaces to get readline functionality. The Solaris SEAM (Solaris Enterprise Authentication Mechanism), which is a propietary program which is derived from the MIT Kerberos V5 sources, also happens to call the libss library, with which it is dynamically linked. Yet now when you run the Kerberos administration CLI program from SEAM, and install the newer version of libss library so that it dynamically links with it, and then the libss library could possibly dlopen the GNU readline library you can a process containing propietary Solaris code, BSD licensed libss code, and GPL'ed readline library, all in the same address space. But has there been a GPL violation? No, since, the only time a derivitive work can conclusively shown to be created is when the user ran the kadmin program, and the GPL does not restrict use, only distribution. Could the kadmin program be considered a derived work of the readline library? No, because it was written to call libss *years* ago, long before libss was modified to potentially call the readline library. The kadmin program called the libss *interface*, and at the time the author of the kadmin program had no idea that it might subsequently end up calling a GPL'ed library indirectly via libss. And furthermore, the BSD-licensed libss program does not even directly link against the readline library, but rather uses dlopen() and dlsym() to call a particular *interface* which could be satisified either by a GPL or BSD licensed library. So how can you say that the libss program is a derivitive work of either library? I believe you can use a similar solution to solve the openssl library problem. If there is a shim layer, and the application uses a search path to find a library which it then dlopen()'s, this should completely trump the license compatibility issue, since in this case it is clear that it is not a derived work of any one particular library, but rather it is calling an interface which can be satisified by multiple libraries, and which library will get used can only be determined at run-time. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
On Wed, May 04, 2005 at 02:08:01AM -0400, Theodore Ts'o wrote: On Tue, May 03, 2005 at 07:06:36PM -0700, Steve Langasek wrote: The license of the GNUTLS OpenSSL shim is GPL, causing possible license problems in the other direction with GPL-incompatible apps. It's also not a very complete compatibility layer. Could the kadmin program be considered a derived work of the readline library? No, because it was written to call libss *years* ago, long before libss was modified to potentially call the readline library. I'm not sure this is the right list for this, but... (If you decide that I need learnin', and take this to another list, please CC me. ^_^) Surely the above statement (out of context) is actually an expected side-effect of Copyleft? Specifically, if you drag something GPL into your library, you _are_ requiring that all users (even the historical ones) be GPL-compatible, or not use that version of the library. Obviously kadmin is not a directly derived work of readline, but it is a derived work of libss, which is _now_ a derived work of readline. (Or would be, barring the dlopen solution. ^_^) This of course assumes the phrase derived work is legalese for code dependancy or something. I'm sure the GPL actually defines what _they_ mean by it... On the other hand, I agree the dlopen-interface argument below trumps this, but I would have to go re-read the GPL before I relied upon that myself. The kadmin program called the libss *interface*, and at the time the author of the kadmin program had no idea that it might subsequently end up calling a GPL'ed library indirectly via libss. And furthermore, the BSD-licensed libss program does not even directly link against the readline library, but rather uses dlopen() and dlsym() to call a particular *interface* which could be satisified either by a GPL or BSD licensed library. So how can you say that the libss program is a derivitive work of either library? -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean This email is licensed to the recipient for non-commercial use, duplication and distribution. --- pgp28XPT7aKgz.pgp Description: PGP signature
Re: Should Debian use lsb init-functions?
On Wed, May 04, 2005 at 07:56:14AM +0200, Marc Haber wrote: On Wed, 4 May 2005 01:34:17 +0200, Wouter Verhelst [EMAIL PROTECTED] wrote: On Wed, May 04, 2005 at 12:05:19AM +0200, Thomas Hood wrote: I think it would be better if we simply made rc capture initscripts' standard output (and exit status) and formatted it in such a way that bootup messages were prettier. That sounds like an ugly and error-prone hack to me. Not something we want one of our most important systems to be working with. The fact that there is much more than one init script which writes additional output in between the policy conformant Starting foo... Done., giving Starting foo... blurb blurb Done. is one of the most annoying facts in Debian, IMO. I won't deny that; but a) using LSB init scripts won't magically fix that, and b) that's one more reason to not rely on parsing of output to implement this. Additionally, it is bad that on systems which neither have a serial console nor a monitor attached init script output is inaccessible. False. See /etc/default/bootlogd (although it is not without problems) -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Should Debian use lsb init-functions?
On Wed, 4 May 2005 09:45:14 +0200, Wouter Verhelst [EMAIL PROTECTED] wrote: On Wed, May 04, 2005 at 07:56:14AM +0200, Marc Haber wrote: Additionally, it is bad that on systems which neither have a serial console nor a monitor attached init script output is inaccessible. False. See /etc/default/bootlogd (although it is not without problems) The bootlogd docs strongly suggest not using it. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Upcoming removals
Hello François, * François-Denis Gonthier [EMAIL PROTECTED] [2005-05-04 10:08]: On May 3, 2005 09:54 am, Martin Michlmayr wrote: #297426: O: langband -- The langband Common lisp game Reported by: Kevin M. Rosenberg [EMAIL PROTECTED]; 63 days old. #297427: O: langband-data -- The Langband sound/image/etc files for langband engine Reported by: Kevin M. Rosenberg [EMAIL PROTECTED]; 63 days old. Can a non-DD (like me) take over those packages? Yes there is no problem with this. But you have to search for someone who uploads the package for you (sponsor). For example you can ask for one on [EMAIL PROTECTED] Regards Nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgpHWGk712x1G.pgp Description: PGP signature
Re: Should Debian use lsb init-functions?
Marc Haber wrote: The bootlogd docs strongly suggest not using it. Out of curiosity, where? I checked /usr/share/doc/sysvinit, /usr/share/doc/initscripts, and bootlogd(8). The only thing I found was a warning about parsing the kernel's command line in the manpage. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rekall for Debian ?
Am 2005-05-04 13:31:48, schrieb Devrim GUNDUZ: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Wed, 4 May 2005, Michelle Konzack wrote: does anyone know, whether there is a Debian Package for Rekall or not ? There seems so: $ apt-cache search rekall rekall - graphical database front-end Strange, I was searching with apt-cache showsrc knoda recall kexi and gotten only results to knoda and kexi I have downloaded the Sources.bz2 from SARGE and SID manualy and it seems recall is not there, which is realy wiered because it is in the debian/pool for SID and SARGE (two versions). Searching the Packages.bz2 from SARGE and SID ends in the same resultat. Need to contackt the PTS/BTS Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
GGI maintainer seen recently? (Martin Albert)
Hi all, Has anyone had any contact with Martin Albert ([EMAIL PROTECTED]) recently? A new GGI release was made some time ago, but as far as I'm aware no-one involved in the GGI project has been able to contact him, and I may be interested in investigating doing this if MA does not intend to. I believe that GGI 2.1 is intended to be binary compatible with the currently-packaged 2.0.x, so the package name would stay the same (?), although there may be some extra libraries/extensions to be packaged in 2.1. The GGI 2.1 and 2.1.1 release announcements are here: http://marc.theaimsgroup.com/?l=ggi-developm=110186058218018w=2 http://marc.theaimsgroup.com/?l=ggi-developm=111369463201652w=2 Cheers, -- Neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Tue, May 03, 2005 at 12:40:21PM -0700, Steve Langasek wrote: ... On Tue, May 03, 2005 at 12:27:32PM +0200, Adrian Bunk wrote: first of all, if you downgrade a bug only a good hour after I upgraded it, it would be nice if you would: - Cc me - send a better explanation than This is not a missing dependency, feh If you are going to upgrade bugs to RC severity without talking to the maintainers first, it would be nice if you would be right. I have explained how this can produce non-working package combinations. If you do immediately lower the severity of a bug I raised the severity of again, could you please at least put my in the Cc header of the message you send to the BTS? In my testing, e.g. php4 from woody together with php4-mysql from sid is _not_ a working combination. $ apt-cache show php4-mysql Package: php4-mysql Version: 4:4.3.10-12 Depends: Depends: libc6 (= 2.3.2.ds1-4), libmysqlclient12, debconf (= 0.5) | debconf-2.0, phpapi-20020918, php4-common (= 4:4.3.10-12) ^^^ php4-mysql does not depend on php4 because the php4 package is *not* required to be installed in order for php4-mysql to be usable: installing any of the packages that provide phpapi-20020918 is sufficient to give you a php4 engine that can be used with php4-mysql. php4-mysql does not depend on any particular package providing the interface, because it has no way of knowing which one the user wants. The actual bug you're describing, therefore, is that the package relationships do not prevent you from having multiple PHP engines co-installed on your system that each provide different extension ABIs. This is a well-known bug that's irritating but not release-critical, and fixing it in sarge would not be at all straightforward. ... I'd consider this RC, and I think there might be good solutions that are not too difficult (e.g. Conflicts with the woody versions). But with this explanation, I understand your point. Communication is important. Why haven't you simply sent this explanation together with the control message and a Cc to me? This way I would have understood why you've downgraded it (whether I agree or not), and instead of becoming angry I would have thought about possible solutions for this bug (with this information I didn't have before). With this information you've now shared with me, my suggestion would be: All the packages providing phpapi-20020918 are built from the same source package. What about providing php-4.3.10 and letting packages like php4-mysql depend on such a version-specific provides? This would also make sense in cases like the ZTS transitions were you could change this Provides and automatically have all dependencies correct. Perhaps this suggestion doesn't work for some reason. But if you'd have shared the reasons why you don't think this issue was RC, you'd have helped me to think about ways how to fix this issue properly instead of sending an unfriendly email. I do admit that my email was overly unfriendly, but I hope you can understand that a bit of information from you would have been better. Steve Langasek cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Tue, May 03, 2005 at 09:24:34AM -0700, Thomas Bushnell BSG wrote: Adrian Bunk [EMAIL PROTECTED] writes: You seem to confuse this with bug closing. It's common practice to adjust the severity of a bug to a RC one if a RC issue was mistakenly reported as non-RC, and neither your Developers Reference nor your release team have ever disagreed with this practice. If you are also encountering the bug, then this is true, but I would expect you, being as knowledgeable as you are, to indicate that in the bug report and add yourself as a submitter. I didn't know a bug can have more than one submitter. What's the syntax for the email to [EMAIL PROTECTED] for adding a second submitter? ... Even Steve had always agreed that missing dependencies that break partial upgrades from woody were RC bugs And even in the email were he downgraded this bug he only wrongly stated This is not a missing dependency - not that missing dependencies weren't RC. This seems to indicate that he thinks there is a different explanation for the bug, and that while adding the package in question as a dependency makes it go away, this is not the correct fix. But I can only guess, as can you, which means it would be good to hold off until he can say rather than play BTS tag. That's exactly the problem. He has now given an explanation. As I've said in another email in this thread, giving this explanation in the email he lowered the severity with and sending me a Cc would have been perfect. Thomas cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rekall for Debian ?
Am Mittwoch, 4. Mai 2005 13.08 schrieb Michelle Konzack: Morning On Wed, 4 May 2005, Michelle Konzack wrote: does anyone know, whether there is a Debian Package for Rekall or not ? There seems so: $ apt-cache search rekall rekall - graphical database front-end ^ Strange, I was searching with apt-cache showsrc knoda recall kexi ^ and gotten only results to knoda and kexi See that recall and rekall aren't the same thing. griits Mario -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#307570: please provide releasenotes (Re: Release update: editorial changes to the testing propagation scripts)
On Wed, May 04, 2005 at 01:23:25AM +0200, Holger Levsen wrote: This might be related to the fact the they're somewhat hidden, at least to ./google sarge releasenotes - http://www.debian.org/releases/testing/releasenotes isn't helpful atm either. Why not? Isn't http://www.debian.org/releases/testing/i386/release-notes/ch-upgrading.en.html#s-upgradingpackages sufficient? It does say that you first net to get aptitude and then use that as the recommended upgrade mechanism. Regards Javier signature.asc Description: Digital signature
Re: Rekall for Debian ?
Am 2005-05-04 13:27:38, schrieb Mario Fux: Am Mittwoch, 4. Mai 2005 13.08 schrieb Michelle Konzack: Morning On Wed, 4 May 2005, Michelle Konzack wrote: apt-cache showsrc knoda recall kexi See that recall and rekall aren't the same thing. Oops, I mean rekall But Sources.gz and Packages.gz from SARGE and SID do not contain the rekall package which I have manualy verified for some minutes. griits Mario Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Rekall for Debian ?
In article [EMAIL PROTECTED] you wrote: rekall - graphical database front-end Strange, I was searching with apt-cache showsrc knoda recall kexi ---^ Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#307570: please provide releasenotes (Re: Release update: editorial changes to the testing propagation scripts)
Hi Javier, On Wednesday 04 May 2005 13:49, Javier Fernández-Sanguino Peña wrote: This might be related to the fact the they're somewhat hidden, at least to ./google sarge releasenotes - http://www.debian.org/releases/testing/releasenotes isn't helpful atm either. Why not? Isn't http://www.debian.org/releases/testing/i386/release-notes/ch-upgrading.en.h tml#s-upgradingpackages sufficient? It is. But it wasnt there last night. Someone (thanks!) fixed it today at 01:51:49 Uhr UTC, rougly 30 minutes after my mail ;) I closed the bug now. When I saw this tomorrow morning I was a little bit to find the old browser window from last night still open, showing me, the page was indeed empty last night ;-)) btw, google has no (good) hits for sarge releasenotes, but for sarge release notes they have... maybe this helps. regards, Holger, dropping debian-release from cc: as that list is busy enough today ;-) pgpLOySm6vPbB.pgp Description: PGP signature
RE: [GENERAL] Rekall for Debian ?
Didi you notice rekallrecall? :-) :-) What is the correct name anyway? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michelle Konzack Sent: Wednesday, May 04, 2005 1:08 PM To: pgsql-general Cc: debian-devel Subject: Re: [GENERAL] Rekall for Debian ? Am 2005-05-04 13:31:48, schrieb Devrim GUNDUZ: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Wed, 4 May 2005, Michelle Konzack wrote: does anyone know, whether there is a Debian Package for Rekall or not ? There seems so: $ apt-cache search rekall rekall - graphical database front-end Strange, I was searching with apt-cache showsrc knoda recall kexi and gotten only results to knoda and kexi I have downloaded the Sources.bz2 from SARGE and SID manualy and it seems recall is not there, which is realy wiered because it is in the debian/pool for SID and SARGE (two versions). Searching the Packages.bz2 from SARGE and SID ends in the same resultat. Need to contackt the PTS/BTS Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com)
Re: Should Debian use lsb init-functions?
On Tue, 03 May 2005, Russ Allbery wrote: One concern I'd have is that using the LSB functions is (at least somewhat) lintian-testable, whereas the standard for stdout/stderr usage would be much more difficult to test in a lintian/linda sort of way. Making widespread changes happen that are lintian-verifiable seems a lot easier to do than making changes that aren't. Yes, but the fact that it is a bit more difficult to write lintian tests for such stuff pales in comparison to the benefits of the stdout/stderr tagging approach. Besides, we will be rewriting and going fine-comb over all the initscripts anyway (it is pointless to even imagine that the maintainer themselves will do it. Some will never get to it, so the pragmatic view is: do it yourself, make sure it is right, then submit the patches). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rekall for Debian ?
On Wednesday 04 May 2005 07:56 am, Michelle Konzack wrote: Am 2005-05-04 13:27:38, schrieb Mario Fux: Am Mittwoch, 4. Mai 2005 13.08 schrieb Michelle Konzack: Morning On Wed, 4 May 2005, Michelle Konzack wrote: apt-cache showsrc knoda recall kexi See that recall and rekall aren't the same thing. Oops, I mean rekall But Sources.gz and Packages.gz from SARGE and SID do not contain the rekall package which I have manualy verified for some minutes. rekall is only in experimental. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Should Debian use lsb init-functions?
On Wed, 04 May 2005, Wouter Verhelst wrote: I think it would be better if we simply made rc capture initscripts' standard output (and exit status) and formatted it in such a way that bootup messages were prettier. That sounds like an ugly and error-prone hack to me. Not something we want one of our most important systems to be working with. Ugly hack? Not at all, it is good design. At wrost, you get human-parseable output that, while it does not make enough sense for the system to color it green or red, won't break anything (i.e. exactly what we have right now). All messages from every initscript will be easy to group together (hint: tagging the origin of the messages is not done by the initscript, but by the initscript system) and to track, lint, log, etc. It does not force the use of posix shell for the initscripts, either. Believe it or not, usage of posix shell for initscripts is not mandated anywhere, and it would be poor design to force it for no good reason. As for error prone, have you ever tried to audit our initscripts? A controlled rewrite of all of them would benefit us a lot anyway. I don't think echo'ing ERROR: or OK: to stdout/stderr is any more error-prone than calling shell functions (which we will provide in the lsb package anyway, so if someone wants to pre-depends on lsb...) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
bootlogd (was: Should Debian use lsb init-functions?)
On Wed, 04 May 2005 06:25:14 -0400, Anthony DeRobertis [EMAIL PROTECTED] wrote: Marc Haber wrote: The bootlogd docs strongly suggest not using it. Out of curiosity, where? I didn't find that information, so I'll have to retract my statement. However, bug #217582 suggests that there still are bugs. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Rekall for Debian ?
Michelle == Michelle Konzack [EMAIL PROTECTED] writes: But Sources.gz and Packages.gz from SARGE and SID do not contain the rekall package which I have manualy verified for some minutes. It is _not_ in sid/sarge. It's been uploaded only to experimental. Ganesan -- Ganesan Rajagopal (rganesan at debian.org) | GPG Key: 1024D/5D8C12EA Web: http://employees.org/~rganesan| http://rganesan.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release update: editorial changes to the testing propagation scripts
On Tue, May 03, 2005 at 12:46:32PM -0700, Steve Langasek wrote: ... 30 May 2005 Release And if everything goes well, we'll be ready to release at the end of the month. ... Setting goals is the easy part of release management. Ensuring that the goals are met is the hard part of the work of a release manager. This is the third officially announced release date for sarge that gets a wider media coverage. The December 1st 2003 date was missed because the development of the installer took more than a year longer than expected. The September 15th 2004 date was missed because the security infrastructure for testing took more than 6 months instead of only 6 days. I'm sure you've learned from these two fiascos, and you've done everything to ensure that you will not miss your milestone dates. Can you tell about the possible risks that may affect your release plan and what you have done to ensure that they will not delay your release plan? TIA Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release update: editorial changes to the testing propagation scripts
Adrian Bunk [EMAIL PROTECTED] wrote: Can you tell about the possible risks that may affect your release plan and what you have done to ensure that they will not delay your release plan? Why is this a worthwhile use of a release manager's time? How about we analyse the release /after/ we've successfully done it? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
APT 0.6 migration -- second status report
A test suite for package validation is now available: http://apt-secure-test.enyo.de/ Please refer to the README file in this directory for instructions how to use the test suite. The archives in the test suite are automatically generated by a collection of Python scripts. These scripts are available via darcs at: http://darcs.enyo.de/fw/apt-secure-test/ The command darcs get http://darcs.enyo.de/fw/apt-secure-test/; will download the repository. See the README file in the top-level directory for further instructions. I'm going to add further test cases (which depend on a time-traviling DSO to fool GnuPG into creating signatures with weired timestamps). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release update: editorial changes to the testing propagation scripts
On Wed, May 04, 2005 at 02:42:15PM +0200, Adrian Bunk wrote: Can you tell about the possible risks that may affect your release plan and what you have done to ensure that they will not delay your release plan? Can you tell me about the usefulness of whining[1] about release policy for years, and how this will not delay the release? --Jeroen [1] I don't use this word lightly in mail, but to be honest, your continued vendetta against the current release policy is quite annoying. Especially seen in the light of your resignation as Debian Developer, by which you abstained from any committment to help Debian constructively from the inside, this is not really a fair thing to do. As we say in the Netherlands, De beste stuurlui staan aan wal, The best boatsmen are standing on shore: it's easy to complain while not bearing any responsibility, rather than actually doing the job -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Wed, May 04, 2005 at 01:33:52PM +0200, Adrian Bunk wrote: I didn't know a bug can have more than one submitter. What's the syntax for the email to [EMAIL PROTECTED] for adding a second submitter? Not entirely the answer you're looking for, but submit a duplicate bug and merge it. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
* Mark Brown ([EMAIL PROTECTED]) [050504 16:00]: On Wed, May 04, 2005 at 01:33:52PM +0200, Adrian Bunk wrote: I didn't know a bug can have more than one submitter. What's the syntax for the email to [EMAIL PROTECTED] for adding a second submitter? Not entirely the answer you're looking for, but submit a duplicate bug and merge it. No, don't do that. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rekall for Debian ?
Am 2005-05-04 08:15:29, schrieb Josh Metzler: On Wednesday 04 May 2005 07:56 am, Michelle Konzack wrote: But Sources.gz and Packages.gz from SARGE and SID do not contain the rekall package which I have manualy verified for some minutes. rekall is only in experimental. Oh, I was thinking it is in SARGE and SID because two different versions of it. Josh Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Rekall for Debian ?
Question again: I have gotten rekall from the journal Linux User in version 2.2.1 and it does NOT require KDE! Now I see, that I need kdelibs to use it. Thats crazy !!! - Who has does this ? Last year I have seen someone on the Linuxtag 2004 in Karlsruhe who was NOT working with KDE. Kann the Dependencies removed ? It is already enough that Kexi and KNoda depends on kdelibs. Note: Installing the experimental package 2.2.3-2-1 on a SARGE testsystem will install 114 MByte Additional KDE stuff. Greetings Michelle Am 2005-05-04 08:15:29, schrieb Josh Metzler: On Wednesday 04 May 2005 07:56 am, Michelle Konzack wrote: Am 2005-05-04 13:27:38, schrieb Mario Fux: Am Mittwoch, 4. Mai 2005 13.08 schrieb Michelle Konzack: Morning On Wed, 4 May 2005, Michelle Konzack wrote: apt-cache showsrc knoda recall kexi See that recall and rekall aren't the same thing. Oops, I mean rekall But Sources.gz and Packages.gz from SARGE and SID do not contain the rekall package which I have manualy verified for some minutes. rekall is only in experimental. Josh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] - ENE OF REPLYED MESSAGE - -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: A way _not_ to handle bugs
On Wed, May 04, 2005 at 04:01:52PM +0200, Andreas Barth wrote: * Mark Brown ([EMAIL PROTECTED]) [050504 16:00]: Not entirely the answer you're looking for, but submit a duplicate bug and merge it. No, don't do that. It's ugly as hell and may well annoy the maintainer by creating noise but it will do the job. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Tue, May 03, 2005 at 01:54:46PM -0500, Adam M. wrote: Adrian Bunk wrote: grave - serious isn't worth a discussion since there's not a big difference between them (both are RC) You are 100% wrong here. Why do we have bug severities then? Severities are there to inform the developer and the rest of the Debian world about the seriousness of the bug. I tend to stay away from packages that have grave or critical bugs against them before I read the bug report. So, let me refresh your mind about bug severities, ... Let me try to reformulate my point: important - serious or important - grave are worth a discussion, because if the bug is only important it's not unlikely sarge will ship with this bug. We could have a lengthy discussion whether there are possible scenarios where a specific dependency problem might cause data loss (which would make it grave) or whether it's only a policy violation. (If you are using php4-mysql on a web server to write the orders of your costumers into a database, couldn't this bug cause data loss?) But the practical differences between critical, grave and serious are small enough that if I send a bug as grave and you'd downgrade it to serious, I wouldn't care. - Adam cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming removals
On May 4, 2005 04:38 am, Nico Golde wrote: Hello François, * François-Denis Gonthier [EMAIL PROTECTED] [2005-05-04 10:08]: On May 3, 2005 09:54 am, Martin Michlmayr wrote: #297426: O: langband -- The langband Common lisp game Reported by: Kevin M. Rosenberg [EMAIL PROTECTED]; 63 days old. #297427: O: langband-data -- The Langband sound/image/etc files for langband engine Reported by: Kevin M. Rosenberg [EMAIL PROTECTED]; 63 days old. Can a non-DD (like me) take over those packages? Yes there is no problem with this. But you have to search for someone who uploads the package for you (sponsor). For example you can ask for one on [EMAIL PROTECTED] Regards Nico Ow :( Both are gone of http://www.debian.org/devel/wnpp/rfa_bypackage, I guess that means I'm too late? F-D.G.
Re: Upcoming removals
* François-Denis Gonthier [EMAIL PROTECTED] [2005-05-04 11:05]: Both are gone of http://www.debian.org/devel/wnpp/rfa_bypackage, I guess that means I'm too late? No, they are listed at http://www.debian.org/devel/wnpp/orphaned rfa_bypackage is for packages which are RFA: Request For Adoption. The maintainer is looking for someone to take over but they maintain it in the meantime. orphaned is for packages which are O: orphaned. They maintained is no longer maintaining the package; the QA team is supposed to do low level maintenance work until it's adopted or removed from the archive. Read http://www.debian.org/devel/wnpp for more information. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Outrageous Maintainer
On 1 May 2005, at 8:53 am, Wouter Verhelst wrote: On Sun, May 01, 2005 at 12:38:41AM +0200, Jeroen van Wolffelaar wrote: On Sat, Apr 30, 2005 at 06:45:26PM -0300, Otavio Salvador wrote: But you remove the package from testing doesn't mean we won't have users with it installed since it was present there so, IMHO, the Conflict is need. The bug is in the other package, packages are not required to work around other bugs in other packages, that'd be a gigantic mess of workarounds. There'll be lots of workarounds, but that doesn't necessarily equate to 'a mess'. If dash breaks using my package for whatever reason, I'm not going to add a conflict: dash (with non-fixed version or whatever), dash needs to fix it. True. However, it does no harm to add the conflicts, while it does make it easier for your users. When presented with a bug in another package that completely breaks mine (rather than the entire system), usually I do add the conflicts: header. I think that's a dangerous thing to do. When the bug in the other package is fixed, the chances are that you won't know about it, and then you'll end up with two packages which conflict with each other for no reason. In this case, that's fair enough, because they're two variants of the same thing, but I don't think this sort of thing should be done in the general case. Tim -- Dr Tim Cutts GPG: 1024/D FC81E159 5BA6 8CD4 2C57 9824 6638 C066 16E2 F4F5 FC81 E159 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming removals
On Wed, May 04, 2005 at 04:29:37PM +0100, Martin Michlmayr wrote: * Fran?ois-Denis Gonthier [EMAIL PROTECTED] [2005-05-04 11:05]: Both are gone of http://www.debian.org/devel/wnpp/rfa_bypackage, I guess that means I'm too late? No, they are listed at http://www.debian.org/devel/wnpp/orphaned Also, the bug in question had package - description, not package -- description. At least the overview on PTS won't show the bug then. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release update: editorial changes to the testing propagation scripts
Quoting Matthew Garrett [EMAIL PROTECTED]: Adrian Bunk [EMAIL PROTECTED] wrote: Can you tell about the possible risks that may affect your release plan and what you have done to ensure that they will not delay your release plan? Why is this a worthwhile use of a release manager's time? How about we analyse the release /after/ we've successfully done it? It's a worthwhile use of a release manager's time precisely becuase failing to manage risk can result in an unsuccessful or delayed (again) release. Anyone that has managed a project of notable size can atest that under all but the most extraordinary circumstances, risk management is critical. If we wait until after the release to analyze the risks, we may never get there. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On 5/4/05, Adrian Bunk [EMAIL PROTECTED] wrote: On Tue, May 03, 2005 at 01:54:46PM -0500, Adam M. wrote: Adrian Bunk wrote: grave - serious isn't worth a discussion since there's not a big difference between them (both are RC) You are 100% wrong here. Why do we have bug severities then? Severities are there to inform the developer and the rest of the Debian world about the seriousness of the bug. I tend to stay away from packages that have grave or critical bugs against them before I read the bug report. So, let me refresh your mind about bug severities, ... Let me try to reformulate my point: important - serious or important - grave are worth a discussion, because if the bug is only important it's not unlikely sarge will ship with this bug. True, though important bugs can still be fixed during the freeze. We could have a lengthy discussion whether there are possible scenarios where a specific dependency problem might cause data loss (which would make it grave) or whether it's only a policy violation. (If you are using php4-mysql on a web server to write the orders of your costumers into a database, couldn't this bug cause data loss?) It wouldn't be grave just because it broke in my scenario. Data loss occurs when you think something worked, but it didn't. Or it corrupted/destroyed your data. I am ignorant to the actual bug though (haven't tried it myself). If the combination of php4 amd php4-mysql causes silent failures, then this is data loss and bug should be grave. If the application craps out with a visible error(s), or wrong output, then this bug does not cause data loss and is not grave. This doesn't mean all bugs are not important (not in BTS severity sense). I treat all bugs as important and try to resolve them. But the practical differences between critical, grave and serious are small enough that if I send a bug as grave and you'd downgrade it to serious, I wouldn't care. True, it doesn't really matter for the submitter if the bug is critical or serious if they only care that version X+1 of package doesn't go to testing due to the bug and X works. But severities do matter when you try to prioritize your work. For example, it is inappropriate for someone to file a critical bug just because they can't use feature X in program Alpha. Severties can and should be used to keep more buggy versions from progressing into testing. Severities are for practical reasons while many people still put their emotions into bug reports. This usually ends up with inflated bug severities. - Adam
Re: APT 0.6 migration -- second status report
* Florian Weimer wrote: [...] By the way... what about updating apt 0.6 in experimental? Matt, any plans? Ubuntu ships apt 0.6.35, but Debian still has 0.6.25. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
Adrian Bunk [EMAIL PROTECTED] writes: If you do immediately lower the severity of a bug I raised the severity of again, could you please at least put my in the Cc header of the message you send to the BTS? No, that's not a requirement. If you want to receive notifications, you should add yourself as a submitter. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
Adrian Bunk [EMAIL PROTECTED] writes: What's the syntax for the email to [EMAIL PROTECTED] for adding a second submitter? I believe submitter [EMAIL PROTECTED],[EMAIL PROTECTED] works just fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP: spca5xx -- Device driver for USB webcams based on the spca5xx chips
Carlos C Soto([EMAIL PROTECTED])@2005-04-19 14:55: Great! I use this module and wold be great to have it on debian. I was thinking on put a RFP bug for it. The package is not going to be ready in time for sarge though :-( Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Orphaning recover and makeztxt
Gunnar Wolf wrote: Hi, About makeztxt, it is a nice program to convert text files into ztxt files, apt for reading in a Palm with the (GPLed) Weasel reader. It has a simple regex engine used to create the TOCs, and works just fine. The problem is, I no longer own a Palm, so I cannot do much with it. I will happily pick this up for you. -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html pgpLtoobY5dMT.pgp Description: PGP signature
Re: Orphaning recover and makeztxt
John H. Robinson, IV wrote: Gunnar Wolf wrote: Hi, About makeztxt, it is a nice program to convert text files into ztxt files, apt for reading in a Palm with the (GPLed) Weasel reader. It has a simple regex engine used to create the TOCs, and works just fine. The problem is, I no longer own a Palm, so I cannot do much with it. I will happily pick this up for you. Looks like there were a few takers for this: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] I am happy to let Rolandas Juodzbalis have it. -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html pgpz172nTgTGK.pgp Description: PGP signature
Re: Release update: editorial changes to the testing propagation scripts
On Wed, May 04, 2005 at 03:05:24PM +0200, Jeroen van Wolffelaar wrote: On Wed, May 04, 2005 at 02:42:15PM +0200, Adrian Bunk wrote: Can you tell about the possible risks that may affect your release plan and what you have done to ensure that they will not delay your release plan? Can you tell me about the usefulness of whining[1] about release policy for years, and how this will not delay the release? --Jeroen [1] I don't use this word lightly in mail, but to be honest, your continued vendetta against the current release policy is quite annoying. Especially seen in the light of your resignation as Debian Developer, by which you abstained from any committment to help Debian constructively from the inside, this is not really a fair thing to do. As we say in the Netherlands, De beste stuurlui staan aan wal, The best boatsmen are standing on shore: it's easy to complain while not bearing any responsibility, rather than actually doing the job Very well said Jeroen. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Outrageous Maintainer
On Wed, May 04, 2005 at 04:35:25PM +0100, Tim Cutts wrote: On 1 May 2005, at 8:53 am, Wouter Verhelst wrote: True. However, it does no harm to add the conflicts, while it does make it easier for your users. When presented with a bug in another package that completely breaks mine (rather than the entire system), usually I do add the conflicts: header. I think that's a dangerous thing to do. When the bug in the other package is fixed, the chances are that you won't know about it, and then you'll end up with two packages which conflict with each other for no reason. That's why we have versioned conflicts. Also, when adding a conflicts to another package that is buggy, it would be _extremely_ bad form to not track that other package for when the bug is fixed -- or, at least, to file or reassign a bug to that package. In this case, that's fair enough, because they're two variants of the same thing, And, moreover, one of the two is now defunct. but I don't think this sort of thing should be done in the general case. It causes no harm, as long as one is careful. And isn't being careful something you should be doing anyway? -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Should Debian use lsb init-functions?
On Wed, May 04, 2005 at 09:25:31AM -0300, Henrique de Moraes Holschuh wrote: On Wed, 04 May 2005, Wouter Verhelst wrote: I think it would be better if we simply made rc capture initscripts' standard output (and exit status) and formatted it in such a way that bootup messages were prettier. That sounds like an ugly and error-prone hack to me. Not something we want one of our most important systems to be working with. Ugly hack? Not at all, it is good design. What have you been smoking? At wrost, you get human-parseable output that, while it does not make enough sense for the system to color it green or red, won't break anything (i.e. exactly what we have right now). ... in which case you'll get an output that looks similar to a current RedHat boot, except for those one or two lines that look completely out of touch with the rest, and the 'Parse Error' yell right below that. Sounds ugly to me. The alternative would be to have a transitional period in which initscripts are being moved to having lsb-style functions, but where the output of those functions is programmed to behave the same way our current initscripts do. That should not pose a problem. [...] As for error prone, have you ever tried to audit our initscripts? A controlled rewrite of all of them would benefit us a lot anyway. I'm not contesting that. On the contrary. But capturing an initscript's output and trying to parse that is a *bad*, *bad*, *bad* idea. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#307570: please provide releasenotes (Re: Release update: editorial changes to the testing propagation scripts)
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes: Why not? Isn't http://www.debian.org/releases/testing/i386/release-notes/ch-upgrading.en.html#s-upgradingpackages sufficient? the document suggests: , | aptitude -f --with-suggests --with-recommends dist-upgrade ` but aptitude 0.2.15.9-2 does not include the option '--with-suggests'
apt in experimental (Re: APT 0.6 migration -- second status report)
On Wed, May 04, 2005 at 05:41:18PM +0200, Norbert Tretkowski wrote: By the way... what about updating apt 0.6 in experimental? Matt, any plans? Ubuntu ships apt 0.6.35, but Debian still has 0.6.25. I have tried in the past to keep an updated apt in experimental, but it's non-trivial because of the dependent packages. That is, I would upload apt to experimental, along with python-apt+aptitude+synaptic+libapt-pkg-perl+etc. (versioned as NMUs). Then, new versions of these packages would be uploaded to unstable, which would supersede the versions I uploaded and cause them to be removed from experimental. This made the experimental apt significantly less useful, since most folks couldn't install it without removing these other packages (which they want to keep), unless they did the rebuilds themselves. One way around this would be for all of the maintainers of packages depending on apt to agree to a significant version number increment when moving to apt 0.6; then such versions could remain in experimental without being removed. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt in experimental (Re: APT 0.6 migration -- second status report)
hi, On Wed, May 04, 2005 at 12:05:26PM -0700, Matt Zimmerman wrote: One way around this would be for all of the maintainers of packages depending on apt to agree to a significant version number increment when moving to apt 0.6; then such versions could remain in experimental without being removed. or, since we're now officially in the sarge freeze(!) we could just put it into sid and not worry about the dependency issue, right? i've been using apt .6 on one of my machines, and while i haven't kept a super-close eye on it, i haven't noticed anything that would make me think it an unsuitable candidate for unstable. sean -- signature.asc Description: Digital signature
Re: Rekall for Debian ?
On Wed, May 04, 2005 at 04:10:47PM +0200, Michelle Konzack wrote: Am 2005-05-04 08:15:29, schrieb Josh Metzler: On Wednesday 04 May 2005 07:56 am, Michelle Konzack wrote: But Sources.gz and Packages.gz from SARGE and SID do not contain the rekall package which I have manualy verified for some minutes. rekall is only in experimental. Oh, I was thinking it is in SARGE and SID because two different versions of it. The name is sarge, not SARGE. Please don't shout at our releases. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: apt in experimental (Re: APT 0.6 migration -- second status report)
On Wed, May 04, 2005 at 03:28:08PM -0400, sean finney wrote: On Wed, May 04, 2005 at 12:05:26PM -0700, Matt Zimmerman wrote: One way around this would be for all of the maintainers of packages depending on apt to agree to a significant version number increment when moving to apt 0.6; then such versions could remain in experimental without being removed. or, since we're now officially in the sarge freeze(!) we could just put it into sid and not worry about the dependency issue, right? i've been using apt .6 on one of my machines, and while i haven't kept a super-close eye on it, i haven't noticed anything that would make me think it an unsuitable candidate for unstable. I was just talking with Colin Watson on IRC about that very idea; he says that library packages should still be handled carefully in unstable for now. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#307570: please provide releasenotes (Re: Release update: editorial changes to the testing propagation scripts)
Holger Levsen wrote: btw, google has no (good) hits for sarge releasenotes, but for sarge release notes they have... maybe this helps. Try sarge release notes - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt in experimental (Re: APT 0.6 migration -- second status report)
On Wed, May 04, 2005 at 01:10:53PM -0700, Matt Zimmerman wrote: On Wed, May 04, 2005 at 03:28:08PM -0400, sean finney wrote: On Wed, May 04, 2005 at 12:05:26PM -0700, Matt Zimmerman wrote: One way around this would be for all of the maintainers of packages depending on apt to agree to a significant version number increment when moving to apt 0.6; then such versions could remain in experimental without being removed. or, since we're now officially in the sarge freeze(!) we could just put it into sid and not worry about the dependency issue, right? i've been using apt .6 on one of my machines, and while i haven't kept a super-close eye on it, i haven't noticed anything that would make me think it an unsuitable candidate for unstable. I was just talking with Colin Watson on IRC about that very idea; he says that library packages should still be handled carefully in unstable for now. Right - the issue there is that library soname or shlibs changes cause larger numbers of other packages not to be propagatable from unstable to testing, which requires careful coordination. Individual packages are free to decide that they want to fork a sarge branch, but at that point they're taking the burden of maintaining that sarge branch in t-p-u upon themselves. Libraries (and other non-leaf packages) are a different story. I'd like to see apt 0.6 in unstable as soon as possible, although I'd like it even more if it were fixed to stop requiring authentication on CD-ROMs first so that we don't need to make so many d-i and debian-cd changes just to keep the installer working after it lands. :-) (I know Michael Vogt is working on this.) Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt in experimental (Re: APT 0.6 migration -- second status report)
Matt Zimmerman [EMAIL PROTECTED] writes: On Wed, May 04, 2005 at 05:41:18PM +0200, Norbert Tretkowski wrote: By the way... what about updating apt 0.6 in experimental? Matt, any plans? Ubuntu ships apt 0.6.35, but Debian still has 0.6.25. I have tried in the past to keep an updated apt in experimental, but it's non-trivial because of the dependent packages. So how is the key updating solved now if I may ask? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt in experimental (Re: APT 0.6 migration -- second status report)
On Wed, May 04, 2005 at 10:01:38PM +0200, Goswin von Brederlow wrote: Matt Zimmerman [EMAIL PROTECTED] writes: I have tried in the past to keep an updated apt in experimental, but it's non-trivial because of the dependent packages. So how is the key updating solved now if I may ask? In mainline, there is a facility for adding new keys to the keyring by updating the apt package. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release update: editorial changes to the testing propagation scripts
On Wed, May 04, 2005 at 03:05:24PM +0200, Jeroen van Wolffelaar wrote: On Wed, May 04, 2005 at 02:42:15PM +0200, Adrian Bunk wrote: Can you tell about the possible risks that may affect your release plan and what you have done to ensure that they will not delay your release plan? Can you tell me about the usefulness of whining[1] about release policy for years, and how this will not delay the release? Debian DPL candidates often talk during their election campaigns about a lack of communication in Debian. But when asking for some background of an announcement that's considered evil? --Jeroen [1] I don't use this word lightly in mail, but to be honest, your continued vendetta against the current release policy is quite annoying. Especially seen in the light of your resignation as Debian Developer, by which you abstained from any committment to help Debian constructively from the inside, this is not really a fair thing to do. As we say in the Netherlands, De beste stuurlui staan aan wal, The best boatsmen are standing on shore: it's easy to complain while not bearing any responsibility, rather than actually doing the job You are confusing cause and effect. Please look at the reasons why I resigned. I stated before my resignation, that my personal motivation went down to zero because more than one year after the start of the woody freeze, we were still far away from a freeze although I did my best in helping getting nearer to a release, there was zero visible progress [1]. This is the reason why I resigned some time later [2]. At the time when I was a Debian maintainer (maintaining 42 packages and being an active member of the QA team), there were exactly zero possibilities for an average maintainer like me to influence anything from the inside except for the more theoretical influences of starting a GR or participating in votes (which gives me at about as much influence as I have on politics in real life). If this has changed, and Debian maintainers now have more influence I'd be glad to rejoin and help Debian from the inside. You might disagree with this, but the whole sarge release cycle until now was not able to show me that the current release process was working (and even worth dropping two thirds of the Debian architectures, because as your release team announced the testing release process can't cope with a dozen architectures). cu Adrian [1] http://lists.debian.org/debian-devel/2002/01/msg00961.html [2] http://lists.debian.org/debian-devel/2002/01/msg02160.html -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Should Debian use lsb init-functions?
Thomas Hood dijo [Wed, May 04, 2005 at 12:05:19AM +0200]: I have been looking at the lsb init functions and am beginning to feel that they are a bad idea. It will be a hard time converting to them, but in the end I think it will be a net gain. * Converting to lsb init function requires modifying every initscript in Debian. * Every initscript has to read in a file containing a set of function definitions, some/most of which the initscript does not use. Yes. Inertia is hard to break - But it is often necessary. * The lsb functions don't handle all the kinds of output currently produced by initscripts. Ummm... But we currently only print the message. We can print the informative messages _and_ return a meaningful success/failure value. Further more, the base LSB functions can be extended if there is need for it. I think it would be better if we simply made rc capture initscripts' standard output (and exit status) and formatted it in such a way that bootup messages were prettier. It is not just about prettyness, but about giving more concise and useful information at a first glance - about usability. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Some packages up for adoption
Brent Fulgham has decided to give some packages away (mostly Erlang and Dylan related packages but also some others); the following mail is forwarded with permission from debian-private: * Brent Fulgham [EMAIL PROTECTED] [2004-12-30 09:44]: I find that after seven years of working on Debian (and the accumulation of two kids, another dog, a mortgage, and a new job) that I no longer have time to decently maintain my packages. The packages I need to give up are as follows: 1. DrScheme -- Popular scheme implementation used at universities around the world. This one has been adopted already by Stevie Strickland but the following are still available: 2. Erlang -- Concurrent programming language 3. erlang-doc-html -- HTML documentation for Erlang. 4. erlang-manpages -- Manpages for Erlang. 5. wings3d -- Awesome 3-D modelling software (written in Erlang) 6. libsdl-erlang -- SDL binding for Erlang. 7. gwydion-dylan -- Dynamic Language 8. gwydion-dylan-sgml -- SGML documentation package for Dylang. 9. libopengl-dylan -- OpenGL binding for Dylan. 10. libpng-dylan -- PNG binding for Dylan. In addition, the following GNUstep packages should be handled by the GNUstep packaing team: I sent a message to [EMAIL PROTECTED] about these. gnustep-antlr gnustep-dl2 gnustep-gd gnustep-netclasses pdfkit.framework renaissance steptalk -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Orphaning recover and makeztxt
John H. Robinson, IV dijo [Wed, May 04, 2005 at 10:21:37AM -0700]: John H. Robinson, IV wrote: Gunnar Wolf wrote: Hi, About makeztxt, it is a nice program to convert text files into ztxt files, apt for reading in a Palm with the (GPLed) Weasel reader. It has a simple regex engine used to create the TOCs, and works just fine. The problem is, I no longer own a Palm, so I cannot do much with it. I will happily pick this up for you. Looks like there were a few takers for this: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] I am happy to let Rolandas Juodzbalis have it. Yup, he was the first taker. I will sponsor his upload. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
On Tue, 2005-05-03 at 20:15 -0400, David Mandelberg wrote: On Tue, 2005-05-03 at 19:40 -0300, Henrique de Moraes Holschuh wrote: GNU version of OpenSSL (I don't recall how it is called). GnuTLS I think. Stupid mail misconfiguration, I sent this before I got Christian Hammer's reply (actually almost immediately after I got Henrique's message). -- The attachment signature.asc (if it exists) is a digital signature. Unless you know what that is, you can completely ignore it. It is mostly harmless and very small. You will be given a post of trust and responsibility. signature.asc Description: This is a digitally signed message part
Re: apt in experimental (Re: APT 0.6 migration -- second status report)
Matt Zimmerman [EMAIL PROTECTED] writes: On Wed, May 04, 2005 at 10:01:38PM +0200, Goswin von Brederlow wrote: Matt Zimmerman [EMAIL PROTECTED] writes: I have tried in the past to keep an updated apt in experimental, but it's non-trivial because of the dependent packages. So how is the key updating solved now if I may ask? In mainline, there is a facility for adding new keys to the keyring by updating the apt package. Which can't be done (savely) if the key is compromised or expires before the update (like it does every year). MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt in experimental (Re: APT 0.6 migration -- second status report)
On Wednesday 04 May 2005 03:05 pm, Matt Zimmerman wrote: That is, I would upload apt to experimental, along with python-apt+aptitude+synaptic+libapt-pkg-perl+etc. (versioned as NMUs). Then, new versions of these packages would be uploaded to unstable, which would supersede the versions I uploaded and cause them to be removed from experimental. aptitude forked between unstable and experimental in December. Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ | Whoever created the human body left in a fairly basic | | design flaw. It has a tendency to bend at the knees. | | -- Terry Pratchett, _Men at Arms_ | \-- Listener-supported public radio -- NPR -- http://www.npr.org ---/ pgptOVBvcdsWz.pgp Description: PGP signature
Re: apt in experimental (Re: APT 0.6 migration -- second status report)
On Wed, May 04, 2005 at 05:54:53PM -0400, Daniel Burrows wrote: On Wednesday 04 May 2005 03:05 pm, Matt Zimmerman wrote: That is, I would upload apt to experimental, along with python-apt+aptitude+synaptic+libapt-pkg-perl+etc. (versioned as NMUs). Then, new versions of these packages would be uploaded to unstable, which would supersede the versions I uploaded and cause them to be removed from experimental. aptitude forked between unstable and experimental in December. Excellent, that's one less package to worry about. I don't think that python-apt is essentially already branched as well (Michael Vogt is preparing a new upload to sync up). -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt in experimental (Re: APT 0.6 migration -- second status report)
On Wed, May 04, 2005 at 11:51:21PM +0200, Goswin von Brederlow wrote: Matt Zimmerman [EMAIL PROTECTED] writes: In mainline, there is a facility for adding new keys to the keyring by updating the apt package. Which can't be done (savely) if the key is compromised or expires before the update (like it does every year). If the key is compromised, we lose, no matter what we do. I recommend that we create keys which will not expire before the next release. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
hi I happen to mantain 'snmpkit' ; you may give it a look a. Christian Hammers wrote: Hello [regarding #306840 and with more info in #243870] One of my packages, Quagga, is licenced under the GPL but is supposed to get linked against NetSNMP. That now is problematic, as NetSNMP depends on OpenSSL (for SNMPv3 crypto support?) which is not GPL compatible. Does anybody know a good and easy to replace GPL-compatible SNMP library that provides SNMP MUX capatiblities for C applications? Or would it be possible to fork NetSNMP into a libsnmp5-gpl-dev package? bye, -christian- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some packages up for adoption
On May 4, 2005 05:29 pm, Martin Michlmayr wrote: 2. Erlang -- Concurrent programming language 3. erlang-doc-html -- HTML documentation for Erlang. 4. erlang-manpages -- Manpages for Erlang. Oh Oh! I want those. I'm not a DD (yet) though are they much work to maintain? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt in experimental (Re: APT 0.6 migration -- second status report)
On Wed, May 04, 2005 at 03:08:42PM -0700, Matt Zimmerman wrote: Which can't be done (savely) if the key is compromised or expires before the update (like it does every year). If the key is compromised, we lose, no matter what we do. I recommend that we create keys which will not expire before the next release. istr discussing (or at least thinking to myself) a method of rolling keys, where one key was used to sign another key, which would then ideally be kept somewhere Safe for the case of unexpected expiration. this second key could then be used to sign a third key, and so-forth. i guess this wouldn't handle upgrades of apt that skipped a key epoch, but that could probably be worked around by keeping the old keys around somewhere so that they could be used to somehow establish a chain of trust to the newest key. in the case of a compromise you'd still need an extra verification; because you'd have to assume that the compromised key could have been used by the mean people to sign phony keys. that could pretty easily be accomplished by attaching another d-d's signature to it when it was generated, right? if the key was really kept somewhere Safe, there would be no risk of the first key's compromise affecting it. sean -- signature.asc Description: Digital signature
Re: apt in experimental (Re: APT 0.6 migration -- second status report)
On Wed, May 04, 2005 at 06:26:30PM -0400, sean finney wrote: istr discussing (or at least thinking to myself) a method of rolling keys, where one key was used to sign another key, which would then ideally be kept somewhere Safe for the case of unexpected expiration. this second key could then be used to sign a third key, and so-forth. i guess this wouldn't handle upgrades of apt that skipped a key epoch, but that could probably be worked around by keeping the old keys around somewhere so that they could be used to somehow establish a chain of trust to the newest key. in the case of a compromise you'd still need an extra verification; because you'd have to assume that the compromised key could have been used by the mean people to sign phony keys. that could pretty easily be accomplished by attaching another d-d's signature to it when it was generated, right? if the key was really kept somewhere Safe, there would be no risk of the first key's compromise affecting it. If you have some code which implements this, I will take a look, but this sort of thing is very awkward to do with gpg, and I don't think that there is much justification for this level of complexity. The existing scheme is simple, and works. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt in experimental (Re: APT 0.6 migration -- second status report)
On Wed, May 04, 2005 at 03:33:37PM -0700, Matt Zimmerman wrote: If you have some code which implements this, I will take a look, but this sort of thing is very awkward to do with gpg, and I don't think that there is much justification for this level of complexity. The existing scheme is simple, and works. /me pretends to search through his pockets nope, no code :) i guess it all depends on how important it is to have seamless key transitions. maybe just informing the admin that the key has changed and pointing them to instructions for how they can verify its authenticity is a better approach in that case. sean -- signature.asc Description: Digital signature
Re: apt in experimental (Re: APT 0.6 migration -- second status report)
Matt Zimmerman [EMAIL PROTECTED] writes: On Wed, May 04, 2005 at 11:51:21PM +0200, Goswin von Brederlow wrote: Matt Zimmerman [EMAIL PROTECTED] writes: In mainline, there is a facility for adding new keys to the keyring by updating the apt package. Which can't be done (savely) if the key is compromised or expires before the update (like it does every year). If the key is compromised, we lose, no matter what we do. I recommend that we create keys which will not expire before the next release. -- - mdz How about this: Each distribution key gets signed by X+Y DDs in the current (stable) keyring. On key updates the new key is checked and if X of those signatures are still valid and the key is newer than the existing one then the key is accepted as new key. Keeping X reasonably large ensures that a compromised key (or two or three) can't be used to smuggle in an fake archive key. Keeping Y large ensures a new key can still be checked and accepted. The timestamp of the key and signatures should be checked to prevent undoing a key update by rolling in an old, compromised key. All of this should be wrapped in something like apt-get update-keys and mentioned in the error message when Release.gpg fails the check. Or, even better, have apt-get update download a Release.keys and verify through the above procedure automatically. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Should Debian use lsb init-functions?
On Wednesday 04 May 2005 23:21, Gunnar Wolf wrote:
Thomas Hood dijo [Wed, May 04, 2005 at 12:05:19AM +0200]:
I have been looking at the lsb init functions and am beginning to feel
that they are a bad idea.
It will be a hard time converting to them, but in the end I think it
will be a net gain.
* Converting to lsb init function requires modifying every initscript in
Debian.
* Every initscript has to read in a file containing a set of function
definitions, some/most of which the initscript does not use.
Yes. Inertia is hard to break - But it is often necessary.
Optimize the easy case: For daemons which interact nicely with s-s-d, a init
script should look like this:
---
#!/bin/bash
NAME=exampled
DAEMON=/usr/sbin/exampled
MESSAGE=Starting the ExampleD
FLAGS=-default
. /lib/handle_init
---
Where /lib/handle_init can handle /etc/default/$NAME files, pidfile handling
(/var/run/$NAME.pid), s-s-d calls and much more.
Do you need more flexibility? Think about
{pre,post}-{{re,}start,stop,reload,status} functions.
lsb output? rewrite handle_init.
lin{da,tian} checkability? quite easy.
bootlogging? handle_init just has to properly redirect all output.
debconf-interfaces interactive startup? rewrite handle_init.
Debug output if -n $PS1?
non-sh init scripts? convert handle_init into a binary to be called, which can
handle /etc/$NAME/init.d/{pre,post}-{{re,}start,stop,{force-,}reload,status}
Regards, David
--
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
-- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
debian sarge is 3.2 or 4 ?
hi everybody now that sarge is frozen, I would like to start a discussion on the number to associate to Sarge release. According to http://www.nl.debian.org/releases/sarge/index.en.html Sarge may be released as Debian 3.1 In 2003, Scott James Remnant proposed in http://lists.debian.org/debian-devel/2003/01/msg00337.html that Sarge should be Debian 4; some (most?) people did agree. But some other people refer to sarge as Debian 3.1 (or 3.2) Considering that woody was released 19 Jul 2002, it took us ~3 years to release; in the meantime, all most important components changed completely; and we did a lot of work in Sarge, that I do not want to see numerically represented as sarge = woody + 0.1 So I would much prefer if sarge would be called Debian 4 Do you agree? a. (ps: I apologize if this has been discussed recently... I googled around, but did not find any recent reference) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian sarge is 3.2 or 4 ?
On Thursday 05 May 2005 01:17, Andrea Mennucc wrote: [ ... ] Considering that woody was released 19 Jul 2002, it took us ~3 years to release; in the meantime, all most important components changed completely; and we did a lot of work in Sarge, that I do not want to see numerically represented as sarge = woody + 0.1 So I would much prefer if sarge would be called Debian 4 Do you agree? Well, it doesn't really matter to me personally, but am I correct that the changes from Woody to Sarge have been at least as big as they were from Potato to Woody (where the version number was bumped from 2.2 - 3.0)? If yes, and with that in mind, it could probably be justified that Sarge ships as 4.0, I guess. -- Frederik Dannemare | http://sentinel.dk | http://linuxworlddomination.dk http://qa.debian.org/developer.php?login=Frederik+Dannemare http://www.ubuntulinux.org/wiki/FrederikDannemare Key fingerprint = 30CF 7AD3 17D9 1A63 A730 ECA6 0D4C 2C97 9D9A 238E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian sarge is 3.2 or 4 ?
Andrea Mennucc wrote: now that sarge is frozen, I would like to start a discussion on the number to associate to Sarge release. Now that sarge is frozen we have /etc/debian_version, the installation manual, the release notes, and the website all containing the version number 3.1. I've probably forgotten a few other things. Updating all these things to change a version number kinda misses the point of a freeze, doesn't it? -- see shy jo, who argued for 4.0 at the appropriate time to discuss the version number to use signature.asc Description: Digital signature
Re: Orphaning Crossfire
On Wed, May 04, 2005 at 01:51:28AM +0300, Jaakko Niemi wrote: Hello, crossfire-* is available for grabs. Upstream is active and helpful. No big issues, just needs some basic work. Any takers? I can take this. I'm not a DD (yet), so I'll need a sponsor too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu and its appropriation of Debian maintainers
quote who=Matt Zimmerman date=2005-05-02 15:06:10 -0700 Another option would be to leave the source package maintainer the same (to retain proper credit, etc.), but override the binary package maintainer during the build (to reflect that it is a different build, and also display a more appropriate name in apt-cache show etc.). What do you think about this approach? FWIW, I think this would be an ideal solution. I think it's worth pointing out that up until this thread, the only complaints we've gotten in terms of attribution and Debian packages are about the *lack* of attribution from patches pulled from Debian. This seems to be a little bit of a damned if you do, damned if you don't situation. :) Hopefully we've figured this one out. And while it is nice to know that this bothers other DDs, this probably could have been handled by mailing the Ubuntu or Launchpad developers. The information on Launchpad was, after all, not going to be giving everyone who saw it the right information and it was probably best classified as a bug in a very young piece of software. Like Matt, I'm happy to act as a point of contact for this sort of thing in the future. Regards, Mako -- Benjamin Mako Hill [EMAIL PROTECTED] http://mako.yukidoke.org/ signature.asc Description: Digital signature
www.debian.org and users information
Hi DD folks, Sarge is now approaching zero kelvin and folks are scrambing to get the last few bugs squashed. I was recently thinking about why the non-clued folks bash Debian with incomplete or inaccurate facts and a way to address that. I think there should be a section on the main page that contains links to cluefull faq to clear the FUD and to shed light on these issues. Here is a short list of some things that I would include on the front page: * what's the difference between stable, testing and unstable and who should use them * Why was past releases took so long and how these issues are being addressed * the plan for the next Debian release: etch * What are the FAQs about Xorg in debian * a guide to the new debian installer * the faqs about CDD (custom debian distributions) * Important Debian news: Sarge is frozen -- what it means to new and current users Upgrade notes for woody users * a guide to sidegrading rpm based distro to Debian * What is Ubuntu and how does it relate to Debian * What is Knoppix and how does it relate to Debian * What is Mephis and how does it relate to Debian * SATA FAQs * the future of documentation that is under the GFDL in Debian * the future of binary firmware in Debian * Ways to install Debian My reasoning is that while some of there are addressed somewhere on the website, people tend to be lazy. We should put this info front and center so a quick look will immediately lead them to good informed facts. -- counter.li.org #238656 -- goto counter.li.org and be counted! `$' $' $ $ _ ,d$$$g$ ,d$$$b. $,d$$$b`$' g$b $,d$$b ,$P' `$ ,$P' `Y$ $$' `$ $ ' `$ $$' `$ $$ $ $$g$ $ $ $ ,$P $ $$ `$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$ `Y$$P'$. `YP $$$P' ,$. `Y$$P'$ $. ,$. signature.asc Description: Digital signature
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
[Paul TBBle Hampson] This of course assumes the phrase derived work is legalese for code dependancy or something. I'm sure the GPL actually defines what _they_ mean by it... One false assumption and one false premise. Derived work is legalese for this work is based, at least in part, on this other work. Roughly, if it were not credited, this would be considered plagiarism. Nothing to do with code dependencies in particular. Now, the false premise is that it *matters* what the GPL means by derived work. The GPL is a copyright license, so what actually matters is what copyright law defines as a derived work. For works that are (legally speaking) not derived from a GPL-licensed original, the GPL has no jurisdiction, no matter what it, or the author of your program, or the Free Software Foundation might say. I might add that claiming a program that uses a library's published API is a derived work is a bit shaky from the get-go. If you actually cut and paste code from the library into your program, it's a lot more clear-cut. signature.asc Description: Digital signature
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
[This part of the thread belongs on -legal] On Wed, May 04, 2005 at 11:51:51PM -0500, Peter Samuelson wrote: [Paul TBBle Hampson] This of course assumes the phrase derived work is legalese for code dependancy or something. I'm sure the GPL actually defines what _they_ mean by it... The GPL simply defers to copyright law to define derivative work. I might add that claiming a program that uses a library's published API is a derived work is a bit shaky from the get-go. If you actually cut and paste code from the library into your program, it's a lot more clear-cut. We talk about APIs on forums like -legal to save time, because everybody (supposedly) knows what we're talking about there. They aren't directly relevant, it's just that certain aspects of program design will normally have certain legal implications because that's how those things are normally implemented. Changing static linking to dynamic, or replacing a linker call with a dlopen() call, *always* has precisely *zero* effect on whether something is a derivative work or not. A work is created derivative, or not, at the time of inception. For source code, this is the time when the code is written. The way in which it is compiled is irrelevant. For a binary, this is the time when the binary is built and linked. A statically linked binary is a derivative work of everything it links because it contains verbatim copies of those things. Every binary, static, dynamic, or other, is a derivative of everything that any part of its source was derived from. A good rule of thumb for whether one piece of source code is a derivative of another is Will it function in a reasonable manner without this other piece?. Thusly a telnet client is not a derivative of the socksified tcp library you stuff in with LD_PRELOAD, but the part which sets up ssl connections is a derivative of the ssl library you use. This is a rule of thumb because it fails in pathological cases; don't abuse it. [There are many other, more complicated cases. Consult -legal for consideration of specific examples.] -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Accepted libunwind 0.98.5-6 (source ia64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 4 May 2005 07:22:10 +0200 Source: libunwind Binary: libunwind-setjmp0-dev libunwind7 libunwind-setjmp0 libunwind7-dev Architecture: source ia64 Version: 0.98.5-6 Distribution: experimental Urgency: low Maintainer: Matthieu Delahaye [EMAIL PROTECTED] Changed-By: Matthias Klose [EMAIL PROTECTED] Description: libunwind-setjmp0 - A libunwind-based non local goto - runtime libunwind-setjmp0-dev - A libunwind-based non local goto - development libunwind7 - A library to determine the call-chain of a program - runtime libunwind7-dev - A library to determine the call-chain of a program - development Changes: libunwind (0.98.5-6) experimental; urgency=low . * Fix libunwind7 shlibs version string. Files: 20ddd1e55275fb3635898461d0e11e55 756 - optional libunwind_0.98.5-6.dsc 2da22bf5853fcd07820994716c905c81 26557 - optional libunwind_0.98.5-6.diff.gz 674f163bb744897d39979d495b13ddd2 192288 libdevel optional libunwind7-dev_0.98.5-6_ia64.deb adcf6f73e8b1986ac0a6dd1bd31e1784 105446 libs optional libunwind7_0.98.5-6_ia64.deb c14629dd10e71eb074e7c0aeb761ab28 8478 libdevel optional libunwind-setjmp0-dev_0.98.5-6_ia64.deb d5bc7c20179893f54235144300789444 7228 libs optional libunwind-setjmp0_0.98.5-6_ia64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCeF6KStlRaw+TLJwRAstVAKCElqI3oxFEqEFZftLUjsGz9qIx4ACguOko P+14tC/sG8sp6VauwHgrhuA= =dYIF -END PGP SIGNATURE- Accepted: libunwind-setjmp0-dev_0.98.5-6_ia64.deb to pool/main/libu/libunwind/libunwind-setjmp0-dev_0.98.5-6_ia64.deb libunwind-setjmp0_0.98.5-6_ia64.deb to pool/main/libu/libunwind/libunwind-setjmp0_0.98.5-6_ia64.deb libunwind7-dev_0.98.5-6_ia64.deb to pool/main/libu/libunwind/libunwind7-dev_0.98.5-6_ia64.deb libunwind7_0.98.5-6_ia64.deb to pool/main/libu/libunwind/libunwind7_0.98.5-6_ia64.deb libunwind_0.98.5-6.diff.gz to pool/main/libu/libunwind/libunwind_0.98.5-6.diff.gz libunwind_0.98.5-6.dsc to pool/main/libu/libunwind/libunwind_0.98.5-6.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted hibernate 1.07-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 May 2005 22:39:02 +0800 Source: hibernate Binary: hibernate Architecture: source all Version: 1.07-1 Distribution: unstable Urgency: low Maintainer: Cameron Patrick [EMAIL PROTECTED] Changed-By: Cameron Patrick [EMAIL PROTECTED] Description: hibernate - activates your computer's suspend functionality Closes: 297130 298391 299901 300445 302177 Changes: hibernate (1.07-1) unstable; urgency=low . * New upstream release. * Check for /var/run/suspend2-new-kernel to prevent people losing data by accidentally suspending with an old kernel and resuming with a newer kernel (closes: #298391). * Provides an Include directive for reading other files within hibernate.conf (closes: #299901). * More robust grub scriptlet (closes: #300445). * Updated module blacklist, including correct module names and buggy kernel version ranges for VIA chipset drivers (closes: #302177). * Package description more accurately describes the supported suspend methods (closes: #297130). * Updated Uploaders field to include Martin Krafft. * Don't install the modules_gentoo scriptlet, as it isn't relevant on a Debian system. * Add a README.Debian file documenting where to get software suspend patches. * Install the example ram.conf configuration file. Files: 68227ae3dc7db8d604075bab3811b6e5 637 utils extra hibernate_1.07-1.dsc 0ceb0ec40065cdcf07a6c0ed51de95ac 59644 utils extra hibernate_1.07.orig.tar.gz 688639028537069ec188d110c84da538 5880 utils extra hibernate_1.07-1.diff.gz dde08e1cc8c495a9c0f7da14e24f1437 63140 utils extra hibernate_1.07-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iEYEARECAAYFAkJ2RRUACgkQIgvIgzMMSnWnCgCdFaikmVmrmsuP7Zf0O9vqeYnx f8wAn3WXNgg99HgvihAgCdaXxl0sy31P =1Scu -END PGP SIGNATURE- Accepted: hibernate_1.07-1.diff.gz to pool/main/h/hibernate/hibernate_1.07-1.diff.gz hibernate_1.07-1.dsc to pool/main/h/hibernate/hibernate_1.07-1.dsc hibernate_1.07-1_all.deb to pool/main/h/hibernate/hibernate_1.07-1_all.deb hibernate_1.07.orig.tar.gz to pool/main/h/hibernate/hibernate_1.07.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python2.3 2.3.5-3 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 4 May 2005 08:20:22 +0200 Source: python2.3 Binary: python2.3-doc idle-python2.3 python2.3-dev python2.3-examples python2.3-mpz python2.3 python2.3-gdbm python2.3-tk Architecture: source all i386 Version: 2.3.5-3 Distribution: unstable Urgency: high Maintainer: Matthias Klose [EMAIL PROTECTED] Changed-By: Matthias Klose [EMAIL PROTECTED] Description: idle-python2.3 - An IDE for Python (v2.3) using Tkinter python2.3 - An interactive high-level object-oriented language (version 2.3) python2.3-dev - Header files and a static library for Python (v2.3) python2.3-doc - Documentation for the high-level object-oriented language Python python2.3-examples - Examples for the Python language (v2.3) python2.3-gdbm - GNU dbm database support for Python (v2.3) python2.3-mpz - Multiple-precision arithmetic support for Python (v2.3) python2.3-tk - Tkinter - Writing Tk applications with Python (v2.3) Closes: 291162 307128 Changes: python2.3 (2.3.5-3) unstable; urgency=high . * Use db-4.2 to build the dbm extension module. * Move documents in info format in one section (closes: #291162). * Remove ancient debian/TODO (closes: #307128). Files: 02390a58f05e44f0977b3a1ab2dced31 1134 python optional python2.3_2.3.5-3.dsc 4809146fea2d455ada12f13e1c5d18dd 2350459 python optional python2.3_2.3.5-3.diff.gz 216f91ce94dca28e11731b47f1950d8f 512746 python optional python2.3-examples_2.3.5-3_all.deb 80c43a9947430f196e18acc5c8e9b98f 233786 python optional idle-python2.3_2.3.5-3_all.deb e616e593124eabeb28153898c7a283d0 2859490 doc optional python2.3-doc_2.3.5-3_all.deb bcb1dca08993fb903205048d88174bb0 2905334 python standard python2.3_2.3.5-3_i386.deb b726db05f059d664982a7362dcb6bd4a 107558 python optional python2.3-tk_2.3.5-3_i386.deb 0fde830ff55b5bb48a535dd81d19f235 26586 python optional python2.3-gdbm_2.3.5-3_i386.deb 58768d0ec3c3c7e4f2810a8d4317a284 30602 python optional python2.3-mpz_2.3.5-3_i386.deb cf0708276010f9f7669e01999276607d 1481274 libdevel optional python2.3-dev_2.3.5-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCeHWlStlRaw+TLJwRAlAFAJ4kUNnP2WwbdiEVZxPbz3IpLecElQCgtIWT UXmJAkZUGUu5nse8fD/1qjM= =8h3y -END PGP SIGNATURE- Accepted: idle-python2.3_2.3.5-3_all.deb to pool/main/p/python2.3/idle-python2.3_2.3.5-3_all.deb python2.3-dev_2.3.5-3_i386.deb to pool/main/p/python2.3/python2.3-dev_2.3.5-3_i386.deb python2.3-doc_2.3.5-3_all.deb to pool/main/p/python2.3/python2.3-doc_2.3.5-3_all.deb python2.3-examples_2.3.5-3_all.deb to pool/main/p/python2.3/python2.3-examples_2.3.5-3_all.deb python2.3-gdbm_2.3.5-3_i386.deb to pool/main/p/python2.3/python2.3-gdbm_2.3.5-3_i386.deb python2.3-mpz_2.3.5-3_i386.deb to pool/main/p/python2.3/python2.3-mpz_2.3.5-3_i386.deb python2.3-tk_2.3.5-3_i386.deb to pool/main/p/python2.3/python2.3-tk_2.3.5-3_i386.deb python2.3_2.3.5-3.diff.gz to pool/main/p/python2.3/python2.3_2.3.5-3.diff.gz python2.3_2.3.5-3.dsc to pool/main/p/python2.3/python2.3_2.3.5-3.dsc python2.3_2.3.5-3_i386.deb to pool/main/p/python2.3/python2.3_2.3.5-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted bzip2 1.0.2-6 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 04 May 2005 17:13:20 +1000 Source: bzip2 Binary: libbz2-1.0 bzip2 libbz2-dev Architecture: source i386 Version: 1.0.2-6 Distribution: unstable Urgency: high Maintainer: Anibal Monsalve Salazar [EMAIL PROTECTED] Changed-By: Anibal Monsalve Salazar [EMAIL PROTECTED] Description: bzip2 - high-quality block-sorting file compressor - utilities libbz2-1.0 - high-quality block-sorting file compressor library - runtime libbz2-dev - high-quality block-sorting file compressor library - development Closes: 303300 Changes: bzip2 (1.0.2-6) unstable; urgency=high . * Fixed RC bug file permissions modification race (CAN-2005-0953), closes: #303300. Patch by Santiago Ruano Rincon [EMAIL PROTECTED]. Original patch available at http://marc.theaimsgroup.com/?l=bugtraqm=111352423504277w=2 Files: a74d3720114343270551736341bd40e0 577 utils standard bzip2_1.0.2-6.dsc 64713d0abd18a046cf5574c359cf92ae 13388 utils standard bzip2_1.0.2-6.diff.gz 78d10de9df81a254a6b5d568a094f2ad 38478 libs standard libbz2-1.0_1.0.2-6_i386.deb cab75a9f8e336237dc9253aac64ccc88 30232 libdevel optional libbz2-dev_1.0.2-6_i386.deb ee9afe41875f2ed2e82eccd8de98efd4 233228 utils optional bzip2_1.0.2-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCeH4agY5NIXPNpFURAtqPAJ9izEld47sqGGtfdo5cr5p5AgX1SgCePbIT qM4bqXq6c+Jo4LWzgXJr2zo= =sj0G -END PGP SIGNATURE- Accepted: bzip2_1.0.2-6.diff.gz to pool/main/b/bzip2/bzip2_1.0.2-6.diff.gz bzip2_1.0.2-6.dsc to pool/main/b/bzip2/bzip2_1.0.2-6.dsc bzip2_1.0.2-6_i386.deb to pool/main/b/bzip2/bzip2_1.0.2-6_i386.deb libbz2-1.0_1.0.2-6_i386.deb to pool/main/b/bzip2/libbz2-1.0_1.0.2-6_i386.deb libbz2-dev_1.0.2-6_i386.deb to pool/main/b/bzip2/libbz2-dev_1.0.2-6_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted firehol 1.231-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 27 Jul 2006 15:20:26 +0200 Source: firehol Binary: firehol Architecture: source all Version: 1.231-2 Distribution: unstable Urgency: medium Maintainer: Alexander Wirt [EMAIL PROTECTED] Changed-By: Alexander Wirt [EMAIL PROTECTED] Description: firehol- An easy to use but powerful iptables stateful firewall Closes: 304853 Changes: firehol (1.231-2) unstable; urgency=medium . * Create lockfile while starting firehol (Closes: #304853) Files: 5edbb352b87b7005d23df6c721fb54ed 578 net optional firehol_1.231-2.dsc cfa5cd397b9d2087fe48614a082ded75 8138 net optional firehol_1.231-2.diff.gz d53994735e73d0506f98e09859f8088a 160202 net optional firehol_1.231-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCeIS101u8mbx9AgoRAvy6AKDas3xePNcgPLj/50JET8Lp13zd+wCgihF7 TwTbSGaVXzVyIS5NFD6NW3U= =EWak -END PGP SIGNATURE- Accepted: firehol_1.231-2.diff.gz to pool/main/f/firehol/firehol_1.231-2.diff.gz firehol_1.231-2.dsc to pool/main/f/firehol/firehol_1.231-2.dsc firehol_1.231-2_all.deb to pool/main/f/firehol/firehol_1.231-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted rivet 0.5.0-3 (powerpc source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 4 May 2005 10:13:50 +0200 Source: rivet Binary: rivet Architecture: source powerpc Version: 0.5.0-3 Distribution: unstable Urgency: low Maintainer: David N. Welton [EMAIL PROTECTED] Changed-By: David N. Welton [EMAIL PROTECTED] Description: rivet - Server-side Tcl programming system combining ease of use and powe Closes: 307339 Changes: rivet (0.5.0-3) unstable; urgency=low . * Bug fix: rivet: 64-bit compile warnings, thanks to dann frazier (Closes: #307339). Files: fba92a4ebb503625bd72849ff74aed8d 523 web optional rivet_0.5.0-3.dsc f349b157968bbf7ad1f2b949b5ee9c83 881755 web optional rivet_0.5.0-3.tar.gz c0f8a0a700602aeaae927b79caf14251 446446 web optional rivet_0.5.0-3_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCeIURAVLWA9/qxLkRAti/AKCoRowInq684s4/5aY6T+4fEaDTgQCg7+X7 HA7hUKrsPCQr39E2RssbB70= =RQYh -END PGP SIGNATURE- Accepted: rivet_0.5.0-3.dsc to pool/main/r/rivet/rivet_0.5.0-3.dsc rivet_0.5.0-3.tar.gz to pool/main/r/rivet/rivet_0.5.0-3.tar.gz rivet_0.5.0-3_powerpc.deb to pool/main/r/rivet/rivet_0.5.0-3_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ipsec-tools 1:0.5.2-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 4 May 2005 13:46:45 +0530 Source: ipsec-tools Binary: racoon ipsec-tools Architecture: source i386 Version: 1:0.5.2-1 Distribution: unstable Urgency: high Maintainer: Ganesan Rajagopal [EMAIL PROTECTED] Changed-By: Ganesan Rajagopal [EMAIL PROTECTED] Description: ipsec-tools - IPsec tools for Linux racoon - IPsec IKE keying daemon Closes: 307233 Changes: ipsec-tools (1:0.5.2-1) unstable; urgency=high . * New upstream release. This release fixes ph2handle unlink bug (closes: #307233). * Urgency high because of fix for security problem with single DES. * Applied patch from Richard Lucassen to pass options to racoon via /etc/default/racoon file. Files: 932cffdc5b24dfee5a90e45de7f170bb 673 net extra ipsec-tools_0.5.2-1.dsc 50dccd981710182c8cf8783b0df2 887818 net extra ipsec-tools_0.5.2.orig.tar.gz 7f30453b6f722af4b785bd09b03c9406 43120 net extra ipsec-tools_0.5.2-1.diff.gz 88083a309a571909102fdb31c20fe62c 77878 net extra ipsec-tools_0.5.2-1_i386.deb 8f77d478432b418dd8e322dd93303866 290744 net extra racoon_0.5.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCeIj5FeACul2MEuoRAleqAKDRK9HgpC+0l+csZ9VSd2Aj5WRN1ACg0cbC oaiM3PA/pMP7I/lXc2HPh9I= =xUa5 -END PGP SIGNATURE- Accepted: ipsec-tools_0.5.2-1.diff.gz to pool/main/i/ipsec-tools/ipsec-tools_0.5.2-1.diff.gz ipsec-tools_0.5.2-1.dsc to pool/main/i/ipsec-tools/ipsec-tools_0.5.2-1.dsc ipsec-tools_0.5.2-1_i386.deb to pool/main/i/ipsec-tools/ipsec-tools_0.5.2-1_i386.deb ipsec-tools_0.5.2.orig.tar.gz to pool/main/i/ipsec-tools/ipsec-tools_0.5.2.orig.tar.gz racoon_0.5.2-1_i386.deb to pool/main/i/ipsec-tools/racoon_0.5.2-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sipsak 0.8.12-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 4 May 2005 17:44:08 +0900 Source: sipsak Binary: sipsak Architecture: source i386 Version: 0.8.12-1 Distribution: unstable Urgency: low Maintainer: ARAKI Yasuhiro [EMAIL PROTECTED] Changed-By: araki yasuhiro [EMAIL PROTECTED] Description: sipsak - SIP Swiss army knife Changes: sipsak (0.8.12-1) unstable; urgency=low . * New upstream release Files: 847c301765826416312eaa915596d8cf 557 net optional sipsak_0.8.12-1.dsc 9740451fd72b5c7e6d85aa516ba5c19c 140783 net optional sipsak_0.8.12.orig.tar.gz db5c87576054adcc5fce0b2814923d0b 6300 net optional sipsak_0.8.12-1.diff.gz 92cc1595091f3ed5dd555683bac4ce9f 35646 net optional sipsak_0.8.12-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCeIw0NOYipi+po4wRAt+8AJ0SdfJt1Dlo0jEFkVZeKQ98jVz6SwCeM1FV Ln64Mw+1RBwaTNSVeADFE+w= =HTH4 -END PGP SIGNATURE- Accepted: sipsak_0.8.12-1.diff.gz to pool/main/s/sipsak/sipsak_0.8.12-1.diff.gz sipsak_0.8.12-1.dsc to pool/main/s/sipsak/sipsak_0.8.12-1.dsc sipsak_0.8.12-1_i386.deb to pool/main/s/sipsak/sipsak_0.8.12-1_i386.deb sipsak_0.8.12.orig.tar.gz to pool/main/s/sipsak/sipsak_0.8.12.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python2.2 2.2.3dfsg-2 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 4 May 2005 09:14:15 +0200 Source: python2.2 Binary: python2.2-doc python2.2-xmlbase python2.2-examples python2.2-dev python2.2-tk python2.2 python2.2-gdbm python2.2-mpz idle-python2.2 Architecture: source i386 all Version: 2.2.3dfsg-2 Distribution: unstable Urgency: high Maintainer: Matthias Klose [EMAIL PROTECTED] Changed-By: Matthias Klose [EMAIL PROTECTED] Description: idle-python2.2 - An IDE for Python (v2.2) using Tkinter python2.2 - An interactive high-level object-oriented language (version 2.2) python2.2-dev - Header files and a static library for Python (v2.2) python2.2-doc - Documentation for the high-level object-oriented language Python python2.2-examples - Examples for the Python language (v2.2) python2.2-gdbm - GNU dbm database support for Python (v2.2) python2.2-mpz - Multiple-precision arithmetic support for Python (v2.2) python2.2-tk - Tkinter - Writing Tk applications with Python (v2.2) python2.2-xmlbase - XML support included in Python (v2.2) Closes: 307094 Changes: python2.2 (2.2.3dfsg-2) unstable; urgency=high . * Use db-4.2 to build the dbm extension module. * Remove cthreads detection on hurd-i386 (closes: #307094). * Move documents in info format in one section. * Remove ancient debian/TODO. Files: 5dced303eaaf447dac99c92427c5bf7e 1176 python optional python2.2_2.2.3dfsg-2.dsc ddbf2a9496c8d4aa8ee229992018386d 1962094 python optional python2.2_2.2.3dfsg-2.diff.gz 580b5d17faa585d62040092b863f2a33 482878 python optional python2.2-examples_2.2.3dfsg-2_all.deb 5190147e86f95900d264213247682345 118298 python optional idle-python2.2_2.2.3dfsg-2_all.deb 95d0aeb56df26162b1b0030592362215 2303664 doc optional python2.2-doc_2.2.3dfsg-2_all.deb 4e8be91f1a99d26ad4335c803f510654 2274268 python optional python2.2_2.2.3dfsg-2_i386.deb 61b6e59b684cd3e882cb951c0ceffa18 97950 python optional python2.2-tk_2.2.3dfsg-2_i386.deb 79bfb1581fc5a83049906deb1ee860f0 57002 python optional python2.2-xmlbase_2.2.3dfsg-2_i386.deb fd7e64c72497d78e553aed199ab850a1 23708 python optional python2.2-gdbm_2.2.3dfsg-2_i386.deb f1071283f8f5bf43f4f782b712a148b0 27600 python optional python2.2-mpz_2.2.3dfsg-2_i386.deb 61e860ff73b6523d983a32505dfd289c 1156312 python optional python2.2-dev_2.2.3dfsg-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCeInZStlRaw+TLJwRAvkEAJ4lnVEc9KQXbOPJe15D0BHwngTcOQCfb6K2 7ULsLwLD/oJmaOm3D/EWQG8= =PVXw -END PGP SIGNATURE- Accepted: idle-python2.2_2.2.3dfsg-2_all.deb to pool/main/p/python2.2/idle-python2.2_2.2.3dfsg-2_all.deb python2.2-dev_2.2.3dfsg-2_i386.deb to pool/main/p/python2.2/python2.2-dev_2.2.3dfsg-2_i386.deb python2.2-doc_2.2.3dfsg-2_all.deb to pool/main/p/python2.2/python2.2-doc_2.2.3dfsg-2_all.deb python2.2-examples_2.2.3dfsg-2_all.deb to pool/main/p/python2.2/python2.2-examples_2.2.3dfsg-2_all.deb python2.2-gdbm_2.2.3dfsg-2_i386.deb to pool/main/p/python2.2/python2.2-gdbm_2.2.3dfsg-2_i386.deb python2.2-mpz_2.2.3dfsg-2_i386.deb to pool/main/p/python2.2/python2.2-mpz_2.2.3dfsg-2_i386.deb python2.2-tk_2.2.3dfsg-2_i386.deb to pool/main/p/python2.2/python2.2-tk_2.2.3dfsg-2_i386.deb python2.2-xmlbase_2.2.3dfsg-2_i386.deb to pool/main/p/python2.2/python2.2-xmlbase_2.2.3dfsg-2_i386.deb python2.2_2.2.3dfsg-2.diff.gz to pool/main/p/python2.2/python2.2_2.2.3dfsg-2.diff.gz python2.2_2.2.3dfsg-2.dsc to pool/main/p/python2.2/python2.2_2.2.3dfsg-2.dsc python2.2_2.2.3dfsg-2_i386.deb to pool/main/p/python2.2/python2.2_2.2.3dfsg-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted postgresql-7.4 1:7.4.7-5 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 19 Apr 2005 21:24:21 +1000 Source: postgresql-7.4 Binary: postgresql-plpython-7.4 postgresql-client-7.4 postgresql-7.4 postgresql-contrib-7.4 libpq3 postgresql-doc-7.4 postgresql-plperl-7.4 postgresql-pltcl-7.4 Architecture: source i386 all Version: 1:7.4.7-5 Distribution: experimental Urgency: low Maintainer: Martin Pitt [EMAIL PROTECTED] Changed-By: Martin Pitt [EMAIL PROTECTED] Description: libpq3 - PostgreSQL C client library postgresql-7.4 - object-relational SQL database, version 7.4 server postgresql-client-7.4 - front-end programs for PostgreSQL 7.4 postgresql-contrib-7.4 - additional facilities for PostgreSQL postgresql-doc-7.4 - documentation for the PostgreSQL database management system postgresql-plperl-7.4 - PL/Perl procedural language for PostgreSQL 7.4 postgresql-plpython-7.4 - PL/Python procedural language for PostgreSQL 7.4 postgresql-pltcl-7.4 - PL/TCL procedural language for PostgreSQL 7.4 Changes: postgresql-7.4 (1:7.4.7-5) experimental; urgency=low . * Ship reindexdb in -contrib. * Added debian/patches/14_pager.patch: Use /usr/bin/pager instead of more as default pager in psql. (Bug #304459) * Added debian/postgresql-doc-7.4.doc-base: Register doc package in doc-base. Files: ace08659a9f45a0f191f77be68ef8c17 991 misc optional postgresql-7.4_7.4.7-5.dsc 459712c7c87bfbcc59aee7d2a41487ca 20817 misc optional postgresql-7.4_7.4.7-5.diff.gz 804158cff1ee8f17d2b15d34af4c308d 5584 doc optional postgresql-doc-7.4_7.4.7-5_all.deb a9d6db30843dd8a3ca7a0e80c78ec30f 2634484 misc optional postgresql-7.4_7.4.7-5_i386.deb 3e19b4cce48cb7ba9489100d146a4884 442460 misc optional postgresql-client-7.4_7.4.7-5_i386.deb f1290cb2105396410aaa96a624906eaa 57264 libs optional libpq3_7.4.7-5_i386.deb 6e5128922d3e8ba8fdd318178db1db3c 333164 misc optional postgresql-contrib-7.4_7.4.7-5_i386.deb 71baf7f88bbaec4f79b8bacae3d6cc73 18400 misc optional postgresql-plperl-7.4_7.4.7-5_i386.deb fa4bfdf2d893f94ac14ea2b6f2662262 20534 misc optional postgresql-plpython-7.4_7.4.7-5_i386.deb 01b9cc465ba547ed0908b711d858155f 22440 misc optional postgresql-pltcl-7.4_7.4.7-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCeJSCDecnbV4Fd/IRAlfmAJ9SB2SPMmY9wlMKDLlXQp1bURwoWwCeOcOd j8Q8ZXKK6U/MU76AjHPLYUs= =R3KG -END PGP SIGNATURE- Accepted: libpq3_7.4.7-5_i386.deb to pool/main/p/postgresql-7.4/libpq3_7.4.7-5_i386.deb postgresql-7.4_7.4.7-5.diff.gz to pool/main/p/postgresql-7.4/postgresql-7.4_7.4.7-5.diff.gz postgresql-7.4_7.4.7-5.dsc to pool/main/p/postgresql-7.4/postgresql-7.4_7.4.7-5.dsc postgresql-7.4_7.4.7-5_i386.deb to pool/main/p/postgresql-7.4/postgresql-7.4_7.4.7-5_i386.deb postgresql-client-7.4_7.4.7-5_i386.deb to pool/main/p/postgresql-7.4/postgresql-client-7.4_7.4.7-5_i386.deb postgresql-contrib-7.4_7.4.7-5_i386.deb to pool/main/p/postgresql-7.4/postgresql-contrib-7.4_7.4.7-5_i386.deb postgresql-doc-7.4_7.4.7-5_all.deb to pool/main/p/postgresql-7.4/postgresql-doc-7.4_7.4.7-5_all.deb postgresql-plperl-7.4_7.4.7-5_i386.deb to pool/main/p/postgresql-7.4/postgresql-plperl-7.4_7.4.7-5_i386.deb postgresql-plpython-7.4_7.4.7-5_i386.deb to pool/main/p/postgresql-7.4/postgresql-plpython-7.4_7.4.7-5_i386.deb postgresql-pltcl-7.4_7.4.7-5_i386.deb to pool/main/p/postgresql-7.4/postgresql-pltcl-7.4_7.4.7-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted glib1.2 1.2.10-10 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 4 May 2005 12:10:14 +0200 Source: glib1.2 Binary: libglib1.2-doc libglib1.2-dbg libglib1.2-dev libglib1.2 Architecture: source all i386 Version: 1.2.10-10 Distribution: unstable Urgency: low Maintainer: Akira TAGOH [EMAIL PROTECTED] Changed-By: Sebastien Bacher [EMAIL PROTECTED] Description: libglib1.2 - The GLib library of C routines libglib1.2-dbg - GLib libraries and debugging symbols libglib1.2-dev - Development files for GLib library libglib1.2-doc - Documentation files for the GLib library version 1.2 Closes: 263042 Changes: glib1.2 (1.2.10-10) unstable; urgency=low . * gstrfuncs.c: - patch from Andreas Jochens [EMAIL PROTECTED] to fix the build with gcc4 (Closes: #263042). Files: ca0f70a41ffd27098e3ecd9ac4b30268 660 libs optional glib1.2_1.2.10-10.dsc fd5f69b6d74c38f67d3e55bd33d97b3a 149234 libs optional glib1.2_1.2.10-10.diff.gz e560188043748056f87f2ae79b246078 55980 doc optional libglib1.2-doc_1.2.10-10_all.deb 71faad7626471c903710fed64a70fe47 119378 libs optional libglib1.2_1.2.10-10_i386.deb 6f27cfa8c917aa1cd74c0ddba9efdd66 157278 libdevel optional libglib1.2-dev_1.2.10-10_i386.deb 823a8547c36bfa38d93db0b3685bb879 269224 libdevel extra libglib1.2-dbg_1.2.10-10_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCeKDuQxo87aLX0pIRAtMgAJ9AIImdi4SAlbnCWCdAvtSo6AHGEwCeKr/d ZWMftVT/iGsGFQ76iBvS6zI= =7Zyf -END PGP SIGNATURE- Accepted: glib1.2_1.2.10-10.diff.gz to pool/main/g/glib1.2/glib1.2_1.2.10-10.diff.gz glib1.2_1.2.10-10.dsc to pool/main/g/glib1.2/glib1.2_1.2.10-10.dsc libglib1.2-dbg_1.2.10-10_i386.deb to pool/main/g/glib1.2/libglib1.2-dbg_1.2.10-10_i386.deb libglib1.2-dev_1.2.10-10_i386.deb to pool/main/g/glib1.2/libglib1.2-dev_1.2.10-10_i386.deb libglib1.2-doc_1.2.10-10_all.deb to pool/main/g/glib1.2/libglib1.2-doc_1.2.10-10_all.deb libglib1.2_1.2.10-10_i386.deb to pool/main/g/glib1.2/libglib1.2_1.2.10-10_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted bugzilla 2.18-6 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 4 May 2005 11:49:10 +0200 Source: bugzilla Binary: bugzilla bugzilla-doc Architecture: source all Version: 2.18-6 Distribution: unstable Urgency: low Maintainer: Alexis Sukrieh [EMAIL PROTECTED] Changed-By: Alexis Sukrieh [EMAIL PROTECTED] Description: bugzilla - web-based bug tracking system bugzilla-doc - comprehensive guide to Bugzilla Closes: 305321 Changes: bugzilla (2.18-6) unstable; urgency=low . * Added a dependency on ucf (= 0.08). * Added myself as Maintainer, moved Rémi Perrot as Uploader. * Added some packages to the suggestions. (closes: #305321) Files: 86f6a36ccba6c7b364c15b9f250126e7 662 web optional bugzilla_2.18-6.dsc 46452ad6c47052dcecb15fa7c97d95d5 61799 web optional bugzilla_2.18-6.diff.gz 737951e77b9b2840f68a58be48c6d462 599620 web optional bugzilla_2.18-6_all.deb 6780a840022a86d4636593abb3c4c9e6 554372 doc optional bugzilla-doc_2.18-6_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCeKZUpFNRmenyx0cRAqREAJkBYfOeM2G4a7SeNd7oO9qafSuhJQCgyTaJ A3PcIidxHBSAHXvNLE/bODU= =/F4a -END PGP SIGNATURE- Accepted: bugzilla-doc_2.18-6_all.deb to pool/main/b/bugzilla/bugzilla-doc_2.18-6_all.deb bugzilla_2.18-6.diff.gz to pool/main/b/bugzilla/bugzilla_2.18-6.diff.gz bugzilla_2.18-6.dsc to pool/main/b/bugzilla/bugzilla_2.18-6.dsc bugzilla_2.18-6_all.deb to pool/main/b/bugzilla/bugzilla_2.18-6_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted powerpc-utils 1.1.3-14 (powerpc source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 01 May 2005 11:58:37 +0100 Source: powerpc-utils Binary: powerpc-utils Architecture: source powerpc Version: 1.1.3-14 Distribution: unstable Urgency: low Maintainer: Michael Schmitz [EMAIL PROTECTED] Changed-By: Michael Schmitz [EMAIL PROTECTED] Description: powerpc-utils - Various utilities for Linux/PowerPC Closes: 304493 Changes: powerpc-utils (1.1.3-14) unstable; urgency=low . * Fixed nvsetvol failure (infinite loop reading NVRAM) on OldWorld machines (reported by Christophe Donatsch [EMAIL PROTECTED]). Closes: #304493. Files: 7c3d97b6bd9733c47d5e0133c329723a 628 base required powerpc-utils_1.1.3-14.dsc 4876084ad3152510e20ae77740adb299 23494 base required powerpc-utils_1.1.3-14.diff.gz 27173135020746c93d739f6273fd753c 32644 base required powerpc-utils_1.1.3-14_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCeKQ1jH3TJU9qR44RAnIiAJ9QkhZCUZCSwEyOlwPV9wN7lJ08UgCcDRsc 6LQcTX8TwG59DZoLb39LO5M= =YqsU -END PGP SIGNATURE- Accepted: powerpc-utils_1.1.3-14.diff.gz to pool/main/p/powerpc-utils/powerpc-utils_1.1.3-14.diff.gz powerpc-utils_1.1.3-14.dsc to pool/main/p/powerpc-utils/powerpc-utils_1.1.3-14.dsc powerpc-utils_1.1.3-14_powerpc.deb to pool/main/p/powerpc-utils/powerpc-utils_1.1.3-14_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sendxmpp 0.0.7.1-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 4 May 2005 12:22:51 +0200 Source: sendxmpp Binary: sendxmpp Architecture: source all Version: 0.0.7.1-1 Distribution: unstable Urgency: low Maintainer: Guus Sliepen [EMAIL PROTECTED] Changed-By: Guus Sliepen [EMAIL PROTECTED] Description: sendxmpp - commandline XMPP (jabber) utility Changes: sendxmpp (0.0.7.1-1) unstable; urgency=low . * New upstream release. Files: e14b1cbc9cd2a4070439fd755fd01656 578 net optional sendxmpp_0.0.7.1-1.dsc b00ebdac865f6d1c509806c038049060 5889 net optional sendxmpp_0.0.7.1.orig.tar.gz 95de3df2bb1e0267cfe39407ffbea812 1635 net optional sendxmpp_0.0.7.1-1.diff.gz 0038b241ab7914bd1f273c196b69cf5d 10124 net optional sendxmpp_0.0.7.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCeKOpAxLow12M2nsRAsSSAJ400Zvo/Dc3lJ97du76vPXeXlO0AwCgmOhD l5s0cZVh5Kc9RaI2HF9k+wY= =avS3 -END PGP SIGNATURE- Accepted: sendxmpp_0.0.7.1-1.diff.gz to pool/main/s/sendxmpp/sendxmpp_0.0.7.1-1.diff.gz sendxmpp_0.0.7.1-1.dsc to pool/main/s/sendxmpp/sendxmpp_0.0.7.1-1.dsc sendxmpp_0.0.7.1-1_all.deb to pool/main/s/sendxmpp/sendxmpp_0.0.7.1-1_all.deb sendxmpp_0.0.7.1.orig.tar.gz to pool/main/s/sendxmpp/sendxmpp_0.0.7.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted util-vserver 0.30.207-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 4 May 2005 13:06:16 +0200 Source: util-vserver Binary: util-vserver Architecture: source i386 Version: 0.30.207-4 Distribution: unstable Urgency: low Maintainer: Ola Lundqvist [EMAIL PROTECTED] Changed-By: Ola Lundqvist [EMAIL PROTECTED] Description: util-vserver - tools for Virtual private servers and context switching Closes: 307429 Changes: util-vserver (0.30.207-4) unstable; urgency=low . * Fix install issue again, closes: #307429. Files: 9b614f92a5f305a7f5af27167a82a280 755 net optional util-vserver_0.30.207-4.dsc 4ffd8343c8ca5ba619354a3e045c9c20 121061 net optional util-vserver_0.30.207-4.diff.gz 38258a40006edb1ae7e1fc9be0ee7248 408648 net optional util-vserver_0.30.207-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCeK8RGKGxzw/lPdkRAmPgAJwLxoMPJpaU1zl249qfDF1k8KyWtgCfSu39 CVHy8hTCrURZz5DiF+p4tyU= =QGTd -END PGP SIGNATURE- Accepted: util-vserver_0.30.207-4.diff.gz to pool/main/u/util-vserver/util-vserver_0.30.207-4.diff.gz util-vserver_0.30.207-4.dsc to pool/main/u/util-vserver/util-vserver_0.30.207-4.dsc util-vserver_0.30.207-4_i386.deb to pool/main/u/util-vserver/util-vserver_0.30.207-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libwww-cnic-perl 0.13-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 04 May 2005 12:28:19 +0100 Source: libwww-cnic-perl Binary: libwww-cnic-perl Architecture: source all Version: 0.13-1 Distribution: unstable Urgency: low Maintainer: Jonathan McDowell [EMAIL PROTECTED] Changed-By: Jonathan McDowell [EMAIL PROTECTED] Description: libwww-cnic-perl - CentralNic Perl toolkit Changes: libwww-cnic-perl (0.13-1) unstable; urgency=low . * New upstream release. Files: 50db42b535562fcc40676f6c37bca94f 618 perl optional libwww-cnic-perl_0.13-1.dsc 135bfbfb05942257ec59c1fd5931e293 23053 perl optional libwww-cnic-perl_0.13.orig.tar.gz 97888bbd04d0437125432ce9abd040e8 1611 perl optional libwww-cnic-perl_0.13-1.diff.gz b7493b40a1cce3b60400d25b0b52959a 72570 perl optional libwww-cnic-perl_0.13-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCeLIO8b1L5FtDA2cRAu2nAKCJkkOwhQZYVV+UPR3+dnUYJkcP+gCgmgts d4hdJdzUfA4lzGmpDqkF2z0= =cfs2 -END PGP SIGNATURE- Accepted: libwww-cnic-perl_0.13-1.diff.gz to pool/main/libw/libwww-cnic-perl/libwww-cnic-perl_0.13-1.diff.gz libwww-cnic-perl_0.13-1.dsc to pool/main/libw/libwww-cnic-perl/libwww-cnic-perl_0.13-1.dsc libwww-cnic-perl_0.13-1_all.deb to pool/main/libw/libwww-cnic-perl/libwww-cnic-perl_0.13-1_all.deb libwww-cnic-perl_0.13.orig.tar.gz to pool/main/libw/libwww-cnic-perl/libwww-cnic-perl_0.13.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted util-vserver 0.30.207-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 4 May 2005 13:19:30 +0200 Source: util-vserver Binary: util-vserver Architecture: source i386 Version: 0.30.207-5 Distribution: unstable Urgency: high Maintainer: Ola Lundqvist [EMAIL PROTECTED] Changed-By: Ola Lundqvist [EMAIL PROTECTED] Description: util-vserver - tools for Virtual private servers and context switching Closes: 306549 Changes: util-vserver (0.30.207-5) unstable; urgency=high . * libvserver so files is now in the package, closes: #306549. Files: 574f363004ae30cb90c6035ac4e05f48 755 net optional util-vserver_0.30.207-5.dsc cc95f13972ae8a9810d4e3ecf0645029 121087 net optional util-vserver_0.30.207-5.diff.gz c5ecffb82f20710a5fcf608c7df769dc 427258 net optional util-vserver_0.30.207-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCeLB5GKGxzw/lPdkRAuEdAJ9+JwFWhva7t+HshJnP1cXdRppsOQCfWurv XfCKOSbfccYVqfx/EkIDO9Q= =GSw1 -END PGP SIGNATURE- Accepted: util-vserver_0.30.207-5.diff.gz to pool/main/u/util-vserver/util-vserver_0.30.207-5.diff.gz util-vserver_0.30.207-5.dsc to pool/main/u/util-vserver/util-vserver_0.30.207-5.dsc util-vserver_0.30.207-5_i386.deb to pool/main/u/util-vserver/util-vserver_0.30.207-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted zaptel 1:1.0.7-4 (powerpc all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 22 Apr 2005 07:35:28 +1200 Source: zaptel Binary: libtonezone1 zaptel-source zaptel libtonezone-dev Architecture: source all powerpc Version: 1:1.0.7-4 Distribution: unstable Urgency: high Maintainer: Debian VoIP Team [EMAIL PROTECTED] Changed-By: Matthew Grant [EMAIL PROTECTED] Description: libtonezone-dev - tonezone library (development) libtonezone1 - tonezone library (runtime) zaptel - zapata telephony utilities zaptel-source - Zapata telephony interface (source code for kernel driver) Closes: 305731 Changes: zaptel (1:1.0.7-4) unstable; urgency=high . * NMU as VOIP team taking so long. Fix compiler flags so that ztcfg works. (Closes: #305731) Files: e19c7d75753d793ccf9cab79f8868d34 878 sound optional zaptel_1.0.7-4.dsc a5077b7fa35537534a4f5efd2fb8fc67 50979 sound optional zaptel_1.0.7-4.diff.gz 0b9cfdc7bd659d2cceea33f5bc536692 274410 devel optional zaptel-source_1.0.7-4_all.deb 2ebed90d87c0dea1d8c2146431fe8f85 42502 sound optional zaptel_1.0.7-4_powerpc.deb 82fb5275a818e35f0ac50fff9f36e829 13444 libs optional libtonezone1_1.0.7-4_powerpc.deb a6e3db331aebcf357dc77595620a5e0e 5954 libdevel optional libtonezone-dev_1.0.7-4_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCeK5Uuk55Di7iAnARApnKAJ9qN0fneE13jQedOmMsGqlFPDlWAwCffZuW YOJFKMUBUmjCxL37S38rmug= =ZGbp -END PGP SIGNATURE- Accepted: libtonezone-dev_1.0.7-4_powerpc.deb to pool/main/z/zaptel/libtonezone-dev_1.0.7-4_powerpc.deb libtonezone1_1.0.7-4_powerpc.deb to pool/main/z/zaptel/libtonezone1_1.0.7-4_powerpc.deb zaptel-source_1.0.7-4_all.deb to pool/main/z/zaptel/zaptel-source_1.0.7-4_all.deb zaptel_1.0.7-4.diff.gz to pool/main/z/zaptel/zaptel_1.0.7-4.diff.gz zaptel_1.0.7-4.dsc to pool/main/z/zaptel/zaptel_1.0.7-4.dsc zaptel_1.0.7-4_powerpc.deb to pool/main/z/zaptel/zaptel_1.0.7-4_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted battfink 0.5-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 4 May 2005 13:27:09 +0100 Source: battfink Binary: battfink Architecture: source i386 Version: 0.5-3 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Ross Burton [EMAIL PROTECTED] Description: battfink - GNOME Power Management Configuration Closes: 306149 Changes: battfink (0.5-3) unstable; urgency=low . * Orphaning package * Rebuild against current libraries (closes: #306149) * Convert to proper CDBS not the old-skool Colin's version Files: c39ba03eca2e71b010bf1234a1c49541 672 gnome optional battfink_0.5-3.dsc 2e8ba7f5970ef6ce66970feec10da938 1669 gnome optional battfink_0.5-3.diff.gz c5ee1c1f9498bc3d3ff6876befc1409d 40072 gnome optional battfink_0.5-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCeMK6LQnkR9C0M98RAly8AJ9FUWVk19hbbwba9rhsdENeZ6CSvACeNBTF qNNtlRUX1tQU8+yBDRpUbGE= =rCub -END PGP SIGNATURE- Accepted: battfink_0.5-3.diff.gz to pool/main/b/battfink/battfink_0.5-3.diff.gz battfink_0.5-3.dsc to pool/main/b/battfink/battfink_0.5-3.dsc battfink_0.5-3_i386.deb to pool/main/b/battfink/battfink_0.5-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted bgoffice 3.0-4 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 3 May 2005 12:53:44 +0300 Source: bgoffice Binary: myspell-bg ibulgarian wbulgarian aspell-bg Architecture: source all i386 Version: 3.0-4 Distribution: unstable Urgency: low Maintainer: Anton Zinoviev [EMAIL PROTECTED] Changed-By: Anton Zinoviev [EMAIL PROTECTED] Description: aspell-bg - Bulgarian dictionary for aspell ibulgarian - The Bulgarian dictionary for ispell myspell-bg - The Bulgarian dictionary for myspell wbulgarian - The Bulgarian dictionary words for /usr/share/dict Closes: 306895 Changes: bgoffice (3.0-4) unstable; urgency=low . * Use cp1251 instead of microsoft-cp1251 in bg_BG.aff. Thanks to Damyan Ivanov, closes: #306895. Files: 95c8ff1125599b23f0b37cd3956cb663 705 text optional bgoffice_3.0-4.dsc fd73c0ce06f94b3996a25c82fa4dceb6 21137 text optional bgoffice_3.0-4.diff.gz f043da3e6f9de13ea4acd701d34a5586 249532 text optional myspell-bg_3.0-4_all.deb 59e4d7015e8ebc6668f4b2b8307c327d 1994362 text optional wbulgarian_3.0-4_all.deb c6209bf07990a66055c4f572e2c19e9b 8484032 text optional aspell-bg_3.0-4_i386.deb 4db57d2f36ff1a5a01841ffd9d5e273f 672874 text optional ibulgarian_3.0-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCd08NJP1eZJv0KwcRAjr/AJ42hjf6pMny+vqdjWrbV5M5cquMswCfXKJD gGDR7dNYlAJTmUkKNpEfaIU= =kVHr -END PGP SIGNATURE- Accepted: aspell-bg_3.0-4_i386.deb to pool/main/b/bgoffice/aspell-bg_3.0-4_i386.deb bgoffice_3.0-4.diff.gz to pool/main/b/bgoffice/bgoffice_3.0-4.diff.gz bgoffice_3.0-4.dsc to pool/main/b/bgoffice/bgoffice_3.0-4.dsc ibulgarian_3.0-4_i386.deb to pool/main/b/bgoffice/ibulgarian_3.0-4_i386.deb myspell-bg_3.0-4_all.deb to pool/main/b/bgoffice/myspell-bg_3.0-4_all.deb wbulgarian_3.0-4_all.deb to pool/main/b/bgoffice/wbulgarian_3.0-4_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dnsmasq 2.22-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 04 May 2005 13:25:23 + Source: dnsmasq Binary: dnsmasq Architecture: source i386 Version: 2.22-2 Distribution: unstable Urgency: low Maintainer: Simon Kelley [EMAIL PROTECTED] Changed-By: Simon Kelley [EMAIL PROTECTED] Description: dnsmasq- A small caching DNS proxy and DHCP server. Closes: 300694 306117 Changes: dnsmasq (2.22-2) unstable; urgency=low . * Make the resolv.conf polling code resistant to backwards-moving system clocks. (closes: #306117) (closes: #300694) Files: 680196fd7cdb4ec952a48e91c8454c99 528 net optional dnsmasq_2.22-2.dsc 0ab6e62c0cbedb6893fbe8f7d8380f01 10466 net optional dnsmasq_2.22-2.diff.gz 6df4ea92ec1df3a12780837bad61e44e 111734 net optional dnsmasq_2.22-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCeMQMwEl0z99oB74RAhKNAJ9MVnYhgutESxRBpYGhDp8dyGmSwACguemD 82PF4vZg0kXca7nLeC+Mh7Q= =i20K -END PGP SIGNATURE- Accepted: dnsmasq_2.22-2.diff.gz to pool/main/d/dnsmasq/dnsmasq_2.22-2.diff.gz dnsmasq_2.22-2.dsc to pool/main/d/dnsmasq/dnsmasq_2.22-2.dsc dnsmasq_2.22-2_i386.deb to pool/main/d/dnsmasq/dnsmasq_2.22-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
