Re: Funding for a Crazy Idea
On 25 Sep 1999, Craig Brozef wrote: > > Uhm, they did just bomb Yugoslavia into the stone age... and > I hope that Debian does not resort to begging bald-faced liars. Would it not be better if the money is spent on Debian than if on warfare? --free software, not bombs-- ciao
Re: Danger Will Robinson! Danger!
I find it hard to believe that this issue arises every time a new kernel is released. It may be useful to some to run the latest, but for most it's not an issue. IMHO including the latest kernel is only useful as a marketing gimmick, and as Debian is non-commercial we don't need that kind of marketing. Debian has no need to "keep up" with the other distributions by including the latest version of everything. It will continue to be the dist of choice for those who know, with or without 2.4. -ptw
Re: Danger Will Robinson! Danger!
On Sun, 12 Mar 2000, Dave said: > The solution to this is that we ignore woody for the moment, and begin an all > out effort to get the 2.4 kernel, XF4.0, and Apache 2.0 into Debian as STABLE. > The work for these things can also incorporate the work needed to re-add the > packages that were removed because of bugs. I know people LOVE to work on > "unstable", and I don't recomend we delay potato's release, so this is the > alternative. We release potato when it's ready, then prepare a point release > for the major packages. Call the maintenance release potato mk 2 or > something. > There's a grain of truth in this idea. IMHO all efforts should be concentrated on making Potato the stable dist asap, but without attempting to add new features. Then we can freeze Woody in about three months and have a new stable shortly after that. I believe that short-sightedness and overeagerness for new features is what has caused the delays for the potato release. A reasonable release cycle will allow Debian to become "up to date". Attempting to add new versions now will just delay Potato further. IMHO, of course. -ptw
Re: Danger Will Robinson! Danger!
On Sun, 12 Mar 2000, Stefan said: > i still don't see why compiling a kernel on your own is a problem. i > have never used a precompiled kernel, and i never had problems. Same here. IMHO, kernel-image packages are nice, but AFAIK, most users benifit from recompiling the kernel at some point anyway. I almost always find it necessary to do so after an install. -ptw
Re: Apt-Problem
On Wed, 15 Mar 2000 19:18:24 +0530, Syed said: > > On Wed, 15 Mar 2000 14:17:54 +0100 (CET), Andreas Tille <[EMAIL > > PROTECTED]> said: > Andreas> > http://ftp.tu-clausthal.de/pub/linux/debian/dists/frozen/main/binary-i386/devel/libtool_1.3.3-9.deb > Andreas> Size mismatch E: Unable to fetch some archives, maybe try > Andreas> with --fix-missing? > > Andreas> As I said I could install the package using dpkg -i > Andreas> /var/cache/apt/archives/partial/libtool_1.3.3-9.deb > Andreas> without any warning/error. > > I got the same error when I was doing an apt-get upgrade last > night. It was with man-db. But when I did an apt-get upgrade > after sometime again, it did not reget the package again, but > installed with the same old package succesfully. anybody knows > what this is ?? > - Khader > I had the same problem (and same output) when doing "apt-get upgrade" last night. I used "apt-get clean" and "apt-get install man-db" before trying "apt-get upgrade" again. The problem went away, so I thought it had been a hardware problem on my end, but I guess I was wrong. Anyone know what happened? -ptw
Re: Intent To Split: netbase
Why is it considered "difficult" for individual users adding /sbin and /usr/sbin to their path if they wish to? I'm sure that most users are competent enough to change their own path, and if they are not, they will be soon after they find that they need to. As a user with no formal computer training, and little experience other than GNU/Linux, changing my path was among the earliest of tasks that I learned. Is there some deeper principal of Unix or Linux philosophy being discussed here? Is there something to be gained that is somehow greater than can be achieved by changing one's own path? Is there something I am missing about this debate? -- ptw miscelaneous endeavors ([EMAIL PROTECTED])
MEI Whitelist Autoresponse
Your message to [EMAIL PROTECTED] has been quarantined! You only need to do this once, but this time, you must verify that you are a human. This is an automated response send by the MEI Whitelist system. At paul's request, this system blocks and quarantines email from senders that are not on a list of approved addresses. If you reply to this message with the following line intact, you will be added to paul's white list automatically! MEI verification code: MEI0250511061987327tId9CNuNr3t1YZv3sJrT8g Your message has been quarantined and will be delivered after you're successfully added to the whitelist. You will be sent separate confirmation emails at each stage. Typically that will be two more automated messages. Thank you for your patience. The first 55 lines of your original message: > From debian-devel@lists.debian.org Wed Aug 27 08:28:47 2003 > Return-Path: > Received: from OITRM05-10A (bordermanager1.kellogg.cc.mi.us [204.39.194.3]) > by mei.net (8.12.9/8.12.9) with ESMTP id h7RCSOHL024889 > for <[EMAIL PROTECTED]>; Wed, 27 Aug 2003 08:28:25 -0400 > Message-Id: <[EMAIL PROTECTED]> > From: > To: <[EMAIL PROTECTED]> > Subject: Thank you! > Date: Thu, 28 Aug 2003 8:34:52 --0400 > X-MailScanner: Found to be clean > Importance: Normal > X-Mailer: Microsoft Outlook Express 6.00.2600. > X-MSMail-Priority: Normal > X-Priority: 3 (Normal) > MIME-Version: 1.0 > Content-Type: multipart/mixed; > boundary="_NextPart_000_000CF422" > BCT-delivery-for: paul > MEI-wl-code: MEI0250511061987327tId9CNuNr3t1YZv3sJrT8g > > This is a multipart message in MIME format > > --_NextPart_000_000CF422 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > > See the attached file for details > --_NextPart_000_000CF422 > Content-Type: application/octet-stream; > name="document_all.pif" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; > filename="document_all.pif" > > TVqQAAME//8AALgAQAAA > 4A4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v > ZGUuDQ0KJADToEjPl8EmnJfBJpyXwSacFN0onI3BJpx/3iyc7cEmnMHeNZyawSacl8Em > nJTBJpyXwSecBsEmnPXeNZyawSacf94tnI3BJpxSaWNol8EmnABQRQAA > TAEEAF2zPz8AAOAADwELAQYAAABw1usBAAAQYAEAAABQ > AgAABAAEAgAAEAAAF/EBAAIAABAAABAAEAAAEBAA > AOLrAQCcfuwBAAgA > > AAAgAC5zaHJpbmsAAFABAAAQxBAAAEAAAMAu > c2hyaW5rAAAwYAEAABIAAADUAABAAADALnNocmluawAAQJABAAAS > 5gAAQAAAwC5zaHJpbmsAADDQAQAAIgAAAPgA > AEAAAMAA > > > > > > >
Re: Bug#492157: ITP: apollo -- The Apollo Solr Server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Guus, Your other comments are out of date (see the BTS for full bug report e-mail conversation), however many thanks for your reply. This feedback is important though: > Finally, it seems Solr is already packaged by the Debian Java > Maintainers, see http://packages.debian.org/solr-tomcat5.5. If there is > anything in your package that is not in theirs, please coordinate with > them. I'll start out by saying that I'm quite happy NOT to package this separately if that's the general consensus. In fact, I hoped this particular discussion would ensue as I certainly don't want to be spending my time maintaining a package that nobody wants! However in reply to the above suggestion, I would point out that apollo takes a different approach to theirs, as it creates a single instance of the jetty-based example from the Solr tarball, then constructs a framework around that which provides two important features lacking in the above: master/slave replication, out-of-the-box from debconf multiple Solr instances running on the same machine Apollo also installs nicely on the current stable (etch) which was one of the drivers for creating something myself, and not using the above, which at the time of testing did not. Apollo has been running on etch in our client production systems for a year now. Given that lenny is not yet released, and even when it is there will be a *lot* of etch servers running out there for a long while, I think this is still a very useful attribute. I obviously looked at the above Debian Maintainers packages solr-common, solr-jetty and solr-tomcat initially, when starting out to build the above-mentioned applications for our clients, however the fact that they didn't install on our stable (etch) production servers was a blocker. Hence apollo came into being. I should also add that apollo is currently built as a native Debian package, where the Solr tarball is downloaded in the build process, and then bits of it used to construct the apollo binary package. I look forward to your comments on the above, and also on this packaging approach. If you (or anyone) wants a preview of the package, then let me know. As I began by saying, it could be that this package isn't deemed to be useful or suitable for Debian. That's fine with me, my motivation was to make available something that I had already built and am currently using in production systems, to other potential users of Solr. Cheers, Paul. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIij8DtfkpAgkMOyMRAtZ8AJ94OwcLBVbaqpm0X4ZJXFosxfK5yACfQghi ZQl/OaTf4xARojKGIDpQU0Y= =ajyE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#492157: ITP: apollo -- The Apollo Solr Server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On further reflection I have decided to withdraw apollo from ITP for now. Although I believe it would be very useful for folks wishing to use Solr in multiple instances with replication out-of-the-box, I now believe there are still some issues around the packaging of it that I want to resolve first. Many thanks to all who contributed to this with feedback. Cheers, Paul. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIiluUtfkpAgkMOyMRAoiEAJ48ZGfknaVtmCSQgAGQ4jyRBmoihgCguDPT pun1FDjxomjhPrzMmBP81No= =EArd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: graphical installer?
On Fri, 30 Aug 2002, Mateusz Papiernik wrote: > Hello! > > Is there any plans for the graphical installer? I know, > it isn't needed, but I think it would be nice step for > beginners - for example automatically search and install > modules for ethernet/whatever - or easy configuration > for printer :-P Of course I'm not a beginner :-P Have a look at PGI: http://hackers.progeny.com/pgi/ Paul.
Re: [sylpheed:37253] Debian 12 released with two RC bugs in Sylpheed
On Sun, 7 Apr 2024 13:26:49 +0200 José Luis González wrote: > Debian 12 was released with two Release Critical bugs I filed on May > 20th 2023 (#1036424 and #1036388) on Sylpheed about issues that I > found on stable, and remain, with Debian 12 released later on June 10th > 2023. Those are not "Release Critical bugs". > I want to know why Debian 12 was released with those two Sylpheed RC > bags, report the incident to you all, know what to do with the > maintainer and kindly request that someone better at the job takes over > Sylpheed maintainance, or otherwise I will become a Debian developer > and package it myself. The upstream mailing list is not the place for this Debian discussion. On the one hand you "kindly request" and on the other your hurl unwarranted insults on a public list about the long-term Debian maintainer. Maybe Debian will overlook your behaviour and accept you as a developer, I don't know. with regards Paul
Re: [sylpheed:37255] Re: Debian 12 released with two RC bugs in Sylpheed
On Sun, 7 Apr 2024 15:18:57 +0200 José Luis González wrote: > I found the report now. It's #1036799. Yes, it looks like a temporary server issue. And you're sending via gmail now. But again, what do you expect a package maintainer to do? It's upstream where bugs get fixed. Your subject is wrong, your two RC bugs are not RC bugs; in fact, they both seem to be describing the same behaviour, and you are requesting that the behaviour be different. i.e. they are feature requests. The more I consider your complaints about the Debian maintainer, the less they seem to hold water. with regards Paul
Re: Illegal Instruction Using sudo in Bookworm on i686
Hi, On 09-06-2024 1:56 p.m., rhys wrote: So given that these no longer fit the "old and busted" description, is Debian going to stick with the decision to not support them? Or is Debian going to continue to support this processor, since it is still apparently a viable product, enough that new systems are using it? https://lists.debian.org/debian-devel-announce/2023/12/msg3.html still stands. Debian basically isn't going to support any i386 CPU anymore in the sense that the Release Team gave the teams the wildcard to drop kernel, installer and images support for i386 (I don't have the details of the current status). """ Following that, there are two routes into running i386: 1. as a multi-arch option on an otherwise amd64 system 2. as an i386 chroot on another architecture system """ That's what we intend to do as Debian. If you want an Debian architecture to keep Debian running on i386 CPU's, you can create a port. But unless you find enough volunteers, I'm a bit skeptical you'll succeed. There are enough problems to cover, of which upstream kernel support and the 32 bit memory build problem are on the top of my mind. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: About i386 support
Hi On 14-06-2024 8:09 p.m., rhys wrote: Even under the bookworm "Intel 686-only" rules, it still works, so I still use it. It's built, it runs, it serves a purpose, and it costs very little. And you can keep trying that until it doesn't work for you anymore, we're not saying we'll hold you from trying. What support means here is that if you come and say: here's a bug, we'll say: you're on your own to fix it. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Reviving schroot as used by sbuild
Hi On 25-06-2024 6:55 p.m., Helmut Grohne wrote: This is very cool. Running autopkgtests in system containers without being root (or incus-admin) very much is what I'd like to do. And it's much better if I don't have to write my own container framework for doing it. I couldn't get it to work locally yet (facing non-obvious error messages). Maybe bug #1059725? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: autopkgtest + podman user experience (Was: Re: Reviving schroot as used by sbuild)
Hi. On 25-06-2024 8:18 p.m., Gioele Barabucci wrote: I'd like to take this chance to suggest, instead of writing more documentation, changing the autopkgtest packaging so that it is split into various per-backend packages, each of which provides a ready-to-go pre-configured environment. See <https://bugs.debian.org/1039958#22>. It has also been suggested in the past, to split off the backends from src:autopkgtest (it too late for me to dig that up). The current autopkgtest maintainers were positive to the idea when it was proposed years ago, and at least I would applaud it when maintenance of the backends was taken away from us. I would expect that part of that way forward would be to agree on a clear expectation what's in scope and what's not in scope of all backends [1]. It's clear that the autopkgtest backends have outgrown autopkgtest. Maybe they don't belong there. Paul [1] Recently I started to work on a different way that autopkgtest would talk to the testbed (via ssh). That may or may not be appropriate for its use by sbuild. See bug 1068588. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: OpenPGP digital signature
Hi, On 30-07-2024 10:21, Simon McVittie wrote: Please note that imtoas...@mail.com is (presumably) not Paul, Correct. the subject line is not what the release team would use, Correct. and Paul seems unlikely to send official Debian announcements through a gmx.com mail relay with a (forged?) gmail address as the sender. Indeed, I wouldn't do that. Please ignore the message. This. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hi all, On 03-08-2024 22:37, Salvo Tomaselli wrote: At the bottom, is it ok for a package to have a single maintainer or not? I have never wanted to be the single maintainer of a package, and here I am, I'm member of a bunch of teams, but most of my packages uploads (not a lot luckily) are for packages that nobody else uploads. The people that believe that package should not be single person maintained, please become co-maintainer of all the packages I list below, you're welcome. In this discussion about single maintainer packages I nearly feel guilty, while at the same time I don't *want* to be the single maintainer. Actually, I don't want to maintain packages at all, my joy is elsewhere in Debian. I'm on LowThresholdNMU and LowThresholdAdoption lists. I guess I should have created a wnpp RFH" bug for all my packages? Not that those really work either (see e.g. #846328, it's still open). So we have established processes, but apparently they don't work as intended. Now we trying to *add* to the set. Maybe we should clean up older processes at the same time because additions just make it even more difficult. XKCD 927 comes to mind [1]. I'm the single maintainer for the following package, only to reflect reality, not because I consider myself "owner". E.g. for years there was a different person in the maintainer field for liferea, but de-facto I was the real maintainer. If people recognize a good team for them, we should make a team maintainer of these: dbconfig-common -> in the debian namespace liferea -> in the debian namespace viking -> in the debian namespace I'm the only member of the teams maintaining: * cacti and cacti-spine -> in the debian namespace (bit complicated packaging due to upstream vendoring stuff; receives quite some CVE's) * siridb, libcleri, qpack, siridb-connector and siridb-admin -> in the siridb-team namespace, but I'd happily move them to the debian namespace if it would help (I don't expect it would, see dbconfig-common, liferea and viking). Feel free to enable all ci pipelines that work for those packages (I couldn't get cacti to build on salsa last time I tried, would love to see that fixed, I now use debomatic to try run builds). I'm not sure if I receive MR message if somebody would try to create one for these packages. Paul [1] https://xkcd.com/927/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Strange armel build error
Hi, On 16-08-2024 17:46, Alec Leamas wrote: All other builds are OK. Has anyone a hint about what might be going on here? https://release.debian.org/testing/arch_qualify.html armel column. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Removing more packages from unstable
Hi helmut, +1 On 20-08-2024 07:28, Helmut Grohne wrote: * As packages fail to migrate to testing for a long time, a release team member eventually looks at the package. I recognize myself here. But to be totally fair, that's *mostly* about testing, and we have processes for that. Once removed from testing, what's in unstable is hardly a matter for the release team. Except we do monitor packages in transitions, as we schedule binNMU's so some of those FTBFS bugs come from us. * There are many more people doing various forms of QA and sending patches. Although I hardly send patches, I do file *loads* of bugs for autopkgtest failures and other QA related checks. Again, mostly for testing, but occasionally for unstable too. For autopkgtest, typically when I need to add packages to our reject_list, which needs maintenance too. My personal motivation for looking into this actually is the /usr-move work and the cross build support work. Please do consider me biased. I'm biased too, but I don't think that's bad. You and I are doing quite a bit of this work, so we have a say. As is quite common, I agree with a lot of what Niels replied too on the topic of automating this. autoremoval from testing currently is mostly handled by udd, which was great to get this bootstrapped, but at this moment makes me uncomfortable as a Release Team member. The tool should be owned and maintained by us. When I first wanted to make changes to it, I couldn't even do it because I wasn't member of the right team, which feels weird. The same is true for the key package set calculation (which is strongly related). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
fftw3 needs testing on K6
Hi all, fftw3 needs testing on AMD K6. The solution suggested by the upstream authors is available at http://piem.org/~piem/debian/fftw3/ . it would be nice if a K6 owner could reproduce the bug (for instance running jamin with fftw3 3.0.1-10) and then try again using the above version. Please CC your reports to [EMAIL PROTECTED] Many thanks, piem
Re: Very BIG Problem with debian packages versioning...
On Fri, Oct 29, 2004 at 11:51:44AM +0200, Vincenzo Belloli wrote: > Package: clamav-daemon > Version: 0.80-2 > The problem is related to clamav debian packages maintained by ... and > hosted here: > deb http://people.debian.org/~sgran/debian woody main > I've 2 identical machines. These are versions installed in the 2 machines: > server1# dpkg -l | grep clam > ii clamav 0.80-2 Antivirus scanner for Unix > ii clamav-base0.80-2 Base package for clamav, an anti-virus > utili > ii clamav-daemon 0.80-2 Powerful Antivirus scanner daemon > ii clamav-freshcl 0.80-2 Downloads clamav virus databases from > the In Note this package here.^^ > ii clamav-testfil 0.80-2 Use these files to test that your > Antivirus > ii libclamav1 0.80-2 Virus scanner library > ii libclamav1-dev 0.80-2 Clam Antivirus library development files > server2# dpkg -l | grep clam > ii clamav 0.80-2 Antivirus scanner for Unix > ii clamav-base0.80-2 Base package for clamav, an anti-virus > utili > ii clamav-daemon 0.80-2 Powerful Antivirus scanner daemon > ii clamav-freshcl 0.80-2 Downloads clamav virus databases from > the In Note this package here too.^^ > ii clamav-testfil 0.80-2 Use these files to test that your > Antivirus > ii libclamav1 0.80-2 Virus scanner library > ii libclamav1-dev 0.80-2 Clam Antivirus library development files > > BUT THIS IS THE MATTER: on the 2 machines there are different versions > of clamd anche clamdscan. Why che debian packages have not been updated > Is it normal that the same debian package version contains > different program versions > > server1# clamd -V > ClamAV 0.80/559/Thu Oct 28 15:08:33 2004 > server1# clamdscan -V > ClamAV 0.80/559/Thu Oct 28 15:08:33 2004 > > server2# clamd -V > ClamAV 0.80/560/Fri Oct 29 09:32:46 2004 > server2# clamdscan -V > ClamAV 0.80/560/Fri Oct 29 09:32:46 2004 *cough* That's "Program version/Database version/Database date". > Now, if i want v.560 on all machines must uninstall the packages and > reinstall them, because from the dpkg point of view the packages has not > changed !! Or just wait for freshclam to update server1... Did you do these at the same time, or was there a day between server1's output and server2's output? ^_^ -- --- Paul "TBBle" Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: debian.org e-mail address and SPF/SRS
On Thu, Nov 04, 2004 at 10:37:08PM +1100, Matthew Palmer wrote: > On Thu, Nov 04, 2004 at 12:11:07PM +0100, Tollef Fog Heen wrote: > > * Matthew Palmer > > | Uhm, having just read through the supplied URL, I can't agree with the > > | sanity of the proposal. > > | It appears to require that headers not be modified at all in transit > > | (which means that forwarding becomes impossible), > > Uhm, which headers are modified by a forwarding agent? New headers > > can be prepended just fine, and you don't have to sign all the > > headers. > See, that's the thing that the FAQ was unclear on. If you don't have to > sign all headers, then you're OK. I was thinking the attachment of > Received: headers as being particularly problematic. To quote the FAQ: > "Mailing lists that do not change the content or re-arrange or append > headers will be DomainKey compatible with no changes required. Mailing lists > that change the message and headers should re-sign the message with their > own private key and claim authorship of the message." > That suggests to me that sticking new headers into the mix would screw up > the signature. Sticking new headers into the mix, yes. Sticking them after the mix, yes. Adding them _before_ the DomainKeys signature will be fine. Of course, this may require a change in the way some software works at the moment? I have the impression that spamasssassin/amavisd append their headers to the end of the header list... > > | and suffers from the same problem as most mail server crypto issues > > | -- domain names (and the associated keys) are trivial to obtain. > > | It's just too easy to get a new domain to spam from, and rejecting > > | mail from unknown domains reduces the system to a fancy whitelist. > > It gives you traceability and it can be used to prevent joe-jobs. > > It's not a silver bullet solution against spam. > And yet it's being touted as one. I predict that the effect of this system > on spam levels will be about as detectable on a spam vs time graph as a fart > in a hurricane. > > | If the "signed headers" problem isn't as bad as I think it is, then it > > | certainly looks saner than SPF, but the FAQ question "How does DomainKeys > > | work with mailing lists?" give me chills (and not the good kind). > > Which mailing list systems do you know of that change headers and > > don't claim the message (basically using themselves as the envelope > > sender). I can certainly imagine there being such beasts out there, > > but most of the larger ones certainly don't, as they would then have > > no way to catch bouncing members. > DomainKeys, by my reading, doesn't use the envelope sender, but instead uses > the visible headers (such as From:) to work out what to authenticate. > Again, to quote the FAQ: This indeed strikes me as a difficulty in the system... Unless the Sender: header is supposed to be filled in from the envelope sender? To my mind, which ever header this protects, is the one you can use to filter against. My problem is I can't see what we really gain, unless you apply a rule that all email from a domain-keys-enabled domain must have a domain-keys signature. To make mailing lists and forwarders work, it'd have to work off the SMTP envelope sender, not the From: header. Before I can decide if this'll work for me, I have to go check what the SMTP envelope sender is on the emails that come out of my server, which I have postfix doing a canonicalisation-remap on so people don't try to email me on my fetchmail-pickup-only POP box. So as far as I can see, this would allow (if everything falls into place) email rejection from domains that mark themselves as such... Kinda like SPF/SRS, but without having to bone up the From address. ^_^ (And chewing up more CPU load. >_<) > I'll reiterate that I haven't read the spec, so if the FAQ is contradicted > by the actual spec, I'll stand corrected, but on the basis of what I've read > in the FAQ, I have no interest in the spec itself, because it's not going to > be any better than SPF in practice. Which is a pity, because the initial > idea is quite a decent one. I haven't read the spec either. IE crashed and I didn't bother returning to the site, trusting debian-devel to tell me all I needed to know about it. ^_^ -- --- Paul "TBBle" Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Introducing pmount in Debian / New plugdev group
On Tue, Nov 09, 2004 at 06:41:40PM +0100, Martin Pitt wrote: > We solved (4) by introducing a new group called 'plugdev'. Every user > who is a member of this group can access hotpluggable devices (digital > cameras, USB drives etc.). pmount can only be executed by members of > this group (it is root:plugdev 750), Hmm. What's to stop a user fetching their own version of the pmount binary? I assume that won't work since they won't have the appropriate device permissions. If so, then a+x mode is safe, and directed by Debian Policy (I think. If not, it's in the Developer's Reference as a good idea). If not, then there's a nasty security hole at that point. The rest of it sounds good. I'm not fussed about hal, since I don't use gnome-volume-manager, but pmount might work better for me than autofs4, which you can't manually unmount without becoming root. >_< -- --- Paul "TBBle" Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Introducing pmount in Debian / New plugdev group
On Wed, Nov 10, 2004 at 01:25:56PM +0100, Sjoerd Simons wrote: > On Tue, Nov 09, 2004 at 06:41:40PM +0100, Martin Pitt wrote: > > We solved (4) by introducing a new group called 'plugdev'. Every user > > who is a member of this group can access hotpluggable devices (digital > > cameras, USB drives etc.). pmount can only be executed by members of > > this group (it is root:plugdev 750), hal runs in this group to be able > > to detect file systems (but it does not run in 'disk'), and udev > > assigns the 'plugdev' group to removable devices (static drives remain > > in group 'disk'). > > > > BTW, we also use 'plugdev' for libgphoto (IIRC Debian uses 'camera' > > for that). > I personally would prefer two groups. One to give access rights to the raw > device of the removable drive and one to mount them using pmount. I don't like > giving all my programs direct access, just because i'm allowed to pmount a > drive. Do the devices have to be g+w? Surely g+r is enough (or not even neccesary) for pmount to identify them as pmountable? Although I guess partitioning would require +w for the user, but in that case the user needs direct access anyway, and then dialling your USB stick becomes a distinct possibility. -- --- Paul "TBBle" Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Bug#280650: ITP: wired -- a music production and creation software
Package: wnpp Severity: wishlist * Package name: wired Version : 0.1 Upstream Author : Contact <[EMAIL PROTECTED]> Colin Laplace, Vincent Bongiorno, Coumba Nar, GrÃgory Duhamel, Diodio Sambe, ClÃment Baret * URL : http://bloodshed.net/wired/ * License : GPL Description : a music production and creation software Wired aims to be a professional music production and creation software running on the Linux operating system. . It brings musicians a complete studio environment to compose and record music without requiring expensive hardware. . Wired supports unlimited Audio/Midi tracks playback and recording, and introduces a Plugin system for instruments and effects. It can also read AKAI CDs and import 18 different Wave formats. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8.1 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Bug#280656: ITP: portmidi -- a library for real-time MIDI input/output
Package: wnpp Severity: wishlist * Package name: portmidi Version : x.y.z Upstream Author : Ross Bencina <[EMAIL PROTECTED]> Phil Burk <[EMAIL PROTECTED]> Roger B. Dannenberg <[EMAIL PROTECTED]> * URL : http://www-2.cs.cmu.edu/~music/portmusic/ * License : Modified BSD style license Description : a library for real-time MIDI input/output PortMidi is a platform independant library for real-time MIDI input/output. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8.1 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Re: Introducing pmount in Debian / New plugdev group
On Wed, Nov 10, 2004 at 04:43:41PM +0100, Martin Pitt wrote: > Marco d'Itri [2004-11-10 14:19 +0100]: > > > Our /etc/udev/udev.rules has two new rules directly after the cdrom > > > and floppy rules: > > > # put removable IDE/SCSI devices into group 'plugdev' instead of 'disk' > > > BUS="scsi", KERNEL="sd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", > > > RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev" > > > BUS="ide", KERNEL="hd[a-z]*", PROGRAM="/etc/udev/removable.sh %k", > > > RESULT="1", NAME="%k", MODE="0660", GROUP="plugdev" > > What about I ship the script in udev (as /etc/udev/scripts/removable.sh) > > and your package install the rules file? Or udev provides the rules file > > too and your package enables it by creating the symlink? > I was not sure whether it is valid that packages put their scripts > into /etc/udev/rules.d. But I would be fine to leave udev.rules > untouched and have pmount ship /etc/udev/rules.d/z_plugdev.rules (z_ > because it must be executed after the standard rules; if it is > executed earlier, CD-ROM and floppy nodes will also be in plugdev, > which is not intended). But don't CD-ROM and floppy devices also need the same sort of pmount support you're proposing here? After all, you can hot-swap the media in them, so it seems reasonable to me that they can be pmounted? What's the rationale for _not_ including these in the pmount infrastructure you're proposing? Hmm. Now that I think about it, surely the plugdev group would have to be given using pam_console so that remote users in the plugdev group can't remotely stomp on the USB memory stick the local user just put in, before they could mount it? In _that_ case, cdrom and floppy strike me as _very_ appropriate for the same treatment, and the local administrator could add appropriate people directly to those groups for things like a headless server where someone whacks in a USB stick, and then wanders back to their laptop to access it. This would close (to my mind) a security hole in systems where both local and remote users have access. -- --- Paul "TBBle" Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Introducing pmount in Debian / New plugdev group
On Thu, Nov 11, 2004 at 09:07:12AM +0100, Martin Pitt wrote: > Hi! > > Paul Hampson [2004-11-11 10:03 +1100]: > > But don't CD-ROM and floppy devices also need the same sort of pmount > > support you're proposing here? After all, you can hot-swap the media in > > them, so it seems reasonable to me that they can be pmounted? What's the > > rationale for _not_ including these in the pmount infrastructure you're > > proposing? > CD-ROMs are fully supported by pmount; hal runs in both floppy and > cdrom group as well, so that media check and file system detection > works. > The only problem are floppies, because there is no sysfs entry for the > floppy device. That means that pmount cannot currently decide that > /dev/fd0 is removable and will refuse to mount it. However, this is > not a big practical problem since legacy floppies are usually present > in /etc/fstab. If a device is already in fstab, pmount > behaves _exactly_ like mount . This fallback allows to use > pmount as a complete replacement of mount in e. g. > gnome-volume-manager. > Maybe there is a misunderstanding here: pmount itself does not care > about the group of a device. pmount decides whether or not the user is > allowed to mount a device by looking at sysfs, not at device > permissions. Ah, thankyou. I did indeed have it ass-backwards. >_< _That_ way 'round, I like it. ^_^ -- --- Paul "TBBle" Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Bug#278246: Cannot help anymore
Since my computer died in an HDD crash, I cannot help with package versions etc. All I can say is that the packages were of late October and the system was heavily upgraded (a February snapshot with tons of upgrades) but it didn't have any broken packages. Now I have to live with an extremely outdated Red Hat 8.0, so I don't know if the bug persists in Debian. Perhaps, if no one can reproduce it, the bug should be closed. Paul
Re: Bug#283903: ITP: dbconfig-common -- common framework for packaging database applications
On Thu, Dec 02, 2004 at 12:29:33AM -0500, Sean Finney wrote: > Package name: dbconfig-common > Version : 0.7 > Upstream Author : sean finney <[EMAIL PROTECTED]> > URL : > http://people.debian.org/~seanius/policy/dbconfig-common.html > License : BSD > Description : common framework for packaging database applications > > dbconfig-common is an implementation of the "best practices for database > applications" (http://people.debian.org/~seanius/policy/dbapp-policy.html) > draft, which provides debian packagers with an easy, reliable, and > consistant method for managing databases used by debian packages. > currently, only support exists for mysql databases, but i'm now > working on integrating postgresql support too. i've started > an alioth project if anyone is interested in helping out. _Sweeet!_ What's the timeframe on seeing this? And any chance of it making Sarge? -- --- Paul "TBBle" Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On Fri, Dec 03, 2004 at 10:53:56PM -0200, Gustavo Noronha Silva wrote: > What I think should be done is pictures of a man should be added to the > package *or*, as someone else suggested, add the picture of a flower > blooming A flower may not be a good idea. For many specialists, a flower is a phallic representation. I could hurt some people's sensibility. Paul
Re: charsets in debian/control
On Sun, Dec 05, 2004 at 04:42:24PM -0500, Daniel Burrows wrote: > On Sunday 05 December 2004 03:32 pm, Jose Carlos Garcia Sogo wrote: > > > Would Peter permit me a mild dissent? I prefer Latin-1. Reason: I can > > > recognize and distinguish Latin-1 characters, even when I do not always > > > understand the words they spell. Recognizing and distinguishing the > > > characters is important to me. And not just to me. Imagine the dismay > > > of a Korean user trying to read Arabic script in a control file. > > But the only field in UTF8 should be Maintainer, and that field should > > have (IMHO) also a roman transliterate for the name, if you don't use a > > latin charset (Greek, Arabic, Japanese, Chinese...) > Well, when aptitude gets UTF8 support, it'll decode all the control fields > that are mainly meant for human consumption: that means at least Description > in addition to the Maintainer field, and maybe also Section. > I don't see any reason to limit ourselves in the long term by sticking to > Latin1 (or ASCII) just because none of us can read all of the languages that > are available in the extended UTF8 namespace. If we want people to stick to > certain subsets of UTF8, that should be determined in Policy, not the > packaging software. > If you want a practical concern (aside from, say, a general suspicion of > building policy into software tools), consider these cases: > -> Someone wants to translate the Description fields of all packages in > Debian into Chinese or Arabic. What will they do if the package tools only > support Latin-1? > -> Someone wants to use the Debian packaging tools to create a new > distribution for use in China. Again, what will they do if the package tools > only support Latin-1? Isn't there a proposal around for Description#en: Description#ja: etc? I can see that this would have to be split somehow to avoid the Packages file suddenly filling CD1 on its own, but... -- Paul "TBBle" Hampson, [EMAIL PROTECTED] 7th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. signature.asc Description: Digital signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On Sun, Dec 05, 2004 at 06:38:30PM -0600, Ron Johnson wrote: > On Sun, 2004-12-05 at 13:16 -0500, Nick Sillik wrote: > > On Sun, 2004-12-05 at 16:22 +0100, Paul Plop wrote: > > > A flower may not be a good idea. For many specialists, a flower is a > > > phallic representation. I could hurt some people's sensibility. > > I was thinking that we could use pictures of the Eiffel Tower or > > Washington Monument in various stages of construction. > "skinnable" images is the best idea in this situation. That way, > whatever pictures you want, you can have. Isn't the skin the problem? -- Paul "TBBle" Hampson, [EMAIL PROTECTED] 7th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. signature.asc Description: Digital signature
Re: charsets in debian/control
On Mon, Dec 06, 2004 at 09:26:57AM +0900, Mike Hommey wrote: > On Mon, Dec 06, 2004 at 09:54:36AM +1100, Paul Hampson <[EMAIL PROTECTED]> > wrote: > > Isn't there a proposal around for > > Description#en: > > Description#ja: > And you'd advocate to write the English text in latin1 and the japanese > text in euc-jp ? > Let's make it clear: 1 text file, 1 encoding. No, I'm advocating the whole thing be UTF-8, to support the above sensibly. Sorry I wasn't clearer. -_-; (On the other hand, I'd _love_ to see rules files written in other languages, as long as the programs being called have manpages in English. ^_^) -- Paul "TBBle" Hampson, [EMAIL PROTECTED] 7th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. signature.asc Description: Digital signature
Re: charsets in debian/control
On Mon, Dec 06, 2004 at 01:40:27AM +, Andrew Suffield wrote: > On Sun, Dec 05, 2004 at 09:32:00PM +0100, Jose Carlos Garcia Sogo wrote: > > But the only field in UTF8 should be Maintainer, and that field should > > have (IMHO) also a roman transliterate for the name, if you don't use a > > latin charset (Greek, Arabic, Japanese, Chinese...) > The transliterated field should be called 'Maintainer'. If you want > some other freaky encoding, unsupported by the older tools, put it in > a new field. Using the old field just breaks stuff for no reason. I like this idea... As I recall, people can throw new header fields in willy-nilly, so people can as of _now_ put... Maintainer-Name: for example. The email address isn't important, since that has to be a subset of ASCII anyway. Apart from documenting correct orthography though, I'm not sure if this has any importance in terms of the tools... Changelogs would presumably continue to match the Maintainer: field, and so they would include the ASCII transliteration of the name. -- Paul "TBBle" Hampson, [EMAIL PROTECTED] 7th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. signature.asc Description: Digital signature
Re: Duelling banjos or how a sane community goes crazy
On Mon, Dec 06, 2004 at 04:33:28PM +0900, Mike Hommey wrote: > On Mon, Dec 06, 2004 at 08:12:50AM +0100, Andreas Tille <[EMAIL PROTECTED]> > wrote: > > I hope all you people are aware that you are causing a new duelling banjo > > case and helping out Google to connect Debian with hot-babes. > Waw, 20th hit on google:hot babe for the german article. On the other hand, the program itself is the number one google hit for both hot babe and hot-babe. The Debian discussion thereof _ought_ to be right up there. ^_^ -- --- Paul "TBBle" Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Depending on Virtual Packages (Public Service Announcement)
On Tue, Dec 07, 2004 at 09:45:33PM +, Ari Pollak wrote: > Daniel Burrows debian.org> writes: > > When your package Depends upon or Recommends a pure-virtual package P, > > you > > should always OR the dependency with a dependency on something that > > provides > > P, > As a totally offtopic suggestion, how come APT doesn't handle virtual packages > the way Fink does, where the user gets to choose which virtual package to > install to satisfy the dependency? Probably because apt is a back-end (nominally) and so doesn't do a lot of questioning. Certainly things like aptitude, synaptic, dselect etc. should. And possibly they do. ^_^ -- --- Paul "TBBle" Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: dselect survey
Florent Rougon <[EMAIL PROTECTED]> writes: > I've always thought that people who say they hate dselect (or, worse, > that dselect is crap) fall into one of the following cases: > > (a) allergic to text-mode interfaces > (b) type or click without thinking > (c) haven't used it for more than 5 years (I don't know how dselect > was > before slink) > (d) didn't bother to read the "dselect for beginners" tutorial or any > similar introductory document > (e) have had problems with packages that didn't install, upgrade or > configure correctly and wrongly blamed dselect for these > problems. On Fri, Dec 10, 2004 at 12:13:29PM +0100, Florent Rougon wrote: > (f) bash dselect 'cause someone else said it was crap I'll vote for (f) then. I remember very early on in my Debian experience, reading an email signature here that quoted someone as saying "dselect has an interface that scares small children". And I must confess the couple of times I've had an installation process start dselect for me, I've ended up Control-Cing out since I couldn't work out how to make it do what I wanted. (I guess this also means (d)) I don't think that's five years ago, but it's probably quite close. ^_^ On the other hand, I don't think I've tried aptitude, or I tried it and had the same problem. apt-get and apt-cache are my friends, and I love them for letting me specify what I want to do in a way that is intuitive to me. Altough I wish I could tab-complete package names sometimes. ^_^ -- --- Paul "TBBle" Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: charsets in debian/control
On Sat, Dec 11, 2004 at 04:08:12PM +0100, Shot (Piotr Szotkowski) wrote: > Hello. > Paul Hampson: > > The email address isn't important, since > > that has to be a subset of ASCII anyway. > Are the Unicode-encoded domain names > supported in (modern) browsers only? > > I can surf to http://Å.pl/ (with, e.g., Firefox) - can I send mail to > [EMAIL PROTECTED], or should I always use the [EMAIL PROTECTED] equivalent, as > the Unicode in domain names is restricted to WWW only? Good point. Others have pointed out that you can. And the flipside is, can I post to [EMAIL PROTECTED] RFC2821 says: Local-part = Dot-string / Quoted-string Quoted-string = DQUOTE *qcontent DQUOTE1 While the above definition for Local-part is relatively permissive, for maximum interoperability, a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form or where the Local-part is case-sensitive. For any purposes that require generating or comparing Local-parts (e.g., to specific mailbox names), all quoted forms MUST be treated as equivalent and the sending system SHOULD transmit the form that uses the minimum quoting possible. Systems MUST NOT define mailboxes in such a way as to require the use in SMTP of non-ASCII characters (octets with the high order bit set to one) or ASCII "control characters" (decimal value 0-31 and 127). These characters MUST NOT be used in MAIL or RCPT commands or other commands that require mailbox names. == RFC2821 doesn't give more detail than that about Quoted-string, so I presume we would have to use something like the ACE encoding used for domain names. A quick google didn't show up anything concrete, so I have _no_ idea what çå would look like as an email box on my mail server. I certainly think RFC2047 would be a bad idea: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?= (I have no idea what that says, I grabbed it from the RFC. It's base64 or something quite like it) So the short answer is the email address in SMTP has to be a subset of US-ASCII, but domain names can be handled by libidn and local-parts are still in need of a standard. -- --- Paul "TBBle" Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Filing bugs with upstream
On Fri, Dec 17, 2004 at 09:26:44AM +1100, Ian Wienand wrote: > So say I've found a bug in Nautilus that exists in upstream. Gnome > has a well maintained bugzilla where I can file the bug. Do I then > file a Debian bug pointing to the Gnome bugzilla report? I do I file > a Debian bug and point the Gnome Bugzilla report to it. Or do I just > file a Debian bug and hope the maintiner files one upstream? I'd say, file a bug upstream, then file a bug in Debian with the upstream bug number and tagged +upstream, and then comment on the upstream bug with the Debian bug number. It largely depends on the relative responsiveness of upstream and the Debian maintainer, which can only be learnt by trying this and seeing what happens next. -- --- Paul "TBBle" Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Status of Kernel 2.4.28 packages?
On Sun, Jan 02, 2005 at 08:02:25PM -0600, Steve Greenland wrote: > On 02-Jan-05, 15:54 (CST), Stephan Niemz <[EMAIL PROTECTED]> wrote: > > By the way, is there a guide somewhere telling how to switch an > > "unstable" system from 2.4 to 2.6? > > apt-get install kernel-image-2.6. Also module-init-tools. I got burnt by this recently when I modularised my kernel and was mystified that my network card had disappeared. -- Paul "TBBle" Hampson, [EMAIL PROTECTED] 7th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. signature.asc Description: Digital signature
Re: Diversion of APT tools by dpkg-cross (apt-get,apt-cache,apt-config)
On Tuesday, Feb 1, 2005, Raphael Bossek writes: > >Hi, > >I'm a active member of the dpkg-cross package part of the www.emdebian.org >project. > >A long outstanding feature request was to support APT for dpkg-cross. The >realisation >result in diversion of apt-get, apt-cache and apt-config which is our CVS >pending for >a new release to experimental as soon as the APT wrapper is stable. > >The Debian Policy Manaual advice me to discuss this diversion here. Please >feel free >to comment the consequences of this diversion. > >dpkg-cross provide a extension for apt-get, apt-cache and apt-config with the >command >line option -a|--arch where your cross-host architecture can be specified. >This arch >is by default your architecture your are developing for using a cross-compiler >suite. > >If no architecture (-a|--arch) is specified the original implemenations >apt-get, >apt-cache and apt-config are executed instead so nothink changes for those >uses who >do not use this extension. > >>From my point of view the extension of the APT tools by diversion do not >>break today >functionality. It was one gole not to break today functionality! > >-- >Raphael Bossek I think that -a is only really useful if you can also easily specify the --root option to dpkg. Right now the only way to get apt to do this is by modifying some of the Dir:: variables and wedging --root= into the Dpkg::options and... well, it's less than trivial. So some way to do that would be a good idea, I think. Just my .02 from trying to get apt and apt-build to work with dpkg-cross awhile back. --pj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#293292: ITP: btexmms -- XMMS plugin to use some (Sony) Ericsson phones as a remote control
On Wed, 2005-02-02 at 10:41 +0100, Peter 'p2' De Schrijver wrote: > * Package name: btexmms xmms plugins would be better named xmms- (btexmms for the source should be fine though) > Version : x.y.z > Upstream Author : Name <[EMAIL PROTECTED]> > * URL : http://www.example.org/ > * License : (GPL, LGPL, BSD, MIT/X, etc.) mmh, looks like it lacks a few info here... > Description : XMMS plugin to use some (Sony) Ericsson phones as a > remote control what is the name of the feature provided by 'some (Sony) Ericsson' ? imo, it would looks better with that name instead. > This plugin allows using some Ericsson and Sony Ericsson phones as a remote > control for XMMS. Phones which are known to work are the SE T68i and the > SE T610. The plugin uses the accessory commands documented in the > Ericsson R320 manual. any chance this documentation can be shipped with the package itself ? ciao, piem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#293167: ITP: request-tracker3.4 -- Extensible trouble-ticket tracking system
o archive-bloat. I consider it a risk of unstable, and basically ignorable in stable (how often are you dist-upgrading a stable machine?) but I was spoilt by living on campus with an on-campus mirror for my unstable machines to beat upon, so I can't say I've suffered at all from it. > Libraries are the way they are because they are the way they are. If they > weren't the way they are they wouldn't be the way they are. If RT's a > library, start defining API compatibility and package it like a library -- > lib* prefix and all, so people know what they're getting into. It's not a library, it's a large data-driven application, and the framework that data's structured into changes between releases, making it hard to autoupdate the data to match the new library. I think bringing libraries into the dicussion was another poster's... straw man? (I'm not sure that's the right logical fallacy) and doesn't help at all. I will say, I'm not _100%_ convinced that request-tracker needs to have 3.4 and 3.2 packages, but I am certainly more convinced of that than I am convinced that there's no need for seperate packages. _My_ usage of it is probably one that could survive a dist-upgrade to 3.4, but I'm only one user who hasn't bothered customising it much. -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: execturing libc
On Fri, Feb 04, 2005 at 10:37:03PM +0100, Goswin von Brederlow wrote: > Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > > > On Fri, 04 Feb 2005, Goswin von Brederlow wrote: > >> The way to circumvent a noexec is to call the dynamic linker like I > >> did for libc: > >> > >> /lib64/ld-linux-x86-64.so.2 > > > > Is it? In sid, ia32: > > /lib/ld-linux.so.2 ./test > > ./test: error while loading shared libraries: ./test: failed to map segment > > from shared object: Operation not permitted > > > > This is a noexec partition. > > > > /lib/ld-linux.so.2 /bin/ls > > test test.c test.sh > > > > This is an exec partition. > > > > > > The hole is/has being/been closed. > > It still lets you execute files that don't have the executable flag > set like libc. It's a different bug but it's still there. Is that a bug? I can run -x perl scripts with perl so why not -x ELF scripts with /lib/ld-linux.so.2 What stops me taking a copy of the binary, making it +x and running that anyway? So I don't see any security concern... -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Bug#294209: ITP: reminiscence -- REminiscence is a rewrite of the engine used in the game Flashback from Delphine Software
On Tue, Feb 08, 2005 at 07:23:44PM +0100, Moritz Muehlenhoff wrote: > In linux.debian.devel, you wrote: > >> Description: free implementation of Delphine Software's FlashBack engine > >> REminiscence is an engine capable of runing any game based on the > >> FlashBackengine. > >> . > >> To actually make use of ScummVM, you currently need to get the orginal > >> FlashBack game data-files > >> > > Did you mean ScummVM there? > REminiscense follows the principle way ScummVM works, but it's an independant > implementation in SDL. > There has been a similar attempt to provide a free engine for Flashback, which > the author withdrew after the original producer contacted him. (I forgot the > name > of the project). Are there similar issues for REminiscense? You're not thinking of "Another World" are you? http://membres.lycos.fr/cyxdown/raw/ (That's the same person who's writing REminiscence) I had them confused in my head, anyway. ^_^ -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Bug#291945: eleventh-hour transition for mysql-using packages related to apache
On Sat, Feb 12, 2005 at 08:25:41PM +0100, Francesco Paolo Lovergine wrote: > On Sat, Feb 12, 2005 at 09:17:44AM -0800, Steve Langasek wrote: > > On Sat, Feb 12, 2005 at 09:53:34AM +0100, Francesco Paolo Lovergine wrote: > > > > > Nice, so we should check that any linked GPL library directly > > > > > (obviuolsy) or > > > > > indirectly (with N=1,2,3... levels of indirection) linked against > > > > > openssl adds the exception. > > > > No, we should simply not be linking libmysqlclient against OpenSSL. The > > > > exemption was needed because there exists software that uses both > > > > libmysqlclient and libssl, but making libmysqlclient itself use libssl > > > > just > > > > because we now have the exemption will cause licensing problems for > > > > applications which currently do *not* depend on libssl. > > > That's clear, I meant simply that if program A links libB which links libC > > > which links libssl, than both A, libB and libC should add the exception, > > > isn't it? That's independently from having A using libssl functions > > > directly or not. > > That's true; I'm merely pointing out the importance of not turning > > libmysqlclient into libC here. > So what if we had two editions of libmysqlclient, one of them > ssl-enabled and the other - as currently - not? That would allow > using ssl whenever possible. I think that could be done, without > breaking things. That's funny. Didn't we spend all that time since Woody merging lib-*-ssl back into lib-*? -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Cross-compiling and dist-cc (Was: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]))
On Tue, Feb 22, 2005 at 12:44:27PM +0100, Wouter Verhelst wrote: > On Tue, Feb 22, 2005 at 08:48:48PM +1300, Nick Phillips wrote: > > Running such a system in parallel with the current systems (and comparing > > the outputs) might be a good test for gcc-as-cross-compiler, then... > And a hell of a lot of work. You can't just create checksums of the > resulting binaries and compare those; it's not as if any difference > between the two compiled binaries would constitute an error... Why not? Is there something non-deterministic in the compilation process? Ideally, version x of gcc should produce the same output natively as when cross-compiling. Or have I missed something important? (I'm actually quite fond of the idea of dist-cc sending pre-processed C code to remote (faster) machines and getting unlinked object code back. I haven't got a good use for it yet, but the _idea_ is neat.) -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: First line in /etc/hosts
On Sat, Feb 19, 2005 at 12:13:34AM -0200, Henrique de Moraes Holschuh wrote: > Also: As far as the kernel is concerned, any local IP is local to *all* > interfaces, and it will happly reply to it (ARP and so on) if allowed to. > The rp_filter will often avoid trouble here, BUT routers often have to > disable rp_filter. So add some rules to the firewall make sure nothing gets > into 127.0.0.0/8 unless it is a local packet. Can't you just leave rp_filter on for lo, or disable it only on those interfaces on which you are likely to see asymmetric routes arriving? -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: [OT] maildir (was Re: procmail and Large File Support)
On Sun, Feb 27, 2005 at 06:51:32PM -0600, Ron Johnson wrote: > On Sun, 2005-02-27 at 18:19 -0500, sean finney wrote: > > recent versions of kernel/ext2/ext3 have built-in dirent hashing, which > > cuts heavily on the many-files penalty. another benefit of maildir > > is that when you modify a single message, you only need to modify the > I thought it was "illegal" to modify a message. "Status: O"? -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: mplayer, the time has come
On Mon, Feb 28, 2005 at 10:19:37AM +0100, A Mennucc wrote:
> Sebastien NOEL wrote:
> >I have some questions about your package:
> >* You build libavcodec and libavformat but that seems to me a waste of
> >time.
> > FFmpeg is already in main, why not only link mplayer with
> > libavcodec.a (libavcodec-dev) and libavformat.a (libavformat-dev) ?
> choice of upstream : AFAICR a monolithic 'mplayer' improves performances
You've missed the point. If you use the libavcodec-dev and
libavformat-dev packages in Debian, you _get_ a monolithic
mplayer. Those packages only contain the static libraries,
which are linked in at compile time, since the packager has
chosen to not produce dynamic libraries for these two libraries
(for a different reason, I suspect, to do with the fluidity of
the libraries' APIs)
And even if libav{codec,format} had shared libraries in Debian,
the static versions in the -dev could be linked in, and I
understand that's the default way mplayer's configure script
accesses external libav{codec,format}.
If you use the ones in Debian, that's one less thing people
need to recompile to rebuild mplayer, like using external
libflac, libsdl etc, and it's easier to rebuild a local
mplayer with the latest lib{avcodec,format} versions, assuming
the packager of those is tracking CVS closely.
--
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]
"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"
This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---
signature.asc
Description: Digital signature
Re: Bug#297233: ITP: wmansied -- An ANSI/ASCII editor.
On Mon, Feb 28, 2005 at 06:11:51PM -0600, Joe Wreschnig wrote: > On Mon, 2005-02-28 at 21:28 +, Roger Leigh wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > "Nelson A. de Oliveira" <[EMAIL PROTECTED]> writes: > > > WMAnsiEd is an ANSI editor with functions like line drawing, ellipse, > > > box, etc., written in Qt. All IBM ANSI and ASCII characters are > > "ANSI" is pretty meaningless as a "standard", since ANSI standardised > > many different things. Perhaps you mean it implements ISO-6429 > > (ECMA-48) SGR control sequences, or maybe something entirely > > different? Either way, it would help if you were much more specific. > > (This applies equally to the other ITP.) > For most of us who grew up on IBM PC systems in the DOS days, "ANSI" was > a character set / graphics style first, and an organization second. I > don't know what the official standards for the character set and > terminal specifications are, but people who are interested are going to > be looking for "ANSI" or "ANSI graphics", not a standards document > number. A bit of googling produced [1] which points at ANSI's "Advanced Data Communication Control Procedure (ADCCP) X3.64-1979". And yes, that's ISO-6429/EMCA-48. ^_^ So it proably should be described as an "ANSI X3.64-1979/ISO-6429/ECMA-48 (aka ANSI, in the domain of modem-based BBS)" or something, so that an apt-cache search will pick it up for "ANSI BBS" while not fuelling the fires of controversy and ignorance, as it possibly does now. ^_^ (Also, Cricket gives a listing of the various whacky X.364 implementations. ^_^ [3]) [1] http://www.geocities.com/TimesSquare/Fortress/2756/graphics.html [2] http://astronomy.swin.edu.au/~pbourke/dataformats/ansi.html [3] http://www.columbia.edu/kermit/gloss.html -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Bug#297606: ITP: unionfs -- Stackable Unification File System
On Wed, Mar 02, 2005 at 09:48:52AM +0100, Roberto Suarez Soto wrote: > On Mar/01, Eduard Bloch wrote: > > unionfs is a Linux kernel driver that provides a unification file system > > which can appear to merge the contents of several directories > > (branches), while keeping their physical content separate. > I've used this, but briefly, in NetBSD. So maybe I'm missing something > when I ask: how is this different from "mount --bind" in kernels 2.4 and up? Hmm. I misread this as the oft-wished-for transparent overlay filesystem. Either I'm daft, or the naming/description might need work... "merge" is possibly the wrong word here? -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
fftw3 non-pic k7 optimisations
Hi all, I am trying to get rid of fftw3 non position independant code brought on i386 by the --enable-k7 configure flag. As dropping these K7 optimisations gets rid of the non-pic, the problem seems to lie in dft/k7/codelets/, which are generated by ocaml scripts found in genfft-k7/. Two questions: - can anyone spot what in these codelets causes the non-pic ? - how much can it hurt to have this non-pic in fftw3 ? Cheers, piem signature.asc Description: Digital signature
Re: fftw3 non-pic k7 optimisations
On Wed, Mar 02, 2005 at 05:16:50PM +0100, Florian Weimer wrote: > * Paul Brossier: > > > Two questions: > > - can anyone spot what in these codelets causes the non-pic ? > > Tables of constants are addressed directly, not in some IP-relative > way. thanks, i thought this could be sort of a problem. so iiuc: KP707106781KP707106781: .float +0.707106781186547524400844362104849039284835938, +0.707106781186547524400844362104849039284835938 is ok, but pfmul KP707106781KP707106781, %mm3 is not pic compliant, and should be replaced with something like pfmul KP707106781KP707106781(%ebx), %mm3 given i didn't know anything about assembly yesterday, how far am i? > > - how much can it hurt to have this non-pic in fftw3 ? > > It shouldn't matter much if all PIC code is grouped together in the > binary because few pages have to be copied in this case. PIC code > itself is always slower, significantly so if the code is using all > available integer registers. I did some tests running 1024 points ffts on an AMD 700, and the difference between with and without --enable-k7 was roughly a drop of 1.5%. The drop could become more important on K7 with smaller number of points, where k7/3dnow optimisations come in. If there is no objections, and as suggested by upstream, i will disable the k7 optimisations in order to make sure that libfftw3f.so remains PIC compliant, despite a little slower. cheers, piem signature.asc Description: Digital signature
Re: Bug#297606: ITP: unionfs -- Stackable Unification File System
On Wed, Mar 02, 2005 at 04:42:15PM +0100, Eduard Bloch wrote: > #include > * Paul Hampson [Wed, Mar 02 2005, 08:05:14PM]: > > > I've used this, but briefly, in NetBSD. So maybe I'm missing something > > > when I ask: how is this different from "mount --bind" in kernels 2.4 and > > > up? > It is different. --bind does only 1:1 copy (files are written to the > source directory, for example), unionfs puts the changed files in one of > the underlying directories. > > Hmm. I misread this as the oft-wished-for transparent overlay > > filesystem. > > Either I'm daft, or the naming/description might need work... > > "merge" is possibly the wrong word here? > Hm. Is that better: > The unionfs driver provides a unification file system for the Linux > kernel. It allows to virtually merge the contents of several > directories and/or stack them, so that apparent file changes in the > unionfs end in file changes in only one of the source directories > (which makes possible to "change" files on read-only filesystems). Ooooh. It _is_ an overlay system! That description is fine. ^_^ -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: NoX idea
On Fri, Mar 04, 2005 at 12:18:14AM +0100, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > If so... then it's flat-out not available on the set of systems in > > question > Hm? it is on all my systems: > # cat /proc/cmdline > auto BOOT_IMAGE=v2.6.8.1 ro root=811 Can we assume your systems are all Linux-based Debian? I expect neither of the BSD-type Debian ports has anything in /proc that's not a pid or self... I have a sneaking suspicion that the Hurd- based Debian port is like that too, but I've never booted Hurd. I'm not gonna speculate on the win32-based port that may or may not actually have come into existance, but I strongly doubt it has (would have) a /proc on the grounds that the win32 kernel doesn't actually have a / to mount things under... And given that even Linux itself is looking to migrate non-PID things from /proc to /sys where sensible, I wouldn't rely on things like /proc/cmdline to be around come Linux 2.8. -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Sat, Mar 05, 2005 at 12:01:47PM +0100, Josselin Mouette wrote: > Le samedi 05 mars 2005 à 00:44 +0100, Goswin von Brederlow a écrit : > > Exactly. I don't have alsa-base installed on any of my 2.6.x systems > > and some of them have sound and some don't. None of them have > > problems. > > A depends would be too strong. A recommends/suggests should be there. > I'm only pointing the issue. When you install a brand new sarge system, > sound doesn't work correctly on many kinds of hardware, because both OSS > and ALSA modules are loaded. Adding a Depends: is only a possible > solution, I'm sure there are better choices. However, I feel we > shouldn't release in this state after having spent so much efforts in > hardware detection. Hmm. I would think that the better solution (the less surprising solution) would be to leave out the ALSA modules from the Debian kernel package, since we have a seperate package of ALSA modules which _does_ depend on alsa-base. Then a "desktop" install could offer to include them, and a non- "desktop" install could leave them out by default, or something. -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: fftw3 non-pic k7 optimisations
On Wed, Mar 02, 2005 at 10:47:34PM +0100, Bill Allombert wrote: > Hello Paul, > > You need to refer to KP707106781KP707106781 through the GOT, something > like > pfmul [EMAIL PROTECTED](%ebx), %mm3 Ok, i gave it a try, it compiles and runs fine, but i still get the 'objdump -p libfftw3f.so | grep TEXTREL' to show up. > Why do you insist to have that code be position-independant ? I could say because it is a 'must' in the debian policy, but... Given that this error occurs only on i386, that fftw3 now works fine on K7 and alike and that non-pic code does not seem to cause too much problems, i could put a lintian override for now. Upstream told me they will have that fixed in the next release. > (Sorry to be pedantic, but 'PIC compliant' is meaningless: PIC is not > a standard but an attribute) you're not, i'm learning :) cheers, piem signature.asc Description: Digital signature
Re: fftw3 non-pic k7 optimisations
On Mon, Mar 07, 2005 at 02:05:44PM +0100, Florian Weimer wrote: > * Paul Brossier: > > >> Why do you insist to have that code be position-independant ? > > > > I could say because it is a 'must' in the debian policy, but... > > There is no such requirement in the Policy. 8-) 10.2. Libraries --- The shared version of a library must be compiled with `-fPIC', and the static version must not be. In other words, each source unit (`*.c', for example, for C files) will need to be compiled twice. hrm, but yeah of course, one could say that it's fine if a library compiled with -fPIC still contains non position independant code. :) bye, piem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#276148: ITP: nsis -- Nullsoft Scriptable Install System (modified for debian)
retitle 276148 ITP: nsis -- Nullsoft Scriptable Install System (modified for debian) retitle 276153 ITP: nsis -- Nullsoft Scriptable Install System (modified for debian) owner 276148 ! owner 276153 ! thanks for the banana republic :( More info and a long description about the version I intend to package: * Package name : nsis Version : 2.05 Upstream Author : Amir Szekely <[EMAIL PROTECTED]> * URL : http://nsis.sourceforge.net/ * License : zlib/libpng License Description : Nullsoft Scriptable Install System (modified for debian) An installer is the first experience of a user with your application. Slow or unsuccessful software installations are the most irritating computer problems. A quick and user friendly installer is therefore an essential part of your software product. NSIS is a tool that allows programmers to create such installers for Windows. It is released under an open source license and is completely free for any use. NSIS creates installers that are capable of installing, uninstalling, setting system settings, extracting files, etc. Because it's based on script files, you can fully control every part of your installers. The script language support variables, functions, string manipulation, just like a normal programming language - but designed for the creation of installers. Even with all these features, NSIS is still the smallest installer system available. With the default options, it has an overhead of only 34 KB. -- bye, pabs signature.asc Description: This is a digitally signed message part
Re: Serious kernel problems on new i386 hardware
On Thu, Mar 10, 2005 at 03:10:12PM +0100, Andreas Tille wrote: > Hi, > I've got a new Dell machine which I was able to install with Kernel 2.4.27. > It has a SATA drive but I disabled SATA in BIOS according to the manuals. > All I write in the following has this SATA disabled BIOS setting. > As I said kernel 2.4.27 works fine. I attach a dmesg and syslog to this > mail. > I tried to upgrade to a 2.6.x kernel but failed always with kernel_panic. > I tried 2.6.8, 2.6.8 and 2.6.10 (here -1-386 and -1-686 versions) and > all failed with the same result: > pivot_root: No such file or directory > /sbin/init: 432: cannot open dev/console: No such file > Kernel panic - not syncing: Attempt to kill init! > ata: 0x1f0 IDE port busy > ata1: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15 > ata1: dev 0 ATAPI, max UDMA/33 > ata1: dev 1 ATAPI, max UDMA/33 > ata1: dev 0 configured for UDMA/33 > ata1: dev 1 configured for UDMA/33 > scsi0 : ata_piix > elevator: using anticipatory as default io scheduler > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > ide0: I/O resource 0x1F0-0x1F7 not free. > ide0: ports already in use, skipping probe > ide1: I/O resource 0x170-0x177 not free. > ide1: ports already in use, skipping probe This is your problem here. You made your initrd under 2.4.27, where your devices where /dev/hd?. However, 2.6 with the initrd has loaded them with the SATA driver, and sees them via /dev/sd?. I think you're going to have to manuall edit your initrd and fstab to deal with the change in device name between versions. Alternatively, pull ata_piix driver out of the initrd, and see if the ide driver will load and run your disks. However, that first line (IDE port busy) worries me a little, since it seems neither driver is actually claiming the port itself. If you want to experiment, there's a command you can put on the Linux kernel command line to break into the initrd before it actually does anything, and you can see what devices exist and drivers and whatnot. I can't remember the command though. -_- -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: automake/autoconf in build-dependencies
On Thu, Mar 10, 2005 at 01:52:45PM +0100, martin f krafft wrote: > I have often tried to argue my position on automake/autoconf in > packages' build dependencies: I do not think they belong there. If > a package does not build without automake or autoconf, it is broken > and should be fixed. However, bugs like #298336 seem to suggest that > other maintainers deem it entirely appropriate to "go the easy way" > -- if I may call it that without being condescending towards Uwe. > I seem to recall the devel-reference or some similar document to > specifically address this issue, but I cannot find the location > anymore. I think you're thinking of /usr/share/doc/autotools-dev/README.Debian.gz > Thus I am interested in opinions of people who argue that > automake/autoconf are perfectly acceptable as build dependencies. > Also, are there technical arguments against these build > dependencies? I am too inexperienced with the GNU autotools to > come up with something. The arguments _for_ build-depending on the various autotools are (off the top of my head) (In the below, read autoconf as autoconf/automake. ^_^) * keeps .diff.gz small and readable, as configure changes are not included. And small configure.in changes cascade into many configure changes * This is a maintainer decision, really. Not _wrong_ per se. * timestamp skew means that the autobuilt makefiles will try to rebuild configure from configure.in even if configure is patched by dpkg-source at the same time as configure.in * A solution for this is in the above-mentioned README.Debian * Upstream distributes without generated files (eg. CVS pull) or with generated files using older or buggier versions of the autotools. * In this case, pristine source tarball means pre-autoconf, and the maintainer again wants to keep the .diff.gz small. > I am perfectly aware that there are (and should be) exceptions. For > instance, if a package should be made available sooner rather than > later, and the maintainer then sits down to work on the autotools > configuration to fix the bug for the next upload. However, this > always bears the danger that the maintainer then loses interest and > the archive will contain what I claim to be a broken source > package... even though it may well build. I'm not sure I'd consider a package that build-depends on autoconf to be _broken_ per se. I don't _believe_ this shows up anywhere in policy or otherwise that can make this a non-ignorable bug report for such a package. I welcome corrections on this point. I am particularly interested in an argument that spells out how this is broken, as opposed to "not neat in my opinion". I _do_ think it is a riskier way of dealing with a package, as I'm not sure what new features are expected to appear in autoconf that weren't in the version used at last build-time, that can be taken advantage of automatically. Surely a bugfix in autoconf would have either already caused a bugreport against the package, or have been irrelevant to the package itself? Certainly, this dubious benefit to my mind does not outweigh the risk of having a previously working build-environment suddenly break, as I vaugely recall happened when autoconf went from 2.13 to 2.53 and suddenly half of the Debian archive FTBFS. (Exaggeration used for effect. ^_^) I don't see how build-depending on autoconf etc could possibly speed up a package release, unless the maintainer is trying to move to a different autoconf version than upstream is using, and refuses to install the version upstream is using. (But is happy for the buildds to do so) In short, _I_ wouldn't do it, same as I wouldn't build-depend on flex and bison. I might not store their output in my CVS tree, but I wouldn't build-depend on them either. (And if anyone feels the need to ask me what this means in terms of 'What is source?' they get to stand between me and Andrew Suffield if I answer. ^_^) (This doesn't apply to config.sub and config.guess. I _do_ pull those at build-time, since _they_ sometimes need to be upgraded for different architectures. This is a different (controversial?) issue. ^_^) -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Serious kernel problems on new i386 hardware
On Fri, Mar 11, 2005 at 12:51:16PM +0100, Andreas Tille wrote: > On Thu, 10 Mar 2005, Jesús Roncero wrote: > > >I've recently had those problems also on a Dell server, using SATA too. The > >fine guys from #gpul helped me a lot on this. Basically, what happened to > >me > >is that kernel 2.4 mapped the SATA drive as /dev/hdc and kernel 2.6 mapped > >it > >to /dev/sda > Well, after doing an > > sed -i "s/hda/sda/" /etc/fstab > > __AND__ > > switching BIOS from "conventional" (=no SATA) to "normal" (=SATA) > > __AND__ > > changing grub boot menu from > >kernel /boot/vmlinuz-2.6.10-1-686 root=/dev/hda3 ro > to >kernel /boot/vmlinuz-2.6.10-1-686 root=/dev/sda3 ro > it worked. I really regard this problem as serious because it probably > leaves people with SATA hardware with an unbootable system after > kernel-image > updates, because the kernel image packages just reinsert "root=/dev/hda?" > into grub's menu.lst . Any idea how to solve this problem? The updates do _what_? Rather than changing that entry in grub's list, find the section like this: ## ## Start Default Options ## ## default kernel options ## default kernel options for automagic boot options ## If you want special options for specifiv kernels use kopt_x_y_z ## where x.y.z is kernel version. Minor versions can be omitted. ## e.g. kopt=root=/dev/hda1 ro # kopt=root=/dev/ide/host0/bus0/target0/lun0/part5 ro and change that last line to be: (Assuming your 2.4 kernel is 2.4.27) # kopt=root=/dev/sda3 ro # kopt_2_4_27=root=/dev/hda3 ro and run update-grub. That should autogenerate the grub-used sections -- the ones without any '#' in front, after ## ## End Default Options ## And future 2.6 installs will get the right device (the sda one) and if you install any further 2.4 kernels you'll have to make another "# kopt_2_4_xx=root=/dev/hda3 ro" line and rerun update-grub. You can check the output in the lower section, and make sure it's generating sensible grub entries. The use labels for the rest of your data partitions, and... I dunno, put both /dev/hda3 and /dev/sda3 in your swap list? Let your 2.4 kernel boot without swap until you manually activate it? Solve to taste, and serve with a side of "I hope that helps". ^_^ Hmm. This assumes you're using update-grub and the Debian-supplied/ maintained grub/menu.lst. If not, then... well, don't lose your paddle. -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: automake/autoconf in build-dependencies
On Mon, Mar 14, 2005 at 01:18:12AM -0500, Kurt B. Kaiser wrote:
> Machine generated files (e.g. configure) constructed by autotools
> should not be in CVS.
> However, these files (as generated by the Debian maintainer's autotools
> run before the upload) should be included in the source package via the
> .diff.gz. so that the user doesn't need autotools.
> Therefore, the Debian maintainer should run autotools using current
> config.{sub,guess} before the diff.gz file is generated, possibly via
> an 'autogen.sh' script.
I think you got this last big backwards. config.{sub,guess} are used by
the configure script, not autoconf. So you can run autoconf at
package-source creation-time, and still gain the benefits of current
config.{sub,guess} at package (re)build-time. In fact, I believe that
was the original motivation for autotools-dev, since config.{sub,guess}
needed to be updated due to the fluidity of some ports (I think the
mips, sh and BSD ports were/are the most common "FTBFS: Update
config.{sub,guess}", but I could be wrong.)
--
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]
"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"
This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---
signature.asc
Description: Digital signature
Re: Another load of typos
On Tue, Mar 15, 2005 at 05:32:10AM +0100, Florian Zumbiehl wrote: > HPGL > HTML > HTTPS These three vary because the letter H is pronounced starting with either a 'h' (haich) or an 'a' (aich). This is _probably_ a distinction between American and British English, although it was originally a distinction between social class of the speaker of British English. (cf. Pygmalion, I believe) But I don't know which one's which. For me, "An aich-pee printer" sounds just as good as "a haich-pee printer". I just wanted to mention it, and also because this way I can have "pee" associated with the Debian mailing lists in google. ^_^ -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Another load of typos
On Thu, Mar 17, 2005 at 11:20:12PM +1100, Hamish Moffatt wrote: > On Thu, Mar 17, 2005 at 10:59:34AM +, Will Newton wrote: > > On Thursday 17 March 2005 03:16, Florian Zumbiehl wrote: > > > ... and probably not for (that is, not unless you tell me otherwise): > > > > HPGL > > > > HTML > > > > HTTPS > > Traditionally I think these would use "an". Even if you pronounce "h" as > > "haich" rather than "aich" as another poster pointed out, many words > > beginning with "h" such as "historic" or "horrendous" require "an" in > > formal > > writing e.g. "an historic achievement". > (This might be a topic without a possible conclusion!) > Funny, but although I'd say "an HTML file" or "an HTTPS url" or > similar, I'd say "a history achievement". That's right. Usually when you pronounce the letter 'haich', it's silent word-initially. When you pronounce it 'aich', it is audible at the start of the word. Or I _think_ that's the case. And at least for these words, they are all abbreviations, as none of them are pronouncable as acronyms. So they are all governed by the local pronounciation of 'H', not the local pronounciation of 'hotel'. > But then we say aich not haich here. I'd say "an HP printer" or "a historic occasion", but if I saw it written "a HP printer" I'd read it "a haich-pee printer" without qualm. And for some reason, everytime I try, I get "a HTML document". So I'm not even consistent in my own usage. Probably because Australian English seems to be influenced by both British and American pronounciation, in the same way that route is understandable in either pronounciation, although then I know the linguistic background of the speaker's English. ^_^ However, this is a pronounciation rule, not a spelling rule, so it's up to the author to write it by speaking it out loud. So I consider these to the uncorrectable automatically, even from the standpoint of paragraph-internal consistency. ^_^ -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Another load of typos
On Thu, Mar 17, 2005 at 01:05:02PM -0800, Steve Langasek wrote: > On Thu, Mar 17, 2005 at 09:04:14AM -0800, Thomas Bushnell BSG wrote: > > Hamish Moffatt <[EMAIL PROTECTED]> writes: > > > (This might be a topic without a possible conclusion!) > > > Funny, but although I'd say "an HTML file" or "an HTTPS url" or > > > similar, I'd say "a history achievement". > > Ah, in "a history achievement", you accent the first syllable of > > "history", which provokes you to pronounce the H. In "an historic > > achievement", the first syllable of "historic" is weak, and so most > > Americans (at least) do not pronounce the H, and so we use "an". > The only people I can recall ever hearing say "an historic" in en_US were > idiot politicians, and they *did* pronounce the initial h. > For that matter, I can't recall ever hearing anyone drop an initial h just > because the syllable was unstressed. > On what do you base this claim of "most"? Bill Walsh (copy editor at The Washington Post) has given this topic a reasonable going over [1], and comes out with the answer that American Standard English is "a h*" but seems to concede that when the second syllable of the h-word is stressed, the first can be weakened and the 'h' may disappear, leaving 'an *' (Which sounds like "anistoric event" to me). On the other hand... "The stylebook of the London Times calls for an hotel, an historic and an heroic. But, remember, that's British English." As to when the second syllable of a h-word is stressed, that's an exercise for the speaker. ^_^ [1] http://www.theslot.com/a-an.html -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Building windows versions of debian packages
On Sat, 2005-11-19 at 23:02 +0100, Enrico Tassi wrote: > mh... I do not completely agree... I think a separate repo should be > the way to start... but at the end I would like to see these packages > in debian... the best developing environment (not only the best OS). > > If you want to start this nice "project"... > I can help a bit Perhaps the people on the debian-win32 list (or its archives) can be used as a starting point? -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Re: dpkg-sig support wanted?
> A cryptographer friend of mine recently attended the NIST Hallowe'en > Hash Bash (http://www.csrc.nist.gov/pki/HashWorkshop/index.html), and > made a few notes in his blog: > > http://www.livejournal.com/users/sevenstring/7326.html > > His suggestion there was "stick to SHA2 (or maybe Whirlpool) for now". > Did anyone else here attend this workshop? I attended, and the message I got was: use SHA-256 (or SHA-512 if you want to be cautious) for new applications, but consider it to be an interim solution for the 5-10 year timeframe until something better is devised, and have the agility to switch to that "something better" when it comes; most importantly, stop using MD5 ASAP. Regarding your friend's suggestion to "stick with SHA2 (or maybe Whirlpool) for now", what I wrote in my notes was: * Asked about which two functions would be best to use in parallel, suggestions were SHA-256+(Whirlpool/Tiger). One of the panelists explained, though, that using two different hash functions and concatenating the output yields a result which is not significantly more secure than either of the functions by itself. And the SHA family of functions were the predominant topic of the workshop; others, such as Whirlpool, were mentioned only occasionally. Some choice quotes from Niels Ferguson: "SHA-1 is a wounded fish in shark-infested waters." "Switch away from SHA-1 as soon as you can, but switch away from MD5 first." It's true that MD5 and SHA-1 are still acceptable for certain uses where the current attacks aren't a threat, but Ferguson argued that it's much easier and safer to replace them entirely than to try to analyze which uses are still OK. Also from my notes: SHA-1 is OK for ephemeral uses, but not for non-repudiation and certification -- essentially, if it matters that the signature be verified by a third party, not just the recipient, avoid SHA-1. Some people wanted NIST to specify an approximate target year for a hash standard to be issued, like they did for AES. Bruce Schneier said we don't know hashing well enough, like we knew about block ciphers for AES, and recommended that we "wait ten years". Several people requested that NIST publish the design criteria with which SHA-1 was designed, but I don't remember hearing a definitive answer to that. (Note that I'm not a cryptographer; I attended simply as an interested individual.) -- Mike Paul <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Alternate proposal for Declassification of debian-private archives
My biggest problem with all this is that it's gonna mean a lot of work - for the 'declassifying team' and for people who want to be bothered about commenting on the process is respect of particular email. Thats time that I feel could be better spent. I do understand the motives... -- Paul On Thu, Dec 01, 2005 at 08:32:59AM -0600, Manoj Srivastava wrote: > Hi, > > > Rationale: > > I have been thinking about the kinds of reasons for not > wanting to have a post to -private published. I came up with two > major (reasonable) scenarios: > > a) The post contained sensitive material. > > In this case, if a reasonable case has been made for the > material being sensitive, and one that the declassification > teams accepted, then the material should be redacted from the > post, and every post it has been quoted in. If it is sensitive > in one post, it is sensitive in another. > > b) I do not want to be associated with the post in question > > In other words, if this showed up in google it may hurt my > future job prospects post ;-). In this case, the post can be > published, just every identifying bit about the author needs > be redacted from this post and the quotes. > > This latter action would, in my opinion, allow more of some > informative, though heated, discussions to be available to posterity > . > > Also, we are, in effect, considering retroactively overturning > a published privacy policy; I think that we do need to state up front > that the copyright holders wishes would be heeded, even when the post > in question is quoted in other emails. > > Here is a diff from AJ's proposal. I am now formally seeking > seconds for this modified proposal, which has explicit guidelines for > the most common case for not wantng the posts to be published. > > manoj > > -- > In accordance with principles of openness and transparency, Debian will > seek to declassify and publish posts of historical or ongoing significance > made to the Debian Private Mailing List. > > This process will be undertaken under the following constraints: > > * The Debian Project Leader will delegate one or more volunteers > to form the "debian-private declassification team". > > * The team will automatically declassify and publish posts made to > that list that are three or more years old, with the following > exceptions: > > - the author and other individuals quoted in messages being reviewed > will be contacted, and allowed between four and eight weeks > to comment; > > - posts that reveal financial information about individuals or > organisations other than Debian, will have that information > removed; > > - - requests by the author of a post for that post not to be published > - will be honoured; > + - If the author makes a resonable case that some material is > + sensitive, then that material is redacted from that post and any > + other post where it has been quoted > + > + - If the author indicates he does not wish to be associated with a > + post, any identifying information is redacted from that post, > + and any quotes in subsequent posts, but the rest of the material > + is published. > > - posts of no historical or other relevance, such as vacation > - announcements, or posts that have no content after personal > + announcements, or posts that have no content after > information is removed, will not be published, unless the author > requests they be published; > > - comments by others who would be affected by the publication of > the post will also be taken into account by the declassification > team; > > - the list of posts to be declassified will be made available to > developers two weeks before publication, so that the decisions > of the team may be overruled by the developer body by General > Resolution, if necessary -- in the event such a resolution is > introduced (ie, proposed and sponsored), the declassification > and publication of messages specified by the resolution will be > deferred until the resolution has been voted on. > --- > > -- > Happiness adds and multiplies as we divide it with others. > Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> > 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343403: ITP: libwww-topica-perl -- Read emails from a Topica mailing list
Package: wnpp Severity: wishlist Owner: Paul Wise <[EMAIL PROTECTED]> * Package name: libwww-topica-perl Version : 0.5 Upstream Author : Simon Wistow <[EMAIL PROTECTED]> * URL : http://search.cpan.org/~simonw/WWW-Topica-0.5/ * License : Perl Description : Read emails from a Topica mailing list This module screen scrapes the Topica website and fetches back RFC822 text representations of all the mails posted to a given list. Where possible it fills in the from, to and date fields. It should be noted that in some cases it's impossible to get both the sender name and their email address. I'll need a sponsor for this module. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: switching to vim-tiny for standard vi?
On Sun, Dec 18, 2005 at 08:56:42PM +0200, Lars Wirzenius wrote: > > I'm one of the people who prefers nvi over vim. I do so quite strongly, > because I find that nvi obeys my fingers and vim does not. The Sounds like you should file a bug against your fingers then. > differences are minute, of course, but they are really irritating. > Unfortunately, I can't enlist them properly, since my fingers don't talk > to me: I notice vim's incompatibility from the fact that my fingers have If your fingers aren't talking to you, perhaps you should also list them as MIA. > to keep correcting text under vim, but not under nvi. On days when I'm > generally annoyed already, if I accidentally use vim instead of nvi, I > can get quite lyrical with my cursing. Funny - on days I'm generally annoyed already and I end up on a machine with nvi as the default vi... I can get quite lyrical with my ranting. For me, vim-tiny would be great! -- Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
On Tue, Dec 20, 2005 at 02:37:59PM +1000, Anthony Towns wrote: > > Yeah; vi not behaving like vi by default seems like a showstopper. But that is not the case. vi by default not acting like a very old and (imho) broken version of vi... is not a showstopper. I love vi - and I love the progress vim has made to make use of vi quicker/better/easier. I don't see that the world has to be stuck in 1985 - should we still be shipping a linux kernel version 1? -- Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Powerfulness (was: tioga : a powerful plotting system in ruby)
On Sat, 2006-01-07 at 23:52 +0100, Juergen Salk wrote: > I am just wondering if we shouldn't be more chary of using > meaningless (or soliciting) phrases like "powerful" in > package descriptions in general. Sounds like something that should be added to lintian. I suggest filing a wishlist bug with a patch. I recently made a lintian patch to check for best-practice homepages in the description field, which was easy, just modify checks/description and checks/description.desc. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#347202: ITP: xmms-midi -- MIDI plugin for XMMS
Package: wnpp Severity: wishlist Owner: Paul Wise <[EMAIL PROTECTED]> * Package name: xmms-midi Version : 0.03 Upstream Author : Chris Reed <[EMAIL PROTECTED]> * URL : http://web.archive.org/web/20040401143932/http://ban.joh.cam.ac.uk/~cr212/xmms-midi/ * License : GPL Description : MIDI plugin for XMMS This plugin enables XMMS to play MIDI files through Timidity. Although upstream is long gone, I use this plugin quite a bit and will maintain it properly until such time as I no longer use xmms. I'll need a sponsor. Co-maintainers are welcome. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: libecw
Miriam Ruiz wrote: > > I'm not sure if it's license ( > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293346 ) can be considered > > free enough to be in main: Some feedback from upstream is in this thread: http://lists.alioth.debian.org/pipermail/pkg-grass-general/2005-August/thread.html#1082 http://lists.alioth.debian.org/pipermail/pkg-grass-general/2005-August/001082.html http://lists.alioth.debian.org/pipermail/pkg-grass-general/2005-August/001083.html http://lists.alioth.debian.org/pipermail/pkg-grass-general/2005-August/001085.html http://lists.alioth.debian.org/pipermail/pkg-grass-general/2005-August/001086.html -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: For those who care about their packages in Ubuntu
On Tuesday 17 January 2006 16:54, Matt Zimmerman wrote: > > You have not ever shown a serious interest in what Debian would like. > > This is, again, insulting, and nonsensical in the face of the repeated > dialogues I have initiated and participated in with Debian developers > regarding Ubuntu practices. > > Debian deserves better than to be represented by this kind of behavior. What BSG writes is the feeling I'm getting from you as well. This is not Planet Ubuntu, Debian doesn't exist purely to source Ubuntu. I'm personally tired of the attitude from Ubuntu users and developers alike that this is Planet Ubuntu. -- Paul Johnson Email and IM (XMPP & Google Talk): [EMAIL PROTECTED] Got Jabber? http://ursine.ca/Ursine:Jabber pgpFMwVfN7DAX.pgp Description: PGP signature
Re: Obsolete packages in Experimental
On Fri, Jan 20, 2006 at 04:09:28AM -0600, Peter Samuelson wrote: > > [Jérôme Warnier] > > Or even better: a list of all packages already installed on my system > > which have an experimental version? > > There might be a better way, but assuming you have experimental in your > sources.list... > aptitude search ~Aexperimental | grep ^i ciao, piem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Sunday 22 January 2006 03:16, David Weinehall wrote: > Since all Ubuntu packages are recompiled against a different set of > libraries, the bug might not even affect the Debian package, even though > they share the same source. Hence having Ubuntu developers triage the > bugs to rule out such issues before they are forwarded to Debian's BTS > is always a good thing; thus the maintainer field should be changed > for *binary packages*. The source is the same, so the field should NOT > be changed for *source packages*. Given Ubuntu hopelessly complicates everything, pretends there is cooperation where there is none, and merely duplicates the effort of the debian-desktop project, and contributes nothing to the community or society, what's stopping us from officially discouraging Ubuntu's existence? -- Paul Johnson Email and IM (XMPP & Google Talk): [EMAIL PROTECTED] Jabber: Because it's time to move forward http://ursine.ca/Ursine:Jabber pgpqOs7lIBNk9.pgp Description: PGP signature
Re: Bug#351069: ITP: knetworkmanager -- system tray applet for controlling NetworkManager
Enrico Zini wrote: > Do we have the NetworkManager daemon in Debian yet? > > I did "apt-cache search network manager" and "apt-cache search > networkmanager" but could not find it. http://bugs.debian.org/270538 ITP: networkmanager -- desktop network management system Date: Tue, 07 Sep 2004 21:26:03 +0100 Last message: Thu, 2 Feb 2006 17:24:14 +0100 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: TrueType fonts packages maintenance team proposal
On Mon, 2006-02-20 at 07:40 +0100, Christian Perrier wrote: > So, please follow up in -devel to show interest, criticism, laughs > and the like. As maintainer (non-DD) of the following two fonts, I think this is a great idea. > ttf-khmeros - KhmerOS Unicode fonts for the Khmer language of Cambodia > ttf-mph-2b-damase - font with ranges from the latest version of unicode There are a few other fonts I'd like to see in Debian (another Khmer one, and a few Burmese Unicode ones). It might be good to write a font policy (if one does not exist), with suggested package names and standards for package descriptions, dependencies and the like. We should also ensure that all the fonts packages have correct debtags. We could also search for binary packages that duplicate font files instead of depending on them (even tho there are lintian warnings). > Please feel free to point me at existing projects I wouldn't be aware > of (debian-desktop?) which cover similar goals... I also think that this project has a bit in common with debian-i18n, perhaps they could be informed too? -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: I am using GPG and am still learning.
On Monday 27 February 2006 11:12, Kirchner Ron - rkirch wrote: > I revoked a key, but need to use this key again, is that possible, as I was > sent a new key but can not seem to No way to do that. Once you revoke a key, it's done. -- Paul Johnson Email and IM (XMPP & Google Talk): [EMAIL PROTECTED] Jabber: Because it's time to move forward http://ursine.ca/Ursine:Jabber -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fonts packages maintenance team (second) proposal
On Wed, 2006-03-08 at 10:33 +0100, Christian Perrier wrote: > So, I hereby propose building a Debian fonts team. I'm interested in participating in this, and would add ttf-khmeros and ttf-mph-2b-damase to the list of group maintained packages. I'm interested in order to communicate with and learn from other font package maintainers, learn from their experience and perhaps add minor polish to some other packages before etch is released. I also feel that fontforge needs some love to get new a upstream version (which re-adds the compact/normal views that I miss), and adopt the package as the maintainer seems inactive on it. Same with defoma I think, which IIRC, has lots of Ubuntu patches we could evaluate applying. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Using CVS for package development
= > Should this CVS repository be mandatory, i.e. does every Debian
= > package have to be there?
A brief word of warning... (I tried CVS on dpkg a while back)
The natural CVS model is to name the directory for the package,
for example .../dpkg/ and relegate the version numbers to tags.
At least one package (dpkg) uses its directory name in such a way
that when the directory is .../dpkg/ the build fails, while it
works when the directory is a versioned one, .../dpkg-1.2.3/.
-Paul Bame
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
= > Communication should be done via a package-specific mailing list. The = > maintainer of the package decides who has commit privileges for this = > package and who gets on this package's developers' mailing-list. = = The way we are currently doing it here (at Pixar) is that nobody checks = in an un-reviewed patch, even if they do have commit privilege. Anyone = with commit privilege can review it for you and give you an OK to check = it in, but it takes two people. It tends to make us think a bit harder = about what we are doing. There are advantages to commiting intermediate versions and un-reviewed patches. The redundancy is a good idea - you won't lose all your work if the disk crashes or somebody does 'rm -r /'. But perhaps a bigger advantage is anyone anywhere with CVS access can use 'cvs diff -rSTABLE' to review the changes -- they don't have to depend on you preparing a 'diff' e-mail or something. They can even check out the trial version to build or test or even compare your changes to their changes. The "final" commit is done by moving a tag or potentially moving something to a "stable" branch. This can be on the honor system since CVS doesn't have per-tag access control (that I know of) with audit possible (I think) through the CVS log files. Obviously all "official/stable" release/builds occur from the STABLE tag. -P -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Possible bug in dpkg-source? Possible fix?
I'm using dpkg-dev 1.4.0.17. The problem is that not just with
source packages I create. It is with all source packages I'm
downloading, e.g., hello.
The type of error I'm getting is as follows:
dpkg-source: failure: remove patch backup file
hello-1.3/debian/substvars.dpkg-orig: No such file or directory
I've checked, and true to the error patch does not create a file
called "substvars.dpkg-orig"; however, it is creating a file called
"substvars.orig".
What's curious is that I don't have any problems extracting the
source when I use the method outlined in the Debian Packaging Manual
for extracting by hand. The patch command I use when doing a manual
extraction is just "patch -p0 -s", and all works like it should.
I'm no expert on the various uses of patch, and I don't know perl,
but I did have a look at dpkg-source. I found the following line:
exec('patch','-s','-t','-F','0','-N','-p1','-u',
'-V','never','-b','.dpkg-orig');
I figured this must be equivalent to typing at the command prompt the
following line:
patch -s -t -F 0 -N -p1 u -V never -b ".dpkg-orig"
Sure enough, when I do this, I do not end up with files that only
have .orig as a suffix instead of the intended .dpkg-orig.
Now, I have looked through the man page for patch and it seems that
the option "-b" should be replaced with "-z". When I make the
substitution, all works well.
Am I behind the times, or is this a bug?
Thanks
Paul Serice
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Rick's Cheesy MIDI Plug-In Package
I've got packaged a program which provides a midi plugin for Netscape. The name of the program is Rick's Cheesy Midi Plug-In. Does anyone mind? Thanks Paul Serice -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
anyone working on updating mgetty?
Mgetty is quite a few versions behind.. is anyone actively maintaining this package? If not, I have enough free time now to take it. -- Paul Haggart - phaggart at cybertap dot com - Debian Linux - PGP 0xD61313E9 "Is all the world jails and churches?" - Rage Against the Machine -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
ircd up for grabs
Anyone want the ircd package? Christopher Clameter handed it off to me, but I don't think I even managed to upload a 'new maintainer' version. I've got enough under my belt as it is.. :) -- Paul Haggart - phaggart at cybertap dot com - Debian Linux - PGP 0xD61313E9 "Is all the world jails and churches?" - Rage Against the Machine -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
mgetty 1.1.7-1 released
I just uploaded mgetty 1.1.7 to master. It's my first multi-target package, so please let me know if it's broken. It's late, and I might have screwed something up. :) -- Paul Haggart - phaggart at cybertap dot com - Debian Linux - PGP 0xD61313E9 "I'm a firm believer in the philosophy of a ruling class. Especially since I rule." - Randal, _Clerks_ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
klogd?!
Anyone else having problems with klogd sucking up all their cpu time? Even with it fully 'nice'd, it still uses 100%. So far, my solution is 'killall klogd' but I'm sure it's a pretty essential program. Any other solutions? -- Paul Haggart - phaggart at cybertap dot com - Debian Linux - PGP 0xD61313E9 "Nobody move or everybody gets hurt!" - Jim Rage, _The Tick_ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
[klee@mit.edu: Bug#10795: makefiles for nethack are i386-specific]
-Forwarded message from Klee Dienes <[EMAIL PROTECTED]>- Subject: Bug#10795: makefiles for nethack are i386-specific From: Klee Dienes <[EMAIL PROTECTED]> Package: nethack Version: 3.2.2 The makefiles for nethack assume that it is being built on an intel-based machine (they use i486-whatever-gcc). They should be changed to use the standard gcc, or barring that, to detect the architecture on which the package is compiled and use a different gcc. -End of forwarded message- Okay, what's the recommended solution for this .. other than porting nethack over to use libc6 (which can't be done at the moment because of the lack of a libc6 xpm library). How does one detect the architecture of the machine being used? -- Paul Haggart - phaggart at cybertap dot com - Debian Linux - PGP 0xD61313E9 "I'll hit you so hard, when you fart your mom will think it's easter!!" - Bill Maher -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Some new package proposals!
-BEGIN PGP SIGNED MESSAGE- Hi all! Since quite some time i've learned to make and have been been making a few packages the Debian way and i'm considering to contribute them to the Debian project. These packages so far are: * isapnptools-1.10 (see "http://www.roestock.demon.co.uk/isapnptools/";) * junkbuster-1.4 (see "http://internet.junkbuster.com/";) * xaw3d-dev-1.3(see "ftp://ftp.x.org/contrib/widgets/Xaw3d/";) Is there already anybody working on these packages and thus making my efforts unnecessary? Above all i'd like to officially provide my own original package "equivs-1.0.3", which is a dummy package used to circumvent dpkg's sometimes completely undesired dependency complaints. I made this package because i preferred to install and maintain a teTeX tree different from the official Debian version in "/usr/local/" so that i might take advantage of Thomas Esser's update shell scripts without having to worry about possibly screwing up my Debian system. Then there are some Debian packages already maintained by someone else which i've started to update with the current original upstream releases making some unofficial Debian packages. The official Debian package maintainers are IMHO too much behind on updating the packages provided with Debian. These packages currently are: * mc-4.0 (see "http://mc.blackdown.org/mc/";), currently officially maintained by "Fernando Alegre <[EMAIL PROTECTED]>". * xkeycaps-2.35 (see "http://home.netscape.com/people/jwz/xkeycaps/";), currently officially maintained by ??? * wget-1.4.5 (see "ftp://gnjilux.cc.fer.hr/pub/unix/util/wget/";), currently officially maintained by "J. Ramos Goncalves <[EMAIL PROTECTED]>" * gv-3.5.8 (see "http://wwwthep.physik.uni-mainz.de/~plass/gv/";), currently officially maintained by "[EMAIL PROTECTED]". If the official maintainers can't provide more current versions and don't mind to give their packages away i'd be delighted to take them over in the hope to make Debian much more up to date. All these unofficial packages can be downloaded from our institute's FTP site at "ftp://ietpd1.sowi.uni-mainz.de/pub/debian/unofficial/";. Note that i have no programmer's background and that i'm more or less limited to simply repackage the original upstream sources without touching anything of their code internals. But i don't think this should be necessary anyway. Cheers, P. *8^) - -- Paul Seelig [EMAIL PROTECTED] African Music Archive - Institute for Ethnology and Africa Studies Johannes Gutenberg-University - Forum 6 - 55099 Mainz/Germany My Homepage in the WWW at the URL http://www.uni-mainz.de/~pseelig -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 Comment: 'finger -l [EMAIL PROTECTED]' for public key. iQCVAwUBM7UsBegqiw1XE3/lAQHeVAP/SgDdcKGAhoKMMz42UxwTbv48rBMSn6J9 xcDI1u7sAOkrukEc6lTMTrBUB19uIz5dPdB/3mPT4r24l63OuMt2Gm1+6uN2Pz3T 8DqLRBeV7PIINU7M6xwlwg7Nhkw5gnavFkYkDpisxiKry6oxMcAtmXM3XQszEJDb MM4x+kKU19A= =gmN5 -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: BS in rxvt+ncurses
On Mon 08 Dec 1997, Remco Blaakmeer wrote: > > I just want to be able to use both the 'Backspace' key and the 'Delete' > key on any VC, xterm or rxvt and I want them to do just what I expect them > to do, which is the same as what they do in MS-DOS. > > Now, if I am seeing it totally wrong, then please explain it to me. The VC sends DEL (octal 177) for the '<--' key, so by your own requirements rxvt should also send DEL for that key. > A year ago I started using Linux and all of a sudden I got confronted with > people who strongly believe that the 'Backspace' key should do 'Delete'. > This is very, very confusing to me. Why don't you just let the keys do > what is written on them? I don't want the 'A' key to generate a 'B' and I > don't want my 'Backspace' key to do 'Delete'. I have a 'Delete' key for > that. It's not a question of a key "doing" something. The key sends something, and the application / tty driver "does" something with it. As long as the "stty erase" value corresponds to what the "<--" key sends, there's no problem. You could make that key send ctrl-e or whatever; as long as the stty value corresponds to that, it will work the way you expect it to. As rxvt's default action is to configure the "<--" key to send whatever is in the "stty erase" value, rxvt does The Right Thing, IMHO. Forcing rxvt to always send ^H for the "<--" key would not be consistent with what VC's do. Paul Slootman -- Can you get your operating system fixed when you need it? Linux - the supportable operating system. http://www.debian.org/support.html home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Porting DPKG!
On Tue, 9 Dec 1997, Turbo Fredriksson wrote: > Darn... He beat me to it with about a week... :) I was just about to do that > (FreeBSD) port my self, but... Atleast he have not made a HP-UX port yet :D > If there would be a port of dpkg to HPUX i would be very happy not having to learn to make packages with and using RPM! Anybody already working on such a beast? Cheers, P. *8^) -- Paul Seelig [EMAIL PROTECTED] African Music Archive - Institute for Ethnology and Africa Studies Johannes Gutenberg-University - Forum 6 - 55099 Mainz/Germany Our AMA Homepage in the WWW at http://www.uni-mainz.de/~bender/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
status of bzip
On Mon 08 Dec 1997, [EMAIL PROTECTED] wrote:
> o Orphaned auctex, bzip (libc5), ghostview, lacheck (libc5), libc5,
If the original bzip is meant here, it should probably be removed. It's
not supported anymore, and the author writes the following on
http://www.muraroa.demon.co.uk/ :
I'm no longer distributing 0.21, because doing so perpetuates
problems with patents, which ensures that the program will never be
widely used. That's a shame, because it's a useful program, and
lots of people seem to like it. If you use 0.21 already, please
upgrade to bzip2. I can't, unfortunately, make bzip2 be able to
decompress 0.21's .bz files, since that would render the
patent-avoidance exercise pointless. I know changing file formats is
painful; from now on, I'll try and make any further changes in a
backwards compatible way.
As bzip resides in base, that should also change, as it it apparently
not free.
Alternatively, there is decompress-only source code available at the
above URL, which could be put into a package and dropped into non-free.
This could be necessary for those that have bzip-compressed data...
What are the thoughts on this? I'd be willing to package this ('bunzip'
perhaps?) bzip2 might then suggest bunzip and conflict with bzip.
Paul Slootman
--
Can you get your operating system fixed when you need it?
Linux - the supportable operating system. http://www.debian.org/support.html
home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED]
http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: status of bzip
On Thu 11 Dec 1997, Paul Slootman wrote: > > As bzip resides in base, that should also change, as it it apparently > not free. Whoops, forget I said the above sentence, I can't seem to find bzip anywhere in Debian... My fingers automatically typed gzip instead of bzip when searching :-( Paul Slootman -- Can you get your operating system fixed when you need it? Linux - the supportable operating system. http://www.debian.org/support.html home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: status of bzip
On Thu 11 Dec 1997, Guy Maor wrote: > Andy Guy <[EMAIL PROTECTED]> writes: > > It is different becuase the lzw patent holders (HP?) have given a > > general license for non-profit use of the patent. > > That's true. It's Unisys that holds the patent, btw. > > The patent on bzip is moot anyway, as bzip2 does not have any patents > on it. It should go to main. I think we should discourage the use of > bzip by not having it in the archive. Someone mentioned that there > was a bunzip which could go to non-free? I started this thread, and mentioned that there is a bunzip-only source available. I suspect that that will also have to go into non-us, if the original bzip also had to go to non-us due to (silly) US patents. I'll contact the author of bzip / bunzip / bzip2 to see what the problems with patents were exactly, to determine where bunzip might go. I'll report back here. By replacing bzip with bunzip, and also offering bzip2, we should be able to limit the further use of bzip. Paul Slootman -- Can you get your operating system fixed when you need it? Linux - the supportable operating system. http://www.debian.org/support.html home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
