[07:54] <zyga> good mornig
[08:08] <dholbach> good morning
[09:14] <opny> hello, the maven plugin assumes  that in a target directory there have to be a jar or war after mvn package. Is there a way I can circumvent this check?
[09:14] <opny> (in snapcraft)
[09:19] <dholbach> opny, you could use https://github.com/ubuntu-core/snapcraft/blob/master/docs/plugins.md and copy the maven plugin to remove the check just to see if that makes it work
[09:19] <dholbach> opny, maybe this should be an option in the maven plugin?
[09:25] <opny> dholbach, hello, yes having it optional may be a good start. I try to add the option in the "overidden" plugin. Actually a property allowing to move custom dir/files like the filesets one would complete the loop
[09:26] <dholbach> maybe you can bring up the idea on the mailing list?
[09:26] <dholbach> it'd be interesting to hear what others think and how the idea could be generalised
[09:27] <opny> dholbach, sure, which one?
[09:27] <dholbach> snappy-app-devel@lists.ubuntu.com?
[09:27] <opny> dholbach, ok
[09:27] <dholbach> awesome :)
[09:41] <JamesTait> Good morning all!  Happy Wednesday, and happy Plimsoll Day! 😃
[10:09] <noizer> HI does somebody knows how I can solve this?   u"!#$%&'*+-.^_`|~:").encode('ascii')
[10:09] <noizer> LookupError: no codec search functions registered: can't find encoding
[10:10] <noizer> it is with werkzeug that i have this error
[11:23] <opny> Is there a method to force snapcraft to update the apt repository as listed in sources.list ?
[11:26] <dholbach> opny, maybe you'd need to talk to sergiusens about reopening https://bugs.launchpad.net/snapcraft/+bug/1493081 (or https://github.com/ubuntu-core/snapcraft/issues/19)
[11:27] <dholbach> kyrofa, ^ do you have any idea if there was any additional discussion about this?
[11:31] <opny> dholbach, thanks.. again :) I'm plagued with Hash mismatch errors which block me for hours
[11:37] <dholbach> opny, I'm afraid I don't know how to work around that
[11:37] <dholbach> maybe when sergiusens and kyrofa come online you can ask them
[11:38] <dholbach> a quick search in the code didn't let me find anything yet
[12:18] <kyrofa> Good morning
[12:19] <kyrofa> dholbach, I'm afraid that was before my time-- I've not heard anything about it
[12:22] <noizer> kyrofa HI does somebody knows how I can solve this?   u"!#$%&'*+-.^_`|~:").encode('ascii')
[12:22] <noizer> LookupError: no codec search functions registered: can't find encoding
[12:22] <noizer> it is with werkzeug that i have this error
[12:26] <kyrofa> noizer, I'm sorry no, I don't know anything about that one
[12:26] <kyrofa> noizer, you might consider asking in #python
[12:29] <noizer> ok
[12:52] <dholbach> hey sergiusens
[12:52] <sergiusens> dholbach, hello
[12:53] <dholbach> sergiusens, is there a way for snapcraft users to provide their own sources.list... or add PPAs or use different mirrors and stuff?
[12:53] <sergiusens> dholbach, not currently; but soon we will remove just use local sources by default so it is whatever you have on your system
[12:54] <dholbach> opny, ^
[12:54] <dholbach> ok cool
[12:54] <opny> sergiusens, dholbach thanks
[12:54] <sergiusens> opny, dholbach for now there is a hidden USE_LOCAL_SOURCES you can export
[12:55] <opny> sergiusens, dholbach seems like sources.list is took once and then not updated anymore..
[12:55] <dholbach> ah, nice one... I saw that in the source and wondered how it'd work
[13:00] <opny> sergiusens, dholbach is it like `USE_LOCAL_SOURCES=1 snapcraft` ? I cannot find it in the snapcraft source, maybe a python/apt thing
[13:01] <dholbach> sergiusens, or _PLUGIN_STAGE_SOURCES?
[13:02] <sergiusens> opny, dholbach sorry, it is SNAPCRAFT_LOCAL_SOURCES
[13:03] <opny> sergiusens, dholbach works, perfect! Thank you :)
[13:03] <dholbach> :-D
[13:03] <dholbach> brilliant!
[13:07] <kyrofa> Anyone else having stability problems with the dragonboard?
[13:07] <ogra_> kyrofa, on what image ?
[13:07] <kyrofa> ogra_, actually on the linaro Ubuntu image, so not really an Ubuntu Core question. But I find if I push it very hard for very long, it just gives up
[13:08]  * ogra_ is about to finish an all-snaps one that should be stable .... my 15.04 one is clearly hacked up enough to expose instability 
[13:08] <ogra_> ah
[13:08] <kyrofa> ogra_, ah, I'll definitely give that a shot when it's available. I'm just worried it's a heating problem or something
[13:10] <kyrofa> Can't build any good-sized snaps on it
[13:44] <ysionneau> hi, how can I generate an oem snap? Do I need to use snapcraft?
[13:44] <ogra_> i dont think we have oem plugins yet ...
[13:45] <ogra_> also note that oem snaps are 15..04 only ... we switched to a different setup with "gadget" snaps in 16.04
[13:45] <ysionneau> type: oem does not seem to work indeed it tells me "you need either app or framework"
[13:45] <ysionneau> oh
[13:45] <ysionneau> I'm following the documentation for "how to port snappy to your platform"
[13:45] <ogra_> yeah, thats still 15.04
[13:45] <ysionneau> https://developer.ubuntu.com/en/snappy/guides/porting/
[13:45] <ysionneau> ok
[13:46] <ogra_> 16.04 is to much in flux still .... we're in the middle of switching the whole image design to a "all snaps" setup
[13:46] <ysionneau> It seems I need the oem snap in order to do the ubuntu-device-flash command to generate the image
[13:46] <ysionneau> oh
[13:46] <ysionneau> interesting
[13:46] <ogra_> right
[13:47] <ysionneau> so, how am I supposed to generate the oem snap?
[13:51] <ogra_> ysionneau, we store the official code for the oem/gadget snaps at https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems ... for 15.04 you would have to go a bunch of revisions backwards in the commits though
[13:53] <ysionneau> oh right, there are the snap.yaml files in there
[13:53] <ysionneau> type: gadget
[13:53] <ysionneau> hmmm
[13:54] <ogra_> yeah, you will have to go back through the history to get to package.yaml and 15.04 setup
[13:54] <ysionneau> ah, if I go back in time indeed I get the package.yaml files
[13:55] <ysionneau> I'm especially interested in the arm64 stuff, so dragon I guess
[13:55] <ysionneau> rev 18 seems interesting
[13:56] <ysionneau> since rev 19 renamed package.yaml to snap.yaml
[13:56] <ogra_> ysionneau, http://people.canonical.com/~ogra/snappy/dragonboard/
[13:56] <ogra_> thats a very hackish 15.04 image
[13:57] <ysionneau> thanks!
[13:58] <ogra_> thogh 15.04 has issues that will likely not get fixed
[13:58] <ogra_> (on the dragonboard specifically)
[13:59] <ogra_> focus is on 16.04 only
[13:59] <ysionneau> hmmm ok
[13:59] <ysionneau> maybe I should switch to 16.04 then
[13:59] <ogra_> yeah
[13:59] <ysionneau> I'm wondering, now that I have that package.yaml
[13:59] <ysionneau> I still don't understand how to generate the oem.snap :p
[13:59] <ogra_> i'm waiting for a final kernel build and should have some test image ready later today
[13:59] <ysionneau> snapcraft is searching for snapcrafy.yaml
[13:59] <ysionneau> -y
[14:00] <ysionneau> ah good news!
[14:00] <ogra_> yeah, we dont use snapcraft for oem/gadget ... but "snappy build" directly
[14:00] <ysionneau> ah great, it worked :)
[14:00] <ysionneau> thanks
[14:02] <ysionneau> now I get "Signature verification failed" :'
[14:02] <ysionneau> while doing the ubuntu-device-flash
[14:02] <ogra_> you need to use --developer-mode
[14:02] <ysionneau> btw, 16.04 is devel ? devel-proposed ?
[14:02] <ogra_> else it wont allow your own oem/gadget
[14:02] <ogra_> 16.04 is rolling/edge
[14:03] <ogra_> (release is rolling, channel is edge)
[14:12] <ysionneau> ogra_: did you ever tried to run your dragon snappy system on qemu?
[14:12] <ysionneau> try*
[14:12] <ogra_> does qemu support arm64 yet ?
[14:12] <ysionneau> yes
[14:12] <ogra_> (and does it emulate the dragon ?)
[14:12] <ogra_> no, i never tried
[14:12] <ysionneau> it does not emulate the dragon specifically
[14:12] <ysionneau> I cannot see any arm64 emulated boards
[14:13] <ysionneau> but you can do something like -M virt -cpu cortex-a53
[14:13] <ysionneau> and such
[14:13] <ogra_> well, i doubt that works with the dragonboard specific kernel
[14:13] <ysionneau> http://www.bennee.com/~alex/blog/2014/05/09/running-linux-in-qemus-aarch64-system-emulation-mode/ < like this
[14:13] <ysionneau> but you don't need to compile your own qemu
[14:14] <ysionneau> it worked on my debian testing with official debian qemu package
[14:14] <ogra_> with a dragonboard kernel ?
[14:14] <ysionneau> nop
[14:15] <ysionneau> I don't even know how this guy generated his kernel (with which config)
[14:15] <ogra_> right, most likely just some generic arm64 thing
[14:16] <ysionneau> yeah I guess
[14:18] <ysionneau> maybe I can just use the dragon snappy image, but use my generic aarch64 kernel
[14:18] <ysionneau> so that it can run in qemu
[14:20] <ysionneau> or I should just generate my own system image
[14:21] <asac> hmm. i have a rolling all-snaps image from the 8th january ... do i need to reinstall to get back on latest rolling lane?
[14:21] <asac> my image doesnt update
[14:23]  * asac just goes and installs latest https://people.canonical.com/~mvo/all-snaps/rpi2-all-snap.img.xz
[14:23] <ogra_> asac, yeah, i dont think they update yet
[14:24] <asac> guess they changed names :
[14:24] <asac> )
[14:24] <asac> of snaps like ubuntu-core
[14:24] <ogra_> (and we have no auto-builds that would submit the snaps to the sotre yet .... all manual)
[14:24] <asac> will see once its booted
[14:24] <asac> hmm
[14:24] <asac> ok
[14:24] <asac> well, thats fine. let me see what i find here on the 4th feb image i guess
[14:24] <asac> interesting that bbb is 40M igger than pi2 image
[14:24] <asac> guess pi2 isnt a full blown kernel?
[14:25] <ogra_> it is
[14:25] <ogra_> but a smaller initrd
[14:25] <asac> hmm. ok. different config?
[14:25] <asac> or how did this end up being different?
[14:26] <asac> anyhopw, i am on pi2 anyway so dont mind smaller footprint
[14:26] <ogra_> simply doesnt pull in as many modules
[14:26] <ysionneau> is there online documentation about the new "all-snaps" architecture?
[14:26] <ogra_> (and yeah, i guess there are less built ... effectively you mostly only want USB stuff that you can plug in)
[14:31] <sergiusens> kyrofa, elopio be there in 2
[14:31] <kyrofa> sergiusens, sounds good
[14:34] <asac> ysionneau: i dont think there is... buut summary is that everything is now snaps. anything specific you want to know?
[14:35] <asac> dholbach: think good clinic topic would be to make overview of all-snaps when mvo is back
[14:35] <kyrofa> jdstrand, is access to /proc/<pid>/statm a risk? (denied in 15.04)
[14:35] <elopio> fgimenez: my deploy got stuck stoping jenkins-master-service. Did you do one?
[14:35] <ysionneau> nothing specific, it's just that I'm very beginner with ubuntu snappy stuff
[14:35] <ysionneau> so I feel more confortable using something documented
[14:35] <dholbach> asac, yes - that's noted down and requested already
[14:35] <ysionneau> root@imperium:/home/yann/dev/snappy# ls -l my-snappy.img
[14:35] <ysionneau> ls: cannot access my-snappy.img: No such file or directory
[14:35] <ysionneau> oops
[14:35] <jdstrand> kyrofa: looks fine to me
[14:35] <asac> dholbach: cool!
[14:35]  * jdstrand adds it
[14:36] <dholbach> asac, niemeyer and mvo just seemed very busy lately - so I didn't get a date from them yet
[14:36] <ysionneau> http://pastebin.com/0u4f92Xc < any idea why this fails?
[14:36] <asac> dholbach: fine
[14:36] <asac> just keep nagging... guess after sprint might be better time
[14:36] <jdstrand> kyrofa: what is requesting the access (trying to decide if in default or a cap)
[14:37] <asac> ysionneau: you cannot use tarballs as device parts anymore... needs to be snap. check with ogra
[14:38] <jdstrand> oh, status is basically the same info
[14:38] <jdstrand> ok, default profile
[14:38] <elopio> plars: http://pad.ubuntu.com/spi I started updating the stuff, with a little bit of problems.
[14:40] <plars> elopio: oh, I've done none of that yet on my side
[14:40] <ogra_> ysionneau, right, like asac says, all-snap means that everything is a snap .... rootfs, kernel, gadget (oem)
[14:40] <ogra_> ysionneau, the 15.04 setup still uses the phone based tarball system-image setup
[14:41] <plars> elopio: for authorization stuff, you'll need to contact ev's team I think
[14:43] <elopio> plars: yes, I'll be talking to them today.
[14:43] <elopio> plars: from your side, we need to be able to call the all-snaps udf.
[14:43] <ogra_> ysionneau, try using the oem snap from my image ...
[14:44] <ysionneau> ogra_: ok thanks
[14:44] <elopio> plars: maybe if we include the binary name, not just "udf-params"
[14:44] <ogra_> oh, annd the dragonboard setup has a very specific partitioning for the bootloader ... that requires the very latest ubunu-device-flash from xenial
[14:44] <ysionneau> 15:37 < asac> ysionneau: you cannot use tarballs as device parts anymore... needs to be snap. check with ogra < which means the documentation is wrong? :o
[14:44] <ogra_> ysionneau, the documentation refers to 15.04
[14:44] <asac> right
[14:44] <ysionneau> yes, which is what I'm using right now
[14:44] <ogra_> it will be changed once all-snaps is the default
[14:45] <asac> ysionneau: i would suggest to stick to 15.04 for now
[14:45] <asac> if you are new
[14:45] <ogra_> if you build for 15.04 you can indeed use tarballs
[14:45] <asac> bc there is lots of stuff landing as we speak on trunk
[14:45] <asac> so if you are not yet deep in this topic it will be rough at best :P
[14:45] <ogra_> but i dont think you will get a dragon image to work with 15.04
[14:45] <ysionneau> so since I'm targeting 15.04 in my pastebin, any idea why it does not work?
[14:45] <ogra_> there are various issues with that
[14:45] <ysionneau> ah
[14:45] <ogra_> (as i said earlier)
[14:46] <plars> elopio: is there a cheat sheet for how to build all the all-snaps images using the all-snaps udf?
[14:46] <ysionneau> what you say about "dragon image" is also true for any arm64 image?
[14:47] <ysionneau> the fact that it would not work for 15.04
[14:47] <ogra_> no
[14:47] <plars> elopio: and can you confirm if I really need to be on xenial to build all-snaps images or not? I remember you mentioned that before, but I thought it was unconfirmed at the time
[14:47] <ogra_> generic arm64 might work or not
[14:47] <ogra_> the specific dragnboard setup will definitely not work though
[14:48] <ysionneau> ok
[14:48] <ogra_> so you can try a aemu arm64 image based on a generic kernel ... but YMMV ... i dont thinnk anyone actually tested arm64 on 15.04
[14:48] <ogra_> *qemu
[14:48] <ysionneau> hmm hmm ok
[14:48] <ysionneau> understood
[14:50] <fgimenez> elopio, nope, your's finished after all
[14:50] <noizer> Hi how can I force delete an application. Because when I'm trying. it says read only permission or something
[14:59] <jdstrand> kyrofa: I'm going to upload this in a few minutes, but I don't know when the next image will be spun. I believe one is undergoing testing to pull in security updates, so the next one may not have this unless they respin (or you ask them to respin)
[15:00] <kyrofa> jdstrand, woo! Excellent news, thank you :)
[15:00] <asac> hmm. snappy search command doesnt exist right now on 16.04?
[15:01]  * asac installs bluez5 out of the blue
[15:01] <jdstrand> asac: snap find foo
[15:01] <jdstrand> I don't know the reasoning behind that, but came across it
[15:02] <elopio> fgimenez: no, it's missing one slave.
[15:02] <asac> good... i looked at snap command
[15:02] <elopio> I'll retry.
[15:02] <asac> but missed that find thingy
[15:02] <asac> thanks jdstrand
[15:02] <jdstrand> np
[15:02] <asac> snap find bluez5 yields nothing
[15:02] <asac> guess store is borked?
[15:03] <asac> snap find bluez
[15:03] <asac> error: no snaps found for "bluez"
[15:03] <asac> ubuntu@localhost:~$ snap find bluez5
[15:03] <asac> error: no snaps found for "bluez5"
[15:03] <asac> ubuntu@localhost:~$ snap find hello
[15:03] <asac> error: no snaps found for "hello"
[15:03] <asac> ok let me find a bt dongle ... /me hopes he can find those mini things
[15:05] <ogra_> asac, 90% of the store snaps cant run on 16.04 anyway ... until they are converted to squashfs
[15:05] <ogra_> might be that the store now finally filters them
[15:06] <ogra_> (snappy install falls over on the click legacy during install for most of them)
[15:07] <asac> ok this is not looking good
[15:07] <asac> let me order a new one
[15:07] <ogra_> no beer before 5 !
[15:15] <asac> hehe
[15:15] <asac> i wish
[15:15] <asac> so what cool BLE device could i buy? guess just a dongle wont make it
[15:22] <ogra_> asac, http://www.amazon.de/Satechi%C2%AE-Bluetooth-Button-Kompatibel-Cortana/dp/B012OWC5NQ/ref=sr_1_4?ie=UTF8&qid=1455117712&sr=8-4&keywords=BLE+bluetooth
[15:23] <ogra_> or http://www.amazon.de/Satechi%C2%AE-Bluetooth-Button-Series-Samsung/dp/B00RM75NOW/ref=pd_cp_23_2?ie=UTF8&refRID=0SA6C938R1PRR0S634S7
[15:29] <asac> lol
[15:29] <asac> a bt button
[15:29] <asac> always wanted that :0
[15:29] <asac> ok ordered :)
[15:29] <asac> lol
[15:30] <jdstrand> kyrofa: 15.04.12~ppa17 uploaded to the ppa
[15:30] <jdstrand> (ubuntu-core-security)
[15:31] <kyrofa> jdstrand, awesome, thanks
[15:37] <ogra_> ppisati, FYI ... boots perfect with the new DT
[15:37] <ogra_> thanks a lot
[15:37] <ogra_> !
[15:38] <ppisati> ogra_: yeaaaaaaahhh! :)
[15:38] <ppisati> ogra_: as soon as i have some time, i'll try to debug what was going on with the old dtb
[15:38] <ogra_> yeah
[15:38] <ogra_> it is weird that we dont see it everywhere
[15:38] <ppisati> yes it is
[16:04] <jdstrand> kyrofa: and ubuntu-core-security 16.04.15 uploaded to xenial
[16:05] <kyrofa> Thanks jdstrand!
[16:12] <sergiusens> elopio, kyrofa reviewzzzz :-)
[16:13] <kyrofa> elopio, did you say the maven PR was good?
[16:14] <elopio> kyrofa: I did, yes. But sergiusens changed everything. I'm looking again.
[16:27] <jdstrand> zyga: dumb question-- I'd like to review the entire PR as it stands now (ie, with all of your changes) in github. how do I do that?
[16:28] <jdstrand> I feel like I found it yesterday, but I can't seem to today
[16:29] <jdstrand> oh, Files changed
[16:29] <jdstrand> ok
[16:29] <jdstrand> zyga: nm
[16:29] <elopio> ev: noise][: can you help me today with spi?
[16:30] <zyga> jdstrand: hey
[16:30] <zyga> jdstrand: :D
[16:30] <zyga> jdstrand: ping me if there are tests missing
[16:30] <zyga> jdstrand: I think you asked for one more but I'm not sure
[16:34] <joc__> elopio: hi, we're making some good progress on running the snappy tests from checkbox
[16:34] <elopio> joc__: awesome!
[16:34] <joc__> elopio: last few failing tests are printing "Error: aa_change_onexec failed with -1. errmsg: Permission denied
[16:35] <ev> elopio: hey, what’s up?
[16:35] <joc__> elopio: are they expecting to be run with sudo?
[16:35] <jdstrand> zyga: I think we are good (gave +1)
[16:35] <jdstrand> zyga: thanks!
[16:35] <elopio> joc__: they should have permission to run sudo, but the scripts themselfs add the sudo command when required. That's more likely that you have an outdated allsnaps image.
[16:36] <kyrofa> sergiusens, any idea why all-snaps doesn't have /etc/protocols?
[16:36] <elopio> joc__: I was looking at this yesterday: http://bec-systems.com/site/942/running-a-reboot-cycle-test-shell-script-with-systemd
[16:36] <elopio> we could use it to test reboots without adt-run. It would be a lot more complex than what we have now, though.
[16:37] <elopio> seems easier to do adt-run with the nil testbed, so it runs in the same host.
[16:37] <joc__> elopio: i wrote some stress-tests that do almost exactly that in checkbox
[16:37] <elopio> ev: hey. I got two errors here: http://pad.ubuntu.com/spi
[16:37] <elopio> In the current section.
[16:38] <joc__> elopio: they arent great though as you can't receonnect to them from a user session
[16:38] <joc__> elopio: but they allowed us to atleast set up warm boot / cold boot stress tests
[16:38] <plars> elopio: did you see my questions earlier about building images? in particular, for x86?
[16:39] <ysionneau> in ubuntu-device-flash , the --oem is supposed to be the path to the .snap ? or the path to the source of the oem package (the directory containing the meta directory)?
[16:39] <sergiusens> kyrofa, should I name it 2.1.2? I already have, but seem to regret it a bit
[16:39] <plars> elopio: also, how much concern do you have for testing older pre-allsnaps images across supported platforms? I'm tempted to just move everything to the new tool except for specific platforms that generally need the older image
[16:39] <elopio> plars: sorry, I didn't. zyga said he's writing a cheat sheet for all snaps, or that's what I understood.
[16:39] <sergiusens> kyrofa, no idea; but why should it be there for you?
[16:40] <plars> elopio: ack
[16:40] <sergiusens> need to resolve a proto name?
[16:40] <elopio> plars: and it doesn't need to be xenial. What I said is that the new ubuntu-image will be xenial only.
[16:40] <kyrofa> sergiusens, for getprotobyname and associated calls
[16:40] <plars> elopio: I found what to do for rpi2, and I can see from your pastebin how to do it for bbb, but I'm interested in db410c and x86 too
[16:40] <sergiusens> kyrofa, so I bet netbase is installed; ogra_ clues?
[16:40] <kyrofa> sergiusens, regarding the version, wouldn't 2.2 be more correct since you have the --output feature?
[16:40] <zyga> jdstrand: perfect, thank you :)
[16:41] <elopio> plars: for db ask ogra_. For x86, maybe he'll know too.
[16:41] <sergiusens> kyrofa, there
[16:41] <noise][> elopio: hey, missed your ping earlier, what can I help with?
[16:41] <sergiusens> kyrofa, netbase is not in the manifest http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
[16:41] <sergiusens> kyrofa, you can ask ogra to seed it I guess
[16:41] <elopio> plars: and if it makes things easier, just don't worry at all about 15.04 images. Our main focus is 16.04.
[16:42] <kyrofa> sergiusens, thanks :) . ogra_ how would you feel about that?
[16:42] <elopio> hey noise][. Pasting the message again: I got two errors here: http://pad.ubuntu.com/spi
[16:42] <elopio> In the current section.
[16:43] <kyrofa> ogra_, it was in 15.04... was it removed for a reason?
[16:43] <ev> elopio: authorisation is keyed on permissions to snaps now, rather than organisation keys: https://spi.canonical.com/assets/tutorial.html#creating-a-product
[16:43] <ev> https://spi.canonical.com/assets/tutorial.html#testing explains how to set up that gold master test
[16:45] <ogra_> kyrofa, i didnt explicitly remove it ... weird ... yeah, we can add it bacjk
[16:45] <ogra_> kyrofa, btw, see my dragonboard mails ... image is up
[16:45] <sergiusens> ogra_, maybe related to the 'one seed to rule them all' thread?
[16:46] <kyrofa> ogra_, I saw that, thank you :)
[16:46] <ogra_> sergiusens, i dont think anything changed yet
[16:46] <ogra_> though i might be wrong, seems severakl teams now tinker with that, could be that slangasek already started with some changes that i missedf
[16:48] <ogra_> plars, i only heard this week that x86 will be a supported target, i'll work on it alongside with enabling the arm64 builds for the db
[16:48] <noise][> elopio: checking..
[16:51] <kyrofa> ogra_, hmm... should we talk to some about adding it back, then? Or do you think it's safe?
[16:52] <ogra_> kyrofa, lets wait for slangasek, i dont want to mess up anything he is currently fiddling with ... apart from that, yeah, i think we should add it back
[16:52] <kyrofa> ogra_, alright sounds good. Thank you!
[16:53] <ogra_>  /etc/services and /etc/protocols is definitely something we should have :)
[16:53] <kyrofa> Agreed
[16:53] <kyrofa> Took me a while to trace my segfault back to that
[16:54] <ysionneau> http://paste.ubuntu.com/15009577/ any idea? ( I'm using the bzr rev12 of snappy-systems for the oem package of beagleblack)
[16:59] <didrocks> Do you know where the webdm code is? I would have expected it to be on https://github.com/ubuntu-core
[17:01] <ogra_> didrocks, m,ost likely on launchpad
[17:01] <ogra_> didrocks, only snappy and snapcraft moved to github
[17:01] <didrocks> oh right, for some reasons, I thought https://code.launchpad.net/~snappy-dev/webdm/trunk was old
[17:01] <dholbach> didrocks, https://code.launchpad.net/webdm
[17:01] <ogra_> afaik
[17:01] <didrocks> yeah, thanks ogra_ & dholbach :)
[17:03] <didrocks> interesting, it doesn't use snapcraft (yet ;))
[17:06] <sergiusens> elopio, pushed now, I had addCleanup which took care of os.environ afaik, but since you love fixtures, it is there now
[17:06] <sergiusens> didrocks, because of multi arch
[17:06] <sergiusens> didrocks, now that that is there it can migrate
[17:06] <didrocks> excellent!
[17:06] <noise][> elopio: i'm able to repro that error, digging now to see why
[17:07] <elopio> sergiusens: ah, I didn't see that and it was just one line above :) But yes, I prefer fixtures.
[17:07] <elopio> sergiusens: missed one: os.environ['SNAPCRAFT_SETUP_PROXIES'] = '1'
[17:08] <sergiusens> strange
[17:08] <elopio> that's twice actually.
[17:09] <sergiusens> elopio, oh, I didn't push :-p
[17:09] <sergiusens> well, I didn't commit to be precise
[17:10] <sergiusens> done
[17:11] <plars> noise][: do we have to specify a primary snap to base the "product" around? What if we just want to test the base image by itself?
[17:13] <elopio> as I understood, that's just for authentication. So I used a dummy snap of mine.
[17:13] <elopio> I might be wrong, of course.
[17:13] <noise][> right, the primary snap is for authz
[17:13] <elopio> sergiusens: just the two os.environ['SNAPCRAFT_SETUP_PROXIES'] = '1', and then you are free to go.
[17:14] <plars> noise][: elopio: so to test the image, I have to create a dummy snap that I have no intention (or desire) of actually installing, and everything is dependent on updating that snap?
[17:14] <elopio> I wonder if useFixture works on a @classmethod. umm...
[17:14] <sergiusens> elopio, oh, right
[17:15] <slangasek> ogra_: hi, I don't think I have context for these highlights
[17:15] <elopio> plars: no, it is dependent on the list of snaps you use. Which don't need to be yours.
[17:15] <ogra_> slangasek, snappy seeds ... did you cahnge anything for them yet ?
[17:16] <plars> elopio: but one of them does, right?
[17:16] <slangasek> ogra_: no, what are you expecting to be changed?
[17:16] <sergiusens> elopio, is this needed at all http://paste.ubuntu.com/15009708/ ?
[17:16] <sergiusens> elopio, and will that work?
[17:16] <ogra_> slangasek, well, there was some discussion to base them on lxc seeds ort some such ...
[17:16] <ogra_> *or
[17:17] <noise][> plars: primary_snap needs to be owned or shared with you
[17:17] <elopio> sergiusens: to be safe, I would put it in the SetUp.
[17:17] <slangasek> ogra_: I'm not sure I was part of any concrete discussion about this
[17:17] <ogra_> slangasek, natbase seems to be gone from snappy in 16.04, i was asked to put it back, i just wanted to make sure i'm not stepping on your toes here
[17:17] <ogra_> *netbase
[17:17] <slangasek> we certainly shouldn't have lots of different parallel seed definitions, but I'm not driving anything here currently, no
[17:17] <ogra_> ok, good
[17:18] <elopio> sergiusens: and maybe it's not needed to clean it up, as all the examples tests will need the proxy. But I've gone mad a couple of times because of environment variables that I'm not sure where are set. That's why I started liking fixtures.
[17:18] <sergiusens> elopio, yeah, that's why I didn't worry about cleanup here
[17:18] <sergiusens> elopio, in anycase, pushed
[17:19] <elopio> sergiusens: thanks. Land whenever you want.
[17:19] <sergiusens> elopio, when testing finishes of course ;-)
[17:20] <elopio> fgimenez: the sync has been here for a long long time: https://paste.ubuntu.com/15009722/
[17:20] <elopio> is it normal?
[17:20] <noise][> elopio: aha!  s/rolling/rolling-core in your "release"
[17:21] <elopio> noise][: what? I didn't know rolling-core was a thing.
[17:21] <elopio> I'll update it.
[17:21] <noise][> elopio: I'm just going by what data is actually in the store/CPI
[17:21] <noise][> for those snaps you list it's rolling-core
[17:22] <elopio> noise][: thanks for digging it out.
[17:22] <noise][> y, sorry that error message isn't very good
[17:23] <fgimenez> elopio, i don't think so, that should be the final step, after all the files has been copied right?
[17:24] <elopio> fgimenez: I don't know. The jenkins page is down.
[17:25] <elopio> if I ctrl+c and sync again would I just break it all?
[17:30] <fgimenez> elopio, :) i think that it would be better to try to restart the docker service, it seems to be broken somehow, anyway compose will simplify this (that's my moto)
[17:30] <elopio> fgimenez: killing and retrying is my motto :p
[17:32] <elopio> restarted. I can't even run docker ps.
[17:32] <elopio> I'll do it all over again.
[17:34] <fgimenez> elopio, wait, docker ps is working
[17:34] <fgimenez> elopio, np :)
[17:34] <elopio> fgimenez: yeah, too late.
[17:35] <kyrofa> ogra_, just read the scrollback. netbase sounds okay to add back then, it seems?
[17:36] <ogra_> kyrofa, yeah, i'll update that tomorrow if thats sufficient
[17:36] <kyrofa> ogra_, perfectly :)
[17:36] <kyrofa> ogra_, thank you!
[17:36] <fgimenez> elopio, all the containers were there http://paste.ubuntu.com/15009811/ anyway we could replace restarting them with the service restart in the sync script if you find problems again
[17:37] <kyrofa> elopio, re: rolling vs. rolling-core, remember there's rolling-personal as well
[17:38] <elopio> let's see how it goes now.
[17:38] <elopio> kyrofa: ahh
[18:02] <sergiusens> elopio, kyrofa https://github.com/ubuntu-core/snapcraft/pull/311
[18:04] <jdstrand> JamesTait: hey-- not trying to create more work for you but I did a refactor branch and have one ACK, which would normally be enough for me to push. were you planning on looking at it more?
[18:04] <jdstrand> JamesTait: I'm not blocked
[18:43]  * zyga thinks that https://github.com/zyga/devtools/ is now useful for snappy development in general
[18:56] <elopio> plars: ^ a temporary ubuntu-image.
[18:56]  * sergiusens notes that zyga has become the ubuntu-image owner ;-)
[18:57] <plars> elopio: I know, I saw... I'd prefer just a cheatsheet of the cli args, but I have that now :)
[18:57] <elopio> it was a trap
[18:57] <plars> haha
[19:00] <zyga> plars: the cli will probably change
[19:00] <zyga> (over time)
[19:46] <sergiusens> elopio, great https://launchpadlibrarian.net/237772709/buildlog_ubuntu-xenial-amd64.snapcraft_2.2_BUILDING.txt.gz
[19:46] <sergiusens> elopio, I need to 'unset' the no_proxy var as well :-/
[19:47] <elopio> sergiusens: I think that if you pass None to the fixture it will remove it.
[19:47] <sergiusens> elopio, too bad I merged the changelog...
[19:47] <sergiusens> elopio, should I create 2.2.1 or should I create a PR that fixes this and still considers it 2.2?
[19:48]  * kyrofa wouldn't look if sergiusens rebased the changelog
[19:48] <sergiusens> kyrofa, nah, not for this
[19:48] <elopio> sergiusens: you can modify the master commit, right? Just reset one change.
[19:48]  * sergiusens ponders splitting up the packaging branch
[19:49] <kyrofa> Yeah I say fix it for 2.2 the move the changelog commit
[19:49] <elopio> sergiusens: I thought you were waiting for my +1 to merge that :D
[19:49] <elopio> also I wonder why travis doesn't fail.
[19:49] <sergiusens> elopio, because it doesn't set a no_proxy ;-)
[19:50] <sergiusens> elopio, I didn't know I was waiting for your +1 fwiw
[19:50] <plars> noise][: I logged in, generated the config.ini, but I get 401 when I try a similar product creation to what leo did: http://paste.ubuntu.com/15010644/
[19:50] <elopio> kyrofa: sergiusens: I reported three bugs for the failing examples. These are not related to our release, so I was about to +1 the changelog.
[19:50] <sergiusens> elopio, kyrofa quick hangout; irc feels like broken telephone
[19:50] <sergiusens> ?
[19:51] <elopio> okay.
[19:51] <noise][> plars: and you own that primary snap?
[19:51] <plars> noise][: the user I'm trying to login as does, yes... but maybe that's the problem if it's really checking. It probably isn't published yet
[19:52] <plars> noise][: I need to wait for approval I guess?
[19:52] <noise][> plars: yeah, has to exist in CPI, thus be published
[19:52] <plars> ok
[19:52] <kyrofa> sergiusens, I can't at the moment, but if you guys go ahead I'm happy with whatever you decide
[19:55] <noise][> plars: "./scripts/api_example.py config.ini https://spi.canonical.com/products" will spit out the list of "packages" that you have access to
[19:55] <plars> noise][: I can't see that until I register the product as above though, right?
[19:56] <plars> right now, it's an empty set, because I wasn't authorized to register the product yet, since the snap is not yet published
[19:58] <noise][> plars: i think that should give you the list of all published packages you own or have shared access to
[19:58] <noise][> regardless of having created a product yet
[19:59] <plars> noise][: ah, ok
[19:59] <noise][> the endpoint returns a dict w/2 top fields: packages, products
[19:59] <plars> noise][: I would have assumed it's only the set of products I've created
[19:59] <plars> I see
[19:59] <noise][> yeah, the packages part if just a bonus :)
[20:11] <sergiusens> elopio, https://github.com/ubuntu-core/snapcraft/pull/312
[20:14] <elopio> sergiusens: +1. Now another for the changelog?
[20:14] <elopio> I'm hungry! :D
[20:14] <sergiusens> elopio, oh, we don't need one is what I thought
[20:15] <elopio> sergiusens: ah, right, no problem.
[20:15] <elopio> merged. Ping me on telegram if you need me.
[20:15] <sergiusens> elopio, built fine https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily/+packages?field.name_filter=snapcraft&field.status_filter=published&field.series_filter=xenial
[20:16] <sergiusens> now let's hope that adt works for at least amd64
[20:29] <sergiusens> kyrofa, feel free to edit for clarity https://launchpad.net/snapcraft/+milestone/2.2 (the Release Notes that is)
[20:29] <sergiusens> don't change bug status yet
[20:29] <sergiusens> as we haven't migrated from proposed still
[21:00] <sergiusens> jdstrand, hey, at your leisure, can you look at https://bugs.launchpad.net/snapcraft/+bug/1544249 ?
[21:02] <jcastro> If I wanted to track development with a spare machine I just dd mvo's all-snap image onto a disk right?
[21:08] <sergiusens> jcastro, yes
[22:25] <sergiusens> elopio, new set of errors FAILED (failures=1, errors=14, skipped=2)
[23:00] <JamesTait> jdstrand, thanks for doing that, I'd missed the new branches.  Taking a look now.
[23:21] <sergiusens> elopio, I'm giving adt some more importance, so I might fix these tonight https://launchpad.net/snapcraft/+milestone/2.2.1
[23:24] <JamesTait> jdstrand, first branch +1'd.
[23:24] <jdstrand> JamesTait: thanks!
[23:25] <jdstrand> JamesTait: fyi, about to head out, but the 3rd branch while 'work in progress' is only missing the 5 TODO tests at the bottom of sr_lint.py
[23:25] <JamesTait> jdstrand, *so* much cleaner, thanks for breaking it up, and apologies for the extra work.
[23:25] <jdstrand> JamesTait: glad it helped. the exercise actually helped me spot a few things
[23:26] <jdstrand> I'm working on those 5 tests now, but won't be done with those and tests before eod
[23:26] <JamesTait> jdstrand, now I don't feel so bad. 😉
[23:27] <jdstrand> but there is a lot to review in that branch if you want to get a head start
[23:27] <JamesTait> jdstrand, that's fine, I can take a look in the meantime and finish the review when you're done.
[23:27] <jdstrand> cool
[23:28] <JamesTait> It's not blocking me, and I'm out Friday and Monday.
[23:28] <jdstrand> me too :)
[23:29] <JamesTait> Yay for long weekends! D
[23:30] <JamesTait> Gah, I hate this keyboard. :-/