| thesheff17 | lantins: 1) I don't think so...2) I'm not sure...I'm also trying to get it to work without going to the store | 01:50 |
|---|---|---|
| thesheff17 | haha sorry terrible answers :) | 01:50 |
| thesheff17 | but yea I would love to know as well | 01:51 |
| thesheff17 | oh these were asked by ryanprior sorry | 01:52 |
| lantins | thesheff17: I was watching a video from eariler this month, they said the kernel would become a snap package, available from the store, along with the base system itself | 01:59 |
| lantins | so, if that happens, im _guessing_ you could swap in your own kernel | 02:00 |
| thesheff17 | ah nice | 02:00 |
| lantins | thesheff17: another video also mentioned that you could host snap packages privately, but no other details were provided | 02:01 |
| lantins | my vagrant install of snappy seems to be failing on me, so I've not had a chance to play around with the command line tools, it could be as simple as pointing it to your own URL | 02:01 |
| lantins | but then i question how updates would happen auto-magically | 02:02 |
| thesheff17 | yea I'm a little confused by how the packages work...do you just provide your own binaries in bin and the build the snappy image? | 02:02 |
| lantins | my gut feeling is telling me, snappy ubuntu core is 12+ months off being production ready | 02:02 |
| lantins | thesheff17: yeah, it seems that way | 02:02 |
| thesheff17 | well as far as I know the updates require a reboot from revision to revision | 02:02 |
| thesheff17 | yea I def want to see snappy in production...but yea you are prob right its going to be a while | 02:03 |
| lantins | the transactional updates, using deltas is what appeals to me :) | 02:04 |
| lantins | would be good for low bandwidth situations | 02:04 |
| lantins | i just hope its not all too tied into 'the store', that' ive NFI how you even 'browse'.... | 02:04 |
| thesheff17 | absolutely for me as well...apt-get works well enough now but I'm always scared its going to break something | 02:05 |
| thesheff17 | yea my company prob wouldn't want the scripts public or in ubuntu store | 02:05 |
| thesheff17 | I also wonder how kernel 4.x will work since it no longer requiring reboots...I haven't really scene anyone testing it yet. | 02:06 |
| lantins | company isn't a problem for me, customers however would not want it public, since they are paying good money for it ;) | 02:06 |
| thesheff17 | haha right | 02:06 |
| thesheff17 | also why did they name it snappy...it totally collides with a google snappy compression package | 02:07 |
| thesheff17 | its hard to search right now on google | 02:07 |
| lantins | these days, every name is taken :) | 02:07 |
| lantins | but yeah, its a right pain to google for things | 02:08 |
| thesheff17 | this is also really interesting http://insights.ubuntu.com/2015/05/06/live-migration-in-lxd/?utm_source=ubunteu&utm_medium=url_shortner&utm_term=PQfLe3&utm_campaign=shortner | 02:09 |
| lantins | I'm thinking, for my planned use case, rolling something from ubuntu core may be the way to go | 02:09 |
| thesheff17 | having live migration of snappy running instances would be so cool | 02:09 |
| thesheff17 | yea I have tested a bunch of docker...it kinda fits into my environment but I don't think I have the resources to implement it | 02:10 |
| lantins | to implement snappy? | 02:11 |
| thesheff17 | to implement docker | 02:11 |
| lantins | ah | 02:11 |
| thesheff17 | also its a little strange docker was like the first package for snappy | 02:12 |
| lantins | docker is cool, ive only ever 'played', never done anything in production :) | 02:13 |
| lantins | yeah, i dont quite get why... | 02:13 |
| lantins | since they can, kinda, be used for the same thing | 02:13 |
| lantins | _kinda_ | 02:13 |
| thesheff17 | right | 02:13 |
| thesheff17 | yea I have 1 docker server in amazon running 1 stage service for my developers but just getting that working was not fun | 02:14 |
| lantins | thesheff17: https://daniel.holba.ch/blog/2015/05/the-snappy-online-summit-is-in-full-swing/ - links to the videos i mentioned above, may be of interest | 02:16 |
| thesheff17 | cool I will def check them out | 02:16 |
| lantins | videos are only a couple of days old, so its fairly uptodate ;) | 02:16 |
| thesheff17 | lantins: cool yea if you are a python guy check out this link http://www.wefearchange.org/2015/04/creating-python-snaps.html I'm slowly trying trying to duplicate this article... I use pip for almost everything I do | 02:21 |
| lantins | ta :) | 02:24 |
| lantins | okay, so python is already installed in snappy, because part of the tools are wrote in python, i wonder how you'd do something like say... Ruby? would every dependancy be rolled into the snap package? | 02:28 |
| lantins | my actual use case would be a go app, so that's easy being a binary | 02:29 |
| thesheff17 | yea I'm guessing this pex package for python basically builds custom binaries or what packages you want included in your snappy image | 02:33 |
| thesheff17 | *of | 02:33 |
| thesheff17 | yea I almost wish you could say take an entire lxc container and make a snappy image out of it... | 02:57 |
| dholbach | good morning | 06:30 |
| JamesTait | Good morning all; happy Monday, and happy Twilight Zone Day! 😃 | 09:06 |
| === davidcalle_ is now known as davidcalle | ||
| beowulf | o/ | 09:31 |
| beowulf | Chipaca: you around today? | 10:08 |
| Chipaca | beowulf: yes, but was at kids' dentist until just now | 10:53 |
| ogra_ | you should talk to your health insurance if they dont let you go to a grown up one ... | 10:54 |
| Chipaca | ogra_: i'm not sure whether to mention this dentist specialises in ASD kids or not | 11:00 |
| dholbach | https://code.launchpad.net/~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/bug-1435774/+merge/256562 is in the sponsorship queue... is the bug still valid? | 11:12 |
| davidcalle | Can someone have a quick look at https://bugs.launchpad.net/developer-ubuntu-com/+bug/1453781 ? I believe the bug reporter is right, but I'd like a confirmation before fixing. Thanks ! | 12:27 |
| davidcalle | (snap format doc bug) | 12:28 |
| Chipaca | davidcalle: I don't think the bug is right | 12:34 |
| davidcalle | Chipaca, glad I asked :) | 12:34 |
| Chipaca | granted, the website isn't entirely correct either | 12:34 |
| Chipaca | :) | 12:34 |
| Chipaca | but that description is correct as things are currently documented | 12:34 |
| Chipaca | escaping a dot inside a character class being necessary depends on the regex language being used | 12:35 |
| Chipaca | and adding a backslash just makes it harder to read | 12:35 |
| Chipaca | so leave it without | 12:35 |
| davidcalle | Chipaca, I was more concerned about the lack of + at the end | 12:36 |
| Chipaca | hah | 12:36 |
| Chipaca | give me a minute | 12:37 |
| Chipaca | davidcalle: the documentation in the project is correct | 12:38 |
| Chipaca | davidcalle: can you change the documentation on the website to match the one in the project? | 12:38 |
| davidcalle | Chipaca, yep | 12:38 |
| Chipaca | it describes the version field thus: “the version of the snap (only `[a-zA-Z0-9.+~-]` are allowed)” | 12:38 |
| Chipaca | the description of the name *is* missing a quantifier, and has no wording to avoid the absence | 12:39 |
| Chipaca | but the version one is correct thanks to the language :) | 12:39 |
| Chipaca | interestingly, it doesn't look like we enforce this in the client | 12:42 |
| davidcalle | Chipaca, I've fixed the regexes and added a link to the full format reference we also have on the site (which is an export of the in-package doc) | 12:52 |
| Chipaca | double plus good | 12:52 |
| Chipaca | davidcalle: are your changes live? | 12:53 |
| davidcalle | Chipaca, they are | 12:59 |
| Chipaca | davidcalle: hm. you changed the regex for the version, but not the wording, meaning it's wrong; if you're going to word it like that you need to change the regexp | 12:59 |
| Chipaca | davidcalle: version should match ^[a-zA-Z0-9.+~-]+$ | 13:00 |
| davidcalle | Chipaca, oh right, I see what you mean match/allowed | 13:00 |
| Chipaca | actually, it'd probably be a good idea to force version to not start with a period, but that can wait | 13:01 |
| Chipaca | get out of the smartassery of creating a package with version ".." | 13:01 |
| Chipaca | i'll file a bug | 13:02 |
| === elopio_ is now known as elopio | ||
| vmayoral|pc | greetings | 14:44 |
| vmayoral|pc | ogra_: ping | 14:44 |
| ogra_ | vwhey hey+ | 14:45 |
| ogra_ | eh | 14:45 |
| ogra_ | vmayoral|pc, hey hey | 14:45 |
| vmayoral|pc | ogra_: hope everything's going fine | 14:46 |
| vmayoral|pc | i'd like to run through you some thoughts if that's fine | 14:46 |
| vmayoral|pc | so, we've been putting a lot of time into creating a ROS framework for snappy that allows developers to create snaps that use ROS | 14:48 |
| ogra_ | ok | 14:49 |
| vmayoral|pc | so far results look quite promising but we are constantly twisting things to basically fit everything in the writable partition (instead of touching system-a) | 14:50 |
| vmayoral|pc | i quite like the approach followed here http://www.piware.de/2015/01/snappy-package-for-robot-operating-system-tutorial/ with a chroot. Would you recommend doing so or would you rather resize the partitions (e.g.: assign 2 GB to system-a so that it can contain libboost and other necessary libraries) | 14:54 |
| vmayoral|pc | for the general developer (familiar with ROS) the second approach would work better but maybe the first one is preferrable from a Snappy perspective? | 14:55 |
| ogra_ | vmayoral|pc, i personally would perfer to be able to independenly upgrade core from the ros ... | 15:07 |
| ogra_ | so keep ROS a snap ... this also saves you from tinkering with partitions | 15:07 |
| === dholbach_ is now known as dholbach | ||
| ogra_ | vmayoral|pc, did you talk to pitti about it yet (he wrote that howto) ... probably he feels like making it an official snap in the store | 15:21 |
| ogra_ | (i see he is not around though) | 15:21 |
| vmayoral|pc | ogra_: that makes sense, i'll try to reach him at some other time then, thanks | 15:24 |
| ogra_ | hey pitti :) | 15:29 |
| pitti | hey ogra_ :) | 15:29 |
| vmayoral|pc | pitti: i was asking ogra_ about his opinion for ROS support on snaps | 15:32 |
| vmayoral|pc | we've been putting a lot of time twisting things to get everything in the writable partition but your approach seems pretty handy as well. I'm just concerned about the traditional ROS users that would expect everything under /opt... | 15:33 |
| pitti | vmayoral|pc: yeah, I wish snappy wouldn't change the entire FHS, but right now we can't have /opt | 15:35 |
| pitti | vmayoral|pc: however, with the specified "private overlay mounts", snaps can actually put stuff wherever they want again, including /opt (just visible within the snap's mount namespace) | 15:35 |
| vmayoral|pc | that's interesting | 15:36 |
| vmayoral|pc | pitti: what we are trying to do, besides releasing a snap with a ROS distro | 15:38 |
| vmayoral|pc | i to release the whole chroot | 15:38 |
| vmayoral|pc | so that users can develop/compile their own packages in the BBB | 15:38 |
| vmayoral|pc | pitti: how do you feel about this? (what we are trying to avoid here is that a developer compiles from source all the ROS packages every time they want to develop something on top of ROS) | 15:41 |
| tbr | does anyone happen to know if this has made it into some image that I could test? https://bugs.launchpad.net/snappy-ubuntu/+bug/1425370 - after all it says merged | 16:15 |
| tbr | or short of that, how do I build my own image | 16:15 |
| tbr | disregard the second question, just remembered that tit's impossible. | 16:16 |
| ogra_ | not impossible :) | 16:17 |
| ogra_ | but really hard to set up | 16:17 |
| ogra_ | tbr, it says "In Progress" ... | 16:18 |
| ogra_ | so it did not land anywhere yet | 16:18 |
| tbr | ogra_: "factually impossible, especially for me" | 16:18 |
| tbr | ogra_: https://bugs.launchpad.net/snappy-ubuntu/+bug/1425370 | 16:19 |
| ogra_ | yes | 16:19 |
| tbr | Merged into lp:goget-ubuntu-touch at revision 172 | 16:19 |
| ogra_ | you look at the wron thing :) | 16:19 |
| ogra_ | (teh code is merged, but not released anywhere yet) | 16:19 |
| ogra_ | look higher up :) | 16:20 |
| tbr | ok, so the answer to my initial question is no then | 16:20 |
| ogra_ | right, as long as the bug status is not "Fix Released" it wont be in any image | 16:20 |
| tbr | ogra_: so even if there would be a CI image from something that is tracking trunk it would be "fix released"? | 16:21 |
| ogra_ | usually as soon as someone uploads the deb for it he will set it to that | 16:22 |
| ogra_ | or the launchpad automation will ... deducted from a changelog entry | 16:22 |
| tbr | I'm not a complete moron, even if it might look like it. I'm just unfamiliar with the ways of working, so I end up asking questions to verify my understanding. I'm terribly sorry for that. | 16:22 |
| tbr | ok. so I'll watch that bug to go into released. | 16:23 |
| ogra_ | huh ? i didnt mean to attack you or something | 16:24 |
| tbr | not taken as such. it's just whenever I try to ask questions to understand processes someone goes "duh, y u no see, it obviuz". That doesn't get me any closer to understanding how things work as I feel that me asking questions that get me closer is unwelcome | 16:25 |
| ogra_ | totally not unwelcome | 16:27 |
| ogra_ | just ask away :) | 16:27 |
| tbr | thanks | 16:27 |
| tbr | is there such a thing as a description of the usual workflow in ubuntu? I really have a hard time as I only see web interfaces here and there and then there is lots of non-obvious glue and magic that confuses me. | 16:30 |
| ogra_ | tbr, well, the usual workflow is to have a bug ... if the bug applies to multiple places (i.e. yours is against a package and a toplevel project (system image)) ass the respective tasks ... if someopne does a merge on launchpad mentioning that bug you see the branches in the bug (with their state ... i.e. merged in your case) ... if i am a clever developer, i mention the bug in my .deb cahngelog so that as | 16:43 |
| ogra_ | soon as i upload LP will automatically close the bug task for this package | 16:43 |
| tbr | ogra_: yeah, that bit I understood. Just wondering if there is "Ubuntu workflows for outsiders" or something like that. A coherent document that would explain most cases. Would also save us both lots of questions/answers and time | 16:48 |
| ogra_ | yeah, i'm not sure there is ... | 16:49 |
| ogra_ | technically it all boils down to launchpad merge proposales nowadays, the bugs are just the accompanying paperwork | 16:50 |
| ogra_ | i.e. you find an issue ... file a bug, grab the source tree, write a patch and push to a private branch that you proposed for merging via the LP UI | 16:51 |
| ogra_ | *propose | 16:51 |
| ogra_ | oh, and private in the sense of "owned by you" not meaning "secret branch" | 16:52 |
| kyrofa | sergiusens, can I access the webdm API discussed in the README after snappy install-ing webdm? Or do I need something else? | 18:08 |
| === j12t_ is now known as j12t | ||
| tbr | ogra_: sure, but then where does a merge get released to, who decides that, how do debs get built, where are they accessible, etc. there's a pile of knowledge that is completely indiscoverable to a newcomer. :-( | 18:20 |
| rsalveti | tbr: we have a lot of docs all around, for ubuntu you can check https://wiki.ubuntu.com/UbuntuDevelopment | 20:56 |
| rsalveti | also feel free to ping the community team and dholbach when he's around | 20:57 |
| rsalveti | https://developer.ubuntu.com/en/ has a lot of info as well, but mostly when building apps and such | 20:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!