TimeWarrior: `timewarrior help` does not work and contact info is useless

dhd · May 2, 2024, 12:32pm

$ timewarrior help start
sh: 1: man: Permission denied

So I’d really like to contact the maintainer. Who could it be?

$ snap info timewarrior | grep contact
contact:   https://twitter.com/DrCoccodrillus

There is no f*** way that I should have to sign up to Melon Husk’s hellsite just in order to report a bug
The account is locked and private!

Definitely never installing any snaps ever again and hopefully abandoning Ubuntu if this is your idea of how to distribute and maintain software.

popey · May 2, 2024, 12:52pm

Hello! Welcome to the community.

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.

DWD · May 2, 2024, 1:07pm

Welcome! It’s also good to remember that:

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:

$ snap info snapcraft
name:      snapcraft
summary:   easily create snaps
publisher: Canonical✓

Publishers can supply whatever means of contact they so desire, including P.O boxes and carrier pigeons.
The first result in my search engine of choice for " DrCoccodrillus" is their gitHub page
The first repo in their pinned repos is the one you need
image1383×459 102 KB

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.

Best regards

Daniel

Edit: spelling

dhd · May 2, 2024, 1:42pm

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.

James-Carroll · May 2, 2024, 2:52pm

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.

popey · May 2, 2024, 3:02pm

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/

But OP wasn’t to know that.

James-Carroll · May 2, 2024, 3:04pm

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.

popey · May 2, 2024, 3:08pm

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.

sigh.

dhd · May 2, 2024, 3:39pm

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).

James-Carroll · May 2, 2024, 3:43pm

For the snap info command, it looks like we’d just want to remove the verbose check here:

github.com

snapcore/snapd/blob/fe6e39a2bc9d5107a329eb967caf4a2d9c843ccf/cmd/snap/cmd_info.go#L389


      
          		return
          	}
          	fmt.Fprintf(iw, "build-date:\t%s\n", iw.fmtTime(buildDate))
          }
          
          func (iw *infoWriter) maybePrintLinks() {
          	contact := strings.TrimPrefix(iw.theSnap.Contact, "mailto:")
          	if contact != "" {
          		fmt.Fprintf(iw, "contact:\t%s\n", contact)
          	}
          	if !iw.verbose || len(iw.theSnap.Links) == 0 {
          		return
          	}
          	links := iw.theSnap.Links
          	fmt.Fprintln(iw, "links:")
          	linkKeys := make([]string, 0, len(iw.theSnap.Links))
          	for k := range links {
          		linkKeys = append(linkKeys, k)
          	}
          	sort.Strings(linkKeys)
          	for _, k := range linkKeys {

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.

popey · May 2, 2024, 3:47pm

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!

James-Carroll · May 2, 2024, 3:53pm

I’ve officially raised the --verbose aspect here so I’ll leave it a few days to get some opinions from the core developers

DWD · May 2, 2024, 5:25pm

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.

drcoccodrillus · May 3, 2024, 5:58am

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.

popey · May 3, 2024, 9:20am

Hey @drcoccodrillus - thanks for popping up!

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.

drcoccodrillus · May 3, 2024, 3:36pm

Thank you very much, @popey

I will take what you say as a starting point and work on it

James-Carroll · May 21, 2024, 1:53am

There’s been no feedback on the Launchpad page but I’ve proposed a PR for this:

https://github.com/snapcore/snapd/pull/13983