[01:21] <MauroGaspari[m]> Eickmeyer: OvenWerks RikMills Are you guys going to Akademy this year? I will be there, would be nice to have a chat in person.
[02:24] <Eickmeyer[m]> Mauro Gaspari: There's no way I can make it, just not enough time. In addition to my job, which is work-from-home, I'm also a stay-at-home dad, and taking over a week off from that would be rough on my family.
[03:11]  * OvenWerks is not indepenently wealthy. Quite honestly there is a lineup of things waiting to take his money  ;)
[07:11] <MauroGaspari[m]> Aww I was hoping to see you guys 😭
[07:12] <RikMills> MauroGaspari[m]: sadly, no
[07:16] <MauroGaspari[m]> It's ok, I love you all anyway 😅
[14:28] <OvenWerks> Problems with the systray audio volume applet again...
[14:28] <OvenWerks> it doesn't see reality
[14:33] <OvenWerks> doesn't control reality either
[14:36] <OvenWerks> Eickmeyer[m]: pavucontrol shows the output as jack sink. pavucontrol also shows jack source/sink as the only devices available. Settings->audio also shows the same thing.
[14:40] <OvenWerks> however, the systray volume control when clicked shows no jacksinks but rather whatever physical devices pulse would have seen before we deleted them all. Using the mouse wheel on the systray icon seems to move the control on one of the devices but the device itself is not set or changed.
[14:53] <OvenWerks> Eickmeyer[m]: how do I find the package this comes from? When I click on the icon and get a window there is a setting button and opening that gives me: Audio Volume settings - Plasma. The about button says Audio Volume 1.0.0
[14:57] <OvenWerks> however, I see plasma-pa is installed as an applet but that is version4:5.24.4
[15:12] <OvenWerks> restarting jack does fix it (at least this time)
[15:42] <Eickmeyer[m]> OvenWerks: As far as I know, the system tray applet is part of plasmashell itself, but RikMills would have more info.
[15:43] <Eickmeyer[m]> You might try adding ppa:kubuntu-ppa/backports and see if the issue is resolved there.
[15:44] <OvenWerks> I would be surprised if it was. I suspect it has something to do with controls starting at the same time as the applet
[15:45] <Eickmeyer[m]> I've typically resolved it by restarting plasmashell with alt-space "plasmashell --replace".
[15:51] <Eickmeyer[m]> But yeah, it's got race condition written all over it.
[15:55] <OvenWerks> I wonder if there is a way of detecting the widget has started or plasma shelll has started
[15:59] <OvenWerks> Hmm, maybe look at the ppid and if it is not controls, add delay
[16:12] <RikMills> what about button?
[16:13] <OvenWerks> RikMills: button?
[16:14] <RikMills> OvenWerks: quote " The about button says Audio Volume 1.0.0"
[16:15] <OvenWerks> RikMills: the volume control applet (the one you can set your mouse on and scroll the audio level up and down) has a setup icon that opens a window
[16:16] <OvenWerks> that window has three tabs: General, keyboard shortcuts and about.
[16:16] <OvenWerks> That about tab/button
[16:16] <OvenWerks> It also says the author is Harold Sitter
[16:17] <OvenWerks> (and GPL licence)
[16:17] <RikMills> oh, I though you meant pulse audio volume control
[16:17] <RikMills> that is plasma-pa AFAIK
[16:18] <OvenWerks> but that version does not match the version of plasma-pa
[16:22] <RikMills> I guess comes from: https://invent.kde.org/plasma/plasma-pa/-/blob/master/applet/metadata.desktop#L116


