| View previous topic :: View next topic |
| Author |
Message |
termite
Guru
Joined: 06 May 2007
Posts: 466
|
 Posted: Wed May 28, 2008 9:57 pm Post subject: |
 |
|
| Quote: | | 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.
| Quote: | | 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  |
|
| Back to top |
|
 |
termite
Guru
Joined: 06 May 2007
Posts: 466
|
| Posted: Wed May 28, 2008 9:59 pm Post subject: |
|
|
| Quote: | | 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.
| Quote: | | This is what hotfixes are for, to not bump the version with every bug fix. |
Good, so let's not bump |
|
| Back to top |
|
|
dodo1122
Guru
Joined: 02 Sep 2006
Posts: 347
Location: York, England
|
| Posted: Wed May 28, 2008 10:46 pm Post subject: |
|
|
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
_________________
#zen-sources on irc.rizon.net |
|
| Back to top |
|
|
termite
Guru
Joined: 06 May 2007
Posts: 466
|
| Posted: Wed May 28, 2008 10:53 pm Post subject: |
|
|
| Quote: | | 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.
| Quote: | | 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.
| Quote: | | 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. |
|
| Back to top |
|
|
dodo1122
Guru
Joined: 02 Sep 2006
Posts: 347
Location: York, England
|
| Posted: Wed May 28, 2008 10:59 pm Post subject: |
|
|
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
_________________
#zen-sources on irc.rizon.net |
|
| Back to top |
|
|
termite
Guru
Joined: 06 May 2007
Posts: 466
|
| Posted: Wed May 28, 2008 11:02 pm Post subject: |
|
|
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? |
|
| Back to top |
|
|
dodo1122
Guru
Joined: 02 Sep 2006
Posts: 347
Location: York, England
|
| Posted: Wed May 28, 2008 11:04 pm Post subject: |
|
|
It won't be portage-dependent. The idea is that users from all distros could use it.
dodo
_________________
#zen-sources on irc.rizon.net |
|
| Back to top |
|
|
termite
Guru
Joined: 06 May 2007
Posts: 466
|
| Posted: Wed May 28, 2008 11:11 pm Post subject: |
|
|
You mean something other than Gentoo is important!??!  |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Wed May 28, 2008 11:16 pm Post subject: |
|
|
| termite wrote: | | Quote: | | 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.
| Quote: | | 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
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
termite
Guru
Joined: 06 May 2007
Posts: 466
|
| Posted: Wed May 28, 2008 11:34 pm Post subject: |
|
|
| Quote: | | 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.
| Quote: | | 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. |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Thu May 29, 2008 12:20 am Post subject: |
|
|
| termite wrote: | | Quote: | | 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.
| Quote: | | 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
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
dodo1122
Guru
Joined: 02 Sep 2006
Posts: 347
Location: York, England
|
| Posted: Thu May 29, 2008 12:46 am Post subject: |
|
|
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
_________________
#zen-sources on irc.rizon.net |
|
| Back to top |
|
|
termite
Guru
Joined: 06 May 2007
Posts: 466
|
| Posted: Thu May 29, 2008 2:05 am Post subject: |
|
|
| Quote: | | 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 |
|
| Back to top |
|
|
mroconnor
Guru
Joined: 24 Feb 2006
Posts: 402
Location: USA
|
| Posted: Thu May 29, 2008 2:16 pm Post subject: |
|
|
I am just catching up on the thread. A few things:
| Code: | | 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. |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Thu May 29, 2008 2:26 pm Post subject: |
|
|
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....
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
mroconnor
Guru
Joined: 24 Feb 2006
Posts: 402
Location: USA
|
| Posted: Thu May 29, 2008 2:32 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Thu May 29, 2008 3:15 pm Post subject: |
|
|
| 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
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
mroconnor
Guru
Joined: 24 Feb 2006
Posts: 402
Location: USA
|
| Posted: Thu May 29, 2008 3:40 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
termite
Guru
Joined: 06 May 2007
Posts: 466
|
| Posted: Thu May 29, 2008 3:52 pm Post subject: |
|
|
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... |
|
| Back to top |
|
|
mroconnor
Guru
Joined: 24 Feb 2006
Posts: 402
Location: USA
|
| Posted: Thu May 29, 2008 4:00 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
dodo1122
Guru
Joined: 02 Sep 2006
Posts: 347
Location: York, England
|
| Posted: Thu May 29, 2008 6:48 pm Post subject: |
|
|
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
_________________
#zen-sources on irc.rizon.net |
|
| Back to top |
|
|
mroconnor
Guru
Joined: 24 Feb 2006
Posts: 402
Location: USA
|
| Posted: Thu May 29, 2008 8:07 pm Post subject: |
|
|
| no worries mate, I'll just git-pull, compile and reboot until I see no dodgy HDAPS messages. LOL |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Thu May 29, 2008 10:45 pm Post subject: |
|
|
| 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
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
HecHacker1
Apprentice
Joined: 26 Jun 2003
Posts: 213
Location: UCSD
|
| Posted: Fri May 30, 2008 3:58 am Post subject: |
|
|
| rmh3093 wrote: |
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? |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Fri May 30, 2008 5:29 am Post subject: |
|
|
| HecHacker1 wrote: | | rmh3093 wrote: |
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
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Unsupported Software
