- Aur-dev - lists.archlinux.org

Re: [aur-dev] AUR 4 and licensing
by David Manouchehri 14 Apr '15

14 Apr '15

> I like this idea, but I don't think it's sound to consider something > GPL-licensed because the author checked a box or accepted the TOC. I doubt > that has any legal significance. I agree that accepting a one time ToS agreement is hardly binding. That's why I suggested printing out a message with a Git hook saying everything you push is going to be GPL, it's a bit harder to claim ignorance when you see that message every time. We're already in the gray area since there's thousands of packages with no license explicitly listed, and I don't think it's sane to suggest removing those. > Wouldn't it make more sense to use a mandatory two-line header like below? This switch to Git is already going to cost us a lot of maintainers who simply don't feel like learning it, I can't say I'm in favor for imposing any more requirements. I'm also not really a fan of littering my PKGBUILDs with static text either. Listing the current maintainer and contributors is already less than ideal (with the move to Git, I guess we could stop listing the contributors inline since they're in the logs).

4 3

Re: [aur-dev] AUR 4 and licensing
by David Manouchehri 14 Apr '15

14 Apr '15

> I don't really like the idea of all this red-tape, requiring one license or > another. So I have some concerns. Is there a plan to enforce this? If the > PKGBUILD is trivial can you reasonably defend a license? I don't think any of us expect there to be any real arguments from it. There's not going to be much "defending" going on, the only likely situation I can see is if somebody's package gets moved to [community] and they're annoyed that somebody else is maintaining it now. GPL would help clear that up. Another thing is that some people upload copyrighted binaries by mistake. Reminding the maintainer that the entire git/tar ball has to be under GPL would probably help them avoid making that mistake. Having the PKGBUILDs under GPL makes one less thing to worry about when migrating it over towards [community]. Right now in theory you have to make sure both the project /and/ PKGBUILD's license allows you to package it. By asking all PKGBUILDs to become GPL, now all any future maintainers have to do is look at the source. > If I write a patch/etc is it under GPL or is it under the project's original > license? I would say everything being tracked by the Git repo is GPL. So if it's an external patch hosted outside of Arch, then no. Same concept with packages like Dropbox that can't be repacked, so they list the source. This seems fair, if you want free hosting on Arch, you play by Arch's rules. > Get rid of the TOS. I don't think the TUs want to become the license police. I don't think any of us were asking the TUs to police anything. No one was suggesting having the TUs read through all 50,000 PKGBUILDs to check for GPL violations.

1 0

[aur-dev] AUR 4 and licensing
by Johannes Löthberg 14 Apr '15

14 Apr '15

Hello, Currently the content of the AUR is in a sort of gray zone. All of the contents are technically copyrighted, and since there is no explicit license it defaults to 'all rights reserved'. To mitigate this I’d propose making a ToS for the AUR that for one says that the user agrees to either license the PKGBUILD and accompanying scripts under a specific license, or that they agree to assign copyright to Arch Linux. While it wouldn’t be possible to apply it to the packages already upload, I’d suggest implementing this change during the migration to AUR 4.0.0 when the official AUR will be started afresh, causing all newly uploaded packages to fall under the ToS. Comments? -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/

5 9

Re: [aur-dev] AUR 4 and licensing
by David Manouchehri 13 Apr '15

13 Apr '15

Lukas Fleischer <lfleischer(a)archlinux.org> wrote: > In order to `git push` a package repository, you need to add your SSH > public key to the AUR profile which means you need to log into the web > interface and accept the ToS. No need for something complicated > involving Git hooks and email address filters. You're right, I forgot about that. The only real purpose of having a hook would just be to serve as a reminder. Johannes L?thberg <johannes(a)kyriasis.com> wrote: > This is Git, not SVN. Sorry, I mixed my hooks up. Didn't mean to start a fight with that one. Both Johannes and Dan are right; it's impossible to have a pre-commit hook on the server side, but it's entirely possible to have a pre-receive hook on the server side. I believe both would have the same result if you put `exit 1` in them though (failing to apply commit).

3 3

Re: [aur-dev] AUR 4 and licensing
by David Manouchehri 13 Apr '15

13 Apr '15

> Showing it during a push would be flawed because then it's too late for them not to agree to it. A Git pre-commit hook on the server side should be fine. On the web side of the AUR, a list of accepted ToS users should be kept, and then on every push check to see if they've been added. Reminding users about the GPL on a push probably isn't a bad idea either. I can't remember how to get the current commiter's email address, but the hook would probably look something like this. ``` if [ ! -f /tmp/userlist_accepted/$git_email ]; then printf "Please visit https://aur.archlinux.org/ and accept the terms of service first.\n" exit 1 done printf "All content posted to the AUR must be licensed under GPLv3.\n" ``` If maintaining another list of private email addresses is too much of a pain, just hash them and the list could be public without any privacy concerns (assuming it isn't md5sum or something equally weak).

5 10

Re: [aur-dev] AUR 4 and licensing
by David Manouchehri 12 Apr '15

12 Apr '15

> Alas that wouldn?t work since with AUR 4.0.0 you will use git to upload packages, and can also use git to create them. You still need to create an account on the AUR website before you can use git+ssh to upload a package I believe. Having a Terms of Service Agreement on registration stating that all content uploaded under GPLv3 would likely work.

2 1

[aur-dev] lib32-gtk3 block and no AUR User Guidelines presidence
by Curtis Lee Bolin 11 Apr '15

11 Apr '15

