[aur-dev] AUR 2.1.0 released
Changes since 2.0.1: * Typeahead suggest for packages. * Fix account editing and hijacking vulnerability. * Fix account privilege escalation vulnerability. * Clear a user's active sessions following account suspension. * Several translation fixes/updates. * pkgsubmit.php: Parse .AURINFO metadata. .AURINFO files can now be included in source packages to overwrite specific PKGBUILD fields. .AURINFO files are parsed line by line. The syntax for each line is "key = value", where key is any of the following field names: * pkgname * pkgver * pkgdesc * url * license * depend Multiple "depend" lines can be specified to add multiple dependencies. You can check the Git log [1] for a complete list of commits. The official Arch Linux AUR setup [2] has already been upgraded! [1] https://projects.archlinux.org/aur.git/log/?id=v2.1.0 [2] https://aur.archlinux.org/
On 18/03/13 19:18, Lukas Fleischer wrote:
Changes since 2.0.1: * pkgsubmit.php: Parse .AURINFO metadata.
.AURINFO files can now be included in source packages to overwrite specific PKGBUILD fields. .AURINFO files are parsed line by line. The syntax for each line is "key = value", where key is any of the following field names:
* pkgname * pkgver * pkgdesc * url * license * depend
Multiple "depend" lines can be specified to add multiple dependencies.
I've read a couple of threads [1][2] relating to this topic, and I am puzzled by the idea of using .AURINFO files to "overwrite" PKGBUILD fields. What is the use case for this? It seems completely different to the idea behind .SRCINFO files. Have there been some other discussions on this topic that I've missed? [1] https://mailman.archlinux.org/pipermail/pacman-dev/2012-August/015900.html [2] https://mailman.archlinux.org/pipermail/aur-dev/2013-March/002392.html
On Mon, Mar 18, 2013 at 08:41:37PM +0000, kachelaqa wrote:
On 18/03/13 19:18, Lukas Fleischer wrote:
Changes since 2.0.1: * pkgsubmit.php: Parse .AURINFO metadata.
.AURINFO files can now be included in source packages to overwrite specific PKGBUILD fields. .AURINFO files are parsed line by line. The syntax for each line is "key = value", where key is any of the following field names:
* pkgname * pkgver * pkgdesc * url * license * depend
Multiple "depend" lines can be specified to add multiple dependencies.
I've read a couple of threads [1][2] relating to this topic, and I am puzzled by the idea of using .AURINFO files to "overwrite" PKGBUILD fields. What is the use case for this? It seems completely different to the idea behind .SRCINFO files. Have there been some other discussions on this topic that I've missed?
Why is it completely different? .AURINFO files are .SRCINFO files without support for split packages (which we currently do not support in the AUR anyway). The use cases are pretty obvious: The AUR does not include a full bash parser and will never include one -- metadata should be provided by the client instead.
[1] https://mailman.archlinux.org/pipermail/pacman-dev/2012-August/015900.html [2] https://mailman.archlinux.org/pipermail/aur-dev/2013-March/002392.html
On 18/03/13 20:48, Lukas Fleischer wrote:
On Mon, Mar 18, 2013 at 08:41:37PM +0000, kachelaqa wrote:
On 18/03/13 19:18, Lukas Fleischer wrote:
Changes since 2.0.1: * pkgsubmit.php: Parse .AURINFO metadata.
.AURINFO files can now be included in source packages to overwrite specific PKGBUILD fields. .AURINFO files are parsed line by line. The syntax for each line is "key = value", where key is any of the following field names:
* pkgname * pkgver * pkgdesc * url * license * depend
Multiple "depend" lines can be specified to add multiple dependencies.
I've read a couple of threads [1][2] relating to this topic, and I am puzzled by the idea of using .AURINFO files to "overwrite" PKGBUILD fields. What is the use case for this? It seems completely different to the idea behind .SRCINFO files. Have there been some other discussions on this topic that I've missed?
Why is it completely different? .AURINFO files are .SRCINFO files without support for split packages (which we currently do not support in the AUR anyway).
The use cases are pretty obvious: The AUR does not include a full bash parser and will never include one -- metadata should be provided by the client instead.
[1] https://mailman.archlinux.org/pipermail/pacman-dev/2012-August/015900.html [2] https://mailman.archlinux.org/pipermail/aur-dev/2013-March/002392.html
I think I was thrown by the word "overwrite", which seems to suggest providing alternative values to the ones in the PKGBUILD - whereas the real purpose is to simply offer a "preferred" source for the same values (i.e. one which is easier to parse). The restriction on the available fields also seemed a little puzzling to me - but I suppose package maintainers are free to include whatever fields they like (as long as they follow the general file format). Will the inclusion of an .AURINFO file be a requirement at some stage in the future?
On Mon, Mar 18, 2013 at 09:25:42PM +0000, kachelaqa wrote:
On 18/03/13 20:48, Lukas Fleischer wrote:
On Mon, Mar 18, 2013 at 08:41:37PM +0000, kachelaqa wrote:
On 18/03/13 19:18, Lukas Fleischer wrote:
Changes since 2.0.1: * pkgsubmit.php: Parse .AURINFO metadata.
.AURINFO files can now be included in source packages to overwrite specific PKGBUILD fields. .AURINFO files are parsed line by line. The syntax for each line is "key = value", where key is any of the following field names:
* pkgname * pkgver * pkgdesc * url * license * depend
Multiple "depend" lines can be specified to add multiple dependencies.
I've read a couple of threads [1][2] relating to this topic, and I am puzzled by the idea of using .AURINFO files to "overwrite" PKGBUILD fields. What is the use case for this? It seems completely different to the idea behind .SRCINFO files. Have there been some other discussions on this topic that I've missed?
Why is it completely different? .AURINFO files are .SRCINFO files without support for split packages (which we currently do not support in the AUR anyway).
The use cases are pretty obvious: The AUR does not include a full bash parser and will never include one -- metadata should be provided by the client instead.
[1] https://mailman.archlinux.org/pipermail/pacman-dev/2012-August/015900.html [2] https://mailman.archlinux.org/pipermail/aur-dev/2013-March/002392.html
I think I was thrown by the word "overwrite", which seems to suggest providing alternative values to the ones in the PKGBUILD - whereas the real purpose is to simply offer a "preferred" source for the same values (i.e. one which is easier to parse).
It is used as an alternate source if you specify all fields. The idea is that you can overwrite fields that the AUR PKGBUILD parser fails to parse without having to update other fields like the package version on every update. This might be changed in the future.
The restriction on the available fields also seemed a little puzzling to me - but I suppose package maintainers are free to include whatever fields they like (as long as they follow the general file format).
Which ones are missing? I don't think that the AUR uses any other fields.
Will the inclusion of an .AURINFO file be a requirement at some stage in the future?
This might become a requirement if it is implemented in makepkg or some other tool that auto-generates such files. It is just an experimental feature for now.
On 18/03/13 22:04, Lukas Fleischer wrote:
On Mon, Mar 18, 2013 at 09:25:42PM +0000, kachelaqa wrote:
I think I was thrown by the word "overwrite", which seems to suggest providing alternative values to the ones in the PKGBUILD - whereas the real purpose is to simply offer a "preferred" source for the same values (i.e. one which is easier to parse).
It is used as an alternate source if you specify all fields. The idea is that you can overwrite fields that the AUR PKGBUILD parser fails to parse without having to update other fields like the package version on every update. This might be changed in the future.
Right - "overwriting" does make sense in the context of correcting parsing failures.
The restriction on the available fields also seemed a little puzzling to me - but I suppose package maintainers are free to include whatever fields they like (as long as they follow the general file format).
Which ones are missing? I don't think that the AUR uses any other fields.
The metadata in .AURINFO files could be used by any third-party tools that want to avoid parsing the PKGBUILD, and those tools may want access to a wider set of fields (e.g. arch, optdepends, makedepends, etc). Presumably, if makepkg ever implements .SRCINFO generation, it will include more fields than the AUR currently needs.
Will the inclusion of an .AURINFO file be a requirement at some stage in the future?
This might become a requirement if it is implemented in makepkg or some other tool that auto-generates such files. It is just an experimental feature for now.
Okay, thanks.
On Mon, Mar 18, 2013 at 11:04 PM, Lukas Fleischer wrote:
The restriction on the available fields also seemed a little puzzling to me - but I suppose package maintainers are free to include whatever fields they like (as long as they follow the general file format).
Which ones are missing? I don't think that the AUR uses any other fields.
What about the "source" field? -- Cédric Girard
On Mon, Mar 18, 2013 at 08:18:19PM +0100, Lukas Fleischer wrote:
Changes since 2.0.1:
* Typeahead suggest for packages. * Fix account editing and hijacking vulnerability. * Fix account privilege escalation vulnerability. * Clear a user's active sessions following account suspension. * Several translation fixes/updates. * pkgsubmit.php: Parse .AURINFO metadata.
.AURINFO files can now be included in source packages to overwrite specific PKGBUILD fields. .AURINFO files are parsed line by line. The syntax for each line is "key = value", where key is any of the following field names:
* pkgname
I'll file a proper bug report if it really turns out to be the AUR's fault (when I get some more time to play), but my 60 second test drive of this makes me believe that overriding the pkgname fails silently on the upload if you specify a pkgname which already exists (and which isn't the package you're uploading). I'm only testing this from burp, so grain of salt and all that... d
* pkgver * pkgdesc * url * license * depend
Multiple "depend" lines can be specified to add multiple dependencies.
You can check the Git log [1] for a complete list of commits.
The official Arch Linux AUR setup [2] has already been upgraded!
[1] https://projects.archlinux.org/aur.git/log/?id=v2.1.0 [2] https://aur.archlinux.org/
On Mon, Mar 18, 2013 at 5:10 PM, Dave Reisner <d@falconindy.com> wrote:
On Mon, Mar 18, 2013 at 08:18:19PM +0100, Lukas Fleischer wrote:
Changes since 2.0.1:
* Typeahead suggest for packages. * Fix account editing and hijacking vulnerability. * Fix account privilege escalation vulnerability. * Clear a user's active sessions following account suspension. * Several translation fixes/updates. * pkgsubmit.php: Parse .AURINFO metadata.
.AURINFO files can now be included in source packages to overwrite specific PKGBUILD fields. .AURINFO files are parsed line by line. The syntax for each line is "key = value", where key is any of the following field names:
* pkgname
I'll file a proper bug report if it really turns out to be the AUR's fault (when I get some more time to play), but my 60 second test drive of this makes me believe that overriding the pkgname fails silently on the upload if you specify a pkgname which already exists (and which isn't the package you're uploading).
Quickly tried this on my local setup. Uploaded a source package named "foo", then tried to upload a "bar" source package with pkgname set in .AURINFO to "foo" and received the error message: "You are not allowed to overwrite the foo package." Might be a burp issue or some sort of strange edge case.
I'm only testing this from burp, so grain of salt and all that...
d
* pkgver * pkgdesc * url * license * depend
Multiple "depend" lines can be specified to add multiple dependencies.
You can check the Git log [1] for a complete list of commits.
The official Arch Linux AUR setup [2] has already been upgraded!
[1] https://projects.archlinux.org/aur.git/log/?id=v2.1.0 [2] https://aur.archlinux.org/
On Mar 18, 2013 5:40 PM, "canyonknight" <canyonknight@gmail.com> wrote:
On Mon, Mar 18, 2013 at 5:10 PM, Dave Reisner <d@falconindy.com> wrote:
On Mon, Mar 18, 2013 at 08:18:19PM +0100, Lukas Fleischer wrote:
Changes since 2.0.1:
* Typeahead suggest for packages. * Fix account editing and hijacking vulnerability. * Fix account privilege escalation vulnerability. * Clear a user's active sessions following account suspension. * Several translation fixes/updates. * pkgsubmit.php: Parse .AURINFO metadata.
.AURINFO files can now be included in source packages to overwrite specific PKGBUILD fields. .AURINFO files are parsed line by line. The syntax for each line is "key = value", where key is any of the
following
field names:
* pkgname
I'll file a proper bug report if it really turns out to be the AUR's fault (when I get some more time to play), but my 60 second test drive of this makes me believe that overriding the pkgname fails silently on the upload if you specify a pkgname which already exists (and which isn't the package you're uploading).
Quickly tried this on my local setup. Uploaded a source package named "foo", then tried to upload a "bar" source package with pkgname set in .AURINFO to "foo" and received the error message: "You are not allowed to overwrite the foo package." Might be a burp issue or some sort of strange edge case.
No worries I'll dig into this more on my own time then.
I'm only testing this from burp, so grain of salt and all that...
d
* pkgver * pkgdesc * url * license * depend
Multiple "depend" lines can be specified to add multiple dependencies.
You can check the Git log [1] for a complete list of commits.
The official Arch Linux AUR setup [2] has already been upgraded!
[1] https://projects.archlinux.org/aur.git/log/?id=v2.1.0 [2] https://aur.archlinux.org/
Em 18/03/2013 16:18, Lukas Fleischer escreveu:
Changes since 2.0.1:
* Typeahead suggest for packages. * Fix account editing and hijacking vulnerability. * Fix account privilege escalation vulnerability. * Clear a user's active sessions following account suspension. * Several translation fixes/updates. * pkgsubmit.php: Parse .AURINFO metadata.
.AURINFO files can now be included in source packages to overwrite specific PKGBUILD fields. .AURINFO files are parsed line by line. The syntax for each line is "key = value", where key is any of the following field names:
* pkgname * pkgver * pkgdesc * url * license * depend
Multiple "depend" lines can be specified to add multiple dependencies.
You can check the Git log [1] for a complete list of commits.
The official Arch Linux AUR setup [2] has already been upgraded!
[1] https://projects.archlinux.org/aur.git/log/?id=v2.1.0 [2] https://aur.archlinux.org/
In spite of the translation being commited to the AUR Git (in transifex = in git), it seems some of the strings are still not translated in pt_BR. So far, I notice "Package Search", "Package Actions" and "Upstream URL". Anyway, congratulations for the awesome new features and thanks for the developing it! Cheers, Rafael Ferreira
The typeahead suggest is great, but I would suggest that until I hit down arrow, it not actually do anything (this is how most typeahead systems work I believe). For example, now, if I type "fo" and hit enter, I am left with a text box that says "focal" and no search is run, whereas I would expect this to simply search for "fo". To search for "fo" I have to type "fo" hit escape and then enter, which is counter-intuitive, at least for me. Cheers, Nick On 03/18/2013 08:18 PM, Lukas Fleischer wrote:
Changes since 2.0.1:
* Typeahead suggest for packages. * Fix account editing and hijacking vulnerability. * Fix account privilege escalation vulnerability. * Clear a user's active sessions following account suspension. * Several translation fixes/updates. * pkgsubmit.php: Parse .AURINFO metadata.
.AURINFO files can now be included in source packages to overwrite specific PKGBUILD fields. .AURINFO files are parsed line by line. The syntax for each line is "key = value", where key is any of the following field names:
* pkgname * pkgver * pkgdesc * url * license * depend
Multiple "depend" lines can be specified to add multiple dependencies.
You can check the Git log [1] for a complete list of commits.
The official Arch Linux AUR setup [2] has already been upgraded!
[1] https://projects.archlinux.org/aur.git/log/?id=v2.1.0 [2] https://aur.archlinux.org/
participants (7)
-
canyonknight
-
Cédric Girard
-
Dave Reisner
-
kachelaqa
-
Lukas Fleischer
-
Nick Lanham
-
Rafael Ferreira