Re: [aur-general] Errors on submission: Invalid name: only lowercase letters are allowed

[Ray Rashif]

On 6 February 2011 14:27, andrew thomas  wrote:
> I tried adopted this package (kernel26-yi)
>
> http://aur.archlinux.org/packages.php?ID=37895
>
> But when I tried to upload an updated PKGBUILD. I got rejected with
> "Invalid name: only lowercase letters are allowed"
> I used makepkg --source to generate a file named
> kernel26-yi-2.6.37-1.src.tar.gz.
>
> Why am I receiving this error?

Please pastebin the updated PKGBUILD. And have you disowned it again?
Else, please remember to adopt using the button - you don't adopt a
PKGBUILD by just submitting it.

[aur-general] AUR & Copyright

[Xyne]

Eric Waller wrote:

> I am not a lawyer and I generally tune out all license flame wars.
> That said, PKGBUILDS generally do not contain copyright or license
> declarations.  Unless I am mistaken, that means someone who comes into
> possession of a PKGBUILD does not have the right to republish it.
> 
> As a minimum, I think Arch should get a nod from the creator of a
> PKGBUILD prior to absorbing it into the colective -- It might help
> avoid any misunderstandings.

What is the legal status of files submitted to the AUR? I have always assumed
that anything uploaded to the AUR is automatically licensed under the GPL or
something similar, in the same way that content contributed to the wiki is.

I can't find anything that states this on the AUR site, which is a potentially
calamitous legal oversight.

The legal issue should be cleared up. If we needed to obtain explicit
permission from every contributor then the AUR would cease to be useful. You
would not be able to adopt and update PKGBUILDs without permission, and you
would need to enable users to delete their own PKGBUILDs when they decide to
withdraw permission.

Re: [aur-general] Errors on submission: Invalid name: only lowercase letters are allowed

[andrew thomas]

>On 6 February 2011 14:27, andrew thomas  wrote:
>> I tried adopted this package (kernel26-yi)
>>
>> http://aur.archlinux.org/packages.php?ID=37895
>>
>> But when I tried to upload an updated PKGBUILD. I got rejected with
>> "Invalid name: only lowercase letters are allowed"
>> I used makepkg --source to generate a file named
>> kernel26-yi-2.6.37-1.src.tar.gz.
>>
>> Why am I receiving this error?

> Please pastebin the updated PKGBUILD. And have you disowned it again?
> Else, please remember to adopt using the button - you don't adopt a
> PKGBUILD by just submitting it.

I had adpoted it.  Since I could not update it, I disowned it.

Here is the pastebin

http://archlinux.pastebin.com/h8dMn7ZW

Re: [aur-general] Moving packages to Community

[Xyne]

Ángel Velásquez wrote:

> We eventually show our respect to the author to notice him that we do
> will move your package, but it's arrogant and too stupid to pretend
> that a TU or Dev have to `ask you for permission` <--- THIS IS
> MADNESS, you aren't the owner of that PKGBUILD ! even if you wrote it
> from scratch! the next thing after from asking for permission will be
> "please pay me" .. so hell no.

See Eric Waller's post and my reply to it. Submitters might be the legal owners
of PKGBUILDs, however insane that may be. The AUR does not clearly indicate
that submitted aurballs must be licensed permissively.

Re: [aur-general] Errors on submission: Invalid name: only lowercase letters are allowed

[Andrea Scarpino]

On Sunday 06 February 2011 11:51:41 andrew thomas wrote:
> Here is the pastebin
> 
> http://archlinux.pastebin.com/h8dMn7ZW
You cannot upload splitted PKGBUILD. See FS#16394[1].

https://bugs.archlinux.org/task/16394

-- 
Andrea

Re: [aur-general] AUR & Copyright

[Thomas S Hatch]

You raise a good point, I would think that we would need to post something
on the submit page stating the copyright nature. My brothers are lawyers, I
will check with them as to what the right thing to do is.

-Thomas S Hatch
On Feb 6, 2011 10:49 AM, "Xyne"  wrote:
> Eric Waller wrote:
>
>> I am not a lawyer and I generally tune out all license flame wars.
>> That said, PKGBUILDS generally do not contain copyright or license
>> declarations. Unless I am mistaken, that means someone who comes into
>> possession of a PKGBUILD does not have the right to republish it.
>>
>> As a minimum, I think Arch should get a nod from the creator of a
>> PKGBUILD prior to absorbing it into the colective -- It might help
>> avoid any misunderstandings.
>
> What is the legal status of files submitted to the AUR? I have always
assumed
> that anything uploaded to the AUR is automatically licensed under the GPL
or
> something similar, in the same way that content contributed to the wiki
is.
>
> I can't find anything that states this on the AUR site, which is a
potentially
> calamitous legal oversight.
>
> The legal issue should be cleared up. If we needed to obtain explicit
> permission from every contributor then the AUR would cease to be useful.
You
> would not be able to adopt and update PKGBUILDs without permission, and
you
> would need to enable users to delete their own PKGBUILDs when they decide
to
> withdraw permission.
>

Re: [aur-general] Errors on submission: Invalid name: only lowercase letters are allowed

[Thomas S Hatch]

You can get around the split package bug this way:
https://aur.archlinux.org/packages.php?ID=42514

[aur-general] [Announcement] First public git repo of the complete AUR.

[Thomas Dziedzic]

Hey there Archers,
I decided to work on this little project over the weekend.
It is a complete git clone of the AUR from the source and it will be
updated regularly (at least once a day) though probably as frequent as
30minutes (please see `Side Notes' for explanation).
What this means is that history for the AUR will now be possible!
Also, for those of you wanting to have an abs like tree for all of the
aur, it is now possible.
I hope this opens up new opportunities, and new possibilities for everyone.

To get the complete git repo, run:
git clone git://pkgbuild.com/aur.git

The web interface is at:
http://pkgbuild.com/git/aur.git/

Also, please take a look at the official readme at:
http://pkgbuild.com/~td123/readme

Special Thanks to Ioni for enabling the git server & Bluewind for
setting up the web interface.

Cheers!
-Thomas Dziedzic

Side Note:
Although it will be updated at least once a day, it will most likely
be updated more frequently (around 30 minute intervals with a script),
I just can't guarantee that for now.
Work is ongoing to automate the sync with the aur tree, but at this
moment, there is no secure way of doing this.
Automating the sync will guarantee the intervals between syncs, I am
aiming for around 30 minute to 3 hour intervals between syncs.
A final goal might be to get continuous updates. Enjoy! =)

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[Lukáš Jirkovský]

On 6 February 2011 20:31, Thomas Dziedzic  wrote:
> Hey there Archers,
> I decided to work on this little project over the weekend.
> It is a complete git clone of the AUR from the source and it will be
> updated regularly (at least once a day) though probably as frequent as
> 30minutes (please see `Side Notes' for explanation).
> What this means is that history for the AUR will now be possible!
> Also, for those of you wanting to have an abs like tree for all of the
> aur, it is now possible.
> I hope this opens up new opportunities, and new possibilities for everyone.
>
> To get the complete git repo, run:
> git clone git://pkgbuild.com/aur.git
>
> The web interface is at:
> http://pkgbuild.com/git/aur.git/
>
> Also, please take a look at the official readme at:
> http://pkgbuild.com/~td123/readme
>
> Special Thanks to Ioni for enabling the git server & Bluewind for
> setting up the web interface.
>
> Cheers!
> -Thomas Dziedzic
>
> Side Note:
> Although it will be updated at least once a day, it will most likely
> be updated more frequently (around 30 minute intervals with a script),
> I just can't guarantee that for now.
> Work is ongoing to automate the sync with the aur tree, but at this
> moment, there is no secure way of doing this.
> Automating the sync will guarantee the intervals between syncs, I am
> aiming for around 30 minute to 3 hour intervals between syncs.
> A final goal might be to get continuous updates. Enjoy! =)
>

What's this?
http://pkgbuild.com/git/aur.git/tree/PKGBUILD

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[Lukáš Jirkovský]

2011/2/6 Lukáš Jirkovský :
>
> What's this?
> http://pkgbuild.com/git/aur.git/tree/PKGBUILD
>

It seems there's more:
apercu.tgz

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[Thomas Dziedzic]

2011/2/6 Lukáš Jirkovský :
> 2011/2/6 Lukáš Jirkovský :
>>
>> What's this?
>> http://pkgbuild.com/git/aur.git/tree/PKGBUILD
>>
>
> It seems there's more:
> apercu.tgz
>

Yes, I know, the aur tree isn't completely clean, for now, you will
have to deal with it.

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[Thomas Dziedzic]

2011/2/6 Thomas Dziedzic :
> 2011/2/6 Lukáš Jirkovský :
>> 2011/2/6 Lukáš Jirkovský :
>>>
>>> What's this?
>>> http://pkgbuild.com/git/aur.git/tree/PKGBUILD
>>>
>>
>> It seems there's more:
>> apercu.tgz
>>
>
> Yes, I know, the aur tree isn't completely clean, for now, you will
> have to deal with it.
>

I will try to clean up my rules this evening.

Thanks for your suggestions :)

Re: [aur-general] AUR & Copyright

[Ray Rashif]

On 7 February 2011 02:38, Thomas S Hatch  wrote:
> You raise a good point, I would think that we would need to post something
> on the submit page stating the copyright nature. My brothers are lawyers, I
> will check with them as to what the right thing to do is.
>
> -Thomas S Hatch
> On Feb 6, 2011 10:49 AM, "Xyne"  wrote:
>> Eric Waller wrote:
>>
>>> I am not a lawyer and I generally tune out all license flame wars.
>>> That said, PKGBUILDS generally do not contain copyright or license
>>> declarations. Unless I am mistaken, that means someone who comes into
>>> possession of a PKGBUILD does not have the right to republish it.
>>>
>>> As a minimum, I think Arch should get a nod from the creator of a
>>> PKGBUILD prior to absorbing it into the colective -- It might help
>>> avoid any misunderstandings.
>>
>> What is the legal status of files submitted to the AUR? I have always
> assumed
>> that anything uploaded to the AUR is automatically licensed under the GPL
> or
>> something similar, in the same way that content contributed to the wiki
> is.
>>
>> I can't find anything that states this on the AUR site, which is a
> potentially
>> calamitous legal oversight.
>>
>> The legal issue should be cleared up. If we needed to obtain explicit
>> permission from every contributor then the AUR would cease to be useful.
> You
>> would not be able to adopt and update PKGBUILDs without permission, and
> you
>> would need to enable users to delete their own PKGBUILDs when they decide
> to
>> withdraw permission.
>>
>

