[gentoo-dev] tinderbox infrastructure project

On 07/09/2018 15:11, Andreas K. Huettel wrote: >> - Invest significantly in Infrastructure spending to fund ambitious >> projects. > > You need people who work on that first. > > Suggestion: Found a tinderbox project, get toralf, kensington, zerochaos, > mgorny, whoelse? on board, integrate

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

On 28/08/2018 00:46, Michael Mol wrote: > I can say that if the licenses are habitually misidentified, I could not use > Gentoo's portage tree in my job without extensive and ongoing revalidation of > the license metadata. > > There are, in fact, automated tools for advising about the license

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

On 26/08/2018 13:15, Michał Górny wrote: > I'm not aware of any major implications. However, I think that if we > provide for the distinction, the distinction should be used correctly. Makes sense. Note that this might also be an argument for _not_ providing such fine-grained distinction

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

On 26/08/2018 12:53, Mart Raudsepp wrote: > The common issue here is that upstream COPYING files really do only > talk about one of the versions. And then you get to validate or source > files to be sure that they do have a "or later" clause in them. And > then on each bump you ideally should

Re: [gentoo-dev] Idea for a new project: gentoo-libs

On 23/06/2018 09:43, Mikle Kolyada wrote: > But how would it serve gentoo itself? Lots of packages in the distro > have dead upstream but still work. > Why would you want to make gentoo an upstream area rather than moving a > dead project itself, say, > to github and do the job there? +1 I like

Re: [gentoo-dev] [RFC] multiversion ebuilds

On 12/05/2018 14:20, Gerion Entrup wrote: > just an idea for now. But what you think about multiversion ebuilds? > Technically this could be realized with the following line in the ebuild > itself: > ``` > VERSIONS=( 3.0.11 3.0.12 3.1 ) > ``` > > and the filename without version: > //.ebuild

Re: [gentoo-dev] Gentoo-dev whitelisting

On 14/05/2018 07:35, Michał Górny wrote: > W dniu nie, 13.05.2018 o godzinie 17∶28 -0400, użytkownik Alec Warner > napisał: >> On Sun, May 13, 2018 at 5:25 PM, Paweł Hajdan, Jr. <phajdan...@gentoo.org> >> wrote: >>> I'm wondering, >>> <https://git

Re: [gentoo-dev] Gentoo-dev whitelisting

On 13/05/2018 20:57, Alec Warner wrote: > https://wiki.gentoo.org/wiki/Project:Infrastructure/ > Mailing_Lists#Managing_the_Gentoo-Dev_whitelist I'm wondering, currently says for me "No repositories found". Am I using a wrong address, or

Re: [gentoo-dev] bug queue size over time

On 20/03/2018 06:05, Paweł Hajdan, Jr. wrote: > On 19/03/2018 21:33, Alec Warner wrote: >> I'd avoid the REST API here. If you want this data; I'd consider filing a >> bug. Infra can do stuff like run nightly reports for this information and >> hang them off of end

Re: [gentoo-dev] rfc: empty directories in ${D}

On 29/03/2018 19:00, Michał Górny wrote: > W dniu czw, 29.03.2018 o godzinie 11∶34 -0500, użytkownik William Hubbs > napisał: >> If we are going to strip the empty directories, we should hard fail the >> emerge at the same time. Otherwise there is no way to know whether the >> package we

Re: [gentoo-dev] Mailing list moderation and community openness

On 20/03/2018 05:17, Michael Palimaka wrote: > I see that in bug #650964[1] Council is pushing forward again with > implementing user whitelisting on this mailing list (ie. anyone that is > not "approved" will have their mail rejected). > > Could someone please explain how this doesn't directly

Re: [gentoo-dev] bug queue size over time

On 19/03/2018 21:33, Alec Warner wrote: > I'd avoid the REST API here. If you want this data; I'd consider filing a > bug. Infra can do stuff like run nightly reports for this information and > hang them off of endpoints you can access. > This works well for public bugs; and not well for private

[gentoo-dev] bug queue size over time

Is it possible to get graphs of bugs.g.o bug queue size for certain query (e.g. by assignee) over time? Best, Paweł signature.asc Description: OpenPGP digital signature

[gentoo-dev] stability of 17.0 hardened profile

I was looking into the new 17.0 profiles (nice work!), and noticed the hardened one is marked as dev. I'm somewhat concerned about switching to that on my laptop (I'm currently using hardened/linux/amd64). Is there something I can do to help move the profile to stable? Alternatively, is there a

