- Aur-dev - lists.archlinux.org

Re: [aur-dev] [aur-general] AurJson - orphan packages
by Gergely Imreh 17 Sep '09

17 Sep '09

2009/9/14 Pierre Chapuis <catwell(a)archlinux.us>: > Le Sun, 13 Sep 2009 18:23:02 +0200, > Pierre Chapuis <catwell(a)archlinux.us> a écrit : > >> Hi, >> >> I was wondering if there's a way to know if a package is orphan using the AurJson interface. >> >> If that's not the case, I think I will find a feature request for something like: >> >> "Uploader":"pseudonym" >> >> in "info/results", with "pseudonym" set as "orphan" if the package is orphan (I hope nobody has taken the pseudonym "orphan" on AUR...). >> >> Does that look fine to you? > > Of course I meant: "I will file a feature request"... > > Another possibility might be to add a boolean like OutOfDate, but the solution I proposed would also enable scripts to find the uploader of a package, which might be useful later. As far as I'm concerned, I don't really care since I only want to know if the package is orphan... I'm CC-ing this to the aur-dev, as I think it belongs there. The following patch adds the Orphan field to the aurjson output. For username we would need to hit the database once more (maybe, have to think more SQL for that), but the Orphan-ness is quite straightforward to evaluate. So let's just do that first. This patch, however, might clash with one patch I sent in a few days ago [1], since that one hasn't been applied to the repo, yet. Anyway, neither of those are hard to see where they should go... Any comments? Cheers, Greg [1] http://mailman.archlinux.org/pipermail/aur-dev/2009-September/000868.html >From 2aba57717cac80f643886b25900c8d7ad14e9198 Mon Sep 17 00:00:00 2001 From: Gergely Imreh <imrehg(a)gmail.com> Date: Mon, 14 Sep 2009 22:28:58 +0800 Subject: [PATCH] aurjson: add "Orphan" boolean field to JSON output Signed-off-by: Gergely Imreh <imrehg(a)gmail.com> --- web/lib/aurjson.class.php | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/web/lib/aurjson.class.php b/web/lib/aurjson.class.php index 29fc424..85a3b89 100644 --- a/web/lib/aurjson.class.php +++ b/web/lib/aurjson.class.php @@ -19,8 +19,9 @@ include_once("aur.inc"); class AurJSON { private $dbh = false; private $exposed_methods = array('search','info'); - private $fields = array('ID','Name','Version','CategoryID','Description', - 'LocationID', 'URL','URLPath','License','NumVotes','OutOfDate'); + private $fields = array('ID','Name','Version','MaintainerUID','CategoryID', + 'Description','LocationID', 'URL','URLPath','License','NumVotes', + 'OutOfDate'); /** * Handles post data, and routes the request. @@ -139,6 +140,8 @@ class AurJSON { if ( $result && (mysql_num_rows($result) > 0) ) { $row = mysql_fetch_assoc($result); mysql_free_result($result); + $row['Orphan'] = ($row['MaintainerUID'] == "0" ? "1" : "0"); + unset($row['MaintainerUID']); return $this->json_results('info', $row); } else { -- 1.6.4.2

3 11

[aur-dev] [PATCH] Fix: FS#15526 non-UTF8 character in rpc output
by Gergely Imreh 14 Sep '09

14 Sep '09

Currently AUR does not check the uploaded packages, whether they are correctly in UTF8 encoding. If there are fields (such as $pkgdesc) that contain such non-UTF8 characters, the rpc interface chokes on those fields: even if there's data successfully retrieved from the database, rpc returns "null". In an effort to make such errors in the PKGBUILDs debugged more easily, let's force rpc to have more useful output: try to convert non-UTF8 fields to UTF8. If it's a success, good. Partial success (some characters showing as \uXXXX) is ok. Failure results in error message printed to that field. Signed-off-by: Gergely Imreh <imrehg(a)gmail.com> --- web/lib/aurjson.class.php | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/web/lib/aurjson.class.php b/web/lib/aurjson.class.php index 29fc424..3482a79 100644 --- a/web/lib/aurjson.class.php +++ b/web/lib/aurjson.class.php @@ -139,6 +139,15 @@ class AurJSON { if ( $result && (mysql_num_rows($result) > 0) ) { $row = mysql_fetch_assoc($result); mysql_free_result($result); + foreach($row as $name => $value) { + $converted = utf8_encode($value); + if ($converted) { + $row[$name] = $converted; + } + else { + $row[$name] = "[PKGBUILD error: non-UTF8 character]"; + } + } return $this->json_results('info', $row); } else { -- 1.6.4.2

2 1

[aur-dev] [PATCH] Hungarian translation
by Gergely Imreh 09 Sep '09

09 Sep '09

