[05:08] <mborzecki> morning
[06:27] <mborzecki> 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] <mup> PR #5397: tests/main/econnreset: limit ingress traffic to 512kB/s <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5397>
[06:29] <mborzecki> 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] <mborzecki> i'll be merging the PR when the travis job becomes green again
[06:49] <mup> PR snapd#5408 opened:  i18n: use xgettext-go --files-from to avoid running into cmdline size limits <Created by mvo5> <https://github.com/snapcore/snapd/pull/5408>
[06:51] <mup> PR snapd#5407 closed: tests: add fedora to distro_clean_package_cache function <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5407>
[07:04] <mborzecki> and opensuse downloads flaky too :(
[07:05] <zyga> Good morning
[07:06] <mborzecki> zyga: hey
[07:06] <zyga> I am heading to school for some errands. I will be back in an hour
[07:15] <pstolowski> mornings
[07:18] <mborzecki> pstolowski: heya
[07:20] <pedronis> mvo: hi,   #5403 uses #5386 :)
[07:20] <mup> PR #5403: many: use extra "releases" information on store "revision-not-found" errors to produce better errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/5403>
[07:20] <mup> PR #5386: snap: introduce a struct Channel to represent store channels, and helpers to work with it <Created by pedronis> <https://github.com/snapcore/snapd/pull/5386>
[07:23] <mvo> pedronis: *cough* sorry and thank you
[07:28] <mborzecki> pedronis: hi, could you take a look at https://github.com/snapcore/snapd/pull/5387 ? :)
[07:28] <mup> PR #5387: snap{/snaptest}: set instance key based on snap name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5387>
[07:29] <mborzecki> this unblocks some unit tests for snapstate
[07:31] <pedronis> mborzecki: will look in a little bit
[07:31] <mborzecki> pedronis: thank you
[07:40] <pedronis> mvo: are you looking at 5403 atm ?   wondering if I should merge or squash merge 5386
[07:42] <mvo> pedronis: not looking at it right now
[07:42] <mup> PR snapd#5386 closed: snap: introduce a struct Channel to represent store channels, and helpers to work with it <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5386>
[07:43] <mup> PR snapd#5409 opened: tests: run "arp" tests only if arp is available <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5409>
[07:45] <pedronis> mvo: I squashed it, and rebased 5403
[07:47] <zyga> I signed up my son to a new school
[07:47] <zyga> Heading home soon
[07:47] <mvo> pedronis: ta
[07:58] <mup> PR snapd#5397 closed: tests/main/econnreset: limit ingress traffic to 512kB/s <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5397>
[08:05] <mup> PR core18#42 opened: hooks: port 008-etc-writable.chroot from core16 <Created by mvo5> <https://github.com/snapcore/core18/pull/42>
[08:07] <mvo> 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] <pedronis> mborzecki: looks good, left a comment
[08:11] <mborzecki> pedronis: thanks, looking
[08:13] <mborzeck1> heh and gnome died again, it's probably somethign with nvidia
[08:13] <mborzeck1> the host is not responding over the network
[08:13] <mborzeck1> but the cursor overlay works, pff
[08:22] <ondra> mcphail install just openhab-ondra, gadget was only in case you need to use some specific usb dongle
[08:22] <ondra> mcphail if you are not planning to use any usb, then no need for gadget
[08:23] <ondra> 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] <mup> PR snapd#5410 opened: tests: update tests to work on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5410>
[08:31] <Chipaca> moin moin
[08:31] <pedronis> Chipaca: hi
[08:31] <Chipaca> pedronis: 'sup
[08:32] <zyga> mvo: looking
[08:32] <pedronis> Chipaca: mainly #5403  and reviewing stuff
[08:32] <mup> PR #5403: many: use extra "releases" information on store "revision-not-found" errors to produce better errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/5403>
[08:33] <zyga> mvo: yes, exactly that
[08:33] <pedronis> Chipaca: and I pinged you here:  https://github.com/snapcore/snapd/pull/5386#discussion_r198392974
[08:33] <mup> PR #5386: snap: introduce a struct Channel to represent store channels, and helpers to work with it <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5386>
[08:33] <zyga> mvo: I think it's a bit of a weirdness but we should do it
[08:33] <zyga> mvo: not just because of our tests
[08:33] <zyga> mvo: but perhaps of scripted interactions in the wild
[08:33] <zyga> mvo: muscle memory or bash history
[08:34] <zyga> mvo: I was thinking where to translate that
[08:34] <zyga> mvo: the repository itself is nice but perhaps too naive
[08:35] <zyga> 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] <zyga> mvo: nothing hard, just something I need to look at
[08:38] <mvo> zyga: yeah, I agree it should work
[08:38] <mborzecki> 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] <mup> PR #5387: snap{/snaptest}: set instance key based on snap name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5387>
[08:38] <mvo> zyga: I guess the question is at what layer to translate
[08:38] <Chipaca> pedronis: answered your ping there
[08:38] <zyga> sorry for being late btw, we had to do some paperwork to move our son to a new school
[08:38] <Chipaca> pedronis: did you answer mvo wrt when architecture would be used, or should i?
[08:38] <zyga> mvo: I think we should translate in the interface manager
[08:38]  * Chipaca hugs zyga
[08:38] <zyga> mvo: because that captures both connection state and repository connection
[08:39] <Chipaca> zyga: PAPERWORK IS AWESOME
[08:39] <zyga> hey Chipaca
[08:39] <zyga> hahaha
[08:39] <zyga> Chipaca, the recovering paperwork addict
[08:39] <mvo> Chipaca: he pointed me to the PR that actually uses this
[08:39] <Chipaca> mvo: fair
[08:39] <mvo> Chipaca: so I think its fine
[08:39] <mvo> zyga: ok
[08:39] <pedronis> it is used quite a bit
[08:39] <zyga> mvo: if you want I can look in a sec
[08:39] <zyga> let me just commit something quickly
[08:40] <pedronis> Chipaca: anyway your review of #5403 when you can would be appreciated
[08:40] <mup> PR #5403: many: use extra "releases" information on store "revision-not-found" errors to produce better errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/5403>
[08:40] <zyga> Chipaca: did you reach the origami phase where instead of filling in the forms you just fold them
[08:40] <Chipaca> pedronis: yep, on it
[08:40] <zyga> and daydream
[08:40] <Chipaca> 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] <Chipaca> zyga: the table had three rows
[08:41] <Chipaca> zyga: so you had to continue it on a separate sheet
[08:41] <zyga> oooh
[08:41] <zyga> I would go to jail if they asked me to fill in all the places I've been to correctly
[08:41] <Chipaca> 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] <Chipaca> so i guess they're getting an original piece of art together with this sumission
[08:42] <zyga> haha :)
[08:42] <zyga> fridge magnets help
[08:42] <Chipaca> (it's all got to be handwritten of course, because this is the nineteenth century)
[08:42] <Chipaca> anyhoo. I'll put that away for now and review stuff :)
[08:47]  * Son_Goku groans to life
[08:48] <zyga> good morning
[08:48]  * Chipaca passes Son_Goku the mate
[08:48]  * Son_Goku wobbles
[08:48] <zyga> Son_Goku: maybe some quick shot of vodka to wake you up ;-)
[08:49]  * zyga hides
[08:49]  * Son_Goku runs away
[08:49] <Son_Goku> ...
[08:49]  * Son_Goku ambles back
[08:49] <Son_Goku> zyga, have you made any progress on implementing the base snap creation to Oz?
[08:50] <zyga> no, I need to schedule that and really work on it soon
[08:50] <zyga> Son_Goku: I have fedora on w510 now so I can work natively on this
[08:50] <Son_Goku> :D
[08:50] <zyga> (and quake, that doesn't help)
[08:50] <Son_Goku> hah
[08:50] <zyga> that game really is fun, it plays surprisingly well on the trackpoint
[08:51] <Son_Goku> well, they _were_ a lot more common when Quake 1 was a fresh game
[08:51] <zyga> I would like to sync about flock and plan when we should deliver stuff
[08:51] <Son_Goku> yeah
[08:51] <zyga> also flock is where, I suspect, we can get most of this ready
[08:51] <Son_Goku> well, Mohan Boddu is interested in syncing with us on this at Flock
[08:51] <Son_Goku> most of the releng team will be there at Flock
[08:52] <Son_Goku> Mohan hit me up this week and was curious about our progress
[08:54]  * Son_Goku waves to sabdfl_
[08:54] <zyga> that's cool, I think we should not come to flock empty handed
[08:54] <Son_Goku> it'd be nice to come to Flock with _something_, yeah
[08:55] <Son_Goku> we already mechanically understand what's needed for a base snap
[08:55] <Son_Goku> so I don't see a reason why oz cannot make one
[08:55] <zyga> yeah, I agree
[08:56] <zyga> I think it's mostly figuring out the architecture of oz and friends to do this
[08:56] <zyga> do you think we will be able to reuse any of the shell scripts?
[08:56] <zyga> or will this all involve writing new code
[08:56]  * Son_Goku wishes GitHub wasn't being unresponsive right now
[08:57] <Son_Goku> what shell scripts?
[08:57] <Son_Goku> we don't have any for making fedora base snap
[09:00] <Son_Goku> there is _a_ python script I wrote to make one
[09:01] <Son_Goku> but I think the answer is generally going to be no
[09:02] <zyga> I mean, those scripts
[09:02] <zyga> I also have some
[09:02] <zyga> ok
[09:02] <Son_Goku> 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] <pedronis> 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] <mup> PR #5369: overlord,interfaces,cmd: WIP early support for interfaces on core18 <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5369>
[09:03] <Son_Goku> zyga: https://pagure.io/fedora-kickstarts/tree/master
[09:04] <Son_Goku> the fedora-docker-* ks files are probably a good starting point
[09:04] <zyga> pedronis: thank you, do you have any ideas on how to improve it?
[09:05] <pedronis> zyga: well, tbh, I don't understand even if   snap connect for core interaces works there and how :)
[09:06] <pedronis> I have a question about that there
[09:06] <mborzecki> pedronis: pushed a fix
[09:07] <zyga> pedronis: I think mvo and me discussed that operations against explicitly named core snap don't work yet
[09:07] <zyga> implicit operations work fine
[09:07] <pedronis> because of the guessing?
[09:08] <mup> PR snapd#5411 opened: many: remove core-support interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5411>
[09:08] <zyga> yes, the guessing knows about snapd now
[09:08] <zyga> it has priority if it exists (the snapd snap)
[09:08] <zyga> for explicit we need to add one more translation point in doConnect and doDisconnect
[09:08] <pedronis> zyga: anyway it sounds we would need some helpers around manipulating conns
[09:08] <zyga> mvo: I opened an RFC to drop core-support
[09:08] <pedronis> so it's clear  snapd cannot get in there
[09:08] <zyga> pedronis: that's a good idea
[09:09] <zyga> pedronis: I can propose some and then the translations can happen in a single spot
[09:10] <zyga> mvo: I don't know if it will pass spread, let's wait and see
[09:14] <pedronis> mvo: you have quite a few PRs open, anything in particular that I should review or re-review?
[09:22] <mborzecki> Chipaca: when you're done with the paperwork, can you take another look at #5366 ?
[09:22] <mup> PR #5366: snap: helper for validating snap instance names <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5366>
[09:22] <Chipaca> mborzecki: i'm reviewing 5403 right now, i'll get to that later
[09:22] <mborzecki> Chipaca: thanks
[09:28] <mborzecki> hmm got xdg-desktop-portals installed and it's showing popoup when runing unit tests
[09:29] <mborzecki> haha 'Allow snap "some-snap" to open file "/tmp/check-935424627432528910/7"?'
[09:30] <Chipaca> pedronis: pausing review of that for a bit, will come back to it later
[09:30] <Chipaca> pedronis: (commented a bunch meanwhile)
[09:31] <mborzecki> uhh it's the launcher
[09:32] <Chipaca> mborzecki: I still think that just dropping "invalid instance key" is not nice
[09:32] <Chipaca> mborzecki: in that it's gobbledegook
[09:32] <mborzecki> Chipaca: invalid snap instance name?
[09:32] <Chipaca> mborzecki: do we call it 'instance' anywhere in user-facing stuff other than this error
[09:33] <Chipaca> like, does 'snap install --help' explain instances
[09:34] <mborzecki> 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] <mborzecki> Chipaca: i can go with 'invalid snap name' or sth along these lines
[09:34] <Chipaca> 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] <Chipaca> mborzecki: the feature description is not a user-visible document :)
[09:34] <jack> Hi guys,
[09:35] <pedronis> Chipaca: but we cannot really add a paragrah yet for something that is an incomplete experimental feature
[09:36] <pedronis> I suppose mborzecki can add a todo there
[09:36] <Chipaca> yes :)
[09:36] <mborzecki> works for me
[09:36] <Chipaca> a TODO is ok
[09:36] <Chipaca> 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] <mborzecki> haha
[09:37] <mvo> pedronis: thanks, most should be easy(ish), let me look for some harder ones
[09:38] <Chipaca> 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] <mvo> pedronis: 5392 would be nice
[09:39] <mvo> zyga: thank you
[09:39] <pstolowski> zyga: hey, #5326 when you have a moment, please
[09:39] <mup> PR #5326: api/snapctl: allow -h and --help for regular users <Created by stolowski> <https://github.com/snapcore/snapd/pull/5326>
[09:40] <sam__> 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] <zyga> I read it last night but I was too tired
[09:40] <zyga> I will do it now
[09:40] <mborzecki> Chipaca: pushed a patch with TODO note
[09:45] <tomreyn> 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] <tomreyn> so i'm wondering whether what the situation with snaps is.
[09:47] <zyga> hey tomreyn
[09:47] <tomreyn> hello zyga
[09:47] <zyga> I don't think we have any official policy about trackers in applications yet
[09:48] <tomreyn> that's... a shame,
[09:48] <zyga> we don't run applications as a part of the acceptance process, it is fully automated
[09:48] <zyga> let me look at the policy that we have to be sure
[09:48] <pedronis> Chipaca: I answered two of your questions, will wait for more feedback
[09:52] <zyga> tomreyn: I don't think the store has any written policy so far, or at least I cannot find any
[09:52] <mup> PR snapd#5412 opened: userd: fix running unit tests on KDE <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5412>
[09:52] <mborzecki> trivial PR ^^
[09:52] <zyga> tomreyn: I would recommend that you discuss this on the forum as it seems like a goal worth pursuing
[09:53] <zyga> mborzecki: +1 but use Also
[09:53] <zyga> so one restore less
[09:53] <zyga> look at what MockCommand return value MockCmd can do
[09:54] <mborzecki> interesting, will do
[09:55] <zyga> tomreyn: discussions on IRC are immediate but actually miss quite a lot of the people that participate in snaps
[09:55] <zyga> tomreyn: a thread on forum.snapcraft.io, in the store category, is the best way to ensure the key people read tihs
[09:55] <tomreyn> 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] <mborzecki> zyga: pushed
[09:56] <zyga> tomreyn: not at all, have a nice day :)
[09:56] <tomreyn> thanks for your time, though.
[10:01] <tomreyn> 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] <zyga> yes, there is that
[10:01] <zyga> may I ask why are you interested having said that snaps are not worth pursuing?
[10:02] <tomreyn> oh, that's good. ubuntu 18.04 installs gnome-calculator as a snap by default, so i was hoping so.
[10:02] <zyga> all snaps owned (as snap names) by canonical
[10:02] <zyga> have secutity support guarantees
[10:02] <Chipaca> zyga: all snaps with a for-stable-ubuntu branch also
[10:02] <zyga> Chipaca: thanks, I didn't know that
[10:03] <Chipaca> snaps installed by default are tracking an ad-hoc branch, not latest/stable, for this purpose
[10:03] <Chipaca> at least that's my understanding :-) i haven't checked, not having an 18.04 to hand
[10:04] <Chipaca> but, as I say, curious why tomreyn is simultaneously curious and incurious
[10:04] <tomreyn> I can be curious about things I don't favor.
[10:04] <Chipaca> tomreyn: yes :)
[10:04] <Chipaca> tomreyn: but you said something like it 'not being worth your time', which is rather less than not favouring it
[10:05] <zyga> 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] <zyga> while you may dislike snaps or anything else, having sane, safe behavior for something used by many people is important to us
[10:05] <Chipaca> I don't favour systemd, myself, but here we are :)
[10:05] <zyga> *efforts
[10:06] <tomreyn> 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] <mcphail> ondra: that's great. thanks! (and thanks for the snap, too)
[10:07] <zyga> tomreyn: ironically distributing open source software is really hard today
[10:08] <zyga> much harder than proprietary software
[10:08] <ogra_> tomreyn, it opens the door the same way for opensource SW
[10:08] <tomreyn> 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] <zyga> 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] <ogra_> and why would the user need to know that ? she just wants to use some software
[10:09] <zyga> tomreyn: as with all new software, no matter how many times new things are announced, some poeple will be taken by surprise
[10:09] <zyga> tomreyn: this is not unique to snaps, it's just how people deal witch change
[10:09] <tomreyn> ogra_: that's correct, just, traditionally, debian, and also ubuntu, wasn't as embracing to proprietary software.
[10:10] <ogra_> thats not true ... ubuntus focus was always "the best user experience" ... i.e. "linux for human beings ..."
[10:10] <zyga> 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] <ogra_> we have shipped proprietary nvidia drivers from day one
[10:10] <zyga> (we are not in the same room btw, :D
[10:10] <ogra_> heh
[10:10] <zyga> I'm in a park with my dog, working on a bench
[10:10] <cjwatson> that's a new value of "one"
[10:10] <zyga> and ogra is probably 1000km away
[10:10] <ogra_> not even in the same country :)
[10:11] <zyga> 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] <zyga> tomreyn: that includes snaps
[10:11] <tomreyn> 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] <zyga> 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] <zyga> tomreyn: the best way to ensure it is really the best software experience across linux is to help
[10:12] <ogra_> 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] <zyga> become an advocate
[10:12] <zyga> document, explain, educate
[10:12] <zyga> point out issues, help address them
[10:13] <zyga> help with the design and with bug fixing
[10:13] <zyga> whatever you feel like doing or feel you are good at
[10:13] <zyga> we are only a handful of people
[10:13] <ogra_> 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] <zyga> we are not a mega-corp with 100M monthly budget on advertising
[10:13] <tomreyn> 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] <zyga> we cannot do everything ourselves
[10:14] <zyga> exatly
[10:14] <zyga> please feel welcome here
[10:14] <zyga> join us
[10:14] <zyga> the forum is a fantastic place to contribute
[10:14] <ogra_> 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] <zyga> no coding is needed
[10:14] <zyga> you can document how snaps work, how they are different, you can make people see this
[10:14] <zyga> the forum is being used to drive documentation pages
[10:14] <zyga> (literally, certain posts just show up as documentation on other pages)
[10:14] <zyga> so anything you contribute has immediate real vlaue
[10:15] <zyga> *value
[10:15] <zyga> and it is very good to be sceptical about it
[10:15] <zyga> you are not the only one
[10:15] <zyga> 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] <zyga> so please, stay around, look around and see how you can help - this is how FOSS works
[10:15] <tomreyn> 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] <zyga> in the meantime, I need to review a patch from a colleague
[10:16] <tomreyn> thanks for your time.
[10:16] <ogra_> cjwatson, did warty not have the drivers on disk (iirc they were shipped but a manual install was needed) ?
[10:17] <mup> PR snapd#5413 opened: tests: purge packages installed by accounts, calendar, and contacts interface tests <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5413>
[10:18] <zyga> tomreyn: one last question
[10:19] <cjwatson> 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] <zyga> tomreyn: do you have any software you made yourself that you share with others?
[10:19] <cjwatson> 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] <ogra_> yeah, i do remember that ... but i thougth we always had restricted on the CD from the start
[10:19] <ogra_> but i probably mis-remember and t was hoary ...
[10:20] <ogra_> *it
[10:20] <tomreyn> 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] <cjwatson> ogra_: I *think* that was only since hoary
[10:20] <ogra_> k
[10:20] <zyga> tomreyn: are you involved in publishing aspect of that game?
[10:20] <ogra_> so day "two" :)
[10:20] <tomreyn> zyga: i have a voice in it. what's your point?
[10:21] <cjwatson> oh look, I have warty images lying around
[10:21] <zyga> 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] <zyga> or that the bug you fixed is released there
[10:21] <ogra_> i even have my original warty laptop ... but it is in some box in the basement :)
[10:21] <cjwatson> they had restricted on the image, but no nvidia
[10:21] <ogra_> ah
[10:22] <cjwatson> linux-amd64-generic was in restricted for some reason
[10:22] <zyga> 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] <ogra_> heh
[10:22] <cjwatson> oh, no, nvidia-kernel-common was on the i386 install image
[10:22] <zyga> I wanted to know if you have experience or stories about that
[10:22] <cjwatson> but not amd64, presumably for reasons ...
[10:22] <ogra_> amd64 was still young in 2004 ...
[10:23] <zyga> pstolowski: so snapctl get as a regular user can read configuration of any snap?
[10:23] <ogra_> i guess nvidia didnt provide 64bit binaries back then
[10:23] <cjwatson> yeah, could well be
[10:24] <cjwatson> the baseline architecture worked well but it was still considered slightly exotic
[10:24] <ogra_> yep
[10:25] <pstolowski> zyga: only *own* snap (needs a valid context, so needs to be run by an app itself)
[10:25] <tomreyn> 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] <zyga> tomreyn: maybe it is not widely used becaue it's not widely available due to packaging complexity?
[10:26] <tomreyn> i don't think that's the case, no.
[10:26] <tomreyn> 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] <zyga> pstolowski: how do you define "own" snaps?
[10:28] <zyga> pstolowski: I mean running "snapctl" outside of snap world
[10:28] <pstolowski> zyga: by presence of context
[10:28] <zyga> ah, isee
[10:28] <pstolowski> zyga: (cookie)
[10:28] <zyga> and without that?
[10:28] <zyga> pstolowski: (review sent)
[10:29] <pstolowski> zyga: without context snapctl get errors out (only -h flag will work)
[10:29] <zyga> thanks!
[10:30] <mborzecki> 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] <mborzecki> Error code: Curl error 52
[10:30] <mborzecki> Error message: Empty reply from server
[10:30] <mborzecki> ehh
[10:31] <pstolowski> 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] <zyga> I was thinking if we could grep for something and retry common apt/dnf/zypper/pacman/git operations
[10:31] <mborzecki> #5412 super simple review, anyone?
[10:31] <mup> PR #5412: userd: fix running unit tests on KDE <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5412>
[10:32] <zyga> merge it
[10:33] <mup> PR snapd#5412 closed: userd: fix running unit tests on KDE <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5412>
[10:36] <tomreyn> 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] <tomreyn> 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] <tomreyn> 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] <zyga> tomreyn: I am afk for a bit. I will reply when I’m back
[10:42] <tomreyn> sure
[10:50] <ondra> mcphail feel free to ping me if I forget updating it, are you tracking stable or other channel?
[10:50] <popey> ondra: automate the builds!
[10:51] <ondra> popey I do consume product of one jenkins, which I do not have control over, so it's hard to automate fully
[10:52] <ondra> popey I need some job periodically checking if there is new thing on jenkins
[10:52] <mup> PR snapd#5414 opened: corecfg: added experimental.hotplug feature flag <Created by stolowski> <https://github.com/snapcore/snapd/pull/5414>
[10:53] <ondra> popey we will eventually get jenkins intergation there, but for that we need hotplug so openhab foundation is happy to adopt snaps, long storey :)
[10:53] <ondra> mcphail BTW if you are in homekit camp, you might be also interested in homebridge snap
[10:59] <mup> PR snapd#5415 opened: interfaces: moved normalize method to interfaces/utils and made it public <Created by stolowski> <https://github.com/snapcore/snapd/pull/5415>
[11:05] <pedronis> mvo:  I did a pass over 5392
[11:19] <zyga> https://www.irccloud.com/pastebin/BJ7ooq1z/
[11:19] <zyga> tomreyn: ^
[11:28] <ogra_> now ... that remonds me that i have to rebuild 4 of my snaps for the libssl CVE ... the store spammed me tonight i should do that :)
[11:28] <ogra_> *reminds
[11:29] <mvo> pedronis: thank you!
[11:37] <mup> PR snapd#5416 opened: interfaces/hotplug: add hotplug Specification and HotplugDeviceInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/5416>
[11:42] <mcphail> ondra: cheers. i've just installed the stable channel. i haven't poked it yet. i'm hoping i can replace my openhabianpi installation
[11:44] <tomreyn> zyga: my response https://paste.ubuntu.com/p/gVWpdPFxrY/
[11:46] <ogra_> tomreyn, your assumption is wrong, the centralized store does exactly that ... it auto-reviews every upload (and even monitors it during its lifetime)
[11:47] <ogra_> and thats only possible with such a centalized model
[11:47] <ogra_> the security model around snaps removes most needs for manual reviews (yet they happen for some special cases like gadget snaps or kernel snaps)
[11:49] <tomreyn> ogra_: then how did the miner make it in there, and what about user tracking? maybe the automated review process is just not as good as a manual one?
[11:49] <zyga> tomreyn: in reality, there is no manual review (anywhere) that is detailed, there is only trust and reaction in case of mistakes
[11:49] <ogra_> it definitely isnt ... but do you think manual reviews in distros are any better ?
[11:49] <zyga> nobody reads code in detail
[11:49] <tomreyn> you probably want them both manual and automated, though
[11:50] <zyga> and really nasty code can be obfuscated
[11:50] <zyga> tomreyn: snaps make you trust the publisher (a specific entity) rather than the middle man
[11:50] <ogra_> tomreyn, note that 90% of uploads to distro archives are not regularly reviewed either
[11:50] <zyga> in both cases (distro and app store) there are ways to catch up with nasty software
[11:50] <zyga> to block it, patch it out
[11:51] <ogra_> a deb usually gets an initial review and then the developer uploads on hs own afterwards
[11:51] <zyga> in reality there is not much difference there
[11:51] <tomreyn> right, snaps make the user have trust relations to *many* publishers, which is overwhelming
[11:51] <ogra_> well
[11:51] <zyga> if you trust mozilla with firefox, use firefox as a snap, or as the tarball from their website, or as the deb in ubuntu
[11:51] <ogra_> snaps rather make the user trust into the security model
[11:51] <zyga> tomreyn: yes but that is _reality_
[11:51] <zyga> tomreyn: in the past nobody really read code
[11:51] <zyga> it's a myth
[11:51] <zyga> it was just nicely packed into one big label ($Distro)
[11:52] <zyga> I think that's not going to change much really
[11:52] <zyga> what is different is now this is explicit (you know who gives you software)
[11:52] <zyga> and you can get software from more authors than before (non-free software)
[11:53] <zyga> and you can have some guarantees about how that software operates (sandbox)
[11:53] <zyga> in reality there is no better model yet
[11:53] <ogra_> tomreyn, btw ... thanks to the snap store otifying me i just invested 2x 2min to update 4 snaps (2 server packages, one VPN tool and a desktop app) to get the latest libssl fixes in ... that would have eaten hours of my day if the packages were not snaps
[11:53] <ogra_> *notifying
[11:54] <tomreyn> yes, there are clearly benefits in centralization.
[11:54] <ogra_> also ... the miner is a totally valid thing ...
[11:55] <ogra_> the fact that the developer did not mention it in the description was not valid though
[11:56] <tomreyn> so a miner package which would say it is a miner and would just mine for a one hardcoded account would be fine?
[11:56] <ogra_> i dont see a reason why the package format should deny maintainers to get money for the work they do ... a miner is a possible way to do that ... just not without telling your users about it in advance
[11:56] <zyga> tomreyn: policy is not decided on IRC
[11:56] <zyga> it's a process and it is done on the forum
[11:57] <ogra_> tomreyn, sure, why wouldnt it ...
[11:57] <zyga> tomreyn: in the end one thing is clear, there's no place for deception in software
[11:57] <ogra_> tomreyn, its a very valid use-case to have an UbuntuCore image with a preinstalled miner snap to maintain your 10000 node miner farm with one-click
[11:57] <tomreyn> then you'll need to discuss whether tracking users, probably unknowingly and against their will, is deception.
[11:58] <ogra_> and in my personal opinion a miner is also a valid thing for a maintainer of opensource software to generate some income ... as long as the user knows in advance what she is getting herself into
[11:58] <tomreyn> anyways, i do not want to distract you off your work any loinger. thanks for the fruitful (i hope) discussion.
[11:59] <zyga> tomreyn: would you mind summarizing this conversation on the forum
[11:59] <zyga> irc is not preserved as much
[11:59] <ogra_> (beyond that fact that you can deny network access ofr a snap with one click or cmdline command)
[11:59] <zyga> I'm sure many people will find that useful
[11:59] <ogra_> yeah, that would be super nice
[12:00] <tomreyn> zyga: that'd be me contributing to improving snaps, but, at leats so far, i'm not yet convinced that i want to do so. sorry for disappointing...
[12:01] <zyga> too bad, maybe next time
[12:01] <tomreyn> (you did bring up a couple things which will make me reconsider a few of my POVs though)
[12:01] <tomreyn> thanks for that
[12:02] <zyga> my point about the forum is that then this conversation is not specifically about you getting some answers but the whole community getting information
[12:02] <zyga> about making sutff better for more than oneself
[12:03] <mup> PR snapd#5366 closed: snap: helper for validating snap instance names <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5366>
[12:03] <mup> PR snapd#5387 closed: snap{/snaptest}: set instance key based on snap name <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5387>
[12:03] <tomreyn> i will be happy to contribute to projects whose goals i share. ;-) you are welcome to reuse what i posted here and on the pastebin, both by paraphrasing or by quoting me.
[12:03] <mup> PR core18#42 closed: hooks: port 008-etc-writable.chroot from core16 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/42>
[12:09] <mup> PR snapd#5417 opened: image: block installation of parallel snap instances <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5417>
[12:16] <mup> PR snapd#5402 closed: i18n: handle write errors in xgettext-go <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5402>
[12:16] <mup> PR snapd#5418 opened: overlord/ifacestate: get/set connection state only via helpers <Core18> <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5418>
[12:17] <mvo> a second review for 5361 would be great
[12:18] <zyga> boo
[12:18] <zyga> mvo: I already did that one
[12:18] <mup> PR snapd#5390 closed: data: add systemd environment configuration <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5390>
[12:19] <Chipaca> mborzecki: "реасе" is a favourite of mine to check for invalid names
[12:19] <Chipaca> mborzecki: :-)
[12:19] <pedronis> mmh, 50 PRs
[12:20] <Chipaca> pedronis: working on it
[12:20]  * Chipaca seems nitpicky and slow today, but still
[12:20] <mborzecki> wow, 49, it was ~45 in the morning
[12:20] <zyga> mvo: 5411 is green
[12:20] <mvo> pedronis: my fault - but I have a lot of simple ones
[12:20] <zyga> it's -377 and some comment changes that made it to +10
[12:23] <pedronis> ovelord tests have become 30s long mmh
[12:23] <pstolowski|lunch> pedronis: managers_test is responsible for that
[12:23] <pedronis> need to dig a bit, seems a bit bad
[12:24] <pstolowski|lunch> pedronis: (and i might have added to that with the retry-conflicts tests)
[12:25] <cachio> zyga, hey, when you have a time, could you please take a look to #5343
[12:25] <mup> PR #5343: tests: adding extra check to validate journalctl is showing current test data <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5343>
[12:27] <zyga> sure
[12:32] <zyga> cachio: merged
[12:32] <cachio> thanks
[12:32] <zyga> I left one comment though
[12:32] <zyga> maybe you can squeeze that into some other PR
[12:32] <mup> PR snapd#5343 closed: tests: adding extra check to validate journalctl is showing current test data <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5343>
[12:35] <zyga> mborzecki: review on 5415
[12:38] <zyga> er
[12:38] <zyga> that was pstolowski|lunch sorry :)
[12:38] <zyga> I'm reading your 5417 so I thought about you
[12:43] <zyga> mvo: funny, same review points :)
[12:43] <zyga> on 5415
[12:43] <mvo> zyga: haha
[12:43] <zyga> er
[12:43] <zyga> 17
[12:44] <mvo> pstolowski|lunch: 5415 looks like an easy one, just one suggeston from zyga missing afaict
[12:49] <mup> PR snapd#5419 opened: [WIP] many: switch to account validation: unproven|verified <Created by pedronis> <https://github.com/snapcore/snapd/pull/5419>
[12:50] <zyga> mborzecki: can you look at my comment on 5413
[12:52] <mborzecki> zyga: hmm that's a bit unexpected
[12:59] <mvo> zyga: I have a conflicting meeting today
[12:59] <zyga> ack
[13:00] <niemeyer> mvo, zyga, mborzecki: I won't attend the standup today.. have a conflict over it
[13:00] <niemeyer> (in principle)
[13:01] <zyga> ack
[13:02]  * zyga tries to join
[13:03] <pstolowski> pedronis: standup or other meeting?
[13:03] <pedronis> conflict
[13:10] <zyga> thank you
[13:50] <pstolowski> zyga, mborzecki arch-linux-64:tests/main/interfaces-content failure https://api.travis-ci.org/v3/job/397340654/log.txt ; is this the same issue you mentioned earlier this week?
[13:57] <mvo> zyga: did you see my earlier (last night?) paste of the test failure of the layout test on core18?
[13:58] <mvo> zyga: it is reproducible, it happend on my latest test run as well
[14:13] <abeato> niemeyer, hi, https://github.com/snapcore/snapd/pull/5309 needs another (hopefully final) round
[14:13] <mup> PR #5309: overlord/configstate: add watchdog options <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5309>
[14:14] <niemeyer> abeato: Heya, looking
[14:15] <abeato> great, thx
[14:17] <zyga> mvo: I did, thank you
[14:17] <zyga> mvo: how can I reproduce that, which branch to start with?
[14:19] <mvo> zyga: please get https://github.com/mvo5/snappy/tree/core18-all-fixes-all-tests and then run "spread -v -debug ubuntu-core-18-64:tests/main/layout
[14:20] <zyga> pstolowski: hmm, what's the failure there?
[14:20] <zyga> thanks!
[14:20] <zyga> pstolowski: I only see the snapd-notify error
[14:26] <zyga> mvo: running now
[14:29] <mup> PR snapd#5420 opened: snap-mgmt: fix for non-existent dbus system policy dir, shellchecks <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5420>
[14:29] <zyga> pstolowski: those sysfs rules are interesting
[14:29] <zyga> I was not aware about some of them
[14:34] <pstolowski> zyga: i restarted the job shortly after; here is the error https://pastebin.ubuntu.com/p/RMyqtdzVzq/
[14:35] <pstolowski> zyga: what sysfs rules?
[14:35] <mborzecki> zyga: #5420 addresses snap-mgmt thing
[14:35] <mup> PR #5420: snap-mgmt: fix for non-existent dbus system policy dir, shellchecks <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5420>
[14:36] <mborzecki> also pushed some fixes for blocking parallel instances when preparing an image PR
[14:38] <zyga> mvo: reproduced (with my extra branch, investigating)
[14:38] <kyrofa> sergiusens, slack isn't connecting today, it seems. Are you able to?
[14:38] <kyrofa> Until it starts working, I'm here if needed
[14:39] <zyga> mvo: so
[14:39] <zyga> mvo: I got this error
[14:39] <zyga> https://www.irccloud.com/pastebin/taNSqyBH/
[14:39] <zyga> this may not be the same error you got yourself
[14:39] <zyga> it is also a bug in the test
[14:40] <zyga> the test encodes assumptions about the base snap
[14:40] <zyga> mvo: my suggestion is to change the test
[14:41]  * cachio afk
[14:42] <zyga> mvo: I will send you a patch shortly
[14:43] <mvo> zyga: cool
[14:44]  * zyga has flaky network with 27K photos being backed up today /o\
[14:44] <mvo> zyga: not sure about the error
[14:44] <zyga> mvo: the error I got may be different because I merged one of my layout fixes here
[14:45] <zyga> mvo: this uncovered the assumption about base snap that just don't hold
[14:52] <kyrofa> Oh, looks like slack is just down in general
[14:53] <mvo> zyga: aha, ok
[14:53] <mvo> zyga: I was looking at a different failure
[14:53] <zyga> mvo: the failure you got is fixed by my PR
[14:53] <zyga> mvo: so that's expected
[14:53] <zyga> I just wanted to see if this is correct after
[14:54] <zyga> vanilla master trips over the bug that this one fixes
[14:54] <pedronis> pstolowski: we get  5+5 s just from the retries indeed
[15:01] <pstolowski> pedronis: that's bad.. perhaps instead of settle we could wait the exact number of ensures
[15:01] <zyga> mvo: hmm, interesting, this is slightly deeper than that
[15:02] <zyga> mvo: the test is expected to run against the core snap
[15:02] <zyga> mvo: but because this is a core system it dones't run against the core snap, it runs again core18 because on all-snap systems we don't pivot
[15:02] <zyga> mvo: which I think is a deeper bug
[15:03] <zyga> mvo: this means that on core18 sytems _all_ snaps run against core18, not core!
[15:03] <zyga> which is a critical bug
[15:04] <zyga> mvo: I switched networks, are you reading this, not sure if irc works now
[15:04] <pedronis> pstolowski: not sure, anyway it's an area to touch again, at least I see where the time comes from now
[15:04] <mvo> xnox: hey, I filed bug 1778936 about the need to get a patch from xenial systemd back. I also added a debdiff, anything else I should do to ensure this is part of the next sru?
[15:04] <mvo> zyga: uh, that sounds nasty
[15:04] <mup> Bug #1778936: please re-add Support-system-image-read-only-etc.patch <systemd (Ubuntu):New> <systemd (Ubuntu Bionic):New> <https://launchpad.net/bugs/1778936>
[15:05] <zyga> mvo: let me look at that now
[15:05] <mvo> zyga: I think you are right, I just did "snap run --shell test-snapd-tools.echo" and a cat /etc/os-release and its core18
[15:06] <mup> PR snapd#5418 closed: overlord/ifacestate: get/set connection state only via helpers <Core18> <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5418>
[15:08] <xnox> mvo, there is a systemd in-flight in the unapproved.
[15:08] <xnox> mvo, is this a regression since xenial?
[15:08] <xnox> mvo, =/ i hope i didn't drop anything else on the floor
[15:09] <mvo> xnox: its a regression, to be fair we had hoped to get to a clean /etc by core18 but it did not work out ./
[15:09] <xnox> mvo, horum
[15:09] <mvo> xnox: I have not noticed any other regression
[15:09] <xnox> i shall dig into the history of that then quickly
[15:09] <mvo> xnox: fortunately the patch still applies almost cleanly
[15:09] <mvo> xnox: it looks like it got dropped when yakkety opened
[15:09] <mvo> xnox: there is no changelog entry, but with 230-1 it was dropped
[15:10] <xnox> mvo, ah, which is before i started systemd maintainance. i guess pitti thought it will be all fixed and dropped it post-xenial.
[15:10] <xnox> mvo, at one point systemd was in-sync in debian and ubuntu
[15:11] <mvo> xnox: https://launchpad.net/ubuntu/+source/systemd/230-1 is what I was looking at  (diffhttp://launchpadlibrarian.net/261334051/systemd_229-6ubuntu1_230-1.diff.gz )
[15:11] <xnox> nice
[15:11] <mvo> xnox: I think he just hated it ;) but thats ok, its really not great that we haven't gotten to the clean etc
[15:11] <xnox> mvo, do we need to talk about that in brussels?
[15:12] <mvo> xnox: we need this before brussels
[15:12] <mvo> xnox: oh, clean etc
[15:12] <xnox> mvo, cause i think we never got around to finalising what needs to be in-distro / on-core to get this done.
[15:12] <mvo> xnox: yes please
[15:12] <xnox> mvo, yeah clean etc.
[15:12] <mvo> xnox: +100
[15:12] <mvo> xnox: I think it must be a combined effort of foundations,core,debian but I think the important thing is to start :)
[15:13] <mvo> xnox: anyway, it won't happen for core18 so we have a bit of time but I will be really sad if we don't have it for core20
[15:17] <xnox> ack
[15:17] <mvo> xnox: ta
[15:18] <mvo> zyga: https://github.com/snapcore/snapd/compare/master...mvo5:core18-use-core?expand=1 <- an integration test for the bug you just found
[15:18] <kyrofa> sergiusens, snapcraft#2172 is all green
[15:18] <mup> PR snapcraft#2172: many: add shellcheck to static tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2172>
[15:18] <mvo> zyga: iirc we do something special on core, did you start looking into it?
[15:18] <zyga> mvo: yes, I did
[15:19] <zyga> thanks for the test, it's really simple
[15:19] <zyga> I mean
[15:19] <zyga> the bug
[15:19] <zyga> we just need to talk about it
[15:19] <mvo> zyga: tell me more :)
[15:19] <zyga> we have two options
[15:19] <zyga> option number one is this: detect core18 and treat it as classic (pivot root, etc)
[15:19] <zyga> a bit hairy but keeps the core status quo
[15:20] <zyga> option number two: drop all special casing, always pivot
[15:20] <zyga> I prefer two but it may affect core in some way
[15:20] <zyga> right now on core we don't do pretty much anything
[15:20] <zyga> we unshare the mount namespace
[15:20] <zyga> bind mount tmp and private /dev/pts
[15:20] <zyga> and that's that
[15:20] <zyga> so all production hacks are visible at runtime
[15:21] <zyga> and all the real / is there
[15:21] <zyga> we talked about this sometime in the past
[15:21] <zyga> when you first added bases to snap-confine
[15:21] <mvo> zyga: yeah, I think option (2) is better but more risky
[15:21] <zyga> I said then that we should unify core and classic to behave like classic (for the purpose of mount ns)
[15:21] <zyga> but chose not to do this then because we wanted to avoid the risk :)
[15:21] <zyga> and impact on core itself
[15:22] <zyga> I think we should do that again
[15:22] <zyga> but try to fix it at the same time
[15:22] <zyga> my memory is rusty but I think there's a real issue there
[15:22] <zyga> that unification doesn't work for a real reason
[15:22] <zyga> but I forgot that reason
[15:22] <zyga> I will do a patch that detects booted base != "core" and uses classic semantics
[15:22] <zyga> because this is a new slate
[15:22] <zyga> so new issues rather than regressions
[15:23] <mvo> zyga: +1
[15:23] <zyga> and because this eventually puts us on a path where core is deprecated and core16 can be the special case (if we end up needing it)
[15:23] <zyga> ok, I'll get to it now
[15:23] <mvo> zyga: \o/
[15:43] <sergiusens> kyrofa: no, slack no work, me fitter, happier, more productive, comfortable
[15:47] <zyga> mvo: core16 and core will use the same os-releaes file, right?
[15:49] <mvo> zyga: yes
[15:49] <mvo> zyga: well, we could decide but that was the plan
[15:50] <zyga> I think it must
[15:50] <zyga> I was just checking and thinking aloud :)
[15:50] <kyrofa> Hahaha
[15:50] <kyrofa> sergiusens, amen
[15:52] <pedronis> they need to be ideally identical in bits that snaps can see, or through snap-confine bind mounting stuff (from snapd for example)
[15:55] <mvo> zyga: yeah, I think pedronis is right, we may need some other way to distinguish
[15:55] <zyga> pedronis: I agree, it is just that now on core we don't pivot so today on core (bare "core" as boot snap) you see _everything_ that exists on the system, in general, not just what is in the core snap itself.
[15:56] <zyga> so on a system that moved to core16 we can attempt to keep that
[15:56] <zyga> but on a core18 system that runs a snap using core16 or core as base we cannot just get that for free, we need to hack things to behave this way
[15:56] <zyga> some things about product hacks may leak but I don't know if that matters
[15:57] <zyga> (as in on a real core system you may see stuff that you won't see on core18 with apps running against core16)
[15:57] <mvo> zyga: lets start with the simple case and just remove the special handling on core18, i.e. on core18 it always behaves like on classic, we always construct the mount namespaces from the snaps
[15:57] <mvo> zyga: i.e. on anything not old-core
[15:57] <zyga> mvo: yes, I agree
[15:58] <zyga> that's what I'm doing now
[15:58] <mvo> zyga: \o/
[16:10] <pstolowski> yay, my go-udev patch merged upstream
[16:20] <zyga> nice :)
[16:34] <mvo> pstolowski|afk: yay
[16:50] <mup> PR snapcraft#2171 closed: {catkin,python} plugin: support cleaning <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2171>
[17:07] <mup> PR snapd#5421 opened: tests: replace MATCH by grep to check users created for ubuntu core <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5421>
[17:14] <sergiusens> kyrofa: 2167 is a little larget than I thought it would be :-P
[17:28] <kyrofa> sergiusens, ignoring the tests?
[17:55] <kyrofa> sergiusens, snapcraft#2172 should be all good now
[17:55] <mup> PR snapcraft#2172: many: add shellcheck to static tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2172>
[18:00] <mup> PR snapd#5422 opened: devicestate: fix race when refreshing a snap with snapd-control <Created by mvo5> <https://github.com/snapcore/snapd/pull/5422>
[18:55] <kyrofa> Hey zyga, I'm having trouble running snaps in lxc on my desktop: cannot remount /tmp/snap.rootfs_nMP7A9/var/lib/snapd/lib/vulkan as read-only: Permission denied
[18:55] <kyrofa> zyga, any ideas?
[18:55] <zyga> oh, feels like a bug
[18:56] <zyga> dmesg | grep DENIED
[18:56] <kyrofa> Run that on the host or the guest?
[18:56] <zyga> either, it is lxc
[19:17] <kyrofa> zyga, [61955.378584] audit: type=1400 audit(1530126985.909:482): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-brave-drum_</var/snap/lxd/common/lxd>" name="/tmp/snap.rootfs_o6dcBz/var/lib/snapd/lib/vulkan/" pid=12945 comm="snap-confine" flags="ro, remount"
[19:22] <kyrofa> zyga, this is a vanilla, confined container
[19:22] <zyga> one sec
[19:23] <zyga> hum
[19:23] <zyga> is this a privileged container?
[19:24] <zyga> this looks like a bug in lxd to me, why is it running snap-confine under its own profile?
[19:24] <zyga> hmm
[19:25] <zyga> stgraber: ^
[19:25] <kyrofa> No, it's unprivileged. Just `lxc launch ubuntu:xenial -e`
[19:27] <stgraber> kyrofa: what snap?
[19:27] <kyrofa> stgraber, any, but that particular test was cla-check
[19:27] <kyrofa> stgraber, happens when running any app
[19:28] <kyrofa> stgraber, running on bionic, lxd 3.1 via snap
[19:29] <stgraber> hmm, can't reproduce this here
[19:29] <stgraber> running a xenial container on current lxd on bionic, then install hello-world or cla-check inside the container, both work fine
[19:30] <kyrofa> Could it have something to do with my nvidia card?
[19:30] <stgraber> getting a clean 18.04 install on a maas node now to see if that behaves differently
[19:30] <stgraber> kyrofa: could be, yeah
[19:31] <zyga> nvidia? how?
[19:31] <stgraber> root@c2:~# hello-world
[19:31] <stgraber> cannot remount /tmp/snap.rootfs_uuibb2/var/lib/snapd/lib/vulkan as read-only: Permission denied
[19:31] <stgraber> on a system with an nvidia gpu
[19:31] <kyrofa> Ah!
[19:32] <kyrofa> zyga, just saw the word "vulkan" and took a leap
[19:32] <zyga> yes, that part is related
[19:33] <kyrofa> That's all I got :P
[19:33] <zyga> but the question is, why did snap-confine not get an apparmor profile
[19:33] <zyga> can you do this from inside the container
[19:33] <zyga> sudo aa-status
[19:33] <stgraber> kyrofa: anyway, a workaround you can probably use for now is "lxc config set NAME security.nesting true" which will unrestrict some mount operations
[19:34] <zyga> stgraber: what does that do?
[19:34] <kyrofa> zyga, sure thing: https://paste.ubuntu.com/p/55BMdHBfxy/
[19:35] <stgraber> zyga: pretty much allows all mounts everywhere in the container which likely includes remounts.
[19:35] <zyga> this looks fine
[19:35] <kyrofa> stgraber, indeed, that seems to let the mount through and the app works
[19:35] <stgraber> zyga: I suspect the denial is correct in that it's the underlying LXD apparmor profile which refuses the mount, not the snap-confine profile that's loaded on top
[19:35] <zyga> stgraber: I see
[19:35] <zyga> so the outer profile needs to allow this as well
[19:40] <zyga> re
[19:40] <zyga> I just had a silly incident with one of the random dev boards I had around started serving everyone new IP addresses faster than my router :P
[19:42] <chiluk> something broke snappy gnome-calculator http://paste.ubuntu.com/p/dFJjCxpXpT/
[19:42] <chiluk> how is this even possible?
[19:42] <kyrofa> zyga, stgraber, so how does having an nvidia card result in a mount that is denied, while none of the other mount magic is denied?
[19:42] <stgraber> kyrofa: probably because only that triggers some snapd hook for vulkan/gl stuff which apparently bind-mounts stuff and then does a remount,ro
[19:42] <zyga> kyrofa: when you have nvidia we do more things
[19:42] <stgraber> the remount,ro part is what apparmor denies
[19:43] <kyrofa> Ah, so the bind mount is okay, it's the remount that's problematic
[19:43] <stgraber> yep
[19:43] <zyga> chiluk: are the two snaps connected?
[19:43] <chiluk> nope ...
[19:44] <chiluk> but I haven't screwed with any of the snaps.
[19:44] <stgraber> it's safe for us to allow bind-mounts in general, remounts are more risky
[19:44] <kyrofa> So what is the fix for this?  I could connect the two.
[19:44] <zyga> chiluk: can you share "snap changes"
[19:44] <zyga> kyrofa: the fix must happen in lxd
[19:45] <chiluk> http://paste.ubuntu.com/p/rJX6bPYjBV/
[19:45] <chiluk> zyga... I ran snap refresh today in hopes that there was an updated snap..
[19:45] <kyrofa> zyga, what is the fix? Just allowing remounts. even though they're risky? Or something more specific?
[19:45] <zyga> chiluk: and snap interfaces | grep gnome-calculator
[19:46] <zyga> kyrofa: well, to allow this specific operation
[19:46] <chiluk> zyga http://paste.ubuntu.com/p/gNWj9FDH5g/
[19:46] <zyga> chiluk: it seems to be connected here
[19:46] <zyga> gnome-3-26-1604:gnome-3-26-1604            gnome-calculator,gnome-characters,gnome-logs,gnome-system-monitor
[19:46] <kyrofa> stgraber, can lxd allow snap-confine specifically to remount?
[19:47] <stgraber> kyrofa: nope
[19:47] <chiluk> zyga.. I believe you... and it's connected on my desktop as well, but the question still remains how did they get unconnected?
[19:47] <stgraber> kyrofa: apparmor doesn't let you do per-process and even if it did, there'd be nothing preventing root in the container from calling a random binary snap-confine
[19:47] <zyga> stgraber: what I don't undertand is how the host of other mounts/remounts we do is ok
[19:47] <chiluk> I haven't explicitly been doing any snappy things..
[19:47] <zyga> and this is not?
[19:47] <zyga> chiluk: can you run: sudo nsenter -m/run/snapd/ns/gnome-calculator.mnt
[19:47] <zyga> chiluk: and then: cat /proc/self/mountinfo
[19:48] <stgraber> zyga: I suspect the rest of the things you're doing is just bind-mounts or standard mounts
[19:48] <zyga> pastebin the result and exit that shell to go back
[19:48] <zyga> stgraber: interesting, let me check
[19:48] <stgraber> zyga: I don't see any case where our profile would allow for remounts
[19:49] <zyga> yes, that's the only place that we remount
[19:49] <stgraber> I have a change here which allows specifically remount,ro and nothing else, but I'm not sure that this is actually safe, at least I very much doubt that it is for privileged containers
[19:49] <chiluk> zyga http://paste.ubuntu.com/p/NjGJMYwkTx/
[19:49] <zyga> stgraber: is this done at apparmor level, why is remounting something read-only not allowed
[19:50] <stgraber> zyga: because remount is a fs operation, not a mount operation, so if you pass a bind-mount from the host and do remount,ro, now the path on the host is read-only too
[19:50] <stgraber> zyga: which was a pretty simple DoS attack for privileged containers against their host
[19:50] <zyga> stgraber: you can pass MS_BIND| MS_REMOUNT to specifically make the bind mount read only, no?
[19:50] <zyga> and we don't do that!
[19:51] <stgraber> right, you don't do that :)
[19:51] <zyga> chiluk: can you finally paste /run/snapd/ns/snap.gnome-calculator.fstab
[19:51] <zyga> chiluk: this should be enough
[19:51] <zyga> stgraber: thanks, I will correct this shortly
[19:51] <zyga> kyrofa: thank you!
[19:51] <kyrofa> zyga, stgraber, thank you both!
[19:52] <chiluk> zyga http://paste.ubuntu.com/p/JwbbwbFfcV/
[19:52] <zyga> kyrofa: can you please drop a topic on the forum with basic info "lxd + nvidia = sad snappy"
[19:52] <zyga> I will do the rest
[19:52] <kyrofa> zyga, of course
[19:52] <stgraber> kyrofa: make sure to mention the security.nesting workaround, that's not great but it works
[19:53] <zyga> chiluk: can you do "snap list" and share the revision of gnome-calculator and the gnome platform snap
[19:53] <chiluk> zyga see first pastebin
[19:53] <zyga> ok, sorry, looking
[19:55] <zyga> hmm
[19:55] <chiluk> zyga... It still could be something I did, but that seems unlikely... I feel like other users will probably eventually hit this.
[19:55] <zyga> let me read the mount table
[19:56] <zyga> this is what snapd claims it did: /snap/gnome-3-26-1604/64 /snap/gnome-calculator/178/gnome-platform none bind,ro 0 0
[19:56] <zyga> I'm checking if that's true
[19:56] <zyga> curiously it doesn't seem to be true
[19:57] <zyga> did this happen just now?
[19:57] <chiluk> it's been happening for a few days.. I'm pretty sure it persists over restart.
[19:57] <chiluk> I guess I could check...
[19:57] <zyga> can you disconnect and re-connect that interface to see if this fixes it
[19:58] <zyga> sadly we don't log much when that part fails
[19:58] <chiluk> you mean run snap connect?
[19:58] <zyga> yes, please disconnect and re-connect gnome-calculator:gnome-3-26-1604
[20:00] <chiluk> snap connect gnome-calculator:gnome-3-26-1604
[20:00] <chiluk> error: snap "core" has no "content" interface slots
[20:00] <zyga> I think you need to spell both sides of the connection this time
[20:00] <zyga> sorry
[20:00] <zyga> it should tab-complete though
[20:00] <chiluk> snap connect gnome-calculator:gnome-3-26-1604 gnome-3-26-1604
[20:01] <chiluk> ^^ made it work.
[20:01] <chiluk> as I expected.
[20:01] <chiluk> but I don't care about fixing this for me.
[20:01] <chiluk> I'm a little confused as to why it broke in the first place.
[20:01] <chiluk> because I can't be the only one.
[20:01] <zyga> can you jump into the mount ns
[20:02] <zyga> and collect mountinfo again please
[20:02] <zyga> same as last time (same commands)
[20:02] <zyga> I would like to diff the two
[20:02] <chiluk> http://paste.ubuntu.com/p/3yZmBfBB5C/
[20:02] <zyga> thank you
[20:03] <stgraber> zyga, kyrofa: https://github.com/lxc/lxd/pull/4704
[20:03] <mup> PR lxc/lxd#4704: lxd/apparmor: Allow ro bind-mounts and remounts <Created by stgraber> <https://github.com/lxc/lxd/pull/4704>
[20:03] <kyrofa> zyga, chiluk, just throwing this out there, but gnome-software has the ability to twiddle those as well, no?
[20:03] <zyga> sure enough :/
[20:03] <zyga> https://www.irccloud.com/pastebin/TevxFMh7/
[20:04] <stgraber> this allows the read-only bind-mounts which you should be using for both priv and unpriv + allows ro remounts for unpriv
[20:04] <zyga> kyrofa: yes but we _claim_ this is connected, we _claim_ it is mounted (snapd) and it's not
[20:04] <zyga> so clearly something was broken
[20:04] <chiluk> right...
[20:04] <kyrofa> Ah interesting
[20:04] <chiluk> how'd it get that way though?
[20:05] <zyga> stgraber: I will fix this in snap-confine, I think it's clearly our mistake because lack of MS_BIND is confusing from an API POV
[20:05] <zyga> chiluk: that's the question
[20:05] <zyga> chiluk: if you can reproduce this please tell me, I'd love to know what happened
[20:05] <zyga> chiluk: do you have any denials in recent history
[20:05] <chiluk> yeah that's unlikely.
[20:05] <zyga> sadly, as I said, snapd doesn't log this
[20:06] <chiluk> zyga.. are you talking app armor?
[20:06] <kyrofa> stgraber, wait, I thought ro remounts were unsafe since they set the host dir ro as well?
[20:06] <zyga> chiluk: yes
[20:06] <zyga> kyrofa: it's subtle
[20:06] <zyga> kyrofa: we don't want to remount the filesystem
[20:06] <zyga> kyrofa: we want to remount the bind mounted view
[20:07] <chiluk> zyga syslog:Jun 27 15:00:44 groovy kernel: [233210.052692] audit: type=1400 audit(1530129644.316:573): apparmor="DENIED" operation="open" profile="snap.gnome-calculator.gnome-calculator" name="/home/dchiluk/Templates/" pid=20481 comm="head" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[20:07] <zyga> guys it's 22:06 and I have snap-confine patches all over my screen, I need to take the dog out, take a shower and not hack much more
[20:07] <zyga> chiluk: that's not related, so if that is the only denial you had I have no other ideas :/
[20:07] <kyrofa> zyga, I think I understand what you need to change on the snapd side, I just don't understand that lxd PR, since it covers filesystem remounts, no?
[20:07] <chiluk> zyga looking
[20:08] <zyga> kyrofa: I think the lxd PR is a separate topic now, I'm not sure it is strictly speaking mandatory or safe (as stgraber explained earlier)
[20:08] <zyga> if fixing snap-confine is sufficient to address this we should know soon (it will be in edge in about a day)
[20:08] <zyga> but first
[20:08] <zyga> dog/shower/sleep
[20:09] <stgraber> kyrofa: note that I only allow those for unpriv containers where the kernel will not let them propagate to the host
[20:09] <zyga> ah
[20:09] <zyga> that's nice, I didn't know the kernel does that
[20:09] <zyga> how does it decide?
[20:11] <stgraber> by looking at the kuid tied to the original mount
[20:11] <stgraber> if that doesn't match your kuid then you get EPERM
[20:12] <stgraber> obviously that doesn't work for privileged containers as those run as real root and so you totally do have the right to go and mess with the host mount table
[20:13] <chiluk> zyga nothing more about calculator or snap that seems relevant in the logs.
[20:15] <kyrofa> stgraber, ah, interesting, okay
[20:15] <chiluk> zyga nothing more about calculator or snap that seems relevant in the logs.
[20:15] <kyrofa> stgraber, thank you for putting that together!
[20:17] <chiluk> zyga if it's any consolation it looks like this machine was installed with 18.04 pre-release *(probably around beta stage)... maybe that's it.
[20:24] <zyga> No chiluk, this happened since your last reboot
[20:24] <zyga> This is purely volatile state
[20:29] <sergiusens> kyrofa: we need to stop moving back and forth with our comm platform :-P But yeah, the code sans tests is quite large; I am not doing a light review and my state of mind right now also complicates things
[20:34] <kyrofa> sergiusens, haha, I sent that ages ago! Slack is back up, we can talk there if you like
[20:34] <kyrofa> Take your time on the review
[20:36] <sergiusens> well, I would rather discuss here, until I have the urge to paste something :-P
[20:36] <sergiusens> kyrofa: I setup matrix during the weekend and added elopio as I knew he was on, he told me you are his only other friend there :-P
[20:36] <kyrofa> Works for me!
[20:36] <kyrofa> Hahahahahaha
[20:40] <sergiusens> kyrofa: if you dismiss my review I lose the ability to approve from the same pane :-P
[20:41] <kyrofa> Oh I didn't actually realize that was a possibility in the first place. How fancy!
[20:45] <kyrofa> Looking forward to that one landing. Not sure how some of this has been working
[21:32] <mup> PR snapcraft#2172 closed: many: add shellcheck to static tests <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2172>
[21:34] <sergiusens> kyrofa: ok, so first pass on #2167 is done
[21:34] <mup> PR #2167: snapstate, devicestate: do not remove seed <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2167>
[21:37] <sergiusens> kyrofa: what do you think of making the <topic>: in the merge more functional instead of locational? Else you get "many:" for most things and it loses importance.
[22:05] <kyrofa> sergiusens, yeah I think most of the time they're the same, sans many :P
[22:05] <kyrofa> I'm good with that, I'll avoid many
[23:15] <kyrofa> sergiusens, updated snapcraft#2167
[23:15] <mup> PR snapcraft#2167: many: detect local source changes <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2167>


