I agree and must acknowledge that 25% of the reasons of the silence is on my full and entire responsibility.
Don't ask me to distribute the 75 other %, to each is own!

thunderrd wrote:

I saw the problems in Bug #479382, and am thinking maybe you have had enough proxy maintaining

Not really. The idea of proxy maintaining perfectly fits my purpose.
When there is a will, there is a way. And I think that until the Bug you mention, we have both (proxy-maintainers and I) fruitfully managed to find one.
I must acknowledge with Bug #479382 a lack of good will from my own side.
Several reasons triggered it: the poor performances of 3.9, 3.10 kernels is one of them, the nvidia mess is another one, "upstream" reactivity a third, ... a fourth...
In such conditions, v.g : I am not myself convinced that the final result is worth it, I admit that fighting / arguing with the proxy-maintainers about a silly-stupid-trivial patch is well above my forces.

thunderrd wrote:

I, for one, appreciate all that you have done, Eric. Thank you.

Thank you for saying this.
But... be aware that... I am for absolutely nothing in the actually best performing ck-sources kernel release available in portage, hmmm... the best performing kernel release available in portage!

OK, then, practically :
- I'll push an unpatched 3.9-r1 that should close Bug #479382 during week 47
- I'll push a 3.4.68 with an amount of patches I hope acceptable by the proxy-maintainers during week 47. (I like the 3.4 series and gentoo is the only distribution offering high releases ck-patched kernels)
- I expect being capable to push 3.10 and 3.11 during week 48.

If, in the future, it occurs that, as I expect, I feel unable to produce acceptable releases of ck-patched kernels without extra patches that do not meet proxy-devs' standards, I'll require a slot to be opened in gentoo-sunrise.

Thank you, thunderrd, for your support._________________

Last edited by aCOSwt on Sun Nov 10, 2013 10:50 pm; edited 2 times in total

- I'll push an unpatched 3.9-r1 that should close Bug #479382 during week 47

That is four months old by now, EOL and insecure; is this still worth pursuing?

aCOSwt wrote:

- I'll push a 3.4.68 with an amount of patches I hope acceptable by the proxy-maintainers during week 47. (I like the 3.4 series and gentoo is the only distribution offering high releases ck-patched kernels)

Definitely worth it for people hit by the changes in the later kernels.

aCOSwt wrote:

- I expect being capable to push 3.10 and 3.11 during week 48.

Sounds good; please note that I have made a forward ported patch for 3.12 some time ago if we want to add more support, I'll probably test this patch more thoroughly soon.

aCOSwt wrote:

If, in the future, it occurs that, as I expect, I feel unable to produce acceptable releases of ck-patched kernels without extra patches that do not meet proxy-devs' standards

Feel free to explain why these patches are needed and I'll look into it.

- I'll push an unpatched 3.9-r1 that should close Bug #479382 during week 47

That is four months old by now, EOL and insecure; is this still worth pursuing?

It's not me who wrote

Quote:

# For proprietary NVIDIA drivers users, we temporarily keep 3.9.11-r1 around
# as some of them experience problems with the new stable kernel 3.10.7;

But... I... quite agree with that.
In addition, some user of the ck-sources reported here a problem with the 3.9 solved in 3.9-r1. I believe I owe him some solution.

BTW : I do not quite like the fiddlings you achieved in the kernel2 eclass, generalizing to a particular purpose the experimental use flag already used by the ck-sources for other purposes.
Of course this is only my opinion as far as I am concerned.
Nevermind anyway.

However, I do not know how you expect the following snippet of code to be working

I do not like it as well as it prevents the K_EXP_GENPATCHES_LIST from being initialized similarly to other lists of the kind (UNIPATCH_EXCLUDE)
But... nevermind once again, let's go for having K_EXP_GENPATCHES_LIST="50*_*.patch*" literally._________________

# For proprietary NVIDIA drivers users, we temporarily keep 3.9.11-r1 around
# as some of them experience problems with the new stable kernel 3.10.7;

But... I... quite agree with that.

Well, yeah, I think we're quite close to dropping that.

aCOSwt wrote:

