| mup | Bug #1606100 opened: "snap revert" command cannot be found <Snappy:New> <https://launchpad.net/bugs/1606100> | 02:18 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| ali1234 | okay i figured it out. my qmake .pro has target.path=build because i copied it from the Qt examples | 04:14 |
| ali1234 | so fixed it... now let's see what the next problem is | 04:14 |
| ali1234 | This application failed to start because it could not find or load the Qt platform plugin "eglfs" in "". | 04:23 |
| ali1234 | getting closer... | 04:23 |
| qengho | Nice! | 04:25 |
| === dpm is now known as dpm-afk | ||
| zyga | good morning | 05:58 |
| === chihchun_afk is now known as chihchun | ||
| didrocks | hey zyga | 06:12 |
| === dpm-afk is now known as dpm | ||
| liuxg | elopio, ping | 07:15 |
| mup | PR snapd#1581 opened: asserts: remove/disable comma separated lists and their uses <Created by pedronis> <https://github.com/snapcore/snapd/pull/1581> | 07:38 |
| liuxg | does anyone know how to use a license file in the snap? | 08:53 |
| mardy | I'm try build snapd, and I'm getting this error (I'm new to golang): http://paste.ubuntu.com/20849102/ | 08:56 |
| stevebiscuit | mardy: try `cd $GOPATH/src/github.com/snapcore/snapd; go build -o /tmp/snap ./cmd/snap` | 09:37 |
| mardy | stevebiscuit: thanks! I missed the fact that I have to build it from within $GOPATH | 09:39 |
| stevebiscuit | mardy: np! | 09:40 |
| mwhudson | hi, i have a firstboot question | 09:41 |
| mwhudson | the console-conf stuff i'm working on prompts for username and password | 09:41 |
| mwhudson | should it just call /sbin/useradd with this info or is there/will there be a snapd api to call? | 09:42 |
| mup | PR snapd#1554 closed: store: Find now takes a Search instead of a query and channel <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1554> | 09:44 |
| mup | PR snapd#1554 closed: store: Find now takes a Search instead of a query and channel <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1554> | 09:44 |
| hikiko | hello :) | 09:56 |
| netphreak | Hi, guys! | 09:57 |
| netphreak | Has there been any new releases of snappy for RPI3? | 09:57 |
| hikiko | question: I was about to change hexchat on snappy-playpen to use the git repo that doesn't have compile errors and noticed that we use the https://dl.hexchat.net/hexchat/hexchat-2.12.1.tar.xz, and I was wondering if I should change it or leave it like it is now +what about the readme? should I remove the todo? | 10:01 |
| hikiko | the official hexchat repo is this: https://github.com/hexchat/hexchat | 10:02 |
| mup | PR snapd#1582 opened: debian: move snapd.refresh.timer into timers.target <Created by mvo5> <https://github.com/snapcore/snapd/pull/1582> | 10:11 |
| hikiko | +another question :) I want to make a snap for blender, and in their page they have a 32bit tarball, an 64 bit tarball and a link to the git repo which one should I use in source? | 10:24 |
| hikiko | what's preferable tarball or repo? | 10:25 |
| tsimonq2 | hikiko: well it depends | 10:25 |
| qengho | hikiko: tarball. | 10:25 |
| tsimonq2 | hm qengho :P | 10:25 |
| tsimonq2 | hikiko: if using the repo fixes all the issues, mark it somehow as a daily snap and keep it like that until the next release | 10:26 |
| hikiko | I was thinking that if the user clones the repo he will then build the appropriate version for his architecture | 10:26 |
| hikiko | tsimonq2, how can I mark it as a daily snap? | 10:27 |
| tsimonq2 | hikiko: s/hexchat/hexchat-daily/g | 10:27 |
| hikiko | +how are you? :) | 10:27 |
| tsimonq2 | great, you? :) | 10:27 |
| hikiko | good! | 10:27 |
| hikiko | alright :) I'll do this to blender then because someone changed hexchat to use this: | 10:28 |
| hikiko | source: https://dl.hexchat.net/hexchat/hexchat-2.12.1.tar.xz | 10:28 |
| hikiko | so I guess it's not a daily-build | 10:28 |
| qengho | hikiko: Assuming your dependencies are all in Ubuntu OR are in public and compilable, and assuming your builder is already a plugin, then use tarball. | 10:30 |
| hikiko | qengho, but which tarball? | 10:31 |
| hikiko | the 32 or the 64? | 10:31 |
| hikiko | can I support both? | 10:31 |
| qengho | hikiko: source tarball. | 10:31 |
| hikiko | oh :) | 10:32 |
| hikiko | ok :) | 10:32 |
| qengho | hikiko: sorry, I confused you. I'm advocating sourceonly. | 10:32 |
| hikiko | thanks qengho tsimonq2 :) | 10:33 |
| qengho | hikiko: The builderson launchpad can make a blender-i386.snap and a blender-amd64.snap and (maybe) blender-armhf.snap and blender-arm64.snap | 10:33 |
| ogra_ | mwhudson, you need adduser ... not useradd, since we default to libnss-extrausers, not to shadow for password management ... also i though that we are forced to use cloud-init for this | 10:34 |
| mwhudson | ogra_: uh yes, i should have said "useradd or something like that" | 10:34 |
| ogra_ | netphreak, there havent been any image releases for any arch yet ... (so not, not even the pi3 .. but flexiondotorg and kgunn made some awesome progress to get graphics up and running during the snappy sprint) | 10:35 |
| ali1234 | okay now i'm really getting somewhere: * failed to open vchiq instance | 10:35 |
| ogra_ | ali1234, is that a 15.04 image ? | 10:35 |
| ali1234 | ogra_: no | 10:35 |
| ogra_ | (16.04 ones should have vchiq) | 10:35 |
| ali1234 | ogra_: i am using the server classic image | 10:36 |
| ogra_ | (on the device side that is though ... ) | 10:36 |
| ogra_ | ah, might be that doesnt have such fancy things :) | 10:36 |
| ali1234 | yeah i need my snap to be able to access it | 10:36 |
| ogra_ | do you see a device in /dev ? | 10:36 |
| ali1234 | the server image has vchiq... app works when run normally | 10:36 |
| ali1234 | yes | 10:36 |
| ogra_ | ah, k | 10:36 |
| ogra_ | bug 1533265 | 10:37 |
| mup | Bug #1533265: /dev/vchiq is inaccessible for unprivileged user <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1533265> | 10:37 |
| ali1234 | wow, other people actually tried this? | 10:37 |
| ali1234 | i thought i was the only one | 10:37 |
| ogra_ | yeah... | 10:37 |
| ogra_ | but i fear that wont happen before we have actual new images ... which is still a few weeks | 10:37 |
| ogra_ | kernel and gadget snaps have just seen their final definition during last weeks sprint | 10:38 |
| ali1234 | well, can i work around it? | 10:38 |
| ogra_ | you can indeed install your snap with --devmode | 10:38 |
| ali1234 | the snap itself is marked as confinement: devmode | 10:38 |
| ogra_ | thats only for the store | 10:38 |
| ogra_ | you need to specify --devmode at install time | 10:39 |
| ali1234 | okay | 10:39 |
| ogra_ | and probably poke zyga to get the needed interface in place faster | 10:39 |
| ali1234 | what does the store do with it btw? | 10:39 |
| ogra_ | not sure that is high on his prio list | 10:39 |
| ogra_ | it prevents the snap from going into the stable channel | 10:39 |
| ali1234 | i see | 10:39 |
| ali1234 | so now i got "qrc:///main.qml:1:1: module "QtQuick" is not installed" | 10:39 |
| ogra_ | did you include it in your snap ? | 10:40 |
| ogra_ | and is the searchpath pointing to the right place ? | 10:40 |
| ali1234 | i included the desktop/qt5 thingy | 10:40 |
| ogra_ | not sure if that has qtquick ... didrocks would know i guess | 10:40 |
| ali1234 | maybe only the older one includes qml | 10:41 |
| ali1234 | qt5conf | 10:41 |
| ogra_ | i think the new one is just the onld one included in the generic tree | 10:41 |
| ogra_ | not sure if thre are actual differences | 10:41 |
| ali1234 | it's quite a bit different | 10:41 |
| ali1234 | installs a lot more stuff | 10:42 |
| ogra_ | ah | 10:42 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | might be a bug with the new one then | 10:42 |
| ogra_ | (if the old one actually works) | 10:42 |
| ali1234 | well ti never saw the old one work due to bugs | 10:42 |
| ali1234 | but i thought it said it set up Qt "and QML" according to the readme | 10:43 |
| ali1234 | so regarding snapcraft cleanbuild | 10:43 |
| ali1234 | how can i notify it that it must use some PPAs? | 10:44 |
| ogra_ | that still doesnt work with external parts i think | 10:44 |
| ali1234 | okay but i can just include all my parts, that's not a problem | 10:44 |
| ogra_ | i think it is possible to set up a pre-created container where you can do such config stuff in advance ... but dont ask me how :) | 10:44 |
| ali1234 | i will probably need a custom launcher anyway | 10:44 |
| ali1234 | i do definitely need to include a ppa with the raspberry pi libraries, and another ppa with a patched Qt that uses it | 10:45 |
| ogra_ | using PPAs for a non cleanbuild build is trivial though ... it just uses the hosts sources.list | 10:45 |
| ali1234 | yes i know, that's what i am doing currently | 10:46 |
| ali1234 | (that's why i am using the server image) | 10:46 |
| ogra_ | well, i dont know how exactly you can use pre-created lxc containers for cleanbuild, but i knwo it is possible | 10:46 |
| ali1234 | hmm i staged qml-module-qtquick2 and qml-module-qtquick-xmllistmodel and libqt5declarative5 but it still says module QtQuick is not installed | 10:48 |
| ali1234 | hmm wait i think i need to clean | 10:48 |
| ali1234 | it works :) | 10:56 |
| ogra_ | \o/ | 10:56 |
| ogra_ | congrats | 10:56 |
| ali1234 | it would be really nice if someone who knew what they were doing packaged up Qt for EGLFS... then snappy would be a competitor for boot2qt (which is commercial only) | 10:58 |
| === hikiko is now known as hikiko|ln | ||
| sborovkov | zyga: Hello. So can I get snap-confine 1.0.38 or whatever version I need to get getwpuid working | 11:11 |
| === dpm is now known as dpm-lunch | ||
| ogra_ | sborovkov, i think there is one in xenial-proposed (i.e. not released and fully tested yet) | 11:30 |
| sborovkov | ogra_: hmm, so is that possible to install it? | 11:30 |
| sborovkov | Ah, found the repo | 11:31 |
| ogra_ | yes, (temporary) enable proposed, apt update ... apt install snap-confine ... disable -proposed again | 11:31 |
| ogra_ | (and apt update for making it clean) | 11:31 |
| didrocks | ali1234: are you sure you have the right version? If it's qtquick 1, you need qt4 | 11:38 |
| didrocks | and so the qt4 launcher | 11:38 |
| ali1234 | didrocks: yes i am sure | 11:38 |
| sborovkov | ogra_: do you by chance have any idea when snapd 2.0.11 will be released/appear in proposed | 11:39 |
| didrocks | otherwise, yeah, I only stage some declarative lib, but not the whole stack | 11:39 |
| mup | PR snapcraft#683 opened: Release changelog for 2.13.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/683> | 11:39 |
| didrocks | (to keep the launcher lighter for non qml projects) | 11:39 |
| ogra_ | sborovkov, nope ... | 11:39 |
| ali1234 | didrocks: why the gtk pixmap stuff? | 11:39 |
| didrocks | if you are using a qt5 project on a GNOME-based desktop, you need gtk pixmaps for the icon themes | 11:40 |
| ogra_ | sborovkov, you can watch bug 1605303 though | 11:40 |
| mup | Bug #1605303: [SRU] 2.0.11 <snapd (Ubuntu):New> <snapd (Ubuntu Xenial):New> <https://launchpad.net/bugs/1605303> | 11:40 |
| didrocks | (as it's using the gtk engine) | 11:40 |
| ali1234 | i'm not running any desktop at all... what should i do? | 11:40 |
| ali1234 | make my own launcher? | 11:40 |
| sborovkov | ogra_: Oh, nice, thanks | 11:40 |
| didrocks | ali1234: you can reuse the same launcher, and override stage-packages | 11:40 |
| ali1234 | i literally don't need any of the things you stage | 11:40 |
| didrocks | that way, you only pick what you want | 11:41 |
| ali1234 | oh, that's cool | 11:41 |
| didrocks | still keeping the same "executable" | 11:41 |
| ali1234 | so i don't need to fork it | 11:41 |
| didrocks | exactly! | 11:41 |
| didrocks | if the script doesn't work because of some missing deps which should be optional, we could fix it | 11:41 |
| ali1234 | it complains when i remove gdk pixbuf | 11:42 |
| didrocks | (I didn't try, so I may required some executables without testing for their existence first, I'm happy to fix if you poke me ;)) | 11:42 |
| didrocks | let me look | 11:42 |
| ali1234 | although actually i'm not sure *how* i removed it | 11:42 |
| ali1234 | it still works | 11:42 |
| ali1234 | it just prints an error "file not found" | 11:42 |
| ali1234 | hang on let me try thing | 11:42 |
| ali1234 | oh i see | 11:42 |
| ali1234 | what i did was add a new part that references the github one | 11:42 |
| ali1234 | let me pastebin my yaml | 11:43 |
| ali1234 | http://paste.ubuntu.com/20860640/ | 11:43 |
| didrocks | that works as well :) | 11:43 |
| ali1234 | the git repo is an identical fork of yours | 11:43 |
| ali1234 | but i suppose it is unnecessary | 11:43 |
| ogra_ | whee, version 0 | 11:44 |
| ogra_ | :) | 11:44 |
| didrocks | ali1234: right! | 11:44 |
| didrocks | ali1234: the error was on gdk-pixbuf-query-loaders? | 11:44 |
| ali1234 | i can't find the error now, seems to have stopped happening... i dunno whats going on | 11:45 |
| didrocks | we only compile first time you install | 11:45 |
| didrocks | and after each update of the snap | 11:45 |
| ali1234 | ah that would be why it went away | 11:45 |
| didrocks | (some steps can be long) | 11:45 |
| didrocks | yep! | 11:45 |
| ali1234 | i wondered why it took so long to start actually | 11:45 |
| didrocks | ok, it seems to be on this run, I didn't protect it, doing now | 11:45 |
| ali1234 | /snap/infodump/x19/bin/desktop-launch: line 113: /snap/infodump/x19/usr/lib/arm-linux-gnueabihf/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders: No such file or directory | 11:45 |
| ogra_ | you could just put libglib2.0 into your stage packages (if that doesnt pull in too many debs) | 11:46 |
| ogra_ | *deps | 11:46 |
| didrocks | yeah | 11:47 |
| didrocks | fixing this | 11:47 |
| didrocks | you need to ensure that you then have all working on various env | 11:47 |
| ogra_ | the script should probably get a check though and give you a nice hint ;) | 11:47 |
| didrocks | like icons and such | 11:47 |
| ali1234 | icons? | 11:48 |
| ogra_ | in case someone runs your snap on a desktop install | 11:48 |
| ali1234 | if they run my snap on a desktop install it absolutely definitely will not work | 11:48 |
| ogra_ | dont forget that your package is installable everywhere on different distros, desktops or core installs | 11:48 |
| ali1234 | it bundles a Qt built for eglfs | 11:48 |
| ali1234 | if your computer doesn't support eglfs it won't work | 11:49 |
| ogra_ | well, you should probably add a wrapper script that spits out a proper warning then | 11:49 |
| ali1234 | the binary already does that | 11:49 |
| ogra_ | ah, k | 11:49 |
| ali1234 | it will say that error i pasted early | 11:49 |
| ali1234 | * can't open vchiq probably | 11:49 |
| ogra_ | i'd also add that info to the long description of the package | 11:50 |
| ogra_ | so people dont accidentially install it because they dont know what it is | 11:50 |
| ali1234 | i'm not going to upload it to the store anyway | 11:50 |
| ogra_ | ah | 11:51 |
| ali1234 | it uses reverse engineered APIs, not just rss | 11:51 |
| ogra_ | then this doesnt matter indeed | 11:51 |
| ali1234 | i could make a "clean" version i suppose | 11:51 |
| ali1234 | actually it should be possible to make a snap that works in eglfs or xcb | 11:52 |
| didrocks | ali1234: pushed on master | 11:52 |
| ogra_ | it surely is ... the question is what overhead you need to ship then | 11:53 |
| ali1234 | didrocks: okay, so i should adjust my yaml to point back to the original repo? or is there a way to override the stage packages via the wikipart syntax? | 11:53 |
| ogra_ | (unused dependencies etc) | 11:53 |
| === hikiko|ln is now known as hikiko | ||
| didrocks | ali1234: I think there is, wait a sec | 11:53 |
| ali1234 | i'm really impressed with snapcraft btw | 11:53 |
| ali1234 | it's so easy | 11:54 |
| didrocks | ali1234: http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/, "composition" | 11:54 |
| didrocks | "composing"* | 11:54 |
| didrocks | sorry | 11:54 |
| ogra_ | ali1234, send your flowers to sergiusens and kyrofa ;) | 11:54 |
| didrocks | so, you just redifine the part | 11:54 |
| didrocks | redefineù | 11:54 |
| ogra_ | (yes, it is the best thing since sliced bread) | 11:54 |
| didrocks | and restart stage-packages (and build-packages) | 11:54 |
| ali1234 | neat | 11:54 |
| ali1234 | so how do i say stage-packages: none? | 11:55 |
| didrocks | stage-packages: [] | 11:55 |
| didrocks | empty list ;) | 11:56 |
| ogra_ | crazy stuff :) | 11:56 |
| ali1234 | so you *can* put all the packages into one line? | 11:56 |
| ali1234 | stage-packages: [foo, bar] | 11:56 |
| ali1234 | like that? | 11:56 |
| didrocks | yeah, that's pure yaml | 11:56 |
| ogra_ | yeah, yaml is very flexible with that | 11:56 |
| didrocks | can be quite unreadable easily though :p | 11:56 |
| didrocks | but for few ones, it's better to have one line IMHO | 11:56 |
| ogra_ | for long lists it surely is | 11:57 |
| ali1234 | hmm can't get this to work | 11:57 |
| didrocks | oh? | 11:58 |
| didrocks | can be a bug in snapcraft, I don't know who apart from Sergio really tested/used this override | 11:58 |
| ali1234 | i say after: [desktop/qt5] | 11:58 |
| ali1234 | but then i don't know what to put for the override part name | 11:59 |
| didrocks | after that, you set another part: | 11:59 |
| didrocks | destkop/qt5: | 11:59 |
| didrocks | stage-packages: [] | 11:59 |
| didrocks | that should be enough | 11:59 |
| e^1 | after coming across snappy i very much liked it, if i liked to contribute from where i can start ? | 11:59 |
| ali1234 | that doesn't work | 11:59 |
| ali1234 | Issues while validating snapcraft.yaml: The 'parts' property does not match the required schema: Additional properties are not allowed ('desktop/qt5' was unexpected) | 11:59 |
| didrocks | what do you get? | 12:00 |
| didrocks | interesting | 12:00 |
| didrocks | sergiusens: do you kow about that? ^ | 12:00 |
| didrocks | ali1234: so, meanwhile, redefine your part, refering to upstream source git | 12:00 |
| ogra_ | e^1, to what would you like to contribute ? to snappy itself, to the build tool (snapcraft) or do you want to snap packages ? | 12:00 |
| icey | does the snap store support private snaps? | 12:00 |
| e^1 | ogra_: to snappy as well as snapcraft | 12:00 |
| ogra_ | icey, it is surely planned, not sure it does for single snaps yet (you could always have a private sub-store though) | 12:01 |
| e^1 | wow it's in pythong :) :) | 12:01 |
| e^1 | snapcraft | 12:01 |
| ogra_ | e^1, https://github.com/snapcore/ should be a good start then | 12:01 |
| e^1 | s/pythong/python | 12:01 |
| e^1 | yeah just stumbled there.. | 12:01 |
| e^1 | ogra_: what about learning more snappy ? | 12:02 |
| icey | Thanks ogra_ | 12:02 |
| ali1234 | actually, does anyone have a raspberry pi running ubuntu/snapd/x11? | 12:02 |
| ali1234 | i could make a simple QML hello world, and see if it runs on x11 | 12:02 |
| ogra_ | e^1, for building snaps come to http://gitter.im/ubuntu/snappy-playpen ... there is where regular package sessions happen and people can answer questions regading snaps | 12:03 |
| sborovkov | ogra_: unfortunately, getpwuid still fails for me with newer snap-confine :( | 12:03 |
| e^1 | ogra_: arrived there :) | 12:04 |
| ogra_ | sborovkov, you had a bug for that, right ? make sure to note it there | 12:04 |
| e^1 | ogra_: how to know how exacly snappy works and how it is diff from regular linux distro ? | 12:04 |
| sborovkov | ogra_: No, I did not. I will create one though now. | 12:05 |
| ogra_ | e^1, https://developer.ubuntu.com/en/snappy/guides/ shows some basics ... i guess beyond this, mainly by asking people :) | 12:06 |
| e^1 | ogra_: cool :) | 12:07 |
| e^1 | ogra_: also is it possible to build snappy from scratch so we can understand what's going on ? | 12:08 |
| ogra_ | sure | 12:08 |
| e^1 | ogra_: can you shed some light about it ? | 12:08 |
| ogra_ | talk to zyga about that if you dont want to build deb packages for snapd and friends | 12:08 |
| ogra_ | (he is at a sprint this week though ... might only be rarely around) | 12:09 |
| e^1 | ok will ask zyga more regarding this | 12:09 |
| ogra_ | cjwatson, is bug 1606203 a bzr or LP bug ? (the log doesnt look like it is snapcraft) | 12:09 |
| mup | Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Snapcraft:New> <https://launchpad.net/bugs/1606203> | 12:09 |
| e^1 | it's just that i discovered a cool open source project i can work on.. | 12:09 |
| ogra_ | shiny title :) | 12:09 |
| e^1 | title ? | 12:10 |
| ogra_ | the bug that mup (the bot) posted | 12:10 |
| e^1 | ooh ok :) | 12:11 |
| sergiusens | didrocks it is fixed in master | 12:13 |
| sergiusens | didrocks and in snapcraft in -proposed | 12:13 |
| mup | PR snapd#1583 opened: snap: remove meta/kernel.yaml again <Created by mvo5> <https://github.com/snapcore/snapd/pull/1583> | 12:14 |
| sborovkov | ogra_: created the bug, do you know if I can bug anyone specific to take a look at that https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1606212 | 12:14 |
| e^1 | ogra_: can i installed updated versio of apps which are not available in snappy ? | 12:14 |
| mup | Bug #1606212: getpwuid is failing on classic image <snapd (Ubuntu):New> <https://launchpad.net/bugs/1606212> | 12:14 |
| ogra_ | sborovkov, add the snapd-interfaces tag to the bug, then jdstrand or tyhicks should see it on their lists | 12:15 |
| e^1 | ogra_: okay everything is similar only change is there is apps dir and almost nothing installed | 12:16 |
| didrocks | ali1234: ok, so wait for next-coming snapcraft release to do proper override ^ :) | 12:16 |
| didrocks | thanks sergiusens! | 12:16 |
| sborovkov | ogra_: thanks | 12:16 |
| cjwatson | ogra_: Looks like bzr has trouble talking to the Launchpad directory service through an authenticated proxy (it's getting a bit confused and using the proxy credentials in the wrong place), which is at least arguably a bzr bug. | 12:19 |
| cjwatson | ogra_: That will probably be no fun to fix, and bzr is largely unstaffed at the moment, so it may be most economical to hack snapcraft to unset https_proxy when calling bzr, with a comment explaining that this is due to this bug. | 12:19 |
| cjwatson | ogra_: It's definitely not an LP bug, I can say that much. | 12:20 |
| ogra_ | k | 12:20 |
| * cjwatson copies and pastes this into the bug report | 12:20 | |
| ogra_ | :) | 12:21 |
| ogra_ | i was about to | 12:21 |
| timothy | cjwatson: and if you need https_proxy to go to internet? :P | 12:21 |
| sergiusens | cjwatson I guess disabling the proxy if it would fail anyways is fine, more so that if you are using bzr you will most likely be using launchpad too | 12:21 |
| cjwatson | timothy: Right, hence the comment. | 12:21 |
| sergiusens | can we get this comment in the bug or can I paste this conversation? | 12:22 |
| cjwatson | timothy: But any non-LP-hosted bzr branch can be mirrored to LP, so there's a workaround. | 12:22 |
| cjwatson | sergiusens: Just did. | 12:22 |
| sergiusens | thanks cjwatson | 12:22 |
| timothy | I hope anything will be migrated to git (github) soon ;) | 12:22 |
| cjwatson | Or git (Launchpad) | 12:22 |
| timothy | it's the same | 12:22 |
| cjwatson | Sure, so just leave out the parenthetical :P | 12:22 |
| lool | ysionneau: Yop | 12:24 |
| ysionneau | hi! | 12:24 |
| e^1 | ogra_: were my questions too silly :P | 12:28 |
| === dpm-lunch is now known as dpm | ||
| ogra_ | e^1, sorry, i got distracted by actual work :) | 12:44 |
| ogra_ | can you re-phrase the questions a bit, i dont really understand them | 12:44 |
| sborovkov | ogra_: hmm, is snap-interfaces right though? I run unconfined | 12:44 |
| ogra_ | snapd-interfaces | 12:45 |
| ogra_ | i think | 12:45 |
| ogra_ | and yes, even when running unconfined (thats then actually a bug in the unconfined mode :) ) | 12:46 |
| zyga | sborovkov: let me check and get back t oyou | 12:48 |
| zyga | sborovkov: so looking at snapd, this system call is not allowed | 12:48 |
| zyga | sborovkov: you can use devmode for now | 12:50 |
| zyga | sborovkov: is there a bug on this? | 12:50 |
| sborovkov | zyga: Well there is no way to run without full screen apps on rpi without devmode anyway :) Created a bug just today https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1606212 | 12:52 |
| mup | Bug #1606212: getpwuid is failing on classic image <snapd-interfaces> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1606212> | 12:52 |
| sborovkov | zyga: the issue is it's not working in devmode as well :( | 12:53 |
| zyga | sborovkov: thank you, I will work on my backlog as time permits | 12:53 |
| zyga | sborovkov: that's unexpected, could be a kernel isuse | 12:53 |
| zyga | sborovkov: does it work outside of snaps? | 12:53 |
| sborovkov | zyga: Did not test that. I will create a simple app to test. Give me few minutes. Note that on snappy only system everything was working perfectly (though image I used was from few weeks ago). going to retest on snappy only system as well. | 12:54 |
| e^1 | ogra_: is it possible to update any app to latest version for example docker ? | 12:55 |
| e^1 | right now docker is quite older version | 12:55 |
| sborovkov | zyga: yup, just ran python, it works perfectly outside of snaps | 12:56 |
| zyga | sborovkov: ok, maybe you can share that demo | 12:56 |
| zyga | sborovkov: I can dig more | 12:56 |
| e^1 | zyga: np mate :) | 12:56 |
| zyga | sborovkov: but maybe just next week :) | 12:56 |
| ogra_ | e^1, sure, if you have a snapcraft.yaml or if upstream releases a new versuin | 12:56 |
| ogra_ | *version | 12:56 |
| sborovkov | zyga: demo? I just ran python3. import pwd; pwd.getpwuid(0); | 12:57 |
| ogra_ | i think a docker snap update is being worked on (i think someone said that here recently) | 12:57 |
| zyga | sborovkov: ok | 12:57 |
| zyga | sborovkov: thanks | 12:57 |
| zyga | sborovkov: does it work on x86? | 12:57 |
| sborovkov | zyga: I am not sure if it's architecture specific. We have screenly only working under arm at the moment. So I don't have snap for x86. is there easy way to just call python interpreter at the moment so I can check that? | 12:59 |
| sborovkov | from the snap I mean | 12:59 |
| zyga | sborovkov: I mean the tiny python one liner | 13:00 |
| zyga | sborovkov: no worries, I'll check it out | 13:00 |
| sborovkov | zyga: it works outside of snaps at least | 13:00 |
| e^1 | ogra_: cool | 13:00 |
| ogra_ | zyga, is mvo at the sprint ? there is an old snap-cconfine package in the image PPA that gets pulled into my os snap builds, can i remove that from the PPA ? | 13:03 |
| ogra_ | (still including the copmare-versions bug... i see it in my logs) | 13:03 |
| zyga | ogra_: yes he is | 13:04 |
| zyga | ogra_: old as in older than current? | 13:05 |
| zyga | ogra_: I think so, as long as it gets replaced by the new one in the archive | 13:05 |
| zyga | ogra_: though I'll let mvo answer with authority | 13:05 |
| sborovkov | zyga: Anyway I will test it on snappy only as well. It seems like I was using quite old image before. Have not updated for pretty long time since everything was working. May be it's not classic only issue. | 13:06 |
| ogra_ | zyga, older than whats in proposed ... but my builds dont use proposed atm, so the PPA version gets pulled in | 13:07 |
| sborovkov | zyga: yup, just build image with latest kernel/gadget snap. INstalled the same snap and it's working. So classic only issue | 13:21 |
| zyga | sborovkov: interesting, that is unexpected then | 13:23 |
| mup | PR snapcraft#683 closed: Release changelog for 2.13.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/683> | 13:27 |
| ogra_ | sergiusens, any chance you can put the prime/stage fixes for type: os on a high prio ? i dont really want to go back to cdimage builds if possible | 13:32 |
| ogra_ | (and i dont count on kyrofa this week given he will have to de-jetlag) | 13:33 |
| ogra_ | (i'd try to come up with a PR myself, but looking at the prime code i fear that would cause more work than helping) | 13:35 |
| ali1234 | i snapped the QML rssnews demo https://github.com/ali1234/rpi-qml-eglfs-snap | 13:37 |
| josepht | ogra_: is there a bug (or bugs) for the prime/stage fixes for type: os? | 13:38 |
| ogra_ | ali1234, oh, careful with silo ppas ... their content changes frequently ... | 13:38 |
| ali1234 | yes i know | 13:38 |
| ali1234 | but i could not find Qt 5.6 anywhere else | 13:38 |
| ogra_ | josepht, bug 1605903 | 13:38 |
| mup | Bug #1605903: "type: os" should prevent stage and prime stages from mangling content <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1605903> | 13:38 |
| ogra_ | ali1234, Mirv (in #ubuntu-devel or -touch) should have a pre-release PPA for the stuff before he pushes it to release | 13:39 |
| ali1234 | yeah, i'm going to ask him about that next | 13:39 |
| ali1234 | afaik silo 11 *is* the prerelase repo | 13:39 |
| ali1234 | (for xenial) | 13:39 |
| ogra_ | josepht, the best would be if they would just be skipped for anything but moving the content and creatings the files in meta/ | 13:40 |
| ogra_ | ali1234, ah ... then it might actually stay around for some weeks | 13:40 |
| ali1234 | is there a working all-snap image for rpi3 yet? | 13:43 |
| ogra_ | there isnt a working all-snaps image for anything yet | 13:44 |
| ali1234 | hmm what was i using before on rpi2 then? | 13:44 |
| ogra_ | we're waiting for the new ubuntu-image and teeh finalization of the new gadget and kernel snap specification | 13:44 |
| ogra_ | whatever is out there is obsolete | 13:45 |
| ali1234 | okay | 13:45 |
| ogra_ | or lets rather say "experimental" | 13:45 |
| ogra_ | :) | 13:45 |
| Pharaoh_Atem | Hello everyone! | 13:47 |
| liuxg | sergiusens, I have a snapcraft.yaml at http://paste.ubuntu.com/20872098/, which uses the license.txt file. however, when I compile it, I get a warining like http://paste.ubuntu.com/20872098/. when I install the snap file, it does not prompt me the license file. is there any problem with my snapcraft.yaml file? thanks | 14:07 |
| sergiusens | liuxg I guess that maybe these might be questions for Chipaca | 14:10 |
| liuxg | sergiusens, thanks! Chipaca, would you please have a check with my question? thanks | 14:16 |
| Croepha | you guys ever have snapd just die on you? and refuse to come back up with: could not unmarshal state entry "snaps": json: cannot unmarshal... | 14:48 |
| ogra_ | Chipaca, ^^^^ | 14:49 |
| ogra_ | bug 1604606 | 14:49 |
| mup | Bug #1604606: snapd fails to start due to: could not unmarshal state entry "snaps": json: cannot unmarshal string into Go value of type int <snapd (Ubuntu):New> <https://launchpad.net/bugs/1604606> | 14:49 |
| ogra_ | smells like that one | 14:50 |
| liuxg | elopio, ping | 15:03 |
| elopio | liuxg: 'sup? | 15:04 |
| liuxg | elopio, I found that you once tested the license implementation at https://github.com/snapcore/snapcraft/pull/201 however, I am now having a problem in using the license http://paste.ubuntu.com/20872098/ | 15:05 |
| mup | PR snapcraft#201: Add licensing support <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/201> | 15:05 |
| liuxg | elopio, do you know how to implement a license in the snapcraft? I once reported a bug againt it long time ago. thanks | 15:06 |
| elopio | liuxg: this is what you need from the snapcraft side: https://github.com/snapcore/snapcraft/tree/master/integration_tests/snaps/license | 15:07 |
| elopio | I'm not sure if that's working on the snapd side. If it is not, and there is no bug reported, you can open one for them. | 15:08 |
| liuxg | elopio, this is what I built for the project http://paste.ubuntu.com/20877984/. when I install it, it does not prompt the license. | 15:11 |
| elopio | liuxg: you can file a bug in launchpad.net/snappy | 15:12 |
| liuxg | elopio, is this a bug in the snapcraft or snappy? | 15:13 |
| elopio | liuxg: snappy, afaik. | 15:13 |
| liuxg | elopio, ok. I will do that. | 15:13 |
| liuxg | elopio, however, there is a warning like DEPRECATED: 'license' defined in snapcraft.yaml | 15:14 |
| liuxg | elopio, I think this could be related to the snapcraft, right? | 15:14 |
| elopio | liuxg: snapcraft puts the license in meta. | 15:15 |
| liuxg | elopio, however, it says that it is a deprecated "license" defined in the snapcraft.yaml. what should be correct way to do it? | 15:16 |
| elopio | the new style is to put it there yourself. We might be putting it in the wrong directory, or snappy could be ignoring it. | 15:16 |
| liuxg | elopio, when I build the project for the second time, it says http://paste.ubuntu.com/20878500/ | 15:16 |
| mup | PR snapd#1584 opened: asserts: introduce new parseHeaders <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/1584> | 15:17 |
| elopio | liuxg: that is a bug in snapcraft. Please report it in launchpad.net/snapcraft | 15:17 |
| liuxg | elopio, I have reported the bug at https://bugs.launchpad.net/snapcraft/+bug/1606283 | 15:19 |
| mup | Bug #1606283: license does not work in the snap installation. <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1606283> | 15:19 |
| elopio | thank you. | 15:19 |
| liuxg | elopio, you are welcome! | 15:20 |
| jdstrand | zyga: hi! hope you had a nice weekend and week last week :) | 15:20 |
| jdstrand | zyga: fyi, bug #1606277 | 15:20 |
| mup | Bug #1606277: log-observe interface is broken in latest snap-confine <snapd-interface> <snap-confine (Ubuntu):New> <https://launchpad.net/bugs/1606277> | 15:20 |
| mup | Bug #1606283 opened: license does not work in the snap installation. <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1606283> | 15:20 |
| === chihchun_afk is now known as chihchun | ||
| zyga | jdstrand: I just noticed, thank you for reporting this, I will fix and release it today | 15:23 |
| cwayne | zyga: hey, do you know when the next planned release of ubuntu-core snap is? | 15:29 |
| cwayne | and do you think there's a chance https://github.com/snapcore/snapd/pull/1563 lands before that | 15:29 |
| mup | PR snapd#1563: Interfaces: hardware-observe <Created by cwayne18> <https://github.com/snapcore/snapd/pull/1563> | 15:29 |
| timothy | cwayne: snapd and snap-core are different projects | 15:30 |
| timothy | err snapd-confine | 15:31 |
| jdstrand | tyhicks: hey, fyi latest comments in bug #1584456 | 15:39 |
| mup | Bug #1584456: apparmor denial using ptmx char device <apparmor> <Snappy:Confirmed> <https://launchpad.net/bugs/1584456> | 15:39 |
| zyga | cwayne: nope, I don't know | 15:39 |
| zyga | cwayne: maybe mvo knows | 15:39 |
| jdstrand | zyga: thanks | 15:39 |
| tyhicks | jdstrand: thanks - I hope that I can work on fixing that bug this week | 15:42 |
| renatu | jdstrand, do you know who wrote the "calendar" policygroup for calendar? | 15:51 |
| renatu | apparmor used by the phone | 15:51 |
| renatu | zyga, what is the difference btw the permanent rule and connected rule, on a snap interface? | 15:52 |
| jdstrand | renatu: I did | 15:55 |
| renatu | jdstrand, could you take a look on that: https://github.com/renatofilho/snapd/commit/198974dddac4e30a971f893b7fb402d662acf637 | 15:56 |
| renatu | jdstrand, I did some small changes, to adapt it to a snap interface. Still not clear for me why do we need permanent and PermanentSlotDBus | 15:57 |
| jdstrand | renatu: I can explain permanent vs connected. a permanent rule is something that is always there regardless of whether snaps are connected. slot side permanent policy is typically used for whatever is needed to allow a server that connecting snaps talk to to run. permanent plugs policy isn't used much | 15:57 |
| jdstrand | renatu: where is this interface supposed to be used? are you implementing an eds-calendar snap for other snaps to connect to or are you having snaps connect to the session eds on classic? | 15:59 |
| renatu | jdstrand, ubuntu-calendar-app | 15:59 |
| jdstrand | sure, that is an app | 15:59 |
| renatu | jdstrand, https://code.launchpad.net/~renatofilho/+junk/ubuntu-calendar-app-snappy | 15:59 |
| jdstrand | but what is it connecting to? | 15:59 |
| renatu | jdstrand, eds. | 16:00 |
| renatu | we do not have eds snappy yet | 16:00 |
| jdstrand | yes, but an eds provided by a snap or by the system? | 16:00 |
| jdstrand | ok | 16:00 |
| renatu | jdstrand, by the system now | 16:00 |
| jdstrand | so if provided by the system, then you don't worry about slot side policy | 16:00 |
| jdstrand | slot side policy is for snaps that provide a service that other snaps plug into | 16:01 |
| jdstrand | so, if/when you implement eds as a snap, then you'd need to create slot policy | 16:01 |
| jdstrand | based on what you've said here, you just need connected plug policy | 16:01 |
| jdstrand | and return nil for everything else | 16:02 |
| jdstrand | (permanent slot, connected slot and permanent plugs) | 16:02 |
| renatu | jdstrand, should I create a new interface for the server? or I can mix both? | 16:02 |
| jdstrand | you can mix | 16:02 |
| renatu | jdstrand, in EDS case, we have contacts and calendar | 16:02 |
| jdstrand | but if you are planning on doing that, it would be good to name it so that it fits | 16:02 |
| renatu | probably we will want a contact interface | 16:02 |
| jdstrand | that's fine but they can still be split into eds-calendar and eds-contacts | 16:03 |
| jdstrand | since those are different dbus APIs | 16:04 |
| renatu | jdstrand, they share the same source registry | 16:04 |
| renatu | interface | 16:04 |
| jdstrand | I see what you mean-- the slot would be the same but the plugs could be different | 16:05 |
| jdstrand | ok, so, probably should be named 'eds', not 'eds-calendar' | 16:05 |
| jdstrand | then we can use interface attributes to specify calendar, contacts or both | 16:05 |
| renatu | jdstrand, any example of that? | 16:06 |
| jdstrand | in this manner, an eds snap can 'slots; [ eds ]' and a consuming snap could pick which it needs | 16:06 |
| jdstrand | renatu: bool_file and seriral_port both use attributes | 16:07 |
| jdstrand | renatu: there are some other PRs in flight that do too | 16:08 |
| renatu | jdstrand, nice, I will take a look. Thanks | 16:08 |
| jdstrand | renatu: but the basic idea would be, you set up cariables for common policy for talking to eds at all, then calendar policy and contacts policy. you look at the interface attributes and always add common, and then calendar and/or contacts depending on the attributes | 16:09 |
| renatu | jdstrand, ok, I think I got the idea. Let me se if I can implement that ;) | 16:09 |
| renatu | jdstrand, if I have a permanent rule means that any app that make use of this rule can use that? Could a app take ownership of the service by mistake? Or there is a specific rule/property for that? | 16:26 |
| jdstrand | renatu: a permanent rule simple means that it is given unconditionally to the snap regardless of auto-connect | 16:28 |
| jdstrand | renatu: they are typically only used on the slot side since a server implementing the slot side (ie, eds itself) may need certain things to run at all | 16:29 |
| jdstrand | renatu: so, a slot permanent rule might be an apparmor rule for binding to a dbus well-known name | 16:29 |
| jdstrand | renatu: a connected rule on the slot side might be an apparmor rule allowing a specific security label (ie, snap) to connect to the server | 16:30 |
| jdstrand | renatu: a connected rule on the plug side might be an apparmor rule allowing connecting to the slot side security label (ie, the eds snap or the unconfined eds system-supplied snap) | 16:31 |
| jdstrand | renatu: does that make sense? | 16:32 |
| jdstrand | renatu: if you haven't already, you might want to read zyga's blog series: http://www.zygoon.pl/2016/04/snappy-snapcraft-and-interfaces.html | 16:32 |
| elopio | didrocks: can you please add me to the ubuntu team in github? | 16:36 |
| elopio | I want to make a docker image with autobuild for snapcraft:master. And we can move yours to a team too. | 16:36 |
| elopio | we can put both dockerfiles in snappy-playpen. | 16:36 |
| Pharaoh_Atem | zyga: just saw your review request and I'm taking the review for goconfigparser | 16:40 |
| zyga | Pharaoh_Atem: thank you | 16:41 |
| zyga | Pharaoh_Atem: I have a few important emergency things I need to do upstream but I will request snap-confine review next | 16:41 |
| zyga | Pharaoh_Atem: and snapd, without the preset bits | 16:41 |
| Pharaoh_Atem | does snap-confine have selinux integration at this point, or is it essentially a stub still? | 16:42 |
| elopio | marcoceppi: arosales: or maybe you can add me to the ubuntu org in github. | 16:42 |
| mup | PR snapcraft#684 opened: Run tests from /tmp <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/684> | 16:42 |
| didrocks | elopio: added! | 16:42 |
| didrocks | elopio: this is the repo having the docker recipe: https://github.com/ubuntu/docker-snapcraft | 16:43 |
| zyga | Pharaoh_Atem: no, it's not even in master yet, | 16:44 |
| zyga | Pharaoh_Atem: it's not a stub, it does other things but doesn't do anything selinux yet | 16:44 |
| Pharaoh_Atem | ah okay | 16:44 |
| zyga | Pharaoh_Atem: I need to stop sprinting at some point and actually sit down and do stuff ;-) | 16:45 |
| elopio | didrocks: awesome! thanks. | 16:46 |
| didrocks | yw :) | 16:47 |
| e^1 | zyga: hey :) i would like to know how to create ubuntu core from scratch ? | 16:55 |
| ogra_ | e^1, that happens in the image build machinery of ubuntu ... the same place where the CD image isos are built | 16:55 |
| ogra_ | it uses ubuntu-cdimage and live-build currently ... the config lives in the livecd-rootfs package | 16:56 |
| e^1 | ogra_: ok let me google more about it.. | 17:00 |
| e^1 | ogra_: what is the basic difference between ubuntu core and normal ubuntu desktop ? | 17:02 |
| e^1 | only snappy makes the difference ? | 17:02 |
| ogra_ | ubuntu core is about 70MB big | 17:02 |
| e^1 | it seems that snappy is added on ubuntu core if i am not mistaken.. | 17:02 |
| ogra_ | it is just enough OS to boot and run snapd | 17:03 |
| jrwren | i can't figure out the difference between ubuntu-base and ubuntu-core | 17:04 |
| ogra_ | e^1, http://wiki.ubuntu.com/ReleaseTeam/CDImageSetup | 17:04 |
| ogra_ | that has some info about the ubuntu build system and where to get the source | 17:05 |
| ogra_ | jrwren, one is a tarball to be used for build chroots, the other is an embedded OS | 17:05 |
| jrwren | ogra_: interesting. thanks! | 17:06 |
| ogra_ | (well, for build chroots, or as base for creating some other installs etc etc) | 17:06 |
| ogra_ | ubuntu-base -> non booting rootfs, just enough to run apt | 17:06 |
| ogra_ | ubuntu-core -> embedded bootable OS based on snaps, just enough OS to boot and run snapd | 17:07 |
| e^1 | ogra_: nice info | 17:07 |
| e^1 | ogra_: so following CDImageSetup we can create 70MB ubuntu core image ? | 17:08 |
| e^1 | but that's CD so it must be quite big | 17:08 |
| ogra_ | no | 17:08 |
| ogra_ | well, yes, but the cdimage setup is very complex | 17:09 |
| ogra_ | that page is just about how to contribute code | 17:09 |
| ogra_ | i dont think the setup is well documented beyond the source code itself | 17:09 |
| e^1 | ogra_: where i can find more info regarding ubuntu core image ? | 17:09 |
| * ogra_ has seen others gove up after spending ages on trying it locally | 17:10 | |
| Pharaoh_Atem | zyga: golang(github.com/mvo5/goconfigparser) review approved: https://bugzilla.redhat.com/show_bug.cgi?id=1359804 | 17:10 |
| ogra_ | the image is built from a kernel snap, a gadget snap and the ubuntu-core snap ... | 17:10 |
| e^1 | ogra_: doubt cleared :) | 17:11 |
| SamYaple | yo yo jdstrand . RE our conversation the other day about named sockets and what have you, all is good i believe. if we implement the /etc/* bindmount/overlay like you were suggesting I can tie all of this together and have it work well | 17:11 |
| ogra_ | the ubuntu-core snap and the kernels snap are currently created by the cdimage build system | 17:11 |
| e^1 | ogra_: now say if i want to install any specific app i need to first package it in snappy format is that correct ? | 17:11 |
| SamYaple | jdstrand: i gave it a good once over and it should be solid | 17:11 |
| ogra_ | atm we use a tool called ubuntu-device-flash to assemble these snaps ... it downlods them from the snap store and assembles an img | 17:12 |
| ogra_ | but that tool is rather abandoned, a new tool called ubuntu-image is in the works. that will directly hook into the cdimage build system | 17:12 |
| ogra_ | e^1, right ... if you wanted ... say a raspberry PI kodi image you would have to package kodi as snap and push it to the store ... then create a gadget snap with the rpi uboot setup inside that says you want a rpi kernel and that you want the kodi snap from the store pre-installed | 17:14 |
| ogra_ | currently ubuntu-device-flash would then take your gadget snap from disk, pull the pi kkernel from the store, the ubuntu-core snap and the kodi snap ... and roll all of them into a bootable SD card image | 17:15 |
| jdstrand | SamYaple: nice! if you haven't already, you might mention the bind mount stuff in bug #1577514 | 17:16 |
| mup | Bug #1577514: Support preloading to make snaps feel at home <snapd-interface> <Snapcraft:Triaged by sergiusens> <https://launchpad.net/bugs/1577514> | 17:16 |
| SamYaple | jdstrand: alrighty ill do it now | 17:16 |
| * ogra_ has the feeling that "tiny preloading library" might become rather big ... | 17:17 | |
| ogra_ | seeing it mentioned in so many bugs | 17:17 |
| SamYaple | ogra_: LD_PRELOAD solves all the things and isnt full of security problems dont ya know? | 17:17 |
| jdstrand | I think niemeyer has a creative way to keep it small and generic (as I outlined my understanding in the aforementioned bug) | 17:18 |
| jdstrand | hehe | 17:18 |
| e^1 | ogra_: it's quite difficutl to digest but getting a rough idea.. | 17:18 |
| jdstrand | well, LD_PRELOAD in this context is ok cause the process is running under confinement and can still only access its own stuff | 17:18 |
| ogra_ | SamYaple, haha | 17:19 |
| ogra_ | the prob is to get all the APIs right and not miss anything an app expects from the function you replace | 17:19 |
| ogra_ | and by the looks of it there will be a lot of functions piling up over time | 17:21 |
| Pharaoh_Atem | zyga: you have a problem in https://bugzilla.redhat.com/show_bug.cgi?id=1359802 | 17:23 |
| e^1 | ogra_: can i use ubuntu base and chroot into ubuntu core and customize it ? | 17:31 |
| e^1 | or how can i customize ubuntu core ? | 17:32 |
| ogra_ | for local experiments you caan re-pack the snap ... | 17:32 |
| e^1 | ogra_: i am not getting you mate.. | 17:32 |
| ogra_ | you can re-pack the snap and sideload it | 17:32 |
| e^1 | ogra_: you have any wiki or something on this / | 17:33 |
| ogra_ | nope | 17:33 |
| ogra_ | it isnt even done yet ... | 17:33 |
| e^1 | ogra_: say for example i want to install apt-get than how can i do that ? | 17:33 |
| ogra_ | docs will come once we actually provide images :) | 17:33 |
| ogra_ | you cant ... | 17:34 |
| ogra_ | there is a classic mode shipped though | 17:34 |
| e^1 | ogra_: okay.. | 17:34 |
| ogra_ | that can give you a container to run apt in | 17:34 |
| e^1 | ogra_: than what about adding a custom binary ? that too no ? | 17:34 |
| e^1 | this means ubuntu core is locked, you can change anything straight away.. | 17:34 |
| ogra_ | i think mvo wrote a longish mail to the mailing lists a few weeks ago ... check the archives | 17:34 |
| e^1 | okay | 17:35 |
| e^1 | will dig mailing list.. | 17:35 |
| ogra_ | for experimenting around you can unpack the ubuntu-core snap, make your changes and snap it again | 17:35 |
| ogra_ | (and then sideload it into your image) | 17:37 |
| e^1 | ogra_: in simple terms unpack this image ubuntu-15.04-snappy-amd64+generic.img.xz ? | 17:41 |
| ogra_ | ah, no, that is old cruft | 17:42 |
| e^1 | than which image ? | 17:42 |
| ogra_ | the 15.04 model is obsolete | 17:42 |
| e^1 | 16.04 ? | 17:42 |
| ogra_ | people.canonical.com/~mvo/all-snaps/ has some very old (and possibly completely broken today) images | 17:43 |
| e^1 | the image is not available http://releases.ubuntu.com/16.04/ | 17:43 |
| ogra_ | and an ubuntu-device-flash-experimental that you can use to roll something more recent | 17:43 |
| ogra_ | there have been no proper or official 16.04 images yet ... | 17:44 |
| ogra_ | all resources that could work on this have been focused on cross-distro stuff and integration into classic installs, so the images are a bit behind | 17:45 |
| e^1 | ogra_: haha lots of new stuff :) | 17:45 |
| ogra_ | we just had a sprint last week where we met to finalize the specs for the images | 17:45 |
| e^1 | ogra_: if i want to contribute in all this stuff than where should i start from ? | 17:46 |
| ogra_ | depends what you want (i think i said that in th beginning already ;) ) | 17:46 |
| e^1 | hmm yeah :) | 17:46 |
| mup | PR snapd#1585 opened: store, daemon, client, cmd/snap, docs/rest.md: adieu search grammar <Created by chipaca> <https://github.com/snapcore/snapd/pull/1585> | 17:47 |
| e^1 | ogra_: so i have to unpack this ubuntu-device-flash image and make changes and pack it ? | 17:47 |
| ogra_ | no | 17:47 |
| e^1 | than which image i should work on ? | 17:48 |
| ogra_ | you would grab the ubuntu-core snap from inside it (easiest would be from a booted image) | 17:48 |
| ogra_ | and unpack that ... | 17:48 |
| ogra_ | then change it | 17:48 |
| ogra_ | and ssnap it again | 17:48 |
| ogra_ | then sideload it into the running image | 17:48 |
| e^1 | ogra_: i am already booted into ubuntu snappy | 17:49 |
| e^1 | ubuntu-core | 17:49 |
| ogra_ | it isnt really clear to me what you want to do there though | 17:49 |
| ogra_ | it is more likely that we remove (a lot) more stuff than that we add anything to it ... | 17:49 |
| e^1 | ogra_: i want to add custom binaries to it | 17:50 |
| e^1 | or custom apps | 17:50 |
| ogra_ | then do it like i explained in the kodi example above | 17:50 |
| e^1 | that's the main thing.. | 17:50 |
| ogra_ | you dont modify the ubuntu-core snap | 17:51 |
| ogra_ | but add another snap package | 17:51 |
| ogra_ | through a definition in your gadget snap ... at image build time | 17:51 |
| e^1 | ogra_: as you said 'grab the ubuntu-core snap from inside it from the booted image' so just curious how to do that ? | 17:53 |
| ogra_ | using scp | 17:53 |
| e^1 | and i am sorry i am annoying you much.. | 17:53 |
| e^1 | if* | 17:53 |
| * Chipaca hugs ogra_ | 17:53 | |
| * ogra_ hugs Chipaca | 17:54 | |
| ogra_ | no worries, i'm fine :) | 17:54 |
| e^1 | ogra_: yeah but what should i scp ? which exact location ? | 17:54 |
| ogra_ | check the output of the mount command ;) | 17:54 |
| ogra_ | you will see i guess | 17:54 |
| ogra_ | (piping to a "grep ubuntu-core" might be helpful to filter a bit | 17:55 |
| ogra_ | ) | 17:55 |
| ogra_ | iirs it is somewhere in /var/snap | 17:56 |
| ogra_ | or /var/lib/snap or so | 17:57 |
| ogra_ | still though ... adding stuff ... if it is more complex than a standalone binary in /usr/bin will mean a lot of other changes | 17:58 |
| Chipaca | /var/lib/snapd/snaps/ubuntu-core_potato.snap | 17:58 |
| ogra_ | i.e. apt will definitely not work if you just add it | 17:58 |
| ogra_ | such a change needs extra integration work in other places | 17:58 |
| Chipaca | ogra_, I'm assuming it's for educational purposes | 17:58 |
| ogra_ | me too :) | 17:58 |
| * Chipaca goes back to watching spread like a hawk | 17:59 | |
| e^1 | yeah got that :) | 18:01 |
| e^1 | this means this is not like other ordinary linux distro.. | 18:02 |
| e^1 | in this lots of stuff have been changed | 18:02 |
| ogra_ | not really | 18:03 |
| ogra_ | but if you change stuff at the readonly core you need to do other stuff | 18:03 |
| ogra_ | this system is designed for and around snaps | 18:04 |
| ogra_ | so if you want to add things, create a snap for it | 18:04 |
| ogra_ | ;) | 18:04 |
| e^1 | first of all i need to understand the structure of ubuntu core and than how snaps work | 18:07 |
| e^1 | this will make things more clear in my brain. | 18:07 |
| ogra_ | the image boots into the readonly snap ... then bind mounts writable bits for it into the writabble partition during the boot process ... then it starts snapd | 18:09 |
| ogra_ | thats all | 18:09 |
| ogra_ | (well, there is a normal ubunt boot process around it using systemd ) | 18:11 |
| e^1 | ogra_: okay, there are 2 new dir apps and writable under / dir | 18:24 |
| ogra_ | ? | 18:28 |
| e^1 | ogra_: according to me only certain dir or portion of the system might be getting version control thus it can be roll back to previous state | 18:32 |
| e^1 | thus keeping the config files intact is that correct ? | 18:32 |
| ogra_ | well, the rollback mchanism relies on the fact that the snaps are readonly blobs that do not change | 18:33 |
| ogra_ | config files are kept for the specific version of a snap | 18:33 |
| ogra_ | so when you roll back you actually go back to both, the old snap and the old config | 18:33 |
| e^1 | cool :) | 18:34 |
| ogra_ | a snap allwayskeeps two versions around | 18:34 |
| e^1 | old and new | 18:34 |
| ogra_ | right | 18:34 |
| e^1 | the same concept as git | 18:34 |
| e^1 | Directed Acyclic graphs :) | 18:35 |
| ogra_ | and since everything is a snap (kernel, rootfs, bootloader) this concept applies to everything in the system | 18:36 |
| ogra_ | (well, and app snaps too indeed) | 18:36 |
| e^1 | super cool | 18:37 |
| e^1 | ogra_: now i reallly very much interested to learn the complete process of packing ubuntu core, this would unravel lot's of important info.. | 18:43 |
| ogra_ | not really ... the magicis in snapd and in snapcraft really | 18:44 |
| e^1 | how each piece stick to each other and work, the version control thing.. | 18:44 |
| ogra_ | it works exactly the same on any ubuntu 16.04 desktop or server ... | 18:44 |
| e^1 | ogra_: okay, let me first investigate snapd and snapcraft | 18:44 |
| ogra_ | just that ubuntu-core actually boots from the ubuntu-core snap instead of a classic riootfs | 18:45 |
| e^1 | ogra_: so this provides the advantage or rollback of even the older kernel right ? | 18:45 |
| e^1 | s/or/of | 18:46 |
| e^1 | or booting older kernel | 18:46 |
| ogra_ | yes | 18:46 |
| e^1 | awesome | 18:46 |
| ogra_ | there is some logic in our bootloader scripts that will do that automatically | 18:46 |
| ogra_ | if the system gets a kernel panic on boot, it willl automatically roll back | 18:46 |
| e^1 | ogra_: are those opensource i.e. available on github ? | 18:46 |
| ogra_ | they are in llaunchpad | 18:47 |
| ogra_ | public, yes | 18:47 |
| e^1 | can you link me if possible ? | 18:47 |
| ogra_ | not easily ... i'm running an eyperimental unity8 here ... copy paste beween browser and irc client doesnt work atm :P | 18:48 |
| ogra_ | one sec | 18:48 |
| ogra_ | (yes, it is as painful as it sounds) | 18:48 |
| e^1 | hehe np, what the name of the repo ? | 18:48 |
| ogra_ | google for "launchpad snappy-hub snappy-systems" | 18:49 |
| ogra_ | the first hit should be the right one | 18:49 |
| e^1 | ogra_: https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems :) | 18:51 |
| ogra_ | right | 18:51 |
| ogra_ | these are the sources for the currennt gadget snaps | 18:52 |
| ogra_ | if you look at the snappy_boot variablein the uboot.env.in files you see the boot logic ... | 18:53 |
| ogra_ | that works hand in hand with snapd which takes over once the system is booted and sets the right variables in the bootloader to notify a successful boot | 18:53 |
| e^1 | yeah saw that file | 18:56 |
| e^1 | but right now that's only for dragonboard ? | 18:56 |
| zyga | Pharaoh_Atem: replied | 18:57 |
| zyga | Pharaoh_Atem: I think it is actually okay | 18:57 |
| e^1 | looks like ogra_ you are a core developer | 18:58 |
| ogra_ | e^1, nope | 18:58 |
| e^1 | contributor ? | 18:58 |
| ogra_ | (nope, not only for dragonboard) | 18:58 |
| e^1 | ohh ok :) | 18:59 |
| ogra_ | (yes, i'm responsible for the image builds ... ) | 18:59 |
| e^1 | ogra_: than you can become my mentor :P in image build stuff :) ( i know it's not possible but still in my wildest dreams :) ) | 19:00 |
| ogra_ | why wouldnt it :) | 19:00 |
| ogra_ | we appreciate all contributions ... | 19:01 |
| e^1 | super awesome :) | 19:01 |
| e^1 | give me HW to start with, like an assignment hehe | 19:02 |
| ogra_ | well, get a raspberry pi2 | 19:02 |
| e^1 | will pi3 do, it's available right now on amazon | 19:03 |
| ogra_ | pi3 will do as well | 19:03 |
| e^1 | ordered pi3 | 19:06 |
| e^1 | now ? | 19:07 |
| ogra_ | well, you wait i guess :) | 19:07 |
| e^1 | ogra_: once i get it let me know what i am suppose to do and will start with that.. | 19:09 |
| ogra_ | yup | 19:09 |
| e^1 | cool :) | 19:10 |
| e^1 | thanks for todays useful info :) | 19:13 |
| ogra_ | np | 19:14 |
| e^1 | ordered a beautiful case too | 19:14 |
| e^1 | ogra_: do i need to order any other stuff which will be useful ? | 19:14 |
| ogra_ | a serial cable for it | 19:14 |
| e^1 | okay | 19:15 |
| e^1 | ogra_: like this one ? http://www.amazon.in/Honey-House-USB-Serial-Cable/dp/B00PQMUBQK/ref=sr_1_1?ie=UTF8&qid=1469474224&sr=8-1&keywords=serial+cable+raspberry+pi2~ | 19:17 |
| ogra_ | yes | 19:18 |
| e^1 | what will be this useful for ? | 19:18 |
| ogra_ | if you want to tinker with the bootloader or initrd you need console access | 19:19 |
| e^1 | okay | 19:20 |
| e^1 | ogra_: are those cable specific for pi2 pi3 or pi1 ? | 19:21 |
| ogra_ | they are pretty unniversal | 19:21 |
| e^1 | okay, because i found some product listing written pi2 on it.. so i thought it's better to clear the confusion | 19:22 |
| zyga | Pharaoh_Atem: are you and Son_Goku one person? | 19:36 |
| Pharaoh_Atem | zyga: yes | 19:50 |
| Pharaoh_Atem | zyga: Son_Goku is my laptop, while Pharaoh_Atem is my workplace workstation | 19:51 |
| ogra_ | thats confusing :) | 19:51 |
| ogra_ | (as someone talking to you) | 19:51 |
| Pharaoh_Atem | the server I used to have for doing IRC stuff normally used Conan_Kudo | 19:51 |
| Pharaoh_Atem | and my home desktop computer used King_InuYasha | 19:52 |
| ogra_ | oh m | 19:52 |
| ogra_ | y | 19:52 |
| ogra_ | and you expect people to memorize all these names to remember whom they talk to ? | 19:52 |
| Pharaoh_Atem | nah | 19:53 |
| Pharaoh_Atem | most of my other selves aren't really around anymore | 19:53 |
| ogra_ | well, it makes sustained conversations over multiple days quite hard | 19:53 |
| Pharaoh_Atem | just Pharaoh_Atem and Son_Goku most of the time | 19:53 |
| ogra_ | k, 2 are handleable :) | 19:54 |
| Pharaoh_Atem | I don't often talk much as Pharaoh_Atem, since it's just my workstation | 19:54 |
| Pharaoh_Atem | usually I'm at work doing work things :) | 19:54 |
| ogra_ | i heard of that "work" thing before | 19:54 |
| Pharaoh_Atem | but when people need to reach me, I'm always available (or at least able to respond later | 19:54 |
| Pharaoh_Atem | ) | 19:54 |
| * ogra_ kind of got used to having a well paid hobby instead ... :D | 19:56 | |
| Pharaoh_Atem | unfortunately, most of us don't have one of those | 19:56 |
| Pharaoh_Atem | and some of us have to work hard to keep work and things we like doing separate | 19:56 |
| ogra_ | well, doing your hobby as your job isnt that easy ... since it is really really hard to stop working then | 19:57 |
| ogra_ | look at zyga ... he is at a sprint, it is 10pm and he should sit in a bar with his colleagues ... instead he chats on IRC ;) | 19:57 |
| e^1 | ogra_: while ordering sd card should i get NOOBS preinstalled or anyway i need to format it to install snappy on it.. | 19:58 |
| Pharaoh_Atem | for me, it just means that I have to push out the time I get to do the stuff I want to do to even later at night | 19:58 |
| ogra_ | e^1, just any SD card will do | 19:58 |
| Pharaoh_Atem | it's not uncommon for me to be working from when I leave work at around 7pm to about 1am | 19:58 |
| e^1 | ogra_: cool :) | 19:58 |
| stokachu | i've got a snap built but hitting a problem with the binary, my setup.py uses the console-scripts entrypoint https://github.com/ubuntu/conjure-up/blob/master/setup.py#L21 | 20:09 |
| stokachu | how do i make that work with snaps? | 20:09 |
| stokachu | http://paste.ubuntu.com/20912532/ thats my snapcraft.yaml | 20:09 |
| ogra_ | stokachu, does entry point refer to a service being up ? | 20:11 |
| stokachu | ogra_: its just the resulting cli tool | 20:12 |
| ogra_ | but you refer to console-setup in the host system your snap runs on ? | 20:13 |
| e^1 | ogra_: done :) so we are going to install snappy on pi and learn building images ? | 20:13 |
| e^1 | just thinking where was i this many days, not ordering a pi :P | 20:14 |
| stokachu | ogra_: yea | 20:14 |
| stokachu | ogra_: i just want to translate python3 setup.py install that creates the bin/conjure-up in the snapcraft file | 20:15 |
| ogra_ | e^1, well, i need to write a porting documentation ... so we can exercise that you build all bits from scratch and i can take notes for the doc from a new-users perspective ;) ... note though that it will still be some days/weeks til the new image setup is ready | 20:15 |
| Pharaoh_Atem | ogra_: zyga and I are going to wind up being close buddies for a long time :) | 20:15 |
| ogra_ | stokachu, well, thats tricky, you can ship console-setup in build-packages but thats only living inside your snap ... you wont actually get anything fro the host system without having an interface if you want any runtime stuff | 20:16 |
| ogra_ | Pharaoh_Atem, you doing a distro port with him ? | 20:17 |
| Pharaoh_Atem | yep | 20:17 |
| Pharaoh_Atem | we're working on the Fedora stuff | 20:17 |
| ogra_ | ah | 20:17 |
| Pharaoh_Atem | and once Fedora is working, I'll be pulling it into Mageia | 20:17 |
| ogra_ | yay | 20:17 |
| Pharaoh_Atem | and I'll be comaintainers with him in Fedora | 20:17 |
| ogra_ | bring it on ! | 20:17 |
| stokachu | ogra_: so i'd need to make a service on the host system in order to interact with it via the cli? | 20:17 |
| stokachu | as its interface | 20:17 |
| e^1 | ogra_: cool :) | 20:18 |
| ogra_ | stokachu, your app will run in a sandbox ... to talk to the outside world you need to have an interface | 20:18 |
| ogra_ | one half of the interface is provided by the OS (and needs to be implemented there) ... the other has to be provided by you | 20:18 |
| ogra_ | stokachu, zyga is your man for details | 20:19 |
| Pharaoh_Atem | though the snap system has some serious issues to resolve before we can get to that point | 20:19 |
| stokachu | ok thanks | 20:19 |
| ogra_ | yo mean like selinux ? | 20:19 |
| Pharaoh_Atem | selinux, snapcraft stuff, etc. | 20:19 |
| ogra_ | well | 20:19 |
| ogra_ | the only way to make snapcraft usable is to have a cross distro db to map package names | 20:20 |
| Pharaoh_Atem | or do "on <distro:rel>" stanza | 20:20 |
| ogra_ | else snapcrafts idea of having one snapcraft.yaml you can use foor everything becomes pointless | 20:20 |
| ogra_ | uh | 20:20 |
| Pharaoh_Atem | that will allow it to point to specific repositories no matter where it's being run from | 20:21 |
| ogra_ | but that would mean you need to do that for every build and stage package for all distros to get a universal snapcraft.yaml | 20:21 |
| Pharaoh_Atem | no | 20:21 |
| ogra_ | ending up with multi page yaml files | 20:21 |
| Pharaoh_Atem | it means that no matter what distro you use, it would ALWAYS use whatever you declared | 20:21 |
| Pharaoh_Atem | so if I made a snapcraft.yaml that says the snap uses Fedora as a base, it will ALWAYS use Fedora, even if you build on an Ubuntu system | 20:22 |
| Pharaoh_Atem | that's a much cleaner way to solve the problem | 20:22 |
| ogra_ | but that snp that someone built on an outdated debian system that missed all security updates now will always use the outdated libssl | 20:23 |
| Pharaoh_Atem | and that's important | 20:23 |
| ogra_ | even if i re-build it on ubuntu | 20:23 |
| Pharaoh_Atem | otherwise snaps are not reproducible | 20:23 |
| Pharaoh_Atem | it would be utterly stupid if you can't make reproducible snaps | 20:23 |
| ogra_ | well, but then i cant just re-build it with a known safe system | 20:24 |
| Pharaoh_Atem | so you're saying the snap author is incapable of being smart about this? | 20:24 |
| Pharaoh_Atem | also, very rarely is the host environment a known safe system | 20:24 |
| ogra_ | the snap author is preferably an upstreaam who has no clue about packaging | 20:25 |
| ogra_ | nah, your cleanbuild env is ... | 20:25 |
| ogra_ | since it runs in a freshly pulled up container | 20:25 |
| ogra_ | snapcraft is a massive chance to get rid of app package management in distros ... | 20:26 |
| ogra_ | so that a distro developer team can concentrate on the core and save manpower | 20:26 |
| ogra_ | and that an upstream just has the most easy way to package his app without having to know distro internals | 20:27 |
| ogra_ | (beyond package dependency names indeed) | 20:27 |
| ogra_ | at least thats my vision | 20:27 |
| e^1 | ogra_: we can also install snappy on x86 and x64 systems right ? | 20:32 |
| ogra_ | sure | 20:32 |
| Pharaoh_Atem | ogra_: as much as you want to think about it, it'll never happy | 20:39 |
| Pharaoh_Atem | *happen | 20:39 |
| Pharaoh_Atem | and it's arguable that it would be a good thing if it did | 20:39 |
| ogra_ | well, after ~15years in the linux business my biggest dream is that distros go away ... and drag all their political issues with tghem ;D and we can just all work together all the time | 20:40 |
| Pharaoh_Atem | there have been many, many, many attempts | 20:40 |
| ogra_ | all of them failed ... but thats human nature i guess | 20:41 |
| Pharaoh_Atem | hell, nearly a decade ago, Jeff Johnson actually suggested implementing deb management in rpm | 20:41 |
| Pharaoh_Atem | when he forked rpm to create his rpm5, he actually did it | 20:41 |
| ogra_ | lol, i remember | 20:41 |
| Pharaoh_Atem | there's literally no reason why we can't implement deb format in rpm.org and actually unify on a common package manager implementation for different formats | 20:42 |
| Pharaoh_Atem | the fact that we don't is only because we can't get people to agree it's a good idea | 20:42 |
| Pharaoh_Atem | as others have said, what makes up Debian, Fedora, Ubuntu, or whatnot isn't necessarily the tools, it's the policy and the people | 20:43 |
| Pharaoh_Atem | there's literally no reason that we couldn't get everyone to use rpm (as LSB proposed a decade ago) and just implement the database/package support layer on top of it for the distros | 20:43 |
| Pharaoh_Atem | and a translation mechanism to get everything working | 20:44 |
| Pharaoh_Atem | ogra_: I held out hope for many, many years for that to happen | 20:49 |
| Pharaoh_Atem | things like niemeyer's smartpm gave me hope it would happen, but it never did :( | 20:49 |
| ogra_ | yeah | 20:52 |
| Pharaoh_Atem | if someone ever became interested in the idea again, I would definitely help out | 20:52 |
| Pharaoh_Atem | but it seems like the walls have gotten higher over the years :( | 20:53 |
| Pharaoh_Atem | it's been a hard battle to get Fedora and Mageia more in sync over the course of this last year | 20:53 |
| Pharaoh_Atem | but we're getting there | 20:53 |
| Pharaoh_Atem | and the two distros are fairly independent | 20:55 |
| Pharaoh_Atem | the biggest irony about smartpm is that it only started becoming popular after niemeyer abandoned it | 20:55 |
| Pharaoh_Atem | it's now used in yocto and is a rather popular alternative in pclos and several other distros | 20:55 |
| ogra_ | well, i effectively think debs and rpms are an anacronism, we still need them on a system level, but in the end, if you look at the world, there are more apk's installed than there are installed debs and rpms together so flatpack and/or snap are rather the future for apps imho | 20:57 |
| * genii sips his coffee and ponders Click N Run | 20:58 | |
| ogra_ | and the even more fun about snap and flatpak is that this battle is completely not fought/fightable by the distros .... in the end the format that upstreas pick is winning ... no matter what you or me want in $favourite_distro | 21:01 |
| ogra_ | *upstreams | 21:01 |
| Son_Goku | ogra_, perhaps, but I think there's a place for package managers | 21:31 |
| Son_Goku | we keep seeing them reinvented over and over again, often poorly | 21:31 |
| ogra_ | yes, in the distro | 21:31 |
| ogra_ | distros wont go away | 21:31 |
| ogra_ | but they should shrink a lot | 21:31 |
| Son_Goku | that indicates that no matter how much people think we can get away from it, we're still going to need them | 21:31 |
| ogra_ | sure | 21:32 |
| Son_Goku | arguably, they'll probably grow in usage rather than shrink | 21:32 |
| ogra_ | but a distro can become a way better maintained core of packages | 21:32 |
| Son_Goku | and things like flatpaks/snaps/etc. will choose to use these as units to compose a software bundle | 21:32 |
| ogra_ | you need whatever your install needs, buuld deps, toolchains and such ... but thats it | 21:32 |
| sergiusens | stgraber when you have time, can you pass me your snapcraft.yaml | 21:33 |
| stgraber | sergiusens: http://paste.ubuntu.com/20924678/ | 21:46 |
| stgraber | sergiusens: still very much work in progress but it does at least get to the go part and fails | 21:47 |
| stgraber | sergiusens: I'm trying with go-importpath now since that's probably the right way to get around my current error | 21:58 |
| mup | PR snapcraft#684 closed: Run tests from /tmp <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/684> | 22:00 |
| mup | PR snapcraft#685 opened: Release changelog for 2.13.2 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/685> | 22:00 |
| stgraber | sergiusens: current is http://paste.ubuntu.com/20926345/ | 22:01 |
| stgraber | sergiusens: the problem I have now is that I need to set a bunch of env variables for golang to be happy, is there some key I can set in snapcraft.yaml to do that? | 22:01 |
| stgraber | sergiusens: looking at our snappy 15 snap, I need to be able to set PKG_CONFIG_PATH, CGO_CFLAGS and CGO_LDFLAGS so I can have them point to where the lxc bits are | 22:02 |
| stgraber | sergiusens: (and have those 3 env variables only be set while building the lxd part, not the lxc or lxcfs ones, so can't seem that globally in my env before calling snapcraft) | 22:03 |
| sergiusens | stgraber not yet, you probably want to wait for the `build-environment` keyword for this, should be available next week | 22:03 |
| sergiusens | stgraber ah, that makes things interesting; we should get together tomorrow | 22:04 |
| sergiusens | I am too tired right now to think straight | 22:04 |
| stgraber | sergiusens: do you have a branch for that already? Mark kinda said this morning that he'd like to see some progress on the lxd snap this week and that's kinda a blocker (I expected to run into problems with the security policy stuff, not with snapcraft) :) | 22:04 |
| stgraber | sergiusens: I'm not going to be building stuff on Launchpad for probably a few more weeks and I'm running snapcraft in a container, so I can certainly run experimental code in there without any problem :) | 22:05 |
| stgraber | sergiusens: anyway, we can chat tomorrow, I should get some sleep too | 22:05 |
| sergiusens | stgraber I can crank up a branch | 22:05 |
| stgraber | that'd be very helpful | 22:06 |
| invapid | if you have a dependency that also needs to be installed from github | 23:01 |
| invapid | is that easy to do? | 23:01 |
| invapid | would that be under "parts" | 23:02 |
| invapid | yes - got that squared away | 23:06 |
| invapid | is there a way to select a specific commit hash or tag? | 23:08 |
| invapid | "source-tag" kinda | 23:27 |
| mup | Bug #1605080 opened: package snap (not installed) failed to install/upgrade: trying to overwrite '/usr/share/man/man1/snap.1.gz', which is also in package snapd 2.0.10 <amd64> <apport-package> <package-conflict> <xenial> <One Hundred Papercuts:Confirmed> <Snappy:Confirmed> <snap (Ubuntu):Invalid> | 23:48 |
| mup | <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1605080> | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!