Re: [gentoo-dev] [RFC] New eclass: mate

2016-06-09 Thread Jason Zaman
On Thu, Jun 09, 2016 at 08:19:43AM -0400, NP-Hardass wrote:
> # Old EAPIs are banned.
> case "${EAPI:-0}" in
>   5|6) ;;
>   *) die "EAPI=${EAPI} is not supported" ;;
> esac

How reasonable would it be to ban EAPI5 as well? This is a new eclass so
it may be better to just take the time to go to EAPI6 directly and not
have to migrate 5->6 later on.


> # @FUNCTION: python_cond_func_wrap
> # @DESCRIPTION: Wraps a function for conditional python use, to run for each
> # python implementation in the build directory.
> python_cond_func_wrap() {
>   if use python; then
>   python_foreach_impl run_in_build_dir "$@"
>   else
>   $@
>   fi
> }

I dont see where you inherited the python eclasses? You also probably
need to use use_if_iuse (from eutils.eclass) instead since it seems like
python might not be in all the ebuilds. Afaik, you're not allowed to
call use foo if foo is not in IUSE already.

Also I'm not sure if having functions start with python_ could lead to
conflicts later on with the python eclasses?

Other than these minor things, look good!
-- Jason




Re: [gentoo-dev] [RFC] Global USE=gui

2016-06-09 Thread Ulrich Mueller
> On Thu, 9 Jun 2016, Michał Górny wrote:

>> That would be a policy violation. Packages should pick a reasonable
>> default if flags are conflicting, but not force users to
>> micro-manage their flags.

> Who did establish that *idiotic* policy and why is he still a
> developer?

Michał,
You may want to reconsider your tone.

The policy was established when documenting REQUIRED_USE for EAPI 4,
and it is based on consensus in bug 353624 [1] and in the gentoo-dev
mailing list [2,3].

Ulrich


[1] https://bugs.gentoo.org/show_bug.cgi?id=353624#c6
[2] http://thread.gmane.org/gmane.linux.gentoo.devel/69755/focus=69772
[3] http://thread.gmane.org/gmane.linux.gentoo.devel/69755/focus=69776


pgp6uX4iHcYK6.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Global USE=gui

2016-06-09 Thread Chí-Thanh Christopher Nguyễn

Michał Górny schrieb:



2. Packages use REQUIRED_USE to force an appropriate choice.


That would be a policy violation. Packages should pick a reasonable
default if flags are conflicting, but not force users to micro-manage
their flags.


Who did establish that *idiotic* policy and why is he still
a developer? The whole *point of USE Flags* is to let people
micro-manage stuff. Picking up a random default makes flags
meaningless, confusing and makes it impossible to establish
appropriate USE dependencies.


I assume "micro-manage" means users maintaining extensive lists of 
per-package flags in package.use, which I agree with ulm is to be avoided.


Setting the USE flags once in make.conf would not qualify as micro-managing 
in my opinion.


There is an exception though, in cases where this breaks reverse USE 
dependencies, it may be allowed and necessary to use REQUIRED_USE[0].



Best regards,
Chí-Thanh Christopher Nguyễn

[0] 
https://devmanual.gentoo.org/general-concepts/use-flags/index.html#conflicting-use-flags




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Global USE=gui

2016-06-09 Thread Michał Górny
On Thu, 9 Jun 2016 22:24:20 +0200
Ulrich Mueller  wrote:

> > On Thu, 9 Jun 2016, Michał Górny wrote:  
> 
> > That said, I think we could go with some generic idea like this
> > (assumes new GUI expand is being used):  
> 
> > [...]  
> 
> > 2. Packages use REQUIRED_USE to force an appropriate choice.  
> 
> That would be a policy violation. Packages should pick a reasonable
> default if flags are conflicting, but not force users to micro-manage
> their flags.

Who did establish that *idiotic* policy and why is he still
a developer? The whole *point of USE Flags* is to let people
micro-manage stuff. Picking up a random default makes flags
meaningless, confusing and makes it impossible to establish
appropriate USE dependencies.

-- 
Best regards,
Michał Górny



pgp4ajVRrfpAZ.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Global USE=gui

2016-06-09 Thread Ulrich Mueller
> On Thu, 9 Jun 2016, Michał Górny wrote:

> That said, I think we could go with some generic idea like this
> (assumes new GUI expand is being used):

> [...]

> 2. Packages use REQUIRED_USE to force an appropriate choice.

That would be a policy violation. Packages should pick a reasonable
default if flags are conflicting, but not force users to micro-manage
their flags.

Ulrich


pgpjoGPHAeN8Z.pgp
Description: PGP signature


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

2016-06-09 Thread Michał Górny
On Wed, 8 Jun 2016 15:16:57 +0200
Alexander Berntsen  wrote:

> It would be wise of us to create a novel way of involving users from
> the ashes of Sunrise.
> 
> Here is my suggestion: It would be fruitful to encourage every single
> Gentoo user to have their own repository. And this repository should
> be publicly available.
> 
> This way we can merge useful things from people, and they can submit
> pull-requests if they have useful things that are not in the tree.
> Before merging anything to the main tree, ebuilds should of course be
> carefully reviewed. Users could also review each other's ebuilds to
> ensure better quality ebuilds.

Didn't you just contradict yourself? First you tell that everyone
should have their own public repo... then you tell that we should merge
stuff from those repos. So are you targeting split-repo model, or
central repo model, or...?

> This could lead to a future where the Gentoo tree is largely
> superseded. Every user would just have their own repository, where
> they could pick and choose packages from other users. The Gentoo tree
> would just focus on a high-quality repository of the basic/core things
> that everybody needs. Gentoo devs would spend most of their time
> maintaining curated small and useful repositories.

Does that mean that using Gentoo would involve spending hours on
figuring out which repository supplies a package that happens to be
quite up-to-date, build and not have huge security issues? I know it's
Gentoo style but we so far focused on making Gentoo painful with a lot
of useless choices on USE flag level.

> While there is some work to be done to facilitate my suggestion, it
> should be a lot less work than Sunrise was. What we need short-term is
> simply documentation where we encourage users to have their own
> repositories that are available online. Next up would be setting
> Portage up to expect a user repository from the get go. The initial
> personal tree could be fork of the Gentoo tree with a remote 'gentoo'
> that they can pull from (emerge could do this automatically). This
> way, users who do not care at all, can just use Gentoo like they do
> today.

