ok i don't want to though

unless my opinion can be "fixed fucking urwid already"

that's not really your problem though

that would be best communicated through different channels

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

ok see

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?

but you can't do that because triage won't allow any bug to be assigned to me

so, idk

yes, i can do that... but i'm working on postgres-exporter so not right now

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

PR is not assigned to me so technically idc :D

i find this policy ridiculous tbh

me too - hence I was not being serious

I try to improve that situation but...

people be people

jbo: i want to ask linimon about this because it's not the first time this has come up

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...

i don't see why, as a maintainer, a bug can't be assigned to me

lw, idk - I had honestly no idea until it was clarified when I did it incorrectly.

I guess it might be to prevent re-assignment wars

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'?

I will - after I made sure that what I'm asking for is not incorrect.

jbo: btw commit this bugs.freebsd.org/bugzilla/show_bug.cgi?id=277017

Title: 277017 – multimedia/libmpeg2: set LICENSE to GPLv2+

no LICENSE_FILE?

ah it does have COPYING... should that be listed as well as LICENSE?

> When the software provides the license file, use this:

LICENSE= LGPL21+

LICENSE_FILE= ${WRKSRC}/COPYING

Title: FreeBSD Porter's Handbook | FreeBSD Documentation Portal

and now we get to play the game of: do you also need to bump PORTREVISION? :>

(yes, you do, as far as I know)

... i can't possibly imagine this required a revision bump

the port is literally identical

this will result in a package that is different from the previous one -> bump

hmm

i mean, i can bump PORTREVISION but this will make all poudriere users sad

I don't make the rules

i guess it does technically change the package

Title: FreeBSD Porter's Handbook | FreeBSD Documentation Portal

not only technically

I guess if I would want to I could argue why I'm going to commit this without a revision bump

but LICENSE_FILE and that discussion is why I didn't pick up the PR

jbo: new patch on the bug

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

oh, this has very few consumers

so probably not even worth discussion the bump

yeah, i can't even remember what i built that uses it but DEVELOPER=yes flagged it

might have been medlaelch?

hmmm

this is assigned already tho

nah it's not

multimedia@ is a fake user

yes it is

...

is chromium@ also fake? python@? desktop@?

yes

anyone can commit a patch assigned to python@ or desktop@

unless an actual maintainer picks it up

<jbo> I'm secretly a group

I'm going to ask about the bump first

so not going to happen tonight

ok

heading home o/

wait don't go i might have other bugs

jbo: fix this pls bugs.freebsd.org/bugzilla/show_bug.cgi?id=277266

Title: 277266 – Norelsys NS1081 card reader won't attach

dude, it takes me like 10 minutes to get home

oh ok, fix that in 10 minutes then

and don't call me dude, dude

that is src/, Sir

at least provide a patch :p

oh you have some sort of objection to src, huh? huh??

o/

(that is a ttyl, not an agree)

goodbye jbo the src hater

lw: what does DEVELOPER=yes do exactly?

just show some extra debug info?

johnjaye: yes, it enables some extra checks that ports maintainers might be interested in

jbo: heh i'm not the only one getting nitpicked reviews.freebsd.org/D44051

Title: ⚙ D44051 snd_uaudio(4): Fix sample rate selection after 42fdcd9fd917.

jbo: new postgres-exporter patch up

hello

Do builds in /usr/ports use the '-j' option to make by default or is that something that has to be explicitly stated ?

enabled by default, individual ports can disable it with MAKE_JOBS_UNSAFE

istr the ports framework itself isn't really -j safe, if you want to influence it you need to specify MAKE_JOBS_NUMBER

don't understand what i'm doing wrong here: missing dependencies? they're clearly right there in the Makefile le-fay.org/tmp/30d/qVGeHI.txt

lw, nah

nah what?

kevans: thanks for the information. I may have slowed down my build by doing a 'sudo make -j 6' if its enabled by default.

nah ALL the things!

kevans: I'll look at the documentation for MAKE_JOBS_UNSAFE and MAKE_JOBS_NUMBER

jbo: i am literally two minutes away from just closing the sublime pr

lw, huh? why is that?

