Re: [Prepare mass bug filling][RFC] New lintian tags: privacy-breach
El Tue, 24 de Dec 2013 a las 2:03 AM, Jakub Wilk escribió: * Bastien ROUCARIES , 2013-12-23, 16:23: I have just implemented lintian-privacy-breach tags [1,2] I don't think “privacy breach” is an appropriate expression to use here. Can we find a less judgmental and more technical term? Perhaps "phone home"?
Re: Pulseaudio
There is a chance. On Sat, Dec 28, 2013 at 3:13 PM, Kathleen Spence wrote: Hello, Just wondering if there was any chance that pulseaudio could be removed from trunk (any debain dist) and just go back to basic known working good alsa? Thank you! Debian User
Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]
Matt, Yes, it is possible, but only the contributions of the fork would be GPLv3 only, the original GPLv2+ code would still be just that. Nevertheless, the final product would be GPLv3 only. Cameron Norman On Tue, Dec 31, 2013 at 6:59 AM, Matt Zagrabelny wrote: On Tue, Dec 31, 2013 at 8:54 AM, Clint Adams wrote: On Sun, Dec 29, 2013 at 03:50:06AM +0100, David Weinehall wrote: Apart from the termination clause, the GPLv2 is far more concise, I don't see tivoization as a problem (it's the software I want to protect, not anyone's combination of it with hardware), nor do I care about compatibility with Apache 2.0 -- I do, however, care about compatibility with GPL v2, which GPL v3 isn't. So your doomsday scenario is that if you license something GPLv2+, someone might fork and modify it to be GPLv3+, I was under the impression that forks couldn't change licenses. Is the scenario which Clint describes (legally) possible? -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3uoxx+f0_ca9lwe-n6p50y-cb4gs683w6cvfqvydw4...@mail.gmail.com
Re: GPL and command-line libraries
Once upon a time Wesley W. Terpstra said...
> Good evening!
>
> I'm developing an error-correcting code library which works on a lot of data
> at once. Since the API is quite simple and the cost of process creation
> relatively insignificant, I would like to provide a command-line API.
>
> ...
>
> To the point: I want this library to be released under the GPL, BUT ...
> Would the GPL still protect it?
>
> If someone writes a program that does: popen('my-api');
> does the GPL require that program to also be GPL?
> From the short answer I got on IRC it seemed the answer was: No!
I would think the answer is Yes!, assuming that Mr Wontshare is
distributing your program with his.
Section 2 of the GPL says:
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote
it.
It would seem irrelevant how the two programs are "linked", whether
through popen(3) or dlopen(3). I can't see copyright law making a
distinction between these two library calls. I know the GPL FAQ says
otherwise, but I dont see why.
Furthermore, Mr Wontshare's software could possibly be determined to be
a derative work of yours in which case your licence will apply.
Unfortunately as far as I know, whether or not something is a derative
work is typically determined on a case by case basis, with little or no
guiding rules as applied to software.
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
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: what is /.udev for ?
Once upon a time Ron Johnson said... > On Wed, 2005-02-09 at 12:43 -0800, Ben Pfaff wrote: > > Ron Johnson <[EMAIL PROTECTED]> writes: > > > > > One thing I do know is that traditional apps like df (and anything > > > that uses stat(), I guess) don't know about /.dev, and so return > > > false information: > > > [df output snipped] > > It's not really false, it's just that /.dev is a subtree of / and > > so shows the same information as / does. > > To me, reporting the same information 2 times means that one of > them should not be there. [...] The information is not the same. Some of it is, some of it isn't. If you remove the line entirely, you lose information about the bind mount. It could be argued that df (presumable short for Disk Free) should somehow identify situations where the same "device" appears multiple times and show only the one set of usage data, but that is probably almost impossible to identify. > "So what?", you say. Well, data should only be listed once, not > twice. gtkdiskfree sums up all total and free disk space, and > having /.dev in there totally distorts the truth. That's a problem with gtkdiskfree, not with having /.dev mounted. The situation also occurs when you have a NFS server exporting a number of disk trees from the one filesystem to a client that mounts those multiple trees at different locations in its own filesystem. df (and presumable gtkdiskfree) will display duplicate filesystem usage information. This situation has been around since long before gtkdiskfree existed (even before linux existed), so if it does not accomodate it, it is a deficiency in gtkdiskfree, not NFS mounts. Likewise for bind mounts. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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
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
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: 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
Re: /usr/lib vs /usr/libexec
Once upon a time GOMBAS Gabor said... > > $ df -h > FilesystemSize Used Avail Use% Mounted on > /dev/hda5 99M 75M 19M 80% / > [...] > > $ du -sh /etc/gconf > 26M /etc/gconf > > That's 1/3 of my root fs. It's damn too much. I discovered this a while ago and learned that most of it can be removed. I think they must be conf files so were never automatically removed, but you should find newer versions of all the files in the /etc/gconf directory in /usr/share/gconf. I've got only a couple of schemas left in /etc/gconf and if I check, those may be able to be removed by now as well. -- 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: 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]
Bug#72140: Challenge
Urgent Announcement: Good Day, I have been instructed by my head office to alert you to the fact that your file has been reviewed and there now are a few potential options for you to consider. Please note that this issue is time sensitive and that your previous credit situation is not an issue at this time. Confirm your details on our secure form to ensure our records are accurate and we will be in touch within a few days via the method of your choice. http://www.mort-blox.com/index.php?refid=windsor --Mike Cameron Financial Advisor - eLMR Inc. Did this reach you in error? please let us know so you won't recieve again: http://www.mort-blox.com/r.php -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mass bugfiling: dbconfig-common-using packages violating policy 7.2
On 8/19/06, sean finney <[EMAIL PROTECTED]> wrote: it was recently brought to my attention that the documented method for using the dbconfig-common hooks in a maintainer's postrm script was non-compliant wrt policy 7.2. policy stipulates that packages can not require use of programs from any non-essential packages in the postrm/purge phase. unfortunately, the example packages used as guidelines didn't make any checks to safeguard this, so i suspect most/all of the packages using dbconfig-common do not either. since these are rc-bugs, i don't think the lintian route is the correct path and plan to file the bugs in the next few days. I just uploaded a new version that fixes this problem. Thanks, Cameron Dale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Thorsten Sauter MIA?
I am still unable to contact Thorsten Sauter. Has anyone heard anything from him in the last 4 months? Anything at all? Cameron Dale said the following on 11/04/2006 4:53 PM: > I've been trying to reach Thorsten Sauter for some time now. I've sent > him a couple emails over the last month and have heard nothing back. I > was recently involved in an NMU of libphp-adodb, which he maintains and > was 6 months out of date and had serveral security problems. There was > even a backport done to stable and oldstable which involved many emails > CC'ed to him, and he never responded. > > I've looked at his packages (grdesktop, libphp-adodb, wmmatrix, > xmms-kjofol) but none of them has seen much attention recently, and 2 > have been NMUed recently. I also see that he has worked with the Debian > Install System Team in the past, though I couldn't find any recent (last > 2 years) contributions there either. > > If anyone knows how to contact him, please let me know, or ask him to > orphan his few remaining packages so they might receive the attention > they deserve. > > Here's some examples of him orphaning some packages recently: > > http://lists.debian.org/debian-devel/2005/01/msg8.html > http://lists.debian.org/debian-devel/2005/01/msg01809.html > http://lists.debian.org/debian-devel/2005/01/msg00517.html > > And other people unable to get a hold of him (though they eventually did): > > http://lists.debian.org/debian-qa/2005/06/msg00105.html > -- Cameron Dale signature.asc Description: OpenPGP digital signature
Is Thorsten Sauter MIA?
I've been trying to reach Thorsten Sauter for some time now. I've sent him a couple emails over the last month and have heard nothing back. I was recently involved in an NMU of libphp-adodb, which he maintains and was 6 months out of date and had serveral security problems. There was even a backport done to stable and oldstable which involved many emails CC'ed to him, and he never responded. I've looked at his packages (grdesktop, libphp-adodb, wmmatrix, xmms-kjofol) but none of them has seen much attention recently, and 2 have been NMUed recently. I also see that he has worked with the Debian Install System Team in the past, though I couldn't find any recent (last 2 years) contributions there either. If anyone knows how to contact him, please let me know, or ask him to orphan his few remaining packages so they might receive the attention they deserve. Here's some examples of him orphaning some packages recently: http://lists.debian.org/debian-devel/2005/01/msg8.html http://lists.debian.org/debian-devel/2005/01/msg01809.html http://lists.debian.org/debian-devel/2005/01/msg00517.html And other people unable to get a hold of him (though they eventually did): http://lists.debian.org/debian-qa/2005/06/msg00105.html -- Cameron Dale signature.asc Description: OpenPGP digital signature
Re: If *-module depends on *-utils, should *-source recommend it?
Once upon a time Steve Langasek said... > > There is nothing in the -source package that actually requires (or should > recommend) the -utils package. A much better fix here is for people to get > over the fact that dpkg isn't apt. Apologies for continuing this but having read through the thread I still dont think I understand the issue with dpkg in this situation. Is the following scenario the issue here with dpkg? : foo-modules_1.0 is installed. It is standalone and does not require any other packages to be installed. foo-modules_2.0 is built from foo-source. foo-modules_2.0 depends on foo-utils. User runs "dpkg -i foo-modules_2.0_arch.deb" dpkg first removes foo-modules_1.0 dpkg then check dependencies of foo-modules_2.0 dpkg complains that foo-utils is not installed and aborts the installation of foo-modules_2.0 foo-modules is now in a broken state unable to be used. Networking depends on foo-modules so it is not possible to install foo-utils unless it is locally available. Is this the scenario being argued over? If so, why does dpkg not first check the dependencies of foo-modules_2.0 before removing foo-modules_1.0? If not, could someone explain to me (or point me to a resource) what the issue is? Thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
Once upon a time Scott James Remnant said... > On Tue, 2005-01-11 at 11:15 +1100, Cameron Hutchison wrote: > > > dpkg first removes foo-modules_1.0 > > dpkg then check dependencies of foo-modules_2.0 > > dpkg complains that foo-utils is not installed and aborts the > > installation of foo-modules_2.0 > > > This is incorrect. > > dpkg doesn't remove foo-modules_1.0 at all. Ok. If we change the above sequence to: dpkg unpacks the data contents (data.tar.gz) of foo-modules_2.0 into their final location in the filesystem (possibly overwriting the contents of the package being replaced) dpkg then checks dependencies of foo-modules_2.0 dpkg complains that foo-utils is not installed and aborts the installation of foo-modules_2.0 Is this correct? I gather it is from what you have elaborated further on in the thread. Would it not make sense to change the order of the first two items in the list? I think the reversed order is correct and the current order is not - but that's based only on my limited understanding. Is there a reason that the data.tar.gz needs to be unpacked before the dependencies are checked to see if the package can be installed? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
Once upon a time Scott James Remnant said... > > Actually, this vastly depends on the package, but yes, in general an > unpacked-but-not-configured package is not yet usable. And nor should > it be. Then wouldn't it make sense to avoid this state is possible? An unusable package is obviously of no use. If it can be detected before installation of a package that it will leave the old and new package unusable, dpkg should not unpack the package. > > > > Is there a reason that > > > > the data.tar.gz needs to be unpacked before the dependencies are checked > > > > to see if the package can be installed? > > > > > > > dpkg -i banana_2.0.all.deb icecream_1.0.all.deb > > > > > But to do this you need to know what to install and this can only be > > done by looking at the package metadata and getting the dependencies > > manualy. > > > You didn't put much thought into that, did you? > > Make icecream depend on banana, while banana still depends on icecream. > With your proposal, dpkg can't unpack either because neither dependency > is satisfied. By looking at the set of packages to be installed, dpkg could determine that the final installed state will be valid. During the transition from the old valid package state to the new valid package state the system will go through an inconsistent period, but it does that already. How is this different? I am suggesting that dpkg determine that a dependency is valid or not without needing to unpack the data component of packages to be installed. > Actually users will be more likely using APT, which worries about this > kind of thing all the time. APT can not be told to install a .deb file. I appreciate the suggestion posted earlier of setting up a local repository, but that is a rather roundabout and cumbersome way to install a single .deb file. As long as dpkg is still used to install .deb files, it would be better if it managed the package installations in a more robust manner. > > Why cannot you just admit that dpkg sucks on this issue because there > > are really no sanity checks before potential damage can be done? > > > There's a general assumption that if you install a package, you kinda > want it installed. I also assume that dpkg will not install a package (sorry, "unpack but not configure a package") if the package dependencies are not met. That is the main point of dpkg, is it not - to manage package dependencies? If I just wanted to install a package, I'd just unpack a tarball. > I actually think dpkg's design is reasonably elegant > in that it saves you having to repeat a step that failed last time. This is just personal preference. I think the opposite about this. I dont like it that dpkg maintains this state between each run and that when I tell dpkg to install something, it may continue with something from a previous failed installation. If I tell dpkg to "install A", I expect it to install A and nothing else. Along the same lines, I dont like it that dpkg maintains a "desired" state of a package. This should be maintained by a higher level tool. dpkg should just install and remove packages (and report on what is installed). It's state should contain only what is installed. But, as I say, this is just personal preference. > If you didn't want the package to be unpacked before its dependencies > are installed, you'd just check the dependencies before unpacking. Exactly. So why doesn't dpkg check the dependencies before unpacking? Oh, you mean I should manually check the dependencies before unpacking? If I wanted to do that, I'd install a tarball. dpkg's purpose is to manage dependencies so I dont have to. However, to pick you up on your point about precision, it's not that I want to prevent a package being unpacked before it's dependencies are *installed*, but that I want to prevent it being unpacked before its dependencies are *checked*. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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: 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: 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: 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: 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 :) One mellion users!!! CP.
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: 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.
Re: Should MUA only Recommend mail-transfer-agent?
On Wed, Aug 06, 2003 at 08:04:00AM -0700, Steve Lamb wrote: | > And is a much better choice than expecting every user to locally | > configure smtp settings in the MUA. Lack of direct-SMTP support in mutt | > is a good thing. | | Yeah because entering "smtp.isp.com" is just so trying for most people. It is if they have to dig up what the correct SMTP server is. Or if they're on a laptop whose "correct" local SMTP server changes as a function of time. | And what if the local user wants to use a remote SMTP server for some reason? They are welcome to configure ssmtp or exim to forward to a smarthost. This has the additional advantage that there's only /one/ point where the outgoing SMTP server needs to be specified, and if it changes later, there is only one program that needs to be reconfigured. 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: 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: "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: 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: 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/ 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/. 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: /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: Google Summer of Code 2008
On 2/29/08, Lucas Nussbaum <[EMAIL PROTECTED]> wrote: > Do you have any proof that GSOC students worked 35-40 hours a week on > their GSOC projects? You probably don't. So again, no real data to back > either claim. We have different opinions, and have to live with it. I don't think there's anything in the GSoC that requires 35-40 hours per week. From some of the postings on the students list last year it seems like 20 hours per week is more common. I think Google leaves this up to the mentoring organization and students to work out for themselves, so if we require 35-40 hours per week, we should obtain assurances from the students during the application process that they have that time to commit. > Frankly, if I were in the position of a GSOC student, I would probably > find it very hard to work 35-40 hours per week on my project, while I > could squash some items off my TODO list. Maybe the whole problem is > that I'm less disciplined than our students ;) I was a GSoC student for Debian last year. I estimate I put in close to 35 hours per week, but it may have been closer to 30. This year I don't plan on applying as I'm finishing my thesis, though by your suggestion I would not be accepted anyway as I am at the DAM stage of NM. I also maintain several packages, and was in the NM queue when I applied to GSoC last year. I consider packaging to be a different style of contribution than my GSoC project, as all my packages were just packaging, while my project is my own code (and now a 'native' package). I certainly did work on my other packages during the summer, but just like this work doesn't interfere with school or full-time jobs, it didn't interfere with my GSoC project. That's just me though, and I can certainly see how a student who's also a Debian contributor could be sidetracked by other things. I think it's up to the mentor and others (maybe admins) to make sure the student does not get sidetracked, and to end the project if this happens all the time. However, I don't see the need to ban DDs from the GSoC, as my previous packaging and Debian experience was essential to completing my project. Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479953: uniform header for automated package maintenance emails
On 5/7/08, Joerg Jaspert <[EMAIL PROTECTED]> wrote: > On 11378 March 1977, Peter Eisentraut wrote: > > I think it would be very nice to press these into some common form, such as > > X-Debian: BTS > > X-Debian: DAK > > X-Debian: PTS > > X-Debian: BTS-link > > > Maybe there is a quasi-standard for constructing these X- headers. > > While I think most of daks mails do have X-Katie or X-DAK headers I do > like X-Debian: FOO and so will go and _add_ this to *all* dak mails > now. Including the queue daemon. Should be merged later today. Are these headers supposed to be mail headers, or pseudo-headers such as the BTS accepts. I thought the former, but I just got this from Dak: To: [EMAIL PROTECTED] Subject: Processing of torrentflux_2.3-9_amd64.changes Message-Id: <[EMAIL PROTECTED]> From: Archive Administrator <[EMAIL PROTECTED]> Date: Wed, 07 May 2008 23:56:07 + X-Debian: DAK torrentflux_2.3-9_amd64.changes uploaded successfully to localhost along with the files: torrentflux_2.3-9.dsc torrentflux_2.3-9.diff.gz torrentflux_2.3-9_all.deb Greetings, Your Debian queue daemon Is that a bug, or were my assumptions wrong? FWIW, I think using real (not pseudo) mail headers is a mildly better solution, but I'm happy either way. Thanks, Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Hi, libphp-adodb is bugged in Debian Lenny
On Tue, Jun 17, 2008 at 11:37 AM, Walter Ferreira <[EMAIL PROTECTED]> wrote: > With cacti soft this libs presents a bug, the cacti developers says fix this > bug is work to package maintainner for each linux distribution [0]. [snip] > Parse error: syntax error, unexpected T_STATIC, expecting T_OLD_FUNCTION or > T_FUNCTION or T_VAR or '}' in /usr/share/php/adodb/adodb.inc.php on line 336 Please use reportbug to file a bug report for this issue so I can try to help you with it. Thanks, Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Converting an svn-buildpackage repository to git
Hi, I'm thinking of converting a subversion repository I use for one of my debian packages to git (preferably with all history intact). The repository was created by svn-buildpackage, so it has a structure like this: trunk/ tags/ tags/1.0-1/ branches/ branches/mybranch/ branches/upstream/ branches/upstream/current/ branches/upstream/1.0/ I've tried using git-svn to import this, specifying the "-T trunk -t tags -b branches" options, which mostly seems to work. However, the upstream branch that I end up with in git has a "current" directory and a directory for each upstream version. I also get a branch for "[EMAIL PROTECTED]", which has an unmodified upstream in it (even though it is rev 3 where this is copied to the trunk). Using git-svnimport is slightly worse, though I do get a single master (trunk) branch, and branches for upstream and mybranch (and even tags). However, each branch has most of the expected files, alongside a "current" directory and a directory for each upstream version. In addition, upstream files that I have not modified are not in their proper place, but are instead only found in the "current" and upstream version subdirectories. I think it's clear these programs aren't working properly with the upstream subdirectories in branches, so how can I get a better result? Is there some way to tell the git programs to look in subdirectories for branches? Or, do I need to modify my subversion repository so upstream is a single branch, with the different versions being tags instead (and why doesn't svn-buildpackage use this form)? Any help you can offer is appreciated, Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Converting an svn-buildpackage repository to git
On 5/31/07, Cameron Dale <[EMAIL PROTECTED]> wrote: I'm thinking of converting a subversion repository I use for one of my debian packages to git (preferably with all history intact). [snip] No replies, so I brute-forced it. It's not pretty, but it works. I posted it on the wiki: http://wiki.debian.org/PackagingWithGit/Svn-buildpackageConversion To summarize, dump the repository, run an AWK script on the dump, load into a temporary repository, then use git-svnimport on that. Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428005: ITP: debtorrent -- the BitTorrent proxy for downloading Debian packages
Package: wnpp Severity: wishlist Owner: Cameron Dale <[EMAIL PROTECTED]> * Package name: debtorrent Version : 0.2.0 Upstream Author : Cameron Dale <[EMAIL PROTECTED]> * URL : http://debtorrent.alioth.debian.org/ * License : MIT Programming Lang: Python Description : the BitTorrent proxy for downloading Debian packages To expand on the BitTorrent protocol and application to work effectively with large, constantly updating collections of files, and therefore enable the efficient peer-to-peer downloading of Debian packages from an APT repository. Features: * Downloads from peers, increasing the available bandwidth to the user * Reduces the bandwidth requirements needed to setup a repository of packages * Seamlessly integrates with the current APT tool * Automatically falls back to downloading from an HTTP mirror when peers are not available Requirements: * Python 2.3 or higher * An APT-based package management system (such as Debian distributions have) *** Though there are currently Alpha releases available (0.1.1), I am planning to wait for the upcoming Beta release before packaging this software (possibly as a native package). Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On 6/10/07, Steve Greenland <[EMAIL PROTECTED]> wrote: On 10-Jun-07, 17:47 (CDT), Daniel Burrows <[EMAIL PROTECTED]> wrote: > Since then, it seems like most users have switched to apt-get and > synaptic, with hardly anyone using aptitude or dselect any more Really? I'd have guessed that most people used aptitude. I can't imagine anyone preferring synaptic to aptitude. Of course, I don't really understand why anyone prefers [any graphical MUA] to mutt, or [any graphical newsreader] to trn. I mean, GUIs are nice for things you don't use every day, but for serious work, they're so damn slow and klutzy. I am definitely a GUI person (aptitude is the last non-GUI program with a GUI available that I still use), but I still prefer aptitude to any other. I was under the impression that most others did too, is it not the recommended Debian way? Maybe the non-developer community prefers the GUIs, it's hard to tell, all I know is that whenever I've strayed from aptitude, something has always brought me back (sometimes strange install choices, but usually it's automatic removal). Even on (k)ubuntu, where the recommended package manager is (adept) synaptic, I've tried them out but ended up going back to aptitude, and through the long process of marking everything as automatic and then picking and choosing what I want to install (which is actually easier on ubuntu thanks to the umbrella packages they use). Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: projectb users - we want you
On Wed, Aug 6, 2008 at 12:13 PM, Joerg Jaspert <[EMAIL PROTECTED]> wrote: > Please login to merkel and add yourself to ~joerg/projectb.users (the > file is mode 666, so everyone with login is able to do it). Done. I'm surprised at the few entries after almost a week. Is no one using projectb, or is everyone busy at debconf? > Also, as a user, or potential user, of that database - feel free to let > us know what other data you would like to see in it. We might actually > put it into the database then. (It has to be related to the archive in > some way, so we wont randomly list, eg., bug data or something, but one > example would be adding the descriptions or so). I'd like to have access to all of the hashes of the files, SHA1 in particular, instead of just the MD5. Also, there's some information available in the archive that doesn't seem to be available in projectb, but that it would be nice to have. The suite_architectures table is incomplete (only listing unstable, experimental, sarge-r0, and etch-m68k). And there also isn't a way to determine the codenames from the suite names without looking in the Release files. Thanks, Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
On 8/2/07, Julien BLACHE <[EMAIL PROTECTED]> wrote: > Raphael Hertzog <[EMAIL PROTECTED]> wrote: > > >> Most (if not all) of the recent docs I've come to read mentionned > >> aptitude rather than apt-get. > > > > I'm sorry but that's hardly the case. Google finds about 2 or 3 times more > > reference to "Debian apt-get" than to "Debian aptitude". > > Way to not read (or is that not understand ?) what I wrote :) > > Hint: "recent". I just searched on the Ubuntu forums (a place full of "regular", i.e. not advanced, users) and found these results for Yesterday, which I hope is recent enough. :) threads mentioning apt-get: 146 threads mentioning aptitude: 27 posts mentioning apt-get: 214 posts mentioning aptitude: 34 I don't think there's any doubt from this that most people use/recommend apt-get, even among the "regular" users. Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is Ricardo Cardenes (rcardenes) MIA?
Hi, I've been trying to reach Ricardo Cardenes (rcardenes) for a while now, and not gotten any response. Does anyone know if he's MIA? I've been unable to get a response from him for 5 months now, and his last upload was an RC bug fix a year ago (before that, his last upload was in 2005). Thanks, Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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: 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: 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: 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: 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: 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 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 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: 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
| * 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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 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 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 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: 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: 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 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 "daemon"s. 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 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 "daemon"s. 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: proposal: 'xterm' alternatives entry
Once upon a time martin f krafft said... > > The procedure would be to upload a new 'xterm' package which moves > /usr/bin/xterm to /usr/bin/xterm.real and introduces /usr/bin/xterm > as alternatives symlink in addition to x-terminal-emulator. Then, > progressively, the other x-terminal-emulator providers can start to > add xterm to their postinst scripts. > > What do you think of this proposal. Are there any string points > *against* it? Perhaps this is a bit tangential, but I really wish that xterm replacements would not use the TERM string of "xterm" unless it completely supports the escape sequences that xterm(1) supports. In my bashrc, I use some query escape sequences to determine the text colour and expect to be able to read back a response. When using other terminal emulators that say they are TERM=xterm but aren't, they dont respond to the escape sequence query and my login hangs, waiting to read the response from the terminal. So, I propose the opposite to you. A terminal emulator should not identify itself as xterm in any way unless it completely and accurately supports the same interfaces that xterm(1) does.
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: 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.
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: 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.
