<remiliascarlet>
ukky: Both Firefox and Chromium suck. They're technically operating systems these days.
<ukky>
remiliascarlet: Firefox sucks less. Unfortunately, I need it when working remotely. Maybe I can try PaleMoon and see if it works.
<remiliascarlet>
SiFuh_: "The knife laws in Japan suck" Yes, you can only carry one of up to 6 cm total size in urban places. Having longer ones in forests or something is still alright though. But so far, I've never had an issue with my knife, which is 11 cm on the blade alone, even walked by police officers many times with it, and nobody even bothered.
<remiliascarlet>
ukky: I need Firefox or a Chromium browser at my dayjob too, because even though 95% of the web backend works fine in browsers like Netsurf, Dillo, or even w3m, there is still a little bit of Javascript going on sadly, although at least it's jQuery and none of the "modern" crap.
<remiliascarlet>
s/backend/frontend
<remiliascarlet>
Because the backend works fine regardless of browser.
<SiFuh>
remiliascarlet: 5.5 cm if it is a folding knife that locks open. 6cm is for pocket knives. Did you hear that story where a 74 year olf American man went to the police station and asked directions to the book store? The police asked him if he had a enough and he spent 9 days in lock up?
<SiFuh>
remiliascarlet: I also read a story about a man missing his flight home because he had purchased a knife and put it in his 'check in' baggage and customs saw it and called him down to ask questions. When they had seen that the seal was broken on the wrapping around the knife they detained him for quite some time.
<SiFuh>
Like how is that saving Japanese lives? He's flying out of the country with his knife packed away.
<SiFuh>
5.5cm and 6cm is a really stupid law. My smallest knife the blade is 9cm
serpente has quit [Remote host closed the connection]
<ukky>
imho, 'prt-get sysup' by default should exit right after first failure when multiple ports get updated. The patch for core/prt-get: https://0x0.st/8olr.patch
<zorz>
ukky: beerman :)
<zorz>
.cpp for .... :-)
<ukky>
zorz: this is just an opinion, not a bug. The patch is automatically applied on my Crux systems.
<ukky>
If it is not a bug, it is a matter of opinion.
<farkuhar>
ukky: isn't that just applying the behaviour of "grpinst", making it a toggleable option rather than a top-level command? I think I already added such an option (--group) in my prt-get fork.
<ukky>
farkuhar: If 'prt-get grpinst' is used, then prt-get will exit as soon as error is detected. But in case of 'prt-get sysup' is will skip failure and continue to the next port in the list of ports that can be updated.
<SiFuh>
There is a feature that I'd like since the database question is out of the loop for now.
<farkuhar>
ukky: The way I interpreted Alan's proposal, the "grpinst" behaviour could be applied to other top-level commands (like "sysup") by having prt-get respect a new flag, --group. So you'd run "prt-get sysup --group" and get the exit-on-first-failure behaviour.
<SiFuh>
Would be nice if you do a prt-get depinst <some dumb package> and it provides a list of all the dependencies you installed for that port at that time. So if you don't like that port or it failed and you don't want it. You can remove those dependencies you no longer need because you were not using them before.
<zorz>
SiFuh: agreed
<ukky>
farkuhar: there is no logic in having '--group' flag for 'sysup', as of course 'sysup' operation _is_ a group operation.
<SiFuh>
It could just be a log file or a text file that gets dumped in some location like in that particular ports directory.
<SiFuh>
Like if you build shotcut. You will find a text file that says shotcut_deps.txt
<ukky>
'sysup' might have '--fail-on-error' and '--continue-on-error' instead of '--group'.
<farkuhar>
ukky: it's possible that the user wants to continue through the first failure and keep updating the other ports, so I made the behaviour toggleable. It could be a default that "sysup" triggers the --group flag, but long-time users might not be expecting that, so I didn't add any logic to link the two.
<SiFuh>
zorz: Usually I have to do ls -lt /usr/ports/packages/ |more
<SiFuh>
PKGMK_EXIT_ON_ERROR="Y"
<zorz>
yes... or write a wrapper that read the # Depends on: libmpfr readline but if other packages depend on that... needs work
<ukky>
farkuhar: of course different users expect different default behavior. Some would prefer '--continue-on-failure'.
<farkuhar>
ukky: I agree that --group is a poor name for the flag, but we inherited a tool that has "grpinst" as a top-level command, so I named the flag accordingly, to minimize the novelty.
<farkuhar>
zorz: you should check out "prt-get listorphans" for that use-case. Combine it with "finddeps" if you want to avoid uninstalling a package that was eagerly linked.
<SiFuh>
farkuhar: Too much work.
<farkuhar>
work no bigger than what zorz already volunteered to take on, in proposing a wrapper script. By the way ... s/SiFuh_/SiFuh/ ?
<zorz>
too much
<SiFuh>
Doesn't matter, they are both ere
<SiFuh>
zorz: They fucked up my paint job again 2 days ago.
<farkuhar>
They will both last longer than zorz.
<SiFuh>
Yeah, zorz is only 4
<zorz>
hahahahahhaa\
<zorz>
hahahahahhaa\
<farkuhar>
Heh, 4 years old ... are those Earth years or Jupiter years?
<zorz>
SiFuh: whos the car?
<SiFuh>
The grandmother told her grandson to move the clothes like out of the rain. He didn't want to. So he stormed out of the house, grabbed it and smashed it into my house. On the way it took out my table with my paint job
<SiFuh>
farkuhar: zorz isn't 48 years old
<SiFuh>
zorz: No one is the car
<zorz>
who owns the car?
<SiFuh>
What car?
<farkuhar>
The car that got the paint job?
<SiFuh>
farkuhar: If zorz was living on Mercury he'd be over 190 now and if he was living on Pluto 18 months old.
<SiFuh>
farkuhar: zorz: That car was done a long time ago. And I don't think I can park the car on top of the table.
<farkuhar>
Oh, so there was a new paint job that didn't involve a car.
<SiFuh>
No, I was doing several paint jobs at the same time.
<SiFuh>
Car, Sai and Fender Flares.
<SiFuh>
The Fender Flares is what they kept fucking
<SiFuh>
9 times already they fucked it up.
<zorz>
give the car to the owner and give him money to go to a repair shop :P
<zorz>
problem solved :)
<SiFuh>
The only one that hasn't touched my paint jobs is the dog.
<zorz>
mans best friend
<SiFuh>
zorz: Did you see that one about the woman years ago comparing man to woman and diamonds to dogs?
<SiFuh>
Hmm Thuraya 4 was sent into space on the 4th of January. I guess it is still working out the geosynchronous orbit. https://www.n2yo.com/satellite/?s=62483
<farkuhar>
Hmm the latest libcdio version bump came with a warning about ABI changes, https://github.com/libcdio/libcdio/blob/master/NEWS.md ... but mpv played back an audio CD just fine today, without needing a rebuild against the updated libcdio.
<farkuhar>
Maybe my mpv process didn't utilize enough of the libcdio ABI to trigger any breakage; all I did was start the playback and let it run straight through to the end of the disc.
<zorz>
i followed ukkys suggest and just compiled firefox134 its was fast.
<farkuhar>
I thought ukky was playing around with PaleMoon these days. It's nice to see zorz experimenting with alternatives to Chromium, though.
<zorz>
i did a trick with git pull in void-packages. post-merge hook triggered
<ukky>
farkuhar: No PaleMoon yet. I use Firefox daily, but from '-bin' port, with my patches to keyboard shortcuts.
<farkuhar>
Anyway, mpv makes no secret about its lack of support for DVD menus, so it's plausible that the libcdio ABI changes will be more visible in other dependent ports, like kodi.
<zorz>
farkuhar: i really liked mplayer, less dependancies... less footprint
<zorz>
amazing
ppetrov^ has quit [Quit: Leaving]
<farkuhar>
ukky: Speaking of '-bin' ports, I wanted to try changing rust-bin so that one port could serve both musl- and glibc-based systems. Here's what I've got so far: https://d.uguu.se/LUUShDUQ
<farkuhar>
I can't think of another instance where a port overrides the default pkgmk functions check_footprint() and make_footprint(), but that's what you have to do if you want to avoid triggering a mismatch based on the libc provider, the CPU architecture, or something else that might vary from one CRUX system to the next.
<farkuhar>
Oh, and the `sed "/[0-9a-f]\{16\}/d"` is needed here because the filenames containing hexadecimal hashes are not identical between the glibc and musl tarballs. It will also be necessary to override check_signature(), to avoid testing a glibc tarball against a musl checksum, and vice-versa.
zorz has quit [Quit: leaving]
<farkuhar>
But if your system is powerful enough to compile firefox in 17 minutes, then compiling rust every few weeks shouldn't be such a hassle either. The rust-bin port is primarily targeted at users who don't have such powerful machines.
<ukky>
farkuhar: Your Pkgfile seems good to generalize glibc/musl builds. Of course, assuming just for x86_64 target CPU.
zorz has joined #crux-social
zorz has quit [Quit: leaving]
zorz has joined #crux-social
<zorz>
farkuhar: yes experimenting with firefox... fuckin firefox needs dbus.
<farkuhar>
zorz likes his firefox to be controllable from a socket. But when it comes to media players, his preferred choice mplayer seems to be less scriptable than some of the alternatives.
<zorz>
george found a simple solution
<farkuhar>
mpv I haven't yet tried to control via sockets or dbus message passing, but it does play nicely with lua scripts if you want to do some external processing of the currently-opened file.
<zorz>
Unable to load /var/lib/dbus/machine-id or /etc/machine-id: Failed to open file "/var/lib/dbus/machine-id": No such file or directory