Bug#905381: [systemd-devel] [PATCH v2] meson: use the host architecture compiler/linker for src/boot/efi
On Do, 27.09.18 17:17, Helmut Grohne (hel...@subdivi.de) wrote:
> cross building systemd to arm64 presently fails, because the build
> system uses plain gcc and plain ld (build architecture compiler and
> linker respectively) for building src/boot/efi. These values come from
> the efi-cc and efi-ld options respectively. It rather should be using
> host tools here.
>
> Fixes: b710072da441 ("add support for building efi modules")
Hmm, any chance you could submit this through github please?
Lennart
--
Lennart Poettering, Red Hat
Bug#754078: crypt devices not brought online (backed by iscsi)
On Sun, 20.07.14 15:58, Michael Biebl (bi...@debian.org) wrote: Currently, with systemd, it gets to where it'd like to bring up the crypt devices. As network and open-iscsi aren't up yet, it wastes a lot of time waiting for block devices that will never appear (at least not without further action later in the boot process). Hm, k. So I guess we'd need something like a cryptsetup-pre.target, where certain units can hook into (via Wants/Before), network.target being one of them. And devices flagged noearly would get a dependency on this target and be ordered after it. Lennart, do you have a different/better idea how we could handle such setups which have more complex requirements, like cryptsetup devices being backed by iscsi which in turn requires network access? Not following here. In contrast to classic sysv the jobs actually stay queued until the devices show up. If you have iscsi devices that shall be mounted during boot, then you really need to make sure that iscsi can work in early boot. Then, if iscsi needs the network, then your network system needs to be able to run in early-boot too. I have the suspcicion this works on Fedora already. But generally, the old Debian scheme of running cryptsetup twice doesn't really apply to systemd, since we never scan for devices, we just subscribe to them. Anyway, still not grokking the actual problem here I must say... Lennart -- Lennart Poettering, Red Hat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744753: anacron: Anacron not triggered when system resumes under systemd
On Fri, 27.06.14 20:45, Michael Biebl (bi...@debian.org) wrote: Am 27.06.2014 20:10, schrieb Lennart Poettering: Well, I know that much. But a service which needs to be restarted on cases like this sounds wrong. Thats a hack really. The service should just watch time changes and react correctly to that. i.e. use TFD_TIMER_CANCEL_ON_SET. THis will report wallclock changes relative to monotonic time, which is what you want to watch for this. All system resumes will trigger this, of course. I might be missing something here, but keep in mind that anacron is not a long running process. It does its work and then exists. So what you describe above does not really help. Since a long time we had on our TODO list to support timer units that are triggered when the system clock changes, based on TFD_TIMER_CANCEL_ON_SET. Hasn't been implemented yet, should be fairly easy though. This should fit your bill perfectly, no? OnClockChange=yes or so... Lennart -- Lennart Poettering, Red Hat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744753: anacron: Anacron not triggered when system resumes under systemd
On Wed, 04.06.14 11:48, Sam Morris (s...@robots.org.uk) wrote: On Tue, Jun 03, 2014 at 08:25:25PM +0200, Lennart Poettering wrote: On Tue, 03.06.14 05:43, Michael Biebl (bi...@debian.org) wrote: Lennart, do you have better solution for such services which need to be restarted on suspend/resume? Why would a service need something like this? This sounds systematically flawed... I'd really try to focus on that and fix the software in question. The service in question, when started, checks to see if any of its cron jobs haven't been run for a specified period, running them if they haven't, then exits. It's intended as a replacement for the daily/weekly/monthly cron jobs, which will not run if your computer is turned off when their time arrives. Well, I know that much. But a service which needs to be restarted on cases like this sounds wrong. Thats a hack really. The service should just watch time changes and react correctly to that. i.e. use TFD_TIMER_CANCEL_ON_SET. THis will report wallclock changes relative to monotonic time, which is what you want to watch for this. All system resumes will trigger this, of course. Lennart -- Lennart Poettering, Red Hat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744753: anacron: Anacron not triggered when system resumes under systemd
On Tue, 03.06.14 05:43, Michael Biebl (bi...@debian.org) wrote: Lennart, do you have better solution for such services which need to be restarted on suspend/resume? Why would a service need something like this? This sounds systematically flawed... I'd really try to focus on that and fix the software in question. Lennart -- Lennart Poettering, Red Hat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747044: udev: fails to bring hotplug interface up (with systemd)
On Thu, 15.05.14 03:38, Michael Biebl (bi...@debian.org) wrote: Am 14.05.2014 18:35, schrieb Lennart Poettering: On Tue, 13.05.14 23:01, Gero Treuner (gt_72_debian@innocircle.com) wrote: So that this is possible: systemctl start sys-devices-virtual-net-@$(encodeunitname my-dev).device What about such addition resp. accepted patch? Well, we cannot extend the shell... I guess Gero was suggesting that systemd provides a small helper binary, like systemd-escape, which accepts a string on stdin and outputs the escaped string on stdout I think I would prefer if we could extend systemctl in some way, so that it understands a syntax for building unit names from unescaped strings. Lennart -- Lennart Poettering, Red Hat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747044: udev: fails to bring hotplug interface up (with systemd)
On Tue, 13.05.14 23:01, Gero Treuner (gt_72_debian@innocircle.com) wrote: Hello Lennart! On Mon, May 12, 2014 at 06:52:59PM +0200, Lennart Poettering wrote: On Mon, 12.05.14 18:40, Michael Biebl (bi...@debian.org) wrote: 1/ I don't want to re-implement the escaping rules outside of systemd, especially since I don't know the escaping rules. 2/ It's hard to escape the interface name from withing a udev rule, unless I call a shell script, where I do the escaping using sed dances. This is ugly, to say the least. 3/ systemctl status ifup@my-eth.service is much more intuitive then systemctl status ifup@my\x2deth.service. Auto-completing helps a bit, but it doesn't get the quoting right [0], so the failure mode is very confusing. Unit names must be escaped. And then %I can be used to undo that. Hence you cann include anything unescaped in the unit name, it just doesn't work... Now it is clear that it is the caller's responsibility to do encoding of unit names. Caller can be: administrating user, software packager i. e. distributor, software author, etc. As such one doesn't have knowledge about the exact details how the encoding has to be done, and sed dances tend to be error prone but nevertheless will be implemented many times in an ad-hoc manner. == systemd could help with a small utility around unit_name_escape() So that this is possible: systemctl start sys-devices-virtual-net-@$(encodeunitname my-dev).device What about such addition resp. accepted patch? Well, we cannot extend the shell... Not entirely sure how this really could look like... but of course, if oyu make a convincing argument how this could look like, then I am all ears. Might be a good idea to bring this up on the systemd ML, maybe somebody there has a good idea, how to teach systemctl escaping in a way that feels good. Lennart -- Lennart Poettering, Red Hat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747044: udev: fails to bring hotplug interface up (with systemd)
On Sat, 10.05.14 06:56, Michael Biebl (bi...@debian.org) wrote: Am 07.05.2014 21:19, schrieb Gero Treuner: On Wed, May 07, 2014 at 02:32:40PM +0200, Michael Biebl wrote: Please try the attached net.agent (copy it to /lib/udev/net.agent and make it executable). It escapes the interface name before starting an instance of the service. If you want to run systemctl status, make sure to quote the name like this: systemctl status ifup@veth\x2ddevmachine.service Please report if that works for you. The patch works fine. Thanks for all. Thanks for testing. Thinking more about it, a nicer solution would be, if systemd would offer another specifier [0], basically the inverse of %I. I.e. you pass a (unescaped) string as instance name and systemd does the escaping which then can be used in the unit file. Let's call that specifier %Y for now. Not following here? Note that unit names cannot contain unescaped strings. THis is because they are stored in the file system. Hence you either have to escape strings manually before including them in unit names, or you let systemctl do this for you automatically, because it detects that you passed an incompletely escaped string on the command line. But the latter really just is synctactic sugar to make things easy to use for admins. So, on the lower-level the string is always escaped, and then we provide %i and %I to refer to it from the unit file, one leaves it escaped as it is, the other one removes the escaping. But what should %Y do then? Lennart -- Lennart Poettering, Red Hat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747044: udev: fails to bring hotplug interface up (with systemd)
On Mon, 12.05.14 18:40, Michael Biebl (bi...@debian.org) wrote: Note that unit names cannot contain unescaped strings. THis is because they are stored in the file system. Hence you either have to escape strings manually before including them in unit names, or you let systemctl do this for you automatically, because it detects that you passed an incompletely escaped string on the command line. But the latter really just is synctactic sugar to make things easy to use for admins. Maybe an example makes it clearer. We do have an ifup@.service in Debian. This service has [Unit] Description=ifup for %I After=local-fs.target BindTo=sys-subsystem-net-devices-%i.device ... And a corresponding udev rule which activates those instance services. Now, say we have network interface containing a '-'. e.g. because I renamed eth0 to my-eth. If I run systemctl start ifup@my-eth.service, the resulting BindsTo= is not set properly, my-eth is not escaped. Well, this is the case since my-eth is ambiguous, since it can either be an unescaped string, or an escaped version of my/eth. Now, systemctl will always assume you escape things properly if in doubt and only if you clearly didn't escape things it will do so for you. Which means in this case it will assume it is properly escaped and hence %i is my-eth, and %I is my/eth. Which is the right thing to do I would argue. The syntax systemctl start ifup@my-eth.service is genuinly problematic, since you actually use three special chars in there: @, ., -. The former two special chars you want systemd to handle as the special chars they are, but the ther former you want to systemd to handle as something it shall not understand as special char, and should hence implicitly escape... But how should systemctl figure out what you are trying to say here? I want a specifier which does the following: Take the instance name and escape it. This has several reasons: 1/ I don't want to re-implement the escaping rules outside of systemd, especially since I don't know the escaping rules. 2/ It's hard to escape the interface name from withing a udev rule, unless I call a shell script, where I do the escaping using sed dances. This is ugly, to say the least. 3/ systemctl status ifup@my-eth.service is much more intuitive then systemctl status ifup@my\x2deth.service. Auto-completing helps a bit, but it doesn't get the quoting right [0], so the failure mode is very confusing. Has it become clearer with this example? I think the misunderstanding here is abotu what the actual name of the unit is. Unit names must be escaped. And then %I can be used to undo that. Hence you cann include anything unescaped in the unit name, it just doesn't work... Lennart -- Lennart Poettering, Red Hat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669866: manpages: New manual page: hostname(5)
On Wed, 23.04.14 07:42, Michael Kerrisk (man-pages) (mtk.manpa...@gmail.com) wrote: On 04/21/2014 05:01 PM, Roger Leigh wrote: On Mon, Apr 21, 2014 at 03:39:20PM +0200, Michael Kerrisk (man-pages) wrote: On 04/21/2014 10:04 AM, Petter Reinholdtsen wrote: [Roger Leigh] Sorry, I've not done anything on this lately--I'm not too active in Debian at present due to RSI and other reasons. Petter, would you possibly be able to look into this on the sysvinit side? As far as I can see from URL: https://bugs.debian.org/669866 , the upstream manpages maintainer is waiting for copyright information for the hostname.5 file. This can only be provide by the authors, and nothing I can do from the sysvinit side. Exactly. The page text says it was written by Lennart P and Roger. If they're both agreeable, and have a license, then I'd take the page. For my part, I'm happy for my contributions to this page to be licensed under whatever DFSG-free licence you use for the manpages. Hi Lennart, See https://bugs.debian.org/669866. Roger Leigh has made a proposal that the hostname(5) page should be upstreamed into man-pages. This makes some sense to me, since /etc/hostname is a standard system file (like /etc/paasswwd, /etc/group, etc.), and most of those are documented by man-pages. It appears that the page is currently distributed by both Debian and as part of systemd, and the version referred top in the bug is noted as being written by you and Roger. What do you think of passing this page to man-pages? Does it make sense? I don't mind if the man page is added to the manpages package under any license you like, but do note that /etc/hostname is a Debianism, which we added to systemd and thus is now supported by the union of Debian-derived distributions and those which adopted systemd. I am not sure what the rules regarding what belongs in the manpages package is, but I have the suspicion that at least Slackware and Gentoo don't have this file. Also, in the systemd context the man page refers to hostnamectl(1) which doesn't exist outside of systemd, and we make stricter recommendations on the hostname to store in /etc/hostname than debian probably traditionally made. How does the Debian version of the man page look like? Is it available online? How would the version you'd add to the manpages package look like? The systemd version you find here: http://www.freedesktop.org/software/systemd/man/hostname.html Lennart -- Lennart Poettering, Red Hat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739593: [Pkg-systemd-maintainers] Bug#739593: Bug#739593: closed by Michael Stapelberg stapelb...@debian.org (Re: Bug#739593: systemd makes / shared by default)
On Tue, 11.03.14 14:14, Christoph Berg (m...@debian.org) wrote:
Re: Michael Stapelberg 2014-03-08 x6d2hwflle@midna.zekjur.net
The following patch works for me to make your newpid program work:
--- i/newpid.c
+++ w/newpid.c
@@ -40,11 +40,9 @@ run (void *argv_void)
pid_t child;
pid_t pid;
- if (umount (/proc) != 0) {
- /* ignore errors here, /proc could be busy
- perror (umount /proc);
+ if (mount(none, /proc, NULL, MS_PRIVATE|MS_REC, NULL) !=
- 0)
Please do not use MS_PRIVATE for this. This has the the result to
disconnect propagation both ways, which doesn't sound too bad, but
actually is. The reason is that this controls propagation for both mount
*and* umount. Hence any file system you inherited from the root
namespace will stay mounted forever in your detached namespace, and that
might be a problem for the admin since that way the device it is mounted
from is kept busy until forever. If you use MS_SLAVE however then any
umount from the host will still propagate into your namespace, and thus
no t keep things busy. Now, if you only care about /proc then this isn't
too bad as no block devices are mounted below /proc, but I would still
do it, since at least binfmt_misc is still mounted there...
MS_PRIVATE only makes sense on file systems you created entirely on your
own.
Ok, that works, thanks! I only tried to remount / which didn't seem to
have any effect.
Unfortunately MS_PRIVATE and MS_REC are not defined in squeeze, so
that fix won't work for chroots running on a systemd system, but
that's something I should be able to work around.
They have been vailable in the kernel for a long long time. If you libc
doesn't expose them use something like this:
#ifndef MS_PRIVATE
#define MS_PRIVATE (1 18)
#endif
#ifndef MS_REC
#define MS_REC 16384
#endif
We use the same code in systemd.
Lennart
--
Lennart Poettering, Red Hat
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719695: [Pkg-systemd-maintainers] Bug#719695: Bug#719695: Bug#719695: Prefer symlinks over Alias= for non-matching service names
{
if (r == -ENOENT
unit_name_is_instance(info-name)) {
/* Unit file doesn't exist, however instance
enablement was requested.
* We will check if it is possible to load
template unit file. */
Lennart
--
Lennart Poettering, Red Hat
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739593: [Pkg-systemd-maintainers] Bug#739593: Bug#739593: closed by Michael Stapelberg stapelb...@debian.org (Re: Bug#739593: systemd makes / shared by default)
On Fri, 28.02.14 06:51, Martin Pitt (mp...@debian.org) wrote: We turned the default from PRIVATE to SHARED on request of the container and security guys, since they want that if you mount something from the host into a subdir of the container, it should just appear there, because that's what most people would most likely expect. Well, but conversely what scripts/people expected before that script was that something that you run under unshare -m really actually did what it says on the tin, namely that it really *does* have its private mount name space. Now it doesn't, and mounts done in that unshared process affect the system outside of it. I. e. all such programs now have to be changed to do that mount --make-rprivate / dance. I have talked to Karel, he's thinking about adding --propagation=slave|shared|private|none to unshare -m now, with a default of slave. Please ping him on IRC or so, so that he sees that there is demand for that. With that change unshare -m should work for everybody the same. The kernel default for this is unlikely to change since they argue that it breaks compatbility, which I kinda agree with. In systemd however, we thought we'd better pick saner defaults. That has the same net effect though, changing the global default? systemd and the kernel shouldn't have two different defaults, otherwise we'll eternally have scripts and programs with different expectations. Well, we don't provide 100% compat anyway, just 99%. We are pretty sure that the shared default makes a lot of sense though and that apps that need their private setups need to be fixed anyway, so we took the liberty to switch here, better earlier than later. Of course, that worked for us quite well, since we already did this change 3y ago where people probably didn't assume things about unshare -m so much yet... Lennart -- Lennart Poettering, Red Hat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739593: [Pkg-systemd-maintainers] Bug#739593: closed by Michael Stapelberg stapelb...@debian.org (Re: Bug#739593: systemd makes / shared by default)
On Thu, 27.02.14 10:36, Michael Stapelberg (stapelb...@debian.org) wrote: The bit I was missing here is that I can run mount --make-rprivate / *inside* the CLONE_NEWNS namespace, so that it doesn't modify the system's global state, but just what I am seeing. (Does anyone actually understand these semantics?!) I think I had to read sharedsubtree.txt about a dozen times before I understood it, so you're not the only one left wanting better documentation. :) Lennart, we are considering disabling the code in systemd which makes / shared by default so that we follow the kernel default. Hmm? Why would you do that? I’d be interested in your comments on that, especially in the context of this bugreport (see http://bugs.debian.org/739593 for full history). If you open your own mount namespace and don't want propagation, then turn off propagation, by remounting the root dir inside the namespace with MS_REC|MS_SLAVE or suchlike. We turned the default from PRIVATE to SHARED on request of the container and security guys, since they want that if you mount something from the host into a subdir of the container, it should just appear there, because that's what most people would most likely expect. Or, if you use something like pam_namespace to give users a private /tmp, they should otherwise see all the mounts popping up/removed as normal. The kernel default for this is unlikely to change since they argue that it breaks compatbility, which I kinda agree with. In systemd however, we thought we'd better pick saner defaults. I'd strongly recommend not to patch this in Debian. First of all, you'd break a lot of stuff when using containers, where suddenly mounts on the host wouldn't propagate anymore to containers, or where using pam_namespace for /tmp could not work anymore, which would certainly be confusing. But more importantly you don't actually fix anything. You just switch defaults, and with the new default your specific case might start working, but for everybody else who changed the default things would still be broken. And since disassocitation is a one-way street if you globally disassociate everything you can never reassociate things... Or to explain this differently: a) With the default of MS_SHARED for the root dir like systemd sets it up, you enable propagation to containers, and those who don't want the propagation can opt-out of it for their specific namespace. Advantage: you cover all usecases with the default setting. All programs will work with both of MS_SHARED and MS_PRIVATE set for /. Disadvantage: you might need to patch a package or two to properly disassociate their namespace from the host by remounting the root dir inside of the namespace with MS_REC|MS_SLAVE as described above. b) If you patch systemd to go back to MS_PRIVATE for the root dir, you disable propagation to containers, and nobody can opt-in to it anymore for their specific namespace. Advantage: you don't have to patch those few programs which currently assume the root dir is MS_PRIVATE and don't disassociate things. Disadvantage: the apps are still broken for those who switch to MS_SHARED for /. You hence only cover the usecases where people do not dissassocitate. You break the usecase where people want the propagation to tkae place. TL;DR: fix the individual processes locally to disassociate their namespaces. Don't tape over it by making all of them disassociate by default, breaking those which do not want to disassociate. Because after disassociation there is no way back. Oh, and of course, in Fedora and RHEL we'll stick to the MS_SHARED defaults. Sooner or later we'll patch through all software that assumes that MS_PRIVATE was the default... Hence, sooner or later we'll fix all these things for you anyway... Hope this makes some sense... Lennart -- Lennart Poettering, Red Hat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618862: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution
On Sat, 08.02.14 21:07, David Härdeman (da...@hardeman.nu) wrote: On Wed, Feb 05, 2014 at 12:16:00AM +0100, Lennart Poettering wrote: On Thu, 30.01.14 10:40, David Härdeman (da...@hardeman.nu) wrote: This issue is fixable with minor upstream changes, e.g. by extending the PasswordAgent protocol to add Subsystem=cryptsetup and Target=diskname entries to the ask. file. I'd be fine with adding a field Id= or so, which then is filled by an identifier of some kind be the cryptsetup tool that is useful to identify the device to query things on. for example: Id=cryptsetup:/dev/sda5 or so could be one way how this could be filled in. We wouldn't enfoce any kind of syntax on this, just suggest some common sense so that people choose identifiers that are unlikely to clash with other subsystems, and somewhat reasonable to read... In the patches I sent I split it into Purpose and Target and my thinking was more or less the same as yours...i.e. that there's no particular syntax and that the meaning of the string is subsystem specific. I'd be happy to change the patch to use Id=subsystem:target if you'd prefer. Yes, please! b) the password agent implementation in systemd doesn't seem to handle binary strings (i.e. strings with '\0'), as can be seen by calls to e.g. strlen()... Whether making it binary safe would be a major change or not is something I haven't researched yet but it seems like a change that should be generally useful upstream... I'd be OK with this, as discussed at FOSDEM, and I see you already posted a ptach for this. Yes. I take it you're pretty busy with the kdbus stuff right now but a review of those patches would be nice when you have the time. Lennart -- Lennart Poettering, Red Hat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618862: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution
On Thu, 30.01.14 10:40, David Härdeman (da...@hardeman.nu) wrote: a) getting the name of the cryptdev that the password request corresponds to currently involves parsing the prompt message (Please enter passphrase for disk %s!) which is obviously not a real solution... This issue is fixable with minor upstream changes, e.g. by extending the PasswordAgent protocol to add Subsystem=cryptsetup and Target=diskname entries to the ask. file. I'd be fine with adding a field Id= or so, which then is filled by an identifier of some kind be the cryptsetup tool that is useful to identify the device to query things on. for example: Id=cryptsetup:/dev/sda5 or so could be one way how this could be filled in. We wouldn't enfoce any kind of syntax on this, just suggest some common sense so that people choose identifiers that are unlikely to clash with other subsystems, and somewhat reasonable to read... b) the password agent implementation in systemd doesn't seem to handle binary strings (i.e. strings with '\0'), as can be seen by calls to e.g. strlen()... Whether making it binary safe would be a major change or not is something I haven't researched yet but it seems like a change that should be generally useful upstream... I'd be OK with this, as discussed at FOSDEM, and I see you already posted a ptach for this. a) the cryptsetup package b) as part of the Debian systemd package c) upstream systemd I'd prefer to keep this tool in a Debian-specific package. I am not convinced that the key script thing is something we should standardize on cross-distributions. Lennart -- Lennart Poettering, Red Hat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: [PATCH] systemctl: allow globbing in commands which take multiple unit names
On Thu, 26.12.13 17:39, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
As discussed on IRC, here's a patch which takes the simple approach of
allowing globbing on loaded unit names in various (almost all :)) systemctl
commands. Comments?
Looks good. But maybe an additional warning should be printed if people
use globs on the systemctl start command line? Some shorter version of
the blurb you added to the man page? i am pretty sure people will run
into this problem, and we should tell them what is going on...
+bool string_is_glob(const char *p) {
+return strchr(p, '*') || strchr(p, '?') || strchr(p, '[');
+}
+
This looks prettier:
#define GLOB_CHARS *=[
bool string_is_glob(const char *p) {
return !!strpbrk(p, GLOB_CHARS);
}
The macro should probably live in the header, next to ther others... And
maybe the function too as static inline? given that is is just one
function call internally that sounds pretty ok as static inline call?
Lennart
--
Lennart Poettering, Red Hat
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: [PATCH] systemctl: allow globbing in commands which take multiple unit names
On Thu, 26.12.13 10:09, Russ Allbery (r...@debian.org) wrote:
Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes:
As discussed on IRC, here's a patch which takes the simple approach of
allowing globbing on loaded unit names in various (almost all :)) systemctl
commands. Comments?
I don't know the coding style of systemd, so please feel free to ignore
this comment if it's not consistent with the style used elsewhere. But
since I saw this in passing:
diff --git a/src/core/device.c b/src/core/device.c
index 2c44dec..d3976c9 100644
--- a/src/core/device.c
+++ b/src/core/device.c
@@ -268,7 +268,7 @@ static int device_update_unit(Manager *m, struct
udev_device *dev, const char *p
memcpy(e, w, l);
e[l] = 0;
-n = unit_name_mangle(e);
+n = unit_name_mangle(e, false);
if (!n) {
r = -ENOMEM;
goto fail;
A wise person convinced me a while back to avoid boolean arguments to C
functions in most cases because the meaning of the argument is very
inobvious at the call site. false what? What's disabled? One has to
go read the function definition to know, and while that's easy to find,
particularly with a cross-referencing editor, it takes one more step.
What I've switched to instead is using tiny enums for this purpose. So:
enum mangle_type {
MANGLE_NOGLOB = 0,
MANGLE_GLOB = 1
};
and then at the call site:
n = unit_name_mangle(e, MANGLE_NOGLOB);
which makes the meaning of that argument immediately obvious.
As long as this is just one boolean arg on functions, or the functions
are internally used I think booleans are fine to use.
I don't think flag fields are necessarily the best choice for APIs in
general. For APIs that are built around a context object seperate
boolean setter calls are the better choice (i.e. foobar_set_waldo() to
set som boolean called waldo on a context object foobar).
Then in many APIs we exposed we actually return strings instead of
enums, since that's much easier to extend. (libudev does this for
example, and so does libsystemd-login)
So, the summary is: keep it low on booleans, keep it low on flags. The
middle ground where you don't have much of neither is the best, and in
general having fewer options is better than having many...
Lennart
--
Lennart Poettering, Red Hat
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732157: [systemd-devel] Fwd: [Pkg-systemd-maintainers] Bug#732157: Want SIGSTOP-style daemon/service readiness notification
On Sat, 14.12.13 14:19, Shawn Landden (sh...@churchofgit.com) wrote: It would be nice if systemd could implement the service supervisor side of the service readiness protocol that upstart calls expect stop: The service doesn't fork, and when considers itself ready it raises SIGSTOP. The supervisor can observe this via the usual mechanisms, being the service's parent, and when it occurs it sends the service CONT and starts whatever was waiting for readiness. Oh, no. That Upstart SIGSTOP hackery is completely broken. SIGSTOP is poperty of the admin, the init system cannot just take possession of that and turn it into something that it really isn't. The admin must be able to freeze processes when he wants to, and the init system should not interfere with that and immediately undo it, nor should it get confused if the admin uses it independently of the init system. Thus, SIGSTOP is really nothing the init system should touch, ever. It's similar to Upstart's ptrace hackery: an init system should not take away functionality that belongs to the admin, and by using ptrace Upstart makes it unavailable to the admin because there can be only one tracer per process at a time. On an Upstart system where this is used you cannot gdb or strace (!!!) the initialization phase of those daemons anymore. This is really not how we should do it: the admin must be capable of tracing and pausing the boot process, and an init system should not make that impossible. The sd_notify(3) protocol is just about tolerable, and it is good that it's documented, but it is quite unattractive for a daemon author: Either they have to add a build- and runtime- dependency on a systemd-specific library, or they have to reimplement a fairly tedious piece of socket code. Well, to make this more palatable we actually made the code available under MIT license (i.e. much less restrictions than the otherwise GPL2+ sources of systemd), and made it embeddable so that people can just drop sd-daemon.c + sd-daemon.h into their sources and forget about it. sd-daemon.c/sd-daemon.h nowadays even compiles fine on Solaris and other OSes in order to make this as little cumbersome as possible. Developers hence have the choice to either link to dynamically, or to embedd it, if they don't want the dependency. Or alternatively, they can just reimplement sd_notify(), which is intentionally designed to be as trivial as it gets. i.e. you just send one datagram containing text to the socket mentioned in $NOTIFY_SOCKET, that's all. Finally, on purpose we actually kept this so simple and left all systemd-specific identifiers out of the protocols (i.e. it's called $NOTIFY_SOCKET not $SYSTEMD_SOCKET or so), so that other folks can implement it too without having to leak the name systemd into their sources, in particular to make this easy for Upstart... (they were never interested though, but at least we can say we tried). For a daemon author, raise(SIGSTOP) is lovely and simple. For an admin raise(SIGSTOP) is just bad. Let's not forget that developers better write programs that don't make the admin's/user's life hard... They usually curse at us anyway, but let's not make the most obvious mistakes by making it impossible to pause processes or tracing the boot-up phase... ennart -- Lennart Poettering, Red Hat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705900: check_ping fail if host do not have IPv6 address
On Sun, 12.05.13 08:02, Petter Reinholdtsen (p...@hungry.com) wrote: Joachim, perhaps time to use the patch I provided in the Debian package, while we wait for these lofty old wizards to fight out their world view dispute? How about just spending some time to track down the *actual* issue and then doing something? It shouldn't be too hard to figure out where the scopeid is lost between nss-myhostname and ping6 on Debian? It's usually a good idea to first understand the whole issue and then fixing it at the right place before prematurely applying knowingly incorrect patches that just tape over things? I fail to see the advantage of having libnss-myhostname, which is intended to make sure it is possible to look up the local host name and always get a working IP address, return an IPv6 address that can't be used to ping, connect or pass on. Thanks for being so constructive. Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705900: check_ping fail if host do not have IPv6 address
On Mon, 13.05.13 10:03, Joachim Breitner (nome...@debian.org) wrote: Hi, I got more information: If, in the attached example test.c, the ai_family field of the hints argument to getaddrinfo is set to AF_UNSPEC, then I do get the correct scope id in the returned data structure. If the hint is set to AF_INET6, I don’t (but I also do not get the debugging information that I put into libnss-myhostname, so I might just not fully understand what’s going on here). BTW, you are aware of getent ahosts and getent ahostsv6 which pretty much do what your test tool does? Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705900: check_ping fail if host do not have IPv6 address
On Tue, 07.05.13 12:43, Noah Meyerhans (no...@debian.org) wrote: On Tue, May 07, 2013 at 04:25:40PM +0200, Petter Reinholdtsen wrote: I do not know IPv6 addressing or the glibc internals well enough to form an opinion on this, but I do not understand your argument. ping6 and libc can know from the values in the IPv6 address if it is a link-local address or not, and if it is a link-local address, it need the scope. Why isn't that enough to implement handling of this issue in ping6 and libc? Because unless you explicitly specify a scope ID, the kernel and libc cannot infer them. This is why you need to specify the scope ID when pinging a link-local address. As mentioned, nss-myhostname provides the scope ID field filled in correctly to glibc. If this information is somehow lost on the way to the caller of getaddrinfo(), then this is a fuckup in glibc, and that's it. Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705900: check_ping fail if host do not have IPv6 address
On Sat, 27.04.13 09:39, Petter Reinholdtsen (p...@hungry.com) wrote:
[Joachim Breitner]
it was reported that libnss-myhostname may report an IPv6 address
for the local hostname that is not pingable, as it is a link scoped
address, and it was suggested that it not do that. Do you agree and
can you fix it?
Here is a simple patch to make sure link local addresses are no longer
returned by libnss-myhostname.
We currently filter addresses of HOST and NOWHERE scope, but local
addresses should generally be fine.
The alternative would be to return addresses with %interface appended,
but I did not investigate how to do that.
This is done by filling in the scopeid field, which we do.
See
http://cgit.freedesktop.org/systemd/systemd/tree/src/nss-myhostname/nss-myhostname.c#n180
+bool is_ipv6_link_local(unsigned short family, void *address) {
+char str_buffer[INET6_ADDRSTRLEN];
+if (AF_INET6 != family)
+return false;
Yoda style comparisons are not acceptable in systemd's sources.
+
+if (NULL == inet_ntop(AF_INET6, address, str_buffer,
INET6_ADDRSTRLEN))
+return false;
+
+if (0 == strncmp(fe, str_buffer, 2)) {
+char c = str_buffer[2];
+if (c == '8' || c == '9' || c == 'a' || c == 'b')
+return true;
+}
+return false;
If you want to filtzer local scoped addresses, then use the scope field
supplied by the kernel, nothing else. You shouldn't duplicate the scope
logic of the kernel by looking at the addersses themsleves...
But anyway, AFAICS we already do the right thing here anyway, and local
addresses should be unproblematic.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624599: More debugging
On Wed, 17.10.12 00:23, Michael Biebl (bi...@debian.org) wrote: As my memory is a bit vague here, I've CCed Lennart, since I don't want to tell nonsense. Lennart, I hope you can chime in here and shed some light on this problem. systemd only orderes queued jobs against each other. And yes if you have a service foobar.service ordered after waldo.service, and waldo.service issues a job for foobar.service and blocks on it, then systemd will honour the ordering and you might deadlock, indeed. There are various Would it be possible to detect such dead lock situations and simply refuse new requests which would cause a dead lock? This would make systemd more robust overall. Sure, but this is a bit like solving the halting problem... I fear this is not really feasible... We thought about this before, but came to no conclusion, and usually the better fix is to just not to wait here. After all, and that is kinda key here: what is expressed in the config file/hook calls *is* simply contradictory... Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686115: CanReload is set to yes unconditionally for legacy SysV services
On Tue, 16.10.12 10:21, Michael Stapelberg (stapelb...@debian.org) wrote: Hi Lennart, Lennart Poettering lenn...@poettering.net writes: I'd prefer if this complex check (at least the last part of it) could be moved into its own function, to make this easier to read. Done. We tend to write: if (...) foo; else bar; Also done. I’ve attached a git format-patch against the current systemd HEAD (for merging it upstream) and an updated version of the patch for systemd 44 (for Debian). Thanks! Applied! Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624599: More debugging
On Sun, 14.10.12 20:06, Michael Biebl (bi...@debian.org) wrote: Summary: systemd blocks on networking.service, networking.service’s systemctl blocks on systemd → deadlock. As discussed on IRC: I think there is a bit more to that then the above explanation. If you run systemctl reload on a non-running service, it will *not* block and simply returns immediately. So this can't explain the problem above. From past discussions with Lennart, I think the problem is, that systemd tries to minimize unnecessary actions. Say during an transaction, a service is started and reloaded. systemd will try to reorder the service so it can avoid the reload. I guess in this case this means blocking, until the actual start happens. And then we indeed get the deadlock. As my memory is a bit vague here, I've CCed Lennart, since I don't want to tell nonsense. Lennart, I hope you can chime in here and shed some light on this problem. systemd only orderes queued jobs against each other. And yes if you have a service foobar.service ordered after waldo.service, and waldo.service issues a job for foobar.service and blocks on it, then systemd will honour the ordering and you might deadlock, indeed. There are various fixes thinkable: Most likely there should not be any ordering between the two units, or you could pass --no-block to avoid the problem. There are even hacks available, such as --ignore-dependencies, but I'd really not recommend using those... Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686115: CanReload is set to yes unconditionally for legacy SysV services
On Mon, 15.10.12 00:33, Michael Stapelberg (stapelb...@debian.org) wrote:
Heya,
I am not a big fan of heuristics like this, but it does fix a valid
issue and I don't see how else we could implement this. So, yeah, looks
mostly good to commit. But first, please make a few changes:
+/* Try to figure out whether this init script
supports
+ * the reload operation. This heuristic looks for
+ * Usage: lines which include the reload option.
*/
+if ( state == USAGE_CONTINUATION ||
+(state == NORMAL strcasestr(t, usage))) {
+if (strcasestr(t, {reload|) ||
+strcasestr(t, {reload}) ||
+strcasestr(t, {reload\) ||
+strcasestr(t, |reload|) ||
+strcasestr(t, |reload}) ||
+strcasestr(t, |reload\)) {
I'd prefer if this complex check (at least the last part of it) could be
moved into its own function, to make this easier to read.
+supports_reload = true;
+state = NORMAL;
+} else if (t[strlen(t)-1] == '\\') {
+state = USAGE_CONTINUATION;
+} else {
+state = NORMAL;
+}
We tend to write:
if (...)
foo;
else
bar;
rather than:
if (...) {
foo;
} else {
bar;
}
C is not PHP after all ;-)
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630206: libnss-myhostname: FTBFS: fatal error: asm/types.h: No such file or directory
On Fri, 17.06.11 09:56, Joachim Breitner (nome...@debian.org) wrote: Hi, Am Dienstag, den 14.06.2011, 23:01 +0200 schrieb Robert Millan: 2011/6/14 Lennart Poettering lenn...@poettering.net: if LEGACY foo_SOURCES += legacy.c else foo_SOURCES += netlink.c endif In the Makefile.am file. Here. I have applied and uploaded this patch to the Debian package. If there will be a better patch that addresses the ifindex issue, I’ll be happy to apply that as well. Hmpf. If you don't fix it nobody will. When I merged this I kinda expected you'd be providing a follow-up patch to fix this. I am not sure I want to leave it in like this, because I'll take the blame for this. Hence, I will revert the patch before the next release if this is not fixed properly. BTW, Lennart, I am also applying the attached patch because HOST_NAME_MAX does not always exist. If you could include that patch in the next version as well, that would be great, as it further reduces the difference to the Debian version. Ah, one of those Hurd features. How useless... Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630206: libnss-myhostname: FTBFS: fatal error: asm/types.h: No such file or directory
On Fri, 17.06.11 11:16, Robert Millan (r...@debian.org) wrote: 2011/6/17 Joachim Breitner nome...@debian.org: I have applied and uploaded this patch to the Debian package. If there will be a better patch that addresses the ifindex issue, I’ll be happy to apply that as well. Thanks Joachim. I may have a look at improving this, though not right now. BTW, Lennart, I am also applying the attached patch because HOST_NAME_MAX does not always exist. If you could include that patch in the next version as well, that would be great, as it further reduces the difference to the Debian version. GNU/kFreeBSD has MAXHOSTNAMELEN, so you could just use this macro if HOST_NAME_MAX isn't defined. Please don't hardcode such limits unnecessarily. Is there any good reason why kfreebsd does not set HOST_NAME_MAX but MAXHOSTNAMELEN? Or is it just to annoy people and to litter other people's code with ifdef orgies? HOST_NAME_MAX is POSIX, so I see really no reason to add some compat kludgery, for MAXHOSTNAMELEN. http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html Fix your glibc first. And if there's a really good reason not to, then at least supply me with a patch, because otherwise I don't care. Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630206: libnss-myhostname: FTBFS: fatal error: asm/types.h: No such file or directory
On Thu, 16.06.11 10:59, Robert Millan (r...@debian.org) wrote: 2011/6/15 Lennart Poettering lenn...@poettering.net: I have commited this now, though I am pretty sure this is actually broken. You cannot just go and make up ifindexes. You need to determine the kernel ifindexes for your interfaces. You probably simply need to call if_nametoindex() on all ifa_name fields. In my tests I didn't observe any ill effects. What is this needed for? It's used all over the place. For example on IPv6 the ifindex is required to make link-local addresses usable. (i.e. a link-local address is private to a specific link, hence you need to specify the link explicitly by means of the ifindex it is behind, which normally happens automatically if you use getaddrinfo() but will not work for you.) Also quite a few other APIs use ifindexes, for example the mcast APIs, or IP_PKTINFO or IP_RECVINTERFACE or IPV6_PKTINFO or IP_MULTICAST_IF. In general it is smart never to deal with interface names internally in apps, but use ifindexes instead, since names can be changed dynamically, and indexes are fixed during the entire existance of an interface. interface names should only be use in user configuration and for presentation purposes. (i.e. on the way in our out of a process, but not in the process itself). So, in short: you are at least breaking mcast, breaking link-local addressing and matching up of addresses with packets right now. And there's probably a lot more. Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630206: libnss-myhostname: FTBFS: fatal error: asm/types.h: No such file or directory
On Tue, 14.06.11 23:01, Robert Millan (r...@debian.org) wrote: 2011/6/14 Lennart Poettering lenn...@poettering.net: if LEGACY foo_SOURCES += legacy.c else foo_SOURCES += netlink.c endif In the Makefile.am file. Here. I have commited this now, though I am pretty sure this is actually broken. You cannot just go and make up ifindexes. You need to determine the kernel ifindexes for your interfaces. You probably simply need to call if_nametoindex() on all ifa_name fields. Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630206: libnss-myhostname: FTBFS: fatal error: asm/types.h: No such file or directory
On Tue, 14.06.11 17:49, Robert Millan (r...@debian.org) wrote: 2011/6/13 Lennart Poettering lenn...@poettering.net: +#ifdef __linux__ +#include netlink.c +#else +#include legacy.c +#endif Urks, no. Please do this in Makefile.am. Tried that, but it's a no-go. Automake doesn't support build time substitutions in _SOURCES AFAICT (its maintainers seem to confirm this in http://lists.gnu.org/archive/html/automake/2008-08/msg00047.html) Uh? No. Please use autoconf conditions and then do if LEGACY foo_SOURCES += legacy.c else foo_SOURCES += netlink.c endif In the Makefile.am file. Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630206: libnss-myhostname: FTBFS: fatal error: asm/types.h: No such file or directory
On Sun, 12.06.11 21:35, Joachim Breitner (nome...@debian.org) wrote: Hi Christoph, Hello Lennart, Am Sonntag, den 12.06.2011, 12:34 +0200 schrieb Christoph Egger: Package: src:libnss-myhostname Version: 0.3-1 Severity: serious Tags: sid wheezy Justification: fails to build from source (but built successfully in the past) Hi! Your pacage failed to build on the kfreebsd-* buildds: libtool: compile: x86_64-kfreebsd-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I/build/buildd-libnss-myhostname_0.3-1-kfreebsd-amd64-oyrjWQ/libnss-myhostname-0.3 -include ./config.h -Wall -g -O2 -Wall -W -Wextra -pedantic -pipe -Wformat -Wold-style-definition -Wdeclaration-after-statement -Wfloat-equal -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-noreturn -Wshadow -Wendif-labels -Wpointer-arith -Wcast-align -Wwrite-strings -Winline -Wno-unused-parameter -ffast-math -fvisibility=hidden -fdiagnostics-show-option -MT netlink.lo -MD -MP -MF .deps/netlink.Tpo -c /build/buildd-libnss-myhostname_0.3-1-kfreebsd-amd64-oyrjWQ/libnss-myhostname-0.3/netlink.c -fPIC -DPIC -o .libs/netlink.o /build/buildd-libnss-myhostname_0.3-1-kfreebsd-amd64-oyrjWQ/libnss-myhostname-0.3/netlink.c:25:23: fatal error: asm/types.h: No such file or directory compilation terminated. make[3]: *** [netlink.lo] Error 1 Full build log at https://buildd.debian.org/status/fetch.php?pkg=libnss-myhostnamearch=kfreebsd-amd64ver=0.3-1stamp=1307742167 If you have further questions please mail debian-...@lists.debian.org it seems that nss-myhostname has changed the way it acquires link addresses between versions 0.2 to 0.3 to make use of the netlink interface. This breaks the package on hurd and freebsd kernels. What should we do here? I see three options: I think it is a major waste of time thinking about BSD and Hurd. That said, I'd be willing to merge a patch that adds support for those legacy systems -- if it is minimal. Note however that it wouldn't be release critical to me, i.e. I will not care if it works or not when releasing a new version. But I geuss that doesn't matter much since it is quite a finished project and I expect very few updates in the future. So yupp, if you send me a minimal, non-intrusive patch with proper coding style that does not pollute the Linux code I'd be willing to merge it. The emphasis is on non-intrusive minimalism. B. Ask Lennart to try to make his program portable. Nah, I will not work on this. Netlink is Linux specific -- it cannot be made on the legacy kernels, and I don't care for the legacy kernels anyway and won't spend time on them. Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630206: libnss-myhostname: FTBFS: fatal error: asm/types.h: No such file or directory
On Mon, 13.06.11 14:13, Robert Millan (r...@debian.org) wrote: tags 630206 patch thanks 2011/6/13 Robert Millan r...@debian.org: 2011/6/13 Lennart Poettering lenn...@poettering.net: I think it is a major waste of time thinking about BSD and Hurd. That said, I'd be willing to merge a patch that adds support for those legacy systems -- if it is minimal. Note however that it wouldn't be release critical to me, i.e. I will not care if it works or not when releasing a new version. But I geuss that doesn't matter much since it is quite a finished project and I expect very few updates in the future. Seems simple enough, I'll give it a try. Patch attached. To be applied after mv netlink.h ifconf.h. Sounds mostly good. Can you prep a proper git patch please? diff -Nur -x aclocal.m4 -x configure -x doc libnss-myhostname-0.3/ifconf.c libnss-myhostname-0.3.new/ifconf.c --- libnss-myhostname-0.3/ifconf.c1970-01-01 01:00:00.0 +0100 +++ libnss-myhostname-0.3.new/ifconf.c2011-06-13 14:06:34.0 +0200 @@ -0,0 +1,5 @@ +#ifdef __linux__ +#include netlink.c +#else +#include legacy.c +#endif Urks, no. Please do this in Makefile.am. diff -Nur -x aclocal.m4 -x configure -x doc libnss-myhostname-0.3/ifconf.h libnss-myhostname-0.3.new/ifconf.h --- libnss-myhostname-0.3/ifconf.h2011-05-09 15:00:58.0 +0200 +++ libnss-myhostname-0.3.new/ifconf.h2011-06-13 14:01:28.0 +0200 @@ -3,6 +3,8 @@ #ifndef foonetlinkhfoo #define foonetlinkhfoo Please fix the header here. +fd = socket (AF_INET6, SOCK_DGRAM, 0); Please follow the coding style, we do not place a space between the function name and the opening bracket. Also, this will obviously fail if IPv6 is not enabled. I personally don't care about that, but I am pretty sure the same kids who care about Hurd also care about IPv6-free systems. It's up to you if you want to fix this. I'd merge it either way. This gets particularly strange given that SIOCGIFCONF according to the (Linux) man page only returns IPv4 addresses. Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587961: [Pkg-utopia-maintainers] Bug#587961: avahi-daemon: patch for #517160 affects more than just reflector
On Sun, 11.07.10 10:44, Julien BLACHE (jbla...@debian.org) wrote: Michael Biebl bi...@debian.org wrote: Hi Michael, I just uploaded 0.6.26-1 which contains a fix for http://avahi.org/ticket/300 Could you please test if that also solves your particular issue and report back. Looking at the code again, the patch does the right thing and the code is now correct in its handling of link local addresses wrt reflector. The remaining issue is that avahi should be better at choosing the IPv4 address it sends back to the client when resolving a service. Working IPv4 LL is all but a given. I think avahi should not return an IPv4 LL address when a global address is also advertised if the host doesn't have a link local address configured on the interface avahi got the mDNS response from. Hmm, if I parse this correctly then you have two machines. One running some mDNS stack that's not Avahi which announces both an IPv4LL and a global address. And another one which runs Avahi and when contacting the first machine ends up using the IPv4LL address of the first one, and you dont want that to happen? Is that correct? Avahi tries to be smart with the addresses it announces, and it only announces one address at a timne, and picks the best local address it can find for that. (i.e. preferring gloabl addresses over IPv4LL if both are available). Now, for the A/ records it receives from other hosts it will just return to the resolving applications the first one the hosts sends. This is kinda mandated by the resolving scheme which basically says browse for an A/ record and return the first one you find. Or in other words: it should be the job of the announcer to pick the best address to announce, not the lookup client to pick the best address it finds. Because the former can have complete knowledge of what is available and the latter cannot. What really puzzles me though is why this is even a problem. Doesn't Debian set up the IP4VLL routes properly? i.e. see: http://avahi.org/wiki/AvahiAutoipd If those routes are in place it shouldn't matter much which address Avahi returns to the lookup clients, because all are equally usable. Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580183: [Pkg-utopia-maintainers] Bug#580183: pid file attack can be used to kill arbitrary processes
On Wed, 07.07.10 19:08, Joey Hess (jo...@debian.org) wrote: Lennart Poettering wrote: PID files are simply broken. We probably shouldn't use them anyway, and alway rely on the bus name instead. And the current situation is that, in Debian, avahi currently uses a pid file without even the arguably broken checks that start-stop-daemon makes. And, even if systemd eventually solves the problem for avahi, Debian has architectures where systemd will probably never run, but avahi does. Well, from my perspective this is barely fixable, and the right fix is using systemd. Also, I don't care von non-Linux systems really. If some people do care about about them, then it is them who need to come up with patches which when good I'll then merge. Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583624: libnss-myhostname: maybe use 127.0.1.1 to be consistent with Debian's default /etc/hosts
On Sat, 29.05.10 09:33, Joachim Breitner (nome...@debian.org) wrote: Dear Christoph, Dear Lennart, Am Samstag, den 29.05.2010, 00:45 +0200 schrieb Christoph Anton Mitterer: May I suggest to map to 127.0.1.1 for IPv4 instead of 127.0.0.2. This would be more consistent what Debian does per default in /etc/hosts. See also the Debian Reference Manual at: http://www.debian.org/doc/manuals/reference/ch05.en.html#_the_hostname_resolution thanks for the suggestion, Christoph. I’m replying to Lennart, the original author of nss-myhostname: Do you see and problem with making the default 127.0.1.1 on Debian? Do you mind if your software diverges in Debian somewhat? Hmm, I see no reason why 127.0.0.2 should be a better choice than 127.0.1.1, or vice versa. Can you come up with a reason? Given that one is as good as the other 127.0.0.2 looks a bit more straighforward to me, and I think that generally docs should be fixed to follow what the code does, not the other way round, so I'd probably vote for changing your manual, and keep the code in place. That said, I think this is really a minor issue, and I think it wouldn't be really that bad if debian would deviate here from the rest of the world. So go ahead with 127.0.1.1 if you want to and really don't want to fix the documentation instead. You have my blessing that that is OK. On top of that, if you can make up a good reason I'd be willing to change the upstream to 127.0.1.1, btw. So, convince me! Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580183: pid file attack can be used to kill arbitrary processes
On Tue, 04.05.10 01:30, Joey Hess (jo...@debian.org) wrote: Package: avahi-daemon Version: 0.6.25-3 Severity: normal Tags; security /var/run/avahi-daemon/pid is writable by the avahi user. Suppose this user is compromised. If the pid is overwritten with a different process id, such as 1, /etc/init.d/avahi-daemon stop will go ahead and kill that. Well, I am not too concerned with this issue tbh, given that this file is both outside the chroot and we set RLIMIT_FSIZE to 0. Which basically means that from inside Avahi you cannot write any file anyway, and particularly not that one... start-stop-daemon avoids this kind of security flaw by checking /proc/pid/exe (when run with -exec), or at least the process name (when run with -name). avahi's init script uses avahi -k. which neglects such checking. Well, both those checks can be easily fooled, they in fact do not improve security. Besides the (admittedly unlikely since if you can shell avahi you probably have better things to do) security hole, killing a process that is stored in a pid file without checking that the pid file is accurate is asking for trouble. PID files are simply broken. We probably shouldn't use them anyway, and alway rely on the bus name instead. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517160: [Fwd: [Pkg-utopia-maintainers] Bug#517160: Patch to partially correct this bug]
On Fri, 17.04.09 13:17, Michael Biebl (bi...@debian.org) wrote: Hi Lennart, Heya! attached is a patch from Rob Leslie which (partially) addresses http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517160 I've forwarded the patch as my mdns/ipv4ll experience is rather limited so I'd appreciate if you could review the patch. Except for the fact that it broke my build the patch is flawless. I have now fixed it and applied it upstream: http://git.0pointer.de/?p=avahi.git;a=commit;h=2ea7e99ed0dcfd371fef5aeecd3de77da1dfcd4f Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#477712: avahi: Please readd bssh to your packages
Package: avahi Severity: normal The newest avahi packages in Debian/unstable seem to come without bssh/vnc. This is a pity since those tools are exceptionally useful. I use them every day. Also, upstream received multiple patches for these tools already, so I am pretty sure I am not the only one who really loves this feature. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477714: avahi-daemon: Please disable IPv6 in the config file again
Package: avahi-daemon Version: 0.6.22-3 Severity: normal Avahi in Debian should *not* be enabling IPv6 support by default. Why not? - Brings no advantages. The intended audience for Zeroconf is desktop uses, normal people. People who don't care about IPv6. If people run IPv6 right now they surely should be capable of enabling support for it in Avahi by reconfiguring a single line in the config file, too. - Because it doubles the network load imposed by Avahi for no gain - Because it causes all services to show up twice in browsers: once via IPv6 and once via IPv4. - Because people might see these duplicates and thus might end up hardcoding their code to only register services via IPv4 instead of leaving the protocols to Avahi. Thus in the long run if the time comes to enable IPv6 by default you'd first have to fix all those apps. - Because it is a big deviation from how other distros do it. - Because I am upstream and I kindly ask you to disable it. Please, please, With cream on top! ;-) - Instead of enabling IPv6 support in Avahi in Debian prematurely you guys should first fix the remaining issues. - Because you guys don't follow my nicely figured out plan to adopt IPv6 in Avahi. (see below) The road to IPv6 for Avahi should be: - Implement some logic so that duplicates are filtered out from browse requests. This is harder than it sounds but would be very useful for multihomed hosts or hosts with VPNs, too. - Add a config option to selectively a) disable IPv6 completely b) register RRs via IPv4, but don't use IPv6 as addresses, c) register services by IPv4+IPv6 by default, leave browsing as IPv4-only d) register and browse for services with both protos e) register IPv6-only, but browse both. f) Use only IPv6 as proto, but still register A RRs on it. g) Only use IPv6. Right now we have a), b), f), g), d). We still lack c), and e). Then, every few years or so we should move from one step to the next. We're right now at b), you guys jumped to d) without going through c) first. The code for c)/e) is missing right now. Instead of skipping it someone needs to sit down and just write it. So please, for proper IPv6 support, fix the remaining issues first. And then do it in a sane way instead of doing the third step without having done the second. I'll will fix this eventually, when I find the time to and the issue is pressing enough. I am always happy to accept patches, if you guys want to speed this up. Also, let's not forget that there is not a single installation around which uses exclusively IPv6 these days. All IPv6 installations are multi-stack installations. Thus using IPv4 for link local service discovery is absolutely fine. Thanks, Lennart -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages avahi-daemon depends on: ii adduser 3.107 add and remove users and groups ii bind9-host [host] 1:9.4.2-10 Version of 'host' bundled with BIN ii dbus 1.2.1-1simple interprocess messaging syst ii libavahi-common3 0.6.22-3 Avahi common library ii libavahi-core50.6.22-3 Avahi's embeddable mDNS/DNS-SD lib ii libc6 2.7-10 GNU C Library: Shared libraries ii libcap1 1:1.10-14 support for getting/setting POSIX. ii libdaemon00.12-1 lightweight C library for daemons ii libdbus-1-3 1.2.1-1simple interprocess messaging syst ii libexpat1 1.95.8-4 XML parsing C library - runtime li ii lsb-base 3.1-24 Linux Standard Base 3.1 init scrip Versions of packages avahi-daemon recommends: ii libnss-mdns 0.10-3 NSS module for Multicast DNS name -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477715: /etc/localtime needs to be copied into the chroots of both avahi-daemon and avahi-autoipd
Package: avahi Severity: normal See https://bugzilla.redhat.com/show_bug.cgi?id=444043 for more info. That file needs to be copied before daemon startup. Can happen in the init script of avahi-daemon. The question however is where to do it for avahi-autoipd since there is no init script for it. I'd be happy to accept patches which do the copying from inside Avahi. Lennart -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466014: libnss-mdns: Replace mdns4* by mdns* in /etc/nsswitch.conf
On Thu, 20.03.08 19:16, Mike Hommey ([EMAIL PROTECTED]) wrote: So please support your point with better arguments. So, let's see what the README/web site of nss-mdns says about this problem: snip libnss_mdns.so.2 resolves both IPv6 and IPv4 addresses, libnss_mdns4.so.2 only IPv4 addresses and libnss_mdns6.so.2 only IPv6 addresses. Due to the fact that most mDNS responders only register local IPv4 addresses via mDNS, most people will want to use libnss_mdns4.so.2 exclusively. Using libnss_mdns.so.2 or libnss_mdns6.so.2 in such a situation causes long timeouts when resolving hosts since most modern Unix/Linux applications check for IPv6 addresses first, followed by a lookup for IPv4. /snip Avahi default, at least in debian, is to register IPv6 addresses. It's a Debian default. Not an Avahi default. And doing what Debian does with Avahi+IPv6 is a very bad idea, as I have told Sjoerd before. Also, I believe only the tiniest number of networks run exclusively Debian Unstable these days. You might not believe this, but there is this alternative operating system around, which is called Windows, and which enabled IPv6 at all only very recently, so this Bonjour thing cannot do IPv6 either when it is running of those machines. And let's not forget all those embedded devices like printers, cameras, routers, which do bonjour -- but without ipv6. But of course, my insight into all this fancy zeroconf stuff is rather limited, ya know? You of course, know much more about it, I figure. So, teach me. As for delays, they should be considered bugs as with the glibc. It's not a limitation in GLIBC. It's the stupid applications. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466014: libnss-mdns: Replace mdns4* by mdns* in /etc/nsswitch.conf
On Sat, 16.02.08 00:05, Mike Hommey ([EMAIL PROTECTED]) wrote: Version: 0.10-3 Severity: wishlist Please replace mdns4_minimal and mdns4 by, respectively, mdns_minimal and mdns by default in /etc/nsswitch.conf. No, don't! Why is that ? Try Google. Try reading docs. Try reading mailing list archives. This has been discussed a million times already on various places. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466014: libnss-mdns: Replace mdns4* by mdns* in /etc/nsswitch.conf
On Fri, 15.02.08 23:39, Mike Hommey ([EMAIL PROTECTED]) wrote: Package: libnss-mdns Version: 0.10-3 Severity: wishlist Please replace mdns4_minimal and mdns4 by, respectively, mdns_minimal and mdns by default in /etc/nsswitch.conf. No, don't! Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458358: distcc: Please merge Zeroconf patch
Package: distcc Version: 2.18.3 Severity: wishlist Please merge my Avahi/Zeroconf patch for distcc: http://0pointer.de/public/distcc.patch I took the time to update it today, here's the announcement: http://lists.freedesktop.org/archives/avahi/2007-December/001235.html I believe this patch is good enough to be merged into the Debian packages, even if upstream didn't do so yet. Back at LCA 2007 Martin Pool (distcc upstream) kind of promised me to merge the original patch. I guess that is as good as it gets since distcc maintainership upstream seems to be kind of dormant. So, please, merge the patch! Thank, Lennart -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434462: avahi-autoipd: fix for #426918 is bogus
Package: avahi-autoipd Version: 0.6.20-2 Severity: normal Hmm, the Check for the existance of link-local routes on all interfaces part of bug 426918 doesn't make any sense in my opinion, and its fix in 0.6.20-1 should be reversed. Unless the route is created on all interfaces, things will get borked if you have two cards. First you ifup the first one -- the link-local route is created. Then the second one -- the link-local route is not created due to the bogus fix. Now the first iface is ifdown'ed -- the link-local route goes away, and we are lost with no link-local route at all. I am not sure what exactly yields the warning that was reported in the original bug report, but I am quite sure that the fix used is not the right one. Lennart -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.20 (PREEMPT) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages avahi-autoipd depends on: ii adduser 3.104 add and remove users and groups ii libc6 2.6-2 GNU C Library: Shared libraries ii libdaemon00.12-0.1 lightweight C library for daemons Versions of packages avahi-autoipd recommends: pn dhcp3-client none (no description available) ii iproute 20070313-1 Professional tools to control the -- no debconf information -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] netICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433943: libnss-mdns: please change default nsswitch.conf line
Package: libnss-mdns Version: 0.10-3 Severity: normal Please drop the final mdns4 from the default nsswitch.conf line. While it is quite useful to enable proper reverse lookups on non-link-local addresses it also has the big drawback that if there is neither avahi nor classic dns set up for an IP address this module has to timeout before the reverse lookup can fail. This becomes a problem because many programs freeze during these lookups, one being ssh on every single incoming connection. Since Avahi is intended to be a zero configuration system, one that just works, this means that it is preferable to guarantee that we don't break on any system, even when this means that a certain amount of functionality is lost. Unfortunately I don't know any better solution for this mess than just dropping mdns4 from the line. In effect the line to use should look like this: hosts: files mdns4_minimal [NOTFOUND=return] dns I already made a similar change in the Fedora packages. Lennart -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/2 CPU cores) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages libnss-mdns depends on: ii avahi-daemon 0.6.19-2 Avahi mDNS/DNS-SD daemon ii base-files4.0.0 Debian base system miscellaneous f ii libc6 2.6-2 GNU C Library: Shared libraries ii perl 5.8.8-7Larry Wall's Practical Extraction libnss-mdns recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433945: avahi-daemon: .local in unicast detection not perfect
Package: avahi-daemon Version: 0.6.19-2 Severity: normal The .local-in-unicast-dns detection is not perfect. Apparently some IP routers do not properly respond to SOA queries if asked for non-existing domains. One example being the WLAN router of the ETAP hotel here at GUADEC in Birmingham. This router has a catchall DNS set up and sometimes responds with an A RR if asked for a SOA RR. This has the unfortunate effect that the query doesn't fail and the check script wrongly assumes that there is a unicast DNS domain called .local while there actually is not. The host command seems not to check whether the data in a DNS response packet actually matches the data in the DNS query packet. To work around this the check script should check if the output of host actually includes real SOA data. OTOH there are a couple of unicast DNS set ups around where RR definitions reside in a subhierarchy of .local, i.e. foo.bar.local instead of just foo.local. If bar.local itself does not exist in the DNS zone files this case is not detect as .local in unicast DNS cases, while it actually should. I would suggest checking the domain and search lines from resolv.conf for domains ending with .local. If so, treat this as a .local in unicast DNS case. Presumably if people have set up unicast .local domains they also specify them in the DNS search domains. A check like this would also have the big advantage that a couple of superfluous DNS queries (which might timeout, ...) can be skipped in many cases. Lennart -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/2 CPU cores) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages avahi-daemon depends on: ii adduser 3.103 Add and remove users and groups ii dbus 1.1.1-3simple interprocess messaging syst ii libavahi-common3 0.6.19-2 Avahi common library ii libavahi-core50.6.19-2 Avahi's embeddable mDNS/DNS-SD lib ii libc6 2.6-2 GNU C Library: Shared libraries ii libcap1 1:1.10-14 support for getting/setting POSIX. ii libdaemon00.10-1 lightweight C library for daemons ii libdbus-1-3 1.1.1-3simple interprocess messaging syst ii libexpat1 1.95.8-3.4 XML parsing C library - runtime li ii lsb-base 3.1-23.1 Linux Standard Base 3.1 init scrip Versions of packages avahi-daemon recommends: ii libnss-mdns 0.10-3 NSS module for Multicast DNS name -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432719: iodine: security improvements
Package: iodine Version: 0.4.0-1 Severity: normal Because the password is stored in /etc/default/iodine please make sure to install this file with 600 access mode. Also, please modify iodine/iodined to XXX out the password passed to it via the command line. This is not a perfect but certainly substantial security improvement because it makes the password not show up in most ps xawww calls. memset(argv[n], 'X', strlen(argv[n])) shold do the job in n is the argument number with the password. Thanks, Lennart -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages iodine depends on: ii adduser 3.102 Add and remove users and groups ii debconf [debconf-2.0] 1.5.13 Debian configuration management sy ii libc6 2.5-9+b1 GNU C Library: Shared libraries ii makedev 2.3.1-83 creates device files in /dev ii zlib1g1:1.2.3-13 compression library - runtime iodine recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432719: iodine: security improvements
On Wed, 11.07.07 18:27, gregor herrmann ([EMAIL PROTECTED]) wrote: memset(argv[n], 'X', strlen(argv[n])) shold do the job if n is the argument number with the password. I've already contacted upstream about this proposal. BTW: It would be awsome if iodine would be able to parse /etc/resolv.conf on its own. This would greatly simplify its use. Lennart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423692: indent: option -brf not documented
Package: indent
Version: 2.2.9-8
Severity: normal
Unfortunately neither the man page nor texinfo mentions the very useful
-brf switch, which aligns functions this way:
int main() {
}
instead of
int main()
{
}
I had to ask Lazyweb to learn about this switch:
http://0pointer.de/blog/projects/cuddle-function.html
Lennart
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.20 (PREEMPT)
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
Versions of packages indent depends on:
ii libc6 2.5-7 GNU C Library: Shared libraries
indent recommends no packages.
-- no debconf information
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] netICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422876: emacs-goodies-el: please include show-wspace.el
Package: emacs-goodies-el Version: 26.10-1 Severity: wishlist Please include show-space.el in your package: http://www.emacswiki.org/cgi-bin/wiki/show-wspace.el It is very, very useful when preparing patches for the Linux kernel due to their strict regulations on tab and whitespace use. Thanks, Lennart -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-gb7405e16-dirty (PREEMPT) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages emacs-goodies-el depends on: ii bash 3.1dfsg-8 The GNU Bourne Again SHell ii emacs21 [emacsen] 21.4a+1-5 The GNU Emacs editor Versions of packages emacs-goodies-el recommends: ii dict 1.10.2-3.1 Dictionary Client pn perl-doc none (no description available) ii wget 1.10.2-2 retrieves files from the web -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412089: trackerd eats 100% CPU and does nothing, tracker-search-tool freezes when searching
On Tue, 27.02.07 00:02, Michael Biebl ([EMAIL PROTECTED]) wrote: [1] tracker is compiled with inotify support but falls back to polling if it hits the 4096 limit. Argh, my memory didn't server me well, the default limit actually is 8192 [1]. Could you also please send me the log file ~/.Tracker/tracker.log [2]. Humm. That contains company data. I'd prefer not to. Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412089: trackerd eats 100% CPU and does nothing, tracker-search-tool freezes when searching
On Mon, 26.02.07 23:06, Michael Biebl ([EMAIL PROTECTED]) wrote: Sorry for the late response. Lennart Poettering wrote: Package: tracker Version: 0.5.4-4 Severity: normal trackerd has been running for ages on my machine now, and apparently doesn't do much except calling poll() and gettimeofday(): You are probably hitting a limitation of inotify. By default you can't monitor more than 4096 instances(directories) [1] with inotify. Can you confirm that this is the case for you? Yepp. That seems to be it. I wonder if you're supposed to use inotify for so many inodes at the same time. Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422368: /etc/avahi/etc/localtime keeps changing during boot
On Sat, 05.05.07 14:40, Michael Tautschnig ([EMAIL PROTECTED]) wrote: Package: avahi-daemon Version: 0.6.16-3etch1 Severity: important Justification: Violates policy/FHS Upon startup, the following code is executed by /etc/init.d/avahi-daemon: if [ -s /etc/localtime ]; then if [ ! -d /etc/avahi/etc ]; then mkdir -p /etc/avahi/etc /dev/null 21 fi cp -fp /etc/localtime /etc/avahi/etc /dev/null 21 fi; The mkdir and cp operations, apart from being very very strange, violate the FHS implication of /etc/ being static. Maybe there is some upstream bug that expects to find localtime in /etc/avahi/etc/localtime, but in any case this could be easily worked around by creating /etc/avahi/etc and a symlink to /etc/localtime within the postinst script. IMHO. Just a few notes as Avahi upstream maintainer: symlinking this will *not* work. avahi-daemon chroot()s to that directory, i.e. wouldn't be able to followup the symlink. That locatime modification is Debian specific. The other distros don't have it. The bug might have gone away with libc 2.5. Also, calling tzset() before chroot()ing might be a way to work around this. I am now a RH employee, using Fedora on my desktop machines, hence I am unable to test this right now. Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412247: RFP: winpdb -- An Advanced Python Debugger
Package: wnpp Severity: wishlist * Package name: winpdb Version : 1.0.8 Upstream Author : Nir Aides * URL : http://www.digitalpeers.com/pythondebugger/ * License : GPL Programming Lang: Python Description : An Advanced Python Debugger Quoting the homepage: snip Winpdb is a GPL python debugger, with support for smart breakpoints, multiple threads, namespace modification, embedded debugging, password encrypted communication and speed of up to 20 times that of pdb. /snip Last but not least it has a nice wxPython GUI. Lennart -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412089: trackerd eats 100% CPU and does nothing, tracker-search-tool freezes when searching
Package: tracker
Version: 0.5.4-4
Severity: normal
trackerd has been running for ages on my machine now, and apparently
doesn't do much except calling poll() and gettimeofday():
gettimeofday({1172239801, 585283}, NULL) = 0
gettimeofday({1172239801, 585410}, NULL) = 0
poll([{fd=11, events=POLLIN}, {fd=13, events=POLLIN}, {fd=14, events=POLLIN}],
3, 1) = 0
gettimeofday({1172239801, 586140}, NULL) = 0
gettimeofday({1172239801, 586254}, NULL) = 0
poll([{fd=11, events=POLLIN}, {fd=13, events=POLLIN}, {fd=14, events=POLLIN}],
3, 0) = 0
gettimeofday({1172239801, 586673}, NULL) = 0
poll([{fd=11, events=POLLIN}, {fd=13, events=POLLIN}, {fd=14, events=POLLIN}],
3, 349) = 0
gettimeofday({1172239801, 935215}, NULL) = 0
gettimeofday({1172239801, 935343}, NULL) = 0
poll([{fd=11, events=POLLIN}, {fd=13, events=POLLIN}, {fd=14, events=POLLIN}],
3, 0) = 0
gettimeofday({1172239801, 935588}, NULL) = 0
poll([{fd=11, events=POLLIN}, {fd=13, events=POLLIN}, {fd=14, events=POLLIN}],
3, 350) = 0
gettimeofday({1172239802, 285154}, NULL) = 0
gettimeofday({1172239802, 285282}, NULL) = 0
That's the output of strace -p $(pidof trackerd) and goes on like this
forever
trackerd could win a prize for wasting resources - waking up all 350ms
for nothing?
If I enter a search term in tracker-search-tool the GUI freezes for
a few minutes or so - and then wakes up again - finding exactly
nothing, regardless what I enter as search term - even if I look for
something really, really common.
Are you sure this software is ready enough for inclusion in Debian?
Lennart
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages tracker depends on:
ii dbus 1.0.2-1simple interprocess messaging syst
ii libc6 2.3.6.ds1-11 GNU C Library: Shared libraries
ii libdbus-1-3 1.0.2-1simple interprocess messaging syst
ii libdbus-glib-1-2 0.73-1 simple interprocess messaging syst
ii libexif12 0.6.13-5 library to parse EXIF files
ii libglib2.0-0 2.12.9-2 The GLib library of C routines
ii libgmime-2.0-22.2.3-3MIME library, unstable version
ii libgsf-1-114 1.14.3-1 Structured File Library - runtime
ii libgstreamer0.10-00.10.10-2 Core GStreamer libraries and eleme
ii libmagic1 4.17-5 File type determination library us
ii libpango1.0-0 1.14.8-5 Layout and rendering of internatio
ii libpng12-01.2.15~beta5-1 PNG library - runtime
ii libpoppler0c2-glib0.4.5-5.1 PDF rendering library (GLib-based
ii libsqlite3-0 3.3.8-1SQLite 3 shared library
ii shared-mime-info 0.19-2 FreeDesktop.org shared MIME databa
ii zlib1g1:1.2.3-13 compression library - runtime
Versions of packages tracker recommends:
pn o3readnone (no description available)
ii tracker-search-tool 0.5.4-4metadata database, indexer and sea
ii tracker-utils 0.5.4-4metadata database, indexer and sea
pn untex none (no description available)
ii unzip 5.52-9 De-archiver for .zip files
pn w3m none (no description available)
pn wvnone (no description available)
ii xpdf-utils [poppler-utils]3.01-9 Portable Document Format (PDF) sui
ii xsltproc 1.1.19-1 XSLT command line processor
-- no debconf information
--
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393608: libnss-mdns: Edits nsswitch.conf, throwing away my changes
On Fri, 12.01.07 12:59, Loïc Minier ([EMAIL PROTECTED]) wrote:
Hi!
Sorry for the late response. I have just come back from .au and still
am eating thhrough 800+ non-spam mails, which arrived since I left.
On Fri, Jan 12, 2007, Lennart Poettering wrote:
Short: If built with --enable-legacy nss-mdns is only half-way IPv6
capable. If built with --disable-legacy nss-mdns is fully IPv6 capable.
Thanks!
So is there any difference between
/usr/lib/libnss_mdns{,4,6}{,_minimal}*so.2 with --disable-legacy?
Yes.
the moudle name suffix 4, 6, or specifies the family of the addresses
that
are resolved. i.e. specifies whether A, or both RRs should be
looked for.
If --enable-legacy is passed, than only IPv4 UDP packets will be used
for resolving - unless avahi-daemon is found in which case also IPv6
UDP packets are used.
If --disable-legacy is passed nss-mdns relies exclusively on
avahi-daemon and thus both IPv4 UDP and IPv6 UDP is used (depending on
the daemon config).
The _minimal just modifies the behaviour for host names not ending
in .local and addresses not starting with 169.254/fe80::.
Yeah, I know, it's confusing. ;-)
The major issue is to understand that you can resolve A records via
both IPv4 and IPv6 and the same is true for records. A records
are address records for IPv4, and are records for IPv6 addresses.
Is that cleared up now?
Greetings from Sydney (where linux.conf.au will start in a few days).
Happy conferencing!
The conferences have been awesome! Rock! Rock! Rock! ;-)
if you are interested you can watch Trent's and my Avahi talk at lca:
http://mirror.linux.org.au/linux.conf.au/2007/video/monday/monday_1150_GNOME.ogg
(Theora)
http://0pointer.de/public/avahi-presentation-lca2007.pdf
And another one of me talking about PulseAudio:
http://mirror.linux.org.au/pub/linux.conf.au/2007/video/talks/211.ogg (Theora)
http://0pointer.de/public/pulseaudio-presentation-lca2007.pdf
Have fun!
Lennart
--
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
Bug#393711: Authoritative .local support in nss-mdns / avahi-daemon
On Sun, 24.12.06 22:09, Loïc Minier ([EMAIL PROTECTED]) wrote: Hi! I just uploaded a nss-mdns NMU which I think addresses the RC issues of this particular package. One of the major changes is that it now requires avahi-daemon to resolve .local entries. IIUC, the proper way to support networks where .local is a real domain name is to disable avahi-daemon when a nameserver claims to have a SOA for the .local domain. This check should be made everytime the DNS settings change and on boot, so I think the simplest way is to: 1) check whether there's a SOA for .local before starting avahi-daemon, and do not really start it when a start was requested but a SOA was found 2) restart avahi-daemon in a dhclient hook to make sure the test is run with the new DNS settings 3) restart avahi-daemon in a resolvconf hoook to make sure the test is run with the new DNS settings The dhclient hook should not be run if resolvconf is installed - because otherwise the hook script might be run twice! The Ubuntu script just silently stops Avahi. This is suboptimal, the user should get some feedback about this. Notifications with the DBUS notification-daemon would be a good thing. Unfortunately, that daemon is solely a session daemon, i.e. it's service cannot be used from a system script. :-( An alternative would be syslog: /snip if test -x /usr/bin/logger ; then logger -p daemon.warning -t avahi EOF Avahi detected that your currently configured local DNS server serves a domain .local. This is inherently incompatible with Avahi and thus Avahi disabled itself. If you want to use Avahi in this network, please contact your administrator and convince him to use a different DNS domain, since .local should be used exclusively for Zeroconf technology. EOF fi /snip Or something like that. Perhaps we should add a page to our avahi.org wiki and explain the situation there and link it from that syslog message. I wish you all a Merry Christmas! And if you need to catch me, you can I wish you a happy new year! Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
Bug#399234: comment in init script is bogus
Package: avahi-daemon Version: 0.6.15-2 Severity: minor A comment in /etc/init.d/avahi-daemon says: # don't start if /etc/avahi-daemon says so. this is wrong. it should say: # don't start if /etc/default/avahi-daemon says so. Lennart -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages avahi-daemon depends on: ii adduser 3.99Add and remove users and groups ii dbus 0.94-2 simple interprocess messaging syst ii libavahi-common3 0.6.15-1Avahi common library ii libavahi-core4 0.6.15-1Avahi's embeddable mDNS/DNS-SD lib ii libc62.3.6.ds1-7 GNU C Library: Shared libraries ii libcap1 1:1.10-14 support for getting/setting POSIX. ii libdaemon0 0.10-1 lightweight C library for daemons ii libdbus-1-3 0.94-2 simple interprocess messaging syst ii libexpat11.95.8-3.3 XML parsing C library - runtime li Versions of packages avahi-daemon recommends: ii libnss-mdns 0.8-5 NSS module for Multicast DNS name -- no debconf information -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399293: base-files: please ship /etc/networks and include link-local 169.254.0.0 to it
Package: base-files Version: 4 Severity: wishlist Hi! Please ship /etc/networks in base-files and include the following single line in it: link-local 169.254.0.0 If defined like this tools like route will show the string link-local for the IPv4LL route created by packages like avahi-autoipd, zeroconf or zcip. The string link-local instead of the numeric 169.254.0.0/24 should be less confusing for users if they encounter these routes after installing one of the aforementioned packages. The network 169.254.0.0/16 for link-local usage is defined in RFC3927. Lennart -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages base-files depends on: ii base-passwd 3.5.11 Debian base system master password ii gawk [awk]1:3.1.5.dfsg-4 GNU awk, a pattern scanning and pr ii mawk [awk]1.3.3-11 a pattern scanning and text proces base-files recommends no packages. -- no debconf information -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393711: libnss-mdns: /etc/nsswitch.conf configuration is broken
for anything but ll addressing is as stupid as using ::1 or 127.0.0.1 on eth0. Perhaps it makes sense to run such a test suite on IPv4 and IPv6 separately, in order to turn on mDNS for one or the other or both (or to leave it off). Part 2) could typically be a /etc/default/libmdns file with MDNS_BACKWARD_COMPATIBILITY=0 or 1. In the abscence of this file, cached debconf responses would be used, and in the abscence of these, the default value would be computed with the test suite, and if debconf is at low priority, the user would get a debconf screen to override the guess. As mentioned above, /etc/default/avahi-daemon can be used for this if nss-mdns is compiled with --disable-legacy. Part 3) could typically be offered by an enable-mdns script or similar, as I believe is nowadays found under Ubuntu to enable mDNS. This script would simply enforce whatever /etc/default/libmdns has, or follow command line options. This script could also serve as a lower-level force turning off mDNS or force turning on mDNS administrative tool. This script could also be called for part 1), this would permit re-running the auto-detection. /etc/default/avahi-daemon also solves this. Obvious problem of the proposal: roaming users with laptops. These people should decide to either use .local for mDNS or for one of their site. The resolvconf hook solves this issue. Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
Bug#399297: libnss-mdns: Please build with --disable-legacy
Package: libnss-mdns Version: 0.8-5 Severity: wishlist Please build libnss-mdns by default with --disable-legacy, i.e. disabling the internal mini-stack included in stock nss-mdns. If required build an alternative version with --enable-legacy, maybe called libnss-mdns-legacy with the mDNS mini-stack activated. A discussion why this is a good idea (security) and what --disable-legacy is actually about has been included in this thread: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393711 The only reasons I see why people would want to use the mini-stack (i.e. --enable-legacy) are: 1. usage in conujunction with a different mDNS daemon implementation, 2. usage in an embedded system where avahi-daemon would not fit in, 3. usage of mdns host names during boot before avahi-daemon is started (i.e. NFS shares). Since Debian only ships Avahi reason #1 shouldn't cound. Embedded people should be able to compile their own versions of libnss-mdns, hence #2 is invalid. #3 might be a real problem, however people mounting NFS shares by mdns host names look for trouble anyway. In addition this problem can be overcome by fiddling with the init script order. Thanks, Lennart -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages libnss-mdns depends on: ii base-files 4 Debian base system miscellaneous f ii libc62.3.6.ds1-7 GNU C Library: Shared libraries libnss-mdns recommends no packages. -- no debconf information -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394328: kdnssd: Please suggest avahi-autoipd instead of zeroconf
Package: kdnssd Version: 4:3.5.5-1 Severity: wishlist Hi! Please consider changing the Suggests: zeroconf into a Suggests: avahi-autoipd (or possibly Suggests: avahi-autoipd | zeroconf). avahi-autoipd is a more advanced implementation of IPv4LL than zeroconf. The major advantage is that it works as plugin for dhclient and becomes active only when DHCP is not available. Lennart -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages kdnssd depends on: ii kdelibs4c2a 4:3.5.5a-1 core libraries and binaries for al ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-13 GCC support library ii libnss-mdns 0.8-5 NSS module for Multicast DNS name ii libstdc++6 4.1.1-13The GNU Standard C++ Library v3 Versions of packages kdnssd recommends: ii avahi-daemon 0.6.13-3 Avahi mDNS/DNS-SD daemon -- no debconf information -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394329: education-standalone: please suggest avahi-autoipd instead of zeroconf
Package: education-standalone Severity: wishlist Please consider changing the Suggests: zeroconf into a Suggests: avahi-autoipd (or possibly Suggests: avahi-autoipd | zeroconf). avahi-autoipd is a more advanced implementation of IPv4LL than zeroconf. The major advantage is that it works as plugin for dhclient and becomes active only when DHCP is not available. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394330: avahi-autoipd: package description is bogus
Package: avahi-autoipd Severity: normal Seems the package description of avahi-dnsconfd has been copied blindly to avahi-autoipd, since it says Avahi DNS configuration tool, which is clearly bogus. Lennart -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393711: libnss-mdns: /etc/nsswitch.conf configuration is broken
Package: libnss-mdns Version: 0.8-6 Severity: serious Hi! The configuration that is patched into /etc/nsswitch.conf by libnss-mdns 0.8-6 is just plain broken and against everything upstream (who happens to be me) or any other person who has any clue about mDNS recommends. The line upstream suggests looks like this: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 This line resembles closely the behaviour MacOSX - the OS which pioneered mDNS - exposes. Everything else is much worse in its behaviour. In contrast, the line your package version adds has several disadvantages, among them: * Slows down all mDNS lookups * Breaks mDNS lookups when the configured DNS server is not reachable (!) * Is a security hole, because local host info is leaked on unicast dns server and as such the internet * Is a security hole, because people on the internet can redirect local services to other hosts * Increases the burden on internet DNS servers needlessly. (This is a major problem which caused the creation of projects like AS112) * Breaks mDNS RR consistency because the unicast DNS zone .local is kind-of merged with the multicast DNS zone .local. However, the conflict protocol which makes sure that no two host names or service names conflict in the .local zone simply doesn't work against names from the .local unicast domain. In short: while upstream proposes a sensible, working line, your package pointlessly fucks it up and is thus simply broken. Sure, the line upstream recommends has also one disadvantage, which is that it is inherently incompatible with unicast DNS domains called .local. But that's the way mDNS has been designed, and is a simple fact that has to be dealt with administratively and not through applying ugly kludges to upstream's clean code. For further discussion see bug #388864 where many points mentioned above were already discussed. Several people showed interest in maintaining nss-mdns in Debian. As you seem to give a fuck about upstream's technical opinion on these issues or even on the opinions of the mDNS/DNS-SD *designers*, and it is clear that your relationship to upstream is not the best, may I suggest that you simply orphan this package and have someone else looking after it? I am fully aware that you happen to have access to a network where .local is a unicast domain name. Due to this you seem to value compatiblity with that network more than correct behaviour of mDNS. However, Debian is not just about you, but about its users - all of them. If you insist that your line is the better one and refuse to change it to the line I recommend and don't want to orphan the package, then I kindly ask you to fork my package and rename your copy. And please don't put mdns in the new package name, since the behaviour you advocate is clearly not the standard mDNS behaviour. Please understand that I don't want to be connected to the broken behaviour your nss-mdns package exposes any longer. Lennart -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages libnss-mdns depends on: ii base-files 3.1.16 Debian base system miscellaneous f ii libc62.3.6.ds1-4 GNU C Library: Shared libraries libnss-mdns recommends no packages. -- no debconf information -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392813: looking at this bug..
On Sat, 14.10.06 23:11, Walter Hofmann ([EMAIL PROTECTED]) wrote: DO NOT USE search local UNLESS YOU REALLY KNOW WHAT YOU DO! And if you do use it, don't file bugs about it. I am fully aware that it is problematic. I read between the lines that the .local domain is something special for nss-mdns!? Yes, that's exactly the case. .local is the multicast DNS domain. All host names ending in .local are resolved exclusively via mDNS if nss-mdns is installed. But I definitely need search local in resolv.conf. Otherwise, random services on this machine will break because I didn't enter the fqdn in many places. I guess then you should disable or deinstall nss-mdns. But somehow, problably due to some dependency or recommendation, nss-mdns got installed on my system and gets in bind's way. So whether nss-mdns does or doesn't support search local is of no concern to me -- I just doesn't want it to interfere with my otherwise working setup. I am sorry, but I guess your setup is simply incompatible with Zeroconf/Bonjour/Rendezvous/mDNS/DNS-SD/Avahi. If you cannot fix your setup to use a different unicast DNS domain, then I guess you should probably deinstall Avahi and nss-mdns, or a least disable it. It won't work reliable in such a setup. Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388864: Stop! Wait!
many mDNSResponders and HOWLs - and of course old Avahi installations - around. Please be patient with this! The first step should be to get all servers to register IPv6 addresses by default, and the second step should be to get the clients upgraded as well. Not the other way round. I now filed a ticket on avahi.org: http://avahi.org/ticket/62 Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#204641: please add ipv4ll routes for every interface
Hi! When zeroconf/ipv4ll support is added to ifupdown It would be advisable to also add special ipv4ll routes to every interface regardless whether ipv4ll is actually configured or not: route add -net 169.254.0.0 netmask 255.255.0.0 dev $IFACE metric 99 route add default dev $IFACE metric 99 These special routes allow communication between ipv4ll and non-ipv4ll hosts without difficulties. These routes should be added to *all* interfaces and in all cases! This can easily be implemented by just sticking a shell fragment into /etc/network/if-up.d/ipv4ll-routes with the two lines mentioned above. For a discussion of these routes, please read: http://avahi.org/wiki/AvahiAutoipd#Routes http://developer.apple.com/qa/qa2004/qa1357.html http://lists.freedesktop.org/archives/avahi/2006-September/000878.html Thank you very much, Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392813: looking at this bug..
On Sat, 14.10.06 15:59, Joey Hess ([EMAIL PROTECTED]) wrote: Seems my last mail crossed yours on the way. Part of the problem is that your /etc/resolv.conf has search local. This means that every dns lookup is first tried in the local domain, so it's trying to look up google.com.local. If I configure my system the same, with search local and avahi disabled, I can get similar results: Could nss-mdns be changed to check for a resolv.conf with search local and somehow avoid all the unnecessary mdns queries for every (!!) dns lookup that are entailed? Or maybe it could return immediately for domains like google.com.local while doing its thing for foo.local? Don't use search local. It will always produce problems like this one. (I'd like to be able to put search local in my resolv.conf, for networks that don't have any other dns than mdns, so it seems like a legitimate thing to want to do.) As I already wrote in my last email, the search local is indeed the problem. It is explicitly *not recommended* to use search local. If people choose to use it it's their problem. search local has lots of problems. This one is only one of them. The search local functionality is *only* useful in setups where traditional DNS is not used *at all*. In all other cases, don't use it, it causes all kinds of problems and will slow down all lookups. I am really surprised that so many people actually make use this configuration option. I never documented it for nss-mdns. Only a minor entry in my changelog even mentions it. To stress this once more: DO NOT USE search local UNLESS YOU REALLY KNOW WHAT YOU DO! And if you do use it, don't file bugs about it. I am fully aware that it is problematic. (Yes, this particular problem is fixable, and I will eventually do so, but it's low-priority to me) Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388864: [EMAIL PROTECTED]: Stop! Wait!]
On Wed, 04.10.06 21:48, Joey Hess ([EMAIL PROTECTED]) wrote: Here's my updated patch. Hmm, I don't remember if I already replied to this. Anyway: the new patch looks fine to me. Thanks for gviving nss-mdns your love! ;-) Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392222: purging pcmcia-cs after installation of pcmciautils breaks PCMCIA
Package: pcmciautils Severity: normal When I purged pcmcia-cs after installing pcmciautils /etc/pcmcia/config.opts was silently removed. However that file is required to correctly initialize the PCMCIA bridge. This was an older testing - newer testing upgrade. Unfortunately I currently don't have access to the the machine where this happened. And I am unable to recover which pcmcia-cs version it was that did these things. (If you need the pcmciautils version I used, that I can recover, just ask) It's not clear to me if this is a bug in pcmciautils or one in pcmcia-cs. As already discussed by personal email I'd like to suggest using /usr/share/pcmciautils/config.opts as fallback if /etc/pcmcia/config.opts is not existant. That way the problem discussed abovce would not have bitten me. In addition upgrades to that file would be easier and a little bit of disk space is saved. Lennart -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391924: avahi-autoipd: Recommends: is bogus
Package: avahi-autoipd Version: 0.6.14-1 Severity: normal In Recommends: s/dhclient/dhcp3-client/ Lennart -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391925: dhcp3-client: please include avahi-autoipd in Suggests:
Package: dhcp3-client Version: 3.0.4-8 Severity: wishlist Hi! avahi-autoipd acts as plugin for dhcp3-client by default. As such it adds IPv4LL support as fallback when DHCP fails. IPv4LL is a protocol for server-less assigning of IP addresses from the link-local range 169.254.0.0/16. IPv4LL was previously also known as APIPA. As such it has been supported by Windows since Win98 times and in MacOS since release 9. IPV4LL is defined in IETF RFC3927. It would be really nice if Debian would offer the same level of technology as Windows/MacOS do, and hence I ask you to add a Suggests: avahi-autoipd to your dhcp3-client packages, or perhaps even a Recommends: avahi-autoipd. Lennart -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages dhcp3-client depends on: ii debconf [debconf-2.0]1.5.5 Debian configuration management sy ii debianutils 2.17Miscellaneous utilities specific t ii dhcp3-common 3.0.4-8 Common files used by all the dhcp3 ii libc62.3.6.ds1-4 GNU C Library: Shared libraries dhcp3-client recommends no packages. -- debconf information excluded -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#204641: avahi-autoipd support would be nice, too
Hi! Much like ifupdown may currently handle more than a single DHCP implementation, ifupdown should also support more than a single IPV4LL/APIPA (aka Zeroconf) implementation. Currently in Debian we have these implementations: avahi-autoipd zcip zeroconf I would suggest using avahi-autoipd as first choice, then zeroconf, and finally zcip. Why? Because avahi-autoipd is clearly the most powerful one and zeroconf is second. Since avahi-autoipd installs itself by default as plugin for dhcp3-client to be used as fallback if DHCP is not available, I would suggest adding ipv4ll as method for configuration, and not activate it from ifupdown if dhcp was configured. (like the original bug reporter suggested). Oh, and please make sure *not* to name the method zeroconf. Please use the name ipv4ll. Zeroconf is actually the name for a set of technologies, and IPv4ll is only one of them. (The others being mDNS and DNS-SD). Thanks, Lennart (who might be a little biased, since he's upstream of avahi-autoipd) -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388864: [EMAIL PROTECTED]: Stop! Wait!]
On Wed, 04.10.06 19:02, Joey Hess ([EMAIL PROTECTED]) wrote:
A few comments regarding your patch:
--- old/nss-mdns-0.8/debian/postinst 1969-12-31 19:00:00.0 -0500
+++ nss-mdns-0.8/debian/postinst 2006-10-04 18:58:41.0 -0400
@@ -0,0 +1,23 @@
+#!/bin/sh
+set -e
+#DEBHELPER#
+
+if [ $1 = configure ] [ -e /etc/nsswitch.conf ]; then
+ if [ -z $2 ] || dpkg --compare-versions $2 le 0.8-4.1; then
+ perl -i -pe '
+ sub insert {
+ my @bits=split( , shift);
+ if (grep { $_ eq mdns4_minimal || $_ eq
mdns4
+ || $_ eq mdns || $_ eq mdns_minimal
} @bits) {
There's also mdns6 and mdns6_minimal for those IPv6-only-maniacs. You
might want to check for them here, too.
BTW, is this fragment executed on package upgrades, too? Would definitely make a
lot of sense.
+ return join , @bits;
+ }
+ @bits = map {
+ $_ eq files ?
($_,mdns4_minimal,[NOTFOUND=return]) : $_
+ } @bits;
+ push @bits, mdns4;
Hmm. I think it would be a better idea to use dns as the single
anchor for our changes, instead of files and for the end of the
list. Why? Because DNS is the reason I split mdns4_minimal from mdns4
in the first place. I didn't document this anywhere but the placement
rules for the two modules are:
1. put mdns4_minimal [NOTFOUND=return] somewhere before dns
2. put mdns4 somwhere after dns
In effect this makes no difference for the resulting file if the
original nsswitch.conf was still the default. However, if it wasn't
(i.e. due to usage of LDAP or any other nss module) this might make a
difference.
My suggestion:
@bits = map {
$_ eq dns ? (mdns4_minimal,[NOTFOUND=return],$_,mdns4) : $_
} @bits;
And it is shorter, too!
+ return join , @bits;
+ }
+ s/^(hosts:\s+)(.*)/$1.insert($2)/e;
+ ' /etc/nsswitch.conf
+ fi
+fi
diff --new-file -ur old/nss-mdns-0.8/debian/postrm nss-mdns-0.8/debian/postrm
--- old/nss-mdns-0.8/debian/postrm1969-12-31 19:00:00.0 -0500
+++ nss-mdns-0.8/debian/postrm2006-10-04 18:56:45.0 -0400
@@ -0,0 +1,18 @@
+#!/bin/sh
+set -e
+#DEBHELPER#
+
+if [ $1 = purge ] [ -e /etc/nsswitch.conf ]; then
+ perl -i -pe '
+ sub remove {
+ my @bits=grep { $_ ne mdns4_minimal
+ $_ ne mdns4
+ $_ ne mdns_minimal
+ $_ ne mdns
+ $_ ne [NOTFOUND=return] }
I am no Perl guru. However, as I understand this, you strip all
occurances of [NOTFOUND=return] from the line. That is a really bad
idea. That syntax might appear in other contexts too, since it is just
a string to make sure that the previously called NSS module is made
authoritative. That might be used by LDAP setups and others, too,
not just nss-mdns.
The strings you should remove are these:
mdns4_minimal [NOTFOUND=return]
mdns4_minimal
mdns4
mdns6_minimal [NOTFOUND=return]
mdns6_minimal
mdns6
mdns_minimal [NOTFOUND=return]
mdns_minimal
mdns
(In that order!)
Otherwise I am very happy with your patch.
Lennart
--
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388864: Stop! Wait!
Hi! I am not that happy with the suggested postinst script. Two things: First, please use mdns4 and mdns4_minimal modules instead of mdns and mdns_minimal. Why? Because many broken programs (one of them being telnet) do host name lookups in a broken way: they first try an ipv6 lookup and if that fails fall back to ipv4. In mDNS host name lookups for nonexistant host names take a long time to timeout. In a network where only IPv4 names are published this will cause these tools to take many seconds to do a connection to an mDNS name if the host didn't registers both ipv6 and ipv4 names. Unfortunately do neither Avahi nor Apple Bonjour register both ipv6 and ipv4 addresses by default. (The reason for that is that this would cause all services to show up twice, once for each protocol. But that's a different story). So, in short, because most people with run nss-mdns together with Avahi or Bonjour hosts with default configurations, please do not enable Ipv6 address lookups by default. i.e. use only mdns4 and not mdns and the same for the _minimal flavour. And secondly, please make mdns4_minimal authoritative for .local and IPv4LL hosts. This can be done by adding [NOTFOUND=return] to the invocation for mdns4_minimal. Why? If you don't pass it lookups for nonexistant mdns host names will take twice as long as necessary, because first mdns4_minimal has to timeout and than mdns4 as well. Since the timeout is 5s or so, this will increase the total timeout to 10s which really hurts I would argue. In addition making mDNS authritative for .local has security advantages and removes unnecessary load from unicast DNS servers. The ideal line has to look like this: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 I strongly suggest following this advice of mine. To my knowledge this line is nearly optimal. I know that Anand Kumria doesn't really follow me in my argumentation and added some misleading documentation to README.Debian. However, I am very unhappy with this situation. Yes, it is a pity that we cannot add proper out-of-the-box support for IPv6 to our zeroconf stack. But humm, that's the situation we have to deal with. Thank you very much, Lennart (who happens to be upstream of nss-mdns) -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388864: [EMAIL PROTECTED]: Stop! Wait!]
On Tue, 03.10.06 19:30, Joey Hess ([EMAIL PROTECTED]) wrote: Lennart Poettering wrote: Humm, the Debian BTS apparently didn't forward this comment I wrote regarding bug #388864 to you. Right, to reach the submitter you need to cc bugnum-submitter. Hmm, why's that? I mean, it would make a lot of sense to include the submitter in all CCs regarding the bug. NOTFOUND=return saves 2 seconds, the rest are the doubled lookups. If you shutdown Avahi these numbers should differ a little more. When Avahi is running nss-mdns makes use of it and the lookup behaviour changes drastically, due to cacheing and stuff. Unfortunately do neither Avahi nor Apple Bonjour register both ipv6 and ipv4 addresses by default. (The reason for that is that this would cause all services to show up twice, once for each protocol. But that's a different story). According to the README.Debian, OS X 10.3 does use ipv6 mdns entries. Is that wrong? I guess the other question is, might this change in the lifetime of the etch release. This is not true AFAIK. According to Marc Krochmal (one of the Zeroconf guys at Apple) the algorithm chosen by apple is more like this: if the main network interface has only an IPv6 address assigned Bonjour goes into IPv6-only mode, otherwise it goes to IPv4-only mode. AFAIK Bonjour is not capable of handling both ipv4 and ipv6 at the same time. I must admit that I don't have a Mac machine standing around, so I cannot really make sure what I am saying is true... Maybe my knowledge is a little bit out of date. I know quite a few people who still run MacOS9, hence just relying on that all people have the latest and greatest MacOSX versions doesn't seem like a good idea to me. This is zeroconf after all, so people expect it to work in all cases. It might make sense to convince the telnet maintainers (and all other developers of sockets based software) to fix their tools and use exclusively the getaddrinfo() API call with ai_family = AF_UNSPEC to support IPv6 and mDNS properly. After that is done we can officially enable mdns instead of mdns4. Hey, maybe this should be added to the goal list for etch+1? Perhaps as subitem for ubiquitious IPv6 support? gethostbyname, gethostbyname2, gethostbyaddr, getipnodebyname, getipnodebyaddr should die! Everyone should use getaddrinfo with AF_UNSPEC! Hurrah! getaddrinfo() has been available in Linux since nearly 10 years. I mean, at some point people should really start using it instead of gethostbyname(). Also related to this, in bug #375419, Arnand says that he doesn't recommend using your line, but later in the bug report it's suggested that it needs version 0.8 to work, and not the 0.7 that the bug reporter was using. I can't reproduce the whois failure described in #375419. #375419 is bogus, just as Aaron Gyes said. This bug should be closed as invalid. I thought about closing this bug myself, but I thought it would be unfriendly to Anand, since I don't maintain this package and I am not even a DD. I guess #351990, #388864 and #387231 are closed by your NMU? Regarding #353131: I just saw that Sjoerd uploaded Avahi 0.6.14. That version includes a new tool avahi-autoipd which is a much better replacement for the zeroconf tool. Maybe it is time to replace the Recommends: zeroconf by a Suggests: avahi-autoipd? Or perhaps drop the line entirely as Sjoerd argues? (This issue might be a little bit controversial since Anand is upstream of zeroconf, so he might feel stepped on his toes) BTW, did Anand react in any way on your and Sjoerds NMUs? Or did he vanish without a trace? Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389647: RFP: rawstudio -- open source raw image converter and manipulation application
Package: wnpp Severity: wishlist * Package name: rawstudio Version : 0.4 Upstream Author : [EMAIL PROTECTED] * URL : http://rawstudio.org/ * License : GPL Programming Lang: C Description : open source raw image converter and manipulation application The Description says it all. For more information see the web site. Apparently Ubuntu already has a package for this application. http://packages.ubuntu.com/edgy/source/rawstudio Lennart -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379147: fusedav and SSL
On Thu, 24.08.06 17:59, Sebastian Harl ([EMAIL PROTECTED]) wrote: Hi Lennart, Hi! fusedav is linking against SSL (by using neon). As fusedav is licensed under the GPL I'm not allowed to link it against OpenSSL unless you explicitly allow me to do so in your README file (see [1]). Would you please be so kind to add an appropriate paragraph to your README file or do you want me to link against GnuTLS (which I did not test so far, as there is no neon26-gnutls package in Debian [yet]). Isn't it necessary that NEON's author adds the same exception clause to his license? Or is this no problem because he chose the LGPL? I am of course OK with changing the license of fusedav to add this clause, but I wonder if that is sufficient. Adding the following sentence to LICENSE is all that is required on my side, right? snip Linking fusedav statically or dynamically with other modules is making a combined work based on fusedav. Thus, the terms and conditions of the GNU General Public License cover the whole combination. In addition, as a special exception, the copyright holders of fusedav give you permission to combine fusedav program with free software programs or libraries that are released under the GNU LGPL and with code included in the standard release of OpenSSL under the OpenSSL license (or modified versions of such code, with unchanged license). You may copy and distribute such a system following the terms of the GNU GPL for fusedav and the licenses of the other code concerned, provided that you include the source code of that other code when and as the GNU GPL requires distribution of source code. Note that people who make modified versions of fusedav are not obligated to grant this special exception for their modified versions; it is their choice whether to do so. The GNU General Public License gives permission to release a modified version without this exception; this exception also makes it possible to release a modified version which carries forward this exception. /snip Using GnuTLS instead of OpenSSL would be cool, though. (Ich kann übrigens auch Deutsch.) Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
Bug#378608: error building nss-mdns: configure: error: tag name CXX already exists
On Thu, 10.08.06 00:22, Sam Morris ([EMAIL PROTECTED]) wrote: I just realised that the Debian package regenerates all the autotools stuff! Running the configure script from the pristine upstream tarball works fine--so I guess this is Debian specific breakage. :/ Ok, then I guess I can leave to the Debian maintainers to fix it. ;-) Oh, and BTW, libtool sucks. Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368486: mod_dnssd and hostnames with only one component
On Sat, 29.07.06 11:01, Sam Morris ([EMAIL PROTECTED]) wrote: Perhaps mod_dnssd's documentation should mention that the hostnames apache uses (and hence supplies to mod_dnssd) must be 'valid'--i.e. resolvable via the DNS or via mDNS. I now added a paragraph about this to mod_dnssd's documentation. It's in SVN and will be part of the next official release. Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380632: please set /etc/hostapd/hostapd.conf access mode to 600
Package: hostapd Version: 1:0.5.3-1 Severity: wishlist Please consider setting the hostapd.conf access mode to 600 by default, because it might contain passwords if used in WPA-PSK mode. Thanks, Lenart -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages hostapd depends on: ii libc6 2.3.6-7GNU C Library: Shared libraries ii libssl0.9.8 0.9.8b-2 SSL shared libraries hostapd recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379147: RFP: fusedav -- fusedav is a Linux userspace file system driver for mounting WebDAV shares.
Package: wnpp Severity: wishlist * Package name: fusedav Version : 0.2 Upstream Author : Lennart Poettering * URL : http://0pointer.de/lennart/projects/fusedav/ * License : GPL Programming Lang: C Description : fusedav is a Linux userspace file system driver for mounting WebDAV shares. snip fusedav is a Linux userspace file system driver for mounting WebDAV shares. It makes use of FUSE as userspace file system API and neon as WebDAV API. /snip Unfortunately NEON in Debian needs an update to 0.26 before this can go in. Lennart -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378987: RFP: seccure -- The seccure toolset implements a selection of asymmetric algorithms based on elliptic curve cryptography (ECC)
Package: wnpp Severity: wishlist * Package name: seccure Version : 0.1 Upstream Author : B. Poettering * URL : http://point-at-infinity.org/seccure/ * License : GPL Programming Lang: C Description : The seccure toolset implements a selection of asymmetric algorithms based on elliptic curve cryptography (ECC) quote The seccure toolset implements a selection of asymmetric algorithms based on elliptic curve cryptography (ECC). In particular, it offers public key encryption / decryption and signature generation / verification. ECC schemes offer a much better key size to security ratio than classical systems (RSA, DSA). Keys are short enough to make direct specification of keys on the command line possible (sometimes this is more convenient than the management of PGP-like key rings). seccure builds on this feature and therefore is the tool of choice whenever lightweight asymmetric cryptography -- independent of key servers, revocation certificates, the Web of Trust, or even configuration files -- is required. /quot -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369827: libnss-mdns: Please update to nss-mdns 0.8
Package: libnss-mdns Version: 0.7-1 Severity: wishlist 0.8 has been available for some time now and has some exciting new features. Please update your packages! -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages libnss-mdns depends on: ii libc6 2.3.6-7GNU C Library: Shared libraries Versions of packages libnss-mdns recommends: ii zeroconf 0.9-1 IPv4 link-local address allocator -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369089: RFP: polypaudio -- Polypaudio Sound Server
Package: wnpp Severity: wishlist * Package name: polypaudio Version : 0.9.0 Upstream Author : Lennart Poettering and Pierre Ossman * URL : http://0pointer.de/lennart/projects/polypaudio/ * License : LGPL Programming Lang: C Description : Polypaudio Sound Server snip polypaudio is a networked sound server for Linux and other Unix like operating systems and Microsoft Windows. It is intended to be an improved drop-in replacement for the Enlightened Sound Daemon (ESOUND). /snip For more information see the homepage. Along with polypaudio itself the following auxiliary apps should be packaged, too: Polypaudio Manager: http://0pointer.de/lennart/projects/paman/ Polypaudio Volume Meter: http://0pointer.de/lennart/projects/pavumeter/ Polypaudio Volume Control: http://0pointer.de/lennart/projects/pavucontrol/ GStreamer Plugin: http://0pointer.de/lennart/projects/gst-polyp/ Libao Plugin: http://0pointer.de/lennart/projects/libao-polyp/ XMMS Plugin: http://0pointer.de/lennart/projects/xmms-polyp/ Since Polypaudio once was part of Debian uploading this new release is probably just a matter of updating the old packaging scripts. Lennart -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369115: RFP: tangerine -- publish music over the local network, using DAAP
Package: wnpp Severity: wishlist * Package name: tangerine Version : 0.2.5 Upstream Author : Snorp * URL : http://www.snorp.net/log/tangerine/ * License : GPL Programming Lang: C# Description : publish music over the local network, using DAAP snip Tangerine is an application that allows you to publish music over the local network, using DAAP. There are several clients that you can then use to connect to it, such as iTunes, Banshee, and Rhythmbox. Music files can be specified either by a directory, or can be automatically discovered using Beagle. Tangerine can also publish any music stored on connected iPod devices. For typical configurations, a graphical tool is included. /snip -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368678: setmixer: Please don't conflict with alsa-base or aumix
Package: setmixer Severity: normal setmixer shouldn't conflict with alsa-base or aumix. The CLI tool works perfectly in conjunction with both of them, the only problem is the init script. IANADD, but I think the policy forbids to put alsa-base/aumix in the Conflicts: field in such a case. The correct fix would be to fix the init script to stop if either aumix or alsa-base is found. (Just as aumix currently does it with alsa-base). setmixer is quite a useful tool, but due to the Conflicts line with alsa-base I am currently unable to use it. Lennart -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367275: libnss-mdns: Please remove Suggests: nscd
Package: libnss-mdns Version: 0.7-1 Severity: wishlist Please remove the Suggests: nscd line from the libnss-mdns package. nscd is not a good cache for mDNS traffic. Please replace the line with Suggests: avahi-daemon, since Avahi actually is a good cache in perfect conformance with the mDNS cacheing specifications. And please update to nss-mdns 0.8! Lennart -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages libnss-mdns depends on: ii libc6 2.3.6-7GNU C Library: Shared libraries Versions of packages libnss-mdns recommends: ii zeroconf 0.9-1 IPv4 link-local address allocator -- no debconf information -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ signature.asc Description: Digital signature
Bug#354882: libneon25: ne_get_range() broken
Package: libneon25 Version: 0.25.5.dfsg-1 Severity: normal Tags: patch ne_get_range() doesn't work with Apache2's mod_dav module and most other current webdav servers. Please apply this trivial patch to fix this: http://0pointer.de/public/neon-partial-get.patch The problem is that neon doesn't consider partial GET responses valid which don't return exactly the byte range requested. However, modern WebDAV servers concatenate the real file length to the returned byte range. Hence, neon will never accept any partial GET responses. I will post this patch to upstream shortly. Lennart -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages libneon25 depends on: ii libc6 2.3.5-13 GNU C Library: Shared libraries an ii libssl0.9.80.9.8a-7 SSL shared libraries ii libxml22.6.23.dfsg.1-0.1 GNOME XML library ii zlib1g 1:1.2.3-9 compression library - runtime libneon25 recommends no packages. -- no debconf information -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350619: patch
Hi! I prepared a fairly simple patch to implement this: http://0pointer.de/public/neon-off_t-64.patch (after applying make sure to rerun autoconf and autoheader) Please not that implementing this means an ABI breakage, since the size of the structure ne_content_range changes. I posted a report about this to the neon mailing list: http://mailman.webdav.org/pipermail/neon/2006-March/002197.html Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349419: status of libapache2-mod-dnssd in Debian?
On Fri, 24.02.06 10:01, Joey Hess ([EMAIL PROTECTED]) wrote: What's the status of getting this into Debian? Anything I can do to move it along? (such as, say, (co-)maintaining and uploading the package) It's sitting in the NEW queue afaik, already a whole week. Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349419: status of libapache2-mod-dnssd in Debian?
On Fri, 24.02.06 13:01, Joey Hess ([EMAIL PROTECTED]) wrote: Lennart Poettering wrote: It's sitting in the NEW queue afaik, already a whole week. Ah, I do see it there. Did you post the deb anywhere else until it gets out of new? debs for i386 are available here: http://0pointer.de/debian/ (along with a few other debs of software i wrote which i'd like to see in debian, but didn't bother to find an uploader/maintainer for) The debian/ directory sits in my upstream SVN (though it isn't included in distributed tarballs): svn checkout svn://svn.0pointer.net/mod_dnssd/trunk mod_dnssd Debianization of mod_dnssd (and mod_mime_xattr from the same rep) wasn't done be me, but by Sebastien Estienne. He passed his work to Sjoerd who did the upload. So better ask one of them if you're looking for a clean source package. Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349419: status of libapache2-mod-dnssd in Debian?
On Fri, 24.02.06 19:26, Sebastien Estienne ([EMAIL PROTECTED]) wrote: It's sitting in the NEW queue afaik, already a whole week. Ah, I do see it there. Did you post the deb anywhere else until it gets out of new? debs for i386 are available here: http://0pointer.de/debian/ I don't know if you updated the binary package from the last source package? No, I had not. But I did now. Thanks for the notice! The debian/ directory sits in my upstream SVN (though it isn't included in distributed tarballs): svn checkout svn://svn.0pointer.net/mod_dnssd/trunk mod_dnssd the version on pkg-utopia and in this svn are the same I guess it doesn't make sense to maintain this a two places, does it? If you're OK with it I'll remove the debian/ dir from upstream SVN as soon as mod_dnssd entered Debian. Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351699: avahi-daemon: Please enable chroot() support
Package: avahi-daemon Version: 0.6.6-1 Severity: wishlist Please make sure to add libcap-dev to avahi's build-depends. Otherwise Avahi will not make use of chroot(). Lennart -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages avahi-daemon depends on: ii adduser 3.80 Add and remove users and groups ii dbus 0.60-5 simple interprocess messaging syst ii libavahi-common3 0.6.6-1Avahi common library ii libavahi-core30.6.6-1Avahi's embeddable mDNS/DNS-SD lib ii libc6 2.3.5-8GNU C Library: Shared libraries an ii libdaemon00.10-1 lightweight C library for daemons ii libdbus-1-2 0.60-5 simple interprocess messaging syst ii libexpat1 1.95.8-3 XML parsing C library - runtime li Versions of packages avahi-daemon recommends: ii libnss-mdns 0.7-1 NSS module for Multicast DNS name -- no debconf information -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350995: Please shut up, ok?
Hi! avahi-daemon is definitely not fucking your network configuration up. How do I know this? It doesn't even have priviliges to do that! It is run as user avahi and inside a chroot, so there is no way to fuck up your network configuration (unless you use avahi-dnsconfd, which you apparently don't). Unless, of course, there's a bug in your dhcp client or the kernel you're using. In which case you should file bugs against those packages! So, shut up and do your homework before raising random accusations against avahi! Besides that, avahi-daemon is not even a hard dependency of libgnomevfs! if you don't like it, don't install it! Lennart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350457: RFP: libapache2-mod-mime-xattr -- Apache module for storing a file's MIME type in an extended attribute (EA) (user.mime_type)
Package: wnpp Severity: wishlist * Package name: libapache2-mod-mime-xattr Version : 0.3 Upstream Author : Lennart Poettering * URL : http://0pointer.de/lennart/projects/mod_mime_xattr/ * License : Apache License 2.0 Description : Apache module for storing a file's MIME type in an extended attribute (EA) (user.mime_type) Quoting the homepage: snip mod_mime_xattr is a module for the Apache HTTPD 2.0 which may be used to set a range of MIME properties of files served from a document tree with extended attributes (EAs) as supported by the underlying file system. The current version of mod_mime_xattr has support for Linux style EAs which are supported by Linux 2.4 with the ACL/EA patches applied and vanilla Linux 2.6. The following attributes may be used: * user.mime_type: set the MIME type of a file explicitly. This attribute is compatible with the shared MIME database specification as published by freedesktop.org * user.charset: set the charset used in a file * user.mime_encoding: set the MIME encoding of a file (e.g. gzip) * user.apache_handler: set the apache handler of a file explicitly /snip Lennart -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
