[12:54] <hamo> Would you please give me a Ubuntu cloak?
[12:57] <topyli> hamo: are you an ubuntu member? if so, please provide a link to your launchpad page and we can help
[12:58] <hamo> topyli: my launchpad username is hamo
[12:59] <hamo> topyli: https://launchpad.net/~hamo
[13:01] <topyli> looking, but you don't seem to be a member. let me look better :)
[13:02] <hamo> topyli: actually, I am an employer of Canonical
[13:03] <hamo> topyli: sorry, employee
[13:03] <topyli> hamo: yeah, but that's different. see here: https://launchpad.net/~ubuntumembers
[13:03] <hamo> topyli: So I could just apply for Canonical cloak?
[13:04] <topyli> hamo: i suppose. does canonical have their own group here on freenode?
[13:05] <topyli> hamo: it shouldn't be too hard for you to become an ubuntu member as well though, just apply
[13:05] <hamo> topyli: Ok..Thanks, will apply
[13:05] <topyli> cheers
[13:06] <topyli> the page is long, but the actual drill is simple: https://wiki.ubuntu.com/Membership
[13:06] <hamo> topyli: Many thanks.
[13:07] <topyli> welcome to the funny farm! :)
[13:12] <AlanBell> hamo: there is a canonical cloak available
[13:13] <AlanBell> hamo: talk to joey about that
[13:13] <AlanBell> and the canonical wiki
[19:45] <skellat> May I receive an Ubuntu cloak?  My Launchpad profile is here: https://launchpad.net/~skellat
[19:46] <Unit193> Pici, AlanBell, topyli ^^ He's part of the members group.
[20:02] <JoseeAntonioR> Unit193: you can highlight the IRCC by saying IRCC
[20:02] <Unit193> JoseeAntonioR: I am aware, what about it?
[20:03] <Unit193> Pretty sure you said that last time too. :P
[20:05] <JoseeAntonioR> Unit193: just saying


