On Fri, Oct 2, 2009 at 1:33 PM, Ronald van Haren wrote:

[...] I haven't really time to look at them. Are they just poor quality or do they possible

should be '...don't really have...' of course :-p Ronald

cc-ing to speedvin so he has a change to reply and take action. (speedvin if you reply please do so to the aur-general mailing list) (sorry for top posting) Ronald On 10/2/09, Xavier wrote:

On Fri, Oct 2, 2009 at 1:33 PM, Ronald van Haren wrote:

...

...

Actually, I would not recommend using any of these packages because of their poor quality : http://aur.archlinux.org/packages.php?K=SpeedVin&SeB=m

I haven't really time to look at them. Are they just poor quality or do they possible cause system breakage ?

btw, isn't that the guy who recently applied to become a TU?

Oh right, I didn't realize that. Actually I already complained : http://mailman.archlinux.org/pipermail/aur-general/2009-September/006559.htm... I didn't realize how correct my comment was !

About the other packages, I was not sure whether to mention them or not. The easiest way would have been to stay silent. If I start giving details, I should address them to the maintainer directly, in the AUR comments. But explaining everything that is wrong (there are all levels of problems : big ones, average, and minor details) will take much more time.

My biggest complaint was on the xorg-server-git one : http://aur.archlinux.org/packages/xorg-server-git/xorg-server-git/PKGBUILD extra package : http://repos.archlinux.org/viewvc.cgi/xorg-server/repos/extra-i686/PKGBUILD?revision=51034&view=markup

- it disables a lot of important features making it unusable (why using xserver-git if you disable ipv6 dri dri2 xvfb composite)

- it replaces one change of xorg-server pkgbuild for integration with libgl : # Needed for non-mesa drivers, libgl will restore it mv "${pkgdir}/usr/lib/xorg/modules/extensions/libglx.so" \ "${pkgdir}/usr/lib/xorg/modules/extensions/libglx.xorg" || return 1 by a completely broken symlink : msg "Fixes for non-Mesa drivers..." ln -s "${pkgdir}/usr/lib/xorg/modules/extensions/libglx.so" \ "${pkgdir}/usr/lib/xorg/modules/extensions/libglx.xorg" || return 1

Not only doing this makes xorg-server-git fileconflicts with libgl. It also creates a symlink which points to the $pkgdir where the package was built...

- it disables libwfb.so without any explanation (the old extra pkgbuild did that too, saying it libwfb was no longer needed. but last pkgbuild doesnt do it anymore. ok that one is a bit confusing)

- it does not provide/conflict xorg-server

- it cleans the build dir at the end of build() so you cannot check / re-use anything

- it defines unused variables (_gitver)

- instead of depending on -git packages, it would be better to depend on a specific version, which a real git package could provide. then it would also be possible to use a normal (non git) package if it is recent enough

List goes on and on.

Comments about other packages : - glib2-newest also seems to be a duplicate of extra - grub2-git has the date reversed ? - kernel26-bfs really had 300 releases ? - dwm-git ? why ? the official dwm repo is just hg, and actually even the use of dwm-hg is debatable (see archives of last month) - several PKGBUILDs have more than one empty md5sums array, for example this one has 3 : http://aur.archlinux.org/packages/xf86-input-mouse-git/xf86-input-mouse-git/... - actually variables which are just empty array should not be declared at all - all git packages do something funny : if [ -d $startdir/src/$_gitname ] ; then cd $_gitname why not if [ -d $_gitname ] , like the prototype does ? much less confusing. http://projects.archlinux.org/?p=abs.git;a=blob;f=prototypes/PKGBUILD-git.pr...

I am sure I would find much more to say by looking closer and going more into smaller details.

2009/10/2 Xavier

...

...

Actually, I would not recommend using any of these packages because of their poor quality : http://aur.archlinux.org/packages.php?K=SpeedVin&SeB=m

I haven't really time to look at them. Are they just poor quality or do

On Fri, Oct 2, 2009 at 1:33 PM, Ronald van Haren wrote: they

...

possible cause system breakage ?

btw, isn't that the guy who recently applied to become a TU?

Oh right, I didn't realize that. Actually I already complained :

http://mailman.archlinux.org/pipermail/aur-general/2009-September/006559.htm... I didn't realize how correct my comment was !

About the other packages, I was not sure whether to mention them or not. The easiest way would have been to stay silent. If I start giving details, I should address them to the maintainer directly, in the AUR comments. But explaining everything that is wrong (there are all levels of problems : big ones, average, and minor details) will take much more time.

