[05:08] morning [06:27] i ran #5397 job 7-8 times now, only one econnreset error, but unrelated to the fix we made, the test got 503 when trying to download the snap what looked like some store side hiccup [06:27] PR #5397: tests/main/econnreset: limit ingress traffic to 512kB/s [06:29] i have seen the mounting squashfs error reproduce a couple of times, and at least one other error which i do not recall seeing before in tests/main/validate-container-failures [06:29] i'll be merging the PR when the travis job becomes green again [06:49] PR snapd#5408 opened: i18n: use xgettext-go --files-from to avoid running into cmdline size limits [06:51] PR snapd#5407 closed: tests: add fedora to distro_clean_package_cache function [07:04] and opensuse downloads flaky too :( [07:05] Good morning [07:06] zyga: hey [07:06] I am heading to school for some errands. I will be back in an hour === pstolowski|afk is now known as pstolowski [07:15] mornings [07:18] pstolowski: heya [07:20] mvo: hi, #5403 uses #5386 :) [07:20] PR #5403: many: use extra "releases" information on store "revision-not-found" errors to produce better errors [07:20] PR #5386: snap: introduce a struct Channel to represent store channels, and helpers to work with it [07:23] pedronis: *cough* sorry and thank you [07:28] pedronis: hi, could you take a look at https://github.com/snapcore/snapd/pull/5387 ? :) [07:28] PR #5387: snap{/snaptest}: set instance key based on snap name [07:29] this unblocks some unit tests for snapstate [07:31] mborzecki: will look in a little bit [07:31] pedronis: thank you [07:40] mvo: are you looking at 5403 atm ? wondering if I should merge or squash merge 5386 [07:42] pedronis: not looking at it right now [07:42] PR snapd#5386 closed: snap: introduce a struct Channel to represent store channels, and helpers to work with it [07:43] PR snapd#5409 opened: tests: run "arp" tests only if arp is available [07:45] mvo: I squashed it, and rebased 5403 [07:47] I signed up my son to a new school [07:47] Heading home soon [07:47] pedronis: ta [07:58] PR snapd#5397 closed: tests/main/econnreset: limit ingress traffic to 512kB/s [08:05] PR core18#42 opened: hooks: port 008-etc-writable.chroot from core16 [08:07] zyga: http://paste.ubuntu.com/p/q87HDCzFqp/ <- this is a failure I see right now on core18 with the interfaces on core PR. I guess this is what you meant yesterday when you said we also need to translate the API calls? [08:10] mborzecki: looks good, left a comment [08:11] pedronis: thanks, looking [08:13] heh and gnome died again, it's probably somethign with nvidia [08:13] the host is not responding over the network [08:13] but the cursor overlay works, pff === mborzeck1 is now known as mborzecki [08:22] mcphail install just openhab-ondra, gadget was only in case you need to use some specific usb dongle [08:22] mcphail if you are not planning to use any usb, then no need for gadget [08:23] mcphail if you want to use some usb device, share with me pid and. vid of that device I will add it. It exposes serial interface slot so you can connect plug from openhab to it [08:28] PR snapd#5410 opened: tests: update tests to work on core18 [08:31] moin moin [08:31] Chipaca: hi [08:31] pedronis: 'sup [08:32] mvo: looking [08:32] Chipaca: mainly #5403 and reviewing stuff [08:32] PR #5403: many: use extra "releases" information on store "revision-not-found" errors to produce better errors [08:33] mvo: yes, exactly that [08:33] Chipaca: and I pinged you here: https://github.com/snapcore/snapd/pull/5386#discussion_r198392974 [08:33] PR #5386: snap: introduce a struct Channel to represent store channels, and helpers to work with it [08:33] mvo: I think it's a bit of a weirdness but we should do it [08:33] mvo: not just because of our tests [08:33] mvo: but perhaps of scripted interactions in the wild [08:33] mvo: muscle memory or bash history [08:34] mvo: I was thinking where to translate that [08:34] mvo: the repository itself is nice but perhaps too naive [08:35] mvo: the disconnect will work but I'm not sure about the connection state, as there are other translation points in the interface manager [08:35] mvo: nothing hard, just something I need to look at [08:38] zyga: yeah, I agree it should work [08:38] pedronis: regarding https://github.com/snapcore/snapd/pull/5387#discussion_r198401006 i can do the instanceName == info.InstanceName() in MockSnapInstance/mockSnap but i need to set instance key in mocnSnap for mount/file locations to be correct, unless i pull the common part to say mockSnapFiles and duplicate the info parsing bits in MockSnap & MockSnapInstance (which I'd like to avoid) [08:38] PR #5387: snap{/snaptest}: set instance key based on snap name [08:38] zyga: I guess the question is at what layer to translate [08:38] pedronis: answered your ping there [08:38] sorry for being late btw, we had to do some paperwork to move our son to a new school [08:38] pedronis: did you answer mvo wrt when architecture would be used, or should i? [08:38] mvo: I think we should translate in the interface manager [08:38] * Chipaca hugs zyga [08:38] mvo: because that captures both connection state and repository connection [08:39] zyga: PAPERWORK IS AWESOME [08:39] hey Chipaca [08:39] hahaha [08:39] Chipaca, the recovering paperwork addict [08:39] Chipaca: he pointed me to the PR that actually uses this [08:39] mvo: fair [08:39] Chipaca: so I think its fine [08:39] zyga: ok [08:39] it is used quite a bit [08:39] mvo: if you want I can look in a sec [08:39] let me just commit something quickly [08:40] Chipaca: anyway your review of #5403 when you can would be appreciated [08:40] PR #5403: many: use extra "releases" information on store "revision-not-found" errors to produce better errors [08:40] Chipaca: did you reach the origami phase where instead of filling in the forms you just fold them [08:40] pedronis: yep, on it [08:40] and daydream [08:40] zyga: so, one change in the hostilization of this process that bit me and delayed me was that they changed from 'list any absences longer than 60 days' to 'list any absences' (ie trips out of the country) [08:41] zyga: the table had three rows [08:41] zyga: so you had to continue it on a separate sheet [08:41] oooh [08:41] I would go to jail if they asked me to fill in all the places I've been to correctly [08:41] so I filled one side of the separate sheet with all the info, turned it around to carry on … and there was a hand-drawn comic on it [08:42] so i guess they're getting an original piece of art together with this sumission [08:42] haha :) [08:42] fridge magnets help [08:42] (it's all got to be handwritten of course, because this is the nineteenth century) [08:42] anyhoo. I'll put that away for now and review stuff :) [08:47] * Son_Goku groans to life [08:48] good morning [08:48] * Chipaca passes Son_Goku the mate [08:48] * Son_Goku wobbles [08:48] Son_Goku: maybe some quick shot of vodka to wake you up ;-) [08:49] * zyga hides [08:49] * Son_Goku runs away [08:49] ... [08:49] * Son_Goku ambles back [08:49] zyga, have you made any progress on implementing the base snap creation to Oz? [08:50] no, I need to schedule that and really work on it soon [08:50] Son_Goku: I have fedora on w510 now so I can work natively on this [08:50] :D [08:50] (and quake, that doesn't help) [08:50] hah [08:50] that game really is fun, it plays surprisingly well on the trackpoint [08:51] well, they _were_ a lot more common when Quake 1 was a fresh game [08:51] I would like to sync about flock and plan when we should deliver stuff [08:51] yeah [08:51] also flock is where, I suspect, we can get most of this ready [08:51] well, Mohan Boddu is interested in syncing with us on this at Flock [08:51] most of the releng team will be there at Flock [08:52] Mohan hit me up this week and was curious about our progress [08:54] * Son_Goku waves to sabdfl_ [08:54] that's cool, I think we should not come to flock empty handed [08:54] it'd be nice to come to Flock with _something_, yeah [08:55] we already mechanically understand what's needed for a base snap [08:55] so I don't see a reason why oz cannot make one [08:55] yeah, I agree [08:56] I think it's mostly figuring out the architecture of oz and friends to do this [08:56] do you think we will be able to reuse any of the shell scripts? [08:56] or will this all involve writing new code [08:56] * Son_Goku wishes GitHub wasn't being unresponsive right now [08:57] what shell scripts? [08:57] we don't have any for making fedora base snap [09:00] there is _a_ python script I wrote to make one [09:01] but I think the answer is generally going to be no [09:02] I mean, those scripts [09:02] I also have some [09:02] ok [09:02] we probably are going to need to adapt this to Fedora tooling, which means a kickstart definition for the base snap, and an imagefactory target for it [09:03] zyga: I looked a bit at #5369, it's nice it is short, it's not super obvious it's correct/maintainable tough, it seems somewhat disperse [09:03] PR #5369: overlord,interfaces,cmd: WIP early support for interfaces on core18 [09:03] zyga: https://pagure.io/fedora-kickstarts/tree/master [09:04] the fedora-docker-* ks files are probably a good starting point [09:04] pedronis: thank you, do you have any ideas on how to improve it? [09:05] zyga: well, tbh, I don't understand even if snap connect for core interaces works there and how :) [09:06] I have a question about that there [09:06] pedronis: pushed a fix [09:07] pedronis: I think mvo and me discussed that operations against explicitly named core snap don't work yet [09:07] implicit operations work fine [09:07] because of the guessing? [09:08] PR snapd#5411 opened: many: remove core-support interface [09:08] yes, the guessing knows about snapd now [09:08] it has priority if it exists (the snapd snap) [09:08] for explicit we need to add one more translation point in doConnect and doDisconnect [09:08] zyga: anyway it sounds we would need some helpers around manipulating conns [09:08] mvo: I opened an RFC to drop core-support [09:08] so it's clear snapd cannot get in there [09:08] pedronis: that's a good idea [09:09] pedronis: I can propose some and then the translations can happen in a single spot [09:10] mvo: I don't know if it will pass spread, let's wait and see [09:14] mvo: you have quite a few PRs open, anything in particular that I should review or re-review? [09:22] Chipaca: when you're done with the paperwork, can you take another look at #5366 ? [09:22] PR #5366: snap: helper for validating snap instance names [09:22] mborzecki: i'm reviewing 5403 right now, i'll get to that later [09:22] Chipaca: thanks [09:28] hmm got xdg-desktop-portals installed and it's showing popoup when runing unit tests [09:29] haha 'Allow snap "some-snap" to open file "/tmp/check-935424627432528910/7"?' [09:30] pedronis: pausing review of that for a bit, will come back to it later [09:30] pedronis: (commented a bunch meanwhile) [09:31] uhh it's the launcher [09:32] mborzecki: I still think that just dropping "invalid instance key" is not nice [09:32] mborzecki: in that it's gobbledegook [09:32] Chipaca: invalid snap instance name? [09:32] mborzecki: do we call it 'instance' anywhere in user-facing stuff other than this error [09:33] like, does 'snap install --help' explain instances [09:34] Chipaca: well the feature refers to them as instances, snap install uses (or will use) --instance when installing from file, other than that there's no explicit instance [09:34] Chipaca: i can go with 'invalid snap name' or sth along these lines [09:34] mborzecki: concretely: I suggest «invalid instance key %q (see 'snap install --help')», and adding a small paragraph to the install help that explains them [09:34] mborzecki: the feature description is not a user-visible document :) [09:34] Hi guys, [09:35] Chipaca: but we cannot really add a paragrah yet for something that is an incomplete experimental feature [09:36] I suppose mborzecki can add a todo there [09:36] yes :) [09:36] works for me [09:36] a TODO is ok [09:36] I can then hit him over the head with it at a later time [09:37] * Chipaca orders a gross of TODO bludgeons off of amazon [09:37] haha [09:37] pedronis: thanks, most should be easy(ish), let me look for some harder ones [09:38] mborzecki: when the help is written, we need to line up instance key vs name between error and help to avoid confusion also [09:38] pedronis: 5392 would be nice [09:39] zyga: thank you [09:39] zyga: hey, #5326 when you have a moment, please [09:39] PR #5326: api/snapctl: allow -h and --help for regular users [09:40] Hi guys, I have a java web application as war file it using tomcat server. Now i want to snap it. please someone guide me. [09:40] I read it last night but I was too tired [09:40] I will do it now [09:40] Chipaca: pushed a patch with TODO note [09:45] hi! i recently read https://github.com/canonical-websites/snapcraft.io/issues/651 and https://blog.ubuntu.com/2018/05/15/trust-and-security-in-the-snap-store and am wondinerg whether embedding (privacy impacting) trackers is currently (1) considered acceptable (b) tested for and (c) how it's being handled, if at all. from my POV this is a major issue on android's primary app ecosystem, and mostly unhandled / unsolved (or rather accepted) there. [09:45] so i'm wondering whether what the situation with snaps is. [09:47] hey tomreyn [09:47] hello zyga [09:47] I don't think we have any official policy about trackers in applications yet [09:48] that's... a shame, [09:48] we don't run applications as a part of the acceptance process, it is fully automated [09:48] let me look at the policy that we have to be sure [09:48] Chipaca: I answered two of your questions, will wait for more feedback [09:52] tomreyn: I don't think the store has any written policy so far, or at least I cannot find any [09:52] PR snapd#5412 opened: userd: fix running unit tests on KDE [09:52] trivial PR ^^ [09:52] tomreyn: I would recommend that you discuss this on the forum as it seems like a goal worth pursuing [09:53] mborzecki: +1 but use Also [09:53] so one restore less [09:53] look at what MockCommand return value MockCmd can do [09:54] interesting, will do [09:55] tomreyn: discussions on IRC are immediate but actually miss quite a lot of the people that participate in snaps [09:55] tomreyn: a thread on forum.snapcraft.io, in the store category, is the best way to ensure the key people read tihs [09:55] zyga: thanks for checking. personally i don't think snaps a a goal worth pursuing so i'm not interested in investing time on improving the policies around it. hope you don't mind. [09:56] zyga: pushed [09:56] tomreyn: not at all, have a nice day :) [09:56] thanks for your time, though. [10:01] zyga: another question, if you have the time: is there a policy which defines which snaps get security support by canonical (in that canonical takes measures to ensure that known security vulnerabilities are overcome in a short amount of time, similar to how the ubuntu security team does it for the supported apt repositories)? [10:01] yes, there is that [10:01] may I ask why are you interested having said that snaps are not worth pursuing? [10:02] oh, that's good. ubuntu 18.04 installs gnome-calculator as a snap by default, so i was hoping so. [10:02] all snaps owned (as snap names) by canonical [10:02] have secutity support guarantees [10:02] zyga: all snaps with a for-stable-ubuntu branch also [10:02] Chipaca: thanks, I didn't know that [10:03] snaps installed by default are tracking an ad-hoc branch, not latest/stable, for this purpose [10:03] at least that's my understanding :-) i haven't checked, not having an 18.04 to hand [10:04] but, as I say, curious why tomreyn is simultaneously curious and incurious [10:04] I can be curious about things I don't favor. [10:04] tomreyn: yes :) [10:04] tomreyn: but you said something like it 'not being worth your time', which is rather less than not favouring it [10:05] tomreyn: snaps and similar efforst are an important part of application distribution, if you look at docker it's been very influential and has changed how many people work, deploy and use software. [10:05] while you may dislike snaps or anything else, having sane, safe behavior for something used by many people is important to us [10:05] I don't favour systemd, myself, but here we are :) [10:05] *efforts [10:06] zyga: sure, i'm happy to discuss my discontent with snaps. i like decentralized architectures, the snap store is centralized. i'm an open source enthusiast, snaps opens the door too widely to proprietary software. i also think that at this time, using snaps and debugging issues from a user perspective is badly documented, so it is difficult to know how to recover from issues. [10:07] ondra: that's great. thanks! (and thanks for the snap, too) [10:07] tomreyn: ironically distributing open source software is really hard today [10:08] much harder than proprietary software [10:08] tomreyn, it opens the door the same way for opensource SW [10:08] the way it was introduced in ubuntu was quite intrasparant. the average user does not even know there ar enow two different mechanism to install packages and they would not know where to look for problems. [10:08] I, as someone working on FOSS for about a decade now, really appreciate that software distribution is breaking away from the initial taxonomy-driven library model [10:09] and why would the user need to know that ? she just wants to use some software [10:09] tomreyn: as with all new software, no matter how many times new things are announced, some poeple will be taken by surprise [10:09] tomreyn: this is not unique to snaps, it's just how people deal witch change [10:09] ogra_: that's correct, just, traditionally, debian, and also ubuntu, wasn't as embracing to proprietary software. [10:10] thats not true ... ubuntus focus was always "the best user experience" ... i.e. "linux for human beings ..." [10:10] tomreyn: I think ubuntu was always driven by being nice to people and that includes being able to use the software that said people want to use, proprietary or not [10:10] * zyga hugs ogra [10:10] we have shipped proprietary nvidia drivers from day one [10:10] (we are not in the same room btw, :D [10:10] heh [10:10] I'm in a park with my dog, working on a bench [10:10] that's a new value of "one" [10:10] and ogra is probably 1000km away [10:10] not even in the same country :) [10:11] tomreyn: note that gnome-software has a mode now (not sure if released yet as we tend to see "git master" more often than not) where you can see just FOSS software [10:11] tomreyn: that includes snaps [10:11] zyga: i agree about the effects of introducing new technology. but don't you think more efforts should have been spent on educating users as to what these changes mean for them, and for how they need to manage their systems? [10:12] tomreyn: I think that it is impossible to make everyone happe, I can bring some people here who will compain that I'm not addressing the issue they have, add the feature they want instead of documenting something [10:12] tomreyn: the best way to ensure it is really the best software experience across linux is to help [10:12] but do you think someone using gnome-software actually *wants* to "manage their system" ? they just want an easy way to get their software [10:12] become an advocate [10:12] document, explain, educate [10:12] point out issues, help address them [10:13] help with the design and with bug fixing [10:13] whatever you feel like doing or feel you are good at [10:13] we are only a handful of people [10:13] if you really needs to be an admin and i.e. "manage your system" you probably dive deeper into the system anyway and will learn abouut snap as you will learn about debs [10:13] we are not a mega-corp with 100M monthly budget on advertising [10:13] sure, there is only so much time when you have limited resources available. i did not mean to blame you or anyone for not documenting things enough. things could probably have been smoother if there had been more people available to work on it. [10:13] we cannot do everything ourselves [10:14] exatly [10:14] please feel welcome here [10:14] join us [10:14] the forum is a fantastic place to contribute [10:14] my mother, or sister definitely do not care about the mechanism how their SW is delivered to them as long as the apps start and run flawlessly [10:14] no coding is needed [10:14] you can document how snaps work, how they are different, you can make people see this [10:14] the forum is being used to drive documentation pages [10:14] (literally, certain posts just show up as documentation on other pages) [10:14] so anything you contribute has immediate real vlaue [10:15] *value [10:15] and it is very good to be sceptical about it [10:15] you are not the only one [10:15] seeing how snaps operate, how the policy is made is the best way to keep people working on it as a day job honest [10:15] so please, stay around, look around and see how you can help - this is how FOSS works [10:15] thanks for the invitation. ;) i'll decline for now (since i'm still thinking that snaps will drive ubuntu in a direction i do not want to support), but maybe my mind will change in the future, you never know. and you placed a good seed there. [10:16] in the meantime, I need to review a patch from a colleague [10:16] thanks for your time. [10:16] cjwatson, did warty not have the drivers on disk (iirc they were shipped but a manual install was needed) ? [10:17] PR snapd#5413 opened: tests: purge packages installed by accounts, calendar, and contacts interface tests [10:18] tomreyn: one last question [10:19] ICBW but I don't think they worked properly until hoary. In any case it was a massive controversy when we started considering doing more stuff with them by way of compiz and the like [10:19] tomreyn: do you have any software you made yourself that you share with others? [10:19] so it's pretty ahistorical to say that Ubuntu has always been all the way over to one end of the spectrum; we've gone back and forth a lot [10:19] yeah, i do remember that ... but i thougth we always had restricted on the CD from the start [10:19] but i probably mis-remember and t was hoary ... [10:20] *it [10:20] zyga: i contribute to an open source game, megaglest. but i didnt write it myself. it's a fork which i help manage / develop. [10:20] ogra_: I *think* that was only since hoary [10:20] k [10:20] tomreyn: are you involved in publishing aspect of that game? [10:20] so day "two" :) [10:20] zyga: i have a voice in it. what's your point? [10:21] oh look, I have warty images lying around [10:21] tomreyn: did you try to ensure that the latest version of your game is available in debian, ubuntu, fedora and opensuse for example [10:21] or that the bug you fixed is released there [10:21] i even have my original warty laptop ... but it is in some box in the basement :) [10:21] they had restricted on the image, but no nvidia [10:21] ah [10:22] linux-amd64-generic was in restricted for some reason [10:22] people see snaps as some uneeded evil often don't have the first hand experience in delivering software across releases of one distribution, let alone across many [10:22] heh [10:22] oh, no, nvidia-kernel-common was on the i386 install image [10:22] I wanted to know if you have experience or stories about that [10:22] but not amd64, presumably for reasons ... [10:22] amd64 was still young in 2004 ... [10:23] pstolowski: so snapctl get as a regular user can read configuration of any snap? [10:23] i guess nvidia didnt provide 64bit binaries back then [10:23] yeah, could well be [10:24] the baseline architecture worked well but it was still considered slightly exotic [10:24] yep [10:25] zyga: only *own* snap (needs a valid context, so needs to be run by an app itself) [10:25] zyga: yes, it's a hassle if you want to be compatible to all or most linux distros and make installing and upgrading easy. if the software was more widely used i would probably spend time on packaging it using flatpack. [10:25] tomreyn: maybe it is not widely used becaue it's not widely available due to packaging complexity? [10:26] i don't think that's the case, no. [10:26] Megaglest is in all major distros, and we don't get to see a lot of players. it's an old game with an old graphics engine. [10:27] pstolowski: how do you define "own" snaps? [10:28] pstolowski: I mean running "snapctl" outside of snap world [10:28] zyga: by presence of context [10:28] ah, isee [10:28] zyga: (cookie) [10:28] and without that? [10:28] pstolowski: (review sent) [10:29] zyga: without context snapctl get errors out (only -h flag will work) [10:29] thanks! [10:30] Download (curl) error for 'http://download.opensuse.org/distribution/leap/42.3/repo/oss/suse/x86_64/libcap-devel-2.22-18.16.x86_64.rpm': [10:30] Error code: Curl error 52 [10:30] Error message: Empty reply from server [10:30] ehh [10:31] zyga: thanks for the review; okay, i see where your question comes from, i'll add a comment in the code, "as is" it may look scary at first [10:31] I was thinking if we could grep for something and retry common apt/dnf/zypper/pacman/git operations [10:31] #5412 super simple review, anyone? [10:31] PR #5412: userd: fix running unit tests on KDE [10:32] merge it [10:33] PR snapd#5412 closed: userd: fix running unit tests on KDE [10:36] zyga: so, i just reflected a bit more about my disappreciation, and to at least contribute *someething* to your efforts, i tried to condense the aspects i'm most hesitant about when it comes to snaps: privacy concerns: witht he classic apt repos i can tell pretty well that this software has received *some* level of review, and can mostly rely on this to prevent, for example, i install software which analyzes and tracks me / my use of it / the [10:36] computer etc. with snaps, i don't have an easy way to tell where i can rely on things to be 'clean' of such issues and where not. the other aspect is security: there are two sub aspects here: for once, very much as for the privacy concerns i have, i also might install one snap but receive some bundled software i don't want, and i have no easy way to tell whether that's so or not. the other aspect is that while it's great that security updates [10:36] can be shipped so easily - unless i can know what gets regular security updates and what doesn't, i can easily end up with software in a known vulnerable version, but no9t realize it. [10:41] tomreyn: I am afk for a bit. I will reply when I’m back [10:42] sure [10:50]