Package Details: oss 4.2_2020-1

Git Clone URL: (read-only, click to copy)
Package Base: oss
Description: Open Sound System UNIX audio architecture
Upstream URL:
Keywords: oss
Licenses: GPL2
Conflicts: libflashsupport-oss-git, libflashsupport-oss-nonfree, oss-git, oss-nonfree
Submitter: keenerd
Maintainer: alexdw
Last Packager: alexdw
Votes: 48
Popularity: 0.000001
First Submitted: 2013-09-25 11:25 (UTC)
Last Updated: 2021-01-15 00:09 (UTC)

Latest Comments

alexdw commented on 2021-01-15 00:30 (UTC)

@seawright Thanks! Updated (4.2_2020-1) for this new release - OSS v4.2 build 2020 12-Jan-2021.

seawright commented on 2021-01-14 10:39 (UTC)

@alexdw New package uploaded at: sha512sum oss* 6b0c5390e92f9c9466669600321140b54d1fde5eeaef2f9938d6bdbc7ae686f4a1ad0fa9669a1505962eb515d61d29d8a677911557a9b245ce039e1ab3b77d69 oss-v4.2-build2020-src-gpl.tar.bz2

alexdw commented on 2020-12-29 17:44 (UTC)

Note: oss-nonfree has been updated to the latest release (4.2 build 2020):

However it doesn't look like the open-source (GPL) package has been updated yet: (latest files still oss-v4.2-build2019 from 19-Dec-2019)

If/when it is I can update this PKGBUILD similarly.

alexdw commented on 2019-05-29 06:52 (UTC)

@je-vv: As discussed in the previous comments, it needs some patches to build with latest kernels, but unfortunately I haven't had time to get it working with the latest version (4.2 build 2019). oss-nonfree (pre-compiled) should be working though, and maybe also oss-git.

je-vv commented on 2019-05-28 22:56 (UTC)

Failing to build, any dependency missing?

make[3]: Entering directory '/home/vasqueja/.cache/aurutils/snapshot/oss/src/oss-v4.2-build2017-src-gpl/build/os_cmd/Linux/ossdetect' cc -c -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -O -O -O -O -Wall -DOSS_LITTLE_ENDIAN -I../../../include -I../../../kernel/framework/include -I../../../kernel/OS/Linux -I../../../kernel/nonfree/include -I../../.. ossdetect.c -o ./ossdetect.o ossdetect.c: In function ‘create_devlinks’: ossdetect.c:555:31: warning: implicit declaration of function ‘makedev’ [-Wimplicit-function-declaration] if (mknod (dev, node_m, makedev (major, minor)) == -1) ^~~~~~~ cc -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -O -O -O -O -s -o ../../../target/sbin/ossdetect ./ossdetect.o -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now /usr/bin/ld: ./ossdetect.o: in function main': ossdetect.c:(.text+0x1028): undefined reference tomakedev' collect2: error: ld returned 1 exit status make[3]: [Makefile:34: ../../../target/sbin/ossdetect] Error 1 make[3]: Leaving directory '/home/vasqueja/.cache/aurutils/snapshot/oss/src/oss-v4.2-build2017-src-gpl/build/os_cmd/Linux/ossdetect' make[2]: [../../make.defs:11: subdirs] Error 1 make[2]: Leaving directory '/home/vasqueja/.cache/aurutils/snapshot/oss/src/oss-v4.2-build2017-src-gpl/build/os_cmd/Linux' make[1]: [../make.defs:11: subdirs] Error 1 make[1]: Leaving directory '/home/vasqueja/.cache/aurutils/snapshot/oss/src/oss-v4.2-build2017-src-gpl/build/os_cmd' make: [make.defs:11: subdirs] Error 1 ==> ERROR: A failure occurred in build(). Aborting...

alexdw commented on 2019-04-22 17:56 (UTC)

FYI, interestingly oss-nonfree works with the new version (4.2 build 2019):

alexdw commented on 2019-04-22 17:21 (UTC)

@seawright: No worries, and thanks for your contributions.

Does anyone have build2019 working in Arch? If so which patches did you need to apply? I tried a few mentioned in the oss-git comments but got stuck on this again (in dmesg) when trying to load with soundon: osscore: Unknown symbol GLOBAL_OFFSET_TABLE (err 0)

seawright commented on 2019-03-20 11:35 (UTC)

@alexdw: Thank you for your offer but I feel I must decline. While I use and therefore have an interest in the ongoing development of OSS4 I do not use Arch and have little knowledge of its package build system. I hope my refusal doesn't result in the Aur OSS* packages becoming unmaintained.

