Re: [gentoo-dev] New project: LLVM

On Sat, Aug 20, 2016 at 5:41 AM, james <gar...@verizon.net> wrote: > On 08/19/2016 05:05 PM, C Bergström wrote: >> >> On Sat, Aug 20, 2016 at 4:52 AM, james <gar...@verizon.net> wrote: >> >> >> > > You removed your rude remark::: > " Sorr

Re: [gentoo-dev] New project: LLVM

On Sat, Aug 20, 2016 at 4:52 AM, james wrote: >> Back to my own glass house.. It will take a few years, but I am trying >> to make it easier (internally) to expose in some clear way all the >> pieces which compose a fine tuning per-processor. If this was "just" >>

Re: [gentoo-dev] New project: LLVM

2:02 AM, james <gar...@verizon.net> wrote: > On 08/19/2016 11:15 AM, C Bergström wrote: >> >> On Fri, Aug 19, 2016 at 11:01 PM, Luca Barbato <lu_z...@gentoo.org> wrote: >>> >>> BTW is pathscale ready to be used as system compiler as well? >> >> >&g

Re: [gentoo-dev] New project: LLVM

On Fri, Aug 19, 2016 at 11:01 PM, Luca Barbato wrote: > BTW is pathscale ready to be used as system compiler as well? I wish, but no. We have known issues when building grub2, glibc and the Linux kernel at the very least. Someone* did report a long time ago that with their

Re: [gentoo-dev] New project: LLVM

@mgorny may be able to help with some of this and has quite a bit of experience building clang/llvm. Where I work we use a "wrapper" that helps coordinate a lot of the moving pieces. https://github.com/pathscale/llvm-suite/ This may not be the perfect "gentoo" way to handle it, but the approach

Re: [gentoo-dev] impending c++11 clusterfuck?

One thing to point out.. trying to detect and using vX are just hacks for what this really is - Adding abi (C++STL/ABI) information to the ebuilds/packages. To extend this - what happens when you have a compiler that isn't compatible with the system default? When the package is merged should some

Re: [gentoo-dev] impending c++11 clusterfuck?

On Mon, Nov 30, 2015 at 10:56 AM, Gregory M. Turner wrote: > I'm quoting myself from bug #566328 here. These were off-the-cuff > remarks that got away from me and became a call-to-arms... > > (In reply to Michał Górny from comment #7) >> This is never this simple. C++11 can

Re: [gentoo-dev] Re: Git workflow

On Mon, Jul 6, 2015 at 2:15 AM, William Hubbs willi...@gentoo.org wrote: On Sun, Jul 05, 2015 at 07:17:26PM +0400, Jason Zaman wrote: On Sun, Jul 05, 2015 at 12:03:29PM +0700, C Bergström wrote: On Sun, Jul 5, 2015 at 11:31 AM, Duncan 1i5t5.dun...@cox.net wrote: C Bergström posted on Sun

Re: [gentoo-dev] Git workflow

On Sun, Jul 5, 2015 at 1:56 AM, hasufell hasuf...@gentoo.org wrote: On 07/04/2015 08:17 PM, C Bergström wrote: I realize that this is subject to lots of different opinions and that my input doesn't carry much weight - At least I thought it's a topic that should be brought up (again

[gentoo-dev] Git workflow

I realize that this is subject to lots of different opinions and that my input doesn't carry much weight - At least I thought it's a topic that should be brought up (again?) - To start I hate git.. I have used it for years now and the multitude of ways that are possible to accomplish

Re: [gentoo-dev] Git workflow

On Sun, Jul 5, 2015 at 3:33 AM, Alon Bar-Lev alo...@gentoo.org wrote: On 4 July 2015 at 23:28, Alexandre Rostovtsev tetrom...@gentoo.org wrote: On Sun, 2015-07-05 at 02:16 +0700, C Bergström wrote: 2) I don't understand your comment about signatures. Gpg commit signatures [1] which

Re: [gentoo-dev] Git workflow

On Sun, Jul 5, 2015 at 1:42 AM, Rich Freeman ri...@gentoo.org wrote: On Sat, Jul 4, 2015 at 2:17 PM, C Bergström cbergst...@pathscale.com wrote: What I personally prefer is a rebase workflow. The recommendation is to rebase when practical. Rebasing makes the history look clean

Re: [gentoo-dev] Git workflow

