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

[konsolebox]

On Sat, Jun 11, 2016 at 3:00 PM, Michał Górny  wrote:
> On Sat, 11 Jun 2016 11:09:39 +0800
> konsolebox  wrote:
>
>> On Wed, Jun 8, 2016 at 11:53 PM, james  wrote:
>> > The grandiose-ness you propose should only come upon graduating from proxy 
>> > school, imho.
>> > user-->strong-users-->proxy-->dev pathway.
>>
>> Pedantic, bureaucratic, procedure-oriented, monolithic, restrictive.
>> Too conservative.
>>
>> What matters is the contribution, and the result.  If you don't like
>> how a user makes a contribution, don't accept the pull request, or
>> don't merge his package.  Simple.  If you think that could turn out to
>> be just a waste of time for them, help them correct their issues; add
>> some documentations to enlighten them and give warnings about wrong
>> practices so they don't blame anyone, and so they can decide whether
>> they would want to contribute or not given the rules presented; but,
>> _don't_ make the steps mandatory.  Don't make contributions
>> restrictive.
>
> You're contradicting yourself. How can improving/review of pull request
> be non-mandatory, if otherwise we are to reject it? Of course, it all
> depends on how you define 'mandatory'. It's not like anybody forces you
> to do something, you know.

No, you just misinterpret. You can review pull requests.  You can
reject stuff, but don't reject them just because some laid-out steps
in the documentation has not been followed.  Some may not be
completely necessary.  I'm implying that these "academic" steps may
not be completely helpful at all times, and making us follow these
things only make making a contribution stiff and restrictive.

I'm mainly referring to the strict user-->strong-users-->proxy-->dev
pathway that James is encouraging, where it seems like you have to
become a proxy developer first (or maybe, prove yourself first; gain
first some trust), before you are acknowledged to be able to
contribute in a manner that Alexander Berntsen has been suggesting.

These stuff imply unnecessary old-fashioned restrictions that aren't
"necessarily" helpful to security.  It doesn't help encourage users to
become active.

To make it clear, I'm mostly talking about users who would want to
contribute, but doesn't necessarily take pledge on the responsibility
of maintaining a package.  And isn't that what we are mostly talking
about?  If we also talk about maintenance-ship, don't we already have
the proxy maintainer for that position?

> Sure, it may seem like we expect people to fix all the tiny issues with
> pull requests but that's just a default profile we're assuming. Many of
> the people actually *want* to do that. If you don't, you can tell us
> straight ahead and we won't waste our time asking you to.
>
> I'm also unhappy when a pull request is left open for two weeks because
> we asked user to do a simple change, and he doesn't reply. I could've
> fixed it myself faster but then the user would lose his chance to do
> it. And the worst thing, I don't even know if he wants to!

There's nothing I say against that.

>> We do already allow people to send pull requests to
>> Gentoo portage's repo in Github, but it seems like they generally only
>> allow patches that fix current packages, not new features or new
>> packages.
>
> That's not true. The rules for pull requests are pretty much the same
> as for bugs.

That's great if that's really the case, but a more transparent, less
restrictive, and more dynamic system that could attract casual
contributors would be better.   Something like a web service where
their work would be officially indexed so everyone could easily find
it, not just the current developers of the current tree snapshot
they're trying to push their work to, who may reject it, if it was
intended to be pushed.  I gave the details about this in my other
e-mail.

-- 
konsolebox

[gentoo-dev] Re: RFC: kernel-2.eclass Prefix support

[Ulrich Mueller]

> On Sun, 12 Jun 2016, Benda Xu wrote:

> I have added EPREFIX logics for EAPI<3 and improved the trailing
> slashes and quotes.

> - [[ -f ${ROOT}/usr/include/linux/autoconf.h ]] \
> + [[ -f "${EROOT}"usr/include/linux/autoconf.h ]] \

Inside [[ ]] quotes are generally not needed. (There are several other
instances of this.)

> - mv ${WORKDIR}/linux* "${D}"/usr/src
> + mv ${WORKDIR}/linux* "${ED}"usr/src

It was like that before your patch, but still ${WORKDIR} should be
quoted here.

Ulrich


pgpyTSJOopnsB.pgp
Description: PGP signature

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

[M. J. Everitt]

On 12/06/16 04:53, james wrote:
>
> So I read this bug, but it did not illuminate an active archive, but the
> requests and subsequent problems encountered, or did i miss it? It
> looks  like the kinks are being worked out. PM having a ML is a great
> idea.
>
>
> Interesting. I found the ML @ game::
>
> http://thread.gmane.org/gmane.linux.gentoo.proxy-maint/
>
> I post a problem there but it has not shown up yet. I use
> gmane extensively, often to just passively follow a list
> Posting usually causes gmane to send me a notice.
>
> I justd subscribed to the mailing list directly, then perhaps gmane
> will grant me posting wrights access?
>
>
> I only see (2) posts in the ML, so is it active?
>
>
> James
>
>
>
If you are struggling to find/subscribe to the gentoo Mailing-lists, and
the Information/FAQ page appears to be missing information, please file
Bugs at bugs.gentoo.org, so that these matters get picked up, tracked
and addressed.

james, you may find this page:
https://www.gentoo.org/get-involved/mailing-lists/instructions.html helpful.

 Thanks.



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 06/12/2016 04:57 AM, Kristian Fiskerstrand wrote:
> On 06/12/2016 05:53 AM, james wrote:


> 
>> I only see (2) posts in the ML, so is it active?
> 
> It is a new ML, but it is active to the extent that you should expect to
> see discussion on it
> 

To elaborate on this, there were posts on it before gmane picked it up
as well

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 06/12/2016 05:53 AM, james wrote:
> On 06/11/2016 08:29 PM, Kristian Fiskerstrand wrote:
>> On 06/12/2016 04:20 AM, james wrote:
>>>
>>> Is there an archive to this wonderful list? I cannot seem to find the
>>> archive?
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=581370
>>
> 
> So I read this bug, but it did not illuminate an active archive, but the
> requests and subsequent problems encountered, or did i miss it? It looks
>  like the kinks are being worked out. PM having a ML is a great idea.
> 

Archive isn't working yet, it results in 500 as per comment 11
> 
> http://thread.gmane.org/gmane.linux.gentoo.proxy-maint/
> 
> I post a problem there but it has not shown up yet. I use
> gmane extensively, often to just passively follow a list
> Posting usually causes gmane to send me a notice.
> 
> I justd subscribed to the mailing list directly, then perhaps gmane will
> grant me posting wrights access?

The ML requires subscription ex ante to post, similar to most other
gentoo hosted MLs


> I only see (2) posts in the ML, so is it active?

It is a new ML, but it is active to the extent that you should expect to
see discussion on it

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: RFC: kernel-2.eclass Prefix support

[Benda Xu]

Thanks Zac, Göktürk,

I have added EPREFIX logics for EAPI<3 and improved the trailing slashes
and quotes.

Benda

--- kernel-2.eclass 2016-02-17 22:46:25.235543840 +0900
+++ kernel-2.eclass 2016-06-12 11:48:19.843801138 +0900
@@ -105,6 +105,8 @@
 HOMEPAGE="https://www.kernel.org/ https://www.gentoo.org/ ${HOMEPAGE}"
 : ${LICENSE:="GPL-2"}
 
