cmd/snap: implement userd command as replacement for snapd-xdg-open #3260

morphis · May 2, 2017

In https://forum.snapcraft.io/t/integrate-snapd-xdg-open-into-snapd-repository/100 we decided to implement a snap userd command which replaces snapd-xdg-open.

Based on discussion from https://forum.snapcraft.io/t/integrate-snapd-xdg-open-into-snapd-repository/100

zyga · May 2, 2017

zyga reviewed May 2, 2017

View changes

The overlord of the word interface is unfortunate.

True, but we deal with dbus interfaces here ..

ogra1 · May 2, 2017

ogra1 reviewed May 2, 2017

View changes

we audit this already inside the core snap, before sending the call to the dbus ... i think it would be nice to agree to only do this auditing in one place (either at the start or at the end of the chain) so you do not need to change two places (core snap as well as snapd code) when adding or removing a protocol handler (i dont care which side we drop, but having a single place will prevent errors)

Where are we doing this? The xdg-open script in the core snap has only:

$ cat /snap/core/current/usr/local/bin/xdg-open                
#!/bin/sh
dbus-send --print-reply --session --dest=com.canonical.SafeLauncher / com.canonical.SafeLauncher.OpenURL string:"$1"

in the mimetype handler of the .desktop file we install inside core: https://github.com/snapcore/core/blob/master/live-build/hooks/500-create-xdg-wrapper.binary#L23
and in the mimeapps.list we implement:
https://github.com/snapcore/core/blob/master/live-build/hooks/500-create-xdg-wrapper.binary#L28
protocols not defined in there will simply be ignored. as i said above i'm not opposed to drop this if it doesnt break things, i'd just like if we have only one place defining it.

Anything inside the core snap is untrusted as it can be altered by the attacker. This filtering really does belond on this side.

ogra1 · May 2, 2017

ogra1 reviewed May 2, 2017

View changes

keeping this as separate package will break for users using only "apt-get upgrade" (vs dist-upgrade) if snapd gets a dependency on it.
...it was one of the main reasons to actually start discussing to move snapd-xdg-open into snapd in the beginning to actually get it into distros that have not seeded it (like elementary) without introducing a package dependency.

similar to snap-confine btw ...

It will stay a separate package but produced by the snapd source package so we can migrate people away from the other snapd-xdg-open deb package. That was the idea. Didn't tested yet this works well.

well, but that means you have to either add a recommends (in which case the package will never be installed for users only doing "apt-get upgrade") or you add a hard dependency in which case users of "apt-get upgrade" will get an upgrade error. we have tons of bugs for that case from snap-confine which was one of the reasons to include it without a separate package, keeping a separate binary package looks to me like we are exactly re-introducing the same problem again just with another package now.

We need one or another way to get the snapd-xdg-open package removed from installations out there. If we have a binary package produced by two different source packages but the second one has a higher version as the first one isn't then the one from the first source package overwritten?

The Recommends is for sure missing. Any other ways how we can achieve this?

yes, include the binaries in snapd and have the proper breaks/replaces lines (and perhaps a provides) in the snapd package.

Ok, including the binaries in the snapd package was the plan. Will add the Breaks/Replaces line.

Done.

CC @mvo5 - I think we just want to have this in the main snapd package and have snapd-xdg-open as an empty transitional package.

@zyga that is what we already do here. But leaving this to @mvo5 to approve.

zyga · May 8, 2017

Personally, given the scope of this branch, I'd like to re-target a smaller subset. Let's start with the basic mechanics (user session daemon) even if it does nothing. Then follow up with more things.

zyga · May 8, 2017

zyga reviewed May 8, 2017

View changes

Some more comments.

I think this should come from the outside. Ideally we'd have one makefile for everything in data/

My point is that := is stronger than ?=

Got it, will change to ?=

Done.

We could convey things like LIBEXECDIR and anything else through make variables.

