Re: [gentoo-dev] games.eclass

On 08/21/2015 08:50 AM, Ulrich Mueller wrote: On Fri, 21 Aug 2015, hasufell wrote: Like allowing that devs may or may not use games.eclass, so that users cannot expect consistent behavior for games anymore? Sorry, but that is not accurate. Usage of games.eclass has been deprecated by QA

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

On 08/21/2015 02:04 PM, Rich Freeman wrote: Right now there isn't even a functional games team to leave alone, and this isn't just about games. Exactly. Start there, instead of having the council or QA impose games policies. It's not their job.

Re: [gentoo-dev] games.eclass

On 08/21/2015 07:39 PM, Rich Freeman wrote: On Fri, Aug 21, 2015 at 11:10 AM, hasufell hasuf...@gentoo.org wrote: On 08/21/2015 08:50 AM, Ulrich Mueller wrote: On Fri, 21 Aug 2015, hasufell wrote: Like allowing that devs may or may not use games.eclass, so that users cannot expect

Re: [gentoo-dev] games.eclass

On 08/22/2015 05:25 PM, Rich Freeman wrote: On Saturday, August 22, 2015, hasufell hasuf...@gentoo.org wrote: Games differ in a lot of ways and they _require_ different policies. In some cases this also means more lax policies and in some cases more strict policies. An example

Re: [gentoo-dev] games.eclass

On 08/22/2015 08:01 PM, Daniel Campbell (zlg) wrote: The primary concern of gamers is that the game runs and that they can reasonably install it (see the games-roguelike/nethack bug which was unsolved for 8 years). What happened with that bug? 8 years? That's insane! It got fixed in

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

On 08/20/2015 07:42 PM, Michał Górny wrote: Hi, Right now, a number of game packages are using USE=dedicated to control 'installing a dedicated game server only'. Aside to that, some game packages also have USE=server that controls building the server itself. Non-game package use USE=client

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

On 08/20/2015 09:32 PM, James Le Cuirot wrote: On Thu, 20 Aug 2015 20:03:26 +0200 hasufell hasuf...@gentoo.org wrote: As an alternative, we would use USE=client and USE=server along with proper IUSE defaults to control client server builds appropriately. Both flags use positive logic

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

On 08/20/2015 11:19 PM, Martin Vaeth wrote: Alexander Berntsen berna...@gentoo.org wrote: - -1. The way dedicated is used in games ebuilds is a very established term that all gamers know and expect to behave in a specific way. This will mess with our users. How do you know what the users

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

On 08/21/2015 12:06 AM, Jason A. Donenfeld wrote: This seems quite reasonable, and I welcome QA's efforts at maintaining uniformity and cleanliness. Like allowing that devs may or may not use games.eclass, so that users cannot expect consistent behavior for games anymore? Instead of ignoring

Re: [gentoo-dev] Re: Git Migration: go-live!

On 08/09/2015 12:16 PM, Ryan Hill wrote: On Sun, 9 Aug 2015 05:36:16 + Robin H. Johnson robb...@gentoo.org wrote: On Sat, Aug 08, 2015 at 05:47:14PM +, Robin H. Johnson wrote: On Thu, Jul 02, 2015 at 09:39:52PM +, Robin H. Johnson wrote: 2015/08/08 15:00 UTC - Freeze 2015/08/08

Re: [gentoo-dev] Re: Git Migration: go-live!

On 08/09/2015 01:55 PM, Aaron W. Swenson wrote: On 2015-08-09 13:22, hasufell wrote: On 08/09/2015 12:16 PM, Ryan Hill wrote: On Sun, 9 Aug 2015 05:36:16 + Robin H. Johnson robb...@gentoo.org wrote: On Sat, Aug 08, 2015 at 05:47:14PM +, Robin H. Johnson wrote: On Thu, Jul 02, 2015

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/microcode-ctl/

On 08/11/2015 08:34 AM, Mike Frysinger wrote: commit: 719cc5ef240b766953ddbe1e7a6593f8091eed12 Author: Mike Frysinger vapier AT gentoo DOT org AuthorDate: Tue Aug 11 06:28:16 2015 + Commit: Mike Frysinger vapier AT gentoo DOT org CommitDate: Tue Aug 11 06:34:22 2015 +

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

On 08/11/2015 01:49 PM, Rich Freeman wrote: On Tue, Aug 11, 2015 at 5:12 AM, Kent Fredric kentfred...@gmail.com wrote: 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

Re: [gentoo-dev] Developer branches on proj/gentoo

On 08/11/2015 03:52 PM, Patrice Clement wrote: Hi there According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, there may be developer-specific, task-specific, project-specific branches etc. As far as I understand, it means I can go and create my own branch on the

Re: [gentoo-dev] Developer branches on proj/gentoo

On 08/11/2015 04:10 PM, Alexis Ballier wrote: On Tue, 11 Aug 2015 16:01:05 +0200 Michał Górny mgo...@gentoo.org wrote: Dnia 2015-08-11, o godz. 15:52:16 Patrice Clement monsie...@gentoo.org napisał(a): Hi there According to

Re: [gentoo-dev] Summary line

On 08/11/2015 04:28 PM, Ian Stakenvicius wrote: On 11/08/15 04:57 AM, Tobias Klausmann wrote: The more we stuff into the summary line, the harder it will be to write meaningful summaries. And thus, people will write crappy ones or ignore the length limit. I recommend against any more

Re: [gentoo-dev] Developer branches on proj/gentoo

On 08/11/2015 05:21 PM, Alexis Ballier wrote: Big changes that that go in feature branches and are merged in one pass are, from my experience, way too much prone to errors. Did anyone ever try to review a merge commit? You will run repoman (and probably other pkgcore based checks) before

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

On 08/11/2015 06:42 PM, Michał Górny wrote: Dnia 2015-08-10, o godz. 22:51:59 hasufell hasuf...@gentoo.org napisał(a): I was wondering if that could be automated in a separate branch (only needs to update in 24h intervals). Please don't cruft the repo with huge metadata. And I have

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

On 08/14/2015 01:10 PM, Andrew Savchenko wrote: On Fri, 14 Aug 2015 02:11:09 -0700 Daniel Campbell (zlg) wrote: I honestly don't see the point of this when `git log` or even `git diff` or standard `diff` will tell you if what's in your overlay differs from the source. With some bash magic it

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

On 08/10/2015 03:19 PM, Michał Górny wrote: Thanks, this is exactly what I wanted. Fixes, References, Bug are all good. Bugzilla goes against your proposal diverging keyword depending on bug tracker software. Afaik Fixes: is for referencing commits, not bug reports. And now I am

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

On 08/09/2015 03:58 PM, Michael Weber wrote: commit: 40b3fd64ec9c5d6d94f0f0897740bc77622c24a1 Author: Michael Weber xmw AT gentoo DOT org AuthorDate: Sun Aug 9 13:58:26 2015 + Commit: Michael Weber xmw AT gentoo DOT org CommitDate: Sun Aug 9 13:58:26 2015 + URL:

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

On 08/09/2015 05:03 PM, Sven Vermeulen wrote: On Sun, Aug 09, 2015 at 04:43:36PM +0200, Dirkjan Ochtman wrote: I think X-Gentoo-Bug: 557022 also makes the job easier for tools that parse commit messages. I don't. Just the bug prefix should be fine for almost all purposes, even for tools.

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-video/handbrake/files/, media-video/handbrake/

On 08/09/2015 03:43 PM, Ian Whyman wrote: commit: b8f141afeb0e183298fe227672ac9338e0e8e12c Author: Ian Whyman thev00d00 AT gentoo DOT org AuthorDate: Sun Aug 9 12:30:22 2015 + Commit: Ian Whyman thev00d00 AT gentoo DOT org CommitDate: Sun Aug 9 13:43:25 2015 + URL:

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: kde-base/kdepim-icons/

On 08/09/2015 08:25 PM, Agostino Sarubbo wrote: commit: 3fd6580a947db519cb60a4c2a05ec380ceb681d8 Author: Agostino Sarubbo ago AT gentoo DOT org AuthorDate: Sun Aug 9 18:23:44 2015 + Commit: Agostino Sarubbo ago AT gentoo DOT org CommitDate: Sun Aug 9 18:23:44 2015 +

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

On 08/09/2015 05:19 PM, Tobias Klausmann wrote: Hi! On Sun, 09 Aug 2015, Sven Vermeulen wrote: On Sun, Aug 09, 2015 at 04:43:36PM +0200, Dirkjan Ochtman wrote: I think X-Gentoo-Bug: 557022 also makes the job easier for tools that parse commit messages. I don't. Just the bug prefix

Re: [gentoo-dev] Git workflow, commit messages

On 08/09/2015 02:06 PM, Anthony G. Basile wrote: Hi everyone, I hate to be a nag, but please read https://wiki.gentoo.org/wiki/Gentoo_git_workflow. In particular, commit messages. I'm seeing lots of cvs style messages going in and without history it will be hard to figure out what

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: kde-base/kdepim-icons/

On 08/09/2015 08:59 PM, Agostino Sarubbo wrote: On Sunday 09 August 2015 20:42:00 hasufell wrote: So, now we have 21 commits with the exact same commit message: = Stable for amd64, wrt bug #556974 = At that point, it's even debatable to have separate commits. IMO, if you stabilize

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

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 fact, I am not sure we can convince people to repeat the bug number in

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

On 08/09/2015 09:56 PM, Michał Górny wrote: Dnia 2015-08-09, o godz. 16:09:29 hasufell hasuf...@gentoo.org napisał(a): On 08/09/2015 03:58 PM, Michael Weber wrote: commit: 40b3fd64ec9c5d6d94f0f0897740bc77622c24a1 Author: Michael Weber xmw AT gentoo DOT org AuthorDate: Sun Aug 9 13

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

On 08/10/2015 10:47 PM, Andrew Savchenko wrote: On Mon, 10 Aug 2015 22:13:23 +0200 hasufell wrote: On 08/10/2015 05:09 PM, Rich Freeman wrote: On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert flop...@gentoo.org wrote: Expanding on this: the rsync master creates the following files/directories

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

On 08/10/2015 05:09 PM, Rich Freeman wrote: On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert flop...@gentoo.org wrote: Expanding on this: the rsync master creates the following files/directories under metatdata. On my own system, I like to symlink them to locations outside my repo so that

Re: [gentoo-dev] .gitignore

On 08/10/2015 05:09 PM, Rich Freeman wrote: On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert flop...@gentoo.org wrote: Expanding on this: the rsync master creates the following files/directories under metatdata. On my own system, I like to symlink them to locations outside my repo so that

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

On 08/15/2015 11:56 AM, Andrew Savchenko wrote: On Sat, 15 Aug 2015 11:02:19 +0200 Michał Górny wrote: OK, if manifests are that important, why not generate full manifest during repoman commit? If we do not tamper with $Id$, the only file outside of this manifest will be ChangeLog generated

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/microcode-ctl/

On 08/12/2015 12:11 PM, hasufell wrote: On 08/12/2015 08:48 AM, Andrew Savchenko wrote: On Tue, 11 Aug 2015 13:17:10 +0200 hasufell wrote: On 08/11/2015 08:34 AM, Mike Frysinger wrote: commit: 719cc5ef240b766953ddbe1e7a6593f8091eed12 Author: Mike Frysinger vapier AT gentoo DOT org

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/microcode-ctl/

On 08/12/2015 08:48 AM, Andrew Savchenko wrote: On Tue, 11 Aug 2015 13:17:10 +0200 hasufell wrote: On 08/11/2015 08:34 AM, Mike Frysinger wrote: commit: 719cc5ef240b766953ddbe1e7a6593f8091eed12 Author: Mike Frysinger vapier AT gentoo DOT org AuthorDate: Tue Aug 11 06:28:16 2015 +

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

So, I've just tried to count the ++ for different ideas and even if I missed one or two or misread someone's opinion, I think the result is pretty clear: reference the bug only in the summary: 1 don't make any of this mandatory: 1 Gentoo-Bug: 123 or similar short form: 9 Gentoo-Bug: url or

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

On 08/12/2015 05:59 PM, Chí-Thanh Christopher Nguyễn wrote: hasufell schrieb: So, I've just tried to count the ++ for different ideas and even if I missed one or two or misread someone's opinion, I think the result is pretty clear: reference the bug only in the summary: 1 don't make any

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

On 08/12/2015 07:48 PM, Dmitry Yu Okunev wrote: On 08/12/2015 08:38 PM, Matt Turner wrote: On Wed, Aug 12, 2015 at 3:40 AM, hasufell hasuf...@gentoo.org wrote: So, I've just tried to count the ++ for different ideas and even if I missed one or two or misread someone's opinion, I think

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

On 08/10/2015 02:51 AM, Ulrich Mueller wrote: On Mon, 10 Aug 2015, Andrew Savchenko wrote: This is not a matter of going l33t, this is a matter of getting rid of redundant and pretty much useless data all the same through almost all commit messages. +1 Gentoo-Bug: 123456 or even Bug:

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-misc/dropbear/, net-misc/dropbear/files/

On 08/09/2015 02:56 PM, Mike Frysinger wrote: commit: ceef36bd30b9f9ac1e58450fc434344fb964fd95 Author: Mike Frysinger vapier AT gentoo DOT org AuthorDate: Sun Aug 9 08:34:29 2015 + Commit: Mike Frysinger vapier AT gentoo DOT org CommitDate: Sun Aug 9 12:56:21 2015 +

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

On 08/09/2015 04:26 PM, Dirkjan Ochtman wrote: On Sun, Aug 9, 2015 at 4:09 PM, hasufell hasuf...@gentoo.org wrote: I was wondering if we should set a standard for referencing bug reports. The portage team already does something like that: https://github.com/gentoo/portage/commit

Re: [gentoo-dev] Git workflow, commit messages

On 08/09/2015 04:31 PM, Gordon Pettey wrote: On Sun, Aug 9, 2015 at 7:06 AM, Anthony G. Basile bluen...@gentoo.org mailto:bluen...@gentoo.org wrote: Particularly, we should prepend CATEGORY/PN: to the first line so we can easily search git log for what happened to a package.

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

On 08/09/2015 04:43 PM, Dirkjan Ochtman wrote: On Sun, Aug 9, 2015 at 4:38 PM, hasufell hasuf...@gentoo.org wrote: I don't really see why it has to be so verbose. Can we just make it bug 557022, or even #557022? That would also make it fit better if you have a single-line commit message only

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-process/anacron/

On 08/10/2015 10:00 AM, Mike Frysinger wrote: commit: 2f168392284fec294f9bfbb06d1c0a8a46f5a7d5 Author: Mike Frysinger vapier AT gentoo DOT org AuthorDate: Mon Aug 10 07:39:36 2015 + Commit: Mike Frysinger vapier AT gentoo DOT org CommitDate: Mon Aug 10 07:59:50 2015 +

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

On 07/17/2015 10:18 AM, Kristian Fiskerstrand wrote: On 07/17/2015 03:13 AM, NP-Hardass 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. I'm not sure if others

Re: [gentoo-dev] [RFC] Rebooting the Installer Project

On 07/18/2015 09:36 PM, NP-Hardass wrote: On Sat, 18 Jul 2015 12:01:48 -0700 Matthew Marchese maffblas...@gentoo.org wrote: Hello all, I have recently pressed the reboot button on the ol' Installer project. I've been able to talk to quite a few developers one-on-one via IRC concerning my

Re: [gentoo-dev] Re: ssl vs openssl vs libressl vs gnutls USE flag foo

On 10/28/2015 12:23 PM, Anthony G. Basile wrote: > > A properly designed sub-USE flag would be useful here and clearly better > than our REQUIRED_USE. I think REQUIRED_USE is fine for heterogeneous > cases, but not when you have something like curl where you can either > turn ssl on or off. If

Re: [gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo

On 10/28/2015 09:36 AM, Alexis Ballier wrote: > On Wed, 28 Oct 2015 03:06:59 +0100 > hasufell <hasuf...@gentoo.org> wrote: >> A is not that difficult. Most uses of 'openssl' can just be replaced >> with 'ssl', others probably with '!gnutls?' even. A few exotic ones >&g

Re: [gentoo-dev] Re: ssl vs openssl vs libressl vs gnutls USE flag foo

On 10/28/2015 07:23 AM, Ryan Hill wrote: > > Agreed. If there's one choice then "ssl" should be used. > openssl/libressl/etc > should really be considered sub-flags of ssl. > > I really wish we had some way of specifying this to make things clearer to the > user, so they could see exactly how

Re: [gentoo-dev] Re: ssl vs openssl vs libressl vs gnutls USE flag foo

On 10/28/2015 12:20 PM, Kristian Fiskerstrand wrote: > On 10/28/2015 07:23 AM, Ryan Hill wrote: > > >> Agreed. If there's one choice then "ssl" should be used. >> openssl/libressl/etc should really be considered sub-flags of ssl. > > > If we are introducing a new and proper way to define this

[gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo

I've seen a lot of ebuilds lately that use 'openssl' USE flag for the purpose of enabling ssl features. I think this should be discouraged since it introduces inconsistency and is especially confusing for packages like media-video/ffmpeg, where'd you expect to get ssl support by having the global

Re: [gentoo-dev] Non-fast-forward push to gentoo repository

On 10/23/2015 09:59 PM, Luis Ressel wrote: > On Wednesday, someone seems to have done a --force'd push to the gentoo > repository. The commits > * 5e04009 sci-mathematics/minisat: rev-bump and build fixes for latest, > QA cleanup > * 9c9fce9 media-libs/urt: build fixes, QA cleanups, new shared

[gentoo-dev] Re: [gentoo-commits] data/gentoo-news:master commit in: 2015-10-21-future-support-of-hardened-sources-kernel/

On 10/21/2015 03:34 AM, Anthony G. Basile wrote: > commit: 1ff602d951b09029917bcc5bf391cbe390772a7b > Author: Anthony G. Basile gentoo org> > AuthorDate: Wed Oct 21 01:31:55 2015 + > Commit: Anthony G. Basile gentoo org> > CommitDate: Wed Oct 21 01:40:43 2015 + > URL:

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/intelhex/

On 10/21/2015 07:21 PM, Ciaran McCreesh wrote: > On Wed, 21 Oct 2015 01:25:53 +0200 > hasufell <hasuf...@gentoo.org> wrote: >> Also, my package manager chokes on it. Repoman not, so that looks >> like a bug. > > s/Repoman/Portage/ > > Portage will qu

Re: [gentoo-dev] ChangeLog

On 11/01/2015 01:16 PM, Patrick Lauer wrote: > Ahoi, > > I'm getting mildly very irritated with the lack of easily accessible > ChangeLogs for our packages. > > Apparently updating them stopped some time in August, so now there are > some outdated ChangeLogs that don't really serve any purpose,

Re: [gentoo-dev] Re: ChangeLog

On 11/03/2015 04:04 PM, Chí-Thanh Christopher Nguyễn wrote: > Matt Turner schrieb: >> The git transition had been 9 years in the making and has massively >> improved Gentoo development. Look at the graph of contributions per >> month: https://www.openhub.net/p/gentoo > > I'd like to point out

Re: [gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo

On 10/30/2015 10:16 PM, Anthony G. Basile wrote: > On 10/30/15 3:35 PM, hasufell wrote: >> On 10/30/2015 06:55 PM, Michał Górny wrote: >>> We have no way of saying 'I prefer polarssl, then gnutls, then >>> libressl, and never openssl'. >> I don't think this is

Re: [gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo

On 10/30/2015 11:56 PM, Michał Górny wrote: > On Fri, 30 Oct 2015 23:40:28 +0100 > hasufell <hasuf...@gentoo.org> wrote: > >> On 10/30/2015 10:16 PM, Anthony G. Basile wrote: >>> On 10/30/15 3:35 PM, hasufell wrote: >>>> On 10/30/2015 06:55 PM,

Re: [gentoo-dev] ChangeLog

On 11/01/2015 02:47 PM, Alexis Ballier wrote: > On Sun, 1 Nov 2015 14:33:07 +0100 > hasufell <hasuf...@gentoo.org> wrote: >>>> >>>> git log -- app-misc/foo >>>> or >>>> git log -- eclass/autotools.eclass >>>> >>

Re: [gentoo-dev] Gentoo-hosted code review

On 11/01/2015 06:44 PM, Michael Palimaka wrote: > There's been a lot of discussion about relying on GitHub for pull > requests and code review and such, so I have set up a Phabricator > instance against gentoo.git to see how a free alternative might work. > > Here's a few examples of how things

Re: [gentoo-dev] ChangeLog

gt;> tree directly from git: >> https://github.com/hasufell/portage-gentoo-git-config >> >> At some point, rsync schould be deprecated completely. > > Nice try, but sometimes (say, in case of very unstable internet connection) > it is IMPOSSIBLE to properly sync git repo (

Re: [gentoo-dev] ChangeLog

??? > You shouldn't use rsync anymore, it is inherently insecure. The git tree is _properly_ gpg signed so you can verify it's correctness. With the following portage configuration/hooks, any user can run the tree directly from git: https://github.com/hasufell/portage-gentoo-git-config At some point, rsync schould be deprecated completely.

Re: [gentoo-dev] Gentoo-hosted code review

On 11/01/2015 08:50 PM, Manuel Rüger wrote: > On 01.11.2015 20:23, hasufell wrote: >> On 11/01/2015 06:44 PM, Michael Palimaka wrote: >>> There's been a lot of discussion about relying on GitHub for pull >>> requests and code review and such, so I have set up a Phabr

Re: [gentoo-dev] ChangeLog

On 11/04/2015 09:56 AM, Andrew Savchenko wrote: > On Sun, 1 Nov 2015 14:53:20 +0100 hasufell wrote: >>>> You shouldn't use rsync anymore, it is inherently insecure. The git >>>> tree is _properly_ gpg signed so you can verify it's correctness. >>>> >&g

Re: [gentoo-dev] ChangeLog

On 11/04/2015 05:33 PM, Chí-Thanh Christopher Nguyễn wrote: > hasufell schrieb: >> On 11/04/2015 09:56 AM, Andrew Savchenko wrote: >>> No, it is not. The whole git tree is insecure and no better than >>> rsync or CVS in terms of data security because SHA1 is vulnera

Re: [gentoo-dev] ChangeLog

On 11/04/2015 05:44 PM, Chí-Thanh Christopher Nguyễn wrote: > hasufell schrieb: > >> If you want to improve the situation, go talk to git upstream >> and send patches. > > Or do what Andrew suggested should happen. > > If you want to break the whole git workflow yes. Good suggestion.

Re: [gentoo-dev] Depending on a range of slots

On 11/02/2015 09:51 PM, Michael Orlitzky wrote: > On 11/02/2015 02:48 PM, Ciaran McCreesh wrote: >> On Mon, 2 Nov 2015 14:33:57 -0500 >> Michael Orlitzky wrote: >>> Followup question, which of these is less dumb? >>> >>> Option 1: berkdb? ( >=sys-libs/db-4:* > >> This doesn't

Re: [gentoo-dev] Re: ChangeLog

On 11/02/2015 10:54 PM, Dale wrote: > Ciaran McCreesh wrote: >> On Mon, 2 Nov 2015 14:00:18 -0600 >> Dale wrote: >>> Rich Freeman wrote: On Mon, Nov 2, 2015 at 1:08 AM, Dale wrote: > Then perhaps all this should have been worked out BEFORE

Re: [gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo

On 10/30/2015 06:55 PM, Michał Górny wrote: > > We have no way of saying 'I prefer polarssl, then gnutls, then > libressl, and never openssl'. I don't think this is something that can be reasonably supported and it sounds awfully automagic. And I don't see how this is possible right now, so I'm

[gentoo-dev] stabilization commits and atomicity

I'd like to discuss whether we should allow/encourage stabilization commits to be less atomic. They often bloat the history, make it hard to skim through the summaries list and people who are looking for stabilization probably do 'git log -- ' anyway, no? In addition, I'm not sure the bug

Re: [gentoo-dev] stabilization commits and atomicity

On 10/19/2015 04:37 PM, Ian Stakenvicius wrote: > > > > It may be my lack of coffee this morning, but I think you and > hasufell are saying the same thing but using "making commits less > atomic" conversely. > > Just so i make sure i'm understanding t

Re: [gentoo-dev] [rfc] drop iputils from @system (i.e. ping)

On 10/15/2015 03:26 PM, Michael Orlitzky wrote: > On 10/14/2015 11:39 PM, Mike Frysinger wrote: >> iputils is currently in @system for everyone. by default, it only >> installs `ping`. do we feel strongly enough about this to require >> all systems include it ? or should this wait for the long

Re: [gentoo-dev] stabilization commits and atomicity

On 10/19/2015 07:37 PM, Rich Freeman wrote: > > However, stabilizing a single package really is an impactful change. > The fact that you're doing 100 of them at one time doesn't really > diminish the impact of each one. Any of them could break a system or > need to be reverted. > Since when do

Re: [gentoo-dev] stabilization commits and atomicity

On 10/19/2015 07:52 PM, Rich Freeman wrote: > On Mon, Oct 19, 2015 at 1:40 PM, hasufell <hasuf...@gentoo.org> wrote: >> On 10/19/2015 07:37 PM, Rich Freeman wrote: >>> >>> However, stabilizing a single package really is an impactful change. >>> The fact

Re: [gentoo-dev] [RFC] Allow SLOT documentation in metadata.xml

On 10/18/2015 08:21 PM, Alexis Ballier wrote: > > > btw, once this is committed, please consider adding or asking for a > repoman warning when subslot is defined but metadata.xml is not filled > Almost forgot: it has been committed yesterday:

Re: [gentoo-dev] stabilization commits and atomicity

On 10/19/2015 07:08 PM, Rich Freeman wrote: > On Mon, Oct 19, 2015 at 11:27 AM, Ian Stakenvicius wrote: >> >> Ahh, so what you're referring to here is stabilization of multiple >> unrelated packages in a single commit.. ok.. i'm not so >> comfortable with that idea.. > > Nor

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/intelhex/

On 10/20/2015 04:02 PM, Mike Frysinger wrote: > commit: a68f2479fba9422913cb760166316bf489d72ca8 > Author: Vincent Palatin chromium org> > AuthorDate: Tue Oct 20 14:01:34 2015 + > Commit: Mike Frysinger gentoo org> > CommitDate: Tue Oct 20 14:01:50 2015 + > URL:

Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

On 10/18/2015 01:43 PM, Rich Freeman wrote: > On Sun, Oct 18, 2015 at 7:37 AM, hasufell <hasuf...@gentoo.org> wrote: >> On 10/17/2015 08:03 PM, Ciaran McCreesh wrote: >>> On Sat, 17 Oct 2015 14:49:36 +0200 >>> hasufell <hasuf...@gentoo.org> wrote: >

Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

On 10/17/2015 08:03 PM, Ciaran McCreesh wrote: > On Sat, 17 Oct 2015 14:49:36 +0200 > hasufell <hasuf...@gentoo.org> wrote: >> You can apply the patches post_unpack or post_src_prepare witht hooks. >> What's the problem? > > Running autorecrap. > You

Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

On 10/17/2015 02:24 PM, Michał Górny wrote: > > 2. eapply_user really belongs in the PM, especially if it's run by > default. And it needs patch applying function. And if we have to > implement patch applying function anyway, we may as well make it public > to avoid unnecessary duplication. >

Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

On 10/17/2015 02:19 PM, Jason A. Donenfeld wrote: > > The other question is more critical -- could you merge eapply and > eapply_user? Or add some hook to PMS so that eapply_user isn't needed? > IOW, it'd be nice if every package was, by default, patchable by the user. > IMO, eapply_user should

Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

On 10/17/2015 02:38 PM, Rich Freeman wrote: > On Sat, Oct 17, 2015 at 8:25 AM, hasufell <hasuf...@gentoo.org> wrote: >> On 10/17/2015 02:19 PM, Jason A. Donenfeld wrote: >>> >>> The other question is more critical -- could you merge eapply and >>&g

Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

On 10/17/2015 02:52 PM, Ulrich Mueller wrote: >>>>>> On Sat, 17 Oct 2015, hasufell wrote: > >>> 2. eapply_user really belongs in the PM, especially if it's run by >>> default. And it needs patch applying function. And if we have to >>> implemen

Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

On 10/17/2015 02:56 PM, Rich Freeman wrote: > On Sat, Oct 17, 2015 at 8:49 AM, hasufell <hasuf...@gentoo.org> wrote: >> >>> The other feature that is supposed to be in EAPI6 (I didn't read the >>> draft yet) is that the PM should refuse to install the package

Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

On 10/17/2015 03:47 PM, Alexis Ballier wrote: > On Sat, 17 Oct 2015 14:49:36 +0200 > hasufell <hasuf...@gentoo.org> wrote: > > [...] >> You can apply the patches post_unpack or post_src_prepare witht hooks. >> What's the problem? > > autoreconf > Can you elaborate why this would be a problem?

Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

On 10/17/2015 03:07 PM, Ulrich Mueller wrote: >>>>>> On Sat, 17 Oct 2015, hasufell wrote: > >> And still doesn't give sufficient control to the user. Documenting >> proper hooks is more useful. > > Nothing prevents the PM from implementi

Re: [gentoo-dev] [RFC/announcement] Reviewers project

On 10/10/2015 05:34 PM, Alexis Ballier wrote: > > It is no secret that I don't care about "hats" :) > If someone is right, he's right, a QA hat doesn't make something wrong > magically right. Also, if you'd ask me, QA should be more about Quality > Assurance, meaning training people, writing

Re: [gentoo-dev] [RFC/announcement] Reviewers project

On 10/10/2015 04:27 PM, Alexis Ballier wrote: >> The side goal is to review current Gentoo commits for major QA >> violations and other issues, aiming at improving the quality of >> ebuilds in Gentoo and helping other developers using bash, ebuilds >> and git effectively. > > This is completely

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgit2/

On 10/10/2015 03:54 PM, Manuel Rüger wrote: > > Dear Julian, > > avoiding this mailing list for further reviews is great news. > Still, I'd like to opt-out from receiving any mails arising from project > "Reviewers". > If there are QA-related issues with packages, I maintain, please file a > bug

Re: [gentoo-dev] [RFC/announcement] Reviewers project

On 10/11/2015 09:52 AM, Ian Delaney wrote: > > To my observation the reaction to this has been between displeasure and > dismay. Yesterday the dev-ML was flooded with the first day's > publication of the members' reviews. Firstly the gentoo-commits ML to my > understanding is intended to be used

Re: [gentoo-dev] [RFC/announcement] Reviewers project

On 10/11/2015 09:19 AM, Sven Vermeulen wrote: > > This is good news. There are quite a few developers that manage a small > subset of packages while doing tremendous work for Gentoo within that > community. For instance, they focus on particular deliverables in > repositories which eventually get

Re: [gentoo-dev] [RFC/announcement] Reviewers project

On 10/12/2015 06:44 AM, wraeth wrote: > > I am aware of this and that it has been the way for quite > some time. However, while it may be the norm in the wider FOSS > community, it has not been the norm on the gentoo-dev list - certainly > people will post things specifically for review, or may

Re: [gentoo-dev] [RFC/announcement] Reviewers project

On 10/12/2015 06:56 AM, Matt Turner wrote: > > So work with the reviewers to ensure the communication is tactful and > graceful. > That would be appreciated. So far, we mostly got people complaining (and some setting up sieve filters to throw all our mails to trash), but not people offering

Re: [gentoo-dev] [RFC/announcement] Reviewers project

On 10/12/2015 04:12 PM, Ian Delaney wrote: > On Mon, 12 Oct 2015 15:47:19 +0200 > hasufell <hasuf...@gentoo.org> wrote: > >> On 10/12/2015 03:29 PM, Ian Delaney wrote: >>> >>> Not sure how to read this. The whole idea is for provider / client >>>

Re: [gentoo-dev] [RFC/announcement] Reviewers project

On 10/12/2015 03:51 PM, Rich Freeman wrote: > That's why I > suggested a top-5 list or something like that, which would have weeded > out false positives and focus more on resolutions and trends than > individual incidents. > https://wiki.gentoo.org/wiki/Project:Reviewers/Common_issues

Re: [gentoo-dev] [RFC/announcement] Reviewers project

On 10/12/2015 03:58 PM, wraeth wrote: > I don't expect everything to have been within the N^th degree of > perfection from day one; and I honestly hope the Reviewers project > finds its feet and benefits the community; I just believe that it's > first day could have been handled better. > We've

Re: [gentoo-dev] [RFC/announcement] Reviewers project

On 10/12/2015 03:41 PM, Alexis Ballier wrote: > > They might have failed to notify it, I did that 2 hours ago already on this thread. What does that tell us ;) but I think they've taken into > account most, if not all, of the problems that had been pointed out: >

Re: [gentoo-dev] [RFC/announcement] Reviewers project

On 10/12/2015 03:29 PM, Ian Delaney wrote: > > Not sure how to read this. The whole idea is for provider / client to > communicate and negotiate a workable solution. At a glance this reads > as the user needs to adapt to the service that the client is offering > and appease the provider. What's

Re: [gentoo-dev] [PATCH] metadata: add slots element

On 10/12/2015 07:49 PM, Alexis Ballier wrote: > On Mon, 12 Oct 2015 19:19:33 +0200 > Julian Ospald wrote: > >> There seems to be some general confusion about specific package SLOTs >> and their meaning, since there can be several naming schemes applied >> and documentation

Re: [gentoo-dev] [PATCH] metadata: add slots element

On 10/13/2015 09:51 AM, Alexis Ballier wrote: > > that would work too, but dtd provides standardization, and avoids > duplicating package-wide information (meaning of slot/subslot) in every > single ebuild. > Yeah, the only thing that I wasn't sure about is the subslots part. With the proposed

<    2   3   4   5   6   7   8   >