[00:35] <rbasak> slangasek: I've been asked to look at the MAAS SRUs in the queue. What's the status of the MAAS SRU exception please? Is it approved? I found https://wiki.ubuntu.com/MAASUpdates but it doesn't seem to be endorsed or linked from https://wiki.ubuntu.com/StableReleaseUpdates
[00:37] <rbasak> (I'm aware I could review, negotiate and approve myself, but I'd prefer to go with whatever is already being done rather than do it all again)
[00:37] <slangasek> rbasak: correct, it has not been signed off on as a standing exception.  infinity has the ball on getting that done.  SRU Team always has the authority to make one-off exceptions, the standing exception just saves us time and avoids inconsistent handling
[00:37] <slangasek> rbasak: that wiki page is not approved, but I'd say it's getting close, so maybe you want to review it yourself by way of assessing the SRU
[00:37] <rbasak> OK
[00:37] <rbasak> THanks
[00:42] <tsimonq2> rbasak: How often do Git imports run?
[00:42] <tsimonq2> (I'm asusming it's in a cronjob, right?)
[00:42] <tsimonq2> *assuming
[00:52] <rbasak> tsimonq2: there's a "daemon" that watches Launchpad publications
[00:53] <rbasak> It's not currently very smart. In theory it should pick up on things in thirty minutes. In reality an actual import could take longer if it falls behind (eg. a large number of new publications). Right now it's recovering from an outage.
[00:54] <tsimonq2> rbasak: Ah.
[00:54] <tsimonq2> Thanks.
[03:11] <andersk> I feel like there ought to be an automated check for version monotonicity across Ubuntu releases.  Having just written a script for this, I found:
[03:11] <andersk> Older in trusty than precise: language-pack-hne language-pack-hne-base language-pack-hsb language-pack-hsb-base language-pack-ss language-pack-ss-base
[03:11] <andersk> Older in xenial than trusty: dh-golang
[03:11] <andersk> Older in artful than xenial: fuse-umfuse-ext2 libclc libdrm mesa patch python-pyvmomi snapcraft wireless-regdb
[03:11] <andersk> Older in bionic than xenial: fuse-umfuse-ext2 linux-meta-azure mesa nvidia-graphics-drivers-384
[03:11] <andersk> Older in bionic than artful: libvorbisidec nvidia-graphics-drivers-384
[03:11] <andersk> Older in cosmic than bionic: firefox gnupg2 gst-plugins-bad1.0 gstreamer-vaapi imagemagick libarchive-zip-perl linux linux-meta-raspi2 linux-raspi2 linux-signed llvm-defaults perl php7.2 snapcraft swauth thunderbird
[03:13] <andersk> The mesa discrepancy in particular seems to be interfering with upgrades on a machine with both xenial and bionic sources, and I’d guess it might be causing upgrades to fail.
[03:19] <Unit193> andersk: Every upgrade I end up with local packages because people can't keep the upgrade path intact, and while I wouldn't mind that in PPA's so much I do mind in the official Ubuntu archive.
[03:20] <Unit193> andersk: I must ask though, what script did you write for this?
[03:21] <Unit193> https://loki.unit193.net/test_versions.py is mine, but it's designed for other uses not specifically testing upgrade paths.
[03:32] <andersk> It’s a similar quick Python script: https://gist.github.com/andersk/72bf1e03fb5c8fff0b13e3dc497d85cd
[03:37] <Unit193> Neat.
[11:24] <LocutusOfBorg> tyhicks, hello, can we please have fscrypt merged / synced from Debian?
[11:24] <LocutusOfBorg> maybe the new version fixes the testsuite
[11:26] <LocutusOfBorg> (yes, it should fix it)
[14:16] <xnox> doko, because boost upstream changed how they abi tag python-like libraries, i doubt anything in debian/ubuntu will know how to actually build against both 36 and 37 variants of the libs.
[14:16] <xnox> doko, thus when i come back, i will work on fixing all of those.
[14:16] <xnox> doko, as part of the 1.67 transition
[14:16] <xnox> doko, it's in NEW queue for both ubuntu & debian.
[14:16] <xnox> doko, (just the boost1.67, not the update to the defaults yet)
[16:20] <tyhicks> LocutusOfBorg: hey - thanks for the ping - it looks like a merge and possibly a sync is possible
[16:22] <tyhicks> general question for #ubuntu-devel... the fscrypt package that I uploaded directly to bionic (and that cosmic inherited) built the golang-github-google-fscrypt-dev binary package which is the source tree of the fscrypt project (many go package seem to do this)
[16:23] <tyhicks> Debian fscrypt source package comments out that binary package from the control file: https://salsa.debian.org/go-team/packages/fscrypt/blob/debian/sid/debian/control#L57
[16:24] <tyhicks> I'd like to simply sync the package from Debian but anyone with that package installed will be left with the old version
[16:24] <tyhicks> I don't think that's a problem, especially considering what the binary package is, but can someone confirm that we can just not build that binary package in cosmic without any problem?
[17:18] <mdeslaur> tyhicks: just make sure there are no reverse depends on it, then you can drop it, yes
[17:19] <tyhicks> mdeslaur: ah, I hadn't thought about that (shouldn't be in this case but I'll make sure)
[17:19] <tyhicks> thanks!
[17:19] <mdeslaur> np
[17:19] <mdeslaur> and reverse-build-depends
[17:20]  * tyhicks nods
[17:20] <tyhicks> all good
[20:34] <ahasenack> doko: hi, what was that sssd /usr/local change? It is failing to build now: https://launchpadlibrarian.net/377463205/buildlog_ubuntu-cosmic-amd64.sssd_1.16.1-1ubuntu4~ppa1_BUILDING.txt.gz
[20:34] <ahasenack> the change: https://launchpadlibrarian.net/370383936/sssd_1.16.1-1ubuntu2_1.16.1-1ubuntu3.diff.gz
[20:37] <ahasenack> it's also adding an init file, not mentioned in the changelog
[21:52] <Snow-Man> anyone know how to get at the unix username of the user building the package inside debian/rules..?
[21:54] <elmo> Snow-Man: ... whoami ?
[21:54] <Snow-Man> tried that
[21:55] <Snow-Man> more specifically: "export USER=$(whoami)" at the beginning of debian/rules
[21:55] <elmo> OK?
[21:55] <Snow-Man> well, it didn't work..
[21:56] <elmo> as in $USER is empty or wrong or what?
[21:57] <Snow-Man> $(USER) ends up being empty
[21:58] <Snow-Man> $USER just gives SER
[21:58] <Snow-Man> specifically trying to fix this: https://buildd.debian.org/status/package.php?p=pgbackrest
[21:59] <Snow-Man> essentially need to do: `sed -i 's/vagrant/$USER/g' /backrest/doc/resource/exe.cache`
[22:00] <Snow-Man> also tried $(LOGNAME) but no joy there
[22:01] <elmo> Snow-Man: it's been a while since I did make files, but don't you need it to write it as $$USER  ?
[22:01] <Snow-Man> elmo: thought $(USER) would work (have been trying both $USER and $(USER)...), but lemme try $$USER...
[22:13] <Snow-Man> ended up having to use $$(whoami), but that worked!  thanks much elmo!
[22:13] <elmo> Snow-Man: no worries
[22:24] <cjwatson> Snow-Man: $(USER) would work if it were a make variable rather than a shell variable, in which case it would need to be assigned using $(shell whoami) rather than just $(whoami).  FWIW
[22:26] <cjwatson> Snow-Man: $USER works because it's pre-set in the build environment, which isn't a particularly robust assumption to make
[22:26] <cjwatson> $$USER rather
[22:28] <cjwatson> $$(whoami) seems like a reasonable approach though and is probably what I'd do if there's only one occurrence
[22:28] <Snow-Man> yea, this is temporary
[22:28] <Snow-Man> and there's only one case of it
[22:28] <Snow-Man> We should be able to eliminate the need for it in the next version
[22:28] <cjwatson> ack