[gentoo-dev] Gentoo Vim needs your help!

[Patrice Clement]

Hi!

I'm the only maintainer left within the Gentoo Vim Project [1] and would need
some help to maintain the vim editor along with the app-vim/ category.

vim and vim packages are low-maintenance: a version bump here, a security fix
there. vim ebuilds aren't that complicated. vim eclasses have to be migrated to
EAPI 8. I would like the eclasses to support neovim at some point too (yeah
it's about time).

It has been suggested to disband the project and return all vim packages to
maintainer-needed since, well, I'm the only person in it. To be honest, I would
like the project structure to remain as-is as I think disbanding the project
may make matters worse.

Feel free to join the #vim IRC channel on irc.libera.chat or respond to this
email if you're interested.

[1]: https://wiki.gentoo.org/wiki/Project:Vim

Cheers

[gentoo-dev] [gentoo-dev-announce] Last rites: app-text/tidy-html5

[Patrice Clement]

# Patrice Clement  (2021-10-09)
# Obsolete and unmaintained. Please switch to app-text/htmltidy.
# Bug #564884. Masked for removal in 30 days.
app-text/tidy-html5

Re: [gentoo-dev] [PATCH] eclass/vim-plugin.eclass: delete if has_version condition.

[Patrice Clement]

Thursday 22 Jul 2021 10:54:02, Patrice Clement wrote :
> ... and replace it with a test against the REPLACING_VERSIONS variable.
> 
> See https://projects.gentoo.org/pms/8/pms.html#x1-10900011.1.
> 
> This is an updated version of the same patch discussed previously on this ML.
> 
> Suggested by Arfrever.
> ---
>  eclass/vim-plugin.eclass | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/eclass/vim-plugin.eclass b/eclass/vim-plugin.eclass
> index 6b72d66111d..460edcce3eb 100644
> --- a/eclass/vim-plugin.eclass
> +++ b/eclass/vim-plugin.eclass
> @@ -126,31 +126,31 @@ update_vim_afterscripts() {
>  display_vim_plugin_help() {
>   local h
>  
> - if ! has_version ${CATEGORY}/${PN} ; then
> - if [[ -n "${VIM_PLUGIN_HELPFILES}" ]] ; then
> + if [[ -z ${REPLACING_VERSIONS} ]]; then
> + if [[ -n ${VIM_PLUGIN_HELPFILES} ]]; then
>   elog " "
>   elog "This plugin provides documentation via vim's help 
> system. To"
>   elog "view it, use:"
> - for h in ${VIM_PLUGIN_HELPFILES} ; do
> + for h in ${VIM_PLUGIN_HELPFILES}; do
>   elog ":help ${h}"
>   done
>   elog " "
>  
> - elif [[ -n "${VIM_PLUGIN_HELPTEXT}" ]] ; then
> + elif [[ -n ${VIM_PLUGIN_HELPTEXT} ]]; then
>   elog " "
>   while read h ; do
>   elog "$h"
>   done <<<"${VIM_PLUGIN_HELPTEXT}"
>   elog " "
>  
> - elif [[ -n "${VIM_PLUGIN_HELPURI}" ]] ; then
> + elif [[ -n ${VIM_PLUGIN_HELPURI} ]]; then
>   elog " "
>   elog "Documentation for this plugin is available online 
> at:"
>   elog "${VIM_PLUGIN_HELPURI}"
>   elog " "
>   fi
>  
> - if has "filetype" "${VIM_PLUGIN_MESSAGES}" ; then
> + if has filetype ${VIM_PLUGIN_MESSAGES}; then
>   elog "This plugin makes use of filetype settings. To 
> enable these,"
>   elog "add lines like:"
>   elog "filetype plugin on"
> -- 
> 2.31.1
> 
> 

Merged. Thanks ulm for the review!

[gentoo-dev] [PATCH] eclass/vim-plugin.eclass: delete if has_version condition.

[Patrice Clement]

... and replace it with a test against the REPLACING_VERSIONS variable.

See https://projects.gentoo.org/pms/8/pms.html#x1-10900011.1.

This is an updated version of the same patch discussed previously on this ML.

Suggested by Arfrever.
---
 eclass/vim-plugin.eclass | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/eclass/vim-plugin.eclass b/eclass/vim-plugin.eclass
index 6b72d66111d..460edcce3eb 100644
--- a/eclass/vim-plugin.eclass
+++ b/eclass/vim-plugin.eclass
@@ -126,31 +126,31 @@ update_vim_afterscripts() {
 display_vim_plugin_help() {
local h
 
-   if ! has_version ${CATEGORY}/${PN} ; then
-   if [[ -n "${VIM_PLUGIN_HELPFILES}" ]] ; then
+   if [[ -z ${REPLACING_VERSIONS} ]]; then
+   if [[ -n ${VIM_PLUGIN_HELPFILES} ]]; then
elog " "
elog "This plugin provides documentation via vim's help 
system. To"
elog "view it, use:"
-   for h in ${VIM_PLUGIN_HELPFILES} ; do
+   for h in ${VIM_PLUGIN_HELPFILES}; do
elog ":help ${h}"
done
elog " "
 
-   elif [[ -n "${VIM_PLUGIN_HELPTEXT}" ]] ; then
+   elif [[ -n ${VIM_PLUGIN_HELPTEXT} ]]; then
elog " "
while read h ; do
elog "$h"
done <<<"${VIM_PLUGIN_HELPTEXT}"
elog " "
 
-   elif [[ -n "${VIM_PLUGIN_HELPURI}" ]] ; then
+   elif [[ -n ${VIM_PLUGIN_HELPURI} ]]; then
elog " "
elog "Documentation for this plugin is available online 
at:"
elog "${VIM_PLUGIN_HELPURI}"
elog " "
fi
 
-   if has "filetype" "${VIM_PLUGIN_MESSAGES}" ; then
+   if has filetype ${VIM_PLUGIN_MESSAGES}; then
elog "This plugin makes use of filetype settings. To 
enable these,"
elog "add lines like:"
elog "filetype plugin on"
-- 
2.31.1

Re: [gentoo-dev] [PATCH] eclass/vim-plugin.eclass: delete if has_version condition.

[Patrice Clement]

Thursday 22 Jul 2021 04:44:39, Sam James wrote :
> 
> 
> > On 21 Jul 2021, at 17:47, Patrice Clement  wrote:
> > 
> > ... and replace it with a test against the REPLACING_VERSIONS variable.
> > 
> > See https://projects.gentoo.org/pms/8/pms.html#x1-10900011.1.
> > 
> > Patch courtesy of Arfrever.
> > 
> 
> Ideally, we'd use Arfrever's sign off, but this is kind of a grey
> area, so it's not a blocker at all right now.
> 
> > Closes: https://github.com/gentoo/gentoo/pull/21733
> > Signed-off-by: Patrice Clement 
> > ---
> > eclass/vim-plugin.eclass | 12 ++--
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/eclass/vim-plugin.eclass b/eclass/vim-plugin.eclass
> > index 6b72d66111d..460edcce3eb 100644
> > --- a/eclass/vim-plugin.eclass
> > +++ b/eclass/vim-plugin.eclass
> > [snip]
> 
> The patch itself seems fine, but I have some suggestions while we're
> working on the eclass:
> 
> - Add EAPI 8 support
> 
> - Please drop obsolete EAPI compatibility hacks like:
> >has "${EAPI:-0}" 0 1 2 && ! use prefix && ED="${D}"
> 
> This is unnecessary because we're only declaring support for EAPI 6 and 7 
> right now.
> 
> - Could you please convert POSIX tests to Bash tests? [0]
> 
> - In update_vim_afterscripts, the einfo seems (at first glance) to be 
> misleading. Should
> it be printing ${afterdir} instead?
> 
> - Ideally, we'd add the standard inherit guard if possible (see e.g. 
> gnuconfig.eclass for a simple example).
> 
> [0] 
> https://devmanual.gentoo.org/tools-reference/bash/#single-versus-double-brackets-in-bash
> 
> Let me know if you need any assistance, etc.
> 
> thanks,
> sam
> 
> 
> 
> 

Thanks for the suggestions. If you don't mind, I'd like to stick to the
original changes for now and address your suggestions later in a follow up
patch.

Best,

Re: [gentoo-dev] [PATCH] eclass/vim-plugin.eclass: delete if has_version condition.

[Patrice Clement]

Wednesday 21 Jul 2021 19:16:36, Ulrich Mueller wrote :
> >>>>> On Wed, 21 Jul 2021, Patrice Clement wrote:
> 
> > +   if [[ -n "${VIM_PLUGIN_HELPFILES}" ]]; then
> 
> Quotation marks are not necessary here (and three more times below,
> in the elif lines).

Thanks, this has been mended.

[gentoo-dev] [PATCH] eclass/vim-plugin.eclass: delete if has_version condition.

[Patrice Clement]

... and replace it with a test against the REPLACING_VERSIONS variable.

See https://projects.gentoo.org/pms/8/pms.html#x1-10900011.1.

Patch courtesy of Arfrever.

Closes: https://github.com/gentoo/gentoo/pull/21733
Signed-off-by: Patrice Clement 
---
 eclass/vim-plugin.eclass | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/eclass/vim-plugin.eclass b/eclass/vim-plugin.eclass
index 6b72d66111d..460edcce3eb 100644
--- a/eclass/vim-plugin.eclass
+++ b/eclass/vim-plugin.eclass
@@ -126,31 +126,31 @@ update_vim_afterscripts() {
 display_vim_plugin_help() {
local h
 
-   if ! has_version ${CATEGORY}/${PN} ; then
-   if [[ -n "${VIM_PLUGIN_HELPFILES}" ]] ; then
+   if [[ -z ${REPLACING_VERSIONS} ]]; then
+   if [[ -n "${VIM_PLUGIN_HELPFILES}" ]]; then
elog " "
elog "This plugin provides documentation via vim's help 
system. To"
elog "view it, use:"
-   for h in ${VIM_PLUGIN_HELPFILES} ; do
+   for h in ${VIM_PLUGIN_HELPFILES}; do
elog ":help ${h}"
done
elog " "
 
-   elif [[ -n "${VIM_PLUGIN_HELPTEXT}" ]] ; then
+   elif [[ -n "${VIM_PLUGIN_HELPTEXT}" ]]; then
elog " "
while read h ; do
elog "$h"
done <<<"${VIM_PLUGIN_HELPTEXT}"
elog " "
 
-   elif [[ -n "${VIM_PLUGIN_HELPURI}" ]] ; then
+   elif [[ -n "${VIM_PLUGIN_HELPURI}" ]]; then
elog " "
elog "Documentation for this plugin is available online 
at:"
elog "${VIM_PLUGIN_HELPURI}"
elog " "
fi
 
-   if has "filetype" "${VIM_PLUGIN_MESSAGES}" ; then
+   if has "filetype" "${VIM_PLUGIN_MESSAGES}"; then
elog "This plugin makes use of filetype settings. To 
enable these,"
elog "add lines like:"
elog "filetype plugin on"
-- 
2.31.1

Re: [gentoo-dev] Add commit to pull request

[Patrice Clement]

Hi Samuel

No you don't have to file a new PR. Basically, you have to:
* commit your code against the branch. At that point, there are two commits (or
more if you commit multiple times) in your branch, or PR if we talk in GH
jargon.
* squash that commit into the previous commit so as to get a single commit.
* force push against said branch: git push -f origin your-awesome-pr.

That's about it.

This article sums up the process pretty well:
https://www.devroom.io/2011/07/05/git-squash-your-latests-commits-into-one/

Cheers,

Sunday 21 Jun 2020 17:48:14, Samuel Bernardo wrote :
> Hi,
> 
> I need to add a commit to a gentoo pull request that I had opened before.
> 
> https://github.com/samuelbernardo/gentoo
> 
> Is it possible to add the commit to that pull request or I need to open
> a new pull request?
> 
> I already try to get help in gentoo-dev channel but I haven't voice there...
> 
> Thanks
> 
>

[gentoo-dev] [gentoo-dev-announce] Package up for grabs: app-office/calcurse

[Patrice Clement]

The following package is now up for grabs:

app-office/calcurse

It needs a bit of care and I don't have time to maintain it properly. See 
#712126.

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] Package up for grabs: net-misc/mosh

[Patrice Clement]

The following package is now up for grabs:

net-misc/mosh

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] [gentoo-dev-announce] Last rites: net-irc/irssi-otr

[Patrice Clement]

# Patrice Clement  (2019-10-02)
# OTR support is fully integrated within irssi since version 1.2.0. Type /help 
otr
# at the command prompt to find out more. The OTR module is therefore obsolete
# and can be tree-cleaned.
# Masked for removal in 30 days. Bug #696074.
net-irc/irssi-otr

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] [gentoo-dev-announce] Package up for grabs: net-im/mattermost-desktop-bin

[Patrice Clement]

Hi

net-im/mattermost-desktop-bin is now up for grabs.

Thanks.

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

Re: [gentoo-dev] Packages up for grabs due to nimiux's retirement

[Patrice Clement]

Monday 20 May 2019 17:53:52, Michał Górny wrote :
> Hello,
> 
> The following packages are now up for grabs:
> 
> [...]
> app-misc/vifm
>
I'm taking over this one.

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] [gentoo-dev-announce] Last rites: media-tv/tvbrowser

[Patrice Clement]

# Patrice Clement  (06 May 2019)
# Broken build. Outdated version. No interest from the Java team to maintain
# it. Removal in 30 days. Bug #581720.
media-tv/tvbrowser

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] [gentoo-dev-announce] Last rites: dev-java/[...], media-sound/jtagger, app-admin/389-console Reply-To:

[Patrice Clement]

# Patrice Clement  (14 Apr 2019)
# Old, unmaintained and sometimes abandoned Java libraries/programs.
# Removal in 30 days.
dev-java/idm-console-framework
dev-java/matrix-toolkits-java
dev-java/sat4j-pseudo
dev-java/sat4j-core
dev-java/swarmcache
dev-java/dbus-java
dev-java/jinklevel
dev-java/proguard
dev-java/nailgun
dev-java/jgroups
dev-java/libmso
dev-java/jicmp
media-sound/jtagger
app-admin/389-console

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] [gentoo-dev-announce] Last rites: dev-java/{echo2,zemberek}.

[Patrice Clement]

# Patrice Clement  (17 Mar 2019)
# Old and unmaintained Java libraries. Removal in 30 days.
dev-java/zemberek
dev-java/echo2

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [PATCH] ant-tasks.eclass: use eapi7-ver

[Patrice Clement]

