[01:04] <vorlon> cjwatson: sorry, just now had a chance to look in on the livecd-rootfs SRU status and just had to mark one of the bugs v-failed.  I defer further questions to sil2100 (for the arm rpi bug) and platonical (for the snap manifests), as I'm on sprint travel from tomorrow
[15:42] <Raboo> Any ubuntu dev eager to do a good friday deed of the day?
[15:44] <Raboo> this bug https://bugs.launchpad.net/ubuntu/+source/biosdevname/+bug/1535045 have a solution since January 2016. But it's still not applied. Could a friendly soul perhaps apply the fix and resolve the bug?
[15:45] <Raboo> or perhaps just push a newer release of biosdevname to the repositories as the bug is also fixed there.
[15:52] <Laney> anyone looked into emacs/ppc64el ftbfs?
[15:53] <Raboo> or would that be something I could do somehow?
[17:04] <gQuigs> does anyone have any scripts to find the least recently uploaded Ubuntu packages (bonus if it only considers actual source changes).  I'm curious if anyone is auditing the old packages we don't import for Debian - and happy to do some work to that end.
[17:06] <mdeslaur> gQuigs: merges.u.c has a "days old" column
[17:15] <superm1> bdmurray, regarding SRU bug 1785165, before the holiday it was rejected due to the changelog missing a # in the fixes by.  can you re-review it when you get a chance?  I uploaded again a few weeks ago
[17:16] <gQuigs> mdeslaur: that's just for packages that exist in Debian though right?  how about packages uploaded only to Ubuntu - example elastichosts-utils (uploaded last in 2019)
[17:24] <jbicha> nobody's auditing that :(
[17:25] <jbicha> there are some interesting links in the Derived from Buster section of https://launchpad.net/ubuntu/disco ("only in Disco" is part of what you want…
[17:25] <jbicha> but it's noisy: some packages we want are removed from Testing but are still in Unstable)
[17:26] <jbicha> https://wiki.debian.org/UltimateDebianDatabase is really powerful but it's a bit awkward to use
[17:29] <jbicha> I personally would really appreciate it if you're able to build a report for packages unique to Ubuntu
[17:30] <jbicha> Some of those packages should be uploaded to Debian. Some are unmaintained and we should just remove them.
[17:47] <Laney> http://qa.ubuntuwire.org/neglected/
[17:48]  * Laney attempts to tab complete gQuigs and fails
[17:51] <jbicha> thanks, I wonder why it doesn't pick up https://launchpad.net/ubuntu/+source/system-integrity-check (2007)
[17:52] <Laney> code's in the footer
[22:24] <sivang> hi all
[22:25] <sivang> are snaps what's used to install the bare gui-less, console providing parts of Ubuntu now days?
[22:26]  * sivang tries to understand if snaps are either mendatory or optional part of the distro nowdays.
[22:34] <JackFrost> sivang: Optional.
[22:35] <sivang> JackFrost: cool, so no part of i.e. ubuntu 18.10 core requires it?
[22:36] <JackFrost> sivang: A minimal install doesn't need it, though generally has it installed.  I have a desktop system, I don't have snapd.
[22:36] <sivang> JackFrost: are there any parts that may require it for a non-minial / GUI install?
[22:37] <gQuigs> sivang: key services that need snaps are LXD (included by default) and livepatch.  on the desktop a few GUI apps were switched but still provided as debs (for now)
[22:37] <JackFrost> sivang: I believe chromium, but I could be wrong on that.
[22:38] <JackFrost> (I use lxc because it's the only one in the repos.)
[22:38] <valorie> JackFrost: are you anti-snap?
[22:38] <JackFrost> valorie: Yes.
[22:38] <valorie> so's tsimonq2
[22:38] <valorie> or was at least
[22:38] <sivang> gQuigs: so development effort indeed goes to eventually replace libapt?
[22:39] <valorie> I see no reason not to see how it goes over time
[22:39] <tsimonq2> valorie: Somewhat.
[22:39] <tsimonq2> Cool idea.
[22:39] <valorie> might beat out flatpack/appimage
[22:40] <tsimonq2> I refuse to ship any in the default installation of Lubuntu though, but I also refuse to ship flatpaks and appimages.
[22:40] <gQuigs> sivang: there's no timeframe that I know of / or more plans that I've seen to switch over more (except chromium as mentioned)
[22:40] <tsimonq2> gQuigs: Well, and LXD.
[22:40] <sivang> gQuigs: I see, thanks for the info
[22:40] <tsimonq2> Oh.
[22:40] <valorie> I see no reason for Kub. to ship them, but people can enable all of them in Discover
[22:40] <valorie> if they want
[22:40] <tsimonq2> Yeah, you commented above. :)
[22:40] <tsimonq2> valorie: +1
[22:40] <tsimonq2> If people want to install them, I won't stop them.
[22:41] <tsimonq2> But I also don't want to stop them from installing any other "universal" formar.
[22:41] <tsimonq2> *format
[22:41] <valorie> competition can be healthy
[22:41] <tsimonq2> Nothing against the snap guys, they're great, but several things need to be solved first.
[22:41] <tsimonq2> (and gals)
[22:42] <sivang> so livepatch is like Mac updates nowdays? (disclaimer: I've been away from the -devel community for a long while now)
[22:42] <gQuigs> sivang: no idea...  it's just for kernel - https://auth.livepatch.canonical.com/
[22:43] <tsimonq2> On a related note, I wish Ubuntu Members could get access to ESM, but I doubt that will ever happen.
[22:43] <gQuigs> Firefox as a snap is almost there that I'd want to see it as the default..  just a few more snap fixes... Shameless plug: https://bryanquigley.com/posts/mindshare/snap-firefox-initial.html
[22:44] <tsimonq2> gQuigs: Are file downloads working?
[22:44] <tsimonq2> Last I used it you couldn't download files, which was a dealbreaker.
[22:44] <gQuigs> tsimonq2: why ESM?  you want to run 12.04 (non-desktop)?
[22:44] <tsimonq2> gQuigs: Yes.
[22:45] <tsimonq2> I may or may not still have a 12.04 server somewhere, I won't say for sure. :P
[22:45] <tsimonq2> ESM's a bit on the expensive side for me.
[22:45] <JackFrost> Would firefox be offered as a snap alongside firefox in normal repos?
[22:46] <tsimonq2> JackFrost: Seeing what they did with Chromium, probably not.
[22:46] <JackFrost> tsimonq2: Yeah I still backport $pkg for a friend to precise, and it has about ~100 downloads according to PPA stats.  Right, then that's when I either hold an old firefox, grab Debian's, or move to Debian. :P
[22:48] <gQuigs> tsimonq2: honestly, I don't think anyone though Ubuntu Members would be interested..  if you can convince the right people to add it as a membership benefit (likely 3 machine limit or some such), I'll volunteer to provision it
[22:48] <gQuigs> Firefox and Chromium are both offered in both apt/snaps right now ... right?
[22:49] <tsimonq2> gQuigs: Who would need convincing?
[22:49] <sivang> so apps runs as a complete seperate cgroup'd virtual appliance through snaps?
[22:49] <tsimonq2> I also happen to be on the Ubuntu Membership Board, I could pitch it to the board. :)
[22:49] <JackFrost> gQuigs: Yes to the former, looks like it to the later.
[22:50] <gQuigs> tsimonq2: that sounds like a start
[22:50] <tsimonq2> gQuigs: Cool, mind if I carbon-copy you on the email?
[22:51] <gQuigs> tsimonq2: sure
[22:51] <sivang> JackFrost: why are you anti-snap btw? My own concerns are that those self contained volumes tend to get scattered with different users of a large server machines in an academic setup , or maybe I'm missing something. Clearly the IoT use case is indeed well defined.
[22:51] <tsimonq2> They're hard to package.
[22:51] <gQuigs> tsimonq2: as for downloading it works, with caveats:  seperates.. the Downloads folder for the snap to a snap specific one at ~/snap/firefox/common/Downloads
[22:52] <tsimonq2> gQuigs: Uff.
[22:52] <JackFrost> sivang: There's a few reasons, I never actually wrote them down though.
[22:53] <gQuigs> and it won't let you open most apps directly from Firefox - have to open the folder first, I'm guessing that's part of the sandboxing..
[22:55] <sivang> JackFrost: I just feel they're well suited for embedded development (which I have extensive experience in) and not too much further, under the assumption that having entire system comprised out of them won't be a burden on the process containerment Kerlen mechanism (e.g. core system components, trusted and delivered as a bundle should probably not be concenred with being sandboxed / contained)
[22:55] <sivang> *Kernel
[22:56] <gQuigs> sivang: " self contained volumes tend to get scattered with different users"  I don't understand that.   more users shouldn't mean more snap "volumes", just more snaps would do that
[23:00] <sivang> gQuigs: so with Mac administration at a university, people downloaded duplicates of MacOS's .img volumes for the same apps (incl. academic software servers and cmd line utils) at different accounts, can this happen with snaps?
[23:01] <sivang> s/.img/.dmg/
[23:04] <gQuigs> sivang: I don't believe so;  give them a try - they don't bite - promise.  And if you really don't like them you can always purge snapd
[23:07] <sivang> gQuigs: are they easier to create to distribute your own software than deb packages?
[23:08] <tsimonq2> I personally say "no" but YMMV.
[23:09] <sarnold> the last time I put a snap together I had it built from scratch in about ten minutes; I haven't been brave enough to try packaging a deb from scratch yet :)
[23:10] <sivang> tsimonq2: can provide specific example?
[23:11] <tsimonq2> sarnold: Takes about the same time. :)
[23:11] <tsimonq2> :P
[23:11] <tsimonq2> sivang: Confinement was tricky last time I tried it.
[23:11] <sarnold> tsimonq2: heh :)
[23:11] <tsimonq2> I would encourage you to try it yourself.
[23:11] <gQuigs> sivang: depends on what you are trying to snap..
[23:12] <sivang> sarnold: well, with debhelper things can be just as quick, and that old what-you-call it system that does 10kg of magic with just a few .mk includes.. CDBS?
[23:12] <tsimonq2> gQuigs: +1
[23:12] <tsimonq2> sivang: Eew.
[23:13] <sarnold> sivang: I think modern debhelper does much the same with less cursing :)
[23:13] <sivang> python software, services and Qt/QML apps?
[23:13] <sivang> sarnold: I had hope it to become so one day last time I've visited this channel as a `main` uploader :)
[23:13] <sivang> *hoped
[23:13] <sarnold> hehe
[23:13] <gQuigs> I snapped a python program almost instantly (cause it was written right for pip)..  and one I wrote myself that does more complicated things - I'm still working on
[23:13] <JackFrost> sarnold: And less breaking with dh compat 11+
[23:14] <tsimonq2> Speaking of that, Disco users can enjoy debhelper 12 as of today. :)
[23:14] <sivang> gQuigs: can evaulate something like https://github.com/sivang/laten-fw ?
[23:14] <gQuigs> sivang: https://docs.snapcraft.io/creating-a-snap/6799
[23:15] <JackFrost> I'm not sure about snap, but thanks to aptly, reprepro, mini-dinstall you can have your own private repo for the packages you create too.
[23:15] <sivang> JackFrost: reprepo FTW!
[23:16] <sivang> tsimonq2: wawo debhelper 12.. It's been too much time since I created a package for Ubuntu :p
[23:19] <gQuigs> sivang: worth a shot - https://docs.snapcraft.io/python-apps/6741  I'm far far far from  snap packaging expert..
[23:19] <gQuigs> #snapcraft might be of more help
[23:22] <sivang> k, cool, thanks guys (or gals if any are around)
[23:23] <sivang> Oh my, 20 minutes are a lot these days :p