So... are we doing split repos, or now forking Gentoo and expecting
things to magically work when people attempt to merge a dozen outdated
forks of Gentoo?

> The final step is the most difficult (but then again we might never
> get so far). It is two-fold. First we make the core/base repository.
> Then we identify important subsets that can be logically separated
> into repositories, and do this.
> 
> Parallel to all this, we should work on tooling. It is unreasonable to
> expect people to be git experts to be effective. The workflows for
> managing user repositories doesn't need the full power of git anyway.
> It would also be good to offer hosting insofar as possible to a set of
> curated repositories we consider to be of high quality.
> 
> 
> In the end, Gentoo might make a gigantic leap into the future with a
> truly modular distribution. If anyone wants to look at distros that
> get this more right than Gentoo, have a look at e.g. NixOS and Exherbo.

NixOS doesn't work. It's a huge pile of hacks that create more problems
than they solve.

Exherbo is special. You can talk about everyone having their own
repository when you have to deal with around 10 users who also happen
to be developers. It doesn't scale to Gentoo.

> What are your thoughts?

I don't really see how this is relevant to Sunrise. Sunrise failed for
a few reasons, and one of them was that the pseudo-distributed model
that it attempted to establish didn't work. You are moving
in the opposite direction than most of the Sunrise contributors.

You have no real technical suggestions, or even a clear vision. I have
no clue how your idea is going to work, or if it's even a single idea.

-- 
Best regards,
Michał Górny



pgp4FdG0juBRI.pgp
Description: OpenPGP digital signature


[gentoo-dev] [PATCH] cmake-utils.eclass: do not pass CMAKE_INSTALL_DO_STRIP in EAPI 6 and later

2016-06-09 Thread Michael Palimaka
CMAKE_INSTALL_DO_STRIP does not appear to be widely used, so this is a good
opportunity to get rid of it.
---
 eclass/cmake-utils.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 02b06bb..bfd3581 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -628,7 +628,7 @@ enable_cmake-utils_src_configure() {
-DCMAKE_INSTALL_PREFIX="${EPREFIX}${PREFIX}"
"${mycmakeargs_local[@]}"
-DCMAKE_BUILD_TYPE="${CMAKE_BUILD_TYPE}"
-   -DCMAKE_INSTALL_DO_STRIP=OFF
+   $([[ ${EAPI} == [2345] ]] && echo -DCMAKE_INSTALL_DO_STRIP=OFF)
-DCMAKE_USER_MAKE_RULES_OVERRIDE="${build_rules}"
-DCMAKE_TOOLCHAIN_FILE="${toolchain_file}"
"${MYCMAKEARGS}"
-- 
2.7.3




Re: [gentoo-dev] [RFC] Global USE=gui

2016-06-09 Thread Michał Górny
On Tue, 7 Jun 2016 12:03:16 -0700
Brian Dolbec  wrote:

> We instead implement something along the lines of:
> 
> an ordered list of the gui toolkits in their preferred order of
> desirability.  This should be an all inclusive list.  Note: these are
> subject to package.use setting overrides.
> 
> PREFERRED_GUIS="gtk2 qt4 qt5 x wxwidgets X ... ncurses tty -gkt3"
> 
> In the above it means that if gtk2 is an option, then choose it, mask
> (de-select) the others.
> In there it also means DO NOT SELECT gtk3  So if you want a pkg and
> it NEEDS gtk3, then the PM will puke it back at you saying you can't
> have one without the other...
> So, then you have to fix it manually via package.use settings.  Accept
> gtk3 for this pkg only (not that it doesn't likely have other gtk3
> deps that will also need this...)
> 
> In the general case it will pick the first toolkit in order of
> preference (left to right) and only that toolkit that the pkg is capable
> of using.
> 
> For pkgs capable of multiple simultaneous toolkits installed, then
> again, manual intervention would be needed to set package.use.
> 
> This would also have to be a package manager feature and run similar to
> the auto-unmask feature.
> 
> FEATURES="preferred-guis"
> 
> Let's try and keep things as simple as possible.
> From what I've gleaned form the emails I have read, is that what the
> general user wants to happen, select the toolkit in the order of their
> preference.

Could we please try to stay generic and not invent specific ugly hacks
for specific hardcoded flag names? We're trying hard to kill those
things, and I'd really feel bad if Portage got more of them.


That said, I think we could go with some generic idea like this
(assumes new GUI expand is being used):

1. Packages use IUSE defaults to set the preferred GUI:

  IUSE="gui_gtk2 +gui_gtk3 ..."

2. Packages use REQUIRED_USE to force an appropriate choice.

3. The default is GUI="", and users who don't care get the choice taken
by IUSE defaults.

4. For those who care, we implement one of the two mechanisms. Either:

a. flag preference lists -- i.e. something like '|| ( gtk3 gtk2 ... )'
in package.use,

b. or flag 'toggling' notes -- like 'gtk3 -gtk2~ -qt5~~ ...'.

Both solutions provide directions for the PM in case REQUIRED_USE
constraints fail.


I think the preference lists are more obvious. For example:

  */* GUI: || ( gtk3 gtk2 )

would mean that by default GUI=gtk3. However, if a package fails to
meet REQUIRED_USE, it is retried with GUI=gtk2. If that one fails as
well, user is asked to take action.

The main problem I see with this, is how to combine multiple
package.use entries (i.e. the global flags with local flags).


The 'toggling' notes are a little more complex. Basically, the idea is
that '~' indicator means that the flag can be toggled in order to
attempt to solve REQUIRED_USE. The more '~'s, the less preferred
toggling is. For example:

  */* GUI: gtk3 qt5~ -gtk2~~

means that:

a) gtk3 is always ON, and can't be toggled (however, it may not be
in IUSE),

b) qt5 is ON by default but can be toggled off if REQUIRED_USE conflict
occurs,

c) gtk2 is OFF by default but can be toggled on (as second attempt) if
REQUIRED_USE fails.

Basically the idea is that PM tries the default set first, then
attempts to toggle flags with '~', then with '~~', then possibly '~' +
'~~'...

