[06:29] <alkisg> Hi, is it possible to install chromium-browser without snap in 20.04? I'm guessing "no", but shouldn't at least the debian package be offered in universe?
[06:34] <dax> not from ubuntu repositories, i have no idea whether it's a PPA somewhere (and wouldn't recommend it if it were)
[06:34] <alkisg> Thank you dax; I'll search where I can file a bug report for it; I don't see any reason to block a specific debian package from reaching ubuntu users, unless it's just to force snap...
[06:35] <dax> it's deliberate behavior, and filing a bug report seems like a waste of time
[06:36] <alkisg> The official excuse is "we don't have resources to provide security updates", but that isn't valid for packages in universe, afaik
[06:36] <alkisg> I'm not asking them to put it in main, so I think that specific concern hasn't been voiced
[06:37] <lotuspsychje> since 19.10 chromium is a snap right?
[06:37] <alkisg> Maybe; I'm not really following non-LTS releases
[06:37] <alkisg> (heya lotuspsychje btw :))
[06:38] <alkisg> Found it: https://bugs.launchpad.net/ubuntu/+source/chromium/+bug/1855594
[06:38] <ubottu> Launchpad bug 1855594 in chromium (Ubuntu) "Sync chromium 78.0.3904.108-1 (universe) from Debian unstable (main)" [Wishlist,New]
[06:39] <tarzeau> dax: i'm building my own .debs of it for ubuntu meanwhile
[06:40] <alkisg> tarzeau: if you have them in a PPA, we'd prefer them to google's chrome, until this ubuntu mess gets properly resolved :)
[06:40] <tarzeau> dax: it's causing problems for computers that run the browser for days, weeks, months (with it's updates breaking running versions in memory)
[06:40] <tarzeau> alkisg: i've been reporting that since 19.04 when they started the shit
[06:41] <alkisg> I think this ^ issue is the way to go
[06:41] <tarzeau> alkisg: we use reprepro with our own webserver, so no PPA sorry
[06:41] <lotuspsychje> there IS a 20.04 opinion going on recently, maybe we should mass vote chromium back into the repos?
[06:41] <alkisg> I've been thinking about that for months too, but today I though this solution, and someone else had thought it before me...
[06:41] <tarzeau> lotuspsychje: it's a company, they don't care
[06:41] <alkisg> lotuspsychje: I certainly will; I have the voting tab open :)
[06:41] <alkisg> tarzeau: companies of course care about both users and contributors
[06:41] <tarzeau> i've been thinking to migrate our workstations back to debian because of that reason
[06:42] <alkisg> E.g. I produce a lot of software and make sure its runs fine on ubuntu; if ubuntu stops caring, then I'll stop caring too
[06:42] <tarzeau> ubuntu hardly produces a lot of software, they copy packaged software from debian and rebuild it
[06:43] <lotuspsychje> alkisg: i also understand tarzeau chromium going snap for his users, isnt very convient (auto-updates)
[06:43] <alkisg> Why would the debian package auto-update?
[06:43] <lotuspsychje> the snap auto updates
[06:43] <alkisg> Didn't tarzeau say that he's not using the snap version?
[06:44] <alkisg> Also, if a sysadmin installs the snap, then it autoupdates for each user separately?! 
[06:44] <lotuspsychje> yeah i mean before it was going snap, he used the repo one for his users
[06:44] <tarzeau> we remove snap and netplan, and gnome-software
[06:44] <tarzeau> and patch gnome-control-center
[06:44] <alkisg> Yeah same here; except, using mate, so no gnome* at all
[06:46] <alkisg> I think that bug above is the correct place to focus our concern; I'll tell my users to comment there
[06:46] <lotuspsychje> good idea
[06:47] <tarzeau> alkisg: liked (also affects me, and 1000+ users)
[06:48] <lotuspsychje> im really a big fan of leaving the users the choice
[06:50] <tarzeau> i'm a fan of consistency, stability, and the tools one needs to get work done
[06:50]  * alkisg sees no point in having 2 package managers
[06:50] <alkisg> If .deb has something wrong, then work to resolve that or completely replace that
[06:51] <tarzeau> alkisg: i agree
[06:51] <alkisg> Also I don't like the snap design, I think the deb design is a lot superior
[06:52] <lotuspsychje> i think the main goal with snaps, is they want easy maintain their software, and it doesnt react the same way as the deb ones
[06:52] <lotuspsychje> the you get the mass complaints
[06:52] <tarzeau> i wouldn't mind if they replaced snap with spack 
[06:52] <tarzeau> https://spack.io/
=== pavlushka_ is now known as pavlushka
[07:46]  * alkisg just answered the survey, noting this issue as well as others
[07:48] <tarzeau> +1
[07:48] <tarzeau> what were your other issues?
[07:50] <tarzeau> alkisg: so will you stop making ltsp ppa, and only do everything with official packages? https://ltsp.org/docs/ppa/
[07:50] <alkisg> tarzeau: heh, for example another of the issues I reported was "make it easier for upstream/motu to provide backports", which is basically what I'm solving with the ppa
[07:51] <tarzeau> ah it's just backports, not the recommend pkg (it's clear for debian, not so much for ubuntu)
[07:51] <alkisg> No, the ppa won't go away, as the ltsp nature is sensitive to other package upgrades, and it needs frequent updates
[07:51] <tarzeau> but suppose i have 20.04 (unreleased) i can go with the official package i guess
[07:51] <alkisg> Of course, and in debian bullseye too
[07:51] <alkisg> You won't get ltsp-binaries, but you'll only lose memtest that way, nothing important
[07:52] <alkisg> Example, a systemd/netplan update made clients not work a few months ago; an ltsp update in the ppa fixed that
[07:52] <alkisg> Without the ppa, you'd just be stuck with unbootable clients
[07:52] <alkisg> (that was for ltsp5)
[07:53] <alkisg> I might stop the ltsp ppa and switch back to only using the greek schools ppa though in the distant future, we'll see
[07:53] <alkisg> (greek schools ppa = ubuntu only, while ltsp ppa = debian too)
[07:53] <tarzeau> when there's no more ldm, what does it look like by default?
[07:54] <alkisg> Like normal ubuntu, e.g. gdm, lightdm...
[07:54] <tarzeau> (i haven't set up 19 yet, our apprenticeship will do with 20.04)
[07:54] <tarzeau> and rdp is also still supported and kiosk mode (autologin)?
[07:54] <alkisg> Maybe we should be talking in #ltsp about these...
[07:55] <alkisg> Autologin, yes. No screen scripts anymore; they're to be replaced by user sessions
[07:55] <alkisg> So you can define /usr/share/xsession/something.desktop that does whatever you like
[07:55] <tarzeau> ah i see, ok that's great
[07:58] <tarzeau> alkisg: are annoyed by https://popcon.ubuntu.com/ not being up to date/wrong?
[07:58] <alkisg> Nah, this is opt-in, its results aren't accurate anyway
[07:58] <alkisg> I'd love to see the server stats though
[07:59] <alkisg> E.g. "how many downloads of the xxx.deb package on each update?"
[07:59] <tarzeau> it should have a big fat red blinking warning: this data is outdated, there's certainly not more i386 ubuntu users than amd64
[08:00] <alkisg> In greece we have 10000 i386 PCs and 1000 amd64 :P
[08:00] <alkisg> E.g. school labs with ltsp and nine 64bit clients, and one 32bit, use i386 arch...
[09:00] <tarzeau> and that's debian based?
[09:00] <tarzeau> or ubuntu? (asking because of the i386 bit)
[09:01] <alkisg> Most are ubuntu so far, so up to 18.04
[09:01] <alkisg> Many schools got new computers, so for 20.04 we'll probably switch to amd64
=== Seveas_ is now known as Seveas