Tuesday 22 May 2018 13:28:50, Ulrich Mueller wrote :
> >>>>> On Tue, 22 May 2018, Marty E Plummer wrote:
> 
> > How's this?
> > ---
> >  eclass/ant-tasks.eclass | 11 ++-
> >  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> > diff --git a/eclass/ant-tasks.eclass b/eclass/ant-tasks.eclass
> > index e008e6eaea8..31683e68243 100644
> > --- a/eclass/ant-tasks.eclass
> > +++ b/eclass/ant-tasks.eclass
> > @@ -16,7 +16,8 @@
> >  JAVA_ANT_DISABLE_ANT_CORE_DEP=true
> >  # rewriting build.xml for are the testcases has no reason atm
> >  JAVA_PKG_BSFIX_ALL=no
> > -inherit versionator java-pkg-2 java-ant-2
> > +inherit java-pkg-2 java-ant-2
> > +[[ ${EAPI:-0} == [0123456] ]] && inherit eapi7-ver
>  
> >  EXPORT_FUNCTIONS src_unpack src_compile src_install
>  
> > @@ -60,12 +61,12 @@ if [[ ${PV} == *beta2* ]]; then
> > MY_PV=${PV/_beta2/beta}
> > UPSTREAM_PREFIX="http://people.apache.org/dist/ant/v1.7.1beta2/src;
> > GENTOO_PREFIX="https://dev.gentoo.org/~caster/distfiles;
> > -   ANT_TASK_PV=$(get_version_component_range 1-3)
> > +   ANT_TASK_PV=$(ver_cut 1-3)
> >  elif [[ ${PV} == *_rc* ]]; then
> > MY_PV=${PV/_rc/RC}
> > UPSTREAM_PREFIX="https://dev.gentoo.org/~caster/distfiles;
> > GENTOO_PREFIX="https://dev.gentoo.org/~caster/distfiles;
> > -   ANT_TASK_PV=$(get_version_component_range 1-3)
> > +   ANT_TASK_PV=$(ver_cut 1-3)
> >  else
> > # default for final releases
> > MY_PV=${PV}
> > @@ -101,7 +102,7 @@ if [[ -z "${ANT_TASK_DISABLE_VM_DEPS}" ]]; then
> >  fi
>  
> >  # we need direct blockers with old ant-tasks for file collisions - bug 
> > #252324
> > -if version_is_at_least 1.7.1 ; then
> > +if ver_test -ge 1.7.1; then
> > DEPEND+=" !dev-java/ant-tasks"
> >  fi
>  
> > @@ -167,7 +168,7 @@ ant-tasks_src_install() {
> > java-pkg_register-ant-task --version "${ANT_TASK_PV}"
>  
> > # create the compatibility symlink
> > -   if version_is_at_least 1.7.1_beta2; then
> > +   if ver_test -ge 1.7.1_beta2; then
> > dodir /usr/share/ant/lib
> > dosym /usr/share/${PN}/lib/${PN}.jar 
> > /usr/share/ant/lib/${PN}.jar
> > fi
> > -- 
> > 2.17.0
> 
> LGTM

Thanks Marty and Ulrich. LGTM too. I'm going to merge this patch.

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] Packages up for grabs

[Patrice Clement]

Hi gents

The following packages are up for grabs:

app-benchmarks/stress-ng
app-cdr/cdrdao
app-i18n/ibus-cangjie
app-i18n/libcangjie
dev-python/cangjie
dev-embedded/libftd2xx
media-sound/fmit
net-misc/redir
net-misc/s3cmd
net-misc/ser2net
sci-electronics/quartus-prime-lite
sys-apps/intel-performance-counter-monitor
sys-apps/likwid

Best,

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] details on the PMS

[Patrice Clement]

Hi Michael