[01:30] <netphreak> Hi, guys :)
[01:32] <netphreak> Any news on ubuntu snappy support on the RPI 3?
[02:25] <zyga> jdstrand: hey
[02:26] <zyga> jdstrand: could you have a quick look at https://github.com/ubuntu-core/snappy/pull/635
[02:26] <zyga> jdstrand: the only new thing there since we last looked at that is https://github.com/ubuntu-core/snappy/pull/635/commits/939d1d5824c8ced1b7e994cf4f2f88ad289693ba
[02:27] <zyga> jdstrand: I would *really* like to land this branch as it's been in a linbo for a week and I have some code that needs it
[02:27] <zyga> jdstrand: if I lost track of the desired file name and other templates then please correct me but I think it is okay
[02:28] <zyga> davidcalle: hey, sorry, lost IRC connection
[02:29] <zyga> davidcalle: can you re-state your request please?
[08:26] <dholbach> good morning
[08:39] <noizer> Good morning
[09:05] <noizer> jdstrand: Hi are you available?
[09:19] <zyga> good morning
[09:48] <ogra_> mvo, you didnt approve the kernels from the last build/upload ?
[10:00] <noizer> Did you heard about the bomming in belgium dammed
[10:08] <zyga> ogra_: hey, good morning
[10:08] <mvo> ogra_: I see nothing in the unapproved queue
[10:19] <netphreak> good morning ;)
[10:19] <netphreak> Any news on ubuntu snappy support on the RPI 3?
[10:20] <noizer> I heard it will be working on RPI 3 netphreak
[10:20] <noizer> But i'm not a canonical developer
[10:21] <ogra_> mvo, https://myapps.developer.ubuntu.com/dev/click-apps/4739/rev/2/ https://myapps.developer.ubuntu.com/dev/click-apps/4316/rev/3/ https://myapps.developer.ubuntu.com/dev/click-apps/4284/rev/8/ https://myapps.developer.ubuntu.com/dev/click-apps/4283/rev/16/ https://myapps.developer.ubuntu.com/dev/click-apps/4283/rev/17/
[10:22] <ogra_> morning zyga
[10:25] <mvo> ogra_: aha, please click on "request for manual review", then I can see them in the review queue, otherwise they are invisible for me
[10:26] <mvo> ogra_: I can do that now myself
[10:26] <mvo> ogra_: just for the next time, that click makes it easier for me to find them
[10:26] <ogra_> ok
[10:27] <ogra_> i wonder how to do that for the automated uploads then :P
[10:29] <zyga> jdstrand: hey
[10:29] <zyga> jdstrand: I didn't know you were around
[10:29] <mvo> ogra_: I think we need to talk to jdstrand and see if we can drop the -all-root requirement
[10:29] <mvo> ogra_: for the squashfs, I think that is causing the issues right now because the repack of the snap can not be done because of different parameters and this causes this manual review thing
[10:29] <ogra_> mvo, well, at least special case os snaps
[10:29] <zyga> jdstrand: I don't know if you saw the discussion on telegram; we were wondering about the apparmor cache, specifically what maintains the cache enabled by https://github.com/ubuntu-core/snappy/pull/635/files#diff-48ca5117699c941398b92fcd61caaed5R43
[10:30] <mvo> ogra_: yes, or that
[10:30] <ogra_> i think the --all-root was wanted (there was a bug)
[10:30] <ogra_> Bug #1546821
[10:31] <sergiusens> ogra_, yes; the bug sequence was, make snapcraft support the os snap without all-root and remove the snappy build functionality
[10:31] <sergiusens> wednesday's release will have that
[10:32] <ogra_> sergiusens, ah, good to know
[10:37] <ogra_> sergiusens, please leave me a few days with the removal from snappy though (even though i expect no issues with switching livecd-rootfs, if there are any we are screwed with the dailies)
[10:38] <sergiusens> ogra_, I am not removing snappy build, that is on mvo and his merry friends :-)
[10:38] <ogra_> ah, ok
[10:41] <ysionneau> can ubuntu-device-flash generate separate .img files for each partition instead of a big img file?
[10:42] <ogra_> ysionneau, nope, but kyrofa has a script to split it into two img files
[10:42] <ogra_> (one for the boot stuff, one for writable
[10:42] <ogra_> )
[10:43] <ysionneau> I guess fdisk + losetup + dd should do the job?
[10:43] <mvo> sergiusens: we still need that bit for various tests (and its ~5 lines) happy to hide it (and make it only available in the tests)
[10:43] <ysionneau> but I'd like to have a look at the script anyway :)
[10:44] <dholbach> davidcalle, want to have a chat about snappy/snapcraft docs in a bit? or shall we talk later?
[10:45] <davidcalle> dholbach: can you do a quick one in ~20min?
[10:45] <dholbach> yes, a quick one
[10:46] <sergiusens> mvo, well I'm not the one pushing for it https://bugs.launchpad.net/snapcraft/+bug/1546821 look at comment #8
[10:47] <sergiusens> mvo, you can hide it; but personally I think our QA would be a lot better if you use snapcraft's snap instead
[10:47] <sergiusens> mvo, if it is just 5 lines it could also just be moved to the test runner code
[10:48] <mvo> sergiusens: fair enough, yes, I think a separate package would be good
[10:48] <mvo> sergiusens: anyway, let me look at this
[10:48] <sergiusens> mvo, but of most importance; people like you and me need to stop using `snappy build`
[10:53] <mvo> sergiusens: thats fine, can we make "snapcraft snap" not look for snapcraft.yaml maybe? this would allow us to keep using our tests
[10:54] <sergiusens> mvo, have you used snapcraft snap? ;-)
[10:54] <mvo> sergiusens: http://paste.ubuntu.com/15471199/
[10:55] <sergiusens> mvo, `snapcraft snap DIR` :-)
[10:56] <mvo> sergiusens: thanks! http://paste.ubuntu.com/15471206/ :P I guess it wants to tell me that the architectures field is mandatory
[10:56] <popey> I spy new update coming down the pipe!
[10:56] <popey> Updating canonical-pi2-linux (4.4.0-1004-raspi2+20160321.17-52)
[10:56] <popey> \o/
[10:56] <mvo> sergiusens: I will prepare a branch that replaces snappy build with snapcraft snap
[10:57] <mvo> sergiusens: will snapcraft snap also run the click-reviewers-tools automatically?
[10:58] <oparoz> Hello guys, I didn't RTFM, but I was just wondering. Can we have several snaps installed and communicte with one another? Redis snap, Libreoffice snap, all usable from a webapp snap?
[11:01] <dholbach> davidcalle, let me know when you have time
[11:02] <popey> is this expected when i update http://paste.ubuntu.com/15471238/ - to 4.4.0-1004-raspi2+20160321.17-52 ?
[11:05] <davidcalle> dholbach: I do now :)
[11:06] <dholbach> yes!
[11:20] <kyrofa> Good morning
[11:22] <kyrofa> ysionneau, those scripts are currently specific to the rpi2 image (they need to be generalized), but they're here: https://github.com/owncloud/pi-image/tree/master/image-creation-tools
[11:36] <sergiusens> mvo, I need to make it run it; but I'm waiting for stabilization of the whole infra for that (wrt click review)
[11:36] <sergiusens> as it might just end up confusing with all the churn
[11:38]  * ogra_ tickles pitti with bug 1547033 ... would be nice to have that fixed before final release ;)
[11:41] <ogra_> sergiusens, https://github.ubuntu.com/96boards/linux ??
[11:41] <ogra_> (from your blogpost)
[11:42] <ogra_> sergiusens, i assume there sneaked some wishful thinking in to take over github with ubuntu ?
[11:44] <sergiusens> ogra_, lolz
[11:44] <sergiusens> ogra_, let me fix that :-P
[12:00] <kyrofa> sergiusens, elopio whew, so those examples were failing for everyone?
[12:02] <sergiusens> kyrofa, yes, I dug into it last night; it is related to the snappy changes that landed yesterday
[12:02] <kyrofa> sergiusens, ah, okay
[12:03] <sergiusens> kyrofa, first -> binary_name = appname if appname == snapname else "snapname.appname"
[12:03] <sergiusens> second, PWD for apps changed again
[12:03] <sergiusens> to be PWD
[12:03] <sergiusens> kyrofa, now the testing infra is broken ;-)
[12:03] <kyrofa> sergiusens, yeah, and a number of environment variables were removed, too
[12:08] <kyrofa> sergiusens, I see an opencv failure as well... trying to track that down
[12:09] <ogra_> mvo, do you think we can do anything about the umount error messages on shutdown (i see a lot red on reboot)
[12:09] <mvo> ogra_: what is that? do you have some more details?
[12:09] <ogra_> mvo, /writable and some bind mounts cant be unmounted
[12:10] <mvo> ogra_: hm, I check
[12:10] <ogra_> i think we should just skip unmounting altogether, call sync and remouont ro
[12:10] <ogra_> and not spit out an error :)
[12:14] <pitti> ogra_: followed up to the bug, mind having a look?
[12:15] <ogra_> pitti, i'll adjust that and we'll see :)
[12:15] <pitti> ogra_: cheers
[12:16] <ysionneau> kyrofa: thx !
[12:17] <kyrofa> sergiusens, does the opencv example work for you on xenial? I'm getting libmvec errors
[12:17] <kyrofa> ysionneau, no problem
[12:18] <sergiusens> kyrofa, well the examples tests runs them, so I hope they do
[12:19] <kyrofa> sergiusens, yeah mine failed... and it fails locally as well. I'll rerun them just to be safe
[12:21] <noizer> What interfaces are there available for network?
[12:21] <kyrofa> jdstrand, haha, using indent in the launcher now?
[12:21] <sergiusens> kyrofa, don't run retest this as it will fail :-)
[12:21] <jdstrand> kyrofa: yeah, I am spending some time in there :)
[12:22] <kyrofa> sergiusens, :(
[12:22] <jdstrand> mvo, ogra_: where do you want to drop -all-root?
[12:22] <ogra_> jdstrand, for os snap builds
[12:23] <ogra_> (we need the system-user-owned files and dirs there)
[12:24] <jdstrand> background: -all-root is required to verify snaps from untrusted sources
[12:24] <jdstrand> otherwise I can't resquash
[12:24] <jdstrand> an os snap is of course trusted
[12:25] <jdstrand> I'm pretty sure if I remove -all-root from the resquash we are going to get different users at some point, if not today
[12:25] <jdstrand> but I can try
[12:25] <jdstrand> ogra_: what about the kernel snap?
[12:26] <ogra_> jdstrand, there it doesnt matter .. nor for the gadget
[12:26] <kyrofa> sergiusens, ah, I was able to get rid of my local failure by upgrading gcc, g++ and libc6-dev
[12:26] <jdstrand> ok
[12:26] <sergiusens> jdstrand, I've been doing kernel snaps with all-root just fine
[12:26] <jdstrand> ok good
[12:26] <sergiusens> kyrofa, weird situation, abi breakage again?
[12:26] <ogra_> it is only important for the system daemons to have their users around
[12:26] <jdstrand> hopefully I can just remove -all-root if it is an os snap and it will work. but I might have to disable the resquash for them
[12:26] <kyrofa> sergiusens, yeah not sure. Everything is broken!
[12:28] <sergiusens> kyrofa, tests seem to be running fine now for your stuff ;-)
[12:30] <jdstrand> mvo, ogra_: I added a card for -all-root and os snaps
[12:30] <ogra_> thanks !
[12:31] <ysionneau> will the ubuntu-device-flash available at http://people.canonical.com/~mvo/all-snaps/ubuntu-device-flash be packaged for ubuntu desktop 16.04 ?
[12:33] <ogra_> ysionneau, there is a replacement in the works called ubuntu-image, though i was hoping mvo pushes the changes for bridging the time til thats ready if it takes longer
[12:33] <kyrofa> mvo, yeah still worth landing I say
[12:33]  * ogra_ isnt sure what the actual ETA for ubuntu-image is ... sergiusens knows though
[12:35] <sergiusens> ogra_, you didn't join the meeting yesterday; so you didn't figure it out
[12:35] <kyrofa> popey, I just noticed you tried to install the owncloud-pi gadget. Are you just looking for the owncloud snap?
[12:35] <sergiusens> ogra_, now you might
[12:36] <ysionneau> ogra_: ah ok
[12:36] <ogra_> sergiusens, yeah, i totally missed while being busy releasing snaps to the store
[12:42] <ogra_> ppisati, do you happen to have auboot binary for the rpi3 ?
[12:42]  * ogra_ is to lazy to compile one :P
[12:52] <ysionneau> hmmmm, so when snapcraft says 'architectures' when trying to build a gadget snap, it means?
[12:53] <popey> kyrofa: yeah, i just thought I'd try installing that
[12:53] <kyrofa> popey, oh okay, so not really looking for anything in particular?
[12:55] <popey> well, owncloud in particular, yeah :)
[12:58] <sergiusens> ysionneau, it means we have a bug :-)
[12:58] <sergiusens> ysionneau, can you log one?
[12:59] <kyrofa> popey, oh, just try `snappy install owncloud`
[12:59] <ysionneau> you mean can I file a bug report ?
[12:59] <sergiusens> ysionneau, yes please https://bugs.launchpad.net/snapcraft/+filebug
[12:59] <sergiusens> ysionneau, I will add it to the 2.6 work due tomorrow
[12:59] <popey> kyrofa: on 16.04?
[12:59] <kyrofa> popey, indeed
[12:59] <ysionneau> I'm really not used to your bugtracker and I don't even have an account
[12:59] <ysionneau> but I guess it's the occasion
[12:59] <popey> kyrofa: ok
[12:59] <ysionneau> let me try that...
[13:01] <kyrofa> popey, the gadget snap only exists for creating an image with the owncloud snap preinstalled
[13:03] <kyrofa> sergiusens, I swear every time I run the example tests I get one more failure. I'm up to 4 now
[13:03] <sergiusens> kyrofa, yeah I see the same
[13:03] <sergiusens> fgimenez, any help ^
[13:03] <sergiusens> ?
[13:04] <kyrofa> The opencv failure is the same one I just got rid of locally by updating
[13:04] <kyrofa> I wonder if the others are similar
[13:05] <ysionneau> https://bugs.launchpad.net/snapcraft/+bug/1560481
[13:06] <popey> kyrofa: does it start automatically once installed?
[13:07] <kyrofa> popey, yes, though it takes a moment to generate mysql creds and stuff. Check the syslog
[13:07] <kyrofa> popey, you'll see apache waiting for creds, and mysql initializing
[13:07] <kyrofa> popey, on the rpi2, maybe a few moments ;)
[13:08] <popey> it's been a while.
[13:08] <sergiusens> kyrofa, ogra_ jdstrand https://github.com/ubuntu-core/snapcraft/pull/391
[13:09] <popey> kyrofa: no apache or mysql processes running
[13:09] <ogra_> sergiusens, looks good
[13:09] <kyrofa> popey, hmm, see errors in the syslog then?
[13:09] <popey> [340124.599445] audit: type=1400 audit(1458651897.178:59): apparmor="DENIED" operation="capable" profile="owncloud.canonical_mysql_9.0.0ubuntu1" pid=10400 comm="mysqld" capability=24  capname="sys_resource"
[13:10] <popey> kyrofa: ah, works on my edge pi2, but not my stable pi2
[13:10] <popey> guess this is expected?
[13:10] <kyrofa> popey, uh oh, no it's not
[13:10] <popey> heh
[13:10] <kyrofa> popey, but I just released in an attempt to fix that
[13:11] <kyrofa> popey, I apparently failed
[13:11] <popey> no worries
[13:11] <kyrofa> popey, can you give me the errors on the stable?
[13:11] <popey> any particular logs?
[13:12] <popey> http://paste.ubuntu.com/15471936/
[13:12] <popey> that's dmesg last bunch of lines
[13:12] <kyrofa> popey, just the syslog where they fired up. Those denials are normal
[13:12] <ysionneau> hope my bug ticket is clear enough sergiusens
[13:14] <popey> ricmm: fyi, the youtube-streamer demo (I think it's yours?) spams the syslog every 5 seconds after install http://paste.ubuntu.com/15471942/
[13:18] <sergiusens> ysionneau, no worries; I know what you are after :-)
[13:19] <sergiusens> ysionneau, in any case, gadget snaps in they future will be arch specific
[13:19] <sergiusens> so this is rather a remporary thing
[13:19] <ppisati> ogra_: yep
[13:19] <ogra_> i cant even get a purp out of mine (i finally built an aarch64 one)
[13:19] <ppisati> ogra_: https://github.com/piso77/ubuntu-embedded/blob/master/boards/raspi3/rootfs/boot/firmware/uboot.bin
[13:20] <ppisati> ogra_: and here is an ubuntu img, if you want to do some debug etc
[13:20] <ppisati> ogra_: http://people.canonical.com/~ppisati/ubuntu_embedded/ubuntu-embedded-16.04-raspi3.img.xz
[13:20] <ogra_> well, i hopefully only need a gadget snap :)
[13:21] <ppisati> ogra_: +1
[13:21] <ogra_> bah+
[13:21] <ogra_> reading uboot.env
[13:21] <ogra_> *** Warning - bad CRC, using default environment
[13:21] <ogra_> missing our patch
[13:22] <ogra_> ppisati, how exactly did you build it ?
[13:23] <ppisati> ogra_: you mean the steps?
[13:23] <ppisati> export ARCH=arm; export $(dpkg-architecture -aarmhf); export CROSS_COMPILE=arm-linux-gnueabihf-
[13:23] <ppisati> make rpi_3_32b_defconfig
[13:23] <ogra_> ppisati, oh, 32bit ?
[13:23] <ppisati> make ...
[13:24] <ppisati> ogra_: yep
[13:24] <ogra_> ah, there is a special config ... thats my error
[13:24] <ppisati> ogra_: my uboot binary is of some days ago
[13:24] <ppisati> ogra_: i think back then there was no 64b option
[13:25] <ogra_> rpi_3_defconfig defaults to 64 in swarrens branch
[13:25] <ppisati> i just noticed that
[13:26] <ogra_> grmpf
[13:26] <ogra_> still doesnt boot
[13:26] <ogra_> i suspect my trusty gcc is to old or something
[13:26] <ppisati> ogra_: i'm on wily FWIW
[13:39] <didrocks> popey: it's mine, and yeah, it will spam you until you configure it!
[13:39] <popey> :(
[13:39] <didrocks> popey: which is better than failing IMHO
[13:39] <didrocks> we can maybe just make it print once
[13:39] <popey> my poor sd card
[13:39] <popey> it's been spamming for days
[13:39] <didrocks> why did you install something without having it running?
[13:40] <popey> to look at it
[13:40] <didrocks> (hem, look at the logs, you have way more spammer ;))
[13:40] <popey> I can't believe you asked that question
[13:40] <didrocks> but didn't configure it, so didn't look at it? :p
[13:40] <popey> i wanted to see what was in the package, I didn't expect my syslog to be spammed for days as a result. "I'll configure that later"
[13:40] <popey> "NO, YOU MUST CONFIGURE IT NOW!"
[13:41] <popey> And I'll keep reminding you until your SD card wears out :)
[13:41] <didrocks> popey: the issue is that if we didn't spam regularly, how would you know days after what to put in it?
[13:41] <popey> Documentation
[13:41] <popey> a README perhaps is the standard way
[13:41] <didrocks> no way to expose the README in snappy
[13:41] <popey> I can find it in the directory it's installed in
[13:41] <didrocks> (forget people looking at the source git branch)
[13:42] <didrocks> hum, I'm unsure
[13:42] <didrocks> at least, it should print it once, ok
[13:42] <popey> Thunderbird doesn't spam my syslog if I don't configure a mail account.
[13:42] <didrocks> yeah, but configuring it is easier than snappy
[13:42] <popey> Debateable :)
[13:42] <didrocks> and you have a walkthrough
[13:43] <popey> I don't believe that spamming the syslog is ever a right answer to "How should we tell the user that the app isn't configured"
[13:43] <ogra_> ppisati, no go :( not sure why
[13:43]  * ogra_ just built on a wily machine
[13:43] <didrocks> popey: remember you are not in the regular case, you are in the one installing something but not using it. However, I do agree, I can spam you once
[13:44] <didrocks> popey: then, you go to answer people asking how to configure it :)
[13:44] <didrocks> popey: mind opening a bug on the demo branch?
[13:44] <didrocks> I'll do that on Friday
[13:44] <popey> link?
[13:44] <didrocks> http://github.com/ubuntu-core/demos
[13:44] <popey> (I strongly disagree that people don't install and not configure stuff)
[13:45] <didrocks> popey: I guess the real SD card issue is something else though, look at the logs you have, and yeah, we need ubuntu core to care about this
[13:47] <popey> didrocks: done.
[13:47] <didrocks> popey: link?
[13:47] <popey> https://github.com/ubuntu-core/demos/issues/2
[13:48] <ogra_> ppisati, was there any script i need to run ?
[13:48] <ppisati> ogra_: oh yeah, after yui build the uboot binary
[13:48] <ppisati> ogra_: you need to run...
[13:49] <jdstrand> sergiusens: ack, thanks
[13:49] <ogra_> i thought i remembered mkknlimage ... but cant find it
[13:51] <ppisati> ogra_: mkknlimg
[13:51] <ppisati> ogra_: https://github.com/raspberrypi/tools/blob/master/mkimage/mkknlimg
[13:51] <ysionneau> sergiusens: is there something I can do in my snap.yaml to temporary work around the issue to keep working?
[13:52] <sergiusens> ysionneau, use `snappy build` for now
[13:52] <ysionneau> ah, works, thanks!
[13:53] <kyrofa> ysionneau, note that will be going away soon, so move back to snapcraft once the bug is fixed
[13:53] <ysionneau> allright, noted, thanks!
[13:58] <ogra_> sigh .. no go
[13:58] <fgimenez> sergiusens, no idea, it seems that 3 of the failures are consistent in each execution. we have a new test image fwiw, iirc that caused problems previously
[14:00] <ysionneau> how can I make a kernel snap? any example?
[14:05] <kyrofa> ysionneau, did you see the new Snapcraft release announcement? And sergiusens blog post?
[14:07] <ysionneau> kyrofa: was it on snappy-devel ?
[14:07] <ysionneau> I subscribed to this ML on the 10th of feb
[14:08] <kyrofa> ysionneau, snappy-app-devel
[14:08] <ysionneau> ah, I should subscribe to this one then
[14:08] <kyrofa> ysionneau, indeed!
[14:08] <kyrofa> Check the archives, sent out about 10 hours ago
[14:08] <ysionneau> done.
[14:08] <ysionneau> thx
[14:09] <ysionneau> https://lists.ubuntu.com/archives/snappy-app-devel/2016-March/000645.html o/
[14:09] <ysionneau> awesome!!
[14:11] <sergiusens> ysionneau, bug reports welcome :-)
[14:11] <ysionneau> ah, you need to have snapcraft build your kernel, maybe I can hack something by creating a squashfs out of my already built kernel+modules+initrd
[14:12] <ysionneau> $ snapcraft --target-arch arm64 < !!!!!
[14:12] <ysionneau> --target-arch ? :)
[14:12] <ysionneau> so snapcraft is beginning to have some cross compilation notions ?
[14:12] <ogra_> ppisati, i dont really get it ... do you do anything special ?
[14:12] <ogra_> ppisati, i cant even get a burp out of the board with any uboot binary i build
[14:13] <ppisati> ogra_: raspi3, right?
[14:14] <ogra_> ppisati, yeah ... which compiler do you use ? just the gcc-5 eabihaf ?
[14:14] <ogra_> *hf
[14:16] <sergiusens> ysionneau, only for kernels
[14:17] <ysionneau> but can any other plugin get the --target-arch value?
[14:18] <ysionneau> I'll have a look anyway
[14:18] <ysionneau> it would be cool if I can make my Alchemy plugin use that
[14:18] <ysionneau> so that I don't need to set the TARGET_CPU via environmnent variable
[14:23] <ppisati> ogra_: don't you get to the uboot console?
[14:23] <ppisati> ogra_: i mean, nothing
[14:23] <ppisati> ogra_: zero output on the serial?
[14:23] <ogra_> nothing
[14:23] <ogra_> rightr
[14:23] <ppisati> ogra_: oh wait
[14:23] <ppisati> ogra_: is it the first time you use it?
[14:23] <ogra_> if i copy yours in place it gets me the console but obviously the snappy patches are missing
[14:24] <ogra_> yes
[14:24] <ogra_> copying mine back in place gets me total silence on the serial
[14:24] <ppisati> ok
[14:24] <ppisati> let me try to rebuild one
[14:25] <ogra_> mind throwing http://paste.ubuntu.com/15472180/ in ?
[14:25] <ogra_> ppisati, you are using the swarren rpi_dev branch ?
[14:25] <ppisati> yes
[14:26] <ogra_> and only --dtok as option to mkknlimg ?
[14:26] <ogra_> (ro also --283x=
[14:26] <ogra_> --283x)
[14:26] <ogra_> *or
[14:27] <ogra_> (though it doesnt seem to make any difference here )
[14:27] <ogra_> my only idea is that we use different compilers or so
[14:27] <sergiusens> kyrofa, fwiw, I see opencv failing now too (on the builders)
[14:28] <kyrofa> sergiusens, urgh. Do the builders update first?
[14:28] <sergiusens> ysionneau, implement set_target_machine in your plugin
[14:31] <sergiusens> kyrofa, we can ask elopio like live now :-)
[14:31] <kyrofa> sergiusens, good idea
[14:32] <kyrofa> elopio, standup?
[14:33] <ppisati> ogra_: i just compiled the tip of rpi-dev and uboot doesn't work here either
[14:33] <ogra_> aha
[14:35] <ogra_> do you knwo which commit you used ?
[14:36] <ppisati> ogra_: ok
[14:37] <ppisati> ogra_: git checkout -b rpi_dev_32bok f135e8f
[14:37] <ppisati> ogra_: make rpi_3_32b_defconfig
[14:37] <ppisati> ogra_: make ...
[14:37] <ppisati> ./mkknlimg --dtok --ddtk --283x u-boot/u-boot.bin myuboot.bin
[14:37] <ppisati> and it will work
[14:37] <ppisati> just tested
[14:38] <ppisati> either he broke 32bits or we are doing something wrong with the latest
[14:38] <ppisati> but this will work
[14:39] <ogra_> hmm git acts up
[14:41] <ogra_> ogra@styx:~/all-snaps/rpi3/u-boot$ LC_ALL=C git checkout -b rpi_dev_32bok f135e8f
[14:41] <ogra_> fatal: Cannot update paths and switch to branch 'rpi_dev_32bok' at the same time.
[14:41] <ogra_> Did you intend to checkout 'f135e8f' which can not be resolved as commit?
[14:42] <ogra_> ppisati, thats after a fresh: git clone git://github.com/swarren/u-boot.git
[14:43] <ppisati> ogra_: i wonder if he deleted that commit, and the corresponding object is not present in the upstream repo anymore
[14:43] <ogra_> :(
[14:43] <ppisati> ogra_: i can give you a copy of my uboot tree
[14:43] <ppisati> ogra_: until we find what's going on
[14:43] <ogra_> yes please ... just tar it up or so
[14:46] <ppisati> it's tarring...
[14:53] <ogra_> swamped under hot tar ?
[14:56] <ppisati> ogra_: http://people.canonical.com/~ppisati/u-boot.tgz
[14:56] <ogra_> thx !!!
[14:56] <ppisati> ogra_: today i got a new internet connection and a new router
[14:56] <ogra_> cool ... how fast ?
[14:56] <ppisati> ogra_: my firewall&c is a bit fucked up ATM
[14:56] <ppisati> 100Mbit / 50Mbit
[14:56]  * ogra_ just switcvhed to 50/10
[14:56] <ppisati> d / u
[14:57] <ogra_> the best i could get here
[14:57] <ogra_> (after 10 years with 2/2 ...)
[14:57] <ppisati> i guess you live far from a city
[14:57] <ogra_> i live in the middle of a city :P
[14:57] <ppisati> doh!
[14:57] <ppisati> :)
[14:57] <ogra_> germany is a third world country wrt internet speed
[14:58] <ppisati> you must something really bad to your isp then
[14:58] <ppisati> neeee
[14:58] <ppisati> italy is worst
[14:58] <ppisati> i justgot lucky
[14:58] <ppisati> i have FTTH
[14:58] <ogra_> we dont even have 2% fiber coverage afaik
[14:58] <ogra_> and DSL max speed is around 100MBit ... but you have to be lucky
[14:59] <ppisati> here vodafone is selling 300 / 30 fiber
[14:59] <ppisati> but i didn't want to switch isp
[14:59] <ogra_> (my wire could go up to 70 but then it would get shaky ... old cables ... )
[14:59] <Trevinho> ppisati: I told you to do that... :-)
[14:59] <ppisati> (now i'm on fastweb / swisscom)
[14:59] <ppisati> Trevinho: you have fweb too? or vodafone?
[14:59] <Trevinho> ppisati: vodafone, but using telecom actually.
[15:00] <Trevinho> ppisati: I mean, they've not their fiber network here yet (building atm)
[15:00] <ppisati> Trevinho: yeah, i was scared about downtime, etc
[15:00] <ppisati> Trevinho: so i got an upgrade from my existing isp
[15:00] <Trevinho> ppisati: i've to say it's reaaaaally good in that terms. I was worreid, but it's not like their bad adsl
[15:00] <ogra_> in most of germany the copper is still from the 70s ... i think thats the main prob
[15:01] <ppisati> ogra_: i think pretty much everywhere copper sucks
[15:01] <ppisati> ogra_: i must admit, having real fiber popping out of your wall is very nice :)
[15:01] <ogra_> yeah
[15:21] <ogra_> ppisati, ok, now i end up with FTD errors
[15:21] <ogra_> *FDT
[15:24] <ogra_> Hit any key to stop autoboot:  0
[15:24] <ogra_> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
[15:24] <ogra_> No FDT memory address configured. Please configure
[15:24] <ogra_> the FDT address via "fdt addr <address>" command.
[15:25] <ogra_> i got device_tree_address=0x02000000 in config.txt and also have my env set up to use fdt addr 0x02000000
[15:38] <ogra_> ppisati, do you have your uboot.env.in somewhere ?
[15:45] <ysionneau> sergiusens: it seems I need a snapcraft.cfg or something to use the kernel plugin?
[15:45] <ysionneau> or else the load_config will return {} and the  storeapi.download() will fail
[15:49] <sergiusens> ysionneau, oh, maybe a bug is in order; but you need to `snapcraft login` first
[15:50] <ysionneau> ah!
[15:50] <ppisati> ogra_: https://github.com/piso77/ubuntu-embedded/blob/master/boards/raspi3/rootfs/boot/firmware/uboot.env
[15:50] <ogra_> ppisati, i'm looking for the content, not the blob :)
[15:50] <ppisati> ogra_: heh :)
[15:50] <sergiusens> ysionneau, it's necessary to obtain the generic initrd found in the os snap
[15:51] <kyrofa> elopio, examples tests are still failing it seems
[15:51] <ysionneau> sergiusens: works after snapcraft login :) bear in mind I'm a snapcraft noob ! thx !
[15:51] <ppisati> ogra_: http://pastebin.ubuntu.com/15472788/
[15:51] <sergiusens> ysionneau, no worries; your bug reports will be welcomed as we want to provide the easiest experience possible
[15:51] <ppisati> ogra_: i'm out for a bit
[15:52] <ogra_> ppisati, ok, i cant seem to load any devicetree at all
[15:52] <ogra_> looks like you dont do anything different in your env
[15:52] <ppisati> ogra_: which firmware version are you using?
[15:53] <ogra_> ppisati, the one from your package in the "embedded" PPA
[15:53] <ppisati> ogra_: https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+sourcepub/6187265/+listing-archive-extra
[15:53] <ogra_> right, exactly that
[15:53] <ppisati> ogra_: and the dtb is called...
[15:53] <ppisati> bcm2710-rpi-3-b.dtb?
[15:53] <ogra_> and the dtb from the latest 4.4. kernel
[15:54] <ysionneau> sergiusens: cool :) done! https://bugs.launchpad.net/snapcraft/+bug/1560553
[15:54] <ogra_> (though by now i tried all of them upstream, our kernel, and from your test img)
[15:54] <ogra_> ppisati, right
[15:54] <ppisati> if you skip the dtb in memory, you load it from uyboot and pass it to the kernel
[15:54] <ppisati> ogra_: does it work?
[15:54] <ogra_> ah, we dont have a concept of that in snappy ... i'll try
[15:55] <ogra_> (we always use what the blob gives us in ram since we need overlay support)
[15:57] <ogra_> U-Boot> fatload mmc 0:1 ${fdt_addr_r} ${fdtfile}
[15:57] <ogra_> reading bcm2710-rpi-3-dtb
[15:57] <ogra_> ** Unable to read file bcm2710-rpi-3-dtb **
[15:57] <ogra_> hmm
[15:58] <ogra_> oh, copy paste messes up the uboot shell
[15:58] <ogra_> fun
[15:59] <ppisati> ah
[15:59] <ppisati> fuck me
[16:00] <ppisati> sudo ./mkknlimg --dtok ../../u-boot/u-boot.bin myuboot.bin
[16:00] <ppisati> fixed the uboot in memory problem for me
[16:00] <ppisati> try it out
[16:00]  * ppisati really rushes out now, biab
[16:00] <ppisati> ogra_: ^
[16:00] <ogra_> ok
[16:01] <sergiusens> elopio, fantastic :-/ http://<IP_ADDRESS>:8080/job/github-snapcraft-examples-tests-cloud/317/testReport/junit/test_busybox/BusyBoxTestCase/test_busybox/
[16:05] <kyrofa> sergiusens, that's the opencv error
[16:05] <kyrofa> sergiusens, so something isn't updated
[16:05] <elopio> cannot find /lib/x86_64-linux-gnu/libmvec.so.1
[16:06] <kyrofa> elopio, yeah, I fixed that by updating gcc g++ and libc6-dev
[16:07] <kyrofa> I assume it was actually libc though
[16:07] <elopio> kyrofa: sergio added apt-get upgrade.
[16:07] <elopio> ah E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
[16:08] <kyrofa> elopio, ah, so it didn't actually happen
[16:08] <elopio> fgimenez: do you have a good solution in mind to make sure that the slaves are always up-to-date before jobs run?
[16:09] <elopio> maybe a nightly redeploy?
[16:11] <elopio> sergiusens: that solution might not be too good, because it forces us to have one single execution at a time.
[16:11] <elopio> that means that if we have three PRs that want to run tests, the last one will have to wait like 2 or 3 hours.
[16:11] <sergiusens> elopio, what solution? the hackish thing I did?
[16:11] <elopio> yes, apt-get in the test script.
[16:12] <sergiusens> where should it go?
[16:12] <elopio> on the other hand, we are ok with only one apt-get upgrade per day-ish, so it's fine to let the other jobs fail when they can't get the lock.
[16:12] <elopio> sergiusens: I don't know, that was my question for fgimenez.
[16:13] <fgimenez> elopio, nightly redeploy sounds very good, that way we can make sure we have the versioned code up to date
[16:14] <elopio> fgimenez: we would have to trigger also the regeneration of the dockers, right?
[16:14] <fgimenez> we can begin with the current (and weak) validation and improve it as we find holes
[16:14] <sergiusens> elopio, fgimenez can we force a redeploy now?
[16:14] <elopio> sergiusens: I'm forcing an upgrade now.
[16:14] <sergiusens> ok, whatever gets the job done
[16:15] <fgimenez> elopio, the engine can stay, only the containers should be updated
[16:15] <elopio> redeploying when there's a queue of pending executions is not that good.
[16:15] <ogra_> crap
[16:16] <ogra_> bah, no mvo
[16:16] <fgimenez> elopio, but before any new redeploy we need to fix the extraction of the config.xml files of the jobs
[16:17] <elopio> fgimenez: you mean, removing the old and keeping just the new ones?
[16:17] <fgimenez> elopio, yep, keeping the ones that come with the container
[16:18] <elopio> ogra_: heads up that I'm enabling now the dput job from master. Could you do your thing after the new deb is in place so we get the new version in edge?
[16:18] <ogra_> elopio, what deb is that ?
[16:18] <ogra_> ubuntu-snappy(-cli) ?
[16:18] <elopio> ogra_: yes. take a look: http://<IP_ADDRESS>:8080/job/github-snappy-daily-ppa/
[16:19] <elopio> it's currently dputing to a test ppa. I've just changed it to do it from now on on the image ppa.
[16:19] <ogra_> elopio, hmm,. that shoudl go to the archive, no ?
[16:19] <ogra_> we are not supposed to use PPAs in 16.04
[16:20] <elopio> ogra_: for edge, I think we must use PPAs. I wouldn't want to put to the archive directly from master.
[16:20] <elopio> once we are ready to promote to stable it's when we should update the archive, I think.
[16:21] <ogra_> elopio, well, the ubuntui-core snap doesnt make a difference between edge/stable ... it is just building from the archive (which you can override from the PPA but we are supposed not to)
[16:21] <ogra_> we dont have any separate ubuntu-core snap build
[16:22] <elopio> ogra_: the edge you published yesterday was build from the image ppa, right?
[16:23] <ogra_> elopio, it has the PPA enabled but we removed all xenial packages from there
[16:23] <ogra_> (apart from the dragonboard kernel which will be moved ot the archive this week)
[16:24] <ogra_> elopio, the point is that we cant have PPA snappy in ubuntu-core when we release it ... this is the official snap
[16:24] <ogra_> we would need some ubuntu-core-edge snap for that ... that would mean to introduce a completely new product on cdimage
[16:24] <ogra_> (not really trivial)
[16:26] <elopio> ogra_: but, don't you agree that we shouldn't update the archive until we know that this snappy package is stable?
[16:26] <ogra_> elopio, we should, but we cant do the testing in the production snap
[16:27] <elopio> so, yes, we have a circular mess here.
[16:27] <ogra_> right
[16:28] <ogra_> we can indeed do it like you want until release
[16:28] <ogra_> after all the 16.04 ubuntu-core snap isnt officially released yet
[16:28] <ogra_> but the problem needs solving
[16:29] <elopio> ogra_: what if the PPA has only this ubuntu-snappy deb?
[16:29] <elopio> Then, we use the PPA only as a staging place for this deb, but is built using all the dependencies from the archive. Every day, we dput a new ubuntu-snappy to this ppa. Every day, you take this new ppa and build a snap. Every day, we publish this snap to edge.
[16:29] <elopio> Once we are ready to go to stable, we both promote the snap and push the deb into the archive?
[16:30] <ogra_> elopio, you would have to delete the deb from the PPA before we build the official snap
[16:30] <ogra_> each time
[16:32] <elopio> ok, there's a step missing. What I don't like is to have to generate a new snap. I want just to promote the same snap we put earlier into edge.
[16:32] <elopio> but that breaks your requirement of not using the ppa for the official snap.
[16:33] <sergiusens> elopio, there is no problem with putting a new snappy-cli in the archive
[16:33] <sergiusens> few will directly consume it
[16:33] <sergiusens> unless you really don't trust it; then automating this step is not really good
[16:33] <elopio> sergiusens: isn't it the same package that will be used for snappy-dimension on classic ?
[16:33] <sergiusens> they will in the end consume the snap
[16:34] <sergiusens> elopio, yes they will btw
[16:35] <elopio> I still don't like updating the archive once a day.
[16:35] <sergiusens> elopio, what shall we do with https://github.com/ubuntu-core/snapcraft/pull/388 ?
[16:35] <sergiusens> are we waiting on something?
[16:36] <elopio> ogra_: where does this no-ppa requirement come from? If the PPA only has the exactly same deb that will go to the archive, the result is the same when we use the ppa or the archive.
[16:36] <ogra_> elopio, sabdfl
[16:36] <ogra_> elopio, in 16.04 only the archive should be used
[16:36] <ogra_> updates only via SRU
[16:36] <sergiusens> elopio, the no PPA requirement makes perfect sense; it should have never been a PPA
[16:36] <elopio> sergiusens: we are waiting on the slaves to dist-upgrade
[16:37] <sergiusens> elopio, ah, ok, thanks :-)
[16:37] <elopio> but if we want a daily edge, then we would have to SRU every day.
[16:38] <ogra_> elopio, which wont fly with the SRU rules :)
[16:38] <ogra_> SRUs need to stay 2 weeks in quarantaine
[16:39]  * ysionneau flooding bugs
[16:39] <elopio> so that makes it even bad if we don't want a daily edge.
[16:39] <sergiusens> ysionneau, what else did you find?
[16:39] <ysionneau> https://bugs.launchpad.net/snapcraft/+bug/1560570
[16:39] <elopio> let's say we have a two week cycle. At the end of the second week we want to release, but we will have to put the version for two weeks in quarantine
[16:39] <ogra_> elopio, well, we would need to have a whole cdimage setup for an ubuntu-core-edge
[16:40] <ysionneau> https://bugs.launchpad.net/snapcraft/+bug/1560569
[16:40] <ogra_> elopio, which is possible but quite some work, nothing i can "just do"
[16:40] <elopio> ogra_: but I also don't want an ubuntu-core-edge. I just want the same package to be promoted from edge -> stable
[16:43] <ogra_> elopio, well, then your daily builds need to go to the archive
[16:43] <elopio> ogra_: I think that for me, the least bad option of what you told me is to generate the edge snap from the ppa. Once we are ready to move to stable, put the deb into the archive and generate the stable snap from the archive.
[16:44] <elopio> it kind of invalidates part of the testing we do during the week, but it's not terrible.
[16:44] <elopio> all the other options look worse to me. ogra_: what's your prefered option?
[16:44] <ogra_> well, not using the PPA :)
[16:45] <ogra_> or getting permission to use it all the time ...
[16:45] <elopio> ogra_: so with not using the PPA do you mean, daily pushes to the archive, or no daily edge?
[16:45] <ogra_> daily to the archive
[16:46] <ogra_> but that wont fly witgh the SRU policy
[16:47] <elopio> ok, I'll send an email. sergiusens: does what I said make sense to you? Or am I missing another requirement here?
[16:49] <sergiusens> ogra_ and ppisati, can you comment on https://bugs.launchpad.net/snapcraft/+bug/1560570 please. I feel estranged
[16:50] <ysionneau> or maybe it's just a need for tegra (x1?) kernels ?
[16:50] <ysionneau> but by looking at the file path, it seems arm64 generic
[16:50] <ogra_> sergiusens, i'll leave that to ppisati
[16:50] <sergiusens> ysionneau, it confuses me since I'm not a kernel guy and I see 64bit and 32bit mixups in there
[16:50] <ysionneau> yep
[16:50] <ysionneau> but I can confirm that in our build system we also set CROSS32CC
[16:51] <ogra_> ysionneau, any reason to not use an aarch64 gcc ?
[16:51] <ysionneau> it's consistent with the web link I've put
[16:51] <sergiusens> ysionneau, seems hackish tbh
[16:51] <sergiusens> ogra_, https://devtalk.nvidia.com/default/topic/894945/jetson-tx1/jetson-tx1/post/4742474/#4742474
[16:51] <ysionneau> ogra_: no idea, it's what we use here and it's also what's on the web link
[16:51] <ysionneau> the kernel is compiled using aarch64 toolchain, but a few parts are compiled using "VDSO32C" makefile variable
[16:52] <ysionneau> which is set from CROSS32CC
[16:53] <ogra_> oh my
[16:53]  * ogra_ agress with sergiusens ... seems hackish
[16:53] <ysionneau> or maybe ... https://android.googlesource.com/kernel/tegra/+/android-tegra-flounder-3.10-lollipop-release/arch/powerpc/Makefile
[16:54] <ysionneau> do something like CROSS32CC = $(CC) -m32
[16:54] <sergiusens> ysionneau, yeah, powerpc is 32bit :-)
[16:55] <ogra_> ppc32tegra ?
[16:55] <ogra_> :)
[16:55] <ysionneau> o/
[16:56] <ysionneau> only source I find for this hack is https://devtalk.nvidia.com/default/topic/917802/issue-with-building-nvidia-kernel-for-tx1/ and https://devtalk.nvidia.com/default/topic/923810/jetson-tx1/rebuilding-the-tegra-tx1-kernel-from-source/
[16:57] <sergiusens> ysionneau, fwiw I marked this invalid as you can solve it in your snapcraft.yaml https://bugs.launchpad.net/snapcraft/+bug/1560569
[16:58] <kyrofa> sergiusens, elopio still waiting on the upgrade? How are you guys seeing that, anyway?
[16:58] <sergiusens> kyrofa, I can't see anything; I'm shooting blanks ;-)
[16:58] <sergiusens> err, shooting in the dark :-)
[16:59] <kyrofa> sergiusens, well, where did you put the dist-upgrade in the first place?
[16:59] <ysionneau> sergiusens: arg sorry!
[16:59] <kyrofa> sergiusens, or was that in that one git repo?
[16:59] <elopio> kyrofa: I'm dealing with the last slave.
[16:59] <sergiusens> kyrofa, inside the jenkins instance; but they removed that in favor of something else
[16:59] <elopio> I found the problem: libc-dev-bin : Depends: libc6 (> 2.23) but 2.21-0ubuntu6 is installed
[17:00] <sergiusens> elopio, dist-upgrade?
[17:00] <sergiusens> ysionneau, no worries
[17:00] <ogra_> ppisati, http://paste.ubuntu.com/15473201/ ... but sadly it hangs there (with blinking cursor though)
[17:00] <elopio> sergiusens: yes, solved with install -f and dist-upgraded again.
[17:00] <elopio> should be done soon.
[17:00] <sergiusens> ysionneau, I still have to think about that CC thing; you can do it from the outside (as in `CCXXXX=xxxx snapcraft --target arm64`) if you want
[17:01] <ysionneau> yes for now I do export it from my shell before running snapcraft
[17:01] <ysionneau> it's not a blocker for me
[17:01] <ysionneau> I have to confess I'm not a Tegra kernel export either ... so I don't know if it's a good thing for you to integrate that
[17:01] <sergiusens> ysionneau, k; I'll leave the bug open in case more people run into it; this one I guess will go in if the population seeing it is huge
[17:01] <ysionneau> but I need it to compile
[17:02] <ysionneau> btw I've tried -m32 from aarch64 toolchain, does not seem OK :o
[17:02] <sergiusens> ysionneau, from the bc thing and others it seems it is an android kernel this is based out of
[17:02] <ysionneau> let me ask but it's highy probable
[17:03] <ysionneau> at least I see some android merges in the git history
[17:07] <sergiusens> ysionneau, thought so :-)
[17:08] <sergiusens> elopio, so are we good?
[17:08]  * sergiusens is getting anxious ;-)
[17:08] <sergiusens> I bet kyrofa is too
[17:08]  * kyrofa is indeed, he has all sorts of stuff queued up
[17:08] <elopio> sergiusens: good, but the slave is still unpacking debs.
[17:09] <elopio> they are slow. Maybe we should use the slaves only to direct scripts to scalingstack instances.
[17:11] <elopio> ok, done. I'm retesting my branch.
[17:14] <kyrofa> Thanks elopio! Hopefully that fixes things
[17:15] <ysionneau> allright, kernel snap is done o/
[17:19] <ysionneau> sergiusens: your kernel plugin works well o/ thanks!
[17:41] <ysionneau> any idea what this could be? http://paste.ubuntu.com/15473724/
[17:46] <ogra_> ysionneau, you dont need --developer-mode with the all-snaps u-d-f
[17:46] <ogra_> tough the issue looks like something with your gadget
[17:49] <Laney> snappy friends
[17:50] <Laney> I was looking at doing the seed change for xenial that you are asking for
[17:50] <Laney> but... https://paste.ubuntu.com/15473751/
[17:50] <ogra_> Chipaca, ^^
[17:50] <ogra_> i assume they would rather seed ubuntu-snappy-cli to not get the systemd services installed
[17:50] <ogra_> s/would/should/
[17:52] <sergiusens_> elopio, kyrofa we are back in business
[17:52] <kyrofa> sergiusens_, YES!
[17:52] <ogra_> you business people you
[17:54] <elopio> \o/
[17:55] <Laney> ogra_: I'm off in 5 minutes - maybe you can execute the seed/meta change when someone waks up?
[17:55] <Laney> https://bugs.launchpad.net/ubuntu/+source/ubuntu-snappy/+bug/1548887
[17:55] <ogra_> Laney, well, *if* someone wakes up
[17:56] <Laney> sure
[17:56] <ogra_> not sure if mvo planned to come back today ... and Chipaca's IRC client is a zombie since the telegram group exists
[17:57] <Laney> It's really weird
[17:57] <ogra_> (would really be nice if he could just shut it down)
[17:57] <Laney> sometimes this seems urgent
[17:57] <Laney> but nobody is actually pushing the change
[17:57] <Laney> so I don't really understand what's going on tbh
[17:58] <ogra_> well, i think it is just the wrong package ... i suggested -cli before but smoser said he'd like ubuntu-snappy instaed
[17:58] <ogra_> i think the systemd units come from the ubuntu-snappy package and -cli will omit them ...
[17:58] <Laney> mvo re-confirmed on the bug after I asked
[17:58] <ogra_> you definitely do not want them
[17:59] <Laney> was assuming that having it on the beta is a good thing
[17:59] <Laney> but hey ho
[17:59] <ogra_> yeah, it would be
[17:59] <ogra_> but if you cant reach anyone who can make that decision ...
[17:59] <Laney> nobody is chasing though
[18:00] <Laney> and they're apparently asking for the wrong thing
[18:00] <Laney> so ?!?!?!
[18:00] <ogra_> *shrug*
[18:00] <Laney> you see what I mean :P
[18:00] <ysionneau> btw where can I fetch the os snap? (or do I need to generate it? how?)
[18:00] <ysionneau> I used the os.snap which appeared in my kernel snap parts dir
[18:00] <ogra_> ysionneau, http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
[18:00] <ogra_> just grab the one for your arch
[18:01] <ysionneau> should it be the arch of the kernel or user space?
[18:01] <ogra_> or simply use: -os ubuntu-core.canonical
[18:01] <ogra_> that will pull the last released one from the store
[18:01] <sergiusens_> ogra_, no need for .canonical iirc
[18:01] <ogra_> oh ?
[18:01] <ogra_> when was that dropped ?
[18:01] <jdstrand> kgunn: is it possible to test the mir snap in a qemu vm?
[18:02] <sergiusens_> ogra_, not dropped; it is optional
[18:02] <ogra_> well, it used to be mandatory for a while :)
[18:02] <ysionneau> not sure what's wrong with my gadget snap
[18:02] <sergiusens_> jdstrand, using virt-manager it is easier; you need a different display
[18:02] <sergiusens_> ogra_, we setup an alias :-
[18:02] <sergiusens_> :-)
[18:02] <ogra_> ah
[18:02] <Chipaca> looking...
[18:02] <ogra_> Chipaca, !
[18:02] <ogra_> alive !
[18:02] <Chipaca> ogra_, not a zombie! just even more lagged
[18:02] <ogra_> :D
[18:03] <ysionneau> http://paste.ubuntu.com/15473862/ here is my meta.yaml
[18:03] <jdstrand> sergiusens_: you're saying it will work in virt-manager?
[18:03] <Chipaca> people always ping me at 6pm :-(
[18:03] <ysionneau> 19:01 < ogra_> or simply use: -os ubuntu-core.canonical < ok!
[18:03] <Chipaca> um
[18:03] <ogra_> ysionneau, that will just produce an empty gadget
[18:03] <ogra_> you dont define any files
[18:03] <Chipaca> i don't think you should install those services on a system with apt-get
[18:03] <kgunn> jdstrand: right, that's my understanding is that other vm's don't have nicely configured display/gfx stacks
[18:04] <jdstrand> I can use virt-manager all day :)
[18:04] <jdstrand> ok, thanks
[18:04] <ogra_> Chipaca, thats why i suggested to seed -cli instead
[18:05] <ogra_> (assuming that doesnt ship the units)
[18:05] <kgunn> jdstrand: curious, you just getting around to display-server policy stuff?
[18:05] <Chipaca> this is mvo territory i'm afraid
[18:05] <ogra_> then we have to wait i guess
[18:07] <jdstrand> kgunn: sadly no. still blocked, but hopefully soon
[18:07] <jdstrand> I wanted to test a launcher change
[18:07] <kgunn> ok, lemme know if you have any probs
[18:08] <Chipaca> ogra_, i've not looked in to what's needed; it might be ubuntu-snappy itself, with the services adhoc-disabled somehow
[18:08] <Chipaca> i've just never had to look :-)
[18:08] <ogra_> heh, same here
[18:10] <Chipaca> i'd love to *know*, of course, but my bandwidth is only so much
[18:10] <ysionneau> ogra_: I think I'm fine with an empty gadget for now
[18:10] <ogra_> ysionneau, but ubuntu-devicel-flash isnt :)
[18:10] <ysionneau> ok =)
[18:11] <ogra_> you use the ubuntu-device-flash binary from mvo's all-snaps dir ?
[18:11] <ysionneau> yes
[18:11] <Chipaca> ok, back to making dinner for me
[18:12] <ogra_> Chipaca, enjoy
[18:12] <ysionneau> ah indeed I've put a dummy file and now it goes forward to the next error
[18:12] <ogra_> good
[18:12] <ysionneau> ../paros_gadget/paros_1.0_all.snap failed to install: exit status 2
[18:12] <ysionneau> o/
[18:12] <ysionneau> maybe it should be absolute path
[18:13] <ysionneau> nop, same
[18:13] <ogra_> no, its the content
[18:14] <ogra_> so you have a dtb file thats called tegra-x1 ?
[18:14] <ysionneau> no
[18:14] <ysionneau> stat("/tmp/diskimage828293005/tegra-x1.dtb", 0xc8202e0448) = -1 ENOENT (No such file or directory) <= indeed
[18:14] <ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/pi2/meta/snap.yaml
[18:15] <ogra_> have a look at that file
[18:15] <ysionneau> yes I based my snap from this and from the gadget documentation
[18:15] <ogra_> you need the boot-assets ... and your platform entry should be the same as your dtb
[18:15] <ysionneau> allright, let's do this
[18:17] <ysionneau> maybe this field should be renamed "dtb" instead of platform :o
[18:17] <ysionneau> so that it's more clear what you are supposed to put
[18:17] <ogra_> well, the gadget is supposed to becompletely re-worked (i learned today) ...
[18:19] <ysionneau> ahah, ok
[18:24] <ogra_> elopio, so whatever we'll do with the PPA stuff, lets for now just do it as you said ... (and perhaps start a mail discussion about how we want to finally fix this process) ... and let me know when i should hit the button for a build
[18:24] <ogra_> we are still in pre-release after all
[18:25] <elopio> ogra_: I sent the mail. Let me dput...
[18:25]  * ogra_ doesnt want to be the blocker
[18:32] <elopio> ogra_: oh, you are not at all. We just need to finish the details of how to connect everything.
[18:32] <elopio> ogra_: in his update from yesterday, mvo added a changelog entry for the upload. Should I do that?
[18:33] <elopio> with my current dch, I get a version that's lower than his.
[18:34] <ogra_> then it wont be pulled in
[18:34] <ogra_> you need a higher version
[18:35] <ogra_> (livecd-rootfs is dumb ... it just pulls the latest available versions)
[18:43] <jdstrand> kgunn: so, I installed it and rebooted and see this in the logs: http://paste.ubuntu.com/15474097/
[18:44] <jdstrand> kgunn: I'm using 'vmvga': http://paste.ubuntu.com/15474110/
[18:44] <jdstrand> this is the same setup I would use to run unity7
[18:44] <elopio> ogra_: no, that makes sense. But what's the trick to get a version number like 1.7.3+20160322ubuntu1~ppa3 automatically?
[18:45] <elopio> I'm not sure how to increase the date of the previous entry.
[18:46] <kgunn> jdstrand: hmmm....fails on the vt arg
[18:46] <jdstrand> kgunn: this is on 16.04. is there a mir snap in the store for 15.04?
[18:46] <jdstrand> I can try there too
[18:47] <kgunn> jdstrand: i took down the 15.04 one i think
[18:47] <jdstrand> that would explain why I couldn't snappy search it
[18:47] <jdstrand> is https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ up to date?
[18:47] <kgunn> jdstrand: yes
[18:48] <kgunn> jdstrand: and i just now tested against snapcraft2.5
[18:48] <kgunn> and it worked fine
[18:48] <jdstrand> kgunn: do you have a vm where this works? if so, can you paste 'virsh dumpxml <vmname>'
[18:49] <jdstrand> kgunn: I downloaded the mir from the store. should I be using snapcraft like in the instructions?
[18:49] <kgunn> jdstrand: nah, that snap should work fine
[18:49] <kgunn> jdstrand: i'm using Virtual Machine Manager
[18:49] <kgunn> which
[18:49] <jdstrand> yeah that's fine
[18:49] <jdstrand> what is the name of the vm?
[18:50] <jdstrand> in a terminal you should be able to do 'virsh list --all'
[18:50] <jdstrand> to see the names
[18:50] <ogra_> elopio, you dont want to increase the date but turn ubuntu1 to ubuntu2
[18:50] <jdstrand> then if you could paste 'virsh dumpxml <your vm name>' that would be great
[18:50] <ogra_> (that is what will effectively land in the archive)
[18:51] <elopio> ogra_: that's easy, with -i. But that would still be less than the one mvo uploaded. Should I delete that deb?
[18:51] <jdstrand> kgunn: ^
[18:51] <kgunn> jdstrand: https://pastebin.canonical.com/152534/
[18:52] <jdstrand> ah qxl
[18:52] <jdstrand> kgunn: thanks!
[18:52] <elopio> ogra_: also I can't combine -i, with the --local to add the prefix ppa# that mvo told me to use.
[18:52] <elopio> these tools...
[18:56] <jdstrand> kgunn: ok, progress. a black screen :)
[18:57]  * jdstrand builds the mir client snap
[19:02] <kgunn> ;)
[19:08] <jdstrand> I have clocks :)
[19:08] <jdstrand> kgunn: ^
[19:09] <kgunn> i assumed you ooo'd and awww'd
[19:09] <jdstrand> kgunn: curious if it makes sense to upload mir-client-demo or soemthing
[19:09] <ogra_> elopio, well, you could assemble the version externally and just pass it to dch
[19:09] <jdstrand> kgunn: it is very cool-- I did! :)
[19:13] <elopio> ogra_: yes, I went that way. Failed to build on armhf, I'm reporting a bug.
[19:13] <ogra_> elopio, fun
[19:21]  * ogra_ calls it a day
[19:25] <elopio> have a good night ogra_!
[19:25] <ogra_> and you a good rest of the day :)
[20:10] <kyrofa> elopio, is sergio off for a bit?
[20:11] <elopio> kyrofa: I didn't notice when he left. Maybe lunch?
[20:12] <kyrofa> elopio, he pinged out a bit ago. Yeah, maybe
[20:13] <elopio> kyrofa: I'm about to take a lunch break too. I quickly saw your clean branch, which looks awesome
[20:14] <elopio> I'll look at it all when I'm back.
[20:14] <kyrofa> elopio, oh good! Excellent, thank you :) . I've got some more ready when that one lands
[20:14] <elopio> kyrofa: this state, partial clean and resume look nice. What do you think about putting some integration tests in there?
[20:15] <kyrofa> elopio, yeah I'll do that when things are actually cleaned (that PR is just preliminary stuff)
[20:16] <elopio> great. To be clear, I'm not asking for this branch :)
[20:16] <elopio> we can define some important use cases, and make sure that the binaries work for them with tests. Maybe leave that for next week, and I'll help you writing some.
[20:24] <kyrofa> Sounds good
[20:31] <ezraholm50_TAM> hey guys, could anyone help me get webmin running on snappy?
[20:37] <genii> !webmin
[20:38] <genii> ...so probably not
[20:45] <ezraholm50_TAM> ah great... thnx for the heads up
[20:45] <ezraholm50_TAM> anyway, aside from snap, it works great on my 5 ubuntu 14 to 16 systems
[20:46] <ezraholm50_TAM> i just need to easily figure out some stuff that i would rather do with some kind of a UI then on cmd line
[20:46] <ezraholm50_TAM> checking out deb2snap right now
[20:57] <roadmr> is there a way to get "snapcraft snap" to rebuild if files changed? Right now I have to rm -rf parts stage which feels super kludgy
[21:04] <kyrofa> roadmr, indeed, it's yucky. Unfortunately not just yet, but it's in progress
[21:10] <roadmr> kyrofa: thanks :) I can do it that way in the meanwhile, no problem
[21:13] <roadmr> is there a way to run a command at snap installation time? use case is e.g. a custom ssh server for which I'd like to generate keys when the snap is installed (rather than shipping the same set of keys to every user :)
[21:15] <kyrofa> roadmr, no, but you can check to see if keys already exist, and if not, generate them
[21:25] <roadmr> kyrofa: that works! thanks :)