The maintainer of lib32-gtk3, alucryd, recently updated the version to 3.16.1 although it's dependencies are in testing. So now anyone wanting to install something depending on lib32-gtk3 would now be forced to enable the testing repository. In alucryd's comments with another user he seems to be under the impression all users already have lib32-gtk3 installed, and he isn't forcing anyone to update. He is forgetting all of the people that are installing something for the first time that depends on lib32-gtk. They are completely blocked without adding the testing repository. I reviewed the AUR User Guidelines and can find nothing to prevent this type of lapse in logic. This isn't the first time I have seen this issue. Since there isn't a separate testing AUR, can something be added to the AUR User Guidelines maybe stating packages that require the testing repository must have "-testing" added to the name or whatever would best resolve this problem. Thank You For Your Time, Curtis Lee Bolin

4 3

[aur-dev] [PATCH 1/2] Allow users to delete their own packages
by Lukas Fleischer 04 Mar '15

04 Mar '15

Allow users to remove their own package bases for a short period of time after initial submission (defaults to one day). Implements FS#43648. Signed-off-by: Lukas Fleischer <archlinux(a)cryptocrack.de> --- conf/config.proto | 1 + web/lib/pkgbasefuncs.inc.php | 5 +++-- web/lib/pkgreqfuncs.inc.php | 14 ++++++++++++++ 3 files changed, 18 insertions(+), 2 deletions(-) diff --git a/conf/config.proto b/conf/config.proto index b4a381d..95194a7 100644 --- a/conf/config.proto +++ b/conf/config.proto @@ -25,6 +25,7 @@ max_rpc_results = 5000 aur_request_ml = aur-requests(a)archlinux.org request_idle_time = 1209600 auto_orphan_age = 15552000 +auto_delete_age = 86400 [auth] key-prefixes = ssh-rsa ssh-dss ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 ssh-ed25519 diff --git a/web/lib/pkgbasefuncs.inc.php b/web/lib/pkgbasefuncs.inc.php index 5741b01..6f9ef85 100644 --- a/web/lib/pkgbasefuncs.inc.php +++ b/web/lib/pkgbasefuncs.inc.php @@ -436,11 +436,12 @@ function pkgbase_unflag($base_ids) { * @param array $base_ids Array of package base IDs to delete * @param int $merge_base_id Package base to merge the deleted ones into * @param int $via Package request to close upon deletion + * @param bool $grant Allow anyone to delete the package base * * @return array Tuple of success/failure indicator and error message */ -function pkgbase_delete ($base_ids, $merge_base_id, $via) { - if (!has_credential(CRED_PKGBASE_DELETE)) { +function pkgbase_delete ($base_ids, $merge_base_id, $via, $grant=false) { + if (!$grant && !has_credential(CRED_PKGBASE_DELETE)) { return array(false, __("You do not have permission to delete packages.")); } diff --git a/web/lib/pkgreqfuncs.inc.php b/web/lib/pkgreqfuncs.inc.php index a5d6be8..0fab447 100644 --- a/web/lib/pkgreqfuncs.inc.php +++ b/web/lib/pkgreqfuncs.inc.php @@ -184,6 +184,7 @@ function pkgreq_file($ids, $type, $merge_into, $comments) { " Request for " . $row['Name'], $body, $headers); $auto_orphan_age = config_get('options', 'auto_orphan_age'); + $auto_delete_age = config_get('options', 'auto_delete_age'); $details = pkgbase_get_details($base_id); if ($type == 'orphan' && $details['OutOfDateTS'] > 0 && time() - $details['OutOfDateTS'] >= $auto_orphan_age && @@ -201,6 +202,19 @@ function pkgreq_file($ids, $type, $merge_into, $comments) { $q = "UPDATE PackageBases SET MaintainerUID = NULL "; $q.= "WHERE ID = " . $base_id; $dbh->exec($q); + } else if ($type == 'deletion' && $details['MaintainerUID'] == $uid && + $details['SubmittedTS'] > 0 && $auto_delete_age > 0 && + time() - $details['SubmittedTS'] <= $auto_delete_age) { + /* + * Close package request. NOTE: This needs to happen *before* + * the actual deletion operation. Otherwise, the former + * maintainer will not be included in the Cc list of the + * request notification email. + */ + pkgreq_close($request_id, "accepted", + "Deletion of a fresh package requested by its " . + "current maintainer.", true); + pkgbase_delete(array($base_id), NULL, NULL, true); } return array(true, __("Added request successfully.")); -- 2.3.1

1 1

[aur-dev] Remove category support
by Hugo Osvaldo Barrera 28 Feb '15

28 Feb '15

Hi, I've seen mention of removing the categories from the AUR several times in aur-general, and someone mentioned that, while they serve no real purpose, nobody has sent patches either. Well, I gave this a try to see how well I could do and this *seems* to work fine, though more granualar testing may be required (I'll do this if the patch seems ok, and if its goal is deemed acceptable). Feedback is, naturally, greatly appreciated. Cheers, -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text?

6 10

[aur-dev] ./configure --prefix Conventions
by Jashandeep Sohi 11 Feb '15

11 Feb '15

Hi, I was browsing some PKGBUILD on AUR and it seems there are two ways of running the autoconf configure script. One, is the more frequent `./configure --prefix=/usr` and the other is `./configure --prefix=$pkgdir/usr`. I was wondering if one is more correct than the other? Are there any downsides to using the second one? Thanks, Jashandeep Sohi

4 3