Package Details: oss-git 5693e1e-2

Git Clone URL: https://aur.archlinux.org/oss-git.git (read-only, click to copy)
Package Base: oss-git
Description: Open Sound System UNIX audio architecture
Upstream URL: http://developer.opensound.com/
Keywords: oss
Licenses: GPL2
Conflicts: libflashsupport-oss, libflashsupport-oss-nonfree, oss, oss-nonfree
Provides: oss
Submitter: Nowaker
Maintainer: seawright
Last Packager: seawright
Votes: 26
Popularity: 0.000000
First Submitted: 2013-09-21 13:15 (UTC)
Last Updated: 2024-02-08 22:55 (UTC)

Dependencies (6)

Required by (12)

Sources (12)

Pinned Comments

Galaxy commented on 2019-10-24 02:55 (UTC)

The latest support Intel HDA is 0x8c20, and I am using a348. If your sound card is not listed there, it is not supported.

  • 8c20 ("8 Series/C220 Series Chipset High Definition Audio Controller")
  • a348 ("Cannon Lake PCH cAVS")

Latest Comments

« First ‹ Previous 1 .. 3 4 5 6 7 8 9 10 11 12 13 .. 15 Next › Last »

erlhel commented on 2019-10-16 03:23 (UTC)

The problem in last two comments was probably caused by some incompatibility between gcc and the kernel which was not updated to exactly the same level. https://github.com/lwfinger/rtlwifi_new/issues/487 I now got the same problem back which I reported below, and others before me. osscore: Unknown symbol GLOBAL_OFFSET_TABLE (err -2) And the "not a valid ELF object" error remains.

erlhel commented on 2019-10-16 02:15 (UTC)

I get this problem with gcc/plugin versions in the linking of kernel modules: http://penyacom.org/p?q=MHpTM2w STRUCTLEAK is set in the kernel 5.3.1-arch1-1.0-ARCH https://penyacom.org/p?q=d2g2TWY The gcc version is gcc-9.2.0-2.0

erlhel commented on 2019-10-15 23:59 (UTC)

I see this error in the build output, but it does not cause the build to fail. make[1]: Leaving directory '/home/erling/projects/oss-git/src/oss/build/kernel/OS/Linux' /bin/sh: line 0: cd: noregparm: No such file or directory make: *** [make.defs:62: dep_subdirs] Error 1 Build output: http://penyacom.org/p?q=SERJUW4

erlhel commented on 2019-10-15 23:22 (UTC)

I get return code -20 from soundoff.

erlhel commented on 2019-10-15 23:21 (UTC)

I still get errors like this, seemingly for every kernel module: ".../kernel/crypto/cmac.ko.xz is not a valid ELF object".What I use is 32 bit linux. archlinux32. I use the pentium4 architecture and compile the components with march=pentium4. The kernel is 5.3.1-arch1-1.0.ARCH. It's an Intel Pentium 4 computer.

Galaxy commented on 2019-10-14 07:13 (UTC)

I have updated both places.

makepkg works fine now.

erlhel commented on 2019-10-14 00:40 (UTC)

I also get GLOBAL_OFFSET_TABLE error -2. I get errors like this, seemingly for every kernel module: ".../kernel/crypto/cmac.ko.xz is not a valid ELF object" I tried both the github master link below and the AUR package. I did not understand which was the latest or most suitable. I did not understand the comment before this one, if there was something I should change in the installation. What I use is 32 bit linux. archlinux32. I use the pentium4 architecture but compile the components with march=i686. The kernel is 5.3.1-arch1-1.0.ARCH. It's an Intel Pentium 4 computer.

seawright commented on 2019-10-10 19:48 (UTC)

Pull request sent. Note: Should be patch -p3 <... in PKGBUILD to apply patch as left a/ and b/ in diff file.

Galaxy commented on 2019-10-10 02:41 (UTC)

@seawright

You can send pull request to <https://github.com/GalaxyAUR/oss-git/tree/master>.

seawright commented on 2019-10-09 21:28 (UTC) (edited on 2019-10-09 21:40 (UTC) by seawright)

It would appear that a 2nd kmod-link patch is required to fix the other Makefile in the /usr/lib/oss/build directory.

diff -ru setup/Linux/oss/build.orig/Makefile.tmpl setup/Linux/oss/build/Makefile.tmpl
--- setup/Linux/oss/build.orig/Makefile.tmpl    2019-10-09 12:48:41.351431860 +0100
+++ setup/Linux/oss/build/Makefile.tmpl 2019-10-09 20:46:45.143954962 +0100
@@ -5,6 +5,7 @@
 ifneq ($(KERNELRELEASE),)
obj-m := MODNAME.o
+   MODNAME-objs := MODNAME_wrapper.o MODNAME_mainline.o 
else
The install script install.sh also requires patching but it's too long to include in a comment. Would it be OK to email it to the package maintainer?

« First ‹ Previous 1 .. 3 4 5 6 7 8 9 10 11 12 13 .. 15 Next › Last »