Hello Heiko,

This is an upstream issue. It seems, that gspcav1 1.00.20 doesn't work with kernels > 2.6.26, as I've just read in a German forum.

The file semaphore.h is now located in /usr/src/linux-2.6.30-fbcondecor/include/linux.

So the file gspca_core.c in the gspcav1-fbcondecor package needs to be patched and "asm/semaphore.h" needs to be changed to "linux/semaphore.h".

As a workaround you can add this line to your PKGBUILD: sed -i "s:asm\/semaphore.h:linux\/semaphore.h" gspca_core.c

But you should also file a bug report to upstream, so that the gspca developers can update the software, so that it compiles with kernel 2.6.27 and above.

I tried adding that line: build() { cd $startdir/src/gspcav1-20071224 sed -i -e "s/KERNEL_VERSION = .*/KERNEL_VERSION = ${_kernver}/" Makefile sed -i "s:asm\/semaphore.h:linux\/semaphore.h" gspca_core.c <----- HERE make || return 1 #Install kernel module install -D -m644 gspca.ko $startdir/pkg/lib/modules/$_kernver/kernel/drivers/media/video/usbvideo/gspca.ko sed -i -e "s/KERNEL_VERSION='.*'/KERNEL_VERSION='${_kernver}'/" $startdir/*.install } I still recieved the same installation error messages. Forgive me if I just put it in the wrong place, but like I said before, I am new to package workings and installations, so please avoid ambiguity if it is based on the assumption of my knowledge. I started poking around in gspca_core.c, and I noticed several inclusions that look like they should be changed from the asm directory to the linux directory (I think one actually had a typo as well), but I do not know how to work around the md5sums validity checker.

I have reduced the amount of errors by changing paths: #include #include #include #include #include This is what I am left with: make -C /lib/modules/2.6.30-fbcondecor/build SUBDIRS=/home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224 CC=cc modules make[1]: Entering directory `/usr/src/linux-2.6.30-fbcondecor' CC [M] /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/gspca_core.o In file included from /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/gspca_core.c:845: /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/utils/spcausb.h: In function ‘spca5xxRegRead’: /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/utils/spcausb.h:95: error: implicit declaration of function ‘info’ /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/utils/spcausb.h: In function ‘spca_set_interface’: /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/utils/spcausb.h:278: error: implicit declaration of function ‘warn’ In file included from /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/gspca_core.c:853: /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/Sunplus-jpeg/sp5xxfw2.h: In function ‘sp5xxfw2_init’: /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/Sunplus-jpeg/sp5xxfw2.h:122: error: called object ‘info’ is not a function /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/Sunplus-jpeg/sp5xxfw2.h:136: error: called object ‘info’ is not a function /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/Sunplus-jpeg/sp5xxfw2.h:141: error: called object ‘info’ is not a function /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/Sunplus-jpeg/sp5xxfw2.h:148: error: called object ‘info’ is not a function /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/Sunplus-jpeg/sp5xxfw2.h:176: error: called object ‘info’ is not a function /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/Sunplus-jpeg/sp5xxfw2.h: In function ‘sp5xxfw2_start’: /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/Sunplus-jpeg/sp5xxfw2.h:214: error: called object ‘info’ is not a function /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/Sunplus-jpeg/sp5xxfw2.h:230: error: called object ‘info’ is not a function /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/gspca_core.c: In function ‘spca5xx_ioctl’: /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/gspca_core.c:2463: error: implicit declaration of function ‘video_usercopy’ /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/gspca_core.c: At top level: /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/gspca_core.c:2609: error: unknown field ‘owner’ specified in initializer /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/gspca_core.c:2609: warning: initialization from incompatible pointer type /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/gspca_core.c:2611: error: unknown field ‘type’ specified in initializer /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/gspca_core.c:2615: warning: initialization from incompatible pointer type /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/gspca_core.c: In function ‘spca50x_create_sysfs’: /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/gspca_core.c:2769: error: implicit declaration of function ‘video_device_create_file’ /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/gspca_core.c:2780: error: implicit declaration of function ‘video_device_remove_file’ /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/gspca_core.c: In function ‘spca5xx_probe’: /home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/gspca_core.c:4301: error: incompatible types when assigning to type ‘struct device’ from type ‘struct device *’ make[2]: *** [/home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224/gspca_core.o] Error 1 make[1]: *** [_module_/home/aaron/src/gspcav1-fbcondecor/src/gspcav1-20071224] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.30-fbcondecor' make: *** [default] Error 2 ==> ERROR: Build Failed. Aborting... Any more advice? Heiko Baums wrote:

Am Wed, 8 Jul 2009 14:52:24 -0400 schrieb Aaron Lane :

...

I tried adding that line:

build() { cd $startdir/src/gspcav1-20071224 sed -i -e "s/KERNEL_VERSION = .*/KERNEL_VERSION = ${_kernver}/" Makefile sed -i "s:asm\/semaphore.h:linux\/semaphore.h" gspca_core.c <----- HERE make || return 1

I just see, that I made a few typos in the sed command. Maybe that's why you still get the same error.

This is the correct one: sed -i "s:asm\/semaphore\.h:linux\/semaphore\.h:g" gspca_core.c

The position of the sed command looks correct.

...

I started poking around in gspca_core.c, and I noticed several inclusions that look like they should be changed from the asm directory to the linux directory (I think one actually had a typo as well), but I do not know how to work around the md5sums validity checker.

To look for the existence and location of kernel header files just run this command on the console: find /usr/src/linux-2.6.30-fbcondecor -iname "*semaphore*"

Replace semaphore with parts of the other file names.

Then you can add more sed commands as you need.

To generate new md5sums just run this command: makepkg -g

Cheers, Heiko

This message is on the AUR home page now: "The AUR no longer manages the community repo. Entries on this site may be out of date." Principally a good idea. But will community be integrated into the package search on http://www.archlinux.org/packages/ or is such a package database on a separate location, so that community packages could be flagged out-of-date e.g.? Heiko

On July 22, 2009 06:58:31 pm Daniel J Griffiths wrote:

Community has a bugtracker, which should (ideally) be used to notify us if a package is out of date or broken. Right now the Flyspray for [community] has a rather clear notice that says: "Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!". Shouldn't that notice be updated to reflect current changes. What would be the recommended way of notifying TU's of an outdated package (mailing list or bugtracker?).

On Wed, Jul 22, 2009 at 7:32 PM, Daniel J Griffiths wrote:

Ronuk Raval wrote:

...

On July 22, 2009 06:58:31 pm Daniel J Griffiths wrote:

...

Community has a bugtracker, which should (ideally) be used to notify us if a package is out of date or broken.

Right now the Flyspray for [community] has a rather clear notice that says: "Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!".

Shouldn't that notice be updated to reflect current changes. What would be the recommended way of notifying TU's of an outdated package (mailing list or bugtracker?).

Personal opinion... Update the bugtracker to reflect the lack of a 'flag out of date' option for community anymore, use bugtracker for anything related to community packages. The TUs as a whole need to use the bugtracker more anyway. (Wonder, back me up here)

The 'flag out of date' option for community still works (unless it was disabled). Users just need to check the package version in the repo instead of the version displayed in AUR to know if a package is out-of-date or not.

2009/7/23 Heiko Baums :

Am Wed, 22 Jul 2009 19:46:45 -0400 schrieb Eric Bélanger :

...

The 'flag out of date' option for community still works (unless it was disabled).  Users just need to check the package version in the repo instead of the version displayed in AUR to know if a package is out-of-date or not.

I understood the message on the AUR homepage so, that the community packages shall be removed from AUR (in the future). Or did I misinterpret it?

I think it's best to remove the list of [community] packages from the AUR instead of keeping them in a frozen state. http://archlinux.de has updated information for [community]. That could be used till [community] is integrated into the main website or some other solution is found. -- Abhishek

Daniel J Griffiths wrote:

Personal opinion... Update the bugtracker to reflect the lack of a 'flag out of date' option for community anymore, use bugtracker for anything related to community packages. The TUs as a whole need to use the bugtracker more anyway. (Wonder, back me up here)

personally i wouldn't want to get out of date notification via bugtracker. i prefer that community should be moved on the front page. -- Ionut

2009/7/23 Roman Kyrylych :

This is absolutely no-go because this way bugtracker will be flooded with out-of date messages that have no useful information.

Agreed. The web interface is the best place to mark out-of-date. For now, people can send to the maintainer directly.

+1 for complete merging community into main website (with limited permissions for TUs) and removing community-related part of AUR (with a notice that if there was some important info in comments - it should be reported as bugs or it will be lost)

This information could be kept archived somewhere. A simple HTML dump of the all the community package pages would suffice.

(if there would be possibility to limit permissions per category then I would love to merge Community Packages bugtracker project as well, but that's not an option at this time).

That'd be really nice if possible. Then I wouldn't have to file two bugs for each namcap tag. -- Abhishek

2009/7/23 Loui Chang :

On Thu 23 Jul 2009 22:04 +0530, Abhishek Dasgupta wrote:

...

This information could be kept archived somewhere. A simple HTML dump of the all the community package pages would suffice.

Well, I won't remove the packages outright. I'll just dummify them so they won't appear in the AUR. Any particular reason that you'd want to archive it though?

Archiving the pages is easy, also some comments in the package pages are useful for now. -- Abhishek

2009/7/24 Loui Chang :

I know archiving is easy. I could just do a mysqldump. Is there an application that you need the data for?

No, just the data could be useful in the future. -- Abhishek

On Wed, Jul 22, 2009 at 7:11 PM, Aaron Griffin wrote:

On Wed, Jul 22, 2009 at 5:51 PM, Heiko Baums wrote:

...

This message is on the AUR home page now: "The AUR no longer manages the community repo. Entries on this site may be out of date."

Principally a good idea. But will community be integrated into the package search on http://www.archlinux.org/packages/ or is such a package database on a separate location, so that community packages could be flagged out-of-date e.g.?

Actually, I'm still not sure on what we want to do here. I'd like input from the TUs as to what they'd prefer....

Right now I'm thinking we may just integrate community into the main site search, and give the TUs access to the dev website... but we need to play with permissions to make sure people can only do what they're supposed to

I'm in favour of this idea. It would simplify things for dev or TU/dev who maintain packages in both core/extra and community. And for users to search for binary packages.

2009/7/23 Evangelos Foutras : [snip]

That would be best, in my opinion. It would be quite practical to put [community] alongside with the other repos. Additionally, if the permission system in use allows it, we (TUs) could use [testing] (instead of the proposed [community-testing]) for [community] packages as well.

Setting permissions on a per-package basis is harder than setting permissions on a whole repository; this was discussed in the original thread for moving [community] to devtools. -- Abhishek