| sergiusens | diddledan every Tuesday, the snap; every 3 weeks the deb | 00:51 |
|---|---|---|
| diddledan | :-p | 00:51 |
| kyrofa | Ugh, man it gets dark early | 00:58 |
| kyrofa | Canonical needs to buy me a few soft boxes | 01:09 |
| bdx | hey, whats up all | 01:38 |
| bdx | beating this nginx logging horse to death here | 01:38 |
| bdx | I had great success with getting my logs to syslog via the snap logging proxy | 01:40 |
| bdx | not sure the technical name for that mechanism | 01:40 |
| bdx | a req came down the line that this application log to a separate file(s) and the logs end up in s3 | 01:41 |
| bdx | so I had to log to $SNAP_COMMON | 01:41 |
| bdx | which works great until I try to setup logrotate | 01:41 |
| bdx | I hit my head on a few things, but ended up getting logrotate in this working/broken state | 01:42 |
| bdx | in short, the issue I seem to be having is that when logrotate goes to swap out the logfile, nginx needs a kick (reload) to start writing to the new logfile | 01:43 |
| bdx | which brings me to the (logrotate) postrotate sripts | 01:44 |
| bdx | which can be used to send signal or run a bin when your gets rotated and swapped out | 01:44 |
| bdx | so my idea here was to create a wrapper command in my snap to facilitate running the `nginx -s reload` command | 01:45 |
| bdx | here's whats in my wrapper http://paste.ubuntu.com/26115750/ | 01:49 |
| bdx | the output I'm getting ^ | 01:50 |
| bdx | seems like the snap is preventing the process from being restarted | 01:50 |
| bdx | nginx: [alert] kill(17878, 1) failed (1: Operation not permitted) | 01:50 |
| bdx | I should probably write another forum post pertaining to this | 01:50 |
| bdx | possibly my last one on logging wasn't specific enough | 01:51 |
| bdx | is this making sense? | 01:51 |
| bdx | do I need to add more context somehow in a more proper write up? | 01:51 |
| bdx | let me know | 01:51 |
| bdx | thx thx | 01:51 |
| sergiusens | elopio would be great if you could run through snapcraft#1789 and also maybe try and apply your changes, I don't see how they look good when running | 02:21 |
| mup | PR snapcraft#1789: cli: improve the help command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1789> | 02:21 |
| mup | PR snapcraft#1791 opened: tests: move the python plugin integration tests to a separate suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1791> | 05:49 |
| mborzecki | morning | 06:03 |
| mup | PR snapcraft#1792 opened: tests: do not hit the network in python unit tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1792> | 06:25 |
| m4sk1n_ | https://github.com/m4sk1n/snapcraft/tree/i18n-wip I don't know how should I config ./bin/snapcraft to apply translations… | 06:46 |
| mborzecki | mvo: hey | 07:01 |
| mvo | hey mborzecki - good monring | 07:01 |
| mvo | morning even | 07:01 |
| mborzecki | :) | 07:02 |
| mborzecki | mvo: got a quick question, https://travis-ci.org/snapcore/snapd/builds/311243551?utm_source=github_status&utm_medium=notification any idea why this has failed? | 07:02 |
| mvo | mborzecki: yes, I looked at it earlier and restarted because iirc it could not allocate machines, it looked very transient, I don't have the log in front of me unfortunately anymore | 07:04 |
| mborzecki | i'll restart the build then | 07:05 |
| mborzecki | traving is also having hiccups today, couldn't restart the build | 07:07 |
| mvo | mborzecki: it is restarted already, at least when I looked at it ~1min ago :) | 07:07 |
| mborzecki | i clicked 3-4 times, got 'Oh no! .. blah blah' | 07:08 |
| mborzecki | mvo: that arch test that fails, got this from sysctl: kernel.random.entropy_avail = 32, not a good sign | 07:11 |
| mvo | mborzecki: heh, yeah | 07:12 |
| mborzecki | i kind of lik the idead that was circled yesterday, just mknod /dev/random c 1 9 and we're done for the tests at least | 07:12 |
| mvo | mborzecki: yeah, I think we should just do it, for clarity I would use a symlink (if gpg is happy with that) | 07:13 |
| mvo | mborzecki: will you do a PR with that? or shall I do one :) ? | 07:13 |
| mborzecki | oh and `dd=/dev/random of=/dev/null` chokes obvioulsy on that machine | 07:13 |
| mborzecki | i can do it | 07:13 |
| mvo | if anyone has a fedora system at hand, what is the package that contains aa-enforce in fedora? | 07:14 |
| mvo | and apparmor_parser ? | 07:14 |
| mborzecki | mvo: there's no aa in fedora | 07:30 |
| mup | PR snapd#4354 opened: tests/lib: introduce helpers for setting up /dev/random using /dev/urandom in project prepare <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4354> | 07:39 |
| mborzecki | mvo: ^^ | 07:40 |
| zyga-ubu1tu | hey hey | 08:01 |
| mborzecki | zyga-ubu1tu: hey | 08:02 |
| zyga-ubu1tu | sorry for being absent-ish yesterday, I'll try to make up for that | 08:02 |
| mborzecki | zyga-ubu1tu: need a 2nd review on #4338 if you would be so kind :) | 08:03 |
| mup | PR #4338: config, overlord/snapstate, timeutil: rename ParseSchedule to ParseLegacySchedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4338> | 08:03 |
| zyga-ubu1tu | mborzecki: yep, looking | 08:05 |
| mborzecki | zyga-ubu1tu: thanks | 08:06 |
| mup | PR snapd#4338 closed: config, overlord/snapstate, timeutil: rename ParseSchedule to ParseLegacySchedule <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4338> | 08:08 |
| mborzecki | mvo: this build timed out https://travis-ci.org/snapcore/snapd/builds/311243551?utm_source=github_status&utm_medium=notification | 08:09 |
| mborzecki | zyga-ubu1tu: while you're doing reviews, would you mind taking a look at #4340 as well? | 08:13 |
| mup | PR #4340: snap: YAML and app validation parts of after/before app startup ordering <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4340> | 08:13 |
| pstolowski | zyga-ubu1tu, hey! can you take another look at #4303 (addressed your previous feedback, and got +1 from Gustavo) | 08:15 |
| mup | PR #4303: interfaces: use ConnectedPlug/ConnectedSlot types (step 1) <Created by stolowski> <https://github.com/snapcore/snapd/pull/4303> | 08:15 |
| zyga-ubu1tu | pstolowski: sure, looking now | 08:15 |
| pstolowski | zyga-ubu1tu, thanks! | 08:15 |
| zyga-ubu1tu | pstolowski: that's a biggie :) | 08:17 |
| pstolowski | zyga-ubu1tu, look at the followup... it's fairly mechanical though | 08:17 |
| zyga-ubu1tu | brb, reboot | 08:22 |
| === __chip__ is now known as Chipaca | ||
| apw | i have two differnt python based snaps which are not working if they are rebuilt in a bionic userspace; both exploding when installed and run with: | 08:41 |
| apw | /snap/so-trello/x1/usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /snap/so-trello/x1/usr/bin/python3) | 08:41 |
| zyga-ubuntu | apw: hey | 08:42 |
| zyga-ubuntu | apw: yo uneed to build them on xenial userspace | 08:42 |
| zyga-ubuntu | apw: I believe kalikiana is aware of the issue | 08:42 |
| zyga-ubuntu | mvo: crazy idea: include newer libc in core/ | 08:42 |
| zyga-ubuntu | ^ | 08:42 |
| apw | huh, since when did that change | 08:42 |
| apw | i thought the point was that core contained everything you might need | 08:42 |
| zyga-ubuntu | apw: bionic uses newer libc, core ships older libc | 08:42 |
| apw | and if it didn't your snap got all fat | 08:43 |
| zyga-ubuntu | apw: yes, but it doesn't contain your latest libc | 08:43 |
| apw | right, so it should be using the one in the core snap | 08:43 |
| zyga-ubuntu | apw: if by "it" you mean snapcraft then yes | 08:43 |
| zyga-ubuntu | apw: but this is hard to do, use cleanbuild to build in a container | 08:43 |
| apw | zyga-ubuntu, i'll try that then, though it should do that by defualt probabally ... | 08:45 |
| ikey | hey zyga-ubuntu wanna see somethin' cool? :) | 08:45 |
| ikey | ("cool" being at your own interpretation obv.) | 08:45 |
| zyga-ubuntu | ikey: sure :) | 08:49 |
| ikey | https://ibin.co/3jcgpSR7n4Tu.png | 08:49 |
| * zyga-ubuntu was making kitchen tidy enough to make tea | 08:49 | |
| ikey | :D | 08:49 |
| zyga-ubuntu | oooh | 08:50 |
| zyga-ubuntu | snap store | 08:50 |
| zyga-ubuntu | thank you :) | 08:50 |
| zyga-ubuntu | is that released? can I play? | 08:50 |
| ikey | its not yet :P | 08:51 |
| ikey | this is as far as i got yesterday | 08:51 |
| ikey | today i shall add more stuff | 08:51 |
| zyga-ubuntu | ikey: how is the integration, any pain points? anything missing | 08:51 |
| mvo | zyga-ubuntu: why a newer libc? | 08:51 |
| ikey | zyga-ubuntu, same as before | 08:51 |
| ikey | no caching of offline usable metadata, meaning many, many roundtrips | 08:51 |
| zyga-ubuntu | mvo: because it would be compatible with existing software and it would let people use bionic and artful libs with greater ease | 08:51 |
| ikey | no cached indexes or proper categories | 08:51 |
| ikey | no integration with appstream so having to support two visual standards | 08:52 |
| zyga-ubuntu | ikey: the api is that you talk to snapd and then snapd talks to the store, right? | 08:52 |
| ikey | right | 08:52 |
| ikey | and the list installed stuff is wonky | 08:52 |
| zyga-ubuntu | ikey: I thought we started to do appstream now | 08:52 |
| ikey | as it only has like half the meta | 08:52 |
| ikey | so even for an installed snap you need to go to the store to get the real data on it | 08:52 |
| ikey | (which seems an odd choice) | 08:52 |
| zyga-ubuntu | yes, that's true | 08:53 |
| zyga-ubuntu | Chipaca: ^ | 08:53 |
| ikey | for now im just gonna have to supplement the hand-picked snaps with some extra meta-data | 08:53 |
| ikey | due to aforementioned lack of organisation/appstream | 08:53 |
| zyga-ubuntu | ikey: hmmm | 08:53 |
| zyga-ubuntu | ikey: you should talk about this with chipaca, robert ancell and store people | 08:54 |
| ikey | this is nothing new btw, same issues as back in september | 08:54 |
| zyga-ubuntu | aha, I see | 08:54 |
| Chipaca | zyga-ubuntu: i'm aware | 08:54 |
| zyga-ubuntu | great | 08:54 |
| zyga-ubuntu | as long as we all know it will get fixed over time | 08:54 |
| ikey | the other issue is snapd startup time | 08:54 |
| ikey | its.. painful | 08:55 |
| Chipaca | my plate is full of things -- and in particular spread misbehaving in weird ways | 08:55 |
| ikey | on Solus snapd is socket activated to prevent massive boot time regressions | 08:55 |
| ikey | unfortunately it also means slowing down the startup of the SC the first time it runs | 08:55 |
| ikey | until snapd is "ready" | 08:55 |
| ikey | the same thing can be emulated just issuing "snap list" after boot | 08:55 |
| zyga-ubuntu | ikey: right | 08:55 |
| ikey | takes around 5+ seconds | 08:56 |
| zyga-ubuntu | ikey: thank you for the honest feedback! | 08:56 |
| ikey | no worries :] | 08:56 |
| Chipaca | ikey: ouch. We moved away from socket activating it -- why not start it automatically now? | 08:56 |
| zyga-ubuntu | ikey: does systemd have an "idle" schedule to run stuff when everything has settled? | 08:56 |
| Chipaca | i mean, don't make things block on it | 08:56 |
| * apw now finds snapcraft cleanbuild fails with no root device found from lxc | 08:56 | |
| Chipaca | yes, systemd does have that | 08:56 |
| ikey | because we actually care about stuff like this Chipaca | 08:56 |
| ikey | https://www.phoronix.com/scan.php?page=article&item=11-linux-boot&num=1 | 08:56 |
| ikey | spoiler: we came in just after clear linux (where I used to work) | 08:56 |
| ikey | snapd presents a huge boot time regression | 08:57 |
| Chipaca | ikey: what happpens if you set snapd's type to 'idle'? | 08:57 |
| ikey | honestly, not tried | 08:57 |
| ikey | but it has no need to be switched on during boot anyway | 08:57 |
| ikey | it should only be turned on when spoken to | 08:57 |
| Chipaca | ikey: if it's socket activated, refreshes might never happen, and retries might never happen | 08:58 |
| Chipaca | ikey: unless you've set things up for that | 08:58 |
| ikey | well. tbh i dont think automatic refreshes should be mandatory anyway | 08:58 |
| ikey | so theres another design decision im not in agreement with | 08:58 |
| ikey | for our users they risk excessive bandwidth consumption as they have no direct control over updates | 08:58 |
| Chipaca | ikey: have you been paying no attention to the quagmire of awfulness that is security in the face of no automatic updates? | 08:59 |
| ikey | i think you forget who you're talking to, Chipaca. | 08:59 |
| ikey | if you don't give users a way to at least delay an update until an appropriate time, you're pulling a Windows | 08:59 |
| mvo | ikey: 5+ seconds :/ I wonder why, that is really slow. I think we (snapd team) need to dig into this | 09:00 |
| ikey | many people are still reliant on HSDPA+/3G | 09:00 |
| ikey | and have bandwidth limitations | 09:00 |
| ikey | being able to defer the update until it is *affordable* is a must for the most basic UX requirements | 09:00 |
| Chipaca | ikey: i'm on a short fuse for personal reasons this week, please read things as if i were being 2 points more polite | 09:00 |
| ikey | throwing "security" as a blanket for piss-poor engineering in IoT isn't going to cut it | 09:00 |
| ikey | fair do. | 09:00 |
| zyga-ubuntu | as an argument here | 09:01 |
| zyga-ubuntu | I think the core should update automatically | 09:01 |
| zyga-ubuntu | services should update if started | 09:01 |
| zyga-ubuntu | and apps should be blocked from running (by default) when out-of-date | 09:01 |
| mup | PR snapd#4353 closed: hookstate: add compat "configure-snapd" task <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4353> | 09:01 |
| ikey | zyga-ubuntu, so you're gonna pull a PS4? :) | 09:01 |
| zyga-ubuntu | (especially desktop apps can have nicer notification) | 09:01 |
| * mvo hugs Chipaca | 09:01 | |
| Chipaca | ikey: you can already set updates to happen at whatever time bandwidth is cheap | 09:01 |
| ikey | "Time" ? | 09:01 |
| zyga-ubuntu | ikey: well, it's a gradient; I don't care if my apps are as up-to-date as my system | 09:01 |
| zyga-ubuntu | ikey: if I know and can act on it | 09:01 |
| ikey | Launch-blocking is one approach | 09:02 |
| zyga-ubuntu | ikey: there are ways this can change over time | 09:02 |
| ikey | And allows having deferred updates | 09:02 |
| ikey | Mandatory core updates, again I would disagree with, depending on context | 09:02 |
| ikey | If a user has LSI installed they don't need core | 09:02 |
| zyga-ubuntu | ikey: for snapd | 09:02 |
| ikey | Unless they're on Ubuntu with snapd reexec | 09:02 |
| ikey | Anywhere else, core is unnecessary | 09:02 |
| Chipaca | mvo: the police asked for a summary of all the bullying since it started, and writing all that out has been rough | 09:02 |
| ikey | zyga-ubuntu, is there any other instance core is used by snapd outside of the reexec case? | 09:03 |
| mvo | Chipaca: *meh* I can imagine :( sorry to hear that | 09:03 |
| Chipaca | reminds me i need to take thursday off to go look at a new school | 09:03 |
| zyga-ubuntu | ikey: I think core will shrink to "just snapd" over tiem | 09:03 |
| ikey | gotcha | 09:03 |
| zyga-ubuntu | ikey: as bases mature and there is a distinct 16 and 18 ubuntu base | 09:03 |
| ikey | basically, current ux: | 09:04 |
| ikey | sudo snap install --edge solus-runtime-gaming | 09:04 |
| ikey | installs core | 09:04 |
| ikey | then installs the runtime | 09:04 |
| zyga-ubuntu | Chipaca: man, that sucks. I hope it can get resolved quickly | 09:04 |
| mvo | zyga-ubuntu: do you happen to known in what fedora package "apparmor_parser" and "aa-enforce" are? same question for opensuse | 09:04 |
| ikey | runtime gets updates, linux-steam-integration does not | 09:04 |
| zyga-ubuntu | mvo: none | 09:04 |
| ikey | neither can be found in searches | 09:04 |
| zyga-ubuntu | mvo: it's not packaged | 09:04 |
| zyga-ubuntu | mvo: for suse it is just "apparmor" (in tumblweed, I believe) | 09:04 |
| ikey | in solus we give users choice over which updates are applied and when | 09:05 |
| mvo | zyga-ubuntu: ta | 09:05 |
| ikey | because, believe it or not, not ALL updates are security. | 09:05 |
| Chipaca | mvo: am i wrong in thinking 2.29 should be getting default-provider snaps automatically? | 09:05 |
| ikey | in Solus we differentiate updates at 3 levels: Mandatory, Security, Other | 09:05 |
| zyga-ubuntu | ikey: I think most users don't care; I would focus on making it less annoying and getting bandwidth under control | 09:05 |
| ikey | With all due respect, they do. | 09:06 |
| ikey | Solus users care about it a lot | 09:06 |
| ikey | Having things update beyond their control is frustrating and a kickback to the Windows world they left | 09:06 |
| ikey | And if you decide to block the launch of an app because of an update, you will have outrage unless there is a good *reason* to block it | 09:06 |
| ikey | Blocking the launch because someone decided to reshade the theme? Gonna get people vexed | 09:07 |
| ikey | Stop their laptop shutting down before a meeting because of updates? or kill their bandwidth before heading out to NZ on tethered phone for a week? Gonna piss em off :P | 09:07 |
| zyga-ubuntu | ikey: yeah, there are things to polish in the experience | 09:07 |
| Chipaca | ikey: ok, so how do you programatically tell a good reason from a bad one? | 09:07 |
| zyga-ubuntu | ikey: perhaps blocking on startup is excessive (for vast majority of updates) | 09:08 |
| zyga-ubuntu | Chipaca: they have the evil bit set | 09:08 |
| zyga-ubuntu | oh man | 09:08 |
| Chipaca | of _course_ users want their shit to just work | 09:08 |
| ikey | Chipaca, by describing an update | 09:08 |
| zyga-ubuntu | not set :) | 09:08 |
| Chipaca | :-( | 09:08 |
| ikey | so in solus we auto-describe security updates through reference to some CVE or other | 09:08 |
| ikey | and its flagged as zyga-ubuntu says | 09:08 |
| ikey | so thats security, sorta more important than "user is finicky about updates" | 09:08 |
| ikey | mandatory in snapd terms is core | 09:08 |
| ikey | i.e. required for architecture to work | 09:09 |
| ikey | (in solus thats actually libc, bash, etc) | 09:09 |
| * Chipaca goes back to hating spread because he's unfit for human interaction right now | 09:09 | |
| ikey | so you have this core set of things that will always update regardless of any other update/install/refresh, because "mandatory" ^^ | 09:09 |
| apw | zyga-ubuntu, ok this cleanbuild option is using an lxc command line which doens't work ... i needs a --storage option | 09:09 |
| ikey | compromises++ | 09:09 |
| zyga-ubuntu | apw: ask kalikiana about that please | 09:10 |
| apw | kalikiana, ^ | 09:10 |
| Chipaca | apw: you want to talk with kalikiana | 09:11 |
| Chipaca | heh | 09:11 |
| apw | talk isn't the word i want to use right now :/ | 09:11 |
| mvo | Chipaca: hi, sorry, laptop went crazy | 09:12 |
| mvo | Chipaca: so default providers, the PR is not merged yet, some complications in it | 09:12 |
| Chipaca | aw | 09:12 |
| mwhudson | apw: i don't quite know what you are doing but | 09:12 |
| apw | mwhudson, trying to make snap work again, as apparently that is impossible, i will just stop trying i think | 09:13 |
| mwhudson | apw: if you create a lxd container called "snapcraft-$project", you can use SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft build and it will use the container you created | 09:13 |
| apw | mwhudson, project as in the snap name ? | 09:13 |
| mvo | Chipaca: https://github.com/snapcore/snapd/pull/4103 | 09:13 |
| mup | PR #4103: snapstate: auto install default-providers for content snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4103> | 09:13 |
| mwhudson | apw: yes | 09:13 |
| mwhudson | apw: it's a slimy hack, but it does work | 09:14 |
| apw | mwhudson, i'd try random hack three then,. thanks | 09:14 |
| Chipaca | mvo: yikes | 09:15 |
| Chipaca | apw: nice attitude there | 09:15 |
| apw | Chipaca, heh its never a good start to your day when your snaps won't work and you can't rebuild them anymore | 09:16 |
| zyga-ubuntu | sorry about the distraction, my son hasn't arrived for classes, trying to sort this out | 09:16 |
| Chipaca | apw: I'm surprised you've not had to switch to cleanbuild ages ago; the libc change is a couple of months old already | 09:17 |
| apw | Chipaca, well apparently i can't switch to cleanbuild cause that don't work either :/ | 09:17 |
| Chipaca | apw: it does for other people, so why doesn't it for you? | 09:18 |
| ikey | hm, zyga-ubuntu, thought, what if we went in completely the opposite direction..? | 09:18 |
| Chipaca | apw: it's not a random hack; if it's not working it's a bug | 09:18 |
| ikey | instead of trying to jimmy snaps to fit distro "ways", instead use the software center to *educate* users about snaps.. | 09:18 |
| apw | Chipaca, it isn't supplying a required option to lxc on my system to start the container | 09:18 |
| apw | Chipaca, and i was refering to mwhudson's description of the next thing to try as a slimy hack | 09:18 |
| zyga-ubuntu | ikey: hmm? sorry can you please re-state your question | 09:18 |
| apw | Chipaca, not my choice of epithet for the thing i was trying | 09:18 |
| ikey | zyga-ubuntu, ok so instead of trying to force snaps to fit the old fashioned method of distro updates, instead educate users about snaps being self-updating | 09:19 |
| ikey | and why they differ | 09:19 |
| ikey | before they ever go to install one | 09:19 |
| ikey | i.e. promote the difference instead of trying to stifle it | 09:19 |
| jamesh | mvo: hi. In https://github.com/snapcore/snapd/pull/4140#issuecomment-347159305 you said you uploaded the test snap to the store. I was looking at writing a spread test using it, but can't seem to see it there. Is there anything more needed? | 09:19 |
| mup | PR #4140: interfaces: add an interface for gnome-online-accounts D-Bus service <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4140> | 09:20 |
| Chipaca | apw: ah i missed him saying that -- sorry for calling you on it then | 09:20 |
| apw | Chipaca, heh i don't mind, i _am_ feeling grumpy about it all today :) | 09:20 |
| Chipaca | apw: my main concern is that calling them hacks doesn't put the focus on getting things fixed, whereas calling them bugs does | 09:20 |
| mwhudson | Chipaca: fwiw my use case for my hack is fixed by https://github.com/snapcore/snapcraft/pull/1769 | 09:21 |
| mup | PR snapcraft#1769: lxd: add an --image argument to cleanbuild <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1769> | 09:21 |
| mwhudson | although having control over the container that gets created when you use SNAPCRAFT_CONTAINER_BUILDS would also be good | 09:22 |
| apw | mwhudson, and only installing it once with build-deps etc sounds good | 09:22 |
| * mwhudson grumbles at pylint | 09:24 | |
| mwhudson | apw: yeah | 09:25 |
| zyga-ubuntu | eh | 09:27 |
| zyga-ubuntu | mystery resolved | 09:27 |
| zyga-ubuntu | my son turned off his phone in school | 09:27 |
| zyga-ubuntu | went inside the class and waited for the teacher | 09:27 |
| zyga-ubuntu | the teacher waited outside of the class and tried to call him and then me | 09:27 |
| zyga-ubuntu | ^_^ | 09:27 |
| zyga-ubuntu | stress-- | 09:27 |
| zyga-ubuntu | back to work | 09:28 |
| zyga-ubuntu | pstolowski: branch looks good so far, I'll try to finish it quickly | 09:28 |
| zyga-ubuntu | pstolowski: sorry for the lag | 09:28 |
| * ikey passes metaphorical handkerchief to zyga-ubuntu | 09:28 | |
| pstolowski | zyga-ubuntu, np, thanks for looking at this monster | 09:28 |
| Chipaca | pstolowski: hey | 09:28 |
| Chipaca | pstolowski: what's the status of snapctl restart et al? | 09:29 |
| apw | mwhudson, that fails with: PermissionError: [Errno 13] Permission denied: 'snap/.snapcraft' | 09:29 |
| mwhudson | apw: congrats | 09:30 |
| mwhudson | ? | 09:30 |
| mwhudson | sorry that's probably not very helpful but i've not seen anything like that before | 09:30 |
| apw | i think i have to accept that snapcraft and bionic is just not a thing | 09:30 |
| apw | and create a VM to do this in | 09:30 |
| pstolowski | ? | 09:34 |
| pstolowski | ups, ignore me | 09:34 |
| Chipaca | pstolowski: did you see my question about snapctl service control? | 09:35 |
| pstolowski | Chipaca, yes, will reply | 09:35 |
| Chipaca | k | 09:35 |
| Chipaca | pstolowski: i ask because of the forum thing, you can reply there if you'd rather | 09:35 |
| pstolowski | Chipaca, yes, will reply there, I didn't respond right away cause I'm not sure if it made it in 2.30 or not at the end, need to check | 09:37 |
| pstolowski | Chipaca, replied | 09:44 |
| pstolowski | Chipaca, nb, nothing stops anyone from using systemctl + a long hard to remember name directly, right? | 09:45 |
| Chipaca | pstolowski: confinement sure does | 09:46 |
| pedronis | not inside a snap | 09:53 |
| pstolowski | right | 09:55 |
| mup | PR snapcraft#1779 closed: catkin-tools plugin: use stage-packages <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1779> | 10:02 |
| pedronis | pstolowski: Chipaca: anyway afaik and skimming the code snapctl start/stop etc made it to 2.30 | 10:02 |
| pstolowski | yes | 10:02 |
| === matteo` is now known as matteo | ||
| ShibaInu | error: cannot refresh "core": snap "core" has changes in progress | 10:20 |
| ShibaInu | what does this mean | 10:20 |
| zyga-ubuntu | ShibaInu: that "snap changes" will show that some other operation on core snap is already in progress | 10:20 |
| ShibaInu | zyga-ubuntu: not sure what is going on though, I seemingly dont have any snap running? | 10:20 |
| zyga-ubuntu | ShibaInu: run "snap changes" | 10:21 |
| ShibaInu | 27 Do 2017-11-30T10:13:40Z - Auto-refresh snap "core" | 10:21 |
| zyga-ubuntu | ShibaInu: so the message should be probably beter | 10:21 |
| zyga-ubuntu | better* | 10:21 |
| zyga-ubuntu | "refreshing of snap core is already in progress" | 10:22 |
| zyga-ubuntu | or something alike | 10:22 |
| ShibaInu | zyga-ubuntu: do you know by the way whether vulkan now works on snappy? | 10:23 |
| zyga-ubuntu | ShibaInu: I don't know, sorry | 10:23 |
| ShibaInu | ok, no problem | 10:24 |
| ShibaInu | thanks by the way | 10:24 |
| pedronis | ShibaInu: are you using core from edge? | 10:24 |
| ShibaInu | pedronis: yes | 10:24 |
| zyga-ubuntu | ShibaInu: we should have some vulkan test snap but I'm not aware of any | 10:24 |
| pedronis | ShibaInu: there was an issue that will get an update in that state, you need to abort the change , snap abort 27, the next edge build from today then should work | 10:25 |
| pedronis | or so we think | 10:26 |
| ShibaInu | pedronis: so if i do snap abort 27 i will have to wait for the next edge? or will vulkan work | 10:26 |
| pedronis | this is not about vulkan | 10:26 |
| pedronis | just the update getting stuck | 10:27 |
| ShibaInu | oh | 10:27 |
| ShibaInu | i see | 10:27 |
| ogra_ | i guess you'd have to include mesa-vulkan-drivers and libvulkan1 inside your snap | 10:28 |
| ogra_ | and allow/connect the opengl interface to give it HW access | 10:29 |
| ogra_ | (just a guess though) | 10:29 |
| cachio | mvo, test on candidate completed, we are ready to go to stable | 10:38 |
| mvo | cachio: brilliant news | 10:39 |
| mvo | cachio: lets target after the meeting, then we can briefly discuss and we need to warn the store people as well | 10:39 |
| cachio | mvo, agree | 10:39 |
| mvo | thanks cachio | 10:40 |
| zyga-ubuntu | pstolowski: almost done | 10:43 |
| pstolowski | \o/ | 10:45 |
| zyga-ubuntu | pstolowski: oh damn, those "load diff" parts of the PR | 10:47 |
| zyga-ubuntu | pstolowski: it's even longer :") | 10:47 |
| pstolowski | :} | 10:47 |
| * Chipaca -> physio while spread runs | 10:48 | |
| * zyga-ubuntu misread that as "past" | 10:49 | |
| zyga-ubuntu | "pasta" | 10:49 |
| zyga-ubuntu | uuuuhhh | 10:50 |
| zyga-ubuntu | HOW MANY ARE THERE | 10:50 |
| zyga-ubuntu | pstolowski: I wanted to say I'm near the end | 10:51 |
| zyga-ubuntu | but the end is full of "load more" buttons | 10:51 |
| zyga-ubuntu | pstolowski: I'm at lxd_support_test.go | 10:51 |
| pstolowski | zyga-ubuntu, sorry... | 10:55 |
| * zyga-ubuntu hugs pstolowski who had to _write_ all that | 10:56 | |
| pstolowski | zyga-ubuntu, https://www.youtube.com/watch?v=jHPOzQzk9Qo | 10:56 |
| zyga-ubuntu | pstolowski: when the camera pans and shows more people on crosses this is how scrolling down feel | 10:57 |
| zyga-ubuntu | *feels | 10:58 |
| zyga-ubuntu | there's more interfaces :D | 10:58 |
| pstolowski | yes, that video seems very appropriate ;) | 10:58 |
| Laney | hi | 11:10 |
| zyga-ubuntu | o/ | 11:11 |
| Laney | I'm looking for some documentation on seed.yaml | 11:11 |
| Laney | can anyone point me in the right direction? | 11:11 |
| zyga-ubuntu | mmm maybe pedronis ca | 11:13 |
| mup | PR snapd#4355 opened: release: 2.30~rc2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4355> | 11:15 |
| cachio | mvo, 30 rc2 ready for beta validation? | 11:18 |
| mvo | cachio: yes | 11:18 |
| mvo | cachio: should be a piece of cake almost no change | 11:18 |
| cachio | mvo, ok, I'll start with it | 11:18 |
| mvo | cachio: except arm/arm64, LP is busted right now and can't build those | 11:18 |
| mvo | cachio: I'm talking on #launchpad about this right now | 11:19 |
| zyga-ubuntu | mvo: uh | 11:19 |
| zyga-ubuntu | shutdown_test | 11:21 |
| cachio | mvo, ok, np | 11:23 |
| mup | PR snapcraft#1793 opened: Refactor storeapi <Created by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1793> | 11:23 |
| mup | PR snapd#4356 opened: many: add new `snap refresh --amend <snap>` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/4356> | 11:24 |
| zyga-ubuntu | amend? | 11:24 |
| jamesh | mvo: did you see my message earlier? I couldn't find the test-snapd-gnome-online-accounts snap on the store | 11:24 |
| mvo | jamesh: I did not, sorry.let me check for this snap | 11:24 |
| jamesh | mvo: I was asking in relation to https://github.com/snapcore/snapd/pull/4140#issuecomment-347159305 | 11:25 |
| mup | PR #4140: interfaces: add an interface for gnome-online-accounts D-Bus service <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4140> | 11:25 |
| jamesh | thanks | 11:25 |
| mvo | jamesh: what is your primary SSO account? if you could /msg that to me I will add access for you | 11:25 |
| mvo | jamesh: I also just published the snap | 11:25 |
| jamesh | mvo: I want to use this snap in a spread test. So doesn't that require it to be accessible to everyone? | 11:26 |
| mvo | jamesh: the snap was just not published before, I published it now | 11:26 |
| mup | PR snapcraft#1793 closed: Refactor storeapi <Created by daniellim2000> <Closed by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1793> | 11:26 |
| mvo | jamesh: so tests should work now | 11:26 |
| jamesh | mvo: okay. Thanks | 11:26 |
| mvo | jamesh: I can also give you access to this snap if you need to update it or anything like this | 11:27 |
| mvo | jamesh: if not, thats fine too of course | 11:27 |
| jamesh | mvo: okay. What identifier do you need for that? My email? | 11:27 |
| mvo | jamesh: yes, your primary sso email | 11:27 |
| jamesh | mvo: okay. That's james.henstridge@canonical.com | 11:28 |
| mvo | jamesh: just mail or /msg it to me and I add you as the snap collaborator | 11:28 |
| mvo | jamesh: ta | 11:28 |
| mvo | jamesh: the store should have send you mail | 11:28 |
| jamesh | got it. Thanks | 11:29 |
| brunosfer | Hi guys, does anyone knows what's the difference between stage-packages: and build-packages: on the .yaml identation file to create a snap? | 11:34 |
| zyga-ubuntu | yes | 11:34 |
| zyga-ubuntu | stage are unpacked into your snap | 11:34 |
| zyga-ubuntu | build aren installed on your machine to help | 11:35 |
| brunosfer | but how can they be installed on my machine if the whole core is squashfs? | 11:36 |
| brunosfer | they're built in the snap sandbox? | 11:36 |
| zyga-ubuntu | on your build machine | 11:36 |
| brunosfer | got it. thanks for the help :) | 11:36 |
| zyga-ubuntu | :) | 11:36 |
| mup | PR snapcraft#1793 opened: project: refactor storeapi <Created by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1793> | 11:41 |
| niemeyer | o/ | 11:43 |
| niemeyer | cachio: Do you want to try the image out to see what we get? | 11:43 |
| cachio | niemeyer, ok | 11:43 |
| brunosfer | Does anyone knows what's wrong here? doing on the shell "hciconfig" I get the hci0 interface, however when I do "bluez.hciconfig" it show's me the error "Can't open HCI socket.: Permission denied" | 11:45 |
| brunosfer | In all the above I use sudo | 11:45 |
| zyga-ubuntu | is the interfce connected? | 11:45 |
| zyga-ubuntu | snap interfaces | 11:45 |
| cachio | niemeyer, let's do it after the standup | 11:45 |
| brunosfer | zyga-ubuntu: I think today I forgot my brain... Thanks ;) | 11:47 |
| zyga-ubuntu | pstolowski: commented | 11:47 |
| zyga-ubuntu | brunosfer: :-) | 11:47 |
| brunosfer | zyga-ubuntu: I totally forgot to check that. | 11:47 |
| zyga-ubuntu | pstolowski: update the SPI interface next time | 11:47 |
| zyga-ubuntu | pstolowski: I'm merging it to save others from reviewing :) | 11:48 |
| === cachio is now known as cachio_afk | ||
| mup | PR snapd#4303 closed: interfaces: use ConnectedPlug/ConnectedSlot types (step 1) <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4303> | 11:48 |
| pstolowski | zyga-ubuntu, thanks, will do | 11:48 |
| mup | PR snapd#4357 opened: wrappers: autogenearte After/Before in systemd's service files for apps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4357> | 11:49 |
| mborzecki | niemeyer: pushed the fixes to #4313, appreciate if you could take another look | 11:49 |
| mup | PR #4313: timeutil: refresh timer take 2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4313> | 11:49 |
| niemeyer | mborzecki: Thanks, will do | 11:56 |
| mup | PR snapd#4358 opened: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358> | 12:06 |
| mborzecki | if anyone has got a spare moment #4340 needs reviewing | 12:07 |
| mup | PR #4340: snap: YAML and app validation parts of after/before app startup ordering <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4340> | 12:07 |
| niemeyer | mvo: Sent some notes on #4356.. general idea looks good | 12:08 |
| mup | PR #4356: many: add new `snap refresh --amend <snap>` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/4356> | 12:08 |
| niemeyer | mvo: Only real open point is how to report this to the server in the right way | 12:08 |
| niemeyer | mvo: Lying about the revision is dangerous since the server may end up inferring bogus information out of it (e.g. epochs).. | 12:08 |
| niemeyer | mvo: Will leave that with pedronis if you need to sort out over the next few days | 12:09 |
| pstolowski | niemeyer, hello! will you manage to take a quick look at #4358 before you start holidays? Just a quick early review will be very valuable (you can focus on just the repo/handlers/policy for 1st pass), so I can address any comments and start working on autoconnect changes | 12:09 |
| mup | PR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358> | 12:09 |
| niemeyer | pstolowski: Will do! | 12:09 |
| mvo | niemeyer: thanks, sounds great. I will polish it a bit and then we need to brainstorm about the lying part :) | 12:10 |
| mvo | niemeyer: (we == pedronis and I) | 12:10 |
| niemeyer | mvo: My ideal scenario is we just don't send it | 12:10 |
| niemeyer | mvo: As anything there would be bug prone | 12:11 |
| mvo | niemeyer: :+1: | 12:11 |
| * pstolowski lunch | 12:11 | |
| niemeyer | mvo: We need an ack from server team on that | 12:11 |
| niemeyer | mvo: and less urgently, we need to send the epoch too, for those specific cases, so the server can better tell what to return | 12:11 |
| mvo | niemeyer: *nod* | 12:11 |
| niemeyer | mvo: If there's a strong reason not to send anything in terms of epochs (can't think of one right now), I'd suggest just assuming the latest epoch on the server end, and hoping for the best | 12:12 |
| niemeyer | mvo: Clearly more error prone | 12:12 |
| mvo | niemeyer: yeah, makes sense. | 12:14 |
| mvo | niemeyer: there will be a bit of risk in any case, snapd knows (potentially) very little about the snap. but my gut-feeling is that 99% of the users/use-case will be developers of their own snaps | 12:15 |
| mvo | niemeyer: in any case, thanks for your thoughts on this! | 12:15 |
| niemeyer | mvo: Right, exactly.. my main concern is misbehavior on the sweet spot of the use cases precisely | 12:16 |
| * mvo nods | 12:16 | |
| niemeyer | mvo: Someone trying to cook an epoch upgrade will have trouble if the store doesn't know what epoch to assume | 12:16 |
| niemeyer | mvo: Noting here that our spec for epochs allows a posteriori uploads for any epoch | 12:17 |
| pedronis | epoch will only happen with the new apis, and there we have places to do the right thing | 12:18 |
| pedronis | I need to double what the store does with revisions in the current api | 12:18 |
| pedronis | *double check | 12:18 |
| Chipaca | mvo: ikey: about startup time, note that if, as some people have asked, we need to checksum snaps on boot, startup time is going to go to heck (i'd propose making that fsck manual on classic fwiw) | 12:19 |
| niemeyer | pedronis: Right, this is definitely about the upcoming API, not the current one.. it's mainly about being aware of this need, as I recall it being written off as unnecessary in one of our conversations | 12:26 |
| zyga-ubuntu | mborzecki: can you please have look at 4315 again? | 12:32 |
| mborzecki | ok | 12:32 |
| mborzecki | looking | 12:32 |
| zyga-ubuntu | thank you | 12:32 |
| zyga-ubuntu | I could use a review on 4329 | 12:38 |
| zyga-ubuntu | niemeyer: ^ not sure if you want to take that one today | 12:39 |
| pedronis | Laney: what's the question about seed.yaml ? | 12:59 |
| === cachio_afk is now known as cachio | ||
| mup | PR snapd#4355 closed: release: 2.30~rc2 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4355> | 13:34 |
| brunosfer | zyga-ubuntu: Could you help me out with the plug connection from bluez service in snap? I can't figure out how to connect the bluez slot with the bluetooth-controller so that I can have access to the hci0 from shell. | 13:38 |
| zyga-ubuntu | brunosfer: so what did you try? | 13:39 |
| brunosfer | zyga-ubuntu: The documentation here: https://github.com/snapcore/snapd/wiki/Interfaces is too evasive, just refer to a snap that you already have to consume the bluetooth service. | 13:40 |
| zyga-ubuntu | brunosfer: I'm curiouto know what you tried | 13:40 |
| brunosfer | zyga-ubuntu: sudo snap connect bluez:bluetooth-control core:blue | 13:40 |
| brunosfer | zyga-ubuntu: sudo snap connect bluez:bluetooth-control core:bluez | 13:40 |
| morphis | brunosfer: you can't intermix plugs/slots with different interfaces | 13:40 |
| zyga-ubuntu | brunosfer: what is the name of the snap you are trying to use? bluez? | 13:41 |
| brunosfer | zyga-ubuntu: yes | 13:41 |
| morphis | brunosfer: the bluez interface only gives you access to the bluez DBus API | 13:41 |
| morphis | if you want raw access to hci0 you need bluetooth-control | 13:41 |
| morphis | define a plug in your snap for it | 13:41 |
| morphis | plugs: | 13:41 |
| morphis | bluetooth-control: | 13:42 |
| brunosfer | I want to connect bluez to the controller so I can replicate the same behaviour I have in classic mode when I do hciconfig anf the hci0 interface pops up | 13:42 |
| morphis | interface: bluetooth-control | 13:42 |
| morphis | or event shorter with just plugs: [bluetooth-control] | 13:42 |
| brunosfer | I don't have a snap built yet... I'm trying to access the interface using the console | 13:42 |
| morphis | brunosfer: btw. if you can you shouldn't use hciconfig anymore | 13:42 |
| morphis | the easiest and best is to go through the bluez dbus API to power up the interface | 13:43 |
| brunosfer | thanks for the advice, but for testing purposes I would like to know how can I attach the interface of bluez with the console... | 13:44 |
| ogra_ | you dont need interfaces on the console | 13:44 |
| morphis | not sure what you mean by that | 13:44 |
| ogra_ | interfaces are for interaction between snaps ... | 13:45 |
| ogra_ | on the console you can do everything you want ... interfaces wont apply there | 13:45 |
| brunosfer | if I want to refer to a specific interface such as hci5 | 13:46 |
| ogra_ | thats a device :) | 13:46 |
| brunosfer | how can I specify that if I only have a interface... | 13:46 |
| ogra_ | i was referring to snap interfaces | 13:46 |
| ogra_ | how would you access that device on any other linux ? | 13:46 |
| morphis | brunosfer: where do you want to specify that? | 13:46 |
| ogra_ | it isnt different ... | 13:47 |
| brunosfer | I'm struggling here with all the changes in the OS, I was so used with the classic mode... | 13:47 |
| morphis | brunosfer: what exactly are you trying to do? | 13:47 |
| brunosfer | I want to replicate the same behaviour in classic mode when you type "hciconfig" on the shell and you see the devices you have | 13:49 |
| sergiusens | mpt_ hello again, I keep pinging you because your insight is really good! I have another PR which could use your input snapcraft#1789 | 13:51 |
| mup | PR snapcraft#1789: cli: improve the help command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1789> | 13:51 |
| zyga-ubuntu | hmmm | 13:52 |
| zyga-ubuntu | ogra_: | 13:52 |
| zyga-ubuntu | ogra_: do you have a moment: | 13:52 |
| ogra_ | zyga-ubuntu, sure | 13:52 |
| zyga-ubuntu | ogra_: can you grab any core device you have around you and run losetup --all | 13:53 |
| morphis | brunosfer: so you want to put hciconfig into a snap? | 13:53 |
| brunosfer | I have an application that uses bluez API and I want to port it to a snap. | 13:54 |
| brunosfer | But first, I want to make sure I understand well how plugs and slots, work, so I can move on with the snap. | 13:55 |
| zyga-ubuntu | ogra_: how many times is core attached? | 13:56 |
| zyga-ubuntu | brunosfer: plugs and slots are endpoints on snaps | 13:56 |
| brunosfer | my idea is to connect the bluetoothctl and try out, in classical mode it works, in ubuntu core using the bluez.hciconfig it says I have permissions for hci0 | 13:56 |
| ogra_ | zyga-ubuntu, http://paste.ubuntu.com/26118700/ | 13:56 |
| zyga-ubuntu | brunosfer: as long as the interfaces of each side are compatible you can connect them together | 13:56 |
| zyga-ubuntu | brunosfer: snapd changes the confinement system affecting each snap | 13:57 |
| ogra_ | zyga-ubuntu, on some i had run snap abort for a hanging core already (pi3 and joule) | 13:57 |
| zyga-ubuntu | /dev/loop0: []: (/writable/system-data/var/lib/snapd/snaps/core_3587.snap) | 13:57 |
| zyga-ubuntu | /dev/loop3: []: (/var/lib/snapd/snaps/core_3587.snap) | 13:57 |
| zyga-ubuntu | why is this happening? | 13:57 |
| brunosfer | zyga-ubuntu: you mean that I just need to run my sdp server as in classic mode and building the snap it magically connects to the correct interface hci0 in this case? | 13:58 |
| zyga-ubuntu | ogra_: something is not detaching those | 13:58 |
| ogra_ | zyga-ubuntu, you tell me :) | 13:58 |
| zyga-ubuntu | brunosfer: no | 13:58 |
| zyga-ubuntu | brunosfer: I just told you what interfaces are in general, | 13:58 |
| mpt_ | looking | 13:58 |
| === mpt_ is now known as mpt | ||
| zyga-ubuntu | brunosfer: specific interfaces (e.g. the bluez interface) have particular behavior that may or may not fit your use case | 13:59 |
| ogra_ | zyga-ubuntu, they are double mounted ... thats the design of assembling the rootfs i think | 13:59 |
| zyga-ubuntu | ogra_: they are not only double mounted, the same core is loop-attached twice to separate loop devices | 13:59 |
| ogra_ | zyga-ubuntu, i.e. we mount /writable from initrd, then mount the snap ... then do all the bind mounting back into /writable for rw stuff and then use run-init to switch the rootfs | 13:59 |
| ogra_ | the original snap mount will stay | 14:00 |
| zyga-ubuntu | ogra_: mmmm | 14:00 |
| ogra_ | zyga-ubuntu, and then i guess systemd mounts them again due to having a .mount unit | 14:00 |
| zyga-ubuntu | ogra_: aha | 14:00 |
| zyga-ubuntu | ogra_: I see | 14:00 |
| zyga-ubuntu | ogra_: thanks! | 14:00 |
| * zyga-ubuntu knows more but needs to see why his test is still failing | 14:01 | |
| ogra_ | we could perhaps make these mount usingts skipped ... based on /proc/cmdline or so | 14:01 |
| ogra_ | since we dont really need them mounted twice | 14:01 |
| ogra_ | (but can not "not mount" them when assembling the rootfs) | 14:01 |
| zyga-ubuntu | ogra_: right | 14:02 |
| ogra_ | i'm not sure if "mount --move" would work here to move the existing mount to a new place ... | 14:02 |
| zyga-ubuntu | ogra_: ideally we'd mount them but reuse the loopback device | 14:02 |
| ogra_ | sounds risky in any case though | 14:02 |
| ogra_ | yeah or that | 14:02 |
| ogra_ | will need a *lot* of testing though ... after all you suffle stuff around unterneath your rootfs / | 14:03 |
| ogra_ | *shuffle | 14:03 |
| * zyga-ubuntu analyzes http://pastebin.ubuntu.com/26118742/ | 14:05 | |
| pstolowski | niemeyer, i've just addressed the last tiny bit in #4301, would be great if you had another look at it, it's a prerequisite for everything else re interface hooks | 14:08 |
| mup | PR #4301: interfaces: PlugInfo/SlotInfo/ConnectedPlug/ConnectedSlot attribute helpers <Created by stolowski> <https://github.com/snapcore/snapd/pull/4301> | 14:08 |
| zyga-ubuntu | ha | 14:16 |
| zyga-ubuntu | ok | 14:16 |
| zyga-ubuntu | niemeyer: that issue I talked about in the call, it's actually trickier | 14:17 |
| zyga-ubuntu | niemeyer: but I now have a full(er) picture | 14:17 |
| zyga-ubuntu | niemeyer: it relates to those loop devices I spoke with ogra above | 14:17 |
| zyga-ubuntu | niemeyer: I think I just need to adjust logic to check that the / inside matches / outside (when snap name == "core") | 14:17 |
| zyga-ubuntu | niemeyer: because on core / is mounted in initrd and it is a spearate mount of the same snap (but has different loopback device) | 14:18 |
| zyga-ubuntu | niemeyer: alternatively we could not perform this detection when running on core and when the base snap is "core" | 14:18 |
| zyga-ubuntu | niemeyer: as any change would warrant a reboot | 14:18 |
| ogra_ | cant you just match the mountpint and ignore it if there is /writable involved ? or will that use the wrong loop device ? | 14:19 |
| om26er | kyrofa: ping | 14:19 |
| zyga-ubuntu | ogra_: what do you mean by match the mountpoint? | 14:20 |
| ogra_ | zyga-ubuntu, well, if you check the loop device you surely also check where it is mounted, no ? if the mountpoint contains /writable it is the one mounted from the initrd | 14:21 |
| zyga-ubuntu | ogra_: no, we don't do that | 14:21 |
| ogra_ | ah ,k | 14:21 |
| zyga-ubuntu | ogra_: we don't look at loop devices at all | 14:22 |
| zyga-ubuntu | ogra_: we look at what the current base device is outside | 14:22 |
| zyga-ubuntu | ogra_: and what / is inside | 14:22 |
| zyga-ubuntu | ogra_: and compare device numbers | 14:22 |
| ogra_ | ah, k | 14:22 |
| zyga-ubuntu | ogra_: I think it's not far but I need to tweak that somehow | 14:22 |
| ogra_ | zyga-ubuntu, technically your rootfs core snap is always on loop0 ... since it is the very first thing we mount | 14:23 |
| ogra_ | in case that helps ... | 14:23 |
| zyga-ubuntu | ogra_: I don't look at just core, I'm checking the designated base snap | 14:24 |
| zyga-ubuntu | ogra_: it could be core but doens't need to be | 14:24 |
| ogra_ | well, there i dont know how michael plans to assemble the rootfs | 14:24 |
| * zyga-ubuntu thinks what to do | 14:24 | |
| ogra_ | but i imagine even there core would be 0 or 1 | 14:24 |
| zyga-ubuntu | ogra_: I think I just want to adjust this to work with what we do today | 14:24 |
| joc | does anyone know if the snapd 2.30 has any REST API changes in it? | 14:25 |
| zyga-ubuntu | ogra_: regardless if it is core (we can have bootable bases too) | 14:25 |
| ogra_ | depending if you first mount base or first mount core | 14:25 |
| zyga-ubuntu | joc: hey, probably, what are you seeing? | 14:25 |
| ogra_ | we have to :) | 14:25 |
| ogra_ | (i understand core+base is just todays core cut in half ... ) | 14:26 |
| joc | zyga-ubuntu: we use /v2/snaps to get list of installed snaps - when running on beta channel that's failing | 14:26 |
| ogra_ | (at least in the bootable case) | 14:26 |
| joc | zyga-ubuntu: think maybe the devmode field got removed? | 14:27 |
| pedronis | joc: it's omitted when false | 14:28 |
| pedronis | now | 14:28 |
| pedronis | mmh | 14:28 |
| pedronis | if it's a problem we have stuff to revert | 14:28 |
| pedronis | mvo: ^ | 14:28 |
| joc | pedronis: well we like to record details of the system we are testing and if snaps are in devmode it is useful to know | 14:31 |
| cwayne | joc: is that what's making our snap list test fail? | 14:31 |
| joc | cwayne: yes i believe so | 14:32 |
| pedronis | mvo: we might have to undo more of robert change | 14:32 |
| pedronis | or all of it | 14:32 |
| pedronis | joc: you are hitting this: https://github.com/snapcore/snapd/pull/4260 | 14:33 |
| mup | PR #4260: Stop various JSON field from being sent with null values <Created by robert-ancell> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4260> | 14:33 |
| pedronis | it seems it does for bools as well which is a bit questionable | 14:34 |
| === cachio is now known as cachio_lunch | ||
| Laney | pedronis: sorry for the late reply, I'm working on seeding snaps for Ubuntu images and c_jwatson said that classic snaps need to be specified differently in seed.yaml, so I was looking for docs to show me how to do that | 14:39 |
| pedronis | Laney: they need classic: true in the snap entry | 14:40 |
| pedronis | otherwise they are like the reset | 14:40 |
| pedronis | s/reset/rest/ | 14:41 |
| joc | pedronis: whatever your decision we would like to know soon as this breaks our test runs when that version of snapd is present, we would have to release new versions of checkbox snaps | 14:41 |
| Chipaca | niemeyer: where should the snap.yaml me documented? | 14:41 |
| Chipaca | i'm a bit lost | 14:41 |
| niemeyer | Chipaca: The #doc category.. not sure if we have that already, or if it's still in the old wiki | 14:41 |
| pedronis | joc: best to wait for mvo to have an opinion on this, I would be keen to revert myself but I also don't know what was robert motivation for the change, just tidiness or what | 14:42 |
| Laney | pedronis: ok, so just name/channel/classic: true then? | 14:43 |
| Laney | got an example of one in your head that I can test with? :-) | 14:43 |
| pedronis | Laney: and file and snap-id | 14:43 |
| pedronis | Laney: no | 14:44 |
| Laney | oh yes we have file too | 14:44 |
| Laney | not snap-id though | 14:44 |
| pedronis | Laney: is this code in ubuntu-image for classic images? | 14:45 |
| Laney | https://bazaar.launchpad.net/~laney/livecd-rootfs/snap-seeding/view/head:/live-build/auto/build#L35 | 14:45 |
| pedronis | live-build? | 14:45 |
| Laney | ish | 14:45 |
| pedronis | not ubuntu-image though? | 14:45 |
| Chipaca | niemeyer: here https://forum.snapcraft.io/t/the-snap-format/698 ? | 14:46 |
| pedronis | Chipaca: yes | 14:47 |
| pedronis | I was about to give you that link | 14:47 |
| * pedronis needs to take a break | 14:48 | |
| Laney | pedronis: no, deb based images with some snaps added | 14:49 |
| mup | PR snapcraft#1791 closed: tests: python plugin integration tests moved to a separate suite <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1791> | 14:54 |
| mvo | joc: sorry for the delay, my suggestion is to open a forum topic, invite robert to it so that he can weight in, I am fine with reverting fwiw | 14:55 |
| joc | ok | 14:56 |
| pedronis | mvo: the PR just mentioned debugging and size of payload, OTOH the fix for Tracks is needed | 14:57 |
| mvo | pedronis: right, I can prepare a partial revert PR | 14:59 |
| === cachio_lunch is now known as cachio | ||
| elopio | hey zyga-ubuntu, would you like to review some polish subtitles for a short snapcraft video? | 15:19 |
| zyga-ubuntu | elopio: sure | 15:23 |
| zyga-ubuntu | elopio: I'm going to pick my son from school but I can review it soon, just give me a link | 15:23 |
| elopio | zyga-ubuntu: https://www.youtube.com/timedtext_editor?action_mde_edit_form=1&v=ZsUV9xnrkTA&lang=pl&bl=csq&ui=cr | 15:24 |
| elopio | thank you! | 15:24 |
| * kalikiana waves at elopio | 15:26 | |
| * kalikiana coffee break | 15:26 | |
| sergiusens | elopio help PR updated | 15:36 |
| sergiusens | kyrofa you might want to look at my help PR as there's something there you can use ;-) | 15:37 |
| Chipaca | niemeyer: pedronis: should we still be documenting the 'aliases' entry in snap.yaml? | 15:42 |
| niemeyer | mborzecki: Almost finished | 15:43 |
| niemeyer | mborzecki: Will you be around for a bit still? Would like to discuss any open points | 15:43 |
| niemeyer | Chipaca: It's dead, so probably not :) | 15:43 |
| Chipaca | at some point we're going to want to split the snap.yaml bit out of that doc | 15:45 |
| Chipaca | not today tho | 15:45 |
| * Chipaca gets back to hating tests | 15:45 | |
| zyga-ubuntu | elopio: sure | 15:47 |
| Chipaca | also not in that doc: assumes | 15:47 |
| zyga-ubuntu | elopio: done | 15:50 |
| zyga-ubuntu | elopio: I re-wrote it mostly | 15:50 |
| zyga-ubuntu | elopio: not very bad but very machine-translated IMO (too direct) | 15:51 |
| zyga-ubuntu | elopio: you can get (plenty) of 2nd reviews from pstolowski or mborzecki :) | 15:51 |
| * zyga-ubuntu prints something and goes to figure out a solution on paper | 15:51 | |
| pstolowski | elopio, hey, yeah polish are majority in snapd team now, you can take advantage of that :) | 15:54 |
| mborzecki | niemeyer: yeah, i can be around | 15:54 |
| zyga-ubuntu | elopio: resistance is futile :) | 15:55 |
| elopio | zyga-ubuntu: pstolowski: great! :) Thanks. | 15:56 |
| zyga-ubuntu | elopio: how did you get the initial translation | 15:57 |
| zyga-ubuntu | elopio: was that google translate? | 15:57 |
| zyga-ubuntu | jdstrand: hey, are you around? | 15:57 |
| elopio | zyga-ubuntu: google code-in. | 15:57 |
| zyga-ubuntu | elopio: aha | 15:57 |
| elopio | zyga-ubuntu: maybe, they didn't do the work :/ | 15:58 |
| zyga-ubuntu | elopio: no, I doubt they would do that; it is exactly like how I translated things when I was younger | 15:59 |
| zyga-ubuntu | elopio: (I started as a translator) | 15:59 |
| elopio | zyga-ubuntu: did you check the title and description too? | 15:59 |
| * kalikiana feeling lonely at the snapcraft weekly HO | 16:00 | |
| Chipaca | niemeyer: why is spread's order with -shell different from without it, for a given seed? is that on purpose? | 16:01 |
| Chipaca | niemeyer: wait, ignore me, typo on the commandline | 16:02 |
| mup | PR snapcraft#1774 closed: storeapi: support for pushing binary metadata <Created by matiasb> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1774> | 16:03 |
| pstolowski | zyga-ubuntu, are you updating these subtitles or shall I? | 16:04 |
| pedronis | Chipaca: I think snapcraft started deprecating it in 2.35 | 16:05 |
| pedronis | sergiusens: hi, is snapcraft still SRUed, or snap only for new stuff? | 16:06 |
| niemeyer | Chipaca: Phew! | 16:08 |
| niemeyer | mborzecki: Sent! | 16:08 |
| niemeyer | mborzecki: Please let me know if you want to have a call on this | 16:08 |
| jdstrand | zyga-ubuntu: yes | 16:08 |
| cachio_ | niemeyer, any news on the rawhide image? | 16:16 |
| niemeyer | cachio_: No, it's still quietly awaiting | 16:16 |
| niemeyer | ;) | 16:16 |
| niemeyer | cachio_: Let me confirm mborzecki is good to go, and I'll look into it | 16:17 |
| Chipaca | aw, for a moment I read "it's still quietly amazing", and was happy | 16:17 |
| cachio_ | niemeyer, sure | 16:19 |
| om26er | Hi! Now that snapcraft 2.35 is in xenial-updates, will build.snapcraft use that for the next build that kicks in ? | 16:45 |
| om26er | nessita: ^ | 16:45 |
| nessita | om26er, I have no idea! could you please ask someone from the web team? they maintain build. | 16:47 |
| nessita | om26er, but I'm interested in teh answer if you find out :-) | 16:47 |
| mup | Issue snapcraft#1794 opened: Apply patchelf work to non classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1794> | 16:55 |
| om26er | popey: are you around ? | 16:57 |
| popey | om26er: sup | 16:58 |
| om26er | popey: need you to merge a few PRs on android-studio snap project. | 16:58 |
| om26er | https://github.com/snapcrafters/android-studio/pull/4 | 16:58 |
| mup | PR snapcrafters/android-studio#4: Revert "explicitly make studio.sh executable" <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/4> | 16:58 |
| popey | will take a look in a bit | 16:59 |
| om26er | and https://github.com/snapcrafters/android-studio/pull/5 | 16:59 |
| mup | PR snapcrafters/android-studio#5: new version <Created by rajabiy> <https://github.com/snapcrafters/android-studio/pull/5> | 16:59 |
| om26er | Alright, thanks popey | 16:59 |
| kalikiana | kyrofa: can we have a HO tomorrow your morning to talk about bug 1686481 ? as in, whether/ how we want to try and work-around packaging problems | 17:03 |
| mup | Bug #1686481: stage-packages does not handle unmet dependencies <kubernetes> <Snapcraft:In Progress by kalikiana> <https://launchpad.net/bugs/1686481> | 17:03 |
| * kalikiana will add another comment on the bug before eod'ing | 17:06 | |
| kyrofa | kalikiana, sure thing | 17:08 |
| kyrofa | kalikiana, you can schedule one, or ping me, my morning is open | 17:09 |
| * Chipaca brb, other laptop is growing a bulge and needs help | 17:09 | |
| kyrofa | Chipaca, oh no | 17:09 |
| Chipaca | kyrofa: "why is the trackpad no longer working!!!" grumbled the kids | 17:09 |
| Chipaca | tell you why: the laptop was a pillo | 17:10 |
| Chipaca | pillow* | 17:10 |
| kyrofa | Yikes, I somehow doubt "help" is what it needs | 17:10 |
| popey | kyrofa: who 'owns' the "snapcraft enable-ci travis" command? | 17:13 |
| kyrofa | popey, well, we do I suppose | 17:13 |
| kyrofa | What's up? | 17:13 |
| popey | if I run it, it spits out a wall of text then says [y/N]. What exactly is it asking me there? | 17:13 |
| popey | There are no questions. | 17:14 |
| om26er | who shall I talk to for a quick query about build.snapcraft ? | 17:14 |
| popey | om26er: just ask away | 17:14 |
| om26er | I did, above :) | 17:15 |
| om26er | "Now that snapcraft 2.35 is in xenial-updates, will build.snapcraft use that for the next build that kicks in ?" | 17:15 |
| kyrofa | popey, hmm, I think that should be more of a "continue? [y/N]" type thing | 17:15 |
| kyrofa | popey, not the best experience, agreed | 17:15 |
| kyrofa | popey, I don't remember the justification, but I suspect it was wanting to point out that this is experimental | 17:16 |
| popey | ok | 17:16 |
| popey | ta | 17:16 |
| popey | om26er: yes, should do, I see xenial-updates in the build log | 17:18 |
| om26er | super! that unblocks both AndroidStudio and SublimeText. | 17:18 |
| kyrofa | om26er, sorry, missed that question. Indeed, it should be working now | 17:18 |
| popey | om26er: merged those two, keep an eye on the build log :) | 17:29 |
| om26er | popey: great. will keep looking. | 17:30 |
| mup | PR snapcraft#1795 opened: Don't include source tarballs from previous runs <Created by ted-gould> <https://github.com/snapcore/snapcraft/pull/1795> | 17:31 |
| kalikiana | kyrofa: awesome, will do. thanks! | 17:31 |
| * kalikiana sent out meeting minutes as well | 17:31 | |
| kalikiana | now time for dinner | 17:32 |
| sergiusens | kalikiana enjoy | 17:35 |
| kalikiana | thanks! | 17:36 |
| mup | Bug #1736541 opened: core rest api docs out of date <snap-docs> <Snappy:New> <https://launchpad.net/bugs/1736541> | 17:40 |
| om26er | popey: Need you to setup sublime text for auto build in build.snapcraft, the packaging is already there. | 17:40 |
| om26er | ...whenever you can. | 17:40 |
| jdstrand | mvo: is this known when running ./run-checks: http://paste.ubuntu.com/26119892/ | 17:41 |
| jdstrand | mvo: this is running the tests on an artful host in a xenial lxd container | 17:42 |
| mup | PR snapd#4359 opened: interfaces/many: misc updates for default, browser-support, opengl, desktop, unity7, x11 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4359> | 17:50 |
| sergiusens | elopio any update on the help PR? | 17:55 |
| popey | om26er: ok, doing now | 17:59 |
| elopio | sergiusens: +1. | 18:01 |
| popey | om26er: building now | 18:01 |
| om26er | great stuff | 18:01 |
| om26er | seems amd64 builders are quite busy today | 18:02 |
| kyrofa | sergiusens, snapcraft#1780 is ready for another look | 18:02 |
| mup | PR snapcraft#1780: cli: add export-login command <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1780> | 18:02 |
| jdstrand | mvo: fyi, that happens in both master and release/2.30 | 18:06 |
| === alan_g is now known as alan_g|EOD | ||
| mvo | jdstrand: not known, let me try to reproduce | 18:06 |
| mvo | jdstrand: I assume 4359 targets 2.30 ? | 18:07 |
| sergiusens | kyrofa just looking | 18:07 |
| sergiusens | kyrofa also `patchelf --print-needed` | 18:08 |
| kyrofa | sergiusens, oooo! | 18:08 |
| sergiusens | kyrofa and I followed up on the rpath one | 18:08 |
| mup | PR snapd#4360 opened: interfaces/many: misc updates for default, browser-support, opengl, desktop, unity7, x11 for 2.30 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4360> | 18:08 |
| mvo | jdstrand: :) and \o/ | 18:09 |
| jdstrand | mvo: oh heh, I was trying to be good then I saw you milestoned 4359 :) | 18:09 |
| jdstrand | mvo: so both are milestoned. I guess I should remove the 4359 one? | 18:10 |
| * jdstrand removes | 18:10 | |
| jdstrand | if you want it back, holler | 18:10 |
| mvo | jdstrand: yes | 18:11 |
| mvo | jdstrand: I mean, what you did (remove) if fine | 18:11 |
| jdstrand | thanks :) | 18:11 |
| mvo | sergiusens, kyrofa, stgraber - hey, just a quick heads up, we have a new snapd in the candidate channel it should fix issues with lxd. if you guys could just run it a little bit to make sure there is nothing wrong with it, that would be great | 18:13 |
| stgraber | mvo: what issue? | 18:14 |
| kyrofa | mvo, does that include https://forum.snapcraft.io/t/lxc-snaps-dont-update/786 ? | 18:14 |
| kyrofa | Or the one reported in the release thread? | 18:15 |
| mvo | kyrofa: the one from the release thread. afaik zyga-ubuntu is working on the other issue still | 18:15 |
| kyrofa | mvo, alright, thank you | 18:16 |
| mvo | stgraber: the fix for snap-confine to work correctly under lxd, its finally in candidate | 18:16 |
| om26er | is there a way to check the size of delta between two revisions of a snap in store ? | 18:16 |
| mvo | stgraber: i.e. this one https://github.com/snapcore/snapd/pull/4246 is the most important change | 18:16 |
| mup | PR #4246: snap-confine: fix snap-confine under lxd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4246> | 18:16 |
| mup | PR snapd#4339 closed: userd: generalize dbusInterface <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4339> | 18:20 |
| mup | PR snapd#4317 closed: tests: make interfaces-snapd-control-with-manage more robust <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4317> | 18:21 |
| Chipaca | nearly there! got a strace | 18:26 |
| Chipaca | but now i need to stop | 18:26 |
| Chipaca | fun thing: the strace only succeeds in repro'ing the issue if it's not writing to stdout | 18:26 |
| Chipaca | so there's a timing issue the size of a bus, i reckon | 18:27 |
| Chipaca | yikes, 30 minutes past get-stinky-boys-in-the-water | 18:27 |
| * Chipaca runs | 18:27 | |
| zyga-ubuntu | re | 18:28 |
| zyga-ubuntu | jdstrand: o/ :) | 18:28 |
| zyga-ubuntu | how are things? | 18:29 |
| zyga-ubuntu | kyrofa: no updates still, it's all non trivial I'm afraid | 18:30 |
| jdstrand | mvo: fyi, I ran run-checks with release/2.29 and it doesn't fail | 18:30 |
| zyga-ubuntu | kyrofa: so I'm still working on a related but not quite the same issue | 18:30 |
| jdstrand | zyga-ubuntu: hey :) | 18:30 |
| zyga-ubuntu | jdstrand: the more I look at mount stuff | 18:30 |
| zyga-ubuntu | jdstrand: the more it is like that abyss quote | 18:30 |
| jdstrand | heh and :\ | 18:31 |
| zyga-ubuntu | jdstrand: today I realized that / is not the core snap (separate loopback device) | 18:31 |
| zyga-ubuntu | jdstrand: and that / is mounted twice from the same device | 18:31 |
| zyga-ubuntu | jdstrand: and that the mount table is ~400 element-strong which is a bit crazy | 18:32 |
| jdstrand | yeah. haven't been thrilled with how big that table is | 18:32 |
| * zyga-ubuntu printed http://pastebin.ubuntu.com/26118789/ | 18:34 | |
| jdstrand | a lot of that is the writable-path stuff | 18:43 |
| mvo | fwiw, I want to kill writable-path for base-18 | 18:47 |
| mvo | but it will be quite a bit of work | 18:47 |
| lundmar | I only need just one more +1 here https://forum.snapcraft.io/t/request-autoconnect-avahi-observe-plug-for-lxi-tools/2976 . Please :) | 18:51 |
| mvo | niemeyer: I guess you are super busy with a gazilion of things, if there is a free spot a high level opinion on 4342 would be great (the abstrace UI PR) | 18:53 |
| zyga-ubuntu | lundmar: LXI as in that test equipment protocol? | 18:58 |
| zyga-ubuntu | lundmar: I'll vote | 18:59 |
| zyga-ubuntu | done | 19:00 |
| jdstrand | well, it needs someone from the reviewers team | 19:02 |
| jdstrand | kyrofa: hey, perhaps you would like to weigh in on https://forum.snapcraft.io/t/request-autoconnect-avahi-observe-plug-for-lxi-tools/2976 for lundmar? | 19:05 |
| kyrofa | jdstrand, happily, let me do some quick research as well | 19:07 |
| jdstrand | thanks | 19:07 |
| lundmar | zyga-ubuntu: exactly, the LXI standard that most modern T&M instruments supports. lxi-tools is an open source effort to support this open standard. | 19:08 |
| lundmar | zyga-ubuntu: If you test lxi-tools with an instrument which is not in the list of tested instruments (see https://github.com/lxi-tools/lxi-tools) please let me know and I will add it to the list. That is, if it works ;) | 19:11 |
| zyga-ubuntu | lundmar: looking at the lsit | 19:12 |
| zyga-ubuntu | lundmar: nowadays I just have my power supply left | 19:12 |
| kyrofa | jdstrand, that slot isn't supplied by the core snap on ubuntu core, right? | 19:12 |
| zyga-ubuntu | lundmar: I have rigol DP832 which is on the list | 19:13 |
| mborzecki | /quit/quit | 19:13 |
| zyga-ubuntu | lundmar: thank you :) | 19:13 |
| lundmar | hehe, your welcome ;) | 19:13 |
| lundmar | DP832 is awesome | 19:13 |
| lundmar | except for the fan noise ofc haha | 19:14 |
| zyga-ubuntu | haha, my thoughts exactly | 19:14 |
| zyga-ubuntu | it's a very sturdy and reliable unit | 19:14 |
| zyga-ubuntu | just noisy :) | 19:14 |
| zyga-ubuntu | and the feature set is very good for the price | 19:14 |
| lundmar | yes, heavy = quality :) | 19:14 |
| cachio_ | niemeyer, https://travis-ci.org/snapcore/snapd/builds/311803585#L1078 | 19:16 |
| cachio_ | when we run the tests from travis fedora-27 is not starting neither | 19:16 |
| cachio_ | niemeyer, it is weird because from my machine I can run on fedora-27 | 19:17 |
| cachio_ | niemeyer, using the API is it póssible to see the console output? | 19:17 |
| zyga-ubuntu | lundmar: I used to have an agilent DSOX A2004 but without the lan interface | 19:24 |
| zyga-ubuntu | lundmar: is the usb protocol very different from LXI? | 19:24 |
| zyga-ubuntu | (the protocol wrapped in USB) | 19:24 |
| lundmar | zyga-ubuntu: not in the sense they both supports sending SCPI commands | 19:25 |
| lundmar | but compared, USB is basically just a raw connection, no protocol. | 19:26 |
| zyga-ubuntu | so that rigol power supply, the USB interface to control is is totally distinct to the network interface? | 19:27 |
| zyga-ubuntu | or are you saying that both wrap SCPI | 19:27 |
| lundmar | both wrap SCPI | 19:27 |
| lundmar | LXI can use three protocols: RAW/TCP, VXI11/TCP, and HISLIP/TCP. The latter is next gen and I'm currently implementing the protocol so we can have a first class open source offering for it. | 19:29 |
| lundmar | the need for avahi/zeroconf is also next gen | 19:30 |
| niemeyer | cachio_: I'm not sure to be honest.. I haven't | 19:30 |
| lundmar | zyga-ubuntu: let me know if you run into issues with the lxi-tools snap. If you can confirm that the screenshot feature works with your DP832 that would be helpful. | 19:32 |
| zyga-ubuntu | lundmar: trying | 19:33 |
| cachio_ | mvo, the install cache test is failing in all the snap cores | 19:36 |
| cachio_ | mvo, basically the logs don't contain any information about the cache | 19:36 |
| zyga-ubuntu | lundmar: "Broadcasting on interface lo | 19:36 |
| zyga-ubuntu | lundmar: I think that's silly ;) | 19:37 |
| cachio_ | mvo, should I create a forum topic or you want to take a look first | 19:37 |
| zyga-ubuntu | lamont: woot, works like a charm | 19:37 |
| zyga-ubuntu | sorry lundmar ^ | 19:38 |
| lundmar | zyga-ubuntu: there is nothing wrong in talking to yourself through lo :D | 19:38 |
| cachio_ | mvo, catalog update failing too | 19:38 |
| zyga-ubuntu | lundmar: my suggestion would be to make it clear the format is always BMP or enrich the tool to support other formats | 19:38 |
| cachio_ | mvo, it is similat to the prevous one | 19:38 |
| zyga-ubuntu | where can I post those images? | 19:38 |
| lundmar | zyga-ubuntu: great. Well, unfortunately the screenshot format is dictated by the instruments so to keep the interface simple we simply let the screenshot plugins manage which format is used. | 19:40 |
| lundmar | zyga-ubuntu: also, we don't want to support any conversion etc. but only provide the source material. | 19:41 |
| zyga-ubuntu | lundmar: https://imgur.com/3KKb5oF | 19:42 |
| lundmar | nice | 19:42 |
| zyga-ubuntu | lundmar: right but some smarts could be useful for first time users :) | 19:42 |
| lundmar | zyga-ubuntu: in other words, some instruments gives you a .bmp or .png . In your case .bmp is about 3x as fast as .png | 19:43 |
| lundmar | the poor chipset is too slow to do .png compression haha | 19:43 |
| zyga-ubuntu | lundmar: right but the client side can fingerprint and convert | 19:44 |
| lundmar | either way - the tool provides a lossless image. It's up to to user to convert it to whatever format they want. | 19:45 |
| lundmar | zyga-ubuntu: fyi - this is kind of the unoffical discussion thread for lxi-tools in case you feel like chiming in: https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/?all | 19:46 |
| zyga-ubuntu | lundmar: yes but the user _cannot know_ what the format is :) | 19:46 |
| zyga-ubuntu | lundmar: apart from looking | 19:47 |
| zyga-ubuntu | lundmar: in either case, it works :") | 19:47 |
| lundmar | true | 19:47 |
| lundmar | I had a guy using the lxi-tools snap in a NFS mounted directory - of course the confinement gave him permission denied. | 19:48 |
| lundmar | his only solution was to use --classic install | 19:49 |
| zyga-ubuntu | lundmar: this is now fixed | 19:49 |
| zyga-ubuntu | lundmar: as long as that is in /home | 19:49 |
| zyga-ubuntu | lundmar: I implemented support for NFS | 19:49 |
| zyga-ubuntu | lundmar: he should have actually used --devmode as classic has lower chance of working | 19:49 |
| lundmar | good. I'm not sure but I think maybe his case was outside home. | 19:49 |
| lundmar | from the doc description --classic and --devmode seems to be the same except the added debug messaging | 19:50 |
| zyga-ubuntu | lundmar: where? | 19:53 |
| zyga-ubuntu | lundmar: devmode is "same as strict but with advisory confinement" | 19:53 |
| zyga-ubuntu | lundmar: classic is "it runs on top of your system, no magic", usually this will fail with shared libraries missing | 19:53 |
| lundmar | zyga-ubuntu: https://docs.snapcraft.io/reference/snap-command | 19:54 |
| zyga-ubuntu | lundmar: indeed, that doesn't capture it | 19:55 |
| lundmar | zyga-ubuntu: that is, both "disable security confinement" | 19:55 |
| zyga-ubuntu | Chipaca: do you know where that docs came from ^ | 19:55 |
| zyga-ubuntu | lundmar: yes but the important aspect is not there | 19:55 |
| lundmar | ok | 19:56 |
| zyga-ubuntu | lundmar: "disable the use of root filesystem redirection" | 19:56 |
| zyga-ubuntu | that's classic | 19:56 |
| jdstrand | popey: hey, not sure if you saw yesterday, but vlc snaps keep coming in with broken symlinks | 19:56 |
| lundmar | so classic disable confinement while devmode is advisory confinement | 19:56 |
| jdstrand | popey: for the desktop file | 19:56 |
| lundmar | ? | 19:56 |
| lundmar | zyga-ubuntu: a little elaboration on the difference in the docs would be nice :) | 19:57 |
| zyga-ubuntu | lundmar: classic == like curl | sh | 19:57 |
| zyga-ubuntu | lundmar: devmode == like curl | sh in a very fancy chroot | 19:57 |
| zyga-ubuntu | lundmar: yes, I'm not sure who wrote those docs though | 19:58 |
| lundmar | snaps are using cgroups and apparmor for confinement right? | 19:58 |
| lundmar | no lxc right? | 19:59 |
| zyga-ubuntu | lundmar: apparmor, seccomp, some cgroups (devices and freezer) and dbus bus rules/permission | 19:59 |
| zyga-ubuntu | lundmar: and chroot on steroids | 19:59 |
| Chipaca | zyga-ubuntu: those docs are via davidcalle afaik | 19:59 |
| lundmar | ok, so no use of linux containers (lxc) | 19:59 |
| zyga-ubuntu | lundmar: we rely on mount namespace heavily | 19:59 |
| zyga-ubuntu | lundmar: no but lxc uses many of the same things | 20:00 |
| zyga-ubuntu | lundmar: we just don't use all the namespaces, just the mount namespace | 20:00 |
| zyga-ubuntu | Chipaca: thanks! | 20:00 |
| Chipaca | zyga-ubuntu: which bit is causing confusion? | 20:00 |
| lundmar | yeah, I haven't looked into the details of snap yet but it is difficult to find any description anywhere of the techs involved | 20:00 |
| zyga-ubuntu | davidcalle: do you know if we could fix the description of --devmode and --classic there | 20:00 |
| zyga-ubuntu | Chipaca: ^ | 20:00 |
| zyga-ubuntu | lundmar: I could write some | 20:01 |
| Chipaca | lundmar: have you seen the messages describing the flags? | 20:01 |
| lundmar | zyga-ubuntu: it would be nice at this stage to have a writeup describing the techs involved but maybe it would be something for a blog post | 20:02 |
| Chipaca | lundmar: e.g. “The publisher of snap %q has indicated that they do not consider this revision to be of production quality and that it is only meant for development or testing at this point. As a consequence this snap will not refresh automatically and may perform arbitrary system changes outside of the security sandbox snaps are generally confined to, which may put your system at risk.” | 20:02 |
| Chipaca | lundmar: that's --devmode | 20:02 |
| Chipaca | lundmar: whereas --classic says “This revision of snap %q was published using classic confinement and thus may perform arbitrary system changes outside of the security sandbox that snaps are usually confined to, which may put your system at risk.” | 20:02 |
| Chipaca | lundmar: so there's a technical difference (as described by zyga above), but there's also the expectations about what you're trying to do (and the tooling encourages you along these lines) | 20:03 |
| lundmar | Chipaca: you guys should put some of those details in the snap man page :) | 20:05 |
| jdstrand | lundmar: in terms of the security sandbox: https://forum.snapcraft.io/t/security-policy-and-sandboxing/554. it has references to other information at the bottom | 20:05 |
| Chipaca | lundmar: so much to do, tho | 20:05 |
| lundmar | jdstrand: thanks - good stuff! | 20:06 |
| lundmar | Chipaca: yeah, btw. did you see my response on the autocompletion function suggestion? | 20:06 |
| lundmar | the addition of e.g. a completer-function key etc. | 20:07 |
| Chipaca | lundmar: I did. I didn't like it, but haven't gotten back to explaining why :-/ | 20:07 |
| Odd_Bloke | kyrofa: sergiusens: ISTR that the snapcraft snap had some problems in the past; can it now be used safely? | 20:07 |
| lundmar | Chipaca: You can't possible not like such a simple elegant solution ;) | 20:07 |
| kyrofa | Odd_Bloke, yes, today it should be good to go | 20:07 |
| Chipaca | lundmar: restricting completers to only use -F is the opposite of having things just work | 20:07 |
| Chipaca | lundmar: not everything is -F | 20:07 |
| kyrofa | Odd_Bloke, that's why we held off on a stable release for so long | 20:08 |
| kyrofa | But now that it's in stable, you should be good | 20:08 |
| Odd_Bloke | OK, great! | 20:08 |
| lundmar | Chipaca: hmm, I have yet to see a script that does not use -F . But if thats the case then yes its a problem. | 20:08 |
| Chipaca | anyway why am i on work irc at 8pm | 20:09 |
| * Chipaca goes to see if the apple crumble is done | 20:09 | |
| Chipaca | oh now i remember why: the kitchen is full of dirty dishes | 20:11 |
| zyga-ubuntu | Chipaca: greatest peril in modern history | 20:12 |
| zyga-ubuntu | Chipaca: take your flying cars vision-of-the-future, give me automatic kitchen | 20:12 |
| Chipaca | yeah | 20:14 |
| Chipaca | and now i've got 10 minutes while spread does it thing | 20:14 |
| Chipaca | so, dishes ¯\_(ツ)_/¯ | 20:14 |
| jdstrand | mvo: would you like me to create a forum topic on http://paste.ubuntu.com/26119892/? | 20:15 |
| kyrofa | Oh come on github | 20:16 |
| kyrofa | sergiusens, elopio needs one more review on each PR | 20:20 |
| sergiusens | kyrofa which one? | 20:25 |
| kyrofa | Both milestone PRs | 20:25 |
| kyrofa | The "what why and how" is the big one | 20:25 |
| jdstrand | mvo: I'll just create one | 20:25 |
| sergiusens | kyrofa oh, those | 20:25 |
| kyrofa | The other is actually quite small if you factor it out | 20:25 |
| sergiusens | yeah | 20:25 |
| kyrofa | sergiusens, would be nice to see an integration test for snapcraft#1781 | 20:38 |
| mup | PR snapcraft#1781: many: set rpath for elf files for classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1781> | 20:38 |
| sergiusens | kyrofa talked to elopio actually, going to use the opencv demo as a validation | 20:42 |
| kyrofa | Ah, alright | 20:43 |
| sergiusens | kyrofa it has dependencies, so it is a good candidate to make sure $ORIGIN is setup correctly | 20:43 |
| sergiusens | kyrofa I do have to tend to other matters now, so this will not happen until later in the evening/night though | 20:52 |
| sergiusens | tests are taking long to run anyways... | 20:55 |
| * sergiusens will bbl | 20:55 | |
| mup | Issue snapcraft#1698 closed: “snapcraft help” parity with --help <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1698> | 20:56 |
| mup | PR snapcraft#1789 closed: cli: improve the help command <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1789> | 20:56 |
| kyrofa | Yes they sure are | 21:00 |
| zyga-ubuntu | jdstrand: hey | 21:09 |
| zyga-ubuntu | jdstrand: are you going to be around this week? | 21:09 |
| zyga-ubuntu | ogra_: did you see the new arm microsoft laptops? | 21:25 |
| * zyga-ubuntu looks forward to arm laptops with 8GB ram | 21:35 | |
| zyga-ubuntu | I hope it won't be bootloader-locked into windows | 21:35 |
| === __chip__ is now known as Chipaca | ||
| mup | Issue snapcraft#1711 closed: Develop enable-ci circle-ci <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1711> | 23:23 |
| mup | PR snapcraft#1780 closed: cli: add export-login command <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1780> | 23:23 |
| mup | PR snapcraft#1792 closed: tests: do not hit the network in python unit tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1792> | 23:23 |
| gsilvapt | howdy all | 23:26 |
| gsilvapt | kyrofa, you around? | 23:26 |
| kyrofa | gsilvapt, hey there! | 23:27 |
| gsilvapt | how's it going? | 23:27 |
| gsilvapt | kyrofa, I need your help to solve this issue again: https://github.com/snapcore/snapcraft/pull/1746#event-1370522583 | 23:27 |
| mup | PR snapcraft#1746: cli: add version command <Created by gsilvapt> <https://github.com/snapcore/snapcraft/pull/1746> | 23:27 |
| gsilvapt | I'm not 100% how can I achieve this | 23:28 |
| kyrofa | gsilvapt, did we never get past that static failure? | 23:28 |
| gsilvapt | Not in my end no, kyrofa | 23:28 |
| kyrofa | I got some more experience that since I last looked, let me take a peek here in a sec as soon as I clean all this sanded cardboard off of me | 23:29 |
| gsilvapt | Haha, thank you kyrofa :) | 23:30 |
| kyrofa | gsilvapt, I can't seem to duplicate that issue locally. I've updated the branch to the latest master, which also runs the tests again. Let's see what happens. However, sergiusens also reviewed it, make sure you respond to his review | 23:36 |
| gsilvapt | My question is how to create the constant he asked so I can answer with this done | 23:37 |
| gsilvapt | If you could be kind to provide another example of this concept implemented elsewhere, I might be able to understand and do it again for this one | 23:37 |
| gsilvapt | kyrofa ^ | 23:37 |
| kyrofa | gsilvapt, what I believe he's asking for is to create a single variable holding the format string, and then use that variable twice, one in the version command and one in __init__ | 23:38 |
| kyrofa | gsilvapt, basically taking your goal of making sure they stay in sync by hard-coding the string in both places one step further by using the same variable to hard-code them | 23:39 |
| kyrofa | (both) | 23:39 |
| kennyloggins | kyrofa: peek is a snap for sharing endlessOS pics on slack though gif manipulation, not a flatpack. | 23:39 |
| gsilvapt | kyrofa, ok but is there a specific place to set that global variable? I mean, I don't want to set it in the wrong place and not be able to use it | 23:39 |
| sergiusens | gsilvapt the clarification from kyrofa is exactly what I asked for | 23:40 |
| * sergiusens is still on the move | 23:40 | |
| kyrofa | gsilvapt, put it in the version module. That's already imported by __init__ in order to create the version command | 23:41 |
| kyrofa | gsilvapt, don't be afraid to take a crack at it and propose the change, we're happy to help you through it | 23:41 |
| kyrofa | (all we ask is that you make sure it works before proposing, heh) | 23:42 |
| kennyloggins | tea is the answer to anything. | 23:44 |
| === gsilva is now known as gsilvapt | ||
| gsilvapt | kyrofa, this may seem a dumb thing but I'm not following where I should define this variable | 23:58 |
| gsilvapt | Do you know if the click docs mention that? | 23:58 |
| kyrofa | gsilvapt, you should never feel dumb! | 23:58 |
| kyrofa | gsilvapt, nah, this has nothing to do with click, just talking python here | 23:58 |
| kyrofa | gsilvapt, let me find you an example | 23:59 |
| gsilvapt | kyrofa, often I do. I mean, this code base is a bit complex for me so I'm still getting use to it :P | 23:59 |
| gsilvapt | kyrofa, lets do this the other way around if that's okay. Let me try to go over each step and you'll stop me when I'm wrong | 23:59 |
| gsilvapt | is that ok? | 23:59 |
| kyrofa | gsilvapt, feeling dumb is different than simply not understanding a massive codebase :P | 23:59 |
| kyrofa | gsilvapt, sure thing | 23:59 |
| gsilvapt | Maybe. But then outsiders come and feel ok with just doing stuff :P | 23:59 |
| kyrofa | Hit me | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
