Zen-Sources: 2.6.26-rc3-zen0

Message

termite · Post by **termite** » Wed May 28, 2008 9:57 pm

the 9999 ebuild is just a stub which provides the kernel-sources virtual so that git uses dont keep getting prompted to install a kernel, it does not provide any source, you still need to clone manually

Yes, but those of us who use non-9999 builds used to get all the patches you guys put in to that particular branch, and a new ebuild whenever you released a new version. The former overwrote the old source, whereas the latter brought in a new tree. Presumably, there was some logic to when you'd move from, say, an rc3-zen1 to an rc3-zen2.

The new system doesn't seem to have any advantage over just using git and 9999, and has the new disadvantage of getting piles of duplicated source trees with only tiny differences between them.

how about we unkeyword the hotfix ebuilds so that you have to manually add ** keyword, then they wont want to get installed automatically

Better, but still not as good as the old system. If you're going to go this route, it would make sense to add explanations to each new ebuild with the changes, so that users know whether they want the update or if they should just wait for the next one. However, I'm pretty sure Portage doesn't have this mechanism built in (ie show new features of an update) though...

Sorry to be a nuisance, I just want to help

termite · Post by **termite** » Wed May 28, 2008 9:59 pm

no, we cannot just leave major versions out there, as we can't test every configuration, hence we need feedback on how the kernel is performing, specific configuration compile errors, things not working etc.

Sure, but if you add a patch and leave the version number the same, a reinstall of the same version will still get the new patch, and you'd get the same feedback. All you'd have to do is ask users to re-emerge.

This is what hotfixes are for, to not bump the version with every bug fix.

Good, so let's not bump

dodo1122 · Post by **dodo1122** » Wed May 28, 2008 10:46 pm

What do you mean? To get the new patch, which has been applied *AFTER* tagging a release would mean retagging it, and hence remaking the patch, reuploading it and would mean that we'd have to make a silent update, with many people not realising there was an update. This gives more work, and no benefits over applying the hotfix.
Sure, hotfixes in ebuilds are not perfect, that is why we are working on a better way to make hotfixes available. Although this, hotfixes are more logical than making users wait for next zen version to get a working kernel, if they do not want to use git (mind you, hotfixes are only targeted to non-git users).

dodo

termite · Post by **termite** » Wed May 28, 2008 10:53 pm

To get the new patch, which has been applied *AFTER* tagging a release would mean retagging it, and hence remaking the patch, reuploading it and would mean that we'd have to make a silent update

Yes.

with many people not realising there was an update

Yes, but if you're uploading a specific patch to fix a specific problem, presumably that problem was brought up by a user, who could then be told to re-emerge and re-test.

no benefits over applying the hotfix

The benefit would be that there wouldn't be an entire new source tree pulled and installed, thus avoiding duplication of an entire tree (ie about ~250mb of diskspace) for a tiny change.

dodo1122 · Post by **dodo1122** » Wed May 28, 2008 10:59 pm

Hence i said we are working on a better method. Also the hotfix ebuilds will be unkeyworded, solving the problem for forced updates. If a person does not want the old tree, nothing hard in running emerge -P zen-sources or paludis -u '=sys-kernel/zen-sources-blah' . The 'better method' would be a script which would download the hotfix, and apply it to an existing tree.

dodo

termite · Post by **termite** » Wed May 28, 2008 11:02 pm

OK, that's better, I suppose.

Just out of curiosity, what form do you see the script taking? Something that all zen-sources users have and just run when they need to or something somehow tied into Portage?

dodo1122 · Post by **dodo1122** » Wed May 28, 2008 11:04 pm

It won't be portage-dependent. The idea is that users from all distros could use it.

dodo

termite · Post by **termite** » Wed May 28, 2008 11:11 pm

all distros

You mean something other than Gentoo is important!??!

rmh3093 · Post by **rmh3093** » Wed May 28, 2008 11:16 pm