My biggest complaint was on the xorg-server-git one : http://aur.archlinux.org/packages/xorg-server-git/xorg-server-git/PKGBUILD extra package :

http://repos.archlinux.org/viewvc.cgi/xorg-server/repos/extra-i686/PKGBUILD?revision=51034&view=markup

- it disables a lot of important features making it unusable (why using xserver-git if you disable ipv6 dri dri2 xvfb composite)

- it replaces one change of xorg-server pkgbuild for integration with libgl : # Needed for non-mesa drivers, libgl will restore it mv "${pkgdir}/usr/lib/xorg/modules/extensions/libglx.so" \ "${pkgdir}/usr/lib/xorg/modules/extensions/libglx.xorg" || return 1 by a completely broken symlink : msg "Fixes for non-Mesa drivers..." ln -s "${pkgdir}/usr/lib/xorg/modules/extensions/libglx.so" \ "${pkgdir}/usr/lib/xorg/modules/extensions/libglx.xorg" || return 1

Not only doing this makes xorg-server-git fileconflicts with libgl. It also creates a symlink which points to the $pkgdir where the package was built...

- it disables libwfb.so without any explanation (the old extra pkgbuild did that too, saying it libwfb was no longer needed. but last pkgbuild doesnt do it anymore. ok that one is a bit confusing)

- it does not provide/conflict xorg-server

- it cleans the build dir at the end of build() so you cannot check / re-use anything

- it defines unused variables (_gitver)

- instead of depending on -git packages, it would be better to depend on a specific version, which a real git package could provide. then it would also be possible to use a normal (non git) package if it is recent enough

List goes on and on.

Comments about other packages : - glib2-newest also seems to be a duplicate of extra - grub2-git has the date reversed ? - kernel26-bfs really had 300 releases ? - dwm-git ? why ? the official dwm repo is just hg, and actually even the use of dwm-hg is debatable (see archives of last month) - several PKGBUILDs have more than one empty md5sums array, for example this one has 3 :

http://aur.archlinux.org/packages/xf86-input-mouse-git/xf86-input-mouse-git/... - actually variables which are just empty array should not be declared at all - all git packages do something funny : if [ -d $startdir/src/$_gitname ] ; then cd $_gitname why not if [ -d $_gitname ] , like the prototype does ? much less confusing.

http://projects.archlinux.org/?p=abs.git;a=blob;f=prototypes/PKGBUILD-git.pr...

I am sure I would find much more to say by looking closer and going more into smaller details.

Ok thanks Xavier for testing.Now let's go! About dwm-git we can delate this package if not offical repos are not allowed. grub2-git can be delated too becouse the git repo is down. glib2-newest is needed to compile libsoup-git (see comments). kernel26-bfs - About this 300 relase we have voting on kernel26-bfs page what to do to change one variable in PKGBUILD and aplly new patch and most votes was for bumping pkgrel ;) xorg-server-git - I disable many things to stripe things down if someone like to have more things he can enable it in PKGBUILD. I will post conflict with xorg-server ;) And sorry about this poor quality PKGBUILDS. I think now I have no chanches for being a TU sadly :(

2009/10/3 Xavier

On Fri, Oct 2, 2009 at 9:58 PM, member SpeedVin wrote:

...

Ok thanks Xavier for testing.Now let's go! About dwm-git we can delate this package if not offical repos are not allowed.

It's not that it is not allowed. It's about the added value. If it provides exactly the same code as dwm-hg, just outdated, and from an unofficial source, then WHY ? Anyway hbekel posted a more detailed comment in AUR, so maybe just answer there.

...

kernel26-bfs - About this 300 relase we have voting on kernel26-bfs page what to do to change one variable in PKGBUILD and aplly new patch and most votes was for bumping pkgrel ;)

I just read one comment on AUR : "I want to put in a vote for using the pkgrel number to show package changes. Either using the BFS version and/or an iterative count when the PKGBUILD changes would be good with me. I don't check this page often and tend to use yaourt to tell me about AUR package updates. Because pkgrel isn't updated, this package always appears unchanged."

The right way is to use an interative count. Because you could do important changes/fixes to the PKGBUILD for the same BFS version.

Now I see you are using the two numbers for pkgrel : 300.2 . So bfs version + iterative count. I have never seen a pkgrel used like this, but I don't know if there is a guideline. And it seems like it should work.

...

xorg-server-git - I disable many things to stripe things down if someone like to have more things he can enable it in PKGBUILD.

Then please document this ! At least put a big warning or note before the configure line. Or even describe these changes in the pkgdesc.

I updated my packages now I think all is OK ;)Thanks for testing (It really helps to make PKGBUILDS better and better).