Re: [gentoo-dev] SAT-based dependency solver: request for test cases

On 10/02/2018 09:20, Michał Górny wrote: > To be honest, I don't think this is the right approach to the problem. Feel free to suggest a better one. > Truth is, dependencies in Gentoo are seriously broken, and most of > the developers aren't even aware of that because of layers upon layers > of

Re: [gentoo-dev] about stable, dev and exp profile status

On 11/01/2018 08:43, Fabian Groffen wrote: > I always was under the impression the following order (and explanation) > was the case: > > stable -> development -> experimental > > For this reason, e.g. Prefix profiles are (still) experimental, which > means they really shouldn't bother non-Prefix

Re: [gentoo-dev] Manifest2 hashes, take n+1-th: one hash to decide them all

On 25/10/2017 14:32, Hanno Böck wrote: > Good security includes reducing complexity. Tough (as evident by this > thread) it's a thought many people find hard to accept. > > This thread is going into a completely different direction and I find > that worriesome. We have two non-problems ("what if

Re: [gentoo-dev] Manifest2 hashes, take n+1-th: 3 hashes for the tie-breaker case

On 24/10/2017 06:11, Michał Górny wrote: > W dniu wto, 24.10.2017 o godzinie 06∶04 +0200, użytkownik Michał Górny > napisał: >> Three hashes don't give any noticeable advantage. If we want a diverse >> construct, we take SHA3. SHA3 is slower than SHA2 + BLAKE2 combined, so >> even with 3 threaded

Re: [gentoo-dev] Manifest2 hashes, take n+1-th

On 20/10/2017 18:15, Michał Górny wrote: > W dniu pią, 20.10.2017 o godzinie 17∶42 +0200, użytkownik Paweł Hajdan, > Jr. napisał: >> Curious, do we have any measurements/estimates of the performance cost? > > With a single thread serial processing of all hashes, it's just sum o

Re: [gentoo-dev] Manifest2 hashes, take n+1-th

On 19/10/2017 21:08, Michał Górny wrote: > Considering all arguments made so far, I'd like to propose changing: > manifest-hashes = SHA256 SHA512 WHIRLPOOL > to: > manifest-hashes = SHA512 SHA3_512 +1, fine for me > 1. The main argument for using multiple hashes is to prevent the (very >

Re: [gentoo-dev] Revisions for USE flag changes

On 12/08/2017 03:11, Brian Evans wrote: > --changed-use (-U) >Tells emerge to include installed packages where USE flags have >changed since installation. This option also implies the >--selective option. Unlike --newuse, the --changed-use option >does

Re: [gentoo-dev] can't gpg sign with repoman, but can with git

On 20/07/2017 11:38, Kristian Fiskerstrand wrote: > On 07/19/2017 09:24 PM, Paweł Hajdan, Jr. wrote: >> * 4 files being committed... >> error: gpg failed to sign the data >> fatal: failed to write commit object >> !!! Exiting on git (shell) error code: 128 > > y

[gentoo-dev] can't gpg sign with repoman, but can with git

Hey folks, This is mysterious, and likely some issue with my setup, although it used to work. Trying tocommit with repoman commit (app-portage/repoman version 2.3.1) results in the following: * 4 files being committed... error: gpg failed to sign the data fatal: failed to write commit object

[gentoo-dev] stabilization candidates, July 2017

Hey folks, If you'd like to help Gentoo stable be more up to date, please read on. See for potential stabilization candidates (over 1000 of them). These are automatically checked to pass repoman, and bugzilla is also

Re: [gentoo-dev] crossdev: installing _host_ build dependencies not automatic?

On 03/05/2017 17:56, Alexis Ballier wrote: > From man emerge: > >--root-deps[=rdeps] > If no argument is given then build-time dependencies of >packages for ROOT are installed to ROOT instead of /. If the >rdeps argument is given then discard all build-time

[gentoo-dev] crossdev: installing _host_ build dependencies not automatic?

I encountered while working on some cross-compiling project. Admittedly, it may not be that easy to handle host package dependencies fully automatically. I'm wondering - is it documented what portage guarantees, and what I'm expected to just

[gentoo-dev] packages up for grabs (from phajdan.jr, May 2017)

