I know if I received different sha256sum results from repeated reads of the same file that I would be tearing the system apart and re-assembling everything hoping for a bad connector.

lol

looks like it was ram

Actually I am always happy when it is RAM. Because then the problem is easily solved and it is done.

y agreed best possible outcome

good morftervening all. I have a makefile question - I have a project I build on multiple hosts, how would I tell FreeBSD, NetBSD and OpenBSD apart using makefile variables? I haven't seen a mention of the OS "name", just versions, mentioned in sys.mk,

nor have I seen direct mentions in the OpenBSD man page for make

Viking667: can you check instead for the features your program needs to use?

i suppose i should say first, what different thing should happen based on what you find out?

compiler, mainly. Because I'm compiling on NetBSD as well, I'm not counting on the user having installed clang there.

the program I'm compiling isn't compiler-dependent, but I'm a bit wary about simply slapping in a CC = cc line.

And I started compiling back in gcc-2.8 days, and the big change back in gcc2.96 was quite the upset for some.

s/2.8/2.83

I expect I'll need to answer the same question for the Linux installs.

i feel like if you solve this really well and portably, you'll have constructed autoconf

ugh. That thing.

:D

If you want to keep it simple then I would probably go with CC = cc there. However the general solution to portable build is, probably heresy here in *BSD but, autoconf+automake which work well.

I am a person that thinks progressive improvement is the best way. Start simple. Move forward slowly.

hm. The project's simple enough, its only real requirements are some sort of pdcurses/ncurses and a working terminal emulator that isn't totally braindead.

(after all, I started this all off in djgpp days)

[pawn stars guy] mmmn. best i can do is a working \r

?

*shrug* using autoconf beats creating autoconf by a mile :)

i'm trying to remember how you hook pkg-config into all that. but i would hope there's like an AC_CURSES sort of macro already written for you that does the right thing

Has NetBSD even got a pkg-config without that package being part of base?

as for a working terminal emulator... maybe i will run your program under eshell in emacs. less and vi somehow warn me in such cases that the terminal is not fully functional

yeah, list doesn't do that either. Mostly my own code from late nineties, other stuff from Bob Stout and someone else.

well yeah, exactly, "the right thing" when curses is part of base is probably not pkg-config. i feel like linuxes have pkg-config set up for more things more often

They seem to, yes.

more things are packages there :)

far more.

Howdy, folks!

I managed to get TF2 to run, but got stuck since the keyboard input got goofed up.

Basically, mouse input works, but it wasn't picking up on the keyboard. (Probably because of a goofed up layout that LSU chooses when running the game.)

It wasn't like that with HL2:DM (And probably other source games). So it must be a SDL2 goof up.

I could probably test it with a test SDL2 program running in a linux chroot.

Well, keyboard input works when running the game using vulkan, but poops itself when using OpenGL.

strange...

Other than that, i tested it with a simple SP session on itemtest, and ctf_2fort, and it's a solid >=60 FPS out of the gate with all video settings set to low, with some being configured via the console, and some launch options.

Then with 16 TF Bots(nextbot), it kinda dips down, but it's not that bad.

Run 'freebsd-update [options] fetch' first.

im getting this when i run: freebsd-update install

SKull: "systemd caused an outrage in the linux world. but was that outrage based upon actual user experience or just people going "it's new and therefore i don't like it!"." If I were to say, the former. SystemD is bloated, buggy, it outright destroys the underlying distro overtime (which happened to some of my Debian and Arch machines in the past), very anti-Unix-like, and serious exploits are

commonly marked as "won't fix" or "it's not a bug, it's a feature". The only people who say "it's new and therefore I don't like it" are progressive (or regressive rather) YouTubers like "TheLinuxExperiment" who keep pushing for making Linux more like Windows, but without Microsoft (which is funny, because Microsoft is among the biggest sponsors of the Linux kernel, and they have quite a lot of

say in it too).

Just wondering, what exactly is the process of submitting a package to make it installable with pkg?

remiliascarlet: create a port, Q/A the port, generate a patch against the ports tree that adds your port, post it to bugzilla

the porter's handbook goes into all of that in greater detail

kevans: Thanks, I'll forward that then.

