ksx4system | https://www.youtube.com/watch?v=PSWejov-pss | 03:47 |
---|---|---|
ksx4system | enjoy some awesome music | 03:47 |
golinux | Music should be on #devuan-offtopic. :) | 03:54 |
oz4ga | I'm trying to setup a minimal chimera system using debootstrap.When I chroot into and try to do an "apt install console-setup locales", then I get the following error-message: "/bin/sh: 1: /usr/bin/apt-listchanges: not found" .I've tried this many times before w.o.o problems. is the apt package broken some how ?? | 05:06 |
onefang | Looks like your chroot doesn't have apt-listchanges installed, but the apt config thinks it does. | 05:09 |
onefang | Had you copied tho apt config files from asystem that does have it installed? | 05:10 |
oz4ga | erm yes and it has work flawlessly many times before | 05:10 |
onefang | Add apt-listchanges to the list of packages you tell debootstrap to install. | 05:11 |
oz4ga | why has it vanished since yesterday? | 05:13 |
onefang | apt-listchanges is a separate package. If you don't install it, but the apt config files you copied from a system that does have it installed, then apt will try to call it. | 05:14 |
oz4ga | I just do "debootstrap --arch amd64 chimaera /mnt http://deb.devuan.org/merged/ chimaera" | 05:15 |
rrq | the host is amd64? | 05:17 |
oz4ga | yes and this has worked for a loong time | 05:17 |
onefang | Maybe you turned off suggested packages? | 05:19 |
oz4ga | it has works with that switchd of alos for a loooong time, I tried to remove the no-suggest and no-reccommends. no change | 05:20 |
onefang | Had you recently installed apt-listchanges in the system you copied the apt config files from? | 05:21 |
rrq | oz4ga: procfs mounted ? | 05:22 |
gnarface | possible that maybe the apt cache had been cleared or something? | 05:22 |
onefang | Or perhaps tripped over usrmerge? | 05:22 |
oz4ga | onefang: no it's a valilla install from the netinstall iso | 05:22 |
oz4ga | rrq: yes it'smountes | 05:23 |
rrq | right.. hmm I tried that debootstrap and didn't arrive at your issue | 05:23 |
rrq | though /usr/bin/apt-listchanges is not installed | 05:24 |
onefang | So it's in the config files you copied. | 05:25 |
rrq | oz4ga: I guess the /bin/sh error is from running your chimaera script | 05:25 |
onefang | Eithor remove it from the config file, or install aptlistchanges on the debootstrap. | 05:26 |
oz4ga | Forgive me I've spend the last 25 years in FreeBSD. I don't quite understand which config file I should remove what from | 05:29 |
onefang | Or try it from scatch, but don't copy the hosts apt config files. Coz I think that's the root of your problem. | 05:32 |
oz4ga | heck it's only 5:30 in the morning, so I could give this a try again without all my "cleverness" that has worked so many times before | 05:32 |
onefang | Exactly. lol | 05:33 |
onefang | My guess is you recently installed apt-listchanges on your host, and you are copying your hosts apt config files to the guest, which doesn't have apt-listhcanges installed, but your hosts apt config wants to call it. | 05:37 |
xisop | was apt ever written in perl? If I do `file $(which apt apt-get)` both are ELF binaries | 05:46 |
oz4ga | onefang: apt-listchanges IS installed on my system. The time stamp on the file is "Mar 28 2021". I only fiddled w. Devuan for a month. | 06:00 |
onefang | That's the time stamp for when it was last built, not when it was installed. | 06:01 |
onefang | And it's installed on the host, not the guest. | 06:02 |
oz4ga | never mind. I now did a clean debootstrap. Which site is safe to put in my sources.list file? my curret sources.list file is @ https://pastebin.com/SHJFii2D | 06:02 |
oz4ga | yes and not on the guest. that is correct. | 06:03 |
onefang | Pick one from https://pkgmaster.devuan.org/mirror_list.txt | 06:03 |
onefang | Though we prefer people don't use pkgmaster.devuan.org for their sources.list, coz that's the master the other mirrors sync to, and don't want to bog it down. | 06:05 |
fluffywolf | make pgkmaster a mirror; don't give out the actual master. :) | 06:05 |
oz4ga | SNAFU resolved. Most likely cause "to much cleverness". If I ever find out I have a half brother named Murphy, I'm going to strangle hin :D | 06:18 |
oz4ga | I don't understand where I fscked up, but I guess I learn down road. | 06:20 |
oz4ga | Now back from work and back to my bootstrapping exercise. I'm trying to get Chimera to run natively on ZFS. ZFS because I'm from FreeBSD, so I'm VERY biased in favor of all the ZFS goodness. I went through the process successfully using a Debian BullsEye. I started there because Open-ZFS has a spoon feed article about how to do this. I works like a charm. Do now to Devuan. It manly the same BUT, I've run into a nasty problem. grub-prob doesn't grog zfs . | 17:37 |
oz4ga | grub-probe /mnt/home return "error: unknown filesystem." My zpool is mounted in /mnt and /mnt/home is a separate zfs filesystem. since grub-probe doesn't grog grub-install doesn't either | 17:37 |
oz4ga | Any sugestions to what I'm misssing? | 17:37 |
fsmithred | debian and devuan have the same grub packages. | 17:39 |
onefang | I also don't grok ZFS, but I do know it is "grok" not "grog". | 17:39 |
oz4ga | looking at https://askubuntu.com/questions/1351665/zfs-grub-zfs-detection-failed there is an indication of a file in /etc/grub.d by the mane 10_linux_zfs is missing. it is indeed missing. the solution was to down load tha file. but from where? | 17:40 |
oz4ga | sry about grog and grok ;) | 17:40 |
fsmithred | where did you get that file for debian? | 17:42 |
oz4ga | fsmithred: isn't mixing debian and devuan packages a bad idea? should I install a debian and lift it out from there? | 17:42 |
fsmithred | no, you shouldn't need to | 17:43 |
fsmithred | anything that's in the debian repos is automaticall in our repos, except for those things that require systemd. | 17:43 |
fsmithred | was it in a third-party package? | 17:44 |
oz4ga | I only have a limited amount of disks, but ys I coud redo it all again on another disk in debian. I did EXACTLY the same in devuan as in Debian. I even aborted all my "smartness" | 17:44 |
oz4ga | nono | 17:44 |
oz4ga | all i did was apt install linux-headers-amd64 zfs-initramfs zfs-dkms zfs-zed zfsutils-linux | 17:46 |
oz4ga | the last 2 I had to do twice bccause of ? | 17:46 |
fsmithred | I just added bullseye main contrib non-free to my chimaera, updated, updated apt-file and I can't find that file in debian. | 17:47 |
fsmithred | are you sure you didn't add another repo to /etc/apt/sources.list.d? | 17:48 |
oz4ga | I installed nala in both cases, but thats all | 17:49 |
fsmithred | what's that? | 17:50 |
oz4ga | a qute frontend to apt | 17:50 |
fsmithred | did you check devuan forum for any zfs posts? | 17:53 |
oz4ga | I'm apparently doomed Sisyphus, so why not do it again in debian. Just to se it recognice zfs | 17:53 |
fsmithred | https://dev1galaxy.org/viewtopic.php?id=2506 | 17:53 |
fsmithred | https://dev1galaxy.org/viewtopic.php?id=3794 | 17:53 |
oz4ga | they all point to the open-zfs page about bullseye | 17:54 |
fsmithred | check those first. Maybe they know what to do. | 17:54 |
oz4ga | I'va alreay read them. IT's basicall what I'm doing. | 17:55 |
oz4ga | hey there is another boulder!!! I better roll up to the top of the mountain. and pinky swear I'll use none of my scriped smartness | 17:56 |
oz4ga | so grok == understand and grog == pirate boze ? | 18:03 |
nemo | y | 18:03 |
onefang | Grog is booze, not always pirate. | 18:03 |
nemo | first one being from Robert A Heinlein's "Stranger in a Strange Land" | 18:03 |
onefang | Yep. | 18:03 |
nemo | http://www.catb.org/jargon/html/G/grok.html | 18:04 |
oz4ga | I don't drink, but I remember it from the Game Monkey Island :) | 18:04 |
fsmithred | Gee! | 18:04 |
oz4ga | And talk like a pirate ofc | 18:05 |
oz4ga | ok i won't use any of those words | 18:05 |
joerg | searching for "/etc/grub.d/10_linux_zfs" first hit is >>update-grub 10_linux_zfs fails when /usr is a separate filesystem<< [https://bugs.launchpad.net/bugs/1899372] -- straaaange coincidence | 20:02 |
joerg | >> The 10_linux_zfs script is gathering information from /etc/os-release which is a symlink to ../usr/lib/os-release.<< what could possibly go wrong | 20:04 |
rwp | Hmm... With ZFS it is typical and normal to have /usr as a separate dataset. At least on other operating systems such as FreeBSD. | 20:05 |
rwp | I suspect that moving forward that ZFS on Devuan/Debian will require ZFS to converge /usr into / as if it were not ZFS. | 20:06 |
rwp | Hmm... But ZFS datasets are not the same as separate partitions. I don't see how you could have a ZFS root dataset mounted but not have a /usr dataset mounted. Hmm... | 20:11 |
neotao | So what's devuan doing about usrmerge? | 20:11 |
joerg | I guess it's several years too late to do anything about it | 20:12 |
rwp | Since Devuan is an overlay on Debian it makes it very hard to not follow Debian upstream for these things. | 20:13 |
joerg | ^^^ | 20:13 |
joerg | init freedom isn't just a question of which binary gets started as PID1, it's also about FHS and other properties of your system that are prerequisites for certain init strategies | 20:15 |
rwp | I know the devs have had some discussion of how Devuan should react to UsrMerge and the discussion has sounded rational to me but that doesn't mean the path will be an easy one. | 20:17 |
rwp | They can't really stop it. Yet riding through it also has much breakage. My opinion is that they can only try to smooth out the bumps as much as possible. | 20:17 |
joerg | would need a usrUNmerge devuan thing | 20:18 |
neotao | haven't followed what the devs plan, what's the summary of those discussions? | 20:21 |
joerg | I didn'T follow the details either since ages, I just a few days ago found this very enlightening LWN article https://lwn.net/Articles/773342/ | 20:23 |
joerg | ( December 4, 2018 ) | 20:23 |
neotao | wasn't aware that this proposal is already 10 years old | 20:24 |
neotao | that said, the distinction between / and /usr always struck me as odd | 20:25 |
rwp | I always feel it odd that if one were converging one would convert from /bin into /usr/bin instead of the opposite way of moving /usr/bin into /bin. | 20:27 |
rwp | That LWN highlighting the problem of hard coded paths highlights the problem of hard coded paths. But hard coded paths are really a separate problem which is truly Evil. | 20:28 |
onefang | And easily solved with links. | 20:28 |
neotao | rwp: true, but moving everying from /usr/* to / would clutter the root fs significantly | 20:30 |
rwp | Better solved by fixing the evil use of hard coded paths. | 20:30 |
neotao | I haven't made up my mind yet on this fwiw | 20:30 |
rwp | neotao, Clutter here. Clutter there. It going to be the same either place. | 20:31 |
rwp | I have lived through the merge before on other systems. I don't like it. I really don't like seeing #!/usr/bin/sh in scripts because that happens afterward. | 20:31 |
neotao | looking at /usr, a /games rootdirectory would be kinda cute | 20:31 |
rwp | We can rant about it further on #devuan-offtopic as most of us do there. | 20:34 |
neotao | yeah, sorry | 20:34 |
onefang | In chimaera there is the usrmerge package, that canverts to usrmerge, and includes setting up symlinks. I debootstrapped chimaera, and installed that manually. No issues for me. | 20:34 |
joerg | >><rwp> Better solved by fixing the evil use of hard coded paths<< sounds good. But AIUI those different paths imply other info relevant for lean init systems, i.e. the distinction which lib or binary is available to PID1 (and bootloader etc) and which isn't. the merge irrecoverably drops that info so a usrUNmerge gets really tricky | 20:41 |
brocashelm | if anyone is using ceres and sees an update for libffi8, do not install (dodge the bug with apt-listbugs and try again): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020488 | 20:41 |
brocashelm | new builds will be propagated soon which should fix the error | 20:42 |
joerg | btw also AIUI the "usrmerge" package is [ quote https://www.linux-community.de/ausgaben/linuxuser/2019/08/zusammengefasst/2/ ] >>just a package that runs a script that does the merge to the directory structure (after asking the user if they really want to do this since this conversion can not be undone ) and once all got reconfigured, the user may UNinstall the usrmerge package again<< | 20:47 |
joerg | >> Bestehende Systeme tastet das Setup nicht an, es sei denn, der Nutzer wünscht es. In diesem Fall genügt es, das Paket usrmerge zu installieren, das die entsprechenden Verzeichnisse verschiebt und die weiteren Anpassungen vornimmt. Bei der Installation fragt Debian explizit eine Bestätigung ab, da sich die Umstellung nicht zurücknehmen lässt. Kontrollieren Sie nach der Umstellung, ob das Verzeichnis /etc/dpkg/dpkg.cfg.d/usrmerge existiert und ob es | 20:50 |
joerg | Paketnamen enthält. Ist das der Fall, bedeutet das, dass es mit diesen Paketen noch Konflikte gibt. Bleibt es leer oder existiert nicht, können Sie usrmerge wieder entfernen;<< | 20:51 |
rwp | joerg, I read your words about other info but I do not understand what you are trying to tell me there. | 21:10 |
rwp | Instead of freezing paths one should rely upon PATH to provide all needed executables. | 21:10 |
rwp | Otherwise there are problems of portability. Portability from one OS to another certainly but in this case it is portability from one configuration of the current OS to another configuration of the current OS. | 21:10 |
rwp | That R package example from LWN is due to an often seen anti-pattern. Look for a binary at some particular moment of configuration time and in some particular configuration. Then freeze that found path into a hard coded path in the resulting installation. | 21:11 |
rwp | I find that particularly bad. In order to make things work as part of $DAYJOB I have had to hack fixes into those many times over the years. | 21:12 |
rwp | So now it is a pet peeve of mine. | 21:13 |
rwp | Interestingly when I was doing this type of thing full time at $DAYJOB I found one of the worst portability example was "basename". | 21:14 |
rwp | On Debian derived systems it was in /usr/bin/basename and on Red Hat derived systems it was in /bin/basename. | 21:15 |
rwp | As mentioned a symlink works around the problem. But why did so many people feel compelled to hard code in the full path? | 21:15 |
rwp | Just call basename and let it be found on PATH and there would have been no problem at all. | 21:15 |
joerg | rwp: PATH is a concept of shell basically, no? | 21:17 |
rwp | Everything mentioned so far about hard coded paths has mostly been shell. | 21:18 |
rwp | But what about execvp(2)? | 21:18 |
rwp | My example of needing to hack scripts hard coding in /bin/basename were all shell scripts. | 21:20 |
rwp | But anyway... I know the UsrMerge advocates will point to this and say, See? It makes that problem go away. Bah! I say it just hides it. | 21:21 |
joerg | rwp: >>[22 Sep 2022 20:04:57] <joerg> >> The 10_linux_zfs script is gathering information from /etc/os-release which is a symlink to ../usr/lib/os-release.<< << hardly solved by using $PATH alike concepts | 21:21 |
rwp | That's a different problem entirely! | 21:21 |
rwp | My hard coded path rant was concerning the https://lwn.net/Articles/773342/ particular problem with R described there. | 21:22 |
rwp | The problem of /etc/os-release symlinking to a /usr mount point and the /usr mount not being available at the time is a different problem. | 21:23 |
rwp | I don't know how with zfs though that only some of the datasets would be mounted. But I have never tried zfs with a GNU/Linux OS system yet. I need to try it. | 21:24 |
joerg | me mentioning the LWN article was rather to show how unifying /usr/bin and /bin is dropping some relevant implied infos and all that's been done since is not really helping to fix the problems (to other init approaches) that ensue from that | 21:25 |
rwp | I agree that combining those two directories drops meta information such as where files were originally meant to be installed. That's definitely lost. | 21:26 |
rwp | And hence my comment about seeing #!/usr/bin/sh then start to show up in scripts. | 21:27 |
joerg | not only where, also when, if you dare to have a separate /usr partition | 21:27 |
joerg | and I still wonder who decides of acmeplay binary goes to /usr/bin or to /bin | 21:28 |
rwp | Historically the decision was based upon the core part of the OS that was needed to cold boot the system. | 21:29 |
rwp | Anything needed by init was in /bin and /lib and everything that was not part of that core was in /usr/bin and /usr/lib | 21:30 |
joerg | exactly, and that's depending on ... the init system | 21:30 |
rwp | Yes. And I assume that was why Red Hat put basename in /bin instead of /usr/bin like Debian did. Because it was apparently needed to boot on RH systems. | 21:31 |
rwp | So... I don't understand the motivation for UsrMerge. Because what's the problem? | 21:34 |
rwp | Freeze the list of core components in /bin as they are and then by policy everything else goes in /usr/bin which seems simple enough to me. | 21:34 |
rwp | Scripts, programs, everything, should not be using hard coded paths and should use PATH to locate executables. | 21:35 |
joerg | YEP, on the point. Seem up til now it's up to the distro maintainers what to put on rootfs and what to put on usr-fs, and when somebody needs a flashplayer to talk to the webui of the UPS during system boot, then... we prolly got a layering problem or what it's called? | 21:35 |
rwp | "when somebody needs a flashplayer to talk to the webui of the UPS during system boot"... And then you have many more than two problems! :-( | 21:36 |
rwp | But yes I think you have described the problem. Everyone thinks their niche thing should be in the OS core. | 21:37 |
onefang | Think you have gone well beyond #devuan support channel and should take it to #devuan-offtopic now. | 21:37 |
rwp | Everything can't be in core. Except the UsrMerge advocates say that the distinction is erased. | 21:37 |
rwp | onefang, Agreed. But instead I be afk for a while. Thanks all! | 21:38 |
joerg | yes of course, sorry really plausible examples are hard to unvent in a minute. In smartphone bootup for example, some manuf might want to play a video with audio during boot process, but... the gstreamer player can't run at that point since it isn't even mounted yet | 21:38 |
joerg | onefang: right | 21:40 |
dan9er[m] | How did Devuan remove the systemd dependency for libwacom? I'm looking to make an issue at https://github.com/linux-surface/libwacom whose packages do depend on systemd, and I can't see any systemd service files in their repo. I looked at Chimaera's libwacom2 package and the maintainer is listed at a Debian address | 21:50 |
brocashelm | afaik, libwacom packages are not forked by devuan. anything with "devuan" in the version is forked by devuan | 22:14 |
brocashelm | the reason devuan has "a lot of packages" is due to amprolla merging debian's repos with devuan's repos (their 200 or so forked packages replacing blacklisted debian packages) | 22:15 |
dan9er[m] | brocashelm: I know what amprolla does ("layerfs" for APT source) | 22:53 |
dan9er[m] | Looking at Debian bulleye's libwacom packages, they don't seem to have systemd shit in them | 22:53 |
dan9er[m] | https://packages.debian.org/bullseye/all/libwacom-common/filelist has some udev rules but eudev handles those | 22:54 |
dan9er[m] | And yet linux-surface's libwacom explicitly depends on systemd | 23:01 |
dan9er[m] | yeah #linux-surface-support:matrix.org has some explaining to do | 23:01 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!