Re: [gentoo-dev] [RFC] ban use of base-4 casemods in ebuilds due to locale collation instability
Am 11.11.2015 um 05:16 schrieb Ulrich Mueller:
>> On Tue, 10 Nov 2015, Mike Frysinger wrote:
>
>> Arfrever highlights these are not even safe to use. bash is locale aware,
>> so it'll apply LC_COLLATE rules when processing the ^/, casemods. while
>> you can fix this with external programs ala:
>> LC_COLLATE=C tr ...
>
>> you can't do it with inline code like:
>> LC_COLLATE=C SRC_URI=".../${PN^^}/..."
>
>> On Tue, 10 Nov 2015, Mike Frysinger wrote:
>
>> sorry, i meant char classification here (LC_CTYPE), not collation.
>
> Shouldn't these be safe to use if the string consists purely of ASCII
> characters? I mean, A-Z and a-z should be uppercase and lowercase,
> respectively, in any locale?
Unfortunately, no (have been bitten by this issue already some years ago):
$ echo $LC_ALL
tr_TR
$ f=i; echo ${f^^}
İ
$ f=I; echo ${f,}
ı
- René
Re: [gentoo-dev] multilib amd64 news item for review
Am 17.03.2015 um 16:33 schrieb Michał Górny: However, some users may prefer setting ABI_X86 globally to enable 32-bit libraries in all packages that support building them. This can be done using the following package.use entry: */* abi_x86_32 I'm confused: Has this a different semantics from adding USE+='abi_x86_32' to make.conf? If no, why mention this strange way (which is new to me) for setting default global useflags. And to bring this even further: Wouldn't the nicest approach to add ABI_X86="32" or ABI_X86="32 64" to make.conf? (With the latter being more descriptive, as the first one might suggest that _only_ 32bit should be built). - René
Re: [gentoo-dev] Portage QOS
Am 10.01.2014 19:19, schrieb Ciaran McCreesh: > On Fri, 10 Jan 2014 14:18:24 +0100 > René Neumann wrote: >> And again: What is needed is streamlining the algorithms (discussion >> on that already started as far as I could notice). An algorithm in >> O(n³) is always¹ worse than O(n). The constant factor added by the > > Full dependency resolution is NP-hard... Though NP-hard does not necessarily mean 'unfeasible in practice'. > If you really wanted to > streamline the algorithms, you'd change the inputs slightly. Most of > the complexity of doing a decent job of dependency resolution comes from > dealing with crap input. My intention really was not to tell anybody how the depres algorithms should be improved. I just wanted to make a point against the 'Python is the root of all the bad performance'. >> ¹ For a large enough n. > > ...which could be larger than the number of atoms in the universe. > There are real world cases where an algorithm has an O(n^3) step that > takes a day, and a O(2^n) step that takes a second for most inputs. You > shouldn't be using O() to make performance comparisons. > Point taken. I should've use 'in general' instead of 'always'. What I had in mind when writing this were more smaller problems, where a good algorithm exists but people use their own naïve implementation/data structure. - René
Re: [gentoo-dev] Portage QOS
Am 10.01.2014 14:05, schrieb Igor: > Hello Patrick, > > Friday, January 10, 2014, 4:39:59 PM, you wrote: > >> No, Python isn't slow. >> Bad code is bad. You can write bad code in any language. > > Are you sure? Take a look here: > > http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=all&lang=python3&lang2=gpp&data=u32q > > of course these stats are all so fake, and you may not belive them. > > I've been using C/C++ since school it's fast, even bad code is working fast. > > I WOULD NEVER BELIVE PYTHON IS AS FAST AS C++ with math algorithms You do realize, that we are not doing math (read: number crunching) here? And again: What is needed is streamlining the algorithms (discussion on that already started as far as I could notice). An algorithm in O(n³) is always¹ worse than O(n). The constant factor added by the language difference is of no interest. > It's crazy that you're even trying to state it. Take a look at what > Python is producing in disasm and then look at it in G++. For a larger project, it often is more important to have readable and maintable code opposed to getting the last bit of performance. And Python is _far_ more readable and concise than C or C++ (imho). Due to lack of typechecking, I'm not so sure when it comes to maintainability though (there are test suites of course). - René ¹ For a large enough n.
Re: [gentoo-dev] Re: Portage QOS
Am 10.01.2014 13:52, schrieb Igor: > And you belive that you're outside competition. It looks unreal. > Gentoo is in competition with other distros - it's real and happens > right now. Again, just because this "science" called 'Economics' believes, everything is in competition, does not change reality. > Are you absolutely sure that in the condition when nobody knows how > Portage works we may go that far as saying we have a healthy Penguin? If I want to know whether or not a penguin is healthy, I'd ask my mum (she's a vet). - René
Re: [gentoo-dev] Portage QOS
Am 10.01.2014 13:23, schrieb Igor: > You could make fast and correct decisions. There is no such thing as the single correct decision. Management people often think there is, but this is because management people often have no clue what they are talking about. > > Why not to get rid of Python at all. What is so great in Python that > Gentoo exists for the sake of it? > What is so bad with Python? Also keep in mind: A bad/wrong algorithm does not get better just because you change the implementation language. > > 300 devs, are NOT ABLE to make portage fast in 8 years. > You obviously have no idea how Gentoo works. - René
Re: [gentoo-dev] Re: Portage QOS
Am 10.01.2014 13:10, schrieb Igor: > Hello Chris, > > Friday, January 10, 2014, 1:08:39 AM, you wrote: > >> Right here is the big problem: you're not looking at this from the >> perspective of the average Gentoo developer. We don't care about market >> share. We don't care whether we're on top for another few years. There >> are several forks of Gentoo. I doubt most devs care about them. I >> personally know that we're not going to compete with Debian, which has a >> huge contributor, or Ubuntu or Red Hat, which have whole companies >> behind them. You're selling this as if you're selling to a company which >> wants to be on the top of the market and beating out competitors, and >> that's not what we are. We are a source-based distro that requires some >> effort from users, and people want that or they don't want it. >>> What we need is a vote YES or NO. If you against it - vote NO. It's >>> perfectly normal, if there would be no NO there would be no need voting. > > Thank you for you opinion. > > The competition in open source world is much harder than with > commercial software. 3 commercial systems share 96% of the users. > > 1,6% of the users are shared by 296 Linux distros > > You may think that you're outside this rules but the competition is natural > on the planet and Gentoo is certainly competing weather you want it or not. > > Competition was long before a human foot stood on the ground for the first > time :-) And suddenly there is no competition in Linux world - do you really > belive in it? There is no really competition for the non-enterprise systems. It is a co-existance (one might even call it some kind of symbiosis). Please take your business nonsense somewhere else. Honestly, you sound like some suit with his powerpoint slides talking about buzz-words like 'competitors', 'keeping in power', 'QoS' … There were also numerous threads already about the very same topic. Most came to the conclusions that a) Gentoo is not dying b) the numbers used as arguments are inaccurate at best (how do you count 'Gentoo users'? And do you want users or machines? And what with persons using different systems) - René
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
Am 13.06.2013 07:44, schrieb Michał Górny: > Dnia 2013-06-12, o godz. 13:23:04 > Michael Orlitzky napisał(a): > >> We need worse support for overlays, i.e. no. Having to use >3 overlays >> defeats the purpose of a QA'd tree. Everything in an (official) >> overlay should be in package.mask instead. The main reason it isn't is >> because nobody wants to use CVS. For good examples, see sunrise or >> gentoo-haskell. > > Sunrise is not that good example. I liked to use it as an example but > over time you start to see how degenerated it becomes. It seems that > the bond between people is pretty poor there, and many of the packages > lack proper maintenance. > > Some of them simply don't build at all and wait for a random Sunrise > user to fix them. Then they lay unmaintained once again, and the story > repeats. Then the policies in sunrise need to be more strict: If it is mentioned in the bug, that the version in sunrise does not build anymore, it should be dropped from sunrise if there is no fix in some timeframe [1]. Of course this puts more workload on the sunrise-team as they have to monitor the bugs and respond accordingly. - René [1] Dunno, perhaps two weeks if noone responds "will fix it", four weeks else.
Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
Am 27.05.2013 22:38, schrieb Anthony G. Basile:
> Hi everyone,
>
> I was about to add a use expand flag for monkeyd (a tiny web server) and
> there is a notice in base/make.default to discuss use expand flags on
> the list first. There are about 9 plugins for monkeyd similar to apache
> which can be turned on/off by a configure switch. It makes sense to
> follow the same logic as apache here. There are no dependencies on
> monkeyd and so no use-deps. Seems very safe. Any objections?
>
> --Tony
>
Some time ago, Zac proposed a general PLUGIN (or PLUGINS) use-expand,
which could be used for packages with a small amount of plugins to avoid
having a new USE_EXPAND for each and every package. It also has the
advantage, that the resulting useflag 'plugins_foobar' is sane enough
(opposed to 'monkeyd_plugins_foobar'). With this, it serves as a quite
nice compromise for the fraction of USE_EXPAND-dislikers (like me).
Unfortunately this did not get any real discussion. So could this
package be an option to start this? Or do you insist on
monkeyd_{plugins,modules,...}_ ?
Thanks,
René
Re: [gentoo-dev] Re: CPU use flag detection
Am 19.05.2013 18:03, schrieb viv...@gmail.com: > On 05/19/13 17:47, Alexis Ballier wrote: >> On Sat, 18 May 2013 22:31:11 -0400 >> "Walter Dnes" wrote: >> >> [...] >>> ...shouldn't "mmxext" be moved out of use.local.desc into use.desc? >> >> all the cpu flags should be global IMHO, regardless of how many packages >> use them: we already mask/unmask them globally on arches where they are >> irrelevant. >> >> Alexis. >> > +1 > also +1 they should be easily recognizable as cpu features USE flags, as > already mentioned recently by someone (sorry could not search) So this sounds like one of the places, where a USE_EXPAND could really be correct and worthwhile :). - René
Re: [gentoo-dev] USE_EXPAND is not an IUSE replacement [was: New USE_EXPAND: CLAWS_MAIL_PLUGINS]
Am 03.05.2013 22:20, schrieb Zac Medico: > Is it worth changing? Nope. What's worth changing is the excessive use of USE_EXPAND for no reason (your described usecase makes sense for reasonable USE_EXPAND stuff like VIDEO_CARDS). But seems like I'm the only one concerned by this, so I should probably rest my case and switch to silent sobbing instead ;-). - René
[gentoo-dev] USE_EXPAND is not an IUSE replacement [was: New USE_EXPAND: CLAWS_MAIL_PLUGINS]
Am 24.04.2013 11:51, schrieb René Neumann: > As more and more packages seem to (mis)use USE_EXPAND: Can we get the > possibility to set this directly in package.use? Having to write > 'claws_mail_plugins_foo' does not help readability, and setting it in > make.conf is also not the right way (as is package.env). I just noted, that USE_EXPAND variables are even worse than I thought... NGINX_MODULES_HTTP="-access" emerge -av nginx Invalid '-' operator in non-incremental variable 'NGINX_MODULES_HTTP': '-access In other words: They do not even work from commandline (in a stacking manner). So, what exactly are the use-cases again, and why are normal use-flags replaced by them? I already see a future where packages carry a "FOOBAR_CONFIGURE_OPTIONS" use-expand ... when IUSE is not hip enough any more. - René P.S.: Using USE_EXPAND for PYTHON_TARGETS or LINGUAS or VIDEO_CARDS is of course good, as I (usually) set this system-wide.
[gentoo-dev] Useflags: xsl vs xslt
Dear all, I noticed, that there is a global useflag 'xsl', with one of those bleh-descriptions "Enables XSL support" There is exactly one user of it: php -- to pull in libxslt. Now there is also the local useflag xslt (used by three other packages) for enabling xslt support (by pulling in libxslt). My questions now are: * Is there a real difference between them? As far as I can see XSL is a superset of XSLT, but it's somewhat fuzzy. * Should 'xsl' remain a global useflag? * Should php remain 'xsl' or go to 'xslt'? * When building a new package with optional XSLT-support: Should I use 'xsl' or 'xslt'. Thanks, René
Re: [gentoo-dev] New USE_EXPAND: CLAWS_MAIL_PLUGINS
Am 24.04.2013 19:15, schrieb Zac Medico: > On 04/24/2013 02:51 AM, René Neumann wrote: >> As more and more packages seem to (mis)use USE_EXPAND: Can we get the >> possibility to set this directly in package.use? Having to write >> 'claws_mail_plugins_foo' does not help readability, and setting it in >> make.conf is also not the right way (as is package.env). > > How about if we use a share a single PLUGINS USE_EXPAND among multiple > unrelated packages? That way, you're package.use settings will be less > verbose (plugins_foo versus claws_mail_plugins_foo). > >> And could anyone explain to me, why having 21 additional use-flags is >> bad? I mean, you have them now too, the only 'advantage' being a nicer >> display on 'emerge -v'. > > Using a generic PLUGINS USE_EXPAND will also have the advantage of > making the emerge -v display less verbose. > Yes, this sounds like a good compromise. I'd still go with Michał if I had to choose ... but I'm not the maintainer :).
Re: [gentoo-dev] New USE_EXPAND: CLAWS_MAIL_PLUGINS
Am 21.04.2013 23:38, schrieb Christian Faulhammer: > Hello everybody, > > the upcoming Claws Mail release will have no separation between > internal plugins (stuff that is built on mail-client/claws-mail with > USE="crypt bogofilter") and external ones (all packages > mail-client/claws-mail-*) anymore. > All are now integrated, which would mean 21 additional USE flags for > Claws or alternatively a new set of CLAWS_MAIL_PLUGINS which includes > the old and new internal plugins. > > Any objections against the addition? > > Wishes > > V-Li > As more and more packages seem to (mis)use USE_EXPAND: Can we get the possibility to set this directly in package.use? Having to write 'claws_mail_plugins_foo' does not help readability, and setting it in make.conf is also not the right way (as is package.env). And could anyone explain to me, why having 21 additional use-flags is bad? I mean, you have them now too, the only 'advantage' being a nicer display on 'emerge -v'. - René
Re: [gentoo-dev] Add HEXCHAT_PLUGINS to USE_EXPAND
Am 21.03.2013 14:09, schrieb Denis M.: > Hello, I'd want to ask if it's possible and a good idea to add > HEXCHAT_PLUGINS to the global USE_EXPAND var. I personally don't think this is a good idea. Imho USE_EXPAND should be used for flags that will be used by multiple (>5?) packages -- for the simple reason, that USE_EXPAND somewhat hints for using /etc/make.conf for configuration (yes, you can still use package.use, but this feature is probably not so well known). Also the bug gives no reasoning, why having USE_EXPAND is a good thing here. - René
Re: [gentoo-dev] base.eclass
Am 08.07.2012 22:10, schrieb Michał Górny: > On Sun, 08 Jul 2012 19:49:25 +0200 > René Neumann wrote: > >> Hi all, >> >> I'd like just to receive a short clarification about the 'status' of >> base.eclass: Is this eclass expected to be available everywhere, i.e. >> should each eclass make sure it imports and incorporates it. Or is it >> just an eclass like the others and ebuilds should make sure they >> inherit it if needed? > > No. It is unmaintained, has serious design flaws and it simply should > not be used anywhere. At least in EAPI != [01]. > Thanks for the clarification. As Mike already mentioned, one should probably change the ebuild description to reflect just that fact. (Because at the moment it just says the complete opposite.) - René signature.asc Description: OpenPGP digital signature
[gentoo-dev] base.eclass
Hi all,
I'd like just to receive a short clarification about the 'status' of
base.eclass: Is this eclass expected to be available everywhere, i.e.
should each eclass make sure it imports and incorporates it. Or is it
just an eclass like the others and ebuilds should make sure they inherit
it if needed?
In my special case, I discovered that I cannot rely on 'PATCHES' being
honored and hence have to introduce something like:
src_prepare () {
epatch "some.patch"
distutils_src_prepare
}
And, imho, this is just noise -- having PATCHES=( "some.patch" ) would
be clearer :)
Thanks,
René
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Undocumented and unused USE variables
> * Undocumented use flags: > -- > pango % euse -i pango global use flags (searching: pango) no matching entries found local use flags (searching: pango) [+ D ] pango app-i18n/fcitx: Enable support for x11-libs/pango 3.6.3 [gentoo] 3.6.4 [gentoo] [+ ] 4.0.0 [gentoo] [+ ] 4.0.1 [gentoo] [+ ] 4.2.0-r2 [gentoo] [+ ] 4.2.1 [gentoo] [+ D ] pango media-gfx/fontforge: Enable pango font rendering [+ ] 20100501 [gentoo] [+ ] 20110222 [gentoo] [+ ] 20110222-r1 [gentoo] [+ D ] pango media-gfx/imagemagick: Enable Pango support using x11-libs/pango [...]
