Re: [gentoo-dev] "Lazy" use flags?

On 12 February 2016 at 03:19, M. J. Everitt wrote: > I would avoid complicating the USE flag system .. it's straightforward > as it is, and has already been 'tweaked' by the auto-unmask feature, > leading to large package.use files and has no support of per-category > files

Re: [gentoo-dev] "Lazy" use flags?

On 12 February 2016 at 02:54, NP-Hardass wrote: > Just a slightly OT side note... Quite, these are the *sorts* of things I've been mulling over for a bit without coming to a concrete implementation idea. > I split mine off into a separate file (using a directory for

Re: [gentoo-dev] "Lazy" use flags?

On 11 February 2016 at 15:51, Rich Freeman wrote: > In this case you just wouldn't enable python 2.7 support, but you > wouldn't disable it either. Portage would just pull it in where it is > needed. But you still need a mechanism in place if you *dont* want that to happen.

Re: [gentoo-dev] "Lazy" use flags?

On 11 February 2016 at 13:42, Rich Freeman wrote: >> soft disable = Disable, unless it would break a dependency > > I don't really see why these are needed. Just do what we are already > doing - use the settings in the profile and package defaults. And soft-disable would be

Re: [gentoo-dev] "Lazy" use flags?

On 11 February 2016 at 13:42, Rich Freeman wrote: > I'm not sure why I'd want to set a preference and then just have the > system ignore it without telling me. If I tell it I want a flag > on/off then yell at me if it is a problem. I "prefer" not to pull in python packages

Re: [gentoo-dev] Changing order of default virtual/udev provider

On 9 February 2016 at 16:09, Rich Freeman wrote: > There will always be a > "poppyseed linux" whose purpose in life seems to be to preserve linux > without sysfs or some other obscure practice. This seems to be an attempt at painting the "stick with eudev" model as an "old

Re: [gentoo-dev] Changing order of default virtual/udev provider

On 9 February 2016 at 18:27, Anthony G. Basile wrote: > all the vitriolic attacks i get about eudev come from the gentoo > community. outside of this community i get praise. In case my earlier messages stating a desire to exercise much caution gave the wrong impression, I

[gentoo-dev] "Lazy" use flags?

There's a frequent irritation I experience with the revolving door of REQUIRED_USE -> auto-unmask: There's no mechanism in place to automatically stop using a "REQUIRED" use flag when it ceases to be necessary. So you find yourself doing things like: - I want X - X only supports python 2.7 - X

Re: [gentoo-dev] "Lazy" use flags?

On 10 February 2016 at 02:14, Daniel Campbell wrote: > Another concern, though, is it'd result in something similar. Instead > of "cat/foo bar baz" and later removing 'baz', you'd have "cat/foo bar > ~baz" (with '~baz' as 'enable this if you need to'). You'd still have > cruft

Re: [gentoo-dev] "Lazy" use flags?

On 10 February 2016 at 02:22, Daniel Campbell wrote: > I can certainly see the benefit here, but wouldn't that still result > in (arguably) unnecessary (re)builds? If implemented well it'd also > result in depcleaning them when they're later unneeded, too, so I > guess it's a

Re: [gentoo-dev] "Lazy" use flags?

On 10 February 2016 at 09:35, Róbert Čerňanský wrote: > > The question is whether you really need to specify the lazy use flag > explicitly. I would say that any flag which user did not set > explicitly to -baz or baz could be considered as lazy use flag. > > So if I'd have

Re: [gentoo-dev] "Lazy" use flags?

On 10 February 2016 at 14:12, Rich Freeman wrote: >> I'd personally rather the list of "automatically turn this on if >> required" be something I had the power to restrict than have a blanket >> "autodostuff", because in the event some USE can't be satisfied, the >> first time

Re: [gentoo-dev] Changing order of default virtual/udev provider

On 9 February 2016 at 01:46, Michał Górny wrote: > 1. It is a conflict-induced fork. As such, it will never be merged > upstream and it will never be supported upstream. In fact, it is > continually forces to follow upstream changes and adapt to them. eudev > is more likely to

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

On 9 February 2016 at 10:41, Michał Górny wrote: > Well, the real issue here is that people are using USE_EXPAND as some > kind of 'here, upstream give us some grouped options, let's > thoughtlessly expose them all in some fancy USE_EXPAND without thinking > about usability of

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

