Re: Re: statement from one of the klik project members [was: The klik project and Debian]
Kurt Pfeifle wrote: On Thu, Jan 19, 2006 at 08:34:59PM +, Kurt Pfeifle wrote: And third, klik doesn't really install. It brings exactly 1 additional file (the *.cmg) onto the system. It works with user only privileges. Hang on. You loop-mount with user-only privileges? How? The klik client installation needs root privileges once, to add 7 lines like this one to /etc/fstab: /tmp/app/1/image /tmp/app/1 cramfs,iso9660 user,noauto,ro,loop,exec 0 0 Doesn't this introduce a local root exploit? A user can easily write their own /tmp/app/1/image file which contains, say, a setuid root bash executable. Cameron. signature.asc Description: Digital signature
Accepted hibernate 1.12-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 21 Oct 2005 14:17:00 +0800 Source: hibernate Binary: hibernate Architecture: source all Version: 1.12-1 Distribution: unstable Urgency: low Maintainer: Cameron Patrick [EMAIL PROTECTED] Changed-By: Cameron Patrick [EMAIL PROTECTED] Description: hibernate - activates your computer's suspend functionality Closes: 326695 328296 332240 Changes: hibernate (1.12-1) unstable; urgency=low . * New upstream release (closes: #332240). - Supports swsusp 2.2-rc8 which renamed the /proc entries again. * Remove empty /usr/local/share/hibernate when purged (closes: #328296). * Fix lock scriptlet to work with mawk (closes: #326695). * Update address of FSF in copyright file. Files: 4ab1e1ddd1a92e47d72972628dc2e012 747 utils extra hibernate_1.12-1.dsc 0fb7c524a30daacf200f27de2e398646 64752 utils extra hibernate_1.12.orig.tar.gz 790d801dc8a3385da17435416c84d940 7700 utils extra hibernate_1.12-1.diff.gz bfbded796804eabc25334bd7cfff1a9e 68540 utils extra hibernate_1.12-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iQCVAwUBQ1oTDlYr4CN7gCINAQL18QP/Sz6iZGa6EFhUFRe0FtzQUDwdt2DQKLiy 3dAnZsDRDAF6a1z6DULzY3n0iIo+BIs9cUPJQ2yEks1RBtG/90lyu3/pi8+d0dsY /5eAfsVQsgAkmBtLnriRIGrbR7OZ1d2ZeDzoVPz4cYM5IOeV4+QT32s6PJOVQ8df Tg97t2fKrsY= =4DSQ -END PGP SIGNATURE- Accepted: hibernate_1.12-1.diff.gz to pool/main/h/hibernate/hibernate_1.12-1.diff.gz hibernate_1.12-1.dsc to pool/main/h/hibernate/hibernate_1.12-1.dsc hibernate_1.12-1_all.deb to pool/main/h/hibernate/hibernate_1.12-1_all.deb hibernate_1.12.orig.tar.gz to pool/main/h/hibernate/hibernate_1.12.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted hibernate 1.10-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 26 Jul 2005 19:12:29 +0800 Source: hibernate Binary: hibernate Architecture: source all Version: 1.10-1 Distribution: unstable Urgency: low Maintainer: Cameron Patrick [EMAIL PROTECTED] Changed-By: Cameron Patrick [EMAIL PROTECTED] Description: hibernate - activates your computer's suspend functionality Closes: 310759 317410 Changes: hibernate (1.10-1) unstable; urgency=low . * New upstream release. * Don't break when people use mawk, not gawk, as /usr/bin/awk (closes: #317410). * Correct the location of grub menu file backups to /var/backups, not /var/backup (closes: #310759). Files: 292fa51b8424975697c50d05fd4953a5 637 utils extra hibernate_1.10-1.dsc cbd8320a2a458d1cfad5420c6fa6a823 63598 utils extra hibernate_1.10.orig.tar.gz 783e8682ed26ba10fc975b4fe3996460 7233 utils extra hibernate_1.10-1.diff.gz 982b4f52f42df4e06a4895c4f5427711 67632 utils extra hibernate_1.10-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iEYEARECAAYFAkLohp0ACgkQIgvIgzMMSnW23QCeMaPFqlm+wqgSK2BXAcPnIzRl fbMAn3ZzHJzsao7ok8GO+0UUJ4uxi+2q =OlgZ -END PGP SIGNATURE- Accepted: hibernate_1.10-1.diff.gz to pool/main/h/hibernate/hibernate_1.10-1.diff.gz hibernate_1.10-1.dsc to pool/main/h/hibernate/hibernate_1.10-1.dsc hibernate_1.10-1_all.deb to pool/main/h/hibernate/hibernate_1.10-1_all.deb hibernate_1.10.orig.tar.gz to pool/main/h/hibernate/hibernate_1.10.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
Gervase Markham wrote: We say Debian has a reputation for shipping quality software, and we want them to use the trademark. I would hope you guys also want to use it, as a well-known free software brand. Why is our recognition of Debian's quality used as a negative against that happening? Anyone with a similar reputation (e.g. Ubuntu) can get a similar agreement. I'm curious as to how this would apply to Debian-derived distributions which either (a) don't change the Firefox/Thunderbird packages, or (b) change them in some trivial way. Would someone taking the packages unchanged from Debian be required to either ask MoFo for a trademark agreement or rename their Firefox? This isn't entirely a hypothetical question - I'm involved in producing a customised Debian distribution; we have changed the source code to a bunch of packages (although not any Mozilla ones) and ship a quite different default configuration for many more (including Thunderbird and I think Firefox too), and would like to make sure we're on the right side of Mozilla's trademark licence :-) Cheers, Cameron. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
Eduard Bloch wrote: Why would it have to be before the kernel? Actualy all floppies should Because you can do it before the kernel needs to be running (including the whole userspace overhead needed to prompt the user to insert the usb floppy, for example, and work with it). FWIW, the NetBSD bootloader supports something like this. The default install kernel comes to around 2.7mb. The bootloader reads the kernel and mfs image containing the installer off a couple of floppy discs (which don't contain normal filesystems but instead some kind of multi-volume tar archive for extra perversity). Cameron. signature.asc Description: Digital signature
Re: Debian AMD64 Archive Move
Ed Cogburn wrote: Note: non-free is NOT provided yet. We need to decide what we do with it, as we may be forbidden to distribute some of the software in it (we aren't Debian). Wait a second, if you *aren't* Debian, it should be *easier* for you to provide non-free, not harder. Nope. It is guaranteed that all packages in the main archive are distributable by anybody, whether they're the Debian project or not (DFSG#8). This is not necessarily the case for non-free packages, hence they'd have to be examined individually to determine whether the licence was acceptable. Cameron. signature.asc Description: Digital signature
Accepted hibernate 1.07-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 May 2005 22:39:02 +0800 Source: hibernate Binary: hibernate Architecture: source all Version: 1.07-1 Distribution: unstable Urgency: low Maintainer: Cameron Patrick [EMAIL PROTECTED] Changed-By: Cameron Patrick [EMAIL PROTECTED] Description: hibernate - activates your computer's suspend functionality Closes: 297130 298391 299901 300445 302177 Changes: hibernate (1.07-1) unstable; urgency=low . * New upstream release. * Check for /var/run/suspend2-new-kernel to prevent people losing data by accidentally suspending with an old kernel and resuming with a newer kernel (closes: #298391). * Provides an Include directive for reading other files within hibernate.conf (closes: #299901). * More robust grub scriptlet (closes: #300445). * Updated module blacklist, including correct module names and buggy kernel version ranges for VIA chipset drivers (closes: #302177). * Package description more accurately describes the supported suspend methods (closes: #297130). * Updated Uploaders field to include Martin Krafft. * Don't install the modules_gentoo scriptlet, as it isn't relevant on a Debian system. * Add a README.Debian file documenting where to get software suspend patches. * Install the example ram.conf configuration file. Files: 68227ae3dc7db8d604075bab3811b6e5 637 utils extra hibernate_1.07-1.dsc 0ceb0ec40065cdcf07a6c0ed51de95ac 59644 utils extra hibernate_1.07.orig.tar.gz 688639028537069ec188d110c84da538 5880 utils extra hibernate_1.07-1.diff.gz dde08e1cc8c495a9c0f7da14e24f1437 63140 utils extra hibernate_1.07-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iEYEARECAAYFAkJ2RRUACgkQIgvIgzMMSnWnCgCdFaikmVmrmsuP7Zf0O9vqeYnx f8wAn3WXNgg99HgvihAgCdaXxl0sy31P =1Scu -END PGP SIGNATURE- Accepted: hibernate_1.07-1.diff.gz to pool/main/h/hibernate/hibernate_1.07-1.diff.gz hibernate_1.07-1.dsc to pool/main/h/hibernate/hibernate_1.07-1.dsc hibernate_1.07-1_all.deb to pool/main/h/hibernate/hibernate_1.07-1_all.deb hibernate_1.07.orig.tar.gz to pool/main/h/hibernate/hibernate_1.07.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted hibernate 1.05-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 16 Feb 2005 11:20:16 +0800 Source: hibernate Binary: hibernate Architecture: source all Version: 1.05-1 Distribution: unstable Urgency: low Maintainer: Cameron Patrick [EMAIL PROTECTED] Changed-By: Cameron Patrick [EMAIL PROTECTED] Description: hibernate - Software Suspend 2 script Changes: hibernate (1.05-1) unstable; urgency=low . * New upstream release. Files: 3db3bc435c4390ac843ff6ec9850c98e 580 utils extra hibernate_1.05-1.dsc 9497b9843f414b231a48e5ae2addb0f9 52167 utils extra hibernate_1.05.orig.tar.gz a950714fd6975f5afb7490ebd28ffc49 4373 utils extra hibernate_1.05-1.diff.gz f073f80d59afbece3eef27b4fb21d072 53528 utils extra hibernate_1.05-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCEvVjntB470s6E1wRAj/3AJ0VkwPn5OpA6zxgNe77PZfAkgnaxwCdFr+1 zwXRjGRzKW6pQWB5GkWours= =kB9p -END PGP SIGNATURE- Accepted: hibernate_1.05-1.diff.gz to pool/main/h/hibernate/hibernate_1.05-1.diff.gz hibernate_1.05-1.dsc to pool/main/h/hibernate/hibernate_1.05-1.dsc hibernate_1.05-1_all.deb to pool/main/h/hibernate/hibernate_1.05-1_all.deb hibernate_1.05.orig.tar.gz to pool/main/h/hibernate/hibernate_1.05.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Ipw2100-devel] debian, ipw2200 and wlan0
David Goodenough wrote: ifrename can of course be used to rename an interface, and it is also worth noting that MadWifi uses ath%d, and the RealTech driver uses ra%d. The ralink driver is changing from ra%d to eth%d as eth%d is more commonly used. Personally I use nameif to rename my devices to sensible names based on what's on the other end (e.g. eth and wifi on my laptop). Unfortunately, giving interfaces odd names confuses some software - off the top of my head, iptraf is one of these. Cameron. signature.asc Description: Digital signature
Re: advice on a patch set
martin f krafft wrote: I am trying to package the swsusp2 kernel patch, which comes in hundred little files. My thought was to simply concat these files into one large patch for use with kpatches... however, this does not work because some files are created by early patches and later modified. Since kpatches first tests the patch with --dry-run, it will fail when the later patches do not find a file to patch. Have you considered just using Bernard's apply script that is included with the upstream swsusp package? I'm pretty sure it takes care of testing with --dry-run and backing out previous patches if one of them fails. Cameron. signature.asc Description: Digital signature
Re: acpi vs apm
Matthew Garrett wrote: 1) Dealing with network interfaces and the like sensibly - at the moment, this will often require unloading and reloading modules pre/post suspend Yup. The hibernate package helps with this and can do quite a bit automatically by way of a blacklisted modules mechanism plus configuration options for bringing network interfaces up and down, killing and restarting programmes, mounting and unmounting filesystems and so on. 2) Working with video state. The vbetool package makes it possible to save and restore the graphics card state from userland, which tends to work much better than the kernel fudges. In the long run, either X or the framebuffer drivers need to get much better at programming the video. Oooh, neat. With vbetool my laptop doesn't need any kernel hacks to resume properly and doesn't spit out as many worrying acpi warnings. I'm about to write a hibernate scriptlet for doing this soon. Cheers, Cameron. signature.asc Description: Digital signature
Re: acpi vs apm
Matthew Garrett wrote: So the questions goes: is this a shortcoming with the HP not being properly supported with acpi, am I missing some command like apm which is able to do what I want or is this simply acpi not really having caught up with apm yet? acpi requires a fairly large amount of userland support. I've been doing a lot of work on this, and intend to push it back into Debian post-Sarge. It's not as simple as running something like acpi -s - nor will just echoing 3 into /proc/acpi/sleep work for many machines. What kind of userland support do you see as being missing? I use the hibernate package for ACPI sleep and it works pretty well. Most of the problems that I've seen with ACPI have been kernel or BIOS issues (e.g. the screen not being switched on when resuming unless you give particular kernel options). Cheers, Cameron. signature.asc Description: Digital signature
Accepted hibernate 1.02-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 24 Nov 2004 22:48:41 +0800 Source: hibernate Binary: hibernate Architecture: source all Version: 1.02-1 Distribution: unstable Urgency: low Maintainer: Cameron Patrick [EMAIL PROTECTED] Changed-By: Cameron Patrick [EMAIL PROTECTED] Description: hibernate - Software Suspend 2 script Changes: hibernate (1.02-1) unstable; urgency=low . * New upstream release. Files: 8b1419f084172a1fde196b6158780e07 580 utils extra hibernate_1.02-1.dsc 5f0fee0d6f8be9817b03e997dffe5bb9 46963 utils extra hibernate_1.02.orig.tar.gz dd631c54a014f1d3ed80617a6b779788 4080 utils extra hibernate_1.02-1.diff.gz 466915c4dad683674beb2aa2407259c9 47330 utils extra hibernate_1.02-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBpRY1ntB470s6E1wRAnqXAJ4qsVfinChQ1Z/A/1CdqTIZbl6WQgCfQiPU 233AhisoFQyyJ1nxV245RWA= =eEmB -END PGP SIGNATURE- Accepted: hibernate_1.02-1.diff.gz to pool/main/h/hibernate/hibernate_1.02-1.diff.gz hibernate_1.02-1.dsc to pool/main/h/hibernate/hibernate_1.02-1.dsc hibernate_1.02-1_all.deb to pool/main/h/hibernate/hibernate_1.02-1_all.deb hibernate_1.02.orig.tar.gz to pool/main/h/hibernate/hibernate_1.02.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted hibernate 1.01-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 20 Nov 2004 14:00:06 +0800 Source: hibernate Binary: hibernate Architecture: source all Version: 1.01-1 Distribution: unstable Urgency: low Maintainer: Cameron Patrick [EMAIL PROTECTED] Changed-By: Cameron Patrick [EMAIL PROTECTED] Description: hibernate - Software Suspend 2 script Closes: 280106 Changes: hibernate (1.01-1) unstable; urgency=low . * New upstream release. * Works correctly with current software suspend patches (closes: #280106). Files: f5373037775a9dfa493471380177d85e 580 utils extra hibernate_1.01-1.dsc db5a41fe5abda39b38ba59633eb150f5 45553 utils extra hibernate_1.01.orig.tar.gz fe1d46c99ca85221e369db031671c418 4309 utils extra hibernate_1.01-1.diff.gz 642aa1bef99894b88e339600b093d390 45846 utils extra hibernate_1.01-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBn1n0ntB470s6E1wRAgpQAJ4ij74aaDnQnrrZEahHIHvAwTy5pQCfVYmL lNf7V2QslNi3q2xj3dQOX6U= =nYtr -END PGP SIGNATURE- Accepted: hibernate_1.01-1.diff.gz to pool/main/h/hibernate/hibernate_1.01-1.diff.gz hibernate_1.01-1.dsc to pool/main/h/hibernate/hibernate_1.01-1.dsc hibernate_1.01-1_all.deb to pool/main/h/hibernate/hibernate_1.01-1_all.deb hibernate_1.01.orig.tar.gz to pool/main/h/hibernate/hibernate_1.01.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Which 2.6 kernel for Sarge on a Via C3?
Rich Walker wrote: The C3 reports that it is a 686 without CMOV: More recent C3s do have cmov: shameless:~# cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 9 model name : VIA Nehemiah stepping: 1 cpu MHz : 1000.315 cache size : 64 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr mtrr pge cmov mmx fxsr sse bogomips: 1974.27 They still suck for anything remotely taxing on the CPU. Cameron. signature.asc Description: Digital signature
Accepted hibernate 0.99-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 11 Oct 2004 21:54:58 +0800 Source: hibernate Binary: hibernate Architecture: source all Version: 0.99-1 Distribution: unstable Urgency: low Maintainer: Cameron Patrick [EMAIL PROTECTED] Changed-By: Cameron Patrick [EMAIL PROTECTED] Description: hibernate - Software Suspend 2 script Changes: hibernate (0.99-1) unstable; urgency=low . * New upstream release. - Now the lock scriptlet works with mawk. * Minor tweaks from Erich Schubert [EMAIL PROTECTED]. * Don't Suggests: kernel-patch-swsusp, as that package is not in the official archive, not maintained, and not likely to be updated in the forseeable future. * Add console-tools and vlock to Recommends. * Don't Depend on dash (although it's still nice to have, the script runs faster in dash than bash). Files: dd2037310bc8d9704e80dd68d69b4eda 580 utils extra hibernate_0.99-1.dsc 1709f5984acac2f08d267e98714cd9dc 41257 utils extra hibernate_0.99.orig.tar.gz 8c9faf182c89f0b7dcf037e13a01e411 4253 utils extra hibernate_0.99-1.diff.gz 652f0a1cee70a55813710f5f2d2afb69 40962 utils extra hibernate_0.99-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBaxDSntB470s6E1wRAleJAJ4zM8MZ9eWDEvWrHFt4UUwzc+zNpQCeImqJ dMenP0CjhFdP9DRPsboawUk= =das2 -END PGP SIGNATURE- Accepted: hibernate_0.99-1.diff.gz to pool/main/h/hibernate/hibernate_0.99-1.diff.gz hibernate_0.99-1.dsc to pool/main/h/hibernate/hibernate_0.99-1.dsc hibernate_0.99-1_all.deb to pool/main/h/hibernate/hibernate_0.99-1_all.deb hibernate_0.99.orig.tar.gz to pool/main/h/hibernate/hibernate_0.99.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Content of CDs / DVDs
Richard Atterer wrote: All in all, IMHO generating per-user images on the fly is not really feasible. Would it be more feasible if all of the intelligence was on the client side? The client could slurp down a Packages file, work out which packages to include and split them into CD-sized chunks, download the debs from a mirror somewhere, then fetch the installer and whatever else is necessary to make the CD usable. It'd be like jigdo, but taken one stage further. Cameron. signature.asc Description: Digital signature
Re: Changes in formal naming for NetBSD porting effort(s)
On Wed, Dec 17, 2003 at 09:49:06AM -0800, Nunya wrote: | | I don't believe in magical beings. I *do* believe some humans | | intentionally set out to hurt other humans. Branden's beliefs and | | sneering disdain for some of his fellow humans is quite clear. | | ... and in some cases justified. | | Who are you to pass judgement on others? I am Cameron :-) Seriously, judging people and their beliefs and actions - and acting on these judgments, discriminating against people because of them - is something that everyone does, and I don't see it as /necessarily/ being a bad thing. Life is a series of these decisions, and some of them will almost certainly involve considering people's beliefs and attitudes as being inferior to others'. You are doing it yourself, judging Branden (and others) based on his attitude toward a certain group of people - an attitude which you obviously disagree with strongly, but which you have offered little convincing evidence against. | | Please explain to me the relevance of these names without the specific | | intent of discomforting people. The *intent* is clear. | | They are a reference to the BSD association with daemons. I thought | that was quite obvious? | | Yeah, and the Duke Blue Devils and the Wake Forest Demon Deacons have | references to them to. I think if they used these names for their | dormatories people would raise an eyebrow. | | You are totally rationalizing. *sigh* From Branden's original post where he mentioned the names: We might use names from Christian demonology (since the BSD mascot is the cute and devilish daemon), with the first letter shared by the demon's name and the corresponding BSD flavor. Once again, the stated intent /was/ a punning reference to the BSD daemon. Cameron.
Re: [OT] Re: Changes in formal naming for NetBSD porting effort(s)
On Thu, Dec 18, 2003 at 01:32:41AM +, Scott James Remnant wrote: | On Thu, 2003-12-18 at 01:16, Nunya wrote: | | Face it. You're practicing hate speech. You're not better than what | you hate. | | Ya know, I've always wondered something when people say things like | this... | | If I say I hate Adolf Hitler and his cabinet, is that practising hate | speech? No, but if you say you hate Jews, then many would claim you are. If you wanted to be cynical, you could point out which side won the second world war... Cameron.
Re: Changes in formal naming for NetBSD porting effort(s)
On Wed, Dec 17, 2003 at 10:24:04AM -0500, Branden Robinson wrote: | Demons are evil, | | Demons don't exist. Consequently, their moral value is undefinable. I claim that their moral value /is/ definable in the context of a particular mythology even if they don't exist. In the case of the Christian religion, demons are generally believed to be evil. The Christian religion also has plenty of fundamentalists willing to bash a project merely on the force of the connotations of its name, as this thread has demonstrated. I'm not convinced that this is a valid reason to shun demons as codenames for Debian operating systems, though. Cameron.
Re: Changes in formal naming for NetBSD porting effort(s)
On Wed, Dec 17, 2003 at 08:53:18AM -0800, Nunya wrote: | I don't believe in magical beings. I *do* believe some humans | intentionally set out to hurt other humans. Branden's beliefs and | sneering disdain for some of his fellow humans is quite clear. ... and in some cases justified. | Please explain to me the relevance of these names without the specific | intent of discomforting people. The *intent* is clear. They are a reference to the BSD association with daemons. I thought that was quite obvious? | If you can explain for, historical, literary, philosophical reasons, I | will enthusiastically support those names. If it's just because | let's piss off the Christians, then I say, pick something else. I don't believe that pissing off Christians, as you say, was a reason for choosing them. On the other hand, Branden (amongst others) is quite obviously not concerned about the subset of Christians that is likely to get upset over the suggested names. Cameron.
Re: Changes in formal naming for NetBSD porting effort(s)
On Tue, Dec 16, 2003 at 09:59:46AM +, Will Newton wrote: | (there are at least two ways of pronouncing Debian). ... only one of which is correct :-) Cameron.
Re: Changes in formal naming for NetBSD porting effort(s)
On Tue, Dec 16, 2003 at 12:20:00PM +0100, Mathieu Roy wrote: | Really? What makes a pronounciation incorrect? The pronounciation of | the project initiator, the context, etc... ? Okay, I was being a bit facetious there, but if you insist on taking me seriously, I suspect that the pronunciation of the project initiator is, at least in the case of Debian, more correct than most alternatives. In particular, because the etymology is from a contraction of Deborah and Ian[1], pronouncing it as the first three letters of each of those names seems appropriate. [1] http://www.debian.org/doc/FAQ/ch-basic_defs.en.html#s-pronunciation Cameron.
Re: Changes in formal naming for NetBSD porting effort(s)
On Sun, Dec 14, 2003 at 07:19:22PM -0500, Branden Robinson wrote: | Perhaps we should use the names of famous atheists and other critics of | religion. Bertrand Russell: The Christian religion has been and still is is the chief enemy of moral progress in the world. Cameron.
Re: How to depend on Japanese fonts?
On Sun, Dec 14, 2003 at 05:20:41PM -0800, Jim Gettys wrote: | This is a fundamental change in X architecture, which has been | underway for over 18 months. And it's strongly associated with freedesktop.org, which I'm sure will endear Andrew to the new method even more :-) Cameron.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Mon, Dec 15, 2003 at 04:07:56AM +, Scott James Remnant wrote: | Only GNOME applications should be in the GNOME Applications menu. Why?! Cameron.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 12, 2003 at 01:11:12PM +0100, Moritz Moeller-Herrmann wrote: | It is supported and used in KDE-3.2beta. KDE-3.2 should be released in | January. [...] | Again, please have a look at KDE-3.2. I am currently using the KDE CVS | debian snapshots. KDE stores all it's desktop files in /usr/share | applications and GNOME uses the same directory. Woo, good to hear it! I stand corrected, then. :-) Cameron.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 12, 2003 at 04:12:58AM +0100, Moritz Moeller-Herrmann wrote: | Cameron Patrick wrote: | | On Tue, Dec 09, 2003 at 01:57:29PM +, Henning Makholm wrote: | | | Because you gain *nothing* | | | | Are you claiming that everyone who says that .desktop has technical | | advantages is a liar? These features actually do not exist in the | | desktop format? (It may be so; I have no firsthand information, but it | | does sound far out). | | Most of the advantages of .desktop that I am aware of are currently | vapourware - i.e. they're in the specs on the freedesktop.org site, but | not yet implemented in KDE and Gnome. | | This is not true. Almost all features are being used in current KDE and to | some degree by current GNOME. Could you please give examples? The Categories= field (to place .desktop files into menu hierarchies) is AFAIK not used at all by KDE, although I think Gnome may support it. The freedesktop 'menu' standard (where sub-menus can be generated from the categories in the .desktop files, and which also claims to allow legacy menus to be merged with the new standard) doesn't seem to have been adopted yet by anyone. The worst part, though, is that currently both KDE and Gnome store their .desktop files in different places, so that a .desktop that is available to KDE (and placed in /usr/lib/applnk) won't automatically appear in the Gnome menu, which looks in /usr/lib/applications. I presume that these things are being worked on in later releases of KDE and Gnome, but I don't know where to look for the current status of their adoption of the freedesktop.org standards. I have also noticed what might be considered as 'abuse' of these standards, presumably due to poor implementation of some fields. For example, /usr/share/applications/epiphany.desktop lists its Name as Web Browser; it should more correctly list its name as Epiphany and have a GenericName field containing Web Browser. Cameron.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Wed, Dec 10, 2003 at 07:36:15PM -0700, Bruce Sass wrote: | Have you quantified the bloat you are speaking about? Can the same | argument not apply to any i18n effort? | | Yes, using KDE2. [...] | Yes, the same argument applies to all i18n efforts. | | I18n is great, until disk usage and processing times start to climb | with no real benefit to individual users. I seem to recall reading a number of complaints /from users/ in the BTS, requesting .desktop files precisely because they are i18nalised. Others have suggested expanding the current Debian menu definition to handle i18n. That, to me, sounds like there must be some kind of benefit to individual users to have translated menu items. | I would hardly call avoiding forcing everyone except KDE and Gnome the | need to deal with menu data files which are 10x to 20x the size they | need to be `not buying nobody anything'. I suspect that those who would rather see menu entries in their native language - and whose native language is not English - would consider the larger menu data files necessary to handle i18n to be a real advantage. Cameron.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 01:57:29PM +, Henning Makholm wrote: | Because you gain *nothing* | | Are you claiming that everyone who says that .desktop has technical | advantages is a liar? These features actually do not exist in the | desktop format? (It may be so; I have no firsthand information, but it | does sound far out). Most of the advantages of .desktop that I am aware of are currently vapourware - i.e. they're in the specs on the freedesktop.org site, but not yet implemented in KDE and Gnome. However, since both KDE and Gnome developers helped to write the specs in question, it seems not altogether unreasonable to expect some kind of implementation of them in the future. Internationalisation is the big one that's here already, and IMHO should be added to the Debian menu system regardless of any outcome w.r.t. freedesktop. The relevant pages on the freedesktop.org site are: http://freedesktop.org/Standards/desktop-entry-spec/desktop-entry-spec-0.9.4.html http://freedesktop.org/Standards/menu-spec/menu-spec-0.8.html Cameron.
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 05:18:21PM -0600, Billy Biggs wrote: | Agreed on that, but it's not rewriting all of the menu package, which | is what I felt your post implied. Rewriting all menu files is fairly | trivial and does not have to be done all at once. It should also be fairly easy to get it mostly, if not entirely, automated. q.v. what KDE and Gnome already do in their menu methods. Cameron.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 09:49:25PM +, Andrew Suffield wrote: | Alternate approaches (that involve significantly less work) That's the bit that I (and presumably others) am not convinced about. You keep making this assertion, but with little to back it up. Have you, e.g., looked at the Categories definitions for .desktop files? I don't believe that mapping them onto the section field of our menu system (and vice versa) without losing any information would be trivial. Cameron.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Sat, Dec 06, 2003 at 10:05:57AM +0100, Mathieu Roy wrote: | Sure. However, I use WindowMaker since several years now, and apart | from bug fixes, I did not notice real changes over years (the | changelog does not speak otherwise, it's almost only about bugs and | i18n updates). | | About blackbox, http://blackboxwm.sourceforge.net/, there no news | since September the 2nd... 2002. | | It's maybe a mistake to say that these projects are no longer active | at all, however their activity by comparison to GNOME and KDE is | pretty small. What's your point? The window managers don't /need/ to be changed - or at least they shouldn't. They don't natively support Debian's menu system, they don't natively support .desktop files, and are unlikely to ever do either. The current Debian menu system, despite its faults, supports writing menus for weird formats that an arbitrary window manager (or other menuing system) might be able to read. If .desktops are ever to achieve prominence in Debian, we need to be able to do the same with those. (Personally, I feel that extending the current menu system such that it is both backwards-compatible with what we have not and supports everything in the freedesktop.org standard is not as trivial as Andrew has suggested it is in another thread - but if it was accomplished, we wouldn't have to worry about window managers not supporting .desktop files as their configuration would be generated just as they are now using existing menu-methods.) | For instance, if I correctly understood the story, RedHat stopped | shipping WindowMaker because they do not want to support a window | manager that do not follow the agreements between KDE and GNOME | people, freedesktop.org in fact. There is no reason for Debian to do something merely because Red Hat does. Trying to make Debian compliant with freedesktop's standards by dropping everything that doesn't support them is a sub-optimal approach, and is unlikely to be taken seriously by many people. Cameron.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Sat, Dec 06, 2003 at 11:25:31AM +0100, Mathieu Roy wrote:
| What's your point? The window managers don't /need/ to be changed - or
| at least they shouldn't. They don't natively support Debian's menu
| system, they don't natively support .desktop files, and are unlikely to
| ever do either. The current Debian menu system, despite its faults,
| supports writing menus for weird formats that an arbitrary window
| manager (or other menuing system) might be able to read.
|
| I do not understand how can you, in one hand, say there no need for a
| standard like .desktop for these window managers (well, this term is
| questionnable - wmaker is, for instance, more than a windowmanager),
| and, in another hand, talk about weird formats of different window
| manager.
The situation /now/ is that /most/ window managers use their own unique
format to handle their menus. Even the versions of KDE and Gnome
currently in Debian, while both using .desktop files, store them in a
different place and place them into menu hierarchies differently.
A standard like .desktop or the Debian menu system we have now /is/ a
good thing; we also need a way to make those menu hierarchies available
to applications which cannot and will not read them directly (hence the
weird formats that I mentioned). Currently, freedesktop provides the
former but not the latter, so in order for freedesktop's scheme to be
considered as a replacement for what we use now, there must also be a
way to convert them into the format used by some arbitrary menu system.
In practice, a way to convert existing menu entries into the new system,
and ideally also a way to make use of existing menu-methods, would also
be required.
(I'm sorry, I was imprecise earlier: when I said window managers I was
actually referring to any piece of software which displays a menu of
applications available on the system.)
| The point of .desktop is to avoid having weird formats to handle,
| but only one.
The point is that applications which provide menu entries don't need to
care about about the format that a particular window manager may want
that menu item in. Currently the Debian menu system provides one such
standard format; another candidate is .desktop files.
| If these environment needs the data, or part of the data, that can be
| contained in .desktop (currently provided by the debian menu system),
| why would it be stupid for them to be able to deal directly with
| .desktop?
Of course not. But a lot - in fact, the overwhelming majority - of
these environments predate .desktop files, and are unlikely to change.
They don't integrate directly with any menu system but their own. For
new window managers (or or menu systems), I agree, it makes sense to use
.desktop files for the appropriate menu, as they are more widely
supported outside of Debian.
| If .desktops are ever to achieve prominence in Debian, we need to be
| able to do the same with those.
|
| Sure, as long as some environment will not support .desktop while
| needing the data contained in .desktop, Debian will have to use
| converters.
I claim once again that this will always - at least for the forseeable
future - be the case. Converters for the .desktop format don't yet
exist; converters for the current system are in place and working right
now for /every/ menu system in Debian ... with the exception of KDE and
GNOME, where the Debian menu appears to be treated as a second-class
citizen compared to the {GNOME,KDE}-specific menu. *sigh*
| There is no reason for Debian to do something merely because Red Hat
| does.
|
| Why do you assume that I want Debian to follow RedHat choice?
[...]
| Nobody proposed that. I do not see the point in arguing about a
| non-existant proposal.
In that case, why did you mention what Red Hat were doing?
Cheers,
Cameron.
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 05, 2003 at 02:36:37AM +, Andrew Suffield wrote: | Right, that's what I just described (later on). The thread had | previously been about people wanting to throw away the Debian menu | system and replace it with the .desktop one, or worse, have both | coexist. If we can convert menu entries between the two formats and do so in a sane manner, having the two coexist shouldn't be a problem, and could potentially be the first step towards standardising on freedesktop's format. I agree, though, that having the two coexist with completely different menu items on each is a bad position to be in - and sadly, that's pretty much what we've got now :( I just had a look at the menus of both KDE and Gnome, and it seems that even though the .desktop file format is supposedly common to both, they have different menus with, for the most part, non-intersecting sets of programs on each. Aaargh! This is bad, and I think it needs to be fixed if we are to attempt to do too much more with .desktop files. | Yeah, inverted the sense, you get the idea. We need both tools, at | which point there's no longer a reason not to just continue using the | existing Debian menu system. Except that AFAIK .desktops are still semantically richer than the existing Debian system, and have more momentum behind them outside of Debian. Upstream packages are much more likely to ship to .desktop files than they are Debian menu entries. Admittedly I'm not convinced that they're ready enough in other ways to replace what we have now. | In fact, it looks like it's been implemented twice, once for KDE and | once for GNOME. (Is there any reason why the .desktop files aren't being | shared between the two DE's? It also appears to me that KDE is doing a | marginally better job of integrating the Debian menu into the KDE menu.) | | Yup, that. It needs de-stupiding, which basically means rewriting, | given the triviality of this particular part. Agreed. In my opinion, the current Debian menu hierarchy is a nightmare from a usability perspective. There is a freedesktop.org menu spec[1] that builds upon .desktop entries and sounds to me as though is should help some of these problems, by having .desktop files assigned to multiple categories and attempting to generate a menu hierarchy from those. It also supports merging menus from multiple sources, which might make it easier to incorporate Debian menu entries into it. However, I don't believe it's actually been implemented by anyone yet, and I'm not making any claims about how useful it might be practice. Cheers, Cameron. [1] http://freedesktop.org/Standards/menu-spec/menu-spec-0.8.html - mentioned on the debian-usability list months ago.
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 05, 2003 at 01:17:08PM +, Andrew Suffield wrote: | Thing is, none of this matters. If upstream support .desktop files, | then we just run them through the script that converts them to Debian | menu entries while installing. dh_installmenu would be a good place to | do this. | | The extra features should be pretty simple to implement - just more | text fields. That way we support the upstream menu entries in | everything, not just kde and gnome. Yeah, whatever. Just so long as the current mess is resolved one way or another, I don't have that strong a preference in favour of one system or the other. Given that extra features should be added to Debian's menus anyway, and that no matter what happens there's going to be a need to convert between .desktops and Debian menu entries, I can't see why it should really matter which format is preferred. Cameron.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Thu, Dec 04, 2003 at 12:19:28PM +, Andrew Suffield wrote: | On Thu, Dec 04, 2003 at 12:34:22AM +0100, Raphael Goulais wrote: | On Wednesday 03 December 2003 21:31, Zenaan Harkness wrote: | I agree. I would like to see .desktop standard adopted. There have been | a few threads I have seen so far, and there seems to be some level of | resistance to the idea. | | The silly question is : What does our actual menu system provide that | shouldn't be achieved by using .desktop file ? | | As those are going to be a standard, we should deal with them. | | You could swap our menu system and .desktop files here and your | argument would still be about as valid. I don't think that this is the case. As I understand it, .desktop files have the advantage that they are already shipped by a number of upstream packages, support i18n better than Debian menus, are supported natively by KDE and Gnome, include facilities for providing stuff like generic names and are supported by the freedesktop.org folk. The main advantage of the Debian menu system, on the other hand, seems to be that it is already in place in most .debs which provide menu entries and menu methods. (The above was gleaned from reading past threads, BTW, not from intimate knowledge of the two systems. The worst situation, IMHO, is to see the two mesh poorly, such as the KDE menus which show Debian submenus under a lot of categories, presenting applications with .desktop entries separately from those which only have Debian menu entries.) Cameron.
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Thu, Dec 04, 2003 at 10:04:56PM +, Andrew Suffield wrote: | Why be gratuitously different? | | Why not? Why waste effort just to be the same as everybody else? | | It's identical to the old rpm vs. deb argument. Really? Once again, I believe that there are differences, in that it should be possible to have .desktop entries and Debian menu entries coexisting while we standardise on .desktops for newer software which wants to take advantage of them. However, I think that for this to happen, it would be nice to see somewhat better integration of the current menu system into KDE and Gnome, i.e. not just squirrelled away in Debian submenus. Having .rpms and .debs coexisting during some transitional period is, on the other hand, not a viable option. | There's now a standard used by KDE and GNOME which has more features than the | Debian menu system. | | Which makes more sense: | | * Investing time in adding features to the Debian menu system, keeping maximum | menu work on the Debian maintainers, retaining poor GNOME and KDE | integration, and generally competing with the freedesktop standard | | * Adopting the freedesktop standard and absorbing its benefits for GNOME and | KDE users immediately, while benefiting from upstream work | | This is the fallacy of the false dilemma. Hmm. I don't think it's quite a false dilemma - the original post didn't claim that those two were the only options - however it is most definitely a case of special pleading :-) | Frankly, I'm not clear why there's opposition to adopting the freedesktop | draft specifications in Debian. | | Are there any technical complaints about it? (Apart from I don't like | the .desktop extension, which I consider unimportant.) | | It doesn't support anything but gnome or kde. We have a system that | works for everything, and it is unlikely that anybody else will go to | that much trouble. It doesn't /yet/ support anything but Gnome and KDE. You've been proposing hacking additional features supported by the freedesktop system into the Debian system; Nate has already said that he might write a converter to generate menu files from .desktop files to retain compatibility for everything else, in which case the .desktop system will support everything that the current menu system does. That doesn't sound so bad, does it? | Perhaps a backward-compatability-menu module could be written to | automagically generate Debian menu entries from .desktop entries. If this | would satisfy everyone's complaints, I'll write the damn thing. | | That's half of what is needed (to support gnome and kde within the | debian menu system). The other half is the reverse conversion - take | the upstream .desktop file, and convert it to a debian manu | entry. That supports everything other than gnome and kde. It should be | pretty easy - they're simple text files. I fail to see what the difference is between the quoted text and your 'pretty easy' suggestion... perhaps you meant to say take the Debian menu entry and generate a .desktop? That, also, should be simple, because it's already bleedin' done. In fact, it looks like it's been implemented twice, once for KDE and once for GNOME. (Is there any reason why the .desktop files aren't being shared between the two DE's? It also appears to me that KDE is doing a marginally better job of integrating the Debian menu into the KDE menu.) Cheers, Cameron.
Re: UserLinux white paper
On Wed, Dec 03, 2003 at 08:24:09AM +0100, Bernd Eckenfels wrote: | This is the Proprietary software model, with artificial, government | imposed (via copyright laws) monopolies, resulting in customer lock-in | and price maximization. | | I dont see a monopol, at least no government imposed. I believe that when Zenaan was saying was the copyright laws /are/ a government-supported monopoly on distributing a particular creative work (in this case, a piece of proprietary software). Cameron.
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Thu, Nov 20, 2003 at 01:21:35AM -0500, Branden Robinson wrote: | On Wed, Nov 19, 2003 at 11:01:46PM +0100, Oliver Kurth wrote: | On Wed, Nov 19, 2003 at 01:25:24PM -0800, Don Armstrong wrote: | The firmware is needed. Without it, the device is completely dumb. | But there are some devices which can store the fw permanently. Also, | the fw is distributed on their (windows) installation CDs. | | One wonders why they don't just open up the source to the firmware | drivers since they aren't planning on making any more updates to it. | | I am not sure about this. I think this is true only for the devices with | Intersil radio. | | Does this company even deserve our support? Possibly not, but I think a case could be made that Debian's users do. (You know, that other priority, the one that isn't Free Software...) Cameron.
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 09:58:54PM -0800, Steve Lamb wrote: | Cameron Patrick wrote: | I don't think it is. Python doesn't have a switch/case equivalent. It'd | have to be done with a bunch of if's or something. | | Well, depends. Do you consider its dictionary to be a switch? Nope, no fall-through in that one, so it doesn't help. It /is/ nifty though :-) Cameron.
Re: Tabs v.s. spaces
(This is waaay off-topic but what the heck, I'll keep going...)
On Wed, Nov 19, 2003 at 08:08:51AM -0800, Steve Lamb wrote:
| Cameron Patrick wrote:
| Nope, no fall-through in that one, so it doesn't help. It /is/ nifty
| though :-)
|
| Uh, there was a fall through there. Notice that if x has a value that
| isn't in the dictionary the if will fall through to the else.
I meant fall through in the sense that
switch(foo) {
case 1:
blah(); /* no break; */
case 2:
blurgh();
}
will run blurgh() if foo==1 or foo==2.
The original poster was talking about Duff's device:
http://www.lysator.liu.se/c/duffs-device.html
which relies on this (and other foul properties of C's switch/case) to
unroll a loop.
Cameron.
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 09:10:53AM +0100, Wouter Verhelst wrote: | Please actually try to code something in Python before commenting on its use | of spaces. It is unlike the times of Fortran: in Fortran spaces are used to | make programs easy to read by machines; in Python spaces are used to make | programs easy to read by human. | | then why are they significant? So that anything that attempts to parse the program, be it human or Python, can tell when nested blocks begin and end? FWIW it seems that most people who have actually /used/ Python quite like the significant whitespace thing, even if the idea makes them a bit squeamish at first. Cameron.
Re: Tabs v.s. spaces (was Re: Programming first steps.)
On Tue, Nov 18, 2003 at 11:55:01AM +0100, Julian Mehnle wrote: | Steve Lamb wrote: | 2: Can you provide an example of such free-style coding that you speak | so highly of? | | # Split header into separate header lines, dropping any unneeded or | # spurious header lines: | @header_lines = grep( | ( | /^(?: | # Wanted headers: | X-Spam-Status | ):/ix or | !/^(?: | # Unwanted headers: | Delivered-To| | Path| | Priority| | Received| | Return-Path | | (?: # Prefixes: | List| | X | )-[\w-]+ | ):/ix | ), | split(/\n(?!\s)/, $header_unwrapped) | ); | | I call that readable, but I guess somebody won't. ;-) I can more-or-less follow it and I don't speak Perl. :-) Python's parser wouldn't object to that, BTW, because it's all one expression - the following, for instance, is legal (although ugly) Python: if ( 1 + 1 == 2 ): print hi Cameron. PS. I'll try to stop posting in this thread now. Really
Re: Tabs v.s. spaces
On Wed, Nov 19, 2003 at 01:19:32AM +, Darren Salt wrote: | I find myself wondering if Duff's Device is implementable in Python... I don't think it is. Python doesn't have a switch/case equivalent. It'd have to be done with a bunch of if's or something. Cameron.
Re: Programming first steps.
On Mon, Nov 17, 2003 at 08:49:03AM -0600, Steve Greenland wrote: | On 17-Nov-03, 05:15 (CST), Wouter Verhelst [EMAIL PROTECTED] wrote: | I have one grudge against python, though: its mandated indentation looks | very ugly and unstructured to me. Kinda reminds me of COBOL (and boy, do | I have nightmares of having to write COBOL code at school) | | As a long-time C coder, I agreed with you. But after doing a small | python project, I was surprised at how quickly it became natural. It | does help to have an editor that ensures you don't mix spaces and tabs. I believe that tabs aren't a problem with Python so long as they really do indent to a multiple of 8 spaces. Editors which interpret tabs differently are broken^W^W can cause problems when editing Python code with tabs and spaces mixed though. Vim, Kate and Emacs all work admirably for editing Python code. | Steve, who would not object to the removal of character 9 from the ASCII | set, even without the existence of Python. :-) Cameron.
Re: Tabs v.s. spaces
On Mon, Nov 17, 2003 at 08:56:49PM -0500, H. S. Teoh wrote: | Nevertheless, I find 8-space indentation too wasteful, 4-space | indentation too cumbersome to type, and 1-space indentation | unreadable. Your editor should do that for you! :-) e.g. set softtabstop=4 in vim will allow you to have 4-character indentation by pressing the tab key and outdentation by pressing backspace, but the file will contain spaces instead of tabs. I would be surprised if other editors did not have a similar feature. Personally I prefer 8-space indentation, though. Cameron.
Re: Bug#220930: ITP: unace -- De-archiver for .ace files
On Sun, Nov 16, 2003 at 03:09:17PM +0100, Santiago Vila wrote: | Hmm, do you mean that *you* don't speak about de-archivers? | [ This is the first time I hear about this in 6 years ]. | | Google says: | | dearchiver 391 hits | de-archiver 1660 hits | unarchiver 1240 hits | un-archiver 1500 hits | | This is biased of course, since I'm sure many of the hits come from | the unzip package itself. Perhaps we should ask in debian-l10n-english. I'm a native English speaker and I don't believe I've ever heard the term de-archiver; its meaning is clear, but it sounds 'wrong'. The hyphen, especially, looks out of place. Unarchiver is what I'd use if I had to coin a word for it, but I don't believe that's a common English word either. I'd suggest something along the lines of tool for extracting ACE archives instead. Cheers, Cameron.
Re: ITP: 1-mb-random-data -- one megabyte of pseudo-random data
On Wed, Nov 12, 2003 at 11:17:57AM +0100, Henning Makholm wrote: | Please, please, no! /dev/urandom does not reliably deliver | pseudo-random data. There is a chance that fresh entropy will arrive | in the middle of the computation and mess up with the pseudoness. No, I already covered that in another message. See: http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00876.html | This may happen at a buildd even if the package you build yourself | does seem to be pseudo. How you you imagine fixing that? Or even | discover that something has gone wrong? But there are porting teams to handle that. The kernel /dev/urandom device already has to handle pseudoness on each architecture anyway, so if it doesn't work we're really just exposing a bug in the buildd, which is a Good Thing. My package has been made and I'm testing it right now. It works fine for me. I know how pseudo randomness works, so RTFMing about entropy can be done later. It's not a fundamental flaw in my package, it's just a bug which I'll soon fix. You're welcome to file a bug against my package if it's still there once it enters the archive. Besides, you're just hassling me about all these problems that the current randomness in Debian already has! I'm not making a truly new randomness package, the maintainer behind the scenes is God who's already written entropy for the upstream laws of Physics works now. I just make the package that is based on his patches. | The mere fact that you make this suggestion without sufficiently | researching the subject matter clearly shows that you're inherently | unable to create Debian packages reliably. That's objective! My contribution to the Debian project is being discouraged and ignored by trolls who clearly don't understand the informal standards of how Debian works. There's no point in continuing this thread if all you're going to do is provide slanderous arguments.
Re: On linux kernel packaging issue
On Sun, Nov 09, 2003 at 02:46:38PM +0100, Eduard Bloch wrote:
| Do you see now that 8 of your 10 percent come directly from the
| application code and other two maybe from the optimized libc? There is
| not{hing| much} we have won using an optimised kernel. But the placebo
| effect has been demonstraded once again.
I don't think that anything much has been demonstrated, other than (as
you observed) the small-but-noticeable effect of optimising one
particular CPU-intensive application. Comparing the difference between
kernels running bzip2 won't tell you much, as most of the time is spent
in user space, not kernel space, as your own tests show.
Cameron.
Re: On linux kernel packaging issue
On Sun, Nov 09, 2003 at 03:37:11PM +0100, Eduard Bloch wrote:
| #include hallo.h
| * Michael Poole [Sun, Nov 09 2003, 09:22:13AM]:
| Eduard Bloch writes:
|
| Do you see now that 8 of your 10 percent come directly from the
| application code and other two maybe from the optimized libc? There is
| not{hing| much} we have won using an optimised kernel. But the placebo
| effect has been demonstraded once again.
|
| You have not shown what you claim you have shown. You have shown that
|
| No. Please read my initial mail then and what Glenn tried to proove with
| his bzip2 test.
I believe that Michael is correct. A summary of the messages leading up
to this one on the thread is as follows: [with my comments in square
brackets]
Nikita: There are significant performance gains optimising the
kernel for a modern CPU rather than i386.
Eduard: Optimising kernel code doesn't help as other hardware is the
limiting factor.
Nikita: No, you're wrong.
Andrew Suffield: Prove that optimising for a particular CPU makes things
faster rather than slower.
Glenn: It /does/ make things faster, really! Here are some pretty
numbers!
[Provides an example of Gentoo's bzip2 vs Debian's bzip2, running on an
identical kernel. Gentoo's is ~10% faster. Thus Glenn has given one
valid data point of code running faster when optimised for the machine
it is running on.]
Eduard: Glenn's comparison [of user-space code] is invalid as his
kernel is optimised in both cases. Provides an example of bzip2 running
on a P4 kernel vs a vanilla kernel, with no significant performance
difference. Therefore optimising the kernel yields no performance
advantage.
[Output of time shows that an insignificant proportion of bzip2's run
time is spent in kernel space anyway, thus any difference in kernel
optimisation is not going to make much difference to bzip2's run time
anyway. Correct conclusion is that kernel optimisations make little
difference to some CPU-intensive apps, not that kernel optimisations
make little difference to anything, ever.]
Glenn: I was comparing user-space optimisation so the kernel is
irrelevant.
[i.e. Glenn's point was about optimisation in general, rather than
optimisation of the kernel in particular. Which is okay 'cos he was
replying to Andrew Suffield, and that's what Andrew seemed to be talking
about too.]
Eduard: Yeah, user-space optimisation is the only thing that matters,
here's another benchmark [more or less the same as Glenn's]. See,
I was right!
[Eduard's comparison here provides another data point in favour of
optimisation making a difference in bzip2. Once again utterly
irrelevant for benchmarking different kernels. If one wanted to compare
the effects of optimising the kernel, a valid benchmark would be one
which actually spends most of its time executing kernel code rather than
user code.]
Michael and Cameron: No-one has shown anything remotely interesting
here about the effects of optimisating kernel code. Eduard's
interpretation of his own benchmark is invalid.
Eduard: No it's not!
Cameron: Yes it is!
(Repeat ad nauseum...)
| I know, and that was NOT my claim (but the counterpart!). Don't put
| words in my mouth.
Heh. Now you'll probably accuse me of doing the same. So: tell me
where I have misrepresented you in the above.
Cheers,
Cameron.
Re: On linux kernel packaging issue
On Sun, Nov 09, 2003 at 05:14:44PM +0100, Eduard Bloch wrote:
| That is not a summary of the thread, that is a summary of YOUR
| interpretation of the thread.
I won't dispute this. :-)
| Eduard: Optimising kernel code doesn't help as other hardware is the
| limiting factor.
|
| No. The hardware limits were just an example to show where the
| optimisation do not make any sence, as well as in other parts of the
| kernel.
Hmm. Okay.
| Andrew Suffield: Prove that optimising for a particular CPU makes things
| faster rather than slower.
|
| No. Read and think about it:
|
| | Cpu-specific task management, IRQ processing, cache alignment, etc is
| | being used on higher processors.
| |
| |Please provide carefully documented evidence of the performance gains
| |that you are claiming, not handwaving. Evidence of a difference is not
| |the same thing; anybody who has any experience with low-level
Sounds about right to me. I claim that provide carefully documented
evidence of performance gains can be sensibly paraphrased in this
context as prove that optimising for a particular CPU makes things
faster.
| Eduard: Glenn's comparison [of user-space code] is invalid as his
| kernel is optimised in both cases. Provides an example of bzip2 running
| on a P4 kernel vs a vanilla kernel, with no significant performance
| difference. Therefore optimising the kernel yields no performance
| advantage.
|
| Which was the thing questioned above...
No. You were inferring from bzip2 doesn't run any faster on an
optimised kernel (a premise which I won't dispute) that optimising the
kernel has no performance gains (which is not necessarily the case).
| Glenn: I was comparing user-space optimisation so the kernel is
| irrelevant.
| [i.e. Glenn's point was about optimisation in general, rather than
|
| He did not make his point clear.
I'll grant you that. It's still the only sane way that I can find to
parse what he wrote, though.
| And answered to a mail discussing KERNEL ISSUES. If you like to talk
| about general benefits of code optimisation, start a new thread.
Fair enough.
| Michael and Cameron: No-one has shown anything remotely interesting
| here about the effects of optimisating kernel code. Eduard's
| interpretation of his own benchmark is invalid.
|
| I did not try to test the kernel.
Then what were you trying to do when you timed the same executable
running on two differently-optimised kernels?
| I demonstrated the same things you meant. Show me the invalid
| interpretation or just stop rephrasing things in the way you like
| them.
You seemed to interpret a benchmark showing that bzip2 doesn't spend
much of its time in kernel space when you ran it as showing there is
not much we have won using an optimised kernel. Well, surprise
surprise, if you run a program that doesn't spend much time in kernel
code, optimising that kernel code won't get you much.
What would be more interesting to see is what kind of effects an
optimised kernel has on code that /does/ spend a long time in kernel
space, and how common those kind of applications are. (Although I
suspect the latter would depend a lot on what you used the machine for -
which shouldn't really be a surprise.)
| Nice reduction to the thing you wish to see. Please cool down and reread
| the discussion without emotions, then notice:
|
| | not{hing| much} we have won using an optimised kernel. But the placebo
| | effect has been demonstraded once again.
| |
| | You have not shown what you claim you have shown. You have shown that
| |
| |No. Please read my initial mail then and what Glenn tried to proove with
| |his bzip2 test.
|
| and realize that you already tried to force an opinion that I did not
| have.
Well, Glenn didn't really put many words around his output from timing
bzip2, so any claims about what he was trying to prove are speculative.
I think it is apparent from his previous email in the thread that he was
trying to demonstrate that compiler optimisations make a difference,
though. Admittedly, timing two bzip2 binaries is not the most
meaningful benchmark ever, and it certainly isn't the kind of evidence
that Andrew Suffield was after. Your rebuttal did seem to me to be
missing the point, however weak that point may have been.
Cameron.
Re: Exec-Shield vs. PaX
On Fri, Nov 07, 2003 at 12:15:06PM +0100, [EMAIL PROTECTED] wrote: | I suspect we both agree that it's desirable to have thread stacks | non-executable as well. | | on one hand you acknowledge that it's better to have non-exec thread | stacks but on the other hand you argued that | | it's not a bugfix to break apps that rely on an executable stack - the | stack _is_ executable. | ^ | | as they say, you can't have it both ways. He's saying that there's no reason to have an executable stack for programs which never attempt to execute code on the stack---and having a non-executable stack in such circumstances gives you a security advantage---but it is not okay for the operating system to break those programs which /do/ rely on the stack being executable. Now could you please stop wasting everybody's time by continuing this thread? Ingo has already stated that he won't continue arguing with you, and I don't intend to continue posting in this thread after this message either. Cameron.
Re: A case study of a new user turned off debian
On Tue, Nov 04, 2003 at 04:35:13PM +0100, Josip Rodin wrote: | On Tue, Nov 04, 2003 at 01:53:36AM -0600, Chris Cheney wrote: | It would be helpful if Debian could even be installed on machines newer | than about 2 years old. | | It would be helpful if people wouldn't make sweeping generalizations all the | time. Yes. Everyone knows that all generalisations are false anyway :-) Cameron.
Re: Exec-Shield vs. PaX
On Wed, Nov 05, 2003 at 12:28:51AM -0600, Graham Wilson wrote: | Please, guys, don't have your discussion here. I don't think we really | care about the differences between PaX and exec-shield. Debian is not, | and, to the best of my knowledge, will not, choose one for its kernels, | so there is no need to prove that one or the other is better. Why should it not? If Pax or Exec-shield can be added to the kernel without breaking things, and provide better protection against some types of security holes than a default kernel, then surely there is a case to be made for including one or the other in the stock Debian kernel. (Without breaking things is the tricky bit here, of course.) Cameron.
Re: stable executable names
On Wed, Nov 05, 2003 at 08:47:29PM +1100, Zenaan Harkness wrote: | Now, what's finally got to me one too many times: | * I run firebird then can't run mozilla. | * I run mozilla then can't run firebird. I've also noticed this. A quick look at the BTS shows that someone has already filed a bug on it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=216264 Apparently it has been fixed upstream. | And shouldn't we have stable executable names? The executable names are fine, as far as I can see (mozilla = Mozilla, mozilla-firebird = Mozilla Firebird). Is the strange behaviour above perhaps confusing you? | If I'm running an app, shouldn't I be able to run additional instances | of that app???!!?? AFAIK you can't in the case of Mozilla. When you run mozilla while a copy of mozilla is already running, it will start a new window if it can; if it can't (e.g. the second instance of Mozilla is on a different X display) it will try to con you into creating a new profile. Openoffice displays even weirder behaviour wrt to multiple instances, actually ... perhaps I should file a bug on that one. Cameron.
Re: A case study of a new user turned off debian
On Tue, Nov 04, 2003 at 03:22:10AM -0600, Chris Cheney wrote: | I refuse to use nvidia products, but I somehow doubt that boards based | on their nforce2 chipset work properly either. I have a machine using the nforce2 chipset and the Woody installer doesn't recognise its IDE controller. (Proper support is only in kernel versions = 2.4.21.) Incidentally, wasn't there a woody 3.0r2 planned to be released a couple of months ago with a newer kernel version and miscellaneous security fixes? Cameron.
Re: netkit-inetd in sarge
On Sun, Oct 19, 2003 at 01:37:58PM +1000, Andrew Pollock wrote: | Hmm, am I the only one that thinks | | dd if=/dev/zero | nc victim discard | | is a bad thing, in an environment where the victim is paying cents per meg | for inbound traffic? I'm no so much talking about DoSing anything, but | causing financial damage. Yeah, but you can do that on any given port whether it's open or not. e.g. cat /dev/zero | nc -u victim 12345 (nc in UDP mode seems to ignore ICMP port unreachable packets in my testing... if it doesn't you can always use iptables to make sure it does.) There's no way to /stop/ someone from sending you data, whether you want it or not. Cameron.
Re: XMMS doesn't like itself much...
On Tue, Oct 14, 2003 at 10:15:31PM -0700, Matt Bonner wrote: | It seems that as a couple, xmms and alsa-xmms are likely to break up | soon. Can anyone help them? Or at least me? The latest xmms package has the alsa plugin included, so the alsa-xmms package is no longer needed. i.e. the couple have broken up already :-) Cameron.
Re: testing packages at build
On Thu, Oct 09, 2003 at 02:15:03PM +0200, Bill Allombert wrote: | My first goal is to persuade developers that running tests is | worthwhile. For the implentation I have mainly 3 questions: | | 1) Do porters and autobuilders admins want to be able to skip the tests ? Surely skipping the tests on autobuilders would be a bad idea? The tests may pass on one architecture but not on another (e.g. gnucash in sid), and being able to catch such problems sounds like a Good Thing. | 3) Do we want to allow for autorecovery ? If gcc -O2 leads to a broken | binary, why not set up debian/rules to automatically retry with gcc | -O0 ? This sounds like something that is best done with human intervention, not by an automated process which could potentially break things further when it screws around with compiler options. Are gcc optimiser bugs really that common? Cameron.
Re: Language extensions in programs under /usr/bin
On Wed, Oct 08, 2003 at 09:57:42AM +0100, Colin Watson wrote: | That'd be /usr/share (lib is for arch-dependant data, see FHS) | | ... except that the Python policy seems to have bizarre rules about | this. I assume this is because .pyc files are placed in the same | directory as the corresponding .py files and are architecture-dependent. I don't think it's the .pyc files, AFAIK they're just architecture independent bytecode. I believe it's because some Python modules come with blah.so files which need to live with their corresponding blah.py files, so they can't be put into /usr/share. Cameron.
Re: Quote: Debian and Democracy at Advocato.org
On Wed, Oct 08, 2003 at 09:42:42PM +0200, Thomas Hood wrote: | On Wed, 2003-10-08 at 21:25, Daniel Ruoso wrote: | I think this should be clearly discussed. | | Just to prevent any confusion I'll just point out that | the rant you quoted was authored by Eray Ozkural. Hmm. I've heard that name mentioned before on this mailing list, in conjunction with phrases like dick-head and will never be allowed into Debian. Presumably there's a good reason for this animosity towards him; would someone mind enlightening me as to why? Cameron.
Re: /usr/doc symlinks
On Sun, Oct 05, 2003 at 03:25:01AM -0500, Chris Cheney wrote: | I grepped a current Contents-i386.gz for usr/doc, and after examining | the file itself I notice it is from a comment in the front of | Contents-i386.gz... ARGH!!! From the comment at the top of Contents-i386.gz: This file maps each file available in the Debian GNU/Linux system to the package from which it originates. It includes packages from the DIST distribution for the ARCH architecture. Is it just me, or does this look like a template that was supposed to be sed'ed to replace DIST and ARCH with something more sane (e.g. sid and i386)? Cameron.
Re: correct directorys for www.ltsp.org (for swap)
On Sun, Sep 28, 2003 at 09:54:03AM +0200, Robert Jordens wrote: | the root-filesystem will now point to /usr/share/ltsp/arch and mounted | read-only by the clients | | /usr/share is for architecture independent data. As the root fs for the | clients can be regenerated, that should go into | /var/lib/ltsp/arch. No, in LTSP the one root filesystem image is static data shared between all clients of a given arch and can't be regenerated except by reinstalling LTSP: thus it belongs in /usr not /var. Also it is architecture independent from a Debian packaging perspective as the architecture of the clients need not match the architecture of the file server; it would make sense to have an i386 LTSP root fs stored on a Sparc NFS server, for instance. Thus /usr/share is the correct location. | Now i need to have a swapfile folder where all the NFS_Swap files for | the clints can be. Please tell me wich directory would be fine. | I thinking about /var/cache/ltsp because refering to the FHS [...] | | I guess you are implying the question whether this is the right place or | not... ;-] It seems to me. Possibly /var/tmp or /var/lib would also be an option? Not sure which of the three is best, though. Cameron.
Re: IMPORTANT: your message to html-tidy
On Mon, Sep 22, 2003 at 05:09:30PM -0500, david nicol wrote: | Shamless plug: sign up for totally spam-free forwarding address | at http://pay2send.com Ewww! *recoils in disgust* You don't pay to send, we make others pay to send to you. - if this system become widespread, then you surely /would/ have to pay to send to others. In terms of spam prevention, this has no advantages over TMDA that I can think of, but it seems like a bloody good way to piss off people sending you sending you unsolicited but nevertheless legitimate email[1]. Also, like TMDA and similar systems, it does nothing to help spam that comes from e.g. Debian mailing lists. Cameron. [1] Where the definition of legitimate email may vary from person to person.
Re: non-free software included in contrib
On Mon, Sep 01, 2003 at 09:47:46AM +1000, Matthew Palmer wrote: | When your conclusion is at odds with reality you should rethink your | argument... if Debian was to start classifying packages based on | the probable or possible results of using the package, instead of | the code in the package itself, contrib would disappear and a case | could be made to place all editors in non-free because they can be | used to create non-free stuff. | | Ah, reductio ad absurdum. Such a wonderful means of demonstrating that you | can't think up a decent argument, so you'll take something to it's illogical | extreme to try and scare some people. Don't attack reductio ad absurdum, attack the utter non-sequiturs in the original post. If a package's postinst or main goal is to fetch some non-free piece of software, that is by no means the probable or possible results of using the package, it is the only useful result of using the package as it is intended to be used. A piece of software designed /only/ to fetch and install some non-free software is significantly different to the case of e.g. an editor which can be used to write non-free software or a generalised software installer (like dpkg) which can potentially be used to install non-free software. Cameron.
Re: stack protection
On Sat, Aug 23, 2003 at 11:36:04AM +0200, Milan P. Stanic wrote: | Allowing the dhcp server to write to /dev/mem because it's UID 0 and Unix | security sucks is a bug. | | The problem isn't with UID 0, but with bugs in software. No. The problem is an insecure design that forces the DHCP server to have root priviledges. A finer-grained security would give the DHCP server /just/ enough rights to send and receive the network packets it wants and only fiddle with the files that it actually needs (/var/lib/dhcp/). | I think that the problem cannot be solved in wrong place. It isn't | possible to have secure DHCP server by fixing kernel, but by writing | secure (OK, with less bugs) DHCP server. A kernel with the ability to lock down processes even further would mean that a buggy DHCP server couldn't be exploited to e.g. scribble all over /dev/mem. This is what systems like grsecurity or SE Linux are trying to do. Which is not to say that less-buggy software is a bad goal; but the reality is that programmers are human, and /do/ make mistakes. Cameron.
Re: Bits from the RM
On Wed, Aug 20, 2003 at 12:10:18PM +0200, Michael Piefel wrote: | Am 20.08.03 um 11:08:28 schrieb cobaco: | kde 3.2 release is slated for 8th december[1], is there any chance we'll wait | for it, just so the outdated kde label doesn't apply again immediately after | release? | | It's not KDE 4, so it doesn't really matter that much. There were pretty major changes between KDE 3 and KDE 3.1. As a Debian user, I'd be rather miffed if a new version of KDE came out within a week of sarge being released ... on the other hand, if sarge is to be frozen in a couple of months' time, it seems unlikely that KDE 3.2 will be able to make it in. *grumble* :( Cameron.
Re: Bug#202869: Should MUA only Recommend mail-transfer-agent?
On Tue, Aug 05, 2003 at 08:33:35PM -0700, Erik Steffl wrote: | Mutt can read mail without an MTA, but cannot send mail without one. | | it does not have to be on the same machine It does in the specific case of mutt. I seem to recall Mutt's developers deciding to specifically /not/ support SMTP and only /usr/bin/sendmail for reasons of minimalism and simplicity. Cameron.
GPU fans (was: Re: Future releases of Debian)
On Fri, Jul 25, 2003 at 12:02:09AM -0600, Bob Proulx wrote: | I was able to salvage the fan from the first and fix the | second with it. Just two weeks ago another newer video card fan | died. Wish I had a source for those thin pci card fans... There's a computer shop near me that sells them, but since you probably don't live in Perth, Australia that is unlikely to help you. I have three Nvidia video cards that came with fans - 2 TNT2s and a Geforce 4 - in various computers. The TNT2 fans died after a few months and the cards have been running fine for close to two years (?) with the fans removed. I removed the fan on the Geforce 4 to keep the noise level down and it too seems to work fine. Cameron.
Re: Debian 10th birthday gear
On Tue, Jul 08, 2003 at 11:11:13AM +0200, Sebastian Rittau wrote: |100 million users | 1000 installations | | I would recommend to exchange these last two lines. More installations | than users? If you read it more carefully it implies that there are 100 000 users per installation - which also seems rather unlikely. :) Cameron.
Re: Debian 10th birthday gear
On Tue, Jul 08, 2003 at 12:12:13PM +0200, Mattia Dongili wrote: | actually they are million users :) Dr EvilOne mellion users!!!/Dr Evil CP.
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 11:54:17PM -0500, Joe Wreschnig wrote: | How do you show it's not software? How does it differ from software? | | What if I take the view that Mozilla is an interpreter and anarchism is | the program? Please explain how that differs from the Perl interpreter | and Perl programs. I would argue that while Perl is Turing complete, HTML is not, thus anarchism is not software. Cameron.
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 12:35:06PM -0500, Branden Robinson wrote: | So, what other non-DFSG-free stuff is it silly to ban? Netscape | Navigator? Adobe Acrobat Reader? Of course not. They're software. RFCs aren't software, and so applying the Debian Free /Software/ Guidelines to them seems a little odd. Cameron.
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 06:20:02PM +0100, Neil McGovern wrote: | | When the program is run, it gets put in read/write memory. | So embedded firmware running from an EPROM doesn't count as a program then? CP.
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 02:34:56PM -0500, Branden Robinson wrote: | The Debian Social Contract says Debian Will Remain 100% Free Software. | If there are things in Debian that are not free or not software, | then we may be violation of our guiding principles. The anarchism package is an excellent example of a package in Debian main that, although DFSG-free, is neither software nor software documentation. Cameron.
Re: Please remove RFCs from the documentation in Debian packages
On Thu, Jul 03, 2003 at 02:36:48PM -0500, Branden Robinson wrote: | Well, once you folks have come up with a definition of software, you | be sure and let us know. How about anything included in Debian? That way we won't be in danger of violating the Social Contract #1. Cameron.
Re: Debootstrap, Sid, and console-tools-libs
On Tue, Jul 01, 2003 at 09:57:43PM -0400, Matthew P. McGuire wrote: | | For the curious, the upgrade route failed as well, but on libpam0g not | console-tools-libs. Any work around would be appreciated. | dpkg -i libpam0g*.deb and its dependencies. I don't know /why/ this works when apt doesn't, but it seems to. Cameron.
Re: Packages file under version control
On Tue, Jun 03, 2003 at 10:04:16AM +0200, David Weinehall wrote: | However, given the packages.gz file is much smaller than the total | files being downloaded, is it really worth it? | | When the mirrors sync, yes, when the average user runs | | # apt-get update | # apt-get -u upgrade | | No. Anything to back this up? I just did and apt-get update/dist-upgrade and it wants to download 86MB of stuff. Considering that I last dist-upgraded my (sid) machine just a few days ago, I suspect that for anyone running unstable the Packages.gz and Sources.gz files will be the tip of the iceberg. For anyone running stable, the Packages.gz files rarely change and so apt-get update will not normally bother to download them again. Cameron.
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
On Sun, May 18, 2003 at 11:38:14AM +0100, Neil McGovern wrote: | These are all valid points, however, I still don't want to read HTML | e-mail in mutt. Why not? Mutt deals perfectly well with HTML e-mail if you have lynx or w3m installed on your system and have auto_view text/html in your .muttrc. Cameron.
Re: i386 compatibility libstdc++
On Fri, Apr 25, 2003 at 08:15:05PM -0500, Chris Cheney wrote: | On Fri, Apr 25, 2003 at 05:06:00PM +0200, Arnd Bergmann wrote: | If we really want to split i386 in 'compatible' and 'fast', the i686 border | makes sense because users who care about speed probably bought the machine | during the last two years and those should be i686 compatible. | | i686 has been common for 6 years now (1997 P2/K6), so its hardly just in | the past two years. ;) I agree the split should be at the i686 border | assuming this doesn't harm athlon systems. What about the Via C3? That was introduced not too long ago, runs moderately quickly (~1GHz) with low power consumption, but IIRC doesn't support the i686 instruction set. Cameron.
Re: stop abusing debconf already
On Sun, Apr 20, 2003 at 08:58:14AM +0200, Marc Haber wrote: | | This has always prompted me to ask myself _why_ debconf entries are | persistent then. If I _really_ have to parse config files in my config | script to properly seed debconf to ask the right questions, then why | does debconf have a database in the first place? | So that most of the time, you don't have to hit enter mindlessly to confirm the answers to questions that you've already answered when upgrading? Cameron.
Re: Work-needing packages report for Apr 11, 2003
On Fri, Apr 11, 2003 at 05:23:39PM -0700, Nathan Paul Simons wrote: | | [...] Most sound cards these days don't even *come* with wavetable | synthesis, [...] | Er, the SBLive and its Creative brethren do, don't they? At least, I'm presuming that's what sound fonts are for. Has it been removed in later versions of the card? CP.