Hi, I just noticed a commit in AUR adding Hungarian translation ( 56990b3748df8ed3a38b6f2566ab297902749942 ) Is there any reason why it wasn't sent to the mailing list first? (Or did I just miss it?) The reason I'm asking is that I think there are a few problems with it. The major issue is that the translation omits all the accents we have in the Hungarian language. Thus it is not really "Hungarian", but a "Hungarian typing on an English keyboard". It's acceptable when writing emails, but there's no reason whatsoever to have it on a website. Also, there were a number of mistranslations. Lastly, almost all periods were missing at the end of sentences which had periods in the original version. This is minor, I know, but again, there's no hurry, one can punctuate properly for a website. So I attach a fixed version. Checked a few times, but I don't claim it does not have any translation issues. If there are other Hungarians on the list to comment on it, I'd be glad to hear. Cheers, Greg

5 10

[aur-dev] Putting php 5.3 into [testing]?
by Pierre Schmitz 05 Sep '09

05 Sep '09

Hi all, are thee any big rebuilds planned? Otherwise I would like to put version 5.3 of PHP into testing. There is still an issue with suhosin but this way people would have more time to check their scripts. We should also make sure that our Scripts (like AUR) work with the new PHP version. I could help here if there are problems. The good thing is that we don't provide packages with php scripts; so from our side everything is fine. ;-) But seriously: this version has great potential to break lots of especially very old PHP scripts. Pierre -- Pierre Schmitz, http://users.archlinux.de/~pierre

3 4

[aur-dev] Te agregué como amigo en Facebook
by Benjamin Martinez Velasco 30 Aug '09

30 Aug '09

Hola, aur-dev(a)archlinux.org: He creado un perfil en Facebook donde puedo publicar mis fotos, vídeos y eventos, y quiero agregarte a mis amigos para que puedas verlo. Para ello, necesitas registrarte en Facebook y, después, podrás crear también tu propio perfil. Gracias, Benjamin Para registrarte en Facebook, sigue este enlace: http://www.facebook.com/p.php?i=725936631&k=341UZXQXTT6G6BD1SB36TTWSV&r aur-dev(a)archlinux.org ha sido invitado(a) a unirse a Facebook por Benjamin Martinez Velasco. Si no quieres recibir este tipo de mensajes de Facebook, haz clic en el enlace siguiente para borrar tu nombre de la lista de personas suscritas. http://www.facebook.com/o.php?k=02ad7a&u=100000203350605&mid=1026ec3G5af31c… Las oficinas de Facebook están en 1601 S. California Ave., Palo Alto, CA 94304.

2 1

[aur-dev] FS#15043: patch for part 3 - package licenses link to Arch Wiki pages
by Gergely Imreh 27 Aug '09

27 Aug '09

