| rs | what is the general consensus when it comes to a newly released stable -- when is it a good idea to upgrade to the new testing branch? | 00:05 |
|---|---|---|
| critr | you can just enable backports repo in sources.list and enjoy some of the benefits of newer stuff with less risk of instability. | 00:09 |
| rs | never been a fan of backports, i prefer a mixed system with testing being the base | 00:10 |
| gnarface | there has been some noted upgrade complaints, but it sounds like you're used to worse | 00:11 |
| fluffywolf | ok, this is trying to be the worst upgrade I've ever done. chimaera is not ready yet. | 00:53 |
| golinux | Maybe if we'd had more testers things would have been better. (hint, hint) | 01:10 |
| fluffywolf | unfortunately, I don't have time to repeatedly break the only computer I actually use to test things... | 01:10 |
| fluffywolf | new issue: it now hibernates if I shut the lid. it did not before the upgrade. I do not have a DE. This is very, very broken behavior - an upgrade should not cause your computer to start turning itself off. I don't even know what's doing it. | 01:11 |
| golinux | Have you reported all those things for evaluation? | 01:12 |
| fluffywolf | report to who? heh | 01:12 |
| golinux | Debian package to Debian. Devuan package to Devuan. | 01:13 |
| fluffywolf | but I don't know what package is doing it! lol | 01:13 |
| golinux | Well then, all your pain will have little benefit to make the situation better. | 01:13 |
| golinux | Read logs for starts | 01:14 |
| gnarface | if it's working normally it's something tied to acpid | 01:18 |
| lfluffywof | grrrrrrrrrr | 01:19 |
| lfluffywof | somehow network-manager got installed, but if I kill it, wicd breaks too! | 01:19 |
| lfluffywof | it seems its last step on exiting is to break the interfaces such that I have to restart wicd | 01:20 |
| gnarface | did avahi-daemon also get installed? | 01:20 |
| lfluffywof | yep, looks like it. | 01:20 |
| gnarface | i recommend next time upgrading without "recommends" | 01:20 |
| * fluffywolf fixes that | 01:20 | |
| * fluffywolf also uninstalls network-manager | 01:21 | |
| fluffywolf | why did it downgrade from the 5.14-bpo kernel to 5.10? this broke things, and is a distinctly lower version number in every way. also, apt now has a feature that removes all other kernels? | 01:22 |
| fluffywolf | I had to re-install the 5.14 kernel. I didn't notice it was trying to install a downgrade version... | 01:22 |
| golinux | wicd is dead until someone ports it to python3 | 01:22 |
| fluffywolf | wicd is buggy shit, but it makes my wireless interface work, unlike everything else I've tried on this laptop. heh. | 01:23 |
| golinux | someone is working on that. | 01:23 |
| fluffywolf | it's probably partially kernel bugs. I had to write a script to reload the iwlwifi module when it dies... | 01:23 |
| golinux | Have you see rrq's howto? https://www.devuan.org/os/documentation/install-guides/chimaera/network-configuration | 01:25 |
| fluffywolf | it drops the access point and won't re-authenticate (times out) until the module is reloaded. haven't found any way to get it to work again without reloading the module. | 01:25 |
| Joy-Unit | ceni always worked forme | 01:25 |
| fluffywolf | GRERRRRRRR!#@!@#@#!@#$ | 01:25 |
| fluffywolf | THIS UPGRADE IS NOT READY YET. | 01:25 |
| fluffywolf | I should never have fucking upgraded so close to something being released. | 01:26 |
| golinux | It WAS released well over a week ago. | 01:26 |
| fluffywolf | both chromium and firefox got upgraded during the upgrade. now EVERYTHING starts chromium instead of firefox. | 01:27 |
| golinux | Officially. | 01:27 |
| ksx4system | fluffywolf, test before upgrade for production environments :) and preferably virtualize whatever possible to replace instances instead of upgrading | 01:27 |
| ksx4system | (but that's just one way to do it, you can yolo it like me and just fix stuff if needed) | 01:27 |
| fluffywolf | I'd gotten complacent. debian and every other devuan upgrade has been mostly painless for a while. | 01:28 |
| ksx4system | there's lot of messages during upgrade process, READ THEM ALL and react as needed and everything will be fine :P | 01:29 |
| * ksx4system thinks that Chimaera is good to go | 01:30 | |
| rwp | Things have gotten worse in recent years. The vision and goal of those putting the upstream software together is not the same as yours and mine. | 01:30 |
| rwp | Meanwhile... If everything is starting Chromium now... There are two files to check. | 01:30 |
| fluffywolf | and update-alternatives doesn't seem to like me. | 01:30 |
| rwp | Look at ~/.config/mimeapps.list for one of them. Check that. Probably removing the file after review. | 01:30 |
| fluffywolf | update-alternatives still shows firefox | 01:31 |
| fluffywolf | so why when I, for example, click links in xfce4-terminal, do they open in chromium? does it not listen to the alternatives system? | 01:31 |
| rwp | And I can't remember the file name of the file that sets "the default" web browser. Anyone? | 01:31 |
| fluffywolf | rwp: it should be update-alternatives --config x-www-browser ... | 01:32 |
| ksx4system | rwp: x-www-browser maybe? | 01:32 |
| rwp | I agree that the alternatives are one way. But the freedesktop.org folks don't use it. They have, once again, done their own thing uniquely differently. | 01:32 |
| rwp | It's a file in ~/.local/something or ~/.config/something. I am digging around now... | 01:33 |
| fluffywolf | upgrades should not change behavior like this. | 01:34 |
| fluffywolf | googling suggests I now have to use the full xfce4 crap just to use their terminal? | 01:35 |
| fluffywolf | has xfce now become totally freedesktop shit that I need to purge? | 01:36 |
| rwp | Argh I can't locate it! But both firefox and chromium have options in Settings to make themselves the "default browser". | 01:36 |
| rwp | Pretty much all of the Desktop Environments have become downstreams of freedesktop.org cruft. | 01:36 |
| rwp | i3 FTW! | 01:37 |
| fluffywolf | I suspect, from what I'm finding googling, that the newer xfce4-terminal now uses browser info from some blobular freedesktop database and entirely ignores debian alternatives and every other sane way of changing it. | 01:37 |
| ksx4system | rwp: Openbox > i3 any day | 01:37 |
| fluffywolf | I use icewm. | 01:38 |
| rwp | All good! ykinmkbykiok. :-) | 01:38 |
| * ksx4system will have to try MaxxDesktop or whatever was name of that IRIX desktop clone project | 01:39 | |
| critr | sounds like kde. try to install any kde app without pulling in half of kde with it. | 01:41 |
| rwp | Look at the time! Interruptions have been my life today. Gotta run. But do check ~/.config/mimeapps.list to see what browsers might be set there. | 01:42 |
| fluffywolf | why the hell would it be using a mime anything to click links in a terminal emulator? | 01:42 |
| fluffywolf | everything browser-related in that file says firefox-esr | 01:43 |
| fluffywolf | good god I hate everything to do with freedesktop. | 02:02 |
| fluffywolf | root@cfbox:~# xdg-settings set default-web-browser "firefox.desktop" | 02:02 |
| fluffywolf | root@cfbox:~# xdg-settings get default-web-browser | 02:02 |
| fluffywolf | chromium.desktop | 02:02 |
| fluffywolf | this is clearly broken, since it's silently failing. | 02:03 |
| fluffywolf | poking at xdg-settings source, it tries to detect your de. I'm guessing it silently fails if you're not running one? | 02:05 |
| fluffywolf | I don't even know if this is a debian bug, or a devuan bug for shipping packages that depend on fdo's shit... | 02:11 |
| Stargoose2 | Hello there. I am trying to disable some services on Devuan using "update-rc -f <name> remove", but there are some services that still come up at boot, like networking-routes | 02:12 |
| Stargoose2 | So, for example, how can I disable networking-routes? | 02:12 |
| Stargoose2 | I am new to Devuan, sorry if it is a very basic question | 02:12 |
| fluffywolf | I'm not familiar with networking-routes, and it doesn't seem to exist on my system. what is it? | 02:13 |
| Stargoose2 | fluffywolf: I don't even know, just trying to disable all network services since this machine won't use a network | 02:14 |
| fluffywolf | "networking" is the rc.d entry | 02:15 |
| Stargoose2 | fluffywolf: so if I disable "networking" it will take "networking-routes" with it? | 02:16 |
| fluffywolf | I'm not sure what networking-routes is, so no idea. lol | 02:16 |
| fluffywolf | you'll want to make sure network-manager is uninstalled, too. | 02:16 |
| Stargoose2 | ah, ok | 02:17 |
| fluffywolf | hrmm, and I just found a bug. I removed network-manager myself (I don't like it), but it still has rc.d entries, so the package uninstallation didn't clean up after itself very well. | 02:17 |
| Stargoose2 | it's not installed here | 02:17 |
| fluffywolf | if you don't have network-manager, and you don't manually configure any interfaces, it shouldn't have networking configured. | 02:20 |
| Stargoose2 | it's not configured, I simply don't know how to disable networking-routes in a... polite way. I could delete it's symlink in /etc/rcS.d | 02:21 |
| Stargoose2 | oh my.. even deleting /etc/rcS.d/networking-routes, the thing still comes up at boot | 02:22 |
| fluffywolf | what devuan version are you using? | 02:23 |
| Stargoose2 | 4.0 Chimera on arm64 | 02:24 |
| fluffywolf | hrmm. I don't know enough to help you then, I'm sorry... | 02:24 |
| Stargoose2 | thanks anyway for trying :) | 02:24 |
| fluffywolf | is this actually a service that's running, or just something that configures things on startup? | 02:27 |
| fluffywolf | removing ifupdown-extra package might remove it | 02:28 |
| fluffywolf | what init system are you using? | 02:28 |
| Stargoose2 | fluffywolf: I guess I am using sysvinit, which is the default if Im not mistaken | 02:29 |
| Stargoose2 | And it seems to be a service that is running | 02:29 |
| Stargoose2 | I could disable it by doing chmod -x on /etc/init.d/networking-routes | 02:29 |
| Stargoose2 | But that's a disaster... | 02:29 |
| rrq | does "dpkg -S networking-routes" say something? | 02:30 |
| Stargoose2 | yep, seems to belong to ifupdown-extra | 02:30 |
| Stargoose2 | but I may need to bring eth0 or wlan0 up manually later | 02:31 |
| rrq | so, "apt-get purge ifupdown-extra" might be useful | 02:31 |
| Stargoose2 | So uninstalling infupdown-extra might not be a good idea... | 02:31 |
| rrq | do you need "static routes" ? | 02:31 |
| Stargoose2 | nope | 02:32 |
| rrq | so, "apt-get purge ifupdown-extra" might be useful | 02:32 |
| Stargoose2 | ok :D | 02:32 |
| fluffywolf | I don't have that package installed; I only identified it by googling for that filename. heh. | 02:34 |
| fluffywolf | so it can't be too important! | 02:34 |
| rrq | Stargoose2: then remove any "auto xxx" except "auto lo" from /etc/network/interfaces, and also remove any "allow-hotplug xxx" | 02:34 |
| rrq | and then purge any "network manager" (other than ifupdown) you might have | 02:35 |
| fluffywolf | bbl, my neighbor needs a ride | 02:35 |
| rwp | I don't have ifupdown-extra installed. Never heard of it before. It hasn't been popular with me! :-) | 02:45 |
| Stargoose2 | rrq: I think I got the workflow here.. look for the package that installs the script in /etc/init.d, and remove the package with apt :) | 02:45 |
| rwp | Look closely at anything it is going to remove. apt, apt-get, aptitude, etc will make the dependencies work. So if you try to remove something that your desktop depends upon it will state that it will remove your desktop and do it if you okay it. | 02:45 |
| Stargoose2 | rwp: I don't have a desktop, don't worry :) | 02:50 |
| Stargoose2 | But thanks! | 02:50 |
| Stargoose2 | rrq: any idea about where /etc/init.d/zramswap comes from? dpkg -S does't know about it | 02:53 |
| Stargoose2 | where can I look? | 02:54 |
| rwp | The DE removal was just an example. It's mostly fine! | 02:54 |
| rwp | Since you are going to be doing a lot of file searching you should check out https://pkginfo.devuan.org/ | 02:55 |
| rwp | However /etc/init.d/zramswap doesn't seem to be part of any package. | 02:56 |
| rwp | That will be the compressed ram stuff. | 02:56 |
| Stargoose2 | rwp: so the only way to remove the zramswap service is by deleting /etc/init.d/zramswap, right? | 02:57 |
| gnarface | zram-tools maybe | 02:58 |
| Xenguy | Was just gonna say | 02:59 |
| Stargoose2 | gnarface: but where can I find that it belongs to zram-tools? As I said, dpkg -S doesn't give me that information | 02:59 |
| Xenguy | apt-cache search found it | 02:59 |
| Xenguy | apt-cache search zramswap | 03:00 |
| Stargoose2 | Xenguy: do you mean apt-cache search zram? | 03:00 |
| Xenguy | I assume that would work also | 03:01 |
| gnarface | Stargoose2: don't delete init scripts. try out sysv-rc-conf | 03:02 |
| Xenguy | sysv-rc-conf is what I use. Seems to work nicely | 03:04 |
| Stargoose2 | Hmm... I don't see sysv-rc-conf installed on my system, the command is not found | 03:05 |
| gnarface | it's another optional package you'd have to install | 03:05 |
| gnarface | you don't have to use it, you can manipulate the symlinks by hand instead but it's probably easier | 03:05 |
| rwp | Agreed. Don't delete init scripts. Remove/Purge the package holding it instead. | 03:06 |
| gnarface | yea or just purge the whole thing | 03:06 |
| Stargoose2 | gnarface: I would need the machine in question connected to a network which is not the case for now :) | 03:06 |
| Stargoose2 | yes, purging is what I consider the main option | 03:06 |
| gnarface | apt-get --purge remove zram-tools | 03:06 |
| Stargoose2 | thanks to you guys it's getting clearer and clearer now | 03:06 |
| gnarface | but note you might need it | 03:06 |
| gnarface | if it's installed already, someone put it there on purpose | 03:07 |
| gnarface | most likely | 03:07 |
| Stargoose2 | nah, I never need a swap on the Pi4 ;) | 03:07 |
| Stargoose2 | it's been 10 years of Pi with no swap here | 03:07 |
| rwp | What would automatically install zram-tools? That's so strange. | 03:08 |
| Stargoose2 | rwp: it comes preinstalled on the arm64/pi4 image | 03:08 |
| Stargoose2 | not so strange: who did the image thought that the physical memory on the Pi can be not enough in some cases | 03:09 |
| rwp | What installer did you use? That's the root cause of everything. The installer has opinions. | 03:09 |
| gnarface | well, if you disable it by symlinks then you can enable it again without a network connection. if you purge it you might need a network connection to get it back | 03:09 |
| Stargoose2 | No installer, just flashed the Pi4 image to a microSD | 03:09 |
| Stargoose2 | gnarface: It will be manually connected (via the ip command etc) later | 03:09 |
| rwp | That's just as much of an installer as anything. Other installers are image copiers too. Then the copied image has already made various choices. | 03:09 |
| Stargoose2 | rwp: oh, well, you are semantically correct :) | 03:10 |
| rwp | If working with the /etc/rc?.d/{S,K}* symlinks directly always remember that there needs to be at least one symlink there to inform the tools that it has been locally modified. | 03:10 |
| rwp | If you remove all of the symlinks then the tools assume it is a pristine installation and will install the symlinks that a pristine installation gets. | 03:10 |
| Stargoose2 | rwp: I am not manipulating the symlinks anymore. It's good to know how it works under the hood, but I will uninstall the packages or use the tools | 03:11 |
| Stargoose2 | These manipulations were just initial experiments I have reverted | 03:11 |
| Stargoose2 | Any idea on how can I locate the package for /etc/init.d/bthelper? This one doesn't appear to be known to dpkg -S or apt-get cache search.... | 03:12 |
| gnarface | generated files you're pretty much SOL unless google knows | 03:13 |
| gnarface | but usually it matches the package name or part of the package name | 03:13 |
| gnarface | "bt" probably means bluetooth but i'm just guessing | 03:13 |
| Stargoose2 | gnarface: yes, it's bluetooth-related | 03:13 |
| gnarface | there's scripts that fire on package installation, before and after | 03:14 |
| gnarface | sometimes they make extra files that aren't in the actual package list | 03:14 |
| gnarface | usually /etc/ stuff | 03:14 |
| rwp | Another place to look is: grep /etc/init.d/bthelper /var/lib/dpkg/info/* | 03:14 |
| rwp | If it is not registered with dpkg as a "conffile" then it might be created entirely in the package postinst scripts. | 03:15 |
| Stargoose2 | rwp: grep /etc/init.d/bthelper /var/lib/dpkg/info/* does not give any results | 03:16 |
| Stargoose2 | so this bthelper can safely be deleted (never gonna use BT here) | 03:17 |
| Stargoose2 | right? | 03:17 |
| rrq | yes, but use "update-rc.d bthelper disable" first | 03:19 |
| fluffywolf | only thing I'm finding googling is it's some rpi-specific thing? | 03:23 |
| fluffywolf | is this an rpi you're working on? | 03:24 |
| rwp | My network went away for a while. Expect my client to catch up in a moment and print out something from a couple of minutes ago. | 03:28 |
| gnarface | the rpi images are created differently, it might be worth checking the setup scripts for that | 03:28 |
| gnarface | sources should be on the gitlab | 03:28 |
| gnarface | i think? | 03:29 |
| rwp | I would double check less specifically, in case it isn't using the full path or is using a variable: grep bthelper /var/lib/dpkg/info/* | 03:29 |
| rwp | Sometimes the RPi specific stuff is just hacked in without really following all of the rigorous procedures. | 03:29 |
| Stargoose2 | I got a LOT of information today here, thanks a reeeeal lot, guys. You have been really friendly to me and my strange english :D | 03:31 |
| Stargoose2 | Do you guys know how to set TTY autologin? | 03:34 |
| Stargoose2 | Ah, seems to be an fstab edit like in the old times! :D | 03:38 |
| Stargoose2 | I mean inittab | 03:38 |
| fluffywolf | is this an rpi? | 03:41 |
| Stargoose2 | fluffywolf: yes | 03:41 |
| systemdlete | bareos supports tls 1.3? | 05:34 |
| systemdlete | (just checking, that's all) | 05:34 |
| systemdlete | I mean devuan, not bareos. Bareos definitely needs it. | 05:35 |
| systemdlete | (didn't sleep well last night, so my mind is a bit scrambled atm) | 05:36 |
| systemdlete | actually I doubt this is going to work anyway. I'm trying to run an older bareos 18 director to a a bareos 20 client. That is probably not the least bit supported. | 05:38 |
| * systemdlete wonders why he even thought of trying such a combination... | 05:39 | |
| systemdlete | nvm | 05:39 |
| systemdlete | I'll take my scrambled brains somewhere else... | 05:39 |
| error144 | hi all, yesterday and thanks to rrq, I managed to make devuan-installer-iso work, I take it from there and tried to customize it so it has my own distro in it, but I couldn't, here is what I tried so far: | 13:45 |
| error144 | -Mask all repositories beside debian-installer, result was the tool just broke | 13:46 |
| error144 | -run build.sh, didn't work | 13:46 |
| error144 | -used custom inputs for build-sudo.sh, breaks it up | 13:46 |
| error144 | -tried to change netinstall.mk, didn't work | 13:47 |
| error144 | anyone knows how I can make this tool only use my distro packages, and only use my distro window manager, and not download gnome and such? | 13:48 |
| Joy-Unit_ | can you rephrase your question please, error144? | 13:48 |
| error144 | how to customize devuan-installer-iso to only use existing packages to build the iso file? | 13:49 |
| Joy-Unit_ | question is clear now, thanks. i don't know. | 13:50 |
| error144 | Joy-Unit_, no problem, thanks for pointing that out. | 13:51 |
| rrq | error144: first you'll need to have a debootstrap, thereafter the source list points are in build-sudo.sh | 13:54 |
| rrq | of course the building will need the programs it needs, so "your" repo(s) need to provide them | 13:55 |
| error144 | you mean I must have a tool named "debootstrap"? if so then yes, I have it installed, what next? | 13:56 |
| error144 | "source list points are in build-sudo.sh" you mean what's in #configure apt? | 13:57 |
| error144 | in the git page, it says that only debian-installer is needed, the rest are not, so should I comment them? | 13:57 |
| rrq | lines 43-45 of build-sudo.sh defines the sources.list used in the build system (the chroot) | 13:59 |
| error144 | rrq, so should I remove them in my case? | 14:00 |
| rrq | those sources.list points are used firstly for populating the builds system, and secondly to define the span of posibilites for populating the installer iso | 14:00 |
| rrq | if you want to use different repo(s), that's where you define them | 14:01 |
| error144 | OK, I understood, what next? | 14:02 |
| rrq | the initial debootsrap source i s set at line 10 of build-sudo.sh | 14:02 |
| rrq | if you want a dfferent repo for that, then that's whre you set that | 14:02 |
| error144 | understood, what next? | 14:03 |
| rrq | then it's just a matter of ensuring tat the repo(s) you've define indlcude the programs (and libraries) needed | 14:03 |
| error144 | they do, so how I am going to define what will be in the Iso? | 14:05 |
| rrq | as I mentioned yesterday, the iso content is configured based on the package lists in the pool/ directory, and they get downloaded using those same sources.list points | 14:05 |
| error144 | I checked pool directory, and I couldn't found how to do that? | 14:06 |
| error144 | also there is no "netinstall" file for that? | 14:06 |
| rrq | teh only escape is for the dvd and cds, which uses the "by-vote" list obtained from debian's popcon (or maybe devuan's; I don't rememeber) | 14:06 |
| rrq | you'll see it in hte Makefile | 14:06 |
| rrq | there's a NETINSTALL_something target | 14:07 |
| rrq | which depends on its collection of lists files | 14:07 |
| error144_ | rrq sorry for being noob, but I can't see it? | 14:08 |
| rrq | pool/Makefile:85-87 | 14:09 |
| error144_ | NETINSTALL_LIST_ ... all-required all-important | 14:11 |
| error144_ | should I remove the last two words? | 14:11 |
| rrq | perhaps. why? | 14:12 |
| error144_ | so it doesn't add all the useless packages into the iso? | 14:13 |
| error144_ | and only add the packages that are used | 14:14 |
| error144_ | yesterday when I finish the build, I booted it up to see what changed, and it installed normal devuan, without anything I added? | 14:14 |
| rrq | yes, all-required and all-important are two package lists that gets created by finding the packages in the available package collection that have those priorities | 14:15 |
| error144_ | ok, I will remove them, what's next? | 14:15 |
| rrq | if you don't want that on the ISO than removing those dependencies will work | 14:15 |
| rrq | for that | 14:15 |
| error144_ | ok, do you know how to change "desktop enviroment" list on the installer? | 14:16 |
| error144_ | my custom distro uses a window manager named "dwm", when I installed the build of yesterday, I didn't found it, nor found its files? | 14:17 |
| rrq | if you build a netinstall then that's irrelevant | 14:17 |
| rrq | but the installer itself has a few lists of packages of degrees of necessity | 14:17 |
| error144_ | I choose netinstall thinking that it will have less packages + the packages I used in my distro | 14:18 |
| error144_ | since the desktop build is 4GB I thought it does install packages that are not used as well | 14:18 |
| rrq | yes the desktop iso is named DVD1 in the pool | 14:20 |
| rrq | and its package list preparation is a few lines down | 14:21 |
| buZz | error144_: yeah i always go for minimal installs too | 14:21 |
| buZz | there's not a lot of reason to install 4GB worth of packages for the yolo :P | 14:21 |
| error144_ | buZz I hate when I use a distro for so long, and I check the installed packages and found like 1000 unused packages :( | 14:23 |
| buZz | :) | 14:23 |
| error144_ | =( | 14:23 |
| Joy-Unit_ | if you want simplicity you must walk the narrow path | 14:24 |
| error144_ | rrq so should I go with desktop one removing server headers and desktop by_vote-00? | 14:25 |
| rrq | yes that's the kind of thing you'll need to do to change the iso content | 14:27 |
| error144_ | rrq done, what's next? | 14:27 |
| rrq | if you want to change the installer's behaviour, you'll have to modify the udebs involved | 14:29 |
| error144_ | ok, how to do that? | 14:29 |
| rrq | you would change them to suit, build their new versions for yurself, and put them in "localudebs" to override | 14:30 |
| rrq | some udebs are forked and some are directly from debian | 14:31 |
| rrq | it'd be the normal way of cloning the source, make the change and prpare the package | 14:32 |
| rrq | all that can happen at a distance from the installer-iso workspace | 14:33 |
| rrq | and then you'd add the new udebs into localudebs/ | 14:33 |
| rrq | for example, if you want your installer to default to something else than devuan's round-robin domain, you'd patch for that in the choose-mirror udeb. | 14:37 |
| buZz | its not that recommend to -not- use the round robin, fyi | 14:39 |
| error144_ | rrq this got complecated too quickly, do you have any external resource to know how to do that? | 14:46 |
| error144_ | I am having hard time searching all of what you are saying | 14:46 |
| error144_ | due to the lake of information about this topic | 14:47 |
| rrq | don;t know; it's the "normal" debconf setup of debian-installer | 14:47 |
| buZz | there's nothing unique to devuan's iso making vs debian's , afaik | 14:48 |
| error144_ | even infromation about debian-installer is rare | 14:48 |
| error144_ | I tried it before devuan-installer (or after) | 14:48 |
| error144_ | but I want to use devuan installer, because my ditro is built upon devuan, (just to be compatable, so to say) | 14:49 |
| error144_ | rqq "and put them in "localudebs" to override " but the localuddebs is almost empty? | 14:52 |
| rrq | yes it was a while ago for me, but I remember it as quite hard to work out bits and pieces. I have a meory of finding debconf info on the web, but I dont' rememeber where that was | 14:53 |
| error144_ | rrq if I successed at this I may make an article to explain how to use it. | 14:54 |
| error144_ | I just need to know where to get those udebs | 14:55 |
| rrq | afair the debian-installer iso building does not work out package dependencies and you'll have to enumerate the content maually; devuan's installer-iso includes some scripting to traverse the dependency tree so you only need to enumerate the "roots" packages | 14:55 |
| rrq | udebs are typically part of the main/debian-installer repo section(s), and I think debina has an installer team in their store (salsa) | 14:56 |
| rrq | devuan pacagaes are in devuan's git store | 14:56 |
| rrq | when you build, the builder generates a list of all udebs it has included. You may inspect those for their source information. | 14:57 |
| rrq | some "normal" sources also build udeb packages. | 14:58 |
| rrq | conceptually, the installer consists of an initramfs that includes a collection of pre-unpackaed udebs, and then additional udebs that get loaded from the on-iso pool. | 15:00 |
| rrq | the devuan installer udeb's are mentioned in the pool/installer-menu and pool/installer-extra list files | 15:03 |
| rrq | no, the latter is named pool/installer-undeclared | 15:04 |
| * rrq jumps into the pumpkin and goes away | 15:07 | |
| error144_ | rqq hope the pumpkin is sugary, thank you rrq for this information, I know I will have hard time understanding it, | 15:08 |
| error144_ | so I will slowly searching it one by one until I found out how to do it. | 15:08 |
| ocin | I'm trying to upgrade an ascii to beowulf but the dist-upgrade fails at eudev. 1. I get the message about missing ksyms and 2. it seems to depend on libeudev = something (not >=). https://dpaste.com/BQH3MMARK.txt | 17:20 |
| ocin | not sure what to do now and even less sure how to automate the fix in ansible later, thats gonna be fun. | 17:21 |
| user____ | ocin: I had no trouble doing that some months ago. | 17:21 |
| user____ | Seems things have moved on? Did you update ascii before starting this? | 17:22 |
| ocin | looks like ansible didn't do that even though it should have, but the system was last updated 6 days ago and installed like 3 months ago. | 17:34 |
| ocin | a dist-upgrade was not done on the ascii box since but regular update | 17:35 |
| ocin | I guess the kernel is too old then :/ | 17:41 |
| Stargoose2 | Hi. I deleted /etc/init.d/checkroot.sh during some experiments yesterday (system works fine because I pass "rw" to the kernel). How can I reinstall that file? Acording to dpkg -S, it belongs to the "initscripts" package, but doing "apt-get install --reinstall initscripts" doesn't install the file again. | 17:46 |
| ocin | hmm, I even use the ascii-backports kernel so I really wonder how it can be too old to not support something eudev needs | 17:49 |
| rwp | That /etc/init.d/checkroot.sh is in the initscripts package. | 17:50 |
| rwp | Stargoose2, Pass in the -o DPkg::Options::=--force-confmiss option. | 17:52 |
| rwp | I think it is a terrible default but it was successfully argued that removing a conffile is a local admin explicit action and should not be overwritten by dpkg. | 17:53 |
| rwp | The dpkg man page says "confmiss: Always install the missing conffile without prompting. This is dangerous, since it means not preserving a change (removing) made to the file." | 17:54 |
| rwp | On the opposition side, I think not reinstalling a conffile is dangerous. Because otherwise you have to know about this option in order to get it back! | 17:55 |
| rwp | Stargoose2, I strongly recommend installing "etckeeper" package. It will automatically commit everything into version control. I install it everywhere. | 17:55 |
| Stargoose2 | rwp: Ah, that Dpkg parameter saved the day! Thanks a lot! Taking notes... | 17:56 |
| rwp | In that same area I want to call out -o DPkg::Options::=--force-confnew too. This is useful if scripting everything and wanting to get the NEW version of conffiles without prompting. | 17:58 |
| rwp | If customization is needed then that needs to be done after the upgrade. But then it is customizing against the new version of the conffile and not a ten version old one. | 17:58 |
| rwp | Either way the other version of the conffile will be saved as foo.dpkg-old or foo.dpkg-new (or the odd foo.dpkg-dist that some postinst scripts do uniquely) | 17:59 |
| rwp | I always run "find /etc -name '*.dpkg-*' -ls" and "find /etc -name '*.ucf-*' -ls" to look for these left behind bits of lint after the daily upgrading and merge them and cleanup as needed. | 18:00 |
| rwp | Here is a for-example of when a new conffile was needed rather than preserving the previous. The sudoers file changed to require secure_path to be set. | 18:03 |
| rwp | The old file did not have it. The new one did. Those who got the new file were okay. | 18:03 |
| rwp | Those with the old file were swamping the communication channels asking why PATH wasn't set for them. | 18:03 |
| rwp | But CAUTION if you needed a customization there to get root and sudo taking the new file could lock you out! | 18:03 |
| rwp | So as with all things it is important to test carefully and understand. | 18:03 |
| Stargoose2 | rwp: thanks, very valuable tips indeed! | 18:12 |
| Stargoose2 | All this happened precissely because I was messing with the init system without knowing it well... | 18:12 |
| rwp | etckeeper FTW! :-) | 18:14 |
| rwp | And I say keep on hacking on. Because that is the only way to learn things. Happy Hacking! :-) | 18:14 |
| Stargoose2 | rwp: That is it exactly! I have several pages of notes of service management on Devuan already, and I started yesterday! :D | 18:30 |
| Stargoose2 | This is how I learned everything I know, by hacking, breaking, fixing and documenting! :) | 18:30 |
| Stargoose2 | But man does it make the time fly... hours pass like minutes! | 18:31 |
| fluffywolf | finally got my computer to stop turning itself off. the problem is elogind. | 20:19 |
| fluffywolf | upgrading to a package with default settings TO FUCKING TURN YOUR COMPUTER OFF RANDOMLY is not ok. | 20:20 |
| fluffywolf | power management crap absolutely should not get enabld on an upgrade. it probably shouldn't be enabled without explicit user configuration, ever. | 20:21 |
| gnarface | my hypothesis is that elogind must have pulled in the other stuff as dependencies for a graphical login that it in turn pulled it in | 20:24 |
| gnarface | and i still suspect that if you'd done the upgrade with --no-install-recommends none of it would have been included | 20:24 |
| fluffywolf | no. elogind does power management now. | 20:24 |
| gnarface | certainly it must at minimum require acpid for that? | 20:24 |
| fluffywolf | acpid is not intalled. I removed it trying to fix the problem. and upower, and xfce's power stuff, and everything else that seemed related to power or acpi. | 20:25 |
| gnarface | huh | 20:25 |
| gnarface | disturbing | 20:25 |
| gnarface | well you don't need elogind if you're not using a gui login prompt | 20:25 |
| gnarface | or i should say, you didn't... | 20:26 |
| gnarface | if that has changed in chimaera that's not good | 20:26 |
| fluffywolf | https://manpages.debian.org/testing/elogind/logind.conf.5.en.html see how much of its config is about power management | 20:26 |
| fluffywolf | trying to remove elogind causes excessive other things to be removed, including everything kde-related, like ktorrent. | 20:27 |
| gnarface | that was normal too, but in the past you'd be able to reinstall the non-login parts afterwards | 20:28 |
| fluffywolf | what does elogind do that is beneficial to my system? | 20:28 |
| fluffywolf | all of its configuration options look to be either harmful (like killing everything on logout) or already handled by other programs. | 20:29 |
| gnarface | it's a dropin replacement for systemd-logind, so it's primary benefit is adding support for all the software that otherwise required systemd-logind, which afaik was only the gui-login/user session management stuff | 20:29 |
| rwp | elogind is beneficial only in the sense that it allows Desktop Environments such as XFCE to be installed that would otherwise require systemd-logind. And that would be bad. | 20:30 |
| gnarface | rwp: but it used to be that XFCE could be run without elogind, if you just entered it with startx instead of a graphical login... did that change in chimaera? | 20:30 |
| rwp | Maybe I am conflating it with lightdm and slim? Probably. | 20:31 |
| gnarface | yea, i was under the impression that the window manager itself did not ever require this, only the session management stuff attached to it | 20:31 |
| fluffywolf | trying to remove it is not actually trying to remove anything to do with logins, amusingly. | 20:31 |
| rwp | It is definitely not needed for someone logging in at the Linux vt console, and running startx/xinit to launch a window manager. | 20:31 |
| fluffywolf | but it seems to break gvfs and everything that depends on it. | 20:31 |
| gnarface | but depending on how you installed you might get it all bundled together and have to uninstall it all then reinstall the parts you want ala-carte | 20:32 |
| fluffywolf | aptitude can't find any solution that removes elogind and keeps ktorrent. | 20:32 |
| fluffywolf | so there's a chain of hard dependencies there | 20:32 |
| gnarface | hmm, seems like maybe a mistake | 20:33 |
| rwp | Does pkginfo.devuan.org have a dotty graphical dependency page available? I thought it did. It might be useful to see what depends upon what. | 20:33 |
| fluffywolf | brb | 20:33 |
| gnarface | you should be able to get by without gvfsd too, though dbus might be harder to avoid | 20:33 |
| golinux | https://git.devuan.org/devuan/elogind | 20:34 |
| golinux | Learn something about what elogind does | 20:34 |
| rwp | Also: https://pkginfo.devuan.org/cgi-bin/debtree-query.html?c=package&q=ktorrent | 20:34 |
| rwp | What a web! | 20:34 |
| golinux | Yeah . . . that page confuses the heck out of me | 20:35 |
| rwp | It is telling me that I need a MUCH LARGER display than my current medium sized monitor. | 20:36 |
| fluffywolf | what elogind does is a bunch of things I don't want done. whether it also does useful things I do not know. | 20:40 |
| rwp | elogind does not do anything I find necessary for my use of the computer. | 20:50 |
| rwp | However having it installed and not using it does not cause me any problems either. | 20:51 |
| fluffywolf | "ktorrent" -> "kio" -> "libkf5authcore5" -> "libpolkit-qt5-1-1" -> "libpolkit-gobject-1-0" -> "libpolkit-gobject-consolekit-1-0" -> "libelogind0" looks like at least part of the chain... | 20:52 |
| rwp | I also want to defend acpi too. That sub-system is useful. I am unaware of any problems. It enables several things. | 20:53 |
| rwp | For one is power management for the power button. Which is how KVM and VM management works too. | 20:54 |
| fluffywolf | yes, the subsystem is useful. having a login manager (?) decide that it should randomly suspend your computer, as the default configuration, is very much not useful. | 20:54 |
| rwp | For another is laptop keys. I use it to make my laptop keys work. https://www.proulx.com/~bob/doc/thinkpad-x220-laptop-keys/thinkpad-x220-laptop-keys.html | 20:54 |
| fluffywolf | the default should be all power management is off unless the user turns it on. and it's questionable whether the login manager should even be doing power management. | 20:54 |
| fluffywolf | also, importantly, the power management configuration should not change during an upgrade. | 20:56 |
| Garb0 | Anymore knows anything about the nvidia issue? | 21:00 |
| Garb0 | anyone* | 21:00 |
| gnarface | Garb0: you're gonna have to be more specific | 21:01 |
| Garb0 | Oh, i thought everyone else was getting the same issue as a friend and i got the same issue, basically: | 21:02 |
| Garb0 | `NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver.` | 21:02 |
| Garb0 | Which leads to persistenced not being able to start | 21:02 |
| Garb0 | which leads to dpkg not fully configuring the nvidia driver | 21:02 |
| gnarface | there's so many nvidia issues all the time we can't even tell if you mean a technical one or a legal one | 21:02 |
| Garb0 | Oh lol | 21:03 |
| gnarface | in that particular instance, leading cause is driver version mismatch, but never fear; just uninstall nvidia-persistanced and nvidia-smi - you don't actually need either | 21:03 |
| gnarface | (if it tries to re-install them immediately, just make sure they're matching the main version of most the rest of the nvidia packages) | 21:03 |
| Garb0 | gnarface: Oh, thanks, | 21:04 |
| Garb0 | didn't know the nvidia-driver metapackage could cause so much havoc | 21:04 |
| * fluffywolf has a Advanced Micro Devices, Inc. [AMD/ATI] Chelsea LP [Radeon HD 7730M], would be happy never using an nvidia product ever again | 21:04 | |
| Garb0 | gnarface: I'm on arch btw | 21:05 |
| gnarface | Ronvidia-persistenced is supposed to add some shader caching stuff that is mostly harmful on linux and the nvidia-smi thing is a maintenance/diagnostic tool you only really need for multi-gpu rendering clusters | 21:05 |
| gnarface | ^ this was supposed to be Garb0: nvidia-persisten.... | 21:05 |
| Garb0 | Thank you very much for you help man, i was gonna spend a night fixing this issue, gnarface | 21:05 |
| gnarface | you're welcome, but don't thank me until after you've verified it works, lol | 21:06 |
| gnarface | lol yea the AMD drivers are in one package, it definitely lowers the maintenance load during upgrades | 21:09 |
| gnarface | so does the fact you can manipulate them with native tools instead of needing some contrived gui atrocity for everything | 21:09 |
| gnarface | and i used to be a staunch nvidia sympathizer, they really crapped the bed here | 21:10 |
| gnarface | but i suppose that's drifting off-topic | 21:10 |
| Garb0 | gnarface: Hell na brother, hashcat no worky, which means imma just purge the entirety of the nvidia driver then reinstall it | 21:11 |
| Garb0 | Or maybe i didn't reboot? | 21:12 |
| gnarface | hmm | 21:13 |
| gnarface | if Garb0 makes it back tell them they definitely need to reboot after upgrading this, but removing ALL the nvidia packages then starting over has worked in the past for me | 21:14 |
| gnarface | but you do really have to make sure you get all of them | 21:14 |
| gnarface | and in matching versions | 21:14 |
| gnarface | well, not literally ALL of them but you can't count on the ones you need being automatically included either | 21:14 |
| gnarface | libgl1-nvidia-glx often gets missed | 21:15 |
| gnarface | (for example) | 21:15 |
| Garb0 | Yeah, works now. | 21:21 |
| Garb0 | Thanks, gnarface | 21:21 |
| Joy-Unit | gnarface is very helpful | 21:22 |
| gnarface | happy to be of service | 21:25 |
| fluffywolf | bbl, back to work | 21:25 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!