#devuan

14:47:20 <brocashelm> gnarface: so, doing a bit of research on corectrl, this linuxreviews article shows some ways to hack the user-specified gpu/cpu settings into the kernel/on startup: https://linuxreviews.org/CoreCtrl

14:49:46 <brocashelm> can be done through polkit rules as an example, although pkaction --version told me i was using 0.105 instead of 0.106

16:28:54 <loosh[m]> found it guys i edited /etc/elongind/logind.conf

17:25:55 <spine-o-saurus> hey I need to make openrc script for network interface to accept dhcp lease

17:26:44 <spine-o-saurus> dhclient was running but as soon as the nic plugged in it never got an ip

18:11:07 <yaglu> anyone else having trouble with the display manager not launching?

18:12:04 <yaglu> i just did a fresh install...with kde...install was fine...restarted the system...had to issue startx manually...

18:13:06 <gnarface> you might need to switch permissions backends or uninstall a redundant one or something like that

18:13:59 <gnarface> not all combinations of login managers and window managers work

18:14:12 <gnarface> you might have missed one or it might just have the wrong one

18:14:37 <gnarface> permissions backend, login manager, window manager < these 3 things are picky about what they play nice with

18:16:22 <gnarface> hmm, or at least that was the problem in previous releases, i thought it still was but maybe they finally fixed that...

18:16:46 <gnarface> anyway if you have no login manager try lightdm

18:18:33 <gnarface> hmm, yea maybe they fixed it sorry about that, try making sure lightdm is installed, that's the one that worked for me with kde in beowulf

18:19:40 <gnarface> does installing lightdm and elogind help anything?

18:19:40 <yaglu> sddm is installed...so no...i dont wanna install lightdm

18:20:42 <gnarface> the new release notes do seem to suggest sddm is supposed to be working

18:20:53 <gnarface> i'm not sure how you'd have gotten it without proper dependencies in that case though

18:24:35 <yaglu> screw it...lemme just go back to ghetto xinit scripts and trusty ol dwm

18:24:45 <yaglu> i wanted to give kde a try after a long time

18:31:59 <gnarface> anyone know if this was supposed to work? i don't see the thing about having to have special permissions backends paired with the desktop manager anymore in the release notes

21:21:40 <unixdan22> Hello, I have graphic artifacts on ThinkPad T430 and T530 with integrated Intel HD 4000 GPU. Sometimes white dots appear all over the screen. It seems to be an xserver driver issue. How can it be fixed?

21:27:51 <gnarface> unixdan22: yes, but you'll have to be patient because the channel is kinda slow at these hours

21:28:09 <gnarface> kinda sounds like video ram failure though, i'm afraid to tell you

21:28:34 <gnarface> if it's a software bug and you're fully updated, try the backports kernel, sometimes it helps