This is probably overdue. I'm not really maintaining the following packages, mostly because I no longer use them. I have dropped myself from metadata.xml . Feel free to grab. If you have questions about them, just email me. app-admin/logcheck (2 bugs) app-admin/syslog-summary (1 bug)

Re: [gentoo-dev] Bugzilla package list editing

On 02/05/2017 02:31, Andreas K. Huettel wrote: > Am Sonntag, 30. April 2017, 12:29:46 CEST schrieb Mart Raudsepp: >> Please stop editing package lists when you are not the maintainer and >> arches are already CCed. > +1 > > Please stop it. > And yes that's also true for arch team members. > >

Re: [gentoo-dev] [PATCH 3/4] www-client/chromium: Use eninja from ninja-utils

On 30/04/2017 22:28, Michał Górny wrote: > --- > www-client/chromium/chromium-59.0.3067.0.ebuild | 19 +-- > 1 file changed, 1 insertion(+), 18 deletions(-) Thanks! Please make sure to patch the latest chromium version - at this moment, 60.0.3080.5 . I'm fine with backporting

[gentoo-dev] chromium-59.0.3053.3 will require >=sys-apps/sandbox-2.11 (currently hard masked)

The latest dev channel release of chromium (59.0.3053.3) will require >=sys-apps/sandbox-2.11 to build. I'm sending this announcement because this version of sandbox is currently hard masked. So is the chromium version, but with its fast release cycle we can expect it hitting ~arch in few weeks,

Re: [gentoo-dev] linux/dma-buf.h mysteriously missing

On 29/03/2017 19:51, Matt Turner wrote: > It's a bug that has since been fixed by kernel commit > 2220fc1ab363e6fab1f321430d69be17a8b92bd7 ("uapi: add missing install > of dma-buf.h"). The header was originally added in 4.10, and the fix > commit is in 4.11-rc1. > > I guess we just need to hack

[gentoo-dev] linux/dma-buf.h mysteriously missing

I was packaging chromium-59.0.3053.3 . I worked around the problem described here, but I'd like to find the right long term solution. I was hitting the following compile error: ../../ui/gfx/linux/client_native_pixmap_dmabuf.cc:39:27: fatal error: linux/dma-buf.h: No such file or directory

Re: [gentoo-dev] Pre-GLEP for review: mix-in profiles

On 23/01/2017 13:12, Alexis Ballier wrote: > For example, if you allow use.mask or use.force in mixins, you can end > up having unsatisfiable deps that repoman will never catch. Whoa, that sounds bad. Could you elaborate why we wouldn't be able to catch these errors? > Arguably, desktop profiles

Re: [gentoo-dev] Stats: Gentoo developer commit timeline

On 16/01/2017 10:35, Michał Górny wrote: > Just a quick side project we've done a while ago. It's a timeline of > developer commit activity [1]. Code for data processing in [2]. I did > the data, Amynka prepared a nice JS to graph it. > > [1]:http://dev.gentoo.org/~mgorny/dev-timeline.html >

Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

On 05/11/2016 00:54, Jonas Stein wrote: > Today we have still 524 ebuilds with SRC_URI=*googlecode* in the tree > [2] and should get these fixed before end of 2016. > > [3] https://wiki.gentoo.org/wiki/Shutdown_of_google_code The wiki page seems to indicate some sense of urgency. I'm not sure

Re: [gentoo-dev] Contributed ebuilds and copyright questions

On 25/10/2016 01:03, Rich Freeman wrote: > As long as you have their permission to change the copyright notice. > You cannot currently commit anything with a different copyright notice > to gentoo.git, and you cannot legally change it without permission. How should that permission be documented?

Re: [gentoo-dev] Mentor request

On 19/10/2016 07:14, Kevin Simmons wrote: > In general, I could use a mentor I can ask questions of and get answers > from. I have been a tinkerer/user only of Gentoo in the past and am now > wanting to be more involved. Sounds great! :) Not sure if I'd call myself a mentor, but feel free to

Re: [gentoo-dev] Local workarounds with no reported bugs

On 17/10/2016 12:42, Patrice Clement wrote: > We don't need yet another policy to "fix" two problems you've > encountered +1 ; policies don't always fix things It's a worthwhile guideline though - as Gentoo devs, and maybe even wider community, we should work together to fix problems. That's

Re: [gentoo-dev] recommended way to get gcc-6 for testing packages

