rrq | bgstack15: took a slightly more involved overhaul, but I think it's now push-button ready (again?) | 04:28 |
---|---|---|
rrq | oops I think I missed at merging | 04:29 |
rrq | pm | 04:32 |
plasma41 | rrq: Reading through the meeting notes. The new pkginfo is very nice | 04:34 |
* rrq beaming with pride :) | 04:37 | |
plasma41 | rrq: How soon till it replaces the current pkginfo? | 04:39 |
rrq | not sure; depends on how much gilding it needs | 04:44 |
golinux | rrq: Let me know when you're ready for another round. | 04:46 |
rrq | plasma41: other thing: do you know how to manage gitea pull request branch in my local workspace? | 04:49 |
plasma41 | I don't | 04:50 |
* rrq found https://github.com/gogs/gogs/issues/1655 | 04:54 | |
mason | LeePen: I wish half that tech-ctte traffic didn't make me want to run screaming away from the entirety of Debian. | 14:46 |
bgstack15 | I thought LeePen's last email was brilliant. | 14:48 |
bgstack15 | showing that what has been requested is actually in the spirit of the GR | 14:48 |
mason | bgstack15: Realizing that there are these trolls running counter to that reasoning and trying to rules-lawyer the thing to death, though, is disheartening. They're not going away. | 14:49 |
mason | Maybe they're just a loud minority opinion. That'd make it more tolerable. | 14:49 |
bgstack15 | Don't they consider people like us, "a loud minority"? | 14:50 |
mason | bgstack15: Probably, yes. | 14:51 |
bgstack15 | dare I say it, the moral majority? | 14:51 |
mason | hah | 14:51 |
LeePen | mason: Thanks for watching the show ;) | 17:26 |
mason | LeePen: Thanks for your part of that. Although I am not a huge fan of having something like elogind be the answer. It's a gateway to letting the systemd crew dictate APIs and structure. | 17:27 |
mason | LeePen: PM? | 17:27 |
LeePen | Of course | 17:27 |
mason | (Not sure if you're someone who objects to random unannounced PMs or not.) | 17:27 |
LeePen | I know there are reservations about elogind being the current solution, but it is all we have ATM. | 17:28 |
LeePen | But maybe the new seatd option might be an alternative int he future? | 17:29 |
fsmithred | LeePen, do we test seatd by replacing elogind? | 17:39 |
LeePen | TBH, I don't know. I think to begin with we use elogind as seatd backend. | 17:40 |
LeePen | I really started a package so that we can have a play and see if it might be useful. | 17:42 |
LeePen | Or see how it might be useful. | 17:42 |
fsmithred | what does it do? | 17:42 |
LeePen | I think seatd manages users, seats and sessions. | 17:43 |
LeePen | libseat1 is the interface and can use different backends -- configurable at runtime | 17:43 |
LeePen | (which is a big and helpful step). | 17:43 |
LeePen | The available backends are seatd itself, elogind | 17:44 |
LeePen | and systemd-logind. | 17:44 |
fsmithred | I'll install it in a ceres vm | 17:45 |
LeePen | So (again I think!) programmes which currently use libsystemd0 will have to use libseat1 and then you can switch the backend to what ever you want. | 17:45 |
LeePen | Great. So far, I just packaged the files and wrote an init script. | 17:46 |
LeePen | Since nothing is linked against libseat1, I don't think it will do much (yet). | 17:46 |
LeePen | Upstream has some other display manager and the like which do use it. Maybe we should package those as well. | 17:47 |
bgstack15 | I have a bunch of Ceres vms. I'll try playing with libseat. | 17:52 |
LeePen | bgstack15: great. | 17:54 |
bgstack15 | I will focus on trying to use it with lightdm, and with seatd using itself as its backend. | 17:54 |
LeePen | Good idea | 17:55 |
fsmithred | seatd and libseat1 installed in ceres (separately) without issue | 17:56 |
fsmithred | and it's running | 17:57 |
LeePen | Good start | 17:59 |
fsmithred | guess I'm done for now | 18:00 |
fsmithred | if I try to remove elogind, it wants to install consolekit | 18:04 |
mason | fsmithred: Depending on what you've got installed, you can ask it to suppress consolekit as part of the removal, or in some cases you can let it install consolekit and then just remove it. | 18:26 |
mason | I haven't mapped out just what's going on there. | 18:27 |
fsmithred | mason, the one that I noticed was gparted. Policykit stuff. | 18:40 |
LeePen | I think you won't be able to remove libpam-elogind until enough packages have changed to support libseat1 instead. | 19:24 |
fsmithred | couldn't it Provide libpam-elogind? | 19:36 |
fsmithred | or libpam-systemd, I guess | 19:36 |
LeePen | Possibly, but it can't/doesn't provide libsystemd0 and all it's symbols. | 19:41 |
bgstack15 | er, I must be really missing something. Do I need to configure lightdm to use seatd? | 20:10 |
mason | bgstack15: The idea will be to offer alternatives. The ultimate goal is for stuff to work with the systemd stuff if the user wants that, but only if the user wants it. | 20:14 |
mason | So you'd be able to keep using elogind if you wanted it. | 20:14 |
bgstack15 | I disabled elogind service, instead of uninstalling it. | 20:14 |
bgstack15 | I distinctly remember lightdm's dpkg freaking out about elogind or consolekit | 20:14 |
bgstack15 | Ah, so it is supposed to provide a dbus thingimajig, "org.freedesktop.login1" but somehow it times out on my system after 25s. | 20:17 |
bgstack15 | But in general a terminal or graphical session will allow me in after ~5 seconds | 20:17 |
LeePen | I think lightdm will need patching to use libseat1 API, if I have understood correctly. | 20:36 |
bgstack15 | On my system it was way more than just lightdm that needed it. And I think because it provides the dbus service, lightdm won't need any attention. | 20:43 |
bgstack15 | Perhaps my system is too customized for seatd to work correctly. It sounded like fsmithred got it working. | 20:44 |
fsmithred | not that I know of | 20:48 |
fsmithred | I installed it and ps shows that it's running | 20:48 |
fsmithred | no clue if it's doing anything | 20:48 |
bgstack15 | oh, haha. I just found "/usr/sbin/ofonod" running which has something to do with telephony. Apt-get removing it caused no problems... so I wonder how it got there. | 20:58 |
bgstack15 | Also, the latest fprintd has been causing me some headaches. Anybody else use fprintd? | 20:58 |
Unit193 | LeePen: Oh hey, did anything in that diff end up being helpful? Also it looked like someone had planned to submit eudev to Debian but that seems stalled? | 21:37 |
LeePen | Unit193: Sorry, have missed the diff. Can you post again? | 21:50 |
LeePen | gnu_srs is eudev guru and was prepping for Debian. | 21:51 |
Unit193 | LeePen: http://paste.openstack.org/show/1WGOoHlVNVbTJigSUJfL is what I have now, but that's a merge of the Debian stuff too. Some stuff should be ignored and some is preference, but does make it a little more standard. | 21:53 |
LeePen | Ok. Thanks. | 21:53 |
Unit193 | Nothing specifically important. | 21:53 |
LeePen | Good time to include them. Next 246 rc soon. | 21:54 |
Unit193 | Yeah I needed the rc so rsyslog would upgrade. | 21:55 |
LeePen | Glad it worked.Need to make the bullseye freeze. | 21:59 |
DocScrutinizer05 | http://maemo.cloud-7.de/irclogs/freenode/_devuan-dev/_devuan-dev.2020-11-28.log.html#t2020-11-28T22:42:52 YW | 22:04 |
arachnopavel | Hello, folks. Any plans to do something with the fact that debian fails to release security updates for chromium, postgresql and probably some other packages? | 22:27 |
fsmithred | nope | 22:29 |
arachnopavel | Ok. | 22:30 |
fsmithred | (pretty sure I can speak for all the existing dev on that point.) | 22:30 |
fsmithred | they really don't? | 22:30 |
fsmithred | I've seen chromium updates in the past | 22:30 |
fsmithred | 83.0.4103.116-1~deb10u3 | 22:31 |
fsmithred | u3 means third update from debian, and it's in beowulf-security, so it was also in buster security | 22:31 |
fsmithred | was/is | 22:31 |
arachnopavel | https://security-tracker.debian.org/tracker/source-package/chromium - they really don't. Also, https://wiki.debian.org/Chromium says: "As of 2020-11-16 13:58:33, Debian's Chromium package remains vulnerable to numerous CVEs as outlined in the Chromium Security Tracker. Consider using an alternative browser like Firefox." | 22:32 |
fsmithred | https://security-tracker.debian.org/tracker/CVE-2020-6420 | 22:33 |
fsmithred | yeah, they are way behind. Does anyone have patches for all those? | 22:35 |
Jjp137_ | for what it's worth, Ubuntu seems to be on 86.x | 22:36 |
mason | Ugh, that's discouraging... | 22:36 |
fsmithred | ceres/sid is still on 83 | 22:37 |
mason | fsmithred: Some of those only apply to Android. Randomly picked CVE-2020-6568 as an example. | 22:40 |
fsmithred | yeah, I just went with the latest one on the page I saw | 22:40 |
arachnopavel | Same for postgresql-11: https://security-tracker.debian.org/tracker/source-package/postgresql-11 - the vulns were announced on November 12 (see https://www.postgresql.org/about/news/postgresql-131-125-1110-1015-9620-and-9524-released-2111/ ), but still remain unpatched. | 22:41 |
fsmithred | feeling ambitious? | 22:42 |
mason | https://ubuntu.com/security/cve?q=&package=chromium-browser&priority=&version=&status= is interesting reading too | 22:42 |
arachnopavel | fsmithred, as in making patches by myself? Not really. I'm building chromium from upstream sources, and there are upstream packages for postgresql. Just wanted to know if devuan has or is going to implement some process to fix this mess. | 22:44 |
fsmithred | not until someone volunteers to do it. | 22:45 |
bgstack15 | I think it would be most prudent to find out how to assist the Debian packagers of Chromium. | 22:45 |
fsmithred | that makes a lot more sense | 22:47 |
fsmithred | 80.0 in focal (20.04 LTS) | 22:47 |
fsmithred | 85.0 in groovy and hirsute | 22:48 |
bgstack15 | Wow, and I thought Debian names were bad.. | 22:49 |
fsmithred | yeah, really | 22:50 |
fsmithred | I'm afraid to ask what the second half of that last name is. | 22:50 |
bgstack15 | horse? | 22:50 |
bgstack15 | oh, hippo | 22:52 |
fsmithred | dpkg: regarding chromium-browser_85.0.4183.83-0ubuntu2_amd64.deb containing chromium-browser, pre-dependency problem: | 22:52 |
fsmithred | chromium-browser pre-depends on snapd | 22:52 |
fsmithred | tried on chimaera | 22:52 |
Jjp137_ | yeah from focal onwards it seems they rely on snap packages | 22:52 |
Jjp137_ | the version in bionic still has the usual grocery list of dependencies so maybe that might work | 22:54 |
fsmithred | that's 80.0, isn't it? | 22:54 |
Jjp137_ | nah bionic is on 86.0 | 22:54 |
fsmithred | and snapd is a banned package in devuan. So does that mean we can't use chromium anymore? | 22:54 |
Jjp137_ | here: https://packages.ubuntu.com/bionic/chromium-browser | 22:55 |
fsmithred | ok, that's weird | 22:55 |
Jjp137_ | probably b/c bionic is LTS so they didn't want to just throw snapd in there with no warning | 22:55 |
Jjp137_ | just a guess though | 22:56 |
bgstack15 | Ubuntu has made some questionable choices about what to put in their LTSes before. | 22:56 |
Jjp137_ | wouldn't be surprised if they did | 22:56 |
bgstack15 | But, iirc, they at least reverted from Wayland back to Xorg from 17.10 to 18.04. | 22:57 |
fsmithred | 80.0 in focal (20.04 LTS) | 22:57 |
fsmithred | 86 from bionic looks like it will install on chimaera | 22:57 |
Jjp137_ | focal-updates has 85.0 for some reason: https://packages.ubuntu.com/focal-updates/chromium-browser | 22:57 |
bgstack15 | if we absolutely have to, we can go consult with the Linux Mint team about Chromium in a dpkg. | 22:57 |
bgstack15 | I don't like Chromium-based browsers so I have no desire to deal with that can of worms. I'm resenting my investigation of modern Firefox, but at least I can duplicate the actions of the Debian Firefox team. | 22:58 |
fsmithred | 86 also looks like it will install on beowulf | 22:59 |
fsmithred | I use chromium only for meetings | 23:00 |
fsmithred | you also need chromium-codecs-ffmpeg chromium-codecs-ffmpeg-extra | 23:06 |
fsmithred | and it doesn't replace the older one, because the package name is different: chromium-browser in ubuntu | 23:10 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!