On Sun, Jul 5, 2015 at 6:54 AM, Peter Stuge pe...@stuge.se wrote: C Bergström wrote: 3) Ever tried to make a patch of the *actual* merge commit? Can one of the advocates of merge show me the git command to do that? (Sure you can diff between 2 commits, but the merge commit likes to avoid

Re: [gentoo-dev] Re: Git workflow

On Sun, Jul 5, 2015 at 11:31 AM, Duncan 1i5t5.dun...@cox.net wrote: C Bergström posted on Sun, 05 Jul 2015 01:17:41 +0700 as excerpted: I super don't like merge workflows. 1) merge commits are confusing at best and normal tools don't display and work with them as you'd always expect git log

Re: [gentoo-dev] Anti-spam changes: proposal to drop spammy mail

On Sat, May 23, 2015 at 1:18 PM, J. Roeleveld jo...@antarean.org wrote: On 11 May 2015 15:59:40 CEST, Rich Freeman ri...@gentoo.org wrote: On Mon, May 11, 2015 at 9:37 AM, C Bergström cbergst...@pathscale.com wrote: Sorry to shoot and run, but I think you're trying to tackle this problem

Re: [gentoo-dev] Anti-spam changes: proposal to drop spammy mail

Sorry to shoot and run, but I think you're trying to tackle this problem in the wrong way. The problem isn't to drop the mail. The solution is to change email hosting providers. As a non-profit I believe Google hosted apps would be an option (free). Then it would be possible to simply leverage

Re: [gentoo-dev] Anti-spam changes: proposal to drop spammy mail

What I'm describing is not gmail - it's everything that gmail has and offers, but @gentoo.org domain. I'm using it right now in fact. You get the web interface, IMAP, POP, 2 token authentication (if you want to enabled it) and lots of other things. etc etc It used to be free, but now google

Re: [gentoo-dev] Anti-spam changes: proposal to drop spammy mail

On Mon, May 11, 2015 at 11:55 PM, Rich Freeman ri...@gentoo.org wrote: On Mon, May 11, 2015 at 11:21 AM, C Bergström cbergst...@pathscale.com wrote: On Mon, May 11, 2015 at 9:59 PM, Rich Freeman ri...@gentoo.org wrote: On Mon, May 11, 2015 at 10:44 AM, C Bergström cbergst...@pathscale.com

Re: [gentoo-dev] Anti-spam changes: proposal to drop spammy mail

Look at the forwarding which is already happening. They are already giving that big company the emails. That big company gets a copy of every email which is posted publicly already. Are you concerned about their privacy policy? Are you concerned about them complying to a government demand or

Re: [gentoo-dev] [OT] pkgcore bountry or contract work

On Sun, Feb 22, 2015 at 4:36 AM, Brian Dolbec dol...@gentoo.org wrote: On Sun, 22 Feb 2015 03:32:58 +0700 C Bergström cbergst...@pathscale.com wrote: PathScale is interested to hire a full time dev (for at least a few months) in order to bring pkgcore back to life. General goals 1) Make

[gentoo-dev] [OT] pkgcore bountry or contract work

PathScale is interested to hire a full time dev (for at least a few months) in order to bring pkgcore back to life. General goals 1) Make it capable of parsing/handling the current portage tree (We'll contribute all this work upstream/open source) 2) Improve the web based front-end

Re: [gentoo-dev] arm64 update

On Thu, Feb 19, 2015 at 3:27 AM, Tom Gall tg...@gentoo.org wrote: So first, for those interested in cheap arm64 hardware, the first 96 board is going to start shipping in March for ~$129. The HiKey board is an 8 way 64 bit ARM board with 8 A53 cores. (No A57s bummer!) Only had a gig of

Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)

