| PhoenixMage | hmmm, maybe today I will give samba dc another go *sigh* | 00:08 |
|---|---|---|
| === JoshStrobl is now known as JoshStrobl|zzz | ||
| mwhudson | zyga-suse: maybe you can look at https://forum.snapcraft.io/t/snapd-vs-upstream-kernel-vs-apparmor/1704 then | 00:24 |
| ikey|zzz | https://dev.solus-project.com/R2930:183f2e34c4e9fda0fe3eb06f170633c27d3a07f4 | 00:56 |
| * ikey|zzz walks out | 00:56 | |
| ikey|zzz | crap i typoed and meant solus 3 | 00:57 |
| * ikey|zzz walks out again | 00:57 | |
| willdeberry | hello all, anyone have a moment to assist with getting this snap i am building able to talk to dbus and bluetooth? | 02:12 |
| willdeberry | i am currently getting the following: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied | 02:13 |
| willdeberry | I have tried using the following plugs: network, network-manager, network-control and bluetooth-control | 02:14 |
| willdeberry | do i have to switch to classic mode to get the support i am aiming for? | 02:14 |
| willdeberry | repo link for reference: https://github.com/willdeberry/bjarkan | 02:18 |
| chad_young | willdeberry: I am a novice so take my suggestions as such | 02:36 |
| chad_young | I thought there was a bluez interface | 02:37 |
| willdeberry | this is a non ubuntu core install so it doesn't show a bluez interface | 02:38 |
| willdeberry | trying to use system's bluez/dbus | 02:38 |
| chad_young | sorry - cant help - good luck | 02:39 |
| willdeberry | :( | 02:41 |
| willdeberry | i assume classic is the answer, but just want to exhaust all ideas before jumping to that | 02:41 |
| chad_young | I really have a hard time believeing that "classic" is the only option | 03:00 |
| willdeberry | agreed, which is why i am here :) | 03:02 |
| chad_young | willdeberry - have you posted the same Q on https://rocket.ubuntu.com/home or the forums? | 03:02 |
| chad_young | https://forum.snapcraft.io | 03:03 |
| willdeberry | i have not. i can give rocketchat a try though | 03:04 |
| PhoenixMage | Whats the correct way to restart a daemon inside a snap? | 03:44 |
| PhoenixMage | Is there any way to prevent snapcraft from adding a copy of x86_64-linux-gnu/libpytalloc-util.so.2 when priming? | 05:43 |
| * mvo hugs mwhudson | 06:33 | |
| mvo | mwhudson: about the panic in -buidmode=pie, where should I report this? | 06:38 |
| mvo | mwhudson: reported against the debian golang-1.8 for now as 1711052 | 06:50 |
| zyga-ubuntu | good morning | 06:53 |
| mvo | hey zyga-ubuntu! | 06:55 |
| zyga-ubuntu | mvo: hey | 06:55 |
| zyga-ubuntu | I see we know what the crash is caused by | 06:55 |
| zyga-ubuntu | ish | 06:55 |
| zyga-ubuntu | mwhudson: can you expand on the "it is a hack" comment | 06:55 |
| mvo | zyga-ubuntu: yeah, very happy, testing a workaround (no pie for i386) and if that works we have 2.27.2 and a bottle of champagne (or maybe just a cup of tea) | 06:56 |
| zyga-ubuntu | that works for me | 06:58 |
| mup | PR snapd#3736 closed: apparmor: pass --quiet to parser on load unless SNAPD_DEBUG is set <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3736> | 06:59 |
| zyga-ubuntu | brb | 07:08 |
| mup | PR snapcraft#1488 opened: lxd: always remove existing device for project folder <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1488> | 07:33 |
| mup | PR snapd#3737 opened: debian: do not build with -buildmode=pie on i386 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3737> | 07:35 |
| mup | PR snapd#3738 opened: debian: do not build with -buildmode=pie on i386 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3738> | 07:36 |
| * zyga-ubuntu wonders when launchpad will support markdown | 07:41 | |
| zyga-ubuntu | mvo: do we get build-id in non-pie mode? | 07:42 |
| zyga-ubuntu | mwhudson: and do we need the same approach on armhf? | 07:42 |
| zyga-ubuntu | mwhudson: what's the trigger, is it exactly i386 or is it all 32bit | 07:42 |
| mvo | zyga-ubuntu: we still have a build-id | 07:50 |
| zyga-ubuntu | mvo: when do you plan to release .2? | 07:53 |
| mvo | zyga-ubuntu: as soon as I green light for the pie workaround | 07:53 |
| mup | PR snapcraft#1474 closed: kbuild plugin: use ARCH from environment if set <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1474> | 08:06 |
| zyga-ubuntu | mvo: it's green | 08:11 |
| zyga-ubuntu | mvo: do you want to wait for adt? | 08:11 |
| mvo | zyga-ubuntu: mostly interessted in feedback from mwhudson or Chipaca | 08:13 |
| Chipaca | mvo: on what? | 08:15 |
| Chipaca | aha | 08:16 |
| PhoenixMage | zyga-ubuntu: Do you know if snapcraft puts a copy of libpytalloc-util.so.2 in x86_64-linux-gnu? | 08:19 |
| zyga-ubuntu | PhoenixMage: if that library is referenced via DT_NEEDED | 08:19 |
| zyga-ubuntu | PhoenixMage: snapcraft walks the built package and seeks shared libaries that are used | 08:19 |
| zyga-ubuntu | PhoenixMage: it doesn't handle dlopen-style references though | 08:20 |
| PhoenixMage | zyga-ubuntu: How would I stop it from doing that? It seems to be the wrong version and samba has one of its own. I get mportError: /snap/samba-dc/x1/usr/lib/x86_64-linux-gnu/libpytalloc-util.so.2: version `PYTALLOC_UTIL_2.1.9' not found (required by /snap/samba-dc/x1/usr/lib/samba/libsamba-python-samba4.so) when I run my program | 08:21 |
| zyga-ubuntu | PhoenixMage: that I don't know, sorry, you need to ask a snapcraft developer for this | 08:21 |
| PhoenixMage | ok thanks | 08:21 |
| PhoenixMage | Anyone in channel a snapcraft dev? lol | 08:21 |
| zyga-ubuntu | yes but typically in US timezones | 08:22 |
| mvo | Chipaca: about disabling -buildmode=pie on i386 to workaround the panic, its 3738 | 08:23 |
| Chipaca | mvo: yes | 08:23 |
| PhoenixMage | thats ok, I am usually up pretty late, my boss is in the US | 08:23 |
| Chipaca | mvo: and spread fails with a weird error in the gccgo tests | 08:24 |
| Chipaca | mvo: coincidence? | 08:24 |
| mvo | Chipaca: probably | 08:25 |
| mvo | Chipaca: buildflags is cleaned when gccgo is used | 08:25 |
| mvo | Chipaca: so this should not affect anything, but let me look at the failure | 08:25 |
| Chipaca | mvo: http://pastebin.ubuntu.com/25324369/ | 08:26 |
| Chipaca | save you the lookin' | 08:26 |
| mvo | Chipaca: thanks! strange error | 08:28 |
| Chipaca | mvo: that's what she said! | 08:28 |
| Chipaca | :-) | 08:29 |
| mvo | Chipaca: double fun, the 2.27 version is green | 08:31 |
| Chipaca | mvo: hit that "AGAIN!" button and cross fingers | 08:32 |
| zyga-ubuntu | mvo: xenial moved to 2.26.10 | 08:35 |
| mvo | zyga-ubuntu: yay | 08:37 |
| zyga-ubuntu | mvo: "yay" but I'd make sure that update tests checked that version too | 08:38 |
| mwhudson | zyga-ubuntu, mvo: no armhf should be ok | 08:47 |
| mwhudson | zyga-ubuntu: and the "it's a hack" thing | 08:47 |
| mwhudson | zyga-ubuntu: well you know you can't access the instruction pointer directly in i386 right? | 08:47 |
| mwhudson | so whenever there is access to global data, which you want to do ip-relative | 08:48 |
| mwhudson | the go compiler inserts a call to a function that copies the return address (i.e. the callers' ip) into bx and uses that | 08:48 |
| mwhudson | the hack part is that it does this for _every_ access, there's no cleverness to avoid calling the stubs all the time | 08:49 |
| mwhudson | so it should work, just with large and slow code | 08:49 |
| mup | PR snapd#3733 closed: switch to canonical path for gopkg.in/cheggaaa/pb.v1 <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3733> | 08:49 |
| mwhudson | the crash is unexpected :/ | 08:49 |
| mvo | most crashes are ;) | 08:49 |
| mwhudson | mvo: this only happens in artful, not zesty etc? | 08:49 |
| mvo | mwhudson: I have only observed it with go 1.8 but AIUI only 1.8 has the extra checks in the garbage collector | 08:50 |
| mvo | mwhudson: that result in the panic | 08:50 |
| mup | PR snapd#3730 closed: tests: adding more debug information for the interfaces-cups-control … <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3730> | 08:50 |
| mvo | mwhudson: so I would assume its also there in older versions, just undetected | 08:50 |
| mwhudson | mmm | 08:51 |
| mwhudson | no i think those checks have been there for a while | 08:51 |
| mwhudson | i remember debugging them failing on ppc64 ages ago :) | 08:51 |
| mwhudson | at least similar checks anyway | 08:51 |
| mwhudson | ah hm no maybe you're right about this specific check is new | 08:52 |
| zyga-ubuntu | gary-wzl: hey | 08:52 |
| zyga-ubuntu | gary-wzl: comented on 3617 | 08:52 |
| zyga-ubuntu | mwhudson: yes, I know | 08:52 |
| mwhudson | mvo: in any case if you have a smaller test case than "all of snapd" it makes sense to report it upstream and i'll try to fix it | 08:53 |
| zyga-ubuntu | mwhudson: I see, so it's not a hack per se that it's all barely holding together, | 08:53 |
| zyga-ubuntu | mwhudson: more of a creative coding on your part | 08:53 |
| mvo | mwhudson: no smaller testcase yet unfortunately I can look some more for that. easy to reproduce with snapd though | 08:53 |
| zyga-ubuntu | mwhudson: and the true cause of the bug is still a mystery | 08:53 |
| mwhudson | zyga-ubuntu: yeah | 08:54 |
| mwhudson | mvo: i tried and failed to reproduce it in an artful 32 bit lxd container i had lying around, but maybe i was doing something silly | 08:54 |
| mwhudson | probably a vm is better | 08:54 |
| mvo | mwhudson: if you could quickly ack/nack https://github.com/snapcore/snapd/pull/3737 that would be great | 08:54 |
| mup | PR snapd#3737: debian: do not build with -buildmode=pie on i386 (2.27) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3737> | 08:54 |
| mvo | mwhudson: the sequence appears to be important: "sudo dpkg --purge snapd; apt install snapd; sudo snap install --beta core" and watch syslog to see the crash | 08:55 |
| mvo | mwhudson: for unknown reasons the system needs to be in a pristine state it seems | 08:55 |
| mwhudson | mvo: dpkg --print-architecture isn't really right is it? | 08:55 |
| mwhudson | mvo: surely you want dpkg-architecture -qDEB_TARGET_ARCH or something along those lines? | 08:56 |
| mvo | mwhudson: I also got some cannot unmarshal json errors when run later but that might be fallout from the earlier panic | 08:56 |
| mwhudson | ah i think i saw those ones | 08:56 |
| mvo | mwhudson: indeed, let me fix that, I was too quick | 08:56 |
| mwhudson | (the unmarshal json stuff) | 08:56 |
| mvo | mwhudson: yeah, I suspect its fallout, but hard to tell | 08:58 |
| mwhudson | mvo: commented on the PR | 08:58 |
| mvo | mwhudson: thanks, fixed | 09:01 |
| gary-wzl | zyga-ubuntu: Thanks! | 09:03 |
| zyga-ubuntu | gary-wzl: what you did is fine (existing sprintf vs replace) -- I just made a remark because this is so close to being exactly the same everywhere I think it is worth to pursue this goal | 09:19 |
| gary-wzl | zyga-ubuntu: I was thinking another PR would make more sense to isolate something unrelated to udev tagging rule. | 09:23 |
| zyga-ubuntu | gary-wzl: if you can, please | 09:25 |
| gary-wzl | zyga-ubuntu: yeah, working on that. We'll probably achieve a good results with smaller differ size on #3617 if I put it in that way | 09:26 |
| gary-wzl | Thanks for your comments | 09:26 |
| zyga-ubuntu | gary-wzl: thank you for the work so so much :) | 09:26 |
| * zyga-ubuntu -> offline for 30 min | 09:29 | |
| Chipaca | mvo: don't you have the logic in the makefile backwards | 09:33 |
| Chipaca | ah, no, += | 09:33 |
| Chipaca | ignore me :-) | 09:33 |
| Chipaca | +1 | 09:34 |
| zyga-ubuntu | = | 09:38 |
| zyga-ubuntu | }|}2~|"A | 09:38 |
| zyga-ubuntu | }|A2~" | 09:38 |
| zyga-ubuntu | adsf tr5fgr5tetfetfe45rf~~ju7777777777777777OH[24~ | 09:38 |
| pedronis | Chipaca: I nitpicked again, sorry | 09:39 |
| ogra | zyga-ubuntu, got a new cat ? | 09:39 |
| zyga-ubuntu | ogra: I was wiping dust off my keyboard | 09:39 |
| zyga-ubuntu | ogra: :) | 09:39 |
| ogra | :) | 09:39 |
| Chipaca | pedronis: sigh | 09:41 |
| Chipaca | pedronis: I think I'm going to move it in the followup pr | 09:41 |
| Chipaca | otherwise i'm going to spend my day waiting for it | 09:42 |
| pedronis | Chipaca: it's fine | 09:42 |
| mup | PR snapd#3739 opened: Add read access to virtual disk hard drives in udisk2 interface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3739> | 09:43 |
| pedronis | Chipaca: I mean, it's fine to do it in a follow up | 09:44 |
| pedronis | Chipaca: btw, I'm not picky where after "type ..." | 09:45 |
| Chipaca | mbuahaha | 09:45 |
| Chipaca | i mean, ok | 09:45 |
| * Chipaca puts it inside of Find | 09:46 | |
| pedronis | Chipaca: I said not picky, not careless :) | 09:46 |
| Chipaca | pedronis: aw :-D | 09:46 |
| pedronis | Chipaca: I mean , either just after type or all the method defs, as you prefer | 09:47 |
| * Chipaca nods | 09:47 | |
| Chipaca | pedronis: makes most sense to me to be right after type | 09:47 |
| mvo | zyga-ubu1tu: geh, test failure in autopkgtest because cmd_interfaces_test.go fails with the following diff: http://paste.ubuntu.com/25324625/ | 09:49 |
| mvo | zyga-ubu1tu: do you mind if I simply this test? | 09:49 |
| mvo | zyga-ubu1tu: something is doing line wrapping | 09:49 |
| mup | PR snapd#3724 closed: wrappers: symlink completion snippets when symlinking binaries <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3724> | 09:50 |
| Chipaca | mvo: the way i've addressed that kind of thing is by writing what I want so it's clearest, and then replacing all spaces with \s+ | 09:51 |
| === zyga-ubu1tu is now known as zyga-ubuntu | ||
| pedronis | Chipaca: are you doing the spread tests tweak for the symlinks also in a follow up? or you did it and I missed it | 09:52 |
| Chipaca | or was it with [ \t\n] | 09:52 |
| * Chipaca looks | 09:52 | |
| zyga-ubuntu | mvo: this is because go-flags changed | 09:52 |
| Chipaca | pedronis: i did it and you missed it :-) | 09:52 |
| zyga-ubuntu | mvo: do I mind if you simply _what_ this test? | 09:52 |
| zyga-ubuntu | mvo: (+1 to kill it) | 09:52 |
| ogra | cuddle | 09:52 |
| ogra | :) | 09:52 |
| mvo | zyga-ubuntu: heh, kill is one option :) | 09:52 |
| mvo | zyga-ubuntu: I was thinking about just doing contains and only checking for a subset | 09:53 |
| zyga-ubuntu | mvo: aha | 09:53 |
| zyga-ubuntu | mvo: that's fine as well | 09:53 |
| zyga-ubuntu | mvo: though I was actually hoping to kill it | 09:53 |
| pedronis | Chipaca: thx | 09:53 |
| zyga-ubuntu | the point of the test was to make sure it looks OK | 09:53 |
| mvo | zyga-ubuntu: let me kill it then, even better | 09:53 |
| zyga-ubuntu | and if we cannot eyeball it | 09:53 |
| zyga-ubuntu | then lets kill it | 09:53 |
| Chipaca | zyga-ubuntu: is there a commandline tool that looks at mountinfo? | 09:57 |
| mup | PR snapd#3740 opened: tests: remove TestInterfacesHelp as it breaks when go-flags changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/3740> | 09:57 |
| mup | PR snapd#3741 opened: tests: remove TestInterfacesHelp as it breaks when go-flags changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/3741> | 09:59 |
| mvo | zyga-ubuntu: I only know cat for this :/ | 10:00 |
| zyga-ubuntu | Chipaca: maybe | 10:00 |
| zyga-ubuntu | Chipaca: I know libmount handles stuff | 10:00 |
| zyga-ubuntu | Chipaca: if it has any CLI tools then yes | 10:00 |
| zyga-ubuntu | Chipaca: what do you neeD? | 10:00 |
| zyga-ubuntu | Chipaca: I wrote a mountinfo -> json tool | 10:00 |
| Chipaca | zyga-ubuntu: different question maybe: do you have nfs or autofs working anywhere? | 10:00 |
| zyga-ubuntu | Chipaca: never published it | 10:00 |
| zyga-ubuntu | Chipaca: no :/ | 10:00 |
| Chipaca | zyga-ubuntu: thinking about telling users "d'oh, your home is on the network, this ain't gonna fly" | 10:01 |
| mvo | zyga-ubuntu: 3740 for you | 10:01 |
| zyga-ubuntu | mvo: looking | 10:01 |
| zyga-ubuntu | aah | 10:01 |
| zyga-ubuntu | Chipaca: well, python is your friend, do you want this to be a standalone too | 10:01 |
| zyga-ubuntu | Chipaca: or baked into snap? | 10:01 |
| zyga-ubuntu | Chipaca: if latter I have all the libs ready | 10:02 |
| Chipaca | zyga-ubuntu: i was just playing with the idea, but it'd be best to have it in snap itself | 10:02 |
| Chipaca | e.g. make "snap run" print a warning | 10:02 |
| Chipaca | OTOH, one could argue that if we detect this, we could auto-workaround it | 10:03 |
| Chipaca | OTO²H that seems Hard, so maybe just include an easy-to-use thing that sets it up, non-automatically, and detect and alert if it's not used | 10:03 |
| zyga-ubuntu | Chipaca: mmmmmm | 10:04 |
| zyga-ubuntu | Chipaca: we might | 10:04 |
| Chipaca | yes | 10:04 |
| zyga-ubuntu | Chipaca: but it's per user | 10:04 |
| Chipaca | mmm indeeed | 10:04 |
| zyga-ubuntu | Chipaca: and then it's too late-ish | 10:04 |
| zyga-ubuntu | Chipaca: unless snap run would | 10:04 |
| zyga-ubuntu | Chipaca: and would poke snapd | 10:04 |
| Chipaca | zyga-ubuntu: yes, that's why in snap (as in, in snap run) | 10:04 |
| Chipaca | zyga-ubuntu: and detecting it should be outside of snapd | 10:04 |
| Chipaca | i mean, it's not snapd that needs to know this | 10:04 |
| Chipaca | it's snap-confine | 10:04 |
| Chipaca | right? | 10:04 |
| zyga-ubuntu | Chipaca: it's both | 10:05 |
| zyga-ubuntu | Chipaca: for home-on-nfs it requires at least three changes | 10:05 |
| zyga-ubuntu | Chipaca: snap-confine, snapd for each app and apparmor defaults for home location | 10:06 |
| * zyga-ubuntu -> coffee | 10:06 | |
| zyga-ubuntu | mvo: reviweed | 10:06 |
| * zyga-ubuntu debugs something hairy | 10:06 | |
| === ShalokShalom_ is now known as ShalokShalom | ||
| Chipaca | zyga-ubuntu: not seeing the snapd one | 10:07 |
| Chipaca | pedronis: you got the check move now because i'm a doofus :-) | 10:08 |
| zyga-ubuntu | mvo: hey | 10:08 |
| zyga-ubuntu | mvo: guess what | 10:08 |
| zyga-ubuntu | mvo: I have a patch for 2.27 | 10:08 |
| zyga-ubuntu | 3 lines | 10:08 |
| pedronis | Chipaca: because you had named params only in one place? or something else? | 10:09 |
| Chipaca | pedronis: src/github.com/snapcore/snapd/store/storetest/storetest.go:33: undefined: storetest in storetest.Store | 10:09 |
| pedronis | ah | 10:09 |
| Chipaca | hasty, hasty, hasty | 10:10 |
| pstolowski | mvo, hey, a comment to your testinterfaceshelp change | 10:10 |
| pedronis | persons aren't great compilers but compilers are | 10:10 |
| Chipaca | pedronis: I'm a great compiler | 10:11 |
| Chipaca | of useless facts | 10:11 |
| Chipaca | and dandruff | 10:11 |
| mup | PR snapd#3737 closed: debian: do not build with -buildmode=pie on i386 (2.27) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3737> | 10:12 |
| zyga-ubuntu | mvo: so please hold the line | 10:17 |
| zyga-ubuntu | (release) | 10:17 |
| mvo | zyga-ubuntu: ok | 10:17 |
| mvo | pstolowski: yeah, I think its fine to look at this for master, for 2.27 I'm keen to get it out | 10:18 |
| mvo | zyga-ubuntu: what is it about? | 10:18 |
| zyga-ubuntu | mvo: pushing | 10:19 |
| mup | PR snapd#3742 opened: interfaces: don't crash if content slot has no attributes <Created by zyga> <https://github.com/snapcore/snapd/pull/3742> | 10:20 |
| zyga-ubuntu | mvo: backport up as well | 10:21 |
| mup | PR snapd#3743 opened: interfaces: don't crash if content slot has no attributes (2.27) <Created by zyga> <https://github.com/snapcore/snapd/pull/3743> | 10:21 |
| mvo | zyga-ubuntu: ta | 10:22 |
| mvo | zyga-ubuntu: I was thinking, this diff rings a bell :) | 10:22 |
| zyga-ubuntu | yes | 10:23 |
| zyga-ubuntu | I feel so silly | 10:23 |
| zyga-ubuntu | sorry for not doing it months ago | 10:23 |
| mup | PR snapd#3743 closed: interfaces: don't crash if content slot has no attributes (2.27) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3743> | 10:24 |
| mvo | zyga-ubuntu: no worries | 10:25 |
| mvo | zyga-ubuntu: I run the criticial adt tests in artful/i386 now and when things are green will release 2.27.2 | 10:27 |
| zyga-ubuntu | ok | 10:28 |
| zyga-ubuntu | mvo: I'm digging at one more issue related to content | 10:28 |
| zyga-ubuntu | but no smoking gun yet | 10:28 |
| zyga-ubuntu | so +1 | 10:28 |
| pstolowski | mvo, fair enough | 10:28 |
| mvo | zyga-ubuntu: ok, adt will take a bit so that should be ok | 10:31 |
| mvo | zyga-ubuntu: 3743 seems to be unhappy in the unit tests, can you please checkout the branch and run the unit tests? | 10:34 |
| zyga-ubuntu | mvo: yes | 10:35 |
| zyga-ubuntu | hmm | 10:35 |
| mup | PR snapd#3740 closed: tests: remove TestInterfacesHelp as it breaks when go-flags changes (2.27) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3740> | 10:35 |
| zyga-ubuntu | darn | 10:36 |
| zyga-ubuntu | mvo: sorry | 10:36 |
| zyga-ubuntu | bad backport! | 10:36 |
| * Chipaca brb | 10:36 | |
| mvo | zyga-ubuntu: yeah, just do a followup I merged already as 2.27 is not blocked on spread and I did not notice :/ | 10:37 |
| zyga-ubuntu | ep | 10:37 |
| zyga-ubuntu | https://github.com/snapcore/snapd/pull/3744 | 10:38 |
| mup | PR snapd#3744: interfaces: correctly backport the patch <Created by zyga> <https://github.com/snapcore/snapd/pull/3744> | 10:38 |
| mup | PR snapd#3744 opened: interfaces: correctly backport the patch <Created by zyga> <https://github.com/snapcore/snapd/pull/3744> | 10:38 |
| zyga-ubuntu | seb128: hey | 10:39 |
| zyga-ubuntu | seb128: can you please look at https://forum.snapcraft.io/t/content-interface-connection-issues/1585/21 | 10:39 |
| mup | PR snapd#3744 closed: interfaces: correctly backport the patch <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3744> | 10:40 |
| seb128 | zyga-ubuntu, what bit? | 10:41 |
| zyga-ubuntu | seb128: I cannot reproduce the issue, can you check if my explanations makes sense | 10:41 |
| zyga-ubuntu | seb128: not sure if the real issue is the lack of auto-connect | 10:42 |
| zyga-ubuntu | seb128: or that at some time in the past the connection, even if made, did not really propagate | 10:42 |
| zyga-ubuntu | s/propagate/result in things working/ | 10:42 |
| mup | PR snapd#3745 opened: interfaces: convert uhid to common interface and test cases improvement for time_control and opengl <Created by adglkh> <https://github.com/snapcore/snapd/pull/3745> | 10:43 |
| === chihchun is now known as chihchun_afk | ||
| seb128 | zyga-ubuntu, btw the segfault seems a snap 2.27 regression | 10:50 |
| zyga-ubuntu | seb128: aha, I see, I think this will be fixed with 2.27.2 then | 10:50 |
| zyga-ubuntu | seb128: I'll try stable 2.26.14 now | 10:50 |
| zyga-ubuntu | mvo: is 2.27.2 in candidate? | 10:51 |
| seb128 | zyga-ubuntu, did you see https://forum.snapcraft.io/t/content-interface-connection-issues/1585/20 ? | 10:52 |
| seb128 | or rather my reply to that | 10:52 |
| seb128 | "Where can I find 2.26.14? xenial-proposed only has 2.26.10. | 10:52 |
| seb128 | I tried 2.27.1 from artful-proposed but gnome-calculator abort on start with that version, that seems a different issue/a regression but it blocks me from verifying the fix." | 10:52 |
| mvo | zyga-ubuntu: not even close :) its not even released yet, it will be in beta today | 10:52 |
| zyga-ubuntu | seb128: if you install snapd on ubuntu it re-execs from core snap | 10:52 |
| mvo | zyga-ubuntu: why? | 10:52 |
| zyga-ubuntu | seb128: so you will just get the latest stable this way | 10:53 |
| zyga-ubuntu | mvo: just wanted to check the regression is gone | 10:53 |
| zyga-ubuntu | seb128: snap version | 10:53 |
| seb128 | zyga-ubuntu, then the issue was not fixed in current stable | 10:53 |
| zyga-ubuntu | seb128: vs apt-cache policy snapd | 10:53 |
| seb128 | I confirmed the bug because uploading to 2.27 | 10:53 |
| zyga-ubuntu | seb128: ok, let me debug further | 10:53 |
| seb128 | zyga-ubuntu, the post I just gave had a testcase with gnome-calculator | 10:53 |
| seb128 | thanks | 10:53 |
| seb128 | zyga-ubuntu, is there any way to query snapd for the in-use version? | 10:53 |
| seb128 | snapd --version would be nice | 10:54 |
| zyga-ubuntu | snap version | 10:54 |
| zyga-ubuntu | that does both | 10:54 |
| zyga-ubuntu | it tells you client and server version | 10:54 |
| zyga-ubuntu | there's also a static file in /usr/lib/snapd/info | 10:54 |
| zyga-ubuntu | and similar one in the core snap | 10:54 |
| seb128 | oh, k, easy | 10:54 |
| seb128 | I tried -v | 10:54 |
| seb128 | and --version | 10:54 |
| zyga-ubuntu | ah, sorry about those | 10:55 |
| zyga-ubuntu | wow, 2.26.14 indeed behaves oddly | 10:55 |
| zyga-ubuntu | seb128: reproduced | 10:57 |
| mvo | zyga-ubuntu: is 2.27 behaving correctly? | 11:00 |
| zyga-ubuntu | mvo: so far yes, I wanted to check that thing where a syscall is denied (qt related) | 11:00 |
| zyga-ubuntu | seb128: ok, I think I got one thing wrong | 11:02 |
| zyga-ubuntu | 2.26.14 is still before the feature being enabled | 11:02 |
| zyga-ubuntu | I must have analyzed this incorrectly before | 11:02 |
| zyga-ubuntu | but running | 11:02 |
| zyga-ubuntu | zyga@fyke:/run/snapd/ns$ sudo /snap/core/current/usr/lib/snapd/snap-update-ns gnome-calculator | 11:02 |
| zyga-ubuntu | gives me | 11:02 |
| zyga-ubuntu | cannot update snap namespace: not implemented | 11:02 |
| zyga-ubuntu | which is before the feature went live | 11:02 |
| zyga-ubuntu | I think the extended release cycle for 2.26 has caused me to assume it would contain things that really only are in master | 11:03 |
| zyga-ubuntu | seb128: using 2.27.[12] shows this works | 11:03 |
| Chipaca | pedronis: question about locking of SnapManager: should I worry about holding a lock while accessing its attributes? | 11:04 |
| zyga-ubuntu | seb128: I updated the forum | 11:04 |
| Chipaca | pedronis: afaict everything is holding the state's lock right now, but i don't know if that's needed or incidental | 11:05 |
| zyga-ubuntu | gary-wzl: thanks, +1'd 3745 | 11:08 |
| zyga-ubuntu | mvo: when do we do 2.28? | 11:10 |
| zyga-ubuntu | I'd like to release master soon with the udev tagging bug fixed | 11:10 |
| zyga-ubuntu | as this is a major change | 11:11 |
| zyga-ubuntu | and we may get regressions for a long time | 11:11 |
| zyga-ubuntu | mvo: fedora hicckup again :/ | 11:12 |
| zyga-ubuntu | Error: Failed to synchronize cache for repo 'updates' | 11:12 |
| zyga-ubuntu | ++ dnf -q -y --refresh install libtool | 11:12 |
| * zyga-ubuntu got depressed at 13:13 | 11:13 | |
| zyga-ubuntu | so meta | 11:13 |
| zyga-ubuntu | on to reviews | 11:13 |
| Son_Goku | zyga-ubuntu: no updates doesn't mean that it won't install | 11:16 |
| Son_Goku | as long as fedora repodata was downloaded | 11:16 |
| Son_Goku | but something is seriously messed up with the Linode network for that to happen so often | 11:16 |
| zyga-ubuntu | Son_Goku: yeah, I was thinking the same thing | 11:17 |
| zyga-ubuntu | Son_Goku: I wonder if they have a mirror | 11:17 |
| zyga-ubuntu | I'll ssh-in and see | 11:17 |
| === JoshStrobl|zzz is now known as JoshStrobl | ||
| Son_Goku | if Linode is an official mirror, they may have set in Fedora MirrorManager to direct all traffic from their own nodes to their own mirror | 11:17 |
| jdstrand | mwhudson: hey/ re apparmor working> hello-world.evil (snap install hello-world) is a basic test | 11:17 |
| Son_Goku | I've done the same for my workplace with our registered mirror | 11:18 |
| jdstrand | mwhudson: hello-world.sh and poking around is another | 11:18 |
| Son_Goku | this is Fedora MirrorManager, btw: https://admin.fedoraproject.org/mirrormanager/ | 11:18 |
| Son_Goku | zyga-ubuntu: for example, if there was a Fedora mirror for Canonical (private or public), you can register it with mirrormanager and indicate what IP blocks should always be directed to your mirror | 11:19 |
| zyga-ubuntu | Son_Goku: well, I hope we don't need our own mirror :) | 11:21 |
| zyga-ubuntu | Son_Goku: I just want the cloud bits to work | 11:21 |
| Son_Goku | cloud never works :) | 11:21 |
| zyga-ubuntu | Son_Goku: may be linode bug | 11:21 |
| zyga-ubuntu | Son_Goku: may be something else, but it is too soon to tell | 11:22 |
| Chipaca | pstolowski: i'm seeing a weird thing where retry carries on retrying things after it's gotten something | 11:22 |
| Chipaca | pstolowski: have you seen that, or should I dig further? | 11:22 |
| Chipaca | anyway, right now i'm off to run and lunch | 11:23 |
| zyga-ubuntu | ... obtained time.Time = time.Time{sec:63638477897, nsec:23992430, loc:(*time.Location)(0x7d0500)} ("2017-08-16 10:58:17.02399243 +0000 UTC") | 11:25 |
| zyga-ubuntu | ... expected time.Time = time.Time{sec:63638477897, nsec:27992384, loc:(*time.Location)(0x7d0500)} ("2017-08-16 10:58:17.027992384 +0000 UTC") | 11:25 |
| zyga-ubuntu | mvo: did you notice this? | 11:25 |
| zyga-ubuntu | I see it for the 2nd time today | 11:25 |
| zyga-ubuntu | ... obtained time.Time = time.Time{sec:63638477897, nsec:23992430, loc:(*time.Location)(0x7d0500)} ("2017-08-16 10:58:17.02399243 +0000 UTC") | 11:25 |
| zyga-ubuntu | ... obtained time.Time = time.Time{sec:63638477897, nsec:23992430, loc:(*time.Location)(0x7d0500)} ("2017-08-16 10:58:17.02399243 +0000 UTC") | 11:25 |
| zyga-ubuntu | ... obtained time.Time = time.Time{sec:63638477897, nsec:23992430, loc:(*time.Location)(0x7d0500)} ("2017-08-16 10:58:17.02399243 +0000 UTC") | 11:25 |
| zyga-ubuntu | FAIL: picfg_test.go:124: piCfgSuite.TestConfigurePiConfigNoChangeSet | 11:25 |
| * zyga-ubuntu curses moronic copy-paste on linux | 11:26 | |
| zyga-ubuntu | anyway | 11:26 |
| zyga-ubuntu | mvo: go test -check.f piCfgSuite.TestConfigurePiConfigNoChangeSet -count 1000 | 11:27 |
| zyga-ubuntu | mvo: this fails on master | 11:27 |
| zyga-ubuntu | (reliably) | 11:27 |
| zyga-ubuntu | and that test seems to find real bug | 11:30 |
| zyga-ubuntu | mvo: I'll investigate | 11:31 |
| zyga-ubuntu | mvo: yes, it's a bug | 11:40 |
| zyga-ubuntu | mvo: around? I have a question | 11:42 |
| zyga-ubuntu | mvo: or if you can, a call (whatever you prefer) | 11:42 |
| zyga-ubuntu | mvo: I think the fix is trivial | 11:47 |
| === ikey|zzz is now known as ikey | ||
| Son_Goku | mvo, so where's snapd 2.27.2? | 11:53 |
| ogra | on vacation ... | 11:55 |
| ogra | should come home later today though .... | 11:55 |
| mvo | zyga-ubuntu: in a meeting right now | 11:55 |
| mvo | Son_Goku: almost ready :) | 11:55 |
| mvo | Son_Goku: after lunch (my lunch :) | 11:55 |
| Son_Goku | so... in an hour or so, eh? | 11:55 |
| pstolowski | Chipaca, no, I haven't seen this, do you have any logs? | 11:57 |
| mvo | Son_Goku: yes | 11:58 |
| mvo | Son_Goku: unless zyga-ubuntu comes along and finds yet another bug ;) | 11:58 |
| * Son_Goku glares at zyga-ubuntu | 11:58 | |
| ogra | you guys should really stop implementing all these bugs ... | 11:58 |
| ogra | ... implement features instead :) | 11:59 |
| pedronis | zyga-ubuntu: check.Equals and time are usually a bad idea, you need Time.Equal | 12:00 |
| zyga-ubuntu | pedronis: thanks but that test is just broken | 12:00 |
| zyga-ubuntu | pedronis: and we didn't notice because the comparison is flaky | 12:00 |
| zyga-ubuntu | pedronis: the bug is in the real code | 12:00 |
| zyga-ubuntu | (too) | 12:00 |
| zyga-ubuntu | mvo: | 12:04 |
| zyga-ubuntu | so, can you run zyga@fyke:~/go/src/github.com/snapcore/snapd/corecfg$ go test -count 1000 | 12:04 |
| zyga-ubuntu | not what happens | 12:04 |
| zyga-ubuntu | -count 1000 breaks the test | 12:04 |
| zyga-ubuntu | then I get | 12:04 |
| zyga-ubuntu | ... error string = "cannot run snapctl: snapctl: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory" | 12:04 |
| zyga-ubuntu | libpthread.so.0 | 12:04 |
| zyga-ubuntu | feels like another golang bug | 12:05 |
| zyga-ubuntu | this is around exec | 12:05 |
| zyga-ubuntu | Chipaca: ^ | 12:05 |
| zyga-ubuntu | mvo: https://github.com/snapcore/snapd/pull/3746 | 12:08 |
| mup | PR snapd#3746: corecfg: handle unknown keys that are explicitly set <Created by zyga> <https://github.com/snapcore/snapd/pull/3746> | 12:08 |
| zyga-ubuntu | I'll open a thread about the pthread bug | 12:08 |
| zyga-ubuntu | (ha ha) | 12:09 |
| mup | PR snapd#3746 opened: corecfg: handle unknown keys that are explicitly set <Created by zyga> <https://github.com/snapcore/snapd/pull/3746> | 12:09 |
| zyga-ubuntu | Chipaca: https://forum.snapcraft.io/t/corecfg-tests-crash-with-weird-pthread-bug-when-invoked-with-count-1000/1712 | 12:11 |
| * zyga-ubuntu tries to reproduce that now | 12:11 | |
| zyga-ubuntu | fg | 12:19 |
| Chipaca | zyga-ubuntu: kill $! | 12:20 |
| Chipaca | zyga-ubuntu: i'll take a look at the pthread thing | 12:20 |
| zyga-ubuntu | Chipaca: I'm looking too | 12:21 |
| zyga-ubuntu | Chipaca: it's curious | 12:21 |
| zyga-ubuntu | Chipaca: doesn't happen in a smaller test case yet | 12:21 |
| Chipaca | zyga-ubuntu: which benchmarks were you expecting this to run btw? | 12:23 |
| zyga-ubuntu | Chipaca: benchmarks? | 12:24 |
| zyga-ubuntu | Chipaca: so I ran a small test case that just does systemctl --version with -count 1000 | 12:24 |
| zyga-ubuntu | and that works | 12:24 |
| zyga-ubuntu | but the real test suite fails | 12:24 |
| zyga-ubuntu | I added almost everything back | 12:24 |
| zyga-ubuntu | and it still works | 12:24 |
| Chipaca | zyga-ubuntu: i'm not seeing anything about pthreads | 12:26 |
| Chipaca | ... error string = "cannot run snapctl: error: error running snapctl: invalid snap cookie requested" | 12:26 |
| Chipaca | ^ that's what i'm getting | 12:26 |
| zyga-ubuntu | yeah | 12:26 |
| zyga-ubuntu | there's something else broken | 12:26 |
| zyga-ubuntu | + mockSnapctl := testutil.MockCommand(c, "snapctl", "") | 12:26 |
| zyga-ubuntu | + defer mockSnapctl.Restore() | 12:26 |
| zyga-ubuntu | add this | 12:26 |
| zyga-ubuntu | the code _may_ run snapctl if the version query goes through | 12:26 |
| zyga-ubuntu | after adding it I see | 12:27 |
| zyga-ubuntu | FAIL: corecfg_test.go:46: coreCfgSuite.TestConfigureErrorOnMissingCoreSupport | 12:27 |
| zyga-ubuntu | corecfg_test.go:60: | 12:27 |
| zyga-ubuntu | c.Check(err, ErrorMatches, `(?m)cannot run systemctl - core-support interface seems disconnected: \[--version\] failed with exit status 1: simulate missing core-support`) | 12:27 |
| zyga-ubuntu | ... value = nil | 12:27 |
| zyga-ubuntu | ... regex string = "(?m)cannot run systemctl - core-support interface seems disconnected: \\[--version\\] failed with exit status 1: simulate missing core-support" | 12:27 |
| Chipaca | also these: | 12:27 |
| Chipaca | ... obtained time.Time = time.Time{sec:63638483255, nsec:193288244, loc:(*time.Location)(0x7d1520)} ("2017-08-16 13:27:35.193288244 +0100 BST") | 12:27 |
| zyga-ubuntu | ... Error value is nil | 12:27 |
| zyga-ubuntu | so, it's sitll racy and broken but | 12:27 |
| zyga-ubuntu | Chipaca: this is fixed by | 12:27 |
| zyga-ubuntu | https://github.com/snapcore/snapd/pull/3746 | 12:27 |
| mup | PR snapd#3746: corecfg: handle unknown keys that are explicitly set <Created by zyga> <https://github.com/snapcore/snapd/pull/3746> | 12:27 |
| zyga-ubuntu | so cherry pick that | 12:28 |
| zyga-ubuntu | e9f0f9be1cc64a61607b42ebad2d483aa08d61ae | 12:28 |
| Chipaca | zyga-ubuntu: what's this supposed to be testing, again? | 12:29 |
| Chipaca | zyga-ubuntu: note that this thing doesn't do Exec, it does Fork | 12:29 |
| zyga-ubuntu | Chipaca: which test case? | 12:29 |
| zyga-ubuntu | it does os.exec/Exec | 12:30 |
| Chipaca | zyga-ubuntu: there is no Exec in os.exec | 12:30 |
| Chipaca | zyga-ubuntu: there's syscall.Exec, which calls clone(2) which is where the issues were | 12:31 |
| zyga-ubuntu | ah, sorry, exec.Command | 12:32 |
| zyga-ubuntu | +1 | 12:32 |
| Chipaca | zyga-ubuntu: and then there's os/exec's Command, which has a Start (and a Run, that calls Start), that call os.StartProcess, that call syscall.StartProcess, that calls forkExec, that does the necessary stuff | 12:33 |
| zyga-ubuntu | https://github.com/zyga/snapd/tree/wtf/weird-bug | 12:33 |
| zyga-ubuntu | Chipaca: inside that branch run | 12:34 |
| zyga-ubuntu | zyga@fyke:~/go/src/github.com/snapcore/snapd/corecfg$ go test | 12:34 |
| zyga-ubuntu | and compare that to | 12:34 |
| zyga-ubuntu | zyga@fyke:~/go/src/github.com/snapcore/snapd/corecfg$ go test -count 1000 | 12:34 |
| zyga-ubuntu | that shows the issue | 12:34 |
| zyga-ubuntu | AFAIK -count is not concurrent | 12:34 |
| zyga-ubuntu | Chipaca: I updated the forum post | 12:36 |
| Chipaca | zyga-ubuntu: ... error string = "cannot run snapctl: should never call snapctl" | 12:38 |
| mup | PR snapd#3738 closed: debian: do not build with -buildmode=pie on i386 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3738> | 12:41 |
| seb128 | zyga-ubuntu, mvo, when are xenial users going to get 2.27? | 12:42 |
| mvo | seb128: I just uploaded 2.27.2 to xenial-proposed. the 2.27 release had a regression for some Qt systems | 12:43 |
| mup | PR snapd#3742 closed: interfaces: don't crash if content slot has no attributes <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3742> | 12:43 |
| seb128 | mvo, gnome-calculator segfaults on 2.27.1 btw | 12:43 |
| seb128 | and it doesn't use qt :p | 12:43 |
| mvo | seb128: does edge also segfault? | 12:44 |
| mvo | seb128: what do I need to do to reproduce? | 12:44 |
| seb128 | mvo, I think zyga said it should be fixed in .2 so don't waste time on it | 12:44 |
| seb128 | I can test and let you know | 12:44 |
| mvo | seb128: I'm building 2.27.2 in the beta channel as we speak | 12:44 |
| seb128 | mvo, I'm too old school to understand you, just going to wait for the artful debs | 12:45 |
| seb128 | which is how I tested 2.27.1 :p | 12:45 |
| mvo | seb128: *pffff* ;) | 12:46 |
| * mvo hugs seb128 | 12:46 | |
| * seb128 hugs mvo back | 12:46 | |
| mvo | seb128: artful debs are also uploaded, if you follow -proposed things should be available RSN | 12:46 |
| seb128 | mvo, I don't play with channel but I'm afraid to end up on a situation where I put myself on a beta channel for good when I just wanted to test a specific version and then go back to normal default behaviour | 12:46 |
| seb128 | good | 12:46 |
| seb128 | it's already confusing me enough that the snapd process version doesn't match the snapd deb I've installed :p | 12:47 |
| Chipaca | zyga-ubuntu: what's the environment in which you were getting the pthread thing? | 12:49 |
| zyga-ubuntu | re | 12:49 |
| zyga-ubuntu | seb128, mvo: I didn't test .2 | 12:49 |
| zyga-ubuntu | Chipaca: xenial | 12:49 |
| zyga-ubuntu | amd64 | 12:49 |
| seb128 | zyga-ubuntu, you confirmed the issue in .1 and the fix in .2 then? | 12:50 |
| zyga-ubuntu | seb128: I was focusing on the content issue | 12:50 |
| zyga-ubuntu | seb128: and it looked unrelated | 12:50 |
| Chipaca | zyga-ubuntu: are you reexec'ing? | 12:50 |
| zyga-ubuntu | seb128: I can check .2 | 12:50 |
| zyga-ubuntu | Chipaca: in the test? | 12:50 |
| Chipaca | zyga-ubuntu: yes | 12:50 |
| ogra | seb128, try yourself ... switching to edge (and back) is so trivial and safe | 12:51 |
| zyga-ubuntu | Chipaca: there's nothing to reexec there but I think I was | 12:51 |
| Chipaca | zyga-ubuntu: doesn't snapctl try to reexec? | 12:51 |
| zyga-ubuntu | seb128: and if not we'll airlift ogra to fix your machine | 12:51 |
| seb128 | ogra, is that documented somewhere? | 12:51 |
| ogra | seb128, snap refersh --edge core ... test ... snap refresh --stable core | 12:51 |
| ogra | there ... now it is :P | 12:51 |
| seb128 | ogra, you can't expect users to know that | 12:51 |
| ogra | (modulo typos :P ) | 12:51 |
| seb128 | so the question still stands | 12:52 |
| Chipaca | ogra: that's in the wrong orange! let me file a bug | 12:52 |
| Chipaca | seb128: you can't expect to tell users to try edge either | 12:52 |
| ogra | Chipaca, i only support peaches ! | 12:52 |
| Chipaca | edge _will_ ruin your holidays periodically | 12:52 |
| seb128 | Chipaca, well that's what I'm being asked to do because I've a snap that segfaults since the snapd update | 12:52 |
| ogra | seb128, it is surely documented somewhere on snapcraft.io ... | 12:52 |
| ogra | (but i use it for so long already that i dont know where) | 12:52 |
| Chipaca | seb128: asking you to do it is not the same as expecting you to do it unprompted | 12:53 |
| zyga-ubuntu | Chipaca: snapctl should *never* run in either case | 12:53 |
| zyga-ubuntu | Chipaca: the code bails out earlier | 12:53 |
| willdeberry | morning all. trying to solve a problem without being forced into a classic confinemet. I have a python bluetooth CLI tool and am getting the following when I try and run it from a snap: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Failed to connect to socket /var/run/dbus/system_bus_socket: Permission denied | 12:53 |
| zyga-ubuntu | Chipaca: not sure if snapctl re-execs but I assume so | 12:53 |
| seb128 | anyway, not a argument I'm interested to have | 12:53 |
| Chipaca | zyga-ubuntu: do you still get the pthread thing? | 12:53 |
| willdeberry | I have tried the following plugs without any success: bluetooth-control, network, network-contorl, network-manager | 12:53 |
| zyga-ubuntu | willdeberry: are they connected? | 12:53 |
| seb128 | I'm going to wait for the deb to be there to see if snapd stopped segfaulting my apps | 12:53 |
| popey | hi willdeberry | 12:54 |
| zyga-ubuntu | Chipaca: yes, I can show you during the call | 12:54 |
| ogra | willdeberry, there is a dbus interface too ... | 12:54 |
| zyga-ubuntu | let me order coffee & cake | 12:54 |
| zyga-ubuntu | and I'll join | 12:54 |
| willdeberry | zyga-ubuntu: i tried manually connecting them and had no change | 12:54 |
| willdeberry | hello popey, thanks for the reply on twitter | 12:54 |
| mvo | seb128: what do I need to do to verify the error? | 12:54 |
| mvo | seb128: is snap install gnome-calulator enough? | 12:54 |
| willdeberry | ogra: the docs for the dbus interface seem to point to only need if i am exposing dbus bus/methods though | 12:55 |
| koza | willdeberry, what kind of bus your script is using? if OBEX then this is a known issue | 12:55 |
| mvo | seb128: also, why does this comes up 1min *after* I tagged 2.27.2 :/ | 12:55 |
| mvo | seb128: (not your fault I know, just bad timing) | 12:55 |
| willdeberry | koza: just using dbus to interact with the local bluetooth on the system | 12:55 |
| seb128 | mvo, because you don't read the forum? | 12:55 |
| Chipaca | seb128: that's a bit harsh | 12:56 |
| seb128 | mvo, I mentioned it on https://forum.snapcraft.io/t/content-interface-connection-issues/1585 some days ago | 12:56 |
| seb128 | Chipaca, that's the reality though | 12:56 |
| willdeberry | popey: I am still occastionally seeing the syntax error you opened an issue report on github about too. snapcraft will give me a working build and the very next will have the error again. even if nothing change in the master branch of code | 12:56 |
| ogra | seb128, i do read the forum (like all day) and didnt know about it | 12:56 |
| seb128 | Chipaca, and I'm not even speaking about launchpad bugs | 12:56 |
| koza | willdeberry, could you pastebin snapcraft.yaml, $ snap list <yoursnap> | 12:56 |
| popey | willdeberry: huh, that's strange! | 12:56 |
| seb128 | ogra, well on that url ^ | 12:57 |
| seb128 | "Where can I find 2.26.14? xenial-proposed only has 2.26.10. | 12:57 |
| seb128 | I tried 2.27.1 from artful-proposed but gnome-calculator abort on start with that version, that seems a different issue/a regression but it blocks me from verifying the fix." | 12:57 |
| mvo | seb128: aha, so its not a 2.27 regression? | 12:57 |
| mvo | seb128: oh, it is | 12:57 |
| seb128 | mvo, it is | 12:57 |
| mvo | seb128: meh | 12:57 |
| koza | willdeberry, i mean $ snap interfaces <yoursnap> | 12:57 |
| ogra | seb128, if it is 2.27 specific i'D have expected a comment on https://forum.snapcraft.io/t/in-progress-snapd-2-27-1/572 where blockers are collected | 12:57 |
| seb128 | mvo, but basically | 12:58 |
| seb128 | $ snap install gnome-3-24 | 12:58 |
| seb128 | $ snap install gnome-calculator | 12:58 |
| seb128 | $ snap connect gnome-calculator:gnome-3-24-platform gnome-3-24:gnome-3-24-platform | 12:58 |
| seb128 | $ snap run gnome-calculator | 12:58 |
| seb128 | mvo, that works in 2.26 and segfault in 2.27.1 | 12:58 |
| seb128 | ogra, your workflow would have to be documented for people to know that | 12:58 |
| willdeberry | koza: so had to install it on another machine to be able to test/work with yall while I am work. Reconnected all the interfaces on this new machine and noticed a slight variance in the AccessDenied message: An AppArmor policy prevents this sender from sending this message to this recipient | 12:58 |
| seb128 | ogra, or launchpad bugs to be look at | 12:59 |
| ogra | seb128, it isnt *my workflow* (note i'm not in the snapd team ... it is simply what i grok from reading the forum as a non team member | 12:59 |
| willdeberry | koza: https://pastebin.com/vqaxnDfe | 12:59 |
| seb128 | anyway I've no interest in arguing more | 13:00 |
| ogra | if there is a thread about preparing a release, i dump my blockers in there ... or at least a link to the thread about my blockers ... thats more common sense than anything else | 13:00 |
| popey | seb128: interestingly that works in 2.27 on solus (I don't have 2.27.1 or .2 there) | 13:00 |
| seb128 | to me launchpad is the place to file bugs | 13:00 |
| ogra | thats fine | 13:00 |
| koza | willdeberry, try "Debugging Confined Apps" section from https://snapcraft.io/docs/build-snaps/debugging to get better understanding of how to fix it. | 13:00 |
| ogra | just link them where the communication about the release happens ;) | 13:00 |
| willdeberry | koza: I will go through that, ty. devmode definitely works, but honestly not surprised by that | 13:01 |
| seb128 | ogra, I don't know about that place or special workflow | 13:01 |
| seb128 | anyway enough arguing | 13:01 |
| ogra | seb128, because you dont read the forum ? | 13:01 |
| seb128 | good afternoon to you snappy people :-) | 13:01 |
| * ogra grins | 13:01 | |
| * seb128 goes back to do work | 13:01 | |
| seb128 | ogra, indeed not, why would I? I file my bugs in launchpad, if that's the wrong place then bugfiling should be closed on the snapd component | 13:02 |
| mvo | seb128: does not segfault for me | 13:03 |
| mvo | seb128: with 2.27.2 | 13:03 |
| ogra | your bugs are fine in launchpad ... but if you see a blocker you consider urgent, trusting that someone sees your bug in time might not be the best way | 13:03 |
| seb128 | mvo,good then it's fixed, thanks for testing! | 13:03 |
| seb128 | ogra, well then we have an issue | 13:03 |
| seb128 | ogra, if the team wants to know about issue they should look at the bug tracker | 13:03 |
| koza | willdeberry, don't you have bluez snap installed? | 13:03 |
| ogra | well, if you look at the thread there are plenty of people reporting blockers ... | 13:03 |
| ogra | sure, and that happens ... | 13:04 |
| willdeberry | koza: no. i installed bluez via apt | 13:05 |
| ogra | still, if you want quick attention for something you consider urgent, you obviously come to IRC to block the release ... you could as well go to the forum ... | 13:05 |
| mvo | seb128: hopefully :) | 13:05 |
| koza | willdeberry, also see in the logs (journalctl) what is the exact thing that you try to access that gets denied; will help in understanding what is your issue | 13:05 |
| koza | willdeberry, oh, try snap :) | 13:06 |
| willdeberry | i assume i should prune the system version before? | 13:06 |
| ogra | ... this is totally independent from LP bugs | 13:07 |
| jdstrand | mwhudson: I responded extensively in the forum (https://forum.snapcraft.io/t/snapd-vs-upstream-kernel-vs-apparmor/1704/2) | 13:07 |
| koza | willdeberry, yes | 13:08 |
| ikey | hm no tagged releases of snapd-xdg-open | 13:26 |
| ogra | just use master | 13:27 |
| ogra | i doubt it will change, given it is being replaced eventually | 13:28 |
| ikey | so then why wouldnt it be tagged? :P | 13:28 |
| ikey | come on basic sw dev here lol | 13:28 |
| ogra | https://github.com/snapcore/snapd-xdg-open/blob/master/debian/changelog ... | 13:29 |
| ogra | version is 0.0.0 | 13:29 |
| ogra | ;) | 13:29 |
| ikey | so why am i being told to package it then?> | 13:29 |
| ogra | ogra@styx:~$ dpkg -l |grep snapd-xdg-open | 13:30 |
| ogra | ii snapd-xdg-open 0.0.0~16.04 amd64 Opens URLs via D-Bus | 13:30 |
| ikey | i mean i get that snaps let you play it loose with basic software practices but for something that needs to be packaged ... and is in git ... | 13:30 |
| ikey | should have tags and distcheck tarballs | 13:30 |
| ikey | sorry to say it but git aint launchpad | 13:30 |
| ogra | ikey, it is a hack that is going away and that was initially only released as source deb | 13:30 |
| ogra | but if you want opening of links in snap to work right now, you want it installed on a desktop ... | 13:31 |
| ikey | right so you know this limitation - thus snapd-xdg-open is currently needed, and should be tagged | 13:31 |
| ikey | because its a runtime requirement | 13:31 |
| ogra | (note we do not pre-install it in ubuntu either, but it is available for users) | 13:32 |
| ogra | (though due to apt bugs ... ) | 13:32 |
| ikey | heh | 13:32 |
| ogra | or rather due to mis-behaviour of apt-get that is fixed in apt (without -get) | 13:32 |
| ogra | sadly people on 16.04 still use the old apt-get typically | 13:33 |
| Son_Goku | I'm super annoyed about snapd-xdg-open | 13:37 |
| Son_Goku | ikey: I've been told repeatedly to *not* package it | 13:37 |
| ogra | so speed up snapd userd | 13:38 |
| Son_Goku | because they're going to break it real-soon-now | 13:38 |
| ogra | we're not breaking it | 13:38 |
| ogra | snapd will include something that replaces it eventually | 13:38 |
| Son_Goku | morphis_: then we should just get snapd-xdg-open in asap: https://bugzilla.redhat.com/show_bug.cgi?id=1369560 | 13:39 |
| ogra | https://github.com/snapcore/snapd/pull/3260 | 13:39 |
| mup | PR snapd#3260: cmd/snap: implement userd command as replacement for snapd-xdg-open <Created by morphis> <https://github.com/snapcore/snapd/pull/3260> | 13:39 |
| ogra | thats the PR | 13:39 |
| Son_Goku | or you know, fuck it | 13:39 |
| Son_Goku | I could just backport that | 13:39 |
| willdeberry | koza: new error: https://pastebin.com/wGUb06R1, current interfaces: https://pastebin.com/scMJD25G | 13:40 |
| popey | willdeberry: is it installed in -devmode? | 13:42 |
| willdeberry | not currently. using latest edge | 13:43 |
| willdeberry | popey: devmode worked right out of the box with the system based bluetooth stack | 13:44 |
| willdeberry | i have a feeling classic would work too, but i hate jumping to that to just solve the problem until i know that is the only way | 13:44 |
| popey | worth testing with your snap in devmode | 13:44 |
| popey | best to test with devmode first | 13:44 |
| ogra | the bluetooth stack in use shouldnt make any difference | 13:45 |
| mvo | seb128: snapd 2.27.2 is now in artful-proposed | 13:46 |
| mvo | seb128: according to LP anyway | 13:46 |
| mup | PR snapd#3747 opened: Merge release 2.27.2 back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/3747> | 13:50 |
| popey | mvo: will 2.27.2 be the one that goes to stable - so 16.04 users will get it at some point via core? | 13:52 |
| zyga-ubuntu | re | 13:52 |
| zyga-ubuntu | niemeyer: https://github.com/snapcore/snapd/pull/3621 | 13:52 |
| mup | PR snapd#3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621> | 13:52 |
| zyga-ubuntu | irssi got stuck on the wifi here | 13:52 |
| koza | willdeberry, there is no bluetooth interface connected | 13:53 |
| mup | PR snapd#3520 closed: asserts: add store assertion type <Created by atomatt> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3520> | 13:54 |
| oSoMoN | mvo, I've been talking to willcooke and kenvandine and it seems the agreement is to create a new "desktop team" shared account for the store for snaps officially supported by the desktop team | 13:56 |
| oSoMoN | niemeyer wants this to be documented as a wiki doc on the forum (does that need to be owned by the wiki user btw?), let's work out the details of that shared account and create the doc then | 13:57 |
| kenvandine | +1 | 13:58 |
| kenvandine | lets name it ubuntu-desktop | 13:58 |
| willdeberry | koza: bjarkan (my snap) is connected to bluetooth-control interface. that's the only bluetooth interface i see | 13:59 |
| oSoMoN | mvo, what would you need to create that shared account? can it be associated to ~canonical-desktop-team/~ubuntu-desktop ? | 13:59 |
| ogra | oSoMoN, i think thats store territory (i doubt mvo can create it) | 14:00 |
| ogra | iirc they created the shared canonical account too | 14:00 |
| oSoMoN | ogra, who should I talk to? | 14:01 |
| ogra | nessita, perhaps | 14:01 |
| ogra | though this is likely not actually a "shared account" but simply the owner of the snaps ... actual sharing happens then via the "collaboration" setting in the sotre | 14:02 |
| ogra | *store | 14:02 |
| ogra | (where you simply add all the uploaders on a per-snap basis) | 14:02 |
| koza | willdeberry, sorry I have meant "bluez" interface. You need it as bluetooth_control gives you only a control over kernel-side of BT stack and this is not what you want to use here. bluez snap will make it appear. | 14:03 |
| ogra | koza, any idea why that isnt there ? on a classic install this should simply connect you to the deb based bluez stack | 14:04 |
| * ogra notes he doesnt see bluez here either on his desktop | 14:04 | |
| ogra | sounds like a bug | 14:04 |
| oSoMoN | ok, so we still need an owner account for those snaps officially supported by the desktop team | 14:04 |
| ogra | right | 14:04 |
| oSoMoN | nessita, can you create such an account for us? | 14:04 |
| ogra | and then yoou "collaborate" pre-snap with all the desktop people | 14:04 |
| ogra | *per-snap | 14:05 |
| koza | ogra, no idea | 14:05 |
| koza | ogra, might be a good candidate for a bug report | 14:05 |
| willdeberry | popey: devmode works, even without any interfaces connected | 14:05 |
| willdeberry | koza: I even installed bluez snap package and the only interface that provides is bluez:service. I don't see :bluez listed as a slot | 14:06 |
| koza | willdeberry, yes devmode will work obviously | 14:07 |
| zyga-ubuntu | https://lwn.net/Articles/731121/ | 14:07 |
| zyga-ubuntu | Headline features include support for the Snap packaging format | 14:08 |
| zyga-ubuntu | ^_^ | 14:08 |
| zyga-ubuntu | ikey: you hit lwn | 14:08 |
| ogra | zyga-ubuntu, https://www.heise.de/newsticker/meldung/Linux-Distribution-Solus-3-bringt-Unterstuetzung-fuer-Snap-Pakete-3801856.html | 14:09 |
| ogra | even made the german news ;) | 14:09 |
| ikey | yeah cbmuser is ranting in the comment section | 14:09 |
| ikey | because reddit made it clear they're sick of his crap | 14:10 |
| ogra | (i must say thats really impressive for a one man show) | 14:10 |
| ikey | its not a one man show | 14:10 |
| koza | willdeberry, you on classic on core? | 14:10 |
| nessita | oSoMoN, hi! could you summary what you need? | 14:10 |
| willdeberry | koza: i agree, but popey wanted confirmation, so i just wanted to validate that again | 14:10 |
| willdeberry | koza: i am on classic, 16.04 | 14:10 |
| ogra | ikey, well ... mostly ... no ? | 14:10 |
| ikey | no | 14:10 |
| ogra | ok :) | 14:10 |
| kenvandine | oh, so we need to add individuals per snap, that's not ideal | 14:11 |
| ikey | so core team is myself, JoshStrobl, datadrake (bryan), cybre (stefan), justin, sunnyflunk (peter) | 14:11 |
| zyga-ubuntu | ogra: nice! | 14:11 |
| ikey | community are also very much involved by way of patches too ogra https://dev.solus-project.com/differential/ | 14:11 |
| ikey | we have a very open development process | 14:11 |
| oSoMoN | nessita, the desktop team needs a store account that will be used for snaps it officially supports | 14:12 |
| ogra | oh, wow, i didnt know | 14:12 |
| oSoMoN | nessita, through the collaboration feature, i.e. several people on the team will actually upload/maintain the snaps | 14:12 |
| ogra | (about the team ... i see the dev process ... :) ) | 14:12 |
| ikey | the changelog lists a bunch of different names https://solus-project.com/2017/08/15/solus-3-released/ | 14:12 |
| ikey | and thats only gen'd for the budgie iso | 14:12 |
| ikey | i.e. whats in the ISO, not the repos, or the gnome or mate isos | 14:12 |
| ikey | bigger project than people think :) | 14:13 |
| ikey | im most visible because im the first full time and the one with the biggest mouth | 14:13 |
| ogra | heh | 14:13 |
| nessita | oSoMoN, what username/visible name would this account have? | 14:15 |
| nessita | oSoMoN, for example, the base shared account is "canonical", would this be "canonical-desktop" or something else? | 14:15 |
| oSoMoN | nessita, kenvandine was suggesting ubuntu-desktop, which sounds good to me | 14:16 |
| kenvandine | yeah | 14:16 |
| kenvandine | ubuntu-desktop | 14:16 |
| kenvandine | that's our usual | 14:16 |
| popey | Hang on. | 14:16 |
| popey | If I am installing chromium on solus, it's a desktop app surely? | 14:17 |
| nessita | kenvandine, is the name available in LP? | 14:17 |
| * nessita checks | 14:17 | |
| popey | Not an UBuntu Desktop app | 14:17 |
| oSoMoN | true | 14:17 |
| kenvandine | nessita, that already exists on LP | 14:17 |
| ikey | It wont launch without being installed as --devmode, fwiw | 14:17 |
| nessita | kenvandine, hum is a team so we can't use the name | 14:17 |
| ikey | well. it launches. and locks forever | 14:17 |
| kenvandine | bummer | 14:17 |
| kenvandine | what we really want is a team for the store :) | 14:17 |
| nessita | kenvandine, let me think, one sec | 14:17 |
| koza | willdeberry, the bluez interface can be provided only by the app (the bluez snap in this case). it is not implicit on both core and classic which means you need to have the snap installed for it to appear. could you install it and list interfaces? | 14:18 |
| nessita | kenvandine, yeah but we don't have teams in the store (this is intentional) | 14:18 |
| kenvandine | yeah | 14:18 |
| popey | be good not to have a name which confuses people who don't use ubuntu | 14:18 |
| oSoMoN | popey, the idea was that owner reflects who maintains the snaps, in that case the ubuntu desktop team | 14:18 |
| zyga-ubuntu | ikey: what doesn't work? | 14:18 |
| oSoMoN | but I agree, it could cause confusion | 14:18 |
| kenvandine | nessita, could the account we use collaborate with ~ubuntu-desktop in LP? | 14:18 |
| ikey | zyga-ubuntu, chromium, was replying to popey | 14:18 |
| kenvandine | to allow anyone in ~ubuntu-desktop to upload? | 14:18 |
| zyga-ubuntu | ikey: aha | 14:18 |
| nessita | kenvandine, no, there are no links to LP teams in the store | 14:18 |
| zyga-ubuntu | ikey: any denials/seccomp things in syslog? | 14:19 |
| kenvandine | ok | 14:19 |
| popey | what's the rationale for it not being under the 'canonical' account? | 14:19 |
| nessita | popey, I sort of agree with you but I think there is a forum post about this, let me check | 14:19 |
| ikey | zyga-ubuntu, ya on the thread | 14:19 |
| kenvandine | yeah | 14:19 |
| kenvandine | there is | 14:19 |
| oSoMoN | too generic I think, we want a clearer separation of what the team maintains | 14:19 |
| popey | "we"? | 14:20 |
| kenvandine | and we might allow community members of the ubuntu-desktop team to help | 14:20 |
| ogra | well, so i cant install it on fedora because it comes from ubuntu-desktop ? | 14:20 |
| nessita | oSoMoN, note that the concept of "team" does not apply in the store | 14:20 |
| popey | thats what the collaboration feature is for, surely? | 14:20 |
| ev | yeah, I'm also curious about why we wouldn't use 'canonical' | 14:20 |
| ev | If Canonical is putting someone on maintaining a snap, surely they should show up as the vendor, no? | 14:20 |
| nessita | kenvandine, do you have the forum post handy? I can't find it | 14:20 |
| popey | Sorry to throw a spanner in the works here, it's just that a) naming things is hard, and b) I don't want us to name something that the store people are gonna have to rename later | 14:21 |
| zyga-ubuntu | ev: I think niemeyer described this somewhere | 14:21 |
| kenvandine | https://forum.snapcraft.io/t/which-snaps-should-be-supported-by-canonical | 14:21 |
| willdeberry | koza: that's what this link was: https://pastebin.com/scMJD25G | 14:21 |
| nessita | that one! | 14:21 |
| oSoMoN | all very good points, now I'm not so sure any longer about that new account :) | 14:21 |
| zyga-ubuntu | mvo: is a tarball up? | 14:21 |
| mup | PR snapd#3735 closed: many tests: move all panicing fake store methods to a common place <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3735> | 14:22 |
| zyga-ubuntu | mvo: or ... are you done with the release? | 14:22 |
| mvo | zyga-ubuntu: tarball up, all done | 14:22 |
| mvo | zyga-ubuntu: 2.27.2 is in beta now | 14:22 |
| koza | willdeberry, do you have snapcraft.yamls as well? | 14:22 |
| zyga-ubuntu | mvo: thank yu! | 14:22 |
| willdeberry | koza: https://github.com/willdeberry/bjarkan/blob/master/snap/snapcraft.yaml | 14:23 |
| mvo | zyga-ubuntu: thank you for all your help with it! | 14:23 |
| nessita | kenvandine, oSoMoN the forum topic seems to be waiting for more answers from niemeyer, do you think you can continue the conversation there to reach an agreement? | 14:24 |
| nessita | ev, popey do you agree? ^ | 14:24 |
| popey | I only see a suggestion to use Ubuntu, but no reason why? | 14:24 |
| nessita | kenvandine, ie niemeyer is waiting from feedback from you :-) | 14:24 |
| kenvandine | nessita, further up in the post i think there was some agreement to this and he asked for a wiki post to document our support | 14:24 |
| ev | I got the opposite take. It sounds like Gustavo is okay with 'canonical' if and only if the "process surrounding the snap" is documented | 14:24 |
| popey | I mean, internally it's nice to know who is responsible for a snap. But externally, users don't care, they just want the safety that Canonical are caring for these pacakges, not which team or developer, surely? | 14:25 |
| nessita | ev, from https://forum.snapcraft.io/t/which-snaps-should-be-supported-by-canonical/1064/9 it feels like gustavo is not sure | 14:25 |
| ev | what he seems to be rightly concerned about are snaps written by individuals inside Canonical, with no intention of providing full time support, being published under the canonical account | 14:25 |
| kenvandine | ev, yeah, i think he basically agreed to a shared account like canonical if we documented it | 14:26 |
| ev | nessita: I took that as "not sure about ubuntu vs canonical" for the name | 14:26 |
| kenvandine | it just raised other ideas | 14:26 |
| niemeyer | nessita, ev: I think you're both in agreement.. | 14:26 |
| nessita | ev, yeah me too | 14:26 |
| ev | ha! | 14:26 |
| nessita | :-) | 14:26 |
| ev | hi Gustavo | 14:26 |
| kenvandine | hey niemeyer! | 14:26 |
| niemeyer | Heya :) | 14:26 |
| nessita | kenvandine, I don't think the proposal is " a shared account like canonical", but "the canonical shared account", which is different :-) | 14:26 |
| koza | willdeberry, as a reference check the "bluetoothctl" app from bluez snap which basically does exactly the same thing as the script you want to snap. https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/bluez/tree/snapcraft.yaml#n18 | 14:27 |
| kenvandine | i think the benefit of using ubuntu is we could give access to community members of the desktop team | 14:27 |
| kenvandine | to some snaps, perhaps | 14:27 |
| kenvandine | and it wouldn't feel wrong | 14:27 |
| kenvandine | for example we have community members in ~ubuntu-desktop for LP, so similar concept | 14:27 |
| niemeyer | All we need is that place describing what was mentioned in the forum message.. this can be a message in the forum even, which makes it visible and nice to maintain and comment on | 14:27 |
| nessita | kenvandine, but is gedit from ubuntu supposed to be installable in fedora (as a snap)? | 14:27 |
| kenvandine | the desktop team would be committed to maintenance, but we do have non-canonical members of the desktop team | 14:28 |
| kenvandine | nessita, that's another whole thread :) | 14:28 |
| oSoMoN | niemeyer, how do we make a forum post easily editable by several contributors (wiki-style)? | 14:28 |
| popey | kenvandine: The store supports collaborators on snaps. You could invite individuals to help that way? | 14:28 |
| koza | willdeberry, there is also not yet stable snap that packages a script which uses bluez interface. you can check it out too https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/bluez-tests/tree/snapcraft.yaml | 14:28 |
| kenvandine | popey, yup | 14:28 |
| nessita | kenvandine, my point being that if gedit (or whichever snap) is meant to be used in other distros, then having publisher ubuntu is not accurate I think | 14:29 |
| niemeyer | oSoMoN: A moderator just needs to make it so.. I can easily do it once the post is up | 14:29 |
| kenvandine | nessita, right | 14:29 |
| kenvandine | maybe desktop? | 14:29 |
| nessita | the publisher should be canonical | 14:29 |
| nessita | kenvandine, the publisher is a vendor, an entity | 14:29 |
| oSoMoN | niemeyer, ack, so I’ll start that post and we can iterate on it | 14:29 |
| nessita | an insitution | 14:29 |
| ev | yeah, I agree with nessita | 14:29 |
| kenvandine | ok | 14:29 |
| niemeyer | oSoMoN: Sounds great, just let me know when you want it "wikied" :) | 14:30 |
| kenvandine | ev, nessita: that's a sound point | 14:30 |
| niemeyer | oSoMoN: I also have a special user in the forum which I change the ownership to in some cases.. might make sense here to make it show up nicely.. see for instance: ... | 14:30 |
| kenvandine | can we get someone on the desktop team with publishing permissions for canonical? So we don't have to funnel everything through mvo? | 14:31 |
| niemeyer | oSoMoN: https://forum.snapcraft.io/t/configuration-in-snaps/510 | 14:31 |
| ev | kenvandine: you can get added as collaborators on those snaps, once set up | 14:31 |
| nessita | kenvandine, every initial setup for a new snap has to go thru mvo, once that's done, he can add collaborators and the collaborators can push and released independently of mvo | 14:33 |
| oSoMoN | niemeyer, yes I had spotted that special "wiki" user, but I wasn't sure how it worked | 14:33 |
| oSoMoN | no vacation for mvo, ever | 14:33 |
| kenvandine | ev, nessita: yeah, that's what my concern was | 14:33 |
| kenvandine | we're going to be adding quite a few snaps | 14:34 |
| ogra | oSoMoN, the collaborators can also add other collaborators | 14:34 |
| ogra | (at least if mvo allowed that) | 14:34 |
| kenvandine | but the initial setup is limited to just mvo | 14:34 |
| ogra | so it is only the initial setup you need him for | 14:34 |
| niemeyer | oSoMoN: It's two independent things.. the wiki user is just a normal user I made up to make some collaborative posts more obvious | 14:34 |
| nessita | kenvandine, yeah, right now there is no workaround for that | 14:34 |
| kenvandine | ok | 14:34 |
| ogra | kenvandine, well, i guess you dont add new packages on aa per-day basis :) | 14:35 |
| ogra | -a | 14:35 |
| kenvandine | i guess we can continue to upload new snaps as individuals then ask mvo to change owner? | 14:35 |
| niemeyer | oSoMoN: The actual wiki functionality may be enabled for any top-level post, no matter who's the author | 14:35 |
| nessita | kenvandine, so maybe create an initial revision for all the snaps and have him upload that, even if it's an empty snap (using plugin nil or something) -- of course never release such revisions | 14:35 |
| kenvandine | ogra, close to right now | 14:35 |
| kenvandine | we're trying to snap all of our desktop apps | 14:35 |
| nessita | kenvandine, changing owner is something I do, so please email me for that | 14:35 |
| ogra | sure, but only until you have your set in ... | 14:35 |
| kenvandine | ogra, right | 14:35 |
| ogra | you wont do it regulary after you have submitted your set of apps | 14:36 |
| kenvandine | it'll be busy for a little while then tail off | 14:36 |
| ogra | and mvo had vacation this year already ... so all is good :P | 14:36 |
| nessita | lol | 14:36 |
| kenvandine | but actually i like the idea of getting them in the store as individuals and then changing publisher | 14:36 |
| kenvandine | at least we can get moving on testing, etc | 14:36 |
| kenvandine | lol | 14:36 |
| popey | it doesn't look so good from outside | 14:37 |
| popey | snap install foo | 14:37 |
| kenvandine | yeah | 14:37 |
| popey | "installing foo from random developer I have never heard of" | 14:37 |
| kenvandine | but we'll have some people of time in edge so we can get slightly broader testing | 14:37 |
| ogra | nessita, hmm, if there are collaborators already and you change the owner, do the collaborators persist ? that would take mvo completely out | 14:37 |
| kenvandine | i can then like once a week or so email a list to nessita to change | 14:37 |
| ogra | they could just set that up in advance | 14:37 |
| popey | how many are we talking about? can we not prep a list and just get them all registered en-masse via mvo in one hit? | 14:37 |
| kenvandine | ah, that would be interesting | 14:37 |
| popey | rather than drip feed | 14:38 |
| kenvandine | can he do that in advance? | 14:38 |
| kenvandine | we can put together the list | 14:38 |
| nessita | ogra, yes, they persist (for now, until we migrate to new snap-developer assertions) | 14:38 |
| kenvandine | assuming he can add the collaborators before the snap is uploaded | 14:38 |
| ogra | nessita, then kenvandine should just register them, add someone else from the team as collaborator and you switch the owner ... | 14:38 |
| nessita | popey, the thing is they also need an initial build for upload, is not enough to register the name | 14:38 |
| popey | you can use the same yaml with one line changed to make the snaps | 14:39 |
| === Guest42362 is now known as Abhishek_ | ||
| ogra | then it is just between you two | 14:39 |
| popey | for the first non-published rev, to do the collaboration part | 14:39 |
| nessita | correct | 14:39 |
| popey | snapcraft init, then replace my-snap-name with your app name, snapcraft, done :) | 14:40 |
| popey | (20 times) :D | 14:40 |
| ogra | write a ruby script :) | 14:41 |
| ogra | (because ruby is modern :P ) | 14:41 |
| kenvandine | and they won't be installable right? | 14:41 |
| popey | pffft, ruby is old school, it's all rust now baby | 14:41 |
| kenvandine | sigh... ruby | 14:41 |
| popey | kenvandine: not if not published | 14:41 |
| ogra | rusty then :P | 14:41 |
| popey | you can upload them and never publish | 14:41 |
| kenvandine | so i can create a pile of empty snaps and send them to mvo | 14:41 |
| popey | ya | 14:41 |
| kenvandine | and for the ones we already have we can just email nessita a list | 14:42 |
| popey | to re-home them? yes | 14:42 |
| kenvandine | cool | 14:42 |
| nessita | kenvandine, correct | 14:42 |
| kenvandine | we should add our collaborators to the current ones first then :) | 14:42 |
| popey | so you need a list of collaborators, list of snaps, and a pile of snap files. | 14:43 |
| kenvandine | ok | 14:43 |
| oSoMoN | niemeyer, kenvandine: here we go with a very rough draft, contributions welcome! https://forum.snapcraft.io/t/snaps-officially-supported-by-canonical/1719 | 14:45 |
| niemeyer | oSoMoN: Thanks! LGTM.. let me know I should make it a wiki and transfer ownership to the wiki user as well | 14:46 |
| oSoMoN | niemeyer, please do, so that kenvandine and others can edit | 14:47 |
| morphis_ | oSoMoN: btw. there is a discussion ongoing what "officially supported" means in terms of Ubuntu / Canonical | 14:47 |
| pedronis | niemeyer: in repair, if Runner.SaveState returns an error but we also run it more frequently, should we report those errors immediately over other errors, or just log them and continue/report the other errors? | 14:47 |
| morphis_ | oSoMoN: slangasek is the main contact here | 14:47 |
| oSoMoN | morphis_, ha that’s particularly relevant here | 14:48 |
| morphis_ | yeah | 14:48 |
| kenvandine | it is | 14:48 |
| morphis_ | seb128 and willcooke are involved as well | 14:48 |
| * zyga-ubuntu goes home | 14:49 | |
| zyga-ubuntu | ttyl | 14:49 |
| Chipaca | zyga-ubuntu: i'm this >< close to giving up on this thing | 14:49 |
| oSoMoN | great, so no need for us to be involved, there’s enough of the team taking part already | 14:49 |
| zyga-ubuntu | Chipaca: on the -count bug? | 14:49 |
| Chipaca | yes | 14:49 |
| morphis_ | oSoMoN: but good that his gets documented as we have a policy for quite some time what it means to publish certain snaps under "canonical" for our commercial offerings | 14:49 |
| zyga-ubuntu | Chipaca: I'll have a fresh look tomorrow | 14:49 |
| Chipaca | zyga-ubuntu: my best guess so far is that the lookup in path is not done in the same thread as the setenv | 14:50 |
| niemeyer | oSoMoN: Changed it slightly.. I guess you'll get notifications there from now on | 14:50 |
| oSoMoN | niemeyer, thanks | 14:51 |
| niemeyer | pedronis: Good question.. hmm | 14:51 |
| niemeyer | pedronis: I think not saving the state is not such a hard failure is it? | 14:51 |
| pedronis | no | 14:52 |
| niemeyer | In the sense that the repairs should be idempotent | 14:52 |
| mup | PR snapd#3745 closed: interfaces: convert uhid to common interface and test cases improvement for time_control and opengl <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3745> | 14:52 |
| pedronis | so we could just log | 14:52 |
| niemeyer | pedronis: Yeah, I think we can log and let other errors take priority.. if there are no other errors, then we report the save state failure | 14:52 |
| pedronis | our real problems will be more if we fail to write the bits needed to log/run the repair themselves | 14:52 |
| niemeyer | Yeah | 14:52 |
| niemeyer | pedronis: Let's please document these ideas in the code itself so we remember them later | 14:53 |
| kenvandine | oSoMoN, although it was willcooke that told us to use ubuntu desktop team :) | 14:53 |
| oSoMoN | yes, the rationale made sense, but the conclusions of this discussion make even more sense I think | 14:54 |
| oSoMoN | nothing is set in stone so we can continue discussing this, the ownership of snaps in the store can easily be transferred apparently | 14:55 |
| oSoMoN | the argument that those snaps are not ubuntu-specific is particularly important (although they will obviously get more testing on ubuntu) | 14:56 |
| ogra | today perhaps :) | 14:57 |
| popey | Actually, you mind find the opposite is true :) | 14:57 |
| ogra | if you post your "please test..." stuff to the forum you usually get testing from all sides | 14:57 |
| ogra | and that will rise | 14:57 |
| davidcalle | ikey: ping | 14:57 |
| ikey | davidcalle, pong | 14:57 |
| oSoMoN | ogra, popey: right, I meant more testing on ubuntu from me, really | 14:58 |
| popey | hehehe | 14:58 |
| ogra | heh | 14:58 |
| davidcalle | ikey: hey, I'm adding solus support to the snap doc, about the table at the bottom of https://snapcraft.io/docs/core/install, what can you tell me? How is snapd in solus in sync with releases, what are the supported features? (eg. do you support confined snaps or devmode only, do you support classic) | 14:59 |
| ikey | support all modes, and intend to sync snapd on the same day (where feasible) into solus repos | 15:00 |
| ikey | full confinement has some quirks we're still working out (like chromium) | 15:00 |
| ikey | but the solus kernel uses the same apparmor as the ubuntu kernel | 15:00 |
| davidcalle | Alright, that's great :) | 15:00 |
| ikey | we're on 2.27 atm though because of the initial integration process | 15:01 |
| ikey | getting the various bits of support in | 15:01 |
| ikey | on the next solus repo sync all existing users will receive snapd upon update too | 15:01 |
| davidcalle | Ok | 15:01 |
| ogra | and then just enable re-exec ynd you dont have to care anymore ;) | 15:02 |
| ikey | sure i will | 15:02 |
| ikey | it'll reexec the ubuntu core snapd, not the solus one, right? | 15:02 |
| ogra | it re-execs into the core snap | 15:02 |
| ogra | so you get whatever is in there | 15:02 |
| ikey | and snapd is patched for solus support | 15:02 |
| ogra | oh | 15:02 |
| ikey | whereas the core one would operate like an ubuntu one, no? | 15:02 |
| ogra | yeah, that would not work i guess | 15:03 |
| ogra | :( | 15:03 |
| ikey | unless we could carry across the "im still a solus" flag to the internal snapd | 15:03 |
| ikey | so it still does solus like things | 15:03 |
| ikey | (when all patches are merged/finished) | 15:03 |
| ogra | <trump voice>so sad</trump voice> | 15:03 |
| ikey | lol | 15:03 |
| ikey | there were fine snaps on both sides.. | 15:03 |
| ikey | >_> | 15:03 |
| ogra | lol | 15:04 |
| om26er | Hi! apart from experimenting and deploying snaps, whats the best way to contribute to the snappy ecosystem ? | 15:04 |
| davidcalle | morphis_: speaking of the snapd support table on https://snapcraft.io/docs/core/install, I think we should drop the "version" col and just keep the "status" one in sync, can you help with the update? | 15:04 |
| * ikey is thinking version syncing the doc is gonna be a pain.. :p | 15:04 | |
| morphis_ | davidcalle: not really, filled with a lot of other things | 15:05 |
| popey | om26er: https://forum.snapcraft.io/t/join-snapcrafters/1325 :D | 15:05 |
| popey | ^ that would be awesome | 15:05 |
| ikey | popey, apparently the Zoom people have shown interest in Snap | 15:05 |
| ikey | popey, https://dev.solus-project.com/T6 | 15:05 |
| popey | Yay! | 15:05 |
| ikey | specifically the comment from mcritchlow | 15:05 |
| popey | (what's zoom?) | 15:05 |
| ikey | XD | 15:05 |
| ikey | https://zoom.us/ | 15:05 |
| ikey | video conferencing thinger | 15:05 |
| popey | oooh | 15:05 |
| ikey | closed source | 15:06 |
| ogra | neat ! | 15:06 |
| ikey | but they have a linux tarball... | 15:06 |
| ikey | so.. snappable | 15:06 |
| popey | We can help here! | 15:06 |
| palasso | Ohh here's all the snappy hippies hiding! btw just watched last LUP | 15:06 |
| popey | hi palasso | 15:06 |
| ikey | important bit: | 15:06 |
| ikey | " I've messaged Zoom requesting that they package the app up as a snap. I really think it would make their lives much easier, and ours as end users. Couldn't hurt for others to bother them as well if you agree. The response I got was positive, and they've added it to their feature request list." | 15:06 |
| palasso | hey!!! | 15:06 |
| * ogra hands palasso a space cookie | 15:06 | |
| ogra | peace dude ! | 15:07 |
| ogra | :) | 15:07 |
| * ikey only got handed patches and bugs, quite jealous | 15:07 | |
| ikey | lol | 15:07 |
| popey | ikey: we can reach out to them if you like? | 15:07 |
| * ogra hands one to ikey too | 15:07 | |
| ikey | ta xD | 15:07 |
| davidcalle | morphis_: ok, nevermind, I'll leave it for later | 15:07 |
| popey | kk | 15:07 |
| ikey | popey, i think thats likely the best strategy | 15:07 |
| * popey adds to the to-do lane | 15:07 | |
| ikey | yknow, what with y'all being official n all | 15:07 |
| popey | ya | 15:07 |
| popey | XD | 15:07 |
| ikey | and me being some hippy at the helm.. | 15:07 |
| ikey | hey i like that title | 15:07 |
| * ikey uses it now | 15:07 | |
| popey | make it your linkedin profile or it doesn't count | 15:08 |
| ikey | totally doing it now | 15:08 |
| morphis_ | davidcalle: thanks | 15:08 |
| popey | bet that will email all your contacts and tell them too :) | 15:09 |
| ikey | popey, https://www.linkedin.com/in/ikeydoherty/ | 15:09 |
| ikey | XD | 15:09 |
| popey | haha, excellent | 15:09 |
| * ikey changes it everywhere now | 15:09 | |
| om26er | popey: aha, cool. Thanks for the link. So the snaps with publisher "snapcrafters" are the one' that this team maintains ? | 15:10 |
| ikey | popey, lol https://twitter.com/ehawk61/status/897833943885647874 | 15:10 |
| popey | om26er: yeah, exactly | 15:10 |
| popey | :D | 15:11 |
| === cachio is now known as cachio_lunch | ||
| ikey | davidcalle, oh and if you could just put solus above arch in the supported list with an emoji indicating "lol" that'd be great | 15:24 |
| ikey | >_> | 15:24 |
| ikey | <_< | 15:24 |
| * ikey is mostly kidding | 15:25 | |
| pstolowski | niemeyer, can you take another look at https://github.com/snapcore/snapd/pull/3569 ? I think I addressed all your comments and the branch is rotting a little bit ;) | 15:28 |
| mup | PR snapd#3569: snapd, snapctl: use json Decoder instead of Unmarshall <Created by stolowski> <https://github.com/snapcore/snapd/pull/3569> | 15:28 |
| davidcalle | Well, in alphabetical order, so you'll still be above Ubuntu ;-) | 15:29 |
| * Chipaca creates a spinoff called aaaabuntu | 15:30 | |
| * ikey changes names to Alpha Centauri Solus just to game the list | 15:30 | |
| davidcalle | ikey: you should have picked Abuntu instead of Solus | 15:30 |
| davidcalle | Ahahaha | 15:30 |
| ikey | good job the "buntu" suffixes stopped though really | 15:31 |
| ikey | we had a very real risk of Bubuntu existing | 15:31 |
| ikey | and thats just an unforgivable name | 15:31 |
| * Chipaca is still toying with the idea of creating uubuntu | 15:32 | |
| davidcalle | Nothing beats the quirkyness of Google's Goobuntu | 15:32 |
| ikey | yubuntu | 15:32 |
| ikey | with that unity work | 15:32 |
| ikey | *fork | 15:32 |
| ikey | words. | 15:32 |
| Chipaca | and then clearly, yabuntu | 15:37 |
| Chipaca | mvo: might Christian Ehrhardt's comment about pie be related to our recent woes? | 15:40 |
| willdeberry | koza: so updated to use uhid plug before resorting to swapping out bluez classic for snap. I am at least getting apparmor denials. Is there a snap way to add policies or would that have to be done manually outside the snap? https://pastebin.com/Df4qSxG6 | 15:43 |
| davidcalle | ikey: https://github.com/CanonicalLtd/snappy-docs/pull/92 works for you? | 15:44 |
| mup | PR CanonicalLtd/snappy-docs#92: Add Solus install instructions <Created by caldav> <https://github.com/CanonicalLtd/snappy-docs/pull/92> | 15:44 |
| ikey | davidcalle, looks legit | 15:47 |
| ikey | idk if its worth mentioning solus 3 has it preinstalled or not | 15:47 |
| davidcalle | Oh, I wasn't aware of that, yes, it should | 15:48 |
| Chipaca | pedronis: did you see my question about SnapManager attributes and locking? | 15:48 |
| pedronis | Chipaca: where? | 15:48 |
| Chipaca | before the standup i think | 15:48 |
| davidcalle | ikey: so, your user base is on Solus 2, progressively migrating to 3 which has it installed by default? | 15:48 |
| Chipaca | let me search :-) | 15:48 |
| ikey | davidcalle, Uhm little more complicated than that, Solus 2017.04.18.0 was the last release prior to this Solus 3 ... | 15:49 |
| ikey | We changed versioning schemes | 15:49 |
| davidcalle | Heh :D | 15:49 |
| ikey | But all new Solus 3 ISOs have snapd included by default | 15:49 |
| davidcalle | ikey: and Solus 3 is the default image to download? | 15:50 |
| ikey | right | 15:50 |
| ikey | as of yesterday | 15:50 |
| davidcalle | Congrats! | 15:50 |
| Chipaca | 2017-08-16 12:04:18 <Chipaca>pedronis: question about locking of SnapManager: should I worry about holding a lock while accessing its attributes? | 15:50 |
| Chipaca | 2017-08-16 12:05:05 <Chipaca>pedronis: afaict everything is holding the state's lock right now, but i don't know if that's needed or incidental | 15:50 |
| ikey | ty :D | 15:50 |
| davidcalle | Alright, let me reword the PR | 15:50 |
| pedronis | Chipaca: no, I missed it | 15:50 |
| Chipaca | pedronis: no worries, i've been on detours until just now | 15:51 |
| pedronis | Chipaca: there's no lock in managers usually | 15:51 |
| pedronis | they just use the state lock | 15:51 |
| pedronis | but maybe you have something particular in mind | 15:51 |
| Chipaca | pedronis: so they need to use the state lock? | 15:51 |
| Chipaca | i noticed that they sorta-kinda did, but it's not enforced and i wondered if it was just happenstance | 15:52 |
| pedronis | Chipaca: any particular example? | 15:52 |
| Chipaca | pedronis: SnapManager's nextRefresh | 15:53 |
| Chipaca | pedronis: basicallly, the real question is | 15:53 |
| pedronis | it's a bit of borderline that thing | 15:53 |
| Chipaca | pedronis: given that i need to release the state lock before calling to the store | 15:53 |
| pedronis | well NextRefresh is | 15:53 |
| davidcalle | ikey: let's try again https://github.com/CanonicalLtd/snappy-docs/pull/92/files | 15:54 |
| mup | PR CanonicalLtd/snappy-docs#92: Add Solus install instructions <Created by caldav> <https://github.com/CanonicalLtd/snappy-docs/pull/92> | 15:54 |
| Chipaca | pedronis: if i wanted to update that _after_ calling the store, and had no other reason to grab the lock again, i still need to grab the lock again | 15:54 |
| pedronis | Chipaca: yes, but that guy and his friend should probably say in their docs that you need to hold the state lock | 15:55 |
| pedronis | which they don't | 15:55 |
| pedronis | afaict | 15:55 |
| ikey | davidcalle, perfick | 15:55 |
| === cachio_lunch is now known as cachio | ||
| pedronis | Chipaca: they don't have docs at all, which is also bad | 15:55 |
| Chipaca | pedronis: well, ensureRefreshes is the thing that actually accesses them | 15:55 |
| pedronis | Chipaca: no, they are used in api as well | 15:56 |
| Chipaca | ah | 15:56 |
| pedronis | if it was only ensure | 15:56 |
| pedronis | they wouldn't need to be exported | 15:56 |
| pedronis | I think tests do too | 15:56 |
| pedronis | but those could use export_test.go | 15:56 |
| Chipaca | pedronis: ah, i thought it was just for the tests | 15:56 |
| davidcalle | Saviq: deployed https://developer.ubuntu.com/core/examples/snaps-on-mir | 15:56 |
| ogra | \o/ | 15:56 |
| Chipaca | (cross-package tests would need it in the main thing) | 15:56 |
| ogra | that took a while :) | 15:57 |
| pedronis | Chipaca: as I said probably time to give them some docs | 15:57 |
| pedronis | Chipaca: anyway they are used in api.go sysInfo (with the lock) | 15:57 |
| Chipaca | pedronis: a'ight, so bottom line is, grab the state lock before accessing the manager's attrs | 15:57 |
| davidcalle | ogra: speaking of, you may want to wheigh in on the Raspip3 comment at the top of the doc | 15:58 |
| davidcalle | Raspi3* | 15:58 |
| davidcalle | ikey: there will be probably a design review on the logo addition to the front page, so it will only go live tomorrow | 15:59 |
| ikey | ah yeah sure no rush :D | 16:00 |
| ikey | not everyday someone tells you to stick a boat on your website anyway | 16:00 |
| davidcalle | Hah | 16:00 |
| ogra | davidcalle, hmm, where is the source for that ? | 16:01 |
| davidcalle | ogra: https://github.com/canonical-websites/developer.ubuntu.com/blob/master/templates/pages/core/examples/snaps-on-mir.md | 16:02 |
| ogra | ah, i was looking at CanonicalLDT | 16:02 |
| ogra | **LTD | 16:02 |
| ogra | (why is that separate ?) | 16:02 |
| davidcalle | ogra: all websites are now under canonical-websites | 16:03 |
| davidcalle | ogra: not sure about the rationale | 16:03 |
| ogra | and https://github.com/CanonicalLtd/snappy-docs isnt a web site ? | 16:03 |
| davidcalle | ogra: sorry, the connection is breaking up :) | 16:04 |
| ogra | LOL | 16:04 |
| Chipaca | pedronis: added docs with // The caller should be holding the state lock. | 16:04 |
| ogra | davidcalle, https://github.com/canonical-websites/developer.ubuntu.com/pull/309 | 16:08 |
| zyga-suse | ikey: hey, did you rebase on 2.27.2? | 16:11 |
| davidcalle | ogra: ty! | 16:14 |
| ikey | zyga-suse, didnt see the new vendor tarball | 16:14 |
| willdeberry | is there a way to handle apparmor policies for snaps within the snap itself so I can interact with bluetooth/dbus properly? | 16:14 |
| zyga-suse | ikey: should be .2 just as the last one | 16:16 |
| zyga-suse | willdeberry: no, because that would totally disable all security sanity | 16:16 |
| zyga-suse | willdeberry: as any malicious snap would just say "I want anything" | 16:16 |
| Pharaoh_Atem | mvo: it seems your script for generating %changelog entries for the dates are doing the wrong days of the week | 16:18 |
| Pharaoh_Atem | mvo: your entries for 2.27.1 and 2.27.2 have the wrong days of the week | 16:19 |
| tpatel | I'm having issue with snap-v2.26.14 where on reboot, conect-socket-interface is connected but getting ECONNREFUSED error on socket connections. It was working on 2.26.9 version. | 16:19 |
| === jkridner|pd is now known as jkridner | ||
| tpatel | I'm having issue with snap-v2.26.14 where on reboot, content-socket-interface is connected but getting ECONNREFUSED error on socket connections. It was working on 2.26.9 version. | 16:20 |
| pedronis | niemeyer: something like this: https://github.com/snapcore/snapd/pull/3560/commits/d5c5d933060ec32467c35fb0182a5a2702b9f87a ? | 16:22 |
| mup | PR snapd#3560: cmd/snap-repair: implement most logic to get the next repair to run/retry in a brand sequence <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3560> | 16:22 |
| * ogra wonders what "content-socket-interface" would be | 16:27 | |
| * ikey punches multipath-tools with a spanner | 16:28 | |
| ikey | developed a full blown allergy to non-stateless software.. | 16:28 |
| Saviq | davidcalle: thanks! | 16:29 |
| __chip__ | huh, my computer just randomly shut down | 16:33 |
| ogra | thats probably a subtle hint ... | 16:33 |
| __chip__ | crappy dell acting like it's old just because i've had it since i joined canonical | 16:33 |
| __chip__ | actually not even that, a year after joining i got it | 16:34 |
| niemeyer | pedronis: Yeah, but I think it can be simplified slightly | 16:36 |
| niemeyer | pedronis: Note that the three errors checked for above are the three errors checked for below | 16:36 |
| niemeyer | pedronis: I think it can be something like err1 = makeRepair; err2 = SaveState; if err1 != nil && err1 != skip { return err1 }; if err2 != nil { return err2 } | 16:37 |
| === __chip__ is now known as Chipaca | ||
| Pharaoh_Atem | mvo, niemeyer: snapd 2.27.2 updates have been proposed for Fedora 25 and Fedora 26 | 16:46 |
| Pharaoh_Atem | and it's also now built in Rawhide | 16:46 |
| pedronis | mvo: did you see this: https://forum.snapcraft.io/t/failure-to-upgrade-to-2-27-1-and-2-27-2-with-lxd-installed/1713/2 | 16:47 |
| niemeyer | Pharaoh_Atem: Sweet! | 16:50 |
| niemeyer | Pharaoh_Atem: Thank you | 16:50 |
| Pharaoh_Atem | now I just wish people would test it so it doesn't sit in the queue for a week :( | 16:51 |
| Pharaoh_Atem | https://forum.snapcraft.io/t/in-progress-snapd-2-27-2/572/42?u=conan_kudo | 16:51 |
| oSoMoN | nessita, so following up our conversation earlier today, could you please transfer ownership of the chromium snap from my personal account to the shared canonical account? | 17:03 |
| nessita | oSoMoN, yes, would you please send me an email with cc Bret Barker and mvo? (we try to keep an informal log of transfer requests) | 17:04 |
| oSoMoN | sure, doing that now | 17:05 |
| mvo | Chipaca: what posting from Christian Ehrhardt is that? do you have a url (sorry, was out and juts catching up) | 17:09 |
| oSoMoN | nessita, you have mail | 17:09 |
| nacc | mvo: ubuntu-devel | 17:09 |
| nacc | mvo: https://lists.ubuntu.com/archives/ubuntu-devel/2017-August/039946.html3 | 17:10 |
| Chipaca | mvo: ubuntu-devel, https://lists.ubuntu.com/archives/ubuntu-devel/2017-August/039946.html | 17:10 |
| nacc | err, s/3$// | 17:10 |
| Chipaca | bingo :-) | 17:10 |
| nacc | what Chipaca said :0 | 17:10 |
| mvo | Pharaoh_Atem: meh, I need to tweak my script :/ thanks for noticing | 17:10 |
| nacc | christian did all the heavy lifting to debug it, related bug is LP: #1711092 | 17:10 |
| mup | Bug #1711092: gcc-7 toolchain triggers bug in build system causing non snmp drivers failing to be linked <nut (Ubuntu):New> <https://launchpad.net/bugs/1711092> | 17:10 |
| mvo | Pharaoh_Atem: thanks for pushing the update to fedora. | 17:11 |
| mvo | pedronis: checking the lxd issue now | 17:11 |
| mvo | nacc, Chipaca: thanks a bunch | 17:11 |
| mvo | Chipaca: I think mwhudson might be interessed in https://lists.ubuntu.com/archives/ubuntu-devel/2017-August/039946.html and if it might be the reason why -buildmode=pie in snapd is failing | 17:12 |
| Chipaca | mvo: agreed | 17:23 |
| Chipaca | ok, i've pushed my PR, I'm off | 17:23 |
| mup | PR snapd#3748 opened: many: fetch & cache remote snaps and sections; complete from there <Created by chipaca> <https://github.com/snapcore/snapd/pull/3748> | 17:23 |
| mvo | Chipaca: see you! | 17:23 |
| Chipaca | see you all on here, Wednesday next week :-D | 17:23 |
| mvo | Chipaca: enjoy ! | 17:23 |
| Chipaca | (I might reply to review comments ... with photos of me at the beach) | 17:24 |
| * Chipaca isn't going to the beach | 17:24 | |
| Chipaca | o/ | 17:24 |
| pedronis | niemeyer: https://github.com/snapcore/snapd/pull/3560/commits/011f4441d3198030f7b8a5473e0fa0435a5a5842 and added some tests | 17:28 |
| mup | PR snapd#3560: cmd/snap-repair: implement most logic to get the next repair to run/retry in a brand sequence <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3560> | 17:28 |
| niemeyer | pedronis: LGTM! | 17:34 |
| jdstrand | willdeberry: can you either file a bug or post to the forum with what you are trying to do wrt dbus/bluetooth with a reproducer? | 17:36 |
| pedronis | niemeyer: thanks, I think addressed all the feedback there | 17:37 |
| pedronis | *I think I addressed | 17:37 |
| willdeberry | jdstrand: i sure can | 17:46 |
| willdeberry | i will take care of that after work | 17:48 |
| niemeyer | pedronis: please feel free to merge once you're happy about it.. there were not blockers on that one | 18:04 |
| pedronis | mmh | 18:04 |
| pedronis | seems master is broken | 18:04 |
| niemeyer | :( | 18:05 |
| pedronis | I think some test on matt branch isn't passing anymore with some change on master | 18:05 |
| pedronis | I mean the store assertion PR | 18:06 |
| pedronis | found the issue | 18:11 |
| pedronis | it's an interaction between one of my recent PRs and his, uncovering test code that was always a bit fragile | 18:13 |
| mup | PR snapd#3749 opened: asserts/assertstest: fix master <Created by pedronis> <https://github.com/snapcore/snapd/pull/3749> | 18:15 |
| mvo | pedronis: thanks for fixing msater | 18:30 |
| mvo | master | 18:30 |
| ikey | i think the chromium snap broke my host side GL .. | 19:07 |
| ikey | couldnt launch steam and got libGL errors | 19:08 |
| ikey | eh i think apparmor is breaking solus a lot. | 19:10 |
| ikey | /bin/sh: /home/ufee1dead/.local/share/Steam/steamapps/common/ARK/ShooterGame/Binaries/Linux/ShooterGame: Text file busy | 19:10 |
| pedronis | mvo: a new kind of fedora failure: /var/tmp/rpm-tmp.QSCKfG: line 15: python: command not found | 19:21 |
| pedronis | Warning: file /etc/mock/fedora-25-.cfg does not exists. | 19:21 |
| pedronis | unable to update /etc/mock/default.cfg | 19:21 |
| mvo | pedronis: uff | 19:21 |
| mvo | pedronis: that does not ring any bells :/ | 19:21 |
| pedronis | mvo: well, I'm tempted to put fedora to manual or something | 19:24 |
| pedronis | I don't even know how to do that though | 19:24 |
| cachio_ | mvo, weird results for i386 : https://paste.ubuntu.com/25327320/ | 19:26 |
| cachio_ | mvo, the rest seem to be ok | 19:27 |
| mvo | pedronis: yeah, I think that is ok | 19:28 |
| pedronis | mvo: trying that | 19:29 |
| pedronis | mvo: seems manual should work also with systems | 19:29 |
| mvo | cachio_: the errors look like its an older snapd in the image | 19:29 |
| mvo | cachio_: can you ssh into it and see what "snap version" shows? | 19:30 |
| mvo | pedronis: cool | 19:30 |
| cachio_ | mvo, yes | 19:30 |
| cachio_ | mvo, mmm, it is hte 2.26.14 | 19:33 |
| mvo | cachio_: what is the output of snap list? | 19:34 |
| cachio_ | mvo, I executed from 2.27.2 | 19:34 |
| mvo | cachio_: uh, strange | 19:35 |
| cachio_ | https://paste.ubuntu.com/25327614/ | 19:35 |
| pedronis | mvo: I did this: https://github.com/snapcore/snapd/pull/3749/commits/8f640461859d56702cc8c7fe4e5fe1b63a92a9e5 | 19:36 |
| mvo | cachio_: I guess any traces *why* this has happend will be erased by the testsuite now ? | 19:36 |
| mup | PR snapd#3749: asserts/assertstest: fix master <Created by pedronis> <https://github.com/snapcore/snapd/pull/3749> | 19:36 |
| mvo | cachio_: maybe snap list --all ? | 19:36 |
| mvo | cachio_: or snap changes has some info? | 19:36 |
| mvo | pedronis: heh, nice | 19:37 |
| pedronis | well, not nice, but I want to make master green again | 19:37 |
| mvo | pedronis: yeah, we can easily re-enable it | 19:38 |
| mvo | pedronis: and have a PR that validates the fixes then etc | 19:38 |
| cachio_ | mvo, I don't see nothing weird | 19:39 |
| cachio_ | https://paste.ubuntu.com/25327631/ | 19:39 |
| cachio_ | mvo, I'll make the whole process again | 19:42 |
| mvo | cachio_: thanks | 19:42 |
| mvo | cachio_: can you pastebin the entire syslog | 19:42 |
| mvo | cachio_: before you wipe the system please? | 19:42 |
| mvo | cachio_: I wonder if we find clues in there | 19:43 |
| jdstrand | ikey: re apparmor> the kernel patches or the policy? I would be quite surprised the policy would break GL on the system. the kernel could be missing some important patches I guess. I think it more likely that the mount namespace for the snap is propagating to the host | 19:43 |
| ikey | jdstrand, i ran snap run chromium, it hard locked, ctrl+c'd it, ran steam, couldnt initialise GL | 19:44 |
| ikey | not until i rebooted | 19:44 |
| ikey | (and chromium is still pooched) | 19:44 |
| ikey | yet cybre can run it without issue on solus | 19:44 |
| ikey | v odd | 19:45 |
| jdstrand | that could be gl errors. I know I sometimes get weird lockups with chrome | 19:45 |
| ikey | should point out im using chrome host side | 19:45 |
| jdstrand | did you have anything in the dmesg? | 19:45 |
| ikey | nope | 19:45 |
| ikey | and if i strace it the process exits | 19:45 |
| ikey | because you have to be root to strace it | 19:45 |
| ikey | and then sandbox throws a hissy fit | 19:45 |
| ikey | (and gotta be root because setuid binaries) | 19:46 |
| jdstrand | you need to run strace special | 19:46 |
| * jdstrand gets link | 19:46 | |
| cachio_ | mvo https://paste.ubuntu.com/25327666/ | 19:46 |
| jdstrand | also, if you ran it as root, it is possible ~/snap/chromium or a subdir is root-owned and could cause an issue | 19:46 |
| jdstrand | ikey: https://forum.snapcraft.io/t/stracing-snap-commands/1433 | 19:47 |
| ikey | yeah i ran it as root *after* the failure | 19:47 |
| ikey | to strace it | 19:47 |
| cachio_ | mvo, tell me if you need anything else | 19:47 |
| jdstrand | ikey: you might run find to see if the perms are correct | 19:48 |
| ikey | im not sure if you're getting what im saying jdstrand :p | 19:48 |
| ikey | it was buggy from the getgo | 19:48 |
| jdstrand | or just rm -rf ~/snap/chromium and start over | 19:48 |
| ikey | it was locking, so i straced with root after | 19:48 |
| jdstrand | I do get that | 19:48 |
| ikey | i didnt start it initially as root | 19:48 |
| * jdstrand understands | 19:48 | |
| * ikey blitz aforementioned dir | 19:49 | |
| ikey | nope | 19:49 |
| jdstrand | I'm saying having run it as root might've messed things up differently so further debugging would be different | 19:49 |
| pedronis | mvo: I want to land a couple of things and then I can propose one that undoes that | 19:49 |
| pedronis | and we'll see if it's a fluke or something is broken more permanently | 19:49 |
| ikey | i see audit calls but no denials | 19:49 |
| jdstrand | anyway, if the dir is gone, you can stracec using the technique in the above forum post | 19:49 |
| ikey | Aug 16 20:49:06 ironhide SGI_video_sync[13187]: <audit-1326> auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=13187 comm="SGI_video_sync" exe="/snap/chromium/1/usr/lib/chromium-browser/chromium-browser" | 19:50 |
| ikey | etc | 19:50 |
| jdstrand | I strongly suspect the mount namespace isn't being setup right if this is affecting the rest of the system | 19:50 |
| jdstrand | that said, I tried in a vm with not a lot of ram and the kernel starting killing off a bunch of random stuff | 19:50 |
| jdstrand | you would've seen something in dmesg though if it was that | 19:51 |
| jdstrand | or a video driver issue | 19:51 |
| jdstrand | (strongly based on what you said, not any personal observation) | 19:51 |
| ikey | ya | 19:52 |
| ikey | and now hastebin is dead -_- | 19:52 |
| ikey | k so this is the tail 100 https://pastebin.com/sSwme915 | 19:52 |
| ikey | when I ctrl+c it: https://pastebin.com/LiPPVRar | 19:54 |
| ikey | interestingly i dont get that output when im not stracing it | 19:54 |
| jdstrand | ikey: I think you need oSoMoN to help at this point, unless you're still convinced about the gl issues and mount namespace, then perhaps zyga | 19:56 |
| ikey | no im more interested atm in the black-screen-of-death-locks-forever bit | 19:56 |
| ikey | do it tomorrow anyway, too late her now :p | 19:58 |
| ikey | *here | 19:58 |
| ikey | -_- | 19:58 |
| jdstrand | ikey: re black screen of death. my theory had something to do with the host being affected by the chromium snap's mount namesapce. that shouldn't be terrible to verify. reboot, sha256sum (or similar) the contents of that dir from the host, launch chromium, then sha256sum the contents of that directory again from the host | 19:59 |
| jdstrand | ikey: I'm not familiar with solus' setup of that dir, but my understanding is there is a tmpfs and some symlinks? just make sure the host isn't actually changed. then you could 'snap run --shell chromium' and see if the mount namespace ha all the gl stuff the snap should have | 20:01 |
| jdstrand | then report in the forum and perhaps oSoMoN or zyga or someone else can help | 20:02 |
| cachio_ | mvo, I am running again and I see similar issue | 20:05 |
| mvo | cachio_: what do I need to do to reproduce? | 20:06 |
| niemeyer | cprov: Just finished recording the whiteboard session on epochs.. now just needs assembling.. | 20:06 |
| mvo | cachio_: just make a core from beta? | 20:06 |
| niemeyer | Should have something later today or tomorrow | 20:06 |
| cachio_ | I created the beta image | 20:07 |
| cachio_ | with validator project | 20:07 |
| mvo | cachio_: what is validator project? | 20:07 |
| niemeyer | Going outside for a while now.. o/ | 20:07 |
| cachio_ | https://github.com/fgimenez/validator.git | 20:08 |
| cachio_ | mvo, | 20:08 |
| cachio_ | mvo, then run ./create.sh beta pc-i386 | 20:08 |
| cachio_ | mvo, this will get you the image | 20:09 |
| cachio_ | mvo, you need to install ubuntu-image snap | 20:09 |
| cachio_ | mvo, then | 20:10 |
| cprov | niemeyer: cool! Looking forward to watch it. Thanks for working on that. | 20:10 |
| cachio_ | kvm -snapshot -smp 2 -m 1500 -redir tcp:8022::22 -nographic -serial mon:stdio <path_to_the_img> | 20:10 |
| cachio_ | mvo, export SPREAD_EXTERNAL_ADDRESS=localhost:8022 | 20:10 |
| cachio_ | . ./tests/lib/external/prepare-ssh.sh localhost 8022 | 20:10 |
| cachio_ | spread -v external:ubuntu-core-16-32 | 20:11 |
| mup | PR snapd#3749 closed: asserts/assertstest: fix master <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3749> | 20:11 |
| mvo | cachio_: checking | 20:11 |
| cachio_ | mvo, inthe meantime I am running the other stuff | 20:13 |
| cachio_ | the problem is that I go so slow with the pi2 and 3 | 20:13 |
| cachio_ | I need new cards | 20:13 |
| pedronis | mvo: merged, master should get back to green | 20:13 |
| mvo | cachio_: working on it | 20:14 |
| mvo | pedronis: thanks a bunch | 20:14 |
| mvo | cachio_: thinks are "funny". core r2800 is indeed 2.26.14 but that is not what got uploaded, something is wrong with lp->store | 20:20 |
| cachio_ | mvo, mmm, ok | 20:22 |
| cachio_ | mvo, should I cancel the execution? | 20:23 |
| mvo | cachio_: please give it another go, looks like a number mismatch | 20:23 |
| mvo | cachio_: yes | 20:23 |
| mvo | cachio_: cancel please but now you can create a new image, the right rev is now in the right place | 20:23 |
| cachio_ | mvo, ok | 20:23 |
| mvo | cachio_: it was me messing up, sorry for that :( | 20:23 |
| cachio_ | mvo, I'll run again with the new image in that case | 20:24 |
| cachio_ | mvo, np | 20:24 |
| mvo | cachio_: thank you | 20:27 |
| mvo | cachio_: keep me updated, I call it a day :) | 20:27 |
| cachio_ | mvo, sure, tx | 20:27 |
| mup | PR snapd#3750 opened: snapstate: undo a daemon restart on classic if needed <Created by mvo5> <https://github.com/snapcore/snapd/pull/3750> | 20:29 |
| tyhicks | jdstrand: I'm no longer sure when snapd is (re)generating the seccomp BPF filters | 20:31 |
| tyhicks | jdstrand: is it possible for the BPF filter to be generated under one kernel and then the binary BPF filter loaded into a different kernel (after a reboot) | 20:31 |
| tyhicks | (trying to think through libseccomp API design decisions) | 20:32 |
| tyhicks | snap-confine.rst covers how the .bin files are generated but not when they're generated | 20:43 |
| pedronis | do we have a fix for piCfgSuite.TestConfigurePiConfigNoChangeSet yet ? | 20:47 |
| pedronis | is it this: snapd#3746 ? | 20:50 |
| mup | PR snapd#3746: corecfg: handle unknown keys that are explicitly set <Created by zyga> <https://github.com/snapcore/snapd/pull/3746> | 20:50 |
| pedronis | I'm not familiar with that code | 20:50 |
| mwhudson | jdstrand: thanks | 20:59 |
| willdeberry | jdstrand: just poking you since you recommeneded, https://forum.snapcraft.io/t/accessdenied-when-running-my-packaged-snap-app/1724 . Hopefully this helps with reproducability for others. | 21:05 |
| mup | PR snapd#3751 opened: interfaces/many: updates based on chromium and mrrescue denials <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3751> | 21:20 |
| mwhudson | jdstrand: still here? | 21:45 |
| jdstrand | mwhudson: I am just about to leave, but feel free to asking | 22:07 |
| jdstrand | ask* | 22:07 |
| mwhudson | jdstrand: i replied in the forum, if you have 2s to read and quickly reply that'd be great but it can wait till tomorrow too :) | 22:08 |
| jdstrand | mwhudson: responded. heading out. I'll keep an eye on the forum and backscroll. have a nice rest of the day :) | 22:16 |
| mwhudson | jdstrand: thanks, you too | 22:16 |
| * mwhudson afk for a bit | 22:21 | |
| willdeberry | so aside from the plug issues I am having with bluetooh which is being addressed via the forums, I am occasionally running into the following error on random builds when no code is changing: /snap/bjarkan/50/usr/bin/python3: 1: /snap/bjarkan/50/usr/bin/python3: Syntax error: word unexpected (expecting ")") | 23:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!