| qengho | chasinglogic: Enough of snappy was in 16.04 kernel and apparmor that it can run there. We're not backporting to something like the soon-to-expire-anyway 2015 releases. | 00:50 |
|---|---|---|
| chasinglogic | qengho: I didn't expect it to be backported, I was just looking for the newest version. But I also don't want to start playing with 15.04 if I can't upgrade it when 16.04 comes out | 00:51 |
| qengho | chasinglogic: Let's make sure we're talking about the same thing. Ubuntu 16.04 LTS was released in 2016-04. It had snappy functionality, but no official release of Snappy. I think(!) Ubuntu is releasing Snappy images for the first time, based off of Ubuntu 16.04 soon. | 00:56 |
| chasinglogic | I'm talking about Ubuntu Snappy Core the distribution | 00:56 |
| qengho | Okay. That doesn't exist yet. It's in progress. | 00:57 |
| chasinglogic | qengho: correct, that's the info that zyga gave me so I'm just waiting | 00:58 |
| chasinglogic | :D | 00:58 |
| qengho | chasinglogic: Though, installing "snapd" on a Ubuntu 16.04 gets you what it will look like, inside. You don't have to wait to get started. You have to wait to get an image to put on a embedded device. | 01:00 |
| qengho | ^embedded^small | 01:00 |
| chasinglogic | qengho: Yeah I've been playing with snaps and snapcraft on my desktop and laptop, I'm looking for something coreos-esque to make clusters out of. (and I'd like to convert my pi to snappy core) | 01:01 |
| qengho | Ah, right. Soon. | 01:01 |
| liuxg | elopio, ping | 01:41 |
| thomi | if a snapped command dumps it's core, any ideas where it ends up on disk? | 01:42 |
| liuxg | in the tutorial at http://snapcraft.io/create/, it teaches us to use "hello" to run the example, however, in the second example, it askes us to run it by using "hello-debug.hello" (package_name.<name under apps>. Previously, the second one was the way for ubuntu core. what is the correct way to run an app? | 01:50 |
| mup | PR snapcraft#639 opened: Use a snap that doesn't require a manual review for the upload test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/639> | 01:54 |
| elopio | liuxg: hello | 01:54 |
| liuxg | elopio, I found a very strange problem. at the link http://snapcraft.io/create/, for the first tutorial, I can run the app using "hello", however, I cannot run it using "hello.hello" | 01:55 |
| liuxg | elopio, if I change the package name to "hello1" like http://paste.ubuntu.com/18752046/, then I can run it using "hello1.hello". However, hello does not run any more. is this a bug? | 01:56 |
| elopio | liuxg: if your command has the same name as the snap, then the command will not have the . | 01:57 |
| elopio | in the tutorial example, the snap should be only hello. Not hello.hello. | 01:58 |
| elopio | in your case when you renamed the snap, then hello1.hello is the right name for the command. So unless I misunderstood your comments, thats by design. | 01:58 |
| liuxg | elopio, is this a special case? the package name and name under "apps" are the same. we cannot use "." to run it? | 01:59 |
| elopio | thomi: what do you mean with "dumps it's core"? | 01:59 |
| elopio | liuxg: yes. The no foo.foo, just foo. | 02:00 |
| liuxg | elopio, would you please point me to the design doc for it? thanks | 02:00 |
| liuxg | elopio, I want to have a better understanding about the design. As a tutorial, it is not inconsistent for the tutorials there, and it causes confusion to developers. | 02:01 |
| elopio | liuxg: no, sorry, that was too long ago. | 02:04 |
| elopio | I have no idea if there ever was a document. | 02:05 |
| liuxg | elopio, I think it is good to point out to developers. it is truly a little confusing. Anyway, I know it from you :) In fact, I tried to figure it out by playing it. | 02:06 |
| qengho | liuxg: When the app name is the same as the package name, only the package name is used to construct the executable name. When they're different, you prefix the app name with the package name and ".". | 02:08 |
| elopio | liuxg: oh, look, I found the PR: https://github.com/snapcore/snapd/pull/688 | 02:08 |
| mup | PR snapd#688: snappy: support generation of short binary names <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/688> | 02:08 |
| liuxg | qengho, thanks. I know it now | 02:08 |
| liuxg | elopio, thanks for the help. we just need to document it somewhere. | 02:10 |
| elopio | sure. File a bug please. | 02:10 |
| liuxg | elopio, which project should I file against? would you please give me a link for it? thanks | 02:14 |
| elopio | liuxg: the link is at the bottom of the snapcraft.io page. | 02:15 |
| liuxg | elopio, ok. I got it. thanks | 02:15 |
| thomi | elopio: as in after a segfault | 02:16 |
| thomi | elopio: but I think I figured it out anyway | 02:16 |
| liuxg | when i am trying to install a snap, the very first installation seems to have errors. However, the second installation is successful http://paste.ubuntu.com/18754704/, what is the reason for it? thanks | 02:37 |
| mup | Bug #1600083 opened: 'snap' tool bash completion does not complete local file names <Snappy:New> <https://launchpad.net/bugs/1600083> | 02:44 |
| mup | Bug #1600085 opened: interface for making bpf syscalls <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1600085> | 02:50 |
| mup | Bug #1566604 changed: the snap command has no autocompletion <Snappy:Fix Released> <https://launchpad.net/bugs/1566604> | 03:02 |
| mup | PR snapcraft#639 closed: Use a snap that doesn't require a manual review for the upload test <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/639> | 03:30 |
| liuxg | does anyone know how to stop a running snap service? | 03:44 |
| ljp | liuxg: sudo systemctl stop snapd.service snapd.socket | 03:50 |
| === ljp is now known as lpotter | ||
| stevebiscuit | arges: client.Find() *only* returns the snaps available on the store, I've had to merge the result from that and client.List() to simulate the *old* behaviour for snapweb: https://github.com/snapcore/snapweb/pull/31 . We could maybe introduce something similar to the client lib if there's demand for apps other than snapweb | 03:51 |
| mup | PR snapweb#31: Show installed snaps in store listing <Created by stevenwilkin> <https://github.com/snapcore/snapweb/pull/31> | 03:51 |
| liuxg | lpotter, thanks. I have a webserver service like "hello-world-service". it has the port number 8000. how to stop it? | 03:52 |
| liuxg | lpotter, on ubuntu core, it used to have "snap services status", and we can use "stop" or "start" command to manage it. | 03:54 |
| lpotter | might try something like systemctl stop snap.<snap_name>.<command>.service | 03:58 |
| 17SAAMNLJ | lpotter, thanks, it works. | 04:29 |
| === chihchun_afk is now known as chihchun | ||
| RyanTG | If I have vlc-2.2.2-5 via apt and vlc-daily via snap, why does the apt version take precedence when I go to launch it? | 05:13 |
| RyanTG | Is it a path ordering problem? | 05:30 |
| tsimonq2 | RyanTG: try uninstalling vlc from apt | 05:33 |
| qengho | RyanTG: Yeah, you have two programs with the same name. If you want one, use its full path. /snap/bin/vlcsomething or /usr/bin/vlcsomething | 05:45 |
| mup | PR snapd#1513 opened: tests: readd the fake store tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1513> | 06:02 |
| liuxg | when I am trying to build the example at https://github.com/snapcore/snapcraft/tree/master/demos/webcam-webui on 16.04 desktop, my snapcraft version is 2.12. I get the error like :Error downloading stage packages for part 'cam': no such package'fswebcam' . what could be the problem for it? thanks | 06:10 |
| RyanTG | tsimonq2: I did uninstall vlc using apt-get purge, but i'm concerned about the day trying to remove an apt package wants to remove a lot of other stuff with it, or gets reinstalled if it's part of a meta-package like *-desktop | 06:12 |
| tsimonq2 | RyanTG: I think it's fine :) | 06:20 |
| mup | PR snapd#1514 opened: client: improve error from client.do() on json decode failures <Created by mvo5> <https://github.com/snapcore/snapd/pull/1514> | 06:25 |
| dholbach | hey hey | 06:34 |
| mup | PR snapd#1491 closed: use more consistent "snap %q (rev %s)" task descriptions <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1491> | 06:35 |
| mup | PR snapd#1442 closed: many: allow removal of broken snaps, add spread test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1442> | 06:36 |
| qengho | RyanTG: Suggest something. You have two packages installed that provide the same program. What do you propose should happen? | 06:43 |
| qengho | Many service programs are rightly programmed to disallow running as root. What should we do for their snaps? | 06:44 |
| RyanTG | qengho: I'm not sure what should happen. When I first installed it, I knew I already had vlc from apt. I wanted to see what would happen. I thought there would be a good chance of vlc showing up twice in my menu (maybe that happens in dash, but I don't use dash). | 06:46 |
| RyanTG | I use classicmenu-indicator | 06:47 |
| mup | PR snapd#1513 closed: tests: readd the fake store tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1513> | 07:59 |
| mup | Bug #1600136 opened: App indicator does not show icon for Qt apps <desktop> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1600136> | 08:04 |
| mup | Bug #1600138 opened: App indicator does not show menu entries for Qt apps <desktop> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1600138> | 08:07 |
| mup | PR snapd#1514 closed: client: improve error from client.do() on json decode failures <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1514> | 08:11 |
| Dubstar_04 | Good Morning, I'm having issues with Nvidia drivers and snaps. If i use the Nouveau drivers it works fine. Is there anything I can do? | 08:16 |
| mup | Bug #1600140 opened: App indicator adds an entry for each snap launch <snap-desktop-issue> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1600140> | 08:19 |
| mup | PR snapd#1514 opened: client: improve error from client.do() on json decode failures <Created by mvo5> <https://github.com/snapcore/snapd/pull/1514> | 08:27 |
| mup | PR snapd#1515 opened: asserts,daemon: cross checks for account and account-key assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/1515> | 08:32 |
| mcphail | Dubstar_04: gl errors? I get that too | 08:35 |
| mup | Bug #1600154 opened: Reading gsettings key don't work locally (writing does) <snap-desktop-issue> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1600154> | 08:56 |
| zyga | Dubstar_04: hey | 09:00 |
| zyga | Dubstar_04: we're are aware of the issue, can you tell me which distribution you are using | 09:00 |
| zyga | Dubstar_04: on ubuntu the fix is not fully released yet | 09:00 |
| liuxg | didrocks, I just removed my snapcraft which was verion 2.12. Now, i want to try to install it again. do i need to add any ppa? | 09:19 |
| didrocks | liuxg: xenial? | 09:19 |
| liuxg | didrocks, yes | 09:20 |
| didrocks | liuxg: no, the version in the distro (2.12) should be the one you would use | 09:20 |
| liuxg | didrocks, I used the command "sudo apt-get install snapcraft", but it complains "Unable to locate package snapcraft" | 09:20 |
| liuxg | didrocks, I am trying to isolate the problem, so I removed my previsous snapcraft | 09:21 |
| didrocks | it's in universe | 09:21 |
| didrocks | same than my answer on the ML | 09:21 |
| didrocks | you did remove universe, from your system | 09:21 |
| liuxg | didrocks, how can I add it back? | 09:21 |
| didrocks | liuxg: how did you remove it, you have two ways, command line (changing the sources.list file or UI) | 09:22 |
| liuxg | didrocks, i just did it by "apt remove snapcraft" | 09:22 |
| didrocks | no, you removed universe explicitely on your system I would say | 09:22 |
| didrocks | (that was before) | 09:22 |
| didrocks | in "update" (or whatever it is in english -> ensure that universe is ticked | 09:23 |
| liuxg | didrocks, I do not remember it clearly when I did that. | 09:23 |
| Dubstar_04 | syga: i'm on ubuntu 16.04. | 09:24 |
| didrocks | liuxg: "software-properties-gtk" | 09:24 |
| didrocks | that's what you need to run | 09:24 |
| didrocks | ensure universe is checked | 09:24 |
| Dubstar_04 | zyga: ^^ | 09:24 |
| liuxg | didrocks, yes, it is on, then ... | 09:24 |
| didrocks | tick it off | 09:24 |
| didrocks | and then on | 09:24 |
| didrocks | but it can't be on from your output on the ML | 09:24 |
| didrocks | and the fact you are telling me you can't install snapcraft | 09:25 |
| liuxg | didrocks, is it the one "Community-maintained free and open-source software"? | 09:25 |
| didrocks | liuxg: exactly "(universe)" next to it | 09:26 |
| liuxg | didrocks, thanks. it is true. it was ticked off. | 09:27 |
| zyga | Dubstar_04: then this will be fixed with the next SRU | 09:27 |
| didrocks | ah, see! :) | 09:27 |
| Dubstar_04 | zyga: superb. thanks. | 09:27 |
| liuxg | didrocks, is there any way to have an example for packaging a ubuntu phone app into snap? | 09:30 |
| liuxg | didrocks, I think this will be very useful to developers to show the convergence story. | 09:30 |
| liuxg | didrocks, one app runs on all platforms. | 09:31 |
| didrocks | liuxg: not yet, you can be the one creating it! :) | 09:31 |
| didrocks | liuxg: I think adding the right package deps + desktop/qt5 launcher should be enough | 09:31 |
| liuxg | didrocks, I have a little problem in building the ubuntu-clock example. | 09:32 |
| didrocks | from playpen? | 09:32 |
| liuxg | didrocks, yes | 09:32 |
| didrocks | that's the issue you mentioned on the ML, right? | 09:32 |
| didrocks | did you retry since you added universe? | 09:32 |
| didrocks | (as I told you, this was your problem there as well) | 09:32 |
| liuxg | didrocks, yes, I am now building it again to see what happens. | 09:33 |
| didrocks | keep me posted! | 09:35 |
| liuxg | didrocks, this time, I have a different issue http://paste.ubuntu.com/18772870/ | 09:35 |
| didrocks | liuxg: this is a temporary failure from launchpad | 09:37 |
| didrocks | you need to apt get update | 09:37 |
| didrocks | and rerun | 09:37 |
| didrocks | (this can get 30 min to get sorted out) | 09:37 |
| liuxg | didrocks, OK. then I will wait and see. so, you are having the same problem with it? | 09:38 |
| didrocks | cjwatson: FYI, seems we can still have some hash sum mismatch (I thought they were all fixed) ^ | 09:38 |
| didrocks | liuxg: no, it depends on your mirror | 09:38 |
| didrocks | liuxg: if you catch it at the wrong time | 09:38 |
| didrocks | so, try to sudo apt update | 09:38 |
| didrocks | and rerun a build | 09:38 |
| liuxg | didrocks, OK. I might need to change another one to see it. thanks | 09:38 |
| didrocks | if still failing the same way | 09:38 |
| didrocks | wait a little bit | 09:38 |
| didrocks | and redo :) | 09:38 |
| didrocks | keep us posted! | 09:38 |
| liuxg | didrocks, in fact, I did apt update before building the project. | 09:39 |
| liuxg | didrocks, I changed a mirror site, and it seemed better :) | 09:41 |
| liuxg | didrocks, thanks for your help | 09:42 |
| didrocks | liuxg: yw! :) | 09:42 |
| liuxg | didrocks, I am getting the .snap file :) it used to work for me. I think it was broken somehow. | 09:43 |
| cjwatson | didrocks: you can still have hash sum mismatches if sites have actual wrong content, yes. that one isn't a problem with mirror structure | 09:57 |
| cjwatson | didrocks: (because files in pool/ have always had a unique mapping from URL->content - my recent fixes were about indexes because pool/ didn't need fundamental fixes) | 09:58 |
| cjwatson | didrocks: so no, that's *not* a temporary failure, and it's *not* a failure from Launchpad, it's just that one mirror being busted | 09:58 |
| cjwatson | didrocks: or possibly data corrupted in transit | 09:59 |
| mup | Bug #1600166 opened: Snap rely on dns-masq running on 127.0.0.1 instead of /etc/resolv.conf <Snappy:New> <https://launchpad.net/bugs/1600166> | 09:59 |
| mup | PR snapd#1516 opened: daemon: drop auther() <Created by chipaca> <https://github.com/snapcore/snapd/pull/1516> | 10:03 |
| didrocks | cjwatson: oh ok, I'm not expert enough to ensure those were valid corruptions or the races on the indexes we had. Ok, so now, we can only have valid mismatch, thanks for looking at it! :) | 10:07 |
| cjwatson | didrocks: right, you can tell it's not an index race just by seeing that the mismatch is on a file in pool | 10:08 |
| cjwatson | the previous hard case was always on something in dists | 10:08 |
| didrocks | ah ok, gotcha! | 10:10 |
| didrocks | TBH, I never looked closely than the error message, getting it now. (my bad) | 10:11 |
| Chipaca | dpm, good job on the notes snap work! | 10:17 |
| Chipaca | just saw the bugs and read all the pain :-) | 10:17 |
| dpm | Chipaca, thanks, kudos to didrocks to help me figuring them out! :) | 10:18 |
| Chipaca | ah, but we already know didrocks rocks. Oxymoronic, really. | 10:18 |
| didrocks | :-) | 10:20 |
| mup | PR snapd#1514 closed: client: improve error from client.do() on json decode failures <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1514> | 11:28 |
| === hikiko is now known as hikiko|ln | ||
| szszsz | Hi! Is there any difference between installing snappy package with sudo and without it? | 12:37 |
| mup | PR snapd#1516 closed: daemon: drop auther() <Reviewed> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1516> | 12:38 |
| jdstrand | zyga: I see you merged 73 (good-- I was hoping you saw my comment that it was fine to merge :) | 12:44 |
| zyga | jdstrand: yep | 12:44 |
| zyga | jdstrand: I'm going to cut the release shortly, I just feel sleepy and I'm rading some suse manuals | 12:44 |
| zyga | jdstrand: I'll just do it now | 12:45 |
| jdstrand | I imagine that would do that to you :) | 12:45 |
| zyga | no, that's not related ;> | 12:45 |
| zyga | suse is pretty interesting, many new concepts | 12:45 |
| zyga | I should just sleep more ;) | 12:46 |
| Odd_Bloke | szszsz: I believe there is a difference, but I'm not a snappy person so I don't know exactly. :) | 12:48 |
| zyga | szszsz: no, | 12:49 |
| zyga | szszsz: it allows you to install the package if you are signed in | 12:50 |
| szszsz | Odd_Bloke: zyga: OK, thanks! | 12:50 |
| === hikiko|ln is now known as hikiko | ||
| zyga | jdstrand: https://github.com/snapcore/snap-confine/pull/76 | 12:55 |
| mup | PR snap-confine#76: Drop the alternative to ROOTFS_IS_CORE_SNAP <Created by zyga> <https://github.com/snapcore/snap-confine/pull/76> | 12:55 |
| zyga | jdstrand: not critical, I'll cut the release now without this patch landing | 12:56 |
| jdstrand | zyga: commented | 13:00 |
| jdstrand | zyga: a welcome change :) | 13:00 |
| sborovkov | Hello, are there any news about ubuntu-image | 13:03 |
| zyga | sborovkov: not sure, try to ask slangasek | 13:03 |
| zyga | jdstrand: 1.0.36 is out | 13:04 |
| zyga | jdstrand: I'll do the packaging honors :) | 13:05 |
| sborovkov | slangasek: Hi, what's the status of ubuntu-image? | 13:06 |
| sborovkov | Also are there any news about gadget snap spec being finalized? I remember that was blocking for /dev/vchiq on RPI | 13:06 |
| jdstrand | zyga: cool, thanks! | 13:13 |
| zyga | jdstrand: BTW, your regression tests have some if ! something; then exit 1; fi lines | 13:19 |
| zyga | jdstrand: all of the script runs under set -e | 13:19 |
| zyga | jdstrand: so that is redundant, each failing line fails the test | 13:19 |
| jdstrand | zyga: I saw your review, I'll be going through that and all the interface PRs after I get through emails | 13:19 |
| zyga | jdstrand: thanks! | 13:20 |
| jdstrand | fyi, I'll be on holiday until Jul 20th starting Sat | 13:20 |
| zyga | jdstrand: I'll try to help with interfaces but I'm super slow lately | 13:20 |
| zyga | must be summer :/ | 13:20 |
| zyga | ah, nice | 13:20 |
| zyga | I plan to have holiday early August | 13:20 |
| jdstrand | but tyhicks can do policy reviews in my absence. I'll send a Where's Jamie later today | 13:20 |
| jdstrand | zyga: nice! :) | 13:20 |
| === dpm is now known as dpm-bbiab | ||
| ysionneau | is it possible when declaring systemd services in the snap, to setup dependencies between services? | 13:38 |
| didrocks | ysionneau: no, I think that goes with the bigger bug "enable setting up your own entries in the .service file" | 13:40 |
| didrocks | ysionneau: you aren't stuck and can hack it though :p | 13:40 |
| didrocks | (as the .service file is rw, you can change it after installing your snap) | 13:41 |
| didrocks | even from another service | 13:41 |
| didrocks | (yeah, it's a hack) | 13:41 |
| kyrofa | didrocks, dpm-bbiab thanks for tracking down the app indicator bug, it's been bothering me | 13:42 |
| didrocks | kyrofa: yw! I'm going to fix the apparmor policy, at least, we will have the menu appearing | 13:43 |
| didrocks | (and won't block process anymore) | 13:43 |
| didrocks | the icon one… I'm puzzled and unsure how we can fix it | 13:43 |
| kyrofa | didrocks, ah right, I meant the icon one. The other one should be a bit easier... the icon is tough | 13:44 |
| didrocks | because this file is generated just before sending the dbus call | 13:44 |
| didrocks | not at install time, not at startup time… | 13:44 |
| kyrofa | Indeed | 13:44 |
| kyrofa | And we definitely don't want to patch unity | 13:45 |
| didrocks | right, because, what about other shells? | 13:45 |
| didrocks | and other distros? | 13:45 |
| kyrofa | Exactly | 13:45 |
| kyrofa | Curious to hear jdstrand's thoughts on that one | 13:45 |
| didrocks | yep | 13:45 |
| mvo | mwhudson: hi, I heard rumors you have some clues about the yakkety autopkgtest failures? I'm super curious to learn more :) | 13:46 |
| jdstrand | I just responded to the bug actually. perhaps my comments might provide inspiration for a solution | 13:47 |
| ysionneau | didrocks: ok :) | 13:54 |
| kyrofa | Thanks for the thoughts jdstrand. So snaps can write to the system /run/shm/ ? | 13:54 |
| ysionneau | didrocks: another thing, it seems you can to daemon: oneshot, but then it fails because Restart=on-failure in the unit file | 13:54 |
| ysionneau | systemd wants Restart=no | 13:55 |
| ysionneau | but you cannot say restart-condition: no in the yaml, it is refused :x | 13:55 |
| jdstrand | kyrofa: they can write to: /{dev,run}/shm/snap.@{SNAP_NAME}.** | 13:55 |
| kyrofa | ysionneau, indeed, I made a bug for that a week or two ago | 13:55 |
| ysionneau | you can say restart-condition: never, but this is not accepted by systemd | 13:55 |
| ysionneau | so 1°) oneshot is basically un usable, and 2°) Restart=no/never does not work | 13:55 |
| kyrofa | jdstrand, ah okay, but it's not namespaced like /tmp? | 13:55 |
| ysionneau | kyrofa: do you have the bug id please? | 13:56 |
| jdstrand | kyrofa: it doesn't matter if it is a file or a directory or a directory tree | 13:56 |
| kyrofa | jdstrand, the snap and system see the same /run/shm? | 13:56 |
| kyrofa | Nice, okay | 13:56 |
| jdstrand | kyrofa: it is namespaced (noticed SNAP_NAME) but it isn't mount namespaced. ie, it is in the global namespace | 13:56 |
| kyrofa | ysionneau, bug #1595661 | 13:57 |
| mup | Bug #1595661: snapd uses "never" in systemd unit files when it should be using "no" <snapd (Ubuntu):New> <https://launchpad.net/bugs/1595661> | 13:57 |
| mup | PR snapd#1517 opened: wrappers: run update-desktop-database after add/remove of desktop files <Created by mvo5> <https://github.com/snapcore/snapd/pull/1517> | 13:57 |
| kyrofa | jdstrand, right, very good | 13:57 |
| * jdstrand notes that he always warned about a private /tmp would cause problems, but the /tmp problem is a difficult one | 13:58 | |
| ysionneau | thanks kyrofa | 13:59 |
| kyrofa | jdstrand, the private tmp complicates things, but still makes sense I think | 13:59 |
| didrocks | jdstrand: interesting idea, I think that worth a shot | 14:00 |
| kyrofa | didrocks, is that icon stuff upstream Qt, or do we have ubuntu patches on top? | 14:01 |
| didrocks | kyrofa: it's upstream Qt in Qt5, we have sni-qt for qt4 | 14:01 |
| kyrofa | Right, I remember that now | 14:02 |
| didrocks | (the indicator spec is based on KDE one) | 14:02 |
| didrocks | I worked on this years ago (not the main contributor), I have blurry memories of it, so, I don't know how much this is going to be easy | 14:02 |
| didrocks | it worthes a try at least | 14:02 |
| didrocks | jdstrand: oh btw, debugging the notes indicator, I'm going to add the apparmor profile needed updates for that, but debugging, I had another instance of messages that are in /var/log/syslog but not shown in scanlogs | 14:04 |
| mup | PR snapd#1518 opened: tests: add -y flag to apt autoremove command in unity task restore <Created by fgimenez> <Conflict> <https://github.com/snapcore/snapd/pull/1518> | 14:11 |
| === dpm-bbiab is now known as dpm | ||
| kyrofa | didrocks, you've been doing amazing parts work, by the way | 14:15 |
| kyrofa | didrocks, very much appreciated | 14:15 |
| niemeyer | Hellos | 14:18 |
| niemeyer | ogra_: ping | 14:18 |
| ogra_ | niemeyer, yo | 14:18 |
| niemeyer | ogra_: Heya | 14:18 |
| niemeyer | ogra_: Yesterday I went over a long trip on core images and initramfses | 14:19 |
| niemeyer | ogra_: One thing I learned is that our canonical-pc-linux doesn't currently support SCSI virtio.. we should fix that so we can support partvirtualization on those images | 14:19 |
| didrocks | kyrofa: thanks a lot :-) | 14:19 |
| ogra_ | niemeyer, can you file a bug, i'll add it then | 14:20 |
| niemeyer | ogra_: Will do, and I have a question out of curiosity too | 14:20 |
| niemeyer | ogra_: our cmdline has init=/lib/systemd/systemd | 14:20 |
| ogra_ | niemeyer, long term there is still the plan to have "two half initrds" ... but we first need images for this | 14:20 |
| ogra_ | i assume that init= thing can go nowadays | 14:21 |
| ogra_ | thats 15.04 legacy | 14:21 |
| niemeyer | ogra_: But that's inside partition 3, and under system-data | 14:21 |
| ogra_ | well, it is on / after the initrd assmbled the rootfs | 14:21 |
| niemeyer | ogra_: Where do we tell the initramfs where to chroot to before running that | 14:21 |
| ogra_ | we dont ... we assemble the rootfs first ... then we call run-init (which is another "pivot_root") | 14:22 |
| niemeyer | ogra_: Yeah, I understand there must be something pivoting into it.. the question is just where is that set | 14:22 |
| ogra_ | assembly happens based on partition names | 14:22 |
| ogra_ | not sure what you mean by "where is tha set" ... we assemble the rootfs under ... say /rootfs ... thats done by scripts in the initrd that look up the partiition names, mount teh right bits in the right places etc ... once that /rootfs is complete we pivot into it | 14:24 |
| jdstrand | didrocks: scanlog does not show dbus denials atm. there is a card for that | 14:25 |
| niemeyer | ogra_: Well, yeah, that's basically what an initrd is, isn't it :) | 14:26 |
| ogra_ | (essentially it looks for the writable partiton, mounts the core snap in the target dir and then processes $target/etc/system-image/wriitable-paths to get the rw bind mounts in place ... relative to $target) | 14:26 |
| niemeyer | ogra_: The question is how that's expressed.. | 14:26 |
| niemeyer | ogra_: How do we assemble that initrd so it does what we want.. there are a bunch of code there which is standard for every initrd, so I'm guessing this is not hand-coded every time, but rather has some proper configuration and conventions around it | 14:27 |
| ogra_ | niemeyer, aah ... | 14:27 |
| ogra_ | we use initramfs-tools from the distro ... and on top of that we use initramfs-tools-ubuntu-core ... | 14:28 |
| didrocks | jdstrand: ah, making sense. https://github.com/snapcore/snapd/pull/1519 btw | 14:28 |
| mup | PR snapd#1519: Add Qt5 indicator support in unity7 interface <Created by didrocks> <https://github.com/snapcore/snapd/pull/1519> | 14:28 |
| mup | PR snapd#1519 opened: Add Qt5 indicator support in unity7 interface <Created by didrocks> <https://github.com/snapcore/snapd/pull/1519> | 14:28 |
| niemeyer | Aha | 14:28 |
| ogra_ | initramfs-tools itself has a hooks and scripts ability to override scripts and hooks with your own stuff | 14:28 |
| niemeyer | ogra_: Wheres the source of initramfs-tools-ubuntu-core? I bet the answer to my questions are all there | 14:28 |
| ogra_ | so initramfs-tools-ubuntu-core ships our assembly script that is run by the infra of initramfs-toools | 14:29 |
| ogra_ | apt-get source ... there is no tree or anything | 14:29 |
| niemeyer | No repository? Are we back at the 90s? :) | 14:29 |
| ogra_ | you want scripts/ubuntu-core-rootfs http://paste.ubuntu.com/18789757/ ... | 14:30 |
| ogra_ | nah, we're stuck in the 80s with that one ... 90s ... way to modern :P | 14:30 |
| ogra_ | note that this script still carries 15.04 bits ... we need to drop them | 14:31 |
| niemeyer | Gotcha | 14:31 |
| ogra_ | we were also discussing to drop all the bind mount bits from ubuntu-core and do everything in the initrd | 14:32 |
| ogra_ | currently this is split in two ... i'd love to have the initrd give us an already properly set up rootfs instead (thats phone legacy we dont reall need anymore) | 14:32 |
| ogra_ | and a third thing that we should talk about at the sprint is to perhaps split the core snap in two as well ... | 14:33 |
| ogra_ | i know zyga is eager to actually only have the snap exec env in core ... we dont really need bits like systemd on classic ... | 14:34 |
| ogra_ | so we might be able to have core and core-bootable ... | 14:34 |
| ogra_ | oon classic you would onyl install core | 14:35 |
| ogra_ | images would use core+core-bootable ... which would ship the bits to actually run it as rootfs | 14:35 |
| ogra_ | (but thats sprint stuff that i'd like to discuss there) | 14:36 |
| niemeyer | Sounds good | 14:36 |
| niemeyer | I also recall seeing the idea flying that we might not need an initrd at all, but that's been a while ago and I have no context | 14:36 |
| ogra_ | well, thet wouldnt work ... we need the rw bind mounts to appear somehow ... before init runs | 14:37 |
| ogra_ | *that | 14:37 |
| ogra_ | at least some of them | 14:37 |
| niemeyer | Yeah, I wouldn't worry at this point | 14:42 |
| ogra_ | (no initrd would *massively* speed up our boot ... but i dont see a way to get along without one) | 14:44 |
| niemeyer | ogra_: There's nothing inside the initrd that cannot be on the image itself | 14:48 |
| ogra_ | niemeyer, well, a) you need the modules to find your disk ... b) you need the bits that init expects | 14:49 |
| mup | Bug #1600260 opened: Support paravirtualization <Snappy:New> <https://launchpad.net/bugs/1600260> | 14:49 |
| didrocks | niemeyer: I guess you are already aware of it, but the PR is failing in spread (can't access one of the test snap package), unsure it needs a rekick | 14:49 |
| mvo | didrocks: just rekick | 14:50 |
| mvo | didrocks: that got fixed ages ago (~7min or so) | 14:50 |
| didrocks | ahah :) | 14:50 |
| didrocks | sorry to not be on the edge! | 14:50 |
| mvo | didrocks: ;) | 14:50 |
| niemeyer | ogra_: There are straightforward solutions for those, I believe | 14:50 |
| didrocks | "This build can't be restarted | 14:51 |
| niemeyer | ogra_: But again, let's not worry for now | 14:51 |
| didrocks | mvo: mind doing it? ^ | 14:51 |
| ogra_ | i dont, but lets talk at the sprint | 14:51 |
| niemeyer | Yeah | 14:51 |
| didrocks | (I don't remember if "retest this please" rekicks travis CI as well) | 14:51 |
| niemeyer | ogra_: #1600260 filed | 14:51 |
| mup | Bug #1600260: Support paravirtualization <Snappy:New> <https://launchpad.net/bugs/1600260> | 14:51 |
| ogra_ | thx | 14:51 |
| niemeyer | didrocks: It doesn't | 14:51 |
| mvo | didrocks: sure, done | 14:52 |
| didrocks | yeah, that's what I thought, I don't have permissions to restart the build, that's weird, IIRC, travis CI don't show up the button in that case (but I got it) | 14:52 |
| niemeyer | ogra_: Thank you for looking into it | 14:52 |
| didrocks | anyway, thanks! | 14:52 |
| ogra_ | np, should be an easy fix | 14:52 |
| dak__ | hello. i have a question - i made a snap for angband and installed it, but when i run the command, it looks for /share/angband directory instead of $SNAP/share/angband, thus failing. any additional step needed to make the snap point to the right location? | 15:03 |
| didrocks | dak__: hey! it really depends on the upstream build system, you can for some set --datadir= and point to something or having them relocatable | 15:09 |
| didrocks | the best is for the apps to see there is no /share and then, look to a relative path | 15:09 |
| jdstrand | niemeyer: fyi, finally responded to https://github.com/snapcore/snapd/pull/1405. going through other PRs now | 15:16 |
| mup | PR snapd#1405: interfaces: add zigbee-dongle interface <Reviewed> <Created by jocave> <https://github.com/snapcore/snapd/pull/1405> | 15:16 |
| niemeyer | jdstrand: jd | 15:16 |
| niemeyer | jdstrand: Thanks! | 15:16 |
| mup | Bug #1600271 opened: snap install/remove multiple package names <Snappy:New> <https://launchpad.net/bugs/1600271> | 15:19 |
| joc_ | jdstrand: thanks for response on zigbee-dongle, can i just check one point | 15:20 |
| joc_ | jdstrand: if /dev/zigbee/ only contains symbolic links will the apparmor glob /dev/zigbee/* work | 15:21 |
| joc_ | jdstrand: i was under the impression it wouldn't, and was the reason why some of the other interfaces I looked at dereference paths that include symbolic links (e.g. bool-file) | 15:22 |
| mup | PR snapd#1483 closed: many: migrate SnapSetup and SideInfo to use RealName <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1483> | 15:25 |
| jdstrand | joc_: no, it won't. apparmor resolves symlinks. as such, snappy will need to resolve those and add them like you said | 15:35 |
| jdstrand | joc_: for the no attributes case. for the with attributes case, that wouldn't be needed (since it is the device cgroup that does the enforcement) | 15:35 |
| joc_ | jdstrand: thanks for confirmation | 15:39 |
| joc_ | niemeyer: does that mean it's ok to land that PR as is? and work on jdstrand's suggestion for a version that uses attributes later | 15:40 |
| mhall119 | is there a snap command to show info about a snap? | 15:40 |
| mhall119 | something like "snap show foo"? | 15:40 |
| jdstrand | joc_: note, for 'as-is' it won't work til you resolve those symlinks | 15:40 |
| jdstrand | based on my understanding of what you said is in that dir anyway | 15:41 |
| joc_ | jdstrand: the zigbeeDevPaths function evaluates the symlinks found in that dir and adds the resolved paths to the apparmor snippet | 15:43 |
| jdstrand | ah, cool | 15:45 |
| mup | PR snapd#1520 opened: tests: add locale-control interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1520> | 15:46 |
| mhall119 | sergiusens: BTW, I'm still waiting on that snapcraft fix to be available for me to try in a cleanbuild, any update on that? | 15:50 |
| didrocks | mvo: interesting trick (about the reexec) | 15:50 |
| mhall119 | "that snapcraft fix" being the pkg-config lookup changes for pantheon-mail | 15:50 |
| kyrofa | mhall119, not yet... ran into some CI issues that really delayed our release | 16:01 |
| joc_ | mvo: so under the new update process, the "snap" exe would still be provided by the deb install but snapd would be updated with ubuntu-core snap? | 16:13 |
| cjwatson | dholbach: https://bugs.launchpad.net/bugs/1599786 - do you agree with the position in my follow-up comment at the end? | 16:14 |
| mup | Bug #1599786: Run snapcraft update before attempting a snap build <launchpad-buildd:In Progress by cjwatson> <https://launchpad.net/bugs/1599786> | 16:14 |
| dholbach | sergiusens, ^ | 16:15 |
| kyrofa | dholbach, cjwatson agreed | 16:17 |
| cjwatson | right, will revert when I get a minute, thanks | 16:18 |
| mup | PR snapcraft#640 opened: Setup the FakeParts store for all unit tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/640> | 16:19 |
| kyrofa | cjwatson, worth pointing out that it's not quite released in snapcraft yet though | 16:19 |
| kyrofa | cjwatson, any chance you could delay the reversion for a few days? :P | 16:19 |
| cjwatson | kyrofa: well, I haven't rolled out the launchpad-buildd change either | 16:20 |
| cjwatson | kyrofa: and it would take a few days to do that ... | 16:20 |
| kyrofa | cjwatson, ah, scratch that then. We'll be SRUing very soon | 16:20 |
| kyrofa | cjwatson, go ahead and toast it | 16:20 |
| tsimonq2 | hey kyrofa | 16:20 |
| cjwatson | right. I mean, we can do virtual-builder-only rollouts just by getting IS to copy to a PPA, so it's not *that* hard, but I wouldn't want to do it late on a Friday | 16:21 |
| kyrofa | Indeed | 16:21 |
| kyrofa | Hey tsimonq2 :) | 16:21 |
| zyga | joc_: both snap and snapd would come from snaps | 16:23 |
| zyga | joc_: they both check and reexec the more up-to-date version | 16:23 |
| joc_ | zyga: ok just checking, only snapd was mentioned :) | 16:23 |
| tsimonq2 | kyrofa: I'm working hard on getting that coverage good to go :) | 16:27 |
| tsimonq2 | kyrofa: I have everything but a checksum from a file and from a remote URL: https://coveralls.io/builds/6919217/source?filename=snapcraft%2Finternal%2Fsources.py#L129 | 16:27 |
| kyrofa | zyga, speaking of that, do you have any thoughts on bug #1599620? | 16:27 |
| mup | Bug #1599620: SNAP_REEXEC doesn't cover snap-exec <snapd (Ubuntu):New> <https://launchpad.net/bugs/1599620> | 16:27 |
| mup | PR snapcraft#641 opened: yield the correct exception when retries are out <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/641> | 16:28 |
| kyrofa | tsimonq2, make sure you have an invalid checksum as well | 16:28 |
| tsimonq2 | kyrofa: yep, covered | 16:28 |
| tsimonq2 | kyrofa: I'm getting close ;) | 16:28 |
| kyrofa | tsimonq2, the format, I mean | 16:28 |
| kyrofa | tsimonq2, https://coveralls.io/builds/6919217/source?filename=snapcraft%2Finternal%2Fsources.py#L154 | 16:29 |
| kyrofa | tsimonq2, nice work! | 16:29 |
| tsimonq2 | kyrofa: that's weird because I have https://github.com/snapcore/snapcraft/pull/619/files#diff-3ce6f0422479e72d9db0860efb0e7b42R238 | 16:30 |
| mup | PR snapcraft#619: Add source-checksum option for tar and zip sources (bug 1585913) <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/619> | 16:30 |
| kyrofa | tsimonq2, that's not testing the format, that's just an incorrect checksum. Also a good test, but not the same | 16:31 |
| zyga | kyrofa: looking | 16:31 |
| kyrofa | tsimonq2, you need to have a checksum that doesn't match the _format_ of any others | 16:31 |
| mup | PR snapcraft#640 closed: Setup the FakeParts store for all unit tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/640> | 16:31 |
| tsimonq2 | kyrofa: ohhh okay | 16:31 |
| ogra_ | mvo, http://paste.ubuntu.com/18797420/ ... classic delta ;) ... (adds 5MB to the core snap) | 16:31 |
| tsimonq2 | kyrofa: yeah I added that as sort of a "just in case" but I see | 16:31 |
| zyga | kyrofa: ah, I recall this issue now | 16:31 |
| zyga | kyrofa: so I think we should have a way to test snap-exec for sure | 16:32 |
| zyga | kyrofa: not sure if the environment variable is the way to go here | 16:32 |
| kyrofa | tsimonq2, if it's behavior you want to preserve (i.e. if it SHOULD work that way) you should cover it in a test so it can't regress | 16:32 |
| kyrofa | zyga, indeed. I had to use overlayfs just to test my dev version :P | 16:32 |
| zyga | kyrofa: I'd have to get more familiar with the current flow of events there | 16:32 |
| zyga | kyrofa: yeah, it's annoying, we had do to something similarly odd to test snap-confine | 16:33 |
| kyrofa | Yeah... really rough | 16:33 |
| zyga | kyrofa: I think that snap-exec is something we'd run from snap-confine, correct? | 16:33 |
| tsimonq2 | kyrofa: it would be good for that not to regress... :) | 16:33 |
| zyga | kyrofa: if so, perhaps we could allow snap-confine to be built in test mode where this is divertable | 16:33 |
| zyga | kyrofa: otherwise I bet it would be a security risk | 16:33 |
| kyrofa | zyga, well, snap run invokes snap-confine requesting it to run snap-exec.... so not really | 16:34 |
| kyrofa | zyga, but kinda :P | 16:34 |
| zyga | kyrofa: the way I understand the flow is that we planned to skip the request so that snap-confine *always* ran snap-exec | 16:34 |
| kyrofa | zyga, that may be the final intention. mvo would need to clarify that. It's not the way it works currently | 16:34 |
| zyga | so that when you ask snap confine to do something it will never let you do that but run code under user's control | 16:34 |
| zyga | kyrofa: that's right | 16:35 |
| zyga | kyrofa: this was a phased upgrade process, we didn't implement it all the way | 16:35 |
| kyrofa | zyga, sounds about right | 16:35 |
| zyga | kyrofa: as long as there's an agreed plan and we all know it I'm sure we can figure out how to safely test snap-exec | 16:35 |
| kyrofa | zyga, very good. I guess I wanted to make sure someone knew about that bug so we could keep it in the back of our minds | 16:36 |
| zyga | kyrofa: I remember you mentioning this already; I was actually preparing for the switch more or less | 16:36 |
| zyga | kyrofa: with the change to snap-confine testing so that we can drop the old tests/ and use new unit tests and spread tests | 16:36 |
| kyrofa | zyga, indeed, I tried to mention it a few times but got no love :P | 16:36 |
| zyga | kyrofa: because I knew we won't be able to run arbitrary payload with arbitrary confinement soon | 16:36 |
| kyrofa | Nice | 16:37 |
| tsimonq2 | hey kyrofa, can I please get a bit of help? | 16:45 |
| kyrofa | tsimonq2, sure, what's up? | 16:45 |
| tsimonq2 | kyrofa: I'll push my code in like 30 secs, then I'll explain | 16:46 |
| tsimonq2 | pushed | 16:46 |
| tsimonq2 | okay, I'm expecting it to fail Travis BTW | 16:46 |
| tsimonq2 | kyrofa: in my code I want to call the source_checksum function within the source_checksum_determine_type function | 16:47 |
| tsimonq2 | kyrofa: the problem is, when I use self, it complains about not being in the TestTar and TestZip classes | 16:47 |
| tsimonq2 | kyrofa: but I need a variable from source_checksum_determine type to pass to source_checksum | 16:48 |
| tsimonq2 | kyrofa: (this is all in snapcraft/internal/sources.py ) | 16:48 |
| tsimonq2 | kyrofa: been working at this for an hour, trying different things, but it seems obvious | 16:48 |
| mup | PR snapcraft#641 closed: yield the correct exception when retries are out <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/641> | 16:52 |
| mvo | ogra_: oh, nice | 16:55 |
| mvo | ogra_: is that available in edge now? thats cool | 16:55 |
| mvo | kyrofa: not sure I have all the context - snap run runs snap-confine and that runs snap-exec currently, in the future probably snap-confine will run snap-exec automatically but not yet because we need to transition to this first | 16:58 |
| kyrofa | mvo, very good, that's what we thought | 16:58 |
| mvo | kyrofa: cool | 17:00 |
| tsimonq2 | kyrofa: so I don't know if you have any thoughts on my PR? :) | 17:00 |
| mvo | ogra_: really cool! and just 5mb because we skip on the man-pages I assuem (which is fine, just curious) | 17:01 |
| mvo | ogra_: is that in the latest images? if so, I will be excited to bring back classic on monday :) | 17:02 |
| kyrofa | tsimonq2, sorry, on the phone... my move is suddenly going up in flames | 17:03 |
| tsimonq2 | kyrofa: oh okay :) | 17:03 |
| ogra_ | mvo, yeah, i still need to quieten the script a bit, but essentially it is done now | 17:07 |
| ogra_ | mvo, it is in the latest cdimage snaps, we'll need to push them to the store eventually | 17:08 |
| ogra_ | (there might also be more cleanup needed, i think the dpkg status file lists stuff we removed binaries from, but it is good enough for a start) | 17:09 |
| kyrofa | tsimonq2, okay, I'm back now. uhaul will be the death of me | 17:11 |
| === chihchun is now known as chihchun_afk | ||
| mvo | ogra_: very nice, I will play with it monday and start with re-adding classic, this is huge, thank you! | 17:13 |
| ogra_ | awesome ... :) | 17:13 |
| ogra_ | and sorry it took so long (after all it was not really much code, but so much inspection work) | 17:13 |
| mvo | ogra_: no worries, if we can manage to make it work before the sprint (and I think we can) thats is good enough for me | 17:15 |
| ogra_ | we definitely can | 17:15 |
| mvo | cool | 17:16 |
| mvo | ogra_: I call it a day, lets talk more later | 17:16 |
| * mvo waves | 17:16 | |
| tsimonq2 | kyrofa: heh, good luck with that :) | 17:17 |
| kyrofa | tsimonq2, my units pass... | 17:17 |
| kyrofa | tsimonq2, (for your branch) | 17:17 |
| kyrofa | tsimonq2, how do I reproduce the issue you're seeing? | 17:17 |
| tsimonq2 | oh really? | 17:18 |
| tsimonq2 | wait yeah | 17:18 |
| tsimonq2 | weird, it should have failed lol | 17:18 |
| tsimonq2 | but I guess it didn't | 17:18 |
| tsimonq2 | which means it's my machine! \o/ | 17:18 |
| tsimonq2 | kyrofa: so, can you confirm my next steps? | 17:20 |
| tsimonq2 | - Remote URL checksum | 17:20 |
| tsimonq2 | - Invalid checksum | 17:20 |
| tsimonq2 | kyrofa: that's it maybe? | 17:21 |
| tsimonq2 | wait this is weird... https://coveralls.io/builds/6919217/source?filename=snapcraft%2Finternal%2Fsources.py#L134 | 17:21 |
| tsimonq2 | so it never does the file thing? | 17:22 |
| mup | PR snapcraft#642 opened: Make maven plugin honour https_proxy and proxy authentication <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/642> | 17:22 |
| * tsimonq2 facepalms | 17:22 | |
| tsimonq2 | I NEVER COMMITED! | 17:22 |
| tsimonq2 | kyrofa: *now* everything should break and it should be as described | 17:23 |
| niemeyer | joc_: It should at least do what I suggested in terms of using apparmor rather than globbing the FS at connection time | 17:23 |
| niemeyer | joc_: But it doesn't look like implementing what jdstrand suggested would be hard either | 17:24 |
| kyrofa | tsimonq2, heh | 17:24 |
| niemeyer | Why not just doing it quickly rather than postponing and risking having it like that for a long time? | 17:24 |
| tsimonq2 | kyrofa: but does my checklist look good then? | 17:24 |
| kyrofa | tsimonq2, for units yeah that sounds about right | 17:25 |
| tsimonq2 | kyrofa: anything else I might have to do? | 17:25 |
| kyrofa | tsimonq2, I've not reviewed it completely, so not that I know of but that doesn't mean "no" ;) | 17:26 |
| tsimonq2 | kyrofa: alright :) | 17:27 |
| mcphail | When can we expect updating snaps to use binary deltas instead of downloading full packages? Is it on the horizon? | 17:34 |
| kyrofa | tsimonq2, do you know the difference between instance and class methods? | 17:35 |
| tsimonq2 | kyrofa: vaguely, please refresh | 17:36 |
| kyrofa | tsimonq2, an instance method operates upon a specific method, mutates it in some way or at least utilizes information specific to that instance | 17:37 |
| kyrofa | tsimonq2, whereas class methods are not specific to instances-- they're available on the class itself without requiring an instantiation | 17:37 |
| tsimonq2 | kyrofa: oh okay | 17:37 |
| kyrofa | tsimonq2, note that the functions you've written for checking the format etc. are not specific to the class upon which it's implemented at all | 17:38 |
| kyrofa | tsimonq2, does that make sense? | 17:38 |
| tsimonq2 | kyrofa: I see, so do I need to call the specific class along with the function? | 17:39 |
| kyrofa | tsimonq2, with what you've written, a fix for test_non_matching_checksum is this: http://pastebin.ubuntu.com/18803040/ | 17:39 |
| kyrofa | tsimonq2, however, notice how I have to instantiate a zip class just to check the checksum | 17:40 |
| kyrofa | tsimonq2, well, that's not specific to zip. It's not specific to any source | 17:40 |
| kyrofa | tsimonq2, so I suggest a small refactor-- pull those functions out of any class and implement them standalone | 17:40 |
| tsimonq2 | kyrofa: what functions, in the tests or in the code for it? | 17:41 |
| kyrofa | tsimonq2, the code for them | 17:41 |
| kyrofa | tsimonq2, they shouldn't be in FileBase | 17:41 |
| tsimonq2 | kyrofa: so I need to pull out of FileBase and not put it in any other class, you're saying? | 17:42 |
| kyrofa | tsimonq2, exactly | 17:42 |
| kyrofa | tsimonq2, then you can test them directly without needing to instantiate any classes | 17:43 |
| tsimonq2 | kyrofa: cool, thanks, I can work with that :) | 17:43 |
| mup | PR snapcraft#643 opened: Release debian/changelog for 2.12.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/643> | 17:43 |
| kyrofa | tsimonq2, typically when designing an API like this, you go through a decision-making process. You have four-ish options: do you make this function a public instance method, a private instance method, a class method, or standalone? | 17:45 |
| kyrofa | tsimonq2, you have to ask yourself a number of questions when determining the answer to that question | 17:46 |
| tsimonq2 | kyrofa: welp, snapcraft#643 seems to say that my PR's not getting in | 17:47 |
| mup | PR snapcraft#643: Release debian/changelog for 2.12.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/643> | 17:47 |
| kyrofa | tsimonq2, first you decide instance/non-instance. You ask "Is my function really specific to this class? Does it require access to its member variables?" | 17:47 |
| kyrofa | tsimonq2, not into this release anyway. You can hit the next one :) | 17:47 |
| tsimonq2 | kyrofa: oh okay :) | 17:47 |
| tsimonq2 | kyrofa: I'm reading what you're saying ;) | 17:47 |
| kyrofa | tsimonq2, if the answer is no, then you have to decide class method versus standalone. You'd ask "is this method still do something specific to this class? To subclasses need to be able to override it?" | 17:48 |
| kyrofa | tsimonq2, if the answer is no, then you prefer standalone functions. They're easy to test and easy to reuse | 17:49 |
| tsimonq2 | kyrofa: I see, makes sense | 17:49 |
| kyrofa | tsimonq2, so typically, prefer standalone functions if it makes sense to implement things that way. It leads to a more modular and testable design | 17:49 |
| kyrofa | tsimonq2, applying that logic to your checksum functions, let's ask: "are they really specific to that given source? Does it require access to member variables?" | 17:50 |
| tsimonq2 | kyrofa: I see, and with something like this, it's probably good to be a standalone :) | 17:50 |
| tsimonq2 | yeah | 17:50 |
| tsimonq2 | they aren't source-specific | 17:50 |
| kyrofa | tsimonq2, right. They don't meet the test for class methods either | 17:51 |
| tsimonq2 | yeah | 17:51 |
| kyrofa | Anyway, that's my software spew for today :) | 17:52 |
| kyrofa | tsimonq2, one more thing: if you have a class instance and you want to call a method on it, even a method inherited from a parent class, just call self.method(), not MyParentClass.method(self) | 17:53 |
| tsimonq2 | kyrofa: it's useful, I learned something new :) | 17:53 |
| tsimonq2 | kyrofa: oh okay | 17:53 |
| tsimonq2 | hey kyrofa | 18:01 |
| tsimonq2 | kyrofa: one more thing | 18:01 |
| tsimonq2 | wait hm | 18:02 |
| kyrofa | tsimonq2, hmm? | 18:03 |
| tsimonq2 | kyrofa: yeah, so I have the teo classes, right? I still can't call one from another and I still can't get the variable from one to another | 18:04 |
| kyrofa | tsimonq2, I'm missing context here. Two classes-- zip and tar? One variable are you trying to get from one to the other? | 18:05 |
| kyrofa | s/One/What/ | 18:05 |
| tsimonq2 | kyrofa: check_checksum_determine_format and check_checksum | 18:05 |
| kyrofa | tsimonq2, those are what you're making standalone now, right? | 18:06 |
| tsimonq2 | kyrofa: I need source_checksum and checkfile to hop from one to the other | 18:06 |
| tsimonq2 | kyrofa: yes, pushed | 18:06 |
| kyrofa | tsimonq2, standalone functions have no "self," that's for instance methods | 18:07 |
| tsimonq2 | kyrofa: so how do I call it then | 18:08 |
| tsimonq2 | s/then/then?/ | 18:08 |
| kyrofa | tsimonq2, just... directly. Like `check_checksum()` | 18:08 |
| kyrofa | No self at all | 18:08 |
| tsimonq2 | oh! | 18:08 |
| tsimonq2 | ok | 18:08 |
| tsimonq2 | let me see | 18:08 |
| tsimonq2 | kyrofa: well I think that fixed it, I don't know, because I have the following: def check_checksum_determine_format(self, source_checksum, checkfile): and I only pass source_checksum and checkfile, do I really need to pass self as well? what could that do? | 18:10 |
| tsimonq2 | (I only pass those two variables in my tests) | 18:10 |
| kyrofa | tsimonq2, no, no self | 18:10 |
| kyrofa | tsimonq2, remove that as a param | 18:10 |
| kyrofa | tsimonq2, again, just for instance methods | 18:10 |
| kyrofa | tsimonq2, which these are no longer | 18:10 |
| tsimonq2 | oh that's right! sorry, that was obvious :P | 18:11 |
| mup | PR snapd#1518 closed: tests: add -y flag to apt autoremove command in unity task restore <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1518> | 18:55 |
| mhall119 | is there a list of available interfaces for a snap to use? | 18:59 |
| niemeyer | mhall119: https://github.com/snapcore/snapd/blob/master/docs/interfaces.md | 19:06 |
| mup | PR snapd#1476 closed: overlord: make SyncBoot work again <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1476> | 19:42 |
| mhall119 | thanks niemeyer | 19:48 |
| mhall119 | is is necessary to include the gsettings plug in order for an app to access just it's own settings? | 19:54 |
| mup | PR snapd#1521 opened: many: removed authenticator, store gets a user instead <Created by matiasb> <https://github.com/snapcore/snapd/pull/1521> | 20:18 |
| tsimonq2 | mhall119: or you could just do snap interfaces | 20:22 |
| mhall119 | tsimonq2: I did, but I wasn't sure if that showed all of the ones in snapd, or just the ones with a slot or plug installed | 20:35 |
| tsimonq2 | mhall119: mine has ones with no snaps in them | 20:36 |
| mhall119 | thanks tsimonq2 | 20:39 |
| tsimonq2 | no problem mhall119 :) | 20:40 |
| === evanmeag_ is now known as evanmeagher | ||
| mup | Bug #1592714 changed: snapd-interface application problem with systry icon <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1592714> | 21:04 |
| cyphermox | where can I get the files I need to do porting; for instance the gadget and os snaps? | 21:12 |
| kyrofa | mhall119, I believe `snap interfaces` will show all interfaces that have slots on the system | 21:15 |
| kyrofa | mhall119, e.g. snapd may support more interfaces than are available on the given system | 21:15 |
| tsimonq2 | kyrofa: that's what I said :) | 21:15 |
| tsimonq2 | kyrofa: hello btw :) | 21:16 |
| kyrofa | tsimonq2, well, you said you see ones with no _plugs_ in them, no? | 21:16 |
| tsimonq2 | kyrofa: yes | 21:16 |
| tsimonq2 | $ snap interfaces | pastebinit | 21:16 |
| tsimonq2 | http://paste.ubuntu.com/18823922/ | 21:16 |
| kyrofa | tsimonq2, I'm saying `snap interfaces` will not show all interfaces | 21:16 |
| kyrofa | tsimonq2, just the ones with slots | 21:17 |
| tsimonq2 | kyrofa: no it won't, see my pastebin | 21:17 |
| tsimonq2 | :cups-control - | 21:17 |
| tsimonq2 | :firewall-control - | 21:17 |
| tsimonq2 | :gsettings - | 21:17 |
| tsimonq2 | (for example) | 21:17 |
| kyrofa | tsimonq2, those are slots | 21:17 |
| kyrofa | tsimonq2, with no corresponding plug | 21:18 |
| kyrofa | tsimonq2, I'm saying there's no way to see interfaces with no slots available | 21:18 |
| tsimonq2 | kyrofa: oh | 21:18 |
| kyrofa | tsimonq2, i.e. snapd can support X interface, but if the system has no snaps installed providing the X slot, `snap interfaces` won't show it | 21:19 |
| tsimonq2 | kyrofa: oh ok | 21:19 |
| tsimonq2 | kyrofa: huh, for some reason only sha512 checksums work...while I hack on it, is there anything obvious you can point out? | 21:44 |
| tsimonq2 | oh I'm stupid | 21:46 |
| tsimonq2 | kyrofa: sorry for all the pings | 21:46 |
| mcphail | Is there a way to install snapd on a first-generation raspberry pi running raspian? | 21:50 |
| tsimonq2 | kyrofa: I think my PR's ready, I'm pretty proud of my first comment :D https://github.com/snapcore/snapcraft/pull/619 | 23:52 |
| mup | PR snapcraft#619: Add source-checksum option <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/619> | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!