termite wrote:
the 9999 ebuild is just a stub which provides the kernel-sources virtual so that git uses dont keep getting prompted to install a kernel, it does not provide any source, you still need to clone manually
Yes, but those of us who use non-9999 builds used to get all the patches you guys put in to that particular branch, and a new ebuild whenever you released a new version. The former overwrote the old source, whereas the latter brought in a new tree. Presumably, there was some logic to when you'd move from, say, an rc3-zen1 to an rc3-zen2.

The new system doesn't seem to have any advantage over just using git and 9999, and has the new disadvantage of getting piles of duplicated source trees with only tiny differences between them.
how about we unkeyword the hotfix ebuilds so that you have to manually add ** keyword, then they wont want to get installed automatically
Better, but still not as good as the old system. If you're going to go this route, it would make sense to add explanations to each new ebuild with the changes, so that users know whether they want the update or if they should just wait for the next one. However, I'm pretty sure Portage doesn't have this mechanism built in (ie show new features of an update) though...

Sorry to be a nuisance, I just want to help

you are comparing apples and oranges here... when the kernel was in the OLD repo the eclass for the 9999 ebuild pulled from git and yes it overwrote the old dir.... having a git ebuild was a waste of time, just use git manually

.... as for the non-git ebuilds, some people dont want the existing trees overwritten because if the kernel fails for some reason they dont have to re-emerge anything, just adjust the symlink to /usr/src/linux

if you dont like many kernel trees in your src dir then run 'emerge -P zen-sources' after you update

termite · Post by **termite** » Wed May 28, 2008 11:34 pm

as for the non-git ebuilds, some people dont want the existing trees overwritten because if the kernel fails for some reason they dont have to re-emerge anything, just adjust the symlink to /usr/src/linux

Yes, but since hotfixes are tiny, surely it would just be easier to reverse the patch? I think maybe this should be part of the functionality of the new script dodo is talking about.

if you dont like many kernel trees in your src dir then run 'emerge -P zen-sources' after you update

Not practical, imo, since it often takes some time to figure out whether a new version is better or worse than the old one, so I don't want to immediately unmerge the old version(s). Right now, I keep a 2.6.25 around as well as the new 26 rc's. All I'm saying is that there's no need for massive duplication for a two-line code change in one out of 100,000 files.

Anyway, I think this proposed script could solve a lot of these issues.

rmh3093 · Post by **rmh3093** » Thu May 29, 2008 12:20 am

termite wrote:
as for the non-git ebuilds, some people dont want the existing trees overwritten because if the kernel fails for some reason they dont have to re-emerge anything, just adjust the symlink to /usr/src/linux
Yes, but since hotfixes are tiny, surely it would just be easier to reverse the patch? I think maybe this should be part of the functionality of the new script dodo is talking about.
if you dont like many kernel trees in your src dir then run 'emerge -P zen-sources' after you update
Not practical, imo, since it often takes some time to figure out whether a new version is better or worse than the old one, so I don't want to immediately unmerge the old version(s). Right now, I keep a 2.6.25 around as well as the new 26 rc's. All I'm saying is that there's no need for massive duplication for a two-line code change in one out of 100,000 files.

Anyway, I think this proposed script could solve a lot of these issues.

you are only supposed to emerge a hotfix version if the fix is for something you are experiencing a problem with... the easy solution is DONT update when not needed

dodo1122 · Post by **dodo1122** » Thu May 29, 2008 12:46 am

I would also like to inform zen users with nvidia cards that the latest driver (173.14.05) along with a patch to make it work with 2.6.26-rc kernels is in zen-overlay

dodo

termite · Post by **termite** » Thu May 29, 2008 2:05 am

you are only supposed to emerge a hotfix version if the fix is for something you are experiencing a problem with... the easy solution is DONT update when not needed

Yep, so de-keywording stuff should be fine

mroconnor · Post by **mroconnor** » Thu May 29, 2008 2:16 pm