On 05/09/16 13:07, Joshua Kinard wrote: > On 08/31/2016 17:28, Paweł Hajdan, Jr. wrote: >> gcc-6 doesn't seem to be in portage. > It's in the hardened-development overlay. You can use layman to install the > overlay, then test out gcc-6.2.x. Already found a bug related to mips

[gentoo-dev] recommended way to get gcc-6 for testing packages

I was looking at . gcc-6 doesn't seem to be in portage. Is there recommended way to get it installed? I'm also wondering what are the plans for adding it to portage. Why not just add it hard masked or unkeyworded? Paweł signature.asc

[gentoo-dev] chromium-54 needs ffmpeg-3.0.1

See for context. chromium-54 is currently hard masked; it'd soon enter ~arch, and then stable in ~6 weeks. ffmpeg-3.0.1 is currently hard masked. These are the options I see for how to proceed. Feel free to share further alternatives. A. Prepare

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

On 15/06/16 21:11, Michał Górny wrote: > I would personally go for the following layout: > > - All packages, > - Core system [includes baselayout], > - Eclasses and Profiles, > - GCC Porting, > - Hardened, > - Keywording & Stabilization, > - New packages ('New ebuilds' previously), > - SELinux.

Re: [gentoo-dev] ssh keys setup for git.gentoo.org after ssh-dss deprecation

On 3/26/16 11:41 AM, Michał Górny wrote: > On Sat, 26 Mar 2016 18:40:17 +0900 > Aaron Bauman wrote: >> Git SSH key changes are done manually by the infra team. I just went >> through >> the same issue when I updated my keys. Hope this helps. > > Updated. Thanks! Everything

[gentoo-dev] ssh keys setup for git.gentoo.org after ssh-dss deprecation

I recently hit ssh-dss key deprecation (), and PubkeyAcceptedKeyTypes=+ssh-dss on the client side allows me to keep access to Gentoo infrastructure I need. I generated a new RSA key using instructions from

Re: [gentoo-dev] gcc-5 news item wrt C++ ABI

On 10/3/15 4:13 AM, Mike Frysinger wrote: > Title: GCC 5 Defaults to the New C++11 ABI > Author: Mike Frysinger > Content-Type: text/plain > Posted: 2015-10-02 > Revision: 1 > News-Item-Format: 1.0 > Display-If-Installed: >=sys-devel/gcc-5 > > GCC 5 uses the new C++ ABI by

Re: [gentoo-dev] gcc-5 news item wrt C++ ABI

On 10/3/15 7:30 PM, Ciaran McCreesh wrote: > On Sat, 3 Oct 2015 13:24:11 -0400 > Mike Frysinger wrote: >> On 03 Oct 2015 13:38, Ciaran McCreesh wrote: >>> On Fri, 2 Oct 2015 22:13:09 -0400 Mike Frysinger wrote: Display-If-Installed: >=sys-devel/gcc-5 >>> >>> This means

Re: [gentoo-dev] LibreSSL import plan

On 9/29/15 3:32 PM, Rich Freeman wrote: > The thing is that I think the libressl authors are shooting themselves > in the feet. When upstreams do this sort of thing they think they're > making the upgrade path easier by not changing their symbol names. In > reality, they're making the upgrade

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

On 9/14/15 9:13 AM, konsolebox wrote: > On Mon, Sep 14, 2015 at 2:29 PM, Paweł Hajdan, Jr. > <phajdan...@gentoo.org> wrote: >> On 9/14/15 6:35 AM, konsolebox wrote: >>> Many times we need to match packages like this: >>> something-1.0.2a.* >> >

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

On 9/14/15 6:35 AM, konsolebox wrote: > Many times we need to match packages like this: something-1.0.2a.* Could you give specific examples, i.e. what packages, what dependencies, why is that needed? Paweł signature.asc Description: OpenPGP digital signature

Re: [gentoo-dev] www-client/chromium gtk3 support

On 9/10/15 8:05 PM, hasufell wrote: > a) the gnome maintainers already said they are not interested in > supporting it indefinitely (they are the maintainers of gtk+ as well) Aren't there at least some gtk2-only apps? It seems to me we're not that close to removal of gtk2 from the tree. I'm also

[gentoo-dev] www-client/chromium gtk3 support

A user asked for optional gtk3 support in www-client/chromium: However, reading e.g. says this: > having USE=gtk3 to enable gtk+-3 instead of gtk+-2 support is >

Re: [gentoo-dev] samba (and related) packages are in desperate need of help

