[06:58] <al-maisan> Good morning
[07:36] <noodles775> gmb: I'm just updating those comments in the js-test - you're right, I can see how it's now much easier to read as a dev. :)
[09:06] <noodles775> allenap: I'll have one ready for you in 5 :)
[09:07] <allenap> noodles775: Jolly good :)
[09:32] <noodles775> allenap: thanks! https://code.launchpad.net/~michael.nelson/launchpad/432152-orig-file-counts/+merge/12645
[09:32] <allenap> noodles775: Cool.
[10:16] <allenap> noodles775: I don't understand the query really. It reads like you're selecting distinct LFAs.filename where the corresponding content is the same size.
[10:17] <allenap> noodles775: I don't understand how that can be a valid thing to ask for, so maybe that's explained by the other clauses in the query.
[10:19] <noodles775> allenap: I'm just wanting distinct filenames to then sum the size - it just so happens that when the lfas with the same filename will also have the same size.
[10:19] <noodles775> allenap: the unit test might help to demo what it's doing?
[10:19] <allenap> noodles775: I should probably read it :)
[10:30] <allenap> noodles775: If I apply http://pastebin.ubuntu.com/282003/ to your branch, the tests still pass (note the differing filecontent). Should that happen?
[10:31]  * allenap will be back in ~5-10 minutes.
[10:31] <noodles775> allenap: yes, that's correct.
[10:32] <noodles775> allenap: it should fail if you change the name.
[10:32] <noodles775> allenap: ah, I see... the filecontent is the actual content, not the length, so if you use filecontent='222' (ie. 3 bytes) it should also fail.
[10:42] <allenap> noodles775: When does it not matter if the content is different but the size the same?
[10:42] <noodles775> allenap: the query is only checking the filesize - not the filecontent.
[10:43] <noodles775> For publishing tarballs/dsc files, (according to cprov), the fact that the filename is the same is enough to ensure that they are the same file (in that archive).
[10:43] <allenap> noodles775: Ah, okay, that's what I was looking for :)
[10:43] <noodles775> But it might make it clearer if we also include the LFC.sha1 in the query, so it's obvious that that's what's happening (I tried to clarify that in the comment, but it's still confusing).
[10:45] <allenap> noodles775: Yeah, including the sha1 will probably document this better, and will also mean that future developers don't suspect a smell when there isn't one because of the data model.
[10:46] <noodles775> allenap: great, I'll do that then.
[11:02] <allenap> noodles775: Thanks, r=me, with one other suggestion, which you are welcome to ignore if you don't like it.
[11:02] <noodles775> Thanks allenap !
[12:06] <stub> allenap, jtv: https://code.edge.launchpad.net/~stub/launchpad/librarian-gc/+merge/12650 , https://code.edge.launchpad.net/~stub/meta-lp-deps/updates/+merge/12322 , https://code.edge.launchpad.net/~stub/launchpad/sanitize-db/+merge/12520
[12:06] <stub> (in order both smallest to largest and in priority too)
[12:06] <jtv> just when the lunch gong goes...
[12:06] <jtv> allenap: shall I take that last one then?
[12:07] <allenap> stub: Is the first the highest or lowest priority?
[12:07] <stub> first is highest since it might need to be cherry picked.
[12:08] <allenap> jtv: Perhaps you should do the first then.
[12:09] <jtv> allenap: okay
[12:09] <allenap> jtv: I am about to go to lunch too :) But I'll pick up as soon as I'm back.
[12:10] <allenap> Sorry stub, looks like both of us are afk now. Nothing to do with you, well, on my part at least :)
[12:10] <stub> k
[12:25] <thumper> sinzui: https://code.edge.launchpad.net/~thumper/launchpad/rehash-branch-index/+merge/12651
[12:29] <jtv> stub: I'm surprised to hear that the librarian-gc branch fixes anything (unless content_id is None as well), since AFAIK None < anything
[12:30] <stub> None < some_integer == True
[12:30] <stub> We don't want that test to pass if next_wanted_content_id is None
[12:31] <jtv> stub: oic
[12:31] <stub> Or we would be reporting 'LibraryFileContent None exists in the database', or we would if it didn't crash when trying to format None as an integer.
[12:34] <jtv> stub: I can't help feeling that that loop would be a lot prettier with the config check outside it, but if this is for CP...
[12:34] <jtv> It would be good to have a test though.
[12:36] <stub> jtv: Hmm.... I don't see that working as I still need to lookup the next wanted id even if there is an upstream librarian
[12:37] <stub> I was hoping nobody noticed the lack of test ;)
[12:38] <stub> Now I have to work out what actually triggers this case :)
[12:38] <stub> I think it occurs if the highest id isn't wanted
[12:38] <jtv> it can avoid disappointments...
[12:39] <stub> (Hmm.... that should be a generator really)
[12:45] <jtv> stub: to get me into the right context: is this a CP candidate?
[12:46] <stub> jtv: Yes
[12:46] <stub> I can try adding a test in a minute
[12:47] <jtv> stub: I'd appreciate that
[12:57] <stub> Oh sod off. I know there is another mp for this branch.
[12:57] <stub> facist review system :-P
[12:58] <stub> Can http://paste.ubuntu.com/282095/ be reviewed without a mp ?
[13:03] <jtv> stub: you could stick a tinyurl on the queue
[13:03] <stub> np. worked out how to do the resubmit.
[13:04] <stub> https://code.edge.launchpad.net/~stub/launchpad/memcache/+merge/12653
[13:05] <jtv> stub: that second branch has a review request for Francis... do I take it you don't want to wait for that?
[13:05] <stub> If you know anything about debian packaging, sure.
[13:06] <jtv> stub: rusty, but this looks pretty trivial.  Why don't you tell me what could go wrong?
[13:06] <stub> I just assigned francis as he suggested this workflow and it sat there for a few days ignored ;)
[13:06] <stub> jtv: I have no idea what could go wrong. I don't even know what happens after it gets merged in to build the package ;)
[13:08] <jtv> stub: well my apt has no objections to installing memcached, so you've got my imprimatur
[13:09] <jtv> stub: any progress on test?
[13:09] <stub> jtv: Nah - reject it and I'll resubmit when I have something
[13:09] <jtv> stub: as you wish
[13:20] <noodles775> allenap, jtv: just in case you get to it before I'm back, my MP is here: https://code.launchpad.net/~michael.nelson/launchpad/436182-newlines-in-sources-bz2-indices/+merge/12655
[13:20] <allenap> noodles775: Cool.
[13:22] <jtv> noodles775: in call
[13:22] <jtv> will get back later
[13:56] <deryck> I want a ☎
[13:56] <deryck> allenap, hi
[13:57] <allenap> deryck: Hi
[13:58] <deryck> allenap, I have a small branch, but can I leave it on the queue for offline review.  About to return to tl sprint stuff.
[13:58] <allenap> deryck: Okay, cool.
[13:58] <deryck> allenap, thanks!
[13:59] <deryck> allenap, never mind.  gpg fail on new laptop setup.  will catch up later about it.
[13:59] <allenap> stub: Does ALTER TABLE not implicitly commit a transaction?
[13:59] <allenap> deryck: Heh :)
[14:14] <stub> allenap: No. PG is entirely transactional that way.
[14:28] <jtv> allenap: which one for stub is still on the queue?
[14:28] <allenap> jtv: https://code.edge.launchpad.net/~stub/launchpad/memcache/+merge/12653 I think
[14:28] <jtv> allenap: ok
[14:36] <jtv> stub, about the memcached test: why not self.assertEqual(self.want_memcached, is_live)?
[14:37] <stub> jtv: Better error messages
[14:40] <jtv> I guess...
[14:41] <jtv> Something that bugs me about layers: can't we have split-transaction startup & teardown?
[14:42] <stub> What do you mean?
[14:43] <jtv> So e.g. memcached can start gearing up before Librarian has completed its startup, or vice versa.
[14:43] <jtv> Put those extra cores to work.
[14:43] <stub> jtv: Not out of the box.
[14:44] <jtv> Shame.
[14:44] <jtv> On a different note: in Memcachedlayer.setUp, you assign test_key twice, sort of defeating the purpose.
[14:44] <stub> jtv: We could do it ourselves if we wanted - launch stuff in separate threads and block until they are all ready, but nobody has tried that yet.
[14:44] <stub> I did?
[14:44] <jtv> Well somebody did
[14:45] <stub> fixed
[14:45] <jtv> stub: http://paste.ubuntu.com/282095/ lines 150 & 168
[14:47] <jtv> I'm not a huge fan of firing off threads for this sort of thing, since it gets hard to manage.  But why sit around looping for your service to become available when you could just return and let the next service start?  Managing dependencies is a bitch, of course.
[14:48] <stub> I wouldn't want to bother until we migrate to something superior to layers anyway - no point making the change harder than it already is.
[14:50] <jtv> something I don't understand about your atexit handler: how does its default argument get handled?  How does it avoid dereferencing MemcachedLayer._memcached_process if that's already been torn down?
[14:50] <jtv> review meeting in 10...
[14:52] <stub> jtv: The default value for the pid argument is evaluated when the function is defined.
[14:52] <stub> (Not when the function is invoked)
[14:52] <jtv> stub: Ah.  Also, since the atexit handler is one of those things you won't want to test, can you share a bit more of the killing code between the two places where it's written?
[14:54] <stub> What would you share?
[14:54] <stub> I'd like the tearDown to raise exceptions when things screw up. The atexit is just a second chance of not leaving random processes running if things go wrong.
[14:56] <jtv> hmmm... yeah, not much to share
[14:57] <jtv> only "if pid is not None: os.kill(pid, signal.SIGKILL)"
[14:58] <jtv> It would make tearDown a bit nicer to read though, since you'd be rid of the line break in the "if" condition.
[14:59] <stub> I personally prefer that than the extra indirection
[15:00] <jtv> ok, no particularly strong feelings.
[15:01] <jtv> stub: oh, it's not in the pastebin but above Memcachedlayer.launch you had a double blank line.
[15:02] <jtv> Whereas one is missing above MemcacheClientTestCase
[15:03] <jtv> stub: are you in the reviewers meeting?
[15:03] <stub> Which file is that?
[15:03] <stub> nah
[15:03] <jtv> lib/lp/services/memcache/tests/test_memcache_client.py
[15:04] <stub> fixed
[15:05] <jtv> stub: ok, then r=me
[15:05] <stub> Ta. Now if I can work out how to get lp-dev-deps rebuilt I might one day be able to land it ;)
[15:07] <jtv> I _would_ say "let the Foundations people worry about that," but...
[15:11] <allenap> stub: In line 194 of http://paste.ubuntu.com/282095/ it should be is *not* None I think.
[15:23] <stub> allenap: yup. fixing.
[15:24] <allenap> stub: Cool. I commented on the bug too, just in case you'd gone, not because I like to harass you ;)
[15:26] <jtv> allenap: I've got a pretty urgent MP myself... shall I take it?  Or chuck it on the queue?  :-)
[15:26] <jtv> oh, EdwinGrubbs maybe?
[15:27] <allenap> jtv: I'm doing noodles' review now, but I can push yours on the stack.
[15:27] <EdwinGrubbs> jtv: which review is it?
[15:27] <jtv> allenap: stack?  Not queue?
[15:27] <jtv> EdwinGrubbs: redo-uploads
[15:27] <allenap> jtv: I'm a stack based machine.
[15:27] <jtv> uh-oh
[15:28] <allenap> jtv: Don't worry. I rarely overflow.
[15:28] <jtv> tmi dude, tmi
[15:29] <jtv> EdwinGrubbs: this one: https://code.edge.launchpad.net/~jtv/launchpad/redo-uploads/+merge/12659
[15:29] <EdwinGrubbs> jtv: ok, I'll do it.
[15:29] <jtv> EdwinGrubbs: thanks!
[15:31] <jtv> topic serialization failure
[15:33] <jtv> deryck: what if a bug summary is a full sentence?
[15:33] <jtv> deryck: I sometimes paste an entire error message into a bug search, for instance.
[15:35] <allenap> noodles775: In bug 436182, it says "there's a superfluous newline after libuno-cli-cppuhelper1.0-cil", but it's actually after the comma that follows libuno-cli-cppuhelper1.0-cil. Could that mean that it's really a leading newline in libuno-cli-ure1.0-cil?
[15:35] <mup> Bug #436182: Newlines in Sources.bz2 indices <oem-services> <soyuz-upload> <Soyuz:Triaged by michael.nelson> <https://launchpad.net/bugs/436182>
[15:35] <jtv> deryck: Is "ValueError: The date you gave was in a timezone that is not divisible by 12 minutes, which somehow matters to some hypohetical piece of code." one of these?
[15:36] <noodles775> allenap: that seems to be just the cause of the issue - what happens then is that we (soyuz) incorrectly parse it and add a newline to the end of the field (dsc_binary in this case), as demo'd in the test.
[15:38] <noodles775> allenap: cprov did a separate query showing that the relevant SourcePackageReleases have a '\n' appended to the end of the dsc_binaries field. We should add that to the bug.
[15:45] <deryck> jtv, I think that's ok.  That's why I used quotes.  It's hard to echo on the page nicely, and beuno did sign off on the layout, maybe he has ideas.
[15:47] <beuno> deryck, maybe "Is this the same as: $summary"
[15:47] <beuno> and no quotes?
[15:47] <deryck> beuno, but what is "this"?
[15:47] <allenap> noodles775: This change will affect every field in the index stanza. That sounds like a good bit of belt-and-braces engineering. Might even be worth .strip()ing, not just .rstrip()ing.
[15:47] <beuno> deryck, "Is this bug the same as: $summary?"
[15:48] <noodles775> allenap: I initially had it just on the dsc_binaries, but then chatted with cprov and we decided to apply it generally to all the fields.
[15:48] <deryck> beuno, but it would be more accurately, "Is one of these bugs the same as:  $summary"  which is long, I think.  but I'm not picky.
[15:48] <noodles775> allenap: we've only encountered the problem on dsc_binaries, but it's the same parsing function that parses all the fields.
[15:49] <deryck> beuno, your needed in our room at 4.
[15:49]  * deryck has to have coke before the next meeting, sorry
[15:49] <cprov> allenap, noodles775: and debian policy states it clearly ... http://www.debian.org/doc/debian-policy/ch-controlfields.html
[15:49] <noodles775> allenap: and it's important that it's only rstrip() (imo), as there can be other single line-breaks within the fields values, just not at the end.
[15:49] <cprov> Many fields' values may span several lines;''
[15:50] <beuno> deryck, I will be there in 5ish
[15:51] <jtv> deryck: you're good to go
[15:51] <allenap> cprov, noodles775: Cool, thanks. r=me
[15:53] <jtv> allenap, EdwinGrubbs: sneaking out
[15:53] <jtv> I'll still be here for a while, but not looking for new reviews to do.
[15:55] <noodles775> Thanks allenap !
[15:56] <deryck> jtv, thanks!  Sorry I couldn't be more attentive to review.
[15:57] <jtv> deryck: you're sprinting, no worries.  FWIW I did check that the text gets HTML-escaped, and it does.  Just in case.  :)
[15:57] <deryck> jtv, thanks! :)
[16:47] <EdwinGrubbs> jtv: I don't understand where I go to 'pick a source package in "main" for some Ubuntu release'.
[16:47] <jtv> EdwinGrubbs: https://translations.launchpad.dev/ubuntu/hoary/+source/evolution should do it
[16:48] <jtv> for a dev system
[16:58] <EdwinGrubbs> jtv: When I run reupload-translations.py -s hoary -p evolution
[16:58] <EdwinGrubbs> jtv: I get this: WARNING Found no translations upload for evolution in Ubuntu Hoary.
[16:58] <jtv> EdwinGrubbs: that's normal
[16:59] <jtv> it seems none of these packages have translations uploads in the sample data.  :/
[17:11] <allenap> leonardr: Is this proposal - https://code.edge.launchpad.net/~leonardr/launchpadlib/uses-restfulclient/+merge/5348 - still in need of review?
[17:12] <leonardr> allenap, no, it's long merged
[17:12] <allenap> leonardr: Okay, I'll change the status. Thanks.
[17:13] <EdwinGrubbs> jtv: what does this mean in TestReuploadScript? "INFO\s*Processing [^\s]+ in .*\n"
[17:13] <allenap> gmb: You want someone to review ajaxify-branch-linking?
[17:13] <jtv> EdwinGrubbs: a log message that looks like INFO    Processing <something>
[17:14] <jtv> EdwinGrubbs: the package names are arbitrary thanks to the factory, and I don't want to rely on the ordering even if they weren't.
[17:16] <gmb> allenap: No, Tom's already reviewed that; waiting for a child branch to be ready for reviewing, but I've been sidetracked again.
[17:16] <gmb> this is going to be one of those I-only-land-one-branch weeks, I think.
[17:17] <allenap> gmb: Okay, cool.
[17:17] <gmb> allenap: Thanks for reviewing that trac-launchpad-migrator branch. I'd forgotten it even existed.
[17:17] <allenap> intellectronica: Could you mark https://code.edge.launchpad.net/~gmb/launchpad/ajaxify-branch-linking/+merge/12514 as reviewed by you, so it disappears off the "Requested reviews I can do" bit on +activereviews please? :)
[17:17] <gmb> allenap: We need an nag email for merge proposals, I think...
[17:17] <intellectronica> allenap: sure thing
[17:18] <allenap> gmb: Yeah, I noticed it when I started using launchpad-project/+activereviews. Got a bit of a shock!
[17:18] <allenap> gmb: Are you getting sidetracked by checkwatches?
[17:18] <intellectronica> maaan, the edit button still evades me whenever i go to this page :)
[17:18] <gmb> intellectronica: You're not the only one.
[17:18] <gmb> I think it should still be next to the status myself, but maybe that should only happen when status editing is ajaxified.
[17:19] <allenap> intellectronica: Thanks!
[17:19] <adeuring> allenap: EdwinGrubbs: could one of you please review this MP: https://code.edge.launchpad.net/~adeuring/launchpad/hwdb-refactor-haldevice/+merge/12669 ?
[17:21] <allenap> adeuring: I don't think I'll have time today.
[17:21] <adeuring> allenap: np
[17:22] <allenap> sinzui: Are you able to land https://code.edge.launchpad.net/~sinzui/launchpad/sprint-is-physical/+merge/12026 now?
[17:22] <allenap> sinzui: I'm just doing some late late spring cleaning in +activereviews.
[17:25] <allenap> EdwinGrubbs: Are you reviewing https://code.edge.launchpad.net/~jtv/launchpad/bug-436426-2/+merge/12610?
[17:27] <EdwinGrubbs> jtv: Why are only uploads in the ROSETTA_TRANSLATIONS format re-uploaded? What other formats are there?
[17:28] <jtv> allenap: he's doing my other one
[17:28] <EdwinGrubbs> allenap: no, I'm reviewing the redo-uploads branch
[17:28] <jtv> EdwinGrubbs: the other formats are Soyuz stuff unrelated to Translations.  "Format" looks to be a bit of a misnomer IMHO
[17:29] <EdwinGrubbs> jtv: It also seems that there is no test which exercises the for-loop which calls addOrUpdateEntriesFromTarball().
[17:29] <jtv> EdwinGrubbs: it has to do with the way a single source upload spawns various work items making their own respective ways through the Soyuz work queue.
[17:29] <allenap> EdwinGrubbs, jtv: Okay, thanks. I don't actually have time to review it so I'm not sure why I was asking now!
[17:30] <jtv> EdwinGrubbs: you mean, before I exercised it in this branch?
[17:30] <jtv> allenap: that'll teach you  :-P
[17:30] <jtv> EdwinGrubbs: nm, I misread
[17:31] <jtv> EdwinGrubbs: you're talking about _processPackage, right?  That's called from main(), and is exercised in test_processPackage
[17:31] <sinzui> allenap: The branch bounced many times. mthhadon fixed db-devel a few hours ago. (It was stuck in release-critical)
[17:32] <allenap> sinzui: Okay. I'll mark it as approved then so it drops out of the reviews list, if that's okay.
[17:33] <sinzui> oh. thanks
[17:34] <EdwinGrubbs> jtv: ok, so that test would not have output like "WARNING\s*Found no translations upload for" if you were testing the output?
[17:34] <EdwinGrubbs> jtv: so, is this script just going to be run once manually for karmic and probably never run again unless there is another bug?
[17:36] <jtv> EdwinGrubbs: right on both counts
[17:36] <jtv> want me to inject a mock logger and test the output?
[17:37] <jtv> (actually there's easier ways to check: uploadless_packages)
[17:38] <jtv> EdwinGrubbs: oh, I already check that uploadless_packages is empty there.
[17:38] <jtv> Packages are appended to that in tandem with producing that log message.
[17:38] <jtv> But the test needs a comment!
[17:41] <jtv> Done.
[17:42] <EdwinGrubbs> jtv: and I assume that summarize_translations_queue() ensures that the main() actually processed something, so an empty uploadless_packages couldn't be because nothing was processed?
[17:45] <EdwinGrubbs> jtv: merge-conditional
[17:46] <jtv> EdwinGrubbs: it summarizes what's on the translations queue for that package.  Since the package was just created, it was previously empty.
[17:46] <jtv> The test verifies that _processPackages did upload files to the queue.
[17:46] <jtv> So a pretty thorough test; not just the script's own opinion.
[17:47] <jtv> EdwinGrubbs: thanks!
[17:50] <EdwinGrubbs> jtv: did you want me to review your other branch when I get back from lunch? bug-436426-2?
[17:50] <jtv> EdwinGrubbs: if you have time, yes please; but not as urgent.
[21:53] <barry> EdwinGrubbs: ping


[00:05] <stochastix> f i do,  snap find ,  is that supposed to list all of the snap available?  If I run snap find tele, I get telegram, but otherwise it is not in the long list?
[00:05] <stochastix> I am trying to just get an exhaustive list of the snaps available to look at them.
[01:06] <tsimonq2> elopio: do you use zsh? how did that idea get formed?
[01:06] <elopio> tsimonq2: I met somebody who uses zsh.
[01:06] <elopio> I have a lot of new friends today ^_^
[01:19] <tsimonq2> elopio: :D
[01:19] <tsimonq2> elopio: are you at a sprint or something? :P
[04:06] <slangasek> ogra_: https://github.com/CanonicalLtd/ubuntu-image/pull/63 landed
[04:06] <mup> PR CanonicalLtd/ubuntu-image#63: Don't build 4GB images, build images as big as the required contents <Created by vorlonofportland> <Merged by vorlonofportland> <https://github.com/CanonicalLtd/ubuntu-image/pull/63>
[05:31] <sparkin> hello my fellow crafters!!!!!!!
[05:34] <sparkin> crickets...
[06:55] <mvo> ogra_: was just thinking about the recent change to ubuntu image to make the disk only as small as needed. this does mean that if you run it directly in kvm/qemu the first snap you download causes a disk-full error?
[06:55] <dholbach> hey hey
[06:57] <mup> Bug #1623802 opened: snapd does not properly detect service/mount unit status <Snappy:New> <https://launchpad.net/bugs/1623802>
[06:59] <mvo> pitti: I'm curious why the autopkgtest test runs take so long after an upload, is it because the machines that do the testing are so busy? or is there another reason?
[06:59] <mvo> pitti: (background is my snapd upload from 12h ago that did not yet get run inside adt)
[07:03] <pitti> mvo: yeah, sorry -- look at http://autopkgtest.ubuntu.com/running
[07:03] <pitti> mvo: queues got double-Qt'ed yesterday, and the backlog lasted until this morning; s390x and armhf are still catching up
[07:05] <mvo> pitti: it says queue length is "-" for yakkety/amd64, does that mean the queue is empty?
[07:05]  * pitti orders another Binford 6100 cloud  -- we need MORE POWER
[07:05] <pitti> mvo: yes (some amd64 tests are stilll running, though
[07:06] <mvo> pitti: hm, I don't see snapd on the page but there is a new version https://launchpad.net/ubuntu/+source/snapd/2.14.2+git.1.afda4fc-0ubuntu2
[07:06] <mvo> pitti: what am I missing :) ?
[07:06] <pitti> mvo: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd ?
[07:06] <pitti> mvo: you are missing the FTBFS on arm64
[07:06] <mvo> pitti: oh, meh, ok. this got fixed this morning, but I guess that is too late
[07:07] <mvo> pitti: ok, thank you!
[07:07] <mvo> pitti: so that means it will be considered soon :) ?
[07:10] <pitti> mvo: as soon as it builds, yes
[07:23] <mvo> pitti: cool, thanks. it has build ~1h ago, but I guess it takes a bit until the script catches up (or does it need to get published first?)
[07:25] <pitti> mvo: yes, britney only sees published packages
[07:25]  * mvo nods
[07:30] <zyga> quick noob question, how do I build our kernel in a way that lets me incrementally build / reinstall / reboot while tweaking some things?
[07:31] <zyga> (where what I care about is identical config and initial source as packaged kernel and incremental build after any change)
[07:46] <mup> PR snapd#1916 opened: backends: first bits of kernel-module security backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/1916>
[08:00] <ogra_> mvo, yeah, we need a --size option
[08:00] <ogra_> so you can define a minimal size
[08:01] <ogra_> or allow to pre-create a target img (though thats more ugly)
[08:03] <mvo> ogra_: indeed
[08:07] <ogra_> mvo, i see steve added an image_size variable to builder.py, i guess we just need the option at the top level and hand the value over
[08:09] <mvo> ogra_: yeah, I was thinking it would be pretty easy to add
[08:10] <ogra_> as a quick hack: os.environ.get('IMAGESIZE') ... ;)
[08:10] <ogra_> wouldnt even need an option
[08:19] <ogra_> http://paste.ubuntu.com/23181304/
[08:21] <ogra_> hrm
[08:22] <ogra_> i get "Failed to mount /boot/grub." ... even with the beta channel
[08:22] <ogra_> oh
[08:23] <ogra_> FAT-fs (sda2): error, fat_get_cluster: invalid cluster chain ...
[08:25] <ogra_> hmm, weird, steve didnt touch anything in the vfat creation
[08:27] <bull> hello guys my app which is written in qt have a functionality like- when user click on open file with editor , it open the loaded file with system editor ex gedit , kwrite or whatever user having as per their configuration . after packaging my app with snap the functionality is broken, are you guys working in it ???
[08:29] <bull> am sure there is nothing wrong with my code as you can see this feature in hundreds of other applications out there. snap need to fix this :D
[08:29] <pitti> mvo: snapd tests are queued now
[08:30] <ogra_> aha ... using mtools from proposed helps :)
[08:30]  * ogra_ has a working 500MB kvm image
[08:30] <pitti> mvo: oh, so it wasn't FTBFS, just finished building around that time
[08:30] <ogra_> ogra@localhost:~$ df -h /writable
[08:30] <ogra_> Filesystem      Size  Used Avail Use% Mounted on
[08:30] <ogra_> /dev/sda3       542M  190M  313M  38% /writable
[08:31] <ogra_> bull, for now you need to ship the editor you want and tell your app to use this one ... long term i think zyga works on a sensible-editor interface or some such
[08:32] <bull> ogra_,  you mean gedit or kwrite inside snap as stage package ??
[08:32] <bull> this will fill snap with almost all kde and gnome dependencies am sure :D
[08:32] <ogra_> (i know he does something like this for browsers already, editors should just be a variant of that)
[08:32] <bull> oh
[08:33] <ogra_> bull, yes, i mean that ... just pich one with less deps then
[08:33] <ogra_> *pick
[08:33] <bull> ogra_, my app cant open url in external web browser
[08:33] <ogra_> yes, same thing
[08:34] <bull> ogra_, i have to add sensible- browser in snapcraft yaml ?
[08:34] <mvo> pitti: neat, its running
[08:34] <mvo> pitti: can't wait, I had it down to 1 test failure due to no (non-proxy) network
[08:34] <ogra_> no, you would have to add the browser you want ... there is also work on making xdg-open work if your snap runs on a classic system ... not sure where that stands
[08:35] <mvo> pitti: and in qemu its all working perfectly, so fingers crossed
[08:35] <bull> ogra_,  you mean i have to add a browser inside my snap ??
[08:35] <bull> damn
[08:35] <bull> :D
[08:35] <bull> like chrome or firefox ?
[08:35] <ogra_> hypothetically ...
[08:35] <ogra_> i'd just wait til the right interfaces are there for that one :)
[08:36] <bull> thats really funny :P
[08:36] <bull> and if my app wana talk with snapd installed on user's system ??
[08:36] <bull> is there snapd interface coming ?
[08:36] <ogra_> you can surely find a lightweight editor and seed that into your derfault config .... i wouldnt expect that for a browser
[08:36] <bull> for that too  :/
[08:37] <bull> come-on i don't want change the main aim of my feature
[08:37] <ogra_> ogra@anubis:~/datengrab/images/snappy$ snap interfaces|grep snapd
[08:37] <ogra_> :snapd-control           -
[08:37] <ogra_> that is already there
[08:38] <bull> aim of feature is to make user comfort by providing him an option to edit  file in his favorite editor not with editor of my choce
[08:38] <bull> choice
[08:38] <bull> :P
[08:38] <ogra_> yes, that was clear f4rom your first question
[08:38] <bull> okay
[08:39] <ogra_> isnt there yet ... but there are workarounds i pointed out til this landed
[08:40] <bull> ogra_,  if i will add snapd-control in my snapcraft's plugs will it make it work ?
[08:40] <ogra_> mvo, so http://paste.ubuntu.com/23181304/ seems to work fine as a quick hack, unless you want to invest time into adding an actual option
[08:41] <ogra_> bull, it allows your snap to talk to the REST api of snapd ... so if you implement the right protocol i imagine it will work ...
[08:41]  * ogra_ has no first hand experience with that API
[08:41] <bull> my app uses qprocess to call snap ,
[08:41] <liuxg> ogra_,  I have changed my network setting in my p3 to http://paste.ubuntu.com/23181339/, however, after I disconnect my cable, my wifi on the pi3 still cannot get an IP. what could be the problem for it?
[08:42] <ogra_> liuxg, sit0 isnt your wlan device :)
[08:42] <ogra_> i think it just comes up as wlan0 on the pi
[08:43] <liuxg> ogra_, what should be the wlan device? I could not find any other device there
[08:43] <ogra_> cat /proc/net/dev ?
[08:43] <liuxg> ogra_, yeah, you could be right. thanks. I will check it
[08:50] <bull> snap looking for a web browser to open a folder what ??? QGenericUnixServices::openUrl(const QUrl&): Unable to detect a web browser to launch '/home/bull/github/'
[08:54] <mup> PR snapd#1787 closed: overlord/snapstate, daemon, cmd/snap: more explicit revision support <Blocked> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1787>
[08:54] <mup> PR snapd#1834 closed: many: mostly work to support ABA upgrades <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1834>
[08:54] <pbek> I have a problem with updating my snap in the snapstore. `snap find qownnotes` and https://uappexplorer.com/app/qownnotes.pbek tells me the latest version is 16.09.3, but my package in my https://myapps.developer.ubuntu.com account is at 16.09.7 and all releases are published in the channel `stable` as they should be.
[08:55] <pbek> All releases were published automatically by Launchpad.
[08:55] <ogra_> pbek, there is an issue with the store ... go to the last releaseed snap in the UI, click unpublish and then click publish again
[08:55] <bull> pbek,  which package you trying ?
[08:55] <ogra_> that will make it show up
[08:55] <ogra_> the fix for this should land today or tomorrow
[08:56] <pbek> ogra_: I get a `504 Gateway Time-out` when I try that :)
[08:56] <pbek> bull: qownnotes
[08:56] <ogra_> uh
[08:57] <pbek> ogra_: but it was unpublished
[08:57] <bull> pbek, does it work out-of-box as a snap ?
[08:58] <pbek> bull: what do you mean by that?
[08:58] <bull> i will check that myself by installing it
[08:59] <bull> ty
[08:59] <pbek> ogra_: thank you, 16.09.7 is now visible
[08:59] <ogra_> :)
[08:59]  * ogra_ has to do the same every morning for all ubuntu-core snaps :)
[08:59] <bull> pbek,  like most of apps dont seem to work fine with after packed in snap :D
[09:00]  * ogra_ found that most apps do work fine ...
[09:00] <liuxg> ogra_, if I have this error "error: cannot install snap file: snap "piglow-app" has changes in progress". how can I correct this situation?
[09:00] <ogra_> really depends how complex that app is :)
[09:00] <pbek> ogra_: that explains why noone updated QOwnNotes for some time :)
[09:00] <liuxg> ogra_, I have seen this kind of errors a number of times. but sometimes it disappears.
[09:00] <ogra_> liuxg, snap changes ... find the change in progress ... snap abort $change_number
[09:01] <pbek> bull: oh, I had to do quite some work to make it happen... and there are still some issues
[09:01] <bull> ogra_,  a package management system should not worry about how developer made their app :D\
[09:02] <ogra_> every package management system does that
[09:02] <bull> they worry about what functionality developer providing ??
[09:03] <bull> i think no
[09:03] <mvo> pitti: interessting failure of adt on armhf - there is no sshd config there, is armhf driven via something else than ssh in adt?
[09:03] <ogra_> they have to make integration work
[09:03] <liuxg> ogra_, how to find the change number in the system?
[09:03] <bull> they need to install packaged stuffs to place :D
[09:03] <bull> nothing more then this
[09:03] <ogra_> liuxg, ?
[09:03] <pitti> mvo: yes, armhf and s390x run in lxc; we don't have these arches in scalingstack
[09:03] <ogra_> liuxg, does snap changes not show it ?
[09:03] <bull> snap is different case a sure :D
[09:04] <ogra_> bull, how many deb or rpm packages have you built from scratch ?
[09:04] <pitti> + sed -i s/\(PermitRootLogin\|PasswordAuthentication\)\>.*/\1 yes/ /etc/ssh/sshd_config
[09:04] <pitti> o_O
[09:04] <liuxg> ogra_, yeah, I cannot find anything about it. it seems that it is broken http://paste.ubuntu.com/23181393/
[09:04] <ogra_> liuxg, thats snap list
[09:04] <bull> ogra_, i made more then 20 debs
[09:04] <bull> from scratch
[09:04] <liuxg> ogra_, yeah, that is the list. I try to remove it, it refuses to do that.
[09:05] <bull> and they all were in ubuntu software center
[09:05] <ogra_> bull, from scratch ? into the official archive, matching all integration requirements to make then safely work ?
[09:05] <mvo> pitti: ta
[09:05] <ogra_> *them
[09:05] <bull> not in official archives
[09:05] <pbek> bull: just making debs for QOwnNotes drove me nuts :)
[09:05] <ogra_> i.e. following the debian packaging policy ...
[09:05] <liuxg> ogra_, is there anyway to find the changes, and cancel it?
[09:05] <pitti> mvo: the tests want to ssh to localhost via password? 3v1l :)
[09:05] <popey> With the git source-type, is it possible to pull a specific commit? I can use source-tag, and source-branch... but how do I get a commit?
[09:05] <popey> (in snapcraft)
[09:05] <bull> ogra_,  apps in store don't follow debian policies?
[09:06] <ogra_> liuxg, again ... snap changes ... find the change in progress ... snap abort $change_number
[09:06] <liuxg> ogra_, ok. thanks
[09:06] <ogra_> bull, they get a security check ... thats all i think
[09:07] <bull> ogra_,  snap abort change-id for a install process wont abort process until snap download the full package that is a bug
[09:07] <ogra_> thiough support for this was dropped lng ago since the review was way to time consuming
[09:07] <bull> hmm
[09:08] <bull> ogra_,  snap abort change-id for a install process wont abort process until snap download the full package that is a bug !! plz check it
[09:09] <popey> bull: we know, we know about the bug
[09:09] <ogra_> yes, you complained about this for several days, several times a day ...
[09:09] <ogra_> hard to not notice :P
[09:09] <bull> several times a day ??
[09:09] <bull> lol
[09:09] <bull> i was just reminding :P liuxg
[09:10] <bull> popey, yeah we tested it :P
[09:10] <liuxg> bull, yeah, it takes 3 mins to remove a snap.
[09:11] <bull> liuxg, not about removing snap man , it was about to kill a install process . snap wont kill install process untill it download the whole package
[09:11]  * ogra_ sighs and goes for brakfast
[09:11] <liuxg> liuxg, I am still waiting for the completion of the command. I am sideload a snap. it is not downloading.
[09:12] <bull> liuxg,  use snapcraft-gui
[09:12] <bull> it has package manager to manage snaps
[09:13] <liuxg> bull, snapgraft-gui is a desktop app, right? is it in the store already?
[09:13] <bull> no
[09:13] <bull> it is here https://github.com/snapcraft-gui/snapcraft-gui
[09:13] <bull> repo coming soon
[09:13] <bull> i developed it :P
[09:14] <bull> with all convenience for snap user in mind
[09:14] <bull> you can write recipes and make snaps , with clicks
[09:14] <liuxg> bull, thanks for letting me know. I will try it later on.
[09:15] <bull> okay
[09:16] <bull> ii was having lp ppa but tsimonq2  said he will make new one with better sourcebuild features so we deleted old one
[09:19] <ogra_> liuxg, so what does "snap changes" show you
[09:19] <ogra_> (gimme a pastebin)
[09:25] <bull> QSqlError("", "Driver not loaded", "Driver not loaded")
[09:25] <bull> QSqlQuery::prepare: database not open
[09:27] <bull> ogra_, can we have access to partitions  of hard disk ?? i cant see any such things in the file dialog
[09:28] <ogra_> there is the home interface
[09:28] <bull> home interface show partitions too ?
[09:28] <ogra_> no, only files in home
[09:28] <ogra_> there is no way to get such sensible info yet
[09:29] <ogra_> like partitions ...
[09:29] <bull> wow
[09:29] <bull> thats why i cant load music from mymusic partition using vlc
[09:30] <ogra_> bind mount it under your home somewhere ... i.e. into ~/Music
[09:31] <bull> ogra_,  how :(
[09:31] <ogra_> by bind mounting ?
[09:31] <bull> yea
[09:32] <bull> ogra_,  we have to do it manually before using vlc ?
[09:32] <ogra_> fi you put your music into exotic places you have to make it available in a common place first, yes
[09:33] <bull> :D
[09:33] <ogra_> i have no probs with vlc here
[09:33] <bull> exotic places :P ?
[09:34] <ogra_> (and i think 90% of users wont)
[09:34] <bull> you put music in home /music ?
[09:34] <ogra_> yes
[09:34] <bull> cool
[09:34] <bull> some people do use partitions and external hd
[09:35] <ogra_> good for them
[09:35] <mup> PR snapd#1917 opened: tests: ensure openssh-server is installed in autopkgtest <Created by mvo5> <https://github.com/snapcore/snapd/pull/1917>
[09:35] <bull> not good for them if they dont know how to load music in vlc
[09:35] <bull> people will ditch whole ubuntu for vlc :D
[09:36] <bull> if it will not fixed and snap will be default format :D
[09:36]  * ogra_ goes away for a few hourst ... i really cant take it anymore
[09:36] <bull> *some people
[09:37] <bull> ogra_, LOL
[09:37] <ogra_> not funny, really
[09:37] <bull> yeah i have seen cases
[09:38] <ogra_> if you have something constructive to tell me, fine ... if you find a bug, please file it ... but dont rave about it for hours
[09:44] <bull> hi
[09:44] <bull> tsimonq2, hi
[09:46] <bull> with button icons is it looking sexy > https://raw.githubusercontent.com/snapcraft-gui/snapcraft-gui/master/screenshots/sc1.png
[09:56] <mup> PR snapd#1918 opened: spread.yaml, tests: add adhoc-ubuntu-core spread backend <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1918>
[10:16] <abeato> sergiusens, any idea why I can get this message when creating a snap? : "Copying needed target link from the system /dev/null"
[10:16] <abeato> sergiusens, it created a prime/dev/null file
[10:16] <abeato> which provoked some issues until I noticed
[10:18] <ogra_> mvo, http://paste.ubuntu.com/23181669/ works (not actually more beautiful but i get an extra 500MB when i set WIGGLEROOM=500)
[10:34] <mup> PR snapd#1919 opened: tests: make ubuntu-core tests more robust <Created by mvo5> <https://github.com/snapcore/snapd/pull/1919>
[10:34] <mvo> ogra_: ok
[10:35] <ogra_> mvo, oh, and ouch ... we build the core snap against proposed ...
[10:35] <ogra_> mvo, but -proposed isnt in the sources.list ...
[10:35] <ogra_> i currently can not install vim in classic due to that
[10:35] <ogra_> (in the classic shell i mean)
[10:36] <ogra_> mvo, should i stop using proposed during imagge build or should we add proposed to sources.list ?
[10:39] <mvo> ogra_: I think stop using proposed is best
[10:39] <ogra_> ok
[10:39] <mvo> ogra_: we can also sed it out in classic.create
[10:39] <mvo> (for now)
[10:39] <ogra_> lets see if that builds :)
[10:39] <mvo> but I think !-proposed is best
[10:39]  * ogra_ drops it and does a test build
[10:48] <mvo> pitti: hm, snapd (latest version)vanished from the running page for amd64 but it did not appear on the results page yet. is there a (cron) delay or something?
[10:51] <pitti> mvo: wow, watching it like a hawk, aren't you :) -- there's ~ 5 minutes cron delay indeed
[10:51] <pitti> mvo: still running on http://autopkgtest.ubuntu.com/running#pkg-snapd though on some arches
[10:52] <pitti> mvo: could also be testbed failure, I'll check the logs in a minute
[10:52] <mup> PR snapd#1920 opened: --lazy is only available with -l in trusty <Created by vosst> <https://github.com/snapcore/snapd/pull/1920>
[10:57] <morphis__> pitti: can we configure netplan to generate wifi settings files via NetworkManager and ethernet ones via networkd depending on some flag we put somewhere?
[10:57] <pitti> morphis__: that is the default mode indeed
[10:57] <morphis__> oh really?
[10:57] <pitti> morphis__: oh wait, actually not any more, default is networkd
[10:57] <morphis__> can we change that somehow?
[10:57] <pitti> morphis__: it used to be NM for wifi until I taught it to do wifi via networkd+wpasupplicant
[10:58] <pitti> morphis__: anyway, you can select the backed for every individual definition, yes
[10:58] <pitti> renderer: NetworkManager|networkd, see the manpage
[10:58] <morphis__> pitti: and how can we change that on Ubuntu Core, not sure what configures this globally
[10:58] <morphis__> or would that be a thing console-conf has to know about?
[10:58] <ogra_> but please dont make NM a hard requirement
[10:58] <pitti> you can specify the renderer globally, by device type, or by individual definition
[10:59] <pitti> and you can put it into a separate yaml snippet
[10:59] <ogra_> if it isnt installed on an image it netpplan needs to fall back to using wpa-supplicant
[10:59] <pitti> it normally detects the availability
[10:59] <ogra_> ok
[10:59] <morphis__> ogra_: no :-)
[10:59] <ogra_> :P
[10:59] <pitti> but if you say "use NM" and NM is not installed, those definitions wil just fail
[10:59] <morphis__> pitti: I see
[10:59] <ogra_> right ...
[11:00] <morphis__> pitti: where do I specify the renderer globally?
[11:00] <pitti> morphis__: at the global yaml level, right under the top-level "network:" (again, see manpage)
[11:01] <ogra_> pitti, btw, my network setup on the pi3 now goes really mad ... i'm not yet sure if thats netplan or console-conf that is at fault ... console-conf offers me both interfaces (wired and wireless) but i always end up with only wired usable
[11:02] <ogra_> it works just fine on the dragonboard where i only have a wlan interface ... but having both makes something go mad
[11:02] <morphis__> pitti: thanks
[11:03] <mwhudson> ogra_: there is https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1623756 in this area
[11:03] <mup> Bug #1623756: console-conf generates invalid config when wifi is not configured <subiquity (Ubuntu):In Progress> <https://launchpad.net/bugs/1623756>
[11:03] <ogra_> mwhudson, oh, thanks !
[11:03] <ogra_> yeah, i wanted to file that one but collect some more data ... just got distracted from it
[11:04] <mwhudson> just sent a PR with a presumed fix, really need to get the repo made public now...
[11:04] <ogra_> mwhudson, though mine is slightly different ... i actually configure it with ssid and it even obtains an IP
[11:04] <mwhudson> ogra_: ah ok
[11:05] <ogra_> it still tries to use wired though ... evven if i say "dont configure"
[11:05]  * ogra_ will collect more data first ... perhaps it is the same cause, who knows
[11:05] <mwhudson> ah hm
[11:05] <mwhudson> yeah, that's certainly possible
[11:06] <mwhudson> although if the wired interface is up, you remove it from the config entirely and run netplan apply, i don't know if the interface would be taken down
[11:06] <mwhudson> pitti: would know
[11:07] <ogra_> well, if there is no cable, it should not be tried at all
[11:07] <pitti> no, apply doesn't currently down interfaces which are up
[11:07] <mwhudson> oh
[11:07] <ogra_> not sure if netplan takes mii state into account here
[11:07] <pitti> seemed too dangerous to me
[11:07] <pitti> if we want/need that, bug report please
[11:08] <pitti> ogra_: you mean up, but no link beat?
[11:08] <mwhudson> ogra_: how can you tell that it's being tried? sorry it's late here and i'm probably being dense
[11:08] <pitti> I guess we can safely twiddle those too
[11:09] <pitti> "netplan --debug apply" might be useful
[11:09] <bull> Snapcraft GUI version 2.0 released with everything working :P download .deb here https://github.com/snapcraft-gui/snapcraft-gui/releases/tag/2.0
[11:09] <ogra_> pitti, i mean when i boot i get offered to configure eth0 in console-conf even if there is no cable plugged in ... it shouldnt offer that i think
[11:09] <pitti> hmm
[11:09] <pitti> ogra_: there are routers with broken link beat
[11:09] <pitti> or wifi devices have no link until you connect to an AP
[11:10] <ogra_> hmm, yeah
[11:10] <pitti> so I'm not sure if that's so obvious
[11:10] <pitti> it coudl certainly tell you that
[11:10] <pitti> en1 (disconnected)
[11:10] <ogra_> yeah, i guess something like that in the UI would already help
[11:10] <mup> PR snapd#1921 opened: Replace systemd-run with on-the-fly generation of units <Created by vosst> <https://github.com/snapcore/snapd/pull/1921>
[11:15] <mwhudson> ogra_: sounds good, bug pls
[11:16] <ogra_> yay ...
[11:16]  * ogra_ can install vim again
[11:20] <mup> Bug #1623897 opened: console-conf should show if wired interfaces are connected <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1623897>
[11:20] <ogra_> mwhudson, ^^
[11:24] <mwhudson> ogra_: thanks
[11:24]  * mwhudson zzz
[11:25] <ogra_> sleep well
[11:25] <mup> PR snapd#1922 opened: Use apt in accordance with functionality available on trusty <Created by vosst> <https://github.com/snapcore/snapd/pull/1922>
[11:33] <liuxg> is snapweb currently working already?
[11:36] <mup> PR snapd#1923 opened: Replace realpath with readlink -f for trusty support <Created by vosst> <https://github.com/snapcore/snapd/pull/1923>
[11:47] <bull> liuxg, checkout https://github.com/snapcraft-gui/snapcraft-gui/releases/tag/2.0
[11:48] <liuxg> bull, it looks very nice. I will promote it in my place to the community :)
[11:48] <bull> ty
[11:49] <bull> liuxg, please create issue if you want any changes , and finds any bug
[11:49] <liuxg> bull sure, I will do that. it is actually my strong point :)
[11:50] <liuxg> bull, in fact, I had thought of doing this some time ago :) it is really a nice work.
[11:50] <bull> thanks :) i hope you have found the project page already
[11:50] <bull> hmm
[12:03] <mup> PR snapd#1917 closed: tests: ensure openssh-server is installed in autopkgtest <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1917>
[12:03] <mup> PR snapd#1919 closed: tests: make ubuntu-core tests more robust <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1919>
[12:04] <mup> PR snapd#1915 closed: tests: add http_proxy to /etc/environment in the autopkgtest environment <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1915>
[12:04] <mup> PR snapd#1916 closed: backends: first bits of kernel-module security backend <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1916>
[12:08] <mup> PR snapd#1924 opened: tests: disable prepare-image-grub test in autopkgtest <Created by mvo5> <https://github.com/snapcore/snapd/pull/1924>
[12:10] <mvo> mwhudson: do you happen to know what is the deal with govendor(ing) and gccgo? it seems to be not supported in 16.04 or am I just using it wrong?
[12:11] <liuxg> may I know how to stop auto-update in the background? previously I could use config to disable it.
[12:11] <pitti> mvo: you have a few i386 and amd64 logs now
[12:12] <mvo> mwhudson: aha, I see you commented already, thank you!
[12:13] <mvo> pitti: ha! close
[12:13] <mvo> pitti: still one failure
[12:13] <mup> PR snapd#1925 opened: Adjust regex to account for changes in stat output <Created by vosst> <https://github.com/snapcore/snapd/pull/1925>
[12:14] <mup> PR snapcraft#803 closed: Do not run the bootstrap directory as a script (autotools plugin) <Created by evandandrea> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/803>
[12:14] <mup> PR snapd#1924 closed: tests: disable prepare-image-grub test in autopkgtest <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1924>
[12:15] <mvo> pitti: hm, i386 is strange it says ppa:snappy-dev/image can not be added (it does not exist). this worked on the amd64 run
[12:16] <sergiusens> abeato oh, neat! ldd for one of your elf files has that.
[12:16] <sergiusens> abeato care to fgure out which one?
[12:16] <abeato> sergiusens, lol
[12:16] <mup> PR snapd#1926 opened: tests: add https_proxy into environment as well <Created by mvo5> <https://github.com/snapcore/snapd/pull/1926>
[12:17] <abeato> sergiusens, yes, let me look. Interestingly that happens only when building for ARM, but not for x86
[12:18] <sergiusens> abeato if you can, find the offending lib and give me the ldd output for it
[12:18] <abeato> ack
[12:18] <abeato> sergiusens, anohter question: what does
[12:18] <abeato> Issues while validating snapcraft.yaml: The '0' property does not match the required schema: ['usr/bin/Xorg'] is not of type 'string'
[12:18] <abeato> mean?
[12:19] <pitti> mvo: hm, that add-apt-repo call works in a i386 chroot
[12:23] <sergiusens> abeato it means, remove the brackets :-)
[12:23] <sergiusens> abeato is this `organize`?
[12:24] <abeato> sergiusens, no brackets
[12:26] <abeato> sergiusens, kind of, it works now after removing this line: "# organize: ??
[12:26] <abeato> "# organize: ??"
[12:26] <abeato> which I added to remind me to investigate something
[12:27] <mup> PR snapd#1927 opened: Account for different PWD handling on trusty <Created by vosst> <https://github.com/snapcore/snapd/pull/1927>
[12:28] <sergiusens> abeato let me get you an example
[12:28] <abeato> sergiusens, a parsing error??
[12:28] <sergiusens> abeato https://github.com/snapcore/snapcraft/blob/master/demos/mosquitto/snapcraft.yaml#L28
[12:29] <sergiusens> abeato you are not matching the schema;; we use jsonschema that by default gives us those horrible errors and no easy way to compose our own
[12:29] <abeato> sergiusens, hmm... but why does it complain for a line that is a comment?
[12:32] <sergiusens> abeato oh, I see; give me the full yaml
[12:33] <sergiusens> abeato the lines are off by one btw
[12:40] <bull> sergiusens, can https://github.com/snapcraft-gui/snapcraft-gui/ be part of snapcraft source-code ?? please read this issue here https://github.com/snapcraft-gui/snapcraft-gui/issues/4
[12:41] <abeato> sergiusens, off by one? some whitespace issue?
[12:56] <abeato> sergiusens, I have found no references to something that migth pull /dev/null in the binaries... what kind of thing do you expect me to see?
[13:19] <abeato> sergiusens, and why can this happen:
[13:19] <abeato> Failed to clean step 'prime': Missing necessary state. This won't work until a complete clean has occurred.
[13:19] <abeato> ??
[13:20] <liuxg> ogra_, does Pi3 has a built-in bluetooth in it? thanks. I just try to make use of it, however, I cannot find it.
[13:26] <liuxg> morphis__,  is bluetooth currently supported on pi3?
[13:28] <ogra_> liuxg, pi3 has builtin BT ... but i dont know if we have all firmware and drivers yet
[13:29] <ogra_> theoretically it should be the wlan firmware since i think it is the same device
[13:29] <ogra_> practically i dont know though
[13:29] <liuxg> ogra_, ok. thanks for your reply. I basically duplicate the same step as 410c, but it does not work. I have tried to use bluetoothctrl, but it seems that it is not working.
[13:29] <bull> my bt dont work on ubuntu 16.04 :(  it was working on 14.04
[13:30] <ogra_> liuxg, i'm not really sure if the kernel has all bits and pieces yet for the pi3 img
[13:30] <liuxg> ogra_, yes, I see the wlan there http://paste.ubuntu.com/23182127/
[13:30] <ogra_> yeah, that definiteely works
[13:31] <liuxg> ogra_, currently, the bluetooth works on 410c board.
[13:31] <abeato> ogra, an image on beta channel for rpi3 should work?
[13:31] <ogra_> yup, i noticed that you got it working yesterday
[13:31] <ogra_> abeato, yes
[13:31] <abeato> ogra_, ack
[13:32] <ogra_> we'll release new ones later today or tomorrow on cdimage
[13:32] <ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/ has an interim one i just rolled for someone else
[13:32] <ogra_> in case you need something to dd right now
[13:32] <abeato> ogra_, thanks, will try to build one with u-d-f nonetheless
[13:33] <ogra_> u-d-f is unsupported now
[13:33] <ogra_> that will most likely not produce anything usable anymore
[13:33] <abeato> what do we use now?
[13:33] <ogra_> ubuntu-image ... and you need signed assertions
[13:33] <ogra_> just grab mine from the above url
[13:34] <abeato> yeah, that will be easier...
[13:35] <bull> ogra_,  http://people.canonical.com/~ogra/2CAF65BCd01.jpg :D
[13:43]  * zyga has a theory about what might be broken with ns sharing
[13:46] <bull> bye friends :*
[13:47] <morphis__> ogra_: why is HDMI output disabled on the official pi2 image?
[13:47] <ogra_> morphis__, ?
[13:47] <ogra_> works here
[13:47] <morphis__> ogra_: I had to change the config file on the boot partition to get it
[13:47] <morphis__> hdmi_safe=1
[13:48] <ogra_> weird, i tested console-conf and login onn various monitors here
[13:48] <ogra_> (well, two monitors and a TV)
[13:49] <ogra_> hdmi_safe should only be needed if your monitor has issues with the spec i heard
[13:50] <ogra_> "hdmi_safe Use "safe mode" settings to try to boot with maximum hdmi compatibility. This is the same as the combination of: hdmi_force_hotplug=1, hdmi_ignore_edid=0xa5000080, config_hdmi_boost=4, hdmi_group=2, hdmi_mode=4, disable_overscan=0, overscan_left=24, overscan_right=24, overscan_top=24, overscan_bottom=24 "
[13:50] <ogra_> haha
[13:50] <ogra_> "hdmi_ignore_edid Enables the ignoring of EDID/display data if your display is a crappy Chinese one "
[13:51] <bull> ogra_,  bye
[13:51] <bull> :Zzz
[13:51] <ogra_> ciao
[13:52] <ogra_> morphis__, so whats your monitor ... ?
[13:54] <morphis__> ogra_: hm, it was working well before from what I remember
[13:54] <ogra_> before what ?
[13:55] <ogra_> i dot thinnk we have changed anything in config.txt since 6 months
[13:55] <morphis__> ok
[13:55] <morphis__> then its a local problem here
[13:55] <ogra_> IIRC liuxg had probs as well and needed to use another HDMI port on his monitor, there it then jjust worked
[13:57] <ogra_> but perhaps we should actually default to hdmi_safe to get the widest compatibility ... i'm just a bit reluctant to add display options at all since these are dev boards ... mainly used for embedded development
[14:10]  * zyga -> coffee and food
[14:15] <zyga> jdstrand: ping me when you are around please
[14:16] <mectors> I am trying to upgrade a node-red snap to U16.04. The snap installs without problems. When I execute the snap/bin/nodered.red everything works fine but no .service is created. I am trying devmode. Don't see an error in syslog. What should I do?
[14:18] <zyga> mectors: look at the apps declaration, does it define this is a deamon?
[14:19] <mectors> No was a command. Will change to daemon
[14:19] <qengho> mectors: You're not making that a service. You're making it an app that you can run.
[14:20] <qengho> mectors: "daemon: OneOfTheDaemonTypes" underneath "command:".
[14:20] <mectors> thanks
[14:20] <zyga> jdstrand: http://pastebin.ubuntu.com/23182286/
[14:21] <zyga> jdstrand: aka WTF?
[14:21] <zyga> jdstrand: NOTE: ip in the core snap is not the one in classic
[14:21] <zyga> jdstrand: not sure if this matters in what you did earlier
[14:21] <zyga> jdstrand: I was also thinking if the way I pivot_root is buggy, I tweaked that locally but it has no observable effect
[14:22] <zyga> jdstrand: what bugs me is that I *can* open ns/net but ip cannot
[14:22] <mectors> fixed it. many thanks
[14:22] <zyga> (ip the command)
[14:28] <mup> PR snapd#1928 opened: hookstate,daemon: don't mock HookRunner, mock command <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1928>
[14:29] <jdstrand> zyga: it is very puzzling. I mean, it worked at one point!! I downgraded kernels (even to 4.3-- pre-trusty), used a fresh install of xenial desktop without upgrading, built an image using udf with os, kernel and gadget snaps from June, etc, etc
[14:30] <jdstrand> zyga: I even saw on the old xenial desktop that a new core snap was downloaded when installing hello-world so I replaced current symlink to use the old one. I think I have a few more things to play with there
[14:31] <zyga> jdstrand: maybe the core snap updated?
[14:31] <zyga> jdstrand: and old VMs may still have reeexec anbled
[14:31] <zyga> jdstrand: as a quick exercise, I can run unshare --net=foo
[14:32] <zyga> jdstrand: I can open /proc/self/ns/net from python
[14:32] <zyga> jdstrand: I'm utterly lost as to what this might be
[14:33] <zyga> jdstrand: quick question about pivot_root, does this change make sense: http://paste.ubuntu.com/23182323/
[14:33] <zyga> jdstrand: I read what pivot_root does again and I suspect that either docs are wrong or pivot_root . . should not be used
[14:33] <zyga> (this disabled nvidia binding because it's done in a way that needs the hostfs thing to be in place but I can move that to always happen after pivot root)
[14:37] <jdstrand> zyga: I think tyhicks may be able to better answer that, or possibly an lxd dev
[14:38] <jdstrand> (the pivot_root question)
[14:38] <jdstrand> I can do it, but it'll take me a while to say for sure
[14:39] <jdstrand> zyga: re the core snap updated-- it definitely did, which is why I tried to undo that. It's possible I didn't do that right and have a few more things to try there
[14:39] <zyga> jdstrand: don't worry about pivot root; I'll keep digging
[14:39] <tyhicks> zyga: what are you trying to achieve there?
[14:41] <jdstrand> zyga: regarding the permission denied-- it is seriously puzzling
[14:41] <zyga> tyhicks: use pivot_root correctly
[14:41] <zyga> tyhicks: perhaps avoid one more bind mount
[14:41] <zyga> tyhicks: ignore pivot_root unless you think it affects the big ns issue
[14:41] <zyga> tyhicks: I don't know if you are in the loop
[14:42] <zyga> tyhicks: if you want we can sync quickly
[14:42] <jdstrand> I need to look at another PR and will circle back
[14:42] <zyga> ok
[14:42] <tyhicks> I'm probably not up on what you've been up to the last day or two
[14:43] <tyhicks> the lxd devs will definitely have more real world experience w/ pivot_root than I do
[14:44] <zyga> tyhicks: long story short: the kernel behaves in super odd ways wrt net namespace; with snap-confine built from pull request https://github.com/snapcore/snap-confine/pull/145 "ip netns" gets permission denied to open /proc/$pid/ns/net (as shown by strace on http://pastebin.ubuntu.com/23182286/) but nothing apparently prevents this if you just try to open it directy (see the pastebin)
[14:44] <mup> PR snap-confine#145: Enable snap-confine namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/145>
[14:44] <zyga> this is all with devmode
[14:46] <zyga> tyhicks: and in that pastebin I also don't understand why this fails:
[14:46] <zyga> fstat(4, 0x7fff7fe39650)                = -1 EACCES (Permission denied)
[14:47] <zyga> 4 is stderr after dup()
[14:48] <zyga> might that be some kernel memory corruption?
[14:50] <tyhicks> I don't know much about network namespaces but that strace sure does look odd
[14:50] <tyhicks> let me think about it a little more
[15:00] <mup> PR snapd#1929 opened: Return proper icon URL for non-installed snaps <Created by jamiedbennett> <https://github.com/snapcore/snapd/pull/1929>
[15:06] <tyhicks> zyga: I don't have any good ideas about what's going on there
[15:06] <tyhicks> zyga: I'd have to spend quite a bit of time reading kernel code
[15:07] <zyga> tyhicks: ok, thanks
[15:24] <jdstrand> zyga: ok, I've circled back
[15:25] <jdstrand> I'll keep plugging away at trying to see when this once worked and try other things that I think of along the way
[15:27] <jdstrand> zyga: that said ^, there is perhaps something else to consider. the fact that this isn't working is odd to be sure, but this test (ip netns ...) working within a snap may not be as important if we think about the long term goal: a network-namespace-support interface that allows snaps to add network namespaces to the system and for other snaps to use
[15:28] <zyga> jdstrand: hmm
[15:28] <zyga> jdstrand: for that we'd have to solve the bi-directional mounting in general
[15:28] <jdstrand> zyga: in other words, since we know that network-namespace-support is the desired goal, if we can figure out how to achieve that without fixing this oddity, maybe that's ok
[15:28] <zyga> jdstrand: or do you plan snapd to create the namepaces centrally?
[15:29] <jdstrand> that's up for discussion
[15:29] <zyga> jdstrand: ok, so what shall we do
[15:29] <jdstrand> it seems clear that people will want to use 'ip netns' to setup namespaces. lots of existing code does that
[15:29] <jdstrand> our 'ip' command could be modified to talk to snapd
[15:30] <zyga> jdstrand: I'm inclined to merge this, add more spread tests
[15:30] <zyga> jdstrand: for both working and OMG/WTF broken cases
[15:30] <zyga> jdstrand: and decide if we want to enable this for release or not
[15:40] <mup> PR snapd#1924 opened: tests: disable prepare-image-grub test in autopkgtest <Created by mvo5> <https://github.com/snapcore/snapd/pull/1924>
[16:00] <mectors> just uploaded nodered.mectors. Says it is published but can't see it in the uApp Explorer or install it via snap install.
[16:01] <kyrofa> mectors, did you publish it in a specific channel?
[16:03] <mectors> no just did snapcraft push
[16:04] <kyrofa> mectors, are you familiar with channels?
[16:04] <mectors> kyrofa pushing it to stable now
[16:04] <kyrofa> mectors, ah very good, okay
[16:05] <kyrofa> mectors, so yeah, you can snapcraft push to specific channels, or snapcraft release after the fact, or do it all in from the myapps site
[16:05] <kyrofa> s/all in/all/
[16:05] <kyrofa> But snapcraft push by default doesn't put it in any channels
[16:07] <mectors> kyrofa I updated the channel to stable on myapps but nothing. it says it passed all 40 checks there
[16:08] <mectors> kyrofa sorry my mistake was trying nodered.mectors but nodered works
[16:08] <kyrofa> mectors, good deal!
[16:09] <kyrofa> ev, I've been noticing numerous misunderstandings stemming from the fact that the store shows <snapname>.<publisher> in the header. Is there a reason for leaving it that way?
[16:10] <ev> kyrofa: no, there isn’t and as I’ve come across that myself I’ve considered it part of the task to switch from “short namespaces” to SSO usernames, but they’re orthogonal.
[16:16] <shuduo> matteo: hi, so you can see embedded wifi interface with your image/kernel, right? do you see it in console-conf phase?
[16:30] <zyga> jdstrand: it is quite easy to crash the kernel with various mount calls
[16:30]  * zyga hugs VMs
[16:40] <sergiusens> mectors next time, you can do `snapcraft release <snap-name> <revno-from-store> <channel>`
[16:41] <matteo> shuduo: hi
[16:41] <sergiusens> kyrofa hey, you don't push to channels, you release to channels ;-)
[16:41] <matteo> shuduo: you mean the web interface? yes
[16:42] <shuduo> matteo: do you use pi2-kernel?
[16:44] <matteo> let me check
[16:44] <matteo> pi2-kernel   4.4.0-1021-3  14   canonical  -
[16:45] <zyga> matteo: hey :)
[16:45] <mup> PR snapd#1929 closed: Return proper icon URL for non-installed snaps <Created by jamiedbennett> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1929>
[16:45] <matteo> hi zyga
[16:45] <sergiusens> wow cjwatson, thanks for taking that macaroon task!
[16:47] <cjwatson> sergiusens: np, it happened to hit me and I already have code in LP that does much the same thing
[16:48] <shuduo> ogra_: hi, i'm following the doc "Ubuntu Core Image building" and generated an image for pi3. Now I see some issues like:
[16:49] <shuduo> 1, it booting up time is very long if I plug ethernet cable. if no ethernet cable, it can boot up to console-conf soon. Is it a known issue?
[16:50] <ogra_> nope, definitely not known
[16:50] <shuduo> 2, I can't see integrated wireless interface, is it a known issue? I use pi2-kernel.
[16:50] <matteo> shuduo: do you want my ubuntu core image and openwrt snap?
[16:50] <ogra_> yes, the wifi interface is only seen in very recent console-conf versions ... in the edge channel
[16:51] <ogra_> but it doesnt not work right yet
[16:51] <matteo> I'm using ethernet to access internet, and the wifi as AP
[16:51] <ogra_> shuduo, http://people.canonical.com/~ogra/snappy/all-snaps/u-image-pi3.img.xz
[16:51] <shuduo> matteo: yes, pls.
[16:51] <shuduo> ogra_: okay, let me try your image too.
[16:52] <matteo> shuduo: I'm pushing everything here: https://people.canonical.com/~teknoraver/
[16:52] <ogra_> shuduo, we'll release an image like that this week
[16:53] <matteo> zyga: why this test fails, in your opinion= http://<IP_ADDRESS>:8080/job/github-snapcraft-autopkgtest-yakkety-snaps-cloud/5/console
[16:53] <shuduo> ogra_: good to know. we want to demo openwrt snap with pi3 at end of Sept. it would be great if later image do everything well. :)
[16:54] <ogra_> well, there are still issues with wlan vs eth on the pi3 ... but these should surely be fixed before end of the month :)
[16:54] <zyga> matteo: looking
[16:55] <zyga> ah, vpn
[17:03] <matteo> ping mvo
[17:07] <mvo> matteo: pong (with some latency, but I will read/reply eventually)
[17:08] <matteo> I have an unit test which fails in an odd way
[17:08] <matteo> maybe it's not related to my commit
[17:08] <matteo> so you may want to have a look
[17:08] <matteo> mvo: http://<IP_ADDRESS>:8080/job/github-snapcraft-autopkgtest-yakkety-snaps-cloud/5/console
[17:10] <mvo> matteo: fix in git should actually be fixed in yakkety already
[17:10] <matteo> so if I trigger a new test it will pass?
[17:23] <kyrofa> sergiusens, I mean the push command supports releasing as well, no?
[17:24] <sergiusens> kyrofa yes it does, `snapcraft push <snap-file> --release <channel>`
[17:24] <sergiusens> kyrofa that's release on push, not push to a channel though ;-)
[17:24] <kyrofa> sergiusens, meh :P
[18:04] <sergiusens> stgraber any way to figure out what is going on here? http://paste.ubuntu.com/23183087/
[18:06] <stgraber> sergiusens: hmm, well, LXD forks tar and tar got sigkilled, not sure why
[18:06] <stgraber> sergiusens: out of memory maybe?
[18:06] <stgraber> sergiusens: anything in dmesg?
[18:07] <sergiusens> stgraber yeah, out of mem; strange
[18:08] <sergiusens> I am on a fresh boot
[18:08] <stgraber> oh, actually, that's unsquashfs not tar for that image I guess
[18:09] <sergiusens> stgraber yup
[18:09] <sergiusens> [  598.420356] Out of memory: Kill process 8056 (unsquashfs) score 506 or sacrifice child [  598.420664] Killed process 8056 (unsquashfs) total-vm:645224kB, anon-rss:260812kB, file-rss:0kB
[18:09] <stgraber> how much memory do you have on that system?
[18:10] <stgraber> unsquashfs using 260MB of RAM while not light doesn't seem entirely unreasonable to me
[18:11] <sergiusens> stgraber ah, I have 512
[18:12] <stgraber> how many CPUs in /proc/cpuinfo?
[18:13] <sergiusens> stgraber just the one http://paste.ubuntu.com/23183119/ its a DO droplet
[18:13] <stgraber> weird, not sure why unsquashfs would use more memory than the size of the whole image
[18:14] <mup> PR snapd#1928 closed: hookstate,daemon: don't mock HookRunner, mock command <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1928>
[18:18] <stgraber> sergiusens: I'm testing some unsquashfs options to work on low memory systems
[18:19] <stgraber> sergiusens: running on a 64MB system now with 48 cores, so kinda worst case scenario :)
[18:25] <sergiusens> stgraber yeah, this used to work before, I guess before the move to squash, more so, I have 3 containers here running fine
[18:27] <stgraber> sergiusens: hmm, so I managed to launch a container using a squashfs image just fine on that crazy 64MB system...
[18:27] <stgraber> sergiusens: unsquashfs memory use was showing at 40MB or so
[18:28]  * stgraber pokes things harder
[18:36] <mup> PR snapd#1914 closed: docs: add a little documentation on hooks <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1914>
[18:39] <mup> PR snapd#1888 closed: interfaces: allow special casing for auto-connect until we have assertions <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1888>
[18:40] <mup> PR snapd#1924 closed: tests: disable prepare-image-grub test in autopkgtest <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1924>
[18:44] <kgunn> kyrofa: hey there, so i'm seeing something really interesting...
[18:44] <kyrofa> kgunn, yeah what's up?
[18:45] <kgunn> we've got a snap we're building that's pretty big admittedly...unity8...and it pulls in qtmir
[18:45] <kgunn> so the qtmir pkgs are there in the snap on amd64
[18:45] <kgunn> however, on arm64
[18:45] <kgunn> they are missing....
[18:45] <kgunn> this is true for a snap that was built with lp builders and then one built in a cross build chroot locallly
[18:46] <kgunn> and...to boot...the one built locally
[18:46] <kgunn> the files are in stage and prime!
[18:46] <kgunn> but not in the snap
[18:46] <kgunn> ....oh, and i just added qtmir pkgs specifically to part as stage (using nil plugin)
[18:46] <kgunn> and they still didn't make the snap
[18:46] <kgunn> any ideas?
[18:46] <kyrofa> Hmm
[18:46] <kgunn> AlbertA: ^
[18:47] <kyrofa> If files are in prime, they should 100% definitely be in the snap
[18:47] <kyrofa> Because making the snap is literally running mksquashfs on the prime dir
[18:47] <kyrofa> kgunn, so something is weird here
[18:47] <kgunn> kyrofa: don't suppose you know if you can verify what's in the prime from launchpad ?
[18:48] <kyrofa> kgunn, unsquashfs the resulting snap. I can't think of a single way the prime dir could be different
[18:48] <kgunn> AlbertA: wanna shoot me link for arm64 version one more time from the chroot that definitely had the qtmir stuff in prime?
[18:48] <AlbertA> kgunn: yeah it's
[18:48] <kgunn> just to make sure
[18:49] <AlbertA> https://private-fileshare.canonical.com/~alberto/unity8-session_0_arm64.snap
[19:02] <kyrofa> kgunn, when you say qtmir, are you talking about qtdeclarative5-qtmir-plugin? Or qtmir-desktop?
[19:04] <kyrofa> kgunn, doesn't matter-- both of them are in there
[19:04] <kgunn> right
[19:04] <kyrofa> kgunn, so am I missing something?
[19:05] <kgunn> kyrofa: one sec....got distracted lemme install and check
[19:13] <kgunn> kyrofa: so upon install of that same snap on my dragonboard i get
[19:13] <kgunn> ubuntu@localhost:/snap/unity8-session/current$ sudo find -iname qtdeclarative5-qtmir-plugin
[19:13] <kgunn> ./usr/share/doc/qtdeclarative5-qtmir-plugin
[19:13] <kgunn> ubuntu@localhost:/snap/unity8-session/current$
[19:13] <kyrofa> kgunn, that makes sense, no?
[19:14] <kyrofa> kgunn, find -iname libunityscreensplugin.so should find the lib contained within that package as well
[19:14] <kgunn> kyrofa: sorry i meant this one
[19:14] <kgunn> ubuntu@localhost:/snap/unity8-session/current$ sudo find libqpa-mirserver*
[19:14] <kgunn> find: ‘libqpa-mirserver*’: No such file or directory
[19:15] <kgunn> ubuntu@localhost:/snap/unity8-session/current$
[19:15] <kgunn> kyrofa: ah...yeah, i see it now
[19:16] <kgunn> ubuntu@localhost:/snap/unity8-session/current$ sudo find -iname libqpa*
[19:16] <kgunn> ./usr/lib/aarch64-linux-gnu/qt5/plugins/platforms/libqpa-mirserver.so
[19:16] <kgunn> ./usr/lib/aarch64-linux-gnu/qt5/plugins/platforms/libqpa-ubuntumirclient.so
[19:16] <kgunn> the damn "minus" sign i forgot find get's angry
[19:17] <kyrofa> Hahaha
[19:18] <kyrofa> So does that all look okay then?
[19:19] <kgunn> kyrofa: yes....now i probably made a stink over nothing
[19:20] <kgunn> i bet the lp built one is fine
[19:20] <kgunn> kyrofa: fwiw, we did really have one at one point where it wasn't included....so it got us all amped
[19:20] <kgunn> i think it was a fluke
[19:20] <kgunn> ...and we verified the pkgs weren't there in the sstage/prime area...
[19:20] <kyrofa> kgunn, heh, well if you run into it again, let me know!
[19:21] <kgunn> yeah, see something once like that, makes you all paranoid...
[20:03] <stgraber> sergiusens: https://github.com/lxc/lxd/pull/2383
[20:03] <mup> PR lxc/lxd#2383: Tweak squashfs for low-memory systems <Created by stgraber> <https://github.com/lxc/lxd/pull/2383>
[20:03] <stgraber> sergiusens: with that change in place, I could get LXD to mostly work on a system with just 64MB of RAM
[20:03] <stgraber> sergiusens: mostly in the sense that container creation worked fine, but as soon as the container started, the OOM killer started killing everything :)
[20:04] <stgraber> sergiusens: though that was when running a full Ubuntu in the container, something like busybox would have run without triggering OOM kills I expect
[20:12] <sergiusens> stgraber great, in the meantime I upped the mem for my droplet :-)
[20:13] <stgraber> sergiusens: ok, you could have put a simple wrapper around unsquashfs in /usr/local/bin setting the same options I set in that patch
[20:14] <sergiusens> stgraber I will try your branch later tonight and get back to you to see how it went
[20:14] <stgraber> sergiusens: ok. it should be fine since I got it to run on a system with just 64MB :)
[20:18] <mup> PR snapd#1930 opened: many: support snapctl -h <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1930>
[20:41] <chiluk> hey guys I'm still trying to learn snappy, and I'm trying ot snap up the file command, because I thought it would be simple
[20:42] <chiluk> this is what I have so far http://paste.ubuntu.com/23183657/
[20:42] <chiluk> but whenever I go to run file after installing my snap I get /etc/magic, 0: Warning: using regular magic file `/usr/share/misc/magic'
[20:42] <chiluk> file: could not find any valid magic files!
[21:03] <chiluk> I tried to explicitly copy the configs per https://github.com/owncloud/ubuntu-snap/wiki/Building-your-first-snap and got http://paste.ubuntu.com/23183708/   but I get the same results.
[21:04] <chiluk> what am I missing here?
[21:04] <chiluk> I guess I'll send mail to the mailing list.
[21:20] <mup> PR snapcraft#804 opened: Adjust login to conform to UX specification <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/804>
[21:59] <mwhudson> ogra_: https://github.com/CanonicalLtd/subiquity is public now fwiw
[22:01] <jdstrand> morphis: fyi, I approved udisks2 but you need to press the publish button
[22:37] <ahoneybun> was there a change in snapd that you can install a snap that is not signed?
[22:37] <ahoneybun> *can't
[22:37] <lpotter> ahoneybun: yes there was. add --force-dangerous
[22:37] <ahoneybun> thanks lpotter
[22:38] <ahoneybun> tried to install a inkscape snap from LP and it failed because of a missing signature
[22:41] <ahoneybun> is it "snap install --force-dangerous?
[22:43] <lpotter> yes
[23:05] <sergiusens> stgraber that did the trick btw
[23:43] <stgraber> sergiusens: cool


[13:14] <BluesKaj> Hi all
[23:43] <Eickmeyer[m]> So uh... shouldn't Kubuntu Focus be on https://kubuntu.org/vendors/ as well?