alexdw commented on 2019-03-18 21:59 (UTC)

@seawright: Thanks for the heads-up. I'll try to find some time later this week to update this AUR package (and oss-nonfree if required). Feel free if you would like to make the updatse yourself or even take over as Maintainer. I haven't had an active setup running OSS for a while so updates can take a while as I need to fire up a VM to test.

seawright commented on 2019-03-16 13:32 (UTC)

Re. my previous comment, I haven't tried it but 4front-tech have released an updated source archive which can be downloaded from:

It maybe as simple as updating "pkgver" & "sha512sums" in PKGBUILD to use the updated sources.

seawright commented on 2018-08-26 15:24 (UTC)

Oss-v4.2-build2017 is at least one year out of date and does not support the latest Linux Kernels. Some fixes have been applied to the git repository so if this package doesn't work try the oss-git AUR package. If still having problems follow (or add to) the comments posted there.

hapkin commented on 2018-08-25 14:38 (UTC) (edited on 2018-08-25 14:40 (UTC) by hapkin)

==> ERREUR : Une erreur s’est produite dans build(). Abandon… ==> ERREUR : Makepkg n'a pas pu construire oss.

Couldn't install oss on kernel linux416-rt / manjaro-linux. Can you fix it please?

Linux manjaro 4.16.18-rt12-MANJARO #1 SMP PREEMPT RT Fri Aug 3 12:10:46 UTC 2018 x86_64 GNU/Linux

alexdw commented on 2018-06-10 16:11 (UTC) (edited on 2018-06-10 16:11 (UTC) by alexdw)

@erlheh: The forums do appear to be down - perhaps someone who downloaded the patch can add it to the PKGBUILD or (better still) apply it upstream (will be picked up by the oss-git AUR package)?

Unfortunately it's not easy for me to test this any more as I no longer have an active environment with oss running - my main systems all use soundcards with ALSA support now.

erlhel commented on 2018-06-03 16:39 (UTC)

The system is 32 bit.

erlhel commented on 2018-06-03 16:37 (UTC)

The link to the patch does not seem to work any more. I tried with the 4.14 LTS kernel but I get the same problem - "is not a valid ELF object"

alexdw commented on 2018-02-18 20:26 (UTC)

@tedbell: Thanks for the information. I'll have a look at adding this to the PKGBUILD if it isn't applied upstream soon.

tedbell commented on 2018-02-18 19:50 (UTC) (edited on 2018-02-18 19:50 (UTC) by tedbell)

Will not compile under kernel 4.15

See here for patch:

alexdw commented on 2017-11-05 09:12 (UTC)

@erlhel: Did you manage to fix this? Sorry for the slow response - I was moving home and don't have a 32 bit environment immediately available so would have to set one up to test this.

erlhel commented on 2017-09-23 15:24 (UTC)

I got a problem when starting oss. From dmesg: "osscore: Unknown symbol _GLOBAL_OFFSET_TABLE_ (err 0)" oss-nonfree worked. Installed packages: oss-4.2_2017-2 linux-4.12.13-1 The system is 32 bit.

alexdw commented on 2017-02-26 11:18 (UTC)

Updated (4.2_2017-2) for new source package (17-Feb-2017): @agrajag: Thank you for the new version notification.

alexdw commented on 2017-02-13 23:23 (UTC)

Updated (4.2_2017-1) for new release - OSS v4.2 Build 2017: Thanks again to nuc for the notification.

alexdw commented on 2017-02-13 06:32 (UTC)

@nuc: Thank you for the new version notification; I'll update the AUR OSS packages (oss, oss-git, oss-nonfree) soon.

alexdw commented on 2016-12-22 16:04 (UTC) (edited on 2016-12-26 19:23 (UTC) by alexdw)

@kgunders: As a (rather belated) update, I've submitted the patches as a merge request to the OSS git repo on SourceForge (, and (as far as I can tell) they have been accepted.

alexdw commented on 2016-12-21 23:26 (UTC)

Updated (4.2_2011-6) with a patch to make oss work with kernel 4.8 compiled with CONFIG_HARDENED_USERCOPY (enabled by default for the Arch Linux kernel).

alexdw commented on 2016-12-21 17:06 (UTC)

Quick update - I've found that the issue with kernel 4.8 is the new CONFIG_HARDENED_USERCOPY feature (more details in the oss forum thread: oss works with linux 4.8 if your kernel is compiled without CONFIG_HARDENED_USERCOPY. I'll have a look at writing a patch to make it work with this feature (which is enabled by default for the Arch 4.8 kernel).

ratatat commented on 2016-11-12 22:35 (UTC)