On 9 February 2016 at 11:44, James Le Cuirot wrote: > nginx is monolithic, if a package per module is what you meant. Yeah. That's what I was afraid of. Given what you're doing there, there's practically no other way. Other than to tell Gentoo users that you're giving them

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

On 9 February 2016 at 11:59, Luis Ressel wrote: > Thanks for citing this, I think it demonstrates mgorny's point rather > nicely; we have global USE flags for many of those modules: > > * nginx_modules_http_perl -> perl > * nginx_modules_http_auth_pam -> pam > *

Re: [gentoo-dev] Automatic Bug Assignment

On 7 February 2016 at 04:26, William Hubbs wrote: > One concern I see with making this part of the web ui for Bugzilla is > that Bugzilla would have to be able to parse the metadata.xml files in > our portage tree to find the maintainers. You could simplify it with a cron

Re: [gentoo-dev] Automatic Bug Assignment

On 6 February 2016 at 11:19, Michael Orlitzky wrote: > > You also have to take into consideration how many of them have a valid > package atom in the summary, and how many of those would have exactly > one maintainer. That's a very-sub subset of the full list. Yeah. Now that

Re: [gentoo-dev] Automatic Bug Assignment

On 31 January 2016 at 06:45, Alex Brandt wrote: > Would there be an > issue with adding a bug modification hook to bugzilla or a daily > job to re-assign bugs to ebuild owners (if a CPV is in the > subject)? I would argue the reason this probably isn't already in place

Re: [gentoo-dev] Automatic Bug Assignment

On 6 February 2016 at 07:19, Rich Freeman wrote: > 'd be all for automated bug assignment. Usually when this comes up a > bunch of hero bug wranglers step up and say it isn't needed, because > we have hero bug wranglers. As long as people keep stepping up to do > that I'm not

Re: [gentoo-dev] Automatic Bug Assignment

On 6 February 2016 at 06:41, Alec Warner wrote: > ; but 5% of the time is wrong. Just here, in the "5% are wrong" case, instead of the problem being resolved by bug wranglers, ... the problem has to be resolved by whoever got assigned. And they might not even be around in

Re: [gentoo-dev] Automatic Bug Assignment

On 6 February 2016 at 10:10, Michael Orlitzky wrote: > How about, if there's (exactly) one portage-compatible atom > in the summary and that package has (exactly) one maintainer, we > auto-assign it? Otherwise, leave it to the bug wranglers. One of my conceptual misgivings is

Re: [gentoo-dev] Automatic Bug Assignment

On 6 February 2016 at 09:47, Rich Freeman wrote: > That was my thought around having a query for bugs filed in the last > 24h. Basically they'd be auto-assigned, but people could choose to > review recent bugs to see if any were mis-assigned, and no action is > necessary if

Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM

On 4 February 2016 at 23:27, Jason Zaman wrote: > > www-servers/nginx nginx_modules_http_access nginx_modules_http_auth_basic > nginx_modules_http_autoindex nginx_modules_http_browser > nginx_modules_http_charset nginx_modules_http_fancyindex > nginx_modules_http_fastcgi

Re: [gentoo-dev] [PATCH 10/15] perl-module.eclass: Rename SRC_TEST to DIST_TEST in EAPI=6 and default to "do parallel"

On 13 December 2015 at 09:41, Andreas K. Huettel wrote: > Well. We had that idea already, and at some point something barfed, I dont > remember the details anymore. Maybe someone else from the team knows. > > The problem is introducing too many variables that look like

Re: [gentoo-dev] Revision diffs

On 7 November 2015 at 02:16, Michael Orlitzky wrote: > These days, if I'm careful to revbump when necessary AND limit my > commits to one logical change, can I wind up going from (say) -r1 all > the way to -r4 before pushing my changes. Personally I don't think that's necessary.

Re: [gentoo-dev] JFYIOR: A Simple Package Versioning Spec

On 19 September 2015 at 10:09, konsolebox wrote: > As for A6FGHKE and TRIAL, it's impossible to tell their actual level > values so even if we choose to map them lexicographically, we would > still not be able to use a universal algorithm that could tell how it > affects the

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

On 15 September 2015 at 06:54, Ulrich Mueller wrote: > >> I think it'd be okay to e.g. change the meaning and behavior of * in >> a new EAPI. > > Bug 560466 now. Assuming the syntax can be changed in a future EAPI. What EAPI applies to the use of these specifiers on the

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

