| furrywolf | aww, is the gopher server gone? | 03:56 |
|---|---|---|
| rrq | which host was that? | 04:12 |
| furrywolf | dunno, but I just tried the gopher links, and they no longer work. | 04:13 |
| rrq | which link(s)? | 04:14 |
| furrywolf | gopher://www.devuan.org etc. | 04:15 |
| rrq | mmm that must have been the old www.devuan.org host | 04:15 |
| rrq | would you want to set one up on the current www.devuan.org host? | 04:22 |
| rrq | or even, would you want to one set up on the current www.devuan.org host? | 04:24 |
| golinux | lynx gopher://republic.circumlunar.space isn;t coming up either | 04:26 |
| meep_____ | Can we bring it back but as a Gemini service? | 04:53 |
| meep_____ | I prefer the Krystall client | 04:58 |
| gordonDrogon | A long shot, but has anyone had/used OpenShot with Beowolf? I was using it with ASCII on a crappy old i3 system with on-board Intel graphics and it could use the on-board thing to assist with rendering, but got a new(er) PC, i7, on-board intel (plus PCIe nvidia) and can't get OpenShot to use the hardware at all. (Using the same OpenShot 2.5.1 I was using on the old PC, comes in "AppImage" format) | 14:23 |
| djph | is it one of those goofy "Optimus" based things? | 14:25 |
| gordonDrogon | the PC? It's a refurbished Dell. | 14:27 |
| djph | laptop or desktop? | 14:33 |
| gordonDrogon | desktop. specifically: Dell OptiPlex 9020 | 14:37 |
| djph | gordonDrogon: okay, that should(tm) just fire on nvidia by default ... well, long as you've got things plugged in right | 14:46 |
| gordonDrogon | djph, yes - I thought so. it's plugged in, currently displaying video - 2 monitors - the control panel thing works but OpenShot won't/can't use it. | 14:51 |
| djph | I'm not surprised the onboard graphics are getting disabled since you have proper GPUs | 14:52 |
| djph | but then again, I haven't used OpenShot on a machine with dedicated GPUs in ... well, I don't think ever. | 14:53 |
| gordonDrogon | OpenShot can't/won't us the on-board either, although I've not tried without the nvidia card plugged in. | 14:53 |
| gordonDrogon | I'll give that a go after lunch. | 14:54 |
| djph | I was more thinking it was "disabled" because it was forcing you into using the nVidia (as in "no, you can't change this because I know you have a good card, why would you want to use the bad card?!") | 14:55 |
| gordonDrogon | although right now CPU rendering is almsot as fast on the new PC as using the hardware on the old PC was. | 14:55 |
| gordonDrogon | I'm new to the multi-card thing, but when I plugged the card in, with the video cables still in the on-board one, it whinged that I had nothing plugged into the PCI card. | 14:56 |
| gordonDrogon | I don't care which one I use, but I'd really like some hardware assist when doing the final render on videos. | 14:56 |
| djph | Might need to read into it more. If you're plugged into the nVidias, it might just run with those without even thinking about software | 14:58 |
| djph | Assuming you've got the nVidia drivers running the show | 14:59 |
| gordonDrogon | they are all installed and working and video is coming out of that card. OpenShot just won't use hardware acelleration for whatever reason known to it. I'll remove the card, go back to the on-board one which might be the same as my old i3 system - I can run-up the old drive and check from there just to make sure, then who knows. Maybe I needed to install some extra library or something on the old system I've not done here. | 15:03 |
| gordonDrogon | I'm not weded to this nvidia card- it was just cheap/part of the bundle I bought. I know that they're not that linux friendly, so who knows. | 15:04 |
| gordonDrogon | djph, I've removed the nvidia card. PC works fine with on-board video, vainfo seems to suggest it's working fine, but OpenShot still won't/can't use it. | 15:41 |
| djph | weird | 15:41 |
| gordonDrogon | glxgears works, which suggests it's actually usable from programs. OpenShot is just behaving weirdly then. Maybe I'll downgrade to ASCII and see what happens.. | 15:52 |
| nemo | gordonDrogon: glxgears works at a decent framerate? | 15:54 |
| nemo | gordonDrogon: (with vsync disabled) | 15:54 |
| gordonDrogon | er, 60fps. not sure how to disable vsync (yet) | 15:55 |
| nemo | __GL_SYNC_TO_VBLANK=0 vblank_mode=0 glxgears | 15:55 |
| nemo | the first one is for nvidia non-free | 15:55 |
| gordonDrogon | got it. | 15:56 |
| gordonDrogon | 61825 frames in 5.0 seconds = 12364.921 FPS | 15:56 |
| gordonDrogon | (which I suspect means it's actually using hardware - I hope!) | 15:57 |
| nemo | haha | 16:04 |
| nemo | gordonDrogon: if it is, I want your CPU | 16:04 |
| nemo | gordonDrogon: what's the openshot weirdness? | 16:04 |
| gordonDrogon | old pc: i3 system - OpenShot worked fine, but slow. It supported hardware rendering using the onboard intel video thing. It was running ASCII. New (ish) PC. Intel i7 with on-board intel graphics - fresh install of Beowolf - OpenShot works, but can't enable hardware rendering. | 16:06 |
| gordonDrogon | I'm using the same OpenShot AppImage binary on the new PC that I used on the old one. (the packaged .deb is much older) | 16:07 |
| gordonDrogon | new Pc is a refurbished Dell from a popular UK supplier. It's otherwise working very well. | 16:08 |
| nemo | huh... weird. ascii can use your good graphics card but beowulf can't?? that's usually the reverse of how graphics work on linux | 16:11 |
| nemo | gordonDrogon: did you install the firmware package after upgrading to beowulf? maybe that got missed? | 16:11 |
| nemo | gordonDrogon: and, anything in dmesg that looked suspicious? | 16:11 |
| gordonDrogon | the 'card' is the on-board video. I have a separate nvidia card, but am not using it. | 16:11 |
| gordonDrogon | the only stuff I've installed has come via apt and the standard repositories (including non-free) | 16:12 |
| nemo | you got 12k FPS in glxgears using your embedded nvidia?? | 16:12 |
| gordonDrogon | no - embeded intel. | 16:12 |
| nemo | er intel yes | 16:12 |
| nemo | wow | 16:12 |
| gordonDrogon | I've never used this stuff on the past, but it sounds like it's maybe not quite right ... | 16:12 |
| nemo | well. it's just a very rough "benchmark" | 16:13 |
| gordonDrogon | the display of the gears did not look any faster, but I don't know if that's be design. | 16:13 |
| nemo | so who knows, maybe it's been optimised out the wazoo | 16:13 |
| gordonDrogon | possibly! | 16:13 |
| nemo | gordonDrogon: well, 12k FPS is not going to render visibly 😃 | 16:13 |
| nemo | your monitor would not be capable of it even if your eyes were | 16:14 |
| gordonDrogon | well quite, but I was sort of surprised it wasn't jus a blur ... | 16:14 |
| nemo | heh | 16:14 |
| nemo | gordonDrogon: well, I'm going to guess the animation is designed to render normally | 16:15 |
| nemo | gordonDrogon: and not linked to the frame rate | 16:15 |
| nemo | most are | 16:15 |
| gordonDrogon | I've checked permissions too - /dev/dri/* is group video and I'm in that group. | 16:15 |
| nemo | gordonDrogon: oh. and the firmware package? | 16:17 |
| nemo | (s) | 16:17 |
| gordonDrogon | seems ok, however I'd jsut dug through the openshot debug log: libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so has no function __vaDriverInit_0_32 | 16:17 |
| gordonDrogon | so now following that rabbit hole.. | 16:17 |
| nemo | ah | 16:18 |
| nemo | gordonDrogon: so tool looking for a deprecated/removed function or something | 16:18 |
| gordonDrogon | https://bbs.archlinux.org/viewtopic.php?id=233143 <-- seems to have clues. let me check that. | 16:19 |
| gordonDrogon | reinstalled it, but same result, however I'll follow this path more - seems to be on he right track for now. | 16:21 |
| gordonDrogon | ok, found this: https://github.com/OpenShot/openshot-qt/issues/3210 where it looks like Beowolf is too new. This is something I've never encountered in 25+ years of Debian, (now Devuan, of-course) so I'm somewhat surprised. | 16:25 |
| gordonDrogon | anyway, thanks for the input. sometimes it just needs a bit of chat to make the old grey cells think a bit different... | 16:28 |
| nemo | haha | 16:28 |
| nemo | yeah, debian being "too new" is a rare situation indeed | 16:29 |
| gordonDrogon | I could try building it from source, but not today. | 16:32 |
| nemo | gordonDrogon: hmmm this openshot uses appimage. lame | 16:33 |
| nemo | gordonDrogon: is that how you installed it? | 16:33 |
| gordonDrogon | yes. | 16:33 |
| nemo | ah. welp. this bug is just one of the many reasons I despise app image. but nice to have reinforcement for it ☺ | 16:33 |
| gordonDrogon | well - not that you technically 'install' an appImage, however.. | 16:33 |
| nemo | hehe | 16:33 |
| nemo | whatever | 16:33 |
| gordonDrogon | yea, it's the first time I've encourtered it. 140MB of ... well, almsot everything. | 16:34 |
| nemo | personally I'm rooting for nix as the least-sucky of the whole bad bunch | 16:34 |
| nemo | it's kind of a meta package manager offering some hope for dedupe and security updates | 16:34 |
| gordonDrogon | I'm a bit out of touch - been nothing more than a 'user' for far too many years now. | 16:35 |
| nemo | gordonDrogon: examining the bug it looks like you could also perform surgery on it by symlinking their libraries to the system ones | 16:35 |
| nemo | gordonDrogon: I've done that with some success in closed source games on steam and GoG | 16:35 |
| nemo | gordonDrogon: any reason you didn't use apt install openshot btw? | 16:36 |
| gordonDrogon | possibly. video editing is just a bit of a hobby right now. my new PC software renders at the speed the old one did with the hardware assist, so it's not the end of the world in that respect. | 16:36 |
| gordonDrogon | the openshot in apt is quite old. | 16:36 |
| nemo | 2.5.1 ? | 16:36 |
| gordonDrogon | oh? | 16:37 |
| nemo | https://pkginfo.devuan.org/stage/beowulf/beowulf-backports/openshot_2.5.1+dfsg1-1~bpo10+1.html | 16:37 |
| gordonDrogon | I see 2.4.3 | 16:37 |
| nemo | .. backports | 16:37 |
| gordonDrogon | ah, backports. | 16:37 |
| nemo | always check backports 😝 | 16:37 |
| gordonDrogon | RIGHT. Hold my beer ... | 16:37 |
| nemo | apt -t beowulf-backports install openshot | 16:37 |
| nemo | gordonDrogon: what I like about that backports package is it is tagged as "oldlibs" ☺ | 16:41 |
| nemo | so clearly even 2.5.1 packaged by debian has issues w/ openshot | 16:41 |
| nemo | hmmmm maybe it's qt though | 16:41 |
| nemo | if so, I sympathise | 16:41 |
| nemo | Hedgewars kinda sorta migrated after qt4 was killed off, but we're using internal headers just to still function pending a complete frontend rewrite. hate qt | 16:42 |
| gordonDrogon | Oh, I say, old chap!, Bravo! | 16:43 |
| gordonDrogon | not only working but I'm seeing 35fps rendering speed. | 16:44 |
| gordonDrogon | I might even plug the nVidia card back in and see if it's any better. | 16:46 |
| gordonDrogon | nemo, thanks! | 16:47 |
| nemo | np ☺ | 16:48 |
| nemo | one less app image in the world always makes me happy | 16:48 |
| gordonDrogon | indeed. | 16:48 |
| nemo | gordonDrogon: BTW, I really really really wish debian would rethink their backports behaviour with regards to optional/game/non-critical packages | 16:51 |
| gordonDrogon | I'm not a fan of qt either, but for many other reasons - mostly involving Raspberry Pi people wanting to use some stuff I developed never intending it to be used with the qt make system. ugh. | 16:51 |
| nemo | gordonDrogon: we've spent soooooo much time supporting debian users. the existing backports mechanism is very non-discoverable. ubuntu makes it slightly less sucky btu still | 16:51 |
| nemo | gordonDrogon: heh. like what? | 16:51 |
| nemo | gordonDrogon: util/FileEngine.h:#include <private/qabstractfileengine_p.h> | 16:52 |
| gordonDrogon | oh the all want to cross compile their enny weeny little things. I did a (popular at on time) C based GPIO library for the Pi. | 16:52 |
| nemo | ↑ that's our current problem | 16:52 |
| nemo | nifty | 16:52 |
| gordonDrogon | I'm tempted to resurrect it when I get time to install devuan on a Pi, then make it Devuan only. Churlsh, but I don't care anymore. | 16:53 |
| nemo | gordonDrogon: my OVH VM is devuan these days. it was fairly painless to swap out. | 16:57 |
| nemo | gordonDrogon: I might be hurting their optimisations/dedupe or something, but whatever. not my prob 😝 | 16:57 |
| gordonDrogon | hm. I have an OVH VM too. it's Debian jessie sas-systemd. | 16:58 |
| gordonDrogon | how did you upgrade it to devuan? | 16:58 |
| nemo | gordonDrogon: literally changed the apt lines ☺ | 16:59 |
| nemo | updated, glanced over list, seemed reasonable. fired it off and crossed fingers | 16:59 |
| gordonDrogon | oh. that works? I'll give it a go.. :) | 16:59 |
| nemo | low risk since if I screwed up could reset from console | 16:59 |
| nemo | maybe back up your data just in case | 16:59 |
| gordonDrogon | it's currently mostly sacrificial, so won't hurt. | 16:59 |
| nemo | gordonDrogon: I use mine mostly to have a european IP | 16:59 |
| gordonDrogon | welcome to our great gdpr overlords. | 17:00 |
| fsmithred | gordonDrogon, look at the migration from jessie guide: https://devuan.org/os/install | 17:00 |
| gordonDrogon | ok, thanks. | 17:01 |
| nemo | gordonDrogon: heh. that's one good reason, but it's handy to have for testing too, or accessing the odd french video w/ kids | 17:01 |
| nemo | gordonDrogon: BTW, one reason I'm still on DVD Netflix. Hollywood's stupid-ass using language barriers to control pricing model. | 17:01 |
| nemo | in streaming world | 17:01 |
| * gordonDrogon nods. | 17:01 | |
| nemo | well, that and DVD selection is orderds of magnitude larger due to less hollywood control too | 17:02 |
| nemo | *orders | 17:02 |
| nemo | aaaand a lot more viewing options | 17:02 |
| gordonDrogon | right. | 17:05 |
| gordonDrogon | ok, so 2nd montor plugged in and working - I have a wrapper script round openshot to turn it on/off as I only use it when editing. life is sweet once again. cheap PC for lots of more goodness. �350 for a i7 refurbished Dell, 16GB RAM and 480GB SSD. Quite happy. | 17:07 |
| FlibberTGibbet | ah, i'd love to have access to subbed French films, nemo :( | 17:10 |
| openbsdtai123 | hi, I deboostrap with a arch64/arm64 (foreign, stage) the system of amd64 devuan stable onto /target (debv/sdc1). Now, stage2, how to run the stage2?? | 17:13 |
| nemo | FlibberTGibbet: yeah. streaming world is a complete mess, and hollywood's determination to try and charge different prices based on local earnings for a product with no delivery barriers is entirely to blame | 17:13 |
| nemo | well. that and determination to try to chage as many times as possible to as many entities as possible, thus the "new contract for every provider" thing | 17:14 |
| nemo | *charge | 17:14 |
| nemo | FlibberTGibbet: but with DVD Netflix and a european IP, life is not too bad. still has its annoyances though | 17:14 |
| openbsdtai123 | gordonDrogon: I use 3 monitors with raspberry pi :) low energy and green power. | 17:17 |
| nemo | openbsdtai123: I've been looking into moving my little gentoo server to rpi just to save power | 17:19 |
| nemo | my main issue is it has a modest number of files on it. I'm wondering if a 256GB SD card is a sane thing to do to a pi | 17:20 |
| gordonDrogon | from my Pi experiences, I'd boot the Pi off internal SD, then mount /home, etc. on external drive(s)/nas .. | 17:27 |
| nemo | gordonDrogon: was kinda hoping to just have on pretty little package without any dangly external SSD, but, I suppose | 17:31 |
| gordonDrogon | yea, there is that too. 256GB on a �SD card... the size of my fingernail. I have a 128GB one on my GoPro and that's just bonkers.. | 17:32 |
| meep_____ | Why not put the rootfs on the drive? | 17:37 |
| nemo | gordonDrogon: yeah, my phones been using a 128GB SD card for years now. have transferred it to 3 different phones. best way to get data from one phone to another ☺ | 17:40 |
| nemo | I might bump it up to 256 at some point, but it seems to be doing fine still. it doesn't get written to very heavily | 17:40 |
| gordonDrogon | meep_____, that works, but personally I'm not a fan of having to rely on something on the end of a bit of wire unless it's all fixed in a box... | 17:41 |
| meep_____ | Your on a raspberry pi | 18:23 |
| meep_____ | Isn't that like the modern equivalent of a Commodore64? | 18:24 |
| meep_____ | You've got almost no power delivery buffer to your SoC | 18:24 |
| meep_____ | Reliability isn't exactly of high priority here | 18:24 |
| meep_____ | I'd think you'd be more concerned about wear on a dumb-NAND-flash device | 18:25 |
| meep_____ | And how Devuan turns off all ext4 safety features in order to reduce NAND wear, and uses a fragmentation-preventing filesystem instead of a CoW filesystem, the reliability of your system disk on an sdcard is really out the window | 18:26 |
| nemo | meep_____: well, I'd probably move it from gentoo, so that'd help wear quite a lot | 18:26 |
| nemo | meep_____: only area there'd be significant writes would be /var/log and that is easily handled | 18:26 |
| meep_____ | Maybe if you put ZFS or some other CoW FS on the sdcard, but I really don't think your OS should be on the sd | 18:26 |
| meep_____ | Just boot | 18:26 |
| MinceR | an endurance SD card might also help | 18:27 |
| nemo | also. if the SD card wears out, everything on there is backed up anyway | 18:27 |
| meep_____ | Your USB power sully changes suddenly by +/- 0.03 volts and your kernel crashes | 18:27 |
| nemo | just drop in a new one. | 18:27 |
| nemo | meep_____: hm.... does that actually happen on pis still? | 18:27 |
| nemo | never encountered that | 18:27 |
| meep_____ | And because all safety features were turned off on the sdcard your OS disk is full of truncated files | 18:27 |
| nemo | maybe with a really crappy power supply | 18:28 |
| meep_____ | Yes | 18:28 |
| meep_____ | This really happened | 18:28 |
| meep_____ | To me | 18:28 |
| meep_____ | With Devuan on a raspberry pi | 18:28 |
| nemo | well. truncation would be mostly in /var/log again. big whoop | 18:28 |
| meep_____ | No it was all over the system, in /usr too | 18:28 |
| nemo | but obv annoying if it happened with any regularity | 18:28 |
| nemo | meep_____: huh. why? | 18:28 |
| meep_____ | Run 'mount' and see why | 18:28 |
| meep_____ | Look at those dangerous mount options | 18:29 |
| meep_____ | I switched to NetBSD after seeing that for the pi | 18:29 |
| nemo | meep_____: no. I mean.. what on earth had open file handles in /usr | 18:29 |
| nemo | where? | 18:29 |
| meep_____ | I don't remember exactly | 18:29 |
| meep_____ | I opened a bug about the issue ascii | 18:29 |
| meep_____ | On the mailing list | 18:30 |
| nemo | welp. if you can dig it up. rather curious how that happened | 18:30 |
| meep_____ | Suffice to say debsums reported lots of unhappiness | 18:30 |
| nemo | typically /usr only gets written to when updating | 18:30 |
| meep_____ | /usr is normally mounted rw | 18:31 |
| meep_____ | Not ro | 18:31 |
| nemo | and you'd think that'd be fairly rare. could run sync after update I guess. I know some friends from early linux days still haven't broken the sync reflex due to how unreliable things were way back when | 18:31 |
| meep_____ | At least on a default install | 18:31 |
| nemo | meep_____: I'm aware. that's not my point | 18:31 |
| nemo | actually I don't even have /usr as a separate mount point anyway | 18:32 |
| nemo | but still.... file truncation should only be in areas being actively written to | 18:32 |
| nemo | you typically get damage in /var - sucks hard for mariadb and such | 18:32 |
| nemo | my SO keeps hard powering off her devuan laptop. she's done it... dozens of times | 18:33 |
| nemo | can't get her to stop | 18:33 |
| nemo | file truncation every time. but always in non-critical locations. firefox cache, /var/log. | 18:33 |
| meep_____ | Ounce the filesystem got corrupt | 18:33 |
| meep_____ | It just got more and more and more as time went on | 18:33 |
| nemo | erm... that's not really how it works AFAIK... | 18:33 |
| nemo | at least w/ ext4 | 18:33 |
| meep_____ | Maybe not normally, but all safety features is turned off in the asii rpi install | 18:34 |
| meep_____ | *ascii | 18:34 |
| meep_____ | Your SO? | 18:35 |
| nemo | Significant Other | 18:35 |
| nemo | meep_____: whether safety features are turned off or not, it shouldn't matter that a file that is open readonly is not going to be corrupted | 18:35 |
| nemo | meep_____: and /usr in a normal situation is only written to when updating | 18:36 |
| nemo | so scenario for /usr corruption seems to me to be one where you ran apt update and then OS died almost immediately after | 18:36 |
| nemo | that, or, far more likely, your SD card was bad to begin with | 18:36 |
| nemo | buying off amazon is a great way to get scam cards | 18:36 |
| meep_____ | Well that's not the case | 18:36 |
| meep_____ | Ever since netbsd the system has been running flawlessly | 18:37 |
| nemo | maybe all the bad sections were finally marked invalid. but yeah, no idea. do link me to bug report some time, kinda curious | 18:37 |
| nemo | I mean, not impossible, but sounds kinda magic | 18:37 |
| nemo | perhaps you just got really really unlucky | 18:37 |
| meep_____ | In fact | 18:37 |
| meep_____ | Check out my uptime since netbsd ON THE PI | 18:38 |
| meep_____ | arm64# uptime | 18:38 |
| meep_____ | 9:37AM up 135 days, 6:47, 1 user, load averages: 0.06, 0.02, 0.00 | 18:38 |
| meep_____ | arm64# uname -a | 18:38 |
| meep_____ | NetBSD arm64 9.0 NetBSD 9.0 (GENERIC64) #0: Fri Feb 14 00:06:28 UTC 2020 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/evbarm/compile/GENERIC64 evbarm | 18:38 |
| nemo | $ uptime 12:38:12 up 241 days, 20:37, 3 users, load average: 2.63, 2.20, 1.78 | 18:38 |
| nemo | we doing the uptime thing? yay! | 18:38 |
| nemo | fav linux user competition | 18:38 |
| meep_____ | Yeah yeah all these excuses when the mount options and dmesg are literally screaming in your face ALL EXT4 SAFETY IS OFF!!!!. That's why I switched to BSD for embedded use | 18:39 |
| nemo | meep_____: again. I'm not saying it can't happen, I just can't understand how it happened | 18:39 |
| nemo | and, BSD is fine, been meaning to try it myself. you could also have, oh, changed mount options | 18:40 |
| nemo | this is not about excuses. I literally can't work up a scenario that is not rather low probability | 18:40 |
| nemo | and trying to understand how | 18:40 |
| nemo | esp since I have like a dozen linux machines running at home (not that any of them have had this happen, but still would be good to know) | 18:40 |
| nemo | not to mention all the ones at work | 18:40 |
| nemo | and they loooove randomly rebooting those in the vhost | 18:40 |
| meep_____ | » you could also have, oh, changed mount options | 18:41 |
| meep_____ | I could have, but I didn't trust the arm build maintainer's judgement of nonsafe by default | 18:41 |
| meep_____ | And when asking on the ml, I was told it was mainly just a direct copy from rasbian | 18:41 |
| meep_____ | I understand your skepticism | 18:45 |
| meep_____ | Because this was the first time for me ever losing a significant amount of data on ext4 | 18:45 |
| nemo | meep_____: well. that and I can't understand what was being modified on /usr | 18:50 |
| nemo | not to mention claim it corrupted everything else. that's never happened. | 18:51 |
| nemo | meep_____: so. definitely would like more info on what files were corrupted. would be good to know and might help form at least a theory | 18:51 |
| nemo | meep_____: how does netbsd mount /usr/local ? | 18:51 |
| cronolio | where i can find out a nice documentation for sysvinit ? | 19:05 |
| meep_____ | It corrupted binaries and libraries | 19:10 |
| meep_____ | nemo: NetBSD is different in that packages are installed into their own directory | 19:11 |
| meep_____ | Not /usr | 19:11 |
| meep_____ | Packages even have their own etc | 19:11 |
| meep_____ | For example to configure nut on netbsd, instead of /etc/nut/nutd.conf | 19:13 |
| meep_____ | It's /usr/pkg/etc/nut/upsd.conf | 19:13 |
| meep_____ | Also my system doesn't have a /usr/local | 19:13 |
| meep_____ | arm64# ls /usr/pkg | 19:14 |
| meep_____ | bin etc include info lib libexec man sbin share | 19:14 |
| meep_____ | Only NetBSD stuff goes in /usr/bin | 19:15 |
| meep_____ | Bzip2, groff, cc, etc | 19:15 |
| nemo | meep_____: where does netbsd put shared package libraries? | 19:26 |
| nemo | I mean, this is probably wildly offtopic at this point | 19:26 |
| meep_____ | Third party? In /usr/pkg/lib | 19:27 |
| nemo | meep_____: so... similar to linux flatpak etc? ☹ duplication? | 19:27 |
| meep_____ | No duplication | 19:27 |
| nemo | ok. so /usr/pkg = /usr/local on freebsd | 19:27 |
| meep_____ | So your base system (first part NetBSD operating system) is /usr/ and the prefix set for all third party software is /usr/pkg | 19:28 |
| meep_____ | Bins, mans, etcs, includes, sbins, and shares | 19:28 |
| meep_____ | Kinda of like freebsd? | 19:28 |
| meep_____ | The only problem with NetBSD is the lack of builds | 19:30 |
| meep_____ | If you want to use it as a desktop you'll have to add a lot of ports to the tree yourself | 19:30 |
| meep_____ | But it's got a very interested way it does memory management | 19:30 |
| meep_____ | UVM i think it's called | 19:31 |
| meep_____ | At least the original implementation | 19:31 |
| meep_____ | It's very lean | 19:31 |
| meep_____ | I would like to bring a full usable desktop's worth of software to it one day, If I could acquire the funding to work on it | 19:34 |
| tuxd3v | well my rpi1 on beowulf as a uptime of only 30 days, but it used to have 300+ days | 19:34 |
| tuxd3v | 18:33:26 up 30 days, 14:51, 1 user, load average: 0.00, 0.00, 0.00 | 19:34 |
| meep_____ | tuxd3v: any scary messages in dmesg? | 19:34 |
| meep_____ | (on the pi) | 19:34 |
| tuxd3v | none | 19:35 |
| tuxd3v | rock solid | 19:36 |
| meep_____ | uhub0: autoconfiguration error: illegal enable change, port 1 | 19:36 |
| meep_____ | WARNING: 2 errors while detecting hardware; check system log. | 19:36 |
| meep_____ | Hmm. Maybe there is something wrong with my pi | 19:36 |
| meep_____ | Unless one of those errors in the NO TOD CLOCK DETECTED | 19:36 |
| meep_____ | Which is normal because I don't have a UTC on my smbus | 19:37 |
| meep_____ | *RTC | 19:37 |
| tuxd3v | meep_____, using zram as swap, also helps with the sd card wearing | 19:38 |
| meep_____ | Oh no need with with NetBSD. I never really go above 20 megabytes ram usage | 19:38 |
| meep_____ | I've got over 800 megs to spare | 19:39 |
| meep_____ | Feel like I'm using Linux v1 again with this level of efficiency | 19:39 |
| tuxd3v | I already compiled some code in rpi1, and it really helped me using zram as swap, but my rpi has 256MB of ram | 19:41 |
| tuxd3v | right now I am using a insane 46MB | 19:42 |
| fsmithred | with or without wm? | 19:42 |
| tuxd3v | but I have also running a dns server, dhcp server, scanner server, printer server, and so on.. | 19:42 |
| tuxd3v | only in server mode | 19:43 |
| tuxd3v | no wm | 19:43 |
| meep_____ | Ntp? | 19:45 |
| meep_____ | You need ntp on the pi without an rtc | 19:45 |
| tuxd3v | yes ntp server too :) | 19:45 |
| meep_____ | Unless you wire one in | 19:45 |
| tuxd3v | actually it his the ntp server for my home network :) | 19:46 |
| tuxd3v | his -> is | 19:47 |
| tuxd3v | ho I forgot | 19:47 |
| tuxd3v | rpi1 reserves 16MB for the graphic card weather you want it or not( its the minimum ) | 19:48 |
| tuxd3v | so we could say that he is using 30 MB of Ram | 19:48 |
| tuxd3v | armv6 is very good in code density | 19:49 |
| tuxd3v | armv7 uses a lot more memory due to not so good code density | 19:49 |
| tuxd3v | but still, I managed 35 mb on my Olimex Olinuxino Lime 2 :) | 19:50 |
| tuxd3v | server mode, no dhcp server, scanner, printer, nothing of this, only ntp server | 19:51 |
| tuxd3v | meep_____, what is the Ram comsumption of your rpi? | 19:56 |
| tuxd3v | you are on netbsd? | 19:56 |
| meep_____ | Yes | 19:56 |
| meep_____ | Memory: 530M Act, 260M Inact, 23M Wired, 15M Exec, 557M File, 18M Free | 19:57 |
| meep_____ | Most of that is a crappy ups driver | 19:57 |
| tuxd3v | meep_____, what is your pi version? | 19:58 |
| meep_____ | hw.model = raspberrypi,3-model-b | 19:58 |
| meep_____ | 552 nut 85 0 20M 1528K select/3 209:55 0.00% 0.00% powercom | 19:59 |
| tuxd3v | meep_____, how do you get the hardware model in netbsd? | 20:00 |
| meep_____ | Sysctl hw.model | 20:00 |
| tuxd3v | the sysctl is close to Linux one? | 20:03 |
| meep_____ | Not much difference | 20:03 |
| meep_____ | Other than the BSDs putting more stuff in a sysctl instead of /proc | 20:03 |
| tuxd3v | meep_____, does you have the /proc/cpuinfo?(I guess not..its in sysctl right?) | 20:16 |
| tuxd3v | meep_____, in your vision how is the arm arch supported in netbsd? | 20:17 |
| jonadab | Ok, once is a glitch, twice is a pattern. Has anybody else had the ascii->beowulf upgrade go horrifically wrong, resulting in the network just plain not working? I mean, everything _looks_ like it should be working (ifconfig looks happy, etc.), but no data are sent or received, at all? | 20:51 |
| gnarface | no, i haven't seen that, but i've gotten in some package tangles upgrading a couple times. maybe something got blocked or overlooked? | 20:53 |
| gnarface | obviously regressions are possible but so far what you describe is at worst very rare | 20:53 |
| gnarface | is it wireless or ethernet? | 20:54 |
| jonadab | The upgrade itself went fine, as far as that was concerned. No complaints from apt. (I did do a dist-upgrade on ascii before switching the sources to beowulf, due to past experiences with, umm, I think it was the lenny upgrade, convincing me this is a good practice.) | 20:54 |
| jonadab | Ethernet. | 20:54 |
| jonadab | These were both systems with more than one ethernet interface. | 20:54 |
| gnarface | ok, and when you did the upgrade, you did a "apt-get update && apt-get dist-upgrade" after switching to the beowulf sources, too, right? | 20:54 |
| jonadab | Yes. | 20:54 |
| gnarface | alright | 20:55 |
| gnarface | put your sources.list at paste.debian.net so i can sanity check it | 20:55 |
| jonadab | One moment. | 20:55 |
| jonadab | http://paste.debian.net/1159928/ | 20:56 |
| gnarface | hmmm | 20:57 |
| jonadab | Everything package-wise appeared to go fine. | 20:57 |
| gnarface | i don't know if us.mirror.devuan.org is wired up right though, that could be outdated | 20:57 |
| gnarface | it should be but i'm not sure | 20:57 |
| gnarface | just in case, try it with deb.devuan.org instead | 20:57 |
| gnarface | otherwise it's starting to look like a kernel issue | 20:57 |
| jonadab | But after restarting on the new system, attempting to for example access the internet, failed because nothing could resolve. And no, it's not a resolv.conf problem, I checked that. And ssh to a known IP address also failed. | 20:57 |
| gnarface | can you ping another machine on the LAN? | 20:58 |
| jonadab | No, that also failed. | 20:58 |
| gnarface | try it again with deb.devuan.org and see if that gives you a bunch of packages you didn't have yet | 20:59 |
| jonadab | (This isn't urgent right now, BTW. I have an older system that I'd kept as a spare standing in.) | 20:59 |
| gnarface | otherwise you'll have to try a different kernel version - newer or older would be equally worth testing | 20:59 |
| gnarface | are you using the backports kernel? | 20:59 |
| jonadab | Just replace us.mirror.devuan.org with deb.devuan.org correct? | 20:59 |
| gnarface | correct | 20:59 |
| gnarface | at best they're going the same place anyway. at worst, us.mirror.* is going to outdated records | 21:00 |
| jonadab | No, the only things I used from backports were what certbot needed, almost 100% sure that wasn't the kernel; and in any case the kernel got updated after switching the repos to beowulf. | 21:00 |
| gnarface | well if it's not the beowulf-backports kernel, then that's worth trying too | 21:01 |
| gnarface | if the upgrade left a 4.9 kernel still installed from ascii though you should be able to just reboot to it through the grub menu | 21:01 |
| jonadab | Hmm, there's a thought. | 21:01 |
| jonadab | In the past that didn't always work, due to things like glibc and udev not being compatible with a kernel from across releases. | 21:02 |
| gnarface | eh, it depends on what you're doing, but it should be at least capable of booting to a text terminal you can test the network with | 21:02 |
| gnarface | graphics might fail | 21:02 |
| gnarface | i've booted headless beowulf servers with kernels as old as 4.1.x | 21:03 |
| jonadab | Hmm, with deb.devuan.org, dist-upgrade is now offering me linux-image-4.19.0-10-amd64 | 21:03 |
| gnarface | very interesting | 21:03 |
| gnarface | might just be a coincidence. that one may have been released just now | 21:03 |
| gnarface | either way, worth a try | 21:04 |
| jonadab | Yeah. | 21:04 |
| gnarface | the last idea i have is just check the ethernet cable. they're not invincible. | 21:05 |
| gnarface | been doing this for approaching 2.5 decades now and in that time i've seen 3 ethernet cables die with no apparent physical damage, 2 on the same day. | 21:06 |
| gnarface | just wore out from all the megahurts | 21:06 |
| jonadab | Heh. | 21:06 |
| golinux | jonadab: From devuan.org "Devuan has a network of package repository mirrors in place. The mirror network is accessible using the FQDN �deb.devuan.org� via http NOT https. Country Codes (CC) are currently unavailable but a specific mirror from the list can be accessed using the corresponding BaseURL. | 21:10 |
| golinux | " | 21:11 |
| jonadab | golinux: Yeah, I think what happened was I just search-replaced jessie with ascii, and then later ascii with beowulf, when upgrading. | 21:11 |
| golinux | Currently, there is no US package mirror available. | 21:12 |
| golinux | Always read the Release Notes | 21:12 |
| golinux | It' | 21:12 |
| golinux | s in there too. | 21:12 |
| jonadab | Is that simply because nobody maintains a US package mirror, or is there a specific reason not to have one (e.g., some legal issue)? | 21:12 |
| gnarface | jonadab: no volunteers in the US | 21:12 |
| jonadab | gnarface: Ok, that was my first guess. | 21:13 |
| golinux | No one has offered to host it. We thought someone was going to but . . . | 21:13 |
| gnarface | jonadab: there's only like a dozen mirrors to begin with | 21:13 |
| gnarface | jonadab: (as opposed to debian's 150+) | 21:13 |
| jonadab | I see. | 21:13 |
| golinux | https://pkgmaster.devuan.org/mirror_list.txt | 21:13 |
| jonadab | Broad is the road that leads to destruction. | 21:14 |
| golinux | @0 actually/ | 21:14 |
| golinux | 20 | 21:14 |
| gnarface | oh we got some more? cool | 21:15 |
| golinux | I just counted | 21:15 |
| jonadab | Wait, is berkeley.edu not in the US any more? | 21:16 |
| jonadab | I know people have joked about CalExit... | 21:16 |
| golinux | Not online afaik. See my comment above . . . | 21:16 |
| jonadab | Hmm, it's bandwidth-limited to 1Gbps. Not sure how many users there are to divide that among at any given moment. | 21:17 |
| golinux | They are mirroring isos. I hope that they do get packages up too | 21:17 |
| jonadab | Ah, I see. | 21:17 |
| golinux | talk to onefang. He's the "mirror whisperer" | 21:18 |
| jonadab | Heh. | 21:18 |
| golinux | http://borta.devuan.dev/apt-panopticon/results/Report-web.html | 21:20 |
| tom_ | my remote logging server is full of | 21:30 |
| tom_ | 2020-08-10 12:05:01infogaleralb1.stnhostCRONpam_unix(cron:session): session closed for user rootinfo | 21:30 |
| tom_ | 2020-08-10 12:05:01infogaleralb1.stnhostCRON(root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)info | 21:30 |
| tom_ | Is there any way to not disable this pointless message from being logged? | 21:31 |
| jonadab | Hmm, new information: the _other_ system where I had the same problem, was using us.deb.devuan.org, and when I switch it to deb.devuan.org and update, dist-upgrade does not offer a new kernel, or any other new packages, for that matter. | 21:55 |
| jonadab | (I managed to get one of the two ethernet interfaces working, in each case.) | 21:56 |
| jonadab | (Did I say that before? I had to swap cables around to do it.) | 21:57 |
| gnarface | jonadab: do they both have multiple ethernet devices? | 22:00 |
| jonadab | gnarface: They have two each. | 22:00 |
| jonadab | One onboard, and one expansion card. | 22:00 |
| gnarface | jonadab: do you have this file? /etc/udev/rules.d/70-persistent-net.rules | 22:01 |
| gnarface | jonadab: make sure eth0 is even the right one anymore. this could be at least part of the problem with both of them. | 22:01 |
| jonadab | ... no, /etc/udev/rules.d exists but is empty. | 22:01 |
| gnarface | hmm. | 22:01 |
| gnarface | is eudev running? | 22:01 |
| gnarface | udev or eudev, any udevd? | 22:02 |
| jonadab | Looks like udevd | 22:02 |
| jonadab | According to ps -A | 22:02 |
| jonadab | Hmm, maybe now we are getting somewhere. Unfortunately, I'm a little out of my depth. | 22:03 |
| jonadab | At least we're not still using mknod | 22:03 |
| jonadab | I guess I should've paid more attention to the modern udev systems. | 22:03 |
| jonadab | This stuff turns out to be important :-) | 22:04 |
| gnarface | well normally what's supposed to happen is the ethernet devices are identified by MAC in a specific order, which is cached in a file in /etc/udev/rules.d/ | 22:04 |
| gnarface | but if something were to cause that order to be changed, or unexpectedly stay the same for that matter, it could invalidate your network configs | 22:05 |
| gnarface | if "/sbin/ifconfig -a" shows both ethernet devices, i'd say just try the other one | 22:05 |
| jonadab | If it's as simple as changing my configs to refer to a different device (say, eth2 instead of eth1), I'm going to kick myself. | 22:05 |
| gnarface | well, there is still the issue of figuring out what happened to your persistent rules file | 22:06 |
| gnarface | you're not using some weird init system are you? this is just a stock sysvinit install, right | 22:06 |
| gnarface | ? | 22:06 |
| jonadab | This is pretty much a stock devuan install. | 22:06 |
| gnarface | if one of the network devices is USB, then that's a common cause of hysteresis in boot orders | 22:07 |
| jonadab | Has never had any systemd-encumbered version of Debian. | 22:07 |
| gnarface | but the persistent rules file from udev is supposed to prevent the boot order from mattering | 22:07 |
| gnarface | so something seems to have gone wrong there if so | 22:07 |
| gnarface | but it could still be a driver issue | 22:07 |
| jonadab | USB theoretically shouldn't be involved, unless the onboard one is wired that way in the circuitboard for bizarre reasons. | 22:07 |
| jonadab | Which would be odd, but I've heard of stranger things. | 22:08 |
| jonadab | Yes, driver issue has crossed my mind, e.g., if a driver was dropped from the kernel so one of my devices is no longer supported. | 22:08 |
| gnarface | it wouldn't show up in "/sbin/ifconfig -a" though if that were the case | 22:09 |
| gnarface | do you see them both? | 22:09 |
| jonadab | Ok, and it does. I get three interfaces there, eth0, eth1, lo | 22:09 |
| gnarface | yea first of all try both of them | 22:09 |
| gnarface | eth0 and eth1 | 22:10 |
| gnarface | and remember it's possible they got swapped somehow | 22:10 |
| jonadab | Hmm, right. | 22:10 |
| jonadab | Let me see if I can get the other one to work, in isolation. | 22:10 |
| gnarface | worth a try | 22:10 |
| jonadab | Hmm. | 22:12 |
| jonadab | Now I am confused why I couldn't get anything working before. | 22:12 |
| jonadab | And I *did* physically power it down and back up a couple of times while trying before, so doing that to bring it to my office isn't why it works now. | 22:12 |
| gnarface | having an onboard ethernet device on the USB bus is not unheard-of for mobile devices but it would be weird for a desktop motherboard | 22:13 |
| jonadab | (I did that on the theory that swapping the cables -- which I did try -- might potentially require the eth cards to be power cycled. It shouldn't, with modern equipment, which this is; but I saw that once on a really old system, so I tried a power cycle because, you know, never hurts to try that.) | 22:14 |
| gnarface | pci boot orders aren't always as static as you'd like either though | 22:14 |
| jonadab | Right, this is a desktop motherboard. | 22:14 |
| gnarface | usually they're much more predictable though... | 22:14 |
| jonadab | Relatively recent -- too new to have traditional PCI ports. | 22:14 |
| jonadab | Err, ports is the wrong word. | 22:14 |
| jonadab | Slots. | 22:14 |
| gnarface | what brand is your ethernet switch? is it d-link perchance? | 22:15 |
| jonadab | It has the new kind, x1 and, umm, I think x16. The eth card is x1. | 22:15 |
| jonadab | Hmm, let me check. (There are multiple switches involved -- I don't *think* any of them are dlink, but one moment...) | 22:15 |
| gnarface | i have had one weird powermanagement bug with certain cheap unmanaged d-link switches that makes the link behave like it's dead even though the lights blink | 22:16 |
| gnarface | it only seems to effect old Dell bioses though | 22:16 |
| gnarface | i suppose that's probably worth asking because i didn't; do you get link lights? | 22:16 |
| jonadab | Ok, the relevant switches are made by TP-link and Cisco. | 22:16 |
| jonadab | And yes, the lights appear working. | 22:17 |
| gnarface | when the Dell/D-link combo is acting up, the symptoms is that the link light comes on, and you even see arp and ping traffic cause the traffic lights to blink, but everything is returned 100% packet loss | 22:17 |
| jonadab | Everything *appears* working, except, you know, traffic doesn't go. | 22:17 |
| jonadab | It's quite a weird thing. | 22:18 |
| gnarface | reboot doesn't fix it, but cold boot does sometimes, and usually also just unplugging the cable and counting 10 whole seconds before plugging it in, or logging into the local console on the machine and just ifup && ifdown the interface after boot | 22:18 |
| jonadab | Hmm. | 22:19 |
| gnarface | that particular bug has haunted me since about 2006 but always that particular combo; an old Dell on a D-link 24-port switch | 22:19 |
| gnarface | so since well before kernel 4.x | 22:19 |
| jonadab | Ok, so now I have a system that appears to be working now, but I'm afraid to put it back in production. Maybe I'll do it during an off time, when it won't matter if things are down for a few. | 22:19 |
| * jonadab hasn't kept up with what the kernel version is lately. | 22:20 | |
| gnarface | er, actually this one is a 16-port switch, and in my head the other was 40-ports but my memory isn't what it used to be | 22:20 |
| jonadab | Last I knew, the new versions were 3.6, but that was a _while_ ago. | 22:20 |
| gnarface | wait, do you know what happened to make it start working again? | 22:21 |
| jonadab | No. | 22:21 |
| jonadab | I don't. | 22:21 |
| jonadab | I mean, I removed it from the production environment and brought it back to my office for study. | 22:21 |
| gnarface | another data point to watch for is if it stops while in service - once the Dells doing this are up, they're fine as long as they stay powered up. the issue only ever happens again if they've been off for more than ~22 hours | 22:22 |
| gnarface | jonadab: lemme know if you figure anything out. i hate gremlins | 23:18 |
| tom_ | ok | 23:41 |
| tom_ | Who put the OBEY easteregg in the xanalog binary? | 23:41 |
| tom_ | That's new since beowulf | 23:41 |
| tom_ | gotta say it's hilarious | 23:42 |
| tom_ | Would really freak someone out who hasn't seen They Live | 23:42 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!