pungentweasel | installing a daedalus or ceres package on chimaera ... yay or nay? I need libavcodec59 to compile something and it's not available on chimaera. | 04:21 |
---|---|---|
pungentweasel | nevermind, thats a nay | 04:27 |
gnarface | check for it in chimaera-backports | 04:28 |
pungentweasel | i did :\ | 04:28 |
gnarface | other option is try backporting it yourself | 04:28 |
gnarface | basically you'd get the daedalus or ceres source package then try to build it against the chimaera build deps | 04:29 |
pungentweasel | it requires a massive cascade of upgrades, not sure I trust myself that much | 04:29 |
gnarface | oh | 04:29 |
gnarface | well if it's not also dependent on a newer kernel you could always just install daedalus or chimaera in a chroot and just run whatever it is from inside the chroot | 04:30 |
gnarface | usually recursively backporting a massive cascade of build deps is not worth it | 04:31 |
gnarface | it'll work if you do it right, but by the time you're done you've basically just upgraded the hard way | 04:31 |
gnarface | at that point you might as well have just upgraded | 04:32 |
pungentweasel | hah yeah | 04:32 |
pungentweasel | ultimately what I'm trying to do is compile mpv media player.. apparently the one provided wasn't compiled with support for framebuffer output | 04:33 |
gnarface | hmm | 04:33 |
pungentweasel | but mpv requires libavcodec59 which basically requires the entirety of ffmpeg........ | 04:33 |
gnarface | maybe mplayer will work instead? | 04:33 |
gnarface | install it and check the output of "mplayer -vo help" for fbdev or fbdev2 | 04:35 |
pungentweasel | it does work, but the software I'm trying to use (invidtui) is only built to work with mpv, sadly. I guess I could maybe try modifying that one but I don't know a lick about golang ... | 04:35 |
gnarface | hmm | 04:36 |
gnarface | eh, hang out someone might have another idea | 04:36 |
pungentweasel | invidtui is an awesome tool btw. it works fine on my arch machine, just can't get it working here | 04:36 |
pungentweasel | will do | 04:37 |
hardy | Is it possible to install devuan in KVM VPS? recently i've purchased VPS on https://www.hn.cl/ and want to know if is it possible to install by myself or ask to support to bring it installed. | 04:39 |
debdog | pungentweasel: maybe that works: prefix for custom built software is /usr/local. inside there you can have other versions of libs installed than the repo provides, even conflicting ones. | 04:42 |
debdog | pungentweasel: so get the lib's source and compile/install it inside /usr/local/lib. then do the same for mpv. sometimes one has to tell the compiler to look for libs in /usr/local sometimes it finds it there automatically | 04:45 |
pungentweasel | debdog, I might give that a try, thanks. I have a feeling this is going to turn into a much bigger ordeal than just libavcodec, that was just the 2nd dependency meson complained about when I tried to build mpv.. libav starts with letter A ... I fear there are many more conflicts to come :P | 04:47 |
pungentweasel | I could possibly try an older version of mpv too.. that's another option I might try, if I can figure out how it's supposed to be built with framebuffer support. couldn't find a lot of info | 04:49 |
gnarface | hardy: theoretically, it all depends on how they have it set up | 05:01 |
hardy | gnarface: sending a message like: hey! could you install this ISO image on my VPS? https://mirror.leaseweb.com/devuan/devuan_daedalus/installer-iso/devuan_daedalus_5.0.preview-20221205_amd64_pool1.iso | 05:29 |
pungentweasel | who is your VPS provider? most of them let you install your own ISOs | 05:39 |
hardy | already mentioned it, it's a chilean .CL company https://www.hn.cl | 05:41 |
hardy | will try locally, then go production environment | 05:42 |
pungentweasel | ah yes sorry, forgot that you did | 06:05 |
unclouded_ | hardy: It ought to be possible. I run a lot of beowulf and chimaera systems under libvirt/qemu | 06:36 |
hardy | unclouded_: Thank you! | 07:24 |
systemdlete | trouble downloading starlinux uhuru. It stalls and finally fails. Maybe problem with sourceforge, idk | 19:42 |
systemdlete | I was able to download the openbox image of star earlier on, but the others won't let me download. | 19:51 |
systemdlete | (I wish that starlinux had its own website for ONLY issues with downloading and installation.) | 19:52 |
eyalroz | I have a trivia question to ask you all. | 20:01 |
eyalroz | Someone has suggested to me, that on Linux (and other operating systems), if I have N fonts recognized by fontconfig or whatever - these fonts are all loaded into memory. | 20:01 |
eyalroz | (as opposed to only fonts in use being loaded.) | 20:02 |
eyalroz | Is this true? True for some desktop environments/GUI toolkits? Once-true but no longer? | 20:03 |
gnarface | eyalroz: i don't know for sure but i believe just an index of all the names of the fonts are loaded into memory, not the fonts themselves... and even if they were it's not like the unused ones wouldn't be pushed to swap in favor of stuff you need | 20:11 |
eyalroz | gnarface: Hmm. So, urban myth then. | 20:24 |
gnarface | eyalroz: a quick google search suggests they may have been experiencing a bug in some other library | 20:28 |
gnarface | possibly this one: https://github.com/libass/libass/issues/548 | 20:28 |
systemdlete | hmmm. Using wget from command line on same link seems to work. So, maybe... firefox? | 20:48 |
systemdlete | a cursory web search of "download with firefox failure" gives a number of hits with regard to this topic. One gives a canned response, which wins the contest for best answer. One respondent points out that such canned responses are useless and annoying. I would up their response. | 20:53 |
eyalroz | gnarface: Well, he seems rather adamant about it. | 21:15 |
eyalroz | Anyway, another question: If I have two versions of the same font (family + variant), in paths which fc-cache looks at. What will it do? Is it guaranteed to choose the newer version? | 21:15 |
gnarface | eyalroz: sorry, don't know about that, i dunno if it'll keep the first or last copy it sees | 22:01 |
eyalroz | np, thanks. | 22:02 |
gnarface | i do know the memory footprint thing should be fairly easy to verify as well as control | 22:02 |
gnarface | if you do a clean boot with one font installed then compare the memory footprint to a clean boot with 160MB of fonts installed you'll know | 22:03 |
gnarface | i'm not completely clear on how many different mechanisms fonts can be loaded with but at least for fontconfig and xorg you have independent means of telling it which fonts to pay attention to in the first place | 22:05 |
gnarface | it's not a kernel thing for those and doesn't happen at boot... the ones for the system virtual terminal might be, but there's far less of them and you can remove them or make them modules with a custom kernel build | 22:06 |
gnarface | i do know the truetype fonts which are the bulk of them don't load outside of X because my system cold boots to 170MB memory footprint and i have 157MB of them installed | 22:07 |
gnarface | so if i'm wrong about that we'd be presuming the entire rest of linux is 13MB | 22:09 |
gnarface | i'm pretty sure i have more than 13MB of driver modules loaded alone | 22:10 |
gnarface | but don't take my word for it, check yourself | 22:10 |
gnarface | and note that cached memory isn't the same as actually used memory | 22:11 |
gnarface | LFSveteran: i'll help you try the chroot thing but the more i think about this i'm starting to doubt myself, i realize now i've only done this for headless steam stuff (dedicated game servers) so there's a possibility it won't work if you can't get 32-bit graphics drivers loaded outside the chroot, at least if xorg isn't also launched from within the chroot... not sure now but it's an experiment i'd like to see the | 22:24 |
gnarface | results of | 22:24 |
gnarface | LFSveteran: first step is to just get debootstrap running though then we can try it, the overhead should just be about 500MB of disk space | 22:25 |
systemdlete | Now, this is strange also: md5sum on an ISO is taking FOREVER. These problems only started today, or at least I had not noticed them until now. | 22:27 |
systemdlete | I started md5sum on a 710MB file about an hour ago. | 22:27 |
systemdlete | I rebooted this VM yesterday, btw. | 22:27 |
systemdlete | wth is going on all of a sudden? | 22:28 |
gnarface | less than 710MB of ram allocated to the VM? | 22:29 |
systemdlete | 4g ram, lots of disk space too | 22:31 |
gnarface | odd | 22:31 |
systemdlete | I don't know. the vm crashed sometime before yesterday morning. I cold rebooted the vm. | 22:31 |
systemdlete | I have fsck set to clean all fs every boot (tune2fs -c 1 ) | 22:32 |
systemdlete | I've looked through the system logs in the VM. Nothing weird I can see. I also checked on the host. | 22:32 |
systemdlete | None of the other VMs are behaving unusually. | 22:32 |
gnarface | maybe a bug, hard to say, or something else chewing up the ram/cpu ? | 22:33 |
gnarface | taking me about 10s to md5sum a 953M live iso here | 22:33 |
systemdlete | well, I am running OMD (which is a front-end for a nagios-like system). But I have been running OMD for over a year now without any problems, other than occasionally seeing it having a problem if I leave tbird or ff running | 22:34 |
gnarface | what to top and iotop say about cpu and disk bandwidth usage? | 22:34 |
fifihyperbola | hello friends | 22:34 |
systemdlete | xorg is at the top | 22:34 |
gnarface | of both? | 22:34 |
systemdlete | but even that isn't using more than 2 or 3% most of the time. | 22:34 |
systemdlete | yes, both! | 22:34 |
systemdlete | I know they are evil, no need to remind me. | 22:35 |
systemdlete | 2 vCPUs allocated to the VM. | 22:35 |
gnarface | memory leak in something else could have crowded up the memory space perhaps? | 22:35 |
systemdlete | well, htop shows only 1.63G of the 4G in use... | 22:35 |
gnarface | hmm | 22:36 |
systemdlete | (and thanks for the help. This is driving me nuts, and most likely, it is my own fault. I just don't know what I might have done to cause this.) | 22:36 |
gnarface | does htop show caches? i had similar behavior when a memory leak in the nvidia drivers wouldn't free its caches | 22:36 |
systemdlete | I haven't applied any updates in the past couple days that I can recall. | 22:36 |
gnarface | try running this: free -h && echo '##### freeing memory leaked by wow #####' && echo 3 > /proc/sys/vm/drop_caches && sync && sync && free -h | 22:37 |
systemdlete | well, it's hard to pick out | 22:37 |
gnarface | we're looking for a big change in the before/after "free -h" output | 22:38 |
systemdlete | so it went from like 1.9G to 2.0G free | 22:38 |
gnarface | nah, not big enough | 22:38 |
systemdlete | well, cache did go down | 22:38 |
systemdlete | from 2.1 to 417M | 22:38 |
gnarface | try the md5sum again? | 22:39 |
systemdlete | 2.1G to 417M | 22:39 |
systemdlete | I said I gave the VM 2 vCPUs. Keep in mind this is an FX8350 and I know that is OLLLLLLLD | 22:40 |
gnarface | that's the same exact cpu i just got a 10s readout from here | 22:40 |
systemdlete | on a 700mb ISO image? | 22:40 |
gnarface | a 953MB iso image | 22:40 |
systemdlete | ok, it has not finished up yet. Killing... | 22:40 |
gnarface | that was not pre-cached | 22:40 |
systemdlete | shite | 22:41 |
gnarface | something's definitely wrong but i can't tell you what | 22:41 |
systemdlete | gnarface, I am running md5sum on the host now | 22:41 |
gnarface | also see if sha256sum is faster, which it shouldn't be, but it also shouldn't take nearly an hour | 22:41 |
systemdlete | btw, that download I tried before in the VM using wget or ff... on the host it is done! | 22:41 |
systemdlete | host took about 3 secs | 22:42 |
systemdlete | (if that) | 22:42 |
systemdlete | so. I am thinking maybe I should cold boot the vm again | 22:42 |
systemdlete | Give me a few minutes and I'll report back. | 22:43 |
gnarface | yea must be something weird in there | 22:43 |
systemdlete | cold boot seems to have cleared the VM's mind. | 22:49 |
systemdlete | I forgot to check a couple other things, though. I just didn't think of them. | 22:49 |
systemdlete | 1. shut down omd | 22:50 |
systemdlete | 2. ff has a task display | 22:50 |
systemdlete | actually... | 22:50 |
systemdlete | 3. shut down ff and tbird | 22:50 |
systemdlete | I wish I had thought of those--they might have revealed the culprit, whatever it was | 22:50 |
systemdlete | thanks for the assist, gnarface | 22:51 |
gnarface | seems highly likely one of them was leaking memory, since they're known for it | 22:51 |
systemdlete | ff and tbird. Oh, yeah. | 22:52 |
systemdlete | I know, I know. | 22:52 |
gnarface | after the iso was cached here i was getting < 6s for sha256sum and just above 2s for md5sum | 22:52 |
systemdlete | And I even have a script that can detect leaks. I'll try to remember to run my script if this occurs again. | 22:52 |
systemdlete | about the same here... now, after cold reboot | 22:53 |
gnarface | actually sha512sum is faster than sha256sum, not sure why that would be | 22:53 |
systemdlete | The star linux ISO I tried originally was the openbox version. The instructions for booting with the expert installer do not appear to be on that one. But it IS on the i3 version. | 22:54 |
systemdlete | oops, I meant: Following the instructions, I could not get the boot prompt to work for me. On the i3 version, there is a menu option (advanced) for the various install varieties | 22:55 |
systemdlete | no such advanced option in the menu on the openbox version | 22:55 |
systemdlete | so I tried downloading another version, picking the i3 image, and that was taking forever, and why I came here crying... | 22:56 |
systemdlete | I haven't looked at the xfce image yet. | 22:56 |
systemdlete | downloading the xfce image now, this time in ff again, and it seems to be behaving itself nicely this time. | 22:59 |
systemdlete | I am actually suspicious about omd, frankly. I've noticed that sometimes it stops working, partially. But if I stop ff/tbird occasionally, omd continues to work ok. | 23:00 |
systemdlete | I could try adding another vCPU or two, but I don't want to rob my other VMs of power either. | 23:00 |
systemdlete | (the others get 4) | 23:00 |
systemdlete | omd is not supposed to be a memory or cpu hog, according to what I am told. | 23:00 |
gnarface | nothing is immune to memory leaks if there's a bug in the code somewhere | 23:01 |
FatPhil | Orchestral Manoeuvres in the Dark? | 23:01 |
systemdlete | how true that is! | 23:02 |
systemdlete | FatPhil, that's pretty good. | 23:02 |
systemdlete | OMD is a frontend to tools like nagios | 23:02 |
FatPhil | I'm showing my age | 23:02 |
gnarface | i think i've even seen a memory leak caused by mismatched 32-bit and 64-bit memory freeing on multiarch | 23:02 |
systemdlete | In fact, it can actually be used with those. | 23:02 |
gnarface | (which wasn't really a bug in the code itself but rather a bug in the package dependencies) | 23:03 |
systemdlete | gnarface, I just got finished writing a fairly simple C program. Took me a month to get past all my own memory tramplings. Of course, I hadn't written C in decades really. | 23:03 |
systemdlete | One thing I discovered is that strings are the main culprit, followed by arrays. And even arrays don't cause nearly as much commotion. | 23:03 |
systemdlete | I ended up writing a string concatenator program which I used not only for merging strings, but just for initialization because it auto mallocs memory. Once I replaced all my string manip with that routine, 95% of my headaches went away. | 23:04 |
systemdlete | anyway, getting a little off-topic | 23:05 |
systemdlete | we should retire to the OT channel... | 23:05 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!