New patches have been made available for kernel 4.3: http://ck.kolivas.org/patches/4.0/4.3/4.3-ck3/ I have built a local overlay version, and it seems stable, as have others in this thread: https://forums.gentoo.org/viewtopic-t-941030-start-225.html It might be nice to get this into the tree, as Con has stated that it contains some new performance enhancements. The maintainer yngwin is on leave ATM, so perhaps someone else could pick it up temporarily? https://www.gentoo.org/inside-gentoo/developers/unavailable-developers.html Thanks Reproducible: Always
(In reply to thunderrd from comment #0) > New patches have been made available for kernel 4.3: > > http://ck.kolivas.org/patches/4.0/4.3/4.3-ck3/ > > I have built a local overlay version, and it seems stable, as have others in > this thread: > > https://forums.gentoo.org/viewtopic-t-941030-start-225.html > > It might be nice to get this into the tree, as Con has stated that it > contains some new performance enhancements. > > The maintainer yngwin is on leave ATM, so perhaps someone else could pick it > up temporarily? > https://www.gentoo.org/inside-gentoo/developers/unavailable-developers.html > > Thanks > > Reproducible: Always Hello dears, I made an ebuild for 4.3.3-r1-ck (in order to get a ck ebuild which fix CVE-2016-0728 ) Check https://forums.gentoo.org/viewtopic-t-941030-postdays-0-postorder-asc-start-250.html if you want to test it. On a side note, yngwin, I'm interested to proxy-maintain ck-sources. Would be a great learning experience for me. Kind regards, Laurent
we have 4.3.6 in the tree
Hi, I'm looking to be the maintainer of this package. I've been using the software for about a year now and it is well behind current kernel versions. I've updated most of the ebuilds locally and will look into the remaining bug listed here tonight/tomorrow. Thanks Cory Bolar cory.bolar@gmail.com
Cory, that is nice to read. Please look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers for the next steps.
A version bump would be nice. Current version in the tree is ck-sources-4.3.6.ebuild , while upstream is apparently at 4.9 http://ck.kolivas.org/patches/4.0/ .
FWIW, the hnaparst overlay is keeping current since 4.8.x, with Con's new incarnation of BFS called MuQSS. He updated to a ck-sources-4.9.2.ebuild just today. https://github.com/hnaparst/overlay
(In reply to thunderrd from comment #6) > FWIW, the hnaparst overlay is keeping current since 4.8.x, with Con's new > incarnation of BFS called MuQSS. Thanks, that works for me.
It seems that finally this became orphan again as I read in: https://github.com/gentoo/gentoo/pull/1643 CCing treecleaners as this cannot stand in this situation without any maintainer
I'm volunteering to maintain this package.
Created attachment 460584 [details] 4.9-ck1 ebuild Initial template / ebuild (attached) ^ tested locally, no obvious issues
Created attachment 460668 [details] Minor regression fix Change #1 (still present in the updated ebuild) [quote] - "Since experimental genpatches && we want BFQ irrespective of experimental" ^ Consistent with this particular comment from the ebuild, I had made a decision to switch to 5010_*.patch* (intead of a more-broad pattern 50*_*.patch* ) ... it still pulls in the appropriate "experimental" genpatch to allow BFQ to be a usable / functional scheduler choice in the resultant patched ck-sources kernel source tree; once it gets to /usr/src/ it seems to compile and even run... at least with my chosen config settings. Change #2 (regression fix) The [un]removal of K_SECURITY_UNSUPPORTED // K_DEBLOB_AVAILABLE - as per disussion on freenode IRC, those ought to have been considered a regressions issue (for the sake of compatibility) I'm about 96% certain adding back in these particular changes won't do anything different in my configuration, but I've rebuilt the kernel anyway just in case it unexpectedly changes something subtle [but important] in the kernel source tree: K_SECURITY_UNSUPPORTED="1" K_DEBLOB_AVAILABLE="1"
Created attachment 460678 [details] Cleaned up version of the ebuild I'd like to make a few clarifications here: - Beginning with 4.8, CK sources unconditionally include the BFQ: http://ck.kolivas.org/patches/4.0/4.8/4.8-ck8/patches/ The experimental genpatches 5000_* series also add support for BFQ. This introduces a collision during patching, so we mask them using 5010_* (although it's a rather poor way, since we also exclude any "potential" 5020_* etc.). - Regarding the question about K_EXP_GENPATCHES_NOUSE, gentoo-sources pull in the experimental genpatches when USE=experimental is provided. Setting this to 1 unconditionally pulls in the patchset. - Regarding K_EXP_GENPATCHES_PULL, we need this so that we can selectively apply the experimental patches. We do this by using the variable K_EXP_GENPATCHES_LIST="5010*_*.patch*". - On K_DEBLOB_AVAILABLE="1", deblob is the process of removing binary-only objects from the tree if you are not familiar with it. You can read about it more here: http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/README. I'll spin up a VM to test a build here. I think we are mostly good. I've created a cleaner version of the ebuild using yours as the basis. That's what I will be committing, let me know if you have any concerns about it.
Your new version looks like it will probably work the same as mine. Though I don't see any reason for two of the changes: -# Copyright 1999-2017 Gentoo Foundation +# Copyright 1999-2016 Gentoo Foundation -K_EXP_GENPATCHES_LIST="5010*_*.patch*" +K_EXP_GENPATCHES_LIST="5010_*.patch*" Shouldn't hurt anything though. Other than that, it looks mostly like rephrasing a comment about genpatches, and moving things (but not changing) for some layout reason, and re-inclusion of some unused="" (blank) variables which aren't doing anything. Since 100% of these the changes appear to be trivial, or for cosmetic reasons, and/or for legacy (looking like previous versions) layout purposes, I have no reason to believe this version of the ebuild will produce a different unpacked+patched kernel source tree.
Now that I think about it - I'm having a funny behavior with BFQ (CONFIG_DEFAULT_BFQ=y seems to be a placebo) for my version of the patch. I was investigating this issue today, so I probably should have a closer look to compare the differences: > K_EXP_GENPATCHES_LIST="50_*.patch*" > K_EXP_GENPATCHES_LIST="5010_*.patch*" > K_EXP_GENPATCHES_LIST="5010*_*.patch*"
Sarah, is the 'funny' behavior you are speaking of what you mentioned on IRC earlier about BFQ not becoming active on your drives even though it was selected in the .config? I saw your comments, but had no time to respond. Are you running SSDs? I do, and I had to write a small script to start BFQ on my SSDs, because it started automatically only on the mechanical drives.
commit b4a883ed61410fcdb4d846e7ec604fa8e27ef1e5 Author: Sarah White <kuzetsa@gmail.com> AuthorDate: Thu Jan 19 23:25:09 2017 -0500 Commit: Göktürk Yüksek <gokturk@gentoo.org> CommitDate: Thu Jan 19 23:55:24 2017 -0500 sys-kernel/ck-sources: bump to 9.4.9 #569262 Package-Manager: portage-2.3.0
As per #15 / @thunderrd Yes, I ran into the default behavior of SSD (set noop as IO scheduler) and assumed it was because of a misconfiguration. Embarrassing that I don't have any spinning rust to verify this only happens with SSD. The version bumps should be taken care of, and I'll keep an eye on any bugs for sys-kernel/ck-sources so this particular bug #569262 is RESOLVED / FIXED.
Good job. I'll help however I can to keep this going.