21:40:16 <humpelstilzchen[> unixdan22: do the dots appear on both machines?

21:43:58 <unixdan22> Yes, they appear on both machines. It is unlikely to be a hardware issue, because I have run hardware tests (e.g. memtest) on both machines and they all pass.

21:45:00 <humpelstilzchen[> What xorg driver are you running?

21:48:06 <unixdan22> The artifacts appear more often, when there is intense rendering. For testing I watch the animations on https://webglsamples.org/

21:50:14 <unixdan22> I have tried switching to the intel driver. Now the the dots appear only on objects and not on the background.

21:59:46 <unixdan22> On https://webglsamples.org/book/book.html white dots appear on the aquarium image when I drag the page.

22:20:52 <pmp-p> unixdan22: most likely kernel driver issues i have artefacts on atom Zxxx gpu as well , they like to go as fast as possible from WIP to obsolete-wontfix nowadays

23:28:24 <Kitty> So I found a bug in python's tz library caused by the tzdata package in devuan/debian

23:30:53 <Kitty> the tzdata package has the timezone for Kyiv under the old name Kiev.

23:31:17 <Kitty> when you try to use python, it's internal pytz package doesn't know of this Kiev of which we speak, only of Kyiv.

23:31:31 <Kitty> there is no tz called Kyiv according to tzdata

23:33:48 <Kitty> hmm, there is no testing or unstable version of tzdata

00:27:04 <cytokine_storm> how do i check the boot time. im using sysv

01:16:02 <___used> Where did he go? `sudo grep 'Activating swap\.\.\.' /var/log/boot` is one way

03:18:11 <rwp> Boot time can be checked with "who -b" for one way. I am sure there are other ways too.

03:19:25 <___used> I assumed this kind of question is asked with the system down, requiring a look into logs.

03:19:47 <___used> When up, uptime is popular. Did not know about who -b

03:23:39 <rwp> who -b reads /run/utmp where system boot time is logged.

03:24:22 <rwp> That does depend upon proper logging to occur. But since this is Devuan we don't need to worry about systemd breakage.

03:24:51 <___used> In theory. Why does who -p -m return nothing?

03:25:09 <rwp> I have never used them, so no idea, but probably nothing is logged for them.

03:25:21 <rwp> Some of those options are non-portable and only do things on Solaris systems and things like that.

03:26:17 <rwp> I have used "who -b" for a very long time to get this information the most reliably.

03:27:55 <rwp> Standards docs on who options: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/who.html

03:28:28 <___used> I just read the manpage for who on Beowulf. Feb 2019 vintage, GNU coreutils.

03:29:15 <___used> `who am i` returns nothing here, but there is `whoami`

03:29:52 <___used> Returns nothing and $? -eq 0 ... fails succesfully. I _hate_ that sort of program.

03:30:20 <rwp> If "who am i" returns nothing then your utmp logging is broken. :-(

03:31:37 <rwp> whoami returns the same as "id -un" which returns running process information.

03:32:09 <rwp> "who am i" returns who the tty was logged into from the logged utmp data. Who the process logged into the tty with is historical information.

03:32:59 <rwp> Historical because I could log in as rwp and then I could su to root and then I could su to ___used and then whoami would be ___used but "who am i" would still be rwp who I had logged in as originally.

03:33:33 <___used> Yeah, so, logging is not... as complete as one would wish. Toy OS ;)

03:34:10 <rwp> When using sudo to change users sudo leaves a trail of breadcrumbs with SUDO_USER and others to log the previous user in the environment.

03:35:38 <rwp> Sorry I said utmp for some things above that I should have said wtmp for. My bad.

03:36:06 <rwp> See "man wtmp" for some useful information about the logging. I am curious why your ?tmp is not logging this data for you.

03:36:39 <rwp> There is also "lastb" to which prints out information from btmp which logs bad login attempts but it's pretty unreliable information, don't use it.

03:37:02 <rwp> If one is really trying to track bad logins then one should trace through /var/log/auth.log for all of the details as they happen.

03:38:20 <rwp> If last is reporting boot times for you as logged in /var/log/wtmp then I would think "who -b" should be able to do so as well.

04:33:46 <___used> What I really hate is the zero return code from `who` when unimplemented/unavailable arguments are used.

04:37:06 <gnarface> speaking of unimplemented arguments... i was doing a ceres update last night and something flew by about unimplemented argument -cert[something or another] but i couldn't figure out what package specifically it came from or what it broke. anyone know what's up with that by chance?

04:38:15 <gnarface> oh it was "illegal option: -cacerts" or something similar

04:38:32 <gnarface> it came up in searches for various packages but at first glance nothing i had installed

04:38:58 <gnarface> it did happen while there was a bunch of .pem file names scrolling by though

04:39:37 <gnarface> (i reinstalled what i thought it could be but the error didn't happen again so i don't know if i got it)

04:42:15 <gnarface> you're right i should have been logging, i was being sloppy

04:42:29 <gnarface> i do have /var/log/bootstrap.log but the error isn't mentioned there

04:43:25 <gnarface> whatever package it was, the package install didn't get marked as a fail

04:44:21 <gnarface> i couldn't even be sure from the context whether the command actually did something

04:44:49 <___used> I was unable to log installs using aptitude.

04:44:51 <gnarface> it was clearly complaining about that option but it didn't tell me whether that means it canceled out or actually just worked normally in spite of the error

04:45:29 <___used> The dpkg status logs exist, one can backtrack through them, but why would aptitude implement Tetris, but not logging?

04:45:51 <___used> (it has a Tetris game built in for long slow download installs)

04:46:24 <___used> Essential in snail's paced modem days, not so much now.

04:47:19 <___used> Sorry, Minesweeper, not Tetris. Just opened it to check.

04:49:48 <___used> I tried to pipe aptitude through tee, it works but the "gui" leaves tons of garbage in the log file

05:45:22 <rwp> I never warmed up to aptitude. For me apt-get is my favorite Dr Who actor.

05:45:34 <rwp> gnarface, Do you have /var/log/apt/term.log that you could review? I suggest "less -r" on it.

05:47:02 <gnarface> rwp: ah! thank you, i should have known about this

05:48:00 <gnarface> the relevant package appears to have been ca-certificates-java, and it was one of the ones i reinstalled on a hunch, but the error didn't happen the second time so i'm not clear on what is broke

05:49:36 <rwp> You might review the postinst script by eye and see if you see anything. /var/lib/dpkg/info/ca-certificates-java.postinst

05:52:15 <rwp> I look and find the line containing "cacerts_aliases=$(keytool -cacerts ..." but "man keytool" does not list that as an option.

05:53:53 <gnarface> here we go, i'm not the first to notice it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015771

05:56:13 <gnarface> i see it looks for /var/lib/ca-certificates-java/fresh which explains why it didn't run on the second time but the rest is a mess and i'm afraid to screw with it

05:57:13 <gnarface> generating a bunch of aliases or something like that?

05:59:22 <rwp> If it were me I would post an update to that bug ticket saying simply that you had hit the error too.

05:59:42 <rwp> That would add a recent ping to it and perhaps wake people up that the problem hasn't been addressed yet.

06:00:22 <rwp> Since it has been a month since the first report and no acknowledgement about it. That's long enough for a ping about it.

08:14:50 <xrogaan> Is somebody aware of breaking changes coming in the next stable?