UsL | like the pipe key having two places on us keyboards and not on uk keaybords.. Or however it was. | 00:00 |
---|---|---|
UsL | ΒΆ | 00:01 |
Afdal | :o | 00:01 |
UsL | anyway. Gnight. | 00:02 |
UsL | I must pretend to be an adult tomorrow. | 00:03 |
adhoc | scroll lock was a thing on DOS based systems, | 00:08 |
adhoc | does not always work on the same on modern systems though | 00:08 |
adhoc | crtl+S locks and crtl+Q unlocks scroll in your terminal | 00:08 |
adhoc | not sure which machine introduced that | 00:08 |
adhoc | works on my vt220 | 00:09 |
adhoc | not on the old wyse terminal | 00:09 |
adhoc | and pretty sure did not on the wyse 52 | 00:09 |
adhoc | i suppose it is as much to do what is in the termcap for that display terminal | 00:09 |
Afdal | For some reason I have all my ttys set to autologin | 01:06 |
Afdal | that doesn't seem like a great idea | 01:06 |
Afdal | How did I do this and how do I set it so that I have to actually login when I go to a tty | 01:07 |
adhoc | Afdal: what does your /etc/inittab look like ? | 01:21 |
adhoc | i have entries like; | 01:21 |
adhoc | 1:2345:respawn:/sbin/getty 38400 tty1 | 01:21 |
adhoc | 2:23:respawn:/sbin/getty 38400 tty2 | 01:21 |
adhoc | 2-6 are basicall tthe same with the first character (number) the same as the tty number | 01:22 |
adhoc | the second column is the run level, in this case run level 2 and 3 being multi-user | 01:22 |
* adhoc remember the first glass tty | 01:23 | |
adhoc | and messing with; | 01:23 |
adhoc | #T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100 | 01:23 |
adhoc | although mine was a vt220 | 01:24 |
Afdal | 1:2345:respawn:/bin/login -f afdal </dev/tty1 >/dev/tty1 2>&1 | 01:24 |
Afdal | 2:23:respawn:/bin/login -f afdal </dev/tty2 >/dev/tty2 2>&1 | 01:24 |
Afdal | and so on | 01:24 |
adhoc | neat, never seen that before | 01:24 |
Afdal | what's neat about it @_@ | 01:25 |
adhoc | auto login, never seen that before | 01:25 |
Afdal | Yeah but how'd that happen in the first place @_@ | 01:25 |
Afdal | and how do I turn it off | 01:25 |
adhoc | i mean, there are issues, but that could be useful for kiosk type systems | 01:25 |
Afdal | I've never edited this manually | 01:25 |
adhoc | well, look at my lines above | 01:25 |
adhoc | no idea, but comment them out, copy'n'paste in new lines | 01:26 |
gnarface | Afdal: certainly you can think of something you've done | 01:26 |
adhoc | mode the /bin/login to /sbin/getty 38400 tty1 | 01:26 |
Afdal | I hate mysteries -_- | 01:26 |
Afdal | what does that number even mean | 01:27 |
Afdal | what does any of this gibberish mean | 01:27 |
adhoc | serial port speed, effectively | 01:27 |
adhoc | 38400 baud | 01:27 |
adhoc | divide by 10 gives you approximately the bytes per second | 01:27 |
gnarface | which installer did you use Afdal? | 01:28 |
Afdal | why getty | 01:28 |
Afdal | uh the terminal based one | 01:28 |
Afdal | whose name I keep forgetting | 01:28 |
gnarface | debootstrap? | 01:28 |
Afdal | no | 01:28 |
* gnarface raises eyebrow | 01:28 | |
* Afdal raises paw | 01:29 | |
adhoc | getty has been in use on Linux since ... early 1990's | 01:29 |
gnarface | dselect? | 01:29 |
* fluffywolf spots a furry! | 01:29 | |
Afdal | no | 01:29 |
* adhoc is a bit vague when it came in | 01:29 | |
gnarface | which init, Afdal? | 01:30 |
Afdal | sysvinit at the moment | 01:30 |
Afdal | I wasn't given a choice | 01:30 |
gnarface | did you have a graphical login thingy at any point? | 01:30 |
adhoc | Afdal: was this a debian system you moved over? | 01:30 |
Afdal | omg no | 01:30 |
fluffywolf | and here I thought I was the only devuan user with paws. :P | 01:30 |
Afdal | what's the name of the heckin installer | 01:30 |
adhoc | fluffywolf: that must make it hard to type | 01:30 |
Afdal | it was the only installer I even saw | 01:31 |
fluffywolf | it does! | 01:31 |
gnarface | if that file is wrong then i suspect there might be other things wrong | 01:32 |
Afdal | What's the name of the graphical installer | 01:32 |
Afdal | on live images | 01:32 |
Afdal | I can't even find that | 01:33 |
gnarface | live images use refracta something or another | 01:33 |
Afdal | I hate the modern wweb so much | 01:33 |
Afdal | Yeah it was that | 01:33 |
gnarface | refractasnapshot | 01:33 |
Afdal | I used that in terminal form | 01:33 |
gnarface | or refractainstaller | 01:33 |
gnarface | one of those | 01:33 |
gnarface | i think | 01:33 |
Afdal | refractainstaller, yeah | 01:33 |
gnarface | i don't know crap about it really | 01:34 |
Afdal | and yeah there was a display manager but I set it to autologin so I never see it now | 01:34 |
Afdal | it's the typical one used by Xfce | 01:34 |
Afdal | lightdm probably | 01:34 |
Afdal | or maybe not | 01:35 |
gnarface | well it matters whether it was refractasnapshot or refractainstaller, you should check the man pages for them | 01:35 |
Afdal | it was refractainstaller | 01:36 |
gnarface | i think refractasnapshot would have mirrored the running livecd | 01:36 |
Afdal | it was refractainstaller | 01:36 |
Afdal | I remember the command I ran | 01:36 |
gnarface | i have to assume refractainstaller would need configuration | 01:36 |
gnarface | maybe you missed a setting? | 01:36 |
Afdal | @_@ | 01:36 |
gnarface | or maybe it sets this because you set autologin | 01:36 |
gnarface | it might set it in both places | 01:37 |
gnarface | if you set it in the gui, i dunno | 01:37 |
Afdal | How do I check which display manager I have installed without logging out | 01:37 |
gnarface | dpkg -l | 01:37 |
Afdal | <.< | 01:37 |
gnarface | if you have more than one you can see the default with the alternatives symlink stuff | 01:38 |
Afdal | @_@ | 01:39 |
gnarface | i think it's /etc/alternatives/x-session-manager | 01:39 |
gnarface | or x-login-manager ? | 01:39 |
gnarface | something like that | 01:39 |
gnarface | i don't even have one installed | 01:39 |
gnarface | have you considered using the normal netinstaller? | 01:39 |
Afdal | Well I'm not reinstalling again now | 01:39 |
Afdal | The reason I used terminal based was because I had to install from an ssh | 01:39 |
gnarface | well fyi for the future the regular installers are here: https://files.devuan.org/devuan_chimaera/installer-iso/ | 01:40 |
gnarface | (that's current stable) | 01:40 |
gnarface | fresh off the presses | 01:40 |
Afdal | uhhh yeah | 01:40 |
Afdal | it's probably lightdm | 01:42 |
Afdal | seeing as I have a symlink to desktop-lightdm-background in here | 01:42 |
Afdal | nope, guess not | 01:43 |
gnarface | might be slim? | 01:43 |
Afdal | that's definitely installed | 01:43 |
Afdal | must be that | 01:43 |
gnarface | well if you're not gonna use it you can just uninstall it | 01:43 |
Afdal | Every now and then I have a reason to log out ;o | 01:44 |
Afdal | like switching window managers or whatever | 01:44 |
gnarface | none of that actually requires slim | 01:44 |
Afdal | well certainly I -could- end an X session and go to terminal then start it all up manually | 01:45 |
Afdal | but uh <.< | 01:45 |
gnarface | startx | 01:45 |
Afdal | I like a nice little dropdown menu to choose my window manager/desktop environment session | 01:45 |
gnarface | it's in the xinit package | 01:45 |
gnarface | i think it's still there anyway | 01:46 |
gnarface | if it hasn't been chopped by vandals | 01:46 |
Afdal | Then again maybe I like bein autologged into ttys when I switch to them | 01:56 |
Afdal | I dunno, what are the security implications of that? | 01:57 |
Afdal | particularly on a machine with an ssh server running | 01:57 |
gnarface | i feel like it's a pretty apparent security concern | 01:58 |
adhoc | with physical access, there is no secutiry | 01:59 |
adhoc | with a user account, you have to assume someone can get root | 01:59 |
adhoc | the box is therefore hosed. | 01:59 |
gnarface | well, that's not always true around cats and young children | 01:59 |
gnarface | there are layers of security and layers of threat | 01:59 |
Afdal | yeah if someone is sitting at my machine it doesn't really matter | 02:07 |
Afdal | but do ttys pose any kind of thread from a remote session | 02:07 |
Neutr1no | How do I remove an script that startup at /etc/init.d/? I have moved the script to another directory but I want that it will removed from the init process | 02:07 |
Neutr1no | Afdal: good morning | 02:07 |
Afdal | h-hello | 02:08 |
Neutr1no | Afdal: greetz from northern germany | 02:08 |
gnarface | Afdal: well if the users gain the wrong permissions on the /dev/ node there's a theoretical possibility they could type stuff on your screen but they've already rooted the box at that point | 02:09 |
Afdal | maybe I'll just keep these convenient autologin'd ttys around then :) | 02:10 |
gnarface | Neutr1no: there's a tool called sysv-rc-conf you can use or you could just delete the symlinks in /etc/rc?.d/ | 02:10 |
Afdal | saves me a step when I have to run to a tty to kill a program or something | 02:11 |
gnarface | you should make sure to not allow remote root login with sshd... i have concerns about the sshd security level too | 02:12 |
Afdal | oh definitely, I always have that disabled | 02:13 |
Afdal | it should really be a default openssh setting | 02:14 |
Neutr1no | gnarface: thank you very much. Nice tool, Thx | 02:14 |
Neutr1no | gnarface: it works | 02:14 |
gnarface | Neutr1no: no problem | 02:14 |
Neutr1no | :-) | 02:17 |
Neutr1no | 3 | 02:18 |
Neutr1no | is there also an tool available to configure source from the package manager? | 02:34 |
gnarface | like automake? | 02:38 |
gnarface | what do you mean by source? like kernel sources or program sources or apt sources? | 02:39 |
u-amarsh04 | like apt-get build-dep ? | 02:40 |
Neutr1no | I add an source to /etc/apt/source.list by editing this file. But this source is broken, I want remove it without doing it manualy by editing the file | 02:42 |
gnarface | hmm, i actually don't know of any gui tools for that | 02:42 |
gnarface | there's a gui package manager called synaptic, i don't know if it can manage sources too | 02:43 |
Neutr1no | gnarface: thanks | 02:43 |
Neutr1no | one last question. Is there an good email client with an nice textmode / ncurses gui? | 02:44 |
gnarface | everyone uses mutt for that i think | 02:45 |
onefang | Or neomutt. | 02:47 |
onefang | Synaptic can manage sources. | 02:47 |
onefang | In ASCII "mutt" was a renamed neomutt, but in Beowulf it's called neomutt again. Blame Debian. | 02:48 |
gnarface | there's always emacs post-el too | 02:50 |
Neutr1no | you are best. Thanks for your support. | 02:54 |
* Neutr1no love the shell and want learn more about unix/linux (bash an textmode shells) | 03:00 | |
gnarface | hooraaay! we're the best | 03:03 |
gnarface | best way to start is read the man pages | 03:04 |
gnarface | bash has a man page too | 03:04 |
gnarface | (though with bash, the bash-doc package or the online help at gnu.org might be a better place to start) | 03:05 |
gnarface | most the important command-line programs will have a decent man page for reference, the complex stuff often has a *-doc package to accompany it | 03:06 |
gnarface | also typically packages will put some docs in /usr/share/doc/[package name] | 03:07 |
gnarface | though with a lot of packages, all that's in there is boilerplate copyright stuff | 03:08 |
Neutr1no | gnarface: reading RFC's are interested, to. but man and RFC's are very complex and long. My english is not so good and I don't have enough time for that at the moment | 03:16 |
Neutrino- | can someone help with the configuration from the fvwm window manager? | 08:15 |
gnarface | Neutrino-: i don't know fvwm but it would help someone who does if you lead with what you're trying to accomplish, and what you've tried so far | 08:24 |
Neutrino- | gnarface: I figured it out by myself just in this moment, it works | 08:25 |
Neutrino- | gnarface: thnx | 08:25 |
gnarface | np | 08:26 |
Neutrino- | what is the name from the gui based fvwm theme selector? | 08:54 |
chomwitt | should apt-cache search --names-only "^ff.*" display sffw2 amont the results? | 09:53 |
chomwitt | i think it search 'package names' and not THE package names, which means apt-cache searches also fields like 'Provides' etc | 10:01 |
chomwitt | s/THE package names/THE package name | 10:02 |
chomwitt | but 'Provides' some times have package names like librust-pango-sys+default-dev that dont look searchable by apt-cache search | 11:01 |
chomwitt | xmm,, so it searches Package names in Provides field but not virtual ones | 11:17 |
fsmithred | Afdal, did you figure out how to disable autologin? | 13:18 |
fsmithred | cp /usr/lib/refractainstaller/inittab.debian /etc/inittab | 13:18 |
fsmithred | that will get rid of console autologin. | 13:19 |
Afdal | What's the smartest way to run old software that depends on a software library version no longer in the current repository... | 19:37 |
Afdal | Some kind of container? | 19:37 |
gnarface | if the running kernel is still compatible, you can run it and the whole release version it was from in a chroot | 19:49 |
gnarface | or even just a frankenstein install of mishmashed library versions would work too | 19:49 |
gnarface | since the chroot can be basically disposed of without affecting the parent system | 19:50 |
gnarface | if there's kernel incompatibility too you might need qemu | 19:50 |
gnarface | if it's literally just one library and there's no other dependencies you could also just force the program to load it from a side directory with LD_PRELOAD | 19:51 |
gnarface | (that's assuming you have a way to get it there without corrupting the package tree) | 19:51 |
Afdal | I'm not even sure how to get the library actually I:'} | 19:52 |
gnarface | do you know what version and what its name is? | 19:54 |
Afdal | on a different distro | 19:54 |
Afdal | I think it's libjpeg8 | 19:54 |
Afdal | but it seems Debian/Devuan has dropped or never used the number distinction at the end | 19:54 |
gnarface | checking... | 19:55 |
Afdal | Does Canonical always use the game package names as Debian or do they have their own shenanigans? | 19:56 |
Afdal | same* | 19:56 |
gnarface | it was in ceres recently, libjpeg8-dev and libjpeg8-dbg still are, but it looks like they're moving to libjpeg9 | 19:56 |
gnarface | this doesn't seem to be a package name difference, it's merely time | 19:56 |
gnarface | you're too late, you just missed it | 19:56 |
gnarface | it might still be in the debian snapshot repos... snapshots.debian.org | 19:56 |
gnarface | or you could see if it works with libjpeg9 instead | 19:57 |
Afdal | it doesn't | 19:57 |
Afdal | it's looking for something specifically with an 8 in it | 19:57 |
gnarface | oh, bummer | 19:57 |
Afdal | shared libraries: libjpeg.so.8 | 19:57 |
gnarface | well | 19:57 |
gnarface | this would be dirty but you could try symlinking to that from libjpeg9 | 19:58 |
gnarface | or from that to libjpeg9 i mean | 19:58 |
Afdal | o: | 19:58 |
gnarface | sometimes that works | 19:58 |
Afdal | where are library names usually located? | 19:58 |
gnarface | run this: dpkg -L [package name] | 19:58 |
gnarface | they're typically in /usr/lib/ or /usr/lib/[something arch and distro specific] | 19:59 |
Afdal | actually, uh | 19:59 |
gnarface | for exampel /usr/lib/x86_64-linux-gnu/ | 19:59 |
Afdal | wait... why is bare libjpeg not in the Chimaera repo? | 19:59 |
Afdal | there's only libjpeg-dev | 19:59 |
gnarface | your search pattern is wrong, chimaera is on libjpeg62 | 20:00 |
Afdal | well, there's libjpeg62-turbo | 20:00 |
gnarface | https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=%5Elibjpeg.*&x=submit | 20:00 |
Afdal | is that's the de facto standard lijpeg now? | 20:00 |
gnarface | looks like it | 20:01 |
Afdal | confusing | 20:01 |
gnarface | looks like ceres skipped over 7 and 8 | 20:01 |
gnarface | well, not skipped over but left behind | 20:01 |
gnarface | and neither made it into stable before the cut | 20:01 |
Afdal | dpkg-query: error: --listfiles needs a valid package name but 'libjpeg62-turbo' is not: ambiguous package name 'libjpeg62-turbo' with more than one installed instance | 20:02 |
Afdal | oof | 20:02 |
gnarface | that doesn't seem right | 20:02 |
gnarface | do you have multi-arch enabled? | 20:02 |
Afdal | yes | 20:02 |
gnarface | do you have libjpeg62-turbo for two arches? | 20:02 |
Afdal | do I need to designate x86-64 somewhere | 20:02 |
Afdal | I'm gonna guess probably | 20:03 |
gnarface | it seems to be able to stay installed concurrently with libjpeg8 | 20:03 |
gnarface | oh, sorry, didn't realize that was a question: dpkg -L libjpeg62-turbo:amd64 | 20:08 |
gnarface | package names won't include symlinks, so this is better: ls -l /usr/lib/x86_64-linux-gnu/libjpeg.* | 20:09 |
gnarface | if you're on ceres i'd just install the old one quick before its gone from snapshots | 20:10 |
Afdal | how do I do that | 20:11 |
Afdal | (I'm on Chimaera) | 20:12 |
Afdal | so is it /usr/lib/x86_64-linux-gnu/libjpeg.so.62.3.0 or /usr/lib/x86_64-linux-gnu/libjpeg.so.62 that I want to try symlinking | 20:12 |
Afdal | oh those are only version differences | 20:13 |
gnarface | if you used "ls -l" you can clearly see that libjpeg.so and libjpeg.62 are both symlinks to libjpeg.so.62.3.0 | 20:13 |
gnarface | so in this case you'd want to try symlinking libjpeg8 to libjpeg.so.62.3.0 as well | 20:14 |
Afdal | ah, that's silly | 20:14 |
gnarface | but i think that going backwards is less likely to work than going forwards | 20:14 |
gnarface | i think it would be more likely to work with libjpeg9 than libjpeg62 but it probably won't hurt to try anyway | 20:14 |
gnarface | you'd be better off getting libjpeg8 on here | 20:15 |
gnarface | either from snapshots or by building the source package if still possible | 20:15 |
Afdal | so... ls -s /usr/lib/x86_64-linux-gnu/libjpeg.so.62.3.0 /usr/lib/x86_64-linux-gnu/libjpeg.so.8 | 20:15 |
Afdal | ? | 20:15 |
Afdal | err, ln* | 20:15 |
gnarface | yea | 20:16 |
gnarface | then run "ldconfig" once as root and try the program again | 20:16 |
Afdal | /usr/lib/x86_64-linux-gnu/libjpeg.so.8: version `LIBJPEG_8.0' not found | 20:16 |
Afdal | lol, dangit | 20:16 |
gnarface | yea, worth a try | 20:16 |
gnarface | usually it doesn't work that way | 20:16 |
Afdal | then it's not gonna work with lijpeg9 either | 20:17 |
gnarface | see, there's two dependencies, package dependences and runtime dependencies | 20:17 |
gnarface | sometimes the package dependencies are too specific and programs will work with other packages | 20:17 |
gnarface | but usually newer versions, rather than older | 20:17 |
Afdal | so how do I grab something from this "snapshots" kajigger | 20:17 |
Afdal | actually, wait | 20:17 |
gnarface | if it's actually specifically checking for LIBJPEG_8.0 symbol maybe that's the only one it'll work with | 20:18 |
gnarface | but that would be weird in and of itself | 20:18 |
gnarface | wtf program is this anyway? | 20:18 |
Afdal | Could I just grab the libjpeg8 from another system partition? | 20:18 |
Afdal | yeah... | 20:18 |
Afdal | it's MAME | 20:18 |
gnarface | if you still have it installed elsewhere, sure | 20:18 |
gnarface | oh, you can probably build mame against any libjpeg version | 20:18 |
gnarface | i guess i haven't tried in a while so i don't know for sure | 20:19 |
Afdal | building mame is so complicated -_ | 20:19 |
Afdal | -_- | 20:19 |
gnarface | instructions are on snapshots.debian.org | 20:19 |
Afdal | and I dunno how I would build an older version | 20:19 |
Afdal | so would that just be a ./configure flag then | 20:19 |
gnarface | basically you just add the snapshot repo for a day when it was last seen in the repo, install just that one package, then remove the snapshot repo from your sources again | 20:19 |
gnarface | although, that would be for a release it was actually inlike ceres | 20:20 |
gnarface | (sid) | 20:20 |
gnarface | hmmm | 20:20 |
gnarface | heh | 20:20 |
gnarface | yea just copy it from another partition into your mame directory and run it like LD_PRELOAD="./libjpeg8.so" mame | 20:21 |
gnarface | that would work too | 20:21 |
gnarface | cleanest way would be to build the source package for yourself for chimaera but i have a strong suspicion it won't build right and that's why we're having this discussion in the first place | 20:21 |
Afdal | okay so how do I export an installed package into a .deb | 20:21 |
Afdal | so I don't have to copy a zillion directories | 20:21 |
gnarface | you probably just need that one lib file in your home dir tbh | 20:22 |
gnarface | since nothing else is gonna use it | 20:22 |
Afdal | hmm | 20:22 |
gnarface | check to see if the package is still in /var/cache/apt/archives there | 20:22 |
gnarface | if it was installed recently it might still be there | 20:22 |
Afdal | naw | 20:23 |
gnarface | i forget how to export an installed package back to a deb, i can't remember if there's a way to do that | 20:23 |
gnarface | but seriously, just try copying that one library over and pointing mame to it directly with the LD_PRELOAD environment variable. it might not need anything else | 20:24 |
gnarface | and it might not need to be in a particular location | 20:24 |
Afdal | This is probably what I wanna grab right: /usr/lib/x86_64-linux-gnu/libjpeg.so.8.1.2 | 20:25 |
gnarface | i vaguely recall struggling with this on something some years ago and finding out that the refusal to work with libjpeg62 turned out to be a bug | 20:25 |
gnarface | probably yea | 20:25 |
Afdal | okay so expltain to me this LD_PRELOAD variable | 20:26 |
Afdal | These sorts of headaches make me seriously want to build appimages for old software when I want to hang on to some particular version | 20:27 |
Afdal | Sometimes I think the library dependency system of loonix is more trouble than it's worth... | 20:29 |
gnarface | LD_PRELOAD just forces it to load whatever library you tell it first, preempting the LD_LIBRARY_PATH | 20:29 |
Afdal | Yeah but how do I use it? | 20:29 |
gnarface | i literally typed the command to you | 20:29 |
Afdal | hmm? | 20:29 |
gnarface | LD_PRELOAD="./libjpeg.so.8.1.2" mame | 20:29 |
Afdal | oh, ah | 20:29 |
Afdal | h-here I go :3 | 20:29 |
gnarface | if only this one program needs it, there's no reason to put it in the global environment | 20:29 |
gnarface | chances are they removed it because it's cursed anyway | 20:30 |
Afdal | uhhh hmm this is a stupid question | 20:30 |
gnarface | ? | 20:30 |
Afdal | how do I ./run a binary when it's prefaced with something else first | 20:31 |
Afdal | in bash | 20:31 |
gnarface | what do you mean? | 20:31 |
Afdal | LD_PRELOAD="/home/afdal/oldpackages/libjpeg.so.8.1.2" ./mame | 20:31 |
Afdal | that just loads up my currently installed mame | 20:31 |
Afdal | instead of the old binary I want to run | 20:31 |
gnarface | well it can be /usr/bin/mame too or whatever | 20:31 |
gnarface | both those fields can take full paths | 20:32 |
Afdal | oh rite | 20:32 |
Afdal | oof that just keeps running my current install | 20:32 |
Afdal | what's up with that... | 20:32 |
gnarface | well which mame are you trying to run? i'm not sure even what the confusion is | 20:33 |
Afdal | I'm trying to run an old version on a previous distro | 20:33 |
Afdal | from* a previous distro | 20:33 |
gnarface | LD_PRELOAD="/home/afdal/oldpackages/libjpeg.so.8.1.2" /path/to/wherever/mame | 20:33 |
Afdal | yeah when I do that it just loads up the current mame installation | 20:34 |
Afdal | how do I make bash stop misbehaving I: | 20:34 |
gnarface | it doesn't though | 20:34 |
Afdal | but it does tho {:I | 20:34 |
gnarface | it'll definitely load whatever mame binary you point to, but you might be getting confused because that mame binary is going to still default to using the current user's mame configs in ~/ | 20:34 |
gnarface | which you'd have to correct with mame configs i don't remember off the top of my head | 20:35 |
gnarface | but i'm sure it can be set | 20:35 |
Afdal | I don't think I'm running a symlinked binary... | 20:35 |
gnarface | even if you're running mame from a partition that was not used by the current distro but used by an old distro, that mame version is still going to use the current user's home directory and all configs | 20:36 |
Afdal | yeah but it's not like the ~/.mame config tells mame which binary to use | 20:36 |
Afdal | as evidenced when I try to run ./blah/blah/blah/mame I get thrown that libjpeg8 error | 20:36 |
gnarface | hmmm | 20:37 |
gnarface | nah we're misdiagnosing something here | 20:37 |
gnarface | the ~/.mame does tell it where the highscores and roms are stored, iirc | 20:37 |
Afdal | /media/afdal/e099a547-8781-4ef4-afed-326743586a28/usr/games/mame is definitely the right binary | 20:37 |
Afdal | that I'm trying to run | 20:38 |
Afdal | I think this is just a bash syntax issue | 20:38 |
Afdal | what's the trick tho | 20:38 |
gnarface | i can't imagine what's going wrong at this point, that should have worked | 20:39 |
gnarface | it did used to work on that install? | 20:39 |
Afdal | absolutely | 20:39 |
Afdal | bash just keeps trying to execute the binary it's normally expecting when you run a bare "mame" command instead of the specific binary I want by telling it the right path | 20:40 |
gnarface | with the full path that shouldn't happen | 20:40 |
gnarface | you sure it's not actually a symlink or some wrapper script itself? | 20:41 |
Afdal | nope, not a symlink or script | 20:41 |
Afdal | it's the whole 250MB whale | 20:41 |
Afdal | 310* | 20:41 |
gnarface | what if you also set LD_LIBRARY_PATH="/home/afdal/oldpackages:$LD_LIBRARY_PATH" ? | 20:42 |
gnarface | i would try chrooting into the old install to see if it still runs from there | 20:44 |
gnarface | if the old instasll is still intact | 20:44 |
Afdal | look the issue is bash tries to load up something else when I end any of those ld variable sets with the path to the executable I want to run | 20:45 |
Afdal | Should I just uninstall my current mame installation... | 20:45 |
Afdal | ugh | 20:45 |
gnarface | nah i wouldn't do anything hasty yet till you figure out what's going wrong | 20:45 |
Afdal | how do we tell bash to stop being retarded | 20:46 |
gnarface | we seem to be overlooking something important, bash is not smart enough to be retarded | 20:46 |
Afdal | maybe I should export these variables to globals first and then run the executable command separately | 20:46 |
Afdal | lolwuttheheck | 20:47 |
gnarface | do you have the "locate" package installed? | 20:47 |
Afdal | I tried that and now even a bare "./mame" command makes bash open my current installed binary~ | 20:47 |
Afdal | what is going on with this goofy system | 20:47 |
Afdal | okay so it wasn't a syntax issue | 20:48 |
Afdal | and this is clearly not a symlink I'm trying to run | 20:48 |
Afdal | yeah I have locate | 20:48 |
gnarface | locate could misbehave this way, that's why i stopped using it | 20:49 |
gnarface | it does path caching | 20:49 |
gnarface | there's a command to flush it... updatedb or something? | 20:50 |
gnarface | i forget | 20:50 |
Afdal | this is so bizarre | 20:50 |
Afdal | why would fixing the library dependency error of an old binary then make that binary point to a new one somewhere else | 20:50 |
Afdal | Maybe the smart move is just to run old program versions in containers -_- | 20:52 |
Afdal | Even symlinking my old libjpeg to /usr/lib/x86_64-linux-gnu/libjpeg.so.8 produces the same behavior | 20:54 |
gnarface | sorry, libera lagged me out there, if you said anything after my response at 11:49 Afdal, i missed it | 21:00 |
Afdal | <Afdal> this is so bizarre | 21:03 |
Afdal | <Afdal> why would fixing the library dependency error of an old binary then make that binary point to a new one somewhere else | 21:03 |
Afdal | <Afdal> Maybe the smart move is just to run old program versions in containers -_- | 21:03 |
Afdal | <Afdal> Even symlinking my old libjpeg to /usr/lib/x86_64-linux-gnu/libjpeg.so.8 produces the same behavior | 21:03 |
gnarface | i think there's an important key we're overlooking | 21:03 |
gnarface | like you're ssh'd into a completely different machine or something | 21:03 |
gnarface | i dunno i'm out of ideas | 21:04 |
gnarface | something should have budged | 21:04 |
gnarface | i don't know if it would have worked but it should have at least changed behavior | 21:04 |
gnarface | i agree that maybe containers are the smarter way to go but this problem seems low enough level it could affect everything | 21:04 |
gnarface | a fresh build of mame might be in order | 21:06 |
gnarface | but i think retracing your steps might turn something up too, some simple mistake or oversight | 21:06 |
rwp | I read just a little bit of the scrollback and I read very unusual stuff being debugged. | 21:08 |
rwp | Trying to override libjpeg with a different version? I can't imagine why. | 21:09 |
rwp | But if one wants to debug the dynamic loader then something like this might be helpful. | 21:09 |
rwp | env LD_TRACE_PRELINKING=1 /lib/x86_64-linux-gnu/ld-2.31.so --list /bin/cat | 21:09 |
rwp | Replace with the appropriate things you are actually using. But it will show the libs that are getting linked in and what symbols are doing it. | 21:09 |
rwp | There is also just plain old: /lib/x86_64-linux-gnu/ld-2.31.so --list /bin/cat | 21:10 |
rwp | The /lib/x86_64-linux-gnu/ld-2.31.so is otherwise known as "ld.so" and the "man ld.so" documents it. | 21:10 |
Afdal | naw I'm not debugging anything, just trying to run an old version of a program that requires libjpeg8 | 21:11 |
rwp | There is also "ldconfig -v" which sets up the /etc/ld.so.cache too. | 21:12 |
Afdal | I dunno what you just said @_@ | 21:12 |
rwp | What is the name of the package with the old shared library you need? | 21:15 |
rwp | Is it possible to simply pull it out of snapshot.debian.net and install it? That would be the simplest way forward. | 21:15 |
rwp | (Sorry but I have not read the scroll back buffer in detail about what was previously tried.) | 21:15 |
gnarface | Afdal: can you try it again with LD_PRELOAD and full paths but without located running please? | 21:15 |
Afdal | uhh how do I stop locate from running? | 21:15 |
Afdal | is that a system service | 21:16 |
gnarface | /etc/init.d/located stop | 21:16 |
gnarface | i think | 21:16 |
gnarface | should be a system service yes | 21:16 |
Afdal | I'll give it a go... | 21:16 |
Afdal | hmm that doesn't exist | 21:16 |
Afdal | /etc/init.d/located | 21:16 |
rwp | If the library package has a version'd name, as it ought to have, then multiple versions can co-exist. If not then it's a problem and you will need a chroot or something. | 21:16 |
gnarface | how about just /etc/init.d/locaate ? | 21:16 |
Afdal | nope | 21:16 |
gnarface | dpkg -L locate? | 21:17 |
rwp | Locate runs from cron. It's started from cron not init. | 21:17 |
gnarface | oh | 21:17 |
gnarface | i would just honestly uninstall it | 21:17 |
rwp | It's probably /etc/cron.daily/locate that starts it. | 21:17 |
rwp | There are at least three different packages that implement locate-like functionality. All derived from each other. So it may be mlocate or one of the others too. | 21:18 |
Afdal | I'm not even sure what locate does, what's it's purpose? | 21:18 |
gnarface | hmmm | 21:18 |
Afdal | This was automatically installed on my Devuan installation | 21:18 |
rwp | "locate" is a fast find of every file on the file system. By working off of a pre-compiled database of every file on the file system. | 21:18 |
gnarface | yea but if you have two rootfses mounted in parallel with conflicting mame versions it might not be smart enough to handle that well | 21:19 |
rwp | I don't think locate is part of the default set that is installed. But with Recommends being what they are if Recommends is not burned out with fire then a lot of cruft gets installed. | 21:19 |
rwp | Personally I use locate to find a file or three at least once every other day. It's very useful to me. I use it. | 21:20 |
rwp | But of course if you don't use it then it has no use for you and it would be better to remove it. | 21:21 |
Afdal | I use uh | 21:21 |
Afdal | whatever Catfish depends on | 21:21 |
rwp | I happen to know that Linode at least has a customization that disables locate at boot time. The customer can enable it again though. | 21:21 |
Afdal | I don't think it's locate | 21:21 |
rwp | That's it. catfish: "Recommends: mlocate | locate" | 21:22 |
Afdal | o rly | 21:22 |
rwp | Which means you probably have the "mlocate" version installed. It's a modified fork of "locate". | 21:23 |
rwp | To demonstrate the use of it "locate libjpeg.so" would locate and print out every file on the system with that name in it. | 21:24 |
Afdal | I don't even know why this is relevant. Does bash use locate to index binaries in the background or something? | 21:25 |
rwp | No. | 21:25 |
rwp | It's relevant because you said, "I'm not even sure what locate does, what's it's purpose?" You asked. | 21:25 |
gnarface | doesn't it? i'm pretty sure this is why i stopped using locate over 2 decades ago | 21:25 |
Afdal | o: | 21:25 |
rwp | gnarface, Doesn't it what? I missed the context link there. | 21:26 |
Afdal | I thought all that stuff happened in some bash config file somewhere | 21:26 |
Afdal | is it .bashrc | 21:26 |
Afdal | no... | 21:26 |
rwp | bash is your command shell. Full stop. How is it related to locate? | 21:26 |
Afdal | @_@ | 21:26 |
gnarface | rwp: the primary symptom is that if he runs /media/afdal/e099a547-8781-4ef4-afed-326743586a28/usr/games/mame it is still giving him /usr/games/mame no matter what | 21:27 |
Afdal | isn't it like... when you "install" something it adds a location alias to bash so you can just call the name of the program without adding all that directory fluff | 21:27 |
gnarface | rwp: i suspect a possible misdiagnosis too but locate was definitely associated with these type of gremlins for me a long time ago | 21:28 |
Afdal | all right well lemme try uninstalling it for a sec | 21:29 |
Afdal | hopefully nothing breaks | 21:29 |
gnarface | i've never run into anything that actually needs it or any situation where it was actually notably beneficial | 21:29 |
rwp | Okay. I think you are thinking of the shell's internal hashing. Try "type foo" to see shell tracked aliases. Try "hash -r" to rehash it, flushing all past knowledge of the commend. | 21:29 |
Afdal | and yeah, mlocate is the version I have installed | 21:29 |
rwp | In this case, "type mame" I guess is what you would ask it. | 21:30 |
gnarface | was there also a daemon in redhat a long time ago called located? could i be confusing this locate with something else? | 21:30 |
Afdal | Nope, uninstalling mlocate didn't resolve it... | 21:30 |
rwp | Maybe. I don't know. There are several different forks and mutations of the locate task. | 21:30 |
gnarface | Afdal: what if you just log all the way out and back in? | 21:31 |
Afdal | type mame | 21:31 |
Afdal | mame is /usr/games/mame | 21:31 |
rwp | But let me assure you that locate, mlocate, or other locate, has nothing to do with PATH and bash running a particular program or other. Totally separate. | 21:31 |
Afdal | lol why would that do anything | 21:31 |
Afdal | Clearing environmental variables or something? | 21:31 |
gnarface | Afdal: maybe environment variable corruption from hand testing? yea | 21:31 |
rwp | Afdal, Try "hash -r" to flush the cache. Then try "type mame" again. And what is PATH? echo $PATH | 21:31 |
Afdal | mame is /usr/games/mame | 21:32 |
Afdal | echo $PATH | 21:32 |
Afdal | /home/afdal/bin:/home/afdal/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games | 21:32 |
rwp | I always have "shopt -s checkhash" set in my ~/.bashrc file too. "checkhash -- If set, bash checks that a command found in the hash table exists before trying to execute it. If a hashed command no longer exists, a normal path search is performed." | 21:33 |
rwp | Afdal, So there you go. It's PATH. You have path set including /usr/games and so it finds /usr/games/mame from PATH. | 21:33 |
gnarface | yea but if he called the other binary with the full path prefix that shouldn't matter | 21:33 |
Afdal | uh yes, but that's what should happen when I call "mame" | 21:33 |
Afdal | what shouldn't be happening is that when I do a full directory path ^ | 21:34 |
Afdal | Wonder if I can reproduce this with some other program | 21:34 |
rwp | Calling a program by the full path should not cause a tracked alias to be created for it. | 21:35 |
Afdal | i know rite | 21:35 |
rwp | So is /media/afdal/e099a547-8781-4ef4-afed-326743586a28 actually a full OS being mounted there? And you want the mame from there to use the libs from there? | 21:37 |
Afdal | yes to both | 21:37 |
Afdal | I've got the library issue resolved, so I think | 21:37 |
rwp | Okay. Then that's certainly possible. Have done that many times for other programs. Let me type in a long command line. | 21:37 |
Afdal | I just wanna get that old binary to run on my current Duvuan environment | 21:38 |
gnarface | rwp: incident started because it refused to run against any libjpeg other than libjpeg8 which seems to have just been recently removed | 21:38 |
Afdal | you're not gonna tell me to chroot are you... | 21:38 |
rwp | Try: /lib/x86_64-linux-gnu/ld-2.31.so --library-path /media/afdal/e099a547-8781-4ef4-afed-326743586a28/lib:/media/afdal/e099a547-8781-4ef4-afed-326743586a28/usr/lib /media/afdal/e099a547-8781-4ef4-afed-326743586a28/usr/games/mame | 21:39 |
rwp | Assuming that you are running an amd64 arch system. No chroot required. | 21:40 |
rwp | That tells the ld.so to use the library path for that OS for running that executable. | 21:40 |
Afdal | what even is ld.so | 21:40 |
Afdal | /lib/x86_64-linux-gnu/ld-2.31.so --library-path /media/afdal/e099a547-8781-4ef4-afed-326743586a28/lib:/media/afdal/e099a547-8781-4ef4-afed-326743586a28/usr/lib /media/afdal/e099a547-8781-4ef4-afed-326743586a28/usr/games/mame | 21:41 |
gnarface | the linking library | 21:41 |
Afdal | /media/afdal/e099a547-8781-4ef4-afed-326743586a28/usr/games/mame: error while loading shared libraries: libjpeg.so.8: cannot open shared object file: No such file or directory | 21:41 |
rwp | The /lib/x86_64-linux-gnu/ld-2.31.so is the ld.so dynamic linker. It's what links in libraries to programs. | 21:41 |
Afdal | Is that any different from the LD_PRELOAD trick | 21:42 |
rwp | If that is the error then I don't think it exists in that system directory either. | 21:42 |
rwp | It's similar to the LD_PRELOAD trick. But it loads *everything* from that location rather than cherry picking. | 21:42 |
gnarface | probably /media/afdal/e099a547-8781-4ef4-afed-326743586a28/lib:/media/afdal/e099a547-8781-4ef4-afed-326743586a28/usr/lib/x86_64-linux-gnu, no? | 21:42 |
rwp | It's a way to run RHEL binaries on Devuan for example. And so forth. That's mostly how I have used in the past. | 21:43 |
Afdal | yeah, need the x86_64-linux-gnu bit | 21:43 |
rwp | What does this say: file /media/afdal/e099a547-8781-4ef4-afed-326743586a28/usr/games/mame | 21:43 |
Afdal | /media/afdal/e099a547-8781-4ef4-afed-326743586a28/usr/games/mame: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=de8f998a127c0b6f8c2d3e1016a04128ae1cb0a0, stripped | 21:44 |
Afdal | afdal@devuan-desktop:/media/a | 21:44 |
rwp | It's a 64-bit amd64 binary. So that okay, right? | 21:44 |
gnarface | should be right | 21:44 |
Afdal | interesting, progress perhaps: error while loading shared libraries: libpulsecommon-11.1.so: cannot open shared object file: No such file or directory | 21:44 |
Afdal | so there's another dependency I need to fix first | 21:44 |
gnarface | ah ha | 21:44 |
gnarface | progress! | 21:45 |
gnarface | neeat trick with this /lib/x86_64-linux-gnu/ld-2.31.so --library-path thing, never seen that rwp | 21:45 |
* gnarface didn't even realize that was an executable | 21:45 | |
rwp | Something is still not feeling consistent here. Because if that OS tree had those things installed then it should be there. And if it not there then something is not consistent. | 21:45 |
* gnarface would have already rebuilt mame by now | 21:46 | |
Afdal | oh... wait | 21:46 |
Afdal | wait | 21:46 |
Afdal | hol up | 21:46 |
gnarface | get the paths right, i made a mistake | 21:46 |
rwp | gnarface, We would get RHEL binaries of CAD/EDA programs and I would repackage them to run on our Debian systems using that technique. | 21:46 |
Afdal | I just realized something embarrassing | 21:46 |
gnarface | looking at the wrong directory? | 21:46 |
Afdal | This hasn't been loading the same binaries after all | 21:46 |
* gnarface facepalm | 21:47 | |
* gnarface had that suspicion | 21:47 | |
Afdal | Ugh, well crap | 21:47 |
Afdal | so uh | 21:47 |
gnarface | wait does it run though? | 21:47 |
Afdal | well this raises even more confusing questions | 21:47 |
Afdal | apparently the mame binary on my old *buntu installation was NEWER than the one just upgraded to on Chimaera | 21:47 |
gnarface | not surprising | 21:48 |
rwp | gnarface, Using bash's exec -a option allows creating a script so that ps even shows the correct name running if it is all wrapped up. | 21:48 |
Afdal | which is hilarious and baffling before that was only 18.04 | 21:48 |
gnarface | that's just how ubuntu is, they're bleeding-edge | 21:48 |
Afdal | not typically when it comes to emulators | 21:48 |
Afdal | So uh one of the main reasons I decided to try out Devuan recently is | 21:48 |
gnarface | here's the thing though, this: /media/afdal/e099a547-8781-4ef4-afed-326743586a28/lib:/media/afdal/e099a547-8781-4ef4-afed-326743586a28/usr/lib | 21:49 |
Afdal | I -just- upgraded my 16.04 *buntu to 18.04 | 21:49 |
Afdal | and created a situation where I can't boot anymore | 21:49 |
gnarface | would actually have to be this: /media/afdal/e099a547-8781-4ef4-afed-326743586a28/lib:/media/afdal/e099a547-8781-4ef4-afed-326743586a28/usr/lib:/media/afdal/e099a547-8781-4ef4-afed-326743586a28/usr/lib/x86_64-linux-gnu | 21:49 |
rwp | Note that the installer iso is a good rescue boot system if you need it. | 21:49 |
Afdal | I have no idea why this newer build of mame would be using this ancient libjpeg8 library | 21:50 |
rwp | gnarface, That's a good modification if that is the correct list of directories. | 21:50 |
Afdal | taht's so weird | 21:50 |
gnarface | i don't know for sure you wouldn't need i386-linux-gnu in there too. for Steam or Wine stuff you often would | 21:50 |
Afdal | Well, in any event, damnit, this means this isn't the version of MAME that I'm looking for and I probably have to compile it to use it again after all >:/ | 21:50 |
rwp | Afdal, When a developer compiles a package and uploads it the program running is the binary built on their system. Which may be using an old library. | 21:50 |
rwp | It's the main reason there is a push for source only uploads. | 21:50 |
Afdal | unless... | 21:51 |
rwp | Because otherwise the main arch by the developer is from their own system. Meanwhile all of the other arch's are from the build systems. | 21:51 |
Afdal | I can just grab a .deb from an old *buntu repository | 21:51 |
gnarface | check if mame is in backports first | 21:51 |
Afdal | how do I do that again | 21:51 |
gnarface | nevermind, doesn't look like it is | 21:52 |
Afdal | lol | 21:52 |
rwp | I am with gnarface in that it is probably time to build the mame you want from source. Probably not that difficult. | 21:52 |
Afdal | mame is a -gigantic- piece of software | 21:52 |
rwp | First start with "apt-get build-dep mame" to install the build dependencies. | 21:52 |
Afdal | I'm really hesitant to compile it... | 21:52 |
gnarface | i've built it on a raspberry pi model B | 21:53 |
Afdal | This is really surprising, the *buntu 18.04 build updated MAME all the way up to a build from August this year. Normally MAME builds on *buntu are absolutely ancient | 21:53 |
rwp | Well... There is that. Even my 16GB system struggles with 0AD for example. | 21:53 |
Jjp137 | eh the dependencies don't look that bad? https://docs.mamedev.org/initialsetup/compilingmame.html#debian-and-ubuntu-including-raspberry-pi-and-odroid-devices | 21:53 |
Afdal | Meanwhile Chimaera is on MAME from last January :v | 21:53 |
rwp | Did you perhaps have an Ubuntu PPA in your sources for something? | 21:53 |
Afdal | No? | 21:54 |
Afdal | everyone says that's a terrible idea | 21:54 |
Afdal | oh you mean the sources of the the old system | 21:54 |
gnarface | it is but ubuntu people might have talked you into it for the ubuntu install | 21:54 |
Afdal | yeah that might have been it | 21:54 |
Afdal | Ahem, well... at least with compiling I'll be able to specify exactly the libraries I want and even make an appimage or whatever so I never have to deal with dependency hell again | 21:55 |
gnarface | that's the idea | 21:55 |
gnarface | also, it gets easier every time | 21:56 |
Afdal | compiling from git diffs maybe | 21:57 |
Afdal | I'm expecting a huge headache compiling an old build -_- | 21:57 |
gnarface | well if you're not actually running this on an ARM SoC i doubt you need any special patches or versions | 21:58 |
Afdal | At least the MAME project keeps around source archives for old versions | 21:58 |
Afdal | thank god for that | 21:58 |
rwp | Good luck with everything! I am dropping offline again for a while... | 21:58 |
Afdal | thanks for the educational experience -_- | 21:59 |
gnarface | any time | 21:59 |
Afdal | hmm you know what, I do have a ppa .deb that's close to the version I'd like to use | 22:00 |
Afdal | how do I install a package of another version alongside a different one again... | 22:01 |
gnarface | their own dependencies probably prohibit that | 22:01 |
gnarface | it'd have to be coded to share paths safely | 22:01 |
Afdal | actually that's a .deb made for Trusty, maybe I'd better not mess with something -that- old | 22:01 |
gnarface | chimaera should match current debian stable for build deps | 22:01 |
Afdal | can't I just like | 22:02 |
Afdal | grab the binary from a .dev archive | 22:02 |
gnarface | ... use the version currently in chimaera? | 22:02 |
Afdal | .deb archive* | 22:02 |
gnarface | curious why you needed libjpeg8 tbh | 22:02 |
Afdal | for that other binary compiled for *buntu | 22:03 |
gnarface | i never asked what's wrong with the existing version built against the existing libjpeg | 22:03 |
gnarface | i just sorta assumed you had a problem with it | 22:03 |
gnarface | there's a version in the chimaera repos that should still work | 22:03 |
Afdal | version of what | 22:03 |
gnarface | mame | 22:03 |
Afdal | it's probably not the version I'm interested in | 22:03 |
Afdal | what version? | 22:03 |
gnarface | https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=%5Emame%24&x=submit | 22:04 |
gnarface | looks like 0.228 right now | 22:04 |
Afdal | yeah that's far too new | 22:04 |
gnarface | with some debian pacakges | 22:04 |
Afdal | I want v0.160 or something close to it | 22:04 |
gnarface | you sure it matters? | 22:04 |
Afdal | Yeah, so uh | 22:04 |
Afdal | the whole reason I'm doing this | 22:05 |
Afdal | is I have some input replay files I need to view again/dump to video | 22:05 |
Afdal | that don't work on newer builds of MAME | 22:05 |
gnarface | oh i see | 22:05 |
gnarface | they're not in a format ffmpeg can handle directly? | 22:05 |
Afdal | no they're MAME .inp files | 22:05 |
Afdal | it's a series of player inputs tracked by time that you need the emulator to interpret | 22:06 |
gnarface | i see | 22:06 |
gnarface | damn | 22:07 |
Afdal | Yeah the v0.154 in the jessie repo is close but I think when you go backwards the input files never work that way | 22:07 |
Afdal | So I guess I'm gonna have to compile this | 22:07 |
gnarface | 0.160 source is still available from mame's site? | 22:07 |
Afdal | yup | 22:07 |
Afdal | I just grabbed it | 22:07 |
Afdal | https://www.mamedev.org/oldrel.html | 22:07 |
gnarface | get the build-deps for chimaera mame first and it might just work | 22:07 |
gnarface | "apt-get build-dep mame" | 22:08 |
Afdal | they've got em all even going back to 1997 | 22:08 |
gnarface | also probably apt-get build-essential | 22:08 |
Afdal | I just realized there are kids these days who are younger than the MAME project #whoa #wow | 22:08 |
eyalroz | Hello channel denizens... I was wondering if it's possible to install (packaged) GCC 7 or GCC 8 on Devuan Chimaera. I'd like to avoid going to the trouble of building it from source... | 22:09 |
gnarface | you're probably better off running that in a chroot than integrating it into chimaera, eyalroz | 22:11 |
eyalroz | @gnarface: Really? I mean, gcc-9 and gcc-10 seem to coexist nicely | 22:11 |
gnarface | eyalroz: last seen in beowulf, so i assume it was pulled for a reason | 22:12 |
eyalroz | why not gcc-7 following the same scheme of directory and file naming? | 22:12 |
gnarface | i don't know, i've seen 7 and 8 both come and go through ceres | 22:12 |
gnarface | i just assume you're going to run into a conflict with libc6 major version changes | 22:13 |
gnarface | i could be wrong | 22:13 |
gnarface | but since it's just for building other things it might not be worth the struggle when you can just debootstrap beowulf into a chroot | 22:13 |
gnarface | if you upgraded through beowulf to chimaera, it would have stayed installed if there wasn't a runtime conflict | 22:14 |
gnarface | or rather, if there wasn't an anticipated runtime conflict that was blocked with package dependencies, that is | 22:14 |
eyalroz | gnarface: I have actually never tried debootstrapping (into a chroot or otherwise)... | 22:15 |
gnarface | well technically you just debootstrap into a directory and chroot into that directory afterwards | 22:16 |
gnarface | try this: debootstrap beowulf ./ https://deb.devuan.org/merged | 22:18 |
gnarface | or something like that | 22:19 |
gnarface | (in a spare empty directory)_ | 22:19 |
gnarface | i forget if you need the /merged part | 22:19 |
gnarface | i think you do | 22:19 |
Afdal | that's one long build-dep list... | 22:20 |
gnarface | Afdal: one of the reasons i recommend doing stuff like this in a chroot is to not pollute your main install with all those deps | 22:20 |
Afdal | hmm this old version doesn't even have a configure script | 22:20 |
Afdal | lol too late | 22:20 |
gnarface | just a make file? | 22:21 |
Afdal | yeah | 22:21 |
Afdal | This could get ugly... | 22:21 |
gnarface | i don't recall any real problems building it. the raspberry pi build never ran well but it ran | 22:21 |
Afdal | I need to learn how to make appimages already | 22:22 |
eyalroz | gnarface: I'll try it, will see what happens. | 22:22 |
gnarface | Afdal: install checkinstall, and when you finish building it you can auto-package it with "checkinstall make install" | 22:23 |
Afdal | yeah I know about checkinstall | 22:23 |
Afdal | but that's just a deb | 22:23 |
gnarface | well it helps for cleanup later if you have to do it again | 22:24 |
Afdal | I need it self-contained so I don't have to deal with library problems in the future | 22:24 |
gnarface | the deb checkinstall makes won't enforce any dependencies unless you tell it to explicitly | 22:24 |
Afdal | o rly | 22:24 |
Afdal | I never knew that... | 22:24 |
eyalroz | gnarface: I tried debootstrap'ing, and gort: E: Failed getting release file https://deb.devuan.org/merged/dists/beowulf/Release | 22:24 |
gnarface | Afdal: the binary itself might be a different matter... you should check the READMES | 22:25 |
eyalroz | s/gort/got | 22:25 |
Afdal | Well then what the heck do we need appimages/snaps/whatever for? | 22:25 |
gnarface | Afdal: we don't need them, they're harmful | 22:26 |
Afdal | :o | 22:26 |
gnarface | eyalroz: try it without https | 22:27 |
gnarface | eyalroz: sorry about that, the mirrors in the round-robin mostly don't support https by the round-robin's domain name | 22:28 |
eyalroz | gnarface: NP, that seems to be doing stuff. | 22:28 |
eyalroz | Let's see what ends faster - debootstrap'ing or building GCC-8.5.0 (I went for a somewhat newer version). | 22:29 |
Afdal | Well that was fast, I already feel flabberghasted | 22:32 |
Afdal | at least when configure scripts throw an error it's not to hard to figure out the problem | 22:32 |
Afdal | make errors can be so byzantine -_- | 22:32 |
gnarface | scroll up to where the first error starts in the build log output, you should see a library name mentioned usually | 22:34 |
gnarface | if it just mentions a undefined symbol, google usually can match it to the missing library for you | 22:34 |
gnarface | or at least to someone else's complaint about it | 22:34 |
gnarface | don't worry about any other errors, just install that one missing library and try again | 22:35 |
Afdal | https://pastebin.com/umC9Z72f | 22:35 |
Afdal | Does anything look like a library here @_@? | 22:35 |
gnarface | could you use paste.debian.net instead please? pastebin has ads | 22:36 |
Afdal | what, really? | 22:36 |
Afdal | I've never seen an ad on pastebin... | 22:36 |
gnarface | they won't always show if you're in a region they don't think they can monetize | 22:37 |
gnarface | or if you're using an ad blocker | 22:37 |
Afdal | https://paste.debian.net/1218850/ | 22:37 |
Afdal | does any of that gibberish look like a library to you | 22:37 |
Afdal | Imagine, browsing the internet without an ad blocker... | 22:38 |
gnarface | no actually it looks like a problem with the gcc version | 22:38 |
gnarface | behavior change | 22:38 |
gnarface | something used to be allowed that's not | 22:38 |
Afdal | How did you deduce that | 22:38 |
gnarface | the words in the error | 22:38 |
gnarface | its clearly saying the code of mame is invalid, but one must assume a long time ago this was allowed | 22:39 |
gnarface | happens all the time | 22:39 |
Jjp137 | it seems that -Werror is being passed to the compiler | 22:39 |
Afdal | So I might need to get an old gcc version like that previous user was talking about... | 22:39 |
Jjp137 | and GCC adds new warnings in later versions | 22:39 |
Jjp137 | so you need to find where -Werror is being passed and remove it perhaps | 22:39 |
gnarface | Afdal: maybe but in this case you can probably just change the flag | 22:39 |
Afdal | the flag? | 22:39 |
gnarface | Afdal: -Werror | 22:39 |
gnarface | if you google that line you might come up with direct suggestions | 22:40 |
gnarface | likely you'll have to edit the make file or patch this input.h | 22:40 |
Afdal | I don't know how I would have figured this out on my own ;_;7 | 22:40 |
gnarface | hang out here long enough and you'll get smarter by osmosis | 22:41 |
Afdal | I feel bad for polluting #devuan chat with compiling issues | 22:41 |
gnarface | so basically "-Werror" is a highly strict mode for gcc, it throws errors if they would have just been warnings | 22:42 |
Afdal | If I ask on #mame it'll take 10 years to get an answer or they'll just tell me to use a newer version though -___- | 22:42 |
gnarface | so possibly you can just omit -Werror from the makefile and these warnings will pass harmlessly | 22:42 |
gnarface | i wouldn't roll this into a production system because they in some cases can represent security risks, but mame is not secure to begin with so i assume you're not doing this on a public server | 22:43 |
Afdal | of course not | 22:43 |
Afdal | It's my computer, I do what I want~ | 22:43 |
gnarface | if too much changed in gcc's behavior since then, this might not be as easy to build as i had hoped | 22:44 |
gnarface | but maybe there will be only one or two of such conflicting default behavior changes | 22:44 |
Jjp137 | okay I downloaded the source for 0.160 and turns out the makefile checks if "NOWERROR" is defined | 22:44 |
Jjp137 | so do: NOWERROR=1 make | 22:44 |
gnarface | nice, good find Jjp137 | 22:44 |
gnarface | Afdal: ^ try this before you edit any files | 22:45 |
Afdal | hmm, well it skipped over that error this time and continued | 22:46 |
Afdal | roadblocked by a different error now | 22:46 |
Afdal | TypeError: can only concatenate str (not "int") to str | 22:47 |
Afdal | hmm, is that an error I'm gonna need an older gcc to address | 22:47 |
Jjp137 | that's...Python? | 22:47 |
Afdal | no it's from a .c file | 22:47 |
Jjp137 | dump the output at paste.debian.net again | 22:48 |
Afdal | I'll do the whole thing this time | 22:48 |
Afdal | https://paste.debian.net/1218851/ | 22:49 |
Afdal | uh, oh I posed both attempts in that paste | 22:50 |
Afdal | posted | 22:50 |
Afdal | bottom half is with NOWERROR=1 | 22:50 |
Afdal | https://embeddedartistry.com/blog/2017/05/22/werror-is-not-your-friend/ | 22:52 |
Jjp137 | if you run `python`, is it Python 2 or 3? | 22:52 |
Jjp137 | (press Ctrl+D to quit Python) | 22:52 |
Afdal | 3.9.2 | 22:53 |
Afdal | Is there actually a python dependency in this though | 22:53 |
Jjp137 | yes | 22:53 |
Jjp137 | it tries to run src/build/makelist.py as part of the build process but blows up | 22:54 |
Afdal | oh I didn't even notice those .py bits | 22:54 |
gnarface | you should be able to have python2 and python3 installed concurrently and force it to use python2 even if python3 is the system default | 22:56 |
Jjp137 | Afdal, dumb hack: open the makefile, and at line 373, replace '@python' with 'python2', then try again | 22:59 |
Afdal | lol, well certainly more is happening now... | 23:00 |
Afdal | so many warnings | 23:00 |
Afdal | This might just work :v | 23:02 |
Afdal | so many special drivers for '80s games | 23:03 |
Afdal | aww man, 40 minutes of compiling only to run into another error | 23:45 |
Afdal | I think I'm missing some sort of Qt library | 23:45 |
Afdal | Here's some junk from the last make output before it finally gave up https://paste.debian.net/1218856/ | 23:49 |
gnarface | maybe another version conflict, or maybe just missing *-dev packages for the native qt version, can't tell | 23:55 |
fluffywolf | I don't see any errors there, just warnings | 23:55 |
gnarface | Afdal: is that actually the start of the errors? | 23:56 |
Afdal | no there's a giant endless list of warnings throughout compiling | 23:56 |
gnarface | gotta be something | 23:57 |
gnarface | give us the last few screens worth | 23:57 |
gnarface | or open it in emacs and do a reverse-string search from the end for "error" | 23:57 |
Afdal | well | 23:58 |
Afdal | https://paste.debian.net/1218857/ | 23:58 |
Afdal | that's as far back as my terminal history reaches | 23:58 |
gnarface | alright, you're going to have to get a build log into a text file | 23:59 |
gnarface | make > ~/build_log.tmp.log 2>&1 & | 23:59 |
gnarface | gotta find the part where this particular series of warnings started from | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!