Re: Getting good bug reports
Brian May writes: > Some don't even have Internet access. So, how do you propose reportbug should handle those? Send a fax? Seriously, what problem do you have that isn't solved by "reportbug --offline --output=foo" ? Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762oyx3t3@nemi.mork.no
Re: How to solve race condition between IPv6 ifup and start of services?
Marc Haber writes: > On Sat, 21 May 2011 15:42:51 -0700, Steve Langasek > wrote: >>With an event-based init system such as upstart, you could also set up the >>service not to start until the specified interface is fully configured. > > Issue (1): We don't have event-based init system yet > Issue (2): When is an IPv6 interface "fully configured"? Or: When is *any* interface "fully configured"? The subject does not really have anything to do with IPv6. Interfaces may have any addresses added or removed, and you may want to define service policies depending on some specific network state. This applies just as much to IPv4 as to IPv6. I believe Debian as a distribution should be extremely careful about predefining policies, but preferably give the administrators the tools necessary to define them. So please don't try to define "fully configured" for me. It would of course be nice to have the ability to say: "Run service foo when interface bar has an address matching baz", but I believe these kinds of policies quickly will become too complex to have generic solutions. You can usually script something, using existing tools like laptop-net, udev, dhcp clients, wpa_supplicant etc. And if someone wants a scriptable solution for SLAAC, then writing a small daemon listening for netlink events and running scripts based on them should be piece-of-cake. In fact, it is so easy that it is probably already done. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxifynbx@nemi.mork.no
Re: this list archive spoils e-mails + strange Enigmail typos
Stanisław Findeisen writes: > Well but the quoted text *is* there... (at least in the copy I received > from liszt.debian.org). Both problems (missing text and visible =20) are caused by MIME headers missing from the first part of your message. The quoted text is hidden because there is no empty line after the boundary marker, which makes a MIME client interpret the text as unknown header lines. The =20 is displayed because you send quoted printable content without stating so. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87oc3f1xol@nemi.mork.no
Re: network-manager as default? No!
Fernando Lemos writes: > On Fri, Apr 15, 2011 at 6:50 PM, Felipe Sateler wrote: > >> Preparing to replace network-manager 0.8.3.999-1 (using .../network- >> manager_0.8.3.999-1_amd64.deb) ... >> Unpacking replacement network-manager ... >> Setting up network-manager (0.8.3.999-1) ... >> Reloading system message bus config...done. >> Stopping network connection manager: NetworkManager. >> >> Starting network connection manager: NetworkManager. >> Processing triggers for man-db ... > > As it was said before (*multiple* times, unfortunately), that's > expected. For the record: *I* don't expect it, since this behaviour is completely unnecessary and only a result of bad design. Leaving wpa_supplicant running on stop and re-interfacing with it on start would be simple to do if you wanted to fix this bug. But it's of course always much easier to claim that it's not a bug at all. Pigs can fly. The moon is made of green cheese. etc. > Your *wired* connection won't go down... Why not? That seems very inconsistent. How do I know which interfaces I should expect to go down? Any interface without a wire? Can I make the wlan interface stay up if I use a longer antenna cable? Why not? Only a Network Manager developer can possibly know what to expect of Network Manager... Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxjitj3r@nemi.mork.no
Re: network-manager as default? No!
"Josselin Mouette" writes: > Björn Mork wrote: >> Martin Wuertele writes: >>> up ip rule add >>> downip rule del > >> The power of the pre-up/up/down/post-down scripting is tremendous. > > So is that of NM dispatcher scripts. And this is documented where. > What is your gripe, again? 1) That Network Manager brings down interfaces without me explicitly asking for that (on stop, suspend, or upgrade unless you happen to hit the exception made to ignore a RC bug). 2) That you cannot configure any "complex" networking using Network Manager. And by "complex" here, I mean something like my laptop configuration. Yes, I do both bridging and vlans on my laptop. It makes it much easier to handle virtual guests. BTW, can Network Manager do IPv4 only on a network where IPv6 RAs are present? I ask because I don't know, not to be difficult. I'd really appreciate a HOWTO for that... Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aafrvbz1@nemi.mork.no
Re: network-manager as default? No!
Patrick Schoenfeld writes: > On Fri, Apr 15, 2011 at 02:01:06PM +0200, Bjørn Mork wrote: >> Josselin Mouette writes: >> >> > Since it was completely redesigned, almost from scratch, this doesn’t >> > apply for 0.8. Its system daemon is able to manage connections without >> > anyone logged on, and with a number of features that makes ifupdown look >> > like a baby toy. >> >> So Network-Manager has finally gained basic features like the ability to >> set a lower than default MTU? > > AFAICT n-m had support for setting a lower MTU since 2008. Great. Didn't know that. Couldn't find it documented anywhere, but that's probably because Network Manager in general is completely undocumented. > And with basic network features do you mean things like > > - custom routes per interface Sure, just add up ip route 2001:db8:42::/48 foo dev $IFACE to the interface config > - multiple ip adresses per interface Sure, just add up ip addr add 2001:db8:13::1/64 dev $IFACE to the interface config > - WLAN configuration Sure, just add wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf to the interface config > - 802.11x Don't to that, but the wpa_supplicant scripts should support it AFAIK. > - overriding default nameservers per connection That's actually a feature I try to avoid, as I rarely (if ever?) use a computer with a single interface. So which interface defines the "connection"? But it can of course be done. The main problem is knowing which servers to configure, based on which protocol and which interface, and not doing the actual /etc/resolv.conf replacement. > - overriding default search domain per connection Now, that's a "feature" I find extremely dangerous. So you connect to host "foo", which turns out to be either "foo.bar" or "foo.baz" depending on which interface is currently up? Weird. Why would anyone want that? Yes, it can of course be done. > - netmasks in CIDR notation Which would be nice, but staying backwards compatible is more important. > and all of that > - in a central place with a consistent interface Yes: /etc/network/interfaces > - without reliance on external commands (such as the ip command or shell > scripts) for basic stuff Which is bad because of what? Using the "ip" command or shell scripts is an important feature to me. I don't want "grep", "cp", "ls" etc unified to a single file handling program either. I prefer the UNIX way of simple utilities doing *one* thing and doing that well. > - without crude hacks (e.g. defining additional interfaces just to bring > up another ip) I assume you are talking about alias interfaces? Well, that's a kernel feature from way back and has nothing to do with ifupdown, except that it supports them. Which Network Manager doesn't, if I read the BTS correct. But I rarely use them for additional addresses, no. I use "up ip addr add" instead. >> The list of features *not* supported by Network Manager is so long that > > Most ifupdown features are not native. Its basically a framework which > allows *other* tools to provide all the features you named. Yes, that's why it works. It doesn't *prevent* you from doing what you want. >> I've always believed that peoply chose NM for simplicity. And I can >> understand that. It's simple because it doesn't support anything >> "complex", including common VPN setups. > > ifupdown does not support any VPN setup at all. how does that fit in > your argumentation? It doesn't? Weird. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ei53vcya@nemi.mork.no
Re: network-manager as default? No!
Martin Wuertele writes:
> * Timo Juhani Lindfors [2011-04-15 14:18]:
>
>> ip rule show | grep -Ev '^(0|32766|32767):|iif lo' \
>> | while read PRIO NATRULE; do
>> ip rule del prio ${PRIO%%:*} $( echo $NATRULE | sed 's|all|0/0|' )
>> done
>
> iface ethX inet static
> address x.x.x.x
> netmask x.x.x.x
> gateway x.x.x.x
> up ip rule add
> downip rule del
This is basically what I do, too.
The power of the pre-up/up/down/post-down scripting is tremendous.
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipufvfl7@nemi.mork.no
Re: network-manager as default? No!
Josselin Mouette writes: > Since it was completely redesigned, almost from scratch, this doesn’t > apply for 0.8. Its system daemon is able to manage connections without > anyone logged on, and with a number of features that makes ifupdown look > like a baby toy. So Network-Manager has finally gained basic features like the ability to set a lower than default MTU? How about bridging? VLANs? Unnumbered interfaces? DHCPv6-PD? Disabling IPv6 SLAAC on a specific interface? Multiple uplinks? Multiple routing tables? Creating tap interfaces connected to virtual swiches? Different types of tunnels? Sharing an ethernet interface between PPPoE and IP? The list of features *not* supported by Network Manager is so long that I really don't understand how you can start a feature based discussion. Surely there must be some other attraction to Network Manager than it's network configuration features? They are extremely limited I'm afraid. I've always believed that peoply chose NM for simplicity. And I can understand that. It's simple because it doesn't support anything "complex", including common VPN setups. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqonvi4d@nemi.mork.no
Re: network-manager as default? No!
Stephan Seitz writes: > The only thing that I miss from ifupdown (and I configured bonds, > bridges and vlans) is a good IPv6 support. I can’t separately activate > or deactivate IPv4 or IPv6 parts of an interface. I have seen several requests for this feature, but I really don't understand why you'd want that. If an interface is configured as a dual stack interface, then I expect both stacks to be brought up and down (near) simultaneously. In fact, the one thing I dislike about ifupdown is the illusion that there can be both an "iface eth0 inet" and an "iface eth0 inet6". There can't. It's the same interface running two protocols. I would have preferred something like some routers do: iface eth0 address .. ipv6address .. Juniper router do of course do this even better, splitting the IPv4 and IPv6 configuration in separate "family" blocks, but still grouping all the protocol families under the same "unit" (representing a VLAN, physical port, or some other layer 2 interface). But that is a bit too late to implement in ifupdown. If you really want to handle the protocols individually, then don't configure a dual stack interface in the first place. Use separate vlans or ports. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y63ex79x@nemi.mork.no
Re: network-manager as default? No!
Brett Parker writes: > Everything that you can do with ifupdown you can do with network > manager, That's simply not true. You cannot use n-m remotely without having some out-of-band access. For a start. Fix that, and I'll come back with the next issue. You don't seem to have a clue wrt the power of ifupdown... And no, to all the pedants around here, I have not opened a bug report regarding this. There are more than enough of those already, and the maintainer responses clearly shows that they don't care about such fundamental design flaws. See e.g. bug #432322. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcyr79vb@nemi.mork.no
Re: Flaming as a way to reach technical quality? No!
Steve Langasek writes:
> Yes, a user can do anything with ifconfig if his time has no value. I am
> happily using network manager on my laptop, because unlike ifconfig it's
> easy to configure for use on new wireless networks.
>
> I am not happy that network manager bypasses ifconfig to do this; I would
> have much preferred a daemon that could properly integrate with the existing
> infrastructure we had. But neither that, nor you calling me a stupid user,
> is much motivation for me to go back to the pain of managing wireless
> connections via ifupdown.
I not going to argue against using network manager for that particular
use case. It does provide a nice GUI for entering credentials etc.
But I will claim that using ifupdown is also easy, given that you can
accept a CLI instead of a GUI:
You need to
1) create a /etc/wpa_supplicant/wpa_supplicant.conf with something like
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
## uncomment this entry to automatically connect to any open network
#network={
# ssid=""
# key_mgmt=NONE
#}
2) add this (possibly with another device name) to /etc/network/interfaces:
allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp
3) run wpa_cli in a terminal as a user in the netdev group
Adding new networks and other management tasks can easily be done in the
wpa_cli shell. IMHO easier than using NM, as it won't interfere with
e.g. any temporary address I've configured manually. But this is of
course a highly subjective opinion.
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aag5geyj@nemi.mork.no
Re: Bits from the Release Team - Kicking off Wheezy
Ben Hutchings writes: > On Sat, 2011-04-02 at 23:07 +0200, Bjørn Mork wrote: >> Josselin Mouette writes: >> > Le jeudi 31 mars 2011 à 09:25 +0200, Vincent Danjean a écrit : >> >> Martin F. Krafft started to implement a replacement of ifupdown that >> >> is better designed. But, due to lack of manpower I think, this project >> >> did not finish. See this archives of netconf-de...@lists.alioth.debian.org >> >> for more info. >> > >> > I wonder what amount of features we are missing for network-manager to >> > do the job; instead of rewriting a daemon from scratch, >> >> A daemon will never be able to replace ifupdown. > > ifupdown will never work correctly. Point taken. Sorry about the noise. udevd has demonstrated that it is possible for a daemon to manage and police all devices in a system, while still keeping the kernel as "master of state". You can actually restart udevd without having all you disk devices removed and readded. Of course. So a daemon could do the job. NM, however, can not. I believe the problems with NM is best described by it's current list of bugs, and in particular by the maintainer responses to bugs like #415196. NM can probably be used for really simple desktop setups, but it is not suitable for any non-desktop setup or any non-trivial networking. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ei5hgj0s@nemi.mork.no
Re: Bits from the Release Team - Kicking off Wheezy
Josselin Mouette writes: > Le jeudi 31 mars 2011 à 09:25 +0200, Vincent Danjean a écrit : >> Martin F. Krafft started to implement a replacement of ifupdown that >> is better designed. But, due to lack of manpower I think, this project >> did not finish. See this archives of netconf-de...@lists.alioth.debian.org >> for more info. > > I wonder what amount of features we are missing for network-manager to > do the job; instead of rewriting a daemon from scratch, A daemon will never be able to replace ifupdown. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwq0gy6a@nemi.mork.no
Re: packages with hook interfaces and no documented hook policy
James Vega writes: > The bug[0] which was the impetus behind adding that script seems sound > to me. Delaying hibernation to ensure that the system isn't left in an > unbootable state is a fair trade-off. > > [0]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/191514 Yes, its an ugly bug and I can understand the eagerness to avoid this by adding hacks to unrelated packages. But the problem is neither unattended-upgrades nor pm-utils, is it? They only make the bug more likely to hit. The real problem is that upgrading some packages (kernel in particular, but possibly anything involved in the boot process), will leave the system in an unbootable state for some time. But you don't need unattended-upgrades or pm-utils to hit this. You might as well be running "dpkg -i linux-image-..." while power is failing. Still, I can understand the hack in unattended-upgrades. Fixing the real bug is non-trivial. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxmy7f5t@nemi.mork.no
Re: packages with hook interfaces and no documented hook policy
Neil Williams writes: > Different package objectives. cron-apt may be what you are actually > thinking of. Even then, I wouldn't use cron-apt on a laptop. Well, I do like security updates to just be there and I don't like to do sysadmin tasks. So I want some sort of automated package upgrades. I used to have just a "apt-get update && apt-get upgrade" cron job. But unattended-upgrades provided a few nice features I wanted, like the ability to restrict sources and packages are included in the automated upgrade. Will check out cron-apt, but I still don't see why unattended-upgrades should mess with hibernation. Even less so if it is intended for servers, which should never hibernate at all. > You could also seek clarification of the package descriptions to make > it clearer that unattended-upgrades is more commonly found on a server > than a laptop. (Unless it's a laptop with a faulty battery and is > largely used as a desktop anyway.) Sorry, I just don't see that. There's nothing here indicating that this package isn't suitable for any class of system: Description: automatic installation of security upgrades This package can download and install security upgrades automatically and unattended, taking care to only install packages from the configured APT source, and checking for dpkg prompts about configuration file changes. . This script is the backend for the APT::Periodic::Unattended-Upgrade option. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkqz6zbq@nemi.mork.no
Re: packages with hook interfaces and no documented hook policy
Neil Williams writes: > On Mon, 17 Jan 2011 18:43:23 +0100 > Bjørn Mork wrote: > >> Can any package just provide the hook directories it want without an >> explicit policy? > > A general policy for all hooks sounds like a difficult thing to create > - it could easily be so nebulous as to be unusable. Probably better for > each package supporting hooks to handle their own. > > If the hook syntax is correct for the package running the hook, that > would be the majority of such a policy being met. > > Hook policy is in the hands of whichever package is trying to run the > hooks. If the hook meets the requirement of that package, it's not a > bug to provide such a hook. Ah, I see that I was a bit unclear. What I meant to ask, was just that: Should a package providing hook infrastructure also define a policy for its usage? >> My claim is that packages like unattended-upgrades and pm-utils are >> completely unrelated to each other, > > I'd disagree - if one package provides a hook for another package, > those packages are clearly related. One is executing a known API of the > other - that's a definite relationship. Yes, I see that point. Which implies that if you provide some hook infrastructure without restricting its policy, then you are really opening for *anyone* to break your package. Kind of dangerous... >> and that a hook in >> unattended-upgrades which breaks pm-utils by preventing hibernation >> is a critical bug, even if the breakage seems intentional. > > Sounds to me as if unattended-upgrades would have a perfectly good > reason to prevent hibernation, if configured in that manner. I'm not > sure it's a bug at all. Would be better if unattended-upgrades made > this step configurable, true. Why use unattended-upgrades if the > machine is not on a UPS? That would seem to be the typical use case to > me (the UPS providing a period of time normally sufficient for an > unattended upgrade to complete whilst on UPS power before shutting > down). Other setups would need different configuration and maybe > unattended-upgrades ought to support that. However, that would be a > minor or wishlist bug. Huh? I use unattended-upgrades on my laptop as a way to keep it updated without having to create the cron job myself. But I don't expect it to force itself to run at times where I want to the laptop to sleep. > One alternative would be to conflict with pm-utils. Sorry, I still don't see what's so special about the unattended-upgrades cron job. Couldn't e.g. logrotate just as well argue that it should be allowed to finish its work before the machin is hibernated? Or any program for that matter? hibernate is supposed to freeze running processes, not wait for them to finish. >> But i may be wrong. Maybe it's OK to break any package with a hook >> interface and no policy for its usage, as the package itself then has >> provided the necessary infrastructure for breaking it? > > The package providing the hook interface makes itself accessible to > other packages which may provide hooks. As long as the hook syntax is > correct, it is up to the package providing the hook to ensure that only > relevant functionality is exposed via the hooks. If a package contains > a hook for that program which uses valid syntax to make a particular > change, it's not a bug if that functionality is changed in that manner > by that hook. OK, sounds kind of reasonable. Except that I think I have to remove pm-utils then I just cannot accept that the hibernate/resume process becomes as bloated as a full shutdown/reboot. > There may be a bug in the package supporting hooks if the changed > functionality has adverse effects - that particular functionality may > need to be inaccessible from hooks. > > There may be a bug in the package containing the hook if the hook > breaks the package processing the hook but that bug is clearly a bug > affecting two strongly related packages. This package may need to allow > for such hooks to be disabled in the package configuration to fix such > a bug. The hook should also take steps to ensure that it is only active > in appropriate situations, in this case when an upgrade is actually in > progress. > > Neither bugs would necessarily be RC - it all depends on whether there > is data loss or some other reason for such severity. OK, I understand that I have opened a couple of bugs which will have to be downgraded a bit. Thanks for taking the time to answer this. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874o978fx7@nemi.mork.no
Re: packages with hook interfaces and no documented hook policy
James Vega writes:
> On Mon, Jan 17, 2011 at 12:43 PM, Bjørn Mork wrote:
>> My claim is that packages like unattended-upgrades and pm-utils are
>> completely unrelated to each other, and that a hook in
>> unattended-upgrades which breaks pm-utils by preventing hibernation is a
>> critical bug, even if the breakage seems intentional.
>
> Is this just a case of an upgrade pulling in a new kernel, which could
> cause pm-hibernate to disallow a hibernate[0]?
No, that one I can understand. If the kernel changes, then you have to
reboot before you can hibernate. But that is part of the kernel upgrade
hooks and not really related to how the kernel is upgraded.
This is what I find unacceptable about unattended-upgrades:
case "${1}" in
hibernate)
python
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
;;
where the /usr/share/unattended-upgrades/unattended-upgrade-shutdown
script is documented as
# unattended-upgrade-shutdown - helper that checks if a
# unattended-upgrade is in progress and waits until it exists
So you have to wait for this job to finish before hibernation will
succeed. This may take significant time. When I push the hibernate
button, I expect the system to be frozen and hibernated as quickly as
possibly. I do not want for any random process to finish its work.
My claim is that *any* package installing a program which may be running
at hibernation time just as well could install something similar. There
is nothing special about the unattended-upgrade job which could possibly
justify that you need to wait for it to finish. It should be frozen
like any other process, and thawed like any other process on resume.
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vyj8gt1@nemi.mork.no
packages with hook interfaces and no documented hook policy
After discovering two different unrelated packages abusing the pm-utils hooks, I started wondering if there are any generic guidance wrt such hooks. Can any package just provide the hook directories it want without an explicit policy? And can any package provide hooks in such directories, even if there is no policy for its usage? Does it make any difference if the hooks are configuration files? My claim is that packages like unattended-upgrades and pm-utils are completely unrelated to each other, and that a hook in unattended-upgrades which breaks pm-utils by preventing hibernation is a critical bug, even if the breakage seems intentional. But i may be wrong. Maybe it's OK to break any package with a hook interface and no policy for its usage, as the package itself then has provided the necessary infrastructure for breaking it? Thanks, Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqrv8lz8@nemi.mork.no
Re: Why is help so hard to find?
Michael Biebl writes: > Completely agreed. The focus of dependency based boot is correctness. > The old system with static start/stop priorities was a pain to maintain and > actually had many bugs which were effectively impossible to change, because > changing the priority of *one* package can lead to a domino effect of required > changes to a *lot* of packages. With the dependency based system only a single > package needs to be fixed. > > And to re-iterate what has already been said: if you do find scenarios where > the > ordering is incorrect, please *do* file bugs. Such bugs are valuable. > Fixing incorrect orderings is actually quite simple now. Although I do agree with the improved simplicity, I do not agree that *all* incorrect orderings are simple to fix (or necessarily package bugs). Unfortunately, there are some packages which require system dependent ordering. The most obvious example is the set packages modifying the block device layers. Do you run LVM on top of LUKS on top of MD, or was it the other way round? Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lj2lax0f@nemi.mork.no
Re: Debian Policy "10.7.4 Sharing configuration files" question
Josselin Mouette writes: > Le mardi 11 janvier 2011 à 18:27 +0100, Bjørn Mork a écrit : >> If I wanted some random package maintainer to mess with my configuration >> files, then I would probably just have used Fedora or whatever. > > I am not seeking the opinion of other random developers - I’m sure there > are people who won’t agree. I am asking whether this would be considered > a release-critical bug. Then maybe you could describe what you mean by "change of /etc/inittab in a maintainer script"? Doing sed -i /etc/inittab in a gdm3 maintainer script would definitely be a RC bug. Doing update-inittab in a gdm3 maintainer script, after making sysvinit provide such a program, would not. Maybe you could tell us which parts of Debian Policy 10.7.4 you find unclear instead of asking the exact question 10.7.4 answers? Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwszs0i2@nemi.mork.no
Re: Debian Policy "10.7.4 Sharing configuration files" question
Josselin Mouette writes: > On a different, although similar issue, how would a change > of /etc/inittab in a maintainer script be regarded? > (I’m considering it for gdm3 in wheezy.) If I wanted some random package maintainer to mess with my configuration files, then I would probably just have used Fedora or whatever. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874o9ftkpk@nemi.mork.no
Re: Debian Policy "10.7.4 Sharing configuration files" question
Russ Allbery writes: > For reference for others reading this, the postinst of the relevant > package follows. Note that it adds an unqualified hostname, potentially > shadowing a system in the local domain, if the user agrees to update > /etc/hosts. The debconf question is priority: high and defaults to true. > It looks like the purpose of the alias is because the package configures > an Apache virtual host named rtpg, which I think is also questionable and, > IIRC, contrary to the draft webapp policy. > > I get the impression that the intent of this package is to set up a local > web interface as essentially a cheap form of GUI to control a local daemon > on the system, which is an interesting problem for which Debian does not > currently have good infrastructure support. well, you could always add a name pointing to 127.0.0.1 in some DNS zone you control, and then use this name for the package virtual host. No need to edit the local /etc/hosts then as long as the system can access the DNS (which of course may be a false assumption, but at least not violating any policy requirements). Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vyrx0vk@nemi.mork.no
Re: Bug#594672: ITP: dhcpcd5 -- a DHCP client
Philipp Kern writes: > DHCPv4 and DHCPv6 are sufficiently different protocol-wise to warrant two > different clients. (The v6 people might not want to deal with the cruft > of DHCPv4 too...) Absolutely! Create a new DHCPv6 client, cleanly implementing the protocol without having to carry all the unnecessary DHCPv4 baggage. Or even better: Work on improving some of the *existing* DHCPv6 clients. Maybe we can get at least one of them in good enough shape to be actually usable. I tried to summarize the situation here in December: http://www.gossamer-threads.com/lists/nsp/ipv6/20683 I don't think much has changed since then. The ISC has already demonstrated that combining the clients is a big mistake, no matter how big your existing IPv4 codebase is. Their IPv6 support is still not usable in some for what will be the most common DHCPv6 scenario due to the lack of ppp support (which of course is completely unnecessary for IPv4). An example: xs4all has recently announced native IPv6 access for all their users (opt-in), using DHCPv6-PD on top of PPP: http://www.xs4all.nl/klant/ipv6/ This is exactly what the ISP I'm working for will do when we get that far, and I assume many other ISPs will do something similar. DHCPv6-PD is essantial. And using PPP for the link simplifies a lot in a world where most layer 2 equipment is still unprepared for IPv6. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vd6v3p21@nemi.mork.no
Re: teaching users how to submit good bug reports
Ron Johnson writes: > On 07/22/2010 11:42 AM, Bjørn Mork wrote: > [snip] >> >> But this is not a problem you can solve. You cannot avoid requiring >> some effort from users wanting to report a bug. >> > > For some value of "some effort". > > MS Windows has a bug-reporting pop-up window that with the click of a > button sends traceback info to MS. GNOME also has such a tool, I > think. OK. One of your Windows applications prints "foo" on the screen when you expected it to print "bar". What do you do? Reporting bugs requires some effort. Sending crash dumps does maybe not. But then again, Debian has already several apps which will do that for you. It is still not bug reporting. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4on1die@nemi.mork.no
Re: teaching users how to submit good bug reports
Stefano Zacchiroli writes: > On Thu, Jul 22, 2010 at 06:00:44PM +0200, Bjørn Mork wrote: >> > No, we obviosely do not. When staffing bothes in the past I regularly >> > asked people to report their problem and they had no idea how to do >> > (because they did not know reportbug) even if long term Debian users. >> I believe it's extremely unlikely that you have anything valuable to >> report if you are unable to find reportbug. > > That is just not the attitude we should have, IMVHO. > > Basically, this reasoning has an underlying argument which goes like: > "there's an entry barrier that we are willfully imposing to our users, > either you're good enough to discover the tool, or we're not interested > in your bug reports". No, not at all. The reasoning is based on the observation that a) finding reportbug requires an obvious google search and reading two short lines of text, and b) describing any problem, whether bug or not, is way more complicated than a) If you can do b) then you almost certainly can do a). If you cannot do b) then you have no reason to try a). It has nothing to do with being "good enough". > Now, it *might* be that the net result of that is > that you get higher quality bug reports, but I'm more inclined to > believe that it is just wishful thinking. > > For instance, the story I reported involved a skilled programmer, which > was just too lazy to look for the good tool. Sure. I can understand that. Reporting bugs do require some work, and I am also among those who have refrained from doing so because I didn't want to spend any time on it. But this is not a problem you can solve. You cannot avoid requiring some effort from users wanting to report a bug. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ocdz1n9k@nemi.mork.no
Re: teaching users how to submit good bug reports
Andreas Tille writes: > On Thu, Jul 22, 2010 at 04:05:17PM +0200, Stefano Zacchiroli wrote: >>So, point 2: are we *advertising* reportbug enough to our users? >>In particular, I'm thinking about advertising in "push mode" rather >>then in "pull mode". > > No, we obviosely do not. When staffing bothes in the past I regularly > asked people to report their problem and they had no idea how to do > (because they did not know reportbug) even if long term Debian users. I believe it's extremely unlikely that you have anything valuable to report if you are unable to find reportbug. Googling for "Debian bug" or similar (actually even when I misspelled Debian), lists http://www.debian.org/Bugs/ as the first hit. The second heading on that page says "How to report a bug in Debian". It is a single line linking to http://www.debian.org/Bugs/Reporting which starts with "We strongly recommend that you report bugs in Debian using the reportbug program." and continues with further instructions on how to do that. If you are still unable to find and use reportbug, then I doubt that you are able to identify a bug and much less provide the information required to actually fix it. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y6d31p77@nemi.mork.no
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
Russ Allbery writes: > Having followed the Ubuntu bugs for many of my packages for several years > now, I think Debian's bug system is considerably more user-friendly than > Launchpad. It may not be as *pretty*, and it's not as easy to submit a > bug, but when you submit a bug to Debian, the chances are fairly good that > someone will look at it and reply with a detailed understanding of both > your bug and the package (at least unless you're reporting a bug to one of > the packages that notoriously gets more bugs than anyone could ever deal > with, usually about other software, like the kernel or the desktop > metapackages). Debian's BTS is more friendly in that old-fashioned sense > that involves interacting with people. :) Yes. Absolutely. When googling for some problem, I usually avoid any link into Launchpad because my experience is that it consists of a vague problem description, a number of "me 2"'s, some unrelated problems, and maybe a suggested horrendous workaround. I don't think I've ever seen a real solution there. The Debian BTS is the opposite. There you can expect bug reports to be followed up with an intelligent discussion, and often a patch or other good solution to the problem. If not, you will at least find enough information to know that you are not alone with your problem. BTW, I must also add that the kernel is no exception in Debian, even though it of course fits the description "gets more bugs than anyone could ever deal with". The kernel team does an extremely good job dealing with them. IMHO, the Debian BTS and the users and developers making it what it is, is one of the main advantages Debian has over other distributions. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739vb3465.fsf...@nemi.mork.no
Re: How to make Debian more attractive for users
"Jesús M. Navarro" writes: > "so good that *I* will prefer it over others". The problem with this is that we all(?) already prefer Debian. In my eyes, there is no question about which distro to choose. I prefer Debian for so many reasons that I'm not sure I'm able to list them all. But some of them are - active mailing lists - bug tracker with actual content - reliability and managebility - responsive developers - large package base - a per package choice between stability and bleeding egde The only downside I can think of is the extremist "free" definition, but I can live with that. But I don't think my reasons for choosing Debian can be applied to the masses. They probably don't care much about how easy bug fixing is, and a large number of packages is not important if the version of package X is "too old". I believe they only care about: business user: "can I buy a Linux OS from someone, inluding support?" home user: "what do my friends use?" And the answers to those two questions are currenly "RHEL" and "Ubuntu". Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tynr3agj@nemi.mork.no
Re: New LILO upstream development
Joachim Wiedorn writes: > After the long silence about the popular bootloader LILO the development > was started again. > > The new Homepage can be found here: > http://lilo.alioth.debian.org/ > > For the development of the bootloader I have started an Alioth project > with Git repository and Mailinglist: > http://alioth.debian.org/projects/lilo/ Nice. And thus I learned about bug #573736 $ git clone https://alioth.debian.org/anonscm/git/lilo/lilo.git Initialized empty Git repository in /usr/local/src/git/lilo/.git/ error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt while accessing https://alioth.debian.org/anonscm/git/lilo/lilo.git/info/refs fatal: HTTP request failed Maybe someone could fix the certificate chain sorting on alioth? Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bpb7e26e@nemi.mork.no
Re: Automatically installing hardware specific packages
Petter Reinholdtsen writes: > [Petter Reinholdtsen] >> Are there better ways to do this? Anyone willing to work on it? > > One alternative would be to move the information out of the > discover-data package, and into the Packages file instead, similar to > how Iceweasel[1] and Moonlight[2] might find their plugins and codec > packages, and store USB and PCI ids there. > > [1] https://wiki.ubuntu.com/FlashExperienceIntrepid > [2] http://wiki.debian.org/Teams/DebianMonoGroup/Moonlight > > The idea I got was to add headers like this to the package supporting > specific hardware, and use this information to look up the USB and PCI > ids present in the machine: > > Xb-Hardware-Bus-PCI: 1af4:1002 > Xb-Hardware-Bus-USB: 1d6b:0001 And subdevice ids and class ids and more buses and ... > This way the build system for the X video card packages could extract > the list of PCI devices supported by the driver and include it in the > control file of the package, and the RAID controller packages could > list the supported hardware ids too. It would get rid of the central > hardware->package directory, and probably scale better than the > discover-pkginstall approach. > > A problem with this approach is that some packages support a lot of > PCI ids, and another is that some packages support ranges of ids or > classes of devices. Not sure how that is best represented in a > Packages file. Why not reuse the module alias syntax for the hardware application database as well? It allows for a number of different bus configurations, not only pci and usb, with class matches where appropriate. And it is a well known syntax. And it buys you easy direct matching against /sys/devices/.../modalias Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ocfavi9k@nemi.mork.no
Re: Bindv6only once again
Paul Wise writes: > How many times will this discussion will go round and round in > circles? I'm getting dizzy. I believe it will continue until someone finds the end of the circle. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874oh7b1gi@nemi.mork.no
extlinux (was: Re: lilo removal in squeeze (or, "please test grub2"))
Daniel Baumann writes: > as of current git, you can now use EXTLINUX_UPDATE=false in > /etc/default/extlinux to prevent having update-extlinux do anything. That's the single feature I misseded. Thanks. Although it would be even better if it was possible to include some fixed part in it, while keeping most of it auto updated. I tested the extlinux package after reading about it yesterday, and the missing feature that immediately hit me was the ability to use a serial console. This is of course as easy as with sys-/pxe-/mem-linux: just add "serial 0 9600 0" or something similar to the config file. But running update-extlinux would remove it on every kernel upgrade. Anyway, I understand that this issue is now solved. It has puzzled me for a while that grub2 has been chosen over extlinux as the default x86 bootloader, but didn't know until this discussion came up that extlinux now was packaged separately from syslinux, with the nice helper scripts. I guess we all know syslinux and pxelinux very well from Linux installation procedures over the last 15 years (for syslinux at least), and HPA has been an active upstream maintainer all this time AFAIK. This makes me very confident in extlinux. While grub2 has already bitten me too much to be considered at all on the important boxes... Just comparing http://git.kernel.org/?p=boot/syslinux/syslinux.git with http://bzr.savannah.gnu.org/r/grub/trunk/grub/ should IMHO give more than enough information to choose extlinux over grub2 Thanks a lot for packaging extlinux! Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4qrjbk2.fsf...@nemi.mork.no
Re: APT do not work with Squid as a proxy because of pipelining default
Goswin von Brederlow writes: > A HTTP/1.1 conforming server or proxy This is not the real world... > is free to process pipelined > requests serially one by one. The only requirement is that it does not > corrupt the second request by reading all available data into a buffer, > parsing the first request and then throwing away the buffer and thereby > discarding the subsequent requests in that buffer. It is perfectly fine > for the server to parse the first request, think, respond to the first > request and then continue to parse the second one. Yes, this can be done. But you should ask yourself what proxies are used for. The serializing strategy will work, but it will make the connection slower with a proxy than without. That's not going to sell many proxy servers. > Note that that behaviour in the server already gives a huge speed > increase. It cuts away the round trip time between the last responce and > the next request. For static web content the speedup of processing > pipelined requests truely in parallel is neglible anyway. Only dynamic > pages, where formulating the responce to a request takes time, would > benefit by working on multiple responces on multiple cores. And those > are probably busy handling requests from other connections. So I > wouldn't expect servers to actually to parallel processing of pipelined > requests at all. This is true for a web server. It is only true for a proxy server if it can either forward a pipelined request or parallelize it. That's where we get the complexity. If you keep your simple serial strategy, then a pipelined request will be slower than a parallel one. > And your argument 1 applies perfectly to fixing squid by the way. It > should accept pipelined requests and then it can proces them one by one > and send them non pipelined if it likes. It should NOT corrupt the > requests/responces. Sure. Squid should be fixed. But I'm afraid fixing squid in Debian won't fix all the http proxies around the world. > So just from your argument 1 APT should default not to pipeline and > squid should be fixed. Good. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wruz1xn7@nemi.mork.no
Re: APT do not work with Squid as a proxy because of pipelining default
Pierre Habouzit writes: > On Wed, May 19, 2010 at 10:42:55AM +0200, Bjørn Mork wrote: > >> 2) http proxy servers cannot always process pipelined requests due to >>the complexity this adds (complexity is always bad for security), and > > This is bullshit. It's *VERY* easy to "support" pipelining: parse one > request at a time, and until you're done with a given request, you just > stop to watch the socket/file-descriptor for reading (IOW you let the > consecutive request live in the kernel buffers). Yeah, you make it sound easy. I'm sure those writing proxy servers are just stupid. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r5l83tsv@nemi.mork.no
Re: APT do not work with Squid as a proxy because of pipelining default
Petter Reinholdtsen writes: > [Roger Lynn] >> But apt has been using pipelining for years. Why has this only just >> become a problem? > > It has been a problem in Debian Edu for years. Just recently I > figured out the cause and a workaround. And FWIW I have experienced this problem for years too, but never figured out why until this discussion came up. And I do want to claim more than common user knowledge of http proxy servers. Still, it never occured to me that my spurious apt problems could be caused by proxies. And no, it's not just squid - I've been seeing the exact same at work where the office network have some intercepting proxy solution from websense. Anyway, this is definitely the type of problem that can and do exist for years without that necessarily causing a massive number of bug reports against apt. I still do not think that is an argument against fixing it? Can we please agree that in the real world 1) RFC1123 beats any other standard: "Be liberal in what you accept, and conservative in what you send", and 2) http proxy servers cannot always process pipelined requests due to the complexity this adds (complexity is always bad for security), and 3) http clients cannot know whether their requests are proxied ? The sum of these three points is that a http client should never send pipelined requests. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vdak5lkg@nemi.mork.no
Re: Bug#575209: closed by Holger Levsen (Re: Bug#575209: general: Error resolving hostname [resent])
Fabian Greffrath writes: > - Sites with domain names like do already exist! > Do you think they should be accessible by any other proprietary > operating system, but not Debian? Not really! Anyone can enter bogus data in the DNS. Neither the existence of such data nor the failure to detect it by other operating systems are arguments for allowing it in Debian. Literally anyone can add an invalid A record and make an OS which accepts it. > - There is already an inconsistency among the different > implementations in Debian (or Linux as a whole), as e.g. ping and any > other program using gethostbyname() fail to resolv, whereas nslookup > and host succeed. This is not an inconsistency. gethostbyname(), getaddrinfo() etc look up hostnames, whereas dig, nslookup and host query the DNS. The distinction is that almost anything is allowed in DNS, while a hostname must obey the updated version of RFC 952 (as amended by RFC 1123). See e.g. http://www.mail-archive.com/dn...@ietf.org/msg01731.html for an excellent explanation of the difference. > - The advice in the cited RFC is already ignored. Domain names that > start with a digit, e.g. 12345.foo.bar, can be resolved, whereas the > RFC tells us "They [labels] must start with a letter, end with a > letter or digit [...]". So let's just relax the rules in the RFC (they > are only recommendations after all) a bit more to also allow hyphens > as border characters in labels. It doesn't harm anyone, it just > enables us to resolv a few more actual domain names! This rule has been formally changed by the standards track RFC 1123. That is something quite different than "the cited RFC is already ignored"! > the advice of RFC 1035 which is the standards track RFC describing the *domain name system* which is so much more than host names. It is irrelevant wrt the discussion of valid hostnames. Unfortunately this RFC is one of the most confusing ever written, mixing a lot of irrelevant informational data with the actual standard. It should have merely referred to RFC 822 (updated several times) and RFC 952 (amended several times) for the restrictions on valid mail and host names. The verbose examples copying restrictions imposed by other standards have always been confusing, and of course even more so after the other standards were changed... > RFC 1178: which is an informational RFC. > RFC 952: which is the standards RFC describing valid hostnames. This should be obeyed, as amended by other RFCs. > RFC 1123: which is a standards track RFC updating and clarifying lots of other standards. Among the changes is the modification of RFC 952 wrt labels starting with a digit. You forgot to mention RFC 2181 which is a standards track RFC trying to fix a few of the errors in RFC 1035, among those the mixture of standard requirements and informational text. Although as irrelevant to this discussion as RFC 1035 itself, I believe it helps understand the distinction between valid DNS labels and valid host or mail names. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874ok4o80p@nemi.mork.no
Re: defaulting to net.ipv6.bindv6only=1 for squeeze
Jarek Kamiński writes: > Yes. Following code actually works (runs with bindv6only enabled, > listens on [::]:1234 and accepts connection made to localhost:1234): I'm sure it works. But I wanted to note that "localhost" is somewhat ambigious. It may include ::1 ipv6-pppoe-1:~# grep localhost /etc/hosts 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback ipv6-pppoe-1:~# host localhost localhost has address 127.0.0.1 localhost has IPv6 address ::1 You'd better test 127.0.0.1:1234 explicitly if that's what you want. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Has Debian abandoned Python?
Luk Claes writes: > This discussion on -devel is quite useless and contra productive for > everyone involved. > > There is currently discussion ongoing about how to move forward, though > due to the complex nature of the current situation (where also lots of > FUD etc is on the lists), it is being dealt in private. That discussion is quite useless and contra productive for everyone involved. Well, I don't know do I? So I'm going to assume it is. Thanks for trying to make things even worse. I realise that there has been too much flaming in this thread. But please try to grasp the real problem: NO COMMUNICATION is the problem. You just contributed to that. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Has Debian abandoned Python?
Ana Guerrero writes: > If you really want to help, read the mail archive of the debian-python > mailing list [1] (optionally hang out in the IRC channel), and get > an idea of what the problem is. > I also advise to take a look to the archive to people participating > in this thread who has not been following the list. If you are lazy, > just look for all the emails from Matthias in the python list. > > Ana > > [1] http://lists.debian.org/debian-python/ This is good advice, so I went looking there to find out what it's all about. And you were definitely right: The mailing list archive fully demostrates the complete lack of communication and cooperation from the maintainer, which seems to be the main problem with python at the momemt This is the only python3 relevant article I found from Matthias Klose: http://lists.debian.org/debian-devel/2009/02/msg00431.html So 16 Feb 2009 he wrote "I will start uploading python2.6 and related packages, then proceed with python3.x in the next weeks." Did I miss any updates after this? If so, do you have a direct thread link to that discussion? Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Permissions of /var/mail/$USER
Nicolas François writes: > When an user is created, useradd creates a /var/mail/$USER mailbox with > the mode 0660 (owned by $USER:mail). > > I heard this causes some issues for dovecot, and a solution could be to > move to mode 0600. Where did you hear this? Exactly what did you hear? Is this documented in a bug report? Maybe some reference(s) to the bug report(s) would make it easier for the rest of us to understand the issues? > Here is an extract from the Debian policy: > > Mailboxes are generally either mode 600 and owned by or mode > 660 and owned by `:mail'[3]. The local system administrator may > choose a different permission scheme; packages should not make > assumptions about the permission and ownership of mailboxes unless > required (such as when creating a new mailbox). Anyway, doesn't this make any dovecot issue a policy violation? Or am I misunderstanding the "packages should not make assumptions about the permission and ownership of mailboxes" part? Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Josselin Mouette writes: > Le lundi 07 septembre 2009 à 20:00 +0200, Giacomo A. Catenazzi a > écrit : >> Steve Langasek wrote: >> > Case 1, please. Either case 2 fails to handle the allocation error, or >> > glib >> > is doing its own abort. Neither is acceptable. > > Yeah, sure. As if there was anything more sensible to do than aborting > when a memory allocation fails. When this happens under Linux, the > application will end up OOM-killed really soon anyway. Even so, case 1 documents the author's intentions. Case 2 leaves us wondering whether the abort is intentional or not. Trusting a library to do all your error handling and cleanup is not good style IMHO. In addition to the lack of self-documenting source, it often leave you with the meaningless generic error messages some OSes are so full of. Applications doing their own error handling are in a much better position to provide specific meaningfull error messages to the user. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Patch Tagging Guidelines (aka DEP3)
Raphael Hertzog writes: > after several rounds of discussion on -devel, we now have a > new standard defining meta-information to integrate on patches that we > distribute/apply in our packages: > http://dep.debian.net/deps/dep3/ Just a minor comment on the examples: Please either use your own domain names or one of the names reserverd for examples. foobar.com is registered to Foobar Consulting. They're probably used to this kind of abuse, but still... See RFC 2606 for some names that can be used. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Josselin Mouette writes: > Le lundi 07 septembre 2009 à 11:48 +0200, Bjørn Mork a écrit : >> You're not seriously suggesting that DeviceKit-disks usage of g_print >> instead of printf is actually adding anything useful? > > Yeah sure, just look at g_print and not at the other symbols used by > devkit-disks-part-id : > g_free g_slist_free g_print g_strdup g_printerr g_slist_append > g_strdup_printf g_fprintf g_vfprintf g_strchomp g_strjoinv > g_slist_length g_malloc0 g_build_filename g_file_get_contents > g_utf16_to_utf8 g_strfreev g_slist_nth_data > > Are you suggesting that such an utility should implement its own linked > list structure, and unicode translation functions? I'm suggesting that the utility uses lots of "g_" prefixed functions while it's obvious that the author never ever evaluated the need for these. I assume that's because the author is used to them always being available. Well, in the context of udev helpers, they are not. Do you really need the g_utf16_to_utf8 unicode translation? You could just as well let udev export the raw utf16 value and leave the conversion up to the users. They may want something different than utf8 anyway. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Josselin Mouette writes: > Le vendredi 04 septembre 2009 à 19:32 +0200, Hendrik Sattler a écrit : >> It rather needs to raise the question why simple low-level tools use >> something >> like libglib? > > I’d rather raise the question why each of our simple low-level tools > implement its data structures and basic routines in its own fashion, > leading to bugs and security issues sometimes, instead of re-using the > ones from Glib. Oh, come on... Exactly what does glib add here: #define G_GNUC_PRINTF( format_idx, arg_idx )\ __attribute__((__format__ (__printf__, format_idx, arg_idx))) voidg_print (const gchar*format, ...) G_GNUC_PRINTF (1, 2); You're not seriously suggesting that DeviceKit-disks usage of g_print instead of printf is actually adding anything useful? The fact is that glib is nothing but a libc wrapper for the low-level usage we're talking about here. And as such, completely unnecessary. I wouldn't have cared if we were discussing ordinary desktop utilities. glib is of course available for them, and it doesn't matter whether you use the printf wrapper or not. But it is not an argument for moving glib to /lib. There is already a printf() in /lib. Use it. Or do you want to take your argument to the kernel as well? Maybe it should use the glib wrappers to avoid bugs and security issues? Right. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
m...@linux.it (Marco d'Itri) writes: > On your part, you could try to understand them instead of attributing to > me straw man positions. That's a good advice. Thanks. Please help me understand: What is the usb-db and/or pci-db use case? I'm afraid my creative imagination is far too limited to come up with something without help. All the ideas I have can easily be solved without involving udev at all. Maybe someone else has any suggestions? The helpers take the pci or usb vid/pid and look them up in pci.ids or usb.ids respectively, and then add the returned strings to the available udev info as ID_VENDOR_FROM_DATABASE and ID_MODEL_FROM_DATABASE. These strings can and will change over time, so they are pretty useless in rules. And the vid/pid combination is available for the rules anyway. And stable. The only possible use I can see is for printing pretty messages to the user. But I can't see why udev has to be involved in that. Any utility wanting to do that can just look up the strings in pci.ids or usb.ids themselves. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Hendrik Sattler writes:
> Am Freitag 04 September 2009 16:36:52 schrieb Michael Biebl:
>> devkit-disks-part-id and devkit-disks-probe-ata-smart both link against
>> libraries which are (currently) in /usr/lib, i.e.
>> devkit-disks-part-id links against libglib-2.0 (784K)
>> devkit-disks-probe-ata-smart links against (48K)
>>
>> This will mean, that we will need to install those two libs in /lib.
>
> It rather needs to raise the question why simple low-level tools use
> something
> like libglib?
> What does it use from libglib that it couldn't do without?
>From the looks of it: Nothing.
This is a code example from
http://cgit.freedesktop.org/DeviceKit/DeviceKit-disks/tree/src/part-id.c :
g_print ("DKD_PARTITION=1\n");
g_print ("DKD_PARTITION_SCHEME=%s\n",
//part_get_scheme_name (part_table_get_scheme
(partition_table_for_entry)));
part_get_scheme_name (part_table_get_scheme
(partition_table)));
g_print ("DKD_PARTITION_NUMBER=%d\n", partition_number);
g_print ("DKD_PARTITION_TYPE=%s\n", type != NULL ? type : "");
g_print ("DKD_PARTITION_SIZE=%" G_GINT64_FORMAT "\n", size);
g_print ("DKD_PARTITION_LABEL=%s\n", label != NULL ? label :
"");
g_print ("DKD_PARTITION_UUID=%s\n", uuid != NULL ? uuid : "");
g_print ("DKD_PARTITION_FLAGS=%s\n", flags_combined);
g_free (type);
g_free (label);
g_free (uuid);
g_strfreev (flags);
g_free (flags_combined);
} else {
g_print ("DKD_PARTITION_TABLE=1\n");
g_print ("DKD_PARTITION_TABLE_SCHEME=%s\n",
part_get_scheme_name (part_table_get_scheme
(partition_table)));
}
Looks like someone is unable to spell printf.
And it is also very unclear to me why this has to be in /lib/udev at
all. It seems to add nothing but redundant information and bugs. Maybe
the DDs could start asking upstream a few questions before blindly
accepting things like that? That might save them a few bug reports
later on.
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
m...@linux.it (Marco d'Itri) writes: > On Sep 04, Ron Johnson wrote: > >> Whatever the cause, it breaks the FHS. > Since it keeps being repeated, it is time to destroy this argument. > FHS documents what distributions want to do: of the other relevant > distributions, representatives from Red Hat and Suse said they do not > support this and except Debian nobody else raised the issue. The issue is most certainly raised by other distributions. See e.g. the thread starting with http://article.gmane.org/gmane.linux.gentoo.devel/62973 But I guess Red Hat and Suse decide. Debian does what they do, nobody cares about Gentoo, and Ubuntu does what Debian does. No, wait, they don't: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/372241 > I should stress that this is not related in any way to the merit of > supporting a standalone /usr, but if most distributions do not care > about it then it is FHS which needs to be fixed. Either you follow the FHS or you don't. You seem to argue that most distributions don't and that Debian therefore shouldn't either. That's sad. Please fix the FHS first if you think it should be fixed. Or leave it alone and fix udev instead. Personally I really can't see why these addons (usb-db,pci-db) are so important. Nobody has demonstrated a usecase for them. Yet you make it sound like there is no choice at all, but to include them in udev. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
m...@linux.it (Marco d'Itri) writes:
> On Sep 04, Bjørn Mork wrote:
>
>> Yes. Any device specific matching should use vid:pid. How about just
>> disabling the /lib/udev/{pci,usb}-db helpers alltogether to avoid ever
>> getting any users of this info in Debian? It will always be too
>> unreliable to be useful anyway, regardless of /usr availability.
> So you believe that the upstream maintainers are incompetent and
No, I do not think they are incompetent. I think they have a hard job
trying to port features from hal to udev-extras without repeating all
the mistakes. I realize that hal have many users who presumably are
wanting to push all interfaces they use into udev.
> released something which is unreliable by design?
Do /lib/udev/{pci,usb}-db provide any reliable additional information?
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
Steve Langasek writes:
> I still can't fathom why someone decided that udev should be responsible for
> translating PCI IDs and USB IDs into text strings. This smells of crazy.
Yes. Any device specific matching should use vid:pid. How about just
disabling the /lib/udev/{pci,usb}-db helpers alltogether to avoid ever
getting any users of this info in Debian? It will always be too
unreliable to be useful anyway, regardless of /usr availability.
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Serious problem with geoip - databases could not be build from source
"Giacomo A. Catenazzi" writes: > 5) We create a new free database. > > I don't think is too difficult, and I think we would have support > also at high level. > But it needs a lot of communication works: the term of service of > IANA and the RIRs (Regional Internet Registry) forbid to spider and > publish data. OTOH I really think they will make an exception for > us, or in general for such good networking data. > > Somebody would help me contacting and convincing the RIRs about > a free geoIP database? I believe such usage can be considered within the RIRs AUPs, provided that you follow their guidelines for bulk downloads and only redistribute a small subset of the data (i.e. only the country attribute of the inetnum objects). You are aware of the GPLv3 licensed database at http://software77.net/geo-ip/ ? This database is used by Geo::IPfree, and probably other applications already part of Debian. Or did you want to provide more precise mapping than just IP to country? If so, then I'm afraid the RIRs won't help you much anyway. They don't collect that sort of geographic detail. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#535833: marked as done (general: Slow internet on iceweasel, epiphany and so on...)
Tollef Fog Heen writes: > ]] Roger Leigh > > | Having working local networking is important. We wouldn't consider > | broken IPv4 loopback acceptable, and broken IPv6 loopback is just as > | bad. > > Sure, having it working is important. Is it more important than keeping > those (often new) users for whom Debian appears useless because of its > perceived poor network performance? I don't think measuring the importance of these bugs against each other is going to be productive. Workarounds for bugs in other systems are fine, but not adding bugs in Debian should be an absolute requirement for such workarounds. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching /bin/sh to dash (part two)
Clint Adams writes:
> -idl=$(ls /etc/init.d/${service} 2> /dev/null | head -n 1)
> +idl="/etc/init.d/${service}"
> if [ -n "$idl" ] && [ -x $idl ]; then
You might as well remove the -n test if you do this. There's not much
chance of hitting it anymore...
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ignoring the CoC in regards to cc:s
Josselin Mouette writes: > I’m not subscribed to any list which set the Reply-To header. Could you > at least show some examples of such lists in the free software world? What's "the free software world"? Is that a separate networking domain, or is it connected to the Internet? Anyway, here are a few examples of mailing lists which set the Reply-To header: FreeRADIUS Users' List: http://freeradius.org/list/users.html Linux-Thinkpad List: http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad Load Balancing List: http://vegan.net/mailman/listinfo/lb-l Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff?
Josselin Mouette writes: > Mail-Followup-To is: > A. Useless junk without clear semantics > B. Violating standards Which standards would that be? Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff?
Holger Levsen writes: > On Montag, 27. April 2009, Noah Slater wrote: >> * The Debian lists do not have a Reply-To header, > > does someone know why? I don't know, but there are plenty of reasons to choose from. See e.g. http://www.unicom.com/pw/reply-to-harmful.html Those not wanting redundant CCs should also read http://cr.yp.to/proto/replyto.html Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Henrique de Moraes Holschuh writes: > On Sun, 26 Apr 2009, Matthew Garrett wrote: > >> Hal checks the drive capabilities and shouldn't be polling drives that >> support async notifications. Is that code not working for you? > > It is working fine, thanks for the head's up about it disabling the poller > on AN-capable devices (my laptop is not one of them, but I found one which > can do that to test). Really? Please correct med if I'm wrong. I assume you are talking about the test in hald/linux/blockdev.c which sets storage.removable.support_async_notification based on the flags exported by the kernel in /sys/block/*/capability? I cannot see how this can work at the moment. There doesn't seem to be any driver setting the GENHD_FL_MEDIA_CHANGE_NOTIFY flag yet. Or am I missing something? Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#525481: Wrong usage of gnome proxy settings
Mike Hommey writes: > On Sat, Apr 25, 2009 at 09:56:54AM +0200, Giuseppe Sacco wrote: >> Il giorno ven, 24/04/2009 alle 22.30 +0200, Mike Hommey ha scritto: >> [...] >> > I'm not sure iceweasel uses gnome settings, but uses what gnome exports >> > in the *_proxy environment variable. Can you check what they look like? >> >> giuse...@scarafaggio:~/src/django/mberi$ env | grep prox >> http_proxy=http://192.168.1.53:3128/ >> no_proxy=localhost,127.0.0.0/8,192.168.0.0/16,scarafaggio > > I'm pretty sure iceweasel doesn't support the CIDR notation (e.g. > 127.0.0.0/8). > > I'm not sure if this has to be considered a bug in gnome or a lack of > feature in iceweasel... I'm not even sure other stuff like this > format either (like lynx, links, python's urllib, etc.) > > Fellow developpers, what do you think? The usage of no_proxy is documented on http://www.w3.org/Daemon/User/Proxies/ProxyClients.html "the contents is a comma-separated list of domain names, with an optional :port part" Any further extensions to this scheme cannot be guaranteed to work. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Michael Biebl writes: > See the hal-disable-polling man page. In short: hardware support for MMC media > change notification is broken. Err. You are using the "broken firmware" argument both ways. You should follow your own advice regarding the drives spinning up: Implement a blacklist of devices with broken MMC media change notification and only poll devices in this blacklist. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Matthew Garrett writes: > powertop makes various recommendations that are only useful in very > specific circumstances. Disabling polling in hal saves you a small (and > probably not useful in the real world) amount of power, but is required > to get to the number of wakeups per second that Arjan was aiming for. I > haven't been able to measure any difference in power consumption on a > typical system. I'm sure you know this, but others may not be aware of it... Modern systems have the ability to put inactive devices in a low power state to save power. See for example http://www.lesswatts.org/projects/devices-power-management/ You'll save between 0.5 and 1.5 W by enabling SATA Aggressive Link Power Management according to http://www.lesswatts.org/tips/disks.php As this definitely is measurable, I assume that your measurements have been done without enabling ALPM? Or maybe the power saving estimated by lesswatts is based on normal hard drive usage? Could you please share the details of what you've measured? Which type of drives, controllers and drivers are used in a "typical system"? How about a "typical laptop" (which in my world is the only system class where this matters anyway)? How about "modern laptop" (AHCI controller, SATA DVD)? Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Josselin Mouette writes: > If it’s just your decision, why are you bitching on this list? That's a good question. It was fun for a while. But I think the spectators are getting a bit bored. I'll stop now. Thanks for your answers. Believe it or not, but I've learned a lot about hal from this discussion. I might even find it useful in the end :-) Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Josselin Mouette writes: > Le lundi 20 avril 2009 à 10:26 +0200, Bjørn Mork a écrit : >> I prefer non-broken defaults. hal defaults are broken. No, the keys are >> not always mapped to standard XF86* names. They are sometimes mapped >> into the blue. >> >> See e.g. bug #504643, which explains my disappearing keys. Finding it >> took some time, since stupid me thought "regrep KEY_RADIO /usr/share/hal". >> would reveal any hal related problems. > > So, the HAL defaults are broken *for one keyboard model*. Make that "for every keyboard I'm using". Why would the number of working keyboards matter? If you care about such statistics you should probably use Windows. It works for far more people than Debian does. > Geez, without > HAL your function keys wouldn’t actually work at all Well, it did work with acpid as long as the kernel supported /proc/acpi/event. No need for hal at all those days. > for many models > without jumping through incredible hoops or installing specific > software. I can’t believe you think this should be encouraged. You still need the specific software to actually do something useful in response to these keys. It's not like they are supposed to generate some character in your terminal. They are supposed to trigger some action, like e.g. switching video outputs or enabling bluetooth. AFAIK, you won't get around the specific software requirement. > There are bugs? Fine, let’s fix them. Doesn't look like anybody really does that. 5 months and 4 releases without fixing a trivial bug like this? Looks non-maintained to me. >> You don't seriously beleive that I'm going to trust hal while it's in a >> state like this, do you? > > So you found one bug in HAL, and you deem it unsuitable for everyone? No, I don't. You really could need a copy of "Reading for Dummies". *I'm* not going to trust hal. Everyone else should make their own decision. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Josselin Mouette writes: > Le jeudi 16 avril 2009 à 15:06 +0200, Bjørn Mork a écrit : >> >> a) laptop keys remapped or disappearing (might be caused by the driver - >> >>I don't know) >> > >> > Yes, they are remapped to the standard XF86* names, so that applications >> > configuring shortcuts can have sensible defaults. >> >> So you justify breaking existing setups by claiming the new >> configuration is more "sensible". How many times? How often? > > If you know how to homogenize keycodes between different keyboard models > without actually changing the keycodes, good for you, but I don’t. > > Also, do you prefer configuring a keycode named “0xae” or > “XF86AudioLowerVolume”? I prefer non-broken defaults. hal defaults are broken. No, the keys are not always mapped to standard XF86* names. They are sometimes mapped into the blue. See e.g. bug #504643, which explains my disappearing keys. Finding it took some time, since stupid me thought "regrep KEY_RADIO /usr/share/hal". would reveal any hal related problems. This bug will bite every ThinkPad-user when /proc/acpi/event is removed and we are forced to replace acpid functionality (already so in the latest squeeze kernels). And the cause is a simple case of a broken default key remapping, reported more than 5 months ago. Open through several new releases of hal-info. You don't seriously beleive that I'm going to trust hal while it's in a state like this, do you? >> >> b) unwanted auto-mounting >> > >> > HAL will not do auto-mounting by itself. Some user-level daemon must be >> > listening for events and requesting the actual mount. >> >> The auto-mount support in hal is unwanted even without such daemons. >> Continously polling all removable storage is a very bad default IMHO. >> And why do it if there's no daemon listening for the events anyway? > > You’re mixing apples and oranges. I'm sure you're right. You see, there is no documentation for the oranges, which may have made me assume they are fruit just like the apples. The hal default "polling removable disks" is annoying, useless, and an example of bad hal design. You may of course continue to ignore this by claiming that I don't know what I'm talking about. Unfortunately, it won't do much more that continue to document hal as a dead-end with a big "STAY AWAY!" warning sign. You might as well implement a popup asking the user if (s)he is present every 30 seconds. I'm sure it would be very useful for hal to know, and it woulb be only slightly more annoying than the disk polling. Yes, I do know that the most annoying features can be disabled. My concerns are the bad Debian default values, not the features themselves, combined with forcing these packages on the user. There's absolutely no excuse for forcing every X user to accept all the bogus key remapping in hal-info. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Josselin Mouette writes: > Le jeudi 16 avril 2009 à 00:34 +0200, Bjørn Mork a écrit : >> My list of hal related regressions are >> a) laptop keys remapped or disappearing (might be caused by the driver - >>I don't know) > > Yes, they are remapped to the standard XF86* names, so that applications > configuring shortcuts can have sensible defaults. So you justify breaking existing setups by claiming the new configuration is more "sensible". How many times? How often? Every breakage is still a regression in my eyes. >> b) unwanted auto-mounting > > HAL will not do auto-mounting by itself. Some user-level daemon must be > listening for events and requesting the actual mount. The auto-mount support in hal is unwanted even without such daemons. Continously polling all removable storage is a very bad default IMHO. And why do it if there's no daemon listening for the events anyway? Yes, I know it can be disabled. Having to disable such things to avoid power consumption, noise and wear regressions is still annoying. An the design sucks. Daemons wanting events from a polling source should register with the poller, and polling should be disabled by default until such a daemon registered itself. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Julien Cristau writes: > On Wed, 2009-04-15 at 10:25 +0200, Bjørn Mork wrote: >> Well, you can always argue that the rest can be fixed. Provide patches >> etc. But the point is that hal implies a regression for many (most?) >> users. > > please stop the FUD. Sorry. You're right. That was uncalled for. The introduction of hal has caused a few new problems for me, but I don't know anything about most users. My list of hal related regressions are a) laptop keys remapped or disappearing (might be caused by the driver - I don't know) b) unwanted auto-mounting c) the keyboard problem described below >> hal breaks existing working configurations without warnings. The simple >> test case is using a non-US keyboard properly configured as such in >> xorg.conf. Introduce evdev/hal and watch users get frustrated. The >> problem of course: keyboard layout cannot be auto-configured. But why >> ignore existing configuration? >> > we don't ignore existing keymap configuration, and you get the same > layout after the upgrade as was configured in xorg.conf. OK. I did not. But I guess that's something that's changed with recent console-setup changes? Some testing now reveals that you're right: I now get a Norwegian keyboard layout for every keyboard like device no matter what I write in xorg.conf. That's still confusing to me. I did manage to locate the settings in /etc/default/console-setup. But it's still unclear how to handle multiple input devices using this facility. Not that it matters much, but I find it a bit strange that the "ThinkPad Extra Buttons" and "Video Bus" devices are configured as 105 keys keyboards with Norwegian layout: (**) ThinkPad Extra Buttons: always reports core events (**) ThinkPad Extra Buttons: Device: "/dev/input/event8" (II) ThinkPad Extra Buttons: Found keys (II) ThinkPad Extra Buttons: Configuring as keyboard (II) XINPUT: Adding extended input device "ThinkPad Extra Buttons" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "pc105" (**) Option "xkb_layout" "no" (**) Option "xkb_options" "lv3:ralt_switch" (II) config/hal: Adding input device AT Translated Set 2 keyboard (**) AT Translated Set 2 keyboard: always reports core events (**) AT Translated Set 2 keyboard: Device: "/dev/input/event1" (II) AT Translated Set 2 keyboard: Found keys (II) AT Translated Set 2 keyboard: Configuring as keyboard (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "pc105" (**) Option "xkb_layout" "no" (**) Option "xkb_options" "lv3:ralt_switch" (II) config/hal: Adding input device Video Bus (**) Video Bus: always reports core events (**) Video Bus: Device: "/dev/input/event5" (II) Video Bus: Found keys (II) Video Bus: Configuring as keyboard (II) XINPUT: Adding extended input device "Video Bus" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "pc105" (**) Option "xkb_layout" "no" (**) Option "xkb_options" "lv3:ralt_switch" >> I still haven't got a clue how to really fix this, but have resorted to >> this for now: >> >> >> >> >> >> pc105 >> no >> >> >> >> >> IMHO, this is an ugly hack. I never wanted to configure hal. > > that's fine, you don't have to. You're right. This seems to be taken care of by console-setup now. It was not when I created this file (which I did not do just for fun, although writing XML config files is my idea of a fun night :-) >> I wanted >> to configure X. In fact, I already had a working X configuration so I >> didn't expect to configure anything at all... >> >> Yes, I expected things to "just work", given that it did prior to using >> evdev/hal. hal broke that expectation. > > no, it didn't. you're just spreading nonsense. I think we might have different interpretations of "work". Suddenly ignoring xorg.conf changes in favour of a new config file without any clear (to me at least) indication how to restore previous behaviour is 1) unexpected 2) broken IMHO. You are of course free to have a different opinion. I just wanted to register mine. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Julien Cristau writes: > On Sun, 2009-04-12 at 14:04 +0200, Michael Meskes wrote: >> On Mon, Apr 06, 2009 at 09:55:39PM +0200, Michael Biebl wrote: >> > As (co-)maintainer of pm-utils and hal, I'd prefer if we could work towards >> > standardizing on one power management stack in Debian (and not install 3 by >> > default [1]), i.e. I'd support in phasing out acpi-support and would gladly >> > accept patches for hal and pm-utils which add (if there are) any missing >> > bits >> > from acpi-support. >> >> Not sure whether most users agree after reading #515214. > > 515214 isn't most users. most users just want things to work. False. All users want all things to work. The "just" is nice to have, but not important. It's infinitely better to have to configure things than not being able to. But I think you're on to the problem: It's true that hal makes most things work. The rest can't be made to work if you use hal. Or at least require you to configure a new, non-intuitive, complex system. #515214 is about the rest, the way I read it. Well, you can always argue that the rest can be fixed. Provide patches etc. But the point is that hal implies a regression for many (most?) users. It provides no new (visible) funcionality, but adds complexity and lots of bugs by making auto-configuration override previous local configuration. That's got to be wrong. hal breaks existing working configurations without warnings. The simple test case is using a non-US keyboard properly configured as such in xorg.conf. Introduce evdev/hal and watch users get frustrated. The problem of course: keyboard layout cannot be auto-configured. But why ignore existing configuration? I still haven't got a clue how to really fix this, but have resorted to this for now: pc105 no IMHO, this is an ugly hack. I never wanted to configure hal. I wanted to configure X. In fact, I already had a working X configuration so I didn't expect to configure anything at all... Yes, I expected things to "just work", given that it did prior to using evdev/hal. hal broke that expectation. The same goes for the suspend/resume support. I have an existing working configuration, using acpi-support and pm-utils. There is absolutely no upside to me moving this to hal and some power-daemon. It just obfuscates the configuration, making GUI configuration utilities mandatory and leaving me reading c++ bloat instead of some simple shell script to find out why things didn't work as expected. Just my .02 € as an ordinary user. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: lilo about to be dropped?
Samuel Thibault writes: > Giacomo Catenazzi, le Wed 08 Apr 2009 19:47:55 +0200, a écrit : >> Samuel Thibault wrote: >> >> I installed grub (and Debian). Trying the Windows hidden partition >> >> (to install windows), grub stopped working (it was rescue mode, but >> >> without capability to rescue something). Also rescue disk + >> >> reconfiguring + update-grub did nothing. >> > >> > Err, did you re-run install-grub? >> >> No ;-) only update-grub and >> dpkg-reconfigure -plow grub-pc grub-common > > Then little wonder. update-grub only updates menu.lst. > >> I was expecting that reconfigure will do the right things, > > grub maintainers considered that it's a bad thing to automatically > reinstall things in a MBR. You need to re-run grub-install to do that. Is there some easy way to find out what is installed where? Trying to use grub/grub2, I've often wondered: Is my grub installation on /dev/sda a) complete? or did some other OS/RAID controller/whatever overwrite parts of it? b) uptodate? or did I forget to run grub-install after upgrading the grub package c) identical to the /dev/sdb mirror?" or did I forget to run grub-install after replacing /dev/sda? Some scripts answering these questions would really be helpful. Yes, I know. Send patches. Might do. Or just go for extlinux, which seems to DTRT for me. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
Ben Hutchings writes: > On Mon, Mar 16, 2009 at 01:08:04PM +0100, Bjørn Mork wrote: > >> mii-tool may not be meant for scripts, but I for one have used it in >> the past to force speed/duplex like this: >> >> iface eth1 inet static >> address 10.122.226.9 >> netmask 255.255.255.192 >> up /sbin/mii-tool -F 100baseTx-FD eth1 >> >> I'm pretty sure I'm not the only one... > > You can do this with ethtool now, and more cleanly: > > link-speed 100 > link-duplex full Yes, I know. But that means that existing working configurations have to be modified. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
Martín Ferrari writes: > Problematic tools: > * mii-tool: it could be dropped and replaced by a pointer to ethtool as > it's not meant to be used automatically by scripts. On the other hand, > it's distributed as a stand-alone tool [0] and we could do the same. A couple of notes: mii-tool and ethtool use different driver interfaces which I'm pretty sure aren't completely overlapping for all drivers in the kernel mii-tool may not be meant for scripts, but I for one have used it in the past to force speed/duplex like this: iface eth1 inet static address 10.122.226.9 netmask 255.255.255.192 up /sbin/mii-tool -F 100baseTx-FD eth1 I'm pretty sure I'm not the only one... I fail to see the value of removing mii-tool. I'd rather see just the non-working features removed in favour of an ethtool recommendation. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
Josselin Mouette writes: > Le vendredi 27 février 2009 à 14:33 +0100, Raphael Hertzog a écrit : >> On Fri, 27 Feb 2009, Joerg Jaspert wrote: >> > Like the other poster, cli is very confusing. If we have enough >> > packages (get me a list/matches :) ), im not against a section for it, >> > but cli wouldnt be my favorite name for it. >> >> I would suggest "c-sharp" for the section. > > The CLI is not restricted to a single language support. How are you > going to classify IronPython or boo ? How about those knowing what Common Language Infrastructure is about, trying to describe it in a somewhat less ambigious way than "cli"? Take a look at http://en.wikipedia.org/wiki/CLI Can't speak for anyone else, but I would certainly think "command-line interface" if I encountered a section named "cli". Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#516659: ITP: w3bfukk0r -- scan webservers for hidden directories (forced browsing)
Noah Slater writes: > On Sun, Feb 22, 2009 at 05:18:39PM -0800, Asheesh Laroia wrote: >> I think that the description explains that the purpose is to find hidden >> directories on web servers, presumably either your own or other people's. > > Why would you need to find directories on your own server? Why would you need to buy a gadget like http://www.keyringer.com/ ? Bjørn -- Let me tell you something, you capitalist, Napoleon is just a figment of your imagination -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#509063: ITP: libproxy -- automatic proxy configuration management library
Florian Weimer writes: > * Emilio Pozuelo Monfort: > >> Description : automatic proxy configuration management library >> >> libproxy is a lightweight library which makes it easy to develop >> applications proxy-aware with a simple and stable API. > > WPAD is a broken protocol with security issues inherent to the DNS > devolution mechanism (which is also performed by libproxy). Agreed. Still, it is implemented and used by a number of web proxy using applications. > Please don't add implementations to the Debian archive. Isn't the intention to replace existing and future implementations with this library, thereby confining security issues to a single library? How many WPAD implementations are there currently in the archive? Won't adding this library be an improvement in the long run? I would very much like this library to become the *only* WPAD implementation anywhere. Hopefully eventually with some ability to define local policies, where the default Debian policy could be very strict. E.g. "Never trust DNS for WPAD", or "Never use WPAD at all". Bjørn -- How can you say that trees are bad -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#457318: qmail and related packages in NEW
Gerrit Pape <[EMAIL PROTECTED]> writes: > Hi, I'm quite surprised how the inclusion of qmail and related packages > into sid is handled, or rather not handled, by the ftpmasters. I downloaded the netqmail source from http://dbn.smarden.org/sid/ and looked briefly at it, to see if most of the well-known (some of the for 10+ years!) bugs have been fixed. Unfortunately, it doesn't seem so. The Debian packaging included surprisingly few patches, and the fixes I tested still applies to the Debian package. e.g: [EMAIL PROTECTED]:/usr/local/mydebs/tmp/netqmail-1.06$ patch -p0 --dry-run < ../patch-qmail-1.03-rfc2821.diff patching file qmail-remote.c [EMAIL PROTECTED]:/usr/local/mydebs/tmp/netqmail-1.06$ patch -p0 --dry-run < ../patch-qmail-1.03-rfc1652.diff patching file ./qmail-smtpd.c Hunk #1 succeeded at 229 with fuzz 1. To avoid having packages starting their Debian life with a long list of serious and grave bugs, may I suggest that you take a look at http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html [1] and either include the patches or use the suggested workarounds? Bjørn [1] This page refers to http://home.pages.de/~mandree/qmail-bugs.html as its canonical location but I'm currently unable to open the latter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail and related packages in NEW
Moritz Muehlenhoff <[EMAIL PROTECTED]> writes: > We've discussed this at the Security Team meeting in Essen and we don't > have a problem with qmail being included in Lenny. You are aware of upstream's attitude towards security holes? There are lots of assumptions like "nobody will ever do ...". E.g, quoting from http://cr.yp.to/qmail/guarantee.html : In May 2005, Georgi Guninski claimed that some potential 64-bit portability problems allowed a ``remote exploit in qmail-smtpd.'' This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits. And as we all know, nobody needs more than 640 kB RAM anyway :-) Bjørn -- If you've seen one Jewish grandmother, you've seen them all, huh? So, Mexican people are inherently superior to old people -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OpenPGP smartcard and Debian
Luca Capello <[EMAIL PROTECTED]> writes: > [2] http://www.g10-code.de/p-card.html I assume this was supposed to be http://www.g10code.de/p-card.html Bjørn -- Luser -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#497476: ITP: gw6c -- Client to connect to IPv6 tunnel brokers
Craig Small <[EMAIL PROTECTED]> writes: > Package: wnpp > Severity: wishlist > Owner: Craig Small <[EMAIL PROTECTED]> > > * Package name: gw6c > Version : 5.1 > Upstream Author : Hexaco > * URL : http://go6.net/4105/download.asp > * License : BSD > Programming Lang: C > Description : Client to connect to IPv6 tunnel brokers > > TSP is a control protocol used to establish and maintain static tunnels. > The Gateway6 client (gw6c) is used on the host computer to connect to a > tunnel broker using the TSP protocol and to get the information for its > tunnel. When it receives the information for the tunnel, the Gateway6 > client creates the static tunnel on its operating system. What's the advantage of this client over the already packaged tspc? Bjørn -- I firmly believe that JFK's ghost is living in your bug fix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is it a "user error" to use lilo?
maximilian attems <[EMAIL PROTECTED]> writes: > kernel-img.conf does not pertain to any package, this is meant to be solved > postlenny by linux images using debian kernel toolkit [1] > > kind regards > > -- > maks > > [1] http://multibuild.org/documentation/dkt Sounds good! Thanks for the pointer. But I'm afraid my curiousity wasn't completely satisfied by that link. Seems like it hasn't been updated since the initial discussion of the project a year ago(?) At the moment, http://svn.debian.org/wsvn/kernel/people/waldi/dkt/ seems to be the best source of information about this project. Is that correct? Bjørn -- Only a peasant like you would say that "Head-for-the-mountains" Bush is a spaz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is it a "user error" to use lilo?
maximilian attems <[EMAIL PROTECTED]> writes: > On Wed, Aug 27, 2008 at 09:07:29AM -0500, William Pitcock wrote: >> >> If you have both GRUB and LILO installed, there will be problems. That >> is infact, a bug. They should Conflict with each other to ensure that >> only one can be installed at a time, but it is a minor bug at best, as >> any smart user would not have both bootloaders installed. And infact, >> any typical user would not install a second bootloader. > > things are sorted by the run_bootloader variable in /etc/kernel-img.conf > > user had switched from lilo to grub without changing this preference, > thus user error. Maybe the need for this change should be somewhat more explicit? /usr/share/doc/grub/README.Debian.gz does mention it, but the absolute need to change the setting is not at all clear to me: update-grub --- This script is a debian specific addon used to generate a menu.lst for you either intially, and/or automatically everytime you install a new kernel. To setup automatic updates add these lines to your /etc/kernel-img.conf: postinst_hook = update-grub postrm_hook = update-grub do_bootloader = no For further information see the manpage kernel-img.conf(5) or update-grub(8) Unlike Lilo, it is not necessary to re-run or re-install the boot loader after every change to /boot/grub/menu.lst. menu.lst is automatically found on GRUB's root disk and read during GRUB's boot process. This seems to just deal with automatic updates. Now, what if I don't want to regenerate /boot/grub/menu.lst, would I still understand that I should set "do_bootloader = no"? Maybe. But what if I wanted to ensure that the grub boot block always is up-to-date (even if it's not really necessary). Without this discussion, I would probably have assumed that "do_bootloader = yes" would do that for me. I cannot find anything documenting do_bootloader as a lilo-specific setting in any of kernel-img.conf(5), update-grub(8), /usr/share/doc/grub/README.Debian.gz or /usr/share/doc/lilo/README.Debian I believe both /usr/share/doc/grub/README.Debian.gz and kernel-img.conf(5) should make it clear that you need to set "do_bootloader = no" unless you want lilo automatically installed. Bjørn -- You must be a real dogmatist to think that it's a wonderful day -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is it a "user error" to use lilo?
William Pitcock <[EMAIL PROTECTED]> writes: > If you have both GRUB and LILO installed, there will be problems. That > is infact, a bug. They should Conflict with each other to ensure that > only one can be installed at a time, but it is a minor bug at best, as > any smart user would not have both bootloaders installed. And infact, > any typical user would not install a second bootloader. Well, since I'm obviously not a smart user I can continue to ask the stupid questions :-) What is the recommended procedure for changing from e.g. lilo to grub? Since you plan to drop lilo post-lenny, I guess this will be a quite common question during the lifetime of lenny. Users will notice that lilo is being deprecated and wonder how to switch. Maybe something to document in either lilo or grub? or both. Bjørn -- Why, the rich people have really got it all together -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is it a "user error" to use lilo?
maximilian attems <[EMAIL PROTECTED]> writes: > kernel-img.conf(5) has nothing to do with initramfs-tools. > there you'll find do_bootloader documented. I am glad you are referring to this man page. I found myself looking for it a while ago, surprised to find that it wasn't installed on the system in question. A little searchin told me that was because it's part of kernel-package and therefore not installed on most systems having a /etc/kernel-img.conf file. Maybe this essential documentation should be split out to a separate package depended on by initramfs-tools, linux-image-* and possibly other packages using /etc/kernel-img.conf? Bjørn -- You must be a real weasel to think that if you've seen one source license, you've seen them all -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possible mass bug filing: The possibility of attack with the help of symlinks in some Debian packages
"Dmitry E. Oboukhov" <[EMAIL PROTECTED]> writes:
> On 18:42 Wed 13 Aug , Brian May wrote:
>> Dmitry E. Oboukhov wrote:
>>> qemu makes mount the directory /tmp/mount.$$. Attacker creates many
>>> symlinks /tmp/dir.\d+ -> /etc and if qemu
>>> (/usr/sbin/qemu-make-debian-root) starts then /etc goes
>>> out from root directory tree. The result: system is unusable.
>>>
>> I might be dense, but I don't get this.
>
>> Attacker does:
>
>> [EMAIL PROTECTED]:/tmp# ln -s /etc /tmp/mount-1234
>
>> Then the genuine user does:
>
>> [EMAIL PROTECTED]:/tmp# mkdir /tmp/mount-1234
>> mkdir: cannot create directory `/tmp/mount-1234': File exists
>
>> strace shows:
>> mkdir("/tmp/pmount-1234", 0777) = -1 EEXIST (File exists)
>
>> So, ok, this means the process can't continue any more (denial of
>> service attack), and if the process does continue this is a problem,
>> otherwise I can't see how this would bring the entire system down.
>
>> Brian May
>
> yes, set -e directive is present in this script :)
Don't know if this is considered an attack, but root may be tricked into
unmounting a file system pointed to by the symlink since the script also
does:
cleanup()
{
echo Cleaning up... >&2
umount -d /tmp/mount.$$ || true
rm -f $IMAGE.ext2 $IMAGE
}
trap cleanup EXIT
This will of course not do anything if the file system is busy which
limits its useability as a DoS attack. Anyway, it wouldn't harm if the
script used mktemp.
Bjørn
--
You know, Lassie was Moonie
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can a package modify slapd.conf in its maintainer script?
Bastian Blank <[EMAIL PROTECTED]> writes: > On Mon, Aug 11, 2008 at 08:48:29AM +0200, Petter Reinholdtsen wrote: >> I really wish there was some organized way for packages to >> automatically add schemas and settings to the OpenLDAP server >> configuration, at install time. > > ldap is a network based service. Why does the OP even consider that the > ldap server is running on the local machine? You took the words out of my mouth. Is there any reason why phamm-ldap should depend on slapd? It could recommend slapd, like e.g kolabd does. I think maybe the same goes for gforge-ldap-openldap, which also seems to be a ldap client depending on slapd. Bjørn -- You have the depravity of a creep -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: correct definition of localhost?
Steve Langasek <[EMAIL PROTECTED]> writes: > On Tue, Jul 08, 2008 at 01:47:51PM +0200, Martijn van Oosterhout wrote: >> On Tue, Jul 8, 2008 at 2:37 AM, Joey Hess <[EMAIL PROTECTED]> wrote: >> > http://sourceware.org/bugzilla/show_bug.cgi?id=4980 > >> I just find it wierd that there doesn't appear to be a single person >> who can explain the reasoning for the change... > > Ulrich made the change, and he's not exactly known for giving helpful > explanations. Apparently he thinks bug ping-pong is a better use of his > time. Another great example of his wonderful communication skills: http://lkml.org/lkml/2008/5/31/2 Just in case anyone thought there actually *was* an explanation. Bjørn -- You pathetic young weakling -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2 ftpds packages conflicts
Tiago Saboga <[EMAIL PROTECTED]> writes: > I prefer a) over b), but for the sake of completeness, we should point that > there is third choice: > c) allow it to work, automagically determining new ports > > For this to work, the user would have to choose which server is the "main" > one. I don't know how hard it would be, and don't think it's very useful, but > it's the "perfect" solution. well, you don't know that the adminstrator wants to run the servers on different ports. s/he might want to run them on the default port, but binding to specific, different, ip addresses. Bjørn -- If you've seen one source license, you've seen them all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2 ftpds packages conflicts
[EMAIL PROTECTED] writes: > Yet there are also many users, probably those who are not > professional administrators, that _need_ for everything to work out of the > box. > Who should we help more: those who get paid to administer the machines, > and are probably much more knowledable, or the occasional, home or > small office user that doesn't have the knoweldge or the time to acquire it? None of the suggested solutions will prevent the packages from working out of the box. No further configuration is necessary as long as there is only one package providing the httpd service installed. The question is what to do when the adminstrator wants to install a second httpd package. Should the maintainer enforce a policy using conflicts, or should the adminstrator get to choose? Either way, you can't make it work out of the box. Your choices are a) allow it to work, depending on configuration b) deny it from ever working I prefer a). Bjørn -- No nukes! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2 ftpds packages conflicts
Gerrit Pape <[EMAIL PROTECTED]> writes: > On Mon, Nov 06, 2006 at 11:34:14PM +0100, Sz?kelyi Szabolcs wrote: >> can anyone tell why ftpds do conflict with each other and why httpds do >> not? > > Actually the httpds should conflict too as they install listeners on > 0.0.0.0:80. Nope, not IMHO. There are many perfectly valid reasons for running more than one httpd on a single machine. And even if you can't see one, why would you want to make it impossible (aka difficult)? > E.g.: With no httpd installed, install the apache package, apache will > listen on 0.0.0.0:80; now install the thttpd package, it'll work fine, > but no thttpd daemon will run afterwards, because it fails to bind to > 0.0.0.0:80, see syslog; reboot the machine, and you'll be surprised to > see the thttpd daemon run, and not apache, because thttpd gets started > first. So? It's up to the adminstrator to configure the packages after installation. The default of 0.0.0.0:80 may work as expected in some cases, but the package maintainer cannot guarantee this. And that has nothing to do with other installed packages. The maintainer just can't know what the administrator expects. Yes, this does go for the ftpds too. I don't see any reason why you'd want more than one, but I don't really see any reason to impose the restriction either. If the ftpds can be configured to listen to anything else than 0.0.0.0:21, then the administrator should be allowed to install more than one of them. A warning about the need for manual configuration in the case of a port/address conflict is probably a good idea, though. Bjørn -- Don't you realise that Heidegger's ghost is living in your punk haircut? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
