Github Actions Worklfow in AUR package

Azd325 · 2020-06-26 19:42:52

Hey,

I added a GitHub workflow to my AUR package to validate and test it.

Now I have this kind of problem when I push to the AUR repository.

remote: error: the repository must not contain subdirectories

Are there any reference why this is blocked? It would be cool if it can be pushed.

Last edited by Azd325 (2020-06-26 19:55:54)

Trilby · 2020-06-26 20:05:25

It has no place on the AUR server, that's why. The AUR server is for hosting the build files only, not other tools that you may use locally to maintain the package. Why do you want to commit this content to the AUR in the first place?

Last edited by Trilby (2020-06-26 20:20:07)

eschwartz · 2020-06-26 20:15:56

Check out the "aurpublish" package in the community repository. It has the ability to keep the AUR package as a subdirectory of your github repo (using git subtree), so when you update the package with 'aurpublish ./dir/' it will not try to push the .github/ directory.

Then, keep any files which the package itself doesn't need, and is only needed by your github integrations, outside of the AUR-specific directory.

subtrees are magical.

Last edited by eschwartz (2020-06-26 20:17:08)

Azd325 · 2020-06-27 07:24:19

Trilby wrote:

It has no place on the AUR server, that's why. The AUR server is for hosting the build files only, not other tools that you may use locally to maintain the package. Why do you want to commit this content to the AUR in the first place?

To reduce build steps. It is easier to push this then to run other commands like aurpublish. A lot of AUR packages have also a Travis file inside maybe there should be then also a blacklist of files and not only to ignore subfolders to reduce the clutter if this doesn't have to be on the AUR server.

eschwartz wrote:

Check out the "aurpublish" package in the community repository. It has the ability to keep the AUR package as a subdirectory of your github repo (using git subtree), so when you update the package with 'aurpublish ./dir/' it will not try to push the .github/ directory.

This seems then to be the way to do it.

Trilby · 2020-06-27 12:28:33

Azd325 wrote:

To reduce build steps. It is easier to push this then to run other commands like aurpublish.

What steps are you reducing? You are *adding* steps. Don't commit files other than the PKGBUILD, .SRCINFO, and any necessary patches or service files. The only way anything else would be included is if you deliberately added it to the commit. Don't `git add` superflouous stuff to the AUR repo commits: that is fewer steps.

Azd325 wrote:

A lot of AUR packages have also a Travis file ...

I don't know what a Travis file is, but if it's not used in building the package, it should not be there. But lots of AUR packages are broken, that doesn't mean much: we're certainly not going to lower our standards to the lowest common demoninator.

Azd325 wrote:

... maybe there should be then also a blacklist ...

Why? There are a very small number of things that should be committed to the AUR git repos; there are infinitely many things that shouldn't be. Trying to enumerate all the things that shouldn't be added is silly. Only add what should be - it's a much simpler guideline, and it's much much simpler to implement.

A Travis file should not be in the AUR repo (I'm assuming - again I don't know what this is). So should there be a special blacklist including it? No, users should simply not run `git add Travis`. What should they do instead? Nothing. Just don't add it. Git repos do not need to include everything in the working directory.

(edit: typo)

Last edited by Trilby (2020-06-27 17:25:08)

loqs · 2020-06-27 16:03:45

Trilby wrote:

I don't know what a Travis file is, but it it's not using in building the package, it should not be there.

Travis continuous integration .travis.yml tutorial.

Trilby wrote:

But lots of AUR packages are broken, that doesn't mean much: we're certainly not going to lower our standards to the lowest common demoninator.

Such as packages that do not build and want to store everything in the users home directory creating an empty package https://aur.archlinux.org/packages/rofi-shortcuts-git/
Or call makepkg from inside the .install file using the first created user with a home directory in /home to run the build https://aur.archlinux.org/cgit/aur.git/ … kywire-git

Last edited by loqs (2020-06-27 16:22:23)

Alad · 2020-06-27 17:00:02

Please file deletion requests for such packages.