is imake used by anything? the porter's handbook lists it as a make program

jbo: because python packaging is clearly just... fucked

to say the least

johnjaye: imake used to be commonly used by X applications, nowadays, it's probably quite uncommon to encounter it

lw, no way - really?

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

there are reasons I tend to stay away from python stuff :D

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? lists.freebsd.org/archives/freebsd-python/2024-February/005689.html

Title: PEP517 - can't build port

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

kevans, yeah, and it's only _partly_ the freebsd's ports fault

yeah

python is just cancerous

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?)

and so are many of the new "solutions"

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

not saying that everything else is great & gold

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

(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)

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

lw

ERROR Missing dependencies:

setuptools~=65.6

py-setuptools Python packages installer

63.1.0_1

...

jbo: ?

lw, that is the wrong takeaway. it should make you want to not use python stuff instead.

the problem here is mostly python, not ports

jbo: well someone is responsible for this mess right? with python?

xfce worke now with slim

:)

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*

warsoul, slim has been abandoned since 2013

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.

jbo: ok i see what you mean, my port requires setuptools 65.6, we only have 63.1

so as port maintainer i will just... ignore this update and do nothing about it... ok, cool.

lw, anyway, your problem is (I think) that upstream needs setuptools 65.6 and we have 63.1 in ports

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

it's... f

maybe now you get why I told you I generally don't touch anything python :D

of course setuptools 65.6.0 was release in November *2022*

lw, also >=3.11

:D

omg...

and we still don't have it because... reasons? i guess?

is there a PR for it?

I don't talk for python@ - they seem pretty busy

who the fuck knows, i give up

Title: 270358 – devel/py-setuptools: update to 69.0.3

why can't anyone update what's probably the most important of all python packages for 3 years?

lw ^

what is the problem with python?

vishwin, is a much better person to talk to about python stuff than I am

I'm just the new guy trying to stay away from python

> The exp-run showing no build failures is a mere coincidence.

:D

is it like the requirements are too strict so nothing can be built?

lw, chime in on the PR...

Can somebody help me boot FreeBSD/riscv64 in qemu? I use this qemu command cons.org/riscv/run-run but it never enters u-boot: cons.org/riscv/log

i gave up figuring out how qemu works. so i just use libvirt now

I pass qemu args directly when I use libvirt :-)

jbo: what PR?

well. you know more than me then

It's not a good think that I have to do that.

lw, 270358

VimDiesel: bug 270358

270358 – devel/py-setuptools: update to 69.0.3 bugs.freebsd.org/bugzilla/show_bug.cgi?id=270358

jbo: ugh why? what do you want me to say?

moin cracauer :)

Hello.

i can't even get a fucking 1-line patch committed, why would i wade into this shit

Just some evening virtualization going on here.

do you want to improve the situation & help or just be grumpy and make yet another ethernal starter base?

i do not care about "improving the situation" that has meant we cannot update setuptools since 2022. sorry.

i will just not update my port, i only maintain it because sublime-music requires it, and sublime works fine with the current version

you cannot guilt trip me into fixing political nonsense with python ports

however, i did send a passive aggress mail to python@ about this, so there's that.

jbo: next time you explain to me how few ports committers there are, maybe consider that this nonsense might be the reason

lw, I start to doubt whether you're personally mad at me right now

i am not at all mad at you

going to try light dm now

that a see slim worked

cracauer: #bsdmips on efnet may be able to offer some insight

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?

not sure if any of our riscv-y folks are around right now, though

again i appreciate this is not your fault and i'm not mad at you

Uh, this day just gets worse. One of my my systems just exploded during a freebsd-update upgrade from 12.4 to 13.2: venus.morante.net/downloads/unibia/…d/superblock-error-202402252044.jpg.

but you can understand why this is frustrating, right?

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

tuaris: i think it's trying to say it's angry

filesystem needs to learn to express itself better

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

jbo: i do not expect you to single-handedly fix the ports python ecosystem

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

but frankly i'm on the verge of asking you to commit a merge that removes my maintainership from all my ports

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.

lw, now now, hang in there.

lw, first you're gonna talk to gerald@ about wine-devel takeover ;)

lw, and 9.3

much less hassle than python@

wow

finally

lol

worked :)

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

lw, ...

...

...

lw, it's not python :o)

wow, libmpeg2's annoying

lw, I care, many other's do

ok yes i am being a bit angry here

but like

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

go have another one of your "sticks", grab a glass of vodka and relax :)

jbo: libmpeg2 one is fine, but still a little shy of maintainer timeout (uness you're on multimedia@?)

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

((is multimedia@ even alive?))

and yet we can't update py-setuptools, one of the most important and fundamental python packages, since fucking 2022?

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.

kevans, my main question is/was regarding PORTREVISION bump. IMHO the bump is necessary.

why should i put effort into this shit when it's obvious no one else is?

yes, it is

kevans, thanks for confirming!

lw, look at the commit history and think again

commit history of what?

ports

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')

lots of people care

jbo: you're deflecting

'they' being end-users

of course plenty of people commit to ports

kevans, that was exaclty my line of thinking. hence I asked lw to add the bump. thank you for confirming!

obviously none of those people maintain ports that need a current version of setuptools though

jbo, kevans: does a port "maintained by" multimedia@ need maintainer timeout? i thought these were basically unmaintained

yes

it's a group of people

yes, because there are people actively responsible for reviewing things maintained by the group (wiki.freebsd.org/Multimedia)

heh

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

maybe i should take maintainer of libmpeg2....

I wouldn't recommend that

why not? it hasn't had a commit since 2021, project is basically dead

libmpeg2 doesn't have that many dependencies but there's usually good reason why "basic" ports are maintained by groups

those tend to need a bit more coordination

imo groups are very nearly a mistake, but they exist so what we do what we can with what we have

check some latest efforts on libxml2, libexpat, jpeg etc.

we have way more defunct groups than functional groups

not really comparable, libxml2 is used by everything

wow, that came out really badly

kevans, I have not been around long enough to judge that but I don't doubt it either

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?

kevans, do you have a stick to poke exp-runs? :D

the run itself, or the person that orchestrates exp-runs? :-)

obvious answer: no one actually cares about it, it's just assigned to multimedia@ by defdault

kevans, bugs.freebsd.org/bugzilla/show_bug.cgi?id=276879

Title: 276879 – ftp/curl: Update to 8.6.0

kevans, from what I can tell that is only missing an exp-run and it fixes a CVE so...

oof.

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)

kevans, exactly :D

it would've been better to split the CVE patch out, if feasible. not sure if curl releases backports like that

i'm not worked up. i think i asked a reasonable question

kevans, backport? it's a minor update, no?

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)

in the sense of a patch file that's easier to audit than a dist bump + patch like this

kevans, we'd want the 8.6 update anyway, no?

maybe I'm misunderstanding something fundamental here - sorry

yeah, but there's a question of: is this one you're comfortable MFH'ing, considering it has security contents?

some folks are more conservative than others

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?

Any tips on converting a Linux prctl call to a FreeBSD procctl call?

kevans, oooh... you're referring to PATCHFILES=e75a48d2c32d92b0321fbb09c25885a706077201.patch:-p1 ?

fwiw, it would significantly reduce my frustration level if someone could commit bugs.freebsd.org/bugzilla/show_bug.cgi?id=276347

Title: 276347 – net-im/toot: mark as BROKEN since devel/py-urwid is broken

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

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.

minor update to me doesn't mean a whole lot, I've seen a boatload of poor uses of semantic versioning

yes

kevans, while I have you here (thank you for bothering to help the newbies out): bugs.freebsd.org/bugzilla/show_bug.cgi?id=276347

Title: 276347 – net-im/toot: mark as BROKEN since devel/py-urwid is broken

is there anything "problematic" that would come with that I should know about?

in python i think they normally say not to even other with the distro packages anyway

just download everything into a venv

This is frustrating heh.

is everybody being frustrated tonight?

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

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

*read

kevans, being unclear on the standards/formatting of BROKEN= is my main reason for not having touched this yet :D

kevans, I have seen quite some wild things in BROKEN=

yeah