In this case, the idea would be that the user prefers having both gtk3
and qt5. But if that's impossible, he prefers gtk3 only. if that's
impossible, PM should try 'gtk3 qt5 gtk2', then 'gtk3 gtk2'... And if
all '~'s don't help, REQUIRED_USE is left for user invention.

-- 
Best regards,
Michał Górny



pgp6_zPgu1PxE.pgp
Description: OpenPGP digital signature


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

2016-06-09 Thread Duncan
Daniel Campbell posted on Wed, 08 Jun 2016 22:03:51 -0700 as excerpted:

> I'm not sure what the problem with IRC is. In the context of your
> quizzes, it's important that the interviews take place in real-time. It
> allows a quick method of communication. It's informal, aims to be
> friendly and helpful, and tests your ability to find answers on your own
> in a somewhat quicker fashion. Even if you, as a dev, have little
> interest in IRC or helping out in the #gentoo channel, the interview
> process is valuable and will help you get faster at finding answers.

... For people who work that way.

Which becomes a problem for people who don't.

Not speaking for James, but addressing this more general point from my 
own perspective... since long ago I realized IM/IRC don't present the 
best side of me, and attempting to use them in stressful situations such 
as job interviews (even for volunteer jobs such as here) isn't likely to 
result in anything but disaster.

Which is a shame in some ways, as I've seen generations of devs come and 
go in my dozen years using gentoo, and I expect I'll see generations more 
come and go in the coming dozen, as I don't anticipate leaving gentoo 
behind any time soon.  But I've found other ways to contribute, both to 
gentoo and to the larger community, and am comfortable now in the niche 
and role I've created for myself, so perhaps it's for the better.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




[gentoo-dev] Last rites: sys-apps/dmtcp

2016-06-09 Thread Michael Palimaka
# Michael Palimaka  (9 Jun 2016)
# Fails to build. Unmaintained. Masked for removal in 30 days.
# Bug 574174.
sys-apps/dmtcp



[gentoo-dev] Last rites: media-gfx/fbv

2016-06-09 Thread Michael Palimaka
# Michael Palimaka  (9 Jun 2016)
# Fails to build with newer giflib. Unmaintained. Dead upstream.
# Use media-gfx/fbida instead.
# Masked for removal in 30 days. Bug 571686.
media-gfx/fbv



[gentoo-dev] Last rites: media-gfx/wings

2016-06-09 Thread Michael Palimaka
# Michael Palimaka  (9 Jun 2016)
# Fails to build. Unmaintained. Masked for removal in 30 days.
# Bug 574756
media-gfx/wings



[gentoo-dev] Last rites: app-i18n/xsim

2016-06-09 Thread Michael Palimaka
# Michael Palimaka  (9 Jun 2016)
# Fails to build. Dead upstream. Masked for removal in 30 days.
# Bug 575374.
app-i18n/xsim



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

2016-06-09 Thread Dirkjan Ochtman
On Thu, Jun 9, 2016 at 12:22 PM, Alexander Berntsen  wrote:
> If you mean that we should go with what is currently popular, then
> that would be Microsoft Windows, Mac OS X, and to a lesser degree
> Ubuntu. But I'm not sure what that mental exercise affords us. I am
> more concerned with how we can make Gentoo better, and how we can grow
> and evolve as a distro. I don't think Gentoo as it exists today will
> continue to be a success in 2025. From a user POV I already think that
> Gentoo is likely not the best distro choice for me. But instead of
> immediately abandoning ship like other developers have, I want Gentoo
> to improve.

If you think Exherbo is better for you, then you should probably
use/work on Exherbo instead.

I would tend to agree with those who have written that coordinating
work across repos is kind of a pain. The way we're currently setup,
with a largish active "core" repository and lots of little satellites
seems to work pretty well. We should always invest in ways to make it
easier to contribute work, and to become a dev, and I would not be
opposed to integrating layman/repositories.xml a bit more, but I don't
think your stated goal of totally decentralizing our ebuild tree will
make Gentoo better.

Cheers,

Dirkjan



Re: [gentoo-dev] [RFC] New eclass: mate

2016-06-09 Thread NP-Hardass
Greetings all,

Sorry for the delay, had lots of recurrent hardware issues the last
month or so.
I will be adding this to the MATE project repo after I get your
feedback, and then into Gentoo repo after I've had some users test out
the new packages/eclass.

Just a reminder/summary:
There are 40-50 ebuilds in the MATE desktop environment, with a fair bit
of overlap in the ebuild code, so I thought it best to create an eclass
to handle that.  MATE is a fork of GNOME 2 so I used the gnome.org
eclass as a reference for the mate-desktop.org eclass.  Additionally,
there is much in MATE that is still very much in line with the gnome2
eclass.  Rather than having to edit 40-50 ebuilds if we become
divergent, I thought it more purdent to just create a separete mate_*
namespace. For functions that are currently equivalent, my phase
functions are stubs to the gnome2 phase functions.


Thanks for taking the time to look these over and give your feedback.
(Also, apologies for the thrown together email, I was having trouble
getting git-send working to the mailing list)

--
NP-Hardass

###
mate-desktop.org.eclass
###


# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

# @ECLASS: mate-desktop.org.eclass
# @MAINTAINER:
# m...@gentoo.org
# @AUTHOR:
# Authors: NP-Hardass  based upon the gnome.org
eclass.
# @BLURB: Helper eclass for mate-desktop.org hosted archives
# @DESCRIPTION:
# Provide a default SRC_URI and EGIT_REPO_URI for MATE packages as well as
# exporting some useful values like the MATE_BRANCH

# Old EAPIs are banned.
case "${EAPI:-0}" in
5|6) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

if [[ ${PV} ==  ]]; then
inherit git-r3
else
inherit versionator
fi

# Ensure availibility of xz-utils on old EAPIs
if [[ "${EAPI:-0}" -lt "6" ]]; then
DEPEND="app-arch/xz-utils"
fi

# @ECLASS-VARIABLE: MATE_TARBALL_SUFFIX
# @INTERNAL
# @DESCRIPTION:
# All projects hosted on mate-desktop.org provide tarballs as tar.xz.
# Undefined in live ebuilds.
[[ ${PV} !=  ]] && : ${MATE_TARBALL_SUFFIX:="xz"}

# @ECLASS-VARIABLE: MATE_DESKTOP_ORG_PN
# @DESCRIPTION:
# Name of the package as hosted on mate-desktop.org.
# Leave unset if package name matches PN.
: ${MATE_DESKTOP_ORG_PN:=$PN}