Err..it is as relaxed as the wiki. I don't see why any question about
ownership should arise. If someone wants to claim ownership and not be
willing to share then so be it (don't even upload to AUR then). She
will have a bad reputation, not our problem.

Re: [aur-general] AUR & Copyright

[François Boulogne]

Le 06/02/2011 18:48, Xyne a écrit :
> Eric Waller wrote:
>
>> I am not a lawyer and I generally tune out all license flame wars.
>> That said, PKGBUILDS generally do not contain copyright or license
>> declarations.  Unless I am mistaken, that means someone who comes into
>> possession of a PKGBUILD does not have the right to republish it.
>>
>> As a minimum, I think Arch should get a nod from the creator of a
>> PKGBUILD prior to absorbing it into the colective -- It might help
>> avoid any misunderstandings.
> What is the legal status of files submitted to the AUR? I have always assumed
> that anything uploaded to the AUR is automatically licensed under the GPL or
> something similar, in the same way that content contributed to the wiki is.
>
> I can't find anything that states this on the AUR site, which is a potentially
> calamitous legal oversight.
>
> The legal issue should be cleared up. If we needed to obtain explicit
> permission from every contributor then the AUR would cease to be useful. You
> would not be able to adopt and update PKGBUILDs without permission, and you
> would need to enable users to delete their own PKGBUILDs when they decide to
> withdraw permission.
>
>

There is also the specific problem of patches. From developpers of
another linux distribution, I heard that the empirical rule is that the 
patch is released under the software licence. (So, it could be used by
upstream)

-- 
François Boulogne.

Membre de l'April - Promouvoir et défendre le logiciel libre
http://www.april.org 

Re: [aur-general] AUR & Copyright

[Cédric Girard]

On Sun, Feb 6, 2011 at 8:47 PM, Ray Rashif  wrote:

> Err..it is as relaxed as the wiki. I don't see why any question about
> ownership should arise. If someone wants to claim ownership and not be
> willing to share then so be it (don't even upload to AUR then). She
> will have a bad reputation, not our problem.
>

You can't say that. If someone decide to claim ownership to the PKGBUILD he
wrote and nothing has been done to clear the ownership issue before, the
reputation of this guy would be the last thing to worry about for Arch
Linux.

Considering the wiki, it is clearly stated as being under the GNU Free
Documentation License 1.2.

Regards,
-- 
Cédric Girard

Re: [aur-general] AUR & Copyright

[Bernardo Barros]

2011/2/6 Xyne :
> What is the legal status of files submitted to the AUR? I have always assumed
> that anything uploaded to the AUR is automatically licensed under the GPL or
> something similar, in the same way that content contributed to the wiki is.

Ownership and authorship aren't the same. In the first place the GPL
lisence requires the copyright notice to exist. It is actually based
on authorship, the first line is a copyright notice. And there is
nothing bad about it.

Anyway atributing the work is a good thing. Good people atributive the
works of their friends. Of course, if you revise the code in a not
superficial way you also have some authorship in that piece of code,
then it's a team work.

Or... you can interpret that the buildscript are Public Domain, then
Arch, TU, IBM, Apple  etc., all can use it without atributing
anything. But since it is only useful for Arch users in the end... it
is the same thing in practice.

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[Thomas S Hatch]

2011/2/6 Thomas Dziedzic 

> 2011/2/6 Thomas Dziedzic :
> > 2011/2/6 Lukáš Jirkovský :
> >> 2011/2/6 Lukáš Jirkovský :
> >>>
> >>> What's this?
> >>> http://pkgbuild.com/git/aur.git/tree/PKGBUILD
> >>>
> >>
> >> It seems there's more:
> >> apercu.tgz
> >>
> >
> > Yes, I know, the aur tree isn't completely clean, for now, you will
> > have to deal with it.
> >
>
> I will try to clean up my rules this evening.
>
> Thanks for your suggestions :)
>

This is awesome, thanks!

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[Bernardo Barros]

Very good idea, I will check it out.

AUR was under some kind of version control before or it never was?

Re: [aur-general] AUR & Copyright

[Ray Rashif]

2011/2/7 Cédric Girard :
> On Sun, Feb 6, 2011 at 8:47 PM, Ray Rashif  wrote:
>
>> Err..it is as relaxed as the wiki. I don't see why any question about
>> ownership should arise. If someone wants to claim ownership and not be
>> willing to share then so be it (don't even upload to AUR then). She
>> will have a bad reputation, not our problem.
>>
>
> You can't say that. If someone decide to claim ownership to the PKGBUILD he
> wrote and nothing has been done to clear the ownership issue before, the
> reputation of this guy would be the last thing to worry about for Arch
> Linux.
>
> Considering the wiki, it is clearly stated as being under the GNU Free
> Documentation License 1.2.

Sorry, bad comparison, then. I'm not really sure what to compare it
with. We've never had to talk about things like this before (so
probably the time has come you would say). First of all, we've never
had people claiming "rights" to PKGBUILDs.

Re: [aur-general] AUR & Copyright

[Thomas S Hatch]

On Sun, Feb 6, 2011 at 1:10 PM, Bernardo Barros
wrote:

> 2011/2/6 Xyne :
> > What is the legal status of files submitted to the AUR? I have always
> assumed
> > that anything uploaded to the AUR is automatically licensed under the GPL
> or
> > something similar, in the same way that content contributed to the wiki
> is.
>
> Ownership and authorship aren't the same. In the first place the GPL
> lisence requires the copyright notice to exist. It is actually based
> on authorship, the first line is a copyright notice. And there is
> nothing bad about it.
>
> Anyway atributing the work is a good thing. Good people atributive the
> works of their friends. Of course, if you revise the code in a not
> superficial way you also have some authorship in that piece of code,
> then it's a team work.
>
> Or... you can interpret that the buildscript are Public Domain, then
> Arch, TU, IBM, Apple  etc., all can use it without atributing
> anything. But since it is only useful for Arch users in the end... it
> is the same thing in practice.
>


Realy I think that this is a simple thing, that we should just post some
statement that says that anything uploaded to the AUR can be absorbed into
the Arch Linux distribution. When PKGBUILDS are in the AUR I could care less
who's they are, but they are Arch Linux's when they are moved to
community/extra/core.
So my initial thought would be that the submit page just needs to say - in
effect - "Dude, we can move your package into the main distribution whenever
we want to and it will be assimilated, this should be cool with you, because
Arch is the best"

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[Thomas Dziedzic]

On Sun, Feb 6, 2011 at 2:15 PM, Bernardo Barros
 wrote:
> Very good idea, I will check it out.
>
> AUR was under some kind of version control before or it never was?
>

I think it was never.

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[Thomas Dziedzic]

2011/2/6 Lukáš Jirkovský :
> 2011/2/6 Lukáš Jirkovský :
>>
>> What's this?
>> http://pkgbuild.com/git/aur.git/tree/PKGBUILD
>>
>
> It seems there's more:
> apercu.tgz
>

Since this clean up is more of an aur tree issue, not mine, it has to
be done remotely to do it properly.

Somebody ran a clean up script as evidenced by this commit :P
http://pkgbuild.com/git/aur.git/commit/?id=19c10dddf1c78cb14f958e02cd6a4b2061db2c34

The only leftover files are the .tgz files which will also have to get
cleaned up in the main aur tree. Thanks again!

Re: [aur-general] AUR & Copyright

[Gaetan Bisson]

[2011-02-06 13:22:20 -0700] Thomas S Hatch:
> Realy I think that this is a simple thing, that we should just post some
> statement that says that anything uploaded to the AUR can be absorbed into
> the Arch Linux distribution.

This disclaimer should not be limited to Arch, IMHO: sister projects
might also benefit from importing AUR stuff. I would suggest something
like:

"By uploading content to the Arch User Repository, you irrevocably agree
to release it in the public domain, to the extent permitted by law."

-- 
Gaetan

Re: [aur-general] AUR & Copyright

[Bernardo Barros]

2011/2/6 Gaetan Bisson :
> "By uploading content to the Arch User Repository, you irrevocably agree
> to release it in the public domain, to the extent permitted by law."

GPL would do no harm to Arch either. And pieces of code with less then
10 lines can't have any copyright. The difference in practice is
minimal, since it is very unlikely that this piece of code would
integrate a non-free software, even including big patches and tricky
things. The pratical differente I can see is the need to keep the
attribution when it makes sense. If you rewrite everything from
scratch, you are the author anyway.

Re: [aur-general] AUR & Copyright

[Gaetan Bisson]

[2011-02-06 19:28:38 -0200] Bernardo Barros:
> 2011/2/6 Gaetan Bisson :
> > "By uploading content to the Arch User Repository, you irrevocably agree
> > to release it in the public domain, to the extent permitted by law."
> 
> GPL would do no harm to Arch either. And pieces of code with less then
> 10 lines can't have any copyright. The difference in practice is
> minimal, since it is very unlikely that this piece of code would
> integrate a non-free software, even including big patches and tricky
> things.

Since there is little difference, why choose a complicated license such
as the GPL over the (much simpler) public domain?

> The pratical differente I can see is the need to keep the
> attribution when it makes sense. If you rewrite everything from
> scratch, you are the author anyway.

Rewriting from scratch is okay for one PKGBUILD, but I believe we should
also allow people to copy the whole database.

-- 
Gaetan

Re: [aur-general] AUR & Copyright

[Magnus Therning]

On 06/02/11 21:41, Gaetan Bisson wrote:
> [2011-02-06 19:28:38 -0200] Bernardo Barros:
>> 2011/2/6 Gaetan Bisson :
>>> "By uploading content to the Arch User Repository, you irrevocably
>>> agree to release it in the public domain, to the extent permitted
>>> by law."
>>
>> GPL would do no harm to Arch either. And pieces of code with less
>> then 10 lines can't have any copyright. The difference in practice
>> is minimal, since it is very unlikely that this piece of code would
>> integrate a non-free software, even including big patches and
>> tricky things.
>
> Since there is little difference, why choose a complicated license
> such as the GPL over the (much simpler) public domain?

IANAL, but probably because the concept of an author releasing
something to "public domain" doesn't exist in all jurisdictions.

So it's arguably safer to pick a license, but I agree that the GPL
might be too complicated, why not use BSD?

/M

-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] AUR & Copyright

[Bernardo Barros]

Yes, but since you can't change a licence (from BSD to GPL), then
Apple can just download the entire Arch repository code to adapt and
use in their AppStore code, for example. Very unlikely, but possible
since you can use PKGBUILD on OSX.