I think I'd just tack a (PR 274411) at the end and send it

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

s/from/for/

kevans, may I add a 'Reviewed by: kevans' to cover my newbie ass a little? :D

sure

thank you :)

oh shit

kevans, just to be clear (I am known to be overly cautions): that is irrelvenat to what we just discussed regarding the BROKEN= commit?

jbo: admittedly I never got newlib to work outside of the small segment of arduino ecosystem I was working in

yeah

kevans, oh that... I "forgot" that that was you tbh... still getting to know all the names.

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.

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

I couldn't test an update anymore so I've just kind of let it be

kevans, I'd gladly test it.

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.

kevans, anyway, I'd very gladly test - just respond to the original e-mail if you feel like it (and when you got there)

oh that reminds me, I need to add to devel/xtensa-esp32-elf to my list

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)

heh reminds me of a bash quote

kevans :D

"What's ADHD? Attention Defic....LET'S GO RIDE BIKES!"

kevans, I appreciate your efforts

_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

< Cue Visa Card advertisement >

Getting diagnosed and medicated helped me. It was nuts how different it is now.

kevans, newbie question: any reason why poudriere-testport would still be happy with an added BROKEN= ?

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

kevans, ah, the TRYBROKEN=yes is what I lacked in knowledge

kevans, trying to figure out whether having parenthesis in BROKEN= is fine

iirc contents are assumed to never be parsed, so whatever make(1) is OK with

alright, thanks!

lw, committed

kevans, thank you for the hand-holding - much appreciated!

jbo: thanks.

*nod*

<rainbows>

holy shit the newlib update 'just worked' for the most part

neat!

can you passthrough block devices, like a hard drive, to a bhyve guest? or jail?

markmcb, jails and passthru is not really a thing

and bhyve can AFAIK only do PCI passthru (for good reasons)

incidently, that means that you can passthru an NVMe drive to a VM :)

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

i.e. a windows guest can totally work with 2GB of RAM which would be unthinkable on baremetal

jbo: thanks. i passthrough decrypted luks /dev/mapper devices with qemu/kvm in linux, so was just curious

how is bluetooth now in FreeBSD?

relativley good now?

the.best.

(kidding)

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

was a pain in the ass

sounds about right to

what was causing the pain?

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

and if I didn't get it quick enough it would fail

heh

sounds like something for a script :D

once it was working it was great

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

to fix it all requires a specific order to minimise breakage and churn

I think it was about 3+ years ago when I was using bluetooth with this

vishwin, what does "specifically pinned an older version of said method" mean?

as in, some consumers will have to use version 58 specifically

uff

some as in USE_PYTHON=distutils

when exactly did it become a think that software packages define _specific_ versions for deps?

"back in my day" it was a "this major version" thing

and both upstream and downstream would at least try to keep all minor versions compatible between each other

then the fire nation attacked and the ecosystem became too available and people suck at versioning and...

accessible, not available

well, 58 is the last version to officially support that method

for setuptools, unfortunately there was no good way to deprecate cruft without breaking stuff

their code is a mess by both history and circumstance and they are trying to correct that considering actual standards exist now

vishwin, what exactly does this mean for freebsd ports specifically?

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?

or am I overly simplifying here (because not a python guy)?

it will eventually be three setuptools versions in the tree

all USE_PYTHON=distutils consumers get migrated to 58

only after that does mainline setuptools get updated

well, all USE_PYTHON=distutils consumers that use python 3, as setuptools 44 exists for the remaining python 2 ports

Title: Python/setuptools - FreeBSD Wiki

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)).

vishwin, does this mean that it's currently mostly a python@ man-power issue?

getting python.so perl.so autoload failed on startup hexchat

how i can disable ssl

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)`.

maybe

lld's usually not too wrong about that kind of thing

It makes no sense.

hard to say without seeing the specific case

Ah, I think I see the problem.

OK, it turned out the reason was because that function was defined inside of the `ifdef __linux__` clause.

Which is odd, because it did compile on OpenBSD.

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)`

with <unistd.h> included?

connection refused (ssl handshake time out)

how do i disable ssl on freebsd

