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

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 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 -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5

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 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 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 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 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 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.

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 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'

.. bummer. Is that final as well? J. Leclanche On Sun, Jun 1, 2014 at 5:03 PM, Doug Newgard 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.

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 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 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 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

* Hector Martinez-Seara [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 -- 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 [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 -- 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/

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 [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

-- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF