Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

Anthony G. Basile wrote: > >> I proxy maintain bitcoins for luke-jr. He wants to propose a patch > >> against the bitcoin eclass. The following is his proposed change. > >> I'll commit it after review. > > > > Please do not do that, Anthony. > > I don't have time nor the familiarity to

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

Anthony G. Basile wrote: > I proxy maintain bitcoins for luke-jr. He wants to propose a patch > against the bitcoin eclass. The following is his proposed change. > I'll commit it after review. Please do not do that, Anthony. > Bitcoin Knots includes a number of enhancements users may find

Re: [gentoo-dev] newsitem: important fstab update

Peter Stuge wrote: > --8<-- mount(8) .. > portable. The mount(8) command internally uses udev symlinks > -->8-- That's of course only the mount in util-linux. //Peter

Re: [gentoo-dev] newsitem: important fstab update

Ian Stakenvicius wrote: > > WilliamH wants everyone using /dev/disk/by-label/ > > paths in fstab to instead use LABEL= , to avoid issues if udev > > doesn't create the symlinks before localmount tries to use them. .. > UUID is the same situation in this case -- in fstab you can do it by > UUID= or

Re: [gentoo-dev] newsitem: important fstab update

Rich Freeman wrote: > We give you the tools when you install your system, and we give you > the tools when it is time for renovations... On that note - thank you very much to everyone who contributes to Gentoo! <3 //Peter

Re: [gentoo-dev] Commented packages in the @system set

waltd...@waltdnes.org wrote: > For a build-from-source distro like Gentoo, gcc and associated > tools are a vital part of the distro. A stage4 created (and updated) on a catalyst build farm doesn't need to have gcc, but may still need libstdc++. //Peter

Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

Rich Freeman wrote: > I think you could make an argument that voluntarily placing that > header on your work is an assignment of copyright. > You could also argue otherwise. Especially in jurisdictions where copyright can not be assigned. //Peter

Re: [gentoo-dev] newsitem: important fstab update

Ian Stakenvicius wrote: > by mount and works regardless of device manager, therefore removing > the the dependency of having udev-settle before mounting these paths. the the Looks good. Thanks. //Peter

Re: [gentoo-dev] Commented packages in the @system set

Raymond Jennings wrote: > Why exactly isn't libstdc++ a separate package anyway? I guess because it has no separate upstream. I think a separate package would be a fantastic improvement though. //Peter

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

Patrice Clement wrote: > We should strive for keeping a clean and linear history. I agree with you. > Cherry-picking is not my go-to solution as far as I'm concerned. > It requires a bit of setup and is clearly tedious: you must know > in advance the full SHA-1 of commit(s) you want to

Re: [gentoo-dev] Re: Packages up for grabs

Peter Stuge wrote: > How can I help improve ..? Michał Górny wrote: > people focused on preaching and/or implementing random crap-based > solutions without even stopping for a few minutes to consider what > we exactly need. You could interpret my question as "what e

Re: [gentoo-dev] Re: Packages up for grabs

Michał Górny wrote: > Or file a pull request @ https://github.com/gentoo/gentoo/pulls. > That's the most convenient solution for most of proxy-maint team members. How can I help improve that problematic situation? It's not cool to gravitate the project towards GitHub Inc. //Peter

Re: [gentoo-dev] Re: Packages up for grabs

Felix Janda wrote: > I'd like become a proxy-maintainer for app-editors/nvi. Sweet! If there are some open bugs then please upload patched ebuilds and other neccessary files to the bugtracker, ideally as output by git format-patch, and then talk e.g. to #gentoo-proxy-maint on freenode to get

Re: [gentoo-dev] Packages up for grabs

Andrew Savchenko wrote: > On Sat, 6 Aug 2016 13:37:19 +0000 Peter Stuge wrote: > > Hi Pacho, many thanks for your work, but.. .. > > ..do you think you can arrange to post everything in one mail, > > instead of 14 different ones in a single day? > > I suppose these po

Re: [gentoo-dev] Packages up for grabs