Aren't we doing that already? We just take the defaults here as we do similar for the systemd build step. This works similar like with default values for configure scripts.

Well, not with LIBEXECDIR := /usr/lib that you can see in data/upstart/Makefile

Isn't that already a variable set in the Makefile which can be optionally overridden by the caller?

If you go with one makefile you could just roll that into the existing make install on data.

We can do a single makefile but this would make it a bit harder for people to skip the installation of the upstart files.

zyga · May 15, 2017

zyga reviewed May 15, 2017

View changes

Some comments, good luck! :-)

You can combine this into one line:

if _, err := parser.ParseArgs(os.Args[1:]); err != nil {
...
}

Can combine that. The code was exactly this way before.

Can we call SetUserAgentFromVersion unconditionally? I suspect we can and it would not hurt in any way.

It was done this way before so I guess it's ok.

Good luck a packaging that everywhere ^_^

Quick question: how many dependencies does godbus itself pull in?

I only had to add godbus itself to our vendoring setup, no more. And the good thing is, it is already on Fedora, the only distro where this would hurt.

What about Debian?

Somebody would have to submit a package but our story for debian is basically that we rely on re-execution to work. For unstable and next testing this would be a thing somebody has to look into but I guess that will be a natural thing once we task somebody to package a more recent snapd version for debian.

I think this somebody is you and me We should pick this up in anticipating of this thing landing.

I've talked with Michael and Steve in the past and they weren't much interested as re-execution is supposed to handle this and we can't really update snapd in stable or testing. So unstable is our only possible landing bed. You're a debian developer? If you're I would prefer you do this as I am not one.

I'm a DM, in either case we must package this for Sid.

I think you can skip tomb as it will be imported like that anyway.

Will try.

Done.

Nitpick: I know this is what we currently implement but I'd like us to listen on both io.snapcraft.SomethingNice and com.canonical.SafeLauncher (the second one can be deprecated later)

I would not like to open another gate here with the upcoming xdg portal working which will introduce a very similar API. Lets keep it to what it is today and then refine / rework in a follow up PR.

I'm not versed in the tomb semantics to review this. @pedronis perhaps?

@pedronis any comments from your side?

See below

You may use DeepEquals and pass full objects as arguments.

Done.

You may use DeepEquals and pass full objects as arguments.

Done.

See below

I think we can do better than sleeping. Perhaps add a notification channel/callback to notify when we're ready?

@morphis can you please comment on this.

See above

Typically such functions return a restore func() that undoes the effect.

Done

In cases like that just do:

const safeLauncherIntrospectionXML = `
...
`

Done

Can you please always disambiguate DBus interface vs snapd interface?

Please use %q, as '%s' does not quote properly.

Please use $(MAKE) instead of make below.

Done

You can combine all three rules:

all install clean:
    $(MAKE) -C systemd $@
    $(MAKE) -C upstart $@

Done

Do we need a new FESCO request to allow us to use a user service?

Maybe, didn't checked with Neal yet.

I bet I'm missing something but isn't it the case that user services have this funky syntax including @ in the service name?

They don't have to. @ basically allows to pass arguments to the systemd unit which we don't need in this case as systemd will ensure we're started as the right user and in the right scope.

Aha, I see, thank you!

I think this should come from the outside. Ideally we'd have one makefile for everything in data/

My point is that := is stronger than ?=

Got it, will change to ?=

Done.

Nitpick, this fits on one line nicely:

Done

Please use single quote around this

Will do

keeping this as separate package will break for users using only "apt-get upgrade" (vs dist-upgrade) if snapd gets a dependency on it.
...it was one of the main reasons to actually start discussing to move snapd-xdg-open into snapd in the beginning to actually get it into distros that have not seeded it (like elementary) without introducing a package dependency.

similar to snap-confine btw ...

It will stay a separate package but produced by the snapd source package so we can migrate people away from the other snapd-xdg-open deb package. That was the idea. Didn't tested yet this works well.