+has "${EAPI:-0}" 0 1 2 && ED=${D} EPREFIX= EROOT=${ROOT}
+
 # This is the latest KV_PATCH of the deblob tool available from the
 # libre-sources upstream. If you bump this, you MUST regenerate the Manifests
 # for ALL kernel-2 consumer packages where deblob is available.
@@ -667,7 +669,7 @@
 
# autoconf.h isnt generated unless it already exists. plus, we 
have
# no guarantee that any headers are installed on the system...
-   [[ -f ${ROOT}/usr/include/linux/autoconf.h ]] \
+   [[ -f "${EROOT}"usr/include/linux/autoconf.h ]] \
|| touch include/linux/autoconf.h
 
# if K_DEFCONFIG isn't set, force to "defconfig"
@@ -731,10 +733,10 @@
# of this crap anymore :D
if kernel_is ge 2 6 18 ; then
env_setup_xmakeopts
-   emake headers_install INSTALL_HDR_PATH="${D}"/${ddir}/.. 
${xmakeopts} || die
+   emake headers_install INSTALL_HDR_PATH="${ED}"${ddir}/.. 
${xmakeopts} || die
 
# let other packages install some of these headers
-   rm -rf "${D}"/${ddir}/scsi  #glibc/uclibc/etc...
+   rm -rf "${ED}"${ddir}/scsi  #glibc/uclibc/etc...
return 0
fi
 
@@ -742,15 +744,15 @@
# $S values where the cmdline to cp is too long
pushd "${S}" >/dev/null
dodir ${ddir}/linux
-   cp -pPR "${S}"/include/linux "${D}"/${ddir}/ || die
-   rm -rf "${D}"/${ddir}/linux/modules
+   cp -pPR "${S}"/include/linux "${ED}"${ddir}/ || die
+   rm -rf "${ED}"${ddir}/linux/modules
 
