Re: openresolv vs. resolvconf
Thomas Hood jdth...@gmail.com wrote:
I am interested in how openresolv stacks up against resolvconf.
...
What further pros and cons do people see out there?
Mh, having a quick glimpse at openresolv I doubt it is the drop-in
replacement for resolvconf that it suggests to be (Provides/Conflicts:
resolvconf). At least the current package doesn't seem to execute the
hooks in /etc/resolvconf/update{,-libc}.d
regards
Mario
--
Wine is fine, but wiskey is quicker. Suicide is slow with liquor.
-- Ozzy Osbourne
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/slrnifceo4.9qh.mario.ho...@darkside.dyn.samba-tng.org
Re: Bug#603767: gdm: starts on v8 instead of vt7
On Thu, Nov 18, 2010 at 11:41:37AM +1100, dave b wrote: So what's kind of why i asked about how you were trying to find the bug. Don't tell me to search through lots of C code point it out! I don't have time for that and you seemed to know more! Please calm down and don't shout at me. I'm not willing to be treated this way. I don't have time for that. I never told you to search through lots of C code, neither do I know more. Besides my ability to successfully reproduce this on 2 systems with different hardware all I have are dark memories and wild guesses. I know the issue exists, I know it's nothing really new, and I know that all I have to do to work around it is to avoid GDM restarts. I never tried really hard to track it down, I just never wanted to spend the time it would take. This thread showed up on debian-devel@ and I just added my 2 cents in the hope that somebody probably could gain some ideas from it. Regarding the wild guesses: I personally somehow believe that any of the Gnome daemons transparently started in the background of Gnome applications causes this permanent VT allocation. As I said - it's nothing more than a wild guess - a gut instinct if you like. I cannot prove it. Of course, I already tried to find processes lingering around after stopping GDM - with no success. An idea to trace this down would be to track the processes which increase/decrease the tty usage count in the kernel. I have no idea if this is already possible with the current kernel infrastructure or how, but I'd be willing to run patched kernels to track it. We so then the question is what happens if it is 'busy' and we attempt to use it anyways ;) ? I don't think this should be the way to choose. I would personally prefer solving the cause over working around the result. regards Mario -- If you think technology can solve your problems you don't understand technology and you don't understand your problems. -- Bruce Schneier signature.asc Description: Digital signature
Re: Bug#603767: gdm: starts on v8 instead of vt7
Salvo Tomaselli tipos...@tiscali.it wrote: Well, to me, it does indeed appear to be a GDM bug: I can not reproduce this permanent VT allocation with either KDM, XDM or startx. The issue It happens to me with kdm. Before or after you logged in to a session? Is it reproducible for you by just restarting kdm without being logged in through it before? regards Mario -- Sique Huch? 802.1q? Was sucht das denn hier? Wie kommt das ans TAGgeslicht? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrniea6dd.9qh.mario.ho...@darkside.dyn.samba-tng.org
Re: Bug#603767: gdm: starts on v8 instead of vt7
On Wed, Nov 17, 2010 at 09:36:14AM +0100, Josselin Mouette wrote: Le mercredi 17 novembre 2010 à 13:47 +1100, david b a écrit : After upgrading from lenny to squeeze, gdm starts on vt8 always (even after restarting it). It should start on vt7 as this is the expected I noticed this happens often to me too, and I can assure you it???s not a GDM bug. The Linux VT interface wrongly reports vt7 as being in use, before gdm is even started. Well, to me, it does indeed appear to be a GDM bug: I can not reproduce this permanent VT allocation with either KDM, XDM or startx. The issue does only show up with GDM. And it does never show up when starting GDM the first time after boot, GDM needs to be stopped and started again for the issue to show up here on my systems. It does not happen on all systems, so it might be related to KMS - for example it happens with my radeon-based Which graphics hardware are you using? I can reproduce this on Intel graphics (KMS) and VIA Chrome graphics (no KMS, afaik). regards Mario -- The secret that the NSA could read the Iranian secrets was more important than any specific Iranian secrets that the NSA could read. -- Bruce Schneier signature.asc Description: Digital signature
Re: Bug#603767: gdm: starts on v8 instead of vt7
On Wed, Nov 17, 2010 at 06:01:53PM +0100, Josselin Mouette wrote: Le mercredi 17 novembre 2010 à 17:15 +0100, Mario 'BitKoenig' Holbe a écrit : Well, to me, it does indeed appear to be a GDM bug: I can not reproduce this permanent VT allocation with either KDM, XDM or startx. The issue does only show up with GDM. And it does never show up when starting GDM the first time after boot, GDM needs to be stopped and started again for the issue to show up here on my systems. Try the attached C code, it will show you what the kernel says, which is what GDM bases its decisions upon. Well, as I already said in my previous mail (using deallocvt there), it says busy... I started on a fresh booted system, GDM running (on vt7), switched back to vt1 and logged in as root: r...@darkside:~# deallocvt 7 VT_DISALLOCATE: Device or resource busy deallocvt: could not deallocate console 7 r...@darkside:~# /tmp/vtmap tty1 busy tty2 busy tty3 busy tty4 busy tty5 busy tty6 busy tty7 busy tty8 free tty9 free tty10 free tty11 free r...@darkside:~# /etc/init.d/gdm3 stop Stopping GNOME Display Manager: gdm3. r...@darkside:~# /tmp/vtmap tty1 busy tty2 busy tty3 busy tty4 busy tty5 busy tty6 busy tty7 busy tty8 free tty9 free tty10 free tty11 free r...@darkside:~# deallocvt 7 VT_DISALLOCATE: Device or resource busy deallocvt: could not deallocate console 7 r...@darkside:~# Before stopping GDM, tty7 is busy as expected. After stopping GDM, tty7 is still busy. The VT allocation code has not changed a single bit in gdm between the lenny and squeeze versions. In gdm3 a very similar code is used, which is why both behave the same in squeeze. Well, it's probably not a direct GDM bug but some bug in the Gnome backend? I believe to remember for such permanent VT allocation a while ago when I didn't use any display manager at all (but startx and FVWM as window manager) triggered by running some Gnome application(s). I just cannot currently find such an application that would trigger it. regards Mario -- It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories instead of theories to suit facts. -- Sherlock Holmes by Arthur Conan Doyle signature.asc Description: Digital signature
Re: why are there /bin and /usr/bin...
Simon McVittie s...@debian.org wrote: The FHS says mkfs.* have to be on the root filesystem. I'm not entirely clear why this is. Well, I personally believe this holds for at least two of the purposes listed in FHS Chapter 3: * To enable recovery and/or repair of a system * To restore a system To recover a damaged filesystem you need to be able to create a new one: either to copy files away from the (partially) damaged filesystem - i.e. recovery, or to restore a backup to it. Btw... the FHS says: The following files, or symbolic links to files, must be in /sbin if the corresponding subsystem is installed: ... mkfs.* Command to build a specific filesystem (optional) Is the following worth submitting a bug then or does this conform to the symbolic link clause? /sbin/mkfs.ntfs - /usr/sbin/mkntfs regards Mario -- Do I contradict myself? Very well, then I contradict myself, I am large, I contain multitudes. -- Walt Whitman -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrni62ddc.7r9.mario.ho...@darkside.dyn.samba-tng.org
Re: Advanced Startup/Shutdown with Multilayered Block Devices and Related Issues
Goswin von Brederlow goswin-...@web.de wrote: There is one big problem with an event based startup. Specifically for raid1/4/5/6 devices. Those you can use just fine with missing devices but the boot should really wait for all device to be present. Well, this problem arises with non-event-based startup as well. I don't know how lvm deals with this but md keeps track of missing component devices (mdadm -E /dev/component reveals faulty removed slots) and defaults to refuse starting arrays when components are unexpectedly missing. Debian's mdadm package, for example, insists on running such arrays in the intiramfs code (i.e. takes precedence for a running system w.r.t. required arrays) but doesn't do so in its normal init-script (i.e. takes precedence for safe arrays if they are not required to boot the system). Furthermore, mdadm ships Incremental Assembly for a while now. Of course, this doesn't solve such issues automagically but makes it way more easy to deal with them. regards Mario -- If you think technology can solve your problems you don't understand technology and you don't understand your problems. -- Bruce Schneier -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrni33lp1.mgo.mario.ho...@darkside.dyn.samba-tng.org
Re: Let's write a system admin friendly mail server packaging system
Thomas Goirand tho...@goirand.fr wrote: Mario 'BitKoenig' Holbe wrote: Thomas Goirand tho...@goirand.fr wrote: Mario 'BitKoenig' Holbe wrote: So far this is independent of third packages which is IMHO fine and desirable. So far, this could be solved by a postfix-conf.d-snippet shipped with the amavis package. Quite not. You also need to configure the incoming and outgoing ports of amavis the correct way. Which of course will also be done by the amavis package itself. Still, no dependency on third packages so far. I think you quite don't get it. Here's 3 configuration: - postfix with dkimproxy dkimproxy listens on localhost:10121, and ships a postfix-conf.d-snippet which instructs postfix to send mail to localhost:10121 and receive it back on localhost:10122. - postfix with amavis amavis listens on localhost:10211, and ships a postfix-conf.d-snippet which instructs postfix to send mail to localhost:10211 and receive it back on localhost:10212. - postfix with dkimproxy + amavis Bot postfix-conf.d-snippets are concatenated, that's it. postfix ships to localhost:10121 first, gets it back on 10122, ships it to localhost:10211, gets it back on 10212, and delivers it. Everything that package-maintainers had to do is to make sure their port-pairs don't collide with other packages - and to agree on some useful conf.d-snippet ordering, of course. As I said, I don't know if this would be possible with current postfix at all even if we'd implement conf.d-snippets on our own. sendmail milters can be and are combined that way, one just have to make sure to merge the milter-macro definitions correctly. Cleaner for using it, of course not for the packaging. There's no reason why you should load postfix more, and have the message go 3 times by it, if it can go there only twice. That's exactly the small performance drop as price paid for a straight and clean configuration. regards Mario -- There are 10 types of people in the world: Those who understand binary, and those who don't... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrni06nfi.m0q.mario.ho...@darkside.dyn.samba-tng.org
Re: Let's write a system admin friendly mail server packaging system
Thomas Goirand tho...@goirand.fr wrote: Mario 'BitKoenig' Holbe wrote: So far this is independent of third packages which is IMHO fine and desirable. So far, this could be solved by a postfix-conf.d-snippet shipped with the amavis package. Quite not. You also need to configure the incoming and outgoing ports of amavis the correct way. Which of course will also be done by the amavis package itself. Still, no dependency on third packages so far. * postfix ships to amavis * amavis ships back to postfix * postfix ships to dkimproxy * dkimproxy ships back to postfix No, it's not any cleaner, and it's slower. As I wrote previously, we Cleaner from a dependency-perspective. Why isn't it? This way you are able to configure the whole integration within one package (i.e. amavis ships the amavis-postfix integration, dkimproxy ships the dkimproxy-postfix integration, etc. pp), you can just avoid any complex chaining-magic. And slower? What are we talking about? Whole two percent? Are you trying to say that we shall ship a not performing configuration by default, because big ISP are capable of reconfiguring? If you are, I'm trying to say that I would prefer a straight, clean dependency- minimizing approach over one that does and/or requires complex magic. And I'm aware that clean approaches are usually somewhat less performant than optimized setups, which, in turn, tend to be more complex. And I think that a clean and simple approach would help more users than one that tries to squeeze the last cpu cycles out of your system for the price of being hard to understand. Don't get me wrong: I totally agree with you that what we have now is neither the one nor the other. And yes, I think that somebody who tries to optimize a system for highest performance will write his own configurations anyways. Hey, if you really like to squeeze cpu cycles the first thing you do is to build architecture-specific binaries. Writing some optimized config- files doesn't matter then anymore. I think we shall try to release the best distribution as we can, with correct, performing values by default, and even, if possible, have a default configuration that you never even need to edit, because it's just right by default. We should at least have this goal in mind, those goals - you named three: correctness, performance and useful defaults. Choose two of them :) There are way more btw. - not only for users but also for maintainers, etc. Maybe I'm being too idealistic here. What's your opinion? I don't think it's bad to be idealistic. We just have different ideals probably :) Well, most likely we just weigh conflicting goals different. regards Mario -- Um mit einem Mann gluecklich zu werden, muss man ihn sehr gut verstehen und ihn ein bisschen lieben. Um mit einer Frau gluecklich zu werden, muss man sie sehr lieben und darf erst gar nicht versuchen, sie zu verstehen. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnhvurj0.m0q.mario.ho...@darkside.dyn.samba-tng.org
Re: Let's write a system admin friendly mail server packaging system
Thomas Goirand tho...@goirand.fr wrote: Mario 'BitKoenig' Holbe wrote: Why would you like to go another way with mail servers? Because upstream doesn't want a conf.d folder, unfortunately, and that Well, you can have something equal without upstream support by concatenating conf.d snippets into one huge conf-file, like modutils did (Andreas did describe this for exim already), and today we can also trigger this on package upgrades. If you setup postfix + amavis, then postfix must relay emails to the incoming port of amavis, and amavis got to give the email back to postfix on another port. Both postfix and amavis have to be configured so they can talk to each other. So far this is independent of third packages which is IMHO fine and desirable. So far, this could be solved by a postfix-conf.d-snippet shipped with the amavis package. Now, add dkimproxy in the loop. You have to configure dkimproxy to receive from postfix, relay to amavis, and amavis forwards to postfix. That's pain, indeed, and should IMHO be avoided at all. A clean way to conf this would be * postfix ships to amavis * amavis ships back to postfix * postfix ships to dkimproxy * dkimproxy ships back to postfix I don't know if this is possible with postfix yet. The sendmail milter approach is way cleaner regarding such stuff. This is a LOT less trivial than what you pretend. That's not just less trivial, it's horrible :) And this is probably one of the reasons why newer amavis is now able to perform DKIM signing on it's own. So, this specific chaining should be historic sooner or later. Do you have another example where such a chaining is unavoidable? OF COURSE we do care about the performances of a mail server. Some ISP are running servers that are managing 100s of thousands of mail a day. And of course they use distribution-default configured mail servers for that :) scnr. regards Mario -- () Ascii Ribbon Campaign /\ Support plain text e-mail -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnhvss71.m0q.mario.ho...@darkside.dyn.samba-tng.org
Re: Let's write a system admin friendly mail server packaging system
Thomas Goirand tho...@goirand.fr wrote: What happens here is that, if you take a normal Debian system, then install postfix, then let's say amavis, they don't talk to each other. ... much spams. It is also totally unrealistic to say that it's up to the system administrator to configure everything by hand. If, like me, you do at least one setup a day, it takes too much time for no reason, and it has to be automated in some way. There are lots of examples out there where already works what you are requesting for mail servers. Let's have a look at web servers (well, apache... okay) and how they deal with it. I'm installing apache2 and have a web server - more or less working, I'm installing dhelp and ... magic, magic ... it extends the running web-server to serve the dhelp content as well. I'm installing smb2www and it extends the running web-server to act as smb client as well. How do they do this? There is some conf.d directory which contains config snippets for each of the packages. Let's have a look at DHCP and how they deal with it. I'm installing dhcp3-client and my machine's network settings are configured automagically. I'm installing resolvconf and my name servers become configured automagically via DHCP. I'm installing samba and it's also getting configured automagically via DHCP. I'm installing ntp and my ntp-server is configured automagically via DHCP. How do they do this? There is some conf.d directory which contains config snippets for each of the packages. Let's have a look at SysV boot mimics and how they deal with it. I'm installing the sysvinit packages ... well, you can imagine the rest: ... There is some conf.d directory which contains config snippets for each of the packages. Why would you like to go another way with mail servers? Get maintainer support for such conf.d directories, maybe get upstream support for such conf.d mimics (sendmail most likely won't need it - some m4 magic and triggers will just do it, dunno how it is for the less flexible ones like postfix, exim, whatever), change the depending packages to put their config snippets in there, everything is fine. argument a list of packages that it should use. But the MTA is not the only one to modify here, for example we might have to change the listen and relay port of dkimproxy and amavis, depending if each others are present on the system or not. I am quite in the favor of this system, I don't think this is really necessary. It would probably be a bit more efficient to have one component forwarding the stuff it processed to the next one, but I'm sure there is a less efficient but more generic way to just bounce it back to the MTA which continues forwarding it to the next components. ... And who cares about efficiency in generic approaches. regards Mario -- who | grep -i blonde | talk; cd; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; true; gasp; umount; make clean; sleep -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnhvqa8s.m0q.mario.ho...@darkside.dyn.samba-tng.org
Re: symlinks replaced by directories and vice versa
Brian May [EMAIL PROTECTED] wrote: If you want to replace a directory with a symlink, and the directory still contains files, what do you do with these files? Indeed, symlinks colliding with existing directories should give an error while package installation. And IMHO this could even be done pre etch, since this should just not occur. regards Mario -- It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories instead of theories to suit facts. -- Sherlock Holmes by Arthur Conan Doyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
symlinks replaced by directories and vice versa
Hello, IMHO, one of the most frequently re-appearing issues in package-upgrades is symlinks in previous package versions replaced by directories in current versions and vice versa. Although the Debian policy clearly states in 6.6 (4) A directory will never be replaced by a symbolic link to a directory or vice versa it seems to me that many package maintainers cannot deal well with this behaviour or just don't know it. I personally filed lots of bug reports against lots of packages in the past regarding this issue. Unfortunately, this issue is typically not so easy to detect soon when it appears. Instead, such cases linger around a long time until eons later some unexpected overwrites happen or until you try to remove a package or something like this. I personally just detect them soon because I run daily filesystem-modification checks (in conjunction with debsums) and thus notice quickly when new files appear where no files out of the package managers scope should exist. Unfortunately, the issue appeared so often that at some point in the past I just resigned and gave up to file bug reports because of it and instead I began just to fix it on my systems locally and forget about it. However, since this is such a frequent source of bugs and since so many package maintainers seem not to be able to deal well with it, I'm asking myself, if it wouldn't make sense to change this behaviour to something which is more native to maintainers - i.e. automagically replace symlinks by directories and vice versa (which would natively equal a package upgrade to a package removal followed by an installation of the new version) or abort package installation if it occurs or something like this. I'm not sure if this is the right list to discuss that, but perhaps it's the best list to collect notions from others (especially package maintainers) about it. I know there *are* maintainers out there who *know* about this case and *do* handle it carefully and sometimes even *use* it intentionally, like the sendmail maintainer (although even there it makes problems because of undetected overwrites). However, I have never seen any single case where it was really necessary to package something this way. regards Mario -- delta talk softly and carry a keen sword -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question: mount /var/run as tmpfs
Petter Reinholdtsen [EMAIL PROTECTED] wrote: mount point. For the others, edit /etc/default/rcS and set RAMRUN and RAMLOCK to 'yes'. There are still some packages unable to cope with Hmm, is there any argument against making /etc/default/rcS a conffile or an ucf file to make sure - or at least increase the chance - that users get to know about new conf-items in there? regards Mario -- User sind wie ideale Gase - sie verteilen sich gleichmaessig ueber alle Platten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
Hendrik Sattler [EMAIL PROTECTED] wrote: Which OS combination does not define int to be 32bit on a 64bit architecture? This is mainly compiler-, not primarily OS-dependent. And: all compilers with an ILP64 data model. However, the question should rather be: *why* compilers do not define int to be 64bit on a 64bit architecture? And the answer is simple: Yes int should be 64bit on a 64bit architecture, since int is defined as the architectures natural size data type. However, it is mostly not because of the elsewise massively increasing porting-expenses due to many programmers who never thought about it and simply assumed int to be 32bit. So, your metaphor implicitely leads to exactly the same answer ;) regards Mario -- snupidity bjmg: ja, logik ist mein fachgebiet. das liegt im gen uepsie in welchem? snupidity im zweiten X -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
Andreas Metzler [EMAIL PROTECTED] wrote:
It has been pointed out to me in http://bugs.debian.org/387699
that syvinit is going to move /var/run to a tmpfs to solve a long-standing
Yes, having the opportunity to mount /var/run on a tmpfs would be really
nice. Please consider the same for /var/lock, too. Since both IMHO
require a policy-change, it would be one go for both :)
are checked and mounted. (I do not know how they are going to handle
the fact that /var/run is needed before /var is mounted, mount --move
requires kernel 2.6 afaict.)
Relying on 2.6-only features for this is IMHO a no-go. 2.2 as well as
2.4 are maintained kernel-trees and just because the kernel-team seems
to like to live on the bleeding-edge of still heavily-changing kernels
only, there is no need for admins of stable systems to do the same.
This is nice, but is going to break packages that either ship a
subdirectory of /var/run in the deb or generate it once in
postinst and rely on its existence afterwards.
Yes. Anything shipped with a package (and thus being under package
manager's control) being removed afterwards is IMHO a no-go, too.
Therefor, the Debian policy should explicitely forbid packages to ship
files/directories within /var/run and /var/lock and require them to be
created at runtime instead.
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. Either by using some find+tar magic after
mounting /usr or by keeping /var/run a real directory and keep the
pre-mount stuff in /var/run/pre-mount. Other thoughts?
Those are all ugly hacks. Preserving structures like this will most
likely open room for race conditions/inconsistencies, i.e. systems that
die after the installation of some packages and before the mirror-magic
kept their state.
A somewhat more stable ugly hack could be to use any of the fs-merge
approaches (unionfs, translucency, ...) to get directories written to
the persistent layer while getting files written to the transient layer.
However, even this remains an ugly hack :)
And the approach to require packages to ship their /var/{run,lock}
directories somewhere else and get them mirrored to their real positions
automagically IMHO is ugly as well and requires quite the same effort as
providing some debhelpers that deal with on-the-fly creation/removal,
while the latter is the most clean approach, IMHO.
regards
Mario
--
Why did the tachyon cross the road?
Because it was on the other side.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
Steve Langasek [EMAIL PROTECTED] wrote: It is clear /to me/ from the juxtaposition of these two sentences that the FHS intends for programs to be allowed to create such subdirectories without them being removed at the beginning of the boot process. It is also clear Well, it would then probably be interesting to see how Ubuntu deals with their FHS-incompatibility - except the filing of bugs against Debian packages, of course :) regards Mario -- reich sein heisst nicht, einen Ferrari zu kaufen, sondern einen zu verbrennen Dietmar Wischmeier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
2.4 vs. 2.6 (was: Re: Moving /var/run to a tmpfs?)
Marco d'Itri [EMAIL PROTECTED] wrote: The problem with supporting old kernels is not just the need to maintain 2.4 is not old, it's just stable :) a few packages like initrd-tools or modutils, but that every important package cannot rely on features of modern kernels: inotify, sysfs, etc. Well, I live quite well with Debian unstable on top of 2.4 on my workstation. It seems there are not so much important packages that really rely on modern features. This means that Debian as a whole will either lack support for features relying on these kernel features or will become more and more complex due to compatibility code. Well, if there are really packages that demand on 2.6, they just can depend on kernel-image-2.6, this is no problem at all. I agree with you that package maintainers should not be forced to develop 2.4-compatibility on their own, if upstream doesn't do it itself. However, from my point of view, quite all relevant software just *does* support 2.4 and 2.6 upstream anyways. So there is virtually no need to increase complexity. Please consider carefully the effects of advocating support for old kernels. IIRC, Linus declared feature-freeze for 2.6.16 first. To be honest, I cannot see any feature-freeze until now. I personally decided to give 2.6 a first try on my workstation when 2.6.18 is out. However, as long as I can easily freeze my machine just by doing really simple disk-I/O tasks (which just happened when I had a need to boot into a Knoppix), I will definitely not consider it to run on my servers. regards Mario -- File names are infinite in length where infinity is set to 255 characters. -- Peter Collinson, The Unix File System -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.4 vs. 2.6
Hendrik Sattler [EMAIL PROTECTED] wrote: A good hint for such cases is to actually report such bugs to the driver developers. Did you? It's still in my reproduction and analysis-queue. However, 2.6 is not my biggest priority atm (it will still take a while to get it stable anyways :)). You must have pretty uncommon hardware, though, as many use 2.6 kernels without such problems... Not uncommon hardware, but uncommon usage patterns because my only reason for using 2.6 currently (with Knoppix) is maintenance - and reproduction of 2.4-problems to decide if I report them immediately or later :). regards Mario -- When Bruce Schneier uses double ROT13 encryption, the ciphertext is totally unbreakable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving /var/run to a tmpfs?
Marco d'Itri [EMAIL PROTECTED] wrote: Not all of them are buggy, e.g. ssh, inn and inn2 have the directory in the package but also create it in the init script if needed. I would consider this a bug, when a package ships things which it expects to magically disappear and where it thus cares about re-creating them all the time. There's just no need to ship them in the package then at all. Well... a minor bug probably :) regards Mario -- () Ascii Ribbon Campaign /\ Support plain text e-mail -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does doc packages need to contain gzipped files?
Preben Randhol [EMAIL PROTECTED] wrote: My point is that if I choose to install a doc packages I intend to use it frequently and would therefore like that it is user friendly rather than that one has squeezed some few kilobytes out by gzipping files. If Agreed. Particularly since the saving isn't sooo big at all. On my - of course, not representative - workstation an uncompressed doc/ tree takes only about a third more space (and this includes all the ChangeLogs, READMEs etc. shipped with each package). [EMAIL PROTECTED]:~# du -sh /usr/share/doc 839M/usr/share/doc [EMAIL PROTECTED]:~# cp -ia /usr/share/doc /var/tmp [EMAIL PROTECTED]:~# cd /var/tmp/doc [EMAIL PROTECTED]:/var/tmp/doc# find . -type f -name \*.gz -print0 | xargs -0 gzip -d gzip: ./kernel-package/Rationale already exists;not overwritten gzip: ./kernel-package/HOWTO-Linux-2.6-Woody already exists;not overwritten gzip: ./gcc-4.1-base/.changelog.Debian.gz has 1 other link -- unchanged gzip: ./gcc-4.1-base/changelog.Debian.gz has 1 other link -- unchanged [EMAIL PROTECTED]:/var/tmp/doc# du -sh . 1,3G. [EMAIL PROTECTED]:/var/tmp/doc# regards Mario -- There are 10 types of people in the world: Those who understand binary, and those who don't... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cgiirc Hijacking
Joe Smith [EMAIL PROTECTED] wrote: As I understand it, there is no good reason to have s.d.o in my sources list, as the packages in there are for sarge, and may not be compatible with the current sid ABI. This is nonsense. If this should really be the way you understand it, please ask yourself why a package's version on s.d.o which overrides a version in unstable (i.e. the version on s.d.o is bigger than the version in unstable) should ever have a less compatible ABI than the (smaller) version in unstable. regards Mario -- It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories instead of theories to suit facts. -- Sherlock Holmes by Arthur Conan Doyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cgiirc Hijacking
On Tue, Jun 20, 2006 at 01:18:11PM -0300, Margarita Manterola wrote: In cases where a security bug is being fixed, you usually try to upload the package as soon as possible. If your sponsor is on We did. 0.5.4-6sarge1 was on s.d.o as soon as possible. Since there were no newer version in unstable, the version on s.d.o should have had automatically override even the unstable version. Of course, if you don't source in s.d.o, you don't get security updates :) preparing the package, then ask for help... But not let the bug sit unfixed for more than a month. We didnt. Mario -- There is nothing more deceptive than an obvious fact. -- Sherlock Holmes by Arthur Conan Doyle signature.asc Description: Digital signature
