Current in portage: 2.4.1
Well 2.5 was development branch... however last month 2.6 got released that is stable branch. So 2.6.0 update please :)...
Consider contextual stabilization due dhcp package doesn't work anymore on updated systems and product is considered dismissed since december 2022
@CyberGuerro What do you mean by 1. "Consider contextual stabilization due dhcp package doesn't work anymore on updated systems"? 2. "Product is considered dismissed since december 2022"?
(In reply to Edward Kigwana from comment #3) > @CyberGuerro > > What do you mean by > 1. "Consider contextual stabilization due dhcp package doesn't work anymore > on updated systems"? > 2. "Product is considered dismissed since december 2022"? 1: after update of my PRODUCTION server, dhcp daemon freezes the system and I had to restart it with recovery disk because I must remove daemon from default run-level to permit my system boot. 2: on product owner site https://www.isc.org/dhcp/, owner says "ISC has announced the end of maintenance for ISC DHCP as of the end of 2022"
... or 2.6.2 (with backported boost-1.87 fix, please), if 2.7.8 is just a development version: https://gitlab.isc.org/isc-projects/kea/-/wikis/Release-Notes/release-notes-2.7.8
even minor numbers are considered stable, odd are considered development. So 2.6.X would be stable, and 2.7.X is development. Happy if BOTH are packaged, but if a choice is made, 2.6.X please.
(from gentoo-dev) > Hello, > > the net-misc/kea is up for grabs. > > Best regards, > Dennis
Ouch, takers? I'm a bit loaded already, but since net-misc/dhcp is being replaced (upstream, or at least, that seems to be the push) with net-misc/kea I'm guessing we don't have significant choice in pushing this forward? I note net-misc/dhcp is base-system@gentoo.org, does it make sense for base-system to also onboard kea?
Someone's expressed an interest in bug 946391 at least.
That's good - I was *so* close to last-riting it already. - 2.6.3 contains the necessary boost-1.87 fix - 2.6.2 Fedora already managed to build against py3.14, so any version bump of ours should try too
Andreas, I get the sentiment, but when it comes to dhcpv6 dhcpd isn't a viable/workable option in most cases. It's got all kinds of random requirements, like not being able to bind on ppp interfaces, requiring binding on *broadcast* capable interfaces (where dhcpv6 can run pure unicast, but utilizes multicast in most casese). I'll help Peter where I can here if he steps forward, otherwise I'm going to see if I can get additional human resources made available from ULS's side for this. Kind regards, Jaco
>That's good - I was *so* close to last-riting it already. For what it's worth, I think that would be a big mistake to last-rite it. A fully fledged DHCP server is important to many of us. I'm running Gentoo on my router, which also acts as a DNS and DHCP server. I was using net-misc/dhcp until I saw it had been sunsetted, and then i switched to net-misc/kea. If net-misc/kea was to be removed, all we are left is net-dns/dnsmasq which has optional support for DHCP?
It needs a maintainer. A perpetually broken package serves no one.
I have an ebuild (2.6.X) that I had updated a little while ago but I abandonned the use of kea since. I can refresh it (and make a PR) quickly but I will not propose myself to maintain it.
(In reply to Nicolas PARLANT from comment #14) > I have an ebuild (2.6.X) that I had updated a little while ago but I > abandonned the use of kea since. I can refresh it (and make a PR) quickly > but I will not propose myself to maintain it. I'm working on a PR at the moment so any input would be useful
(In reply to Peter Leese from comment #15) > I'm working on a PR at the moment so any input would be useful Here's my work : https://github.com/gentoo/gentoo/compare/master...PPN-SD:gentoo:upd-kea https://github.com/gentoo/gentoo/commit/e567b55d4b9a077eb85128f6e5bf43ca769f8e7e I just need to skip more tests I think.
(In reply to Andreas Sturmlechner from comment #13) > It needs a maintainer. A perpetually broken package serves no one. I'm happy to step forward as a proxy maintainer, but I'm still on the learning curve at the moment when it comes to ebuilds.
(In reply to Peter Leese from comment #17) > (In reply to Andreas Sturmlechner from comment #13) > > It needs a maintainer. A perpetually broken package serves no one. > > I'm happy to step forward as a proxy maintainer, but I'm still on the > learning curve at the moment when it comes to ebuilds. Thanks, I'm really pleased to hear that and hope we can make that happen.