[00:00] <snadge> ive just gotten used to the "new" way of doing it.. and its been reverted ;)
[00:02] <Daekdroom> Why the hell do you ask that every time?
[00:14] <snadge> i just wanna know if its gonna get changed again
[00:14] <snadge> or what the story is
[01:01] <thumper> snadge: as far as I'm aware, it was decided to revert back
[01:04] <snadge> but i thought this was related to super being used for the help popup
[01:04] <snadge> the help popup doesnt reflect the reversion either.. it still says shift/alt super
[01:35] <Daekdroom> Does anyone here know if there's a bug report regarding sometimes when you drag icons from Launcher, they will sort of "get stuck" somewhere?
[01:59] <thumper> snadge: mine doesn't, I'm pretty sure it is getting it from compiz-config
[01:59] <thumper> snadge: although perhaps just once, I've not checked
[01:59] <thumper> Daekdroom: stuck where?
[01:59]  * thumper has school run
[02:01] <glosoli> LIM is by default included in Precise silently ?
[02:03] <Daekdroom> thumper, wherever near Launcher I release the cursor.
[02:03] <Daekdroom> Let me get a screenshot
[02:04] <Daekdroom> Interesting. It fixed itself a few seconds after I got the screenie :P
[02:05] <snadge> i had to unity --reset to get the keyboard shortcut reversion
[02:05] <Daekdroom> http://imagebin.org/202036
[02:05] <snadge> it looks like you can configure it from both settings -> keyboard or ccsm
[02:06] <snadge> hopefully those configuration settings refer to the same thing ;)
[02:13] <thumper> Daekdroom: what are your steps to reproduce?
[02:13] <Daekdroom> thumper, play with drag n dropping icons in the Launcher until it messes up.
[02:18] <thumper> Daekdroom: hmm, I don't see it...
[02:18] <thumper> Daekdroom: what does "apt-cache policy unity" say?
[02:19] <thumper> Daekdroom: this could be one of the recent fixes
[02:19] <Daekdroom>   Instalado: 5.4.0+bzr2047ubuntu0+654
[02:20] <thumper> hmm...
[03:04] <Daekdroom> I can't find any way to reproduce it. It just happens sometimes.
[08:21] <bschaefer> mhr3, hey, good morning. I have fixed those issues and it now has a nice autopilot test. For: https://code.launchpad.net/~brandontschaefer/unity/fix-711199/+merge/89192
[08:22] <mhr3> bschaefer, yea, i saw it, very nice work
[08:22] <mhr3> there's still one issue though, lenses can push results even when there's no search
[08:23] <bschaefer> mhr3, o really?
[08:23] <mhr3> so what can happen is that you'll be displaying "no results" and there in fact will be results
[08:23] <bschaefer> mhr3, hmm, do you know of an example where that is the case?
[08:24] <mhr3> bschaefer, if could happen in the home lens for example
[08:25] <bschaefer> mhr3, does SearchChange get emited when that happens?
[08:25] <mhr3> say you have a new user account, so there will be nothing recent, but once you run something the lens will update even without search to show the app you just run
[08:26] <mhr3> not really, just the results model / results view will be updated
[08:27] <mhr3> bschaefer, but it's quite corner-case scenario, i'm not going to block the merge on that, still it should be fixed
[08:27] <bschaefer> mhr3, hmm, yes agree!
[08:27] <bschaefer> mhr3, I was thinking, if it was possible to 'text_changed.emit()'
[08:27] <bschaefer> that will cause it to fire of that timer I have
[08:28] <bschaefer> mhr3 I have to look at that code, as im not familiar with it as much though
[08:28] <mhr3> hmm doesn't sound like a clean solution to me
[08:29] <bschaefer> mhr3, yeah, cause anytime an update happens it will emit that...
[08:29] <bschaefer> hence endless loop
[08:29] <bschaefer> hmm, well Ill look into that more
[08:29] <bschaefer> its getting a little late here
[08:30] <mhr3> probably 5.8 stuff :)
[08:30] <bschaefer> mhr3, yes sounds good!
[08:30] <bschaefer> mhr3, thanks for all your help and work for this :)
[08:31] <mhr3> thank you ;)
[08:31] <bschaefer> mhr3, have a good night, ill get thumper to approve it in the morning and hopefully you can see it soon :)
[08:31] <bschaefer> well my morning haha
[08:32] <bschaefer> mhr3, have a good day!
[08:32] <mhr3> bschaefer, good night to you :)
[08:36] <Saviq> didrocks, hey, pinging you to remember about "unity-common" for unity-2d on unity-merger
[08:37] <didrocks> Saviq: hum, didn't I say in the end that's maybe a bad idea?
[08:37] <didrocks> Saviq: let me rethink
[08:37] <didrocks> Saviq: some of your tests are depending on some assets, right?
[08:37] <didrocks> Saviq: or is it something else?
[08:38] <Saviq> didrocks, the tests depend on the Unity dconf schema to be installed
[08:38] <didrocks> Saviq: yeah, so maybe you can ping mhr3 and kamstrup, they did some kind of "mock gsettings" for similar cases
[08:39] <didrocks> Saviq: which seems more correct to me
[08:40] <Saviq> didrocks, truth is we don't care about gsettings or what the schema contains, just that it is there, but yeah, mocking the schema might work, too
[08:41] <didrocks> Saviq: seems a safer option to me in correctness as well as in build-depends and build-time (installing rdepends) ones, wdyt?
[08:41] <mhr3> afaik we dont mock gsettings, we wanted at some point, but dropped it
[08:41] <didrocks> mhr3: oh? I was thinking the work was finished here?
[08:42] <Saviq> didrocks, true, I could try and set GSETTINGS_SCHEMA_DIR to our own copy
[08:42] <didrocks> Saviq: seems better :)
[08:42] <mhr3> didrocks, no, there's many things you can do with gsettings, but pretending you have a schema which you don't isn't one of them
[08:43] <didrocks> mhr3: hum, even with the dconf gkeyfile backend?
[08:43] <mhr3> even
[08:56] <didrocks> greyback: Saviq: unity-2d uploaded built against unity 5.6 btw, unfreezing now -2d :)
[08:56] <Saviq> didrocks, awesome
[08:56] <greyback> didrocks: yay
[09:54] <angeloc> kamstrup, mhr3: merge proposal 95591 done!
[09:56] <angeloc> kamstrup, mhr3: opening sftp:// from dash is amazing!
[10:11] <Saviq> didrocks, ssoo... not sure how to proceed, tried having a local set of gschemas but the tests use the running instance that doesn't know about my GSETTINGS_SCHEMA_DIR, so unless I actually do install the schema I can't fake it, as mhr3 said
[10:11] <didrocks> Saviq: I would surely ask desrt once he's around (he's generally on #ubuntu-desktop, will be here I guess in 4 hours)
[10:12] <Saviq> didrocks, ok will do
[10:15] <mhr3> Saviq, well if you do have the schema at hand it should be possible to just use keyfile backend as didrocks said, the problem is when you dont have the schema
[10:16] <Saviq> mhr3, TBH in my case I just need to fake the schema being there, it's empty and that's enough, but it needs to be installed
[10:17] <Saviq> so yeah, keyfile might work, need to check
[10:25] <mhr3> Saviq, just try setting GSETTINGS_BACKEND=memory
[10:26] <Saviq> mhr3, that might work!
[10:57] <angeloc_>  mhr3: have you seen the patch?
[11:02] <mhr3> angeloc, on my todo
[11:03] <angeloc> mhr3: great news! thank you!
[11:08] <mhr3> angeloc, btw what the agreement? did you sign it yet?
[11:09] <mhr3> what about*
[11:09] <angeloc> mhr3: yes, but htere was a bug on the contributor agreement web page, wich I signalled and was fixed this morning
[11:09] <angeloc> mhr3: but finally I did it!
[11:10] <angeloc> mhr3: what's *?
[11:11] <mhr3> angeloc, i see two issues - pls dont use underscores in enum names
[11:12] <angeloc> mhr3: so sorry... there is a guideline for vala somewhere?
[11:13] <mhr3> you're also using tabs and it's just eeeh :P (spaces only pls)
[11:14] <angeloc> mhr3: yes, i have some glitches with my editor, i'll fix them as soon as possible
[11:16] <mhr3> angeloc, and last thing, i touched the same part of code you did, so there'll be conflicts, it'd be nice if you could merge lp:~mhr3/unity-lens-files/fix-921665 and set it as prereq for the branch
[11:17] <angeloc> mh3r: minchia (Italian approving expression), ok, this is a little bit more difficult, but extremely entertaining!
[11:17] <mhr3> angeloc, i like that you're up for some challenge ;)
[11:18] <angeloc> mhr3:I'm really addicted, Ubuntu development rocks!
[11:20] <mhr3> angeloc, also please use uri_regex instead of normal_regex, "normal" is very ambigous ;)
[11:20] <angeloc> mhr3: I had a suspect ...
[11:20] <mhr3> eeh, i meant web_regex
[11:20] <mhr3> all of those are uris :)
[13:26] <Andy80_> Trevinho: here you have the lspci output http://pastebin.com/mM7YWgH4
[13:28] <Andy80_> Trevinho: http://pastebin.com/g2FbhaNB
[13:30] <Trevinho> il modello esatto del computer lo sai?
[13:30]  * Trevinho sorry
[14:19] <tbf> what's that? with unity 5.4.0+bzr2047ubuntu0+654 gtk apps keep their main menu attached...
[14:19] <tbf> ...hopefully not intended.
[14:23] <Daekdroom> What do you mean by main menu attached?
[14:34] <tbf> Daekdroom: they still appear in the application window...
[14:34] <tbf> Daekdroom: oddly they also get mirrored to the indicator panel
[14:34] <tbf> therefore communication seems to work at least
[14:35] <Daekdroom> I have that version installed and it's working alright over here.
[14:35] <tbf> hmm. odd.
[15:10] <gord> mhr3, is it just me or is test_filesystem_lenses completely non working?
[15:11] <mhr3> gord, i hope it's just you :P
[15:12] <gord> mhr3, me too ;) for me it gets stuck in TestLensesAdded waiting for the lenses to load then times out - which for some reason causes gtest to not run the rest of the tests
[15:13] <mhr3> let me check
[15:14] <mhr3> gord, eeh
[15:15] <mhr3> task-1: [ RUN      ] TestFilesystemLenses.TestFileLoading
[15:15] <mhr3> ?
[15:16] <gord> mhr3, task-1: [ RUN      ] TestFilesystemLenses.TestLensesAdded
[15:16] <gord> TestFileLoading passes
[15:16] <gord> oh wait no fails
[15:16] <mhr3> it doesn't here :P
[15:16] <gord> task-1: [  FAILED  ] TestFilesystemLenses.TestFileLoading (11 ms)
[15:16] <mhr3> what the hell broke it
[15:16] <gord> task-1: unknown file: Failure
[15:16] <gord> task-1: C++ exception with description "std::bad_alloc" thrown in the test body.
[15:28] <mhr3> gord, it's starting to smell like corrupted stack to me
[15:40] <gord> mhr3, disabling the category tests (frequent causer of problems) leaves me with no errors, it just times out trying to load the lenses, i'd assume in WaitForLensesToLoad
[15:41] <mhr3> gord, if the waiting for load times out it's expected to crash (cause the stack variable with the lenses goes away)
[15:41] <mhr3> but why does it time out?
[15:44] <mhr3> oh god, pls tell me it's not because of timeout_add_seconds
[15:44] <mhr3> why the hell would you use that in tests...
[15:50] <gord> mhr3, flipping on debug, it does seem to load all the test lenses just fine
[15:50] <gord> apart from the ones designed to fail obviously
[15:53] <mhr3> i hate when tests are more flaky than the actual code
[16:09] <tsdgeos> didrocks: i'm confused about you asking for that DEP-3 thing for my metacity patch, none of the metacity patches have that
[16:10] <didrocks> tsdgeos: probably because most of them are debian patches and it really depends on the maintainer
[16:10] <tsdgeos> oh
[16:10] <tsdgeos> actually some do
[16:11] <didrocks> tsdgeos: but for most of the work we do in the ubuntu desktop team, we try to have them, especially when it's not obvious or we know it will be maintained for a long time
[16:17] <tsdgeos> didrocks: i've added the comments
[16:25] <didrocks> tsdgeos: thanks :)
[16:43] <kelemengabor> hi, could someone merge the branch proposed for https://bugs.launchpad.net/unity/+bug/923762 ?
[16:53] <gord> mhr3, ^^ re-review of kelemengabor's branch please?
[17:05] <mhr3> gord, review of https://code.launchpad.net/~mhr3/unity/safer-tests/+merge/95949 please?
[17:05] <mhr3> kelemengabor, gord, it looks good
[17:05] <mhr3> but last time didrocks was shouting, right? :)
[17:05] <mhr3> so let's have him take a look at it first
[17:05] <gord> mhr3, sure, will give it a spin
[17:06] <didrocks> mhr3: hum, shouting, for what? :)
[17:06] <didrocks> mhr3: no, just make the refresh of the .pot file a separate merge req, that's all :)
[17:06] <mhr3> didrocks, dunno, isn't that what you do all the time? :P
[17:06] <didrocks> (with the udpated POTFILES.in
[17:06] <didrocks> just don't mix it with other changes :)
[17:06] <didrocks> mhr3: come on!
[17:07] <didrocks> mhr3: it's just you guys who like to make me work 12 hours a day :p
[17:07] <mhr3> didrocks, we just know you love your job to we want you to enjoy every bit of it ;)
[17:07] <didrocks> :p
[17:08] <mhr3> didrocks, anyway, since the branch just updates potfiles.in and .skip isn't fine, right?
[17:09] <didrocks> mhr3: will be great to update then in the same or just another branch the templates
[17:09] <didrocks> so that you, as upstream, avoid ending up with a lot of translation updates in a feature/bug fix branch
[17:09] <gord> mhr3, yaay, test works again :)
[17:10] <mhr3> gord, seems like the signal was the culprit
[17:10] <mhr3> didrocks, you're so nice to us, we don't deserve you
[17:11] <didrocks> mhr3: that's what everyone is telling me everyday </kidding> ;)
[17:11] <didrocks> I'm just your mother it seems some times :)
[17:13] <mhr3> yea, shouting at us everyday, that fits :)
[17:25] <didrocks> gord: welcome to the unity team
[17:25] <didrocks> gord: are you new? :)
[17:25] <didrocks> want some help? ;)
[17:27]  * gord wonders if there is anyone else left who has been working on unity as long as him ... njpatel jumped ship!
[17:27] <gord> or rather, got promoted to some other ship
[17:28] <didrocks> gord: this launchpad email is confusing, what happened?
[17:28] <didrocks> about you getting into the team
[17:29] <didrocks> and acked by… you :)
[17:29] <gord> didrocks, was just me playing about, i wasn't in the team directly but through other teams, couldn't modify a merge request which was weird, so i thought adding myself directly might fix it, turned out jason was just trying to merge a branch into another branch of his, not trunk ;)
[17:30] <didrocks> gord: ah interesting :)
[17:30] <didrocks> yeah, makes sense
[17:31] <didrocks> so indirect membership and you add you directly yourself
[17:31] <didrocks> funny :)
[17:41] <PaoloRotolo> Hi all!
[18:32] <bkerensa> :( unity just displayed a weird screen artifact and upon reboot my unity launcher was reset
[18:32] <bkerensa> and desktop wallpaper
[18:32] <bkerensa> :(
[18:42] <andyrock> om26er__, https://bugs.launchpad.net/ubuntu/+source/unity/+bug/947362
[18:43] <andyrock> can you reproduce this one?
[18:43] <andyrock> htorque, hello
[18:43] <andyrock> ^^^
[18:43] <htorque> yes
[18:43] <om26er__> looking
[18:43] <om26er__> uh he was quicker :D
[18:43] <htorque> hi :-)
[18:44] <andyrock> htorque, can you confirm? :)
[18:44] <andyrock> please
[18:44] <htorque> done
[18:45] <andyrock> thx
[19:41] <bilal> Anyone knows the difference between an autopilot test and a normal one?
[19:53] <mhall119> tedg: do you know if the sound indicator support MPRIS 2.1?
[19:53] <bschaefer> bilal, do you mean a manual test vs an autopilot test?
[19:54] <tedg> mhall119, I don't know, but I'd guess yes.
[19:54] <tedg> mhall119, Conor would know...
[19:55] <mhall119> ronoc?
[19:55] <tedg> bilal, Basically the level of integration.  Autopilot runs on a complete-ish desktop.
[19:55] <tedg> mhall119, Yes
[19:55] <mhall119> thanks
[19:55] <tedg> lamalex, Can you answer bilal's question a bit better than that? ^
[19:55] <bilal> thanks tedg, that's what I needed
[19:55] <mhall119> tedg: also, we need some instructions for pre-seeding HUD data
[19:55] <mhall119> something we can put on developer.u.c
[19:56] <bilal> tedg: no need, thomi is helping me with it ;)
[19:56] <bilal> thanks a lot anyway
[19:56] <tedg> mhall119, Hmm, yes.
[19:56] <tedg> We should make a demo and document it.
[19:58] <mhall119> tedg: do you happen to know if there is any documentation about using MPRIS to connect to the sound menu?
[19:59] <mhall119> http://www.mpris.org/2.1/spec/ isn't very helpful
[20:01] <tedg> mhall119, This looks like it's out of date: https://wiki.ubuntu.com/SoundMenu#Music_player_integration
[20:02] <mhall119> tedg: do you think http://theravingrick.blogspot.com/2011/02/easily-support-sound-menu-in-python.html still  have a good example of integrating with python?
[20:02] <mhall119> or is it out of date now too
[20:03] <tedg> mhall119, Out of date, that's before we did all that work in libunity for people.
[20:04] <tedg> mhall119, They should just be able to use libunity today.
[20:05] <mhall119> so no more MPRIS?
[20:07] <mhall119> they just use Unity.MusicPlayer and the like?
[20:09] <tedg> mhall119, Well, it is MPRIS, it's just done in a nice to use API.
[20:09] <tedg> mhall119, We've implemented the MPRIS client.
[20:10] <thumper> morning
[20:11] <mhall119> tedg: ah, cool, is there any documentation on doing that then?
[20:11] <mhall119> good afternoon thumper
[20:12] <tedg> mhall119, I think only the API docs, but again, ronoc would be the guy to ask, he did all that work.
[20:14] <mhall119> ok
[20:15] <mhall119> tedg: is ronoc also a good person to ask about docs for the message indicator?
[20:15] <mhall119> or is there someone better I can ask
[20:16] <bschaefer> thumper, good morning! I have a review for you :)
[20:16] <bschaefer> thumper, https://code.launchpad.net/~brandontschaefer/unity/fix-711199/+merge/89192
[20:17] <thumper> bschaefer: morning, I'll look at it soon
[20:18] <bschaefer> thumper, thanks, and no worries just wanted to add it to your todo list
[20:23] <tedg> mhall119, No, messaging indicator is me :-)
[20:25] <mhall119> tedg: ah, well then while I have your ear, I need some documentation on integrating with the message indicator to put on developer.u.c
[23:07] <angeloc> mhr3: why you removed AppInfo.launch_default_for_uri (uri, null); from your ubuntu-lens-files branch?
[23:08] <angeloc> I cannot understand
[23:25] <angeloc> mhr3: ?
[23:26] <mhr3> angeloc, cause it's not needed
[23:27] <angeloc> mhr3: yes, it's needed to open web url with browser web, and after my patch, open mountable uris in nautilus?
[23:28] <angeloc> mhr3: how can I open uris without launch_default_for_uri or launch_uris?
[23:29] <mhr3> angeloc, what makes you think it's needed?
[23:29] <angeloc> mhr3: Have I to add a special case in yor code that use these function only when an uri is detected?
[23:30] <angeloc> mhr3: I think that is used to open uris, isn't it?
[23:31] <mhr3> it did, but it wasn't necessary for standard uris
[23:31] <angeloc> mhr3: who launches firefox when on dash user write google.com?
[23:31] <mhr3> if you return NOT_HANDLED from the activate method, unity tries to do what it can do
[23:32] <mhr3> and it can open uris
[23:34] <angeloc> mhr3: so my patch is totally useless! Target of my patch was to extend launch_default_for_uri to use launch_uris if a mountable uri is detected, but if Unity knows how to handle all the uris itself, my patch is worth nothing, am I wrong?
[23:35] <mhr3> yes :)
[23:35] <mhr3> angeloc, unity just does exactly what the files lens was doing before your patch
[23:36] <mhr3> ie trying to run a sftp://... uri but failing cause it wasn't mounted
[23:37] <mhr3> your patch changes the default behaviour, that's why it works
[23:37] <angeloc> mh3r: ok, ok, Unity can hadle web uris, but not mountable ones, so before return new Unity.ActivationResponse (Unity.HandledType.HIDE_DASH); I have to add code to handle mountable uris
[23:37] <angeloc> mhr3: right?
[23:38] <mhr3> yes
[23:38] <angeloc> mh3r: I'm happy, I almost done!