On 16 September 2015 at 19:40, konsolebox wrote: > And I find it so wrong that it makes me think that it shouldn't have > been acknowledged by any packaging system. That versioning madness > should have been just fixed in the ebuilds level. Yeah. My experience with

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

On 14 September 2015 at 23:38, Ulrich Mueller wrote: > Comparison in Algorithm 2 only takes place for the zeroth component > (i.e., "1", for the example above). > > For all following numeric components Algorithm 3 is called. For the > next component, the condition in line 1 is

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

On 14 September 2015 at 18:52, Ulrich Mueller wrote: > It does, in fact. > >> When it only matches 1.0.2 and 1.0.2.* > >> You're reading it in shell glob notation and not the portage notation, >> that the trailing dot is *implied*, > > No, there isn't any dot implied. It uses

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

On 14 September 2015 at 18:09, konsolebox wrote: > Because they could also match pkg-1.0.2aa I don't believe it works that way. That would imply =pkg-1.0.2* would match 1.0.20 When it only matches 1.0.2 and 1.0.2.* You're reading it in shell glob notation and not the

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

On 14 September 2015 at 20:01, Ulrich Mueller wrote: > We could fix this in a future EAPI such that version components would > not be split when matching. So =1.3* would not match 1.30 any more > because the 30 could only be matched as a whole. > > OTOH, I am not aware of any

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

On 14 September 2015 at 21:04, Ulrich Mueller wrote: > Well, version comparison is described in [1] and it says that > =cat/foo-1.020.3 will match cat/foo-1.02.3. Surely, as per Algorithm 2, that is false, because "020" and "02" are both integers, and therefor they'd default to

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

On 14 September 2015 at 21:04, Ulrich Mueller wrote: > Could someone check what is Paludis's behaviour for the examples > above? Also, does =cat/foo-1.2* match cat/foo-1.20 in Paludis? Portage: emerge --ignore-default-opts -vpO =dev-lang/perl-5.2* These are the packages that

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

On 14 September 2015 at 20:01, Ulrich Mueller wrote: >=cat/foo-1.020.3 >=cat/foo-1.020.3* >=cat/foo-01.02.3* Of those, I only expect the last to match, because leading 0's are not typically significant. However, that "=dev-lang/perl-05.22*" matches

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

On 14 September 2015 at 20:22, konsolebox wrote: > If we use an arithmetic operator like ~> then that could be decided As a counter proposal I'd suggest a different suffix character than "*" instead. It just seems less confusing to have something like =cat/foo-1.30+

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

On 14 September 2015 at 16:35, konsolebox wrote: > Many times we need to match packages like this: something-1.0.2a.* > > But that expression is not allowed with ~ (only targets revisions) and > neither with * (.*) is invalid. What does =cat/pkg-something-1.0.2a* do? (

Re: [gentoo-dev] RFI: A better workflow for github pull requests

On 13 September 2015 at 09:15, hasufell wrote: > Because that is not a valid bug report. Patches must be attached to > bugzilla. I would recommend against attaching the pull in patch form against bugzilla. It might lead to unintentionally misleading consequences. If the

Re: [gentoo-dev] <>-DEPENDS

On 8 September 2015 at 00:35, Marc Schiffbauer wrote: > I currently have this case in app-backup/obnam which is not compatible > to =dev-python/paramiko-1.13.0 > > In DEPEND I now have this: > > !=dev-python/paramiko-1.13.0 > || ( dev-python/paramiko-1.13.0 ) > > which

Re: [gentoo-dev] <>-DEPENDS

On 8 September 2015 at 03:26, Marc Schiffbauer wrote: > And as the cherry on the cake theere could be > > <> ( foo/bar-1 foo/bar-5 ) I kinda tried suggesting a similar syntax, but then I realised it couldn't work, because it implicitly says "none of these" but it doesn't

Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-08-30 23:59 UTC

On 5 September 2015 at 01:12, Aaron W. Swenson wrote: > Would you consider dropping the TZ offset? If the script were to translate > the DT to UTC, that'd remove some noise and shorten the line by 5. +1 > dev-java/antenna 2015-09-03 13:45:07Z monsieurp

Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-08-30 23:59 UTC

On 5 September 2015 at 06:51, Michał Górny wrote: >> information. How else would we determine this? > > PGP key matching? /.mailmap git help shortlog -> MAPPING AUTHORS This system allows displaying committers under spellings/aliases/email addresses other than the one they

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

On 3 September 2015 at 07:17, Paweł Hajdan, Jr. wrote: > Do you have specific examples? None that I can currently recall, I've just long resigned myself from trying to care with Google products. The instances I can recall were more defects in their web services, some

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

On 30 August 2015 at 07:53, Matt Turner matts...@gentoo.org wrote: Is there a better way of directing reporters to file bugs upstream? Of course it's not always clear whether a bug is an ebuild bug or something easily patched in Gentoo vs a driver bug that requires an upstream developer...

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

On 30 August 2015 at 19:20, Daniel Campbell z...@gentoo.org wrote: Quick question: what is RT? RT is rt.cpan.org, for which every cpan distribution that gets published gets a free bug tracker there where permissions assigned to that bug tracker reflect permissions granted under the CPAN

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

On 30 August 2015 at 21:37, Duncan 1i5t5.dun...@cox.net wrote: In addition to the other services a distro provides, a big one is having one single place to file bugs, instead of a couple hundred different bug tracker accounts on a half-dozen tracker software bases, and that's not even counting

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

On 31 August 2015 at 00:15, Peter Stuge pe...@stuge.se wrote: In theory it can, but my experience is that in practice it doesn't change very often. sometimes the metadata visible on the CPAN sources is also wrong, and requires an experienced developer to chase its tail to work out where it

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

On 21 August 2015 at 19:16, Sergey Popov pinkb...@gentoo.org wrote: Now, THAT should be fixed either way - by moving 'dedicated' to 'server'(for those packages), or, preferabbly - by allowing USE='dedicated' to work as hasufell said - build ONLY dedicated server and no client at all. Another

Re: [gentoo-dev] QA bikeshed: killing USE=dedicated in favor of uniform USE=client+server

On 21 August 2015 at 13:03, Rich Freeman ri...@gentoo.org wrote: I'd rather see groups like QA making proposals to improve cross-Gentoo consistency than see stagnation. It was an RFC, and people can post issues with it, or escalate to Council if they're concerned. If taking it to Council I'd

Re: [gentoo-dev] Re: useflag policies

On 14 August 2015 at 05:37, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Uh, the point of the 'pretend' bit in the name is that it *is* run when you do emerge -p. It is strange really. It does them *after* prompting yes with --ask Whats the point of that? Granted they are very slow

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

On 15 August 2015 at 21:56, Andrew Savchenko birc...@gentoo.org wrote: And even with current thin-manifest workflow there may be conflict if they touch the same files. They'll be single-line conflicts though, which will mean assuming different developers touch different files, git will be able

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

On 14 August 2015 at 17:45, Michał Górny mgo...@gentoo.org wrote: Don't force the implicit expansion on all developers and users forking the repo. You wouldn't, I thought we were talking about $Id$ only being expanded on the git-rsync transition, and people worrying that $Id$ would be expanded

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

On 14 August 2015 at 07:59, Rich Freeman ri...@gentoo.org wrote: Will that include any case where the string $Id$ appears in a patch file? Surely that can be avoided by using a git attributes specification that only applies to */*/*.ebuild ? -- Kent KENTNL -

Re: [gentoo-dev] Re: useflag policies

On 12 August 2015 at 16:21, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Can't we all (except for the usual suspect) just agree that REQUIRED_USE was a mistake, and go back to pkg_pretend? The only justification for REQUIRED_USE was that it could allegedly be used in an automated

Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

On 11 August 2015 at 20:38, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-08-11, o godz. 10:29:55 Alexander Berntsen berna...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/08/15 22:59, Aaron W. Swenson wrote: Users can fetch/pull from Github. Users should

Re: [gentoo-dev] Re: Referencing bug reports in git

On 11 August 2015 at 20:57, Tobias Klausmann klaus...@gentoo.org wrote: The cat/pn rule is tricky anyway: what if one commit touches 100 packages? Or should that be split into 100 commits for easier partial rollback? I think you've misread The rule

Re: [gentoo-dev] Summary line (was: Re: Referencing bug reports in git)

On 12 August 2015 at 02:28, Ian Stakenvicius a...@gentoo.org wrote: Stuff like 'cat/pn: version bumps', 'cat/pn: new features', 'cat/pn: adjusted dependencies' are generic (and short) enough yet descriptive enough to see what went on while scanning the log. I personally find those summaries a

Re: [gentoo-dev] Re: rsync mirror security

On 11 August 2015 at 09:05, Matthias Maier tam...@gentoo.org wrote: We could also provide automatic signed tags every 30min/1h/2h/whatever (signed with a suitable infrastructure key). With that, the integrity of a tagged git checkout can be easily verified on client side. I'm distinctly under

Re: [gentoo-dev] Re: rsync mirror security

On 11 August 2015 at 15:06, Mike Frysinger vap...@gentoo.org wrote: it would have to re-use the same tag name every time otherwise we end up with 17.5k/8.7k/4.3k/whatever new tags per year ... a really bad idea I was very much under the impression git is not designed with repeated tag

Re: [gentoo-dev] Re: rsync mirror security

456d216e3d1894d62429daf0ec482c3afb087dbe git cat-file tag 456d216e3d1894d62429daf0ec482c3afb087dbe object 9ca77ee7f72902e4e89456ff560a670465969603 type commit tag test tagger Kent Fredric kentfred...@gmail.com 1439264837 +1200 A test tag -BEGIN PGP SIGNATURE- Version: GnuPG v2

Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)

On 10 August 2015 at 11:46, hasufell hasuf...@gentoo.org wrote: As I see it, a lot of people already stuff the bug number into the summary and I can't really say anything against that. It gives a nice overview when you look at it: https://gitweb.gentoo.org/repo/gentoo.git/log/ Given that

Re: [gentoo-dev] git commit / push signing error

On 10 August 2015 at 13:40, Doug Goldstein car...@gentoo.org wrote: $ git push --signed origin master You need a passphrase to unlock the secret key for user: Doug Goldstein car...@cardoe.com 4096-bit RSA key, ID 0xA2BC03DC87ED1BD4, created 2015-04-24 (subkey on main key ID

Re: Verification of installed packages (was Re: OpenPGP verification (was Re: [gentoo-dev] Git, GPG Signing, and Manifests))

On 17 July 2015 at 22:34, Andrew Savchenko birc...@gentoo.org wrote: 2. Add an optional feature to emerge (or even to PMS?) allowing user to provide a usable GPG key for signing packages CONTENTS files after its generation. In order for such key to be usable during emerge run, gpg-agent should

Re: [gentoo-dev] Git, GPG Signing, and Manifests

On 17 July 2015 at 13:13, NP-Hardass np-hard...@gentoo.org wrote: Additionally, I feel that a signature is a means of acknowledging that a package has been looked over, and that developer has stated that they approve of the existing state That much is somewhat implied by a developer owning a

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

On 7 July 2015 at 12:04, Patrick Lauer patr...@gentoo.org wrote: So thanks for your intentional comedy, but let's be serious here. It would be really nice if we could define some sort of variable in the ebuild itself with a relative cost metric for the ebuilds install time. It wouldn't need to

Re: [gentoo-dev] Re: Git workflow

On 7 July 2015 at 01:48, Peter Stuge pe...@stuge.se wrote: fact that a merge commit ideally does *not* contain any modifications. That's not /entirely/ true. The merge commit will have a new TREE object which is a composite TREE object of both of its PARENT TREE objects ( But all BLOBs in the

Re: [gentoo-dev] Re: Git workflow

On 5 July 2015 at 17:03, C Bergström cbergst...@pathscale.com wrote: Again I don't see it as lying - (you're still working on stuff until you push.. development isn't done) The ability to do micro or incremental commits instead of the svn's forced wait approach is the benefit here.

Re: [gentoo-dev] signatures in git work flow

On 6 July 2015 at 08:01, William Hubbs willi...@gentoo.org wrote: Once we have a version of git stable that allows this, can someone fill me in on why we would need to sign commits if we sign pushes? If we have a signature on the push, we know where that came from, so it seems to be overkill

Re: [gentoo-dev] Re: Git workflow

On 6 July 2015 at 07:15, William Hubbs willi...@gentoo.org wrote: 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. git show SHA1 -m -- Kent KENTNL - https://metacpan.org/author/KENTNL

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

On 7 June 2015 at 00:22, Justin Lecher (jlec) j...@gentoo.org wrote: * linewidth 80 (why do we have this short limit still in 2015) I wouldn't say this is the reason... but there's a specific benefit for me at least with the font size I use and the screen size I have. Means you can fit 2

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

On 4 May 2015 at 02:04, Georg Rudoy 0xd34df...@gmail.com wrote: 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

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

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? Shouldn't the USE flag be thus in terms of what that functionality is, not in

Re: [gentoo-dev] Re: git://anongit.gentoo.org is extremely slow

On 23 April 2015 at 21:02, Duncan 1i5t5.dun...@cox.net wrote: with patches already in the live-git version, and I believe lessons were learned about coordinating repo updates when a major host changes as well, so hopefully, if there's a next time it'll go much smoother than this one did.

Re: [gentoo-dev] Re: git://anongit.gentoo.org is extremely slow

On 23 April 2015 at 15:07, Duncan 1i5t5.dun...@cox.net wrote: Perhaps the slashdot effect of everybody almost at once needing to delete and (re)add their overlays in layman, thus forcing a new clone, Eh? That seems incredibly wrong for git. git remote set-url master newurl Would handle the

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

On 18 April 2015 at 02:33, Andrew Savchenko birc...@gentoo.org wrote: The problem is double effort: previously one developer effort was needed, now effort is doubled at least: reviewers must dig into details how submitted code works, test it and only then commit. Now remember that reviewers

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

On 18 April 2015 at 07:14, Justin Bronder jsbron...@gentoo.org wrote: Unless the process has changed drastically since I joined, the only lengthy part of joining is potentially waiting for the recruitment team to catch up on their backlog. If someone doesn't have a couple of hours to spend

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

On 17 April 2015 at 05:27, hasufell hasuf...@gentoo.org wrote: To reply to the topic: If the only reason you want to become a gentoo developer is contributing ebuilds, then you should reconsider that, because there are easier ways to do that. But if you are interested in politics, PMS, EAPI

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

On 17 April 2015 at 02:22, Bob Wya bob.mt@gmail.com wrote: Are you maintaining an overlay listed in Layman? If not then it's pretty obvious that you're just trolling the mailing list and wasting a lot of folk's time... I'm not sure that's the case. Its easy enough to maintain an

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

On 00:29, Sun, 12/04/2015 Michał Górny mgo...@gentoo.org wrote: I think the simplest solution would be to develop a generic USE flag that would only serve the purpose of forcing bundled dependencies for bootstrapping/initial install. We have already: build - !!internal use only!! DO NOT SET

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

On 02:36, Sun, 12/04/2015 Andreas K. Huettel dilfri...@gentoo.org wrote: build - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first half of bootstrapping [make stage1] bootstrap - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!,

Re: [gentoo-portage-dev] Dynamic USE dependencies

On 3 April 2015 at 05:32, Rich Freeman ri...@gentoo.org wrote: Out of curiosity, what is keeping us from having USE flag dependencies handled dynamically, in the same way that package dependencies are? If portage can figure out that I need libxml2 installed even if I don't put it in

Re: [gentoo-portage-dev] Dynamic USE dependencies

On 3 April 2015 at 06:32, Rich Freeman ri...@gentoo.org wrote: Why is this necessary? If a USE flag changes, just rebuild the application. Isn't the nature of your proposal,( that is, dynamic deps for USE flags ) inherently Use flags change, _dont_ rebuild the application ? :) It may help

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

On 27 March 2015 at 10:32, Andreas K. Huettel dilfri...@gentoo.org wrote: It would be great to logically separate ebuild repositories (main tree and overlays) somehow logically from code, data, ... How about adding an additional level repo for everything that contains ebuild trees?

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

On 15 March 2015 at 21:54, Dirkjan Ochtman d...@gentoo.org wrote: . In that vain, gentoo-base could also work? I like this idea. I was initially toying with gentoo-overlay because it was more specific than repo but it didn't float well because the model was wrong. gentoo-base however kinda

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

On 15 March 2015 at 11:37, Rich Freeman ri...@gentoo.org wrote: Suggestions: gentoo-repo gentoo-repository gentoo-main gentoo-repo-main gentoo-repository-main Similarly in the solve confusion as to purpose for newbies: gentoo-packages gentoo-ebuilds The names would be possibly be

Re: [gentoo-portage-dev] RFC: emerge manpage options categorization

On 12 March 2015 at 15:19, Duncan 1i5t5.dun...@cox.net wrote: Comments? A less radical change would be some sort of tagging notation on each feature to indicate their usage. That way, it doesn't impede the current audience who expects to be able to browse the list alphabetically. ( I suggest

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

On 6 March 2015 at 09:03, Michael Orlitzky m...@gentoo.org wrote: I've settled on using a colon i.e. jer format. If the bug references a specific version (range), then I use =, =, etc. appropriately. In the case of stabilization bugs, I'd throw in the =. I was under the impression adding =

Re: [gentoo-dev] Policies for games dirs, new group gamestat for sgid binaries

On 22 February 2015 at 15:35, Daniel Campbell cont...@sporkbox.us wrote: Personally, I think that controlling who is allowed to run certain types of applications via group membership is a great idea. We should introduce that approach for other applications too. How about an editors

Re: [gentoo-dev] Policies for games dirs, new group gamestat for sgid binaries

On 22 February 2015 at 18:06, Gordon Pettey petteyg...@gmail.com wrote: Protect the permissions on the files, not the editors - there's always another way to get content into a file if you have write permission to it. If you try to do that with a g+xo-x, then you're going to have to do the

Re: [gentoo-dev] REQUIRED_USE=test vs. repoman

On 9 November 2014 09:06, Zac Medico zmed...@gentoo.org wrote: Since EAPI 5, you need to either add test to IUSE, or else we need to add the test flag to IUSE_IMPLICIT in the base profile (that would require some discussion of pros/cons). It should have been needed on EAPI4 too, but due to a

Re: [gentoo-dev] RFC: new QA_NEEDED variable for files installed by pre-built binary packages with broken soname dependencies

On 8 November 2014 13:59, Zac Medico zmed...@gentoo.org wrote: Okay, sure. I'll save it for the day when someone finds a valid reason to install binaries with broken soname deps (not likely). Another candidate for a possible valid reason: https://bugs.gentoo.org/show_bug.cgi?id=460468

Re: [gentoo-dev] [EBUILD] unknown description

On 17 October 2014 08:54, sp4ze sp...@sp4ze.net wrote: I looked the other ebuild using faad ( mpd, mplayer... ) but I see no difference with mine. grep faad /usr/portage/media-video/mplayer/metadata.xml flag name=faadUse external faad library for AAC decoding/flag grep faad

Re: [gentoo-dev] Re: git security (SHA-1)

On 21 September 2014 09:01, hasufell hasuf...@gentoo.org wrote: Because there are other VCSs it is not a bug?? No, it just means using SHA1 for making a repository work is not a bug, just like using i am number 6, parent is number 5 is not a security bug. Of course it is a bug since it is

Re: [gentoo-dev] Re: git security (SHA-1)

On 21 September 2014 09:18, hasufell hasuf...@gentoo.org wrote: Kent Fredric: He is proposing quite the opposite. He's saying git is not secure in this way, but lets not let that stop us, migrate and fix that after the fact or we'll never get around to it, because all this debate

Re: [gentoo-dev] Re: git security (SHA-1)

On 21 September 2014 09:18, hasufell hasuf...@gentoo.org wrote: I didn't see him saying that. It rather sounds like we want to have thick signed Manifests and break pull requests and whatnot. Those aren't the only options. We could of course develop a custom commit signature system, either

Re: [gentoo-scm] Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process

On 19 September 2014 06:51, Rich Freeman ri...@gentoo.org wrote: Git even allows the use of tools like meld to resolve conflicts, besides the usual fill-the-file-with-diffs-to-cleanup approach. I'd personally discourage any kind of collision resolution in the merge itself. Mostly because

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

On 19 September 2014 07:33, Diamond diam...@hi-net.ru wrote: Lets assume, that I don't want to scrap old ebuild yet. There's no git cp command. git mv is just git rm + git add. That's what does it look like (usual revbump with git add in reality):

Re: [gentoo-dev] Git copy detection (was: My masterplan for git migration...)

On 19 September 2014 10:13, Diamond diam...@hi-net.ru wrote: P.S. As you see from description this option affects git performance. So, we probably can arrive at a conclusion that git itself isn't good at all for package management. Maybe there are better architectural decisions for that.

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

On 18 September 2014 08:02, Diamond diam...@hi-net.ru wrote: Git doesn't do this by default and it will might be a nightmare to compare such revbumps by hand. git diff -M1 -C1 ^ is usually sufficient to show new files as differences between similar files that were already there, including

<    1   2   3   4   5   6   7   8   9   >