update stable to 7.3.1.1
update latest to 7.4.0-beta1
./release-to-git.sh committed branch 7.4.0-beta1
hostapd: updated to upstream version 2.11
libcares: updated to upstream version 1.33.1
iperf3: updated to upstream version 3.17.1
nano: updated to upstream 8.1
mdadm: fix build
protobuf-c: updated to upstream version 1.5.0
initrd: bump version to 7.4.0-beta1
axel: updfated to upstream version 2.17.14
curl: updated to upstream version 8.9.1
unbound: updated to upstream version 1.21.0
libedit: updated to upstream version 20240808-3.1
nftables: updated to upstream version 1.1.0
libnftnl: updated to upstream version 1.2.7
kernel: fix building arm images
libedit: requires libncurses to build
openssl: updated to upstream version 3.0.14
ixgbe: updated zo upstream version 5.20.10
uclibc-ng: updated to upstream version 1.0.50
squid: fix build with newer versions of libxml2
libxslt: updated to upstream version 1.1.42
libffi: updated to upstream version 3.4.6
openldap: updated to upstream version 2.6.8
sqlite: updated to upstream version 3.46.0
strace: updated to upstream version 6.10
libxml2: updated to upstream version 2.13.3
toolchain: add necessary fix
wireless-regdb: updated to upstream version 2024.07.04
openvpn: updated to upstream version 2.6.12
pciutils: updated to upstream version 3.13.0
fail2ban: updated to upstream version 1.1.0
kernel: fix build slabinfo.c
devtools: adjust to uClib-ng 1.0.49
buildpacket.pl: adjust uClibc-ng version
kernel: updated to upstream version 6.6(.35)
update uClibc-ng to 1.0.49
./release-to-git.sh committed branch 7.3.1.1
openssl: updated to upstream version 3.0.14
initrd: bump version to 7.3.1.1
root.loadmodules: try to fix timeout issues for module loading from modules.sqfs
Hi ET, Now I would argue that we should leave the name convention for the bridge package as is, e.g. bridge.lrp I agree that would be the 'cleanest' option - provided we can maintain the same behaviour for bridges defined in /etc/network/interfaces (especially since the package name is 'bridge.lrp' and so matches the new command name). Looking at my currently running box (7.1.0) ip appears not to have this capability gatekeeper# bridge --help -sh: bridge: not found That is to be expected; we currently...
Hi David Am 07.08.2024 um 17:37 schrieb david M brooke: Hi ET, Thanks for your input. I have not looked in the new interfaces but would ifup/ifdown work the same? I believe so - in fact I think we need to require that. We would want to make sure that the existing syntax in /etc/network/interfaces works as today. As long as we can arrange that, the only users impacted would be those which call 'brctl' from their own scripts. Which is probably a minority. Now I would argue that we should leave the...
Hi ET, Thanks for your input. I have not looked in the new interfaces but would ifup/ifdown work the same? I believe so - in fact I think we need to require that. We would want to make sure that the existing syntax in /etc/network/interfaces works as today. As long as we can arrange that, the only users impacted would be those which call 'brctl' from their own scripts. dMb
Hi David Am 03.08.2024 um 11:08 schrieb david M brooke: [tickets:#110] https://sourceforge.net/p/leaf/tickets/110/ bridge-utils (for 'brctl') is deprecated upstream Status: new Milestone: Bering-uClibc 7.2.x Created: Sat Aug 03, 2024 09:08 AM UTC by david M brooke Last Updated: Sat Aug 03, 2024 09:08 AM UTC Owner: nobody The bridge.lrp Package, which uses bridge-utils to implement the brctl command has been declared obsolete as per https://wiki.linuxfoundation.org/networking/bridge https://wiki.linuxfoundation.org/networking/bridge...
bridge-utils (for 'brctl') is deprecated upstream
./release-to-git.sh committed branch 7.3.1.1-rc1
initrd: reduce risk of squashfs unmount while still loading modules