well, but that means you have to either add a recommends (in which case the package will never be installed for users only doing "apt-get upgrade") or you add a hard dependency in which case users of "apt-get upgrade" will get an upgrade error. we have tons of bugs for that case from snap-confine which was one of the reasons to include it without a separate package, keeping a separate binary package looks to me like we are exactly re-introducing the same problem again just with another package now.

We need one or another way to get the snapd-xdg-open package removed from installations out there. If we have a binary package produced by two different source packages but the second one has a higher version as the first one isn't then the one from the first source package overwritten?

The Recommends is for sure missing. Any other ways how we can achieve this?

yes, include the binaries in snapd and have the proper breaks/replaces lines (and perhaps a provides) in the snapd package.

Ok, including the binaries in the snapd package was the plan. Will add the Breaks/Replaces line.

Done.

CC @mvo5 - I think we just want to have this in the main snapd package and have snapd-xdg-open as an empty transitional package.

@zyga that is what we already do here. But leaving this to @mvo5 to approve.

morphis · May 29, 2017

@mvo5 @ogra1 @zyga @niemeyer Can you guys have another look at this?

niemeyer · May 29, 2017

niemeyer requested changes May 29, 2017

View changes

The general feeling I have of the whole PR is that there's quite a bit of future thinking and perhaps premature abstraction into what is actually a simple change we need to do right now.

Another feeling that comes from reading the code is that this is not really about snapd. This is abstracting away the snapd command and its daemon interface, but the actual sharing of code and functionality with snapd itself is very close to zero. Instead, this is really a client to snapd, and I expect it will soon need to call into the actual snapd, using its sockets, etc. As such, it'd be closer to the "snap" command. Perhaps we should have "snap userd" or similar?

Happy to discuss this live when you have a moment.

I'd also go straight to the point instead of trying to organize and abstract away what is actually a pretty small amount of code. For example, how simple would we be able to make such a userd command inside the current snap command infrastructure?

Then, as a last side-note, let's please take this chance to rename the interface to io.snapcraft.SafeLauncher or similar.

morphis · May 30, 2017

Happy to discuss this live when you have a moment.

Lets hang on after the SU today.

morphis · May 30, 2017

morphis reviewed May 30, 2017

View changes

Let me rework that.

morphis · May 30, 2017

Agreed with @niemeyer that I will move the daemon into snap userd

codecov-io · Jun 19, 2017

Codecov Report

Merging #3260 into master will decrease coverage by 0.2%.
The diff coverage is 17.24%.

@@            Coverage Diff             @@
##           master    #3260      +/-   ##
==========================================
- Coverage   75.86%   75.65%   -0.21%     
==========================================
  Files         403      407       +4     
  Lines       34835    35020     +185     
==========================================
+ Hits        26427    26494      +67     
- Misses       6535     6647     +112     
- Partials     1873     1879       +6

Impacted Files	Coverage Δ
interfaces/builtin/unity7.go	`67.85% <ø> (ø)`	⬆️
userd/userd.go	`0% <0%> (ø)`
testutil/dbustest.go	`0% <0%> (ø)`
userd/launcher.go	`0% <0%> (ø)`
cmd/snap/cmd_userd.go	`83.33% <83.33%> (ø)`
cmd/snap/cmd_aliases.go	`93.33% <0%> (-1.67%)`	⬇️
daemon/api.go	`72.45% <0%> (-0.18%)`	⬇️
cmd/snap/cmd_snap_op.go	`63.63% <0%> (-0.11%)`	⬇️
... and 5 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3aa2420...278ac67. Read the comment docs.

chipaca · Jul 10, 2017

The spread test failures are germane.
What's the status of this PR?

morphis · Jul 10, 2017

@chipaca I know, systemd-run doesn't exist on 14.04 so I am adding upstart variant currently.

morphis · Jul 11, 2017

