| Saviq | Matthew-S: yes, Ubuntu package names today | 00:18 |
|---|---|---|
| Matthew-S | okay, thanks. Another question, if that's the case, how can I go about debugging why an executable behaves differently inside the snap than it does when apt-get installing it? | 00:21 |
| Matthew-S | Specifically, I'm trying to get `git` to work inside the snap, but it's complaining with `fatal: Unable to find remote helper for 'https'1 | 00:34 |
| Saviq | Matthew-S: https://git-scm.com/docs/git-remote-helpers | 01:03 |
| Saviq | looks like git doesn't know where to find those | 01:03 |
| Lin-Buo-Ren-alt1 | Just reproduced this one: https://bugs.launchpad.net/snapcraft/+bug/1695882 | 03:07 |
| mup | Bug #1695882: cleanbuild loses scripted version <cleanbuild> <Snapcraft:Triaged by kalikiana> <https://launchpad.net/bugs/1695882> | 03:07 |
| mborzecki | morning | 04:55 |
| zyga | o; | 04:57 |
| zyga | o/ | 04:57 |
| mborzecki | zyga: hey | 05:03 |
| mborzecki | 2nd time in a row i saw google:ubuntu-core-16-64:tests/main/snap-repair fail on master, looking into it | 05:03 |
| zyga | real failure or logging issue? | 05:05 |
| mborzecki | looked like real failure, the test lists the timers and one it's looking for was not there | 05:05 |
| mborzecki | zyga: https://paste.ubuntu.com/p/8GYQR6z49D/ | 05:06 |
| zyga | mmmm | 05:17 |
| zyga | yeah | 05:17 |
| zyga | looks like it is really broken | 05:17 |
| mborzecki | but it doesn't reproduce :/ | 05:22 |
| zyga | good, it won't spread ;) | 05:22 |
| zyga | like all races | 05:23 |
| zyga | it's a whack-a-mole | 05:23 |
| zyga | my son stays at home today | 05:25 |
| zyga | it's so good not to have to wake him | 05:25 |
| zyga | and drag him off to school | 05:26 |
| zyga | mborzecki: can you please look at https://github.com/snapcore/snapd/pull/5281 | 05:26 |
| zyga | it's 7 lines and has +1 from jamie | 05:27 |
| mup | PR #5281: snap: reject more layout locations <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5281> | 05:27 |
| zyga | mborzecki: can I restart the PR where snap-repair failed? | 05:31 |
| mborzecki | which one is it? | 05:33 |
| zyga | 5282 | 05:33 |
| mborzecki | zyga: yeha, go ahead and restart it | 05:34 |
| mborzecki | wonder if it has something to do with sequence of jobs | 05:35 |
| zyga | oh | 05:36 |
| zyga | probably yes | 05:36 |
| zyga | + systemctl is-active snapd.snap-repair.timer | 05:37 |
| zyga | inactive | 05:37 |
| zyga | on unrelated branch | 05:37 |
| zyga | more of the log https://www.irccloud.com/pastebin/3hQc0OMj/ | 05:37 |
| mup | PR snapd#5281 closed: snap: reject more layout locations <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5281> | 05:41 |
| zyga | good morning mvo | 05:59 |
| mvo | zyga: good morning | 06:04 |
| mvo | zyga: 5274 should have some answers for you :) | 06:05 |
| zyga | looking :") | 06:05 |
| mup | PR snapd#5282 closed: interfaces/raw-usb: also allow usb serial devices <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5282> | 06:06 |
| zyga | mvo: approved | 06:06 |
| mvo | zyga: \o/ | 06:06 |
| zyga | for clarity about canConfigure | 06:06 |
| zyga | I recently wrote functions like this: https://github.com/snapcore/snapd/pull/5278/files#diff-4480ffd44957efa3395867c929f88014R99 | 06:06 |
| mup | PR #5278: cmd/snap-update-ns: add IsTrustedTmpfs and tests <Created by zyga> <https://github.com/snapcore/snapd/pull/5278> | 06:07 |
| mup | PR snapd#5274 closed: configstate: deny configuration of base snaps and for the "snapd" snap <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5274> | 06:07 |
| zyga | and it made me think about giving a yes-or-no answer | 06:07 |
| mvo | zyga: looking, I need to do a followup anyway | 06:07 |
| zyga | and being able to say "error" as a third option | 06:07 |
| zyga | I'm not saying you need to do the same | 06:07 |
| zyga | but I just wanted to show how encoding "no" in a an error may or may not be natural, depending on context | 06:07 |
| zyga | (and my PR needs changes too, I'm on that now) | 06:07 |
| mvo | zyga: right, in this func its just two states: configuration is ok or there is some error that needs reporting | 06:07 |
| * mvo gets breakfast | 06:09 | |
| mborzecki | mvo: hey | 06:10 |
| jamesh | zyga: thanks for the extra review feedback on my PR. The SUSE failure is due to package naming (I checked the website for the most recent version, which differs from what we're running in Spread). I'm doing some tests to see why it is failing on 14.04 | 06:18 |
| zyga | jamesh: as for suse, I will open a PR to see if we can use tumbleweed | 06:18 |
| zyga | tumbleweed is a better indication of things working or not working in upcoming releases of leap so it will be very useful for testing | 06:19 |
| jamesh | zyga: I was looking at OpenSUSE Leap 15 (which is newer than Leap 42.3) | 06:19 |
| zyga | yeah :-) | 06:19 |
| zyga | if you want to test on one machine, use tumbleweed | 06:19 |
| zyga | it's still close to leap and it stays current | 06:19 |
| mvo | jdstrand: just fyi, I cherry picked "interfaces/raw-usb: also allow usb serial devices" | 06:25 |
| mvo | jdstrand: I think its a really nice fix | 06:25 |
| mup | PR snapd#5283 opened: snapstate: get rid of needsMaybeCore <Created by mvo5> <https://github.com/snapcore/snapd/pull/5283> | 06:28 |
| mborzecki | suggestions on how to pass a name for parallel installation when installing with `snap install --dangerous foo.snap` ? | 06:28 |
| zyga | interesting | 06:29 |
| zyga | snap install --dangerous foo.snap --as foo_prod | 06:29 |
| zyga | --instance prod | 06:29 |
| zyga | but also foo_prod.snap | 06:30 |
| mborzecki | hm afaict we ignore the name of the *.snap file and only look at the contents | 06:30 |
| zyga | we should be careful in case someone builds a snap like foo-2_amd64.snap | 06:30 |
| mborzecki | snap install --dangerous foo.snap:foo_prod maybe? slightly unintuitive | 06:31 |
| mborzecki | --as sounds nice | 06:31 |
| === chihchun_afk is now known as chihchun | ||
| mborzecki | zyga: btw. that snap-repair.timer did not reproduce when running with the same seed as travis, so maybe it's not the order of tests after all | 06:33 |
| zyga | but if we ignore the filename and use meta/snap.yaml name | 06:33 |
| zyga | then --instance feels more appropriate | 06:33 |
| mborzecki | --dangerous foo.snap --instance foo_bar? | 06:33 |
| zyga | I'd just say --instance prod | 06:34 |
| zyga | as we would ignore the foo_ part anyway | 06:34 |
| mborzecki | we do enforce single snap installation when using *.snap file, so --instance/--as might be ok | 06:37 |
| zyga | mborzecki: then the only remaining issue is that "snap install foo bar --instance ..." is perhaps confusing | 06:40 |
| zyga | and should be disallowed | 06:40 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 06:57 |
| zyga | hej pawel | 06:58 |
| mvo | hey pstolowski and mborzecki | 06:58 |
| OlofL | I use ubuntu and onlyoffice. But i can not use local printers. only print2pdf is available. any suggestions? | 06:59 |
| zyga | OlofL: it _may_ be unsupported | 07:01 |
| zyga | OlofL: can you please open a terminal and run "snap interfaces | grep cups" and paste that here | 07:05 |
| OlofL | :cups-control - - notepad-plus-plus:cups-control - onlyoffice-desktopeditors:cups-control | 07:06 |
| zyga | sorry, can you please paste that to pastebin.ubuntu.com | 07:11 |
| zyga | the newlines matter and I cannot see them clearly here | 07:11 |
| mborzecki | pedronis: thank you for your review on 5253 | 07:12 |
| OlofL | zyga: https://pastebin.ubuntu.com/p/TPrkrb8JF9/ | 07:16 |
| zyga | right | 07:16 |
| zyga | thank you | 07:16 |
| zyga | this says that the snap is _not_ connected to cups-control interface | 07:16 |
| zyga | I would suggest you do | 07:16 |
| zyga | sudo snap connect onlyoffice-desktopeditors:cups-control | 07:16 |
| zyga | and restart the application | 07:17 |
| zyga | this should give it access to your printers | 07:17 |
| pedronis | mborzecki: hi, I have not finished though as I wrote, I will list some of the areas I mentioned also in the topic | 07:21 |
| * pedronis breakfast | 07:21 | |
| mborzecki | pedronis: thanks! | 07:21 |
| jamesh | zyga: is google:ubuntu-core-16-64:tests/main/ubuntu-core-services known to be flaky, or is that likely to be something from my PR? | 07:27 |
| zyga | jamesh: perhaps flaky, mborzecki is investigating a failure today | 07:27 |
| jamesh | zyga: okay. That's the only one failing on my PR, and I can't think of how it'd be related. | 07:28 |
| jamesh | that said, changing "snap run" has the potential for unintended side effects ... | 07:28 |
| mborzecki | heh, ran the whole ubuntu-core test suite twice now, not reproduced :/ | 07:30 |
| OlofL | zyga: it worked. Only to discover onlyoffice print options just suck. it ended up printing 1 A4 page to 6 pages! | 07:47 |
| zyga | well, little by little, there's some progress :) | 07:47 |
| OlofL | meh. :P Installed libreoffice instead. CBA with all the issues | 07:47 |
| mup | PR snapd#5284 opened: data/systemd/snapd.run-from-snap: ensure snapd tooling is available <Created by mvo5> <https://github.com/snapcore/snapd/pull/5284> | 07:50 |
| mup | PR snapd#5285 opened: tests/main/{snap-repair,ubuntu-core-services}: add debug information <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5285> | 07:51 |
| mborzecki | let's see if it reproduces in this one ^^ | 07:52 |
| mborzecki | pedronis: do you think it would be helpful if i shove the changes that make use if instance key in snapsup into the current PR? | 07:54 |
| pedronis | mborzecki: yes, it would be definitely more consistent (given that is using the original fields atm) | 08:01 |
| mborzecki | ok | 08:01 |
| pstolowski | all, please let me know if you see econnreset test failure again; the PR that adds extra debug was merged yesterday so we might see some more info | 08:15 |
| pedronis | mborzecki: I added the notes I had in mind to the topic, let me know if you have questions, I'm not sure you are familiar with some of things I mention there | 08:16 |
| mborzecki | pedronis: thanks, well i will have questions :) | 08:19 |
| pedronis | mborzecki: :), I suspect working on this is a bit of a crash course in all things snapd, I mean *all* things | 08:20 |
| mborzecki | pedronis: yup, but it's fun | 08:21 |
| zyga | mborzecki: then you hit a kernel bug and the fun continues on level 2 | 08:39 |
| mup | PR snapd#5286 opened: snapstate: fix assumptions about core in setup phase2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5286> | 08:48 |
| * zyga -> short walk | 09:16 | |
| mvo | 5176 needs a second review | 09:16 |
| mvo | should be (hopefully) simple | 09:16 |
| newbee | Hi guys, I have a java program that list the Serial-port in my Ubuntu 16.4 LTS system, its working fine, listing all the serial ports in my system . Then I created the snap of the same project as per the snapcraft instruction, after install the snap in my Ubuntu 16.4 LTS system , its not list the serial ports. As per the documentation I also create custom gadget snap. But when iI install the gadget. snap it shows error,"cannot insta | 09:22 |
| newbee | Please someone help me to solve this... | 09:22 |
| zyga | back | 09:32 |
| zyga | way too hot todaty | 09:32 |
| zyga | newbee: you cannot install gadget snaps on normal systems | 09:32 |
| zyga | newbee: since you ask this question over and over I will respond clearly: you cannot make this work on a regular (laptop/desktop) system yet | 09:33 |
| zyga | newbee: you must run unconfined for now (use --devmode) | 09:33 |
| zyga | newbee: eventually it will work but the work on hot plug devices is just beginning | 09:33 |
| zyga | newbee: your snap would work on a dell edge gateway for example | 09:34 |
| zyga | newbee: where it would get serial port definitions from the gadget | 09:34 |
| zyga | newbee: because that system is a "core" system (unlike a classic system that most people run) | 09:34 |
| zyga | and as a core system it has a gadget snap pre-installed | 09:34 |
| zyga | mborzecki: https://api.travis-ci.org/v3/job/389629553/log.txt | 09:38 |
| zyga | pstolowski: ^ | 09:38 |
| zyga | econreset failed | 09:38 |
| zyga | as well as ubuntu-core-services | 09:38 |
| pstolowski | ty! | 09:38 |
| mborzecki | jackpot | 09:38 |
| pstolowski | very nices, DEBUG: Not retrying: &net.OpError{Op:"dial", Net:"tcp", Source:net.Addr(nil), Addr:(*net.TCPAddr)(0xc8203b8e70), Err:(*os.SyscallError)(0xc82042cb80)} | 09:40 |
| pstolowski | *nice | 09:40 |
| mvo | woah, syscall error | 09:40 |
| newbee | @Zyga : Ok, Thanks... | 09:40 |
| zyga | that syscall error is ... probably.. EINTR | 09:41 |
| zyga | but hard to know | 09:41 |
| zyga | is there something more that shows it? | 09:41 |
| pedronis | I woudl expect the go runtime to handle EINTR | 09:42 |
| pstolowski | indeed | 09:42 |
| pedronis | seems we need more debugging code, to extract those things | 09:43 |
| pstolowski | or just retry if on op error = dial, there is no harm in retrying is it? | 09:45 |
| mvo | zyga: could you please set the series to "xenial" forhttps://code.launchpad.net/~canonical-foundations/+snap/pc-i386 ? | 09:53 |
| mvo | zyga: and the same for pc-amd64 ? | 09:53 |
| mvo | zyga: and rebuild both? | 09:53 |
| zyga | mhm | 09:54 |
| zyga | hmm | 09:54 |
| * zyga looks for any edit controls | 09:54 | |
| zyga | I cannot | 09:55 |
| zyga | mvo: I gave this up to foundations and no longer control it | 09:55 |
| zyga | slangasek: ^ | 09:55 |
| mvo | zyga: oh, you no longer own that - ok | 09:55 |
| mvo | sil2100, slangasek could you please set https://code.launchpad.net/~canonical-foundations/+snap/pc-i386 and (-amd64) to series "xenial" and build again? we landedhttps://github.com/snapcore/pc-i386-gadget/pull/5 and would like to update the gadget with that in the store | 09:56 |
| mup | PR pc-i386-gadget#5: grub.cfg: allow customizing the menuentry via a new "snap_menuentry" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/pc-i386-gadget/pull/5> | 09:56 |
| sil2100 | mvo: I'll be on it in a few! | 09:58 |
| mvo | sil2100: thank you | 09:59 |
| mvo | sil2100: but no rush, its not OMGnow priority :) | 09:59 |
| newbee | @Zyga Once again thanks.. Now I am able read the serial-port in ubuntu 16.04 LTS system using snap application. | 10:06 |
| zyga | newbee: I understand this is frustrating, I suspect you will be able to use fully confined application with serial ports on 16.04 in 2-3 months from now | 10:06 |
| mvo | a second review for 5176 would be great, that would unblock a new 2.33 upload | 10:08 |
| zyga | mvo: is the nack from gustavo fixed? | 10:09 |
| zyga | mvo: asked one wrench-in-the-gear question | 10:11 |
| zyga | mvo: or in other words, reboot your router and run the connectivity check | 10:12 |
| pstolowski | caution to anyone doing self-review... browser session in the tool times-out in very annoying manner, if you hit save after a long period of inactivity on the page, it logs you out and whatever you typed is lost! best to prepare it in a text editor first... | 10:17 |
| zyga | thanks pawel | 10:18 |
| zyga | I haven't done mine yet so I will use this for sure | 10:18 |
| mvo | zyga: I think the gustavo nack is resolved | 10:39 |
| mvo | zyga: and answered the question :) | 10:41 |
| zyga | mvo: ping is not a good example as it is a synchronous process doing the test | 10:43 |
| zyga | I can approve this but my gut feeling says it should be async | 10:43 |
| zyga | and AFAIK we cannot change the API later because users | 10:43 |
| mvo | zyga: maybe I'm not understanding, but what is the concern about this being sync? that the user waits for some seconds on a reply? | 10:44 |
| zyga | it can take very long to respond | 10:45 |
| mvo | zyga: for a consumer script an async interface is more work, it would be "snap debug connectivity; snap changes --last=debug; snap list etc" | 10:45 |
| zyga | and we don't do long things in a sync way | 10:45 |
| zyga | not quite, the command could poll | 10:45 |
| zyga | the UX could stay the same | 10:45 |
| zyga | (though it could get smarter as well, e.g. by reporting progress in real time) | 10:45 |
| mvo | zyga: is the concern about the server side that its sync there? | 10:46 |
| zyga | but my main gripe is with the call me and wait for unbound amount of time for a response | 10:46 |
| zyga | yes | 10:46 |
| zyga | this feels the same like install | 10:46 |
| zyga | and I fear that changing it later would suck | 10:46 |
| zyga | (for complexity) | 10:46 |
| mvo | zyga: don't we run this inside a goroutine? the request handling? and we unlock the state while doing this | 10:46 |
| zyga | perhaps but the client may just time out waiting | 10:47 |
| zyga | perhaps pedronis should decide | 10:47 |
| zyga | as I said, if you feel strongly about it I can approve | 10:47 |
| zyga | the code looks okay otherwise | 10:48 |
| mvo | zyga: its fine, I am just trying to understand the concern | 10:48 |
| mvo | zyga: a bit of a shame that chipaca is not around today, he knows this probably best | 10:49 |
| mvo | zyga: I just checked the code, we don't do a timeout in the client for sync methods. and I added a 30s delay (just to test things) and snapd is fine, both responsive and no observable issue on the client side | 10:53 |
| mvo | zyga: but maybe pedronis has an opinion about whether "debug connectivity" should be a sync or async reply - just to ensure that we carefully looked at this | 10:54 |
| mvo | zyga: or we can talk during the standup. thanks for your review in any case :) | 10:54 |
| mborzecki | pedronis: is it intentional that when store.SnapAction.Action == "refres" the Name field is not used? | 11:09 |
| pedronis | mborzecki: yes | 11:09 |
| pedronis | refreshes are purely instance-key and snap-id based | 11:10 |
| mborzecki | pedronis: is it ok if i pass name nonetheless? i need to construct unique instance keys, snap-id is the same, so appending name would give me the unique part | 11:12 |
| pedronis | mborzecki: pass where? | 11:12 |
| mborzecki | down to store.SnapAction() | 11:12 |
| pedronis | mborzecki: as I wrote we have two options with the store interface | 11:12 |
| pedronis | either we make all the store apis take instance names | 11:12 |
| pedronis | or we tweak SnapAction to take instance keys explicitly | 11:13 |
| pedronis | and deal with things one level up | 11:13 |
| mborzecki | i'm tweaking SnapAction :) | 11:13 |
| pedronis | mborzecki: I think tweaking SnapAction is less magic so probably easier, but both are ok, as long as we consistent | 11:14 |
| pedronis | mborzecki: but as I said if you tweak SnapAction is not a matter of passing name | 11:14 |
| mborzecki | pedronis: so basically suggesting is to extend store.CurrentSnap with InstanceKey explicitly? | 11:14 |
| pedronis | mborzecki: yes | 11:14 |
| pedronis | and action too | 11:14 |
| mborzecki | pedronis: right | 11:14 |
| pedronis | mborzecki: if we start passing down instance keys, we need to do the same with the info stuff | 11:15 |
| pedronis | but I can see pros and cons for both | 11:15 |
| pedronis | you need to see a bit | 11:15 |
| pedronis | mborzecki: btw probably a good time to kill a couple of left overs apis that are not used | 11:16 |
| mborzecki | pedronis: i'm doing the changes right now, so we'll see in a bit whether this feels ok or not | 11:16 |
| mborzecki | pedronis: which ones? | 11:17 |
| pedronis | ListRefresh and LookupRefresh | 11:17 |
| pedronis | they should be unused now | 11:17 |
| pedronis | (SnapAction took over) | 11:17 |
| === chihchun is now known as chihchun_afk | ||
| mborzecki | pedronis: ok, let me note that down and i'll look into it | 11:18 |
| pedronis | mborzecki: probably best done on its own branch, but especially if you decide to pass in instance names | 11:18 |
| pedronis | then you don't want to have to fix those | 11:18 |
| mborzecki | ack | 11:19 |
| pedronis | mborzecki: to be clear they are still there because the switch to SnapAction happened late in 2.32, and there was a chance to have to revert it, also it would have a lot more late churn to remove them | 11:21 |
| pedronis | mborzecki: but 2.33/2.34 is a good time to remove them, now that we known happy with SnapAction | 11:21 |
| mborzecki | ok | 11:22 |
| mborzecki | i'm off for a while, bbl, will miss the standup today, see the note in the forum | 11:23 |
| === pstolowski is now known as pstolowski|lunch | ||
| niemeyer | mvo: Heya | 11:39 |
| niemeyer | mvo: Haven't seen the updated PR, but as a minor, if you implemented a restricted language, I suggest just sticking to the field names we use in the API | 11:40 |
| niemeyer | mvo: So we have a single set of those to keep promises on | 11:40 |
| mup | PR snapd#5287 opened: testutil: syscall sequence checker <Created by zyga> <https://github.com/snapcore/snapd/pull/5287> | 11:43 |
| jdstrand | mvo: thanks! I wasn't sure if it could make it into 2.33 :) | 11:44 |
| zyga | jdstrand: hey, could you please look at https://github.com/snapcore/snapd/pull/5278 | 11:47 |
| zyga | this would unblock the next chunk | 11:47 |
| mup | PR #5278: cmd/snap-update-ns: add IsTrustedTmpfs and tests <Created by zyga> <https://github.com/snapcore/snapd/pull/5278> | 11:47 |
| zyga | one new function with tests and docs | 11:47 |
| zyga | jdstrand: also (though not security sensitive so no need to use your time) 5287 will aid in writing tests | 11:48 |
| zyga | but it's Friday so .. maybe :) | 11:49 |
| * cachio afk | 11:51 | |
| jdstrand | zyga: I started looking at 5278 yesterday and I was trying to imagine who the consumers of the API will be | 11:56 |
| zyga | this is the trespassing issue again | 11:57 |
| zyga | with a richer fix that works in containers | 11:57 |
| jdstrand | zyga: I guess I'm slightly uncomfortable with the word 'trusted' | 11:57 |
| zyga | the rule is that we allow writing to read-only filesystems (mounted ro or squashfs) | 11:57 |
| zyga | and the tmpfs'es that we have mounted ourselves | 11:57 |
| zyga | and since none of the tmpfses that we mount are visible outside, we trust that they don't show up in the host | 11:57 |
| jdstrand | IsSnapdCreatedTmpfs? | 11:58 |
| zyga | I can rename it, sure no | 11:58 |
| zyga | *no problem | 11:58 |
| jdstrand | isSnapdCreatedPrivateTmpfs? | 11:58 |
| zyga | even better | 11:58 |
| jdstrand | let's see how many words we can cram into the variable :P | 11:58 |
| zyga | any, but they must fit in 8 characters ;) | 11:59 |
| zyga | ShouldWriteToTmpfs? | 11:59 |
| jdstrand | iscpt() | 11:59 |
| jdstrand | is cape town? | 11:59 |
| jdstrand | hee | 11:59 |
| zyga | haha | 11:59 |
| jdstrand | anyhoo, I'll trust you on a rename. trusted is perhaps unsurprisingly a loaded word for me | 12:00 |
| zyga | understood :) | 12:00 |
| jdstrand | I'll add 5287 too | 12:01 |
| jdstrand | :w | 12:01 |
| pedronis | afaik so far we use it only in the contest of assertions for the root keys/accounts | 12:08 |
| === chihchun_afk is now known as chihchun | ||
| zyga | woah | 12:26 |
| zyga | a fire extinguisher just exploded downstairs | 12:26 |
| mup | PR snapd#5288 opened: tests: econnreset/retry tweaks <Created by stolowski> <https://github.com/snapcore/snapd/pull/5288> | 12:27 |
| pstolowski|lunch | zyga: woah, i thought it was only possible in duke nukem when you shot them ;) | 12:27 |
| zyga | we are just as surprised | 12:27 |
| mvo | jdstrand: heh, today is the day for final tweaks for 2.33, this one was just too nice to pass up | 12:28 |
| cwayne | mvo: aha, so should I be expecting some test results soon then? | 12:31 |
| === pstolowski|lunch is now known as pstolowski | ||
| mvo | pedronis: do you happen to have an opinion about the sync/async reply (zyga question in 5176). I would love to do something about this one as its the last piece misisng for 2.33 | 12:32 |
| mvo | cwayne: yeah, hopefully a new beta later today, one open PR though that has some discussion right now :) | 12:32 |
| pstolowski | mvo: thanks for the review! i wonder if it would be better to log %#v instead of "Retrying because of: %s" for all retried errors | 12:32 |
| mvo | cwayne: but I hope it can go all the way from beta->candidate today (if not Monday is fine as well) | 12:32 |
| pedronis | mvo: we don't have set a timeout on daemon response right? given that is a debug command I think sync is fine, unless it would break, we are not keeping the lock | 12:33 |
| mvo | pedronis: yeah, no timeout for sync responses. great, I think we are in agreement. | 12:33 |
| mvo | zyga: ^- thanks again for raising/discussing this! if the PR is otherwise ok I would love to move forward with it | 12:33 |
| zyga | mvo: +1 then | 12:34 |
| cwayne | mvo: sounds good, I'll make sure we're on the lookout for results | 12:34 |
| mvo | zyga: ta | 12:36 |
| mvo | cwayne: ta to you as well :) | 12:36 |
| mup | PR snapd#5176 closed: many: add `snap connectivity-check` command <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5176> | 12:41 |
| zyga | uh | 12:49 |
| zyga | the dust is so irrating | 12:49 |
| zyga | the air filter has gone crazy | 12:49 |
| zyga | 269 PM2.5 | 12:49 |
| zyga | like in the suburbs in the winter ;) | 12:49 |
| niemeyer | Hey there | 13:01 |
| niemeyer | Stopped for a cuppa | 13:02 |
| niemeyer | cachio: How's Travis? | 13:02 |
| niemeyer | mvo: All good on the front of the format thing? Not sure if you saw the earlier note | 13:02 |
| niemeyer | Happy standup :) | 13:03 |
| mup | PR snapd#5289 opened: cmd/snap-update-ns: fix a leaking file descriptor in MkSymlink <Critical> <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5289> | 13:22 |
| zyga | jdstrand: ^ trivial leak fix | 13:24 |
| mup | PR snapd#5290 opened: packaging: use official bolt in the errtracker <Created by mvo5> <https://github.com/snapcore/snapd/pull/5290> | 13:24 |
| zyga | jdstrand: also interesting that unit tests that mock the system call level help to find issues like that | 13:26 |
| pstolowski | mvo: the PR I talked about when we started the standup - #5215 | 13:29 |
| mup | PR #5215: ifacestate: improved conflict and error handling when creating autoconnect tasks <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5215> | 13:29 |
| === chihchun is now known as chihchun_afk | ||
| cachio | mvo, about the symliinks test | 13:42 |
| cachio | it is needed a fix for that yet | 13:42 |
| cachio | could you reproduce it? | 13:43 |
| mvo | cachio: I couldn't but let me try again. what was the link to your script again ? the one you use to build the image? | 13:46 |
| mvo | cachio: I will try to reproduce in a clean VM this time | 13:46 |
| mvo | cachio: to ensure no contamination :) | 13:47 |
| cachio | mvo, https://github.com/sergiocazzolato/validator/blob/master/create.sh | 13:54 |
| mvo | cachio: ta | 13:54 |
| sil2100 | mvo: kicked the builds now (sorry for the wait!) | 13:55 |
| * zyga goes out until the dust is filtered/vented | 13:55 | |
| zyga | mvo: I'm always available on telegram/irc and I can return earlier if needed | 13:56 |
| mvo | zyga: thanks, should be fine. see you | 13:56 |
| mvo | cachio: channel is beta, right? | 13:57 |
| zyga | more errors with snap-repair | 13:57 |
| zyga | https://api.travis-ci.org/v3/job/389723922/log.txt | 13:57 |
| cachio | mvo, yes | 13:57 |
| mvo | cachio: ok, on it (in a fresh vm) | 13:58 |
| cachio | mvo, great, thanks | 13:59 |
| mvo | cachio: I tried in a clean vm, installed ubuntu-image using apt, installed snap via snap install --beta core and the created image has symlinks | 14:02 |
| sil2100 | huh, store authorization failure for the pc-* snaps | 14:02 |
| ogra_ | token needs refresh most likely | 14:03 |
| ogra_ | there is a LP UI for that | 14:03 |
| sil2100 | Doing that, was surprised as I didn't see that before | 14:03 |
| sil2100 | Maybe I'm not using LP to build snaps enough | 14:03 |
| ogra_ | yeah, happens very rarely (but happens) | 14:03 |
| cachio | mvo, I don't do that | 14:04 |
| cachio | mvo, I create the beta image with this script | 14:04 |
| cachio | the I create a vm with this image | 14:04 |
| cachio | then I login and I dont see the symlinks | 14:04 |
| cachio | kvm -snapshot -smp 2 -m 2000 -redir tcp:8022::22 -nographic -serial mon:stdio <PATH-TO-IMG> | 14:05 |
| mvo | cachio: if you run "which ubuntu-image" - what do you get? | 14:05 |
| cachio | I create the vm with this command | 14:05 |
| cachio | this /usr/bin/ubuntu-image | 14:06 |
| mvo | cachio: ok, this looks fine. and snap version? | 14:06 |
| mvo | cachio: how big is the image file? ls -lh for the amd64 image? | 14:06 |
| cachio | mvo, 3,0G may 29 14:49 pc.img | 14:07 |
| cjwatson | sil2100: there's (unfortunately, out of LP's control) a hard one-year expiry on store macaroons | 14:08 |
| cjwatson | sil2100: so that can make you have to reauth even if you use it frequently | 14:08 |
| mvo | cachio: hm, I just downloaded the image I created in the vm, booted it and still see the symlinks in /var/lib/snapd/snaps. confusing | 14:09 |
| cachio | mvo, I create the image in my pc | 14:10 |
| cachio | mvo, did you try that | 14:11 |
| cachio | then create the vm in your pc as well | 14:11 |
| cachio | that's what I am doing | 14:11 |
| mvo | cachio: I create the image in a clean 16.04 VM to make sure its not my local environment that changes things. I can also try that in a bionic VM if that is useful. | 14:15 |
| sil2100 | cjwatson: ah, so that's why, thanks for the info | 14:17 |
| cachio | mvo, I'll try the same | 14:21 |
| mvo | cachio: thank you, I try bionic now | 14:21 |
| mvo | 5290 needs a review (should be trivial) | 14:21 |
| mvo | cachio: same in my bionic vm with ubuntu-image from the deb and core from beta I get the "small" image iwth the symlinks. sorry :/ | 14:30 |
| cachio | mvo, still creating the image here | 14:31 |
| mvo | cachio: ok, good luck | 14:31 |
| cachio | I'll let you know once it is finished | 14:31 |
| mvo | mborzecki: thanks for your review | 14:31 |
| mvo | cachio: fingers crossed, really curious that we get different results | 14:32 |
| pedronis | mvo: do you have a sense of which snapd version will be in 18.04.01, 2.33, .34 ? | 14:38 |
| mvo | pedronis: should be .34 | 14:42 |
| mvo | pedronis: worst case we can do a point release of 2.33 - do you need anything specific in it? | 14:42 |
| cachio | mvo, sale issue | 14:42 |
| cachio | sergio-j-cazzolato@localhost:~$ readlink -f /var/lib/snapd/snaps/core_4734.snap | 14:43 |
| cachio | -> /var/lib/snapd/snaps/core_4734.snap | 14:43 |
| mvo | cachio: oh, symlinks. that looks good, no? | 14:43 |
| cachio | mvo, based on the test it should point to /var/lib/snapd/seed/snaps/core_4734.snap | 14:44 |
| cachio | I tested that in a vm on google and it works fine | 14:44 |
| cachio | in a core 16 | 14:44 |
| pedronis | mvo: I think we want the switch to /v2/info and download action by it | 14:47 |
| pedronis | mvo: I'll talk with John on monday and see if he wants to work on that or it's on me | 14:47 |
| mvo | pedronis: ok | 14:49 |
| mvo | cachio: oh, sorry, misread. so no symlinks in (ls -al /var/lib/snapd/snaps)? | 14:51 |
| cachio | exactly | 14:52 |
| cachio | mvo, snap-core-symlinks test failing | 14:52 |
| mvo | cachio: what is output of "snap version" and "apt list ubuntu-image" where the image was created? could you please pastebin that? | 14:54 |
| cachio | snap 2.33~rc1 | 14:55 |
| cachio | snapd 2.33~rc1 | 14:55 |
| cachio | series 16 | 14:55 |
| cachio | kernel 4.4.0-128-generic | 14:55 |
| mvo | cachio: and "apt list ubuntu-image"? | 14:56 |
| cachio | this is in the vm which I used to create the image | 14:56 |
| cachio | ubuntu-image/xenial-updates,xenial-updates,now 1.3+16.04ubuntu2 all [installed] | 14:56 |
| cachio | ubuntu@vm-16:~/src/validator$ snap version | 14:56 |
| cachio | snap 2.32.9 | 14:56 |
| cachio | snapd 2.32.9 | 14:56 |
| cachio | series 16 | 14:56 |
| cachio | ubuntu 16.04 | 14:56 |
| cachio | kernel 4.13.0-32-generic | 14:56 |
| mvo | cachio: the first version looks fine, the second "snap version" output is a version that does not have the new functionatlity for the symlink creation yet | 14:57 |
| mvo | cachio: could you please try to "snap refresh --beta core" in this machine with the second output and create the image again? | 14:58 |
| mvo | cachio: the machine should have output like the first (i.e. snap version 2.33~rc1) | 14:58 |
| cachio | mvo, sure | 14:58 |
| mvo | cachio: thank you | 14:58 |
| mup | PR snapd#5290 closed: packaging: use official bolt in the errtracker on fedora <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5290> | 15:09 |
| cachio | mvo, working now | 15:24 |
| cachio | with beta core on the machine where I built the image | 15:24 |
| cachio | thanks!! | 15:25 |
| mvo | cachio: great! | 15:30 |
| * cachio lunch | 15:34 | |
| kyrofa | Hey zyga, any chance you've made some progress experimenting with CUDA? https://forum.snapcraft.io/t/nvidia-cuda-on-ubuntu-core/292/4 | 16:03 |
| pstolowski | mvo, zyga Retrying because of: &net.OpError{Op:"dial", Net:"tcp", Source:net.Addr(nil), Addr:(*net.TCPAddr)(0xc420509080), Err:(*os.SyscallError)(0xc42044f1c0)} (syscall error: 0x6f); it's ECONNREFUSED | 16:03 |
| pstolowski | mvo: zyga however, my PR just failed on econnreset test (bummer) | 16:04 |
| zyga | kyrofa: no, not at all actually :-( | 16:04 |
| zyga | kyrofa: mborzecki has the hardware now | 16:05 |
| mup | PR snapd#5291 opened: release: 2.33 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5291> | 16:05 |
| zyga | pstolowski: connection refused, curious | 16:05 |
| zyga | Is that taking to the real store or to the fake store? | 16:06 |
| mvo | pstolowski: interessting | 16:07 |
| pstolowski | there is something more going on when this happens... i see my changes kick in with assertions (the above error), but the actual download attempt that we match on in the test is attempted with attempt=1 only (but multiple times) | 16:08 |
| pstolowski | i save the log and will look at it with fresh mind on monday | 16:09 |
| pstolowski | have a good weekend! | 16:09 |
| cachio | mvo, are you creating a new beta today? | 16:14 |
| jdstrand | roadmr: hi! can you pull r1089 of the review-tools. not urgent | 16:14 |
| roadmr | jdstrand: totally! | 16:15 |
| jdstrand | greyback: that has the override fixes we discussed ^ | 16:15 |
| greyback | jdstrand: awesome, thanks! | 16:15 |
| jdstrand | roadmr: curious on the status of the requash enablement? I see r1086 is deployed | 16:16 |
| === pstolowski is now known as pstolowski|afk | ||
| cachio | zyga, quick question https://paste.ubuntu.com/p/WRyvxWqXFj/ | 16:22 |
| cachio | zyga, quick question https://paste.ubuntu.com/p/WRyvxWqXFj/ | 16:22 |
| cachio | there is a problem with apparmor parser executing the test interfaces-calendar-service | 16:22 |
| zyga | Uname -a? | 16:22 |
| cachio | should we consider this error? | 16:22 |
| cachio | Linux jun081014-974428 4.4.104-39-default #1 SMP Thu Jan 4 08:11:03 UTC 2018 (7db1912) x86_64 x86_64 x86_64 GNU/Linux | 16:23 |
| zyga | Most likely yes | 16:23 |
| zyga | Yes | 16:23 |
| cachio | it is opensuse-42.3-64 | 16:23 |
| zyga | Looks like a bug | 16:23 |
| cachio | ok | 16:27 |
| mvo | cachio: yes, 2.33 is in the beta channel now (cc cwayne) | 17:02 |
| zyga | re | 17:15 |
| mup | PR snapd#5289 closed: cmd/snap-update-ns: fix a leaking file descriptor in MkSymlink <Critical> <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5289> | 17:16 |
| slizard | hi folks. I'm seeing some funny stuff in dmesg about apparmor denying the Telegram app do do "mknod" (http://termbin.com/i7eb). Not too familiar with the internals of snaps, but this is somewhat unexpected. Thoughts? | 17:35 |
| zyga | slizard: looking | 17:38 |
| zyga | most likely harmless | 17:39 |
| zyga | ideally we'd look at telegram source code to see what's the impact though | 17:41 |
| mup | PR snapd#5287 closed: testutil: syscall sequence checker <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5287> | 17:44 |
| mup | PR snapd#5291 closed: release: 2.33 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5291> | 17:45 |
| mvo | zyga: \o/ thanks for the merge | 17:45 |
| zyga | :-) | 17:46 |
| zyga | thank you for the release | 17:46 |
| zyga | btw, the tooling PR | 17:46 |
| mvo | my pleasure | 17:46 |
| zyga | I asked for a mount unit instead but if you feel strongly or it is just important to land quickly I can also ack that as-si | 17:46 |
| zyga | *as-is | 17:46 |
| zyga | mvo: some build failures in the ppa | 17:52 |
| zyga | tests | 17:52 |
| slizard | <zyga>: thanks for checking. | 17:52 |
| mvo | zyga: oh, do you have a link? | 17:53 |
| zyga | https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+build/14994462 | 17:53 |
| mvo | zyga: hm, hm, FAIL: devicestate_test.go:488: deviceMgrSuite.TestFullDeviceRegistrationHappyClassicFallback | 17:54 |
| jdstrand | slizard: I think that the telegram snap may have been updated underneath your running telegram. if you stop and restart, that should go away | 17:54 |
| mvo | zyga: might be a racy test | 17:54 |
| slizard | <zyga>: let me check/ | 17:54 |
| jdstrand | slizard: it is a known issue that will be addressed | 17:55 |
| jdstrand | roadmr: not sure you saw my question re turning resquashfs back to enforce. I see r1086 is in the store (thanks!). let's wait til Monday to flip the switch, that way we'll be around if needed | 17:55 |
| zyga | jdstrand: mmm, same refresh problem as always? | 17:56 |
| jdstrand | zyga: yes | 17:56 |
| roadmr | jdstrand: right, best to wait for monday, and apologies, I missed the question earlier :( | 17:56 |
| jdstrand | zyga: the snap has write access to that directory. the only thing it could be was the revision changed from under the running snap | 17:56 |
| jdstrand | roadmr: I'll be starting my holiday on friday (through all of the following week), so I think 4 days of burn in would be a fine indicator | 17:57 |
| jdstrand | it worked really well last time except for electron, which is now fixed upstream and the tools tell people which electron to get, etc, etc, etc | 17:58 |
| roadmr | jdstrand: agreed and we can always flip it off if in doubt and you're not around or somethiing | 17:58 |
| jdstrand | yeah | 17:58 |
| jdstrand | roadmr: I don't know if we'll have something quite like this again, but it is a nice mechanism | 17:59 |
| roadmr | yep :) | 17:59 |
| mup | PR snapcraft#2128 opened: project_loader: stop setting LD_LIBRARY_PATH <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2128> | 18:02 |
| slizard | <jdstrand>: thanks! Restart indeed showed update message and warning is gone. | 18:03 |
| jdstrand | slizard: cool. sorry for the issue; it's on the roadmap to get cleaned up | 18:04 |
| slizard | <jdstrand>: no worries. just wanted to check whether there is an issue that requires attention. | 18:06 |
| * jdstrand nods | 18:06 | |
| jdstrand | there is ;) | 18:06 |
| === CodeMouse92__ is now known as CodeMouse92 | ||
| * cachio afk | 19:07 | |
| * zyga prepares a monster patch | 19:18 | |
| mborzecki | zyga: challenge? :) is it larger than 5253? | 19:53 |
| zyga | mborzecki: we shall see :> | 19:53 |
| mborzecki | hehe | 19:54 |
| zyga | probably not though :) | 19:54 |
| mborzecki | 5258 finally failed the way i wanted it to, apparently snapd.snap-repair.timer is stopped right before the test (?) https://paste.ubuntu.com/p/tD7xrcqPb2/ | 19:57 |
| mborzecki | Fri Jun 8 17:33:49 UTC 2018 is when debug section is entered, while InactiveEnterTimestamp=Fri 2018-06-08 17:32:22 UTC | 19:58 |
| mup | PR snapd#5292 opened: Update docker-support interface for 18.05 <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5292> | 20:37 |
| mup | PR snapd#5293 opened: tests: add retry until the xdg dir can be removed on interfaces-calendar <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5293> | 20:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!