[00:09] <Noldorin> jelmer, ah ok...
[00:09] <Noldorin> so absolute path
[00:09] <Noldorin> fair enough
[05:26] <Pegasus_RPG> Hello. Quick question: if I bzr cp a file to another name, will future changes to the original be propagated to the copy?
[07:32] <vila> hi all !
[07:50] <jelmer> hi vila
[08:01] <mgz> morning!
[08:01] <jelmer> mgz!
[08:01] <vila> jelmer: regarding bzr-upload, as mentioned in the review, I want to use dedicated series, not maintain compatibility at all costs on trunk
[08:01] <vila> hey mgz
[08:01] <vila> standup ?
[08:01] <jelmer> vila: the plugin's metadata suggests it still supports 2.4
[08:02] <vila> because we didn't bump the internal API for 2.5...
[08:02] <vila> so apples and oranges
[08:02] <vila> and as mentioned in NEWS, the code is still compatible with 2.4 so far, only the tests requires 2.5
[08:03] <vila> but one needs to start somewhere :)
[08:03] <vila> the intent is to have a 1.1.0 when bzr-2.5.0 is released
[08:05]  * jelmer looks for his headset..
[08:09] <jelmer> got it
[08:09] <jelmer> vila, mgz: mumble?
[08:09] <vila> jelmer: there we are ;)
[10:54] <vila> jelmer, mgz : can you have a look at https://code.launchpad.net/~bzr/bzr/doc/+merge/84069 ? Given my implication I can't review it anymore ;)
[10:54] <alansaul> Hey guys, how can I get previous versions of a file that I accidently deleted?
[10:55] <alansaul> I dont want to take everything back, just them, can i just do a revert x.rb
[10:55] <jelmer> vila: sure
[10:55] <mgz> ...it didn't seem from the comments I saw go past there were any issues with that mp vila
[10:55] <mgz> alansaul: yup.
[10:55] <vila> mgz: yup, no issues AFAICS, but voting on it myself seems a bit... bizarre
[11:00] <vila> oh crap a > 2.000 lines proposal :-/ Hmm, at least the submitter signed with his own blood that it's mechanical ;)
[11:00] <mgz> we can throw things at him if it breaks stuff :)
[11:02] <vila> Yeah, the most irritating part is to think that annotations will be broken one way or the other :--/
[11:02] <jelmer> vila: +1ed
[11:02] <vila> jelmer: thanks
[11:02] <mgz> vila: on the annotations front, just think of it as jelmer accepting all blame from now on
[11:03] <vila> hehe
[13:04] <mgz> okay, made a teeny bit more work for the pilot, time for lunch
[13:30] <jelmer> vila: when you have a chance, a review of https://code.launchpad.net/~jelmer/bzr/hpss-call-counts-3/+merge/84494 would be great - it fixes the hpss call count for lightweight checkouts which is causing spurious failures
[14:00] <jam1> jelmer, mgz: I'm getting a weird bug with latest bzr.dev
[14:01] <jam1> It is trying to take a lock: "~jameinel/u1db/index-transformations/.bzr/branchlock"
[14:01] <jam1> shouldn't that be: ~jameinel/u1db/index-transformations/.bzr/branch/lock
[14:01] <jam1> ?
[14:01] <jam1> It looks like a bad trailing-slash normalization bu
[14:01] <jam1> bu
[14:01] <jam1> bug
[14:01] <jelmer> hey jam1
[14:01]  * jam1 goes to a speech therapist for stuttering :)
[14:01] <jelmer> jam1: looks like you're also hitting a bad trailing-'g' normalization bug :-P
[14:02] <jelmer> it does seem like that could be related to the recent URL changes
[14:02] <mgz> what fun.
[14:02] <jelmer> jam: is this on Windows?
[14:02] <jam> currently, yes
[14:03] <mgz> jam: file a bug with the command to run, we can probably repo and fix.
[14:03] <jam> jelmer: http://paste.ubuntu.com/761635/
[14:03] <jam> mgz: I'm just running 'bzr push' to launchpad :)
[14:04] <mgz> o_O
[14:04] <jam> k, weird, I also get it with bzr.dev -r-200
[14:04] <mgz> r6079 is one known breaker
[14:05] <mgz> if r6078 works and that one doesn't, means there's an extra regression the test suite didn't catch
[14:05] <jam> well -200 is 6145
[14:06] <jam> mgz: well, I generally keep up to date with bzr.dev, so 6078 seems a bit to old, but it does indeed work and 6345 does not
[14:06] <jam> too
[14:06] <jam> now I'm at "nothing to push", so I can't continue to validate it
[14:07] <mgz> quick, write more code! :)
[14:12] <wgz> okay, I don't get it just pushing to +junk so there must be something specific going on with the branch layout
[14:14] <jam> mgz: https://bugs.launchpad.net/bzr/+bug/900764
[14:14] <wgz> ...or with u1db
[14:14] <jam> Looks like I was using rev 6322 this morning, and I'm using 6345 when I noticed things were broken.
[14:15] <jam> wgz: you can't hide from me :)
[14:15] <jam> even weirder, I think I had successfully pushed a couple of times. Maybe it is a remote autopack issue?
[14:15] <jam> but that shouldn't trigger a bug locking the branch
[14:15] <wgz> oo... ooooo
[14:15] <wgz> repacking would be extra fun.
[14:16] <jam> well the failure is early on in bzrlib.push._show_push_branch
[14:16] <jam> during the first remote write lock call on the Branch.
[14:19] <jam> well, something is working now...
[14:19] <wgz> how do we get logs from the launchpad side?
[14:19] <jam> I wonder if it was a display bug, coupled with a temporary Launchpad failure.
[14:20] <wgz> hm.
[14:20] <wgz> that's an interesting thought, and testable.
[14:22] <jam> mgz/wgz: Interestingly, I have 4 emails in my inbox from Launchpad talking about failures to generate merge proposals.
[14:23] <jam> looks like something with the librarian there
[14:28] <jelmer> yeah, the librarian was down for a while becuase of hardware problems
[14:28] <wgz> I got a 503 from the librarian just before you posted.
[14:29] <jelmer> it's not involved in code hosting though, as far as I know
[14:42] <wgz> coming back and looking at the bug report again, I don't think it can be a bzr.dev regression
[14:43] <wgz> the LockDir url is constructed on the launchpad side and just being reported to the client
[15:00] <vila> jelmer: done
[15:03] <jelmer> vila: thanks
[15:06] <mgz> vila: for some reason, I'm not getting your mail sent to the bzr list
[15:07] <mgz> can read it in the html list archive, but neither of your last two "week in" emails got to my inbox
[15:07] <vila> o_O
[15:08] <vila> mail log confirms the one for this morning was sent
[15:09] <vila> not received but I'm pretty sure that's how I configured my subscription
[15:09] <vila> (i.e. don't send me my own mails, thanks)
[15:13] <mgz> it got as far as the list, but didn't then get back out to me
[15:14] <mgz> and your last week's one had the same issue, I only saw it existed because I got the reply-to-the-reply
[15:14] <vila> bah, vila, learn to read, he said the mail went to the list, not a problem on your side
[15:15] <vila> mgz: that leaves: 1) an issue at your provider (aggressive spam filtering), 2) a wrong filtering on your side ?
[15:15] <vila> mgz: they don't like French maybe ? ;-p
[15:16] <mgz> it's canonical then google, and didn't get spamified
[15:16] <vila> oh, on google ?
[15:16] <mgz> I was wondering if there was anything else odd about either message that might cause it to get dropped
[15:16] <vila> see ? They know far too much already :)
[15:16] <vila> hmm, I can't imagine what can be different, let me check again
[15:18] <vila> mgz: here is my local copy: http://paste.ubuntu.com/761701/
[15:19] <vila> mgz: the only lines that you probably won't find in your copy are the 'X-Draft-From' and 'Xref' ones which are local
[15:19] <vila> you should have more Received: lines though
[15:20] <vila> in other news, consistent oops on https://code.launchpad.net/~gz/bzr/mv_removed_non_ascii_898541/+merge/84609
[15:21] <vila> some one is trying to get between us, mgz, what a nefarious (but hopeless) conspiracy !
[15:23] <vila> there is a suspicious "Warning: <type 'exceptions.KeyError'>: 'branch'" in the oops page...
[15:23] <vila> just after a: "Warning: Macro expansion failed"
[15:23] <vila> any recent bzr deployment on lp ?
[15:25] <mgz> don't think so, but given jam's earlier experience something is up with the launchpad codehosting
[15:25]  * vila nods
[15:28] <vila> the librarian failure seem to have triggered a bunch of import failures.... and the importer caught them as lp down times and happily retried them, ending up with 0 additional failures \o/
[15:29] <vila> it did flip-flop a lot (back/down/back/down) but still managed to retry all the right ones
[15:30] <mgz> what's one of your oops # vila?
[15:30] <vila> (Error ID: OOPS-cbc7444249203b34468eab8a253cf7f1)
[15:31] <mgz> ...actually it's so consistent I can also get my own on that mp
[15:32] <vila> there are several urls with %7Egz (I thought we settled on ~ being legal and as such never quoted anymore, may be not landed on lp ??)
[15:35] <mgz> ...the oops page is really not very browsable
[15:36] <vila> yup :)
[15:36] <jelmer> vila: yes, that's not on LP yet
[15:37] <vila> with 'that' being 'stop quoting ~' ?
[15:37] <mgz> alright, is librarian related, forgot they put the diffs there
[15:38] <vila> yeah, librarian related but librarian is back. Did you propose while it was down ?
[15:38] <mgz> (what jam was saying earlier about getting diff generation failure email should have twigged earlier)
[15:38] <vila> s//submit/
[15:38] <mgz> it lost some files apparently, they need reuploading
[15:39] <mgz> anyway, they're on it, so won't bug 'em further
[15:52] <vila> jelmer: wow, that was confusing (the test rewrites), I got it now
[15:52] <mgz> vila: oh conflicts expert
[15:53] <mgz> how in the hell you you get to the state:
[15:54] <vila> 2.4.2 is still in -proposed ?
[15:54] <mgz> added: config.py / conflicts: Conflict adding file config.py. Moved existing file to config.py.moved.
[15:54] <vila> mgz: different file-ids for the same file
[15:54] <mgz> I can only get to a added: removed: conflicts: state.
[15:54] <mgz> not a modified one.
[15:55] <mgz> without the removed.
[15:55] <vila> what branches do you encounter that in ?
[15:55] <mgz> the repo of a bug in qbzr.
[15:56] <mgz> I have the guy's branch state, but not clear instructions on how he got there, so I'm not sure how to write the test.
[15:56] <vila> bzrlib.tests.test_conflicts
[15:56] <vila> ha, crap, you don't like the way these tests are written
[15:57] <vila> I had an idea about how to rewrite them but I've yet to do it ;)
[15:57] <vila> at least you'll get the bits you need
[15:57] <vila> also, you can have a look at po_merger tests which are script-based and easier to grasp,
[15:58] <vila> basically you create a branch with all the stuff you need and then branch from the "right" revisions
[15:58] <mgz> anyway, just creating two branches with the same file and merging doesn't do it.
[15:58] <mgz> as in, diverging from the same root
[15:59] <vila> mwhahaha, I want some of either 1) what you're smoking, 2) the tweaked bzr addressing the parallel import issues you're using ;)
[15:59] <vila> if merge doesn't conflict merging the same path with two different file-ids it's probably because both paths use the same file-id :)
[16:00] <mgz> it conflicts alright, but not the right way
[16:00] <vila> text conflict ?
[16:00] <mgz> I get added/removed, the example branch just has modified
[16:00] <mgz> but with the conflict saying .moved has been created
[16:00] <mgz> the diff is just a line in the file
[16:01] <mgz> my diff is two files, one added, one removed
[16:01] <vila> meh, I'm lost, can you paste your test ?
[16:01] <mgz> ...I should look at the history in qbzr
[16:02] <mgz> o_O there is only one revision
[16:03] <wgz> vila: zip attachment in bug 815822
[16:03] <vila> jelmer: looking at https://code.launchpad.net/~bzr-core/ubuntu/oneiric/bzr/sru-2.4.2/+merge/81039 , shouldn't some sru team be subscribed there ?
[16:04] <wgz> edit testrepo-fb-checkout/.bzr/branch/location to point to the right abspath of where you unpack it, then inspect testrepo-fb-checkout
[16:06] <wgz> okay, I think I have an idea
[16:06] <vila> grrr, of course I read that after doing it :)
[16:06] <kirkland> jelmer: hey there!  back to my line of bzr/git import questions
[16:07] <vila> wgrant: obviously the .moved file is not there anymore
[16:07] <kirkland> jelmer: so i did my 'bzr up' in each of a dozen or so of the dirs that I imported from git into bzr
[16:07] <vila> wgrant: sry, bad completion
[16:07] <vila> wgz: obviously the .moved file is not there anymore
[16:07] <kirkland> jelmer: now, it is customary to push each of those to its own branch in LP?
[16:07] <kirkland> jelmer: for history/tracking purposes?
[16:07] <mgz> vila: it's just an idea, I still want the expert opinion :)
[16:07] <kirkland> jelmer: or how do others handle that?
[16:08] <mgz> I think the way I was doing it was wrong, I have two child branches both create a file then merge one to the other
[16:08] <jelmer> hi kirkland
[16:08] <kirkland> jelmer: howdy :-)
[16:08] <mgz> perhaps what's needed is a child branch to create a new file, move it over the file in the parent branch, then merge child to parent
[16:08] <kirkland> jelmer: so there are a handful of tags (v1.5, v1.4.3, v1.7, etc)
[16:09] <jelmer> kirkland: tags will be stored in the branch as well ("bzr tags")
[16:09] <vila> mgz: or create a new file with the same path in branch A and B, then merge ../B
[16:09] <jelmer> kirkland: but branches from git are usually pushed as separate branches onto Launchpad
[16:09] <kirkland> jelmer: as I described?
[16:09] <mgz> vila: that gives me the conflict I had, which is added f, removed f
[16:10] <vila> mgz: but from a quick look, the stuff in error.zip is incomplete
[16:10] <mgz> rather than modified f
[16:10] <jelmer> vila: see poolie's comment on that MP
[16:10] <jelmer> kirkland: it depends on your situation a bit - most people register launchpad imports to track branches in git
[16:11] <jelmer> kirkland: what's the situation in which you're using bzr-git?
[16:11] <kirkland> jelmer: I'm helping my new company migrate from git to bzr/Launchpad
[16:11] <vila> jelmer: I followed the comment to bug #848064 and there he says (and I pretty much agree) that this is not specific to bzr (or at least we don't have evidence so far)
[16:12] <kirkland> jelmer: they have one project (private/proprietary in Launchpad)
[16:12] <jelmer> kirkland: ah, I see - in that case what you described indeed makes the most sense - push each separate branch import from git as a separate branch on Launchpad
[16:12] <kirkland> jelmer: great
[16:12] <jelmer> kirkland: the tags should come along
[16:12] <kirkland> jelmer: okay, I'll have a look
[16:12] <vila> mgz: ctrl-alt-del, looks like I misunderstood
[16:12] <jelmer> kirkland: (and new versions of bzr-git will in fact no longer create separate directories for tags)
[16:13] <kirkland> jelmer: oh, interesting
[16:14] <kirkland> jelmer: okay, thanks for your help, cheers!
[16:14] <vila> mgz: .moved is the THIS file (confusing)
[16:15] <vila> mgz: therefore, the added one should be the OTHER file
[16:16] <vila> mgz: bbiab
[16:38] <jelmer> vila: argh, Option didn't have a help argument in 2.4 :-(
[16:57] <mgz> ha! got the repo
[16:57] <mgz> ...that was the most convoluted thing ever
[16:59] <vila> jelmer: and you encounter that in what context ?
[17:02] <vila> mgz: so, fresh from the bug, he did delete .moved file and AFAICS we don't have the branch he was merging from
[17:02] <vila> mgz: additionally, his dirstate file seem to miss the revid for the merge too :-/
[17:03] <vila> mgz: on the other hand, he provided the .zip to reproduce a bug which is not related to conflicts.
[17:04] <vila> mgz: in a nutshell, the branch he provided may not be one you can re-create
[17:07] <mgz> vila: I don't have the exact dirstate he got, the 'modifed' thing is mystifying as the bug needs no file-id to repo
[17:07] <mgz> but I have a series of steps that gets that problem
[17:08] <vila> mgz: with bzr-2.3.4 ?
[17:08] <mgz> with current bzr, the logic error in qbzr is reasonably clear
[17:08] <mgz> it's just less obvious how to actually trigger it
[17:09] <mgz> I'll wave the test case in front of you
[17:09] <mgz> (shortly)
[17:09] <vila> k
[17:13] <jelmer> vila: current bzr-svn trunk is broken with bzr 2.4
[17:15] <vila> ha, because of the new config support ?
[17:15] <vila> jelmer: I thought I mention the compatibility part not being addressed when I first submitted but then thought you had different series targeted at 2.4 and 2.5 and finally, I forgot about it :-/
[17:16] <jelmer> vila: np, it's not too hard to work around
[17:17] <vila> jelmer: so, more than help should cause problems no ?
[17:20] <jelmer> vila: some other minor regressions, fixing them now
[17:20] <vila> jelmer: what kind ?
[17:21] <jelmer> vila: not related to config, but apart from that bzr-svn trunk is 2.4-compatible
[17:21] <vila> but not 2.3 ? Where do you draw the line ?
[17:22] <vila> jelmer: stable + trunk ?
[17:22] <jelmer> vila: 2.4 and bzr.dev at the moment
[17:22] <vila> k
[17:22] <jelmer> vila: it varies, I dropped 2.3 support a month or so ago
[17:23] <jelmer> vila: I usually aim for the latest stable series and bzr.dev, but it depends on how hard it is to stay compatible
[17:24] <vila> now that you mention it, you probably want to add a .id attribute in your store
[17:24] <jelmer> vila: anyway, I just noticed it as I was trying to actually switch over some code to use the new options stuff
[17:25] <vila> right, it's opt-in at the option level
[17:25] <vila> but even the new options can still be read/modified with the old implementation
[17:27] <jelmer> vila: right, but how well will 2.4 work?
[17:28] <vila> bzr-2.4 use the new config implementation for only one (or a few) options
[17:29] <vila> so it should work at it works before :)
[17:29] <vila> worked
[17:29] <vila> as far as bzr-svn is concerned, get_config_stack will not be called and since no branch option use get_config_stack in bzr-2.4 nothing has changed
[17:30] <vila> jelmer: unless you encounter a scenario I can't imagine ?
[17:38] <jelmer> vila: I'm wondering whether I should start using get_config_stack in bzr-svn, or if that will affect compatibility with bzr 2.4
[17:39] <vila> that should even break with bzr-2.4, there is no get_config_stack there
[17:39] <jelmer> vila: there is on SvnBranch :-)
[17:40] <vila> ooooh, that
[17:40] <vila> hmm
[17:40] <vila> that's a tricky question :)
[17:41]  * vila looks at bzr diff -rbzr-2.4.2.. bzrlib/config.py
[17:43] <vila> jelmer: registering options looks suspicious
[17:43] <vila> no cmdline overrides
[17:43] <jelmer> vila: that's actually something that seems to work
[17:43] <vila> k
[17:44] <jelmer> vila: did cmdline overrides work at all in 2.4?
[17:44] <vila> it didn't exist
[17:44] <vila> just listing
[17:44] <vila> ha, remote (smart) branches broken, no impact or bzr-svn ?
[17:45] <jelmer> vila: nope - remote branches can't access svn stuff anyway, not even in bzr.dev
[17:46] <vila> jelmer: and no expansion either, so overall I saw nothing likely to fail, the basic pieces were in place and if some internals have changed, they should already work in 2.4
[17:46] <jelmer> vila: cool
[17:47] <vila> and given the current read/write scheme using both implementations should be ok
[17:47] <vila> once this model change (so bzr.dev only) it will become dangerous to access one option with both implementations
[17:48] <vila> but even there, that will require modifying the value, so unlikely to be encountered soon (except for GUIs may be)
[18:00] <mgz> okay, have a test
[18:00] <mgz> don't really understand all this monkeying but hey
[18:07] <mgz> vila: do you have a sec to look at a diff and tell me ways to make it saner?
[18:07] <vila> mgz: shoot
[18:10] <mgz> vila: http://pastebin.ubuntu.com/761875/
[18:12] <vila> the 'remove/add/rename_one' dance you mean ?
[18:13] <mgz> yeah, and any of the other branch creaty bits.
[18:13] <vila> well, the branch creation bits are not that bad (unless you can create a richer branch in make_branch_and_tree)
[18:13] <mgz> I guess remove/os.rename/add would work
[18:14] <vila> yup, was about to ask/suggest about using os. everywhere in tree nowhere
[18:14] <vila> as I understand it, error.zip was obtained after shell commands, with no bzr commands involved
[18:15] <vila> so qbzr may be confused because some files referenced in the dirstate are not there anymore and some other have totally different content
[18:15] <mgz> yeah, but I can't get into that state, though I can do this similar one.
[18:17] <vila> oh, misread, make_branch_and_tree is the basic bzr one
[18:18] <vila> so po_merger tests use branch_builder and scripts which can be more readable, but your tree setup being 10 lines long... that would be overkill
[18:22] <vila> you can also add assertLength(1, tree.conflicts()) to complement self.assertPathExists("parent/f.moved")
[18:23] <vila> EOD'ing
[18:28] <mgz> thanks vila.
[18:31] <vila> mgz: rhaa, my comments were confusing. One thing you should think about is that the bug may be caused by some difference between the dirstate content and what qbzr thinks about the wt. As it's written, your test may not reflect that as it uses an in-memory tree which *may* not trigger the same behavior
[18:32] <vila> test scripts running complete commands are less likely to suffer from that which is why I mentioned them as opposed to the bzr-upload ones
[18:32] <vila> there, that's should be clearer ;)
[18:35] <vila> hmm, almost, by in-memory, I mean a wt with its internal state as opposed to loaded from the dirstate
[18:50] <lamal666> lifeless, is pyjunitxml already integrated in testtools somehow?
[18:55] <jelmer> lamalex: it's a separate package
[18:56] <lamalex> i know, but im wondering if there's a simple integration path that i haven't figured out
[19:02] <lifeless> lamalex: in what sense integrated?
[19:03] <lifeless> if you mean 'report tests using it',most folk I know have been setting that up in their local test glue, or if they have non via subunit
[19:04] <lifeless> there is a merge proposal just waiting copyright signoff to add a junitxml.main as a convenience for folk too
[19:04] <lamalex> ah, i guess we dont really have any test glue we've just been doing python -m testtools.run discover
[19:04] <lamalex> which is probably why im having a hard time figuring out how to fit the two together :P
[19:04] <lifeless> right now the easiest thing will be
[19:05] <lifeless> python -m subunit.run discover | subunit2junitxml -o tests.xml
[19:05] <lifeless> (I think, thats from memory - use -h and season to taste)
[19:05] <lamalex> yah
[19:05] <lamalex> ok, thanks lifeless
[19:05] <lamalex> i honestly would have never figured that out
[19:07] <lifeless> heh
[19:32] <lamalex> lifeless, does testtools output subunit by default/
[19:32] <lifeless> no, subunit.run does (which is testtools compatible)
[19:35] <lamalex> ahh
[19:36] <lamalex> woop dere it is
[21:23] <poolie> hi all
[21:43] <wgz> hey poolie
[21:43] <poolie> hi there wgz, how's it going?
[21:46] <wgz> good, a little bit of an interesting launchpad day. how was your weekend?
[21:55] <poolie> really nice