@niemeyer @chipaca @zyga This is ready for another review round. If the spread test still fails for 14.04 ignore that for the moment, I am working on getting it to pass.

zyga · Aug 8, 2017

zyga requested changes Aug 8, 2017

View changes

A few comments, I think this is very close now. Let's please iterate on this.

Perhaps fmt.Errorf("cannot obtain bus name %q", busName)

Thank you for using $(MAKE)

Why not just sed < > ?

Please quote the argument with single quotes.

@Sed This is using the same as in data/systemd/Makefile as @mvo5 initially suggested :-)

Let me do the quoting.

You mean quoting all of s:...:g? That wont work as it wont replace ${BINDIR}

It will because it is make that is doing the string expansion, not sh.

Thanks, added the quoting, fwiw, while sed < > works I like the cat better because the shell < and the make $< in one line make my eyes twitch ;)

Nitpick: it would be nice if those would end with a dot like proper sentence.

I think this could be wrapped in a nice helper.

cannot open supplied URL

"fmt" belongs upstairs with "testing"

I think this should be swapped with the snapd import above. Maybe my memory is skewed towards python experience but imports are (stdlib, 3rd party, this project)

I think you can skip the NotNil test since ErrorMatches already expresses it.

Same

The next few tests could be pulled into one table-driven test.

This should be updated along with the earlier comment about Can not

I would love if we confined the safe launcher eventually :-)

Finally, thank you again for doing this :-)

That is an insane number of Breaks/Replaces directives!

I wish we had one spelling for this variable.

I think this will change in time but this is fine for now.

Hmm, what? I admit I don't get the xargs part.

This just moves the "foo=bar\nbar=bar" to "foo=bar bar=baz", i.e. removes the newlines

We could use the https://dbus.freedesktop.org/doc/dbus-java/api/org/freedesktop/DBus.Peer.html#Ping() method to wait properly. I'd rather not do a sleep here as we have plenty of races already.

The ping seems to be java specific, but I did something in a similar spirit in the branch now.

The ping method is not specific to Java: https://dbus.freedesktop.org/doc/dbus-specification.html

On receipt of the METHOD_CALL message org.freedesktop.DBus.Peer.Ping, an application should do nothing other than reply with a METHOD_RETURN as usual. It does not matter which object path a ping is sent to. The reference implementation handles this method automatically.

mvo5 · Aug 23, 2017

mvo5 approved these changes Aug 23, 2017

View changes

Thanks a lot for doing this work! I like this PR a lot. I took the liberty to fix some of the nitpicks I had.

(nitpick) The convention is usually 1. go lib imports, 2. external libraries 3. snapd stuff. I'll fix that.

Nice!

(nitpick) extra newline.

Why not just sed < > ?

Please quote the argument with single quotes.

@Sed This is using the same as in data/systemd/Makefile as @mvo5 initially suggested :-)

Let me do the quoting.

You mean quoting all of s:...:g? That wont work as it wont replace ${BINDIR}

It will because it is make that is doing the string expansion, not sh.

Thanks, added the quoting, fwiw, while sed < > works I like the cat better because the shell < and the make $< in one line make my eyes twitch ;)

A restore functions is missing here, this is the idiomatic way we do this kind of mocking.

lol@upstart - I assume you mean dbus here?

No, we need both the upstart (for 16.04 session) and systemd config files here.

@zyga but we don't generate any upstart files, do we? We generate a dbus service file that will auto-start. Or am I missing something?

mvo5 · Aug 23, 2017

One more concern - cmd_userd.go lacks unit tests, I will look/think about this next.

zyga · Aug 23, 2017

zyga reviewed Aug 23, 2017

View changes

Do we want to / need to do something to exit cleanly on a signal? Does it behave correctly when the session is shutting down?

Nice catch, yes we do.

zyga · Aug 23, 2017

zyga reviewed Aug 23, 2017

View changes

Some comments need responses (mainly about tests and sleeping). I'd like to get a confirmation from somebody that they actually tested this on Ubuntu Artful.

