| === tgm4883_ is now known as tgm4883 | ||
| beuno | ogra_, it does not | 05:36 |
|---|---|---|
| beuno | (include types) | 05:36 |
| === hikiko__ is now known as hikiko | ||
| === kickinz1|eow is now known as kickinz1 | ||
| dholbach | good morning | 07:02 |
| davidcalle | Morning o/ | 07:35 |
| clobrano | Morning :) | 07:36 |
| clobrano | Chipaca: thank you ;) | 07:36 |
| === lan3y is now known as Laney | ||
| === Laney is now known as Guest61035 | ||
| === Guest61035 is now known as Laney | ||
| longsleep | Good morning snappy! | 08:18 |
| ogra_ | moin moin | 08:21 |
| longsleep | ogra_: nice release for the rpi2 - i whish i also could use a recent kernel :/ | 08:26 |
| longsleep | btw, i found why recent u-d-f stopped working for me - bug #1499993 | 08:27 |
| ubottu | bug 1499993 in Snappy "U-d-f uses hardcoded names for kernel and initrd instead of the ones defined in hardware.yaml" [Undecided,New] https://launchpad.net/bugs/1499993 | 08:27 |
| ogra_ | longsleep, sadly the verioned approach didnt work properly ... not sure what we can do (beyond finally getting a kernel snap), i guess we need to discuss that | 08:29 |
| === _morphis is now known as morphis | ||
| longsleep | ogra_: you mean the webdm issue cannot be fixed? | 08:33 |
| ogra_ | webdm ? | 08:33 |
| * ogra_ reads the bug again | 08:33 | |
| longsleep | the problem that webdm did not work for side loaded oem snaps? | 08:33 |
| ogra_ | oh, i belive Chipaca already has a fix for that, just needs some testing | 08:34 |
| longsleep | ogra_: no my issue has nothing todo with webdm, but that could be fixed by adding a way to define the names for kernel and initrd files | 08:34 |
| longsleep | ogra_: ok good, but you think the issue with the file name has todo with versioning? | 08:34 |
| longsleep | i guess i can name the uImage vmlinuz and the uInitrd initrd.img but that feels wrong | 08:35 |
| ogra_ | indeed it does ... i didnt say its not a bug :) | 08:36 |
| longsleep | and i miserably failed to get the odroid boot a zImage on the weekend .. | 08:36 |
| longsleep | Nny suggestions on how to debug early kernel load errors without having hardware support for to dump printk buffer on the console would be most welcome :) | 08:38 |
| ogra_ | there is an android option to support /proc/last_kmesg .... i have seen that function in non android kernels in the past | 08:41 |
| ogra_ | hmm, though that wouldnt help in this particular case (where you cant boot at all) | 08:42 |
| longsleep | ogra_: how would that work when the kernel fails to boot | 08:42 |
| ogra_ | yeah, sorry, brainfart | 08:42 |
| longsleep | ogra_: yeah - the problem is that the kernel seems to crash or stop in uncompress - at least before flushin the printk buffer for the fist time | 08:42 |
| longsleep | essentially i see nothing until u-boot gave over to the kernel | 08:43 |
| ogra_ | probably ppisati has an idea ... but i think he is out for another week | 08:43 |
| longsleep | and i "think" i got the zImage and initrd patch right - the bytes for the kernel image look right | 08:43 |
| longsleep | but it just crashes | 08:43 |
| ogra_ | he might know a trick to make uboot more verbose or some such | 08:43 |
| longsleep | well, in u-boot i have added debug and everything looks good | 08:44 |
| ogra_ | i assume you already use "earlyprintk" on your cmdline ? | 08:44 |
| longsleep | yes but that does not help so much when the arm hardware does not have a kernel debug driver to log this stuff to the serial console | 08:44 |
| longsleep | i currently think it is some crazy thing which is missing in u-boot when using bootz instead of bootm, though i did debug this and did not find any :/ | 08:46 |
| longsleep | ogra_: this means for now the only way seems to be to use the hardcoded names for kernel and initrd even if they have different formats. My fear is that they would be overwritten on update - or is that prevented somehow then a custom kernel was used during image creation? | 08:50 |
| ogra_ | no, that was solely because we ended with duplicated kernels on upgrades when we used versioned binaries (i think nobody took uImage into account when that was hacked in) | 08:51 |
| ogra_ | not supposed to be or stay like that ... | 08:52 |
| longsleep | ogra_: ah you mean that was the reason to hardcode the file name? | 08:52 |
| ogra_ | yes | 08:52 |
| longsleep | i see - so you think i can just use those file names and they would be overwritte on ubuntu-core update? | 08:53 |
| ogra_ | and whoever landed it had already worked an 18h day and was focused on amd64 for the last days :) | 08:53 |
| ogra_ | we need to look at it again and see how to get the old support back in | 08:53 |
| longsleep | mhm the patch was made by sergiusens but it was in July already | 08:54 |
| ogra_ | hmm | 08:54 |
| longsleep | "Normalize kernel and initrd with proper templating. by sergiusens approved by chipaca" | 08:55 |
| ogra_ | i think u-d-f calls snappy at some point during installation ... | 08:55 |
| ogra_ | i'd rather suspect a snappy patch from mvo from the last two weeks that broke it | 08:55 |
| longsleep | no http://bazaar.launchpad.net/~phablet-team/goget-ubuntu-touch/trunk/revision/195 | 08:56 |
| longsleep | look at the changes in core_uboot.go | 08:56 |
| longsleep | before it took whatever filename it got and copied to destination folder | 08:56 |
| ogra_ | hmm, right | 08:56 |
| longsleep | now it copies not to the folder but to the hardcoded filename | 08:56 |
| longsleep | so it does not seem to be related to the changes from the last weeks | 08:57 |
| ogra_ | indeed | 08:57 |
| ogra_ | well, i'll bring it up with the team ... thouh everyone is at a sprint in budapest this week | 08:57 |
| ogra_ | response time might not be great | 08:58 |
| longsleep | no worries - i will experiment with using these names for uInitrd and uImage and might eventually get the device to boot zImage as well | 08:59 |
| JamesTait | Good morning all; happy Monday, and happy Drink Beer Day! 😃 | 09:02 |
| Chipaca | good morning people | 09:20 |
| Chipaca | longsleep: if it's broken, it might be my fault, whatever it is :) | 09:20 |
| Chipaca | longsleep: I seem to have fixed webdm, but haven't uploaded it; I can give it to you to try if you want. | 09:21 |
| Chipaca | ogra_: what's uImage? | 09:22 |
| longsleep | Chipaca: uImage is the same as zImage but with a u-boot compatible container | 09:34 |
| Chipaca | ah | 09:34 |
| Chipaca | longsleep: ogra_: when we did that boot simplification we knew we were most likely missing some ... *ahem* ... "corner cases" | 09:34 |
| Chipaca | but the good news it should now fit in our puny little brains and let us extend it | 09:34 |
| Chipaca | (note i haven't read all the backlog so i might be missing something ;) ) | 09:35 |
| longsleep | Chipaca: http://www.denx.de/wiki/view/DULG/UBootImages | 09:35 |
| longsleep | Chipaca: well - yeah i was not able to follow the changes in july so closely as i should have | 09:36 |
| Chipaca | what's "unity os"? :) | 09:36 |
| longsleep | i have no idea | 09:36 |
| Chipaca | neither does wikipedia | 09:36 |
| Chipaca | anyway. gotcha wrt header. | 09:36 |
| longsleep | Chipaca: u-boot learned to boot linux zImage and initrd without u-boot container on 2012-03-30 | 09:38 |
| longsleep | as lots of arm devices use u-boot from 2011 they do not support it and need uImage and uInitrd :/ | 09:38 |
| Chipaca | that's relatively recent compared to lead times in getting uboot on the hardware | 09:38 |
| Chipaca | yeah | 09:38 |
| Chipaca | hard to argue when getting a newer uboot means having to use a more expensive provider | 09:39 |
| longsleep | the patches are small, but i failed to get the ODROID boot a zImage so far .. | 09:39 |
| Chipaca | (or is uboot firmware?) | 09:39 |
| longsleep | yes u-boot is firmware | 09:40 |
| Chipaca | ah! we should be able to fix that then :) | 09:40 |
| longsleep | the soc manufacturer usually ships a tree | 09:40 |
| longsleep | err no | 09:40 |
| Chipaca | aw | 09:40 |
| longsleep | those trees are very messy and most often do not share common git history with upstream u-boot | 09:40 |
| longsleep | for the aml meson8 platform the patch set is about 10000 lines of terrible patch code | 09:41 |
| longsleep | which will never be upstreamed to u-boot head | 09:41 |
| longsleep | and also cannot be rebased on upstream because u-boot has changed a lot since 2011 | 09:42 |
| longsleep | imho snappy should be able to work without too much pain when u-boot does not support bootz command | 09:43 |
| Chipaca | ogra_: do you know offhand where the generic-* snaps are built from? | 10:06 |
| Chipaca | CPI seems to think they are architecture:all | 10:06 |
| Chipaca | which is probably wrong :) | 10:06 |
| ogra_ | Chipaca, https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems | 10:06 |
| Chipaca | ogra_: ta | 10:06 |
| Chipaca | ah, indeed, no architecture header | 10:07 |
| Chipaca | need to query mvo & sergio about that | 10:07 |
| Chipaca | s/header/package.yaml top-level line/ | 10:07 |
| Chipaca | ogra_: echo "config: {ubuntu-core: {autopilot: false}}" | sudo snappy config ubuntu-core - | 10:13 |
| Chipaca | i find the yaml spec hard to read as a quick reference, but the above works \o/ | 10:13 |
| * ogra_ finally managed to file bug 1500375 | 10:13 | |
| ubottu | bug 1500375 in Snapcraft "inconsistent build results due to wrong usage of recommends" [Undecided,New] https://launchpad.net/bugs/1500375 | 10:13 |
| ogra_ | Chipaca, oh, no -- - anymore ? | 10:14 |
| Chipaca | ogra_: yeh, not sure when we picked that one up :) | 10:14 |
| * ogra_ makes a mental note | 10:14 | |
| Chipaca | ogra_: but what i was pointing at was the lack of \ns and faffing with indentation for a single value | 10:15 |
| ogra_ | yeah ! | 10:15 |
| Chipaca | turns out, yaml has something it calls json-compatible maps | 10:15 |
| Chipaca | which i should look into sometime | 10:15 |
| Chipaca | not today tho :) | 10:15 |
| Chipaca | ogra_: now, because it's yaml, the whitespace there is needed :-/ | 10:16 |
| Chipaca | but a single space is tolerable | 10:16 |
| ogra_ | yeah, definitely better than before | 10:16 |
| * ogra_ notes that nobody from the budapest crowd is online ... must have been good beer last night :) | 10:25 | |
| * ogra_ grumbles about bug 1500020 | 10:28 | |
| ubottu | bug 1500020 in ubuntu-core-config (Ubuntu) "/var/lib/opencryptoki needs to be in /etc/system-image/writable-paths" [Undecided,New] https://launchpad.net/bugs/1500020 | 10:28 |
| ogra_ | i dont get why i dont see it on amd64 | 10:28 |
| ricmm | ogra_: we are all online | 11:44 |
| ricmm | well not all I guess | 11:44 |
| ogra_ | :) | 11:44 |
| === bigcat is now known as kengyu | ||
| === kengyu is now known as bigcat | ||
| biezpal | asac, hey, is there any updates about https://bugs.launchpad.net/snappy/+bug/1498396 ? | 12:40 |
| ubottu | Launchpad bug 1498396 in Snappy "Random string in data path breaks application" [Undecided,New] | 12:40 |
| biezpal | asac, it's really important for us.. | 12:41 |
| ogra_ | biezpal, the "current" link for data paths is supposed to re-appear | 12:41 |
| ogra_ | but i doubt that will happen before the next stable release | 12:41 |
| ogra_ | Chipaca, ^^^ do you knwo if anyone already works on this ? | 12:42 |
| biezpal | ogra_, cool, thanks | 12:42 |
| Chipaca | ogra_: it's next in my list, i think | 12:42 |
| ogra_ | (also note that most of the snappy team is at a sprint this week ... quick answers might be rare :) ) | 12:43 |
| biezpal | hmm, maybe it's a right time to participate in snappy development :) | 12:46 |
| ogra_ | every time is the right time for that :) | 12:47 |
| ogra_ | don't hold back :) | 12:47 |
| longsleep | this reminds me, my boss told me he signed the Ubuntu Contributor Agreement, anyone can check? | 12:48 |
| Chipaca | longsleep: when did he do it? | 12:48 |
| longsleep | Chipaca: Friday maybe or on the weekend, though it might be possible he already did it a month back (quote) | 12:49 |
| Chipaca | longsleep: basically, you (or your company? not sure how it works for companies -- i should check) would appear in https://launchpad.net/~contributor-agreement-canonical | 12:49 |
| Chipaca | longsleep: if it's been processed, that is | 12:49 |
| longsleep | let me check | 12:50 |
| Chipaca | longsleep: there was a bit of a backlog but it should be cleared now (the person that used to do it left, and we bungled the transition) | 12:50 |
| longsleep | Chipaca: Companies should appear there too? | 12:51 |
| Chipaca | that's what i don't know :) | 12:51 |
| longsleep | Chipaca: anyhow neither company nor name on the list, but i do not see any companies there | 12:52 |
| Chipaca | yep | 12:52 |
| Chipaca | and the person that i'd ask is not on irc right now; poking up the chain | 12:53 |
| Chipaca | hah! had her timezone wrong. she should be around soon. | 12:53 |
| longsleep | Chipaca: ok great thanks - i will resume work on snapcraft later this week and i would like to be produce mergeable patches this time | 12:54 |
| ogra_ | these slackers in the US only start working in the afternoon ... | 12:54 |
| * Chipaca understands | 12:54 | |
| ogra_ | they should take the chinese as example ! they start working in the middle of the night already :) | 12:54 |
| longsleep | but they leave at 4 | 12:55 |
| ogra_ | true | 12:55 |
| * longsleep wakes up at 4 | 12:55 | |
| longsleep | p.m.! | 12:55 |
| ogra_ | crazy | 12:55 |
| ogra_ | hah | 12:55 |
| Chipaca | so, i should adopt the best of both worlds | 12:55 |
| longsleep | <<< nick name | 12:55 |
| Chipaca | start working in the afternoon, leave at 4 | 12:55 |
| Chipaca | \o/ | 12:55 |
| ogra_ | perfect ! | 12:55 |
| longsleep | Chipaca: best would be to add our https://launchpad.net/~strukturag team to the cla team if any such thing is possible | 12:57 |
| Chipaca | longsleep: i'll check | 12:57 |
| * Chipaca ~> lunch | 13:27 | |
| * ogra_ takes a bit of Chipaca | 13:28 | |
| ogra_ | *bite | 13:28 |
| Chipaca | ogra_: ow | 13:41 |
| ogra_ | well, if you turn into lunch you shoudl expect that :) | 13:42 |
| Chipaca | ogra_: not my fault you can't tell apart a "transforms into" arrow from a "begets" arrow | 13:43 |
| ogra_ | haha | 13:43 |
| === Guest62641 is now known as balloons | ||
| sergiusens | zyga, https://wiki.ubuntu.com/Snappy/Parts | 14:01 |
| ogra_ | sergiusens, if the beer at the bar gets boring in the evening ... bug 1500375 | 14:02 |
| ubottu | bug 1500375 in Snapcraft "inconsistent build results due to wrong usage of recommends" [Undecided,New] https://launchpad.net/bugs/1500375 | 14:02 |
| ogra_ | ;) | 14:02 |
| sergiusens | ogra_, oh, we used to do no recommends, I guess it got lost when we moved to our private apt cache | 14:07 |
| ogra_ | well, i dont care either way, only the consistency counts | 14:08 |
| ogra_ | (i gues without recommends is generally better for this use case though) | 14:09 |
| ogra_ | apw, hmm, is rtg on vacation too (i know ppisati is) | 14:13 |
| T-mon | hello everybody! Since the last update my sideload snappy packages get some kind of uuid as version | 14:29 |
| T-mon | is there a possiblilty to keep the snap version? | 14:30 |
| ogra_ | nope | 14:30 |
| === ralsina_ is now known as ralsina | ||
| T-mon | I see the pros/cons of that concept...but it would be helpfull if this could be configurable :) | 14:31 |
| ogra_ | T-mon, there sill be a "current" link in the /apps/<package>/<version> dir | 14:33 |
| ogra_ | err | 14:33 |
| ogra_ | in the ~/apps/<package>/<version> dir | 14:34 |
| ogra_ | regenerating the version at install time is necessary because you can keep the same version when generating a sideload snap ... installing the same version again wouldnt update the confinement profiles | 14:35 |
| T-mon | ogra_: yes, but my confs are gone with each new upload and I have to figur out the name of the sevice bfore i can follow the service log | 14:35 |
| ogra_ | the UUID enforces that | 14:35 |
| T-mon | yes :) that is one of the benefits | 14:36 |
| T-mon | it makes the development harder...and easier, depending on what you are doing | 14:38 |
| ogra_ | well, it makes sure security cant be broken ... | 14:38 |
| ogra_ | which was the case before | 14:38 |
| T-mon | is this only for sideloads or also for store versions? | 14:40 |
| ogra_ | only sideloads | 14:41 |
| ogra_ | in the store you can upload the same version twice | 14:43 |
| T-mon | so i loose the configs in every new version? | 14:46 |
| T-mon | if I use /var/lib/apps/... | 14:47 |
| ogra_ | why would you ? | 14:47 |
| ogra_ | existing configs get forward copied since forever on upgrades | 14:47 |
| T-mon | I am using the SNAP_APP_DATA_PATH for configs | 14:48 |
| * ogra_ too | 14:48 | |
| ogra_ | never had issues with it | 14:48 |
| T-mon | ok, have to check that again... | 14:50 |
| T-mon | I always remove the old version before uploading the new one...maby I sould not do that? :D | 14:51 |
| ogra_ | ah, yeah, then snapp cant really forward copy anything | 14:51 |
| ogra_ | *snappy | 14:51 |
| * T-mon testing | 14:52 | |
| T-mon | ok :) not removing did the trick :D | 14:55 |
| T-mon | thx | 14:55 |
| ogra_ | :D | 14:58 |
| tedg | sergiusens: Idea: What if we had a global debug flag that would install debug symbol packages and compile things with debug symbols. | 14:58 |
| tedg | sergiusens: Or, I guess, we should have some way to pull the symbols out of a package to generate our own symbols packages. | 14:59 |
| ogra_ | tedg, uhm, that might make you end up with gigantic snaps | 14:59 |
| tedg | ogra_: Sure, but for developer debugging, not for release. | 14:59 |
| ogra_ | well, we should be pretty clear about what it does | 15:00 |
| tedg | But it would be interesting if you could strip all those symbols out as a whole and then interpret crashs with *all* the symbols. | 15:00 |
| * ogra_ imaines someone packaging wget and using that flag ... and then ending up with a 50MB wget snap while he just wanted to debug a wrapper script for the deb wget | 15:00 | |
| apw | ogra_, i thought he was about | 15:06 |
| ogra_ | apw, yeah, i catched him on the internal channel | 15:07 |
| tedg | ogra_: I think it shouldn't be a flag that is used lightly :-) | 15:14 |
| tedg | And we shouldn't take them in the store. | 15:15 |
| elopio | tedg: it sounds really useful for snapcraft run. | 15:16 |
| ogra_ | tedg, and we should have detailed documentation about it :) | 15:18 |
| tedg | And a big warning: <blink>DEVELOPER MODE ENABLED, MAY CAUSE A BLACK HOLE, BE VERY CAREFUL</blink> | 15:19 |
| ogra_ | also <red></red> ... <blink> alone is rarely enough :) | 15:20 |
| sergiusens | rickspencer3, install godd :-) | 15:31 |
| rickspencer3 | lol | 15:31 |
| jdstrand | sergiusens: are you still around? | 15:56 |
| jdstrand | sergiusens: I have a two quick questions on snapcraft and the review tools. I want to file a bug but not sure who is at fault | 15:58 |
| sergiusens | jdstrand, I'm still here | 15:58 |
| sergiusens | jdstrand, you can default to affecting both and we can later invalidate one or maybe none if both are wrong :-) | 15:58 |
| jdstrand | let me get a paste | 15:59 |
| jdstrand | right, but if it is in the review tools I wanted to fix it today | 15:59 |
| ogra_ | just file it against https://launchpad.net/~sergiusens and it will get fixed :) | 16:00 |
| jdstrand | sergiusens: http://paste.ubuntu.com/12603461/ | 16:00 |
| jdstrand | sergiusens: in the past, we said that 'architectures' was deprecated and people should use 'architecture' now. snapcraft is using 'architectures' | 16:00 |
| jdstrand | sergiusens: is that intentional? (ie, should I change the review tools?) | 16:00 |
| jdstrand | sergiusens: the other is the external symlinks check (external symlinks are where an app has a symlink to something outside of its app dirs). are external symlinks something that is supposed to be allowed? I can say in the case of this snap, /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/security/cacerts would be a dangling symlink | 16:03 |
| jdstrand | sergiusens: the security policy handles this fine, but the check is there to try to alert people to issues in their snap, since a symlink out to a minimal system like Ubuntu Core is likely dangling | 16:04 |
| sergiusens | jdstrand, architectures is deprecated? I thought it was the other way around | 16:07 |
| jdstrand | sergiusens: the tools enforce 'architecture' and have for a while | 16:08 |
| sergiusens | hmm, Chipaca can you chime in? | 16:08 |
| Chipaca | whu? | 16:08 |
| Chipaca | sergiusens: context? | 16:09 |
| sergiusens | Chipaca, architectures and not 'architecture' | 16:09 |
| jdstrand | ./go-example-webserver/meta/package.yaml:architecture: [amd64, armhf] | 16:09 |
| jdstrand | ./hello-dbus/package-dir-fwk/meta/package.yaml:architecture: [amd64, armhf, i386] | 16:09 |
| jdstrand | ./hello-dbus/package-dir-app/meta/package.yaml:architecture: [amd64, armhf, i386] | 16:09 |
| Chipaca | yech | 16:09 |
| jdstrand | snappy-examples use 'architecture' | 16:09 |
| jdstrand | snapcraft uses 'architectures' | 16:10 |
| sergiusens | Chipaca, yech? | 16:10 |
| Chipaca | sergiusens: ugly | 16:10 |
| jdstrand | the review tools know about 'architecture' and complain on 'architectures' | 16:10 |
| Chipaca | let me confirm it's the right way around at least :) | 16:10 |
| sergiusens | jdstrand, yeah, the examples have this big problem of always lagging on change :-/ | 16:10 |
| Chipaca | no, that's backward | 16:10 |
| Chipaca | "architecture" is the deprecated one | 16:10 |
| ogra_ | and the format seems different | 16:10 |
| ogra_ | architectures: | 16:11 |
| Chipaca | DeprecatedArchitecture deprecarch `yaml:"architecture"` | 16:11 |
| ogra_ | - amd64 | 16:11 |
| Chipaca | Architectures []string `yaml:"architectures"` | 16:11 |
| ogra_ | thats what i have in snapcraft-built snaps | 16:11 |
| Chipaca | and that is correct | 16:11 |
| ogra_ | (no brackets and a dash) | 16:11 |
| sergiusens | jdstrand, what we do do, is have manifest.json write 'architecture' to not break the store, but in package.yaml, 'architectures' is preferred | 16:12 |
| ogra_ | (and also on a new line) | 16:12 |
| jdstrand | is architectures still a list? | 16:12 |
| jdstrand | sergiusens: ^ | 16:14 |
| jdstrand | ok, so I'll fix the tools for architectures | 16:16 |
| sergiusens | jdstrand, architectures is a list and only a list (contrary to architecture which would be both a string and a list) | 16:17 |
| jdstrand | sergiusens: can you comment on the symlinks issue? | 16:17 |
| jdstrand | sergiusens: re list> ack, I'll fix | 16:17 |
| jdstrand | sergiusens: but note, 'snapcraft' produced a snap with the architecture warning in the past, so if it is meant to be compliant with the store, it isn't | 16:18 |
| jdstrand | s/past/paste/ | 16:18 |
| sergiusens | jdstrand, wait, what symlink issue? | 16:22 |
| jdstrand | sergiusens: http://paste.ubuntu.com/12603461/ | 16:22 |
| sergiusens | jdstrand, that's a bug! | 16:22 |
| sergiusens | :-) | 16:22 |
| jdstrand | ok, so there is a review tools bug and a snapcraft bug | 16:22 |
| * jdstrand files | 16:22 | |
| sergiusens | jdstrand, thanks | 16:22 |
| jdstrand | sergiusens: note, these are going to block store uploads (which is why I'm fixing the review tools one today) | 16:23 |
| sergiusens | jdstrand, I'll be fixing these fast | 16:25 |
| sergiusens | jdstrand, if you have a part that generates this bug please put it in the bug and I'll fix | 16:25 |
| jdstrand | sergiusens: just so we're clear, I'll fix the review tools | 16:29 |
| jdstrand | sergiusens: for architectures | 16:30 |
| fgimenez | elopio, some progress on https://bugs.launchpad.net/snappy/+bug/1498293 | 16:31 |
| ubottu | Launchpad bug 1498293 in Snappy "fake rollback integration test fails" [Undecided,New] | 16:31 |
| elopio | fgimenez: haven't looked at it yet. | 16:31 |
| fgimenez | elopio, this is the patch i used to get the grubenv contents http://paste.ubuntu.com/12603681/ | 16:32 |
| elopio | fgimenez: I thought it was reproducible, but as you said it seems random. I got two good and one bad today. | 16:33 |
| jdstrand | sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1500505 | 16:33 |
| ubottu | Launchpad bug 1500505 in Snapcraft "snapcraft produces snaps with dangling external symlinks" [Undecided,New] | 16:33 |
| elopio | it might be a real bug. I'll do more runs on the evening. | 16:33 |
| fgimenez | elopio, ok, i'll catch up tomorrow, nice evening everyone | 16:33 |
| vmayoral|pc | chipaca: ping | 16:54 |
| Chipaca | vmayoral|pc: pong | 16:54 |
| Chipaca | *just* :) | 16:55 |
| vmayoral|pc | chipaca: do you know if there's a tool to make a snap inactive (disable it)? | 16:55 |
| Chipaca | vmayoral|pc: no, but it's easy to do | 16:56 |
| ogra_ | vmayoral|pc, there is an "unpublich" button in the store page of each app | 16:56 |
| ogra_ | *unpublish | 16:56 |
| Chipaca | well, easy-ish | 16:56 |
| Chipaca | vmayoral|pc: what's your use case? | 16:56 |
| Chipaca | vmayoral|pc: or, in clearer language, what're you trying to do? | 16:57 |
| vmayoral|pc | chipaca: so we'll have snaps that are several MBs and we'd prefer not installing them every time | 16:58 |
| vmayoral|pc | if the "disable" tool from webdm doesn't get rid of the packages then that works | 16:58 |
| Chipaca | i'm not sure, but "disable" might mean turn off services, in that context | 16:59 |
| Chipaca | vmayoral|pc: i'm not sure i understand the connection between "installing them every time" and not getting rid of the packages | 16:59 |
| Chipaca | i'm missing something :-/ | 16:59 |
| vmayoral|pc | Chipaca: i'm probably not making it clear, sorry. Let me put it differently: | 17:00 |
| vmayoral|pc | Imagine i've got two facial recognition algorithms abstracted as snaps the first one's size is 10 MB and the second one is 15 MB. I'd like to have both installed in my device and enable one or the other depending on the scenario (without access to the cloud) thereby i need them both installed but one disabled. Is this possible now? | 17:04 |
| Chipaca | vmayoral|pc: it is possible. | 17:04 |
| Chipaca | vmayoral|pc: | 17:05 |
| Chipaca | mmm | 17:05 |
| Chipaca | vmayoral|pc: well, that's a half-lie, actually :-/ | 17:05 |
| Chipaca | vmayoral|pc: all the bits are there to do this, but there isn't an easy way to bring it about | 17:05 |
| Chipaca | so | 17:05 |
| Chipaca | vmayoral|pc: could you file a bug requesting this feature? | 17:06 |
| Chipaca | whoops | 17:06 |
| vmayoral|pc | moving to a different room ,sorry | 17:07 |
| vmayoral|pc | i'll do that | 17:07 |
| Chipaca | vmayoral|pc: do these snaps require hardware access? | 17:07 |
| vmayoral|pc | they might, for our intentions they will since our goal will be to embed different robot behaviors (with different peripherals) on each snap | 17:08 |
| Chipaca | vmayoral|pc: so, there is a workaround | 17:09 |
| Chipaca | sigh | 17:10 |
| asac | biezpal: if its about the current link one, then yes, we decided to land this change asap | 17:21 |
| ogra_ | asac, well, from a stable POV asap would be in ~4 weeks | 17:22 |
| ogra_ | (or 6 ... or whenever we plan the next release) | 17:22 |
| asac | yes | 17:24 |
| asac | still asap | 17:24 |
| asac | think 3 | 17:24 |
| asac | -4 | 17:24 |
| ogra_ | yeps | 17:25 |
| Chipaca | vmayoral|pc: you there? | 17:25 |
| vmayoral|pc | Chipaca: back again | 17:25 |
| Chipaca | vmayoral|pc: hi again :) | 17:25 |
| Chipaca | vmayoral|pc: i was saying, there is a workaround | 17:25 |
| Chipaca | vmayoral|pc: but it's a bit of a kludge | 17:25 |
| Chipaca | vmayoral|pc: interested? :) | 17:26 |
| vmayoral|pc | sure | 17:27 |
| Chipaca | vmayoral|pc: you install the snap, and then fake-install the skeleton of an old version of the snap | 17:27 |
| Chipaca | vmayoral|pc: and then 'sudo snappy set $snapname active=$skeletonversion' | 17:28 |
| vmayoral|pc | thanks. I'll give it a try. | 17:30 |
| vmayoral|pc | It'll be great though to have this functionality implemented at some point. I'll file a bug as advised. Thanks! | 17:30 |
| Chipaca | vmayoral|pc: yes, please; a feature request from a user carries more weight than if I just say "this'd be cool to have" :) | 17:31 |
| asac | ogra_: do i need to select a size for udf still or does it create the most minimal one now so it resizes? | 17:36 |
| beuno | Chipaca, also, here's here with us this week | 17:37 |
| beuno | so he has... lets say, leverage | 17:37 |
| Chipaca | beuno: hah! | 17:37 |
| ogra_ | asac, i think it still hardcodes 4GB by default ... thats a sergio question | 17:37 |
| Chipaca | beuno: fwiw, if you discuss it at all, it's a very very easy one to implement unless a lot of things change :) | 17:37 |
| Chipaca | beuno: POST {"action":"disable/enable"} to the package url (same place you already install/remove) | 17:38 |
| Chipaca | or was that a PUT | 17:38 |
| ogra_ | asac, it would be nice to have Bug 1485306 fixed, then we could create an 1byte writable partition by default | 17:38 |
| * beuno nods | 17:38 | |
| ubottu | bug 1485306 in Snappy "ubuntu-device-flash should not create data in writable partition" [High,Triaged] https://launchpad.net/bugs/1485306 | 17:38 |
| Chipaca | anyway, that's the idea | 17:38 |
| ogra_ | or 512byte rather ... i.e. 1block | 17:39 |
| asac | ogra_: i am running udf for latest pi2 | 17:39 |
| asac | WARNING: this option should only be used to build azure images | 17:39 |
| asac | is showing | 17:39 |
| asac | bug? | 17:39 |
| ogra_ | yeah, UDF needs to suppress the warning for the rpi arch | 17:39 |
| ogra_ | or it should say "azure and rpi" or some such | 17:40 |
| asac | ogra_: did you put the pi2 in a stable channel? | 17:43 |
| asac | seems not? | 17:43 |
| ogra_ | asac, i had to | 17:44 |
| ogra_ | else u-d-f wouldnt work with system-image | 17:44 |
| ogra_ | (to produce a stable img) | 17:44 |
| asac | ogra_: it doesnt work for me | 17:45 |
| asac | stable just fails | 17:45 |
| ogra_ | sudo ubuntu-device-flash core --channel stable --oem pi2.canonical --enable-ssh --install webdm -o rpi-edge.img --device raspi2_armhf 15.04 | 17:45 |
| ogra_ | asac, thats how i built the image that was released | 17:45 |
| ogra_ | still hgave the command inn my history | 17:45 |
| ogra_ | well ... -o rpi-stable.img :) | 17:46 |
| asac | ogra_: can i create a chroot on the pi2? | 17:47 |
| ogra_ | asac, why wouldnt you ? scp http://cdimage.ubuntu.com/ubuntu-core/daily/current/wily-core-armhf.tar.gz to it ... untar in a "wily-chroot" subdir in /home/ubuntu ... copy resolv.conf in place and chroot away | 17:48 |
| ogra_ | thats what i do here ... | 17:48 |
| ogra_ | asac, http://paste.ubuntu.com/12604190 | 17:49 |
| ogra_ | works just fine here | 17:49 |
| ogra_ | ogra@anubis:~/datengrab/rpi/preloader/newstable/tmp$ ls -lh rpi-edge.img | 17:49 |
| ogra_ | -rw-r--r-- 1 ogra ogra 3,7G Sep 28 19:48 rpi-edge.img | 17:49 |
| ogra_ | ogra@anubis:~/datengrab/rpi/preloader/newstable/tmp$ dpkg -l |grep ubuntu-device-flash | 17:49 |
| ogra_ | ii ubuntu-device-flash 0.31-0ubuntu1 amd64 Flash supported devices with Ubuntu | 17:49 |
| ogra_ | sergiusens, i assume asac poked you in person already ... can we suppress the azure warning when --device raspi2_armhf is used ? | 17:55 |
| ogra_ | i.e. http://paste.ubuntu.com/12604190 | 17:55 |
| ogra_ | would also be nice if the oem snap could be enabled to define the subarch so i dont need the --device option at all in udf | 17:56 |
| sergiusens | ogra_, just create an azure oem snap and get rid of that device channel ;-) | 18:01 |
| ogra_ | sergiusens, i'm talking about rpi | 18:02 |
| sergiusens | ogra_, oh, as soon as I thought I could get rid of device channels... | 18:02 |
| ogra_ | sergiusens, to have u-d-f pick the right subarch on system-image i need to use --device | 18:03 |
| sergiusens | ogra_, you bring them back :-P | 18:03 |
| ogra_ | well | 18:03 |
| ogra_ | tell me a solution that allows a different device tarball without using a device channel :) | 18:03 |
| ogra_ | that no-device-channels idea only works if everyone uses the same device tarball ... which isnt possible with rpi | 18:04 |
| asac | ogra_: the piglow does not glow out of box | 18:07 |
| ogra_ | asac, how would it ? | 18:07 |
| ogra_ | asac, and how would i even test it ... i dont have one :P | 18:07 |
| asac | ogra_: it just worked for me | 18:08 |
| asac | last time | 18:08 |
| asac | on image 4 | 18:08 |
| ogra_ | asac, install the piglow snap and call the right hw-assign bits for it | 18:08 |
| asac | it uses i2c | 18:08 |
| asac | right | 18:08 |
| ogra_ | then it shoudl work | 18:08 |
| ogra_ | though i had to enable more than i2c OOTB for rickspencer ... that might have regressed the I2C behavior | 18:08 |
| ogra_ | (we shouldnt enable anything beyond i2c by default, but rick insisted ...) | 18:09 |
| asac | ogra_: hw-assign doesnt work | 18:10 |
| asac | tells me invalid device | 18:10 |
| ogra_ | what device ? | 18:10 |
| asac | all | 18:10 |
| asac | ttySO | 18:10 |
| asac | and i2c-1 | 18:10 |
| ogra_ | should be /dev/i2c-1 | 18:10 |
| ogra_ | what would ttySO be = | 18:10 |
| ogra_ | ? | 18:10 |
| ogra_ | i guess you mean ttyS0 | 18:11 |
| ogra_ | asac, seriously, make sure ppisati and I get an orangematchbox, that the only way for him and me to make sure these bits work | 18:12 |
| asac | it worked :) | 18:12 |
| ogra_ | :D | 18:12 |
| asac | ricmms mistakes | 18:12 |
| ogra_ | so typical ! | 18:12 |
| ogra_ | :P | 18:12 |
| === pixel_ is now known as Guest53123 | ||
| === Guest53123 is now known as pixel_ | ||
| asac | so we have a npm/node plugin for snapcraft yet? | 18:53 |
| * ogra_ doesnt know | 18:53 | |
| ogra_ | i have htop and wget snapcraft trees for unconfined snaps though :) | 18:54 |
| ogra_ | (and bip indeed ... but confined) | 18:54 |
| asac | Processing triggers for systemd (225-1ubuntu4) ... | 19:21 |
| asac | Failed to get D-Bus connection: No such file or directory | 19:21 |
| asac | dpkg: error processing package systemd (--unpack): subprocess installed post-installation script returned error exit status 1 | 19:21 |
| asac | /bin/df: cannot read table of mounted file systems: No such file or directory | 19:21 |
| asac | Errors were encountered while processing: systemd | 19:21 |
| asac | E: Sub-process /usr/bin/dpkg returned an error code (1) | 19:21 |
| asac | pitti: any idea what to do about that? | 19:21 |
| asac | i am in an lxc/d container | 19:21 |
| ogra_ | asac, wow, one would mean you have a valid /dev, mounted /proc and /sys in that container | 19:22 |
| ogra_ | sounds like an issue with lxc actually | 19:23 |
| asac | yeah its buggy wily in lxc | 19:23 |
| ogra_ | thats update-initramfs printing all these errors btw | 19:24 |
| ogra_ | (from the /bin/df on) | 19:24 |
| ogra_ | (at least i dont know about any other package calling df from postinst) | 19:24 |
| * pixel_ ping facebook o_O | 19:34 | |
| * pixel_ he dead? | 19:34 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!