eschwartz · 2020-06-28 03:22:18

Trilby wrote:

Azd325 wrote:
... maybe there should be then also a blacklist ...
Why? There are a very small number of things that should be committed to the AUR git repos; there are infinitely many things that shouldn't be. Trying to enumerate all the things that shouldn't be added is silly. Only add what should be - it's a much simpler guideline, and it's much much simpler to implement.
A Travis file should not be in the AUR repo (I'm assuming - again I don't know what this is). So should there be a special blacklist including it? No, users should simply not run `git add Travis`. What should they do instead? Nothing. Just don't add it. Git repos do not need to include everything in the working directory.
(edit: typo)

Enumerating badness is playing whack-a-mole. But I'm tempted to blacklist some common forms of obvious "this is never ever ever correct". Configuration files for thirdparty Continuous Integration build services like https://travis-ci.com/ are one of them.

On the other hand, I'm personally guilty of https://aur.archlinux.org/cgit/aur.git/ … man-static for building and signing the official pacman-static binaries, plus https://aur.archlinux.org/cgit/aur.git/ … man-static for tracking repo package updates. So I dunno.

Azd325 · 2020-06-28 10:41:15

eschwartz wrote:

Trilby wrote:
Azd325 wrote:
... maybe there should be then also a blacklist ...
Why? There are a very small number of things that should be committed to the AUR git repos; there are infinitely many things that shouldn't be. Trying to enumerate all the things that shouldn't be added is silly. Only add what should be - it's a much simpler guideline, and it's much much simpler to implement.
A Travis file should not be in the AUR repo (I'm assuming - again I don't know what this is). So should there be a special blacklist including it? No, users should simply not run `git add Travis`. What should they do instead? Nothing. Just don't add it. Git repos do not need to include everything in the working directory.
(edit: typo)
Enumerating badness is playing whack-a-mole. But I'm tempted to blacklist some common forms of obvious "this is never ever ever correct". Configuration files for thirdparty Continuous Integration build services like https://travis-ci.com/ are one of them.
On the other hand, I'm personally guilty of https://aur.archlinux.org/cgit/aur.git/ … man-static for building and signing the official pacman-static binaries, plus https://aur.archlinux.org/cgit/aur.git/ … man-static for tracking repo package updates. So I dunno.

Complete true. Maybe would be a whitelist more helpful if these sources are parsed from PKGBUILD and something is in repo what should be not there than is it should be rejected. Also, in my opinion the subfolder blocking is also not the best idea what if my packages has like 15 different icon sizes. It would be better to have them in a subfolder then lying around in the root.

So my question was if their any references why my push is blocked but it seems there are only opinions but no real references maybe the process has to be defined more clearly to get a clean and healthy AUR

Trilby · 2020-06-28 12:26:55

Azd325 wrote:

... what if my packages has like 15 different icon sizes. It would be better to have them in a subfolder then lying around in the root.

They shouldn't be submitted to the AUR repo at all! The AUR repo is not to be used for hosting the content of packages. Period.

On occasion this rule is stretched when upstream doesn't really make linux-ready content, so a short wrapper script to place in /usr/bin may be tucked away in the AUR repo along side the PKGBUILD. But these are usually just a couple lines of shell code. There's a gaping chasm of difference between a several line script file and 15 image files.

Side note: I see your current AUR package includes a png icon in the AUR repo, but this is the exact same icon provided by upstream in the tarball that the PKGBUILD downloads. Why did you upload the png to the AUR?

Last edited by Trilby (2020-06-28 12:35:19)

Lone_Wolf · 2020-06-28 13:04:40

So my question was if their any references why my push is blocked but it seems there are only opinions but no real references maybe the process has to be defined more clearly to get a clean and healthy AUR

MAYBE creating a bug report against the aur web interface project could clarify that ?

DISCLAIMER
I am suggesting an action that is technically possible.

I have no idea or opinion whether that action is smart, foolish or any other qualification applicable to an action.

eschwartz · 2020-06-28 13:19:26

