[00:00] <bigjools> the text formatter is broken then, it linkifies bug\nNNN
[00:06] <wgrant> bigjools: It deliberately does that, to cope with wordwrapped emails
[00:06] <bigjools> see my text in bug 1081834
[00:06] <_mup_> Bug #1081834: When setting a milestone on a bug task, the edit icon ends up as the "broken graphic" <Launchpad itself:New> < https://launchpad.net/bugs/1081834 >
[00:07] <bigjools> I say tough titty if it's word wrapped
[00:07] <bigjools> coz now you have a broken link
[00:08] <wgrant> It's probably less bad to have that extra link than it is to miss some
[00:09] <bigjools> I disagree
[00:09] <wgrant> Why?
[00:09] <wgrant> You can just not click on that link :)
[00:09] <bigjools> tell that to oops reports
[00:09] <bigjools> you can just type a bug number too
[00:10] <wgrant> But I can just as easily generate a bad link malevolently by typing "bug 2" in a comment
[00:10] <wgrant> Those sorts of things should be (but aren't presently) excluded from OOPS reports
[00:10] <bigjools> why is it even linked if it doesn't exist?
[00:10] <wgrant> Because user error can cause them
[00:10] <bigjools> it's ab ug
[00:10] <bigjools> should not be linked
[00:11] <wgrant> It's turned grey by JS if it doesn't exist.
[00:11] <bigjools> a start, I suppose
[00:11] <wgrant> Users can type bad URLs
[00:11] <wgrant> They can type bad bug numbers too
[00:12] <bigjools> well it doesn't go anywhere, I thought it was a real link, so it's opk
[00:12] <wgrant> It is a real link until the JS detects that it doesn't actually exist
[00:12] <wgrant> Which isn't ideal, but I think it's a reasonable compromise
[00:12] <bigjools> so robots will still click it then
[00:12] <wgrant> Yes
[00:13] <bigjools> I am sure there was code in the formatter to not linkify non-existent bugs
[00:13] <wgrant> There was, but we removed it
[00:13] <wgrant> Because it was completely terrible
[00:13] <bigjools> let me guess ...
[00:13] <wgrant> Making a separate query for each bug reference
[00:13] <bigjools> yeah
[00:13] <wgrant> And it's difficult to do otherwise without a multi-pass template system, which TAL is not
[00:13] <bigjools> I remember it being a problem on changelogs
[00:14] <wgrant> Anyway
[00:14] <wgrant> "bug 2" is just a special type of URL
[00:14] <wgrant> Users can type bad URLs
[00:14] <bigjools> and when I wanted to remove it to fix performance, all of Ubuntu screamed like a thousand voices in the night
[00:14] <wgrant> We still linkify them
[00:14] <wgrant> Why not do the same with bugs?
[00:14] <wgrant> It's not harming anyone
[00:15] <bigjools> ok, you're on maintenance :)
[00:15] <wgrant> 404s are a discretionary sort of OOPS, since users will always be able to generate them simply by typing a bad URL somewhere on LP
[00:15]  * StevenK stabs gina.txt and twists the knife.
[00:15] <wgrant> They don't unconditionally fall under ZOP
[00:15] <bigjools> ok
[00:15] <wgrant> And they don't degrade user experience
[00:15] <wgrant> => meh
[00:16] <bigjools> well at least you thought about it
[00:17] <wgrant> The linkification of bullets isn't ideal, but there's not much we can do about it without breaking other cases
[00:17] <wgrant> Of course, if you used punctuation properly it wouldn't be a problem :P
[00:18] <bigjools> => meh
[00:18] <bigjools> DWIM etc etc
[00:18] <wgrant> Heh
[00:24] <StevenK> wgrant: Hmmm, what about bug 837563?
[00:24] <_mup_> Bug #837563: language-pack-exporter script raised a KeyError <lp-translations> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/837563 >
[00:25] <StevenK> I thought OOPS prefixes were long dead
[00:26] <wgrant> StevenK: Sure, the REPORTIFSEEN part of that bug is no longer relevant
[00:26] <wgrant> The underlying OOPS is
[01:47] <bigjools> hmmm, why would ^\s not work in my sed expression
[01:48] <StevenK> \s as in 'any whitespace' ?
[01:48] <bigjools> yup
[01:48] <bigjools> ^\s should be leading whitespace
[01:49] <bigjools> yet it matcheth not
[01:49] <lifeless> \\s ?
[01:50] <bigjools> nope
[01:50] <bigjools> removing the ^ matches but I want to be more specific
[01:51] <cjwatson> [[:space:]]
[01:52] <cjwatson> \s is a perl-regex-ism
[01:52] <bigjools> it's in the sed man page :)
[01:52] <cjwatson> not in the one I have here it's not
[01:52] <cjwatson> anyway, [[:space:]] is the POSIX form
[01:53] <bigjools> ^[[:space:]] didn't work
[01:53] <cjwatson> full example please
[01:54] <bigjools> sed -ri "s|^[[:space:]]generator:\shttp://.*:5243/|  http://bar:5243/|" test.tmp
[01:54] <cjwatson> you still have a \s there
[01:55] <cjwatson> and I think perhaps you mean [[:space:]]* for zero or more whitespace characters?
[01:55] <bigjools> makes no difference if I change it
[01:55] <cjwatson> [[:space:]] (or \s in regex engines that support that) means exactly one whitespace character
[01:55] <bigjools> I want a + actually, I'll change it
[01:55] <bigjools> \o/
[01:55] <bigjools> thanks cjwatson
[01:56] <cjwatson> yw
[01:56] <bigjools> I really hate regex
[01:56] <StevenK> bigjools: You now have two problems.
[01:56] <bigjools> exactly
[01:56] <StevenK> Or three, if you're also dealing with mod_rewrite
[01:57] <bigjools> heh
[01:58] <StevenK> wgrant: Can't find OOPS-8e259d8c3b45707c6a37f986d3c8127d on carob's filesystem. :-(
[02:00] <StevenK> wgrant: I wonder if we can just destroy the branch puller
[02:04] <wgrant> mwhudson had plans :)
[02:05] <lifeless> and doesn't now ?
[02:09] <mwhudson> i just don't have time now
[02:09] <mwhudson> wgrant: actually i futzed a little on the flight to linaro connect about this and wanted to talk to someone (probably you!) about this
[02:11] <mwhudson> wgrant: my plan went something like this:
[02:11] <mwhudson> set up a launchpad user on each importd
[02:11] <mwhudson> have a fkey from codeimportmachine to this user
[02:11] <mwhudson> change _canWrite to something like this:
[02:11] <mwhudson> +        elif branch.branch_type == BranchType.IMPORTED:
[02:11] <mwhudson> +            job = branch.code_import.import_job
[02:11] <mwhudson> +            if job.machine:
[02:11] <mwhudson> +                return job.machine.user == requester
[02:11] <mwhudson> +            else:
[02:11] <mwhudson> +                return False
[02:11] <lifeless> mwhudson: so did you decide to stay w/Linaro or move back into Canonical ?
[02:13] <wgrant> mwhudson: That's probably the cheapest way to do it, but ideally we'd also solve stacking at the same time
[02:13] <mwhudson> change things around so that a lp:// url rather than a escudero url gets passed to the worker
[02:13] <mwhudson> wgrant: "solve stacking"?
[02:13] <wgrant> mwhudson: Stacking imports would sometimes be nice.
[02:13] <mwhudson> oh right
[02:14] <wgrant> Which means access to more than just that branch
[02:14] <wgrant> Which gets messy
[02:14] <mwhudson> well
[02:14] <mwhudson> imports would end up stacked on the project trunk in this case
[02:14] <mwhudson> but they would get imported from scratch first
[02:14] <mwhudson> which would not be so ideal
[02:14] <wgrant> Well
[02:15] <wgrant> They might end up using /+branch-id, which wouldn't stack
[02:15] <mwhudson> oh true
[02:15] <mwhudson> and indeed, that would be easiest
[02:15] <wgrant> And safest
[02:16] <mwhudson> so the fix is to make pushing to +branch-id stack?
[02:16] <wgrant> Maybe
[02:16] <wgrant> Or just ignore stacking
[02:16] <mwhudson> i don't think attempting to solve stacking at the same time seems especially sensible
[02:17] <wgrant> Indeed, perhaps not
[02:17] <wgrant> But it should be kept in mind as a future consideration, perhaps
[02:17] <mwhudson> once imports don't need the puller, converting mirrored to imported branches should be trivial
[02:18] <mwhudson> and then one can rm -rf lib/lp/codehosting/puller
[02:18] <mwhudson> which would get you lots of LOC credit :-)
[02:18] <wgrant> Yep
[02:18] <wgrant> That's why I haven't converted mirrors yet
[02:18] <wgrant> Because of the escudero mess
[02:18] <mwhudson> right
[02:19] <mwhudson> someone should delete all the codeimportevent mess too :(
[02:19] <mwhudson> that was mostly ddaa really but i feel bad for letting it happen
[02:19] <wgrant> What's the mess there?
[02:19] <wgrant> I admit I don't know those corners of the model well
[02:19] <mwhudson> well, the whole concept is stupid
[02:19] <mwhudson> not stupid
[02:20] <mwhudson> but should have been YAGNIed before implementation
[02:20] <wgrant> Oh
[02:20] <wgrant> That's distinct from codeimportresult... I... seee
[02:20] <mwhudson> yeah
[02:20] <lifeless> thats hardly unique in LP
[02:21] <wgrant> Ah
[02:21] <wgrant> So CodeImportEvent is an audit log, basically
[02:21] <mwhudson> yes
[02:21] <mwhudson> that you mostly can't read
[02:21] <lifeless> auditor being the now extant answer for that
[02:21] <wgrant> Well
[02:22] <wgrant> Except it isn't extant yet :)
[02:22] <lifeless> ENODEPLOY ?
[02:22] <mwhudson> and that means that standard methods are not used to mutate them, which means that e.g. field validators don't run
[02:22] <wgrant> Yeah
[02:22] <mwhudson> wgrant: https://code.launchpad.net/~mwhudson/launchpad has a few branches at the top if that's useful at all
[02:23] <mwhudson> i can't really remember how far i got, i was looking at changing the worker invocation code when i got discouraged i think
[02:24] <wgrant> Hmm, have you made a terrible mistake...
[02:24] <wgrant> I guess we'll see
[02:25] <wgrant> (pushing a series of branches which will each want to create the same new revisions, and they'll be scanned concurrently now...)
[02:25] <mwhudson> oh
[02:25] <mwhudson> heh
[02:25] <mwhudson> they certainly don't seem to be being scanned
[02:25] <wgrant> It takes a 80s at best to do a fresh scan of an LP branch nowadays
[02:26] <wgrant> Often a few minutes
[02:28] <wgrant> Yeah, they all OOPSed
[02:29] <mwhudson> sigh
[02:30] <wgrant> The branch scanner does not win any points for considering locks or using sensible transaction sizes :(
[02:34] <StevenK> lifeless: We don't have the staging instance deployed yet, let alone think about production.
[02:46] <StevenK> wgrant: http://pastebin.ubuntu.com/1376306/ but I'm not sure how to test it
[02:47] <wgrant> Um no
[02:47] <wgrant> Transaction management does not go in DB model classes :)
[02:48] <StevenK> Wrap the generateIncrementalDiff in BMPJ run() ?
[02:50] <StevenK> wgrant: http://pastebin.ubuntu.com/1376309/
[02:51] <StevenK> That I can test, if I can patch out generateIncrementalDiff()
[02:51] <wgrant> Well
[02:51] <wgrant> We in general need a strategy for handling conflicts in jobs
[02:52] <wgrant> eg. what mwhudson just ran into
[02:52] <wgrant> Ignoring all IntegrityErrors is probably not it :)
[03:18] <StevenK> wgrant: Hmmm, it looks like cronscripts/rosetta-export-queue.py already uses the slave DB and based on the logs it isn't getting reaped. bug 504821
[03:18] <_mup_> Bug #504821: poimport (export)_uses a single long transaction, gets reaped <lp-translations> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/504821 >
[03:20] <wgrant> It's still vile
[03:20] <wgrant> But indeed, I haven't seen reaping in quite some time
[03:21] <StevenK> wgrant: Downgrade or close?
[03:21] <wgrant> Invalid until we have reason to believe otherwise
[03:24] <wgrant> It's still something we need to adjust eventually, but it's not causing any trouble today
[03:24] <wgrant> And it's not actively a problem until we ratchet our paranoia up another notch
[03:26] <wgrant> StevenK: In what circumstances does one not have an id?
[03:31] <StevenK> I'm guessing when we get a error page or something like that
[03:31] <StevenK> There are a whole stack of oopses on neem
[03:31] <wgrant> Right, they certainly happen
[03:31] <wgrant> But we should work out why
[03:32] <wgrant> Blindly bypassing an error condition without understanding it is not the way to fix criticals, sadly
[03:32] <wgrant> (unless we have no other choice)
[03:34] <StevenK> I just noticed the OOPSes while looking if there was a langpack export OOPS
[03:35] <StevenK> Checking if they're all the same bugtracker
[03:35] <wgrant> Sure
[03:35] <wgrant> It's been happening for a while
[03:35] <wgrant> And it's likely to be a simple fix
[03:36] <wgrant> But we need to understand why
[03:36] <lifeless> using the slave db is now pointless
[03:36] <lifeless> as transaction bloat is propogated back to the master
[03:37] <wgrant> lifeless: Pointless for bloat
[03:37] <wgrant> Not pointless for load
[03:37] <lifeless> not terribly interesting either ;>
[03:37] <wgrant> (not that load is an issue on any system today)
[03:37] <wgrant> right
[04:00] <StevenK> Oh, hah
[04:00] <StevenK> mercurial has replaced their roundup instance with bugzilla and are redirecting
[04:00] <wgrant> Ah
[04:05] <StevenK> wgrant: Right, there's mercurial fixed, two link farm bugtrackers deleted and I yet to figure out what setuptools is doing
[04:06] <wgrant> :)
[08:30] <adeuring> good morning
[09:15] <czajkowski> aloha
[10:22] <czajkowski> cjwatson: ello how do you want this triaged, https://bugs.launchpad.net/launchpad/+bug/1081860
[10:22] <_mup_> Bug #1081860: uploads to oneiric/partner are redirected to oneiric-proposed/partner <Launchpad itself:New> < https://launchpad.net/bugs/1081860 >
[10:29] <cjwatson> czajkowski: I stole it for ubuntu-archive-tools
[10:29] <cjwatson> So you won't have to care :)
[10:29] <czajkowski> oki dokie :)
[10:29] <czajkowski> thanks colin
[17:31] <czajkowski> cjwatson: me again :) can you moderate a mail if you get a chance later on to devel
[17:32] <czajkowski> really find it hard to type devel without going devil :/
[17:33] <cjwatson> czajkowski: done
[17:34] <czajkowski> cjwatson: thank you
[18:18] <jml> is there a secret way of only retrieving certain keys when GETting Launchpad API resources?
[18:18] <jml> some code_review_comments are really, really big.
[18:20] <jml> further, the size of the download is 2x the size of the comment, because as_quoted_email is included in the dict
[18:21] <jml> also, they both get stored in memory as unicode objects, which take up 4x as many bytes as the string has characters
[18:21] <jml> bringing us up to 8x
[18:22] <jml> then, if you are getting it as part of a collection, the naive way of using it (looping through), will give you a copy of the data in the collection _and_ a copy in the entry object
[18:22] <jml> taking us up to 16x
[18:23] <jml> for this use case, I don't care about the comment body at all. All I want is the dates.
[18:35] <czajkowski> jml: most of the devs are off today as USA based
[18:42] <jml> czajkowski: so I should try to avoid having hard problems today and tomorrow?
[19:30] <czajkowski> jml: most are back tomorrow tbh, or leave a message for wgrant he'll be back online shortlyish
[19:31] <czajkowski> jml: adeuring will be back jtv bigjools, or gmb
[22:26] <wgrant> jml: Well, you can retrieve individual attributes directly, but you can't retrieve a subset of elements that isn't either the whole lot or a single one.
[22:26] <wgrant> lazr.restful unfortunately provides no more advanced facility
[22:26] <wgrant> jml: You should upgrade to Python 3.3 :)
[22:28] <abentley> jml: Are these really, really big code_review_comments full of test results?
[23:15] <james_w`> abentley, yes


[00:50] <mup> PR snapcraft#777 opened: go plugin: don't put debugging symbols in generated binaries <Created by teknoraver> <https://github.com/snapcore/snapcraft/pull/777>
[03:16] <mup> Bug #1621304 opened: In the profile setup, pressing enter after filling the email address does nothing <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621304>
[03:22] <liuxg> does anyone have a nodejs snappy sample for reference in addition to the "shout" on in the demos? thanks
[05:38] <mup> Bug #1621323 opened: On the all-snaps image, the snapweb interfaces are not connected <Snappy:New> <snapweb:New> <https://launchpad.net/bugs/1621323>
[06:18] <Kaleo_> mvo, tvoss, I heard something about dbus session bus support or something. Is there something being baked related to that?
[06:24] <mvo> hey Kaleo_ - no dbus session bus work is happening currently from the core team afaik, is that something important for you/your team?
[06:24] <Kaleo_> mvo, I think so
[06:24] <Kaleo_> mvo, wwho is the core team?
[06:24] <Kaleo_> -w
[06:33] <mup> Bug #1621339 opened: Unable to complete UC16 beta first boot if ESC is pressed after last step <Snappy:New> <https://launchpad.net/bugs/1621339>
[06:33] <didrocks> hey mvo! Great job for yesterday's image! I'm curious if you think we'll have a snapd release today with the "revert fix" we discussed about the other day? As this is the last day for us to prepare the image for Monday's event
[06:35] <Kaleo_> mvo, I've uploaded a i386 snap of test-snapd-thumbnailer-consumer (there was only an amd64 version): is that the right way to support multiple archs? automated review failed, can you let it through?
[06:35] <mvo> Kaleo_: the most important person to talk to would be gustavo as he will design the feature. however he/we are busy with the "ga" release
[06:35] <Kaleo_> https://myapps.developer.ubuntu.com/dev/click-apps/5863
[06:35] <mvo> Kaleo_: yes and yes
[06:35] <Kaleo_> thanks
[06:35] <Kaleo_> mvo, great
[06:36] <mvo> Kaleo_: feel free to join our standups to talk about specific feature you need
[06:36] <mvo> didrocks: pavel was working on this last I checked, give me a minute to look over the open PRs
[06:36] <didrocks> thx!
[06:37] <mvo> didrocks: I really would love to do something for you, even something cheap and hackish like "revert --devmode" so that it preserves the flag, chippaca was also looking at it, but because of the image rush I did not pay too much attention
[06:37] <mvo> Kaleo_: approved, enjoy
[06:37] <Kaleo_> mvo, thank you :)
[06:38] <didrocks> mvo: yeah, I guess it. But indeed, I can hide the --devmode typing quickly when doing the revert and that would work (even if snapd is only in -proposed, I can install my image with it) ;)
[06:39] <mvo> didrocks: lets keep talking over the course of the day, at this time most people are still sleeping :) at least the relevant ones
[06:39] <mvo> Kaleo_: my pleasure!
[06:39] <mvo> I will promote the candidate ubuntu-core images to stable very soon, so if people want to do last minute tests on those :)
[06:40] <didrocks> mvo: ok, I'll let you just ping me once people are ready for this :)
[06:41] <didrocks> mvo: does it has reexec? that case, I'll need to ensure I'm adding the magic variable to /etc/environment in case I have to use snapd from -proposed (and so, the package version)
[06:43] <mvo> didrocks: the version in xenial-updates that got promoted yesterday has re-exec disabled
[06:43] <mvo> didrocks: because the sru process is now working really well for us and also because it causes some hard to understand behavior
[06:43] <didrocks> ok!
[06:44] <tvoss> Kaleo_: we don't need the core Team right now to unblock your work, I'm getting a coffee refill right now, will be online in a few
[06:45] <Kaleo_> tvoss, COFEE
[06:45] <Kaleo_> +F
[07:01] <tvoss> Kaleo_: the core team, so Jamie specifically is aware of our requirements, let's coordinate a little on what we put on their plate
[07:01] <tvoss> Kaleo_: for the time being, we will unblock you and get you a session dbus in a classic environment
[07:02] <dholbach> hey hey
[07:02] <Kaleo_> tvoss, sounds good
[07:03] <Kaleo_> tvoss, and that means  DBUS_SESSION_BUS_ADDRESS needs to be set right?
[07:03] <tvoss> Kaleo_: yeah, we are taking care of that stuff
[07:03] <tvoss> Kaleo_: I think we can have something be eow
[07:03] <tvoss> by, even
[07:03] <Kaleo_> tvoss, ok
[07:19] <mup> PR snapd#1816 closed: libvirt interface to allow snaps to access libvirtd on a classic host <Created by cmars> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1816>
[08:07] <ogra_> hmpf ... so the grade hackery didnt help
[08:07] <ogra_> all ubuntu-core snaps are stuck :(
[08:22] <mvo> ogra_: yeah
[08:22] <mvo> ogra_: if you could give the pi3 image a quick try, that would rock
[08:22] <ogra_> i'll take a deeper look into patching our snapcraft
[08:22] <ogra_> mvo, both downloading atm ... i only get 200k/s from cdimage for some reason :/
[08:27] <zyga> anyone versed in glib-test, is ther any sanity into how -p and -s options work for selecting tests to run
[08:27] <pitti> mvo: guten Morgen
[08:27] <zyga> they seem to do nothing sensible at all, I'm trying to follow the source to see what's going on
[08:28] <zyga> a simple test on some-unit-test-binary -s /stuff-to-skip/ just does nothing and runs all tests with that prefix
[08:28] <zyga> similarly to -p
[08:28] <pitti> ogra_, mvo: IIRC you could reproduce bug 1620559, right? would you mind telling your testing result to it, so that we can mark it v-done?
[08:28] <mup> Bug #1620559: /etc/resolv.conf is empty on snappy <hw-specific> <verification-needed> <Snappy:New> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Xenial):Fix Committed by pitti> <https://launchpad.net/bugs/1620559>
[08:28] <zyga> some values of -p seem to work but the exact criteria are eluding me, it seems the number of slashes in the test name is relevant
[08:29] <pitti> mvo: does networking behave now?
[08:29] <ogra_> pitti, it does
[08:29] <pitti> (I guess RTM day wouldn't be the worst day for it to behave :) )
[08:31] <mvo> pitti: its working fine, thanks again
[08:32] <ogra_> pitti, set to verification-done
[08:32] <pitti> danke
[08:37] <mup> PR snapd#1867 opened: fix incorrect number of implicit interfaces <Created by mvo5> <https://github.com/snapcore/snapd/pull/1867>
[08:51] <mup> Bug #1621378 opened: console-conf should tell the user that the keyboard is US only <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621378>
[08:54] <mup> Bug #1621380 opened: console-conf should allow to configure a hostname <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621380>
[08:56] <mwhudson> mvo: did you figure out the GOARM problems in the end?
[08:56] <mvo> sergiusens: please! https://bugs.edge.launchpad.net/ubuntu/+bug/1621382
[08:56] <mup> Bug #1621382: launchpad building with stage packages broken <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1621382>
[08:56] <mvo> mwhudson: which one of them ;)
[08:57] <mvo> mwhudson: but yeah, after some mild panic attacks we got a images
[08:57] <mvo> mwhudson: network was broken in between and similar but we got it all under control
[09:00] <ogra_> mvo, hmm, why did my pi3 just get an ubuntu-core update in the middle of installing the classic snap ?
[09:00] <ogra_> eeek !
[09:00] <ogra_> ogra@localhost:~$ snap list
[09:00] <ogra_> Name         Version  Rev  Developer  Notes
[09:00] <ogra_> classic      16.04    14   canonical  devmode
[09:00] <ogra_> ubuntu-core  16.04.1  424  canonical  -
[09:00] <ogra_> ogra@localhost:~$
[09:01] <ogra_> mvo, something is wrong with the pi3 image
[09:02] <mvo> ogra_: no kernel?
[09:02] <ogra_> ogra@localhost:~$ systemctl status snapd.firstboot.service
[09:02] <ogra_> ● snapd.firstboot.service - Run snappy firstboot setup
[09:02] <ogra_>    Loaded: loaded (/lib/systemd/system/snapd.firstboot.service; enabled; vendor preset: enabled)
[09:02] <ogra_>    Active: failed (Result: exit-code) since Wed 2016-09-07 21:07:19 UTC; 11h ago
[09:02] <ogra_>  Main PID: 1448 (code=exited, status=1/FAILURE)
[09:02] <mvo> ogra_: snap change 1?
[09:02] <ogra_> ogra@localhost:~$ snap change 1
[09:02] <ogra_> Status  Spawn                 Ready                 Summary
[09:02] <ogra_> Done    2016-09-07T21:07:20Z  2016-09-08T08:45:05Z  Generate device key
[09:02] <ogra_> Done    2016-09-07T21:07:20Z  2016-09-08T08:45:14Z  Request device serial
[09:03] <mvo> ogra_: snap change 2 :)
[09:03] <ogra_> thats already the "install classic" call
[09:03] <ogra_> no trace of firstboot in snap changes
[09:03] <mvo> ogra_: nothing from firstboot? weeeeh
[09:03] <ogra_> also no complaint about a missing model assertion
[09:03] <ogra_> very weird
[09:04] <ogra_> mvo, dragonboard is fine though ...
[09:06] <mwhudson> mvo: the hwcap / "please recompile with GOARM=5" one was the one i meant
[09:06] <mvo> mwhudson: oh, yes, that is the libc aux vector getting srubed by apparmor and that contains the information about the availabity of a floating point unit
[09:07] <mwhudson> ah ok
[09:07] <mwhudson> yes, sounds about right
[09:07] <mvo> mwhudson: tyler and jamie know the even more gorry details
[09:07] <mvo> but I think this is pretty much it and I changed the apparmor confinment to allow this vector to get passed unchanged
[09:08] <mwhudson> yeah, go uses it for quite a few things
[09:48] <matteo> elopio: I've fixed the tests for PR #777
[10:10] <mup> PR snapd#1867 closed: fix incorrect number of implicit interfaces <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1867>
[10:56] <mwhudson> mvo: could you subscribe snappy-dev to https://bugs.launchpad.net/ubuntu/+source/golang-github-coreos-go-systemd pls? (for MIR)
[11:00] <gouchi> hi
[11:00] <gouchi> I got this error error: cannot find signatures with metadata for snap  when I try to test my snap package
[11:00] <gouchi> didn't get this error before
[11:01] <ogra_> use the --dangerous option
[11:01] <ogra_> i assume you try to do a snap install ?
[11:01] <gouchi> yes
[11:02] <ogra_> yeah, then use that for snaps not signed by the store
[11:02] <nhaines> The Ubuntu Core beta image for Rpi2 is pretty fun.  :)
[11:02] <nhaines> Is there a story for wireless networking yet?
[11:03] <gouchi> ogra_: error: unknown flag `dangerous'
[11:03] <ogra_> nhaines, console-conf does not support it yet (it is in the pipe)
[11:03] <nhaines> ogra_: "in the pipe" is good to know.
[11:03] <nhaines> snapweb didn't work at all for me.
[11:03] <nhaines> And 'snap find' is broken now.
[11:03] <ogra_> nhaines, you can cheat indeed and put a config into /etc/netwotrk/interfaces.d/wlan0 (and reboot)
[11:03] <ogra_> broken ? how ?
[11:03] <nhaines> ogra_: now *that* is exactly what I wanted to know.  :)
[11:04] <nhaines> ogra_: it used to list all snaps; now it simply returns an error.
[11:04] <ogra_> thats by design ;)
[11:04] <ogra_> not broken
[11:04] <nhaines> It is a regression and probably a bad design.  ;)
[11:04] <nhaines> Although I'm sure it wasn't scalable.
[11:04] <ogra_> snap find can only show 100 snaps ... but the sotre has more
[11:05] <nhaines> This makes it impossible to discover snaps, though.
[11:05] <nhaines> (So I hope design is on it sometime.)
[11:05] <ogra_> well, if you have 1mio snaps one day you realyl dont want them listed :)
[11:05] <nhaines> ogra_: sure, that's what `less` is for.  ;)
[11:06] <ogra_> sure ... but the less would only start after retrieving lines for 2h :P
[11:06] <ogra_> (and probably cause an OOM)
[11:06] <nhaines> :)
[11:07] <nhaines> So there are problems.  But I was able to have Nextcloud running in all of 30 seconds and I didn't have to do any of that pesky installation or dependencies or configuration.  So there's that!
[11:08] <nhaines> Should snapweb still be listening on port 4200?
[11:08] <ogra_> it should ... but it has bugs and fails to start currently
[11:08] <ogra_> btw... wlan -> http://paste.ubuntu.com/23149789/
[11:08] <nhaines> Okay, currently broken, that's good to know, too.
[11:09] <nhaines> I'm not certain that "pull all keys from Launchpad" is a "real world" solution, but I'll be damned if it wasn't absolutely perfect for me.  :D
[11:09] <ogra_> it will auto-update to a fixed version ;)
[11:09] <nhaines> Yes, benefit of snappy.  ;)
[11:11] <nhaines> Although I sort of feel like "wireless networking setup and web administration don't work right now" could have been in the release notes.  :P
[11:12] <nhaines> But I've been having plenty of fun with snapd on the desktop, and seeing Ubuntu Core 16 start to really take shape is very exciting!
[11:12] <mwhudson> nhaines: do you want to try a bootleg core snap that might let you configure wifi? :)
[11:13] <nhaines> mwhudson: yes, sounds like fun.  :)
[11:13] <nhaines> Particularly because if it doesn't work I can file a bug and jump back to the beta release.  :)
[11:14] <ogra_> well, not sure you can actually sideload ubuntu-core easily
[11:14] <ogra_> i think we block that
[11:14] <mwhudson> i think this would be a "make new image and reflash" sort of test
[11:14] <nhaines> Not with that attitude!
[11:14] <ogra_> heh
[11:14] <mwhudson> builds started on https://launchpad.net/~canonical-foundations/+snap/snappy-first-boot anyway
[11:14] <ogra_> snappy = safety first :)
[11:14] <gouchi> now I launch my package and I got "failed: cannot list snaps: access denied" ?
[11:15] <ogra_> gouchi, wow, thats a weird one
[11:15] <ogra_> havent seen that before
[11:15] <nhaines> The real fun of snaps is that betatesting is really painless because reverting to known-good images is as fast as your disk controller.
[11:15] <ogra_> yeah
[11:15] <nhaines> gouchi: if you're on a classic desktop Ubuntu, try "snap login" again.
[11:16] <ogra_> nhaines, well, that should work without
[11:16] <gouchi> there must have been some changes to snapd because I could test my package
[11:16] <ogra_> unless gouchi's snap calls "snap list"
[11:16] <ogra_> internally
[11:16] <gouchi> no it doesn't
[11:17] <ogra_> yeah, i assumed so
[11:17] <ogra_> if you just call snap list manually, does it also throw that error ?
[11:17] <gouchi> error: cannot list snaps: access denied
[11:17] <ogra_> wow
[11:17] <ogra_> is that on desktop ?
[11:17] <gouchi> strange I must have done something wrong during my installation
[11:18] <ogra_> or "classic"
[11:18] <gouchi> I am running on ubuntu 16.04 desktop
[11:19] <gouchi> I just followed as usual the installation process here : https://github.com/snapcore/snapd
[11:20] <ogra_> you mean you built snapd from source ?
[11:20] <mup> PR snapd#1868 opened: Support revert flags <Created by stolowski> <https://github.com/snapcore/snapd/pull/1868>
[11:20] <gouchi> ogra_: yes
[11:20] <gouchi> ogra_: sorry for the noise there was wrong permission on /run/snapd.socket
[11:21] <ogra_> dont you trust our packages ? :)
[11:22] <gouchi> I try time to time the package if it is working but still failed
[11:23] <gouchi> I don't understand because opengl software are working
[11:29] <gouchi> if somebody wants to look here my snapcraft.yaml and wrapper with the log http://www.hastebin.com/xajesehica.coffee
[11:30] <gouchi> I know I should use dump plugin instead of copy ;-)
[11:35] <nhaines> ogra_: hmm, /etc/network/interfaces.d/wlan0 didn't seem to work.
[11:35] <ogra_> nhaines, i used it on my pi3 and dragonboard
[11:36] <ogra_> on a WPA2 network
[11:38] <nhaines> Quoting my SSID and trying again.  :)
[11:38] <mup> PR snapd#1869 opened: cmd/snap: serialise empty keys list as [] rather than null <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1869>
[11:40] <zyga> jdstrand: hey, around?
[11:42] <nhaines> Hmm, still nothing.
[11:43] <ogra_> any errors ?
[11:43] <nhaines> I see in dmesg where the devices was renamed from wlan0.  But not where to.
[11:43] <ogra_> renamed ?
[11:43] <ogra_> well, use your wired connection to debug :)
[11:43] <nhaines> [   15.286248] rtl8192cu 1-1.3:1.0 wlx74da386871f1: renamed from wlan0
[11:43] <ogra_> uuuh
[11:44] <nhaines> ogra_: yes, that's what I'm doing.  Althuogh...
[11:44] <ogra_> realtek
[11:44] <nhaines> My ifconfig-fu is now weak.
[11:44] <ogra_> thats a USB wlan card, attached externally, right ?
[11:44] <nhaines> Yes, I bought it specifically because it works on the RPi2 with no special drivers--particularly with Ubuntu MATE.
[11:44] <nhaines> ogra_: correct.
[11:45] <ogra_> i bet we dont have the firmware
[11:45] <nhaines> Hmm, schade.  :)
[11:45] <ogra_> check in lsmod if a module is loaded for it
[11:45] <ogra_> and grep in syslog for that module name
[11:45] <ogra_> i bet you find some error about missing firmware files
[11:45] <ogra_> if so, file a bug and let ppisati know about it
[11:46] <nhaines> Hmm, rtl8192cu, rtl_usb, rtl9281c_common, and rtlwifi are all loaded.
[11:46] <ogra_> that looks ok then
[11:46] <ogra_> cat /proc/net/dev ?
[11:46] <nhaines> No errors in syslog.
[11:47] <ogra_> well, if it was renamed, you need to rename the config file and the name of the device inside
[11:47] <nhaines> Oh, it lists wlx74da386871f1.  zeros all across.
[11:47] <nhaines> Hmpf. :)
[11:47] <ogra_> right ..
[11:47] <ogra_> these are the new "predictable" network interface names :)
[11:48] <ogra_> ask lennart poettering whats predictable about them though :P
[11:48] <ogra_> and indeed, it will only work if you pronounce the name three times in a row aloud
[11:49] <nhaines> Well, we'll see in 30 seconds I suppo!
[11:49] <nhaines> suppose!
[11:54] <nhaines> ogra_: well, that worked!  So now my RPi2 running snappy is twice as useful.  ;)
[11:55] <nhaines> Welll, I suppose I learned something new with /proc/net/dev.  Thanks very much for helping me troubleshoot that.  :)
[11:55] <gouchi> adjust program to write to $SNAP_DATA or $SNAP_USER_DATA because the software needs to read/write in ~/.config
[11:55] <nhaines> Also, just imagine me shaking my fist at Lennart Poettering.
[11:56] <gouchi> So we need to patch the software to use those env variables ?
[12:01] <morphis> mvo, pedronis: where can people who want to generate an image for supported devices (pi, dragonboard) get a model assertion from? Do they have to always generate one on their own or is it possible to fetch the official signed one from somewhere?
[12:02] <ogra_> nhaines, heh, glad it worked
[12:02] <ogra_> morphis, afaik thats still in the works, there will be a way to get it generated via the store or LP or so
[12:03] <nhaines> ogra_: now to figure out how to change the hostname.  Although I do want to file a bug that nano isn't around.  :P
[12:03] <morphis> ogra_: ok, so for now I have generate my own one or take it from "somewhere"
[12:03] <ogra_> morphis, if you want to do basic boot testing you can use UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1  with ubuntu-image
[12:03] <morphis> ah
[12:03] <morphis> so I still need one but can use without signature
[12:04] <ogra_> morphis, note though that will only help with boot stuff ... snap commands will not work in the booted image
[12:04] <morphis> ogra_: hm
[12:04] <ogra_> (firstboot will refuse to run without a signed model assertion)
[12:05] <mvo> morphis: its possible to get it from the store, it will be in the assertion store in a bit, I can mail you one in the mantime
[12:06] <morphis> mvo: got the pc.model already from your snapd PR
[12:06] <morphis> but was wondering about one for the pi2/pi3
[12:10] <ogra_> well, we need a way to use self signed ones
[12:10] <ogra_> since what mvo will give you will be the official canonical assertion ...
[12:10] <ogra_> whihc makes your home built images kind of official :)
[12:12] <zyga> seb128: hey
[12:12] <mup> PR snapd#1870 opened: store: ensure the payment methods method handles auth failure <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1870>
[12:12] <zyga> seb128: do you know who manages snapd-xdg-open on github? I have a few things pending there without reply
[12:15] <seb128> zyga, hey, attente did most of the work and mvo helped with review&landing I think
[12:18] <seb128> zyga, I don't understand your "package for <...>" issues reports
[12:19] <seb128> zyga, distributions doing packaging isn't an upstream issue
[12:19] <mup> PR snapd#1871 opened: snap: lessen annoyance of implicit interface tests <Created by zyga> <https://github.com/snapcore/snapd/pull/1871>
[12:24] <morphis> ogra_: yeah
[12:24] <morphis> ogra_, mvo: so what is the one in https://github.com/mvo5/snappy/blob/c230019df76d27ce7c67f3003e1c0ca945030c2d/tests/lib/prepare.sh signed with?
[12:25] <morphis> ogra_: and with that we basically require people to create their own model assertion when they want to build an image which is different to the official one
[12:25] <ogra_> exactly
[12:26] <mup> PR snapd#1869 closed: cmd/snap: serialise empty keys list as [] rather than null <Created by cjwatson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1869>
[12:27] <morphis> ogra_: good
[12:35] <zyga> attente: hey, around? could you please add me to snapd-xdg-open on github / review branches
[12:36] <zyga> seb128: the package bugs are just so that we have downstream packages for all the distros
[12:36] <seb128> zyga, that's not an upstream issue...
[12:36] <zyga> seb128: I agree it's not an upstream issue but this is an easy way to track it
[12:36]  * seb128 sends zyga some postits
[12:36] <ogra_> with passwords on them ?
[12:37]  * seb128 writes "ubuntu/ubuntu" on the postits
[12:39] <zyga> but.. I have all the ubuntu stickers already
[12:40] <seb128> zyga, is there any change you need to commit? I had a look and you don't have anything major there, having an empty README is probably not bothering many people
[12:40] <seb128> or is that to get a 0.1 tarball out?
[12:40] <zyga> seb128: correct
[12:40] <zyga> seb128: this blocks the fedora package
[12:40] <seb128> why?
[12:40] <mup> PR snapd#1872 opened: tests: use in-tree snap{ctl,-exec} for all tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1872>
[12:40] <seb128> they for sure have git snapshot packages
[12:40] <zyga> seb128: because snapshot vs release packaing
[12:40] <seb128> that's a lame excuse
[12:40] <zyga> seb128: and we should just release
[12:41] <jdstrand> zyga: hey
[12:41] <seb128> you could grab the package .tar.gz and claim that a release
[12:41] <zyga> jdstrand: hello, nice to see you
[12:41] <zyga> seb128: no, that's not how fedora packaging works
[12:41] <zyga> seb128: anyway, this is a moot discussion
[12:41] <seb128> right
[12:41] <jdstrand> zyga: you too :)
[12:41] <zyga> jdstrand: I did plenty of updates to the ns-support module
[12:42] <seb128> zyga, well I know if some desktop packages they have that are git snapshot so it's a lame argument to block things they don't want I guess
[12:42] <zyga> jdstrand: there are still a few things but I was wondering if we can merge it and iterate (after a 2nd review with the new changes)
[12:42] <seb128> zyga, but as you said, no point arguing, easy enough to roll a tarball
[12:42] <jdstrand> zyga: ok, I'll take a look
[12:42] <jdstrand> let me get through email for anything urgent
[12:42] <zyga> seb128: I mean, I could do a snapshot realease but I really don't want to, part of what I need to do is to ensure that all the distros ship the same thing and it is easier with versions
[12:43] <seb128> right
[12:43] <zyga> jdstrand: I'd like to propose a small branch that actually uses it, along with some simple spread tests, and let people play with the real thing
[12:44] <zyga> seb128: I should also ITP snapd-xdg-open in debian
[12:44] <mup> Bug #1564369 changed: sudo broken in latest classic <Snappy:Fix Released> <https://launchpad.net/bugs/1564369>
[12:44] <zyga> jdstrand: there will be a change to snap-confine and a new executable snap-discard-namespace
[12:44] <zyga> jdstrand: (not setuid root!)
[12:45] <attente> zyga: hey, sorry, but i don't have write access to that repo either
[12:46] <zyga> attente: oh, interesting
[12:46] <zyga> so who does? :)
[12:46] <zyga> mvo: FYI, I wrote what-is-mounted that prints json with all the details based on mountinfo
[12:46] <attente> zyga: should be didrocks and mvo
[12:46] <zyga> I think grep and awk are ok but if we ever need something more complex we should perhaps think about it
[12:47] <zyga> didrocks: do you have commit access to snapd-xdg-open on github.com/snapcore/snapd-xdg-open?
[12:47] <jdstrand> whoa
[12:48] <jdstrand> how did the libvirt interface go through without security review?
[12:48] <jdstrand> zyga, mvo: ^ libvirt should not auto-connect
[12:48] <ogra_> well, security ... who cares :P
[12:48] <jdstrand> it gives a direct path to root
[12:48] <jdstrand> just like lxd and docker
[12:49] <zyga> jdstrand: should it it auto-connect but be restricted?
[12:49]  * ogra_ pushes code for an nsa interface that auto-connects ... lets see :P
[12:49] <zyga> ogra_: make sure it doesn't show in snap interfaces
[12:49] <ogra_> thats indeed the ppurpose :)
[12:50] <jdstrand> zyga: there are choices to be made, sure. but there was no discussion or coordination on restricting it
[12:51] <jdstrand> zyga: there is nothing in snapd that limits its use to a certain snap atm. there is nothing in the review tools that would limit it (other than the fact that the review tools would warn cause it isn't a known interface yet (thank goodness for defensive tools))
[12:51] <zyga> jdstrand: sure, I don't dispute the no-review part
[12:52] <jdstrand> it also doesn't have any comments on how much privilege it gives
[12:52] <mvo> jdstrand: sorry, I think this one was my fault. I will push a branch that removes the auto-connect
[12:52] <jdstrand> I thought there was an understanding that all security policy went through a member of the security team?
[12:52] <jdstrand> ok
[12:53] <abeato> mvo, hey, do you know if the issue with rpi/vfp detection has already been solved?
[12:53] <mvo> abeato: yes, that is fixed
[12:54] <abeato> mvo, nice, thanks
[12:55] <jdstrand> mvo: if I comment on the original branch, will you incorporate the changes? (feel free to autoconnect now)
[12:55] <cjwatson> Hmm, I think the autopkgtest failures on https://github.com/snapcore/snapcraft/pull/726 are a test infrastructure bug of some kind - I already added snapd to Depends in debian/tests/control, but it doesn't appear to be being installed
[12:55] <mup> PR snapcraft#726: Implement basic form of `snapcraft register-key` <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/726>
[12:55] <jdstrand> mvo: err, feel free to make autoconnect false now
[12:56] <mvo> jdstrand: yes, PR on the way
[12:56] <mvo> jdstrand: sorry again
[12:56] <jdstrand> ok, thanks
[12:56] <mup> PR snapd#1873 opened: interfaces: disable auto-connect in libvirt interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/1873>
[12:57] <didrocks> zyga: added
[13:01] <zyga> didrocks: thank you!
[13:04] <didrocks> yw
[13:14] <morphis> mvo: shouldn't snapd rexec itself when I install the edge ubuntu-core snap on my desktop?
[13:16] <zyga> morphis: AFAIR we disabled this lately
[13:17] <ogra_> unless you have exported the env var that prevents this it should
[13:17] <ogra_> ogra@styx:~/Devel/branches/ubuntu-core-snap$ snap --version
[13:17] <ogra_> snap    2.14.2~16.04+ppa224-1
[13:17] <ogra_> snapd   2.14.2~16.04+ppa224-1
[13:17] <ogra_> series  16
[13:17] <ogra_> ubuntu  16.04
[13:17] <ogra_> this is definitely not the binary from the installed package
[13:17] <ogra_> but from ubuntu-core
[13:18] <morphis> zyga, ogra_:  export SNAP_REEXEC=1 ?
[13:19] <ogra_> well, you shouldnt need to export it ...
[13:19] <ogra_> at least on my machines i get the in-ubuntu-core binary without any tinkering
[13:20] <ogra_> if you want to suppress it you need export SNAP_REEXEC=0 though
[13:20] <zyga> morphis: I think this is set in the service environment file
[13:20] <morphis> ok
[13:20] <zyga> morphis: so snapd won't reexec, snap might if you set it in the shell directly
[13:20] <morphis> let me try zhat
[13:21] <ogra_> ogra@styx:~/Devel/branches/ubuntu-core-snap$ grep Env /etc/systemd/system/multi-user.target.wants/snapd.service
[13:21] <ogra_> EnvironmentFile=/etc/environment
[13:21] <ogra_> not really
[13:21] <ogra_> ogra@anubis:~/datengrab/devel/branches/snappy-systems$ grep Env /etc/systemd/system/multi-user.target.wants/snapd.service
[13:21] <ogra_> EnvironmentFile=/etc/environment
[13:21] <ogra_> nor on my desktop
[13:21] <ogra_> (both xenial)
[13:22] <morphis> Sep 08 15:22:25 nirvana /usr/lib/snapd/snapd[17662]: cmd.go:81: DEBUG: restarting into "/snap/ubuntu-core/current/usr/lib/snapd/snapd"
[13:23] <morphis> with SNAP_REEXEC=1 in /etc/environment
[13:24] <morphis> ah that gives me snap sign :-)
[13:24] <morphis> ogra_: you now have the unsigned model assertion for the pi somewhere?
[13:27] <ogra_> pi2 or 3 ?
[13:27] <morphis> both :-)
[13:27] <ogra_> http://paste.ubuntu.com/23150160/
[13:27] <ogra_> just replace the gadget name :P
[13:28] <morphis> aye
[13:31] <mvo> morphis: not anymore, re-exec got disabled
[13:31] <morphis> mvo: see the log output above
[13:32] <morphis> hm, now I only get a: error: cannot sign assertion: bad GPG produced signature: it does not verify: openpgp: invalid signature: RSA verification failure
[13:32] <morphis> when I try to sign my own model assertion
[13:34] <abeato> it looks like it is not possible to run strace now with a snapped command :(
[13:34] <ogra_> mvo, why do i have 2.14.2~16.04+ppa224-1 in "snap ---version" then ?
[13:34] <ogra_> i definitely dont have that package installed
[13:36] <ogra_> mvo, dpkg -l shows snapd 2.13 installed ... snap --version the ppa string ... so i guess if you wanted to prevent re-exec this didnt work
[13:38] <zyga> jdstrand: I have a quick branch for working snap-confine with ns-sharing, I am still cooking it to contain the spread tests that I wrote
[13:39] <zyga> jdstrand: I didn't do the hat -> profile change update yet
[13:39] <morphis> mvo, ogra_: any idea about that error message?
[13:39] <zyga> jdstrand: do you know who sends the signal (in terms of apparmor peer) when prctl() set-parent-death-signal happens?
[13:40] <morphis> mvo, ogra_: generated a key locally
[13:40] <zyga> jdstrand, tyhicks: the relevant commit is: https://github.com/snapcore/snap-confine/commit/865c5dfb9704d71c16fafc2cf42ef95c1fd2933e
[13:40] <mvo> morphis: apt list snapd shows you 2.13? this still re-execs, please apt upgrade to 2.14.2
[13:40] <morphis> mvo: I've updated to 2.14.2
[13:41] <jdstrand> zyga: I was actually wondering how that would show up in policy myself. aiui, the kernel will send it, so guessing that our base abstraction will allow it
[13:41] <morphis> and added SNAP_REXEC=1 to /etc/environment
[13:41] <morphis> mvo: which gives me
[13:41] <morphis> Sep 08 15:22:25 nirvana /usr/lib/snapd/snapd[17662]: cmd.go:81: DEBUG: restarting into "/snap/ubuntu-core/current/usr/lib/snapd/snapd"
[13:41] <zyga> jdstrand: yes, I was expecting the kernel to send it as well
[13:42] <zyga> jdstrand: please comment on the profile there, I'll open a pull requst once I have a few more spread tests
[13:42] <mvo> morphis: uh
[13:43] <morphis> mvo: don't tell me that shouldn't be possible :-)
[13:43] <ogra_> morphis, nope, i never signed a model assertion ...
[13:44] <mvo> morphis: I'm slightly confused - so snapd is re-execing even with 2.14.2 ? SNAP_REEXEC=1 should be the only way to enable this
[13:44] <ogra_> and i dont think you can "just sign" it
[13:45] <ogra_> it must come from a valid store account
[13:45] <mvo> morphis: sorry for being a bit thick - do you want it to re-exec or do you want to disable that?
[13:45] <morphis> mvo: ok, lets correct this: I've added SNAP_REEXEC=1 to /etc/environment
[13:45] <morphis> mvo: and I want rexec
[13:45] <ogra_> mvo, he wants to know whats the default :)
[13:45] <mvo> morphis: ok, wit hthat setting it should re-exec
[13:45] <morphis> ogra_: I want snapd from edge on my desktop from the edge ubuntu-core snap :-)
[13:45] <mvo> morphis: the default is now (with 2.14.2) SNAP_REEXEC=0 unless you set it to something else
[13:46] <zyga> jdstrand: (separate topic) do you think snapd-xdg-open should be confined
[13:46] <zyga> jdstrand: it processes input from untrusted snaps
[13:46] <zyga> jdstrand: I was thinking aobut cooking a profile for it
[13:46] <mvo> morphis: so SNAP_REEXEC=1 should give you re-exec - but its not working you say?
[13:46] <ogra_> oh, why didnt i get a new snapd with todays upgrade
[13:47] <ogra_> ogra@styx:~/Devel/branches/ubuntu-core-snap$ snap --version
[13:47] <ogra_> snap    2.14.2~16.04
[13:47] <ogra_> snapd   unavailable
[13:47] <ogra_> series  -
[13:47] <ogra_> interesting
[13:47] <ogra_> that output changed a lot now
[13:47] <morphis> mvo: it works
[13:48] <morphis> mvo: I am now getting error messages when signing a model assertion
[13:48] <morphis> $ cat pi3.json| snap sign
[13:48] <morphis> error: cannot sign assertion: bad GPG produced signature: it does not verify: openpgp: invalid signature: RSA verification failure
[13:49] <mvo> morphis: aha, nice. well, not nice but progress. let me check
[13:49] <morphis> mvo: created a key with $ snap create-key which I know want to use to sign the model
[13:49] <morphis> mvo: yeah, one step forward
[13:52] <ogra_> hmm, so updating to snapd 2.14.2 seems to have killed everything for me
[13:53] <ogra_> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused
[13:53] <ogra_> ogra@styx:~$ snap --version
[13:53] <ogra_> snap    2.14.2~16.04
[13:53] <ogra_> snapd   unavailable
[13:53] <ogra_> series  -
[13:53] <ogra_> ogra@styx:~$
[13:53] <mvo> ogra_: anything in syslog? a crash or something?
[13:53] <ogra_> thats after a simple apt install snapd
[13:53] <ogra_> which got me upgraded
[13:54] <ogra_> mvo, yeah http://paste.ubuntu.com/23150243/ .... seems it is very unhappy that i had an ubuntu-coore from edge running
[13:55] <mvo> ogra_: yes, that is tricky
[14:11] <gQuigs> what does, snapd.refresh.timer: Adding 53min 43.246331s random time." mean?
[14:11] <gQuigs> and could it be messing with the system time (machine ends up off by a lot)
[14:12] <zyga> gQuigs: I think it means that systemd added a randomized interval to the refresh timer
[14:12] <zyga> gQuigs: there's a bug open on this but it feels like systemd is just very talkative
[14:13] <gQuigs> well than that's not the cause, thanks zyga!
[14:23] <jdstrand> ogra_: you probably noticed I approved all the ubuntu-core snaps
[14:23] <ysionneau> can someone validate (manual review) my tfacedetect snap on Parrot private store please? It's for an emergency demo
[14:23] <ogra_> jdstrand, ah, no i didnt ... did you approve more than 5 ? because we just did a test build to check if cprov's chaneg worked :P
[14:24] <ogra_> *change
[14:24] <ysionneau> "parrot_store_demo"
[14:24] <jdstrand> ogra_: they were all from 4 hours or more ago. I think it was more than 5
[14:24] <mup> PR snapd#1824 closed: tests: use ubuntu-image for the ubuntu-core-16 image creation <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1824>
[14:25] <ogra_> jdstrand, hmm, so the ones from 3min ago went through automatically then i guess ... great
[14:25] <ogra_> *33min
[14:26] <ogra_> well, let me just start another build ... it only takes 10-15 min
[14:26] <ogra_> cprov, smells like it worked ... but to be sure i'll do another one :)
[14:26] <jdstrand> ogra_: https://myapps.developer.ubuntu.com/dev/click-apps/4142/rev/539/ had r739 of the tools and it passed
[14:26] <jdstrand> so, yeah, looks good
[14:27] <ysionneau> anyone with admin rights on the stores?
[14:27] <ogra_> cprov, and thanks for the timeout fixes ... i can open the uploads overview again \o/
[14:27]  * ogra_ wonders if the stats page also works
[14:29] <ogra_> ah, well, that still times out
[14:32] <morphis> pedronis: already back to work? :-)
[14:32] <ogra_> run pedronis run !
[14:37] <cprov> ogra_: stats page was not worked on yet, revision history and snap-release are quick enough now.
[14:38] <ogra_> yeah, totally ...
[14:38] <morphis> mvo: already any idea what could be wrong?
[14:38] <ogra_> thanks so much !
[14:42] <mvo> morphis: sorry, not yet, could you pastebin yourjson? but it might be something for pedronis, he worked on this recently, we don't have a spread test unfortunately so it might simply be not fully working yet
[14:42] <morphis> ok
[14:43] <morphis> mvo: was just wondering as he gave me a tool to create a set of test keys and with that it works fine
[14:43] <morphis> so looks like something with the setup of create-key is wrong
[14:46] <morphis> mvo: https://paste.ubuntu.com/23150420/
[14:48] <cjwatson> elopio: can you help me see why the autopkgtests in https://github.com/snapcore/snapcraft/pull/726 are failing?  it sort of looks like they might be taking test dependencies from master rather than from the PR branch, but I could be wrong
[14:48] <mup> PR snapcraft#726: Implement basic form of `snapcraft register-key` <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/726>
[14:48] <cjwatson> (assuming you're the right person to ask, I'm not really sure)
[14:49] <kyrofa> cjwatson, you're correct, he's the person you want. He may not be in for a little bit yet, though
[15:02] <elopio> cjwatson: give me a few minutes
[15:10] <elopio> cjwatson: the jenkins job only sends adt-run to the testbed, and it takes care of the installation and dependencies.
[15:10] <cjwatson> I can't work out why snapd wouldn't be installed; it's listed in Depends in debian/tests/control
[15:11] <elopio> cjwatson: didn't you say that this depends on a feature that's not yet in xenial-updates? If so, we might need to install it before adt-run.
[15:11] <mup> PR snapd#1874 opened: snap: support assertion references in `snap prepare-image` <Created by mvo5> <https://github.com/snapcore/snapd/pull/1874>
[15:11] <cjwatson> elopio: it's in xenial-updates as of yesterday
[15:11] <cjwatson> so I don't think that explains it
[15:12] <elopio> cjwatson: the error is not that snapd is not installed, it's unknown flag json. pexpect sucks when the output is too different from what you expect.
[15:12] <elopio> so, as far as I know, this machines should have -updates enabled. Let me check.
[15:12] <cjwatson> true; but there's no record of snapd being installed in the console log
[15:13] <cjwatson> oh, maybe it's preinstalled and I need to force the version?
[15:13] <cjwatson> that could make a certain amount of sense
[15:13] <elopio> that makes sense, true.
[15:14]  * cjwatson tries that
[15:14] <cjwatson> autopkgtest snaps is I think definitely not my problem
[15:15] <elopio> but you have this line in tests/control: snapd (>= 2.14.2~) I thought that would make adt-run update the preinstalled one.
[15:17] <elopio> I'm checking if the demos work in master.
[15:27] <mup> Bug #1621525 opened: classic environment variables for daemon snaps <Snappy:New> <https://launchpad.net/bugs/1621525>
[15:27] <elopio> hah, I undersetand now, you have just added that. Too fast.
[15:30] <balloons> zyga, any news on when snap-confine 1.0.40 will hit xenial?
[15:47] <elopio> cjwatson: this https://github.com/snapcore/snapcraft/pull/778 and a change in a branch by sergiusens are required to get the snaps suite back to green.
[15:47] <mup> PR snapcraft#778: Use --force-dangerous when testing the installation of snaps <Created by elopio> <https://github.com/snapcore/snapcraft/pull/778>
[15:47] <elopio> nothing to do with your change.
[15:47] <nacc> is there a direct link to the agreement that needs to be signed before uploading snaps?
[15:49] <mup> PR snapcraft#778 opened: Use --force-dangerous when testing the installation of snaps <Created by elopio> <https://github.com/snapcore/snapcraft/pull/778>
[15:56] <cjwatson> elopio: glad to hear it - and indeed autopkgtest integration passes on my branch now
[15:58] <elopio> cjwatson: \o/ thanks. sergiusens: so waiting for your review.
[15:58] <elopio> nacc: maybe nessita or noise][_` can help you there.
[15:59] <nacc> elopio: thanks!
[16:00] <cjwatson> nacc: https://myapps.developer.ubuntu.com/dev/tos/
[16:02] <nacc> cjwatson: thanks!
[16:02] <cjwatson> nacc: or https://myapps.developer.ubuntu.com/dev/agreements/new/ if what you want is a link that will prompt for a signature if the developer hasn't already signed it rather than just the text (but it redirects to /dev/click-apps/ if they have)
[16:05] <nacc> cjwatson: got it, thanks!
[16:05] <ogra_> booo ...
[16:05] <nacc> rharper: --^ does that help? :)
[16:06] <ogra_> snapctl breaks autocompletion for the snapcraft command now :P
[16:06] <ogra_> (well, doesnt break but if i need to type snapcr<tab> i can as well type the full thing)
[16:07] <kyrofa> ogra_, heh, sorry about that
[16:07] <kyrofa> ogra_, hopefully eventually we can move it into /usr/lib/snapd, but snap-confine doesn't currently support updating the PATH
[16:07] <ogra_> ah, cool then
[16:13] <mup> PR snapcraft#779 opened: Do not compile pyc files when installing with pip <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/779>
[16:17] <rharper> nacc: thanks!
[16:19] <nacc> rharper: np
[16:34] <SamYaple_> sergiusens: adding in some python stuffs. Was the plan to unify the test suites as well? we are still duping alot between python2 and python3 in the test suites
[16:34] <SamYaple_> sergiusens: my vote would be a new python test and then just test the python2 and python3 bits explicitly to maintain the backwards compat until fully deprecated
[16:40] <zyga> balloons: it almost has, we SRU'd most of the patches. my plan is to release .41 soon and SRU that
[16:42] <zyga> jdstrand: thanks for spotting another -1 :)
[16:42] <zyga> jdstrand: I'll fix that in a moment
[16:43] <jdstrand> :)
[16:43] <zyga> jdstrand: did you have a look at the real thing?
[16:43] <jdstrand> I'm going through the whole thing now
[16:43] <zyga> jdstrand: I"m somewhat worried about the cgroup there, feels like we should think how shared mnt namespace + cgroup interact
[16:43] <zyga> thanks! I just returned and I'm available
[16:44]  * zyga finally emerged haskell toolchain on gentoo, geez that took forever
[16:51] <balloons> zyga, I ask because the issue with juju snap and lxd isn't fixed in the SRU'd patches
[16:51] <balloons> so any ETA? Will it be there before next week? Possible?
[16:51] <zyga> balloons: can you point me to those issues?
[16:52] <balloons> zyga, https://bugs.launchpad.net/snap-confine/+bug/1613845
[16:52] <mup> Bug #1613845: Juju snap can no longer interact with LXD in devmode <conjure> <Snappy Launcher:Fix Released by zyga> <https://launchpad.net/bugs/1613845>
[16:52] <mup> Bug #1621550 opened: Snappy should detect when running in KVM, specify correct ssh connection line <Snappy:New> <https://launchpad.net/bugs/1621550>
[16:52] <zyga> balloons: lxd has a quirk that owrks in devmode
[16:52] <zyga> balloons: right, that might not be SRUd
[16:52] <balloons> zyga, it's not. But 1.0.40 does solve it
[16:52] <zyga> balloons: because we were working on SRUing higher priority tasks
[16:52] <balloons> jcastro, ^^
[16:54] <popey> can someone please help with this:- http://paste.ubuntu.com/23150846/ - login there and yaml - the command never runs, seems to barf at the wrapper
[16:54] <popey> suggestions welcome
[16:54] <balloons> zyga, the charmers summit is next week, and we'd love to highlight using snaps to get juju, but this breaks the story. That's why I was asking
[16:54] <popey> (it is a very simple yaml)
[16:54] <zyga> balloons: let me check the SRU queue
[16:55] <zyga> looking at http://people.canonical.com/~ubuntu-archive/pending-sru.html I see snap-confine but (I'm not super familiar with the report) I don't think it is currently in flight
[16:56] <balloons> zyga, https://launchpad.net/ubuntu/+source/snap-confine/1.0.38-0ubuntu<IP_ADDRESS> doesn't have it, which was in proposed
[16:57] <zyga> balloons: if you can help with the SRU I'd love to do it
[16:57] <zyga> balloons: I cannot dput though (I'm not a core dev)
[16:58] <balloons> zyga, ahh. But it would just need sponsered is all
[16:58] <zyga> balloons: but I can try to work on the paperwork when it is avaialble
[16:58] <zyga> balloons: does it have to be in yakkety fifst?
[16:58] <balloons> zyga, is there a reason you would pursue cherrypicking, rather than just sru 1.0.40 that is already in yakkety?
[16:58] <zyga> first?
[16:59] <zyga> balloons: that's what we did before becasue we couldn't get an effective SRU for many weeks
[16:59] <mhall119> sergiusens: has there ever been a discussion about having an "exec" plugin that would let you run some script or binary at build-time in snapcraft?
[16:59] <balloons> zyga, as 1.0.40 is in yakkety, it should just be a matter of uploading it to the xenial queue and asking for an SRU
[16:59] <zyga> balloons: so we tried to SRU the essential thing each time so that nothingh would regress and we would not risk any daly
[16:59] <zyga> balloons: can you do that?
[17:00]  * zyga should apply for per-package upload rights
[17:00] <balloons> yes, you should :-)
[17:00] <balloons> I cannot upload, but we can get someone to sponsor
[17:01] <zyga> slangasek: could you perhaps sponsor snap-confine from yakkety into xenial-proposed so that we can work on an SRU
[17:07] <slangasek> zyga: "so you can work on an SRU" - what do you mean by that? isn't the work of an SRU the preparation of the SRU bug and the preparation of the upload?
[17:08] <zyga> slangasek: we just need to get the upload in the queue so that I can work on the paperwork
[17:08] <zyga> slangasek: I'd like to do the full process once but I cannot upload
[17:12] <zyga> jdstrand: thank you for the review, I'll fix the trivials and work on statfs change
[17:16] <nacc> zyga: you can do the SRU paperwork (by which do you mean the bug update?) without the upload being in the queue
[17:18] <zyga> nacc: ah, I see, so I should file the bug, document everything (delta from the desired version and proposed)?
[17:19] <slangasek> zyga: you should absolutely file the bug first, the bug has to be referenced in the changelog of the SRU
[17:19] <sergiusens> mhall119 yes there has, https://github.com/snapcore/snapcraft/pull/727, the general consensus is it wouldn't be in core
[17:19] <mup> PR snapcraft#727: Add a new build plugin 'shell' that runs arbitrary shell commands <Created by Magical-Chicken> <Conflict> <https://github.com/snapcore/snapcraft/pull/727>
[17:20] <zyga> slangasek: understood
[17:20] <sergiusens> SamYaple_ yeah, unifying the tests would be good
[17:20] <nacc> zyga: yeah, that's my usual approach, get the bug filed first, prep per the template, then subscribe sponsors, etc.
[17:26] <mhall119> thanks sergiusens, I assumed it would have come up before
[17:28] <sergiusens> mhall119 that is not the first one, but we kept it open to not repeat ourselves all the time ;-)
[17:32] <jdstrand> zyga: thanks for all the changes! I thought your comment changes were great
[17:37] <zyga> jdstrand: I'm not sure about this typo; can you please show me where it is? https://github.com/snapcore/snap-confine/pull/126#discussion_r78042899
[17:37] <mup> PR snap-confine#126: Add support module for namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/126>
[17:44] <mup> Bug #1621568 opened: Unable to access system fonts <Snappy:New> <https://launchpad.net/bugs/1621568>
[17:44] <jdstrand> zyga: you have populate*d*
[17:46] <jdstrand> zyga: oh wait. you added sc_should_populate_ns_group. please disregard
[17:52] <zyga> jdstrand: ah, sorry, yes  there was a discrepancy in that function name for a moment
[17:52] <zyga> jdstrand: thanks!
[17:53]  * zyga learned a lot of cool things while working on snap-confine and its test suite
[17:53] <balloons> zyga, are you all set for the SRU then? It should be a matter of filing the bug, and preparing a source branch to hand off
[17:53] <zyga> balloons: filing the bug, yes, preparing source branch, not sure what that entails yet
[17:53] <balloons> zyga, it shows you as the creator of 1.0.40 on yakkety -- what branch did you use?
[17:54] <zyga> balloons: git.launchpad.net/snap-confine AFAIK
[17:55] <zyga> balloons: there's a git repo there with packaging for all ubuntu releases
[17:55] <zyga> balloons: this is modeled after fedora's fantastic fedpkg workflow but all it is is the debian directory in a git tree
[17:55] <balloons> zyga, did mvo do all the archive work then? I see you as the package uploader
[17:56] <zyga> balloons: perhaps, I don't quite know, I did send a source package to him a while ago
[17:56] <zyga> balloons: I think it may have been uploaded through debian
[17:56] <zyga> balloons: but my memory is very rusty there
[17:56]  * zyga promises to work with mwhudson on collab-maint for snap-confine now
[17:57] <balloons> zyga, I suppose to be fair since the yakkety build works as-is on xenial you could reuse the source package
[17:58] <balloons> have you filed an SRU before?
[17:58] <zyga> balloons: I was working on kernel SRUs in the cert team but I didn't really do an SRU for other things entirly by myself I think
[17:58] <zyga> perhaps eons ago for pyotherside
[18:00] <balloons> zyga, file a bug like this: https://bugs.launchpad.net/ubuntu/+source/snap-confine/+bug/1593396
[18:00] <mup> Bug #1593396: [SRU] 1.0.38-0ubuntu<IP_ADDRESS> <snap-desktop-issue> <verification-needed> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1593396>
[18:01] <balloons> zyga, the full procedure and template is here: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[18:05]  * zyga nods
[18:05] <zyga> I'll look at that first thing tomorrow
[18:11] <mup> Bug #1621575 opened: Poorly worded error when installing a local snap without assertions <Snappy:New> <https://launchpad.net/bugs/1621575>
[18:17] <mup> Bug #1619718 changed: ubuntu-image created vfat eats itself after a while (mcopy creates wrong subdirs) <verification-needed> <Snappy:Fix Released> <Ubuntu Image:Invalid> <mtools (Ubuntu):Fix Released by vorlon> <ubuntu-image (Ubuntu):Fix Released> <mtools (Ubuntu Xenial):Fix Committed by vorlon>
[18:17] <mup> <ubuntu-image (Ubuntu Xenial):Invalid> <https://launchpad.net/bugs/1619718>
[18:22] <zyga> jdstrand: does this look good? https://github.com/snapcore/snap-confine/pull/126/commits/40a93a241b1fbfc34c6eb6b9e87f951b218ee1c7
[18:22] <mup> PR snap-confine#126: Add support module for namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/126>
[18:23] <zyga> jdstrand: all I have to fix left is rm_rf sanity checks
[18:23] <zyga> jdstrand: I'd like to merge this and then propose the branch that makes snap-confine use things :)
[18:26] <mup> PR snapcraft#780 opened: Organize without removing files on target <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/780>
[18:32] <Pharaoh_Atem> zyga: whoa, you're following dist-git style for snap-confine ubuntu packaging?
[18:33] <zyga> Pharaoh_Atem: so far :) It's not fully live yet because of lots of things that we had to do ASAP but I was wondering how to use that for packaging more reliably
[18:33] <zyga> Pharaoh_Atem: (in debian and ubuntu)
[18:38] <zyga> Pharaoh_Atem: if you want to know what I'm up to lately look at the pull request referenced above, it's pretty neat stuff :)
[18:38] <elopio> sergiusens: back to green: https://github.com/snapcore/snapcraft/pull/778
[18:38] <mup> PR snapcraft#778: Use --force-dangerous when testing the installation of snaps <Created by elopio> <https://github.com/snapcore/snapcraft/pull/778>
[18:40] <Pharaoh_Atem> zyga: well, I'd definitely be happy to see ubuntu adopt a dist-git style system
[18:40] <Pharaoh_Atem> makes it much easier to figure out what's going on :)
[18:41] <zyga> well, not ubuntu, it's just me trying but I think I'll stick to it if I can :)
[18:42] <zyga> Pharaoh_Atem: snapd-xdg-open was released upstream AFAIK, I'll look at updating my spec files and I think it should be good to go
[18:42] <Pharaoh_Atem> did you get around to snapd-glib too?
[18:42] <zyga> Pharaoh_Atem: I have what I did before, without the correct package split, if you want I can show you what I got
[18:42] <zyga> Pharaoh_Atem: (so no -devel and stuff)
[18:42] <Pharaoh_Atem> sure
[18:43] <zyga> Pharaoh_Atem: one moment, I ran out of ram with gentoo emering webkit lately so I had to shut everything but gentoo down
[18:44] <mup> PR snapcraft#778 closed: Use --force-dangerous when testing the installation of snaps <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/778>
[18:52] <kgunn> yo, has anyone ever run into missing socket?...like so...
[18:52] <kgunn> kg@kg-MacBookPro:~$ snap list
[18:52] <kgunn> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd-snap.socket: connect: no such file or directory
[18:53] <kyrofa> kgunn, are you up-to-date?
[18:54] <kgunn> kyrofa: updated 2 days back
[18:54] <kgunn> kyrofa: i'm on xenial + stable-phone-overlay enabled
[18:54] <kyrofa> kgunn, core snap is up to date as well?
[18:54] <kgunn> full disclosure :)
[18:54] <kyrofa> kgunn, heh, I always assume you're using that
[18:55] <kgunn> kyrofa: let me update real quick
[18:55] <kyrofa> kgunn, yeah, make sure. That was an issue last week, but it should be fixed by now
[18:59] <zyga> re
[18:59] <zyga> Pharaoh_Atem: ok, I got my fedora up
[19:02] <zyga> Pharaoh_Atem: http://paste.ubuntu.com/23151324/
[19:02] <zyga> Pharaoh_Atem: (that's not much :)
[19:03] <Pharaoh_Atem> it's a good start, at least
[19:03] <zyga> Pharaoh_Atem: that's 0.8, 0.10 was released with some fixes (license is one of them)
[19:03]  * zyga looks at refreshing that
[19:03] <Pharaoh_Atem> I'm impressed that you're using the common name provides
[19:03] <Pharaoh_Atem> it'll enable you to reuse the spec for openSUSE relatively easily
[19:04] <zyga> I love them because they speak in the language of the problem
[19:04] <zyga> the upstream pkg-confing names
[19:04] <zyga> pkg-config*
[19:05] <Pharaoh_Atem> the whole reason these things exist is because it's a way for us to guarantee a resource, be it a build dep or a runtime dep
[19:05] <Pharaoh_Atem> regardless of packaging style
[19:06] <zyga> some of the build-deps there aren't perfect, I don't quite know how vala tooling looks like today and the set I have there is what seems to work but I suspect a smaller set is sufficient
[19:06] <Pharaoh_Atem> I usually use the build system as a reference to figure out build deps
[19:07] <mup> PR snapd#1815 closed: interfaces: auto-connect interface required by livepatch <Created by arges> <Closed by arges> <https://github.com/snapcore/snapd/pull/1815>
[19:07] <kgunn> kyrofa: just sharing, fwiw, not sure how it got goofed...but apt-get install --reinstall snapd, then systemctl start snapd did the trick
[19:07] <Pharaoh_Atem> oh good, you are moving from com.canonical.* to io.snapcraft.*
[19:07] <kyrofa> kgunn, huh, yeah odd
[19:07] <Pharaoh_Atem> I was hoping that would happen
[19:09] <zyga> just a little more and I'll have updates for 0.14
[19:11] <Pharaoh_Atem> have you at least tested my selinux policy module for snapd on f24?
[19:12] <zyga> Pharaoh_Atem: http://paste.ubuntu.com/23151347/
[19:12] <zyga> Pharaoh_Atem: no, not yet, I really have to finish snap-confine features first
[19:12] <zyga> Pharaoh_Atem: I did some work on gentoo but not much either
[19:13] <zyga> Pharaoh_Atem: I want to get gentoo overlay up-to-date which is easy, just takes NaN minutes to build
[19:13] <zyga> Pharaoh_Atem: I did read your code though
[19:13] <zyga> Pharaoh_Atem: it's just that I'm still super-green with selinux in practice, I would not be able to write that my self yet
[19:16] <zyga> Pharaoh_Atem: I pushed the partial packaging to my snapcore-fredora repo, I'll look at the proper splitting policy down the week
[19:36] <jdstrand> zyga: sorry was in a meeting and had some followups. looking
[19:36] <mup> PR snapd#1866 closed: many: add snap configuration to REST API <Reviewed> <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1866>
[19:39] <zyga> jdstrand: no worries, thanks!
[19:53] <zyga> jdstrand: I added a sanity test to ensure my reasoning on nsfs is accurate: https://github.com/snapcore/snap-confine/pull/126/commits/db1a0765f6b058ab24df30931c2f357b57f243f2
[19:53] <mup> PR snap-confine#126: Add support module for namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/126>
[19:56] <mup> PR snapcraft#726 closed: Implement basic form of `snapcraft register-key` <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/726>
[20:02] <mup> PR snapcraft#776 closed: Updated the contents of the snapcraft init template <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/776>
[20:03] <sergiusens> SamYaple_ still around?
[20:03] <sergiusens> SamYaple_ asked a question in snapcraft#779 ; last time they went unnoticed so making sure this one doesn't :-)
[20:03] <mup> PR snapcraft#779: Do not compile pyc files when installing with pip <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/779>
[20:04] <jdstrand> zyga: nice
[20:06] <zyga> jdstrand: :) I'll fix rm_rf and merge
[20:07] <zyga> jdstrand: I'll double check I didn't miss anything
[20:07] <SamYaple_> sergiusens: looking
[20:09] <SamYaple_> sergiusens: i noticed there were still some pyc files, but not all of them. im still not sure why. the fact remains there were less and it did shave of build time
[20:10] <SamYaple_> sergiusens: oh you know what i just had a thought. I wonder if some of the pyc files are getting created when other python packages are getting installed, something importing other python packages on install or somehting
[20:12] <jdstrand> zyga: hey, while you are in there, I noticed that snap-confine needs this when running over ssh: /dev/pts/[0-9]* rw,
[20:13] <jdstrand> apparmor="DENIED" operation="file_inherit" profile="/usr/lib/snapd/snap-confine" name="/dev/pts/2" pid=28375 comm="ubuntu-core-lau" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000
[20:13] <jdstrand> zyga: I noticed this ssh'ing into a xenial classic system and using 'hello-world'
[20:14] <jdstrand> zyga: I can do a PR if it is easier
[20:26] <jdstrand> zyga: hoping you are EOD. I'll do a PR
[20:31] <jdstrand> zyga: fyi, https://github.com/snapcore/snap-confine/pull/128
[20:31] <mup> PR snap-confine#128: allow read/write to /dev/pts/[0-9]* needed for running snaps under ssh <Created by jdstrand> <https://github.com/snapcore/snap-confine/pull/128>
[20:35] <sergiusens> SamYaple_ that might be it
[20:37] <zyga> jdstrand: hmm, curious why is that?
[20:37] <zyga> jdstrand: I work over ssh all day
[20:37] <zyga> jdstrand: and I didn't need it
[20:37] <sergiusens> SamYaple_ setup the env with https://docs.python.org/3/using/cmdline.html#envvar-PYTHONDONTWRITEBYTECODE
[20:38] <sergiusens> SamYaple_ maybe even in `env` so we don't get warnings when running from the snap even
[20:40] <zyga> jdstrand: could it be ssh + screen or something like that?
[20:40] <zyga> jdstrand: (the hint there is "file_inherit" btw)
[20:41] <jdstrand> zyga: I suspect it has something to do with it being a classic system. I didn't dive into why. I'm not doing anything special
[20:41]  * jdstrand nods
[20:41] <jdstrand> I'm not using screen
[20:41] <jdstrand> oh I know
[20:41] <jdstrand> it is cause I am using pam-apparmor on that box
[20:42] <jdstrand> sshd is confined
[20:42] <mup> PR snapcraft#780 closed: Organize without removing files on target <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/780>
[20:42] <jdstrand> zyga: ^
[20:42] <zyga> ah, interesting
[20:42]  * zyga investigates pam-apparmor
[20:43] <jdstrand> zyga: The inherited fd is mediated since it isn't coming from an unconfined process.
[20:43] <jdstrand> that's why
[20:44] <jdstrand> so, nothing to do with classic per se
[20:44]  * jdstrand modifies the comment
[20:45] <zyga> jdstrand: ah, now I understand
[20:45] <zyga> jdstrand: thanks for researching this, I'd like to have a bug for tracking this so that the release can refer to it
[20:45] <zyga> jdstrand: I can file one if you wnat
[20:46] <jdstrand> I can do it
[20:46] <zyga> jdstrand: thanks, please use Fixes: ... in the commit and I'll happily merge it
[20:46] <zyga> jdstrand: I can smell 1.0.41 coming out soon :)
[20:46] <jdstrand> zyga: does Fixes need to be in the first line or the nody?
[20:46] <jdstrand> body*
[20:46] <zyga> jdstrand: like signed-off-by
[20:46] <mup> PR snapd#1875 opened: Add /dev/net/tun device to network-control apparmor rules <Created by cmars> <https://github.com/snapcore/snapd/pull/1875>
[20:47] <zyga> jdstrand: I just use it for easy linking
[20:47] <zyga> jdstrand: it's not a standard of any kind I think
[20:47] <zyga> (works nicely for x-ref between github and launchpad
[20:48] <mup> Bug #1621623 opened: OpenVPN needs access to /dev/net/tun, proposal to add it to network-control interface <Snappy:New> <https://launchpad.net/bugs/1621623>
[20:48] <mup> PR snapd#1876 opened: cmd/snap: make "snap find" error nicer <Created by chipaca> <https://github.com/snapcore/snapd/pull/1876>
[20:56] <jdstrand> zyga: ok, done
[21:01] <zyga> jdstrand: merged
[21:01] <jdstrand> thanks!
[21:06] <mup> PR snapcraft#773 closed: parser - Handle project name and version variables <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/773>
[21:12] <mup> PR snapcraft#781 opened: Workaround bzr with auth proxies <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/781>
[21:12] <sergiusens> ogra_ please try that ^
[21:27] <mhall119> zyga: does /opt/ inside a snap map to the system's /opt/ or is it owned by the snap?
[21:37] <kyrofa> mhall119, probably the core snap
[21:42] <mhall119> kyrofa: is there any pre-determined path that equates to ${SNAP}?
[21:42] <kyrofa> mhall119, no, though I've used the /snap/snapname/current symlink before
[21:43] <mhall119> ok, I'll go with that then
[21:44] <kyrofa> mhall119, beware that isn't standardized across distros
[21:44] <kyrofa> I believe it's in a different place in fedora, for instance
[21:44] <mhall119> kyrofa: not from the snap's perspective, zyga says the snap will see /snap/ no matter where it's actually located on the host
[21:45] <kyrofa> Hmm... okay
[22:02] <mup> PR snapd#1877 opened: many: maintain all snap configurations in state <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1877>
[22:25] <elopio> sergiusens: if I have a tar file, but the source is in a subdirectory, I should use source-subdir, right?
[22:26] <elopio> I'm having a problem trying to build erlang. The subdir contents are copied to build, but then it tries to compile from build/subdir.
[22:41] <elopio> nevermind, sergiusens unping. The problem is that bootstrap exists, but it's a directory.
[22:45]  * Son_Goku sighs
[22:45] <Son_Goku> zyga, ping
[22:59] <ogra_>  sergiusens neat !!! will try tomorrow
[23:13] <qengho> How is one supposed to use $SNAP_USER_COMMON ?
[23:15] <qengho> When my app starts, that directory doesn't exist. And I don't have permission to mkdir it, it seems. "mkdir: cannot create directory '/home/username/snap/snapname/common': Permission denied"
[23:16] <qengho> snapd v 2.14.1+16.10
[23:17] <qengho> Maybe this next version of snapd ....
[23:21] <mup> PR snapcraft#782 opened: Fix gulp plugin's npm install prefix <Created by AlexandreAbreu> <https://github.com/snapcore/snapcraft/pull/782>
[23:22] <mup> Bug #1621324 opened: On the all-snaps image, snappy-debug.security can't access syslog <Snappy:Confirmed> <livecd-rootfs (Ubuntu):New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621324>
[23:31] <mup> Bug #1609965 changed: snapweb store is a blank page <Snappy:Fix Released> <snapweb:Fix Released> <https://launchpad.net/bugs/1609965>
[23:34] <mup> Bug #1621666 opened: It is possible to install the classic snap in a classic system <classic> <Snappy:New> <https://launchpad.net/bugs/1621666>


[07:21] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4400 Needs rebuild due to higher version at destination
[07:21] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4401 Needs rebuild due to higher version at destination
[08:22] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4403 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[09:24] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4403 Failed to build
[12:24] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4403 Diff missing
[13:36] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4402 Preparing packages
[14:03] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4402 Failed to build (hirsute/autopilot). Successfully built (hirsute/bamf)
[14:25] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4402 Preparing packages
[15:23] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4402 Pending binary packages (hirsute/autopilot). Successfully built (hirsute/bamf)
[15:43] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4402 Successfully built
[17:25] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4402 Preparing packages
[18:23] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4402 Pending binary packages (hirsute/autopilot). Successfully built (hirsute/bamf)
[19:03] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4402 Successfully built