After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 779813 - flatpakref files aren't downloaded from git.gnome.org
flatpakref files aren't downloaded from git.gnome.org
Status: RESOLVED FIXED
Product: sysadmin
Classification: Infrastructure
Component: Git
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GNOME Sysadmins
GNOME Sysadmins
Depends on:
Blocks:
 
 
Reported: 2017-03-09 16:59 UTC by Allan Day
Modified: 2017-03-13 18:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Allan Day 2017-03-09 16:59:42 UTC
.flatpakref files are being hosted on git.gnome.org, with the idea that users can click a download link and have them downloaded from there. Unfortunately, these files are being opened in the browser, rather than being downloaded.

This leaves users in a confusing position - instead of getting something they can install, they get a page with some text on it.

For an example link, see the Builder "Download" button on http://flatpak.org/apps.html .

Would it be possible to configure cgit so that .flatpakref files get downloaded?
Comment 1 Olav Vitters 2017-03-09 18:46:34 UTC
Added the mime type handles for .flatpak, .flatpakref and .flatpakrepo.

https://infrastructure.gnome.org/browse/puppet/commit/?id=054d1d7990257710317586682491e27e20b89b02

Might take 20 minutes before it activates.
Comment 2 Olav Vitters 2017-03-09 19:31:19 UTC
https://git.zx2c4.com/cgit/tree/ui-plain.c#n44

cgit has code disallowing this. ugh.
Comment 3 Allan Day 2017-03-10 10:24:03 UTC
Thanks for looking at this, Olav! Is there anything else you can try, or is this a dead-end?
Comment 4 Andrea Veri 2017-03-10 11:46:48 UTC
This should be fixed Allan, please review.
Comment 5 Allan Day 2017-03-10 14:28:00 UTC
It works here indeed. Thanks!
Comment 6 Adrien Plazas 2017-03-13 09:35:12 UTC
Is it me or instead of downloading the .flatparef it downloads the page displaying it.
Comment 7 Adrien Plazas 2017-03-13 09:38:01 UTC
More info: it works with Web but not with Firefox.
Comment 8 Allan Day 2017-03-13 10:19:39 UTC
(In reply to Adrien Plazas from comment #6)
> Is it me or instead of downloading the .flatparef it downloads the page
> displaying it.

Ugh, you're right.
Comment 9 Carlos Soriano 2017-03-13 10:28:51 UTC
fwiw it was working with Builder yesterday, but not now.
Comment 10 Andrea Veri 2017-03-13 10:39:53 UTC
Using a LocationMatch actually applies the rule to the resulting generated page while using a FilesMatch doesn't work either as /browse passes the content serving to a cgi-bin script (cgit.cgi) which handles Content-Type via the cgitrc configuration file which has the limitation Olav mentioned earlier.
Comment 11 Allan Day 2017-03-13 11:35:29 UTC
Let us know if this isn't going to be resolved any time soon, so we know whether we need to do anything about the download links on flatpak.org.
Comment 12 Olav Vitters 2017-03-13 13:34:08 UTC
I think the problem was that to download these files you _have_ to click on the 'plain' link. I've restored behaviour and ensured the download only happens for the plain link.
Comment 13 Allan Day 2017-03-13 16:46:28 UTC
Those links are now taking me to the cgit page for the file - no download and no raw text.
Comment 14 Olav Vitters 2017-03-13 16:57:45 UTC
Because http://flatpak.org/apps.html is entirely wrong. Do an s/tree/plain/.

Correct:
https://git.gnome.org/browse/gnome-apps-nightly/plain/gnome-builder.flatpakref

Not correct:
https://git.gnome.org/browse/gnome-apps-nightly/tree/gedit.flatpakref

Make GNOME great again. Use right link. Not fake link.
Comment 15 Allan Day 2017-03-13 18:56:17 UTC
(In reply to Olav Vitters from comment #14)
...
> Make GNOME great again. Use right link. Not fake link.

Done. Thanks - I hadn't noticed the issue with the links.