[02:07] <wrst> Unit193: it feels a bit too polished without all the print out
[02:07] <wrst> people know I mean business when I boot up :)
[02:08] <Unit193> Fair enough.
[02:09] <Unit193> I just think Debian's looks so shiny, I wonder if I can set that in Ubuntu. :>
[02:12] <wrst> been so long since i have ran debian as a desktop I don't even know what it looks like
[04:42] <cyberanger> same here (when it comes to plymouth at least)
[04:45] <Unit193> Full text output reminds me of knoppix.
[05:01] <cyberanger> Unit193: is that bad? (My first distro)
[05:02] <Unit193> Nope.


[00:56] <kirkland> is there a public "view" of my app uploaded to the snappy store?
[00:57] <kirkland> I can see https://myapps.developer.ubuntu.com/dev/click-apps/3123/ but that looks to be private to me
[06:14] <mvo> ogra_: good morning! there is https://code.launchpad.net/~mvo/snappy-hub/bbb-env/+merge/264975 right now but thats incomplete, right? would be awsome if you could point me to the steps that are missing. is it just adding "snappy-system.txt" to mkenvimage?
[07:04] <fgimenez> good morning
[07:43] <ogra_> mvo, the input file shouldnt be called uEnv.txt, we want that file empty in the /boot dir ... (or alternatively fix snappy to not look for it but to check for uboot.env instead)
[07:43] <ogra_> i'll prepare an MP with the file content
[08:04] <dholbach> good morning
[08:55] <JamesTait> Good morning all; happy Viking 1 Landing Day! 😃
[09:05] <longsleep> ogra_: I was thinking about the saveenv a bit more and was wondering why you guys do not see fat corruption that way. Any idea?
[09:06] <ogra_> longsleep, different layer i guess
[09:06] <ogra_> the assigned size of the file on the fs is fixed, only the content inside changes, i guess that makes it behave different
[09:21] <ogra_> mvo, https://code.launchpad.net/~ogra/snappy-hub/bbb-new-binaries-and-env/+merge/265375
[09:25] <mvo> ogra_: hm, thats long :) none of this is in the default env that uboot already generates? thats a bit disappointing of uboot :/
[09:26] <ogra_> mvo, thjats in the default env that is hardcoded into the uboot binar
[09:26] <ogra_> y
[09:26] <ogra_> which gets emptied automatically if uboot.env gets loaded
[09:27] <mvo> ogra_: aha, that was my question, if it merges or overrides
[09:27] <ogra_> to keep it we need to carry over the whole of it
[09:27] <mvo> yeah, makes sense
[09:27] <mvo> would be great if we could document this for porters later how to ge tthe defaults that needs to be added
[09:27] <ogra_> thats my plan once we are finished
[09:27] <mvo> yay
[09:28] <mvo> :)
[09:28] <ogra_> i added the MP as item to the trello card
[09:28] <longsleep> ogra_: ah yes that makes sense - the file size always stays the same
[09:28] <ogra_> (and commented on https://code.launchpad.net/~mvo/snappy-hub/bbb-env/+merge/264975)
[09:28] <mvo> so does that mean with that uboot.env a fresh system with your latest uboot will fully work with the uboot.env (and with my snappy branch)?
[09:29] <mvo> ogra_: yeah, my branch is obsolete now
[09:29] <ogra_> mvo, thats what i tested here
[09:29] <mvo> ogra_: \o/
[09:29] <ogra_> mvo, no, it isnt
[09:29] <ogra_> i left out the bits your branch has
[09:29] <ogra_> the README needs updating though :)
[09:29] <mvo> ogra_: you tested and it all worked? thats fantastic news
[09:29] <mvo> ogra_: haha, ok
[09:29] <mvo> ogra_: I merge your stuff then :)
[09:29] <ogra_> mvo, last friday, yes
[09:30] <ogra_> with my own snap though (based off the beagleblack snap from the store) ... we'll still need an end to end test with a snap built fr4om the branch
[09:32] <mvo> ok
[09:32] <ogra_> (and with your chanes in place indeed)
[09:32] <mvo> ogra_: did you managed to test if the fs corruption is fixed too?
[09:32] <ogra_> (without me cp'ing the snappy binary in place ;))
[09:33] <ogra_> i didnt have any corruption, but i would still like to see it in a real end to end test first
[09:35] <ogra_> (i switched back and forth twice when i tested, the prob is indeed that i manually hack the env to trigger that)
[09:36] <longsleep> thats what i also wanted to ask, how can i build an image which does change the stuff in uboot.env? Is there something in edge channel already?
[09:36] <ogra_> well, technically we dont support rollback on non beagle boards currently
[09:37] <ogra_> though i bet in 15.04 it might still work somehow
[09:45] <longsleep> ogra_: rollback works fine for the odroidc with my image
[09:45] <ogra_> hah, good  :)
[09:45] <longsleep> and i would like to keep it that way with the upcoming changes :)
[09:46] <ogra_> well, snappy will refuse to update at some point ...
[09:46] <ogra_> in rolling ...
[09:46] <longsleep> i can easily trigger it from uboot shell now, the only thing missing is the stuff modifying the uboot.evn after successfull boot
[09:46] <longsleep> why would it refuse to update?
[09:47] <ogra_> because only fully supported boards are supposed to get updates
[09:47] <ogra_> (there were a few discussions on the ML about this ... in the RPi threads )
[09:48] <longsleep> how is it detected? I have the auto updater currently enabled and it worked fine when version 3 was released
[09:48] <ogra_> (that doesnt stop you from doing any uboot shell hackery, but the automatism wil likely refuse to work at some point)
[09:49] <ogra_> yes, as i said, in 15.04 that still works
[09:49] <longsleep> well - thats why i am here to fix things and make it working
[09:50] <ogra_> i assume what is supported will be considered by the store ... technically only the bits from plain mainline are under active support currently ... which limits us to the BBB on arm
[09:52] <Chipaca> rsalveti: ping about the difference between "snappy service status" and "snappy service list"
[09:52] <longsleep> yes that is fine with me - i can even run my own system-image server if required. I want to provide a stable upgrade path to anyone trying my images.
[09:53] <ogra_> well, system-image will go away
[09:53] <ogra_> everything will become a snap
[09:54] <longsleep> right - i might to want to run my own source for snaps then. I already have the odroid oem snap in the store. If that is the way thats fine too.
[09:58] <chihchun> is rootfs of snappy ubuntu core built with this seed ? https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-core.wily ?
[09:59] <chihchun> bafu: hi
[10:01] <bafu> chihchun, hi
[10:02] <ogra_> chihchun, from the system-imae file in there
[10:02] <ogra_> *image
[10:03] <chihchun> ogra_: thanks
[10:11] <chihchun> ogra_: for the device tarball, I assume it's built by CI system. But I could not find the source code or build script ?
[10:11] <ogra_> no, it is built by cdimage during the rootfs build
[10:12] <ogra_> which is done by live-build ... the configs and scripts used by live-build live in the livecd-rootfs package
[10:12] <chihchun> ogra_: got it, thanks
[10:13] <chihchun> did not aware the config of live-build also included
[10:14] <ogra_> well, we abuse the chroot from it after the rootfs has been produced to actually roll the device tarball
[10:14] <ogra_> so you have all in one central place
[10:41] <ogra_> mvo, hmm ...
[10:42] <ogra_> mvo, i wonder how/where we can ship mkenvimage in the snappy-hub tree
[10:44] <mvo> ogra_: hm, hm, its part of u-boot-tools, could we just depend on that?
[10:44] <ogra_> the uboot-tools one might be older or use different defaults
[10:45] <ogra_> since we require the uboot binary to be built by hand anyway we should use the mkenvimage from the same build imho
[10:46] <ogra_> i have a proper binary here, i just dont know where to put it
[11:20] <ogra_> mvo, http://people.canonical.com/~ogra/snappy/bootloader/ has a snap created from the tree now
[11:20] <ogra_> (boots fine here )
[11:59] <ogra_> "Firefox prevented the execution of Adobe Flash for github.com, do you want to keep it blocked" ....
[11:59] <ogra_> WTF
[11:59] <ogra_> where does github use flash !
[12:02] <tbr> IIRC in the repository url widget and somewhere else
[12:05] <ogra_> gross
[12:06] <mvo> ogra_: nice, let try it too
[12:06] <kyrofa> seb128, quick status update: the snappy scope is in the NEW queue awaiting review
[12:07] <seb128> kyrofa, hey, great, let me have a look
[12:07] <ogra_> kyrofa, was that a subtle way of asking seb128 to review it ?
[12:07] <ogra_> :)
[12:07] <longsleep> Flash is used in all kind of places as it is the only way to put something into clipboard with javascript.
[12:07] <kyrofa> ogra_, maaaaaaaybe
[12:07] <ogra_> :D
[12:07] <ogra_> longsleep, well, github was one of the pages where i wouldnt have expected it
[12:07] <tbr> ogra_: just as I remembered, it's some sort of clipboard bridge flash abomination, probably due to the native browser restrictions on pushing things to clipboard
[12:08] <ogra_> yeah
[12:08] <longsleep> ogra_: they have the copy to clipboard button for clone urls
[12:08] <ogra_> because selecting an url and hitting ctrl-c is so hard :P
[12:09] <ogra_> but yeah, understood :)
[12:09]  * tbr uses a different paste buffer anyway, so selects the url manually in the field and then middle-click pastes
[12:09] <ogra_> same here
[12:10] <ogra_> but even here ctrl-c works :)
[12:10] <ogra_> and i kind of would expect people that use git to know how to copy/paste something
[12:10] <ogra_> (or is that knowledge limited to us bzr users ? (muhahaha))
[12:37] <ogra_> mvo, did it work for you ?
[12:38] <mvo> ogra_: haven't checked yet, the BBB is busy with some squashfs releated work
[12:38] <ogra_> ah
[12:38] <ogra_> well, i think we should soon start to produce an image to start testing
[12:39] <longsleep> i would be interested in that as well :)
[12:39] <mvo> ogra_: good point, I will try to hurry here (hurry and BBB is a bit of a contradiction though)
[12:39] <ogra_> haha, yeah
[12:40] <ogra_> we should have picked the parallella board as default :)
[12:41] <kyrofa> ogra_, ahh, the parallella
[12:41] <ogra_> shiny little fast thing :)
[12:41] <ogra_> (the odroid is nearly as fast though)
[12:42] <longsleep> you can test my snap :P https://www.stdin.xyz/downloads/people/longsleep/tmp/odroidc-bootloader/
[12:42] <ogra_> i have a bit of an SD card shortage atm ... but will try it at one point
[12:44] <longsleep> so - now that i have a snap the only thing i need now is a ubuntu-device-flash which builds an image using uboot.env :)
[12:44] <kyrofa> ogra_, speaking of SD cards, how hard is it to get u-boot to boot to a USB HD instead of the SD?
[12:44] <ogra_> kyrofa, that depends completely on the ROM
[12:44] <ogra_> some boards can do that ... but it is realyl rare
[12:45] <ogra_> (the pandaboard was capable of booting via USB if you gave it a uboot binary via netboot or usb cable iirc)
[12:45] <longsleep> odroidc u-boot does not support booting from USB
[12:46] <kyrofa> ogra_, that's too bad. My main personal web server is a mirabox (one of those plug computers), and that thing toasts through an SD card a year or so
[12:47] <ogra_> well, if you have an MMC inside where you could put the /boot partition on to carry bootloader, kernel and initrd, booting off USB key is possible
[12:47] <ogra_> but you need these bits in place on SD or MMC
[12:48] <kyrofa> ogra_, hmm, interesting. And that stuff could be read-only, yeah? I may ask your advice on that later :)
[12:48] <ogra_> well, if you use snappy it cant be read only because snappy needs to be able to modify the bootloader config
[12:49] <ogra_> but if you stick to one image and dont upgrade you could keep it readonly indeed
[12:49] <ogra_> the good thing is that we mount everything by label ... so you can just use a normal snappy img and dd it to your usb key and it will work
[12:51] <ogra_> (you could do that only with the writable partition btw, since that is the only one that actually counts on snappy ... i.e. remove the label from the writable lartition on the SD, format the USB key and copy the former writable partition contents over ... then add a label to the usb key and it should work)
[12:51]  * ogra_ is plannning to do that for a owncloud install here ...
[12:52] <kyrofa> ogra_, heh, that's currently one of the usages for my current server
[12:52] <kyrofa> ogra_, good ideas, thank you :)
[12:53] <mterry> sergiusens, could you install python3-fixtures to the snapcraft tarmac instance?
[12:57] <rsalveti> fgimenez: replying back your question from yesterday, just report to snappy itself (about the writable-paths)
[12:59] <kyrofa> sergiusens, we talked briefly last week about making webdm available in the Ubuntu Personal channel. Is that still something you plan on doing?
[12:59] <fgimenez> rsalveti, ok thx, will do
[13:07] <longsleep> btw, anyone has written a tool to enlarge the writeable partition to fill the whole storage device?
[13:08] <longsleep> i mean i can easily use a script for my particular device but i would like to see a generic solution for this in snappy.
[13:13] <ogra_> longsleep, we have scripts for the initrd to do that ... just not ported over to snappy
[13:13] <longsleep> ogra_: is this planned? I know cloud-init can do it - do you mean these scripts?
[13:14] <ogra_> no, initrd scripts that do it before the first mount
[13:14] <longsleep> ok - that was what i have to do myself unless snappy gets it by default :)
[13:15] <longsleep> i mean i have plenty of stuff to be done on first boot
[13:15] <longsleep> like waiting for entropy, generate keys, dhparams etc ..
[13:16] <ogra_> not from the initrd i hope :)
[13:17] <longsleep> yeah - from the initrd it should only be the resize
[13:17] <longsleep> though i do consider waiting for entropy in initrd as well
[13:37]  * rsalveti finally get to read backlog
[13:43] <rsalveti> Chipaca: better to ask mvo, he is the one that added the entries to the checklist
[13:44] <Chipaca> fair :)
[13:45] <rsalveti> longsleep: https://trello.com/c/EdWkd2UW/181-use-cloud-init-to-extend-resize-the-writable-partition-during-first-boot
[13:45] <rsalveti> longsleep: that's in the list, patches are welcome if you want to give it a try
[13:46] <longsleep> rsalveti: my problem is that i do not like cloud-init very much :)
[13:46] <rsalveti> hard to find one that really likes it :-)
[13:46]  * ogra_ is with longsleep :)
[13:46] <longsleep> hehe
[13:46] <longsleep> well - i have some gear to do it without cloud init for non snappy ubuntu
[13:47] <rsalveti> we don't yet know if it's better to do in the initrd or cloud-init
[13:47] <rsalveti> the good with thing with cloud-init is that we don't need to add extra logic in the initrd itself
[13:47] <rsalveti> but that's the main difference
[13:48] <ogra_> but get multi hour boot times :P
[13:48] <ogra_> and python on the image
[13:48] <rsalveti> well, cloud-init is already there
[13:48] <longsleep> cloud init is so bloated - i would like it to go away :)
[13:48] <rsalveti> the new cloud-init should probably be in go
[13:48] <rsalveti> but further down the line
[13:49] <longsleep> yeah - i can see that. Though cloud-init is the only thing which stopped me to implement something so far
[13:50] <longsleep> and for me, that is just one problem. I need means to run (and optionally block) for other things on boot as well
[13:50] <longsleep> first boot - i mean
[13:51] <rsalveti> yeah, it's not ideal
[13:51] <longsleep> in non snappy i just have a upstart service with run-parts a directory and writing a marker when complete. That way i can easily spawn multiple stuff, wait on it and make sure it is only done once.
[13:52] <longsleep> for example on the ODROIDC generating 2048 bit dhparams takes over 10 minutes
[13:53] <longsleep> and the question is what services are allowed to start until that is complete
[13:53] <longsleep> assuming a default params file is shipped or something
[13:53] <longsleep> another thing is the system time
[13:53] <longsleep> when generating certificates on first boot, it is bad if the time is 1970 :)
[13:54] <ogra_> longsleep, that means you have not enabled fixrtc on the cmdline then
[13:54] <longsleep> i have - but i have no clue what it does
[13:54] <longsleep> if it does not happen with snappy thats fine
[13:54] <longsleep> just an example from other devices
[13:55] <ogra_> well, seems it doesnt work then ... it forces the clock to the last mount time or the creation time of your partition
[13:55] <ogra_> (whatever is newer)
[13:55] <longsleep> that is reasonable
[13:55] <ogra_> so while the clock will still be off, the diff wont be that massive
[13:55] <longsleep> yeah that should be fine.
[13:55] <mvo> Chipaca: what was the question again? sorry can't see it in the backlog
[13:56] <Chipaca> mvo: there wasn't a question in the backlog; just a note to ask a quesiton
[13:56] <mvo> heh, ok
[13:56] <Chipaca> mvo: what's the difference between "snappy service list" and "snappy service status"?
[13:57] <mvo> Chipaca: I was thinking that list would simply list the available ones and status gives details for a specific one, but that was shooting from the hip, so feel free to override/refine/improve :)
[13:57] <Chipaca> mvo: ok, i'll implement status and then we see if we need list
[13:58] <mvo> sounds good
[14:14] <longsleep> rsalveti, ogra_ : Well i just tried the stuff cloud-init is doing - seems all the gear is there (growpart, resize2fs).
[14:14] <ogra_> sure
[14:15] <rsalveti> longsleep: yeah, might be a config change only
[14:16] <longsleep> the config says something about sfdisk missing which is true but it does not seem to be required. I just ran growpart and then resize2fs. Growpart showed some warning about sfdisk but did the trick just fine. Did not even have to reboot.
[14:17] <longsleep> so this could be a 3 liner script instead of cloud-init. Find disk device and partition number for writable label. Run gropwart on that partition, on success run resize2fs
[14:20] <rsalveti> yup
[14:20] <longsleep> rsalveti: In your trello extend/resize task there is a reference to "recovery" what is this "recovery" ?
[14:21] <rsalveti> longsleep: we had an idea to investigate on having a recovery (similar to what we have for phones), but for snappy
[14:22] <longsleep> rsalveti: oh all right - but that does not exist yet?
[14:22] <rsalveti> the recovery could help restoring the image to factory, help sideloading apps and doing extra logic
[14:22] <rsalveti> longsleep: nops, just an idea atm
[14:22] <longsleep> ok
[14:33] <dholbach> mvo, mterry: thanks a bunch!
[14:37] <elopio> zyga: have you tried to measure the code covered by plainbox?
[14:39] <zyga> elopio: hey
[14:39] <zyga> elopio: code coverage of plainbox itself?
[14:39] <zyga> elopio: yes
[14:40] <zyga> elopio: cli parts are poorly covered, most of the core is covered well
[14:40] <zyga> elopio: though a few of the new features may have lowered the scoer a little
[14:40] <zyga> elopio: there's a script in trunk to run all tests with coverage
[14:40] <tedg> mvo, So I think I might be caught up in the conflict between the copy plugin and trunk. Are you merging that?
[14:41] <elopio> zyga: not plainbox itself. The code that the plainbox tests are covering.
[14:41] <elopio> like in snapcraft, call plainbox from python3-coverage or something like that.
[14:41] <mvo> tedg: I can fix merge conflicts, sure, one sec
[14:41] <tedg> Great, thank you!
[14:41] <zyga> elopio: ah
[14:42] <zyga> elopio: no, that's hard to do in general
[14:42] <zyga> elopio: though, if we specialize
[14:42] <zyga> elopio: then it's quite possible
[14:42] <zyga> elopio: I wrote a bit of an interesting proof of concept a while ago
[14:42] <zyga> elopio: you can run a test with that, it will show you what was executed per test case
[14:42] <zyga> elopio: it was specialized to python obviously
[14:43] <zyga> elopio: (our code tends to be split between python, shell and C so we did not pursue that but for python-specific projects we could)
[14:43] <zyga> elopio: if you have ideas how you'd like to make it better to run unit tests via plainbox I'm all ears
[14:43] <elopio> zyga: we only need python here. Do you have a link?
[14:43] <zyga> elopio: I'll be adding benchmark support next week
[14:43] <zyga> elopio: it wasn't specific for plainbox but sure, let me find it
[14:45] <zyga> elopio: though the benchmarks I'm after are like "this test compiles the linux 3.14 kernel"
[14:45] <zyga> elopio: :-)
[14:46]  * zyga looks at his +junk branches
[14:46] <zyga> it's somewhere there :D
[14:47] <elopio> zyga: for snapcraft seems to be a good fit. I'd like nicer regex matching, but we can add that.
[14:47] <zyga> elopio: one thing that's possible (not sure if useful yet)
[14:47] <zyga> elopio: is write a local job that looks at your python code to see what tests exist (just to discover them)
[14:48] <zyga> elopio: and then let you run each single test directly via plainbox (each test would become a new job)
[14:48] <zyga> elopio: local jobs are like test generators, they can run any code and can print additional test definitions)
[14:57]  * zyga goes through his old code...
[14:57] <kyrofa> tedg, the click scope launches click apps and scopes via UAL, right?
[14:59] <tedg> kyrofa, Basically, it sends URLs to the dash when sends them to URL dispatcher which uses UAL.
[14:59] <zyga> found it :)
[14:59] <kyrofa> tedg, alright. Do you envision the same happening for snaps?
[14:59] <zyga> whee
[14:59] <tedg> kyrofa, Yeah, I do.
[14:59] <tedg> kyrofa, Should just be appid:// URLs
[15:00] <kyrofa> tedg, should something like that work currently?
[15:00] <tedg> kyrofa, No, there's no way to define an application in a snap today.
[15:00] <mvo> ogra_: http://paste.ubuntu.com/11914911/ <- this looks good, right?
[15:00] <ogra_> mvo, "reading uboot.env"
[15:00] <tedg> kyrofa, Only binaries and services, it needs to grow a bit of functionality before applications can exist.
[15:00] <ogra_> mvo, so it does :)
[15:02] <kyrofa> tedg, alright, interesting. What needs to grow beyond having a binary and some sort of .desktop (or yaml, whatever) file with install hooks?
[15:03] <mvo> ogra_: yay!
[15:03] <tedg> kyrofa, Well, it is more fundamental than that. There's no such thing as a way to provide install hooks or anything like that.
[15:03] <tedg> kyrofa, So once a system is defined for that, it can be used to provide application information.
[15:03] <tedg> kyrofa, Then we'll have appids.
[15:04] <zyga> elopio: one sec, just adding boilderplate and fixing this to work on python3
[15:04] <zyga> elopio: (it's pretty old)
[15:04] <kyrofa> tedg, okay, I gotcha
[15:05] <mvo> Chipaca: will you be able to do a bit of code review for the new uboot env snappy code today?
[15:06] <kyrofa> tedg, do you have any idea of a timeline for those features?
[15:06] <Chipaca> mvo: sure
[15:08] <mvo> Chipaca: https://code.launchpad.net/~mvo/snappy/snappy-snappy-bootsuccess-env2/+merge/265259 and the new uboot-go env code (which is relatively small). happy to talk about deails
[15:10] <tedg> kyrofa, I don't know of anyone working on it currently.
[15:10] <tedg> kyrofa, I proposed a spec, but it hasn't passed through the system yet.
[15:10] <tedg> kyrofa, It also needs more work if the basics do get approved there.
[15:11] <kyrofa> tedg, alright. Just curious from an Ubuntu Personal perspective
[15:11] <mvo> tedg: hm, I don't see a conflict in snapcraft between copy-plugin and trunk(?)
[15:11] <kyrofa> tedg, in the same vein, will UAL handle legacy app launches?
[15:12] <tedg> mvo, I've got the copy tests failing, could have been my merge, but I saw this comment from mterry: https://code.launchpad.net/~mvo/snapcraft/copy-plugin/+merge/264706/comments/665846
[15:12] <tedg> kyrofa, I understand, not sure what you mean by "legacy" in this context.
[15:12] <kyrofa> tedg, libertine
[15:12] <tedg> kyrofa, libertine or /usr/share
[15:13] <tedg> kyrofa, Yes, there's a branch for that, needs review.
[15:13] <zyga> elopio: almost done
[15:13] <elopio> zyga: no hurries.
[15:13] <kyrofa> tedg, awesome! Okay, thanks for the update :)
[15:14] <Chipaca> mvo: i think you need to update depedencies.tsv
[15:15] <mterry> tedg, the tests in the copy-plugin branch failing you mean?
[15:20] <zyga> elopio: python3 support for the example and I'm done
[15:23] <tedg> mterry, Yeah
[15:23] <mvo_> Chipaca: feedback on uboot-go would also be great, it has no review yet and api review etc
[15:23] <Chipaca> sure
[15:23] <mvo_> \o/
[15:37] <kyrofa> tedg, the spec you proposed, is it the extension points document?
[15:38] <tedg> kyrofa, Yes
[15:39] <Chipaca> mvo_: how do i review the one in github?
[15:39]  * Chipaca has a low github score
[15:39] <tedg> kyrofa, Idea being that person could provide extension points for applications (devs don't need them as much) and then apps could connect into those points.
[15:39] <mvo_> Chipaca: just clone and yell at me via mail or irc
[15:40] <mvo_> Chipaca: or file issues, but I think thats more overhead
[15:40]  * Chipaca engages yelling mode
[15:41] <Chipaca> mvo_: so, silly things first
[15:41] <Chipaca> mvo_: https://github.com/mvo5/uboot-go/blob/master/uenv/uboot.go~
[15:41]  * mvo_ drops dead
[15:41] <mvo_> thanks Chipaca
[15:42] <Chipaca> mvo_: next, in https://github.com/mvo5/uboot-go/blob/master/uenv/env.go
[15:43] <Chipaca> mvo_: you don't check the writes
[15:43] <Chipaca> mvo_: what's the reasoning there?
[15:43] <Chipaca> mvo_: not so worried about the writes to the bytes buffer, but the writes to the actual file probably need checking
[15:43] <mvo_> Chipaca: absolutely
[15:44] <Chipaca> mvo_: that's in Save fwiw
[15:44] <ogra_> pfft, that sounds like we even test code ... "checking" hah
[15:44] <Chipaca> mvo_: and you don't Sync the file
[15:44] <mvo_> Chipaca: yes!
[15:44] <ogra_> Chipaca, we mount with sync option
[15:45] <ogra_> (while more elegant it shouldnt be needed to do any extra sync call)
[15:45] <mvo_> I will still add the f.Sync()
[15:45] <Chipaca> ogra_: great! that means the Sync will be instant
[15:45] <Chipaca> :)
[15:45] <ogra_> yeah
[15:45] <mvo_> Chipaca: thats great great feedback, keep it coming
[15:45] <Chipaca> mvo_: you also don't do the atomic rename dance
[15:45] <ogra_> technically not needed ... for code sexiness it is though :)
[15:45] <Chipaca> mvo_: not sure if that's important in this case
[15:46] <Chipaca> ogra_: ideally we could stop using sync, and reap perf gainz :-p
[15:46] <Chipaca> anyway
[15:46] <ogra_> on /boot ?
[15:46] <ogra_> :)
[15:46] <Chipaca> mvo_: in Import, why don't you return scanner.Err() instead of only returning it if it's not nil, and returning nil otherwise?
[15:46] <zyga> elopio: ok, done https://git.launchpad.net/testtrace/tree/demo.py
[15:46] <Chipaca> ogra_: maybe in arm we don't copy kernels and initrds around between a/ and b/ ?
[15:46] <Chipaca> ogra_: i thought we did
[15:47] <Chipaca> ogra_: and sync makes that slow
[15:47] <zyga> elopio: not much but I did clean it up a little
[15:47] <ogra_> Chipaca, ah
[15:47] <ogra_> i didnt think of that
[15:47] <mvo_> Chipaca: yes!
[15:48] <Chipaca> mvo_: and starting to get really nit-picky with this file: in “Set sets an environment name to the given value”
[15:48] <Chipaca> mvo_: you could write “Set an environment name to the given value”
[15:49] <Chipaca> mvo_: ditto “Get returns the value of the environment variable” -> “Get the value of the environment variable”
[15:49] <mvo_> Chipaca: I guess its a good sign that we are at this level already
[15:49] <mvo_> :P
[15:49] <zyga> elopio: have a look and tell me if it's of any use to you
[15:49] <Chipaca> either that, or my head works via BFS
[15:49] <mvo_> heh
[15:49]  * mvo_ starts fixing
[15:50] <elopio> zyga: looking. Also looking at the python3-coverage approach, that doesn't require a TestCase.
[15:50] <zyga> elopio: they are based on the same logic
[15:50] <zyga> elopio: I mean, the same low-level feature
[15:50] <zyga> elopio: this is tied to a test case so that one can easily get data that is per-test-case
[15:51] <zyga> elopio: though this is just an old proof-of-concept, dusted and packaged
[15:51] <elopio> zyga: it's useful, thanks.
[15:52] <elopio> what's not clear for me is why python3-coverage needs to run a python file. Seems the same to me who starts the run. But I'll dig more, slowly through the week.
[15:53] <zyga> elopio: because it sets up that low level trace call this way
[15:57] <Chipaca> mvo_: that's all i have for now :)
[16:00] <mvo_> Chipaca: I pushed a updated version, let me know if there is anything I overlooked or if my comment on e.g. write-rename make sense
[16:01] <Chipaca> mvo_: there is one thing in run-checks, but we have the same issue
[16:01] <Chipaca> mvo_: we should probably quote the lint output
[16:01] <elopio> wow, this works.
[16:02] <mvo_> Chipaca: indeed, let me fix that
[16:02] <elopio> mterry: zyga: if we replace all the calls to snapcraft to something like "python3-coverage run --append --source snapcraft bin/snapcraft", we would be able to collect the coverage.
[16:03] <elopio> easiest solution that comes to mind.
[16:03] <mvo_> nice!
[16:03] <Chipaca> mvo_: difference being http://pastebin.ubuntu.com/11915213/
[16:04] <mvo_> Chipaca: fixed, I may cowboy it into lp:snappy
[16:04] <Chipaca> mvo_: haven't looked at the gofmt output, but it might need the same kindness
[16:06] <mvo_> Chipaca: indeed so, updated that too now
[16:07] <mvo_> Chipaca: I can prepare a branch for snappy now too, unless you want to do that (don't want to steal your credits :)
[16:08] <Chipaca> mvo_: s/rational/rationale/; s/FAt/FAT/; s/we not truncate/$english/; and \o/
[16:09]  * ogra_ prefers FAT free ...
[16:09] <mvo_> Chipaca: pfff, whats wrong with "we not truncate" :P
[16:09] <mvo_> Chipaca: fixing !
[16:10] <Chipaca> mvo_: i no idea
[16:10] <Chipaca> mvo_: but it wrong
[16:10] <Chipaca> mvo_: as if something missing
[16:10] <mvo_> Chipaca: :-D pushed another fix
[16:11]  * mvo_ hugs Chipaca for his patience
[16:11] <FergusL> anyone tried Snappy on OrangePi boards ?
[16:11] <ogra_> FergusL, a few people i would think
[16:11] <ogra_> (or is OrangePi different from OrangeBox) ?
[16:12] <Chipaca> mvo_: wrt snappy branch, i don't mind either way :)
[16:12] <mvo_> Chipaca: then you do it and I get dinner ;)
[16:12] <Chipaca> ogra_: http://www.orangepi.org/
[16:12] <ogra_> oh
[16:12] <mvo_> Chipaca: and I will come back later and fix all the issues in the -env2 branch and prepare the backport after that - deal?
[16:12] <ogra_> WOW !
[16:13] <ogra_> sata and GigE
[16:13] <ogra_> FergusL, then i was wrong ... :) i mixed it up
[16:13] <longsleep> yeah, but crappy allwinner cpu
[16:14] <ogra_> well, you cant have everything
[16:14] <Chipaca> and it has an upgrade key!
[16:14] <Chipaca> mvo_: deal
[16:17] <fgimenez> nice evening everyone o/
[16:20] <FergusL> I have OrangePi 2 with H3 (quad 1.6GHz A7)
[16:23] <Chipaca> mvo_: only thing I see in -env2 is that we don't have a packaged golang-uboot-yadda
[16:25] <mvo_> Chipaca: indeed, please add this as a review comment (if you haven't already). I will either package or just pull it into snappy, but it feels like its really a standalone thing
[16:25]  * Chipaca nods
[16:42] <Chipaca> mterry: any reason not to approve the copy plugin?
[16:43] <Chipaca> ah, the last changes after your comments are fairly new
[16:50] <longsleep> Anyone who is interested in a simple generic Snappy writable resize to max script - grab it here: https://github.com/longsleep/snappy-odroidc/blob/master/scripts/resize-snappy-writable.sh
[17:07] <mterry> Chipaca, also all my previous review comments haven't been addressed yet
[17:08] <mterry> Chipaca, that is one thing I don't like about inline comments.  They get "lost" when someone does any update at all
[18:08] <tedg> mterry, Do I have the wrong version of something? manage.py: error: unrecognized arguments: -d /tmp/tmp.5BfenzNjeb
[18:08] <mterry> tedg, README.md should have the right PPA to install to get the correct plainbox version
[18:08] <mterry> tedg, also, not on wily?!  :)
[18:09] <tedg> mterry, Ha, yeah. Can't wait for libertine container to work :-)
[18:10] <mterry> tedg, libertine?
[18:10] <tedg> mterry, The system that's being developed to run a "standard Ubuntu" on a read only filesystem.
[18:10] <tedg> mterry, Runs as a container, but then exports the apps to the launcher, etc.
[18:10] <mterry> ah interesting
[18:11] <kyrofa> rsalveti, we're investigating i18n in the snappy scope. Do you know if webdm supports that at all?
[18:11] <tedg> The nice part is that you can have real apps on multiple containers then. So it'll be easier to keep a wily version of things around.
[18:38] <mterry> mvo_, can snap binary exec: lines be multi-word like service start/stop lines can be?  I'm guessing so
[18:39] <mvo_> mterry: yes, that should work
[18:39] <mterry> mvo_, cool
[18:54] <kyrofa> Hey bregma, did you ever try running Ubuntu Personal on the rpi2?
[18:55] <bregma> kyrofa, Ubuntu Personal no, because there is missing support for Mir (or Mir is missing support)
[18:55] <bregma> or both
[18:55] <kyrofa> bregma, heh, okay gotcha
[18:57] <kyrofa> ogra_, were you ever able to get i2c + devicetree working on the rpi image?
[18:58] <ogra_> kyrofa, not yet, thats in the works for the next (delayed) stable image
[18:59] <ogra_> working on fixing the image itself before going back to the rpi
[19:00] <kyrofa> ogra_, alright, sounds good
[19:00] <ogra_> i'll send a mail announcement once the image is ready
[19:00] <ogra_> we're just re-working a critical part for the default image that takes my attention atm
[19:53] <tedg> mterry, So I think that focused assemble is confusing the copy plugin and breaking it's test.
[19:54] <tedg> its'
[19:54] <tedg> mterry, Do you have a second to take a look at that?
[19:55] <tedg> mterry, I think that it shouldn't be in the build step anymore, no?
[19:56] <mterry> tedg, yeah... the integrated test for copy should do 'snapcraft stage' instead of 'snapcraft snap' since it doesn't provide the metadata that 'snapcraft snap' now demands
[19:56] <mterry> tedg, and should test ./stage/dst instead of ./snap/dst
[19:56] <tedg> Ah, okay.
[19:57] <tedg> mterry, Cool, works, thanks!
[19:57] <mterry> tedg, sweet
[20:00] <kyrofa> ogra_, without i2c, does that mean GPIO works OOTB?
[20:00] <kyrofa> ogra_, on the rpi2