# @ECLASS-VARIABLE: MATE_DESKTOP_ORG_PV
# @DESCRIPTION:
# Package version string as listed on mate-desktop.org.
# Leave unset if package version string matches PV.
: ${MATE_DESKTOP_ORG_PV:=$PV}

# @ECLASS-VARIABLE: MATE_BRANCH
# @DESCRIPTION:
# Major and minor numbers of the version number, unless live.
# If live ebuild, will be set to ''.
if [[ ${PV} ==  ]]; then
: ${MATE_BRANCH:=}
else
: ${MATE_BRANCH:=$(get_version_component_range 1-2)}
fi

# Set SRC_URI or EGIT_REPO_URI based on whether live
if [[ ${PV} ==  ]]; then
EGIT_REPO_URI="
https://github.com/mate-desktop/${MATE_DESKTOP_ORG_PN}.git
git://github.com/mate-desktop/${MATE_DESKTOP_ORG_PN}.git
http://github.com/mate-desktop/${MATE_DESKTOP_ORG_PN}.git
"
SRC_URI=""
else

SRC_URI="http://pub.mate-desktop.org/releases/${MATE_BRANCH}/${MATE_DESKTOP_ORG_PN}-${MATE_DESKTOP_ORG_PV}.tar.${MATE_TARBALL_SUFFIX};
fi

# Set HOMEPAGE for all ebuilds
HOMEPAGE="http://mate-desktop.org;

# Set default SLOT for all ebuilds
SLOT="0"


###
mate.eclass
###


# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

# @ECLASS: mate.eclass
# @MAINTAINER:
# m...@gentoo.org
# @AUTHOR:
# Authors: NP-Hardass  based upon the gnome2
# and autotools-utils eclasses
# @BLURB: Provides phases for MATE based packages.
# @DESCRIPTION:
# Exports portage base functions used by ebuilds written for packages
using the
# MATE framework. Occassionally acts as a wrapper to gnome2 due to the
# fact that MATE is a GNOME fork. For additional functions, see
gnome2-utils.eclass.

# Check EAPI only
case "${EAPI:-0}" in
5|6) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

# Inherit happens below after declaration of GNOME2_LA_PUNT

# @ECLASS-VARIABLE: MATE_LA_PUNT
# @DESCRIPTION:
# Available values for MATE_LA_PUNT:
# - "no": will not clean any .la files
# - "yes": will run prune_libtool_files --modules
# - If it is not set, it will run prune_libtool_files
# MATE_LA_PUNT is a stub to GNOME2_LA_PUNT
GNOME2_LA_PUNT=${MATE_LA_PUNT:-""}

inherit gnome2 autotools mate-desktop.org

case "${EAPI:-0}" in
5|6)
EXPORT_FUNCTIONS src_prepare src_configure src_install 
pkg_preinst
pkg_postinst 

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

2016-06-09 Thread Rich Freeman
On Thu, Jun 9, 2016 at 6:22 AM, Alexander Berntsen  wrote:
>
> On 09/06/16 12:14, Johannes Huber wrote:
>> This statement is not feeded with numbers. Distrowatch tells
>> something else.
> I don't know what "feeded" means. Distrowatch is useless for anything
> but figuring out what distros are popular among people who actually
> still use distrowatch.
>

It isn't even useful for that.  It is only useful for figuring out
which distros that advertise themselves in USER_AGENT strings are
popular among people who actually still use distrowatch.

Gentoo doesn't tend to be big on self-promotion, so we probably don't
get a lot of credit for the traffic we do generate.

Here is my user agent right now:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/51.0.2704.63 Safari/537.36

Good luck figuring out what distro I'm on from that...

-- 
Rich



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

2016-06-09 Thread Igor Savlook

On 06/09/2016 12:38 PM, Alexander Berntsen wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/06/16 16:53, Consus wrote:

How all those people are expected to coordinate their work?

I don't want to control this. That's up to them. It works well in
Exherbo and NixOS. But I agree that tooling to support it would be
useful.

- --
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWTkuAAoJENQqWdRUGk8BGo0P/1Zu0ql2hEjeyLa4PAZcpSZX
Bkync3nf328qXZtghIR1BM/oBXc44LLV4bPctCAKCzvOTuf7O6u7GvEyqeRjqXHz
EK2V85/XsujiwUFwucb064IUxvg3xhuJvJorOt8PlgVu1JrER6ZgQao5cGo7DU6/
UDSsGBC09MjSnm7QJOmygMVYRETR/3WrG5P8fAAlS6YBYsn+3MLQFES/BH1TEVCk
YpF97XCtpFf+m/ryfXYgaf3PKX+yd5NrIv+jjLjAjudzgUOy6DzDrMXZqLcYVS2m
HtqnnENKsPBXRpq3M34BrCSeD3JWyS5n3VLHuwDTl4oGCiRKSA34d7qotiAWjlDe
r9+8kQv3kt0nlqBJ7gI6vIqm9QPEEkhPYQbbTf3pQlDVtPnrgdouFKrWlTNJTg0+
XbyDKZos2bz3Y7/HH3u2Ptz7YdE5Lv0TlE3p+nenBxjCCn58KzPCdo3aaASWpaUQ
cgazEBqipLp93W4imxDs+bXWVFDXSDb1zSB0Vr/J9R3eOo9bNHRGGsgGzpGUMwju
RB6vMAmTA/1WaNy2FBLpgPPToLyekun2mUYnLPIL+rJxrPHDWYltp0BNQDs8rWaT
kxVCjZHv8q7UynuTnLZaklXtKvB5Yb8gx2oxV9gzTr/JFEyogxvHYdI+0XM71uHH
x4KZKm2K77AzK8aNkb1N
=0cnT
-END PGP SIGNATURE-

Ok how coordinate? Example: I install packageA in exherbo from 
repository1 and packageA denend on packageB on repository2. Now packageB 
removed from repository2 and exherbo crash on install package or on 
rebuild world (epic fail).
Exherbo user need wait when return packageB or create new repository for 
this package.




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

2016-06-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/06/16 12:14, Johannes Huber wrote:
> This statement is not feeded with numbers. Distrowatch tells 
> something else.
I don't know what "feeded" means. Distrowatch is useless for anything
but figuring out what distros are popular among people who actually
still use distrowatch.