I am just catching up on the thread. A few things:

Code: Select all

Linux cosmo 2.6.26-rc4-zen1 #23 SMP PREEMPT Thu May 29 00:17:17 EDT 2008 x86_64 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux

seems to be working just fine

Secondly, being a git only user the new hotfix system doesnt seem troubling to me, but maybe I'll try the ebuild just to see what everyone is talking about. But the theory sounds on target, if you dont need the specific hotfix then dont emerge it.

rmh3093 · Post by **rmh3093** » Thu May 29, 2008 2:26 pm

To be honest, I was 100% against this whole hotfix idea... I rather let a bunch of fixes pile up and then bump the version or the fixes could wait for some big changes and get included in the next version bump. I best option is using git manually. Because then you can use git-bisect to actually track down your bug....

mroconnor · Post by **mroconnor** » Thu May 29, 2008 2:32 pm

Im still getting comfortable with git....it is amazingly complex.

This system is similar in theory to how my Oracle linux servers can be kernel patched. If I have a kernel issue that is related to me specifically Oracle will create a patch for me BUT if it helps many users they will push into the main kernel for all to download.

rmh3093 · Post by **rmh3093** » Thu May 29, 2008 3:15 pm

mroconnor wrote:Im still getting comfortable with git....it is amazingly complex.

This system is similar in theory to how my Oracle linux servers can be kernel patched. If I have a kernel issue that is related to me specifically Oracle will create a patch for me BUT if it helps many users they will push into the main kernel for all to download.

we hardly even use the complex aspects of git, you non-zen-devs dont basically dont do anything you couldnt do with cvs or svn, they all had branches and what not... but you all probably didnt play with branches much with other version control systems... I will admit that git does come with a few gotcha's for unexperienced users, the key is to learn the 3-fixes

mroconnor · Post by **mroconnor** » Thu May 29, 2008 3:40 pm

Yeah, I realized unless you are maintaining a repo you really only need to know how to fix your local when you bork it. I was thinking of setting something up here just to learn and maybe use for document management or something.

I made a script of the 2 fixes, because I find myself using it so frequently. LOL

termite · Post by **termite** » Thu May 29, 2008 3:52 pm

I'm too lazy to bother with git, honestly

Seriously, though, I like all my software managed through a single system, and Portage does a fine job for my needs. I think the de-keywording of hotfix releases is fine.

One small quibble: The major release (in this case zen-sources-2.6.26_rc4-r10) should be keyworded, imo. Otherwise, a ** entry for zen-sources will just get the latest, whereas an ~arch keyword will lag behind in major releases...

mroconnor · Post by **mroconnor** » Thu May 29, 2008 4:00 pm

I agree with you about the single system to manage everything. But I became such git-pull junky to see when the devs put something new out there it wasn't funny.

/me pokes dodo for HDAPS support

dodo1122 · Post by **dodo1122** » Thu May 29, 2008 6:48 pm

Patience

Right now i'm hacking up a program to apply hotfixes to kernel dir. We have a script done already, and although it works ( but is very hackish), it won't really do. When i have it ready, i'll add it to our overlay.

And as to HDAPS, well, I'll try my best

dodo

mroconnor · Post by **mroconnor** » Thu May 29, 2008 8:07 pm

no worries mate, I'll just git-pull, compile and reboot until I see no dodgy HDAPS messages. LOL

rmh3093 · Post by **rmh3093** » Thu May 29, 2008 10:45 pm

mroconnor wrote:no worries mate, I'll just git-pull, compile and reboot until I see no dodgy HDAPS messages. LOL

i wouldnt hold your breath for HDAPS, the block/freeze/protect patch is SO outdated, i dont think any of us know enough about it do fix it (or have the desire to learn)

i'd rather spend my time working on a gallium3d driver for r500 cards, or port SD to 2.6.26

HecHacker1 · Post by **HecHacker1** » Fri May 30, 2008 3:58 am

