Bug#1037244: dhcpcd-ui: new upstream 0.7.9 release
Hi Leandro On 21/06/2023 20:37, Leandro Cunha wrote: [1] https://tracker.debian.org/pkg/dhcpcd5 [2] https://salsa.debian.org/debian/dhcpcd-ui/-/commit/3ca27368227960a2d97ca4fbd1a56314546d96d3 You can probably remove libdbus-1-dev as a buildtime dependency as well. Roy
Bug#881103: openresolv: bump version to 3.9.0 so it works with systemd
Package: openresolv Version: 3.8.0-1 Severity: important Dear Maintainer, Please consider bumping openresolv to 3.9.0 so it works with systemd, which is the Debian default init now. The current version fails to restart services, rendering it pretty useless. Thanks Roy -- System Information: Distributor ID: Sparky Description:SparkyLinux Release:5 Codename: Nibiru Architecture: x86_64 Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#879208: [pkg-wpa-devel] Bug#879208: wpasupplicant: Build wpa_supplicant with interface matching support
On 20/10/2017 15:20, Andrew Shadura wrote: > Control: notfound -1 2:2.4-1.1 > > On 20 October 2017 at 14:33, Roy Marples <r...@marples.name> wrote: >> Dear Maintainer, >> >> Plese build wpa_supplicant with interface matching support: >> CONFIG_MATCH_IFACE=y >> >> This allows the administrator to configure named interfaces to run >> wpa_supplicant on which may not exist at boot time. >> This allows USB network sticks to be easily pluggable when not >> using Network Manager or similar. > > Hi, I don't think this option exists in wpa-supplicant 2.4, but I will > look into this for 2.6. Adding this to 2.6 would be most welcome :)
Bug#879208: wpasupplicant: Build wpa_supplicant with interface matching support
Package: wpasupplicant Version: 2:2.4-1.1 Severity: normal Dear Maintainer, Plese build wpa_supplicant with interface matching support: CONFIG_MATCH_IFACE=y This allows the administrator to configure named interfaces to run wpa_supplicant on which may not exist at boot time. This allows USB network sticks to be easily pluggable when not using Network Manager or similar. Thanks Roy -- System Information: Distributor ID: Sparky Description:SparkyLinux Release:5 Codename: Nibiru Architecture: x86_64 Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages wpasupplicant depends on: ii adduser 3.116 ii libc6 2.24-17 ii libdbus-1-3 1.11.20-1 ii libnl-3-200 3.2.27-2 ii libnl-genl-3-200 3.2.27-2 ii libpcsclite1 1.8.22-1 ii libreadline7 7.0-3 ii libssl1.0.2 1.0.2l-2 ii lsb-base 9.20170808 wpasupplicant recommends no packages. Versions of packages wpasupplicant suggests: pn libengine-pkcs11-openssl pn wpagui -- no debconf information
Bug#820069: dhcpcd5: configures interface without being asked to
dhcpcd does not parse /etc/network/interfaces. I suspect dhcpcd was started by an init script, and the default config is to configure all interfaces. You can restrict this with /etc/dhcpcd.conf. Roy
Bug#821405: dhcpcd no longer starts wpa_supplicant
The next release of wpa_supplicant will be able to hotplug itself: https://w1.fi/cgit/hostap/commit/?id=2e997eece5776eca0a99d53893e343539f9f8eb2 So then you can have the same functionality. Roy
Bug#821387: don't say dhcpcd not running if really still running
On 18/04/2016 12:23, 積丹尼 Dan Jacobson wrote: > Package: dhcpcd5 > Version: 6.10.1-1 > X-debbugs-CC: r...@marples.name > > man page says: > > -k, --release [interface] > This causes an existing dhcpcd process running on the interface > to release its lease and de-configure the interface regardless of > the -p, --persistent option. If no interface is specified then > this applies to all interfaces. If no interfaces are left run- > ning, dhcpcd will exit. > > But in reality, > > # dhcpcd5 -k > dhcpcd not running > # pstree -al|grep dhc > |-dhcpcd5 wlxf428530bfc87 > |-grep dhc > # dhcpcd5 -k wlxf428530bfc87 > sending signal ARLM to pid 1312 > waiting for pid 1312 to exit > # dhcpcd5 -k wlxf428530bfc87 > dhcpcd not running Also see the -x and -M options and the section on Multiple interfaces. A patch for better wording would be welcome :) Because you started dhcpcd on interface wlxf428530bfc87 without -M, all exit operations need to be given the same interface. > By the way, maybe it should also call itself by the name we called it, > dhcpcd5. The idea was that the dhcpcd package (@ version 3 iirc) would be retired at some point. Debian elected to have dhcpcd5 because it was slightly incompatible on the commandline with dhcpcd3. dhcpcd5 in Debian is actually dhcpcd-6.x, so go figure :) Roy
Bug#813803: restarting non-existing services leads to error messages and non-zero exit code
> NetworkManager[26333]: dns-mgr: Writing DNS information to > /sbin/resolvconf > Failed to try-restart named.service: Unit named.service failed to > load: No such file or directory. > Failed to try-restart unbound.service: Unit unbound.service failed > to load: No such file or directory. > NetworkManager[26333]: dns-mgr: resolvconf failed with status > 3072 I don't have systemd. Can someone test this openresolv patch please? http://roy.marples.name/projects/openresolv/vpatch?from=b834d4569fca2c05=fd12d59c00a247fc Roy
Bug#799795: Debian 8.2 does not get Default Gateway if DHCP client uses 121 option
I would say that dhcpcd is correct and the DHCP server is not correctly configured. Option 121 has to include every route (bar the implied subnet route for the address), including the default route. >From RFC3442 If the DHCP server returns both a Classless Static Routes option and a Router option, the DHCP client MUST ignore the Router option. Similarly, if the DHCP server returns both a Classless Static Routes option and a Static Routes option, the DHCP client MUST ignore the Static Routes option. Roy
Bug#792430: openresolv: Fail if a zone is declared on multiple interfaces.
Hi
> When a zone is declared on multiple interfaces (not necessarely same
> content, but the same name), the configuration generated doesn't work,
> two entries are provided and this log indicates the failure at bind restart:
> config: error: /var/lib/bind/resolvconf-zones.conf:23: zone
> 'example.org': already exists previous definition:
> /var/lib/bind/resolvconf-zones.conf:16
>
> I think it's the same problem for other resolvers.
>
> Maybe use the first declaration, in interfaces order and drop others ?
> It's not perfect, but technically, the problem have no solution (if
> zones are the same, it works perfectly, else, some zone are not reachable).
>
> This problem also affects the version /3.5.2-1/.
I cannot replicate this.
Attached is output from a system with two interfaces each of which has
DNS servers from DHCP, IPv6RA and DHCPv6.
As you can see, the final result is generated perfectly.
uberlaptop2$ resolvconf -l
# resolv.conf from wm0.dhcp
# Generated by dhcpcd from wm0.dhcp
domain marples.name
search marples.name
nameserver 10.73.2.1
# resolv.conf from wm0.dhcp6
# Generated by dhcpcd from wm0.dhcp6
search marples.name
nameserver 2a01:348:31:2::1
# resolv.conf from wm0.ra
# Generated by dhcpcd from wm0.ra
search marples.name
nameserver 2a01:348:31:2::1
# resolv.conf from iwn0.dhcp6
# Generated by dhcpcd from iwn0.dhcp6
search marples.name
nameserver 2a01:348:31:2::1
# resolv.conf from iwn0.ra
# Generated by dhcpcd from iwn0.ra
search marples.name
nameserver 2a01:348:31:2::1
uberlaptop2$ resolvconf -v
DOMAIN='marples.name'
SEARCH='marples.name'
NAMESERVERS='10.73.2.1 2a01:348:31:2::1'
LOCALNAMESERVERS='127.0.0.1'
DOMAINS='marples.name:10.73.2.1,2a01:348:31:2::1'
uberlaptop2$ cat /etc/resolvconf.conf
name_servers=127.0.0.1
unbound_conf=/usr/pkg/etc/unbound/resolvconf.conf
named_options=/tmp/named-resolvconf-options.conf
named_zones=/tmp/named-resolvconf-zones.conf
uberlaptop2$ cat /tmp/named*
# Generated by resolvconf
forward first;
forwarders {
10.73.2.1;
2a01:348:31:2::1;
};
# Generated by resolvconf
zone "marples.name" {
type forward;
forward first;
forwarders {
10.73.2.1;
2a01:348:31:2::1;
};
};
uberlaptop2$
Can you post similar output from your system please?
Mail me directly if you don't want it to appear on this public tracker.
Roy
Bug#792428: openresolv: "Failed to get D-Bus connection" randomly at update and boot on bind9 restart
> After an update from any source (dhcp, openvpn, static, ...), restart of > bind fail with message: > Failed to get D-Bus connection: Operation not permitted > > It's not all the time, but very very often. the named (bind) subscriber doesn't use DBus, only the dnsmasq subscriber does. Are you sure it's bind it's trying to restart? Can you post your /etc/resolvconf.conf please? Roy
Bug#792428: openresolv: "Failed to get D-Bus connection" randomly at update and boot on bind9 restart
> After an update from any source (dhcp, openvpn, static, ...), restart of > bind fail with message: > Failed to get D-Bus connection: Operation not permitted > > It's not all the time, but very very often. In openresolv, only the dnsmasq subscriber uses DBus. All the named subscriber (bind) in openresolv will do is write the config files and restart named (bind). Have you modified the named subscriber to use DBus or do you write out to a dnsmasq configuration file as well? Please post your /etc/resolvconf.conf file. Roy
Bug#761050: Please read Re: openresolv sets local bind to always forward requests, even when local bind is authoritative
Sorry aboutt he late response, for some reason this ended up in my spam filter. > On Mon, 22 Jun 2015 12:25:38 +0200 (CEST) >> On Tue, 16 Jun 2015, Herbert Parentes Fortes Neto wrote: >> >>> The upstream said: >>> >>> "Not really an openresolv bug as I see it. >>> For example 192.168.x.x can route to 10.x.x.x even if both sets are not >>> publicly route-able. In-fact some Spanish ISPs do this for their >>> Internet TV." >> >> I regret to say that upstream did not understand my bug report (perhaps I >> did not explain clearly). I never claimed that requests to resolve >> unroutable IPs should never be forwarded; I did claim (and maintain) that IF >> the local bind is set up to be authoritative on a domain (which happens to >> be an unroutable block of IPs for me, but does not have to be), then >> openresolv should not override that by always forwarding queries in any >> case. So the problem is not about forwarding queries involving unroutable >> addresses (even if that happens in my case) but about forwarding queries >> that can have (and therefore should have) an authoritative answer from the >> local bind, without going any further. >> >> If I did not explain clearly, please let me know and I will try to explain >> better. If you confirm wontfix, I will find a way to tweak my local >> configuration of bind + openresolv to work around this for myself, but I do >> believe the current behaviour is wrong in principle and in practice, so it >> should be fixed in a more general way. OK, so you have setup bind to be authortative in some way. Openresolv wants to setup forwarding servers. These two facts maybe in conflict. Now, I am no expert with bind configs, but it would really help if you could post your non working configuration and explain how it should be changed by openresolv to work for you. If you can do that, I'm sure we can make more progress with this issue. Roy
Bug#770043: Denial of Service in dhcpd5: CVE-2014-6060
On 18/11/2014 16:47, Salvatore Bonaccorso wrote: just in case we hear from Roy I've made this known to quite a few Debian developers - I don't want anything more to do with the Debian project. It takes me more time to look after the Debian package than it does for the other distro's I regularly contribute to combined. Maybe I'm doing it wrong but, frankly, I find the whole process tedious and I'd much rather someone else deal with this. So again, I'll say for about the 5th time in the strongest possible way. I NO LONGER WISH TO MAINTAIN ANY PACKAGE IN DEBIAN. I also don't have a Debian machine anymore, it's since been re-purposed for something else. I still develop my software on numerous platforms and am happy to address issues with it in Debian, just not the package itself. If anyone wants to take it up, fine. Just subcribe to dhcpcd-disc...@marples.name where I make release announcements or just use the deb-watch foo which worked the last time I looked at it. Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770043: Denial of Service in dhcpd5: CVE-2014-6060
Hi Salvatore On 18/11/2014 17:23, Salvatore Bonaccorso wrote: On Tue, Nov 18, 2014 at 04:58:39PM +, Roy Marples wrote: On 18/11/2014 16:47, Salvatore Bonaccorso wrote: just in case we hear from Roy I've made this known to quite a few Debian developers - I don't want anything more to do with the Debian project. It takes me more time to look after the Debian package than it does for the other distro's I regularly contribute to combined. Maybe I'm doing it wrong but, frankly, I find the whole process tedious and I'd much rather someone else deal with this. So again, I'll say for about the 5th time in the strongest possible way. I NO LONGER WISH TO MAINTAIN ANY PACKAGE IN DEBIAN. I also don't have a Debian machine anymore, it's since been re-purposed for something else. I still develop my software on numerous platforms and am happy to address issues with it in Debian, just not the package itself. If anyone wants to take it up, fine. Just subcribe to dhcpcd-disc...@marples.name where I make release announcements or just use the deb-watch foo which worked the last time I looked at it. First of all thanks for your that quick feedback, I certainly wasn't aware of that and feel sad that was such a tedious process for you. In any case thanks for the work on the Debian package itself you did so far! Given the above also, can you orphan the packages properly, see https://www.debian.org/doc/manuals/developers-reference/pkgs.html#orphaning such that other might be aware that the packages are up to adoption? And this is the problem I read the paragraph and see that I have to file a bug per package. I then started reading this: https://www.debian.org/Bugs/Reporting As I no longer have a Debian box, I no longer have reportbug. So that leaves me having to write custom email headers, which none of my email clients I use support, or at least it's not obvious to me the end user. This is too complicated and too time consuming for a distribution I no longer have a direct interest in supporting, especially for someone who has never been a Debian developer. Sorry, but even NetBSD's archaic bug handling system is easier to use than this method, by sheer virtue of a web interface to submit bugs. Why is this so hard? With other distributions I just email an active $random developer and ask them to remove me from the package. Normally job done at this point. What possible motivation is there have to many checks in place in an overly complicated system? I really regret ever putting my name on the Debian packages at this point. Please just remove it from them with my thanks. Thanks Roy signature.asc Description: OpenPGP digital signature
Bug#724105: Is package gone from mentors?
Hi On 2014-10-14 10:07, Marcin Kulisz wrote: I'm not capable of uploading it but I'd like to have a look into this package. Unfortunately it looks like it's gone from mentors and there is no provided VCS for this package in the PTS. Can you re-upload it or send a link to VCS? BTW pls cc me in as I'm not subscribing this bug. All of my packages (dhcpcd, dhcpcd-gtk, openresolv) are timing out on mentors. I've tried asking various people to upload it or do something with it but nothing happens. It seems Debian no longer cares about my software, or the mentor process is not working. As a result of this, I've re-purposed my non booting debian partition (non booting thanks to systemd) for something else and no longer have the package updates available. Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758713: dhcpcd5: Segfault after a possible endless recursion
Hi Axel On 2014-08-20 13:48, Axel Beckert wrote: I've just installed dhcpcd5, configured wicd to use it and instructed wicd to renew the connection on eth0 (which used dhclient previously). I had to manually kill running dhclient processes, but dhcpcd got an IP. And then segfaulted after a few seconds: The chances are this is already fixed in dhcpcd-6.4.3 which I've uploaded to mentors, but I just cannot get a Debian dev to upload to Debian proper. Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724105: openresolv: FTBFS: make[1]: *** No rule to make target `config.mk'. Stop.
Hi I've uploaded openresolv-3.5.7-1 to mentors, which fixes this issue: http://mentors.debian.net/debian/pool/main/o/openresolv/openresolv_3.5.7-1.dsc If you could put the package into Debian proper I'd appreciate it. Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724105: openresolv: FTBFS: make[1]: *** No rule to make target `config.mk'. Stop.
Hi
On 23/04/2014 12:41, Hideki Yamane wrote:
I've made a patch for this FTBFS issue, just ignoring config.mk
in Makefile and build fine. Please check and consider to apply it.
From the dh_auto_clean man page:
This is intended to work for about 90% of packages. If it doesn’t
work,
or tries to use the wrong clean target, you’re encouraged to skip
using
dh_auto_clean at all, and just run make clean manually.
So why can we just skip dh_auto_clean?
I'm loath to accept that patch as it's GNU make only.
Attached is a patch applied upstream which allows it to work with GNU
make and BSD make.
RoyIndex: Makefile
==
--- Makefile
+++ Makefile
@@ -1,6 +1,19 @@
-include config.mk
+# Nasty hack so that make clean works without configure being run
+_CONFIG_MK_SH= test -e config.mk echo config.mk || echo config-null.mk
+_CONFIG_MK!= ${_CONFIG_MK_SH}
+CONFIG_MK= ${_CONFIG_MK}$(shell ${_CONFIG_MK_SH})
+include ${CONFIG_MK}
+
+SBINDIR?= /sbin
+SYSCONFDIR?= /etc
+LIBEXECDIR?= /libexec/resolvconf
+VARDIR?= /var/run/resolvconf
+RCDIR?= /etc/rc.d
+RESTARTCMD?= if ${RCDIR}/\1 status /dev/null 2\1; then \
+ ${RCDIR}/\1 restart; \
+ fi
NAME= openresolv
VERSION= 3.5.6
PKG= ${NAME}-${VERSION}
ADDED config-null.mk
Index: config-null.mk
==
--- config-null.mk
+++ config-null.mk
@@ -0,0 +1,1 @@
+# This space left intentionally blank
Bug#719588: Bug#723967: dhcpcd5: diff for NMU version 6.0.5-1.1
Hi On 04/12/2013 13:57, Christoph Egger wrote: Package: dhcpcd5 Version: 6.0.5-1 Severity: normal Tags: patch pending Dear maintainer, I've prepared an NMU for dhcpcd5 (versioned as 6.0.5-1.1) and uploaded it to DELAYED/7. Please feel free to tell me if I should delay it longer. Regards. Please upload it. Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724078: dhcpcd-dbus: FTBFS: make[1]: *** No rule to make target `config.mk'. Stop.
Hi On 18/11/2013 17:39, Michael Ablassmeier wrote: attached patch should fix this issue. Not uploading for now in case you have other plans for the package. In case you are in search for a sponsor get in touch with me :) I'm ideally looking for someone who can maintain the dhcpcd packages in Debian as I find the method of creating a new package for each release quite tedious. If you can do this for me, I'd appreciate it :) If so, just subscribe to dhcpcd-disc...@marples.name or use the debian watch I think I created in the package. As to my plans, well I have two features to implement before I release dhcpcd-6.2 which should be done in a month or so. Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719588: dhcpcd5: FTBFS on GNU/kFreeBSD due to missing include
Hi Petr On 13/08/2013 12:11, Petr Salinger wrote: Package: dhcpcd5 Version: 6.0.5-1 Severity: serious Tags: patch User: debian-...@lists.debian.org Usertags: kfreebsd Hi, the current version fails to build on GNU/kFreeBSD. It needs small tweak, see bellow. Please include this change also as upstream. Thanks in advance Petr --- platform-bsd.c +++ platform-bsd.c @@ -44,6 +44,7 @@ #include syslog.h #include unistd.h +#include common.h #include dhcpcd.h #include if-options.h #include platform.h http://roy.marples.name/projects/dhcpcd/changeset/698ad80c88a5cdbe3376a3f4ac9219c842451a38 I'll release a new dhcpcd soon and get it pushed into Debian. Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637285: openresolv: dns-domain dns-sortlist in the interfaces file is not getting into resolv.conf
Hi Alex On 11/08/2011 06:30, Alex Apke wrote: domain is missing because search supersedes it. Any domain entries are silently merged with the search option. Is there a problem with this? From a resolver search standpoint, there is no problem appending the domain entry to search field. But I believe the domain value in resolv.conf is used to set the machine's domain name (hostname -d), this is now lost in openresolv compared to what resolvconf did. I have a server with a default internal IP address, and a local name defined in /etc/hosts for one network interface, but the second interface is on the public network. So I want the domain name of the server to be set to the public name, not the default internal one. According to hostname(1) the DNS domain name is fetched via getaddrinfo(3) which in turn just used the information in /etc/resolv.conf Also, note this in resolv.conf(5) The domain and search keywords are mutually exclusive. If more than one instance of these keywords is present, the last instance wins. Lastly, looking over the original resolvconf code it just merges it all into search as well so openresolv is mirroring the behaviour. The eth0 and eth1 stanza's you mention are example files sent to resolv.conf - not the final /etc/resolv.conf that ends up. Which local resolver are you using? Some require a little configuration to use openresolv. I have bind9 running locally, and am using the libc resolver, so there shouldn't be too much extra needed. AFAIK bind9 on Debian doesn't have any resolvconf hooks other than sending the loopback address as a nameserver to resolvconf. So to get the stanzas working as described on my homepage, you'll need to configure /etc/resolvconf.conf to write out two files for named and update your named configuration to include these two files. See the below links for details. http://roy.marples.name/projects/openresolv/wiki/OpenResolvConfig http://roy.marples.name/projects/openresolv/wiki/OpenResolvConfigBind You should note that the sample Bind config listed probably isn't suitable for Debian - it just serves as an example of how to include the two files needed. Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637285: openresolv: dns-domain dns-sortlist in the interfaces file is not getting into resolv.conf
On 11/08/2011 09:58, Alex Apke wrote: So that means that having a domain entry listed before search gives the desired behavior, I am looking for. With the original sample I used for opening the ticket, this is the expected layout: # Generated by resolvconf domain example.com search foo bar example.com nameserver 127.0.0.1 nameserver 192.168.0.2 nameserver 8.8.8.8 nameserver 8.8.4.4 options timeout:5 sortlist 130.155.160.0/255.255.240.0 130.155.0.0 The resolver will ignore domain, and use search, which will have the domain appended to it. In the above example, the domain will be foo because it's the first in the list domain foo search bar foo domain foo That sets the domain to foo and blanks the search list because domain was last. The libc source code will use the last domain or search statement it finds and use that for all. So when it comes to the generated resolv.conf file, having a domain keyword is pretty redundant. It looks like the behaviour you really want is the correct domain first in the search list. You can do this by setting interface_order and/or dynamic_order and/or search_domains in /etc/resolvconf.conf Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637285: openresolv: dns-domain dns-sortlist in the interfaces file is not getting into resolv.conf
On 11/08/2011 17:18, Alex Apke wrote: It looks like the behaviour you really want is the correct domain first in the search list. You can do this by setting interface_order and/or dynamic_order and/or search_domains in /etc/resolvconf.conf Sure, as a backup procedure, there is always that, but I still think it would be possible for openresolv to do what I am suggesting above. Sure it's possible. My question is, what technical issue does it solve? Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637285: openresolv: dns-domain dns-sortlist in the interfaces file is not getting into resolv.conf
Hi Alex On Wed, 2011-08-10 at 00:15 -0700, Alex Apke wrote: domain sortlist are missing, and the domain value is being appended to search, plus the eth0 eth1 stanza's aren't broken up like in the following URL: http://roy.marples.name/projects/openresolv/wiki/OpenResolvReasons domain is missing because search supersedes it. Any domain entries are silently merged with the search option. Is there a problem with this? The eth0 and eth1 stanza's you mention are example files sent to resolv.conf - not the final /etc/resolv.conf that ends up. Which local resolver are you using? Some require a little configuration to use openresolv. Here's a patch which addresses the sortlist option which is indeed an issue. http://roy.marples.name/cgi-bin/gitweb.cgi?p=openresolv.git;a=commitdiff;h=98068bb3b35c1af98226adedbaa263ffdc14d775 I'll do another release based on feedback on the domain issue above. Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635479: openresolv: Feature request: DHCPv6 support in DHCP hook script
Hi Geoff On Tue, 2011-07-26 at 00:12 -0700, Geoffrey Sisson wrote: This patch adds basic DHCPv6 support for openresolv. It's unlikely that this is a comlete patch. For example, some applications might resonably expect resolvconf -d eth0 to remove both the IPv4 and IPv6 interface information. However, it does provide basic DHCPv6 functionality. The patch looks good, but my understanding is that ISC dhclient can only operate for IPv4 OR IPv6 and not both at the same time. As such, why make a distinction in protocol when dealing with resolvconf? Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630688: Openresolv doesn't work with dnsmasq
Hi I've uploaded openresolv-3.4.4 to mentors@ which fixes this problem by specifying default config files to write out for dnsmasq, pdns and unbound. Please test it, and if let me know if it works for you. Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634331: no longer works on a bridge interface
On Mon, 2011-07-18 at 19:14 +0200, martin f krafft wrote: dhcpcd5 fails to obtain an address (it fails to put packets on the wire) when the interface is a bridge. Manual configuration works, as does IPv6 autoconf and isc-dhcp-client, so the problem seems to be with dhcpcd. Seems to work fine for me. sudo brctl addbr br0 sudo brctl addif br0 wlan0 eth0 sudo dhcpcd -dB br0 dhcpcd[4182]: version 5.2.12 starting dhcpcd[4182]: br0: using hwaddr 00:19:e0:82:33:92 dhcpcd[4182]: br0: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT dhcpcd[4182]: br0: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason CARRIER dhcpcd[4182]: br0: reading lease `/var/db/dhcpcd-br0.lease' dhcpcd[4182]: br0: checking for 169.254.15.125 dhcpcd[4182]: br0: sending ARP probe (1 of 3), next in 1.89 seconds dhcpcd[4182]: br0: sending ARP probe (2 of 3), next in 1.65 seconds dhcpcd[4182]: br0: sending ARP probe (3 of 3), next in 2.00 seconds dhcpcd[4182]: br0: using IPv4LL address 169.254.15.125 dhcpcd[4182]: br0: adding IP address 169.254.15.125/16 dhcpcd[4182]: br0: adding route to 169.254.0.0/16 dhcpcd[4182]: br0: writing lease `/var/db/dhcpcd-br0.lease' dhcpcd[4182]: br0: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason IPV4LL dhcpcd[4182]: br0: sending ARP announce (1 of 2), next in 2.00 seconds dhcpcd[4182]: br0: sending ARP announce (2 of 2) dhcpcd[4182]: br0: broadcasting for a lease dhcpcd[4182]: br0: sending DISCOVER (xid 0x7f13dfa6), next in 4.96 seconds dhcpcd[4182]: br0: sending DISCOVER (xid 0x7f13dfa6), next in 7.48 seconds dhcpcd[4182]: br0: offered 10.73.0.196 from 10.73.0.1 `uberserver' dhcpcd[4182]: br0: sending REQUEST (xid 0x7f13dfa6), next in 3.85 seconds dhcpcd[4182]: br0: acknowledged 10.73.0.196 from 10.73.0.1 `uberserver' dhcpcd[4182]: br0: checking for 10.73.0.196 dhcpcd[4182]: br0: sending ARP probe (1 of 3), next in 1.39 seconds dhcpcd[4182]: br0: sending ARP probe (2 of 3), next in 1.99 seconds dhcpcd[4182]: br0: sending ARP probe (3 of 3), next in 2.00 seconds dhcpcd[4182]: br0: leased 10.73.0.196 for 86400 seconds dhcpcd[4182]: br0: adding IP address 10.73.0.196/24 dhcpcd[4182]: br0: deleting IP address 169.254.15.125/16 dhcpcd[4182]: br0: using Classless Static Routes (RFC3442) dhcpcd[4182]: br0: adding route to 10.73.0.0/24 dhcpcd[4182]: br0: adding default route via 10.73.0.1 dhcpcd[4182]: br0: deleting route to 169.254.0.0/16 dhcpcd[4182]: br0: writing lease `/var/db/dhcpcd-br0.lease' dhcpcd[4182]: br0: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason REBIND This is under ubuntu 10.04 How are you configuring the bridge interface and dhcpcd? Does it work as the above? Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630688: Openresolv doesn't work with dnsmasq
On Fri, 2011-06-17 at 07:45 +0100, Simon Kelley wrote: On 17/06/11 07:34, Roy Marples wrote: On Fri, 2011-06-17 at 00:02 +0200, Juliusz Chroboczek wrote: The point I'm making is that replacing dhcpd with dhcpcd5 broke a working system by replacing resolvconf with openresolv. I'd like to clarify whose bug that is: Can you tell me which package owns a file in /etc/resolvconf/update.d which updates dnsmasq? It's the dnsmasq package. OK, so what's the correct protocol here? openresolv, by default, just configures libc Now, by default that's what the package does, but for Debian we could tailor the default resolvconf.conf installed to update the same config files for dnsmasq and I assume pdnsd. Thoughts? Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630688: Openresolv doesn't work with dnsmasq
On Fri, 2011-06-17 at 00:02 +0200, Juliusz Chroboczek wrote: The point I'm making is that replacing dhcpd with dhcpcd5 broke a working system by replacing resolvconf with openresolv. I'd like to clarify whose bug that is: ... No, it worked out of the box. Well, that is interesting because as far as I can tell, resolvconf does NOT ship with support for dnsmasq and dnsmasq does NOT ship with support for resolvconf. Can you tell me which package owns a file in /etc/resolvconf/update.d which updates dnsmasq? Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630688: Openresolv doesn't work with dnsmasq
On Thu, 2011-06-16 at 11:54 +0200, Juliusz Chroboczek wrote: Investigation showed that the openresolv doesn't write /var/run/dnsmasq/resolv.conf, instead appending the DHCP-provided name servers to /etc/resolv.conf (*after* 127.0.0.1, which is why everything broke). openresolv does not come pre-configured for non libc resolvers. You are expected to configure /etc/resolvconf.conf (which has a man page) to get it to write out a dnsmasq configuation file which dnsmasq can then include. If the default for dnsmasq + resolvconf on Debian is to write out to that file, then we can patch the resolvconf.conf that ships with openresolv to do just this. Did you previously configure resolvconf to do this? Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601312: openresolv should provide various hooks
On 25/10/2010 08:10, Vadim Solomin wrote: To be a drop-in replacement, openresolv should provide ifupdown, dhclient and pppd hooks, just as resolvconf does. It would be more logical to add resolvconf support to each package, dhclient, pppd, etc which is how it is done in other distros. But we can do this too for the Debian package if that is the desired fix. Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595081: ITP: openresolv -- management framework for resolv.conf
Package: wnpp Severity: wishlist Owner: Roy Marples r...@marples.name * Package name: openresolv Version : 3.3.5 Upstream Author : Roy Marples r...@marples.name * URL : http://roy.marples.name/projects/openresolv * License : BSD-2 Programming Lang: Shell Description : management framework for resolv.conf Allows multiple daemons to manage resolv.conf and configures local resolvers such as dnsmasq and unbound. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595089: ITP: dhcpcd-gtk -- GTK+ frontend for dhcpcd and wpa_supplicant
Package: wnpp Severity: wishlist Owner: Roy Marples r...@marples.name * Package name: dhcpcd-gtk Version : 0.5.1 Upstream Author : Roy Marples r...@marples.name * URL : http://roy.marples.name/projects/dhcpcd-ui * License : BSD-2 Programming Lang: C Description : GTK+ frontend for dhcpcd and wpa_supplicant dhcpcd-gtk sits in the notification area and notifies you of changes to your IPv4 network configuration from dhcpcd and wpa_supplicant. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595081: ITP: openresolv -- management framework for resolv.conf
On Tue, 2010-08-31 at 15:17 -0700, Steve Langasek wrote: We already have one of these called resolvconf, and it has plenty of bugs without adding a *second* framework for managing resolv.conf. Please coordinate with the resolvconf maintainer and, preferably, merge your efforts with the existing package. I tried many few years ago, but my patches were rejected (I forget why, don't have the emails anymore), so I created my own variant from scratch keeping a compatible commandline interface. #477723 - author is trying to pass resolvconf off to a new maintainer for over 2 years The other resolvconf bugs do not affect openresolv, and openresolv also solves many of them. (In fact, I think that should be a blocker and that the ftp team should reject any upload of a separate openresolv package.) I find that a very narrow minded view. Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595081: ITP: openresolv -- management framework for resolv.conf
On Tue, 2010-08-31 at 15:20 -0700, Don Armstrong wrote: On Tue, 31 Aug 2010, Roy Marples wrote: Description : management framework for resolv.conf Allows multiple daemons to manage resolv.conf and configures local resolvers such as dnsmasq and unbound. How does this differ from resolvconf which already has significant buy-in and integration in Debian? * Works with POSIX shell and userland * Does not need awk, grep or sed which means we can work without /usr mounted * Works with other init systems than Debians' out of the box * Available as a 2 clause BSD license * Prefer configs via IF_METRIC for dynamic ordering * Configures zones for local resolvers other than libc The last point is quite important, especially when running VPN systems. Take the following resolv.conf files which have been generated by a DHCP client and sent to resolvconf: # resolv.conf from bge0 search foo.com nameserver 1.2.3.4 # resolv.conf from tap0 domain bar.org nameserver 5.6.7.8 In this instance, queries for foo.com will go to 1.2.3.4 and queries for bar.org will go to 5.6.7.8. This does require the resolvers to be configured to pickup the resolvconf generated configuration for them though. openresolv ships with helpers for dnsmasq, ISC BIND,PowerDNS Recursor and unbound Other than that, the openresolv is command line compatible with resolvconf. However, the setup is not. Instead of many directories and files to manage, openresolv just uses /etc/resolvconf.conf. Aside from the user specific configuration, openresolv integrates 100% with a Debian based system. Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594672: ITP: dhcpcd5 -- a DHCP client
Package: wnpp Severity: wishlist Owner: Roy Marples r...@marples.name * Package name: dhcpcd5 Version : 5.2.7 Upstream Author : Roy Marples r...@marples.name * URL : http://roy.marples.name/projects/dhcpcd * License : BSD-2 Programming Lang: C, Shell Description : dhcpcd5 - a DHCP client dhcpcd is a one stop IPv4 network management daemon which includes * RFC2131 compliant DHCP client * IPv4LL (aka ZeroConf) support * ARP address conflict resolution * Link carrier detection * Wireless SSID profiles * ARP ping profiles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594672: ITP: dhcpcd5 -- a DHCP client
On Sat, 2010-08-28 at 11:19 +0200, Patrick Matthäi wrote: Am 28.08.2010 10:35, schrieb Roy Marples: Package: wnpp Severity: wishlist Owner: Roy Marplesr...@marples.name * Package name: dhcpcd5 Version : 5.2.7 Upstream Author : Roy Marplesr...@marples.name * URL : http://roy.marples.name/projects/dhcpcd * License : BSD-2 Programming Lang: C, Shell Description : dhcpcd5 - a DHCP client dhcpcd is a one stop IPv4 network management daemon which includes It only supports IPv6? Only IPv4 at present. IPv6 support, at least for RA is planned for the next major version, possibly with support for the experimental RFC5006 (DNS in IPv6 RA). Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594672: ITP: dhcpcd5 -- a DHCP client
On Sat, 2010-08-28 at 13:13 +0200, Mehdi Dogguy wrote: On 08/28/2010 12:44 PM, Julien Cristau wrote: On Sat, Aug 28, 2010 at 09:35:29 +0100, Roy Marples wrote: * Package name: dhcpcd5 Version : 5.2.7 Upstream Author : Roy Marples r...@marples.name * URL : http://roy.marples.name/projects/dhcpcd * License : BSD-2 Programming Lang: C, Shell Description : dhcpcd5 - a DHCP client What's the difference with the existing dhcpcd package? It's the same project (according to [1]). It's essentially an upgrade, however it's not 100% compatible with the commandline from dhcpcd3 and it uses a method similar to dhclient for configuring the system - aside from IP and routing which is managed internally. However, it's a new package. See bug #551034. Also, dhcpcd5 is designed to be run as a system daemon instead of per interface. This is so it can react to kernel level events and manage routing on a multi interface system a lot better (esp important for BSD system as they lack route metrics). Essentially it's like NetworkManager in this respect but a lot lot smaller. However unlike NetworkManager dhcpcd does not handle link setup and relies on something else to configure wpa_supplicant, ppp, etc. You can also configure an interface based on ARPping a host, wireless SSID. By this, I mean choose to run DHCP or a static IP, or override key DHCP values. Lastly, it works fine on BSD based systems which finally gives them an alternative. Infact, dhcpcd has been merged into the NetBSD base system since 5.0. I only mention this as Debian has kFreeBSD. I'm sure I missed some features out that maybe important to someone :) There are also related side projects which will find their way into Debian also - dhcpcd-dbus and dhcpcd-ui (GTK+ systray moniter/interface) and openresolv (resolvconf alternative, doesn't appear to suffer from the Debian resolvconf reported bugs). dhcpcd-dbus also talks to wpa_supplicant so that dhcpcd-ui can attempt to configure it. Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594672: ITP: dhcpcd5 -- a DHCP client
On Sat, 2010-08-28 at 12:33 +0200, Patrick Matthäi wrote: Am 28.08.2010 12:11, schrieb Roy Marples: dhcpcd is a one stop IPv4 network management daemon which includes It only supports IPv6? Only IPv4 at present. IPv6 support, at least for RA is planned for the next major version, possibly with support for the experimental RFC5006 (DNS in IPv6 RA). Whops, s/IPv6/IPv4/ in my message, please. :) IMHO it shouldn't uploaded to Debian, without missing IPv6 support. What makes you think IPv6 support is required? It does not touch any existing IPv6 and neither does dhcpcd3. As such it co-exists just fine with kernel based RA solicitation. Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551034: Newer upstream available
On Mon, 2010-08-16 at 20:29 +0200, Johannes Schauer wrote: you can lower the build dependencies to from debhelper (= 7.0.50~) to debhelper (= 7.0.15). this way it will also compile on debian lenny. Dropping the dependency now gives this lintian error. dhcpcd5 source: debhelper-overrides-need-versioned-build-depends (= 7.0.50~) I believe that's because of the override_dh_* section in debian/rules I use. If there's another way of doing that without being large or ugly that works with older debhelper then I'm all ears :) Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551034: Newer upstream available
On Thu, 2010-06-17 at 19:32 +0100, Roy Marples wrote: Aside from that, I think I've addressed all issues so the only thing left is to make dhcpcd-3 alternatives friendly which I assume you will do? Any progress here? Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551034: Newer upstream available
On 15/06/2010 21:13, Simon Kelley wrote: I have the dhcpcd5 package installed and running. It seems to be behaving itself and looks like a good start. Some observations of things that should be looked at. . The source package should be dhcpcd5, not dhcpcd, since the existing source package is dhcpcd OK. . The initscript sources /etc/default/dhcpcd, but it doesn't define or use any variables. At very least there should be an ENABLED flag, and a distributed default file which leaves that disabled. Should it be possible to restrict the set of interfaces here too? I'm not clear if that can be done in /etc/dhcpcd.conf There is no requirement for an ENABLED flag in initscripts. http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit I'll probably just stop it from sourcing /etc/default/dhcpcd as dhcpcd.conf can handle everything. You can restrict interfaces like so in dhcpcd.conf allowinterfaces eth0 wlan0 denyinterfaces br0 . Coexistence with dhcpcd3 The following files are in both dhcpcd and dhcpcd5 /etc/default/dhcpcd /usr/share/man/man8/dhcpcd.8.gz /sbin/dhcpcd dhcpcd5 conflicts with dhcpcd, so the man page and binary are OK, but the default file isn't, since it's a config file that could be left even after dhcpcd has been removed. It should probably be /etc/default/dhcpcd5 It's worth thinking about designing dhcpcd5 so that it doesn't conflict with dhcpcd. Since taking a working system with dhcpcd and installing dhcpcd5 isn't going to keep it working by having dhpcd5 take over, making installation of dhcpcd5 cause removal of dhcpcd looks unfriendly. The other DHCP clients in Debian can be installed simultaneously, I think. The simplest way to do that would be to make the binary /sbin/dhcpcd5 and the man page similarly. NOte that if /sbin/dhcpcd exists, it's going to be called by ifup. If it doesn't accept the flags that ifup provides and work compatibly under those circumstances, then it needs to be called something else. The preinst removal of files left by dhcpcd is wrong, a package should not touch files belonging to a different package. The above comes from the view that dhcpcd-5 can co-exist with dhcpcd-3. Whilst they can physically exist on the same system both being present can cause a few issues: * Confusion as to which dhcpcd version and documentation is being used * dhcpcd running as a single daemon will conflict with dhcpcd per interface as setup in /etc/networking/interfaces due to start order. The only valid reason for co-existence so far is that some flags have been removed from the commandline that could be used by other people/programs. dhcpcd-4 shipped with some compat code to handle the transition from dhcpcd-123 to dhcpcd-4, to give both developers and users time to migrate. Debian doesn't have this luxury as it skipped dhcpcd-4 entirely! However, a patch can be maintained to add these compat flags back again. I could not find the source to ifup my Ubuntu to find out what flags it passes to dhcpcd - can you tell me please? So unless anyone as any other other reasons why co-existance is benefical I'll work on a new dhcpcd package today. Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551034: Newer upstream available
On 17/06/2010 10:17, Roy Marples wrote: The only valid reason for co-existence so far is that some flags have been removed from the commandline that could be used by other people/programs. dhcpcd-4 shipped with some compat code to handle the transition from dhcpcd-123 to dhcpcd-4, to give both developers and users time to migrate. Debian doesn't have this luxury as it skipped dhcpcd-4 entirely! However, a patch can be maintained to add these compat flags back again. I could not find the source to ifup my Ubuntu to find out what flags it passes to dhcpcd - can you tell me please? After careful perusal of the interfaces man page (still can't find the source for ifup to ensure I'm correct), the only options passed to dhcpcd are -h $hostname -i $vendor -I $client -l $leasetime These options still exist and are valid. With the removal (or just non usage) of /etc/defaults/dhcpcd any existing user options are just ignored and the user is expected to put any configuration into /etc/dhcpcd.conf. I've also solved the init script vs network/interfaces issue by grepping for iface * inet dhcp and aborting if such a match is found. As such, I cannot justify a reason for having to maintain co-existance with older dhcpcd versions. The only question remainig that I can see is do we want to attempt to parse /etc/defaults/dhcpcd into /etc/dhcpcd.conf on upgrade? That would requre bash to be installed and I'm not sure that it's worth the time spent. Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551034: Newer upstream available
On 17/06/2010 14:03, Simon Kelley wrote: I still bear the scars from an email I once got from someone who had driven 200 miles to reboot a box which had dropped off the net as a result of an automatic update to dhcpcd. I'm not really seeing how that is relevant to the topic at hand as that scenario could equally apply to any package. If anyone has the blame, it's the user for allowing a critical piece of software to be remotely upgraded and not validated locally first. After careful perusal of the interfaces man page (still can't find the source for ifup to ensure I'm correct), the only options passed to dhcpcd are -h $hostname -i $vendor -I $client -l $leasetime These options still exist and are valid. Good, but what aboutinterfacename which is also passed? That also works. I've also solved the init script vs network/interfaces issue by grepping for iface * inet dhcp and aborting if such a match is found. Aborting installation, or start-up. The best approach is to have a dhcpcd5 package which can be installed and configured at leisure (see above for more details) It aborts at startup. So, on a virgin system with dhcpd5 installed, dhcpcd will automatically start and Do The Right Thing. On a system already configured for DHCP via /etc/network/interfaces, dhcpcd will not start (via /etc/init.d/dhcpcd start). I can understand that the biggest problem with making the set of files in dhcpcd3 and dhcpcd5 disjoint is the man page: much better to be able to type man dhcpcd rather then man dhcpcd5. This is achievable by using Debian's alternatives system. It would need a new version of dhcpcd3, but that's quite possible. I've uploaded a new package to mentors.debian.net that uses the alternatives system. However, I now get these errors from lintian E: dhcpcd5: init.d-script-missing-dependency-on-remote_fs /etc/init.d/dhcpcd: required-start E: dhcpcd5: init.d-script-missing-dependency-on-remote_fs /etc/init.d/dhcpcd: required-stop I've tried adding a dhcpcd-5.lintian-overrides file, but it doesn't seem to work. Any help would be nice here :) The issue is this - the ntp helper script will restart ntp via invoke-rc.d and as such /usr is required in $PATH. Now, invoke-rc.d is *optional* and it's lack of presence won't affect a Debian system with /usr nfs mounted from working correctly. Any pointers on fixing this lintian issue are welcome :) Aside from that, I think I've addressed all issues so the only thing left is to make dhcpcd-3 alternatives friendly which I assume you will do? Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551034: Newer upstream available
Resent as it didn't make it to the bug report On 10/06/2010 20:59, Simon Kelley wrote: I'm very much in favour of moving to a dhcpcd5 package. Given my terrible record in getting stuff done on this I'm not going to promise to do it, but I will sponsor uploads if needed, and I'll certainly test things. Roy, please shout when you have stuff available for testing somewhere on the net. I've uploaded packages for dhcpcd5, dhcpcd-dbus, dhcpcd-gtk and openresolv to mentors.debian.net for testing. Let me know how they work out. Thanks Roy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551034: Newer upstream available
Hi I'm upstream for dhcpcd and have recently installed Ubuntu on one of my machines and as such have a vested interest and now the means of using my software on a Debian based system. I have packages prepared for dhcpcd, dhcpcd-dbus and dhcpcd-gtk already and will work on one for openresolv (resolvconf implementation) later today. This provides a light weight alternative to NetworkManager or WICD. The only big issue that I see with people upgrading are moving configuration from /etc/default/dhcpcd to native dhcpcd in /etc/dhcpcd.conf and existing /etc/network/interfaces inet dhcp lines conflicting with dhcpcd running in master mode via its own init.d script. The script cannot run before networking as it needs the loopback interface and possibly wpa_supplicant started which would solve the problem. One solution would be to sed /etc/network/interfaces and comment these lines out. Can I prevent the init.d/dhcpcd script from being started/stopped on package upgrade/downgrade/removal/install? Where can I post these packages for review? Thanks Roy signature.asc Description: This is a digitally signed message part
Bug#551034: Newer upstream available
On Thu, 2010-06-10 at 20:59 +0100, Simon Kelley wrote: I'm very much in favour of moving to a dhcpcd5 package. Given my terrible record in getting stuff done on this I'm not going to promise to do it, but I will sponsor uploads if needed, and I'll certainly test things. Roy, please shout when you have stuff available for testing somewhere on the net. Great! I've uploaded dhcpcd5, dhcpcd-dbus, dhcpcd-gtk and openresolv to ment...@d.o Thanks Roy signature.asc Description: This is a digitally signed message part
Bug#415119: closed by Gerrit Pape [EMAIL PROTECTED] (Bug#415119: fixed in dash 0.5.3-8)
On Tue, 05 Jun 2007 08:54:04 + [EMAIL PROTECTED] (Debian Bug Tracking System) wrote: This is an automatic notification regarding your Bug report #415119: dash compiles incorrectly when LC_ALL isn't C, which was filed against the dash package. It has been closed by Gerrit Pape [EMAIL PROTECTED]. The fix is invalid. The sort man page clearly states that LC_ALL=C should be used, as LC_COLLATE=C doesn't work on my system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415119: dash compiles incorrectly when LC_ALL isn't C
On Fri, 23 Mar 2007 10:47:44 + Gerrit Pape [EMAIL PROTECTED] wrote: tags 415119 + patch forwarded 415119 upstream quit On Fri, Mar 16, 2007 at 08:02:16AM +, Roy Marples wrote: When LC_ALL is set to something like en_GB.UTF-8 then dash makes the builtincmd structure in the wrong lexical order, breaking bsearch, specifically the truecmd : Thanks for the patch, Roy, I forwarded it upstream Regards, Gerrit. I thought Debian was upstream - based on the name of the package. Heh. Do you have a URL for upstream so I can update our ebuild? Thanks Roy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415119: dash compiles incorrectly when LC_ALL isn't C
Package: dash
Version 0.5.3-7
When LC_ALL is set to something like en_GB.UTF-8 then dash makes the
builtincmd structure in the wrong lexical order, breaking bsearch,
specifically the truecmd :
$ :
dash: :: not found
The attached patch addresses the issue.
Thanks
Roy Marples--- dash-0.5.3.orig/src/mkbuiltins 2005-11-26 03:17:55.0 +
+++ dash-0.5.3/src/mkbuiltins 2007-03-15 21:23:51.448422603 +
@@ -65,7 +65,7 @@
if ($i ~ /^-/)
line = $(++i) \t line
print line
- }}' $temp | sort -k 1,1 | tee $temp2 | awk '{
+ }}' $temp | LC_ALL=C sort -k 1,1 | tee $temp2 | awk '{
opt =
if (NF 2) {
opt = substr($2, 2)
