Re: [gentoo-portage-dev] .53, .54 and beyond...
Jason Stubbs wrote: On Saturday 26 November 2005 11:07, Marius Mauch wrote: On Sat, 26 Nov 2005 00:01:15 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: The only other new thing in trunk that I know of is logging but there's still a question mark over the ordering of messages... Can that be resolved soon? Anything else missing? Any reasons against any of the above? Resolved how? I'm not really sure I understood the original problem (other than listdir being underdeterministic in theory). TGL suggested that all the messages go into a single file with some sort of prefix that would then be parsed on the python side. The original order of messages could then be maintained. However, seeing as there needs to be no compatibility with the temporary files it could wait for later anyway. a) haven't seen a patch for it, so no clue about how complex it is code wise and b) I generally dislike any markup/parsing in the temporary files. I'd rather get it out as-is now and incorporate any feedback later. As you said this interface doesn't have to be compatible, also I intended to add a general might change-note for elog in the release notes. - the pycrypto hash additions (for .54) This is only useful if the vote goes in favour of adding further hash types to Manfiest, right? If the vote goes that way I've got no issues with it, but if it doesn't it would essentially be dead code. Well, the vote was more for the SHA1 change actually as that's the one triggering the size increase. The pycrypto stuff itself doesn't do anything really, it would just make the size increase more apparent. - Killing off auto-use+USE_ORDER? Yep, I'd really like to see this one gone too. We should probably state the intention on -dev first though as there might be a lot of people against it. Well, Spanky liked the suggestion ;) - the recursive grab* functions I just posted (for .54) Needs a small amount of work (/etc/portage/package.mask/foo/bar would break it) but I like the general idea. How would it break? - integration of set modules, either as emerge targets (requires serious gutting of emerge) or a first-class atoms (semantically tricky, no clue about implementation yet) I'm working on this with my refactoring. Defininately a post-.54 thing unless you want to quickly hack it into getlist()? Don't think so given that offhand I don't even know what getlist() does ... Oh, btw, two things that are in trunk but weren't listed in your original mail: - the rewritten versioning code (including the cvs and mult-suffix enhancements) - finally killing of the stupid masked by -* message Marius -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Sat, 2005-11-26 at 13:15 +0900, Jason Stubbs wrote:
On Saturday 26 November 2005 02:05, Ned Ludd wrote:
On Sat, 2005-11-26 at 00:51 +0900, Jason Stubbs wrote:
On Saturday 26 November 2005 00:31, Ned Ludd wrote:
* post_sync action hook (.53/.54 )
* VDB prevention of single byte NULL entries being created. ( .54 )
Doable for .54.
Yeah and from the sounds of it we may want more than 1 set of postsync
hooks or the addition of a postsync.d/
(dev thread on getting vital info to users)
Heh.. that was my suggestion. ;)
Yeah it seems doable for .53 but if you want to wait till .54 or
a .53-rXX thats fine. I'd prefer to see it in .53 unless
that's going out the door today.
* new prepstrip offering splitdebug ( .53/.54 )
Need to work out exactly what will be offered when on this one, but at
the earliest it will be .54. Perhaps go with your patch for .54 and leave
Olivier's fancy bits for later?
I can only assure you the code I wrote will function properly.
So that's the only thing I'm trying/willing to push myself.
As long as he has those [ -x checks ] his code should be harmless,
but I don't see the advantage in it over building with -g3.
There are a few other questions too... Should
the default be to generate external debug info?
I think the security team would say yes they want it by default and
would be willing (taviso) to write a proper debug-HOWTO.xml for gentoo.
I think ferringb would say make it FEATURES=splitdebug if
it's going in midstream.
It does add some size which would make peoples $ROOT's a little bit
bigger. But from mine and other peoples testing it's pretty damn
minimal. I think Halcy0n @ gentoo said after doing an -e world he ended
up with only 18M of split debug info
I'm also fond of split packaging of debug info also (but I'm not going
to push for that till I find a more elegant way)
[EMAIL PROTECTED] debug $ qsize pax-utils
app-misc/pax-utils-debug-0.1.4-r0: 3 files, 5 non-files, 16.27 KB
app-misc/pax-utils-0.1.4: 6 files, 6 non-files, 102.485 KB
Perhaps we should get input from gentoo-dev ml ?
Sounds good for pretty much all aspects of split debug (other than the
capability itself).
Should generating internal
debug info still be offered?
When FEATURES=nostrip is enabled we should not split off
any debug info or touch the executable.
FEATURES=splitdebug|stripdebug and do nothing if neither is set?
If feature based it seems logical to me to have it as either
splitdebug || nosplitdebug
I know some people hate no* functions or rather they hate no* USE
flags. But it would seem fitting if we decided to make it a default vs
sticking in splitdebug in all profiles.
The feeling I get in general is that some devs want it by default to
make helping users who don't really know how to debug give us the info
we need without much hassles.
stripdebug I'm not sure what you envision with that name.
* flattened vdb {P,R,}DEPEND (.54 )
I might be wrong but I can't really see this being done cleanly. At best,
only USE flags could be gotten rid of which would still leave || ()
constructs. This leads me to question of what use it would really be. If
it can only do a half-arsed job and in a messy way at that I'd personally
prefer it to be done later on.
It will indeed still leave you with || ( foo bar ) or =cpv which you
can be parsed just fine. Yeah it would be nice if it could be reduced
more but later on or now I don't see how it can be reduced anymore than
to the requirements that the ebuild requested.
Again, if it can be done cleanly code-wise no issues with resolving the USE
flags out.
Should only be a few lines of code. (I hope)
Something like hand off the env varable from dyn_compile() in ebuild.sh
to python and python passes it back to ebuild.sh in the next phase for
dyn_install() which gets recorded flattened
If it's not doable then I'll just go for a simple cosmetic patch to
remove newlines and extra spaces.
--
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux
--
gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] [PATCH] make dodoc return better values
Now dodoc always returns with success. I adjusted dodoc to return with
better values. This way I can do the following in my bashrc. It would
probably be better to do something like this by default, but that is an
another discussion.
Regards,
Petteri
Index: main/trunk/bin/dodoc
===
--- main/trunk/bin/dodoc(revision 2317)
+++ main/trunk/bin/dodoc(working copy)
@@ -13,11 +13,16 @@
install -d ${dir}
fi
+success=0
+
for x in $@ ; do
if [ -s ${x} ] ; then
install -m0644 ${x} ${dir}
gzip -f -9 ${dir}/${x##*/}
elif [ ! -e ${x} ] ; then
echo dodoc: ${x} does not exist 12
+ success=1
fi
done
+
+exit ${success}
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH] make dodoc return better values
Petteri Räty wrote:
Now dodoc always returns with success. I adjusted dodoc to return with
better values. This way I can do the following in my bashrc. It would
probably be better to do something like this by default, but that is an
another discussion.
Regards,
Petteri
Hmm. Forgot to add what I do in my bashrc:
dodoc() {
/usr/lib/portage/bin/dodoc [EMAIL PROTECTED] || die dodoc failed
}
Any way this makes dodoc || also useful in ebuilds.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