rmh3093 wrote:
HecHacker1 wrote:
dodo1122 wrote:Ermm, zen has stable patches from ext4-patch-queue. I also think we have delalloc/mballoc support.

dodo
the mount option delalloc does not exist, so i guess this kernel doesn't have the ext4 git patches.

i'm back to 2.6.25 zen because i need vmware.

this page mentions it, but in another language:
http://209.85.141.104/search?q=cache:YL ... cd=1&gl=us
i doubt you will see those patches in zen anymore till they get to stable, i think its pretty stupid for anyone to run unstable filesystems, unstable anything else im all for, but unstable fs's just cause headaches

agreed in general. but it is actually mostly stable now, ibm wrote a white-page about using ext4 and didn't really mention it was all that dangerous
http://www.ibm.com/developerworks/linux/library/l-ext4/

its also in fedora, marked as 100% complete.
http://fedoraproject.org/wiki/Features/Ext4

and performs better than ext3. The ext4 in the kernel has mballoc support, but not delalloc which was removed. Delalloc was removed because it is being moved into the linux vfs layer where it could be used by all filesystems (lkml has discussion about it).

Anyways... ext4 was ok, but not that much better than reiserfs (mballoc helped lessen disk activity, and is enabled by default). I went back to reiser4 with compression because its just so much faster and stable.

What is the future of reiser4? Will it be maintained? Ever integrated into the kernel?

Last time I checked Hans was fighting with Linus over coding styles... but since Hans isn't maintaining this code anymore?

rmh3093 · Post by **rmh3093** » Fri May 30, 2008 5:29 am

HecHacker1 wrote:
rmh3093 wrote:
HecHacker1 wrote:
dodo1122 wrote:Ermm, zen has stable patches from ext4-patch-queue. I also think we have delalloc/mballoc support.

dodo
the mount option delalloc does not exist, so i guess this kernel doesn't have the ext4 git patches.

i'm back to 2.6.25 zen because i need vmware.

this page mentions it, but in another language:
http://209.85.141.104/search?q=cache:YL ... cd=1&gl=us
i doubt you will see those patches in zen anymore till they get to stable, i think its pretty stupid for anyone to run unstable filesystems, unstable anything else im all for, but unstable fs's just cause headaches
agreed in general. but it is actually mostly stable now, ibm wrote a white-page about using ext4 and didn't really mention it was all that dangerous
http://www.ibm.com/developerworks/linux/library/l-ext4/

its also in fedora, marked as 100% complete.
http://fedoraproject.org/wiki/Features/Ext4

and performs better than ext3. The ext4 in the kernel has mballoc support, but not delalloc which was removed. Delalloc was removed because it is being moved into the linux vfs layer where it could be used by all filesystems (lkml has discussion about it).

Anyways... ext4 was ok, but not that much better than reiserfs (mballoc helped lessen disk activity, and is enabled by default). I went back to reiser4 with compression because its just so much faster and stable.

What is the future of reiser4? Will it be maintained? Ever integrated into the kernel?

Last time I checked Hans was fighting with Linus over coding styles... but since Hans isn't maintaining this code anymore?

well im just not crazy about applying filesystem patches, if they dont apply 100% perfect, i cant be sure if the issue was intrinsic to the code, or was a result of a mistake in me fixing conflicts or failed hunks, if the vanilla version of ext4 works fine use it, but i dont think pulling from the ext4-patch-queue git repo is a good idea

reiser4 is in the current zen kernel and seems stable.. i made a loopback image and copied some shit to it and didnt have any issues, others have tried it out and havent had issues... i dont know whats its future is, as long as someone is maintaining patches I will keep applying patches

.... my money is on btrfs though, oracle aint going anywhere, i need to send my laptop to Acer to get some dead pixels fixed (aka LCD replacement) when I get it back I was thinking about using btrfs as my rootfs, right now i just have some media stored on my btrfs partition, havent done any tests on it, but the data is all there and hasent gotten corrupted yet