> Overcomplex mess. This doesn't work on distro level. User have 
> already decided which are the successful distros. Those with a 
> central main repo.
It works well in quite a few distros.

If you mean that we should go with what is currently popular, then
that would be Microsoft Windows, Mac OS X, and to a lesser degree
Ubuntu. But I'm not sure what that mental exercise affords us. I am
more concerned with how we can make Gentoo better, and how we can grow
and evolve as a distro. I don't think Gentoo as it exists today will
continue to be a success in 2025. From a user POV I already think that
Gentoo is likely not the best distro choice for me. But instead of
immediately abandoning ship like other developers have, I want Gentoo
to improve.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWUNUAAoJENQqWdRUGk8BQNkP/2pBzcimg9m5K2hQrKizxtf3
x7OFIW1lGt17e2ZjKFfwnQwB73Ek4WosjXociReMHo/B//CxtnQbeg0QYbp0uXi+
Je3eZsp89xzWgHzJo2mNMBR4IJ7I6vH+8V+9VF74AKuLGza5WaXenfBvq4c/uPoC
1XrRSCfhJPmmkuONokoHng/0LXMJtpS8ySDA2yDyh+nNVLEnGsUHWXdceRuNPpG1
mv/z1b/ElKSNkWnKUJfxFnY8EgDecxKo+1qRechJX3cjCKWSrxciahx0K0JNrur3
86T3c0WkEG3iODYt7b/VMdAVQ2LTUCU6NQEKsbOr14uyK3w9CFUlgouabWI/fna8
drDbGX2r6QyLeMdVa1seGrGqIHvGwPg8usYHS8yCTyBhvHGGtx5ONuJg1Qb8FZdr
65uSGtur/Ar3XipoCxbgr1IkfQH2w2b+OmJBaqnezbOB3u/mTrFASwhU3FJnVhz/
VIwmQTHQ6H3cl0MZRmgscrnlLMT4nhkJygEZVikVtUOR2bUchXeQEgd1uW3IEbx9
MGVKsnA5AaNj03UgAHjdcJKsP9lFlDYskbPtet1hTXepB9Q9q8xl6UGCadjLhHpd
jM5tMYa9Tz/wkypmsfM9OEIC7vheKQxTZYe0zY0zlhJ241jZmvekNLb2dIF80Lue
kLnLtr8skyMaQh2wXDLs
=E/QI
-END PGP SIGNATURE-



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

2016-06-09 Thread Rich Freeman
On Thu, Jun 9, 2016 at 5:41 AM, Alexander Berntsen  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 08/06/16 16:53, Rich Freeman wrote:
>> Do you propose that you can have cross-repo dependencies?
> Sure. This works well in Exherbo using Paludis. We could do it right now
> if we wanted to.
>
>> If so that creates a lot of potential issues, even if you do it
>> the NixOS way.
> You should tell Exherbo and NixOS about all these issues that they
> should be having but aren't having.
>

Perhaps you could explain how they actually prevent the issues I
brought up?  Since you didn't actually quote them I'll do so:

Suppose you have 10 packages, and they each depend on zlib from a
different repository?  If they collide, that is one problem to solve.
If they don't collide then you have 10 copies of zlib now, and good
luck making sure they're all secure, and of course now you're
multiplying the number of "shared" objects you keep in RAM.

How is this prevented in your proposal?  Do we just accept that the
typical user might have multiple copies of a library installed, with
no guarantees that they're free of security issues?

Keep in mind that this isn't the sort of issue that might be obvious
to an end user.  The average windows user probably has 14 versions of
many common DLLs installed all from random sources and probably has a
bunch of random ones with security issues (including zlib).  The
software all works, because the versions don't collide and the user
doesn't realize that they are wasting RAM and are vulnerable.  So, it
would be pretty easy to say that the windows approach "just works."

Maybe they have found some way to prevent issues like these, but the
conversation would move forward if this were actually explained,
rather than just dismissing concerns.

-- 
Rich



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

2016-06-09 Thread Johannes Huber
Am Mittwoch 08 Juni 2016, 15:16:57 schrieb Alexander Berntsen:
> In the end, Gentoo might make a gigantic leap into the future with a
> truly modular distribution. If anyone wants to look at distros that
> get this more right than Gentoo, have a look at e.g. NixOS and Exherbo.

This statement is not feeded with numbers. Distrowatch tells something else.

> What are your thoughts?

Overcomplex mess. This doesn't work on distro level. User have already decided 
which are the successful distros. Those with a central main repo. 




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

2016-06-09 Thread M. J. Everitt
On 09/06/16 10:58, Alexander Berntsen wrote:
> On 09/06/16 11:55, Daniel Campbell wrote:
> > According to Enigmail, it expired April 19th.
> I suggest you refresh your keys. My signing subkey was signed April
> 20th and expires in 2017.
>
Indeed, cache error, thanks. All square now.

MJE




signature.asc
Description: OpenPGP digital signature


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

2016-06-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/06/16 11:55, Daniel Campbell wrote:
> According to Enigmail, it expired April 19th.
I suggest you refresh your keys. My signing subkey was signed April
20th and expires in 2017.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWT20AAoJENQqWdRUGk8BWtIQALacIfky93hrYbBjcpGm15G4
LgVbG88B0V+DSJtw1e25wIXFb86Su1a2GEL1rdCl8zp79kvMDny+cheupu+JlFwv
szSM8fbyLE3NmFTj8pJkwSRmsvqVtWuXzyUk8bnfpoT+4SwYvf9bGMDf1FOFFGb9
q+Bfc0eMEiPi1krrSB9tp9yD5h7+CbN6l3x6uAS2yVqrclFosKh4YI1c2rfKZSBD
YGvcE2WqTjEUB00wZQbiYvdm3WtFeP1MFOsbd6kAb2Gfhl3l1hxKKtGbk0XTUlEq
XoDf9D0jDzAAXSMxsa7KMuhGGGTapcU4+ZAhxKL9Cl4Yh3qbim30W1kIOHVu/2fR
oWyB6WBc5lHStzRFGlg5UhFD2jyHxNpo4+VO57xoMn/dShbcyRPf41ZlsymGqH2h
/PI70+LXrALSrLMeZJ0178I7lRahPF2tcmh5ujXOWj++Y2qjVFRaeH1gAAh330Ye
ZgIcB1dZOUf79TJwmM+vNheUH6ix9pVoX2A8UC1ZGKJFD3w89mvM3+lR2kBysIp+
XdfFt/N3oTGttVKnPDqvXfAA8Ce/WUH7CpPH63oBJRxOhPsmJApen2j1heJ8ynjz
WFDXfpstxkCp1f6dNp+KGnfUms8DRPQx0plTYx/s4v7QcirGaVKQxi/0xJ/ysfsn
6fBFVtrLIEUGQ2Ly0PL2
=aAbh
-END PGP SIGNATURE-



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

