This version needs to be stabilized asap because the old version does not build with current stable glibc on some architectures. I will stabilize on amd64 and x86 then add the other architectures to the bug.
Arch teams, please test and stabilize as soon as possible. Thanks, William
Stable for HPPA.
sparc stable
arm stable
ppc stable
Bringing down wlan (iwlwifi) iface: clear inet4 address after few seconds of work. Went back to 5.6.4
(In reply to Dmitry from comment #6) > Bringing down wlan (iwlwifi) iface: > clear inet4 address after few seconds of work. > Went back to 5.6.4 This issue does not belongon this bug. If you think there is an issue that should block stabilization, feel free to open another bug and supply us with all of the information we need to determine that. Arch teams, please continue.
Dmitry, did you file the bug? I'm confirming what you're seeing, 6.2.0 simply drops IPv4 address for unknown reasons.
(In reply to Leho Kraav (:macmaN @lkraav) from comment #8) > Dmitry, did you file the bug? I'm confirming what you're seeing, 6.2.0 > simply drops IPv4 address for unknown reasons. I have seen this myself, but it's very infrequent and always seems to be triggered by an external source. Each time I've seen it, dhcpcd has also been un-responsive to `dhcpcd -x` but isn't consuming CPU either. That means it's blocking on something, which is odd as dhcpcd uses non blocking sockets - except attaching control sockets which is fixed here: http://roy.marples.name/projects/dhcpcd/fdiff?v1=31e1e5558285fbce&v2=284b3c234d2b32e3&sbs=1 The only consumer I know of this to cause the block is dhcpcd-dbus which is used by dhcpcd-gtk. So what *probably* happens is that carrier drops, dhcpcd spins down IPv4 and notifies listeners of this and blocks here. I don't know if this fixes the reported problem, but it seems to for me.
Stable on alpha.
ia64 stable
ppc64 stable, all done.
