[00:06] <joelkraehemann> thank you for releasing latest GSequencer :)
[00:06] <joelkraehemann> https://launchpad.net/ubuntu/+source/gsequencer/1.4.24-1
[00:44] <joelkraehemann> hi all
[00:45] <joelkraehemann> https://launchpad.net/builders/bos02-s390x-010
[00:45] <joelkraehemann> ^^ is this server still up?
[00:45] <joelkraehemann> I don't get any progress for half an hour
[00:52] <wgrant> joelkraehemann: All three architectures are stuck in the same place, so it looks like a package bug.
[00:52]  * wgrant wonders if whichever test runs after ags_functional_mixer_test tries to use the network or something like that.
[00:53] <sarnold> thanks wgrant, I didn't think to look for other architectures
[00:55] <joelkraehemann> there a few things linux doesn't like ...
[00:55] <joelkraehemann> like sigaction on SIGSEGV ?
[00:58] <flexiondotorg> krytarik: Thanks, that was it.
[01:00] <flexiondotorg> tsimonq2: FYI See earlier comment from k_rytarik
[01:01] <tsimonq2> flexiondotorg: ack
[01:04] <joelkraehemann> so it was the update hanging-up the VM?
[01:05] <joelkraehemann> can I restart the build?
[01:07] <joelkraehemann> I have canceled all builds
[01:09] <joelkraehemann> and started rebuild
[01:15] <infinity> flexiondotorg: Quirking things in the release-upgrader should be a last resort for bugs you can't fix (ie: because the bug exists in xenial and can't be easily worked around)
[01:15] <infinity> flexiondotorg: It's not a replacement for just making sure "apt-get dist-upgrade" DTRT in 99% of cases.
[01:15] <flexiondotorg> OK
[01:16] <flexiondotorg> What sort of bugs is it intended to workaround?
[01:16] <sarnold> does it break all those "looping triggers" bugs?
[01:17] <flexiondotorg> I was updating it to make sure some obsolete packages seeded in xenial and remove during the upgrade.
[01:17] <flexiondotorg> *are removed
[01:17] <infinity> flexiondotorg: Obsolete as in "no longer in the archive", or just "not part of foo-desktop anymore"?
[01:18] <flexiondotorg> Not part of ubuntu-mate-desktop any more, and...
[01:18] <infinity> flexiondotorg: Unseeded-but-still-in-the-archive shouldn't be removed by an upgrade.  A user might have been using it.
[01:18] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/topmenu-gtk/+bug/1744912
[01:18] <ubottu> Launchpad bug 1744912 in topmenu-gtk (Ubuntu) "Please remove topmenu-gtk from the Bionic archive" [Undecided,New]
[01:18] <infinity> flexiondotorg: If it *must* be removed, do to it breaking other things, that's for dpkg relationships to handle, not the release upgrader.
[01:18] <flexiondotorg> Those packages need ejecting. Very broken.
[01:18] <infinity> flexiondotorg: But if removed from the archive, release-upgrader already handles that in a second pass for all upgrades.
[01:19] <flexiondotorg> OK.
[01:19] <flexiondotorg> So if that removal request is processed I'm good?
[01:19] <infinity> Yeah.
[01:19] <flexiondotorg> Do all flavours need an entry in the release upgrader?
[01:20] <flexiondotorg> I don't see Budgie.
[01:20] <infinity> Pretty sure budgie is there.
[01:20] <infinity> Or maybe it was another flavour I added last cycle.
[01:22] <infinity> Or this cycle.
[01:22] <infinity> ubuntu-release-upgrader (1:18.04.8) bionic; urgency=medium
[01:22] <infinity>   * data/DistUpgrade.cfg: Add ubuntu-budgie-desktop support.
[01:22] <infinity>   * Run pre-build.sh to update mirrors.cfg and demoted.cfg.
[01:22] <infinity>  -- Adam Conrad <adconrad@ubuntu.com>  Mon, 05 Feb 2018 04:00:06 -0700
[01:22] <flexiondotorg> Actually, yeah, Just saw it.
[01:23] <joelkraehemann> wgrant: what is the command line of autopkgtest actually used?
[01:24] <joelkraehemann> ^^ excuse me pbuilder or alike?
[01:25] <infinity> flexiondotorg: Also, topmenu-gtk isn't in bionic?
[01:25] <flexiondotorg> Oh, did it get removed already?
[01:25] <flexiondotorg> It was there when that bug was raised.
[01:25] <infinity> flexiondotorg: Removed by Steve a month and a half ago when processing Debian removals.
[01:25] <flexiondotorg> But great.
[01:26] <flexiondotorg> Thanks infinity
[01:29] <wgrant> joelkraehemann: This isn't autopkgtest. Builds use sbuild.
[01:38] <flexiondotorg> infinity: https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-release-upgrader/ubuntu-mate-bionic-update/+merge/342372
[03:04] <joelkraehemann> wgrant: I don't think its a bug, just try add missing dependencies on data (files from different packages)
[03:13] <joelkraehemann> ags_functional_drum_test tries to open a not-existing directory
=== led_ir23 is now known as led_ir22
=== ackkk is now known as ackk
[10:43] <joelkraehemann> looking at the logs inside the schroot following message looks suspicious:
[10:43] <joelkraehemann_> Failed to create secure directory (/run/user/1000/pulse): No such file or directory
[10:45] <joelkraehemann> is it possible to run within a container rather then a schroot?
[11:26] <GunnarHj> wgrant: It was a fruitful discussion yesterday. Any chance you can take a look at the snapd import issue too?
[12:53] <joelkraehemann> I just run the test on a SLES 12.3 linux one instance it seems fine so far, no crash
[12:55] <joelkraehemann> I was using https://build.opensuse.org/package/show/home:jkraehemann/libinstpatch
[13:06] <joelkraehemann> now I try the libinstpatch version available in ubuntu
[13:08] <joelkraehemann> it crashes
[13:08] <joelkraehemann> actually, I can reproduce it
[13:13] <joelkraehemann> this is the bt http://codepad.org/mKZ5c5dA
[13:15] <ahasenack> tjaalton: hi,
[13:15] <ahasenack> tjaalton: so freeipa is doomed in bionic?
[13:16] <ahasenack> tjaalton: I found this thread: https://www.redhat.com/archives/freeipa-users/2017-February/msg00322.html
[13:16] <ahasenack> it looks like the /etc/httpd/alias -> /etc/apache2/nssdb is also not in certmonger
[13:19] <joelkraehemann> however, there was a critical warning before the line number of the SIGSEGV
[13:19] <joelkraehemann> (ags_functional_ffplayer_test:52633): libInstPatch-CRITICAL **: ipatch_container_get_children: assertion 'IPATCH_IS_CONTAINER (container)' failed
[13:23] <tjaalton> ahasenack: no, but it would need libnsspem anyway
[13:24] <joelkraehemann> for short, I have 2 versions one working the other not
[13:24] <ahasenack> tjaalton: do you know if a previous version of freeipa required that too?
[13:24] <joelkraehemann> !DIFF!
[13:24] <ahasenack> or we never saw it because it was never updated, and the setup script (which is the dep8 test) never ran?
[13:24] <tjaalton> ahasenack: it did
[13:25] <tjaalton> ahasenack: ah, no, new ipa server requires libnsspem now
[13:25] <tjaalton> before it was just the client to renew certs
[13:25] <tjaalton> which didn't work, obviously
[13:25] <ahasenack> so should the bionic version be reverted for now?
[13:25] <tjaalton> no
[13:25] <ahasenack> the situation now as I understand it is that it does not exist in bionic anymore
[13:26] <tjaalton> true
[13:26] <ahasenack> the package in proposed won't migrate
[13:26] <tjaalton> correct again
[13:26] <tjaalton> the release team will weigh in about nss-pem, and how it should be packaged, if at all
[13:27] <ahasenack> does it exist in debian?
[13:27] <tjaalton> no
[13:27] <ahasenack> I think it's broken there too
[13:27] <ahasenack> yep
[13:27] <ahasenack> with final freeze coming up next week, it looks like freeipa won't make it then
[13:27] <tjaalton> it's in universe
[13:28] <ahasenack> now it's not even there :)
[13:28] <tjaalton> right, but still, different rules
[13:28] <ahasenack> ah, wrt the freeze you mean?
[13:28] <tjaalton> right
[13:45] <GunnarHj> cjwatson, wgrant: I "fixed" bug #1758684 through a manual upload of the template. Possibly that's it, but I'm going to keep an eye on it when the package is uploaded next time.
[13:45] <ubottu> bug 1758684 in Ubuntu Translations "LP only imported a fraction of the snappy translation template" [High,In progress] https://launchpad.net/bugs/1758684
[13:49] <seb128> GunnarHj, what did you change/how did you generate the right template?
[13:50] <GunnarHj> seb128: I grabbed it from the tarball with stripped files. Didn't change anything.
[13:50] <seb128> GunnarHj, so it's identical to the one which is in the builddir after build?
[13:50] <GunnarHj> seb128: Yes.
[13:50] <seb128> but the after-build being imported is incomplete?
[13:51] <GunnarHj> seb128: Yes, so it was for some reason. Let's see what happens next time.
[13:51] <seb128> GunnarHj, and that happened on several uploads?
[13:52] <GunnarHj> seb128: Yes, a few I think. Haven't digged deep into the history. But artful has a reasonable number of strings.
[13:52] <seb128> that's weird
[13:52] <GunnarHj> yep
[13:52] <seb128> indeed https://launchpad.net/ubuntu/bionic/+upload/17785673/+files/snapd_2.32+18.04_amd64_translations.tar.gz has a complete pot
[13:53] <seb128> and uploading the same "by hand" works?
[13:53] <seb128> cjwatson, wgrant, you didn't switch launchpad to the new gettext yet, did you?
[13:53] <GunnarHj> seb128: Yes. And no complaints.
[13:54] <seb128> GunnarHj, https://translations.launchpad.net/ubuntu/bionic/+source/snapd/+imports has no older/other files than your manual upload
[13:54] <seb128> are you sure they made it to the import queue?
[13:54] <seb128> GunnarHj, I think it's another case where https://translations.launchpad.net/ubuntu/bionic/+source/snapd/+sharing-details is set to share with upstream so the template from the source isn't imported?
[13:55] <GunnarHj> seb128: Yes, I'm 100% sure they were there. They disappear after a while after having been imported.
[13:55] <seb128> k, weird
[13:57] <GunnarHj> seb128: I also saw that, but autosync isn't enabled. The affects of those sync settings isn't crystal clear to me.
[13:57] <seb128> yeah, it's confusing to me as well :/
[13:58] <cjwatson> seb128: no
[13:58] <seb128> cjwatson, ok, thanks
[13:58] <seb128> GunnarHj, well, I don't understand what's going on there then
[13:59] <GunnarHj> seb128: Well, correction I think. The *template* was imported. The PO files don't really need to be imported since we are upstream. The snapd project grabs the PO files from LP exports.
[13:59] <seb128> GunnarHj, the french translate page has a mention "These translations are shared with Snappy trunk series template snappy."
[14:00] <seb128> which points to https://translations.launchpad.net/snappy/trunk/+pots/snappy/fr
[14:00] <seb128> but that has 102 strings only
[14:00] <seb128> so something seems buggy/not configured as it should
[14:01] <GunnarHj> seb128: Indeed.
[14:01] <seb128> GunnarHj, https://github.com/snapcore/snapd/tree/master/po has no update for 5 months
[14:01] <seb128> so that seems buggy
[14:02] <seb128> GunnarHj, can you post about that / how are translations updated on https://forum.snapcraft.io/ ?
[14:03] <seb128> GunnarHj, I've a feeling translations is not something the snappy team is giving much attention to atm so the discussion/reminder might be useful
[14:04] <GunnarHj> seb128: I have precisely the same feeling. Sure, I can call their attention to it.
[14:06] <seb128> GunnarHj, thanks, I can follow up on the post as well
[14:06] <GunnarHj> seb128: Btw, this is the latest sync I noticed upstream:
[14:06] <GunnarHj> https://github.com/snapcore/snapd/pull/4053/commits/f884b3ba
[14:06] <GunnarHj> Don't know if they had exported from the LP project or the LP package, though.
[14:08] <seb128> GunnarHj, could be from https://code.launchpad.net/~snappy-dev/snappy/snappy-moved-to-github but it looks like things changed with the move to github so unsure how it's meant to work nowadays, the name of that branch suggests it's deprecated ... I think we need to talk to the snappy team, the forum is the right place
[14:09] <GunnarHj> seb128: Sure, it's on my list. :)
[14:09] <seb128> thx
[15:08] <seb128> stgraber, the lxd manpage seems buggy on the current bionic package, ".TH PANIC: "1" "March 2018" "panic: failed to configure SQLite replication" "User Commands""
[15:28] <stgraber> seb128: yeah, that's known
[15:28] <stgraber> seb128: help2man is unhappy with our --help, we'll switch to some other way to generate them
[15:35] <joelkraehemann> seb128: http://codepad.org/1pUsFFpl
[15:36] <joelkraehemann> ^^ this is a fix that is actually not in ubuntu
[15:42] <xnox> joelkraehemann, interesting
[15:47] <joelkraehemann> there some more changes available upstream actually not in ubuntu
[16:04] <joelkraehemann> just run the ubuntu libinstpatch version with the diff previously shared
[16:04] <joelkraehemann> and it works
[16:20] <joelkraehemann> I just reported on debian reportbug including the patch
[16:21] <joelkraehemann> Bug#894386
[16:24] <joelkraehemann> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894386
[16:24] <ubottu> Debian bug 894386 in src:libinstpatch "libinstpatch: memory corruption in file IpatchSF2Reader.c" [Normal,Open]
[17:24] <flexiondotorg> infinity: Thanks for the release upgrade review last night.
[17:24] <flexiondotorg> I've revised my merge proposal - https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-release-upgrader/ubuntu-mate-bionic-update/+merge/342372
[17:35] <TJ-> what would be the appropriate package to report an S3 resume bug that only happens when suspend was triggered by lid close. On resume the unlock/greeter is shown and I authenticate then when it switches to the user session the screen goes and remains black. Switching to other VTs works fine but the Xorg GUI remains black. No indications in any log files, expected processes still running
[17:37] <nacc> TJ-: taht sounds like the greeter itself? gdm maybe?
[17:37] <nacc> TJ-: given that the kernel is fine (it seems)
[17:38] <TJ-> nacc: it's after the greeter, when the user session is switched. there's a possible clue in "Failed to configure CRTC 63" !
[17:38] <nacc> TJ-: ah is taht from X?
[17:44] <TJ-> seems to be, I'm tracking it down
[17:59] <seb128> joelkraehemann, thanks, nice debugging!
[19:52] <rlink> I've just uploaded a debdiff to fix LP#1752306 for Xenial.  (already fakesync'd for Trusty and fixed in Bionic.)  Anyone around to take a peek?
[20:58] <nacc> rlink: i can
[20:58] <nacc> rlink: fyi, use LP: #1752306, the bot will link to it
[20:58] <ubottu> Launchpad bug 1752306 in xmltooling (Ubuntu Artful) "Security bug in XMLTooling-C before 1.6.4 [CVE-2018-0489]" [Undecided,Incomplete] https://launchpad.net/bugs/1752306
[21:00] <nacc> rlink: oh but you need security sponsoring
[21:01] <nacc> sarnold: --^ any advice?
[21:02] <nacc> smoser: re: https://code.launchpad.net/~smoser/ubuntu/+source/ssh-import-id/+git/ssh-import-id/+merge/342231, did you upload tag it first?
[21:04] <sarnold> nacc,rlink, cool, thanks
[21:04] <nacc> sarnold: thanks, i figure your team has to pick that up, right?
[21:05] <sarnold> nacc: right; whoever is on community on a given week will normally do it
[21:06] <nacc> sarnold: yep, thanks
[21:06] <sarnold> nacc: this week it's ratliff :) I don't know how she's doing on time for the day, so I can't promise anything
[21:24] <ratliff> rlink, sarnold: I'm working on it now
[21:25] <sarnold> cool! thanks ratliff :)
[21:26] <rlink> nacc, sarnold, ratliff: Thank you.
[21:26] <ratliff> rlink: thanks for providing the debdiff!
[21:27] <rlink> ratliff:  No prob.  I provided the last Xenial one for xmltooling, too, so I think I got everything right on the first try this time.  ;-)
[21:27] <ratliff> rlink: it looks good to me so far. do you have a way to test it if I put it in the security-proposed ppa?
[21:30] <rlink> ratliff:  Yes, but not until tomorrow.
[22:16] <sarnold> infinity: are webbrowser-app and mediascanner2.0 good candidates for the do-release-upgrade tool to remove on upgrading to 18.04 LTS? https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1756800
[22:16] <ubottu> Launchpad bug 1756800 in ubuntu-release-upgrader (Ubuntu) "Failed to start AppArmor initialization with status=123/n/a" [Undecided,Confirmed]
[22:17] <smoser> nacc: i did not push tag.
[22:50] <infinity> sarnold: The release upgrader should offer to remove both as "obsolete", since they've been removed from the archive.
[22:51] <infinity> sarnold: If they genuinely *break* something, and you want to force them off, the something broken by them should conflict and force them off.  Otherwise, users get a choice to keep old junk around.
[22:53] <infinity> sarnold: Ahh, and now that I've read the bug, release-upgrader removing things won't magically remove conffiles any better than a conflict will.
[22:53] <sarnold> infinity: hrm. On re-reading the bug it looks like it might be in part due to the packages being removed but not *purged*.
[22:54] <sarnold> infinity: thanks. I guess the best we can do is sob along with the users :/
[22:54] <infinity> sarnold: I think at least a versioned breaks (which is effectively a conflict, since there's no unbroken version in this case) is correct there.
[22:55] <infinity> sarnold: And then, due to the fact that you now have a dpkg relationship that says "we're doing evil things here with those old packages", the apparmor maintainer scripts could thwack those conffiles.
[22:56] <infinity> sarnold: It's not perfect, but it beats doing nothing.
[22:57] <infinity> sarnold: Anyhow, I disagree that an upgrading tool should be working around this when it could be solved at the package level.
[22:57] <sarnold> infinity: that scares me. I think you're right that it's probably better than nothing. But I'm still scared that fiddling with something like that this late in the cycle
[22:57] <infinity> sarnold: It's... Not that scary?
[22:57] <sarnold> infinity: it is to me :)
[22:58] <sarnold> it's been five years since I last goofed around with handling conffiles in maintainer scripts, and that was all from one package :)
[23:00] <sarnold> thanks infinity
[23:00] <infinity> sarnold: As a side note, if we haven't already, we should move to a world where apparmor profiles live in /lib/apparmor, and /etc/apparmor is used for user overrides.
[23:00] <infinity> sarnold: Which would sidestep this whole issue.
[23:02] <sarnold> infinity: yeah .. that's part of some recent work john is doing. hysterical raisins across ubuntu, debian, suse, snap, libvirt, lxd, make the whole thing a right mess :/
[23:03] <infinity> sarnold: One could also fix this current bug in apparmor proper by simply making it ignore #include statements that return ENOENT.
[23:04] <infinity> sarnold: Seems entirely reasonable to do opportunistic includes rather than requiring them to exist.
[23:04] <sarnold> we opted instead for #include_if_available or something similar to retain backward compatibility
[23:05] <infinity> sarnold: (Which is, actually, what this profile was doing, since it's including directories, so any argument that "lack of files should be an error to avoid injection trajectories" or some such is BS :P)
[23:06] <infinity> sarnold: I'm not sure how allowing ENOENT would break backward compat.  Can you honestly say with a straight face that anyone would rely on the behaviour "it won't load if the file isn't there" to perform some complex startup logic?
[23:06]  * infinity shrugs.
[23:07] <sarnold> if abstractions/base isn't there you're gonna have a bad time if the profiles load anyway
[23:09] <infinity> sarnold: Okay, that's fair.  Maybe.  Except that comes with apparmor, so it's very much a self-foot-shooting issue if you have apparmor but not that bit.
[23:09] <sarnold> infinity: yeah... it's just that there's cases where the profile should fail and cases where it shouldn't, so new behaviour gets a new name
[23:09] <infinity> sarnold: Anyhow, if those two packages are the only ones with this obsolete-conffiles-doing-includes issue, magling/deleting the files is much easier than changing behaviour.
[23:11] <sarnold> hrm. it would be nice to know if this is exhaustive list or not.
[23:12] <infinity> sarnold: Check Contents.amd64 for xenial (and maybe trusty, if you're feeling bored) for anything that ships files in /etc/apparmor.d, grab (or install) all debs, grep for include (or other things known to break on remove-but-not-purge), profit?
[23:13] <infinity> sarnold: I suppose the other middle road to the include issue could have been to make the behaviour different from <relative> and "absolute" includes, but maybe that would have been too magic.
[23:14] <infinity> (Since I suspect this class of bug probably only exists for "absolute" usage)
[23:17] <sarnold> infinity: I *think* that might have been raised as a possibility during discussion of the "include if exists" feature, but not selected ..
[23:18] <sarnold> infinity: thanks for the tip on Contents.amd64.
[23:18] <infinity> Fair enough.