Re: [aur-general] Submitting a new package (sunjdk)
On Mon, 06 Apr 2009 03:01:46 +0200 M Rawash mraw...@gmail.com wrote: On Mon, 2009-04-06 at 19:57 +1930, Angel Velásquez wrote: it's *not* a duplicate, i just cited the lack of updates as one of the reasons i forked the package, you can review sunjdk here: http://aur.archlinux.org/packages.php?ID=25303 regards IMO this is a duplicate effort, because this package provided the same as existent packages (jre,jdk) in repos, and btw you can't use the Maintainer tag since this isn't a binary package and you aren't a TU/Dev Thanks for your effort, anyway frankly, i'm not really sure if the Maintainer/Contributor tags signify anything other than 'current maintainer'/'former contributor', i didn't even know there was a debate about it.. cheers Don't find it in the other thread anymore, so I point it out here: Another wiki page that needs updating: http://wiki.archlinux.org/index.php/Arch_Packaging_Standards Philipp
Re: [aur-general] How to handle interchangeable dependencies?
Laurie Clark-Michalek wrote:
I disagree. This same thing happens to me with my package brasero-lite. It
is brasero but without the gnome dependencies, and has the
provides=('brasero'), but when I try and install a package that has brasero
as a dependencie, such as sound-juicer, pacman attempts to install brasero,
not realising that i allready have brasero-lite. This isn't a sound juicer
fault, it is a fault in pacman.
That is a different problem
The brasero-lite PKGBUILD should have provides=(brasero=2.26.0) in
it. Sound-juicer requires brasero=2.26.0 so just providing brasero
is not enough.
Allan
Re: [aur-general] legal question
On Mon, Apr 6, 2009 at 07:39, Firmicus firmi...@gmx.net wrote: Hi everyone I just noticed that two packages in AUR appear to install fonts whose use is illegal. http://aur.archlinux.org/packages.php?ID=10408 http://aur.archlinux.org/packages.php?ID=16470 (here the fonts themselves are pirated) Both packages have many votes. Even though it might not be an infringement from our part to offer the PKGBUILDs, it still does not look very good for Arch Linux to be encouraging the use of illegal software (note that font is also software). Unless someone provides me with good arguments against it, I will delete the above two packages during the next few days. Best, F It's the choice of the user whether they want to install the package and violate the license. It's been help up all over that sites that host user-uploaded content aren't responsible for the legality of the content uploaded, so long as they comply with any DMCA takedown requests. I'd wait for one of those before deleting any of these.
Re: [aur-general] legal question
Firmicus wrote: Hi everyone I just noticed that two packages in AUR appear to install fonts whose use is illegal. http://aur.archlinux.org/packages.php?ID=10408 I think these are fine in their current format. Can never actually be distribute in a package by us though. http://aur.archlinux.org/packages.php?ID=16470 (here the fonts themselves are pirated) These should be deleted. Allan
Re: [aur-general] legal question
Allan McRae a écrit : Firmicus wrote: Hi everyone I just noticed that two packages in AUR appear to install fonts whose use is illegal. http://aur.archlinux.org/packages.php?ID=10408 I think these are fine in their current format. Can never actually be distribute in a package by us though. OK, I'll leave it there then. http://aur.archlinux.org/packages.php?ID=16470 (here the fonts themselves are pirated) These should be deleted. Done
[aur-general] legal question
Hi everyone I just noticed that two packages in AUR appear to install fonts whose use is illegal. http://aur.archlinux.org/packages.php?ID=10408 http://aur.archlinux.org/packages.php?ID=16470 (here the fonts themselves are pirated) Both packages have many votes. Even though it might not be an infringement from our part to offer the PKGBUILDs, it still does not look very good for Arch Linux to be encouraging the use of illegal software (note that font is also software). Unless someone provides me with good arguments against it, I will delete the above two packages during the next few days. Best, F
Re: [aur-general] How to handle interchangeable dependencies?
I disagree. This same thing happens to me with my package brasero-lite. It
is brasero but without the gnome dependencies, and has the
provides=('brasero'), but when I try and install a package that has brasero
as a dependencie, such as sound-juicer, pacman attempts to install brasero,
not realising that i allready have brasero-lite. This isn't a sound juicer
fault, it is a fault in pacman.
2009/4/6 Allan McRae al...@archlinux.org
hollun...@gmx.at wrote:
Hi there.
I'm looking for a clean way to handle packages that can replace others.
Examples:
lash can be substituted by lash-git, it works fine, except namcap
complains:
hydrogen-svn E: Dependency detected and not included (lash-git) from
files ['usr/bin/hydrogen']
hydrogen-svn W: Dependency included and not needed (lash)
Adding 'lash' or 'lash=0.6.0' to the provides array of lash-git doesn't
help.
I have the same situation with for example jack-audio-connection-kit
where we have quite a number of different packages that all provide the
same basic functionality and are interchangeable.
Note that it mostly works with provides, it just isn't clean and there
are cases where it can break stuff.
Is there a solution to this?
I think this is more a limitation in namcap than your package. I think a
bug report for namcap would be appropriate.
Allan
Re: [aur-general] Maintainer vs Contributor tag let's find a solution ; )
On Mon, 6 Apr 2009 08:53:06 +0300
Evangelos Foutras foutre...@gmail.com wrote:
I'm not sure if this has been mentioned before, but here's my take:
- Maintainer: The person who currently maintains a package.
- Contributor: The person who first submitted the package. If a
package is so badly constructed that it needs to be rewritten from
scratch, the contributor tag would only list the person who did the
rewrite.
I know we've agreed on multiple contributor tags, but I believe the
method detailed above is cleaner, more maintainable and more
straight-forward. I'll most likely adopt it for my own packages, but
I'm not saying that anyone else should.
I would say that we should hold a voting to make a final decision.
However, it's not an important issue at all, so the current way of
doing things (multiple contributor lines) is sufficient.
As I already mentioned someplace else it's still mixed up here:
http://wiki.archlinux.org/index.php/Arch_Packaging_Standards
I'd love it if someone knowledgeable could go through that page and
could correct any other errors before I try to adhere to those
standards.
There are also other points that aren't mentioned there, like whether
one should use $pkgver or ${pkgver}. All the PKGBUILd.proto files use
$pkgver, I've seen both versions in wildlife.
/me is now off to edit contributor tags..
Philipp
[aur-general] Adoptable AUR packages
There are three kinds of orphans in AUR at the moment. 1) A sea of packages that have either become obselete or have been added in some other package. ( Like dolphin ). 2) The others are ruby/python/perl libraries. The problem with these is that installing them using pyPI or gems is quite simple (though not highly recommended). So many of these get orphaned 3) The last category is where maintainers do not have the time to do justice to their packages and hence orphan it. I found I had a little free time and could adopt some packages. I found myself in this sea. It would be good if we can start a wiki page where every useful package that is currently orphaned can be added and removed once adopted. I checked out the wiki. The AUR cleanup day is the closest I got to. We would need something like an inverse of that now. So any user who wants to adopt a package should go to the page, choose whatever he wants to adopt and remove it from the page. I feel this will clear up a lot of packages in the second and last categories. Also, we can give a guideline for people who disown packages to add it to the corresponding page (obselete/required) in the hope that someone will take over the package --- Ashok `ScriptDevil` Gautham
Re: [aur-general] How to handle interchangeable dependencies?
hollun...@gmx.at wrote: Hi there. I'm looking for a clean way to handle packages that can replace others. Examples: lash can be substituted by lash-git, it works fine, except namcap complains: hydrogen-svn E: Dependency detected and not included (lash-git) from files ['usr/bin/hydrogen'] hydrogen-svn W: Dependency included and not needed (lash) Adding 'lash' or 'lash=0.6.0' to the provides array of lash-git doesn't help. I have the same situation with for example jack-audio-connection-kit where we have quite a number of different packages that all provide the same basic functionality and are interchangeable. Note that it mostly works with provides, it just isn't clean and there are cases where it can break stuff. Is there a solution to this? I think this is more a limitation in namcap than your package. I think a bug report for namcap would be appropriate. Allan
Re: [aur-general] How to handle interchangeable dependencies?
On Mon, 06 Apr 2009 22:32:48 +1000
Allan McRae al...@archlinux.org wrote:
hollun...@gmx.at wrote:
On Mon, 06 Apr 2009 21:46:48 +1000
Allan McRae al...@archlinux.org wrote:
Laurie Clark-Michalek wrote:
I disagree. This same thing happens to me with my package
brasero-lite. It is brasero but without the gnome dependencies,
and has the provides=('brasero'), but when I try and install a
package that has brasero as a dependencie, such as sound-juicer,
pacman attempts to install brasero, not realising that i allready
have brasero-lite. This isn't a sound juicer fault, it is a fault
in pacman.
That is a different problem
The brasero-lite PKGBUILD should have provides=(brasero=2.26.0)
in it. Sound-juicer requires brasero=2.26.0 so just providing
brasero is not enough.
Allan
I believe this doesn't work either and the problems are at least
related.
Concrete example:
lash-git: provides=('lash=0.6.0')
calf-git: depends=('fluidsynth' 'libglade' 'lash=0.6.0')
namcap calf-git-20090406-1-i686.pkg.tar.gz
calf-git E: Dependency detected and not included (lash-git) from
files ['usr/bin/calfjackhost']
calf-git W: Dependency included and not needed (lash)
As I said, we have two completely different problems here. Yours is
a limitation of namcap and it would be good to file a feature request
to get it fixed.
The other problem is a PKGBUILD with incomplete provides
encountering a versioned dependency. Completely different.
Allan
Allan, I still don't know how I can solve the above mentioned problem.
As you see I versioned the provides and required the version in this
case and it doesn't help.
As I see it I have the same problem here as Laurie Clark-Michalek.
I believe if this was in AUR and I tried to download calf-git through
yaourt it would try to install lash despite lash-git being installed
already.
Philipp
Re: [aur-general] Request deletion lv2-c++-tools
On Mon, Apr 6, 2009 at 08:34, hollun...@gmx.at wrote: http://aur.archlinux.org/packages.php?ID=23651 It seems like the c++ in the name causes problems, at least with yaourt. I made a new package with cpp instead. Philipp Yaourt isn't an official tool, and any limitations in it should be handled by its authors. If the correct name is with ++, I see no reason to change it. There are packages in the main repos which have ++ in pkgname as well, so it's not really a unique issue.
Re: [aur-general] How to handle interchangeable dependencies?
On Mon, Apr 6, 2009 at 08:42, hollun...@gmx.at wrote: Allan, I still don't know how I can solve the above mentioned problem. As you see I versioned the provides and required the version in this case and it doesn't help. As I see it I have the same problem here as Laurie Clark-Michalek. I believe if this was in AUR and I tried to download calf-git through yaourt it would try to install lash despite lash-git being installed already. Philipp Yaourt isn't an officially supported tool. Have you tried by downloading the package and then using makepkg -i? I suspect that yaourt is the source of this bug.
Re: [aur-general] How to handle interchangeable dependencies?
hollun...@gmx.at wrote:
On Mon, 06 Apr 2009 22:32:48 +1000
Allan McRae al...@archlinux.org wrote:
hollun...@gmx.at wrote:
On Mon, 06 Apr 2009 21:46:48 +1000
Allan McRae al...@archlinux.org wrote:
Laurie Clark-Michalek wrote:
I disagree. This same thing happens to me with my package
brasero-lite. It is brasero but without the gnome dependencies,
and has the provides=('brasero'), but when I try and install a
package that has brasero as a dependencie, such as sound-juicer,
pacman attempts to install brasero, not realising that i allready
have brasero-lite. This isn't a sound juicer fault, it is a fault
in pacman.
That is a different problem
The brasero-lite PKGBUILD should have provides=(brasero=2.26.0)
in it. Sound-juicer requires brasero=2.26.0 so just providing
brasero is not enough.
Allan
I believe this doesn't work either and the problems are at least
related.
Concrete example:
lash-git: provides=('lash=0.6.0')
calf-git: depends=('fluidsynth' 'libglade' 'lash=0.6.0')
namcap calf-git-20090406-1-i686.pkg.tar.gz
calf-git E: Dependency detected and not included (lash-git) from
files ['usr/bin/calfjackhost']
calf-git W: Dependency included and not needed (lash)
As I said, we have two completely different problems here. Yours is
a limitation of namcap and it would be good to file a feature request
to get it fixed.
The other problem is a PKGBUILD with incomplete provides
encountering a versioned dependency. Completely different.
Allan
Allan, I still don't know how I can solve the above mentioned problem.
As you see I versioned the provides and required the version in this
case and it doesn't help.
As I see it I have the same problem here as Laurie Clark-Michalek.
I believe if this was in AUR and I tried to download calf-git through
yaourt it would try to install lash despite lash-git being installed
already.
It should not. If it does, then it is a bug in yaourt. If you have
lash-git installed, then build calf-git manually using and installed it
with pacman -U pkg, there should be no complaints from pacman.
Allan
Re: [aur-general] How to handle interchangeable dependencies?
On Mon, 6 Apr 2009 08:44:38 -0400 Daenyth Blank daenyth+a...@gmail.com wrote: On Mon, Apr 6, 2009 at 08:42, hollun...@gmx.at wrote: Allan, I still don't know how I can solve the above mentioned problem. As you see I versioned the provides and required the version in this case and it doesn't help. As I see it I have the same problem here as Laurie Clark-Michalek. I believe if this was in AUR and I tried to download calf-git through yaourt it would try to install lash despite lash-git being installed already. Philipp Yaourt isn't an officially supported tool. Have you tried by downloading the package and then using makepkg -i? I suspect that yaourt is the source of this bug. both packages, lash-git and calf-git are so far only local so far, I'll upload and try calf-git for the sake of this experiment. Philipp
Re: [aur-general] How to handle interchangeable dependencies?
On Mon, 06 Apr 2009 22:48:53 +1000
Allan McRae al...@archlinux.org wrote:
hollun...@gmx.at wrote:
On Mon, 06 Apr 2009 22:32:48 +1000
Allan McRae al...@archlinux.org wrote:
hollun...@gmx.at wrote:
On Mon, 06 Apr 2009 21:46:48 +1000
Allan McRae al...@archlinux.org wrote:
Laurie Clark-Michalek wrote:
I disagree. This same thing happens to me with my package
brasero-lite. It is brasero but without the gnome
dependencies, and has the provides=('brasero'), but when I try
and install a package that has brasero as a dependencie, such
as sound-juicer, pacman attempts to install brasero, not
realising that i allready have brasero-lite. This isn't a sound
juicer fault, it is a fault in pacman.
That is a different problem
The brasero-lite PKGBUILD should have provides=(brasero=2.26.0)
in it. Sound-juicer requires brasero=2.26.0 so just providing
brasero is not enough.
Allan
I believe this doesn't work either and the problems are at least
related.
Concrete example:
lash-git: provides=('lash=0.6.0')
calf-git: depends=('fluidsynth' 'libglade' 'lash=0.6.0')
namcap calf-git-20090406-1-i686.pkg.tar.gz
calf-git E: Dependency detected and not included (lash-git) from
files ['usr/bin/calfjackhost']
calf-git W: Dependency included and not needed (lash)
As I said, we have two completely different problems here. Yours
is a limitation of namcap and it would be good to file a feature
request to get it fixed.
The other problem is a PKGBUILD with incomplete provides
encountering a versioned dependency. Completely different.
Allan
Allan, I still don't know how I can solve the above mentioned
problem. As you see I versioned the provides and required the
version in this case and it doesn't help.
As I see it I have the same problem here as Laurie Clark-Michalek.
I believe if this was in AUR and I tried to download calf-git
through yaourt it would try to install lash despite lash-git being
installed already.
It should not. If it does, then it is a bug in yaourt. If you have
lash-git installed, then build calf-git manually using and installed
it with pacman -U pkg, there should be no complaints from pacman.
Allan
== calf-git dependencies:
- fluidsynth (already installed)
- libglade (already installed)
- lash (building from AUR)
So this is a bug in yaourt, the second today it seems.
Guess I start hunting for the yaourt and namcap bugtrackers..
Thanks for your help with that Allan and Daenyth.
Re: [aur-general] Request deletion lv2-c++-tools
On Mon, Apr 06, 2009 at 02:58:58PM +0200, hollun...@gmx.at wrote: On Mon, 6 Apr 2009 08:43:22 -0400 Daenyth Blank daenyth+a...@gmail.com wrote: On Mon, Apr 6, 2009 at 08:34, hollun...@gmx.at wrote: http://aur.archlinux.org/packages.php?ID=23651 It seems like the c++ in the name causes problems, at least with yaourt. I made a new package with cpp instead. Philipp Yaourt isn't an official tool, and any limitations in it should be handled by its authors. If the correct name is with ++, I see no reason to change it. There are packages in the main repos which have ++ in pkgname as well, so it's not really a unique issue. Ok, so either we keep it working for now (keep the cpp version) or break it and keep it correct (c++ version). Guess it's you choice at this time, please delete one of the two, I'll adjust the one affected package (ll-plugins). Well, which one do you intend to maintain?
Re: [aur-general] How to handle interchangeable dependencies?
On Mon, Apr 06, 2009 at 02:55:52PM +0200, hollun...@gmx.at wrote: So this is a bug in yaourt, the second today it seems. Guess I start hunting for the yaourt and namcap bugtrackers.. When tracking down bugs please do not pollute your results by relying on unsupported scripts.
Re: [aur-general] How to handle interchangeable dependencies?
On Mon, 6 Apr 2009 09:34:03 -0400 Loui Chang louipc@gmail.com wrote: On Mon, Apr 06, 2009 at 02:55:52PM +0200, hollun...@gmx.at wrote: So this is a bug in yaourt, the second today it seems. Guess I start hunting for the yaourt and namcap bugtrackers.. When tracking down bugs please do not pollute your results by relying on unsupported scripts. The problem is that even if those scripts are unsupported they are widely used (well, namcap not as widely a one could wish). On a sidenote: I wasn't trying to hunt bugs but to write clean PKGBUILD scripts. Does one know how to report bugs for namcap? What seems to be the namcap page is unavailable: http://abhidg.mine.nu/ Philipp
Re: [aur-general] How to handle interchangeable dependencies?
2009/4/6 hollun...@gmx.at: The problem is that even if those scripts are unsupported they are widely used (well, namcap not as widely a one could wish). On a sidenote: I wasn't trying to hunt bugs but to write clean PKGBUILD scripts. Does one know how to report bugs for namcap? What seems to be the namcap page is unavailable: http://abhidg.mine.nu/ Report the bug in the Arch Linux section of the bugtracker and remember to put namcap in the bug title. http://abhidg.mine.nu is my home website which has namcap-reports (a web interface showing namcap errors and warnings). It has nothing to do with the actual namcap program. -- Abhishek
Re: [aur-general] Request deletion lv2-c++-tools
On Mon, 6 Apr 2009 09:30:13 -0400 Loui Chang louipc@gmail.com wrote: On Mon, Apr 06, 2009 at 02:58:58PM +0200, hollun...@gmx.at wrote: On Mon, 6 Apr 2009 08:43:22 -0400 Daenyth Blank daenyth+a...@gmail.com wrote: On Mon, Apr 6, 2009 at 08:34, hollun...@gmx.at wrote: http://aur.archlinux.org/packages.php?ID=23651 It seems like the c++ in the name causes problems, at least with yaourt. I made a new package with cpp instead. Philipp Yaourt isn't an official tool, and any limitations in it should be handled by its authors. If the correct name is with ++, I see no reason to change it. There are packages in the main repos which have ++ in pkgname as well, so it's not really a unique issue. Ok, so either we keep it working for now (keep the cpp version) or break it and keep it correct (c++ version). Guess it's you choice at this time, please delete one of the two, I'll adjust the one affected package (ll-plugins). Well, which one do you intend to maintain? Either one, the one with c++ is the correct name but just won't work with namcap until the '+' bug is fixed. It's not like it was high profile and the author vanished from the net some time ago so I guess he won't care either. Philipp
Re: [aur-general] How to handle interchangeable dependencies?
On Mon, 6 Apr 2009 19:18:55 +0530 Abhishek Dasgupta abh...@gmail.com wrote: 2009/4/6 hollun...@gmx.at: The problem is that even if those scripts are unsupported they are widely used (well, namcap not as widely a one could wish). On a sidenote: I wasn't trying to hunt bugs but to write clean PKGBUILD scripts. Does one know how to report bugs for namcap? What seems to be the namcap page is unavailable: http://abhidg.mine.nu/ Report the bug in the Arch Linux section of the bugtracker and remember to put namcap in the bug title. http://abhidg.mine.nu is my home website which has namcap-reports (a web interface showing namcap errors and warnings). It has nothing to do with the actual namcap program. Ah, sorry, and thanks. I got kind of mislead because this seems to be the only wiki page related to namcap http://wiki.archlinux.org/index.php/Namcap_Reports Philipp
Re: [aur-general] How to handle interchangeable dependencies?
On Mon, Apr 06, 2009 at 03:45:43PM +0200, hollun...@gmx.at wrote: On Mon, 6 Apr 2009 09:34:03 -0400 Loui Chang louipc@gmail.com wrote: On Mon, Apr 06, 2009 at 02:55:52PM +0200, hollun...@gmx.at wrote: So this is a bug in yaourt, the second today it seems. Guess I start hunting for the yaourt and namcap bugtrackers.. When tracking down bugs please do not pollute your results by relying on unsupported scripts. The problem is that even if those scripts are unsupported they are widely used (well, namcap not as widely a one could wish). It should be clear if you saw the disclaimer on the AUR home page. I guess that could be a case to put the disclaimer on every page, so the point is hammered in. Heh. Namcap is a supported script by the way. Does one know how to report bugs for namcap? Arch Linux bug tracker: http://bugs.archlinux.org/index.php?project=1do=indexswitch=1
Re: [aur-general] How to handle interchangeable dependencies?
On Mon, Apr 06, 2009 at 04:21:53PM +0200, hollun...@gmx.at wrote: On Mon, 6 Apr 2009 10:02:41 -0400 Loui Chang louipc@gmail.com wrote: On Mon, Apr 06, 2009 at 03:45:43PM +0200, hollun...@gmx.at wrote: On Mon, 6 Apr 2009 09:34:03 -0400 Loui Chang louipc@gmail.com wrote: On Mon, Apr 06, 2009 at 02:55:52PM +0200, hollun...@gmx.at wrote: So this is a bug in yaourt, the second today it seems. Guess I start hunting for the yaourt and namcap bugtrackers.. When tracking down bugs please do not pollute your results by relying on unsupported scripts. The problem is that even if those scripts are unsupported they are widely used (well, namcap not as widely a one could wish). It should be clear if you saw the disclaimer on the AUR home page. I guess that could be a case to put the disclaimer on every page, so the point is hammered in. Heh. Won't help ;) What do you suggest? I could delete and/or block yaourt from AUR if there are too many support requests to Arch. Does the AUR webpage and yaourt rely on namcap as well? Both don't get it right either. AUR doesn't rely on namcap. '+' bug for yaourt reported here: http://bugs.archlinux.org/task/14122?opened=4326 Jeez don't file bugs for unsupported scripts. Contact the yaourt developers. If you can't get a hold of them then there's nothing that the Arch Linux devs can do for you.
Re: [aur-general] How to handle interchangeable dependencies?
On Mon, 6 Apr 2009 10:27:21 -0400 Loui Chang louipc@gmail.com wrote: On Mon, Apr 06, 2009 at 04:21:53PM +0200, hollun...@gmx.at wrote: On Mon, 6 Apr 2009 10:02:41 -0400 Loui Chang louipc@gmail.com wrote: On Mon, Apr 06, 2009 at 03:45:43PM +0200, hollun...@gmx.at wrote: On Mon, 6 Apr 2009 09:34:03 -0400 Loui Chang louipc@gmail.com wrote: On Mon, Apr 06, 2009 at 02:55:52PM +0200, hollun...@gmx.at wrote: So this is a bug in yaourt, the second today it seems. Guess I start hunting for the yaourt and namcap bugtrackers.. When tracking down bugs please do not pollute your results by relying on unsupported scripts. The problem is that even if those scripts are unsupported they are widely used (well, namcap not as widely a one could wish). It should be clear if you saw the disclaimer on the AUR home page. I guess that could be a case to put the disclaimer on every page, so the point is hammered in. Heh. Won't help ;) What do you suggest? I could delete and/or block yaourt from AUR if there are too many support requests to Arch. I don't suggest anything, just point out reality. Almost every Arch user uses AUR, many through yaourt. yaourt, Votes: 1918, certainly far more users than that. It still is in AUR, not community. Does the AUR webpage and yaourt rely on namcap as well? Both don't get it right either. AUR doesn't rely on namcap. K, thanks, so I have to file another one, hopefully at the right place for a change. '+' bug for yaourt reported here: http://bugs.archlinux.org/task/14122?opened=4326 Jeez don't file bugs for unsupported scripts. Contact the yaourt developers. If you can't get a hold of them then there's nothing that the Arch Linux devs can do for you. For me the case is simple, the yaourt webpage[1] led me to this bugtracker or at least made it appeared to be the bugtracker, I just reported the bug. If this is wrong then official Arch and yaourt need to straighten this out. No matter if it's unofficial, it's heavily related and as such both projects should talk to each other. [1] http://archlinux.fr/yaourt-en Best regards, Philipp
Re: [aur-general] Adoptable AUR packages
On Mon, Apr 6, 2009 at 8:19 PM, Imanol Celaya ornitorrin...@archlinux-es.org wrote: doesn't the orphan search function in AUR do the same and automated? That is exactly my point. Orphan search gives you even packages that have been orphaned because the packages are not needed any more. In fact such packages are the majority. --- Ashok `ScriptDevil` Gautham
Re: [aur-general] How to handle interchangeable dependencies?
Le Mon, 6 Apr 2009 16:53:16 +0200, hollun...@gmx.at a écrit : For me the case is simple, the yaourt webpage[1] led me to this bugtracker or at least made it appeared to be the bugtracker, I just reported the bug. If this is wrong then official Arch and yaourt need to straighten this out. No matter if it's unofficial, it's heavily related and as such both projects should talk to each other. [1] http://archlinux.fr/yaourt-en The real bugtracker for Yaourt is the one linked at the bottom of the page, not at its top [1]. The people at archlinux.fr should indeed fix that so that no more users report bugs for Yaourt on the official bugtracker. [1] http://bugs.archlinux.fr/index.php?tasks=allproject=3string=type=sev=due=dev=cat=status=alldate=0 -- catwell
Re: [aur-general] Submitting a new package (sunjdk)
On Tue, Apr 7, 2009 at 12:00 PM, Xyne x...@archlinux.ca wrote: Lucas Salies Brum lu...@archlinux.com.br wrote: IMHO, maintain this package on AUR is waste of time. Sorry. --- Lucas Saliés Brum I don't understand this reasoning (which several people have expressed). If he thinks it's worth maintaining and its his time, what difference does it make to anyone else? No one else has to maintain it and the only thing that could happen is that someone who wants that package will find it and use it. Xyne Duplicate PKGBUILD will fill the AUR of many garbabe that will be orphan later.. Frankly, the majority of the orphan and out-of-date PKGBUILD on AUR are versions of things duplicated :/ I think this should be deleted and no matter what, and it's the opinion of the majority so, why is there yet? -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
Re: [aur-general] Adoptable AUR packages
The other problem is that a list of orphaned packages on the wiki would be subject to the same kind of problem: someone puts something there, then a year passes and the package isn't needed anymore but doesn't get removed because there are 8000 packages on that list. I think this wouldn't really solve much in the long term. +1 to Mr. Haren. -Andrei Garoth Thorp On Mon, Apr 6, 2009 at 8:47 AM, Ronald van Haren pre...@gmail.com wrote: On 4/6/09, Ashok Gautham scriptdevil.a...@gmail.com wrote: On Mon, Apr 6, 2009 at 8:19 PM, Imanol Celaya ornitorrin...@archlinux-es.org wrote: doesn't the orphan search function in AUR do the same and automated? That is exactly my point. Orphan search gives you even packages that have been orphaned because the packages are not needed any more. In fact such packages are the majority. --- Ashok `ScriptDevil` Gautham Instead of inventing a new way of sorting orphan packages it would be best to put the/'a lot of' effort in cleaning up the current list. Packages that should not be there should be removed. Ronald
Re: [aur-general] AUR package removal request
2009/4/6 revel re...@muub.net: Hello, Please remove [1] from AUR. I changed the package name to [2] some time ago and kept [1] in kind of deprecated state. [1] http://aur.archlinux.org/packages.php?ID=15158 [2] http://aur.archlinux.org/packages.php?ID=22238 deleted. -- Abhishek
Re: [aur-general] Request deletion lv2-c++-tools
2009/4/6 hollun...@gmx.at: Well, I just decided. I used the '++' package as example in the yaourt bug report. It also is the proper name. breaking this package in yaourt isn't a big problem since it's low profile anyway. Please remove: http://aur.archlinux.org/packages.php?ID=25310 Best regards, Philipp deleted. -- Abhishek
Re: [aur-general] Adoptable AUR packages
Ashok Gautham wrote: There are three kinds of orphans in AUR at the moment. 1) A sea of packages that have either become obselete or have been added in some other package. ( Like dolphin ). ... 3) The last category is where maintainers do not have the time to do justice to their packages and hence orphan it. IMHO, this is the sort of information that the maintainer should provide in the package's comments section when he disowns it. Likewise, if someone flags something as out-of-date, he probably ought to leave a note. -- Chris
Re: [aur-general] Maintainer vs Contributor tag let's find a solution ; )
Scripting/coding style has been discussed before. To use ${pkgver} instead
of $pkgver is due to consistency. Technically, the braces enable one to
append to variables eg. ${pkgver}alpha. Another camp would like
double-quotes as well. If you remember, the reason for quotes on
${src,pkg}dir is the fact that no one knows which bloke keeps his local
build dir named with spaces.
To KIS, # Maintainer: for binary maintainer and # Contributor: for the
following:
* A submitter of a package.
* A _significant_ contributor to the content of the buildscripts including
the PKGBUILD
-- so how would one define significant? well, it's up to you. If a
person does not own a package but has
contributed a good deal to it via other means (comments on AUR), the
owner _may_ choose to add that person to the list as well.
It's not supposed to be a big deal, so long as there's a way to contact
someone.
Re: [aur-general] How to handle interchangeable dependencies?
On Tue, 7 Apr 2009 05:16:53 +0800 Ray Rashif schivmeis...@gmail.com wrote: To my knowledge, this is a namcap limitation (I've never used yaourt before). As to why I've never filed a bug - I don't think it's that much of a big issue. namcap is a complementary packaging tool; it isn't fool-proof. It's supposed to be a secondary aid - the first is your judgement from careful practice. Fixing the + problem in AUR won't be of much help IMHO (but I recall it was in the TODO list). Such a package can come with p instead, and when/if it gets to a supported repository there'd be nothing to complain about. namcap, AUR and yaourt have that limitation, I filed feature requests for all three as well as a bugreport for the + issue in yaourt. I agree that namcap is just a tool but quite an important one, it's _the_ dependency checking tool for arch, even if it doesn't work for everything. It should handle these not too common cases that it can handle correctly, or rather expose the same behaviour as pacman. Yes, you still need to get the package to compile first and test the functionality, but I couldn't package effectively without it.
Re: [aur-general] Maintainer vs Contributor tag let's find a solution ; )
On Tue, 7 Apr 2009 05:35:15 +0800
Ray Rashif schivmeis...@gmail.com wrote:
Scripting/coding style has been discussed before. To use ${pkgver}
instead of $pkgver is due to consistency. Technically, the braces
enable one to append to variables eg. ${pkgver}alpha. Another camp
would like double-quotes as well. If you remember, the reason for
quotes on ${src,pkg}dir is the fact that no one knows which bloke
keeps his local build dir named with spaces.
Quotes on ${src,pkg}dir ?
I believe I haven't seen this, can you give an example?
To KIS, # Maintainer: for binary maintainer and # Contributor:
for the following:
* A submitter of a package.
* A _significant_ contributor to the content of the buildscripts
including the PKGBUILD
-- so how would one define significant? well, it's up to you. If a
person does not own a package but has
contributed a good deal to it via other means (comments on AUR),
the owner _may_ choose to add that person to the list as well.
It's not supposed to be a big deal, so long as there's a way to
contact someone.
I believe it was agreed and agreed again today that maintainer is not
only for maintainers of binary packages but also for the maintainers of
AUR packages.
--Philipp
Re: [aur-general] Maintainer vs Contributor tag let's find a solution ; )
I meant srcdir or pkgdir (:
Right..If that's the way it's enforced if at all.
On 06/04/2009, hollun...@gmx.at hollun...@gmx.at wrote:
On Tue, 7 Apr 2009 05:35:15 +0800
Ray Rashif schivmeis...@gmail.com wrote:
Scripting/coding style has been discussed before. To use ${pkgver}
instead of $pkgver is due to consistency. Technically, the braces
enable one to append to variables eg. ${pkgver}alpha. Another camp
would like double-quotes as well. If you remember, the reason for
quotes on ${src,pkg}dir is the fact that no one knows which bloke
keeps his local build dir named with spaces.
Quotes on ${src,pkg}dir ?
I believe I haven't seen this, can you give an example?
To KIS, # Maintainer: for binary maintainer and # Contributor:
for the following:
* A submitter of a package.
* A _significant_ contributor to the content of the buildscripts
including the PKGBUILD
-- so how would one define significant? well, it's up to you. If a
person does not own a package but has
contributed a good deal to it via other means (comments on AUR),
the owner _may_ choose to add that person to the list as well.
It's not supposed to be a big deal, so long as there's a way to
contact someone.
I believe it was agreed and agreed again today that maintainer is not
only for maintainers of binary packages but also for the maintainers of
AUR packages.
--Philipp
[aur-general] Deletion request
Hi, I uploaded the wrong PKGBUILD on [1] (it was supposed to be kernel26-source, but I uploaded kernel26 instead...). Could someone please delete this package? Thanks in advance and sorry for the inconvenience. Thomas [1] http://aur.archlinux.org/packages.php?ID=23126
Re: [aur-general] Deletion request
On Mon, Apr 6, 2009 at 20:57, Thomas Jost thomas.j...@gmail.com wrote: Hi, I uploaded the wrong PKGBUILD on [1] (it was supposed to be kernel26-source, but I uploaded kernel26 instead...). Could someone please delete this package? Thanks in advance and sorry for the inconvenience. Thomas [1] http://aur.archlinux.org/packages.php?ID=23126 Done
Re: [aur-general] Maintainer vs Contributor tag let's find a solution ; )
On Tue, Apr 07, 2009 at 10:56:33AM +1000, Allan McRae wrote:
My summary of this:
1) Maintainer tag: It is a comment - makepkg does not care so nor should
you
2) $foo vs ${foo} : they do the same thing (except in rare cases where
brackets are needed...) - makepkg does not care so nor should you.
3) $srcdr vs $srcdir. The quotes are good for people who build in
directories with spaces in their name - so it may be good to use quotes.
But I don't care about people who use spaces in directory names, so I am not
going to do this. Note the prototype does include quotes...
4) $startdir/src vs $srcdir. $srcdir is correct. As stated in the
PKGBUILD man page, there is no guarantee that these will continue to point
at the same directory in future pacman versions.
Case closed!