On 09/14/14 08:24 PM, Jauhien Piatlicki wrote: 14.09.14 15:23, Jauhien Piatlicki написав(ла): Another question: will it be possible to maintain a copy of tree on github to make contributions for users simpler (similarly to e.g. science overlay)? (Can it somehow be combined with proposed

Re: [gentoo-dev] gentoo git workflow

On 09/15/14 02:34 AM, hasufell wrote: William Hubbs: On Sun, Sep 14, 2014 at 08:04:12PM +0200, Andreas K. Huettel wrote: Deciding on a _commit policy_ should be fairly straightforward and we already have one point * gpg sign every commit (unless it's a merged branch, then we only care about

Re: [gentoo-dev] Packages up for grabs

On 06/ 3/14 02:50 AM, Parker Schmitt wrote: I think we need to keep the opencl stuff. In a few weeks I'll have time to help. I work for PathScale and can probably take on dev-lang/ekopath path64 - while I'd like it to continue - it could(should?) be retired - I'd need someone to help

Re: [gentoo-dev] Re: LTO use in the tree

On 04/27/14 06:23 PM, Rich Freeman wrote: On Sat, Apr 26, 2014 at 10:37 PM, C. Bergström cbergst...@pathscale.com wrote: #2 The only reference to anything which the compiler could impact is Use Boyer-Moore (and unroll its inner loop a few times). Finding out which flag controls that for ${CC

Re: [gentoo-dev] Re: LTO use in the tree

On 04/27/14 02:58 AM, Martin Vaeth wrote: Rich Freeman ri...@gentoo.org wrote: FWIW the list of packages I have issues with include: Not sure whether this is the right place to post it. It's interesting to see that rather lengthy list. From a compiler engineer perspective I'd like to toss in

Re: [gentoo-dev] Re: LTO use in the tree

On 04/27/14 09:14 AM, Alex Xu wrote: On 26/04/14 08:34 PM, C. Bergström wrote: Pragmatically nobody gives a f* if grep has been optimized to the max since it's usually not the bottleneck. http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html My point about grep + LTO

Re: [gentoo-dev] Portage team, Zac's development break and stepping down as lead

Drive-by trolling comment but I wish the effort to keep porkage alive would have instead been directed towards pkgcore.

Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)

On 01/13/14 03:43 PM, Alexander Berntsen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13/01/14 09:39, C. Bergström wrote: Drive-by trolling comment but I wish the effort to keep porkage alive would have instead been directed towards pkgcore. Realistically, we have to keep

Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)

On 01/13/14 04:31 PM, Fabio Erculiani wrote: On Mon, Jan 13, 2014 at 10:15 AM, C. Bergström cbergst...@pathscale.com wrote: On 01/13/14 03:43 PM, Alexander Berntsen wrote: Where I work uses pkgcore[1], but not the areas which are generally beneficial to the whole community. (We use it as part

Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)

On 01/14/14 12:37 AM, Greg KH wrote: On Mon, Jan 13, 2014 at 04:15:37PM +0700, C. Bergström wrote: At the end of the day we have one codebase which is engineered and another which has evolved. I'll take an evolved codebase over engineered anyday. You do realize that is exactly why Linux has

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

On 12/19/13 03:20 PM, Michał Górny wrote: Dnia 2013-12-19, o godz. 00:56:31 C. Bergström cbergst...@pathscale.com napisał(a): On 12/19/13 12:47 AM, Kent Fredric wrote: On 19 December 2013 06:33, Jan Kundrát j...@gentoo.org wrote: I'm worried by the cost of such a policy, though, because we

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

On 12/19/13 03:35 PM, Michał Górny wrote: Dnia 2013-12-19, o godz. 15:28:46 C. Bergström cbergst...@pathscale.com napisał(a): On 12/19/13 03:20 PM, Michał Górny wrote: Dnia 2013-12-19, o godz. 00:56:31 C. Bergström cbergst...@pathscale.com napisał(a): On 12/19/13 12:47 AM, Kent Fredric

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

On 12/18/13 02:54 PM, Michał Górny wrote: Hello, folks. Hi snip Basically, I've hit this with sys-devel/llvm. A user has requested lldb support to be enabled in the ebuild [2]. Sadly, lldb requires C++11 to be used, and this means that whole LLVM needs to become C++11 enabled. And then, it

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

On 12/18/13 11:29 PM, Jan Kundrát wrote: On Wednesday, 18 December 2013 14:58:07 CEST, hero...@gentoo.org wrote: I think it is better achieved by a (simple and stupid) global CXXFLAGS. Adding an extra USE flag feels a little over-engineering. What compiler flag do you propose to use? Note

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