Azd325 wrote:

Complete true. Maybe would be a whitelist more helpful if these sources are parsed from PKGBUILD and something is in repo what should be not there than is it should be rejected.

Not everything is (accurately) parsed from the PKGBUILD. Variables set from within a package() function cannot be reliably extracted into .SRCINFO, and this includes install= and changelog=

Azd325 wrote:

Also, in my opinion the subfolder blocking is also not the best idea what if my packages has like 15 different icon sizes. It would be better to have them in a subfolder then lying around in the root.

The PKGBUILD format does not permit source=() to contain local sources inside a directory, hence why the AUR rejects this regardless of the .SRCINFO contents.

This is indisputably true regardless of whether you personally agree with Trilby's opinion about these icons not belonging in the AUR. (He is absolutey correct, they don't.)

Azd325 · 2020-06-28 15:31:52

Trilby wrote:

Azd325 wrote:
... what if my packages has like 15 different icon sizes. It would be better to have them in a subfolder then lying around in the root.
They shouldn't be submitted to the AUR repo at all! The AUR repo is not to be used for hosting the content of packages. Period.

I would call the icons as related files like the wiki describes this (PKGBUILD and related files) because there is no definition what should be included and what not. https://wiki.archlinux.org/index.php/Ar … guidelines You only tell me your opinion without references. Period.

Trilby wrote:

Side note: I see your current AUR package includes a png icon in the AUR repo, but this is the exact same icon provided by upstream in the tarball that the PKGBUILD downloads. Why did you upload the png to the AUR?

Thanks for the report! I will change this. This file was added 4 years ago because the original icon from the package was in a crap resolution and worked not well on high-res screens and it was uploaded directly to the AUR because it was not clear that it shouldn't be uploaded. Also, if you use other PKGBUILDs as reference which do the same that will happen.

eschwartz wrote:

This is indisputably true regardless of whether you personally agree with Trilby's opinion about these icons not belonging in the AUR. (He is absolutey correct, they don't.)

I talked about the subfolder block in an example with icons. That a subfolder would make more sense in a case to hold files and keep a clean repo.

Then a media file check would make sense on the server side.

Lone_Wolf wrote:

MAYBE creating a bug report against the aur web interface project could clarify that ?

Where I can file a report to give this to a discussion to help to improve the submitting of packages?

Otherwise guys, I know more about what should be in and what not and that the references need more care to answer these questions and points directly.

eschwartz · 2020-06-28 15:52:06

Azd325 wrote:

Trilby wrote:
Azd325 wrote:
... what if my packages has like 15 different icon sizes. It would be better to have them in a subfolder then lying around in the root.
They shouldn't be submitted to the AUR repo at all! The AUR repo is not to be used for hosting the content of packages. Period.
I would call the icons as related files like the wiki describes this (PKGBUILD and related files) because there is no definition what should be included and what not. https://wiki.archlinux.org/index.php/Ar … guidelines You only tell me your opinion without references. Period.
Trilby wrote:
Side note: I see your current AUR package includes a png icon in the AUR repo, but this is the exact same icon provided by upstream in the tarball that the PKGBUILD downloads. Why did you upload the png to the AUR?
Thanks for the report! I will change this. This file was added 4 years ago because the original icon from the package was in a crap resolution and worked not well on high-res screens and it was uploaded directly to the AUR because it was not clear that it shouldn't be uploaded. Also, if you use other PKGBUILDs as reference which do the same that will happen.

If you have 15 media icons to patch into the package... did you consider maybe submitting an upstream bug "please provide icons with better resolution"?

Azd325 wrote:

eschwartz wrote:
This is indisputably true regardless of whether you personally agree with Trilby's opinion about these icons not belonging in the AUR. (He is absolutey correct, they don't.)
I talked about the subfolder block in an example with icons. That a subfolder would make more sense in a case to hold files and keep a clean repo.
Then a media file check would make sense on the server side.

I don't comprehend the meaning of your response. I will reiterate the part of my post which you ignored.