Hi Pacho, many thanks for your work, but.. Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho Ramos wrote: Pacho

Re: [gentoo-dev] Package up for grab

Daniel Campbell wrote: > Tox .. > All it needs is feature parity with video, voice, and file sharing. And a new name. :) //Peter

Re: [gentoo-dev] why is the security team running around p.masking packages

Rich Freeman wrote: > > do not be shy to suggest reading materials .. > Do NOT skip descriptions of blobs/trees/commits/objects/reference/etc. > If you don't understand the data model, you'll never get it. I have an intro here: http://peter.stuge.se/git-data-model //Peter

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

Consus wrote: > This is how overlays work right now. What are suggesting to change? Technically not a lot in terms of how packages get installed. It's more about offering support and/or visibility for overlays. So technically it's about hosting user repos, making the ebuilds within easily

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

Alexander Berntsen wrote: > It would be fruitful to encourage every single Gentoo user to have > their own repository. And this repository should be publicly available. .. > What are your thoughts? Genius. This is exactly what I have been doing for many years, but I couldn't have expressed it as

Re: [gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar

Cool! aide...@gentoo.org wrote: > +_find_dep_version() { > + local pn="$1" > + local p > + > + pushd "${EPREFIX}$(get_erl_libs)" >/dev/null > + for p in ${pn} ${pn}-*; do > + if [[ -d ${p} ]]; then > + echo "${p#${pn}-}" > +

Re: [gentoo-dev] Reminder: ALLARCHES

Mike Gilbert wrote: > "doing your job" Remember that everyone is a volunteer. > dropping stable keywords on everything but the bare necessities Gentoo magically does a number of things which upstream never intended and do not intentionally support. It is amazing, and thank you so much to

Re: [gentoo-dev] Last rites: app-cdr/webcdwriter

James Le Cuirot wrote: > # James Le Cuirot (26 Jan 2016) > # No new release since 2008. Removal in 30 days. > app-cdr/webcdwriter Is there a problem with it? I don't use it and have no interest in this particular package but merely lack of release is not a valid reason to

Re: [gentoo-dev] USE=desktop-file request

Rich Freeman wrote: > I'm not sure it is really worth trying to control this via a USE flag > for such a light dependency. I don't care how light dependencies are - I want to be able to choose every single one that is optional. That is Gentoo's killer feature, and I am thoroughly disappointed

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

Michael Orlitzky wrote: > If anyone has a concrete idea that works better, it's not too late to > change it. Add code to init script and service file to check the config before starting the program, and react if PHP5 is still set. //Peter

Re: [gentoo-dev] Re: News item: Apache "-D PHP5" needs update to "-D PHP"

Kristian Fiskerstrand wrote: > Maybe I'm thinking things too difficult, why not just define both -D > PHP and -D PHP5 in the transition period and suggest this config for > any change? Because it mostly just defers the problem. If the desire is to move away from PHP5 then I would suggest to

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

Michael Orlitzky wrote: > >> If anyone has a concrete idea that works better, it's not too late to > >> change it. > > > > Add code to init script and service file to check the config before > > starting the program, and react if PHP5 is still set. > > Which init script? For Apache. > It's

Re: [gentoo-dev] [PATCH 0/5] python-r1 suite: python_gen_impl_dep() function

Michał Górny wrote: > Please review the patches sent in reply. The changes look good to me, but maybe the function should have 'use' in its name; it's not obvious that the parameter is about USE as opposed to PN. //Peter

Re: [gentoo-dev] Re: repo/gentoo.git, or how committing is challenging

Patrick Lauer wrote: > my time, spent to work around deficiencies I shouldn't even see - > if other people had done their job. Ah but that's the thing - it *isn't* their job. They are volunteering. That's a very different construct. And yes, you do have to work around deficiencies created by

Re: [gentoo-dev] Re: repo/gentoo.git, or how committing is challenging

Ryan Hill wrote: > You want me to use a potentially unstable live ebuild instead? > Well, no, that's not gonna happen. Are you demanding that someone else produces for you, and refusing to do anything but consume? If the stable version is broken and if needing to use ~ or live is not up to your

Re: [gentoo-dev] Breakage and frustration

Rich Freeman wrote: > a big question is how to make it happen without just throwing > complaints on the folks who are trying their best to keep it all going. The answer to this is the same as it has always been: Demonstrate that you are capable and reliable and given social compatibility then

Re: [gentoo-dev] Use GLEP27!

Ulrich Mueller wrote: > (If directories are really needed, we could use the scheme foreseen > in [1] for package.* and use.* files.) So package.{users,group} ? > Also a mechanism how a subprofile could undefine a user or group > defined in its parent seems to be missing. Maybe set the id to -1

Re: [gentoo-dev] git update hook: detecting missing Manifest DIST entries

Robin H. Johnson wrote: > 1. Script #1 (helper), that given an ebuild, spits out the filenames of the >distfiles. >- Use an explicitly specified PORTDIR for eclasses. >- Must NOT rely on the ebuild directory structure (i'd love to give >it the ebuild via stdin and tell it the

Re: [gentoo-dev] RFD: Replacement for versionator.eclass in PMS (for EAPI 7?)

Ulrich Mueller wrote: > 1. Will these three functions be sufficient, or have we overlooked >anything important? Something that comes to mind as probably being semi-frequent is to transform a version number component into a Gentoo -p number. Or do you suggest doing that by replacing the

Re: [gentoo-dev] rfc: adding sbin directories to PATH for all users

Mike Gilbert wrote: > > I would like for us to discuss adding the sbin directories to PATH for > > all users. > > I support this idea. The distinction between bin and sbin is stupid. I support it too FWIW. //Peter

Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle

Peter Stuge wrote: > Robin H. Johnson wrote: > > However, the largest sticking point, even with parallel threads, is that > > it seems the base ChangeLog generation is incredibly slow. It averages > > above 350ms per package right now (at 19k packages in a full cycle,

Re: [gentoo-dev] Re: ChangeLog

Michael Orlitzky wrote: > Once users have the full git repo on their machines, they have two > options. They can update it efficiently with `git pull`, or they can > update it with rsync by using `emerge --sync`. You can even mix the two, I don't think you can mix the two, because how my local

Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle

Robin H. Johnson wrote: > However, the largest sticking point, even with parallel threads, is that > it seems the base ChangeLog generation is incredibly slow. It averages > above 350ms per package right now (at 19k packages in a full cycle, it's > a long time), but some packages can take up to 5

Re: [gentoo-dev] Revision diffs

Michael Orlitzky wrote: > after making those three revbumps, what I see is that I added and > removed the entire ebuild three times. True, but useless. Try git show/log -M //Peter

Re: [gentoo-dev] Re: [rfc] enable USE=xattr by default

Anthony G. Basile wrote: > if you emerge when using a vanilla kernel or some other which doesn't > support user.pax.* on tmpfs, then you'll loose those markings. Would it be at all possible to add the markings after/as files land on the destination filesystem instead? It's not really intuitive

Re: [gentoo-dev] Re: [rfc] enable USE=xattr by default

Anthony G. Basile wrote: >> Would it be at all possible to add the markings after/as files land >> on the destination filesystem instead? .. > since we sometimes have to do pax markings during src_compile() or > src_test() or early during src_install() etc, the safest approach is to > preserve

Re: [gentoo-dev] www-apps/otrs: needs new maintainer

Stefan G. Weichinger wrote: > * the former dev has removed himself as maintainer > * the package is rather outdated now in portage > * there are some ebuilds already which could be considered to be added > (at least as unstable, sure) > > pls advise, If you have interest in this package then you

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

upstream hat on Kent Fredric wrote: I've always seen it as a case where Gentoo devs stand as a layer of sanitization between downstream and upstream. This is the last thing I want. Did you play the whisper game as a kid? I want direct contact with the user who can reproduce the problem in the

Re: [gentoo-dev] Infra plans regarding $Id$ - official answer...

Hi and happy Git days! :) Robin H. Johnson wrote: It expands to the hash of the blob of that file; and from that, you can identify which commits the blob exists in. $ git ls-tree HEAD README 100644 blob 08ae16956b8944da2fef75fee892dcba457cf4f0README $ $ (stat --printf='blob %s\0'

Re: [gentoo-dev] Re: useflag policies

Sergey Popov wrote: qt? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) ) Fine by me, if you would ask. May I suggest instead: qt? ( qt5? ( dev-lang/qt$something:5 ) qt4? ( dev-lang/qt$something:4 ) ) Alexandre Rostovtsev wrote: qt? ( qt5? (

Re: [gentoo-dev] rfc: openrc mount service prototype

William Hubbs wrote: [1] http://www.semver.org Major version zero (0.y.z) is for initial development. Anything may change The problem is that version 0 hit stable Just treat version numbers as the meaningless counters they are. I can't just randomly break things from 0.17 to 0.18 for

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule

Rich Freeman wrote: I suspect that trying to force it would basically end up putting the entire distro on hold until most of the current devs quit, I think you're right. I also think those developers should quit right here and now. I don't think they will. //Peter

Re: [gentoo-dev] Re: Git workflow

William Hubbs wrote: I think I understand what he's asking for... I think he is asking the question, What changed in commit hash. If you use the hash of a merge commit with git show, you get nothing, so the merge commit is useless in terms of following changes. I have explained why merge

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule

Alec Warner wrote: Its difficult to make a large change like all commits require review, particularly for long-time contributors who are expecting to move quickly. I think it's a character flaw (maybe hubris due to lack of experience and/or ignorance?) to lack the humility to say that I would

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule

hasufell wrote: that said... I don't think it currently makes sense to enforce a strict global review workflow. For the record, neither do I, and I never proposed that it should hold up starting to use Git. //Peter

Re: [gentoo-dev] Git workflow

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 being seen) If there are no conflicts when merging then the

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule

William Hubbs wrote: If we do add a code review system, it should be fully accessible from the command line. Pybugz is almost there for bugzilla; the only thing it lacks is the ability to reply to specific comments. Gerrit is also almost there, it has an ssh interface which is very usable for

Re: [gentoo-dev] Git workflow

C Bergström wrote: To start I hate git.. I have used it for years now and the multitude of ways that are possible to accomplish nearly the same thing are *annoying* at best.. I'd be interested to hear a couple of examples of what you mean, perhaps in a private mail. Tack på förhand. :)

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule

NP-Hardass wrote: or do they typically restrict review to a certain class of users? Hm, why would that end up happening? I'm not saying it can't, just that I don't understand why it would. What do you have in mind? Well, it was just proposed earlier in the thread that it could be used

Re: [gentoo-dev] Git workflow

C Bergström wrote: 1) Rebase doesn't obscure history, That's plain wrong. Rebasing changes the parent of your commit. That means that others can no longer see the history of your commit, specifically its original parent. Sometimes the parent is irrelevant, sometimes it is critical. (Unless

Re: [gentoo-dev] A few mgorny/ projects for upstream-grabs

Michał Górny wrote: dev-util/atomic-install A nice one -- tool to quasi-atomically install files from $D to live system. The idea is to replace live files as fast as possible, and quickly revert that if it fails in the middle. I like the idea, but I would personally like to see it

Re: [gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml

Duncan wrote: The point you made here was console-based workflow, as quoted above, and that's what I addressed, arguing that even if was valid at some point, it's no longer the factor it once was. For you, that is. Be aware that this creates your bias. You can't extrapolate from your own

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

Rich Freeman wrote: I find email an incredibly frustrating experience all-around. It works great as long as everybody doesn't use anybody for hosting who isn't in the top-10 provider list, and doesn't use a mailing list. DMARC marks top-10 essentially creating their own walled email garden.

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

Anthony G. Basile wrote: The way gcc is dealing with this is that it is NOT bumping the soname so we can get libraries linking aginst libstdc++.so with the wrong abi and you get breakage. .. I'm not sure how to solve this one Is there any alternative to implementing the different sonames in

Re: [gentoo-dev] CI services for Gentoo Social Contract meanings of dependant notifications on depgraph breakages

Rich Freeman wrote: Jenkins, Buildbot and others are existing libre options in this ecosystem, but aren't keeping pace with development. Politics that somehow matter usually require compromise. The (rhetorical) question is, what is most important? .. The only choices we actually have

Re: [gentoo-dev] CI services for Gentoo Social Contract meanings of dependant notifications on depgraph breakages

Robin H. Johnson wrote: Why should we not be able to benefit from really good closed-source CI tools that are offered for free to the open-source community? Because it may not be in line with Gentoo politics. Jenkins, Buildbot and others are existing libre options in this ecosystem, but

Re: [gentoo-dev] Becoming a Gentoo developer?

Yanestra wrote: after a talk with some of the persons present here, it appears, Gentoo Linux is actually something like a Freemason lodge. I disagree with this. I do agree that the threshold to become a developer with write access to the gentoo repo is very high, which is why I'm not a

Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

Andrew Savchenko wrote: we should not solely rely on third-party proprietary solutions (travis is a github lock-in) because of convenience. We must not. //Peter pgp10MsxnxXNc.pgp Description: PGP signature

Re: [gentoo-dev] Looking for a generic solution to non-USE-conditional circular deps

James Le Cuirot wrote: Pacho Ramos pa...@gentoo.org wrote: As that USE flag should only be used for being able to install the package the first time, maybe it should be treated in a special way. I mean, it shouldn't be easily changed by users but, instead, switched internally by the

Re: [gentoo-dev] RFC News item: FFmpeg default

Ben de Groot wrote: I see no reason to stick with libav as default, except political (which I'm trying to avoid here). It's very convenient to try to ignore politics, but IMO that's no better in open source than on election day. A default is always a political choice. With any choice, the

Re: [gentoo-dev] libressl status

hasufell wrote: This is something that has to be resolved upstream. If they don't cooperate long-term, then their fork will just die out for sure (and for good). I agree that this is what one would intuitively expect, but what actually happens is that whatever is perceived as most mainstream

Re: 回复：Re: [gentoo-dev] RFC News item: FFmpeg default

Nicol TAO wrote: so. believe it or not? Communication should reduce confusion, not risk increasing it. //Peter

Re: [gentoo-dev] RFC News item: FFmpeg default

Ben de Groot wrote: Title: FFmpeg default Posted: 2015-04-01 Bad date for such news. //Peter

Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted

Andreas K. Huettel wrote: 0. What names for the tree/repository. gentoo IMO this is the only really accurate name. (it's also the repo_name) There you go. It already has the name gentoo. :) portage doesn't make sense, everything else is too long or potentially confusing... Yes

Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted

Jason A. Donenfeld wrote: Calling it gentoo makes sense, because the entire tree is what makes gentoo. Exactly. And the repo already has this name set in repo_name. But since it's namespaced in ebuilds/ and because ebuilds/ might have other gentoo-official repos too, then perhaps

Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted

Rich Freeman wrote: Calling it gentoo makes sense The thing is, Gentoo is more than a bunch of ebuilds. Sure, but the gentoo ebuild repo is just a bunch of ebuilds. Gentoo as name can and should be used elsewhere too of course. Certainly they're a HUGE part of Gentoo, but they alone

Re: [gentoo-dev] Re: Fonts project meeting and elections

Guilherme Amadio wrote: We could have global USE flags for each popular font format, turn on the flag for OpenType by default, and let users choose extra formats they want. I like this suggestion very much. This is exactly what I want from Gentoo. Another thing we might want to work on is

Re: [gentoo-dev] Re: Fonts project meeting and elections

Ben de Groot wrote: I propose that we prefer installing just OpenType. But this should be user configurable, so in those cases I propose we do: IUSE=+opentype if use opentype; then FONT_SUFFIX=otf else FONT_SUFFIX=ttf fi So if I first USE=-opentype and later

Re: [gentoo-dev] Re: Fonts project meeting and elections

Ben de Groot wrote: I propose that we prefer installing just OpenType. But this should be user configurable, so in those cases I propose we do: IUSE=+opentype if use opentype; then FONT_SUFFIX=otf else FONT_SUFFIX=ttf fi So if I first USE=-opentype and later USE=opentype the

Re: DKIM [gentoo-dev] Hello Everyone

Anthony G. Basile wrote: On 02/22/15 12:08, Nicolas Sebrecht wrote: * Fun is lost for a long time. This is is extremely false. It's a very subjective matter. I don't doubt that Gentoo is fun for some or many or even all developers. I also have no doubt that the process of becoming a developer

Re: [gentoo-dev] SCIM - terminal spreadsheet - sc fork

Andrés Martinelli wrote: Hello there! As many of you already pointed, the spreadsheet app SCIM I am working on, collides in its name with Smart Common Input Method. I decided that is time to change its name to avoid problems and to get lost with the other. What are your suggestions? I

Re: [gentoo-dev] ebuild copyright assignment

Rich Freeman wrote: This is part of the set of topics which we cover outside the scope of the quizzes. A brief comment from reality is that this legal problem is quit likely a significant hurdle for many potential developers - as for me. If you want contributing to be easy, overhead

Re: [gentoo-dev] ebuild copyright assignment

Justin (jlec) wrote: This is part of the set of topics which we cover outside the scope of the quizzes. A brief comment from reality is that this legal problem is quit likely a significant hurdle for many potential developers - as for me. If you want contributing to be easy, overhead like this

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog

hasufell wrote: from what comments I got back no one really wanted to join (at least under the current system). I wasn't going to force the games team to elect a new lead when it appears none cared much at that point who the lead was. Also, I would advise caution on considering it

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

Rich Freeman wrote: I personally find it annoying when people fork projects, decide not to maintain ABI compatibility with the original project, and then keep filenames the same/etc such that the packages collide in their recommended configurations. Some people do it on purpose, with

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

Rich Freeman wrote: I personally find it annoying when people fork projects, decide not to maintain ABI compatibility with the original project, and then keep filenames the same/etc such that the packages collide in their recommended configurations. Some people do it on purpose, with the

Re: [gentoo-dev] Review: USE=libav news item

Michał Górny wrote: Title: USE=libav introduction Author: Micha?? G??rny mgo...@gentoo.org Your mailer doesn't set charset for the .txt attachment. Content-Type: text/plain Posted: 2015-01-yy Revision: 1 News-Item-Format: 1.0 Display-If-Installed: media-video/ffmpeg Display-If-Installed:

Re: [gentoo-dev] Things one could be upset about

Joshua Kinard wrote: Using seed stage3 stages I built 6 months ago (but never released due to getting sidetracked), I run into errors like this: !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict:

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog

Rich Freeman wrote: working out things 1:1 if possible .. it is probably better to let Comrel do their job, rather than having everybody bicker on the list. Working out things 1:1 *on the list* is nice in that it adds transparency. Of course, it is then also very easy for people to send

Re: [gentoo-dev] Things one could be upset about

Patrick Lauer wrote: they can all be fixed. Let's not tolerate mediocrity. All you can do is to try to set an example, but you'll likely find that most of the time, nobody is willing to live with the tradeoffs for excellence - the obvious one being perceived slower development. Countless

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog

Patrick Lauer wrote: Do you, as QA team member, think that a review workflow improves quality? No. Bureaucracy does not improve quality by itself. A review workflow isn't about bureaucracy, it's about review. :) Now, review means different things to different people, and some will

Re: [gentoo-dev] First release of Gentoo Keys

Rich Freeman wrote: Would this work: gpg --gen-key option 2 - DSA and Elgamal Watch that entropy. //Peter

[gentoo-dev] Nominate global USE-flag harfbuzz

$ grep :harfbuzz profiles/use*desc profiles/use.local.desc:dev-libs/efl:harfbuzz - Enable complex text shaping and layout support. profiles/use.local.desc:dev-qt/qtgui:harfbuzz - Use media-libs/harfbuzz for text shaping (experimental in Qt 5.3.x, default in Qt 5.4.0 and later). If enabled, it

Re: [gentoo-dev] metadata.xml unherd/-ization, v2

Rich Freeman wrote: How about contact instead of team. there is no meaning to a contact besides being CC'ed on bugs. Please simply call it cc then? :) //Peter

Re: [gentoo-dev] Duplicate bug reports, resolution status and Bug 426262

Michael Mol wrote: 4) Jer marked #530478 as a dupe of #426262, To me that looks bogus. #530478 is about app-office/dia while #426262 is about two eclasses. Jeroen - please explain why you consider 530478 a duplicate of 426262? I note that you did not do so in Bugzilla while marking the dupe,

Re: [gentoo-dev] rfc: runlevels in runit or a single service directory

William Hubbs wrote: I'm just wondering what the default should be. .. Does anyone have any comments on that approach? I think the Gentoo default should just be what upstream uses and documents. //Peter pgpcub1K1GUj7.pgp Description: PGP signature

Re: [gentoo-dev] terminal spreadsheet - sc fork

Andrés Martinelli wrote: I am working on a terminal spreadsheet based on sc, but with some adds like undo/redo.. you can find it here: https://github.com/andmarti1424/scim Any new ideas and/or contribution is always welcome! See also teapot. Right, an undo stack is a nice feature.

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

Ian Stakenvicius wrote: OK, i've cobbled something together that looks like it'll work. Cool! Thanks a lot for doing that. //Peter

Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]

Alexis Ballier wrote: - why not adding a clang subprofile ? there's one for amd64-fbsd; I had been able to build a complete stage 3 without too much trouble. There's probably nothing bsd specific there, so moving generic code from there to profiles/features should work. I'd try to test

Re: [gentoo-dev] News item review: bash-completion-2.1-r90

Michał Górny wrote: the new framework is opt-out rather than opt-in. Why is it desirable to make that change? //Peter pgpAbh_XiMjXl.pgp Description: PGP signature

Re: [gentoo-dev] News item review: bash-completion-2.1-r90

Rich Freeman wrote: the new framework is opt-out rather than opt-in. Why is it desirable to make that change? there is no longer a performance penalty There is a severe behavioral penalty! We think that most users will prefer to just leave everything enabled now. I really do not want

Re: [gentoo-dev] News item review: bash-completion-2.1-r90

Peter Stuge wrote: There is a severe behavioral penalty! Rich Freeman wrote: I really do not want that to be chosen for me. Well, then all you need to do is tell eselect to disable them, etc. Well, but see above - this is a huge change in behavior - I really don't think that should be done

Re: [gentoo-dev] [PATCH git-r3] Remove unnecessary HEAD-branch mapping code

Michał Górny wrote: Remove the code responsible for recognizing which branch HEAD pointed out to since it was unsafe and unnecessarily complex. A proper match is not really necessary since all operations can be safely performed on an opaque 'HEAD' (or rather refs/git-r3/HEAD since fetching to

Re: [gentoo-dev] Re: Re: Looking for alternative to RESTRICT=userpriv

Steven J. Long wrote: It's a lot more secure to have a single well-defined privileged trust anchor (the privileged process) with a well-defined protocol, than to have built-in privilege escalation which allows arbitrary actions. You appear to have missed the point of what it does. I

Re: [gentoo-dev] Add bc back to the stage3

Hey Jorge, Jorge Manuel B. S. Vicetto wrote: I know that our policies state that technical issues should be raised in the dev ml, although they also support doing the discussion in specialized mls, but they also mention that one should make an effort to contact those involved in the

Re: [gentoo-dev] Re: RFC: Deprecating and killing herds in metadata.xml

Steven J. Long wrote: it's a bit late for that It's never too late to improve. //Peter

<    1   2   3   4   5   6   >