Feeling Depressed?
Diabetes? Break out the OJ or Get This http://www.myyv.com/p/coupon/thompsoncoop Stop all future contacts myyv.comb.php Great wits are sure to madness near allied.
Re: packages missing from sarge
On Sat, May 07, 2005 at 09:03:19PM -0400, Joey Hess wrote: polyxmass-doc That's the documentation for binaries that _are_ in sid; it was a few days late for sarge. I find this to be quite sucky, that Debian ships the program, but not the documentation. (Let's note that I'm not the maintainer, and the maintainer thinks along the lines of not important, as the documentation can be downloaded from the upstream website anyway; as the doc on the upstream website is that of the last version, which may change between sarge and etch, I tend to disagree.) -- Lionel signature.asc Description: Digital signature
Re: Debian AMD64 Archive Move
On Sunday 08 May 2005 4:23pm, Goswin von Brederlow wrote: Ed Tomlinson [EMAIL PROTECTED] writes: On Sunday 08 May 2005 09:27, Joerg Jaspert wrote: On 10283 March 1977, Ed Tomlinson wrote: Whats going on == someone needs to check it. Thats it. That was the point made by Ed Cogburn. Its already been checked in the other arch! If this is not the case please explain why. Without that explanation I am forced to agree with Ed - the problem are political... Which is the bane of debian. We are *NOT* Debian, thats all you need to get! Ok. So from what I understand you are worried there are packages that debian can distribute but only debian has the permission... If this is the case is there not a way you can ask debian to distribute just the non free stuff? ie. This project builds the packages from debian sources, debian hosts the non free stuff on one of their servers. Who is to say we are allowed to build the binaries? This isn't an answer to his question. He's saying why not let the AMD64 non-free be distributed from a Debian server, since you're original excuse was that you aren't Debian. The answer is of course that you never even bothered to ask Debian for help or for a statement about your identity that would eliminate any theoretical legal threat. Hell, you could have just kept non-free on alioth and linked to it from AMD64's new location until a solution to the problem was found since non-free by itself is very small and the move away from alioth was because of space reasons, but no, even keeping the old location temporarily wasn't acceptable, non-free had to go, period. You saw a chance to get rid of non-free, even though its temporary, even though a majority of DDs have officially disagreed with you in a vote, and its only result is to annoy the AMD64 users until AMD64 returns to a Debian server, all because of your extremist ideology. I've been using Debian since pre-1.0 days when I got it off an Infomagic CD when I didn't have regular net access, but the times have changed, certainly the people around Debian have. I never would have thought that Debian would reach the point where it would deliberately and **pointlessly** annoy its own users because of software religion, instead of just trying to produce the best Linux distro possible, but its apparently come to that. No wonder Ubuntu looms large over Debian now, they're taking the best of Debian, but leaving behind the religious wars, and they will now gain strength and speed as Debian slows down due to endless religious infighting. Anyway, its been fun, but its time to move on now, apparently. Goodbye all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Regarding Bug#308495
Processing commands for [EMAIL PROTECTED]: submitter 308495 [EMAIL PROTECTED] Bug#308495: general: pmud does not turn off display Changed Bug submitter from Jeffrey B. Green [EMAIL PROTECTED] to [EMAIL PROTECTED] thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Tue, May 10, 2005 at 04:40:11PM -0700, Thomas Bushnell BSG wrote: What does the default Debian install do? Debian seems to use ext3 without directory indexing by default. Which is a sane choice as directory indexing on ext3 still seems to be not fully mature. And as mentioned in another thread it's not available on ext2 at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
Ed Cogburn [EMAIL PROTECTED] writes: On Sunday 08 May 2005 4:23pm, Goswin von Brederlow wrote: Ed Tomlinson [EMAIL PROTECTED] writes: On Sunday 08 May 2005 09:27, Joerg Jaspert wrote: On 10283 March 1977, Ed Tomlinson wrote: Whats going on == someone needs to check it. Thats it. That was the point made by Ed Cogburn. Its already been checked in the other arch! If this is not the case please explain why. Without that explanation I am forced to agree with Ed - the problem are political... Which is the bane of debian. We are *NOT* Debian, thats all you need to get! Ok. So from what I understand you are worried there are packages that debian can distribute but only debian has the permission... If this is the case is there not a way you can ask debian to distribute just the non free stuff? ie. This project builds the packages from debian sources, debian hosts the non free stuff on one of their servers. Who is to say we are allowed to build the binaries? This isn't an answer to his question. Obviously it isn't an answere but a questions. One designed to show him the errors of his ways. The project can't just build the packages from non-free since nothing says we have the right to. And in fact there are known cases the specificaly say we DONT. Wether Debian distributes it or someone else doesn't even figure into that. He's saying why not let the AMD64 non-free be distributed from a Debian server, since you're original excuse was that you aren't Debian. The answer is of course that you never even bothered to ask Debian for help or for a statement about your identity that would eliminate any theoretical legal threat. Hell, you could have just kept Hell, no. Why would we ever ask? We also never got those negative responses and rejections about this from the ftp-masters, the DPL, the DAM, the RMs, the Security team, We never asked for amd64 to be added to sid over a year ago and never filed a bug about it. No never. non-free on alioth and linked to it from AMD64's new location until a solution to the problem was found since non-free by itself is very small and the move away from alioth was because of space reasons, but no, even keeping the old location temporarily wasn't acceptable, non-free had to go, period. Actualy no. Space reasons actualy never figured into that for me. The new system is just some 10-20 times faster, has the right infrastructure, the right software, someone with root on the project. And the old location is still there. Even now it still has non-free although the old main/contrib parts have been removed. There are also still at least 2 mirrors of it with public access as you might have seen if you had bothered to check. You saw a chance to get rid of non-free, even though its temporary, even though a majority of DDs have officially disagreed with you in a vote, and its only result is to annoy the AMD64 users until AMD64 returns to a Debian server, all because of your extremist ideology. No DD has voted on the legality of a project outside of debian blidnly building and distributing packages from non-free. And even if they had it would not have any weight. When it came to adding the packages from alioth into the DAK and we hit non-free we took a step back, looked, saw that we can't just add it and decided to put it off till someone can look it over in detail. As you might have known if you had volunteered, joined the irc channel, help patch things together, discussed solutions, etc. I didn't see you doing any of that. Not now and not in the last 2 years. I've been using Debian since pre-1.0 days when I got it off an Infomagic CD when I didn't have regular net access, but the times have changed, certainly the people around Debian have. I never would have thought that Debian would reach the point where it would deliberately and **pointlessly** annoy its own users because of software religion, instead of just trying to produce the best Linux distro possible, but its apparently come to that. No wonder Ubuntu looms large over Debian now, they're taking the best of Debian, but leaving behind the religious wars, and they will now gain strength and speed And Ubuntu also leaves behind suspectible non-free packages. as Debian slows down due to endless religious infighting. Anyway, its been fun, but its time to move on now, apparently. Goodbye all. Let me ask just one questions: Do you have any idea who I or the other debian-amd64 members are and what we have done the last 2 years? You might also want to check those names against db.debian.org. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Experience more powerful orgasms
Now, it's finally possible for you to enlarge your penis http://www.tullam.info/ss/ Expand your Penis 20% Larger in weeks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Wednesday 11 May 2005 05:50, Goswin von Brederlow
[EMAIL PROTECTED] wrote:
Russell Coker [EMAIL PROTECTED] writes:
On Wednesday 11 May 2005 01:28, Goswin von Brederlow
[EMAIL PROTECTED] wrote:
Why would it be desirable to have arch-os directories under libexec?
On fedora-devel Bill Nottingham suggested having /usr/lib vs /usr/lib64
for programs that care about such things and /usr/libexec for programs
that don't.
32bit mozilla with flash plugin and 64bit mozilla without. A lot of
people seem to want that.
Bill's idea seems to work in that case. Although as you would need
different names in /usr/bin it might make sense to just name the libexec
files with the same extension as the file in /usr/bin that launches them.
What about mips O32, N32, N64 abis?
/lib, /lib32 and /lib64?
If you currently have /lib, /lib32, and /lib64 on MIPS then with Bill's idea
those directories could be used for three different versions of Mozilla.
What about i386 knetbsd and linux?
What is required there?
The multiarch /arch-os/ path is already present in the toolchain for
many things including include files and libs and works for all cases
of multiarch in a clean way. The lib{,32,64} subdirs are different on
every arch, confusing and insuffient for the bsd case.
Surely for every case in which multiple versions of binaries are needed we
also need multiple versions of libs. So having multiple /usr/lib directories
should do.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Recurring problems since upgrade of openldap2 (2.1 - 2.2)
Hi Torsten, Hi Michael, On Wed, Apr 20, 2005 at 12:09:15AM +0200, Michael Tautschnig wrote: I don't know which package I should file this bug against, but since the upgrade of the openldap2-packages I'm seeing these errors quite frequently: chown: /home/roland/debian/openldap/build/2.1.30/openldap2-2.1.30/libraries/libldap/cyrus.c:468: ldap_int_sasl_open: Assertion `lc-lconn_sasl_ctx == ((void *)0)' failed. This looks quite likely like the problem is in libldap2. In fact a bug report about this issue is already filed. I am still not sure what the bug is all about. Seems like libldap tries to open a sasl connection twice for some reason and want's to make sure that this is only done once. Not to mention that you probably don't need SASL. Could not reproduce this yet and it seems that it normally occurs with ldaps or failover configurations. I'm still seeing these problems every now and then - could you please send me the bug-number, such that I can at least track any news about regarding the problem. Seeing the problem enter stable is not to my liking... Regards, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#308533: ITP: gstat -- A program for multivariable geostatistical modelling, prediction and simulation
On Tue, May 10, 2005 at 08:55:28PM +, Dirk Eddelbuettel wrote: Howdy, Francesco Paolo Lovergine frankie at debian.org writes: Package: wnpp Severity: wishlist Owner: Francesco P. Lovergine frankie at debian.org * Package name: gstat Version : 2.4.4 Upstream Author : Edzer J. Pebesma e.pebesma at geog.uu.nl et al. * URL : http://www.gstat.org/ * License : GPL Description : A program for multivariable geostatistical modelling, prediction and simulation Gstat is an open source (GPL) computer code for multivariable geostatistical modelling, prediction and simulation, and has been around from 1997. In the original form, gstat is a stand-alone executable, interfaced to various GIS (including GRASS 6). As of 2003, the gstat functionaly is also available as an S extension, either as R package or S-Plus library. Do you intend to package this as r-cran-gstat, in-line with the numerous other R packages based on CRAN sources? Ah, nice point. Yes the package set is not yet ready now, I'd like packaging all needed bindings, so thank you for your suggestion... I'm just asking as gstat is also part of CRAN, e.g. can be found on http://cran.r-project.org/src/contrib/ and its mirrros. We have a never-quite-finalized Debian R Policy draft that several of us adhere to, and that we plan to expand -- i.e. we're working on getting all of CRAN auto-built (and apt-get'able, though not necessarily inside Debian as adding 500+ packages may be madness). Feel free to follow-up off-line if you have questions. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Russell Coker [EMAIL PROTECTED] writes:
On Wednesday 11 May 2005 05:50, Goswin von Brederlow
[EMAIL PROTECTED] wrote:
Russell Coker [EMAIL PROTECTED] writes:
On Wednesday 11 May 2005 01:28, Goswin von Brederlow
[EMAIL PROTECTED] wrote:
Why would it be desirable to have arch-os directories under libexec?
On fedora-devel Bill Nottingham suggested having /usr/lib vs /usr/lib64
for programs that care about such things and /usr/libexec for programs
that don't.
32bit mozilla with flash plugin and 64bit mozilla without. A lot of
people seem to want that.
Bill's idea seems to work in that case. Although as you would need
different names in /usr/bin it might make sense to just name the libexec
files with the same extension as the file in /usr/bin that launches them.
What about mips O32, N32, N64 abis?
/lib, /lib32 and /lib64?
I just thought of something even worse: knetbsd-amd64.
- bsd 64 bit libs
- bsd 32 bit libs
- linux 64 bit libs
- linux 32 bit libs
Or does bsd amd64 not support all 4 of those?
If you currently have /lib, /lib32, and /lib64 on MIPS then with Bill's idea
those directories could be used for three different versions of Mozilla.
What about i386 knetbsd and linux?
What is required there?
/usr/lib/i386-linux/ and /usr/lib/i386-knetbsd/.
The multiarch /arch-os/ path is already present in the toolchain for
many things including include files and libs and works for all cases
of multiarch in a clean way. The lib{,32,64} subdirs are different on
every arch, confusing and insuffient for the bsd case.
Surely for every case in which multiple versions of binaries are needed we
also need multiple versions of libs. So having multiple /usr/lib directories
should do.
Note that multiarch does not imply multiple versions of the same
binary though. So only the normal bin dirs we already have.
But different binaries for different archs might use the same
libraries and then those must be available for each arch. Since the
library name does not contain an unique arch-os pair different dirs
are a must. Like you say.
The question is just what do we name them. :)
The /lib, /lib64, /lib32 dirs used currently are a bit haphazzard and
can't cover all cases.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
Hi everybody, I'm only have a doubt, if someone make a mirror of the official debian (including non-free) and all that packages are ditributed is in danger to being sued? Accordingly with Goswin that's nothing about complain, only the main server of the distribution don't have non-free, the main server of non-free packages is still being alioth. I hope that packages still having the same process to update-compile as before, is'n it? Have a nice day. -- Engañarse por amor es el engaño más terrible; es una pérdida eterna para la que no hay compensación ni en el tiempo ni en la eternidad. Kierkegaard Jaime Ochoa Malagón Integrated Technology Tel: (55) 52 54 26 10
Re: Debian AMD64 Archive Move
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ed Cogburn [EMAIL PROTECTED] wrote: snip class=lotsofannoyingstuff / Yea, like annoying users by leaving non-free behind just because you're still mad that the DDs voted to keep it. Sure. I *am* an AMD64 user, and I can completely understand *why* they are being cautious. You, however, are just being plain rude to the NON-OFFICIAL amd64 porting team. If you're *THAT* in need of non-free, add in the i386 sources line for it and *BUILD THEM YOURSELF*. The amd64 port is *NOT* official yet, and while there's a release cycle going, I'd rather the developers GOT ON WITH THE RELEASE, than waste time on the packages in non-free, just what exactly do you need from there that you can't build anyway? Also, if you're *really* that bothered, why not use Ubuntu which has *official* support for amd64? (I know my reasons for sticking to debian unstable, do you?) Thanks, - -- Brett Parker web: http://www.sommitrealweird.co.uk/ email: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCgcGMEh8oWxevnjQRAp12AKCccqkD4DW4Y7nzmI91I59QkuvyzACgptZM Dh8hkXXWT+Ko7idWgxnqAok= =VLgs -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pine license
On Wed, May 11, 2005 at 12:28:29AM -0400, Raul Miller wrote: On 5/10/05, Glenn Maynard [EMAIL PROTECTED] wrote: In the past, UW has (in my opinion) played deliberate word games to retroactively revoke the Freeness of a prior Pine license, and this license is clearly non-free *without* any such stretching or contriving. I don't think the issue at that time was that they revoked the prior license, but that we generally try and cooperate with the providers of software. If someone doesn't want us working with them, why should we? I fully agree that we should cooperate with what copyright holders want, in general. What I remember, however, was that Pine was under a clearly Free license, and UW played word lawyer (modify and distribute, was it?) to minimize its freeness well after it was released and in wide use. I'm just saying that we should treat anyone with such a history with extreme scrutiny and skepticism, giving them no benefit of the doubt; they've lost that privilege. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
* Ed Cogburn | We ARE Debian for Heaven's sake! I can't see that you've done anything at all for the AMD64 port, nor are you a DD. Please go troll somewhere else. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hijacking apt-cacher (Jonathan Oxer MIA?)
#include hallo.h I do not get any answers from the maintainer of apt-cacher (Jonathan Oxer [EMAIL PROTECTED]) without any obvious reason, he has been responding few weeks ago. Looking at the outstanding bug reports for apt-cacher, I decide to hijack the package, where I rewrote the major parts (it's Debian native) to solve structural problems. Jonathan has been promising fixes for months/years now but I could not see any active development. If anyone has contact with Jonathan, please tell him to contact me. Otherwise I am going to upload the new package as 0.9 to unstable in less than a week, declaring myself as the new maintainer. Snapshot of the current changes file attached. Regards, Eduard. Format: 1.7 Date: Sun, 08 May 2005 23:07:38 +0200 Source: apt-cacher Binary: apt-cacher Architecture: source all Version: 0.8.6.1+0.9beta1 Distribution: experimental Urgency: low Maintainer: Jonathan Oxer [EMAIL PROTECTED] Changed-By: Eduard Bloch [EMAIL PROTECTED] Description: apt-cacher - caching system for Debian package and source files Closes: 180544 203123 251468 251660 261273 267680 273776 274059 274975 277279 278070 278799 282599 294617 299404 305175 305956 307151 Changes: apt-cacher (0.8.6.1+0.9beta1) experimental; urgency=low . * NMU (most likely, no reaction from Jonathan) * new format, separates package contents and HTTP headers (closes: #274975). The new script apt-cacher-format-transition.pl converts the old cached files to the new version and moves the parts to the new locations * used syswrite/sysread where appropriate to minimise effects of Perl buffering in combination with Apache2 (avoids apt-get's long waiting for headers phase in most cases, still appears from time to time, but not soo often. * uses modification times of index files if configured, this should avoid desynchronisation of some files (closes: #180544). Used curl to get the HTTP head for that (wget was just too stupid with its timestamping abilities). By the way rewrote the fetcher code to use curl only, removing the wget depedency (closes: #277279) * rewrote large parts of unsafe code, worked around race conditions (closes:#251468), fixed some crap like inserting of status code into half-downloaded files (closes: #251660), really detached the fetcher thread from the reader when the file is initialy beeing downloaded, and made error code passing more reliable * removed another useless fork (thread-over-thread-over-thread, jeez...) * removed the CHLD handler that fscked up the return codes that I needed from close (became cruft anways since I dropped the unneccessary forking) It now also fails sanely on mirror failure conditions (closes:#203123) * allowing alternative URL scheme (with apt-cacher?/server/...) which does work with alternative http daemons and added alternative dependency on boa and httpd-cgi (closes: #282599, #273776) * applied patch from Peter Denison [EMAIL PROTECTED] for more flexible names of index files (closes: #267680) * IPv6 filtering patch by Darren Salt (closes: #294617, #278070) * added my patch to do basic URL filtering (closes: #307151) * README.Debian update to the new stuff, removed cruft in debian/debian-old * rewrote the import script, made it work more efficient and work around the epoch numbers in the file names from apt's cache (closes: #278799) * rewrote and simplified the cleanup script (closes: #299404), also added support for source files and bzip2 compression (closes: #261273, #305956). Also made it refresh the index files rather then relying on possibly outdated data (or missing data because of tiffani/apt-dupdate usage) and really lock them while reading to not kill the cached data because the file is beeing downloaded just while the cleanup process runs * changed install.pl to copy the ownership of new files/directories and only doing so when they are new, rather than resetting them to www-data, and on every package upgrade * added my apt-precache.pl script for people that may need this toy (closes: #305175). It still needs some refinement to control the expiration of the subscriptions. * added hooks for checksumming of forwarded packages * new feature: checksumming of data (downloaded and uploaded). Optionaly, see README.Debian for instructions to enable it (closes: #274059) Files: f87111c2331a9bb05009312778433eb4 306 net optional apt-cacher_0.8.6.1+0.9beta1.dsc 1a6d4d29351eb607cdf98ca13f06feaf 48627 net optional apt-cacher_0.8.6.1+0.9beta1.tar.gz 3d4e6b1de9eb2923d2ca045e2b74ffcf 37048 net optional apt-cacher_0.8.6.1+0.9beta1_all.deb -- Immerhin meint die Filmförderungsanstalt, im Jahr 2002 seien 59 Millionen CD-Rohlinge von 5,9 Millionen Nutzern mit Filmen bespielt worden, im Durchschnitt also zwölf Rohlinge pro Anwender. --
Re: Policy and FHS-2.3?
* Juergen Salk | Among some other things, FHS version 2.3 provides a /srv hierarchy | to pick up at least some of the non-library contents that is | currently living below /usr/lib (e.g. CGI-Scripts)[4]. FHS 2.3 is utterly unusable wrt /srv for packagers since it's the local admin's domain. No packages should drop files into /srv as the structure is left unspecified. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Tue, May 10, 2005 at 11:00:48PM +0200, Adrian Bunk wrote: On Tue, May 10, 2005 at 10:42:43PM +0200, Andreas Tille wrote: On Tue, 10 May 2005, Adrian Bunk wrote: How often does a quick NMU that gives a fast improvement in the RC bugs metric hide the real problem that the maintainer is completely or partially MIA? Actually what is your opinion how to improve the QA process? It might sound strange, but I'd suggest to completely disallow NMUs without maintainer permission. This would make it take longer until RC bugs are fixed, but it would help on speeding up the finding of maintainers who are for any reason not able to properly maintain their packages. What are we trying to do, then? Release Debian, or find MIA maintainers? Based on your previous mails, I thought you wanted the first. That will go a *lot* easier if we don't have buggy packages anymore, for which NMU's can be helpful under certain circumstances. If, however, you are indeed intent on finding MIA maintainers for some to me obscure reason, then I think it'd be nice if you'd talk to those people actually doing that work at this moment, to see whether they agree with you that NMU's make their work harder. My guess is that you'll find they don't, but then of course I haven't asked either. -- 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: pine license
On Wed, May 11, 2005 at 12:28:29AM -0400, Raul Miller wrote: Also, if I recall correctly, there was a gnu project to write a pine replacement, but I don't know where that stands. Probably it's not complete because of a lack of development effort. Well, there's nano -- and if you want the pine UI, most people recommend mutt with a .muttrc that contains pine-style keybindings. At least that's what I used when switching from pine to mutt... -- 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: Hijacking apt-cacher (Jonathan Oxer MIA?)
* Eduard Bloch [EMAIL PROTECTED] [2005-05-11 10:55]: I do not get any answers from the maintainer of apt-cacher (Jonathan Oxer [EMAIL PROTECTED]) without any obvious reason, he has been responding few weeks ago. ... If anyone has contact with Jonathan, please tell him to contact me. Jon became the president of Linux Australia a while ago and is working on a book so he's probably just busy and will appreciate your work. I'd give him a chance to say go ahead though. If he doesn't reply to this mail, I'm fairly sure one of the Debian Melbourne guys have his phone number. In fact, Russell Coker has organized a meetup on Saturday so he might be able to ask Jon in person for you there (assuming that he'll attend, obviously). -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Wed, May 11, 2005 at 09:50:48AM +0200, Wouter Verhelst wrote: On Tue, May 10, 2005 at 11:00:48PM +0200, Adrian Bunk wrote: On Tue, May 10, 2005 at 10:42:43PM +0200, Andreas Tille wrote: On Tue, 10 May 2005, Adrian Bunk wrote: How often does a quick NMU that gives a fast improvement in the RC bugs metric hide the real problem that the maintainer is completely or partially MIA? Actually what is your opinion how to improve the QA process? It might sound strange, but I'd suggest to completely disallow NMUs without maintainer permission. This would make it take longer until RC bugs are fixed, but it would help on speeding up the finding of maintainers who are for any reason not able to properly maintain their packages. What are we trying to do, then? Release Debian, or find MIA maintainers? Based on your previous mails, I thought you wanted the first. That will go a *lot* easier if we don't Both belong together. The release team plans with a 1 month freeze and a big emphasis on the RC bugs metric. To be honest, I was very surprised if the release team would miss it's own release date by less than one month. E.g. there will always be problems like bugs with a too low severity or wrong tags that will show up late in the freeze. If there was more focus on the many other problems like maintainers not properly maintaining their packages instead of only on the RC bugs metric both before and during the freeze, the resulting release was better and some negative surprises were less likely. This might seem to defeat the goal of super-short freezes, but I have yet to see at least one freeze that was not only announced as super-short, but that was actually as short as it was announced... have buggy packages anymore, for which NMU's can be helpful under certain circumstances. This depends on how you define buggy packages. If you count only RC bugs you are correct. But non-RC bugs aren't the only bugs. Many annoying things like segfaults under specific circumstances are not considered RC. As an example, look at how many segfaults in the texinfo source package are unfixed for several months. And the last NMU didn't include e.g. my upstream-approved one-line patch for the #259561 segfault. Well, this bug is only important... RC bugs are a metric to measure the quality of Debian. But as it is a well-known fact about metrics, work on improving the metric often only improves the metric but not what it was supposed to measure. If, however, you are indeed intent on finding MIA maintainers for some to me obscure reason, then I think it'd be nice if you'd talk to those people actually doing that work at this moment, to see whether they agree with you that NMU's make their work harder. My guess is that you'll find they don't, but then of course I haven't asked either. Completely MIA maintainers are one part of the problem. But then there's the class of maintainers who manage to upload a new upstream version and perhaps fix some RC bugs every few months but are not able to properly handle all bugs in their packages. 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]
ITP: gnumail-doc -- User guide for GNUMail
Package: wnpp Severity: wishlist * Package name: cenon-doc Version : 0.1 Upstream Author : * URL : http://gnustep.made-it.com/Guides/GNUmail.html * License : Read on at the bottom* Description : User guide for GNUMail This package is an illustrated user guide for GNUMail. * Permission to use, copy, modify and distribute this Guide and its accompanying documentation for any purpose and without fee is hereby granted in perpetuity, provided that the above copyright notice and this paragraph appear in all copies. The copyright holders make no representation about the suitability of this Guide for any purpose. It is provided as is without expressed or implied warranty. -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux ibook 2.4.23-ben1 #7 Sat Dec 27 11:20:38 CET 2003 ppc Locale: LANG=POSIX, LC_CTYPE=POSIX -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Relevance of unzoo?
Hi, how important is it to have unzoo, now that zoo is in main? unzoo is only able to list and extract files, not to add new ones. Thomas -- +++ Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS +++ GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: distributed batch processing
On 10 May 2005, at 1:05 am, Paul Brossier wrote: Hi all, I am looking at ways to distribute batch jobs on various hosts. Essentially, i have N different command lines, and M different hosts to run them on: foo -i file1.data -p 0.1 foo -i file2.data -p 0.1 foo -i file3.data -p 0.1 ... foo -i file1.data -p 0.2 ... I had a try with 'queue' [1], but it seems rather obsolete now. I am now seeking recent alternatives. I went across a few solutions, such as DQS [2] (non-free, unmaintained), OpenPBS [3] (non-free), and distribulator [4] (looks interesting). Now i feel like i have missed something obvious. Is there a tool out there that i could use as a drop in replacement for queue? This is not the right forum for this question. However, I'll answer you anyway, since I know something about this. The two market leaders for this sort of processing are Sun GridEngine (which is free [as in beer, at least]) and Platform LSF, which is proprietary and costs $$$, but is very good at what it does. Both products can do what you are asking. Personally, I use LSF in my day job on a ~1500 CPU cluster, running a mixture of Red Hat 8.0, Debian sarge (on newer X86 boxes), Tru64 5.1B (on alphas) and SGI ProPack Linux (on our SGI Altixes), but I know SGE could run this as well. In LSF, you'd submit that set of jobs (let's say your files are named file1.data - file100.data) as something like the following: bsub -Jset1[1-100] -o 0.1.output.%I foo -i file\$LSB_JOBINDEX.data -p 0.1 bsub -Jset2[1-100] -o 0.2.output.%I foo -i file\$LSB_JOBINDEX.data -p 0.2 The standard output and standard error, as well as a job summary (CPU time and memory used, etc) would appear in output files named: 0.1.output.1 0.1.output.2 etc GridEngine would have its own methods for doing these so called job arrays. I looked at GNU queue a long time ago, and it looked (to me) as though its mode of operation was largely based on how LSF works, but when I looked at GNU queue it was pretty fundamentally broken (and it got removed from woody as a result). GridEngine is rather different in its organisation, but a lot of people swear by it. 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]
Packages are available for testing (was: Bug#308101: ITP: gstreamer0.8-pitfdll -- DLL/QTX loader plugin for GStreamer)
Hello people! I uploaded fist pitfdll package to http://mentors.debian.net/ Feel free to check it out and report any problems with it. The source package name is pitfdll, the resulting binary package is gstreamer0.8-pitfdll. And don't forget to read the README.Debian. PS Looking for sponsor for the package! :-) -- Dan Korostelev [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Hijacking apt-cacher (Jonathan Oxer MIA?)
#include hallo.h * Martin Michlmayr [Wed, May 11 2005, 10:45:47AM]: * Eduard Bloch [EMAIL PROTECTED] [2005-05-11 10:55]: I do not get any answers from the maintainer of apt-cacher (Jonathan Oxer [EMAIL PROTECTED]) without any obvious reason, he has been responding few weeks ago. ... If anyone has contact with Jonathan, please tell him to contact me. Jon became the president of Linux Australia a while ago and is working on a book so he's probably just busy and will appreciate your work. I'd give him a chance to say go ahead though. If he doesn't reply to this mail, I'm fairly sure one of the Debian Melbourne guys have his phone number. In fact, Russell Coker has organized a meetup on Saturday so he might be able to ask Jon in person for you there (assuming that he'll attend, obviously). Okay. In fact, his mail address produces bounces but I did not get them when sending mail to [EMAIL PROTECTED] Something is fishy there. Regards, Eduard. -- Lennier: There's no alcohol in here, is there? Ambassador Londo Mollari: Alcohol? No, of course not. Here, drink up. Lennier: Because my people do not react well at all to alcohol. Even a small quantity causes psychotic impulses and violent, homicidal rages. [Londo stops him from drinking] Ambassador Londo Mollari: Ahh ahh ahh... my mistake. *Alcohol*... -- Quotes from Babylon 5 -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] writes: Christoph Hellwig [EMAIL PROTECTED] writes: On Tue, May 10, 2005 at 02:03:01PM -0300, Humberto Massa wrote: These are two questions: Q: What filesystems... ? A: Every one of them with the possible exception of FAT and Minix. ext2 doesn't. Convert it to utilize directory hashing. The ability is there but iirc isn't used by default. What does the default Debian install do? Afaik the good, old, slow linear list. With that file open/stat is O(n) and ls also O(n) (cause you keep reading the dir instead of starting at the top each time). In which case, we do have that bug. Would you agree that that bug should be fixed (in Etch), irrespective of whether the FHS is also changed to split /usr/lib? Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
* Andreas Barth | Agreed. We should IMHO make such a requirement to be part of etchs | release policy. How are you going to solve the problem ia32-libs solves if not in this way? (Unless we want to make etch fully multiarchified, which I don't think we will.) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
Lionel Elie Mamane wrote: On Sat, May 07, 2005 at 09:03:19PM -0400, Joey Hess wrote: polyxmass-doc That's the documentation for binaries that _are_ in sid; it was a few days late for sarge. I find this to be quite sucky, that Debian ships the program, but not the documentation. (Let's note that I'm not the maintainer, and the maintainer thinks along the lines of not important, as the documentation can be downloaded from the upstream website anyway; as the doc on the upstream website is that of the last version, which may change between sarge and etch, I tend to disagree.) There's no particular reason we can't let this documentation package in, but it is up to its maintainer. -- see shy jo signature.asc Description: Digital signature
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
On Wed, May 11, 2005 at 03:50:29PM +0200, Tollef Fog Heen wrote: * Andreas Barth | Agreed. We should IMHO make such a requirement to be part of etchs | release policy. How are you going to solve the problem ia32-libs solves if not in this way? (Unless we want to make etch fully multiarchified, which I don't think we will.) I didn't see the previous message, so I'm not sure exactly what problem you're referring to - but regardless of multiarch, I want the arch-libs packages to die in etch. They should be built from biarch source packages instead. I just didn't have time to work on that before sarge. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG wrote: Humberto Massa [EMAIL PROTECTED] writes: with the possible exception of FAT and Minix. Q: are they used by a default? A: Last time I installed Debian (15 days ago), it asked me if I wanted my partition ext3, xfs, or reiserfs IIRC; I chose reiserfs, and I am pretty sure finding a file in a directory in reiserfs is O(log n) in the worse case. (Actually, I think that except for HUGE directories [far larger than /usr/lib] it accesses two or three blocks of disk in every case, hence being O(1)). How many directory entries do you think fit in a block? Is this a trick question? see... the average lib*.so.x.y in my disk is 12 characters long, a block has 8192 bytes, with an overhead of two dwords per dentry we have an average 409.6 directory entries in a block. YMMV. ls /usr/lib | wc -l brings me 9000, so it's very different to the disk thrice and twenty times just to give a ENOENT (ten times in the average to give success in load one lib) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
[Humberto Massa] It had equated the two of them in the first part of the phrase. [Raul Miller] The GPL did not use the word equals. Neither that is to say nor namely are equal to equals. Are we to understand that your argument hinges on such fine semantic distinctions as claiming that that is to say does not connote equivalency? Have you nothing better with which to prop up your point of view? (I'd come up with an analogy for how absurd this is beginning to sound, but by now I suspect you'd entirely miss the point, purposely or not.) signature.asc Description: Digital signature
Re: /usr/lib vs /usr/libexec
Christoph Hellwig [EMAIL PROTECTED] writes: On Tue, May 10, 2005 at 04:40:11PM -0700, Thomas Bushnell BSG wrote: What does the default Debian install do? Debian seems to use ext3 without directory indexing by default. Which is a sane choice as directory indexing on ext3 still seems to be not fully mature. And as mentioned in another thread it's not available on ext2 at all. So that means that, in fact, directory lookups on Debian are O(n), and we are, in fact, subject to problems from huge directories. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Martin Dickopp [EMAIL PROTECTED] writes: Would you agree that that bug should be fixed (in Etch), irrespective of whether the FHS is also changed to split /usr/lib? I'm not expert enough on the other factors that might be relevant to say. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG wrote: Christoph Hellwig [EMAIL PROTECTED] writes: On Tue, May 10, 2005 at 04:40:11PM -0700, Thomas Bushnell BSG wrote: What does the default Debian install do? Debian seems to use ext3 without directory indexing by default. Which is a sane choice as directory indexing on ext3 still seems to be not fully mature. And as mentioned in another thread it's not available on ext2 at all. So that means that, in fact, directory lookups on Debian are O(n), and we are, in fact, subject to problems from huge directories. As I said before, as far as I recall, the Debian installer suggested me only filesystems that have O(1) [O(log n) worst case] directory lookup. I chose reiserfs, but the installer IIRC suggested ext3 and xfs as alternatives. I will probably re-install my laptop this weekend, and then I can give you more accurate info. HTH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
[Raul Miller] However, I can present my point of view without resorting to this argument: ... Does that make sense? Much clearer, thanks. I was annoyed by the increasingly fine hair-splitting - thanks for bringing the level back to the realm of the meaningful. signature.asc Description: Digital signature
Re: GPL and linking
On 5/11/05, Peter Samuelson [EMAIL PROTECTED] wrote: The GPL did not use the word equals. Neither that is to say nor namely are equal to equals. Are we to understand that your argument hinges on such fine semantic distinctions as claiming that that is to say does not connote equivalency? Have you nothing better with which to prop up your point of view? I'm disputing an argument which seems to require a number of such fine points. It is difficult for me to raise such disputes without mentioning the the points themselves. However, I can present my point of view without resorting to this argument: Let's say that we have a court case which involves some contested GPLed work. How should we proceed? First, let's consider a work which doesn't have any binaries. This would be no different from any other copyright case -- you have to show that the work in question is copyrighted under the GPL, and you'd have to show that the terms of the GPL are being violated. This should be relatively simple, and we can neglect sections 2 and 3 (which are clearly being complied with if the rest of the license is being followed). Now let's imagine that we've got a case which involves binaries. What do we have to do? First, we need exhibits: the sources, and the binaries. Out of consideration for the court, we want to pick examples which are as simple as possible while representing all of the important contested issues. So let's imagine we have Exhibit A (the sources) and Exhibit B (the binary). [We need to also show that this binary is representative of something which is being distributed, but that's not really different from what you have to do in other copyright cases, so I'll ignore that part.] Second, we need to show that Exhibit B is derived from Exhibit A. Again, we want to present this in a simple and easily understandable form, and we want to also present complete information. Once we've shown that B is derived from A, we can start examining the terms of the GPL to make sure that they are being followed. For example, let's say now that we're the defending party, and we want to show that the mere aggregation clause applies. To do this, we would show that the disputed work could be replaced by something trivial, and that having done so, the program is still the same program -- we might do this by showing that it still has the same behavior. Switching sides again, if someone asserted that the mere aggregation clause applied, and used program behavior to make that assertion, and I believed that mere aggregation did not apply, I would show how the program failed to operate in some independent context, with the disputed section removed. Is that clear enough? Now, back to the argument: an argument has been raised that the GPL is flawed because a work based on the Program defined in two parts, where the first part asserts that work based on the Program is a derivative work. The assertion has been made that the second part of that definition is meaningless. Let's assume that this assertion is true, that the second part of that definition is meaningless. Let's further assume that I can construct an example case where a work isn't covered by the GPL because the second part of that definition is meaningless. What would that mean? Since Section 0 says that the GPL grants you license to distribute this work, and since there's no part of the GPL that grants you license where Section 0 does not apply, in our hypothetical case we would have shown that the GPL does not grant you license to distribute this work. At this point, either: A) Copyright law doesn't apply, so it doesn't matter that you don't have license, or B) The GPL doesn't apply, so it doesn't matter that the GPL doesn't grant you license, of C) Distributing the work is prohibited by law. My argument is that if you reach C) by ignoring the second half of the definition of work based on the Program, that you're doing something wrong. Does that make sense? -- Raul
Re: Questions about apt-get upgrade/install semantic
Gunnar Wolf a écrit : It is not only that - It is because apt-get is an infrastructure manager, not an individual package manager. dpkg does work on single packages, but apt-get works on the whole collection - and it could lead to inconsistencies if you let apt-get do a half-assed job and upgrade just one out of many packages - There might be dependencies down there, and this kind of command would not follow them (or would be inconsistent with the user's wishes of upgrading _only_ that). Greetings, Well, ok for that, but I was speaking of the non-trivial upgrade. I mean when upgrade e.g. samba, I want to upgrade it and, of course all its needed dependency upgrade. dpkg of course is great for installing a package alone. But I was wondering why apt-get install package does an upgrade if I don't have the latest version (that is ok the default behaviour) and why apt-get upgrade package doesn't do that thing. It seemed to be strange... But what everyone says in this thread can justify such a thing. But I would find more logical to do install to install a package... If it is already installed, why not, upgrade it... but it is an upgrade and not an installation. So I whish that apt-get upgrade package do the same as apt-get install package (well I know that upgrade roughly consists in removing the package and installing the new one). Cheers ;) , -- Martin Braure de Calignon Debian addict, active member of Amaya (Amayita)'s fan club (and fan of her tatoo) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Humberto Massa [EMAIL PROTECTED] writes: Thomas Bushnell BSG wrote: Christoph Hellwig [EMAIL PROTECTED] writes: On Tue, May 10, 2005 at 04:40:11PM -0700, Thomas Bushnell BSG wrote: What does the default Debian install do? Debian seems to use ext3 without directory indexing by default. Which is a sane choice as directory indexing on ext3 still seems to be not fully mature. And as mentioned in another thread it's not available on ext2 at all. So that means that, in fact, directory lookups on Debian are O(n), and we are, in fact, subject to problems from huge directories. As I said before, as far as I recall, the Debian installer suggested me only filesystems that have O(1) [O(log n) worst case] directory lookup. I chose reiserfs, but the installer IIRC suggested ext3 and xfs as alternatives. I will probably re-install my laptop this weekend, and then I can give you more accurate info. BUt according to Christoph Hellwig, the ext3 which is the default is used without directory indexing, which returns you to O(n). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Wednesday 11 May 2005 17:21, Thomas Bushnell BSG wrote: BUt according to Christoph Hellwig, the ext3 which is the default is used without directory indexing, which returns you to O(n). You have yet to present any numbers which show there is a problem here. Can we please discuss real world problems? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Will Newton wrote: On Wednesday 11 May 2005 17:21, Thomas Bushnell BSG wrote: BUt according to Christoph Hellwig, the ext3 which is the default is used without directory indexing, which returns you to O(n). You have yet to present any numbers which show there is a problem here. Can we please discuss real world problems? This is not an imaginary problem, after all, in principle. Let's see, as I wrote before, my installation has *thousands* of files in /usr/lib and, in some filesystems, this can add up to a very large time (and ab-use of dentry cache memory) to link, say, Konqueror (which links to *hundreds* of shared objects). Imagine that, to load Konqui, you have to go 200 times to the disk (ok, cache, but...), each of them reading the 1 entries I have in /usr/lib, some of them twice or three times, to follow the symlinks. This is a real inefficiency. So, if you ask me for MHO, ext3 should be used by default *with* directory indexing. And maybe FHS should be pressed to provide something like /usr/libexec. -- HTH Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Wednesday 11 May 2005 17:35, Humberto Massa wrote: This is not an imaginary problem, after all, in principle. Let's see, as I wrote before, my installation has *thousands* of files in /usr/lib and, in some filesystems, this can add up to a very large time (and ab-use of dentry cache memory) to link, say, Konqueror (which links to *hundreds* of shared objects). Imagine that, to load Konqui, you have to go 200 times to the disk (ok, cache, but...), each of them reading the 1 entries I have in /usr/lib, some of them twice or three times, to follow the symlinks. This is a real inefficiency. That is a possibility, it does sound sub-optimal. However, if you optimise before measuring there is no guarantee things will get any faster. Is reading the directory taking an appreciable amount of time compared to say, doing relocations? So, if you ask me for MHO, ext3 should be used by default *with* directory indexing. And maybe FHS should be pressed to provide something like /usr/libexec. How much stuff would go in libexec? I suspect it would mostly be stuff in currently in subdirectories of /usr/lib, which is less than 7% of my /usr/lib. So 7% performance improvement on something that is yet to be proven to be a bottleneck. On some filesystems. Without benchmarks it's a pointless discussion anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
[Humberto Massa] As I said before, as far as I recall, the Debian installer suggested me only filesystems that have O(1) [O(log n) worst case] directory lookup. I chose reiserfs, but the installer IIRC suggested ext3 and xfs as alternatives. As Christoph (I think) said, Debian creates ext3 filesystems without the dir_index flag, by default. He even mentioned that ext3 dir_index may have a few problems remaining, so that this is a wise default. You may of course use 'tune2fs -O dir_index /dev/whatever' to change this, and then you'll have your O(1) lookups and opens. Requires remounting, and I think an fsck pass. HOWEVER This is a very silly thing to argue about without benchmarks. Those who care about this - yes, Thomas, I mean you - should get numbers. Here's how: (1) dynamicly link a hello world program to a dozen or so libraries (2) find or create a Debian system with a few thousand /usr/lib files (3) figure out execution time using your favorite loop technique (4) rename /usr/lib to /usr/libexec, create a new /usr/lib, and use 'ln' (not 'ln -s' of course - symlinks of course just add *more* lookups, in the original big directory) to repopulate /usr/lib with just a few hundred library files and symlinks. You may wish to give /lib similar treatment, but tread with care lest you find yourself unable to complete the procedure. (For one thing you'll want to do it in 'sash' or 'busybox'.) (5) repeat your favorite loop technique Getting a cold dentry cache before steps 3 and 5 is left as an exercise to the poor sap with so much dedication to the Gentoo premature optimisations R us ideals. Oh yeah, for bonus points: (6) put your original /usr/lib back where it was, then convert libfoo.so.N symlinks to hard links. That will cut your directory lookups in half. See if this makes any difference. If so, ponder a new proposal taking this optimisation into account as well. signature.asc Description: Digital signature
Re: /usr/lib vs /usr/libexec
Le mercredi 11 mai 2005 à 13:35 -0300, Humberto Massa a écrit : Imagine that, to load Konqui, you have to go 200 times to the disk (ok, cache, but...), each of them reading the 1 entries I have in /usr/lib, some of them twice or three times, to follow the symlinks. This is a real inefficiency. You said it: there is a cache. After the first access, the directory will be in the cache. Making all of this a purely imaginary problem. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Re: /usr/lib vs /usr/libexec
Peter Samuelson wrote: (...) HOWEVER This is a very silly thing to argue about without benchmarks. Those who care about this - yes, Thomas, I mean you - should get numbers. Here's how: (steps 1-6) You are 100% right and I stand corrected. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
On 5/11/05, Raul Miller [EMAIL PROTECTED] wrote: [an argument, much of which would make sense in a parallel universe where the GPL is on the law books as 17 USC 666] I am not a lawyer (or a fortiori a judge), so all that I can do to explain why this isn't valid legal reasoning is to point you at documents to which you and I both have access. To the extent that the arguments that I have made involve fine points, I have backed them up with more valid binding case law than you can shake a stick at. You have offered me the instruction sheet for a copyright registration form and some definitions from random online dictionaries. So I'm not going to say that your point of view isn't perfectly valid as your own point of view; but I don't have any reason to believe that it's a good predictor of how a court case involving the FSF suing FooSoft for linking against GNU readline would be argued. Cheers, - Michael
Re: GPL and linking
On 5/11/05, Michael K. Edwards [EMAIL PROTECTED] wrote: So I'm not going to say that your point of view isn't perfectly valid as your own point of view; but I don't have any reason to believe that it's a good predictor of how a court case involving the FSF suing FooSoft for linking against GNU readline would be argued. Of course, a court case does not have to be argued that way. However, I believe that a person who holds a GPL copyright who neglects these points in court is likely to lose. A judge can ignore issues which are not raised in court, and will focus on issues which are raised and contested in court. -- Raul
Re: mrtg package problems
Laszlo Boszormenyi wrote: Hi, On Tue, 2005-05-10 at 12:23 -0500, Adam Majer wrote: Currently there are two packages that he maintains, Yup. I would like to maintain mrtg since I do use it. As to the other package, it probably should be orphaned. OK, please check the bugs, review patches etc. for mrtg. I may even sponsor it if you need it. A company I am contact with, is just checking it, but they may switch to netmrg. Most (or almost most :) of the bugs seem like they were fixed some time ago. Some of the bugs look like usability issues and I will get to those. My other big cleanup job was with lpr, which I think is now in a much better shape then when it was orphaned. This is another small, yet important to me, package that was neglected way too long. As to netmrg, well, it looks OK. I guess it depends what one needs. All I need it to get some SNMP data into a graph form. For me mrtg is perfect for what I need it. The new mrtg (0.11) will probably not make it into Sarge due to the freeze. The one in Sarge is quite usable without any major bugs. And finally, I will not be needed a sponsor :) Anyway, I will try to take care of the problem. I'll see if I can contact Shiju and if there is no response by end of the month, I'll orphan the packages and take over mrtg, unless someone has a problem. I am OK with it, even if I am only a simple DD without too much words. Anyway, you can do NMUs meanwhile as Jeroen already wrote about it. Sure. I will look over the bugs and try to get the vast majority closed/fixed. I didn't know that Jeroen tried to contact Shiju until I read his reply to you yesterday. - Adam signature.asc Description: OpenPGP digital signature
Re: mrtg package problems
Gunnar Wolf wrote: Adam Majer dijo [Tue, May 10, 2005 at 12:23:10PM -0500]: Currently there are two packages that he maintains, http://qa.debian.org/[EMAIL PROTECTED] *libnet**-easytcp-perl **mrtg I would like to maintain mrtg since I do use it. As to the other package, it probably should be orphaned. I am not currently using it, but seems easy to maintain - I'll take it over. Sure. Thanks. I guess Shiju's packages are now divided up. Now let's see if he even reads his email anymore. There is no rush anymore since the new packages will most likely not enter Sarge. - Adam signature.asc Description: OpenPGP digital signature
updated cogito package - now with docs!
The upstream now includes docs for the GIT core, though still not for Cogito. The docs are available in .txt and .html, and they _would_ be available as manpages except for a bug in asciidoc. The asciidoc maintainer has been offered a patch. You can grab the new cogito package here: http://highlab.com/~seb/debian You can look at the docs here (or in /usr/share/doc/cogito if you install the package): http://highlab.com/~seb/git-docs/git.html -- Sebastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
On 5/11/05, Raul Miller [EMAIL PROTECTED] wrote: Of course, a court case does not have to be argued that way. No, but if it's to have a prayer of winning, it has to be argued in terms of the law that is actually applicable, not as if the court were obliged to construe the GPL so that every word has meaning and then proceed directly to copyright law. However, I believe that a person who holds a GPL copyright who neglects these points in court is likely to lose. Erroneous beliefs are among the liberties granted to humankind by the universe. One or both of us holds some very erroneous beliefs. A judge can ignore issues which are not raised in court, and will focus on issues which are raised and contested in court. A judge cannot ignore law which doesn't happen to be in one of the parties' briefs. Cheers, - Michael
Last Stop 4 UR Favorite Pills
Bypass the Doctor Get Drugs Now http://www.s0o.net/p/coupon/marybmato Hate recieving these msgs s0o.netu.php Down these mean streets a man must go who is not himself mean, who is neither tarnished nor afraid.
Re: GPL and linking
On 5/11/05, Michael K. Edwards [EMAIL PROTECTED] wrote: On 5/11/05, Raul Miller [EMAIL PROTECTED] wrote: Of course, a court case does not have to be argued that way. No, but if it's to have a prayer of winning, it has to be argued in terms of the law that is actually applicable, not as if the court were obliged to construe the GPL so that every word has meaning and then proceed directly to copyright law. The law as written says that you do not have permission to copy except as granted by a license. Thus the GPL's license grant is not only applicable, it's the issue which is most likely to be contested in such a case. A judge can ignore issues which are not raised in court, and will focus on issues which are raised and contested in court. A judge cannot ignore law which doesn't happen to be in one of the parties' briefs. In principle, at least, the parties will not be contesting the law. In principle, one party will be asserting that unlicensed copies are being distributed, and will be asking for monetary compensation for the resulting damages. The other party will be asserting that the copies were licensed (or, perhaps, simply settling out of court). Of course, I did gloss over a number of other issues which you would have to address in a real court case. For example, I didn't say anything about how to determine damages for the case -- for that you'd probably have to put a value on development time and show how the issue has cost you development time. -- Raul
Re: pine license
On Wed, 11 May 2005 03:33:41 -0400 Glenn Maynard wrote: I fully agree that we should cooperate with what copyright holders want, in general. What I remember, however, was that Pine was under a clearly Free license, and UW played word lawyer (modify and distribute, was it?) Yes, see for instance: http://www.asty.org/articles/20010702pine.html to minimize its freeness well after it was released and in wide use. I'm just saying that we should treat anyone with such a history with extreme scrutiny and skepticism, giving them no benefit of the doubt; they've lost that privilege. Agreed. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpR5lLStHysw.pgp Description: PGP signature
Re: updated cogito package - now with docs!
On Wed, 11 May 2005 14:05:28 -0600, Sebastian Kuzminsky wrote: The upstream now includes docs for the GIT core, though still not for Cogito. The docs are available in .txt and .html, and they _would_ be available as manpages except for a bug in asciidoc. The asciidoc maintainer has been offered a patch. You can grab the new cogito package here: http://highlab.com/~seb/debian FYI, you can make the packages and source apt-get'able w/ a script like http://www.acm.rpi.edu/~dilinger/libmusicbrainz-ruby/mkarchive.sh -- 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 09:36:39AM -0700, Thomas Bushnell BSG wrote: 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. I'm quite surprised - I have to admit it actually works (and Colin immediately fixed two minor glitches with multiple submitters). 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: Relevance of unzoo?
On Wed, May 11, 2005 at 12:39:04PM +0200, Thomas Schoepf wrote: Hi, Hi Thomas, how important is it to have unzoo, now that zoo is in main? unzoo is only able to list and extract files, not to add new ones. the functionality of unzoo is a subset of the functionality of zoo? In this case a dropping of unzoo seems reasonable. But the packages clamav and amavis-ng do recommend the unzoo package. However they use it (I havn't checked) they should be converted to use the zoo package before the unzoo package gets removed. 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: updated cogito package - now with docs!
Andres Salomon [EMAIL PROTECTED] wrote: On Wed, 11 May 2005 14:05:28 -0600, Sebastian Kuzminsky wrote: You can grab the new cogito package here: http://highlab.com/~seb/debian FYI, you can make the packages and source apt-get'able w/ a script like http://www.acm.rpi.edu/~dilinger/libmusicbrainz-ruby/mkarchive.sh Cool. Ok all you crazy gits, add this to your sources.list and get apt-getting: # Seb's Cogito packages deb http://highlab.com/~seb/debian / deb-src http://highlab.com/~seb/debian / Only i386 binary packages for now, get the sources if you want to try compiling it on your architecture (and send me bugreports when it breaks!). -- Sebastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relevance of unzoo?
This one time, at band camp, Adrian Bunk said: On Wed, May 11, 2005 at 12:39:04PM +0200, Thomas Schoepf wrote: Hi, Hi Thomas, how important is it to have unzoo, now that zoo is in main? unzoo is only able to list and extract files, not to add new ones. the functionality of unzoo is a subset of the functionality of zoo? In this case a dropping of unzoo seems reasonable. But the packages clamav and amavis-ng do recommend the unzoo package. However they use it (I havn't checked) they should be converted to use the zoo package before the unzoo package gets removed. Command line arguments are hard coded in the csae of clamav, at least, I'm afraid. This is of course changeable, but it will mean a new upload (and a new upstream just came out today - blech). Take care, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp4AU8n9JY0O.pgp Description: PGP signature
Re: Hijacking apt-cacher (Jonathan Oxer MIA?)
Hi Eduard and Martin, On Wed, 2005-05-11 at 10:45 +0100, Martin Michlmayr wrote: * Eduard Bloch [EMAIL PROTECTED] [2005-05-11 10:55]: I do not get any answers from the maintainer of apt-cacher (Jonathan Oxer [EMAIL PROTECTED]) without any obvious reason, he has been responding few weeks ago. ... If anyone has contact with Jonathan, please tell him to contact me. Jon became the president of Linux Australia a while ago and is working on a book so he's probably just busy and will appreciate your work. I'd give him a chance to say go ahead though. Just to make it official: go ahead ;-) Eduard, I'm really sorry I haven't responded recently but I've been following your work on apt-cacher and I certainly appreciate your efforts. In recent times I've been even more of a pathetic excuse for a DD than usual, so I apologise for that. There is a whole litany of excuses including those already mentioned by Martin: I'm now President of Linux Australia (a position involving much more work than it may appear), I'm working on 3 more books, spent the last few months organising Debian Miniconf4, have a newish baby son, am on 5 (IIRC) management or advisory boards, am part of upstream for a bunch of projects, and am trying to run a business that's so frantically busy I can't hire people fast enough. So since you've shown so much interest and initiative, you're welcome to either adopt or co-maintain Apt-cacher as you prefer. It still has personal interest for me but obviously you're in a better position to give it the attention it deserves right now. Cheers :-) Jonathan Oxer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pine license
Wouter Verhelst [EMAIL PROTECTED] writes: Well, there's nano -- and if you want the pine UI, most people recommend mutt with a .muttrc that contains pine-style keybindings. At least that's what I used when switching from pine to mutt... Does that actually offer the pine experience though? I thought what people liked about the pine UI was that _everything_ is an in-your-face menu (even stuff like editing your settings); from my experience with mutt, it seems fairly different in that respect, much more than just keybindings. [Personally I absolutely loathe pine, but a lot of people like that sort of thing.] -Miles -- Come now, if we were really planning to harm you, would we be waiting here, beside the path, in the very darkest part of the forest? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308725: ITP: dhcpv6 -- a stateful address autoconfiguration protocol for IPv6
Package: wnpp Severity: wishlist Owner: Adam M. [EMAIL PROTECTED] * Package name: dhcpv6 Version : 0.10 Upstream Author : ?? Not a single one - many... * URL : http://dhcpv6.sourceforge.net/ * License : Mostly BSD, some LGPL and MIT/X Description : a stateful address autoconfiguration protocol for IPv6 DHCPv6 is a stateful address autoconfiguration protocol for IPv6, a counterpart to IPv6 stateless address autoconfiguration protocol. It can either be used independently or it can coexist with its counterpart protocol. This protocol uses client/server mode of operation but can also provide support through a Relay Agent. Current upstream does not appear to be very active. I'm not yet certain whether I will make this a Debian package or Upstrea/Debian patch. This depends on how much of the code can be replaced by current libc functionality. I should get this package done within a month (so by mid-June) since I will be doing some code reviewing and not just packaging. - Adam -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-k7 Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
Fine. I have been goaded into rebutting this specimen. On 5/11/05, Raul Miller [EMAIL PROTECTED] wrote: I'm disputing an argument which seems to require a number of such fine points. It is difficult for me to raise such disputes without mentioning the the points themselves. However, I can present my point of view without resorting to this argument: Let's say that we have a court case which involves some contested GPLed work. How should we proceed? First, let's consider a work which doesn't have any binaries. This would be no different from any other copyright case -- you have to show that the work in question is copyrighted under the GPL, and you'd have to show that the terms of the GPL are being violated. This should be relatively simple, and we can neglect sections 2 and 3 (which are clearly being complied with if the rest of the license is being followed). Nope. Under US law at least (IANALIAJ), you'd have to show: 1. that you, yourself, hold a valid registered copyright to a specific portion of the copyrightable expression in a particular work A; and 2. that a portion of your contribution to A has been copied to work B, using the Computer Associates v. Altai abstraction-filtration-comparison standard, and that the amount of _copyrightable_ material that has been copied exceeds de minimis; and 3. that the distributor of B does not have license from you to copy that material from A to B, or that the distributor's conduct exceeds the scope of the license (e. g. creation of a derivative work when the license extends only to verbatim copies), or that the license has been terminated for material breach not otherwise reparable under the applicable contract law standard; After which, the distributor of B has an opportunity to demonstrate: 4. that some statutory or judicially created affirmative defense, such as fair use, justifies the distributor's conduct; or 5. that public policy or a principle of equity demands that the distributor's conduct be sanctioned despite the unavailability of any defense under current law. Then, and only then, you may be entitled to some relief under copyright law. That relief may be as little as one dollar of damages. Now let's imagine that we've got a case which involves binaries. What do we have to do? First, we need exhibits: the sources, and the binaries. Out of consideration for the court, we want to pick examples which are as simple as possible while representing all of the important contested issues. So let's imagine we have Exhibit A (the sources) and Exhibit B (the binary). [We need to also show that this binary is representative of something which is being distributed, but that's not really different from what you have to do in other copyright cases, so I'll ignore that part.] Second, we need to show that Exhibit B is derived from Exhibit A. Again, we want to present this in a simple and easily understandable form, and we want to also present complete information. Once we've shown that B is derived from A, we can start examining the terms of the GPL to make sure that they are being followed. For example, let's say now that we're the defending party, and we want to show that the mere aggregation clause applies. To do this, we would show that the disputed work could be replaced by something trivial, and that having done so, the program is still the same program -- we might do this by showing that it still has the same behavior. This has no bearing on the definition of work based on the Program or of mere aggregation or on any other relevant ambiguity in the construction of the contract. The only sense in which I can see it having any relevance is if the only theory under which B is derived from A is characters and mise en scene, as in Micro Star v. FormGen; in which case the existence of a reasonable alternative to A, under which B does something similarly useful, may be a successful defense. Switching sides again, if someone asserted that the mere aggregation clause applied, and used program behavior to make that assertion, and I believed that mere aggregation did not apply, I would show how the program failed to operate in some independent context, with the disputed section removed. Is that clear enough? Clear as mud. What do you mean, used program behavior to make that assertion? Even though this is an offer of contract, its drafter harps on one copyright note. Mere aggregation is a phrase with no legal meaning (there is a single usage of this phrase in all of the appellate law accessible to FindLaw, and it refers to members of a school prayer club). According to FindLaw, Merriam-Webster's Dictionary of Law defines aggregation as: 1: the collecting of individual units (as damages) into a whole 2: a collection of separate parts that is unpatentable because no integrated mechanism or new and useful result is produced I think it is vanishingly improbable, even if this were a
[Baghira] :: Re: packages missing from sarge
Sorry, but looks like there is no rc bugs in the baghira package. There was only one bug Serious policy violations but it is resolved now. Why it is out of release? p/s Also baghira is a source package for kwin-baghira. Is it means that kwin-baghira will be refused too? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
On 5/11/05, Michael K. Edwards [EMAIL PROTECTED] wrote: Fine. I have been goaded into rebutting this specimen. Most of this is focused on contract law issues. I've written a separate post suggesting the obvious alternative (Tort law) Since Section 0 says that the GPL grants you license to distribute this work, and since there's no part of the GPL that grants you license where Section 0 does not apply, in our hypothetical case we would have shown that the GPL does not grant you license to distribute this work. Wrongo. The GPL grants you license to copy, modify, and distribute A under the applicable terms. Whether by mere aggregation or by reductio ad absurdum, you may distribute some collections containing A; and there is no basis in the text of the GPL for enforcing on the licensee any division into some permitted collections and some forbidden collections. So B may be distributed so long as the applicable covenants of specific performance with respect to A are honored. I'm assuming that we're talking about a case involving binaries for the work A+B, which means we're talking about a case where either 1) The applicable terms are being followed, and B is available under GPL terms 1a) B is merely aggregated with A in the context of these binaries, or 2) The applicable terms are not being followed, and B is not available under GPL terms, and the work A+B is a significant work in the context of copyright law. At this point, either: A) Copyright law doesn't apply, so it doesn't matter that you don't have license, or B) The GPL doesn't apply, so it doesn't matter that the GPL doesn't grant you license, of C) Distributing the work is prohibited by law. My argument is that if you reach C) by ignoring the second half of the definition of work based on the Program, that you're doing something wrong. Does that make sense? No. Ok, I'm looking for how you think this doesn't make sense. Copyright law applies to the copying of A. True. And to the copying of B. And, to the copying of A+B. The distributor of B claims license under the GPL to copy A. This requires that B do so under certain terms, which is I think where our dispute lies, but continuing... The court construes the terms of that license, settles all other relevant questions of fact, and either decides that the plaintiff is entitled to some relief or that he is not. No disagreement here. It is then so ordered, and there's a path for appeals on points of law. Prohibited by law doesn't mean jack. It's true that the court can (and will) interpret the law. However, Prohibited by law does in fact have meaning. -- Raul
Re: [Baghira] :: Re: packages missing from sarge
Vadim Petrunin wrote: Sorry, but looks like there is no rc bugs in the baghira package. There was only one bug Serious policy violations but it is resolved now. Why it is out of release? http://packages.qa.debian.org/b/baghira.html Ask the maintainer. It was not in Sarge because of that one RC bug. The fixed version was uploaded just two days ago so... Sarge has frozen a while before that. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Project Leader report for 2005-04-24
On Fri, May 06, 2005 at 11:06:31PM -0500, Branden Robinson wrote: On Mon, Apr 25, 2005 at 01:45:52PM +0200, Josselin Mouette wrote: Why, in this case, isn't the package released for the other architectures? There's nothing wrong with sending an update later for architectures that were missing in the first run. I don't have an answer for this. My guess is that the Security Team decided delaying the update was the lesser of two evils. Security folks, would you care to comment? In any event, we have recovered from the ARM situation (and xfree86 for stable/arm is built for it), and you can expect some happy details in my next DPL report. There is a certain amount of overhead involved in issuing an advisory, and issuing multiple advisories for an issue multiplies that overhead. It's also generally considered bad for the stable archive to be out of sync (in particular, this can make packages uninstallable in the case of interdependencies between arch: all and arch: any packages). -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Baghira] :: Re: packages missing from sarge
Vadim Petrunin wrote: Sorry, but looks like there is no rc bugs in the baghira package. There was only one bug Serious policy violations but it is resolved now. Why it is out of release? As you can see in update-excuses: baghira (- to 0.6f-1) Maintainer: Jose Luis Tallon Too young, only 2 of 5 days old Not touching package, as requested by freeze (contact debian-release if update is needed) Not considered Depends: baghira kdelibs (not considered) The new kdelibs is actually on its way into testing (missing an m68k build ATM). After that point and once it's 5 days old, it would only need an approval by debian-release to get back in. -- see shy jo signature.asc Description: Digital signature
Re: packages missing from sarge
On Tue, May 10, 2005 at 11:10:10AM +0200, Rene Mayrhofer wrote: Steve Langasek schrieb: If that 2.3.x bug really only affects the newer ( 2.6.8) kernel, why not just get 2.3.x pushed into sarge? Are there any other big issues with it, that weren't in 2.2.x? Some people might certainly like the agressive mode support, or 2.3.1's NAT-T fixes. Personally, 2.2.x is fine for me though --- anything but 2.1.x for me :-) Mainly because 2.3.x causes other openswan boxes to crash in some (reproducable) cases - that's a pretty bad regression from 2.2.0 and I keep bugging upstream with it for at least 3 months. No fix until now, so we can't wait until it will be fixed. I would vote for 2.2.0-4. (or even 2.2.0-5). Because 2.2.3 is no longer in the archive, and resurrecting new binaries via t-p-u gives us even less than the usual protection against breakage caused by a lack of testing. :/ Does that mean that the only way to get the known stable 2.2.0-x back into testing is an upload to unstable with an epoch? I really wouldn't like to go that route if I can avoid it Well, AFAIK openswan has never actually been in testing /before/, so it's not a matter of getting it /back/; but yes, the upshot is that I'm not comfortable adding packages to testing via t-p-u. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Accepted libgimp-perl 2.0.dfsg-5 (powerpc source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 10 May 2005 19:43:03 +0200 Source: libgimp-perl Binary: libgimp-perl Architecture: source powerpc Version: 2.0.dfsg-5 Distribution: unstable Urgency: low Maintainer: Marc 'HE' Brockschmidt [EMAIL PROTECTED] Changed-By: Marc 'HE' Brockschmidt [EMAIL PROTECTED] Description: libgimp-perl - Perl support and plugins for The GIMP Closes: 302734 307856 308390 Changes: libgimp-perl (2.0.dfsg-5) unstable; urgency=low . * debian/rules: + Call Makefile.PL (which calls configure) with an explicit GIMP=/usr/bin/gimp. This creates a valid Gimp/Config.pm and enables scripts to properly work (as they need to start gimp if it isn't there). Thanks for the patch to Marc Glisse [EMAIL PROTECTED], this Closes: #302734, #307856, #308390. + Add a bit of shell code to replace all /opt/bin/perl references with /usr/bin/perl in the examples. A copy is left around to allow make to restore the original files in the clean target. Files: 52336ad58cb744e9b7d84512b0d7e8de 730 perl optional libgimp-perl_2.0.dfsg-5.dsc 873f8f13886d70d6c89069608f310792 5774 perl optional libgimp-perl_2.0.dfsg-5.diff.gz 6be9e9687f8382e2876a5c8693a7730a 394484 perl optional libgimp-perl_2.0.dfsg-5_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iEYEARECAAYFAkKBs6UACgkQmO5zOp3h7rHRgwCghSJ9Blod70UUNJ6g8tx7IKDV Wb4An3cvwUNVux29GaPXPjuf16TtR1P7 =SXDJ -END PGP SIGNATURE- Accepted: libgimp-perl_2.0.dfsg-5.diff.gz to pool/main/libg/libgimp-perl/libgimp-perl_2.0.dfsg-5.diff.gz libgimp-perl_2.0.dfsg-5.dsc to pool/main/libg/libgimp-perl/libgimp-perl_2.0.dfsg-5.dsc libgimp-perl_2.0.dfsg-5_powerpc.deb to pool/main/libg/libgimp-perl/libgimp-perl_2.0.dfsg-5_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted doscan 0.3.1-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 May 2005 09:43:07 +0200 Source: doscan Binary: doscan Architecture: source i386 Version: 0.3.1-1 Distribution: unstable Urgency: low Maintainer: Florian Weimer [EMAIL PROTECTED] Changed-By: Florian Weimer [EMAIL PROTECTED] Description: doscan - port scanner for discovering services on large networks Changes: doscan (0.3.1-1) unstable; urgency=low . * New upstream version Files: f0209320f4080041b78f4ef43f2f2d37 863 net optional doscan_0.3.1-1.dsc 0ea5e557279631937d5928576f214836 129378 net optional doscan_0.3.1.orig.tar.gz 9b4088cffde31e9ebf23f816f09439f1 2612 net optional doscan_0.3.1-1.diff.gz 3101b2ddb5bd2d90e2c61452a44a739f 52924 net optional doscan_0.3.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUBQoG42r97/wQC1SS+AQIAXQf/Xqz7rsM69N1d5Aj8vuuXfQldNcXeRQmN EMtf6aeLELPnk7R16UF5zWPWI98PXkiI+1hrSX7yNQRLNpehA3BG2l3Mw4dz7IFp AV+OZ70lzLMEyKHyX3r94bzL6Vwrs8xKJSgnc9q0ssPIw7RNUhWHf7iBtgLD1xPL mKiLQrr9cUJAWOpnnQOU9IdfJ6/wNZLqLyAGP62oLZeV/zu600c4v7pzf1mBq6Ah rNiLQJyh5ZsWTxhZeFTQjtkE2jiha7gvbnmkM8sAvqPOcn52qbCF/00nx5ySfn8d talTBDAFEI/djduTVA6AKoBJfZrNPrASWQxTDtZYM7YeZe+A9CMPRw== =Jskm -END PGP SIGNATURE- Accepted: doscan_0.3.1-1.diff.gz to pool/main/d/doscan/doscan_0.3.1-1.diff.gz doscan_0.3.1-1.dsc to pool/main/d/doscan/doscan_0.3.1-1.dsc doscan_0.3.1-1_i386.deb to pool/main/d/doscan/doscan_0.3.1-1_i386.deb doscan_0.3.1.orig.tar.gz to pool/main/d/doscan/doscan_0.3.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted nagat 1.0a2-5 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 May 2005 10:21:04 +0200 Source: nagat Binary: nagat Architecture: source all Version: 1.0a2-5 Distribution: unstable Urgency: low Maintainer: Turbo Fredriksson [EMAIL PROTECTED] Changed-By: Turbo Fredriksson [EMAIL PROTECTED] Description: nagat - Nagios Administration Tool Closes: 287332 Changes: nagat (1.0a2-5) unstable; urgency=low . * Reverse check for already included nagat config. * If /etc/$apache/conf.d is a directory, make a link to the nagat config in this directory. Closes: #287332 Files: 8a114d1d68834c61f34b49c4e6456989 598 web extra nagat_1.0a2-5.dsc 4fffba99fc7da99e8031daf4b21b4131 3962 web extra nagat_1.0a2-5.diff.gz 7c9c598b6729b5ab8831457880ab2808 30428 web extra nagat_1.0a2-5_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFCgcCKmlWzPKccHgARAje/AJ9mwDSCwY2xL4qLTLAMSTvzpLmiRACdHJSW 8E6mMYBxq9OVHOlMo/ZqI2w= =kDjs -END PGP SIGNATURE- Accepted: nagat_1.0a2-5.diff.gz to pool/main/n/nagat/nagat_1.0a2-5.diff.gz nagat_1.0a2-5.dsc to pool/main/n/nagat/nagat_1.0a2-5.dsc nagat_1.0a2-5_all.deb to pool/main/n/nagat/nagat_1.0a2-5_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted apache 1.3.33-6 (powerpc all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 May 2005 01:58:54 -0600 Source: apache Binary: apache-dev apache-common apache-doc apache-utils apache apache-dbg apache-perl libapache-mod-perl apache-ssl Architecture: source powerpc all Version: 1.3.33-6 Distribution: unstable Urgency: low Maintainer: Debian Apache Maintainers debian-apache@lists.debian.org Changed-By: Adam Conrad [EMAIL PROTECTED] Description: apache - versatile, high-performance HTTP server apache-common - support files for all Apache webservers apache-dbg - debug versions of the Apache webservers apache-dev - development kit for the Apache webserver apache-doc - documentation for the Apache webserver apache-perl - versatile, high-performance HTTP server with Perl support apache-ssl - versatile, high-performance HTTP server with SSL support apache-utils - utility programs for webservers (transitional package) libapache-mod-perl - integration of perl with the Apache web server Closes: 308548 Changes: apache (1.3.33-6) unstable; urgency=low . * Update fi.po to remove a few dozen unfortunate linefeeds that didn't belong and were breaking debconf (closes: #308548) Files: 46b5b4a196292a9adad499c60fb0842c 1107 web optional apache_1.3.33-6.dsc 58b6e3f69193204d536a3f7e3d0c7b6d 367596 web optional apache_1.3.33-6.diff.gz 00dbd2df2ffd2e6db67d75abb66104d0 1189176 doc optional apache-doc_1.3.33-6_all.deb 5b1a91ef5e5b46155f5f109b3b33593f 331118 devel extra apache-dev_1.3.33-6_all.deb 3a558b1b17f8d883815a2db74ac245bc 211900 web optional apache-utils_1.3.33-6_all.deb b8642f164b0ddc9ab0f0bf8adca09b5f 398402 web optional apache_1.3.33-6_powerpc.deb 68230e4bc18c6ffb3b32bff990ef07f1 510078 web optional apache-ssl_1.3.33-6_powerpc.deb 2a42d3e9430d5873382684ffa5b6ece8 515026 web optional apache-perl_1.3.33-6_powerpc.deb d502bc363b74791ecfdbcd9facca02cf 9267802 devel extra apache-dbg_1.3.33-6_powerpc.deb d65304324b0b33e6c44f4ade91dc3b25 921168 web optional apache-common_1.3.33-6_powerpc.deb e1dc7fac80285d606343f2951d3a6dfd 490370 web optional libapache-mod-perl_1.29.0.3-6_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCgcetvjztR8bOoMkRAur1AJ4qkfpR3cXKwJnQn27Xe0UK7q6WDACaAoy2 VzAFgroEz64FoXbyXNJ4HTA= =WnmF -END PGP SIGNATURE- Accepted: apache-common_1.3.33-6_powerpc.deb to pool/main/a/apache/apache-common_1.3.33-6_powerpc.deb apache-dbg_1.3.33-6_powerpc.deb to pool/main/a/apache/apache-dbg_1.3.33-6_powerpc.deb apache-dev_1.3.33-6_all.deb to pool/main/a/apache/apache-dev_1.3.33-6_all.deb apache-doc_1.3.33-6_all.deb to pool/main/a/apache/apache-doc_1.3.33-6_all.deb apache-perl_1.3.33-6_powerpc.deb to pool/main/a/apache/apache-perl_1.3.33-6_powerpc.deb apache-ssl_1.3.33-6_powerpc.deb to pool/main/a/apache/apache-ssl_1.3.33-6_powerpc.deb apache-utils_1.3.33-6_all.deb to pool/main/a/apache/apache-utils_1.3.33-6_all.deb apache_1.3.33-6.diff.gz to pool/main/a/apache/apache_1.3.33-6.diff.gz apache_1.3.33-6.dsc to pool/main/a/apache/apache_1.3.33-6.dsc apache_1.3.33-6_powerpc.deb to pool/main/a/apache/apache_1.3.33-6_powerpc.deb libapache-mod-perl_1.29.0.3-6_powerpc.deb to pool/main/a/apache/libapache-mod-perl_1.29.0.3-6_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted partman 65 (powerpc source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 May 2005 09:48:56 +0100 Source: partman Binary: partman Architecture: source powerpc Version: 65 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Colin Watson [EMAIL PROTECTED] Description: partman- Partition the storage devices (partman) (udeb) Closes: 308577 Changes: partman (65) unstable; urgency=low . * Colin Watson - Constify 'name' arguments to many functions. - devices[index_of_name(name)] has unspecified results, as index_of_name() may change the devices pointer; this caused parted_server to crash on OPEN when compiled with gcc 4.0. Insert a sequence point to fix this (closes: #308577). * Updated translations: - German (de.po) by Herbert Straub - Greek, Modern (1453-) (el.po) by Kostas Papadimas - Spanish (es.po) by Enrique Matias Sanchez - Portuguese (Brazil) (pt_BR.po) by Carlos Eduardo Pedroza Santiviago - Romanian (ro.po) by Ovidiu Damian - Russian (ru.po) by Yuri Kozlov - Ukrainian (uk.po) by Eugeniy Meshcheryakov Files: 0796accafb7dab9a4bc0cedfdca6d662 640 debian-installer standard partman_65.dsc 4b34cdc193e5385ac95d5351a8e7d1f9 118940 debian-installer standard partman_65.tar.gz a8afa471d12912f095931514ba8eb38b 114508 debian-installer standard partman_65_powerpc.udeb package-type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCgcek9t0zAhD6TNERAp8QAJ4tZSmIEgizPw0eQWZxB7dJZMertwCeLF3R ib9AIPBBKs2N5NPTpIIG7WE= =VxxF -END PGP SIGNATURE- Accepted: partman_65.dsc to pool/main/p/partman/partman_65.dsc partman_65.tar.gz to pool/main/p/partman/partman_65.tar.gz partman_65_powerpc.udeb to pool/main/p/partman/partman_65_powerpc.udeb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnome-libs 1.4.2-20 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 May 2005 10:59:29 +0200 Source: gnome-libs Binary: libart2 libgnomesupport0 libgnomeui32 libgtkxmhtml-dev gnome-dev-doc libgnorbagtk0 libgtkxmhtml1 libgnorba-dev gnome-libs-data libgnorba27 libzvt-dev libzvt2 gnome-bin libart-dev libgnome32 libgnome-dev Architecture: source i386 all Version: 1.4.2-20 Distribution: unstable Urgency: low Maintainer: Debian GNOME Maintainers [EMAIL PROTECTED] Changed-By: Sebastien Bacher [EMAIL PROTECTED] Description: gnome-bin - Miscellaneous binaries used by GNOME gnome-dev-doc - GNOME developers documentation gnome-libs-data - Data for GNOME libraries libart-dev - The GNOME canvas widget - development files libart2- The GNOME canvas widget - runtime files libgnome-dev - The GNOME libraries -- development package libgnome32 - The GNOME libraries libgnomesupport0 - The GNOME libraries (Support libraries) libgnomeui32 - The GNOME libraries (User Interface) libgnorba-dev - GNOME CORBA services -- development package libgnorba27 - GNOME CORBA services libgnorbagtk0 - GNOME CORBA services (Gtk bindings) libgtkxmhtml-dev - The GNOME gtkxmhtml (HTML) widget -- development package libgtkxmhtml1 - The GNOME gtkxmhtml (HTML) widget libzvt-dev - The GNOME zvt (zterm) widget -- development package libzvt2- The GNOME zvt (zterm) widget Closes: 286873 Changes: gnome-libs (1.4.2-20) unstable; urgency=low . * gtk-xmhtml/XmHTMLI.h: - patch from Andreas Jochens [EMAIL PROTECTED] to fix the build with gcc4 (Closes: #286873). Files: 832646b689393f1586cf4fb8686ce83b 1928 oldlibs optional gnome-libs_1.4.2-20.dsc 3d928c6a5c1b9ada381561cd1ee5a6fa 22471 oldlibs optional gnome-libs_1.4.2-20.diff.gz f8317b426171e6b2babc2d7e33c0c1d0 308686 gnome optional gnome-libs-data_1.4.2-20_all.deb 3afc833434140f47c7a6accdbf9d10b3 519556 doc optional gnome-dev-doc_1.4.2-20_all.deb 376d3285dbc1c4f95d70b0c382d2e69b 80864 oldlibs optional libgnome32_1.4.2-20_i386.deb a170accd659b050631c8b68b9f195000 452096 oldlibs optional libgnomeui32_1.4.2-20_i386.deb 575cb78596600a52e2b96413921142a8 25684 oldlibs optional libgnomesupport0_1.4.2-20_i386.deb b6589d20195e58cca448c648ca07b3e3 591358 libdevel optional libgnome-dev_1.4.2-20_i386.deb b193942d52c695a13eaeca1d65f6634c 49488 oldlibs optional libart2_1.4.2-20_i386.deb db1d1daa3f293a491a34a444a34bcfa6 46504 libdevel optional libart-dev_1.4.2-20_i386.deb dad467a48929631f491e2e796e6d9ff8 55102 oldlibs optional libgnorba27_1.4.2-20_i386.deb 7e8850095f34a2d96716cad89aa83521 45038 oldlibs optional libgnorbagtk0_1.4.2-20_i386.deb c22ee4c68d0597b46e3429e3dee9435e 36724 libdevel optional libgnorba-dev_1.4.2-20_i386.deb f51dad8b017aa6e35f5f6c7aa62c7193 98106 oldlibs optional libzvt2_1.4.2-20_i386.deb c42a22c9ae562d64b0154eaca85d655b 51692 libdevel optional libzvt-dev_1.4.2-20_i386.deb ce1c79ac99eece9435ab15da38fd4aad 189660 oldlibs optional libgtkxmhtml1_1.4.2-20_i386.deb 7078744da9123b1ac8e95e8a7286c95a 249796 libdevel optional libgtkxmhtml-dev_1.4.2-20_i386.deb 86a0dc8e3934a1827550ff8b2bad42d6 94854 gnome optional gnome-bin_1.4.2-20_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCgcs/Qxo87aLX0pIRAkY5AJsFhGq9JQr7vbanAEePuAjx64cC5gCfejrk zM3Kinr+9UmtndOejMIK5RY= =J2d6 -END PGP SIGNATURE- Accepted: gnome-bin_1.4.2-20_i386.deb to pool/main/g/gnome-libs/gnome-bin_1.4.2-20_i386.deb gnome-dev-doc_1.4.2-20_all.deb to pool/main/g/gnome-libs/gnome-dev-doc_1.4.2-20_all.deb gnome-libs-data_1.4.2-20_all.deb to pool/main/g/gnome-libs/gnome-libs-data_1.4.2-20_all.deb gnome-libs_1.4.2-20.diff.gz to pool/main/g/gnome-libs/gnome-libs_1.4.2-20.diff.gz gnome-libs_1.4.2-20.dsc to pool/main/g/gnome-libs/gnome-libs_1.4.2-20.dsc libart-dev_1.4.2-20_i386.deb to pool/main/g/gnome-libs/libart-dev_1.4.2-20_i386.deb libart2_1.4.2-20_i386.deb to pool/main/g/gnome-libs/libart2_1.4.2-20_i386.deb libgnome-dev_1.4.2-20_i386.deb to pool/main/g/gnome-libs/libgnome-dev_1.4.2-20_i386.deb libgnome32_1.4.2-20_i386.deb to pool/main/g/gnome-libs/libgnome32_1.4.2-20_i386.deb libgnomesupport0_1.4.2-20_i386.deb to pool/main/g/gnome-libs/libgnomesupport0_1.4.2-20_i386.deb libgnomeui32_1.4.2-20_i386.deb to pool/main/g/gnome-libs/libgnomeui32_1.4.2-20_i386.deb libgnorba-dev_1.4.2-20_i386.deb to pool/main/g/gnome-libs/libgnorba-dev_1.4.2-20_i386.deb libgnorba27_1.4.2-20_i386.deb to pool/main/g/gnome-libs/libgnorba27_1.4.2-20_i386.deb libgnorbagtk0_1.4.2-20_i386.deb to pool/main/g/gnome-libs/libgnorbagtk0_1.4.2-20_i386.deb libgtkxmhtml-dev_1.4.2-20_i386.deb to pool/main/g/gnome-libs/libgtkxmhtml-dev_1.4.2-20_i386.deb libgtkxmhtml1_1.4.2-20_i386.deb to pool/main/g/gnome-libs/libgtkxmhtml1_1.4.2-20_i386.deb libzvt-dev_1.4.2-20_i386.deb to pool/main/g/gnome-libs/libzvt-dev_1.4.2-20_i386.deb libzvt2_1.4.2-20_i386.deb to pool/main/g/gnome-libs/libzvt2_1.4.2-20_i386.deb -- To UNSUBSCRIBE, email to
Accepted gambit 0.97.0.7-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 4 May 2005 18:28:16 +0200 Source: gambit Binary: gambit Architecture: source i386 Version: 0.97.0.7-1 Distribution: unstable Urgency: low Maintainer: Peter van Rossum [EMAIL PROTECTED] Changed-By: Peter van Rossum [EMAIL PROTECTED] Description: gambit - Game theory analysis software and tools Closes: 227262 Changes: gambit (0.97.0.7-1) unstable; urgency=low . * New upstream release, released 15 Oct 2004. (Closes: #227262 on edit game segfault; closes #268445 on FTBFS with gcc 3.4) Files: 94eaeda83483fef4b4f0e7f674c6ba1b 588 math optional gambit_0.97.0.7-1.dsc cbdc41473214155d046afcd3b5dd78d2 870379 math optional gambit_0.97.0.7.orig.tar.gz 0380d9dc1cbcade12cdb34062f344f33 25145 math optional gambit_0.97.0.7-1.diff.gz 0866e703b6d7ef86c8f1bd40e2a578d2 3464672 math optional gambit_0.97.0.7-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCgeu1Yj5J4IdrJS8RAlE7AJ0aVkdkboGhqVj+ZlHxSJ6QoZxaFwCggqf7 GjCr1mQsXwUCHYqsnFAevXQ= =9JzO -END PGP SIGNATURE- Accepted: gambit_0.97.0.7-1.diff.gz to pool/main/g/gambit/gambit_0.97.0.7-1.diff.gz gambit_0.97.0.7-1.dsc to pool/main/g/gambit/gambit_0.97.0.7-1.dsc gambit_0.97.0.7-1_i386.deb to pool/main/g/gambit/gambit_0.97.0.7-1_i386.deb gambit_0.97.0.7.orig.tar.gz to pool/main/g/gambit/gambit_0.97.0.7.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted quotatool 1.4.7-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 May 2005 11:24:21 +0200 Source: quotatool Binary: quotatool Architecture: source i386 Version: 1.4.7-1 Distribution: unstable Urgency: high Maintainer: Bas Zoetekouw [EMAIL PROTECTED] Changed-By: Bas Zoetekouw [EMAIL PROTECTED] Description: quotatool - tool to edit disk quotas from the command line Closes: 258289 289812 Changes: quotatool (1.4.7-1) unstable; urgency=high . * New upstream release - correctly detect XFS-enabled kernels (closes: #258289, #289812) - correctly display kBs instead of blocks in some cases * Boosted Standards-Version to 3.6.1 (no changes needed) Files: fed35e035ab6c637b3e240b3c03ea505 580 admin extra quotatool_1.4.7-1.dsc 78969d1f52f94aad40336faa4a3d28de 113102 admin extra quotatool_1.4.7.orig.tar.gz f54117b6375cd0798be76f1af3f609f5 2269 admin extra quotatool_1.4.7-1.diff.gz 53bd5a5e32c541a78d455cb0ceaa60c0 16900 admin extra quotatool_1.4.7-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCgdHGK67kHwZE+rcRAtnbAJ9qM+4nV6ux2T7IykcwNqwv29rCFACgglDM RwY7g33kmiSuGKSgRlIYLmI= =ZgY/ -END PGP SIGNATURE- Accepted: quotatool_1.4.7-1.diff.gz to pool/main/q/quotatool/quotatool_1.4.7-1.diff.gz quotatool_1.4.7-1.dsc to pool/main/q/quotatool/quotatool_1.4.7-1.dsc quotatool_1.4.7-1_i386.deb to pool/main/q/quotatool/quotatool_1.4.7-1_i386.deb quotatool_1.4.7.orig.tar.gz to pool/main/q/quotatool/quotatool_1.4.7.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gip 1.4.0.1-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 6 May 2005 22:18:37 +0200 Source: gip Binary: gip Architecture: source i386 Version: 1.4.0.1-1 Distribution: unstable Urgency: low Maintainer: Khalid El Fathi [EMAIL PROTECTED] Changed-By: Khalid El Fathi [EMAIL PROTECTED] Description: gip- IP calculator for GNOME desktop environment Changes: gip (1.4.0.1-1) unstable; urgency=low . * New upstream release. * No new features, it's only compiles with gtkmm-2.4 now. Files: de2ab5866cde60dfbc56df13b41cbfd1 582 gnome optional gip_1.4.0.1-1.dsc e89365c9f2a2074e727d747f93f70aa2 49538 gnome optional gip_1.4.0.1.orig.tar.gz c6289194c055c2fd92ca7f074d2bf1e9 3192 gnome optional gip_1.4.0.1-1.diff.gz fbc9775d6169ed0b4e063531f873ef5e 116130 gnome optional gip_1.4.0.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCgdr9w3ao2vG823MRAqFKAJ49GhpUVceVWGbbCXxbUSd6D6LIkgCgiPz/ D4tvApa2n+dVMfS4PXgQC/0= =cqK/ -END PGP SIGNATURE- Accepted: gip_1.4.0.1-1.diff.gz to pool/main/g/gip/gip_1.4.0.1-1.diff.gz gip_1.4.0.1-1.dsc to pool/main/g/gip/gip_1.4.0.1-1.dsc gip_1.4.0.1-1_i386.deb to pool/main/g/gip/gip_1.4.0.1-1_i386.deb gip_1.4.0.1.orig.tar.gz to pool/main/g/gip/gip_1.4.0.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linuxlogo 4.12-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 5 May 2005 17:23:27 +0200 Source: linuxlogo Binary: linuxlogo Architecture: source i386 Version: 4.12-1 Distribution: unstable Urgency: low Maintainer: Khalid El Fathi [EMAIL PROTECTED] Changed-By: Khalid El Fathi [EMAIL PROTECTED] Description: linuxlogo - Color ANSI System Logo Closes: 292741 305502 Changes: linuxlogo (4.12-1) unstable; urgency=low . * New upstream release * Bug fix: Preinst not compatible with file-rc (Closes: #292741). * Added patch Correct name of Danish translation and update translation, thanks to Claus Hindsgaul [EMAIL PROTECTED] (Closes: #305502). Files: 7401894e56176d6624b65c5fb529b70f 579 misc extra linuxlogo_4.12-1.dsc 3c59c4c332d611503a1d2e3663736966 90222 misc extra linuxlogo_4.12.orig.tar.gz cca88338e3535364926bd4c5f631419b 13102 misc extra linuxlogo_4.12-1.diff.gz bc70076ec3a6bae2f8fa4dbeca2aff48 59646 misc extra linuxlogo_4.12-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCgd2Gw3ao2vG823MRAnNCAJsEexXtzr+A18iCzbUTtCmYIPBHiACfYh2B BauduBcl71/AiDqMW26L1yU= =HK57 -END PGP SIGNATURE- Accepted: linuxlogo_4.12-1.diff.gz to pool/main/l/linuxlogo/linuxlogo_4.12-1.diff.gz linuxlogo_4.12-1.dsc to pool/main/l/linuxlogo/linuxlogo_4.12-1.dsc linuxlogo_4.12-1_i386.deb to pool/main/l/linuxlogo/linuxlogo_4.12-1_i386.deb linuxlogo_4.12.orig.tar.gz to pool/main/l/linuxlogo/linuxlogo_4.12.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted quota 3.12-6 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 May 2005 12:29:13 +0200 Source: quota Binary: quota Architecture: source i386 Version: 3.12-6 Distribution: unstable Urgency: medium Maintainer: Michael Meskes [EMAIL PROTECTED] Changed-By: Michael Meskes [EMAIL PROTECTED] Description: quota - implementation of the disk quota system Changes: quota (3.12-6) unstable; urgency=medium . * Removed patch file that I accidently left in the source tree * Removed non-doc CVS patches that shouldn't have been in -5 anyway * Removed update-inetd call completely * Added patch to set of grace time only after exceeding soft limit, not at reaching * Added small patch from CVS to fix memory leak in rquotad Files: d963898244497e8a1419fa96ee37e6be 613 admin optional quota_3.12-6.dsc f4669969daaa40bae76449c947cb8276 29823 admin optional quota_3.12-6.diff.gz 0e9cdc1de6305dbb5159e14dba808c7f 419002 admin optional quota_3.12-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCgd6WVkEm8inxm9ERAnBsAJ9zcfoEtvd547bsKV5cVTOg4Dbl0wCePkLR aIJGq2dEBAtMmgVqYwndQXQ= =UW1Q -END PGP SIGNATURE- Accepted: quota_3.12-6.diff.gz to pool/main/q/quota/quota_3.12-6.diff.gz quota_3.12-6.dsc to pool/main/q/quota/quota_3.12-6.dsc quota_3.12-6_i386.deb to pool/main/q/quota/quota_3.12-6_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted nagat 1.0a2-6 (all source)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 11 May 2005 11:58:01 +0200
Source: nagat
Binary: nagat
Architecture: source all
Version: 1.0a2-6
Distribution: unstable
Urgency: low
Maintainer: Turbo Fredriksson [EMAIL PROTECTED]
Changed-By: Turbo Fredriksson [EMAIL PROTECTED]
Description:
nagat - Nagios Administration Tool
Closes: 272726
Changes:
nagat (1.0a2-6) unstable; urgency=low
.
* Install '/etc/nagios/nagat{cfg,objs}.dat' (as www-data/640).
Closes: #272726
Files:
0a3c78c5ee5dabfd89a97ae5a0d1584d 598 web extra nagat_1.0a2-6.dsc
8f1e3644397fe13318acc23d987211ff 4103 web extra nagat_1.0a2-6.diff.gz
173bc40f91cbc34626a3c799cb1b1ab9 30558 web extra nagat_1.0a2-6_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQFCgdjZmlWzPKccHgARAn0eAJ4u/2iR7W7j1+8/SWJ2uUDuiRYM1wCeNSZL
JdwmKrhHPIxGeNqY6wM=
=jnPK
-END PGP SIGNATURE-
Accepted:
nagat_1.0a2-6.diff.gz
to pool/main/n/nagat/nagat_1.0a2-6.diff.gz
nagat_1.0a2-6.dsc
to pool/main/n/nagat/nagat_1.0a2-6.dsc
nagat_1.0a2-6_all.deb
to pool/main/n/nagat/nagat_1.0a2-6_all.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted autofs 4.1.3+4.1.4beta2-8 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 May 2005 13:38:41 +0200 Source: autofs Binary: autofs-hesiod autofs-ldap autofs Architecture: i386 source Version: 4.1.3+4.1.4beta2-8 Distribution: unstable Urgency: medium Maintainer: Steinar H. Gunderson [EMAIL PROTECTED] Changed-By: Steinar H. Gunderson [EMAIL PROTECTED] Description: autofs - kernel-based automounter for Linux autofs-hesiod - Hesiod map support for autofs autofs-ldap - LDAP map support for autofs Closes: 297359 304245 Changes: autofs (4.1.3+4.1.4beta2-8) unstable; urgency=medium . * Last upload for sarge, with one last patch. urgency=medium as requested by the release team. * 060_non_replicated_ping: New patch, backport from autofs 4.1.4 final by Daniel Andre Vaquero. Fixes problems with NFS mounts failing, and replicated hosts not working. (Closes: #297359, #304245) Files: 2228e99ee310fb6e51ba1240adf46ea6 34377 utils extra autofs_4.1.3+4.1.4beta2-8.diff.gz 420b381b701710ff3efed6108b558806 24182 utils extra autofs-hesiod_4.1.3+4.1.4beta2-8_i386.deb c88520c19be296184089541134678bd5 673 utils extra autofs_4.1.3+4.1.4beta2-8.dsc d62e9107f8cd1c98f8269e6753a77b00 36242 utils extra autofs-ldap_4.1.3+4.1.4beta2-8_i386.deb d8c860bbac757528b1582fd13dfcdf98 106652 utils extra autofs_4.1.3+4.1.4beta2-8_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCgfBaXKRQ3lK3SH4RAku3AKCeVabPPd6SUMLBRWBV4USrTw4GXgCfceDy aj2TkgKtcLEejWSHFyQVBh4= =vU7x -END PGP SIGNATURE- Accepted: autofs-hesiod_4.1.3+4.1.4beta2-8_i386.deb to pool/main/a/autofs/autofs-hesiod_4.1.3+4.1.4beta2-8_i386.deb autofs-ldap_4.1.3+4.1.4beta2-8_i386.deb to pool/main/a/autofs/autofs-ldap_4.1.3+4.1.4beta2-8_i386.deb autofs_4.1.3+4.1.4beta2-8.diff.gz to pool/main/a/autofs/autofs_4.1.3+4.1.4beta2-8.diff.gz autofs_4.1.3+4.1.4beta2-8.dsc to pool/main/a/autofs/autofs_4.1.3+4.1.4beta2-8.dsc autofs_4.1.3+4.1.4beta2-8_i386.deb to pool/main/a/autofs/autofs_4.1.3+4.1.4beta2-8_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted calamaris 2.59-5 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 May 2005 14:20:13 +0200 Source: calamaris Binary: calamaris Architecture: source all Version: 2.59-5 Distribution: unstable Urgency: low Maintainer: Philipp Frauenfelder [EMAIL PROTECTED] Changed-By: Philipp Frauenfelder [EMAIL PROTECTED] Description: calamaris - log analyzer for Squid or Oops proxy log files Closes: 307994 308165 308214 308348 308430 Changes: calamaris (2.59-5) unstable; urgency=low . * Corrected typo in debconf template and updated translations accordingly. Closes: #307994, #308165, #308214, #308348, #308430 Files: 19d47b219e14e72e7072bd3782528ecd 603 utils optional calamaris_2.59-5.dsc 2719307aca954369f752bd10323d1469 17034 utils optional calamaris_2.59-5.diff.gz 344437915affbd33738ad4fe509b7762 68240 utils optional calamaris_2.59-5_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCgfj2WLF0MZ2lytgRAg1hAJ9OGtV3UJToiYNeHVgqkRgPB/ChTACfVmBe VvUjoqn69FgqGKjxvJKg/ug= =ARuE -END PGP SIGNATURE- Accepted: calamaris_2.59-5.diff.gz to pool/main/c/calamaris/calamaris_2.59-5.diff.gz calamaris_2.59-5.dsc to pool/main/c/calamaris/calamaris_2.59-5.dsc calamaris_2.59-5_all.deb to pool/main/c/calamaris/calamaris_2.59-5_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gjots2 2.1.1-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 10 May 2005 14:28:22 +0200 Source: gjots2 Binary: gjots2 Architecture: source i386 Version: 2.1.1-3 Distribution: unstable Urgency: low Maintainer: Khalid El Fathi [EMAIL PROTECTED] Changed-By: Khalid El Fathi [EMAIL PROTECTED] Description: gjots2 - A simple jotter (outline processor) for X11/gtk-gnome Closes: 306402 Changes: gjots2 (2.1.1-3) unstable; urgency=low . * Bug fix: Missing deps on mpage for printing (Closes: bug#306402). * Forwarded patch upstream: replaces option -seascape (which is not recognized) by option --orientation=seascape. Files: 9b90602198838adbc4916198738efd4f 583 gnome optional gjots2_2.1.1-3.dsc bd5418336c9b3e4fd99cbecab13bb860 3123 gnome optional gjots2_2.1.1-3.diff.gz b887b2bcd2f6236e8784488f0eb30052 66952 gnome optional gjots2_2.1.1-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCgfmow3ao2vG823MRAoHMAJ4oGX9WOV1QKYzFHgVOsUTbgvxSvACfRycP dKbIKIKQXn/QmUFo1Tx6wzs= =mgDq -END PGP SIGNATURE- Accepted: gjots2_2.1.1-3.diff.gz to pool/main/g/gjots2/gjots2_2.1.1-3.diff.gz gjots2_2.1.1-3.dsc to pool/main/g/gjots2/gjots2_2.1.1-3.dsc gjots2_2.1.1-3_i386.deb to pool/main/g/gjots2/gjots2_2.1.1-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted alsa-lib 1.0.8+1.0.9rc3-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 May 2005 13:32:05 +0200 Source: alsa-lib Binary: libasound2-dev libasound2-doc libasound2 Architecture: source all i386 Version: 1.0.8+1.0.9rc3-1 Distribution: experimental Urgency: low Maintainer: Jordi Mallach [EMAIL PROTECTED] Changed-By: Jordi Mallach [EMAIL PROTECTED] Description: libasound2 - ALSA library libasound2-dev - ALSA library development files libasound2-doc - ALSA library developer documentation Closes: 291533 293928 299423 300792 Changes: alsa-lib (1.0.8+1.0.9rc3-1) experimental; urgency=low . * New upstream release - Closes: #291533 ttable in .asoundrc do not accept fractions - Closes: #293928 wrong routings of channels for 5.1 ICH5 - Closes: #299423 Please include asound_fm.h - Closes: #300792 FTBFS (ppc64/gcc-4.0): static declaration ... - libasound2-plugins is no longer built from this source package * Thomas Hood - Remove the control entry, commands in rules, build dependencies related to libasound2-plugins - Add some mutual Suggestions among the ALSA library packages - Drop dpatch applied upstream: 10_conf-space-fix - debian/NOTES: + Add note about what to do if we ever have libasound3 + Remove note about building libasound2-plugins - Tweak descriptions Files: b0e0a7beb2baba793bee22b04f28fa76 849 libs optional alsa-lib_1.0.8+1.0.9rc3-1.dsc 20b950e68dfb0eb355f5c0817c98577e 956199 libs optional alsa-lib_1.0.8+1.0.9rc3.orig.tar.gz 18c37cfd7e5ffb2329990b2ab5a35432 12560 libs optional alsa-lib_1.0.8+1.0.9rc3-1.diff.gz d15443217b0aaccda3cf9e53fb17dd69 321282 libs optional libasound2_1.0.8+1.0.9rc3-1_i386.deb 8702e67153965ce9c1b0b9200a51f427 460290 libdevel optional libasound2-dev_1.0.8+1.0.9rc3-1_i386.deb 93e9cb5a6a72adf6be15ccbe939661cf 462820 libdevel optional libasound2-doc_1.0.8+1.0.9rc3-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCgf2tJYSUupF6Il4RAit3AKDGdwRGHUH1mBpbz2rrL0lP8t+GxQCg8IZ+ I8/XD5lwtE6DteBPdSHiikU= =gQaP -END PGP SIGNATURE- Accepted: alsa-lib_1.0.8+1.0.9rc3-1.diff.gz to pool/main/a/alsa-lib/alsa-lib_1.0.8+1.0.9rc3-1.diff.gz alsa-lib_1.0.8+1.0.9rc3-1.dsc to pool/main/a/alsa-lib/alsa-lib_1.0.8+1.0.9rc3-1.dsc alsa-lib_1.0.8+1.0.9rc3.orig.tar.gz to pool/main/a/alsa-lib/alsa-lib_1.0.8+1.0.9rc3.orig.tar.gz libasound2-dev_1.0.8+1.0.9rc3-1_i386.deb to pool/main/a/alsa-lib/libasound2-dev_1.0.8+1.0.9rc3-1_i386.deb libasound2-doc_1.0.8+1.0.9rc3-1_all.deb to pool/main/a/alsa-lib/libasound2-doc_1.0.8+1.0.9rc3-1_all.deb libasound2_1.0.8+1.0.9rc3-1_i386.deb to pool/main/a/alsa-lib/libasound2_1.0.8+1.0.9rc3-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted lablgtk2 2.4.0+2005.02.18-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 May 2005 13:50:00 +0200 Source: lablgtk2 Binary: liblablgtk2-gnome-ocaml-dev liblablgtk2-ocaml liblablgtk2-ocaml-dev liblablgtk2-gnome-ocaml Architecture: source i386 Version: 2.4.0+2005.02.18-3 Distribution: unstable Urgency: low Maintainer: Debian OCaml Maintainers debian-ocaml-maint@lists.debian.org Changed-By: Samuel Mimram [EMAIL PROTECTED] Description: liblablgtk2-gnome-ocaml - runtime libraries for OCaml bindings to Gnome liblablgtk2-gnome-ocaml-dev - OCaml bindings to Gnome liblablgtk2-ocaml - runtime libraries for OCaml bindings for Gtk+ version 2 liblablgtk2-ocaml-dev - OCaml bindings to Gtk+ version 2 Closes: 308567 Changes: lablgtk2 (2.4.0+2005.02.18-3) unstable; urgency=low . * Put wildcards in liblablgtk2-gnome-ocaml-dev.files in order not to install native files if they are not present, closes: #308567. Files: d73edd31eaf960e563cf7a563b335612 1037 libdevel optional lablgtk2_2.4.0+2005.02.18-3.dsc 272d865c23b1f811169f3528320969aa 5533 libdevel optional lablgtk2_2.4.0+2005.02.18-3.diff.gz 8e4fd0b58f310646b2d21cdb339cb098 128754 libs optional liblablgtk2-ocaml_2.4.0+2005.02.18-3_i386.deb 107df7e79e66e351bf148e39a3fd2539 37162 libs optional liblablgtk2-gnome-ocaml_2.4.0+2005.02.18-3_i386.deb 89bd722976ec47daff3be2cfcbb07cf3 2157354 libdevel optional liblablgtk2-ocaml-dev_2.4.0+2005.02.18-3_i386.deb 8b141c1f37500f96096e3c1412b5e4b2 200716 libdevel optional liblablgtk2-gnome-ocaml-dev_2.4.0+2005.02.18-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCgfJwIae1O4AJae8RAsl0AJ4iszshs3bz1VGks3CndXXuESAwdQCcC6eB KS9BQv1r9C3uyK7LcZLUEeQ= =9CNu -END PGP SIGNATURE- Accepted: lablgtk2_2.4.0+2005.02.18-3.diff.gz to pool/main/l/lablgtk2/lablgtk2_2.4.0+2005.02.18-3.diff.gz lablgtk2_2.4.0+2005.02.18-3.dsc to pool/main/l/lablgtk2/lablgtk2_2.4.0+2005.02.18-3.dsc liblablgtk2-gnome-ocaml-dev_2.4.0+2005.02.18-3_i386.deb to pool/main/l/lablgtk2/liblablgtk2-gnome-ocaml-dev_2.4.0+2005.02.18-3_i386.deb liblablgtk2-gnome-ocaml_2.4.0+2005.02.18-3_i386.deb to pool/main/l/lablgtk2/liblablgtk2-gnome-ocaml_2.4.0+2005.02.18-3_i386.deb liblablgtk2-ocaml-dev_2.4.0+2005.02.18-3_i386.deb to pool/main/l/lablgtk2/liblablgtk2-ocaml-dev_2.4.0+2005.02.18-3_i386.deb liblablgtk2-ocaml_2.4.0+2005.02.18-3_i386.deb to pool/main/l/lablgtk2/liblablgtk2-ocaml_2.4.0+2005.02.18-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted zope-tinytableplus 0.9-4 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 May 2005 14:13:26 +0200 Source: zope-tinytableplus Binary: zope-tinytable zope-tinytableplus Architecture: source all Version: 0.9-4 Distribution: unstable Urgency: low Maintainer: Jonas Meurer [EMAIL PROTECTED] Changed-By: Jonas Meurer [EMAIL PROTECTED] Description: zope-tinytable - Present tabular data in Zope (transitional package) zope-tinytableplus - Present tabular data in Zope Changes: zope-tinytableplus (0.9-4) unstable; urgency=low . * hijacked zope-tinytable with maintainer request * added empty zope-tinytable dummy package for transitional purposes Files: 01acd25e442ae6c4148ad21383d46562 620 web extra zope-tinytableplus_0.9-4.dsc ea5b18953ff70e57f99cd2435218ba36 3240 web extra zope-tinytableplus_0.9-4.diff.gz 47eb7a7c425c132d49872cf62f61b399 22362 web extra zope-tinytableplus_0.9-4_all.deb c62aa4f9cd6d7b0b338c6489dadcf072 2560 web extra zope-tinytable_0.9-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCggLcd6lUs+JfIQIRAhgHAJwLN5zu/Tgs7VSJclIheT28SXlnQQCeOjXV CivasRuvQartizJLuzlVi6g= =qe2M -END PGP SIGNATURE- Accepted: zope-tinytable_0.9-4_all.deb to pool/main/z/zope-tinytableplus/zope-tinytable_0.9-4_all.deb zope-tinytableplus_0.9-4.diff.gz to pool/main/z/zope-tinytableplus/zope-tinytableplus_0.9-4.diff.gz zope-tinytableplus_0.9-4.dsc to pool/main/z/zope-tinytableplus/zope-tinytableplus_0.9-4.dsc zope-tinytableplus_0.9-4_all.deb to pool/main/z/zope-tinytableplus/zope-tinytableplus_0.9-4_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted clalsadrv 1.0.1-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 8 Apr 2005 22:55:07 +0200 Source: clalsadrv Binary: libclalsadrv libclalsadrv-dev Architecture: source i386 Version: 1.0.1-1 Distribution: unstable Urgency: low Maintainer: Free Ekanayaka [EMAIL PROTECTED] Changed-By: Free Ekanayaka [EMAIL PROTECTED] Description: libclalsadrv - ALSA driver C++ access library libclalsadrv-dev - Development file for libclalsadrv Changes: clalsadrv (1.0.1-1) unstable; urgency=low . * New upstream release * Fixed watch file Files: 7f83ef54e3efc862c13be5a949135878 614 - optional clalsadrv_1.0.1-1.dsc 2f693c52173aac55dcb35dcfca79df91 13155 - optional clalsadrv_1.0.1.orig.tar.gz 18554222fff3a3ee1c085634d57cf764 2993 - optional clalsadrv_1.0.1-1.diff.gz b98b417d7f43e1a72d6b8ed722890c60 10602 devel optional libclalsadrv-dev_1.0.1-1_i386.deb 84fc519960496a6db9fefc2b3572a1ec 10514 libs optional libclalsadrv_1.0.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCf9W/h0XdeHWCwhoRAv8cAKCLe/RSUnDhyLtvF4DQ7lpRPXyrjACfVnoG /juIGPxL/cs2AfiGhfHRcdQ= =x07s -END PGP SIGNATURE- Accepted: clalsadrv_1.0.1-1.diff.gz to pool/main/c/clalsadrv/clalsadrv_1.0.1-1.diff.gz clalsadrv_1.0.1-1.dsc to pool/main/c/clalsadrv/clalsadrv_1.0.1-1.dsc clalsadrv_1.0.1.orig.tar.gz to pool/main/c/clalsadrv/clalsadrv_1.0.1.orig.tar.gz libclalsadrv-dev_1.0.1-1_i386.deb to pool/main/c/clalsadrv/libclalsadrv-dev_1.0.1-1_i386.deb libclalsadrv_1.0.1-1_i386.deb to pool/main/c/clalsadrv/libclalsadrv_1.0.1-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libpam-mount 0.9.23-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 10 May 2005 18:37:19 +0200 Source: libpam-mount Binary: libpam-mount Architecture: source i386 Version: 0.9.23-1 Distribution: unstable Urgency: low Maintainer: Bastian Kleineidam [EMAIL PROTECTED] Changed-By: Bastian Kleineidam [EMAIL PROTECTED] Description: libpam-mount - a PAM module that can mount volumes for a user session Changes: libpam-mount (0.9.23-1) unstable; urgency=low . * New upstream release. * Improved documentation in README.Debian and pam_mount.conf for encrypted loopback mounts. Files: 25b8b57f192fcd07f1ec39ef92bc0d2f 669 admin extra libpam-mount_0.9.23-1.dsc bd6fdd953495d8661036f72e177aa0c2 416543 admin extra libpam-mount_0.9.23.orig.tar.gz 07cd9e60b2a8283dc661445d188485c1 53560 admin extra libpam-mount_0.9.23-1.diff.gz 8f91c746ca664b456335695981de847c 104056 admin extra libpam-mount_0.9.23-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCggYQeBwlBDLsbz4RApyPAKDCLLIEXo4oL0CMtvslyR6S5WmicACfbO6j bnfu6g81TMovA0AF7c2Xmlk= =IMKR -END PGP SIGNATURE- Accepted: libpam-mount_0.9.23-1.diff.gz to pool/main/libp/libpam-mount/libpam-mount_0.9.23-1.diff.gz libpam-mount_0.9.23-1.dsc to pool/main/libp/libpam-mount/libpam-mount_0.9.23-1.dsc libpam-mount_0.9.23-1_i386.deb to pool/main/libp/libpam-mount/libpam-mount_0.9.23-1_i386.deb libpam-mount_0.9.23.orig.tar.gz to pool/main/libp/libpam-mount/libpam-mount_0.9.23.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gaim 1:1.3.0-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Format: 1.7 Date: Wed, 11 May 2005 09:44:03 -0400 Source: gaim Binary: gaim gaim-dev gaim-data Architecture: source i386 all Version: 1:1.3.0-1 Distribution: unstable Urgency: high Maintainer: Robert McQueen [EMAIL PROTECTED] Changed-By: Ari Pollak [EMAIL PROTECTED] Description: gaim - multi-protocol instant messaging client gaim-data - multi-protocol instant messaging client - data files gaim-dev - multi-protocol instant messaging client - development files Changes: gaim (1:1.3.0-1) unstable; urgency=high . * New upstream version. Fixes two remote DoS/overflow security bugs, CAN-2005-1262 and CAN-2005-1261. Files: 0aab554b7932fe03e9b1c7b43b22b44b 916 net optional gaim_1.3.0-1.dsc 9edb44790e6b13c816f486dc62d87058 5347248 net optional gaim_1.3.0.orig.tar.gz a3c3fd8a64fbf72b5fe81d8b31107975 28046 net optional gaim_1.3.0-1.diff.gz 7559fcea42956a310f47027782547e71 2927952 net optional gaim-data_1.3.0-1_all.deb 2eb2f2a4d0e3124d7d4cf916ced8350c 884936 net optional gaim_1.3.0-1_i386.deb 0fb391fb9151c45edf6f6616dd79ea78 102732 devel optional gaim-dev_1.3.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCgg6CwO+u47cOQDsRA2vkAJ0RxNrgj6zGyle2nS8El96x2f3UCQCfdSe/ lIAeB4D8HBvlXswvyYEqlZo= =uwnL -END PGP SIGNATURE- Accepted: gaim-data_1.3.0-1_all.deb to pool/main/g/gaim/gaim-data_1.3.0-1_all.deb gaim-dev_1.3.0-1_i386.deb to pool/main/g/gaim/gaim-dev_1.3.0-1_i386.deb gaim_1.3.0-1.diff.gz to pool/main/g/gaim/gaim_1.3.0-1.diff.gz gaim_1.3.0-1.dsc to pool/main/g/gaim/gaim_1.3.0-1.dsc gaim_1.3.0-1_i386.deb to pool/main/g/gaim/gaim_1.3.0-1_i386.deb gaim_1.3.0.orig.tar.gz to pool/main/g/gaim/gaim_1.3.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libflash 0.4.11-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 9 May 2005 19:32:27 +0900 Source: libflash Binary: libflash-mozplugin libflash-dev libflash0 libflash-swfplayer Architecture: source i386 Version: 0.4.11-4 Distribution: unstable Urgency: low Maintainer: Nobuhiro Iwamatsu [EMAIL PROTECTED] Changed-By: Nobuhiro Iwamatsu [EMAIL PROTECTED] Description: libflash-dev - GPL Flash (SWF) Library - development files libflash-mozplugin - GPL Flash (SWF) Library - Mozilla-compatible plugin libflash-swfplayer - GPL Flash (SWF) Library - stand-alone player libflash0 - GPL Flash (SWF) Library - shared library Closes: 282062 283119 283408 290801 295133 Changes: libflash (0.4.11-4) unstable; urgency=low . * New maintainer (closes: 283119) * Error( undefined symbol:XtWindowToWidget) was solved by link libXt . (closes: #282062, #283408, #290801, #295133) * URL Under construction (close: #275915) Files: bcc9f2f7a64e64ab3d3b6a86632abd6c 702 libs optional libflash_0.4.11-4.dsc 515233ce55fd9a6ef8f9a91070c503e7 39832 libs optional libflash_0.4.11-4.diff.gz caa5da498152c56d20bbc7786dff8ad0 61310 libs optional libflash0_0.4.11-4_i386.deb 8460b6f4b0dc55b84707dbe79344e59e 65298 libdevel optional libflash-dev_0.4.11-4_i386.deb 6c8161ab33e53d92a7a3cd4b7ccdf57d 11758 graphics optional libflash-swfplayer_0.4.11-4_i386.deb 3ccec9728829b8ee463f22c7c40ab2ff 12194 web optional libflash-mozplugin_0.4.11-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCghdd7qLvonfc4IMRAnVDAJwPRK1Ja4Sr7t1sVmgPVgGi/9WDFACePXrl Lc85/vf09aLEITWF11zh4n4= =9ccx -END PGP SIGNATURE- Accepted: libflash-dev_0.4.11-4_i386.deb to pool/main/libf/libflash/libflash-dev_0.4.11-4_i386.deb libflash-mozplugin_0.4.11-4_i386.deb to pool/main/libf/libflash/libflash-mozplugin_0.4.11-4_i386.deb libflash-swfplayer_0.4.11-4_i386.deb to pool/main/libf/libflash/libflash-swfplayer_0.4.11-4_i386.deb libflash0_0.4.11-4_i386.deb to pool/main/libf/libflash/libflash0_0.4.11-4_i386.deb libflash_0.4.11-4.diff.gz to pool/main/libf/libflash/libflash_0.4.11-4.diff.gz libflash_0.4.11-4.dsc to pool/main/libf/libflash/libflash_0.4.11-4.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dvi2ps 3.2j-10 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 5 May 2005 22:14:58 +0900 Source: dvi2ps Binary: dvi2ps Architecture: source i386 Version: 3.2j-10 Distribution: unstable Urgency: low Maintainer: OHURA Makoto [EMAIL PROTECTED] Changed-By: OHURA Makoto [EMAIL PROTECTED] Description: dvi2ps - TeX DVI-driver for NTT JTeX, MulTeX and ASCII pTeX Closes: 307690 Changes: dvi2ps (3.2j-10) unstable; urgency=low . * Add Spanish po-debconf templates. (Closes: #307690). Files: b336797d0ec4be29ac1889b31665c50b 620 tex optional dvi2ps_3.2j-10.dsc d490a08790659588872ddec4781c8e49 16687 tex optional dvi2ps_3.2j-10.diff.gz 0d26bd2f3f915a37cde79dd5c1268686 97986 tex optional dvi2ps_3.2j-10_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCghsp7qLvonfc4IMRAm3yAKCMd8IqO4c2SxikcAAon9yTKZUEUwCgsi8m VOVAHj2+KFoJw5VpcwQeVLQ= =q4wV -END PGP SIGNATURE- Accepted: dvi2ps_3.2j-10.diff.gz to pool/main/d/dvi2ps/dvi2ps_3.2j-10.diff.gz dvi2ps_3.2j-10.dsc to pool/main/d/dvi2ps/dvi2ps_3.2j-10.dsc dvi2ps_3.2j-10_i386.deb to pool/main/d/dvi2ps/dvi2ps_3.2j-10_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ptex-jisfonts 2-15 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 May 2005 23:50:36 +0900 Source: ptex-jisfonts Binary: ptex-jisfonts Architecture: source all Version: 2-15 Distribution: unstable Urgency: low Maintainer: OHURA Makoto [EMAIL PROTECTED] Changed-By: OHURA Makoto [EMAIL PROTECTED] Description: ptex-jisfonts - Provide an environment of jis.tfm and jisg.tfm for pTeX/dvips Closes: 308468 Changes: ptex-jisfonts (2-15) unstable; urgency=low . * Add Czech po-debconf templates. (Closes: #308468). Files: d4334c999647b3e8236df895b931d553 598 tex optional ptex-jisfonts_2-15.dsc 2a6956529e566715f526386c4a8da310 9918 tex optional ptex-jisfonts_2-15.diff.gz fc6f98ab6c1ab50d5b05dbdf53c2bb92 96736 tex optional ptex-jisfonts_2-15_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCgh2q7qLvonfc4IMRAmDsAKCDVg+A0+VetPVL/CKebT2eQ+gzHwCdEZOb ZlUSNNNK3cnwXemW0cXUz48= =YHs6 -END PGP SIGNATURE- Accepted: ptex-jisfonts_2-15.diff.gz to pool/main/p/ptex-jisfonts/ptex-jisfonts_2-15.diff.gz ptex-jisfonts_2-15.dsc to pool/main/p/ptex-jisfonts/ptex-jisfonts_2-15.dsc ptex-jisfonts_2-15_all.deb to pool/main/p/ptex-jisfonts/ptex-jisfonts_2-15_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted quilt 0.40-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 May 2005 15:51:51 +0200 Source: quilt Binary: quilt Architecture: source i386 Version: 0.40-1 Distribution: unstable Urgency: low Maintainer: Martin Quinson [EMAIL PROTECTED] Changed-By: Martin Quinson [EMAIL PROTECTED] Description: quilt - Tool to work with series of patches Changes: quilt (0.40-1) unstable; urgency=low . * New upstream version * Add /usr/share/quilt/quilt.make for the ones not using CDBS. Files: 99e5c2f1e038d55d3fec11494c8dcd9d 586 devel optional quilt_0.40-1.dsc 12305c1b114e9ca0a31980117b65a903 334556 devel optional quilt_0.40.orig.tar.gz 1dc3bf8fc5ac77c0bd4a533daa189425 8210 devel optional quilt_0.40-1.diff.gz 8f4cfce07e714c1bfb1aa7a1d885c685 263902 devel optional quilt_0.40-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCghuNIiC/MeFF8zQRAu+rAJ485UggxhKHlPEGw5/m/7Nhw/uK+QCeK3Dq /Dx5YA0+vQky+0L0DUisF2Q= =zFmI -END PGP SIGNATURE- Accepted: quilt_0.40-1.diff.gz to pool/main/q/quilt/quilt_0.40-1.diff.gz quilt_0.40-1.dsc to pool/main/q/quilt/quilt_0.40-1.dsc quilt_0.40-1_i386.deb to pool/main/q/quilt/quilt_0.40-1_i386.deb quilt_0.40.orig.tar.gz to pool/main/q/quilt/quilt_0.40.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libnet-easytcp-perl 0.26-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 May 2005 10:07:52 -0500 Source: libnet-easytcp-perl Binary: libnet-easytcp-perl Architecture: source all Version: 0.26-1 Distribution: unstable Urgency: low Maintainer: Debian Perl Group [EMAIL PROTECTED] Changed-By: Gunnar Wolf [EMAIL PROTECTED] Description: libnet-easytcp-perl - Easily create secure, bandwidth-friendly TCP/IP clients and serve Changes: libnet-easytcp-perl (0.26-1) unstable; urgency=low . * New upstream release * Package taken over from MIA maintainer (see thread strting at http://lists.debian.org/debian-devel/2005/05/msg00533.html) * Bumped up standards-version to 3.6.1 Files: 35aad0ac1e330b10d6942044a5d0dc28 697 perl optional libnet-easytcp-perl_0.26-1.dsc c8ff3f221bcdb358ed9dfa8c6b098b35 28712 perl optional libnet-easytcp-perl_0.26.orig.tar.gz d640ca3ed549d29f1bcfd901dbe654a8 2178 perl optional libnet-easytcp-perl_0.26-1.diff.gz f4aa70cc61c5ef24892ae63d383e55de 38634 perl optional libnet-easytcp-perl_0.26-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCgiRA2A7zWou1J68RAm0rAJ9BoAQmdGyC4+HDaJg8dXuyPZeVIQCgvJ4f hXRXay0jKMXUXpe+F77DkT0= =kcuF -END PGP SIGNATURE- Accepted: libnet-easytcp-perl_0.26-1.diff.gz to pool/main/libn/libnet-easytcp-perl/libnet-easytcp-perl_0.26-1.diff.gz libnet-easytcp-perl_0.26-1.dsc to pool/main/libn/libnet-easytcp-perl/libnet-easytcp-perl_0.26-1.dsc libnet-easytcp-perl_0.26-1_all.deb to pool/main/libn/libnet-easytcp-perl/libnet-easytcp-perl_0.26-1_all.deb libnet-easytcp-perl_0.26.orig.tar.gz to pool/main/libn/libnet-easytcp-perl/libnet-easytcp-perl_0.26.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted rng-tools 2-unofficial-mt.10-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 May 2005 06:43:37 -0300 Source: rng-tools Binary: rng-tools Architecture: source i386 Version: 2-unofficial-mt.10-1 Distribution: unstable Urgency: high Maintainer: Henrique de Moraes Holschuh [EMAIL PROTECTED] Changed-By: Henrique de Moraes Holschuh [EMAIL PROTECTED] Description: rng-tools - Daemon to use a Hardware TRNG Closes: 308248 Changes: rng-tools (2-unofficial-mt.10-1) unstable; urgency=high . * Last changes for Sarge (I hope) * The following changes warrant an upstream version bump: + Backport selected changes from rng-tools--hmh-devo--3.0--patch-80: + Upgrade udev and makedev versioned depends to require hwrng naming of the hardware random device + Attempt to makedev only hwrng, deprecate all other device naming for hw_random and friends (closes: #308248) + Backport configure.ac tweaks, and call ./configure correctly + Backport s/TRNG/HRNG/ in all docs + Backport intel-intelfwh name change for Intel FWH profile Files: c247242ff7eed7a09341d11f892cca3f 908 utils optional rng-tools_2-unofficial-mt.10-1.dsc b01aa8b7e833dbf9d230f146fb23a1bf 102405 utils optional rng-tools_2-unofficial-mt.10.orig.tar.gz 88202f2f6c3eded29cdf84202edcc153 12714 utils optional rng-tools_2-unofficial-mt.10-1.diff.gz 0f060087ce9c15d10bc0640645730705 39278 utils optional rng-tools_2-unofficial-mt.10-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iQEVAwUBQoHXNojztdzjjnrPAQKj2wf/bMx8Oyc0DyAUU6/ezppcHTmyqeBxlx24 HKqlt/w+RMMnbS9lrCkBMA3tMSVVm72D0iPDTNXR4JvOMxrcXQiH8jkz2/KbgPVG u4SCEfU8J/oxjjYBWzJLoHTlQjmYuBj1zafxHOYrsrgcZjE93oOZfMwhaSO+FGdV 4TYfLF2zuCEudndV1m8d+2qpBCYNufbuIvS5qZ5/2SX1dBXQqgoSXumE9cIJTPTY HgkDopqWzdn1U+ybkNJ9y2Fh+H+Pw7K2VlNlb5pDYXshCIlEpmwkKIjkeLr8xhSE NOfpJb92dDO0P8v9IYSH6WtYboeVGr5ocbn+cfbCoKGQJ2xviye+ng== =+nFd -END PGP SIGNATURE- Accepted: rng-tools_2-unofficial-mt.10-1.diff.gz to pool/main/r/rng-tools/rng-tools_2-unofficial-mt.10-1.diff.gz rng-tools_2-unofficial-mt.10-1.dsc to pool/main/r/rng-tools/rng-tools_2-unofficial-mt.10-1.dsc rng-tools_2-unofficial-mt.10-1_i386.deb to pool/main/r/rng-tools/rng-tools_2-unofficial-mt.10-1_i386.deb rng-tools_2-unofficial-mt.10.orig.tar.gz to pool/main/r/rng-tools/rng-tools_2-unofficial-mt.10.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dash 0.5.2-5 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 May 2005 14:01:40 + Source: dash Binary: dash-udeb ash dash Architecture: all source Version: 0.5.2-5 Distribution: unstable Urgency: low Maintainer: Gerrit Pape [EMAIL PROTECTED] Changed-By: Gerrit Pape [EMAIL PROTECTED] Description: ash- Compatibility package for the Debian Almquist Shell dash - The Debian Almquist Shell dash-udeb - The Debian Almquist Shell for boot floppies (udeb) Closes: 308043 Changes: dash (0.5.2-5) unstable; urgency=low . * debian/po/cs.po: new; initial Czech debconf translation (closes: #308043, thx Martin Sin, Miroslav Kure). Files: 3a5209046ab5c93099c68be2a4a94257 553 shells optional dash_0.5.2-5.dsc 78e9439b89d1e68a2cbc843430384c43 20842 shells optional dash_0.5.2-5.diff.gz 33cf14c14a7b3e679bebeb299495cf19 14882 shells optional ash_0.5.2-5_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCghN1GJoyQbxwpv8RAjW2AKCG5Qcs9gl2HJqbBclhTw5z3kYInACcC7Kj Y3Sx4asdxYhUPfeokgbNMWk= =s+xV -END PGP SIGNATURE- Accepted: ash_0.5.2-5_all.deb to pool/main/d/dash/ash_0.5.2-5_all.deb dash_0.5.2-5.diff.gz to pool/main/d/dash/dash_0.5.2-5.diff.gz dash_0.5.2-5.dsc to pool/main/d/dash/dash_0.5.2-5.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted preview-latex 0.9.1-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 12 May 2005 00:02:12 +0900 Source: preview-latex Binary: preview-latex preview-latex-style Architecture: source all Version: 0.9.1-2 Distribution: unstable Urgency: low Maintainer: OHURA Makoto [EMAIL PROTECTED] Changed-By: OHURA Makoto [EMAIL PROTECTED] Description: preview-latex - render LaTeX environments within emacs preview-latex-style - LaTeX style files for editor embedded preview of some environment Closes: 308464 Changes: preview-latex (0.9.1-2) unstable; urgency=low . * Add Czech po-debconf templates. (Closes: #308464). Files: 439e83994d2bc488349ce6c643650f01 686 tex optional preview-latex_0.9.1-2.dsc 8569d3cf452ee0f76b5fdb6202099810 12151 tex optional preview-latex_0.9.1-2.diff.gz 4fc7c7b94ca379a4c1e4c133884a4559 658518 tex optional preview-latex_0.9.1-2_all.deb effeff96b1a39b75ba042a43cdabc2ee 95666 tex optional preview-latex-style_0.9.1-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCgiYd7qLvonfc4IMRAi9LAKDIcNZVv1FmzjbO1CyinU3MFs+dawCg1pRq /vmtHQzvAV4Qqnie6wOizkU= =u4IT -END PGP SIGNATURE- Accepted: preview-latex-style_0.9.1-2_all.deb to pool/main/p/preview-latex/preview-latex-style_0.9.1-2_all.deb preview-latex_0.9.1-2.diff.gz to pool/main/p/preview-latex/preview-latex_0.9.1-2.diff.gz preview-latex_0.9.1-2.dsc to pool/main/p/preview-latex/preview-latex_0.9.1-2.dsc preview-latex_0.9.1-2_all.deb to pool/main/p/preview-latex/preview-latex_0.9.1-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sablevm-classlib 1.11.3-2 (powerpc all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 10 May 2005 23:29:48 -0400 Source: sablevm-classlib Binary: libsablevm-native1 libsablevm-classlib1-java Architecture: source all powerpc Version: 1.11.3-2 Distribution: unstable Urgency: low Maintainer: Grzegorz B. Prokopski [EMAIL PROTECTED] Changed-By: Grzegorz B. Prokopski [EMAIL PROTECTED] Description: libsablevm-classlib1-java - GNU Classpath modified to work with SableVM JVM libsablevm-native1 - GNU Classpath modified to work with SableVM JVM (native part) Closes: 304823 306507 Changes: sablevm-classlib (1.11.3-2) unstable; urgency=low . * Fixed Ant bootstrapping. Closes: #304823, #306507. * Changes kept to minimum to allow inclusion into Sarge. Files: 0adda16842fd2b75a45d16c8ea917482 748 libs optional sablevm-classlib_1.11.3-2.dsc 612ca9f12ee433cb6b7c5c9adefa21ca 65148 libs optional sablevm-classlib_1.11.3-2.diff.gz 09c8a8b2dbc6150c8004339cb0f83d74 3695766 libs optional libsablevm-classlib1-java_1.11.3-2_all.deb 24f1230ac93781ac468b7bcebc5c5b56 194290 libs optional libsablevm-native1_1.11.3-2_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCgisT4vzFZu62tMIRAi7hAJ9tbjWSXvi4SrK4DXlWRZaeSCJfTQCdFvey DlLsMO77fRmGNADCL6aQBrE= =WEFp -END PGP SIGNATURE- Accepted: libsablevm-classlib1-java_1.11.3-2_all.deb to pool/main/s/sablevm-classlib/libsablevm-classlib1-java_1.11.3-2_all.deb libsablevm-native1_1.11.3-2_powerpc.deb to pool/main/s/sablevm-classlib/libsablevm-native1_1.11.3-2_powerpc.deb sablevm-classlib_1.11.3-2.diff.gz to pool/main/s/sablevm-classlib/sablevm-classlib_1.11.3-2.diff.gz sablevm-classlib_1.11.3-2.dsc to pool/main/s/sablevm-classlib/sablevm-classlib_1.11.3-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted rcs 5.7-15 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 11 May 2005 17:51:01 +0200 Source: rcs Binary: rcs Architecture: source i386 Version: 5.7-15 Distribution: unstable Urgency: low Maintainer: Romain Francoise [EMAIL PROTECTED] Changed-By: Romain Francoise [EMAIL PROTECTED] Description: rcs- The GNU Revision Control System Closes: 69257 Changes: rcs (5.7-15) unstable; urgency=low . * Adopting this package with Mark's blessing. . * debian/control: + Bump Standard-Version to 3.6.1.0. + Update maintainer contact info. . * debian/copyright: Ditto. . * debian/rules: + Adjust CFLAGS to include -g and remove useless -I directive. + Remove LDFLAGS. . * Patch upstream Makefile.in to use install -s (which has the nice effect of also deleting .comment sections from the binaries). . * Patch man/rlog.1 to document option -q which does nothing, it's provided for consistency with other commands (closes: #69257). . * Remove a few unneeded files from the Debian diff (.orig files, Emacs lock files). Files: 6d9e3cdf148e71f583d82704a0e4360c 546 devel optional rcs_5.7-15.dsc 9cc6862c7a34bc8a9d07dff6257baa44 37739 devel optional rcs_5.7-15.diff.gz b1d905f3ef4c1aeb0cd035403858ca7e 314008 devel optional rcs_5.7-15_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCgirXogN2vsA8Vt8RApUwAKCnHWx5qNj9B7flCnkx2Mz6WxDbHwCaAwVA 0o5pDh+0xn5jy3oU4bMJ4Ew= =C1Yb -END PGP SIGNATURE- Accepted: rcs_5.7-15.diff.gz to pool/main/r/rcs/rcs_5.7-15.diff.gz rcs_5.7-15.dsc to pool/main/r/rcs/rcs_5.7-15.dsc rcs_5.7-15_i386.deb to pool/main/r/rcs/rcs_5.7-15_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