Hi, There is a feature request (FS#15043) for multiple package parsing enhancements on AUR. One of them (part 3) asks for "arch and license arrays can be converted to links [to Arch Wiki]". I checked out the "license" part, as I see the arch is not displayed on AUR at the moment. Linking to common licenses might be an useful idea, so here's a patch that does just that. Good code should speak for itself, but maybe I do elaborate a little: - I took the common licenses distributed in /usr/share/licenses/common and uploaded them to the Wiki as Licenses:NAME. - The code checks for these names in the licenses array, and if there's any match, turns it into a link. If no match, just display it as text. - Can handle multiple licenses in case needed. I can see some problems arise, though. I took the names of these licenses exactly as it is in the directory, and that includes capitalisation. E.g. "APACHE" and "PerlArtistic". Could match the names case-insensitive, but that's a bad idea since the Wiki link is case-sensitive... Thus, if some people use wrong capitalisation in their PKGBUILD (like [1]) and complain that the link "does not work 0rz", then it is the reason... Namcap's check for licenses is case-insensitive, so that's no help to prevent such problems. Anyway, here it is, let me know if there's any issue with the way things are handled, or any other functionality that should be included. Cheers, Greg Ps: I sent this out once before with the patch .gz attached, which seemed to disappear. If later gets sent out, then my apologies.. [1] http://aur.archlinux.org/packages.php?ID=27609 >From 7c7c6b13c6cc2dac0ac4b6ea958dfcf1483a2117 Mon Sep 17 00:00:00 2001 From: Gergely Imreh <imrehg(a)gmail.com> Date: Sun, 16 Aug 2009 15:19:41 +0800 Subject: [PATCH] add wiki link to common licenses in package details The package licenses turned into wiki links in case of common licenses (the ones that are already in /usr/share/licenses/common). Currently the license name has to be the same as in the directory (same case too). Not common licenses left alone and displayed as text. Can handle multiple licenses in the rare case it is needed. Signed-off-by: Gergely Imreh <imrehg(a)gmail.com> --- web/template/pkg_details.php | 28 +++++++++++++++++++++++++++- 1 files changed, 27 insertions(+), 1 deletions(-) diff --git a/web/template/pkg_details.php b/web/template/pkg_details.php index e87fc01..4fed861 100644 --- a/web/template/pkg_details.php +++ b/web/template/pkg_details.php @@ -28,9 +28,35 @@ if ($atype == "Developer" or $atype == "Trusted User") { $votes = "<a href=\"voters.php?ID=$pkgid\">$votes</a>"; } +# License # In case of wanting to put a custom message $msg = __('unknown'); -$license = empty($row['License']) ? $msg : $row['License']; +if (empty($row['License'])) { + $license = $msg; +} +else { + $common_licenses = array('APACHE', 'CCPL:by', 'CCPL:by-nc', \\ + 'CCPL:by-nc-nd', 'CCPL:by-nc-sa', 'CCPL:by-nd', 'CCPL:by-sa', \\ + 'CDDL', 'CPL', 'EPL', 'FDL', 'FDL1.2', 'FDL1.3', 'GPL', 'GPL2', \\ + 'GPL3', 'LGPL', 'LGPL2.1', 'LGPL3', 'LPPL', 'MPL', 'PHP', 'PSF', \\ + 'PerlArtistic', 'RALINK', 'RUBY', 'ZPL'); + $license_linkbase = "http://wiki.archlinux.org/index.php/Licenses:"; + + # In case the package is under more than one license + $licenses = explode(" ", $row['License']); + $license = ''; + foreach ($licenses as $pkglicense) { + if (in_array($pkglicense,$common_licenses)) { + # replace ":" in the wiki links as it has meaning for the wiki + $wikilink = str_replace(":", "-", $pkglicense); + $license .= '<a href="' . $license_linkbase . $wikilink \\ + . '" target=_blank>'. $pkglicense . '</a> '; + } + else { + $license .= $pkglicense . ' '; + } + } +} # Print the timestamps for last updates $updated_time = ($row["ModifiedTS"] == 0) ? "(unknown)" : gmdate("r", intval($row["ModifiedTS"])); -- 1.6.4

2 3

[aur-dev] [patch] remove community from web
by Sergej Pupykin 26 Aug '09

26 Aug '09

Hi, this patch removes community references from aur web.

2 1

[aur-dev] FS#15043: patch for part 3 - package licenses link to Arch Wiki pages
by Gergely Imreh 16 Aug '09

16 Aug '09

Hi, There is a feature request (FS#15043) for multiple package parsing enhancements on AUR. One of them (part 3) asks for "arch and license arrays can be converted to links [to Arch Wiki]". I checked out the "license" part, as I see the arch is not displayed on AUR at the moment. Linking to common licenses might be an useful idea, so here's a patch that does just that. Good code should speak for itself, but maybe I do elaborate a little: - I took the common licenses distributed in /usr/share/licenses/common and uploaded them to the Wiki as Licenses:NAME. - The code checks for these names in the licenses array, and if there's any match, turns it into a link. If no match, just display it as text. - Can handle multiple licenses in case needed. I can see some problems arise, though. I took the names of these licenses exactly as it is in the directory, and that includes capitalisation. E.g. "APACHE" and "PerlArtistic". Could match the names case-insensitive, but that's a bad idea since the Wiki link is case-sensitive... Thus, if some people use wrong capitalisation in their PKGBUILD (like [1]) and complain that the link "does not work 0rz", then it is the reason... Namcap's check for licenses is case-insensitive, so that's no help to prevent such problems. Anyway, here it is, let me know if there's any issue with the way things are handled, or any other functionality that should be included. Cheers, Greg [1] http://aur.archlinux.org/packages.php?ID=27609

1 0

[aur-dev] [PATCH 1/3] rpc: small optimizations
by Dan McGee 07 Aug '09

07 Aug '09

Signed-off-by: Dan McGee <dan(a)archlinux.org> --- web/html/rpc.php | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/web/html/rpc.php b/web/html/rpc.php index f94d5bc..dc3d20b 100644 --- a/web/html/rpc.php +++ b/web/html/rpc.php @@ -1,13 +1,13 @@ <?php -set_include_path(get_include_path() . PATH_SEPARATOR . '../lib' . PATH_SEPARATOR . '../lang'); +set_include_path(get_include_path() . PATH_SEPARATOR . '../lib'); include("aur.inc"); include("aurjson.class.php"); -$rpc_o = new AurJSON(); if ( $_SERVER['REQUEST_METHOD'] == 'GET' ) { if ( isset($_GET['type']) ) { + $rpc_o = new AurJSON(); echo $rpc_o->handle($_GET); } else { -- 1.6.4

1 1

[aur-dev] PKGBUILD parsing on the AUR
by Xyne 03 Aug '09

03 Aug '09

Hi, I'm hoping someone could answer these questions: How does the AUR parse uploaded PKGBUILDs? How does it handle PKGBUILDs with if-then-else statements? E.g. depends=('foo' 'baz') [ "$(uname -m)" == 'x86_64' ] && depends=('lib32-foo' 'lib32-baz') How could I help implement this?: http://bugs.archlinux.org/task/15728 Thanks, Xyne

3 6