Afdal | 40 minutes -____- | 00:00 |
---|---|---|
gnarface | it won't be as slow as the first time unless you ran "make clean" | 00:00 |
fluffywolf | it should only take a few seconds if you run it again, unless you changed things. | 00:00 |
Afdal | oh rite <.< | 00:00 |
gnarface | these warnings are consistent with a version mismatch or missing -dev package | 00:01 |
gnarface | they'd be consistent with sloppy code too, but when you see this many in a row it's usually something missing | 00:02 |
Afdal | let's see here, what's an easy way to cat a log into a web paste again | 00:02 |
gnarface | you can configure pastebinit to use paste.debian.net i think | 00:02 |
gnarface | but if you used the "> ~/... 2>&1 &" trick i mentioned before then it's already in a file and paste.debian.net will accept text file upload | 00:03 |
gnarface | or you could open it in emacs | 00:03 |
gnarface | if you used that trick verbatim it might be still running in the background though, make sure it's done before you grab the file | 00:04 |
fluffywolf | if you try solving a problem with emacs, you then have two problems. | 00:04 |
gnarface | :-p | 00:04 |
Afdal | that 2>&1 & gobbledegook didn't work for me | 00:04 |
Afdal | pastebinit it is... | 00:04 |
gnarface | well wait | 00:04 |
gnarface | it had to work | 00:04 |
gnarface | it has to work | 00:04 |
gnarface | it won't show anything on the terminal though | 00:05 |
Afdal | oh | 00:05 |
fluffywolf | I usually 2>&1 | tee foo.log | 00:05 |
gnarface | it'll redirect to the file you tell it | 00:05 |
Afdal | well it also ends instananeously so I presumed it didn't even try to compile | 00:05 |
gnarface | no it's cached | 00:05 |
gnarface | also it backgrounds so, like i said, it might still be running in the background | 00:05 |
gnarface | you can check with "ps aux --forest" | 00:05 |
fluffywolf | the extra & at the end of the suggestion above makes it run in the background, and with the output redirected, you won't see it. this is, imho, a really bad way of doing that. lol | 00:06 |
fluffywolf | tee exists for things like this. | 00:06 |
gnarface | probably so | 00:06 |
fluffywolf | jobs will tell you if you still have something running in the background. fg will re-attach you to it. | 00:07 |
Afdal | https://termbin.com/4xhu | 00:08 |
Afdal | there we go | 00:08 |
gnarface | can't make it go to paste.debian.net? | 00:09 |
fluffywolf | the first two errors about missing packages are probably a good place to start. | 00:09 |
fluffywolf | there's also a few errors about c++ standards and such, but I'd see if they go away when fixing the package issues first. | 00:10 |
gnarface | fluffywolf: this is an attempt to build a really old mame version on chimaera, we've already had to disable -Werror and force python2 in the make file | 00:11 |
fluffywolf | I'd wonder if a ./configure or such didn't complete properly. | 00:11 |
gnarface | it doesn't have ./configure | 00:11 |
gnarface | wait | 00:12 |
Jjp137 | Afdal, do you use the MAME debugger at all? if not, go to src/osd/sdl/sdl.mak, and remove the # in front of line 68 | 00:12 |
Jjp137 | otherwise working around this Qt problem seems like a huge pain | 00:12 |
fluffywolf | well, then edit your makefile and add the c++11 options it tells you to add to the cc flags... | 00:12 |
gnarface | Afdal: in the source directory, there isn't by chance an automake or autogen script or something like that in place of ./configure, is there? | 00:12 |
* gnarface just assumed it predates mame using that but didn't check | 00:12 | |
fluffywolf | it's not that old if it wants c++11. lol | 00:14 |
fluffywolf | I mean, the c++11 spec is only ten years old, as you might guess from the 11... | 00:15 |
gnarface | yea i guess not, and actually it wanted a newer libjpeg than was in chimaera | 00:15 |
gnarface | but the point is it's old enough to default to python2 | 00:15 |
fluffywolf | and no real software started using the new spec the day it came out. | 00:15 |
fluffywolf | figure out how to properly configure it. | 00:16 |
gnarface | Afdal: we might have missed an early step if there's a ./autosomething script in the src directory you're supposed to run first to generate the ./configure script... that's not common but i've seen it before in places, not sure if i remember it being a mame thing or not | 00:18 |
gnarface | Afdal: try running "ls -l auto*" in the directory the makefile is in | 00:19 |
Jjp137 | nah I have the source downloaded, and the readme says "If you're on a *nix system, it could be as easy as typing `make`" | 00:19 |
gnarface | alright, noted Jjp137 | 00:20 |
fluffywolf | link to source? | 00:20 |
gnarface | Afdal: nevermind that last one | 00:20 |
fluffywolf | I don't even know what we're working on. lol | 00:20 |
Jjp137 | https://www.mamedev.org/oldrel.html (version 0.160) | 00:21 |
fluffywolf | why do you need the old version? | 00:21 |
fluffywolf | holy fuck that's a big file. | 00:22 |
* fluffywolf downloads it to a linode instead of at home, since it's too big | 00:22 | |
Jjp137 | reasoning: http://reisenweber.net/irclogs/libera/_devuan/_devuan.2021-11-09.log.html#t2021-11-09T22:04:59 | 00:23 |
gnarface | fluffywolf: replay files | 00:23 |
gnarface | fluffywolf: incompatible with the new version, apparently | 00:23 |
gnarface | fluffywolf: (overarching goal is to screencap them with ffmpeg so this old version can be ditched once and for all) | 00:24 |
fluffywolf | ... the zip file seriously contains nothing but another zip file. | 00:24 |
fluffywolf | lol | 00:24 |
fluffywolf | did you go through the makefile? | 00:25 |
fluffywolf | # uncomment to compile c++ code as C++11 | 00:25 |
fluffywolf | # CPP11 = 1 | 00:25 |
* gnarface didn't look | 00:25 | |
Jjp137 | well we'll wait for Afdal I guess ^ | 00:26 |
fluffywolf | I don't know why they'd have files that only compile as c++11, then make it a configuration option, but that'd be a good place to start. | 00:27 |
fluffywolf | I don't have enough of a build environment to actually try doing anything with it on my linode. | 00:27 |
adhoc | what are you building ? | 00:27 |
gnarface | i would have to assume it has something to do with the test compiler being the windows one | 00:27 |
Jjp137 | maybe a past Qt version tolerated it idk | 00:28 |
adhoc | morning all | 00:28 |
gnarface | adhoc: mame 0.160 on chimaera | 00:28 |
adhoc | mame ... the archade machine emulator ? | 00:28 |
gnarface | yea | 00:28 |
adhoc | neat =) | 00:28 |
fluffywolf | "To compile MAME, you need a C++17 compiler and runtime library. We support building with GCC version 7.2 or later " wow, they really like using new c++ features. | 00:29 |
adhoc | is/was there a debian build script for that ? | 00:29 |
adhoc | fluffywolf: that they do. c++ folk in my old work were always pushing the versions up... | 00:30 |
adhoc | we have gcc 10 on chimaera, right? | 00:30 |
Jjp137 | yeah | 00:30 |
fluffywolf | I learned c++ more than two decades ago, before they had any of this stuff. heh. | 00:31 |
gnarface | adhoc: the problem is it's an old version, there's already a package for it in chimaera, but it's not compatible with Afdal's replay files | 00:31 |
adhoc | ah | 00:31 |
adhoc | are there tools to port the replay files forward to the new version ? | 00:32 |
gnarface | no idea | 00:32 |
fluffywolf | using the debian build scripts from an older packaged version with the exact version might deal with some of the dependency issues and compiler flags and cra. | 00:33 |
fluffywolf | crap | 00:33 |
gnarface | hmm, an interesting idea | 00:34 |
gnarface | i think we didn't expect to be this far down the rabbit hole | 00:34 |
gnarface | if it has a ./debian directory at the top level there's a chance you could do it easily i think | 00:35 |
adhoc | there are always other options | 00:35 |
fluffywolf | install windows in a vm and use the binary. :) | 00:35 |
adhoc | if the older version of the tool for older replay files is still available, why not spin that up on a vm or container of an old version of devuan ? | 00:35 |
fluffywolf | I still use glib and gtk+ 1.2.10 here, which I have to tweak to make compile on a modern system, but they still do. | 00:36 |
fluffywolf | with tweaking, that is. | 00:36 |
gnarface | adhoc: this was supposed to be faster, maybe now we should have | 00:39 |
gnarface | adhoc: user wanted to specifically avoid having to set up and manage containers | 00:39 |
adhoc | containers are work | 00:40 |
adhoc | they are also a neat way to package up versions of software that don't fit nicely on your ideal platform | 00:40 |
adhoc | i run chimaera containers on beowulf, and vice-versa | 00:41 |
adhoc | also a bunch of other things i don't want to spray depencencies on local machines, or machines with limited storage | 00:41 |
adhoc | VMs or physical | 00:42 |
adhoc | local kubernetes infrastructure or things in the cloud | 00:42 |
adhoc | it has taken me a loooong time to get comfortable with using containers, really finding the corner cases where they are actually appropriate | 00:44 |
adhoc | now getting into the bowels of it, grokking how to build them from scratch | 00:45 |
Afdal | <Jjp137> nah I have the source downloaded, and the readme says "If you're on a *nix system, it could be as easy as typing `make`" | 01:30 |
Afdal | that's the best part XD | 01:30 |
adhoc | *could* | 01:32 |
Afdal | removed that bit about qt debugging and compiling again now | 01:33 |
Afdal | we'll see what happens... | 01:33 |
Jjp137 | you removed just the #, right? | 01:34 |
Afdal | yeah | 01:34 |
Afdal | While we're on the subject of compiling emulators | 01:36 |
Afdal | I've always wanted to compiled ZSNES | 01:36 |
Afdal | but it's written in x86 assembly | 01:36 |
Afdal | and last I checked it's rather difficult to get the right build environment in x64 systems | 01:37 |
Afdal | Maybe after compiling MAME makes me a pro compiling athlete I'll finally give that a go | 01:41 |
adhoc | a x86-64 machine can run 8086 assembly, but not in protected mode ;) | 01:41 |
adhoc | how much x86 assembly is in ZSNES ? | 01:42 |
Afdal | quite a bit I think | 01:42 |
Afdal | it's why it's so fast | 01:42 |
adhoc | there are machine code to assembly dissasemblers | 01:42 |
adhoc | and also assembly to C translators | 01:42 |
fluffywolf | does a snes emulator need to be fast in the last 20 years? | 01:43 |
adhoc | just emulate an x86 machine =P | 01:43 |
Afdal | Actually ZSNES has a special niche still | 01:44 |
Afdal | it's not the speed that's so useful | 01:44 |
adhoc | does ZSNES run on DOS? mayebe FreeDOS ? | 01:44 |
Afdal | it's its impressive netplay system | 01:44 |
Afdal | It works fine in Wine | 01:44 |
Afdal | I'd just like a native build | 01:44 |
adhoc | oh, so its a win32 app ? | 01:45 |
* fluffywolf doesn't know much about games | 01:45 | |
Afdal | No there are Linux builds | 01:45 |
Afdal | it's just | 01:45 |
Afdal | nobody compiles the older versions | 01:45 |
Afdal | which had the netplay | 01:45 |
Afdal | there's a very specific old version that has extremely robust desync-free network play | 01:45 |
Afdal | This seems to be doing over the entire compile after removing that debugging support flag, so this'll probably take another 40 minutes to see results again | 01:49 |
Afdal | Ooh actually I hope "debugging support" doesn't include the cheat engine for things like freezing variables or watching memory addresses in games | 01:49 |
Afdal | That actually is important to me | 01:49 |
fluffywolf | I wouldn't think so. | 01:51 |
Afdal | I've heard that stuff referred to as a debugging tool before | 01:51 |
Afdal | ah there, it failed again | 01:54 |
Afdal | whaddya think https://paste.debian.net/hidden/1a6b9fb1/ | 01:56 |
Afdal | something about LD this time | 01:57 |
fluffywolf | I usually think of, when it comes to compiling things, debugging support meaning some combination of compiling with debugging symbols and -O0, and including code to log internal things based on some command line or environment flags. | 01:57 |
Afdal | A lotta undefined reference errors | 01:58 |
Afdal | that's a gcc version probably rite | 01:58 |
Afdal | version problem probably* | 02:00 |
fluffywolf | I would think it's going to be a library or such, not gcc | 02:01 |
gnarface | looks like glibc | 02:03 |
gnarface | i think glibc version | 02:03 |
gnarface | maybe looking for 2.2.5 and finding something incompatible? | 02:03 |
Afdal | wait... what's the difference? | 02:03 |
fluffywolf | that object member is provided by the mame source. it's very unlikely a gcc issue. | 02:03 |
fluffywolf | is that the entire compile output? | 02:03 |
gnarface | hmmm | 02:04 |
fluffywolf | something that includes drivenum.h didn't get compiled and linked in. | 02:04 |
Jjp137 | does obj/sdl64/mame/mame/drivlist.o exist, and if so, how big is it? | 02:04 |
fluffywolf | probably an earlier error | 02:04 |
gnarface | i wonder if we've changed enough that a "make clean" would have been in order? | 02:04 |
Afdal | no that's not the whole thing | 02:04 |
Afdal | should I pipe it to an error log again | 02:05 |
gnarface | maybe | 02:05 |
fluffywolf | yes. 2>&1 | tee foo.log is my favorite way of doing that. | 02:05 |
fluffywolf | but, a make clean might indeed be in order... but you'll have to wait 40 minutes again. | 02:05 |
fluffywolf | hrmm, we could do the cable internet provider thing, and tell people to make clean and call back instead of reboot the modem and call back? :) | 02:06 |
Afdal | h-here I go... | 02:06 |
gnarface | but... the thing i see is it fails during linking though, not building, and the first thing in the linking warnings is a warning about the native libc6 overwriting the definition of what appears to be the same class that then gets complained about having missing/undefined symbols, leading to the fail... | 02:06 |
gnarface | i admit i don't really understand what's going on here but it looks suspicious | 02:06 |
Afdal | what does that 2>&1 gibberish do again | 02:07 |
fluffywolf | are you making with -j <number of cores + 1>? (i.e. make -j5) | 02:07 |
Afdal | nope | 02:07 |
Afdal | nothing fancy | 02:07 |
Afdal | should I multithread the compile? | 02:07 |
fluffywolf | 2>&1 redirects your standard error stream to your standard output stream, so you can pipe both to another program at once. | 02:08 |
gnarface | Afdal: rough translation "send errors to the same place output was already going" (so they don't get left behind by the | ) | 02:08 |
Afdal | Can you explain it to me in parts... | 02:08 |
Afdal | what's the 2 signify | 02:08 |
fluffywolf | if you have more than one physical core, you can substantially improve compile time. | 02:08 |
fluffywolf | 2 is standard error | 02:08 |
fluffywolf | the fd | 02:08 |
gnarface | Afdal: the text coming to the terminal is actually a combination of errors and regular text output, coming from TWO separate streams, rather than one | 02:08 |
gnarface | Afdal: by default there's no visual distinction done by the terminal, but if you redirect one of them you want to keep them together usually, that's what the "2>&1" makes sure happens | 02:09 |
Afdal | I've seen output with lots of errors before and a simple &| tee was enough to grab them | 02:09 |
gnarface | i've never seen that syntax before | 02:10 |
gnarface | doesn't mean it won't work | 02:10 |
gnarface | but... it might have been a specialized build system too that only uses stdout instead of stderr and stdout | 02:10 |
gnarface | wouldn't that background it though first? | 02:11 |
Afdal | Wait does does an ampersand signify in bash? | 02:11 |
Afdal | what* | 02:11 |
gnarface | it does different things in different contexts i guess | 02:11 |
Afdal | -_- | 02:11 |
gnarface | at the end of the command-line it backgrounds the command | 02:11 |
gnarface | if you write it as &1 that means "where 1 is going also" | 02:12 |
gnarface | the > is the literal text readirect | 02:12 |
gnarface | *redirect | 02:12 |
Afdal | oof, so esoteric | 02:12 |
gnarface | so stdout is #1 and and stderr is #2 as fluffywolf waid | 02:12 |
Afdal | does FISH have less byzantine syntax | 02:12 |
gnarface | *said | 02:12 |
gnarface | so 2>&1 sends 2 to where you send 1 | 02:13 |
gnarface | which is only necessary if you're redirecting 1 somewhere, like with another > or | | 02:13 |
Afdal | I think I understand now | 02:13 |
gnarface | tee is nice because you can use it to copy the output to two places at once | 02:13 |
Afdal | all right so I have eight cores | 02:14 |
Afdal | let's try -j4... | 02:14 |
critr | wow, even i understood that. thanks, gnarface | 02:14 |
gnarface | np | 02:14 |
fluffywolf | -j9 | 02:14 |
Afdal | Does that do something :o | 02:14 |
fluffywolf | uses the other four too. :P | 02:15 |
Afdal | beyond j8 | 02:15 |
gnarface | i mean, it probably won't help extra | 02:15 |
fluffywolf | and having one extra can make it a little faster since it can run while one of the others is waiting for i/o. | 02:15 |
Afdal | I had a bad experiencing compiling something with all my cores once so I'm afraid to use them all | 02:15 |
fluffywolf | i/o is usually a fairly small part of compiling, so it won't make a huge speedup, but will make a little. | 02:15 |
Afdal | That was when my last CPU melted ~_~ | 02:15 |
gnarface | you could overheat easily like this if your cooling solution is inadquete... -j4 is plenty | 02:16 |
fluffywolf | that's not the compiler's fault. that's the cooling's fault. heh. | 02:16 |
gnarface | inadequate* | 02:16 |
fluffywolf | also, any modern cpu will throttle before melting. | 02:16 |
Afdal | it already had problems but that was the final straw | 02:16 |
fluffywolf | the days of exploding dies are past... | 02:16 |
Afdal | Actually, I had to -disable- throttling on that particular CPU to get a stable system | 02:17 |
fluffywolf | oh, so it was user error too. :P | 02:17 |
gnarface | Afdal: i don't blame you for being wary - i don't trust hardware overheat protect defaults much either. these people are in the business of selling hardware and just because the cpu isn't critical yet doesn't mean they've thought to protect the video ram | 02:18 |
Afdal | nah either the CPU or the motherboard was broken from the beginning | 02:18 |
Afdal | might have been both actually | 02:18 |
fluffywolf | an ampersand just means file descriptor. it can have some automagic defaults and special values other than just a number. | 02:19 |
Afdal | I'm still using that motherboard | 02:20 |
Afdal | and in fact it was an obstacle for ages to me installing other distros | 02:20 |
fluffywolf | I think in that context is means to duplicate it rather than replace it, or something. | 02:20 |
Afdal | and why I felt the need to install Devuan over ssh | 02:20 |
* fluffywolf is not a bash expert. also, is not sure anyone can be a bash expert, since bash is friggin' huge these days... | 02:20 | |
Afdal | But surprisingly, amazingly, it seems some sort of software or kernel fix on Devuan has finally resolved my issue and I can actually allow my screensaver to power off my monitor without it causing my whole system to freeze up | 02:21 |
gnarface | hehe | 02:21 |
adhoc | fluffywolf: you can learn enough useful bits of bash =) | 02:22 |
fluffywolf | upgrading to chimaera has caused this box to become slightly unstable somewhere in the power management stuff, which I need to track down at some point. | 02:22 |
adhoc | debian has always been flakey on laptops | 02:23 |
adhoc | debian/devuan has always been good on servers ;) | 02:23 |
fluffywolf | if it switches from a/c to battery while the screen is blanked, it doesn't always wake up. | 02:23 |
adhoc | fluffywolf: so it is probably more to do with the hardware and kernel support | 02:23 |
adhoc | fluffywolf: yup, this is why i don't bother with linux on laptops any more | 02:24 |
Afdal | lol | 02:24 |
Afdal | Linux is the only thing that makes laptops bearable for me | 02:24 |
adhoc | makes ones backpack lighter ;) | 02:24 |
fluffywolf | googling that error suggests that you might need to add -no-pie to your cflags, but I haven't read up enough on it to say that with any confidence. | 02:24 |
adhoc | Afdal: desktops FTW! | 02:24 |
Afdal | still sucks tho | 02:25 |
fluffywolf | adhoc: I've had good luck. I pretty much only use laptops now. | 02:25 |
* adhoc grew up in the era of "you can't trust a computer you can lift" | 02:25 | |
Afdal | going from my custom built desktop mechanical keyboard with uber tactility to a trashbin tier chiclet keyboard on a laptop | 02:25 |
adhoc | ew | 02:25 |
fluffywolf | I mostly use toughbooks; they have pretty good keyboards. | 02:26 |
* adhoc has been enjoying a number of very noisey mechanical keyboards recently | 02:26 | |
Afdal | and those absolutely horrible touchpads they make these days... | 02:26 |
adhoc | fluffywolf: we used to use them at work (previous job) and we supported freebsd on them, they were solid. | 02:26 |
fluffywolf | they're not as good as my unicomp, which is in turn not as good as the old model Ms that I wish I still had, but they're rather good for laptop keyboards. | 02:26 |
fluffywolf | the worst laptop keyboard I have ever used is my hp stream 11. it is utterly awful in every possible way. even the controller is awful - if you type fast, it only gets every other keystroke! | 02:27 |
fluffywolf | I have no idea how they managed to fuck that up so badly. | 02:27 |
fluffywolf | if you type "password", it always comes out as "pasword". I think they're doing some kind of debounce to make up for utterly horrid switches. | 02:27 |
Afdal | I got myself a nice System76 machine but even they, who deal with enthusiasts, couldn't resist a lame chiclet board | 02:27 |
Afdal | it's probably one of the better chiclet boards out there | 02:28 |
Afdal | but it's still a chiclet board | 02:28 |
fluffywolf | also, whomever decided that rather than having buttons, you should click the entire touchpad down, needs to be beaten repeatedly. | 02:28 |
Afdal | indeed | 02:28 |
Afdal | the buttons on mine are completely garbage with barely any tactility | 02:29 |
Afdal | I'm thinking I may have to mod them somehow | 02:29 |
Afdal | tap clicking is the worst idea ever invented and it blows my mind whenever I try a desktop environment that has it on by default | 02:29 |
fluffywolf | more googling still makes me think the relocation error is a result of a missing object, not the root cause. | 02:30 |
Afdal | Whoa... I think this compile actually finished this time | 02:30 |
fluffywolf | yay! | 02:30 |
Afdal | so the make clean was necessary | 02:30 |
fluffywolf | and it didn't take 40 minutes, either. :P | 02:30 |
Afdal | let's see if it werks... | 02:30 |
fluffywolf | using half your cpu instead of an eighth of the cpu. :) | 02:30 |
Afdal | it works \:O/ | 02:31 |
Afdal | a little ugly on the text side but whatever | 02:31 |
Afdal | I can't habeeb it, I actually compiled MAME | 02:31 |
fluffywolf | I've been compiling with -j since my dual p3-866, the first real multi-cpu box I owned.... | 02:31 |
Afdal | wait lemme make sure it runs replay files now | 02:31 |
* fluffywolf waits until it turns out 0.161 is the one for the files, not 0.160. :P | 02:31 | |
adhoc | fluffywolf: make -j ... | 02:32 |
* adhoc remembers the first dual p-pro box | 02:32 | |
Afdal | uh | 02:32 |
Afdal | crap | 02:33 |
Afdal | my replays are desyncing | 02:33 |
Afdal | nooooooo | 02:33 |
adhoc | might have been back in the HUMBUG days | 02:33 |
gnarface | can't you turn up the clockspeed or is that dosbox? | 02:33 |
fluffywolf | do the replays use wall time instead of some internal cycle time, and thus never work on anything but the original box and compile, or something? | 02:33 |
adhoc | Afdal: are they in avi format ? =P | 02:33 |
Afdal | they're input files, not videos | 02:34 |
Afdal | I need to dump them to video later | 02:34 |
gnarface | Afdal: i have some ffmpeg ideas and notes for that | 02:34 |
gnarface | Afdal: check to make sure mame is configured right, defaults might not be optimal | 02:34 |
Afdal | I'm a pro ffmpeg encoder ;y | 02:34 |
fluffywolf | adhoc: my dual p3-866 was really nice, and easily beat the first generation of p4s. | 02:34 |
fluffywolf | I had a whopping 2GB of ram in it, too. | 02:34 |
gnarface | Afdal: oh, you might want to check your old config from the old distro for settings | 02:35 |
Afdal | Well... I have no idea how to figure out how the v0.160 version on Canonical repos was configured :'( | 02:35 |
gnarface | Afdal: just try getting that config and fixing the paths | 02:35 |
Afdal | I'm using that same config now | 02:35 |
fluffywolf | can you still download it from some archive somewhere? | 02:35 |
gnarface | oh hmm | 02:35 |
Afdal | ugh I have no idea what to do here ;_; | 02:37 |
gnarface | Afdal: we even sure you got the right video drivers? | 02:37 |
Afdal | beats me | 02:37 |
gnarface | what video card is it? | 02:37 |
Afdal | RX560 | 02:37 |
Afdal | that's almost certainly not the issue though | 02:37 |
Afdal | this is a compiling consistency issue | 02:38 |
gnarface | maybe we have been over this, you have the firmware-amd-graphics package from non-free? | 02:38 |
Afdal | how do I check that | 02:38 |
gnarface | dpkg -l |grep firmware | 02:38 |
gnarface | this lists packages: dpkg -l | 02:38 |
Afdal | Error: attempt to free untracked memory 0x55f790ed7260 in (null)(0)! | 02:38 |
Afdal | Ignoring MAME exception: Error: attempt to free untracked memory | 02:38 |
gnarface | this cuts out all but the lines that have "firmware" in them: |grep firmware | 02:38 |
Afdal | getting a lot of these errors while running, I don't remember getting them from terminal usage on buntu | 02:38 |
gnarface | yea, well ubuntu had the right versions of everything | 02:39 |
Afdal | maybe I really need to use the right gcc after all | 02:40 |
gnarface | but really | 02:40 |
gnarface | if it's expecting to use opengl | 02:40 |
fluffywolf | errors like that are almost always bugs. | 02:40 |
gnarface | and you don't have firmware-amd-graphics installed, | 02:40 |
gnarface | it will drag performance | 02:40 |
gnarface | not sure how much | 02:40 |
gnarface | but typically lots | 02:40 |
Afdal | Yeah but that's not how input replays work | 02:40 |
gnarface | doesn't it still render the game? | 02:41 |
Afdal | they don't care about your own speed | 02:41 |
Afdal | yeah | 02:41 |
fluffywolf | do the inputs replays use some internel counter, like cpu cycles, or wall clock time, which will never synchronize right except on the original box? | 02:41 |
Afdal | you can speed the game up to 1600% or whatever and input replays will stay in sync | 02:41 |
Afdal | when they're working properly | 02:41 |
gnarface | hmmm | 02:41 |
Afdal | I dunno which of those is which, fluffywolf | 02:41 |
gnarface | maybe i don't understand the problem then | 02:41 |
fluffywolf | stupid question, but are you sure you're running the binary you compiled, not your system one? | 02:42 |
fluffywolf | (assuming you already tried installing it from a package) | 02:42 |
gnarface | yea best double check that... | 02:43 |
Afdal | oh definitely, it won't even let you attempt to play .inp replays from older versions | 02:43 |
fluffywolf | just checking. I've done it too many times. :P | 02:43 |
Afdal | hmm, interesting, this .inp file isn't desynching | 02:44 |
Afdal | maybe it's just one of them that's busted | 02:44 |
gnarface | could they be from multiple versions? | 02:44 |
Afdal | nope | 02:44 |
gnarface | that's a really nice video card fyi, if you don't have firmware-amd-graphics and a bunch of mesa files you're really missing out | 02:45 |
Afdal | mame let's you know which version an input file was recorded in when you try to load it up | 02:45 |
fluffywolf | what game are you playing, for curiosity's sake? | 02:45 |
Afdal | various games | 02:45 |
Afdal | but I mostly try to clogger tough arcade scrolling shooters | 02:45 |
Afdal | so I have things like one-life clears or extreme score plays | 02:45 |
Afdal | in input replay format | 02:45 |
Afdal | that I need to dump to video | 02:45 |
* fluffywolf has never been a gamer | 02:46 | |
fluffywolf | "need" :) | 02:46 |
Afdal | Darius Gaiden, Dimahoo, Raiden, etc. | 02:46 |
fluffywolf | never even heard of those. lol | 02:46 |
gnarface | Afdal: i'm in no way questioning the value of posterity for this stuff. ignore these haters | 02:46 |
Afdal | :3 | 02:46 |
Afdal | what I do find interesting | 02:47 |
Afdal | is that this binary is only 114MB | 02:47 |
Afdal | oh wait I have nothing to compare that too anymore | 02:47 |
* adhoc used to have a Raiden ][ in a stand up arcade cabinet | 02:47 | |
Afdal | since I don't even have the old binary | 02:47 |
adhoc | and a 1942 | 02:47 |
* fluffywolf has never owned a video game device | 02:47 | |
Afdal | I'm gonna single-credit clear Raiden II, one of these days... | 02:47 |
Afdal | workin on the first Raiden first though | 02:47 |
Afdal | I've conquered a lotta scrolling shooters but for some reason I have always found the original Raiden games to be incredibly brutal | 02:48 |
fluffywolf | is the brutality decreased by having a bucket of quarters to put in the machine? | 02:49 |
Afdal | lol | 02:49 |
Afdal | I remember people in my old arcade would actually like | 02:49 |
Afdal | stick a stack of quarters right next to the monitor while they were playing | 02:49 |
fluffywolf | that is, if you have to put in money to continue, they might _want_ you to die a lot. :P | 02:49 |
Afdal | no one knew that you were only supposed to use one... | 02:49 |
Afdal | uh so firmware-amd-graphics | 02:51 |
Afdal | dpkg -l | grep firmware gives me a lot of entires | 02:51 |
gnarface | oh? | 02:51 |
gnarface | i usually only have a couple | 02:51 |
Afdal | firmware-amd-graphics 20190114-2 all Binary firmware for AMD/ATI graphics chips | 02:51 |
Afdal | oh there it is | 02:51 |
gnarface | you got it | 02:52 |
Afdal | most of them are wireless card drivers | 02:52 |
Afdal | Can never be too careful | 02:52 |
gnarface | chances are you got everything then, but for opengl and video encoding/decoding acceleration stuff you'll probably also need a bunch of the mesa packages | 02:53 |
gnarface | you should see a bunch of packages come up if you run: dpkg -l |grep mesa | 02:53 |
Afdal | yeah I've got all those | 02:53 |
Afdal | but again, if games ran like turds or something due to poor drivers | 02:53 |
Afdal | MAME would just run the game real bad, but the input replay still stays in sync | 02:54 |
Afdal | that's generally how it works | 02:54 |
gnarface | yea like i said, i hadn't understood the actual problem | 02:54 |
fluffywolf | troubleshooting that might need the help of people familiar with mame, then. | 02:55 |
Afdal | yeah I'll try not to pollute the chat in here anymore | 02:55 |
Afdal | although they'll probably just say something like "just get the latest version bro" | 02:56 |
Afdal | Oh that's interesting, I'm running these exact same input replay again now and it's not desyncing like it did earlier | 02:56 |
Afdal | well if it only happens sometimes I can live with that | 02:56 |
gnarface | you might want to try it with the cpu governor set to "performance" | 02:57 |
gnarface | just as a control test to eliminate powersaving features as a possible issue | 02:57 |
Afdal | CPU governor? | 02:57 |
fluffywolf | that sounds suspiciously like they use wall time not frames or some other design sillyness. | 02:57 |
Afdal | yisss I think this is gonna work after all \:O/ | 02:59 |
fluffywolf | yay! | 02:59 |
Afdal | Now how do I package something up nicely with checkinstall so its library dependencies are self-contained | 02:59 |
Afdal | so I can future-proof this | 02:59 |
Afdal | since according to gnarface you don't actually need appimages or snaps or flatpaks to do that... | 03:00 |
gnarface | well what i said you should do is just leave the dependencies field blank | 03:00 |
gnarface | so the package doens't require anything | 03:00 |
Afdal | oh that's the default behavior of checkinstall? | 03:00 |
Afdal | I had no idea | 03:00 |
fluffywolf | I can't help with this... I know a lot more about compiling than about installation tools. | 03:01 |
gnarface | yea, it's pretty self-explanatory, just run "checkinstall make install" and follow the on-screen instructions | 03:01 |
gnarface | Afdal: if you have the native mame packages you might want to uninstall them first | 03:03 |
Afdal | Oh? | 03:04 |
gnarface | well it might not matter but it might confuse you even if it doesn't break things | 03:04 |
gnarface | to have two mame instances installed | 03:04 |
gnarface | on presumably different path prefixes | 03:04 |
Afdal | oh maybe I don't even want it installed actually | 03:05 |
Afdal | this binary file is working fine for me | 03:05 |
Afdal | but I was thinking I might like to package it up anyway | 03:05 |
gnarface | if you're just gonna make a batch of videos then migrate to the stock stable version in the repos after that, i don't see any reason to install it | 03:05 |
Afdal | ugh, getting some segmentation faults on certain games with this build | 03:09 |
Afdal | guess the compile isn't perfect yet after all | 03:09 |
Afdal | wow, quite a lot of games | 03:10 |
Afdal | okay, guess I still got some compiling tunage to do | 03:10 |
fluffywolf | old versions might have bugs... | 03:11 |
Afdal | yeah but not these sorts of bugs | 03:11 |
Afdal | which I never experienced before | 03:11 |
Afdal | So uh, how do I compile with a different version of gcc or glibc? | 03:11 |
fluffywolf | that can be pretty difficult. | 03:12 |
Afdal | -_- | 03:12 |
fluffywolf | a different glibc probably means a vm or at least a chroot. | 03:12 |
Afdal | oof | 03:12 |
Afdal | maybe I should come back to this another time | 03:12 |
fluffywolf | trying to downgrade the system one would break installed software, and trying to get two versions at once I don't think is something debian will do with packages. | 03:13 |
Afdal | I've definitely managed multiple versions of gcc on *buntu before | 03:13 |
Afdal | not that I remember how | 03:13 |
fluffywolf | yes, but multiple glibc too? | 03:14 |
Afdal | what's glibc @_@ | 03:14 |
fluffywolf | gcc is usually easier, apt-get install gcc-whateverversion | 03:14 |
Afdal | no really | 03:14 |
Afdal | what is it | 03:14 |
Afdal | I get it confused with gcc | 03:14 |
fluffywolf | do you do any programming? | 03:14 |
Afdal | y-yes | 03:14 |
Afdal | but not in C | 03:14 |
Afdal | oh wait gcc is a set of compilers | 03:15 |
Afdal | while glibc is a set of C libraries | 03:15 |
Afdal | okay | 03:15 |
fluffywolf | libc, and glibc, are the system libraries that provide all the standard functions. | 03:15 |
fluffywolf | basic things like printf() all the way through advanced linking and crap. | 03:15 |
fluffywolf | however, I doubt either of these are the cause of your problems. both gcc and glibc are very stable and tend not to cause things to break. | 03:16 |
fluffywolf | it's far more likely to be some other library. | 03:16 |
Afdal | maybe I should peruse the output log pertaining to the driver used by some of these games that are segfaulting | 03:17 |
fluffywolf | the reason to have multiple gccs is when something needs to link with a third-party binary that only works with a specific gcc version. | 03:17 |
fluffywolf | (at intermediate steps of the compiling process, you can't mix files from different gcc versions) | 03:17 |
fluffywolf | earlier you pasted a memory usage error; memory usage errors like that are very common causes of segfaults. | 03:19 |
Afdal | hmm | 03:21 |
Afdal | what else could cause those but incorrect glibc stuff | 03:21 |
fluffywolf | any library the program uses. lol | 03:21 |
Afdal | o-oh | 03:22 |
fluffywolf | video output libraries (sdl, opengl, etc, whatever it uses), math libraries, optomized standard routine libraries, image libraries, file formats libraries, gui widget libraries, sound libraries,... | 03:23 |
fluffywolf | glibc is _very_ stable. | 03:23 |
fluffywolf | stable both in that it doesn't have bugs, and stable in that they don't change anything in it without a really damn good reason. | 03:23 |
fluffywolf | unlike, say, python, where they entirely break everything with every single minor version bump. | 03:24 |
Afdal | lol | 03:25 |
fluffywolf | compile with debugging support, attach gdb, see where it crashes... but you're going to be good with C by the time you fix if, if you take that route. | 03:25 |
Afdal | ;_; | 03:26 |
fluffywolf | also, since this is an old version, it may well be a bug in mame itself that you just weren't triggering before, than has since been fixed... | 03:26 |
fluffywolf | "mame crashes when running on systems with X hardware" is a perfectly reasonable bug type that gets fixed. | 03:26 |
Afdal | I used this same hardware on these same games with the same mame version in the past | 03:28 |
Afdal | that's why I have input replays for them... | 03:28 |
fluffywolf | then "mame crashes when foo library is installed", too. heh. | 03:28 |
fluffywolf | the type of memory usage errors you were showing before very strongly suggest a bug in mame. | 03:28 |
fluffywolf | that bug may be worked around with some combination of library versions, I have no idea... | 03:29 |
fluffywolf | if you don't want a vm, you could do a fresh install of whatever distribution you were running back then onto a spare hard drive or a usb key, so you have exactly what you had back then. | 03:30 |
fluffywolf | memory management issues are very common in C code. it's one of the main reasons that while I love C, I think it's time we use it for fewer things... because so many of those memory management bugs don't just cause crashes, but also cause security holes. | 03:31 |
Afdal | ugh #mame is a registered voice only channel on Libera | 03:32 |
Afdal | I HATE those -_- | 03:32 |
fluffywolf | lol | 03:33 |
fluffywolf | registering is pretty easy... | 03:36 |
* fluffywolf pets the now-registered Afdal | 03:42 | |
Afdal | :'} | 03:43 |
fluffywolf | sigh, why is php's array_merge so horribly broken? oh, yeah, php... | 03:50 |
Afdal | People still use that garbo? | 03:51 |
Afdal | I understand if people feel stuck with Javascript since it's the only clientside game in town | 03:51 |
Afdal | but your options for server side could be literally anything... | 03:51 |
fluffywolf | "According to W3Techs' data, PHP is used by 78.9% of all websites with a known server-side programming language. " | 03:55 |
Afdal | 78.9% of everything is trash... | 03:55 |
fluffywolf | lol | 03:55 |
Hydragyrum | >with a known server-side programming language | 04:03 |
Hydragyrum | because most other things won't be easily determined from just looking at the website from the client perspective | 04:04 |
Hydragyrum | python, c, ruby, etc. cgi won't really show as being in that language for instance | 04:05 |
fluffywolf | why do library functions that take a reference as an argument need to be called with &$foo, but this is a syntax error if you call your own functions that take a reference as an argument, and instead want just $foo? | 04:27 |
fluffywolf | oh, yeah, php.... | 04:27 |
Afdal | oh hay I found a *buntu .deb file after all | 04:48 |
Afdal | Woo, and it works \:o/ | 04:50 |
Afdal | all I had to do was symlink that old libjpeg8 library | 04:50 |
gnarface | heh | 04:52 |
adhoc | fluffywolf &$foo, in which language ? | 04:52 |
Afdal | All that effort compiling | 04:53 |
Afdal | and I'm denied the satisfaction -_-7 | 04:53 |
gnarface | there might be ubuntu-specific patches on that one | 04:53 |
Afdal | Maybe, someday... I'll compile something really complicated and tricky and work through all the problems successfully | 04:53 |
gnarface | maybe they fixed some stuff | 04:53 |
Afdal | Someday ;_;7 | 04:53 |
Afdal | Although I did find and get some bugs fixed in GRUB recently | 04:54 |
Afdal | GRUB ain't no MAME tho | 04:54 |
fluffywolf | <fluffywolf> oh, yeah, php.... | 04:59 |
Afdal | thanks for the tips everyone | 04:59 |
Afdal | was a good learning experience | 04:59 |
fluffywolf | so it was libjpeg making it crash, not glibc? :) | 05:02 |
fluffywolf | oh, you mean you used a ubuntu package. | 05:04 |
fluffywolf | ok, enough php for one night. got the section I was working on working. | 05:08 |
Yonle | Hello world! | 08:11 |
Yonle | By the way is that ok to flash devuan to usb with `bs=4M`? | 10:08 |
Yonle | In the wiki, it says "bs=1M" | 10:09 |
Yonle | How can i change init system? | 10:46 |
debdog | I can't imagine 4M vs. 1M matters | 10:53 |
Yonle | debdog, Well, using 4M leads me having a lot of corrupted squashfs error. Fixed after reflashing | 10:55 |
humpelstilzchen[ | probably has nothing to do with the 4M | 10:58 |
user_____ | I have a stumper question: I have an older USB stick with a bootable Devuan on it, nowhere in grub or isolinux menu could I find the VERSION. I am loathe to dig in the live image for a splash screen. Can someone help id it? | 15:43 |
user_____ | live/vmlinuz: 1693d18c97650fc02ed3f8cd0c116a7565c13c22 vmlinuz | 15:44 |
user_____ | Date is 2020-05-30 -- I assume this is the date in the iso, since it is ro, not when I dd'd it to the stick. | 15:44 |
user_____ | I'll be waiting for an answer. Also, thanks if you point me to a way to do this on my own. Repo with used kernels and SHA1 sums? | 15:45 |
djph | user_____: why not just boot it and look at /etc/os-release ? | 15:49 |
user_____ | No free machine to boot on and no free kvm for a decent speed vm boot | 16:12 |
user_____ | <aside> when making ISOs for release: please copy /etc/os-release into /live or such on the iso. | 16:12 |
user_____ | fdisk -l /dev/sdc -> /dev/sdc1 * 1.1G id0 Empty ;; /dev/sdc2 1.4M id0xef EFI (FAT-12/16/32) | 16:14 |
user_____ | filesystem.squashfs is 1.1GB in the iso | 16:15 |
user_____ | I am going to overwrite this media soon, just curious if there is a way to id it without booting. | 16:16 |
user_____ | I notice Thunar in xfce4 on Beowulf does not show the EFI partition in the partition list side pane. | 16:23 |
user_____ | Is there a way to turn it on, so it shows? | 16:23 |
rwp | user_____, Looking in the media's /etc/os-version should say something. If not check /etc/apt/sources.list file. | 16:27 |
user_____ | That would mean unpacking the 1.1G squashfs, which I what I am avoiding now. Is there a way without unpacking? | 16:27 |
rwp | Hmm... I don't know. Seems like there is always a README file in a live boot area somewhere. | 16:28 |
Yonlecoder | Well, Have you reflash the ISO before? | 16:29 |
user_____ | Say again? | 16:30 |
Yonle | Well | 16:31 |
Yonle | *shrug* | 16:31 |
rwp | user_____, I just checked the refracta live for Devuan and it has a top level README.txt file. So if yours is missing it then I deduce it is not a Devuan live image but some other system. | 16:32 |
user_____ | There is no README anywhere, the splash pngs are all Devuan branded, no version | 16:32 |
user_____ | Sorry ;) | 16:32 |
user_____ | I must have gotten a "special edition" somewhere. | 16:33 |
user_____ | May 2020 vintage | 16:33 |
rwp | user_____, Hmm... I pulled the refracta minimal-live for beowulf just now and it has nothing in the top level. So maybe one of those? I don't know. | 16:38 |
user_____ | "one of those" is highly informative ;-) Thanks! ;-) | 17:01 |
peterrooney | is it hard to mount iso images? | 17:06 |
debdog | mount -o loop file.iso /mnt | 17:07 |
debdog | as root, I think | 17:08 |
rwp | It's an ISO, so read-only, so to avoid the read-only warning add "ro" to that option list. As root. mount -o ro,loop file.iso /mnt | 17:08 |
rwp | user_____, That "maybe" was pretty definite too. :-) | 17:09 |
user_____ | The question was, how to find out w/o decompressing. The iso is in a USB stick which is mounted. | 17:21 |
peterrooney | user_____: what's in /dists ? | 17:33 |
user_____ | /dists is not present unless decompressing ... | 17:36 |
rwp | user_____, I had forgotten but one can mount a squashfs without decompressing it. Simply mount it -o ro,loop just like the iso. | 17:38 |
rwp | Need two mount points. I'l assume /mnt/iso and /mnt/squashfs for the two. Then: | 17:39 |
rwp | mount -o ro,loop devuan_beowulf_3.1.1_amd64_minimal-live.iso /mnt/iso | 17:39 |
rwp | mount -o ro,loop /mnt/iso/live/filesystem.squashfs /mnt/squashfs | 17:39 |
rwp | At that point /mnt/squashfs is available for browsing. | 17:39 |
rwp | cat /mnt/squashfs/etc/os-release | 17:40 |
user_____ | https://termbin.com/c4rs -- this is what I see, squashfs not extracted. | 17:42 |
user_____ | rwp: I know how to do that, the question was, how to do it without... | 17:42 |
user_____ | Just say it can't be done ;) | 17:43 |
rwp | But I did not decompress it all at once. I think being mounted as a squashfs is incremental. | 17:43 |
user_____ | I think you may be wrong. | 17:43 |
user_____ | https://www.kernel.org/doc/html/latest/filesystems/squashfs.html | 17:44 |
rwp | What can I say? It worked for me. It was fast, immediately responding. I didn't see any system memory stress through the process. (shrug) | 17:45 |
user_____ | ok | 17:46 |
user_____ | PRETTY_NAME="Devuan GNU/Linux 3 (beowulf)" | 17:48 |
rwp | There you go! :-) | 17:48 |
ama | Hello. Is it possible to run another distribution with SystemD on a container (LXC) on Devuan? I have a server that someone wants to replace the nice current setup (Devuan with Devuan containers) with Ubuntu. The alternative I would like to provide would be to keep it like it is now and set up an Ubuntu conainer (they ar purchasing a software which is only supported if they run it on Ubuntu, alas). | 19:10 |
UsL | funny license.. "Only run on Ubuntu." Check. | 19:11 |
ama | Yes, it badly sucks. But they need that comercial program and that's the condition the company has. :-( | 19:13 |
UsL | I can't help you with containers much, but I'm sure someone will chip in. Hang around. | 19:14 |
ama | I will, thank you! :-) | 19:16 |
bb|hcb | ama: I am also not too well aware with containers, but they should provide enough isolation to be able to run any Linux that is compatible with the host kernel | 19:17 |
ama | Even with SystemD you think, bb|hcb? That'd be so great... | 19:20 |
rwp | I hate to post an "I don't know" but I don't but I do think that the entire point of containers is to isolate what's in the container from what is outside of it. | 19:23 |
ama | I guess it's possible if a container has its own proccess 0 on top of its kernel.... | 19:23 |
rwp | Therefore I would simply proceed pushing forward with the blind idea that it should work. | 19:24 |
ama | I see, rwp, it sounds reasonable. I should probably try on a test box and see what I end up with... :-) | 19:24 |
bb|hcb | systemd is just another program (no matter how 'good' is it) ;) | 19:25 |
rwp | UsL, It's probably the support contract rather than the license. Unfortunately support contracts often are like that. Lots of software only supported on RHEL for example. | 19:25 |
ama | Yes, rwp, it's the support what they don't get if they run it on anything other thaw Windows or Ubuntu. | 19:26 |
rwp | ama, Testing on a victim system is always a good idea. Don't break a system you depend upon. Break a system that you can throw away and start again with. | 19:26 |
ama | Hahaha, rwp, I love that "victim system" idea. I'll do that, yes, haha. | 19:26 |
ama | I always keep a couple of the last decomissioned servers for "victimising" them purposes. LOL | 19:28 |
rwp | Good plan! I'll note that it is possible to run KVM nested. Which means can set up a VM that itself hosts VMs, such as LXC containers. https://docs.fedoraproject.org/en-US/quick-docs/using-nested-virtualization-in-kvm/ | 19:29 |
rwp | Not a performance option. But good for testing purposes. | 19:29 |
ama | Vintimising a container! Cool idea! Haha | 19:30 |
bb|hcb | ama: you have two options - run a container on main host, or run a kvm on the main host; while nested works, i see no point in doing that | 19:30 |
ama | s/Vintimising/Victimising/ | 19:30 |
rwp | bb|hcb, The point is useful when testing out container hosting infrastructure. Can do that in a VM and not break a host system. | 19:31 |
ama | I think rwp was suggesting nesting for testing purposes only, bb|hcb. Or, at leasr, I have interpreted that way. | 19:31 |
ama | Exactly, rwp, that's what I understood from what you said. | 19:32 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!