In addition, some user of the ck-sources reported here a problem with the 3.9 solved in 3.9-r1. I believe I owe him some solution.

True, but an overlay / local ebuild might fit the purpose better; and isn't this something that can be forward ported? If you really want it, go ahead, alternative kernel sources aren't considered supported by Gentoo Security; it is just a suggestion to avoid affecting users and/or receiving blame.

aCOSwt wrote:

BTW : I do not quite like the fiddlings you achieved in the kernel2 eclass, generalizing to a particular purpose the experimental use flag already used by the ck-sources for other purposes.

You can keep experimental out of K_WANT_GENPATCHES and set K_EXP_GENPATCHES_NOUSE if you don't want the experimental USE flag.

And when you want to instead define your own USE flag gentoo-experimental you can have it set K_EXP_GENPATCHES_LIST="*" when calling the unpack function; note that you need to set K_EXP_GENPATCHES_PULL or override SRC_URI if you do so, because due to Portage's limitations we can't export a variable to control the USE flag name.

aCOSwt wrote:

However, I do not know how you expect the following snippet of code to be working

I do not like it as well as it prevents the K_EXP_GENPATCHES_LIST from being initialized similarly to other lists of the kind (UNIPATCH_EXCLUDE)
But... nevermind once again, let's go for having K_EXP_GENPATCHES_LIST="50*_*.patch*" literally.

Since K_EXP_GENPATCHES_LIST works only on 50*_*.patch*; you can just use * instead, I have tested a lot of stuff (things similar to this as well) before pushing this and it all worked. I don't see what does not work in that piece of code...

BTW : I do not quite like the fiddlings you achieved in the kernel2 eclass, generalizing to a particular purpose the experimental use flag already used by the ck-sources for other purposes.

You can keep experimental out of K_WANT_GENPATCHES and set K_EXP_GENPATCHES_NOUSE if you don't want the experimental USE flag.

I understand that but if you want the genpatches experimental tarball and have the ck-sourcesexperimental use flag set, the kernel2 eclass will interpret this use flag as linked with the genpatches experimental patches.

TomWij wrote:

aCOSwt wrote:

However, I do not know how you expect the following snippet of code to be working

I do not like it as well as it prevents the K_EXP_GENPATCHES_LIST from being initialized similarly to other lists of the kind (UNIPATCH_EXCLUDE)
But... nevermind once again, let's go for having K_EXP_GENPATCHES_LIST="50*_*.patch*" literally.

Since K_EXP_GENPATCHES_LIST works only on 50*_*.patch*; you can just use * instead, I have tested a lot of stuff (things similar to this as well) before pushing this and it all worked. I don't see what does not work in that piece of code...

Well, having K_EXP_GENPATCHES_LIST initialized the way I (&& hardened) would initialize UNIPATCH_EXCLUDE, I mean, something of the kind

BTW : I do not quite like the fiddlings you achieved in the kernel2 eclass, generalizing to a particular purpose the experimental use flag already used by the ck-sources for other purposes.

You can keep experimental out of K_WANT_GENPATCHES and set K_EXP_GENPATCHES_NOUSE if you don't want the experimental USE flag.

I understand that but if you want the genpatches experimental tarball and have the ck-sourcesexperimental use flag set, the kernel2 eclass will interpret this use flag as linked with the genpatches experimental patches.

All its occurences are guarded by -z ${K_EXP_GENPATCHES_NOUSE} which means that the USE flag is only checked if you not set that; thus, if you set it, the eclass won't check the USE flag.

aCOSwt wrote:

TomWij wrote:

aCOSwt wrote:

However, I do not know how you expect the following snippet of code to be working

I do not like it as well as it prevents the K_EXP_GENPATCHES_LIST from being initialized similarly to other lists of the kind (UNIPATCH_EXCLUDE)
But... nevermind once again, let's go for having K_EXP_GENPATCHES_LIST="50*_*.patch*" literally.

Since K_EXP_GENPATCHES_LIST works only on 50*_*.patch*; you can just use * instead, I have tested a lot of stuff (things similar to this as well) before pushing this and it all worked. I don't see what does not work in that piece of code...

