I've been using the 5.x series for a month or so on my stable machine without much issue. Reproducible: Always
Last I heard, the 5.x series could only be used (reliably) with baselayout-2/openrc
(In reply to comment #1) > Last I heard, the 5.x series could only be used (reliably) with > baselayout-2/openrc > Oh, bummer. My system was also bumped to baselayout2 a while ago, so I guess that explains it. Feel free to close then, since that might not happen for awhile.
5.2.2 is a very good stable candidate as it fixes one Linux specific issue with the 5.2 series and a long standing issue with wireless on Linux for the whole 5.x series.
(In reply to comment #1) > Last I heard, the 5.x series could only be used (reliably) with > baselayout-2/openrc This is not true - the dhcpcd module for baselayout-1 can easily be backported from openrc.
FWIW, I've been using dhcpcd 5.0.4 for over 6 months now, and it's been much more reliable than 4.0.x
All, I haven't pushed for stabilization of this series because of bug #284631. It is definitely a show-stopper for at least one user, but I don't know about anyone else. Does anyone have any suggestions? William
(In reply to comment #6) > It is definitely a show-stopper for at least one user It's not a dhcpcd bug. dhcpcd-4 enables clientid by default, dhcpcd-5 not so. His DHCP server rejects messages without a clientid (which is a bug with the DHCP server). His provided traces prove this even though he claims he has enabled clientid.
So, what's actually holding up stabilization of the 5.x series? The only open bug has been reported by only one user and seems impenetrable to investigation. Can we not consider the possibility that it is an isolated case? And what of backporting from openrc, is that yet to be implemented? It runs fine on baselayout-1 for a trivial network configuration on my laptop anyway. I think it would be unfortunate if stabilization of the 5.x series was delayed when there is nothing serious wrong with it.
William, could we add the arch testing teams to this bug so that it can get some more real-world testing? If, as Roy has said, bug #284631 is not in fact a real bug, then it will never be resolved and dhcpcd will never be stabilized.
(In reply to comment #9) > William, could we add the arch testing teams to this bug so that it can get > some more real-world testing? If, as Roy has said, bug #284631 is not in fact > a real bug, then it will never be resolved and dhcpcd will never be stabilized. I understand that some critical updates have happened since 5.2.2, so I would want to stabilize 5.2.6. Roy, am I correct here? If so, we can't do that until 7 Aug. Also, how much would it break baselayout 1? I'm not sure that base-system is going to want to back port anything since we are working toward openrc/baselayout stabilization.
(In reply to comment #4) > (In reply to comment #1) > > Last I heard, the 5.x series could only be used (reliably) with > > baselayout-2/openrc > > This is not true - the dhcpcd module for baselayout-1 can easily be backported > from openrc. So, how do we find a volunteer to do this? I'm not sure what it involves. Also, this bug should probably depend on 328227 and 331087.
(In reply to comment #11) > (In reply to comment #4) > > (In reply to comment #1) > > > Last I heard, the 5.x series could only be used (reliably) with > > > baselayout-2/openrc > > > > This is not true - the dhcpcd module for baselayout-1 can easily be backported > > from openrc. > So, how do we find a volunteer to do this? I'm not sure what it involves. I'm not sure that we do since the base-system team is more interested in stabilizing baselayout-2 and openrc. > Also, this bug should probably depend on 328227 and 331087. The bugs you suggested as dependencies are correct, and I have added them. Also, I added 262097, which is a bug requesting that the dhcpcd module be backported for another issue, and 295613, which is the openrc tracker. Depending on base-system's response to the first bug, I will either remove it or the openrc tracker from the dependencies.
How much work is there in backporting it? I can understand that the baselayout team probably aren't interested, but the rest of us using stable are. Surely there is someone who has done this sort of thing before for whom it wouldn't be much trouble?
I just hit a bug whit dhcpcd-4 and kernel 2.6.35. https://bugzilla.kernel.org/show_bug.cgi?id=16187 Seems this will affect many other users if they are switching to 2.6.35 as it seems to be unrelated to the network-driver used.
And 5.2.7 is needed, 5.2.6 still has the bug.
(In reply to comment #15) > And 5.2.7 is needed, 5.2.6 still has the bug. 5.2.6 was removed from the tree. The very earliest we can stabilize will be when a new release of baselayout-1 with a fix for bug #262097 goes stable or when baselayout-2 or openrc goes stable (bug #295613).
Looks like kernel security trumps everything, so I guess this bug can be closed now.
Actually I rushed in a bit quickly with that comment, 5.2.7 has so far only been made stable for x86 and hppa.
(In reply to comment #18) > Actually I rushed in a bit quickly with that comment, 5.2.7 has so far only > been made stable for x86 and hppa. > The rest will come once they get the kernel marked. Should I close it as dupe (or fixed) ?
@William: I think this is what we want now, even though 5.2.8 is out? We really need this for the blocked bug, I think. @everyoneelse: Please refrain from fiddling with this bug and let the package maintainers make official changes. Keep comments to a minimum too.
Jeroen, I'm not sure what you mean by "this", but I believe you are referring to the summary requesting > 5.2.7 stabilization. I would say that's what we need. Also, I think we need to wait for > gentoo-sources-2.6.35. Am I understanding you correctly?
(In reply to comment #21) > Jeroen, > > I'm not sure what you mean by "this", but I believe you are referring to the > summary requesting > 5.2.7 stabilization. > > I would say that's what we need. Also, I think we need to wait > for > gentoo-sources-2.6.35. > > Am I understanding you correctly? And a new version of bl1 to go stable (comment #16). I'm not sure which version, though. So, we are at the point where gentoo-sources-2.6.35, dhcpcd-5.2.7 and some version of baselayout-1 need to be stablized together.
(In reply to comment #16) > The very earliest we can stabilize will be when a new release of baselayout-1 > with a fix for bug #262097 goes stable or when baselayout-2 or openrc goes > stable (bug #295613). > So, bug 295613 or bug 343925. I just made this one depend on 343925 now. I *guess* people can move on with >dhcpcd-5.2.7 after doing bug 343925. William: You explicitly ACK to get this bug moving again...
Arch teams, this must be stabilized simultaneously with >=sys-kernel/gentoo-sources-2.6.35 and bug 343925. It is a few days early for 5.2.8, but I do not see that as an issue since there are no bugs.
since, on amd64, baselayout-1.12.14-r1 was stabilized, I proceeded to test dhcpcd and that seems have not problems. Amd64 ok.
(In reply to comment #25) > since, on amd64, baselayout-1.12.14-r1 was stabilized, I proceeded to test > dhcpcd and that seems have not problems. Amd64 ok. > tested with gentoo-sources-.35-r12 and git-sources-.37-rc1
works on arm, but need to check bug 334341 first
5.2.8 is fine on x86. Maybe the dependency on #343925 (OpenRC) can be removed since baselayout is fixed? It was mentioned in comment #24 that this needs to be stabilized simultaneously with 2.6.35, but why can't we stabilize earlier?
(In reply to comment #28) > Maybe the dependency on #343925 (OpenRC) can be removed since baselayout is > fixed? I think you mean the dependency on bug #295613. I don't really want to remove it until the new baselayout-1 is stabilized everywhere and that bug is closed. > It was mentioned in comment #24 that this needs to be stabilized simultaneously > with 2.6.35, but why can't we stabilize earlier? We can't stabilize earlier because of bug #331087.
x86 takes the lead...the brave architecture in your neighbourhood.
Stable for HPPA.
On x86 I get this error with the new dhcpcd whenever service dependencies are cached: * Caching service dependencies ... * Cannot add provide 'net', as a service with the same name exists! [ ok ] Commenting out the "provide net" line in the /etc/init.d/dhcpcd file removed the error, but I'm not sure if this is a good idea. Everything seems to work ok though, despite this error.
Tested on SPARC, still sets its hostname FQDN correctly, so I guess it's good to go.
(In reply to comment #32) Same here (x86): * Cannot add provide 'net', as a service with the same name exists! [ ok ]
Stable on alpha.
arm stable
amd64 done. Thanks Agostino
This new version prevents my laptop from connecting to my network and takes a very long time to start up. I compiled dhcpcd-4.0.15 and both issues were resolved.
(In reply to comment #38) > This new version prevents my laptop from connecting to my network and takes a > very long time to start up. I compiled dhcpcd-4.0.15 and both issues were > resolved. I'm guessing you are running a linux kernel earlier than 2.6.35. If that is the case, upgrade your kernel to 2.6.35 or newer then try this again.
(In reply to comment #39) > (In reply to comment #38) > > This new version prevents my laptop from connecting to my network and takes a > > very long time to start up. I compiled dhcpcd-4.0.15 and both issues were > > resolved. > > I'm guessing you are running a linux kernel earlier than 2.6.35. If that is the > case, upgrade your kernel to 2.6.35 or newer then try this again. > No, I am running zen-sources-2.6.36-zen1
(In reply to comment #40) > No, I am running zen-sources-2.6.36-zen1 In that case, please open a separate bug for your issue. This bug is a stabilization request only. Thanks, William
(In reply to comment #32) > On x86 I get this error with the new dhcpcd whenever service dependencies are > cached: > * Caching service dependencies ... > * Cannot add provide 'net', as a service with the same name exists! > [ ok > ] > Commenting out the "provide net" line in the /etc/init.d/dhcpcd file removed > the error, but I'm not sure if this is a good idea. > Everything seems to work ok though, despite this error. I've never seen this error with openrc, so it is an issue with baselayout-1 and how it handles dependencies. You should be fine running dhcpcd from the net.* scripts, which is how it is supposed to be run with baselayout-1.
(In reply to comment #38) > This new version prevents my laptop from connecting to my network and takes a > very long time to start up. I compiled dhcpcd-4.0.15 and both issues were > resolved. > I think I have the same issue as you. Added a bug here: https://bugs.gentoo.org/show_bug.cgi?id=349486
ia64/s390/sh/sparc stable
ppc64 stable
(In reply to comment #42) > I've never seen this error with openrc, so it is an issue with baselayout-1 and how it handles dependencies. > > You should be fine running dhcpcd from the net.* scripts, which is how it is > supposed to be run with baselayout-1. So perhaps "provide net" should be removed from /etc/init.d/dhcpcd on baselayout-1? Or removed altogether - does it serve any purpose on baselayout-2? This message is really annoying - it appears on each depscan update.
(In reply to comment #46) > (In reply to comment #42) > > I've never seen this error with openrc, so it is an issue with baselayout-1 and how it handles dependencies. > > > > You should be fine running dhcpcd from the net.* scripts, which is how it is > > supposed to be run with baselayout-1. > So perhaps "provide net" should be removed from /etc/init.d/dhcpcd on > baselayout-1? Or removed altogether - does it serve any purpose on > baselayout-2? > This message is really annoying - it appears on each depscan update. The bug for this is bug #346805. This is an issue in baselayout-1. For some reason, it doesn't like having more than one init script present that provides net. I can't remove the 'provide net' line from dhcpcd's init script, because it can be run standalone (without the net scripts at all) to control all of the network interfaces on a system.
ppc team, what is your status wrt stabilizing this? Thanks, William
ppc stabled this, but forgot to remove itself from CC, removing+closing 28 Feb 2011; Brent Baude <ranger@gentoo.org> dhcpcd-5.2.10-r2.ebuild: stable ppc, bug 355279 I remove bug 295613 from the dep list, to enable reso/fix. This dep was ignored by all.
