| eyalroz | rwp: Well, I'm glad to report that I usrmerge'd sucessefully, albeit with some manual assisting | 00:16 |
|---|---|---|
| eyalroz | but - it's not enough to look at usrmerge.postinst, there are some perl scripts in the data part of the deb that one needs to examine | 00:16 |
| eyalroz | unfortunately, it can't cope with some basic executables being in a state of the /usr/sbin or /usr/bin version linking to a /bin or /sbin version, | 00:17 |
| eyalroz | and the same for udev | 00:17 |
| eyalroz | but if you do that manually in the direction it likes, it takes care of the rest. | 00:18 |
| eyalroz | On a semi-related note, with kernel 6.6.13, I got this in my bootlog: | 00:19 |
| eyalroz | Wed Feb 7 01:13:44 2024: Setting up ALSA...warning: 'alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore' failed with error message 'Found hardware: " | 00:19 |
| eyalroz | HDA-Intel" "Realtek ALC1150" "HDA:10ec0900,104386ae,00100001 HDA:8086280b,80860101,00100000" "0x1043" "0x86ae" | 00:19 |
| eyalroz | why does alsactl think this is a failure? | 00:19 |
| rrq | "if device is not known (sic type), error code 99 is returned" | 00:23 |
| rwp | eyalroz, Good to hear that you got through the usrmerge even if it took some manual help to do it. | 00:47 |
| eyalroz | rwp: the usrmerge script seems to play it safe, and bails on you if it gets confused about anything. | 00:50 |
| eyalroz | which is good | 00:50 |
| eyalroz | rrq: interesting... | 00:51 |
| eyalroz | rrq: as my devices were known with kernel 6.5.0 :-P | 00:51 |
| rwp | eyalroz, There have been some reports like yours of people who have run usrmerge and it has bailed out on them due to local system modifications that have been made. It's both a pro and a con. It is good that it bails out rather than cause a bigger problem. It is bad that it cannot be completely automated for all cases because then there will always be cases where it just can't work automatically. | 00:55 |
| eyalroz | rwp: I think I'll write the maintainer with a specific improvement suggestion. You see, his logic does cover the situation I had, but he only applies it after making sure that some "basic" executables are where he expects them. | 00:56 |
| rwp | Excellent! It will be good to improve things such that it might work better for the next person. | 00:57 |
| u-amarsh04 | eyalroz thanks for being willing to make suggestions on improving usrmerge script - what I didn't like on principle was that it wasn't production quality to begin with and there wasn't a directive to ensure symbolic links from the old binaries' location to the new location | 02:29 |
| CEP | hello, how are they? | 15:32 |
| CEP | gnarface, Hello, I was finally able to solve the sound issue, on the Asus laptop I worked on the file /home/'user'/.xsessionrc, added delay to the beginnings of: wireplumber & pipewire &, and deleted 'pkill...' | 15:39 |
| buZz | pipewire ftw :D | 16:23 |
| buZz | CEP: dont forget to launch pipewire-pulse | 16:23 |
| buZz | if you want to use the pulseaudio emulation inside pipewire | 16:23 |
| CEP | buZz, Yes, only in the text I put (the first two are the ones that have a delay time), pipewire-pulse does not have a delay time | 16:43 |
| gnu_srs1 | I'm happy w/o pipewire or pulseaudio. Plain alsa stuff works for me TM :) | 16:44 |
| CEP | I think what gave the error was killing 'previous processes', I have no idea how that line was added, maybe it was created when daedalus was installed... | 16:48 |
| equarrillo | Hello. Are there small ptograms available to manage automount usb-s? | 17:00 |
| equarrillo | udiskie has lots of dependncies | 17:00 |
| equarrillo | Udev and autofs manual config doesn't work for me. | 17:02 |
| equarrillo | What is used in default installation? | 17:03 |
| CEP | buZz, I installed daedalus on a laptop to work, I just wanted to install and not reconfigure much, but I listen to music when I work, or other PCs, pipewire was installed during the installation of the operating system | 17:08 |
| netbsd | hello guys | 17:26 |
| netbsd | to connect to my WIFI, I use systemd+ systemctl with network-manager-gnome i.e. nm network manager, gui. With systemctl enabled. | 17:27 |
| netbsd | However when you got NO SYSTEMD, then Debian is not intended for GUI with the proto. Protected EAP... | 17:27 |
| CEP | hello | 17:27 |
| netbsd | so then, iw+iwd but it offers ... nothing. Any ideas, welcome. | 17:27 |
| netbsd | vim or nano to get Prot. EAP to work? | 17:28 |
| rwp | netbsd, I am using Devuan 5 Daedalus (no systemd) with network-manager and it presents me with WiFi access points and I can connect with WPA/WPA2. I don't know anything about EAP however. | 18:43 |
| rwp | I have no idea how EAP/PEAP would be interacting such that there would a problem with it. Just providing a data point that it's working okay for me with normal WPA2 APs. | 18:45 |
| mason | netbsd: Your init has little to do with your wireless authentication or encryption. | 18:58 |
| peterrooney | mason: you haven't met systemd. | 19:49 |
| mason | Would that that were so. | 19:50 |
| eyalroz | u-amarsh04: So, I wrote Marco d'Itri, who maintains that package, and here's what he says: | 21:52 |
| eyalroz | "The merging work in Debian is concluded, so I will not make further modifications for very specific use cases." | 21:53 |
| eyalroz | Ugh :-( | 21:53 |
| eyalroz | rwp: might interest you as well | 21:53 |
| rwp | That's a pretty typical response. Unfortunately. | 21:57 |
| Juest | hey, is devuan truly systemd free or it uses extracted components that are useful standalone? | 22:16 |
| rwp | Juest, Devuan avoids the running of systemd giving the user init freedom to choose among the available inits. Depending upon your needs you might not need *any* systemd related anything. Or you might need to have installed a library or two on disk in order to meet dependencies that are just not worth forking the package to avoid. | 22:22 |
| Juest | i see | 22:23 |
| rwp | Devuan uses Debian packages verbatim as much as possible. Which means that Debian packages which will work without systemd are used verbatim. It is only about a hundred packages which are Debian hard coded to require systemd. Those are forked to avoid the hard Depends: requirement. Other than those hundred some packages all of the rest are Debian packages. | 22:26 |
| rwp | Which is why it is not worth forking every package that depends upon libsystemd0 for example which just sits on disk and does not cause trouble just having it installed. But that is technically a part of systemd so not truly hard core pedantic free of systemd but definitely not running it. | 22:27 |
| eyalroz | Juest: tl;dr: Yes, Devuan is truly systemd free. | 23:22 |
| eyalroz | Also... | 23:24 |
| eyalroz | # ls -la /usr/lib/x86_64-linux-gnu/libsystemd.so.0 | 23:24 |
| eyalroz | lrwxrwxrwx 1 root root 15 Nov 11 00:14 /usr/lib/x86_64-linux-gnu/libsystemd.so.0 -> libelogind.so.0 | 23:24 |
| Juest | elogind is systemd logind extracted so its still systemd code | 23:25 |
| eyalroz | Juest: Yes, that's the exception to the tl;dr :-( | 23:36 |
| eyalroz | But as the elogind repository states: "Unlike systemd, whose logind arranges to manage resources for user sessions via RPC calls to systemd, in elogind there is no systemd so there is no global cgroup-based resource management" | 23:37 |
| eyalroz | This was extracted not because it's necessarily more useful, but because some desktop environments and other packages depend on the existence of something which looks like systemd's logind. | 23:38 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!