Re: recommends for apparmor in newest linux-image-4.13
On Thu, Nov 23, 2017 at 03:43:10PM +0100, Lars Wirzenius wrote: > > do you think you could manage to either point the general -devel > reading population to a discussion of why using AppArmor by default is > horrible news, or write that yourself? That would seem to be more > constructive than you just showing up after months of discussion > saying it's horrible news. It's just a bad idea of a security model that implements ad-hoc and mostly path based restrictions instead of an actually verified security model. Using that by default makes it much harder to actually use a real MAC based security model, which not only is required for various security sensitive deployments but also a good idea in general. Last but not least apparmor had various issues where certain distros shipped non-upstream features that later turned out to be incompatible with what went upstream.
Re: recommends for apparmor in newest linux-image-4.13
On Thu, Nov 23, 2017 at 01:59:44PM +, Ben Hutchings wrote: > On Thu, 2017-11-23 at 14:58 +0100, Christoph Hellwig wrote: > > On Thu, Nov 23, 2017 at 01:55:49PM +, Ben Hutchings wrote: > > > AppArmor is the default LSM. > > > > There is no such thing as a default LSM in Linux. > > $ grep DEFAULT_SECURITY /boot/config-4.13.0-1-amd64 > # CONFIG_DEFAULT_SECURITY_SELINUX is not set > # CONFIG_DEFAULT_SECURITY_TOMOYO is not set > CONFIG_DEFAULT_SECURITY_APPARMOR=y > # CONFIG_DEFAULT_SECURITY_DAC is not set > CONFIG_DEFAULT_SECURITY="apparmor" That's still not an upstream default lsm. Looks like someone in Debian just decided to make apparmor the default, which is horrible news :(
Re: recommends for apparmor in newest linux-image-4.13
On Thu, Nov 23, 2017 at 01:55:49PM +, Ben Hutchings wrote: > AppArmor is the default LSM. There is no such thing as a default LSM in Linux. > > The changelog suggests it was done that systemd units might use it, > > but in that case those systemd units should depend on apparmor. > > They don't depend on AppArmor unless it's enabled. Which is a decision > made in the kernel configuration (potentially overriden by the kernel > comamnd line). So we should not need the recommends.
recommends for apparmor in newest linux-image-4.13
Hi all, is there any good reason for the recommends of apparmor in the latest linux packages? apparomor is just one of many security modules, and a fairly bogus one to start with. The kernel should not recommend it as it doesn't add at all to the expected kernel functionality. The changelog suggests it was done that systemd units might use it, but in that case those systemd units should depend on apparmor. And to start with there probably should be a policty that no unit file shall fail the boot for a missing security module (any of them).
Re: /run vs /var/run (was: Please test new sysvinit)
On Sun, Dec 18, 2005 at 01:03:37PM -0500, Joe Smith wrote: 1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm, or that if it does exist, that it can be be read as a block device, or that if it can, it has a file system on it. 2. Neither does FHS. 3. The Linux 2.6 device list states that as of now, if /dev/shm exists it should have a tmpfs filesystem. But makes no guarentees that it exists, or that it will remain a filesystem Also Linux allows to not build support for a full-blown tmpfs that supports all posix filesystem operations, but also a cut-down version that's just enough for posix shm. You can't use read or write on files in /dev/shm in that case. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sparc build failure analysis (was Re: StrongARM tactics)
On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote: numactl only supports i386 amd64 ia64 appears to assume intel-style stuff, would need major redesign for other architectures There's nothing intel-specific in here, rather it assumes NUMA support in the kernel. Obviously this is only the case for architectures that support numa. I've actually tested it on ppc64, although not on debian. libaio this should build on all architectures. Currently it needs a tiny bit of architecture-specific code, but that could be avoided by using proper syscall macros instead of trying to do it's own. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: net-tools maintenance status
On Thu, Nov 10, 2005 at 01:48:27PM +0100, Olaf van der Spek wrote: On 10/29/05, Olaf van der Spek [EMAIL PROTECTED] wrote: On 10/25/05, Olaf van der Spek [EMAIL PROTECTED] wrote: On 10/24/05, Bernd Eckenfels [EMAIL PROTECTED] wrote: On Mon, Oct 24, 2005 at 02:21:04PM +0200, Olaf van der Spek wrote:I'm afraid I have to ask the same question again (three months later).What's the status of this package in general and my patch in particular?There was some discussion about it, but nothing really happened. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=222324 there was no consensus on the patch yet, if i see that correctly. Ian Jackson did not respond to my last message, but I think you're the one that has to decide as you're the (upstream) maintainer. Bernd? Bernd? any chance you could get quoting right? this message is totally unreadable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing an intention to produce an armeb port of Debian
On Mon, Sep 19, 2005 at 08:16:42AM +, W. Borgert wrote: On Mon, Sep 19, 2005 at 10:45:26AM +0930, Debonaras Project Lead wrote: The Debonaras project (http://www.debonaras.org) is a group of Linux developers who have created the beginnings of a big-endian ARM (armeb) port of Debian. We have built 2500+ stable packages so far (see http://ftp.debonaras.org). Just a completely uninformed question: Wasn't the -el (endian little) in mipsel a pun on the wrong endianess? If so, shouldn't it be armBE, because it's the right endianess? What gets you the impression there's a wrong endianess? BE for arm is unusal, but I couldn't see why one is wrong or right. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How can I build a package from source that require the source of another (library) package?
On Sat, Sep 17, 2005 at 04:02:56PM -0400, Jaldhar H. Vyas wrote: On Sat, 17 Sep 2005, Tomas Fasth wrote: Well, I can and already do. But it doesn't make a difference because pathan has been programmed to depend on the xerces source, not the exported library interface. For example, this is how the compiler error looks like: I think I had to deal with this kind of thing when I was attempting to deal with packaging dbxml. (And its this kind of thing that makes me glad you're doing it not me!) It's still only looking for header files even though they are not public ones. So you should copy any headers it needs into your (pathan) source package as is done for device driver packages which rely on kernel headers not in the kernel-headers package. This is as wrong as doign that for kernel drivers? What driver packages do that? Look like I need to file some bugs.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#327029: Non-functional with read-only /dev
On Thu, Sep 15, 2005 at 07:44:00PM +0200, Wouter Verhelst wrote: On Thu, Sep 15, 2005 at 07:12:16PM +0200, SZALAY Attila wrote: On Thu, 2005-09-15 at 18:30 +0200, Marco d'Itri wrote: : Tell the user to learn how UNIX works, and stop bitching. AF_UNIX sockets must be created on a rw file system, and a symlink will not work. On FreeBSD it works. So I think it's possible. If I'm not mistaken, FreeBSD got rid of static /dev ages ago, and has had a (properly implemented) DevFS-like thing since. It has the same underlying issue as the Linux one. The FreeBSD developer don't seem to care, though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Handling event device files [was: Bug#324604: [Fwd: The bug persists]]
On Sun, Sep 11, 2005 at 01:05:36PM +0200, Frank Lichtenheld wrote: 2) make makedev produce more of these files (but probably most users don't need them, at least not on desktop PCs which have seldomly two mouses or keyboards) That's the right choice. Lot's of laptops have additional even sources, as do various external disk enclosures or random usb devices. In addition the uinput driver can create additional sources from userspace input. makedev should create all 32 specified /dev/input/eventN devices. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: arch, svn, cvs
Greg Hudson contributes an interesting viewpoint: http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot It's completely unfounded bullshit. Whether you prefer a pyramid or lots of commiters style organization is pretty much a personal or rather community organizational issue. Both have their up- and downsides. All the actual arguments he presents are totally unfounded, abd besides that bitkeeper as the specific SCM he mentions supports multiple commiters style development just fine - for bkbits.net projects for example you can add multiple ssh keys and thus let different people push to the same repository. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: arch, svn, cvs
On Sat, Aug 20, 2005 at 08:57:06PM +0200, Florian Weimer wrote: * Christoph Hellwig: Greg Hudson contributes an interesting viewpoint: http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot It's completely unfounded bullshit. Whether you prefer a pyramid or lots of commiters style organization is pretty much a personal or rather community organizational issue. Both have their up- and downsides. Of course, but if I look at Linux release management (which is still somewhat problematic, as countless vendor-specific patches can attest) and cursory pre-integration peer review, I think he has a point. While I agree that Linus is a very bad release manager that doesn't have anything to do with the developmen model. Is there *any* large project using a pyramid model and produces regular, high-quality releases which are used mostly unchanged by distributors? I don't know about any single large project that produces releases that are used mostly unchanged by distributors. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: arch, svn, cvs
On Sat, Aug 20, 2005 at 02:26:26PM -0700, Thomas Bushnell BSG wrote: Christoph Hellwig [EMAIL PROTECTED] writes: It's completely unfounded bullshit. Do you have a specific complaint? Or is every single sentence in that post unfounded bullshit? Pretty much every sentence. I didn't want to go through because it's rather offtopic here, but as you're requesting it: * Limited development speed: even with the best tools, a single integrator can only achieve a certain level of throughput. the whole point of the pyramid development model as we have in Linux is obviously to delegate decisions where possible possible while having a single point for policy decisions when it comes hard to hard. * Opinionated maintainers: it is a rare individual who is always right. For instance, the mainline Linux kernel does not contain a kernel debugger because Linus won't allow it. I don't think kernel development should be 'easy'. I do not condone single-stepping through code to find the bug. [2] So what's the alternative? People with commit rights fighting each other leading to breakups? I am a firm believer that in the end one person should have the final say for a given tree. This obviously must come with an easy way for anyone challeing that person to have an own not discriminated against, which is something that CVSs in the style of BitKeeper/arch/git/etc allow easily by not having a specific trunk. * Limited filtering: work done by (or approved by) an area maintainer is only subject to review by the branch integrator, and such review may be cursory or nonexistent. Of course, anyone can review all the changes that go into a branch, but only two people are in a position to say no, this change does not meet our standards; it cannot go in and make it stick. That's not true at all. Everyone is in a position to publically speak up and say that a change is not okay. Obviously only the release manager for a specific branch has the final say, but his job is to listen to the right people. This is extremly important to avoid commit wars where people back out others changes without enough discussion. For Linux, the consequences of these limitations have been slow and unpredictable release schedules, poor stability of release branches, and a lack of important standards (for instance, no consistent kernel module ABI or even API within a release branch). As soon as we actually had a release branch that was't a problem. A stable internal API and ABI is not a standard in any traditional sense of the word. It's a feature that's associated with a very high engineering cost. One that's far too high compared to the benefits for most free software projects - there's a reason none of the major free software kernels keep a stable API/ABI. E.g. FreeBSD is breaking their ABIs and APIs in the stable branches all the time and OpenBSD doesn't even have stable branches except for security fixes, they have new release every six month that completely break the API and ABI aswell. Whether you prefer a pyramid or lots of commiters style organization is pretty much a personal or rather community organizational issue. Yes, and Greg is saying that a pyramidal structure doesn't work well, and that bitkeeper doesn't really have many advantages unless you are using a pyramidal structure. For one thing it has enormous adavantages over CVS or even SVN, as having used bitkeeper for projects like that. Alone the feature of offline development and coloberation without a central server is an extremme productivity gain. Let alone the nice merge algorithms. But again I think the pyramidal structure works extremly well for the Linux kernel, it's actually very similar to the development model I know that are used in development of extremly large in-house or propritary software projects I've been involved with where normally every team has a branch or two and these only get merged back by a gatekeeper (which is usually a team of very few people) after extremly careful review. It's not like the BitKeeper model is something that, the concepts are more than 30 years old. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: co-maintainers sought
- [RFA] bcm4400-source - module source for Broadcom's bcm4400 ethernet driver : http://packages.qa.debian.org/b/bcm4400-source.html What problems do you see with the in-kernel b44 driver that you still need bcm4400? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#312669: /sbin/ifconfig: Add ifconfig to user path
On Fri, Jun 10, 2005 at 01:47:00PM +0200, Wouter Verhelst wrote: b) The mere fact that there is something newer which performs the same function does in no way imply that the older implementation is deprecated. This is true for many things -- kernels, network configuration software, /dev implementations. the ifconfig interface can only support a small subset of the linux networking functionality and thus the linux networking maintainers did indeed declare it deprecated. That does not mean it'll go away but you're no encouraged to use it either. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tue, Jun 07, 2005 at 12:04:26PM +0200, Wouter Verhelst wrote: Obviously. What I meant is, we shouldn't throw out doorstop architectures (sic) because they still want 2.4. Which architecture do you refer to? All architectures supported by debian are supported much better by 2.6 thn by 2.4, in fact none of them is supported anymore upstream except for important bugfixes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new cogito package, OpenSSL license issue resolved
On Sat, May 14, 2005 at 08:19:38AM -0600, Sebastian Kuzminsky wrote: This is the last issue I know of keeping this package out of the Debian archives. Yay! There's still the manpage issue, but I expect it will be resolved upstream in the next few days. Any chance you can make the package use the included assemly sha1 implementation on powerpc? It's a notable difference and with that change I could switch from self-compiled cognito to the package. I've updated my Cogito source package (0.10+20050513-3) to use the ppc-sha1 on powerpc, but I dont have a powerpc machine to compile on, so I haven't tested it. It still uses mozilla-sha1 on all the other architectures. Works just fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new cogito package, OpenSSL license issue resolved
On Fri, May 13, 2005 at 11:44:05PM -0600, Sebastian Kuzminsky wrote: I've updated the Cogito package to compile against the upstream-included GPL SHA1 implementation lifted from Mozilla, instead of the (possibly) GPL-incompatible OpenSSL code. Thanks to Florian Weimer and Anibal Monsalve Salazar for bringing this issue to my attention. I have a terrible head for this kind of legal stuff, can't we all just get the code? This is the last issue I know of keeping this package out of the Debian archives. Yay! There's still the manpage issue, but I expect it will be resolved upstream in the next few days. Any chance you can make the package use the included assemly sha1 implementation on powerpc? It's a notable difference and with that change I could switch from self-compiled cognito to the package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Tue, May 10, 2005 at 04:40:11PM -0700, Thomas Bushnell BSG wrote: What does the default Debian install do? Debian seems to use ext3 without directory indexing by default. Which is a sane choice as directory indexing on ext3 still seems to be not fully mature. And as mentioned in another thread it's not available on ext2 at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Tue, May 10, 2005 at 02:03:01PM -0300, Humberto Massa wrote: These are two questions: Q: What filesystems... ? A: Every one of them with the possible exception of FAT and Minix. ext2 doesn't. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Tue, May 10, 2005 at 02:21:50PM -0300, Humberto Massa wrote: ext2 doesn't. With dir_index, yes it does. If you want to forward port a three year old patch full of bugs and incompatible to the dir_index used in ext3 - all luck to you. All debian kernel-image packages don't have it for sure. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Little help about Intel865PERLL with ICH5
On Fri, Apr 29, 2005 at 10:31:39AM -0400, Ivan Adams wrote: Hi, I have Intel865PERLL with ICH5 and I need to make SATA RAID to work. I have made the Enhanced Mode in Raid BIOS, but no one (debian) kernel didn't saw it property. Even now I am with Knoppix 3.8 and it saw it wrong. I have Debian Sid cd1 and Debian Sarge cd1 and Debian Sarge Netinstall and also Debian Stable (7 discs). That RAID isn't. What you see is correct. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: spca5xx -- Device driver for USB webcams based on the spca5xx chips
On Wed, Apr 20, 2005 at 05:57:02PM -0700, Jeff Carr wrote: Could someone give us a simple rundown of how we would submit a patch to the debian kernel sources to add spca5xx support? The spca5xx driver adds support for a large number of USB cameras. Recently Carlos posted something about adding support to debian-devel and Jurij suggested we go here as it is a kernel issue. If you want the driver to get into the Debian kernel-source package please submit it upstream. That's the only way for changes that aren't strictly fixes to get into the Debian kernel packages these days. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FTBFS for illegal archs
On Mon, Apr 18, 2005 at 09:08:14AM +0200, Simon Richter wrote: Hi, Wouter Verhelst wrote: That being said, I'm not sure this is necessary. For starters, Jeroen included the if that's possible bit; but apart from that, it's not because the ACPI interface does not exist for an architecture today that it will never exist; it's not completely impossible that one day, someone will make a PowerPC-based system with an ACPI interface, even if it is unlikely. At that point, it'd be nice if the package would build for PowerPC without /too/ much effort. And as long as it won't build on PowerPC today, your job is done, I'd say. Not quite unlikely. In fact ACPI support for the Pegasos is on my todo list. :-) Umm, why? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] Power Management (Re: FTBFS for illegal archs)
On Mon, Apr 18, 2005 at 10:05:35AM +0200, Simon Richter wrote: Hi, Christoph Hellwig wrote: Not quite unlikely. In fact ACPI support for the Pegasos is on my todo list. :-) Umm, why? Because it is the only way you can shut down PM capable PCI cards. No, that's completely wrong. Individual PCI devices don't care about what higher level mechanisms are used for powermanagment, and there's lots of non ACPI-based PM implementations in the Linux kernel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Vancouver meeting - clarifications
On Wed, Mar 23, 2005 at 01:46:17AM +0100, Pierre THIERRY wrote: Scribit Bas Zoetekouw dies 15/03/2005 hora 10:37: I find it a bit hard to believe that Debian isn't able to support 11 architectures while for example FreeBSD and NetBSD seem to manage fine. - FreeBSD: 6 ports, 12646 packages - Debian: 11 ports, 9157 packages (sarge) [17593 in sid] - NetBSD: 55 ports, 5300 packages I think that Debian stands quite well the comparison... And maybe SCC will enable Debian to ``support'' many more architectures, and in a smooth way, instead of a somewhat all-or-nothing. note that netbsd ports are different from debian or linux kernel ports. they count a port for basically every single piece of hardware while we count one for each user-level incompatible API, which could be half a dozend netbsd ports each. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Fri, Mar 04, 2005 at 02:41:27PM +0100, Josselin Mouette wrote: When you install an alsa-modules package for the 2.4 kernel, you get alsa-base per the dependencies. However, when you install sarge with a 2.6 kernel, alsa-base doesn't end up being installed. It's not a depency in any way. I play sound just fine with OSS drivers without the ALSA mess getting in my way anywhere. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Ipw2100-devel] debian, ipw2200 and wlan0
On Mon, Feb 07, 2005 at 01:24:25PM -0800, Oliver Kurth wrote: Wrong. - the orinoco drivers use eth - the hostap drivers use wlan - madwifi uses ath - at76c503 uses wlan none of the drivers you mention as not using eth%d are in mainline. And they'll get fixed before merge. It seems that every driver uses its own scheme. It's a mess. Fortunately, some drivers give you an option to change it. You don't need driver cooperation for fixing it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Ipw2100-devel] debian, ipw2200 and wlan0
On Mon, Feb 07, 2005 at 04:50:27PM +0100, Mike Hommey wrote: Debian is a distribution which tries to provide good software, implying changes if necessary. Wireless interfaces should be called wlan%d, not eth%d, and upstream doesn't want to change because There are fewer compatability issues with existing distributions by defaulting to eth%d vs. wlan%d. [1] And all upstream drivers do use eth%d. I'll encourage Debian kernel maintainers to make the adequate changes. No, it's a totally arbitrary and pointless change. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292831: udev: udev prevents X from beeing started
On Mon, Jan 31, 2005 at 12:59:46PM -0200, Henrique de Moraes Holschuh wrote: Well, that does kill the gnome depends on udev stuff. But it does not excuse hal from depending on udev. hal is designed around the hotplug system and udev, that's excuse enough I'd say ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292831: udev: udev prevents X from beeing started
On Mon, Jan 31, 2005 at 12:45:42PM -0200, Henrique de Moraes Holschuh wrote: On Mon, 31 Jan 2005, Ron Johnson wrote: Unfortunately, GNOME depends on hal, and hal depends on udev. If it does indeed depend on udev, how does it work under kernel 2.4 at all? Because that statement is utter bullshit. There's a single and optional gnome component that wants to use hal. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initrd, lvm, and devfs
On Mon, Jan 17, 2005 at 08:03:42PM +1100, Russell Coker wrote: Devfs is regarded as obsolete in the kernel source. The current initrd images produced by initrd-tools does the following for a LVM system: mount -nt devfs devfs /dev vgchange -a y umount /dev This relies on a kernel with devfs compiled in to boot a system with an LVM root file system. I think that we should not rely on obsolete kernel features (IE devfs) for any boot option that is supported by the installer (IE LVM). This problem is solved in Fedora by having udev in the initrd, I think that we should use the same solution. Also I think that we should consider when we want to drop support for devfs in the kernel-image packages. At some stage this feature has to be removed as increasing amounts of kernel code don't work well with it. Agreed. But please let's get sarge out first, ok? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initrd, lvm, and devfs
In that case, we should probably drop debian-installer altogether, as it uses DevFS throughout :-) Documentation/feature-removal-schedule.txt in 2.6.11-rc1: What: devfs When: July 2005 Files: fs/devfs/*, include/linux/devfs_fs*.h and assorted devfs function calls throughout the kernel tree Why:It has been unmaintained for a number of years, has unfixable function calls throughout the kernel tree Why:It has been unmaintained for a number of years, has unfixable races, contains a naming policy within the kernel that is against the LSB, and can be replaced by using udev. Who:Greg Kroah-Hartman [EMAIL PROTECTED] so unless Debian wants to stay with stoneage kernels you're better of starting to fix D-I. That beeing said D-I people have been told repeatedly that basing an installer on devfs is a bad idea long time ago, but let's not warm that up again. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New stable version after Sarge
On Fri, Jan 07, 2005 at 08:22:47PM -0600, Marcelo E. Magallon wrote: Thing has a release cycle that's not compatible with a 6 month release period? Say GNOME or KDE? Well, Big Thing gets in the next release. So simple. We are known for missing upstream releases by a hair (sarge is almost certainly going to miss the next upgrade to GNOME, perhaps to KDE, it's already missing X.org, gcc 3.4 is subject to debate) so this wouldn't put us in a worse situation than now. And it's two version for the kernel late, not to mention the glibc from stoneage.
Re: Status of Kernel 2.4.28 packages?
On Wed, Jan 05, 2005 at 09:23:18PM -0800, Marc Wilson wrote: On Sun, Jan 02, 2005 at 08:02:25PM -0600, Steve Greenland wrote: Converting to udev is an additional step, and caused me a lot more work than the basic 2.6 upgrade (mostly getting my head around it, and converting from usbmgr). Converting to udev is in no way a part of converting to a 2.6 kernel. Not even if you're using devfs. Only people unfortunate enough to be using Gnome 2.8 are required to have udev running. I'm running gnome 2.8 just fine without udev
Re: Status of Kernel 2.4.28 packages?
On Thu, Jan 06, 2005 at 12:33:00PM +0100, Wouter Verhelst wrote: AOL. magicdev works just fine to do essentially the same thing as gnome-volume-manager. I don't use magicdev either. I really prefer to mount my storage device myself. Call me a control-freak.
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 04:58:56PM -0500, William Ballard wrote: Apparently the dickhead maintainer of ndiswrapper-source has just gone into his shell and refuses to discuss this problem. Btw, could anyone explain why ndiswrapper is in main? It's only use is to run propritary windows drivers inside the linux kernel, so it's a clear fit for contrib.
Re: New stable version after Sarge
On Wed, Jan 05, 2005 at 08:11:44AM -0500, Greg Folkert wrote: OK, exactly what are YOU NOT DOING, now? Come on, I know you CAN'T be that busy. You only maintain a few trivial packages... come on you could NMU the kernel-source-2.[4|6] fixing all th issues. No need to MMU. The debian-kernel team is doing pretty regular uploads. Sending us diffs to fix bugs is of course highly welcome.
Re: Status of Kernel 2.4.28 packages?
By the way, is there a guide somewhere telling how to switch an unstable system from 2.4 to 2.6? An install of the appropinquate kernel-image package should do it. At least it did for me on various ppc and an x86_64 installed as i386 system.
Re: Status of Kernel 2.4.28 packages?
On Mon, Jan 03, 2005 at 10:19:57AM +0100, Stephan Niemz wrote: Yes, converting from devfs to udev is one thing that doesn't seem to be easy. Another one is the ISDN support. Hasn't that changed significantly, too? And what's going to happen with /etc/modutils/*, how much manual tweaking would be needed there? And I'm sure there is more. I haven't used either devfs nor udev so I can't comment on that. ISDN should be fine nowdays - while there's been quite a lot of ISDN changes there's nothing that's different from the usersland POV.
Re: Status of Kernel 2.4.28 packages?
On Sun, Jan 02, 2005 at 07:37:59PM +0100, Stephan Niemz wrote: The kernel version 2.4.28 is out for almost seven weeks now. Does anybody know about the status of the corresponding Debian packages? And is there an estimation for when the kernel-patch-* packages will support the new kernel version? There's an unfinished 2.4.28 kernel-source package in the debian-kernel SVN repository. For me and several other members of the debian kernel team 2.4 packages have been a much lower priority than 2.6 packages. Given that and that sarge will release with 2.4.27 anyway I'm not sure when a 2.4.28 package will get into unstable. Any reason you're not using 2.6 kernels?
Re: Status of Kernel 2.4.28 packages?
On Sun, Jan 02, 2005 at 08:16:44PM +, Tim Cutts wrote: 2.6 is still too new as far as most ISVs are concerned, and so Debian shouldn't lower the priority of work on 2.4 kernels too much just yet, in my opinion. Debian isn't lowering priority on Linux 2.4 work but individual people are.
Re: Linux Core Consortium
On Tue, Dec 14, 2004 at 08:34:17AM -0500, Ian Murdock wrote: On Fri, 2004-12-10 at 00:44 +0100, Christoph Hellwig wrote: Besides that the LCC sounds like an extraordinarily bad idea, passing around binaries only makes sense if you can't easily reproduce them from the source (which I defined very broadly to include all build scripts and depencies), and that case is the worst possible thing a distribution can get into. The LCC core will be fully reproducible from source. You may (and probably will) lose any certifications if you do that, for the same reason that the distros reproduced from the Red Hat Enterprise Linux source (e.g., White Box Linux) lose them. But it won't be take it or leave it. If reproducing from source and/or modifying the core packages is more important to you than the certifications, you will be able to do that. So again what do you gain by distributing binaries if their reproducible from source?
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 12:40:29PM -0500, Ian Murdock wrote: I can imagine many of you are thinking, What difference does it make if Debian has the support of proprietary software vendors? Ok. If attracting ISV and IHV support to Debian isn't a worthwhile goal in itself, how about helping ensure that Linux remains open and free in the face of increased commercialization (this was, after all, Debian's founding goal)? I've long argued that, as the Linux world's leading non-commercial, community-driven free software distributor, Debian can and should lead the way against the elements of our community that seek to own Linux all to themselves. In fact I'm using Debian exactly because it doesn't try to apeal ISVs, IHVs, OEMs and other business-driven three-letter acronyms. As soon as you ty to please them quality of implementation goes down. Besides that the LCC sounds like an extraordinarily bad idea, passing around binaries only makes sense if you can't easily reproduce them from the source (which I defined very broadly to include all build scripts and depencies), and that case is the worst possible thing a distribution can get into.
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 03:10:52PM -0500, Daniel Jacobowitz wrote: We would never have a common kernel with these vendors anyway - they No does Debian with itself :P
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 03:51:15PM -0500, Ian Murdock wrote: The common core will include a common kernel. See the FAQ at http://componentizedlinux.org/lsb/: Importantly, the LCC platform will include a common kernel, eliminating one of the largest sources of incompatibilities between Linux distributions as each vendor incorporates its own potentially incompatible patch sets. Which already shows that either they're going to play the UL-like rebrand a single distro game or they are totally disconnected from reality.
Re: kernel-patch-acl
On Fri, Dec 05, 2003 at 01:58:27PM +1100, Russell Coker wrote: Much of this patch is scheduled to be included in 2.4.24, so the work required Who claims that?
Re: New kernel headers break LVM build
On Wed, Nov 19, 2003 at 02:18:34PM +, Patrick Caulfield wrote: The only solution I can think of is for the lvm10 package to build-depend on (eg) kernel-source-2.4.19, then in the build script untar the header files, make the arch symlink (ugh) and compile against that. Does anyone else have any nicer ideas? apart from getting everyone to migrate to LVM2 :-) Fix LVM1 to keep copies of the headers it needs in it's source tree.
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Fri, Nov 07, 2003 at 04:22:27PM -0500, Daniel Jacobowitz wrote: Then how do you suggest maintaining a kernel 2.4.20 for one architecture and a 2.4.22 for another architecture, that's bogus to start with..
Re: To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)
On Sun, Sep 21, 2003 at 09:11:29PM +0200, martin f krafft wrote: Why would you have to remove features? I routinely modify my patch packages to apply to Debian kernel source, and this has never required removing a feature. Because maybe you are a kernel hacker and have a clue. While I am quite good with C, networking, and operating systems, I am not willing to port grsecurity's changes to the official IP stack to a 2.5 backport. So you're maintaining a kernelpatch for debian that has sever security implication but you don't know enough about it and the code it touches to do some forward porting? Also, please explain: how is the normal kernel not DFSG but a derived version is? Debian seems to have problems with certain firmware images. Note that the way it's removed in kernel-source is rather useless to meet DFSG as it's a) still in the orig.tar.gz and b) many of the arch kernel patches back out the removal of this code in the diff of the kernel-source package again..
Re: where to install additional kernel modules?
On Sun, Aug 24, 2003 at 01:00:47PM +0200, martin f krafft wrote:
i see pcmcia-source and comedi-source installing the modules into
/lib/modules/`uname -r`/pcmcia and /lib/modules/`uname -r`/comedi.
my bcm4400-source and bcm5700-source packages install into
/lib/modules/`uname -r`/kernel/drivers/net/bcm.
Thinking about it, I argue that it would be better to install them
into /lib/modules/`uname -r`/bcm since
/lib/modules/`uname -r`/kernel is the hierarchy used by the
kernel-image and should not be touched by additional modules that
are not part of the kernel image.
is there a policy item that covers this? what do people think?
the right place is /lib/modules/${kver}/${package}
Re: where to install additional kernel modules?
On Sun, Aug 24, 2003 at 12:03:23PM -0400, Aaron M. Ucko wrote: martin f krafft [EMAIL PROTECTED] writes: Where then should comedi install itself? comedi drivers are for data acquisition cards. /lib/modules/VERSION/misc? no. that's wrong for 2.4+ kernels.
Re: where to install additional kernel modules?
On Sun, Aug 24, 2003 at 12:13:03PM -0400, Aaron M. Ucko wrote:
Christoph Hellwig [EMAIL PROTECTED] writes:
no. that's wrong for 2.4+ kernels.
Interesting, as it seems to be the status quo; I have a bunch of
modules in /lib/modules/2.4.21/misc (from four different modules
packages produced via make-kpkg), which incidentally all seem to load
fine.
They will of course still load fine, but one of the reasons for
the module directory layout change is that each package gets its
own directory under /lib/modules/${kver}/
No need to Cc me, BTW.
Then setup your headers properly..
Re: proposal: per-user temporary directories on by default?
On Wed, Jul 23, 2003 at 02:09:28PM +1000, Martin Pool wrote: There is already a PAM modules, libpam-tmpdir which automatically sets this up on login by creating a per-user directory under /tmp and pointing TMPDIR at it. Despite the scary low version number of 0.04 it seems to work reliably and presumably any bugs could be fixed. Nice idea, wrong implementation. Let login fork the login shell with CLONE_NEWNS and do a VFS-binding from ~/tmp to /tmp.
Re: coreutils with acl support
On Wed, Jul 23, 2003 at 08:18:02AM -0400, Michael Stone wrote: I don't know whether kernels other than linux support acl's, so this may not affect the freebsd or hurd ports. FreeBSD supports ACLs but they don't have a libacl - their support for Posix1003.1e is in libc.
Re: coreutils with acl support
On Wed, Jul 23, 2003 at 08:18:02AM -0400, Michael Stone wrote: libacl1 and libattr1 to base and required status. (Or demote coreutils Oh and btw, the depency on libattr1 is probably a bug. Since glibc 2.3 we have the xattr syscalls in libc (see /usr/include/sys/xattr.h)
Re: proposal: per-user temporary directories on by default?
On Wed, Jul 23, 2003 at 09:23:23AM -0500, Chad Walstrom wrote: On Wed, Jul 23, 2003 at 12:35:15AM -0600, Joel Baker wrote: Except for OS types or versions that don't support that, or people who actually want /tmp when they explicitly request it, even if TMPDIR=~/tmp is fine most of the time. For example, when your home directory is actually on an NFS mounted volume. Changing your TMPDIR to ~/tmp is pretty much insane in that case, setting yourself up for painfully slow write operations on files that SHOULD be considered throw-away anyway. ~/tmp was just an example. You can aswell use $foofilesystem/$USER/tmp or whatever you want. The big difference is that we actually make this identical to /tmp for that particular user.
Re: Bug#198158: architecture i386 isn't i386 anymore
On Thu, Jun 26, 2003 at 09:04:55AM -0400, David B Harris wrote: No it doesn't. I've yet to even hear of an architecture that NetBSD runs on but which Linux doesn't. pc532 They just have a different definition of architecture than us. (ie: our hppa may be three or four arches to the NetBSD kernel folk.) Yupp. But under this different arch concepts there's also hidden lots of hardware supported by only either NetBSD or Linux even if the CPU is supported by both..
Re: Bug#198158: architecture i386 isn't i386 anymore
On Wed, Jun 25, 2003 at 12:35:53PM -0400, Colin Walters wrote: I'm surprised that pthreads apparently doesn't use it. nptl doesn't support i386 anymore because of that.
Re: Bug#198158: architecture i386 isn't i386 anymore
On Wed, Jun 25, 2003 at 02:04:54PM -0500, Gunnar Wolf wrote: ports - NetBSD gives us the potential to bring Debian to _many_ new platforms. It's not that many actually. The only CPU that NetBSD claims to support but Linux doesn't is the pc532. Also the (umerged) Linux VAX and arm26 aren't really useable unlike their NetBSD counterparts.
Bug#198158: architecture i386 isn't i386 anymore
On Wed, Jun 25, 2003 at 02:52:31AM -0500, Branden Robinson wrote: The drawbacks: * Someone actually has to write this kernel patch. http://miaif.lip6.fr/~tarreau/linux-patches/486emulation/
Re: Maintaining kernel source in sarge
On Sun, May 25, 2003 at 01:51:05AM +0200, Arnd Bergmann wrote: SuSE don't have a single kernel source either. They have a set of a few hundred common patches plus some more patches (e.g. 200 for s390) that are used only for one architecture, usually both 32 and 64 bit. Single patches can be enabled or excluded per architecture there. Right. Still they have a single source package for all the achitectures which is a good start. And I talked to people involved in their kernel maintaince and they say they're trying to cut down these conditional applies patches as much as possible because they are a maintaince nightmare As a real-world example, kernel-patch-s390 can provide the ptrace bug fix from Martin Schwidefsky, while kernel-patch-debian contains the generic solution from Alan Cox. This sounds like a really bad idea (okay, not worse than the current situation but still bad). Martin should diff his patch ontop of Alan, if it has other core changes he should really post it to lkml and explain those. Now this unfortunately hasn't happend and if it has incompatible core changes (I haven't checked) that's one of those rare cases where you want to appy a patch condtionally. When building kernel-image-s390, make-kpkg would first apply the arch specific patches and the the arch independent ones that have not been superceded by an arch specific one. Again that's a very bad idea. Arch-independent patches should _always_ be applied before Arch-dependent ones, otherwiese applying MI patches will get absolute horror.
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 06:32:26PM -0400, Matt Zimmerman wrote: It's not noise at all when it's something that we and others (desperately!) want to know about. Then read through the prepatch diffs, everything adding checks to ioctl methods or similar is likely one them.
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 08:10:20PM -0400, Matt Zimmerman wrote: in task_struct then perhaps so assuming that we care about it enough to do it in such a way. Otherwise I don't see your point. Are task_struct and mm_struct exposed to modules? Yes. they should need to be, but I am no expert in the kernel. If this is meant to be this way, then shouldn't the struct have some amount of padding to allow for changes like this without breaking compatibility? At least not for upstream. If you think it's valueable for debian to provide this do it.
Re: Maintaining kernel source in sarge
On Sun, May 25, 2003 at 01:11:44AM -0400, Matt Zimmerman wrote: Then read through the prepatch diffs, everything adding checks to ioctl methods or similar is likely one them. This approach does not scale. Right, you got it. Similarly it doesn't scale to announce all these bits. Just take the latest upstream if you want these kinds of fixes. This is how every bigger upstream (and other projects like OpenBSD) work.
Re: Maintaining kernel source in sarge
On Sun, May 25, 2003 at 08:20:39PM +1000, Russell Coker wrote: What is the status of the pcmcia support anyway? Seems to work fine. Red Hat uses inkernel pcmcia at least. There's some pcmcia drivers not (yet?) merged in the kernel but patching them in is rather easy.
Re: Maintaining kernel source in sarge
On Sun, May 25, 2003 at 02:34:50PM +0200, Arnd Bergmann wrote: When building kernel-image-s390, make-kpkg would first apply the arch specific patches and the the arch independent ones that have not been superceded by an arch specific one. Again that's a very bad idea. Arch-independent patches should _always_ be applied before Arch-dependent ones, otherwiese applying MI patches will get absolute horror. Ok, but I still would love to see single patches instead of one big patch containing all the common stuff. The one big patch is very bad, I agree. You can't really avoid situations where you want a patch on all architectures except one or two. This may be either because a patch breaks on one architecture (which should be of course be fixed, but you might not want to rebuild all kernels and modules on all other architectures because of it), Right. or because the same fix is contained both in the debian collection and in the patch set published by the upstream arch kernel maintainer. No, for that case it shouldn't. Fix the upstream maintainers patch instead.
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 11:37:09AM -0400, Daniel Jacobowitz wrote: Guido, you're not going about it the right way. It's a three-way merge. You take a kernel.org tree, diff it against the architecture tree that you're interested in, and then wiggle it into applying to the kernel source package that comes with Debian. It's not all that hard, and there's a number of tools to help you (dirdiff, for instance; but all I ever use is diff, patch, a text editor, and CVS/BK). Why can't Debian have just one tree for multiple architectures like SuSE and RedHat (sometimes) do. Okay suse supports 'only' i386, x86_64,ppc,ppc64,s390,s390x,ia64 but their kernel also has patches for sparc,sparc64,mips and m68k although I can't guarantee that these really work in the relased tree (but last time I visted their office people were playing with those ports in their spare time). Sure, it's more work but I think it's worth it. And imagine how many people would scream if debian had $BIGNUM XFree86 or glibc packages..
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 01:25:38PM -0400, Daniel Jacobowitz wrote: Sure, it's more work but I think it's worth it. Because no one's done it? Hey, if that was an argument. The question is whether people want it.. We can't count on it because the architecture ports become available at different times; m68k still hasn't caught up IIRC. It would be nice, though. Some m68k architectures might be a hard, I agree. But having a package that works on as many machines as possible would be very cool. Note that although I'm not a DD (and don't have plans to become one), I'd be happy to invest time to help out wherever needed for such a kernel-unified package.
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 07:51:17PM +0200, Karsten Merker wrote: Because it simply did not work out - not all architectures are in sync with Linus' tree Oh, I know that well enough. and if I understood our port maintainer correctly, there are some architecture-specific things Linus does not accept for his tree some architectures have code that can't go into a stable branch anymore, yes. ia64 is the only major example I know. or that are incompatible between other architectures. Umm, no. Sometimes you get conflicts when applying the plain architecture patches, bat that's not due to incompatible requirements but because they touch the same area. I doubt that a standard Suse kernel tree produces a working kernel on mips, mipsel or m68k; can't say for the other architectures, though. Even Marcelo's tree seems to get a working m68k kernel nowdays - although just the less stranger m68k variants. Well, the mips tree is total mess, you'd have to ask the guys playing with it at suse (Andreas Jaeger IIRC). OTOH to the diff to a 2.4.20 XFS tree (i.e. almost like Marcelo's tree) to get it working on my indy was rather small.
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 08:18:40PM +0200, Bernd Eckenfels wrote: On Sat, May 24, 2003 at 07:55:08PM +0200, Christoph Hellwig wrote: Some m68k architectures might be a hard, I agree. But having a package that works on as many machines as possible would be very cool. well, I there is a shared debian-kernel cvs then all architecture maintainers can commit, and the package can be build for those who are ready. This might generate a autobuilder and testing-transition problem :( Yes, same as for gcc,glibc,xfree86. The real question is 'should the kernel be different' and if yes why?
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 02:34:17PM -0400, Matt Zimmerman wrote: What benefit is there in not announcing these problems? Security through obscurity? How can we inform our users of their exposure when we are not informed ourselves about security problems? Noise. You can's accnounce every possibly security-related fix found by an audit - note that it's not clear whether it actually _is_ security-relevant at this point and certainly no one wrote an exploit for it. It is infortunate if this must sometimes happen, but hopefully it is an exception, and in those cases we will need to rebuild modules and provide for both kernel images to be installed at once. It's not an exception. Fixes can and will change the ABI all the time. You should not expect to be able to load a binary kernel module into _any_ other one than the one it was compiled against. Sometimes security fixes may even break the source API. (remember the dcache issues in 2.2.early?).
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 11:37:09AM -0400, Daniel Jacobowitz wrote: Guido, you're not going about it the right way. It's a three-way merge. You take a kernel.org tree, diff it against the architecture tree that you're interested in, and then wiggle it into applying to the kernel source package that comes with Debian. It's not all that hard, and there's a number of tools to help you (dirdiff, for instance; but all I ever use is diff, patch, a text editor, and CVS/BK). These diff some random CVS tree vs kernel-source approach also has other problems. At least kernel-patch-2.4.20-m68k reintroduces the oh so unfree firmware the kernel-source package removes..