The PKGBUILD format does not permit source=() to contain local sources inside a directory, hence why the AUR rejects this regardless of the .SRCINFO contents.

Subfolders make no sense in the AUR if you CANNOT do anything with them, because makepkg doesn't permit subfolders to be used.

Trilby · 2020-06-28 15:56:12

Do not upload anything the the AUR that is not necessary to properly build the package. How is that not clear.

I'd also highlight that anytime you upload content to the AUR that you have not created yourself, you put the server / owners of the server at risk due to copyright violations of that material.

Copyright protected material can be "included in the aur" when inclusion means there is a recipe (PKGBUILD) to download it from the proper upstream source. Copyright protected material (which would include any software worth sharing via AUR mechanisms) cannot be legally uploaded to the AUR server.

Futher, the AUR server is a community resource with finite storage and limited bandwidth. So any misuse of it to store material that has no need to be there is a burden on the community.

Again, this isn't about blacklisting media files. The idea isn't to allow everything except for a specific set of blacklisted possibilities. Instead only upload "whitelisted" material which would be material that is 1) necessary for the build process and 2) not subject to copyright protection.

Last edited by Trilby (2020-06-28 15:57:49)

Azd325 · 2020-06-28 17:47:07

eschwartz wrote:

I don't comprehend the meaning of your response. I will reiterate the part of my post which you ignored.
The PKGBUILD format does not permit source=() to contain local sources inside a directory, hence why the AUR rejects this regardless of the .SRCINFO contents.
Subfolders make no sense in the AUR if you CANNOT do anything with them, because makepkg doesn't permit subfolders to be used.

Good to know with makepkg,

Trilby wrote:

Do not upload anything the the AUR that is not necessary to properly build the package. How is that not clear.

It is a clear point but the process in the wiki makes it not clear.

Trilby wrote:

I'd also highlight that anytime you upload content to the AUR that you have not created yourself, you put the server / owners of the server at risk due to copyright violations of that material.
Copyright protected material can be "included in the aur" when inclusion means there is a recipe (PKGBUILD) to download it from the proper upstream source. Copyright protected material (which would include any software worth sharing via AUR mechanisms) cannot be legally uploaded to the AUR server.

Absolute valid point.

Trilby wrote:

Futher, the AUR server is a community resource with finite storage and limited bandwidth. So any misuse of it to store material that has no need to be there is a burden on the community.

Make sense, still it has to be more controlled.
I have now to restructure my package that it will use aurpublish that the community still can contribute easy and everything is one source and only the needed files are published to aur.

Arch Linux

#1 2020-06-26 19:42:52

Github Actions Worklfow in AUR package

#2 2020-06-26 20:05:25

Re: Github Actions Worklfow in AUR package

#3 2020-06-26 20:15:56

Re: Github Actions Worklfow in AUR package

#4 2020-06-27 07:24:19

Re: Github Actions Worklfow in AUR package

#5 2020-06-27 12:28:33

Re: Github Actions Worklfow in AUR package

#6 2020-06-27 16:03:45

Re: Github Actions Worklfow in AUR package

#7 2020-06-27 17:00:02

Re: Github Actions Worklfow in AUR package

#8 2020-06-28 03:22:18

Re: Github Actions Worklfow in AUR package

#9 2020-06-28 10:41:15

Re: Github Actions Worklfow in AUR package

#10 2020-06-28 12:26:55

Re: Github Actions Worklfow in AUR package

#11 2020-06-28 13:04:40

Re: Github Actions Worklfow in AUR package

#12 2020-06-28 13:19:26

Re: Github Actions Worklfow in AUR package

#13 2020-06-28 15:31:52

Re: Github Actions Worklfow in AUR package

#14 2020-06-28 15:52:06

Re: Github Actions Worklfow in AUR package

#15 2020-06-28 15:56:12

Re: Github Actions Worklfow in AUR package

#16 2020-06-28 17:47:07

Re: Github Actions Worklfow in AUR package

Board footer