ew 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 — http://leechcraft.org
r 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 cm
software.
--
Georg Rudoy
n
> 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
actions.
--
Georg Rudoy
taining 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
t 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
L__)
```
in the template inside the eclass.
If everybody's happy with that, I'll be also happy to open a PR with
that change.
--
Georg Rudoy
v proves to be stable enough. After all,
sadly, upstream udev has much larger userbase than eudev.
--
Georg Rudoy
LeechCraft — http://leechcraft.org
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
gory in
the foreseeable future, and leechcraft-base suggests also something
like leechcraft-addons.
--
Georg Rudoy
LeechCraft — http://leechcraft.org
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 — http://leechcraft.org
aft-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
LeechCr
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 — http://leechcraft.org
of the proof lies on exact ebuild maintainer.
--
Georg Rudoy
LeechCraft — http://leechcraft.org
ode, don't you?
--
Georg Rudoy
LeechCraft — http://leechcraft.org
outer world (see [1] in your original post for the list).
--
Georg Rudoy
LeechCraft — http://leechcraft.org
oesn'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
the existing codebase as well (extremely unlikely
:)).
[1] http://gcc.gnu.org/projects/cxx1y.html
[2] http://clang.llvm.org/cxx_status.html under C++1y section
--
Georg Rudoy
2014-02-26 12:35 GMT+04:00 Dirkjan Ochtman :
> On Wed, Feb 26, 2014 at 9:26 AM, Georg Rudoy <0xd34df...@gmail.com> 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
2014-02-26 12:52 GMT+04:00 Michał Górny :
> Dnia 2014-02-26, o godz. 12:26:06
> Georg Rudoy <0xd34df...@gmail.com> napisał(a):
>
>> I'm currently considering using C++14 in my project, particularly
>> features that aren't supported by gcc 4.8 and are ba
14 июня 2014 г. 19:45 пользователь "Ciaran McCreesh" <
ciaran.mccre...@googlemail.com> написал:
>
> 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 rebui
t 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
;m also rather interested in having
gcc-4.8 in stable, or, otherwise, in solution #1 from the original
mail.
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
ing 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
kqoauth-0.98-r2.ebuild
Description: Binary data
27;
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
" for users that are used to what works
>> > well?
>>
>> 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
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
months.
This is hardly applicable to Gentoo though as corresponding ebuilds
already require gcc >= 4.8.
--
Georg Rudoy
2014-09-15 10:24 GMT+01:00 Tom Wijsman :
> On Mon, 15 Sep 2014 10:11:08 +0100
> Georg Rudoy <0xd34df...@gmail.com> wrote:
>
>> How frequently the list of supported arches does shrink? Is it
>> statistically significant?
>
> The amount of software that exists m
mistic regarding the popularity, but that's rather unimportant
issue, according to Gentoo's policies.
--
Georg Rudoy
LeechCraft — http://leechcraft.org
/github.com/0xd34df00d/leechcraft/commit/fa8ff9dc315e894fada4aaf73534bdfc15121cb3
[3]
https://github.com/0xd34df00d/leechcraft/commit/6b26961b52b6e8277db39b084f483d1959253313
--
Georg Rudoy
issues after more optimizer passes.
--
Georg Rudoy
e mangling there.
Given this code:
void no () noexcept (false);
void yes () noexcept (true);
void foo1 (decltype (&no)) {}
void foo2 (decltype (&yes)) {}
the compiler will [1] mangle foo1 and foo2 differently depending on
whether it's built using C++ <= 14 or C++ >= 17.
[1] https://gcc.godbolt.org/z/xmZTBO
--
Georg Rudoy
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
r 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
e. 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
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
C++14.
--
Georg Rudoy
et 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
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
ke programs
non-buildable with clang (and perhaps icc, not sure about its status).
--
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
s. 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
tatic 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
ojects 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
4 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
c-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
me treatment, although
it has a single net-im/kadu[xmpp] revdep. Maybe worth dropping it to
m-n then.
--
Georg Rudoy
46 matches
Mail list logo
