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 debian.org> writes: > > Package: wnpp > > Severity: wishlist > > Owner: "Francesco P. Lovergine" debian.org> > > > > * Package name: gstat > > Version : 2.4.4 > > Upstream Author : Edzer J. Pebesma 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: > 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 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 -J"set1[1-100]" -o 0.1.output.%I foo -i file\$LSB_JOBINDEX.data -p 0.1 bsub -J"set2[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 * 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 -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 does an upgrade if I don't have the latest version (that is ok the default behaviour) and why apt-get upgrade 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 do the same as apt-get install (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
[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
Re: Hijacking apt-cacher (Jonathan Oxer MIA?)
#include * Jonathan Oxer [Thu, May 12 2005, 08:55:08AM]: > > 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. Wow. Nice, please continue with the good work. As russian people say, "ÐÑÐ ÐÐ ÐÐÑÑÑÐ" (sth. like "to make hay while the sun shines" by Dict). > 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. Ack. I will set myself as main maintainer and keep you in the Uploaders list as Co-Maintainer, I think this is a good deal. As said before, your other address creates bounces (see below), please fix that sooner or later. MfG, Eduard. [EMAIL PROTECTED] SMTP error from remote mailer after RCPT TO:<[EMAIL PROTECTED]>: host mf154.ivt.com.au [216.93.178.156]: 554 <[EMAIL PROTECTED]>: Recipient address rejected: Please see http://spf.pobox.com/why.html?sender=edi%40gmx.de&ip=146.82.138.7&receiver=mailf -- Susan Ivanova: Ambassador, do you really want to know what's going on down there? Ambassador Londo Mollari: Yes, absolutely! Susan Ivanova: Boom. Boom boom boom. Boom boom. Boom! Have a nice day! -- Quotes from Babylon 5 -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pine license
On Thu, May 12, 2005 at 10:33:18AM +0900, Miles Bader wrote: > 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? Could you all please discuss this type of stuff on -legal, not on -devel, the technical discussion list? Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
