Reporting bugs in snaps

[wxl]

This has been bugging me for a while. It’s really hard to try to figure out how to report an issue with a particular snap.

Sure, for the common ones, it’s relatively simple. The top four featured ones I see on the store seem to be more or less clear:

1. josm has a contact email
2. vault, being Canonical’s doing, has a link to their GitHub issues (albeit not visible with snap info unless you use --verbose)
3. artikulate has a contact link to the KDE bug tracker (which is also under links so it shows up regardless of whether or not you use --verbose)
4. mumble, as a Snapcrafters project, has a link to their GitHub issues (which, like artikulate, is also under links)

But for other ones, it’s anyone’s guess. For example, let’s consider authenticator. It has no website, contact, bug reporter, anything. Nothing. In fact, not to pick on him, but all of @kenvandine’s snaps lack any sort of information altogether.

This includes element-desktop, which makes me concerned in particular as Lubuntu has started offering as an option in the installer. Where do we tell people to report bugs? Where do we search for bugs? Kind of makes it hard to support without knowing that.

At least in that case, we have a star developer with a long track record of snapping, so I’m sure posting somewhere on the forum would probably work.

For other snaps, not only is there no information, but it’s not even easy to find information about the developer, upstream or otherwise. Consider pcsx2-tabetai. There’s not const or lolsmith (the publisher is “Const (lolsmith)”) on Launchpad or on the forum that I can tell. Doing a general search for the two together doesn’t really produce any relevant results and individually is a morass. I’m pretty confident that they’re not involved in the upstream development.

All that holds true for tabetai, which seems to be appended to all of their snap names and, as such, be a hint to their identity. Indeed, looking on GitHub for that user name, you can finally find the repo for the snap. Note there are no issues there, closed or otherwise. In fact, that’s true for every one of their other snap repos, too, except for one issue on the mcomix snap they published and, even then, it hasn’t been touched since it was filed in 2019. Note, too, the creator isn’t even sure they’re reporting in the right place.

So if someone was using that package and had a bug (as it appears someone who posted to the Lubuntu Reddit appears to have), what would they do? The upstream certainly doesn’t provide snaps (they have AppImages) so you can’t go there for help. Would they post here? What guarantee is there that the publisher or developer even looks at the forum?

Now imagine that you have a relative newcomer to Linux in general. Do you think they would even bother to hunt through all those possibilities I just did? Or do you think they would just throw their hands up in there air and denounce the whole OS? I’m inclined to believe the latter. We have to make this easier.

So tl;dr I get the reason why there isn’t necessarily a single tracker to report bugs for snaps, but there needs to a much more clear path to report bugs and find help. I can suggest two solutions that together should solve the issue:

1. Make contact information mandatory (I think this should be obvious and easy to implement)
2. Add a feature to snapd (maybe snap bug) that uses the contact information to get the user easily to the right place.

[popey]

Thanks for the post @wxl

There’s at least two specific problems here, plus a wider malaise I will lament about, and then get ignored, as usual.

They are:

1. Store apps without metadata, or with incorrect metadata at all
2. Store apps with out of date metadata

Let’s start with 2). Back in the day (3 years ago?) there were no ‘source-code’, ‘issues’ and ‘donate’ fields in which to put that useful metadata. There was just one place to put a link to the upstream issue tracker, and you had to hope the publisher would put some nice detail in the body of the snap.

When the extra fields were added, there was no song and dance about it, they were just quietly added. No blog (that I recall or can find) and no ‘newsletter’ to publishers. It was just that one day “huh, there’s new fields here” - which you’d only notice if you happened to look at the store.

Many publishers almost never look at the store web UI

They publish via CI/CD and ‘aint got time for that’. As such, mostly only newly published snaps have that metadata, because the publisher sees them at the time of creation.

For 1) it’s plain laziness. I’m guilty of it with some of my snaps having ‘minimum effort’ pages. I try and make them appealing, and if I see one that isn’t I’ll make a note to update it.

The fact is everyone (at Canonical) seems busy doing other things. There’s no Snapcraft advocacy team as there was years back. Indeed, when I was on that team I gave a lightning talk in Paris (so maybe 5 years ago now) telling Canonical snap publishers that they should pull their fingers out of their arses and make their store pages appealing.

I gave lxd as an example of a good page, and core as an example of the worst. As best as I can tell, everyone the talk was aimed at in the room ignored everything I said. Par for the course.

The core snap store page hasn’t changed in all that time

I started a thread here on the internal staff category. Nobody even read it. Most of the moderators had left the company, or don’t login anymore. Ironic, given the thread I started was asking for more moderators. I had to poke someone on the Ubuntu community team to try and get a reply. They had to create an account here, because they too had never logged in.