Saturday 24 Feb 2018 02:48:02, Michael Lienhardt wrote :
> I noticed that the following files are not mentioned, or stated optional in 
> the PMS:
>   - profiles/repo_name
>   - metadata/layout.conf
> 
> It seems to me that without these files, portage complains. Shouldn't them be 
> declared as mandatory?
> 
>   - profiles/package.use and profiles/make.defaults 
> (https://wiki.gentoo.org/wiki/USE_ORDER)
> These files are not documented in the PMS: should the package manager 
> recognize these files? (if so, I think it would be clearer to document them 
> in the PMS)
> 
> Also, in https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-430004.7.1 the 
> directory is named metadata/cache while it is named metadata/md5-cache in my 
> repository.
> 
> 
> Should I report something on the Gentoo Bugzilla?
> 
> Best,
> Michael Lienhardt
> 

Please do.

If the documentation is lacking for these files, it must be fixed ASAP. Thanks
for picking this up!

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

Re: [gentoo-dev] about commits in the future

[Patrice Clement]

Hi Fabian

Every now and then, my commits get rejected from the Gentoo Git server with an
error saying that my clock is behind and that I need to rewind it. I then run
the command `ntpdate europe.pool.ntp.org' to get my clock synced. Eventually, I
rebase my latest commits with git and push to the repo. Something might have
gone wrong during the clock sync and git rebase? I'm not too sure.

Thanks for pointing out this oddity though!

Wednesday 21 Feb 2018 09:47:29, Fabian Groffen wrote :
> Please consider commit 2fb923d758749be609c1daab2a72ad4f1ec4c2a9
> (use something like
>git log --pretty=fuller app-emulation/nemu/nemu-1.4.0.ebuild)
> 
> It was made roughly one day in the future.  I'm wondering:
> 1) is this bad at all?
> 2) if it is bad (got me confused for another reason) is it technically
>possible to reject such commits?
> 3) if 2) should we decide on some clock skew and reject anything which
>is beyond that?
> 
> How do others feel about this?
> 
> Thanks,
> Fabian
> 
> -- 
> Fabian Groffen
> Gentoo on a different level

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

[Patrice Clement]

 +../../../../../../../features/prefix/standalone/beyond-kernel-2.6.32
> diff --git 
> a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi 
> b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi
> new file mode 100644
> index ..7ed6ff82de6b
> --- /dev/null
> +++ 
> b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi
> @@ -0,0 +1 @@
> +5
> diff --git 
> a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent
>  
> b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent
> new file mode 100644
> index ..b3da232ba558
> --- /dev/null
> +++ 
> b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent
> @@ -0,0 +1,2 @@
> +..
> +../../../../../../../features/prefix/standalone
> diff --git a/profiles/default/linux/amd64/17.0/no-multilib/prefix/parent 
> b/profiles/default/linux/amd64/17.0/no-multilib/prefix/parent
> new file mode 100644
> index ..f3229c5b9876
> --- /dev/null
> +++ b/profiles/default/linux/amd64/17.0/no-multilib/prefix/parent
> @@ -0,0 +1 @@
> +..
> diff --git a/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi 
> b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi
> new file mode 100644
> index ..7ed6ff82de6b
> --- /dev/null
> +++ b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi
> @@ -0,0 +1 @@
> +5
> diff --git 
> a/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent 
> b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent
> new file mode 100644
> index ..4372cb6f5834
> --- /dev/null
> +++ b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent
> @@ -0,0 +1,2 @@
> +..
> +../../../../../../features/prefix/standalone/beyond-kernel-2.6.16
> diff --git a/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi 
> b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi
> new file mode 100644
> index ..7ed6ff82de6b
> --- /dev/null
> +++ b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi
> @@ -0,0 +1 @@
> +5
> diff --git 
> a/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent 
> b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent
> new file mode 100644
> index ..ee208c413bf2
> --- /dev/null
> +++ b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent
> @@ -0,0 +1,2 @@
> +..
> +../../../../../../features/prefix/standalone/beyond-kernel-2.6.32
> diff --git a/profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi 
> b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi
> new file mode 100644
> index ..7ed6ff82de6b
> --- /dev/null
> +++ b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi
> @@ -0,0 +1 @@
> +5
> diff --git a/profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent 
> b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent
> new file mode 100644
> index ..b8a505e58f6c
> --- /dev/null
> +++ b/profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent
> @@ -0,0 +1,2 @@
> +..
> +../../../../../../features/prefix/standalone
> diff --git a/profiles/default/linux/x86/17.0/prefix/parent 
> b/profiles/default/linux/x86/17.0/prefix/parent
> new file mode 100644
> index ..f3229c5b9876
> --- /dev/null
> +++ b/profiles/default/linux/x86/17.0/prefix/parent
> @@ -0,0 +1 @@
> +..
> diff --git a/profiles/profiles.desc b/profiles/profiles.desc
> index 2812791936cc..e0683269cc11 100644
> --- a/profiles/profiles.desc
> +++ b/profiles/profiles.desc
> @@ -334,8 +334,14 @@ x86-linuxprefix/linux/x86
> exp
>  # Linux Standalone Profiles
>  amd64-linux  prefix/linux-standalone/amd64   exp
>  amd64-linux  prefix/linux-standalone/amd64/legacyexp
> +amd64-linux  
> default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2   exp
> +amd64-linux  
> default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32exp
> +amd64-linux  
> default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16exp
>  x86-linuxprefix/linux-standalone/x86 exp
>  x86-linuxprefix/linux-standalone/x86/legacy  exp
> +x86-linuxdefault/linux/x86/17.0/prefix/beyond-kernel-3.2 
> exp
> +x86-linuxdefault/linux/x86/17.0/prefix/beyond-kernel-2.6.32  
> exp
> +x86-linuxdefault/linux/x86/17.0/prefix/beyond-kernel-2.6.16  
> exp
>  arm-linuxprefix/linux-standalone/arm/armv7a  exp
>  arm64-linux  prefix/linux-standalone/arm64   exp
>  ppc64-linux  prefix/linux-standalone/ppc64   exp
> -- 
> 2.15.1
> 

Thanks for the work.

Could you also consider adding a Prefix profile compatible with FreeBSD?

Best,

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

Re: [gentoo-dev] Projects up for grabs: cron, m68k

[Patrice Clement]

Wednesday 20 Dec 2017 12:49:18, Anthony G. Basile wrote :
> On 12/20/17 12:07 PM, Anthony G. Basile wrote:
> > On 12/20/17 12:02 PM, Michał Górny wrote:
> >> Hello, everyone.
> >>
> >> Due to prolonged inactivity of Mike Frysinger (vapier), the following
> >> projects have had effectively no members for 6 months already:
> >>
> >> https://wiki.gentoo.org/wiki/Project:Cron
> >>
> >>   sys-process/anacron [m]
> >>   sys-process/at
> >>   sys-process/bcron
> >>   sys-process/cronbase
> >>   sys-process/cronie [m]
> >>   sys-process/dcron
> >>   sys-process/fcron [m]
> >>   sys-process/vixie-cron
> >>   virtual/cron
> >>
> >> https://wiki.gentoo.org/wiki/Project:M68k
> >>
> >>   sys-apps/zorroutils [m]
> >>   sys-fs/atari-fdisk
> >>
> >> The packages listed with '[m]' have other maintainers. The remaining
> >> packages are solely maintained by the listed projects.
> >>
> >> If you are interested in helping out with some of those packages, please
> >> consider joining the appropriate project and/or co-maintaining the
> >> individual packages.
> >>
> >> If the projects see no activity within the next month, I will disband
> >> them and move the appropriate packages to maintainer-needed.
> >>
> > 
> > Those are very important packages.  I use fcron and at and I can help
> > take care of those.  I should probably take a look a t cronbase and
> > virtual/cron too.
> > 
> 
> Okay a followup on my last email, I added myself to the project and will
> try to take care of all cron packages.
> 
> -- 
> Anthony G. Basile, Ph.D.
> Gentoo Linux Developer [Hardened]
> E-Mail: bluen...@gentoo.org
> GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
> GnuPG ID  : F52D4BBA
> 

Hi there

We use fcron a lot at ${work} so I've also added myself to the project in an
attempt to help out with fcron-related bugs.

Cheers

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

[gentoo-dev] [gentoo-dev-announce] Last-rites: app-vim/pam-syntax

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (19 Dec 2017)
# A slightly better syntax file for PAM configuration files is shipped with Vim
# since version 8.0. The one we package is old and out of date.
# Masked for removal in 30 days. See bug 578278.
app-vim/pam-syntax

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

Re: [gentoo-dev] [PATCH 2/3] vim-plugin.eclass: use Portage internal variables.

[Patrice Clement]

Sunday 05 Nov 2017 00:26:33, Michał Górny wrote :
> W dniu sob, 04.11.2017 o godzinie 22∶48 +0100, użytkownik Patrice
> Clement napisał:
> > Closes: https://bugs.gentoo.org/469400
> > ---
> >  eclass/vim-plugin.eclass | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/eclass/vim-plugin.eclass b/eclass/vim-plugin.eclass
> > index a05cdb4520b..3c809768cf8 100644
> > --- a/eclass/vim-plugin.eclass
> > +++ b/eclass/vim-plugin.eclass
> > @@ -39,11 +39,11 @@ vim-plugin_src_install() {
> > ebegin "Fixing file permissions"
> > # Make sure perms are good
> > chmod -R a+rX "${S}" || die "chmod failed"
> > -   find "${S}" -user  'portage' -exec chown root '{}' \; || die 
> > "chown failed"
> > +   find "${S}" -user "${PORTAGE_USERNAME}" -exec chown root '{}' 
> > \; || die "chown failed"
> > if use userland_BSD || [[ ${CHOST} == *-darwin* ]] ; then
> > -   find "${S}" -group 'portage' -exec chgrp wheel '{}' \; 
> > || die "chgrp failed"
> > +   find "${S}" -group "${PORTAGE_GRPNAME}" -exec chgrp 
> > wheel '{}' \; || die "chgrp failed"
> > else
> > -   find "${S}" -group 'portage' -exec chgrp root '{}' \; 
> > || die "chgrp failed"
> > +   find "${S}" -group "${PORTAGE_GRPNAME}" -exec chgrp 
> > root '{}' \; || die "chgrp failed"
> > fi
> > eend $?
> > fi
> 
> This is going to die on every non-Portage package manager.
> 
> -- 
> Best regards,
> Michał Górny
> 
> 

Michal, Ulrich,

ACK. This code has been there for ages and I also don't think it makes sense to
keep it as it seems these operations are handled by Portage already. Mike
(floppym) suggested to remove the whole if clause and call fperms instead:

diff --git a/eclass/vim-plugin.eclass b/eclass/vim-plugin.eclass
index abe9c7b3661..46908bb73e6 100644
--- a/eclass/vim-plugin.eclass
+++ b/eclass/vim-plugin.eclass
@@ -35,19 +35,6 @@ vim-plugin_src_install() {
has "${EAPI:-0}" 0 1 2 && ! use prefix && ED="${D}"
local f

-   if use !prefix && [[ ${EUID} -eq 0 ]] ; then
-   ebegin "Fixing file permissions"
-   # Make sure perms are good
-   chmod -R a+rX "${S}" || die "chmod failed"
-   find "${S}" -user  'portage' -exec chown root '{}' \; || die 
"chown failed"
-   if use userland_BSD || [[ ${CHOST} == *-darwin* ]] ; then
-   find "${S}" -group 'portage' -exec chgrp wheel '{}' \; 
|| die "chgrp failed"
-   else
-   find "${S}" -group 'portage' -exec chgrp root '{}' \; 
|| die "chgrp failed"
-   fi
-   eend $?
-   fi
-
    # When globbing, if nothing exists, the shell literally returns the glob
# pattern. So turn on nullglob and extglob options to avoid this.
eshopts_push -s extglob
@@ -86,7 +73,7 @@ vim-plugin_src_install() {
"couldn't move ${S} to ${ED}/usr/share/vim/vimfiles"

# Fix remaining bad permissions
-   chmod -R -x+X "${ED}"/usr/share/vim/vimfiles/ || die "chmod failed"
+   fperms -R a+rX /usr/share/vim/vimfiles
 }

Please let me know what you guys think.

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

[gentoo-dev] [PATCH 3/3] vim-plugin.eclass: rework if else clause and reduce find calls down to one.

[Patrice Clement]

---
 eclass/vim-plugin.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/vim-plugin.eclass b/eclass/vim-plugin.eclass
index 3c809768cf8..d635a2aa436 100644
--- a/eclass/vim-plugin.eclass
+++ b/eclass/vim-plugin.eclass
@@ -40,11 +40,11 @@ vim-plugin_src_install() {
# Make sure perms are good
chmod -R a+rX "${S}" || die "chmod failed"
find "${S}" -user "${PORTAGE_USERNAME}" -exec chown root '{}' 
\; || die "chown failed"
+   local _grp="root"
if use userland_BSD || [[ ${CHOST} == *-darwin* ]] ; then
-   find "${S}" -group "${PORTAGE_GRPNAME}" -exec chgrp 
wheel '{}' \; || die "chgrp failed"
-   else
-   find "${S}" -group "${PORTAGE_GRPNAME}" -exec chgrp 
root '{}' \; || die "chgrp failed"
+   _grp="wheel"
fi
+   find "${S}" -group "${PORTAGE_GRPNAME}" -exec chgrp "${_grp}" 
'{}' \; || die "chgrp failed"
eend $?
fi
 
-- 
2.13.6

[gentoo-dev] [PATCH 1/3] vim-plugin.eclass: dohtml is now obsolete.

[Patrice Clement]

---
 eclass/vim-plugin.eclass | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/eclass/vim-plugin.eclass b/eclass/vim-plugin.eclass
index abe9c7b3661..a05cdb4520b 100644
--- a/eclass/vim-plugin.eclass
+++ b/eclass/vim-plugin.eclass
@@ -71,11 +71,7 @@ vim-plugin_src_install() {
local f
for f in *; do
[[ -f "${f}" ]] || continue
-   if [[ "${f}" = *.html ]]; then
-   dohtml "${f}"
-   else
-   dodoc "${f}"
-   fi
+   dodoc "${f}"
rm "${f}" || die
done
 
-- 
2.13.6

[gentoo-dev] [PATCH 2/3] vim-plugin.eclass: use Portage internal variables.

[Patrice Clement]

Closes: https://bugs.gentoo.org/469400
---
 eclass/vim-plugin.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/vim-plugin.eclass b/eclass/vim-plugin.eclass
index a05cdb4520b..3c809768cf8 100644
--- a/eclass/vim-plugin.eclass
+++ b/eclass/vim-plugin.eclass
@@ -39,11 +39,11 @@ vim-plugin_src_install() {
ebegin "Fixing file permissions"
# Make sure perms are good
chmod -R a+rX "${S}" || die "chmod failed"
-   find "${S}" -user  'portage' -exec chown root '{}' \; || die 
"chown failed"
+   find "${S}" -user "${PORTAGE_USERNAME}" -exec chown root '{}' 
\; || die "chown failed"
if use userland_BSD || [[ ${CHOST} == *-darwin* ]] ; then
-   find "${S}" -group 'portage' -exec chgrp wheel '{}' \; 
|| die "chgrp failed"
+   find "${S}" -group "${PORTAGE_GRPNAME}" -exec chgrp 
wheel '{}' \; || die "chgrp failed"
else
-   find "${S}" -group 'portage' -exec chgrp root '{}' \; 
|| die "chgrp failed"
+   find "${S}" -group "${PORTAGE_GRPNAME}" -exec chgrp 
root '{}' \; || die "chgrp failed"
fi
eend $?
fi
-- 
2.13.6

[gentoo-dev] [PATCH 0/3] vim-plugin.eclass: improvements.

[Patrice Clement]

Hi

I have put together a few patches to improve the state of the vim-plugin
eclass. One commit solves a long standing bug.

Please review.

Thanks!

Patrice Clement (3):
  vim-plugin.eclass: dohtml is now obsolete.
  vim-plugin.eclass: use Portage internal variables.
  vim-plugin.eclass: rework if else clause and reduce find calls down to
one.

 eclass/vim-plugin.eclass | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

-- 
2.13.6

Re: [gentoo-dev] [PATCH] eutils.eclass: Document optfeature suggests packages not installed

[Patrice Clement]

Hi Chris

Sunday 03 Sep 2017 16:56:08, Chris Mayo wrote :
> ---
> Please consider this clarification of optfeature.
> 
> Chris
> 
>  eclass/eutils.eclass | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
> index fe4339f6b89..f35fa5980d7 100644
> --- a/eclass/eutils.eclass
> +++ b/eclass/eutils.eclass
> @@ -827,8 +827,8 @@ use_if_iuse() {
>  # @FUNCTION: optfeature
>  # @USAGE:   [other atoms]
>  # @DESCRIPTION:
> -# Print out a message suggesting an optional package (or packages) which
> -# provide the described functionality
> +# Print out a message suggesting an optional package (or packages)
> +# not currently installed which provides the described functionality.
>  #
>  # The following snippet would suggest app-misc/foo for optional foo support,
>  # app-misc/bar or app-misc/baz[bar] for optional bar support
> -- 
> 2.13.5
> 
> 

We (Michal Gorny and I) have reviewed your patch and merged it.

Thanks!

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

[gentoo-dev] [PATCH 2/2] vim-spell.eclass: document variables using Gentoo documentation tags.

[Patrice Clement]

---
 eclass/vim-spell.eclass | 37 +++--
 1 file changed, 23 insertions(+), 14 deletions(-)

diff --git a/eclass/vim-spell.eclass b/eclass/vim-spell.eclass
index 1b0f93c264d..8c1b6314ed8 100644
--- a/eclass/vim-spell.eclass
+++ b/eclass/vim-spell.eclass
@@ -68,23 +68,34 @@ RDEPEND="${DEPEND}"
 SRC_URI="mirror://gentoo/${P}.tar.bz2"
 SLOT="0"
 
-if [[ -z "${VIM_SPELL_CODE}" ]] ; then
-   VIM_SPELL_CODE="${PN/vim-spell-/}"
-fi
+# @ECLASS-VARIABLE: DESCRIPTION
+# @DESCRIPTION:
+# Default DESCRIPTION for Vim spell ebuilds.
+: ${DESCRIPTION:="vim spell files: ${VIM_SPELL_LANGUAGE} 
(${VIM_SPELL_LOCALE})"}
 
-DESCRIPTION="vim spell files: ${VIM_SPELL_LANGUAGE} (${VIM_SPELL_CODE})"
+# @ECLASS-VARIABLE: HOMEPAGE
+# @DESCRIPTION:
+# Default HOMEPAGE for Vim spell ebuilds.
+: ${HOMEPAGE:="https://www.vim.org"}
 
-if [[ -z "${HOMEPAGE}" ]] ; then
-   HOMEPAGE="http://www.vim.org/;
-fi
+# @ECLASS-VARIABLE: VIM_SPELL_LOCALE
+# @INTERNAL
+# @DESCRIPTION:
+# Locale for the current ebuild.
+: ${VIM_SPELL_LOCALE:="${PN/vim-spell-/}"}
+
+# @ECLASS-VARIABLE: VIM_SPELL_DIRECTORY
+# @INTERNAL
+# @DESCRIPTION:
+# Path to Vim spell directory files.
+: ${VIM_SPELL_DIRECTORY:="/usr/share/vim/vimfiles/spell/"}
 
 # @FUNCTION: vim-spell_src_install
 # @DESCRIPTION:
 # Install Vim spell files.
 vim-spell_src_install() {
-   target="/usr/share/vim/vimfiles/spell/"
-   dodir "${target}"
-   insinto "${target}"
+   dodir "${VIM_SPELL_DIRECTORY}"
+   insinto "${VIM_SPELL_DIRECTORY}"
 
had_spell_file=
for f in *.spl ; do
@@ -112,15 +123,13 @@ vim-spell_src_install() {
 # Display installed Vim spell files.
 vim-spell_pkg_postinst() {
has "${EAPI:-0}" 0 1 2 && ! use prefix && EROOT="${ROOT}"
-   target="/usr/share/vim/vimfiles/spell/"
echo
elog "To enable ${VIM_SPELL_LANGUAGE} spell checking, use"
-   elog ":setlocal spell spelllang=${VIM_SPELL_CODE}"
+   elog ":setlocal spell spelllang=${VIM_SPELL_LOCALE}"
echo
elog "The following (Vim internal, not file) encodings are supported 
for"
elog "this language:"
-   for f in "${EROOT}/${target}/${VIM_SPELL_CODE}".*.spl ; do
-   enc="${f##*/${VIM_SPELL_CODE}.}"
+   for f in "${EROOT}/${VIM_SPELL_DIRECTORY}/${VIM_SPELL_LOCALE}".*.spl ; 
do enc="${f##*/${VIM_SPELL_LOCALE}.}"
enc="${enc%.spl}"
[[ -z "${enc}" ]] && continue
elog "${enc}"
-- 
2.13.0

[gentoo-dev] [PATCH 1/2] vim-spell.eclass: document functions using Gentoo documentation tags.

[Patrice Clement]

---
 eclass/vim-spell.eclass | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/eclass/vim-spell.eclass b/eclass/vim-spell.eclass
index 0a3ef952a87..1b0f93c264d 100644
--- a/eclass/vim-spell.eclass
+++ b/eclass/vim-spell.eclass
@@ -1,12 +1,13 @@
-# Copyright 1999-2011 Gentoo Foundation
+# Copyright 1999-2017 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
-#
-# Original Author: Ciaran McCreesh 
-# Maintainers: Vim Herd 
-# Purpose: Simplify installing spell files for vim7
-#
-
+# @ECLASS: vim-spell.eclass
+# @MAINTAINER:
+# Vim Maintainers 
+# @AUTHOR:
+# Ciaran McCreesh 
+# @BLURB: Eclass for managing Vim spell files.
+# @DESCRIPTION:
 # How to make a vim spell file package using prebuilt spell lists
 # from upstream (${CODE} is the language's two letter code):
 #
@@ -21,9 +22,9 @@
 #
 # * Upload the tarball to the Gentoo mirrors.
 #
-# * (for now) Add your spell file to package.mask next to the other vim7
-#   things. The vim herd will handle unmasking your spell packages when vim7
-#   comes out of package.mask.
+# * Add your spell file to package.mask next to the other vim things. Vim
+#   Project members will handle unmasking your spell packages when vim comes 
out
+#   of package.mask.
 #
 # * Create the app-vim/vim-spell-${CODE} package. You should base your ebuild
 #   upon app-vim/vim-spell-en. You will need to change VIM_SPELL_LANGUAGE,
@@ -52,7 +53,7 @@
 # Don't forget to update your package as necessary.
 #
 # If there isn't an upstream-provided pregenerated spell file for your language
-# yet, read :help spell.txt from inside vim7 for instructions on how to create
+# yet, read :help spell.txt from inside vim for instructions on how to create
 # spell files. It's best to let upstream know if you've generated spell files
 # for another language rather than keeping them Gentoo-specific.
 
@@ -77,6 +78,9 @@ if [[ -z "${HOMEPAGE}" ]] ; then
HOMEPAGE="http://www.vim.org/;
 fi
 
+# @FUNCTION: vim-spell_src_install
+# @DESCRIPTION:
+# Install Vim spell files.
 vim-spell_src_install() {
target="/usr/share/vim/vimfiles/spell/"
dodir "${target}"
@@ -103,6 +107,9 @@ vim-spell_src_install() {
[[ -z "${had_spell_file}" ]] && die "Didn't install any spell files?"
 }
 
+# @FUNCTION: vim-spell_pkg_postinst
+# @DESCRIPTION:
+# Display installed Vim spell files.
 vim-spell_pkg_postinst() {
has "${EAPI:-0}" 0 1 2 && ! use prefix && EROOT="${ROOT}"
target="/usr/share/vim/vimfiles/spell/"
-- 
2.13.0

[gentoo-dev] [PATCH 0/2] vim-spell.eclass: improvements.

[Patrice Clement]

Hi everyone

I'm working on solving https://bugs.gentoo.org/469414 but realised much of the
eclass documentation isn't up to our standards. Here's a few commits to fix
that oversight.

Please review.

Thanks!

Patrice Clement (2):
  vim-spell.eclass: document functions using Gentoo documentation tags.
  vim-spell.eclass: document variables using Gentoo documentation tags.

 eclass/vim-spell.eclass | 66 ++---
 1 file changed, 41 insertions(+), 25 deletions(-)

-- 
2.13.0

Re: [gentoo-dev] New package neomutt

[Patrice Clement]

-xsl-stylesheets
> + || ( www-client/lynx www-client/w3m www-client/elinks )
> + )"
> +RDEPEND="${CDEPEND}
> + selinux? ( sec-policy/selinux-mutt )
> +"
> +
> +S="${WORKDIR}/${PN}-${P}"
> +
> +src_prepare() {
> + eapply_user
> + eautoreconf
> +}
> +
> +src_configure() {
> + local myconf=(
> + "$(use_enable crypt pgp)"
> + "$(use_enable debug)"
> + "$(use_enable doc)"
> + "$(use_enable gpg gpgme)"
> + "$(use_enable nls)"
> + "$(use_enable smime)"
> + "$(use_enable notmuch)"
> + "$(use_with idn)"
> + "$(use_with kerberos gss)"
> + "--with-$(use slang && echo slang || echo 
> curses)=${EPREFIX}/usr"
> + "--sysconfdir=${EPREFIX}/etc/${PN}"
> + "--with-docdir=${EPREFIX}/usr/share/doc/${PN}-${PVR}"
> + )
> +
> + if [[ ${CHOST} == *-solaris* ]] ; then
> + # arrows in index view do not show when using wchar_t
> + myconf+=( "--without-wc-funcs" )
> + fi
> +
> + # mutt prioritizes gdbm over bdb, so we will too.
> + # hcache feature requires at least one database is in USE.
> + local hcaches=(
> + "tokyocabinet"
> + "qdbm"
> + "gdbm"
> + "berkdb:bdb"
> + )
> + local ucache hcache lcache
> + for hcache in "${hcaches[@]}" ; do
> + if use ${hcache%%:*} ; then
> + ucache=${hcache}
> + break
> + fi
> + done
> + for hcache in "${hcaches[@]}" ; do
> + [[ ${hcache} == ${ucache} ]] \
> + && myconf+=( "--with-${hcache#*:}" ) \
> + || myconf+=( "--without-${hcache#*:}" )
> + done
Can you simplify this code a little?

> +
> + # there's no need for gnutls, ssl or sasl without socket support
> + if use gnutls; then
> + myconf+=( "--with-gnutls" )
> + elif use ssl; then
> + myconf+=( "--with-ssl" )
> + fi
> + # not sure if this should be mutually exclusive with the other two
> + myconf+=( "$(use_with sasl)" )
> +
> + if use mbox; then
> + myconf+=( "--with-mailpath=${EPREFIX}/var/spool/mail" )
> + else
> + myconf+=( "--with-homespool=Maildir" )
> + fi
> +
> + econf "${myconf[@]}" || die "configure failed"
econf dies on its own, please nix || die.

> +}
> +
> +src_install() {
> + emake DESTDIR="${D}" install || die "install failed"
> + if use mbox; then
> + insinto /etc/neomutt
> + newins "${FILESDIR}"/Muttrc.mbox Muttrc
> + else
> + insinto /etc/neomutt
> + doins "${FILESDIR}"/Muttrc
> + fi
> +
> + # A newer file is provided by app-misc/mime-types. So we link it.
> + rm "${ED}"/etc/${PN}/mime.types
Please append || die here.

> + dosym /etc/mime.types /etc/${PN}/mime.types
> +
> + # A man-page is always handy, so fake one
> + if use !doc; then
> + emake -C doc DESTDIR="${D}" muttrc.man || die
emake dies on its own.

> + # make the fake slightly better, bug #413405
> + sed -e 
> 's#@docdir@/manual.txt#http://www.mutt.org/doc/devel/manual.html#' \
> + -e 's#in @docdir@,#at http://www.mutt.org/,#' \
> + -e "s#@sysconfdir@#${EPREFIX}/etc/${PN}#" \
> + -e "s#@bindir@#${EPREFIX}/usr/bin#" \
> + doc/mutt.man > mutt.1
Ditto, append || die here as well.

> + cp doc/muttrc.man muttrc.5
Ditto.

> + doman mutt.1 muttrc.5
> + else
> + # nuke manpages that should be provided by an MTA, bug #177605
> + rm "${ED}"/usr/share/man/man5/{mbox,mmdf}.5 \
> + || ewarn "failed to remove files, please file a bug"
> + fi
> +
> + dodoc COPYRIGHT ChangeLog.md OPS* README*
> +}
> -- 
> 2.13.0
> 
> 
> -- 
> Nicolas Bock <nicolasb...@gentoo.org>



-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] vim-syntax USE flag

[Patrice Clement]

Hi Mike

Saturday 22 Jul 2017 16:27:39, Mike Gilbert wrote :
> Packages currently handle installation of vim syntax support files
> inconsistently. Some builds install the files if the "vim-syntax" USE
> flag is enabled, while others install them unconditionally.
> 
> Do these files fall into the "small text files" category for
> unconditional installation? If so, we should probably phase out the
> vim-syntax USE flag.
> 
> If we want to keep the USE flag, I would suggest documenting a global
> policy regarding its use. Should that live in the devmanual? Or maybe
> the Vim project page?
> 

Do you have a list handy of packages installing the vim syntax files
unconditionally? I can look into this issue.

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

[gentoo-dev] Re: [RFC] NeoVim and vim-syntax

[Patrice Clement]

Hi Vadim and thank for your email.

Sorry for taking so long to respond, been busy with work, life, etc.

Thursday 01 Jun 2017 02:32:24, Vadim A. Misbakh-Soloviov wrote :
> Currently, we have a situation, that there are two Vim's: "old" one (vim8) 
> and 
> NeoVim (for those who do not know: a fork of Vim with much and much more 
> clean 
> code, many neat features and so on).
Vim8 is here to stay and has served us well until now. Calling him "old" is
unfair. :)

To be honest, I haven't given NeoVim a try yet (should I?).
> 
> Unfortunately, both of them have different runtimedirs: XDG ones for NeoVim 
> and the ones you know for Vim8, while NeoVim is fully compatible with Vim's 
> plugins, and epecially with vimscripts (like syntax definitions and ftdetect 
> scripts).
ACK. I have one question though: will this retrocompatibility last forever?

> 
> On the other side, we have a bunch of packages in the portage tree, that have 
> "vim syntax" support (use-flags, or direct vim-syntax packages), or even vim-
> plugins.
> All of them goes to `/usr/share/vim/vimfiles`, while correct path for NeoVim 
> would be `/usr/share/nvim/site` (does not exist at the moment, but nvim 
> checks 
> for it).
That's good to know.
> 
> So, that situation leads to impossibility to get all of that syntax 
> definitions 
> and plugins when user uses NeoVim.
> 
> As I said above, NeoVim supports Vim's plugins/scripts very well (although I 
> didn't find any evidence of the opposite), so it is possible to fix that 
> situation by many of "kludge" ways, including:
> 
> - implementing "nvim-syntax" (and `app-nvim/*`?) and duplicate all the 
> installed files
This sounds like a lot of duplicate work for very little gain.
> 
> - patching NeoVim source to include Vim's runtimedirs (incl. "after" dir),
> // NeoVim upstream highly disagree with such way, if any
Very appealing.

Why is NeoVim upstream against this solution by the way? Truth to be told, we
can have it our way and patch NeoVim so that it behaves however we like.
> 
> - patching VIMRUNTIME environment variable,
Who would need patching in this case: NeoVim or Vim8?
> 
> - making a wrapper,
A good approach as well. Will need a bit of maintainenance.
> 
> - rewrite all the existing ebuilds to take nvim into account and force all 
> newcomers to also take it,
Too much work.
> 
> - symlinking a directory,
> // mostly bad way, since opposite plugin compatibility is not garanteed and 
> users can install nvim-only plugins in the future
idea--
> 
> - making postinst hook to regenerate content of NeoVim's site-directory 
> (maybe, by symlinking installed vim modules there)
Ew.
> 
> or even:
> 
> - making eselect module for user to rule that.
> 
> Although, talking on eselect module, I've two visions of the situation:
> a) it can be something like bashcomp module, where users can select which of 
> installed vim modules they want to "enable" in NeoVim
> or (better, imo) way:
> b) it can be something like php module, where portage installs all the stuff 
> in the location neither available to Vim nor NeoVim, and users selects which 
> modules they enable for either implementation.
> 
> Module can be called something like "eselect-vim" or "eselect-vim-modules" 
> (?), if any.
To be honest, the eselect idea looks very convoluted. Why?

Please correct me if I'm wrong but by design, most, of not all, modules can be
enabled or disabled via the .vimrc file. It only takes a single line in your
personal .vimrc file if you wish a module not to load at runtime. I fail to see
the added value of an eselect module for solving a task Vim already handles
very well.
> 
> 
> For now, I have preview of neither of eselect module variants, nor even 
> patches for another "ways". I'd very like to discuss the situation and find a 
> better of possible solution first.
> Maybe, when (if?) we found such a solution, I'd contribute a PR with it on GH.
> 
> --
> wbr,
> mva

So here you have it. I'm fine with knocking together a wrapper or patching
NeoVim sources. Do you think it's a big deal to put NeoVim modules in the
app-vim category? It makes more sense to me to keep everything under the same
umbrella.

Cheers
-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

[gentoo-dev] [gentoo-dev-announce] Last rites: dev-java/jdbc-jaybird

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (20 Jun 2017)
# Fails to build with Java 8. Project is active on Github yet ebuild has never
# been marked stable.
# Masked for removal in 30 days.
dev-java/jdbc-jaybird

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

[gentoo-dev] Last rites: dev-java/jaxme

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (07 Apr 2017)
# Part of the JDK since Java 6. Removal in 30 days.
dev-java/jaxme

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

[gentoo-dev] [gentoo-dev-announce] Last rites: dev-java/swing-worker

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (28 Mar 2017)
# Part of the JRE since Java 6. Removal in 30 days.
dev-java/swing-worker

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] [gentoo-dev-announce] Last rites: dev-java/swidgets

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (18 Mar 2017)
# Does not compile anymore. Upstream dead.
# Removal in 30 days.
dev-java/swidgets

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

[gentoo-dev] Last rites: dev-java/jusb

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (11 Mar 2017)
# Upstream dead: no update since 2003. Ebuild is outdated and buggy.
# Removal in 30 days. Bug #279088
dev-java/jusb

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[Patrice Clement]

Friday 02 Dec 2016 14:10:27, Michał Górny wrote :
> Hi, everyone.
> 
> I've heard multiple times about various tinderbox projects being
> started by individuals in Gentoo. In fact, so many different projects
> that I've forgotten who was working on most of them.
> 
> I know that Toralf is doing tinderboxing for most of the stuff.
> What other projects do we have there? What is their status?
> 
> Is there anything we could try to integrate with pull requests to get
> a better testing?
> 
> -- 
> Best regards,
> Michał Górny
> <http://dev.gentoo.org/~mgorny/>

Continuous integration is all the rage these days and tinderboxing is the
obvious way to go concerning Gentoo. AFAIK, Toralf is the only contributor
doing tinderboxing out of his own will. In reality, we should have a team of
devs looking after our own tinderboxes instead of relying on the community.

I'm wondering if we could start a donation campain for this project and ask
people if they've got spare machines laying around. I know a lot of folks are
reading this mailing list so maybe asking on gentoo-dev first for a start would
be appropriate.

Otherwise, can the Foundation sponsor the purchase of a couple of servers?

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

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

[Patrice Clement]

Hello fellow Gentoo developers and subscribers of the gentoo-dev mailing list,

I've been wanting to write this email for a while but for some reason never got
round to doing it due to lack of motivation and time. 

I will be discussing many topics in this email revolving around git
essentially. I first want to go over some basic concepts about git and GitHub
and why we should be doing things differently if we want to avoid cluttering up
our repository with useless stuff.

* Background

As you know, a little while ago we've migrated the main tree to git, the
revision control tool which needs no introduction. A few months after the
migration, our repository was mirrored over to GitHub to give the project a bit
more exposure to what some developers refers to as "the GitHub generation". The
response from the community was extordinary and as a result, a massive number
of Pull Requests came our way. We soon then started to lend ourselves to the
duty of PR triaging and merging, and started to make what's called in the git
world "merge commits". Understanding merge commits requires understanding how
GitHub considers a contribution. 

When a contributor sends a PR via GitHub, he will essentially be making a
different branch, start working on it and eventually file it. For those of you
familiar with git or who've already filed PRs on GitHub, this is old news.
However, there's a number of different way to deal with PRs on the receiving
end (us) in order to keep a sane log history (graph actually).

When we first started working with git, and GitHub, the tendency was to rely on
merge commits to merge contributions back into the main repo. In my opinion,
this was, and still is, a bad idea. What's so special about merge commits? 

* A short walk through merge commits

As you may know, merging one branch into another often results in creating a
new commit. This commit is called a "merge commit" in git jargon. Let's pick
for instance cf4cce36684de5e449ec60bde3421fa0e27bac74. I'm not trying to put
the blame on a particular developer, we've all used merge commits at one point
or another and I was one of the first! In the log graph, this commit is
displayed as such:

$ git log --graph --oneline master
[snip]
* | |   cf4cce3 Merge remote-tracking branch 'github/pr/1845'
|\ \ \
| * | | abf61de net-im/ejabberd: require https://github.com/gentoo/gentoo/pull/1234.patch

Once fetched, using your favourite web crawler, the patch can be directly
applied via the git am command onto HEAD of the repository you're dealing with.
There's this common idiom for fetching AND applying at patch all at once:

$ curl https://github.com/gentoo/gentoo/pull/1234.patch | git am

* This is where I'm meant to sell you my solution

Ultimately, I've decided to write a tool to leverage this way of fetching PRs
and merging them. The tool is called Gentoo-App-Pram and is available in the
tree:

# emerge Gentoo-App-Pram

It is written in Perl, works fairly well and has been used by a fair (growing?)
number of developers so far. The tool is CLI-based so you will need to feel at
home with the command line.

Once emerged, cd into your Gentoo git repo and type `pram' followed by the PR
number you wish to merge:

$ cd /home/patrice/gentoo
$ pram 1234

pram will then fetch the PR as a patch and display it to you in your
favourite $EDITOR. At this point, you can make any change to the PR i.e.
editing commit message(s), changing code in-line, etc. 

pram also leverages the "Closes:" header. This header is recognised by GitHub,
and Larry the Cow, and will automatically close a PR when parsing it in the
body of a commit message. So for instance, the following header will
automatically close PR 1234: "Closes: 
https://github.com/gentoo/gentoo/pull/1234;.
You don't need to manually add it as pram will do this for you.

After saving and getting out of $EDITOR, pram will ask you whether the PR needs
merging by asking a yes/no question. "y" will launch git am and merge the
patch whereas "n" will abort the operation and clean it up.

That's pretty much it. Make sure to read the man page since there are other
options available (pram --man).

pram wouldn't have been possible without Kent Fredric's help. He's assisted me
in releasing the package on CPAN and contributed a few patches. Kudos to him!

To wrap up:
- Please stop making merge commits. This strategy is not useful in the case of
  Gentoo and does more harm than good.
- Cherry-pick or git-am external contributions such as PRs.
- Better yet, use Gentoo-App-Pram. :-)

If you want to contribute to Gentoo-App-Pram, send me a PR on GitHub at
https://github.com/monsieurp/Gentoo-App-Pram or file a bug report at
https://bugs.gentoo.org and assign it to me.

Comments and suggestions welcome.

Cheers,

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] Local workarounds with no reported bugs

[Patrice Clement]

Monday 17 Oct 2016 09:23:09, Michał Górny wrote :
> Hello, everyone.
> 
> I'd like to point out a major problem in Gentoo: there's a fair number
> of developers who add various local workarounds to problems they meet
> and don't bother to report a bug. Worst than that, this applies not
> only for upstream problems but also to Gentoo eclass/ebuild-related
> issues.
>
> --8<--snip--8<--snip--8<--snip--8<--snip--8<--
>
> Therefore, I'd like to request establishing an official policy against
> workarounds with no associated bug reports.
> 
> Your thoughts?
> 
> -- 
> Best regards,
> Michał Górny
> <http://dev.gentoo.org/~mgorny/>

Michal

You're being emotional in my opinion and as a result, are painting *all* Gentoo
developers with a broad brush. Relax. We don't need yet another policy to "fix"
two problems you've encountered, this sounds silly. To be honest, I don't
understand your 2nd example: a change was made in an eclass and as all eclass
changes, these need to be discussed either here on the mailing list or via IRC.
You seem to be maintainer of git-r3; who made the commit? did you sign off
on it? if not, why was it merged? etc. Give us a bit more context please. Your
message looks more like a rant rather than a rational proposal.

Cheers,

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: dev-python/pylons*

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (10 Oct 2016)
# Note from upstream (https://github.com/Pylons/pylons):
# Pylons has merged with repoze.bfg, and is now in maintenance-only mode. It's
# highly recommended that new projects start with the new merged web framework,
# pyramid. Masked for removal in 30 days.
dev-python/pylons-sphinx-themes
dev-python/pylons

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: dev-java/jmf-bin

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (09 Oct 2016)
# Although still available for download, the JMF API is a dead project which
# hasn't been updated in years and hence very old.
# Masked for removal in 30 days.
dev-java/jmf-bin

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] [gentoo-dev-announce] Last rites: dev-libs/vrb

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (10 Sep 2016)
# Upstream dead. This package tries very hard to outsmart autotools and
# reinvent the wheel by coming up with its own configure script. A complete
# disaster resulting in a gigantic wave of QA errors.
# Masked for removal in 30 days.
dev-libs/vrb

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] app-text/htmltidy: Maintainer Request

[Patrice Clement]

Sunday 05 Jun 2016 19:39:26, Yury German wrote :
> app-text/htmltidy currently has no maintainers. It has a vulnerability
> [Security Bug] filed against it. And a number of other [package depend
> on it]. Is nyone willing to pick it up?
> 
> [Secuity Bug]
> https://bugs.gentoo.org/show_bug.cgi?id=561452
> 
> [package depend on it]
> https://qa-reports.gentoo.org/output/genrdeps/dindex/app-text/htmltidy
> https://qa-reports.gentoo.org/output/genrdeps/rindex/app-text/htmltidy
> 
> __
> Yury German
> GLSA Coordinator | Gentoo Security Team
> Administrator| Planet Gentoo
> Email: bluekni...@gentoo.org
> 
> GPG Fingerprint: 8858 89D6 C0C4 75C4 D0DD  FA00 EEAF ED89 024C 043
>

Don't bother. Have a look at [1], [2] & [3] to find out why.

tl;dr

htmltidy has got to be culled at some point since it's now considered obsolete
after tidy-html5 entered the tree a little while ago. It's roughly the same
codebase yet it's HTML 5 compliant. Yay!

I've been maintaining the latter since its inclusion in the Portage tree but
would definitely need help to remove the former. I didn't swap htmltidy for
tidy-html5 cause they're two different projects. As you can see from the links
above, htmltidy has a gazillion deps.

[1]: http://tidy.sourceforge.net/
[2]: http://www.html-tidy.org/
[3]: https://github.com/htacg/tidy-html5

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

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

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (5 Jun 2016)
# Unmaintained ebuilds. Upstream is either dead or AWOL. Also, most of these
# ebuilds are still sitting in ~arch after years in the tree.
# Masked for removal in 30 days.
dev-util/ccmalloc
dev-util/dwarves
dev-util/tinlink
dev-util/cdecl
dev-util/redet
dev-util/eggy
dev-util/mock
dev-util/par
dev-util/injectso
dev-util/dissembler
dev-util/ghh
dev-util/lsuio
dev-util/rec
dev-util/usb-robot
dev-util/jif
dev-util/httpup
dev-util/crow-designer
dev-util/qdevelop
dev-util/intel2gas
dev-util/webcpp
dev-util/as11
dev-util/duma
dev-util/filepp
dev-util/pretrace
dev-util/ald
dev-util/kdoc
dev-util/skelgen
dev-util/ftncheck

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] [gentoo-dev-announce] Last rites: dev-util/{osdt,weblint}

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (2 Jun 2016)
# Ancient software (1996!). Unmaintained.
# Masked for removal in 30 days.
dev-util/weblint

# Patrice Clement <monsie...@gentoo.org> (2 Jun 2016)
# Dead upstream. No release since 2009.
# Masked for removal in 30 days.
dev-util/osdt

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

Re: [gentoo-dev] [PATCH] git-r3.eclass: Support EGIT_SUBMODULES to filter used submodules, #497164

[Patrice Clement]

Monday 23 May 2016 21:54:19, Michał Górny wrote :
> ---
>  eclass/git-r3.eclass | 53 
> +++-
>  1 file changed, 52 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
> index 957ff08..61218a8 100644
> --- a/eclass/git-r3.eclass
> +++ b/eclass/git-r3.eclass
> @@ -165,6 +165,36 @@ fi
>  #
>  # EGIT_CHECKOUT_DIR=${WORKDIR}/${P}
>  
> +# @ECLASS-VARIABLE: EGIT_SUBMODULES
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# An array of inclusive and exclusive wildcards on submodule names,
> +# stating which submodules are fetched and checked out. Exclusions
> +# start with '-', and exclude previously matched submodules.
> +#
> +# If unset, all submodules are enabled. Empty list disables all
> +# submodules. In order to use an exclude-only list, start the array
> +# with '*'.
> +#
> +# Remember that wildcards need to be quoted in order to prevent filename
> +# expansion.
> +#
> +# Examples:
> +# @CODE
> +# # Disable all submodules
> +# EGIT_SUBMODULES=()
> +#
> +# # Include only foo and bar
> +# EGIT_SUBMODULES=( foo bar )
> +#
> +# # Use all submodules except for test-* but include test-lib
> +# EGIT_SUBMODULES=( '*' '-test-*' test-lib )
> +# @CODE
> +if [[ ${EGIT_SUBMODULES[@]+1} && $(declare -p EGIT_SUBMODULES) != "declare 
> -a"* ]]
> +then
> + die 'EGIT_SUBMODULES must be an array.'
> +fi
> +
>  # @FUNCTION: _git-r3_env_setup
>  # @INTERNAL
>  # @DESCRIPTION:
> @@ -243,7 +273,8 @@ _git-r3_env_setup() {
>   if [[ ${EGIT_HAS_SUBMODULES} ]]; then
>   eerror "EGIT_HAS_SUBMODULES has been removed. The eclass no 
> longer needs"
>   eerror "to switch the clone type in order to support submodules 
> and therefore"
> - eerror "submodules are detected and fetched automatically."
> + eerror "submodules are detected and fetched automatically. If 
> you need to"
> + eerror "disable or filter submodules, see EGIT_SUBMODULES."
>   die "EGIT_HAS_SUBMODULES is no longer necessary."
>   fi
>  
> @@ -357,6 +388,26 @@ _git-r3_set_submodules() {
>   l=${l#submodule.}
>   local subname=${l%%.url=*}
>  
> + # filter out on EGIT_SUBMODULES
> + if declare -p EGIT_SUBMODULES &>/dev/null; then
> + local p res= l_res

Watch out for the extra space.

> + for p in "${EGIT_SUBMODULES[@]}"; do
> + if [[ ${p} == -* ]]; then
> + p=${p#-}
> + l_res=
> + else
> + l_res=1
> + fi
> +
> + [[ ${subname} == ${p} ]] && res=${l_res}
> + done
> +
> + if [[ ! ${res} ]]; then
> + einfo "Skipping submodule \e[1m${subname}\e[22m"
> + continue
> + fi
> + fi
> +
>   # skip modules that have 'update = none', bug #487262.
>   local upd=$(echo "${data}" | git config -f /dev/fd/0 \
>   submodule."${subname}".update)
> -- 
> 2.8.3
> 
> 

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place

[Patrice Clement]

Thursday 19 May 2016 23:08:05, Mike Frysinger wrote :
> On 18 May 2016 22:25, aide...@gentoo.org wrote:
> > awk doesn't have the -i option like sed and if editing file in place is
> > desired, additional steps are required. eawk uses tmp file to make it
> > look to the caller editing happens in place.
> 
> what's your real use case ?  i've never once thought "man, i wish i could
> run an awk script and modify a file in place".  and i write awk most days.
> -mike

Same question. Why would you ever want to run awk and have it in-place edit a
file? Have you ever heard about Perl? In place editing a file with it is as
easy as ABC:

$ perl -i'' -ne 's/foo/bar/g;' file.txt

And you're done. If you don't fancy Perl, you could use Ruby with the exact
same syntax and it works just as well. Then add either of these to DEPEND and
you're set.

Please walk us through why you actually want this function to be added cause I
read this thread and your diff like 10 times and couldn't come up with a
sensible reason which would justify this change.

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] On banning merge commits

[Patrice Clement]

Hi gents

After yet another discussion about git in the #gentoo-dev channel tonight, the
topic of merge commits came up for the umpteenth time.

We all seem to agree merge commits are really bad design, add clutter to the
log graph after a while and should be banned altogether from reaching the
central repository.

As of now, no policy is in place yet to keep developers from pushing merge
commits.

What is the correct course of action? I would very much like it to be worded in
a document (GLEP and/or Wiki page) so that confusion is avoided and we all are
on the same page on this topic.

Cheers,

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: dev-java/freehep-*

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (17 Apr 2016)
# Unmaintained ebuilds (EAPI 0!) which don't compile with Java 8.
# Removal in 30 days. See bug 580094.
dev-java/freehep-export
dev-java/freehep-graphics2d
dev-java/freehep-graphicsio
dev-java/freehep-graphicsio-emf
dev-java/freehep-graphicsio-java
dev-java/freehep-graphicsio-pdf
dev-java/freehep-graphicsio-ps
dev-java/freehep-graphicsio-svg
dev-java/freehep-graphicsio-swf
dev-java/freehep-graphicsio-tests
dev-java/freehep-io
dev-java/freehep-mcfio
dev-java/freehep-misc-deps
dev-java/freehep-parameterdatabase
dev-java/freehep-record
dev-java/freehep-rootio
dev-java/freehep-rtti
dev-java/freehep-sio
dev-java/freehep-stdhep
dev-java/freehep-swing
dev-java/freehep-util
dev-java/freehep-xdr
dev-java/freehep-xml

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: dev-vcs/stat{svn,cvs}

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (14 Mar 2016)
# No activity nor release since 2010. Does not compile with Java 8.
# Masked for removal. See bug 577368.
dev-vcs/statsvn
dev-vcs/statcvs

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: java-virtuals/jaxp && dev-java/jax{p,b,-ws,-ws-api,r} && dev-java/jsr93

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (09 Feb 2016)
# Old, ancient, deprecated, obsolete.. so many adjectives could describe these
# ebuilds. Let's just say it's about time to kiss them goodbye.
# Masked for removal in 30 days. See bug 566232.
java-virtuals/jaxp-virtual
dev-java/jaxp
dev-java/jaxb
dev-java/jax-ws
dev-java/jax-ws-api
dev-java/jaxr
dev-java/jsr93

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] Automatic Bug Assignment

[Patrice Clement]

Saturday 30 Jan 2016 11:45:48, Alex Brandt wrote :
> Hey Guys,
> 
> I've oft wondered why we don't automatically assign bugs to the 
> ebuild maintainer (if a CPV is in the subject).  Would there be an 
> issue with adding a bug modification hook to bugzilla or a daily 
> job to re-assign bugs to ebuild owners (if a CPV is in the 
> subject)?
> 
> Just curious not trying to incite anything.
> 
> Regards,
> 
> -- 
> Alex Brandt
> Software Developer for Rackspace and Developer for Gentoo
> http://blog.alunduil.com

Alex

I like your idea (I tought about it a while ago but never bothered raising the
issue on the gentoo-dev ML). So I looked around on the Internet to see if
there's another open source project like Gentoo who ran into a similar issue
with Bugzilla.

And it turns out there is (!).

Context: the FreeBSD project recently ditched GNATS in favour of Bugzilla [1].

FreeBSD devs now make heavy use of the bug tracker and like us, they try to
optimise Bugzilla and fine-tune it as best as they can. And like us, they ran
into this similar issue: how to automatically assign bugs. So they put together
a Bugzilla extension to fix this problem. Code is available here [2]. Since
it's already been implemented, no need to reinvent the wheel, we can find
inspiration through their code.

However, I'm not familiar at all with this code. If you have questions or want
to find out more, don't ask me, ask them! FreeBSD devs hang out in
#freebsd-bugs on freenode (at least the Bugzilla team). They've been really
helpful so far and are a delight to talk to. 

[1]: https://lists.freebsd.org/pipermail/freebsd-announce/2014-June/001559.html
[2]: 
https://github.com/freebsd/bugzilla/tree/freebsd-local/extensions/FBSDAutoAssign

Cheers,

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: net-libs/iojs

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (08 Feb 2016)
# iojs and nodejs merged and formed the new major version nodejs 4.0. iojs will
# not be maintained after 3.3.x and all users are suggested to move to nodejs 4
# (or newer) as quick as possible to avoid any security-related issues.
# Masked for removal in 30 days. See bug 573870.
net-libs/iojs

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] games.eclass policy

[Patrice Clement]

Sunday 07 Feb 2016 11:38:27, M.B. wrote :
> 
> Hello folks.
> 
> While hacking away on a new ebuild I came across the issue that
> games.eclass apparently got banned from future use. The only references
> I was able to dig up (apart from helpful people on IRC), were
> https://bugs.gentoo.org/show_bug.cgi?id=566498 (games.eclass: use of
> games group needs to be removed wrt 20151011 Council meeting)
> and
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Games_team_policies_issue
> (A mere deprecation notice).
> 
> In contrast, a simple "grep deprec /usr/portage/eclass/" gives numerous
> deprecation warnings; just games.eclass is not among them.
> 
> Please provide some guidance how (community-)developers are supposed to
> handle games (in particular wrt games.eclass) in the future. This also
> includes usage of /usr/games/{bin/lib/share} etc.
> 
> Regards,
> tomboy64
> 
> 

Good point. 

I too came across this problem when dealing with another bug
(games-emulation/ppsspp). A user filed a bug, complaining the ebuild wasn't
installing the compiled binary in /usr/games and suggested it should inherit
the games eclass: https://bugs.gentoo.org/show_bug.cgi?id=572606#c12 

I wasn't aware of the ban too so if someone has a better solution, I'm all
ears.

Regards,

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

[gentoo-dev] [Fwd: [gentoo-automated-testing] BROKEN: repository became broken!]

[Patrice Clement]

Hi dlan

This commit is breaking the tree:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=97a6aec

I did try to work around the issue you've introduced when but the enlightenment
eclasses are a bit of mystery to me and I eventually gave up.

Could you revert this commit and fix this issue?

Thank you!

- Forwarded message from mgo...@bonedaddy.net -

> From: mgo...@bonedaddy.net
> Subject: [gentoo-automated-testing] BROKEN: repository became broken!
> To: gentoo-automated-test...@lists.gentoo.org
> CC: d...@gentoo.org
> Date: Mon, 01 Feb 2016 03:31:56 +
> 
> Looks like someone just broke Gentoo!
> 
> New issues:
> https://qa-reports.gentoo.org/output/gentoo-ci/780f65b/output.html#dev-libs/efl
> 
> 
> Introduced by commits:
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=97a6aec
> 
> 
> Changes since last check:
> https://gitweb.gentoo.org/repo/gentoo.git/log/?qt=range=2496d1d..37c79f8
> 
> --
> Gentoo repository CI
> 

- End forwarded message -

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

Re: [gentoo-dev] Gentoo Bugzilla 5 upgrade completed

[Patrice Clement]

Monday 01 Feb 2016 05:53:52, Robin H. Johnson wrote :
> Hi everybody,
> 
> Idl0r has done all the work to upgrade us to Bugzilla's latest major
> version, v5.0, from upstream.
> 
> Please report bugs in the usual place (product=Gentoo Infrastructure,
> component=Bugzilla).
> 
> Sorry for the extended outage: the last portion, running the
> collectstats.pl script took much longer than originally estimated, as it
> seemed to be CPU-bound on the host (not the DB in any way).
> 
> -- 
> Robin Hugh Johnson
> Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee
> E-Mail : robb...@gentoo.org
> GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
> 

This is great news! Thanks a lot for your work.

Goodbye {JSON,XML}RPC, hello REST! [1]

[1]: https://wiki.mozilla.org/Bugzilla:REST_API

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

Re: [gentoo-dev] [PATCH v2 08/19] ebuild-maintenance: rewrite the text on adding binary files to the tree #558642

[Patrice Clement]

Sunday 24 Jan 2016 03:46:02, Gokturk Yuksek wrote :
> Remove the paragraph about adding binary files to CVS.
> Replace the instances of CVS with git.
> 
> X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=558642
> Signed-off-by: Gokturk Yuksek <gokt...@binghamton.edu>
> ---
>  ebuild-maintenance/text.xml | 19 +++
>  1 file changed, 3 insertions(+), 16 deletions(-)
> 
> diff --git a/ebuild-maintenance/text.xml b/ebuild-maintenance/text.xml
> index ac68dcd..10709ea 100644
> --- a/ebuild-maintenance/text.xml
> +++ b/ebuild-maintenance/text.xml
> @@ -42,22 +42,9 @@ above 20KB) which should be distributed as tarballs via the
>  Gentoo 
> mirror system
>  so that people do not waste excessive amounts of bandwidth and hard drive
>  space. Also, you should not add binary (non-ASCII) files to the
> -Portage CVS tree. If you need to do this in another CVS tree, for
> -example, if you need to add a small PNG graphic for whatever reason,
> -be sure to add it to CVS by using the -kb option, like so:
> -
> -
> -
> -# cvs add -kb myphoto.png
> -
> -
> -
> -The -kb option tells CVS that myphoto.png is a binary
> -file and should be treated specially.  For example, merging the 
> -differences between two different versions of this file should not be 
> -allowed to happen, for obvious reasons.  Also, speaking of merging 
> +git tree. Also, speaking of merging
>  changes, any patches you add to Portage should generally not be 
> -compressed.  This will allow CVS to merge changes and correctly inform 
> +compressed.  This will allow git to merge changes and correctly inform
>  developers of conflicts.
>  
>  
> @@ -149,7 +136,7 @@ simply, 1.0-gentoo.diff.  Also note that the
>  gentoo extension informs people that this patch was created 
>  by us, the Gentoo Linux developers, rather than having been grabbed from a 
>  mailing list or somewhere else. Again, you should not compress these 
> -patches because CVS does not play well with binary files.
> +patches because git does not play well with binary files.
>  
>  
>  
> -- 
> 2.4.10
> 
> 

"Again you should not compress these patches because git does not play well
binary files".

I'm not sure this statement still holds true with git. Does it?
-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[Patrice Clement]

Tuesday 19 Jan 2016 00:44:49, NP-Hardass wrote :
> With all of the unclaimed herds and unclaimed packages within them, I
> started to wonder what will happen after the GLEP 67 transition
> finally comes to fruition.  This left me with some concerns and I was
> wondering what the community thinks about them, and some possible
> solutions.
> 
> There is a large number of packages from unclaimed herds that, at this
> time, look like they will not be claimed by developers.  This will
> likely result in a huge increase in maintainer-needed packages (and
> subsequent package rot).  This isn't to say that some of these
> packages weren't previously in a "maintainer-needed" like state, but
> now, they will explicitly be there.
> 
> A possible approach to reducing this is to adopt some new policies.
> 
> The first of which is an "adopt-a-package" type program.  In
> functionality, this is no different than proxy-maintenance, however,
> this codifies it into an explicit policy whereby users are encouraged
> to step and take over a package.  This obviously requires a greater
> developer presence in the proxy-maint project (or something similar),
> but, personally, I think that a stronger dev presence in proxy-maint
> would be better for Gentoo as a whole.
> 
> The second policy change would be that maintainer-needed packages can
> have updates by anyone while maintaining the standard "you fix it if
> you break it" policy.  This would extend to users as well.  With the
> increased ease that users can contribute via git/github, they should
> be encouraged to contribute and have their efforts facilitated to ease
> contributions to whatever packages they desire (within the
> maintainer-needed category).
> 
> Similar to the concept of a "bugday," coupled with above, an
> "ebuildday" where users and devs get together so users can learn to
> write ebuilds and for devs to work together to maintain packages that
> usually fall outside their normal workload could prove beneficial to
> the overall health of Gentoo packaging.
> 
> Once again, these are just some random musings inspired by recent
> events on the dev ML, and thought it might be worth discussing.
> I've cc'd proxy-maint as a lot of this discussion is likely to involve
> them, and would like them to put in their official opinion as well.
> 
> 
> -- 
> NP-Hardass

More food for thought on the topic of "what do we do with maintainer-wanted
packages". 

NP-Hardass I quite like your idea but what about clearing down the massive
queue of reports assigned to maintainer-wanted first? 

Right now, the number of bug reports assigned to maintainer-wanted amounts to
over 4k: http://tiny.cc/maintainer_wanted

There's literally a slew of reports we can mark as WONTFIX / OBSOLETE because,
well, some of these bugs are over 10 years old (!) and a lot of projects have
stalled / are dead by now / or the industry has moved on. It has to be done at
some point anyway so better now than later. And the upside is that it doesn't
require ebuild skills or knowing Gentoo by heart: only clicking links and
checking whether projects are still alive.

What do you think?

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] Herd likely up for grabs: net-irc

[Patrice Clement]

Sunday 17 Jan 2016 21:16:45, Michał Górny wrote :
> Hello, everyone.
> 
> The current maintainers of net-irc herd so far haven't replied to
> our queries. If we don't get any reply in a week, we will be disbanding
> it and looking for new maintainers for its packages.
> 
> Is anyone interested in keeping the herd as a whole and maintaining all
> of its packages? If nobody replies till 2016-01-24, the herd will be
> automatically disbanded and I will be sending a complete list of
> packages needing maintainers.
> 
> Packages currently in herd along with their other maintainers:
> 
> [...]
> net-irc/irssi: swegener@
> net-irc/irssi-otr: 
> net-irc/irssistats   : 
> 
> -- 
> Best regards,
> Michał Górny
> <http://dev.gentoo.org/~mgorny/>

Avid user of irssi here. I'd like to take these 3 please.

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: dev-java/struts

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (06 Jan 2016)
# Struts 2 and friends suffer from a lack of interest. These ebuilds are
# outdated, riddled with CVEs (about 5 currently opened in Bugzilla) and some
# of them do not compile at all. Time to see them off.
# Masked for removal in 30 days. See bug #540888.
dev-java/struts-plugins
dev-java/struts-xwork
dev-java/struts-core
dev-java/struts

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] New project: Shell tools

[Patrice Clement]

In preparation for the implementation of GLEP 67, members of the Shell tools
herd are announcing the Shell tools project [1], which will replace the old
herd.

[1] https://wiki.gentoo.org/wiki/Project:Shell_Tools

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: www-client/uzbl

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (05 Jan 2016)
# According to its maintainer. this project is slowly dying 
# and there's no activity occuring on mailing lists / git repo.
# Masked for removal. See bug 570836.
www-client/uzbl

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] News for Gentoo CI and pull request CI

[Patrice Clement]

Friday 11 Dec 2015 23:13:33, Michał Górny wrote :
> Hi, everyone.
> 
> I'd like to make a short announcement that in the last few days I've
> been using my little free time to hack on my CI scripts, and they had
> a few major improvements. Most notably:
> 
> 1. pkgcheck now checks for outdated Manifests. In other words,
> gentoo-ci will most likely complain about missing or extraneous
> Manifest entries before Infra does, and pull request checks should
> complain loudly about them before the PRs are merged.
> 
> 2. The scripts use XML output of pkgcheck and group issues by packages,
> rather than grepping text output for failure indications
> and considering successive lines a single failure. Which means better
> output, better permalinks, better navigation and a completely new ugly
> UI.
> 
> 3. Most of the persisting issues (like deprecations) are skipped now,
> and all the output fits on one page. And that page is usually easier on
> the browser than each of the splits were.
> 
> 4. gentoo-ci compares previous check results correctly, and splits
> the output into three groups: new issues, previous issues and fixes
> issues.
> 
> 5. gentoo-ci bisects on new issues, pinpoints the exact commit
> introducing the failure and CCs both the author and the committer.
> In other words, does the hard work for me and does it more efficiently.
> It also has nice bisect caching support which makes bisecting a number
> of issues caused by the same commit very fast.
> 
> 6. pull-request checks now distinguish between issues introduced by PR
> and carried over from ::gentoo. Not that you should ignore the latter
> entirely since they may hide additional issues from PR.
> 
> Most of this fun stuff came from a simple obvious thing that only
> recently occurred to me: I don't have to run a full pkgcheck for
> bisecting! I just need to check the packages that are failing
> in the most recent commit!
> 
> Of course, the whole thing is open source:
> 
> 1. https://bitbucket.org/mgorny/repo-mirror-ci
> 
> 2. https://bitbucket.org/mgorny/pkgcheck-result-parser
> 
> Enjoy!
> 
> -- 
> Best regards,
> Michał Górny
> <http://dev.gentoo.org/~mgorny/>


Awesome Michal, thanks a lot!

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH 02/13] python-utils-r1.eclass: Reorder implementations to semi-ascending order

[Patrice Clement]

Sunday 06 Dec 2015 20:03:21, Michał Górny wrote :
> Reorder the Python implementations to ascending version order, with
> CPython listed first and other implementations in descending preference.
> 
> The previous ordering has been used for two reasons:
> 
> 1. There were packages which supported Python 3.x or PyPy partially but
> their documentation builds or test functions required CPython 2.x.
> The specific ordering caused python_export_best (the predecessor of
> python_setup) to use CPython 2.x for those tasks. This is now replaced
> by explicit implementation restrictions in python_setup.
> 
> 2. PyPy setup runs were usually slower than CPython, and CPython 3.x
> runs were often slower due to 2to3 calls. Combined with parallel build
> runs, this ordering caused slower builds to start earlier and sometimes
> resulted in more efficient use of threads. However, nowadays we no
> longer do parallel builds.
> 
> Therefore, it seems reasonable to finally reorder the implementations
> into a more intuitive order.
> ---
>  eclass/python-utils-r1.eclass | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> index 0bce6a9..3ea23a8 100644
> --- a/eclass/python-utils-r1.eclass
> +++ b/eclass/python-utils-r1.eclass
> @@ -41,10 +41,10 @@ inherit toolchain-funcs
>  # @DESCRIPTION:
>  # All supported Python implementations, most preferred last.
>  declare -g -r _PYTHON_ALL_IMPLS=(
> - jython2_5 jython2_7
> - pypy pypy3
> - python3_3 python3_4 python3_5
>   python2_7
> + python3_3 python3_4 python3_5
> + pypy pypy3
> + jython2_5 jython2_7
>  )
>  
>  # @FUNCTION: _python_impl_supported
> -- 
> 2.6.3
> 
> 

Michal,

While at it, please delete jython2_5 from this list since jython versions < 2.7 
are in
the process of being purged from Portage. 

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

Cheers,

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

[gentoo-dev] Last rites: dev-java/{many packages} app-text/epubcheck

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (06 Dec 2015)
# We maintain old versions which were never stabilised
# and are too far behind for a trivial version bump.
# Masked for removal in 30 days. See bug #161440.
dev-java/webgraph
dev-java/mg4j

# Patrice Clement <monsie...@gentoo.org> (05 Dec 2015)
# Upstream dead: no update since 2007.
# Masked for removal in 30 days. See bug #567580.
dev-java/jpf
dev-java/jpfcodegen

# Patrice Clement <monsie...@gentoo.org> (03 Dec 2015)
# Broken and outdated. Let's see off these 3 packages.
# Masked for removal in 30 days. See bug #567326.
app-text/epubcheck
dev-java/css-validator
dev-java/jigsaw

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-p2p/deluge/

[Patrice Clement]

Monday 23 Nov 2015 18:18:49, Robin H. Johnson wrote :
> On Mon, Nov 23, 2015 at 01:22:14PM +0000, Patrice Clement wrote:
> > commit: 19c9530e8cf386649a0815cd532d24f6e7261867
> > Author: Paolo Pedroni  users  noreply  github 
> >  com>
> > AuthorDate: Tue Nov 17 10:31:30 2015 +
> > Commit: Patrice Clement  gentoo  org>
> > CommitDate: Mon Nov 23 13:17:37 2015 +
> > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=19c9530e
> > 
> > net-p2p/deluge: Version bump. Fixes bug 561398.
> > 
> > Gentoo-Bug: 561398
> > 
> >  net-p2p/deluge/{deluge-1.3.11.ebuild => deluge-1.3.12.ebuild} | 1 +
> >  1 file changed, 1 insertion(+)
> This commit did NOT include any new Manifest entry, so stopped
> replication to rsync (because we verify all Manifests now).
> 
> If you git-pull/merge new ebuilds, please make sure you update the
> Manifest!
> 
> -- 
> Robin Hugh Johnson
> Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee
> E-Mail : robb...@gentoo.org
> GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
> 

Oops. Thanks for the heads up and for fixing it.

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

[gentoo-dev] Last rites: app-text/htmltidy

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (21 Nov 2015)
# Upstream dead + superseded by app-text/tidy-html5.
# Masked for removal in 30 days. See bug #564884.
app-text/htmltidy

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: net-p2p/phex

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (12 Nov 2015)
# Upstream dead + ebuild was never stabilised.
# Masked for removal in 30 days. See bug #276095.
net-p2p/phex

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: dev-java/{poi,dbunit} && dev-db/jxtray

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (12 Nov 2015)
# Upstream is somewhat alive but has made compiling POI difficult to compile
# and package. Further, POI is affected by a bunch of CVEs. It has solely two
# deps that we are masking as well since both projects are not very trendy
# and/or alive. Masked for removal in 30 days. See bug #402757.
dev-java/poi
dev-java/dbunit
dev-db/jxtray

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

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

[Patrice Clement]

Sunday 01 Nov 2015 18:08:06, James Le Cuirot wrote :
> On Mon, 2 Nov 2015 04:44:39 +1100
> Michael Palimaka <kensing...@gentoo.org> wrote:
> 
> > Phabricator also has all sorts of fancy (optional) features that could
> > be useful for collaborative development (see http://phabricator.org/
> > for more info).
> > 
> > What do you think?
> 
> Looks nice! I hadn't heard of Phabricator before. It has a good mix of
> open and closed projects using it, according to Wikipedia. I'm using
> GitLab at work, which also does the job but Phabricator would probably
> scale easier being PHP-based rather than Ruby-based; I say that as a
> Ruby developer! I've had Gerrit recommended a few times but while I'm
> sure it's capable, my brief encounters with it have found the interface
> a little overwhelming.
> 
> -- 
> James Le Cuirot (chewi)
> Gentoo Linux Developer


I would very much be able to emerge gerrit on Gentoo. There's no ebuild for it
(yet). Someone filed a bug:

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

The Android Open Source project use Gerrit as its main code-review tool in
their workflow. 

https://android-review.googlesource.com/#/q/status:open

Diffs are shown side-by-side, which I find lacking on Github. Example:

https://android-review.googlesource.com/#/c/175598/7/drivers/platform/goldfish/goldfish_pipe.c@179

Anyway, just my 2 cents on the topic. Have a look and you'll see in terms of
features, I think it's on a par with Github. And it's open source. ;)

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

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

[Patrice Clement]

Monday 02 Nov 2015 09:29:48, Duncan wrote :
> Patrice Clement posted on Mon, 02 Nov 2015 09:33:49 +0100 as excerpted:
> 
> > [gerrit]
> > 
> > Anyway, just my 2 cents on the topic. Have a look and you'll see in
> > terms of features, I think it's on a par with Github. And it's open
> > source. ;)
> 
> FWIW from previous gerrit suggestions...
> 
> The problem there is ... java, along with the maintenance and security 
> issues it brings when run on a publicly accessible server where java is 
> otherwise unnecessary.  (IIRC, at least one infra person said it's a hard 
> no on java running on gentoo infra, period, as it simply cannot be done 
> correctly and safely with the resources available.  Tho I'm not 100% sure 
> IRC on that one.)
> 
> #2 problem, as with several code-review products, is the security issue 
> of the huge stack of code (regardless of language) on a web server, with 
> direct single-user write access to the tree.  If it were a different user 
> for each dev account so unconditional write access wasn't a monolithic 
> grant...
> 
> Now if a one-way repo sync is done to the tree gerrit accesses from 
> gentoo-master, not reversed, sandboxing the tree gerrit has access too, 
> the problem is lessened to some degree, but of course that dramatically 
> lessens the usefulness as well, since the reviewed code must then be 
> checked back into the main tree manually.
> 
> Which would seem to be one potential positive for phabricator, since at 
> least from the bit here in-thread, it appears to be review-only, no 
> direct commit access, thereby eliminating at least that security threat.
> 
> -- 
> 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
> 
> 

By reading your answer, I'm not sure if it is clear or obvious for most users 
how 
the workflow between the Gentoo infra <-> Github infra functions so maybe we
should explain it one more time:

1) Gentoo developers receive notifications (emails) from Github that somebody's
  sent a PR and would like to merge it into the main repo
2) They go over to github.com/gentoo/gentoo/pulls and checkout the PR
3a) Sometimes (often), the PR has tons of errors and doesn't respect our coding
  standards and suddenly, we get a zillion notifications that mgorny and
  hasufell are peer-reviewing the PR ;)
3b) Sometimes the PR is spot on, the ebuild(s) submitted is (are) flawless, we
  merge it.
4) How do we merge it? We do *NOT* make use of the "Merge" button Github offers
(and never will). Why? Changes would get lost in the wind if we did so, since
the repository sitting on the Github infra is merely a mirror. Instead, we pull
each PR into our own local copy of the Gentoo git repository hosted at
https://gitweb.gentoo.org/repo/gentoo.git/ and then merge them. 

See: https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Workflow_walkthrough and
https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Github_PRs_made_easy

Think of Github as a nice and fancy UI to bridge the gap between developers and
those allergic to a console and used to a browser.

Now, with this explanation out of the way, I'm not sure what you mean by the
"security threat" issue you've brought up your email. 

Gerrit is a code-review web platform that CAN allow commits to be merged, but
this privilege has to be granted to specific users (like Github). It is really
up to us and how infra want to manage merging. It doesn't make Gerrit less or
more secure IMHO. This is a biased argument.

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

[gentoo-dev] Last rites: dev-java/castor dev-db/octopus

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (29 Oct 2015)
# Upstream is somewhat alive but there are better XML parsers out there.
# Removal in 30 days. See #268619.
dev-java/castor
 
# Patrice Clement <monsie...@gentoo.org> (29 Oct 2015)
# No release since 2007. Has dependencies on old ebuilds.
# Removal in 30 days. See #564370
dev-db/octopus  

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-java/bcprov/

[Patrice Clement]

Friday 09 Oct 2015 08:28:06, Michał Górny wrote :
> Dnia 2015-10-08, o godz. 22:11:12
> "Patrice Clement" <monsie...@gentoo.org> napisał(a):
> 
> > commit: 82be4dfc08bacbac9814583a8cccc40bb1d2fd59
> > Author: Patrice Clement  gentoo  org>
> > AuthorDate: Thu Oct  8 22:02:48 2015 +
> > Commit: Patrice Clement  gentoo  org>
> > CommitDate: Thu Oct  8 22:06:19 2015 +
> > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=82be4dfc
> > 
> > dev-java/bcprov: Clean up old.
> > 
> > Package-Manager: portage-2.2.20.1
> > Signed-off-by: Patrice Clement  gentoo.org>
> > 
> >  dev-java/bcprov/Manifest  |  3 --
> >  dev-java/bcprov/bcprov-1.38-r2.ebuild | 57 
> >  dev-java/bcprov/bcprov-1.38-r3.ebuild | 57 
> >  dev-java/bcprov/bcprov-1.40-r1.ebuild | 59 
> >  dev-java/bcprov/bcprov-1.45-r1.ebuild | 59 
> >  dev-java/bcprov/bcprov-1.45.ebuild| 59 
> >  dev-java/bcprov/bcprov-1.48-r1.ebuild | 64 --
> >  dev-java/bcprov/bcprov-1.49-r2.ebuild | 81 
> > -
> >  dev-java/bcprov/bcprov-1.49-r3.ebuild | 81 
> > -
> >  dev-java/bcprov/bcprov-1.50-r1.ebuild | 58 
> >  dev-java/bcprov/bcprov-1.50.ebuild| 81 
> > -
> >  dev-java/bcprov/bcprov-1.52.ebuild| 84 
> > ---
> >  12 files changed, 743 deletions(-)
> 
> Replying to one of the particularly influential commits in long batch
> of wrongdoing.
> 
> So here you remove all of the ebuild which have SLOT="0", effectively
> breaking *stable* dev-java/bcmail, dev-java/bcpkix, dev-java/itext:
> 
> https://qa-reports.gentoo.org/output/gentoo-ci/62d6c0c/6.html#l59
> https://qa-reports.gentoo.org/output/gentoo-ci/62d6c0c/6.html#l153
> https://qa-reports.gentoo.org/output/gentoo-ci/62d6c0c/6.html#l249
> https://qa-reports.gentoo.org/output/gentoo-ci/62d6c0c/6.html#l343
> https://qa-reports.gentoo.org/output/gentoo-ci/62d6c0c/6.html#l710
> 
> What's even worse, you instantly stabilize new dev-java/bcmail ebuilds
> which have the same issue.
> 
> As a side issue, why the hell do you stabilize a number of random old
> versions? This does not like a sane solution, instantly adding dozen
> of poorly-tested middle versions into the stable tree.
> 
> -- 
> Best regards,
> Michał Górny
> <http://dev.gentoo.org/~mgorny/>

bcprov ebuilds were a clusterfuck that I was trying to fix and obviously I
failed. Taking a look at it right now. Fix underway.

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: dev-java/xmlc + dev-db/derby

[Patrice Clement]

# Patrice Clement <monsie...@gentoo.org> (1 Oct 2015)
# Project is over 10 years old and seems to have stalled.
# Masked for removal in 30 days. See bug 561954.
dev-java/xmlc

# Patrice Clement <monsie...@gentoo.org> (24 Sep 2015)
# This package was never marked stable 
# and is relying on an old version of JavaCC.
# Masked for removal in 30 days. See bug 561410.
dev-db/derby


signature.asc
Description: PGP signature

Re: [gentoo-dev] ALLARCHES and the maintainer action(s)

[Patrice Clement]

Saturday 19 Sep 2015 09:55:14, Anthony G. Basile wrote :
> On 9/19/15 8:56 AM, Ian Stakenvicius wrote:
> > Sent from an iPhone, sorry for the HTML...
> >
> > On Sep 19, 2015, at 8:31 AM, Vadim A. Misbakh-Soloviov <m...@mva.name> 
> > wrote:
> >
> >>> So, if an arch developer tests the package(s) on one architecture, he is
> >>> allowed to stabilize/keyword for all.
> >> And how about the
> >>> some arches rquires additional tests during stabilization, like so: mips*,
> >> arm*, and some more exotic ones
> >> definition in developer manuals? :)
> >>
> >> -- 
> >> Best regards,
> >> mva
> > The ALLARCHES keyword is meant for stuff that is essentially 
> > platform-agnostic.  Python code shouldn't act any different on arm than 
> > arm64 than amd64.  Using that keyword on something like ffmpeg would be a 
> > bad use of the keyword.
> 
> Even with python where, for example, `import ctypes' might trigger 
> something on one arch and not another.  Anyhow, thanks for the reminder 
> ago.  I see that keyword as "risky" but an unfortunate risk we have to 
> take because we are short of manpower and don't have automated arch 
> testing.  I say use it where it appears reasonable (eg interpreted 
> script and not compiled code) but be ready that every once in a while 
> we'll get bitten.
> 
> -- 
> Anthony G. Basile, Ph.D.
> Gentoo Linux Developer [Hardened]
> E-Mail: bluen...@gentoo.org
> GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
> GnuPG ID  : F52D4BBA
> 
> 

We've been using this keyword fairly often (we = Gentoo Java team) whenever
possible since the announcement and it worked out pretty well so far.

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

Re: [gentoo-dev] symlinks in the tree

[Patrice Clement]

Saturday 12 Sep 2015 15:30:45, Justin Lecher (jlec) wrote :
> On 12/09/15 15:19, hasufell wrote:
> > +1 for banning symlinks
> > 
> 
> mrueg just mentioned a very crucial point. There are filesystem which
> don't support symlinks and would break everything.
> 
> 
+1 too

A functionality that causes a maintenance burden should be avoided. It's just
common sense.

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org


signature.asc
Description: PGP signature

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

[Patrice Clement]

Friday 04 Sep 2015 09:59:07, James Le Cuirot wrote :
> On Fri, 4 Sep 2015 09:53:38 +0100
> malc <mlash...@gmail.com> wrote:
> 
> > James - you're right - I hadn't paid attention to MTA wrapping...
> > Patrice - even though it's counter to what James asked, I added short
> > sha-1s [ i.e. the output of git rev-parse --short
> > f1cb2b98f62fa9cbf1ef5a0f149dd47fee6964be ]
> > Now the output looks like below (or attached txt file)
> 
> That looks very nice, thanks. I don't know what will happen if
> something doesn't fit but hopefully it's something sensible. :)
> 
> -- 
> James Le Cuirot (chewi)
> Gentoo Linux Developer
> 
+1

It looks nice indeed. Thanks.

@infra: do you guys have a public git repo hosted under 
http://github.com/gentoo ? 

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

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

[Patrice Clement]

Thursday 03 Sep 2015 18:01:55, James Le Cuirot wrote :
> On Thu, 3 Sep 2015 18:49:05 +0200
> Róbert Čerňanský <ope...@tightmail.com> wrote:
> 
> > Can it be *please* modified so that one removal/addition fits on a
> > single line?  It is very hard to eye-parse when lines are split in
> > two.  Or maybe leave the length as is and do not break the lines?
> 
> I agree but it's because it used to just have the CVS username rather
> than the full name and e-mail address. I'd be happy with just the
> e-mail address. If that's still too long, maybe we could replace
> @gentoo.org with @g.o and that would deal with most cases.
> 
> -- 
> James Le Cuirot (chewi)
> Gentoo Linux Developer
> 
Can we also get the SHA1 of each commit/removal?

Thanks!

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

[gentoo-dev] Last rites: dev-java/{a lot of packages}

[Patrice Clement]

# Patrice Clement monsie...@gentoo.org (19 Aug 2015)
# Upstream dead: no releases since 2010.
# Technology has moved on and there are far better alternatives
# (easymock, mockito and jmock).
# Masked for removal in 30 days. See bug #190307.
dev-java/mockobjects

# Patrice Clement monsie...@gentoo.org (19 Aug 2015)
# Upstream dead too: no releases since 2005.
# Masked for removal in 30 days. See bug #190307.
dev-java/xdoclet

# Patrice Clement monsie...@gentoo.org (16 Aug 2015)
# Dependency of dev-java/base64. This project isn't getting a lot of traction
# and we already have a ton of Java serialiser APIs in the tree.
# Masked for removal. See bug #557866.
dev-java/java-xmlbuilder

# Patrice Clement monsie...@gentoo.org (16 Aug 2015)
# Last release was in 2008. Does not compile with recent JDKs (= 1.8).
# Masked for removal. See bug #557920.
dev-java/httpunit

# Patrice Clement monsie...@gentoo.org (16 Aug 2015)
# Project discontinued: part of the java.util namespace as of Java 8.
# See https://docs.oracle.com/javase/8/docs/api/java/util/Base64.html.
# Masked for removal. See bug #557866.
dev-java/base64

# Patrice Clement monsie...@gentoo.org (14 Aug 2015)
# Unreachable HOMEPAGE (dead). Very very very old package:
# last release came out in 2001.
# Masked for removal in 30 days. See bug #232666.
dev-java/tclib

# Patrice Clement monsie...@gentoo.org (14 Aug 2015)
# Last release is over 13 years old (!).
# Masked for removal in 30 days. See bug #177032.
app-text/jdictionary

# Patrice Clement monsie...@gentoo.org (1 Aug 2015)
# Package relying on j2me. Not useful anymore since j2me has long been removed.
# Removal in 30 days. See bug #556460.
dev-java/antenna


signature.asc
Description: PGP signature

[gentoo-dev] Developer branches on proj/gentoo

[Patrice Clement]

Hi there

According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model,
there may be developer-specific, task-specific, project-specific branches
etc. As far as I understand, it means I can go and create my own branch on the
main repository and push it and it gets spread all over the place. Is that
correct?

Could someone explain to me the rationale behind this decision?

Truth to be told, I kinda dislike the fact any developer can do this. 

proj/gentoo should be kept for serious business i.e. commits that affects the
tree. On the long run, if everybody goes down that road, we will see flourish
numerous branches (who said unmaintained?), all stalled at a different state of
the main repo, and it will only generate a lot of noise and confusion for
nothing. Further, since we've moved over to git, the main tree now gets
replicated to github and we all have github accounts here, don't we? Which makes
the whole forking and submitting PRs a cinch.

If a developer wants to tinker with the tree, he can fork it to its github
devspace, fiddle around, and later on send us a PR back with his changes to
merge.

Cheers,
Patrice

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

[Patrice Clement]

Monday 10 Aug 2015 12:02:25, Daniel Campbell (zlg) wrote :
 On 08/10/2015 06:15 AM, Doug Goldstein wrote:
  On Mon, Aug 10, 2015 at 3:36 AM, Chí-Thanh Christopher Nguyễn 
  chith...@gentoo.org wrote:
  Doug Goldstein schrieb:
  gpg: cancelled by user gpg: skipped 0xA2BC03DC87ED1BD4:
  Operation cancelled gpg: signing failed: Operation cancelled 
  error: gpg failed to sign the data
  
  There was an IRC discussion yesterday about this. Probably your
  pinentry tries to talk to a GUI and fails. Try:
  
  unset DISPLAY export GPG_TTY=$(tty)
  
  to make it fall back to curses, or use eselect pinentry to
  select curses as default.
  
  Interestingly, git requires GPG_TTY if eselect-pinentry is set to
  gtk-2 or qt4, but repoman doesn't.
  
  
  Best regards, Chí-Thanh Christopher Nguyễn
  
  
  
  $ eselect pinentry show Current pinentry binary implementation: 
  pinentry-curses
  
  $ eselect pinentry list Available pinentry binary implementations: 
  [1]   pinentry-curses *
  
  Its the only version I've got on this machine. The box is headless
  and I ssh into and I use keychain to manage my SSH and GPG agent.
  
 What's your keychain line look like in your .bashrc/.bash_profile?
 Here's the relevant portion of mine. I was also having problems with
 it until I changed the order of the arguments:
 
 [snip]
 /usr/bin/keychain --agents ssh,gpg ~/.ssh/id_rsa ${GPGKEY}
 source ~/.keychain/sporkbox-sh  /dev/null
 source ~/.keychain/sporkbox-sh-gpg  /dev/null
 [snip]
 
 For some reason, it's important that ssh comes before gpg. I got this
 advice straight from drobbins, so unless it's changed, that's the way
 to get it working.
 -- 
 Daniel Campbell - Gentoo Developer
 OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
 fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6

Would someone mind documenting this issue in the wiki?

https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Issues

So that we all have a point of reference to go to.

Thanks!


pgp5LAuSmShMi.pgp
Description: PGP signature

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

[Patrice Clement]

Sunday 09 Aug 2015 20:17:57, Patrick Lauer wrote :
 On Sunday 09 August 2015 08:06:53 Anthony G. Basile wrote:
  Hi everyone,
  
  I hate to be a nag, but please read
  https://wiki.gentoo.org/wiki/Gentoo_git_workflow.  In particular, commit
  messages.  I'm seeing lots of cvs style messages going in and without
  history it will be hard to figure out what happened just from the
  message.  Particularly, we should prepend CATEGORY/PN:  to the first
  line so we can easily search git log for what happened to a package.
 
 Lazy me says:
 
 Can't we make repoman do that?
 

We should delegate this task to git and set up a hook for this kind of checks.

http://git-scm.com/docs/githooks

I'm not going to copy and paste what's on the website but a hook is basically a
script that gets executed post/pre commits/push/[insert action here]. 

Hooks can be written in any programming language.

If we take the concept event further, even repoman itself could go away..

[gentoo-dev] Last rites: www-servers/skunkweb

[Patrice Clement]

# Patrice Clement monsie...@gentoo.org (3 Aug 2015)
# Broken and no releases in 10 years (!).
# Removal in 30 days. See bug #451790.
www-servers/skunkweb

[gentoo-dev] Last rites: dev-java/jjtraveler

[Patrice Clement]

# Patrice Clement monsie...@gentoo.org (30 Jul 2015)
# Broken and upstream dead isn't always a good mix.
# Removal in 30 days. See bug #368049.
dev-java/jjtraveler 

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

[Patrice Clement]

Saturday 18 Jul 2015 15:36:01, NP-Hardass wrote :
 On Sat, 18 Jul 2015 12:01:48 -0700
 Matthew Marchese maffblas...@gentoo.org wrote:
 
  Hello all,
  
  I have recently pressed the reboot button on the ol' Installer
  project. I've been able to talk to quite a few developers one-on-one
  via IRC concerning my plans. Most seem to be in support of Gentoo
  having a official installer (the biggest concern is appears to be
  how things will be implemented and the amount of features involved).
  This e-mail is to fulfill GLEP 39's request for comments (RFC),
  concerns, requests, etc. Since I'm a little new to the project I'm
  coming with a bit of ignorance; I know the previous Installer project
  fostered mixed feelings.
  
  If you'd like to review before replying you can see the Wiki page and
  find the source on GitHub: https://github.com/gentoo/stager
  
  To summarize I'm writing it in pure Python 3. It first will be able
  to create full backups (stage 4s) and recoveries. After that is
  finished I plan to move on to installations. There will potentially
  be a web interface UI for it. Others are free to create other
  front-ends; to me a web UI makes the most sense and would probably
  require the least deps.
  
  I'd like to hear it all so please speak your mind. Looking forward to
  hearing from you.
  
  maffblaster
  

Hi Matthew
 
I fancy your idea a lot. We ought to do it for complete newbies who are new to
Gentoo but would like to give the distribution a shot nonetheless. I fondly
remember my first attempt who took me ages to complete.. Good times. :)

Following up on NP-Hardass' email in which he's raising good points:
 
 Who is your target audience?  New users?  Experienced users?  Not so
 much a comment about your installer, but installers in general, I feel
 the handbook is critically important to helping new users to understand
 Gentoo. Whether the handbook would remain a resource that users would
 look at if they had an installer remains to be seen.  

IMHO, users should be guided and walked through the installation process. They
should understand what's going on so the Handbook must be equally important as
when a normal chap installs Gentoo without using the installer. 

It should ask users trivial questions, a bit like the Debian CLI installer.

Which partition do you want to format?

How do you want to configure your network interface?

etc.

Worth mentioning for sysadmins, devops and users alike: automation is all the
rage these days. Beyond creating an installer, it'd be interesting to feed the
program with a sort of configuration file so that the whole process can be
performed in one go. Or think about integrating it with Chef, Puppet et al.

I think it's a personal taste here and whether we want to reinvent the wheel or
not.

 The project page  states: 
 
 Greatly aiding the fresh install process. stager will not
 remove the need for reading through the Handbooks, but rather work
 along side the handbook in order to help users install Gentoo.
 
 Can you elaborate on this?  I have trouble envisioning an automated 
 installer process that requires working along side the handbook.
 
 I know that you mentioned a web interface.  I assume that you there are
 plans for a simpler, local interface like ncurses or cli, or text in a
 terminal? Is it meant to be interactive?

Python has an ncurses module that allows developers to create interactive
programs out of the box.

The web interface would also be a interesting feature (maybe for remote
installations?) but truth to be told, I see it as a nice to have feature
rather than a must have.

 I like the idea of having an automated installer, so I wish you the
 best of luck with the project.  I'm sure you'll encounter tons of
 people with tons of opinions on what it should and shouldn't be, so
 just do your best to maintain a clear, well-defined vision and stick to
 it.
 

Definitely. Write a roadmap and stick to it.

Cheers,
Patrice


pgpbM4b8TosrW.pgp
Description: PGP signature

[gentoo-dev] Last rites: app-arch/dczip net-p2p/frostwire

[Patrice Clement]

# Patrice Clement monsie...@gentoo.org (5 Jul 2015)
# SRC_URI unreachable. Upstream looks dead.
# Removal in 30 days. See bug #502994.
app-arch/dczip

# Patrice Clement monsie...@gentoo.org (5 Jul 2015)
# Package does not compile with recent JDKs (= jdk-1.8). More recent versions
# use Gradle which we don't have packaged in Gentoo yet.
# Removal in 30 days. See bug #552452.
net-p2p/frostwire


pgpQ99CJ4o3g7.pgp
Description: PGP signature

Re: [gentoo-dev] Git workflow

[Patrice Clement]

Sunday 05 Jul 2015 16:03:27, hasufell wrote :
 On 07/05/2015 06:10 AM, C Bergström wrote:
  5) More about linear commits and history - I need to double check,
  but I don't think rebase changes the actual commit date (I could be
  mistaken).
 
  You are mistaken, and should have double checked before you argued.
 
  Arguing without checking makes you look bad.
  
  How? I didn't claim to know and clearly not knowing didn't seem
  important (to me). I'm not trying to overstate anything. I'm just
  trying to passionately bring this up. I ***wish*** someone with some
  guts would actually take charge of this on the gentoo side, have a
  vote or make some executive decision which is stronger than this wimpy
  policy we have now.
  
 
 Most of what you brought up wasn't really useful critique, but rather
 noise based on your personal frustration with git.
 
 This thread is not about giving lectures on how git works. We appreciate
 useful comments on the git workflow. But in order to give useful
 comments, you have to know and understand the project and how it works
 internally.
 
 There will be a sh*tload of developer, feature and whatnot branches. It
 is just insane to tell everyone to unconditionally do rebases
 everywhere. You haven't even commented on a fraction of the resulting
 problems. So please lets stop this discussion and move on.
 

+1

How about you guys carry on this discussion somewhere else in a place like,
I don't know, IRC?

#which-git-workflow-fits-best-my-needs

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog kde5-functions.eclass kde5.eclass

[Patrice Clement]

man 3 glob
man 3 fnmatch
man 1 bash - read the section called Pattern Matching under EXPANSION.

in this case, $(ls) would unnecessarily spawn a subshell for listing files. You
can often get the same result by using wildcard expansion (or globbing) like
Michal said:

for lang in *; do
...
done

It is often faster.

Cheers,
Patrice

Sunday 28 Jun 2015 14:25:25, Johannes Huber wrote :
 On Sunday 28 June 2015 04:12:01 Michal Górny wrote:
 
   + for lang in $(ls) ; do
  
  How about... for lang in *?
 
 What is the advantage?
 
 Greetings
 -- 
 Johannes Huber (johu)
 Gentoo Linux Developer / KDE Team
 GPG Key ID FDF4F788




pgpz97nHdicW7.pgp
Description: PGP signature

[gentoo-dev] Last rites: dev-java/mockmaker

[Patrice Clement]

# Patrice Clement monsie...@gentoo.org (22 Jun 2015)
# No update from upstream since 2002. This package might cause problems with
# new JDKs. Removal in 30 days.
dev-java/mockmaker


pgpkfuNinZ4VQ.pgp
Description: PGP signature

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

[Patrice Clement]

Hi Michal

I could help out with phsh if you need a hand.

Cheers,
Patrice

Monday 15 Jun 2015 19:54:59, Michal Górny wrote :
 Hi, everyone.
 
 My time for Gentoo is quite limited right now (you gotta start working
 for money at some point :)), and the little time I have I'm trying to
 use for the Gentoo work I consider most important. This sadly means
 that many of my past tools are earning their share of bitrot and would
 really use a new contributors, or possibly even full-time upstream
 maintainers :).
 
 Here's a long list of projects along with short description, their state
 and planned TODO items that I won't have time to implement anytime soon.
 
 
 app-admin/eclean-kernel
 
   The tool to clean up old kernels. A bit controversial in the end
   because /boot is a mess.
 
   status: works with some /boot layouts, fails hard on some, has some
   known bugs/requests
 
   TODO:
   - figure out how it sanely could work,
   - support /boot shared between multiple systems,
   - support BootloaderSpec (maybe),
   - clean up the code, possibly rewrite in something saner than Python
 (C++?).
 
 
 app-cdr/mirage2iso
 
   Quite an old tool to convert various image formats to .iso using
   libMirage.
 
   status: working, no known bugs, may use a little cleanup
 
   TODO:
   - support selecting track to read (right now it reads first supported
 one),
   - support extracting multiple tracks (sessions) -- options to pass
 track list and output filename pattern,
   - support converting to .bin + .toc/.cue,
   - support for more track types (right now, Mode 1  Mode 2 form 1 are
 supported),
   - support for audio tracks (how? external converter? a library?).
 
 
 app-portage/cpuinfo2cpuflags
 
   The tool to get CPU_FLAGS_X86 for your system :). Not really
   abandoned but I have some TODO items I won't be able to do soon.
 
   status: working, no known bugs
 
   TODO:
   - replace /proc/cpuinfo parsing with CPUID assembly/intrinsics --
 support more kernels than just Linux,
   - possibly extend to non-x86 arches.
 
 
 app-portage/diffmask
 
   A tool to maintain package group unmasks in sync, and clean up stale
   unmasks. Quite specific since it requires unmasks to be copied
   exactly from mask file.
 
   status: quite working, not exactly proud of the design
 
   No real TODO items but it would be nice to think a bit about
   the design and figure out if we couldn't do something more user-
   friendly (i.e. not being that strictly bound to package.mask).
 
 
 app-portage/flaggie
 
   The package.use ( make.conf) flag management tool. Pretty high
   priority.
 
   status: rather working, has a few bugs, certainly would use some new
   Portage features
 
   TODO:
   - remove make.conf editing support (it's very complex and broken --
 can eat random '$' from the file in some cases),
   - therefore: edit global flags via '*/*' entries in package.use,
   - support writing 'FOO_BAR:' format for USE_EXPAND in package.use,
   - support parsing 'FOO_BAR:' format for USE_EXPAND on command-line
 (i.e. 'flaggie libfoo VIDEO_CARDS: +radeon -nvidia'),
   - remove implicit '*' expansion in package names and flag names --
 package.use can handle '*', so leave it as is and just expand it
 when checking if the flags are supported,
   - possibly clean up package.use writer (or rewrite it since I'm
 no longer able to figure out how it works exactly :)).
 
 
 app-portage/gentoopm
 
   A wrapper providing nice API to all three Package Managers. Used by
   gpyutils, smart-live-rebuild...
 
   status: stuck in EAPI 4 era, might have some hidden bugs
 
   TODO:
   - add APIs for EAPI 5 -- but this requires Package Manager APIs first,
   - maybe some cleanup.
 
 
 app-portage/install-mask
 
   A tool to update INSTALL_MASK in make.conf using well-known file
   groups. Uses make.conf manipulation code from flaggie.
 
   status: working, make.conf manipulation broken as in flaggie
 
   TODO:
   - the tool should be killed, and INSTALL_MASK group support should be
 moved into Portage :). Alike:
 
 INSTALL_MASK=@systemd @locale -@locale_pl
 
 with matches being applied sequentially, and groups being defined
 in $repo/metadata/install-mask.conf [and masters].
 
 
 app-portage/pms-test-suite
 
   A GSoC project and as such, totally abandoned. Not sure if anybody
   really cares these days.
 
   status: stuck in EAPI 4 era, waiting for EAPI 5 in gentoopm...
 
   TODO:
   - support EAPI 5,
   - find some use for it?
 
 
 dev-util/atomic-install
 
   A nice one -- tool to quasi-atomically install files from $D to live
   system. The idea is to replace live files as fast as possible,
   and quickly revert that if it fails in the middle. Never finished but
   nevertheless a good idea :). If someone's up for it, I'd love to see
   it working one day.
 
   status: never reached 'fully working' state
 
   How it was supposed to work (and mostly works):
   - writes 'journal' synchronously with 

