[gentoo-dev] Re: [New eclass] twisted-r1.eclass
On Sun, Aug 4, 2013 at 1:13 AM, Michał Górny mgo...@gentoo.org wrote:
We've been working with yac for a while to get the old twisted.eclass
converted to be compliant with distutils-r1 both in design
and in spirit. This is the first version we'd like to submit for review.
Thanks for doing this. If memory serves (and cvs log says it does) I'm
to blame for the first version of this eclass so perhaps I should
review this one :) twisted.eclass changed quite a bit since I last
looked at it, though.
I've reviewed the One more bit of optimization version.
1. The eclass aims to be less conditional than the old one. Especially
we've dropped all the ${CATEGORY}/${PN} checks. The code still sets all
the funny defaults for Twisted suite but those aren't incremental
and can easily be overrode in ebuilds. And in most cases, they simple
are (SRC_URI, LICENSE).
The original version just set those unconditionally, the conditionals
I think you're referring to were added by Arfrever in revision 1.8.
It's not clear to me why. Does someone on this list remember?
2. The eclass comes with a pure bash-3.2 CamelCase converter
for changing PNs like 'twisted-foo' into 'TwistedFoo'. The relevant
code can be moved to eutils as portable replacements for bash-4 ${foo^}
and friends.
That was considered when the original was committed but rejected as
getting too messy. Two questions: have you tested this contraption
with the oldest version of bash we still care about, and have you
considered making it take the input as an argument and echoing the
result (making it work the way versionator.eclass functions do)? If
you want this to be usable as a portable utility function you'd have
to write it that way, might as well do that from the start.
I'm only ok with this code because we'll eventually end up requiring
bash 4 at which point this can be written sanely.
3. The eclass provides a reusable twisted-r1_python_test and sets it as
default python_test. If someone needs to override it, he can still call
it using the former name.
Kind of a shame EXPORT_FUNCTIONS only works on actual phase functions.
The rm -rf in there is slightly hacky: its target will legitimately
not exist if this is the initial install or if we're not in a
twisted-* package (in which case the package should probably not be
hitting this function, but it will if not overridden). There's
potential for confusion there if an upgrade drops or renames a
twisted/plugins/twisted_blah.py file, but that seems like enough of an
edge case it's not worth worrying about.
I was going to recommend adding variables that control what gets
copied and removed, but I can't think of any current users of such
variables. So it's probably not worth the hassle.
If I read this right it'll break if distutils_install_for_testing ever
changes its mind on where to install (and its docstring says to use
TEST_DIR, not which path that'll be). So I'd add a check for
${TEST_DIR}/lib being equal to $libdir after the call to
distutils_install_for_testing, and print a noisy QA message about
updating the eclass if they're different.
4. Cache updating hack is based off twisted.eclass. Sadly, it's not
something we can do without postrm/postinst. Similarly to the old
eclass, TWISTED_PLUGINS needs to list the plugin locations. Since most
ebuilds install to twisted.plugins, it defaults to that. If an ebuild
does not install plugins at all, it needs to set empty TWISTED_PLUGINS.
If I read that right you can just __import__(module), you don't need
__import__(module, globals()). Also, maybe do the loop over plugin
locations in bash. I think if you do that you don't need __import__
and sys.modules anymore, you can just generate import $module and
list(getPlugins(IPlugin, $module)).
I wouldn't worry too much about using pkg_post* for this. It's what
they're there for (twisted's isn't the only plugin system with a file
like this, see for example gdk-pixbuf).
It seems that if TWISTED_PLUGINS is set to the empty array, [[
${TWISTED_PLUGINS[@]} ]] || TWISTED_PLUGINS=( twisted.plugins ) will
set it to twisted.plugins. Is that intentional? It's not necessarily a
problem (you can just set TWISTED_PLUGINS back to the empty array
after the inherit) but it's a bit confusing and I don't think it's
what you intended (why bother with that conditional at all?)
I was going to claim importing from twisted.plugin should never fail,
but then I realized dev-python/twisted might want to use these
functions too.
I might add a comment to the functions operating on that array to
remind people it might be the empty array. It wasn't immediately
obvious to me upon reading the code it'd safely do nothing (today I
learned rm -f (with no further arguments) successfully does nothing,
while rm (with no arguments) fails because of a missing operand).
--
Marien Zwart (marienz)
Re: [gentoo-dev] Re: [PATCH/RFC] eclass/flag-o-matic.eclass: prepend-ldpath
On Monday 15 October 2012 04:35:09 Gregory M. Turner wrote: On 10/14/2012 9:29 PM, Mike Frysinger wrote: Python clearly has an amazing community, so I hate to say anything negative... but I sometimes wish they would build less and buy more. build systems are hard to get right. python is in the situation where the setups they care about mostly work and people generally aren't complaining, but it's more through a hack effort than doing it right which means all the other cases they haven't considered break horribly. cross-compiling for example has never worked correctly out of the box. The reasons for Python's awkward build system are probably mostly historical. I'll (unsuccessfully) try to keep this brief, but still: Python is old: Python 1.0.0 was released January 1994, and Python existed before that. I don't know what its build system was like back then, but most systems you might want them to buy didn't exist yet. Distutils (the build system for external extension modules as well as chunks of Python's standard library) is still old: it was integrated into Python 1.6 (September 5, 2000). Autoconf 2.13 existed, 2.50 wasn't there yet. Looks like CMake was just turned into a separate project around that time. Python's needs are a little special: you can build extension modules using just Python and a C compiler (and you don't need the C compiler if your code is pure-python). This is important on awkward platforms (currently mostly Windows, but I'm pretty sure there were others similarly awkward). This same Python-powered build system is used to build part of the standard library, for obvious reasons. And there are other build systems that make use of python mainly to be cross-platform (scons and derivatives mostly). It would probably be possible to redo Python's own build system now and end up with something better, but I'm not aware of anyone having seriously attempted this, probably because it's just not quite broken enough to be worth it. The awkwardness of distutils we're somewhat stuck with, although there are efforts to modernize and clean up distutils. I'm not so sure there's anything they could have bought to replace Python's own build system, let alone distutils (build systems like automake actually use distutils.sysconfig), without a working time machine (and a rather confusing time loop to allow build systems that currently support python to do so without distutils.sysconfig). -- marienz.
Re: [gentoo-dev] Re: [PATCH/RFC] eclass/flag-o-matic.eclass: prepend-ldpath
I'm going to do something potentially rude and comment on this without having read the entire thread. On Thu, Oct 11, 2012 at 10:39 PM, Gregory M. Turner g...@malth.us wrote: Anyhow one thing I have figured out is how things can work correctly on Linux wihtout -L.: on Linux, the python plugins aren't actually linked against libpython.so! Python can be built with and without a shared library (libpythonx.y.so). If the shared library is built the interpreter executable is linked against it (of course), and normally so are the extension modules. This is useful because it makes the linker do the right thing for applications that embed python (and end up loading libpythonx.y via dlopen). If the shared library is not built extension modules cannot link against it, and the python executable itself exports the relevant symbols. So on a normal shared python build extensions should end up linked against libpythonx.y.so. However, at least one popular distro and presumably most of its derivatives (Debian) has a system python built without the shared library, plus the shared library built separately, for use by applications that embed python. I am not entirely sure why they still do this (if I understand correctly it was originally done for performance reasons, but I'm not sure if they've checked those are still valid). Their extension modules cannot link to libpythonx.y: their python interpreter executable provides the same symbols libpythonx.y provides, so loading such an extension module into the regular interpreter would result in collisions. The reason I mention this is Gentoo's python is built with the shared library, so on Gentoo your extensions *should* end up linked to libpythonx.y (if they use a more or less standard build system, at least). If yours are not I'm curious what happened, and would appreciate it if you gave me some more information off-list (marienz on freenode or email). -- Marien Zwart.
Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass
(pardon any awkward formatting, writing from webinterface instead of a proper client. Please yell at me off-list or on irc if this post is excessively broken.) https://bugs.gentoo.org/show_bug.cgi?id=300922 From that bug: - chpathtool does some simple heuristic to switch the build EPREFIX to the new target EPREFIX - python (seemingly) doesn't like when the pyc files are changed and *not* regenerated. You will see the message: Bad marshalling data I'm not sure if I'm interpreting this correctly, but it sounds as if your chpathtool edits the .pyc file to replace the path? If yes: that will indeed not work, as strings are stored length-prefixed. You cannot sensibly edit .pyc files, you should normally just rewrite them. The .pyc/.pyo file store a version-dependent magic, the mtime of their corresponding .py file, and (since recently) the size of the correspondig .py file. If either changes the .pyc/.pyo is regenerated. The magic does not normally change in released pythons, so that's not much of a problem. The mtime is probably no longer a problem these days either. There used to be a more subtle problem: the python objects you import have the path to their source embedded into them, and if you move the .pyc/.pyo file around that path would be wrong, confusing some (mostly debugging) tools (see http://bugs.python.org/issue1180193 ). This was fixed fairly recently (in python 3, python 2.7 and python 2.6.2), so it is probably no longer worth worrying about, but it's probably one reason these files were handled this way in the past. -- Marien Zwart (marienz)
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On za, 2012-06-23 at 17:08 +0100, Ciaran McCreesh wrote: Is it that Paludis installs a newer SLOT even if a reverse dependency explicitly requests another SLOT? Sounds like a bug to me. No, it's that if a user requests a complete resolution, Paludis installs the newest version of things that it can. Extensive consultation with users has shown that this is a good behaviour, except in the small number of situations that have recently arisen where people are doing weird things with versions and slots. It surprises me that this behavior is normally desirable for packages where all dependencies (including any in the world set or the like) are slotted. The first example that comes to mind here is gtk+: if all packages a user has installed that depend on gtk+ explicitly depend on slot 2 (which is probably uncommon now but reasonable back when gtk 3 was introduced), and they do not have gtk+ in their world file (which is reasonable), do your users really expect the package manager to install gtk 3? If your package manager has a feature similar to emerge --depclean, shouldn't this then suggest immediately removing it again, as nothing depends on it? I would argue that library versions that can be installed side-by-side, like gtk+ 2 and 3, fit the traditional way of how slots worked. But I think automatically pulling in the latest and greatest version of such a library only makes sense if code written against the old library stands a chance of making use of the new library. It might make sense to add a way to inform your package manager if pulling in new slots by default is useful, but I would prefer to give this a more obvious name than funky-slots, and to come up with a better approach for deciding whether or not the property should be set than is SLOTS being used for something clever or not. I would also suggest that the default should be to *not* pull in new slots by default, but perhaps some review of how slotting is most commonly used would help decide on that. -- Marien Zwart
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On do, 2012-06-21 at 20:05 +0100, David Leverton wrote:
1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE,
should REQUIRED_USE be re-verified:
a) for every dep resolution
b) when the package is involved in the resolution for some other reason
(not necessarily being reinstalled, just when the resolver has some
reason to look at it)
c) something else?
I think b) should be sufficient (and probably easier to implement), but
is there any reason why it wouldn't be?
I would still prefer for the resolver to not treat such packages
specially at all, and to just deal with USE flag changes explicitly the
same way they're dealt with for normal packages/flags, just skipping
the actual rebuild and reinstall steps (just updating the vdb). This
sidesteps problems like this one completely. If the package manager
folks think they can safely do something smarter here that might be
nice, but the feature still seems useful (in reducing the number of
silly rebuilds) and far easier to understand without such magic.
This also means things like has_version checks work exactly like they do
right now.
2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag of
package B being disabled, but it's unlikely to be useful. To make this
more concrete, a fictional but vaguely plausible example:
app-text/docmangler:
# links to poppler to handle PDFs, and can use Ghostscript for
# PostScript support if available
IUSE=postscript
IUSE_RUNTIME=postscript
DEPEND=app-text/poppler
RDEPEND=${DEPEND}
postscript? ( app-text/ghostscript )
app-misc/coolapp:
IUSE=doc
# if Ghostscript is installed, docmangler uses it for both
# PostScript and PDF files, but Ghostscript misrenders our PDFs
DEPEND=doc? ( app-text/docmangler[-postscript] )
Here, the [-postscript] dep would force the user to disable that flag,
but it wouldn't do much good because Ghostscript would still be
installed. This doesn't happen with regular USE flags because (if the
ebuild is written correctly) disabling the flag removes the feature even
if its dependencies happen to be installed.
Possible solutions:
a) automatically rewrite the dep as
postscript? ( app-text/ghostscript )
!postscript? ( !app-text/ghostscript )
There may be more than one version of docmangler, with a postscript flag
with different effects (IUSE_RUNTIME or full IUSE, different
dependencies). That means this kind of rewriting would have to be done
based on the dependencies of the docmangler installed at the time this
package gets built, which seems like entirely too much magic, and...
b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make
sense in that case to disallow them in !foo-style conditionals in the
dependencies of the package itself, as that could cause similar paradoxes)
this seems generally impossible, as the same USE flag may be
IUSE_RUNTIME in only some versions of docmangler.
c) don't address it in the spec itself, and require people to manually
write the dep in the blocker form if it's required
I would be in favor of leaving this up to the writer of the coolapp
ebuild, especially as if docmangler is currently using a full USE flag
for postscript this is already currently broken. It seems coolapp should
not be building the pdfs, or should be deleting them after they're
built, rather than forbidding the user from having a docmangler that can
create pdfs (as presumably not *all* generated pdfs are corrupt).
I really think this GLEP should be purely about reducing silly rebuilds
in packages where it makes sense to USE-depend on them with a flag set,
or where an already popular flag can be used to pull in some obvious
packages. I think something like suggested dependencies can be used to
solve a slightly different problem, and perhaps we could have those too,
but let's leave those for later.
--
Marien Zwart
Re: [gentoo-dev] [RFC] gcc-native-flags() proposal addition to toolchain-funcs.eclass
On wo, 2012-06-20 at 17:56 +0200, viv...@gmail.com wrote: #409471 dev-python/pypy-1.8-r1 CFLAGS=-march=native fails to compile https://bugs.gentoo.org/show_bug.cgi?id=409471 Thanks, but currently I do not think we quite need this: I do not think we should use a whitelist of known-working flags for pypy, and rather than blacklisting known-broken flags I am optimistic about just getting them fixed upstream reasonably quickly. And I hope we're done with these for the time being, until another cpu or gcc version comes along. If more bugs like this surface and we can't get support added by upstream reasonably quickly I'll see about using this to fail early, though. -- Marien Zwart
Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
On di, 2012-06-19 at 18:53 +0200, hasufell wrote: On 06/17/2012 10:31 PM, Michał Górny wrote: Hello, A simple solution to a program long-unsolved. In GLEP form. Both attached and published as a gist: https://gist.github.com/2945569 (please note that github doesn't render GLEP headers correctly) As already stated I like this idea, because I already got some optional dep bloat in x11-misc/spacefm and media-sound/gmusicbrowser. However I have a few objections: 1. Optional deps are SUGGESTIONS from the dev which he considered nice/good/sane at the time of writing the ebuild. Other people might totally disagree with those suggestions. As useflags in IUSE_RUNTIME can pick from global useflags as well or even set +foo the user might have a hard time to turn off things he does not want without turning them off for regular IUSE as well. I think we're not all agreeing on which problem is being solved here. I see IUSE_RUNTIME as an improvement for packages that have a runtime dependency on another package to provide a certain feature, but no way of turning this feature off at build time. Examples of this kind of dependency are executables or python imports, where the executable or library being absent is dealt with at runtime. For such packages putting the dependency behind a USE flag makes sense, and for other packages to depend on the package with that USE flag set also makes sense. This already works today. However, if you originally built the package with the USE flag off, and now try to install something that depends on the package with the USE flag on, you force a rebuild. That's not so nice, as there's no change to the installed package at all: the rebuild is a waste of time. IUSE_RUNTIME allows the package manager to skip that rebuild, as it now knows it is unnecessary. What you are describing is more like suggested dependencies. Those may also be useful, but do not solve quite the same problem. I do not think they quite replace the USE flag-based approach described above, as it makes sense for other ebuilds to depend on foo with support for feature blah through the blah USE flag without all those other packages having to know which specific dependencies this adds to foo, or whether foo needs a rebuild to enable the feature or not. Also, even in packages in which IUSE_RUNTIME is used for something like suggested dependencies it is not terribly hard for the user to turn the USE flag off (package.use) and install the interesting bits by hand. 2. Afais useflags that are already in IUSE and used for build-time stuff must not be used for IUSE_RUNTIME too. This is a random rule IMO. I don't have many cases in mind where this would be annoying (could think of debug enabling some in-source switches and adding optional debug tools in RDEPEND. Having one flag here would make it cleaner and tighter for the user to interact with useflags.). However... this is not a logical rule, rather a technical issue. If there is a way to avoid this restriction that would be nice. I do not see where you are going with this. If it makes sense to turn on the build-time support for a feature without installing all the dependencies then the extra dependencies should go behind a separate USE flag (and that separate USE flag may depend on the USE flag controlling the build-time support using REQUIRED_USE). Or perhaps the additional dependencies should be in some new kind of suggested depend. 3. There are no unconditional optional deps possible. ssuominen had an example: virtualx.eclass could have suggestion/recommendation to enable USE=xvfb in x11-base/xorg-server I do not see where you are going with this. Can you refer me to where this suggestion was made? virtualx.eclass adds a hard dependency if the test USE flag (or some other USE flag) is set, and no dependency if this USE flag is not set. When would virtualx.eclass add an optional dependency? -- Marien Zwart
Re: [gentoo-dev] [RFC] Dynamic SLOTs
On zo, 2012-06-17 at 09:26 +0200, Michał Górny wrote: I'm attaching a reStructuredText version of the spec. You can view it rendered as a gist[1]. But please keep the replies on the list, rather than forking the gist. I've only thought about this a little, but some thoughts so far: A common operation in an ebuild will be (say) get the selected version of python. That's easy enough if there's only one kind of dynamic slot being used by the ebuild (just use CURRENT_SLOTS directly), but if the ebuild supports more than one kind of dynamic slot you need a helper function that picks the selected value of that one kind of slot out of CURRENT_SLOTS, either relying on the naming scheme or on a list of supported values of that kind of slot hardcoded in the helper function (in an eclass). That seems a little fragile. Your dynamic slot groups idea could help with this, by having that list sit in a more sensible place than in an eclass, and perhaps by having the package mangler provide a variable per slot group (a little like how USE_EXPAND works). I really dislike the implicit dependencies. First of all: it is entirely possible for ebuild A supporting dynamic slots for (say) python to have a build-time dependency on ebuild B that supports dynamic slots (also for python), but only to get at a utility to run, not to use B as a library. In that case we don't want to force slots to match, and (as you point out) that may not even be possible if the two packages don't support the same slots. Also, it just breaks down completely if you don't use your slot groups idea: if A has DYNAMIC_SLOTS=|| ( py2.6 py2.7 ) and B has DYNAMIC_SLOTS=|| ( ruby1.8 ruby1.9 ) it makes no sense to require the dynamic slot setting to match, but if A has DYNAMIC_SLOTS=|| ( py2.5 py2.6 ) and B has || ( py2.7 py3.2 ) then we do need them to match, and the user has requested an impossible situation (he needs to use versions of A and B that have at least one supported python version in common). Without slot groups the package manager cannot tell these two cases apart. I think it'd make more sense to have those slot groups, per-slot group variables like DYNAMIC_SLOTS_PYTHON=py2.7 py3.2 resulting in CURRENT_SLOT_PYTHON getting set, and an addition to the dependency syntax that lets you depend on a matching named dynamic slot. That makes your DYNAMIC_SLOTS=|| ( py2.6 py2.7 ruby1.8 ruby1.9 ) example impossible, but I think it'd be uncommon for that approach to make sense: I think it'd usually make more sense to split that into two packages, one per language. -- Marien Zwart
Re: [gentoo-dev] Do we need games group and all that game prefixes?
+1 on getting rid of the munging. In my opinion games aren't nearly special enough to get this kind of special treatment. On zo, 2012-05-20 at 20:16 +0300, Maxim Kammerer wrote: Games are rather unique in that they sometimes keep scores across multiple users. Yes, and that's frequently handled by making them setgid to some group that actual user accounts are not in, allowing the games to write to their own statedir without allowing users to mess with those files by hand. Gentoo's approach actually breaks this, as it's already using the group the game executables are in for access control (so actual user accounts *are* in the group the game executables are in). This leads to bug 125902, which contains a lengthy discussion on this same subject. My personal opinion is that Gentoo's games setup only helps on systems that have no or heavily restricted network access, no or heavily restricted access to external media, has actual games installed system-wide, and needs access to those restricted to some accounts through technical means. I think such a setup is sufficiently uncommon we shouldn't specialcase games this heavily to support them. I don't think restricting games for resource consumption reasons makes sense, as people will virtually always be able to uselessly consume resources some other way. And I don't think restricting access to games because they're offensive/a waste of time/etc makes sense on the majority of systems, as people will be able to access similar content through other means, or will be able to install games into their homedir. However, when this came up in the past Gentoo's games project (which does an outstanding job maintaining a *lot* of games ebuilds) was opposed to changing this as the current setup isn't actually *broken* (for the majority of games), and changing things around a lot of work. So I'd like to request they reconsider (and start installing new/updated games in a more normal way), but as they're the ones doing most of the work here I think it makes sense to leave the decision with them. -- Marien Zwart
Re: [gentoo-dev] Living in a bubble [gentoo-proctor] Warning^2
On Wed, Jun 06, 2007 at 10:29:47AM -0500, Grant Goodyear wrote: Chris Gianelloni wrote: [Tue Jun 05 2007, 05:00:28PM CDT] As a member of the Council, I find it personally offensive that the Proctors have taken this action on what wasn't even a problem thread. I'm sick of this. I call for the immediate disbanding of the Proctors. As much as I dislike many of the posts from geoman/ciaranm, they really had not done anything worthy of being banned. I ask that this ban is undone *immediately* and that the Proctors have their powers revoked. *Sigh* I, too, was quite surprised to see people banned for what appeared to be reasonable behavior (in this case). That said, I wish you'd started w/ a more temperate response, instead of going all nuclear on the proctors. It's likely to create some hard feelings, and that just makes things harder to fix. So, how about using this incident as an opportunity for a calm discussion about the mandate and role of the proctors? The proctors clearly felt that they should shut down this thread _before_ things got out of hand. Perhaps the goal was laudable, but the methods were not? (As an aside, I didn't realize that Roy's e-mail was supposed to be a proctor directive.) Or are people really looking for the proctors to get involved only when behavior is particularly egregious? Is there a way to fix the current system, or should it be chucked entirely, as has been suggested? Well reasoned thoughts and opinions welcome. I was originally planning to send this yesterday, but wanted to delay it a bit because the list had just calmed down again. I'm a recent addition to the proctors team, probably pulled in mainly because I'm a #gentoo op, and have also been involved with conflict resolution things for the userrel project. This was the first time I was around as a proctor during an event involving proctors. A disclaimer: I was a bit tired when I originally wrote this and have not fully proofread this, so expect the grammar to be a bit bizarre in places. I probably missed some relevant bits too, but this is more than long enough already. An attempt at a timeline of what happened with that thread: An initial mail from Benjamin Judas is sent to the gentoo-dev list (which is mainly a *technical* list), with a sent date of 20:09 UTC, arriving in my inbox at 20:15 UTC. It contains pretty much no technical content, and some things (small scottish griper brain, I'm waiting for the stinky comments from the usual corners. that seem likely to lead to flames. The second mail is from Stephen P. Becker, dated 20:18 UTC (less than 10 minutes after the first), arriving in my inbox at 20:25 UTC. It contains no technical content, but does contain Clean the sand out of your pee-hole..., which might be a joke but seems likely to fuel the flames even if it was meant as one. More mails follow, with pretty much no technical points in them. I'll skip them, since they did not really affect the decisions that were made. Around this time a proctors member (NeddySeagoon) sends another mail to the list asking people to stop replying. He was alerted to the thread via irc at around 20:33 UTC (after which he still had to actually read the start of the thread). His mail has a sent header of 20:44, arriving in my inbox at 20:55. This gets two replies that both make it rather obvious they disagree with this suggestion and definitely do not intend to stop posting to the thread (one sent 20:52 (*before* Neddy's mail makes it to my inbox) arriving in my inbox at 21:00, and one sent 21:00 arriving at 21:10). At this point the decision is made to *temporarily* disable ml access for those two people in an attempt to let the thread die out (mail from amne, 21:13 sent, 21:20 in my inbox). Please take a look at the timestamps above. We spend some time reading the mail sent to the list, discussing what to do, and typing in replies. Add in the roughly ten minute lag between sending mail to the list and it reaching most of the subscribers and we're continually about 15 minutes behind no matter how quickly we try to react. And we do try to react quickly, because it seems likely more flames are being sent and making their way through the list software while we decide what to do. Amne actually responded to the second reply to NeddySeagoon's mail before I had the time to receive and read the thing. In hindsight it is obvious this attempt to stop the thread failed. A flood of replies resulted, most of them taking apart the wording of NeddySeagoon's original request to stop replying. And some more flaming later we get the following from a council member to the -dev list: From Chris Gianelloni [EMAIL PROTECTED]: I really have to agree with you. The proctors have completely lost their way. They are ineffective. They tend to compound the problems they were created to stop. Yes, they obviously did not manage to stop this particular thread. I am not sure how they *could* have
Re: [gentoo-dev] New eclass: gkrellm-plugin
On Thu, Mar 08, 2007 at 11:19:20AM -0600, Jim Ramsay wrote:
gkrellm-plugin_pkg_setup() {
if ! built_with_use app-admin/gkrellm X \
! has X ${IUSE}; then
eerror This plugin requires the X frontend of gkrellm.
eerror Please re-emerge app-admin/gkrellm with USE=\X\
die Please re-emerge app-admin/gkrellm with USE=\X\
fi
}
Any chance of plugins existing (or appearing in the future) that work
with a USE=-X gkrellm and a USE=X gkrellm the same way? In that case
that check will not do the right thing. Perhaps add a var the plugin
ebuild can set to indicate it does not need gkrellm built with X even
though the plugin has no X USE flag?
This will also error out if you try to build a plugin that has the X
USE flag with both the plugin and gkrellm itself built with -X, you
probably meant to check for use X too?
--
Marien.
pgpunqAqv1Kld.pgp
Description: PGP signature
Re: [gentoo-dev] New eclass: gkrellm-plugin
On Thu, Mar 08, 2007 at 03:51:42PM -0600, Jim Ramsay wrote:
gkrellm-plugin_pkg_setup() {
if [[ -z ${PLUGIN_NO_XCHECK} ]]
! built_with_use app-admin/gkrellm X; then
eerror This plugin requires the X frontend of gkrellm.
eerror Please re-emerge app-admin/gkrellm with USE=\X\
die Please re-emerge app-admin/gkrellm with USE=\X\
fi
}
This is basically horrible nitpicking, but perhaps point at
package.use here to prevent people from doing USE=X emerge gkrellm on
the commandline (prevents accidentally remerging gkrellm with -X and
breaking stuff later and all that)?
(http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2chap=2
does not quite mention this specifically, and is a bit long to link to
anyway, or I'd say link to that in the message)
--
Marien.
pgpqOICfh19Cf.pgp
Description: PGP signature
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, Feb 22, 2007 at 04:13:11AM +, Ciaran McCreesh wrote: On Thu, 22 Feb 2007 04:04:37 + Steve Long [EMAIL PROTECTED] wrote: | In process terms, I can't understand why the team working on it isn't | a pkgcore dev (eg marienz if you can't communicate with ferringb) Because a) they haven't asked, Since I'm a relatively active pkgcore dev and listed explicitly in the text you reply to, I'm going to assume I'm part of the they here. I have not asked for access to PMS. The whole process of only people we deem sufficiently skilled get access makes me a bit uncomfortable. For example, what if I managed to get through whatever process there is for verifying if I'm capable of contributing, and then am unable to actually contribute because of time constraints? I'm afraid that would effectively reduce my credit for participating in future projects of the same kind. That's sort of a worst case scenario though. And it's likely I do lack the knowledge and experience to contribute a lot to this specification, but that is a bit hard for me to judge without being able to see what is there already in the first place. b) they're more interested in replacing the ebuild format I am very curious where you got that idea. No, I am not interested in replacing the ebuild format. Nor is any other pkgcore dev as far as I know. I do have a few ideas for extensions to the format, which work together with the EAPI proposal. c) every other time they've gotten involved they've been highly unhelpful. Do you have any examples in mind here? I can't think of one, I'm curious what project you are referring to. No longer in reply to this particular mail, but to the thread in general: I am a bit unsure about what the goal for PMS is here. It does not seem to be to document what a certain (the current?) version of portage does, as the defacto standard. Instead you want to document what portages *intention* is, or something like that. That obviously sounds like an excellent idea, but as far as I know most of the PMS contributors are also Paludis devs. Paludis, being an alternative to portage, is *also* trying to handle ebuilds the way portage is intended to handle them. So what I'm afraid of is that by the time that Paludis 1.0_pre is released we will simultaneously see PMS released to the public, and Paludis 1.0_pre supporting that PMS perfectly, with all deviations on the part of portage (or pkgcore) being considered bugs in their implementation of the specification. This does not go into just how far PMS might end up deviating from existing portage behaviour and existing ebuilds in the tree, and how much of that is acceptable for a specification that is intended to be picked up by the council as something official all ebuilds and managers must adhere to. We have already seen some examples where code used in ebuilds currently in the tree would be invalid under the new specification. It does not seem right to me to have a specification like this (which if it gets picked up by the council all tree ebuilds and all package managers should comply with) written mostly by developers of a single package manager (no pkgcore devs have access to the PMS spec at the moment. I do not know who *does* have access though. Is there a list somewhere, or do you need to have access to get at the list? :) ). Most of this could be countered by saying that there should be a reference package manager to go along with the specification, but I am not convinced this is the right approach here, since a reason to write this specification to begin with was to be able to figure out which of the package managers are viable portage alternatives. The idea was to not get any messy portage quirks documented as required standard behaviour, the risk here is that we'll now get paludis quirks documented as required standard behaviour. -- Marien. pgpL3ElYSvXzs.pgp Description: PGP signature
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thu, Feb 22, 2007 at 06:42:39PM +0100, Kevin F. Quinn wrote: On Thu, 22 Feb 2007 17:10:38 +0100 Marien Zwart [EMAIL PROTECTED] wrote: The idea was to not get any messy portage quirks documented as required standard behaviour, the risk here is that we'll now get paludis quirks documented as required standard behaviour. Well, that'll come out in review later, I would expect. I'll be surprised if the EAPI=0 spec Ciaran et. al. are working on just gets rubber-stamped without anyone looking! This thread shows there are a number of people who know what they're talking about and will review it heavily when it is published as a draft, and the council are unlikely to approve something that doesn't have broad support. I'd like to add some emphasis on when it is published as a draft. What makes me uncomfortable is that the intention seems to be to release that draft simultaneously with the Paludis 1.0_pre mentioned earlier, which is rather a lot later than I'd like to see it. With respect to having a small relatively closed group for initial drafting - it's a sensible way to do things in the early stages (it's not the only sensible way of course). In the early stages: agreed. I just hope it will not be developed up to release candidate status with little external (from non-Paludis devs) input. If anyone doesn't like it, there's nothing stopping them from drafting their own in a different way. Indeed, having two strong drafts would be good, for finding idiosyncrasies from different perspectives. If I considered myself qualified and had a lot of spare time I would have started doing that by now :) I have to say, the few queries I've seen from Ciaran have been exactly what I would (happily) expect. Yes, the *few* queries I've seen were ok. Perhaps there is simply much less there yet than I think there is. -- Marien. pgpq4paBtpv9u.pgp Description: PGP signature
[gentoo-dev] Reminder: upgrade portage or you commit broken digests!
(Sending this to both -dev and -core to reach more people, sorry for the spam) Devs running ~arch portage should upgrade to portage-2.1_pre9-r5, which pulls in an important pycrypto upgrade. If you do not upgrade you will commit broken SHA256 digests (see bug 131293 and 131396). Please upgrade. If you are running portage 2.0.x you are not affected and do not have to upgrade anything. We will do occasional checks for broken digests over the next couple of days, but if you think you committed something with pycrypto 2.0.1-r5 in roughly the last 24 hours please check if the sha256 digest matches after you upgrade pycrypto (and portage). You will likely fix things faster than we do. Thanks. -- Marien. pgpGc9gqw8cwO.pgp Description: PGP signature
[gentoo-dev] SHA256 digest issues
As reported in bug 131293 a pycrypto bug caused a lot of digest and Manifest files to be created with bogus sha256 hashes. A fixed pycrypto (2.0.1-r5) was committed to the tree. This means the following: - If you run ~arch portage and the latest pycrypto you will hit digest failures. You will hit fewer digest failures as packages are fixed. - If you run ~arch portage and do not upgrade pycrypto you will hit more and more digest issues as stuff is fixed. - If you run stable portage you are not affected. If you commit to the tree with an unfixed pycrypto you can add new broken digests, so please do not do that. We (portage project) are fixing known broken Manifests/digests. If you come across any broken SHA256 digests feel free to fix them though: the package is basically unusable with ~arch portage until it is fixed, and fixing it twice does not really hurt :) Apologies for the inconvenience. -- Marien. pgpOBtdXlWs8r.pgp Description: PGP signature
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
On Mon, Feb 13, 2006 at 02:00:48PM -0500, Patrick McLean wrote: How about RICER or RICERFLAGS :) +1. RESOLVED RICER has such a nice ring to it :) -- Marien. pgp70IcstDKz0.pgp Description: PGP signature
Re: [gentoo-dev] Bugzilla etiquette suggestions
On Sun, Feb 12, 2006 at 09:11:33PM +, Daniel Drake wrote: I wrote most of this a while ago but didn't get round to finishing it. This seems appropriate at this time, so here it is :) Here are some small *suggestions* for how I think we can motivate users on Bugzilla to contribute more, and to contribute more often. I'm not suggesting this be enforced as policy, but it would be nice to see other developers giving this some thought. I'm far from perfect here, but I am working on sticking to my own suggestions more and more. Agree with and try to follow most of this myself, but I'm hesitant about: 4. Give the user a chance to make minor corrections If a user contributes a patch/ebuild which is slightly wrong, and the issue is non-critical, don't immediately correct it on their behalf and commit it to get the bug out of the way. Instead, provide an explanation of their mistake and give the user a day or two to correct it and attach an updated version. This has the bonuses that the user definately won't repeat that mistake in future contributions, and they will have the nice feeling of full credit for the contribution after you name them in the ChangeLog :) If they don't respond in that time, make the correction yourself and commit it anyway. I think this is too much effort, especially for small corrections. I tend to fix them myself, commit with a message like ...based on an ebuild from ... (bug #) and comment on the bug like Committed with minor changes. It would probably be a good thing if I went into a bit more detail about what the minor changes were and why I made them, I guess :) snip I think a short note of thanks in the bugzilla comment can go a long way (suggestion: thank them for something in particular so that it doesn't sound so generic). I am extremely bad at the not sounding generic bit... :( -- Marien. pgp8ekbbuVh0A.pgp Description: PGP signature
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Wed, 30 Nov 2005 18:50:02 -0500 Mark Loeser [EMAIL PROTECTED] wrote: Jakub Moc [EMAIL PROTECTED] said: 1.12.2005, 0:29:48, Chris Gianelloni wrote: revdep-rebuild --library=libstdc++.so.5 is all that's needed here to avoid things like Bug 64615. Yea, I updated my statement on the bug to reflect this. C++ stuff should be the only thing affected, so this _should_ be enough. Its also already something that's been in the ebuild for a while now. Not sure if everyone is aware of this, but most installed pythons link to libstdc++.so. This is not a problem if you run the above revdep-rebuild (it should catch it just fine). It is a problem if you get rid of gcc 3.3 before installing libstdc++-v3 or running the revdep-rebuild, as it will leave you with a broken python and therefore unable to emerge. -- Marien. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Thu, 1 Dec 2005 01:53:25 +0100 Jakub Moc [EMAIL PROTECTED] wrote: 1.12.2005, 1:30:41, Marien Zwart wrote: Not sure if everyone is aware of this, but most installed pythons link to libstdc++.so. This is not a problem if you run the above revdep-rebuild (it should catch it just fine). It is a problem if you get rid of gcc 3.3 before installing libstdc++-v3 or running the revdep-rebuild, as it will leave you with a broken python and therefore unable to emerge. Which returns us to the question why don't we build python with nocxx so that we could avoid this major PITA. Actually I'm looking into that. According to the information I have found on the python-dev list and in python's documentation the libstdc++ link is not needed, but a dev asked a python herd member for it, and therefore the link was added. Haven't caught that dev yet, so at the moment I don't know why that link is there. If someone on this list knows the reason it was added, please enlighten me. -- Marien. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] last rites for dev-python/twisted-cvs
Hi, twisted-cvs is a live cvs ebuild that is completely useless since it is checking out a module that no longer exists (upstream switched to svn long ago). I plan to remove it next sunday (yes, that's less than the usual week, but the ebuild doesn't even finish src_unpack, so...). -- Marien. pgpWDSBTPCeBJ.pgp Description: PGP signature
[gentoo-dev] request for comments/review: twisted.eclass
Hi all,
Since it's policy and especially since it's the first time I write one
of these things I'm submitting an eclass I want to add to the tree for
review. It will only be used by the twisted subpackages I'll be
maintaining (see bug 80639).
Subpackage ebuilds using this only have to set MY_PACKAGE,
DESCRIPTION, KEYWORDS and DEPEND. I'd like to get rid of MY_PACKAGE but
I haven't figured out how to convert lowercase to uppercase without
using tr (MY_PACKAGE will be Conch if PN is twisted-conch). Also
adds the ability to run the unit tests for the package and updates
twisted's plugin cache.
Would like to hear about any ideas on how to do that case conversion
and any bugs spotted. If there are no objections I'd like to add this
to the tree in about two days, so bug 80639 can finally be fixed.
--
Marien.
# Copyright 2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License, v2 or later
# $Header: $
# eclass to aid installing and testing twisted packages.
# you should set MY_PACKAGE to something like 'Names' before inheriting.
# you may set MY_PV to the right version (defaults to PV).
inherit distutils versionator
MY_PV=${MY_PV:-${PV}}
MY_VERSION=$(get_version_component_range 1-2 ${MY_PV})
MY_P=Twisted${MY_PACKAGE}-${MY_PV}
HOMEPAGE=http://www.twistedmatrix.com/;
SRC_URI=http://tmrc.mit.edu/mirror/twisted/${MY_PACKAGE}/${MY_VERSION}/${MY_P}.tar.bz2;
LICENSE=MIT
SLOT=0
IUSE=
S=${WORKDIR}/${MY_P}
twisted_src_test() {
python_version
# This is a hack to make tests work without installing to the live
# filesystem. We copy the twisted site-packages to a temporary
# dir, install there, and run from there.
local spath=usr/$(get_libdir)/python${PYVER}/site-packages/
mkdir -p ${T}/${spath}
cp -R ${ROOT}${spath}/twisted ${T}/${spath} || die
if has_version =dev-lang/python-2.3; then
${python} setup.py install --root=${T} --no-compile || die
else
${python} setup.py install --root=${T} || die
fi
cd ${T}/${spath} || die
PATH=${T}/usr/bin:${PATH} PYTHONPATH=${T}/${spath} \
trial -R ${PN/-/.} || die trial failed
}
twisted_src_install() {
distutils_src_install
if [[ -d doc/man ]]; then
doman doc/man/*
fi
if [[ -d doc ]]; then
insinto /usr/share/doc/${PF}
doins -r $(find doc -mindepth 1 -maxdepth 1 -not -name man)
fi
}
update_plugin_cache() {
einfo Updating twisted plugin cache...
python_version
# we have to remove the cache or removed plugins won't be removed
# from the cache (http://twistedmatrix.com/bugs/issue926)
rm
${ROOT}usr/$(get_libdir)/python${PYVER}/site-packages/twisted/plugins/dropin.cache
# notice we have to use getPlugIns here for =twisted-2.0.1
compatibility
python -c from twisted.plugin import IPlugin,
getPlugIns;list(getPlugIns(IPlugin))
}
twisted_pkg_postrm() {
distutils_pkg_postrm
update_plugin_cache
}
twisted_pkg_postinst() {
distutils_pkg_postinst
update_plugin_cache
}
EXPORT_FUNCTIONS src_test src_install pkg_postrm pkg_postinst
pgpdTyhgtfMRU.pgp
Description: PGP signature