@alexdw - Same exact thing here (just so you know). Thanks for all your work!

alexdw commented on 2016-10-31 00:19 (UTC)

Confirmed broken for me with kernel 4.8.4 (possibly all 4.8) - osstest causes segmentation fault with any of the oss packages (oss, oss-git, oss-nonfree). I might not have too much time to investigate at the moment, but for a start have posted a topic on the OSS forums:

alexdw commented on 2016-10-28 06:57 (UTC)

@kgunders: Thank you! I think I've posted a patch or two on the OSS forums before but I haven't looked at getting them directly upstream. I'll have a look this weekend after checking what's going on with kernel 4.8.2.

kgunders commented on 2016-10-27 23:44 (UTC)

alexdw- you do an awesome job of keeping ossv4 up on arch. Have you ever tried to get your patches merged upstream? Would maybe be nice for other distro maintainters not to have to reinvent the wheel every kernel update.

alexdw commented on 2016-10-21 07:00 (UTC)

@KennyLives: Thanks for the heads-up. I'll try to have a look at this over the weekend.

KennyLives commented on 2016-10-20 04:00 (UTC)

October 19 2016: Broken after kernel update 4.8.2-1-ARCH

alexdw commented on 2016-06-14 23:10 (UTC)

Uploaded a new version with a patch to allow compilation with kernel 4.6. Thanks again to kgunders and ratatat for the information.

alexdw commented on 2016-06-14 22:31 (UTC)

OK, I just had a look at this and I think it's due to a mismatch between the return type of the function "osspci_remove" in "" (static int) and the ".remove" component of the "pci_driver" structure (void). A patch on "" to resolve this mismatch should hopefully fix this.

alexdw commented on 2016-06-12 22:11 (UTC)

@ratatat: Thanks for the information. From that I wonder if the easy fix would be to change the compiler parameters to not treat this warning as an error? Probably it would be better to actually fix the code to not trigger this warning.

ratatat commented on 2016-06-10 16:41 (UTC)

sudo sh /usr/lib/oss/build/ gives OSS build environment set up for REGPARM kernels Building module osscore Building module oss_ali5455 Compiling module oss_ali5455 failed make -C /usr/lib/modules/4.6.2-1-ARCH/build M=/usr/lib/oss/build modules make[1]: Entering directory '/usr/lib/modules/4.6.2-1-ARCH/build' CC [M] /usr/lib/oss/build/oss_ali5455.o In file included from /usr/lib/oss/build/oss_ali5455.c:21:0: /usr/lib/oss/build/ error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .remove = osspci_remove ^~~~~~~~~~~~~ /usr/lib/oss/build/ note: (near initialization for ‘osspci_driver.remove’) cc1: some warnings being treated as errors scripts/ recipe for target '/usr/lib/oss/build/oss_ali5455.o' failed make[2]: *** [/usr/lib/oss/build/oss_ali5455.o] Error 1 Makefile:1429: recipe for target '_module_/usr/lib/oss/build' failed make[1]: *** [_module_/usr/lib/oss/build] Error 2 make[1]: Leaving directory '/usr/lib/modules/4.6.2-1-ARCH/build' Makefile:15: recipe for target 'default' failed make: *** [default] Error 2

alexdw commented on 2016-06-08 22:17 (UTC)

@kgunders: Thanks for the heads-up; I'll try to have a look at this over the weekend.

kgunders commented on 2016-06-08 19:58 (UTC)

Head's Up: broken on 4.6.1 kernel ;(

Xylemon commented on 2016-04-13 06:10 (UTC)

Thanks for the response alexdw, 1) I am not sure if there are any, but if you're going for a 'standard' OSS install then I guess the PKGBUILD should be left as is (I can always edit it in anyway I suppose). There is currently talk of some new OSS work, I'll suggest this feature to be upstreamed. 2) Sure, I'll look into this soon.

alexdw commented on 2016-04-10 11:10 (UTC)

@Xylemon: You're welcome, and thank you for your suggestions. 1) Are there any disadvantages to changing this config setting? If not then shouldn't this be suggested as an upstream change to OSS? Generally I have tried to keep this AUR package as close to the 'standard' OSS as possible. 2) I don't know how to do this but feel free to branch this oss AUR package into an 'oss-openrc' for this purpose.

Xylemon commented on 2016-04-08 18:06 (UTC)