[gentoo-dev] Last rites: dev-java/aspectwerkz

[Patrice Clement]

# Patrice Clement monsie...@gentoo.org (14 Jun 2015)
# Upstream dead. No update since 2005.
# Masked for removal in 30 days.
dev-java/aspectwerkz


pgp_VbFm_2dK4.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: ban EAPI 1

[Patrice Clement]

Wednesday 10 Jun 2015 22:43:10, Ulrich Mueller wrote :
 Hi,
 The number of EAPI 1 ebuilds in the Portage tree has decreased to
 a total of 60, corresponding to 0.16 %.
 
 We briefly discussed in the QA team if we should demote EAPI 1 in
 layout.conf from eapis-deprecated to eapis-banned. This would
 have the consequence that repoman would refuse to commit packages
 containing such ebuilds. AFAICS there would be no impact on users.
 
 What do you think?
 
 Ulrich

Make it happen!


pgpXWxYvFmO0B.pgp
Description: PGP signature

[gentoo-dev] [gentoo-dev-announce] Last rites: dev-java/excalibur-logger

[Patrice Clement]

# Patrice Clement monsie...@gentoo.org (25 May 2015)
# Upstream dead. Project no longer supported by the ASF 
# who moved it into the Attic in 2010.
# See #550326. Masked for removal in 30 days.
dev-java/excalibur-logger


