00:00:04 ok i don't want to though 00:00:14 unless my opinion can be "fixed fucking urwid already" 00:00:20 that's not really your problem though 00:01:10 that would be best communicated through different channels 00:02:00 I don't know whether there is a hard rule/guideline but can you change b/audio/py-sublime-music/files/patch-sublime__music_ui_util.py to be a non-git diff? those are a PITA to maintain AFAIK 00:02:18 ok see 00:02:39 what i want to say is: yes, but, not right now, i'm working on something else, can you please comment on the bug and assign it to me to do that? 00:02:52 but you can't do that because triage won't allow any bug to be assigned to me 00:03:04 so, idk 00:03:16 yes, i can do that... but i'm working on postgres-exporter so not right now 00:03:21 yeah, I'll check with someone more knowledgable first before I'll comment on the PR tho. I once had a shit show of a day because of that type of patch but that might have just been PEBKAC 00:03:37 PR is not assigned to me so technically idc :D 00:03:56 i find this policy ridiculous tbh 00:04:04 me too - hence I was not being serious 00:04:08 I try to improve that situation but... 00:04:11 people be people 00:04:37 jbo: i want to ask linimon about this because it's not the first time this has come up 00:04:47 I also love how some maintainer(s) can not provide maintainer-feedback or maintainer-approval on PRs regarding their ports but submitting new ports in the meantime... 00:04:48 i don't see why, as a maintainer, a bug can't be assigned to me 00:05:10 lw, idk - I had honestly no idea until it was clarified when I did it incorrectly. 00:05:35 I guess it might be to prevent re-assignment wars 00:06:16 if i mail linimon i'll cc you... in the mean time can you please leave a comment on the sublime port and hopefully i'll notice it next time i check 'my bugs'? 00:07:04 I will - after I made sure that what I'm asking for is not incorrect. 00:07:53 jbo: btw commit this https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277017 00:07:56 Title: 277017 – multimedia/libmpeg2: set LICENSE to GPLv2+ 00:08:14 no LICENSE_FILE? 00:09:11 ah it does have COPYING... should that be listed as well as LICENSE? 00:09:20 > When the software provides the license file, use this: 00:09:25 LICENSE= LGPL21+ 00:09:26 LICENSE_FILE= ${WRKSRC}/COPYING 00:09:30 https://docs.freebsd.org/en/books/porters-handbook/book/#licenses-license 00:09:31 Title: FreeBSD Porter's Handbook | FreeBSD Documentation Portal 00:10:05 and now we get to play the game of: do you also need to bump PORTREVISION? :> 00:10:16 (yes, you do, as far as I know) 00:10:23 ... i can't possibly imagine this required a revision bump 00:10:28 the port is literally identical 00:11:29 this will result in a package that is different from the previous one -> bump 00:11:45 hmm 00:12:01 i mean, i can bump PORTREVISION but this will make all poudriere users sad 00:12:21 I don't make the rules 00:12:23 i guess it does technically change the package 00:12:28 https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-portrevision 00:12:30 Title: FreeBSD Porter's Handbook | FreeBSD Documentation Portal 00:12:32 not only technically 00:12:49 I guess if I would want to I could argue why I'm going to commit this without a revision bump 00:13:03 but LICENSE_FILE and that discussion is why I didn't pick up the PR 00:13:36 jbo: new patch on the bug 00:13:40 you ask all of the current committers for a yes/no on whether to bump and you get four different answers along yes and no 00:14:52 oh, this has very few consumers 00:15:08 so probably not even worth discussion the bump 00:15:17 yeah, i can't even remember what i built that uses it but DEVELOPER=yes flagged it 00:15:21 might have been medlaelch? 00:16:15 hmmm 00:16:26 this is assigned already tho 00:16:33 nah it's not 00:16:39 multimedia@ is a fake user 00:16:39 yes it is 00:16:43 ... 00:16:49 is chromium@ also fake? python@? desktop@? 00:16:55 yes 00:17:05 anyone can commit a patch assigned to python@ or desktop@ 00:17:12 unless an actual maintainer picks it up 00:17:12 I'm secretly a group 00:17:55 I'm going to ask about the bump first 00:17:58 so not going to happen tonight 00:17:59 ok 00:18:01 heading home o/ 00:18:10 wait don't go i might have other bugs 00:18:25 jbo: fix this pls https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277266 00:18:27 Title: 277266 – Norelsys NS1081 card reader won't attach 00:18:31 dude, it takes me like 10 minutes to get home 00:18:40 oh ok, fix that in 10 minutes then 00:18:47 and don't call me dude, dude 00:18:59 that is src/, Sir 00:19:22 at least provide a patch :p 00:19:22 oh you have some sort of objection to src, huh? huh?? 00:19:36 o/ 00:19:44 (that is a ttyl, not an agree) 00:19:57 goodbye jbo the src hater 00:37:08 lw: what does DEVELOPER=yes do exactly? 00:37:14 just show some extra debug info? 00:40:08 johnjaye: yes, it enables some extra checks that ports maintainers might be interested in 00:47:35 jbo: heh i'm not the only one getting nitpicked https://reviews.freebsd.org/D44051 00:47:36 Title: ⚙ D44051 snd_uaudio(4): Fix sample rate selection after 42fdcd9fd917. 00:58:09 jbo: new postgres-exporter patch up 01:19:42 hello 01:25:19 Do builds in /usr/ports use the '-j' option to make by default or is that something that has to be explicitly stated ? 01:28:12 enabled by default, individual ports can disable it with MAKE_JOBS_UNSAFE 01:29:28 istr the ports framework itself isn't really -j safe, if you want to influence it you need to specify MAKE_JOBS_NUMBER 01:32:03 don't understand what i'm doing wrong here: missing dependencies? they're clearly right there in the Makefile https://www.le-fay.org/tmp/30d/qVGeHI.txt 01:33:17 lw, nah 01:33:30 nah what? 01:33:40 kevans: thanks for the information. I may have slowed down my build by doing a 'sudo make -j 6' if its enabled by default. 01:33:45 nah ALL the things! 01:34:04 kevans: I'll look at the documentation for MAKE_JOBS_UNSAFE and MAKE_JOBS_NUMBER 01:34:31 jbo: i am literally two minutes away from just closing the sublime pr 01:35:53 lw, huh? why is that? 01:36:55 is imake used by anything? the porter's handbook lists it as a make program 01:37:43 jbo: because python packaging is clearly just... fucked 01:37:51 to say the least 01:38:10 johnjaye: imake used to be commonly used by X applications, nowadays, it's probably quite uncommon to encounter it 01:38:38 lw, no way - really? 01:38:40 the last time I tried to package a python thing (6 years ago at this point?), I gave up because it was constant whack-a-mole and the only viable solution would've been to just package a whole ass venv 01:39:38 there are reasons I tend to stay away from python stuff :D 01:39:41 jbo: you tell me, here i was thinking i'd just update this random port i maintain (it's a dependency of sublime-music) and what even is going on? https://lists.freebsd.org/archives/freebsd-python/2024-February/005689.html 01:39:42 Title: PEP517 - can't build port 01:40:00 even once you get it figured out, if you're unfortunate enough to have a dependency on another python port not maintained by you then you get either constant build breakage (likely less so today) or constant runtime breakage 01:40:31 kevans, yeah, and it's only _partly_ the freebsd's ports fault 01:40:55 yeah 01:41:17 python is just cancerous 01:41:21 I'm just saying, rust may be doing this shit right with just vendoring everything in or whatnot; only leaf ports (or was that golang?) 01:41:24 and so are many of the new "solutions" 01:41:29 kevans: and it takes 2 months to commit a trivial patch to add BROKEN= to a port because no one dares touch *any* python port 01:41:32 not saying that everything else is great & gold 01:42:12 python, go, rust... all of that was supposed to solve the problems that "other languages" have. but they introduce 7 new problems that didn't exist before and most people just pretend those problems don't exist because all that _they_ do is write one single script 01:42:44 (that is: our porters' policies re: rust and golang, rather than the languages themself; though I suppose these policies are based on what they're doing in reality) 01:43:52 i know jbo has heard this rant before but... i wanted to play Factorio this evening and instead i'm sending multiple email messages and messing about with all kinds of this to do what should be a trivial update, this just makes me not want to submit any more ports in future 01:43:54 lw 01:43:55 ERROR Missing dependencies: 01:43:55 setuptools~=65.6 01:44:01 py-setuptools Python packages installer 01:44:01 63.1.0_1 01:44:03 ... 01:44:20 jbo: ? 01:44:33 lw, that is the wrong takeaway. it should make you want to not use python stuff instead. 01:44:39 the problem here is mostly python, not ports 01:45:14 jbo: well someone is responsible for this mess right? with python? 01:45:46 xfce worke now with slim 01:45:48 :) 01:45:48 jbo: like why the fuck is urwid still broken. that's not the fault of "python", there's been a patch for it since *December* 01:46:23 warsoul, slim has been abandoned since 2013 01:46:57 lw, indirection problems: touching anything python makes stuff break because the way that python works (and partly the ports system). so anything not related to python's issues is therefore also becoming a python issue. 01:47:19 jbo: ok i see what you mean, my port requires setuptools 65.6, we only have 63.1 01:47:34 so as port maintainer i will just... ignore this update and do nothing about it... ok, cool. 01:47:36 lw, anyway, your problem is (I think) that upstream needs setuptools 65.6 and we have 63.1 in ports 01:48:14 the proper thing to do is to update py-setuptools - and then test all the consumers because anytime something python changes other python stuff breaks 01:48:19 it's... f 01:48:34 maybe now you get why I told you I generally don't touch anything python :D 01:48:53 of course setuptools 65.6.0 was release in November *2022* 01:48:58 lw, also >=3.11 01:48:59 :D 01:49:04 omg... 01:49:06 and we still don't have it because... reasons? i guess? 01:49:07 is there a PR for it? 01:49:16 I don't talk for python@ - they seem pretty busy 01:49:18 who the fuck knows, i give up 01:49:51 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270358 01:49:53 Title: 270358 – devel/py-setuptools: update to 69.0.3 01:49:55 why can't anyone update what's probably the most important of all python packages for 3 years? 01:49:55 lw ^ 01:50:31 what is the problem with python? 01:50:58 vishwin, is a much better person to talk to about python stuff than I am 01:51:05 I'm just the new guy trying to stay away from python 01:51:39 > The exp-run showing no build failures is a mere coincidence. 01:51:40 :D 01:52:10 is it like the requirements are too strict so nothing can be built? 01:53:52 lw, chime in on the PR... 01:56:15 Can somebody help me boot FreeBSD/riscv64 in qemu? I use this qemu command https://www.cons.org/riscv/run-run but it never enters u-boot: https://www.cons.org/riscv/log 01:56:57 i gave up figuring out how qemu works. so i just use libvirt now 01:57:34 I pass qemu args directly when I use libvirt :-) 01:57:42 jbo: what PR? 01:57:45 well. you know more than me then 01:58:07 It's not a good think that I have to do that. 01:58:07 lw, 270358 01:58:24 VimDiesel: bug 270358 01:58:25 270358 – devel/py-setuptools: update to 69.0.3 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270358 01:58:53 jbo: ugh why? what do you want me to say? 01:58:57 moin cracauer :) 01:59:06 Hello. 01:59:24 i can't even get a fucking 1-line patch committed, why would i wade into this shit 01:59:45 Just some evening virtualization going on here. 01:59:53 do you want to improve the situation & help or just be grumpy and make yet another ethernal starter base? 02:00:30 i do not care about "improving the situation" that has meant we cannot update setuptools since 2022. sorry. 02:00:56 i will just not update my port, i only maintain it because sublime-music requires it, and sublime works fine with the current version 02:01:06 you cannot guilt trip me into fixing political nonsense with python ports 02:01:44 however, i did send a passive aggress mail to python@ about this, so there's that. 02:03:16 jbo: next time you explain to me how few ports committers there are, maybe consider that this nonsense might be the reason 02:03:53 lw, I start to doubt whether you're personally mad at me right now 02:04:15 i am not at all mad at you 02:04:19 going to try light dm now 02:04:24 that a see slim worked 02:04:56 cracauer: #bsdmips on efnet may be able to offer some insight 02:05:07 jbo: however i am a little bit mad beceause i spend 6+ hours today doing testport + runtime testing on a new port and yet i can't get a single 1-line fucking patch committed for two months? 02:05:10 not sure if any of our riscv-y folks are around right now, though 02:05:19 again i appreciate this is not your fault and i'm not mad at you 02:05:25 Uh, this day just gets worse. One of my my systems just exploded during a freebsd-update upgrade from 12.4 to 13.2: http://venus.morante.net/downloads/unibia/screenshots/freebsd/superblock-error-202402252044.jpg. 02:05:30 but you can understand why this is frustrating, right? 02:05:56 lw, I am sorry to hear that. I assure you that I went back to the office only with the intention to make sure that once you completed your chores I would be able to commit immediately to show that things can also run smoothly (at least where I can help). I'd much rather not have spend my sunday night at the office either :D 02:06:18 tuaris: i think it's trying to say it's angry 02:06:33 filesystem needs to learn to express itself better 02:06:52 jbo: i really appreciate your help with committing my ports patches and i'm 100% certain that without your help i'm be sitting here with absolutely no movement on those patches at all 02:07:08 jbo: i do not expect you to single-handedly fix the ports python ecosystem 02:07:47 lw, as for 277017 I _could_ commit that but I'd really like to talk to some more experienced committers first. then we can tick that one too 02:07:53 but frankly i'm on the verge of asking you to commit a merge that removes my maintainership from all my ports 02:08:18 lw, and yeah... with python... it's probably outside of my capabilities to fix that situation. I'm sure vishwin can shed some light on this. 02:08:34 lw, now now, hang in there. 02:08:58 lw, first you're gonna talk to gerald@ about wine-devel takeover ;) 02:09:00 lw, and 9.3 02:09:09 much less hassle than python@ 02:09:17 wow 02:09:19 finally 02:09:20 lol 02:09:24 worked :) 02:09:28 why should i bother updating wine-devel to 9.3, whoever even cares? let's just package whatever was current in 2022, that's how ports rolls apparently 02:09:39 lw, ... 02:09:43 ... 02:09:48 ... 02:09:51 lw, it's not python :o) 02:09:51 wow, libmpeg2's annoying 02:09:55 lw, I care, many other's do 02:10:08 ok yes i am being a bit angry here 02:10:11 but like 02:10:22 Going to take a copy of the VM, and try to see if I can recover it. Otherwise, I might as well retire this old i386 system and rebuild from backups 02:10:27 go have another one of your "sticks", grab a glass of vodka and relax :) 02:10:45 jbo: libmpeg2 one is fine, but still a little shy of maintainer timeout (uness you're on multimedia@?) 02:10:52 today i spent 6+ hour testing wine-devel 9.2 to make sure it works... and that's fine, i understand this is a port a lot of people use, i'm happy to put the work in to make sure it's alright 02:10:59 ((is multimedia@ even alive?)) 02:11:28 and yet we can't update py-setuptools, one of the most important and fundamental python packages, since fucking 2022? 02:11:30 kevans, no idea. would have certainly waited for the timeout. But given that it's not an "intrusive" change I wouldn't mind doing it exactly after 14 days tbh. 02:11:41 kevans, my main question is/was regarding PORTREVISION bump. IMHO the bump is necessary. 02:11:42 why should i put effort into this shit when it's obvious no one else is? 02:11:45 yes, it is 02:11:51 kevans, thanks for confirming! 02:12:01 lw, look at the commit history and think again 02:12:12 commit history of what? 02:12:15 ports 02:12:17 the license is encoded in the pkg metadata, so without the bump they won't pick up the license actually being specified (which is admittedly maybe low impact, but probably not 'no impact') 02:12:17 lots of people care 02:12:32 jbo: you're deflecting 02:12:33 'they' being end-users 02:12:39 of course plenty of people commit to ports 02:12:40 kevans, that was exaclty my line of thinking. hence I asked lw to add the bump. thank you for confirming! 02:12:56 obviously none of those people maintain ports that need a current version of setuptools though 02:15:03 jbo, kevans: does a port "maintained by" multimedia@ need maintainer timeout? i thought these were basically unmaintained 02:15:42 yes 02:15:48 it's a group of people 02:15:50 yes, because there are people actively responsible for reviewing things maintained by the group (https://wiki.freebsd.org/Multimedia) 02:15:53 heh 02:16:18 If the group's not doing that then it may be that they need dissolved, or they just need poked to remind them that they're on the group 02:16:32 maybe i should take maintainer of libmpeg2.... 02:16:46 I wouldn't recommend that 02:17:03 why not? it hasn't had a commit since 2021, project is basically dead 02:17:03 libmpeg2 doesn't have that many dependencies but there's usually good reason why "basic" ports are maintained by groups 02:17:23 those tend to need a bit more coordination 02:17:35 imo groups are very nearly a mistake, but they exist so what we do what we can with what we have 02:17:36 check some latest efforts on libxml2, libexpat, jpeg etc. 02:17:47 we have way more defunct groups than functional groups 02:17:53 not really comparable, libxml2 is used by everything 02:18:13 wow, that came out really badly 02:18:15 kevans, I have not been around long enough to judge that but I don't doubt it either 02:19:08 and in any case, if group maintainership of libmpeg2 is so critical to its existence in ports, why has no one replied to my PR? 02:19:20 kevans, do you have a stick to poke exp-runs? :D 02:19:39 the run itself, or the person that orchestrates exp-runs? :-) 02:19:43 obvious answer: no one actually cares about it, it's just assigned to multimedia@ by defdault 02:19:52 kevans, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276879 02:19:55 Title: 276879 – ftp/curl: Update to 8.6.0 02:20:04 kevans, from what I can tell that is only missing an exp-run and it fixes a CVE so... 02:20:52 oof. 02:20:53 lw, how about taking a breather? (totally not meant in a rude/arrogant/negative way - just seems like you are getting yourself worked up right now) 02:20:57 kevans, exactly :D 02:21:11 it would've been better to split the CVE patch out, if feasible. not sure if curl releases backports like that 02:21:12 i'm not worked up. i think i asked a reasonable question 02:21:41 kevans, backport? it's a minor update, no? 02:22:37 lw, agreed. I will handle it once we have maintainer-timeout and I consulted with my mentors (I am more hesitant when maintainer-timeout occurrs with groups as they might have "reasons", but again, this is a non-intrusive change so we should be good - I just don't have the experience & street-cred to make the call) 02:22:42 in the sense of a patch file that's easier to audit than a dist bump + patch like this 02:23:39 kevans, we'd want the 8.6 update anyway, no? 02:23:52 maybe I'm misunderstanding something fundamental here - sorry 02:24:03 yeah, but there's a question of: is this one you're comfortable MFH'ing, considering it has security contents? 02:24:36 some folks are more conservative than others 02:25:37 kevans, apologies for asking you to be patient with me but: what? it's a port update where upstream updated from 8.5 to 8.6. why would we be "conservative" given that it's a relatively widely used tool with a new upstream release that also addresses a known CVE? 02:25:42 <_xor> Any tips on converting a Linux prctl call to a FreeBSD procctl call? 02:26:15 kevans, oooh... you're referring to PATCHFILES=e75a48d2c32d92b0321fbb09c25885a706077201.patch:-p1 ? 02:26:32 fwiw, it would significantly reduce my frustration level if someone could commit https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276347 02:26:35 Title: 276347 – net-im/toot: mark as BROKEN since devel/py-urwid is broken 02:26:50 jbo: because in general port updates don't get MFH'd by default, we've historically tried not to destabiize quarterly too much so you have to gauge risk to some extent 02:28:25 kevans, merge-quarterly=? is separate from exp-run=? right? we could complete the exp-run, commit to main and address that quesiton separately? it's not like the exp-run for main would replace an exp-run for quarterly. 02:28:31 minor update to me doesn't mean a whole lot, I've seen a boatload of poor uses of semantic versioning 02:28:42 yes 02:29:30 kevans, while I have you here (thank you for bothering to help the newbies out): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276347 02:29:33 Title: 276347 – net-im/toot: mark as BROKEN since devel/py-urwid is broken 02:29:50 is there anything "problematic" that would come with that I should know about? 02:30:06 in python i think they normally say not to even other with the distro packages anyway 02:30:12 just download everything into a venv 02:30:35 * _xor wonders why prctl decided to use unstructured function parameters where the semantics can change depending on argument values 02:30:46 <_xor> This is frustrating heh. 02:30:56 is everybody being frustrated tonight? 02:31:39 jbo: nah, should be fine. I do wonder if a link to the urwid PR in the BROKEN message might be helpful, though I admittedly don't recall at the moment if that's common practice 02:31:48 <_xor> I'm wondering if there's a legit technical reason for prctl to be implemented this way because FreeBSD's version (procctl) makes more sense and is easier to erad 02:31:50 <_xor> *read 02:32:02 kevans, being unclear on the standards/formatting of BROKEN= is my main reason for not having touched this yet :D 02:32:10 kevans, I have seen quite some wild things in BROKEN= 02:32:33 yeah 02:32:45 I think I'd just tack a (PR 274411) at the end and send it 02:33:04 just so that it's very clear from a random observer if the problem's actually fixed or not without having to follow breadcrumbs back to it via PR indirection 02:33:11 s/from/for/ 02:33:21 kevans, may I add a 'Reviewed by: kevans' to cover my newbie ass a little? :D 02:33:24 sure 02:33:29 thank you :) 02:33:45 oh shit 02:33:54 * kevans remembers that he has an e-mail he forgot to respond to 02:34:26 kevans, just to be clear (I am known to be overly cautions): that is irrelvenat to what we just discussed regarding the BROKEN= commit? 02:34:30 jbo: admittedly I never got newlib to work outside of the small segment of arduino ecosystem I was working in 02:34:38 yeah 02:34:53 kevans, oh that... I "forgot" that that was you tbh... still getting to know all the names. 02:35:16 kevans, I did write that e-mail after a long, tiring day so I was wondering whether I was just too noob in my questions. 02:35:41 it wouldn't surprise me to learn that we're missing some important bits, I can prepare an update and try to suss out what's needed if you can test it 02:35:55 I couldn't test an update anymore so I've just kind of let it be 02:36:00 kevans, I'd gladly test it. 02:36:32 kevans, I did also reach out to lev@ to ask for an upgrade (not update) of devel/gcc-arm-embedded but that is a lot more work because upstream changed drastically. 02:37:06 kevans, anyway, I'd very gladly test - just respond to the original e-mail if you feel like it (and when you got there) 02:37:41 <_xor> oh that reminds me, I need to add to devel/xtensa-esp32-elf to my list 02:38:17 jbo: sure thing, thanks. I need a break from what I was doing, so I'll take a look at it now (which means you might see an e-mail in the next two weeks, because I tend to get distracted easily) 02:38:35 <_xor> heh reminds me of a bash quote 02:38:54 kevans :D 02:38:54 <_xor> "What's ADHD? Attention Defic....LET'S GO RIDE BIKES!" 02:38:59 kevans, I appreciate your efforts 02:40:38 _xor: I just feel terrible for my wife, but we've lived together for nearly 10 years now so she's gotten used to putting up with my shit and helps me find ways to not piss her off 02:41:04 < Cue Visa Card advertisement > 02:41:18 <_xor> Getting diagnosed and medicated helped me. It was nuts how different it is now. 02:41:47 * kevans switches over to -social for a minute 02:44:08 kevans, newbie question: any reason why poudriere-testport would still be happy with an added BROKEN= ? 02:45:12 jbo: testport runs with TRYBROKEN=yes, but this sounds like runtime breakage so it wouldn't necessarily be noticed unless there was, e.g., a unit test that tried to exercise it 02:45:32 kevans, ah, the TRYBROKEN=yes is what I lacked in knowledge 02:45:41 kevans, trying to figure out whether having parenthesis in BROKEN= is fine 02:47:06 iirc contents are assumed to never be parsed, so whatever make(1) is OK with 02:47:24 alright, thanks! 02:50:16 lw, committed 02:50:46 kevans, thank you for the hand-holding - much appreciated! 02:51:40 jbo: thanks. 02:52:11 *nod* 02:52:12 02:53:00 holy shit the newlib update 'just worked' for the most part 02:54:00 neat! 02:55:42 can you passthrough block devices, like a hard drive, to a bhyve guest? or jail? 02:55:56 markmcb, jails and passthru is not really a thing 02:56:22 and bhyve can AFAIK only do PCI passthru (for good reasons) 02:56:45 incidently, that means that you can passthru an NVMe drive to a VM :) 02:57:12 whether that is desirable is another question as part of the niceness of VMs is that they need less memory as the FS is handled by the host 02:57:31 i.e. a windows guest can totally work with 2GB of RAM which would be unthinkable on baremetal 02:58:19 jbo: thanks. i passthrough decrypted luks /dev/mapper devices with qemu/kvm in linux, so was just curious 03:01:35 how is bluetooth now in FreeBSD? 03:01:49 relativley good now? 03:02:06 the.best. 03:02:15 (kidding) 03:06:25 I wrote a howto on how I got it to work, having to use hccontrol then virtual_oss stuff then for pairing had to edit the hcsecd.conf 03:06:30 was a pain in the ass 03:07:06 sounds about right to 03:07:12 what was causing the pain? 03:08:42 having to manually do it each time and then once I ran hccontrol -n ubt0hci create_connection 'device' I had to quickly run virtual_oss -C 2 -c 2 -r 48000 -b 16 -s 768 -R /dev/null -P /dev/bluetooth/'device' -d dsp 03:09:07 and if I didn't get it quick enough it would fail 03:09:08 heh 03:09:19 sounds like something for a script :D 03:09:40 once it was working it was great 03:10:05 lw: tl;dr upstream deprecated a major use method and specifically pinned an older version for said method, two versions cannot be in the same environment concurrently, our RUN_DEPENDS practice is outdated and wrong 03:10:25 to fix it all requires a specific order to minimise breakage and churn 03:13:08 I think it was about 3+ years ago when I was using bluetooth with this 03:26:15 vishwin, what does "specifically pinned an older version of said method" mean? 03:31:08 as in, some consumers will have to use version 58 specifically 03:31:23 uff 03:31:26 some as in USE_PYTHON=distutils 03:31:58 when exactly did it become a think that software packages define _specific_ versions for deps? 03:32:08 "back in my day" it was a "this major version" thing 03:32:23 and both upstream and downstream would at least try to keep all minor versions compatible between each other 03:33:14 then the fire nation attacked and the ecosystem became too available and people suck at versioning and... 03:33:29 accessible, not available 03:34:38 well, 58 is the last version to officially support that method 03:35:06 for setuptools, unfortunately there was no good way to deprecate cruft without breaking stuff 03:35:46 their code is a mess by both history and circumstance and they are trying to correct that considering actual standards exist now 03:39:02 vishwin, what exactly does this mean for freebsd ports specifically? 03:39:42 vishwin, what I'm hearing is that the only valid update for setuptools is to 58 and before the next update marking any upstream as BROKEN= that doesn't support >=58? 03:39:49 or am I overly simplifying here (because not a python guy)? 03:41:33 it will eventually be three setuptools versions in the tree 03:41:53 all USE_PYTHON=distutils consumers get migrated to 58 03:42:02 only after that does mainline setuptools get updated 03:42:33 well, all USE_PYTHON=distutils consumers that use python 3, as setuptools 44 exists for the remaining python 2 ports 03:43:26 https://wiki.freebsd.org/Python/setuptools 03:43:27 Title: Python/setuptools - FreeBSD Wiki 03:45:35 vishwin, thank you for taking the time explaining this here. I think I understand better now (at least definitely compared to what I read in the PR(s)). 03:45:50 vishwin, does this mean that it's currently mostly a python@ man-power issue? 03:58:18 getting python.so perl.so autoload failed on startup hexchat 04:09:03 how i can disable ssl 04:24:33 clang is drunk. I clearly defined `void setupbackground(void);`, then I wrote the whole function, then I use it in the main function, and I get `ld: error: undefined symbol: setupbackground\n>>> referenced by slock.c\n>>> slock.o:(main)`. 04:24:50 maybe 04:25:21 lld's usually not too wrong about that kind of thing 04:26:35 It makes no sense. 04:26:47 hard to say without seeing the specific case 04:27:06 Ah, I think I see the problem. 04:28:07 OK, it turned out the reason was because that function was defined inside of the `ifdef __linux__` clause. 04:28:25 Which is odd, because it did compile on OpenBSD. 04:29:48 The next problem is: `warning: call to undeclared function 'setgroups'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]\n if (setgroups(0, NULL) < 0)` 04:32:41 with included? 04:33:16 connection refused (ssl handshake time out) 04:33:31 how do i disable ssl on freebsd 04:33:45 im remember selecting this option in install by mistake 04:34:00 It's included. 04:35:40 looks like it's probably behind a __BSD_VISIBLE 04:36:06 have one of the _*_SOURCE macros defined? 04:38:24 kevans: `-D_DEFAULT_SOURCE` 04:38:50 hmm, doesn't seem to be one of the ones we care about 04:41:02 https://cgit.freebsd.org/src/tree/sys/sys/cdefs.h#n644 this is about where we start sorting through visibility 04:41:03 Title: cdefs.h « sys « sys - src - FreeBSD source tree 06:03:11 what is the distinction between section 4 and section 9 of the manual? they both say kernel stuff 06:04:05 i guess section 4 is about hardware and /dev? 11:23:49 gm 11:23:57 how do i disable ssl 11:26:03 That question is way too broad to be possible to answer. 11:29:44 i remember selecting this in installation yesterday 11:29:51 now hexchat wont connect 11:30:13 connection refused (ssl handshake time out) 11:30:19 this is what it says 11:43:17 warsoul: change the port for the irc server 13:08:52 Is there a reason that KERNEL_RETPOLINE was never enabled in GENERIC? 13:09:53 https://reviews.freebsd.org/rS330110 13:09:54 Title: rS330110 13:10:11 "In this commit it is disabled by default, but will be changed in a 13:10:14 followup commit." 13:40:50 there is a typo here: https://docs.freebsd.org/en/books/handbook/security/#security-passwords' it says to "grep user /etc/master.passwd" to see the hash mechanism in the user's login class when it should be /etc/login.conf 13:40:51 Title: Chapter 16. Security | FreeBSD Documentation Portal 14:13:32 cedb, open a bug with a suggested edit on bugs.freebsd.org 14:43:55 rafe: the follow-up hasn't happened yet, it's possible it was just forgotten about - you could just follow-up on the follow-up ;) 14:49:22 Although with e5c6dece988, I think it's enabled conditionally. 14:50:00 ah, 2a5ba072014 enables it outright 14:52:13 the first you mentioned is userland, no? 14:52:22 and I don't see that second hash 14:56:27 That's because it's an MFC of something that was done before the switch to git ;) 14:56:33 https://cgit.freebsd.org/src/commit/?id=2a5ba07 14:56:34 Title: src - FreeBSD source tree 14:59:46 I see, so it's a "default no" but enabled if the compiler supports it 15:19:46 the way i read it, it's enabled conditionally for platforms that aren't amd64, and if the compiler supports it on anything else 15:27:36 it defaults to no on all platform, and is marked as broken on amd64 15:28:26 (wich is kinda weird tbh) 15:28:35 shouldn't it be the opposite ? 15:32:20 I ain't got no clue. 15:36:08 I found some code in the makefiles that said We will remove this in Freebsd 12. 15:36:16 Maybe there's a lot of that stuff? 15:36:57 deprecate ALL the things 15:38:14 There was a bunch of deprecations a few days ago. 15:51:39 babz, that's not how I read kern.opts.mk.if NOT i386 and NOT amd64, set as broken 15:53:41 oh you're right 15:54:05 i was reading the phabricator link above 15:54:57 this one makes much more sense 19:23:49 lw, ping 19:24:36 jbo: is this a particularly busy time of the year for ports? 19:24:48 normally the channel isn't this active! 19:24:51 I am curious how do people here feel about Gentoo, in terms of being a ports like system and OS that paid some attention to the way FreeBSD values things. 19:25:07 johnjaye, this channel has no direct relation to/with ports 19:25:43 right, i meant it might be some spillover from something like a new release or new stable or something. 19:25:54 nah 19:25:57 i thought you said something like you have 1000 entries on buzgilla now to look over. 19:26:11 you must be mistaking me for somebody else 19:26:44 well maybe! 19:28:29 how dare you! 20:30:59 hi, i'm having trouble with usb permissions 20:31:25 namely, the old i can make it work if i do things as root but i cannot figure out how to give a user the required permissions 20:37:00 pirate, depends on the circumstances. sometimes the operator group is sufficient. but without more details your guess is as good as ours. 20:42:28 jbo: i tried adding the user to the operator group 20:43:36 pirate: but what are you trying to do? 20:44:18 well, i have a hid device, usb connected relays 20:44:34 and i'm trying to control them via python script 20:44:49 works fine if i run it as root, works fine under linux 20:44:59 sounds like a job for devd 20:45:14 similarly, i wanna control a 3d printer with octoprint 20:59:32 What does it mean I have: USES= compiler:c++11-lang ? I don't think I have a compiler called c++11-lang 21:00:00 mns, it tells the ports framework that the port requires a C++ compiler that is C++11 capable. 21:00:16 mns, that does not specify the compiler itself, just the required capability 21:02:52 jbo: thanks. that;s from lang/gcc13/Makefile. I'm trying to use the same compiler, was trying with /usr/bin/cc (clang 14), but that failed, whereas buildign with gcc12 seems to work. 21:03:53 mns, if the port requires GCC, there is USE_GCC= 21:04:37 mns, note that I assume that you know what you're doing. typically, ports are compiled with llvm so potential deps might have a different ABI 21:05:36 "typically" is the key word here. the ports framework provides a lot of infrastructrue to allow different compilers etc. 21:15:53 https://bugs.kde.org/show_bug.cgi?id=481874 21:15:55 Title: 481874 – Add arm64 support for FreeBSD 21:33:14 jbo: tbh, i'm not seeing how devd does permissions 21:36:50 i added the user to both operator and dialout, still permissions failure 21:54:58 jbo: thanks. I'm trying to help with https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274939 so trying to compare between just downloading the source from gnu.org and building it (which works), and how ports builds it. I realised I had /usrlocal/gnat12/bin in my path (for Ada) and wanted to use the same compiler as what is being used by lang/gcc13. 21:55:00 Title: 274939 – Feature request: enable the m2 (modula2) front end in lang/gcc13 22:20:06 pirate, you typically setup a devd rule which sets the permissions on ATTACH 22:20:25 mns, nice - thanks for helping! 22:26:47 jbo: trying to, not sure I am yet. Benchmark of just doing lang/gcc13 as is, takes about 9 hours on my system, so hard to be productive 22:27:06 mns, are you building through poudriere? 22:27:51 mns, strongly recommend to use ccache 22:28:09 jbo: no, just 'cd /usr/ports/lang/gcc13 ; sudo MAKE_JOB_NUMMBER=6 make' 22:28:19 yeah definitely use ccache :D 22:28:29 that way you don't re-build the same thing over and over 22:28:57 I'll have to look into setting that up, unless you have some pointers 23:24:17 jbo: is there an example i can see somewhere? 23:30:55 pirate, man devd.conf(5) has at least one USB matching example AFAIK