Package Base Details: oss-git

Git Clone URL: https://aur.archlinux.org/oss-git.git (read-only, click to copy)
Keywords: oss
Submitter: Nowaker
Maintainer: Galaxy
Last Packager: Galaxy
Votes: 22
Popularity: 0.003574
First Submitted: 2013-09-21 13:15
Last Updated: 2019-11-01 17:19

Pinned Comments

Galaxy commented on 2019-10-24 02:55

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 ... Next › Last »

Galaxy commented on 2019-10-19 06:27

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

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

@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

@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

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

@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

@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

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

erlhel commented on 2019-10-16 16:29

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

erlhel commented on 2019-10-16 03:23

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.