Yep, multiplayer in TF2 works pretty darn well. (Again, ignoring the fact i have a crummy internet connection.)

Tried a community server, and then casual. Both 100% work without an issue.

Though, i did use mastercomfig for some tweaks here and there.

Howdy, folks!

I tried TF2 before, but then I saw it was pretty much online multiplayer only, and never played it again.

mane heyoo! how's your server going?

morning

antranigv: :-) it vlepy.com hostsujemy.net and nocne-rozmowy.pl

Soon gonna be more

Thanks for asking

mane nice!

It hosts*

I just don’t know why my pf.rules won’t be loaded on boot

I need to do that manually

mane: Did you do sysrc pf_enable=YES ?

Also sysrc pf_rules=PATH might be needed if it is not /etc/pf.conf.

jan0sch: I got those

Weird, should work fine. Any error messages during boot? I once had the problem that I had an interface in the rules that was created by a service which started after pf and that messed things up.

idk

hi, I am reinstalling FreeBSD in my old Dell Latitude E4200 but when selecting 1. Boot Installer from the USB image it gets stuck at Loading Kernel. Does anyone have faced similar issue? any ideas/tips? FreeBSD14.1

I set verbose and now it works

I get a lot of ahcich4 CONNECT requested / AHCI reset / SATA connect timeout AHCI reset : device not found

why?

rwp, you've already said, df gets it wrong so it's all good... mostly... the thing i find odd is the 'size' in 'zfs list' however, 'zpool list' reports the correct size. I guess it's doing the 84T minus what's used in other datasets? (if so then it's correct, confusing but correct.)

there's no "size" in "zfs list"?

yeah ignore that.. my f*up .. changed the order in my paste block and didn't read it.. I need sleep i think.

(or a good strong drink)

anyone know how to get du to give me a total for each directory in the root file system and only root file system? (tip: -hsx * isn't going to cut it as it will pick up the mount points it's not supposed to traverse on the command line and traverse them (correctly) as they are

'specified')

du -sh /*/ might do what you're looking for

-d 1 (as -s is a shortcut for -d 0)

nimaje, no

you have to keep -x of course

i did

what is your problem with it? for me du -hxd 1 / seems to do exactly what you want

ahh hang on i might a misunderstood - rerunning as / and not /*

i have 2 zfs pools in the root mounted at /cache and /sorbs .. i don't want them in the results because they are huge with a huge number of files and something just filled up the root fs and I'm looking for the directory where it resides... as it happens i found it without getting du to work.. but 30 odd years using *NIX and never worked out how to do it :P

"sudo du -xhd 1 /" did indeed work perfectly and did what i wanted.

mane: here I have a /dev/pf and I enable pf related options in kernel

where can I find information about the VT, specifically, I am getting VGA 640x480 and I remember before (in FreeBSD 12) I managed to get it properly configured with a smaller font

thanks

does freebsd 14.1 base not include ipv6 dhcp client?

afaik it does not, are you in a situation where you need one?

yes, but i can install from ports as well

which one is recommended?

i only find isc dhcp package, which is not developed anymore as far as I understand

there is dhcpcd which had a release in may

hey all when using vimage with jails, I should be able to use ifconfig_epair100b="DHCP" in the rc.conf of the jail if epair100a is connected to a bridge which also has a dhcp server connected right? (I seen to get getting a bpf permission error when trying this)

the error is jail side, ah I bet I need raw sockets

oh I have them enabled already, any idea what I am missing?

pkg install drm-kmod, and then in /etc/rc.conf kld_list="i915kms" (for Intel)

Michelle, I wouldn't say "wrong" so much as "different". df was created when hard partitions were disks. But zfs pools sharing space across datasets. So for any particular dataset the size is an undefined quantity. The pooled data might be consumed by any of the datasets. So df is wired to use available as size instead.

Michelle, This results in df reporting that as datasets consume space that the file system shrinks and grows as datasets free up space. Which is certainly an odd thing!

why is vlc not in the quarterly repositories?

rwp point taken.. however it is unexpected behaviour to some respects (which to me is 'wrong') .. I can understand that for (sub)datasets but the "root" pool I would expect it to show everything because all the datasets are children (as terminology is likely wrong/confusing - in my case I suggest 'sorbs' should show the full pool size ie 'zpool list' reported, and then similar to existing (if not the same) for sorbs/Movies sorbs/TV sorbs/Music etc..)

polarian: probably x265, like some other stuff, not sure why the checksum of that patch changed, which made the build fail

nimaje: ah

ok np thank you

hey all I am running 14.1-RELEASE-p2, I did a buildworld/installworld to reach this patchset, so from there I did an installworld to zroot/usr/venv/jail/mount/base and made a snapshot, I then made a clone, which I used for: zroot/usr/venv/jail/mount/ports.paulwebster.online, I then created a jail, here is my jail.conf: dpaste.org/j2miX and my /etc/devfs.rules: dpaste.org/qi1JJ in my /etc/rc.conf in the jail I have:

ifconfig_epair100b="up"

and in /etc/rc.local I have: dhclient epair100b, this worked before I rebooted. After reboot I am receiving this when I jexec into the jail: dpaste.org/rPPap what have I got wrong?

no idea what you did wrong, but why dhclient in rc.local instead ifconfig_epair100b="up DHCP" ?

debugging really

I tried that originally but what it does it make it so 'service jail restart' hangs

if I can get it working via rc.local that would be the next step :)

how about first try with giving it some static ip and then debug from there?

it works fine with a static ip

and trying dhclient from that started jail?

yep same problem

"Can't find free BPF," according to the paste

indeed

and its correct its not in /dev

however it should be according to devfs.rules

forums.freebsd.org/threads/vnet-jai…interfaces-unable-to-run-dhcp.84114 ?

yeah its basically the same as what I have: dpaste.org/j2miX

oops wron link

and in my jail.conf I am of course applying ruleset 10

and I got it working :) I have no idea why, I just recompiled my kernel for an unrelated issue; on box reboot it now just magically works

huh interesting, when I move to using ifconf_....=DHCP it still hangs

it seems to prefer the rc.local dhclient method

infact it does not just prefer it, it does not even get an ip if I use ifconfig_e100b=DHCP in rc.conf

so now onwards with nat and the firewall (yay)

daemon: did you forget the pub?

I cant for the life of me find out how to mount/read a zvol on the host system, bhyve won't boot it and I can't figure out how to investigate why

any i deas?

zvols are block devices, not filesystems.

polarian: zpool import zvol?

polarian: i think you want mdconfig(8)

er wait what partitions and/or filesystems are on the zvol?

jaredj: yes

the zvol should have a gpt partition table on it with OpenBSD FFS2 filesystems (UFS driver can mount these and mostly read the data)

I have to figure out why bhyve cant find /bsd

(the kernel)

yeah. soo after you mdconfig -a it, i think the geom utilities (gpart, yes?) should show its partitions

Hello. The troubles with prosody started after update

For me this is very sad.

Hello. The troubles with prosody started after upgrade*

/usr/local/bin/lua54: error loading module 'util.encodings' from file '/usr/local/lib/prosody/util/encodings.so': Shared object "libicui18n.so.73" not found, required by "encodings.so"

That is not starting anymore. What can I do?

Now I can't write to anyone...

that kinda thing happens to me, V-T60, when i don't update the base system before getting a newer pkg update

scoobybejesus: How is that?

well, is this in a jail or on the host?

Did I choose to upgrade incorrect way?

so you did pkg upgrade and that updated prosody and now it doesn't work anymore?

On the host......

Yes

I did pkg update and pkg upgrade

It upgraded all packages and now prosody doesn't work

are you on 14.1-RELEASE-p3?

Now I feel so isolated.

FreeBSD orangepi 14.0-RELEASE FreeBSD 14.0-RELEASE #0 releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 09:03:07 UTC 2023 root⊙rnfo:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm

How do I?

did it update lua or icu too?

what does freebsd-version -kru show?

14.0-RELEASE

14.0-RELEASE

14.0-RELEASE

That's end?

I broke the computer?

seems like you might want to do freebsd-update fetch install

literalyl?

literally?

hm, do you have /usr/local/lib/libicui18n.so.74 ?

to get to the latest patch release

# freebsd-update fetch install

# file /usr/local/lib/libicui18n.so.74

/usr/local/lib/libicui18n.so.74: symbolic link to libicui18n.so.74.2

Excellent...

so for some reason that '/usr/local/lib/prosody/util/encodings.so' is linked to the wrong version

Fetching public key from update1.freebsd.org... failed.

for years, I've had a really stupid idea that I've wanted to do that would require me to do a "kBSD" of one sort or another (thought of doing it with NetBSD's kernel, but I haven't been able to split it out of their build system - so maybe I could do it with a FreeBSD kernel and libc instead). it's a *really* stupid idea though, about a SysV-flavored *x with BSD-level freeness (I got reasons, but they're mostly daft)

linked to the wrong version?

Can I link to the right version?

No escape anymore?

Can I downgrade the package?

root@orangepi:/usr/local/lib/prosody/util # file encodings.so

encodings.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (FreeBSD), dynamically linked, for FreeBSD 14.0 (1400097), stripped

What can be done with it?

Does FreeBSD allow to install the earlier version?

i think you can install from your pkg cache, but a quick search doesn't reveal how to specify that it use the cached version

i broke the computer. excellent.

so now no other way but compile freebsd from sources?

pkg add /var/cache/pkg/...

Installing prosody-0.12.4...

the most recent version of prosody-0.12.4 is already installed

There are only this one...

any way find correct libicu?

the problem is that prosody expects an older version of icu for some reason, so you should try pkg install -f prosody first

Is icu installed?

is the old pkg version in /var/cache/pkg/? what nimaje was pointing out...

# ls -alh /var/cache/pkg/prosody-0.12.*

lrwxr-xr-x 1 root wheel 29B Jan 12 2010 /var/cache/pkg/prosody-0.12.4.pkg -> prosody-0.12.4~39b955520d.pkg

-rw-r--r-- 1 root wheel 367K Jan 11 2024 /var/cache/pkg/prosody-0.12.4~39b955520d.pkg

It says Jan 12

Probably it is the old one?

though it is weird.

It says that I already have this version

i need -f?

yeah, I'd try that - pkg install -fy /var/cache/pkg/prosody-0.12.4.pkg

yes, i tried

no help

Shared object "libicui18n.so.73" not found, required by "encodings.so"

% pkg search -f prosody

i have icu-74.2_1,1 International Components for Unicode (from IBM)

[...] prosody-0.12.4_3 [...]

Shared Libs required:

libicuuc.so.74

libicui18n.so.74

libicudata.so.74

and this too lua54-icu-utils-0.0.20220329_4 Lua interface to selected ICU utilities

maybe you need a slightly newer prosody package?

that was without _3

from my /var/cache/pkg

now i can upgrade back

Installed packages to be UPGRADED: prosody: 0.12.4 -> 0.12.4_3

should i?

ok, i try

well, you have that 74 version of the icu library, so i'd say yes

prosody should have been rebuilt if icu changed.

what on earth.............

# service prosody restart

prosody not running?

Starting prosody.

V-T60: install -f to make pkg ignore that it already has it and download and install anyway, not add -f

it started working

hurrah!

insane

21:09:44 - Connection re-established. Nick

You saved my XMPP from collapse

I say: #freebsd is good

Nice.

ohhh - i see, you would have expected pkg upgrade to do that. that is odd, i don't know why it didn't

insane is waht I'm trying to do by making a SysV analog off a BSD kernel, lol

thanks

:D

V-T60: so your first pkg upgrade didn't update prosody for some reason

i don't know what was that

but i managed to say good bye to my prosody server

x.x

V-T60: Do you still have the full output of the pkg upgrade?

If so paste it to pad.bsd.to

Licca: whyyy

"alternate history" OSes are kinda my thing lol

V-T60: No the first time you ran pkg upgrade

and a kernel is a bit too much for my capability lol

hell, I made a few attempts to rewrite a simpler kernel, like MS-DOS...but since MS-DOS 4.01 has been MIT'd, that's been obviated

skered: bpa.st/raw/JFUQ

i don't even understand now why on earth

I actually did start writing my own userland, though I'll prolly can a lot of it

the prosody wasn't even upgraded

i expected that something could be changed for good with an upgrade

and first of all decided to restart the prosody.

I'd guess it was with the recalc after the init. fetching.

oh... During the icu 74.2 bump prosody wasn't revision bumped.

now i don't understand, did i have _3 or the simple one

What does it mean?

>During the icu 74.2 bump prosody wasn't revision bumped

How is that so?

oh, yeah, looks so?

lrwxr-xr-x 1 root wheel 31B Aug 16 21:08 prosody-0.12.4_3.pkg -> prosody-0.12.4_3~361f8b79d3.pkg

The new file appeared in my /var/cache/pkg

skered: Should I expect for package working stable now?

Or are there still some issues I should know about?

I think you're alright.

good.

And looks like the package is new

So I changed something for good.

Everything that uses icu should be broken?

What do you mean?

What is broken?

so I wanted to come up with a minimal "build system", with just a kernel, libc and /bin/sh, to which I could start adding tools one by one

V-T60: Nothing.

V-T60, "bump" here means moving to a new version. So someone maintaining the libicui18n port, which gets built into the packages, which contain the files libicui18n, moved from making it build version 73 to version 74

But prosody should have built multiple time sinsce isu 74.2.. I dunno something odd with pkg

V-T60: the number after the underscore in the package version is the 'revision'. this is bumped up to a new number when a new package needs to be released even though the software being built has not changed (e.g., prosody here: it was version 0.12.4 before and version 0.12.4 after)...

why you call this built? oh, or you mean package maintainers?

yes.

yes.

so, the 0.12.4 (underscore-nothing) package you had, contained libraries that depended on libicui18n version 73

oh, so you mean the version of this lib shouldn't have been changed?

during the _n

the 0.12.4 underscore 3 package contains libraries that depend on libicui18n version 74

oh, so that's strange if so

it's the same version of the prosody source code being built, 0.12.4, but other things have changed; that's why the underscore numbers are there and are incremented

the dependencies between the packages /should/ have made it so your upgrade would Just Work

yeah, that is what i expected.

I'd like to guess a second `pkg upgrade` might have fixed it too.

hmmm

I've seen this in the past with pkg though when making a large jump (all be it 1) between versions.

This would have been at elast a year old between updates?

Albeit?

hey uncle dch . I see that "DTRACE : on" in erlang-runtime27, however, I still don't see erlang* in dtrace -l, any thoughts?

antranigv: did you specify the binary using -c cmd?

otherwise it would list just static kernel probes

yuripv usually I don't need to do that. one sec

that's... interesting

it works fine with `dtrace -l` when using erl, but not when running `iex`

Hey! Has anyone managed to setup brightness controls in VT?

using the brightness buttons

oh shit, I just realized! I ran `iex` before loading DTrace. I'm sorry. dch you may ignore me.

could it be that firefox is not available for 14.1-RELEASE in amd64 ?

# mkdir -p /usr/local/etc/pkg/repos

# echo 'FreeBSD: { url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest" }' > /usr/local/etc/pkg/repos/FreeBSD.conf

pkg update

pkg install firefox

I know how to do that

I installed 14.1-RELEASE, that would be the quarterly, right?

so it is not available -I am a bit surprised, that is all-

firefox is available in quarterly and I have it installed from quarterly but the x265 dependency failed to build in the most recent build.

Errors from x265 blocking other things: pkg-status.freebsd.org/beefy20/data…8dd78683/logs/errors/x265-3.5_2.log

so it is a temporary unavailability (right now my understanding is that it is not available as per the freshports page for amd64). -I can not install it in my system-

In this case the error is "SHA256 Checksum mismatch for x265-asm-warnings.patch".

Not unless you have a previous package of it saved off. And the dependencies. Which you might have on another system.

I took the opportunity to see if there was any other browser more lightweight ot be used (I only have to access some router admin web from that system)

Tried dillo but it does not work

The most recentkly installable version that I have installed is firefox-129.0_1,2.pkg from Aug 3.

rwp so can you use a previous version?

What do you mean? I am running it right now.

if I type pkg install firefox, it does not work

I just can't update it until the next version builds and becomes available.

freshports show "-" for amd64 14 quarterly

uskerine: 14.1-RELEASE is quarterly yes... freshports.org/www/firefox shows there is no build available for quarterly 14

Right. Because the build failed for it.

Actually for firefox and vlc and all of the consumers of x265 they were all skipped because x265 failed.

This is one of those frequently occurring problems that seems like it would be easy to improve. (Says I a newcomer to FreeBSD.) Don't remove the previous packages from the repo until the new packages have built.

rwp: feel free to take it to the ML and report the issue :)

I am not sure about the proper place to stick it but I am sure a freebsd staff member will see it on the mailing list

uskerine, Pop over to pkg-status.freebsd.org/beefy20/buil…0amd64-quarterly&build=d032848c5848 and then scroll down to skipped ports then enter "firefox" into the search field.

polarian, I am pretty sure that to the powers-that-be the current situation is a well known one to them. And there is probably a very good reason things are as they are now. But that reason is not really strongly visible to the community. And this issue keeps popping up here as people run into the problem.

well take Arch Linux as an example, the package in the main repositories is only replaced after it is built and tested within a test repository

so it is valid criticism :)

I would think FreeBSD would be like that but it is not.

the root cause is that dependencies are a modern plague

what happened to download the .tar.Z uncompress and "make" "make install"

Since it takes quite a few days for the build systems to complete builds, days and days, holding cycles for a full complete build would delay the release of working builds.

uskerine, You have hit the point exactly! I think the common wisdom is that people who care about this should run a local build and the tool is poudriere.

I am a newcomer myself and have not gotten around to setting up poudriere but it has gotten down to be on my short list of tasks that I simply must do soon.

Meanwhile... I pkg upgrade pretty much daily and so catch almost every pkg release. Therefore if I need to install something that is not in the upstream I can always transfer it from my very long existing /var/cache/pkg/* directory of previous pkgs.

rwp: freebsd is all about stability... how can a system be stable if one second there is a port and the next second it is gone.

what I mean is something as classic as xfig requires 25 dependencies

Say if this happened within quarterly for an important network utility or something... and a companies entire workflow is ruined for 24 hours due to it

uskerine, I totally agree with you about the dependency plague that everything seems to be suffering from these days.

polarian, A company depending upon FreeBSD is probably running poudriere creating their own local pkg repository and won't hit this problem.

And notably Netflix is well known as running FreeBSD CURRENT upgrading frequently for their servers.

also you can not keep using FreeBSD 12, I recovered an old laptop (FreeBSD 12) and had to reinstall from scratch to 14 because I could not pkg update and the upgrade to 13.3 failed

Also the worst things are desktopy things like firefox and vlc and servers don't typically even have X installed (I wouldn't install it on a server) and so things like this are less likely to affect a server.

uskerine, Just for clarification the ports/pkg upgrade failed but the base upgrade from 12 forward worked okay for base?

there was a study (an actual paper) about the dependencies in Maven (Java), it concluded that around 70% of the dependencies between packages were not actually needed, the mess is astronomucal

rwp: I doubt it... the amount of compute that would take would not be finantially viable. If they want high speed access to the pkg repository they would likely mirror it...

rwp I was no longer able to pkg update/pkg upgrade my FreeBSD 12

and therefore the process to upgrade to 13 (which requires the 12 being updated) failed

rwp: but my point is it could happen to any port...

no big deal as it was an auxiliary laptop, I reinstalled 14 from scratch and all good

uskerine, So... if that were me, I would grab the command from the "man pkg" to get "pkg query -e '%a = 0' %o" to list packages I had installed manually. Then I would purge all of them. Then I would install them again on the new system.

the one benefit of freebsd and all BSDs as a whole is that the base system includes the userland, so pkg breaking will not break your system, only additional software

Some of them probably changed package names. That would be a small number and I would scramble and deal with those problems as I saw them.

By purge all of them I would save a backup copy of /usr/local/etc for any customizations I had done so I could reference those later. Then I have a handful of things that I install myself in /usr/local and then I would use pkg to erase everything installed by pkg. Then I would probably clean up any lint files left behind manually. Then could install everything fresh from there and configure using the saved off etc configuration.

Effectively FreeBSD has two release models. FreeBSD base is a stable release model. FreeBSD ports is a rolling release model.

rwp: I pretty much did exactly this last week to go from 9.3-p43(+) to 14.1

The problem with rolling releases is pretty much exactly the problem you experienced. If you don't keep up and allow a system to fall too far behind then due to changes always rolling it becomes impossible to upgrade it as a rolling upgrade.

From 9 to 14! That's quite a jump!

yup.. completely pointless except for openssl

But for the ports/pkgs a rolling release being broken does not break the base system. And the base system working reliably always allows one to fix the ports/pkgs and bring them up to date.

Was that system on the hostile Internet? With OpenSSH available? I am not aware of any direct attacks at this time but that's always a concern that an old sshd will become vulnerable.

so based on your experience, when firefox will be avaialble again for quarterly? (I assume that firefox missing for latest quarterly in amd64 is something not that irrelevant)

Otherwise I totally agree that if a machine is doing that it is supposed to be doing then there is no real reason to upgrade it. It's not really an upgrade in that case. What was working before is still working afterward. If totally successful then nothing has changed.

the ssh (and all other services) was (is still) behind a firewall in rfc1912 space with no incoming nat

Then it was almost completely a noop for you as you say. Nothing changed.

uskerine, A while back I waited for a broken sudo build to run through TWO build cycles before things were repaired and it popped out and that took about 12 days IIRC in that case. But every case will have details.

I am only sure that it will eventually be built. Someone with more skills at navigating the pkg-status page above should be able to interpret the status and the state and predict things better than I by a lot.

the upgrade was needed for patching services available on the lan, openssl was the blocker.. it was getting too messy to use ports for openssl and patch everything myself back to 9.3

uskerine, I feel your pain though and I feel like I should make my /var/cache/pkg/*.pkg files available to you in some way so that you can install the previous version of firefox. Which as far as I know is not otherwise saved by FreeBSD systems.

I myself am still learning the nooks and crannies of how FreeBSD infrastructure is handled. I don't think there is an archive.freebsd.org like thing that we could reach into in order to retrieve previously built versions. But maybe by saying this someone who knows more will pop in and point to one! We can always hope.

For that matter this might have been talked about at a conference presentation and if anyone knows of any talk on the build infrastructure and can post a reference to a video or paper or other doc I would definitely be interested in seeing it.

My observation of things, which is likely wrong in many ways, is that when a build slot becomes available then the builder attempts to build the top of the ports tree at the commit that it happens to be at the time it started the build. Then it tries to run all of the way to completion. Along the way some things might fail to build such as that pesky x265 dependency which creates of cone of packages which are not built in that cycle.

This build of everything takes several DAYS to complete. Even if a fix to a broken port is committed and pushed in that time it will continue on the previous until it has completed it. Then when done this build cycle repeats grabbing the next top of ports git tree.

The project builders needing to build EVERYTHING is a big task and takes days. This is one of the motivations to run a local package builder. Because then you only build the list of things you specify to build and the task is completed more quickly.

Except for Chromium/Firefox/others which are HUGE pigs to build and local build resources might not be enough and those things can take days to build on lower end hardware.

Again my understanding is a little vague and I welcome it when anyone who knows corrects my misunderstandings of things.

rwp: you're not wrong

rwp: there's also a number of things wrong with package management (in reference to quarterly builds) that is just bad management (in my opinion) and i had a dummy spit over it way back in the days of 10 being current.. haven't really had much to do with FreeBSD (as a project) since because of it (and won't for sometime).. won't get into it here (people can read the archives) but from the current conversation about broken dependencies and missing packa

ge.. that is a direct symptom of my beef.

I think I can see how things got to here and now. Before binary pkgs were created FreeBSD was a source build system. cvsup or whatever and then build everything locally. Have a build failure? Hack and patch it into working locally. That's less accessible to newcomers unfamiliar with the process but well loved by long time skilled users.

Along comes binary pkgs and now things are totally nice and easy! Except not all of the bugs have yet been worked out of the binary pkg infrastructure and we end up with problems like this problem with a new system not being able to pkg install things that were installable last week but not this week.