adhoc | morning all | 03:09 |
---|---|---|
adhoc | is it possible to work out from; apt-cache show $PACKAGE | 03:10 |
adhoc | what the license is for the $PACKAGE? | 03:10 |
rwp | No. But from apt-cache policy $package one can tell which repository it is in and all things in main are DFSG free, and non-free in the non-free. | 03:18 |
rwp | If this were Debian I would look at the packages page and look at the Copyright file link from there. For example: https://packages.debian.org/sid/rsync | 03:21 |
rwp | Of course once a package is installed then the /usr/share/doc/$package/copyright file is authoritative. | 03:22 |
theca | what init do you guys like and why? | 05:02 |
gnarface | if theca comes back, tell them to wait longer next time, and to ask in #devuan-offtopic instead | 05:04 |
rrq | yeah; such existential considerations of fundamental significance are wasted in the support channel | 05:17 |
adhoc | anyone tinkered with arm64/aarch64 SBCs? | 05:18 |
adhoc | have a few pine rock64 systems in the mail... | 05:18 |
gnarface | adhoc: yea check out #devuan-arm, it's a slower channel but there are some of us here messing with them | 05:51 |
adhoc | gnarface: awesome, thanks | 06:11 |
gour | hello is there a plan for devuan to replace sysvinit with something else and is there some strong candidate for it? | 12:14 |
pandakekok9 | gour: Not that I know, but if sysv will be replaced, openrc is will most likely be the replacement | 12:16 |
gour | pandakekok9: thanks...but, doesn't openrc depend partially on syvinit? | 12:20 |
pandakekok9 | openrc has its own init, but you can use sysv as well | 12:20 |
gour | if i'd want to install openrc and repalce runit, apt wants to install sysvinit-core? | 12:22 |
pandakekok9 | Hmm, I guess Devuan doesn't support openrc's init yet... | 12:26 |
pandakekok9 | init package pre-depends on sysvinit-core or runit-init | 12:27 |
pandakekok9 | You can remove sysvinit-core and init though. Then follow Gentoo's instructions at https://wiki.gentoo.org/wiki/OpenRC/openrc-init | 12:28 |
pandakekok9 | Ignore the scary warning by apt | 12:29 |
pandakekok9 | Some packages might depend on the init package though, and break them | 12:29 |
buZz | openrc should be supported, according to https://www.devuan.org/os/init-freedom | 12:30 |
buZz | and even in installer > Devuan 3.1 now supports the options of Runit, SysVinit, and OpenRC that can be selected from during the Devuan installation process | 12:31 |
Walex2 | IIRC originally OpenRC was a set of scripts, a bit like the old single/multi user scripts of UNIX | 12:32 |
gour | yeah, i did select runit when installing & running chimaera, but not many scripts are available for it | 12:32 |
Walex2 | gour: "technically" the '/etc/init.d/' scripts could be used with any process supervisor. | 12:33 |
Walex2 | they do single process "supervision" ('start'/'reload'/'stop') that is somewhat different from multiple process supervision. | 12:34 |
Walex2 | also IIRC the 'runit' 'runsvdir' process supervisor is compatible with 'daemontools', so presumably 'daemontool' scripts could be used with it too. | 12:36 |
rgh[m] | You probably wouldn't to use sysinit scripts though. The "daemontools" tools are so much more elegant and simpler. | 13:24 |
rgh[m] | gour Look on the s6 or nosh sites for links to other sites with collections of "daemontools" scripts. | 13:27 |
Walex2 | "nosh" is something I particularly admire BTW. | 17:08 |
Junicchi | is there an easier way to install gcc-10 to devuan? | 18:53 |
hagbard_ | It's the default version in devuan testing. | 18:54 |
Junicchi | hagbard_: what if i'm from beowulf? | 18:54 |
Junicchi | i guess i can use testing's repository's then | 18:55 |
hagbard_ | Would be worth a try. | 18:57 |
Junicchi | dunno how to doit so will build all of the package i guess | 19:00 |
rwp | If running Beowulf Stable and wanting something newer then beowulf-backports are always the better place to start looking. | 19:17 |
rwp | But gcc-10 is not available in backports. That would mean it would require an upgrade to Chimaera Testing or Ceres Unstable. | 19:18 |
rm | you can mix stable and testing packages | 19:18 |
rm | use only a few things from testing | 19:18 |
rm | that's about the least problematic case of repo mixing | 19:19 |
rwp | I do not recommend mixing things up like that because it creates a Frankenstein system. | 19:19 |
rwp | But it's always up to the local system owner! It's their system. | 19:19 |
hagbard_ | I recommend to entirely upgrade to chimaera. There are no stability issues i ran into, and it would allow a clean system without mixed repositories. | 19:20 |
rwp | A full upgrade to Chimaera would be my vote for someone who wants the newest versions of things. | 19:20 |
Junicchi | building gcc10 taking hours i'm updating to chimera | 19:45 |
rwp | Junicchi, Just curious here but why do you want gcc10? (I am finding gcc10 rather more annoying than previous versions. Hoping they improve in the next release.) | 20:27 |
Junicchi | rwp: it was just a dependency of a software i wanted to install | 21:04 |
Junicchi | but i just wanted to update my distro to chiamera in general | 21:04 |
Junicchi | tbh it hung | 21:04 |
Junicchi | it just stuck on %67, task mount:8055 blocked more than 120 seconds | 21:05 |
Junicchi | >Tainted: P OE 4.19.0-16-amd64 | 21:06 |
Junicchi | dpkg is stuck on "mounting cgroupfs hierarchy" everytime | 21:18 |
rwp | Junicchi, What is the command you are using to upgrade? | 21:19 |
Junicchi | after updating my sources list i did: apt dist-upgrade | 21:19 |
Junicchi | since it stuck i cancelled it | 21:20 |
Junicchi | and had to perform dpkg --configure -a | 21:20 |
rwp | Hmm... I always recommend doing an "upgrade" first as that is simpler, then "upgrade --with-new-pkgs", and then "dist-upgrade". | 21:20 |
Junicchi | and now it's stuck on mounting cgroups | 21:20 |
Junicchi | sounds interestinf | 21:20 |
rwp | I am not knowledgeable about cgroups so am unable to help. :-( | 21:21 |
Junicchi | but now that dpkg fails to reconfigure i cant fix it either | 21:21 |
iv4nshm4k0v | I'm surprised that dpkg is concerned with Cgroups. Or is it some maintscript, or an init.d script via invoke-rc.d? Perhaps move /etc/init.d/cgroupfs-mount out of the way and try again? | 21:25 |
rwp | It would almost certainly be a package postinst script that is in the middle of this. | 21:25 |
rwp | I would be inclined to run "dpkg -l | grep -v -e ^rc -e ^ii" and look to see what packages are in other states as a clue to which package it might be. | 21:27 |
iv4nshm4k0v | rwp: On my system, only cgroupfs-mount.postinst seem to have anything to do with cgroups; and it only does invoke-rc.d for the init.d script I've mentioned above. (And it fails, for my policy-rc.d script denies anything.) | 21:27 |
rwp | I would not expect Junicchi to have a /usr/sbin/policy-rc.d script on a normal system outside of a chroot though. | 21:28 |
rwp | Junicchi, Can you determine which package is giving problems? | 21:30 |
iv4nshm4k0v | rwp: I'd say it's never late to adopt such a script. Also, invoke-rc.d translates policy-rc.d's 101 into 0 ('success'.) | 21:30 |
rwp | iv4nshm4k0v, Use of policy-rc.d is specific. I would not recommend it for everyone to use to disable everything! | 21:31 |
iv4nshm4k0v | rwp: IME, invoke-rc.d is used chiefly to (re)start services after installation or upgrade by the postinst script. /My/ preference is to a. start new services manually, after I've at least taken a look at their default configuration; and b. to restart them manually as well, so as to not interfere with active use and such. | 21:35 |
iv4nshm4k0v | There's a bit of micromanagement in that, but it so far have paid off. | 21:35 |
rwp | That's actually one of the surprising/usually-unexpected things about policy-rc.d is that it only affects invoke-rc.d and not boot time init. | 21:36 |
rwp | Therefore a boot will start everything normally. But an "apt-get upgrade" will not. And therefore old daemons are left running when they would normally have been restarted. | 21:37 |
rwp | It was designed to be used in chroot's to prevent starting daemons in a chroot when packages were installed/upgraded there. | 21:37 |
rwp | And of course in chroot's there is no "boot" that happens there so that part of things was not considered. | 21:38 |
rwp | And can't forget things like logrotate which also uses invoke-rc.d to signal running processes too. That is also disabled by use of policy-rc.d too. | 21:38 |
rwp | However as always it is your system and it is certainly okay for you to customize it as you desire. ykinmkbykiok :-) | 21:40 |
iv4nshm4k0v | FWIW, I check for the old daemons with: # (set -C -e -x -u -- "$(gawk 'BEGINFILE { if (ERRNO != "") { nextfile; } } /deleted/ && $6 !~/^\/(dev\/zero$|SYSV)/ { print FILENAME; nextfile; }' /proc/*/maps | tr \\n , | tr -dc 0-9, | sed -e "s/,\$//")" ; test -n "$1" && TZ=UTC ps -o pid,ppid,pidns,tty,stat,vsize,size,lstart,comm,cmd -p "$1") 2>&1 | less -UF . | 21:43 |
iv4nshm4k0v | Also, I'm not using logrotate, though I'm somewhat surprised that it should do anything outside the cron context. | 21:43 |
rwp | I am liking "needrestart -b" for checking for daemons that need a restart. (apt-get install needrestart) | 21:44 |
rwp | Note that the package inserts a hook into /etc/apt/apt.conf.d/99needrestart that I do not like and disable. | 21:44 |
iv4nshm4k0v | In this specific case, I still think it makes sense to disable cgroupfs-mount via either a trivial policy-rc.d, or # chmod a-x , and try # dpkg --configure -- cgroupfs-mount ; and then enable it back and # dpkg --configure --pending . | 21:45 |
rwp | I am still not clear on why Junicchi's system is having a problem at that step. That's not normal. I would like to see the root cause of the problem found. | 21:46 |
iv4nshm4k0v | rwp: # sh -x /etc/init.d/cgroupfs-mount start ? | 21:50 |
mason | iv4nshm4k0v: safer to run it through env -i | 21:56 |
rwp | I wish "service" had a verbose option for applying -x to the init.d scripts. | 21:57 |
iv4nshm4k0v | mason: Indeed. | 21:57 |
Junicchi | i just removed postinst scripts everytime i received error nof successfully completed | 22:02 |
Junicchi | my release is now: | 22:59 |
Junicchi | No LSB modules are available. | 22:59 |
Junicchi | Distributor ID: Devuan | 22:59 |
Junicchi | Description: Devuan GNU/Linux 4 (chimaera/ceres) | 22:59 |
Junicchi | Release: testing/unstable | 22:59 |
Junicchi | Codename: n/a | 22:59 |
Junicchi | and i have chimaera,chimaera-updates,chimaera-proposed-updates repositories with main,contrib,non-free | 23:00 |
Junicchi | but can't install nvidia-detect | 23:00 |
Junicchi | and when i try to install nvidia-kernel-* packages apt says they're not installable | 23:00 |
Junicchi | why i lost them? | 23:00 |
Junicchi | any ideas rwp | 23:01 |
Junicchi | tho i couln't activate chimaera-security and chimaera-backports since they don't exist | 23:04 |
fsmithred | there is no chimaera-updates or any others than just "chimaera" | 23:04 |
fsmithred | and if you find a chimaera-security, it's not real. It's just for testing out the new installers. | 23:05 |
Junicchi | humm | 23:06 |
Junicchi | then how should i install nvidia-drivers? | 23:06 |
fsmithred | did you try to install with the glob as you posted above? | 23:07 |
fsmithred | I just tried 'aptitude -s install nvidia-kernel-dkms' in chimaera and it looks like it would install. | 23:07 |
Junicchi | >No candidate version found for nvidia-detect | 23:08 |
fsmithred | maybe something is wrong with sources.list or you need to update the package cache | 23:10 |
fsmithred | I see 460.73.01-1 in chimaera/ceres | 23:10 |
Junicchi | oh, interesting | 23:13 |
Junicchi | N: Can't select candidate version from package nvidia-detect as it has no candidate | 23:13 |
Junicchi | N: There is 1 additional record. Please use the '-a' switch to see it | 23:13 |
Junicchi | when i use `apt show nvidia-detect -a` it shows the correct package | 23:13 |
Junicchi | but why | 23:13 |
Junicchi | i decided to clear apt cache with apt clean and can't update it now | 23:16 |
fsmithred | ? | 23:16 |
Junicchi | .../binary-i386/Packages.xz File has unexpected size (8266524 != 8267908). Mirror sync in progress? | 23:16 |
fsmithred | oh, try again in a couple minutes | 23:16 |
fsmithred | nvidia-detect installs and runs correctly in beowulf and chimaera here. | 23:19 |
fsmithred | I assume it's correct in chimaera: "No NVIDIA GPU detected." is correct. | 23:19 |
Junicchi | i've been successfully using it on beowulf | 23:22 |
Junicchi | after having some errors after my update to chimarea just purged nvidia drivers to reinstalling them | 23:23 |
Junicchi | but pretty weird that can't install it now | 23:24 |
Junicchi | now i only have this in my sourceslist: deb http://deb.devuan.org/merged chimaera main non-free contrib | 23:25 |
Junicchi | and it still has no installation candidate | 23:25 |
Junicchi | weird | 23:25 |
fsmithred | that is weird | 23:25 |
fsmithred | nothing pinned in /etc/apt/preferences.d? | 23:26 |
Junicchi | ahh | 23:27 |
Junicchi | i had a pin on preferences | 23:28 |
fsmithred | working now? | 23:28 |
Junicchi | xd removing the pin worked | 23:28 |
Junicchi | i dunno why i created that, i don't even know what it is | 23:29 |
Junicchi | sorry for wasting your time btw, thanks for your help | 23:29 |
fsmithred | np | 23:31 |
Junicchi | ok now having another error | 23:34 |
Junicchi | http://0x0.st/-aF4.png | 23:34 |
Junicchi | dunno what cgroups is but it seems to be the one that triggered the problem | 23:35 |
fsmithred | weren't you talking to someone else about this error earlier? Or was that someone else? | 23:36 |
Junicchi | yes, i was getting the same error while performing dist-upgrade | 23:38 |
Junicchi | i'll try to remove postinst script | 23:40 |
Junicchi | ^tho doing this is simply supressing the error | 23:44 |
fsmithred | do you even need that package? | 23:44 |
fsmithred | doesn't sound like it's essential | 23:44 |
Junicchi | nvidia-driver? | 23:44 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!