[gentoo-dev] debug/release builds extensions/clarification proposal
Hi
I would like to give some idea into consideration.
Abstract
In short, adding following new variables to make.conf and implement handling
of them in eclasses:
- CFLAGS_DEBUG (and friends like CXXFLAGS_DEBUG) - use defined debug compiler
flags - by default set to -O0 -ggdb (and maybe -Wall as well)
- LDFLAGS_DEBUG - user defined debug linker flags - default to "${LDFLAGS}"
- FEATURES_DEBUG - default to "${FEATURES} nostrip" (or splidebug, according
to preference)
Background
Currently handling debug/release builds is incoherent and misleading to say
the least. We have got in Gentoo:
- CFLAGS/LDFLAGS - user needs to take care of adding -O0 and/or -ggdb
- user needs to take care of FEATURES=nostrip or FEATURES=splitdebug (not
both)
- user may set debug USE flag
The drawbacks are as follows:
- USE=debug is useless when CFLAGS/LDFLAGS or FEATURES are not appropriate
- CFLAGS/LDFLAGS must be set globally when they are about to be "supported"
- those who don't want to set them globally, they are forced to use (very
flexible and great indeed) /etc/portage/env hack - which is undocumented and
unsupported, because everything user set there, is not shown by emerge --info,
thus bug reports from such machines are not taken into consideration, as
virtually everything that breaks can be there
- too much choice leads to confusion, and many users who enabled some of those
(but not all), still don't get useful backtraces and only fool themselves when
reporting something upstream.
Motivation:
The idea is modeled after handling such situations in CMake build system. I'm
one of contributors to official Gentoo KDE team experimental overlay (kde-
crazy) and we provide live ebuilds and betas/snapshots for KDE4 and related
applications. It's quite probable that many of our users participate in KDE
testing, it's vital to provide for them an easy way of setting up testing box
(though it's not the motive here).
KDE4 uses CMake as build system and CMake out-of-the-box provides build
configurations: Release, Debug, RelWithDebInfo, MinSizeRel (one can easily
figure out what they mean). For typical use, user doesn't want nor needs more
than two configurations - let's call them Release and Debug - it fits in
existing USE=debug handling scheme, where there are two build types with
"release" as default. Overlay team and Gentoo KDE developers already make use
of this feature and we provide debug USE flag for all KDE4 packages. The
motive is to make handling build type in more coherent, predictable and less
confusing way and I guess this proposal addresses it quite well.
Implementation:
Implementation would be provided by build system eclasses - for far cmake
eclasses could benefit from this extension, though new USE=debug capable
eclass could be introduced for other build systems (including autotools).
Implementation is trivial - eclass would be responsible for handling USE=debug
flag, when debug is set:
- replace CFLAGS with CFLAGS_DEBUG, LDFLAGS with LDFLAGS_DEBUG and possibly
others
- replace FEATURES with FEATURES_DEBUG
Implementation could as well automatically add "debug" to IUSE as well -
specific packages that are not interested in such flag - would just override
IUSE in its ebuilds.
For cmake-utils - handling debug IUSE is already done, only replacing
CFLAGS/LDFLAGS/FEATURES would be requited.
For autoconf based packages - some of them already provide 'support' for debug
builds ('a'ka --enable-debug), but making use of debug USE would need special
support here or separate eclass that could be introduced for packages that can
benefit. If could be as well enforced globally (by adding either --enable-
debug or --disable-debug apart from switching CFLAGS - as confgiure scipt
ignores unknown arguments) but that's just a matter or implementation.
Backward compatibility
As extension operates on newly introduced variables - backward compatibility
is preserved. Backward compatibility may be "broken" for those who utilize
/etc/portage/env hack as strange compiler/iinker flag/FEATURE combinations may
appear.
In similar scheme more build profiles could be implemented, (like libs/apps
ready for profiling) but let's leave it alone for now.
Discussion and constructive criticism is welcome :)
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: debug/release builds extensions/clarification proposal
On Monday 01 of December 2008 08:04:04 Duncan wrote:
Well, so far it's not GLEP, just an idea thrown to brainstorm.
> As such, neither /etc/portage/env nor eclasses can effectively deal with
> FEATURES in general, tho there are a few specific exceptions that do
> happen to be implemented at the bash level.
Those exceptions are nostrip and splitdebug at least, besides I intend to keep
it bash (or ebuild) level only - to preserve simplicity and yet functionality.
FEATURES_DEBUG was a clean and convenient approach of me being unaware of
FEATURES internals - thanks for clarification. FEATURES little inconsistency
problem needs to be addressed. The goal is to have only one, determined and
always working way of "not-stripping" symbols. Of course it can be easily
handled in eclass by something like this:
if use debug; then
FEATURES=${FEATURES//splitdebug//}
FEATURES=${FEATURES//nostrip//}
FEATURES="${FEATURES} ${PREFERRED_NOSTRIP_METHOD}"
Dzwon tanio do wszystkich!
Sprawdz >> http://link.interia.pl/f1fa7
Re: [gentoo-dev] Re: debug/release builds extensions/clarification proposal
On Monday 01 of December 2008 09:36:12 Diego 'Flameeyes' Pettenò wrote:
> > - USE=debug is useless when CFLAGS/LDFLAGS or FEATURES are not
> > appropriate
> What are you saying here? I'm afraid you're mistaken here.
The point is to look at this from users' (well, a bit) point of view -
USE=debug variable is ambiguous in it's meaning. While it enables only
codepaths (asserts, #ifdefs and similar) it suggests (by name and for some
packages not only suggests) enabling debug symbols.
And policy is to enforce CFLAGS from make.conf and wipe out every package-
defined flags as far as I know.
> For the most part, USE=debug means "enable debug code paths", which for
> lots of projects simply means "enable assertions"; there are packages
> that take this as "enable debug symbols too" but I don't think that's
> very valid since users might want debug code paths but not symbols and
> vice-versa (I indeed have debug symbols bug no debug codepaths enabled).
That's correct, the problem is - Gentoo does not provide officially supported
mechanism of enabling both or just debug symbols per package basis - it
doesn't even provide any supported/documented mechanism for per package
CFLAGS, FEATURES and similar.
If /etc/portage/env hack/feature could be made official (for CFLAGS,LDFLAGS
and bash-domain FEATURES) - it could address this issue good enough, because
with proper smart combination of symlinks/files the "ultimate configuration"
power would be delivered, not just "cleaning/workaround" I am actually
proposing. Per package debug/release/profile/or_any_other configuration is
what I would pursue, and in my proposal I used USE=debug as existing and
supported way of achieving this.
While I don't like hack @pve uses (I prefer portage/env as more convenient
way), his idea about emerge --info seems interesting.
> - -ggdb *does not have any runtime performance hit*; neither in
Yes, I'm well aware of that, though it increases disk space requirements a bit
as it's applied to all libs/bins.
> - -O0 is not always a good idea; beside bugs in packages concealed by
>-O1+ [1]
[1] is a pathology and should be fought against, -O1+ may leave frame stack
useless for debugging due to inline optimizations in some places (especially
debugging inline class implementations is limited, which affects Qt/KDE) -
besides - I may not stated it clear - those default values would be defined in
the very same make.conf, so it could be:
CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=nocona -O2 -pipe -msse3 -ftree-vectorize"
CXXFLAGS="${CFLAGS}"
CFLAGS_DEBUG="-O2 -ggdb"
Yet, I still cannot think of this proposal other way like of dirty workaround
for the problem, that doesn't really exist (well, at least for developers, who
have meta-distribution and ultimate freedom for user in mind). For the users
the problem is real, of course it's usually a consequence of either not being
aware of those mechanisms or as a result of ambiguous semantics of USE=debug.
And what about pushing some bash-domain FEATURES to USE flags? Like nostrip,
splitdebug? I guess being able to set it per package is important.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: debug/release builds extensions/clarification proposal
On Monday 01 of December 2008 08:04:04 Duncan wrote: > (Of > course, if it's the latter, it will need to be an official GLEP, and > you'll have three separate package managers and their developers to push > the proposal thru to at least to general agreement, or the council will > almost certainly reject the GLEP, if it gets even that far.) That I found interesting - what does any 3rd party package manager to do with setting policies and enhancements regarding official Gentoo package manager? Have you ever heard of "liberum veto"? But that's an off topic of course. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: debug/release builds extensions/clarification proposal
On Monday 01 of December 2008 22:51:57 Ciaran McCreesh wrote:
> Experience, manpower, the ability to try out potential enhancements
> rapidly, a long track record of getting it right and the growing
> recognition that most people doing package manager work for Gentoo
> aren't doing it with Portage.
While of course I agree that any input from 'outside' is welcome and valuable,
yet to get things done, in my opinion the final decision should not be blocked
by from any alternative package manager and some policies should be enforced.
But on topic, what's a counter proposal for my idea then?
Quick search in archives gave me some results I don't particularly like, like
the idea with /etc/portage/packages.cflags and /etc/portage/package.env, and
they have been dropped for similar reasons - as the former needs special
parsing instead just sourcing the script (the problem is that someone needs to
implement this - this is usually the problem, especially in pure volunteer
projects like Gentoo), the latter looks a bit messy to me. /etc/portage/env
would be the best approach when made officially supported (recently it looks
like /etc/portage/env is sourced multiple times and that should be fixed, for
convenience, just in case user wants to put:
CFLAGS="-O0 -ggdb"
CXXFLAGS="${CFLAGS}"
FEATURES="${FEATURES} nostrip"
(or even USE="${USE} debug")
actually /etc/portage/env could easily replace package.keywords and
package.use as well and introduce replacement for meybe-proposed-sometime
package.features - I wonder whether it's been discussed already.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: debug/release builds extensions/clarification proposal
On Tuesday 02 of December 2008 10:40:19 Alec Warner wrote:
>
> You asked, so the counter proposal is to *do nothing*.
>
> Ideas (even good ones) don't always get implemented.
>
> Sometimes that just isn't the direction the maintainers want to take
> the project.
> Sometimes it is harder to implement than most people realize.
> Sometimes suggested implementations are just a hack and a bad idea all
> around.
>
> I think starting with an implementation may have been a bad starting move.
>
> Start with what you want to accomplish:
> - Get feedback on whether this is useful or not.
> - Get feedback on other features that may be available.
> - Get feedback on how some folks would accomplish this.
>
> "I want to be able to turn debug builds on or off on a per-package
> basis. Debug builds entail both debugging symbols, split-debug, debug
> CFLAGS and debug LDFLAGS."
>
> Is that a fair summary of your request?
Yes, precisely. But forget about this proposal, as I stated already it's just
a workaround for inability to set CFLAGS/LDFLAGS and those two FEATURES per-
package basis in *official* way.
> I am unsure how much you actually care about how each package manager
> implements this feature (or if anyone implements it but portage, or
> paludis, or whatever the majority of the KDE users are using).
>
> I'm also unsure how useful this is when say, some part of KDE links
> against libfoo and KDE is built with debug symbols but libfoo is not.
> Is that really useful? Are users actually asking for this proposed
> feature or do you just think they want it? Do you have any data to
> back up why someone should implement this feature (mailing list posts,
> forums threads, etc..)
No, and I'm afraid I cannot provide any single evidence that users actually
need features like:
- per package cflags/ldflags/features
- per category use flags, accept_keywords, cflags
- or tag clouds instead of hard coded categories
- user-defined packages sets (official)
- multiple portage configurations support to ease building binaries for
several targets on a same host
- dynamic libraries tracking for safe package upgrade or removal
- real backwards dependencies
- maybe git driven Portage
- automatic kernel modules rebuilding
- mysql split ebuilds
Actually, I'm perfectly certain that users are way more interested in critical
important aspects of their system like whether HOMEPAGE should be set in
ebuilds or in metadata.xml :D
Please let me solve your little problem with HOMEPAGE for you...
Package's homepage obviously may be, and actually is - ${PN}-${PV} specific.
That being said it *would* needs to be specified either in every ebuild or as
someone proposed - in metadata.xml in versioned/tagged way.
And no matter how many searches you run - it may be easy to predict that due
to lazyness (less probable) or just to avoid copy/paste (copy/paste is bad -
everyone knows that) - some developers used to put HOMEPAGE in eclasses -
because it may be used to put in postinst message for some reasons, that being
said it needs to be in ebuild domain in current implementation.
Mixing XML and bash (ebuild) in general isn't a bad idea but using bothe of
them seems to be inconsistent - but some trade off needs to be paid sometimes.
When duplicating HOMEPAGE is such a pain for developer (as he needs to type it
all over again, I agree, it is pain, especially when one need to put some
things only to please repoman), why not invest some time and develop tools
that could make it easier - like meta-ebuilds (or ebuild generators) and
ebuild templates? I've done something like this to autogenerate plasma applet
live ebuilds from KDE playground on their SVN (it's not yet commited to
overlay as eclass is not yet ready to fetch/unpack and build packages from
this location and I haven't got time yet to patch it).
If declaring HOMEPAGE in eclasses troubles you as you need BASH to process it
properly (it may be pain for non-BASH search tools) and XML may be problematic
to parse for bash tools - why not create such ebuild generator or 'compiler' -
that could generate ebuild? Or for example as complete BASH script (no need
for inherit anything) - and use eclasses ONLY like 'development library'.
This way - every ebuild could be:
- eclass-breakage free (overwriting eclasses don't take place so you are
certain that user's emerge-problem is not him messing with eclasses - like
mixing those from other overlays)
- every defined variable is there (no need for 'inherit' lookup) - so that one
can easily find HOMEPAGE= using every kind of tool (unless it is enclosed with
some condition - why would anyone need to do that btw?)
- much larger disk space requirements for Portage tree - but that could be
compensated by for example gzipping every ebuild.
Of course every problems with dichotomy ebuild vs metadata could be solved by
some new Portage backend - better suited for queries and storage (maybe some
relational database).
But so far - the
[gentoo-dev] Proposal: disable python and perl USE flags in profile
Following advise from https://bugs.gentoo.org/show_bug.cgi?id=250179, I'm bringing it here. -- regards MM -- Wygraj telefon komorkowy! Sprawdz >> http://link.interia.pl/f1fc0
Re: [gentoo-dev] reorganization of /var/lib gentoo-related files
On Wednesday 31 of December 2008 15:33:14 Fabio Rossi wrote: > Ok, but at the end we have an exception in the tree (/var/lib/gentoo/news/) > which is not justified (looking at the current discussion). My proposal has > arisen after having seen the /var/lib/gentoo/news/ hierarchy. Then it seems way more appropriate and easier to implement to force Gentoo news to comply to FHS and shot on sight those responsible for this mess :D -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] reorganization of /var/lib gentoo-related files
On Wednesday 31 of December 2008 16:57:12 Ciaran McCreesh wrote: > Gentoo does not comply with the FHS. It was established a long time ago > that FHS is considered silly and any compliance is merely because the > FHS people somehow managed to avoid screwing that particular area up. Well, we're not here to deliberate about people's taste in FHS silliness manner. FHS, being standard de-facto, following the definition of the word "standard" as something accepted by majority and thus promised to be respected. Not justified standard violations or justified by "I don't like it" or "It's silly" should be repressed and some good standards should be explicitly forced in my opinion. Otherwise, inconsistency will create the feel of mess. I believe we can agree on this. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] reorganization of /var/lib gentoo-related files
On Wednesday 31 of December 2008 17:28:09 Ciaran McCreesh wrote: > On Wed, 31 Dec 2008 17:21:45 +0100 > > Maciej Mrozowski wrote: > > On Wednesday 31 of December 2008 16:57:12 Ciaran McCreesh wrote: > > > Gentoo does not comply with the FHS. It was established a long time > > > ago that FHS is considered silly and any compliance is merely > > > because the FHS people somehow managed to avoid screwing that > > > particular area up. > > > > Well, we're not here to deliberate about people's taste in FHS > > silliness manner. FHS, being standard de-facto, following the > > definition of the word "standard" as something accepted by majority > > and thus promised to be respected. Not justified standard violations > > or justified by "I don't like it" or "It's silly" should be repressed > > and some good standards should be explicitly forced in my opinion. > > Otherwise, inconsistency will create the feel of mess. I believe we > > can agree on this. > > You could use the same argument to say "Gentoo must switch to RPM > because LSB says so". No, I would be invalid argumentation - I know it - you know it, so let's not continue with discussion of this kind until one side will EOT seeing it's pointless, while the other side will secretly announce epic victory ;) It's not the point to blindly follow freedesktop or LSB - the point is to consistently follow one standard across whole distribution - if it's FHS - fine, if not - fine as well - but *only one* at a time. That being said I'd rather propose to force Gentoo news to comply to FHS as FHS is the most commonly used file/directory layout in Gentoo. cheers in new year -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] reorganization of /var/lib gentoo-related files
On Thursday 01 of January 2009 22:03:55 Ciaran McCreesh wrote: > No, FHS is not the most commonly used layout. The traditional Unix > layout is the most commonly used layout. So.. why not blindly use Unix layout everywhere instead (for Gentoo news as well) On Thursday 01 of January 2009 22:37:28 Alistair Bush wrote: > I actually agreed with Ciaran on this point. especially seeing I would > like us to follow the parts of LSB that make sense within the Gentoo > ecosystem. (take Init Script Actions as an possible example > http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-ge >neric/iniscrptact.html). So, you agree with Mr Ciaran on that FHS is silly or on blindly following *every* LSB standard being silly? Great, but I wasn't suggesting any of this, I just suggested to pick any standard (most commonly used in Gentoo already), and *only one* and blindly follow it to avoid inconsistency. In such scenario, please elaborate what is your point really. >> It's not the point to blindly follow freedesktop or LSB - the point is to >> consistently follow one standard across whole distribution - if it's FHS >> - fine, if not - fine as well - but *only one* at a time. > > That being said I'd rather propose to force Gentoo news to comply to >> FHS as FHS is the most commonly used file/directory layout in Gentoo. > This really is bikeshedding.. Isn't consistently following a > standard also blindly following it. So when you ask us to consistently > follow FHS why not ask for us to blindly follow it. > Man this is getting boring. Yes, you're right. Let everyone follow his own standards - everyone likes spaghetti afterall... (just look at eclasses/ebuilds in you're uncertain) No, it's not bikeshedding, it's misunderstanding the sentence. Consistently following *some* standard is blindly following *the same* standard, but consistently following *some standard* is *not* blindly following LSB nor is blindly following FHS. See the difference? So to make it all clear once again and for the last time - I would rather propose to force Gentoo news to comply to existing the most commonly used file/directory hierarchy structure in Gentoo distribution. cheers -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] reorganization of /var/lib gentoo-related files
On Thursday 01 of January 2009 23:15:20 Ciaran McCreesh wrote: > On Thu, 1 Jan 2009 23:07:08 +0100 > > So.. why not blindly use Unix layout everywhere instead (for Gentoo > > news as well) > We do. /var/lib/gentoo/news > Seriously, find something useful to change. I realise it's hard around > here to get anything major done, but all going around trying to change > the colour of the door handle on the bikeshed does is make life harder > for those people who are doing something useful. I'm just commenting on someone's thread and giving counter proposal. And at least I'm not derivating the topic to non-topic specific areas and I'm not polluting mailing list with general non meritorical ideas as some are, am I? cheers & EOT -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/anki: anki-0.9.9.5.ebuild metadata.xml ChangeLog
On Thursday 15 of January 2009 09:12:12 Christian Faulhammer wrote: > Hi, > > "Heath Caldwell (hncaldwell)" : > > + > > + Enable support for LaTeX > > + > > You only have to add flags to metadata.xml, that are not in > use.desc...and USE=latex is there with a similar description as yours. I would disagree here. I found considerable amount of packages in portage with less than specific "Add support for XML files" as USE=xml description. While it may be by someone considered *similar* to "Enable XML support via libxml library", I found it more than confusing, as XML support is enabled in some packages anyway (as those packages just use only XML files for configuration), in some cases if may not be even remotely related to libxml. That being said, I would rather suggest adding always *precise* and *non- general* USE flags descriptions even for global USE flags (actually especially for them) as I usually found it pretty much necessary to look up ebuilds to get to know what does particular USE flag actually do, and I guess this should be avoided at all cost, especially when it does not cost a penny as maintainer actually already knows what's all about with those USE flags for particular package. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: package.mask
On Thursday 15 of January 2009 05:24:41 Donnie Berkholz wrote: > So if you want to know both, you need to look in 2 places? That doesn't > seem very nice to me. Also in a distributed VCS, we'd want to generate > ChangeLogs from the commit logs to avoid all kinds of annoying conflict > resolution and remove redundant information. Hmm... or the other way around, so that, after making changes, echangelog would generate ChangeLog entry, then repoman manifest, and at the end repoman commit could just pick this entry and place as commit message. It would of course make sense when all commits were 'atomic' in some way - (one commit per package/directory - if there's no such policy already). -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RDEPEND definition in docs differ from official PMS specs
On Sunday 18 of January 2009 16:21:57 Ciaran McCreesh wrote:
> And yes, I'd really like to see this killed for EAPI 3. Ideally we'd go
> with a single DEPENDENCIES variable with labels of some kind,
> something like:
>
> DEPENDENCIES="
> build:
> foo/bar
> build+run:
> foo/baz
> post:
> foo/plugin"
>
> which would make it much easier to start specifying dependencies for
> use of ROOT properly in the future -- it'd just be new labels, not
> zillions of new variables.
What's the benefit of changing syntax so dramatically? (apart from the sake of
changing it to someone's liking) and what's so wrong with zillion of separate
dependency variables? Are they too easy to read, implement and understand?
As everyone knows, to avoid copy&paste one can easily use such scheme:
COMMONDEPEND="
somedep
someotherdep
someuse? ( conddep )
"
DEPEND="${COMMONDEPEND}
somebuilddeponly
"
RDEPEND="${COMMONDEPEND}
someruntimedeponly
"
Similar simple bash play can be used for other purposes as well.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] new categories: (was: Last Rites: games-puzzle/ksudoku)
On Monday 02 of February 2009 22:15:53 Luca Barbato wrote: > not sure how useful could be but could make more sense even if right now > kde-base contains everything comes from the main kde distribution. To be more specific, kde-base contains everything (and only) that is distributed as KDE stable release (no extragear included). And it causes confusion as when packages are dropped from KDE release schedule (so they usually go back to extragear to release when they want), one needs to look to new place for them (in kde-misc or somewhere else). Actually categories are bad idea imho. I was thinking, maybe it would be possible to drop categories completely in the future (maybe keeping symlinks for compatibility and to ease migration) and to put *all* packages in one directory - that would require making all names unique of course. "Categorization" could be provided for user/search tools as tag clouds being defined in metadata.xml as vector of tag:weight values where tag would be some word from defined dictionary (word like "mail" "client" "kde" "dns" or sth) and weight - real value [0,1] defining how relevant is that tag. For compatibility's sake symlinks could be provided, in.ex. sys-devel/gcc -> all/gcc. But that's just an off-topic. -- regards MM -- Nie boj sie przyszlosci! Zapytaj wrozke >> http://link.interia.pl/f2049
Re: [gentoo-dev] Packages up for grabs
On Saturday 31 of January 2009 08:54:07 Donnie Berkholz wrote: > and... > > The system-config-* collection > -- [snip] > app-admin/system-config-printer > dev-python/pycups Those two I'm maintaining in kde-testing overlay as they're prerequisites for kde4 printing administration. So if anyone is interested in babysitting them, one can contact me (reavertm) on #gentoo-kde and grab those packages from overlay (new version bumps) - they could be put in tree and unmasked for better testing. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Category tags on packages (was: new categories:)
On Sunday 08 of February 2009 19:51:29 Tiziano Müller wrote: > It's metadata-stuff, why not put it there? > > You have two possibilities: > > a) Introduce new elements: > > foo > bar > > > b) Think of herds as tags, then you have many packages already tagged. > To be able to add new herds/tags without messing up with the > maintainer-info, I'd then introduce new attributes for and > instead of writing foo meaning that a package is maintainer > by team "foo" just write foo > instead. > Then you can use the "herd" element in metadata.xml freely as a tag. That's basically exactly what I've proposed, I'd just add (possibly optional) weight or relevance of tag as well, for example: foo bar as one cannot forget that tag search is *vector*, not binary search - so there are more possibilities to explore. Btw, too bad, metadat XML schema is written in DTD and not in some easier to read more expressive way - like RelaxNG. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] global useflags
On Tuesday 24 of February 2009 00:22:39 Josh Sled wrote: > To that end, please allow me to suggest: > "Cross-KDE support for file metadata indexing via nepomuk and soprano." > > If you don't want to couple the message to those particular packages, > then maybe just reference the "NEPOMUK project" instead. Then maybe: "Cross-KDE support for semantic search and information retrieval." As for particular packages, there are more of them (strigi is quite important for example), so maybe it's better to not specify any of them as suggested. > (Also, I note in passing the existing kde-base/pykde4 use.local.desc has > a tyop of "Nemomuk".) Good catch, source of this issue was in metadata.xml in overlay. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: LC_ALL=C Set by default for portage
On Monday 09 of March 2009 01:36:52 Mike Frysinger wrote: > > Plz fix the bug [1] > > > > [1] - http://bugs.gentoo.org/show_bug.cgi?id=166730 In my opinion it's nowhere near locale specific bug, unless user sets PORTAGE_TMPDIR to some path containing UTF-8 character beyond ASCII and having broken locales in system. The problem is mainly that such build logs are barely helpful when localized in some funny way. > it's not entirely clear this is a locale specific bug considering other > people say they hit it with en_US.UTF8. that's the locale i use and ive > never hit that problem. Agreed. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3
On Monday 09 of March 2009 22:36:33 Ciaran McCreesh wrote: > On Mon, 9 Mar 2009 22:33:11 +0100 > > Christian Faulhammer wrote: > > Ciaran McCreesh : > > > Next, some probably easy but long standing features: > > > > > > * src_test run unless RESTRICTed or explicitly disabled by the user > > > (bug 184812) > > > > A big no. This will lead to many failures on user systems, people > > who run stable will be greatly annoyed. I know this is inspired by > > good intentions, but will not have the desired effect. > > People who run stable won't see test failures, because developers and > arch testers and ~arch users will all have run the tests already and > made sure there aren't any failures. And if there *are* failures that > make it past all three levels of checking before stable, they really > need to be investigated -- chances are they're showing a legitimate > problem. Unfortunately upstream tends to think of tests in very relaxed way. Some critical packages, like openssl are thoroughly tested for regressions and are already supplied with complete unit test modules. There's unfortunately the problem with let's call them "desktop" packages, where having test suite compile at all (not talking about running it successfully) can be considered luck. What are packagers supposed to do in such case? - hold the package in stasis in some overlay and push upstream to fix the issue they're probably not willing/understaffed to - when fixed - push to tree? - fix test suit by themselves? - RESTRICT=test in affected package? It all depends on what one tries to achieve. I'm quite certain that user of average distribution (even source based) is not particularly interested in *actively* participating in software testing process with all consequences like not getting something built just because some minor unit test failed for him. That kind of package maintenance should be left *only* for packagers imho (if not taken care of upstream developers already). Also the problem is with numbers - such global change (like enabling src_test stage for every package by default unless restricted) will immediately affect all packages in tree. Thus I wouldn't recommend converting user environments into tinderbox. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Developer Retirements
On Tuesday 10 of March 2009 16:29:56 Alec Warner wrote: > > With some devs reviewing gentoo-commits@, I highly doubt that this commit > > could go unnoticed more than a few hours. > really? cause I bet I could slip something in; now I'm motivated to try ;p I somewhat share the view that's rather easy to slip some parts in stream of commits. Would it be possible to introduce some kind of *commit*/*ebuild* *reviewing* *system*? So that every change to tree would need to be somewhat approved by anyone else - just to provide extra pair of eyes to catch early some silly, obvious, unnecessary or very tricky parts of code. It could be quite cheap to introduce and yet not-demotivating step to increase overall quality. I bet it's a practice already by some developers but it would be nice if it could be introduced as a rule for everyone (possibly requiring some GLEP). Personally I don't find it at all humiliating if someone is capable of QA my code - I actually very appreciate it, and I guess most developers do. Should I start separate thread? -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] devs on IRC (was :Regen2 ( was QA Overlay Layout support ))
On Wednesday 11 of March 2009 19:06:33 Thilo Bangert wrote: > my complaint isn't about people using IRC. i object to the way that much > of our knowledge, discussion and decision making process appear to have > been moved into the temporal black hole that is IRC. > realtime communication is an valuable tool, but IRC has drawbacks as well. > this is alienating a lot of people who dont happen to be on IRC at the > right moment/timezone or who dont have the time to be always on. > it looks like many projects within Gentoo have resorted to a communication > process which uses IRC exclusivly. this is unfortunate... Hard to disagree with this. I observed it myself - when I started maintaining ebuilds in overlay, consequently I started to use IRC to be in touch with the rest of KDE Gentoo team. Unfortunately it has some drawbacks like less my availability on forums (and I used it much more often) - to the point that I forgot to update whole 4.2 release announcement in Desktop Environment (in that sticky "Read before posting" thread). IRC is black hole definitely and from developers point of view everything looks just, as they actively communicating with each other - unfortunately being somewhat isolated from the rest of the world. This may increase that feeling from typical user point of view - that developers are somewhere there cooking something, and there's no way to get to them (unless they find about IRC). This is the problem as most users used to sweep forums first as it's "medium" available for them out of the box - just google for some problem and there you are. Now, important. While I don't propose for developers to visit forums - it may be another *solution*. Developers - they (we/you) already chosen IRC as best/fastest/favourite medium for communication apart from mailing list that is - it could stay that way. Why not integrate more users by creating *Support* *staff* role? They could be recruited as typical staff (like moderators) - using staff quiz. Their "job" would be to: - wander on forums answering user questions - poke developers on IRC with some issues (maybe proposed patches) - filling bugzilla bugs (they'd need some *basic* bugzilla knowledge - just to be able to find whether are such issues already and to properly, descriptively create new bug) - not full bugwrangling with assigning and such - provide living evidence that "Gentoo is not dying" whatever and has support They could be given @gentoo.org aliases to make them motivated. It would be easier for those alike to become developers later. There's thread related to user contribution on forums - as reference: http://forums.gentoo.org/viewtopic-t-702248.html (this should rather be discussed on gentoo-project I guess, but nm) -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
No idea whether it's "fast" idea, but:
- USE flags aliases
This could solve problems with USE flag name changes and breaking dependency
tree because of it.
Placed, let's say in profiles/{use.aliases,use.local.aliases}
example - use.aliases: (no idea whether global aliases are really needed)
# - ...
xml - libxml2
example - use.local.aliases: (more real-world scenario)
# - ...
dev-libs/soprano:sesame2 - java
media-video/transcode:dvdread - dvd
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 3 PMS Draft
On Monday 16 of March 2009 21:47:17 Ciaran McCreesh wrote: > I've got a very rough draft of what EAPI 3 might end up looking like, > based upon discussion: [cut] Nice work. To avoid further confusion I'd suggest removing all traces of kdebuild- format and its features (like PDEPEND labels, ranged dependencies) from PMS document, especially its references to Gentoo KDE project. It has not been accepted thus should not exist in "Gentoo PMS" document. > * RDEPEND=DEPEND is still in. Again, was a decision reached? Imho it would be about time to kill implicit build time dependency assignment. -- regards MM -- Udar sloneczny prezesa Kaczynskiego... >>> http://link.interia.pl/f2083
Re: [gentoo-dev] please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On Sunday 22 of March 2009 18:18:15 Ulrich Mueller wrote:
> > On Sun, 22 Mar 2009, mrness wrote:
> > Please do not apply patches that have ${P} prefix in other ebuild
> > versions than ${PV}.
> > Is that hard to create a new patch with a proper name?
> And multiply number and total size of files in ${FILESDIR}?
I guess it may be possible to drop P (or replace with PN) from patch file
names, to make it more obvious which patches should apply with which package
version.
Also, I'd like Tomáš Chvátal (scarabeus) to finally propose his GLEP or just
post it for discussion here as it's related to patch files management and
provides naming scheme - it would address this issue as well as separate
upstream patches from Gentoo specific ones in FILESDIR (and good thing is it's
backward compatible and it doesn't need any EAPI revbump that would inevitably
cause pointless discussion).
--
regards
MM
--
10% zysku na lokacie bankowej z gwarancja BFG. Sprawdz!
http://clk.tradedoubler.com/click?p=74281&a=1586724&g=17879004
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Wednesday 25 of March 2009 15:19:36 Ciaran McCreesh wrote: > > Being rude doesn't make you cool. (Nor make your points more > > effective) > > That's not being rude. [...] (no comment) > so you're doing them a > discourtesy by wasting their time by repeatedly posting ideas you > haven't thought through [...] Considering average post count and Gentoo membership on that list, I'm pretty convinced you're not entitled to decide who is wasting developers' time. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] blocking mixed versions of split QT libraries
On Monday 18 of May 2009 16:52:19 Ciaran McCreesh wrote: > On Mon, 18 May 2009 17:47:52 +0300 [snip] > The definition of soft behaviour allows soft blockers to be treated > identically to hard blockers. We had to do it this way because > Portage's rules for soft blockers are too fuzzy and arbitrary to turn > into a formal specification -- they were a "code first, think later" > solution with which we can't do anything useful. Not sure who is 'we' there, but Portage team already made is useful. Basic portage rule for soft-blocks behaviour is "no longer referenced (a'ka 'soft') blocked package can be uninstalled cleanly without user intervention" - it's well defined behaviour and possible subject of formal specification - it's just up to PM to implement block resolution algorithms for corner cases (those would not be the subject of formal specification of course, it's just an implementation detail like whether to apply rule like order set by '||' operator takes precedence over '!' block or order of block appearance in RDEPEND sets block precedence) - Zac did good job there saving users (especially KDE users) from nightmare of handling all package refactoring/blocks manually. -- regards MM -- Oryginalne przepisy na grilla. Zaskocz swoich gosci! Sprawdz >>> http://link.interia.pl/f217c
Re: [gentoo-dev] blocking mixed versions of split QT libraries
On Monday 18 of May 2009 19:26:58 Ciaran McCreesh wrote: > On Mon, 18 May 2009 19:15:59 +0200 > > Maciej Mrozowski wrote: > > Not sure who is 'we' there, but Portage team already made is useful. > > Basic portage rule for soft-blocks behaviour is "no longer referenced > > (a'ka 'soft') blocked package can be uninstalled cleanly without user > > intervention" > > That's not in the least bit well defined, and it's also extremely > dangerous. Please elaborate on that. (to make it simple, let me use portage terminology below) Everything what user should be interested in is expected to be in 'world' file or 'world_sets' or pulled as dependencies. This I define by "referenced". Everything else like things installed temporarily, no longer pulled packages, are subject of 'depclean'. I don't see why pruning those you consider extremely dangerous - especially when there are parameters like --pretend or --ask. While "no longer referenced" term may be considered not fully defined as it does not specify the way things become not referenced anymore (as packages may be determined to be referenced later, during block resolution stage, but that's implementation specific) - the term "referenced" is defined well enough. Nobody is (for now) expecting every PMS compliant package manager to return identical dependency graph in corner cases. > > Zac did good job there saving users (especially KDE users) from > > nightmare of handling all package refactoring/blocks manually. > > The nightmare only existed because of abuse of that feature. Had blocks > kept their original meaning, people would not have abused them to the > same extent. Unfortunately in packaging of dynamically developed applications like whole KDE environment (with Gentoo KDE split package policy - ~250 ebuilds with every release) it's impossible not to 'abuse' blocks - either to handle file collisions issues, or removed/moved libraries (by upstream). Not sure what was original meaning of blocks you're referring to, either way - there is no rule stating ">= N uses of feature X in scope Y in time frame T is considered abuse" - that being said, I'm surprised you're looking for cheap excuse for providing no working block auto-resolution mechanism (or maybe there is some I'm not aware of) - it does not need to be in any Gentoo specification after all - just to make things easier for users. -- regards MM -- Zrob sobie prezent. Wygraj nagrode! Sprawdz >> http://link.interia.pl/f2176
Re: [gentoo-dev] rfc: Accessibility on our release media
On Sunday 24 of May 2009 01:14:57 Andrew Gaffney wrote: > On 05/23/2009 05:56 PM, Mounir Lamouri wrote: > > William Hubbs wrote: > >> [snip] > >> My question for the group is, how do you feel about speech software > >> being on our minimal cd as well as our live cd? > > > > I agree, it should be in our minimal and live CD's. There is no reason > > to consider blind persons out of the minimal CD. > > The real issue here is the size. If these additional packages plus all of > the alsa modules add 20MB to the minimal CD, it's just not worth it. It's > not "minimal" anymore. Is it the problem with those additional ~20MiB? If it's about not fitting anymore on "minimal" release media - then it's not the problem - it will still be able to fit on ~128MB memory sticks and 3,5" ~210MB cd's. And if it's going to make Gentoo accessible for those handicapped in some way - why not? (Not sure how they actually manage to set up Gentoo with "no monitor" - even with speech engine on terminal - I just couldn't - most respect for them). -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New eclass proposal: auto-export
On Wednesday 22 of April 2009 15:35:37 Petteri Räty wrote:
> Here's an eclass proposal to wrap EXPORT_FUNCTIONS with auto detection
> of functions. This way all eclasses don't have to duplicate the EAPI
> detection code. If people find this useful, I will document it properly
> with eclass-manpages etc.
I like the idea, I'd have some feature request regarding it.
I'd like to have global eclass-wise EXPORT_FUNCTIONS variable introduced in
ebuilds (functions and variables can have identical names, bash handles it)
with list of allowed phases to export for all inherited eclasses.
It's needed in cases when eclass global scope is needed (for some setup for
example, setting SLOT etc) but overriding phases is not desired.
Currently it seems to be needed to override every not needed phase with dummy
phase_function() {
:
}
It means overriding all src_* phases if no ${S} is present.
With proposed solution, there would be for example:
in ebuild:
EXPORT_FUNCTIONS="pkg_setup pkg_postinst pkg_postrm"
inherit kde4-base
[...]
in eclasses there would be autoexport code
autoexport.eclass would need to be tweaked to export only those defined phases
that are listed in EXPORT_FUNCTIONS if EXPORT_FUNCTIONS is not empty
That would disable overriding not wanted phases all way down (provided all
eclasses all way down use autoexport that is).
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Policy regarding enabling IUSE defaults application in ebuild
Hi I'd like to raise your attention on problem of in my opinion overusing IUSE defaults in various packages. Currently there seems to be no policy whatsoever at least advising when it's appropriate to add + and when not, so it's just up to developer's taste. While it usually doesn't do any particular harm (but I guess security and prefix/alt team won't agree on this) - insanely enabling everything by default is not the best idea in my opinion. Of course we need an example. Let's have a look at latest stable media- video/mplayer-1.0_rc2_p20090322 ebuild: IUSE="3dnow 3dnowext +a52 +aac aalib +alsa altivec +amrnb +amrwb arts +ass bidi bindist bl +cddb +cdio cdparanoia -cpudetection -custom-cflags -custom-cpuopts debug dga +dirac directfb doc +dts +dv dvb +dvd +dvdnav dxr3 +enca +encode esd +faac +faad fbcon ftp gif ggi -gtk +iconv ipv6 jack joystick jpeg kernel_linux ladspa libcaca lirc +live lzo mad md5sum +mmx mmxext mng +mp2 +mp3 musepack nas +nemesi +network openal +opengl oss png pnm pulseaudio pvr +quicktime radio +rar +real +rtc -samba +schroedinger sdl +speex sse sse2 ssse3 svga teletext tga +theora +tremor +truetype +unicode v4l v4l2 vdpau vidix +vorbis -win32codecs +X +x264 xanim xinerama +xscreensaver +xv +xvid xvmc zoran" Personally I'd really like to hear some explanation from maintainers about the reasons mplayer needs all those dependencies or why they are *really* recommended for every user of *any* profile (let me remind this). But thats's not the point - the point is, Gentoo probably needs some policy to advise, when some newly added USE flags are appropriate to be enabled by default. I suggest as follows: - When newly added USE flag makes already provided feature optional - needs to be enabled by default (this is required to make package feature set somewhat invariant after update) - When newly added USE flag adds new feature that is considered very common (that's tricky part and decision should be always made by herd, not individual developer) *but* *does* *not* *pull* *any* *dependencies* - enable by default - in any other case *do* *not* *enable* by default - (why? because "I use it so I'll enable it by default" is not enough of an explanation) What's the opinion on that? I guess we need some policy or at least some suggestion mentioned in devmanual - really.. -- regards MM signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Global use flags eabled by default
Hello Somewhat continuing my battle to reasonably minimise USE flags enabled by default for users, I'd like to ask about one particular commit. Note that there's no commit message and it looks a bit fishy: http://sources.gentoo.org/viewcvs.py/gentoo- x86/profiles/base/use.defaults?r1=1.1&r2=1.1.1.1 It enables considerable amount of USE flags in base profile. I'm most concerned about 'gstreamer' USE flag as it's not needed at all for KDE users (they get xine phonon backend as default and will just cause unnecessary dependency chain). If author of that commit is concerned about Gnome functionality, he could talk with Gnome devs first - besides gstreamer is probably pulled there as dependency so no point really in enabling it as USE flag in base profile. Please remove it. (also 'gtk' is there, why not 'kde' as well? remember we're talking about *base* profile, not *desktop* profile) And my main point is - since we have EAPI=1 (use defaults) and EAPI=2 (use deps, yes, it's time to learn those), sane defaults should be set per package level if possible and respected via use deps. Also this is very related to bug [1] and discussion about it [2]. It would be nice to see some progress on that matter (progress = perl and python dropped from profile, and only enabled for ebuilds when maintainer see it fit). 1. https://bugs.gentoo.org/show_bug.cgi?id=250179 2. http://archives.gentoo.org/gentoo- dev/msg_afe72c138992b6a590120de199ffcc44.xml -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Global use flags eabled by default
On Wednesday 01 of July 2009 17:14:11 Maciej Mrozowski wrote: > Hello > > Somewhat continuing my battle to reasonably minimise USE flags enabled by > default for users, I'd like to ask about one particular commit. Note that > there's no commit message and it looks a bit fishy: > > http://sources.gentoo.org/viewcvs.py/gentoo- > x86/profiles/base/use.defaults?r1=1.1&r2=1.1.1.1 > > It enables considerable amount of USE flags in base profile. > I'm most concerned about 'gstreamer' USE flag as it's not needed at all for > KDE users (they get xine phonon backend as default and will just cause > unnecessary dependency chain). > If author of that commit is concerned about Gnome functionality, he could > talk with Gnome devs first - besides gstreamer is probably pulled there as > dependency so no point really in enabling it as USE flag in base profile. > > Please remove it. > (also 'gtk' is there, why not 'kde' as well? remember we're talking about > *base* profile, not *desktop* profile) Sorry about confusion. That ^^^ part - it's typical pebkac. I had it enabled somewhere in package.use (hard to spot in multiple files). The second part with perl / python is still valid though. > 1. https://bugs.gentoo.org/show_bug.cgi?id=250179 > 2. http://archives.gentoo.org/gentoo- > dev/msg_afe72c138992b6a590120de199ffcc44.xml Judging from positive responses, it's just the thing that can be done. grep -rHe "built_with_use.*\(python\|perl\)" /usr/portage (courtesy of Nirbhbeek) will generate remaining packages to be fixed. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Deprecate EAPI1?
On Monday 12 of March 2012 01:49:35 Brian Harring wrote: > On Sun, Mar 11, 2012 at 04:14:33PM +0100, Ch??-Thanh Christopher Nguy???n wrote: > > Ciaran McCreesh schrieb: > > >> Is there really much of a benefit to this? I guess for anybody who > > >> runs scripts to mass-manipulate ebuilds it might be helpful, but I > > >> think all the package managers planned on supporting all the EAPIs for > > >> quite a while longer. > > > > > > We have to support them indefinitely. It's not possible to uninstall a > > > package whose EAPI is unknown. > > > > Would it be feasible to do a pkg_pretend() check and refuse > > install/upgrade if packages with unsupported EAPI are detected? > > The question should be "is it worth doing it", rather than "can we > hack out something". > > As Ciaran said, PM's are going to be supporting EAPI1 indefinitely In principle, it's actually entirely possible for any PM to start supporting exclusively completely API and ABI-breaking EAPI. There's always the problem with self-upgrading software as it needs to somehow predict (and limit) its development to keep upgrade paths. We have this exact problem where I work (with updating basestation SW) and some solution for this software is to stop being self-upgrading. With external upgrade tool (which would rsync package tree do any vdb/metadata-magic needed) one could replace current PM with latest, API/ABI- incompatible PM version. Now, it may not really make sense for PM as upgrade process of PM itself isn't any different from upgrade process of any other package, still it would allow any API/ABI-breaking ebuild format changes to be introduced if we really need them so badly. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] skel.ebuild cosmetics (move RESTRICT after DEPEND)
On Monday 07 of May 2012 10:32:45 Samuli Suominen wrote: > On 05/07/2012 02:24 AM, Ulrich Mueller wrote: > Therefore I suggest we move this example a bit down in skel.ebuild > as it's more logical to continue with new lines instead of applying > in-between > > Any objections? > >>> > >>> Yes. Please leave it as it is. > >> > >> Yeah, I will if someone has a (good) argument for doing so. > > > > RESTRICT and PROPERTIES are on a single line and it's natural to add > > them to the second group of such variables, namely LICENSE, SLOT, > > KEYWORDS, and IUSE. > > > > Whereas DEPEND and RDEPEND typically extend over several lines; > > sometimes they are quite long. So, a RESTRICT line placed after > > *DEPEND will be much more easily missed than in its current place. And I use quite different 'rule' where to place variables: - to separate frequently changed ones (KEYWORDS, IUSE) with rather invariant ones (SLOT, LICENSE) Rationale: It generates smaller diffs (and less conflicts when doing semi-automatic merges of ebuild changes between branches as those are likely both IUSE and KEYWORDS changes, KEYWORDS changes are rarely desired to be included in merge, if IUSE is just below the line with KEYWORDS, KEYWORD change will be accidentally taken in) -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] supporting static-libs
On Tuesday 28 of August 2012 02:15:40 hasufell wrote: > Is there a reason not to support static-libs in an ebuild if the package > supports it? > > It seems some developers don't care about this option. What's the gentoo > policy on this? Isn't this actually a bug? A little remark. For CMake controlled buildsystem (as you're coming here from latest dev- games/simgear), there's no automatic way of building both static and shared libs (simgear allows to choose just one). This is why I removed static libs support that you proposed for dev- games/simgear (similar to ruby eclass abi handling - manually calling phases twice to build package 1st as shared, 2nd time as static). This is what I called "not worth the effort" in private discussion with you, not quite "I don't care for static libs" :) -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] supporting static-libs
On Thursday 06 of September 2012 10:18:34 Brian Harring wrote:
> On Mon, Sep 03, 2012 at 10:54:15PM +0200, Maciej Mrozowski wrote:
> > On Tuesday 28 of August 2012 02:15:40 hasufell wrote:
> > > Is there a reason not to support static-libs in an ebuild if the
> > > package supports it?
> > >
> > > It seems some developers don't care about this option. What's the
> > > gentoo policy on this? Isn't this actually a bug?
> >
> > A little remark.
> > For CMake controlled buildsystem (as you're coming here from latest dev-
> > games/simgear), there's no automatic way of building both static and
> > shared libs (simgear allows to choose just one).
> > This is why I removed static libs support that you proposed for dev-
> > games/simgear (similar to ruby eclass abi handling - manually calling
> > phases twice to build package 1st as shared, 2nd time as static).
> > This is what I called "not worth the effort" in private discussion with
> > you, not quite "I don't care for static libs" :)
>
> Guessing in the worst case, you can do a double compile to get around
> this, no? And yes, that's freaking horrible, just verifying cmake
> isn't doing something special that blocks it.
Not sure why they would need to block it, one build dir for static, second one
for shared. All safely separated (still stinks as a hack).
> Is upstream doing anything about this, or is it not on their
> radar/list-of-things-they-care-about ?
Off the radar.
CMake provides equivalent of '--enable-static --disable-shared' and '--
disable-static --enable-shared' by the means of BUIlLD_SHARED_LIBS and not
specifying linkage when defining library:
add_library(foo src1 src2)
It doesn't automatically provide both at the same time however. CMake is
cross-platform (meaning it support different generators: GNU Make, NMake,
Visual Studio Project, XCode etc) so their main audience aren't "distros",
also on Windows for instance when shared .dll is created, also import .lib is
created. If static .lib was to be created as well, they would need to have
separate build subdir for it (and a bit more complex library resolution
algorithm).
Still, if developer bothers enough to provide them both, he can easily
implement it in buildsystem with explicitly given linkage (and separate target
names):
set(foo_SRC src1 src2)
add_library(foo SHARED ${foo_SRC})
if (ENABLE_STATIC)
add_library(foo_static STATIC ${foo_SRC})
endif ()
That being said I can understand why it's off the radar - technically
everything is already available, likely not worth the effort and in many cases
building both static/shared is actually not needed.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On poniedziałek, 30 stycznia 2017 14:04:06 CET William Hubbs wrote: > All, > > I have been looking at the meson build system [1] [2], and I like what I > see. > > I have opened an issue on OpenRC's github wrt migrating OpenRC to the > meson build system [3]. > > As I said on the bug, the downside is the addition of py3 and ninja as > build time dependencies, but I think the upside (a build system where > we don't have to worry about parallel make issues or portability) > outweighs that. > > What do folks think here? I'd recommend to jump a bandwagon and switch to CMake. Yes, it's ugly in certain areas, has its quirks but whoever switches to it ones, never goes back, and not because of technical debt being too big. Also because I can help with it (and a lot of folks can), while Meson is still largely unknown. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Reminder: ALLARCHES
On Saturday 30 of April 2016 23:16:42 Andreas K. Huettel wrote: | Hi all, | | just as a small reminder, to ease the load on all arch teams: | | If a stablerequest has the keyword ALLARCHES set, then | * the first arch that tests successfully and stabilizes | * can and *should* immediately stabilize for all requested arches! | | Whether this keyword is set on a bug is decision of the package maintainer. | | For example, Perl team sets ALLARCHES normall for all pure-perl packages | (i.e., no compilation / gcc involved). | | Here's an example how this was used: | https://bugs.gentoo.org/show_bug.cgi?id=578408 | https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=44c2d31dfc61bb3e2aee370 | 9cb5a784b213511fa Going further, perhaps introducing something along the lines of 'noarch' to KEYWORDS syntax would solve the problem in long run? Or do we really need to have fine grained control over packages visibility even for those that are really processor architecture agnostic? regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Reminder: ALLARCHES
On Monday 02 of May 2016 16:43:01 you wrote: | On Saturday 30 of April 2016 23:16:42 Andreas K. Huettel wrote: | | Hi all, | | | | just as a small reminder, to ease the load on all arch teams: | | | | If a stablerequest has the keyword ALLARCHES set, then | | * the first arch that tests successfully and stabilizes | | * can and *should* immediately stabilize for all requested arches! | | | | Whether this keyword is set on a bug is decision of the package | | maintainer. | | | | For example, Perl team sets ALLARCHES normall for all pure-perl packages | | (i.e., no compilation / gcc involved). | | | | Here's an example how this was used: | | https://bugs.gentoo.org/show_bug.cgi?id=578408 | | https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=44c2d31dfc61bb3e2aee3 | | 70 9cb5a784b213511fa | | Going further, perhaps introducing something along the lines of 'noarch' to | KEYWORDS syntax would solve the problem in long run? | Or do we really need to have fine grained control over packages visibility | even for those that are really processor architecture agnostic? Yes, subject was discussed: http://article.gmane.org/gmane.linux.gentoo.devel/63776/match=noarch or http://article.gmane.org/gmane.linux.gentoo.devel/89824/match=noarch but I perhaps it's worth re-revisiting since it's hard to find definitive conclusion to those topics. regards MM signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [RFC] Enable CMAKE_WARN_UNUSED_CLI by default in cmake-utils for EAPI>=6
Hello,
General advise: do not convert ebuilds inheriting cmake-utils to EAPI 6 unless
you know what you are doing (you are fully aware of eclass behaviour removed
with https://bugs.gentoo.org/show_bug.cgi?id=514384).
Background:
Pre EAPI-6 cmake-utils.eclass contained certain feature to mitigate CMake
variable case changes done by upstream.
This feature was explicitly removed with
https://bugs.gentoo.org/show_bug.cgi?id=514384 and no alternative was
proposed.
It opened new area of possible ebuild regression bugs when switching to EAPI-6
for ebuilds inheriting cmake-utils.eclass.
Unfortunately there is common misconception, also among developers, that it's
sufficient to simply replace "${cmake-utils_use_with foo)" with "-DWITH_foo=ON"
etc.
This is MOST OF THE TIME not the case.
When converting cmake-utils ebuild to EAPI>=6, one needs to consult
CMakeLists.txt wrt case each variable is written with since CMake is case-
sensitive and WITH_FOO != WITH_foo != WITH_Foo.
Proposal:
CMake allows warning about unused CMake variables passed by CLI. Since this is
how Gentoo passes ebuild configuration options, it's proposed to enable this
feature.
Unfortunately it won't fail compilation but at least it gives a chance to spot
case mismatch when reading build output.
Future thoughts:
For better damage control it's technically possible to extend configure phase
of cmake-utuls eclass to check mycmakeargs against parsed package buildsystem
but this might not be very reliable.
regards
MM
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: [RFC] Enable CMAKE_WARN_UNUSED_CLI by default in cmake-utils for EAPI>=6
On Monday 02 of May 2016 18:06:44 you wrote:
> Unfortunately there is common misconception, also among developers, that
> it's sufficient to simply replace "${cmake-utils_use_with foo)" with
> "-DWITH_foo=ON" etc.
Obvious errata, should be:
Unfortunately there is common misconception, also among developers, that it's
sufficient to simply replace "${cmake-utils_use_with foo)" with "-
DWITH_foo=$(usex foo)" etc.
regards
MM
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: [RFC] Enable CMAKE_WARN_UNUSED_CLI by default in cmake-utils for EAPI>=6
On Monday 02 of May 2016 18:13:38 you wrote:
> On Monday 02 of May 2016 18:06:44 you wrote:
> > Unfortunately there is common misconception, also among developers, that
> > it's sufficient to simply replace "${cmake-utils_use_with foo)" with
> > "-DWITH_foo=ON" etc.
>
> Obvious errata, should be:
> Unfortunately there is common misconception, also among developers, that
> it's sufficient to simply replace "${cmake-utils_use_with foo)" with "-
> DWITH_foo=$(usex foo)" etc.
And commited:
diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index ebcb631..427c13f 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -87,7 +87,6 @@ _CMAKE_UTILS_ECLASS=1
# Warn about variables that are declared on the command line
# but not used. Might give false-positives.
# "no" to disable (default) or anything else to enable.
-: ${CMAKE_WARN_UNUSED_CLI:=no}
# @ECLASS-VARIABLE: PREFIX
# @DESCRIPTION:
@@ -113,7 +112,8 @@ _CMAKE_UTILS_ECLASS=1
# Should be set by user in a per-package basis in /etc/portage/package.env.
case ${EAPI} in
- 2|3|4|5|6) : ;;
+ 2|3|4|5) : ${CMAKE_WARN_UNUSED_CLI:=no} ;;
+ 6) : ${CMAKE_WARN_UNUSED_CLI:=yes} ;;
*) die "EAPI=${EAPI:-0} is not supported" ;;
esac
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Enable CMAKE_WARN_UNUSED_CLI by default in cmake-utils for EAPI>=6
On Wednesday 18 of May 2016 09:22:53 Andrew Savchenko wrote:
> On Mon, 02 May 2016 18:06:44 +0200 Maciej Mrozowski wrote:
> > Hello,
> >
> > General advise: do not convert ebuilds inheriting cmake-utils to EAPI 6
> > unless you know what you are doing (you are fully aware of eclass
> > behaviour removed with https://bugs.gentoo.org/show_bug.cgi?id=514384).
> >
> > Background:
> >
> > Pre EAPI-6 cmake-utils.eclass contained certain feature to mitigate CMake
> > variable case changes done by upstream.
> > This feature was explicitly removed with
> > https://bugs.gentoo.org/show_bug.cgi?id=514384 and no alternative was
> > proposed.
> > It opened new area of possible ebuild regression bugs when switching to
> > EAPI-6 for ebuilds inheriting cmake-utils.eclass.
> >
> > Unfortunately there is common misconception, also among developers, that
> > it's sufficient to simply replace "${cmake-utils_use_with foo)" with
> > "-DWITH_foo=ON" etc.
> > This is MOST OF THE TIME not the case.
> > When converting cmake-utils ebuild to EAPI>=6, one needs to consult
> > CMakeLists.txt wrt case each variable is written with since CMake is case-
> > sensitive and WITH_FOO != WITH_foo != WITH_Foo.
> >
> > Proposal:
> >
> > CMake allows warning about unused CMake variables passed by CLI. Since
> > this is how Gentoo passes ebuild configuration options, it's proposed to
> > enable this feature.
> > Unfortunately it won't fail compilation but at least it gives a chance to
> > spot case mismatch when reading build output.
> >
> > Future thoughts:
> >
> > For better damage control it's technically possible to extend configure
> > phase of cmake-utuls eclass to check mycmakeargs against parsed package
> > buildsystem but this might not be very reliable.
>
> For me the real confusion was from this line:
>
> die "${FUNCNAME[1]} is banned in EAPI 6 and later: use
> -D$1${arg}=\"\$(usex $2)\" instead"
>
> It recommends to use ${arg} without any warning about case, so when I just
> copied what it recommends: -DWITH_nls="$(usex nls)", I had a nice surprise
> and fun debugging.
Ah, there you go..
@kensington
Come on, man, you should have known better.
Invalid suggestion removed. Thanks for noticing.
I prefer to have developers figure out the right EAPI-6 migration path
themselves rather than blindly relying on suggestions:
diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 427c13f..5958230 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -161,7 +161,7 @@ _cmake_use_me_now() {
local arg=$2
[[ ! -z $3 ]] && arg=$3
- [[ ${EAPI} == [2345] ]] || die "${FUNCNAME[1]} is banned in EAPI 6 and
later: use -D$1${arg}=\"\$(usex $2)\" instead"
+ [[ ${EAPI} == [2345] ]] || die "${FUNCNAME[1]} is banned in EAPI 6 and
later"
local uper capitalised x
[[ -z $2 ]] && die "cmake-utils_use-$1 []"
@@ -184,7 +184,7 @@ _cmake_use_me_now_inverted() {
[[ ! -z $3 ]] && arg=$3
if [[ ${EAPI} != [2345] && "${FUNCNAME[1]}" != cmake-
utils_use_find_package ]] ; then
- die "${FUNCNAME[1]} is banned in EAPI 6 and later: use -
D$1${arg}=\"\$(usex $2)\" instead"
+ die "${FUNCNAME[1]} is banned in EAPI 6 and later"
fi
local uper capitalised x
regards
MM
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: [PATCH 2/2] cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530
On środa, 2 listopada 2016 04:00:06 CET Maciej Mrozowski wrote:
> ---
> eclass/cmake-utils.eclass | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index 88d2163..f7eac26 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -525,13 +525,13 @@ enable_cmake-utils_src_configure() {
>
> local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
> cat > ${toolchain_file} <<- _EOF_ || die
> - SET (CMAKE_C_COMPILER $(tc-getCC))
> - SET (CMAKE_CXX_COMPILER $(tc-getCXX))
> - SET (CMAKE_Fortran_COMPILER $(tc-getFC))
> SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive
> manager" FORCE)
> SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE FILEPATH
> "Archive
> index generator" FORCE)
> _EOF_
>
> + # Bug 542530, export those instead of setting paths in toolchain file
> + tc-export CC CXX FC
> +
> if tc-is-cross-compiler; then
> local sysname
> case "${KERNEL:-linux}" in
mgorny commented to use local instead:
local -x CC=$(tc-getCC)
...
If no other comments, I'll apply this and commit patches somewhere around next
weekend. Would be nice if someone using some exotic prefix tried this (should
work though, we feed various cross-compilers to cmake via env this way at
work).
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] [PATCH 0/2] cmake-utils small rework + bug 542530
From: Maciej Mrozowski Bummer, let me start it properly again, this time sending to reachable address. Maciej Mrozowski (2): cmake-utils.eclass: CMake argument passing rework - clean build_rules and toolchain_file files from unrelated stuff (pass to CMake directly) - move some invariant CMake options actually to invariants parts - eliminate common_config (pass to CMake directly) for better transparency cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530 eclass/cmake-utils.eclass | 60 +++ 1 file changed, 24 insertions(+), 36 deletions(-) -- 2.7.3
[gentoo-dev] [PATCH 1/2] cmake-utils.eclass: CMake argument passing rework - clean build_rules and toolchain_file files from unrelated stuff (pass to CMake directly) - move some invariant CMake option
From: Maciej Mrozowski
---
eclass/cmake-utils.eclass | 54 ++-
1 file changed, 21 insertions(+), 33 deletions(-)
diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 393ee28..88d2163 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -517,13 +517,10 @@ enable_cmake-utils_src_configure() {
includes=""
fi
cat > "${build_rules}" <<- _EOF_ || die
- SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive
manager" FORCE)
SET (CMAKE_ASM_COMPILE_OBJECT "
${includes} ${CFLAGS} -o -c " CACHE STRING "ASM
compile command" FORCE)
SET (CMAKE_C_COMPILE_OBJECT "
${includes} ${CPPFLAGS} -o -c " CACHE STRING "C
compile command" FORCE)
SET (CMAKE_CXX_COMPILE_OBJECT "
${includes} ${CPPFLAGS} -o -c " CACHE STRING "C++
compile command" FORCE)
SET (CMAKE_Fortran_COMPILE_OBJECT "
${includes} ${FCFLAGS} -o -c " CACHE STRING
"Fortran compile command" FORCE)
- SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE FILEPATH
"Archive index generator" FORCE)
- SET (PKG_CONFIG_EXECUTABLE $(type -P $(tc-getPKG_CONFIG)) CACHE
FILEPATH "pkg-config executable" FORCE)
_EOF_
local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
@@ -531,6 +528,8 @@ enable_cmake-utils_src_configure() {
SET (CMAKE_C_COMPILER $(tc-getCC))
SET (CMAKE_CXX_COMPILER $(tc-getCXX))
SET (CMAKE_Fortran_COMPILER $(tc-getFC))
+ SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive
manager" FORCE)
+ SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE FILEPATH
"Archive index generator" FORCE)
_EOF_
if tc-is-cross-compiler; then
@@ -571,32 +570,29 @@ enable_cmake-utils_src_configure() {
# in Prefix we need rpath and must ensure cmake gets
our default linker path
# right ... except for Darwin hosts
IF (NOT APPLE)
- SET (CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
- SET (CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH
"${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/usr/$(get_libdir);${EPREFIX}/$(get_libdir)"
- CACHE STRING "" FORCE)
-
+ SET (CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
+ SET (CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH
"${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/usr/$(get_libdir);${EPREFIX}/$(get_libdir)"
CACHE STRING "" FORCE)
ELSE ()
-
- SET(CMAKE_PREFIX_PATH "${EPREFIX}${PREFIX}" CACHE
STRING "" FORCE)
- SET(CMAKE_SKIP_BUILD_RPATH OFF CACHE BOOL "" FORCE)
- SET(CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
- SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE CACHE BOOL "")
- SET(CMAKE_INSTALL_RPATH
"${EPREFIX}${PREFIX}/lib;${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/usr/$(get_libdir);${EPREFIX}/$(get_libdir)"
CACHE STRING "" FORCE)
- SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE CACHE BOOL
"" FORCE)
- SET(CMAKE_INSTALL_NAME_DIR "${EPREFIX}${PREFIX}/lib"
CACHE STRING "" FORCE)
-
+ SET(CMAKE_PREFIX_PATH "${EPREFIX}${PREFIX}"
CACHE STRING "" FORCE)
+ SET(CMAKE_SKIP_BUILD_RPATH OFF CACHE BOOL ""
FORCE)
+ SET(CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
+ SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE CACHE
BOOL "")
+ SET(CMAKE_INSTALL_RPATH
"${EPREFIX}${PREFIX}/lib;${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/usr/$(get_libdir);${EPREFIX}/$(get_libdir)"
CACHE STRING "" FORCE)
+ SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE
CACHE BOOL "" FORCE)
+ SET(CMAKE_INSTALL_NAME_DIR
"${EPREFIX}${PREFIX}/lib" CACHE STRING "" FORCE)
ENDIF (NOT APPLE)
_EOF_
fi
# Common configure parameters (invariants)
- local common_config=${BUILD_DIR}/gentoo_common_config.cmake
local libdir=$(get_libdir)
- cat > "${common_config}" <<- _EOF_ || d
[gentoo-dev] [PATCH 2/2] cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530
From: Maciej Mrozowski
---
eclass/cmake-utils.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 88d2163..23cc094 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -525,13 +525,13 @@ enable_cmake-utils_src_configure() {
local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
cat > ${toolchain_file} <<- _EOF_ || die
- SET (CMAKE_C_COMPILER $(tc-getCC))
- SET (CMAKE_CXX_COMPILER $(tc-getCXX))
- SET (CMAKE_Fortran_COMPILER $(tc-getFC))
SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive
manager" FORCE)
SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE FILEPATH
"Archive index generator" FORCE)
_EOF_
+ # Bug 542530, export those instead of setting paths in toolchain file
+ local -x CC=$(tc-getCC) CXX=$(tc-getCXX) FC=$(tc-getFC)
+
if tc-is-cross-compiler; then
local sysname
case "${KERNEL:-linux}" in
--
2.7.3
Re: [gentoo-dev] [PATCH 1/2] cmake-utils.eclass: CMake argument passing rework - clean build_rules and toolchain_file files from unrelated stuff (pass to CMake directly) - move some invariant CMake op
On czwartek, 3 listopada 2016 07:31:10 CET Michał Górny wrote:
> On Thu, 3 Nov 2016 00:52:16 +0100
>
> Maciej Mrozowski wrote:
> > From: Maciej Mrozowski
> >
> > ---
> >
> > eclass/cmake-utils.eclass | 54
> > ++- 1 file changed, 21
> > insertions(+), 33 deletions(-)
> >
> > diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> > index 393ee28..88d2163 100644
> > --- a/eclass/cmake-utils.eclass
> > +++ b/eclass/cmake-utils.eclass
> > @@ -517,13 +517,10 @@ enable_cmake-utils_src_configure() {
> >
> > includes=""
> >
> > fi
> > cat > "${build_rules}" <<- _EOF_ || die
> >
> > - SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive
manager"
> > FORCE)>
> > SET (CMAKE_ASM_COMPILE_OBJECT " $
{includes}
> > ${CFLAGS} -o -c " CACHE STRING "ASM
compile
> > command" FORCE) SET (CMAKE_C_COMPILE_OBJECT "
> > ${includes} ${CPPFLAGS} -o -c
"
> > CACHE STRING "C compile command" FORCE) SET
(CMAKE_CXX_COMPILE_OBJECT
> > " ${includes} ${CPPFLAGS}
-o
> > -c " CACHE STRING "C++ compile command" FORCE)
SET
> > (CMAKE_Fortran_COMPILE_OBJECT "
> > ${includes} ${FCFLAGS} -o -c " CACHE
STRING
> > "Fortran compile command" FORCE)>
> > - SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE FILEPATH
"Archive
> > index generator" FORCE) - SET (PKG_CONFIG_EXECUTABLE $(type -P
> > $(tc-getPKG_CONFIG)) CACHE FILEPATH "pkg-config executable" FORCE)>
> > _EOF_
> >
> > local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
> >
> > @@ -531,6 +528,8 @@ enable_cmake-utils_src_configure() {
> >
> > SET (CMAKE_C_COMPILER $(tc-getCC))
> > SET (CMAKE_CXX_COMPILER $(tc-getCXX))
> > SET (CMAKE_Fortran_COMPILER $(tc-getFC))
> >
> > + SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive
manager"
> > FORCE) +SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE
> > FILEPATH
> > "Archive index generator" FORCE)>
> > _EOF_
> >
> > if tc-is-cross-compiler; then
> >
> > @@ -571,32 +570,29 @@ enable_cmake-utils_src_configure() {
> >
> > # in Prefix we need rpath and must ensure cmake gets
> > our
default
> > linker path # right ... except for Darwin hosts
> > IF (NOT APPLE)
> >
> > - SET (CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
> > - SET (CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH
> > "${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/u
> > sr/$(get_libdir);${EPREFIX}/$(get_libdir)" -CACHE
> > STRING ""
FORCE)
> > -
> > + SET (CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
> > + SET (CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH
> > "${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/u
> > sr/$(get_libdir);${EPREFIX}/$(get_libdir)" CACHE STRING "" FORCE)>
> > ELSE ()
> >
> > -
> > - SET(CMAKE_PREFIX_PATH "${EPREFIX}${PREFIX}" CACHE
> > STRING ""
FORCE)
> > - SET(CMAKE_SKIP_BUILD_RPATH OFF CACHE BOOL "" FORCE)
> > - SET(CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
> > - SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE CACHE BOOL "")
> > - SET(CMAKE_INSTALL_RPATH
> > "${EPREFIX}${PREFIX}/lib;${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/$
> > {CHOST}/lib;${EPREFIX}/usr/$(get_libdir);${EPREFIX}/$(get_libdir)" CACHE
> > STRING "" FORCE) - SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH
TRUE CACHE
> > BOOL "" FORCE) -SET(CMAKE_INSTALL_NAME_DIR "${EPREFIX}$
{PREFIX}/lib"
> > CACHE STRING "" FORCE) -
> > + SET(CMAKE_PREFIX_PATH "${EPREFIX}${PREFIX}"
> > CACHE
STRING "" FORCE)
> > + SET(CMAKE_SKIP_BUILD_RPATH OFF CACHE BOOL ""
> > FORC
Re: [gentoo-dev] [PATCH 2/2] cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530
On piątek, 4 listopada 2016 20:58:23 CET James Le Cuirot wrote:
> On Fri, 4 Nov 2016 13:37:42 +0100
>
> Alexis Ballier wrote:
> > On Fri, 4 Nov 2016 12:33:37 +
> >
> > James Le Cuirot wrote:
> > > On Fri, 4 Nov 2016 13:20:16 +0100
> > >
> > > Alexis Ballier wrote:
> > > > On Thu, 3 Nov 2016 00:52:17 +0100
> > > >
> > > > Maciej Mrozowski wrote:
> > > > > From: Maciej Mrozowski
> > > > >
> > > > > ---
> > > > >
> > > > > eclass/cmake-utils.eclass | 6 +++---
> > > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> > > > > index 88d2163..23cc094 100644
> > > > > --- a/eclass/cmake-utils.eclass
> > > > > +++ b/eclass/cmake-utils.eclass
> > > > > @@ -525,13 +525,13 @@ enable_cmake-utils_src_configure() {
> > > > >
> > > > > local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
> > > > > cat > ${toolchain_file} <<- _EOF_ || die
> > > > >
> > > > > - SET (CMAKE_C_COMPILER $(tc-getCC))
> > > > > - SET (CMAKE_CXX_COMPILER $(tc-getCXX))
> > > > > - SET (CMAKE_Fortran_COMPILER $(tc-getFC))
> > > > >
> > > > > SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE
> > > > >
> > > > > FILEPATH
> > > >
> > > > Have you tested cross compiling ?
> > > > IIRC toolchain file is used *before* getting those vars from env and
> > > > is used to determine system & compiler type. Without this you get
> > > > bugs like #503216
> > >
> > > I was dubious (since I filed that bug) but I briefly tested by
> > > cross-compiling media-libs/openal and it worked. I didn't think to
> > > try older CMake versions though. The behaviour might have changed.
> >
> > could you please send me (in private) build logs with & without the
> > changes please ?
> >
> > (dont have easy access to a x compile setup atm)
>
> I diff'd the logs (needed MAKEOPTS="-j1") and they were practically
> identical, save for the expected change in configure arguments. I also
> tested with CMake 2.8 and that worked too. To further convince myself,
> I took the current eclass and loosely reversed the change we made for
> bug #503216. It failed with CMake 3.6 in exactly the same way it failed
> back then. I am therefore happy for this to proceed. Would you agree?
Env way w/ CMake is used (without toolchain file) where I work for a couple of
years with quite a bunch of exotic cross-compilers so I never doubted it would
work (with toolchain file lacking CMAKE__COMPILER variable).
The only thing surprised me here was CMake handling CC/CXX var multi-param
abuse acceptably.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] The gx86 multilib project -- masterplan
On Sunday 27 of January 2013 19:11:16 Micha³ Górny wrote:
> On Sun, 27 Jan 2013 21:04:14 +0300
>
> Sergei Trofimovich wrote:
> > On Sun, 27 Jan 2013 17:30:22 +0100
> >
> > Micha³ Górny wrote:
> > > On Sun, 27 Jan 2013 16:07:48 +
> > >
> > > Ciaran McCreesh wrote:
> > > > On Sun, 27 Jan 2013 16:12:37 +0100
> > > >
> > > > Micha³ Górny wrote:
> > > > >RDEPEND="dev-libs/libfoo[${MULTILIB_USEDEP}]
> > > > >
> > > > >dev-libs/libbar[ssl,${MULTILIB_USEDEP}]"
> > > >
> > > > This looks like it might be a bit fragile. Is it something better
> > > > addressed by an EAPI extension?
> > >
> > > I have no idea. This one's clear and simple. Not sure how you could be
> > > able to do that better in EAPI.
> >
> > EAPI might allow lib[multiple?][use?][flags?] as an alias of
> > [multiple?,use?,flags?].
> I still don't think that would be really helpful.
>
> dev-libs/libfoo[ssl][${MULTILIB_USEDEP}]
>
> is IMO just more confusing than the usual [ssl,...] -- people start
> thinking 'does it mean something special?'
>
> Unless you mean adding the brackets to the variable itself -- but that
> will be just scary...
>
> dev-libs/libfoo${MULTILIB_USEDEP}
Alternatively, less fragile but more verbose would be eclass function to
produce dependency string. While it may sound as overkill - we already do it
in KDE:
'add_kdebase_dep':
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/kde4-
functions.eclass?view=markup
Example usage:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/kde-
base/pykde4/pykde4-4.9.5.ebuild?view=markup
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: [PATCH 3/3] Convert virtualgl to cmake-multilib.
On Tuesday 05 of February 2013 21:19:24 you wrote:
> +CMAKE_VERBOSE=1
This is already eclass default.
> + abi_configure() {
> + local mycmakeargs=(
> + "${mycmakeargs[@]}"
> + -DVGL_LIBDIR=/usr/$(get_libdir)
> + -DTJPEG_LIBRARY=/usr/$(get_libdir)/libturbojpeg.so
> + -DCMAKE_LIBRARY_PATH=/usr/$(get_libdir)
> + -DVGL_FAKELIBDIR=/usr/fakelib/${ABI}
No no, we should patch CMake instead to avoid doing things like those for
every single ebuild. So to teach CMake to know our libsuffix and such.
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On Thursday 07 of February 2013 06:52:44 Peter Stuge wrote: > Tomáš Chvátal wrote: > > we as gentoo will provide both while preffered default will be what > > major distros use. > > What kind of careless mainstream attitude is that? Really? Quite the opposite, decision to use implementation A over B was taken with utmost care for user in mind. > I mean: You are saying that given two options, Gentoo will do > whatever "major distros" are doing. > > (Never mind that Gentoo *is* a major distro, and whatever Gentoo does > generates collective bias just like whatever any other distro does.) We are not, let's not go too far, please. > Oops, I forgot - that would mean actually having to *get informed* first. > > "We as gentoo" must certainly avoid getting informed at all > cost111oneone > > Are you *really* quite serious? Please explain yourself. > > > If you disagree with that and you don't want your lead to make that > > decision > Hm? Where can I learn more about the "lead" ? So it is a single > person's decision, and not "we as gentoo" that decides? I'd like to > understand how this decision making process actually works. Does > anyone know? It depends - in distro-wide, package-tree-wide matters we have Gentoo Council. In local matters like this - who does the job decides. Tomáš does the job - he decides. > > which you and I both don't want. > > Guess what - I have been on the receiving end of the arguably > insanely lame mainstream attitude that you support, and honestly > > it fucking broke my heart > that people working on Linux distributions (it wasn't just Gentoo, > it was *every* distro) would be so genuinely uninterested in what > happens upstream, especially at a time where a downstream decision > may carry a bit of extra weight. > > I do not want that. > > (Around the time this happened to me I wrote roughly the same in a > private email to developers of another distribution which shall > remain unnamed. I found that email in a pastebin a few days later.) > > > It is long since clear to me that I have much too high expectations > on people. > > But are you *REALLY* not able to do *any* better than "default will > be what major distros use" ? > > Seriously? Seriously you should take a deep breath, walk a dog maybe :) regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Evaluating a new malloc()
On Tuesday 26 of February 2013 11:44:31 Rich Freeman wrote: > On Tue, Feb 26, 2013 at 11:35 AM, Alec Warner wrote: > > I see a *HUGE* reason. glibc ships with ptmalloc. If you think they > > should use jemalloc, talk to them. Don't just do it in Gentoo. > > Certainly I think it would be far more productive to talk to the glibc > maintainers first. You mean productive like below? ;) http://sourceware.org/bugzilla/show_bug.cgi?id=11261 Ulrich Drepper: "Stop reopening. There is a solution for people who are stupid enough to create too many threads. No implementation will be perfect for everyone. The glibc implementation is tuned for reasonable programs and will run much faster than any other I tested." Merge of jemalloc upstream is likely never going to happen. regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Sets in the tree
On Wednesday 14 of August 2013 21:42:35 Michael Palimaka wrote:
| Now that portage-2.2 is in ~arch, we should now be able to add sets to
| the tree.
|
| How should we go about doing this? In some overlays, the repository root
| has sets/{foo,bar,etc} and sets.conf which might look like this:
|
| [gentoo sets]
| class = portage.sets.files.StaticFileSet
| multiset = true
| directory = ${repository:gentoo}/sets/
| world-candidate = True
|
| It might be useful to have a standard header for each set:
|
| # Maintainer: f...@example.com
| # Description: The complete set of all Foo packages
|
| Should everyone be free to add sets at will, or should each addition be
| discussed first, similar to adding new global USE flags?
|
| Anything else to consider?
Discussion about current portage sets was sure to get hot.
I strongly disagree with adding current portage sets to gentoo-x86.
Not because they're not PMS compliant (which is a reason alone) but because
they can be
considered interim solution.
Please refer to Zac's email on why portage-2.2_ was kept masked for that long.
For live rebuilds, there's already proposal:
https://bugs.gentoo.org/show_bug.cgi?id=272488
For proper 'metapackage' replacement (USE flags support, etc), actually there's
also some
idea (Zac's 'PROPERTIES=set'):
https://bugs.gentoo.org/show_bug.cgi?id=182028
In my opinion, we need to _have_ proper sets before we include them in
gentoo-x86.
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] open season on other-dev's packages -- policy change?
On Friday 01 of November 2013 22:13:04 Ciaran McCreesh wrote: | The point is that git makes it super-easy to contribute patches, both | for users and for developers. Well, it's not like one cannot submit patches against portage tree patches already.. And git is only super-convenient when combined with proper review tool, preferably with 'auto-push'. But then again who would honestly 'trust' user-submitted merge request without trying to 'QA'* the package himself? The 'need' to check it myself delays user submissions in my case anyway. (moving to git would likely help with shortening the cycle when combined with having 'overlays' being git clones of official gentoo-x86. I'm afraid however whole 'atomic' tree is just too huge to be practically cloned. Maybe Exherbo-like concept of project-specific git repos would work but splitting gentoo-x86 would sounds like a revolution) * - looking for possible automagic in buildsystem, checking installed filelist regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On Sunday 15 of December 2013 00:13:09 Peter Stuge wrote: | Markos Chandras wrote: | > Please do not let Peter render another thread useless. | | Isn't it obvious that the discussion about forks is both related to | cron *and* useful on its own? I think there's some misunderstanding (or otherwise trolling). There's no discussion as there are no competing forks. There is discontinued (judged by upstream and bug activity) project and there is follow-up project. | It's not really possible to view an entire thread as a single item. | Life is more complicated than that, for good and bad. | | Finally, consider that even if what I write makes you personally | uncomfortable it may still be useful for the community as a whole. In this particular thread, lecturing us on forks (in ex. not always being automatically profitable), while at the same time likely being unaware of status of vixie-cron development and its Gentoo maintenance story, then trying to get what we define as 'dead upstream' in pretentious one-liners like someone's life depended on it is what Markos called it - useless - not 'personally uncomfortable'. | You can only decide what is useless for you - and I don't care even | if you think that I'm useless for Gentoo (I didn't say that you've | said so, I am only saying if!) but I do care if you claim that your | opinion is representative of the entire community, as you did above. | That's not cool. Neither is trolling. Please be so kind and discontinue this practice. Thanks for understanding. regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Friday 17 of January 2014 13:06:22 gro...@gentoo.org wrote: | dev-util/kdevelop-php-docs While of course it doesn't invalidate your entire idea, this particular example is a kdevelop plugin written in C++ that provides php API documentation integration. This tells however that decision to "auto"-keyword/stabilize remaining arches cannot be taken lightly and not by everyone. regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On Monday 24 of March 2014 16:28:44 Ciaran McCreesh wrote: | On Mon, 24 Mar 2014 10:55:38 -0400 | Damien Levac wrote: | > A lot of people already replied to this question: package search. | | Sure, but can you point to prior examples of this kind of stuff | actually working? https://wiki.debian.org/Debtags http://debtags.debian.net/search/ True, may not be as popular as full-text description search. regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] crossdev and multilib interference
On Wednesday 26 of March 2014 02:07:56 Mike Frysinger wrote: | cmake is completely broken when it comes to library searching and multilib and | cross-compiling. it will happily look in hardcoded / paths to test for the | existence of files as well as directly execute `pkg-config`. it's a great | example of people saying "autotools is crap, so let's invent our own kind of | crap and ignore lessons learned". this isn't the fault of cmake eclasses, but | it'd be nice if we could someone standardize the hacks in there so we don't | have to duplicate across ebuilds. If we provided toolchain.cmake (passed to CMake via -DCMAKE_TOOLCHAIN_FILE=) file for each crossdev, that could not only set compiler paths/etc but also override CMAKE_SYSTEM_PREFIX_PATH, we would get pretty close to autotools. Yes, CMake has pretty rudimentary (to put it mildly..) cross-compilation support but it still can be done there somewhat "right". regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Multimedia overlay
On Tuesday 11 of August 2009 11:08:34 Robert Buchholz wrote: > In my opinion, the entrance barrier for devs is lower on git.overlays, > there is no signup, password, mail verification required. There's > scripts to keep the ssh keys in LDAP and on git.overlays in sync, and > people can just request access to at overl...@g.o and usually get it > done within 24 hours. Except usually it takes much longer than 24 hours (like over a month in my case). No, thank you. Good luck with new overlay yngwin :) -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Multimedia overlay
On Tuesday 11 of August 2009 17:07:47 Arun Raghavan wrote: > The advantage is primarily that we retain control of the > infrastructure on which it (the official Gentoo project) is hosted. Yes, and this is the problem. That's probably why there's still no CIA.vc bot tracking kde-testing overlay on #gentoo-kde Being able to grant/revoke overlay access easily is of course other thing. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Multimedia overlay
On Tuesday 11 of August 2009 19:38:48 Arun Raghavan wrote: > This still does not address the original problem - if > $external_service shuts down, is bought out, has arbitrary terms about > content that are not immediately clear as being unfavourable to us, > (at least) that part of the project which is hosted on is negatively > affected. As far as git is concerned, there's no reason not to have this 'unsafe' gitorious repo cloned on Gentoo within infra and synced periodically (preferably with push disabled) for layman purpose. Development would still be kept on gitorious as it's superior in terms of manageability. I guess it satisfies both sides, doesn't it? -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Thursday 13 of August 2009 12:35:43 Tiziano Müller wrote: > Am Mittwoch, den 12.08.2009, 23:55 -0600 schrieb Ryan Hill: > > On Wed, 12 Aug 2009 19:46:56 +0100 > > > > Ciaran McCreesh wrote: > > > On Wed, 12 Aug 2009 20:41:30 +0200 > > > > > > Tomáš Chvátal wrote: > > > > Also we should allow the stuff as directory thingus (portage already > > > > handles it right). > > > > > > That's a seperate thing that needs EAPI control. You'll need to propose > > > it for EAPI 4 if you want that. > > > > Why is that (seriously curious, not disagreeing)? Portage has supported > > this for quite a while now. Does the current PMS disallow it? > > > > What I've really wanted for a long time is different package.mask files > > for different types of masks. eg. > > > > package.mask/broken.mask (qa.mask?) > > package.mask/removal.mask > > package.mask/security.mask > > package.mask/testing.mask > > To avoid collision with the current package.mask I'd prefer > package.mask.d/ for the directory. Also makes the transition easy since > we can generate package.mask out of the files in package.mask.d/. package.mask.d being directory and not used internally by PM - so being just a convention (which may be used for manually or scripted generation of resulting package.mask as dev-zero proposed- it's now utilized in kde-testing overlay because package.mask dir used to cause paludis crashes) can be implemented just now with no PMS changes (since PM is supposed to ignore unknown files/directories in there?). I'd suggest allowing package.mask as either directory or file though, no need for entities multiplying... besides the reference implementation in already there for ages. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 3 and "nonfatal die"
On Friday 21 of August 2009 22:56:41 David Leverton wrote:
> Does anyone have any opinions on which of the four options (#1
> make die respect nonfatal, #2 make die always die, #3 add a new
> die variant that respects nonfatal, #4 make regular die respect
> nonfatal, and add a new variant that doesn't) we should go with?
> We should definitely get this resolved and agreed on before EAPI
> 3 is finalised.
I suggest #5 - drop the idea of 'nonfatal'.
Quoting devmanual:
"The die function should be used to indicate a fatal error and abort the
build. Its parameters should be the message to display."
Period.
In such case, following code:
nonfatal some_function
when:
some_function() {
so_sth || die "sth failed"
}
only means, that "some_function" shouldn't have been equipped with 'die'
mechanism, as use case appeared that demands it being non-fatal.
And in this case "some_function" should be fixed to be nonfatal instead (and
all existing invocations suffixed by "|| die".
Simple as this.
Please refrain from adding silly workarounds like this - only thing they add
is unnecessary complexity and thus maintenance/debugging burden.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 3 and "nonfatal die"
On Friday 21 of August 2009 23:12:23 Ciaran McCreesh wrote: > On Fri, 21 Aug 2009 23:09:33 +0200 > Maciej Mrozowski wrote: > > I suggest #5 - drop the idea of 'nonfatal'. > Then how do you plan to handle all the standard utilities that die on > failure in EAPI 3? >>> #1 make die respect nonfatal The most obvious. About consequences - when you override behaviour of "die-on- failure" function (that has been marked as fatal for reason) you're supposed to know what you're doing, so all codepaths should be checked in that case, otherwise one should be really ready to grab the pieces in such case. >>> #2 make die always die In such case nonfatal is useless as it's supposed to surpass "die-on-failure" EAPI3 functions, am I right? Correct me if I'm wrong, bug there are just two ways to mark function invocation as 'failed': - return nonzero value - soft way - abort further execution of script, so call die function - hard way In such case nonfatal works against its purpose (it cannot interfere in arbitrary function's flow control, and return value only affects this, so the only mean for it is to interfere in general-purpose-die-function). This could be fixed by introducing 'even-more-fatal' way of aborting script execution, like function 'really-die-seriously-this-time' that ignores 'nonfatal' :P (which leads us to #3 and #4). >>> #3 add a new die variant that respects nonfatal Seems the most reasonable to me, but should be introduced with caution (if at all). It's very old question how to approach flow control: whether to: - maintain in using 'do_it_now_think_later' approach (exceptions' handling, nonfatal) - 'do_it_now_think_now' (checking return values) Ideally would be to have just one. And if the goal is to implement exception-handling-like (actually catching and ignoring) approach in flow control for EAPI3 instead of relying on return value (|| die) with runtime errors throwing (current 'die'), one would need not just one or two "die functions", but maybe whole family, with different fatality levels (for example controlled by environment variable, so that one could ignore those with level > 0 or could be more strict and only ignore those with level > 2, when 0 would be the most fatal, 1 less-lethal and so on). >>> #4 make regular die respect nonfatal, and add a new variant that doesn't) we should go with? All existing 'die' invocations now are supposed to be fatal (according to definition in devmanual), so making them maybe-fatal in EAPI3 is wrong imho. General problem is defining what's really fatal and what's not - and I can assure that someone in a future will find some use case for preventing aborting of execution of some fatal function that failed. That being said I don't like refraining from "return value approach" towards "exception handling approach" (and I'm ebuild/eclass developer and I don't see adding || die very disturbing) that has been proposed for EAPI3 in die-on- failure utility functions, and thus I don't like nonfatal (which is of course needed for them). -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Friday 21 of August 2009 23:46:38 Ciaran McCreesh wrote: > On Fri, 21 Aug 2009 23:42:11 +0200 > PMS accurately reflected the Portage documentation at the time it was > written and at the time it was approved. Agreed, but I think it was supposed to reflect Portage 'behaviour' at the time. Of course it's hard to blame anyone for it, especially after all these years. > The correct way to proceed is to use EAPI 4 to move this to be a > specified feature, and to permit it only for profiles marked as using > EAPI 4. It's true, but being able to modularize profile may outweights the need to be strict-with-the-book here - it's a matter of usefulness. I think it should be decided by those who actually do the work in profile, whether it's worthy to push this now instead of waiting for EAPI approval. So, can profile developers share their view? -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 3 and "nonfatal die"
On Saturday 22 of August 2009 01:06:30 Ciaran McCreesh wrote:
> On Sat, 22 Aug 2009 01:01:48 +0200
>
> Maciej Mrozowski wrote:
> > That being said I don't like refraining from "return value approach"
> > towards "exception handling approach"
>
> nonfatal's not an exception handling approach. Think of it as a utility
> like 'nice', 'ionice', 'xargs', 'env' or 'hilite'.
Le sigh..
Replacing return value with die ("throw") *and* providing 'nonfatal' as
mechanism to catch and ignore what's been thrown is obviously "exception
handling approach" (not literally that is, I don't have to recall the
semantics of \" character) - every respected software engineer will see that.
But on topic, if you want to participate in discussion, please refer to
suggestions given by David, please.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)
On Friday 04 of September 2009 22:08:02 Ciaran McCreesh wrote: > On Fri, 04 Sep 2009 22:04:46 +0200 > Rémi Cardona wrote: > > Having tools to manipulate those variables is very misleading since > > users will (rightfully) assume that we've done our homework and that > > upstream did too. > Why not use EAPI 4 to make sure people have done that homework then? Because it won't make *upstream* do their homework. I suppose you volunteer to make this homework for Gentoo to fulfill new EAPI requirements as I assume your lawyer skills equals the will to propose yet another EAPI. Therefore I fully support this idea. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: perl-module.class review
On Monday 21 of September 2009 17:38:53 Tomáš Chvátal wrote:
> I think it is not required
> EXPF="src_compile src_test src_install" <- definition, also nulls anything
> what was in it before :]
> case ${EAPI:-0} in
> 2) EXPF="${EXPF} src_configure" ;;
> 1|0) ;;
> *) die "Unknown EAPI, Bug eclass maintainers." ;;
> esac
> EXPORT_FUNCTIONS ${EXPF} <- export
How about unsetting variables after use in first place so that they no longer
pollute global env.
--
regards
MM
--
Rudi Schuberth odkrywa kulisy swojego odchudzania. Ile schudnie?
Sprawdz >>> http://link.interia.pl/f236a
[gentoo-dev] [RFC] Dropping (or enabling only on request) bootstrap from SCM eclasses
In pre-EAPI-2, src_unpack phase was the most logical phase to be provided by
SCM eclasses, thus classes has been set up to export ${ECLASS}_src_unpack.
This phase in most (if not all) SCM eclasses provided:
- unpack functionality - fetch and store in ${DISTDIR}
- bootstrap functionality - either patching or bootstrapping just unpacked
sourced with command
In EAPI-2, bootstrap functionality belongs to prepare phase, thus it's been
moved there - SCM eclasses in EAPI-2 codepath has been set up to provide
src_prepare.
And this is the problem (some people may be even unaware of it).
In pre EAPI-2 it was sufficient to do the following in live ebuilds:
inherit ${some_eclass} ${scm_eclass}
${scm_eclass} inherited as last one, would just shadow src_unpack, providing
what we want. In EAPI-2 however, it as well shadows src_prepare which is in
*most* cases unwelcome, especially if one uses autopatcher (base.eclass, so
cmake-utils.eclass, kde4-*.eclass, and probably some other).
Because SCM bootstrap is either not used at all, or used very rarely, there's
suggestion to:
- either drop it
- or (preferably) to make SCM eclasses export src_prepare only on specific
request
- or to make it easier - to not export it at all - thus making it required for
developer to intentionally invoke ${ECLASS}_src_prepare if bootstrapping is
required.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Dropping (or enabling only on request) bootstrap from SCM eclasses
On Thursday 24 of September 2009 08:32:53 Ulrich Mueller wrote:
It's all about making live <-> tagged ebuild synchronization easier.
Currently
> Not a good idea, IMHO. In pre-EAPI-2, the SCM eclasses shadow
> src_unpack of base.eclass, so also no autopatching of base.eclass
> takes place. If we now change it _not_ to export src_prepare, then
> there may be surprises when bumping an ebuild to EAPI-2.
I think only those will be surprised, who declare PATCHES variable
and who don't make use of it. To ensure we're on the same page, autopatcher
is:
PATCHES=(
"${FILESDIR}/patch1"
"${FILESDIR}/patch2"
)
accompanied with invocation of base_src_prepare (EAPI-2) or base_src_unpack
(pre-EAPI-2).
And when bumping ebuild EAPI one is required anyway to verify whether patches
are applicable, proper phases are invoked etc.
The only other people who are going to be surprised would be those who rely on
current implicit SCM src_prepare behaviour but I'm yet to find anyone with
such ebuild.
Actually *now* there's surprise factor all the time when using tagged EAPI-2
ebuild to create live EAPI-2 ebuild as it requires either explicitly
overriding src_prepare or src_unpack, because when you just place
'inherit someeclass git'
PATCHES=("file1" " file2")
it will shadow src_prepare and *silently* ignore autopatcher you may think
you're using (hey, PATCHES variable is there!). Current situation makes live
<-> tagged ebuild synchronization a bit less convenient and certainly more
tricky.
> Besides, most SCM eclasses (at least cvs, subversion, git and bzr)
> have their own autopatch facility running in src_prepare (before
> bootstrap). Why would one need _both_ this and the one in base.eclass?
Because autopatcher makes it able to specify patches that are version
independent (same patches for live and tagged ebuilds), while SCM
patching/bootstrapping may be used for some specific cases (I haven't seen any
yet personally, hence suggestions to drop it completely or disable by default
and not to export src_prepare).
When migrating SCM eclasses to EAPI-2, I recommended leaving bootstrap in
src_unpack phase and not to move it to src_prepare because I was well aware it
will break most live EAPI-2 ebuilds having 'inherit '. And
because developers doing this change didn't care for that case, I don't see
why now they should oppose the idea to fix what they've broken, especially
when it's probably going to affect only bad live EAPI-2 ebuilds (with not
working PATCHES).
But anyway, think for a while about the purpose of SCM eclasses. At least in
my opinion, they should only provide [tarball or SCM] -> SRCDIR delivery
method, so just unpack method - any source processing should be purely
*intentional* (and not enabled by default in SCM eclasses) - so in my opinion
- unconditionally shadowing src_prepare by SCM eclasses is just
architecturally wrong and needs to be fixed.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: package.use.stable.mask
On Saturday 10 of October 2009 22:50:37 Zac Medico wrote: > Maybe a syntax extension for IUSE would be a little nicer. For example: > > IUSE="unstable? ( foo bar )" No no no, the biggest reason for this is to not touch ebuild at all - it needs to be fully ebuild independent. It's like with recent KDE4 stabilization. Having ability to exclude certain optional dependencies from stabilization *without* modifying ebuilds (remove USE flag and its support from IUSE) is the motivation here. For now - we just mask them in package.use.mask with appropriate version specification (let's say <=kde-base/kdeutils-meta-4.3.10 cups) - but it's not ideal as you may think. It's no surprise, we don't manage ebuilds in *purely* individual manner - instead we try to keep all ebuilds across all releases the same if possible (eclass handles it properly) - it's over 250 of them after all and we maintain now 4.3.1, 4.3.2, 4.3. (stable branch - what makes next 4.3.x releases), (pure trunk) and trunk snapshots like 4.3.69. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] openrc-0.5.1 arrived in the tree
On Wednesday 14 of October 2009 08:12:03 Eray Aslan wrote: [...] Please STOP already, all of you. There is only one important fact nobody seems to comprehend - new openrc was added to TESTING repository. That being said, if one uses packages from such repository (portage subtree, whatever), one *should* be ready to *grab* *the* *pieces* or *downgrade* when needed. Come on - it's not rocket science. OpenRC has been unmasked and put in testing subtree to gather feedback (sic!) - and users choosing testing repository are expected to use Gentoo bugzilla as it's the preferred way to provide such feedback - NOT gentoo-dev mailing list. Again, please stop all of you. Thanks in advance -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] KDE Team Meeting - October 2009
On Tuesday 20 of October 2009 20:33:12 Alex Alexander wrote: > Greetings, > > The KDE Team will have its usual monthly meeting this Thursday. > > Date: Thursday, 2009/10/22 > Time: 1900 UTC > Channel: #gentoo-meetings I'd like to suggest following agenda items: 1. Proposition to split desktop profile to: KDE, Gnome, (and maybe some others). That being said active presence of some Gnome guys would be most appreciated. 2. Discussion of KDE4 split ebuild policy. I think we need to sanitize it a bit (more functional/application approach) - especially regarding kdepim, kdebase-workspace. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] KDE Team Meeting - October 2009
On Wednesday 21 of October 2009 22:34:18 Denis Dupeyron wrote: > 2009/10/21 Maciej Mrozowski : > > 1. Proposition to split desktop profile to: KDE, Gnome, (and maybe some > > others). > > How about making a desktop profile with everything common and being > the parent of Gnome, KDE, XFCE, etc... sub-profiles with the specific > stuff? Sure, provided there's point in doing so (like to enable X USE flag there? truetype? maybe dbus?) . One parent profile more won't hurt anyway - it can be made empty for now, and left to be really used in the future - but certainly current bloat needs to be purged from there. It's not even funny to suggest users to use desktop profile as it will pull all KDE and all Gnome related dependencies which is silly, no matter DE one prefers. -- regards MM signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
Hi there! Resulting from discussion during last Gentoo KDE team meeting taking place 22 Oct 2009 at #gentoo-meetings (summary fill be available soon), having Gentoo GNOME team representative, it's been decided to go ahead with splitting desktop profile to DE-specific subprofiles, to avoid bloat and provide desktop specific separation which should result in desktop subprofiles being actually practical. It's been proposed to: - keep 'desktop' profile but strip it from any desktop specific features and settings, making it default recommended choice for anyone using non-KDE and non-GNOME desktop environment, yet avoiding USE flags bloat. Any other DE is free to join and create own DE-specific subprofile if needed. - create 'KDE' (or 'kde') and 'GNOME' (or 'gnome') subprofiles within 'desktop' profile and move any desktop specific things there. This should in theory allow us to not add 'recommended' IUSE defaults to desktop specific packages, but keep those settings in profile - making profile effectively 'out of the box' solution for those who need it. If you have any comments, suggestions, important notices regarding this change, please keep discussion in gentoo-desktop mailing list. Thanks -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
On Saturday 24 of October 2009 16:00:03 Jeremy Olexa wrote: > Just so it is clear and there aren't any questions in the future. The > XFCE team maintains a set of recommended global use flags in our docs[1] > (maintained by Josh (nightmorph)). So, whatever direction this ends up, > xfce will not be going down that same road. Well, if XFCE 'satisfying use deps' USE flags are not excessive, I think they could stay in desktop (parent) profile of course as desktop profile is meant for general use desktop. This would address some parts of Nirbheek's concern. > Additionally, One cool thing about Gentoo is that you *can* have more > than one DE installed. We don't have things like KGentoo =P I hope this > profile thing doesn't make it harder for end users to use GNOME and KDE > at the same time. That's the 'edge' case we encounter. Of course splitting desktop profile *will* make it harder for them to have GNOME and KDE at the same time. But, to be clear, we're talking here mainly about default USE flags (not gnome-base/* entries in package.mask in KDE subprofile... hmm, jmbsvicetto? worth considering... ;) ) Splitting profiles is to provide out of the box desktop specific solutions (because that's what majority uses afaik, though I don't have any poll to back my words), not to prevent anyone from mixing things - those may just need the same package.use/make.conf effort to set it up (mainly to satisfy USE deps, as one can put recommended USE flags in +EAPI-1 IUSE in desktop environment ebuilds after all). -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
On Monday 26 of October 2009 21:06:04 Rémi Cardona wrote: > IMHO, we shouldn't even have desktop/server subprofiles to begin with. > I've always considered Gentoo to be an "opt-in" distro where after a > successful install, you end up with a bash prompt and a _means_ of > installing new packages. > Finding out what USE flags mean and do is part of the Gentoo experience. > If we were doing spin-off distros like Ubuntu and Fedora do, then > subprofiles would be fine, but we're not. > So with my X hat on, I won't be adding any "X" subprofile. > And with my (former?) Gnome hat on, I vote against any "gnome" subprofile. I most cases I agree with you. To be more specific - desktop profile should be annihilated because it's a joke. It's impractical and bloated. Splitting it to "kde" and "gnome" is just nicer way of annihilating it. However, considering amount of confused users on IRC and forums, especially after KDE4 stabilization and Qt4 default USE flags change, and considering no automatic USE flags management provided by portage (for example via -- interactive mode) - there's no way to make it easier to use. Making something "easier to use" does not necessarily need to mean "less flexible". It we're to provide mostly learning experience and not practical solutions, why not rename Gentoo to Eduentoo :) And I fail to see *any* point in forcing users to learn Gentoo internals (sic! like USE flags). What else? Ebuild syntax so that they're able to get to know what particular global USE flag is responsible for, when someone forgot (or decided not to) describe it in metadata.xml even when semantics is different? Maybe I sound too harsh here, but that's because I'm not ideologist - I'm practical man. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild
On Sunday 08 of November 2009 23:19:13 Mike Frysinger wrote: > > So, you didn't get my point. It must be true then, what they say about > > geeks and social skills... > > i dont think your point is relevant to this thread > -mike Indeed it is - it's not about what's been said, but about the way it's been said. cheers MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] openrc stabilization todo
On Thursday 03 of December 2009 15:06:12 Rémi Cardona wrote: > Le 03/12/2009 02:22, Jeremy Olexa a écrit : > > Can parallel init script startup be made the default yet? I've been > > running with it for months and never noticed a problem.. > > I've been running it for more than a year on half a dozen boxes, without > any issues as well. > > +1 for making it the default. -1 from me (at least with <0.5.3, I'm following openrc Gentoo releases closely) *Very* occasionally, bud deadlocks used to happen here. I'll report it for 0.5.3 if I run into this again. -- regards MM
Re: [gentoo-dev] Re: Qt3 deprecation and removal policy
On Thursday 31 of December 2009 14:43:54 Mark Bateman wrote: > Ben de Groot gentoo.org> writes: > > As announced 5 months ago[1], Gentoo's Qt team now officially > > deprecates usage of x11-libs/qt:3 and packages depending on this > > version of Qt. > > > > > > # Policy for remaining ebuilds depending on qt:3 # > > > > * if Qt3 optional, remove this option > > * if Qt4 depending version stable, remove Qt3 depending versions > > * if Qt4 depending version in testing, mark stable, then remove older > > versions * if no Qt4 version in tree, get Qt4 version in testing by > > 2010-01-21 and stable by 2010-02-21 > > * if no Qt4 version exists, check for equivalent/replacement packages, > > and mask by 2010-02-21 > > > > Note: for packages that currently have no version marked stable, the > > references to stabling Qt4 versions obviously don't apply. > > > 1: > http://archives.gentoo.org/gentoo-dev-announce/msg_d851e05567d538b662f34de8 > dfdb7316.xml > > > Cheers, > > QUCS is a qt3 only application. > This is a fantastic electrical simulation package and is in active > developement. > > There is a svn branch for the qt4 port but it isn't there yet. > Removal of qt3 will break this app that is in the main tree > > If the policy is to then remove this app (which would be a very big shame > since it will mean - based upon past experience - hard to get back in) > could a hard-mask live ebuild for the svn/nightly be made until the next > qucs is released It could be moved to kde-sunset overlay where legacy KDE3 stuff (like KDE 3.5.10 itself) is being kept and maintained by the community. -- regards MM
Re: [gentoo-dev] PYTHON_DEPEND - Suggested replacement for NEED_PYTHON
On Monday 11 of January 2010 01:25:45 Arfrever Frehtes Taifersar Arahesis wrote: > 2010-01-10 21:56:01 Fabian Groffen napisał(a): > > On 10-01-2010 09:29:28 +0100, Arfrever Frehtes Taifersar Arahesis wrote: > > > I would like to suggest introduction of support for PYTHON_DEPEND > > > variable, which would be a better replacement for NEED_PYTHON > > > variable. NEED_PYTHON variable does not allow to specify that e.g. > > > only versions of Python 2 are accepted. (Eventually PYTHON_DEPEND > > > variable will have to be set only in ebuilds of packages not > > > supporting installation for multiple versions of Python.) > > > > Can you explain the intended use of this variable, and why normal DEPEND > > is not sufficient? > > PYTHON_DEPEND is intented to simplify specification of dependency on > Python. > > PYTHON_DEPEND="2:2.5" is shorter than: > DEPEND="|| ( =dev-lang/python-2.7* =dev-lang/python-2.6* > =dev-lang/python-2.5* )" Doesn't that accidentally mean that dev-lang/python is improperly slotted and all 2.x releases should be slotted with :2? So that dependency string would look like: DEPEND=">=dev-lang/python-2.5.0:2" -- regards MM
[gentoo-dev] eutils changes wrt EAPI-3 - ebeep and epause no longer available
A as result of discussion http://www.mail-archive.com/gentoo- d...@lists.gentoo.org/msg37300.html ebeep and epause functions defined in eutils are not available in EAPI >= 3. For interactive installs, PROPERTIES="interactive" should be used instead. -- regards MM
[gentoo-dev] Re: eutils changes wrt EAPI-3 - ebeep and epause no longer available
On Wednesday 17 of February 2010 03:25:16 Maciej Mrozowski wrote:
If no objections, I'm going to commit in 5 days the following patch to
eutils.eclass
Index: eutils.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v
retrieving revision 1.333
diff -u -B -r1.333 eutils.eclass
--- eutils.eclass 17 Feb 2010 17:10:23 - 1.333
+++ eutils.eclass 25 Feb 2010 03:11:32 -
@@ -54,13 +54,11 @@
else
ebeep() {
- [[ $(type -t eqawarn) == function ]] && \
- eqawarn "QA Notice: ebeep is not defined in EAPI=3, please
file a bug at http://bugs.gentoo.org";
+ ewarn "QA Notice: ebeep is not defined in EAPI=${EAPI}, please file a
bug at http://bugs.gentoo.org";
}
epause() {
- [[ $(type -t eqawarn) == function ]] && \
- eqawarn "QA Notice: epause is not defined in EAPI=3, please
file a bug at http://bugs.gentoo.org";
+ ewarn "QA Notice: epause is not defined in EAPI=${EAPI}, please file a
bug at http://bugs.gentoo.org";
}
fi
--
regards
MM
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On Monday 01 of March 2010 22:24:56 Ben de Groot wrote: > For some reason beyond my understanding, we have the cups useflag > enabled by default in profiles. This has started to generate circular > dependencies, at least for desktop profile users (gtk -> cups -> > poppler -> gtk). I propose we no longer enable the cups useflag. +1 Please do, as well there are some other candidates for purging from base profile, namely 'perl' and 'python' USE flags. Related bug and discussion: Bug 250179 http://archives.gentoo.org/gentoo-dev/msg_afe72c138992b6a590120de199ffcc44.xml -- regards MM
[gentoo-dev] Re: eutils changes wrt EAPI-3 - ebeep and epause no longer available
On Thursday 25 of February 2010 04:11:49 Maciej Mrozowski wrote:
> On Wednesday 17 of February 2010 03:25:16 Maciej Mrozowski wrote:
>
> If no objections, I'm going to commit in 5 days the following patch to
> eutils.eclass
>
> Index: eutils.eclass
> ===
> RCS file: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v
> retrieving revision 1.333
> diff -u -B -r1.333 eutils.eclass
> --- eutils.eclass 17 Feb 2010 17:10:23 - 1.333
> +++ eutils.eclass 25 Feb 2010 03:11:32 -
> @@ -54,13 +54,11 @@
> else
>
> ebeep() {
> - [[ $(type -t eqawarn) == function ]] && \
> - eqawarn "QA Notice: ebeep is not defined in EAPI=3, please
> file a bug at http://bugs.gentoo.org";
> + ewarn "QA Notice: ebeep is not defined in EAPI=${EAPI}, please file
> a bug at http://bugs.gentoo.org";
> }
>
> epause() {
> - [[ $(type -t eqawarn) == function ]] && \
> - eqawarn "QA Notice: epause is not defined in EAPI=3, please
> file a bug at http://bugs.gentoo.org";
> + ewarn "QA Notice: epause is not defined in EAPI=${EAPI}, please
> file a bug at http://bugs.gentoo.org";
> }
>
> fi
No objections, so commiting this one.
--
regards
MM
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Friday 05 of March 2010 11:22:18 Dirkjan Ochtman wrote: > I *am* a stable user, and I do want to install python3 (without having > to override keywords -- because my packager, the gentoo python team, > says it works!). I recognize the cruft problem, but I don't think > keeping things in unstable It's "testing" :) Now on more serious note, ideally python could be treated just like any other non-leaf package (in dependency tree), just like library. In such case it's completely reasonable to stabilize the newest version of such 'library', especially when it's slotted and doesn't conflict in any way with the rest. However, because of being used by package manager, python is leaf application really and it's going to be immediately pulled for everyone. It would be nice if portage didn't automatically pull newest available packages with new SLOTs unless explicitly referenced in dependencies. That would have certainly caused python 3 stabilization to be a non issue. (@Zac is this "greedy/non-greedy' behaviour you've talking some time ago?) Hmm, but that would also prevent automatic KDE 4.x -> 4.y updates.. -- regards MM
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On Monday 01 of March 2010 22:24:56 Ben de Groot wrote: > For some reason beyond my understanding, we have the cups useflag > enabled by default in profiles. This has started to generate circular > dependencies, at least for desktop profile users (gtk -> cups -> > poppler -> gtk). I propose we no longer enable the cups useflag. poppler[utils] are just pdfto*sth converters, and they're most likely pure runtime depedencies for net-print/cups. Could someone from printing herd verify? If so, then it's sufficient to fix cups dependencies (move poppler[utils] from COMMON_DEPEND to PDEPEND) and problem solved. If no, I can split off utils from poppler - with CMake it's effortless. -- regards MM
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On Saturday 06 of March 2010 18:05:20 Nirbheek Chauhan wrote: > On Sat, Mar 6, 2010 at 5:02 PM, Ben de Groot wrote: > > Would it be possible to make cups a PDEPEND in gtk+ or is it really > > needed at compile time? > > cups is definitely needed at compile-time > > > The same for cups: can we make poppler a PDEPEND? Maciej, did > > you get any further with looking into that? > > From what I can see in cups-1.3.11, pdftops is purely a runtime > dependency. The configure flags enable code that doesn't need pdftops > at compile-time. Infact, poppler[utils] is in pure RDEPEND to reflect > that. So in total, I think it can be moved to PDEPEND. Apart from PDEPEND, one change needed as well in cups ebuilds: --with-pdftops pdftops needs to be replaced with --with-pdftops=/usr/bin/pdftops as otherwise it will fail during configure phase (giving absolute path disables autodetection) cups can use either poppler or ghostscript as pdf-to-ps filter, so given the fact that ghostscript is already a dep of cups, maybe --with-pdftops=gs could be used instead to avoid poppler dependency completely, but that's up to cups maintainers to determine whether it's safe/desired. So it's all simple, all this fuzz was unnecessary. Btw, do we still have active printing herd? -- regards MM
Re: [gentoo-dev] webapp-config needs a new maintainer
On Wednesday 10 of March 2010 07:52:28 Benedikt Böhm wrote: > Hi! > > On Wed, Mar 10, 2010 at 4:30 AM, Sebastian Pipping wrote: > > There are quite a few bugs open for it plus the latest version (1.50.18) > > is not even in Gentoo but on SourceForge only. > > The release on sourceforge is not compatible with the current > implementation in Gentoo AFAIK. > > > So your first task would be a proper bump and a maybe few bug fixes after: > webapp-config is in a horrible shape and also has several design > flaws. i wouldn't touch it. that's why i already added an idea to the > GSoC list for a complete w-c rewrite. i talked to gunnar in 2008 or > 2009 at chemnitz linux days, and we agreed that w-c needs a rewrite. > but none of us had/has time to do it. hopefully gsoc can change this > situation. This issue always bothered me. Why do we need exclusive web-app config application that effectively mirrors what emerge is supposed to do? I mean installation/removal/updates, and what's the most important config updates. I see this solution suboptimal. Don't bash me, maybe I'm obviously missing something but I'd really prefer simpler, Debian-like approach to webapps, so: - web-apps installed in /usr/share instead of /var/www (is there any benefit from polluting /var/www with system-managed applications?) - webapp-specific apache config installed in let's say /etc/apache2/conf.d/ and included from httpd.conf so that any application works out of the box (Alias directive may be suitable in example below) (example entry for phppgadmin:) DirectoryIndex index.php Options +FollowSymLinks AllowOverride None Order deny,allow Allow from all php_flag magic_quotes_gpc Off php_flag track_vars On php_value include_path . That file (apache config) as well as wep-app specific config file (/usr/share/phppgadmin/conf/config.inc.php) would be under config-protect, so any modifications are tracked. It's obviously less flexible than webapp-config (no automatic vhosts handling - it would be installed initially for all vhosts, sure, one can easily configure that), but at least doesn't need webapp-config anymore. -- regards MM
Re: [gentoo-dev] Qt3 mask breaks significant science packages
On Friday 12 of March 2010 17:17:01 Fabian Groffen wrote: > On 12-03-2010 08:46:34 -0700, Denis Dupeyron wrote: > > That said they were perfectly entitled to make the decision of not > > wanting to maintain qt3 any longer. The only advice I can give is that > > all disgruntled users and developers create a qt3 project and > > adopt/unmask/re-commit the qt3 libraries for maintainers of packages > > who need it. I doubt this will happen as this could have been done a > > long time ago, but it's never too late. > > Didn't we have a graveyard thing/overlay somewhere some day? Some users > might happily prefer to use stuff that's treecleaned, or removed due > security issues. If removal of stuff would mean it's dumped in there it > can be easily used by users and more easily readded later afterwards, if > need arises. Yes, it's called kde-sunset and it contains KDE3 and should contain Qt3 applications (maybe it does, may not all of them though) removed from tree recently. It's not graveyard really as some users actively maintain this overlay. http://git.overlays.gentoo.org/gitweb/?p=proj/kde-sunset.git (layman -a kde-sunset) -- regards MM
Re: [gentoo-dev] Qt3 mask breaks significant science packages
On Sunday 14 of March 2010 06:09:44 James Cloos wrote: > > "BdG" == Ben de Groot writes: > BdG> Abandoned packages do not belong in the portage tree. > > Nonsense. That attitude only servers to harm the user base. > > Leaving them in does not. But leaving them broken and unmaintained in main repository harms Gentoo quality and image. "User base" is welcome to step up and help with maintenance and that's what guys in kde-sunsite overlay actually do. So... patches welcome! Thanks! -- regards MM
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On Saturday 27 of March 2010 21:58:41 William Hubbs wrote: > On Sat, Mar 27, 2010 at 05:45:51PM +0100, Torsten Veller wrote: > > * Petteri R?ty : > > > So let's summarize for assigning to the single arch: > > > > > > In support (and my comments in support): > > > - Can be used as a gentle reminder for slacker arches > > > > And if not "only one arch" or "single arch" is slacking? > > I guess you would find another gentle way to remind them. > > > > > > How about a tool generating mails to arch teams, which lists all > > STABLEREQ, KEQWORDREQ bugs to which the arch team is CC'ed for a month? > > (Or probably easier or possible at all: which weren't changed for 30 > > days.) > > I know that I have several bugs right now with minor arch's on them > waiting to be stabilized. A couple have been waiting for a very long > time. I have even pinged some of the bugs several times with no response. > > Is there anything else I can do to get these arch teams attention? Yes, I think getting from them the privilege of being the only ones able to stabilize applications should do the job. No, seriously - given the fact that some of my packages were even stabilized without contacting me (app-misc/hal-cups-utils, app-admin/system-config- printer-common) - I think it should be: * solely up to the package maintainers to stabilize application on arches they're using or on any arch if package is arch-agnostic (optionally, but preferably with some peer review from other project members or arch team members). * to arch team members in other cases (like now) * other rules (30 days 'waiting' period, bugzilla bug with STABLEREQ) applied as they are now Role of arch teams would be decreased to peer review and solving KEYWORD requests. It's really freaking silly to wait months for stabilization of some random php/perl library that's known to work. Comments? -- regards MM
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On Sunday 28 of March 2010 09:39:18 Ciaran McCreesh wrote: > > It's really freaking silly to wait months for stabilization of some > > random php/perl library that's known to work. > How do you know it works if you don't test on the arch in question? The problem is not waiting for some to go stable so it would be possible to close bug and ignore arches. It's not about closing bug at all. The only inconvenience from exotic arches lagging is inability to remove particular old ebuild from tree, that's it. It's about having package marked stabled on my arch (amd64 in my case, may be other from other developer's perspective) in a timely manner. And I know it works on my arch because I test it and often use it on daily basis. On Sunday 28 of March 2010 13:32:59 Richard Freeman wrote: > amd64 has had the policy that any dev can stabilize if they've tested it > on a stable amd64 system, and this hasn't really caused problems. That would have certainly solved the problem if that policy was written and published anywhere. -- regards MM
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On Monday 29 of March 2010 09:30:38 Peter Volkov wrote: > В Вск, 28/03/2010 в 07:47 +0200, Maciej Mrozowski пишет: > > No, seriously - given the fact that some of my packages were even > > stabilized without contacting me (app-misc/hal-cups-utils, > > app-admin/system-config- printer-common) > > If you know packages are broken why they were not hardmasked? If they > have no problems what why it was bad idea to mark them stable? They are not broken, they're just not suitable. It's like stabilizing gcc-2.95 now, even when it won't work with some recent KDE/boost. hal-cups-utils is not a problem system-config-printer-common-1.1.13 is as it's being used by maybe incompatible now system-config-printer-kde from testing arch (I've raised those deps now), besides I wanted to wait for polkit-1 with this package (otherwise dbus "newprinternotifications" can be received only by root or require tweaking dbus conf to work out of the box . That's why kde- base/system-config-printer-kde and kde-base/printer-applet were intentionally left out from KDE-4.3.3 stabilization list. -- regards MM
[gentoo-dev] [RFC] More reliable hiding preserved libraries
Problem
..is known, let me summarize briefly.
Uninstalling packages providing libraries, without checking reverse runtime
dependencies of those packages leaves their dependencies unsatisfied (packages
with broken executables and/or shared libs).
Some package managers try their best not to remove said libraries, yet
allowing packages to be removed.
Those orphaned libraries cause problems[1] as build systems of some other
packages being (re)installed afterwards pick them up and abuse those orphaned
libraries. (we don't like orphans abused, we prefer them... "gone").
Solution
Now, I suppose there are some ideas how to make orphaned libraries not go in a
way. Basically then need to be available for system, but hidden for "emerge".
There is opt-out suggestion[2], unfortunately it does not provide any info how
exactly it's supposed to be achieved. As far as portage/pkgcore is concerned,
maybe - as Brian Harring suggested - sandbox could be used to somehow "hide"
preserved libraries or preserved library directory from ebuild environment
(preserved library directory a'ka "purgatory" - libs could be moved there when
considered orphaned).
Opt-in suggestion is as follows:
1. Use some library path (read by ld loader from environment) and export it
globally to environment pointing it to preserved library directory.
2. During "emerge", unset environment variable corresponding to said preserved
library directory - orphans are no longer located.
Attached patch for glibc (2.11, but should apply to any other glibc around)
and uClibc (this one is not tested but should work as well) that makes ld
loader aware of LD_GENTOO_PRESERVED_LIBRARY_PATH variable.
(LD_LIBRARY_PATH would work as well, but it's being used widely so cannot be
safely mangled.. on the second though it can - one could filter out preserved
library paths from it during "emerge").
Thoughts?
1. https://bugs.gentoo.org/show_bug.cgi?id=240323
2. https://bugs.gentoo.org/show_bug.cgi?id=307391
--
regards
MM
diff -ru ../glibc-2.11/elf/rtld.c ./elf/rtld.c
--- ../glibc-2.11/elf/rtld.c 2009-10-30 18:17:08.0 +0100
+++ ./elf/rtld.c 2010-04-03 10:51:46.468906521 +0200
@@ -874,6 +874,8 @@
/* The library search path. */
static const char *library_path attribute_relro;
+/* Gentoo preserved library path. */
+static const char *preserved_library_path attribute_relro;
/* The list preloaded objects. */
static const char *preloadlist attribute_relro;
/* Nonzero if information about versions has to be printed. */
@@ -1385,7 +1387,18 @@
/* Initialize the data structures for the search paths for shared
objects. */
- _dl_init_paths (library_path);
+ char *llp = alloca ((library_path != NULL ? strlen (library_path) : 0) +
+(preserved_library_path != NULL ? strlen (preserved_library_path) : 0) + 2);
+ *llp = '\0';
+ if (library_path != NULL)
+{
+ strcat (llp, library_path);
+ if (preserved_library_path != NULL)
+strcat (llp, ":");
+}
+ if (preserved_library_path != NULL)
+strcat (llp, preserved_library_path);
+ _dl_init_paths (llp);
/* Initialize _r_debug. */
struct r_debug *r = _dl_debug_initialize (GL(dl_rtld_map).l_addr,
@@ -2648,6 +2661,16 @@
mode = trace;
break;
+ case 29:
+ /* Read Gentoo preserved library path from env here. Watch out for
+ possible future 'case' additions in this switch as well as in
+ EXTRA_LD_ENVVARS defined in sysdeps//dl-librecon.h.
+ LD_GENTOO_PRESERVED_LIBRARY_PATH is blacklisted for SUID
+ programs in sysdeps/generic/unsecvars.h. */
+ if (memcmp (envline, "GENTOO_PRESERVED_LIBRARY_PATH", 29) == 0)
+ preserved_library_path = &envline[30];
+ break;
+
/* We might have some extra environment variable to handle. This
is tricky due to the pre-processing of the length of the name
in the switch statement here. The code here assumes that added
diff -ru ../glibc-2.11/sysdeps/generic/unsecvars.h ./sysdeps/generic/unsecvars.h
--- ../glibc-2.11/sysdeps/generic/unsecvars.h 2009-10-30 18:17:08.0 +0100
+++ ./sysdeps/generic/unsecvars.h 2010-04-03 10:48:07.192280437 +0200
@@ -10,6 +10,7 @@
"LD_DEBUG_OUTPUT\0" \
"LD_DYNAMIC_WEAK\0" \
"LD_LIBRARY_PATH\0" \
+ "LD_GENTOO_PRESERVED_LIBRARY_PATH\0" \
"LD_ORIGIN_PATH\0" \
"LD_PRELOAD\0" \
"LD_PROFILE\0" \
diff -ru ../uClibc-0.9.30.1/ldso/include/dl-hash.h ./ldso/include/dl-hash.h
--- ../uClibc-0.9.30.1/ldso/include/dl-hash.h 2008-11-03 16:41:17.0 +0100
+++ ./ldso/include/dl-hash.h 2010-04-03 11:23:44.026291507 +0200
@@ -132,6 +132,7 @@
extern int _dl_linux_dynamic_link(void);
extern char * _dl_library_path;
+extern char * preserved_library_path;
extern char * _dl_not_lazy;
static __inline__ int _dl_symbol(char * name)
diff -ru ../uClibc-0.9.30.1/ldso/include/ldso.h ./ldso/include/ldso.h
--- ../uClibc-0.9.30.1/ldso/include/ldso.h 2008-05-3
Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
On Saturday 03 of April 2010 12:56:04 Fabian Groffen wrote: > Is it known why this does happen exactly? When a lib is kept because it > is still used, only its soname + what the soname points to should be > kept. That would mean the lib can no longer be found during linking, > unless you add some trickery (or does GNU ld do something "handy" out of > the box right here?). So for example: > > % ls > usr/lib/libfoo.so -> libfoo.so.2.1 > usr/lib/libfoo.so.2 -> libfoo.so.2.1 > usr/lib/libfoo.so.2.1 > > % scanelf --soname usr/lib/libfoo.so > libfoo.so.2 usr/lib/libfoo.so > > what should kept preserved is: > > usr/lib/libfoo.so.2 -> libfoo.so.2.1 > usr/lib/libfoo.so.2.1 > > because trying to link to libfoo using `gcc -o bar -lfoo bar.c` should > (in theory and on some platforms at least) fail. It doesn't matter, as 'broken' build system may alphabetically find library by file name, and link to this library by full path. On Saturday 03 of April 2010 13:13:00 Michał Górny wrote: > > 2. During "emerge", unset environment variable corresponding to said > > preserved library directory - orphans are no longer located. > Wouldn't that cause failure when the toolkit relies on a 'hidden' > preserved library? It would indeed. Now when I think about it, moving stuff to preserved library dir could be just done - provided it's possible - along with fixing/setting DT_RPATH's in reverse runtime dependencies. This way no system-wide LIBRARY_PATH's would be necessary. Is it possible? Mike? On Saturday 03 of April 2010 13:33:16 Gilles Dartiguelongue wrote: > > There is opt-out suggestion[2], unfortunately it does not provide any > > info how exactly it's supposed to be achieved. As far as portage/pkgcore > > is concerned, maybe - as Brian Harring suggested - sandbox could be used > > to somehow "hide" preserved libraries or preserved library directory > > from ebuild environment (preserved library directory a'ka "purgatory" - > > libs could be moved there when considered orphaned). > that sounds nice, it would allow us to more easily spot > packages/upstreams doing it wrong (maybe that would work for packages > linking to themselves too btw) Keeping preserved libraries in separate location (in "purgatory" or dumping place) is just a method for making implementation possibly easier (or possible at all), with nice side effects though. -- regards MM
Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
On Saturday 03 of April 2010 14:16:14 Fabian Groffen wrote: > Shouldn't we fix that buildsystem then? Do you have an example of a > package/buildsystem that does that? "We" already do, the thing is that maybe we don't have to. https://bugs.gentoo.org/show_bug.cgi?id=240323 From top of my head: python having issues with sys-libs/db as well as some packages with readline. > > It would indeed. Now when I think about it, moving stuff to preserved > > library dir could be just done - provided it's possible - along with > > fixing/setting DT_RPATH's in reverse runtime dependencies. This way no > > system-wide LIBRARY_PATH's would be necessary. > > Is it possible? Mike? > No, unless you somehow make sure you reserve space for this, by e.g. > setting a bogus rpath entry at buildtime. If you want to go that route, > you probably want to look at the Prefix' binutils-config wrapper that > already calls the linker with added rpath arguments. Afterwards you can > use chrpath to set it to the correct location. Will get messy with the > vdb though, but if Portage's doing it, it can probably be dealt with. Sounds messy indeed, what about hardened/SELinux/AppArmor/whatever - do they allow such DT_RPATH operations? It should be probably also restricted for binary-only packages. On Saturday 03 of April 2010 20:51:43 Tiziano Müller wrote: > Don't fix the hack. Remove the preserve libs "feature", make the PMs > check for rdeps per default before unmerging things. This will only prevent creating orphans of uninstalled libraries, what about upgraded ones when SOVERSION has been bumped (the most common case)? Besides I can already imagine PMS-related discussion regarding "make the PMs check for rdeps per default before unmerging things" - thx but no thx. > Slot libraries where needed, slot dep operators (EAPI 4) will help. Again, you suggest to SLOT every library that happened to bump SOVERSION. It's unrealistic. Besides library should be slotted when it's API changes, for source based distributions it's not needed for ABI changes - let's not confuse those two. Also excessive slotting increases probability of breaking library discovery mechanisms in various build systems (not everyone uses pkg-config). > And if that doesn't work out we need a separate var to give the PM a hint when API/ABI breakages happen (such that the PM knows when to re-install the rev deps). It needs PMS amended and thus GLEP. Please submit a GLEP item for this if you see it fit. Anyway, as explained in OT, it's not a problem of package manager dependencies system but issue with broken/not smart build systems - no dependency tree magic will solve this issue. -- regards MM
