IRC log for #devuan on 20191126

00:07.13*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
00:10.50systemdletedmesg shows that there's a drm error about 60 seconds after the previous messages, and that's about how long the delay is
00:31.06systemdletenvm my crack about drm error:  That was on my host devuan.
00:32.05systemdleteIn my VM, when I logout of xfce (the polite way), the screen goes to blank for a very long time (indeterminate)
00:32.27systemdleteIf I open a window on, say, tty1 and restart slim, the running slim won't die -- stop fails.
00:32.46systemdletebut slim does restart successfully, and the DM appears in tty7.
00:38.41*** join/#devuan tuxd3v (~tuxd3v@78.130.55.150.rev.optimus.pt)
00:39.07tuxd3v#join #devuan-arm
00:44.38HurgotronI upgraded a rather small install of ascii to beowulf, now ssh logins have a delay of 25 seconds.
00:44.50Hurgotronauth.log says "Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)"
00:45.31HurgotronThe web suggests that restarting systemd-logind helps... but I'm on Devuan. :)
00:45.34Hurgotronanyone?
00:47.09golinuxDoesn't elogind take care that?
00:47.46golinuxI am no expert but check if you have any of that installed
00:48.27Hurgotronyes it's installed... should it be running?
00:52.03*** join/#devuan IoFran (~Thunderbi@189.237.240.124)
00:52.15golinuxRead the release notes carefully: http://files.devuan.org/devuan_ascii/Release_notes.txt
00:52.45golinuxThe answer is probably in there.
00:53.04golinuxIt definitely isn't in my head.  :D
00:53.15Hurgotronwell it worked with ascii, without elogind :)
00:53.37HurgotronBut anyway, I'm on the right track now.
00:54.01Hurgotronfucking cgroup shit isn't available in my vserver.
00:55.31tuxd3vhello, does any body has devuan running in the HP Mycloud Home NAS?
00:59.07gnarfacetuxd3v: i don't have one, but what is the issue you're having with it?
01:00.19tuxd3vgnarface, mine doesn't run devuan :(
01:00.38tuxd3vI was thinking in.. see if possible to have devuan running there :)
01:01.24tuxd3vI believe a propeietary module or something was needed, in the pastm don't know if linux kernel already has all what is needed..
01:01.49gnarfacetuxd3v: oh, i thought you were just having trouble locating the Samba mount point.  i don't know about actually installing linux onto one.
01:02.54tuxd3vbut even so, I also  need support from the bootloader.. I am not yet getting the dust out of it, but I will when I have devuan running like it should in my RPi1 B v1.0 :)
01:03.06systemdleteSo I killed the slim from tty1.  Started it manually, with -d, but now the whole VM seems to be hung.
01:03.13tuxd3vright now is compiling a kernel... 2 days now, and counting :)
01:03.33systemdleteQuestion:  Was there any changes in 2.1 having to do with entropy?  Some of the entries re slim delays seem to revolve around entropy issues.
01:03.43systemdlete(entries = google hits)
01:04.38tuxd3vsystemdlete, does you have rng-tools installed ?
01:05.09tuxd3vif so point it to '/dev/urandom' just to ckack the solution :)
01:05.13systemdleteno, I tried that.  It's a VM, so there's no rng device.  But I did install haveged, which was recommended.
01:05.23systemdleteno help
01:05.29systemdletesame problem persists
01:06.17tuxd3vI tried haveged but got rng-tools back, with '/dev/urandom' in /etc/defaults/rng-tools
01:06.30systemdletehmmm.  In a VM?
01:07.04tuxd3vfor know in kernel 5.3 no support for TRNG on Allwinner H6( Orange Pi one plus.. ), so its the only option..
01:07.13systemdleteAt any rate, running slim from command line, as root, results in a hang (in a VM at least)
01:07.34systemdlete(I'll try that, thanks)
01:07.43tuxd3vbut are you sure it has to do with rng?
01:08.03systemdletewhat has to do with rng?  The long delay or the slim hang?
01:08.32systemdleteI googled for hits on long delay on slim and some of the hits suggest entropy issues.
01:08.55tuxd3vho..
01:08.57systemdletegoogle "slim: waiting for x server to begin accepting connections"
01:09.12systemdlete(that's the last message I see in slim.log)
01:10.57*** join/#devuan rdav (~rdav@110.193.150.122.sta.dodo.net.au)
01:12.31gnarfacei think you should be able to get urandom in a VM... it's not a hardware device...
01:13.13tuxd3vI saw some hist about problems related with glibc 2.38, but we are in 2.24-11 I believe ?!
01:13.44tuxd3vyeah I sugested puting it in /etc/default/rng-tools
01:13.45systemdletegnarface, tuxd3v:  I'm trying it now!
01:14.08tuxd3v<PROTECTED>
01:14.21systemdletetuxd3v: DId you try googling what I did, see above
01:14.32tuxd3vsystemdlete, let us know if that solved the problem
01:14.41systemdleteoh, I will, believe me...  :D
01:14.53systemdletenoop
01:14.59systemdletestill hangs at boot
01:15.16tuxd3vyes, I saw one of the first hits about glibc 2.38 on gentoo
01:15.18systemdleteI use the term "hang" loosely, of course.  Eventually, I do get the login screen
01:15.31systemdletelook at subsequent hits also
01:17.47systemdletesome of the suggestions I've seen are to wiggle the mouse a bit during boot... that made me laugh
01:18.07systemdletereminds me of that Dilbert cartoon where his boss can't get his "laptop" to work...
01:18.38systemdletehe tells the pointy-haired boss to "turn it over and shake it"
01:18.49tuxd3vwell, that is in fact related to low entropy
01:19.01tuxd3vor slow entropy device..
01:19.25systemdleteFunny, I didn't have slow entropy until now
01:19.28tuxd3vbecause entropy is got by several ways
01:19.56tuxd3vI don't have problems with my slim
01:20.14systemdleteare you in a vm?
01:20.23tuxd3vI use slim and slimlock...I am just amazed by its simplicity, beauty, and functionality
01:20.26tuxd3vno
01:20.29fsmithredsystemdlete, did you install the full desktop or just the parts you want?
01:20.32systemdleteah
01:20.34tuxd3vI am in a real server :D
01:20.47systemdlete:p  real server...
01:20.55tuxd3vyeah
01:21.13tuxd3vif you want I can share my config with you..
01:21.18tuxd3vanother thing..
01:21.29tuxd3vdoes you have a .Xinitrc file
01:21.38systemdletefsmithred:  Depends what we are talking about here.   This VM was ascii 2.0 and I have updated/upgraded to newest packages which I have been led to believe makes my VM 2.1 ascii now
01:22.00systemdletewas working under 2.0 --> now not working under 2.1 with (mostly) same software
01:22.11fsmithredis this the first time you've upgraded since you installed the system?
01:22.13systemdlete*other software
01:22.27golinux<systemdlete> Question:  Was there any changes in 2.1 having to do with entropy?
01:22.30systemdleteno, not by any means.  I have been updating pretty often
01:22.41fsmithredthen you were already there
01:22.45systemdleteok
01:22.47golinuxThere is in beoowulf iirc
01:22.55fsmithredthe only reason to call it 2.1 is because there are updated isos
01:23.01systemdleteright
01:23.29systemdleteI even tried to force re-install slim.  Which it did, but to no avail.
01:23.34fsmithredyeah, in beowulf you can get delays with openssh-server
01:24.07fsmithredmake sure you've got all the right libpolkit packages
01:24.07systemdleteI also think that those hits are talking about much newer kernels, like 5.x
01:24.07tuxd3vhehe, my RPi1 is compiling a kernel for 2 days , and I suspect a 3rd one is comming..
01:24.09golinuxsystemdlete: Do you have a mixed system?
01:24.39tuxd3vMy "desktop", compiled a kernel in the moments I were here speaking with systemdlete :D
01:24.59systemdletetuxd3v:  impressive
01:25.10systemdletegolinux: ?
01:25.33fsmithredis there any beowulf in your sources.list?
01:25.40systemdleteshouldnt be
01:25.55tuxd3vthe thing is.. I doesn't wanted the kernel compiled, just wanted the process to download it, but it downloaded and compiled it without I notice it..
01:25.58systemdleteThe only VM I've done that in is my beowulf experimental VM.
01:26.10tuxd3vthis machines are bacoming fast...
01:26.24tuxd3v<PROTECTED>
01:26.28systemdletetuxd3v can have his pie and eat it too
01:26.35systemdletes/pie/pi/
01:27.00systemdletewhat is a "mixed" system?
01:27.17fsmithredmixed stable/testing or other
01:27.21golinuxascii/beowulf
01:27.23systemdletemixed-up, probably.  But that has more to do with the operator I am afraid...
01:27.30systemdleteah.
01:27.32systemdleteNo
01:27.36fsmithredreally, check the polkit shit
01:27.51golinuxI second that
01:28.17systemdleteAs I said, my only references to beowulf are in an ascii-cum-beowulf VM I have been experimenting with occasionally.  That's a different VM though.
01:28.28systemdleteOh what fun. Check the polkit shit...
01:28.38systemdletegoes off, not to be seen for years and years
01:28.39fsmithreddpkg -l | egrep "consolekit|elogind|policykit|polkit|libpam"
01:28.47fsmithredand past result
01:28.54fsmithredpaste
01:28.55golinuxYou have ascii in your sources.list or testing?
01:29.36systemdleteI can tell you that there is no elogind here, only consolekit, for compat with xfce, as per the instructions in release notes
01:29.38golinuxoops or dtable
01:29.47systemdletehold on
01:29.49golinuxstable
01:30.46golinuxIf you have stable your are pulling debian pkgs from Buster.
01:30.55systemdletedpkg -l | egrep "consolekit|elogind|policykit|polkit|libpam" ---> http://paste.debian.net/1117962/
01:31.38systemdletesources.list --> http://paste.debian.net/1117963/
01:31.42fsmithredinstall libpam-ck-connector
01:31.44fsmithredpretty sure
01:32.20systemdlete<PROTECTED>
01:32.39systemdleteoh shit
01:32.43systemdletenever mind those
01:32.50systemdletehas finger-checked again
01:33.00systemdleteright pew, wrong church
01:33.04systemdletethose are for my host devuan
01:33.07systemdlete(sorry!)
01:36.17systemdletedpkg -l |grep etc ---> http://paste.debian.net/1117965/
01:36.42systemdletehttp://paste.debian.net/1117966/
01:36.51systemdlete(sources.list)
01:37.18fsmithredthey're the same
01:37.30fsmithredand you don't have the problem in the host system?
01:37.56systemdleteehhh.  No.  Though I've had some OTHER interesting problems lately.
01:38.50fsmithredone more thing to check. It's unlikely, but maybe some backports packages slipped in.
01:38.54systemdleteWhen this ascii VM locked up a day or two ago, due to some problem with a web page, it caused the hostkey to stop working, even though I could ssh in from my  testbox to the host
01:38.58fsmithreddpkg -l |grep bpo
01:39.13fsmithredwill give some false positives. Look for ~bpo in the version
01:39.31systemdletehttp://paste.debian.net/1117967/
01:40.04systemdleteyeah, lots
01:40.14systemdleteremmina libpolkit
01:40.19fsmithreddid you intend to install all those from backports?
01:41.25systemdletenot sure.  Remmina, maybe.  Long time ago.
01:41.38systemdleteis dovecot coming from backports also?
01:41.55fsmithredyes
01:41.58systemdleteoh
01:42.09systemdleteis there a normal one in the other repos?
01:42.16fsmithredall the ones with ~bpo in the version
01:42.33systemdleteif not, I don't mind using package called "imap" instead
01:42.48golinuxBTW us.deb.devuan.org is not recommended as there is no us mirror
01:43.33fsmithredno remmina in ascii
01:43.50systemdleteah, well, I can probably remove remmina
01:44.30systemdletefsmithred:  Do you suspect an incompatibility causing this slim issue?
01:44.42systemdleteOr is your concern elsewhere?
01:44.42fsmithredit's possible
01:44.45systemdleteok
01:45.01fsmithredI don't know what all those backported polkit packages do
01:45.10golinuxI was thinking that
01:45.27systemdletemakes remmina go *POOF!*
01:45.28fsmithredoh
01:45.43fsmithredpolicykit-1 in ascii-security is the bpo version
01:46.33fsmithredtry installing libpam-ck-connector
01:48.16*** join/#devuan Xenguy (~Xenguy@devuan/community/Xenguy)
01:48.48systemdleteeh... I'm not getting something here.  dpkg -l is still showing dovecot-core and dovecot-imapd but I can't remove them because apt-get thinks they're not installed?
01:49.01systemdleteI was able to remove remmina no problems
01:49.57XenguyHey folks, I saw an email about a point release for Ascii, but no updates have shown up yet?  Any ideas why?
01:50.13XenguyMy mirror is deb.devuan.org
01:50.24Xenguy(as recommended, I believe)
01:51.03Xenguysystemdlete: dpkg -r  ?
01:51.17gnarfacei don't know anything specific about the point release, but sometimes mirror propagation takes a few hours
01:51.35gnarfacehow long ago was it announced?
01:51.41Xenguygnarface: Yeah, probably just need to be patient
01:51.49fsmithredXenguy, the new isos have been up for a couple days
01:51.52Xenguychecks the email timestamp...
01:51.59fsmithredif you've upgraded recently, you're already there
01:52.01golinuxJust do a normal upgrade and you should be there.  Those pkgs have been arounf for a while so you
01:52.10golinuxshould have them
01:52.24systemdletenvm.  Those are just the config files.  I want to save those.
01:52.24golinuxThat mind meld thing again.
01:52.30XenguyHrm, so maybe this is just a false alarm
01:52.41golinuxThere is no alarm
01:52.46XenguyOK thanks, I'll chill
01:53.45tuxd3vsustemdlete, have you tested what we spoke above?
01:53.52golinuxThere is if you are installing for the first time.  The apt security bug fix is in the new isos etc,
01:53.54se7enI just read the email stating that there is an ASCII upgrade, v2.1
01:54.05se7enWill `apt full-upgrade` upgrade my system?
01:54.07XenguyMeanwhile, I miss y'all (you too furrywolf) but I've been kidnapped by HR (the thieving bastards!)...
01:54.47golinuxProbably just a normal upgrade would do.
01:54.48XenguyIt'll all be over by Wednesday, and a bloody Amen to that
01:55.07se7enI usually run `apt update && apt full-upgrade` to ensure I don't have broken packages anyway
01:55.32se7enAlso, any plans to host Libressl on apt?
01:55.54se7enI'm a bit tired of compiling it, and then in apt openssl often installs and replaces it
01:56.39fsmithredmake a deb package so it won't do that
01:57.20se7enWell, I've never made a .deb before so I'm a bit afraid that I'll do it wrong
01:57.38gnarfacese7en: just use checkinstall.  it is easy
01:57.53se7enWill look into, gnarface
01:58.20XenguyThanks gnarface fsmithred golinux , I think I'm good
01:58.41Xenguy^^ Checkinstall is awesome
01:59.00gnarfaceXenguy: if you need to be sure, i'd say just check the last few things in your /var/log/apt/history.log against the versions showing up in pkginfo.devuan.org currently
01:59.26gnarfacebut yea if you recently ran an "apt-get upgrade" and got packages, you probably have all the updates already
01:59.29XenguyRight on (just after I kick HR's ass ; -)
02:00.24Xenguygnarface: I think I just misinterpreted what a "point release" is, so I'm thinking it's all good now
02:00.49systemdletesorry, tuxd3v, I forgot what that was...
02:01.25Xenguygoes up in a puff of smoke...
02:01.56systemdleteI remember you wanted me to test something, but I think it scrolled off
02:06.45*** join/#devuan qbmonkey (~SockMonke@2600:6c46:4f80:1c00:20b:97ff:fe94:9aa2)
02:13.45systemdletefsmithred:  Still working on removing those policykit stuff from backports
02:14.03systemdleteproblem is, it wants to remove a good chunk of my system with those packages
02:14.29systemdleteIs there a way to safely downgrade?
02:14.45systemdleteto pick up those packages from the regular repos
02:15.31gnarfacenot really, at this point.  downgrades aren't tested upstream.  but if you purge all the backport packages it will probably be ok
02:16.25gnarfaceif you sucked in the wrong thing though, like say, a newer version of apt that fundamentally restructured your dependency tree.... then there may be no going back
02:17.14systemdlete"you can checkout any time you like, but you can never leave..."
02:17.23gnarfaceyea, something like that.  keep backups.
02:17.28systemdleteoh yes.
02:17.34systemdleteI do.
02:17.44systemdleteI backup my backups to the cloud.
02:18.06*** join/#devuan fling (~fling@fsf/member/fling)
02:18.09systemdleteI'll have to try it at the command line because it wants to remove dbus
02:18.25systemdleteI'm afraid that'll choke any desktop I'm running like xfce
02:18.57gnarfaceit's reasonable to expect it may remove some things you will want to re-add after.  just be careful that if it removes the kernel you don't reboot before installing another :)
02:19.24systemdleteI don't think the kernel was one, no
02:21.13systemdletebut udisks2 is one it wants to remove
02:21.50fsmithredsystemdlete, you should not remove them. They are from ascii-security
02:22.09systemdletebut they are ~bpo
02:22.35fsmithredapt-cache policy policykit-1
02:22.44fsmithreddon't paste the result. I already know it.
02:22.53fsmithredDid you try adding libpam-ck-connector?
02:23.14gnarfacewell, you don't actually need udisks2 to boot
02:23.26gnarfaceit's for gui drive mounting tools
02:23.31systemdletewell, I'd replace it as soon as I have the rest removed
02:24.15systemdleteok, connector is installed.  Reboot?
02:24.25fsmithredthey're gonna come back on the next upgrade
02:24.37fsmithredeven if you comment out the backports repo
02:24.58systemdlete(I have commented out the backports already, and updated)
02:24.59fsmithredreboot or 'init 1'
02:25.35systemdleteslim has difficulty shutting down also.  Apparently it cannot stop X
02:25.52fsmithredI'm not surprised.
02:26.09systemdletewow.
02:26.16systemdletefixed it, fsmithred!  fixed it!
02:26.23fsmithredyup
02:26.23systemdleteslim came right up
02:26.38systemdletetries it again, just for fun
02:27.19systemdleteuh-oh
02:27.22systemdletespoke too soon.
02:27.36systemdleteafter reboot, back to same fun-and-games...  :(
02:28.21systemdletecrap.
02:29.12systemdletewonders if anyone else in this channel is having as much "fun" as he is with an ascii 2.1 upgrade in a VM
02:29.26fsmithrednope
02:29.35systemdleteVM?
02:29.45fsmithredyeah, most of my test systems are in vm
02:30.01systemdleteso...
02:30.24gnarfaceso what did you do!?
02:30.26systemdleteAs the song suggests, I don't "mess around with (sl)im"
02:30.41systemdleteI guess I broke it.
02:31.04*** join/#devuan furrywolf (~furrywolf@172.58.95.68)
02:31.14gnarfacehehe well that part is reasonably obvious.  the real question is how, specifically?
02:31.31gnarfacethe trick is being able to retrace your steps
02:31.37systemdleteIt all started...
02:31.44systemdleteI had a bad childhood...
02:31.51gnarfacewoah there
02:31.53gnarfacenot that far back
02:32.02systemdlete:D
02:32.02fsmithredyou only need to go back as far as root's history
02:32.08gnarfaceprobably just back to the last thing you installed/upgraded, or maybe the thing right before that
02:32.18systemdletethinks
02:32.19gnarfacesomething from backports, or a custom kernel maybe?
02:32.28systemdleteno custom kernels
02:32.35fsmithreddovecot?
02:32.39systemdletebackports, the ones you know about.
02:32.41systemdleteAh!
02:32.42gnarfaceany custom builds, 3rd party packages or weird non-stock configuration edits should be suspect...
02:32.48systemdletenow dovecot I've had some problems with
02:33.01systemdletewhich makes me wonder...
02:33.10systemdletedisables dovecot and reboots...
02:33.16fsmithredisn't that some fedora thingy?
02:34.13systemdletedovecot?
02:34.23fsmithrednm, I looked it up
02:34.25systemdleteidk really
02:34.41systemdleteit was the first imap server I ever worked with
02:34.41gnarfaceit's in debian but it's kinda messy
02:34.55fsmithredI was thinking of dracut
02:35.13systemdleteoh, no.  not dracut
02:35.17gnarfaceit's kinda general purpose imap thing but if you start actually trying to generally repurpose it, things can get weird
02:35.24systemdleteIn fact, I rarely touch tools like those
02:36.11gnarfaceoh hmm.... imaps starving entropy was a thing i had an issue with i think once...
02:36.20systemdleteI can tell you this (maybe this would be helpful?):  The last message I see in slim.log is that it is waiting on X to start receiving connections
02:36.42systemdletewell disabling dovecot helped zero
02:36.50gnarfaceyea i saw you mention that earlier.  i silently concurred with someone else's hypothesis that it could be a entropy starvation issue
02:37.02systemdletehow cruel!
02:37.17fsmithredinstall haveged?
02:37.45fsmithredI had to do that for live isos that have openssh-server
02:37.46gnarfacewell, switching to /dev/urandom should have worked too
02:37.58gnarfacenot securely, but it would have worked
02:37.59fsmithredwhat do you switch?
02:38.00systemdleteyeah, right now, though, I have rng-tools because tuxd3v wnated me to try that, pointing to /dev/urandom, etc
02:38.07systemdletebut I can go back to haveged
02:38.29gnarfacefsmithred: anything that would otherwise read from /dev/random as a source
02:39.08gnarfacefsmithred: it's a ugly quick&dirty hack but you basically can just symlink /dev/random to /dev/urandom and you should no longer get any blocking while waiting for entropy
02:39.13systemdletegnarface:  removed rng-tools
02:39.27fsmithredthanks
02:39.59fsmithredfor the live isos I had to make sure haveged started before ssh
02:40.00systemdletewhat is the entropy being used for anyway?  I mean, why does slim demand it?
02:40.08fsmithredno clue
02:40.12gnarfaceyea that's a good question
02:40.14systemdleteok, installing haveged
02:40.37systemdleteusually asks pretty good questions. It's just that the answers to them are kind of, well, you know.
02:41.27gnarfacedoes slim support network authentication or something?
02:41.46gnarfacecould it be prepping an encrypted socket for something?
02:42.28gnarfacei don't even know, but there are very few rational excuses
02:43.09gnarfaceit could be hanging on a network timeout of some sort too though, unrelated to encryption handshakes...
02:43.42systemdleteok rebooted with haveged installed and enabled.  Still slow to get to slim
02:44.02gnarfacehave you timed it yet?
02:44.11systemdleteI'm wondering if maybe I should just rebuild the system from a 2.1 ISO.  I could restore my home and system files.
02:44.21systemdleteno.  But I think it takes about a minute
02:44.27systemdleteI can time it.
02:44.44fsmithreda minute?
02:44.44systemdletefrom the moment it goes blank
02:44.46gnarfaceif it takes the same amount of time every time within less than a second, that is evidence
02:44.52fsmithredoh that.
02:45.02fsmithredI thought you meant the install takes a minute.
02:45.03gnarfaceif it's exactly 60 seconds every time, then it's *almost certainly* a network timeout issue
02:45.18gnarface(possibly related to DHCP and your MTA)
02:45.37systemdletei disabled dovecot
02:45.45gnarfacedovecot isn't the MTA
02:45.45systemdletenot using dhcp or dhcpcd
02:45.52fsmithredwhat's in /etc/network/interfaces?
02:45.52systemdletepostfix
02:45.58fsmithredauto or allow-hotplug?
02:46.17systemdlete(doing timing test)
02:46.22*** join/#devuan qbmonkey (~SockMonke@2600:6c46:4f80:1c00:20b:97ff:fe94:9aa2)
02:46.33gnarfacesystemdlete: did you disable postfix too as a test?  make sure no alternatives are installed either, like exim4 or sendmail...
02:49.06systemdlete02:10
02:49.18systemdletenot yet, doing now, then timing again
02:49.46gnarfacehmm.  2:10 is long for a network configuration issue based timeout
02:50.23systemdletewell, some of that might be something else, although 10 seconds for that other thing is kinda long also
02:50.28systemdletelet me get you another timing...
02:52.09*** join/#devuan aqu4bot (~aqu4bot@unaffiliated/subsen/bot/aqu4)
02:53.51systemdlete2:10 again
02:54.05systemdleteand both postfix and dovecot were disabled this time
02:54.12systemdletewhat if I try a differnt DM?
02:54.22systemdletejust to see if it might be slim-related?
02:54.33gnarfaceit's a good idea
02:54.37gnarfaceyou could try without a DM entirely too
02:54.44systemdletewell, I've done that.
02:54.57systemdletethe login comes right up
02:55.23tuxd3vhumm
02:55.37systemdletesorry, no
02:55.40tuxd3vgnarface is right, it could
02:55.43systemdleteI mean, the desktop comes right up
02:57.11tuxd3vcan you share your '/etc/slim.conf'
02:57.13systemdleteI don't care if it's not compat with my desktop b/c I'm not actually going to try to login, right?
02:57.13tuxd3v?
02:57.58systemdletehttp://paste.debian.net/1117975
02:58.21systemdleteI dont' recall changing it, but I might have
02:58.27systemdletes/dont'/don't/
02:58.51systemdletegnarface:  which DM should we try?
02:58.55tuxd3v... I made a builder so that I could be in charge, clicking the buttons..now my builder builds kernels without me doing nothing...boring
02:59.44systemdlete(tuxd3v: Typical Marxian phenomenon, where the worker becomes alienated from his work)
03:00.16systemdletesddm?
03:00.20systemdletexdm?
03:00.28systemdletelightdm?
03:00.32fsmithredlightdm should work
03:00.35systemdleteok
03:01.08fsmithredI need to sleep.
03:01.30fsmithredgood luck with it.
03:03.45systemdletethank you so much again, fsmithred.
03:03.52tuxd3vfsmithred, good night
03:04.00systemdleteg'nite, fsmithred
03:04.13tuxd3vsystemdlete, take my config: https://paste2.org/C8PmFkyx
03:04.24tuxd3vsubstitute tuxd3v by your user to login
03:04.41systemdletewell, a little delay, but then lightdm appears
03:04.42tuxd3vmake abkackup of your config, and experiment with this one :)
03:04.51systemdleteI will try again, to see if it is faithful
03:05.18systemdletetuxd3v: thanks.  Let me finish this test with lightdm, then I'll try your config.
03:05.35tuxd3vno problem
03:06.57systemdletecame right up again (lightdm)
03:07.04systemdleteone more time, just for certainty...
03:11.24*** join/#devuan rdav (~rdav@245.184-26-211.sta.nsw.iprimus.net.au)
03:16.40tuxd3vsystemdlete, solved?
03:16.50systemdletehold on
03:16.55systemdletestill getting slim back
03:16.59tuxd3vok
03:17.12systemdleteI will need desktop to copy in your file -- I hate typing
03:17.34systemdleteIt's coming... it's in its usual 2:10 pause
03:17.48systemdleteso it is definitely a slim-related issue somehow
03:17.58systemdletebecause lightdm came right up upon boot
03:19.30tuxd3vactivate openssh-server then do a scp to inside of the vm ;)
03:20.52systemdletenah
03:20.56systemdletethis was quick enough
03:21.12systemdleterebooting with YOUR slim.conf (I saved the one I had though)
03:21.43systemdletenot looking too good
03:21.54systemdleteit's hanging there, blank screen again
03:22.24tuxd3vhumm
03:23.09systemdleteslim IS running, btw, during this pause
03:23.22systemdleteI can see it by opening tty1 as root
03:23.35tuxd3vls -l /var/run/slim.lock
03:23.42tuxd3vcheck if the lock file is there
03:23.52systemdleteyeppers
03:24.03systemdleteoh, hold on
03:24.08systemdleteslim had already come up
03:24.13systemdletelet me try that again
03:24.22gnarfacesystemdlete: when slim is hanging or right after it comes up, can you ssh into the VM to see if anything weird shows up /var/log/Xorg.0.log at that point or right before hand?
03:24.43systemdleteyeah, I've got tty1 open on root now
03:24.53systemdletesure, this reboot
03:25.17gnarfacesystemdlete: (sorry i didn't answer the earlier question; i was afk but i would have suggested xdm.  still, it looks like lightdm still allowed you to isolate the issue.  now i'm wondering if it's related to the graphical drivers somehow)
03:25.50systemdleteit is, per many entries from google
03:26.32gnarfaceinside the VM you should have a lot of control over that though
03:26.34systemdletethe lock is there, tuxd3v
03:26.57tuxd3vso its running..
03:27.00gnarfaceyou should be able to tell the VM to lie about the hardware, which should allow you any choice of drivers...
03:27.06*** join/#devuan D-HUND (~debdog@2a00:79c0:639:ad00:7a24:afff:fe8a:d04d)
03:27.09systemdletex is not running
03:27.39systemdletenow x is running
03:27.55systemdletebut slim has not appeared yet
03:28.35systemdletesuspended AIGLX clients for switch...
03:28.50systemdleteand slim is up
03:30.00tuxd3vmy file has a 'default_user        tuxd3v'
03:30.13tuxd3vthat you need to chamge acordingly with your user..
03:30.30systemdletewell, the issue seems to be that X is not running and slim is waiting for X to accept connections.
03:30.36tuxd3v<PROTECTED>
03:30.40systemdletemaybe how slim is launching X?
03:31.27gnarfacesystemdlete: out of curiosity, how much RAM are you allocating to this VM?  it's qemu-kvm?  or vbox?
03:31.51systemdletevbox 4G
03:32.07systemdleteand I also checked to see there is ample disk space, swap, etc
03:32.14gnarfacehmm. 4G should be fine
03:32.17systemdleteyeah
03:32.26systemdleteEspecially merely upon boot...
03:32.37gnarfacei was just thinking maybe if you were assigning it 8MB, Xorg could be hanging just to allocate swap for the video drivers
03:32.42systemdleteif a boot process ate that much ram, we'd really have issues
03:32.52systemdleteoh
03:32.55systemdletetrue
03:33.01gnarfaceyea you should be fine with as little as 64MB of ram though
03:33.10gnarfacewith most drivers anyway
03:33.17systemdletethe thing is though... let's remember that lightdm has no such issues I can tell
03:33.33gnarfaceyea, but not all graphical interfaces are created equally
03:33.38systemdleteThere were several hits when I googled it indicating issues with the drivers.
03:33.56systemdlete(I agree, which is why I'm tempted to dump slim at this point)
03:34.01gnarfaceif for example slim was compositing by default and lightdm was not, then there would be a massive difference in hardware and driver usage just at start
03:34.31gnarfacebut, that might mean easy fixes include switching video drivers too
03:34.36systemdleteI did NOT try to log in because I'd have to install the elogind ware and remove the policykit
03:34.36tuxd3vverify  /var/log/Xorg.0.log, for anny error
03:34.40systemdleteconsolekit I mean
03:35.54systemdletehttp://paste.debian.net/1117981/
03:36.25gnarface[   583.635] (EE) No surface to present from. ???????????????????????
03:36.46gnarfacenever seen this, but it looks like the source can only be a xorg.conf mistake or a bad driver
03:37.29gnarfacealso you said it's vbox but this Xorg log is clearly struggling with vmware drivers....
03:38.36systemdleteYeah, trying to recall...
03:38.55systemdleteI think for vbox users, they call in vmware drivers for some things.  But I am not clear on that.
03:39.09systemdletecheck this out:  https://forums.gentoo.org/viewtopic-p-7700690.html   See last comment
03:39.10gnarfacei recall that vmware had heavy graphical performance issues if you did not install the vmware guest additions package in the VM itself
03:39.35systemdletewell, I've had the vbox GAs installed there for some time now.
03:39.37gnarfacethere might have been permissions settings necessary on the host too
03:39.59*** join/#devuan ymasson (~ymasson@lfbn-bor-1-147-114.w90-50.abo.wanadoo.fr)
03:39.59*** join/#devuan parazyd (~parazyd@devuan/developer/parazyd)
03:40.15systemdletedk; dc.  I only deal with vbox.  If there's any use of vmware it is not anything I did intentionally.
03:40.15gnarfaceyea it could be solely a slim bug
03:40.30gnarfacebut i don't see any conclusive proof one way or another
03:40.31systemdleteseems like, yes.  Did you see that last comment on that page?
03:40.38systemdleteno, not conclusive
03:41.18gnarfacei've never heard of it being a thing that vbox requires vmware drivers... that seems wrong to me, but i have not used either so i don't know for sure
03:42.05gnarfaceif missing vmware drivers causes performance issues in vmware, and if it's loading vmware drivers and it's *not* vmware, that seems like it could be a source of performance issues as well...
03:42.48gnarfacethough honestly i wouldn't even expect it to work at that point, so maybe make double sure this is not actually a vmware vm.... you could be following the wrong debugging process entirely....
03:44.02systemdleteit's Vbox.  I am 100% sure of that.
03:44.41systemdletemore likely misconfiguration of X somehow.  But, look, this works.  I can log in to my desktop, even after the long pause from slim
03:45.04systemdletethings work; I haven't noticed any problems operationally.  I can run my desktop all my fave programs, etc
03:45.13systemdleteat least until yesterday when this started happening.
03:45.29tuxd3vIt could be on activating 3d aceleration.. a problem with the drivers..
03:45.31systemdleteI appreciate the suggestion, of course.
03:45.45systemdleteI have 3d enabled, along with vt-x and nested pages
03:45.50gnarfacewell misconfiguration of X can include loading the wrong drivers... can you think of any Xorg related changes to the config or drivers before the last time you restarted it, however long it was before that?
03:45.56tuxd3vgnarface, you have eagle eyes.. you catched the bug very fast..
03:46.19systemdletecaught what bug very fast?
03:46.26gnarfacetuxd3v: grep skills ;)
03:46.27tuxd3vyour bug
03:46.38systemdletewhat bug is it?
03:46.40tuxd3vgnarface, hehe
03:47.01tuxd3vits a bug related with xorg, or drivers of virtual box
03:47.11tuxd3vI saw a lot of entries about that..
03:47.12systemdletewell, perhaps.
03:47.17systemdleteOr it could be slim.
03:47.40tuxd3vsome even states that it could be when activating 3d aceleration..
03:47.44systemdleteMaybe it doesn't play well in all configurations of X.  I mean, it generates errors saying it cannot get X to stop
03:48.07gnarfacewell, it could be a slim bug, but it could also just be slim compositing by default that exposes a driver bug or a mesa bug....
03:48.08systemdletewell, if so, it is not a problem for lightdm!
03:48.22systemdletegnarface: +1 absolutely
03:48.54systemdletesomething in its environment does not like what it is trying to do, even though until just days ago, everything seemed to be fine
03:49.15systemdletegnarface: the only updates I recall would be a few days ago when I did that last update/upgrade
03:49.29systemdleteI think it included the -11 kernel, but I'm not 100% sure
03:49.48systemdletebut I don't remember this long pause until slim presented the login
03:50.21tuxd3vsystemdlete, truncate the log file and reboot
03:50.31gnarfacesystemdlete: well, the kernel change would have changed the video driver version at the very least.  that is a conceivable cause of regression, but a mesa update could easily have accompanied it
03:50.32tuxd3v> /var/log/Xorg.0.log
03:50.42tuxd3vthen paste the log again, if you can
03:50.49tuxd3vbecasue it will be clean
03:50.54tuxd3v<PROTECTED>
03:51.09tuxd3vI suspect that somehow it fallback to modesetting..
03:51.12systemdleteknow what else?  I tried nomodeset.  I recall reading something about new configurations that pass the resolution along to the kernel (KMS?) but it seems this does not always work for everyone, so they have to disable kernel modesetting and let X do it
03:51.16tuxd3vafter a minute or so..
03:52.05systemdleteAnd the first time, modeset did seem to clear up the problem, the same way that fsmithred's suggestion did (replacing that driver).  But after that, the same problem kept appearing.
03:52.37gnarfacethat part makes me wonder if changes to your VMs are even being saved
03:52.38systemdleteI even tried nouveaux.modeset=0 on a lark because someone suggested it on one of the sites
03:53.10systemdleteAre you referring to disk images?  or maybe the vbox config's?
03:53.36systemdleteIf so, then I should be able to make some changes to a few files, reboot and see if the changes are still there.
03:53.42gnarfacewell, i'm non-speficially referring to both
03:53.50gnarfacebut i primarily had the disk images themselves in mind
03:53.51systemdletehmmm.
03:54.01systemdletefile perms... hmmmmm
03:54.16gnarfacesince a reasonably common configuration is read-only images that spawn disposably to ram, and don't get saved
03:54.32gnarfacejust make sure you're not doing something like that every time you make a change that disappears the next time you reboot the VM
03:54.41systemdletefile perms look fine
03:55.05gnarfacei mean it would be obvious if they weren't being saved.  the timestamps on them wouldn't update when the VM shuts down
03:55.13systemdleteI very much doubt that.
03:55.21systemdletetimestamps look up to date
03:55.59systemdletevirtual disk images have current time on them
03:56.47systemdletemeta data can only be changed when VM is quiescent (mostly, except for a few fields ones I rarely change)
03:57.25systemdleteThere was one issue, though, that I am still pursuing  but on my testbox
03:58.45systemdleteListen to this, gnarface:  A few days ago, I went to open a url I received in an email -- from a very reputable source, though I cannot say the same for their IT work, I simply dk -- and it began loading, the display flashed (when in the full screen mode) and the web page froze, the time in the VM froze, and I could not even break out of it.
03:59.08systemdleteI could ssh in from another system, so the host was actually OK (I think).
03:59.23systemdleteI repeated that a couple times before I got fed up of rebooting the host.
03:59.57systemdleteI am going to see if I can replicate that scenario in a VM on my testbox (different physical machine)
04:00.26systemdletebtw, when I open the same link in a browser on the host, the page hung, but no impact on the rest of the system.
04:00.41gnarfacehmmmmm.... does sound suspicious
04:00.44systemdleteyeah.
04:01.07tuxd3vare you using nouveau driver ?
04:01.38gnarfacecross-platform graphical vulnerabilities have been identified in the nvidia official driver before.  it's a risk for anything using direct rendering though
04:01.39systemdleteIf anything, I'm more suspicious of that incident than the current one.  The current one could be another manifestation of the same issue, but it's hardly deadly like the complete lockup one.
04:02.04systemdletethis is an AMD system.  Not sure on the hw specs atm
04:02.14systemdleteIts' an ASUS board
04:02.53systemdleteM5A78L_M_USB3
04:03.02systemdleteI'm using the onboard video
04:03.30tuxd3vyou have amdgpu enabled or you are using another driver?
04:03.42systemdleteIf I can't replicate that scenario on the other PC, maybe I'll install a spare video card, though it's kind of old
04:04.01systemdletecoach me on that, and I'll tell you...
04:04.09systemdlete(I'm no hw guru)
04:04.50systemdletegnarface:  Sorry I didn't investigate the HW/nvidia side first.
04:05.19systemdleteJust didn't think of it.  I was thinking of it all as VM and software.  I don't typically look for HW problems.
04:05.32systemdlete(though I've certainly had some over the many years)
04:06.20tuxd3vxserver-xorg-video-radeon
04:06.33tuxd3vthis is what you should be using.. I mean the package
04:07.07tuxd3vlspci|grep -i AMD
04:07.22systemdleteit is def installed
04:07.32tuxd3v'Integrated ATI Radeon™ HD 3000 GPU'
04:08.29tuxd3vI don't know if it is supported by amdgpu, I believe that you need to be with radeon driver..
04:09.50systemdleteit's installed, but does not show in lspci:  http://paste.debian.net/1117984/
04:10.53systemdletethis board has been around a number of years.  My impression is that it is fairly popular.  So I'd think, by now, there would be well-established support for its hardware configuration.
04:11.03systemdletebut I could be wrong about it.
04:14.14tuxd3vI mean run it in the host os
04:14.16tuxd3v:)
04:14.53tuxd3vyou are in vmware?
04:14.54systemdleteoh
04:14.55tuxd3v00:02.0 VGA compatible controller: VMware SVGA II Adapter
04:14.58systemdleteno virtualbox
04:15.45systemdlete01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS780L [Radeon 3000]
04:15.51systemdlete(from host)
04:16.17tuxd3vyeah
04:16.34tuxd3vI don know if it has support for amdgpu
04:16.47tuxd3vdo a 'lsmod' in the host
04:16.54systemdletegnarface, tuxd3v:  I recall reading a post about how some people in linux do not like the quality of vbox's video drivers.  That might be why they configure vbox linux systems with the vmware drivers
04:17.29systemdletelsmod |grep gpu   shows nada
04:18.14tuxd3vlsmod|grep -Ei "amd|radeon" --color
04:18.53systemdleteamdkfd, radeon, kvm_amd... yes they are there
04:19.27systemdletehttp://paste.debian.net/1117985/
04:21.07tuxd3vyup
04:21.31tuxd3vyou are using the admkfd, that uses the userspace radeon driver
04:21.33systemdletemoreover, see:  https://forums.virtualbox.org/viewtopic.php?t=91874&start=15
04:21.37tuxd3vnot the amdgpu one..
04:21.57systemdlete" if i purge xserver-xorg-video-vmware, my debian sid vm can't start x, because modesetting-ddx does not work (error: failed to add fb -22)."
04:22.11systemdleteso it sounds like that vmware driver is essential
04:22.35systemdletes/is/might be/
04:23.51*** join/#devuan pekman (~pekman@unaffiliated/pekman)
04:26.01systemdletenow I've got mouse hesitation... on my host.  Probably because of the cheap kvm switch.
04:26.13systemdleteI've had periodic issues with that POS too.
04:27.55*** join/#devuan Inepu (~Mithrandi@host67-78-static.1-79-b.business.telecomitalia.it)
04:33.36systemdletetuxd3v: So what should I do?
04:35.59systemdleteor do I need to do anything?
04:36.00tuxd3vdon't know, but one thing that I would try, would be to disable 3d acceleration in the vm
04:36.06tuxd3vamd see if that solves
04:36.14systemdleteok
04:36.18tuxd3valso check the Xorg logs in the host
04:36.18systemdletegimme a moment
04:36.24tuxd3vto see if my config is ok
04:42.43systemdletedisabling 3d did nothing to change the problem
04:42.55systemdletestill hangs upon boot, sorry.
04:43.03*** join/#devuan DonkeyHotei (tiL6@april-fools/2014/runnerup/danielg4)
04:44.28systemdletelast 1000 lines of host xorg log:  http://paste.debian.net/1117989/
04:44.41systemdlete(seems to be a limit)
04:47.12gnarfacedoes it dump those repeated modeline blocks when a VM starts up?
04:47.27systemdleteon the host?
04:48.01gnarfaceyea, that last paste was from the host, right?
04:48.16systemdleteyes
04:48.49gnarfaceit's weird that it's dumping all the detected modelines a half dozen times in a row.  does it dump once for each VM you start, or is it actually dumping that block of text 6x times (or whatever it is) every time you start just 1 VM?
04:49.15systemdletethere is one way to find out... hold on
04:50.31tuxd3vyeah too many modelines several times
04:50.37gnarfacei'm hypothesizing the delay being related to some sort of auto-detect loop now
04:50.52gnarfacei didn't figure that would be the case for a VM but maybe in fullscreen mode ...
04:50.58gnarfacei dunno
04:51.17gnarfaceseems suspicious though in light of the other misbehaviors
04:51.32tuxd3vgnarface, yes it could be
04:52.27gnarfaceit could be nothing too.  i'm not using any radeon stuff here.
04:54.14systemdleteok, it looks like those logs were because of yours truly resetting my kvm switch.
04:54.36systemdletethe problem there, btw, was a weak battery.  I replaced it and seems like things are good again.
04:54.39systemdlete(for now)
04:55.12systemdleteeach time I reset or change to a different pc, I was causing that flood of messages in the x.org log
04:55.29systemdleteinterestingly, though, not one single message upon firing up or shutting down a VM!
04:55.49systemdleteEven when the VM changes its video, there are no new messages on the host in the log
04:56.20systemdletethat could have to do with the verbosity the x log is set to
04:57.15systemdletewell, actually, as regards fullscreen mode, I've been doing all these tests for you in windowed mode, not full screen.
04:58.46systemdleteFull screen mode: Same thing.
05:06.19systemdleteHey, I just had this nifty idea.
05:06.46systemdleteI will stop slim, then launch it in strace, capturing the output for a few minutes.
05:06.49systemdlete:D
05:06.56systemdletesee what it is "Thinking"
05:15.30golinuxsystemdlete: Are you still slimming around?
05:15.42systemdletetrying to, yeah...
05:16.00systemdleteor did you mean "sliming" around?  lol
05:16.15golinuxThat's a real marathon . . .
05:16.32golinuxI've never had an issue with slim but some folks do.
05:16.56golinuxActually I thought of slumming
05:17.21golinuxSo many OT possibilities.
05:17.25systemdletewell, I went to the doc today.  I am hitting 180 lbs. that's enough
05:17.44systemdleteyeah, keep it up golinux and get your self kicked by the mods!
05:17.50systemdlete:p
05:17.55golinuxLOL!
05:18.08systemdleteyou are a primary offender that way around here...
05:18.33systemdletethough I'm probably right behind you... like #2 or 3
05:21.12systemdleteright now, I'm trying to strace the damned thing.
05:34.46systemdleteHmmm.  Looks like slim is epoll_wait'ing on /proc/filesystems, but I'm not sure if I'm seeing this right.
05:36.52*** join/#devuan DocScrutinizer05 (~saturn@openmoko/engineers/joerg)
05:37.18systemdletenope.  Its waiting on slim.lock
05:45.39systemdletethe last thing that process opens looks like /proc/filesystems, then it does that poll
05:45.48systemdlete(I think, still looking at this)
06:03.40systemdleteOne thing is for certain:  slim is waiting (epoll'ing) for some time, waiting on one or more file descriptors.
06:05.16systemdletebbl.  Food!
06:06.33*** join/#devuan HumanG33k (~HumanG33k@62.147.242.8)
06:15.17*** join/#devuan TwistedFate (~quassel@unaffiliated/twistedfate)
06:15.38TwistedFatewhat is devuan using for config file management?
06:16.14TwistedFatei removed and purged a package, now the config files will not install when i re-install it..
06:16.16gnarfacesystemdlete: maybe this is a simple issue with a default setting in /etc/security/limits.conf being starved out by the VMs... i used to have to raise nofile for tf2 servers...
06:20.28systemdleteno files is 1024.  I *think* that's plenty...
06:21.01systemdleteI'm now trying to ascertain WHICH files epoll_wait is waiting on.
06:21.14systemdleteprob easier to examine the source at this point...
06:25.50TwistedFateguys, how do i force apt or dpkg to reinstall the package configuration as well?
06:26.22gnarfaceTwistedFate: it's supposed to do that normally ...
06:26.25TwistedFatei removed a package, purged it and deleted the configs directory, now when i reinstall it, it doesn't install configs too :/
06:26.39gnarfacesystemdlete: the new default is 8192 i think (what i had to raise it to for the TF2 server)
06:27.06gnarfaceTwistedFate: were they in a separate package?
06:27.53systemdletewhen you say "the new default is..." can you explain that please?  thanks
06:27.58TwistedFategnarface: i'm unsure, i installled nginx and it gave me /etc/nginx and bunch of other directories and configs in that directory
06:28.08TwistedFatenow they're gone
06:28.37*** join/#devuan chomwitt (~chomwitt@2a02:587:dc42:5000:f5d3:5385:cc1a:2111)
06:28.49gnarfacesystemdlete: well it's not that new of a default, but you said it was 1024 which i recall having not been the default for many years now
06:29.14gnarfaceTwistedFate: you sure you didn't manually copy them from /usr/share/doc/nginx?
06:29.54TwistedFategnarface: yes, i'm sure, i just manually deleted them
06:31.48systemdletegnarface:  So, did I miss an update?  Or just some brain cells?
06:32.10systemdletereally needs to start smoking...
06:32.59gnarfacesystemdlete: well probably what happened is you kept your old config file and didn't merge any changes during an update (expected behavior) or else maybe your kernel is super old... but you said this was ascii, right?  so it shouldn't be that old
06:33.17systemdlete4.9.0-11, yes sir
06:33.54systemdleteare you telling me yours is set to 4192, but I somehow missed that change?
06:34.02systemdlete8192
06:34.33gnarfacewell the first part i'm sure of.  the second part ... only 80-90%
06:35.07gnarfacei know for sure i had to increase it for the TF2 server.  i think i also had to increase it for something in wine at one point too.  but i'm less sure that i've heard the default was changed to that later.
06:35.29gnarfaceit is something easy enough to test though
06:36.09systemdleteI'm having some wine myself right now
06:36.31systemdletesure, I could.  But I think I want to try the getting rid of all things ~bpo first
06:36.31gnarfaceit looks like that config file is part of libpam-modules, maybe verify that you have the ascii version of that just as a sanity check
06:41.17*** join/#devuan rdav (~rdav@245.184-26-211.sta.nsw.iprimus.net.au)
06:45.54TwistedFatehow can i check apt/apt-get/aptitude commands history and output?
06:54.37systemdletegnarface:  Didn't you say that ~bpo packages are from backports?
06:55.09systemdleteI've still got them even though I've cleared the packages cache (archive in /var) and commented them out in sources
06:55.57gnarfacesystemdlete: i did say that, but then shortly afterwards fsmithred said something about seeing them in ascii-security for some reason...
06:56.19gnarfacesystemdlete: which ones are you seeing still, specifically?
06:56.27systemdletepolicykit
06:56.33systemdletethat's ok
06:56.40gnarfacehmmm, that's a package they forked so maybe that is on purpose.  any others?
06:57.13systemdletewell, I meant all the policy-kit related stuff
06:57.18gnarfaceTwistedFate: check in /var/log/apt/
06:58.29gnarfaceTwistedFate: aptitude may be separate from that
07:09.31*** join/#devuan Jjp137 (~Jjp137@cpe-75-83-16-81.socal.res.rr.com)
07:10.55*** join/#devuan rdav__ (~rdav@245.184-26-211.sta.nsw.iprimus.net.au)
07:11.16*** join/#devuan Uberius (~uberius@gateway/tor-sasl/uberius)
07:12.21TwistedFate'apt-get remove nginx && apt-get purge nginx' shows in my 'history |grep purge' but it's not showing in /var/log/apt/history.log for some reason..
07:12.36gnarfacesystemdlete: there's some way to check if it's hitting the limits.conf limit, but i forget exactly how... you might need to enable some debugging in the logs
07:13.26gnarfaceTwistedFate: as i understand it, you only purge installed packages.... so it would have probably just ignored the second call or errored it out after succeeding at a regular uninstall of nginx.
07:22.03*** join/#devuan unixman_home (~unixman2@1-209-137-216.mtaonline.net)
07:22.03*** join/#devuan unixman_home (~unixman2@unaffiliated/eracc)
07:23.31Jjp137no you can still purge packages if they left configuration files behind
07:24.08Jjp137although purge also does remove so you don't need to do both commands
07:42.38*** join/#devuan FatPhil (~luser@6-251-190-90.dyn.estpak.ee)
07:43.08*** join/#devuan Pali (~pali@Maemo/community/contributor/Pali)
07:56.06*** join/#devuan arnoldoree (~arnoldore@ranoldoree.plus.com)
07:56.18*** join/#devuan pav5088 (~pav5088@175.39.118.119)
07:57.31*** join/#devuan e3d3 (~e3d3@ppp-124-122-133-197.revip2.asianet.co.th)
08:08.06TwistedFatewelp
08:08.29TwistedFateturns out it didn't want to reinstall the configs because of an additional file/package that needed to be purged also
08:19.06*** join/#devuan morruth (~quassel@77.244.126.31)
08:20.05*** part/#devuan e3d3 (~e3d3@ppp-124-122-133-197.revip2.asianet.co.th)
08:20.27*** join/#devuan knidos (~knidos@85.98.23.152)
08:22.09*** join/#devuan r3boot (~r3boot@2a02:58:5:4a14::20)
08:27.35*** join/#devuan sardonico (ale@freeshell.de)
08:30.03*** join/#devuan rdav (~rdav@122-150-193-110.sta.dodo.net.au)
08:59.25*** part/#devuan TwistedFate (~quassel@unaffiliated/twistedfate)
09:01.45*** join/#devuan rdav (~rdav@122.150.193.110)
09:04.15*** join/#devuan morruth (~quassel@77.244.126.31)
09:08.04*** join/#devuan knidos (~knidos@85.98.23.152)
09:13.53*** join/#devuan cocoadaemon (~foo@home.crommer.fr)
09:15.29*** join/#devuan knidos (~knidos@85.98.23.152)
09:21.15systemdletegnarface:  Is this pursuit -- to determine the cause of the long hang in slim -- a worthy goal for the furtherment of science and human knowledge?  Or could I just install lightdm and be done with it?
09:23.09gnarfacesystemdlete: oh i thought you had some specific reason to want slim.  like i said, i personally would have long ago given up on graphical login managers entirely for something like this, or switched to something else
09:23.24gnarfacesystemdlete: if you don't care, what you should do is file a bug report and move on
09:24.02systemdleteMany already have.  Or at least, this is a well-known issue, per google.  But, yes, I suppose I should do that favor and file it.
09:24.21systemdleteBut where?  Devuan? Debian? X.org? slim?
09:24.57gnarfacewell i'd first check to see if one is already filed with debian
09:25.02systemdleteAnd given that I don't know when the issue arose precisely... maybe I would just be adding more clutter to somebody's bug list.
09:25.09systemdletedebian. OK
09:25.20r3bootsystemdlete: did you check ~/.xsession-error to see if there's something that's blocking the startup?
09:25.27systemdleteoooh!
09:25.34systemdletenice one. NO, I hadn't.
09:26.05systemdletebut, then again, would this show up there?   This is in the display manager, so I would think .xsession-error would not even have been opened yet?
09:26.33systemdleteWe've been looking at the X org log files in /var/log
09:26.58r3bootI am missing backlog, so I might have missed something; Avid slim user here (on arch tho)
09:27.05systemdletenp
09:27.33gnarfacer3boot: he's using it in a VM and it delays startup significantly compared to lightdm
09:27.34systemdleteI think DM's, generally, are user-agnostic until the point a login is successful.
09:27.53gnarfacer3boot: (the short version)
09:28.02systemdletegnarface:  (thank you)
09:28.38r3bootgnarface: check, thnx
09:31.23systemdleteof course, I'll also have to replace the policyshit packages with elogind
09:42.13systemdletewhy does the screen flash just as the lightdm login appears?  I noticed that with slim also.
10:02.59*** join/#devuan user844842 (user@gateway/vpn/mullvad/user844842)
10:26.54*** join/#devuan Uberius (~uberius@gateway/tor-sasl/uberius)
10:48.58*** join/#devuan cosurgi (~cosurgi@wilab32.bl.pg.gda.pl)
10:52.15systemdleteanother question:  fwanalog ran for the first time in the same VM as we were looking at w/r/t slim.  However, I don't remember actually installing it, and neither does dpkg.* or any of the files in /var/log/apt.
10:52.43systemdleteI DO recall *considering* it for helping to track down some mysterious packets.
10:53.15gnarfacehmm, not sure about that
10:53.43systemdleteI *may* indeed have installed it.  But I would think it would be recorded somewhere.
10:54.06gnarfacewhat about /var/log/dpkg.log ?
10:54.17systemdletesee ^^^
10:54.32systemdleteno, nothing there either
10:54.40gnarfaceinteresting
10:54.58systemdleteI did:  zgrep fwanalog /var/log/dpkg.* /var/log/apt/*
10:55.52gnarfaceis there a /var/log/aptitude?
10:55.58systemdletehmmm.
10:56.17systemdleteno
10:57.25gnarfacedoes it show up in dpkg -l ?
10:57.46systemdleteyes
10:58.06gnarfacealready there with the base system maybe?
10:58.44systemdleteno way.  I know that for a fact.  It was not there previously (yesterday).  If it had been I'd been getting reports daily.  This is the first time.
10:59.07systemdleteLike I said, I was considering installing it to see if it could help me get more info on some packets being logged.
10:59.09gnarfaceinteresting
10:59.28systemdleteBut I don't recall if I actually installed it or not last night -- I was having so much fun with these other issues.
11:02.28systemdleteomg.
11:02.37*** join/#devuan parazyd (~parazyd@devuan/developer/parazyd)
11:02.42systemdleteI just re-installed gufw and it installs the policykit crap again
11:02.54systemdleteso now I've got elogind AND some policykit stuff also.
11:03.36systemdleteThis is just too much fun.
11:07.55systemdleteSystem (VM) is still bootable, login-able, desktop-able
11:08.10systemdleteSo I guess it's OK, even with both.
11:08.50*** join/#devuan gmaster (~gmaster@91.149.182.144)
11:10.02systemdleteseriously, I am really ready to just rebuild this whole mess from scratch and restore my user files
11:10.29systemdleteI realize that's the sleazy way out of this, but these package dependencies are driving me batty
11:11.21systemdletegufw depends on policykit prob because it needs to authenticate the user running it.
11:11.52systemdlete(but it must be welded on to the method this way?)
11:13.02systemdleteenough for one night.  bbl -- thanks to all who helped.
11:13.08gnarfaceapparently, but systemd could have something to do with it, i don't know.
11:13.28systemdletethx, gnarface.  Time for sleep now.
11:13.32gnarfacepeace
11:13.36systemdletesame
11:30.38*** join/#devuan cd (~cd@unaffiliated/cd)
11:42.05*** join/#devuan KnoP (~KnoP@p57B19DCA.dip0.t-ipconnect.de)
11:42.44*** join/#devuan Jjp137 (~Jjp137@cpe-75-83-16-81.socal.res.rr.com)
11:55.11*** join/#devuan knidos (~knidos@85.98.23.152)
12:11.03*** join/#devuan knidos (~knidos@85.98.23.152)
12:12.11*** join/#devuan macamic (macamic@gateway/vpn/privateinternetaccess/macamic)
12:19.45*** join/#devuan macamic (macamic@gateway/vpn/privateinternetaccess/macamic)
12:20.13*** join/#devuan macamic (macamic@gateway/vpn/privateinternetaccess/macamic)
12:33.40*** join/#devuan xrogaan (~xrogaan@unaffiliated/xrogaan)
12:43.41*** join/#devuan user844842 (user@gateway/vpn/mullvad/user844842)
12:56.28*** join/#devuan zeden (~user@unaffiliated/zeden)
13:02.39*** join/#devuan knidos (~knidos@85.98.23.152)
13:07.57*** join/#devuan bpmedley (~bpm@2601:246:8201:8e0:71bf:b4cd:137d:2da8)
13:08.42*** join/#devuan poontangmessiah (~poontangm@unaffiliated/poontangmessiah)
13:30.57*** join/#devuan cocoadaemon (~foo@x53.octopuce.fr)
13:34.27*** join/#devuan antenagora (~antenagor@147.162.137.245)
13:59.54*** join/#devuan abefcd (8168f497@129.104.244.151)
14:00.46*** join/#devuan attos (~nix@x4db64a24.dyn.telefonica.de)
14:02.15*** join/#devuan knidos (~knidos@85.98.23.152)
14:26.24*** join/#devuan g4570n (~g4570n@unaffiliated/g4570n)
14:34.42*** join/#devuan targz (~Thunderbi@unaffiliated/targz)
14:35.26*** join/#devuan james1138 (47de852a@71-222-133-42.albq.qwest.net)
14:38.19*** join/#devuan knidos (~knidos@85.98.23.152)
14:46.11*** join/#devuan Shentino (~shentino@unaffiliated/shentino)
15:01.19*** join/#devuan knidos (~knidos@85.98.23.152)
15:01.58*** join/#devuan proteus-guy (~proteus-l@cm-58-10-208-146.revip7.asianet.co.th)
15:09.56*** join/#devuan furrywolf (~furrywolf@172.58.92.23)
15:11.53*** join/#devuan yeti (~username@p57BDF493.dip0.t-ipconnect.de)
15:12.41*** join/#devuan rdav (~rdav@110.193.150.122.sta.dodo.net.au)
15:16.59*** join/#devuan knidos (~knidos@85.98.23.152)
15:25.36*** join/#devuan Akuli (~akuli@mobile-access-5d6a29-212.dhcp.inet.fi)
15:29.44*** join/#devuan james1138 (47de852a@71-222-133-42.albq.qwest.net)
15:32.11*** join/#devuan amarsh04 (~amarsh04@118.211.39.107)
15:40.07*** join/#devuan IoFran (~Thunderbi@189.237.240.124)
15:41.53*** join/#devuan poontangmessiah (~poontangm@unaffiliated/poontangmessiah)
16:07.26*** join/#devuan poontangmessiah_ (~poontangm@unaffiliated/poontangmessiah)
16:14.26*** join/#devuan ymasson (~ymasson@lfbn-bor-1-147-114.w90-50.abo.wanadoo.fr)
16:19.14*** join/#devuan IoFran (~Thunderbi@189.237.240.124)
16:22.08*** join/#devuan omnio (~omnio@86.121.165.118)
16:27.31*** join/#devuan g4570n (~g4570n@unaffiliated/g4570n)
16:31.01*** join/#devuan Pali (~pali@Maemo/community/contributor/Pali)
16:42.52*** join/#devuan IoFran (~Thunderbi@189.237.240.124)
16:58.16*** join/#devuan IoFran2 (~Thunderbi@200.68.140.9)
17:01.48*** join/#devuan jathan (~jathan@200.39.241.171)
17:01.54*** join/#devuan gmaster (~gmaster@91.149.182.12)
17:25.12*** join/#devuan Uberius (~uberius@gateway/tor-sasl/uberius)
17:34.29*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
17:40.01*** join/#devuan HumanG33k (~HumanG33k@62.147.242.8)
17:40.03*** join/#devuan maggotbrain (~maggotbra@c-73-254-248-250.hsd1.wa.comcast.net)
17:45.31*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
17:54.39*** join/#devuan puria (~puria@net-188-218-183-123.cust.vodafonedsl.it)
17:57.05*** join/#devuan IoFran (~Thunderbi@189.237.240.124)
18:07.23*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
18:08.37*** join/#devuan mith_ (~Mithrandi@host67-78-static.1-79-b.business.telecomitalia.it)
18:08.45*** join/#devuan sunshavi (~user@190.239.244.220)
18:18.36*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
18:21.01*** join/#devuan rsx (~rsx@ppp-188-174-146-106.dynamic.mnet-online.de)
18:24.02*** join/#devuan shibboleth (~shibbolet@gateway/tor-sasl/shibboleth)
18:26.29*** join/#devuan fling (~fling@fsf/member/fling)
18:30.13*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
18:33.11*** join/#devuan Uberius (~uberius@gateway/tor-sasl/uberius)
18:40.38*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
18:41.01*** join/#devuan st3ma (~st3ma@213.178.26.60)
19:00.32*** join/#devuan IoFran (~Thunderbi@189.237.240.124)
19:10.53*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
19:17.24*** join/#devuan AntoFox (~AntoFox@mob-5-92-168-11.net.vodafone.it)
19:27.02*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
19:39.35*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
20:06.43*** join/#devuan Acacia (~Acacia@unaffiliated/acacia)
20:11.55*** join/#devuan IoFran (~Thunderbi@189.237.240.124)
20:22.41*** join/#devuan IoFran (~Thunderbi@189.237.240.124)
20:28.44*** join/#devuan zeden (~user@unaffiliated/zeden)
20:33.18*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
20:44.59*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
20:55.55dbristowSooo close to finishing downloading the 2.1 torrent.  I think I am still lacking about 10M of the files.
20:56.03dbristow99.9% done
20:56.38dbristow23.10G out of 23.11G
20:56.38*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
21:01.23*** join/#devuan poontangmessiah (~poontangm@unaffiliated/poontangmessiah)
21:09.49*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
21:13.01*** join/#devuan retak (~ite@2a01:c22:d451:6100:f2de:f1ff:feb2:f9aa)
21:21.23*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
21:26.59*** join/#devuan Centurion_Dan (~Thunderbi@devuan/developer/centuriondan)
21:34.11*** join/#devuan sunshavi (~user@190.239.244.220)
21:34.18*** join/#devuan IoFran (~Thunderbi@189.237.240.124)
21:47.13*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
21:58.23*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
22:09.09*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
22:23.24*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
22:24.43*** join/#devuan xe-non (uid379608@gateway/web/irccloud.com/x-dbkfiaffvjjysbfs)
22:26.00*** join/#devuan sardonico (ale@freeshell.de)
22:34.44*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
22:45.24*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
23:04.09*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
23:14.44*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
23:25.30*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
23:33.03*** join/#devuan petzi (~petzi@p578b3438.dip0.t-ipconnect.de)
23:37.08dbristowYay, it's finally seeding.
23:39.33*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)
23:50.24*** join/#devuan IoFran2 (~Thunderbi@189.237.240.124)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.