Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Mon, May 06, 2024 at 07:42:11AM -0700, Russ Allbery wrote: > Historically, deleting anything in /var/tmp that hadn't been accessed in > over seven days was a perfectly reasonable and typical configuration. > These days, we have the complication that it's fairly common to turn off > atime updates for performance reasons, which makes it a bit harder to > implement that policy when /var/tmp isn't its own partition and thus > inherits that setting from the rest of the system. Apologies for being a bit late to this, but is this true? relatime-type setups will still update atime if the time between the previous update and the access is larger than some threshold, so you lose some degree of granularity but the rough policy should still apply.
Re: Do not plan to support /usr/lib/pam.d for Debian pam
On Fri, Sep 15, 2023 at 02:08:06PM -0600, Sam Hartman wrote: > > > Apropos of the discussion about removing default configuration from > /etc. > Upstream PAM now supports doing that. You can set up a vendor directory > such as /usr/lib where pam.d and security live. What are other distributions doing here?
Re: HFS/HFS+ are insecure
On Sat, Jul 22, 2023 at 10:21:47AM +0200, Jonas Smedegaard wrote: > Quoting Matthew Garrett (2023-07-22 09:54:59) > > On Sat, Jul 22, 2023 at 03:41:58PM +0800, Paul Wise wrote: > > > Disabling auto-mounting and for manual GUI mounts, requesting users > > > confirm they trust the filesystem they are mounting would avoid that > > > as much as is reasonably possible without entirely deleting the code > > > and without breaking the use-cases of people who need the filesystem > > > code. > > > > When is a user going to plug in a USB stick and *not* click that > > button? > > When the user had plugged in a coworker's phone they were asked to please > charge. We're a long way down the social engineering chain there - I think that turns into a question of how many people are going to benefit from not automounting because of that case vs the number who benefit from the convenience under normal circumstances.
Re: HFS/HFS+ are insecure
On Sat, Jul 22, 2023 at 03:41:58PM +0800, Paul Wise wrote: > That still potentially exposes insecure code to untrusted data, just in > a user context rather than a kernel context. The same goes for uml + > fuse + namespaces, and even guestfs VMs. You can move the data and code > to different contexts, but that doesn't change the fundamental issue. That's still a huge win! You can seccomp it, you can assign LSM restrictions, you can significantly reduce the risk associated with mounting an untrusted filesystem. We have many more controls in a user context than we do in a kernel context. > Disabling auto-mounting and for manual GUI mounts, requesting users > confirm they trust the filesystem they are mounting would avoid that as > much as is reasonably possible without entirely deleting the code and > without breaking the use-cases of people who need the filesystem code. When is a user going to plug in a USB stick and *not* click that button? I'm not analysing a filesystem by hand to check whether it's trustworthy before I want it mounted. There's no reason to automount when the screen is locked and presenting a dialog in the case where one was plugged in and then the screen unlocked is reasonable, but that just makes no sense as generic behaviour.
Re: HFS/HFS+ are insecure
On Fri, Jul 21, 2023 at 10:55:39AM +0200, Marco d'Itri wrote:
> Unless somebody has a better idea then then my plan is to ship in the
> next upload of kmod a file in /etc/modprobe.d/ which uses the blacklist
> directive to prevent automatically loading some file system modules.
I think this would break any existing fstab entries that reference hfs
and hfsplus, and the convenient way to integrate Linux boot with x86
Macs is certainly to have an hfsplus EFI partition so this may be a
legitimate use-case. It also means that anyone who has a need to use one
of these filesystems in a static manner is vulnerable to automount
attacks using them.
Completely untested, but I think something along the lines of:
SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="hfsplus", ENV{UDISKS_AUTO}="0"
LABEL="udisks_insecure_fs_end"
in a udev fragment should work? Any static fstab or mount units should
still work, but it should disable udisks automounting regardless of the
desktop agent involved, even if the fs modules are already loaded.
Re: HFS/HFS+ are insecure
On Thu, Jul 20, 2023 at 07:56:12PM +0200, Marco d'Itri wrote: > Package: src:linux > Severity: normal > > You are totally correct. > Kernel team, please blacklist HFS/HFS+ for automounting. Isn't this a userland policy decision? udisks will happily trigger a module load for hfsplus if udev has identified it, and I don't think there's a trivial mechanism for the kernel to disable that. I believe the only way for the kernel to disable automounting would be to disable the drivers entirely (which we don't want to do), so this probably needs to be assigned elsewhere rather than being a linux bug. (Or, alternatively, we could move hfs(+) support to FUSE and provide extremely tight seccomp policies around them, and then drop kernel support, but even though this has been talked about a bunch I haven't seen anyone try to implement it)
Re: The future of mipsel port
On Tue, Jul 18, 2023 at 12:45:51PM +0800, YunQiang Su wrote: > Known supported hardwares: > MIPS P5600 > Ingenic X2000 > Loongson 3A4000 This sounds reasonable, but do you have a list of hardware currently supported by the mipsel port that would be left unsupported by this?
Re: systmd-analyze security as a release goal
On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote: > qemu is basically an interpreter for foreign machine code. If your > threat model allows access to qemu-user-static for an attacker, they > can run pretty much any binary is if it were native, and the whole > SystemCallArchitectures hardening becomes meaningless. My understanding of the threat is that compatibility syscalls (eg, x32 on amd64) are less well-tested than the local architecture syscalls, and so allowing apps to call them increases the risk - a compromised app that can make compatibility syscalls stands a higher probability of being able to elevate privileges, either in userland or to the kernel itself. Allowing qemu to translate syscalls from other architectures to the local syscall ABI doesn't increase that risk, so isn't a concern. The goal isn't to prevent code form other architectures from running, it's to reduce the attack surface by preventing calls to the compatbility syscalls.
Re: Producing verifiable initramfs images
On Thu, Feb 6, 2020 at 12:07 AM Anthony DeRobertis wrote: > > An interesting challenge you've taken up, I fear it's going to be a lot > of work. Heh. It's work we're doing internally, so it'd be good to get it into an upstream-acceptable form. > On almost all of my older installs, the initramfs is built with > MODULES=dep, because otherwise /boot runs out of space; the amount of > space MODULES=most takes is ever-increasing. So the kernel packages > plopping a default initramfs in /boot would break those systems (but > that's solvable e.g., by having it be an optional extra binary package) Right. Not everyone is going to care about this use case - I'd just like to enable it. Of course, one approach here would be to provide two images - one with a minimal set of modules suitable for booting most systems, and one with a more complete set of modules. It wouldn't precisely solve the MODULES=dep problem, but it should handle both the common resource constrained case (most desktop and laptop hardware) and the case where you probably aren't too worried about the size of /boot (most servers). > Even with the default, it's possible to include extra modules — either > by the admin plopping them in /etc/initramfs-tools/modules or I believe > through package hooks. (I'm not sure if it also does the work > MODULES=dep does and adds any extra modules found). But maybe as long as > the kernel is only loading signed modules, it's OK to put additional > modules in an extra, non-TPM-measured archive? Yup, that's definitely an option. > /etc/modprobe.d is included in initramfs. That's going to be challenging > because it can include both configuration and code, and even without the > code, "arbitrary kernel modules loaded with arbitrary options" seems to > big a difference to ignore. And you can't not include this, since > initramfs loads so many modules. > > Local udev rules (from /etc/udev/rules.d/) are included as well; they > wind up in /usr/lib/udev/rules.d on the initramfs. Those are again an > interesting combination of configuration and code. I think there's two options here: 1) Rather than copy the files in directly, provide an abstraction that covers the initramfs use cases and generates modprobe.d and udev rules from static configuration, or: 2) As long as these files don't change frequently, this isn't a problem - you can ask the user or admin to verify the files and then flag them as acceptable for future measurements. This is slightly less helpful, but is still an improvement (ie, you're able to figure out /which/ files have changed rather than just knowing that something in the initramfs has changed)
Re: Salsa CI news
On Wed, Feb 5, 2020 at 4:33 PM Dmitry Smirnov wrote: > Second, it that binary build, the way it is compiled upstream, would never be > accepted by ftp-masters due to lack of some sources in Debian "main". > That's what I called problem with DFSG compliance. It's worth remembering that Debian infrastructure relied on qmail for a long time, despite it not being under a DFSG compliant license at all. We can argue that everything running in Debian infrastructure /should/ reflect what we ship to users, but the reality is that there are multiple reasons why it may not and the project as a whole hasn't concluded that it should be a requirement to do so.
Re: EFI in Debian
On Mon, Jul 09, 2012 at 12:26:49PM -0400, Ted Ts'o wrote: > On Mon, Jul 09, 2012 at 04:48:38PM +0100, Matthew Garrett wrote: > > Hey, it's hardly my fault that nobody else bothered turning up to the > > well-advertised events where this got discussed... > > If it's documented on paper, it didn't happen. :-) > > Discussions in smoke-filled rooms, even if they are well-advertised, > don't really impress me (This isn't your fault, but Microsoft's.) I look forward to the LF's discussion of this being made public, then. -- Matthew Garrett | mj...@srcf.ucam.org -- 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/20120709163145.ga2...@srcf.ucam.org
Re: EFI in Debian
In article <20120708235244.gb24...@thunk.org> Ted Ts'o wrote: > Matthew Garret believes that this is a requirement; however, there is > no documented paper trail indicating that this is actually necessary. > There are those who believe that Microsoft wouldn't dare revoke a > Linux key because of the antitrust issues that would arise. Hey, it's hardly my fault that nobody else bothered turning up to the well-advertised events where this got discussed... > This would especially true if the bootloader displayed a spash screen > with a huge penguin on it, and the user was obliged to hit a key > acknowledging the spash screen before the boot was allowed to > continue. James is working on a signed bootloader which would do > this. Well, sure, we could associate "Large picture of a penguin on your boot screen" with "your machine has been hacked", but I'm not convinced that's a great strategy. -- Matthew Garrett | mj...@srcf.ucam.org -- 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/e1sogcu-0007me...@chiark.greenend.org.uk
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Henrique de Moraes Holschuh wrote: >On Tue, 21 Apr 2009, Michael Biebl wrote: >> > powertop encourages to disable polling, so it is a big point. >> >> I agree with you in general, but I doubt polling every 2 or 16 seconds will >> make >> any significant difference power consumption wise. > >It does. It won't be much, but still... in any proper new laptop, that >drive will have a non-broken firmware that does SATA power-saving and AN, >and you are waking it up. Hal checks the drive capabilities and shouldn't be polling drives that support async notifications. Is that code not working for you? -- Matthew Garrett | mjg59-chiark.mail.debian.de...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
wrote: >Michael Biebl writes: > >> See the hal-disable-polling man page. In short: hardware support for MMC >> media >> change notification is broken. > >Err. You are using the "broken firmware" argument both ways. > >You should follow your own advice regarding the drives spinning up: >Implement a blacklist of devices with broken MMC media change >notification and only poll devices in this blacklist. The majority of drives would be in that blacklist. This is clearly not a scalable approach. I'm not aware of any PATA drives that provide notification of media change without any polling being involved. -- Matthew Garrett | mjg59-chiark.mail.debian.de...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
wrote: >You'll save between 0.5 and 1.5 W by enabling SATA Aggressive Link Power >Management according to http://www.lesswatts.org/tips/disks.php As this >definitely is measurable, I assume that your measurements have been done >without enabling ALPM? Or maybe the power saving estimated by lesswatts >is based on normal hard drive usage? ALPM is only relevant for AHCI and native SATA drives. The majority of native SATA drives support asynchronous notification, so in that case there won't be any polling. >Could you please share the details of what you've measured? Which type >of drives, controllers and drivers are used in a "typical system"? How >about a "typical laptop" (which in my world is the only system class >where this matters anyway)? How about "modern laptop" (AHCI controller, >SATA DVD)? Standard PATA optical drives, typically connected to an Intel southbridge running in piix mode. -- Matthew Garrett | mjg59-chiark.mail.debian.de...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Giacomo A. Catenazzi wrote: >Michael Biebl wrote: >> It makes no measurable difference here on my laptop (nx7000) running Debian >> Lenny. > >ok, this confirm also Matthew Garrett analysis, and it is good. >But so why powertop reccomend to disable pooling? powertop makes various recommendations that are only useful in very specific circumstances. Disabling polling in hal saves you a small (and probably not useful in the real world) amount of power, but is required to get to the number of wakeups per second that Arjan was aiming for. I haven't been able to measure any difference in power consumption on a typical system. -- Matthew Garrett | mjg59-chiark.mail.debian.de...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Giacomo Catenazzi wrote: >Recently it was discovered that a blinking cursor consumes a lot of power >(blink is normally between 1 and 2 second interval). >I think it should be the same, in this case. >Take into account that both uses hardware, thus not allowing some chips >to rests. No, they're not comparable. The difference in power draw between active and idle in modern GPUs can be on the order of 10-20W. That's not the case for ATA hardware, and even if it were we don't do anything to idle the chipsets at the moment. -- Matthew Garrett | mjg59-chiark.mail.debian.de...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Steve Langasek wrote: >On Tue, Apr 21, 2009 at 06:13:47PM +0200, Michael Biebl wrote: >> > powertop encourages to disable polling, so it is a big point. > >> I agree with you in general, but I doubt polling every 2 or 16 seconds will >> make >> any significant difference power consumption wise. > >If it requires the drive to be spun up (due to limitations in the firmware), >it most certainly does. This is (by far) the uncommon case. Blacklisting drives where this does happen seems reasonable. -- Matthew Garrett | mjg59-chiark.mail.debian.de...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: lrmi vs new kernels vs libx86
On Sun, Mar 08, 2009 at 09:07:29PM +0100, David Paleino wrote: > Matthew: since you're libx86 upstream, you might be interested in the contents > of debian/patches, I'll remove those as soon as you release a new version > (also, please drop debian/ from upstream tarballs) Thanks, I'll take a look at those. -- Matthew Garrett | mj...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: lrmi vs new kernels vs libx86
David Paleino wrote: >I'll start work on liblrmi (i.e. ITP, making it, buildtesting relevant >packages, [..]) if some interest is shown. I'm not sure what the benefit would be over libx86? liblrmi would leave you stuck with x86, whereas using libx86 means that much of the code will also work on amd64. -- Matthew Garrett | mjg59-chiark.mail.debian.de...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: lrmi vs new kernels vs libx86
Evgeni Golov wrote: >On Sun, 08 Mar 2009 17:17:44 +0000 Matthew Garrett wrote: > >> >All other (incl David), is there any interest in forking libx86 and >> >using it globally instead of fixing that ftbfs 7 times? >> >> You could just send a patch to libx86 upstream, you know... > >The patch for what? >For the *_MASK defines FTBFS? Thats the task of the maintainer. >For updating to lrmi 0.10? Maybe. >For incorporating the fixes from v86d? Wasnt able to incorporate them >to the actual libx86 as v86d used 0.10 as base. Whichever of the above you were planning to put in any forked version and are applicable to distributions other than Debian. I'm happy to merge stuff. -- Matthew Garrett | mjg59-chiark.mail.debian.de...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: lrmi vs new kernels vs libx86
Evgeni Golov wrote: >All other (incl David), is there any interest in forking libx86 and >using it globally instead of fixing that ftbfs 7 times? You could just send a patch to libx86 upstream, you know... -- Matthew Garrett | mjg59-chiark.mail.debian.de...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#501137: ITP: acerfand -- Control the fan of the Acer Aspire One
On Tue, Oct 07, 2008 at 05:30:12PM -0500, Gunnar Wolf wrote: > Matthew, and out of personal curiosity (as I will probably continue to > use this, at least until something better comes along): What does the > danger amount to? Say, a random lock-up? Or will it lead to hardware > malfunction (or shorter lifespan)? I am currently setting the > fan-on threshold at 70C, the fan-off at 60C (the default settings for > acerfand) It really depends on how the hardware is designed, but an example would be where the kernel ends up reading the incorrect register when checking the temperature and misinterprets it as requiring a critical thermal shutdown. Lockups are certainly possible, and it's just about conceivable that you could cause hardware damage - though that's a bit of a stretch. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#501137: ITP: acerfand -- Control the fan of the Acer Aspire One
Gunnar Wolf <[EMAIL PROTECTED]> wrote: > Keeps the fan from spinning constantly in the noisy Acer Aspire > One. Provides also tools to query several machine-specific EC > registers Be careful with this - it can't perform the locking used by the kernel and firmware for EC access, so there's a risk of racing and trashing the contents of other registers. This should really be implemented as a kernel driver using either the hwmon or thermal interfaces and a generic fan control daemon implemented on top of that. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
Ben Hutchings <[EMAIL PROTECTED]> wrote: > This means that when draining the battery we do not allow the CPU to run > at full speed, so CPU-bound tasks take longer. This tends to extend > battery life but reduces the processing work derived from the battery, > since other components then take a higher share of power. And when > running on AC, we just waste power, though with a slight performance > gain. If you're using the computer at all, it's not even likely to increase battery life. A CPU at 600MHz and in C0 will draw significantly more power than a CPU at 1.2GHz but in C4. It's more important to finish whatever the CPU is doing quickly than it is to keep it at a low speed. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making debian/copyright machine-interpretable
Sam Hocevar <[EMAIL PROTECTED]> wrote: >And there is more to come. The GPL version 3 is compatible with > the CDDL, but the GPL version 2 isn?t. Which means that in the near > future, GPLv2-only software cannot be distributed as part of a CDDL > operating system such as Nexenta. We have no way to know how much of > Debian should be stripped from such a system. It would be helpful to clarify this. As far as I know, GPLv3 isn't compatible with the CDDL in the sense of "an application may mix sections of source code under these two licenses" - just the "a GPLv3 application may make use of CDDLed libraries" sense. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting Debian to use less power?
Carlo Segre <[EMAIL PROTECTED]> wrote: > Will these options be enabled in 2.6.21? In 2.6.20, CONFIG_TIMER_STATS is > not and renders the program of limited utility on my laptop. 2.6.20 doesn't support dynamic HZ, so your system will be waking up at least HZ times a second anyway. You need 2.6.21 for this to be any practical use. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages newer in Ubuntu than in Debian
On Tue, May 01, 2007 at 11:51:02AM +0200, Martin Michlmayr wrote: > Matthew, you still have some packages in Debian. Should they be > orphaned, or do you intend to maintain them through sponsors? For the most part, I'm planning on maintaining them through sponsors. There's one or two that should probably be orphaned or removed due to lack of upstream development, but I'll check the status of them. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: P3 capabilities (was dselect memory use)
Russell Coker <[EMAIL PROTECTED]> wrote: > P3 server machines can easily handle more RAM, I've had P3 servers with 1G > and > 2G before. But desktops are limited (desktop and server versions of the P3 > CPU have significant differences among other things). Like any other P6-class CPU[1], the Pentium 3 can handle up to 64GB of RAM via PAE. Certain chipsets may be more restrictive, but it's not a function of the CPU. i810 and i815 are documented to be limited to 512MB, but the i820 and i840 were desktop chipsets with support for more. [1] Well, except some of the low-end Pentium Ms. I guess Celerons may be missing it as well. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ondemand governor by default in etch
Anthony DeRobertis <[EMAIL PROTECTED]> wrote: > Matthew Garrett wrote: >> p4-clockmod is entirely useless. It's high-latency and doesn't drop the >> core voltage. > > Nice. Is there a good alternative for P4 machines? Is the ACPI one any > better (assuming a semi-sane BIOS)? It really depends on the hardware - not all P4s support voltage scaling, and without that you'll see no useful effects. The acpi driver is certainly worth a go, as is speedstep-ich (which /might/ work, but I wouldn't be optimistic). Just to elaborate on why p4-clockmod isn't terribly useful: modern CPUs expose multiple degrees of chip-level power management (C states in ACPI speak). C1 is equivilent to having the idle loop use the hlt instruction, and results in lower power usage. C2 is similar to the old APM idle modes, which allowed the processor power down even more of itself. Modern chips tend to support C3 and C4 states, in which the CPU actually disconnects itself from the bus and is pretty much unclocked. At that point, the frequency of the CPU is fairly unimportant. Simply throttling down the processor won't cause any significant reduction in power consumption, since most of what's left switched on would be drawing that much power anyway. Dropping the core voltage, however, is an obvious win - since power consumption is v^2/r, you're saving the square of the amount you've reduced it by. So p4-clockmod doesn't really help you in the case of an entirely idle CPU. And in the more common case of a CPU that /isn't/ entire idle, it can be more harm than good. Halving the speed of the chip means that you're awake for twice as long as you would otherwise be, which may mean that you don't get long enough to drop into the deeper sleep states. Intel's presented figures (at last year's OLS, I think) that suggest that p4-clockmod and straightforward throttling aren't useful approaches to dealing with power consumption. The main reason for the methods being implemented is to deal with cases where a loaded CPU is becoming too hot - the hardware has no way to prevent the OS from scheduling more work, so instead it slows down to reduce heat output. Instantaneous power consumption is reduced, but it now takes twice as long for your job to complete and your hard drive hasn't halved the amount of power it's consuming. If you own a machine that doesn't implement the ACPI interface to throttling (/proc/acpi/processor/*/throttling), then p4-clockmod may be required in order to allow the OS to respond to high temperatures. On the other hand, if you're not in that situation, it's probably more harm than good. There's a few laptops around that don't implement C3 or C4 states, and it might be beneficial there as well. Otherwise, just skip it. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ondemand governor by default in etch
Anthony DeRobertis <[EMAIL PROTECTED]> wrote: > driver: p4-clockmod p4-clockmod is entirely useless. It's high-latency and doesn't drop the core voltage. Deeper C states (C3/C4) will save more power, so the only reason to have it loaded at all is to support thermal throttling. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On including 64-bit libs in 32-bit packages (see #344104)
Bill Allombert <[EMAIL PROTECTED]> wrote: > On Mon, Oct 23, 2006 at 07:30:47PM +0100, Matthew Garrett wrote: >> Bear in mind that the 64-bit kernel doesn't offer all the functionality >> that the 32-bit one does. vm86 is the most obvious thing missing. > > and it seems a 64-bit kernel needs a 64-bit iptables. Yes, applications with close ties to the kernel are likely to be a problem. Last time I checked USB printers didn't work either. It's possible that it'll be a supportable configuration in the future, but we may well have flying cars by then. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396117: ITP: cpufreq-detect -- detect CPU frequency control driver
Peter Palfrader <[EMAIL PROTECTED]> wrote: > How come it never outputs p4_clockmod? I use that happily on several > different machines. In most workloads, p4_clockmod will have a negligable effect on power consumption and has a sufficiently high latency that it creates a noticable reduction in interactive performance. When I worked on that script originally, I decided that anyone who wanted that could just add p4_clockmod to /etc/modules. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On including 64-bit libs in 32-bit packages (see #344104)
Juliusz Chroboczek <[EMAIL PROTECTED]> wrote: > If I'm reading the function int10LinuxLoadSubModule in > os-support/linux/int10/linux.c right, it shouldn't matter. vm86 will > return ENOSYS, which will cause vm86_tst to fail, which will cause the X > server to use x86emu instead of vm86. > > Or am I missing something? The x86emu code doesn't get built on i386, does it? It doesn't look like the INT10_VM86 and INT10_X86EMU conditionals can both be set simultaneously. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On including 64-bit libs in 32-bit packages (see #344104)
Hamish Moffatt <[EMAIL PROTECTED]> wrote: > That might explain some trouble with X on obscure video chipsets > recently reported on debian-amd64 then. On any architecture other than i386, Xorg builds use the x86emu backend rather than the vm86 one. In theory that should let things work happily, but there's no guarantee that the x86emu emulation is strictly accurate. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On including 64-bit libs in 32-bit packages (see #344104)
Hamish Moffatt <[EMAIL PROTECTED]> wrote: > On Mon, Oct 23, 2006 at 07:30:47PM +0100, Matthew Garrett wrote: >> Bear in mind that the 64-bit kernel doesn't offer all the functionality >> that the 32-bit one does. vm86 is the most obvious thing missing. > > [8:23am] [EMAIL PROTECTED]:~> grep VM86 /boot/config-2.6.17-2-amd64 > CONFIG_VM86=y In arch/x86_64/ia32/ia32entry.S, both the vm86 calls (vm86 and vm86old) are stubbed to sys32_vm86_warning, which just printks "vm86 mode not supported on 64 bit kernel" and then returns -ENOSYS. This is moderately likely to bite people on X - the 32 bit packages will use vm86 to make VESA calls, and a surprising number of drivers use VESA calls. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On including 64-bit libs in 32-bit packages (see #344104)
Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > "Nikita V. Youshchenko" <[EMAIL PROTECTED]> writes: >> Is it possible to make 64bit kernels available? > > Sarge does have them and the BTS has a patch for linux-2.6 to enable > them again. Now go and hit the kernel team till they apply the > patch. :) Bear in mind that the 64-bit kernel doesn't offer all the functionality that the 32-bit one does. vm86 is the most obvious thing missing. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
Steve Greenland <[EMAIL PROTECTED]> wrote: > On 16-Aug-06, 19:23 (CDT), Matthew Garrett <[EMAIL PROTECTED]> wrote: >> Yeah, wanting to use functionality when it's available is always a >> dreadful idea. Far better to reimplement it locally in order to ensure >> that we have more copies of it to fix should there ever be any sort of >> security flaw. > > You can't have it both ways. Either your program *requires* the > new/unusual functionality exist on the system, in which case it will > never port to the systems that don't have it, or you'll have to > provde a custom implementation, in which case you have the multiple > implementations problem anyway. Or (c), my program will take advantage of extra functionality when it's present. You seem to be asserting that this level of granularity is unacceptable, so in your model we end up with a choice between less functional software or potential screaming security misery. I think this is arbitrary and unnecessary. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
Steve Greenland <[EMAIL PROTECTED]> wrote: > On 16-Aug-06, 04:00 (CDT), Gabor Gombas <[EMAIL PROTECTED]> wrote: >> This will never work. Real life example from a couple of weeks ago: I >> wrote a program that was running happily on Sarge, then somebody wanted >> to build it on RHEL and failed because the UUID library on RHEL does not >> have uuid_unparse_lower(). > > So you chose to use a function not reliably available. Sounds like bad > planning to me. Yeah, wanting to use functionality when it's available is always a dreadful idea. Far better to reimplement it locally in order to ensure that we have more copies of it to fix should there ever be any sort of security flaw. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
John Goerzen <[EMAIL PROTECTED]> wrote: > Debian is all about not making assumptions like this. If you want this > feature, you are free to install it. And, while this makes Debian a wonderful choice for all sorts of things, it means that Debian itself isn't a compelling desktop distribution. Instead, that's going to be left to derived distributions of one sort or another. Personally, I have no problem with this. But if Debian is unwilling to fill these (not terribly niche) requirements itself, it's not reasonable to complain when people build on Debian in order to provide a more complete solution for a more narrow use case. It's not possible to simultaneously believe that Debian's flexibility is what makes it worthwhile, and that the fact that other projects treat Debian as a supermarket is a bad thing. One or the other. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Steve Kemp <[EMAIL PROTECTED]> wrote: > Neither Ubuntu nor Debian do anything special to get hardware support > that is provided by the kernel proper and tools that neither group > created. That's not actually true. I do a lot of work in Ubuntu to add extra hardware support. All the code gets pushed upstream so will end up in Debian too, but Ubuntu's lack of a concept of package ownership makes it massively easier to do integration work - rather than filing half a dozen bugs and having to chase people up, I can just upload the packages. Given the amount of time I currently have available to me, I tend to choose the latter. If Debian had slightly less of a culture of "Keep your hands off my package", I'd do it here instead. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lilypond and python
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > I don't think you understand. A workaround costs me lots of time to > get in place. I'm perfectly clear about how to go about installing a > workaround. The question is, is the work worth it? Running sed costs you lots of time? Come on. I can understand your irritation at the lack of information about how the python transition is going, but it really shouldn't take you any length of time at all to change things to reference 2.4 directly. If it /is/ horribly awkward and time consuming, I'm sure someone will be willing to submit a patch or NMU it for you. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 5
Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Except that libapt does NOT correctly handle dependency loops and can > split them between dpkg calls causing install failures. > > The more circular depends there are the more likely such a failure > becomes. So wouldn't it be a good thing to remove all the circular > depends that are not neccessary? Wouldn't it be a better thing to fix the bug and have deterministic software? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 5
David Weinehall <[EMAIL PROTECTED]> wrote: > Well, if foo depends on foo-data, and foo-data depends on foo, I find > it really hard to see the point of splitting the two into distinctive > packages... foo-data can often be arch: all, saving mirror space. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Package Tracking System
Denis Barbier <[EMAIL PROTECTED]> wrote: > So by default it is assumed that I should make Ubuntu's work and dig > into these patches to see if some pieces should be applied into Debian? > No thanks, I am getting tired of all those Debian developers who are > more interested in improving Ubuntu than Debian, and just added the > following rules to my .procmailrc: How does dropping potentially useful patches improve Debian? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Erast Benson <[EMAIL PROTECTED]> wrote: > On Wed, 2006-07-12 at 01:02 +0100, Matthew Garrett wrote: >> 1) The GPL requires that all scripts used to control compilation and >> installation of the executable be released under terms compatible with >> the GPL. > > Joerg clearly stands that: > > 1) Makefiles != scripts or at least it is unclear whether Makefiles may > be called "scripts": At that point we start getting into semantic arguments that are basically uninteresting to anyone other than a judge (and possibly not even then). As copyright holder, if this is Joerg's opinion, he can add an exception to the license that avoids the problem entirely. > This means in other words: If I take other people's GPL code and create > a "derived work" from that code, I need to make the whole work available > under GPL. I do not need to make non-GPL code available at all, if GPL > code is derived on that code. I do not need to make the build system > available under GPL (GPL §3 requires me to make it available but does > not mention a license) and the build system is not code that is > "derived" from the GPLd project.""" It's an interesting arugment But, again, this is semantic bickering and entirely unnecessary - if Joerg is copyright holder, he can ensure that the license reflects his opinion. > The key point is: GPL is pure source license. It does not explicitly > require you to use a specific license for the binary in case you make > the source available. Can I suggest you read section 2(b)? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Eric Dorland <[EMAIL PROTECTED]> wrote: > Just to point out that as of Firefox/Thunderbird 2 the entire codebase > is triple licensed under the MPL, GPL and LGPL and any objection to > the MPL as far as Mozilla is concerned is fairly academic at this > point. Seriously? That's absolutely great. Is there any sort of announcement of this anywhere? Thanks, -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Erast Benson <[EMAIL PROTECTED]> wrote: > Don't forget that Joerg were main developer of cdrtools for quite some > time and we should respect his point of view on how result of his work > for the last (what 10 years?) should be licensed. Debian is built on top > of contributions made by people like Joerg. Besides, Joerg made a good > point on why he thinks that his mix of CDDL and GPL code is OK. Please > provide real fact arguments aligned with general license interpretation > rules, if none provided, I suggest to close those bugs. 1) The GPL requires that all scripts used to control compilation and installation of the executable be released under terms compatible with the GPL. 2) The Schily makefile system is licensed under the CDDL. 3) The Schily makefile system is used to control compilation and installation of the executable 4) The CDDL is not compatible with the GPL Now, this can quite easily be worked around by Joerg agreeing that all of the software in the cdrecord tarball can be treated under the terms of the CDDL (assuming that he has the right to do so, of course - any significant patches that have been contributed by people under the terms of the GPL would have to be rewritten or permission granted by the authors). Then it just ends up being a "Is CDDLed material acceptable for Debian?" argument, which is much more straightforward but not really suited for the debian-devel mailing list. (For what it's worth, I have no great objection to the CDDL. Most of the aspects of it that people claim to be unhappy with are also in the MPL, and we still ship Mozilla quite happily. Yes, I know that most of Mozilla is also available under the GPL. I don't really see why that's relevant...) -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: openwatcom -- C/C++ compiler and IDE that produce efficient, portable code
Matthew Palmer <[EMAIL PROTECTED]> wrote: > It's not limited to modified versions Yes it is. In fact, it seems to be limited to the modifications themselves, rather than an entire modified source tree. > it's for a period of time far exceeding that of the distribution. Like Mozilla. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: openwatcom -- C/C++ compiler and IDE that produce efficient, portable code
Adam Borowski <[EMAIL PROTECTED]> wrote: > # 1.4 "Deploy" means to use, sublicense or distribute Covered Code > # other than for Your internal research and development (R&D) and/or > # Personal Use, and includes without limitation, any and all internal > # use or distribution of Covered Code within Your business or > # organization except for R&D use and/or Personal Use, as well as > # direct or indirect sublicensing or distribution of Covered Code by > # You to any third party in any form or manner. > > "use", like, for example, compile a piece of software. You don't > need to distribute openwatcom to anyone to fall within this clause. Ok, but it still needs to be modified. Are you suggesting that the freedom to produce a binary that can't be recompiled by anyone else is a necessary freedom? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: openwatcom -- C/C++ compiler and IDE that produce efficient, portable code
Adam Borowski <[EMAIL PROTECTED]> wrote: > the moment you use openwatcom to compile any work-related piece of > software (thus not "Personal Use"), you need to make the source of > openwatcom publicly available for 12 months. What? "You must make Source Code of all Your Deployed Modifications publicly available under the terms of this License, including the license grants set forth in Section 3 below, for as long as you Deploy the Covered Code or twelve (12) months from the date of initial Deployment, whichever is longer." That is, if you modify openwatcom and distribute that modified version (even internally), you must provide the source code to the modified version to the public. Some people may find that objectionable, but it doesn't appear to mean what you claim. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mactel linux support?
Junichi Uekawa <[EMAIL PROTECTED]> wrote: > Your bug is meant to be already fixed (#355252), but I see there are > some deviations between Debian and Ubuntu (which you seem to > maintain), I'm suspecting there might be problems with Debian code > which is only updated about 3 months ago. Ok, that's a possibility - there were a few patches, and we may have ended up applying slightly different ones. > I thought EFI should work with FAT (I was surprised to see blessing > can be applied to HFS+ also), which is the first partition on the > internal disk. There's two different mechanisms of booting a file under the Mac EFI - you can either put the filename in nvram, or you can bless a file. I believe that the blessing can only be done on HFS+ filesystems. > I'm hoping that I can switch default boot through some kind of nvram > setting. You can, but you can't get into the firmware interface without having blessed a file first. Which needs MacOS right now. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mactel linux support?
Junichi Uekawa <[EMAIL PROTECTED]> wrote: > fix gnu-efi (bug: #376000) I'm sure this is a dupe of a bug I filed, but I can't find it right now. > I don't quite grok how I can make erfit be the default bootloader > without access to MacOSX command-line to 'bless', I hope I can find > out as I delve deeper. You can't. Intel Mac blessing is different to traditional HFS stuff - it's not too difficult to do the blessing, but we have no way of generating HFS+ filesystems without resorting to APSLed code and that seems to be the only useful bootable format. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: One can not guess if somebody is willing to accept private mails or not...
Charles Plessy <[EMAIL PROTECTED]> wrote: > In the early 2006, I complained privately about the sarcastic tone of > one of the answers he made to me on -devel, and I guess that I hurted > him more strongly than if I had done this publicly, because I received > insults on his blog in return. I said "Drop him a private email discussing your concerns", not "Misinterpret what Anthony said, decide that an off-hand comment is an insult and then bitch at him via private email". There's a fairly important difference there. For what it's worth, I'm not keen on the way Anthony dealt with your email. On the other hand, nor do I think your initial email to him was in any way appropriate. However, I don't see him joining threads purely in order to everyone that disagreeing with you may result in personal attacks via private email. And nor do I see him publically attacking people and then asking for any responses to be private. My response to Bill was purely based on the fact that he has criticised Anthony several times during the past couple of weeks, but that no useful discussion has arisen from this. Private email seems like a somewhat better mechanism for discussing this sort of thing than public email - there's less risk of it escalating. Do you have any reason to believe that Anthony would feel any desire to repost private mail that made reasonable arguments, rather than, say, accusing him of ad-hominem attacks for no obvious reason whatsoever[1]? If not, why did you post it? [1] As a hint for answering this question, consider the amount of private mail received by Anthony. Consider the amount of it that has been published on his blog. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who can make binding legal agreements
Bill Allombert <[EMAIL PROTECTED]> wrote: > Given the above link point to your post, you can only blame yourself for > its content. It's not strictly necessary to bitch about Anthony's actions at every opportunity. If you disagree with his course of actions, perhaps dropping him a private mail discussing your concerns would work better? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-DD's in debian-legal
George Danchev <[EMAIL PROTECTED]> wrote: > I do not believe that it is feasible/useful/possible to clarify every single > statement whether stated by an official DD ... It is addressee job to check > that out if they are interested in. If the addressee is not capable to check > official db.debian.org or to ask the sender to confirm that statement with > gpg signed message and to compare that against the official debian-keyring > then he (addresee) will ask for help. The context is a representative of Sun emailing debian-legal, and someone appearing to speak on behalf of Debian emailing him back. The DPL chose to clarify that Walter was not in a position to speak on behalf of Debian, presumably because he felt that there had been potential for confusion. Does that seem unreasonable? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-DD's in debian-legal
Jeremy Hankins <[EMAIL PROTECTED]> wrote: > I'm not sure I understand this part, though. Do you think that folks > like myself, who are not DD's, should not participate in the discussions > on d-l? Do you think that those of us who are not DD's should put a > disclaimer (IANADD) on every message to the list? I can tell you from > experience that the latter gets pretty distracting after a while. This > is a serious question, btw, because you're pointing to what you > evidently consider to be a serious problem, yet you're not suggesting a > solution. Let's go back to Walter's original text: "What is key for Debian is for clarifications to go into the license, not the FAQ. I am spectacularly unimpressed with the arguments I have seen about estoppel etc. It makes the license lawyerbait. Just fix the license." Starting with "What is key for Debian" makes it sound like a policy statement on behalf of Debian, and "Just fix the license" could then be interpreted as a demand from Debian that Sun alter the license. In that context, it seems reasonable to point out that Walter is not in a position to speak on behalf of Debian. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
John Goerzen <[EMAIL PROTECTED]> wrote: > His message was polite, and didn't seem like a demand (despite the use > of the word "cabal"). The "Too many excuses. All inadequate" bit was polite? > His request was quite reasonable, and I heartily agree with it. > > His message also was much more than that, which aj totally dismissed. The post was phrased in an unnecessarily hostile manner. There should be no expectation for people to usefully respond to that sort of thing. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The correct use of debian-devel
Cesare Leonardi <[EMAIL PROTECTED]> wrote: > They seems to say: "If you don't write code, you cannot permit to speak > in debian-devel". Or, that is worse: "If you don't write code you are > not partecipating in the Debian development". No. They say "If you are not participating in Debian development, you do not get to make demands of the project". Being in NM is one way of showing that you're participating in Debian development, but there are several others - including making useful contributions to the debian-devel mailing list. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
John Goerzen <[EMAIL PROTECTED]> wrote: > On Sun, Jun 04, 2006 at 05:39:10PM +1000, Anthony Towns wrote: >> For those playing along at home, Mike isn't a Debian developer, doesn't >> maintain any packages, and isn't a new-maintainer applicant. He doesn't >> even seem to be a regular participant on the debian-legal list. > > That's not even remotely relevant to the points he makes. The identity > of the person that makes the arguments isn't relevant. The arguments > are. How about reading what Anthony actually replied to? Mike demanded that the DPL perform certain actions. Suggesting that somebody actually get involved in Debian before making demands of its leadership isn't unreasonable. Alternatively, it could be phrased as a request. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding ddccontrol to debian
Hendrik Sattler <[EMAIL PROTECTED]> wrote: > Actually, this should be a kernel thing as a user might also control this=20 > stuff for a VT. > There is a framework for LCD backlight in kernel (2.6.16 at least), maybe t= > his=20 > could be utilized or extended for such stuff? That would require the kernel to be able to speak DDC to every video card one of these devices could be plugged into. At the moment, it can't. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys
Junichi Uekawa <[EMAIL PROTECTED]> wrote: > This has opened a can of worms; because your transnational ID was as > official as it could get. Most of us do not know what other countries > consider to be official, and it's more of an intent and goodwill > rather than scientific or legally binding officialness that we are > signing and interchaning keys based on ID cards. If there's anyone who should be revoking signatures, it's the people who are signing keys without being fairly certain that they belong to the correct person. This really shouldn't be controversial. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removal of svenl from the project
On Wed, Mar 15, 2006 at 05:56:05PM +0100, Sven Luther wrote: > I was a bit short on you, because you started to make noise about the reason > for the refusal being a #include being wrongly placed in the patch, and a > printk that was not strictly necessary, which i think for someone like you or > the ubuntu kernel team is a joke reason not to even do a single reply on the > bug report. I hadn't replied to the bug report because I wasn't involved in the Ubuntu kernel at the point when it was filed, so I didn't reply there. When you brought my attention to it, I pointed out two issues that you could fix in seconds. I had none of the hardware in question, and didn't want to spend time trying to work out if there was some subtle reason for the code being there. There was certainly no effort to sabotage your platform, and I haven't heard any sort of apology for your accusations. > I also remember that you where much less than curteous and extremely > patronizing when i proposed myself to handle the ubuntu powerpc kernels, a > year or so ago, when i still believed that cooperation was possible, and i > never heard you apologize for that, so should we expulse you for both being > offensive to me (and having gone over to the ennemy :) ? I have absolutely no recollection of this happening, and can't find any references to you talking to me about it in my logs. You appeared to spend some time arguing with Thibaut Varene - are you sure you're not confused? Friendly, -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removal of svenl from the project
Mike Bird <[EMAIL PROTECTED]> wrote: > Your accusation fails to allege sufficient facts to constitute > an allegation of defamation. The facts have previously been discussed elsewhere. I replied merely to point out that Sven does not always apologise for his behaviour. > Rather than wasting list bandwidth, please consult a solicitor. I have absolutely no interest in starting legal action against Sven. And rather than wasting /my/ bandwidth, would you please not Cc me on replies? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removal of svenl from the project
Pierre Habouzit <[EMAIL PROTECTED]> wrote: > I know Sven may sometimes be a bit overpresent in some trolls, he also=20 > may answer too quick, without having read the mail he answers to=20 > correctly enough. But AFAICT, I've always seen him apologies when he=20 > did so (I can provide links if you can't believe me). Sven has insulted me and accused me of engaging in a conspiracy against him and his employers in order to cover up my own incompetence on more than one occasion without any hint of an apology. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG4 and combined works [was: Anton's amendment]
Anton Zinoviev <[EMAIL PROTECTED]> wrote: > Obviously any patch that is automatically generated in this way is a > work based on A. The license of A permits to use "patch files" for > the purpose of modifying the sources of A at build time. However the > license of A doesn't explicitly permit us to use "patch files" or any > other work based on A for the purpose of modifying the sources of > another program, in our case B. If the license forbids the use of modified code in other works, then it's plainly not a free license. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Wed, Jan 18, 2006 at 08:43:48PM -0500, Ian Murdock wrote: > Fact is, the potential for confusion here never even occurred to > me when we started doing this at Progeny. Quite the contrary to what > Matthew suggests, it seems to me that changing the Maintainer > field is a perfectly reasonable thing to do now that I'm aware of it. Ah, my apologies. I'd assumed it was something that you'd probably have thought about, so I'll happily withdraw that. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ironies abound (was Re: GPL v3 draft)
I do apologise. These should plainly have been on -legal. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ironies abound (was Re: GPL v3 draft)
Glenn Maynard <[EMAIL PROTECTED]> wrote: > On Wed, Jan 18, 2006 at 03:21:14AM +, Matthew Garrett wrote: >> I'm not going to defend patch clauses. I think they're massively >> horrible things, and the world would be a better place without them. But >> deciding that they're not free any more would involve altering our >> standards of freedom, and I don't see any way that we can reasonably do >> that. > > It's disappointing, then, that Debian is so fixed in stone that it's > incapable of correcting its mistakes. Declaring patch clauses non-free isn't correcting a mistake. It's stating that the entire community's definition of freedom is wrong. Patch clauses have been acceptable for longer than Debian has existed. The degree of freedom they provide has, if anything, increased with improvements in technology. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, Jan 17, 2006 at 07:32:20PM -0800, Thomas Bushnell BSG wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: > > >> Have they modified these packages? > > > > Some of them, yes. Mostly the backports. > > What happens to the maintainer field in these cases? I haven't seen any that have been changed. > Certainly, if they are modifying the packages, I would think the same > there here applies as in the case of Ubuntu: they should reset the > Maintainer field to point to themselves, and continue to give credit > to the Debian developer in a suitable fashion. The founder of Debian seems to disagree, but still. The DCCA situation suggests that we need to define exactly what we want and make it clear to all derived distributions that this is what we expect. This isn't something that only affects Ubuntu - we're talking about a large number of fairly major distributions. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, Jan 17, 2006 at 07:23:41PM -0800, Thomas Bushnell BSG wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: > > The DCCA distribution is a mixture of packages from Sarge plus some > > backports. In all cases, the Maintainer: field appears to be the same as > > in Debian. Several derived distributions (gnuLinEx, Knoppix, Mepis, > > Linspire, Progency, Sun-Wah, UserLinux (ha ha ha) and Xandros) are > > supposed to be using these packages in an unmodified form, as I > > understand it. > > Have they modified these packages? Some of them, yes. Mostly the backports. > What do they do about version numbering of recompilations? (Do they > recompile?) They have to recompile the backports, at least. I haven't checked the MD5s of the binaries, but that's easy enough to do. > Do they modify the packages at all? As stated, in some cases yes. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ironies abound (was Re: GPL v3 draft)
Don Armstrong <[EMAIL PROTECTED]> wrote: > On Wed, 18 Jan 2006, Matthew Garrett wrote: >> Patch clauses only prohibit code reuse if your build system is >> insufficiently complicated. > > And you are willing to contain an entire copy of the codebase from > which you are extracting. [Unless the patch clause is per-file...] Oh, sure. But bandwidth and disk space are relatively cheap commodities compared to what they used to be. If the Linux source tree contained an entire copy of the BSD kernel source, I doubt anyone would really bat an eyelid. It's certainly an inconvenience, but I don't think it really prevents anything of any great interest. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: >> Other than, say, the DCC Alliance? > > I wasn't aware of them until just now. :) Wow! > Interestingly, the DCC Alliance says that it wants to become part of > Debian. > > Do you have information on their plans with respect to the issues > discussed in this thread? The DCCA distribution is a mixture of packages from Sarge plus some backports. In all cases, the Maintainer: field appears to be the same as in Debian. Several derived distributions (gnuLinEx, Knoppix, Mepis, Linspire, Progency, Sun-Wah, UserLinux (ha ha ha) and Xandros) are supposed to be using these packages in an unmodified form, as I understand it. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [ad-hominem construct deleted]
John Hasler <[EMAIL PROTECTED]> wrote: > mdz writes: >> Have you ever received such a notification? > > Yes. I haven't. I'm going to cry now :-((( -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > No other Debian derivative, as far as I'm aware, says that it > cooperates fully with Debian. Other than, say, the DCC Alliance? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dissection of an Ubuntu PR message
David Nusinow <[EMAIL PROTECTED]> wrote: > Please stop trying to twist my words around. Canonical didn't contribute > back. An individual who happened to work for Canonical did. If someone > employed by the US government contributes to Debian of his own volition do > we say that the US government gives back to Debian? Do we say that your > employer gives back to Debian? If it's an authorised use of company time, sure. Whether or not it is in this case, I don't know. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265920
Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> wrote: > i've thought for a long time about how to reply to your message. Let's quickly outline what's happened here: 1) Luke files a bug agains Debian. So far, so good. 2) Some time later, Luke contacts a KDE developer and asks if the bug has been fixed. 3) The response is, approximately, "This is the first I've heard of it". We (Debian) have a bug tracking system in order to keep track of bugs in our distribution. It's the job of either the bug submitter or (more usually) the Debian maintainer to contact upstream to make sure that they're aware of the bug. It is *not* the upstream maintainer's job to examine Debian's bug database. Which is, uh, pretty much what Dirk said. Luke, what the christ are you upset about? Nobody's said "Don't report this bug to us", they've said "If you report a bug to Debian and nobody forwards it, we know nothing about it". -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Federico Di Gregorio <[EMAIL PROTECTED]> wrote: > What really I don't understand is how a proprietary tool can promote > more efficient collaboration on the development of _free software_. > Sounds like an ossimoron to me. I think it's hard to argue against the fact that Sourceforge has encouraged a great deal of collaboration on free software, despite now not being entirely open. (It's probably also hard to argue against the fact that Sourceforge has discouraged a great deal of collaboration, what with their inability to do things like run a stable CVS service. Thanks, Sourceforge) -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Frans Jessop <[EMAIL PROTECTED]> wrote: > Ubuntu's launchpad is amazing. Do you think it would be helpful if all DD's > worked through it on their projects? Wouldn't that keep things more > organized and efficient? Or perhaps Debian could build its own version of > launchpad which is better. Again, I think it would do a good job keeping > everything organized an efficient. Launchpad is currently non-free, so it doesn't seem terribly likely. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Michelle Konzack <[EMAIL PROTECTED]> wrote: > If you need to pay 450.000 DHs (42.000 ¤) for an E3 of 34 MBit > which give you maximum 20-24 MBit because the Infrastructure is > to bad in Morocco then it IS expensive. No. Based on what you've said, the price is the same regardless of whether you download 1GB or 20GB in a month. Therefore, as long as the increase in traffic doesn't saturate your line, the cost per GB is 0. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dependencies on makedev
Adam Heath <[EMAIL PROTECTED]> wrote: > That's the wrong answer. > > What ever happened to standard unix tools? chmod/mkdir/chown/mv? > > You're suggesting doing things like some other OS(like Windows, were you have > to edit a registry). Indeed. Editing plain text configuration files has never been the Unix way, and vi certainly isn't a standard unix tool. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
Lars Wirzenius <[EMAIL PROTECTED]> wrote: > * Less strong ownership of packages. (snip) > This idea hasn't been tested. It could be tested if > some group of maintainers declared that some or all > of their packages were part of the experiment, that > anyone could NMU them for any reason whatsoever, as > long as they take proper care not to mess the package > up. It's not something that's been tested in Debian, but it's the standard way of getting things done in Ubuntu. So far, it seems to have worked fairly well. The two situations aren't directly analagous since Ubuntu has a smaller and more cohesive group of people involved, but I think it's possibly indicative that this proposal would work. I think I've said this before, but I have no objections to anyone uploading any of my packages. I'd be even happier if anyone who did so was willing to enter into some sort of reciprocal agreement. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: QPL and non-free
Matthew Garrett <[EMAIL PROTECTED]> wrote: > Francesco Poli <[EMAIL PROTECTED]> wrote: > >> That is completely irrelevant. The FSF doesn't use the DFSG as freeness >> guidelines. > > But the DFSG are intended to be a more detailed description of what free > software (a term initially defined by the FSF) is. If the DFSG are > wildly divergent from the FSF's viewpoint, we need to figure out how and > why. Having two different definitions of free software does nothing to > help the community. Argh, sorry. This should have been on -legal -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: QPL and non-free
Francesco Poli <[EMAIL PROTECTED]> wrote: > That is completely irrelevant. The FSF doesn't use the DFSG as freeness > guidelines. But the DFSG are intended to be a more detailed description of what free software (a term initially defined by the FSF) is. If the DFSG are wildly divergent from the FSF's viewpoint, we need to figure out how and why. Having two different definitions of free software does nothing to help the community. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: QPL and non-free
Michael Poole <[EMAIL PROTECTED]> wrote: > Wesley J. Landaker writes: > >> Readers should also note that the FSF believes[1] that the QPL is a free >> license; but it's not GPL compatible. > > This does not mean a lot. They believe the same thing of the GNU FDL, > but the FDL is non-DFSG-free in the general case. I don't think the FSF have ever claimed that the GFDL would class as a free software license. Their standards for free documentation licenses are clearly different to the DFSG. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Anand Kumria <[EMAIL PROTECTED]> wrote: > On Wed, Dec 14, 2005 at 09:30:15AM +, David Pashley wrote: >> 5.5 hours for a package to make it through NEW. I think you owe some >> people an apology. > > -> 8126 T Oct 25 Debian Installe ( 46) xmovie_1.9.13-0_i386.changes is N= > EW >10552 T Dec 14 Joerg Jaspert ( 23) xmovie_1.9.13-0_i386.changes REJ= > ECTED > > How many hours is that, David? David's example is representative. Your one isn't. Of all the people to pick on in Debian, the ftp-masters aren't the obvious target. How about dealing with some more significant problems? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
Steve Langasek <[EMAIL PROTECTED]> wrote: > On Sun, Dec 18, 2005 at 03:57:35AM +, Matthew Garrett wrote: >> Under Linux, can't all of this be done with mount --move anyway? I'm not >> convinced that we actually need a /run any more. > > So you would have these files stored in /var/run from the beginning, and use > mount --move to shuffle them around if /var is a separate mount point? I'm > pretty sure --move is a 2.6-only feature, too, and we haven't yet gotten rid > of 2.4 for etch; and is there an equivalent solution for non-Linux ports? Yeah, it's 2.6 only. Are we seriously expecting to ship etch with 2.4 kernels? Is anyone still doing active security support for it? The linux-onlyness of it is a bit more awkward, but non-Linux OSs tend to be lacking things like decent ram filesystems anyway, so the semantics are going to vary in any case. But I guess if it's difficult, sticking with /run might be easier. Has anyone talked to the FHS guys about this? (I haven't actually checked whether it's in there, so the answer may well be "yes" :) ) -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
Steve Langasek <[EMAIL PROTECTED]> wrote: > The principle is the same: /lib is used only for the minimal system required > for booting, and everything else should go in /usr/lib. /run should be used > only for junk that needs to be stored early in the boot sequence, and > everything else should go in /var/run. Under Linux, can't all of this be done with mount --move anyway? I'm not convinced that we actually need a /run any more. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Thijs Kinkhorst <[EMAIL PROTECTED]> wrote: > I'm not really convinced that such an approach would have a significant > effect as long as you're not measuring existing DD's to the same > standards. Which, as far as I can see, does not happen. A procedure is in place for developers to be ejected from the project. If you feel that anyone is behaving in a way that would not have allowed them to get through NM, then please do invoke it. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le vendredi 09 décembre 2005 à 23:49 +1000, Anthony Towns a écrit : >> How many more years are we going to waste time with this hysteria before >> realising it doesn't achieve anything but "rapidly sucking the fun out >> of things"? > > How many developer resignations will you need to understand inaction > from people at key positions sucks the fun out of things in a worse way? Reading these threads makes me want to resign. WILL YOU NOT THINK OF THE CHILDREN? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Common Power-Management Framework
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > Nobody said the user can't give his input on how the service will behave. > That's what the GUI is for, and what configuration files are for. The user needs to be able to configure this without any form of excessive privileges, which means that some amount of policy has to be determined by processes running as the user. It's also important that this sort of thing can only be controlled by an appropriate user - if I'm logged in on a background VT, I shouldn't be able to trigger power management state transitions. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Common Power-Management Framework
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > 1. power management is system infrastructure. I can explain WHY it > is so, but I don't think many people would argue that power > management is an user-level service. Whether a laptop suspends when you close the lid is a per-user preference. The length of time before an idle system suspends is a per-user preference. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Common Power-Management Framework
Kevin Locke <[EMAIL PROTECTED]> wrote: > Interesting. I wasn't aware to what extent HAL is able to notify > programs about power-related events. In fact, we had briefly discussed > receiving events from HAL in addition to the power-daemons. Perhaps > with some work, we would be able to rely completely on HAL. At the moment, HAL will listen for ACPI events and has partial support for PMU notifications. APM is a bit more awkward, since the standard doesn't really allow for a great deal of policy - the system is told that a suspend is going to happen, has an opportunity to run some code and then the system suspends. This can possibly be hacked around in the kernel to some extent, but, well. However, the basic idea behind using HAL is to get PM event notification in a platform independent way. Whether it's an ACPI or a PMU-based system is fairly uninteresting - userspace just wants to know that the user has pressed the power button, pulled the poewr, closed the lid or whatever. HAL provides that, so lets the policy daemon be entirely ignorant of the underlying hardware. > The common power-management framework is really intended to be a policy > layer, so it may still have some value for running scripts based on > power events (it could fill the roll of the "small daemon" you talk > about in your second mail to this thread). However, I realize that the > GNOME Power Manager[1], and likely a KDE equivalent, already handles > several of the tasks normally associated with power-management, so > perhaps there is no need for another program to be handling events. Gnome power manager is an implementation of a policy daemon, yes. It's well-suited to certain types of desktop environment, but it's not ideally suited to server environments. On a desktop, stuff like screen-blanking and response to lid closing is a per-user preference, whereas on a server you probably don't want users to be able to fiddle with that. > What are your (or anyone else's) thoughts about the value of a daemon to > invoke scripts based on the power-related HAL events? Is this > unnecessary given the function of the GNOME Power Manager and > equivalents, or would it have enough value to be worth implementing? HAL will call scripts to perform certain actions, such as triggering suspends and (where possible) will do things like altering screen brightness on request. The policy daemon is responsible for asking for these things to happen, and is also necessary for notifying other bits of userspace. > Would it be better to spend our time adding features to the Gnome Power > Manager and equivalents instead of creating a separate program? I'm > sure we will be discussing this extensively on the powermgmt-devel list > in the near future, but I would like to hear what the -devel community > thinks of this idea (it's too easy to justify ones own work in ones own > mind). I think a small, light daemon that runs configurable scripts on various HAL events would be an entirely sensible thing to implement. Ideally, it should check whether some user manager has started and (depending on configuration) let that take care of things instead. That way, there's a system-wide config up until the point where someone logs in. So, I think the best plan of action would be: 1) Implement a small PM daemon on top of HAL (basically a replacement for apmd, acpid and pmud) a) Should call HAL for system state transitions b) Should call scripts installed by other packages c) Should be configurable in terms of default response to actions d) Should (optionally) get out of the way if a user runs a power management daemon 2) Define a mechanism for packages to drop scripts into this framework 3) Ensure that packages like gnome-power-manager and whatever KDE come up with are able to call the same scripts when necessary -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Common Power-Management Framework
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > Can I tell HAL to just handle power management instead of touching anything > else, and get it to do the right thing in a headless, GUIless server > environment? Can I do that with standard, system-wide configuration files? HAL on its own will never trigger any actions. It will provide information about events, and it can be asked to perform certain transitions. For power management there's a need for another small daemon that provides local policy, and it's entirely sensible to have one that can be configured for a server-type environment. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: Common Power-Management Framework
Kevin Locke <[EMAIL PROTECTED]> wrote: > Fundamentally, our goal is to create an architecture-independent, > power-system-independent, and power-daemon-independent system to handle > power-related events (e.g. lid close, battery events). This will likely > happen by hooks from the power daemons (scripts in their event handlers) > that will invoke a common event handler. This common handler will run > its system-independent scripts (possibly in the style of a runlevel) > based on its configuration, then return control to the daemon to > complete its handling. To a large extent, this sort of work is currently being done in HAL. Is there any need to create another level of abstraction, or should we just work on that? It also sounds (though I'm not certain) like you're concentrating on system-wide power management transitions, whereas I'd argue that it needs to be possible for configuration to be done on a per-user basis (you wouldn't believe the degree of argument over whether closing the lid of a laptop should trigger a suspend or not) -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Peter Samuelson <[EMAIL PROTECTED]> wrote: > [Goswin von Brederlow] >> > Use 2: I have this Ubuntu CD and want to know which debs are from >> >debian and which got recompiled >> >=20 >> > Look for all debs that have a deb signature of the debian archive >> > (to be added to dinstall at some point). > > [Matthew Garrett] >> The answer is "all of them", so this one's not very compelling. [Someone with a horrid, horrid quoting style] > What? All Ubuntu .deb files went through ftp-master.debian.org at some > point? I know you can't actually mean that. Hmmm, perhaps you meant > "none of them"? If so, that's an Ubuntu-specific answer, because even > if Ubuntu recompiles all packages, many Debian derivative distributions > do not. I was unclear. All of them are recompiled. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Use 2: I have this Ubuntu CD and want to know which debs are from >debian and which got recompiled > > Look for all debs that have a deb signature of the debian archive > (to be added to dinstall at some point). The answer is "all of them", so this one's not very compelling. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I am still on the keyring. With my old key.
Marc Haber <[EMAIL PROTECTED]> wrote: > What are you trying to do instead? If you might have noticed, we have > _just_ _another_ ftpmaster situation _right_ _now_, and from handling > of #339686 by a member of the DPL team I don't get the impression that > the DPL team actually cares. (#340306) > In fact, how can the message of "we don't care about security if it's > ftpmaster breaking security features" be more official than by the > downgrade of that bug to wishlist by a DPL team member? Rejecting signed packages is not equivalent to "we don't care about security". You appear to be complaining that a bug that was filed on Tuesday hasn't been fixed on Wednesday. Further, this appears to be a bug that affects a tiny number of people. Expecting it to be prioritised over anything else that people may be working on is insane, and bringing it up in such a hostile manner (not to mention attempting to use it to claim that the DPL team don't care about your particular issue) isn't going to result in it being fixed faster. Instead, it's going to result in people assuming that you're some sort of conspiracy-theory loon. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sugarcrm licence issue
Glenn Maynard <[EMAIL PROTECTED]> wrote: > On Thu, Nov 10, 2005 at 05:42:07PM +, Matthew Garrett wrote: >> This is based on the contents of their copyright files. Can we please >> stop this "The only code under the MPL is Mozilla" argument? > > It's not an "argument"--nobody is claiming that a license is free or non- > free based on whether or not the license is being used. (I'm a bit > disappointed that you're essentially saying "even if this license is > non-free, you can probably get away with it anyway", though.) The ultimate decision over whether a license is free or not rests with the FTP masters. They can be overruled by a general resolution. The presence of code under the MPL in the main section of the archive suggests (but does not confirm) that the people who actually make the decision believe it to conform to the DFSG. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request: Source for parts of GNU/Solaris
George Danchev <[EMAIL PROTECTED]> wrote: > Sorry, this is another violation. The source comes first, then binaries next > to it. Hm, I wonder how could you make people believe (trust>) in your "open > source" project ? George, I don't think there's much point in repeating objections that have already been made. It's quite clear what our issues with Nexenta are now - shouting at them further is unlikely to help things get resolved to our satisfaction. (This does, of course, assume that the Nexenta guys are willing to actually discuss the issues rather than ignoring them. I'll remain optimistic for a while) -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
