| sergiusens | Chipaca: I am now | 00:47 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| elopio | Hey mvo, I enabled the translations for snappy in launchpad. | 06:24 |
| mvo | elopio: excellent, thanks a bunch! | 06:25 |
| elopio | mvo: I wasn't quite sure about the configs to set, so maybe you'll like to take a look. | 06:25 |
| elopio | I set autoimport and autoexport in trunk. | 06:25 |
| mvo | elopio: nice, I have a look. we need to change the image seed too, right now iirc we don't have all the packages needed to get translations :) | 06:27 |
| elopio | mvo: do you mean, to start snappy in a different language? | 06:27 |
| mvo | elopio: yes, on a snappy system, I think we lack some of the required libraries/packages | 06:28 |
| elopio | I see. I was wondering how to do that. | 06:28 |
| elopio | but for now I'm happy. It will be good for the open house to encourage people to contribute translations. | 06:28 |
| mvo | elopio: absolutely! | 06:29 |
| === chihchun is now known as chihchun_afk | ||
| dholbach | good morning | 06:46 |
| seb128 | hey dholbach & snappy crew | 06:56 |
| dholbach | salut | 06:57 |
| mvo | hey good morning seb128 and dholbach and fgimenez | 06:58 |
| dholbach | hey mvo | 06:59 |
| fgimenez | good morning mvo and all | 06:59 |
| seb128 | hey mvo | 07:09 |
| Saviq | mo'ing | 07:47 |
| seb128 | hey Saviq | 07:48 |
| Saviq | oi | 07:50 |
| === chihchun_afk is now known as chihchun | ||
| * ogra_ sihs about the size of personal | 07:57 | |
| ogra_ | *sighs | 07:57 |
| ogra_ | one day we'll produce desktop images that dont take a lifetime to download :P | 07:58 |
| Saviq | it's not the size of the image that's the problem, it's your crappy internets, ogra_! ;) | 07:59 |
| ogra_ | yeah+ | 07:59 |
| ogra_ | still, it would be good if ubuntu-device-flash and the system-image server could talk rsync | 08:00 |
| Saviq | or delta, at least | 08:00 |
| ogra_ | re-downloading the whole thing every time is just so wasteful | 08:00 |
| Saviq | ogra_, is console=ttyACM0 on Pi meant to stay? that seems to actually be my problem as the emon add-on uses serial to communicate | 08:01 |
| Saviq | so the bootloader gets scared by all that happens on ttyACM0 | 08:02 |
| ogra_ | yes, i think it is meant to stay for the default image | 08:02 |
| ogra_ | embedded boards = serial console | 08:02 |
| Saviq | ok then, /me rolls a custom snap then, ogra_ do you guys have a branch for your main pi snap? | 08:03 |
| ogra_ | we might have a "gui oem snap" for it or some such though | 08:03 |
| ogra_ | in that i would drop it | 08:03 |
| ogra_ | no branch yet, you can just unpack it and modify as needed | 08:04 |
| Saviq | kk | 08:04 |
| * ogra_ puts "make branch" on his TODO | 08:04 | |
| ogra_ | i have a half baked one for the overlay dtb support (needs also a spoecific device tarball with the last kernel), i'll upload that if this personal download ever finishes | 08:05 |
| === john-mca` is now known as john-mcaleely | ||
| === erkules_ is now known as erkules | ||
| dholbach | hey rsalveti, did you get my open house mail? | 08:39 |
| === davidcalle_ is now known as davidcale | ||
| === davidcale is now known as davidcalle_ | ||
| === davidcalle_ is now known as davidcalle | ||
| JamesTait | Good morning all; happy "I Forgot" Day! 😃 | 09:06 |
| Chipaca | JamesTait: i don't even remember what i forgot! | 09:26 |
| JamesTait | Chipaca, have you been drinking again? | 09:27 |
| Chipaca | JamesTait: not today (yet), and only twice ever enough to forget | 09:27 |
| JamesTait | Chipaca, so, success? | 09:29 |
| mvo | Chipaca: hey, goooood morning! do you happen to know if there is anything blocking the noUpdateGrub branch from landing? if everything is ready I can land it today | 09:34 |
| Chipaca | mvo: god morning! | 09:35 |
| mvo | sergiusens: hi, for later - could you pass me the links for the passwd and adduser diff so that I can upload your fix? | 09:35 |
| mvo | Chipaca: I hope that was a typo ;) | 09:35 |
| Chipaca | ooh, my beuno script has a bug! | 09:35 |
| Chipaca | mvo: god morning! | 09:35 |
| Chipaca | indeed | 09:35 |
| Chipaca | /exec -o beuno mvo | 09:35 |
| Chipaca | ^^ failing | 09:35 |
| mvo | lol | 09:35 |
| Chipaca | mvo: goooooooooooooooooooooooooooooooooooooooooooooood morning! | 09:35 |
| mvo | loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooool | 09:36 |
| Chipaca | it's “echo -n "${1:-beuno}: g";eval printf "o%.0s" {2..$((RANDOM/512))}; echo 'd morning!'” | 09:36 |
| ogra_ | mvo, i think this was the final one for shadow http://paste.ubuntu.com/11778897/ ... the adduser stuff should be in an MP | 09:36 |
| Chipaca | but /bin/sh doesn't have a RANDOM? guess i havne't used it in a while | 09:36 |
| ogra_ | Chipaca, shuf -i 1-100 -n 1 | 09:37 |
| ogra_ | Chipaca, also ... https://wiki.ubuntu.com/DashAsBinSh the page every ubuntu dev should know by heart :) | 09:38 |
| ogra_ | (there is a more complex example for $RANDOM in a POSIX compliant way) | 09:39 |
| Chipaca | ogra_: i was using dash (or ash?) as sh before the official switch | 09:39 |
| Chipaca | ogra_: but i guess i never tested this thing after the last time i tweaked it? dunno | 09:39 |
| ogra_ | :) | 09:39 |
| Chipaca | i was using some small sh back in debian, which was before warty | 09:40 |
| mvo | ogra_: nice, thanks. I wasn't sure if there was a real branch for passwd or just the pastebin | 09:40 |
| Chipaca | anyway | 09:40 |
| Chipaca | mvo: in answer to your question | 09:40 |
| Chipaca | mvo: i don't know what's missing, but sergio should be around soon | 09:40 |
| ogra_ | mvo, just the pastebin i think, but sergiusens might have made changes since so better have him confirm that paste as final | 09:40 |
| mvo | ok | 09:41 |
| mvo | thanks Chipaca and ogra_ | 09:41 |
| Chipaca | there's still some question around console | 09:42 |
| ogra_ | more than one ... see Saviq above about the RPi :) | 09:44 |
| Chipaca | ogra_: where? | 09:44 |
| ogra_ | i think console shoul dprehaps become an option to u-d-f or some such | 09:44 |
| ogra_ | Chipaca, in the backlog ... his RPi runs sime peripherial HW attached to the serial console ... our default image uses that device as console device and crashes his HW ... | 09:45 |
| ogra_ | we need to find a more flexible way to set console altogether i think | 09:45 |
| ogra_ | on all images | 09:45 |
| ogra_ | and grub shouldnt use two console entries, IMHO all output from the boot should go to the same console device | 09:46 |
| ogra_ | (preferably the one where also your getty will start once finished) | 09:47 |
| Chipaca | the default image also runs a getty on serial afaik | 09:47 |
| Chipaca | or is that a freebie from it being console? | 09:47 |
| rsalveti | morning snapers | 09:52 |
| ogra_ | snaaapers :) | 09:54 |
| rsalveti | ogra_: I think we'd just need another oem for rpi2 that would not use the serial port by default | 09:56 |
| rsalveti | since unless hardcoded in the kernel, that's just a cmdline option, right? | 09:56 |
| ogra_ | rsalveti, i think we need a gerneral solution for console= | 09:57 |
| ogra_ | rsalveti, grub has similar probs | 09:57 |
| rsalveti | ogra_: what are the problems with grub? | 09:57 |
| ogra_ | (not actually killing hardware ... but cloud definitely wants serial while desktop will definitely want tty) | 09:57 |
| ogra_ | we need a more flexible way to define it at image creation time IMHO | 09:58 |
| rsalveti | problem with options at the image creation time can make the same image behave differently | 09:58 |
| rsalveti | which is why having another oem is so cheap | 09:59 |
| ogra_ | i dont want "options" i want one option ;) | 09:59 |
| rsalveti | oem/gadget | 09:59 |
| rsalveti | for now, yeah :P | 09:59 |
| ogra_ | --console=serial|native | 09:59 |
| ogra_ | something like that | 09:59 |
| rsalveti | right | 09:59 |
| rsalveti | sergiusens: ^^ | 09:59 |
| ogra_ | nothing you can freely define ... | 10:00 |
| ogra_ | just a switch | 10:00 |
| ogra_ | (it is ugly to mangle the cmdline during build, i know that, but i dont see a better way) | 10:00 |
| ogra_ | (unless we want to have a ton of duplicate oem snaps for each device just for one option changed) | 10:01 |
| Chipaca | --console=serial|network|native ;) | 10:02 |
| ogra_ | hah, even a third option :) | 10:02 |
| * ogra_ didnt think about network :) | 10:02 | |
| * ogra_ laughs about balloons' open house mail ... switching folders in my mailer is like zapping on TV and always seeing the same ad on all channels | 10:05 | |
| Chipaca | asac: rsalveti: mvo: sergiusens: should i re-enable click-review on build? | 10:10 |
| Chipaca | asac: rsalveti: mvo: sergiusens: i ask because bug #1470265 | 10:15 |
| nothal | Bug #1470265: Binary with an underscore fails to produce an apparmor profile <Snappy:New> <http://launchpad.net/bugs/1470265> | 10:15 |
| ubottu | bug 1470265 in Snappy "Binary with an underscore fails to produce an apparmor profile" [Undecided,New] https://launchpad.net/bugs/1470265 | 10:15 |
| asac | Chipaca: did the error messages get cleaned up yet? | 10:21 |
| Chipaca | asac: if by that you mean has it caught up with current snappy, yes | 10:21 |
| Chipaca | asac: there might be things still improperly reported as broken, because not enough testing, because we're not using it :) | 10:22 |
| asac | Chipaca: no, i mean are the errors it spits out now readable and complains only about things that are really issues? | 10:22 |
| Chipaca | in particular there's at least something about systemd units that seems off | 10:22 |
| Chipaca | asac: the majority of things it complains about are actual issues; the (mostly hypothetical) remaining things are bugs we need to address | 10:23 |
| Chipaca | asac: but either we start using it, or we start reimplementing it in 'snappy build' | 10:23 |
| Chipaca | asac: snappy assumes you've used it, and does not do deep checks | 10:23 |
| Chipaca | asac: so things break in strange ways | 10:24 |
| Chipaca | asac: (as in the linked bug) | 10:24 |
| asac | Chipaca: so is the bug that a snap install fails ? | 10:24 |
| Chipaca | asac: also in the linked bug: the full output from the review tool for a modified 'hello-world' that reproduces the issue | 10:24 |
| asac | e.g. bails out ...? | 10:24 |
| asac | e.g. you build and you install, and then a) it does not install or b) does not work right? | 10:24 |
| Chipaca | asac: no, the bug is that snap install does not bail, but fails to do all the things it should, afaik | 10:24 |
| Chipaca | (b) | 10:25 |
| Chipaca | mostly (b) | 10:25 |
| Chipaca | things we catch and fail on, we mostly catch at build time too | 10:25 |
| Chipaca | (mostly!) | 10:25 |
| asac | so i think there are two times of checks. all checks that ensure that a nsap can be installed and work shoudl be in snappy build | 10:25 |
| asac | all things we dobnt want by policy should be in review tools | 10:25 |
| Chipaca | asac: that's pretty much all of the review tools | 10:25 |
| asac | right, then parts need to be moved | 10:26 |
| asac | whatever needs checking for runtime reasons isnt review tools | 10:26 |
| asac | review tools is really abotu not allowing certain options that otherwise dont cause issues | 10:26 |
| asac | e.g. you add custom profile groups to your snap is technically working | 10:26 |
| asac | just not allowed | 10:26 |
| === chihchun is now known as chihchun_afk | ||
| Chipaca | asac: want to say as much in that bug? | 10:32 |
| ogra_ | asac, well, it is checking the options in the .yaml files ... i dont think it helps the above bug to re-enable the review tools though, binaires with underscores simply need to be supported ... (there are surely plenty) | 10:32 |
| ogra_ | (and the check needs to go once snappy got fixed to support them) | 10:32 |
| Chipaca | ogra_: it's not snappy but apparmor | 10:33 |
| ogra_ | well, apparmor then | 10:33 |
| asac | Chipaca: think did that now | 10:37 |
| asac | also included ogra's input | 10:37 |
| Chipaca | yup | 10:38 |
| Chipaca | thanks | 10:38 |
| ogra_ | hah | 10:38 |
| ogra_ | *snap* | 10:38 |
| ogra_ | 10 seconds apart :) | 10:38 |
| Chipaca | sabdfl: note bug 1470265 is about _s in binaries (ls /usr/bin | grep _), not in package names | 11:22 |
| ubottu | bug 1470265 in Snappy "Binary with an underscore fails to produce an apparmor profile" [High,Confirmed] https://launchpad.net/bugs/1470265 | 11:22 |
| Chipaca | possibly the same argument applies, but it does mean renaming things like "document_viewer" (the core app document viewer that originated the bug report) | 11:23 |
| ogra_ | yeah, we cant really anforce that | 11:25 |
| ogra_ | *enforce | 11:25 |
| Chipaca | ogra_: well, we are right now, in the "neener neener no apparmor for you" sense | 11:31 |
| ogra_ | yeah | 11:31 |
| sergiusens | morning | 11:51 |
| === alex-abreu|off is now known as alex-abreu | ||
| sergiusens | mvo: https://trello.com/c/BnuEpCft/134-support-extrausers-for-adduser-useradd-and-groupadd | 11:51 |
| sergiusens | asac: rsalveti ogra_ as I mentioned in the document for gadgets, we can use grubenv for specific options as well | 11:54 |
| ogra_ | sergiusens, on arm ? :P | 11:55 |
| sergiusens | ogra_: trollolololol | 11:55 |
| ogra_ | :P | 11:55 |
| ogra_ | sergiusens, i think we need some global way to set console= | 11:55 |
| ogra_ | arch and device independent | 11:55 |
| sergiusens | ogra_: we can support this, but not right away | 11:55 |
| ogra_ | yeah, i didnt expect it today :) | 11:56 |
| sergiusens | ogra_: on arm we can just have the default boot line in snappy-system.txt read from an additional variable in uEnv.txt | 11:56 |
| ogra_ | sergiusens, no | 11:56 |
| sergiusens | to support the default case and would be similar to grubenv | 11:56 |
| ogra_ | sergiusens, i want a way that doesnt require touching the oem snap | 11:56 |
| sergiusens | ogra_: oh, snappy config | 11:57 |
| ogra_ | being able to use the same image on serial and non serial setups | 11:57 |
| sergiusens | ogra_: then you get to right yaml ;-) | 11:57 |
| ogra_ | so the first boot goes to the right console device | 11:57 |
| ogra_ | i think it needs to be a udf option | 11:57 |
| sergiusens | *write | 11:57 |
| sergiusens | ogra_: no thanks, no more u-d-f options | 11:57 |
| ogra_ | well, thats the only way | 11:58 |
| sergiusens | I get slaughtered by adding them from people looking at crisp syntax ;-) | 11:58 |
| ogra_ | unless you can show me something else without me modifying any parts of the image | 11:58 |
| sergiusens | ogra_: live feed a snappy config is the best thing I can think of (as in "preactivate") | 11:58 |
| ogra_ | so writing a one liner yaml file that gets parsed by udf ? | 11:59 |
| sergiusens | ogra_: or pass it a file path | 11:59 |
| ogra_ | and you prefer that over a cmdline option ? | 11:59 |
| ogra_ | (its not really different, just more work for the user) | 12:00 |
| sergiusens | @reviewlist | 12:00 |
| nothal | https://code.launchpad.net/~mvo/snappy/snappy-fix-bbb-crash/+merge/263530 | No reviews (less than a day old) | 12:00 |
| nothal | https://code.launchpad.net/~fgimenez/snappy/filter-tests/+merge/263222 | Approve: 1 (2 days old) | 12:00 |
| nothal | https://code.launchpad.net/~mterry/snappy/selftest-reboot-notice/+merge/262265 | Approve: 1 (14 days old) | 12:00 |
| nothal | https://code.launchpad.net/~mvo/snappy/snappy-console/+merge/262061 | Approve: 1, Needs Fixing: 1 (15 days old) | 12:00 |
| nothal | https://code.launchpad.net/~mvo/snappy/snappy-verify/+merge/261718 | Needs Fixing: 1 (20 days old) | 12:00 |
| dholbach | thanks rsalveti | 12:04 |
| Chipaca | sergiusens: hola! what's missing for noGrubUpdate? | 12:15 |
| sergiusens | Chipaca: I rebuilt the image last night, what is missing is a proper e2e test | 12:20 |
| ogra_ | mvo, seb128 desktop-next is still unhappy about the clickpkg user ? | 13:19 |
| seb128 | ogra_, yes, I'm looking at that | 13:19 |
| seb128 | it's because it inherits from touch-core | 13:19 |
| mvo | oh, it worked fine in core | 13:19 |
| ogra_ | cool (just got the mail from nusakan) | 13:19 |
| seb128 | which includes packagekit-plugin-click | 13:19 |
| seb128 | which brings click | 13:19 |
| seb128 | which creates clickpkg user | 13:19 |
| seb128 | which fails the build because that got cleaned out from the prebuild list | 13:20 |
| seb128 | mvo, ogra_ ^ | 13:20 |
| ogra_ | seb128, so re-add it | 13:20 |
| ogra_ | assuming you want to support click packages on dekstop-next | 13:20 |
| mvo | seb128: just give it a different uid/gid, we will hardcode that in snappy | 13:20 |
| seb128 | is that going to work on snappy? | 13:20 |
| ogra_ | (or is that mutually exclusive vs snap) | 13:20 |
| ogra_ | seb128, heh, no idea :) | 13:21 |
| seb128 | I was going to hack livecd-rootfs to uninstall packagekit-plugin-click on desktop-next | 13:21 |
| seb128 | mvo, do you think we want click on snappy personal? | 13:22 |
| * ogra_ would keep it for the start to have more apps available ... if snap and click can actually coexist | 13:23 | |
| ogra_ | once the click packages were migrated thats indeed pointless | 13:24 |
| seb128 | yeah, unsure if click works on snappy, probably needs some dirs to be made rw, unsure if they are | 13:25 |
| seb128 | also currently the click scope is installed, but unsure if the snap one is going to be co-installable or replace it | 13:25 |
| ogra_ | (having a terminal would surely be helpful ;) ) | 13:26 |
| ogra_ | so if clicks dont work, it might make sense to have a terminal snap ahead of time :) | 13:27 |
| sergiusens | mvo: did you see my reply wrt clickpkg/snappypkg? | 13:36 |
| seb128 | mvo, sergiusens, do you have opinion on including click on not or personal? | 13:37 |
| seb128 | or->on | 13:37 |
| sergiusens | seb128: wouldn't that be confusing in the end? | 13:38 |
| mvo | sergiusens: yes, I think you are spot on, I like the config idea | 13:38 |
| sergiusens | mvo: oh goodie /usr/share/snappy/ or similar? | 13:39 |
| seb128 | sergiusens, having click? | 13:39 |
| sergiusens | seb128: yeah, click and the click scope and then snappy and the snappy scope | 13:39 |
| mvo | sergiusens: yeah, I think so, part of ubuntu-core-config I guess so that its easy to split between 15.04 and 16.04 | 13:40 |
| seb128 | sergiusens, unsure, but atm we don't have snappy scope yet | 13:40 |
| ogra_ | Chipaca, WRT the network interface naming, did we actually do anything about it ? (seems it all works atm and i wonder why, did pitti revert anything ? ) | 13:40 |
| seb128 | mvo, ^ opinion? | 13:40 |
| Chipaca | ogra_: no, it's still broken (on intel) | 13:40 |
| ogra_ | oh | 13:40 |
| pitti | ogra_, Chipaca: no, I didn't revert anything, but awe was talking to me about ofono | 13:41 |
| ogra_ | i'll start a ML thread about it then ... | 13:41 |
| pitti | we discussed it in bug 1467640 and PM, and I gave some suggestion | 13:41 |
| ogra_ | just wanted to know the status quo, since i had not heard anything about it anymore | 13:41 |
| ubottu | bug 1467640 in ofono (Ubuntu) "No mobile data connection for mako on wily" [High,Confirmed] https://launchpad.net/bugs/1467640 | 13:41 |
| sergiusens | seb128: it's just my personal opinion that if you add it, it will be hard to remove in the future | 13:41 |
| mvo | seb128: hmmm, I'm not if mixing the two is a good idea, I think they might get confused, especially click as there will be files in /apps that do not have the meta-data that click expects | 13:41 |
| sergiusens | seb128: and maybe kyrofa can share is scope preview with you | 13:42 |
| sergiusens | seb128: but it would be mostly unpopulated | 13:42 |
| ogra_ | pitti, ah net.ifnames=0 sounds good | 13:42 |
| seb128 | mvo, so should I just remove click and package-plugin-click from a livecd-rootfs hook? | 13:42 |
| ogra_ | (though i guess we will eventually need to support that stuff) | 13:42 |
| pitti | ogra_: if that's just about ofono, I suggested that we disable the ifnames just for the rmnet* devices, isn't that easier? (doesn't require changing kernel params or other image changes0 | 13:43 |
| ogra_ | pitti, well, i dont really care specifically about rmnet | 13:43 |
| ogra_ | this is more about eth0 which is hardcoded in half the world | 13:43 |
| pitti | ogra_: did that break anything else? | 13:43 |
| sergiusens | mvo: do you want to do the config or should I? And should we use numbers or names/strings? | 13:43 |
| ogra_ | yes, snappy VM images | 13:43 |
| pitti | ogra_: oh right, sorry -- I thought I was talking on #u-touch :) | 13:43 |
| ogra_ | we ship /e/n/i.d/etc9 by default pre-built | 13:44 |
| ogra_ | *eth0 | 13:44 |
| sergiusens | mvo given the stricktness of uid/gid, matching with numbers is fine in my opinion if it is in a config (not in code ala android ;-) ) | 13:44 |
| ogra_ | well, rmnet will affect snappy phones at some point :) | 13:44 |
| mvo | sergiusens: I can do it, unless you really want to, I won't stand in the way of course | 13:44 |
| ogra_ | so it isnt totally offtopic | 13:44 |
| kyrofa | seb128, I do indeed have a snappy scope | 13:44 |
| sergiusens | mvo: go ahead ;-) | 13:44 |
| ogra_ | but for the moment we have no networking on kvm images ... that needs immediate action | 13:44 |
| mvo | sergiusens: I was thinking that uid/gid by number will not work on desktop installs of ubuntu-device-flash as its generated dynamically there :/ | 13:45 |
| mvo | sergiusens: I switch networks now, trying to find a place that is less hot :) | 13:45 |
| * mvo is back in 2minutes | 13:45 | |
| ogra_ | seb128, heh, i just booted my first kvm personal ... how did you even manage to take that picture yesterday ... the reboot is so fast i cant read what it prints | 13:46 |
| kyrofa | seb128, is this for the personal image? | 13:46 |
| sergiusens | mvo: we can read from the snappy sysroot though | 13:47 |
| seb128 | kyrofa, yes | 13:47 |
| seb128 | ogra_, I filmed the boot with my bq and went frame by frame on the movie with mplayer | 13:48 |
| ogra_ | LOL ! | 13:48 |
| seb128 | :-) | 13:48 |
| ogra_ | wowo | 13:48 |
| ogra_ | -o | 13:48 |
| kyrofa | seb128, awesome! Right now, the snappy scope runs by utilizing the webdm API. It'll move to using the snappy service when its API is finished | 13:48 |
| seb128 | kyrofa, great | 13:48 |
| kyrofa | seb128, lp:unity-scope-snappy | 13:49 |
| seb128 | kyrofa, thanks | 13:49 |
| * ogra_ guesses popey should work on a terminal-app snap then ;) | 13:49 | |
| seb128 | kyrofa, I'm not looking at that yet, trying to get an image to boot and start unity8 first, but then it's next | 13:49 |
| kyrofa | seb128, very cool. I've got an orange matchbox here if you get to the point where I can help with anything | 13:50 |
| seb128 | kyrofa, ok, noted, thanks :-) | 13:50 |
| kyrofa | seb128, of course! :) | 13:51 |
| dholbach | rsalveti, asac: newest incarnation: https://i.imgur.com/pF720DL.png - deployment will take a bit longer | 13:51 |
| dholbach | kudos to davidcalle for his great styling work :) | 13:52 |
| ogra_ | seb128, so with modifying grub.cfg i get it to boot here ... | 14:03 |
| ogra_ | (the boot takes nearly 10min in kvm though, but i see a greeter with guest session) | 14:04 |
| seb128 | yeah, that's expected | 14:04 |
| seb128 | if we ever get a image to build without cloud-init you should see the ubuntu user and be able to log in :p | 14:05 |
| ogra_ | oh. it is still in there ? | 14:05 |
| ogra_ | k | 14:05 |
| kyrofa | seb128, if you let me know when you've got an image with unity8, I can actually package the scope as a snap for you | 14:06 |
| ogra_ | heh, yeah, clicking on the passwd field gets me a black screen now | 14:06 |
| seb128 | right | 14:06 |
| seb128 | ogra_, bug #1307618 | 14:06 |
| nothal | Bug #1307618: Unity 8 Desktop Preview does not work in the guest session <unity8-desktop-session (Ubuntu):Confirmed> <http://launchpad.net/bugs/1307618> | 14:06 |
| ubottu | bug 1307618 in unity8-desktop-session (Ubuntu) "Unity 8 Desktop Preview does not work in the guest session" [Medium,Confirmed] https://launchpad.net/bugs/1307618 | 14:06 |
| ogra_ | yup | 14:06 |
| seb128 | kyrofa, we have an image that works if you manually hack around a bit | 14:07 |
| seb128 | hopefully less manually hacking by tomorrow | 14:07 |
| kyrofa | seb128, are you planning to do unity8 as a framework? | 14:09 |
| seb128 | kyrofa, is that doable with what framework can do? | 14:10 |
| kyrofa | seb128, I actually have no idea :P | 14:10 |
| seb128 | kyrofa, but currently no, I think framework are too limited | 14:11 |
| seb128 | eventually we are getting there | 14:11 |
| seb128 | but not in the first iteration | 14:11 |
| kyrofa | seb128, that makes sense | 14:12 |
| kyrofa | seb128, okay, so the snappy scope won't have any framework dependencies other than webdm | 14:12 |
| seb128 | k | 14:13 |
| kyrofa | seb128, and we just hope that no one tries to install it on Ubuntu Core :P | 14:13 |
| seb128 | hehe | 14:13 |
| mterry | mvo, I just saw your comment on the clean-up card | 14:19 |
| mterry | mvo, but unfortunately, I've been doing a lot of disruptive cleanup on the demo branch | 14:19 |
| ogra_ | seb128, so now when i boot with all console= args dropped i actually see the errors :) | 14:19 |
| ogra_ | clould init actually tries to pull some remote file via http and fails ... thats why it takes so long | 14:19 |
| mterry | mvo, and your branches don't merge well at all anymore. I've also done some pep8/pylint cleanup myself -- will try to see what your run-checks does vs mine | 14:20 |
| mvo | mterry: sure, no problem. let me know if I can help in any way here | 14:20 |
| mterry | mvo, what's the story with pyflakes vs pylint? Is one better/more-maintained than the other? | 14:21 |
| seb128 | ogra_, right, and worth, that results in not having an "ubuntu" user working, which is why we remove cloud-init | 14:21 |
| mvo | mterry: I have not investigated pylint in a while, when I used it last some years ago I got quite a few false positivies, pyflakes fit my needs better, but that might have changed by now | 14:21 |
| ogra_ | seb128, yeah | 14:21 |
| mterry | mvo, will try -- pylint3 crashes on one of my files... | 14:22 |
| mvo | heh | 14:22 |
| ogra_ | seb128, just saying, there is no way to even see the errors with the console= args we set by default | 14:22 |
| seb128 | ogra_, well, "try to remove", still fighting issues due to mvo's clickpkg->snappypkg :p | 14:22 |
| ogra_ | evil mvo ! | 14:22 |
| seb128 | ogra_, without those it boot loop to grub anyway no? | 14:22 |
| * ogra_ tries to manually add a user in the mounted partition :) | 14:22 | |
| mterry | mvo, pyflakes is nicer indeed :) | 14:23 |
| ogra_ | seb128, nope, i only needed an initrd line and drop the panic and console= args | 14:23 |
| ogra_ | which gets me a proper boot | 14:23 |
| seb128 | k | 14:24 |
| seb128 | do you know why the config is not having an initrd? | 14:24 |
| seb128 | well, we should wait for the grub cfg refactoring work to land to look at that more | 14:24 |
| seb128 | issues might just be outdated | 14:24 |
| ogra_ | seb128, no, but Chipaca does i think | 14:24 |
| ogra_ | right, the next build might be fine | 14:24 |
| ogra_ | not sure what landed yet | 14:24 |
| ogra_ | hmm | 14:25 |
| ogra_ | ogra@anubis:~/datengrab/personal$ cat mnt/var/lib/extrausers/passwd | 14:25 |
| ogra_ | ubuntu:x:1000:1000:ubuntu,,,:/home/ubuntu:/bin/bash | 14:25 |
| ogra_ | seems the ubuntu user actually exists | 14:25 |
| seb128 | ogra_, yeah, but it has no passwd or that is screwed in some way | 14:26 |
| seb128 | I set the passwd from a systemd.debug-shell shell and then I can log in | 14:27 |
| ogra_ | it doesnt look like mouse or kbd work for me | 14:27 |
| ogra_ | on the greeter | 14:27 |
| seb128 | weird | 14:27 |
| seb128 | wfm | 14:27 |
| ogra_ | (doubleclick does, but nothing else) | 14:27 |
| ogra_ | and there is no pointer | 14:28 |
| elopio | fgimenez: lets skip the hangout today, unless you have something to talk about. | 14:32 |
| fgimenez | elopio, ok, nothing special, i've put in review filter-test again and was able to reproduce the udf issue | 14:34 |
| elopio | fgimenez: cool, I'll will look at the branch. | 14:34 |
| elopio | anybody has an idea about what's going on here? https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1470727 | 14:35 |
| ubottu | Ubuntu bug 1470727 in goget-ubuntu-touch (Ubuntu) "ubuntu-device-flash touch fails with: failed to find user uid/gid" [Undecided,Confirmed] | 14:35 |
| fgimenez | elopio, ok thanks, the idf issue seems to be related to something else different from the image version or even udf, which hasn't been updated lately | 14:35 |
| fgimenez | *udf | 14:35 |
| sergiusens | elopio: fgimenez heh, mvo is taking care of that; it's related to the latest landing of changing clickpkg to snappypkg as the user to install under | 14:36 |
| sergiusens | mvo: I have a hackier solution; just create clickpkg in /etc/passwd with the same uid/gid as snappypkg and list it after the snappypkg :-P | 14:37 |
| mvo | sergiusens: woah, thats … scary | 14:37 |
| sergiusens | mvo: supported and works though ;-) | 14:37 |
| elopio | ok, I see. Thanks. | 14:39 |
| sergiusens | mvo: http://docstore.mik.ua/orelly/networking/puis/ch04_01.htm 4.1.2 :-P | 14:44 |
| elopio | balloons, dholbach: did you avoid on purpose mentioning this IRC channel on the wiki page? or should I add it? | 14:44 |
| dholbach | elopio, I thought I had added it - please add it if I forgot | 14:45 |
| balloons | ty elopio .. feel free to edit that wiki page(S) | 14:45 |
| elopio | on it... | 14:46 |
| mvo | elopio: yeah, my fault, but I think I have a plan for a fix (unless sergiusens keeps confusing me ;) | 14:46 |
| sergiusens | mvo: the uid/gid alias is magic and 2 lines of livecdrootfs ;-) | 14:48 |
| ogra_ | sergiusens, and one spare build to collect the new md5 | 14:51 |
| elopio | :) | 14:51 |
| Chipaca | mvo: how goes squashfs? | 14:53 |
| ogra_ | totally squashed | 14:54 |
| Chipaca | so much so, now it's called sqlfs | 14:55 |
| Chipaca | wait, no | 14:55 |
| mvo | Chipaca: did I send you the spreadsheet already with my results so far? | 14:56 |
| Chipaca | mvo: well, i didn't see it | 14:57 |
| === kickinz1|afk is now known as kickinz1 | ||
| Chipaca | mvo: ta | 15:00 |
| mvo | Chipaca: the percentages are pretty terrible, but the absolute time is not too bad | 15:01 |
| sergiusens | mvo: percentages of? | 15:02 |
| mvo | Chipaca: there is a additional sheet with the memory consumption | 15:02 |
| mvo | sergiusens: startup time overhead with squashfs | 15:02 |
| elopio | beuno: did you see the invitation about the open house on tuesday? sergiusens pointed out correctly that we haven't invited anybody from the store. | 15:36 |
| elopio | could you (or somebody from your team) join us? | 15:36 |
| elopio | mvo: is this a bug in gettext? http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/po/snappy.pot#L89 | 15:51 |
| elopio | or should we just not comment things before the G line ? | 15:51 |
| mvo | elopio: let me look at the code | 15:52 |
| mvo | elopio: I think thats a gettext problem, at least partialy. the alternative xgettext-go uses a slightly different heurisitic to find the comments, if there is a blank line, it will not consider the comment | 15:54 |
| elopio | mvo: cool. So with your proposed branch we get a lot of nicer things. | 16:03 |
| elopio | rsalveti: can we publish the rc we will be testing in cdimage.ubuntu.com ? | 16:11 |
| elopio | mterry: you like translations, right? | 17:18 |
| elopio | https://code.launchpad.net/~elopio/snappy/translator-comment/+merge/263673 | 17:18 |
| mterry | elopio, heh I suppose I do :) | 17:18 |
| mterry | elopio, but mvo has been the architect of snappy's gettext support | 17:18 |
| rsalveti | elopio: sure, once we get the rc I can build the pre-built images and publish them there | 17:19 |
| mterry | elopio, looks good though | 17:19 |
| elopio | balloons: ^ so no need to document ubuntu-device-flash, for now. | 17:19 |
| elopio | thanks mterry. I think mvo is super busy trying to get his holidays :) | 17:21 |
| mterry | :) | 17:22 |
| elopio | ogra_: will you publish a raspberry pi for the RC? | 17:23 |
| elopio | *a raspberry pi image. | 17:23 |
| sergiusens | rsalveti: do you mind doing what the comment in https://code.launchpad.net/~mvo/snappy/snappy-clickpkg-snappypkg-meh/+merge/263681 mentions? | 17:46 |
| rsalveti | sergiusens: so pushing to wily, rebuilding udf and copying over to tools-proposed? | 18:44 |
| rsalveti | guess the usual dance | 18:44 |
| rsalveti | sergiusens: will wait the auto-merge to kick-in | 18:48 |
| elopio | it's missing the commit message. | 18:51 |
| === bschaefer_ is now known as bschaefer | ||
| rsalveti | elopio: keep forgetting about that | 19:03 |
| rsalveti | should be good to release now | 19:03 |
| rsalveti | Chipaca: sergiusens: elopio: do we have the rollback work for apps already, in case it fails when updating | 19:07 |
| rsalveti | guess that would be connected with health checks and hooks, which is not yet done | 19:07 |
| rsalveti | just thinking how we can roll back the app in case the app can be successfully installed but not properly working | 19:07 |
| rsalveti | manik_: ^ | 19:08 |
| rsalveti | haha, mvo forgot to update the changelog this time | 19:09 |
| elopio | rsalveti: we can copy many of the tests we have to the hello world snap. But I have tons of questions. First, the format of course. | 19:10 |
| elopio | then more interesting things, like | 19:10 |
| elopio | we had this error on hello-world.evil that wasn't printing the error. That wasn't caused by the app. | 19:10 |
| elopio | so we can install the app, get green on its health checks. Then update the system, and we want to update the app we will get red on its health checks. | 19:11 |
| elopio | so I suppose a ubuntu-core update should run the health checks of all the installed snaps. | 19:11 |
| ogra_ | uh | 19:11 |
| ogra_ | that will make it long and slow | 19:12 |
| rsalveti | right | 19:12 |
| manik_ | this has nothing to do with ubuntu core | 19:12 |
| ogra_ | (depending on the amount of apps indeed) | 19:12 |
| manik_ | well, could be | 19:12 |
| elopio | indeed. Long and slow, and we no longer control de updates. They will be affected by third parties. | 19:12 |
| rsalveti | guess first step would have the health checks and testing hooks for the app itself | 19:12 |
| manik_ | but my question was that can we offer the system (snappy core + app such as network OS) uptime guarantee | 19:13 |
| rsalveti | how that mix with the system image, it's still unclear | 19:13 |
| ogra_ | i guess we also need a switch to turn off the auto-rollback ... i.e. if you want to develop and debug your snap you should be able to force-install a broken one via sideloading | 19:13 |
| manik_ | such that core/app updates guarantee a functioning box | 19:13 |
| rsalveti | the goal is to have update/rollback for every snap type | 19:13 |
| rsalveti | just not sure what was discussed about that yet | 19:14 |
| elopio | ogra_: that's right too. | 19:14 |
| manik_ | auto rollback is the key here | 19:14 |
| manik_ | and sure, the requirement for debugging also makes sense | 19:14 |
| manik_ | in line with ogra_ | 19:14 |
| elopio | would it help if we make a binary hello-world.test to start playing with it? | 19:17 |
| rsalveti | elopio: I think so, but I'm sure sergiusens and Chipaca probably know more about this as well | 19:20 |
| rsalveti | the missing pieces and such | 19:21 |
| rsalveti | but definitely something we need to do soon | 19:21 |
| rsalveti | and backport to 15.04 as well | 19:21 |
| manik_ | i guess, we can expose a declarative in package.yaml to give the snap developers the capability to auto-rollback or not | 19:22 |
| manik_ | unless, there's a better option | 19:22 |
| manik_ | this would take care of both debugging/production use cases | 19:23 |
| elopio | what if we make this just an extra command? | 19:23 |
| elopio | snappy selfcheck will run all the snappy tests, and all the tests of the snapps installed. | 19:24 |
| elopio | if we do it after an update, we are still able to do a rollback if an update breaks an app. | 19:24 |
| manik_ | who will invoke this cmd? | 19:24 |
| elopio | the person who invoked the update. | 19:25 |
| manik_ | see, that's the problem... cause no one will | 19:25 |
| manik_ | at least in enterprises | 19:25 |
| manik_ | at scale, we need to define what should happen automaticallyu | 19:25 |
| rsalveti | right, it needs to be something automatically done for the app that gets updated | 19:25 |
| manik_ | agreed | 19:26 |
| ogra_ | well, it could be a separate command that gets auto-invoked after snappy update | 19:26 |
| rsalveti | sergiusens: https://launchpad.net/ubuntu/+source/ubuntu-snappy/1.4ubuntu1 | 19:26 |
| ogra_ | in case anyone sees benefit in having it separate :) | 19:26 |
| manik_ | why only snappy updates? what about app updates only? | 19:26 |
| elopio | an it could be removed. | 19:26 |
| ogra_ | i meant the command :) | 19:26 |
| elopio | *and. | 19:26 |
| ogra_ | "snappy update foo" | 19:26 |
| ogra_ | (foo being the app) | 19:26 |
| rsalveti | mterry: guess we can make the demo branch trunk at some point, and start having code review for it as well (snapcraft) | 19:27 |
| rsalveti | when you get comfortable with the cleanup | 19:27 |
| manik_ | and how will we take care of the cases where it shouldn't be auto-invoked after an update? | 19:27 |
| mterry | rsalveti, yeah fair | 19:28 |
| ogra_ | manik_, by having an option you can hand to snappy ... "snappy update --no-check foo" | 19:30 |
| ogra_ | or some such | 19:30 |
| kyrofa | rsalveti, is there an equivalent to reviews.ubuntu.com/click/api/1.0/reviews for snaps? | 19:31 |
| manik_ | ogra_: again, i think my concern is that for small scale of devices, this is all good.. but at massive scale, when an orchestration tool drives app installation/updates and we need to guarantee system uptime regardless of app update failure, this is not very clean | 19:31 |
| ogra_ | manik_, in such setups you wouldnt manually call snappy update ... that --no-check is really only for developers to be able to debug a broken snap (or to develop it) | 19:32 |
| kyrofa | rsalveti, I'm not sure who's running the store stuff, so feel free to redirect me | 19:33 |
| ogra_ | manik_, i dont see any use case for it in actual production envs :) | 19:33 |
| manik_ | ogra_: right, so by default every app will be auto-rollback'ed | 19:33 |
| ogra_ | yeah | 19:33 |
| manik_ | we don't want that | 19:34 |
| manik_ | i'll give you examples | 19:34 |
| ogra_ | you rather want to have a broken app installed that runs amok ? | 19:34 |
| manik_ | let me explain | 19:34 |
| manik_ | network OS running on snappy, stores persistent information in format 1 in v1.0, and an update for v2.0 changes the persistent object storage to format 2 which only v2.0 can read | 19:35 |
| manik_ | in this situation, even though the app update failed, you don't want to rollback | 19:35 |
| Chipaca | the data directories are different | 19:35 |
| ogra_ | you want to roll back to the complete old stack ... including your data | 19:35 |
| Chipaca | the data directory of a snap gets copied on install of a new version | 19:36 |
| Chipaca | that is, the current data dir is copied to the new data dir after stopping the current snap's services | 19:36 |
| Chipaca | if you roll back, you use the old data dir | 19:36 |
| manik_ | hmmm.. | 19:37 |
| Chipaca | now, if it's the os snap, then it's more complicated :) | 19:37 |
| Chipaca | but any installed snap is like above | 19:37 |
| manik_ | Chipaca: are you referring to snappy itself when you refer to the OS snap? or a Network OS running on top of snappy | 19:37 |
| * ogra_ guesses snappy itself | 19:39 | |
| ogra_ | an network OS is just like any other app snap | 19:39 |
| Chipaca | manik_: the core operating system that includes snappy itself | 19:40 |
| manik_ | ok | 19:40 |
| manik_ | i have 1 other scenario, but this is highly unlikely if not entirely implausible | 19:41 |
| ogra_ | these are the best ;) | 19:41 |
| Chipaca | shoot :) | 19:41 |
| Chipaca | yeah | 19:41 |
| manik_ | the app depends on interaction with a 3rd party such as a server for its own continuous operation | 19:41 |
| Chipaca | is the server local to the device, or remote? | 19:42 |
| manik_ | some changes at the server necessitate updates from v1 --> v2 | 19:42 |
| manik_ | remote | 19:42 |
| ogra_ | thats actually a good one ... | 19:42 |
| manik_ | in this case, the v1 apps cease to exist because server can't handle connections from v1 apps | 19:42 |
| ogra_ | can an app request to update itself ? | 19:42 |
| Chipaca | no, an app can't request to update itself | 19:43 |
| ogra_ | well, should we support it ? | 19:43 |
| Chipaca | ogra_: i'm not sure how that helps :) | 19:43 |
| Chipaca | autopilot would find and install new versions of the app | 19:43 |
| ogra_ | indeed v2 would have to be in the store already | 19:43 |
| Chipaca | so, what you would do | 19:43 |
| ogra_ | right it would also have to be able to suppress the update | 19:44 |
| Chipaca | is get your v2 ready in a beta channel or something | 19:44 |
| Chipaca | and when you throw the switch to make v2 the current version of the server | 19:44 |
| Chipaca | you move v2 to the stable channel | 19:44 |
| ogra_ | phew | 19:44 |
| ogra_ | thats a lot of coordination work | 19:44 |
| Chipaca | yes | 19:44 |
| Chipaca | and not recommended | 19:44 |
| Chipaca | but that's how you'd do it if you needed to make a hard cutoff | 19:44 |
| rsalveti | kyrofa: guess beuno is your friend for that | 19:44 |
| Chipaca | ideally you'd have a window | 19:45 |
| Chipaca | where v1 and v2 are both ok | 19:45 |
| rsalveti | sergiusens might know as well, since he is working on the rest api | 19:45 |
| ogra_ | updating the server and sending a push/update command to the nodes sounds easier | 19:45 |
| Chipaca | and you'd move people over inside that window | 19:45 |
| kyrofa | rsalveti, thanks! | 19:45 |
| Chipaca | ogra_: hm, not sure we're wanting to address that kind of hard client-server sync | 19:45 |
| ogra_ | unless you have a hard ABI break onn the server or so | 19:45 |
| ogra_ | where its either/or | 19:46 |
| Chipaca | yeah | 19:46 |
| Chipaca | so, hard cut-offs could happen | 19:46 |
| ogra_ | well, the case is definitely very corner :) | 19:46 |
| Chipaca | i've had to orchestrate a couple myself :) | 19:46 |
| manik_ | in this case, if the v2 of the snap can explicitly request not to roll-back as part of its package.yaml and than later in the future v3 can renew that guarantee | 19:46 |
| kyrofa | beuno, does the store support reviews for snaps yet? i.e. the snap equivalent of reviews.ubuntu.com/click/api/1.0/reviews | 19:46 |
| Chipaca | manik_: hmm, disagree | 19:46 |
| elopio | hum, and we might want some types of health-checks that contact an external service. | 19:46 |
| ogra_ | elopio, careful what you wish for :) | 19:47 |
| Chipaca | manik_: if v2 is getting rolled back automatically it's because it's broken | 19:47 |
| * ogra_ sees the privacy trolls standing on the side already | 19:47 | |
| Chipaca | manik_: so, ok, v1 won't be much better | 19:47 |
| manik_ | right, but we want to let the app developer decide if they can support rollback with their architecture or not | 19:47 |
| Chipaca | manik_: but it's not worse. note you already tested that it should work by having it in a different channel. | 19:47 |
| rsalveti | right, why would we rollback v2 | 19:47 |
| ogra_ | rsalveti, because it fails to start for some reason | 19:48 |
| ogra_ | typo in the config ... bad testing etc | 19:48 |
| rsalveti | exactly, so it's known to be broken | 19:48 |
| rsalveti | and as Chipaca said, as useful as v1 | 19:48 |
| ogra_ | rsalveti, right, but the server it talks to can only handle requests from v2 now | 19:48 |
| Chipaca | now, *manual* rollback, i could see disallowing or, better / easier, alerting the user as to it being a bad idea | 19:48 |
| ogra_ | its a client/server scenario | 19:48 |
| Chipaca | manual rollback is advanced user territory anyway | 19:49 |
| ogra_ | with a hard dep between them | 19:49 |
| Chipaca | ogra_: yes, i get it, v1 is useless | 19:49 |
| Chipaca | ogra_: but v2 is broken | 19:49 |
| ogra_ | right | 19:49 |
| rsalveti | I think it's fine to have a flag or such that could set the auto rollback or not | 19:49 |
| rsalveti | if you want to force that | 19:49 |
| Chipaca | oh, ok :) | 19:49 |
| manik_ | i just want the developer to control whether he wishes to have rollback or not | 19:50 |
| manik_ | this way we are not imposing this as a hard requirement | 19:50 |
| manik_ | and also get out of the way of these corner case discussions | 19:50 |
| manik_ | we just tell the end customer, if you want rollback, we can provide it | 19:50 |
| rsalveti | right, I think that's fair | 19:50 |
| ogra_ | well, rather "if you want to suppress it" | 19:52 |
| ogra_ | it should be the default | 19:52 |
| manik_ | ogra_: i think the challenge with that is that most systems do not guarantee app rollbacks and i am not sure if many developers take care of all corner cases in terms of rollback | 19:53 |
| ogra_ | its one of our key features | 19:53 |
| rsalveti | ogra_: right | 19:53 |
| manik_ | what we are proposing with snappy is an entirely new way of updates/rollbacks | 19:53 |
| rsalveti | have a way to suppress it | 19:53 |
| * ogra_ imagines something like: snappy config ubuntu-core set no-rollbacks | 19:54 | |
| ogra_ | but by default rollbacks happen | 19:54 |
| manik_ | what's the advantage to doing default rollbacks? | 19:55 |
| ogra_ | that you can never end up with a broken libreoffice on your desktop ;) | 19:55 |
| ogra_ | and that your firewall route still works after a failed update | 19:55 |
| ogra_ | *router | 19:55 |
| ogra_ | or that your delivery drone has no outage due to an upgrade failure | 19:56 |
| rsalveti | forcing a default for rollbacks is to make sure the system is always in a usable state | 19:56 |
| ogra_ | (so you can immediately use it again even after failed upgrades) | 19:56 |
| manik_ | if a declarative flag in package.yaml is mandatory and defaults to yes, this can still achieve the same goal of rollback but forces the developer to think about all corner cases for rollbacks | 19:56 |
| ogra_ | yeah, but it bloats the package.yaml for everyone | 19:57 |
| rsalveti | don't need to put in package.yaml if that is already the default | 19:57 |
| ogra_ | for a small percentage of apps that dont want rollback | 19:57 |
| manik_ | ok, my idea was just to make the developers explicitly aware that we will do this.. in case for whatever reason that are not thinking straight | 19:58 |
| ogra_ | well, we advertise that pretty badly :) | 19:58 |
| ogra_ | hard to not be aware of it | 19:58 |
| manik_ | ok, so we have an agreement on this | 19:59 |
| manik_ | now, the real question is, is this capability already there? | 19:59 |
| ogra_ | haha | 19:59 |
| manik_ | or parts of it | 19:59 |
| ogra_ | thats the trick question in this conversation :) | 19:59 |
| ogra_ | (see the beginning of the discussion, it isnt ... ) | 20:00 |
| rsalveti | sergiusens: will you backport https://bugs.launchpad.net/snappy/+bug/1459749 as well? | 20:00 |
| ubottu | Ubuntu bug 1459749 in Snappy 15.04 "Origins for frameworks and oem packages are lost after install" [High,Triaged] | 20:00 |
| rsalveti | going to put it under the 15.04.2 milestone | 20:00 |
| manik_ | is this being tracked at the trello boards? | 20:01 |
| mvo | meh, what changelog did I forget? | 20:02 |
| rsalveti | mvo: 1.3ubuntu1 for ubuntu-snappy | 20:03 |
| rsalveti | mvo: but no worries, already pushed the packaging changes | 20:03 |
| mvo | rsalveti: uh, thanks, sorry for forgetting the bzr push | 20:03 |
| rsalveti | mvo: np, I always forget that as well | 20:04 |
| ogra_ | yeah, it is awful | 20:04 |
| manik_ | rsalveti: where can i review the 15.04.2 milestones? | 20:05 |
| ogra_ | using debian/changelog works though ;) | 20:05 |
| rsalveti | manik_: https://trello.com/c/KaabaSIw/160-application-rollback-on-updates | 20:06 |
| rsalveti | will discuss this with the team again next wekk | 20:06 |
| rsalveti | week | 20:06 |
| rsalveti | half of the team is off tomorrow | 20:06 |
| rsalveti | manik_: https://launchpad.net/snappy/+milestone/15.04.2 | 20:06 |
| rsalveti | I'm still reviewing the bugs | 20:07 |
| manik_ | great | 20:07 |
| manik_ | what about the option of granular system resource control | 20:07 |
| manik_ | for example an app requesting 2CPUs, 5G RAM, 10G storage and 1G bandwidth | 20:08 |
| manik_ | basically, exposing the system cgroup mapping to the app developer to let them decide | 20:09 |
| ogra_ | sounds pretty dangerous | 20:10 |
| * ogra_ guesses that needs some security team input | 20:10 | |
| rsalveti | that's a big topic | 20:10 |
| ogra_ | yeah | 20:10 |
| manik_ | yes, i did send an email on this to the alias during the IoM sprint | 20:11 |
| manik_ | but i guess everyone was too caught up at that time | 20:11 |
| mvo | sergiusens: thanks again for the adduser/useradd patches, I uploaded them now. I added a task to push the patches to debian, feel free to do that otherwise I will send them early next week (if they merge the diff we have less delta to maintain :) | 20:11 |
| ogra_ | mvo, a compelling argument for them might be that we got the extrausers idea from their server setups :) | 20:12 |
| ogra_ | (i'm still surprised debian hasnt patched the tools themselves yet) | 20:13 |
| beuno | kyrofa, it does, there's no material difference between snaps and clicks | 20:32 |
| kyrofa | beuno, so I can use the same API, but use snap package IDs? | 20:33 |
| beuno | kyrofa, indeed you can | 20:34 |
| kyrofa | beuno, how about screenshots? | 20:34 |
| beuno | kyrofa, yes, no differences between clicks and snaps | 20:34 |
| sergiusens | rsalveti: no need to rebuild u-d-f | 20:35 |
| rsalveti | then just copying to tools-proposed | 20:35 |
| kyrofa | beuno, very good, thank you :) | 20:42 |
| sergiusens | rsalveti: yes, I will backport that origins bug, I created the 15.04 task for it, but forgot to add a milestone for it | 20:43 |
| rsalveti | sergiusens: cool | 20:43 |
| sergiusens | rsalveti: ultimately, we don't need to copy u-d-f for it to work, but it would be good to get personal there anyways. | 20:52 |
| rsalveti | yeah | 20:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