[aur-general] [Remove] pngout-static

[Lou]

Yarr. Yet Another Removal Request.

pngout-static
http://aur.archlinux.org/packages.php?ID=38726

I adopted this package yesterday, but uploaded a new one simply called
"pngout". Thanks.

Hail Arch.

Re: [aur-general] [Remove] pngout-static

[Evangelos Foutras]

On Sun, Feb 6, 2011 at 11:51 PM, Lou  wrote:
> pngout-static
> http://aur.archlinux.org/packages.php?ID=38726
>
> I adopted this package yesterday, but uploaded a new one simply called
> "pngout". Thanks.

Done, thanks.

[aur-general] Standardized CPAN Package Versions

[Xyne]

Hi,

I have CC'd this to aur-general as this concerns all CPAN packagers on Arch.

CPAN package versions are a mess on Arch Linux. It seems that many if not most
CPAN packagers on Arch are unaware of how CPAN deals with versions and thus
they do not correctly translate the CPAN version. Most of the time a naive
translation is used instead, and this prevents Pacman from working correctly.

To give an example, CPAN considers "1.15" to be a later version than "1.23.0",
whereas Pacman will consider the latter version the newer version. This is
because "1.15" is short for "1.150" on CPAN, whereas "1.23.0" is short for
"1.023.0". This can be confirmed using the "version" module[1].

I have written a simple Perl script[2] that addresses this issue.* It accepts
CPAN versions as command-line arguments and prints out standardized Pacman
package versions. The package versions enable Pacman to correctly compare CPAN
packages, e.g. when resolving minimal dependencies.

I propose that the script be packaged and made an official tool for Perl
package developers.** It should also be included on the Perl Package Guidelines
wiki page[3].

I hope that this will be seriously considered as it addresses a real issue.
Tools that generate CPAN packages for Pacman (e.g. Bauerbill) cannot work
properly when there is no consistency in how Arch packages are versioned.

Please note as well that this is completely separate from my previous (and
continued) contention regarding the "provides" array of CPAN packages.

Regards,
Xyne


[1]: http://search.cpan.org/~jpeacock/version-0.88/
[2]: http://xyne.archlinux.ca/scripts/pacman/ver_cpan2pacman
[3]: https://wiki.archlinux.org/index.php/Perl_Package_Guidelines

* The script only depends on Perl. The name and license are preliminary. I will
  gladly change both to something more suitable.

* I would be willing to maintain it, but an official tool should probably be
  included in [core] or [extra], not [community]. 

Re: [aur-general] AUR & Copyright

[Xyne]

On 2011-02-06 19:48 -0200 (05:7)
Bernardo Barros wrote:

> Yes, but since you can't change a licence (from BSD to GPL), then
> Apple can just download the entire Arch repository code to adapt and
> use in their AppStore code, for example. Very unlikely, but possible
> since you can use PKGBUILD on OSX.


I agree that the simpler, the better, Most PKGBUILDs are not worth copyrighting
anyway. The key point is to make sure that all PKGBuILDs can be used freely by
Arch.

The other point is that all previously submitted PKGBUILDs are in a legal grey
area if there has never been such a disclaimer. It bothers me that the project
is apparently exposed to potential legal trolls, even if it is unlikely that
anything will happen.

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[keenerd]