The process-based conversations tend to work, and publishers get some technical support, but this place is basically dead. It’s only us weirdo hangers-on who actually want the thing to succeed who actually contribute.

The only recent peaks in traffic have probably been due to crypo scam posts (you’re welcome) and the follow-up posts. It’s quite depressing, really.

So yes, at a micro level, there should be somethig done about the store approval policies. Kick out apps that are outdated, deprioritise apps with no screenshots, don’t leave the same snaps on the front page and in categories for months

At some level, it’s almost like Canonical have given up and don’t care about this anymore. I personally suspect that any of the fabulous individuals who does care, just isn’t given the resources or cycles to actually do anything about it. Even if that means 10 minutes to update the metadata on a web page, or add a few fresh apps to the editor’s picks category after three years…

It’s all deeply frustrating when you’ve put so much time into something, and it’s just left to rot.

[iGadget]

This is… bad. If even Canonical doesn’t seem to care anymore, why on earth should we? And it’s also quite contradictory to on the one hand double-down on Snaps (i.e. Thunderbird in 24.04) but at the same time to completely ignore the fundamentals like this… How in their heads is that a working strategy?

[wxl]

My complaint here was about bug reporting. What you’re describing, @popey , is a whole different ball of wax. To some degree, I don’t care so much about some of the issues you describe. I don’t give a hoot if there’s no screenshots as long as I know how to get support! I also don’t really care of the forum’s dead, at least as long as it’s not intended to be a place to get basic help with bugs and support for your average end-user.

What concerns me is this:

@popey

it’s almost like Canonical have given up and don’t care about this anymore

Now perhaps this is a little hyperbole and you’re merely expressing frustration, just as we all did at one time with the Ubuntu Wiki as it had fallen into disrepair. That I can understand.

But if you’re actually telling me that Canonical has decided to sort of move on from Snaps, then we’ve got a big problem. There is no justifiable reason why Canonical can force Snap packages on folks if they’re not going to support them. I can’t imagine that’s what you’re saying. Right?

That said, I’m going to run on the assumption that Canonical actually does care and does want to continue to make Snaps first class citizens. I certainly see them doing enough work in this direction to suggest that.

So back to my issue: bug reporting and support in Snaps. It seems that it would be a simple thing to:

1. Warn publishers, past and future, that as of some date in the near future, all Snaps will require at least a support contact
2. Change the store and snapd so that they will not list Snaps which do not meet the criteria

If publishers are so lazy that they can’t make the change, we probably don’t want their Snaps anyways.

So how do we make this happen?

[James-Carroll]

@wxl

1. Warn publishers, past and future, that as of some date in the near future, all Snaps will require at least a support contact
2. Change the store and snapd so that they will not list Snaps which do not meet the criteria

+1 on this idea! It’s a minimum standard for snaps to be in the “Canonical” account for a reason, but basics shouldn’t be limited to a subset of users.

[KhazAkar]

As a great example, we can take a look how quite recently Flathub, biggest flatpak “store” took approach to mentioned issues in their guidelines. Some of them I would drop, but the rest - useful.

[soumyaDghosh]

I think this PR can fix some of that issue for those who uses appstream metadata. But no idea when will they merge it.

https://github.com/canonical/snapcraft/pull/4652

Also, to fix the ugly titles of snaps, I created a PR in discover and got this reply, which I think is very much valid.

https://invent.kde.org/plasma/discover/-/merge_requests/853

At this point, I am also hopeless. And I think that only a FOSS version of snaps and snapcraft can save it. (Which actually just needs time, it’s not that complicated to make)

[johnandmegh]

@wxl

That said, I’m going to run on the assumption that Canonical actually does care and does want to continue to make Snaps first class citizens. I certainly see them doing enough work in this direction to suggest that.

As an outside observer, I would agree with both your statement - that a lot of work goes into ensuring the functionality of the underlying Snapcraft technology - and with the sentiment of @popey that there isn’t currently much visibly happening with the Snap Store as a “universal app publishing platform for Linux”.

Canonical-owned work could theoretically be very healthy, and could enable Ubuntu Core, etc., but the theoretical community groundswell around Snaps could simultaneously be atrophied due to neglect from the sponsor, and overwork of the small handful of folks trying to make it work.

I think the catch is that what you’re looking for, IMO, would be a result of having a healthy, facilitated flow between application developers, Canonical, and the user community. I don’t think it happens, or can be sustained, without that.

[soumyaDghosh]

@johnandmegh

I think the catch is that what you’re looking for, IMO, would be a result of having a healthy, facilitated flow between application developers, Canonical, and the user community. I don’t think it happens, or can be sustained, without that.

Very much agree with this.

[soumyaDghosh]

Snapcraft: Adopting appstream metadata