2016-06-09 Thread Daniel Campbell
On 06/09/2016 02:53 AM, M. J. Everitt wrote:
> On 09/06/16 10:48, Alexander Berntsen wrote:
>> On 09/06/16 11:45, M. J. Everitt wrote:
>> > Btw, your key is showing up as expired, Alex.
>> It doesn't expire until next year.
>>
>>
> 
> I'll blame it on Enigmail, but this is the information I'm seeing:
> 
> "EXPIRED KEY Good signature from "Alexander Berntsen 
> Key ID: 0x705073B5 / Signed on: 09/06/16 10:48"
It's his signing subkey that's expired: 0x541A4F01

According to Enigmail, it expired April 19th.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


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

2016-06-09 Thread M. J. Everitt
On 09/06/16 10:48, Alexander Berntsen wrote:
> On 09/06/16 11:45, M. J. Everitt wrote:
> > Btw, your key is showing up as expired, Alex.
> It doesn't expire until next year.
>
>

I'll blame it on Enigmail, but this is the information I'm seeing:

"EXPIRED KEY Good signature from "Alexander Berntsen 
Key ID: 0x705073B5 / Signed on: 09/06/16 10:48"


signature.asc
Description: OpenPGP digital signature


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

2016-06-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/06/16 11:45, M. J. Everitt wrote:
> Btw, your key is showing up as expired, Alex.
It doesn't expire until next year.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWTtdAAoJENQqWdRUGk8Bl9cQALN5ngYXFjHv4sU9VZiOzMlI
9ysiZhCDWdBJuyJlxIejYo/wMnDiKZZJextwEKEAmyd5hEjmgv0pIcWCgPAyoc8y
tsr2ztcuFYdG1TqlZ8XcPc0KmeJMXXECkrI+m20+i+Rx/bu4OnKnNf0i95EJ3s44
MfGRQuBGwPzABOuR33A1JvIdyvQ2Qlv3orpqI8va9OW48jNiLmRjpiD0Rg90bjMk
Ew9nZOkG5ADAMPboURCyN0Y2cLMBbISgdWsy4gUzNDFdgvf2btIwWO8g9Seb7JB5
be0oFJ9J43rL2MQ1QMdOkeIoOSltJhoEEGxGVVWtnQtuS+SGWuU2j+Lwq56jJTNN
qqIM8H12tuEmltQ446tdLIlC0ObV2q0mnVKi079JDN/NwqH26gCiq601MFncv5Md
GUTu45YwuhhxfckAdVZKXjytzPXTtBmnKXkr6hLFUWE84OOjjMs1G/YTuRFm2yF8
btH8M8SG0XxQndEretqM85nZEsDfxrDo1uL5Z+4B4HWrMudOGV9+WzAywLddhnjh
+2F4YKWxiiANEn5saeHoLA90ossDc7QYzTwg9PDQUxGPvWVNViUyNEIXll0wExH2
N+xCWgAk9DpGG78C59diK6MCHdt75bn0PHeYizgA+xVlTuG96kFi7LjO7e7vrywS
tzhpcDzD/o7ufDh0kaHr
=vE+S
-END PGP SIGNATURE-



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

2016-06-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/06/16 01:08, Andreas K. Huettel wrote:
> Sigh. Every 2 years somebody else comes up with the same silly
> idea.
I stopped reading your email after this sentence.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWTq/AAoJENQqWdRUGk8BlpYP/3dt+jPnIFwW0WKoqLLDzQNr
l8qWQZZ3IYzuBV0AUtkDY+Skit7L/mbFOkNNYpwPKeDzfD3YL0G9ajdtC0HLP5Ii
WfplFd62qBB5A3xaw5sCL3Dta2SB6I9mRiLA0E1WfxoM1sq5vxgQXYIdacWPV1/d
QrSPvUqjQN//cRjWFWAASzQpMp4VwQ6fpKOsDqDdIrk7bHwPGitRVUTghZKjXKfW
rNyktONBjKf1Gt7eD7Wuog4sWFm3f02olBKbr5GTIkxWYAF5Q7jmLCuyvqIQYtcp
E1sUiHA+48+lRS+iTCdPuAMmXfeNE3T6pUKAZO6Cv77bSwmzQzQ98+uImZyfbFi7
CLQGOxsJz6p24GGI66Qfgbe2trBUMxM8ozBtrdtg+3Pl8CZqE87Lfhr+CK6rWB66
DzZojr1JIQy/YVjC1m/xo/97Uc4DcXp7BDjliCH6PkdjEsS8ySnqr1X/4eJ+3iRm
8GXWD2vL/sBkGTMg2ZP6yw3CHEmmi7N0lU/O0qPq3BTM9RVffZjxaRc39ysoj0QU
Rfur4Y8ObAqx2UV/RoRMSd+U4uWPaB1Km/mVRFMeRCLDq5L7ZKp692qwFCX8dBZy
9sVfGlIaoI1IMIdSgL2Nx8nxq3jfmDr/m7Q2HllWPpEodrdiwCns4/azf2jIpupg
p8gTq794oVzQw1O/2RDn
=gDDu
-END PGP SIGNATURE-



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

2016-06-09 Thread M. J. Everitt
On 09/06/16 10:37, Alexander Berntsen wrote:
> On 08/06/16 16:39, Zac Medico wrote:
> > The first obstacle that comes to my mind is how to discover the
> > packages. There needs to be a central index of repositories which
> > includes searchable metadata for all of the packages provided by
> > those repositories. It will be something like gpo.zugaina.org, with
> > the ability to download the whole database, and update the local
> > copy incrementally.
> This falls under the tooling side of things, and I agree that it is
> very useful.
>
We should be thinking about bringing the gpo.zugaina.org under the
Gentoo umbrella .. it -is- a *very* useful resource, and should belong
with the main sites, perhaps with a refactorage of the 'overlays.g.o' site?!

Btw, your key is showing up as expired, Alex.





signature.asc
Description: OpenPGP digital signature


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

2016-06-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/06/16 18:15, Peter Stuge wrote:
> Do NOT - I repeat NOT - tie "user repos" to GitHub Inc.
If I were in charge or to be involved, I would not even dream about
tying users to a proprietary SaaS. That would be highly unethical in
my view.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWTqSAAoJENQqWdRUGk8Bm24P/j3H/32R5MPk0namYpXdBPU7
aqiCLMoQGMNDHLSXlN7e4UfseE5HdwDIyeZmdUGPeCB6cRI3b0K5I0nmOVQJiuND
rvrX86h+gBGbzbQFKNP19TYq5qMusfJylUvidOBkstz0fTQrIIcOioAJ5AYlhcFB
2ypdlZdqCQm2IvjjCdRMOiMEAMl4TfNEhIiic5yvCCe9U6gsOyUhjIGSu8Ul3Fru
IFl8M8D+9S4eOARIVC0ciutUJQBrqVdxAytA3x04qdxRRuCGr8DcPG8EYVvRK3Vw
ozydEBNJtZIkhiJpB0Kqw6e2I5yJpmjfJ0c6boLNGAxCP5IboE11D2QzGq6o+iNf
IxHyAhldKfxF2ZOLKBfivuwgAHG12oJzMHaTgGMuq0nMSW9M5tINvV5ftw3UqVMj
0pS3Hx2styOhZjuH9qtrlCZsD5fbJt4sma+fkOP3uCBgYY6Y2KEZ8vIXMkgTro5H
qFzRNTbbQkp/P8s9Vz3JO5vk1HeMImy4oypFbJ1fyzqim0pK0CvxNi9hgqTTe2Sb
elBaYd3u0vbw42OGbqNuH7ciiNN248dFUc0XME4S4S6ETHdT2e1rraT+gjTJ5UQT
ca4lkfS4ApRDCSptgAkeQ+RKtsaM2aWJgSwFTW1HXBcr7r+BCQYHTAWRjOZ9MGR9
/c9M5xEZHSxiKxpMfRif
=Ie70
-END PGP SIGNATURE-



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

2016-06-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/06/16 17:53, james wrote:
>> DEAL?
No thanks.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWTpTAAoJENQqWdRUGk8BPAsQAM1vjeh7AzBx8yVGHcZ0U+vJ
RNoIDrF05PLGAVTqbtMniVNv/jcAwaAk1S2WZGpqaUHnQpWgo+1/Pc9p3HEg6UGf
/tq7uSihJk3dwimSjowzzC9JOu+sJT5d3yc0NPdypxgbuJ0DcPQLXVCCEC/dg1Oi
Anol5S7FR0C6bZFQtQ241MnpEe7pwZT8xEGzhHYC+PaL4bWk5pNcNzArP3VEEhP6
q40tMWsESueulxalagxb3vAb+/Ngi2Y06Jzx213ge9uA4d0Q6Hk0uv7EbTGPmHZ5
RVaf96MFcuyqU9SwjOLhaoz84uYnPaCTPRDT5eTomK2Ls5U1Xghkm8bSrH2hwbeU
EGngSDy+Bf2kPGV1VXCvB7yBrIbPzolDcAkDl51kfJKPtE4IlQb5wJP991Vm8h4n
0cOS5LX+BGvOED2UKLWq8Mr1nf/nQFCmLss4+MFE69/9UenC1LqQmCIT4o809d1C
WLHJLk1+qHNVNTdeOW0Af6hcZ04F8Bci+ALCShhMEiQ8ioTFFdWaFdGpNUsDb7qw
Yx4D78TEggV4qxHUrl/zvKKw6x1zvbzoberBcvzVErV7CPKGtUzRHH/oPmX09drh
8C0sVYVROdVMOGfe5zgEefV9UDdkDqQHxwi9JeOgzQI/PoL3jAYJiwENIGNdG2jv
MGN1PSZvXyzuiCOrtxQ4
=RA10
-END PGP SIGNATURE-



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

2016-06-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/06/16 16:53, Rich Freeman wrote:
> Do you propose that you can have cross-repo dependencies?
Sure. This works well in Exherbo using Paludis. We could do it right now
if we wanted to.

> If so that creates a lot of potential issues, even if you do it
> the NixOS way.
You should tell Exherbo and NixOS about all these issues that they
should be having but aren't having.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWTnZAAoJENQqWdRUGk8BGoAQAMmRKgmeRFN1wSfNIF7JUAqu
H23vd/MR1IJ5s3IPwzgo0zJTpHMJFatyCCJnYqNKcse+lS13w584gWI2ukLLh7iW
zgeN8ngXcQ0U07Bn1fdO6PXGWHEL9+bUm2QKuGOIIDxdkhMlb/uJz3sDK4+uaqqE
nBBxwUJT2YofBmALqt0l5VJeJBhV1HkRhfC/pBoKM1rvAjWTsiKH98xQC4TQ6Qr5
bV/cNDvSn8sw3kqNOHNJ9EulcRg0mycJAAdVrrlUTlHWB4r1YlWfBC8bT86cxJ+7
DeDE8rSyAY2MJ4s5TV00KzJqgTv/16C9xoZEiIfXjYe7MKuh5EWGbJZGp/rlMPis
B2g2bjSGxdaWWSJBS597KfuPqTqnsfekxvccQCSXaXBhDa1mXIPNW5jDwRQgOsd3
P88GDzF2SZyT9CzSipgf9m5olhg0kA5YFT+RbkvP98ZpYrVzmuO/lXkxyQIUQGxm
C/zGrPbnydaJFYIlE051dKjvdCdRU9HAoRFV6/8AWTio7aOILGWjTJx/nGrkUHdh
pmyDrMP/lnlDJwyS/kyoou2hw8v0w7dh3ges12VF4GqxlLF6hbBE7areXjVKyX+X
VhRKEm0cBVp3KSEv5jRpa4w7qzqnttXHVf7r4Q0T9/Ic01n/oP0p+UIrymScQ2JH
SpmugNyiZCPv2uM70IBz
=GcTt
-END PGP SIGNATURE-



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

