[gentoo-dev] ghc support in multilib-build.eclass
Hi, Right now, the configuration header generated for packages like openssl by multilib-build.eclass doesn't play nicely with ghc. Long story short, ghc runs `gcc -E` with `-undef`, which causes the `#if defined(__x86_64__)` branch (or whatever is the relevant one) to be missed, falling back to ``` error "No ABI matched, please report a bug to bugs.gentoo.org" ``` There is already a workaround for Swig in the template. I propose extending this workaround with a very small change, replacing ``` #elif defined(SWIG) ``` with ``` #elif defined(SWIG) || defined(__GLASGOW_HASKELL__) ``` 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
Re: [gentoo-dev] Last rites: app-leechcraft/*, virtual/leechcraft-*
вт, 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-*
The PR ( https://github.com/gentoo/gentoo/pull/15938 ) 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 / ...)
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
пн, 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? > > FORGET I MENTIONED IT 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
пн, 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 ago). > 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 (https://pvp.haskell.org/) 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 case. 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 libHSregex-base-0.94.0.0-541xQVwwNRiBGjsNKmOPoy-ghc8.6.5.so 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
вс, 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
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
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.
[1] https://gcc.godbolt.org/z/xmZTBO
--
Georg Rudoy
Re: [gentoo-dev] Changing policy about -Werror
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 maintenance. 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
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. [1] https://github.com/0xd34df00d/leechcraft/commit/663b69249cd61d1cbd490a3eee7909ae26d03240 [2] https://github.com/0xd34df00d/leechcraft/commit/fa8ff9dc315e894fada4aaf73534bdfc15121cb3 [3] https://github.com/0xd34df00d/leechcraft/commit/6b26961b52b6e8277db39b084f483d1959253313 -- Georg Rudoy
Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists
2017-12-08 2:43 GMT-05:00 R0b0t1 <r03...@gmail.com>: > > On Mon, Dec 4, 2017 at 3:39 PM, Kristian Fiskerstrand <k...@gentoo.org> 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 actions. -- Georg Rudoy
Re: Accidental spoofing -> Re: [gentoo-dev] We Are All wltjr On This Blessed Day
On 05.12.17 at 15:14 user Aaron W. Swenson <titanof...@gentoo.org> 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
On 19.11.17 at 16:49 user Martin Vaeth <mar...@mvath.de> 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 3:22 GMT-05:00 David Seifert <s...@gentoo.org>: > 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 13:35 GMT-05:00 David Seifert <s...@gentoo.org>: > 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 16:49 GMT+03:00 Mike Frysinger <vap...@gentoo.org>: > 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 https://llvm.org/bugs/show_bug.cgi?id=23529 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 11:10 GMT+01:00 Sergey Popov pinkb...@gentoo.org: 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 1:30 GMT+03:00 Kent Fredric kentfred...@gmail.com: 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 one. 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 13:19 GMT+03:00 Maxim Koltsov maksbo...@gentoo.org: 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 ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60177 ) 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 C++14. -- Georg Rudoy
Re: [gentoo-dev] Re: RFC: c++14 global USE flag
2015-05-03 13:51 GMT+03:00 Duncan 1i5t5.dun...@cox.net: 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-03 0:17 GMT+03:00 Kent Fredric kentfred...@gmail.com: On 3 May 2015 at 09:11, Maxim Koltsov maksbo...@gentoo.org 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 20:11 GMT+01:00 Maxim Koltsov maksbo...@gentoo.org: 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 support. 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-10 15:59 GMT+01:00 Tom Wijsman tom...@gentoo.org: On Wed, 10 Sep 2014 13:56:04 + hasufell hasuf...@gentoo.org wrote: Tom Wijsman: On Tue, 09 Sep 2014 19:12:28 + hasufell hasuf...@gentoo.org 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 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
Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?
2014-09-13 21:03 GMT+01:00 Peter Stuge pe...@stuge.se: 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 months. 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 10:24 GMT+01:00 Tom Wijsman tom...@gentoo.org: 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 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 22:56 GMT+04:00 Maxim Koltsov maksbo...@gentoo.org: 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
Hi, 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: slotting: + 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. useflags: + 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 kqoauth-0.98-r2.ebuild Description: Binary data
Re: [gentoo-dev] gcc-4.8 may be needed in stable for www-client/chromium-38.x
2014-07-29 20:28 GMT+04:00 Mike Gilbert flop...@gentoo.org: 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 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
Re: [gentoo-dev] New global USE flags upower and udisks (split from udev in some cases)
2014-07-19 0:19 GMT+04:00 Samuli Suominen ssuomi...@gentoo.org: 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?
14 июня 2014 г. 19:45 пользователь Ciaran McCreesh ciaran.mccre...@googlemail.com написал: On Sat, 14 Jun 2014 15:32:56 + hasufell hasuf...@gentoo.org wrote: Ciaran McCreesh: On Sat, 14 Jun 2014 16:41:51 +0200 Michał Górny mgo...@gentoo.org wrote: However, this means that we force much more rebuilds than necessary. 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
Hi! 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 ebuilds? 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 :)). [1] http://gcc.gnu.org/projects/cxx1y.html [2] http://clang.llvm.org/cxx_status.html under C++1y section -- Georg Rudoy
Re: [gentoo-dev] Depending on clang as a compiler
2014-02-26 12:35 GMT+04:00 Dirkjan Ochtman d...@gentoo.org: 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 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 ebuilds? 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 you. 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 12:52 GMT+04:00 Michał Górny mgo...@gentoo.org: 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 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 ebuilds? 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 ebuild? -- Georg Rudoy
Re: [gentoo-dev] How to support C++11 in libraries?
2013/12/20 Jan Kundrát j...@gentoo.org:
On Friday, 20 December 2013 12:56:43 CEST, Sven Eden wrote:
And no, the languages are _not_ source-incompatible. That would be a
scandal!
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 $?
0
...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
unfortunately.
--
Georg Rudoy
LeechCraft — http://leechcraft.org
Re: [gentoo-dev] How to support C++11 in libraries?
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 — http://leechcraft.org
Re: [gentoo-dev] [RFC] SRC_URI behaviour
2013/6/16 Zac Medico zmed...@gentoo.org: 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 — http://leechcraft.org
Re: [gentoo-dev] [RFC] New category for LeechCraft
2013/3/6 Diego Elio Pettenò flamee...@flameeyes.eu: 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
Re: [gentoo-dev] [RFC] New category for LeechCraft
2013/3/6 Diego Elio Pettenò flamee...@flameeyes.eu: 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 — http://leechcraft.org
Re: [gentoo-dev] [RFC] New category for LeechCraft
2013/3/6 Dirkjan Ochtman d...@gentoo.org: On Wed, Mar 6, 2013 at 10:15 AM, Maxim Koltsov maksbo...@gentoo.org 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 — http://leechcraft.org
Re: [gentoo-dev] [RFC] New category for LeechCraft
2013/3/6 Maxim Koltsov maksbo...@gentoo.org: 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 — http://leechcraft.org
Re: [gentoo-dev] RFC: new qt category
2013/1/17 Chris Reffett creff...@gentoo.org: 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. +1. -- Georg Rudoy LeechCraft — http://leechcraft.org
Re: [gentoo-dev] systemd/udev split
2013/1/14 Diego Elio Pettenò flamee...@flameeyes.eu: 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 — http://leechcraft.org
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/1 Jamie Learmonth jamie-li...@boxlightmedia.com: 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. 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 — http://leechcraft.org
Re: [gentoo-dev] Voting on adding Leechcraft to the tree
Hi! 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 — http://leechcraft.org
