=== rbalint_ is now known as rbalint [00:35] 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] (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] 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] 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] OK [00:37] THanks [00:42] rbasak: How often do Git imports run? [00:42] (I'm asusming it's in a cronjob, right?) [00:42] *assuming [00:52] tsimonq2: there's a "daemon" that watches Launchpad publications [00:53] 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] rbasak: Ah. [00:54] Thanks. [03:11] 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] 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] Older in xenial than trusty: dh-golang [03:11] Older in artful than xenial: fuse-umfuse-ext2 libclc libdrm mesa patch python-pyvmomi snapcraft wireless-regdb [03:11] Older in bionic than xenial: fuse-umfuse-ext2 linux-meta-azure mesa nvidia-graphics-drivers-384 [03:11] Older in bionic than artful: libvorbisidec nvidia-graphics-drivers-384 [03:11] 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] 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] 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] andersk: I must ask though, what script did you write for this? [03:21] https://loki.unit193.net/test_versions.py is mine, but it's designed for other uses not specifically testing upgrade paths. [03:32] It’s a similar quick Python script: https://gist.github.com/andersk/72bf1e03fb5c8fff0b13e3dc497d85cd [03:37] Neat. [11:24] tyhicks, hello, can we please have fscrypt merged / synced from Debian? [11:24] maybe the new version fixes the testsuite [11:26] (yes, it should fix it) [14:16] 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] doko, thus when i come back, i will work on fixing all of those. [14:16] doko, as part of the 1.67 transition [14:16] doko, it's in NEW queue for both ubuntu & debian. [14:16] doko, (just the boost1.67, not the update to the defaults yet) [16:20] LocutusOfBorg: hey - thanks for the ping - it looks like a merge and possibly a sync is possible [16:22] 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] 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] 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] 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] tyhicks: just make sure there are no reverse depends on it, then you can drop it, yes [17:19] mdeslaur: ah, I hadn't thought about that (shouldn't be in this case but I'll make sure) [17:19] thanks! [17:19] np [17:19] and reverse-build-depends [17:20] * tyhicks nods [17:20] all good [20:34] 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] the change: https://launchpadlibrarian.net/370383936/sssd_1.16.1-1ubuntu2_1.16.1-1ubuntu3.diff.gz [20:37] it's also adding an init file, not mentioned in the changelog [21:52] anyone know how to get at the unix username of the user building the package inside debian/rules..? [21:54] Snow-Man: ... whoami ? [21:54] tried that [21:55] more specifically: "export USER=$(whoami)" at the beginning of debian/rules [21:55] OK? [21:55] well, it didn't work.. [21:56] as in $USER is empty or wrong or what? [21:57] $(USER) ends up being empty [21:58] $USER just gives SER [21:58] specifically trying to fix this: https://buildd.debian.org/status/package.php?p=pgbackrest [21:59] essentially need to do: `sed -i 's/vagrant/$USER/g' /backrest/doc/resource/exe.cache` [22:00] also tried $(LOGNAME) but no joy there [22:01] 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] elmo: thought $(USER) would work (have been trying both $USER and $(USER)...), but lemme try $$USER... [22:13] ended up having to use $$(whoami), but that worked! thanks much elmo! [22:13] Snow-Man: no worries [22:24] 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] Snow-Man: $USER works because it's pre-set in the build environment, which isn't a particularly robust assumption to make [22:26] $$USER rather [22:28] $$(whoami) seems like a reasonable approach though and is probably what I'd do if there's only one occurrence [22:28] yea, this is temporary [22:28] and there's only one case of it [22:28] We should be able to eliminate the need for it in the next version [22:28] ack