decuser | About to launch into a devuan install - first time devuan, long time freebsd, former Debian user (until systemd). A little confused about inits :) | 02:10 |
---|---|---|
decuser | Which to choose? I'm leaning towards OpenRC - runit sounded good 'til I dled the code and saw it wasn't the <300 lines of code advertised... what's y'all's take on it? | 02:11 |
gnarface | decuser: if you're confused you should try the default first | 02:18 |
decuser | fair enough. I should have said, I'm ambivalent. I figured it would ask me during install, so I was doing homework. If there's a default, I'll definitely go with that! | 02:19 |
DHE | isn't openrc the gentoo init system? | 02:21 |
gnarface | yes, but the openrc install that is inherited from debian still relies on the default (sysvinit) for actually starting and stopping processes, only using openrc for process monitoring and management | 02:21 |
gnarface | if you want to actually use it how gentoo uses it, you have to modify the base install or replace the openrc package with a custom build | 02:22 |
gnarface | nonetheless, it is popular in both forms, just not as popular as the default | 02:22 |
gnarface | runit is much less popular | 02:22 |
gnarface | people go with openrc or s6 i think generally, unless they just use bare sysvinit, which is very capable, despite all rumors to the contrary | 02:23 |
gnarface | once i saw a demonstration of using emacs as an init | 02:24 |
gnarface | you can really overcomplicate things, and i recommend just learning sysvinit first before you decide you want to throw it overboard | 02:24 |
Jjp137 | yeah the installer at the relevant step pretty much says something like "if you don't know what this is all about, just pick 'sysvinit'" | 02:28 |
gnarface | the very opinion that it is heavy is itself obsolete by modern standards, and what systemd people are trying to replace it with falls far short of the stated goal of doing better | 02:31 |
gnarface | there's a lot of misinformation about it though, and a lot of artificially amplified opinions | 02:31 |
gnarface | i recommend anyone just really try it themselves | 02:31 |
gnarface | it isn't perfect but it largely doesn't actually suffer from any of the problems people say it has | 02:32 |
fsmithred | try what? | 02:32 |
gnarface | fsmithred: the default init | 02:32 |
fsmithred | sysvinit? | 02:32 |
gnarface | yea | 02:32 |
fsmithred | that thing that's been there for the 20 years I've been using linux and I didn't notice it? | 02:33 |
fsmithred | ok, I just read the log to catch up. | 02:36 |
sgage | Yep, that's the one ;-) | 02:36 |
fsmithred | it's easy to change to one of the other init systems after the install, if you wanted to try one | 02:36 |
gnarface | yea, that too. there's nothing about the openrc install that requires it to actually be part of the installer other than the opinions of people who want to promote openrc | 02:37 |
fsmithred | I think it's there for street cred, too. | 02:38 |
gnarface | i guess a rising tide raises all ships | 02:38 |
fsmithred | init diversity and all. | 02:38 |
gnarface | or something like that | 02:38 |
fsmithred | the runit dev showed up in forum recently with a link to a bunch of run scripts | 02:38 |
fsmithred | and a few people are starting to use them | 02:39 |
decuser | gnarface, So Sysvinit is the default. Cool. I remember using it back in the day. I don't miss runlevels, but I guess that's the price one pays to play in the linux world. I'm still dling the thing - internet is slow for us in Texas, I guess. I'm used to BSD init now - super simple by comparison. /etc/rc.conf and /etc/rc.d, and that's pretty much it. | 03:15 |
mason | I don't miss runlevels because... there they are. :) | 04:10 |
sgage | I can haz runlevels? | 04:19 |
mason | You can. | 04:26 |
systemdlete | Does anyone else get these error messages just before (once) and after (twice) the crypt fs queries for the password at boot? The message: "failed to execute '/lib/udev/${exec_prefix}/bin/udevadm' '${exec_prefix}/bin/udevadm trigger -s block -p ID_BTRFS_READY=0': No such file or directory" | 08:35 |
systemdlete | It seems to be quite harmless, but I don't get many hits when I google for it. | 08:35 |
systemdlete | The one hit at gentoo says this is somehow related to btrfs and systemd I think. | 08:36 |
systemdlete | no such path even exists on my system here. | 08:37 |
rrq | probably you should edit /lib/udev/rules.d/64-btrfs.rules and remove the "${exec_prefix}" bit in the RUN component | 09:13 |
rrq | or any other file in /lib/udev/rules.d/ that has it | 09:14 |
rrq | it's a friendly reminder from the eudev packager that life is not perfect | 09:17 |
kreyren1 | What is the state of xen in devuan? | 10:27 |
enyc | kreyren1: I would strongly expect, no different to debian | 10:40 |
* enyc meows | 10:42 | |
kreyren1 | i guess good enough then O.o | 10:42 |
* kreyren1 pats enyc | 10:43 | |
enyc | kreyren1: I used older xen elts support whatnot, long story. | 10:44 |
enyc | kreyren1: not so familiar with 'current' debian xen | 10:46 |
enyc | but no suggestion it is systemd-dependent in any way | 10:46 |
kreyren1 | gut gut | 10:46 |
enyc | intiial look at debian xen 4.14 packages confirms that | 10:47 |
enyc | via packages.debian.org dependencies | 10:47 |
DocScrutinizer05 | if it's not too offtopic: postfix virtual /etc/postfix/virtual what does a line like "some@body.com thisdoesnotexist" result in? will it reject mails to some@body.com? | 11:22 |
xinomilo | probably reject - unknown recipient.. | 11:25 |
DocScrutinizer05 | thanks! :-) | 11:25 |
xinomilo | depends on setup, so please try it first, don't take -just- my word on it.. :) | 11:26 |
systemdlete | <rrq> it's a friendly reminder from the eudev packager that life is not perfect | 12:05 |
systemdlete | thanks, but I'm pretty sure I don't need such reminders unless they help tackle a problem that needs solving. | 12:05 |
systemdlete | :P | 12:05 |
systemdlete | (thanks for your response, btw, rrq) | 12:05 |
ribcage | hey, could i migrate debian 10.1 to devuan without internet, just by using "devuan_beowulf_3.0.0_i386-desktop.iso" ? | 17:04 |
fsmithred | ribcage, probably not with 3.0.0 since the packages are from about six months ago. | 17:13 |
fsmithred | if you've done any update/upgrade, you already have newer packages. | 17:14 |
fsmithred | You might be able to do it with 3.1.0. I've never heard of anyone trying it. | 17:14 |
ribcage | i did not do an update since the end of 2019 when i installed it | 17:14 |
fsmithred | make sure you have backups of anything important | 17:14 |
fsmithred | oh | 17:14 |
fsmithred | well, maybe | 17:14 |
fsmithred | what desktp do you have? | 17:14 |
fsmithred | and check the migration guide at devuan.org | 17:15 |
ribcage | i originally installed it with lxqt, cant remember... but i disabled the desktop long ago and only run it headless | 17:15 |
fsmithred | oh, that'll make it easier | 17:16 |
fsmithred | use --simulate first | 17:16 |
mason | Pruning packages in advance, disabled or otherwise, will also help. | 17:16 |
fsmithred | I gotta run. Let us know how it goes. | 17:16 |
ribcage | sure, when i try it | 17:16 |
ribcage | i don't know what pruning is... | 17:19 |
ribcage | you mean removing packages that i don't use? | 17:19 |
ribcage | mason: is that what you mean? | 17:23 |
plub | hello. i install vice emulator, but there is no vice executeable | 17:27 |
plub | i could websearch where the executeable is, or i could download the .deb and dpkg X it to see what files are in it | 17:27 |
plub | but can apt give me some info about what executeables a package installs? | 17:28 |
djph | typically /usr/{,local/}bin/executable | 17:28 |
plub | that would be in my path | 17:28 |
djph | yes | 17:28 |
plub | but there is no 'vice*' in my path | 17:29 |
djph | unless it's a system thing, and it ends up in sbin | 17:29 |
djph | which would require root | 17:29 |
plub | i'll extract the .deb | 17:30 |
plub | mhm the binary is /usr/bin/x64 | 17:32 |
n4dir | apt-file show <pkg>; whereis <pkg> can help | 17:33 |
plub | well it's not <pkg> it's <file> where file is some file or directory | 17:33 |
plub | maybe i'll tweak dpkg's installer to verbosely spit out the names and paths of any extracted executeables by default | 17:34 |
n4dir | not sure where that "it's file" is comming from. | 17:34 |
plub | apt-file doesnt take packagenames as arguments | 17:35 |
n4dir | might write a bug report for the manpage then | 17:35 |
n4dir | it will give the bin paths right away, if you know it, no clue why you had to ask | 17:36 |
mason | ribcage: Yes, any packages you remove won't have to be upgraded. Just be careful to only remove packages you really don't need. | 17:38 |
mason | ribcage: At some points in the past I've removed packages I wanted during major upgrades, just to get them out of the way, knowing I'd reinstall them after. | 17:38 |
mason | plub: dpkg -L vice-emulator or whatever the package is. | 17:39 |
plub | thank you mason | 17:39 |
mason | If you don't know what package it is, dpkg -S /path/to/file for some file in it | 17:39 |
ribcage | mason: i would prefer to not change any packages that are not dependant on systemd | 18:28 |
mason | ribcage: That's fine. I'm just saying it can increase your chance of success and an easy upgrade. | 18:29 |
rwp | On beowulf the /etc/pam.d/lightdm-greeter contains "session optional pam_systemd.so" and of course it logs errors to the syslog. | 19:10 |
rwp | If the line were prepended with a "-" then that would disable the error logging for that entry. See map.conf(5). | 19:11 |
rwp | And then the second of course is that on Devuan it probably should just be commented out. | 19:12 |
rwp | It's just an error message to the syslog now though and does not break anything. | 19:12 |
fsmithred | rwp, I think you need to update lightdm | 19:21 |
rwp | From a backport? Why? | 19:21 |
fsmithred | new version just moved in from beowulf-proposed-updates that fixes the problem | 19:21 |
fsmithred | or edit yourself | 19:21 |
fsmithred | session options pam_elogind.so | 19:21 |
rwp | Of course I am editing it myself already. | 19:21 |
fsmithred | that was one of the fixes in the 3.1 point-release | 19:22 |
rwp | If it is in beowulf-proposed-updates then it is proposed for Beowulf Stable and I am patient. | 19:22 |
fsmithred | it moved into beowulf main a few days ago | 19:22 |
rwp | The system is up to date daily. | 19:22 |
fsmithred | 1.26.0-4+devuan2 | 19:23 |
rwp | That version is what is installed and is what contains the missing file. | 19:23 |
rwp | Hmm... | 19:23 |
rwp | Could it be an upgrade did not bring in the new file because it is a "conffile"? That's probably the problem. | 19:23 |
rwp | I will reinstall it with --force-confnew and see if that brings in a new file. | 19:24 |
fsmithred | I've got the older version and it has elogind. I probably changed that. | 19:24 |
rwp | I just did "apt-get -o DPkg::Options::=--force-confnew install --reinstall lightdm" and I see both pam_systemd.so and pam_elogind.so in the file. | 19:25 |
rwp | I will pick apart the deb and see what is in it. | 19:25 |
rwp | It's in the deb. So the 1.26.0-4+devuan2 contains it. Did not get patched. | 19:26 |
fsmithred | oh, the date on my file is May 8 | 19:34 |
fsmithred | and I just upgraded two minutes ago | 19:35 |
rwp | It's a conffile so there will be a dpkg diff happening and you may have a .dpkg-old or .dpkg-new there. | 19:35 |
fsmithred | no, I have three files that match /etc/pam.d/lightdm* | 19:37 |
fsmithred | and they've all got may 8 date | 19:37 |
fsmithred | so maybe they didn't change and the files in the new deb package have the same date? | 19:37 |
rwp | Hmm... Not sure exactly what is happening. So can't say. | 19:38 |
fsmithred | Jan 9 | 19:38 |
rwp | For your amusement, I automate everything and this is my snippet I just assembled to twiddle this. https://paste.debian.net/plain/1185860 | 19:38 |
rwp | I run a daily upgrade with --force-confnew active. So my conffiles always get updated to the packaged versions. And then my configuration scripts configure them as to my desired settings. | 19:39 |
rwp | And then I have a second part which removes the left behind .dpkg-old files. | 19:40 |
fsmithred | are you still getting error messages with elogind in the file? | 19:40 |
rwp | Yes. Because the error comes from the pam_systemd.so line on the line before it. | 19:40 |
rwp | Here is the pristine in-deb-package version of that file. https://paste.debian.net/plain/1185862 | 19:41 |
fsmithred | and starting the line with minus sign fixes it? | 19:41 |
rwp | Lines starting with a - supress any error message from not being able to load it. | 19:42 |
rwp | But as you can see since I know I don't need it I simply edit the line out of my file. :-) | 19:42 |
fsmithred | yeah, I'm just thinking about what we should do, since we already fork that package | 19:43 |
rwp | The pam.conf man page says: "If the type value from the list above is prepended with a - character the PAM library will not log to the system log if it is not possible to load the module because it is missing in the system. This can be useful especially for modules which are not always installed on the system and are not required for correct authentication and authorization of the login session." | 19:43 |
fsmithred | thanks | 19:44 |
rwp | Here is the error message that gets logged that started me looking at things today. https://paste.debian.net/plain/1185864 | 19:45 |
rwp | Everything works as it is now but since I noticed this logged error this morning and the package was already forked I figured I would say something since it could suppress that error. | 19:46 |
fsmithred | that's in syslog? | 19:46 |
rwp | Yes. In the /var/log/syslog file. | 19:46 |
fsmithred | oh, I know what the problem is. | 19:47 |
fsmithred | I have lightdm installed, but I'm not using it on this box. | 19:47 |
rwp | Ah, yes, that would do it. | 19:47 |
rwp | I use logcheck everywhere, and agressively suppress noise from it. Which is required if one uses logcheck because otherwise *EVERYTHING* produces noise. | 19:48 |
rwp | But it means I notice pretty much every possible syslog message that is not otherwise suppressed by me in some way. | 19:48 |
plub | this is a good place to learn things | 19:48 |
fsmithred | yikes, grepping for systemd on the laptop with chimaera is overwhelming | 19:48 |
rwp | Hello plub! Glad it is at least entertaining. :-) | 19:49 |
rwp | fsmithred, Really? When I grep the only thing I am seeing right now is a noisy CRON suppression line. | 19:49 |
fsmithred | anacron is going nuts over /run/systemd/system | 19:50 |
fsmithred | network manager has a bunch of errors, but oops, that's because resolv.conf is immutable | 19:50 |
fsmithred | not by accident | 19:50 |
rwp | This is all I see here: https://paste.debian.net/plain/1185865 | 19:50 |
fsmithred | yeah, I see that | 19:51 |
rwp | And that suppression line is from "anacron"'s /etc/cron.d/anacron entry. | 19:51 |
rwp | Which is just telling me that since I don't need anacron on that box I should purge it. That would remove that bit of noise from things. | 19:51 |
rwp | That's a good cleanup for me on this end. I hadn't noticed that bit of lint yet. | 19:52 |
rwp | Since anacron is great on mobile laptops that suspend and wake up but it has no real purpose on an always on 24x7 machine. | 19:52 |
fsmithred | I'm not seeing the pam error in chimaera | 19:52 |
rwp | Let me dig the chimera deb for lightdm out and see if it is modified in the later version. | 19:53 |
fsmithred | file looks the same, I think | 19:53 |
fsmithred | last three lines for sure | 19:53 |
rwp | Yes. File looks the same. I looked at the ceres lightdm_1.26.0-7+devuan3_amd64.deb file. | 19:54 |
rwp | Re: immutable /etc/resolv.conf file. Ha! I bet at any given time at least 2% of all of those files have been marked immutable as a relief from smashing the head against the desk. | 19:56 |
rwp | Especially if Network Mangler is in use on the machine. It has screwed me over too many times. | 19:57 |
rwp | Say... (I hate to mention Amazon but...) Is there an Amazon AMI for Devuan available? It doesn't look like one has been submitted to the Community AMIs. :-( | 20:02 |
fsmithred | fighting with n-m is what originally brought me to the debian forum | 20:03 |
rwp | Wait... Does that mean that NM actually did something good then? My mind just exploded! | 20:04 |
* rwp steps away IRL for something... | 20:04 | |
fsmithred | no, I did something good. I went to a good forum. (used to be very good) | 20:05 |
rwp | fsmithred, Yes. But I was joking that NM being so terrible was the motivation for you joining the forum and you joining the forum was a good thing so by chaining... | 20:41 |
DeepDive | HI there I was wndering if anyone can help ... during an upgrade Ive got this eudev error: | 20:48 |
DeepDive | Setting up eudev (3.2.9-8~beowulf1) ... | 20:48 |
DeepDive | The group `kvm' already exists and is not a system group. Exiting. | 20:48 |
DeepDive | dpkg: error processing package eudev (--configure): | 20:48 |
DeepDive | installed eudev package post-installation script subprocess returned error exit | 20:48 |
gnarface | DeepDive: diagnosis: error self-explanatory. prescription: manually correct then retry. | 20:54 |
DeepDive | shall i delete kvm? | 20:55 |
gnarface | DeepDive: yes. actually i suspect that if you either remove the group or make it into a system group it will work | 20:55 |
gnarface | DeepDive: (the fact that this is happening though suggests you mixed unsupported repos sometime in the past) | 20:56 |
DeepDive | I thought about it but since the group has a member (me) I was reluctant to do that | 20:56 |
gnarface | your user is also allowed to be a member of system groups | 20:56 |
gnarface | chances are you could put yourself back in the new group just as easily | 20:56 |
DeepDive | pardon my ignorance but what is a "system group"? | 20:58 |
gnarface | a group that has no users of the same name and a gid lower than 500 | 20:59 |
gnarface | if you copied uids and gids from a redhat system it could explain this, they use different ranges by default last i checked | 21:00 |
DeepDive | ah ha! thanks. this one has gid 1001 | 21:00 |
gnarface | in debian, regular users start at 1000 | 21:00 |
DeepDive | all clear now | 21:00 |
DeepDive | do you recommend changing the guid or deleting? | 21:02 |
gnarface | well, i don't think it'll matter if this is all that's wrong | 21:02 |
DeepDive | i'll give it a go | 21:02 |
gnarface | the problem is that the fact this is wrong in the first place hints at the possibility of many other things wrong | 21:02 |
gnarface | this group shouldn't have been created wrong by a supported package | 21:02 |
gnarface | if you created it yourself then maybe that is the best scenario | 21:02 |
DeepDive | i didint create it myself so it must have been an unsupported package | 21:03 |
gnarface | if some unsupported package from ubuntu or whatever created it long in the past before you switched from debian to devuan though, it suggests you may have other weird packages doing other weird things... | 21:03 |
gnarface | i dunno | 21:03 |
gnarface | i would make a backup then try to keep my eyes open | 21:03 |
gnarface | you could scan /etc/passwd and /etc/group for anomalies maybe | 21:04 |
DeepDive | the only one I can think of is ungoogled chromium | 21:04 |
gnarface | there shouldn't be anything above uid or gid 1000 except users you created yourself | 21:04 |
rwp | I noticed just in the last week that eudev added "kvm" and "renderer" as new groups it makes in the package postinst script. | 21:05 |
gnarface | rwp: is it possible this is a bug in the current version of eudev actually? afaik, kvm should be a system group though.... | 21:05 |
DeepDive | rwp, so if i delete it and reconfigure udev, it should recreate it correctly | 21:05 |
rwp | Yes. It does an unconditional addgroup without looking to see if one exists. And the script is running with -e. I would say that is a bug. | 21:06 |
DeepDive | i'll try | 21:06 |
gnarface | rwp: no i mean the part where DeepDive has a kvm group of gid 1001 - is that a bug in the current eudev or do you agree with my diagnosis that it had to have been created previously? | 21:06 |
rwp | I agree with you that it had to have been created previously. | 21:07 |
gnarface | ok | 21:07 |
rwp | But prior to a week ago or whenever the new eudev appeared that did not matter. It's a newly introduced thing. | 21:07 |
gnarface | hmm, interesting | 21:07 |
rwp | Because the previous eudev did not do the addgroup and so did not notice. | 21:07 |
rwp | I remember other packages checking for the existence of accounts before creating them. I'll see if I can't find an example. | 21:08 |
rwp | Ha! The postfix postinst script does this test before creating: "chgrp postfix private 2>/dev/null || addgroup --system postfix" | 21:08 |
rwp | And a comment before it saying "# make sure that the postfix user exists. Simplest portable way to check is to chown something, so we'll create the directories that we need here." | 21:09 |
rwp | It was last Sunday Feb 14 because I made a comment about it in devuan-offtopic when I noticed all of my systems getting kvm and renderer added. | 21:11 |
rwp | gnarface, JFTR I don't think the problem is that it *must* be a system group. I think the problem is that the package postinst does the addgroup unconditionally with -e active. | 21:12 |
DeepDive | ok dleeting kvm did the trick. it was recreated as system group | 21:12 |
rwp | Removing the group and letting the postinst add it again on a reconfigure then should succeed. But reconfiguring again should error. I expect from looking at the postinst. | 21:13 |
gnarface | the only real thing i'm worried about is if there is now files somewhere on the filesystem with orphaned gids set | 21:14 |
rwp | Is that an actual problem? | 21:14 |
gnarface | well, contrived, but yes, because the old kvm gid will match the next user he creates probably... | 21:14 |
gnarface | giving that user ownership to stuff they probably don't deserve to have | 21:14 |
rwp | I mean for one the only files ever owned by kvm would be in /dev which is an in memory file system. | 21:14 |
gnarface | that's based on a number of fragile assumptions | 21:15 |
rwp | Probably there are other users already assigned and the next addgroup will go past it to another gid. | 21:15 |
rwp | Certainly a reboot would flush the existing /dev and create a new one. | 21:15 |
DeepDive | given that I am the only use on this machine, I think the prob should be minimal | 21:15 |
DeepDive | *user | 21:15 |
onefang | Do a find on the old gud. | 21:16 |
rwp | Also one could go looking for it. | 21:16 |
onefang | Er gid. | 21:16 |
rwp | Jinx! :-) | 21:16 |
gnarface | yea i just used to work in a multi-user system with NIS and i've seen this go sideways badly | 21:16 |
gnarface | i would recommend scanning the filesystem for that gid | 21:17 |
rwp | I think I would just reboot the system and verify that everything is happy (boots, and so forth) after a reboot. | 21:17 |
rwp | find / -xdev -group 1001 -ls | 21:17 |
gnarface | if you have NIS and NFS together, 1-off uid/gid mismatches can compound problems massively | 21:17 |
rwp | Assuming that one wants to search only / and not any other devices (-xdev) but perhaps other partitions there. | 21:18 |
rwp | DeepDive, Are you using either NIS/yp or NFS? | 21:18 |
rwp | gnarface, I liked the old days when NFS was only based upon the numbers. But now it defaults to --manage-gids and there is all of the name translation of NIS/yp involved. | 21:19 |
rwp | gnarface, I am just generally skeptical of the real problem of removing accounts and a fear of leaving lint files behind. But Debian decided to allow packages not to clean up if the packager was afraid of the problem. And allows closing lint reports that installing and then purging a package leaves accounts behind. | 21:20 |
DeepDive | rwp - NIS/NFS ... you are flying over my head sorry ;-) | 21:21 |
rwp | DeepDive, Then you have answered, "No, I am not using either of those." :-) | 21:21 |
DeepDive | Great ;-) | 21:21 |
DeepDive | I am performinf a find right now | 21:21 |
DeepDive | find / -xdev -group 1001 -ls -- nothing found | 21:22 |
rwp | I can't imagine why there would have been a previously existing kvm user account already created though. I don't see one on my main KVM systems. | 21:22 |
rwp | Good! | 21:23 |
gnarface | well, my loose hypothesis was something like "well there's a kvm with gid 1001, suggesting it was manually created, so maybe it was manually applied to things too..." | 21:23 |
gnarface | i've seen worse happen with good intentions | 21:23 |
rwp | The world is a crazy place and filled with crazy people all doing crazy things. | 21:24 |
rwp | Okay so I have never filed a Devuan bug report before. I want to file on one the postinst for the new eudev package. Where do I start? | 21:24 |
DeepDive | I do use this laptop quite rarely and I am the only one, so I would have remembered. if I had created it :-) | 21:25 |
gnarface | rwp: you can file bugs at bugs.devuan.org but last i heard, of the listed submission methods, only the email one is actually working | 21:26 |
rwp | Hmm... libvirt-daemon-system also creates that group account. | 21:26 |
gnarface | i assume it is standard behavior inherited from upstream. the regular udev package probably does it too | 21:26 |
rwp | find /var/lib/dpkg/info/ -type f -exec grep "add.*kvm" {} + | 21:26 |
rwp | That returns /var/lib/dpkg/info/libvirt-daemon-system.postinst too. | 21:26 |
rwp | Note that they have the right protections to not error if the group already exists. | 21:27 |
rwp | if ! getent group kvm >/dev/null; then addgroup --quiet --system kvm | 21:27 |
fsmithred | submit@bugs.devuan.org | 21:27 |
fsmithred | Package: <package> # first line | 21:28 |
rwp | Email bug reporting works just fine. Preferred actually. | 21:28 |
fsmithred | and give relevant info | 21:28 |
fsmithred | version helps | 21:28 |
fsmithred | and thanks | 21:29 |
rwp | I don't see this reported previously yet: https://bugs.devuan.org/cgi/pkgreport.cgi?which=pkg&data=eudev | 21:29 |
fsmithred | oh, seeing libvirt there reminds me - debsums told me that at least a dozen libvirt files were changed from their defaults | 21:30 |
fsmithred | it's installed by I don't use it and I don't recall changing any files | 21:30 |
DeepDive | glad to have helped you guys finding a bug | 21:32 |
rwp | DeepDive, Yes! Many eyes finds all bugs. And this one is a good one to find. I had looked right at it and not realized what I was seeing when I saw it on Sunday. | 21:33 |
plub | +1 | 21:35 |
DeepDive | And thanks again for your help. Devuan has been an incredibly stable and consistent distro so far ... My old laptop has a new life | 21:37 |
gnarface | hooraaay! | 21:39 |
DeepDive | Have a good day guys, talk to you soon :) | 21:40 |
gnarface | peace | 21:40 |
plub | a 65-year old lady came to me with a 'broken laptop' that windows had slowed-down. spent some time with her, asked her what she did with computer. put firefox, libreoffice, solitaire and a screensaver background changer on | 21:46 |
plub | 'you saved my computer!' | 21:46 |
plub | had one support call. | 21:46 |
plub | thanks to devuan | 21:46 |
plub | but then she started using it more, so her cat peed on the keyboard and she needed a new laptop anyway | 21:47 |
onefang | I turned 60 last month. | 21:47 |
plub | congrats | 21:47 |
rwp | plub, Eccellent work! | 21:52 |
rwp | Where was my spell checker when I needed it? Hmm.. Excellent work! :-) | 21:52 |
rwp | gnarface, (DeepDive left), I filed a bug report by email. It went out. I am still waiting for the reply message to respond with the assigned bug number. | 21:53 |
rwp | And fsmithred too ^^ I'll post the bug number when I get one for it. | 21:55 |
fsmithred | rwp: https://bugs.devuan.org/cgi/bugreport.cgi?bug=550 | 22:05 |
fsmithred | email is slow sometimes | 22:05 |
rwp | fsmithred, Oh! And now I see this one! Oh well. https://bugs.devuan.org/548 | 22:23 |
fsmithred | oops. oh well, I guess they'll be merged | 22:29 |
rwp | fsmithred, I have never quite liked the way the BTS handles merges. I think I will close my report and then add this information to the first one. Simpler to deal with later. Easier all around. | 22:49 |
fsmithred | rwp if you want to reply to bug 548 just email 548@bugs.devuan.org and I can close your report with a note | 22:57 |
kiwi9 | Just another vote for the devs ... **this is a truly excellent OS**. I use it as a desktop and was looking for an XFCE OS that was as efficient as possible (I measure efficiency by idle cpu temperature) while giving me access to the latest packages where needed and Devuan does take the cake. | 23:03 |
kiwi9 | I'm curious. Does anyone use it with s6 and 66 instead of OpenRC ? | 23:03 |
rwp | fsmithred, I have submitted the actions to close my bug and update the previous bug. | 23:07 |
rwp | fsmithred, I am actually fairly proficient with the BTS email interface from using Debian. This is just my first interaction with Devuan's BTS. I didn't know they were using a BTS instance before today. I was afraid they had done something different. Glad to see they have not. | 23:07 |
fsmithred | thanks, rwp. You probably know it better than I do. | 23:08 |
rwp | I wanted to say that I appreciate that you are hinting what should be done next. That's awesome! It helps people out. | 23:08 |
fsmithred | kiwi9, I made a Refracta live-iso with s6, but not 66, and I have done nothing with it. | 23:09 |
fsmithred | I'm not sure that s6 is even running. | 23:09 |
rwp | kiwi9, If you try it with s6 please make a report back as to how well it works. Of otherwise! :-) | 23:11 |
rwp | fsmithred, The BTS web display. Do you know why collapsed all indentation to the left? It rather made the result harder to read. | 23:11 |
fsmithred | no, I don't | 23:12 |
fsmithred | I don't even know what you're saying. | 23:12 |
rwp | When I look at the web display of the email the "The code is this." part, the following script snippets were indented in my original. But are all left aligned in the web display of it. | 23:13 |
rwp | All of the indentation went flat to the left. Which made the understanding of it much more difficult over the original. | 23:13 |
rrq | view page source ;) | 23:14 |
fsmithred | I think the forum might do that, too | 23:14 |
rwp | My command to close #550 has arrived and been processed but not my update to #548 yet but if you look at https://bugs.devuan.org/550 then you will see the problem. | 23:14 |
fsmithred | enter reader view (never noticed that before) | 23:15 |
rrq | yes, there must be a css that "destroys" the <pre> tag layout | 23:15 |
fsmithred | code is indented | 23:15 |
fsmithred | and I haven't seen "view page source" in my browser in a long time | 23:16 |
rwp | I don't know what "reader view" is. Is that a control on the web page or a web browser mode? | 23:16 |
rwp | The source does include a <pre class="message"> tag. So you are likely correct that some css is damaging it. | 23:17 |
rrq | (didn't someone get tasked with moving the bugs.d.o css into the www area?) | 23:17 |
fsmithred | browser | 23:17 |
fsmithred | View | 23:17 |
rwp | And my addition has now been processed and is available at https://bugs.devuan.org/548 | 23:17 |
fsmithred | great, thanks. | 23:18 |
fsmithred | rrq, that sounds vaguely familiar, but maybe just because someone was talking about css | 23:19 |
rrq | yeah... probably "task in progress" I guess :) though css rules for a pre element suggests a competition between content folks and layout folks .. probably should be rendered as a plain div with appropriate layout | 23:21 |
* rrq "thinking" loud | 23:23 | |
rwp | rrq, I don't know what you are saying. But I like the sound of it. :-) | 23:24 |
rwp | fsmithred, I'll just note that my message to #548 was added but my BCC of it to the control server to change the severity still seems to be lagging. That or it failed outright. | 23:26 |
fsmithred | kiwi9, do you know much about s6? I found a VM where I have it installed but not running. Any idea what I should do with it? | 23:35 |
kiwi9 | next to nothing I'm afraid. i have read a bit and the ideas seem to have merit but I don't know how well the implementation has gone. I guess I should try it but was looking to see if I could learn from anyone else's experience :-) | 23:37 |
fsmithred | kiwi9, they're working on this now, instead of 66: https://github.com/DanySpin97/tt | 23:51 |
kiwi9 | thanks | 23:52 |
numzob | get your kicks on Route 66 | 23:52 |
fsmithred | and I'm pretty sure they will come up with a more searchable name when it's ready | 23:53 |
danyspin97 | kiwi9: the best way to test s6 is 66 right now | 23:57 |
fsmithred | is there a guide? | 23:57 |
danyspin97 | fsmithred: I have thought about a new name for tt | 23:58 |
fsmithred | I have s6 installed but no idea what to do with it | 23:58 |
danyspin97 | and well...a rewrite in Rust for various reasons | 23:58 |
danyspin97 | fsmithred: s6 and 66 are different tools though | 23:58 |
fsmithred | don't you need s6 to use 66? | 23:58 |
danyspin97 | you could use s6 without 66, but you need to configure it by yourself and get services from someone who already has them | 23:58 |
danyspin97 | fsmithred: yea, s6 is needed | 23:59 |
danyspin97 | along with s6-rc if I recall | 23:59 |
danyspin97 | correctly | 23:59 |
danyspin97 | I haven't used 66 new versions in 2 years, so I don't know exactly how it should be installed now | 23:59 |
fsmithred | s6 and s6-doc are the only packages | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!