| === rbalint_ is now known as rbalint | ||
| 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:35 |
|---|---|---|
| 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:37 |
| 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:42 |
| rbasak | tsimonq2: there's a "daemon" that watches Launchpad publications | 00:52 |
| 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:53 |
| tsimonq2 | rbasak: Ah. | 00:54 |
| tsimonq2 | Thanks. | 00:54 |
| 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:11 |
| 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:13 |
| 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:19 |
| Unit193 | andersk: I must ask though, what script did you write for this? | 03:20 |
| Unit193 | https://loki.unit193.net/test_versions.py is mine, but it's designed for other uses not specifically testing upgrade paths. | 03:21 |
| andersk | It’s a similar quick Python script: https://gist.github.com/andersk/72bf1e03fb5c8fff0b13e3dc497d85cd | 03:32 |
| Unit193 | Neat. | 03:37 |
| LocutusOfBorg | tyhicks, hello, can we please have fscrypt merged / synced from Debian? | 11:24 |
| LocutusOfBorg | maybe the new version fixes the testsuite | 11:24 |
| LocutusOfBorg | (yes, it should fix it) | 11:26 |
| 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) | 14:16 |
| tyhicks | LocutusOfBorg: hey - thanks for the ping - it looks like a merge and possibly a sync is possible | 16:20 |
| 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:22 |
| 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:23 |
| 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? | 16:24 |
| mdeslaur | tyhicks: just make sure there are no reverse depends on it, then you can drop it, yes | 17:18 |
| 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:19 |
| * tyhicks nods | 17:20 | |
| tyhicks | all good | 17:20 |
| 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:34 |
| ahasenack | it's also adding an init file, not mentioned in the changelog | 20:37 |
| Snow-Man | anyone know how to get at the unix username of the user building the package inside debian/rules..? | 21:52 |
| elmo | Snow-Man: ... whoami ? | 21:54 |
| Snow-Man | tried that | 21:54 |
| 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:55 |
| elmo | as in $USER is empty or wrong or what? | 21:56 |
| Snow-Man | $(USER) ends up being empty | 21:57 |
| 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:58 |
| Snow-Man | essentially need to do: `sed -i 's/vagrant/$USER/g' /backrest/doc/resource/exe.cache` | 21:59 |
| Snow-Man | also tried $(LOGNAME) but no joy there | 22:00 |
| 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:01 |
| Snow-Man | ended up having to use $$(whoami), but that worked! thanks much elmo! | 22:13 |
| elmo | Snow-Man: no worries | 22:13 |
| 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:24 |
| 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:26 |
| 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 | 22:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!