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
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 def
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
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
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
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.
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
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
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
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
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
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
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
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
- [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
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,
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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).
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.
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
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
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.
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
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
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.
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
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
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
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
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?
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
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..
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
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
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.
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
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
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.
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)
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
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
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.
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
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/
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
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.
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
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
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.
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.
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
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
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
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
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
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
74 matches
Mail list logo