[00:20] <crimsun> does anyone actively use LLVM? (http://llvm.org)
[00:20] <crimsun> I need it for work, so I'm going to be updating to 2.1 and pushing to Debian
[00:20] <RAOF> What do you mean by actuvily?
[00:21] <crimsun> RAOF: meaning "I need this software updated, or my life at work will be miserable" :)
[00:21] <RAOF> Hah, no.
[00:21] <RAOF> Although I'm interested in it for two reasons: pypy & gallium.
[00:21] <crimsun> understandably so
[00:22] <crimsun> I'll be going with the gcc4.0 portion instead of gcc4.2, but I'm happy to coordinate packaging both if people seem to want both (?)
[00:22] <RAOF> I think I may want to start adding the nouveau 3d stuff to my ppa soonish, so a version that works with the gallium stuff would be good :).
[00:25] <pwnguin> RAOF: is the exa stuff making progress upstream?
[00:25] <RAOF> pwnguin: For nouveau?
[00:25] <pwnguin> yes
[00:26] <RAOF> From what I gather, it pretty much works on everything != nv30 atm.
[00:26] <RAOF> And by "works" I mean, "is fast on Xservers >= 1.4"
[00:26] <pwnguin> and for nv30?
[00:27] <RAOF> I'm not sure.  It was broken at some point because they didn't do the T&L init properly (and EXA is using the 3d engine).
[00:27] <pwnguin> last i knew, they wanted to hold off on xrandr improvements until exa was better
[00:27] <RAOF> I don't know if that's fixed yet.
[00:28] <ajmitch> exa is definitely getting better
[00:28] <RAOF> Ah.  EXA may well be in a state that's amenable to accelerating xrandr now.
[00:28] <ajmitch> that's mostly what they've been working on lately, it seems
[00:28] <ajmitch> of course there's been some experiments with gallium & ttm stuff
[00:28] <RAOF> For values of "they" in {Xorg, nouveau}, it seems.
[00:30] <RAOF> It looks like nouveau may be approaching the point where people start to really work on gallium stuff
[00:38] <ajmitch> & hopefully some ttm stuff soon in a branch, for texturing support :)
[00:41] <davebags> hey guys
[00:59] <_16aR_> Hello
[00:59] <_16aR_> Anyone has tried apturl on PPAs ?
[01:26] <bmk789> is ubuntu planning a port to PS3?
[01:26] <Fujitsu> bmk789: There are Gutsy ISOs.
[01:26] <bmk789> really?
[01:27] <Fujitsu> Yes.
[01:27] <Nafallo> I think there where feisty isos as well, no?
[01:27] <Fujitsu> http://cdimage.ubuntu.com/ports/releases/7.10/release/
[01:27] <Fujitsu> Nafallo: Quite possibly.
[01:28] <bmk789> Fujitsu: thanks
[01:40] <joejaxx> not the netsplits again :(
[01:43]  * somerville32 dances.
[01:44]  * somerville32 sings "It is raining servers!"
[01:44] <Fujitsu> bigon: That is broken versioning in -proposed.
[01:45] <Fujitsu> How annoying.
[01:45] <bigon> Fujitsu: yea I realised that :/
[01:48]  * Fujitsu people would conform to the SRU procedures and versioning.
[01:48] <Fujitsu> +wishes
[01:52] <persia> Fujitsu: For the latter, it may help to provide explicit guidance on versioning in the procedural documentation.  For the latter, it is perhaps more difficult.
[01:54] <Fujitsu> -0ubuntu1 is clearly wrong.
[01:55] <Fujitsu> It fails part 2.3, and common sense.
[01:56] <persia> Fujitsu: I agree it fails common sense, but I could construct a case for a hypothetical package in which it would meet 2.3.
[01:56] <persia> (although I would doubt a new upstream was ever a good SRU candidate anyway)
[01:56] <joejaxx> grr blasted lpia FTBS
[01:56] <Fujitsu> persia: We clearly want 2.20.1 in Hardy at some point, and the proper Hardy versioning would be -0ubuntu1.
[01:57] <Fujitsu> persia: GNOME 2.20.1 has a blanket exception.
[01:57] <Fujitsu> The first point release usually does.
[01:57] <bigon> packages are not checked by archive admin before being published in -proposed?
[01:58] <Fujitsu> bigon: I thought they were, but apparently not.
[01:58] <persia> Fujitsu: Ah.  Yes.  That's completely broken right now, although I suspect we are really targeted 2.22 for hardy, which means it won't matter later.
[01:58] <persia> bigon: Checked, but people are busy.
[01:58] <Fujitsu> That does, however, seem to be the standard for GNOME.
[01:58] <Fujitsu> But that is just plain wrong, wrong, wrong.
[01:59] <bigon> it was why I asked about migration,  this package should be directly migrated to hardy
[02:00] <persia> bigon: If it were before, yes.  Migrating now is trickier, as it requires manual adjustments on the servers, and the status is tracked badly.
[02:02] <Fujitsu> You might be able to convince an archive admin to do it (heck, seb128 is an archive admin and he uploaded some of the stuff with bogus versioning).
[02:04] <blueyed> Fujitsu: what would the correct version have been? 2.20.1-0ubuntu0.1?
[02:04] <persia> blueyed: That would have been preferable.
[02:05] <Fujitsu> blueyed: Yes.
[02:07] <Fujitsu> Also, I'm sure that SRUs are meant to be in the development release first, unless it isn't open yet.
[02:07] <Fujitsu> And those didn't look like particularly critical updates.
[02:08] <Fujitsu> But if archive admins don't follow procedure, I guess we can't expect others to.
[02:09] <persia> Fujitsu: No, it just means we need to complain to the archive admins, much as we'd complain to anyone else.
[02:24] <bigon> about SRU version what's better? 0.4.3-1ubuntu2.1 or 0.4.3-1ubuntu3~gutsy1 ?
[02:24] <persia> bigon: I like 0.4.3-1ubuntu2.1
[02:25] <persia> (both are policy-compliant)
[02:25] <Fujitsu> ~gutsy1 is for backports, not SRUs.
[02:25] <bigon> oh ok
[02:25] <Fujitsu> The normal SRU versioning is .1, or .7.10 (or appropriate release)
[02:26]  * persia agrees with Fujitsu, and notes that the documentation on this matter is notoriously poor
[02:26] <Fujitsu> I thought it was resolved a year ago that said documentation was to be improved, but apparently not.
[02:27] <persia> Fujitsu: Yes, it was resolved a year ago that said documentation was to be improved, but there was neither assignment nor volunteers.
[02:33] <ScottK> persia: I was responding to your earlier ping about overlap between our MOTU meeting topics.
[02:33] <ajmitch> hello Hobbsee
[02:34] <persia> ScottK: Ah.  Yes.  I'm very tempted to agree with you about new packages.  Would you be willing to rebut me on new versions in a first discussion, and then we'll hiit new packages in a second?
[02:34] <Hobbsee> hi ajmitch
[02:36] <Fujitsu> ScottK: What do you think about new packages?
[02:36] <Fujitsu> Morning Hobbsee.
[02:36] <Hobbsee> hiya Fujitsu
[02:37] <persia> Fujitsu: MOTU Meeting agenda may help create context in case ScottK still has 12-hour lag.
[02:38] <Fujitsu> persia: Thanks.
[02:38]  * ajmitch looks at agenda
[02:38] <ScottK> persia: I've got sending details on my proposal to the MOTU ML tonight or tomorrow.  I'll try and incorporate what you're propsing.
[02:38] <ScottK> As I understand it anyway.
[02:38] <ajmitch> ScottK: what's a 1-line summary of what you're proposing?
[02:39] <persia> ScottK: OK.  Just to clarify, I'd like to separate "new version" from "new package", and use REVU for "new package" and LP for "new revision".  I have other thoughts on how these should be reviewed, but they may be separate to that central dichotomy.
[02:39] <ScottK> ajmitch: Quit trying to status new package reviews in two places.  LP for needs packaging/assignement/fix released with a link to revu and revu comments in between
[02:40] <ScottK> persia: I'm going to have to disagree with you on that as I find REVU useful for new version too, but definitely agree that the diff of the Debian dir is quite needed.
[02:40]  * persia agrees with ScottK that the current state is broken and likely to create duplicate work or conflicting information to contributors
[02:40] <ajmitch> alright, I wasn't aware that people were using LP much for tracking the status
[02:40] <ScottK> ajmitch: Some are and some aren't and that's part of the problem.
[02:41] <ajmitch> I thought that the general practice was following what you are proposing
[02:41]  * Fujitsu thinks that an interdiff of the .diff.gz should be all that is needed for new upstream versions, soon.
[02:41] <persia> ScottK: Not just the debian dir: I want a full diff of everything in diff.gz.  Anyway, I'm happy to debate LP vs. REVU at the appropriate time, I just want to separate the concerns, as I think that new package issues are sufficiently different from new version issues to warrant separate discussions.
[02:41] <ScottK> ajmitch: It is what has been agreed at a MOTU meeting.  Some people (dholbach in particular) have pushed the current practice well beyond what the community has ever agreed to.
[02:42] <ScottK> persia: Fair enough.
[02:42] <persia> Fujitsu: Actually, I'd really like something better than interdiff, which gets annoying when the diff.gz files are in different orders, but basically, yes.
[02:42] <ajmitch> probably because he didn't want processes to stagnate, and was trying to find new ways of managing it
[02:43]  * ScottK find process churn to be a problem and would like to avoid semi-random process changes.
[02:43] <persia> ajmitch: I'd agree with that, and believe that the current state comes from the best of intentions, but it's likely time to review, and either choose a more modern method, or go back to the old way, rather than maintaining both processes.
[02:44] <ScottK> I think moving from the wiki to LP for needs-packaging was a good move.  It was the unagreed churn after that I find problematic.
[02:44]  * persia notes that the parallel processes have been maintained since late feisty
[02:45] <ScottK> And been problematic since then too.
[02:46] <persia> ScottK: did we have conflicts in feisty?  I thought that the parallel model worked fairly well when first testing the new process, it was only after it became normal without the old becoming deprecated that we hit a wall.
[02:46] <ScottK> persia: I've never liked the double book keeping approach and it was never agreed to.  It just happened.
[02:47] <ScottK> When I pinned dholbach down on this point at UDS he described it as a logical consuequence of the move to needs-packaging bugs and so no agreement to change the process was needed.
[02:49] <persia> ScottK: Ah.  I see your point there.  I still think there needs to be opportunity for experimentation with process alterations, to provide a basis of discussion, but I agree that regularisation of double-entry is not ideal: if the new process is better, we should use it.  If not, we should drop it.  If not there yet, we should adjust it.
[02:49] <ScottK> Right, but there continue to be process 'experiments' that get documented in the wiki in ways that make it not at all clear it's an experiment.
[02:50] <ScottK> New package reviews in bzr was one of those late Gutsy until I pushed back on that.
[02:50] <persia> ScottK: That's true, and a different problem.
[02:50] <ScottK> I agree with process experimentation if and only if it's clear what's experiment and what's not.
[02:51] <ScottK> So I don't think it's at all different.
[02:51] <ajmitch> agreed, I like having new processes if they'll make life easier
[02:51] <ajmitch> but confusing people with multiple ways to do things doesn't make it easier
[02:52] <ScottK> Yes.  Experimentation is fine, but a short experiment followed by mail to MOTU ML, and then a few days later, "No one objected so here's how we do it now..." is not fine.
[02:52] <ScottK> Confusing old people coming back is not good either.
[02:53] <ScottK> As siretart pointed out at UDS, we really need a process changelog people coming back can review.
[02:53] <persia> ScottK: I see several different issues: 1) The process shouldn't change without discussion, 2) experimental and test processes should be clearly marked as such, 3) experimental processes should be adopted wholly or stopped after the testing period: we should not support dual processes, 4) current processes should be documented somewhere for clear reference to all parties.
[02:54] <ScottK> I don't think anyone disagrees with these points as stated, the just aren't followed by some.
[02:54] <persia> I don't see how these are related, except that they are about processes.  Because all of these issues exist, things get awkward.  I think we've an hours worth for the 9th, but perhaps we could have a meta-process agenda item for the 23rd?
[02:54] <ajmitch> ScottK: ubuntu-devel-announce should be used for that, I think
[02:54] <ajmitch> it's not used often enough
[02:54]  * persia agrees with ajmitch about process changelog
[02:54] <ScottK> Sounds reasonable.
[02:54] <ScottK> persia: I'd like to nail down the specifics we have for the next meeting and not defer them, but sure.
[02:55] <persia> ScottK: Ah.  Yes.  it's precisely because I believe the new package / new upstream issue is more important than meta-process that I suggest meta-process be handled on the 23rd.  We need to fix the other now, as it's already annoying Contributors and slowing reviews.
[02:56] <ScottK> Agreed.
[02:57] <ScottK> persia: If we could add debian dir diff and .diff.gz diff to REVU would you consider that an appropriate place for new upstream versions?
[02:58] <persia> ScottK: Maybe.  I think debian dir diff is dangerous because someone might not check for other files in diff.gz.  I also think that once we've accepted a package, we need more agressive cryptographical checks to make sure we're shipping the right thing.  I'm still preparing the list for the 9th, so I'm not really prepared to debate that now.
[02:58] <Fujitsu> ScottK: New upstream versions are closer to normal sponsoring jobs - the process should be similar to them, not NEW packages.
[02:58] <persia> Fujitsu: That's the other point.
[02:59] <persia> Anyway: this is on the agenda for the meeting: let's wait until everyone is together to discuss specifics.
[02:59] <ScottK> Except you need to download the entire pacakge.
[02:59] <Fujitsu> When the vast majority of packages have sane watch files in the near future, it should be easier.
[02:59] <ScottK> OK.
[02:59] <Fujitsu> ScottK: Why?
[02:59] <persia> ScottK: If you don't do that anyway, you aren't checking the cryptography properly.
[02:59] <Fujitsu> Exactly.
[03:00] <ScottK> Yes, you need to download it, so LP doesn't give you a good place to do that from.
[03:00] <Fujitsu> If I sponsor an upstream version, I check the upstream site anyway, to see that it's the really the right tarball.
[03:00] <persia> ScottK: Right.  Downloading from LP would be even *more* broken.  You need to download from upstream.
[03:01] <ScottK> So the packager provides a diff.gz and a .dsc and you get the tarball yourself?
[03:02] <persia> ScottK: No, I just want the interdiff.  I can apply that to the current diff.gz to make a candidate diff.gz, download upstream with the watch file or get-orig-source, and make my own .dsc.
[03:02] <ScottK> I see.
[03:02] <Fujitsu> That means you are guaranteed to get a real upstream tarball, can more easily review the changes, and not upload a lot of big attachments to LP.
[03:03] <persia> Plus, it enforces that all Ubuntu-local new upstreams have get-orig-source or watch files so we can more easily maintain them in the future.
[03:03] <ajmitch> ScottK: of course the suggested way is often to rm the supplied tarball & grab upstream's
[03:04] <Fujitsu> persia: That too.
[03:04] <Fujitsu> And with the Debian mass-filing yesterday...
[03:04] <persia> Fujitsu: Now we just need to get "should" changed to "must" for get-orig-source, and everything is golden :)
[03:05] <Fujitsu> Yep.
[03:08] <bddebian> pfft ;-P
[03:08] <ScottK> persia: You mean must for repacked tarballs?
[03:09] <persia> ScottK: It's already "should" for all packages in Debian: I don't see why it shouldn't become "must".  Writing get-orig-source to call uscan is trivial.
[03:10] <ScottK> persia: Where is get-orig-source a should for non-repacked tarballs in Debian policy?
[03:10] <persia> ScottK: Of course, I don't expect that to happen for a couple years, and don't see the point of imposing it in Ubuntu early: at this point I'd like "must" for repacks, and "should" for thers.
[03:10]  * ScottK doesn't see the point if you have a watch file.
[03:11] <persia> interface standardisation, but I agree it's not very important.
[03:11] <Fujitsu> Are we all agreed that a debian/watch is a "must" for REVU?
[03:12] <persia> Fujitsu: That's also for discussion on the 9th, but I'm a fan
[03:12]  * ScottK agrees it's a good idea and someone should propose it at a MOTU meeting so we can agree to the process change.
[03:12] <Fujitsu> ScottK: It's there.
[03:12] <ScottK> Perfect
[03:13]  * ajmitch wonders if it should be made a lintian error on REVU
[03:13] <Fujitsu> ajmitch: That's a good idea.
[03:13] <persia> ScottK: You're correct.  I must have been looking at a draft or proposal.  Currently, 4.9 only says "This target is optional, but providing it if possible is a good idea."
[03:14] <ScottK> ajmitch: Sounds like a good idea.
[03:14] <bddebian> Watch files are NOT possible for every application.  I have like 50% of the packages on the games team that are virtually impossible to create watch files for
[03:14] <Fujitsu> bddebian: Why would such a high number be impossible?
[03:14] <persia> bddebian: Really?  Is this because upstream doesn't act sane, or is there something else happening?
[03:14] <ScottK> bddebian: OK.  Required unless proven not feasible.
[03:15] <bddebian> Either upstream is gone (can't find the tarballs at all) or the upstream naming is such that it cannot be done
[03:15] <ajmitch> persia: I doubt that many games have sane upstreams
[03:15]  * persia is worried about maintainability of Ubuntu-local packages without automated mechanisms to track new upstreams
[03:15] <ajmitch> bddebian: of course your packages would sneak in the back door via a debian sync :)
[03:16] <persia> bddebian: Ah.  Yes, I should have said "dead or insane".  Games are extra hard.  Happy Penguin should organise a general upstream repository.
[03:16] <persia> ajmitch: Doesn't help with the recent mass-bug filed.
[03:16] <chillywilly> hmmm, terminal fonts are all fubar after the dist-upgrade
[03:16] <ajmitch> persia: of course not
[03:16] <chillywilly> that's not cool :-/
[03:16] <Fujitsu> I believe said bug-filing will be a regular occurence, too :)
[03:17] <bddebian> persia: I think we should just lynch all the damn upstream devs.  It's crazy :)
[03:18] <persia> bddebian: Nah: lynching makes them not produce more games.    PATCHES seems to have a list of variation, against which one could compare things.  On the other hand, if you want to differentiate "updated" from "pending" merges, you'll either need access to the internals, or to maintain your own gutsy/hardy Sources.gz as a reference.
[04:13] <StevenK> And if nickserv will answer
[04:13] <Fujitsu> persia: What I really want is a list of packages that are deemed to be `local', as represented in the MoM stats.
[04:13] <Hobbsee> it will - slowly
[04:13] <Fujitsu> StevenK: I can imagine it might be a bit flooded.
[04:14] <persia> Fujitsu: Ah.  I believe that is just the list of packages that are present in local Sources.gz and not in sid Sources.gz, but I suspect there is a blacklist involved as well.
[04:15] <Fujitsu> persia: Right, it has about 70 fewer packages than mine. I'll see what happens if I also exclude the blacklist..
[04:20] <persia> Fujitsu: Ah.  I see now.  Where's the MoM blacklist?
[04:20] <slangasek> Fujitsu: so anyway, I have to disagree with your conclusion that "Debian" likes PHP.  There are some people peripherally involved in Debian who seem to like prototyping in PHP, and sadly qa.debian.org seems to be pretty heavy on PHP, but I believe that Debian developers as a whole (taking myself as a representative sample) have a healthy dislike for PHP. :)
[04:21] <Fujitsu> slangasek: Well, QA people like PHP. There we go.
[04:21] <Fujitsu> Oh dear.
[04:22] <persia> Err..  Rather Debian QA websites appear to be typically implemented in PHP.  They may hate it, but that doesn't force things.
[04:22] <Fujitsu> persia: If they hate it, why would they right their tools in it?
[04:22] <Fujitsu> *write, gah.
[04:23] <persia> Fujitsu: That may be the best of the environments available on servers that the authors don't control, where the administrators haven't deployed something else yet (although I'd expect most to be running etch by now: they  may not have been when the tools were developed)
[04:24] <persia> I could even believe that some of the tools were first deployed onto Woody servers, which makes PHP a less surprising choice
[04:24] <Fujitsu> I guess so.
[05:21] <ScottK> persia: I've been considering your new upstream sponsorship proposal.  I've a counter proposal.  First we need to agree and document a Best Current Practice for MOTUs reviewing and sponsoring new upstream versions.  From that I think how to submit them and what to submit will be obvious.
[05:21] <persia> ScottK: That sounds good.  Do you think we can do that in a meeting, or do you want to first collaborate on a proposal?
[05:22] <ScottK> I think the conversation on IRC was a good start.  I think document that and you're 90% there.
[05:22] <ScottK> If you can put that together, maybe we can agree in the meeting.
[05:23] <persia> ScottK: In that case, I'll outline things a bit more (as it's quiet), let you object, and propose it at the meeting.
[05:23] <persia> New Upstreams:
[05:23] <persia> Reviewer should be reviewing the work done by the packager: if good, the package should be prepared for upload to meet cryptographic requirements.
[05:24] <persia> This means that the reviewer needs to look at the difference in packaging (interdiff of diff.gz) to make sure the right things are being done, and then use the provided watch file or get-orig-source to prepare a candidate package.
[05:25] <persia> The candidate package should be reviewed to see if there are other bugs that can be usefully closed, or other adjustments deemed wise, these applied, and uploaded.
[05:25] <persia> New Packages:
[05:26] <persia> Reviewer should be reviewing both the work done by the packager and the applicability of the proposed package for Ubuntu.  The packaging should meet all automatic tests, follow documented policy, and provide a get-orig-source rule or watch file to ease future team maintenance of updated packages.
[05:27] <persia> The package should integrate well with an Ubuntu system, and not directly conflict with anything in main unless there is an associated spec for a future transition.
[05:27] <persia> Each candidate should be approved by two members of ubuntu-dev for correctness and suitability, after which it may be uploaded.
[05:28] <persia> ---
[05:28] <minghua> What does "directly conflict" mean there?
[05:28] <persia> Aside from that, it's just implementation details
[05:28] <ajmitch> persia: would you require approval by 2 ubuntu-dev members for all packages, or just those by non-MOTUs?
[05:28] <Fujitsu> I think that `should meet all automatic tests' should probably be clarified - I presume it means lintian/linda?
[05:28] <persia> minghua: Something like the Y Window system, unless there is a strong compellling reason.
[05:28] <Fujitsu> Yay!
[05:29]  * ajmitch kicks freenode
[05:29] <persia> ajmitch: I say 2, but if the packager is one, that only requires one more.  I'm not perfect, and I don't expect you to be.
[05:29] <minghua> persia: But what if X Window and Y Window can be installed in parallel?
[05:29] <persia> Fujitsu: Yes, it all needs a little more clarification, but that's the base of what I was thinking: perhaps also piuparts.
[05:30] <persia> minghua: They can't (or couldn't last I looked), but it they could, it wouldn't be a conflict.
[05:30] <minghua> persia: Basically I am asking if it's "conflict of interest" or "Conflict in dpkg-sense"
[05:30] <persia> minghua: Conflict in dpkg-sense
[05:30] <Fujitsu> I think those guidelines look pretty good.
[05:30] <minghua> Right.  (BTW I didn't know Y Window System is a real-world example...)
[05:31] <persia> minghua: It's a local-frame-buffer windowing system for posix compliant systems, but it's not call-compatible to X.
[05:31] <persia> (and I think upstream is losing interest, or has already done so, due to newer, faster, X)
[05:31]  * ajmitch isn't entirely happy with requiring 2 ACKs for everything yet again - it will get ignored quite often
[05:32] <persia> ajmitch: We require 2 ACKs now: that won't be a change.
[05:32] <minghua> persia: Thanks.  Don't let me sidetrack you though. :-)
[05:32] <ajmitch> persia: we did change it so that MOTUs weren't *required* to get the additional review, I believe
[05:32] <ajmitch> though it was still encouraged
[05:32] <persia> ajmitch: Given that I've never advocated another MOTUs package on first review, I don't find that encouraging.
[05:33] <ajmitch> at which point does it become ignorable? when you're hired by canonical? :)
[05:33] <minghua> persia: An extra ACK for MOTU's new package upload is probably better left as a soft requirement.
[05:33] <ScottK> ajmitch: I think we changed it from MOTU needs to acks to MOTU counts as one of the acks.
[05:33] <persia> minghua: I'll defer to current policy regarding the number of ACKs, but I think it's 2,
[05:33] <ajmitch> ScottK: it was always a MOTU counting as an ACK before that
[05:33] <ScottK> This is for new packages.  For new upstreams, it's only one.
[05:33] <persia> ScottK: That's my memory: it used to be three people, and now it's down to two.
[05:34] <persia> ScottK: For new upstreams, MOTU needs an ACK?  I've just uploaded the one I did.  Was that wrong?
[05:34] <minghua> Basically I don't think it's enforceable, and it's always bad to have unenforceable policies.
[05:34] <ScottK> persia: No that's right.
[05:34] <ScottK> persia: For new upstream MOTU can be the one.
[05:34] <persia> ScottK: Right.  Originating MOTU as ACK.
[05:34] <ajmitch> minghua: it's certainly not enforceable, most of core-dev would ignore it, I'd say
[05:35] <minghua> ajmitch: Yeah, I'm with you on this.  (Not that my opinion matters much, though.)
[05:35]  * Fujitsu admits to having ignored the rule once, though it was just a rename.
[05:35] <ScottK> ajmitch: I've seen Riddell upload new packages for review.
[05:35] <ajmitch> (my opinion isn't worth anything either)
[05:35] <persia> ajmitch: Maybe: we can encourage them to look at each other's packages, and to let us look at their packages: for a good package (even one that needs a little work), the total cycle is usually less than an hour.
[05:35] <ajmitch> ScottK: he'd be one of the few then
[05:35] <ScottK> The ironic thing is I found a licensing/copyright problem in it.
[05:36] <persia> That's actually the reason I favor reviews.  The people who do lots & lots of reviews get pretty good at looking for things.  Most developers couldn't care less about many of the issues.
[05:38] <ScottK> StevenK: Any idea how long one has to generally wait for an AM to be assigned these days?
[05:38] <ajmitch> probably several weeks
[05:38] <Fujitsu> ScottK: Mine was 3 months, IIRC.
[05:38] <Fujitsu> Yeah, about that.
[05:38] <ScottK> Thanks.
[05:39]  * ScottK got advocated today, so waiting for AM now.
[05:39]  * persia continues to find NM sufficiently painful to be avoided
[05:39] <ajmitch> given the length of the list of unassigned applicants, it could take awhile
[05:39] <ajmitch> jcastro! dude!
[05:39] <Fujitsu> Oh joy, of the 149 Ubuntu-specific packages that actually have watch files, 59 of them don't work at all.
[05:39] <ajmitch> only 59?
[05:39] <ajmitch> that's pretty good
[05:40]  * persia grumbles at reviewers who don't test watch files
[05:40] <Fujitsu> persia: These could well be old stuff synced from the middle of nowhere.
[05:40] <persia> Fujitsu: Ah.  True.
[05:40] <ajmitch> sorry persia, we're not all wonderful at reviewing like some
[05:41] <persia> ajmitch: Huh?  I'm not a very good reviewer: I just run uscan, linda, lintian, and have 4 or 5 manual checks.
[05:42] <ajmitch> if I review, I'll get grumbled at, I'm sure
[05:43] <persia> ajmitch: Actually, while I grumble at people in general, I'm always happy when people review: there's never enough people to just take a look at the packages, and give the packagers a little feedback.
[05:44]  * somerville32 has learnt a lot from persia
[05:45]  * ajmitch heads out