I'll review again when pinged.

niemeyer · Aug 23, 2017

niemeyer requested changes Aug 23, 2017

View changes

A few trivials and one relevant question. Probably the last pass.

s/snap//

s/snap//; this is really the user session service. The fact it's about snaps is implied in the context. The association in the sentence is also slightly unclear ("snap user session service" are four nouns in a row, which can be mentally aggregated in different ways.. e.g. "snap user"). Just removing the "snap" word here as well should be enough.

This should be "userd" I think. Besides being inconvenient and confusing to have two packages named dbus that need to be used next to each other, the content here is really about a particular package leveraging dbus rather than being a door into dbus.

Can we please rename this type to Launcher and the file to launcher.go. Originally it was important to have Safe in here because it was a general namespace. The safety implications are now implied with this being under snapcraft.io, in that safety is a concern across all such external interactions, so we don't need to call it out explicitly.

We may also end up putting this behind an interface some day, so the name would also be less right in that case.

I'm slightly concerned here because the real xdg-open is a shell application with a pretty extensive and hard to review implementation.

Isn't there a standard dbus service these days to take such URLs?

if there was, this whole chunk of work wouldn't've been necessary :-)

The xdg-desktop-portal work brings something like this, yes, but that isn't an option cross-distro. Maybe in a few years when everyone has settled on xdg-desktop-portal but as long as that doesn't happen we have to live with xdg-open. I don't see a big problem with xdg-open, it's in main (so comes with security updates from our side), an official upstream project (https://cgit.freedesktop.org/xdg/xdg-utils/) etc.

I can understand that it being a shell script and hard to read is suboptimal but this is something which doesn't play into a discussion for the current implementation.

We started with just bringing snapd-xdg-open into the tree which then became a whole rewrite. Lets not start another rewrite in the same thread. If xdg-open is still suboptimal from a snapd perspective lets figure that out in another thread but lets finish this one first. It's already going on for too long :-)

I'm not aware of anything that is more portable than xdg-open :/

We could check which of gvfs-open, kde-open, exo-open to use ourself, but that would duplicate the detection logic in xdg-open of course.

mvo5 · Aug 24, 2017

I also created the companion PR for the core side: snapcore/core#54

zyga · Aug 25, 2017

zyga reviewed Aug 25, 2017

View changes

Feels like libexecdir thing to me.

This is the regular snap binary that provides the userd subcommand. So we need bindir here unless I miss something.

This is correct, though I expected this to be implemented in a libexecdir command, as users shouldn't usually do things here. Not a biggie, though.

zyga · Aug 25, 2017

zyga reviewed Aug 25, 2017

View changes

Hey

Thank you for picking this up mvo. Two nitpicks, one about libexecdir vs bindir (no manual page for us to write) and one more about ping. I really really want to use the ping method because it's the right thing to do in this context.

Please use the regular peer ping method here.

Unfortuantely ping is not implemented by us, I can dig a bit more into this but it looks like a limiation/missing feature of the godbus library which is not very high-level.

I changed the code to use "ping" now.

zyga · Aug 25, 2017

zyga approved these changes Aug 25, 2017

View changes

niemeyer · Aug 25, 2017

niemeyer approved these changes Aug 25, 2017

View changes

Conan-Kudo · Aug 25, 2017

Conan-Kudo approved these changes Aug 25, 2017

View changes

Looks great, but a few comments.

Feels like libexecdir thing to me.

This is the regular snap binary that provides the userd subcommand. So we need bindir here unless I miss something.

This is correct, though I expected this to be implemented in a libexecdir command, as users shouldn't usually do things here. Not a biggie, though.

👍 🎉

Please refrain from making unrelated changes to the spec. Changing from pushd / popd to using make -C is a different type of change.

Sorry, I just inherited this change, I can revert this back if you prefer.

Ditto here.

Same as above.

Finally, thank you again for doing this :-)