Hi, I wanted to thank you for providing OSS support on Arch and I have two suggests to help improve the experience: 1) You should add this bit right before the configure process: sed -e "s;grc_max=3;grc_max=6;g" -i "setup/srcconf.c" sed -e "s;GRC_MAX_QUALITY=3;GRC_MAX_QUALITY=6;g" -i "configure" It allows you to use additional high quality resamplers in Vmix by editing the configure script. Credit to the funtoo ebuild for this one. 2) Could you (or perhaps we could) make an openrc version of this PKGBUILD? This would be great for people who don't want to use systemd.

alexdw commented on 2015-08-10 19:44 (UTC)

@Geistesblitz: I'm not sure I fully understand what you're getting at, or how it relates to this AUR oss package. Similarly, I can't find a new version of oss that would mean this one is out of date, so I've removed the out-of-date flag.

Geistesblitz commented on 2015-08-10 13:55 (UTC)

I really can't do a thing. The scripts should be more powerful for a noobie as me because the kernel's always changing and the compatibility is not always full. I wish that the autobuild system:PKGBUILD should do more things, better, with a richer log in which we could learn exactly the entire steps that are needed to use this professional sound system in our lives. Offtopic: I wish that Linus should implement OSS by default , entirely , because as I think it is : there are better maths in the code that there are in ALSA, maybe I'm completly wrong but that's what I've heard... The FreeBSD guys would be happy if the porting system would be far easier. Still Offtopic : why ARchlinux have lost the allmightlypower rc.conf ... That was something , the BSD hierarchy is far more simple : rc.conf, loader.conf and you almost done . You should really fusion with this guys: Arch+Gentoo+FreeBSD = DeathofMicrosoft.

doru001 commented on 2015-06-26 18:49 (UTC)

@alexdw: Thank you, it works. The kernel update from 4.0.5 to 4.0.6 was required. The change of mirror I'm not sure.

alexdw commented on 2015-06-25 20:47 (UTC)

@doru001: That looks like an issue with the particular mirror rather than anything with this specific package. I just tried and this package works for me (with latest kernel: 4.0.6).

doru001 commented on 2015-06-25 10:27 (UTC)

sudo /usr/bin/pacman -U /home/user/bin/aur/oss/oss-4.2_2011-3-i686.pkg.tar.xz /home/user/bin/aur/oss/libflashsupport-oss-4.2_2011-3-i686.pkg.tar.xz gives error: failed retrieving file 'linux-headers-4.0.5-1-i686.pkg.tar.xz' from : The requested URL returned error: 404

alexdw commented on 2015-06-01 22:47 (UTC)

Updated (4.2_2011-3) with a patch for gcc-5. See: (the part on "extern inline")

alexdw commented on 2015-05-31 09:53 (UTC)

Correction: building OSS is broken with current gcc version - thanks @ruegerjr for the information.

alexdw commented on 2015-05-27 21:48 (UTC)

OSS appears to be broken again in latest (4.0.4) kernel. If I have time over the weekend I'll try to work out a patch for it.

alexdw commented on 2015-05-07 20:01 (UTC)

Updated (4.2_2011-2) with patch by "oss117" from OSS forums: This should fix the compile error for 4.x kernels (tested as working for 4.0.1).

kgunders commented on 2015-05-04 15:42 (UTC)

Unfortunate that OSS is broken on 4.x kernels: Directory preparation complete. Build ID will be 2011 make: *** No rule to make target 'build'. Stop. ==> ERROR: A failure occurred in build(). Aborting...

alexdw commented on 2015-03-01 23:25 (UTC)

Updated (4.2_2011-1) for build 2011. @KenjiTakahashi: Thank you for the notification.

alexdw commented on 2014-09-08 19:45 (UTC)

Updated (4.2_2010-2) for build 2010, some clean-up in the PKGBUILD as suggested by nuc (thank you!), use of mkaurball (for new .AURINFO requirement in AUR) and renaming libflashsupport-oss to not conflict with the other ones (seems to be another new AUR requirement). @nuc: Thanks again for all the information - much appreciated!

nuc commented on 2014-09-04 01:27 (UTC)