im remember selecting this option in install by mistake

It's included.

looks like it's probably behind a __BSD_VISIBLE

have one of the _*_SOURCE macros defined?

kevans: `-D_DEFAULT_SOURCE`

hmm, doesn't seem to be one of the ones we care about

cgit.freebsd.org/src/tree/sys/sys/cdefs.h#n644 this is about where we start sorting through visibility

Title: cdefs.h « sys « sys - src - FreeBSD source tree

what is the distinction between section 4 and section 9 of the manual? they both say kernel stuff

i guess section 4 is about hardware and /dev?

gm

how do i disable ssl

That question is way too broad to be possible to answer.

i remember selecting this in installation yesterday

now hexchat wont connect

connection refused (ssl handshake time out)

this is what it says

warsoul: change the port for the irc server

Is there a reason that KERNEL_RETPOLINE was never enabled in GENERIC?

Title: rS330110

"In this commit it is disabled by default, but will be changed in a

followup commit."

there is a typo here: 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

Title: Chapter 16. Security | FreeBSD Documentation Portal

cedb, open a bug with a suggested edit on bugs.freebsd.org

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 ;)

Although with e5c6dece988, I think it's enabled conditionally.

ah, 2a5ba072014 enables it outright

the first you mentioned is userland, no?

and I don't see that second hash

That's because it's an MFC of something that was done before the switch to git ;)

Title: src - FreeBSD source tree

I see, so it's a "default no" but enabled if the compiler supports it

the way i read it, it's enabled conditionally for platforms that aren't amd64, and if the compiler supports it on anything else

it defaults to no on all platform, and is marked as broken on amd64

(wich is kinda weird tbh)

shouldn't it be the opposite ?

I ain't got no clue.

I found some code in the makefiles that said We will remove this in Freebsd 12.

Maybe there's a lot of that stuff?

deprecate ALL the things

There was a bunch of deprecations a few days ago.

babz, that's not how I read kern.opts.mk.if NOT i386 and NOT amd64, set as broken

oh you're right

i was reading the phabricator link above

this one makes much more sense

lw, ping

jbo: is this a particularly busy time of the year for ports?

normally the channel isn't this active!

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.

johnjaye, this channel has no direct relation to/with ports

right, i meant it might be some spillover from something like a new release or new stable or something.

nah

i thought you said something like you have 1000 entries on buzgilla now to look over.

you must be mistaking me for somebody else

well maybe!

how dare you!

hi, i'm having trouble with usb permissions

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

pirate, depends on the circumstances. sometimes the operator group is sufficient. but without more details your guess is as good as ours.

jbo: i tried adding the user to the operator group

pirate: but what are you trying to do?

well, i have a hid device, usb connected relays

and i'm trying to control them via python script

works fine if i run it as root, works fine under linux

sounds like a job for devd

similarly, i wanna control a 3d printer with octoprint

What does it mean I have: USES= compiler:c++11-lang ? I don't think I have a compiler called c++11-lang

mns, it tells the ports framework that the port requires a C++ compiler that is C++11 capable.

mns, that does not specify the compiler itself, just the required capability

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.

mns, if the port requires GCC, there is USE_GCC=

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

"typically" is the key word here. the ports framework provides a lot of infrastructrue to allow different compilers etc.

Title: 481874 – Add arm64 support for FreeBSD

jbo: tbh, i'm not seeing how devd does permissions

i added the user to both operator and dialout, still permissions failure

jbo: thanks. I'm trying to help with 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.

Title: 274939 – Feature request: enable the m2 (modula2) front end in lang/gcc13

pirate, you typically setup a devd rule which sets the permissions on ATTACH

mns, nice - thanks for helping!

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

mns, are you building through poudriere?

mns, strongly recommend to use ccache

jbo: no, just 'cd /usr/ports/lang/gcc13 ; sudo MAKE_JOB_NUMMBER=6 make'

yeah definitely use ccache :D

that way you don't re-build the same thing over and over

I'll have to look into setting that up, unless you have some pointers

jbo: is there an example i can see somewhere?

pirate, man devd.conf(5) has at least one USB matching example AFAIK