That is an insane number of Breaks/Replaces directives!

niemeyer · Aug 28, 2017

Thanks for the long work here @morphis, thanks for taking this over @mvo, and thanks for the reviews everybody else!

feikname · Aug 28, 2017

Thank you guys for this!

So, snaps that call xdg-open will work out of the box without any dependences when 2.28 gets released?

mvo5 · Aug 29, 2017

@feikname correct :)

morphis · Aug 29, 2017

@mvo5 I owe you a beer or something else on the next sprint for taking this over and finishing it!

morphis changed the title from WIP: Implement --user instance for snapd to daemon: implement --user instance for snapd May 4, 2017

morphis referenced this pull request May 12, 2017
Closed
many: add support for session dbus services via snaps #2592

Simon Fels added some commits Jun 1, 2017

Merge remote-tracking branch 'origin/master' into f/snapd-user-instance

1ba7608

many: rework user service implementation to be part of the snap command

f6825ad

diddledan referenced this pull request in baedert/corebird Jun 2, 2017
Open
Add snap package instructions to documentation #732

morphis changed the title from daemon: implement --user instance for snapd to cmd/snap: implement userd command as replacement for snapd-xdg-open Jun 19, 2017

chipaca added the Decaying label Jul 10, 2017

Ads20000 referenced this pull request in snapcrafters/discord Aug 19, 2017
Closed
Cannot open link #1

mvo5 added this to the 2.28 milestone Aug 23, 2017

mvo5 added some commits Aug 24, 2017

rename dbus package to userd

3ab33bc

rename io.snapcraft.SafeLauncher -> io.snapcraft.Launcher

bb185e7

mvo5 added a commit to mvo5/core that referenced this pull request Aug 24, 2017

Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher
This is the companion for snapcore/snapd#3260 on the snapd side.

97939d6

mvo5 referenced this pull request in snapcore/core Aug 24, 2017
Merged
Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher #54

feikname referenced this pull request in yvt/openspades Aug 28, 2017
Closed
`xdg-open` does not work with Snap version of OpenSpades #639

Conan-Kudo added a commit to Conan-Kudo/snapd that referenced this pull request Sep 6, 2017

packaging/fedora: Add missing godbus dependencies
This should have been caught when snapcore/snapd#3260 was being worked on. Signed-off-by: Neal Gompa <ngompa13@gmail.com>

4a66417

mvo5 added a commit to mvo5/snappy that referenced this pull request Sep 11, 2017

packaging/fedora: Add missing godbus dependencies
This should have been caught when snapcore/snapd#3260 was being worked on. Signed-off-by: Neal Gompa <ngompa13@gmail.com>

010ccf5

