| jyri | wpa is easy, you just need to generate the passphrase | 15:11 |
|---|---|---|
| jyri | https://wiki.archlinux.org/title/wpa_supplicant#Connecting_with_wpa_passphrase | 15:11 |
| jyri | write the network { to a file and then add this to the /etc/network/interfaces | 15:12 |
| jyri | auto wlxd03745ad048a | 15:13 |
| jyri | iface wlxd03745ad048a inet dhcp | 15:13 |
| jyri | wpa-conf /path/to/your/config.file | 15:13 |
| jyri | hmm, that got broken? | 15:13 |
| jyri | the "I" should be tab | 15:14 |
| jyri | naturally change the wlxd03745ad048a to your wifi card name | 15:14 |
| jyri | that can be easily written to a script that granma can run in coffee shop I think | 15:18 |
| rrq | yeah, and see "man wpa_action" for the details | 15:21 |
| luser978 | who is the idiot who came up with interface renaming instead of softlinks? poettering? | 16:34 |
| Akuli | are we talking about eth0 --> enp0m2 ? | 16:34 |
| luser978 | that too | 16:35 |
| Akuli | (i don't actually remember what the newer name for eth0 is, but it looks something like that) | 16:35 |
| Akuli | i just hope i won't ever have to deal with the new naming scheme | 16:35 |
| luser979 | bsd used names like that but does /not/ rename them at runtime. | 16:36 |
| luser979 | this rant was about runtime renaming | 16:37 |
| mason | BSD names NICs for the driver behind them, not the card/slot. | 17:09 |
| diegs | o/ I'm having this very weird problem where, after enabling the i386 architecture in dpkg, I try to install the i386 freetype on an amd64 install but the result is apt wanting to uninstall a bunch of amd64 libraries: https://f.perl.bot/raw/e1kmia | 17:25 |
| diegs | Just wondering if this has happened before, and if there is any way I can solve this Thanks | 17:25 |
| mason | diegs: id you add the architecture or change your architecture entirely? | 17:28 |
| diegs | just added it | 17:28 |
| diegs | dpkg --add-architecture i386 | 17:29 |
| mason | Oh. Hrm. | 17:29 |
| mason | In most cases you probably don't need i386 dev packages. | 17:29 |
| mason | You might need the backing i386 library, but a dev package should just be headers and such. | 17:30 |
| diegs | Yeah, but I'm trying to build xash3d <https://github.com/FWGS/xash3d-fwgs> | 17:30 |
| diegs | >NOTE FOR USERS WITH X86 COMPATIBLE CPUs: We have forced build system to throw an error, if you're trying to build 64-bit engine. This done for keeping compatibility with Steam releases of Half-Life and based on it's engine games. Even if Xash3D FWGS does support targetting 64-bit, you can't load games without recompiling them from source code! | 17:30 |
| mason | Does it not build with the amd64 libfreetype6-dev? | 17:30 |
| diegs | It does build, but it won't work with the game resource files | 17:30 |
| diegs | So it'd be paperweight | 17:30 |
| mason | You'd ought to be able to specify that it link to the 32-bit libraries in build options. | 17:31 |
| mason | But I've never tried to build that, so I don't know | 17:31 |
| diegs | hrm | 17:31 |
| diegs | Well, thank you regardless | 17:32 |
| mason | diegs: Look at their build instructions. | 17:32 |
| diegs | Okay | 17:32 |
| mason | They don't say to install libfreetype6-dev:i386 | 17:32 |
| mason | They explicitly say to install libfreetype6-dev | 17:32 |
| diegs | >Enable i386 on your system, if you're compiling 32-bit engine on amd64. If not, skip this | 17:32 |
| mason | Oh, I take that back. | 17:33 |
| diegs | And as of right now, the build system gives me this error: freetype2 isn't installed correctly. Make sure you installed proper development package for target architecture | 17:33 |
| mason | diegs: Do you get the same issue if you give the entire line they recommend at once? | 17:33 |
| diegs | No, the output is different | 17:34 |
| diegs | But it does fail | 17:34 |
| mason | Let's look at that failure instead. | 17:34 |
| diegs | https://f.perl.bot/raw/sn9wyd mason | 17:34 |
| mason | Hrm. That's interesting. It doesn't error on my Beowulf box. | 17:37 |
| mason | And it does the same libfontconfig1-dev substitution. | 17:37 |
| mason | diegs: Something I'd try then is installing the "but isn't going to be installed" packages to see if something is blocking them. | 17:38 |
| mason | And if something is, there you are. | 17:38 |
| diegs | mason: looks like the mass removal thing showed up again: https://f.perl.bot/raw/ff7sbm | 17:40 |
| mason | diegs: Then next up, add the new installs to the bigger command line. | 17:40 |
| diegs | okay | 17:40 |
| mason | and try adding all the would-be-excluded dependent packages at once to that same command line. | 17:41 |
| mason | It ought to tell you why it doesn't want to install some or all of them. | 17:41 |
| diegs | well, the thing is it does eventually allow me to install everything | 17:43 |
| diegs | https://f.perl.bot/raw/1hj39r | 17:44 |
| diegs | it's all because of linux-libc-dev:i386 mason | 17:44 |
| diegs | if i attempt to install it, it gets rid of all these amd64 packages | 17:44 |
| mason | And if you leave just that out, the other stuff breaks? | 17:45 |
| mason | Folks in here have noted that aptitude(8) sometimes does a better job figuring out complex dependencies or explaining what the conflicts are if it can't solve them. | 17:46 |
| mason | It's worth mucking with it to see. There's something funny in your installed packages, though, causing this, as I don't see the same result here. | 17:46 |
| Rrad | Hello. Are /etc/rc.2/S01* (for example) scripts all run in parallel? | 19:26 |
| djph | no | 19:36 |
| mason | There's make-style parallel execution available. | 19:39 |
| djph | ... maybe I'm crossing *BSD and linux .../ | 19:40 |
| mason | Read /etc/init.d/rc and search for "concurrency" | 19:41 |
| mason | well, capitalized | 19:41 |
| mason | Rrad: If you read that you should end up at startpar(8) | 19:43 |
| Rrad | Thanks djph. Mason I was just now reading /etc/init.d/rc and found the same thing and I was wondering how to figure out if that makefile-like parallelism is used. | 19:44 |
| Rrad | Reading now more about it, thank you. | 19:44 |
| Rrad | The other thing I'm still wondering about is how the priorities are assigned to the scripts by update-rc.d. I assume that insserver's man page might shed more light on that. | 19:45 |
| mason | Rrad: You can follow the script and see those things that explicitly disable it. | 19:47 |
| mason | Priorities are a bit funny when automated. | 19:47 |
| mason | I'd rather that were less automated than it is. | 19:48 |
| Rrad | My goal right now is to setup sdmem to run right before halt. I could obviously just edit the halt/reboot script but I want to do it properly with it's own script. | 19:48 |
| Rrad | Halt is S14, by itself. And there are other S13 scripts under rc.0. So I wonder how I could describe the dependencies so that halt is pushed up to S15. | 19:49 |
| Rrad | I also wonder if update-rc.d would even push it up. I read in it's man that it does not touch existing links to scripts | 19:49 |
| Rrad | By "automated" you mean update-rc.d decides the numbers, right? | 19:52 |
| Rrad | (using insserv) | 19:52 |
| amesser | Rrad: yes the numbers are generated from the dependencies in the script headers | 20:00 |
| Rrad | amesser, am I understanding correctly that update-rc.d will not touch the priorities of existing linked scripts in rc directories even if I go and fiddle with the priorities? | 20:07 |
| mason | I thought it'd redo them as needed. It'll certainly change numbers. Worth some empirical testing. | 20:13 |
| Rrad | Hmmm I'll read the manual again more carefully first. I don't want to break my system. :-) Thanks for the info! | 20:24 |
| mason | Rrad: You can make changes and back them out manually if needed, without exercising the actual scripts. | 20:26 |
| amesser | Rrad: I think the script will always rebuild the priorities from scratch | 21:15 |
| amesser | If you want to change the order or priority for some system supplied script, the best method imho is to place custom header in /etc/insserv/overrides<script-name> | 21:16 |
| amesser | I meant /etc/insserv/overrides/<scriptname> | 21:17 |
| amesser | It will override the original header | 21:17 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!