[05:42] <Mirv> tsimonq2: btw if you wondered why there was some unneeded patches not in series files, that happened sometimes since I used a lot of automation like http://pastebin.ubuntu.com/25218283/ which might have added files for the upload that I was actually not committing to git :)
[05:43] <Mirv> if there was uncommitted cruft locally
[05:43] <Mirv> tsimonq2: anyway, really nice to see silo 2819! :)
[05:47] <Mirv> if I had so called free time, I'd start to be really happy to help but life is way too busy these days
[05:49] <tsimonq2> Mirv: Hey! :)
[05:50] <tsimonq2> Mirv: Yeah, just waiting on some package removals and we can land it :D
[05:52] <tsimonq2> I mean, the silo in and of itself *should* be ready to land. It just won't migrate from -proposed...
[05:54] <Mirv> "just" :D it'll be interesting to see if the migration will need some hinting this time or not. I'll gladly stare at update_output.txt with you.
[05:54] <Mirv> it's still painful to remember to Qt 5.6 migration
[05:56] <tsimonq2> hehehehe :)
[05:57] <tsimonq2> Mirv: yeah it might take some beating into submission to get through :P
[05:59] <tsimonq2> Mirv: Any suggestions, suggestions, and patches are more than welcome :)
[06:00] <tsimonq2> That's redundant. :P
[06:00] <tsimonq2> suggestions, help, patches, that's three words that make sense :P
[06:05] <Mirv> tsimonq2: from the PPA you're missing AFAIK at least gammaray (qtbase-abi), musescore (qtbase-abi) rebuilds
[06:06] <Mirv> checked with artful they still have those deps
[06:06] <tsimonq2> Mirv: Thank you
[06:07] <tsimonq2> Mirv: Do you still have permissions to copy packages there? I'm not a Core Developer and I've just been poking my usual (Core Developer) victim^Msponsor ;)
[06:13] <Mirv> tsimonq2: sure, I'm as core developer as before, just with much less time for Ubuntu ;)
[06:13] <tsimonq2> Mirv: Sure ;)
[06:16] <Mirv> tsimonq2: both uploaded, gammaray is something that often requires newer upstream version though
[06:16] <tsimonq2> Mirv: Oh, thanks. :)
[06:17] <tsimonq2> Mirv: I'm working on an updated telegram-desktop now
[06:36] <tsimonq2> Mirv: ... so build-essential being uninstallable made those builds fail ... what
[06:36] <tsimonq2> At least my Telegram build
[06:36]  * tsimonq2 retries
[06:40] <tsimonq2> Mirv: gammaray is FTBFS because we forgot to adjust the reverse dependencies for qt3d-assimpsceneio-plugin to the new package name
[06:40] <tsimonq2> Luckily this was caught early, I'll try to take care of it in my PPA
[07:08] <Mirv> tsimonq2: ok. I uploaded gammaray ~2 with that fixed. meanwhile musescore has some other problem you should look into at some point.
[07:12] <Mirv> (gammaray also seems to have another problem)
[07:13] <tsimonq2> Mirv: Sure.
[07:14] <tsimonq2> Mirv: Also, thanks :)
=== klebers_ is now known as klebers
[07:23] <Mirv> you're welcome!
[07:28] <sil2100> Mirv: \o/
[08:08] <Mirv> sil2100: o/
=== santa is now known as Guest62238
[08:41] <tsimonq2> Could someone from the SRU team please review bug 1641912?
[08:41] <ubottu> bug 1641912 in gtk+2.0 (Ubuntu Zesty) "Please backport two recent-manager patches" [Critical,In progress] https://launchpad.net/bugs/1641912
[09:26] <sil2100> tsimonq2: I could take a look in some moments
[09:27] <tsimonq2> sil2100: Thanks :)
[10:36] <rbalint> xnox, juliank: mvo did not reply but i think sponsoring the tagged u-u 0.94 would be better than another nmu we have to integrate
[10:37] <xnox> rbalint, 0.94 into debian, or ubuntu, or both?
[10:38] <juliank> rbalint: The commits needed for the download-only stuff so far are already cherry-picked in artful, zesty, and xenial
[10:38] <xnox> juliank, however, that is only half of the critical story. we have other clients waiting for the rest of rbalint's fixes.
[10:38] <juliank> I think mvo probably had a reason not to upload 0.94
[10:38] <juliank> true
[10:41] <rbalint> juliank, xnox: maybe he was waiting for test results, maybe he just does not have time
[10:41] <xnox> ogra, does mvo do irc these days at all?
[10:41] <xnox> see ^^^^^
[10:45] <juliank> Well, you can just upload 0.94~ubuntu1 or something in either case and sync 0.94 when mvo uploads it to Debian or whatever
[10:45] <rbalint> xnox: to debian, then we can sync it
[10:46] <ogra> xnox, if he is not on vacation (or molten because of the heat) he does, yes
[10:47] <ogra> (i think the first one is true atm )
[10:47] <juliank> Just do the ~ubuntu dance for 0.94, I don't think it's particularly nice to just upload it to Debian without mvo knowing
[10:48] <juliank> It's also a day faster this way
[10:48] <juliank> :D
[10:49] <xnox> juliank, checkout https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/1707880 i hate dh_systemd_start
[10:49] <ubottu> Launchpad bug 1707880 in debhelper (Ubuntu Zesty) "newly installed additional units are not started on upgrade" [Undecided,New]
[10:49] <rbalint> juliank: not for me, i can upload to debian only yet :-\
[10:51] <juliank> xnox: But that's a more general bug really, then
[10:54] <juliank> rbalint: Well, but others can :)
[10:58] <xnox> juliank, sure but i don't see how this can be fixed in dh-systemd itself. unless it injects things into preinst to detect new units that do get installed....
[11:03] <rbalint> juliank: if someone uploads 0.94~ubuntu1 to artful please note that the fix for LP: #1649709 is not included because i think it is not a bug and not forwarded it upstream
[11:03] <ubottu> Launchpad bug 1649709 in unattended-upgrades (Ubuntu) "unatttended-upgrades 0.92ubuntu3 installs all updates but update-manager is set to only install security automatically" [Medium,Fix released] https://launchpad.net/bugs/1649709
[11:05] <xnox> rbalint, what do you mean, it's not a bug?! =)
[11:06] <rbalint> xnox: i just fixed the description of  LP: #1649709
[11:06] <ubottu> Launchpad bug 1649709 in unattended-upgrades (Ubuntu) "unatttended-upgrades 0.92ubuntu3 installs all updates but update-manager is set to only install security automatically on development release" [Medium,Fix released] https://launchpad.net/bugs/1649709
[11:06] <xnox> rbalint, but:
[11:06] <xnox> / This option will controls whether the development release of Ubuntu will be
[11:06] <xnox> / upgraded automatically.
[11:06] <xnox> Unattended-Upgrade::DevRelease "false";
[11:06] <xnox> it got fixed by setting DevRelease to false, no?
[11:07] <xnox> (such that unattended upgrades does not upgrade on dev series)
[11:07] <rbalint> xnox: it is essentially removing u-u
[11:07] <xnox> yeah....
[11:07] <xnox> it has a sour taste to it.
[11:07] <rbalint> so the fix is redundant
[11:07] <xnox> and dev series, kind of, have to upgrade.
[11:07] <xnox> i guess we need to reopen that bug, and mark it as won't-fix or opinion, if we are reverting it.
[11:08] <rbalint> yes, but was waiting for bdmurray to comment first
[11:21] <infinity> xnox, rbalint: I disagree with both of you, it seems.
[11:21] <infinity> The claim that "users will get no upgrades" is BS.  update-manager still gives them upgrades.
[11:22] <infinity> But unattended-upgrades in a devel series, no matter how careful we are, has much more potential for breakage than in a stable series.
[11:22] <infinity> I suspect most devel series users want to be present, at the console, when upgrades happen.
[11:24]  * ogra wouldnt mind a present at the console when updates happen :)
[11:27] <infinity> xnox, rbalint: I could maybe see a halfway argument, where unattended-upgrades on a devel series defaulted to download-only, so that you have seeded your cache when update-manager (or a manual apt-get run) is invoked.
[11:27] <infinity> Though, even then, with the churn of devel, you might end up downloading twice as many things as you ultimately install.
[11:29] <xnox> infinity, i believe the bdmurray's fix disables the download of updates as well.
[11:30] <infinity> xnox: Sure.  Not super relevant, mind you.  Like I said, that "halfway" compromise might be a bad idea anyway.  It's not uncommon under heavy development for the same package to update 4 times in a week.  I don't want to download all 4 just to install the last one if I upgrade weekly.
[11:31] <infinity> Anyhow, I would contend that daily upgrading the devel series noninteractively is not what most devel users want.  There's a reason people screamed when that bug fix went in and it started happening.
[11:32] <infinity> And "just remove the package, then" is a cop-out because I don't want to install test devel media and then have to make it non-standard just to get it to not mess with me.
[11:33] <juliank> xnox: that's true, but I guess it should really detect "new" units and start them
[11:34] <juliank> Having to add hacks to every package that adds a systemd unit seems weird
[11:34] <xnox> infinity, and we cannot enable just o=beautiful-security suite, as it does really need o=beautiful and o=beautiful-security.
[11:34] <infinity> xnox: Yes... And?
[11:34] <xnox> infinity, or would it work fine for u-a against o=beautiful-security to pull in new deps from o=beutiful?
[11:34] <xnox> without configuring u-a to install from o=beatiful?
[11:34] <infinity> xnox: No.  The whole reason this started happening is because we had to add the release pocket to get new deps from security.
[11:35] <xnox> ack.
[11:35] <infinity> xnox: I don't think returning to the "yay, devel series upgrades behind your back daily" behaviour is sane.
[11:35] <infinity> xnox: People disliked it.  A lot.  For very good reasons.
[11:35] <bdrung_work> rbasak, regarding http://cloud-images.ubuntu.com/daily/streams/v1/ – is this file format documented somewhere? which tools are available for it? I found python-simplestreams, but this doesn't really fit my needs.
[11:36] <juliank> Or well, I guess try-restart could check if the unit has ever been started, and if not (and it's enabled), start it
[11:36] <xnox> right, they are not supported either way; and they should dist-upgrade; and it's best they dist-upgrade interactively; and u-a only does upgrade hence for devel it should really not do anything non-interactive.
[11:36] <rbasak> smoser: ^
[11:36] <rbasak> bdrung_work: there are CLI tools in simplestreams. What do you need, exactly?
[11:36] <xnox> juliank, something like that. I guess i need to forward this to debian BTS proper.
[11:37] <bdrung_work> rbasak, i want to query the stream information and extract the latest cloud images and their download location
[11:38] <juliank> xnox: But that must have been a problem when we first added apt-daily.timer, and nobody noticed that
[11:38] <rbasak> bdrung_work: python/python3-simplestreams can do that. In what way does it not fit your needs?
[11:38] <bdrung_work> so that i can compare the versions with the versions that I have (and an option to download them)
[11:40] <bdrung_work> rbasak, maybe i haven't found the function. is there some function/class that I can give a url (like http://cloud-images.ubuntu.com/releases/) and get the dict (gpg checked) back?
[11:41] <smoser> bdrung_work, usquery or image-status at https://github.com/smoser/talk-simplestreams/tree/master/bin are the closest thing to that.  there is also sstream-mirror.
[11:41] <rbasak> bdrung_work: also  "sstream-query http://cloud-images.ubuntu.com/releases/" does that, so you could start by looking at that implementation.
[11:42] <bdrung_work> okay. i will look at sstream-query
[11:42] <rbasak> bdrung_work: some documentation of the data model: http://bazaar.launchpad.net/~simplestreams-dev/simplestreams/trunk/view/head:/doc/README
[11:45] <bdrung_work> and got a traceback: http://paste.debian.net/979190/
[11:46] <smoser> bdrung_work, http://paste.ubuntu.com/25219664/
[11:46] <rbasak> bdrung_work: do you have ubuntu-cloudimage-keyring installed?
[11:46] <bdrung_work> no
[11:46] <smoser> right. you need that or need to add the cloud images keyring to your gpg keyring
[11:47] <bdrung_work> a nicer error message would be nice
[11:47] <rbasak> Agreed.
[11:47] <smoser> agreed.
[11:48] <smoser> bdrung_work, you can also hit it over https and skip gpg if you wanted.
[11:48] <smoser> sstream-query http://cloud-images.ubuntu.com/daily/streams/v1/com.ubuntu.cloud:daily:download.json
[11:49] <smoser> the client in lxc does metadata over https and data over http if possible falling back to data over https
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
=== sergiusens_ is now known as sergiusens
[14:27] <juliank> Do we want to keep apt-transport-https for artful? We can either drop it now, or keep it around for a release? If we want to keep it, should (can) we at least move the binary to universe?
[14:28]  * juliank vaguely recalls some binaries being in different components than their source packages, but not sure if src main and bin universe, other way around, or both
[14:29] <juliank> Ah it's mentioned as "Binary only demotions to universe" in https://wiki.ubuntu.com/ArchiveAdministration#Component_Mismatches_and_Changing_Overrides
[14:58] <infinity> juliank: I'd rather see it dropped and have apt Provides/Conflicts/Replaces apt-transport-https for a smooth transition.
[14:59] <infinity> juliank: I mean, if it's a 100% replacement now.
[15:25] <elopio> Hello! Can somebody please approve snapcraft in -proposed? I want to finish the testing tonight.
[15:31] <nacc> slangasek: server team acks LP: #1700826
[15:31] <ubottu> Launchpad bug 1700826 in ubuntu-meta (Ubuntu Zesty) "please include numactl on the ubuntu-server iso" [Undecided,In progress] https://launchpad.net/bugs/1700826
[15:31] <nacc> dannf: --^ but with 16.04.3 frozen, it is going to miss that ISO
[15:37] <slangasek> nacc: will someone on server team also do the merge/
[15:38] <nacc> slangasek: i can do that today, yeah
[15:41] <dannf> nacc: ok, thx (and bummer). do you know if it will start appearing in the xenial dailies shortly after 16.04.3?
[15:42] <nacc> dannf: i don't know --^ that's a good question for infinity / slangasek
[15:44] <slangasek> nacc, dannf: it would
[15:45] <dannf> cool, that's probably good enough for my needs. ta!
[15:46] <elopio> slangasek: sorry, RAOF is not around and I'm not sure who to ping today instead. Can you help us accepting snapcraft to proposed?
[15:55] <infinity> slangasek, dannf: If you approve and merge that today, I'm not against it magically appearing on the .3 ISOs iff I have a reason to re-spin.  But, if today's images end up being final, obviously you missed the boat.
[15:56] <infinity> (Well, it would also need a copy-to-updates/pomote-to-main dance)
[16:01] <slangasek> infinity: ack. Meanwhile, TB meeting?
[16:01] <slangasek> (you're chair)
[16:01] <infinity> slangasek: Which is why I was there two minutes ago. :P
[16:01] <slangasek> but didn't start the meeting ;)
[16:11] <rbasak> nacc: ^ FYI
[16:11] <nacc> rbasak: yep, i saw, thanks
[16:12] <nacc> infinity: good to know, i plan on merging after our meeting, but yeah, will need AA help to copy/promote.
=== led2 is now known as led1
[16:36] <nacc> slangasek: infinity: fwiw, seeds updated
[16:36] <nacc> slangasek: still needs the pocket copy & promotion, though
[16:46] <slangasek> nacc: doing
[16:48] <nacc> slangasek: thanks!
[16:48] <nacc> dannf: --^ fyi
[16:49] <dannf> nacc, slangasek : thanks!
[16:53] <slangasek> nacc, dannf: done
[16:53] <nacc> slangasek: excellent, thanks
[16:55] <slangasek> elopio: looks like me dragging my feet to respond has paid off, and sergiusens_ has gotten apw to look at it now ;P
[17:21] <apw> slangasek, heh, thanks
[17:32] <elopio> slangasek: works for me :)
[17:40] <sergiusens_> slangasek: oh, I didn't mean to do that, I didn't even care to look in #ubuntu-devel and since I didn't see elopio ping anyone on #ubuntu-release and a p w was around I thought I just ping him
=== sergiusens_ is now known as sergiusens
[17:40] <slangasek> sergiusens: hey, it all works out great for me, so... :)
[18:06] <juliank> infinity: The idea of keeping it is to provide one release cycle of detecting any unknown issues and having a fallback in such a case, really
[18:06] <juliank> in 6 months we can then say: nobody missed it in the current release, so let's drop it :D
[18:08] <juliank> The question is: Is it still pulled in by seeds / in main?
[18:08] <juliank> If so, that should be fixed first
[18:08]  * juliank does not have an artful chroot atm
=== JanC_ is now known as JanC
[23:20] <xnox> slangasek, in an unpriviledged container (lxd default) everything appears to have CAP_IPC_LOCK capability, yet it does not work, as mlockall() returns ENOMEM which means - trying to lock more than permitted.
[23:21] <xnox> thus causing iscsid.service to fail to start.
[23:21] <xnox> should iscsid.service run in lxd container? should it ignore failure to lock memory in an unpriviledged container?
[23:22] <xnox> or should the Pre checks check if locking memory actually works?
[23:22] <sarnold> xnox: btw "unprivileged"  -- fewer 'd's :)
[23:22] <sarnold> I'd think failure to lock memory would be a warning at worst
[23:22] <xnox> sarnold, tah. also thanks for an opinion.
[23:23] <nacc> sarnold: the problem is if iscsid is your root disk
[23:23] <nacc> sarnold: then getting swapped out might mean you lose your root disk :)
[23:23] <sarnold> oh, it's client-side thing?
[23:23] <nacc> sarnold: and i believe the granularity of iscsid is ... not great
[23:23] <xnox> nacc, not going to be the case for unpriviledged container. and also, what else can it do?
[23:23] <xnox> sarnold, yes client.
[23:23] <nacc> xnox: yeah, i agree, it's probably ok to ignore in unpriv. containers
[23:23] <nacc> xnox: that's just the intention of the code in iscsid (for sarnold's point)
[23:24] <xnox> so iff we are in a container, and failed to lock memory continue.
[23:24] <xnox> but do hard fail if we are not in a container.
[23:24] <xnox> sarnold, is it normal that unpriviledged container has capsh --print things listed in current and bounding set that do not work.
[23:25] <sarnold> xnox: I don't know containers real well but I think that's the conclusion I've come to before
[23:25] <xnox> it would make it much easier if the unprivileged containers did not have cap_sys_ipc and cap_sys_audit_read
[23:25] <nacc> xnox: i assume this is for LP: #1576341 ?
[23:25] <ubottu> Launchpad bug 1576341 in snapd (Ubuntu) "systemd in degraded state on startup in LXD containers" [Undecided,New] https://launchpad.net/bugs/1576341
[23:25] <xnox> it would make it much easier if the unprivileged containers did not have cap_sys_ipc_lock and cap_sys_audit_read
[23:25] <nacc> xnox: yeah, it's confusing as to what is "real" caps and what is not
[23:26] <xnox> nacc, partially. that one is fixed now with https://github.com/systemd/systemd/pull/6503/files systemd would hard fail on not able to do setpriority()
[23:26] <xnox> despite having cap_sys_nice
[23:27] <sarnold> I still think that a warning would be best. "Warning: Don't put swap on iscsi devices due to risk of deadlock." maybe no swap. maybe swap on local disk.
[23:27] <xnox> but i now have iscsid.service and systemd-journald-audit.socket still to do.
[23:27] <sarnold> doing something brutal in either of those two cases would be mean.
[23:27] <nacc> xnox: i thought artful-proposed version of open-iscsi has the fixes
[23:27] <nacc> xnox: which is stuck due to a test regression (on my todo)
[23:28] <nacc> xnox: at least, that was my last comment in the bug -- i've not re-tested recently :)
[23:29] <nacc> xnox: with the fix actually coming from rbalint and incorporated into the most recent merge
[23:31] <xnox> oooh
[23:31] <slangasek> xnox: I don't think any service that asks for locked memory should ignore that failure
[23:31] <xnox> i like that condition in that patch from rbalint
[23:32] <xnox>  private-users to check whether we are running in a user namespace... hm but that is not true.
[23:32] <nacc> xnox: yeah, it's pretty clean with that (or at least a bit cleaner than the generic condition)
[23:32] <xnox> cause e.g. priviledged containers, is still has user namespace, it's just ultimately container root is mapped to host root i think.
[23:32] <xnox> let me check that.
[23:34] <xnox> no actually that does the right thing it seems.
[23:37] <nacc> xnox: yeah, in my testing it seemed to work, but i'll admit to trusting rbalint as well :)
[23:38] <xnox> # systemctl is-system-running
[23:38] <xnox> running
[23:38] <xnox> win =)
[23:40] <nacc> xnox: nice
[23:43] <xnox> and https://github.com/systemd/systemd/pull/6508/files
[23:44] <nacc> xnox: cool, that makes sense based upon the conclusion in the other LP bug (LP: #1457054)
[23:44] <ubottu> Launchpad bug 1457054 in systemd (Ubuntu Wily) "journal is broken in unprivileged LXC and nspawn containers" [Medium,Fix released] https://launchpad.net/bugs/1457054
[23:46] <xnox> now i need to figure out why the new system crashes amd64/i386 VMs, and fails to reboot 5 times in a row on s390x.
[23:50] <infinity> juliank: Keeping it for artful might be reasonable if you'd like people to have a fallback, but I'd like to see the forced P/C/R migration before the 18.04 release then.  If enough data can be gathered to determine it's definitely no longer necessary or useful.