[gentoo-dev] Re: [New eclass] twisted-r1.eclass
On Sun, Aug 4, 2013 at 1:13 AM, Michał Górny 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 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] [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 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] [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
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=2&chap=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] 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] 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
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
[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 :) > 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 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
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
[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