04:36:11 <rtprio> anyone know if i can update glibc inside the /compat/linux ?
04:37:28 <mason> rtprio: As long as you keep things consistent, just think of it as an encapsulated Linux distribution. Just make sure you don't use something so new expects unsupported syscalls. Not sure if there's a guide for that.
04:50:34 <rtprio> great
05:01:04 <nimaje> where does your current one come from? from linux_base-rl9?
15:11:21 <polarian> dch: hey would you mind if I PMed you to ask you something?
15:11:31 <polarian> you are core, its only a quick question so I didnt think it warranted an email
15:11:35 <polarian> warrented*
15:11:42 <polarian> whatever, spelling is hard :p
16:54:16 <skered> Top level src/ Makefile[s] is just make running make? I'd like to guess that's a make per-project/component, maybe even down to the program level - given that most (all?) have a Makefile.
16:56:14 <skered> Is possible to provide the lower level makes a prefix?  ex: bear (generates compile_commands.json).   The docs say to run bear at the top level however I think there is some leakage of data between indepent parts of the tree when you do that with LSP/clangd.
17:05:15 <ivy> skered: you can do something like 'make -C bin/ls all install' if you want to build a single program
17:05:34 <ivy> (or 'cd bin/ls; make all install' which is functionallity equivalent)
17:05:53 <ivy> this skips a lot of stuff the top-level Makefile.inc1 does, but for quickly testing something, it's usually fine
17:06:29 <ivy> i'm not sure what you mean by provide a prefix though
17:10:23 <skered> Yeah, I know I can build single things by hand but I was hoping I could get the internal makes to exec via bear such that they have their own compile_commands.json
17:12:33 <skered> The issue is with the single one off `make -C ... ` even with bear it doesn't have --sysroot so it's using system paths.  That's another issue I've seen with trying to do one offs.
17:14:10 <skered> er hold on... what's the different between `make -C bin/cat` and `make -C bin/cat all` ?
17:15:25 <ivy> all is the default target, so nothing
18:40:47 <karolyi> cyric: are you cy⊙Fo by any chance?
18:41:10 <ivy> karolyi: i don't think Cy is on IRC
18:42:00 <karolyi> ivy: I hoped to reach him online in a more responsive way than email is, but I'll email him then
18:42:12 <ivy> karolyi: he's usually fairly responsive to email, fwiw
18:42:21 <karolyi> thanks, good to know
18:42:27 <ivy> although he's busy with some personal irl stuff recently
18:43:19 <karolyi> I hope to get this patch in spamassassin before 4.0.3 releases as I've been told "we have not yet planned any dates for a v4.0.3 release": https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8374
19:51:51 <Macer> Due to a significant increase in abuse, largely driven by AI scraping, this Bugzilla instance is now only available to authenticated users.
19:51:57 <Macer> :(
19:56:13 <rwp> The AI Scraping Plague is destroying everything.
19:58:40 <LXGHTNXNG> kweeehhh :(
20:00:23 <ivy> i actually have an Apache Bugzilla login but for some reason it's not accepting it, oh well
20:00:33 <polarian> they dont like ivy bridge :)
20:13:11 <karolyi> need me to pastebin it?
20:14:35 <karolyi> my account is from way back in time
20:30:11 <ivy> polarian: but it's so pretty https://upload.wikimedia.org/wikipedia/commons/8/8e/Ivybridge%2C_the_bridge%2C_Plymouth%2C_England-LCCN2002708050.jpg
20:32:00 <polarian> lol
22:18:14 <polarian> alright something I cant find any info on, whats the best way to find a file from LBA on freebsd
22:18:59 <polarian> I have a read error, I need to find the file at the LBA
22:20:56 <rwp> No idea.  But upon what file system type?  ZFS?  UFS?
22:21:48 <rwp> If you don't know I think the easiest way to print it is "df -hT" the -T option prints the file system top.
22:22:22 <polarian> rwp: zfs
22:22:50 <rwp> And it must be a single disk configuration because otherwise zfs would have "healed" it from one of the other copies.  Drat!
22:23:11 <polarian> rwp: yes
22:23:13 <polarian> its in my laptop
22:23:19 <polarian> nothing on my laptop I care about, so yeah
22:23:31 <polarian> I have a sneaky suspicion this HDD is finally kicking the bucket
22:23:35 <polarian> its 13 years old
22:23:37 <polarian> maybe more
22:23:54 <polarian> I swore I wouldn't replace it until it dies
22:23:55 <rwp> What does "zpool status -v" say?
22:24:01 <polarian> and I still wont, until it kills itself
22:24:05 <polarian> rwp: I had 2 read errors
22:24:09 <polarian> but no files listed
22:24:13 <polarian> so I assume its zfs metadata
22:24:22 <rwp> I think the zpool status -v should list the files associated.
22:24:26 <polarian> yes
22:24:32 <polarian> hence why I think its metadata
22:24:39 <polarian> this is not recoverable without reverting to a snapshot
22:24:59 <polarian> and my last snapshot is too far back for me to care enough
22:26:16 <polarian> I wouldnt have this issue with OpenBSD, because errors go unchecked :p
22:26:26 <polarian> xD
22:26:31 <rwp> I think if it were me I would read all of the data off to backup.  During that read any blocks with errors will be printed.  Then you can decide to replace the storage device.  And restore the backup upon it.
22:26:38 <polarian> yeah my last snapshot was 2 months ago
22:27:00 <polarian> rwp: like I said, I dont give a fuck about anything on my laptop
22:27:13 <polarian> anything I care about is already cloned to my server
22:27:18 <joepublic> perhaps throw it into a volcano
22:27:26 <polarian> so I will run this HDD until it kills itself
22:27:35 <rwp> Then like joepublic suggests, time to discard it and replace it.
22:27:43 <polarian> nah
22:27:46 <polarian> not until it dies for good
22:27:54 <polarian> and if it hangs on for dear life, then so be it :p
22:28:10 <polarian> also one or two read errors doesn't mean the HDD is on the way out jsyn
22:28:19 <polarian> this HDD has no realloc sectors
22:28:27 <polarian> so its not had to reallocate at all yet
22:28:57 <rwp> If you want to try to postpone the inevitable then read every block and write it back.  One of the blocks will have an error.  Write zeros or random data over the block with the errors.  The firmware on the drive will try to write the block.  If that works then it is recovered.  If it fails then it will use a spare block on the drive and again the drive is recovered.
22:29:21 <polarian> rwp: that is what I was going to do
22:29:29 <polarian> but if my suspicion is that its filesystem metadata
22:29:32 <polarian> I could break zfs by doing that :p
22:29:40 <polarian> best to errr... leave it for now :3
22:29:54 <rwp> To read and write every block I would boot the installer iso as a live boot system.  Jump to a shell.  Then "dd if=/dev/ada0 of=/dev/ada0 bs=1M status=progress" and let it read and write every block.
22:30:38 <polarian> hmmm
22:30:44 <rwp> The installer might try to zpool import the storage.  If so then BEFORE doing this make sure the drive is exported and NOT mounted.  Critically important to have nothing else writing to it.
22:30:56 <polarian> yeah I get that
22:31:05 <polarian> I feel like I would fuck that one up though
22:31:11 <polarian> and end up wiping my system
22:31:24 <polarian> but I much rather just rewrite the block info
22:31:24 <rwp> They don't call dd the disk destroyer for nothing.
22:31:28 <polarian> aka convert the LBA to block
22:31:30 <polarian> and then do it
22:31:39 <polarian> I thought they called it the dick destroyer :p
22:31:41 <polarian> j jk
22:32:15 <rwp> Useful flags for dd in this case are bs=1M iflag=fullblock oflag=sync,direct so that the writes are all synchronous and when the command exits the buffers are all sync'd and flush'd.
22:32:54 <polarian> actually
22:32:59 <polarian> I can just convert the LBA
22:33:01 <polarian> and seek
22:33:42 <rwp> I note that you are giving inconsistent feedback.  "like I said, I dont give a fuck about anything on my laptop" and "I feel like I would fuck that one up though".  So you both care about the data and don't care about the data.  Hmm...  I would back up and then reinstall and then put your data back.  that's a safe answer.
22:34:23 <polarian> can anyone remember the maths for converting LBA to block
22:34:30 <polarian> physical block that is
22:35:40 <rwp> Since you say this is very old then it can't be very large.  Run "dd if=/dev/ada0 of=/dev/null bs=1M status=progress" let it run until it prints an error.  That error should tell you which block has the read error.
22:36:10 <polarian> err thats a good idea
22:36:12 <polarian> or err
22:36:26 <polarian> pass blocksize=512
22:36:29 <polarian> and slap the LBA into dd
22:36:33 <polarian> and it should hit the right lBA
22:36:35 <polarian> lemme see
22:37:48 <rwp> The reason I always set bs=1M is because it avoids the small physical reads that may actually be multiple repeated reads of the same block.  Getting down to the 1M size block should be good enough and much more efficient to get there.
22:37:51 <polarian> dd: /dev/ada0: Input/output error
22:37:53 <polarian> haha
22:37:55 <polarian> it works
22:38:02 <polarian> how
22:38:12 <polarian> now*
22:38:16 <polarian> do I be stupid and zero this block...
22:38:23 <polarian> this could brick my filesystem...
22:38:28 <rwp> Did it tell you the block with the error?
22:38:34 <polarian> no I did some maths
22:38:43 <polarian> bs=512, and then skip=<LBA>
22:38:45 <polarian> count=1
22:38:56 <polarian> so one block and skip to the LBA which smartctl reported error
22:39:02 <polarian> and yes I got the error which means the maths worked
22:39:13 <polarian> now what do I do I wonder...
22:39:25 <polarian> well if theres a read error, then its not like the data is required on the system
22:39:26 <rwp> The thing I like about dd if=/dev/ada0 of=/dev/ada0 from a live boot is that I don't have to do any math and I can't be wrong about it.
22:39:29 <polarian> otherwise it wouldnt boot already
22:39:39 <polarian> question is do I
22:39:42 <joepublic> I am not sure how writing randomly to the drive differs from the volcano solution
22:39:51 <polarian> dd if=/dev/zero of=/dev/ada0 bs=512 skip=<LBA>
22:39:54 <polarian> count=1
22:39:59 <polarian> DONT FORGOT THE COUNT=1 otherwise fuck!
22:40:05 <rwp> The volcano solution is better because then the drive will be replaced.
22:40:21 <polarian> should I zero the block, votes y/n
22:40:45 <rwp> It's not the solution I proposed.  Which means you have to decide to do it yourself.
22:40:58 <Macer> jump! jump!
22:41:06 <polarian> actually, just in case I will wait a few days, snapshot, move it to my server and then fuck about with this
22:41:15 <rwp> And joepublic is voting volcano.  Which is a good vote in my opinion.  But you say you don't care about this data.
22:41:17 <polarian> theres nothing massively important
22:41:21 <polarian> but I rather not reinstall freebsd all over again
22:41:24 <polarian> redo the configs
22:41:26 <polarian> you get the point
22:41:27 <joepublic> really, just the drive, not the whole laptop
22:41:38 <polarian> the drive stays until it wont spin no more
22:41:48 <Macer> it's a platter?
22:41:51 <polarian> yes
22:41:59 <polarian> this thing will spin until it dies
22:42:10 <polarian> I dont care if I am 100 years old by then, it will keep spinning until it dies
22:43:21 <vkarlsen> No planned obsolescence here, we run the hardware until the wheels fall off
22:43:32 <Macer> lol.. to each their own. i only use platters for my nas.
22:43:45 <rwp> Since you are looking at crazy schemes...  How about this?  Get a USB attached drive of the same size.  Mirror the two drives together.  Let zfs silver the attached drive into the mirror.  Then let zfs "heal" the bad block on the original disk with a scrub?  It will lose whatever that block is holding.
22:43:59 <Macer> i definitely wouldn't bother with a 2.5" platter in a laptop nowadays though.
22:44:34 <rwp> My NAS boxes are all spinning drives too.  More cost effective.
22:44:40 <Macer> vkarlsen yeah. i still use my 2013 macbook pro. when a meteor hits it i'll replace it
22:45:18 <Macer> i was trying to put some iteration of bsd on it but i just can't cope with the trackpad not working out the box lol
22:45:39 <polarian> vkarlsen: seeeee... someone gets it
22:46:03 <polarian> rwp: ots fomeeeee
22:46:05 <polarian> oops
22:46:07 <polarian> thats not english
22:46:09 <polarian> it was meant to say "its fineeeeeeeee"
22:46:14 <Macer> i use it for office work. and even today it does that quite well and the screen is probably better than 90% of the screens on things today
22:46:36 <Macer> say what you want about apple products but the retina screens are legit. :)
22:46:44 <rwp> polarian, Does that mean you did it?  And now the bad block is gone?
22:46:47 <polarian> also with NAND prices at £102/TB, HDDs are the way to go :p
22:46:58 <polarian> rwp: no I didnt do it, I wont touch it until I snapshot and move it to a server
22:47:04 <polarian> I currently dont have a server running openzfs (long story)
22:47:06 <Macer> i'm surprised platters aren't going through the roof
22:47:07 <polarian> I will in a few days
22:47:12 <Macer> you'd think there would be carry over
22:47:13 <LXGHTNXNG> they are macer
22:47:16 <polarian> and then I will copy the snapshot over
22:47:21 <polarian> and if I need to, I can rebuild the pool from snapshot
22:47:23 <Macer> oh they are? i haven't had to get one in a while
22:47:24 <polarian> in the worst case
22:48:01 <Macer> my pools are both at 50% but at least now with zfs supporting raidz expansion i can just toss one or two more onto a vdev and be done with it instead of having to make another vdev
22:48:04 <Macer> what a godsend
22:48:54 <rwp> Remember that life is a 2x multiplier.  You need to be able to back that data up.  So will need a second system of at least the same size for backup purposes.
22:49:54 <polarian> openzfs is a brain fuck I swear
22:49:59 <Macer> well.. this thing has been a trooper for a decade without problems replacing dead disks :)
22:50:36 <Macer> but i do have a backup server but that's for the super important stuff
22:50:38 <polarian> whenever you feel comfortable with openzfs it reminds you, that you know a mere fraction of what it is
22:50:45 * polarian sighs
22:50:50 <rwp> Life is good!  Right up until it isn't.  WWJD?  He would save.  :-)
22:50:58 <Macer> haha
22:51:34 <Macer> polarian i come from the days of yesteryear where backups etc were a lot more difficult.. these kids don't know how easy they have it :)
22:52:04 <polarian> Macer: why because you do zfs snapshot zroot@whatever, then send it to some remote server
22:52:12 <polarian> and then restore everything from scratch by recv it again?
22:52:15 <Macer> you know speaking of that
22:52:24 <Macer> does zfs allow encrypted zfs send?
22:52:27 <Macer> i never looked into that
22:52:30 <polarian> no afaik
22:52:33 <Macer> doh!
22:52:36 <polarian> its done over SSH
22:52:39 <Macer> well.. there's your reason why :)
22:52:43 <Macer> no i mean the data itself
22:52:54 <polarian> elaborate?
22:53:03 <rdr> use case?????
22:53:20 <rwp> I thought very recent zfs does allow send on encrypted datasets and will send the encrypted data of them.  Because initially there were bugs in that process.  Which I think is only recently fixed and mature enough to test out.
22:53:21 <Macer> storing it on a storage conglomerate
22:54:13 <rdr> so you are using ZFS with encryption, but ssh transfers the data with encryption so...
22:54:16 <Macer> rwp ah. ok. yea i was curious about that considering you'd be using a 'public service' as a snapshot backup and obviously if it's sensitive data...
22:54:55 <Macer> rdr the sending and storing are different issues. sure you can zfs send using ssh to make the connection remain encrypted but i was asking about the actual data itself being stored remotely on storageco servers
22:54:55 <rdr> you could add another layer of encryption and encrypt the data on the encrypted drive to send over encrypted ssh :D
22:55:41 <rwp> Initially there were a few very serious bugs found in that new encrypted dataset code.  I read the disclosures and didn't feel I needed to be the beta tester for those features.  But I thought I read that they were mostly worked out now.  I have been wanting to try them.
22:55:43 <Macer> so their ai can't scrub your data to train itself or whatever :)
22:56:09 <Macer> ah cool... if you ever try it let me know what it does lol
22:56:33 <rwp> Remote backups to servers not in a secure location should just always be encrypted data blobs just as a matter of policy.
22:56:41 <polarian> I really need to play/learn more with backups
22:56:49 <polarian> I dont know all the cool shit you can do
22:56:49 <Macer> yeah. i agree with you there
22:56:54 <polarian> my good old way of doing backups is tarballs
22:56:56 <Macer> that's why i was curious about it
22:56:57 <polarian> versioned...
22:56:59 <rwp> That is a scary thing to hear someone say! :-/
22:57:09 <polarian> I have tons of tarballs
22:57:19 <polarian> I dont even know whats in most of them
22:57:27 <polarian> they are mostly phone backups because android has no good fucking way to backup
22:57:35 <Macer> wasn't tar created for tape backups though? :)
22:57:42 <Macer> so i mean.. in a way it makes sense?
22:57:45 <polarian> Macer: ah whatever, it does its job
22:58:12 <Macer> no. i'm actually saying that what you're doing isn't necessarily 'wrong' .. i mean tar was meant to back things up wasn't it?
22:58:21 <Macer> like it means 'tape archive' doesn't it?
22:58:23 <rdr> tarballs are sticky and get stuck everywhere
22:58:45 <Macer> too bad tape drives and tapes are so ridiculously expensive
22:58:55 <Macer> especially for how slow they are
22:59:02 <rdr> i'm still trying to tame the cat command =^(o.o)^-
22:59:32 <rdr> okay question that i should just ask AI
22:59:32 <Macer> and the marketing at 2x the actual space because of compression too
22:59:53 <rdr> what is the best way to list all processes to grep if something is running, "ps auxww"?
23:00:23 <rwp> Best?  Everyone does their own thing.  But yes "ps auxww" is good.  Try it with "d" too.
23:00:41 <rdr> i'm just wondering if some flags are superfluous
23:00:46 <rwp> Some people like to | grep "[f]oo" so that it does not match itself.  (shrug)  I just ignore the grep matching itself.
23:00:57 <rwp> Nope.  You need all of those flags.
23:01:10 <rdr> on a certain otherOS it's just aux I should read the man page
23:02:20 <polarian> come to think of it, if the block is erroring, then it cant be read anyways, so if the device is still booting
23:02:22 <polarian> its not mandatory
23:02:28 <rwp> Reading the man page is the way.  Because then you see that "u" is user,pid,%cpu,%mem,vsz,rss,tt,state,start,time,command: and implies -r and other useful things.
23:03:48 <rwp> Without 'u' it sorts hierarchically by controlling terminal and then process id.  Which isn't enough for me to get the mental tree image out of it.  So add 'd' for it.  Try "ps axd" for example.
23:04:33 <rwp> ps will truncate lines to the terminal size.  That's the reason for adding 'w' and another 'w' for "ww" so you get the full command line arguments.  If that's desired.
23:04:51 <swee> I noticed specifically on freebsd with a coffee lake cpu/igpu with i915kms, kde plasma wayland feels like it's less than 60fps (it's much smoother on linux), i know it's not me because it's much smoother with X11 (with screen tears), and Xonotic still reports 100+ FPS with the same effects level
23:05:05 <swee> just a freebsd silly or what?
23:05:29 <rdr> wayland on freebsd is still newish
23:05:35 <rwp> s/freebsd/wayland/ is being silly
23:05:49 <rdr> but xonotic can go as many frames as it wants it just wont display on your screen if it is running at 60fps
23:06:17 <swee> rwp: wayland is much smoother on linux
23:06:33 <rdr> lets see if kde has a fps addon
23:07:17 <swee> it used to have a benchmark effect in Plasma 5, i dunno what happened to it
23:07:27 <rdr> 1. Built-in "Show FPS" Desktop Effect
23:07:38 <rwp> swee, What is the advantage of Wayland again?  (my looks away shyly, I think I will go for a walk now)
23:07:43 <polarian> alright err
23:07:48 <polarian> here goes nothing
23:08:01 <rdr> system settings -> Desktop effects (might be in submenu) -> Show FPS
23:08:09 <rdr> is your refresh rate correct in KDE settings?
23:08:09 <swee> rdr: https://lounge.swee.codes/uploads/25c6037017771e1b/image.png yeah..
23:08:13 <polarian> reading 512 bytes from /dev/zero and then seeking to the LBA
23:08:17 <polarian> hope to fuck this doesnt brick my device
23:08:31 <rdr> you might just need to get it... with get new or maybe it isn't installed
23:08:36 <rdr> i'm gonna check
23:08:39 <polarian> dd if=/dev/zero of=/dev/ada0 bs=512 seek=2239833278 count=1
23:08:42 <polarian> am I missing anything :p
23:08:44 <polarian> rwp: back me up :p
23:08:50 <swee> rdr: yeah it is, 60hz, just like in linux
23:09:06 <polarian> ah it looks fineee
23:09:10 <polarian> count=1 will stop any major damage :3
23:09:23 <rwp> polarian, If that is the block then that seems as reasonable as I can judge.  But if you break it you get to keep both halves of it.
23:09:48 <polarian> ah fuck
23:09:59 <polarian> I cant write to it while mounted I forgot
23:10:17 <polarian> will deal with this another time then :3
23:10:36 <rwp> Saved by the safety feature!  Well, you will need to boot a live iso boot or something and then do it.
23:11:08 <polarian> rwp: yeah yeah I know
23:11:11 <polarian> cant be arsed rn
23:11:19 <polarian> will let the corruption fester like an open wound for a few days
23:11:25 <polarian> I dont have the time to play with this
23:11:45 <polarian> I should really play with backing up with snapshots, and rebuilding the device from snapshot
23:12:02 <rwp> Always a good skill to be able to do.
23:12:17 <polarian> in theory, I should install a second freebsd machine, and then clone my laptop using the snapshot from a server
23:12:27 <polarian> if I can pull the snapshot and rebuild my entire laptop to another laptop
23:12:30 <polarian> it means backups are working :3
23:12:46 <polarian> rwp: yeah but when you have infra still on Linux it makes shit harder
23:12:50 <polarian> my infra is old
23:13:01 <polarian> its about to be replaced, but yeah
23:13:34 <polarian> I have never actually had a checksum failure, so err...
23:13:34 <rwp> I have quite a mixed set of systems here too.  But they all talk to each other okay.
23:13:50 <polarian> I do wonder if bitrot is really as bad as data scientists point out
23:14:39 <rwp> I have had power cable problems and have had SATA cable problems that both caused checksum failures and the zfs checksum checking saved me from losing my data.  ZFS rocks!
23:15:23 <rwp> But so far on ZFS I have not had a storage device, either spinning or flash nand, fail yet.
23:16:10 <rwp> Since zfs detected, reported, protected me, from the cable problems that is still a big win for zfs.
23:16:56 * rwp must head to a meetup, later!
23:18:21 <polarian> rwp: enjoy!
23:18:37 <polarian> OpenBSD may be getting a better fs soon :)
23:18:44 <polarian> ik people have been saying it for decades
23:18:59 <polarian> one of the devs is porting his 9front filesystem (gefs) to OpenBSD rn
23:54:25 <polarian> trying to setup serial terminal access right now
23:54:27 <polarian> and it aint going well
23:54:37 <polarian> ttyU0   "/usr/libexec/getty std.115200" vt100   on secure
23:54:43 <polarian> this should work
23:55:05 <polarian> baudrate of 115200, vt100 emulation, on, and allow root access
23:55:51 <polarian> I am using two ttl serial adapters, with the rx and tx soldered to the opposites on each
23:56:01 <polarian> so GND to GND, RX to TX and TX to RX
23:56:53 <polarian> from the client machine I have plugged in a different adapter and jumped rx and tx, and I indeed get a loopback, so I have the right interface