On 2/6/11, Thomas Dziedzic  wrote:
> Hey there Archers,
> I decided to work on this little project over the weekend.
> It is a complete git clone of the AUR from the source and it will be
> updated regularly (at least once a day) though probably as frequent as
> 30minutes (please see `Side Notes' for explanation).
> What this means is that history for the AUR will now be possible!
> Also, for those of you wanting to have an abs like tree for all of the
> aur, it is now possible.
> I hope this opens up new opportunities, and new possibilities for everyone.

This is awesome.  Glad to see some official support for such crazy
stuff.  The change sets look much more impressive than I thought they
would.  There is still the Hard Problem of getting write access
control for 20k accounts and grafting a comment system onto git (both
of which were really discouraging when I tried solving it) but today
is a huge win for CLI usability in Arch.

I am also glad to see it done, as now version tracking can be removed
from the list of silly-things-for-AUR3-to-try as there is no reason
for me to duplicate efforts :-)

-Kyle
http://kmkeen.com

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[Loui Chang]

On Sun 06 Feb 2011 14:34 -0600, Thomas Dziedzic wrote:
> 2011/2/6 Lukáš Jirkovský :
> > 2011/2/6 Lukáš Jirkovský :
> >>
> >> What's this?
> >> http://pkgbuild.com/git/aur.git/tree/PKGBUILD
> >
> > It seems there's more:
> > apercu.tgz
> 
> Since this clean up is more of an aur tree issue, not mine, it has to
> be done remotely to do it properly.
> 
> Somebody ran a clean up script as evidenced by this commit :P
> http://pkgbuild.com/git/aur.git/commit/?id=19c10dddf1c78cb14f958e02cd6a4b2061db2c34

That was me hehe. I was curious to see what would happen.
So it looks like you're just copying over what's in the filesystem.
It might be a good idea to work with aur-dev to help make the source
cleaner, then everyone can benefit - even those who don't use your git
repo.

You probably want to grab the tarballs, and extract what's in those.
The next release of the AUR will only have tarballs and PKGBUILDs.
The other files won't be extracted.

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[keenerd]

On 2/6/11, Loui Chang  wrote:
> You probably want to grab the tarballs, and extract what's in those.
> The next release of the AUR will only have tarballs and PKGBUILDs.
> The other files won't be extracted.

Hey, you are stealing my idea!  :-)  AUR3 does that, and it saves
several hundred megabytes.  Completely worth it.

-Kyle
http://kmkeen.com

[aur-general] AUR & Copyright

[Nicky726]

If I may add my two cents, I would go for GPL for PKGBUILDs, as it ensures 
stuff remains OSS. Though some broader discussion/voting may be good. And a 
compromise in form of selection from OSS licences when uploading, defaulting 
to one could not be that hard to implement.

Nicky
-- 
Don't it always seem to go
That you don't know what you've got
Till it's gone

(Joni Mitchell)

Re: [aur-general] AUR & Copyright

[Bernardo Barros]

2011/2/6 Xyne :
> I agree that the simpler, the better, Most PKGBUILDs are not worth 
> copyrighting
> anyway. The key point is to make sure that all PKGBuILDs can be used freely by
> Arch.

BSD is also copyright, isn't it?


Copyright  . All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are
permitted provided that the following conditions are met:

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[Thomas Dziedzic]

On Sun, Feb 6, 2011 at 4:43 PM, Loui Chang  wrote:
> On Sun 06 Feb 2011 14:34 -0600, Thomas Dziedzic wrote:
>> 2011/2/6 Lukáš Jirkovský :
>> > 2011/2/6 Lukáš Jirkovský :
>> >>
>> >> What's this?
>> >> http://pkgbuild.com/git/aur.git/tree/PKGBUILD
>> >
>> > It seems there's more:
>> > apercu.tgz
>>
>> Since this clean up is more of an aur tree issue, not mine, it has to
>> be done remotely to do it properly.
>>
>> Somebody ran a clean up script as evidenced by this commit :P
>> http://pkgbuild.com/git/aur.git/commit/?id=19c10dddf1c78cb14f958e02cd6a4b2061db2c34
>
> That was me hehe. I was curious to see what would happen.
> So it looks like you're just copying over what's in the filesystem.
> It might be a good idea to work with aur-dev to help make the source
> cleaner, then everyone can benefit - even those who don't use your git
> repo.
>
> You probably want to grab the tarballs, and extract what's in those.
> The next release of the AUR will only have tarballs and PKGBUILDs.
> The other files won't be extracted.
>
>

So PKGBUILDs aren't going to be able to be viewed?

Re: [aur-general] AUR & Copyright

[Xyne]

Ray Rashif wrote:

> Sorry, bad comparison, then. I'm not really sure what to compare it
> with. We've never had to talk about things like this before (so
> probably the time has come you would say). First of all, we've never
> had people claiming "rights" to PKGBUILDs.

I agree that it is unlikely to be a problem, but the best thing to do is
deal with the eventuality rather than continue with naive optimism.

What needs to be done, imo:
* decide on a permissive license or public domain for submitted files
* add a clearly visible notification
* add a note concerning the submission of files that cannot be redistributed,
  e.g. a copyrighted icon included in the upload
* hope that no previous author ever shows up to claim copyright before the
  addition of the notice

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[Thomas Dziedzic]

On Sun, Feb 6, 2011 at 5:19 PM, Thomas Dziedzic  wrote:
> On Sun, Feb 6, 2011 at 4:43 PM, Loui Chang  wrote:
>> On Sun 06 Feb 2011 14:34 -0600, Thomas Dziedzic wrote:
>>> 2011/2/6 Lukáš Jirkovský :
>>> > 2011/2/6 Lukáš Jirkovský :
>>> >>
>>> >> What's this?
>>> >> http://pkgbuild.com/git/aur.git/tree/PKGBUILD
>>> >
>>> > It seems there's more:
>>> > apercu.tgz
>>>
>>> Since this clean up is more of an aur tree issue, not mine, it has to
>>> be done remotely to do it properly.
>>>
>>> Somebody ran a clean up script as evidenced by this commit :P
>>> http://pkgbuild.com/git/aur.git/commit/?id=19c10dddf1c78cb14f958e02cd6a4b2061db2c34
>>
>> That was me hehe. I was curious to see what would happen.
>> So it looks like you're just copying over what's in the filesystem.
>> It might be a good idea to work with aur-dev to help make the source
>> cleaner, then everyone can benefit - even those who don't use your git
>> repo.
>>
>> You probably want to grab the tarballs, and extract what's in those.
>> The next release of the AUR will only have tarballs and PKGBUILDs.
>> The other files won't be extracted.
>>
>>
>
> So PKGBUILDs aren't going to be able to be viewed?
>

Nvm, I read your mail wrong.

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[Thomas Dziedzic]

On Sun, Feb 6, 2011 at 4:58 PM, keenerd  wrote:
> On 2/6/11, Loui Chang  wrote:
>> You probably want to grab the tarballs, and extract what's in those.
>> The next release of the AUR will only have tarballs and PKGBUILDs.
>> The other files won't be extracted.
>
> Hey, you are stealing my idea!  :-)  AUR3 does that, and it saves
> several hundred megabytes.  Completely worth it.
>
> -Kyle
> http://kmkeen.com
>

I fail to see how this is worth it, imo, a better system is to convert
to git and not track the src.tar.gz

Is there a good reason for this switch? To save 450mb is not a good
reason imo, for an incomplete listing of all the files.

-Thomas

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[Loui Chang]

On Sun 06 Feb 2011 17:19 -0600, Thomas Dziedzic wrote:
> On Sun, Feb 6, 2011 at 4:43 PM, Loui Chang  wrote:
> > On Sun 06 Feb 2011 14:34 -0600, Thomas Dziedzic wrote:
> >> 2011/2/6 Lukáš Jirkovský :
> >> > 2011/2/6 Lukáš Jirkovský :
> >> >>
> >> >> What's this?
> >> >> http://pkgbuild.com/git/aur.git/tree/PKGBUILD
> >> >
> >> > It seems there's more:
> >> > apercu.tgz
> >>
> >> Since this clean up is more of an aur tree issue, not mine, it has to
> >> be done remotely to do it properly.
> >>
> >> Somebody ran a clean up script as evidenced by this commit :P
> >> http://pkgbuild.com/git/aur.git/commit/?id=19c10dddf1c78cb14f958e02cd6a4b2061db2c34
> >
> > That was me hehe. I was curious to see what would happen.
> > So it looks like you're just copying over what's in the filesystem.
> > It might be a good idea to work with aur-dev to help make the source
> > cleaner, then everyone can benefit - even those who don't use your git
> > repo.
> >
> > You probably want to grab the tarballs, and extract what's in those.
> > The next release of the AUR will only have tarballs and PKGBUILDs.
> > The other files won't be extracted.
> 
> So PKGBUILDs aren't going to be able to be viewed?

Yes they will, but not the other files.

Re: [aur-general] [Announcement] First public git repo of the complete AUR.

[Loui Chang]

On Sun 06 Feb 2011 17:52 -0600, Thomas Dziedzic wrote:
> On Sun, Feb 6, 2011 at 4:58 PM, keenerd  wrote:
> > On 2/6/11, Loui Chang  wrote:
> >> You probably want to grab the tarballs, and extract what's in those.
> >> The next release of the AUR will only have tarballs and PKGBUILDs.
> >> The other files won't be extracted.
> >
> > Hey, you are stealing my idea!  :-)  AUR3 does that, and it saves
> > several hundred megabytes.  Completely worth it.
> 
> I fail to see how this is worth it, imo, a better system is to convert
> to git and not track the src.tar.gz
>
> Is there a good reason for this switch? To save 450mb is not a good
> reason imo, for an incomplete listing of all the files.

Well, there are several reasons. Lukas' commit message from commit ec0dfc2
briefly summarizes it.

> Automatic tarball extraction was vulnerable in different ways. Users
> should also only use source tarballs to build packages, so this has
> been removed completely. From now on, only the PKGBUILD is extracted
> in a secure manner.

Also,

I'm not really sure that git is the best way to distribute source
packages, but I'm glad that you're exploring different options. :D

If I want to obtain or share a few build scripts for a few packages I
really don't want to keep a 450mb repo.

I have heard about shallow checkouts being implemented in git though, so
maybe it could work. devtools uses subversion at least partially because
of this large checkout issue.

Re: [aur-general] AUR & Copyright

[Eric Waller]

Well, I was reluctant to start this -- As I stated, I tend to tune out
long philosophical license debates.

I am pleased in reading this thread that we are all in violent
agreement.  Arch is good -- Sharing is good -- Protecting our
community is good -- giving credit where credit is due is good.  I am
in favor of any mechanism that supports these.

I am pleased with the rational, professional attitudes all the way around.
Kudos to all...

Re: [aur-general] Standardized CPAN Package Versions

[Kaiting Chen]

On Sun, Feb 6, 2011 at 5:16 PM, Xyne  wrote:

> I have CC'd this to aur-general as this concerns all CPAN packagers on
> Arch.
>
> CPAN package versions are a mess on Arch Linux. It seems that many if not
> most
> CPAN packagers on Arch are unaware of how CPAN deals with versions and thus
> they do not correctly translate the CPAN version. Most of the time a naive
> translation is used instead, and this prevents Pacman from working
> correctly.
>
> To give an example, CPAN considers "1.15" to be a later version than
> "1.23.0",
> whereas Pacman will consider the latter version the newer version. This is
> because "1.15" is short for "1.150" on CPAN, whereas "1.23.0" is short for
> "1.023.0". This can be confirmed using the "version" module[1].
>
> I have written a simple Perl script[2] that addresses this issue.* It
> accepts
> CPAN versions as command-line arguments and prints out standardized Pacman
> package versions. The package versions enable Pacman to correctly compare
> CPAN
> packages, e.g. when resolving minimal dependencies.
>
> I propose that the script be packaged and made an official tool for Perl
> package developers.** It should also be included on the Perl Package
> Guidelines
> wiki page[3].
>
> I hope that this will be seriously considered as it addresses a real issue.
> Tools that generate CPAN packages for Pacman (e.g. Bauerbill) cannot work
> properly when there is no consistency in how Arch packages are versioned.
>
> Please note as well that this is completely separate from my previous (and
> continued) contention regarding the "provides" array of CPAN packages.
>

I hate to ask but if it's to be official, do you have any unit tests?
--Kaiting.

-- 
Kiwis and Limes: http://kaitocracy.blogspot.com/

Re: [aur-general] Standardized CPAN Package Versions

[Justin Davis]

On Sun, Feb 6, 2011 at 5:16 PM, Xyne  wrote:
> Hi,
>
> I have CC'd this to aur-general as this concerns all CPAN packagers on Arch.
>
> CPAN package versions are a mess on Arch Linux. It seems that many if not most
> CPAN packagers on Arch are unaware of how CPAN deals with versions and thus
> they do not correctly translate the CPAN version. Most of the time a naive
> translation is used instead, and this prevents Pacman from working correctly.
>
> To give an example, CPAN considers "1.15" to be a later version than "1.23.0",
> whereas Pacman will consider the latter version the newer version. This is
> because "1.15" is short for "1.150" on CPAN, whereas "1.23.0" is short for
> "1.023.0". This can be confirmed using the "version" module[1].
>

Could you give real-life examples? I have not seen a case where CPAN
is confused by that. You seem to be saying that the packagers are at
fault here but I always blamed the CPAN module authors. From what I
remember, the biggest problem is when changing the number of digits.
For example, if you go 0.8, 0.9, to 0.10. Ding. Bad. Switching from
decimal to dotted decimal (multiple decimal points) also has problems.

Regarding the "version" module, ou will get different results using
the older "qv" function. I assume you are using the "parse"
class-method. Some old code still uses "qv" I imagine. I need to
convert some of mine, for example. I will have to look carefully at
this behavior before I do.

How do you know that CPAN uses the version module for comparing
versions? Again, do you have an example of bad version comparison CPAN
is performing?

Self-indulgent side-story: I once suspected CPAN used the date a
package was uploaded for comparing versions. This is half true. Look
at the Taint module: http://search.cpan.org/dist/Taint/ the only
example I know of. The latest version is older in age than the other
two versions on CPAN. Which one is downloaded? 0.9, the highest
version which is also the one with the oldest upload date. Which one
is displayed first? 0.7, the version uploaded most recently.

> I have written a simple Perl script[2] that addresses this issue.* It accepts
> CPAN versions as command-line arguments and prints out standardized Pacman
> package versions. The package versions enable Pacman to correctly compare CPAN
> packages, e.g. when resolving minimal dependencies.
>

Because I do not understand the problem very well I have a hard time
deciding if your script fixes it.
-- 
-Justin

Re: [aur-general] Standardized CPAN Package Versions

[Kaiting Chen]

On Sun, Feb 6, 2011 at 7:52 PM, Kaiting Chen  wrote:

> I hate to ask but if it's to be official, do you have any unit tests?
>

I realize that all it does is hook into the 'version' module and resolves
some underscore business. But tests make everyone feel better, even though
no one likes writing them. --Kaiting.

-- 
Kiwis and Limes: http://kaitocracy.blogspot.com/

Re: [aur-general] AUR & Copyright

[Kaiting Chen]

On Sun, Feb 6, 2011 at 5:36 PM, Xyne  wrote:

> I agree that the simpler, the better, Most PKGBUILDs are not worth
> copyrighting
> anyway. The key point is to make sure that all PKGBuILDs can be used freely
> by
> Arch.
>

I vote that future PKGBUILD's uploaded to the AUR simply include '# All
rights relinquished' or something similar. One line to settle things once
and for all. --Kaiting.

-- 
Kiwis and Limes: http://kaitocracy.blogspot.com/

Re: [aur-general] AUR & Copyright

[Ángel Velásquez]

2011/2/6 Nicky726 :
> If I may add my two cents, I would go for GPL for PKGBUILDs, as it ensures
> stuff remains OSS. Though some broader discussion/voting may be good. And a
> compromise in form of selection from OSS licences when uploading, defaulting
> to one could not be that hard to implement.
>
> Nicky
> --
> Don't it always seem to go
> That you don't know what you've got
> Till it's gone
>
> (Joni Mitchell)
>

Why you didn't reply on the thread ? :S now this thread is splitted
without reason

-- 
Angel Velásquez
angvp @ irc.freenode.net
Arch Linux Developer / Trusted User
Linux Counter: #359909
http://www.angvp.com

Re: [aur-general] AUR & Copyright

[Ray Rashif]

On 7 February 2011 07:21, Xyne  wrote:
> Ray Rashif wrote:
>
>> Sorry, bad comparison, then. I'm not really sure what to compare it
>> with. We've never had to talk about things like this before (so
>> probably the time has come you would say). First of all, we've never
>> had people claiming "rights" to PKGBUILDs.
>
> I agree that it is unlikely to be a problem, but the best thing to do is
> deal with the eventuality rather than continue with naive optimism.
>
> What needs to be done, imo:
> * decide on a permissive license or public domain for submitted files
> * add a clearly visible notification
> * add a note concerning the submission of files that cannot be redistributed,
>  e.g. a copyrighted icon included in the upload
> * hope that no previous author ever shows up to claim copyright before the
>  addition of the notice

Here is what Gentoo does for all their official ebuilds [1]:

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

This also appears in all third-party ebuilds [2], so I would assume
one written by an individual and distributed by itself would contain
this same license note.

In order for something like this to work for Arch, aside from official
and third-party repositories, the AUR needs to (1) reject PKGBUILDs
without the license header, (2) inject the header to every submitted
PKGBUILD, or (3) display a note and assume contributors will take the
initiative. None of those appeal to me, personally, but as far as this
subject is concerned I abstain :)

[1] http://gentoo-portage.com/
[2] http://en.gentoo-wiki.com/wiki/List_of_overlays

Re: [aur-general] Standardized CPAN Package Versions

[Xyne]

Justin Davis wrote:

> Could you give real-life examples? I have not seen a case where CPAN
> is confused by that. You seem to be saying that the packagers are at
> fault here but I always blamed the CPAN module authors. From what I
> remember, the biggest problem is when changing the number of digits.
> For example, if you go 0.8, 0.9, to 0.10. Ding. Bad. Switching from
> decimal to dotted decimal (multiple decimal points) also has problems.

You seem to think that I am saying that the versions on CPAN are wrong. I am
not. I am saying that Arch packagers do not understand the CPAN version schemes
and thus fail to correctly convert CPAN versions to Pacman package versions
($pkgver).

For example, a CPAN package could be update from 0.199 to 0.2. Pacman will
consider 0.199 to be the newer version, e.g.:

$ vercmp 0.199 0.2
1

A "force" flag would thus be required to update the package. The standardized
versions would be 0.199 and 0.200, which pacman can correctly compare.

The whole point of this is that CPAN has a very specific versioning scheme that
does not directly translate to Arch. It has syntax for major versions, minor
versions, alpha versions, etc. They is also a mixture of different syntax due
to legacy version strings that have not been updated. The provided script can
generate standardized versions using the "version" module which was designed
for this, and which is distributed as part of the Perl distribution and can
thus be considered official itself.


As the developer of tools to package CPAN packages for Pacman
automatically (Pacpan and Bauerbill), I can assure you that the the lack of
standardized versions in Arch poses a real-world problem. There is no way to
reliably generate PKGBUILDs with versioned dependencies as long as there
is no standard conversions.

The versions on CPAN can be directly compared using the version module. We must
format versions in a way that Pacman can compare, and that is what this script
does.

Regards,
Xyne

Re: [aur-general] Standardized CPAN Package Versions

[Xyne]

Kaiting Chen wrote:

> On Sun, Feb 6, 2011 at 7:52 PM, Kaiting Chen  wrote:
> 
> > I hate to ask but if it's to be official, do you have any unit tests?
> >
> 
> I realize that all it does is hook into the 'version' module and resolves
> some underscore business. But tests make everyone feel better, even though
> no one likes writing them. --Kaiting.

I'm sorry, but I consider this a nonsensical pseudo-technical question.

As mentioned in my other reply, the "version" module is part of the official
Perl distribution (and thus included in the "perl" package). It can therefore
be considered official and it should be stable, and therefor so should its
output when parsing versions.

The function in my script is extremely simple. It does the following:
* checks if the passed version is defined
* checks if the passed version can be parsed by "version"
* converts the version to a pure decimal form with "numify" from version
* replaces the underscore (representing an alpha version) with "a" (see
  Pacman's documentation if you do not know how it treats letters in versions)
* inserts a decimal point between the major and minor version numbers, which
  formats all versions to x.xxx or x.xxx.xxx

The last two steps are the only extras. Everything else is within the "version"
module.

The replacement of "_" with "a" follows directly from the meaning of "_" on
CPAN and the way Pacman handles letters in versions as alpha releases.

The final step provides a standardized package version that Pacman can
understand and which is the most human-readable.

Both of the final steps are simple linear transformations. Where exactly would
you like to see unit tests for this script?


Regards,
Xyne

[aur-general] deletion request

[Seven Seven]

Please delete kde`s pkg:
http://aur.archlinux.org/packages.php?ID=19552
http://aur.archlinux.org/packages.php?ID=36568
http://aur.archlinux.org/packages.php?ID=46070
Thanks

Re: [aur-general] deletion request

[Thomas S Hatch]

On Sun, Feb 6, 2011 at 8:41 PM, Seven Seven  wrote:

> Please delete kde`s pkg:
> http://aur.archlinux.org/packages.php?ID=19552
> http://aur.archlinux.org/packages.php?ID=36568
> http://aur.archlinux.org/packages.php?ID=46070
> Thanks
>
Annihilated, thanks

Re: [aur-general] Standardized CPAN Package Versions

[Kaiting Chen]

On Sun, Feb 6, 2011 at 8:57 PM, Xyne  wrote:

>  Both of the final steps are simple linear transformations. Where exactly
> would
> you like to see unit tests for this script?
>

Ahh, never mind Xyne. I didn't really understand the (extended) regex at the
bottom which is why I asked, but taking another look it seems like it's
pretty simple and if you feel confident that it will produce vercmp correct
behavior then I'll take your word for it. --Kaiting.

-- 
Kiwis and Limes: http://kaitocracy.blogspot.com/

Re: [aur-general] Standardized CPAN Package Versions

[Justin Davis]

On Sun, Feb 6, 2011 at 8:36 PM, Xyne  wrote:
>
> You seem to think that I am saying that the versions on CPAN are wrong. I am
> not. I am saying that Arch packagers do not understand the CPAN version 
> schemes
> and thus fail to correctly convert CPAN versions to Pacman package versions
> ($pkgver).
>

You said a version comparison done by "CPAN" is wrong here:

> To give an example, CPAN considers "1.15" to be a later version than "1.23.0",
> ...

You seem to be lumping the version module and CPAN together. This is
what is confusing in your message. You mentioned a CPAN version scheme
but there is no such thing. CPAN authors are free to version things
like crazy, however they like. I can upload a distribution file to the
CPAN with a version that is less than my last version. CPAN will
politely notify me of my mistake and release the distribution anyways.

> For example, a CPAN package could be update from 0.199 to 0.2. Pacman will
> consider 0.199 to be the newer version, e.g.:
>
> $ vercmp 0.199 0.2
> 1
>
> A "force" flag would thus be required to update the package. The standardized
> versions would be 0.199 and 0.200, which pacman can correctly compare.
>
> The whole point of this is that CPAN has a very specific versioning scheme 
> that
> does not directly translate to Arch. It has syntax for major versions, minor
> versions, alpha versions, etc. They is also a mixture of different syntax due
> to legacy version strings that have not been updated. The provided script can
> generate standardized versions using the "version" module which was designed
> for this, and which is distributed as part of the Perl distribution and can
> thus be considered official itself.
>

CPAN has no specific versioning scheme at all. Many versions of
distributions on CPAN follow the simple decimal format like 1.23. Some
have the dotted-decimal format of 1.23.45 etc. Others have dates for
versions like 20101234. Sometimes new releases of a distribution
change from one scheme to the next. It's chaos.

The version module has in the past been unreliable. It is bloated and
even changes behavior. This is mentioned in my previous email. The old
behavior used the 'qv' function while the new behavior uses the
'parse' class method. Yes, they give different results. I even tried
using the version module for my module's $VERSION, which ended up
prefixing the version in my distribution file with a 'v'. Annoying.

>
> As the developer of tools to package CPAN packages for Pacman
> automatically (Pacpan and Bauerbill), I can assure you that the the lack of
> standardized versions in Arch poses a real-world problem. There is no way to
> reliably generate PKGBUILDs with versioned dependencies as long as there
> is no standard conversions.

Certainly you know by now, I create a similar tool with my
CPANPLUS::Dist::Arch module. You know I have seen the same problems.
How about we slow down a little and work together to try to fix this.
A good first step would be to clearly define the problem. There is
also plenty of test data available, the entire CPAN and Backpan with
thousands of versions to play with. What Kaiting says is absolutely
correct. Why not test this out and gather some data before asking
everyone to start using it?

I would have to see for myself whether this worked for a majority of
cases before adopting it. Before that, clearly defining the problem in
a document with some real data would be helpful. Then some scripts
could be made to gather versions and comparisons. We could even work
with the perl community to try to clean up their versions or flag the
offensive versions.

There is also the problem which stopped me from probing further on
this subject. If some packages do not use the same method as I do in
normalizing versions than it is all for naught. There could be two
packages with different version strings, representative of the same
original CPAN distribution, which pacman evaluates differently.

-- 
-Justin

Re: [aur-general] Moving packages to Community

[Rafael Beraldo]

I maintain a few PKGBUILDs on AUR, including one that has a considerable
amount of votes [1]. It would be awesome to have any package that I maintain
moved to [community], it doesn't matter if the TU asked me or not, but this
is a personal opinion. Nevertheless, it is certainly polite to write a
comment notifying that the TU is going to move the package, not to mention
useful, since (I assume that) many people that use a given package would
also be notified by e-mail that the package is being moved.

Just for the record, I agree that it should be put in the guidelines. I
think that the main argument in favor of it is that it is not only polite
but convenient for those who want to keep track of the packages one is
using.

[1] http://aur.archlinux.org/packages.php?ID=10227

--
Rafael Beraldo
http://devio.us/~rberaldo/

[aur-general] License installation

[rafael ff1]

Hi there.

I read Licenses  and
PKGBUILDpages at
Archwiki and I've been wondering: case a software's license is one
the common ones (ex: GPL), if the PKGBUILD should do some kind of reference
(symlink) from /usr/share/licenses/common/GPL/ to
/usr/share/licenses/${pkgname}/ or.. do nothing, maybe?

Thanks

Re: [aur-general] License installation

[Kaiting Chen]

On Sun, Feb 6, 2011 at 11:50 PM, rafael ff1  wrote:

> I read Licenses  and
> PKGBUILDpages at
> Archwiki and I've been wondering: case a software's license is one
> the common ones (ex: GPL), if the PKGBUILD should do some kind of reference
> (symlink) from /usr/share/licenses/common/GPL/ to
> /usr/share/licenses/${pkgname}/ or.. do nothing, maybe?
>

`pacman -Qi $pkgname | grep Licenses` --Kaiting.

-- 
Kiwis and Limes: http://kaitocracy.blogspot.com/

Re: [aur-general] License installation

[rafael ff1]

Thanks for the reply, Kaiting. I actually understand what license is for
each packages. My question is if, in the PKGBUILD, I should set a
folder/symlink for each package in /usr/share/licenses/$pkgname

For example: package is LGPL. I have "license" package installed. Should I
symilink from common/LGPL folder to ${pkgname} ? Or do nothing - and leave
as it is?




2011/2/7 Kaiting Chen 

> On Sun, Feb 6, 2011 at 11:50 PM, rafael ff1  wrote:
>
> > I read Licenses  and
> > PKGBUILDpages at
> > Archwiki and I've been wondering: case a software's license is one
> > the common ones (ex: GPL), if the PKGBUILD should do some kind of
> reference
> > (symlink) from /usr/share/licenses/common/GPL/ to
> > /usr/share/licenses/${pkgname}/ or.. do nothing, maybe?
> >
>
> `pacman -Qi $pkgname | grep Licenses` --Kaiting.
>
> --
> Kiwis and Limes: http://kaitocracy.blogspot.com/
>

Re: [aur-general] License installation

[Thomas S Hatch]

On Sun, Feb 6, 2011 at 11:20 PM, rafael ff1  wrote:

> Thanks for the reply, Kaiting. I actually understand what license is for
> each packages. My question is if, in the PKGBUILD, I should set a
> folder/symlink for each package in /usr/share/licenses/$pkgname
>
> For example: package is LGPL. I have "license" package installed. Should I
> symilink from common/LGPL folder to ${pkgname} ? Or do nothing - and leave
> as it is?
>
>
>
>
> 2011/2/7 Kaiting Chen 
>
> > On Sun, Feb 6, 2011 at 11:50 PM, rafael ff1 
> wrote:
> >
> > > I read Licenses  and
> > > PKGBUILDpages at
> > > Archwiki and I've been wondering: case a software's license is one
> > > the common ones (ex: GPL), if the PKGBUILD should do some kind of
> > reference
> > > (symlink) from /usr/share/licenses/common/GPL/ to
> > > /usr/share/licenses/${pkgname}/ or.. do nothing, maybe?
> > >
> >
> > `pacman -Qi $pkgname | grep Licenses` --Kaiting.
> >
> > --
> > Kiwis and Limes: http://kaitocracy.blogspot.com/
> >
>

For common licences that already exist, you don't need to make a symlink in
the package, the licence files already exist on the machine, and the correct
licence in the PKGBUILD is enough.

You only really need to include the licence if it is not one
of these installed in the licences directory.

Re: [aur-general] License installation

[rafael ff1]

Got it! Thanks all!

2011/2/7 Thomas S Hatch 

> On Sun, Feb 6, 2011 at 11:20 PM, rafael ff1  wrote:
>
> > Thanks for the reply, Kaiting. I actually understand what license is for
> > each packages. My question is if, in the PKGBUILD, I should set a
> > folder/symlink for each package in /usr/share/licenses/$pkgname
> >
> > For example: package is LGPL. I have "license" package installed. Should
> I
> > symilink from common/LGPL folder to ${pkgname} ? Or do nothing - and
> leave
> > as it is?
> >
> >
> >
> >
> > 2011/2/7 Kaiting Chen 
> >
> > > On Sun, Feb 6, 2011 at 11:50 PM, rafael ff1 
> > wrote:
> > >
> > > > I read Licenses  and
> > > > PKGBUILDpages at
> > > > Archwiki and I've been wondering: case a software's license is one
> > > > the common ones (ex: GPL), if the PKGBUILD should do some kind of
> > > reference
> > > > (symlink) from /usr/share/licenses/common/GPL/ to
> > > > /usr/share/licenses/${pkgname}/ or.. do nothing, maybe?
> > > >
> > >
> > > `pacman -Qi $pkgname | grep Licenses` --Kaiting.
> > >
> > > --
> > > Kiwis and Limes: http://kaitocracy.blogspot.com/
> > >
> >
>
> For common licences that already exist, you don't need to make a symlink in
> the package, the licence files already exist on the machine, and the
> correct
> licence in the PKGBUILD is enough.
>
> You only really need to include the licence if it is not one
> of these installed in the licences directory.
>