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 2 3 4 5 6 7 8 9 10 11 12 .. 15 Next › Last »

seawright commented on 2019-10-21 23:33 (UTC)

@Galaxy Tried using makepkg instead of yay and get error message: "oss-git is not available for the 'pentium4' architecture" even though uname -m returns i686 and /etc/pacman.conf has Architecture set to "auto".

Galaxy commented on 2019-10-19 06:27 (UTC)

I found my notebook is not supported by OSSv4 after trying a lot. Thus, I just test it with makepkg now.

The PKGBUILD says "arch=(i686 x86_64)", I have no idea why there are architecture issue.

As I remember, OSSv4 have two parts, kmod and tools, they use different config.c or something. "no-pic" is needed for kmod part. Tools part seems fine with "PIC".

All patches are fix for compatibility, which seems less likely to be a writing. Thus I think it is OK to use direct provider as filename. Like the Arabic numerals are in fact from India.

seawright commented on 2019-10-18 22:13 (UTC)

I used yay to build the package and did get a warning about "package not suitable for your architecture - proceed anyway?" to which I answered yes. Could this have caused galaxy.patch to be omitted?

erlhel commented on 2019-10-18 21:47 (UTC)

@seawright If you verified the problem and it helped to apply the patch manually I don't know. I gave it up, restored my backup and am now running oss on linux-lts with i686 again.

seawright commented on 2019-10-18 20:47 (UTC)

@erlhel OK now I am confused. The -fno-pic (along with -fno-pie) is already included in galaxy.patch which is included in PKGBUILD so should have been applied when the package was built. So why did I have to apply it manually?

seawright commented on 2019-10-17 20:59 (UTC)

All the patches are getting a bit messy and could do with a good clean up. I provided a patch which someone asked if anyone had a copy of. I never realised that it would get incorporated in the package under my username. I am not the author though I can't remember who is. There is at least one line of code nested in the ifdef statements that in its current form would never be used though I wouldn't want to remove it as it may be required for an unknown kernel version, but the version number in the patch would need to be changed.

seawright commented on 2019-10-17 20:48 (UTC)

@erlhel As for the "Not a valid ELF object error" It isn't a problem, just annoying. It doesn't appear to be directed to stdout or stderr or you could redirect it to /dev/null. It is produced by /usr/bin/ossvermagic when run from line 37 of the /usr/sbin/soundon script as "ossvermagic -z -s" and what it is saying is true: "/lib/modules/5.3.5-arch1-1.0-ARCH/kernel/crypto/lrw.ko.xz is not a valid ELF object". The file isn't a valid ELF object at least not until it is inflated with a liblzma-based decompression tool.

seawright commented on 2019-10-17 20:29 (UTC) (edited on 2019-10-18 10:09 (UTC) by seawright)

@erlhel Yes spot on. I had never seen the problem until I updated gcc to V9. Not sure whether adding -fno-pic would break an earlier version but it does remove the GLOBAL_OFFSET_TABLE error and allow the modules to be installed. The patch only requires one line of code to be changed though, as I applied it manually, I don't know where it should be inserted in PKGBUILD. 

--- oss-v4.2-build2017-src-gpl/setup/srcconf.c 2017-02-17 14:20:42.000000000 -0500
+++ oss-v4.2-build2017-src-gpl.wtware/setup/srcconf.c   2018-02-01 18:16:56.138166665 -0500
@@ -962,7 +962,7 @@
 #if defined(SCO_VERSION)
       fprintf (f, "CFLAGS=-O -D_KERNEL -D_DDI=8\n");
 #else
-      fprintf (f, "CFLAGS += -D_KERNEL\n");
+      fprintf (f, "CFLAGS += -D_KERNEL -fno-pic\n");
 #endif
 #ifdef HAVE_KERNEL_FLAGS
       add_kernel_flags (f);

erlhel commented on 2019-10-16 18:39 (UTC)

The kernel configuration. http://penyacom.org/p?q=eUtnMTE

erlhel commented on 2019-10-16 16:29 (UTC)

This is supposed to be the patch for the GLOBAL_OFFSET_TABLE error. I don't see it in my build log when I search for "-fno-pic". http://ossnext.trueinstruments.com/forum/viewtopic.php?f=3&t=5863&p=21678&hilit=GLOBAL_OFFSET_TABLE#p21678

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