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?).

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) -- Daniel J Griffiths (Ghost1227) griffithsdj@archlinux.us http://ghost1227.com

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.

Eric Bélanger wrote:

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.

It works only the first time as updating does not reset it... Allan

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

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