[07:51] <meena> whoohoo! Green! https://github.com/canonical/cloud-init/pull/363
[08:43] <meena> whoa, who would've thought exchanging one file, but not… everything it touches, could somehow break the system??!
[13:24] <Odd_Bloke> Weird how that works. :)
[14:01] <andras-kovacs> Hi! Is there a nice way to set a short name as static host name instead of the FQDN? (with cloud-init of course)
[14:01] <andras-kovacs> Or should I make it with a runcmd?
[14:02] <andras-kovacs> I mean ask cloud-init to set only hostname into the /etc/hostname instead of the hostname.domain.
[14:37] <Odd_Bloke> andras-kovacs: What distro are you running on?
[14:39] <andras-kovacs> Red Hat...
[14:40] <andras-kovacs> I think a runcmd part will be fine like hostnamectl set-hostname "${HOSTNAME/.*/}"
[14:40] <andras-kovacs> It's a bit messed up scenario :(
[14:43] <Odd_Bloke> andras-kovacs: https://github.com/canonical/cloud-init/blob/master/cloudinit/distros/rhel.py#L80-L91 is the code that performs the hostname set on Red Hat.
[14:44] <Odd_Bloke> andras-kovacs: The hostname passed there is determined by _select_hostname below, and out_fn is self.hostname_conf_fn (so "/etc/sysconfig/network" in this case, I _think_).
[14:45] <Odd_Bloke> That's about as much help as I can be for RH hostname setting though, I'm afraid.
[14:45] <Odd_Bloke> (Feel free to ask more Qs though!  I just don't have the background to speak with authority.)
[15:07] <andras-kovacs> Very many thanks!!
[17:18] <meena> Odd_Bloke: more questions, or rather, the key question.
[17:18] <meena> up on GitHub.
[19:45] <Odd_Bloke> falcojr: FYI, I don't know the answers to some of your Qs in https://github.com/canonical/cloud-init/pull/367 off-hand, so I'm doing some research.
[19:46] <falcojr> sounds good
[20:00] <Odd_Bloke> falcojr: Could you pastebin an example traceback produced by the code in that PR?  (You should have one in cloud-init.log.)
[20:01] <falcojr> sure
[20:01] <Odd_Bloke> Thx!
[20:04] <falcojr> https://paste.ubuntu.com/p/cH8rWmwQ4z/
[20:04] <falcojr> looks like I missed a substitution
[20:07] <falcojr> I'll put it in a github comment too
[20:09] <Odd_Bloke> falcojr: Cool, you've presumably seen my comment then. :)
[20:10] <falcojr> yep, I've been looking in some of the same areas
[20:10] <Odd_Bloke> Cool, will follow up on your higher-level behavioural questions now.
[20:23] <Odd_Bloke> falcojr: OK, I've replied with the behavioural questions; I've skirted around talking about implementation to give you the opportunity to think about it unbiased, so let me know if you'd like to discuss that some more.
[20:24] <Odd_Bloke> s/questions/answers/