+        +type Daemon struct {
+        +	tomb   tomb.Tomb
+        +	conn   *dbus.Conn
+        +	ifaces []registeredInterface

@@ -112,3 +112,12 @@ Section: oldlibs
          Pre-Depends: dpkg (>= 1.15.7.2)
          Description: Transitional package for snapd
           This is a transitional dummy package. It can safely be removed.
+        +
+        +Package: snapd-xdg-open

@@ -103,6 +103,8 @@ override_dh_auto_build:
          	cd cmd && ( autoreconf -i -f )
          	cd cmd && ( ./configure --prefix=/usr --libexecdir=/usr/lib/snapd $(VENDOR_ARGS))
          	$(MAKE) -C cmd all
+        +	# Build any available upstart configurations
+        +	$(MAKE) -C data/upstart all

@@ -142,6 +144,10 @@ override_dh_install:
          	# and now the normal install rules
          	install --mode=0644 debian/snapd.system-shutdown.service debian/snapd/$(SYSTEMD_UNITS_DESTDIR)
          	$(MAKE) -C cmd install DESTDIR=$(CURDIR)/debian/tmp
+        +
+        +	# install any available upstart jobs
+        +	$(MAKE) -C data/upstart install DESTDIR=$(CURDIR)/debian/snapd/

+        +	if opts.User {
+        +		d, err = user.NewDaemon()
+        +	} else {
+        +		httputil.SetUserAgentFromVersion(cmd.Version)

		@@ -0,0 +1,11 @@
		+all:

		@@ -0,0 +1,10 @@
		+[Unit]

snapcore/snapd

Join GitHub today

cmd/snap: implement userd command as replacement for snapd-xdg-open #3260

Conversation

morphis commented May 2, 2017 • edited Edited 1 time morphis May 4, 2017

zyga reviewed May 2, 2017 View changes

ogra1 reviewed May 2, 2017 View changes

ogra1 May 3, 2017 • edited Edited 1 time ogra1 May 3, 2017

ogra1 reviewed May 2, 2017 View changes

ogra1 May 3, 2017 • edited Edited 1 time ogra1 May 3, 2017

morphis changed the title from WIP: Implement --user instance for snapd to daemon: implement --user instance for snapd May 4, 2017

zyga commented May 8, 2017

zyga reviewed May 8, 2017 View changes

morphis referenced this pull request May 12, 2017

zyga reviewed May 15, 2017 View changes

morphis May 15, 2017 • edited Edited 1 time morphis May 15, 2017

ogra1 May 3, 2017 • edited Edited 1 time ogra1 May 3, 2017

Simon Fels added some commits May 2, 2017

Some checks were not successful

morphis commented May 29, 2017

Simon Fels added some commits May 29, 2017

All checks have failed

All checks have failed

Some checks were not successful

niemeyer requested changes May 29, 2017 View changes

morphis commented May 30, 2017

morphis reviewed May 30, 2017 View changes

morphis commented May 30, 2017

Simon Fels added some commits Jun 1, 2017

diddledan referenced this pull request in baedert/corebird Jun 2, 2017

Simon Fels added some commits Jun 2, 2017

All checks have failed

All checks have failed

All checks have failed

codecov-io commented Jun 19, 2017 • edited Edited 1 time codecov-io Jul 18, 2017

Codecov Report

All checks have failed

morphis changed the title from daemon: implement --user instance for snapd to cmd/snap: implement userd command as replacement for snapd-xdg-open Jun 19, 2017

Simon Fels added some commits Jun 19, 2017

All checks have failed

All checks have failed

All checks have failed

Some checks were not successful

Some checks were not successful

chipaca commented Jul 10, 2017

chipaca added the Decaying label Jul 10, 2017

morphis commented Jul 10, 2017

All checks have failed

morphis commented Jul 11, 2017

Simon Fels and others added some commits Aug 1, 2017

All checks have failed

All checks have failed

All checks have failed

All checks have failed

Some checks were not successful

zyga requested changes Aug 8, 2017 View changes

zyga Aug 8, 2017 • edited Edited 1 time zyga Aug 8, 2017

morphis commented May 2, 2017 •

Edited 1 time

morphis
May 4, 2017

zyga reviewed May 2, 2017

View changes

ogra1 reviewed May 2, 2017

View changes

ogra1 May 3, 2017 •

Edited 1 time

ogra1
May 3, 2017

ogra1 reviewed May 2, 2017

View changes

ogra1 May 3, 2017 •

Edited 1 time

ogra1
May 3, 2017

zyga reviewed May 8, 2017

View changes

zyga reviewed May 15, 2017

View changes

morphis May 15, 2017 •

Edited 1 time

morphis
May 15, 2017

ogra1 May 3, 2017 •

Edited 1 time

ogra1
May 3, 2017

niemeyer requested changes May 29, 2017

View changes

morphis reviewed May 30, 2017

View changes

codecov-io commented Jun 19, 2017 •

Edited 1 time

codecov-io
Jul 18, 2017

zyga requested changes Aug 8, 2017

View changes

zyga Aug 8, 2017 •

Edited 1 time

zyga
Aug 8, 2017