[arch-projects] AUR 1.4.0
Version 1.4.0 of the AUR has been released!
This is probably the most exciting version since we launched the AUR.
Thanks to all the hard-working contributors who made this one possible,
especially eliott, tardo, louipc, xilon, and thralas.
Thanks also to our tireless translation team who cleans up after the
messes we make!
And finally, thanks to git-- I'm not sure we would have had such an
amazing release without it. I've taken some time to come around on it,
but it's an awesome tool.
The full changelog is attached from 1.3.1 to 1.4.0. Or you can go look
at the whole thing yourself at:
http://projects.archlinux.org/git/?p=aur.git;a=shortlog
As usual, report all problems here.
- P
commit 22fcea238f0ede3def934c1d8b32935025f22d3c
Author: Paul Mattal
As usual, report all problems here.
The 'Flagged as safe' language string is missing in several language files, including EN, which causes the untranslated text (exactly the same, as it's english) to be displayed red and bold. PT, CA, and ES are incomplete as well (some are lacking more than this single string). Two-line patch at http://ius.student.utwente.nl/cgi-bin/gitweb.cgi?p=aur/.git;a=commitdiff;h=c... Joerie
Joerie de Gram wrote:
As usual, report all problems here.
The 'Flagged as safe' language string is missing in several language files, including EN, which causes the untranslated text (exactly the same, as it's english) to be displayed red and bold.
PT, CA, and ES are incomplete as well (some are lacking more than this single string).
Two-line patch at http://ius.student.utwente.nl/cgi-bin/gitweb.cgi?p=aur/.git;a=commitdiff;h=c...
Thanks. I've cherrypicked this onto the stable branch. We'll release 1.4.1 in a day or so once these sorts of big things shake out. Merging to starting for 1.5.0 in testing. I think we'll plan to do 1.5.0 in about a month, so the merge window will be 2-3 weeks with 1-2 weeks for testing/regressions/translations. - P
Paul Mattal wrote:
Joerie de Gram wrote:
As usual, report all problems here.
The 'Flagged as safe' language string is missing in several language files, including EN, which causes the untranslated text (exactly the same, as it's english) to be displayed red and bold.
PT, CA, and ES are incomplete as well (some are lacking more than this single string).
Two-line patch at http://ius.student.utwente.nl/cgi-bin/gitweb.cgi?p=aur/.git;a=commitdiff;h=c...
Thanks. I've cherrypicked this onto the stable branch. We'll release 1.4.1 in a day or so once these sorts of big things shake out.
Merging to starting for 1.5.0 in testing. I think we'll plan to do 1.5.0 in about a month, so the merge window will be 2-3 weeks with 1-2 weeks for testing/regressions/translations.
- P
_______________________________________________ arch-projects mailing list arch-projects@archlinux.org http://archlinux.org/mailman/listinfo/arch-projects
what's the plan for 1.5.0? any goals? - tardo
On 10/2/07, tardo
what's the plan for 1.5.0? any goals?
I have a few goals. Right now I'm working on account creation/editing. There are a few issues: - a user can willy-nilly change his or her username. (should this be allowed?) - usernames can be ridiculous "hsmnbn3# sd789^# " for example - password can be blank - in fact username can also be blank but that username has already been assigned in the official AUR. Those are the issues I'm going to address with compatibility for old (bad) usernames, etc. I think I'd put a check to prompt a user with a bad username to change it when the go in to edit their account. (And maybe even on login) Also I'd like to move presentation code out of the lib functions and into templates.
Loui wrote:
On 10/2/07, tardo
wrote: what's the plan for 1.5.0? any goals?
I have a few goals. Right now I'm working on account creation/editing.
There are a few issues: - a user can willy-nilly change his or her username. (should this be allowed?) - usernames can be ridiculous "hsmnbn3# sd789^# " for example - password can be blank - in fact username can also be blank but that username has already been assigned in the official AUR.
Those are the issues I'm going to address with compatibility for old (bad) usernames, etc.
I think I'd put a check to prompt a user with a bad username to change it when the go in to edit their account. (And maybe even on login)
Also I'd like to move presentation code out of the lib functions and into templates.
_______________________________________________ arch-projects mailing list arch-projects@archlinux.org http://archlinux.org/mailman/listinfo/arch-projects
Hmm, in that case, I'll try and refactor code from packages.php into two different files. My goals: - Separate code from package.php into pkgsearch.php and pkgdetails.php - pkgsearch will have everything that current package.php has. -- you can search for packages, adopt/flag/disown/vote/notify multiple packages - pkgdetails will be strictly for the package details, including comments - the problem with this is that current programs depend on this, but hopefully an rpc is being worked on - Work on the login timeout issue. I want to eliminate the need for a timeout altogether, as I don't see the point of it. - pkgsubmit process should include the submitter in notify list - package owners shouldn't be allowed to vote. - delete multiple comments at once Dunno if i'll get all this done in 2-3 weeks, but i'll try :x - tardo
On 10/2/07, tardo
Hmm, in that case, I'll try and refactor code from packages.php into two different files.
Keep the package details in packages.php for compatibility, for links to packages to still work for example.
Loui wrote:
On 10/2/07, tardo
wrote: Hmm, in that case, I'll try and refactor code from packages.php into two different files.
Keep the package details in packages.php for compatibility, for links to packages to still work for example.
_______________________________________________ arch-projects mailing list arch-projects@archlinux.org http://archlinux.org/mailman/listinfo/arch-projects
Well packages.php will remain for backwards-compatibility, but I plan to make the changes site-wide so AUR doesn't depend on it at all. I'll update you guys as I progress. - tardo
On 10/3/07, tardo
Well packages.php will remain for backwards-compatibility, but I plan to make the changes site-wide so AUR doesn't depend on it at all. I'll update you guys as I progress.
I mean there's no need to keep any search functionality in packages.php, just make that the details page. eg packages.php?ID=9999 doDetails doesn't make a difference either. Currently if it's set to something 'anything' then it will show package details.
On 10/2/07, Loui
I have a few goals. Right now I'm working on account creation/editing.
There are a few issues: - a user can willy-nilly change his or her username. (should this be allowed?) - usernames can be ridiculous "hsmnbn3# sd789^# " for example - password can be blank - in fact username can also be blank but that username has already been assigned in the official AUR.
Those are the issues I'm going to address with compatibility for old (bad) usernames, etc.
I think I'd put a check to prompt a user with a bad username to change it when the go in to edit their account. (And maybe even on login)
I've done this part. If a user with a bad username tries to edit his/her account they'll be told that their username is invalid and to change it. I decided to continue to allow users to change their username whenever they please for now. Please fetch and let me know what you think. Cheers. http://louipc.dontexist.org/cgi-bin/gitweb.cgi?p=aur/.git;a=commit;h=b73d600...
2007/10/3, Paul Mattal
As usual, report all problems here.
Found a bug in parser. See http://aur.archlinux.org/packages/cheese/cheese/PKGBUILD and how depends are parsed on http://aur.archlinux.org/packages.php?do_Details=1&ID=11879 Can't we use parsepkgbuild from namcap2? See http://projects.archlinux.org/git/?p=namcap.git;a=blob;f=parsepkgbuild;h=68a... This way PKGBUILD is parsed by bash and resulting output is much easier to parse with PHP or Python. -- Roman Kyrylych (Роман Кирилич)
2007/10/3, Roman Kyrylych
2007/10/3, Paul Mattal
: As usual, report all problems here.
Found a bug in parser. See http://aur.archlinux.org/packages/cheese/cheese/PKGBUILD and how depends are parsed on http://aur.archlinux.org/packages.php?do_Details=1&ID=11879
Can't we use parsepkgbuild from namcap2? See http://projects.archlinux.org/git/?p=namcap.git;a=blob;f=parsepkgbuild;h=68a... This way PKGBUILD is parsed by bash and resulting output is much easier to parse with PHP or Python.
Moreover, the > and < are not converted to > and < in output. -- Roman Kyrylych (Роман Кирилич)
2007/10/3, Roman Kyrylych
2007/10/3, Roman Kyrylych
: 2007/10/3, Paul Mattal
: As usual, report all problems here.
Found a bug in parser. See http://aur.archlinux.org/packages/cheese/cheese/PKGBUILD and how depends are parsed on http://aur.archlinux.org/packages.php?do_Details=1&ID=11879
Can't we use parsepkgbuild from namcap2? See http://projects.archlinux.org/git/?p=namcap.git;a=blob;f=parsepkgbuild;h=68a... This way PKGBUILD is parsed by bash and resulting output is much easier to parse with PHP or Python.
Moreover, the > and < are not converted to > and < in output.
Just to make it more clear what I was trying to say. I was talking about the other bug: the page contains <a href='http://archlinux.org/packages/search/glib2'>glib2>=2.12.0</a><br />
= should be >= instead
-- Roman Kyrylych (Роман Кирилич)
On 10/3/07, Roman Kyrylych
Found a bug in parser. See http://aur.archlinux.org/packages/cheese/cheese/PKGBUILD and how depends are parsed on http://aur.archlinux.org/packages.php?do_Details=1&ID=11879
Partial patch in my git repo [1] I've rewritten the code which concats PKGBUILD variables spanning multiple lines to one line. However, it'll need some fine tuning - it currently counts opening and closing braces in order to determine which parts of the PKGBUILD resemble arrays. Any braces used in, e.g. the description might break it, so it'll need to be modified to ignore braces enclosed within single or double quotes. Joerie [1]: http://tinyurl.com/3yjjda
Roman Kyrylych wrote:
2007/10/3, Paul Mattal
: As usual, report all problems here.
Found a bug in parser. See http://aur.archlinux.org/packages/cheese/cheese/PKGBUILD and how depends are parsed on http://aur.archlinux.org/packages.php?do_Details=1&ID=11879
Can't we use parsepkgbuild from namcap2? See http://projects.archlinux.org/git/?p=namcap.git;a=blob;f=parsepkgbuild;h=68a... This way PKGBUILD is parsed by bash and resulting output is much easier to parse with PHP or Python.
At least the last time we looked into parsing PKGBUILDs with bash, we decided we couldn't do this for unsupported, since the provenance of the bash script is completely unknown. An attacker could write evil bash, simply create an account, upload it, and he's run arbitrary bash on the server. This is why we intentionally did not parse PKGBUILDs using bash, though I really really wanted to. I do, in fact, parse them with bash in the tupkgupdate script, but those are only trusted PKGBUILDs checked into cvs. - P
2007/10/4, Paul Mattal
Roman Kyrylych wrote:
2007/10/3, Paul Mattal
: As usual, report all problems here.
Found a bug in parser. See http://aur.archlinux.org/packages/cheese/cheese/PKGBUILD and how depends are parsed on http://aur.archlinux.org/packages.php?do_Details=1&ID=11879
Can't we use parsepkgbuild from namcap2? See http://projects.archlinux.org/git/?p=namcap.git;a=blob;f=parsepkgbuild;h=68a... This way PKGBUILD is parsed by bash and resulting output is much easier to parse with PHP or Python.
At least the last time we looked into parsing PKGBUILDs with bash, we decided we couldn't do this for unsupported, since the provenance of the bash script is completely unknown. An attacker could write evil bash, simply create an account, upload it, and he's run arbitrary bash on the server.
This is why we intentionally did not parse PKGBUILDs using bash, though I really really wanted to. I do, in fact, parse them with bash in the tupkgupdate script, but those are only trusted PKGBUILDs checked into cvs.
hmm, probably, you're right, but doesn't " --noprofile --norc -r" avoids this? -- Roman Kyrylych (Роман Кирилич)
participants (5)
-
Joerie de Gram
-
Loui
-
Paul Mattal
-
Roman Kyrylych
-
tardo