reiser4progs-1.0.4 will not work with libaal-1.0.5 , it needs DEPEND=">=sys-libs/libaal-${PV} to be changed . Suggest: DEPEND="=sys-libs/libaal-${PV}* Reproducible: Always Steps to Reproduce: 1.unmask and emerge reiser4progs-1.0.5 (brings in libaal ${PV}) 2.change your mind , revert to 1.0.4 3.mkfs.reiser4 /dev/..... 4 mount /dev/..... fails Actual Results: downgrading R4 to 1.0.4 will not force a UD for libaal but it must since the version mix fails to work. Expected Results: ebuild should ensure correct version of dependant libs. marked this a critical since fsck suggests the fs has errors and prompts for using -build-fs this would presumably destroy data on a populated fs.
appears that reverting libaal is necessary but not sufficient to fix this condition. I did libaal then rebuild R4progs and it the prob was identical. I have now solved this by pulling v1.1 of the R4 1.0.4 ebuild off CVS. This seems very bad that ebuilds going under the same version number do not rebuild working software.
*** Bug 109320 has been marked as a duplicate of this bug. ***
fixed in 1.0.5
>>fixed in 1.0.5 cool, so it just needs fixing in 1.0.4 ;) that was the bug I posted, not 1.0.5 committing a trivial mod like that must be very little effort in relation to the hours of agravation that this tiny error caused . 1.0.4 is still in portage so I see no reason to leave a known bug in the ebuilds.
actually 1.0.4 isnt in portage anymore, your tree is out of date
LOL. perhaps "fixed in 1.0.5" meant "I just fixed it in 1.0.5 and 1.0.4 has just been removed, please sync". I did sync just before posting but only a few hours after the changes to CVS it it apparently had not propagated to the mirrors. It seems from cvs that that 1.0.4 is still there as 1.0.4_p1 and that this does also carry the fix. Thanks for tidying this up. One thing to note about this sort of versioning : I put a block on >package_name .1.0.4* in package.mask and this effectivly masks 1.0.4_p1 which it seems is the latest (and now only) 1.0.4* ebuild.
which is correct behavior 1.0.4_p1 means patchlevel 1 over 1.0.4 you should go with something like '<package_name-1.0.5'
Thanks for the explaination on that , I'll bear it in mind in the future. As it seems we are being pushed towards 1.0.5 , it that version suitable for use with kernels built with 1.0.4 or should I prefere p1? I have existing partitions using 1.0.4 and wish new partitions to work with 1.0. 4-based kernels. TIA.
i have no idea reiser4 is unsupported
>>i have no idea that may explain of few of the issues I am having. On what information are you acting in modifying the ebuilds and chosing what versions to remove or retain in the tree? regards.
i punt older versions after a certain amount of time if you have bugs, talk to the reiser4 people
I have no bugs with reiser4 it has worked brillantly since I installed it 18mth ago. I _do_ now have a broken portage tree and yet another packed locked in package. mask and an ebuild in overlay. 1.0.4 has worked fine with my 2.6.11 kernel since I installed it until last week when I rebuilt what I believed to be the same version : 1.0.4 . Changes made to the ebuild broke file system software. That is not an R4 bug it is a Gentoo portage bug. A careless one. The patch that was added in version 1.5 of reiser4prog-1.0.4 is the culprit. That would have been best left for _p1 and not have been applied to 1.0.4 2.6.11 vintage kernels can hardly be regarded as an old or depreciated so "punting" 1.0.4 seems premature to say the least. It is sufficent to compare the times of the posts in this thread to the time revision 1.8 marks its removal in CVS to see that it was "punted" off instead of fixing this issue. If that is called RESOLVED FIXED ... fine.