dodir ${ddir}/asm
-   cp -pPR "${S}"/include/asm/* "${D}"/${ddir}/asm
+   cp -pPR "${S}"/include/asm/* "${ED}"${ddir}/asm
 
if kernel_is 2 6 ; then
dodir ${ddir}/asm-generic
-   cp -pPR "${S}"/include/asm-generic/* "${D}"/${ddir}/asm-generic
+   cp -pPR "${S}"/include/asm-generic/* "${ED}"${ddir}/asm-generic
fi
 
# clean up
@@ -784,7 +786,7 @@
> "${S}"/patches.txt
fi
 
-   mv ${WORKDIR}/linux* "${D}"/usr/src
+   mv ${WORKDIR}/linux* "${ED}"usr/src
 
if [[ -n "${UNIPATCH_DOCS}" ]] ; then
for i in ${UNIPATCH_DOCS}; do
@@ -797,8 +799,8 @@
 #==
 preinst_headers() {
local ddir=$(kernel_header_destdir)
-   [[ -L ${ddir}/linux ]] && rm ${ddir}/linux
-   [[ -L ${ddir}/asm ]] && rm ${ddir}/asm
+   [[ -L "${EPREFIX}"${ddir}/linux ]] && rm "${EPREFIX}"${ddir}/linux
+   [[ -L "${EPREFIX}"${ddir}/asm ]] && rm "${EPREFIX}"${ddir}/asm
 }
 
 # pkg_postinst functions
@@ -819,21 +821,21 @@
 
# if we are to forcably symlink, delete it if it already exists first.
if [[ ${K_SYMLINK} > 0 ]]; then
-   [[ -h ${ROOT}usr/src/linux ]] && rm ${ROOT}usr/src/linux
+   [[ -h "${EROOT}"usr/src/linux ]] && rm "${EROOT}"usr/src/linux
MAKELINK=1
fi
 
# if the link doesnt exist, lets create it
-   [[ ! -h ${ROOT}usr/src/linux ]] && MAKELINK=1
+   [[ ! -h "${EROOT}"usr/src/linux ]] && MAKELINK=1
 
if [[ ${MAKELINK} == 1 ]]; then
-   cd "${ROOT}"usr/src
+   cd "${EROOT}"usr/src
ln -sf linux-${KV_FULL} linux
cd ${OLDPWD}
fi
 
# Don't forget to make directory for sysfs
-   [[ ! -d ${ROOT}sys ]] && kernel_is 2 6 && mkdir ${ROOT}sys
+   [[ ! -d "${EROOT}"sys ]] && kernel_is 2 6 && mkdir "${EROOT}"sys
 
echo
elog "If you are upgrading from a previous kernel, you may be 
interested"
@@ -1353,11 +1355,11 @@
[[ ${ETYPE} == headers ]] && return 0
 
# If there isn't anything left behind, then don't complain.
-   [[ -e ${ROOT}usr/src/linux-${KV_FULL} ]] || return 0
+   [[ -e "${EROOT}"usr/src/linux-${KV_FULL} ]] || return 0
echo
ewarn "Note: Even though you have successfully unmerged "
ewarn "your kernel package, directories in kernel source location: "
-   ewarn "${ROOT}usr/src/linux-${KV_FULL}"
+   ewarn "${EROOT}usr/src/linux-${KV_FULL}"
ewarn "with modified files will remain behind. By design, package 
managers"
ewarn "will not remove these modified files and the directories they 
reside in."
echo

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

[james]

On 06/11/2016 08:29 PM, Kristian Fiskerstrand wrote:

On 06/12/2016 04:20 AM, james wrote:


Is there an archive to this wonderful list? I cannot seem to find the
archive?


https://bugs.gentoo.org/show_bug.cgi?id=581370



So I read this bug, but it did not illuminate an active archive, but the
requests and subsequent problems encountered, or did i miss it? It looks 
 like the kinks are being worked out. PM having a ML is a great idea.



Interesting. I found the ML @ game::

http://thread.gmane.org/gmane.linux.gentoo.proxy-maint/

I post a problem there but it has not shown up yet. I use
gmane extensively, often to just passively follow a list
Posting usually causes gmane to send me a notice.

I justd subscribed to the mailing list directly, then perhaps gmane will 
grant me posting wrights access?



I only see (2) posts in the ML, so is it active?


James

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

[james]

On 06/11/2016 05:52 PM, waltd...@waltdnes.org wrote:

On Sat, Jun 11, 2016 at 10:58:35PM +0200, Kristian Fiskerstrand wrote

On 06/11/2016 10:53 PM, Daniel Campbell wrote:

On 06/11/2016 07:48 AM, james wrote:

[snip]

Good/Bad idea, posting proxy-maintainer questions to gentoo-user?
(recall irc does not work for me). Also, it might just spur on other
users to create/maintain a few packages in their own area of interest.


There is also a gentoo-proxy-ma...@lists.gentoo.org list for these
kinds of questions that is likely more appropriate


Archive?

I did find (2) entries in gmane::

http://news.gmane.org/gmane.linux.gentoo.proxy-maint

surely, I'll be adding to this list



   And also gentoo-devhelp



Huh. I did now see this one on the comprehensive list. Is there an 
archive? I did find this on gmane, but this list seems mostly inactive.

Pretty sparse over the last year.

Thanks for the resource listings.

James

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

[Kristian Fiskerstrand]

On 06/12/2016 04:20 AM, james wrote:
> 
> Is there an archive to this wonderful list? I cannot seem to find the
> archive?

https://bugs.gentoo.org/show_bug.cgi?id=581370

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: kernel-2.eclass Prefix support

[Göktürk Yüksek]

Benda Xu:
> Hi Fellows,
> 
> This is a trivial patch for kernel-2.eclass to support Prefix.  Does it
> look good to be commited?
> 
> Thanks,
> Benda
> 
> Bug: 478436
> --- kernel-2.eclass   2016-02-17 22:46:25.235543840 +0900
> +++ kernel-2.eclass   2016-05-24 01:14:22.246809021 +0900
> @@ -539,8 +522,8 @@
>  #==
>  kernel_header_destdir() {
>   [[ ${CTARGET} == ${CHOST} ]] \
> - && echo /usr/include \
> - || echo /usr/${CTARGET}/usr/include
> + && echo "${EPREFIX}"/usr/include \
> + || echo "${EPREFIX}"/usr/${CTARGET}/usr/include
>  }
>  
>  cross_pre_c_headers() {
> @@ -667,7 +650,7 @@
>  
>   # autoconf.h isnt generated unless it already exists. plus, we 
> have
>   # no guarantee that any headers are installed on the system...
> - [[ -f ${ROOT}/usr/include/linux/autoconf.h ]] \
> + [[ -f ${EROOT}/usr/include/linux/autoconf.h ]] \
EROOT already ends with a trailing slash.

Also there are inconsistencies in the rest of the patch w.r.t. quoting
EROOT and EPREFIX.

>   || touch include/linux/autoconf.h
>  
>   # if K_DEFCONFIG isn't set, force to "defconfig"
> @@ -741,15 +724,15 @@
>   # Do not use "linux/*" as that can cause problems with very long
>   # $S values where the cmdline to cp is too long
>   pushd "${S}" >/dev/null
> - dodir ${ddir}/linux
> + dodir ${ddir#${EPREFIX}}/linux
>   cp -pPR "${S}"/include/linux "${D}"/${ddir}/ || die
>   rm -rf "${D}"/${ddir}/linux/modules
>  
> - dodir ${ddir}/asm
> - cp -pPR "${S}"/include/asm/* "${D}"/${ddir}/asm
> + dodir ${ddir#${EPREFIX}}/asm
> + cp -pPR "${S}"/include/asm/* "${ED}"/${ddir}/asm
>  
>   if kernel_is 2 6 ; then
> - dodir ${ddir}/asm-generic
> + dodir ${ddir#${EPREFIX}}/asm-generic
>   cp -pPR "${S}"/include/asm-generic/* "${D}"/${ddir}/asm-generic
>   fi
>  
> @@ -784,7 +767,7 @@
>   > "${S}"/patches.txt
>   fi
>  
> - mv ${WORKDIR}/linux* "${D}"/usr/src
> + mv ${WORKDIR}/linux* "${ED}"/usr/src
>  
>   if [[ -n "${UNIPATCH_DOCS}" ]] ; then
>   for i in ${UNIPATCH_DOCS}; do
> @@ -819,22 +799,22 @@
>  
>   # if we are to forcably symlink, delete it if it already exists first.
>   if [[ ${K_SYMLINK} > 0 ]]; then
> - [[ -h ${ROOT}usr/src/linux ]] && rm ${ROOT}usr/src/linux
> + [[ -h ${EROOT}usr/src/linux ]] && rm ${EROOT}usr/src/linux
>   MAKELINK=1
>   fi
>  
>   # if the link doesnt exist, lets create it
> - [[ ! -h ${ROOT}usr/src/linux ]] && MAKELINK=1
> + [[ ! -h ${EROOT}usr/src/linux ]] && MAKELINK=1
>  
>   if [[ ${MAKELINK} == 1 ]]; then
> - cd "${ROOT}"usr/src
> + cd "${EROOT}"usr/src
>   ln -sf linux-${KV_FULL} linux
>   cd ${OLDPWD}
>   fi
>  
>   # Don't forget to make directory for sysfs
> - [[ ! -d ${ROOT}sys ]] && kernel_is 2 6 && mkdir ${ROOT}sys
> + [[ ! -d ${EROOT}sys ]] && kernel_is 2 6 && mkdir ${EROOT}sys
>  
>   echo
>   elog "If you are upgrading from a previous kernel, you may be 
> interested"
>   elog "in the following document:"
> @@ -1353,11 +1310,11 @@
>   [[ ${ETYPE} == headers ]] && return 0
>  
>   # If there isn't anything left behind, then don't complain.
> - [[ -e ${ROOT}usr/src/linux-${KV_FULL} ]] || return 0
> + [[ -e ${EROOT}usr/src/linux-${KV_FULL} ]] || return 0
>   echo
>   ewarn "Note: Even though you have successfully unmerged "
>   ewarn "your kernel package, directories in kernel source location: "
> - ewarn "${ROOT}usr/src/linux-${KV_FULL}"
> + ewarn "${EROOT}usr/src/linux-${KV_FULL}"
>   ewarn "with modified files will remain behind. By design, package 
> managers"
>   ewarn "will not remove these modified files and the directories they 
> reside in."
>   echo
> 

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

[james]

On 06/11/2016 03:59 PM, Daniel Campbell wrote:

On 06/11/2016 01:58 PM, Kristian Fiskerstrand wrote:

On 06/11/2016 10:53 PM, Daniel Campbell wrote:

On 06/11/2016 07:48 AM, james wrote:



There is also a gentoo-proxy-ma...@lists.gentoo.org list for these kinds
of questions that is likely more appropriate



Ah, yes. I had forgotten about that list. That does seem like the best
place for that. My apologies.


Great. That sounds perfect. I never saw that mail list.

Perhaps this list needs to be listed::
here:
https://www.gentoo.org/get-involved/mailing-lists/all-lists.html

and maybe here:

https://www.gentoo.org/get-involved/mailing-lists/

Is there an archive to this wonderful list? I cannot seem to find the
archive?

THANKS!
James

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

[waltdnes]

On Sat, Jun 11, 2016 at 10:58:35PM +0200, Kristian Fiskerstrand wrote
> On 06/11/2016 10:53 PM, Daniel Campbell wrote:
> > On 06/11/2016 07:48 AM, james wrote:
> >> [snip]
> >>
> >> Good/Bad idea, posting proxy-maintainer questions to gentoo-user?
> >> (recall irc does not work for me). Also, it might just spur on other
> >> users to create/maintain a few packages in their own area of interest.
> 
> There is also a gentoo-proxy-ma...@lists.gentoo.org list for these
> kinds of questions that is likely more appropriate

  And also gentoo-devhelp

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [gentoo-dev-announce] Last rites: dev-util/{...}

[Matthias Schwarzott]

Am 11.06.2016 um 21:41 schrieb Matthias Schwarzott:
> Am 05.06.2016 um 21:04 schrieb Robin H. Johnson:
>> On Sun, Jun 05, 2016 at 01:47:48PM +0200, Patrice Clement wrote:
>>> dev-util/cdecl
>>> dev-util/dwarves
>>> dev-util/intel2gas
>>> dev-util/lsuio
>>> dev-util/mock
>>> dev-util/par
>>> dev-util/tinlink
>>> dev-util/usb-robot
>> I've used the above subset of these, so I'll review the upstreams to see
>> if they just moved or what.
>>
> 
> I also would like to have dev-util/dwarves be kept. I use the pahole
> tool from time to time.
> As I checked it, the git repository has new commits from this year.
> 
I took dev-util/dwarves now and updated it to a snapshot containing the
latest changes from upstream.
Now it works with recent compiler output again.

Regards
Matthias

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

[Daniel Campbell]

On 06/11/2016 01:58 PM, Kristian Fiskerstrand wrote:
> On 06/11/2016 10:53 PM, Daniel Campbell wrote:
>> On 06/11/2016 07:48 AM, james wrote:
>>> [snip]
>>>
>>> Good/Bad idea, posting proxy-maintainer questions to gentoo-user?
>>> (recall irc does not work for me). Also, it might just spur on other
>>> users to create/maintain a few packages in their own area of interest.
> 
> There is also a gentoo-proxy-ma...@lists.gentoo.org list for these kinds
> of questions that is likely more appropriate
> 
Ah, yes. I had forgotten about that list. That does seem like the best
place for that. My apologies.

-- 
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)

[Kristian Fiskerstrand]

On 06/11/2016 10:53 PM, Daniel Campbell wrote:
> On 06/11/2016 07:48 AM, james wrote:
>> [snip]
>>
>> Good/Bad idea, posting proxy-maintainer questions to gentoo-user?
>> (recall irc does not work for me). Also, it might just spur on other
>> users to create/maintain a few packages in their own area of interest.

There is also a gentoo-proxy-ma...@lists.gentoo.org list for these kinds
of questions that is likely more appropriate

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Daniel Campbell]

On 06/11/2016 07:48 AM, james wrote:
> [snip]
> 
> Good/Bad idea, posting proxy-maintainer questions to gentoo-user?
> (recall irc does not work for me). Also, it might just spur on other
> users to create/maintain a few packages in their own area of interest.

Anyone is welcome to post to either gentoo-user _or_ gentoo-dev. Ebuild
questions are likely more appropriate on gentoo-dev, but if we're
talking about a high volume of e-mail, it may suit gentoo-user more
since that's the target audience. You'd get a better idea of consensus
over there, as there are some devs who aren't subscribed to gentoo-user.
It wouldn't be fair for us to form consensus for a mailing list we
aren't on. Granted, some of us also hang out on -user. I'm not one of
them, but I think your idea to discuss ebuilds and things over a mailing
list is good. We already have an avenue for that in the forums and IRC,
so the mailing list couldn't hurt.

The only issue is you'd want to make sure you're getting quality answers
from people who know what they're doing. There are many ways to write an
ebuild, but a great majority of them are inefficient or not up to
Gentoo's standards.

That said, the idea has merit. Are there others who would rather not use
the fora or IRC?
-- 
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: [gentoo-dev] Packages up for grabs

[Pacho Ramos]

El sáb, 11-06-2016 a las 22:48 +0200, Pacho Ramos escribió:
> El jue, 02-06-2016 a las 10:42 -0500, james escribió:
> > 
> > On 06/01/2016 06:20 PM, Justin Bronder wrote:
> >  > Due to a lack of time and the fact I don't use any of these
> > packages 
> >  > anymore, they are all up for grabs.
> >  >
> >  >  - media-gfx/openmesh [no project]
> >  >  - sys-cluster/ganglia [cluster]
> >  >  - sys-cluster/ganglia-web [cluster]
> >  >  - sys-cluster/torque [cluster]
> >  >  - sys-cluster/munge [cluster] dependency of sys-
> > cluster/torque
> >  >  - sys-cluster/mpe2 [cluster]
> >  >
> >  > Also, if there's anyone out there using the science overlay and
> > empi 
> >  > who's feeling motivated, that work still needs a champion to get
> > it
> >  > into the main tree.  If not, I'll probably drop it in a few
> > months
> >  > and open openmpi and mpich2 to project maintenance as well.  I
> >  > haven't been involved in HPC for over a decade now, it's time to
> >  > pass the torch.
> > 
> > 
> > Hello Justin,
> > 
> > I've been working on cluster ebuilds for a while (Apache Mesos,
> > spark, 
> > etc). I'm willing to proxy maintain these except torque. Assuming
> > there 
> > are no users of torque on gentoo (bgo seems inactive...it's dead;
> > how 
> > would I know?).
> > 
> > My focus is building gentoo centric HPC clusters that do not
> > require 
> > systemd as a component, with deployment emphasis on bare-metal and 
> > minimized gentoo systems where only the codes absolutely necessary
> > to 
> > support the necessary frameworks are dynamically installed. Many of
> > the 
> > 'retro' tools in this cluster space, are quite useful for my work.
> > 
> > The guidexml page for empi is old, so where do I read up on it's 
> > projected usage (just not familiar with that empi project/package).
> > 
> > James
> > 
> Then, I would suggest you to contact proxy-maint project (I have CCed
> them to this for letting them to know)
> 
> Thanks for volunteering!

Bleh, nevermind... I missed the other mail with jsbronder volunteering
for doing that job :)

Re: [gentoo-dev] Packages up for grabs

[Pacho Ramos]

El jue, 02-06-2016 a las 10:42 -0500, james escribió:
> On 06/01/2016 06:20 PM, Justin Bronder wrote:
>  > Due to a lack of time and the fact I don't use any of these
> packages 
>  > anymore, they are all up for grabs.
>  >
>  >  - media-gfx/openmesh [no project]
>  >  - sys-cluster/ganglia [cluster]
>  >  - sys-cluster/ganglia-web [cluster]
>  >  - sys-cluster/torque [cluster]
>  >  - sys-cluster/munge [cluster] dependency of sys-
> cluster/torque
>  >  - sys-cluster/mpe2 [cluster]
>  >
>  > Also, if there's anyone out there using the science overlay and
> empi 
>  > who's feeling motivated, that work still needs a champion to get
> it
>  > into the main tree.  If not, I'll probably drop it in a few months
>  > and open openmpi and mpich2 to project maintenance as well.  I
>  > haven't been involved in HPC for over a decade now, it's time to
>  > pass the torch.
> 
> 
> Hello Justin,
> 
> I've been working on cluster ebuilds for a while (Apache Mesos,
> spark, 
> etc). I'm willing to proxy maintain these except torque. Assuming
> there 
> are no users of torque on gentoo (bgo seems inactive...it's dead;
> how 
> would I know?).
> 
> My focus is building gentoo centric HPC clusters that do not require 
> systemd as a component, with deployment emphasis on bare-metal and 
> minimized gentoo systems where only the codes absolutely necessary
> to 
> support the necessary frameworks are dynamically installed. Many of
> the 
> 'retro' tools in this cluster space, are quite useful for my work.
> 
> The guidexml page for empi is old, so where do I read up on it's 
> projected usage (just not familiar with that empi project/package).
> 
> James
> 

Then, I would suggest you to contact proxy-maint project (I have CCed
them to this for letting them to know)

Thanks for volunteering!

Re: [gentoo-dev] Council Council: call for agenda items for June 12 meeting

[Daniel Campbell]

On 06/11/2016 06:18 AM, Rich Freeman wrote:
> On Sat, Jun 11, 2016 at 8:09 AM, Pacho Ramos  wrote:
>>
>> Yeah, I also fail to see what is wrong with suggesting the items for
>> the agenda... is not that the purpose of this call? Or maybe I am
>> missing some replies to the thread :|
>>
> 
> I'm not entirely sure I've caught everything going on based on reactions/etc.
> 
> But, to answer your question generally (I'm not specifically referring
> to the topics mgorny raised):
> 
> Anybody can ask the council to discuss anything at the meetings.  Note
> that the purpose of the council isn't to micromanage everything in
> Gentoo, and in general we like to try to build consensus and seek
> input before we just hand down decisions.  This allows everybody to
> have their say and it is foolish to disregard the expertise of those
> who don't happen to be on the council.  I think having a forum to
> formally air opinions but leave with decisions and not endless debate
> is one of the main value-adds of the council.
> 
> So, if somebody suggests a topic that isn't entirely ripe for a
> decision most likely the council is probably going to try to trigger
> some list discussion to get it there if that is reasonable, and if not
> it will probably just air some opinions and try to offer some advice
> on what still needs to be done.  There is never harm in asking the
> council to get involved, but if a council agenda item is the first
> time a topic comes up, don't be surprised if you don't leave with
> something resembling a final decision.
> 
> This is of course how this council has generally operated and future
> councils are free to operate differently, though I'd generally say
> that this sort of approach has worked really well for the last few
> years IMO.  In the end it is really the individuals behind initiatives
> who have the power to make them happen.  The council functions best
> when it is opening up the way for individuals to scratch their itch
> and not just handing down "unfunded mandates."
> 
That's pretty much the way I understood it. As you said, the council
seems to have been run that way for the past few years.

I like that approach, because it gives everyone some pause and gives
other perspectives a chance to percolate. Based on what I've read in
past council discussions, the council is likely to have 'the full
picture' in mind and can often point out weaknesses in proposals, which
can only help them in the long run.

-- 
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

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-admin/ccze
app-crypt/ckpass
app-mobilephone/sobexsrv
dev-libs/libkpass
media-gfx/qrencode
sys-apps/razercfg
x11-misc/xdotool

Re: [gentoo-dev] [gentoo-dev-announce] Last rites: dev-util/{...}

[Matthias Schwarzott]

Am 05.06.2016 um 21:04 schrieb Robin H. Johnson:
> On Sun, Jun 05, 2016 at 01:47:48PM +0200, Patrice Clement wrote:
>> dev-util/cdecl
>> dev-util/dwarves
>> dev-util/intel2gas
>> dev-util/lsuio
>> dev-util/mock
>> dev-util/par
>> dev-util/tinlink
>> dev-util/usb-robot
> I've used the above subset of these, so I'll review the upstreams to see
> if they just moved or what.
> 

I also would like to have dev-util/dwarves be kept. I use the pahole
tool from time to time.
As I checked it, the git repository has new commits from this year.

Regards
Matthias

Re: [gentoo-dev] RFC: kernel-2.eclass Prefix support

[Zac Medico]

On 06/11/2016 08:02 AM, Benda Xu wrote:
> Hi Fellows,
> 
> This is a trivial patch for kernel-2.eclass to support Prefix.  Does it
> look good to be commited?

The EPREFIX and EROOT variables are undefined prior to EAPI 3, so the
eclass should die if the EAPI is 0, 1, or 2.
-- 
Thanks,
Zac

[gentoo-dev] RFC: kernel-2.eclass Prefix support

[Benda Xu]

Hi Fellows,

This is a trivial patch for kernel-2.eclass to support Prefix.  Does it
look good to be commited?

Thanks,
Benda

Bug: 478436
--- kernel-2.eclass 2016-02-17 22:46:25.235543840 +0900
+++ kernel-2.eclass 2016-05-24 01:14:22.246809021 +0900
@@ -539,8 +522,8 @@
 #==
 kernel_header_destdir() {
[[ ${CTARGET} == ${CHOST} ]] \
-   && echo /usr/include \
-   || echo /usr/${CTARGET}/usr/include
+   && echo "${EPREFIX}"/usr/include \
+   || echo "${EPREFIX}"/usr/${CTARGET}/usr/include
 }
 
 cross_pre_c_headers() {
@@ -667,7 +650,7 @@
 
# autoconf.h isnt generated unless it already exists. plus, we 
have
# no guarantee that any headers are installed on the system...
-   [[ -f ${ROOT}/usr/include/linux/autoconf.h ]] \
+   [[ -f ${EROOT}/usr/include/linux/autoconf.h ]] \
|| touch include/linux/autoconf.h
 
# if K_DEFCONFIG isn't set, force to "defconfig"
@@ -741,15 +724,15 @@
# Do not use "linux/*" as that can cause problems with very long
# $S values where the cmdline to cp is too long
pushd "${S}" >/dev/null
-   dodir ${ddir}/linux
+   dodir ${ddir#${EPREFIX}}/linux
cp -pPR "${S}"/include/linux "${D}"/${ddir}/ || die
rm -rf "${D}"/${ddir}/linux/modules
 
-   dodir ${ddir}/asm
-   cp -pPR "${S}"/include/asm/* "${D}"/${ddir}/asm
+   dodir ${ddir#${EPREFIX}}/asm
+   cp -pPR "${S}"/include/asm/* "${ED}"/${ddir}/asm
 
if kernel_is 2 6 ; then
-   dodir ${ddir}/asm-generic
+   dodir ${ddir#${EPREFIX}}/asm-generic
cp -pPR "${S}"/include/asm-generic/* "${D}"/${ddir}/asm-generic
fi
 
@@ -784,7 +767,7 @@
> "${S}"/patches.txt
fi
 
-   mv ${WORKDIR}/linux* "${D}"/usr/src
+   mv ${WORKDIR}/linux* "${ED}"/usr/src
 
if [[ -n "${UNIPATCH_DOCS}" ]] ; then
for i in ${UNIPATCH_DOCS}; do
@@ -819,22 +799,22 @@
 
# if we are to forcably symlink, delete it if it already exists first.
if [[ ${K_SYMLINK} > 0 ]]; then
-   [[ -h ${ROOT}usr/src/linux ]] && rm ${ROOT}usr/src/linux
+   [[ -h ${EROOT}usr/src/linux ]] && rm ${EROOT}usr/src/linux
MAKELINK=1
fi
 
# if the link doesnt exist, lets create it
-   [[ ! -h ${ROOT}usr/src/linux ]] && MAKELINK=1
+   [[ ! -h ${EROOT}usr/src/linux ]] && MAKELINK=1
 
if [[ ${MAKELINK} == 1 ]]; then
-   cd "${ROOT}"usr/src
+   cd "${EROOT}"usr/src
ln -sf linux-${KV_FULL} linux
cd ${OLDPWD}
fi
 
# Don't forget to make directory for sysfs
-   [[ ! -d ${ROOT}sys ]] && kernel_is 2 6 && mkdir ${ROOT}sys
+   [[ ! -d ${EROOT}sys ]] && kernel_is 2 6 && mkdir ${EROOT}sys
 
echo
elog "If you are upgrading from a previous kernel, you may be 
interested"
elog "in the following document:"
@@ -1353,11 +1310,11 @@
[[ ${ETYPE} == headers ]] && return 0
 
# If there isn't anything left behind, then don't complain.
-   [[ -e ${ROOT}usr/src/linux-${KV_FULL} ]] || return 0
+   [[ -e ${EROOT}usr/src/linux-${KV_FULL} ]] || return 0
echo
ewarn "Note: Even though you have successfully unmerged "
ewarn "your kernel package, directories in kernel source location: "
-   ewarn "${ROOT}usr/src/linux-${KV_FULL}"
+   ewarn "${EROOT}usr/src/linux-${KV_FULL}"
ewarn "with modified files will remain behind. By design, package 
managers"
ewarn "will not remove these modified files and the directories they 
reside in."
echo

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

[james]

On 06/10/2016 10:09 PM, konsolebox wrote:

On Wed, Jun 8, 2016 at 11:53 PM, james  wrote:

The grandiose-ness you propose should only come upon graduating from proxy 
school, imho.
user-->strong-users-->proxy-->dev pathway.


Pedantic, bureaucratic, procedure-oriented, monolithic, restrictive.
Too conservative.


Funny, this seems like a warm complement, not a criticism or deficiency.



What matters is the contribution, and the result.  If you don't like
how a user makes a contribution, don't accept the pull request, or
don't merge his package.  Simple.  If you think that could turn out to
be just a waste of time for them, help them correct their issues; add
some documentations to enlighten them and give warnings about wrong
practices so they don't blame anyone, and so they can decide whether
they would want to contribute or not given the rules presented; but,
_don't_ make the steps mandatory.  Don't make contributions
restrictive.


Security is out the window with what you propose, so you will only 
attract a subset of folks to your beliefs, imho.




We do already allow people to send pull requests to
Gentoo portage's repo in Github, but it seems like they generally only
allow patches that fix current packages, not new features or new
packages.


Yes, do mostly to a lack for formal documentation on howto do those 
things, imho.


You miss the point. Your way is but one pathway. Go forth and create it,
alone or with a dev, as you do not need help. Me, I'm a simpler, sort of 
a monkey-see monkey-do type of hack. I like to read and find formalized 
documentation, augmented with examples, of great comfort and confidence. 
It keeps the trains rolling along the same track, in a very productive 
manner.



That's the very reason why I didn't like becoming a dev.  The system
is too conservative and old-school for me.  I avoid projects where
collaboration is mandatory.  I prefer contributing to a project with
open and loosely knit arrangements, and a dynamic system.  Rankings,
team bonding mean nothing.


You are confusing issues. There is a multitude of folks I've encountered 
over the years that are gentoo-lone-wolves, most have an extraordinary 
levels of competence and do not require interaction with gentoo proper. 
Many like the solace, so there is nothing precluding you from utopic 
gentoo. You are all ready there, aren't you?


/usr/local/portage + github mastery and you do not need the community, 
right?


I do appreciate your input and all the other input. I'm just looking for 
a different pathway, where I can read, and find answers, at my own pace. 
A formal set of documents does provide the gentoo devs/council control 
over what folks learn along the way to dev status and prevents the same 
questions from being asked, over and over and over again. Ad-hoc forums, 
such as irc-proxy and mail-reflectors have poor QA attributes over time, 
imho. QA in those mediums is labor intensive.

Those sorts of mediums are great for unique and non-standard needs.
Documents are king for routine and basic questions that are often seen,
evidence by the myriad of howto's, FAQ's and such documents in existence.


So my conclusion is to just post proxy centric questions, to gentoo-user
and all other questions along the pathway from user==>dev. If docs are 
parsed out and formalized/standardize from the archive, then that would 
be a good thing. If not, I guess folks can use their own filters to 
search out random answers to the (50-500) common questions along that 
pathway.


Good/Bad idea, posting proxy-maintainer questions to gentoo-user?
(recall irc does not work for me). Also, it might just spur on other 
users to create/maintain a few packages in their own area of interest.



konsolebox


James

Re: [gentoo-dev] Council Council: call for agenda items for June 12 meeting

[Rich Freeman]

On Sat, Jun 11, 2016 at 8:09 AM, Pacho Ramos  wrote:
>
> Yeah, I also fail to see what is wrong with suggesting the items for
> the agenda... is not that the purpose of this call? Or maybe I am
> missing some replies to the thread :|
>

I'm not entirely sure I've caught everything going on based on reactions/etc.

But, to answer your question generally (I'm not specifically referring
to the topics mgorny raised):

Anybody can ask the council to discuss anything at the meetings.  Note
that the purpose of the council isn't to micromanage everything in
Gentoo, and in general we like to try to build consensus and seek
input before we just hand down decisions.  This allows everybody to
have their say and it is foolish to disregard the expertise of those
who don't happen to be on the council.  I think having a forum to
formally air opinions but leave with decisions and not endless debate
is one of the main value-adds of the council.

So, if somebody suggests a topic that isn't entirely ripe for a
decision most likely the council is probably going to try to trigger
some list discussion to get it there if that is reasonable, and if not
it will probably just air some opinions and try to offer some advice
on what still needs to be done.  There is never harm in asking the
council to get involved, but if a council agenda item is the first
time a topic comes up, don't be surprised if you don't leave with
something resembling a final decision.

This is of course how this council has generally operated and future
councils are free to operate differently, though I'd generally say
that this sort of approach has worked really well for the last few
years IMO.  In the end it is really the individuals behind initiatives
who have the power to make them happen.  The council functions best
when it is opening up the way for individuals to scratch their itch
and not just handing down "unfunded mandates."

-- 
Rich

Re: [gentoo-dev] Council Council: call for agenda items for June 12 meeting

[Pacho Ramos]

El sáb, 11-06-2016 a las 03:35 -0700, Daniel Campbell escribió:
> On 06/10/2016 02:45 PM, Michał Górny wrote:
> > 
> > Hello,
> > 
> > Considering the strength of response from a Council member, I would
> > like to officially apologize for providing the agenda items and I
> > would
> > like to withdraw them all appropriately. Thank you for your time,
> > and I
> > wish you re-election.
> > 
> > 
> > On Fri, 3 Jun 2016 16:06:25 +0200
> > Michał Górny  wrote:
> > 
> > > 
> > > On Fri, 3 Jun 2016 07:01:03 -0400
> > > "Anthony G. Basile"  wrote:
> > > 
> > > > 
> > > > Hi everyone,
> > > > 
> > > > The Council will be meeting on Sunday June 12.  This is a call
> > > > for any
> > > > agenda items.  
> > > In preferred order of discussion (i.e. shortest topics first):
> > > 
> > > 1. the 'file installation masks' GLEP [spec:1, RFC:2, bug:3]. It
> > > still
> > > hasn't been merged by the GLEP editors but it's otherwise ready
> > > with
> > > reference implementation for Portage. Preferably please discuss
> > > this
> > > separately/before LINGUAS as it is quite generic and I think
> > > having it
> > > approved would benefit us. The part specifically needing Council
> > > approval is the extra configuration file in metadata/ dir of the
> > > repository.
> > > 
> > > 2. The patch fixing USE_EXPAND handling in Portage to adhere to
> > > the rules enforced by the PMS for EAPI 5 and newer [patch:4,
> > > patch v1:5, bug:6]. The patch comes in two variants. The former
> > > (preferred by me) applies the change to all EAPIs since this way
> > > we can
> > > kill the ugly logic for earlier EAPIs and PMS leaves the behavior
> > > undefined for them. The latter applies it only to EAPI 5 and
> > > newer,
> > > leaving current behavior for older EAPIs. I don't think it really
> > > makes
> > > sense to have different logic as EAPI 5 is quite common already,
> > > and
> > > different behavior will only increase confusion.
> > > 
> > > 3. New sys-devel/gcc USE=multislot [QA bug:7]. I originally
> > > wanted to
> > > do this via QA but considering the replies to bugs opened so far,
> > > I
> > > think Council approval would be additionally helpful. The key
> > > point of
> > > my request would be to kill the flag, and stop force-removing old
> > > versions implicitly.
> > > 
> > > 4. LINGUAS [8,9]. Long story short, PMS considered, we implicitly
> > > strip
> > > localizations from most of the packages out there. I think the
> > > first
> > > step towards fixing it that the most people can approve is
> > > renaming
> > > the USE_EXPAND from LINGUAS to I18N or L10N, or generally
> > > something
> > > else, plus a news item.
> > > 
> > > 5. USE=gui [10]. It seems to get some appreciation but I suspect
> > > it's
> > > going to end up going to the Council anyway.
> > > 
> > > I think that's all for now. If I recall something else, I'll let
> > > you
> > > know.
> > > 
> > > 
> > > [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:INSTALL_MASK
> > > [2]:https://archives.gentoo.org/gentoo-dev/message/af5de8be051fdf
> > > 60d4d4aef97df6e683
> > > [3]:https://bugs.gentoo.org/show_bug.cgi?id=584452
> > > [4]:https://archives.gentoo.org/gentoo-portage-dev/message/42e3a1
> > > 34d14e33e037e35e6c5df9d05d
> > > [5]:https://archives.gentoo.org/gentoo-portage-dev/message/b79fc6
> > > bd174a356c62bda59d0b0e9e8e
> > > [6]:https://bugs.gentoo.org/show_bug.cgi?id=583750
> > > [7]:https://bugs.gentoo.org/show_bug.cgi?id=584610
> > > [8]:https://archives.gentoo.org/gentoo-dev/message/a08ea09c2c8e53
> > > 4fd9bc1146703c66ff
> > > [9]:https://archives.gentoo.org/gentoo-dev/message/41e09d1ddc8b30
> > > abb9f9d21d205b7b82
> > > [10]:https://archives.gentoo.org/gentoo-dev/message/eecad37024811
> > > 8c474a0d819fa7f3576
> > > 
> > 
> > 
> I can understand wanting to avoid a conflict of interest, but I
> really
> don't see the trouble in suggesting your ideas hit the agenda. The
> council can always choose "we don't want to decide on this yet". At
> least, that's what I understand.
> 

Yeah, I also fail to see what is wrong with suggesting the items for
the agenda... is not that the purpose of this call? Or maybe I am
missing some replies to the thread :|

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

[Daniel Campbell]

On 06/10/2016 09:05 AM, Alec Ten Harmsel wrote:
> On Fri, Jun 10, 2016 at 04:20:06PM +0100, M. J. Everitt wrote:
>> (2) any user can edit wiki pages not governed by Projects. Even Project
>> pages I'm sure could be updated by means of patches submitted to the
>> appropriate team, with some basic follow-up to ensure action.
> 
> Only users with a wiki account. The gentoo wiki/handbook et. al. are
> great, but I personally really do not like editing wikis in general.
> When I see a clarification or improvement that I could make in gentoo's
> docs, I remember that I'd have to:
> 
> * get a wiki account
> * use a dumb web editor and (probably) HTML to make a change instead of vim

I edit the wiki every now and then, and use a great extension for
Firefox called "It's All Text" which allows you to use any program to
edit the text in  elements. It makes editing much better for
me. I'm not sure if Chromium has anything equivalent, but it's something.

> * get it approved somehow
> 
> All my enthusiasm vanishes at that point. If gentoo's wiki/docs were,
> say, a bunch of markdown files in a git repo somewhere, I would be much
> more willing to clone the repo, make a change, and send in a patch. A
> wiki and handbook could be auto-generated from this, of course. From an
> infra standpoint, this is also simpler than maintaining a wiki.
> 
>> (3) until some enthusiastic sponsors come forward to host/maintain these
>> systems, I don't think its fair to overburden the already stretched
>> Infra guys (no offence, guys! you're doin a great job).
> 
> Agree. Gentoo is fantastic.
> 
> Alec
> 


-- 
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: [gentoo-dev] Council Council: call for agenda items for June 12 meeting

[Daniel Campbell]

On 06/10/2016 02:45 PM, Michał Górny wrote:
> Hello,
> 
> Considering the strength of response from a Council member, I would
> like to officially apologize for providing the agenda items and I would
> like to withdraw them all appropriately. Thank you for your time, and I
> wish you re-election.
> 
> 
> On Fri, 3 Jun 2016 16:06:25 +0200
> Michał Górny  wrote:
> 
>> On Fri, 3 Jun 2016 07:01:03 -0400
>> "Anthony G. Basile"  wrote:
>>
>>> Hi everyone,
>>>
>>> The Council will be meeting on Sunday June 12.  This is a call for any
>>> agenda items.  
>>
>> In preferred order of discussion (i.e. shortest topics first):
>>
>> 1. the 'file installation masks' GLEP [spec:1, RFC:2, bug:3]. It still
>> hasn't been merged by the GLEP editors but it's otherwise ready with
>> reference implementation for Portage. Preferably please discuss this
>> separately/before LINGUAS as it is quite generic and I think having it
>> approved would benefit us. The part specifically needing Council
>> approval is the extra configuration file in metadata/ dir of the
>> repository.
>>
>> 2. The patch fixing USE_EXPAND handling in Portage to adhere to
>> the rules enforced by the PMS for EAPI 5 and newer [patch:4,
>> patch v1:5, bug:6]. The patch comes in two variants. The former
>> (preferred by me) applies the change to all EAPIs since this way we can
>> kill the ugly logic for earlier EAPIs and PMS leaves the behavior
>> undefined for them. The latter applies it only to EAPI 5 and newer,
>> leaving current behavior for older EAPIs. I don't think it really makes
>> sense to have different logic as EAPI 5 is quite common already, and
>> different behavior will only increase confusion.
>>
>> 3. New sys-devel/gcc USE=multislot [QA bug:7]. I originally wanted to
>> do this via QA but considering the replies to bugs opened so far, I
>> think Council approval would be additionally helpful. The key point of
>> my request would be to kill the flag, and stop force-removing old
>> versions implicitly.
>>
>> 4. LINGUAS [8,9]. Long story short, PMS considered, we implicitly strip
>> localizations from most of the packages out there. I think the first
>> step towards fixing it that the most people can approve is renaming
>> the USE_EXPAND from LINGUAS to I18N or L10N, or generally something
>> else, plus a news item.
>>
>> 5. USE=gui [10]. It seems to get some appreciation but I suspect it's
>> going to end up going to the Council anyway.
>>
>> I think that's all for now. If I recall something else, I'll let you
>> know.
>>
>>
>> [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:INSTALL_MASK
>> [2]:https://archives.gentoo.org/gentoo-dev/message/af5de8be051fdf60d4d4aef97df6e683
>> [3]:https://bugs.gentoo.org/show_bug.cgi?id=584452
>> [4]:https://archives.gentoo.org/gentoo-portage-dev/message/42e3a134d14e33e037e35e6c5df9d05d
>> [5]:https://archives.gentoo.org/gentoo-portage-dev/message/b79fc6bd174a356c62bda59d0b0e9e8e
>> [6]:https://bugs.gentoo.org/show_bug.cgi?id=583750
>> [7]:https://bugs.gentoo.org/show_bug.cgi?id=584610
>> [8]:https://archives.gentoo.org/gentoo-dev/message/a08ea09c2c8e534fd9bc1146703c66ff
>> [9]:https://archives.gentoo.org/gentoo-dev/message/41e09d1ddc8b30abb9f9d21d205b7b82
>> [10]:https://archives.gentoo.org/gentoo-dev/message/eecad370248118c474a0d819fa7f3576
>>
> 
> 
> 
I can understand wanting to avoid a conflict of interest, but I really
don't see the trouble in suggesting your ideas hit the agenda. The
council can always choose "we don't want to decide on this yet". At
least, that's what I understand.

-- 
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)

[Ashish Gupta]

Presently, the way to make contributions as outlined in [1] is to create
a bugzilla ticket and attach the patch to that ticket. But there is no
community involvement really for this.

A possible model for increasing user-collaboration and promoting user activity:

>From User's POV:
  - Do emerge --sync and get the tree (Obvious)
  - Make changes, fix/add ebuilds in /usr/portage
  - Do emerge --please-take-my-tree-to-community-review

What will emerge --please-take-my-tree-to-community-review do?
  - Generate a suitable patch between the user's local tree and the
official tree
  - Trigger pybugz[2] (or similar..) to create a new Bugzilla
ticketwith as much information
as possible. For example, it can be automatically guessed whether
the changes
are about fixing an existing ebuild or adds a new ebuild.
===
  - In addition to the emails that are sent by bugzilla to the
developers or groups
responsible, a new email would be sent to
nice-users-that-will-help-me-review-my-code at gentoo.org for
community review.
This will help the user fix issues (The user might range from
complete novice to
almost-developer) according to feedback he or she recieves from other users.
Other users can also run the new ebuilds easily (will promote
sharing user contributions).
  - Once enough people have used the new contributions, the changes
have more chances
of being merged into the official tree.
===

The bugzilla ticket can be suitably updated by the contributor. The
best part is that
the user doesn't need any git expertise and can focus on the task at
hand. This will
also help promote user discussion and the feedback-improve cycle for
user contributions.
IMHO, once it is extremely easy for the users to make contributions, they will
have less mental barriers to become contributors. The discussion on
the ML (or IRC),
will also help in deduplication/enhancement as some existing user(s)
might have already made
similar changes to the same ebuilds but didn't consider sharing them earlier.

As far as the execution is concerned, one possibility is to have a USE flag:
So if portage was installed with USE="dev-mode", all the above
features would be enabled
and dependencies like pybugz (or others) will be pulled in.
Who ever sets this USE flag should also have the possibility of adding
his or her email address
to the contributors ML through the terminal so that they can start
participating asap.

I'm not sure if this satisfies or handles all/any of the features that bernalex
had in mind but I think it would be a big step forward in user contributions and
making them feel that they are a part of the Gentoo community and that
their work
/contributions are deemed important. It might also make potential
Gentoo devs feel
that it is not *that* difficult to become an official developer as
they are already
contributing as a user.

PS - Not directly related, but the same model can most probably be used to help
 users in suggesting would-be-good-to-have features and receiving
feedback on that
 from other users, out of which some might actually take the bold step of
 building it and sending it back to the requesting user.

All criticism is welcome.

[1]: https://wiki.gentoo.org/wiki/Submitting_ebuilds
[2]: https://github.com/williamh/pybugz/ (Package is www-client/pybugz)

Regards,
Ashish Gupta

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

[Michał Górny]

On Sat, 11 Jun 2016 11:09:39 +0800
konsolebox  wrote:

> On Wed, Jun 8, 2016 at 11:53 PM, james  wrote:
> > The grandiose-ness you propose should only come upon graduating from proxy 
> > school, imho.
> > user-->strong-users-->proxy-->dev pathway.  
> 
> Pedantic, bureaucratic, procedure-oriented, monolithic, restrictive.
> Too conservative.
> 
> What matters is the contribution, and the result.  If you don't like
> how a user makes a contribution, don't accept the pull request, or
> don't merge his package.  Simple.  If you think that could turn out to
> be just a waste of time for them, help them correct their issues; add
> some documentations to enlighten them and give warnings about wrong
> practices so they don't blame anyone, and so they can decide whether
> they would want to contribute or not given the rules presented; but,
> _don't_ make the steps mandatory.  Don't make contributions
> restrictive.

You're contradicting yourself. How can improving/review of pull request
be non-mandatory, if otherwise we are to reject it? Of course, it all
depends on how you define 'mandatory'. It's not like anybody forces you
to do something, you know.

Sure, it may seem like we expect people to fix all the tiny issues with
pull requests but that's just a default profile we're assuming. Many of
the people actually *want* to do that. If you don't, you can tell us
straight ahead and we won't waste our time asking you to.

I'm also unhappy when a pull request is left open for two weeks because
we asked user to do a simple change, and he doesn't reply. I could've
fixed it myself faster but then the user would lose his chance to do
it. And the worst thing, I don't even know if he wants to!

> We do already allow people to send pull requests to
> Gentoo portage's repo in Github, but it seems like they generally only
> allow patches that fix current packages, not new features or new
> packages.

That's not true. The rules for pull requests are pretty much the same
as for bugs.

If a fix or enhancement makes sense, the maintainer can approve it or
not. Don't expect that people are going to agree with you, or consider
your contribution more correct just because you provided a patch
or a pull request. And don't expect the developer to take long-term
responsibility for changes he doesn't understand, use or approve.

As for new packages, the rules are simple -- someone has to maintain
them. Gentoo is not the kind of zero-maintenance distro where an ebuild
written once is good forever. With the very limited manpower Gentoo
has, don't expect people to just take some random package you use
and maintain it for you if they don't even have any clue what it does.

If you are not going to maintain your contribution, we can't guarantee
it will be accepted. I'm certainly not interested in having to worry
about 20 more maintainer-needed packages next month because someone
contributed an ebuild that seemed good enough.

In this case, less is better than more. A really bad thing is to
provide something new just to have it removed (or became useless)
in a month or so.

-- 
Best regards,
Michał Górny



pgpKi2xKv6zjw.pgp
Description: OpenPGP digital signature