Just informing you guys that it is now possible to use Skype with OSS without PulseAudio! You can obtain the corresponding package here -> I have also modified the wiki entry for it -> Hope it's ok to post here :) @alexdw: While you'll be updating the package you might also fix some (minor) stuff on that occasion: In depends/makedepends 'gcc', 'sed', 'make' and 'libtool' are totally redundant since they are part of the base-devel group and thus needed by makepkg anyways (see Also constantly changing directory into $srcdir is an unnecessary step, since makepkg already switches into that directory by itself (see In conflicts, 'oss-linux', 'oss-linux-free' and 'oss-testing' are totally out of date and should be replaced by 'oss-git' and 'oss-nonfree'. (Of course similar changes need to be done for the other two packages) Keep up the good work! :)

alexdw commented on 2014-09-02 18:03 (UTC)

@nuc: Thanks for the new version notification. I'll have a look at updating the PKGBUILD to 2010 on Monday - I'm away travelling for work at the moment and won't have access to my primary (Linux) PC until then.

nuc commented on 2014-09-02 16:31 (UTC)

Hm seems they modified the upstream package on 26 August, I wonder why. However the 2009 build is outdated anyways and the PKGBUILD should be updated to 2010.

rulojuka commented on 2014-09-02 16:04 (UTC)

Hi, The sha512 checksum failed for oss-v4.2-build2009-src-gpl.tar.bz2 I think the sha512sum is outdated (or just wrong, because none of the files at check to the sum in the PKGBUILD) PKGBUILD: 116df88ffca4515b9fb2b5f25cebc5d5f4aacc26500d387d8db09d38edb4bacb9a82f7b4fe5669ebddbc42ef811eeb2c9a81c2bbd6953c16e7894544c0e6e092 oss-v4.2-build2009-src-gpl.tar.bz2 9fd40ee5ac10b312c97961060b34bb5f4db46eb6d993271f9cd21768910278e6af8b5196638542f25ac287411b42dae8b61c7189637a563c5d6f0bece0e9543d

alexdw commented on 2014-04-14 05:51 (UTC)

@Nowaker: OK, thanks - done. I'll have a look at fixing oss-git (if necessary) some time this week. @steadybright: If you use the updated package it should work for now. I can't say it will work after every Linux upgrade - 3.8.0, 3.10.0, 3.10.7 and 3.14.0 all caused issues so future upgrades might also.

Nowaker commented on 2014-04-14 01:16 (UTC)

@alexdw, Because you are a maintainer of oss-nonfree, please feel free to adopt this package and oss-git - I just disowned them. Thanks.

steadybright commented on 2014-04-14 01:13 (UTC)

@alexdw: The patch you posted worked for me as well (3.14.0-5). Thanks! So do I just install this patch after each Linux update to get oss working again?

alexdw commented on 2014-04-13 16:33 (UTC)

I've applied the same simple patch I used for oss-nonfree and changed the main source file to the latest build (2009) - seems to work for me (osstest runs with 3.14.0):

steadybright commented on 2014-04-12 18:46 (UTC)

Same problem as noted by seschwar on 2014-04-06: OSS does not work with 3.14.05-ARCH I received nearly identical message as seschwar pasted below.

seschwar commented on 2014-04-06 14:29 (UTC)

Does not work on linux-3.14: # sh /usr/lib/oss/build/ OSS build environment set up for REGPARM kernels Building module osscore Failed to compile OSS make -C /usr/lib/modules/3.14.0-3-ARCH/build M=/usr/lib/oss/build modules make[1]: Entering directory '/usr/lib/modules/3.14.0-3-ARCH/build' CC [M] /usr/lib/oss/build/osscore_wrapper.o /usr/lib/oss/build/osscore_wrapper.c: In function ‘oss_get_uid’: /usr/lib/oss/build/osscore_wrapper.c:471:3: error: incompatible types when returning type ‘kuid_t’ but ‘int’ was expected return current->cred->uid; ^ /usr/lib/oss/build/osscore_wrapper.c: In function ‘alloc_fop’: /usr/lib/oss/build/osscore_wrapper.c:997:14: warning: assignment from incompatible pointer type [enabled by default] fop->fsync = oss_no_fsync; ^ /usr/lib/oss/build/osscore_wrapper.c: In function ‘oss_pci_read_devpath’: /usr/lib/oss/build/osscore_wrapper.c:1671:3: warning: return discards ‘const’ qualifier from pointer target type [enabled by default] return dev_name(&dip->pcidev->dev); ^ /usr/lib/oss/build/osscore_wrapper.c: In function ‘oss_get_uid’: /usr/lib/oss/build/osscore_wrapper.c:475:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ scripts/ recipe for target '/usr/lib/oss/build/osscore_wrapper.o' failed make[2]: *** [/usr/lib/oss/build/osscore_wrapper.o] Error 1 Makefile:1274: recipe for target '_module_/usr/lib/oss/build' failed make[1]: *** [_module_/usr/lib/oss/build] Error 2 make[1]: Leaving directory '/usr/lib/modules/3.14.0-3-ARCH/build' Makefile:17: recipe for target 'default' failed make: *** [default] Error 2 You can try to apply alexdw's patch for oss-nonfree.

nuc commented on 2014-03-28 17:21 (UTC)

I noticed that there has been made some fix upstream to compile OSS under Linux: I see memmove being used there. Might this be an alternative fix? (as I see it differs from toksik's patch). @toksik: Maybe it would be nice if you committed your fixes to the OSS mailing list: The lead developer still accepts commits from there.

nuc commented on 2014-03-27 13:44 (UTC)

@Nowaker: Well if that is the case, @keenerd should be confident with taking it back into the repos. Could you ping him? (take at look at @keenerd's comment below) PS: And btw OSS v4.2_2009 is out:

Nowaker commented on 2014-02-01 14:37 (UTC)

@nuc, toksik provided patches and I applied them all, including soundon fix. If there's still an issue, you can try fixing it. I didn't have any issues with `soundon`.

nuc commented on 2014-02-01 14:35 (UTC)

Is there any news concerning the soundon fix, that keenerd mentioned? It would be really nice to have it back in the repos, since currently all binaries in the repos are being compiled without OSS support :(

freestyler7 commented on 2013-12-05 19:15 (UTC)

Thanks for the package. Worked perfectly.

nuc commented on 2013-11-16 19:39 (UTC)

oss 4.2_2008-3 is fully working, thanks!

Nowaker commented on 2013-11-16 18:00 (UTC)

I performed the same change to oss-git package. I couldn't verify if it's working though, so if anyone could have a look, I would be grateful.

Nowaker commented on 2013-11-16 17:37 (UTC)

Updates done. Thank you toksik!

toksik commented on 2013-11-14 18:53 (UTC)

I didn't expect that comments are stripped off of leading white space and tabs so the posted patch is a bit mangled. Here it is again: kmod-link.patch: @keenerd Great to hear you're interested in bringing OSS back into the repo. The soundon issue seems to be easy to fix: ossvermagic.patch: I could not reproduce the uninstall problem and might need some more details on it. However the deletion of the alsa modules could as well be replaced by some file in /etc/modprobe.d/ that blacklists these modules. @Nowaker I've also uploaded an updated PKGBUILD:

nuc commented on 2013-11-11 22:21 (UTC)

Oh great.. so Hannu Savolainen's statement was quite right > OSS doesn't use memmove at all so this problem must be caused by some > new version of gcc that geterates calls to memmove. I have never heard > about this kind of problem.

keenerd commented on 2013-11-11 20:51 (UTC)

> This removes the dependency on gcc-4.7 and will hopefully allow OSS to be readded to the repo. toksik, awesome! Not to be a BOFH, but if I brought it back into the repos I'd want the nastiest remaining bugs fixed first. The two major issues were 'soundon' and the uninstall script. 'soundon' would sometimes take several minutes to finish. (That was isolated to a single line in the soundon script, didn't look deeper.) The uninstall script had become a complete mess - it was supposed to put the alsa drivers back into place as if nothing happened. Instead you'd have to reinstall the kernel and reboot.

toksik commented on 2013-11-11 18:43 (UTC)

@Nowaker It is soley the OSS developers fault. Either they relied on something that cannot be relied on, especially not when they turn compiler optimizations on by default. It was pure luck that this did not affect OSS in the past. Or they are just doing the wrong thing to build the kernel module. My patch fixes the latter.

Nowaker commented on 2013-11-11 18:18 (UTC)

@toksik, Thank you very much for your input. I will update all the PKGBUILDs very soon. Is it something worth reporting to GCC issue tracker as a bug? Or it's just oss's fault?

toksik commented on 2013-11-11 18:14 (UTC)

I seem to have finally discovered the actual bug in OSS and was able to fix it properly. This removes the dependency on gcc-4.7 and will hopefully allow OSS to be readded to the repo. The patch below requires setup/Linux/oss/build/osscore.c to be renamed to osscore_wrapper.c (in prepare) and should be applied after all other patches. Explanation: When osscore.ko is loaded by running soundon dmesg shows osscore: no symbol version for memmove osscore: Unknown symbol memmove (err -22) saying two things: 1. The function memmove is called somewhere in the kernel module. Generally this is fine as the linux kernel provides the function. What is interesting is that it is never directly called in the OSS codebase. Instead it is GCC that, in newer versions, sometimes generates calls to memmove as part of its code optimization at optimization level "-O3". To be precise it is an assingment in the function setfragment_error in kernel/framework/audio/oss_audio_core.c that gets optimized in this way. GCC's behaviour is correct and even documented in it's man page. 2. Symbol version information for memmove is missing. The usual way to build a kernel module externally is to use the Makefile provided in /lib/modules/VERSION/build: It takes care of generating symbol version information and linking everything to a .ko kernel module. This is also what OSS does with it's linux kernel wrapper to generate /lib/oss/build/osscore.ko. What it does then is what causes the problem: The main part of OSS /lib/oss/objects/osscore.o, which unfortunately contains the call to memmove, is linked together with this osscore.ko to /lib/modules/extramodules-VERSION/oss/osscore.ko with a conventional "ld". This of course does not take care of symbol versioning so that it is missing for symbols only used in this main part of OSS. The fix is to hand both /lib/oss/build/osscore.c (renamed to osscore_wrapper.c to avoid name conflicts) and /lib/oss/objects/osscore.o (copied by to osscore_mainline.o) over to the provided Makefile that then generates symbol version information for the whole osscore.ko module. I've successfully tested the patch on x86_64 and i686 with gcc-4.8.2. --- setup/Linux/oss/build/ 2013-11-10 20:56:26.182816531 +0100 +++ setup/Linux/oss/build/ 2013-11-10 21:00:08.858276861 +0100 @@ -203,11 +203,8 @@ exit 3 fi -if ! $LD -r osscore.ko osscore_mainline.o -o /lib/modules/$UNAME/kernel/oss/osscore.ko -then - echo Linking the osscore module failed - exit 5 -fi + +cp -f osscore.ko /lib/modules/$UNAME/kernel/oss/osscore.ko if test -f Module.symvers then --- setup/Linux/oss/build/Makefile.osscore 2013-11-10 20:57:25.732493923 +0100 +++ setup/Linux/oss/build/Makefile.osscore 2013-11-10 20:59:46.185066359 +0100 @@ -5,6 +5,7 @@ ifneq ($(KERNELRELEASE),) obj-m := osscore.o + osscore-y := osscore_wrapper.o osscore_mainline.o else

RunningDroid commented on 2013-10-20 18:26 (UTC)

I tried adding the -L line to CFLAGS and the build failed the same way. Then I ran "pacman -Ql gcc47 | grep '\.a$' " and there weren't any *.a files, so I rebuilt gcc47 and that solved it.

Nowaker commented on 2013-10-20 10:24 (UTC)

@RunningDroid, I just tried building it to make sure it works. I installed gcc47 and oss from scratch, and got: ==> Finished making: oss 4.2_2008-2 (nie, 20 paź 2013, 12:06:38 CEST) Full log: "cannot find -lgcc" suggests gcc compile-time libs are not available. gcc47 is installed though... Could you please try adding something like this to gcc-4.7 call? -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.3 This is where *.a files reside: pacman -Ql gcc47 | grep '\.a$'

RunningDroid commented on 2013-10-20 02:12 (UTC)

I seem to be having trouble building this, the build fails with "/usr/bin/ld: cannot find -lgcc" makepkg build log:

seschwar commented on 2013-10-17 14:57 (UTC)

@Osune: I think it is unlikely that OSS is picked up by a TU and put into [community] again, because it does not build with Arch's current tool chain, which includes GCC 4.8. Also upstream isn't very active and does not keep up with Linux kernel development very well. This makes it unsuitable for a rolling release distribution. OSS support being dropped from VLC is unfortunate, but understandable from the maintainer's point of view. You could open an issue and nicely request it being readded on the grounds that it does not require any additional dependencies, practically does not increase the size of the package and basically doesn't impact VLC for non-OSS users in any way. Alternatively you could use mplayer, mpv or some GStreamer based video player, all of which still include OSS output. @Tibor: OSS does not build correctly with GCC 4.8 and later. We will only find out, whether this is a bug in GCC or in OSS, if someone which too much time bisects GCC and then locates the offending code in OSS. The gcc47 PKGBUILD was updated to allow installation alongside gcc-multilib. If you have any problems with building gcc47 report it in gcc47's comments. @all: Thank you all for your continued patronage. :P

TiborB commented on 2013-10-16 19:35 (UTC)

Hi, what is current status in regard to gcc47 dependency? It is still being listed in "makedepends" array....

Osune commented on 2013-10-15 00:45 (UTC)

Hoi, does this working package mean we will see (in near? future) oss in official repositories again? It's a shame that oss suport in most packages was droped since it moved to AUR (e.g. VLC). Thanks for maintaining OSS!

Nowaker commented on 2013-10-04 10:17 (UTC)

@Freso, you are right. And it's already documented. :) Will update all my pkgvers soon.

Nowaker commented on 2013-09-29 23:25 (UTC)

@lspci, It compiles but does not work. Try modprobe and you will see.

hav3lock commented on 2013-09-29 23:23 (UTC)

please update your pkgbuild to use gcc-libs instead of gcc47. Gcc47 is not necessary. The package compiled and built just fine for me using the current gcc-libs version. gcc47 is deprecated and not needed. please update.

Nowaker commented on 2013-09-29 21:09 (UTC)

Thanks guys for your contribution. @Freso, what you say would absolutely make sense for binary packages - as in official repositories. Whenever you build a *-git package from AUR, you get a current version from HEAD. pkgver only says when the maintainer last updated the PKGBUILD. pkgver may be "a1b2c3" but you clone a repo with "d4e5f6" on HEAD anyway. However, I will ask on aur-general or arch-general. It would be best to have official guidelines on the wiki. @seschwar, 1 - You put in on the bottom, I first didn't even notice that. 2 - We will duck it if I perform some other changes, so far it's you who mainly wrote the PKGBUILD. :D

Freso commented on 2013-09-29 13:00 (UTC)

Re: 4; the pkgver=yyyymmdd is deprecated since you can have any number of commits in one day and you won't be able to discern exactly which version of the software you run by just telling the day you fetched and make'd it. I'm guessing that the reason it "seems to be picked most often for -git packages on AUR", is that a lot of -git packages on AUR are outdated. :) For git packages, `git describe --always` (see e.g. morituri-git) or `echo $(git rev-list --count HEAD).$(git rev-parse --short HEAD)` (see e.g. seom-git) should give a usable version string.

seschwar commented on 2013-09-28 20:37 (UTC)

I am on i686, so I didn't notice the conflict between gcc47 with gcc-multilib. And I agree with the fact that we shouldn't force gcc47 on anyone except for compiling OSS. It looks like the conflict arises from gcc47's provides=('gcc=4.7') and gcc-multilib's conflicts=('gcc'). The packages actually have no conflicting files. Thus they could both be installed at the same time. I have asked the maintainer of gcc47 to fix this issue. This way we wouldn't have to worry about maintaining an extra GCC package just for OSS. To address your other points: 1. Did I forget that? 2. Contributor would be fine by me. /me tries to duck the responsibility :) 3. It seems to be a purely stylistic choice, but as a maintainer it is yours to make. 4. Thanks for fixing that. I totally forgot to do something sensible with pkgver().

Nowaker commented on 2013-09-28 19:13 (UTC)

@seschwar, I changed a few minor things before publishing oss and oss-git on AUR: 1. Added you to the PKGBUILD header on top, according to packaging standards.[1] 2. Marked you as Maintainer as well :) 2. Changed indentation to 2 spaces, as implicitly suggested in various places. [2] [3] 4. Changed oss-git pkgver to 20130928. There is no official format but this one seems to be picked most often for -git packages on AUR. [1] [2] [3]

Nowaker commented on 2013-09-28 18:53 (UTC)

I just uploaded your changes. Thank you seschwar! However, I am not satisfied with the dependency of gcc47 as it is conflicts with the core/gcc. If someone wants to use gcc 4.7 for all their compilation, it's OK, but forcing people to remove current gcc just to install one package is a no go. What do you think of writing of introducing gcc47-compat package and depend on it? ==> Continue installing gcc47 ? [Y/n] ==> [v]iew package contents [c]heck package with namcap ==> --------------------------------------------------- ==> Y [sudo] password for nowaker: loading packages... resolving dependencies... looking for inter-conflicts... :: gcc47 and gcc-multilib are in conflict (gcc). Remove gcc-multilib? [y/N] y error: failed to prepare transaction (could not satisfy dependencies) :: libtool: requires gcc=4.8.1 ==> WARNING: Your packages are saved in /tmp/yaourt-tmp-nowaker

seschwar commented on 2013-09-26 13:42 (UTC)

My previously pasted PKGBUILD made OSS install its modules into /usr/lib/modules/$KERNEL/kernel/oss. This PKGBUILD correctly installs them to /usr/lib/modules/$KERNEL/extramodules/oss. Also the split PKGBUILD should be accepted by the AUR now. Here it is:

Nowaker commented on 2013-09-25 18:56 (UTC)

Thanks for solving the issue. I will update the PKGBUILD shortly. Regarding the wrong description, I will fix it too - AUR just does not handle multiple packages in one PKGBUILD correctly.

klothius commented on 2013-09-25 18:54 (UTC)

Wrong description :D

seschwar commented on 2013-09-25 18:24 (UTC)

Following the suggestion in Petars's comment[1] I just updated my previously submitted PKGBUILD[2] to use GCC 4.7. It successfully compiles, modprobes and produces sound! Finally! Here[3] is the PKGBUILD. 1: 2: 3:

Nowaker commented on 2013-09-25 11:41 (UTC)

Adopted the package. I will try to continue the investigation from