On 12/18/13 11:50 PM, Jan Kundrát wrote: On Wednesday, 18 December 2013 17:37:56 CEST, C. Bergström wrote: From the perspective of a compiler vendor - I must ask why not? There is code out there which builds fine under C++98, but fails to build when C++11 is enabled (as but one exmaple

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

On 12/19/13 12:33 AM, Jan Kundrát wrote: On Wednesday, 18 December 2013 18:05:46 CEST, C. Bergström wrote: If moving to C++11 - Isn't that considered just part of the work along the path? There's some clang tools to help with the migration, but I don't think anyone expects it to be zero work

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

On 12/19/13 12:47 AM, Kent Fredric wrote: On 19 December 2013 06:33, Jan Kundrát j...@gentoo.org wrote: I'm worried by the cost of such a policy, though, because we would suddenly have to patch some unknown amount of software Given the nature that changing that CXX Flag globally for all users

Re: [gentoo-dev] git-r3: initial draft for review

Do you have any plans to add support for sparse checkout? Something like this |cd parentdir git clone -n url cd repo_dir git remote add –f name url git config core.sparsecheckout true echo /foldername/ .git/info/sparse-checkout git checkout tagname (Credit goes to :

Re: [gentoo-dev] New eclass cuda.eclass

On 11/26/12 12:59 AM, Rick Zero_Chaos Farina wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/25/2012 11:47 AM, Justin wrote: Hi, I would like to introduce a new eclass for packages using the nvidia cuda compiler suite. Currently the eclass simply sanitize the NVCCFLAGS. May be

Re: [gentoo-dev] Six month major project on Gentoo

On 12/15/11 01:05 AM, Christian Ruppert wrote: On Wednesday 14 December 2011 16:36:42 Gaurav Saxena wrote: Hello all, I am interested in doing my final year computer scence project on gentoo. I would be having a duration of six months to work on the project. Could you please suggest me some

[gentoo-dev] EKOPath/Path64 compiler ebuilds + support

Hi Recently a couple new ebuilds were added to the portage tree and I felt it's worthwhile to give a friendly heads up. So without further ado let me introduce EKOPath and Path64. EKOPath - This is a binary installer that comes from one of the nightly PathScale builds. The source to the

Re: [gentoo-dev] sandbox-1.3 testing request

Mike Frysinger wrote: can people who feel adventurous unmask sandbox-1.3.2 and give it a spin on their systems before i unmask it for everyone ... if you hit a bug, use bugzilla mmkay -mike I pulled the latest git sources about a week ago and seemed like I hit a regression in the

Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

Duncan wrote: C. Bergström [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 16 Sep 2008 22:30:51 +0200: 1) Add a symlink in GNU patch ebuild to symlink patch to gpatch You mean the other way, right? gpatch - patch , since we already have patch, and need gpatch

Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

Ulrich Mueller wrote: On Wed, 17 Sep 2008, C. Bergström wrote: Here's another idea and I don't know why I didn't think of it sooner.. Instead of any system change to the patch ebuild.. Inside the eutils.eclass do a quick check for gpatch and if it exists use that vs patch

Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

Fabian Groffen wrote: On 17-09-2008 09:59:42 +0200, C. Bergström wrote: Why not simply alias patch=gpatch in profile.bashrc? See the FreeBSD profile for an example. I'd like to package portage for OpenSolaris and have it just drop-in work so modifications like what you suggest

Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

Fabian Groffen wrote: On 17-09-2008 10:21:17 +0200, Santiago M. Mola wrote: Why not simply alias patch=gpatch in profile.bashrc? See the FreeBSD profile for an example. I'd like to package portage for OpenSolaris and have it just drop-in work so modifications like what you suggest

Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

Fabian Groffen wrote: On 17-09-2008 10:41:07 +0200, C. Bergström wrote: By the way, I'm against this stuff. I rather see a PATH solution involved. Portage already has a DEFAULT_PATH, and if someone refuses to install patch, one could always use a special directory with symlinks to the g

[gentoo-dev] Request for feedback on GNU Patch change

To start.. I humbly ask for no response vs starting a flamewar.. Short version: The proposed change will require changes in two places, but may cause other breakage and or simply not settle well with general consensus. 1) Add a symlink in GNU patch ebuild to symlink patch to gpatch 2) Change

Re: [gentoo-dev] Re: gentoo-dev vs lkml?

This is a great link for the leaders, developers and just about anyone else involved in our community. While this is solely my opinion I do humbly ask anyone with a spare few minutes to step back and take a look. http://video.google.com/videoplay?docid=-4216011961522818645q=poisonous+people