pgphGZTVlwCAX.pgp
Description: PGP signature

Re: [gentoo-dev] more packages up for grabs

[Patrice Clement]

Monday 18 May 2015 17:13:41, Tim Harder wrote :
 Here are some packages that I've dropped (or will drop) myself as
 primary maintainer from. Many of them (e.g. protobuf*) could really use
 some more collaborative non-maintainer update method but no one has
 gotten around to finalizing, documenting, and implementing the required
 metadata.xml changes yet as far as I know.
 
 * app-misc/pfm
 * www-client/links
 * www-misc/urlwatch
 
 If you have questions about any of them feel free to drop me a line.
 
 Thanks,
 Tim

Hey Tim

I'd love to pick these up. In particular links: always been fond of it. :)

Cheers,
Patrice


pgp3G_Kfuhleh.pgp
Description: PGP signature

[gentoo-dev] [gentoo-dev-announce] Last rites: dev-java/xt

[Patrice Clement]

# Patrice Clement monsie...@gentoo.org) (13 May 2015)
# Unused package, homepage dead, no revdeps.
# Fails to compile with recent JVMs, see bug #549090.
# Last release dates back to 2010.
# Masked for removal in 30 days.
dev-java/xt


pgpWovcCCDB1E.pgp
Description: PGP signature

[gentoo-dev] [gentoo-dev-announce] Last rites: dev-java/openjms

[Patrice Clement]

# Patrice Clement monsie...@gentoo.org (14 Apr 2014)
# Upstream seems to be dead. No updates since 12 March 2007.
# Masked for removal in 30 days. See bug 546506.
dev-java/openjms


pgpoUgIhksvEx.pgp
Description: PGP signature