Thanks for letting the community know about this bug in some software you installed. @drcoccodrillus has an account here, so maybe me pinging them will let them know there’s a bug in their package.
While I appreciate you may not care for the communication method the publisher chose, let’s focus on the bug and how it might be fixed, rather than ranting at us volunteers about something out of our control.
The publisher of the Snap isn’t necessarily the Developer of the software, although often it is.
Unless the publisher is “Canonical” the Snap package isn’t a reflection on Ubuntu or Canonical at all (and Snaps != Ubuntu) . It’s some software that some individual(s) decided to package for (y)our convenience. For contrast here’s a package which is maintained by Canonical with community contributions:
If you have a GitHub account, you can submit an issue to the project directly! If you don’t have a GitHub account, then I suggest you consider whether you ought to have one for the longer term interactions you will have in the software development and packaging communities.
Hi! Thank you for your kind responses. I want to stress that the problem is not the maintainer, personally, who is surely a very nice and competent person, nor is it you personally, but the snap platform … though I’m sure you’ve heard this complaint before.
Thanks for Googling it for me I’ll follow up there and sorry for the somewhat unhinged rant, it was a sequence of frustrations upon frustrations.
I must be honest, I don’t think we have heard that feedback regarding the contact details before. The closest I’ve seen is someone on the Ubuntu Discourse recently who asked why the bug reports for the Steam Snap were on Github not Launchpad, which is also specifically for bug reports whereas “Contact” is generally more informal and personally seeing Twitter there isn’t unreasonable IMO (politics of Twitter itself aside).
Infact, looking at the website (which should also pull through to snap info but I’m aware there can be exceptions), there’s a link to the Github on the store page too.
So they’ve provided both a direct handle to get in touch informally and a direct handle to submit bug reports, discussion, and sourcecode formally.
Aside from providing an email address rather than a Twitter account, this snap to me looks to be in good standing, and I would expect that the github link was also part of snap info but I’m cautiously anticipating there might be a reason it didn’t show for you (I.E the metadata is on the Store Page and not part of Snap itself, if you already have the snap installed, it queries the info locally and might be slightly different to the website). If that’s happening, the maintainer would be able to add it to the snap directly, but I can easily understand plenty of maintainers not realising the distinction.
I suspect it’s because historically the contact field was the only place you could put source/issues/contact. Later, the other metadata fields were added (maybe around 2021?).
snap info --verbose shows it though.
For example:
snap info halloy | head -n 14
name: halloy
summary: IRC application written in Rust
publisher: Alan Pope (popey*)
store-url: https://snapcraft.io/halloy
contact: https://github.com/squidowl/halloy/issues
license: GPL-3.0
description: |
Halloy is an open-source IRC client written in Rust, with the Iced
GUI library. It aims to provide a simple and fast client for Mac,
Windows, and Linux platforms.
snap-id: ZhQtGnWXizPzgzCZagJMGc1vZSgSCMny
channels:
latest/stable: 2024.6.7068008 2024-04-06 (54) 24MB -
latest/candidate: ^
snap info --verbose halloy | head -n 14
name: halloy
summary: IRC application written in Rust
publisher: Alan Pope (popey*)
store-url: https://snapcraft.io/halloy
contact: https://github.com/squidowl/halloy/issues
links:
contact:
- https://github.com/squidowl/halloy/issues
issues:
- https://github.com/squidowl/halloy/issues
source:
- https://github.com/squidowl/halloy/
website:
- https://squidowl.org/
Seems like an easy PR, assuming there’s a white list for fields in non-verbose mode, it might just be a case of bumping that info up from --verbose to not verbose. I still think the local vs remote might play a small part but it’s been years since I’ve checked and the --verbose alone would already be a good action point ignoring the second (theoretical) issue.
Feel free to file an issue on snapd, which, frustratingly and ironically lists the wrong issue tracker in their store page (so two bugs needed), and in the wrong field, and the source entry is not filled in. So many bugs.
snap info --verbose snapd
name: snapd
summary: Daemon and tooling that enable snap packages
health:
status: unknown
message: health has not been set
publisher: Canonical✓
store-url: https://snapcraft.io/snapd
contact: https://github.com/snapcore/snapd/issues
links:
contact:
- https://github.com/snapcore/snapd/issues
website:
- https://snapcraft.io
https://github.com/snapcore/snapd/issues is a dead link - redirecting to https://github.com/snapcore/snapd/pulls because the snap team uses launchpad.
Wow! Thanks everyone for the productive discussion and sorry again for the tone of my initial message.
As you say… it’s there… in snap info --verbose. Which admittedly isn’t the first place I thought to look (sadly many CLI tools don’t even follow the convention of accepting --verbose these days) but it is there. It definitely should be in the snap store, as you say, this would be an easy fix (though I’ll leave it to someone who understands the code better).
For the snap info command, it looks like we’d just want to remove the verbose check here:
Which itself is trivial, but the non-trivial bit will be actually building and testing it since the snapd snap is a difficult one, and there’ll probably be some tests that would need adjusting, but overall it very much looks like a small change that I’ll try PR soon.
I’ll be honest, I’d file an issue first, and see if you can get consensus on the change that’s needed, before you dive in and make a PR that you’ll have to keep updating as it gets out of sync with main. I agree it’s a good thing to ‘fix’ if it’s indeed not by design.
@dhd all good - it’s so often the case that user frustration can be boiled down to bugs. So if nothing else you’ve uncovered (at least) 3 bugs here. Good work!
Confinement is great, but as soon as you need something from the host such as man-db the situation can become very difficult. Such is the frustration and benefit of confinement.
Well done on uncovering those issues.
I made a brief attempt at bundling man-db in the snap to see if i could give you a quick solution but didn’t have the time necessary to follow it to conclusion.
Hopefully your interactions in this thread have given you some encouragement.
I am sorry that I have caused frustration in any way. At the same time, I’m glad that the initial frustration has sparked a productive conversation.
I’ll leave aside for a moment the aspects that have been discussed till now in this thread and I return to the first point that @dhd mentioned. Regarding the use of man, when it comes to snaps, I knew there was some work in progress. I’ve been monitoring this thread for a while Support for man pages, but I don’t think there have been any further developments. Is there any update I’ve missed about this topic that could help to address the issue? In that case I’m ready to work on it and fix the bug in the timewarrior snap.
I’ll leave aside the dead thread about support for man pages for a moment as that’s out of my skill set and requires internal Canonical people to do some stuff.
I will say, that the way @dhd attempted to get to the man page, interestingly, wasn’t via man taskwarriror - but taskwarrior help which I guess then launches (or attempts to launch) man for taskwarrior. One (“temporary” ) bodge workaround could be to intercept this and display the man page (or some rendering of it) from inside the snap, rather than make it available outside.
For example, a simple wrapper around taskwarrior could be shipped, and if it detects the first argument as ‘help’, do something other than launch taskwarrior itself, just render the man page out (which could be shipped as a text or markdown file or something). For any other argument, just pass through to the real taskwarrior binary.
Yes, it’s horrid, but also, yes, it’s been eight years now, so maybe this is the path of least resistance.
Thanks again for joining the conversation, and for making the snap in the first place.