[00:04] <sergiusens> rsalveti: check #ubuntu-release :-P
[01:51] <sergiusens> @reviewlist
[01:51] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir/+merge/260620 | No reviews (4 days old)
[01:51] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/fix-tests/+merge/260618 | Approve: 1 (4 days old)
[01:51] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/link-to-external-ui/+merge/260833 | Needs Information: 1 (less than a day old)
[01:51] <nothal> https://code.launchpad.net/~sergiusens/snappy/trunkBackport470/+merge/260884 | No reviews (less than a day old)
[01:51] <nothal> https://code.launchpad.net/~sergiusens/snappy/forgetGocheck/+merge/260890 | No reviews (less than a day old)
[03:00] <rsalveti> sergiusens: Chipaca: don't we have auto-merge for snappy/15.04?
[03:00] <rsalveti> checking https://code.launchpad.net/~mvo/snappy/snappy-lp1449032-poor-mans-rsync-15.04/+merge/260556 , not sure what are the missing steps in there
[03:22] <miken> rsalveti: missing commit message?
[06:40] <dholbach> good morning
[06:46] <dholbach> seb128, so you finally got an answer? :)
[06:46] <seb128> dholbach, hey, yeah, thanks for nagging mvo for me ;-)
[06:47] <dholbach> :)
[06:57] <zyga> good morning
[07:03] <fgimenez> good morning
[07:34] <davidcalle> Morning snappy o/
[07:34] <seb128> hey davidcalle
[08:20] <beowulf> morning
[08:29] <beowulf> sergiusens: hey, you asked if 'service ui' was a good name for the link to a snaps running web ui from webdm, it's the least bad name i could come up with
[08:30] <beowulf> i am open to suggestions as to what that link should be called, but i think the design of this area needs work
[08:37] <beowulf> sergiusens: also, thanks for the reviews :)
[08:40] <ogra_> mvo, hmm, seems the image builds all failed tonight looking for that apparmor features file
[08:41] <mvo> ogra_: let me look into this
[08:41] <ogra_> i dont get why
[08:41] <ogra_> neither apparmor nor livecd-rootfs changed
[08:41] <mvo> ogra_: I think its because I added the cache generation
[08:42] <ogra_> (or am i looking at the wrong archive ?)
[08:44] <ogra_> oh, i see ... the PPA
[08:44] <mvo> ogra_: I think I know whats going on, I will check
[08:45] <ogra_> k, thanks :)
[08:47] <elopio> good morning.
[08:51] <JamesTait> Good morning, folks! Happy Repeat Day, and happy Repeat Day! 😃
[09:44] <mvo> jdstrand: hey, for later. I put some ideas and a proof-of-concept for the apparmor cache file handling in https://bugs.launchpad.net/snappy/+bug/1460152/comments/6
[09:46] <mvo> jdstrand: I added a different fix, but it might be a option to consider changing apparmors behavior here
[09:47] <mvo> jdstrand: one example where the current behavior is not ideal is if a backup file is restored for a policy with the original (backup) mtime, then the cache is not re-generated either
[10:31] <miken> Hi people. I created this bug the other day, but wasn't sure if it's a webdm bug or more generally how snappy itself sets up /tmp/snaps/ the first time a framework is installed. Can someone pls check? https://bugs.launchpad.net/bugs/1460517
[10:57] <sergiusens> rsalveti: I see it merged
[10:58] <sergiusens> rsalveti: oh yeah, lp-propose's bug where the commit message is actually the description ;-)
[10:59] <sergiusens> beowulf: how about just ui or web ui... or we can go back in time and call it 'web portal' :P
[11:07] <beowulf> sergiusens: web portal is possibly the most human, still doesn't accurately explain what's going on (because we can't explain what's going on, unless the user can give a string to explain what's at the end of that url?)
[11:07] <beowulf> i'll change it to anything though, just pick some words :)
[11:11]  * ogra_ curses vivid and reboots his overheating laptop for the nth time today :(((
[11:14] <sergiusens> ogra_: go back to precise!
[11:14] <sergiusens> beowulf: maybe ogra_ has better words for it
[11:15] <ogra_> for what ? renaming webdm ?
[11:15] <sergiusens> ogra_: no, let me get a screenshot ;-)
[11:15] <ogra_> (if i can open a browser without my laptop sutting down :P )
[11:16] <ogra_> *shutting
[11:17] <sergiusens> ogra_: http://imgur.com/grZ72cS
[11:17] <beowulf> ogra_: in your webrtc snap, you define a ui port, in webdm we create a button for this
[11:17] <sergiusens> the mouse is over "Service UI"
[11:17] <beowulf> ogra_: what should that button say?
[11:18] <beowulf> (talking buttons, who knew)
[11:18] <ogra_> just "Open" ?
[11:19] <ogra_> service Ui sounds confusingly as if i would access a configuration option there
[11:19] <beowulf> ogra_: you might, in some snaps
[11:19] <ogra_> (somehow like "Management UI")
[11:20] <ogra_> well, then call it "Manage/Open" or some such ...
[11:21] <beowulf> "Open" is actually open ended enough to cover all options, or about "Open $name"
[11:21] <ogra_> its a bit tricky to find a unique name for a multi purpose button :)
[11:21] <ogra_> yeah, i guess Open is the best here unless you want to indicate management/configuration can be accessed through it
[11:22] <ogra_> but i guess thats up to the app
[11:37] <beowulf> http://bazaar.launchpad.net/~stephen-stewart/webdm/link-to-external-ui/revision/155
[11:37] <beowulf> sergiusens: ^
[11:39] <sergiusens> beowulf: compromise :-)
[11:53] <sergiusens> @reviewlist
[11:53] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir/+merge/260620 | No reviews (4 days old)
[11:53] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/fix-tests/+merge/260618 | Approve: 1 (4 days old)
[11:53] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (less than a day old)
[11:53] <nothal> https://code.launchpad.net/~sergiusens/snappy/trunkBackport470/+merge/260884 | No reviews (less than a day old)
[11:53] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1449032-poor-mans-rsync/+merge/260931 | No reviews (less than a day old)
[11:53] <sergiusens> mvo: mind checking ^ ?
[11:58] <mvo> sergiusens: yes! I wanted to get to this list this afternoon anyway :)
[12:07]  * Chipaca adds https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 to the pile
[12:08] <Chipaca> mvo: wrt https://code.launchpad.net/~mvo/snappy/snappy-lp1449032-poor-mans-rsync/+merge/260931
[12:09] <Chipaca> mvo: the comment about "xxx on trunk yadda yadda" might be worth addressing
[12:09] <Chipaca> given that this is for trunk an' all
[12:16] <mvo> Chipaca: *cough*
[12:16] <mvo> Chipaca: indeed
[12:16] <mvo> Chipaca: its good that I have you
[12:21] <mvo> Chipaca: meh, extra work, I need to add a new CopyFlagArchive or CopyFlagPreserverUtimes, CopyFlagPreserverPermissions
[12:21] <Chipaca> mvo: ah
[12:21] <Chipaca> mvo: leave it for now then
[12:21] <mvo> Chipaca: ok
[12:21] <mvo> Chipaca: I will update the comment to say why its not using the internal one at least
[12:44] <Chipaca> rsalveti: wrt "don't we have automerge for 15.04", we do, but the branch was missing a mommit cessage
[12:48] <mvo> yes, my bad
[12:48] <rsalveti> morning
[12:49] <rsalveti> Chipaca: got it
[12:49] <Chipaca> speaking of morning, lunch.
[12:49] <rsalveti> sergiusens: man, you're waking up quite early
[12:49] <rsalveti> need to start doing the same
[12:50] <rsalveti> hm, actually, my irc server is in a different timezone
[12:50] <rsalveti> that explains the log timestamp
[12:50] <rsalveti> seb128: were you able to get uefi to work in the end?
[12:51] <seb128> rsalveti, no, I upgraded to the 0.22 version uploaded to wily this night and generated a new image/dd-ed that to a key but the device is still not listed a valid boot one
[12:51] <seb128> I was waiting on slangasek to be around to ask him how I can debug that more
[12:52] <rsalveti> right, yeah
[12:54] <rsalveti> @reviewlist
[12:54] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir/+merge/260620 | No reviews (4 days old)
[12:54] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/fix-tests/+merge/260618 | Approve: 1 (4 days old)
[12:54] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (less than a day old)
[12:54] <nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
[12:54] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-oauth-quoting/+merge/260909 | No reviews (less than a day old)
[12:54] <rsalveti> sergiusens: Chipaca: mvo: anyone to review mterry's mrs?
[12:55] <rsalveti> guess also something to backport to 15.04
[12:55] <Chipaca> rsalveti: looking at them right now
[12:55] <rsalveti> Chipaca: awesome
[12:55] <mvo> rsalveti: I just did
[12:56] <rsalveti> great
[12:57] <Chipaca> mterry: why dir = strdup(dir)?
[12:58] <mterry> Chipaca, that's the main focus of the bug fix.  strtok changes its argument.  And getenv returns the real live environment memory
[12:58] <mterry> Chipaca, so we have to copy the environment memory so strtok doesn't ruin it
[12:58] <Chipaca> two things:
[12:58] <Chipaca> (1) ahh
[12:58] <Chipaca> (2) aaaaaah
[12:59] <mterry> :)
[12:59] <rsalveti> mvo: https://launchpadlibrarian.net/208158748/livecd-rootfs_2.306%2Bppa1_2.306%2Bppa2.diff.gz
[12:59] <rsalveti> mvo: you're creating the cache without the features file
[12:59] <rsalveti> I believe that means it would use the features file from the builder (host)
[12:59] <Chipaca> mterry: about EEXIST, that's a can'thappen, btw
[12:59] <mterry> Chipaca, it did for me!
[12:59] <Chipaca> mterry: wat
[12:59] <mterry> Chipaca, the test didn't pass if you ran it multiple times
[12:59] <Chipaca> mterry: tell me more!
[13:00] <mterry> Chipaca, if you try to mkdir a directory that exists, it gives you EEXIST
[13:00] <Chipaca> mterry: yes
[13:00] <Chipaca> mterry: but that mkoldtmpdir is called after you have a private /tmp/
[13:00] <mvo> rsalveti: oh, let me look at this and its implications
[13:00] <mterry> Chipaca, oh huh.  OK.  Fair.  Then it just affects the test code
[13:00] <Chipaca> i guess in tests we don't run as root?
[13:00] <mterry> Chipaca, right
[13:00] <Chipaca> chicken
[13:00] <Chipaca> :-p
[13:00] <mterry> :)
[13:00] <rsalveti> mvo: that could mean that the cache is incompatible with our targets
[13:01] <rsalveti> and that would make the cache to be generated again during first boot
[13:03] <mvo> rsalveti: makes sense, meh - I need to figure out now why it was not working with the feature file. oh well :) I would actually really like to change the way the caching works to tie the cache stronger to the original file. I did a patch but need to wait for jdstrand as its a bit of a depature from the current way the caching works.
[13:05] <Chipaca> mterry: um, just realised one thing: not checking the return value of that strdup
[13:06] <mterry> Chipaca, ah!  ok.  I've lived in a g_strdup world so long that I forgot I needed to
[13:06] <Chipaca> mterry: :)
[13:09] <mterry> Chipaca, added a check and a comment on why we strdup (since that interaction really isn't obvious).  hence the bug I guess :)
[13:10] <Chipaca> mterry: if the strdup fails, maybe die("wtf") is in order?
[13:11] <mterry> Chipaca, sure could.  The other error cases were more mild in that function, but they were more mild errors
[13:11] <Chipaca> ah, wait, it's mkoldtmpdir
[13:11] <Chipaca> i'm not sure i care ;)
[13:11] <mterry> yeah
[13:11] <Chipaca> otoh, if the strdup failed, you're running on a c-64 or sth
[13:12] <mterry> although it doesn't bode well for the future of the run
[13:12] <Chipaca> yup
[13:12] <mterry> I think a die() is appropriate
[13:12] <Chipaca> ok
[13:12] <mterry> Chipaca, done
[13:14] <jdstrand> mvo: re caching-- I think we need to pull in jjohansen
[13:25] <sergiusens> mvo: can't we add the kernel and os snap versions to the cache file and have ubuntu-core-launcher add them to the mix to determine which to load?
[13:25] <sergiusens> just throwing out an idea
[13:25] <mvo> sergiusens: yeah, I need to dig deeper, but I would love something like this
[13:27] <jdstrand> we should probably have tyhicks involved too
[13:27] <jdstrand> mvo: maybe it makes sense to setup a hangout?
[13:28] <jdstrand> caching seems like it isn't that complicated, but it is actually quite complicated and understanding all the requirements, etc is key
[13:29] <mvo> jdstrand: probably, I can also write up something by mail and start a discussion with that?
[13:30] <jdstrand> mvo: mail will be too slow in this case. there is a lot to digest-- between distro, touch and snappy requirements, history and systemd, planned work and new ideas, I think we need to have a hangout
[13:30] <mvo> ok
[13:31] <jdstrand> mvo: feel free to send an email detailing the snappy requirements and your thoughts-- that would definitely be useful
[13:31] <mvo> ok
[13:31] <jdstrand> that can springboard the conversation
[13:37] <rsalveti> mvo: right, we can have that script with a known/working features file and then land your change to improve the cache handling
[13:37] <rsalveti> I believe the the features files should be stable for the generic kernel
[13:37] <rsalveti> my main concern in there is once we start getting other kernels
[13:37] <rsalveti> but we can handle this later on
[13:39] <rsalveti> mvo: we could just land that other approach we had which is not pre-caching and cleaning up the cache when updating
[13:39] <rsalveti> then work with the security team next week to land a better fix
[13:40] <rsalveti> since we'd need a fix already for 15.04.1, what do you think?
[13:40] <mvo> rsalveti: yeah, I think that is ok, I am not overly happy with the options so far, removing the cache files after the upgrade feels like too much of a special case for my taste and the generate-on-image is also problematic once we have hte kernel snap. ideal would be to solve it in apparmor_parse IMO
[13:41] <rsalveti> right, I agree, mostly concerned with the time that it would take to land that
[13:41] <mvo> rsalveti: right, cleaning that dir works as a short-term, I am not really liking it, but of course its fine as a stop-gap. I would love to keep the upgrade free of special cases, it should (IMO) just be a untar
[13:41] <mvo> rsalveti: time is a good point
[13:41] <mvo> rsalveti: I look into the rm solution then
[13:41] <rsalveti> mvo: cool, but let's plan something for earlier next week to discuss this in depth
[13:43] <kyrofa> beowulf, ping
[13:47] <mterry> mvo, re: my envvars branch.  Thanks for the review!  You commented on needing a dep on ubuntu-core-launcher if I'm going to remove the TMPDIR creation.  But I didn't remove it, I just moved it lower in that file.  So I think I can skip the dep.  You mentioned that the env vars would make sense in the snappy package.  I don't disagree, but then I run into circular dependencies (that code is used in 3 total packages).  Is there a nice neutral place tha
[13:47] <mterry> t isn't helpers?  Lastly, I'll add SNAP_ARCH
[13:48] <mvo> mterry: thanks, looks like I missed that the dir is created, all good then :)
[13:49] <mvo> mterry: you could create a new package just for this, it seems to be a bit overkill though, so maybe helpers is good enough. I leave that to you, if it stays in helpers a small comment why its there would be cool (i.e. mention the circular deps)
[13:49] <mterry> OK
[13:49] <beowulf> kyrofa: pong
[13:50] <kyrofa> beowulf, quick question: The webdm download_size and install_size-- they're in bytes?
[13:51] <beowulf> kyrofa: yes
[13:52] <kyrofa> beowulf, just wanted to make sure. Thanks!
[13:52] <beowulf> kyrofa: did you see the default icon i added?
[13:53] <beowulf> kyrofa: default-package-icon.svg, let me know if it works for you or needs changing
[13:56] <kyrofa> Why yes I did! It's lovely, thank you :)
[13:56] <kyrofa> beowulf, ^^ it works perfectly
[13:59] <beowulf> \o/
[14:03] <mterry> mvo, ok updated and merged from trunk
[14:05] <mvo> mterry: thanks a bunch, just top-approve yourself (as its already approved), tarmac will merge
[14:05] <mvo> automatically
[14:05] <mterry> mvo, done, though it feels dirty  :)
[14:06] <mterry> I'm curious what capacity/interest we have for sunsetting these deprecated variables
[14:10] <ogra_> well, did we change to the new ones before or after the store was flushed
[14:33] <slangasek> seb128: ok, so now I'd like to see a recursive directory listing for partition 2 of this image
[14:49] <Chipaca> @reviewlist
[14:49] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (less than a day old)
[14:49] <nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
[14:49] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-oauth-quoting/+merge/260909 | No reviews (less than a day old)
[14:49] <nothal> https://code.launchpad.net/~chipaca/snappy/unsetActiveClick/+merge/260570 | No reviews (4 days old)
[14:49] <nothal> https://code.launchpad.net/~chipaca/snappy/setActiveClick/+merge/260569 | No reviews (4 days old)
[14:49] <Chipaca> nothal: something is very wrong with you, somewhere
[14:55] <sergiusens> Chipaca: somehow somewhere something is wrong
[14:55]  * sergiusens feels as if it were a Friday
[14:56] <Chipaca> sergiusens: something other than nothal finding half the branches?
[15:09] <seb128> slangasek, hey, sorry I was in a call ...  http://paste.ubuntu.com/11544712/
[16:02] <slangasek> seb128: no .efi executables.  So this version of udf is /also/ broken.
[16:03] <seb128> slangasek, is there anything on the image saying what version of udf was used to generate it, in case for some reason something didn't work?
[16:03] <slangasek> seb128: not that I know of
[18:00] <seb128> slangasek, do you have any suggestion what to do next about the uefi thing?
[18:00] <seb128> did anyone got it to work?
[18:00] <slangasek> seb128: well the version I pointed you to yesterday still works
[18:00] <slangasek> the one in the tools ppa
[18:00] <seb128> the wily one is supposed to have the same changes no?
[18:01] <seb128> the changelog includes
[18:01] <seb128>   [ Steve Langasek ]
[18:01] <seb128>   * Add UEFI support for grub.
[18:01] <slangasek> of course it's supposed to, but clearly somebody regressed something there
[18:02] <slangasek> it's good to know about this regression, and the snappy team should fix that; but if you're trying to get unblocked for your own work, use the version I know is tested :)
[18:03] <seb128> k, going to do that next
[18:16] <sergiusens> slangasek: there are 4 unrelated commits between that and what follows though
[18:17] <sergiusens> I'll check for regressions in any case
[18:18] <slangasek> I've just re-confirmed locally that udf 0.21-1+175~ubuntu15.04.1 sets up the boot partition correctly
[18:18] <slangasek> # ubuntu-device-flash core 15.04 -o ubuntu-15.04-snappy-amd64-generic.img -s 4 --channel stable --oem generic-amd64 --enable-ssh
[18:18] <slangasek> # kpartx -a ubuntu-15.04-snappy-amd64-generic.img
[18:18] <slangasek> # mount /dev/mapper/loop0p2 /mnt
[18:19] <slangasek> # ls /mnt/EFI/BOOT/
[18:19] <slangasek> BOOTX64.EFI  grub.cfg
[18:19] <seb128> sergiusens, slangasek: I've had issue with that usbkey so trying again on another one, it's almost done writing, going to let you know if that one worked better in a bit
[18:19] <sergiusens> seb128: slangasek (amd64)ubuntu@localhost:~$ ls /boot/efi/EFI/BOOT/
[18:19] <sergiusens> BOOTX64.EFI  grub.cfg
[18:20] <sergiusens> that's with the latest wily one
[18:20] <slangasek> seb128: have you checked the contents of the generated image, /before/ flashing it to the usb stick?
[18:20] <slangasek> to rule out an incomplete usb write
[18:20] <sergiusens> running in kvm though
[18:20] <slangasek> seb128: ^^ ok so sergiusens shows the wily version working
[18:20] <seb128> slangasek, no, but it seems it worked this time
[18:20] <seb128> so I guess things were wrong puting the image on the first key :-/
[18:20] <sergiusens> well, I don't know if it boots for uefi, I can attest the files are there at least :-)
[18:21] <seb128> slangasek, sergiusens: the laptop lists the key as a boot device this time, so it looks good ;-)
[18:21] <seb128> sorry for the noise :-/
[18:21] <seb128> yeah, and it boots!
[18:21] <sergiusens> no worries, you are the first live user ;-)
[18:21] <sergiusens> for uefi that is
[18:21] <seb128> :-)
[18:22] <seb128> great, so that works
[18:22] <seb128> tomorrow to try to resolve desktop image package conflicts
[18:22] <sergiusens> great, as soon as that wily powerpc issue is gone I'll propagate this to all the ppa's
[18:22] <seb128> slangasek, sergiusens, thanks!
[19:17] <mterry_> Is tarmac not hooked up for ubuntu-core-launcher?
[19:22] <sergiusens> mterry_: I don't think so, no
[19:22] <mterry_> sergiusens, should we push to trunk manually once we're approved?
[19:24] <sergiusens> mterry_: I can setup a no build merge for it with tarmac; can setup a bzr bd/sbuild thing for tomorrow or later
[19:25] <mterry_> sergiusens, that would be awesome
[22:02] <tedg> sergiusens, When you do core launcher can you do snapcraft too please? :-)