You are not logged in.
@Ropid - I believe that when Arch packages are built, they do so in an environment that has [testing] enabled, whereas I currently build [repo-ck] with [testing] disabled. I can change this behavior moving forward, but probably not until I get some free time (this week maybe but more than likely over the weekend).
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Arch builds packages targeting the repo they are initially intended for. As core packages must pass through testing that means they are built against testing.
Packages going straight to extra/community would not be built against testing.
Edit:
You can also extract the .BUILDINFO from a package and see which packages were present in the build environment.
Last edited by loqs (2018-05-07 19:07:01)
Offline
@loqs - Thanks for the clarification. Again, when I build [repo-ck] in the future, I will be mirroring this behavior. I just don't have a chunk of time to devote to changing the build process now.
EDIT: Looks like gcc-8.1.0 just hit [core]. I will rebuild 4.16.7 using it now and freshen the repo. Watch for 4.16.7-2 to hit [repo-ck] in a few hours.
Last edited by graysky (2018-05-07 19:16:48)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Thinking about this some more, I think there's no need to change the build environment. It might even be a mistake? If things are built like for a 'testing' package, the same problem might show up in the opposite direction: linux-ck might be using newer versions of stuff, while a user at home then can't compile a dkms package because of using older versions. There's perhaps no good solution for this and best would be to simply keep things exactly like they are right now.
Last edited by Ropid (2018-05-07 19:37:29)
Offline
Ah the status quo!
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Thinking about this some more, I think there's no need to change the build environment. It might even be a mistake? If things are built like for a 'testing' package, the same problem might show up in the opposite direction: linux-ck might be using newer versions of stuff, while a user at home then can't compile a dkms package because of using older versions. There's perhaps no good solution for this and best would be to simply keep things exactly like they are right now.
Uh, I guess you could have [repo-ck] and [repo-ck-testing].
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Thnx, bauerbill too I tried
The new -ck-16.7.2 came down in a jiffy
I wonder whether compiling for the next day or two beats it or whether I should get a 2nd gentoo pc for such things
anti-X - artix - obarun - Void - systemD Free Space
Offline
I've been using repo-ck without issue for years. But last time I updated with pacman -Syu, I receive the following eror:
"error: failed retrieving file 'nvidia-ck-haswell-1:390.48-3-x86_64.pkg.tar.xz' from repo-ck.com : The requested URL returned error: 404"
I'm at a loss to know where to start looking. Any help will be greatly appreciated
Offline
I've been using repo-ck without issue for years. But last time I updated with pacman -Syu, I receive the following eror:
"error: failed retrieving file 'nvidia-ck-haswell-1:390.48-3-x86_64.pkg.tar.xz' from repo-ck.com : The requested URL returned error: 404"
I'm at a loss to know where to start looking. Any help will be greatly appreciated
the same problem here
I also tried mirror I found here - http://repo-ck.segfault.gq/$arch but: could not resolve host
any ideas? i have to use other kernel because i can't start GUI with kernel-ck now...
Jaki koniec świata.Ziemia to nie cały świat ,a tylko mały Wąchock we wszechświecie.
Offline
The missing nv packages are my fault... I bumped to 396.24 but the corresponding util package hasn't yet hit [extra]. Fixed now with nvidia-ck 2:390.48-1. Please refresh and report back.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
The missing nv packages are my fault... I bumped to 396.24 but the corresponding util package hasn't yet hit [extra]. Fixed now with nvidia-ck 2:390.48-1. Please refresh and report back.
Works great now. Thanks for the quick service.
Offline
@graysky, i know this is above and beyond, but could you either teach me, or connect me with instructions that teach me how to pull all the updated modules from drm-next and/or amd-staging-drm-next and include those with the linux-ck bulldozer.....
the tricky part is there is also libdrm which is the other half of whats needed as i understand? could you just show me what part of your package build pulls from there or something so i can kinda modularly inject and remove drm as needed?
i would even push a binary and/or pkgbuild w/ git repo to whichever repo afterwards in order to contribute.
if im not understanding this right, please enlighten me but i keep getting:
0] RIP: 0010:generic_reg_update_ex+0x12b/0x158 [amdgpu]
[25985.267921] RSP: 0018:ffffa6ee00b47790 EFLAGS: 00010246
[25985.267922] RAX: ffffa6ee00b477b0 RBX: ffff9535a7765280 RCX: 0000000000000000
[25985.267923] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9535a89ccb00
[25985.267923] RBP: ffffa6ee00b477f8 R08: 0000000000000000 R09: 0000000000000000
[25985.267924] R10: 0000000000000001 R11: 00000000fffffffb R12: 0000000000000000
[25985.267925] R13: 0000000000000000 R14: ffff9535a7778000 R15: ffff95359edc9000
[25985.267926] FS: 00007fd270a7f940(0000) GS:ffff9535bed00000(0000) knlGS:0000000000000000
[25985.267926] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[25985.267927] CR2: 0000563f2f92efd0 CR3: 000000041edd8000 CR4: 00000000000406e0
[25985.267928] Call Trace:
[25985.267970] dce110_stream_encoder_update_hdmi_info_packets+0x205/0x398 [amdgpu]
[25985.268009] dc_stream_adjust_vmin_vmax+0xb9/0xe8 [amdgpu]
[25985.268048] set_freesync_on_streams.part.4+0x43/0x210 [amdgpu]
[25985.268087] mod_freesync_notify_mode_change+0x11b/0x140 [amdgpu]
[25985.268127] amdgpu_dm_atomic_commit_tail+0x52c/0xd80 [amdgpu]
[25985.268129] ? preempt_count_add+0x68/0x98
[25985.268131] ? _raw_spin_unlock_irq+0x1d/0x38
[25985.268132] ? wait_for_common+0x112/0x190
[25985.268133] ? _raw_spin_unlock_irq+0x1d/0x38
[25985.268134] ? wait_for_common+0x112/0x190
[25985.268140] commit_tail+0x3d/0x68 [drm_kms_helper]
[25985.268146] drm_atomic_helper_commit+0x103/0x110 [drm_kms_helper]
[25985.268152] restore_fbdev_mode_atomic+0x1a7/0x210 [drm_kms_helper]
[25985.268158] drm_fb_helper_restore_fbdev_mode_unlocked+0x45/0x90 [drm_kms_helper]
[25985.268163] drm_fb_helper_set_par+0x29/0x58 [drm_kms_helper]
[25985.268165] fb_set_var+0x212/0x3e0
[25985.268167] ? memcg_check_events.isra.21+0x39/0x1f0
[25985.268170] fbcon_blank+0x26e/0x310
[25985.268173] do_unblank_screen+0x9b/0x150
[25985.268175] ? vt_ioctl+0x363/0x10f8
[25985.268176] ? filename_parentat.isra.17.part.18+0xd3/0x140
[25985.268178] ? __offline_pages+0x440/0x7f0
[25985.268179] ? tty_ioctl+0x215/0x870
[25985.268181] ? __inode_wait_for_writeback+0x7f/0xe8
[25985.268182] ? current_time+0x16/0x60
[25985.268184] ? do_vfs_ioctl+0xa4/0x610
[25985.268186] ? __fput+0x121/0x1e0
[25985.268187] ? preempt_count_add+0x68/0x98
[25985.268189] ? SyS_ioctl+0x61/0x80
[25985.268190] ? do_syscall_64+0x74/0x190
[25985.268192] ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[25985.268193] Code: 89 da 48 8b 07 48 8b 40 38 e8 42 e8 6b c4 48 8b 74 24 18 65 48 33 34 25 28 00 00 00 89 d8 75 20 48 83 c4 50 5b 41 5c 41 5d 5d c3 <0f> 0b e9 1a ff ff ff 44 89 e0 4d 89 cd 41 bc 01 00 00 00 eb 99
[25985.268217] ---[ end trace 4534303478d331e5 ]---
which the amd-staging-drm-next kernels fix, but then i dont have all the ck-bulldozer optimizations that make an enormous difference for me.
Offline
git checkout amd-staging-drm-next
git remote add ck https://github.com/ckolivas/linux.git
git fetch ck
git cherry-pick caae7ce4055208164b84678a509e8dedc2ba43b7 #repeat for the rest of the commits from https://github.com/ckolivas/linux/commits/4.16-ck
Note this will break once amd-staging-drm-next rebases from 4.16 to 4.17
Then apply the rest of the linux-ck PKGBUILD (the stable patch will probably fail to apply due to conflicting changes relating to AMDGPU)
Last edited by loqs (2018-05-11 20:13:37)
Offline
thank you, i really appreciate you for taking the time to help me, between this and mesa bugs i dont know if im doing wrong or is buggy, because eitherway potential to fail :D
thanks so much you really made my night and next several days :D
Offline
Now shipping nvidia-390xx-ck on [repo-ck]. Please use this thread to report any bugs as usual.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
nvidia-390xx-ck ~ Very cool... .. !
Last edited by keepitsimpleengineer (2018-05-12 21:25:05)
Al Einstein: "Man soll die Dinge so einfach machen wie möglich ~ aber nicht einfacher." (Things should be as simple as possible ~ but not too simple.) ~ Al (Einstein) war ein Cousin von Albert, "Al" ist die Abkürzung für Aloysius
Offline
Now shipping nvidia-390xx-ck on [repo-ck]. Please use this thread to report any bugs as usual.
==> Validating source files with sha256sums...
NVIDIA-Linux-x86_64-390.48-no-compat32.run ... Passed
kernel-4.16.patch ... Passed
==> Extracting sources...
==> Starting prepare()...
Creating directory NVIDIA-Linux-x86_64-390.48-no-compat32
Verifying archive integrity... OK
Uncompressing NVIDIA Accelerated Graphics Driver for Linux-x86_64 390.48....
patching file kernel/common/inc/nv-linux.h
patching file kernel/conftest.sh
==> Starting build()...
cat: /usr/lib/modules/extramodules-4.16-ck/version: No such file or directory
==> ERROR: A failure occurred in build().
...and after checking to see if linux-ck was installed (it wasn't)
[ljohnson@KISE-066 nvidia-390xx-ck]$ makepkg -srci
==> Making package: nvidia-390xx-ck 390.48-1 (Sun May 13 11:16:00 PDT 2018)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found NVIDIA-Linux-x86_64-390.48-no-compat32.run
-> Found kernel-4.16.patch
==> Validating source files with sha256sums...
NVIDIA-Linux-x86_64-390.48-no-compat32.run ... Passed
kernel-4.16.patch ... Passed
==> Extracting sources...
==> Starting prepare()...
Creating directory NVIDIA-Linux-x86_64-390.48-no-compat32
The directory 'NVIDIA-Linux-x86_64-390.48-no-compat32' already exists. Please either
move the existing directory out of the way, or specify a
different directory with the '--target' option.
==> ERROR: A failure occurred in prepare().
Aborting...
UPDATE: Turns out booting with linux-ck-k10 fails due to failing to load nic, still sorting that out
~precompiled nvidia-390xx-ck installs as expected
Possible compile error above due the fact that extra/nvidia-390xx is also installed..?
Last edited by keepitsimpleengineer (2018-05-13 20:17:57)
Al Einstein: "Man soll die Dinge so einfach machen wie möglich ~ aber nicht einfacher." (Things should be as simple as possible ~ but not too simple.) ~ Al (Einstein) war ein Cousin von Albert, "Al" ist die Abkürzung für Aloysius
Offline
keepitsimpleengineer, please edit your post to add code tags. While you're at it, be sure to include the full command you used. The first error is very clearly your failing as linux-ck is properly listed as a dependency. The second most likely is as well depending on the flags you passed to makepkg. It looks like this has nothing in particular to do with the linux-ck packages (and definitely not the precompiled binaries in [repo-ck]) but is just a failure to use makepkg properly.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
@keepitsimpleengineer what is the output if you change the flags to -Crsi ?
Offline
Since one of the last linux-ck kernel releases (maybe since 4.16.8) I am not able to enter the password for my encrypted root partition correctly because some keystrokes are registered more than once.
This does not happen when I boot the default kernel.
I am building the kernel from source with native optimizations.
Any ideas what change could have introduced this issue?
Offline
I have had the same exact behavior with mine, both compiled and binary download of cpu specific kernels. I was using -ck directly from my distro's repository but in recent months it stopped. I had the same problem then and thought it was hw peculiarity.
This only happens on console though, once X goes up everything is normal. I just have to enter user and pw with really quick sharp strokes to get it right the first time.
anti-X - artix - obarun - Void - systemD Free Space
Offline
I can confirm that this goes away when X is loaded.
Offline
I installed the update 4..16-9 and it still the same. It seems as the setting of how long it lags from key-stroke before it replicates the character is set to be too sort. But this setting seems to change or be reset by X and be slightly longer. It might be as simple as 200ms to 400ms difference.
Small problem but noticeable and irritating when working on a hard to see console.
anti-X - artix - obarun - Void - systemD Free Space
Offline
Will there be any ryzen linux-ck kernel ,I have a 2600x now alway use the piledriver kernel and before that k10
Offline
@john29 - I've supported -march=znver1 for a while now...
https://wiki.archlinux.org/index.php/Un … d_packages
https://en.wikipedia.org/wiki/List_of_A … hitectures
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline