hat it even came with a patch:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065085 (thanks
ktetzlaff).
> > 1) Looking at the packaging I see that `dhcpcd-base`, unlike `dhcpcd`
> > (which was renamed from dhcpcd5), does not ship the daemon part of dhcpcd,
> > which takes over dhc
On Sat, Sep 14, 2024, at 09:30, Daniel Gröber wrote:
> 3) dhcpcd-base enables IPv6 privacy addressess by default.
Please never do this *by silent default* when DHCPv6 is being used for stateful
address assignment, privacy addresses are a big issue on non-home networks and
even on home netwo
I haven't been following the rest of this discussion, but one small
point since this is a common source of confusion:
On Sat, Sep 14, 2024 at 02:30:08PM +0200, Daniel Gröber wrote:
> Lastly I don't quite understand how the ftp-master priority override
> mechanism plays into this and indeed why we'
the mismatch between dhcpd being a system daemon
vs. ifudown wanting a per-interface process?
2) I'm worried about the behavioural change regarding inet/inet6 stanzas
outlined in #1065085 with a patch by ktetzlaff pending.
3) dhcpcd-base enables IPv6 privacy addressess by default.
1)
ma 11. maalisk. 2024 klo 7.02 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> ma 11. maalisk. 2024 klo 1.29 Bernd Zeimetz (be...@bzed.de) kirjoitti:
> > On Mon, 2023-06-19 at 13:54 +0300, Martin-Éric Racine wrote:
> > > I hereby propose bin:dhcpcd-base:
> > >
> > > 1) already supporte
On Mon, 11 Mar 2024 07:02:38 +0200, Martin-Éric Racine
wrote:
>Meanwhile a bare minimal system needs a non-GUI solution and swaping
>which DHCP client gets pulled by ifupdown is the simplest, least
>disruptive way of accomplishing this.
Most bare minimal non-GUI systems run fine with systemd-netw
ma 11. maalisk. 2024 klo 1.29 Bernd Zeimetz (be...@bzed.de) kirjoitti:
> On Mon, 2023-06-19 at 13:54 +0300, Martin-Éric Racine wrote:
> > I hereby propose bin:dhcpcd-base:
> >
> > 1) already supported by ifupdown.
> > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege
> > separation
Hi,
On Mon, 2023-06-19 at 13:54 +0300, Martin-Éric Racine wrote:
> I hereby propose bin:dhcpcd-base:
>
> 1) already supported by ifupdown.
> 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege
> separation.
> 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf
> 4) suppo
pose bin:dhcpcd-base:
> > > > > > > > > >
> > > > > > > > > > 1) already supported by ifupdown.
> > > > > > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with
> > > > > > > > > > privilege separation.
>
; > I hereby propose bin:dhcpcd-base:
> > > > > > > > >
> > > > > > > > > 1) already supported by ifupdown.
> > > > > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with
> > > > >
h priority:important.
> > > > > > > >
> > > > > > > > I hereby propose bin:dhcpcd-base:
> > > > > > > >
> > > > > > > > 1) already supported by ifupdown.
> > > > > > > > 2) dua
Sent: Saturday, November 18, 2023 14:10
To: debian-devel@lists.debian.org
Subject: Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Am 18.11.23 um 15:26 schrieb Martin-Éric Racine:
> What is the current situation?
I don't think we reached a consensus yet.
One particula
Am 18.11.23 um 15:26 schrieb Martin-Éric Racine:
What is the current situation?
I don't think we reached a consensus yet.
One particular aspect I don't like of the current proposal is that users
upgrading from bookworm will end up with both, isc-dhcp-client and
dhcpcd-base being
supported by ifupdown.
> > > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with
> > > > > > > privilege separation.
> > > > > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf
> > > > > > &g
lient for use with debootstrap and moving the
> priority from one package to another seems like an incremental
> improvement that is not blocking the bigger goal of changing the default
> network configuration tool in any way.
>
> I expect that dhcpcd will not be important in trixie, bu
gt; > > > I hereby propose bin:dhcpcd-base:
> > > > > >
> > > > > > 1) already supported by ifupdown.
> > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege
> > > > > > separation.
> > &g
On Tue, Jul 11, 2023 at 03:06:57PM -0600, Sam Hartman wrote:
> However, there are some significant disadvantages to netplan:
> 1) It's an extra layer. You can ignore it when reading the config (at
> least if you aren't too surprised by your config ending up in /run).
> But it is extra complexity,
On Fri, Jul 14, 2023 at 09:33:12AM -0400, Jeremy Bícha wrote:
> On Wed, Jul 12, 2023 at 8:32 AM Lukas Märdian wrote:
> > (We're also working on a bidirectional Netplan-NetworkManager integration,
> > that allows NM to feed back it's configuration into Netplan YAML format. It
> > is
> > a small pa
On Sat, Jul 15, 2023 at 02:04:57PM -0400, nick black wrote:
> Sam Hartman left as an exercise for the reader:
> > I consider anything that requires me to write wpa_supplicant config to
> > be a bad idea (unless I'm running an AP) and NetworkManager driving
> > wpa_supplicant is a better idea.
>
>
Sam Hartman left as an exercise for the reader:
> > "nick" == nick black writes:
> I consider anything that requires me to write wpa_supplicant config to
> be a bad idea (unless I'm running an AP) and NetworkManager driving
> wpa_supplicant is a better idea.
i think everyone's agreed on this
On Wed, Jul 12, 2023 at 8:32 AM Lukas Märdian wrote:
> (We're also working on a bidirectional Netplan-NetworkManager integration,
> that allows NM to feed back it's configuration into Netplan YAML format. It is
> a small patch for NetworkManager and is purely optional.)
Does that already exist in
> "Lukas" == Lukas Märdian writes:
Lukas> That would lead to a situation where users would need to
Lukas> differentiate what system they are on when doing their
Lukas> network configuration: Debian Cloud (Netplan)
No, I think if the user is feeding configuration into a cloud image
> "nick" == nick black writes:
I consider anything that requires me to write wpa_supplicant config to
be a bad idea (unless I'm running an AP) and NetworkManager driving
wpa_supplicant is a better idea.
--Sam
Sam Hartman left as an exercise for the reader:
> In the wifi case though, I agree that netplan is a good idea.
> It doesn't look like systemd-networkd supports setting up the
> authentication for a wireless network. So, you'd need to be using
> wpa_supplicant directly and systemd-networkd. I thi
On Wed, Jul 12, 2023 at 01:33:02PM +0200, Andrey Rakhmatullin wrote:
> On Wed, Jul 12, 2023 at 12:26:52PM +0100, Simon McVittie wrote:
> > > From the discussions above, it seems that NetworkManager is relevant as
> > > well,
> > > though, and is being pulled in whenever a desktop task is installed
Hi Lukas,
* Lukas Märdian [2023-07-12 12:53]:
Thank you for pointing this out. It's been on my TODO list for a while to split
the netplan.io package, and make the Python-CLI parts optional. They are not
strictly required to configure a system at boot time.
I took your mail as an occation to fi
On Wed, Jul 12, 2023 at 12:26:52PM +0100, Simon McVittie wrote:
> > From the discussions above, it seems that NetworkManager is relevant as
> > well,
> > though, and is being pulled in whenever a desktop task is installed (in
> > addition to ifupdown or future systemd-networkd).
>
> What happens
On Tue, 11 Jul 2023 at 17:48:40 +0200, Lukas Märdian wrote:
> From the discussions above, it seems that NetworkManager is relevant as well,
> though, and is being pulled in whenever a desktop task is installed (in
> addition to ifupdown or future systemd-networkd).
What happens at the moment is:
On Tue, Jul 11, 2023 at 03:06:57PM -0600, Sam Hartman wrote:
> > "Lukas" == Lukas Märdian writes:
>
>
> Lukas> Therefore, I'd love to see Netplan to be used in combination
> Lukas> with this! It's a clean, declarative configuration language
> Lukas> not specifically tied to syst
On Jul 11, Sam Hartman wrote:
> 1) It's an extra layer. You can ignore it when reading the config (at
> least if you aren't too surprised by your config ending up in /run).
> But it is extra complexity, especially in a situation like " run dhcp on
> my ethernet" that is relatively simple.
I agre
On 2023-07-12 07:54, Gioele Barabucci wrote:
1) It's an extra layer. [...]
2) It's a layer that you cannot ignore when editing the config. [...]
I'd also add 3) It requires Python and various Python libraries. At
least the CLI tool does.
In some circumstances installing Python and a bunch
On 11/07/23 23:06, Sam Hartman wrote:
However, there are some significant disadvantages to netplan:
1) It's an extra layer. [...]
2) It's a layer that you cannot ignore when editing the config. [...]
I'd also add 3) It requires Python and various Python libraries. At
least the CLI tool does.
> "Lukas" == Lukas Märdian writes:
Lukas> Therefore, I'd love to see Netplan to be used in combination
Lukas> with this! It's a clean, declarative configuration language
Lukas> not specifically tied to systemd-networkd as an
Lukas> implementation. So it could also be used on
On Mon, Jul 10, 2023 at 09:39:52AM -0400, nick black wrote:
> Helmut Grohne left as an exercise for the reader:
> > And yeah, please work on changing that ifupdown by default. I'm faced
> > with having to uninstall it from more and more systems. In case, you
> > do a straw poll, I vote for systemd
Helmut Grohne left as an exercise for the reader:
> And yeah, please work on changing that ifupdown by default. I'm faced
> with having to uninstall it from more and more systems. In case, you
> do a straw poll, I vote for systemd-networkd, which happens to be
> installed by default. Would there b
t
discussion going and implemented before trixie. However, this is about
changing the default dhcp client for use with debootstrap and moving the
priority from one package to another seems like an incremental
improvement that is not blocking the bigger goal of changing the default
network configuration to
On Sat, 8 Jul 2023 at 08:39, Bastian Blank wrote:
>
> On Fri, Jul 07, 2023 at 06:07:58PM -0600, Sam Hartman wrote:
> > > "Bastian" == Bastian Blank writes:
> > Bastian> Why do we need to have the priority adjusted instead of fix
> > Bastian> d-i to install what it knows the user needs
On Fri, Jul 07, 2023 at 06:07:58PM -0600, Sam Hartman wrote:
> > "Bastian" == Bastian Blank writes:
> Bastian> Why do we need to have the priority adjusted instead of fix
> Bastian> d-i to install what it knows the user needs?
> Because it's not just D-I, it's bootstrapping in general.
>> sleeping over it, and discussing with debian fellows, I would
>> like to call for consensus to rise Priority: Important to
>> dhcpcd-base (as initially requested in #1038882), and switch to
>> Recommends: dhcpcd-base | dhcp-client.
Bastian> Why do
to
> rise Priority: Important to dhcpcd-base (as initially requested in
> #1038882), and switch to Recommends: dhcpcd-base | dhcp-client.
Why do we need to have the priority adjusted instead of fix d-i to
install what it knows the user needs?
Bastian
--
Where there's no emotion, there'
, DHCPv6 with PD) with privilege
> > > > > separation.
> > > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf
> > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail
> > > > > 5) a mere inet line in /etc/network/
onf
> > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail
> > > > 5) a mere inet line in /etc/network/interfaces is sufficient to
> > > > configure both stacks.
> > > ...
> > >
> > > I agree that dhcpcd seems the be
network/interfaces.d/, and
/etc/netplan/whatever.yaml.
Will dhcpcd-base provision an IP address for a one interface and not
interfere with any existing interfaces or routes (e.g. bridged
interfaces, static VPN routes, containers, etc.)
-Jim P.
On Thu, Jun 22, 2023 at 08:51:01PM +0200, Philipp Kern wrote:
> TBH time is too short to manually provision IP addresses on servers.
And DHCP is gladly enough entirely optional since SLAAC exists. But
for that you need systemd-networkd/systemd-resolved or a whole bunch of
other software.
Bastian
On 22.06.23 16:03, Marco d'Itri wrote:
On Jun 22, Martin-Éric Racine wrote:
The point has always been to ship some ifupdown-supported DHCP client
by default. This can be done either by keeping the default client's
priority to important or by making ifupdown Depends on one. I prefer
the later.
Marco d'Itri writes:
> On Jun 22, Martin-Éric Racine wrote:
>
>> The point has always been to ship some ifupdown-supported DHCP client
>> by default. This can be done either by keeping the default client's
>> priority to important or by making ifupdown Depends on one. I prefer
>> the later.
> I
On Jun 22, Martin-Éric Racine wrote:
> The point has always been to ship some ifupdown-supported DHCP client
> by default. This can be done either by keeping the default client's
> priority to important or by making ifupdown Depends on one. I prefer
> the later.
It would be totally unacceptable
esolv.conf
> > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail
> > > > 5) a mere inet line in /etc/network/interfaces is sufficient to
> > > > configure both stacks.
> > > ...
> > >
> > > I agree that dhcpcd seems the b
ual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege
> > > separation.
> > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf
> > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail
> > > 5) a mere inet line in /etc/network/interfa
On Thu, Jun 22, 2023 at 01:39:02PM +0800, Paul Wise wrote:
> On Tue, 2023-06-20 at 11:19 +0200, Lukas Maerdian wrote:
>
> > Netplan allows to configure both of those tools and is already being
> > used across Ubuntu and in Debian cloud-images for this purpose. All
> > while keeping full flexibilit
On Tue, 2023-06-20 at 11:19 +0200, Lukas Maerdian wrote:
> Netplan allows to configure both of those tools and is already being
> used across Ubuntu and in Debian cloud-images for this purpose. All
> while keeping full flexibility to use the underlying tool's native
> config files, should Netplan'
On 2023-06-19 Sven Joachim wrote:
[...]
> If my above statements about debootstrap are correct, this will result
> in no dhcp-client being installed at all by debootstrap unless the
> override bug also requests bumping dhcpcd-base's priority from optional
> to important.
On Tue, Jun 20, 2023 at 10:23:58AM +0100, Matthew Vernon wrote:
> We might be using slightly different terms, but for desktops I still
> tend to use ifupdown (since the network config is easily configured
> thus, and essentially never changes); laptops I have ifupdown &
> network-manager (since th
Simon McVittie left as an exercise for the reader:
> I was using "desktop" in the sense of task-gnome-desktop and friends, more
> than as a class of hardware. Laptops and other portable computers are the
> main thing that really needs easily user-configurable networking.
> I think it makes sense fo
On Tue, 20 Jun 2023 at 10:19, Lukas Maerdian wrote:
>
> Am 19.06.23 um 20:01 schrieb Simon McVittie:
> > On Mon, 19 Jun 2023 at 14:13:11 +0200, Ansgar wrote:
> >> On Mon, 2023-06-19 at 13:35 +0200, Michael Biebl wrote:
> >>> Why does isc-dhcp-client have priority:important to begin with?
> >>> I d
On Tue, 20 Jun 2023 at 11:42, Simon McVittie wrote:
>
> On Tue, 20 Jun 2023 at 05:03:19 -0400, nick black wrote:
> > Simon McVittie left as an exercise for the reader:
> > > At the moment I believe the status quo for d-i is that networking is
> > > managed by NetworkManager if a desktop task happe
On Tue, 20 Jun 2023 at 05:03:19 -0400, nick black wrote:
> Simon McVittie left as an exercise for the reader:
> > At the moment I believe the status quo for d-i is that networking is
> > managed by NetworkManager if a desktop task happens to have pulled it in,
> > or ifupdown otherwise? And that se
On Tue, 2023-06-20 at 05:03 -0400, nick black wrote:
> Simon McVittie left as an exercise for the reader:
> > At the moment I believe the status quo for d-i is that networking is
> > managed by NetworkManager if a desktop task happens to have pulled it in,
> > or ifupdown otherwise? And that seems
Ansgar writes:
> I think this should be NetworkManager for desktop environments and I
> personally like systemd-networkd for other environments. In both cases
> these replace both ifupdown and isc-dhcp-client.
We might be using slightly different terms, but for desktops I still
tend to use ifupd
nick black writes:
> what
> does NetworkManager offer that makes it superior to
> systemd-networkd on the desktop
I don't know what systemd-networkd has to offer in this regard, but for
laptop usage I'm personally fond of the ModemManager integration along
with multihoming policies (eth0 preferr
Am 19.06.23 um 20:01 schrieb Simon McVittie:
On Mon, 19 Jun 2023 at 14:13:11 +0200, Ansgar wrote:
On Mon, 2023-06-19 at 13:35 +0200, Michael Biebl wrote:
Why does isc-dhcp-client have priority:important to begin with?
I don't think users care so much about a dhcp client but rather a
network con
Simon McVittie left as an exercise for the reader:
> At the moment I believe the status quo for d-i is that networking is
> managed by NetworkManager if a desktop task happens to have pulled it in,
> or ifupdown otherwise? And that seems reasonable (although I personally
> prefer to set up systemd-
Am 19.06.23 um 21:05 schrieb Luca Boccassi:
On Mon, 19 Jun 2023 at 18:21, Philipp Kern wrote:
On 2023-06-19 14:37, Luca Boccassi wrote:
The advantage of doing that is that it's what Ubuntu does IIRC, so
there will be extra pooling&sharing of resources to maintain those
setups, and the road sh
RA, DHCPv6 with PD) with privilege
>> > separation.
>> > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf
>> > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail
>> > 5) a mere inet line in /etc/network/interfaces is sufficient to
>> > config
IPv6 name servers to /etc/resolv.conf
> > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail
> > 5) a mere inet line in /etc/network/interfaces is sufficient to
> > configure both stacks.
> ...
>
> I agree that dhcpcd seems the best alternative to isc-dhcp-client f
from the CTTE or a similar authority, before we proceed?
>
> Regarding *whether* to make that change: as Luca said, I don't think a
> DHCP client really needs to be at an elevated Priority at all. I think
> it would be better to lower the priority of isc-dhcp-client to optional,
&g
pdown maintainer to switch the Recommends to point to
dhcpcd-base instead of isc-dhcp-client
+1
OpenPGP_signature
Description: OpenPGP digital signature
g *whether* to make that change: as Luca said, I don't think a
DHCP client really needs to be at an elevated Priority at all. I think
it would be better to lower the priority of isc-dhcp-client to optional,
but *not* raise the priority of dhcpcd-base, and instead have ifupdown
pull in the DHCP c
On Mon, 19 Jun 2023 at 18:21, Philipp Kern wrote:
>
> On 2023-06-19 14:37, Luca Boccassi wrote:
> > The advantage of doing that is that it's what Ubuntu does IIRC, so
> > there will be extra pooling&sharing of resources to maintain those
> > setups, and the road should already be paved for it.
>
>
A, DHCPv6 with PD) with privilege
> > > separation.
> > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf
> > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail
> > > 5) a mere inet line in /etc/network/interfaces is sufficient to
> > &g
conf
> > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail
> > 5) a mere inet line in /etc/network/interfaces is sufficient to
> > configure both stacks.
>
> I agree that dhcpcd seems the best alternative to isc-dhcp-client for
> the moment, and I'll make
in /etc/network/interfaces is sufficient to
> configure both stacks.
...
I agree that dhcpcd seems the best alternative to isc-dhcp-client for
the moment, and I'll make the relevant changes in ifupdown as soon as I
can. Josué, any thoughts?
Cheers,
-- S
signature.asc
Description: PGP signature
On Mon, 19 Jun 2023 at 14:13:11 +0200, Ansgar wrote:
> On Mon, 2023-06-19 at 13:35 +0200, Michael Biebl wrote:
> > Why does isc-dhcp-client have priority:important to begin with?
> > I don't think users care so much about a dhcp client but rather a
> > network configuration system
>
> The priorit
On 2023-06-19 14:37, Luca Boccassi wrote:
The advantage of doing that is that it's what Ubuntu does IIRC, so
there will be extra pooling&sharing of resources to maintain those
setups, and the road should already be paved for it.
I am not sure if I have seen this play out in practice[1].
Ubuntu
of isc-dhcp-client to normal is
> > a better route.
> > ifupdown already recommends isc-dhcp-client and if ifupdown want's to
> > use dhcpcd in the future it could change this recommends.
>
> The priority question isn't the important one. The real question is:
>
&g
p-client and if ifupdown want's to
> use dhcpcd in the future it could change this recommends.
The priority question isn't the important one. The real question is:
What network configuration system should users end up with (by
default)?
I think this should be NetworkManager for deskto
Pv6 name servers to /etc/resolv.conf
> > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail
> > 5) a mere inet line in /etc/network/interfaces is sufficient to
> > configure both stacks.
> >
> > While dhcpcd development became somewhat erratic last year due to
>
While dhcpcd development became somewhat erratic last year due to
upstream's health issues, things are seemingly back to normal.
Additionally, a new developer has joined and is willing to take over
the development should upstream's health deteriorate again.
Why does isc-dhcp-client have pri
with PD) with privilege separation.
3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf
4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail
5) a mere inet line in /etc/network/interfaces is sufficient to
configure both stacks.
While dhcpcd development became somewhat erratic last
On Sat, Jun 17, 2023 at 11:44 PM Andreas Beckmann wrote:
>
> On 17/06/2023 20.30, Martin-Éric Racine wrote:
> > This is what I would do if the archive policy demands it. Won't affect
> > transitional dhcpcd5 or dhcpcd-base.
>
> Ack.
>
> I'm not sure whether
On 17/06/2023 20.30, Martin-Éric Racine wrote:
This is what I would do if the archive policy demands it. Won't affect
transitional dhcpcd5 or dhcpcd-base.
Ack.
I'm not sure whether the transitional dhcpcd5 package should have a
versioned dependency on the "right"
hat's why it was not packaged at the time using the same
> source package. So to me it makes sense to avoid adding the epoch to
> avoid automatic upgrades like it was avoided in the past, otherwise
> people might expect a smooth upgrade path. Also for reference the old
> dhcpcd wa
ieve the severity is justified,
> as one could have carried the old dhcpcd package over a number
> of Debian versions since wheezy, and won't get the dhcpcd you
> introduced.
While I guess in general and in theory this would apply, in this
particular case I think the following does
;m fine with either marking the bug as WONTFIX or
> > re-introducing the epoch for one specific binary target whose name
> > matches what was last seen in Wheezy. I simply want to hear what is
> > the mailing list's concensus.
>
> The bug seems to only affect your binary packa
either marking the bug as WONTFIX or
> re-introducing the epoch for one specific binary target whose name
> matches what was last seen in Wheezy. I simply want to hear what is
> the mailing list's concensus.
Hmn, hard to tell, I tend to believe the severity is justified,
as one coul
(non-subscriber, please keep me in CC)
Someone filed a bug asking to re-introduce an epoch.
An older fork of the same package back in Wheezy last featured the epoch.
Personally, I'm fine with either marking the bug as WONTFIX or
re-introducing the epoch for one specific binary target whose name
Package: wnpp
Severity: wishlist
Owner: David Paleino
* Package name: dhcpcd-dbus
Version : 0.4.2
Upstream Author : Roy Marples
* URL : http://roy.marples.name/projects/dhcpcd-dbus
* License : BSD-2
Programming Lang: C
Description : DBus bindings for
On 01-Oct-99, 11:28 (CDT), Dpk <[EMAIL PROTECTED]> wrote:
> What would be the best way to check for this? A simple 'ps |grep
> dhcpcd' ? Would doing so make my package dependent on procps? or is
> there a convenient way to check the installed version of dhcpcd
> s
On Fri, Oct 01, 1999 at 12:28:36PM -0400, Dpk wrote:
> I recently adopted dhcpcd... previous versions of dhcpcd would restart
> during upgrades, which obviously is bad for those doing it remotely.
> Since my recent upload does not restart dhcpcd, I need to start it for
> those up
Previously Edward Betts wrote:
> Check $2
No, check $1.
Wichertk
--
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/
Dpk <[EMAIL PROTECTED]> wrote:
> What would be the best way to check for this? A simple 'ps |grep
> dhcpcd' ? Would doing so make my package dependent on procps? or is
> there a convenient way to check the installed version of dhcpcd
> someway?
Check $2
I recently adopted dhcpcd... previous versions of dhcpcd would restart
during upgrades, which obviously is bad for those doing it remotely.
Since my recent upload does not restart dhcpcd, I need to start it for
those upgrading from previous versions that did stop the daemon.
What would be the
en I installed my laptop, but
after reading the cardmgr docs it was easy: Change one setting to "y" in
the config file for the pcmcia tools and the system will use dhcpcd
whenever an ethernet card is inserted.
So yes, this should probably be part of the boot floppies, as it can't
On Sat, Oct 10, 1998 at 10:32:22AM +0100, John Lines wrote:
> > I believe this is adequate need to get dhcpcd moved into base,
> > and onto the boot floppies.
> Also in a corporate environment many people are running DHCP servers to
> provide network information to Windows 95 sy
s is adequate need to get dhcpcd moved into base,
> and onto the boot floppies.
>
Also in a corporate environment many people are running DHCP servers to
provide network information to Windows 95 systems. It would be great to be
able to let people try Linux without needing to know more abou
dhcpcd moved into base,
and onto the boot floppies.
Ben
--
Brought to you by the letters B and F and the number 12.
"I'm calling from the plane. I'll call you when I get there." -- TMBG
Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/
I'm on FurryM
Joey Hess <[EMAIL PROTECTED]> writes:
> A long time ago, you wrote:
> > Is dhcpcd still up for grabs? If so I'd like to take over the package
> I asked you once before if you still intended to make a new upload, you said
> yes, soon, but I'm still listed as the m
Joey Hess <[EMAIL PROTECTED]> wrote:
: I asked you once before if you still intended to make a new upload, you said
: yes, soon, but I'm still listed as the maintainer. Dhcpcd has some bugs that
: need looking at - are you still planning to maintain it?
There's a new dhcpcd pa
A long time ago, you wrote:
> Is dhcpcd still up for grabs? If so I'd like to take over the package
I asked you once before if you still intended to make a new upload, you said
yes, soon, but I'm still listed as the maintainer. Dhcpcd has some bugs that
need looking at - are you s
> In file included from /usr/include/linux/if.h:23,
> from /usr/include/linux/netdevice.h:30,
> from if.c:28:
> /usr/include/linux/socket.h:9: redefinition of `struct sockaddr'
Seems if.c includes , which in turn goes to
. With gli
1 - 100 of 102 matches
Mail list logo
