In D41873#975105, @dfr wrote:In D41873#975104, @manu wrote:In D41873#975103, @dfr wrote:In D41873#975075, @manu wrote:I think that the question is should we have a FreeBSD-sh package or not.
I really like the idea of a FreeBSD-sh package - it covers what I'm trying to achieve here and avoids breaking up the carefully curated set of libs in runtime. We would have to be careful about upgrades to try to avoid leaving systems without /bin/sh.
There is always FreeBSD-rescue in case sh fails to upgrade
Good point. I will abandon this review and make one to add FreeBSD-sh.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Nov 24 2023
Nov 24 2023
In D41873#975104, @manu wrote:In D41873#975103, @dfr wrote:In D41873#975075, @manu wrote:I think that the question is should we have a FreeBSD-sh package or not.
I really like the idea of a FreeBSD-sh package - it covers what I'm trying to achieve here and avoids breaking up the carefully curated set of libs in runtime. We would have to be careful about upgrades to try to avoid leaving systems without /bin/sh.
There is always FreeBSD-rescue in case sh fails to upgrade
In D41873#975103, @dfr wrote:In D41873#975075, @manu wrote:I think that the question is should we have a FreeBSD-sh package or not.
I really like the idea of a FreeBSD-sh package - it covers what I'm trying to achieve here and avoids breaking up the carefully curated set of libs in runtime. We would have to be careful about upgrades to try to avoid leaving systems without /bin/sh.
In D41873#975075, @manu wrote:I think that the question is should we have a FreeBSD-sh package or not.
I'm not against *this* specifically, it will be nice to be able to have a shell-free nginx without FreeBSD-runtime but if we start doing this I think that we will end up moving all the libs in clibs.
I mean, it works with nginx but what about other programs ? Some that needs casper libs for example or gssapi ? Those are still in FreeBSD-runtime. Right now FreeBSD-runtime is only 8MiB so that's not that big.
I think that the question is should we have a FreeBSD-sh package or not.
Nov 14 2023
Nov 14 2023
freebsd_igalic.co added a reviewer for D41873: pkgbase: Move libz and libcrypt from runtime to clibs: pkgbase.
Sep 14 2023
Sep 14 2023
Document the change to MANSPLITPKG
Jul 16 2023
Jul 16 2023
Mar 15 2023
Mar 15 2023
So where is this review? It seems to have wound down a bit.
Feb 20 2023
Feb 20 2023
I'll be updating this review and try to revive it.
Nov 8 2021
Nov 8 2021
Apr 20 2021
Apr 20 2021
ehem_freebsd_m5p.com added a comment to D29224: make only vital packages vital, not their sub-packages.
I'm unsure which commit did it, but at a point near this commit the time taken by release builds drastically decreased. Before this close to 20 hours for an aarch64 cross-build, just over 6 after. Even though I can leave my build machine running, the decrease in latency is very nice. Thank you.
Mar 28 2021
Mar 28 2021
Mar 18 2021
Mar 18 2021
freebsd_igalic.co updated the diff for D29224: make only vital packages vital, not their sub-packages.
rebase
Looks ok,
Can you rebase your patch against latest main ?
Thanks.
Mar 12 2021
Mar 12 2021
freebsd_igalic.co updated the summary of D29224: make only vital packages vital, not their sub-packages.
freebsd_igalic.co retitled D29224: make only vital packages vital, not their sub-packages from make jail, runtimes & utilities sub-packages non-vital to make only vital packages vital, not their sub-packages.
freebsd_igalic.co added a comment to D29224: make only vital packages vital, not their sub-packages.
addressed in latest update
freebsd_igalic.co updated the diff for D29224: make only vital packages vital, not their sub-packages.
address @manu's review
Mar 11 2021
Mar 11 2021
freebsd_igalic.co added inline comments to D29224: make only vital packages vital, not their sub-packages.
I don't think that the jail package should be vital.
Otherwise that looks good.
freebsd_igalic.co added a reviewer for D29224: make only vital packages vital, not their sub-packages: pkgbase.
Jan 30 2021
Jan 30 2021
Jan 21 2021
Jan 21 2021
Jan 14 2021
Jan 14 2021
manu added a comment to D20734: pkgbase: differentiate package versions for ALPHA/BETA/PRERELEASE/RC phases (part 2).
Push with a rebase and a few modif (PRERELEASE didn't worked).
Jan 8 2021
Jan 8 2021
addressed @swills' concerns.
I suggested this kind of approach in D27959 for kldxref; I think it's reasonable in that case, although perhaps we could indeed end up with something like if_em.test.ko
Jan 4 2021
Jan 4 2021
Dec 31 2020
Dec 31 2020
Dec 24 2020
Dec 24 2020
Dec 21 2020
Dec 21 2020
OK from manpages.
Dec 20 2020
Dec 20 2020
address @yuripv's comments.
May 26 2020
May 26 2020
Apr 17 2020
Apr 17 2020
Mar 20 2020
Mar 20 2020
rene added a comment to D20734: pkgbase: differentiate package versions for ALPHA/BETA/PRERELEASE/RC phases (part 2).
ping?
Jan 29 2020
Jan 29 2020
Nov 27 2019
Nov 27 2019
Sep 19 2019
Sep 19 2019
rene updated the diff for D20734: pkgbase: differentiate package versions for ALPHA/BETA/PRERELEASE/RC phases (part 2).
Remove the ".0" in version numbers for FreeBSD-CURRENT (so 13.s20190919151659 instead of 13.0.s20190919151659). Taken from D8943
Jul 1 2019
Jul 1 2019
rene added a comment to D20734: pkgbase: differentiate package versions for ALPHA/BETA/PRERELEASE/RC phases (part 2).
Merge ideas from D8943
mat added a comment to D20734: pkgbase: differentiate package versions for ALPHA/BETA/PRERELEASE/RC phases (part 2).
This is quite similar to D8943.
Jun 24 2019
Jun 24 2019
Jun 16 2019
Jun 16 2019
D20651: pkgbase: differentiate package versions for ALPHA/BETA/PRERELEASE/RC phases is now accepted and ready to land.
rene added a comment to D20651: pkgbase: differentiate package versions for ALPHA/BETA/PRERELEASE/RC phases.
Address @manu comments.
Jun 15 2019
Jun 15 2019
manu added inline comments to D20651: pkgbase: differentiate package versions for ALPHA/BETA/PRERELEASE/RC phases.
Jun 12 2019
Jun 12 2019
Jun 11 2019
Jun 11 2019