[arch-general] Upstream urls and package descriptions
Intro: Below are some questions / ideas I came up with. I simply don't know if anyone cares about these issues, whether there are rules or at least suggestions how to best deal with them or is it up to the maintainer. I've heard there were some plans wrt a build server that would periodically check if packages still build. Any news? If there indeed are issues that need fixing, should I file the low-priority bugs now? Summer vacation may not be the best time for Arch-related work so maybe I should wait until September so that people are back from holidays? Upstream urls: I found that dozens of packages in the repos have an upstream url that prints 'Page Not Found' in one way or another. Should I open bug reports for these packages or does nobody care about it? I could also check if the source is still available. If opening bug reports is OK, should I limit creating the reports to e.g. 10 a day? If I find a url that works, I will include it as a suggestion for the maintainer. For example for https://www.archlinux.org/packages/community/i686/autocutsel/ neither the url nor the source is available, but I found what seems like a perfectly good autocutsel website: http://www.nongnu.org/autocutsel/ with a link to the source. Some projects seem to be gone for good e.g. https://www.archlinux.org/packages/extra/i686/apricots/ even grabs the sources from ftp.archlinux.org https://projects.archlinux.org/svntogit/packages.git/plain/trunk/PKGBUILD?h=... Would http://freecode.com/projects/apricots be a better website? It has some info e.g. that last development is from a decade ago, a screenshot, a longer description ... What about urls that point to a redirect? Is it OK only if the redirect is automatic and otherwise upstream urls should be updated if they moved e.g. from SourceForge to GoogleCode? An example: https://www.archlinux.org/packages/extra/any/junit/ has http://junit.sourceforge.net/ as the upstream url, but when you go there, it says 'Please see our main site at junit.org'. Is there a rule that 'www' should be omitted or that it should be included? https://www.archlinux.org/packages/extra/i686/alsa-lib/ : http://www.alsa-project.org https://www.archlinux.org/packages/extra/any/alsa-firmware/ : http://alsa-project.org/ What about the slash at the end of the url? Sometimes the slash makes a difference: https://www.archlinux.org/packages/community/i686/pidgin-toobars/ uses http://vayurik.ru/wordpress/en/toobars/ and shows (via a redirect) the Russian version http://vayurik.ru/wordpress/toobars while the English version demands no slash at the end of the url: http://vayurik.ru/wordpress/en/toobars The same upstream url can be used by many packages and standardizing would make it a bit easier to find which packages need to have the upstream url updated. Are upstream urls mandatory? https://www.archlinux.org/packages/extra/any/hwdetect/ does not have one. Package descriptions: There was an attempt at improving the descriptions last year, but it didn't go so well https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/bitcoin&id=bd4647fb433c517c03fb08f869944dc987372a69 I don't know if maintainers should write package descriptions or should they just take them from upstream, but IMHO e.g. https://www.archlinux.org/packages/extra/i686/kdeplasma-addons-wallpapers-vi... : 'Description: Virus' has to go. Even https://www.archlinux.org/packages/extra/i686/kdeplasma-addons-wallpapers-we... - Weather or https://www.archlinux.org/packages/extra/i686/kdetoys-ktux/ - KTux are pretty bad descriptions. Quite a few descriptions could be more informative, but I don't know if anyone cares about it e.g. description for https://www.archlinux.org/packages/extra/i686/kdeutils-ktimer/ says 'Countdown Launcher' and is IMHO too terse. Should I suggest changing it upstream, will the maintainer change it to a more descriptive one or is it considered just pointless churn? Similarly, https://www.archlinux.org/packages/extra/i686/kdeplasma-addons-applets-calcu... could be described as e.g. 'A simple calculator' instead of the current 'Calculate simple sums'. Is adding 'data files' phrase to descriptions of packages that provide architecture-independent data recommended? I've noticed many packages share the same description, usually because it's a generic one: monica - A monitor calibration tool kdegraphics-kgamma - A monitor calibration tool or because the packages represent different version of e.g. the same toolkit: qt3 - A cross-platform application and UI framework qt4 - A cross-platform application and UI framework Sometimes the descriptions explicitly says it's a python2 thing: python2-atspi - Python 2 bindings for at-spi python2-dbus - Python 2.7 bindings for DBUS Some language-related packages use the same description for all of them e.g. xpdf-korean - Encoding information to use specific character sets in Xpdf; does not include fonts vim-spell-af - Language files for Vim spell checking Other packages, like firefox-i18n-* or libreoffice-* adjusted the description for each package: firefox-i18n-af - Afrikaans language pack for Firefox libreoffice-af - Afrikaans language pack for LibreOffice Is one way preferred over the other or is it up to the maintainer? Should language files always have a description that says which language do they represent or are package names enough? I also found https://www.archlinux.org/packages/extra/any/libreoffice-sid/ - ??? language pack for LibreOffice https://www.archlinux.org/packages/extra/any/libreoffice-tt/ - TT ? language pack for LibreOffice What's this?
On Thu, Aug 1, 2013 at 6:02 PM, Karol Blazewicz <karol.blazewicz@gmail.com>wrote:
I also found https://www.archlinux.org/packages/extra/any/libreoffice-sid/ - ??? language pack for LibreOffice https://www.archlinux.org/packages/extra/any/libreoffice-tt/ - TT ? language pack for LibreOffice
What's this?
I've checked it out of curiosity and it looks like TT is Tatar [1] and Sid is Sidama [2]. [1] https://en.wikipedia.org/wiki/Tatar_language [2] http://en.wikipedia.org/wiki/Sidama_language
Am 01.08.2013 18:02, schrieb Karol Blazewicz:
Upstream urls: I found that dozens of packages in the repos have an upstream url that prints 'Page Not Found' in one way or another. Should I open bug reports for these packages or does nobody care about it? I could also check if the source is still available. If opening bug reports is OK, should I limit creating the reports to e.g. 10 a day? If I find a url that works, I will include it as a suggestion for the maintainer.
Creating bug reports is the way to go here. It actually doesn't matter how many you create, the maintainers will fix them when they fix them.
On Thu, Aug 1, 2013 at 6:37 PM, Rodrigo Rivas <rodrigorivascosta@gmail.com> wrote:
On Thu, Aug 1, 2013 at 6:02 PM, Karol Blazewicz <karol.blazewicz@gmail.com>wrote:
I also found https://www.archlinux.org/packages/extra/any/libreoffice-sid/ - ??? language pack for LibreOffice https://www.archlinux.org/packages/extra/any/libreoffice-tt/ - TT ? language pack for LibreOffice
What's this?
I've checked it out of curiosity and it looks like TT is Tatar [1] and Sid is Sidama [2].
[1] https://en.wikipedia.org/wiki/Tatar_language [2] http://en.wikipedia.org/wiki/Sidama_language
Yup :-) http://en.wikipedia.org/wiki/ISO_639-3 helps decipher language codes. On Thu, Aug 1, 2013 at 7:41 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 01.08.2013 18:02, schrieb Karol Blazewicz:
Upstream urls: I found that dozens of packages in the repos have an upstream url that prints 'Page Not Found' in one way or another. Should I open bug reports for these packages or does nobody care about it? I could also check if the source is still available. If opening bug reports is OK, should I limit creating the reports to e.g. 10 a day? If I find a url that works, I will include it as a suggestion for the maintainer.
Creating bug reports is the way to go here.
OK. Should I open a single report for the base package e.g. libreoffice-i18n and list which split packages need to be fixed or open a report for each split libreoffice-* package?
It actually doesn't matter how many you create, the maintainers will fix them when they fix them.
Sure. It's hard not to spam the bugtracker RSS feed since it provides only 10 or 15 last reports - no idea if anyone cares anyway :-)
On Thu, Aug 1, 2013 at 1:23 PM, Karol Blazewicz <karol.blazewicz@gmail.com>wrote:
On Thu, Aug 1, 2013 at 6:37 PM, Rodrigo Rivas <rodrigorivascosta@gmail.com> wrote:
On Thu, Aug 1, 2013 at 6:02 PM, Karol Blazewicz <karol.blazewicz@gmail.com>wrote:
I also found https://www.archlinux.org/packages/extra/any/libreoffice-sid/ - ??? language pack for LibreOffice https://www.archlinux.org/packages/extra/any/libreoffice-tt/ - TT ? language pack for LibreOffice
What's this?
I've checked it out of curiosity and it looks like TT is Tatar [1] and Sid is Sidama [2].
[1] https://en.wikipedia.org/wiki/Tatar_language [2] http://en.wikipedia.org/wiki/Sidama_language
Yup :-) http://en.wikipedia.org/wiki/ISO_639-3 helps decipher language codes.
On Thu, Aug 1, 2013 at 7:41 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 01.08.2013 18:02, schrieb Karol Blazewicz:
Upstream urls: I found that dozens of packages in the repos have an upstream url that prints 'Page Not Found' in one way or another. Should I open bug reports for these packages or does nobody care about it? I could also check if the source is still available. If opening bug reports is OK, should I limit creating the reports to e.g. 10 a day? If I find a url that works, I will include it as a suggestion for the maintainer.
Creating bug reports is the way to go here.
OK. Should I open a single report for the base package e.g. libreoffice-i18n and list which split packages need to be fixed or open a report for each split libreoffice-* package?
It actually doesn't matter how many you create, the maintainers will fix them when they fix them.
Sure. It's hard not to spam the bugtracker RSS feed since it provides only 10 or 15 last reports - no idea if anyone cares anyway :-)
The best way might be to follow Allan's suggestions on how to contribute to Arch Linux. http://allanmcrae.com/2013/05/ways-to-contribute-to-arch-linux/ His suggestion about fixing bugs on the bug tracker also applies to filing new bugs. If you've found the issue, file a bug and provide a patch for the solution. Myra -- Life's fun when your sick and psychotic!
On Thu, Aug 1, 2013 at 11:02 PM, Myra Nelson <myra.nelson@hughes.net> wrote:
The best way might be to follow Allan's suggestions on how to contribute to Arch Linux.
http://allanmcrae.com/2013/05/ways-to-contribute-to-arch-linux/
His suggestion about fixing bugs on the bug tracker also applies to filing new bugs. If you've found the issue, file a bug and provide a patch for the solution.
Myra
Yup, I've read that post. I prefer to ask on the ML before filing dozens of bug reports. I'm still a noob and therefore I ask questions, like what exactly can be considered a bug, should I file a bug per package or per pkgbase etc. I haven't seen any guide that explains it, so I've come to the ML.
-- Life's fun when your sick and psychotic!
Oh yeah! :P
[2013-08-01 20:23:18 +0200] Karol Blazewicz:
Should I open a single report for the base package e.g. libreoffice-i18n and list which split packages need to be fixed or open a report for each split libreoffice-* package?
One report per pkgbase is good. -- Gaetan
Hi, 2013/8/1 Karol Blazewicz <karol.blazewicz@gmail.com>:
Package descriptions: There was an attempt at improving the descriptions last year, but it didn't go so well https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/bitcoin&id=bd4647fb433c517c03fb08f869944dc987372a69
In my opinion, the changes themselves were successful, but the changes were not well received. For me, it was instructive in learning about which processes should be used in the future. Just to single out the change you linked to, I think: pkgdesc='Peer-to-peer network based digital currency - QT' is a clear improvement over: pkgdesc="Bitcoin is a peer-to-peer network based digital currency - QT" After the changes were reverted, nothing more happened with this. As far as I can remember, Angel wished to see the script, I gave him a copy and he had an idea for a way forward. I guess one possibility is to write a patch for namcap, makepkg or pacman, or possibly write a general utility for formatting PKGBUILDs (like "go fmt" does for Go source code). The opportunities for PKGBUILD formatting are endless. Since it's really just bash scripting, I doubt a tool for formatting PKGBUILD files will be able to be *exact* and *precise* until a declarative package format appears in the far future, if that should happen (and if that should turn out to be a better way). In any case, package maintainers can look at the svn log if they wish to pull in the reverted change to the pkgdesc. -- Sincerely, Alexander Rødseth xyproto / TU
On Fri, Aug 2, 2013 at 12:28 AM, Alexander Rødseth <rodseth@gmail.com> wrote:
Hi,
2013/8/1 Karol Blazewicz <karol.blazewicz@gmail.com>:
Package descriptions: There was an attempt at improving the descriptions last year, but it didn't go so well https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/bitcoin&id=bd4647fb433c517c03fb08f869944dc987372a69
In my opinion, the changes themselves were successful, but the changes were not well received.
That's what I meant, sorry if I haven't made it clear.
For me, it was instructive in learning about which processes should be used in the future.
Just to single out the change you linked to, I think:
pkgdesc='Peer-to-peer network based digital currency - QT'
is a clear improvement over:
pkgdesc="Bitcoin is a peer-to-peer network based digital currency - QT"
I agree that this change was clearly for the better, but there had be some kind of disagreement since the commits have been mass reversed. I'm trying to gently prod Arch Overlords so at least I (we?) know what kind of changes have a chance of being accepted.
On 02/08/13 02:02, Karol Blazewicz wrote:
Intro: Below are some questions / ideas I came up with. I simply don't know if anyone cares about these issues, whether there are rules or at least suggestions how to best deal with them or is it up to the maintainer.
I've heard there were some plans wrt a build server that would periodically check if packages still build. Any news?
I see I have just received word that a proof-of-concept for the idea is available. So there is some progress.
If there indeed are issues that need fixing, should I file the low-priority bugs now? Summer vacation may not be the best time for Arch-related work so maybe I should wait until September so that people are back from holidays?
I'm fairly sure summer holidays are in the end of December/start of January, so that should not be an issue! :D
Upstream urls: I found that dozens of packages in the repos have an upstream url that prints 'Page Not Found' in one way or another. Should I open bug reports for these packages or does nobody care about it? I could also check if the source is still available. If opening bug reports is OK, should I limit creating the reports to e.g. 10 a day? If I find a url that works, I will include it as a suggestion for the maintainer.
If there are bugs, open bugs. The bug tracker is for tracking bugs... It does not matter how many are opened. Even better if you provide a solution in the bug. We can close bugs far quicker than you can create them, so that will never be a real issue.
For example for https://www.archlinux.org/packages/community/i686/autocutsel/ neither the url nor the source is available, but I found what seems like a perfectly good autocutsel website: http://www.nongnu.org/autocutsel/ with a link to the source.
File a bug.
Some projects seem to be gone for good e.g. https://www.archlinux.org/packages/extra/i686/apricots/ even grabs the sources from ftp.archlinux.org https://projects.archlinux.org/svntogit/packages.git/plain/trunk/PKGBUILD?h=... Would http://freecode.com/projects/apricots be a better website? It has some info e.g. that last development is from a decade ago, a screenshot, a longer description ...
I'd say such packages should just be dropped altogether.
What about urls that point to a redirect? Is it OK only if the redirect is automatic and otherwise upstream urls should be updated if they moved e.g. from SourceForge to GoogleCode? An example: https://www.archlinux.org/packages/extra/any/junit/ has http://junit.sourceforge.net/ as the upstream url, but when you go there, it says 'Please see our main site at junit.org'.
Even an automatic redirect might not be permanent, so I think these should be changed.
Is there a rule that 'www' should be omitted or that it should be included? https://www.archlinux.org/packages/extra/i686/alsa-lib/ : http://www.alsa-project.org https://www.archlinux.org/packages/extra/any/alsa-firmware/ : http://alsa-project.org/
If both are correct, it does not matter. About here I got bored...
[2013-08-01 18:02:38 +0200] Karol Blazewicz:
The same upstream url can be used by many packages and standardizing would make it a bit easier to find which packages need to have the upstream url updated.
That is just not feasible. As you noticed yourself: sometimes, a www prefix and/or slash suffix to a URL are required, sometimes not. Certain upstream projects have several websites; others use a language different from English on their main page, but have an English subpage available (what page would you link to then?), etc.
I don't know if maintainers should write package descriptions or should they just take them from upstream, but IMHO e.g. https://www.archlinux.org/packages/extra/i686/kdeplasma-addons-wallpapers-vi... : 'Description: Virus' has to go.
For this and everything else that follows, please open separate bug reports or feature requests in our tracker - except for:
Some language-related packages use the same description for all of them e.g. xpdf-korean - Encoding information to use specific character sets in Xpdf; does not include fonts vim-spell-af - Language files for Vim spell checking
That's fine to me (obviously, I maintain them): they're split packages that all do the same thing and I do not think the redundant description causes any confusion of what package is meant for what language...
Should language files always have a description that says which language do they represent or are package names enough?
Just calm down. Anything that makes sense is fine. :) -- Gaetan
participants (7)
-
Alexander Rødseth
-
Allan McRae
-
Gaetan Bisson
-
Karol Blazewicz
-
Myra Nelson
-
Rodrigo Rivas
-
Thomas Bächler