Re: charsets in debian/control
On Sun, Dec 05, 2004 at 06:40:52PM +0100, Goswin von Brederlow wrote: > On that note, how likely is it to hit a UTF-8 character encoding that > contains a '\n'? Any non UTF-8 aware parser would assume a new line > has started and get parse errors. 0% likely, guaranteed. UTF-8 is *designed* to be upwards compatible with plain ASCII. Every valid ASCII character has the same meaning in UTF-8. Every UTF-8 byte sequence for a non-ASCII character will not contain *any* ASCII characters. This is achieved by making sure that everything above plain ASCII has the high bit set, not just for the first byte, but for all of them. -- Bart.
Re: debian-installer beta 1
On Sun, Nov 16, 2003 at 10:42:11PM +0100, David Weinehall wrote: > On Mon, Nov 17, 2003 at 07:52:32AM +1100, Brian May wrote: > > > > 1. Linux 2.6.0? > > Not released yet. Yes, it has a _lot_ of nice features, but it is beta > software.. It (or patches to 2.4.22) is also needed if you decide to buy a modern machine right now. I've had to dig up an old plain IDE disk to stage a Linux install to my dual SATA drives in my new machine. Otherwise the beta installer worked fine. The strange thing with SATA support is that I couldn't get the modules in debian's 2.6.0-test9 kernel to recognize my drives, but a self compiled 2.6.0-test9-bk19 kernel with the SATA drivers (for promise and via) compiled in did work. -- Bart.
Bug#159037: general: Time Problem
On Sat, Aug 31, 2002 at 07:14:43PM -0400, Matt Filizzi wrote: > I don't know what is causing this problem but all I know is that I have > narrowed it down to being caused either by a package or by the install > system. I installed from the woody install disks then upgraded to sid. > What happenes is that the time jumps ahead then back, eg (this is output > from "while true; do date;done" I've had the same thing happen and in my case it's caused by the VIA chipset on my motherboard. Some kernels will print "probable hardware bug: clock timer configuration lost - probably a VIA686a." which you can check for in the dmesg output. I notice that kernel 2.4.19 doesn't print this anymore and also doesn't exhibit the problem, so I'm happy using that. -- Bart.
Re: Bug#156503: M$ true type fonts in non-free?
On Wed, Aug 14, 2002 at 08:47:31AM -0400, Eric Sharkey wrote: > There used to be more information about Microsoft's interprettation of > their own EULA on the font web page. Since that page is gone, it's no > longer there, but the gist of it was that they were taking a very very > strict view of "a true and complete copy", to the extent that changing > the packaging of the fonts in any way (even just changing the filename > without changing the file contents) would make it no longer a true and > complete copy. They were pretty clear on this point. > > In other words, no tarballs allowed. Distribution has to be in the form > of a collection of separate Windows 95 self-installing executables. Then there should still be nothing wrong with packing all of those .exe's in a tar file, for transport. The package would then be based on the current installer package. -- Bart.
Re: Packages still in Potato
On Wed, Apr 17, 2002 at 09:39:12PM +0200, Peter Makholm wrote: > If a package works, has no new upstream versions and doesn't get > outdated policywise there is no need for a new version of the package > just because we're making a new release. The "making a release" may not be the best reason. But a regular interval certainly is. One of my packages hasn't been updated since potato. It turns out to no longer compile from source. however, that kind of bug is typically only found when a buildd tries to build a new version. It's not enough for the packages to be able to run, they have to be buildable as well. And because that depends on the state of the rest of the system, we will have to test for it once in a while. Bit rot really does exist. -- Bart. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intent to remove: tom, libtom2
Hi, I'm the maintainer of "tom", an experimental programming language. The archives contain a version from October 1999. Trying to recompile it now on a sid machine fails. Upstream development on this implementation was already dead, as they switched to a new system writen in tom itself. And there too development has stopped. It's my opinion that this package serves no useful purpose and should be removed from testing and unstable. Note that I can file a "does not build" bug easily if usefulness doesn't seem like a good criterion. Speak now or forever hold your peace... -- Bart. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Boost and Loki
On Wed, Apr 25, 2001 at 03:37:20PM -0500, David A. Greene wrote: > Since we're on the topic of C++ libraries, has anyone looked > at Loki from Andrei Alexandrescu? It is described in > "Modern C++ Design" from AW, but the website > (www.moderncppdesign.com)is currently down. I'm not sure of > the license. Loki is a library of (among other things) See http://cseng.aw.com/book/0,3828,0201704315,00.html and the "Source Code" link on that page. To me it looks like the official site(s) are misconfigured. They redirect to a missing page. The source files contain the following notice: // The Loki Library // Copyright (c) 2001 by Andrei Alexandrescu // This code accompanies the book: // Alexandrescu, Andrei. "Modern C++ Design: Generic Programming and Design // Patterns Applied". Copyright (c) 2001. Addison-Wesley. // Permission to use, copy, modify, distribute and sell this software for any // purpose is hereby granted without fee, provided that the above copyright // notice appear in all copies and that both that copyright notice and this // permission notice appear in supporting documentation. // The author or Addison-Welsey Longman make no representations about the // suitability of this software for any purpose. It is provided "as is" // without express or implied warranty. Which looks perfectly DFSG compliant to me. I haven't really tried using them yet, but I already noticed that the Thread support has only been done for win32, so someone will have to write some additional (probably simple, if you know about pthreads) code. -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: What to do about /etc/debian_version
On Fri, Jan 05, 2001 at 08:07:44AM -0500, Michael Stone wrote: > Screw it, just kill the file. We don't have a mechanism for coping with > it. I've seen third-party software install scripts use the file to determine which Linux distribution it's running on. -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: Need server
On Thu, Jan 04, 2001 at 02:56:41PM +0100, Michael Meskes wrote: > On Thu, Jan 04, 2001 at 01:48:34PM +0100, Josip Rodin wrote: > > There are almost two hundred public Debian mirrors, use them. > > Sure. But I was hoping someone would know a machine that a) is up-to-date > (the three machines outside the US I tried so far are not) and b) is > accessible pretty well (which ftp.debian.org is not). download.sourceforge.net Does rsync too :-) -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: autodetecting MBR location
On Tue, Jan 02, 2001 at 02:24:22PM +0100, Tollef Fog Heen wrote: > | s/[0-9]*// > | s/part$/disc/ > > What is the use of the first s/? Unless your first letter is a digit, > it will just remove the zero-width string '' between the first / and > the beginning of the string. > > A better solution will probably be to > > s/[0-9]$// > > which will remove 5 from /dev/hda5. You seem to know that $ and ^ anchor a match to the end or the beginning of a string. So you should also know that in the absence of one of these characters, the match may start anywhere in the string. So the statement works fine as it is. However, stylistically s/[0-9]*// is better written as s/[0-9]+// because the case where no digits match is better classified as "not a match". -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: perl 5.00{5,4} dependancies
On Tue, Dec 26, 2000 at 04:43:13PM +0100, I wrote: > I can verify that it works, we did a local recompile: Maybe we did, but I can't read apt-cache output because this version comes simply from unstable. So no ifs and whens, it's already done and it works. -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: perl 5.00{5,4} dependancies
On Tue, Dec 26, 2000 at 03:26:07PM -, Moshe Zadka wrote: > On Tue, 26 Dec 2000, Dariush Pietrzak <[EMAIL PROTECTED]> wrote: > > > I'm not sure that solves all the problems - I'd like apache-perl > > recompiled against perl5.6, and so the rest of modules. > > I would do, but I'm not at all sure if mod_perl works with Perl 5.6. > Last I heard, they weren't playing well together. I can verify that it works, we did a local recompile: Package: libapache-mod-perl Status: install ok installed Priority: optional Section: web Installed-Size: 1032 Maintainer: Daniel Jacobowitz <[EMAIL PROTECTED]> Version: 1.24.01-2 Depends: apache-common (>= 1.3.14-0), apache-common (<< 1.3.15-0), perl-5.6, libwww-perl, libmime-base64-perl, libdevel-symdump-perl, data-dumper, liburi-perl, libc6 (>= 2.1.97), libperl5.6 (>= 5.6.0) It also seems to be working fine. -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: mp3 encoding patents.
On Wed, Sep 13, 2000 at 12:57:10PM -0700, Sean 'Shaleh' Perry wrote: > On 13-Sep-2000 [EMAIL PROTECTED] wrote: > > Sorry to bring up this subject again. > > I just wanted to know that can't mp3 encoders be distributed from a non-us > > site where the policies are much more relaxed ? > > > the patents are held in Germany. This restricts us because most countries in > Europe accept them. We would have a mirroring problem in any case, but that would still not rule out hosting them in (and for) countries that don't allow these kinds of patents. Speaking for the Netherlands: you can't patent maths/software here. European patents are also not automatically valid here, you still have to apply for the patent. However, there's a fast track for european patents, so the application could just be a formality. What happens if such a formality clashes with the local laws is an interesting question. Searching the Dutch patent database, I couldn't find the relevant patents, but that might be because I don't know which are the relevant patents. Anyone have some numbers? http://nl.espacenet.com/ for Dutch patents, replace the nl with a different country code if you're interested. Oh, and of course IANAL. -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP lame
[this is debian-devel, where we don't Cc unless explicitly asked] On Tue, Sep 05, 2000 at 05:24:12PM +0200, Adrian Bunk wrote: > The policy says about non-US: > > 2.1.5. The non-us server > That's in the context of "how to categorize a package", not a list of Debian machines and their one and only purposes. What frustrates me is that there's software that's - useful - free - legal (at least for quite a few millions of people) but not officially available for Debian. I understand fully that using the name "non-US" for patent-encumbered software is wrong. However, the machine pandora.debian.org is in an excellent position to also host a "non-Software-Patents" section of the archive, which can again be subdivided in main, contrib and non-free. -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP lame
On Tue, Sep 05, 2000 at 10:10:49AM -0500, David Starner wrote: > The problem is not "patents", it's that this particular patent also > applies in Germany, meaning we can't distribute from non-us either. Yes we can, but not to or from Germany. Non-US is in The Netherlands, which doesn't have software patents. -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Signing Packages.gz
On Sun, Apr 02, 2000 at 02:46:30PM +1000, Anthony Towns wrote: > PGP (v2.x, I'm not uptodate with the recent OpenPGP stuff), generates a > secret (albeit symmetric, rather than public/private keypair) IDEA key > everytime you try to encrpt a message. It encrypts the message with this > key, then encrypts the key with the recipients public key, and (and here's > the bit I was referring to) *sends that secret IDEA key across the net*. But you might emphasize that this secret key is used exactly once, just for this message. Intercepting it won't allow you to sign other stuff as someone else. So equating the sending of this kind of secret key and leaving your private key on a server is comparing apples and oranges. -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: ITP: transformiix
On Tue, Mar 21, 2000 at 10:42:38PM -0300, Nicolás Lichtmaier wrote: > Transformiix is a XSLT processor written in C++. URL? > Which section would this go? web or text? I'd say text. Otherwise we could also dump all databases, scripting languages and most other stuff in web. -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: ITP: fakedate
On Tue, May 25, 1999 at 06:43:12PM -0700, Joseph Carter wrote: > On Tue, May 25, 1999 at 02:32:16PM -0400, Ben Pfaff wrote: > >[...regarding time-travel library...] > > > >Or a clever wrapper for shareware style trial packages for linux > >that stop working after a certian time. I don't think there are any > >yet, but when lin= ux is popular there will be. > > > > Presumably such shareware authors would be smart enough to statically > > link their binaries. > > ...and thusly guarantee nobody in their right mind will waste the memory > their application requires. => Not to mention having to write their own libc. :-) -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: doc book filtering tools?
On Sat, May 22, 1999 at 12:33:48PM -0400, Dale Scheetz wrote: > I am specifically looking for the db2rtf conversion filter, but there seem > to be a whole collection of such converters that are no where to be found > in Debian. (at least not in the slink contents file) In potato there's "cygnus-stylesheets" which has db2* commands. In slink there's probably docbook-stylesheets which you can use by hand using "jade -t rtf -d /path/to/print/docbook.dsl file.sgml" -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: dupload problem
On Tue, Jan 19, 1999 at 05:30:50PM -0500, Bob Hilliard wrote: > When I upload a package I first issue the command "ssh-agent > bash", then "dupload -t master .changes". This does the > job, but asks for my pass-phrase twice for each file being uploaded. [...] > How can I eliminate the excessive number of pass-phrase entries? By running "ssh-add" after "ssh-agent bash"? BTW, I use this in my .tcshrc so that I always have an ssh-agent running: if (! $?SSH_AUTH_SOCK) then rm -f /tmp/ssh_agent.* >&/dev/null exec ssh-agent tcsh endif It is a bit dangerous, because the name of that environment variable has already changed once, which resulted in an endless loop, but I still like it :-) -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: Where does 'www-data' come from?
On Wed, Jan 20, 1999 at 08:20:23AM +1100, Hamish Moffatt wrote: > On Tue, Jan 19, 1999 at 01:51:39PM -0500, J. S. Connell wrote: > > On Tue, 19 Jan 1999, Eduardo Marcel Macan wrote: > > > started to wonder... Where does the name "www-data" come from? IS there > > > any > > > argument against 'www' ? > > > > Or perhaps one might ask why Debian deviated from common practice in naming > > the httpd user "www-data" instead of "httpd", like "everyone else". > > Because www-data is more descriptive? That's what I wonder: Is www-data the uid of the web server process or is it the owner of the served files? Both at the same time is a very unwise choice as a default (but sometimes necessary for discussion boards and the like). -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: moving mutt-i from non-us to main
People, The fact that there even exist two debian versions of mutt should tell you that it was an issue for people. Looking through the changelogs, I see that mutt was moved to non-US in Feb. 1997: mutt (0.61.1-1) unstable; urgency=low * New upstream release. * Now non-US. (Bug #7257) -- J.H.M. Dassen <[EMAIL PROTECTED]> Tue, 11 Feb 1997 14:15:27 +0100 Has anything changed since then, or do we have a too short collective memory? -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: Slink not installable from CDs
On Wed, Oct 14, 1998 at 05:33:12PM +0100, Enrique Zanardi wrote: > Are we going to include "apt" in the base system? Its package > ordering feature (and a few others) obsoletes the other methods, but > currently apt doesn't work with mountable media. A "multi-cdrom-apt" > method should be added quick. Not multiple media, but it works perfectly with file:// urls. What do you mean with "mountable media"? -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: [larsbj@ifi.uio.no: Re: copyright problem]
On Sun, Oct 11, 1998 at 04:07:31PM +, Raja R Harinath wrote: > I don't see how it follows. "we have implicitly allowed all users to > link LyX with XForms" does not imply "we have implicitly allowed > (re)distribution of the resulting LyX binaries", which I guess is the > issue at hand. Because *implicit* permission isn't good enough. By default *nothing* is allowed. So every right the authors grant you had better be written down in a license accompanying the software, otherwise one of the authors (or sometimes even their employers) can later sue you. In this particular case it is important to be explicit about the extra permissions granted, because people might get the mistaken belief that it is thus also ok to import other GPLed code into the project. -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: dhcpcd should probably be in base and on the boot floppies
On Sun, Oct 11, 1998 at 11:22:58AM +0300, Tommi Virtanen wrote: > Last time I checked, pcmcia and dhcp didn't get along > very well. Any ideas? (I'm interested in fixing this, > but don't know where to start) I didn't have the complete picture yet when I installed my laptop, but after reading the cardmgr docs it was easy: Change one setting to "y" in the config file for the pcmcia tools and the system will use dhcpcd whenever an ethernet card is inserted. So yes, this should probably be part of the boot floppies, as it can't get much easier than that. -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: office package
On Sat, Oct 10, 1998 at 02:20:14PM -0700, Joseph Carter wrote: > > > I wonder if and when we get together a real office package under gnome. I > > > wouldlove to see that. My personal favorites would be a glyx, gtksql with > > > poistgresql and a spreadsheet, currently siag seems to be the best bet. > > > But > > > that one's not with gtk either. Seriously, take a look at gnumeric if you haven't already. It looks awesome and is in very active development. It's part of Gnome. -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: office package
On Sat, Oct 10, 1998 at 10:10:48PM +0200, Michael Meskes wrote: > I wonder if and when we get together a real office package under gnome. I > wouldlove to see that. My personal favorites would be a glyx, gtksql with > poistgresql and a spreadsheet, currently siag seems to be the best bet. But > that one's not with gtk either. Then you'll just *love* to know that I noticed something called "KSiag" on http://www.kde.org/news_dyn.html > Sigh! Indeed. Sorry for the heavy sarcasm. -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: perl5.005 installation structure
On Wed, Oct 07, 1998 at 01:47:51AM -0700, John Lapeyre wrote: > Could you confirm or deny, that the /usr/lib/perl5 no longer > contains *.pm files ? There seems to be some confusion, but on If this is the case, then the list of packages that have to be changed grows even larger: I suppose dpkg-perl for example installs into a directory which is no longer searched by this version. -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: Perl 5.005.02
On Tue, Oct 06, 1998 at 01:35:46PM +0200, Raphael Hertzog wrote: > The perl package is in incoming. So here is the list of the 33 packages that > need to be updated. The maintainers are listed. The list corresponds to > package which contains filenames matching "/usr/lib/perl5.*\.so". This didn't catch vim-perl, which seems to have been statically linked to perl, but references the libraries of the current version so should be upgraded as well. -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: procps
On Jan 8, [EMAIL PROTECTED] wrote > > Please file a bugreport against ftp.debian.org so Guy remembers this. > > Note that this is probably already covered: > #4378: Dependencies should be checked automatically > #9857: ftp 'dinstall' needs to check dependancies Now you're really scaring me: out of curiosity, I browsed the first bug report, which contains this beauty of a message: Hi! I'm on vacation for one month, so I'm not reading any email. I'll be back on July 14, and I'll respond to all my email by July 16. You will only receive this email once. Guy To me this illustrates the severity of the situation. (Note, btw, that this is nothing personal against the current ftp site maintainer, it's the whole procedure I have a problem with). -- Bart Schuller [EMAIL PROTECTED] At Lunalabs, where the Lunatech Research http://www.lunatech.com/ future is made today.. Partner of The Perl Institute http://www.perl.org/Linux http://www.li.org/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: procps
On Jan 8, Scott Ellis wrote > On Thu, 8 Jan 1998, Bart Schuller wrote: > > Does anyone know where killall went? procps_1.2.2-1 doesn't seem to > > include it. "killall" is used in quite a lot of scripts, which are now > > starting to break. > > Yes, it got broken out upstream into a seperate psmisc package. Which is > now stuck in incoming. You can find an incoming mirror at > ftp://ftp1.us.debian.org/pub/debian/Incoming Thanks. I mut say I find the policy with respect to split or renamed packages getting stuck in Incoming suboptimal. First e2fsprogsg, now killall. It is a bit too easy to end up with a broken system, something which the policy for new packages is supposed to prevent. -- Bart Schuller [EMAIL PROTECTED] At Lunalabs, where the Lunatech Research http://www.lunatech.com/ future is made today.. Partner of The Perl Institute http://www.perl.org/Linux http://www.li.org/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: procps
BTW, Does anyone know where killall went? procps_1.2.2-1 doesn't seem to include it. "killall" is used in quite a lot of scripts, which are now starting to break. -- Bart Schuller [EMAIL PROTECTED] At Lunalabs, where the Lunatech Research http://www.lunatech.com/ future is made today.. Partner of The Perl Institute http://www.perl.org/Linux http://www.li.org/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: potential mayhem with trial libc6 package and kernel-headers
On Dec 20, Manoj Srivastava wrote > >>>>> "Bart" == Bart Schuller <[EMAIL PROTECTED]> writes: > Bart> Particularly if they happened to have a fully unpacked and > Bart> configured kernel source tree in /usr/src/linux . > > Bart> * Poof * > > No it does not! Would you please look at what the postinst > does before spreading FUD? I'm sorry, I can't explain it, but that is exactly what happened to my system. But you're perfectly right, looking at the postinst, it's paranoid enough. So I'll just pretend it never happened :-) -- Bart Schuller [EMAIL PROTECTED] At Lunalabs, where the Lunatech Research http://www.lunatech.com/ future is made today.. Partner of The Perl Institute http://www.perl.org/Linux http://www.li.org/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: potential mayhem with trial libc6 package and kernel-headers
On Dec 19, Rob Browning wrote > People who weren't using kernel-headers before (because they never > needed it), may be in for a shock. Particularly if they happened to have a fully unpacked and configured kernel source tree in /usr/src/linux . * Poof * It's only a slight inconvenience, but I'd rather have known beforehand, so that I might have saved my .config -- Bart Schuller [EMAIL PROTECTED] At Lunalabs, where the Lunatech Research http://www.lunatech.com/ future is made today.. Partner of The Perl Institute http://www.perl.org/Linux http://www.li.org/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Ray Dassen, read this!
On Dec 14, Guy Maor wrote > Email to you is bouncing. Thanks, I just phoned Ray, he will have a word with his sysadmins in about 11 hours. -- Bart Schuller [EMAIL PROTECTED] At Lunalabs, where the Lunatech Research http://www.lunatech.com/ future is made today.. Partner of The Perl Institute http://www.perl.org/Linux http://www.li.org/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#15859: libc5 in stable is horribly broken (fwd)
On Dec 12, Turbo Fredriksson wrote > On 12 Dec 1997, Andreas Jaeger wrote: > > > Just use the libc functions setutent/getutent. They're available in > > both libc5 and glibc2. > > Sorry... I'm using perl, and these functions are not avalible.. *sigh* [...] > *sigh* What can a poor perl proggrammer do...? :) man perlxstut man h2xs something along the lines of h2xs -n Sys::Utmp utmp Looking at utmp.h, it doesn't seem that much work to make a proper perl extension for utmp handling. I might even try to do it myself. No promises though. -- Bart Schuller [EMAIL PROTECTED] At Lunalabs, where the Lunatech Research http://www.lunatech.com/ future is made today.. Partner of The Perl Institute http://www.perl.org/Linux http://www.li.org/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: version numbers on virtual packages
On Dec 5, Darren/Torin/Who Ever... wrote > I was going to change perl to perl5 think weekend and just provide the > virtual package perl. This would close a bug filed by Brian White who > is worried about Perl6. While I was thinking about this during builds I think you'd better make that perl5.004, because breakage could just as well occur with 5.005 or 5.006, not just perl6. With 5.005 we'll need a threaded and non-threaded version as well. Fun. But are you trying to protect debian perl based packages or user written perl programs? The user should already know about possible perl versions and use #!/usr/bin/perl5.004 where necessary. Debian can't protect user written code from breaking. Preventing other debian packages from breaking can be done without changing the package name. -- Bart Schuller [EMAIL PROTECTED] At Lunalabs, where the Lunatech Research http://www.lunatech.com/ future is made today.. Partner of The Perl Institute http://www.perl.org/Linux http://www.li.org/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#9813: rxvt 2.20-4 : Bad setting of TERM environ variable
On May 16, J.H.M.Dassen wrote > On May 15, John Goerzen wrote > > Brian Mays <[EMAIL PROTECTED]> writes: > > > rxvt (and rxvt-xpm) always exports the variable "COLORTERM" so that > > > programs can check for color support. As a side note, when XPM support > > > has been > > > > Unfortunately, I know of no programs that make use of this variable. In > > fact, I believe that ncurses doesn't even use it. > > The S-Lang library support it. For a demonstration: start up rxvt (I've used > 2.20-4) and fire up mutt. You'll have colour support, with $TERM == xterm . > Now start it up "env -u COLORTERM mutt". It'll be black&white. Which makes for a very confusing setup, as COLORTERM doesn't get propagated by telnet, ssh, etc. It took us a while to figure out under what circumstances we got color. What problem is COLORTERM trying to solve? It's very non-standard. Also, I'd hope that if xterm now does color as standard, that fact is reflected in its terminfo entry. -- Bart Schuller [EMAIL PROTECTED] At Lunalabs, where the Lunatech Research http://www.lunatech.com/ future is made today.. Partner of The Perl Institute http://www.perl.org/Linux http://www.li.org/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .