netphreak | hi, guys! | 01:30 |
---|---|---|
=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
shuduo | morning | 05:58 |
mvo | ogra_: if you have time at some point it would be great if we could update the arm64 kernel in xenial in the store | 07:45 |
zyga | Good morning | 08:03 |
mvo | ogra_: hm, the latest rpi2 kernel from the archive (canonical-pi2-linux.canonical_4.4.0-1004.5-1.snap) appears to not boot at all, hangs at "Uncompressing Linux... done, booting the kernel." | 08:08 |
mvo | ogra_: auto-rollback-broken-boot ftw :) | 08:09 |
dholbach | good morning | 08:19 |
didrocks | dholbach: good morning! | 08:19 |
dholbach | salut didrocks | 08:19 |
shuduo | hello, i am working on repack mopidy (http://github.com/mopidy/mopidy.git) into snap format. i'm referring py2-project of snapcraft-examples. after snapcraft build, i notice the execute file /usr/bin/mopidy as a python script file contain my work directory path in first line. | 08:38 |
shuduo | i wonder mopidy is pip compatible but spongeshaker don't has weird path. any idea how to solve or workaround it? | 08:40 |
ogra_ | mvo, the cdimage snaps shoudl work ... | 08:58 |
ogra_ | (for updating the store) | 08:58 |
asac | hmm. running snapcraft from within snapcraft tree isnt possible anymore? it cannot find the plugins for me :/ | 09:00 |
asac | odd | 09:01 |
ogra_ | mvo, for arm64 we now have the linux-snapdragon kernel, the cdimage snap is already built from it by default since friday, i need to create as new package in the store for the new name | 10:05 |
ogra_ | s/as/a/ | 10:05 |
* ogra_ is waiting for dd to finish to chekc the rpi image | 10:06 | |
ogra_ | mvo, hmm, i think we need a gadget update for the rpi side | 10:07 |
mvo | ogra_: is the kernel available as an artifact on cdimage? | 10:08 |
mvo | ogra_: do we need a new dtb ? or why is the gadget update needed? | 10:08 |
ogra_ | http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ | 10:08 |
ogra_ | mvo, iirc the 4.4 support was added, the all-snaps gadget is still on older firmware | 10:09 |
ogra_ | (i updated the 15.04 one but forgot about all-snaps back then) | 10:10 |
ogra_ | above on the cdimage link are all all-snaps snap artefacts | 10:11 |
mvo | ogra_: I can upload the dragonboard snap thats fine, I will upload to edge and you can test on your board? | 10:11 |
Sin_ | hi, all | 10:11 |
ogra_ | mvo, sure ... but create a new package called canonical-linux-snapdragon then | 10:11 |
ogra_ | and delete the old one | 10:12 |
mvo | ogra_: oh, its called differently? ok | 10:12 |
ogra_ | yeah, and that kernel is supposed to support more snapdragons as i understood | 10:12 |
mvo | ogra_: I assume the dragonboard.device tar file is not available on cdimage? "just" the snap? | 10:12 |
mvo | ogra_: aha, interessting | 10:12 |
ogra_ | the tarballs are still there too | 10:12 |
mvo | ogra_: in the past the tarball device stuff would not boot on the dragonboard | 10:13 |
mvo | ogra_: is that no longer the case, i.e. does it boot now? | 10:13 |
ogra_ | i'm booting the cdimage snaps daily since a few weeks on the dragonboard | 10:13 |
mvo | ogra_: cool | 10:13 |
ogra_ | i admittedly havent tries the rpi in a while ... nor the BBB | 10:13 |
ogra_ | *tried | 10:13 |
Sin_ | how to install apache on a rpi 2 ubuntu snappy core? | 10:14 |
ogra_ | rpi should work after gadget update (will work on that now) ... | 10:14 |
ogra_ | BBB still needs someone to test (but i can do that as well, just later) | 10:14 |
ogra_ | Sin_, sure, you just need to snap it up using snapcraft | 10:15 |
Sin_ | ogra, i'm trying to install snapcraft on rpi, but no luck | 10:16 |
ogra_ | if you are on the 16.04 image: sudo snappy enable-classic; snappy shell classic | 10:16 |
ogra_ | that gives you an apt environment in whicgh you can do work to create snaps | 10:17 |
ogra_ | (you can just apt-get install snapcraft there) | 10:17 |
Sin_ | "ubuntu core does not use apt-get" | 10:18 |
Sin_ | 15.04 img | 10:19 |
ogra_ | Sin_, http://people.canonical.com/~mvo/all-snaps/rpi2-all-snap.img.xz take that one | 10:20 |
Sin_ | thank you! | 10:21 |
=== chihchun is now known as chihchun_afk | ||
asac | sergiusens: i cannot run the 96boards example from withing my snapcraft-master checkout | 11:05 |
asac | it tells me "kernel plugin ot found" | 11:05 |
asac | odd because its in the snapcraft/plugins directory | 11:05 |
asac | are we still supporting running from within tree? | 11:05 |
asac | i am running ../../bin/snapcraft --target arm64 from within that 96b dir | 11:08 |
asac | sergiusens: http://paste.ubuntu.com/15452970/ | 11:08 |
sergiusens | asac, yeah, it is supposed to just work, I've been running in tree | 11:09 |
sergiusens | asac, kernel plugin is not in master | 11:09 |
sergiusens | asac, https://github.com/ubuntu-core/snapcraft/pull/366 | 11:10 |
ogra_ | ppisati, hmm, did you ever get around the FDT_ERR_BADMAGIC on the pi2 ? | 11:11 |
* ogra_ is just trying the -next branch of the firmware | 11:11 | |
ppisati | ogra_: yep, there's a way | 11:11 |
ppisati | ogra_: hold on | 11:11 |
ogra_ | (or do you happen to have an up-to-date packaged version of the firmware) | 11:12 |
ppisati | ogra_: well, the newest formware relocate the dtb in memory | 11:12 |
ppisati | ogra_: so the answer is: | 11:12 |
ppisati | ogra_: https://github.com/piso77/ubuntu-embedded/blob/master/boards/raspi3/rootfs/boot/firmware/config.txt | 11:12 |
ppisati | ogra_: see at the end | 11:13 |
ppisati | ogra_: device_tree_address=0x02000000 | 11:13 |
ppisati | ogra_: and uboot.env needs to be modified to look for the dtb there too | 11:13 |
ppisati | ogra_: here is some more info | 11:13 |
ppisati | https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=134018 | 11:14 |
ppisati | ogra_: search for "The slot at 0x100 is limited to...| | 11:14 |
ppisati | that gives some more context | 11:14 |
ogra_ | ppisati, thanks a lot ! | 11:14 |
ppisati | ogra_: our kernel support teh rpi3 btw | 11:14 |
ogra_ | yeah, but we have no fully working u-boot yet i think | 11:15 |
ppisati | ogra_: yes we do :) | 11:15 |
ogra_ | (i havent checked swarrens branch on the weekend ... last i checked it still was WIP | 11:15 |
ogra_ | ) | 11:15 |
ogra_ | ppisati, oh ! | 11:15 |
ppisati | yeah, i was using that one | 11:15 |
ppisati | and it worked | 11:15 |
ogra_ | for both pi's | 11:15 |
ppisati | no | 11:15 |
ogra_ | ? | 11:15 |
ogra_ | ah | 11:15 |
ppisati | it's not merged | 11:15 |
ogra_ | right+ | 11:16 |
ppisati | one for rpi2 and one for rpi3 | 11:16 |
ogra_ | preferably i'd like to use the same image on both ... for 32bit at least | 11:16 |
kyrofa | Good morning | 11:19 |
ogra_ | hmpf ... | 11:42 |
ogra_ | still not booting the new kernel | 11:42 |
ogra_ | aha | 11:44 |
ogra_ | eeek ! | 11:45 |
ogra_ | ppisati, i get a massive load of "cant mount device as F2FS filesystem" during boot | 11:45 |
ogra_ | purely cosmetic, but looks really scary | 11:46 |
ogra_ | mvo, so i got it booting ... but you wont like the solution ... our dtb from the kernel snap needs to end up in the toplevel of system-boot and overwrite the one from the firmware | 11:48 |
ogra_ | ubuntu@localhost:~$ uname -a | 11:49 |
ogra_ | Linux localhost.localdomain 4.4.0-1004-raspi2 #5-Ubuntu SMP Mon Mar 14 22:27:12 UTC 2016 armv7l armv7l armv7l GNU/Linux | 11:49 |
ogra_ | (using the cdimage kernel snap) | 11:49 |
ogra_ | hmm, and resizing worked just fine | 11:50 |
ogra_ | ubuntu@localhost:~$ df -h |grep /writable | 11:50 |
ogra_ | /dev/mmcblk0p2 118G 151M 111G 1% /writable | 11:50 |
ogra_ | not sure what issue ali1234 had with his | 11:50 |
=== chihchun_afk is now known as chihchun | ||
ogra_ | kyrofa, didnt you also see the rpi not resize ? | 11:50 |
kyrofa | ogra_, indeed, yes | 11:50 |
ogra_ | weird | 11:51 |
kyrofa | ogra_, ppisati I've been seeing garbled HDMI output and evbug errors whenever I press keys on the keyboard as well | 11:51 |
=== chihchun is now known as chihchun_afk | ||
ogra_ | kyrofa, well, lets see if todays update will get you going then | 11:52 |
kyrofa | ogra_, awesome :) | 11:53 |
ogra_ | just need to discuss with mvo what we do with the dtb | 11:53 |
kyrofa | ogra_, so reading the scrollback, it seems you have a booting rpi3? | 11:54 |
ogra_ | (as a quick hack i can indeed just copy it into the gadget, but thats no solution long term) | 11:54 |
ogra_ | kyrofa, no, paolo has ... i'm working on the existing images today ... once we have a release i'll look at the pi3 | 11:54 |
sergiusens | kyrofa, good morning! I could really use a review on the kernel plugin PR ;-) | 11:54 |
kyrofa | ogra_, ah, read too quickly then, but awesome :) | 11:55 |
kyrofa | sergiusens, yessir! Part way through now | 11:55 |
davidcalle | kyrofa: sergiusens: hi, is there a way to add an export to the launch wrapper created by snappy/snapcraft? | 11:55 |
sergiusens | davidcalle, no; the launch wrapper is an implementation detail | 11:55 |
sergiusens | davidcalle, it shouldn't be promoted to anyone ;-) People should write their own wrappers if they need that | 11:56 |
sergiusens | davidcalle, or create a plugin that exports env | 11:56 |
davidcalle | sergiusens: right, so, maybe the best course of action would be to create a wrapper part myself that exports what I want and launch the actual binary | 11:59 |
davidcalle | sergiusens: (first time I'm trying to snap something that's not a terminal game, some concepts and ways of doing things are still abit blurry to me :) ) | 12:00 |
kyrofa | davidcalle, exactly | 12:02 |
davidcalle | kyrofa: sounds good, thanks | 12:02 |
kyrofa | davidcalle, you'll find little wrapper scripts here and there to be pretty central to how things are done | 12:02 |
sergiusens | darn, in an hour I have meetings for 5 hours :-/ | 12:07 |
kyrofa | sergiusens, brutal | 12:07 |
kyrofa | enoch85, you around? | 12:12 |
asac | sergiusens: i am using your feature bran | 12:13 |
asac | ch | 12:13 |
asac | sergiusens: http://paste.ubuntu.com/15452970/ | 12:14 |
davidcalle | dholbach: kyrofa: sergiusens: it worked, thanks a lot :) | 12:14 |
asac | ls -la ../../snapcraft/plugins/kernel.py | 12:14 |
asac | -rw-rw-r-- 1 asac asac 10623 Mar 21 09:55 ../../snapcraft/plugins/kernel.py | 12:14 |
asac | sergiusens: let me know if you need anything | 12:15 |
asac | i am on 559044dc02646a3b10f078bd1d74182a3efd9a8d | 12:15 |
ogra_ | mvo, http://people.canonical.com/~ogra/snappy/canonical-pi2_3.1_all.snap built from https://code.launchpad.net/~ogra/+junk/snappy-systems (see revision 32-34) ... that one boots with the cdimage kernel | 12:44 |
ogra_ | mvo, the dtb problem persistes though and i'm not sure it could boot with a 4.2 kernel at all | 12:45 |
ogra_ | (without manually copying the 4.2 dtb in place) | 12:46 |
ogra_ | mvo, bah, you didnt use any of the cdimage snaps for the store, thats not ok | 12:48 |
ogra_ | (i want to auto-submit them starting this week) | 12:48 |
ogra_ | oh, wait, i got tricked by the versioning | 12:49 |
ogra_ | hmm, no, actually correct, not one of them | 12:50 |
sergiusens | asac, you need to be on f8fea60694c2f2540c9f7490bdd0376848179c1f | 12:50 |
sergiusens | asac, https://github.com/ubuntu-core/snapcraft/pull/366/commits/f8fea60694c2f2540c9f7490bdd0376848179c1f | 12:50 |
dholbach | davidcalle, is it running already? | 12:51 |
davidcalle | dholbach: yep, got it running :) Now, I'm trying to ship games in the snap and have them accessible to it | 12:52 |
dholbach | upload to the store! :) | 12:52 |
dholbach | snapcraft upload! | 12:52 |
ogra_ | mvo, so i think we have to re-do all of this | 12:54 |
ogra_ | we need to use the cdimage snaps here | 12:54 |
davidcalle | dholbach: still trying to figure out some runtime details :) | 13:07 |
dholbach | ok ok :) | 13:07 |
netphreak | Hello, guys! | 13:20 |
mvo | ogra_: sorry, I went for the safe route to ensure the cves are fixed, once they are in stable (i.e. now) I am more than happy to switch to the new artifacts | 13:35 |
mvo | ogra_: this was "upload-cve-fixes-first-without-any-risk" mode | 13:35 |
ogra_ | ? | 13:36 |
ogra_ | these snaps all come from the very latest xenial archive debs | 13:36 |
ogra_ | i would not expect any open CVEs in them | 13:36 |
ogra_ | (they are completely identical to the tarballs ... content wise) | 13:37 |
=== Abhishek__ is now known as Abhishek_ | ||
kyrofa | ogra_, the resize on boot thing, is that for the writable partition? | 13:40 |
ogra_ | yes | 13:40 |
kyrofa | ogra_, should that continue to work if the writable partition is on a separate device? | 13:40 |
jdstrand | mvo: hey, fyi, there is a new xenial kernel that might land today. this is going to require updates to ubuntu-core-security and ubuntu-core-launcher. I'm not sure when you are planning new os and kernel snap updates, but you might want to ping me if you are doing them before wednesday | 13:49 |
elopio | mvo: related to that, if we are going with a two week cadence, we need to prepare today the 16.04 stable release to publish it tomorrow. | 14:00 |
elopio | do you think we should talk to the kernel team first about doing 3 weeks instead of 2? | 14:00 |
noizer | Hi jdstrand short question is it possible to use security-override and caps ( network-listener, ...) together? | 14:05 |
jdstrand | noizer: in 16.04, yes. in 15.04, no | 14:05 |
noizer | jdstrand: ok thx | 14:06 |
mvo | elopio: I think we can do that | 14:08 |
mvo | elopio: i.e. prepare update today | 14:09 |
mvo | elopio: I triggered a new image build | 14:10 |
elopio | mvo: ok. I also like the idea of trying a release tomorrow to get an idea of what will make it easier. We can decide on the # of weeks a little later. | 14:14 |
mvo | elopio: yeah, we did not have a stable release since 8. match, so +1 for a new update | 14:20 |
noizer | Will snappy be compatible with the Raspberry pi 3? | 14:22 |
ogra_ | noizer, yes | 14:23 |
noizer | ogra_: ok that will be nicee | 14:24 |
kyrofa | ogra_, think the writable partition resize would continue to work if it was on another device (e.g. an external HD)? | 14:25 |
ogra_ | kyrofa, thats what my "yes" above was for ... as long as the patition is properly named it should all work | 14:26 |
ogra_ | (and as long as the old label from the old writablöe was removed ... i never tried what happens if you have two of them :) ) | 14:26 |
kyrofa | ogra_, excellent thank you! And yeah, I imagine other problems would occur if that were the case! | 14:26 |
kyrofa | jospoortvliet, are you around? | 14:27 |
noizer | what does the caps exactly with a snap. Does it changes the apparmor profiles? | 14:38 |
asac | noizer: yes under the hoot it generates the profile for that specific app | 14:39 |
sergiusens | ogra_, out of the blue question; how do I build a 32 kernel ofrom an amd64 system? | 14:39 |
ogra_ | sergiusens, hmm, better aks the kernel guys :) | 14:39 |
sergiusens | ppisati, ^ :-) | 14:39 |
asac | sergiusens: -m32? | 14:39 |
asac | :) | 14:39 |
ogra_ | i guess with some clever ARCH= setup | 14:39 |
sergiusens | asac, is that all? | 14:39 |
noizer | asac Is that possible to get the changes for some caps? because i need to make my apparmor myself for my own snaps got special restrictions | 14:39 |
ogra_ | passed to the toolchain | 14:39 |
asac | noizer: are you on 15.04? | 14:40 |
noizer | asac no im on 16.04 rolling | 14:40 |
sergiusens | asac, how about a 32 bit kernel from an armhf system? | 14:41 |
asac | sergiusens: i386_defconfig | 14:41 |
asac | dunno i will check this later and let you know if you havnet found :_) | 14:41 |
asac | you surely would want a cross compiler on armhf | 14:42 |
ogra_ | you want to build an x86 kernel on an arm host ? | 14:44 |
ogra_ | what did you guys smoke today ? | 14:44 |
asac | yeah or on amd64 :) | 14:44 |
asac | its important that you can read live the build process | 14:45 |
ysionneau | hi, does ubuntu-core support booting on a GPT disk? | 14:46 |
ogra_ | ysionneau, indeed | 14:47 |
ysionneau | it seems the init scripts are searching for writable using findfs LABEL=writable, but in GPT you need to do findfs PARTLABEL=writable | 14:47 |
ogra_ | the amd64 and arm64 images default to it | 14:47 |
ogra_ | ysionneau, we set both ... partition label and filesystem label | 14:48 |
ysionneau | I'm on a Tegra X1 board and I'm using my own xml to describe the partitionning | 14:48 |
ysionneau | I guess my issue is in this xml | 14:48 |
ysionneau | I set name="writable" for the partition, but it does not seem to set the label, only the partlabel | 14:49 |
ogra_ | http://paste.ubuntu.com/15463687/ | 14:50 |
ogra_ | ubuntu@localhost:~$ findfs LABEL=writable | 14:50 |
ogra_ | /dev/mmcblk1p9 | 14:50 |
ysionneau | ah, I guess it's my ext4 "file" which is missing its label then | 14:50 |
ogra_ | (thats both on a dragonboard) | 14:50 |
ogra_ | well, ubuntu.-device-flash creates the labels | 14:51 |
ogra_ | before it unpacks the os snap in it | 14:51 |
ogra_ | ("system-boot" and "writable" are the defaults) | 14:51 |
ysionneau | I'm creating the ext4 myself, maybe I should just use udf | 14:53 |
ogra_ | yeah, you definitely should | 14:53 |
kyrofa | ogra_, ah, the pi2 gadget was updated? | 15:08 |
kyrofa | ogra_, means I need to update my fork | 15:08 |
kyrofa | ogra_, what changed? | 15:08 |
ogra_ | kyrofa, last three commits https://code.launchpad.net/~ogra/+junk/snappy-systems | 15:09 |
ogra_ | (i'm about to merge that into the main tree) | 15:09 |
kyrofa | ogra_, ah, very nice. Okay I'll keep an eye out | 15:09 |
sergiusens | kyrofa, meeting? | 15:11 |
kyrofa | sergiusens, sure! I figured you were booked | 15:12 |
sergiusens | kyrofa, join snapcraft | 15:12 |
ysionneau | yeah, I've got snappy booting on the drone board o/ | 15:27 |
didrocks | nice ysionneau \o/ | 15:34 |
joc_ | elopio: ping | 15:37 |
popey | I just updated my snappy machine:- | 15:39 |
popey | /var/lib/dpkg/info/tzdata.config: 379: /var/lib/dpkg/info/tzdata.config: cannot create /etc/timezone: Directory nonexistent | 15:39 |
popey | (sorry, classic dimension) | 15:39 |
popey | (classic)ubuntu@localhost:~$ ls -l /etc/timezone | 15:39 |
popey | lrwxrwxrwx 1 root root 17 Feb 3 09:22 /etc/timezone -> writable/timezone | 15:39 |
popey | that looks wrong (writable/timezone) is in red in my shell | 15:40 |
ogra_ | popey, it exists outside of the classich container | 15:43 |
ogra_ | (and we can only use relative links for that) | 15:43 |
ogra_ | (though even absolute wouldnt help in this case) | 15:43 |
mvo | elopio: I think we have an updated ubuntu-core in 16.04/edge ready for tesing | 15:46 |
elopio | mvo: thanks. I will start. | 15:46 |
mvo | elopio: \o/ | 15:46 |
elopio | mvo: what about the 15.04 update? is it still happening today? | 15:47 |
popey | ogra_: so what's the fix? | 15:47 |
ogra_ | popey, dunno, copy that dir into classic ... (no idea how) | 15:49 |
ogra_ | there are a bunch more files (three iirc) | 15:50 |
ogra_ | in /etc/writable | 15:50 |
joc_ | elopio: hey, the example tests appear to have errored on the plainbox snapcraft PR, would appreciate you having a quick look | 15:51 |
ogra_ | elopio, please take into acocunt that we have a new name for the dragonoboard kernel and that you *need* the new pi2 gadget snap (3.1) to make the 4.4 kernel boot | 15:51 |
elopio | joc_: looking. | 15:55 |
elopio | mvo: the tests are failing on the rollback when comparing the versions: 16.04-20160321-05-01+fake1 <= 16.04-20160321-05-01 | 15:56 |
elopio | that date 20160321-05-01 in the version is new. I suppose the function you wrote to compare is not ready to handle it. | 15:56 |
elopio | ogra_: noted. | 15:57 |
ogra_ | elopio, use ~fake1 ? | 15:57 |
ogra_ | (i would expect this to work the same as dpkg versions) | 15:57 |
mvo | elopio: can you point me to the actual test output please? the statement is correct, I don't think this is a version compare issue | 15:58 |
elopio | mvo: https://paste.ubuntu.com/15464432/ | 15:59 |
mvo | ta | 15:59 |
elopio | mvo: fgimenez was saying that the version maybe shouldn't include the date, because we already have a date field. | 15:59 |
mvo | elopio: aha, I think I have an idea | 16:00 |
elopio | and we can easily change the +fake1 to ~fake1 as ogra says. That's probably better. | 16:00 |
mvo | elopio: that may indeed be a bug in the version compare code, iirc you normally can only have a single "-" but thats ok, should be easy to fix | 16:00 |
ogra_ | elopio, thats a limitation if using cdimage to build the snaps now ... | 16:00 |
ogra_ | (the date in the version string) | 16:00 |
mvo | elopio: I think ~fake1 is not what we want it will be a lower version this way but we want the fake version to be higher | 16:01 |
ogra_ | i cant make cdimage aware of the latest version in the store so that i could bump it or some such ... | 16:01 |
ogra_ | fgimenez, ^^ | 16:01 |
elopio | lower, hum. This version rules are complex. | 16:02 |
elopio | ogra_: I think the output of snappy list will be a lot nicer if we don't have the dates twice. I didn't fully understand what you said about making cdimage aware of the latest version. Could you expand a little on that? | 16:03 |
jdstrand | mvo: hmmm, bug #1553040 seems to be happening on the hour | 16:04 |
ubottu | bug 1553040 in systemd (Ubuntu) "systemd-logind crashed with SIGSEGV" [Medium,Confirmed] https://launchpad.net/bugs/1553040 | 16:04 |
mvo | ogra_: lets wait with that before we figure the actual issue out | 16:04 |
ogra_ | elopio, cdimage doesnt know about the store ... by default it uses version numbers based on the date for everything it builds ... i can neither know what the last version was to bump it nor can i know whats in the store to bump it by 1 | 16:04 |
mvo | jdstrand: meh, that sucks | 16:04 |
jdstrand | I guess I can uninstall ubuntu-core and reinstall | 16:04 |
jdstrand | as a workaround | 16:04 |
mvo | jdstrand: sorry for the language, I think we need to set the priority to high | 16:04 |
mvo | jdstrand: yes, that should work | 16:04 |
jdstrand | mvo: no need to be sorry. it does :) | 16:04 |
ogra_ | elopio, the only safe way to generate a version on cdimage auto-builds is to actually use a version string (or parts of it) | 16:05 |
ogra_ | err | 16:05 |
ogra_ | is to actually use a date string | 16:05 |
ogra_ | :P | 16:05 |
mvo | jdstrand: the real fix is to just ensure the bootloader detection magic is smater and will not attempt to reboot if its not a snappy system | 16:05 |
fgimenez | ogra_, could you use something like curl -s -H "X-Ubuntu-Architecture: amd64" -H 'Accept: application/hal+json' 'https://search.apps.ubuntu.com/api/v1/package/ubuntu-core.canonical/edge' | jq '.version' to get the version? | 16:05 |
elopio | ogra_: could you take the version from the debian changelog? | 16:05 |
* jdstrand nods | 16:05 | |
ogra_ | fgimenez, no, i dont have any access to the outside world during builds | 16:06 |
ogra_ | elopio, which debian changelog ? | 16:06 |
jdstrand | Removing ubuntu-core.canonical | 16:06 |
mvo | elopio, ogra_: lets keep the version for now until this is better understood, it smeels like a bug in the version compare code in snappy | 16:06 |
jdstrand | snappy package cannot be removed | 16:06 |
jdstrand | hmm | 16:06 |
mvo | jdstrand: lol, of course not, can't remove your os | 16:06 |
elopio | mvo: ogra_: sounds good. | 16:06 |
ogra_ | mvo, well, i agree with fgimenez that we shouldnt have the date twice ... but i have no idea wht to do | 16:06 |
mvo | ogra_: oh, thats orthogonal I guess, thats fine | 16:07 |
elopio | what is that -05-01 appended to the date? | 16:07 |
ogra_ | elopio, the os snap isnt bound to any debian/changelog ... and cant be | 16:07 |
ogra_ | elopio, time | 16:07 |
jdstrand | mvo: yes, that obviously makes sense on a device, but sdoc now is interesting... I really should be able to remove that. I guess I can look at the cron job | 16:08 |
elopio | got it. | 16:08 |
jdstrand | not cron | 16:08 |
ogra_ | systemd timer :) | 16:08 |
jdstrand | /lib/systemd/system/snappy-autopilot.timer | 16:08 |
jdstrand | yes, I was getting there :) | 16:08 |
mvo | jdstrand: yes you should | 16:09 |
mvo | jdstrand: I mean, yes you should be able to do that, this was written when we had no idea about this use-case | 16:09 |
jdstrand | mvo: oh sure, I was simply acknowledging that fact :) | 16:10 |
elopio | joc_: looks like an error connecting to the testbed. You can re-try them commenting: "retest this please" | 16:11 |
mvo | jdstrand: yeah :) | 16:15 |
popey | updating my snappy pi.. I get this... | 16:20 |
popey | 2016/03/21 16:19:37.029389 sort.go:162: Invalid version "16.04-20160321-14-25", using '0' instead. Expect wrong results | 16:20 |
popey | is that normal? | 16:20 |
ogra_ | popey, most likely related to the issue that elopio and mvo are looking at above | 16:21 |
popey | oh, sorry | 16:21 |
mvo | popey: yes, thanks, what ogra_ said, but this error message is actually very useful | 16:22 |
popey | Oh good :) | 16:22 |
ogra_ | yeah, that explins elopio's error :) | 16:23 |
ogra_ | *explains | 16:23 |
popey | http://paste.ubuntu.com/15464724/ is the full output fwiw | 16:23 |
ogra_ | popey, funny, i wonder what happens after reboot :) | 16:25 |
ogra_ | seems it thinks it installed them | 16:26 |
mvo | ogra_: I finally looked at this and I think changing the version to only have a single "-" in it would be best if that is possible | 16:26 |
elopio | popey: thanks a lot. So it affects more than the integration tests, and you caught it early :) | 16:26 |
mvo | ogra_: i.e. 16.04+2016032114-25 | 16:26 |
ogra_ | mvo, hmm, yeah ... i can do that but need to re-build and re-upload | 16:27 |
ogra_ | mvo, with a plus sign ? | 16:27 |
mvo | ogra_: yeah, plus is fine | 16:27 |
ogra_ | ok | 16:27 |
mvo | ogra_: or give me a sec and I paste a new string, "-" and ":" are problematic | 16:27 |
mvo | ogra_: "+" and "." are fine | 16:27 |
ogra_ | that takes quite some turnaround time though (livecd-rootfs upload ... waiting for publisher for 2h ... then rebuild and re-upload to the store) | 16:27 |
mvo | ogra_: and "-" is fine as long as there is only one | 16:28 |
popey | Do I dare reboot this? | 16:28 |
ogra_ | do you ? | 16:31 |
jospoortvliet | kyrofa: I'm around now for a bit | 16:36 |
jospoortvliet | sadly, not feeling well today | 16:36 |
ogra_ | mvo, http://paste.ubuntu.com/15464880/ | 16:36 |
jospoortvliet | spend most of the day in bed and will be returning soon | 16:36 |
lool | sergiusens: hey | 16:36 |
kyrofa | jospoortvliet, ah I'm sorry! Nothing important here, go back to bed :) | 16:37 |
mvo | ogra_: maybe a "." in between? "date +20%y%m%d.-%M" ? | 16:37 |
mvo | ogra_: otherwise looks fine | 16:37 |
kyrofa | jospoortvliet, OC9 will be released as soon as it's built | 16:37 |
lool | sergiusens: did we have a nack on supporting patch files in snapcraft, or is this something that just needs work? | 16:37 |
mvo | ogra_: I think we can not avoid this delay, we could unpublish this particular version that is problematic though | 16:37 |
jospoortvliet | kyrofa: rocking | 16:37 |
jospoortvliet | kyrofa: we didn't figure out what PHP modules were missing though | 16:37 |
lool | sergiusens: other question, is there anything discussing extending CFLAGS/CPPFLAGS/LIBS etc. somewhere? | 16:37 |
ogra_ | mvo, i'll upload to the PPA first ... that at least speeds up the publlisher | 16:37 |
kyrofa | jospoortvliet, the images require imagick | 16:38 |
kyrofa | jospoortvliet, that build process is complicated though, so it won't make it by tonight | 16:38 |
jospoortvliet | ok... got it | 16:38 |
kyrofa | jospoortvliet, it's dog slow on the rpi2 too, FYI | 16:38 |
jospoortvliet | kyrofa: yeah, of course... ;-) | 16:39 |
kyrofa | jospoortvliet, things are a bit snappier without it :P | 16:39 |
jospoortvliet | kyrofa: for ownCloud, we should add caching at least, that'll help with performance | 16:39 |
jospoortvliet | quite a bit ;-) | 16:39 |
jospoortvliet | was hoping somebody would help... | 16:39 |
kyrofa | jospoortvliet, yeah, that'll help | 16:40 |
jospoortvliet | btw see https://doc.owncloud.org/server/9.0/admin_manual/installation/source_installation.html for a list of deps that are useful/helpful | 16:40 |
jospoortvliet | add what you can ;-) | 16:40 |
kyrofa | jospoortvliet, yeah I'm familiar with it, the snap config is pretty bare-bones at the moment indeed | 16:41 |
sergiusens | lool, nack on patches | 16:41 |
sergiusens | lool, extend CFLAGS, CPPFLAGS and LIBS where? | 16:41 |
* sergiusens needs to leave for a bit | 16:41 | |
lool | sergiusens: I want to pass an extra flag in CFLAGS to my build on top of the snapcraft ones | 16:42 |
lool | e.g. cmake build, autotools build etc. | 16:42 |
sergiusens | lool, can't you do that with the flags keywords those support? | 16:42 |
lool | I cant extend the current flags with this | 16:43 |
lool | if I say CFLAGS="foo", it will override | 16:43 |
lool | I could try CFLAGS="$CFLAGS foo", but dont think this works | 16:43 |
kyrofa | jospoortvliet, anyway, go back to bed. I'll send out an email | 16:43 |
sergiusens | lool, maybe CFLAGS="$CFLAGS foo" | 16:43 |
jospoortvliet | kyrofa: thanks! | 16:43 |
sergiusens | lool, why do you think it wouldn't ? :-) | 16:43 |
lool | sergiusens: I think I tried it, but I'll try again | 16:43 |
lool | it was before fixing the shell escaping issue, perhaps it works now | 16:44 |
sergiusens | lool, btw, what is your strategy with those PRs? | 16:45 |
ogra_ | lool, stop scaring your shell, then it doesnt try to escape :P | 16:45 |
lool | sergiusens: what's the proposed approach for patches? point at a patched tree? I'm adapting this bb recipe https://github.com/open-switch/ops-build/blob/master/yocto/openswitch/meta-distro-openswitch/recipes-ops/openvswitch/ops-openvswitch.bb which is openswitch's openvswitch build (naming is confusing); it uses upstream's tree and adds openswitch patches; trying to do the same with snapcraft is hard | 16:45 |
lool | sergiusens: I'm about to update them | 16:45 |
sergiusens | lool, the policy is you will have your own tree | 16:46 |
sergiusens | lool, if you think about, that is what patches really are; git just makes patching obsolete | 16:46 |
sergiusens | just look at our ubuntu kernel :-) | 16:46 |
lool | sergiusens: sure, it's just that there is no merge support either, so how do you automatically take latest upstream git with your changes? | 16:48 |
lool | it means people need an automation point on their own | 16:48 |
lool | if we had something like Launchpad git recipes, then it would be fine though | 16:48 |
lool | e.g. I'd point at my branch with patches and merge it with upstream before building | 16:49 |
sergiusens | lool, sorry, I can't follow; but more so because I need to run; can we talk later or tomorrow? | 16:49 |
lool | sure | 16:49 |
lool | ttyl | 16:49 |
mvo | ogra_: thanks | 16:56 |
ogra_ | new image build triggered | 17:22 |
=== heath__ is now known as heath | ||
elopio | thanks ogra_ | 17:38 |
elopio | it's awesome when everything starts to be in place. Now jenkins will notice that a new edge was released, and run all the jobs itself. | 17:38 |
ogra_ | neat ! | 17:39 |
ogra_ | well, the upload is still all me manual ... | 17:39 |
ogra_ | (and a big PITA) | 17:39 |
elopio | oh, sure, it's ci, cyborg integration. | 17:40 |
elopio | I also will need to manually select the channel checkbox z.Z | 17:41 |
joc_ | elopio: unfortunately my "retest this please" comment seems to have been ignored | 17:43 |
elopio | joc_: I think I need to whitelist you so you can retest. | 17:46 |
elopio | let me see. It's still a little confusing this plugin. | 17:46 |
joc_ | elopio: thanks | 17:47 |
elopio | ogra_: can we change also the version of the latest edge snap? | 17:50 |
ogra_ | elopio, which one ? | 17:51 |
ogra_ | i cahnged all versions that are generated by the build to the schema tht mvo suggested above | 17:51 |
ogra_ | $upstream+YYYYMMDD.HH-MM | 17:51 |
elopio | ogra_: in the store, revision #62 edge I see 16.04-20160321-14-13 | 17:51 |
ogra_ | no, tht comes from the snap.yaml | 17:52 |
ogra_ | i dont think thats changeable | 17:52 |
ogra_ | (and i learned today that we cant delte snaps ourselves either) | 17:52 |
elopio | we can upload a new one with the fixed version. | 17:53 |
ogra_ | thats what i will do once this build finished | 17:53 |
elopio | so if I understand correctly, that would mean to go to that cdimage url where you are uploading the snaps, download it and upload it to the store selecting the edge channel. | 17:53 |
ogra_ | exactly, thats what i'm doing all day aleready :) | 17:53 |
elopio | ogra_: ok, so nevermind I said anything. I thought that last part was on mvo's hands. | 17:54 |
ogra_ | i was fiddling with the click-toolbelt stuff to have cdimage auto-upload from there ... but that will still take a few days | 17:54 |
elopio | ogra_: using snapcraft or calling the api directly? | 17:54 |
ogra_ | mvo is the one who needs to approve the snaps to have them published :) | 17:54 |
ogra_ | elopio, 12.04 server ... no snapcraft ... | 17:55 |
ogra_ | thus: click-toolbelt | 17:55 |
elopio | got it, I will be slowly trying to understand all those parts this week. Let me know if I can give you a hand somewhere. | 17:56 |
mvo | ogra_: are they ready already :) ? | 18:10 |
ogra_ | mvo, ready, yes, not uploaded yet | 18:11 |
mvo | ogra_: nice, keep me updated! | 18:13 |
mhall119 | zyga: ping | 18:25 |
=== devil is now known as Guest3520 | ||
ogra_ | mvo, https://myapps.developer.ubuntu.com/dev/click-apps/4142/ (ubuntu-core), https://myapps.developer.ubuntu.com/dev/click-apps/4283/ (canonical-pc-linux (dont forget i386 ;) )), https://myapps.developer.ubuntu.com/dev/click-apps/4284/ (canonical-pi2-linux) | 18:36 |
ogra_ | mvo, https://myapps.developer.ubuntu.com/dev/click-apps/4316/ (canonical-bbb-linux), https://myapps.developer.ubuntu.com/dev/click-apps/4739/ (canonical-snapdragon-linux) | 18:36 |
ogra_ | happy approving :) | 18:36 |
=== Guest3520 is now known as devil__ | ||
=== devil__ is now known as devil_ | ||
elopio | ogra_: mvo: is this a good version for the ubuntu-snappy deb we upload to the PPA? 1.7.3+20160310ubuntu1~ppa14-1 | 18:40 |
elopio | 14 is the number of the build, so it's always increasing. | 18:40 |
ogra_ | why -1 ? | 18:40 |
mvo | elopio: this looks good, you can skip the final "-1" | 18:40 |
ogra_ | :) | 18:40 |
kgunn | ogra_: i haven't check on dragonboard in a while, is it getting any love? or is it roughly in same state as ~January | 18:43 |
ogra_ | kgunn, totally | 18:43 |
ogra_ | the store is full of shiny new packages and we'll do an alpha release this week | 18:43 |
kgunn | cool | 18:44 |
ogra_ | (4.4 kernel is now canonical-snapdragon-linux ... and ubuntu-core for arm64 just got updated) | 18:44 |
ogra_ | we still dont have any classic mode on arm64 though | 18:44 |
popey | ogra_: so will there be another update i can pull down on my edge pi which will replace the busted one? | 18:44 |
popey | (in some hours?) | 18:44 |
ogra_ | popey, why hours ? | 18:45 |
popey | I assume it takes a while :) | 18:45 |
ogra_ | just pour some extra fuel into elopio and it will be fast :) | 18:45 |
elopio | ogra_: mvo: dch adds a 1 at the end. I'm not sure how to remove that. | 18:49 |
elopio | dch --distribution xenial -m --local ~ppa$BUILD_NUMBER- Daily release to the PPA | 18:49 |
elopio | any tips to improve that ^ ? | 18:49 |
ogra_ | hmm, i thought it only does that with explicit -i | 18:51 |
mvo | elopio: its fine, it won't hurt | 18:51 |
kyrofa | sergiusens, this should look familiar, but a bit easier to review: https://github.com/ubuntu-core/snapcraft/pull/384 | 19:52 |
kyrofa | elopio, ^^ | 19:52 |
sergiusens | kyrofa, my comments weren't exported though :-P | 19:55 |
kyrofa | sergiusens, unfortunately not :( . Darn intermediate branch. I wish I could change the PR partway through | 19:59 |
kyrofa | sergiusens, but the complicated bits (strip cleaning) aren't here anymore, so your comments wouldn't be relevant anyway | 19:59 |
sergiusens | kyrofa, heh :-) I search for the closed one and replicate | 20:00 |
sergiusens | kyrofa, oh they aren't? I don't want to blindly trust you though ;-) | 20:00 |
kyrofa | Haha, no don't trust me! I realized a lot of that other PR didn't have anything to do with strip cleaning-- there was a bit of setup to do it. This PR is that "bit of setup" | 20:00 |
kyrofa | So then subsequent PRs can just fill in their little bits | 20:01 |
kyrofa | sergiusens, smaller PRs=better | 20:01 |
sergiusens | kyrofa, oh, you removed the strip part | 20:03 |
kyrofa | sergiusens, right | 20:03 |
sergiusens | kyrofa, got it; I still managed to add MOAR comments ;-) | 20:03 |
kyrofa | Yeah I keep forgetting about !r | 20:04 |
sergiusens | kyrofa, btw, somethings failed here https://github.com/ubuntu-core/snapcraft/pull/383 | 20:04 |
kyrofa | sergiusens, hmm... | 20:06 |
kyrofa | sergiusens, huh... I can't connect to the VPN at the moment. NM is telling me it doesn't have permission | 20:12 |
sergiusens | kyrofa, heh, I hate nm :-P | 20:12 |
kyrofa | *sigh* | 20:12 |
sergiusens | kyrofa, elopio btw, I am doing some manual traffic shaping on which PR gets tested next | 20:12 |
kyrofa | I'd totally reboot, but I have an emergency build of owncloud going that I can't stop | 20:12 |
kyrofa | sergiusens, no problem | 20:13 |
sergiusens | kyrofa, ssh and screen ;-) | 20:13 |
kyrofa | sergiusens, screen doesn't work in classic | 20:13 |
kyrofa | sergiusens, otherwise that's the obvious choice | 20:13 |
sergiusens | kyrofa, if it is a serial connection it would be fine | 20:13 |
kyrofa | sergiusens, :P | 20:13 |
sergiusens | to disconnect and reconnect | 20:13 |
kyrofa | sergiusens, SSH I'm afraid | 20:13 |
zyga | mhall119: hey | 20:55 |
sergiusens | kyrofa, testing is taking forever :-P | 21:11 |
kyrofa | sergiusens, yeah, killer | 21:11 |
mhall119 | zyga: hey, I had a task to follow up with you about show to ship apps written for the phone/tablet on a the snappy desktop, do we have a plan for how we're going to approach that for 16.04? | 21:18 |
mhall119 | last we spoke you were still workign that out | 21:18 |
kyrofa | jdstrand, I've got two owncloud.canonicals in the manual review queue for network-listener. Mind taking a look? | 21:24 |
jdstrand | kyrofa: approved | 21:28 |
kyrofa | jdstrand, thank you! | 21:30 |
zyga | mhall119: I think that hasn't changed since, we're still tying loose knots together to make the system work | 21:30 |
zyga | mhall119: I think we're still a bit behind there on what we aim to deliver | 21:31 |
mhall119 | zyga: with it using the snappy space, will we be able to land that feature for users of 16.04 even after release? Or will it have to wait until 16.10? | 21:40 |
sergiusens | kyrofa, care to rebase https://github.com/ubuntu-core/snapcraft/pull/384 ? | 21:42 |
zyga | mhall119: I'm almost 100% sure that we'll land updates across all systems | 21:44 |
zyga | mhall119: we really need to land all the key things for 16.04 but we'll be making updates as the system evolves; AFAIR we're still trying to determine exactly how snappy updates in ubuntu will look like but that's the plan | 21:45 |
mhall119 | zyga: ok, can you send an update to the email thread dholbach started, titled "Releasing the SDK libs as a snap" with the current state of things? | 21:48 |
zyga | mhall119: yes, I'll read updates since I replied initially and I'll do my best to reply | 21:49 |
mhall119 | thanks, just to keep everybody in the loop updated | 21:49 |
popey | error: owncloud-pi2.kyrofa failed to install: gadget package installation not allowed | 21:51 |
popey | should I be able to install that? | 21:51 |
sergiusens | popey, no, gadgets are only allowed during image creation | 22:02 |
davidcalle | sergiusens: hi again, is there a way to put myself in the position of my snap, with the same constraints and path, and run commands (and maybe install packages)? | 22:05 |
davidcalle | paths* | 22:06 |
popey | sergiusens: shouldn't they be hidden from snapy find then? | 22:21 |
sergiusens | popey, oh they should; I made that statement or logged a bug about that or told stevebiscuit | 22:30 |
sergiusens | I forget which | 22:30 |
sergiusens | that and other kernels | 22:30 |
sergiusens | and also other uninstallables | 22:31 |
sergiusens | davidcalle, there's supposed to be a `snappy shell <snap>` ... but zyga | 22:31 |
sergiusens | lol, that came out wrong; I mean zyga can expand on if that is implemented or no | 22:31 |
sergiusens | t | 22:31 |
wililupy | Question: Whats the best documentation for building Kernel Snaps? | 23:08 |
sergiusens | elopio, care to look at https://github.com/ubuntu-core/snapcraft/pull/386/files | 23:40 |
sergiusens | wililupy, wait for snapcraft 2.5 to be announced later tonight or early in the morning | 23:41 |
wililupy | sergiusens: ack | 23:41 |
elopio | sergiusens: looks good. Are you going to include these two fixes I have in-progress? | 23:41 |
sergiusens | elopio, nah; we will get those in on Wednesday | 23:42 |
sergiusens | elopio, I have a bunch of small fixes to get in | 23:42 |
sergiusens | these can go there | 23:42 |
elopio | sergiusens: will you open a new milestone for the wednesday or should I target these bugs to 2.6? | 23:46 |
sergiusens | elopio, 2.6 | 23:51 |
sergiusens | elopio, 2.6 is the wednesday milestone ;-) | 23:51 |
sergiusens | we are releasing 2.5 today :-) | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!