On 9/9/15 4:00 PM, Lars Wendler wrote: > On Wed, 2 Sep 2015 21:23:24 +0200 Paweł Hajdan, Jr. wrote: >> I don't see any references to upstream bug reports, and so no evidence >> of upstream being uncooperative. >> >> Are there any public links that you could share?

Re: [gentoo-dev] www-client/chromium gtk3 support

On 9/9/15 5:48 PM, hasufell wrote: > There was a tracker on bugzilla about it at some point, but people > didn't care enough, so I stopped filing bugs. Neither the gnome team > nor QA had a strong enough opinion to enforce consistency here over > the whole tree. Looks like that was

Re: [gentoo-dev] Re: Better way to direct upstream bugs upstream?

On 9/3/15 10:16 PM, Andrew Udvare wrote: > Chromium team is no different in this regard. No options, for anything. > It is extremely annoying when they implement 'privacy-violating' > features like the previously visited sites in the New tab (before you've > entered a URL), with no option to

Re: [gentoo-dev] Re: Better way to direct upstream bugs upstream?

On 8/30/15 12:02 PM, Kent Fredric wrote: > Or upstream might be a monolithic giant like Google where their > upstream bug tracking is some pointless forum where you get ignored by > the people actually working on things. Ouch. Do you have specific examples? I'm not denying they exist. I just

Re: [gentoo-dev] samba (and related) packages are in desperate need of help

On 9/1/15 3:24 PM, Lars Wendler wrote: > * samba upstream is extremely uncooperative. Best example is that we > still have some automagic dependencies [5] in samba's build system and > upstream is not very keen on fixing these. > > [...] > > [5] https://bugs.gentoo.org/489748 >

Re: [gentoo-dev] RFC: EAPI 4 deprecated ban

On 8/16/15 3:29 PM, Rich Freeman wrote: They are deprecated already: https://gitweb.gentoo.org/repo/gentoo.git/tree/metadata/layout.conf Deprecated means stop adding them, and move away from them. Repoman will give you a warning about them. Is anything blocking deprecating EAPI4 in the

Re: [gentoo-dev] RFC: EAPI 4 deprecated ban

On 8/15/15 3:16 AM, Ian Stakenvicius wrote: Secondly, though, conversion to EAPI5 is not actually trivial, there are a couple of things, 'usex' related for instance, that also need to be taken care of. If it was just a matter of running a sed -e 's/^EAPI=4/EAPI=5/' on all in-tree ebuilds this

Re: [gentoo-dev] RFC: EAPI 4 deprecated ban

On 8/15/15 7:35 AM, Michał Górny wrote: Dnia 2015-08-15, o godz. 00:05:57 Johannes Huber j...@gentoo.org napisał(a): if we want to attract more contributors we should consider to have one supported EAPI (latest). EAPI 4 is the last not marked as deprecated ( EAPI 5). The move in ebuilds from

[gentoo-dev] git history older than proj/gentoo: Initial commit (56bd759)

I'd like to start with: kudos for the very skilfully performed migration from CVS to git! I just committed a simple changed and it worked great. I was curious and started exploring the repo a little bit, and the initial commit says: This commit is the start of the NEW history. Any historical

Re: [gentoo-dev] useflag policies

On 8/2/15 7:27 PM, Michał Górny wrote: What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME team policy. USE=qt would mean 'any version of Qt, if optional', and qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be obligatory, no USE=qt would apply. If only one Qt

Re: [gentoo-dev] [RFC] check-reqs.eclass: fail check-reqs_memory() for virtual rather than physical RAM

On 6/3/15 10:56 PM, Mike Gilbert wrote: The chromium build issue is a point of some contention; see the bug below. https://bugs.gentoo.org/show_bug.cgi?id=471810 I agree that it makes sense to check virtual memory. I guess that would be MemTotal + SwapTotal in /proc/meminfo. It would

[gentoo-dev] what's the correct format for bugs containing package name and version?

I'm trying to find the best fix for https://bugs.gentoo.org/show_bug.cgi?id=535814 Currently file-stabilization-bugs.py uses the '%s: stabilization request' % cpv format. Here are some options I see: a) keep '%s:' as is b) change to just '%s' c) change to '=%s:' d) change to '=%s' e) something

Re: [gentoo-dev] do we need special elog messages for bindist?

On 2/25/15 8:38 PM, Mike Gilbert wrote: I would like to remove the elog for a couple of reasons: 1. The use flag description is there for whoever cares to read it. There is no need to alert the user every time. 2. We are not lawyers, and I have no business giving legal advice about patent

[gentoo-dev] Re: [gentoo-dev-announce] Service relaunch: archives.gentoo.org

On 2/26/15 9:23 AM, Robin H. Johnson wrote: The Gentoo Infrastructure team is proud to announce that we have re-engineered the mailing list archives, and re-launched it, back at archives.gentoo.org. [...] Major thanks to a3li, for his development of this project. Awesome work! I was

[gentoo-dev] do we need special elog messages for bindist?

I'm looking at https://bugs.gentoo.org/show_bug.cgi?id=538628 which suggests removing elog messages chromium has for bindist: This is the snippet we use in the ebuild: if use bindist; then elog bindist enabled: H.264 video support will be disabled. else

Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps

On 2/20/15 12:10 PM, Ben de Groot wrote: At the suggestion of radhermit, I'm putting my neovim deps ebuilds up here for review, before I commit them to the official tree. Do you see any possible improvements? Overall the ebuilds look nice and clean. Some ideas: - consider asking libtermkey

Re: [gentoo-dev] proposed update to toolchain.eclass

On 1/18/15 10:50 PM, Anthony G. Basile wrote: Hi everyone, I'd like to make a commit to toolchain.eclass in a few days. mgorny noticed some code which can be improved. Basically gcc creates fixed include files from system headers because of the requirement that it have ansi c compliant

Re: [gentoo-dev] [gentoo-project] Re: towards a more distributed model

On 11/20/14 5:15 PM, Ciaran McCreesh wrote: On Thu, 20 Nov 2014 01:36:32 +0100 hasufell hasuf...@gentoo.org wrote: Exherbo is already running a more modular approach, I'd be interested what they have to say about this or which problems they were facing. Well the big thing is that unlike

Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11

On 11/20/14 5:04 PM, Ian Stakenvicius wrote: Ok, added the RESO/NEEDINFO case, and bumped my polling time to 5 minute intervals. Diego, please keep going, your efforts are still very much appreciated. +1, and thanks Ian for your script! Paweł signature.asc Description: OpenPGP digital

Re: [gentoo-dev] Re: RFC: News item regarding c++98 vs c++11

On 10/24/14 7:29 PM, Anthony G. Basile wrote: So I don't have to keep email the entire item to the list, how about just adding it as follows: Nor is c++11 code compiled with gcc-4.7 ABI-compatible with c++11 compiled with 4.8, and vice versa. An example can be see in ref. [2] Ref. [2]

Re: [gentoo-dev] Re: RFC: News item regarding c++98 vs c++11

On 10/24/14 4:31 PM, Anthony G. Basile wrote: I've update the c++ news item for your consideration. I incorporated suggestions, in particular a note about incompatibility between c++11 compiled with different version of gcc differing in minor number (eg 4.7 and 4.8). Thanks, I think this is

Re: [gentoo-dev] Re: RFC: News item regarding c++98 vs c++11

On 10/21/14 4:25 PM, Mike Gilbert wrote: On Tue, Oct 21, 2014 at 4:45 AM, Martin Vaeth mar...@mvath.de wrote: Ian Stakenvicius a...@gentoo.org wrote: On 20/10/14 06:58 AM, Anthony G. Basile wrote: I don't think we'll ever want to support a mixed abi system. Can we, even? Would it be a

Re: [gentoo-dev] RFC: News item regarding c++98 vs c++11

On 10/20/14 12:53 AM, Anthony G. Basile wrote: GCC 4.7 introduced the new experimental 2011 ISO C++ standard [1], along with its GNU variant. This new standard is not the default in GCC 4.7, 4.8 or 4.9, the default is still gnu++98, but it can be enabled by passing -std=c++11 or

Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11

On 10/13/14 1:38 AM, viv...@gmail.com wrote: have you considered to stabilize gcc:4.9 instead possibly 4.9.2 ? I'm not really suggesting to do so, but seem that most of the problems of 4.9.1 are the same of 4.8.3 so maybe it's worth considering. Il 11/10/2014 13:57, Paweł Hajdan, Jr. ha

[gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11

In my earlier thread http://thread.gmane.org/gmane.linux.gentoo.devel/92113 I explored the possibility to stabilize gcc-4.8, and we have that going now in https://bugs.gentoo.org/show_bug.cgi?id=516152. Meanwhile I just applied a small patch for chromium-38 that allows it to compile with gcc-4.7.

Re: [gentoo-dev] Adding dev-lang/perl version to emerge --info

On 10/4/14 12:05 AM, Andreas K. Huettel wrote: since Perl is a fairly central package and it's hard to debug problems without the exact version, the perl team would like to add dev-lang/perl to profiles/info_pkgs. This has the effect that the installed version of dev-lang/perl is by

Re: [gentoo-dev] Why masks are being used for security issues instead of GLSA?

On 9/25/14 6:03 AM, Alex Xu wrote: 1. one of your examples is clearly wrong, mariadb has no masked versions in the tree. 2. since you claim to have read package.mask, [...] if you bothered to read a single one of them, they will have said that there is a GLSA in progress or that

Re: [gentoo-dev] Early idea: install_qa_check() refactor and 'public API'

On 9/11/14 12:20 AM, Michał Górny wrote: I would like the post-install QA checks to be modularized, standardized and extensible. For a start, I've split most of the function into install-qa-check.d/ scripts in Portage and made install_qa_check() function run them [1]. However, that's just a

Re: [gentoo-dev] Followup notes: {cvs,git,git.overlays}.gentoo.org migration; awol: some overlays commits, gitweb

On 8/19/14 1:00 AM, Robin H. Johnson wrote: The new SSH keys, in case you still didn't have them: On Mon, Jun 30, 2014 at 10:26:52PM +, Robin H. Johnson wrote: 1024 5f:c3:fe:9a:ac:a7:99:f4:d3:c1:93:4c:52:87:74:28 (DSA) 256 aa:6a:e4:74:1d:73:d2:5a:9f:45:9f:18:55:81:c9:9a (ECDSA) 256

Re: [gentoo-dev] rfc: calling all eclass phase functions by default

On 8/17/14, 12:32 AM, Kent Fredric wrote: Collison systems I've seen usually do one of two things: - In the event of a collision, demand the consumer resolve the problem by redefining the function the collision occurs on in terms of its composite parts. ( which is basically what we already

Re: [gentoo-dev] rfc: calling all eclass phase functions by default

On 8/17/14, 9:18 AM, Michał Górny wrote: Dnia 2014-08-17, o godz. 09:06:04 Paweł Hajdan, Jr. phajdan...@gentoo.org napisał(a): The warning would make the problem more visible to ebuild writers. Then we already have a solution that works, i.e. explicitly defining the phase function

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

On 7/29/14 6:49 PM, Michał Górny wrote: Dnia 2014-07-23, o godz. 19:48:17 Paweł Hajdan, Jr. phajdan...@gentoo.org napisał(a): Looks like www-client/chromium is going to start using c++11 seriously and require gcc-4.8+, see thread https://groups.google.com/a/chromium.org/d/msg/chromium

Re: [gentoo-dev] minimalistic emerge

On 8/8/14, 6:27 PM, Igor wrote: Is there any warranty that updated with -uDN system will remain full functional for 1 year? I have 100% warranty that not updated system is going to remain functional for 5 or 6 years. I have some with 7 years uptime. I'd say there is no warranty. However, a

Re: [gentoo-dev] Status of ppc and ppc64 teams.

On 8/5/14, 12:03 AM, Anthony G. Basile wrote: The bigger problem is actually KEYWORDREQ's so we are going to request maintainers not ever drop ~ppc or ~ppc64 even when they feel a major bump has occurred, eg a deep rewrite to a library. We know this is living dangerously but we'll going to

Re: [gentoo-dev] Re: don't rely on dynamic deps

On 7/30/14, 7:36 AM, Samuli Suominen wrote: If it's 2-3 packages out of ~300, I'd rather pick them out than revision bump all ~300 for the 2-3. Or not pick them out at all and let users do the rebuild (which is the obvious answer to the output you posted) Peter Stuge pointed it out already,

Re: [gentoo-dev] Re: don't rely on dynamic deps

On 7/27/14, 1:42 PM, Samuli Suominen wrote: Only one person said he had to manually build 2 GNOME related packages, simple-scan and something else So, broken? Far from it. More like essential feature. People have just listed some known races dynamic deps have, and I take those races

Re: [gentoo-dev] don't rely on dynamic deps

On 7/21/14, 11:52 PM, Alexander Berntsen wrote: Michał has documented the shortcomings of dynamic deps in our wiki[0]. (Thank you!) [...] [0] https://wiki.gentoo.org/wiki/Project:Portage/Dynamic_dependencies There's one more thing I'd like to ask about: For Minor linking change w/ dependency

Re: [gentoo-dev] don't rely on dynamic deps

On 7/27/14, 4:42 PM, Rich Freeman wrote: With dynamic deps you'd need to revbump if there is a linking change. Otherwise portage would just allow the dependency to be removed, and then linking will break, since the executable is unnecessarily linked to the dependency (in that scenario).

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

Looks like www-client/chromium is going to start using c++11 seriously and require gcc-4.8+, see thread https://groups.google.com/a/chromium.org/d/msg/chromium-packagers/fvJvPG8fa7I/iWPEsUxhKikJ This is in the dev channel for now, but given the 6 weeks release cycle it'll go to stable in about 3

Re: [gentoo-dev] don't rely on dynamic deps

On 7/21/14, 11:52 PM, Alexander Berntsen wrote: Michał has documented the shortcomings of dynamic deps in our wiki[0]. (Thank you!) This documentation also includes two of our possible solutions. [0] https://wiki.gentoo.org/wiki/Project:Portage/Dynamic_dependencies Thank you, this is very

Re: [gentoo-dev] Enable format-security in the dev profiles

On 7/21/14, 6:02 AM, Samuli Suominen wrote: Why not generate a Portage QA warning out from the warning -Wformat-security produces instead? That way compile wouldn't abort needlessly. +1, and then it can be done globally. Paweł signature.asc Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent to need to change all keywords at the same time

On 7/17/14, 2:28 PM, Pacho Ramos wrote: I recently noticed this: https://bugs.gentoo.org/show_bug.cgi?id=502836 imlib2 ebuild can only be stabilized in one round for all arches as KEYWORDS are set in eclass depending on E_STATE=release. That has an important drawback as forces all arches to

Re: [gentoo-dev] Returning dev: Thomas Alan Gall (tgall)

On 7/14/14, 10:26 AM, Justin (jlec) wrote: we have an returning oldtimer here, Thomas Gall aka. tgall. His original bug has been opened in 2003, so he knows gentoo from the early days. He is joining the arm team now and will stabilize mostly for arm64, where he already started to work with a

[gentoo-dev] PSA: ruby_targets_ruby21 masked on stable

I added the following entry to profiles/base/use.stable.mask: # dev-lang/ruby:2.1 is not stable. ruby_targets_ruby21 This is needed for https://bugs.gentoo.org/show_bug.cgi?id=505920, as otherwise rexical would generate the following repoman error: dependency.bad18

[gentoo-dev] scanelf-based RDEPEND

I'd like to ask for some help with https://bugs.gentoo.org/show_bug.cgi?id=512806 After the latest check I've done I think the list is valid and should be added to www-client/chromium's RDEPEND. Do you see any obvious problems with that? Should I perform some additional checks? Note that while

Re: [gentoo-dev] RFC: Removing src_test from www-client/chromium

On 6/1/14, 4:41 PM, Tom Wijsman wrote: I can't speak for other people, but please consider reporting issues to Gentoo first. Our bug queue is under 30 bugs, while upstream is several thousand. Once we can confirm a bug clearly belongs to upstream, we can tell the reporter to file bug upstream

Re: [gentoo-dev] RFC: Removing src_test from www-client/chromium

On 5/31/14, 8:30 PM, Tom Wijsman wrote: On Sat, 31 May 2014 19:50:20 +0200 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: This is one of my points: I don't remember a single chromium bug filed in Gentoo that would be caught by a test or that a failing test actually detected. Your point

Re: [gentoo-dev] RFC: Removing src_test from www-client/chromium

On 5/29/14, 12:46 PM, Tom Wijsman wrote: In general it has always worked well after a compile; but, there's every now and then one or another annoying regression, like recent Chromium had some font issues or some random tabs crash some versions ago and ... If a test catches one of these, you

[gentoo-dev] RFC: Removing src_test from www-client/chromium

It's more of a project-internal decision IMHO, but just wanted to get feedback from the larger community. Currently 11 out of 27 bugs assigned to chromium.g.o are related to test failures. I don't remember a single case where a test failure would point to a real bug in our package. I'm

  1   2   3   4   5   6   >