Re: Spliting packages between pkg and pkg-data
On Tue, Nov 22, 2005 at 09:48:53AM +0100, Goswin von Brederlow wrote: > Aparently yes. Menu seems to be smart enough for that, see other > mails. Bad example, sorry. But manpages certainly aren't. Well, being able to read the documentation (including the man page) of a binary without requiring the binary to be installed is a good thing IMHO. Especially for big and complex software that is likely to be split to pkg and pkg-data... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to use lsb init-functions
On Tue, Nov 22, 2005 at 12:21:37PM +0100, Thomas Hood wrote: > But the problem is that foo may produce output and this will break up the nice > single-line format. I don't mind deverting stdout to /dev/null, but I am > reluctant to divert stderr to /dev/null and error messages will also break up > formatting: I'm thinking that it would be very useful to redirect stderr to a file (say /var/log/boot/.error). It happens far too often that the error message scrolls off the screen, then fonty/gdm/etc. starts making scrolling back impossible. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Heimdal autotools dramas
On Sat, Nov 26, 2005 at 11:44:48AM +1100, Brian May wrote: > The Heimdal configure script correctly detects that glob() is present > in libc6, but appears to build glob.c anyway, and it also installs > glob.h. It tests for the GLOB_QUOTE flag but that is not present in glibc, so it decides that glibc's glob() function is not good enough. See cf/broken-glob.m4. Also, libroken.so contains only the symbol rk_glob(), not glob(). I haven't checked the actual Debian package, but unless it overwrites /usr/include/glob.h (which I highly doubt) Heimdal's version of glob() will not be used outside of Heimdal. > A similar situation appears to exist with fnmatch, but I haven't > investigated in detail. I've just tried a Heimdal-0.7.1 build here and libroken does not have fnmatch. > lib/roken/Makefile.am has: > > if have_glob_h > glob_h = > else > glob_h = glob.h > endif > > Some how that is being set in lib/roken/Makefile, despite the fact > have_glob_h is also set (this is confusing me!!!) > > I simply cannot see where lib/roken/Makefile.am references > glob.c. However, lib/roken/Makefile references glob$U.lo and glob$U.o. Heimdal is using the AC_LIBOBJ machinery. > I asked upstream Heimdal and got no response. I did not see your mail on the heimdal-discuss list... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- 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)
On Sat, Dec 17, 2005 at 06:09:05PM -0600, Peter Samuelson wrote: > Given the need, and now the reality, of /run, is there any need for a > separate /var/run? I vote we migrate to /var/run -> /run, at least in > the default install. If /run is tmpfs, it means everything stored there eats virtual memory. So a musch metter strategy would be to move everything from /run to /var/run at the end of the boot process. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: /run vs /var/run (was: Please test new sysvinit)
On Sun, Dec 18, 2005 at 05:24:40PM +0100, Marco d'Itri wrote: > Reality check: packages have been using it for a long time and the world > has not fallen yet. Emphasis on "yet". /dev/shm was created to be used uniquely by shm_open(), and violating this _will_ cause some problems after a certain level of abuse. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
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. AFAIK /dev/shm is just an internal detail of glibc's implementation of shm_open() on Linux 2.6 kernels, so it has nothing to do with POSIX. > 2. Neither does FHS. Ditto. > 1. It exists only on Linux-based OS's > 2. There is no gaurentee that it will continue to be there at all > 3. There is no guareteee that it will remain a filesystem in the future > even if it is there. > 4. There is no gaurentee that it exists at all. Yep. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
On Sun, Dec 18, 2005 at 06:54:42PM +, Andrew M.A. Cater wrote: > Will it work fine over a serial console? Is it fine for ex-Solaris/HP-UX > /AIX admins who may have got used to nvi? As an ex-Solaris/AIX admin I can say that I used vim there too (except when the filesystem containing vim did not come up for some reason :-) And yes, it works fine on a real vt220. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
On Mon, Dec 19, 2005 at 01:49:37AM +0100, Bernd Eckenfels wrote:
> tmpfs stores run ressources in vm more efficiently (since they are otherwise
> in th buffercache and the filesystem).
Quite the contrary. tmpfs needs vm space even if nobody needs the data
(thus, it could be evicted from the page cache if it were on a
disk-backed fs). I just looked at my /var/run directory and I found only
5 files (4 of them are sockets) that are used often ("often" = "at least
once in every 5 minutes" here). The rest should definitely not occupy my
VM space in any form.
> And you cant really move the run ressources.
What you mean by that? /run is needed to store things before the real
/var is mounted for a very few things that _must_ run before /var is
mounted. If something is capable to be started _after_ /var is mounted,
I think it has no right to use /run.
For the few things that really needs /run it could be easy to implement
moving data out of /run after /var is mounted.
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
On Mon, Dec 19, 2005 at 01:14:45PM +0100, Marco d'Itri wrote: > > But what about the future, and what about it being specifically for > > POSIX-SHM? > Tell us... Do you have reasons to believe that we will be forced to > remove /dev/shm/ in the future? If in the future glibc decides to choose some other implementation for shm_open(), then it has no reason to stay. > > /run doesn't especially /need/ to be a tmpfs fs does it? It could It does not have much sense if it is not a tmpfs, since we already have /var/run. Gabog -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please test new sysvinit, sysv-rc, initscripts
On Sat, Dec 17, 2005 at 11:49:55PM +0100, Thomas Hood wrote:
> A new version of sysvinit (binary packages sysvinit, sysv-rc and initscripts)
> has
> just been uploaded to experimental.
Just tried it on amd64.
> After rebooting you should have logs of the fsck runs in
> /var/log/fsck/check{root,fs}.
> You should have a rotated /var/log/dmesg, and /var/log/boot if you are using
> bootlogd.
fsck logs are OK, /var/log/dmesg.0 is root:root instead of root:adm.
bottlogd is still broken.
> Please check /etc/motd. Is this now a symlink to /var/run/motd and are its
> contents
> correct?
Correct.
> Try switching to runlevel 1. Does this work as expected?
Did not try it yet.
> Now shut down. Any problems?
Well, the reboot already used the new scripts and it went OK.
> Boot with INIT_VERBOSE=yes kernel parameter. Is the boot more verbose?
I'd say yes, but it scrolls too fast, and first fonty then gdm makes
scrollback impossible (and framebuffer with bigger resolution is out of
question because the fglrx driver does not like it).
> Any glitches in any of the messages?
Without a working bootlogd it is hard to tell.
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
On Mon, Dec 19, 2005 at 07:40:24PM +0100, Bernd Eckenfels wrote: > Yes, we are talking about a few pages in swap space at most. It's 55 pages (220k) on this machine (368k on ext3). And it's a simple desktop with not much running state. > And I am not sure if "not used" is valid here, since symlinks and > sockets would be in memory even if they are not used be constant directory > reads/stats in /var/run, methinks. I don't have any symlinks under /var/run. Bound sockets do consume kernel memory; the extra VM usage in case of tmpfs is orthogonal to that. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
On Mon, Dec 19, 2005 at 09:12:22PM +0100, Marco d'Itri wrote:
> There is no reason why it should be moved.
But there is a reason why its current abusers should get fixed to use
something else. Just think what happens if an app does something like
shm_open("/network", ...), or even better, shm_open("/network/ifstate",
O_RDWR|O_CREAT|O_TRUNC), which is perfectly legal for any random
application to do.
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
Re: /run vs /var/run
On Mon, Dec 19, 2005 at 09:11:42PM +0100, Marco d'Itri wrote: > The real lesson in this is that object names should be choosed > carefully. Exactly. Therefore any object not created by shm_open() should not use the /dev/shm/ path prefix. Glad you finally agree :-) Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: /run vs /var/run
On Tue, Dec 20, 2005 at 03:59:04AM +1000, Anthony Towns wrote: > Putting R in / spoils the otherwise read-only character of that > directory. *shrug* No, it's not. Mounting something over a top-level subdirectory does not require / to be writeable. > That is, pretty much everything that runs as a daemon, and that might > have otherwise used /var in general. That's why I'd like to have a check for /run (or /lib/run or whatever) being empty at the end of the boot process, and complain if it isn't (possibly also remounting it r/o so abusers break noisily). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
On Mon, Dec 19, 2005 at 03:33:35PM -0800, John H. Robinson, IV wrote: > One of the first things I do on any debian install is to install vim, > and set that to be a far higher priority for editor than anything else > imaginable. Same here. That's why I do not care what the default editor in base is :-) Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs. /lib/run
On Mon, Dec 19, 2005 at 11:41:26AM -0800, Russ Allbery wrote: > Perhaps this is a bad idea (or perhaps this is even how it's already > done), but given the very limited number of things that would have to use > /run, would it be possible to write them all to use /var/run if it's > available and only if it's not, fall back on /run? That way, /run could > be created during the boot process, then moved to /var/run and removed > again once /var is available, making it a transient aspect of the boot > process and not hanging around as a new top-level directory. /run cannot be created during the boot process since it may be needed before / is writeable. Also, if /run does not exist when the system is up, the admin may think that the name is available and put real data there (or just simply expect it to be present once he/she mkdir'ed it), so removing it is dangerous. What may be possible (and I'd prefer) is to use a name like /.run, but AFAIK there are people here who dislike dot-names in /. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- 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)
On Tue, Dec 20, 2005 at 09:23:05AM -0200, Henrique de Moraes Holschuh wrote: > Then IMHO Debian is NOT the appropriate system to run on that box. Get a non > glibc-based one that also likes to pass -Os to gcc and compiles the kernel > with -Os. AFAIK -Os is not the upstream default for kernel builds only because it still triggers compiler bugs sometimes. At least that was the conclusion of the last such discussion on linux-kernel. > All VM-based filesystems in the BSDs, Linux and Solaris swap out just fine, > and they always have done so AFAIK. In fact, other than the filesystems for > on-chip disks (flash or eeproms), and stuff like procfs and sysfs that > aren't really there anyway, I have never heard of non-swappable in-memory > filesystems. ramfs. It was there before tmpfs (and it's also the smallest and simplest file system one can get on Linux). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
On Tue, Dec 20, 2005 at 12:13:15PM +0100, Thomas Hood wrote: > The new mountvirtfs prints such warnings for all the "virtual" > filesystems. Where? I do not see any such checks in /etc/init.d/mountvirtfs. Also, to be effective, such checks should run at level S99 in rc[2345].d and I do not see anything there. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
On Tue, Dec 20, 2005 at 12:19:16AM -0500, Glenn Maynard wrote: > Well, I get to use other people's systems now and then, and I'm always having > to ask people to install vim. If vim is the default, and configured to act > like vi by default, then people who like old vi get it, and people who like > new vim can change it with just .vimrc. A rare opportunity--everybody wins. > :) Not everyone. I personally like the advanced features like syntax highlighting, and that definitely will not be part of base (because vim-runtime is huge). And if I still have to install vim-runtime by hand then I can install the vim binary package as well. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
On Tue, Dec 20, 2005 at 09:09:27AM +, Roger Leigh wrote: > Wouldn't that break mtab, or will that be moved under /var at the end > of booting? It can be moved. Using mount --bind even the mount binary does not need to be modified for the new location. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs. /lib/run
On Tue, Dec 20, 2005 at 03:42:56PM +1000, Anthony Towns wrote: > For (a) you just need to wait until S10checkroot.sh has finished. > For (b) you need to wait until S35mountall.sh has finished. I really like storing the fsck logs and that requires a writable place before S10checkroot.sh finishes. Also, adding a new directory somewhere seems better than making the boot process more complicated and more rigid. Just make sure that new directory cannot be used after the boot process finishes to catch abusers :-) Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: Please test new sysvinit, sysv-rc, initscripts
On Tue, Dec 20, 2005 at 12:45:13AM +0100, Frans Pop wrote: > Did you move bootlogd init script before udev? That should at least get > you a log and allow you to check the rest. That worked, thanks. However, I just compared the contents of /dev/.static/dev and /dev and I cannot see any device that is not present in the latter and that should have any affect on bootlogd. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: /run vs. /lib/run
On Tue, Dec 20, 2005 at 10:09:43PM +1000, Anthony Towns wrote: > The other aspect is that /var's the place for stuff that varies during > normal use; introducing some other place for the same thing is redundant > and thus more complex. The more I think about it, the usage of /run matches /tmp much better than /var. It is for _temporary_ storage until a better place becomes available. If you want to tweak the boot process, then tweaking the mounting of /tmp seems better than tweaking the mounting of /var. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
On Tue, Dec 20, 2005 at 08:57:08AM -0600, Steve Greenland wrote: > [1] Dark blue on black. Need I say more? That's not vim's fault: $ echo $TERM xterm But this is gnome-terminal, and _not_ xterm. xterm used a white default background since prehistoric times, so when vim detects xterm, it uses colors that look good with the traditional xterm colors. If it detects the Linux console, it uses colors that look good on the console. Now, if your terminal pretends to be xterm but does not use the color scheme of xterm, how should vim know that? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs. /lib/run
On Tue, Dec 20, 2005 at 10:46:33PM +1000, Anthony Towns wrote: > Likewise, how do you document the mounting of /run in mtab? If you start with a read-only /, then no matter what you do, the first mount command will not be recorded in mtab (unless you implement a mount daemon that holds mtab in memory until it can write it somewhere). > Hrm, why don't we use /proc/mounts for mtab information, and have mount > store _only the extra information it needs_ in /var/run/mtab? What keeps you from implementing it? :-) A more technical problem: right now /etc/mtab presents a system-wide global view, but the contents of /proc/mounts is already a per-process thing. So if you want to use that, then you need a separate /var/run/mtab. for every process (or at least one mtab file per different namespace; which brings the question how do you detect if the process changes its namespace). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: /run vs. /lib/run
On Thu, Dec 22, 2005 at 05:18:43PM +1100, Russell Coker wrote: > Putting system directories under /tmp is a really bad idea, it opens > possibilities of race condition attacks by unprivileged users against system > processes. Generally for almost everything we should be looking to reduce > usage of /tmp rather than increase it. There are no user processes while scripts in /etc/rcS.d are running (not even crontabs, since cron itself has not been started yet). And after rc.S has finished, there is no justification to use /run. I do not see the problem with using /tmp for /run. Moreover, I still mean to mount a temporary tmpfs over /tmp, so unless you explicitely do a "chmod a+w /tmp", normal user processes will not even be able to write to /tmp until the real /tmp is mounted (or if /tmp is on /, until the tmpfs is unmounted). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
On Thu, Dec 22, 2005 at 05:09:02PM +1100, Russell Coker wrote: > 368K is an issue on a machine with 8M of RAM, it's an annoyance if you have > 16M, beyond about 32M it stops being a problem. Yeah, and a new optimization step only takes a few thenth of a second and only a few extra KB of memory, so why not add it. And then everyone complains that newer gcc versions are far slower than 2.95 was, and some people can no more build complex applications due to the extra memory requirements. It was just 0.1% bloat every time... > Incidentally if 368K of memory is a problem for you then you should probably > stop using Ext3. Ext2 uses less RAM (and that's RAM for non-pagable data). I hope you've already packed the UPS you're sending me. Once I receive it, I'll gladly convert my ext3 filesystems to ext2. Until then please do not compare apples to oranges. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: udev event completion order
On Wed, Dec 21, 2005 at 07:29:16PM +, Darren Salt wrote:
> I'd call that broken, just as I consider udev (076) to be broken given that
> it breaks expectations wrt device naming. (Here, it swapped the names of the
> DVD drives (drivers are built-in) and sound devices (drivers are modular).)
But that was the case since ages for SCSI (and nowadays SATA) devices.
No modules, no udev, just plug a new SATA/SCSI disk to the controller
that happens to be detected first and all disks on the other controller
gets renamed. udev at least provides persistent naming using
/dev/disk/by-{id,label,path,uuid}.
This is also true for any add-on cards: just plug them to different PCI
slots and the attached devices get renamed. This is not a new problem at
all, it is just exposed more frequently as device handling becomes more
and more dynamic. Again, udev now provides an interface to manually
override these name changes if you want to.
Btw. looking at /usr/src/linux/init/do_mounts.c, the name parsing is
already sysfs-based so it would not be too hard to implement support for
something like
"root=/sys/devices/pci:00/:00:1e.0/:02:0b.2/usb5/5-2/5-2.4/5-2.4:1.0/host0/target0:0:0/0:0:0:0"
So if you worry that the "root=/dev/sda1" style is not
reliable (well, it never was), then talk to the kernel guys.
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: udev event completion order
On Mon, Jan 02, 2006 at 08:19:30PM +0100, Adrian von Bidder wrote: > 'just plug' is the watchword. New device model just needs a reboot - in > some circumstances device numbering is random without hardware changes and > without software changes. So it exposes a bug more frequently than before. So why not fix the bug instead of trying to paper over it forever? As a user, a disk changing its name if I plug it to a different SATA connector that happens to be connected to a different chip on the MB is _exactly_ the same problem as the name change on a single reboot. Any solution must work equally well for the "plugged in at a different location" case or it is useless. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: bits from the release team
On Wed, Jan 04, 2006 at 01:10:49AM +0100, Sven Luther wrote: > But yes, udev is the problematic case, altough i run 2.6.14 with sarge udev > and it works. AFAIK it should work with the default ruleset. It breaks only with certain custom rules due to a bug in the libsysfs version used by udev. So, if you did not create any udev rules yourself you should be fine. With old udev and new kernel my rules that map my USB disks to persistent names under /dev were definitely broken. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, Jan 04, 2006 at 12:23:31AM -0200, Felipe Augusto van de Wiel (faw) wrote: > Perhaps the idea of maintain a kernel with other distros is not bad, > if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire, > Xandros, "DCC Alliance Fan Club" and also other Debian Derivatives. I really > don't know if it is possible to mix RH, Debian, SuSE, Slackware and > other distros to maintain the same kernel, but certainly should be possible > to get all Debian (and Debian based/derivative) playing together. :-) Different distros have different target audiences so this may not be easy. Often fixing a driver bug for one class of users breaks it for an other class of users so it is quite possible that different distros want different bugs to be fixed/left alone. Also, other distros (e.g. RedHat) already found out the hard way that diverging too much from upstream costs a lot. So unless you find someone to pay the maintainers of such a forked kernel, it will not work out in the long term. > If you give it a quick look (and a quick try), we will have more > users testing the same kernel, which means more feedback, we will have > more developers working to get it stable and working to get it secure. > Probably even upstream get benefits from this model and sounds like a very > good way to work together, even to try to integrate outside patches and > backporting things. =) Dave Jones (Fedora) and Greg KH (Gentoo) already posted a much better idea on l-k: make packages from daily -git snapshots available for distro testers, so bugs like the past udev breakages are found _before_ the next official kernel version is released. Packaging at least -rc kernels for unstable might be a good idea for Debian too. That would provide more testing coverage for -rc releases, and this is what upstream needs the most. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Tue, Jan 03, 2006 at 10:43:55PM +0100, Julien BLACHE wrote: > I wonder how that's going to happen wrt udev and a couple of other > things that, as of today, depend on a precise version of the kernel. The udev breakages were rather annoying but the situation is not as bad as it looks. ALSA for example is worse but it gets less "press coverage". To avoid such breakages in the future, - test -rc kernels as they come out - complain loudly on linux-kernel if something breaks (just cursing on debian-devel will not help) Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dependencies on makedev
On Wed, Jan 04, 2006 at 11:52:58AM +0100, Josselin Mouette wrote: > Furthermore, udev doesn't bring new problems. You can't have a > persistent naming scheme with a static /dev either, unless you are > loading modules by hand. If you still want to load your modules by hand, > udev won't prevent you from doing so. Even that will not help you if an SCSI/SATA device fails and thus the other devices get renamed. And with the current work to port the old IDE drivers to libata, this may be the issue with practically every disk in the not so distant future. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, Jan 04, 2006 at 02:19:31PM +0100, Steinar H. Gunderson wrote: > udev has broken my system -- completely (as in: can't boot and/or log in) -- > _seven_ distinct times since this summer. How on you can claim that ALSA is > worse, is beyond me :-) That's why I said udev breakage is rather annoying. But according to recent posts on linux-kernel, ALSA broke the kernel-user space ABI much more often, and technically it is worse and harder to fix than a bug in udev (even if it is less annoying because only sound breaks). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, Jan 04, 2006 at 02:26:51PM +0100, Maximilian Attems wrote: > the -rc kernels are build in experimental, staging area for unstable > and without any potential d-i breakage. Ah, nice, I did not notice it. Perhaps it should get some more publicity to attract more testers :-) Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: poppler
On Mon, Jan 09, 2006 at 03:03:07PM +0100, Moritz Muehlenhoff wrote: > I've heard that gpdf is to be replaced by evince in GNOME, which > already links dynamically, so it's probably best to remove it for Etch. While evince is nice it is unfortunately unbearably slow compared to gpdf/gv/acroread with some PDF files, so I personally won't be removing gpdf from my system anytime soon. So if someone has some time to fix gpdf once again, it may still worth it. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: documentation types
Hi,
On Fri, Feb 10, 2006 at 12:09:40PM +0100, Hendrik Sattler wrote:
> Is there any preference on which type should be included in the -dev package?
> I would prefer PDF:
> * one file only
> * easy to print
> * many viewers available
>
> I would rather not build all three as this is a definite waste of disk space.
Well, if they are big enough that the disk space usage is a concern,
then they should definitely be moved to a separate -doc package.
Otherwise, I'd suggest html, because that's the only useful format for
every-day use ('grep' etc. cannot be used on PS/PDF, or just think about
doing development on a text console).
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
Re: update-inetd and xinetd
On Tue, Feb 14, 2006 at 08:37:26AM +1000, Andrew Pollock wrote: > I realise that update-inetd needs to be more flexible than just servicing > xinetd and netkit-inetd style configurations though... What do you mean by "more flexible"? IMHO update-inetd should implement just the minimum needed for package management purposes (adding/removing/enabling/disabling a service). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: documentation types
On Thu, Feb 16, 2006 at 10:04:25AM +0100, Javier Fernández-Sanguino Peńa wrote: > Moreover, I know of *no* -doc packages that provide SGML format so there > is not that much experience (or tools) on how to automatically do what others > suggest (dwww integratin). IMHO SGML is losing ground in favor of XML. GNOME Help files are already DocBook/XML (AFAIK KDE Help also). So there is definitely precedence, and providing soma automatic, user-selectable DocBook/XML -> HTML translation would have meaning for dwww integraton. The other option is to say that GNOME/KDE can already display DocBook/XML without the HTML conversion phase, so allow DocBook/XML as an alternative of HTML in the policy. Maybe this is just wishful thinking. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: documentation types
On Fri, Feb 17, 2006 at 12:57:54AM +0100, Javier Fernández-Sanguino Peńa wrote: > > And if the administrators choice is to not want any automatically created > > formats, he may use a docbook program that displays it from the SGML or XML > > source. Why not, such a tool may exist at one time or maybe does already. > > It does not exist, before going into a useless discussion, show me some code. WTF are you smoking? $ head -3 /usr/share/gnome/help/totem/C/totem.xml http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; [ $ yelp /usr/share/gnome/help/totem/C/totem.xml It works. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: documentation types
On Fri, Feb 17, 2006 at 02:33:47PM +0100, Javier Fernández-Sanguino Peńa wrote: > Show me a *documentation* package (i.e. those that install documentation > under /usr/share/doc/ and use doc-base's install-docs to register > documentation files [1]) that uses that. You are pointing me to a help > browser for a specific environment, GNOME has one, KDE has another one, in > Debian the management interface for system documentation is called doc-base > (includes dwww, dhelp, and doc-central) and it doesn't handle SGML, much less > XML, as far as I know. I do not understand you. The quote you replied to was: > > > > And if the administrators choice is to not want any automatically > > > > created > > > > formats, he may use a docbook program that displays it from the SGML or > > > > XML ^ > > > > source. Why not, such a tool may exist at one time or maybe does > > > > already. ^ You answered: > > > It does not exist, before going into a useless discussion, show me some > > > code. ^ And I told you that you're wrong. There is _zero_ reference to documentation packages, doc-base, install-docs or anything else in the quote you replied to. It only spoke about _displaying_ the documentation. And yes, displaying is the most important step. If there are multiple, well-established viewers for a documentation format (as you have acknowledged), then it makes sense to think about adopting Debian's document handling system for that format. After all, Debian is about serving the users. It's not the users who should bend to what is convinient for Debian. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Sat, Feb 25, 2006 at 05:01:25PM +0100, Michelle Konzack wrote: > If I have a hardware which comes with a CD/DVD/Floppy with the firmware > and there is a free firmware loader but it must stay in contrib it will > not realy productiv. It is a big disavantage. Why? I've been using Debian for quite some time but I've never checked that the package I'm about to install is coming from main or from contrib. Yes, I understand that there are technical/legal reasons for putting packages in contrib instead of main, but with my "dumb user" hat on, I simply _do not care_. I simply can not understand why you all are making such a big fuss about ndiswrapper being in contrib or in main. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd and experimental
On Tue, Feb 28, 2006 at 08:59:46AM +, Brian M. Carlson wrote: > [0] In case you're unsure, you can check the X-Spam-Status header, which > will tell you that I am an LDOSUBSCRIBER, in which case you can assume Just nitpicking: there is no X-Spam-Status: header in my copy; however, there is a X-Qmail-Scanner-MOVED-X-Spam-Status: header instead. And even if somebody founds that and somehow guesses that this is the right header to look at (I have extra headers added by 3 different spam checkers), he/she would probably have still no idea what LDOSUBSCRIBER means. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: dspam in experimental. Please, test.
On Tue, Feb 28, 2006 at 10:20:30AM +0100, Jesus Climent wrote: > For those of you who enjoy to live in the bleeding edge, have loads of free > time or just feel like helping a bit, there is a dspam package in experimental > waiting for your love. Finally :-) Thank you for packaging it! > Please, give it a try and if you find a bug, report it. I'm still running my locally built dspam version but I intend to check out the Debian packages as soon as I'll have some time. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Mon, Feb 27, 2006 at 10:04:59AM -0800, Adam McKenna wrote: > Taking it out of main moves us in the wrong direction if our goal is to > give our users a *usable* operating system, as opposed to some kind of > 'proof of concept' OS that some people here seem to want to create, but > that the majority of our users will not want to use. One point that nobody raised so far: _reliable_ working on ndiswrapper depends on the 16k-stack patch that is not available in Debian AFAIK. Without that patch, drivers requiring ndiswrapper (being free or not) only work by pure chance. So whatever the Depends: line says, ndiswrapper for any practical purposes depends on software that is not in main. So the question is: does a piece of software, that is known not to work reliably and will never work reliably with the (Linux) kernels shipped by Debian, have a place in main? There are efforts from time to time to make the 4K stack the default on i386 upstream; if/when that happens, ndiswrapper will stop working with stock Linux kernels. What will be the answer then? Other distributions like Fedora have already switched to 4K stacks... Gabor p.s. I personally still do not care whether ndiswrapper is in main or in contrib... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Tue, Feb 28, 2006 at 02:36:52PM +0100, Wouter Verhelst wrote: > The CIPE driver doesn't actually need hardware, since it is an > encryption layer. As such, I can use it as a test-case for ndiswrapper, > to find out how the latter works and to actually be able to test whether > I set it up correctly. If a customer should at one point ask me to help > them out with setting up ndiswrapper, I can then first experiment on my > own with the CIPE driver, and then help them out with their non-free > driver. In this case I do not want to hire you as a consultant ever, thank you very much. You should know that Windows gives ~16k stack to network drivers, while current Linux+ndiswrapper only gives ~6k if you are lucky, and ~4k if/when the "4K stacks" option becomes the default. So even if your test case works it _does not_ give any indication that any other non-free driver will also work. A non-free driver that happens to use 10k stack will work perfectly on Windows but will not work on the kernels shipped by Debian at all. > A kernel hacker might be interested in helping out to hack on > ndiswrapper itself, but not be very interested in having their laptop > crash every five minutes by loading experimental versions of the driver. > An obvious solution would be to use a virtualization environment like > qemu, but then you can't use a driver that requires specific hardware. > The fact that CIPE exists, which does not have any hardware > requirements, can allow you to test stuff without having an unstable > computing environment for other things. You are not serious that such a developer would be incapable to locate the ndiswrapper source if it was in contrib instead of main, are you? Also, such a developer would be a fool to use the Debian-packaged version of ndiswrapper instead of the latest upstream snapshot, given the long time between stable Debian releases. > Now consider that there is a change in some future version of the > kernel, which is security-related, and which breaks the kernel API wrt > network drivers incompatibly. Unlikely, whoever breaks in-kernel API is responsible for fixing all in-kernel drivers as well. And IMHO there are more Linux network driver maintainers than ndiswrapper maintainers, and they are quite capable of morphing a huge number of drivers at once. On the other hand, the kernel has already broken compatibility with ndiswrapper (16k stacks were never part of the official kernel) and there is effor to break it even more (if you want to look at it from this angle). Just look up the "4k stack" flamewars in LKML archives. Fedora already ships it's kernels with 4k stacks. Please stop these excuses. "ndiswrapper will remain in main because the sky is blue" is a lot more acceptable reasoning than anything that popped up in this thread so far. If you _really_ want to help ndiswrapper, then work on solving the 4k-stack issue; that would help a _lot_ more than this silly thread. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: 4GB address space
On Tue, Feb 28, 2006 at 05:46:07PM +0100, Wouter Verhelst wrote: [...] > > user applications can use the whole 4GB of virtual address space while the > > kernel runs it's own AS. [...] > > Run "make menuconfig"; then, select "Processor type and features", and > "High Memory Support". Done. The question was not about HIGHMEM but about Ingo Molnar's "4G/4G split" patch, which is not part of the base kernel. HIGHMEM does not let userspace use the whole 4G address space. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd and experimental
On Wed, Mar 01, 2006 at 01:04:17AM +, Brian M. Carlson wrote: > I understand that different mail systems do different things (although I > hope you're not using qmail[0]). Not on my desktop, but I have no control over the institute's central services. > However, the code of conduct seems to > point out that one should not Cc someone unless they specifically ask > for it (a guideline that you neglected to follow, after I pointed this > out to Mr. Bushnell). Frankly, I never check the recipient list when I press "g" in mutt. I assume that if you do not want to be CC'ed, then you can set up Reply-To: to express that. > But since some new or one-time posters may not > realize this (and want to be Cc'd anyway), this provides a heuristic to > guess if someone is actually subscribed, nothing more. Assuming that a new poster will find and decipher the cryptic contents of a non-standard e-mail header (that is even likely to be overwritten if there are several spam filters in the delivery chain) is completely unrealistic. The only sensible default is to assume that if there is a specific requirement for the reply, then the Reply-To: header will be set up accordingly (either automatically, or by the user who has the requirement). > If you are unsure, you could simply not Cc someone unless they ask. The problem is, every project has different requirements for its mailing lists. Right now I'm subscibed to about 20 lists only, but I'm sure as hell can not remember the policy for each of them. So if you'd like people to follow a specific policy, then tell that to their MUA by setting Reply-To:. After all, we have computers to do some work instead of us, not the other way around... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: udev vs ldap at startup
On Fri, Aug 11, 2006 at 02:59:16PM +1000, Brian May wrote: > The second query is trying to find out all the groups root is in (is > it possible to skip this???). Only if you either remove ldap from the groups: line in nsswitch.conf, or you do not use any programs that call initgroups()/getgrent(). A workaround may be to have /etc/nsswitch.conf.files that does not have LDSP entries, bind-mount it over /etc/nsswitch.conf in say /etc/rcS.d/S02blah, and unmount it in /etc/rcS.d/S99blah. This is not a real fix though since udev events can be processed well after rcS is run. The real fix would be to tame libldap2/libnss-ldap. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: udev vs ldap at startup
On Fri, Aug 11, 2006 at 12:56:23PM +0200, Vincent Danjean wrote: > Then, I've been unable to start the userspace. I mean, even > with 'init=/bin/bash' on the kernel cmdline, it did not work > (ie it hung up). Next time try "init=/bin/dash". dash avoids the unneccessary NSS lookups bash performs. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
On Tue, Aug 15, 2006 at 02:26:29PM -0500, Steve Greenland wrote: > And guess what? System tests are actually more reliable, especially > when the user tells you what the system is. You can simply flip to > compiling foo_linux.c or foo_solaris.c and go on your way. 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(). And RHEL _is_ Linux and it is pretty heavily used in corporate environments. So instead of foo_linux.c you need foo_sarge.c, foo_etch.c, foo_rhel.c, foo_opensuse.c and probably a dozen more, which is just plainly unmanageable. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
On Wed, Aug 16, 2006 at 07:11:19PM -0500, Steve Greenland wrote: > So you chose to use a function not reliably available. Sounds like bad > planning to me. More than a year ago the plan was that we'll support Debian Sarge only. Then a couple of weeks ago our project partner said they'll be using RHEL no matter what. So much for planning. > I spend quite a bit of my life working on non-Linux platforms (as well > as a variety of Linux ones). I've built *lots* of free software on these > platforms. My experience is that the ones whose build instructions say > "edit the makefile to pick your platform and compiler" compile and work, > and when they don't, they're easy to fix. The ones that use autoconf > tend to blow up on non-Linux[1], in ways that are hard to debug and damn > near impossible to fix. A couple of years ago I used to be an AIX/Solaris admin and I had quite the opposite experiences. Installing software that used autoconf was generally painless, building the software simultaneously on 3 platforms from a common source (NFS) just worked almost always. On the other hand, sw with custom build systems were always a pain: usually they had no idea how to build a shared lib on AIX, they did not support building outside of the source directory etc. In case of bugs, autoconf helps a _lot_ since you know that every build system looks the same, if you find a bug (like libtool being notoriously broken on AIX) the same bug will be present in every package and the same fix can be applied etc. On the other hand, all custom build systems had their own bugs that required a lot more time to investigate. autoconf/automake/libtool are just like many traditional UNIX tools: they are all sharp knifes which can cut you deep if you use them badly, but can also help a lot if you use them wisely. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: using long long and printf("%m") in debian
On Sat, Aug 19, 2006 at 12:52:17AM +0200, Michael Rasmussen wrote: > Is there any written documentation on debian.org for support of c99 in > the archs supported by debian? Well, even the gcc-4.2 documentation still has the sentence "GCC has incomplete support for this [C99] standard version", so IMHO the formal answer is "no Debian arch has full C99 support with the default compiler". On the other hand, most of the useful features of C99 seem to be supported in current gcc versions, so the real-life answer is more like "you can assume C99 support on all archs". Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
On Fri, Aug 18, 2006 at 01:24:06PM -0500, Steve Greenland wrote: > No sign of what it actually did, no sign of whether the answer was > yes or no. Yes, there is some stuff in there. But not always enough. > Sometimes it spits out what the compile command was, and the code used, > and sometimes it doesn't. If you want more information you can always do "bash -xv ./configure ..." > Hmmm, why is it checking for "string.h" and "limits.h" after it has > already checked for "ANSI C header files"? Because whoever created configure.ac told it to do so? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian ISOs
On Wed, Aug 23, 2006 at 11:30:53AM +0200, Christian Perrier wrote: > I have a few doubts about the knowledge of the average user for > Bittorrent. For sure, having BitTorrent helps reducing the load > because all users that have some know-how with it will use it...but > making it the main distribution mode...ahem.I think that most of > the users will stick to ISO images downloads. Many users do not know what an ISO image is, either. If someone creates a nice frontend with a big button saying "Push me to download & burn the latest Debian CD/DVD", users won't care if it uses bittorrent in the background. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: Linking a static library with -fPIC for flex
On Thu, Sep 07, 2006 at 02:45:50PM -0500, Bill Allombert wrote: > So if you are to write a library that include a flex scanner, all you > have to do is to prvide your own yywrap() function, even if it is > just return 1; and you won't need to link with libfl.a. Why can't flex emit a default yywrap() function as part of the scanner code, marking it __attribute__((weak)) so the app can override it? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: so many applications wake up so often
On Fri, Sep 08, 2006 at 12:36:17PM -0500, John Goerzen wrote: > I have no idea what Gnome, KDE, etc. are doing to my disk -- all I know > is that they seem to have business with it all the time, and it makes it > very difficult for the disk to spin down. FYI, kernel 2.6.17 has support for tracing all block device events from userspace. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
On Sat, Sep 16, 2006 at 06:54:05PM +0200, Andreas Metzler wrote: > The whole thing is grey territory in FHS, but still I tend to think > that sysvinit should somehow preserve the (empty) directory structure > of /var/run through reboots. Definitely. When using chroots, it is not uncommon that some directories containing UNIX-domain sockets (like /var/run/saslauthd, /var/run/mysql, /var/run/postgresql) are bind-mounted to 5-10 different locations. Right now all that information can be kept in one single location: /etc/fstab. Having to edit the init scripts instead would be quite inconvenient. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A plan to get rid of unnecessary package dependencies
On Mon, Sep 25, 2006 at 11:12:49PM -0700, Thomas Bushnell BSG wrote: > Hey. If we have a programmatic way of detecting this cases, why not > just fold that into the shlibdeps program, and be done with it? Note that if a shared object has constructor and/or destructor functions then there is NO WAY to automatically decide if it is needed or not, even if it does not even provide exported symbols. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A plan to get rid of unnecessary package dependencies
On Tue, Sep 26, 2006 at 12:35:35PM +0200, Christian Aichinger wrote: > AIUI the number of libraries using such tricks is minor, so it > is unnerving that we can't use the dh_ method because of that. I > don't see any solution though :-/ You could invent a mechanism to tag a library as "never to remove even if no symbols appear to be referenced". Since this should be quite rare even a single (config?) file listing all problematic libraries would be enough, at least in the beginning. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: A plan to get rid of unnecessary package dependencies
On Wed, Sep 27, 2006 at 02:44:10PM +0200, Christian Aichinger wrote: > The problematic sections seem to be .init and .fini. There are > sections called .ctors and .dtors, but they aren't marked as > executable. .ctors and .dtors contain function pointers that are called by code in the .init/.fini sections (crtbegin.o, crtend.o). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: A plan to get rid of unnecessary package dependencies
On Wed, Sep 27, 2006 at 01:35:12PM -0700, Kevin B. McCarty wrote: > [**] I hope someone out there knows how a library maintainer can > reliably determine this! "Use the Source, Luke." For C, you should examine all functions marked with __attribute__((__constructor__)) or __attribute__((__destructor__)). For C++ you need to check every static object as well. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: apt-findremovable v0.1 (initial release)
On Tue, Oct 03, 2006 at 10:23:21PM +0700, Alexey Feldgendler wrote: > Seems like debfoster does what you need. However, it's considered obsolete > now that aptitude takes care of unused packages. debfoster (2.6-1) unstable; urgency=low * New upstream version, new maintainer team. * Revert deprecation. Closes: #366518. Long live debfoster :-) Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-findremovable v0.1 (initial release)
On Wed, Oct 04, 2006 at 01:07:02PM +0200, Raphael Hertzog wrote: > I would rather appreciate that apt-get and aptitude share the information > of which packages have been explicitely installed and which have been > automatically installed. I often install packages to play with them a little or just to read the man page. 90% of the time I do _not_ want to keep those packages regardless that I have installed them manually. And there are cases when a package is no longer depended on but I still want to keep it. That's why I like debfoster: it asks the question "do you want to keep the package or not", which is orthogonal to how and why it was installed. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: anticipating the upstart migration
On Sun, Oct 08, 2006 at 11:48:44PM +1000, Anthony Towns wrote: > What happens if you lose power between deinstalling sysvinit and unpacking > upstart, eg? Always leave the old version of init available as /sbin/init.old. That way you can get a working system by booting with "init=/sbin/init.old" if something goes wrong. PostgreSQL did a similar trick because upgrading to a new major version needs the binaries of the _previously_ installed version to be able to upgrade the database. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: anticipating the upstart migration
On Sun, Oct 08, 2006 at 10:53:39PM -0300, Henrique de Moraes Holschuh wrote: > No wrappers for the single most critical binary in a Unix system after the > libc. Sorry. Right. How about upstart not providing a /sbin/init binary at all, but instead using an "init=/sbin/upstart" boot parameter? The other binaries are less critical, so they can be diverted, and upstart can fall back to sysvinit-provided binaries if it detects sysvinit is running (a'la module-init-tools, as was already proposed)? update-grub and friends could check the presence & value of the "init=..." boot parameter and could warn the user if he/she is trying to do something stupid. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: anticipating the upstart migration
On Mon, Oct 09, 2006 at 01:44:00AM +0200, Michael Biebl wrote:
> We don't really need the ability to install *multiple* init systems in
> parallel imho
Yes we do, for the same reason we allow multiple kernel images to be
installed simultaneously: if the new one does not work, there should be
a way to boot with the old version to fix things up. Especially if you
want testers. There's no way I'm personally going to try upstart if I
see no easy way ('easy' means adding a kernel parameter in the grub
menu, but definitely no rescue CD or such) to go back to sysvinit in
case the system fails to boot.
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
Re: gids assigned non-deterministically
On Tue, Oct 10, 2006 at 09:36:56AM +0200, Tim Dijkstra wrote: > That is no longer a reality with groups like plugdev, powerdev and > netdev, which users need to be a member of to be able to get the wonders > of automatically mounted usb-sticks, tweakable power management and > whatever comes with the utopia stack. Then use pam_group to temporarily assign those groups to users. That way the gids can be different on every system, and you can even gain performance by having less groups in LDAP. Especially if you have more than a handful of users (and if you are considering LDAP, I assume you have), groups with hudreds or thousands of members can cause headaches. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gids assigned non-deterministically
On Tue, Oct 10, 2006 at 11:33:43AM +0200, Tim Dijkstra wrote: > Hmm, pam_group doesn't sound to secure to me... what if on one machine > gid 110 is www-data and on another plugdev. Then if a user logs in on the > second > machine it will get access to gid 110, make some suid executable, which on > another machine ... This can't happen. Groups are _not_ transferred over remote login. New files are owned by the user's primary group, and _not_ by the supplemental groups (and I really hope you do not want to use 'plugdev' etc. as the primary group for any real user...) Even newgrp does not work with groups granted by pam_group (more precisely, newgrp asks for the group's password, but system groups should be always locked). So I see no way to transfer a locally granted group to another machine. On the other hand, it is true that you should never create files owned by local uids/gids on shared storage. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gids assigned non-deterministically
On Tue, Oct 10, 2006 at 11:15:51AM -0400, Roberto C. Sanchez wrote: > That is fine for a home network. However, on a network of 1000 > workstations, having to specify group memberships on the clients is kind > of a pain. It's not different than having to specify what NFS file systems to mount or where the LDAP server is. If you have 1000 workstations, you do not configure them individually, but either install them from one master image (possibly even every day, like in the case of publicly accessible university machines), or have some central configuration/management system (like Quattor). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: gids assigned non-deterministically
On Tue, Oct 10, 2006 at 03:36:20PM +0200, Tim Dijkstra wrote:
> That's not an argument someone can just 'chown :plugdev' something.
Crap. I knew I'd overlook something. I think you could still prevent
that with SELinux though :-)
On the other hand I was thinking about if in your case basically all
user needs to be a member of all these groups anyway, then there is no
point in having these groups at all. Just make pmount executable by
anyone, and edit /etc/dbus-1/system.d/{avahi-dbus.conf,hal.conf} and
replace '' etc. with '' or with ''.
Similarly, if all users have read(/write) access to a device because all
users are part of the group owning the device node, then you can just
make that device node a+r(/a+w) and forget about the group.
Of course there may be services running under other uids that you do not
want to give all access humans has; it has to be decided.
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-findremovable v0.1 (initial release)
On Sat, Oct 07, 2006 at 06:30:33PM +0200, Michelle Konzack wrote: > If I tell the Maintainer: "I am connecting over ssh2 using keys > to two of my servers in Tehran, I want to install something and > I choose aptitude for better searching, aptitude crashs and kill > the ssh session", he/she will close immediatly the bugreport, > because this NO bugreport. You could check the logs: if sshd is killed, that should be logged. And you can strace sshd from the point you connect to the point it dies, and then you'd know why it died. Or you can start sshd in debugging mode. The thing is, if a crashing app can kill the ssh connection then your system is broken. If you're the sysadmin, then it's _your job_ to find out why. You can ask if you don't know how to debug such a situation, but just complaining instead of doing the work will get you nowhere. > The problem is, that the Servers are in Tehran and I am in > Strasbourg. I do not know how to debug this on distance... man strace. Enable core dumps if they are disabled (e.g. because you've started sshd with 'ulimit -c 0' in effect) and look for core files. Check the logs; if it's OOM, it will be logged, if ssh dies due to a signal it ought to be logged. You can always start a second sshd on a non-standard port if you're afraid of losing connectivity during debugging. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: anticipating the upstart migration
On Tue, Oct 10, 2006 at 05:25:57PM -0400, Eric Dorland wrote: > Shouldn't it be possible to move the alternatives around in an atomic > fashion? ln -sf bar foo.tmp ; mv foo.tmp foo . Or am I missing > something? - If you set up the alternatives in preinst, then there is a time when the symlink exists but the pointed binary hasn't been unpacked yet -> unbootable system. - If you set up the alternatives in postinst, there is a time when there is no /sbin/init at all -> unbootable system. It's not enough to install a single link atomically. Unpacking /sbin/init.upstart AND setting the /sbin/init symlink AND setting the /etc/alternatives/init symlink _together_ would have to be atomic. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Sun, Oct 22, 2006 at 10:48:26PM -0700, Russ Allbery wrote: > I don't think using any non-POSIX feature should be a policy violation, > probably. There are some that are in such widespread use and are > supported by all shells that weren't written specifically as test suites > that I think it's worthwhile making an exception for them. But using > general bash features in /bin/sh scripts really do break real systems. How about instead of speaking about POSIX, policy should just list the shells that are officially supported as /bin/sh? There is no need listing every shell, just a representative subset: bash (obviously), dash (it's popular) and an other "minimalistic" shell (posh?) to prevent allowing everything & the kitchen sink if dash starts to rapidly acquire new features. If a maintainer script does not work with a shell on the list -> serious bug, if it does not work with some other shell -> wishlist bug. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ca-certificates symlinks out of /etc
On Tue, Oct 31, 2006 at 07:10:45PM +0100, martin f krafft wrote: > cat /etc/ssl/certs/cacert-class3.pem >> /etc/ssl/certs/cacert.pem > > on systems that needed access to all of CACert's certificates. Btw., mounting /usr read-only is a good way to prevent stupid bugs like this. You can configure apt to re-mount it r/w when during package install/removal so upgrade/install still works, and that catches 99% of the cases you want to write under /usr. For the other 1% forcing you to think and remount it manually is actually a good thing. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building in a directory named "something:something"
On Thu, Nov 02, 2006 at 11:13:30AM +0100, Goswin von Brederlow wrote: > I'm not sure what to do about it. Should one guard against this? > Should sources use the absolute path instead of relative ones? Ideas > are welcome. I think yes. Having ':' in the file name is no different than having ' ' in the file name (at least as far as make is concerned) and requires the same escaping. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ca-certificates symlinks out of /etc
On Thu, Nov 02, 2006 at 12:01:12PM +0100, martin f krafft wrote: > Anyway, thanks for the discussion. I don't think I heard a single > argument for using symlinks, other than to save 440k of space in > /etc. Symlinks just make _sense_. It's the idiocy of other OSes to duplicate data because they have no proper notion of symlinks. I always hate arguments like this to "make things worse for people who know UNIX because there are some dumb users who don't". So, here is a constructive solution for those who do not like symlinks in /etc: - Rebuild OpenSSL with X509_CERT_DIR in crypto/cryptlib.h defined as "/etc/ssl/certs:/var/ssl/certs". I did not test it, but looking at the OpenSSL sources It Should Just Work. - Change ca-certificates to create the symlinks in /var/ssl/certs instead in /etc/ssl/certs, and make it clear that the user should not manually alter the contents of /var/ssl/certs or else he/she should keep both pieces when something breaks. - Declare /etc/ssl/certs to be the playground of the local sysadmin. No package should touch anything inside it. That gives you the best of both wolds with minimal efforts. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: ca-certificates symlinks out of /etc
On Thu, Nov 02, 2006 at 02:24:33PM +0100, martin f krafft wrote: > Why do the files need to be in /usr/share at all? Why not provide > /etc/ssl/certs and /etc/ssl/certs/disabled and let the user use > /bin/mv to enable/disable them. Certificates are not configuration files so they should not be in /etc. On the other hand, the decision of which certificate files should be USED _is_ a configuration decision, so that information should be under /etc. So the current way of the certificates being under /usr/share and symlinks to them being in /etc matches the intended (and expected) usage of both /etc and /usr/share perfectly. > At the same time, the debconf > question about which ones to disable/enable could do exactly the > same, and all the files would be proper configuration files that > could be edited all the same. The whole point of a certificate is that you CAN NOT edit it because that would break the signature. You can only replace a certificate as a whole, add a new one or delete an old one. Therefore it does not make sense to list certificates as conffiles. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Sat, Nov 11, 2006 at 11:10:52PM -0600, Manoj Srivastava wrote: > Why don't we do that? Because people wanted to have a > different shell that can serve as /bin/sh. What purpose does it > serve to allow that? We can't, in all honesty, say that any disk > space is conserved, since bash is essential, it is too deeply rooted > in all places in our system to be casually ripped out. There is a very simple reason: people want to be able to unmount /usr cleanly on shutdown, without risking file system corruption. If you require /bin/sh to be bash, then the only way to achieve this is to move all the dependencies of the various libnss-* packages from /usr/lib to /lib. That would currently mean libraries of LDAP, PostgreSQL and MySQL with their dependencies (OpenSSL, GnuTLS, Cyrus SASL and Kerberos at least, I'm not sure I cathced all). Forcing /bin/sh to be bash would imply a grave bug for all these packages. Also, if in the future someone starts using dynamically loadable bash builtins in maintainer scripts (if /bin/sh is required to be bash, then that suddenly becomes allowed too) then maintainer script debugging may become quite "interesting" when the seemingly same command starts to mean completely different things in different scripts... > It is my opinion that we would be better off dumping this > whole shell specification thing in policy, standardizing on bash, and > let it go. If you want to standardize on one shell, that should not be bash. bash is just hopelessly bloated. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Sat, Nov 11, 2006 at 11:10:52PM -0600, Manoj Srivastava wrote: > It would, at one fell swoop, solve the problem Thomas hinted > at before, about our specification allowing shell to randomly shadow > other commands on the system. (I missed this part in my previous mail) Using /bin/bash does _NOT_ solve this problem as bash allows you to dynamically enable, disable and re-define the built-in commands. Even worse, bash allows you to load a DSO and use it as a built-in command. Just imagine if some maintainer scripts start to supersede ls, sed, awk etc. this way... And if you want do disallow the problematic features, then policy quickly becomes much more complex than just saying "all maintainer scripts must also work with dash". So again I propose that instead of listing features, policy should just say "maintainer scripts must work with bash, dash [and probably a 3rd alternative]". And if someone wants to use a shell not on this list as /bin/sh, then he is on his own and if something breaks then that's at most a wishlist bug. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Tue, Nov 14, 2006 at 12:03:06PM -0600, Manoj Srivastava wrote: > What problem exactly are you trying to solve? We have a > working OS now, and have had one for over a decade; and we have been > using bash all along. Reading what you say leads one to imagine all > kinds of dire prolems that would be the case if one were to use > bash -- but we have been using bash for all this while. > > So again? What is the problem you see make bash unacceptable > here? It's not bash that is unacceptable. It's restricting Debian to bash _only_ that is unacceptable. You mentioned different shells shadowing different utilities. But thanks to the "enable" command, that's true for two bash scripts as well - looking at an "if test ... then ..." construct in a #!/bin/bash script you never know whether that "test" command will invoke the bash builtin or the external /bin/test utility without deeper analysis of the script. On the other hand, for a #!/bin/sh script you know that you only have to check the /bin/sh symlink to decide what "test" means. Right now configure scripts can be speeded up by making /bin/sh point to something other than bash. If you mandate /bin/sh to always be bash, then it suddenly becomes a valid optimization to turn cat, sed, rm, grep etc. into bash builtins thus cutting down the number of fork()/execve() calls by about 60-70% (for just this 4 commands alone) - you just need a patched autoconf that inserts the appropriate "enable" commands at the beginning of the configure script. But that means command shadowing becomes worse and harder to diagnose than enabling different shells as /bin/sh. There are probably a lot of other areas where such tricks could be used. Thanks to the "enable" command, you can even turn bash into a (much more bloated) busybox. I say that restricting /bin/sh to just one possible value does not solve the complexities of having different shells as /bin/sh. You just trade a well-known (and already handled) complexity for a much-less-known complexity. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Wed, Nov 15, 2006 at 09:44:09AM +0100, Eduard Bloch wrote: > Where is your argument? Manoj asks you about facts and you answer with > "can break". Everything can break if the local admin _wants_ th shoot > herself in the food. I'm not talking about the local admin. Right now Debian maintainer scripts are not allowed to use the "enable" command because that is a bashism, and more importantly there is _no reason_ to use the "enable" command because simply saying "make /bin/sh point to dash if you want to go faster" is much more effective and easier. What I'm saying is if you take away the freedom of allowing /bin/sh to point to dash, then people who care about shell performance will be forced to use other means _even in scripts shipped by Debian_ - and the "enable" command is a very powerful tool to achieve that. And at that moment you will have exactly the same "builtins aliasing different external commands in different scripts" problem as you have now when allowing different shells - so you gain nothing by restricting /bin/sh to bash. > Following your argumentation, I would assume that we all have to switch > to "trusted" (restricted) hardware and non-free OSes. Why? Because a hex > editor could be used to modify the behaviour of every program with > a sufficient level of idioticy. I fail to see how that relates to what I have written... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Tue, Nov 14, 2006 at 06:37:33PM -0800, Thomas Bushnell BSG wrote: > I'm a little confused. When I use "test -a", I'm not using a "bash > feature"; I'm using a *test* feature, supported by /usr/bin/test for as > long as it's existed, IIRC. [Little OT] Minor historical detail if someone is interested: 'test' in coreutils comes from sh-utils, and sh-utils changelog has this entry: Sun Aug 11 18:10:30 1991 David J. MacKenzie (djm at wookumz.gnu.ai.mit.edu) [...] * test.c: New file, from bash. So you in fact _are_ using a bash feature, and there was a time when /usr/bin/test did not even exist (but hey, neither did Debian :-) But this is not really relevant in the current discussion. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Tue, Nov 14, 2006 at 06:13:34PM -0800, Thomas Bushnell BSG wrote: > I do. Debian test is provided by the coreutils package. As the man > page says: > >( EXPRESSION ) > EXPRESSION is true > > And, we have the existing rule in section 10.1 of the policy manual: > > "Two different packages must not install programs with different > functionality but with the same filenames." By that definition bash is _ALSO_ broken because according to the man page the coreutils test command does not support unary -a, -N, and == and therefore provides different functionality than the bash builtin. By your reading, 'ktelnet' is not allowed to be installed as 'telnet' because netkit-telnet does not allow you to request encryption. Care to file bugs against the Kerberos packages to stop providing the telnet, rsh, rcp etc. alternatives? If you revert to the (IMHO much saner) interpretation of "different _general_ functionality but still allowing extra command line arguments not present in the other package", then dash suddenly becomes fine since the "test" builtin provides the same generic functionality as the coreutils "test" command (namely, evaluate logical expressions), just the coreutils test happens to support some extra command-line options that the dash builtin does not have. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Tue, Nov 14, 2006 at 09:36:36PM -0800, Thomas Bushnell BSG wrote: > Why? Surely it would be useful to know what the differences are between > various shells. The statement "Posix-compatible" was apparently > intended by the authors of that part of the Policy Manual to do that > work for us, but it doesn't. That doesn't mean the work is valueless. POSIX (SUSv3) + -a/-o + local was such a statement, and you started arguing because it did not contain your favorite-of-the-day feature. You fail to realize that any such statement _WILL_ restrict the set of allowed features because that is the _purpose_ of such a statement. And yes, the world moves and sometimes the limits should be extended - that's happening right now. But that does not mean that suddenly everything-and-the-kithcen-sink that some particular implementation supports should be allowed. And it is also _fine_ if GNU coreutils supports more than required by the policy; just make sure you explicitely write "/usr/bin/test" if you want to rely on such a feature. > If you think that we can just assume that all existing shells do nothing > bad in this regard, it should be about five minutes work to find out > what all their builtins are and form the union of that set. That changes whenever a new version of a shell is released, so the only possible way to do this is to drop the feature-based requirements and use an "it must work with shells x, y and z" approach. That way the users of those shells would report any discrepancies as bugs, just as they do now for bashisms. And yes, "x, y and z" has to be selected carefully not to create many new bugs, but that I think is doable. Also, listing "all existing shells" would be insane, since many of them have specific goals and are simply not designed to be able to be used as /bin/sh (just think about tcsh - it is an existing shell too). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#398793: [Adduser-devel] Bug#398793: adduser: Non system wide readable (home) directories should not be 751
On Fri, Nov 17, 2006 at 07:43:20AM +0100, Olaf van der Spek wrote: > I guess that depends on what a user's definition of a directory being > readable means. There is just one definition for that: whether open(..., O_RDONLY|O_DIRECTORY) succeeds or not. > And it sounds a lot like security by obscurity. No, you just need a basic understanding of UNIX permissions to make use of it. > Yes, do you think 750 or 751 should be used? Depends on what do you want to achieve. The debconf question is only shown to the sysadmin, and if the sysadmin has no idea of UNIX permissions, then he/she should better not manage a multi-user system... > Consider the case where a user wants an easy way to ensure that none of > the files in his home directory are world-readable. The easy way is "chmod -R o-r $HOME". If you really-really want to accomodate dumb users who has no idea of UNIX permissions, then - move public_html out of /home (we used a /public hierarchy mirroring the layout of /home) - run a cron script every couple of minutes that unconditionally changes home directories to mode 750 (well, we used 700), and their /public counterparts to mode 755 - put a symlink under $HOME when the account is created that points to the appropriate place under /public for user convenience - modify the daemons you'd like to access user data to use /public instead of /home And yes, you _do_ need that cron script that often otherwise some dumb users just change the permissions (usual explanation "they saw a chmod command on the web and tried it" without knowing what it does) and then complain loudly that their home directories "mysteriously" became readable or their web pages "mysteriously" stopped working. On the other hand, power users quickly got accustomed to using ACLs when they wanted to make their home directories visible by just their friends only or they wanted public_html only accessible through the web but not through the filesystem (think passowrd-protected files). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#398793: [Adduser-devel] Bug#398793: adduser: Non system wide readable (home) directories should not be 751
On Fri, Nov 17, 2006 at 01:11:26PM +0100, Olaf van der Spek wrote: > Sounds like the wrong definition. There is no choice as it is enforced by the kernel: if you can open() the directory, then you can list its contents, otherwise not. > So what is the purpose of using 751 (besides security through obscurity)? This is "security through obscurity" to exactly the same degree as password authentication is. Sure, you can send the rest of your life trying to find out what files exist in the directory by trying every possible strings as a file name, but that is essentially the same as mounting a brute-force password guessing attack against say an LDAP server. This threat model is well understood and if you care about it then simply monitoring CPU usage and I/O activity will quickly reveal the offending user. Using the kernel's auditing framework AFAIK it would not be difficult to write a tool that automatically checks for this kind of abuse. > Is a Debian system required to use Apache with user dirs? No, why would it? On the other hand, what do you mean by "user dirs" - mod_userdir or something else? For example we used an external mapping program with mod_rewrite instead of mod_userdir. > That doesn't sound right either. > With PHP you can easily read those files from another user/vhost if > they're world-readable. I thought that mentioning ACLs would make it clear that the files are no longer world readable, they are readable only for a very limited set of users. If you allow users to have unchecked PHP scripts running under the web server's user ID on a real multi-user system then you're welcome to shoot yourself in the foot. If you allow different vhosts to run untrusted PHP files under the same user ID then you're welcome to shoot yourself in the other foot. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
On Sat, Nov 25, 2006 at 10:22:06AM -0800, Thomas Bushnell BSG wrote: > This is an excellent example of doing the wrong thing, in my opinion. > > Why not fix the bash bug instead?? Because it is _NOT_ a bug in bash, it is a feature. AFAIR (it was some time ago I've looked at the code trying to fix this issue) bash guarantees some environment variables to always exist and to have a certain (initial) value, and that requires calls to the NSS functions. Removing support for the affected environment variables would fix the issue, but would break existing #!/bin/bash scripts depending on those variables. And I'm talking about user-written scripts, not Debian-provided scripts. This is a perfect example when none of the components involved can be considered as bogus, it is their interaction that causes the problem. One component (bash in this case) wants to do more than it would be required for its role, and that causes a side-effect that makes the other components break. The good old UNIX slogan "do just one thing, but do that well" was invented for a reason... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
On Fri, Nov 24, 2006 at 02:03:54PM -0800, Thomas Bushnell BSG wrote: > And around and around we go. Dash itself say it is not suitable for > interactive use, and, bash is an Essential part of Debian. Care to point me where dash says it is not suitable for interactive use? the _Debian package_ description only says that bash is probably better, and "man dash" has a sentence: "It incorporates many features to aid interactive use [...]". Btw. why not just make a clear distinction between the "default shell meant for executing system scripts" and the "default shell meant for interactive use"? If scripts use /bin/sh, /bin/sh points to dash, but adduser always sets /bin/bash as the shell for non-system user accounts by default, then everyone should be happy. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: Ondemand governor by default in etch
On Thu, Dec 07, 2006 at 09:36:29AM -0600, John Goerzen wrote: > I believe that we should enable CPU frequency scaling, and the ondemand > governer, by default in etch. I did not follow the cpufreq issues closely, but by reading the linux-kernel list in the last couple of months I had the impression that the locking rules of cpufreq vs. CPU hotplug are a real mess. There were some attempts to fix them, but they are not part of kernel 2.6.18. Since CPU hotplug is needed for suspending on SMP systems (think HT-capable and dual-core CPUs), I wonder how safe it would be to enable cpufreq by default this close to the release. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ondemand governor by default in etch
On Fri, Dec 08, 2006 at 06:31:55PM -0500, Anthony DeRobertis wrote: > OTOH, it works absolutely great on AMD64 chips. Not for me: powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3200+ processors (version 2.00.00) ACPI Exception (acpi_processor-0237): AE_NOT_FOUND, Evaluating _PSS [20060707] powernow-k8: BIOS error - no PSB or ACPI _PSS objects Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible grave bug in debian-installer or ifupdown?
On Mon, Dec 18, 2006 at 09:23:13AM +0100, Bastian Venthur wrote: > But who has created the allow-hotplug-line? I thought hotplug is dead? Doesn't matter, udev handles "allow-hotplug" interfaces just fine, I use it on several machines. But the last time I used the Etch installer was around May... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible grave bug in debian-installer or ifupdown?
On Mon, Dec 18, 2006 at 06:36:49PM -0500, Jim Crilly wrote:
> I would agree, when I did an install of etch a few weeks ago the use of
> allow-hotplug caused the network to come up later in the boot process and
> caused problems with syslog-ng remote logging. Apparently when syslog-ng
> can't connect to one of it's destinations on startup it fails completely,
> this is probably a bug in syslog-ng but it's definitely been exacerbated by
> the default ifupdown configuration in etch.
Yes, that's a can of worms that will have to be dealt with in the
future. Basically any network service that supports binding to just one
specific IP address needs to use /etc/network/if-{up,down}.d or similar
mechanisms.
Probably we'll need a mechanism saying that "service X depends on hw
devices Y and Z, so X should be started if and when Y and Z are both
available".
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: localisation in system wide daemons
On Fri, Dec 22, 2006 at 09:37:35AM +0100, Javier Fernández-Sanguino Peńa wrote: > In any case, it would not be too difficult to adjust programas that parse > logs to be able to parse translated messages. Take in account that all > translated text messages would be available in a message catalog (typically a > PO file). Well, if you already have all messages in a catalog, why don't you translate the logs on the _viewing_ side? - No need to bloat the daemon's code - No need to fear from fresh new locale-related bugs in a lot of programs running as root - You do not loose searchability via Google - If you fire the previous sysadmin who likes to read log files in some arcane language you still have a chance the next admin can read the logs too - In case of network-related messages, you may simply have no other option since the real error message is generated by a remote process you have no control over Btw. googleability IMHO is quite an important reason: most of the time if you encounter a cryptic log message the best option is to cut&paste it into a google search and look at the results. With localized log messages that would never work so you take away the chance from the poor sysadmin to find out the meaning of the message. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: localisation in system wide daemons
On Fri, Dec 22, 2006 at 09:37:35AM +0100, Javier Fernández-Sanguino Peńa wrote: > b.- be able to read the non-english logfiles, Btw.: you rarely _read_ logfiles, because most of the time they are just too terse (unless you already know what they mean, but then it is no longer important what language do they use). What you do instead is looking up the message in the documentation (or in Google), and reading the description _there_. Localized log messages make this a lot harder to do. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: localisation in system wide daemons
On Sun, Dec 31, 2006 at 12:15:27PM +0100, Marc Haber wrote: > I have received some bug reports which contain logs from a non-english > locale, but in the cases that I have not been able to figure it out I > have asked the submitter to retry with LANG=C. > > Actually no big deal here. If the log message talks about some data corruption and the user wants to ask how to salvage the data then answering "please reproduce the exact corruption on an English-speaking system" sounds problematic... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: for those who care about GNOME^w glib applications.
On Wed, Mar 22, 2006 at 11:29:01AM -0300, Gustavo Franco wrote: > FYI, GMemChunk (old and deprecated by the upstream) was reimplemented to > use GSlice, so no need to change or rebuild code to be affected due to buggy > code. I don't know exactly why asking GSlice to force allocate and free memory > through "standard malloc" solves the problem, maybe someone else can > clarify this point. Because those applications are abusing the API and make assumptions about how some pieces of memory were allocated. More specifically, they think that they can call g_free() (or equivalent) directly instead of the appropriate API function. With the introduction of GSlice that is no longer the case. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#357703: udev breaks syslog
On Tue, Mar 28, 2006 at 12:57:24PM +0200, Marco d'Itri wrote: > Does anybody have an opinion about this? > When udev is installed for the first time on a running system the > current /dev/log socket ends up in /dev/.static/ (which is not > world-readable) until the next reboot. How about restarting syslog (or it's equivalent) after relocating the old /dev? glibc already has infrastructure for restarting services on upgrade, maybe udev can borrow that. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences -
Re: Bug#357703: udev breaks syslog
On Tue, Mar 28, 2006 at 06:15:27PM +0200, Marco d'Itri wrote: > Harder than it looks. There are multiple syslog daemons, how can the > package know which one is installed and needs to be restarted? glibc already checks for more than 40 packages and restarts only those that are installed. I doubt there are that many packages that needs a restart on udev install/upgrade. It's true that it is not a clean solution that udev needs to keep track of the packages that should be restarted, but this method works now while a more sophisticated method needs someone to design & implement it. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: System users that receive mail in /var/mail/systemuser?
On Mon, Apr 10, 2006 at 11:16:06AM +0200, Wouter Verhelst wrote: > * System users on a Debian system are created with the --system > argument. On reading the manpage, these users are called "system > users", not "Debian system users"; so non-Debian software could very > well be using that by using the documented API. Yep, we're doing that here, and those usesrs should definitely receive e-mail. Most of the time the mail is redirected using .forward but not always, but in all cases it must be configurable at the user level without any extra privileges, so playing with /etc/aliases is out of question. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
