Re: [aur-general] Applying for TU-ship
Hello,
-----Original Message----- Date: Wed, 20 Aug 2008 16:44:53 +0200 Subject: Re: [aur-general] Applying for TU-ship From: "Ronald van Haren" To: "Discussion about the Arch User Repository (AUR)"
Please try to keep the discussion in one thread and don't start a new one for every question you get. Besides that, you misspelled my name ;) Sorry.
Besides that I took a quick look at some of your packages (started in alphabetical order I came to dia-svn if someone wants to check further). Some remarks:
- The # $ID line has no use for packages in unsupported. If you adopt a package which has been dropped into unsupported you can safely remove that line on the first update you do. Okay, I will do so.
- aumix needs a conflicts and provides field with aumix-gtk in community. Besides that the comment that is still there from the time it was in extra is a bit confusing. Done.
- '# Adopted by:' is no valid field. See for example autoaur Will change it to another Contributor line.
- A lot of packages have only arch=('i686') set. Please try to verify if it also works on x86_64. How can I do that? I have no access to a x86_64 machine. If a user reports that he successfully compiled it, I add the architecture to the arch-array.
- In biblatex you can create the directories with one install command like install -d $pkgdir/opt/texlive/texmf-local/{bibtex,doc/biblatex,tex/latex/biblatex} Same yields for biblatex-dw. I know that, but I do not think that this is convenient. In the way with the three lines it is easier to understand I think.
- In biblatex, LPPL is a custom license, so the license field should read license=('custom: LPPL'). Same for biblatex-dw LPPL is a common license. I made a feature request about that some time ago.
- Don't use the replaces field in bibledesktop-devel. For these cases conflicts and provides is enough (see man PKGBUILD) Will fix that with next update. They update at least once a week.
- try to follow the cvs guidelines in the build part of bluefish-cvs I will try.
- in bmeps: license field should read license=('BSD') not custom:BSD The same may apply for dklibs, i guess.
- concordance: don't use echo inside the build function. If you don't know the license, use license=('unknown') or something. The author drops no word about license issues. Done.
- Try to avoid using cp for copying one file. Use install instead in ctwm. Done.
- don't use the replaces field in dia-svn. I will build a new revision at once, fixing this.
Regards, Stefan
On Wed, Aug 20, 2008 at 08:58:52PM +0200, stefan-husmann@t-online.de wrote:
- A lot of packages have only arch=('i686') set. Please try to verify if it also works on x86_64. How can I do that? I have no access to a x86_64 machine. If a user reports that he successfully compiled it, I add the architecture to the arch-array.
That seems reasonable. That's my approach.
Please try to keep the discussion in one thread and don't start a new one for every question you get. Besides that, you misspelled my name ;) Sorry.
nah, don't worry.
- '# Adopted by:' is no valid field. See for example autoaur Will change it to another Contributor line.
- A lot of packages have only arch=('i686') set. Please try to verify if it also works on x86_64. How can I do that? I have no access to a x86_64 machine. If a user reports that he successfully compiled it, I add the architecture to the arch-array.
yes that is okay. Maybe post a comment where you ask for that would be a good idea (maybe you already did, I didn't check).
- In biblatex you can create the directories with one install command like install -d $pkgdir/opt/texlive/texmf-local/{bibtex,doc/biblatex,tex/latex/biblatex} Same yields for biblatex-dw. I know that, but I do not think that this is convenient. In the way with the three lines it is easier to understand I think.
okay. it wasn't really wrong. It's just I'm one of those lazy guys ;)
- In biblatex, LPPL is a custom license, so the license field should read license=('custom: LPPL'). Same for biblatex-dw LPPL is a common license. I made a feature request about that some time ago.
big oops. Sorry for that.
- in bmeps: license field should read license=('BSD') not custom:BSD The same may apply for dklibs, i guess.
probably. I haven't looked any further. Most likely a number of the comments I gave you come back in the other package, but I think you got the point and you're willing to learn, which is a good thing. Guess I can leave the rest of the packages to you :) Regards, Ronald
participants (3)
-
Loui
-
Ronald van Haren
-
stefan-husmann@t-online.de