roundduckman | Ok, I've been stuck for the last few days on trying to install Nvidia drivers for a mobile 1050 Ti. Gnarface helped a bit, but I do need some perspective from one who recently used Nvidia on Devuan on a laptop. I need help, I'm stuck and I end up having to load a new backup after each screw up that ends up in dependency hell. | 00:07 |
---|---|---|
yellyfish | hey. i am kinda confused. i tried to install libsdl2-dev but it depends on libudev-dev. I have libeudev1 installed so i tried to also install the dev package for eudev but it need an older version? | 00:35 |
yellyfish | it says it depends on libeudev1( = 3.2.2-13) but i have 3.2.5-1 | 00:36 |
yellyfish | how do i downgrade and is it wierd that i need to? or am i doing something wrong? | 00:39 |
debdog | mayhap installing libudev-dev solves that. it's a transitional package so it should not actually change anything regarding e/udev | 00:55 |
debdog | if not, what is the exact error message when attempting to install libsdl2-dev? | 00:57 |
yellyfish | dependency conflict | 01:01 |
yellyfish | The following packages have unmet dependencies: | 01:01 |
yellyfish | libsdl2-dev : Depends: libudev-dev | 01:01 |
yellyfish | E: Unable to correct problems, you have held broken packages. | 01:01 |
debdog | you have backports enabled? | 01:08 |
yellyfish | yeah | 01:08 |
debdog | oh | 01:08 |
debdog | sorry, i am out | 01:08 |
debdog | don't have an Ascii vm atm and I don't want to mess with my production system :/ | 01:09 |
yellyfish | no problem :) | 01:10 |
yellyfish | i am tinkering meanwhile to make it work | 01:10 |
gnarface | DeeEff: in order to preserve expected behavior from lets just call it "Debian Classic" a number of the limitations of the system are also inherited. downgrades not being a supported action is one of those, unfortunately. nothing is tested for downgrading. | 01:16 |
gnarface | yellyfish: yea there's some tangle there you have to force out manually. for some people, just deleting the /etc/init.d/udev script worked, but before i heard about that i had to fix it by uninstalling the running kernel out from underneath the system briefly | 01:17 |
DeeEff | gnarface: I think I've noticed this. Fortunately though, it can fix some issues. I had a dependency graph problem fro my initial ceres install (from back when devuan was barely even a mailing list topic) that persisted to present day. Downgrading actually fixed a _ton_ of issues and allowed me to use eudev and elogind instead of the systemd variants. | 01:17 |
DeeEff | I managed to solve my issue by the way | 01:17 |
gnarface | that roundduckman guy gets nearly there and panics and hoses it every time. if filipdevuan comes back and those two are both here at the same time, maybe try to get them to talk. they have similar optimus hardware | 01:18 |
DeeEff | There's a (silent) kernel panic when you try to start X with Nvidia driver 390.67 with kernel 4.16.0-2 | 01:18 |
DeeEff | Is a 650ti Optimus? | 01:19 |
gnarface | sorry, no that wasn't to you, DeeEff, that was more just to the channel in general | 01:19 |
DeeEff | I think it's partly that Nvidia hasn't updated their driver to support 4.16 yet, since the panic appears to come from the module | 01:19 |
yellyfish | so delete udev script and restart? | 01:20 |
gnarface | DeeEff: they have similar hardware to each other - your situation is different | 01:20 |
DeeEff | It seemed to work with 4.16.0-1, but that may have just been a fluke. A new ABI would be enough to kill it. | 01:20 |
gnarface | yellyfish: you shouldn't even have to restart, but it didn't work for everyone. some people had to uninstall all dependencies of udev before eudev would go in | 01:21 |
yellyfish | then just logout/login? | 01:21 |
gnarface | not necessary either | 01:21 |
gnarface | but you probably want to test the reboot process anyway to make sure none of the init scripts got hosed while you were doing this | 01:22 |
yellyfish | k. be right back | 01:22 |
DeeEff | yellyfish: | 01:22 |
DeeEff | Are you on ascii? | 01:22 |
yellyfish | ye | 01:23 |
DeeEff | Huh, weird. I had similar Nvidia problems recently (see above). I had about five issues in total but the last one burnt about 3 full days for me. | 01:24 |
gnarface | DeeEff: it is possible that if you're using nvidia packages from ceres, they might not work well/stably with the ascii kernel - you'd want to make sure that you got the nvidia driver version and the kernel version from the same place | 01:25 |
DeeEff | Funny that he has issues with udev, ascii seems to use eudev properly and packages it to make things easy enough to switch from systemd-udevd. | 01:25 |
gnarface | DeeEff: so if you're using the ceres nvidia driver version, the kernel needs to be from ceres as well. if you're using the one from ascii-backports, then the kernel needs to be from ascii-backports as well. they're only tested in pairs like that upstream, so any other combinations may have unexpected behavior and instability. make sense? | 01:26 |
DeeEff | gnarface: its the opposite I think. Ceres uses the latest kernel, and the changes to 4.16 are all the final mitigation to spectre and meltdown. I think the ABI change that those changes necessitate broke the driver | 01:26 |
DeeEff | The latest Nvidia package has backwards compatible ABI interfaces and will work as far back as 3.6 IIRC | 01:27 |
DeeEff | The problem is the kernel doesn't work that way just for Nvidia specially. | 01:27 |
gnarface | well on ceres stuff is known to be frequently broken without notice for weeks at a time. Nvidia drivers are particularly misbehaved in this way. | 01:27 |
gnarface | if you're just trying to get recent enough nvidia drivers to play steam, it would have been safer to try backports than ceres | 01:28 |
DeeEff | Yeah, I mean, I don't blame the devuan project for ceres being unstable or broken | 01:29 |
DeeEff | But to say it's just broken and unusable would be wrong. I've been using ceres since the beginning and this has been my first major issue. | 01:30 |
DeeEff | Happy to help test that claim if it's needed though :) | 01:30 |
gnarface | i've been using sid longer than ceres, and i can confirm nvidia has single-handedly ruined my day with their sloppy package management dozens of times | 01:30 |
gnarface | right now i'm running a custom kernel on my ceres box though so i can't report on compatibility with the stock one | 01:31 |
gnarface | for the last several versions though i've had a mystery source of some sort of runaway memory leak | 01:31 |
gnarface | it doesn't happen all the time but some combination of firefox and other opengl programs seems to trigger it | 01:32 |
gnarface | what i would have recommended in your situation i guess would have been to just stay on ceres but downgrade the *nvidia drivers* temporarily | 01:33 |
gnarface | sometimes if you're quick you can do it before they pull the old ones out of the repo | 01:33 |
gnarface | otherwise you have to resort to digging through the debian snapshots repo | 01:33 |
gnarface | i don't think there's devuan snapshots yet but i could be wrong | 01:33 |
DeeEff | Huh, well I suppose that's a reasonable reaction | 01:37 |
DeeEff | I will say though, the sid devs are also the same devs who decided they wanted systemd sooooooo | 01:38 |
DeeEff | :) | 01:38 |
DeeEff | All in all I've been pretty happy and I'm glad that my issues are solved now just by downgrading my kernel. | 01:38 |
yellyfish | i don't think much changed. | 01:44 |
yellyfish | i tried downgrading libeudev1 but it wants to uninstall lots of xorg packages | 01:45 |
gnarface | yellyfish: yea getting the switchover from udev to eudev for me did require uninstalling a lot of packages, but that's the part that's supposed to work if you just delete the /etc/init.d/udev script instead, after stopping udev. worth a try anyway. (if you go the "remove everything" route though, make sure after it's done you put the kernel back in before you reboot) | 01:47 |
gnarface | the process it *wants* to follow involves uninstalling the running kernel right out from underneath yourself | 01:48 |
gnarface | which is risky, but should work actually if you don't lose power at an opportune time | 01:48 |
gnarface | inopportune time, i mean | 01:48 |
yellyfish | how do i save all these packages on a file to reinstall after? | 01:50 |
yellyfish | i mean just the names | 01:50 |
terryc | Q: my "eth0" has gone missing. defined in /e/n/interfaces. ?? after migrate to Devuan-ascii. Stumped | 01:50 |
gnarface | terryc: you mean it's no longer in the interfaces file, or just doesn't show up despite being in it? | 01:51 |
gnarface | yellyfish: you could get a list of the installed packges with `dpkg -l` and just redirect that to a file | 01:52 |
gnarface | or you could copy&paste the terminal output from the package conflict message in there | 01:52 |
gnarface | if those are packages that are being removed as dependencies of udev i expect most will come back automatically as dependencies of eudev though | 01:53 |
gnarface | yellyfish: do you need hints like this? `dpkg -l > installed_package_list.txt 2>&1` | 01:57 |
terryc | The migration borked static networking and invoke dhcp using eth1. removing dhcp leaves no networking. doing 'ifup eth0'='what eth0' ifquery reads interfaces okay. brain fade to making static work | 01:57 |
fsr | apt-get blah blah } | 01:58 |
fsr | shit | 01:58 |
fsr | apt-get blah blah | tee myfile | 01:59 |
fsr | I hate this keyboard | 01:59 |
gnarface | terryc: sorry gotta go for a bit but that info should be the same as from debian (also you could just read the man page: "man interfaces") | 02:03 |
yellyfish | i shouldn't worry about autoremoved packages right? those are dependencies not required anymore, right? | 02:03 |
fsr | yellyfish, generally, yes. | 02:04 |
fsr | terryc, what does ifconfig show? | 02:04 |
fsr | or 'ip a' | 02:05 |
terryc | As far as I can tell, everything for static is still there, so contents of /etc/network/interfaces is fine with no change. i just can not get ifup or reboot to use static networking again. | 02:05 |
fsr | what interfaces does ifconfig say you have? | 02:05 |
fsr | the interfaces file will say whatever you put in there | 02:06 |
fsr | the system (udev/eudev) will give your physical interfaces names, regardless of what you put in the interfaces file | 02:06 |
terryc | ifconfig: now with dhcp running shows lo & eth1. Reboot with no dhcp and just lo and I can not get eth0 loaded. | 02:10 |
yellyfish | looks like it worked, for now. I'll have to see when i restart the machine if it all is fine | 02:11 |
fsr | terryc, if there's a file named /etc/udev/rules.d/70-persistent-net look in it | 02:13 |
fsr | um, do you have two wired interfaces, or did eth0 get renamed? | 02:14 |
terryc | eth0 got renamed by dhcp. i'll fiddle with udev and be back. | 02:17 |
Criggie | renaming ethernet interfaces is something systemd would do | 02:22 |
Criggie | lets not do that. | 02:22 |
nacelle | udev does it | 02:26 |
nacelle | etc. | 02:26 |
nacelle | its not just a systemd thing | 02:27 |
fsr | if you're on ascii, you should have eudev, and that will use the traditional names | 02:28 |
fsr | if you want to use the "predictable" names, add net.ifnames=1 to the boot command | 02:28 |
terryc | SOLVED: fsr and gnarface thanks. Problem solved. It was due to udev. Somehow the eth0 spec was commented out during migration. | 02:30 |
fsr | commented out where? | 02:31 |
nacelle | I usually blow away 70-persistent-net.rules and reboot to fix the boxes I usually hit the issues on, fwiw | 02:31 |
nacelle | much easier than trying to sort it all out | 02:31 |
fsr | yeah, that works on jessie | 02:31 |
fsr | but that file doesn't exist in stretch/ascii | 02:32 |
nacelle | funky | 02:32 |
nacelle | i've never seen this before, but I'm seeing it on my ascii boxes | 02:32 |
nacelle | will have to learn eudev | 02:33 |
fsr | maybe | 02:33 |
fsr | I haven't had to do anything with it | 02:33 |
fsr | but I've never had to write any udev rules | 02:33 |
nacelle | i've written too many :( | 02:34 |
fsr | sorry to hear | 02:34 |
nacelle | I worked with a software/hardware product line that always expected the hardware to have nics in a particular order | 02:34 |
terryc | commented out in /etc/udev/rules.f/*net*. | 02:34 |
nacelle | eth0 had to be the nic for the mgmt port, etc. | 02:34 |
nacelle | I dont have any rules.d/ files on ascii | 02:35 |
fsr | seems like that would work well with the predictable names | 02:35 |
nacelle | anyways, they got a motherboard series in where the mgmt port was hard wired up as eth2 under the kernel they booted... so they hacked in some udev rules to always remap when they detected that kind of motherboard | 02:35 |
nacelle | and I got really used to hacking around udev at that point :-) | 02:36 |
nacelle | yeah, it did | 02:36 |
nacelle | but when jumping kernel versions, it gets tricky | 02:36 |
nacelle | they do shit like change the pci scan order, so nics come up different between 2.4 and 2.6, etc. | 02:36 |
terryc | nacelle, thanks for the tip. it usually is only a problem with a 'boxen" migrates motherboards, but this wasn't the case. just a OS migrate from debian-stretch to devuan-ascii. | 02:36 |
nacelle | ah yeah, in that instance always blow away 70-persistent-net.rules if it exists | 02:37 |
terryc | I might have to adopt that if hardware becomes more unreliable. Usually it is just a fiddle with mother board replacement. | 02:52 |
yellyfish | ?quit | 03:09 |
gnarface | terryc: hey sorry about that, glad you figured it out. usually it won't do that unless it thinks you changed ethernet devices. did you? i think it just goes by MAC address. you can either delete that persistent-net.rules file or you can correct it by hand | 04:28 |
gnarface | it just iterates ethN every time it sees a new mac address, and the file itself is the record | 04:28 |
gnarface | it seems dumb but it makes more sense if you imagine the behavior for multi-homed servers | 04:30 |
gnarface | but i admit that's caught me before too, when doing concurrent hardware upgrade at the same time | 04:31 |
gnarface | - change motherboard during debian upgrade, suddently eth1 with no eth0 in sight, wtf? | 04:34 |
gnarface | i know that feeling | 04:34 |
gnarface | but basically it just was expecting you to still plug the old one back in | 04:35 |
gnarface | if the hardware is all the same, something went wrong | 04:36 |
terryc | gnarface: thank you for that background. Explains stuff. | 08:11 |
x2sdna27 | does devuan include thinkpad_acpi? | 08:12 |
terryc | There is acpi stuff in the packages list, but nothing specifically for thinkpad. qiuet time now. You could wait, ask the mailing list or on the forum | 08:56 |
terryc | Is this any help; ww.thinkwiki.org/wiki/Thinkpad-acpi | 08:57 |
gnarface | well he's gone now but there is a kernel module called thinkpad_acpi that maybe he was thinking of | 09:36 |
gnarface | as far as i know it's included still | 09:36 |
gnarface | the x86 kernels haven't been altered | 09:37 |
_abc_ | When I installed git-deamon I got a git daemon started on every boot. It is not controlled by /etc/init* ; can someone say how it is turned on/off when installed? At boot time? I.e. disable autostart? | 09:57 |
gnarface | i can only guess maybe something else controlled by init is starting it, like inetd | 10:01 |
gnarface | could be rc.local but i think packages aren't allowed to use that | 10:01 |
gnarface | but it could have been put in rc.local by hand | 10:01 |
_abc_ | It's not in any rc script I could grep -Rl | 10:03 |
_abc_ | I'll have to read the package source install scripts to see what is going on, no time now | 10:03 |
_abc_ | Please suggest a way in xfce4 to un-maximize applications. If one maximizes it, it loses decorations and there is no way to undo it for most appls, other than restart from cli with -geometry XxY | 10:23 |
_abc_ | I did something with devilspie to automate this in part but it is a nasty hack | 10:24 |
_abc_ | Is there a central way to set do-not-undecorate-maximized-windows? Basically clicking maximize causes the apps to go fullscreen not maximized. | 10:24 |
_abc_ | bbl I'll ask that again. Thanks | 10:25 |
epicmetal | So is Ceres on par with Sid in terms of reliability/QA? As in, a lot of Debian users use Sid on their workstations. Is Ceres usable like this or is it more like Fedora Rawhide? | 15:39 |
KatolaZ | epicmetal: ceres is sid | 15:53 |
KatolaZ | apart from the packages forked by devuan | 15:53 |
epicmetal | KatolaZ: okay, so do the packages forked by Devuan cause it to be more unreliable? | 15:54 |
KatolaZ | epicmetal: it's usually the opposit | 15:55 |
KatolaZ | ~opposite | 15:55 |
KatolaZ | :) | 15:55 |
epicmetal | And are there remnants of systemd in Ceres, given that it is presumably pulled from Sid and is essentially a rolling release? | 15:55 |
VlijmenFileer | About to try out current Devuan. Is any list available of packages missing compared to Debian, preferably highlighting the popular ones? | 15:55 |
epicmetal | In other words, because Ceres is presumably continually importing Sid, does it have systemd in it because Devuan hasn't removed it yet | 15:56 |
epicmetal | I should just try it shouldn't I... | 15:57 |
KatolaZ | epicmetal: the only stuff related to systemd is libsystemd | 16:04 |
KatolaZ | but, as I have explained several times, that is pretty innocuous | 16:04 |
KatolaZ | since it does nothing if systemd is not running | 16:04 |
KatolaZ | epicmetal: systemd cannot enter Devuan repos | 16:05 |
KatolaZ | and packages that depend directly on systemd are banned from Devuan repos | 16:05 |
epicmetal | Ok | 16:05 |
epicmetal | What are the chances of Devuan adopting runit? | 16:06 |
KatolaZ | epicmetal: as a default? | 16:06 |
KatolaZ | there is a plan to support runit as an option | 16:06 |
epicmetal | KatolaZ: yeah, like in the future | 16:06 |
KatolaZ | more or less as openrc is an option in ascii already | 16:06 |
KatolaZ | (and will continue to be in beowulf) | 16:06 |
epicmetal | So it will just support alternatives as options but keep sysvinit as default? | 16:07 |
KatolaZ | epicmetal: the important is to have alternatives :) | 16:08 |
KatolaZ | not to change the default | 16:08 |
KatolaZ | and leave users on their own... | 16:08 |
KatolaZ | ;) | 16:08 |
KatolaZ | the plan is to let user choose the init they want | 16:09 |
KatolaZ | and to support as many of them as possible | 16:09 |
epicmetal | Ok. I just assumed that sysvinit would be increasingly hard to support as time goes on | 16:10 |
epicmetal | Don't ask me why I think that, I didn't pay close enough attention to the Debian debates ;) | 16:10 |
KatolaZ | epicmetal: don't assume | 16:12 |
KatolaZ | :) | 16:12 |
KatolaZ | we must solve problems when they become real | 16:12 |
KatolaZ | and not before | 16:12 |
KatolaZ | we don't have enough energy for that | 16:12 |
epicmetal | I appreciate that | 16:12 |
epicmetal | KatolaZ: so Ceres still installs libsystemd0? | 18:05 |
epicmetal | https://git.devuan.org/dev1fanboy/Upgrade-Install-Devuan/wikis/Ceres-without-Systemd | 18:05 |
epicmetal | Nevermind, I have to disconnect | 18:13 |
KatolaZ | epicmetal: yes | 18:13 |
KatolaZ | well, if any of the packages you use is linked against libsystemd0 | 18:14 |
KatolaZ | we are working on that as well | 18:14 |
KatolaZ | but again, is like having link2 built against libsvga2 and not having an svga terminal available | 18:14 |
KatolaZ | s/link2/links2 | 18:15 |
KatolaZ | (I just realised that the example might be obscure in some camps, sorry...) | 18:15 |
epicmetal | KatolaZ: what's the plan for that? | 18:17 |
KatolaZ | replacing libsystemd0 with a nooped version | 18:19 |
epicmetal | i see | 18:19 |
KatolaZ | apparently people continue to freak out when they see "libsystemd0" | 18:21 |
KatolaZ | really for no reason at all | 18:21 |
KatolaZ | since it does absolutely *nothing* if systemd is not running as init | 18:21 |
epicmetal | probably because they don't know what it does | 18:22 |
KatolaZ | you can fear only what you don't understand | 18:22 |
epicmetal | it's pretty opaque to a non-dev | 18:22 |
epicmetal | library has functions, who knows what they do | 18:22 |
KatolaZ | yeah sure | 18:22 |
KatolaZ | :D | 18:22 |
epicmetal | they could theoretically do bad things | 18:22 |
epicmetal | i.e. side effects | 18:22 |
KatolaZ | they might suck your sould while you sleep | 18:22 |
KatolaZ | who knows! | 18:22 |
epicmetal | there's no way to know without inspecting it | 18:23 |
epicmetal | there's nothing stopping upstream from adding code to libsystemd0 that is functional without systemd running | 18:23 |
KatolaZ | epicmetal: come on... | 18:26 |
KatolaZ | what shoudl this code do, exactly? | 18:26 |
epicmetal | KatolaZ: who knows | 18:26 |
epicmetal | that's the point | 18:26 |
epicmetal | I'm just speaking hypothetically | 18:26 |
KatolaZ | yeah | 18:26 |
epicmetal | I should really sleep now | 18:28 |
xrogaan | in the end, what is in ascii? polkit or policykit? | 18:34 |
xrogaan | I ask so I can hack around. | 18:34 |
xrogaan | the structure ressemble policykit | 18:35 |
fsr | xrogaan, the release notes have some information about which kits go with with desktops | 18:35 |
fsr | for xfce, you'll have consolekit, policykit-1, policykit-1-gnome and some libpolkit packages | 18:36 |
xrogaan | This is a mess. Which is it? | 18:36 |
fsr | you're being polite | 18:37 |
fsr | which desktop do you use? | 18:37 |
xrogaan | doesn't matter. | 18:37 |
fsr | yeah, it does | 18:37 |
KatolaZ | it actually does xrogaan | 18:38 |
xrogaan | I want to write polkit rules, it's independent from the desktop. | 18:38 |
fsr | unless you're ok with some missing functions like logout buttons | 18:38 |
xrogaan | I have a mate-polkit installed, but also policykit-1 | 18:38 |
xrogaan | those are different names, doc on the internet differ if you search for polkit or policykit. | 18:39 |
xrogaan | I don't know what is what. | 18:39 |
fsr | what desktop are you using | 18:39 |
fsr | ? | 18:39 |
KatolaZ | xrogaan: *-polkit packages normally are just policykit stuff for a specific desktop | 18:39 |
xrogaan | for the moment, mate | 18:40 |
xrogaan | so we're using policykit structure then? | 18:40 |
KatolaZ | polkit == policykit | 18:40 |
xrogaan | not it ain't, 'cause polkit requires some javascript ruleset while policykit is more akin to an ini file. | 18:41 |
fsr | https://files.devuan.org/devuan_ascii/Release_notes.txt | 18:41 |
KatolaZ | then you know more than me | 18:41 |
KatolaZ | I have no clue of why all this stuff is deemed *necessary* | 18:42 |
fsr | see Session management and policykit backends | 18:42 |
KatolaZ | it just looks like a lot of cruft, if you ask me | 18:42 |
xrogaan | freedesktop had a project named PolicyKit, it evolved and became polkit | 18:42 |
xrogaan | and now everything is messy because everybody uses some "version" of the project, but don't tell you which. | 18:43 |
xrogaan | the newer polkit has a javascript format for their .rules files. | 18:43 |
KatolaZ | xrogaan: if it were on my hands, I would have removed all this nonsense | 18:43 |
KatolaZ | because just nonsense it is | 18:43 |
xrogaan | and it's actually being used in /usr/share/polkit-1/rules.d/ | 18:44 |
xrogaan | but if you take a look at the structure of local config (/etc/polkit-1), it actually uses the older stuff. | 18:44 |
fsr | well, we're based on debian, so everything is a little bit old | 18:44 |
xrogaan | yeah, well: https://wiki.debian.org/PolicyKit | 18:46 |
xrogaan | `ToDo: explain how it works. ' | 18:46 |
xrogaan | This is on par with all the systemd nonsense. | 18:47 |
fsr | damn, I'd love to see that explanation | 18:48 |
fsr | Ii've read the man pages, and I still don't get it | 18:48 |
KatolaZ | I have the impression just a few people (if any) has really understood how it works | 18:49 |
KatolaZ | this is typical of stuff that lacks documentation | 18:49 |
KatolaZ | if documentation is not there, it means that there are not enough people who have understood it | 18:49 |
KatolaZ | and who can explain it to others | 18:49 |
fsr | In ascii desktop-live (xfce) I have /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules and no other files | 18:50 |
fsr | there are still files in ../actions | 18:50 |
xrogaan | yeah, that's the system rules. You shouldn't touch that. | 18:50 |
xrogaan | the local admin should use the /etc/polkit-1 directory | 18:51 |
fsr | yeah, if I knew what to put there... | 18:51 |
xrogaan | thing is, the etc thing differs from the system one and that's just crazy. | 18:51 |
fsr | ascii version of Refracta is held up because of this crap | 18:51 |
fsr | synaptic starts without authentication and lets users install software | 18:52 |
xrogaan | latest reference manual: https://www.freedesktop.org/software/polkit/docs/latest/ | 18:52 |
xrogaan | we seem to be using 0.105 though, which is old. | 18:52 |
KatolaZ | xrogaan: we seem to be using it, which is *wrong* :D | 18:53 |
fsr | bbl | 18:54 |
xrogaan | If I understand correctly, old policykit uses "polkit" as a name for specific things. But the genius at freedesktop thought it smart to rename the whole project polkit. | 18:54 |
xrogaan | geniuses* | 18:54 |
xrogaan | and also change the way rules are written. | 18:55 |
xrogaan | and then debian comes along and say "we'll use that version for the next 2 decades." | 18:55 |
xrogaan | [DIR]0.105/2012-04-24 16:47 << which isn't too far off the truth. | 18:56 |
xrogaan | https://www.freedesktop.org/software/polkit/docs/0.105 | 18:56 |
xrogaan | problem is, the polkit doc about system config do not match ascii's system. | 19:14 |
xrogaan | ascii uses the new rules. | 19:14 |
AlexLikeRock | BUG !: | 19:48 |
AlexLikeRock | DROPBOX at devuan jessie : | 19:49 |
AlexLikeRock | dropbox: load fq extension '/home/alex/.dropbox-dist/dropbox-lnx.x86-52.4.60/PyQt5.QtPrintSupport.cpython-35m-i386-linux-gnu.so' | 19:49 |
AlexLikeRock | Dropbox isn't running! | 19:49 |
AlexLikeRock | any one can write the bug ?? | 19:49 |
AlexLikeRock | please | 19:49 |
KatolaZ | o_O | 19:50 |
AlexLikeRock | they run , but , the icon at SYSTEM TRAY "not appear (non visible) " | 19:50 |
xrogaan | AlexLikeRock: it's a dropbox issue | 19:55 |
xrogaan | contact the maintainer/developer of the dropbox software you are using. | 19:55 |
AlexLikeRock | xrogaan, you are right , its external program | 19:56 |
xrogaan | I don't personally use dropbox, so I cannot help. | 19:57 |
xrogaan | also, jessie is old. Consider upgrading towards ascii. | 19:57 |
AlexLikeRock | nop | 19:58 |
AlexLikeRock | i need stability , i love jessie | 19:58 |
KatolaZ | AlexLikeRock: ascii is stable... | 19:58 |
xrogaan | ascii is the stable channel. Jessie is old-stable | 19:58 |
AlexLikeRock | jessie its more stable than ascii | 19:58 |
AlexLikeRock | i now that | 19:59 |
AlexLikeRock | tanks by the way | 19:59 |
Tashtari | Hi all. I'm having problems with `apt-get source`, I get signature verification warnings when I try to download a package. The debian-keyring package is installed already, and none of the solutions to do with debian seem to work for me - wondering if this is peculiar to devuan. | 20:24 |
Tashtari | http://paste.debian.net/1032310/ | 20:27 |
xrogaan | it should check against system keys | 21:27 |
xrogaan | in there > /usr/share/keyrings/ | 21:28 |
Tashtari | xrogaan: I agree, it seems like it should. But maybe it -is-? One of the things I did was try copying /usr/share/keyrings/debian-maintainers.gpg (and also devuan-keyring.gpg) to ~/.gnupg/trustedkeys.gpg, and all that did was get rid of the error about the missing file. | 21:30 |
xrogaan | no, no | 21:38 |
xrogaan | it shouldn't look into your home folder. Do you run the software under root? | 21:38 |
xrogaan | I have no idea what is going on. | 21:39 |
Tashtari | xrogaan: No, I'm running it as an unprivileged user, apt-get source isn't doing anything that should require root. | 21:41 |
Tashtari | Though I -could- run it as root, I suppose... | 21:41 |
Tashtari | Nope, same error. | 21:42 |
xrogaan | which version of devuan are you on? | 22:00 |
xrogaan | try : apt-get update; apt-get install --reinstall debian-keyring devuan-keyring debian-archive-keyring | 22:01 |
xrogaan | are there stuff in /usr/share/keyrings? | 22:02 |
xrogaan | Tashtari: https://lists.debian.org/debian-user/2013/03/msg00887.html | 22:03 |
Tashtari | Jessie. And ok, I'll give it a shot.. | 22:07 |
Tashtari | There are things in /usr/share/keyrings - several debian*.gpg and devuan*.gpg files. | 22:08 |
Tashtari | Nope. Tried reinstalling, to no avail. | 22:12 |
Tashtari | xrogaan: The thread you linked only seems to suggest installing that package, which is installed already. D: | 22:14 |
golinux | sources.list please | 22:17 |
Tashtari | golinux: http://paste.debian.net/1032357 | 22:20 |
KatolaZ | Tashtari: you should already have all the needed keyrings | 22:30 |
Tashtari | KatolaZ: I totally agree. | 22:32 |
Tashtari | But I'm still getting the errors. | 22:32 |
KatolaZ | Tashtari: are you running apt-get source as regular user? | 22:34 |
Tashtari | Yes, though I've tried running it as root, too, with the same error. | 22:35 |
xrogaan | the thread I linked actually say that if a package is signed with an expired key, you'll get some kind of error. | 22:36 |
KatolaZ | Tashtari: can't reproduce it on ascii | 22:38 |
Tashtari | xrogaan: Really? I don't see that in the linked thread... | 22:40 |
xrogaan | https://lists.debian.org/debian-user/2013/03/msg00885.html | 22:41 |
Tashtari | Hm. Okay, if the key is expired, though, how can I confirm this? | 22:42 |
KatolaZ | Tashtari: I have just tried on ascii using jessie repos | 22:42 |
xrogaan | dunno, try another package? | 22:42 |
KatolaZ | and it works without errors | 22:42 |
KatolaZ | Tashtari: apt-key list | 22:42 |
KatolaZ | but the jessie key is not expired | 22:42 |
KatolaZ | it expired in 2022 | 22:42 |
KatolaZ | s/red/res | 22:43 |
Tashtari | I just ran `apt-key list | grep "expire"` and all of them expire 2019 at the earliest... | 22:43 |
KatolaZ | uh? | 22:43 |
KatolaZ | o_O | 22:43 |
KatolaZ | oh ok | 22:44 |
KatolaZ | 2019 | 22:44 |
KatolaZ | right | 22:44 |
Tashtari | I mean, I don't see any expired keys there | 22:44 |
KatolaZ | yep I got it | 22:44 |
Tashtari | xrogaan: Just tried getting the source for nano, same error. | 22:46 |
KatolaZ | Tashtari: you must have an error somewhere then | 22:46 |
Tashtari | Sure, the question is where? | 22:48 |
KatolaZ | Tashtari: can you see that Key ID in the list provided by apt-key list? | 22:48 |
Tashtari | Which key ID? | 22:48 |
KatolaZ | the offending one | 22:48 |
KatolaZ | the ID of the key that signed the package | 22:48 |
Tashtari | ah, let's se... | 22:49 |
Tashtari | see* | 22:49 |
KatolaZ | Tashtari: http://paste.debian.net/1032310/ | 22:49 |
KatolaZ | this is what you posted | 22:49 |
Tashtari | Right. | 22:49 |
KatolaZ | hold on | 22:49 |
KatolaZ | let's see who does that key belong to... | 22:49 |
Tashtari | Nope. `apt-key list | grep C8D648BD` returns nothing | 22:50 |
KatolaZ | that;s not a valid key, I guess... | 22:51 |
KatolaZ | which mirror are you hitting? | 22:51 |
Tashtari | us.mirror.devuan.org, by the looks of it. | 22:51 |
KatolaZ | mmmhhh | 22:52 |
KatolaZ | no I mean the Debian one | 22:52 |
Tashtari | I'm not hitting a debian mirror, I don't think. This is my whole /etc/apt/sources.list: http://paste.debian.net/1032357 | 22:54 |
KatolaZ | Tashtari: actually you are | 22:55 |
KatolaZ | :) | 22:55 |
KatolaZ | everybody is | 22:55 |
Tashtari | Where? | 22:55 |
KatolaZ | Tashtari: devuan packages that have not been forked from debian still come directly from debian mirrors | 22:55 |
Tashtari | Ah. | 22:55 |
Tashtari | When I do my `apt-get source grub2`, though, it only hits us.mirror.devuan.org. | 22:56 |
Tashtari | No mention of debian. | 22:56 |
KatolaZ | yeah | 22:59 |
KatolaZ | it's transparent :) | 23:00 |
Tashtari | How do I answer your question, then? :) | 23:00 |
KatolaZ | you don't have to | 23:02 |
KatolaZ | I should | 23:02 |
KatolaZ | hold on | 23:02 |
KatolaZ | :) | 23:02 |
KatolaZ | well, it seems you would hit deb.debian.org | 23:02 |
KatolaZ | which is the correct cdn | 23:03 |
KatolaZ | this is pretty weird... | 23:03 |
Tashtari | That is certainly true. | 23:03 |
KatolaZ | biab | 23:05 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!