[04:20] <slangasek> LocutusOfBorg: I wasn't meaning to drive the haskell transition, I just ran aground on it when a separate transition wound up blocked by pandoc uninstallability.  But considering how deep the haskell stack is, I figure it doesn't hurt to have people pitching in around the clock
[04:32]  * tsimonq2 can help where I can with that as well
[04:34] <tsimonq2> slangasek: If you're around, any chance you could no-change rebuild qtubuntu against the new qtbase?
[04:36] <slangasek> tsimonq2: it looks from here like gsettings-qt also needs rebuilt, is that true?
[04:42] <tsimonq2> slangasek: Out of curiosity, how do you figure that?
[04:42] <slangasek> tsimonq2: packages that depend on qtabase-abi-5-9-0 in bionic and haven't been rebuilt in bionic-proposed
[04:45] <tsimonq2> slangasek: You mean the one that you just rebuilt? Yeah that ;)
[04:45] <tsimonq2> Thanks
[04:46] <tsimonq2> slangasek: And for future reference, do you have some sort of script or did you find that out manually?
[04:48] <slangasek> tsimonq2: I have a script but it's a bit idiosyncratic and sometimes gets the wrong answer vs the transition tracker, so I haven't published it
[04:49] <tsimonq2> slangasek: Ah ok gotcha
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-cardata [amd64] (bionic-proposed/universe) [3.0.0-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-forcats [amd64] (bionic-proposed/universe) [0.2.0-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-gower [ppc64el] (bionic-proposed/universe) [0.1.2-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-nortest [amd64] (bionic-proposed/universe) [1.0-4-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-rcpproll [ppc64el] (bionic-proposed/universe) [0.2.2-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-cvst [amd64] (bionic-proposed/universe) [0.2-1-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: r-cran-guerry [amd64] (bionic-proposed/universe) [1.6-1-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: r-cran-spatstat.data [amd64] (bionic-proposed/universe) [1.1-1-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: r-cran-gower [amd64] (bionic-proposed/universe) [0.1.2-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: r-cran-rcpproll [i386] (bionic-proposed/universe) [0.2.2-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: r-cran-gower [i386] (bionic-proposed/universe) [0.1.2-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: r-cran-gower [arm64] (bionic-proposed/universe) [0.1.2-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: r-cran-gower [s390x] (bionic-proposed/universe) [0.1.2-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: r-cran-rcpproll [amd64] (bionic-proposed/universe) [0.2.2-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: r-cran-rcpproll [armhf] (bionic-proposed/universe) [0.2.2-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: r-cran-gower [armhf] (bionic-proposed/universe) [0.1.2-1] (no packageset)
[05:16] -queuebot:#ubuntu-release- New binary: r-cran-rcpproll [arm64] (bionic-proposed/universe) [0.2.2-1] (no packageset)
[05:16] -queuebot:#ubuntu-release- New binary: r-cran-lava [amd64] (bionic-proposed/universe) [1.5.1-1] (no packageset)
[05:16] <infinity> Oh hey, I finally made ocaml transition.
[05:16] <infinity> Huzzah.
[05:16] -queuebot:#ubuntu-release- New binary: r-cran-rcpproll [s390x] (bionic-proposed/universe) [0.2.2-1] (no packageset)
[05:17] <tsimonq2> \o/
[05:17] -queuebot:#ubuntu-release- New binary: r-cran-readr [ppc64el] (bionic-proposed/universe) [1.1.1-1] (no packageset)
[05:18] <infinity> tsimonq2: Which package in desktop-common offends you?
[05:19] <infinity> tsimonq2: The point of desktop-common is similar to minimal/standard in the platform seeds, in that we all sort of agree that this is part of a "normal *buntu".
[05:19] <tsimonq2> infinity: I figured out how to make it go bye bye I think, and from what I can tell we shouldn't pick it up anyways because it seems like a recommends (if that changes I'll make a bigger deal about it) but snapd
[05:19] <infinity> tsimonq2: If you think something doesn't fit that, and other flavours agree, then we'd remove it (and flavours that want to keep it would see it in their own desktop)
[05:19] -queuebot:#ubuntu-release- New binary: r-cran-readr [amd64] (bionic-proposed/universe) [1.1.1-1] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: r-cran-readr [i386] (bionic-proposed/universe) [1.1.1-1] (no packageset)
[05:20] <infinity> tsimonq2: So, a release or two ago, didn't we all agree that snapd was something everyone wanted?
[05:20] <infinity> tsimonq2: Curious which flavour is a snowflake here. :)
[05:20] -queuebot:#ubuntu-release- New binary: r-cran-readr [s390x] (bionic-proposed/universe) [1.1.1-1] (no packageset)
[05:21] <tsimonq2> infinity: I'm curious when that was agreed on for the sake of reference, but things have changed. I don't see Lubuntu ever needing to use anything snapd provides.
[05:21] <infinity> lubuntu users don't install packages?
[05:22] <infinity> tsimonq2: Not sure about the concensus reference, but the addition was before Xenial released.
[05:22] <tsimonq2> Oh, so we should install the flatpak daemon too? Just saying. :P
[05:23] <tsimonq2> infinity: And Lubuntu positions (in multiple senses of the word) have changed as well.
[05:23] <tsimonq2> (since Xenial at least)
[05:23] <rbasak> Wasn't there an ML discussion that concluded that nobody was SRUing flatpak any more?
[05:23] <Ukikie> I like the option to not include snapd if a flavor desires.
[05:24] <infinity> slangasek: So, was the concensus on snapd before it was added to desktop-common?
[05:24] <infinity> s/the/there/
[05:24] <tsimonq2> rbasak: I personally don't care about flatpak but rather "snapd should be installed by default because it helps install software" is a weak argument if Lubuntu doesn't ever decide to ship any Snaps by default.
[05:24] <tsimonq2> Ukikie: I do too.
[05:24] -queuebot:#ubuntu-release- New binary: r-cran-readr [arm64] (bionic-proposed/universe) [1.1.1-1] (no packageset)
[05:24] -queuebot:#ubuntu-release- New binary: r-cran-readr [armhf] (bionic-proposed/universe) [1.1.1-1] (no packageset)
[05:25] <rbasak> Snaps are, currently at least, primarily for third party apps. What a flavor ships by default is thus irrelevant.
[05:25] <infinity> (except for some Canonical projects that have gone snap-only)
[05:25] <rbasak> (whether it ships or doesn't ship snaps by default, that is)
[05:26] <rbasak> infinity: they're still effectively third party to Ubuntu though.
[05:26] <rbasak> Layered on top of the OS rather than part of it.
[05:26] <infinity> rbasak: Well, yes.
[05:26] <infinity> With the exception of subiquity...
[05:26] <infinity> Where it's hard to say with a straight face that your installer is "3rd party".
[05:26] <rbasak> "primarily"
[05:26] <Ukikie> subiquity isn't packaged? 0_o
[05:27] <Ukikie> Seems to be, hm.
[05:27] <tsimonq2> rbasak: So why would we ship a daemon that we don't plan on utilizing? People can install snapd if they want.
[05:27] <rbasak> Who's "we"? You as developers or your users?
[05:28] <rbasak> In any case, note that I'm not arguing for or against whether Lubuntu should seed snapd.
[05:28] <tsimonq2> Us as Lubuntu developers.
[05:28] <rbasak> I'm just rubbishing your argument that it has anything to do with whether a flavour by default ships any snaps or not.
[05:29] <infinity> Ukikie: The version in the archive isn't what's used for the images (and looks ancient and should probably be removed)
[05:29] <Ukikie> That sounds less than ideal.
[05:29] <rbasak> I'd also argue that a decision should have everything to do with what's best for your users. Rather than what developers need.
[05:30] <infinity> I have no issues will pulling it out of desktop-common and putting it in everyone's desktop seeds instead (except lubuntu).  I'm more curious about if slangasek got concensus before adding it.
[05:31] <Ukikie> (As Xubuntu this time) Last I had heard during the video call/discussion, it was going to be discussed whether it would be opt-in or not.  That never happened that I saw and just ended up required. :/
[05:31] <tsimonq2> rbasak: The "mission" of Lubuntu is to be useful for people with lower end hardware or for people who want to get a speed boost on their existing machine. I don't believe snapd fits that.
[05:32] <rbasak> tsimonq2: now that's a valid argument. Though I'm still staying neutral; nothing to do with me :)
[05:32] <infinity> I was about to say that arugment made no sense to me. ;)
[05:32] <tsimonq2> infinity: I see no mailing list discussion on ubuntu-devel-discuss, ubuntu-release, or ubuntu-devel at the time this change was made. Although that's not everywhere it could have been discussed, those are typically the places, no?
[05:32] <infinity> Hrm, except maybe from a memory footprint perspecive.
[05:32] <infinity> tsimonq2: Yeah, that's where I looked and also found nothing. :P
[05:33] <rbasak> infinity: yeah memory footprint is what I was thinking.
[05:33] <rbasak> (also possibly disk footprint)
[05:33] <rbasak> Though that is perhaps only relevant to whether users would install snaps, rather than whether the mere presence of snapd is desirable.
[05:34] <tsimonq2> infinity: Memory footprint, the fact that it uses All The Loopback Devices, LXQt/LXDE and other Lubuntu upstreams aren't fast enough to really need Snaps, etc.
[05:34] <rbasak> But if the philosophy is to have nothing by default, then that's also valid.
[05:34] <infinity> tsimonq2: The loop mounts only come in to play when someone installs a snap.
[05:34] <infinity> At which point, the user has made a decision.
[05:35] <tsimonq2> rbasak: I guess by that same point, we should also install every other popular daemon that allows people to install software, no? Because then it gives everyone all the options... :P
[05:35]  * tsimonq2 shrugs
[05:35] <infinity> Anyhow, I honestly don't care if you want to remove it.  But if a flavour doesn't want it, it shouldn't be in common.
[05:35] <infinity> So we should sort that.
[05:35] <tsimonq2> Alright.
[05:36] <Ukikie> Xubuntu wasn't thrilled about the late breaking font changes, IIRC.
[05:36] <infinity> (There's also the reality that Canonical owns all the *buntu brands, and Mark could tell you that you want snapd and there's nothing you can do about it, but I'm pretty sure that's not what happened here)
[05:37] <infinity> I mean, there are certainly bits of the system we won't let you remove while still using that brand.
[05:37] <Ukikie> And to be fair, snap is Ubuntu's homegrown system, so it's a little more than any random like flatpak.
[05:37] <tsimonq2> Ukikie: Then out of curiosity, why did nobody respond on behalf of Xubuntu when Jeremy sent the email to ubuntu-release?
[05:38] <Ukikie> tsimonq2: Because not everything can be caught at the last minute. :)
[05:39] <slangasek> infinity: no, that wasn't based on a consensus discussion with the flavors, it was a fiat that this is now part of the Ubuntu platform
[05:39] <tsimonq2> ...huh?
[05:39] <tsimonq2> Ukikie: Ah, ok.
[05:39] <infinity> slangasek: Was it?  Kay.  I don't remember that happening either.  I remember a few flavours adding it of their own free will, and then it ended up in -common, but I assumed people were asked before that.
[05:40] <infinity> Assumed incorrectly, as it turns out.
[05:40] <tsimonq2> Well Lubuntu still won't pull it in because we don't have recommends enabled.
[05:40] <tsimonq2> But I'm curious about whether that came from Mark or somewhere else...
[05:41] <infinity> Which is a bug, not a feature. :P
[05:41] <infinity> A bug I hate working around.
[05:41] <tsimonq2> A bug that, now that this is a thing, makes me less eager to solve. :P
[05:43] <slangasek> you cite memory footprint; would that be addressed by having snapd shut itself down after boot if there were no snaps installed, and be socket activated after that?
[05:44] <slangasek> (lubuntu is not the only Ubuntu that cares about memory footprint; the above sounds like a good general enhancement)
[05:47] <rbasak> I have always wondered why snapd doesn't do that.
[05:47] <tsimonq2> slangasek: Sure, if snapd was not enabled or used at all whatsoever, then I wouldn't care because it would just be taking up disk space at that point.
[05:47] <tsimonq2> (you know, if Snaps weren't installed by default at all)
[05:49] <tsimonq2> One thing I'm wondering about down the road is if any Snaps will be a core part of Ubuntu in that it would be part of the platform. That's the slippery slope I don't want to lead in to.
[05:51] <slangasek> tsimonq2: no flavor would be forced to include software packaged as snaps; even if Canonical thinks Ubuntu users are better served by having a particular package as a snap instead of a deb, flavors can always continue maintaining a deb in the archive
[05:52] <tsimonq2> slangasek: Alright, cool. But seeing how things are moving, do you think it will stay that way?
[05:53] <slangasek> what I do think matters is to preserve consistency when users go to install packages, across flavors.  As we start to see more and more new software as snap-only, and more instructions to 'snap install', I think it matters to have this work everywhere
[05:57] <slangasek> tsimonq2: I see no reason to believe that would ever change.  And anyway, by the time you had an Ubuntu that you couldn't build from debs, I'm not sure there'd be much of a "flavor" story at all
[05:57] <tsimonq2> Sure, and assuming snapd can stay completely out of the way when not used (as talked about before), I have no problem with having snapd installed by default for people to be able to do that; even if I don't support Snaps as a platform, for consistency, I really don't care, go ahead.
[05:58] <tsimonq2> slangasek: You wouldn't have Linux distributions then, you'd have "upstream" (probably)...
[05:58] <slangasek> tsimonq2: do you want to file a bug on the snapd package about the auto-shutdown question?
[05:58] <tsimonq2> slangasek: Sure.
[06:10] <tsimonq2> slangasek: bug 1730159
[06:23] <tsimonq2> slangasek: And out of curiosity, back to snapd being in desktop-common... is that final or still up for discussion?
[06:30] -queuebot:#ubuntu-release- New binary: haskell-tasty-golden [i386] (trusty-proposed/universe) [2.2.0.2-1] (no packageset)
[06:40] <slangasek> tsimonq2: rarely is any decision final; you should feel free to raise a question to the Tech Board for example if you think this needs review
[06:40] <tsimonq2> slangasek: Alright, thanks.
[13:07] <Laney> infinity: slangasek: I'm seeing https://paste.ubuntu.com/25894759/ taking out workers in lcy01 - no time to investigate right now but if you're around it'd be good to check it out
[13:07] <Laney> ubuntu@juju-prod-ues-proposed-migration-machine-3:~$ systemctl list-units autopkgtest@lcy01* --state=inactive -a
[13:07] <Laney> [...]
[13:07] <Laney> 18 loaded units listed.
[13:08] <Laney> Seems to only(?) be affecting lcy01
[15:53] -queuebot:#ubuntu-release- Unapproved: mate-applets (zesty-proposed/universe) [1.18.1-0ubuntu1 => 1.18.1-0ubuntu1.1] (ubuntu-mate)
[16:33] -queuebot:#ubuntu-release- Unapproved: yubioath-desktop (xenial-proposed/universe) [2.3.0-1 => 2.3.0-1ubuntu0.1] (no packageset)
[16:36]  * tsimonq2 slides a $drink to whoever is on SRU duty on Monday
[17:46] <slangasek> haskell-shake failed its testsuite on ppc64el on rebuild; that looks like it'll need some investigating
[20:14] <xnox> infinity, i was calculating on the envelope our tests will run for like one more week, without any backlog being added.