Re: [gentoo-dev] Last rites: app-leechcraft/*, virtual/leechcraft-*

2020-09-22 Thread Georg Rudoy
вт, 22 сент. 2020 г. в 07:58, David Seifert :
> No, the original point really stands. The energy we have invested in
> EAPI bumping and what not is in no relation to the actual gain. The ROI
> on leechcraft has been negative, and not just by a small bit. The back
> and forth has been tiring, and the last-ditch efforts always come in at
> the last minute. This time it's going for sure.

Then, to save time and keep the tree clean, I'd add dev-libs/qrosscore
to the above list, as it has no consumers but similar problems.

net-libs/qxmpp would also have deserved the same treatment, although
it has a single net-im/kadu[xmpp] revdep. Maybe worth dropping it to
m-n then.

  Georg Rudoy

Re: [gentoo-dev] Last rites: app-leechcraft/*, virtual/leechcraft-*

2020-09-22 Thread Georg Rudoy
The PR ( ) contains
non-live snapshot ebuilds. Although, indeed, it's been last updated a
few months ago.

What's ultimately blocking there is splitting the commit adding those
ebuilds into multiple commits, one per package, while keeping the tree
consistent. I admit I hadn't had (and most likely won't have in the
foreseeable future) the resources to do these
consistent-per-package-commits — doing this (effectively a toposort,
counting in the dependencies between ebuilds) by hand is painful, and
there's no good automation I'm aware of that'll do that for me. On the
other hand,
1. I know at least some other multipackage groups don't always do
per-package updates and instead commit everything in one fell swoop
(like qt, for instance).
2. I think I've been told on #gentoo-proxy-dev that if this indeed
proves to be a burdensome thing, adding all the ebuilds in one commit
is feasible. But it's indeed been a while ago, keeping track of time
is hard.

If (2) is correct, I'm more than happy to fix whatever other issues
are pointed out in the PR.

But, of course, all this is ultimately up to you folks. I'm just a proxy.

вт, 22 сент. 2020 г. в 07:12, Joonas Niilola :

> I'd also like to point out something regarding "- packages only"; It
> may be buildable one day for users, and broken the next. And some of the
> deps may be unbuildable, it's really random and up to state of upstream
> instead of state of ::gentoo repo. This was the case with leechcraft for
> example, check bug #693328. You should always have a keyworded static
> version available.
> -- juippis
> On 9/22/20 2:23 PM, Michał Górny wrote:
> > # Michał Górny  (2020-09-22)
> > # Poorly maintained suite of NIH packages.  Only live ebuilds left
> > # for over a year.  This really belongs in an overlay.  Some of them
> > # depend on deprecated dev-qt/qtwebkit (#684672).
> > # Removal in 14 days.  Bug #693328.
> > app-leechcraft/laretz
> > app-leechcraft/lc-advancednotifications
> > app-leechcraft/lc-aggregator
> > app-leechcraft/lc-anhero
> > app-leechcraft/lc-auscrie
> > app-leechcraft/lc-azoth
> > app-leechcraft/lc-bittorrent
> > app-leechcraft/lc-blasq
> > app-leechcraft/lc-blogique
> > app-leechcraft/lc-certmgr
> > app-leechcraft/lc-core
> > app-leechcraft/lc-cpuload
> > app-leechcraft/lc-cstp
> > app-leechcraft/lc-dbusmanager
> > app-leechcraft/lc-deadlyrics
> > app-leechcraft/lc-devmon
> > app-leechcraft/lc-dolozhee
> > app-leechcraft/lc-eleeminator
> > app-leechcraft/lc-fenet
> > app-leechcraft/lc-gacts
> > app-leechcraft/lc-glance
> > app-leechcraft/lc-gmailnotifier
> > app-leechcraft/lc-historyholder
> > app-leechcraft/lc-hotsensors
> > app-leechcraft/lc-hotstreams
> > app-leechcraft/lc-htthare
> > app-leechcraft/lc-imgaste
> > app-leechcraft/lc-intermutko
> > app-leechcraft/lc-kbswitch
> > app-leechcraft/lc-kinotify
> > app-leechcraft/lc-knowhow
> > app-leechcraft/lc-krigstask
> > app-leechcraft/lc-lackman
> > app-leechcraft/lc-lastfmscrobble
> > app-leechcraft/lc-laughty
> > app-leechcraft/lc-launchy
> > app-leechcraft/lc-lemon
> > app-leechcraft/lc-lhtr
> > app-leechcraft/lc-liznoo
> > app-leechcraft/lc-lmp
> > app-leechcraft/lc-mellonetray
> > app-leechcraft/lc-monocle
> > app-leechcraft/lc-musiczombie
> > app-leechcraft/lc-nacheku
> > app-leechcraft/lc-netstoremanager
> > app-leechcraft/lc-networkmonitor
> > app-leechcraft/lc-newlife
> > app-leechcraft/lc-ooronee
> > app-leechcraft/lc-otlozhu
> > app-leechcraft/lcpackgen
> > app-leechcraft/lc-pintab
> > app-leechcraft/lc-pogooglue
> > app-leechcraft/lc-popishu
> > app-leechcraft/lc-poshuku
> > app-leechcraft/lc-qrosp
> > app-leechcraft/lc-rosenthal
> > app-leechcraft/lc-sb2
> > app-leechcraft/lc-scroblibre
> > app-leechcraft/lc-secman
> > app-leechcraft/lc-seekthru
> > app-leechcraft/lc-summary
> > app-leechcraft/lc-sysnotify
> > app-leechcraft/lc-tabsessmanager
> > app-leechcraft/lc-tabslist
> > app-leechcraft/lc-touchstreams
> > app-leechcraft/lc-tpi
> > app-leechcraft/lc-vrooby
> > app-leechcraft/lc-xproxy
> > app-leechcraft/lc-xtazy
> > app-leechcraft/leechcraft-meta
> > app-leechcraft/liblaretz
> > virtual/leechcraft-browser
> > virtual/leechcraft-downloader-http
> > virtual/leechcraft-notifier
> > virtual/leechcraft-quark-sideprovider
> > virtual/leechcraft-search-show
> > virtual/leechcraft-storage-device-manager
> > virtual/leechcraft-task-show
> > virtual/leechcraft-trayarea
> > virtual/leechcraft-wysiwyg-editor
> >
> > eclass/leechcraft.eclass
> >

  Georg Rudoy

Re: [gentoo-dev] Cleaning up the installation handbook (Legacy boot / MBR / ...)

2020-05-02 Thread Georg Rudoy
On 02.05.2020 at 20:30 user Andreas K. Hüttel  wrote:
> I'm hereby volunteering to clean things up. But - I'll go the brutal way:
> * Legacy boot and MBR will get kicked out. *
> This is your chance to protest or support.

I just installed Gentoo last month on an AMD64 machine that was booted in 
legacy mode
and I had no control over that as far as I can tell.
That was a very recent, freshly ordered Ryzen 3700 Hetzner server.

Dunno if such anecdotical evidence proves anything though.

  Georg Rudoy

Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-20 Thread Georg Rudoy
пн, 20 апр. 2020 г. в 17:38, Michael Orlitzky :
> Diamond dependencies manifest mainly in delayed version
> bumps, while slyfox does all the work to make sure that the things
> already in the tree will work with the new version. This requires lots
> of careful updates to neighboring packages, and unfortunately a lot of
> cabal file hacking.

This is precisely what I meant by "doesn't scale well".

Wonder if this can be automated.

> > Dunno much about Go and I don't have a single Go package locally to
> > check. Do they do static or dynamic linking with the deps, for
> > instance? What's the language model wrt API and linking?

Lol, happy to!

> >> and C.
> >
> > More stable API (and ABI).
> >
> Definitely. The "Haskell" language changes entirely every few years.

Some say the same about C++ (and ABI does change even within a standard), so...

> I've learned the hard way that it discourages you from doing all the
> things that I just said high-quality software should do.

Again, ranging from one-off pseudo-scripts that I had to come back to
after a couple of years, to quite complicated pieces of software
running in prod and actually serving customers I had to update up to
the latest LTS after 3-4 years of inactivity, I tend to disagree. Even
the latter was a surprisingly smooth process boiling down to about an
hour or two of very effortless, mechanical and thus boring code
changes (mostly about Semigroup/Monoid hierarchy, if you wonder).

This is surely offtopic, but I just don't want to silently participate
in spreading things that aren't objectively true (even if they are
subjectively true in your/mine/etc experience).

> There's a core of mature Haskell that's pretty easy to develop against.
> (I think you just have to wait about five years with any project before
> the authors realize that changing everything every month isn't fun.) Out
> in the woods you can still get into a lot of trouble though. We now have
> the mature core stuff in ::gentoo, and the crazies out in the ::haskell
> overlay. That feels like the right mix.

I've seen transifex-client last-rited the other day and was thinking
of throwing up something in haskell (plus I have a couple of other
projects that might be useful). Let's see what it'd take to get that
into ::gentoo once I'm done.

BTW having things like servant in ::haskell as opposed to ::gentoo is
like having boost in some C++ overlay as opposed to ::gentoo.

  Georg Rudoy

Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-20 Thread Georg Rudoy
пн, 20 апр. 2020 г. в 16:51, Michael Orlitzky :
> Except that Haskell as a research language tends to inspire more "fire and 
> forget" software.

I'd say this is not the case for the last few years, but that's maybe
just my own impression from interacting with

> (And Haskell works better in Gentoo than anywhere else, in my opinion.)

Totally agreed here. That's one of the main reasons I run Gentoo
(especially before dev-haskell/stack emerged upstream a few years

> You package each dependency as a separate package. If there's a conflict
> between two packages, then... you can't have those two packages
> installed together. When that happens, you alert upstream, and try to
> convince them to be more lenient with their dependencies (again, nothing
> Haskell-specific here). Sometimes that involves code changes, but often
> it's just an edit to the cabal file. Many people follow either semver or
> the PVP ( which keeps things from getting too
> far out of control.

I'd say the Haskell-specific thing is the presence of stackage LTS
releases that people tend to stick to. For instance, beam-postgres
disappeared in recent LTSes, so some projects of mine are stuck on
older LTSes (adding that to extra-deps was a pain for reasons I don't
remember at the moment), while the others can happily use the new
ones. Libraries incompatibilities are just a matter of time in this

Sure, hacking on .cabal/package.yaml is one way to solve this, but I
wasn't sure it's reasonably robust in the long run.

Anyway, thanks for your feedback. This probably means I should stop
thinking about the general case and maybe start playing around with
packaging stuff, and then seeing where it breaks.

> If upstream absolutely insists on minor-version dependencies, then you
> either tolerate it conflicting with everything else, or leave it out of
> the tree. You probably shouldn't even be packaging a library whose API
> is distinguishable across minor releases.

That's not a matter of just the API per se. Even the library file name
encodes its deps in its name (if I understand correctly, that's the
hash in
for example). Personally I just find it hard to reason about this sort
of dependencies management. But, again, I should probably avoid trying
that and just jump head first to packaging.

> I don't see anything fundamentally different here
> between Haskell (or Go, or...)

Dunno much about Go and I don't have a single Go package locally to
check. Do they do static or dynamic linking with the deps, for
instance? What's the language model wrt API and linking?

> and C.

More stable API (and ABI).

  Georg Rudoy

Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-20 Thread Georg Rudoy
вс, 19 апр. 2020 г. в 16:09, Michael Orlitzky :
>  But please quit looking to Go as an example of anything
> anyone should be doing.

On a somewhat related note, I'd like to take this chance to ask about
packaging haskell software, which has somewhat similar issues:

1. Two different executables might depend on different versions of a
library. This is, of course, solvable via slots, so this is minor
(but, looking at a random sample of `dev-haskell/`, most of libs there
aren't slotted).
2. The dependency trees are pretty big and wide. A simple project of
mine depends on a hundred or two of dependencies on average, and the
union of all deps of all the projects I do is probably closer to a
thousand. Again, this is minor, just bear in mind the corresponding
ebuilds tree size increase.
3. What is major is the following. Let's say two executables A and B
depend on libfoo:1 and libfoo:2 respectively, and depend on the same
version of libbar. libbar itself depends on libfoo (and supports both
versions), but libbar built with libfoo:1 is incompatible with libbar
built with libfoo:2. Loosely speaking, the slot of a library is
defined by all its dependencies' _versions_.

Of all these, (3) is quite major, as it leads to exponential explosion
of the slots count. Otherwise, one might choose to carefully curate
the library versions, ensuring that no such situation arises, but this
approach is neither feasible nor possible at all for sufficiently
large packages base.

In practice, outside of Gentoo/system PM issues, this does not pose a
problem since each executable is built in an isolated sandbox and
links statically to its dependencies, so different executables can
happily be deployed alongside each other even if they have
incompatible dependencies. But looks like Gentoo's approach to haskell
is to use dynamic linking and expose the dependencies to the package
manager (which I sure agree is the right thing to do), so what should
be right the solution here?

  Georg Rudoy

Re: [gentoo-dev] Packages up for grabs

2020-04-14 Thread Georg Rudoy
On 14.04.2020 at 08:36 user Joonas Niilola  wrote:
> media-fonts/iosevka (b,v)

Can take a look at PM'ing this (unless somebody else is interested).

  Georg Rudoy

Re: [gentoo-dev] [RFC] C++ standard in ebuilds

2018-09-17 Thread Georg Rudoy
On 9/17/18 at 5:24 PM user Matt Turner  wrote:
> I don't understand what a potential solution would be.
> The various projects use -std=c++XXX because that's what their code
> requires. -std=c++XXX can't generally be changed. If a dependent
> project is incompatible that's no different than any other case of
> incompatible dependencies in Gentoo.

It can't generally be downgraded. I'd expect very few post-C++11
packages to actually break when upgrading just the standard.

> I think -std=c++XXX discussions before happened because gcc changed
> the C++ ABI with -std=c++11. I don't think that's particularly
> relevant here, since as far as I know different -std=c++XXX values
> don't change the ABI with current gcc.

noexcept specifier on functions became a part of the function type in
C++17, so it can affect name mangling there.

Given this code:

void no () noexcept (false);
void yes () noexcept (true);

void foo1 (decltype ()) {}

void foo2 (decltype ()) {}

the compiler will [1] mangle foo1 and foo2 differently depending on
whether it's built using C++ <= 14 or C++ >= 17.


  Georg Rudoy

Re: [gentoo-dev] Changing policy about -Werror

2018-09-13 Thread Georg Rudoy
On 14.09.2018 at 0:44 user Richard Yao  wrote:
> This is a really odd design decision by the GCC developers. With other 
> compilers, the separation between front end and backend is strong enough that 
> you will never have this sort of thing. It does not seem necessary to me 
> either. :/

You might be able to perform certain additional data/control flow analysis 
after things like inlining, dead code removal or devirtualization.

Moving that logic to the frontend would require essentially duplicating what's 
the optimizer's gonna do anyway, which might have negative effects on 
compilation times (both with and without optimizations) and compiler code 

BTW I'm not sure the separation on backend/frontend makes sense for modern C++ 
compilers. clang surely does some optimizations, and llvm (at least, in theory) 
is certainly able to find certain issues after more optimizer passes.

  Georg Rudoy

Re: [gentoo-dev] Changing policy about -Werror

2018-09-13 Thread Georg Rudoy
On 13.09.2018 at 16:20 user Fabian Groffen  wrote:
>> > To illustrate harmless:
>> >   warning: this statement may fall through [-Wimplicit-fallthrough=]
>> > The warning message already has it in it that it's just a pure guess.
>> One that exposed a lot of unintentional fallthoughs which were fixed
>> when reporting to upstream.
> Sure that's why the warning is there.  But you ignore the point that the
> same code compiled fine and ran fine for years without problems.

I have more than a few examples of my code compiling fine and running "fine"
for years (so that no observable defects were visible), yet newly introduced
warnings or static analyzer runs showed the defects that resolved actual bugs
when fixed. And, ironically, that also includes the fallthrough
warnings [1-3].

And cases of me stumbling upon some other legacy code, compiling it with a
newer compiler and going "WTF how it even managed to produce anything meaningful
at all?" are not uncommon.

Just my two C++ents here.


  Georg Rudoy

Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists

2017-12-08 Thread Georg Rudoy
2017-12-08 2:43 GMT-05:00 R0b0t1 <>:
> On Mon, Dec 4, 2017 at 3:39 PM, Kristian Fiskerstrand <> wrote:
> > On 12/04/2017 10:36 PM, William L. Thomson Jr. wrote:
> >> Sorry last one, directed to Alec, but all should read.
> >
> > I hope you really mean that, we've all heard you complaining about this
> > too many times already.
> >
> Inasmuch as a random person is likely to care, glancing at the
> messages shows wltjr is the more convincing of the parties involved.
> Having actually wasted time trying to figure out what is going on
> there is no mention of what ever happened from Gentoo that indicates
> anything improper took place.

Single-point samples are not really representative.

The messages wltjr sent and the bugs/PRs/etc he linked convinced me in
quite the contrary, at least, about the legitimacy of the current

  Georg Rudoy

Re: Accidental spoofing -> Re: [gentoo-dev] We Are All wltjr On This Blessed Day

2017-12-05 Thread Georg Rudoy
On 05.12.17 at 15:14 user Aaron W. Swenson <> wrote:
> One reason is to send from a nonexistent account to avoid getting
> replies in the first place.

>From and Reply-To are two separate fields.

But that, of course, depends on the way bans are implemented in the
maillist management software.

  Georg Rudoy

Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-19 Thread Georg Rudoy
On 19.11.17 at 16:49 user Martin Vaeth <> wrote:
>> Ninja is most of the speed of meson less configure time savings
> ++
> For eix, the main motivation to support meson as an
> alternative build system was to be able to use ninja...

As somebody having a big C++/Qt/cmake project: there are basically two corner 
cases for the build scenario:

1. Doing a full clean build — that's what's relevant for Gentoo, and in this 
case the speed of make or ninja is hugely offset by the compilation speed, and 
their overhead is negligible.
2. Doing an incremental build after changing a couple of files — that's what 
relevant during normal development, and arguably not that relevant for Gentoo. 
And, ninja doesn't have that much of a speed advantage lately in this case. In 
fact, make turns out to be faster in the latter if the project is using automoc 
in cmake.

Just my two cents.

  Georg Rudoy

Re: [gentoo-dev] Last rites: leechcraft

2017-01-31 Thread Georg Rudoy
2017-01-31 3:22 GMT-05:00 David Seifert <>:
> Proxy-maint has always been there, so no real excuse for all those bugs
> rotting away.

I didn't bother with finding another maint who'd proxy it for me,
yeah, that's my bad.

> Here's the deal: If you fix all those bugs within the 30
> day time period, we'll keep it in the tree. Please also modernize the
> eclass a bit, and preferably drop all ebuilds to unstable.

I'll make a new release of leechcraft itself and bump the version to
that new one, so they'll naturally be dropped to unstable, 0.6.70 and
earlier (if any) indeed could be removed. Most of the bugs, as I saw
them, are due to the current last released version being 2.5 years old
and obviously bitrotten somewhat since then.

The ebuilds I have around use multibuild to build both qt4 and qt5
versions according to use flags. Is that still relevant, or the world
has migrated to qt5 and the benefit of still supporting qt4 is not
worth the effort and clumsiness?

> Send all your PRs via Github, mentioning my handle @SoapGentoo.

Thanks, will do.

  Georg Rudoy

Re: [gentoo-dev] Last rites: leechcraft

2017-01-30 Thread Georg Rudoy
2017-01-30 13:35 GMT-05:00 David Seifert <>:
> Please do not resurrect leechcraft unless you're willing to fix the
> bugs with GCC 5 (and GCC 6) and newer dependencies. Personally, I feel
> leechcraft should probably live in an overlay instead of the tree.

I was previously proxy-maintaining it via Maxim Koltsov aka maksbotan.
What's the best way for me to step up and maintain it more directly?
Would PRs on github work?

  Georg Rudoy

Re: [gentoo-dev] moving gcc-5.2 to unstable

2015-10-01 Thread Georg Rudoy
2015-10-01 16:49 GMT+03:00 Mike Frysinger <>:

> what do people want to have in place before we move gcc-5.2 into ~arch ?

Just letting know that gcc 5 isn't compatible with clang due to

Setting gcc as a primary compiler will effectively make programs
non-buildable with clang (and perhaps icc, not sure about its status).

  Georg Rudoy

Re: [gentoo-dev] Re: useflag policies

2015-08-11 Thread Georg Rudoy
2015-08-11 11:10 GMT+01:00 Sergey Popov

 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such
 package even exists?)

Take app-text/poppler as an officially supported example.

Take x11-libs/qwt as an example of a library that gets a patched library
name to avoid collisions (at least, last time I looked into it).

I would argue this is a very desirably property for libraries in general. I
even keep my own small overlay with Qt5-enabled versions of libraries like
qxmpp, qtermwidget or liblastfm.

 Do not use REQUIRED_USE here, not needed.

You missed the fourth option: the package can not be built without Qt GUI,
but it supports building with either Qt version at the same time.

  Georg Rudoy

Re: [gentoo-dev] Re: RFC: c++14 global USE flag

2015-05-03 Thread Georg Rudoy
2015-05-03 1:30 GMT+03:00 Kent Fredric

 and python very often *is* saying Support for python ( not in, but _for_

Why should the user care if python is supported? What does python support
per se offer to the user? I would argue that what's important are the
features exposed via Python stuff (unless the user theyself is expected to
write some Python code, of course).

Same logic applies for C++14, IMHO.

 What does it matter to a user that its in C++14 ? It doesn't.

And end user is more concerned with what does this do for me.

 If a useflag doesn't tell me what it does for me, then what impetus is
 there for me to toggle it?

The consequences do matter, like pulling and building llvm/clang, if not
present already. Toggle it if you're ready to deal with the consequences
(having clang in your system, particularly).

Speaking of llvm, media-libs/mesa has llvm use flag. Why should user care
if it's llvm or whatever?

 For instance, Seamonkey doesn't have a USE=perl flag. Nor should it have

Nice example with USE=perl, thanks! git has that, for instance. Without
that, `git add -i` won't work, but I still have USE=perl, not
USE=add_interactive and possibly a bunch of other features depending on
Perl that would pull it when enabled.

  Georg Rudoy

Re: [gentoo-dev] Re: RFC: c++14 global USE flag

2015-05-03 Thread Georg Rudoy
2015-05-03 13:19 GMT+03:00 Maxim Koltsov

 Well, I can see your point. But I don't see any reasonable alternative ---
 this functionality can't be generalized by any name, except c++14 ---
 that's only thing in common.

Yes, exactly.

 Moreover, this is (I hope) a _temporal_ solution, until there's a gcc with
 needed level of support.

I have increasing concerns about that. The relevant bugreport ( ) is more than a year
old, and still no feedback on it from gcc guys.

Moreover, this bug is hardly related to C++11/14 — it's pure 03. I could
live with some kludges in C++11, but they became incompatible with some of

  Georg Rudoy

Re: [gentoo-dev] Re: RFC: c++14 global USE flag

2015-05-03 Thread Georg Rudoy
2015-05-03 13:51 GMT+03:00 Duncan

 What about a somewhat more generic flag such as newcode?  Like the bindist
 or minimal flags, this could be global, but with local descriptions very
 strongly recommended.  Similarly, like minimal, setting it globally would
 be strongly discouraged.

 In this case, the newcode local description would be something like:

 C++14 related: gcc doesn't support yet, requires clang

 ... with an appropriate use-conditional dep.

 The newcode flag would however be generic enough that it could be reused
 for C++17, etc, as well, and could obviously be phased out for any
 particular package once its specific newcode dependencies are met in
 stable -- in this case, when a supporting gcc stabilizes.

Nice idea, thanks! There are a couple of corner cases though.

 newcode would even be generic enough to be used for say qt6 when the time
 comes, if it turns out to be stuck in the qt overlay for quite some time,
 as was qt5, for the longest time,

What if a package would support (optional) builds with C++17-related
features and (optional) builds with say Qt6, and these could be toggled
independently? Does that imply having something like newcode_cpp17 and
newcode_qt4 on per-package basis?

 and the good bit is, generic meaning,
 that USE=newcode requires a dep that's still generally problematic or
 might be considered excessive to get, for optional functionality that may
 or may not be considered worth it, should be pretty obvious.

Does that imply that merely pulling clang for builds is not a
newcode-concern then, and, back to the original topic, in case of
leechcraft C++14 can be enabled unconditionally, again with unconditional
pulling of clang?

That's probably a way to go, but feels like not Gentoo-way enough (just
removing an option).

 Making that meaning even more obvious would be the fact that the flag
 would likely be packageuse-masked for many users for much of the the
 time.  That could for instance allow packages using it in-tree, before
 the dep it pulls in is itself in-tree, while still making it possible to
 unmask, for users who either already have the required overlay active, or
 who don't have it active ATM, but are willing to activate it to get the
 features it toggles.

Depending on the answer to the previous question, if all the deps are
in-tree, then there is no need in masking the useflag. It could be unmasked
on the per-package basis again, I guess? Then there is a question of the
default (globally unmasked and per-package masks vs globally masked and
per-package unmasks), but that's a relatively minor one.

  Georg Rudoy

Re: [gentoo-dev] Re: RFC: c++14 global USE flag

2015-05-02 Thread Georg Rudoy
2015-05-03 0:17 GMT+03:00 Kent Fredric

 On 3 May 2015 at 09:11, Maxim Koltsov wrote:

 LeechCraft has some functionality that is implemented in C++14 and won't
 be available otherwise.

 Can you clarify the nature of that functionality?

The Tox support module and email client module (the latter isn't in tree
yet, but a good example anyway) both rely on relaxed constexpr from C++14.

In some of the newer code I rely on automatic return type deduction and
generic lambdas, for example, or some changes in STL. Thus, it's safer to
say that basically all new modules that are written (and would be written)
since ~January 2015 would require C++14 as a baseline language.

Moreover, C++14 allows writing more efficient code (without extra levels of
indirection induced by std::function required if one is to specify the
return type of a function returning a lambda, for example) in some places.

 Shouldn't the USE flag be thus in terms of what that functionality is, not
 in terms of the dependency required to provide it?

Since the most general criteria for the functionality is whether C++14
compiler is available, c++14 or something like that seems the best fit
for the USE flag name.

We have idn or gnutls or python etc USE flags after all, not
support_international_names_in_blah or
allow_secure_news_fetching_in_foo or build_scripting_support_for_baz.

Or I just didn't get you here, sorry me in this case :)

  Georg Rudoy

Re: [gentoo-dev] RFC: c++14 global USE flag

2015-04-24 Thread Georg Rudoy
2015-04-24 20:11 GMT+01:00 Maxim Koltsov
 This is temporal, until gcc gets needed support and that version makes its
 way into ~. Then the flag won't be needed anymore, we'll just depend on new
 enough gcc and enable C++14 mode by default.

There is a problem with this. gcc has some bugs even in C++03
implementation (I have shown you the related bug the other day, can
quote it here if anyone's interested), and for now I used C++14 flag
to enable those code paths that depend on good enough standards

The problem is that the other, kludgy code paths are incompatible with
C++14 at all, so either LC is built in C++11 mode with C++11 plugins
set, or in C++14 mode, but only using clang (or any other conforming
compiler, but I'm not aware of anything like that). Effectively, even
gcc 5.1 cannot build LC in C++14 mode.

The same story will happen when C++17 gets released, so this should
probably be settled once and for all.

 I'm CCing LeechCraft author just in case.

I'm on this list, no need to :)

  Georg Rudoy

Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?

2014-09-15 Thread Georg Rudoy
2014-09-10 15:59 GMT+01:00 Tom Wijsman
 On Wed, 10 Sep 2014 13:56:04 +
 hasufell wrote:

 Tom Wijsman:
  On Tue, 09 Sep 2014 19:12:28 +
  hasufell wrote:
  Jauhien Piatlicki:
  When I accept ~arch I expect that no live ebuilds will be built. I
  think other gentoo users expect the same.
  Just because users are used to it doesn't make it better.
  How does it make it better for users that are used to what works

 It improves usability by providing additional information.

 Usability is not to be found in information that is subject to change.

How frequently the list of supported arches does shrink? Is it
statistically significant?

  Georg Rudoy

Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?

2014-09-15 Thread Georg Rudoy
2014-09-13 21:03 GMT+01:00 Peter Stuge
 I would actually expect
 there to be a policy which forbids patches on live ebuilds. Make
 another live ebuild or maybe an overlay if you want to offer a
 different set of commits than the upstream repo.

 For me, the whole point of live ebuilds is that they are the latest
 upstream code, no more, no less.

While I agree with the rest of your message, there should be
exceptions from this rule IMO.

For example, maintainers of my project in other distros keep a set of
patches to enable building it with older compilers (as I use C++11
pretty extensively, and gcc 4.7 already cannot swallow all of it). The
patches for existing code hardly change ever, probably once in a few
This is hardly applicable to Gentoo though as corresponding ebuilds
already require gcc = 4.8.

  Georg Rudoy

Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?

2014-09-15 Thread Georg Rudoy
2014-09-15 10:24 GMT+01:00 Tom Wijsman
 On Mon, 15 Sep 2014 10:11:08 +0100
 Georg Rudoy wrote:

 How frequently the list of supported arches does shrink? Is it
 statistically significant?

 The amount of software that exists makes this impossible to determine.

Let's limit our sample to Gentoo tree then. How frequently arches list
shrinked as a result of bumping  the version (because the upstream has
chosen so, not because of insufficient resources to keep testing all
previously stated arches)?

  Georg Rudoy

Re: [gentoo-dev] [RFC] qt5-build.eclass

2014-08-17 Thread Georg Rudoy
2014-08-17 22:56 GMT+04:00 Maxim Koltsov
 For the record: I /think/ that an eclass for packages supporting both qt4
 and qt5 (using multibuild.eclass) /might/ be useful. Looking forward to
 hearing Qt team opinion.

I second this opinion (especially after porting a few libraries'
ebuilds to multibuild to support qt5 builds).

I don't know, though, how (and whether it's possible) to automate
sed'ing the library names in qmake/cmake/whatever build system, since
you'll have to have different ones for qt4 and qt5 builds.

  Georg Rudoy

[gentoo-dev] Supporting both Qt4 and Qt5 builds

2014-08-11 Thread Georg Rudoy

I'm thinking of converting a few ebuilds (x11-libs/qwt,
dev-libs/kqoauth, net-libs/qxmpp among them) to support building with
both Qt4 and Qt5.

Should this better be done by adding the corresponding useflags (qt4
and qt5 respectively) or by slotting? The pros and cons for each, off
the top of my head:

+ Allows having different use flags for qt4 and qt5 builds (can't
think why that would be needed in the above examples though).
- Possibility of exponential growth of the number of slots in case
slotting would be required according to some other criteria (again,
can't think why that would be needed in the above examples).
- Requires keeping two different copies of the same ebuild with
basically the same build rules, with all the consequences.

+ Seems to be easier and doing the required trick.
+ app-text/poppler already does this.
- Enabling support for previously disabled Qt version requires
rebuilding the whole library twice.

What's your opinion on this?

I've attached the useflag-based variant as a draft.

  Georg Rudoy

Description: Binary data

Re: [gentoo-dev] gcc-4.8 may be needed in stable for www-client/chromium-38.x

2014-07-29 Thread Georg Rudoy
2014-07-29 20:28 GMT+04:00 Mike Gilbert
 A third option that comes from the chromium-packagers ML:

 3. Download and use the pre-built clang binaries from the Chromium project.

As a proxy maintainer of a package that also utilizes C++11
extensively in late releases, I'm also rather interested in having
gcc-4.8 in stable, or, otherwise, in solution #1 from the original

I remember though when I wrote in this maillist a few months ago about
having a build dep on clang I got an impression that it would be
rather inconvenient and discouraged, though feasible.

  Georg Rudoy

Re: [gentoo-dev] New global USE flags upower and udisks (split from udev in some cases)

2014-07-18 Thread Georg Rudoy
2014-07-19 0:19 GMT+04:00 Samuli Suominen
 So, I propose:

 upower with short generic description of Support for power management
 udisks with short generic description of Support for storage management

Being a proxy maint of lc-vrooby, I support this proposal.

Also, have you considered udisks2? For example, lc-vrooby can use any
of udisks:0 and udisks:2, but the rdeps that get pulled and the
backends that get compiled are controlled by the flags.

  Georg Rudoy

Re: [gentoo-dev] Subslots: should they be bumped like SONAME or on any ABI changes?

2014-06-14 Thread Georg Rudoy
14 июня 2014 г. 19:45 пользователь Ciaran McCreesh написал:

 On Sat, 14 Jun 2014 15:32:56 +
 hasufell wrote:
  Ciaran McCreesh:
   On Sat, 14 Jun 2014 16:41:51 +0200
   Michał Górny wrote:
   However, this means that we force much more rebuilds than
   This shouldn't be considered to be a problem.
  Why not?

 If not having to do lots of compiling is your goal, you're using the
 wrong distribution.

Gentoo always seemed to me to have different goals than just compiling for
the sake of compiling. // pure user impression

[gentoo-dev] Depending on clang as a compiler

2014-02-26 Thread Georg Rudoy

First of all, I'm not a Gentoo dev but a proud Gentoo user and also a
developer of a piece of software that's present in portage tree under
app-lc/ category, and Gentoo is kind of tier-1 distro for me.

I'm currently considering using C++14 in my project, particularly
features that aren't supported by gcc 4.8 and are barely supported by
4.9 [1], but the standard is already fully supported by clang 3.4 [2].
Thus I wonder how bad is actually depending on recent clang in

I ask because depending on the outcome of the discussion I'll either
start playing around with C++14 in, say, only new modules that aren't
present in the tree yet (most likely I guess) but are good candidates
for inclusion, or postpone that until gcc like 4.10 is released (less
likely but most safe I guess), or happily start using all new nifty
C++14 features in the existing codebase as well (extremely unlikely

[2] under C++1y section

  Georg Rudoy

Re: [gentoo-dev] Depending on clang as a compiler

2014-02-26 Thread Georg Rudoy
2014-02-26 12:35 GMT+04:00 Dirkjan Ochtman
 On Wed, Feb 26, 2014 at 9:26 AM, Georg Rudoy wrote:
 I'm currently considering using C++14 in my project, particularly
 features that aren't supported by gcc 4.8 and are barely supported by
 4.9 [1], but the standard is already fully supported by clang 3.4 [2].
 Thus I wonder how bad is actually depending on recent clang in

 If you want to do that, it's not a problem with me. That said, I
 probably wouldn't install packages that wanted to pull in a whole
 different toolchain unless I wanted them really badly (but on machines
 where I already have clang installed, I might not even notice).

 I'd say there's value in staying close to where the community's at, if
 you actually want your software to be used. If you don't care that
 much about your software being used by other people, nobody can stop

I thought about some policy-related problems. Good if there aren't any.

Thanks for the opinion. Depending strictly on clang is more like a
temporary measure until gcc catches up, which I hope will happen fast
enough. In this case I'll also probably stick with just introducing
the dependency in newer, probably even unpackaged modules so everyone
will be able to use what's already considered to be somewhat stable
and solid part of the app with standard gcc.

  Georg Rudoy

Re: [gentoo-dev] Depending on clang as a compiler

2014-02-26 Thread Georg Rudoy
2014-02-26 12:52 GMT+04:00 Michał Górny
 Dnia 2014-02-26, o godz. 12:26:06
 Georg Rudoy napisał(a):

 I'm currently considering using C++14 in my project, particularly
 features that aren't supported by gcc 4.8 and are barely supported by
 4.9 [1], but the standard is already fully supported by clang 3.4 [2].
 Thus I wonder how bad is actually depending on recent clang in

 Well, you should note that DEPENDing on sys-devel/clang is currently
 implemented as USE=clang in sys-devel/llvm (please don't depend on that
 directly, we will split it back ASAP). So if someone doesn't have clang
 enabled, he'd hit portage telling him to enable the flag.

And what about setting CMAKE_CXX_COMPILER in src_configure() (or where
it should be overriden)? I don't think it's a good idea to forcefully
set the compiler binary in CMakeLists.txt itself, is it better done in

  Georg Rudoy

Re: [gentoo-dev] How to support C++11 in libraries?

2013-12-20 Thread Georg Rudoy
2013/12/20 Jan Kundrát
 On Friday, 20 December 2013 12:56:43 CEST, Sven Eden wrote:

 And no, the languages are _not_ source-incompatible. That would be a

 You might argue about this, but that doesn't change these facts. This is
 absolutely valid C++98 program:

 jkt@svist ~ $ cat foo.cpp int main() {
auto int foo;
return 0;
 jkt@svist ~ $ g++ -std=c++98 -pedantic foo.cpp
 jkt@svist ~ $ echo $?

 ...which will *not* build under the C++11 mode:

 jkt@svist ~ $ g++ -std=c++0x foo.cpp
 foo.cpp: In function ‘int main()’:
 foo.cpp:2:14: error: two or more data types in declaration of ‘foo’

 Yes, -Wc++0x-compat warns about this, yes, it's included in -Wall, but it
 does not change the fact that there *is* code out there which does conform
 to C++98 standard, does *not* try to outsmart the compiler, and which will
 not build in the C++11 mode. Do we really have to be having this discussion?

The C++ Committee considered this exact case in relation to the new
meaning of `auto` and decided that such code doesn't really exist in
the wild. You won't hit auto-related issues in almost all packages in
Portage I guess.

There are more obscure cases of incompatibility though, with more
obscure error messages, like with autogenerated move ctors and the
likes. I've hitted it myself a couple of times in more or less complex
template code, but can't think of an example off the top of my head

  Georg Rudoy
  LeechCraft —

Re: [gentoo-dev] How to support C++11 in libraries?

2013-12-19 Thread Georg Rudoy
2013/12/19 Michał Górny
 In practice wouldn't that mean you'd have to add c++11 USE flag to every
 C++11 application and lib?

 No. Only the libs that change their ABI in C++11.

Which is true for every library that exchanges quite a few STL classes
with the outer world (see [1] in your original post for the list).

  Georg Rudoy
  LeechCraft —

Re: [gentoo-dev] How to support C++11 in libraries?

2013-12-18 Thread Georg Rudoy
 Either way, it is reasonable to assume that some users would like to build
 their own software and link it with system libraries. It is not reasonable
 to force these users to build in the C++11 mode, IMHO.

As far as I understand now you're just forcing users to build in C++03
mode, don't you?

  Georg Rudoy
  LeechCraft —

Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-16 Thread Georg Rudoy
2013/6/16 Zac Medico
 How about it we add a src_fetch phase, so that the VCS intricacies can be
 delegated to ebuilds/eclasses (like they are now, but without having to
 abuse src_unpack). If we include a way for src_fetch to communicate changes
 in VCS revisions to the package manager, then we'll be able to integrate
 functionality like smart-live-rebuild directly into the package manager (as
 discussed in bug 182028 [1]).

As a side note from a developer of an app that keeps various loosely
coupled modules in one repo — it'd be great if there would be a way to
also tell whether the changed revision actually affects the given
package. The default, of course, should be to assume that every change
in the repo affects a given package, but when it can be proved that
package doesn't need to be rebuilt — why bother rebuilding it? Of
course, the task of the proof lies on exact ebuild maintainer.

  Georg Rudoy
  LeechCraft —

Re: [gentoo-dev] [RFC] New category for LeechCraft

2013-03-06 Thread Georg Rudoy
2013/3/6 Diego Elio Pettenò
 On 06/03/2013 08:07, Maxim Koltsov wrote:
 1) Do you agree with adding new category?

 Not really... are you going to add any more packages?

Yes, definitely.

  Georg Rudoy
  LeechCraft —

Re: [gentoo-dev] [RFC] New category for LeechCraft

2013-03-06 Thread Georg Rudoy
2013/3/6 Diego Elio Pettenò
 How many more are you expecting?

Six components are ready to be packaged in the nearest future, four
are being developed, and there are plans for, well, like a dozen more.

Also, keeping stuff in one category allows splitting several huge
ebuilds like leechcraft-azoth into more smaller ones. Each use flag
there is basically a separate plugin, and as plugins could be built
separately, there is no need in recompiling all of them just to
install/uninstall/etc a single one. That single azoth thingie adds
around 30 more packages.

  Georg Rudoy
  LeechCraft —

Re: [gentoo-dev] [RFC] New category for LeechCraft

2013-03-06 Thread Georg Rudoy
2013/3/6 Dirkjan Ochtman
 On Wed, Mar 6, 2013 at 10:15 AM, Maxim Koltsov wrote:
 Not that you have to explain it, but that leads me to wonder if (a)
 there are other Gentoo devs who would maintain this stuff if you
 become disinterested
Yep, Pinkbyte is also co-maintaining, and in case of something
terrible I could try becoming a maintainer, since I'm also a long-time
Gentoo user :)

(b) how many users there even are for LeechCraft-related packages.
Summer estimates are around 10k more or less permanent users.

 FWIW, in Debian's popcon, there seems to be about 6 users who have
 LeechCraft installed (which ranks it slightly south of 70,000th).
Debian's popcon is slightly irrelevant as LC isn't available in Debian repos.

  Georg Rudoy
  LeechCraft —

Re: [gentoo-dev] [RFC] New category for LeechCraft

2013-03-05 Thread Georg Rudoy
2013/3/6 Maxim Koltsov
 1) Do you agree with adding new category?
Yep :)

 2) How should we call it: app-leechcraft, leechcraft-base or anything else?
Personally I'd prefer app-leechcraft (or maybe app-lc to save some
typing). I doubt there will be anything but that single category in
the foreseeable future, and leechcraft-base suggests also something
like leechcraft-addons.

  Georg Rudoy
  LeechCraft —

Re: [gentoo-dev] RFC: new qt category

2013-01-17 Thread Georg Rudoy
2013/1/17 Chris Reffett
 but I think dropping the qt- prefix
 will lead to overly generic/already existing package names: gui
 declarative dbus core opengl etc. I don't see any value from
 dropping the prefix that would justify this.


  Georg Rudoy
  LeechCraft —

Re: [gentoo-dev] systemd/udev split

2013-01-14 Thread Georg Rudoy
2013/1/14 Diego Elio Pettenò
 I don't want systemd and I don't want eudev. And I'm not alone I'm sure.

You are definitely not alone (though I'm not a gentoo dev).

I think it makes sense to keep it split as long as udev is buildable
without systemd and until eudev proves to be stable enough. After all,
sadly, upstream udev has much larger userbase than eudev.

  Georg Rudoy
  LeechCraft —

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/boost: boost-1.46.1-r1.ebuild metadata.xml boost-1.49.0-r1.ebuild boost-1.51.0-r1.ebuild ChangeLog boost-1.47.0.ebuild boost-1.35.0-

2012-11-01 Thread Georg Rudoy
2012/11/1 Jamie Learmonth
 Firstly, why are you guys always so mad, and secondly why don't we just
 start packaging more of these packages as binaries then or bundling the
 needed version like the rest of the world does anyways?

So are you suggesting to package all the binaries that depend upon too
old boost, or upon too new boost, or whatever, as binaries?

I always thought those few -bin packages are -bin just because they
take quite a lot time to be compiled.

 So how about we transform this distro into one where decisions are made on
 real world benefits, not purist ideals, and technical giants help each other
 to make breakthroughs unimaginable to others because they are smarter, work
 together, and the most kick-ass geeks on this interweb. I want to keep using
 Gentoo not just because of the pretty colours on the eix output or because
 when I run emerge --world in a coffee shop all the chicks think I'm that guy
 from the Hackers movie, or even because my favourite color is purple. I want
 to keep using Gentoo because the team effing rocks!

 Who's with me?

I hope you'd forgive I'd oppose that suggestion, given I'm not a
Gentoo dev but just a C++ developer who uses Gentoo as his primary
(and, in fact, only) distro and loves it a lot.

Gentoo has a wonderful community which I truly love, but first thing
about a distro is how it helps you to solve your problems and achieve
your goals. I'd surely miss the slotted Boost, since it was one of the
things I needed for my C++ thingies and which I loved, but Diego's
arguments are sane and reasonable, and I also had quite some PITA with
old/new/whatever Boost versions, so OK, I can live without slotted
Boost. But please, leave Gentoo as that powerful distro that really
helps to work and code. I want it source-based. I want to be able to
seamlessly have Qt 4.8., or cabal integrated with Portage (kudos
to gentoo-haskell guys, they're doing great work), and things like

That makes even more sense given the new C++11 standard and it's
gradual implementation in gcc. One could just as well say let's just
keep the newest gcc 4.7 in portage, since there is software that fails
to build with gcc 4.6 and earlier, for example.

  Georg Rudoy
  LeechCraft —

Re: [gentoo-dev] Voting on adding Leechcraft to the tree

2011-07-20 Thread Georg Rudoy

I'm one of LeechCraft developers, and Maxim asked me to assist him in
resolving any questions regarding the app should they occur. I'm also
using Gentoo and maintain the ebuilds in the rion overlay, so I hope
I'd be able to assist in resolving corresponding issues as well.

Seems like the only issue that needs clarification now is the number
of packages and the need in separate eclass. Actually, there are 32
ebuilds for now (and new will be added as new modules are written),
and the eclass contains some common procedures for them.

And Maxim gave a link only to net-misc/ category in his original
message, while related ebuilds are also in www-client/, www-misc/,
virtual/ categories, for example. And, well, while he was true
regarding the amount of active developers (we've got around 4-6 of
them who regularly contribute new code), seems like he was a bit
pessimistic regarding the popularity, but that's rather unimportant
issue, according to Gentoo's policies.

  Georg Rudoy
  LeechCraft —