| josharenson | If you have a snap installed from the stable channel, is there an easy way to get a newer channel without uninstalling/reinstalling? | 00:47 |
|---|---|---|
| nacc | josharenson: snap refresh foo --<channel> | 00:48 |
| nacc | josharenson: i think? | 00:48 |
| nacc | josharenson: i mean, that will change what is installed, of course, not sure how you expect to avoid that? | 00:49 |
| josharenson | nacc: its downloading... thanks | 00:49 |
| nacc | josharenson: unless you just meant the two steps :) | 00:49 |
| josharenson | nacc: yeah this is what I was looking for | 00:49 |
| nacc | josharenson: great! | 00:51 |
| === JanC_ is now known as JanC | ||
| sergiusens | jdstrand are you using master? | 01:32 |
| mup | PR snapcraft#895 closed: Release changelog for 2.22 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/895> | 02:16 |
| === chihchun_afk is now known as chihchun | ||
| foxmask | bonjello | 08:00 |
| dholbach | hey hey | 08:11 |
| didrocks | good morning dholbach! | 08:25 |
| abeato | $ sudo snap connect modem-manager:mmcli modem-manager:service | 08:41 |
| abeato | error: cannot perform the following tasks: | 08:41 |
| abeato | - Connect modem-manager:mmcli to modem-manager:service (connection denied by slot rule of interface "modem-manager") | 08:41 |
| abeato | morphis_, zyga any idea on why this might be happening? ^^ | 08:42 |
| morphis_ | abeato: did you sideload a modem-manager snap? | 08:42 |
| abeato | moyes | 08:42 |
| abeato | morphis_, yes | 08:43 |
| morphis_ | then I guess the base_declaration.go denies slot connection for unasserted snaps :-) | 08:43 |
| morphis_ | which doesn't sound right to me | 08:43 |
| abeato | hmpf | 08:43 |
| morphis_ | abeato: need to check with jdstrand what the rational behind this is | 08:44 |
| abeato | morphis_, agreed, will try to reach him later | 08:44 |
| morphis_ | thanks | 08:44 |
| dholbach | salut didrocks | 08:46 |
| tsdgeos | is there a way to tell snapcraft "reload the .deb files that may be old since the last run"? | 08:48 |
| tsdgeos | or do i need to clean and run it again? | 08:49 |
| didrocks | tsdgeos: you can clean a part if needed | 08:52 |
| didrocks | to not clea all parts of your builds | 08:53 |
| tsdgeos | that doesn't help much | 08:56 |
| tsdgeos | since all the debs are in the same part | 08:56 |
| tsdgeos | given the big amount of debs in the unity8 snap | 08:56 |
| didrocks | tsdgeos: not other way AFAIK than redownloading all of them | 08:56 |
| tsdgeos | would be good not having to refetch several MB of data just because 1 .deb changed | 08:57 |
| didrocks | please open a bug for this | 08:57 |
| tsdgeos | otoh not sure if we can actaully know only 1 deb changed | 08:57 |
| tsdgeos | i guess we can (since apt-get update knows) | 08:57 |
| didrocks | could, from the checksum | 08:57 |
| didrocks | or if we don't want to compute them, opening the ar, there is a checksum inside | 08:57 |
| didrocks | tsdgeos: please refer here the opened bug | 08:58 |
| tsdgeos | sure | 08:58 |
| tsdgeos | didrocks: https://bugs.launchpad.net/snapcraft/+bug/1640721 | 09:07 |
| mup | Bug #1640721: Feature Request: Would be nice to have a way to refresh .deb files <Snapcraft:New> <https://launchpad.net/bugs/1640721> | 09:07 |
| tsdgeos | not sure i worded it correctly | 09:07 |
| didrocks | tsdgeos: just added a small precision, but yeah, looks good! | 09:17 |
| ppisati | ogra_: i suspect you have a white list of modules that end up in the pc-kernel snap | 10:16 |
| === LarreaMikel1 is now known as LarreaMikel | ||
| ppisati | ogra_: e.g. initramfs-tools-ubuntu-core | 10:17 |
| ppisati | ogra_: that's where you select which kernel modules endup in the pc-kernel snap initrd | 10:17 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| didrocks | Mirv: I'm unsure to understand your PR | 11:02 |
| didrocks | Mirv: I guess you didn't push the second commit with the override, correct? | 11:02 |
| Mirv | didrocks: sorry, I was just thinking I might have explained it better. so the platform qt5 sets QTCOMPOSE, but if the "general" QTCOMPOSE is set after that block the platform qt5 setting is never taking effect | 11:02 |
| didrocks | oh, you already overrde it | 11:03 |
| didrocks | let me check :) | 11:03 |
| Mirv | yes, but currently the override is before it's generally set, so the override never works | 11:03 |
| didrocks | ah indeed :) | 11:03 |
| didrocks | what is QTCOMPOSE for btw? | 11:04 |
| didrocks | looking for locales? but the name doesn't help… | 11:04 |
| didrocks | (I guess it's for input keyboards…) | 11:04 |
| didrocks | (merged) | 11:04 |
| Mirv | yeah the location of compose.dir | 11:07 |
| didrocks | good, thanks! | 11:09 |
| ogra_ | ppisati, yup | 11:18 |
| ogra_ | ppisati, that is what we use today, correct ... i need a way to have a modules file per arch though, i dont want all the VM drivers in arm kernels for example | 11:19 |
| === ant_ is now known as Guest44024 | ||
| === hikiko is now known as hikiko|ln | ||
| tsdgeos | what was the command to get a shell inside the snap ? | 12:34 |
| ogra_ | snap run --shell $yourcommand | 12:34 |
| tsdgeos | tx | 12:36 |
| === hikiko|ln is now known as hikiko | ||
| Elleo | jdstrand: ping? | 13:02 |
| renato__ | Mirv, hey, just tested the platform plugin from here: https://code.launchpad.net/~timo-jyrinki/+snap/ubuntu-app-platform/, but the app still not starting on unity8 | 13:04 |
| renato__ | Mirv, if I add the "mir-graphics-drivers-desktop" it works. Probably some files still missing | 13:04 |
| Mirv | renato__: or environment variable ;) | 13:06 |
| Mirv | renato__: weird though, since you only added that same package that's being staged | 13:07 |
| renato__ | Mirv, no, I am not using any wrapper | 13:07 |
| renato__ | Mirv, could be some dir that you are not exporting? | 13:07 |
| Mirv | renato__: yeah I just started looking at that actually, the same thing occurred to me | 13:07 |
| renato__ | Mirv, nice, let me know if you fix it. | 13:08 |
| popey | jdstrand: http://people.canonical.com/~alan/wine/32bitbuild/wine_1.6-git_amd64.snap - 32 bit build for you | 13:09 |
| Mirv | renato__: not finding anything not exported in the new packages which were libmirplatform13 mir-client-platform-mesa5 mir-platform-graphics-mesa-x10 mir-platform-graphics-mesa-kms10 mir-graphics-drivers-desktop | 13:19 |
| Mirv | renato__: so it might be something that was already installed by previous staged packages, but not exported, which was not needed until now... or something completely different | 13:19 |
| davmor2 | pitti, mwhudson: In console conf, if you have ethernet and wifi you see options to configure the wifi but also on the main page there is what looks to be some global set ipv4/ipv6. Are they actually global or are they only controlling ethernet? | 13:20 |
| renato__ | Mirv, cLet me try to make a list of all files intalled with my package | 13:21 |
| Mirv | renato__: I'll make list of files that are staged by the platform snap but not exported | 13:27 |
| renato__ | Mirv, i will do a diff btw the version with ""mir-graphics-drivers-desktop"" and without it | 13:28 |
| Mirv | doh, what's up with pastebin.ubuntu.com | 13:30 |
| Mirv | renato__: ok here goes, I don't find anything suspicious "mir" http://pastebin.com/vfi0vPGf | 13:31 |
| Mirv | also directly rm -rf :d usr/share/doc and usr/share/man from the list, in addition to move /lib, /lib64 and /usr/include to that canbeprobablysafelyignored | 13:32 |
| Mirv | renato__: logically thinking if mir-graphics-driver-desktop was the only thing you have in staged-packages now, and I added it in platform snap, and it works with your included-in-app but not with included-in-platform, the missing file(s) should be in that pastebin.com output, am I thinking correctly? | 13:35 |
| Mirv | there's surely bunch of /usr/bin that's not being exported, but nothing obvious | 13:35 |
| renato__ | Mirv, I am getting the diff now | 13:36 |
| renato__ | Mirv, page 2: https://docs.google.com/spreadsheets/d/1IKlbILX1S-k2w2Pba5-ZlBoYsBVcOIglmAEUjv8uOcY/edit#gid=144700900 | 13:40 |
| renato__ | Mirv, is "$plataform/usr/lib/x86_64-linux-gnu/mir/" part of LD_LIBRARY_PATH? | 13:43 |
| renato__ | Mirv, and usr/lib/x86_64-linux-gnu/mir/client-platform | 13:43 |
| Mirv | renato__: yeah, so missing env var indeed (you said "no, I am not using any wrapper" so I wasn't sure if you meant it can't be any env var), that's probably it. adding. | 13:49 |
| renato__ | Mirv, did you confirm that? Is the missing var? | 13:49 |
| Mirv | renato__: well it's not set, I'm not sure if it's something that helps | 13:49 |
| jdstrand | sergiusens: re master> no. I was using 2.21 with https://github.com/snapcore/snapcraft/pull/876/files | 13:50 |
| mup | PR snapcraft#876: repo: allow for architecture-specific stage-packages <Created by stgraber> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/876> | 13:50 |
| jdstrand | popey: thanks! | 13:50 |
| Mirv | renato__: you could try it in your local snapcraft-desktop-helpers first of course | 13:50 |
| jdstrand | Elleo: hey | 13:50 |
| renato__ | Mirv, ok let me try first I am not sure if it is necessary | 13:50 |
| renato__ | Mirv, are you able to check if that is exported for QT5 or gtk launcher? | 13:51 |
| Mirv | renato__: it's not, but I'm wondering if Mir could confused that it's not under the standard path /usr/lib/.../mir but /ubuntu-app-platform/usr/lib/.../mir | 13:52 |
| Mirv | renato__: oh, actually now I found it! | 13:52 |
| Mirv | renato__: export MIR_CLIENT_PLATFORM_PATH=$SNAP/usr/lib/$ARCH/mir/client-platform in desktop-exports, not launcher-specific | 13:52 |
| Mirv | so we need to override that common env | 13:53 |
| renato__ | Mirv, let me try | 13:53 |
| Mirv | renato__: http://pastebin.com/mZNLx7j8 - the diff | 13:53 |
| jdstrand | popey: fyi: | 13:53 |
| jdstrand | $ /snap/bin/wine notepad.exe | 13:53 |
| jdstrand | /snap/wine/x1/wine: 15: /snap/wine/x1/wine: /snap/wine/x1/bin/wine64: not found | 13:53 |
| Mirv | renato__: if you're on up-to-date snapcraft-desktop-helpers locally | 13:53 |
| Elleo | jdstrand: heya, got a couple of questions about app armor rules for snaps; is there any equivalent of @{APP_PKGNAME}? At the moment I'm faking it with "snap.@{SNAP_NAME}.@{SNAP_NAME}", but I'm not sure if that covers all cases correctly? and what about @{APP_ID_DBUS}? I saw in the old click stuff it uses libnih-dbus to get a dbus friendly name, but I couldn't find anything similar in snapd? | 13:57 |
| Elleo | jdstrand: I had wondered whether I should write a bit of go code in my interface to make a dbus friendly ID instead? | 13:58 |
| Elleo | jdstrand: like some of the ###TEMPLATE### style replace stuff done in other interfaces | 13:58 |
| popey | jdstrand: balls | 13:59 |
| popey | jdstrand: ok, will rebuild and actually test it this time | 13:59 |
| popey | sorry | 13:59 |
| jdstrand | Elleo: all of the variables are in interfaces/apparmor/template_vars.go | 14:01 |
| jdstrand | Elleo: snap.@{SNAP_NAME}.@{SNAP_NAME} is only going to sometimes be correct | 14:02 |
| renato__ | Mirv, did not solve the problem, let me try more Vars | 14:03 |
| Elleo | jdstrand: okay, neither of those are in template_vars.go, so what would be the correct way of forming an equivelant of APP_PKGNAME and should I rewrite it to be dbus friendly in my interface or add something to snapd to make it available for all snaps? | 14:04 |
| jdstrand | Elleo: but snippets has different ways of creating the label. eg, plugAppLabelExpr(plug) and slotAppLabelExpr(slot) | 14:04 |
| jdstrand | Elleo: see for example udisks2.go and how it expands ###PLUG_SECURITY_TAGS### | 14:05 |
| jdstrand | popey: np. I'm not blocked on it atm since I have a simpler reproducer, but would like to test with wine before claiming to have fixed it | 14:07 |
| jdstrand | popey: and yes, I think I will be able to make this work | 14:07 |
| Elleo | jdstrand: ah, okay, looks like I can use that for the replacement of APP_PKGNAME and then I guess just write some go code to do what libnih-dbus does to make it dbus friendly for APP_ID_DBUS then? | 14:08 |
| popey | jdstrand: that's awesome news, thanks. | 14:08 |
| jdstrand | Elleo: there is already go code for that | 14:08 |
| Elleo | jdstrand: oh? | 14:08 |
| jdstrand | Elleo: that is what plugAppLabelExpr and slotAppLabelExpr do | 14:08 |
| jdstrand | Elleo: they expand out the plugged commands into what you need. just copy the udisks2.go methodology and you'll get what you need | 14:09 |
| Elleo | jdstrand: okay, thanks :) | 14:10 |
| jdstrand | Elleo: (notice that ###PLUG_SECURITY_TAGS### in udisks2ConnectedSlotAppArmor expands to dbus labels) | 14:10 |
| jdstrand | Elleo: it works pretty neat because it will expand to snap.<snap>.* if using a toplevel plugs, snap.<snap>.<command> if only one command is connected or 'snap.<snap>.<command1>,snap.<snap>.<command2>,snap.<snap>.<commandN>' if multiple commands are connected | 14:12 |
| jdstrand | Elleo: so all you need to worry about is peer=(label=###PLUG_SECURITY_TAGS###) | 14:13 |
| Elleo | jdstrand: okay, separate but related questions; where should I be allowing download manager and the apps to write data? currently it's: @{HOME}/.local/share/ubuntu-download-manager/@{APP_PKGNAME}/ (which is where the non-dbus version of PKGNAME was being used), should we be shifting that somewhere else for snaps? and should it be on a per snap basis or a per command basis (I'd guess per snap so all commands within a snap can access downloads from other | 14:14 |
| jdstrand | Elleo: (note, you use ###PLUG_SECURITY_TAGS### on the slot side policy and ###SLOT_SECURITY_TAGS### on the plug side policy (they are opposite since you are specifying the peer) | 14:14 |
| jdstrand | Elleo: per snap. a tenant of snappy is that all commands can access each other's data | 14:15 |
| jdstrand | Elleo: @{HOME}/.local/share/ubuntu-download-manager/ is trickier cause there are a couple of things to keep in mind | 14:16 |
| renato__ | Mirv, I can not find the problem :(. Do you know some Mir guy that could help us? | 14:18 |
| jdstrand | Elleo: the @{HOME} apparmor variable (be default) expands to '/root/' and /home/*/'. the $HOME *environment* variable is set to $HOME/snap/$SNAP_NAME/$SNAP_REVISION | 14:18 |
| renato__ | Mirv, at least get more info about the problem | 14:18 |
| jdstrand | s/be default/by default/ | 14:18 |
| jdstrand | Elleo: and the template policy allows writes to @{HOME}snap/$SNAP_NAME/$SNAP_REVISION/** | 14:19 |
| Mirv | renato__: I think they are all more in your time zone, maybe ask Kevin to give a person to give ideas. | 14:19 |
| Mirv | renato__: I can't also find any further variables to set at this point that could have an effect | 14:19 |
| jdstrand | Elleo: so from a snap's perspective, you don't have to do anything if udm puts stuff in $HOME/snap/$SNAP_NAME/$SNAP_REVISION/.local/share/ubuntu-download-manager/ | 14:19 |
| renato__ | Mirv, do you have a small app that they could easily test? | 14:20 |
| jdstrand | Elleo: (note there is also $SNAP_USER_COMMON env variable, which is set to $HOME/snap/$SNAP_NAME/common | 14:21 |
| jdstrand | ) | 14:21 |
| Elleo | jdstrand: is there a way in which the UDM service can find out the SNAP_REVISION of what it's talking to? or can I have it write to $HOME/snap/$SNAP_NAME/$SNAP_REVISION/current/<blah>? | 14:21 |
| Elleo | jdstrand: ah, thought there was a current symlink there, but seems thats only for snap packages in /snap/ not user directories | 14:22 |
| jdstrand | Elleo: so you have a choice-- you can adjust udm to figure out where to put the downloads or you can store them where you do now and make your clients figure out where it is (which is tricky cause they don't know the user's home) | 14:22 |
| renato__ | Mirv, this is printing on unity8 log while trying to run the app: http://paste.ubuntu.com/23456384/ | 14:22 |
| renato__ | Mirv, check if you see anything that could cause the problem | 14:22 |
| jdstrand | Elleo: SNAP_USER_DATA doesn't have the current symlink | 14:23 |
| jdstrand | Elleo: but this is data that really isn't revision specific, I suspect SNAP_USER_COMMON is a better fit (and easier to implement for you) | 14:23 |
| Elleo | jdstrand: udm sends the path to the client as part of the finished signal, can that be used unmodified if the interface provides access to the current location? then the apps don't need to do any work to find it | 14:23 |
| jdstrand | Elleo: yes, that is possible from a policy perspective. it is a bit weird with the way snap data dirs are setup though. to me SNAP_USER_COMMON seems the way to go unless there is a compelling reason not to (this will come up in the PR review as well) | 14:25 |
| Elleo | jdstrand: for udm to work in a snap it'll need write access to all other snap's common areas though; with the current mechanism it just has access to $HOME/.local/share/ubuntu-download-manager/** and apps get .local/share/ubuntu-download-manager/snap.@{SNAP_NAME}/ or similar | 14:26 |
| Elleo | jdstrand: which would seem to keep things much more isolated | 14:26 |
| jdstrand | Elleo: click had a different way of doing things-- it had data sprinkled throughout the HOME dir by having data in xdg data dirs. snappy consolidates when application data is and sets HOME for the snap so it can put it wherever. ngoi | 14:27 |
| Elleo | jdstrand: is there a way I can find out SNAP_USER_COMMON's value for a snap I'm communicating with over dbus? | 14:28 |
| jdstrand | Elleo: udm is a trusted slot though-- its the connecting snaps that are untrusted. you can still limit it to: '@{HOME}/snap/*/common/.local/share/ubuntu-download-manager/** rwk,' | 14:28 |
| jdstrand | (or something-- point is, limited within the snap's dir) | 14:29 |
| Elleo | jdstrand: okay, when udm decides where to write if I can't get the actual SNAP_USER_COMMON can I assume that @{HOME}/snap/@{SNAP_NAME}/common/... will be correct? | 14:30 |
| jdstrand | Elleo: you can use libapparmor to figure out the connecting process' security label and then derive the $SNAP_NAME from that | 14:30 |
| Elleo | jdstrand: okay, so SNAP_USER_COMMON will always be of that form then? | 14:30 |
| jdstrand | Elleo: you can assume @{HOME}/snap/@{SNAP_NAME}/common/ is correct for series 16, yes. I doubt it will change for series 18, but it is conceivable | 14:31 |
| jdstrand | Elleo: yes | 14:31 |
| Elleo | jdstrand: okay, cool; thanks :) | 14:31 |
| Elleo | jdstrand: will see about making those changes now, I expect I'll be back with more questions soon :P | 14:31 |
| jdstrand | ok | 14:31 |
| Mirv | renato__: please try / give them https://code.launchpad.net/~timo-jyrinki/+snap/uitk-gallery/+build/9673/+files/uitk-gallery_0.1_amd64.snap - anyway, I'm EOD now but just managed to create that snap | 14:39 |
| Mirv | not tested under U8, starts under U7 | 14:40 |
| renato__ | Mirv, yes my app starts on u7 too | 14:40 |
| renato__ | Mirv, the problem is only on unit8 | 14:40 |
| Mirv | renato__: yeah, I just mean that there's nothing fundamentally wrong with that snap (that I just created on LP for the first time), so it should be good for testing | 14:43 |
| Mirv | uses the platform snap | 14:43 |
| mup | PR snapcraft#896 opened: indicators: work with Content-Encoding set <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/896> | 14:44 |
| === JanC is now known as Guest87424 | ||
| === JanC_ is now known as JanC | ||
| renato__ | Mirv, did you push the changes on the launcher? With the MIR client evn var? | 14:59 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapcraft#897 opened: Don't organize in the install dir <Created by josepht> <https://github.com/snapcore/snapcraft/pull/897> | 15:20 |
| mup | PR snapcraft#856 closed: Call organize() after building <Created by josepht> <Closed by josepht> <https://github.com/snapcore/snapcraft/pull/856> | 15:23 |
| kalikiana_ | jdstrand: Would you have another look at https://github.com/snapcore/snapd/pull/2225 ? | 15:35 |
| mup | PR snapd#2225: Implement lxd-client interface exposing the lxd snap <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2225> | 15:35 |
| === zsombi_ is now known as zsombi | ||
| jdstrand | kalikiana_: yes | 15:44 |
| kalikiana_ | Thanks | 15:52 |
| lewciie | hi there! trying to register a snap and getting registration failed but no reason is given | 15:54 |
| didrocks | hey lewciie! What's your specific error message output? | 15:55 |
| lewciie | 'Registration failed.' | 15:55 |
| didrocks | hum, nothing more with --debug? | 15:56 |
| lewciie | let me check | 15:56 |
| didrocks | (just if it gets you more info by any chance) | 15:56 |
| didrocks | also, have you tried with a different name? (the one you are using may be taken?) | 15:57 |
| didrocks | lewciie: just pastebin the output please | 15:57 |
| lewciie | I tried 3 different names, including my full name, lastname, and 'gangsta', none of them worked | 15:57 |
| lewciie | http://pastebin.ubuntu.com/23456703/ | 15:57 |
| didrocks | yeah, no real clue there. "snapcraft login" worked, right? | 15:58 |
| lewciie | yes, log in was successful | 15:58 |
| didrocks | do you mind running snapcraft logout and snapcraft login again? | 15:58 |
| lewciie | sure | 15:58 |
| didrocks | (maybe pastebin the result of login as well) | 15:59 |
| sergiusens | lewciie mind getting this branch https://github.com/snapcore/snapcraft/pull/866 run from source (./bin/snapcraft register) and while you are at it comment on the PR? | 15:59 |
| mup | PR snapcraft#866: Login with option to agree to terms of service and human friendly errors <Created by psivaa> <https://github.com/snapcore/snapcraft/pull/866> | 15:59 |
| sergiusens | didrocks ^ | 15:59 |
| sergiusens | it is most likely developer namespace or ToS signing missing | 16:00 |
| sergiusens | using that branch should give you the correct hint | 16:00 |
| didrocks | ah, graceful store message finally :) | 16:00 |
| didrocks | that wil help, indeed | 16:00 |
| didrocks | lewciie: mind trying what sergiusens did? (do oyu know how to run from a git branch?) | 16:01 |
| lewciie | let me check :) | 16:01 |
| didrocks | sergiusens: we don't have snapcraft CLI for ToS signing or such, correct? | 16:01 |
| sergiusens | didrocks nope, link to webpage is returned | 16:02 |
| didrocks | sergiusens: it's a start at least :) | 16:02 |
| sergiusens | didrocks ToS will always be a webpage though | 16:02 |
| didrocks | ah, you can't grab it, have people type "I accept" or so? | 16:02 |
| cjwatson | There's an upcoming project to improve terms handling | 16:02 |
| lewciie | alright I need further support | 16:02 |
| cjwatson | (store-side) | 16:03 |
| kgunn | ogra_: have you noticed on dragon board... it's like the terminal just goes for a walk sometimes.... | 16:08 |
| ogra_ | for a walk ? | 16:09 |
| kgunn | ogra_: like keyboard input into my ssh console just doesn't respond for many seconds | 16:10 |
| ogra_ | hmm, no, i dont have that | 16:12 |
| ogra_ | checked dmesg for possible wlan errors ? | 16:12 |
| kgunn | nothing there | 16:14 |
| kgunn | just regular init stuff for wlan | 16:14 |
| lewciie | sergiusens: not sure how to run that branch, can get help? :D | 16:15 |
| ogra_ | well, thats the only thing i could imagine | 16:15 |
| kgunn | ogra_: are you on dragonboard much? | 16:16 |
| kgunn | just curious | 16:16 |
| kgunn | wonder who's using it with ubuntu-core besides me | 16:16 |
| ogra_ | not really, but i tend to log in a few times a day and have constantly a ssh windo with htop running on it | 16:16 |
| ogra_ | but nothing where i would actually notice such delays | 16:16 |
| lewciie | hello? can anyone help? :D | 16:27 |
| lewciie | please? | 16:28 |
| lewciie | :) | 16:28 |
| ogra_ | !ask | lewciie | 16:28 |
| ubottu | lewciie: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience | 16:28 |
| ogra_ | :) | 16:28 |
| lewciie | ahhaa | 16:28 |
| lewciie | I asked the questions long ago but thanks, I'm not familiarised with this, will follow the rules | 16:28 |
| ogra_ | (all i see above is "i need further support" ... but no question after that) | 16:29 |
| didrocks | ogra_: I guess there a ping on how to run that branch | 16:29 |
| didrocks | ok, so lewciie, let's try | 16:29 |
| lewciie | you're right, I was in private chat, I'm just impatient, apologies, dont want to spam anyone with this! | 16:29 |
| didrocks | you need to git clone https://github.com/psivaa/snapcraft.git | 16:30 |
| ogra_ | lewciie, better spam ... the channel is logged and google will find the discussion when someone looks for the same issue in a year ;) | 16:30 |
| didrocks | then, cd snapcraft | 16:30 |
| lewciie | ogra_: thank :) | 16:30 |
| lewciie | didrocks: let me do it | 16:30 |
| didrocks | git checkout bug/1619193 | 16:30 |
| mup | Bug #1619193: Registering a snap without agreeing to terms and conditions fails opaquely <store> <Snapcraft:In Progress by psivaa> <Software Center Agent:Fix Released by fgallina> <https://launchpad.net/bugs/1619193> | 16:31 |
| didrocks | and replace your snapcraft command with bin/snapcraft (retry doing the registration without --debug) | 16:31 |
| lewciie | thanks didrocks! | 16:39 |
| lewciie | it worked :) | 16:41 |
| didrocks | lewciie: did it? | 16:41 |
| didrocks | you didn't get an error detail? | 16:41 |
| lewciie | no, not sure what happened... magic? | 16:41 |
| didrocks | (without loging out/in again?) | 16:41 |
| lewciie | I had done that bit already | 16:41 |
| didrocks | hum… sergiusens doesn't sound great, could that be another bug fixed in master? ^ | 16:41 |
| abeato | jdstrand, hey, thanks for the reviews, I've addressed all the issues | 16:55 |
| abeato | jdstrand, there is something that I need to solve though: connection of interfaces, like mmcli connected to modemanager daemon, shows an error | 16:56 |
| abeato | jdstrand, I changed basedeclaration to allow that, but probably the real solution is using snap-declaration. How can I do that? | 16:56 |
| jdstrand | abeato: let me look at what you changed in the base declaration | 16:57 |
| abeato | jdstrand, I had to remove "deny-connection: true" | 16:58 |
| jdstrand | abeato: yes, you need to revert that change to for it to be acceptable to commit | 16:58 |
| jdstrand | abeato: and then we would add a snap declaration | 16:58 |
| abeato | jdstrand, I suspected that, but how can I do that? | 16:58 |
| abeato | I want to connect mmcli to modemmanager daemon, which are in the same snap | 16:59 |
| jdstrand | abeato: so, this is a rough edge for slot implementation interface developers since the base declaration may prevent install or connection for snaps that don't have a store signed snap declaration | 16:59 |
| abeato | jdstrand, we need to be able to do this locally for testing | 16:59 |
| jdstrand | abeato: (this includes installing snaps with --dangerous) | 17:00 |
| jdstrand | abeato: I understand. today you simply fudge the base declaration like you did, then in the PR you revert that | 17:00 |
| abeato | jdstrand, alright, will do that for the PR | 17:01 |
| jdstrand | abeato: I brought this up with Gustavo. how to make this easier for developers needs to be discussed. maybe it will remain as fudging the base declaration but to document that | 17:01 |
| abeato | jdstrand, that should not be the only way imho, this can get very painful | 17:02 |
| jdstrand | abeato: so, today, modem-manager already has a snap declaration | 17:02 |
| jdstrand | abeato: but it isn't used with a locally installed snap where you use --dangerous | 17:02 |
| abeato | jdstrand, as you would need a hacked snapd for whatever small change you have to do to a snap | 17:02 |
| jdstrand | abeato: again, I understand, that is why I brought it up with Gustavo | 17:02 |
| abeato | jdstrand, noted, and thanks, just want to make sure you all know this is not a minor issue for snappers :) | 17:03 |
| jdstrand | abeato: it probably makes sense to file a bug against snappy | 17:08 |
| abeato | jdstrand, ack | 17:08 |
| jdstrand | abeato: simply mentioning that the security of the base declaration requiring a snap declaration from the store is a pain point for local testing before you are ready to upload even to edge | 17:09 |
| jdstrand | roadmr: https://myapps.developer.ubuntu.com/dev/click-apps/4874/rev/12/ is your test snap? | 17:10 |
| jdstrand | roadmr: I ask cause choosing lxd-support as your plugs for the snap declaration test makes me twitchy (that is a super-powerful interface) ;) | 17:13 |
| jdstrand | popey: you may want to subscribe to bug #1592022. I know what the fix is and am working on it | 17:15 |
| mup | Bug #1592022: 32 bit applications on 64 bit system fail due to seccomp <snapd-interface> <Snappy:In Progress by jdstrand> <https://launchpad.net/bugs/1592022> | 17:15 |
| roadmr | jdstrand: yes, it is. I'm happy to use another one (but it has to be one that would not normally pass automated review). Any suggestions? | 17:17 |
| popey | jdstrand: yay | 17:18 |
| roadmr | jdstrand: I'd prefer not deleting the package but I can if you feel it's safer. I updated the payloads to remove lxd-support, so at least the package will be uninstallable (as the just-updated snap-declaration doesn't allow it) | 17:19 |
| jdstrand | roadmr: well, it is the correct one for testing 'installation'. 'mir' slot implementation would be good for 'connection' | 17:19 |
| jdstrand | roadmr: no, it is fine. perhaps removing the snap declaration on prod after you are done would make sense (you could leave it in staging if snapd can point to staging) | 17:20 |
| ogra_ | cjwatson, hmm, shouldnt it be possible to pull stuff via wget from github during an LP snap build ? https://launchpadlibrarian.net/292935958/buildlog_snap_ubuntu_xenial_armhf_kodi-pi_BUILDING.txt.gz | 17:20 |
| roadmr | jdstrand: it can, yes (SNAPPY_USE_STAGING_STORE=1) | 17:21 |
| jdstrand | nice! :) | 17:21 |
| roadmr | jdstrand: ok, I'll be extra careful when using lxd-support for testing | 17:21 |
| abeato | jdstrand, https://bugs.launchpad.net/snappy/+bug/1640874 | 17:21 |
| mup | Bug #1640874: It is not possible to inter-connect locally installed snaps <Snappy:New> <https://launchpad.net/bugs/1640874> | 17:22 |
| jdstrand | roadmr: I mean, you're fine. it is just that there is a snap in the store that if modified could be bad. I just like to reduce those kind of things :) | 17:22 |
| mup | Bug #1640874 opened: It is not possible to inter-connect locally installed snaps <Snappy:New> <https://launchpad.net/bugs/1640874> | 17:22 |
| roadmr | jdstrand: I made it private, so at least only I can get it | 17:24 |
| cjwatson | ogra_: Currently only during the pull phase. This will change in a bit | 17:25 |
| ogra_ | ah, k | 17:25 |
| abeato | jdstrand, besides this issue, which is your opinion on whether the policy for plugs in classic should include just unconfined or unconfined+label? I answered your comment on the ofono PR, whatever you prefer should be the same for both mm and ofono interfaces I guess | 17:25 |
| cjwatson | ogra_: Still good practice to fetch remote stuff in the pull phase though, I'd say | 17:25 |
| jdstrand | abeato: thanks! I updated the description for some clarifying remarks and marked confirmed | 17:25 |
| jdstrand | roadmr: ah, even better. thanks! | 17:25 |
| abeato | awesome! | 17:25 |
| ogra_ | cjwatson, yeah, but then i cant get it to build | 17:25 |
| roadmr | jdstrand: np, and do let me know if you think I should delete it alright. It's a test package so it'd be no big deal | 17:26 |
| roadmr | s/alright/altogether/ | 17:26 |
| cjwatson | ogra_: https://code.launchpad.net/~cjwatson/launchpad-buildd/snap-proxy-allow-build/+merge/310050 anyway | 17:26 |
| jdstrand | abeato: it should be the same. I have a todo to look at that pr today and will comment there | 17:26 |
| ogra_ | cjwatson, ah, perfect ! | 17:27 |
| abeato | jdstrand, great, thanks | 17:27 |
| jdstrand | roadmr: if it is helpful to you, leaving it private seems fine | 17:27 |
| roadmr | it is, I use it to test c-r-t updates :) I'll leave it there for now. | 17:29 |
| mwhudson | davmor2: i don't understand, can you take screenshots (or photos, or something) and point out what you mean? | 18:29 |
| ogra_ | paintings ! | 18:30 |
| davmor2 | mwhudson: I filed a bug https://bugs.launchpad.net/bugs/1640843 | 18:33 |
| mup | Bug #1640843: Networking fails if you touch the default route <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1640843> | 18:33 |
| mwhudson | davmor2: are you testing stable? | 18:34 |
| davmor2 | mwhudson: yeap | 18:34 |
| mwhudson | davmor2: i think that's fixed in edge by hiding that bit of the ui | 18:34 |
| mwhudson | yeah | 18:34 |
| mwhudson | in fact pitti and i realized last night that that we didn't understand what that ui was trying to achieve at all... | 18:35 |
| davmor2 | mwhudson: okay I'll have a look at edge after then, we are just writing the manual steps for everything currently | 18:35 |
| mwhudson | davmor2: yeah, quite a bit has changed in edge, would definitely like your attention on that :) | 18:36 |
| davmor2 | mwhudson: yeah it threw me as well as it look like it was only specific to eth0 as it don't remember seeing it on wlan0 on db so was getting more and more confused with it | 18:36 |
| davmor2 | mwhudson: right I need to finish up the initial round of steps and then I can modify the cases as needs be. | 18:37 |
| === Azrael is now known as Guest56474 | ||
| Guest56474 | Hello, I was wondering if anyone would be able to help me. Running 16.04 64 bit, all up to date. Installed ubuntu-sdk and am running it as root. When I try to create a project (specifically creating a kit), I get the following error: error: Registering root is not possible. Any ideas would be greatly appreciated! | 19:06 |
| ogra_ | Guest56474, try the #ubuntu-app-devel channel instead ... | 19:07 |
| Guest56474 | Gah, apologies. Thank you! | 19:07 |
| * davmor2 shakes his fist at mwhudson this loops on hitting enter on the second page back to the start again :( | 19:45 | |
| davmor2 | mwhudson: you baypassed network config and user setup but hiding them all together ;) | 19:45 |
| mwhudson | davmor2: eh? | 19:48 |
| mwhudson | sounds like it might crashing, can you dig out the logs? | 19:48 |
| davmor2 | mwhudson: give me a minute | 19:49 |
| davmor2 | mwhudson: is it likely to be syslog or else where? | 19:54 |
| davmor2 | mwhudson: never mind found the subiquity log | 19:55 |
| dpb1 | hey, I was trying to use this gist to publish to edge from travis: https://gist.github.com/evandandrea/c754964bfdfb176844f26f605ebbb8db | 19:57 |
| dpb1 | it uses a docker image 'snapcore/snapcraft', and I got this error when running it: | 19:57 |
| dpb1 | Status: Downloaded newer image for snapcore/snapcraft:latest | 19:57 |
| dpb1 | Issues while validating snapcraft.yaml: Additional properties are not allowed ('grade' was unexpected) | 19:57 |
| dpb1 | is it out of date? | 19:57 |
| davmor2 | mwhudson: see pm, I'm about to knock off for the night so if there is anything else let me know in an email and I can get it to you tomorrow | 20:02 |
| sergiusens | dpb1 what does snapcraft --version give you? | 20:13 |
| sergiusens | dpb1 can you pull again? | 20:25 |
| dpb1 | sergiusens: awesome, that fixed it | 20:37 |
| dpb1 | tyvm | 20:38 |
| === ben_r_ is now known as ben_r | ||
| dpb1 | is there a way to search for snaps in the edge channel? | 21:28 |
| mup | Bug #1592022 changed: 32 bit applications on 64 bit system fail due to seccomp <snapd-interface> <Snappy Launcher:In Progress by jdstrand> <https://launchpad.net/bugs/1592022> | 21:51 |
| bschaefer | hmm not sure why i keep getting this on yakkety? Failed to fetch http://us.archive.ubuntu.com/ubuntu/pool/main/g/gcc-6/gcc-6-base_6.2.0-5ubuntu11_amd64.deb 404 Not Found [IP: 91.189.91.23 80] | 22:49 |
| bschaefer | checking... snapcraft is using the wrong version then the policy i have on the machine (not sure where its pulling the wrong path from) | 22:50 |
| bschaefer | is my policy: 6.2.0-5ubuntu12 500 | 22:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!