Hello,
I am pleased to announce that AUR 3.0.0 has just been released. The official AUR setup [1] has already been updated.
Note that in order to build source packages for the AUR, you will now need to use a tool called mkaurball (instead of `makepkg --source`). It is included in the pkgbuild-introspection package [2].
For a comprehensive list of changes, please consult the Git log [3]. As usual, bugs should be reported to the AUR bug tracker [4].
[1] https://aur.archlinux.org/ [2] https://www.archlinux.org/packages/community/any/pkgbuild-introspection/ [3] https://projects.archlinux.org/aur.git/log/?id=v3.0.0 [4] https://bugs.archlinux.org/index.php?project=2
On Tue, May 27, 2014, at 11:42 AM, Lukas Fleischer wrote:
Hello,
I am pleased to announce that AUR 3.0.0 has just been released. The official AUR setup [1] has already been updated.
Note that in order to build source packages for the AUR, you will now need to use a tool called mkaurball (instead of `makepkg --source`). It is included in the pkgbuild-introspection package [2].
For a comprehensive list of changes, please consult the Git log [3]. As usual, bugs should be reported to the AUR bug tracker [4].
[1] https://aur.archlinux.org/ [2] https://www.archlinux.org/packages/community/any/pkgbuild-introspection/ [3] https://projects.archlinux.org/aur.git/log/?id=v3.0.0 [4] https://bugs.archlinux.org/index.php?project=2
I didn't try changing my AUR username before the update, but I'm trying to it from Hspasta to Hspak and I seem to be getting an irrelevant (generic?) error messages:
The username is invalid. It must be between 3 and 16 characters long Start and end with a letter or number Can contain only one period, underscore or hyphen.
Screeny: http://i.imgur.com/uoSamGs.png (I retyped my password too)
Hong
On Fri, 30 May 2014 at 03:54:09, Hong Shick Pak wrote:
[...] I didn't try changing my AUR username before the update, but I'm trying to it from Hspasta to Hspak and I seem to be getting an irrelevant (generic?) error messages:
The username is invalid. It must be between 3 and 16 characters long Start and end with a letter or number Can contain only one period, underscore or hyphen.
Should be fixed now. Thanks for reporting.
Screeny: http://i.imgur.com/uoSamGs.png (I retyped my password too)
Hong
Hi
I'm trying to upload a split package of sddm -qt5-git and -git (attached), but when I upload it, it says: "You are not allowed to overwrite the sddm-qt5-git package.". I'm a maintainer of both of course. Is this a bug? If not, what's the correct course of action? J. Leclanche
On Fri, May 30, 2014 at 8:45 AM, Lukas Fleischer archlinux@cryptocrack.de wrote:
On Fri, 30 May 2014 at 03:54:09, Hong Shick Pak wrote:
[...] I didn't try changing my AUR username before the update, but I'm trying to it from Hspasta to Hspak and I seem to be getting an irrelevant (generic?) error messages:
The username is invalid. It must be between 3 and 16 characters long Start and end with a letter or number Can contain only one period, underscore or hyphen.
Should be fixed now. Thanks for reporting.
Screeny: http://i.imgur.com/uoSamGs.png (I retyped my password too)
Hong
Hi,
On Sun, 01 Jun 2014 at 13:36:29, Jerome Leclanche wrote:
Hi
I'm trying to upload a split package of sddm -qt5-git and -git (attached), but when I upload it, it says: "You are not allowed to overwrite the sddm-qt5-git package.". I'm a maintainer of both of course. Is this a bug? If not, what's the correct course of action? [...]
No, this isn't a bug. You cannot overwrite a package from a different package base. What you can do is:
1. Rename the sddm-qt5-git package without changing its package base:
pkgbase=sddm-qt5-git pkgname=sddm-qt5-git-old
This might also require some "$pkgname" references to be replaced by "$pkgbase" in order to successfully build a new package.
2. Submit the updated package to the AUR. This will result in the package name changing from sddm-qt5-git to sddm-qt5-git-old.
3. Upload the new split package.
4. Request the old (renamed) package (sddm-qt5-git-old) to be merged into the new one.
Please read both [1] and [2] for details.
Regards, Lukas
[1] https://mailman.archlinux.org/pipermail/aur-general/2014-May/028594.html [2] https://mailman.archlinux.org/pipermail/aur-general/2014-June/028631.html
That's very unfortunate and quite a bit counter-intuitive. Is this final? J. Leclanche
On Sun, Jun 1, 2014 at 2:26 PM, Lukas Fleischer archlinux@cryptocrack.de wrote:
Hi,
On Sun, 01 Jun 2014 at 13:36:29, Jerome Leclanche wrote:
Hi
I'm trying to upload a split package of sddm -qt5-git and -git (attached), but when I upload it, it says: "You are not allowed to overwrite the sddm-qt5-git package.". I'm a maintainer of both of course. Is this a bug? If not, what's the correct course of action? [...]
No, this isn't a bug. You cannot overwrite a package from a different package base. What you can do is:
Rename the sddm-qt5-git package without changing its package base:
pkgbase=sddm-qt5-git pkgname=sddm-qt5-git-old
This might also require some "$pkgname" references to be replaced by "$pkgbase" in order to successfully build a new package.
Submit the updated package to the AUR. This will result in the package name changing from sddm-qt5-git to sddm-qt5-git-old.
Upload the new split package.
Request the old (renamed) package (sddm-qt5-git-old) to be merged into the new one.
Please read both [1] and [2] for details.
Regards, Lukas
[1] https://mailman.archlinux.org/pipermail/aur-general/2014-May/028594.html [2] https://mailman.archlinux.org/pipermail/aur-general/2014-June/028631.html
On Sun, 01 Jun 2014 at 16:16:08, Jerome Leclanche wrote:
That's very unfortunate and quite a bit counter-intuitive. Is this final? [...]
No, it's not. As I said in the other thread [1] on this topic, I am open for suggestions.
[1] https://mailman.archlinux.org/pipermail/aur-general/2014-May/028594.html
On 2014-06-01 06:36, Jerome Leclanche wrote:
Hi
I'm trying to upload a split package of sddm -qt5-git and -git (attached), but when I upload it, it says: "You are not allowed to overwrite the sddm-qt5-git package.". I'm a maintainer of both of course. Is this a bug? If not, what's the correct course of action? J. Leclanche
Please don't. You'll force the user to have both qt4 and qt5 installed even if they just want one of them.
Doug
On 01/06, Doug Newgard wrote:
Please don't. You'll force the user to have both qt4 and qt5 installed even if they just want one of them.
No?.. Both will be built by default, but building and installing packages are two very separate things, and split packages exist for the sole purpose of just having a single PKGBUILD build two packages that really should be two packages from the same source
On 2014-06-01 09:50, Johannes Löthberg wrote:
On 01/06, Doug Newgard wrote:
Please don't. You'll force the user to have both qt4 and qt5 installed even if they just want one of them.
No?.. Both will be built by default, but building and installing packages are two very separate things ...
In a binary repo, that is true, but not in the AUR.
You'll need qt4 and qt5 installed to build the package though.
So that means a large download of qt5, unnecessary writes to the users SSD, increased install time, and then having to remove qt5 again afterwards! (or the opposite way around qt5-qt4)
On 1 June 2014 15:51, Doug Newgard scimmia@archlinux.info wrote:
On 2014-06-01 09:50, Johannes Löthberg wrote:
On 01/06, Doug Newgard wrote:
Please don't. You'll force the user to have both qt4 and qt5 installed even if they just want one of them.
No?.. Both will be built by default, but building and installing packages are two very separate things ...
In a binary repo, that is true, but not in the AUR.
On 01/06, Steven Honeyman wrote:
You'll need qt4 and qt5 installed to build the package though.
If they don't want that they can just modify the PKGBUILD ever so slightly instead of the maintainer to have to maintain several versions of the same PKGBUILD
On 2014-06-01 10:02, Johannes Löthberg wrote:
On 01/06, Steven Honeyman wrote:
You'll need qt4 and qt5 installed to build the package though.
If they don't want that they can just modify the PKGBUILD ever so slightly instead of the maintainer to have to maintain several versions of the same PKGBUILD
Ever so slightly? Change the pkgname, {,make,opt}deps, and remove an entire function. Then hoping that there wasn't a required dep inherited from the one they removed.
On 01/06, Doug Newgard wrote:
No?.. Both will be built by default, but building and installing packages are two very separate things ...
In a binary repo, that is true, but not in the AUR.
Yes it is, makepkg just builds packages by default unless you explicitly tell it to install them too.
On 2014-06-01 10:03, Johannes Löthberg wrote:
On 01/06, Doug Newgard wrote:
No?.. Both will be built by default, but building and installing packages are two very separate things ...
In a binary repo, that is true, but not in the AUR.
Yes it is, makepkg just builds packages by default unless you explicitly tell it to install them too.
In the AUR, you specifically build packages to install them. When building for binary repos, you build them to upload them for others to install them. HUGE difference.
On 01/06, Doug Newgard wrote:
In the AUR, you specifically build packages to install them. When building for binary repos, you build them to upload them for others to install them. HUGE difference.
The AUR is a repository for hosting PKGBUILDs for packages not in the repos. Do not conflate the purpose of the AUR with your use of it.
On 2014-06-01 10:09, Johannes Löthberg wrote:
On 01/06, Doug Newgard wrote:
In the AUR, you specifically build packages to install them. When building for binary repos, you build them to upload them for others to install them. HUGE difference.
The AUR is a repository for hosting PKGBUILDs for packages not in the repos. Do not conflate the purpose of the AUR with your use of it.
For my use? Or for how nearly everyone uses it? Come on now, do you really believe that they main use of the AUR is to run unofficial repos?
On Sun, Jun 01, 2014 at 10:10:35AM -0500, Doug Newgard wrote:
On 2014-06-01 10:09, Johannes Löthberg wrote:
On 01/06, Doug Newgard wrote:
In the AUR, you specifically build packages to install them. When building for binary repos, you build them to upload them for others to install them. HUGE difference.
The AUR is a repository for hosting PKGBUILDs for packages not in the repos. Do not conflate the purpose of the AUR with your use of it.
For my use? Or for how nearly everyone uses it? Come on now, do you really believe that they main use of the AUR is to run unofficial repos?
Consider the idea that the current use of the AUR is the way it is due to the long time lack of support for split packages. I tend to agree with Johannes here.
On 2014-06-01 10:15, Dave Reisner wrote:
On Sun, Jun 01, 2014 at 10:10:35AM -0500, Doug Newgard wrote:
On 2014-06-01 10:09, Johannes Löthberg wrote:
On 01/06, Doug Newgard wrote:
In the AUR, you specifically build packages to install them. When building for binary repos, you build them to upload them for others to install them. HUGE difference.
The AUR is a repository for hosting PKGBUILDs for packages not in the repos. Do not conflate the purpose of the AUR with your use of it.
For my use? Or for how nearly everyone uses it? Come on now, do you really believe that they main use of the AUR is to run unofficial repos?
Consider the idea that the current use of the AUR is the way it is due to the long time lack of support for split packages. I tend to agree with Johannes here.
Even if split package support has been there from the beginning, how would that have changed things? Would someone be building the entire AUR or large parts of it and putting it into a repo? No matter what, the main usage of the AUR is to build packages for your own use, and I don't see how that will change now with split package support.
On Sun, Jun 01, 2014 at 10:20:32AM -0500, Doug Newgard wrote:
On 2014-06-01 10:15, Dave Reisner wrote:
On Sun, Jun 01, 2014 at 10:10:35AM -0500, Doug Newgard wrote:
On 2014-06-01 10:09, Johannes Löthberg wrote:
On 01/06, Doug Newgard wrote:
In the AUR, you specifically build packages to install them. When building for binary repos, you build them to upload them for others to install them. HUGE difference.
The most relevant part here - to me - seems not to be for any individual's use of the AUR, but the means of distribution. In the main repos a PKGBUILD is used by devs/maintainers (maybe 1 person) to serve binary packages to many people. In the AUR each user who wants the package needs to use the PKGBUILD and build their own.
Split packages requiring excess build dependencies (qt4/qt5 as in the discussion above) when it is in the binary repos are a minor burden for one person building the package to be a benefit to many people. When the same split package is in the AUR it is a burden for every person who wants to use either of the final packages.
-Jesse AKA 'Trilby'
I don't really understand why AUR helpers can't be updated to only build the package you want in the split pkgbuild. If you look at my source package, the makedepends are only in their respective package. Is makepkg limited in that way? Because if it is, this is a good feature to have. J. Leclanche
On Sun, Jun 1, 2014 at 4:45 PM, Jesse McClure jmcclure@cns.umass.edu wrote:
On Sun, Jun 01, 2014 at 10:20:32AM -0500, Doug Newgard wrote:
On 2014-06-01 10:15, Dave Reisner wrote:
On Sun, Jun 01, 2014 at 10:10:35AM -0500, Doug Newgard wrote:
On 2014-06-01 10:09, Johannes Löthberg wrote:
On 01/06, Doug Newgard wrote:
In the AUR, you specifically build packages to install them. When building for binary repos, you build them to upload them for others to install them. HUGE difference.
The most relevant part here - to me - seems not to be for any individual's use of the AUR, but the means of distribution. In the main repos a PKGBUILD is used by devs/maintainers (maybe 1 person) to serve binary packages to many people. In the AUR each user who wants the package needs to use the PKGBUILD and build their own.
Split packages requiring excess build dependencies (qt4/qt5 as in the discussion above) when it is in the binary repos are a minor burden for one person building the package to be a benefit to many people. When the same split package is in the AUR it is a burden for every person who wants to use either of the final packages.
-Jesse AKA 'Trilby'
On 2014-06-01 10:56, Jerome Leclanche wrote:
I don't really understand why AUR helpers can't be updated to only build the package you want in the split pkgbuild. If you look at my source package, the makedepends are only in their respective package. Is makepkg limited in that way? Because if it is, this is a good feature to have. J. Leclanche
Doesn't work, makedepends cannot be in the package function only.
.. bummer. Is that final as well? J. Leclanche
On Sun, Jun 1, 2014 at 5:03 PM, Doug Newgard scimmia@archlinux.info wrote:
On 2014-06-01 10:56, Jerome Leclanche wrote:
I don't really understand why AUR helpers can't be updated to only build the package you want in the split pkgbuild. If you look at my source package, the makedepends are only in their respective package. Is makepkg limited in that way? Because if it is, this is a good feature to have. J. Leclanche
Doesn't work, makedepends cannot be in the package function only.
On 01/06, Jerome Leclanche wrote:
.. bummer. Is that final as well? J. Leclanche
Anything else would be pointless either way. makedepends are used when building, not when packaging something, so in that case you'd rather want split packages to be able to have a split build function.
It would be useful for makepkg to be able to build ony one specific package from a split package though, no? Eg. "makepkg --only=package1,package2" J. Leclanche
On Sun, Jun 1, 2014 at 9:57 PM, Johannes Löthberg johannes@kyriasis.com wrote:
On 01/06, Jerome Leclanche wrote:
.. bummer. Is that final as well? J. Leclanche
Anything else would be pointless either way. makedepends are used when building, not when packaging something, so in that case you'd rather want split packages to be able to have a split build function.
-- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
On Mon, Jun 2, 2014 at 7:54 AM, Jerome Leclanche adys.wh@gmail.com wrote:
It would be useful for makepkg to be able to build ony one specific package from a split package though, no? Eg. "makepkg --only=package1,package2" J. Leclanche
I guess one problem for this is that some of the sub-packages might shares the same build function.
On Sun, Jun 1, 2014 at 9:57 PM, Johannes Löthberg johannes@kyriasis.com wrote:
On 01/06, Jerome Leclanche wrote:
.. bummer. Is that final as well? J. Leclanche
Anything else would be pointless either way. makedepends are used when building, not when packaging something, so in that case you'd rather want split packages to be able to have a split build function.
-- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
On Mon, Jun 2, 2014 at 7:54 AM, Jerome Leclanche adys.wh@gmail.com wrote:
It would be useful for makepkg to be able to build ony one specific package from a split package though, no? Eg. "makepkg --only=package1,package2" J. Leclanche
makepkg can already do that:
--pkg <list> Only build listed packages from a split package. Multiple packages should be comma separated in the list. This option can be specified multiple times.
On Sun, Jun 1, 2014 at 9:57 PM, Johannes Löthberg johannes@kyriasis.com wrote:
On 01/06, Jerome Leclanche wrote:
.. bummer. Is that final as well? J. Leclanche
Anything else would be pointless either way. makedepends are used when building, not when packaging something, so in that case you'd rather want split packages to be able to have a split build function.
-- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
On Mon, Jun 2, 2014 at 10:18 AM, Eric Bélanger snowmaniscool@gmail.com wrote:
On Mon, Jun 2, 2014 at 7:54 AM, Jerome Leclanche adys.wh@gmail.com wrote:
It would be useful for makepkg to be able to build ony one specific package from a split package though, no? Eg. "makepkg --only=package1,package2" J. Leclanche
makepkg can already do that:
--pkg <list> Only build listed packages from a split package. Multiplepackages should be comma separated in the list. This option can be specified multiple times.
I think that option can only be used to specify the package functions to call. AFAIK, there's only one build function now and there's no way to build only part of it (no standard way at least.).
On Sun, Jun 1, 2014 at 9:57 PM, Johannes Löthberg johannes@kyriasis.com wrote:
On 01/06, Jerome Leclanche wrote:
.. bummer. Is that final as well? J. Leclanche
Anything else would be pointless either way. makedepends are used when building, not when packaging something, so in that case you'd rather want split packages to be able to have a split build function.
-- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
On 28 May 2014 04:42, Lukas Fleischer archlinux@cryptocrack.de wrote:
Note that in order to build source packages for the AUR, you will now need to use a tool called mkaurball (instead of `makepkg --source`). It is included in the pkgbuild-introspection package [2].
Why do files/directories inside a src tarball need to be 644/755 respectively? [1]
I run with umask 027 so this error is going to bite me every time I create a new PKGBUILD to upload, or forget to change the permissions on my existing PKGBUILD's.
Wouldn't it be a better user experience to just change the permissions to what the AUR needs rather than barfing back to the user?
Cheers, ~p
[1] https://projects.archlinux.org/aur.git/tree/web/html/pkgsubmit.php?id=v3.0.0...
Why do files/directories inside a src tarball need to be 644/755 respectively? [1]
I run with umask 027 so this error is going to bite me every time I create a new PKGBUILD to upload, or forget to change the permissions on my existing PKGBUILD's.
I have to agree with Philip. I also have my system with a different umask 002. It is really annoying to have to remember every time I want to create/update a package to: 1) change temporary the umask in my system 2) check that all the files that will be bundle in the aur package have the correct permission set 3) call mkaurball 4) change back umask ( if using the same terminal )
In my last two submissions to the AUR after the change the truth is that it meant that I had to do the job twice as I did not realize that I forgot to change the permissions
Notice that before AUR 3 just calling "makepkg --source" was enough. Any good reason for this change? If there any possibility as Philip proposes that this is done in the serve side?
Thanks all for the great job, Hector
* Hector Martinez-Seara hseara@gmail.com [2014-06-05 08:56:00 +0300]:
Notice that before AUR 3 just calling "makepkg --source" was enough. Any good reason for this change? If there any possibility as Philip proposes that this is done in the serve side?
I believe (though not 100% sure) this is the reason:
The old way things were done is the AUR parsing the PKGBUILD without actually sourcing it to get version info, so you can't kill the AUR server with mean stuff in your PKGBUILD. This breaks on a lot of corner cases.
The new way is you sourcing the PKGBUILD locally (which *can't* be done on the server side) and generating a machine-readable file from the informations in the PKGBUILD.
mkaurball really just is a wrapper around makepkg --source which generates this .AURINFO file after generating the source tarball.
Note you can (for now) still force-upload old-style packages:
error: failed to upload ...: The source package does not contain any meta data. Please use `mkaurball` to create AUR source packages. Support for source packages without .AURINFO entries will be removed in an upcoming release! You can resubmit the package if you want to proceed anyway.
But I agree, adjusting the permissions probably should (and AFAIK could be done safely) on the server side.
Florian
On Thu, 05 Jun 2014 at 08:12:23, Florian Bruhin wrote:
- Hector Martinez-Seara hseara@gmail.com [2014-06-05 08:56:00 +0300]:
Notice that before AUR 3 just calling "makepkg --source" was enough. Any good reason for this change? If there any possibility as Philip proposes that this is done in the serve side?
[...] But I agree, adjusting the permissions probably should (and AFAIK could be done safely) on the server side.
No, we do not (and will never) modify the tarball on the server-side. If that really annoys you, just write a simple wrapper script around mkaurball or patch mkaurball so that it adjusts the permissions.
Note that this issue will vanish soon anyway since the next major AUR release will provide Git repositories for all AUR packages. You will no longer need to create source tarballs.
Florian
-- http://www.the-compiler.org | me@the-compiler.org (Mail/XMPP) GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/
* Lukas Fleischer archlinux@cryptocrack.de [2014-06-05 09:03:29 +0200]:
Note that this issue will vanish soon anyway since the next major AUR release will provide Git repositories for all AUR packages. You will no longer need to create source tarballs.
That sounds intresting! Is there some kind of specification or some more notes regarding this? I wonder how permissions/merges/etc. will be dealt with.
Florian
On Thu, 05 Jun 2014 at 09:08:48, Florian Bruhin wrote:
- Lukas Fleischer archlinux@cryptocrack.de [2014-06-05 09:03:29 +0200]:
Note that this issue will vanish soon anyway since the next major AUR release will provide Git repositories for all AUR packages. You will no longer need to create source tarballs.
That sounds intresting! Is there some kind of specification or some more notes regarding this? I wonder how permissions/merges/etc. will be dealt with.
Check [1] for some of the implementation details.
Florian
-- http://www.the-compiler.org | me@the-compiler.org (Mail/XMPP) GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/
[1] https://mailman.archlinux.org/pipermail/aur-dev/2014-June/002770.html
On Thu, Jun 05, 2014 at 09:28:15AM +0200, Lukas Fleischer wrote:
On Thu, 05 Jun 2014 at 09:08:48, Florian Bruhin wrote:
- Lukas Fleischer archlinux@cryptocrack.de [2014-06-05 09:03:29 +0200]:
Note that this issue will vanish soon anyway since the next major AUR release will provide Git repositories for all AUR packages. You will no longer need to create source tarballs.
That sounds intresting! Is there some kind of specification or some more notes regarding this? I wonder how permissions/merges/etc. will be dealt with.
Check [1] for some of the implementation details.
On top of that, looking directly at permissions, git only tracks the executable bit, so the only permissions that git knows of for regular files is 755 and 644.
As a demonstration::
$ git ls-files x $ ls -l -rw-r--r-- 1 wgiokas users 0 Jun 5 02:47 x $ chmod u+x x $ ls -l -rwxr--r-- 1 wgiokas users 0 Jun 5 02:47 x $ git diff diff --git a/x b/x old mode 100644 new mode 100755
Florian
-- http://www.the-compiler.org | me@the-compiler.org (Mail/XMPP) GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/
[1] https://mailman.archlinux.org/pipermail/aur-dev/2014-June/002770.html
On Thu, 05 Jun 2014 at 09:52:11, William Giokas wrote:
On Thu, Jun 05, 2014 at 09:28:15AM +0200, Lukas Fleischer wrote:
On Thu, 05 Jun 2014 at 09:08:48, Florian Bruhin wrote:
- Lukas Fleischer archlinux@cryptocrack.de [2014-06-05 09:03:29 +0200]:
Note that this issue will vanish soon anyway since the next major AUR release will provide Git repositories for all AUR packages. You will no longer need to create source tarballs.
That sounds intresting! Is there some kind of specification or some more notes regarding this? I wonder how permissions/merges/etc. will be dealt with.
Check [1] for some of the implementation details.
On top of that, looking directly at permissions, git only tracks the executable bit, so the only permissions that git knows of for regular files is 755 and 644. [...]
Yes, that's exactly what I wanted to suggest when saying that "this issue will vanish soon anyway since the next major AUR release will provide Git repositories for all AUR packages". Sorry for being vague.
aur-general@lists.archlinux.org