Well, having K_EXP_GENPATCHES_LIST initialized the way I (&& hardened) would initialize UNIPATCH_EXCLUDE, I mean, something of the kind

- And I forgot telling that from 3.8, following a discussion I had with him on IRC, Con removed from the ck-patchset a couple of patches aiming at reducing the apparent IO throughput, in particular through extremely low settings of the dirty ratios.
These ratios are now back to default, which means that IO-bound tasks are now CPU-bound for much longer than usual.
This may well explain why some of you might well, since 3.8, feel their system less interactive during heavy disk write operations.

Following BUG 492966, and thanks to Tom Wijsman the ck-sources tree has been updated.

3.11 users should upgrade to 3.11.10,
3.12 users should upgrade to 3.12.2

Note about 3.12.2 : ck-patched kernels have always been concerned with random suspend/resume issues.
This is even more true since 3.9 and the "dramatic CPU offline code changes to mainline"
Con tried to address these issues with several patches, among which the bfs443-hibernate_test2.patch.

The idea grounding this patch is affining tasks to CPU0 as CPUs go offline.

The experimental use flag is back in the ck-sources together with a new use flag named hibernate.
emerging the ck-sources-3.12.2 with both use flags set will apply the above patch to bfs.

OK, OK... I know... BFS-444 is out today... this making my initiative... obsolete!
But... 444 was not even planned when I posted my bump request last week.
I should push it as part of 3.12.3_________________

Following BUG 502442, and thanks to Tom Wijsman, the ck-sources tree has been updated.

3.4 users should upgrade to 3.4.82,

Be aware that a new custom patch is being applied with this release.
Without it, the build of the kernel would fail because of an unresolved reference.
Since 3.4.81, linux defines a new function which is of absolutely no use to bfs.
(It does not concern security either, it is nothing but yet another pathetic try for the cfs to catch some idea of the cpu load when working tickless)
However, this function is declared external in the sched.h header used by bfs.
=> The trivial patch simply adds a void definition of that function in the rightly named compatibility crap section of the bfs.c code._________________

Following BUG 503142, and thanks to Tom Wijsman, the ck-sources tree has been updated.

3.10 users should upgrade to 3.10.32,
3.12 users should upgrade to 3.12.13,

Be aware that the 3.12 branch shows a regression in the handling of usbatm debug traces, so those who get CONFIG_USB_ATM are concerned.

3.13.5 was also made available.

Be aware that, despite a relatively high release number, 3.13.5 is an early release of the ck-sources => It is likely to show a couple of problems.
In particular the fact that it breaks kvm seems confirmed.

kernelOfTruth wrote:

@aCOSwt:don't be so hard on yourself

I first tried to be hard on others... it does not work well either... _________________

Last edited by aCOSwt on Fri May 09, 2014 9:27 pm; edited 1 time in total

Be aware of that, you also helped me solve a couple of issues on a laptop I am testing things currently. For whatever reason, X did not want to see the device it should have been using with the i915-driver, while vesa worked. I had also some trouble getting terminal emulators to work.

Yes, both were something something /dev something related issues, but I had no real clues where to look at, or what. This is no surprise, because, before someone screams udev, I'll just say:

static-dev

Lo, and behold, everything just worked with the new(er) kernel. It's embarrassingly a case of not sure what I did, but that fixed it!

Being said that I am working on updates but was more targetting a 3.14.5 than a 3.14.4, I am interested to know more about your reasons for this. Security fix ? Any particular driver / feature bug fix ? As well as the level of urgency. Depending on that, I could be able to suggest a temporary workaround._________________

WARN: postinst
ck-sources is UNSUPPORTED by Gentoo Security.
This means that it is likely to be vulnerable to recent security issues.

It is the very first time I get a bump request for security fixes.

Nevermind. I won't refuse helping a Perfect Gentelman having apparently registred here in the first intention to get the best *-sources money can't buy.
(Even if 3.14.4 is... actually not the best release!... yet!)

Will do the necessary testings tonight and post the ebuild(s) tomorrow._________________