08:49:11 Hi all! After upgrading to pkg-2.4.x I get the following error when running: cd /usr/ports/packages/All && pkg create -a && /usr/sbin/pkg repo /usr/ports/packages/ //repo.key 08:49:16 pkg: /usr/ports/packages/All/pkg-2.4.2_1.pkg is not a valid package: no manifest found 10:19:28 sgs: there's a related thread on ports@ which might provide some clues ("pkg-2.4.1 broken?") 15:26:10 I would like to know if there is a way to request an app to be ported to FreeBSD. Who would I submit this request to if there is a way to do it? 15:27:01 Which app is it? 15:34:46 zen-browser 15:35:38 I ran across it in Manjaro Linux. Can't remember if it was from the main repos or the AUR. 15:36:09 ... of Arch. 16:18:03 Hmm... "# Re-do process to pick up [possibly] redefined $rc_conf_files" Under what circumstances could there be a difference between the first time and an additional time? 16:20:03 And in the new proposal there is no delay in that very tight loop. If I saw that code I would think it was a coding error for certain. 16:21:23 rwp: what are you referring to? An open review or commit? 16:25:09 rwp: why would you put a delay in rc.conf? that would make every rc script slow for no reason? 16:25:40 bdrewery: referring to https://reviews.freebsd.org/D53597 i think, which someone posted earlier 16:33:07 Hmm... I guess that was in the scrollback from yesterday. I just got back from a trip and looked at IRC and saw: < ketas> oh loooook https://reviews.freebsd.org/D53597 16:35:44 there was no delay before 16:36:14 Right. Hence my question under what circumstances could there be a difference between the first time and an additional time? 16:36:57 if rc_conf_files has new files 16:37:06 And how might that happen? 16:37:14 that's the whole point of that code 16:37:44 when files loaded redefine it 16:38:39 Okay. I see it now. It's initially this: rc_conf_files="/etc/rc.conf /etc/rc.conf.local" 16:38:59 But then someone redefines that to be somethign else in /etc/rc.conf such as rc_conf_files="/etc/rc.conf /etc/rc.conf.local /etc/myotherlocalrc.conf" 16:39:02 yes 16:39:29 And so it runs through and loads files not yet loaded, again, to pick up that new myotherlocalrc.conf file. 16:39:59 yes 16:40:12 periodic.conf needs it actually but it looked weird to me at first and then kevans pushed me to rewrite even the place i got idea from 16:40:13 And then the proposed change would allow myotherlocalrc.conf file to extend that further to be rc_conf_files="/etc/rc.conf /etc/rc.conf.local /etc/myotherlocalrc.conf /etc/andanotherrc.conf" 16:40:22 yes 16:40:36 up to enough times 16:40:41 ketas: this is the sort of thing you should explain in a commit message, fwiw 16:41:05 yeah probably 16:41:12 there's review for when this was added too 16:41:13 That's actually the answer to my question. In case it is redefined. But then I ask... What should the behavior be if someone redefines it as rc_conf_files="/etc/onlythisfileplease.conf" ?? 16:41:16 and vendor.conf 16:41:25 put them there as refs? 16:41:34 or just one i mean 16:41:47 unsure how to explain more eh 16:41:59 can always improve 16:42:00 In that case it is too late to source onlythisfileplease.conf because it has already sourced the other files. Kind'a a weird case. 16:42:38 unsure what happens then 16:42:51 you can't undo it eh :p 16:42:54 or i mean 16:43:04 I am sure that the redefine that removes previously defined files is ignored. Because they are already sourced by that time. 16:43:05 in the end you can break init 16:43:50 well lets see 16:44:18 only that file gets loaded? 16:44:27 and then, unsure 16:44:36 anyway 16:45:08 It's keeping track of files that are already sourced in $sourced_files and only sources files that are not listed there. But by the time it is redefined the previous files have already been sourced. 16:45:31 the original code doubling has better explanation in it 16:45:54 i could search it up and add as reference 16:46:10 somewhere 16:46:23 some 2017 or when it was eh 16:46:52 so what do you propose? 16:46:59 it can't unload them 16:47:00 Yes. Now that I understand what it is doing the comment "# Re-do process to pick up [possibly] redefined $rc_conf_files" makes sense to me now. I should have noticed it as the clue I needed to know that but it slipped by me anyway. 16:47:51 it could load defaults again but 16:48:44 Honestly I think I don't like the feature at all, even in the original one time case, because it adds a level of complexity that I don't think is actually needed. 16:49:22 Does anyone need multiple levels of /redefining/ the list of rc.conf files? There are already three locations available. 16:50:23 maybe 16:50:27 I try to avoid being too parochial and avoid saying that because I don't have a use that others won't have a use. But it seems that three locations is already many. 16:50:40 could use vendor.conf and rc.conf 16:51:01 And also rc.conf.local 16:51:16 https://reviews.freebsd.org/D13946 16:51:32 hmm wrong one but 16:51:44 even more exotic things 16:51:58 The new code would help me if it had a comment that hinted that the local admin might redefine rc_conf_files in each of the new rc_conf_files up to the 25 loop count limit times. 16:52:55 Being difficult to describe in a comment is a clue that the feature is subtle and has subtle interactions. 16:54:13 The description mentions "...new loop that runs as long as needed or 25 times..." but it does not define what "needed" means there. 16:55:34 that was supposed to mean until files stop appearing 16:55:38 :p 16:56:10 But files are not "appearing". That is why I was asking, how was this working? Because I assumed some network mount or something where files were being created asynchronously or something! 16:56:18 the original periodic issue is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283427 16:56:52 I have to wait for it to make sure I am not a bot, nice anime image, ... ah, there it is... 16:57:16 on some page that waifu took 82s 16:57:28 unsure what they did there 16:58:36 It's anti-abuse mitigation due to the endless AI scrapers that are taking down every web site. It's the new normal. The AI scrapers and ddos'ers are why we can't have nice things. 16:59:20 the 82s tho 16:59:37 Thanks for the previous bug references. It is the top of the hour and I must run to a meeting now. I have exhausted my free time to look at this right now. Gotta run! 16:59:50 maybe those beagleboard hw design files are extra precious 17:00:20 i can't find the original which added that 17:01:42 https://reviews.freebsd.org/D15689 17:01:47 that's not it either 17:01:49 :p 17:02:17 https://www.youtube.com/live/UB4xpQ5ad0Q 17:02:20 Fall 2025 FreeBSD Vendor Summit - Day 1 17:07:03 funnily in the phabricator and bugzilla there are not (yet) used and declined changes too, which sometimes give new good ideas 17:09:14 https://cgit.freebsd.org/src/commit/?id=a8cb567afbd92fb4db0256a0a10b6ceb6686c4ef 17:09:26 that's the commit part of it 17:09:43 maybe it just was that 17:10:26 oh yes 17:10:28 Add comment to explain functionality of code 17:10:53 in next commit 17:10:54 anyway 17:57:13 i don't know what real answer is 17:57:27 if it's not slower, it's fine i guess 18:00:21 i don't know what loops or test -r cost 18:00:50 the less the better :] 18:01:00 ) 18:01:20 ketas: aren't you tuned to the Vendor Summit yet ? 18:01:37 no 18:03:16 now i looked 18:03:27 it's a break now 18:04:30 yeah 18:04:44 had to confirm location and tz 18:05:07 it's a morning on the other side of planet 18:08:14 why is it round 18:08:17 why it's a ball 18:08:51 nah i closed that 18:09:28 i haven't watched or visited any fbsd even yet eh 18:15:03 perhaps you have to give it a try 18:15:57 Panel: Emerging Security Trends and Their Impact on FreeBSD 18:16:09 this tho...! 19:36:59 an AI generated panel? 21:36:33 LLMs discussing