2016-06-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/06/16 16:53, Consus wrote:
> How all those people are expected to coordinate their work?
I don't want to control this. That's up to them. It works well in
Exherbo and NixOS. But I agree that tooling to support it would be
useful.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWTkuAAoJENQqWdRUGk8BGo0P/1Zu0ql2hEjeyLa4PAZcpSZX
Bkync3nf328qXZtghIR1BM/oBXc44LLV4bPctCAKCzvOTuf7O6u7GvEyqeRjqXHz
EK2V85/XsujiwUFwucb064IUxvg3xhuJvJorOt8PlgVu1JrER6ZgQao5cGo7DU6/
UDSsGBC09MjSnm7QJOmygMVYRETR/3WrG5P8fAAlS6YBYsn+3MLQFES/BH1TEVCk
YpF97XCtpFf+m/ryfXYgaf3PKX+yd5NrIv+jjLjAjudzgUOy6DzDrMXZqLcYVS2m
HtqnnENKsPBXRpq3M34BrCSeD3JWyS5n3VLHuwDTl4oGCiRKSA34d7qotiAWjlDe
r9+8kQv3kt0nlqBJ7gI6vIqm9QPEEkhPYQbbTf3pQlDVtPnrgdouFKrWlTNJTg0+
XbyDKZos2bz3Y7/HH3u2Ptz7YdE5Lv0TlE3p+nenBxjCCn58KzPCdo3aaASWpaUQ
cgazEBqipLp93W4imxDs+bXWVFDXSDb1zSB0Vr/J9R3eOo9bNHRGGsgGzpGUMwju
RB6vMAmTA/1WaNy2FBLpgPPToLyekun2mUYnLPIL+rJxrPHDWYltp0BNQDs8rWaT
kxVCjZHv8q7UynuTnLZaklXtKvB5Yb8gx2oxV9gzTr/JFEyogxvHYdI+0XM71uHH
x4KZKm2K77AzK8aNkb1N
=0cnT
-END PGP SIGNATURE-



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

2016-06-09 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/06/16 16:39, Zac Medico wrote:
> The first obstacle that comes to my mind is how to discover the 
> packages. There needs to be a central index of repositories which 
> includes searchable metadata for all of the packages provided by
> those repositories. It will be something like gpo.zugaina.org, with
> the ability to download the whole database, and update the local
> copy incrementally.
This falls under the tooling side of things, and I agree that it is
very useful.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXWTjxAAoJENQqWdRUGk8BuEcP/iE76kp8HAqusjifU3h41IO6
z7EX6oNmkCTIUye/BqsiiaGQKoJazD2GzBUTrsAHtVuLib/ILea0Bu/K3wl8kOw2
T+2sDhmBKMabFmbtVnwgySsW1ZeQOj6518BELjfrYBSywC/TIU4706e6r3uzkrFi
xjVA+7EPcBz7NuyV6osh3yDB7mtsRgZTS5Pa3RWK7r6zwQedgcb1ExU+5qeDMrPw
aCzGM1EhdyGEJkrBdinJd6OsUo9MCUxf+Tt2Ndq6hy9wT3fz745x5xhHFpzhpoeC
Tq+Qm6/E+gLVAOu5Qd+33NHhPtEPQxCJ6lP0fhqavvOOCY3Sq13wdOKBxspXi0SI
sGgkQMbZxaDB99VhEEOWKxcb5kJif4FTxD4b30UpZwFWhKUrrXjPZ0/o7rPQWvt9
1me//ppEvgDd/1DkCA1H2EpbHHFclsW3R3I4QyGj2PyGhtGJ7WwLeUjHG+O5D1Nl
No49ASFKV9KPBUU5OqbvTn3EO7AIVQnK6nqxp5vCqEGmJUi4+ldYV5y34OxTudnQ
vZ3vE0+CwB42IAR23Hx7PdHv68l8vRigsaedcSV6UbraOnv2U3jxBAa2rPrpE5Ht
j/E+lD+wfS6f3l8qn5+jb3dKiTRK/6RmaMzETcy9ZOWc8SmwCspPOvu4mDVHoVFX
6/kewlpe4qcce/SXbAle
=UZKB
-END PGP SIGNATURE-



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

2016-06-09 Thread Daniel Campbell
On 06/08/2016 11:21 PM, Andrew Savchenko wrote:
> Hi!
> 
> On Wed, 8 Jun 2016 22:07:06 -0700 Daniel Campbell wrote:
> 
>> There are some of us against GitHub and/or other commercial outfits, so
>> that's not a problem. We offer some mirrors on GitHub, and some devs
>> host things on there, but it's nothing officially endorsed or otherwise
>> required by Gentoo.
>>
>> In fact I recently deleted my repos and account over the Code of Conduct
>> fiasco, but that's a whole 'nother topic. :P
> 
> Do you mean github's Code of Conduct? Looks like I missed some
> change there.
> 
> Best regards,
> Andrew Savchenko
> 
Yeah. It's unrelated to this thread, but GitHub's adopted the 'Open Code
of Conduct' by the TODO group or whatever. They had claimed it was
solely for their own projects, but there was some drama that came up
where they deleted peoples' repos, issues, and/or comments over that
same CoC. Often, it was enforced due to political or personal leanings
on sensitive subjects that didn't relate to the code at hand.

It may be better to discuss this over IRC or in private e-mail. The tldr
of it is they'd enforced their CoC despite it being nowhere in their
official Terms of Service. For some, that is a problem.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


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

2016-06-09 Thread Andrew Savchenko
Hi!

On Wed, 8 Jun 2016 22:07:06 -0700 Daniel Campbell wrote:

> There are some of us against GitHub and/or other commercial outfits, so
> that's not a problem. We offer some mirrors on GitHub, and some devs
> host things on there, but it's nothing officially endorsed or otherwise
> required by Gentoo.
> 
> In fact I recently deleted my repos and account over the Code of Conduct
> fiasco, but that's a whole 'nother topic. :P

Do you mean github's Code of Conduct? Looks like I missed some
change there.

Best regards,
Andrew Savchenko


pgpFCFhHwO6O4.pgp
Description: PGP signature