bug#38422: .png files in /gnu/store with executable permissions (555)

[Bengt Richter <bokr@bokr.com>]

On +2019-11-30 08:45:09 +0100, Julien Lepiller wrote:
> Le 30 novembre 2019 05:08:55 GMT+01:00, Mark H Weaver <mhw@netris.org> a écrit :
> >Hi Bengt,
> >
> >Bengt Richter <bokr@bokr.com> writes:
> >
> >> On +2019-11-29 07:20:41 -0500, Mark H Weaver wrote:
> >>> The proper solution is to send bug reports to the upstream
> >developers of
> >>> docbook-xsl, faba-icon-theme, and moka-icon-theme, asking them to
> >fix
> >>> the permissions of the *.png files in their source tarballs.
> >>>
> >> That I haven't done. Is there a standard way to do it?
> >
> >No.
> >
> >> "guix show moka-icon-theme" tells me homepage, but it would be nice
> >> to have a guix show --verbose that would show bug reporting info :)
> >
┌───────────────────────────────────────────────────────────────────────┐
│ > >It would be nice, but it would also be an enormous amount of work. │
└───────────────────────────────────────────────────────────────────────┘
> >First we'd need to devise a way to represent that information, and then
> >we'd need to add it to each of our 10K+ packages.  It would also be an
> >additional job to do when adding new packages.  I'm not sure it's worth
> >all that work.  We already record the home page, and from there it's
> >usually not much work to find how to report bugs.  In cases where it
> >_is_ difficult to find out how to report bugs, that's arguably a
> >problem
> >that should be fixed upstream.
> >
┌──────────────────────────┐
│ I think you are right :) │
├──────────────────────────┤
│ > >What do you think?    │
│ > >                      │
│ > >      Regards,        │
│ > >        Mark          │
└──────────────────────────┘
> 
┌──────────────────────────────────────────────────────────────┐
│  I think you are also right -- I withdraw my suggestion :)   │
├──────────────────────────────────────────────────────────────┤
│ > Also, we should not encourage people to report bugs        │
│ upstream directly. We have to evaluate whether the bug is on │
│ our side or theirs first to not drown them in useless bug    │
│ reports :)                                                   │
└──────────────────────────────────────────────────────────────┘

Hm, this seems like it could be important for good relations with upstream?

Should there be an official _distilled and filtered-for-upstream_
git bug repo that guix developers populate and upstream devs
(and anyone) can pull and grep the log of for their projects?

I could imagine (hallucinate ? :) some benfits:

1. First of all, we can all determine easily if there has been
   an "official" report from guix to upstream, to avoid even bothering
   guix developers.
2. If upstream devs know reports have been considered important enough
   by guix developers to be put in the repo, they might pay more attention :)
   There is a lot of tl;dr discussion in many bug-reporting logs, so upstream
   would probably appreciate having curated reports.
3. The log would be a record. Commit hashes would become precise references.
4. To keep the main bug info stream clear of speculative chatty stuff
   (though this sometimes contains critical clues, and belongs somewhere)
   the repo could contain (per major upstream?) files for commentary or
   miscellaneous that guix devs might want to pass on, but not clutter
   the main report with. Of course urls into bugzilla etc can be useful
   as concise see-further refs. All misc stuff optional.
4. The work flow for developers already exists for accepting things
   into the guix package repo, so no major new patterns for everyone to learn.
5. Anyone interested could clone the repo and pull to it for "guix-official"
   bug reporting status.   

WDYT?
-- 
Regards,
Bengt Richter