Re: [gentoo-dev] About merging "ayatana", "indicator", "libindicate", "appindicator" in one global USE flag

[NP-Hardass]

On 4/6/20 9:23 AM, Pacho Ramos wrote:
> El jue, 02-04-2020 a las 16:28 +0200, Pacho Ramos escribió:
>> Hello,
>>
>> I was reviewing about how to enable globally on my system the usage of
>> libappindicator and I realized that we have multiple names for that in the
>> tree.
>> "ayatana" is the only global one, while other packages are using "indicator",
>> "libindicate", "appindicator"...
>>
>> Personally I would merge all them in only one, and I wonder if maybe
>> "indicator"
>> or "appindicator" would be more meaningful for most users than "ayatana", 
>> what
>> do you think?
>>
>> Thanks
> 
> Personally I would opt for global "appindicator" as it seems to be more widely
> used and I think it is a bit more self-explanatory :/
> 

SGTM

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] virtualx.eclass: Append RESTRICT="!test? ( test )" by default

[NP-Hardass]

On 12/11/19 9:58 AM, Michał Górny wrote:
> Append RESTRICT="!test? ( test )" in the default case when virtualx
> is conditional to USE=test.  This fixes 440 MissingTestRestrict
> warnings.
> 
> Signed-off-by: Michał Górny 
> ---
>  eclass/virtualx.eclass | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
> index 40eeea5463bc..6aba6bf488dd 100644
> --- a/eclass/virtualx.eclass
> +++ b/eclass/virtualx.eclass
> @@ -89,6 +89,8 @@ case ${VIRTUALX_REQUIRED} in
>   fi
>   RDEPEND=""
>   IUSE="${VIRTUALX_REQUIRED}"
> + [[ ${VIRTUALX_REQUIRED} == test ]] &&
> + RESTRICT+=" !test? ( test )"
>   ;;
>  esac
>  
> 

Is there a better way to address this than editing a ton of eclasses
independently?

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

[NP-Hardass]

ewarn ""
> + ewarn "Kernel requires all modules to be signed and 
> verified"
> + ewarn "please enable USE=\"module-sign\""
> + ewarn "otherwise loading the module will fail"
> + die "signature required"
> + fi
> + fi
> +}
> +
>  # @FUNCTION: use_m
>  # @RETURN: true or false
>  # @DESCRIPTION:


The documentation for linux_chkconfig_present states "If
linux_config_exists returns false, the results of this are UNDEFINED.
You MUST call linux_config_exists first."
> @@ -352,6 +397,28 @@ get-KERNEL_CC() {
>   echo "${kernel_cc}"
>  }
>  
> +# @FUNCTION: sign_module
> +# @DESCRIPTION:
> +# Sign a kernel module if enabled and supported, or just silently ignore the 
> request and do nothing.
> +# @USAGE: 
> +sign_module() {
> + debug-print-function ${FUNCNAME} $*
> +
> + if use module-sign; then
> + local sig_hash sig_pem sig_x509 modulename
> + sig_hash=$(linux_chkconfig_string MODULE_SIG_HASH)
> + sig_pem="${KV_DIR}/certs/signing_key.pem"
> + sig_x509="${KV_DIR}/certs/signing_key.x509"
> + modulename=$(basename "${1}")
> +
> + einfo "Signing ${modulename}"
> + "${KV_DIR}"/scripts/sign-file \
> + "${KERNEL_MODULE_SIG_HASH:-${sig_hash//\"/}}" \
> + "${KERNEL_MODULE_SIG_PEM:-${sig_pem}}" \
> + "${KERNEL_MODULE_SIG_X509:-${sig_x509}}" \
> + "${1}" || die "Signing ${modulename} failed"
> + fi
> +}
>  # internal function
>  #
>  # FUNCTION:

These KV_DIRs should be KV_OUT_DIRs, as they are objects only available
after building the kernel and thus if KV_OUT_DIR != KV_DIR, this will fail.

The documentation for linux_chkconfig_string states "If
linux_config_exists returns false, the results of this are UNDEFINED.
You MUST call linux_config_exists first."

Additionally, sig_pem and sig_x509 should be derived from MODULE_SIG_KEY.

> @@ -583,12 +650,17 @@ linux-mod_pkg_setup() {
>   # External modules use kernel symbols (bug #591832)
>   CONFIG_CHECK+=" !TRIM_UNUSED_KSYMS"
>  
> + # if signature is requested, check if kernel actually supports it
> + use module-sign && CONFIG_CHECK+=" MODULE_SIG"
> +
>   linux-info_pkg_setup;
>   require_configured_kernel
>   check_kernel_built;
>   strip_modulenames;
>   [[ -n ${MODULE_NAMES} ]] && check_modules_supported
>   set_kvobj;
> + use module-sign && export STRIP_MASK="*.${KV_OBJ}";
> + check_sig_force;
>   # Commented out with permission from johnm until a fixed version for 
> arches
>   # who intentionally use different kernel and userland compilers can be
>   # introduced - Jason Wever <we...@gentoo.org>, 23 Oct 2005
> @@ -716,8 +788,9 @@ linux-mod_src_install() {
>  
>   einfo "Installing ${modulename} module"
>   cd "${objdir}" || die "${objdir} does not exist"
> - insinto /lib/modules/${KV_FULL}/${libdir}
> - doins ${modulename}.${KV_OBJ} || die "doins 
> ${modulename}.${KV_OBJ} failed"
> + sign_module "${modulename}.${KV_OBJ}"
> + insinto /lib/modules/"${KV_FULL}/${libdir}"
> + doins "${modulename}.${KV_OBJ}" || die "doins 
> ${modulename}.${KV_OBJ} failed"
>   cd "${OLDPWD}"
>  
>   generate_modulesd "${objdir}/${modulename}"
> 


You can work around the STRIP_MASK issue by performing the steps in
pkg_postinst after the stripped modules have been installed. You could
probably save a list of installed modules a la
gnome2_gconf_savelist and then pull that up in postinst and sign the
desired modules there.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: How to deal with git sources?

[NP-Hardass]

On 03/15/2018 07:20 PM, Martin Vaeth wrote:
> Vadim A. Misbakh-Soloviov <gen...@mva.name> wrote:
>>
>> GH support answered me (in TL;DR version) "that's because we've upgraded git
>> on *some* of our nodes" (means, some other using older git)
> 
> That would still require that the "git archive" output would have
> changed in some recent git versions. And at least between the most
> current 2.16.2 and comparing with all my git tarballs (some as
> mentioned rather old), I could not produce any difference.
> So I still do not understand what should be going on.
> 
> 

IIRC, it was attributed to
https://github.com/git/git/commit/22f0dcd9634a818a0c83f23ea1a48f2d620c0546

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Managing updates on many identical Gentoo systems

[NP-Hardass]

On 01/18/2018 07:34 AM, Lars Wendler wrote:
> Hi Anthony,
> 
[...]
> 
> well, I never did anything like that but regarding the dependency
> calculation... how about something like
> 
> emerge -1OKanv $(qlist -CISq)
> 
> (--oneshot --nodeps --usepkgonly --ask --noreplace --verbose)
> 
> which simply omits dependency calculations, only takes into account
> available binary packages and doesn't replace same versions?
> Of course this requires all installed packages really being available as
> binpkgs.
> Since all the installations are the same, as long as you provide a sane
> set of binpkgs, dependency calculation should not matter anyway.
> The only issue I can think of is that a system might become broken if
> the update gets interrupted before all packages have been updated.
> 
> Kind regards
> 

TTBOMK, this will fail also if there is a slot change.  For instance,
with the recent autoconf-2.69 move from :0 to :2.69, dependency
resolution would have resulted softblock, thus removing :0 and then
merging :2.69 automatically. with a --nodeps, :2.69 would attempt to
merge without removing :0 for this package, resulting in an emerge failure.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News Item: Old Wine Versions Moving to Wine Overlay

[NP-Hardass]

On 11/28/2017 12:44 PM, Ulrich Mueller wrote:
>>>>>> On Tue, 28 Nov 2017, Ulrich Mueller wrote:
> 
>> It has a malformed signature [...]
> 
> Also, in News-Item-Format 2.0 there is no "Content-Type:" header.
> Sorry for not having noticed this during the review phase.
> 
> Ulrich
> 

Fixed.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News Item: Old Wine Versions Moving to Wine Overlay

[NP-Hardass]

On 11/28/2017 12:36 PM, Ulrich Mueller wrote:
>>>>>> On Tue, 28 Nov 2017, NP-Hardass  wrote:
> 
>> Committed with recommended changes
> 
> It has a malformed signature:
> 
> $ gpg --verify 2017-11-21-old-wine-versions-moving-to-overlay.en.txt.asc
> [...]
> gpg: WARNING: not a detached signature; file 
> '2017-11-21-old-wine-versions-moving-to-overlay.en.txt' was NOT verified!
> 
Fixed.  Sorry about that.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News Item: Old Wine Versions Moving to Wine Overlay

[NP-Hardass]

On 11/22/2017 02:55 AM, Michał Górny wrote:
> W dniu śro, 22.11.2017 o godzinie 01∶55 -0500, użytkownik NP-Hardass
> napisał:
>> Would like to get this out within the next day if no-one sees any issues.
>>
>> Thanks!
>> Title: Old Wine versions moving to wine-overlay
>> Author: NP-Hardass <np-hard...@gentoo.org>
>> Content-Type: text/plain
>> Posted: 2017-11-21
>> Revision: 1
>> News-Item-Format: 2.0
>> Display-If-Installed: app-emulation/wine:0
>> Display-If-Installed: app-emulation/wine-vanilla
>> Display-If-Installed: app-emulation/wine-staging
>> Display-If-Installed: app-emulation/wine-d3d9
>> Display-If-Installed: app-emulation/wine-any
>>
>> To reduce the burden on main Gentoo repository, older versions of Wine
>> will be available only in the wine overlay. These ebuilds will still be
>> fully supported by the Gentoo Wine Project.  This will result in
>> upstream stable releases and the several most recent upstream devel
>> releases being the only versions in ::gentoo; all versions meeting the
>> criteria for support within Gentoo [1] will be available in ::wine.
>>
>> To install the overlay you can either add the repos.conf file to your
>> portage configuration directory or add the repository via layman.
> 
> What about eselect-repository? ;-P
> 
>> * To add the repos.conf file:
>> # wget https://gitweb.gentoo.org/repo/proj/wine.git/plain/wine.conf -O \
> 
> Infra strongly discourages fetching straight from cgit. This is not
> guaranteed to be stable.
> 
>> /etc/portage/repos.conf/wine.conf
>>
>> Edit the /etc/portage/repos.conf/wine.conf file so that "location"
>> points to your desired folder to install the overlay.
>> # emaint sync --repo wine
>>
>> * To install the overlay via layman:
>> # layman -a wine
> 
> It's kinda surprising to see this after the repos.conf solution since it
> was mentioned first.
> 
>>
>> [1]
>> https://wiki.gentoo.org/wiki/Project:Wine/Policies_and_Procedures#Supported_versions
> 

Committed with recommended changes

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] News Item: Old Wine Versions Moving to Wine Overlay

[NP-Hardass]

Would like to get this out within the next day if no-one sees any issues.

Thanks!
Title: Old Wine versions moving to wine-overlay
Author: NP-Hardass <np-hard...@gentoo.org>
Content-Type: text/plain
Posted: 2017-11-21
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-emulation/wine:0
Display-If-Installed: app-emulation/wine-vanilla
Display-If-Installed: app-emulation/wine-staging
Display-If-Installed: app-emulation/wine-d3d9
Display-If-Installed: app-emulation/wine-any

To reduce the burden on main Gentoo repository, older versions of Wine
will be available only in the wine overlay. These ebuilds will still be
fully supported by the Gentoo Wine Project.  This will result in
upstream stable releases and the several most recent upstream devel
releases being the only versions in ::gentoo; all versions meeting the
criteria for support within Gentoo [1] will be available in ::wine.

To install the overlay you can either add the repos.conf file to your
portage configuration directory or add the repository via layman.

* To add the repos.conf file:
# wget https://gitweb.gentoo.org/repo/proj/wine.git/plain/wine.conf -O \
/etc/portage/repos.conf/wine.conf

Edit the /etc/portage/repos.conf/wine.conf file so that "location"
points to your desired folder to install the overlay.
# emaint sync --repo wine

* To install the overlay via layman:
# layman -a wine

[1]
https://wiki.gentoo.org/wiki/Project:Wine/Policies_and_Procedures#Supported_versions
-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: No more stable keywords for Games

[NP-Hardass]

On 11/19/2017 01:45 PM, Philip Webb wrote:
> 171119 James Le Cuirot wrote:
>> On Sun, 19 Nov 2017 08:50:20 -0500
>> Philip Webb <purs...@ca.inter.net> wrote:
>>> 171118 David Seifert wrote:
>>>> As the Games team does not have enough manpower to keep tabs on all
>>>> games packages, we have dropped all games-* ebuilds to unstable
>>>> keywords (modulo those required by stable non-games packages).
>>> Isn't this overkill in the absence of widespread bug reports for games ?
>>> 'Stable' doesn't mean well-maintained,
>>> but in the tree for some time & no serious bug reports.
>> There are plenty of bug reports for games.
> 
> What percentage of games pkgs have bugs ?
> 
> Eg I amuse myself with  games-puzzle/sgt-puzzles ;
> it is maintained upstream with regular updates.
> The only unresolved bug appears to be 602696
> which relates to version 20161207, which is no longer in the tree :
> why is the bug still marked 'confirmed' ?  Shouldn't it be 'resolved' ?
> 
> What justification is there for marking this pkg 'unstable' ?
> My guess is that there are other games pkgs with no valid bug.
> 
> Marking all games 'unstable' still seems to be overkill.
> 

I am going to add my +1 to overkill.

Firstly, we need to reclarify...  Games Project doesn't have exclusive
control over the games-* categories...  So, this should only apply to
packages that the games project controls.  The original message doesn't
really convey that.

Secondly, if the issue is Games Project, then if there is another
maintainer involved in maintaining a package, then the decision to drop
keywords should be mutual with the other maintainer, or Games should
consider dropping maintainership in deference to the other, active
maintainer.

Which brings me to the third point...  If the Games Project admits that
it doesn't have the manpower to maintain things, and is forcibly
dropping all stable keywords as part of their non-maintenance, I think
they should adopt a policy of allowing anyone to come in and take over
(and potentially remove them) from the package.  Someone else should be
able to vouch for and work for the stability and quality of a package
and take responsibility for it.  By Games Project being in the metadata,
it gives the false impression that they are responsible.

I'm the maintainer of games-puzzle/sgt-puzzles and while Games Project
is in the metadata, I'm really the primary maintainer.  I don't want my
stable keywords dropped.  You are welcome to drop your project from the
metadata, but please leave my package, and all those that others are
responsible for, alone.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Java 9 on Gentoo

[NP-Hardass]

On 11/17/2017 04:15 AM, William L. Thomson Jr. wrote:
> On Fri, 17 Nov 2017 03:24:47 -0500
> "William L. Thomson Jr." <wlt...@o-sinc.com> wrote:
>>
>> The icedtea from source ebuild is a result of RedHat. The main person
>> at RedHat responsible for their open source Java is the author of
>> Icedtea. He uses Gentoo as his development/test platform. Gentoo
>> usually will have that at least the same time as others, if not before
>> all others.
>>
>> If it was not for him, and RedHat paying him. I doubt Gentoo would
>> have from source Java. Not to discount Chewi/James efforts. But the
>> author of Icedtea is the one maintaining that in java-overlay.
> 
> Something to keep in mind. Part of why Icedtea lags like with Java 9.
> The Icedtea author as part of their role at RedHat is responsible for
> older versions as well. Much of their time is consumed in dealing with
> older. Thus the latest does not always get as much time, or 100%.
> 
> Next month 1.6 ends, but with 9 out not sure it helps. Still has 1.7
> and 1.8 for some time to come. They have to maintain 3 versions...
> https://access.redhat.com/articles/1299013
> 

Oh come on!

Triple posting to the ML?

Do we really need to have another discussion about not being spammy...
Please... Think before you post...

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] manifest-hashes changing to 'BLAKE2B SHA512' on 2017-11-21

[NP-Hardass]

On 11/15/2017 12:47 PM, R0b0t1 wrote:
> On Wednesday, November 15, 2017, Michał Górny <mgo...@gentoo.org
> <mailto:mgo...@gentoo.org>> wrote:
>> Hi, everyone.
>>
>> The Council has approved the manifest-hashes switch on 2017-11-12
>> meeting [1]. The transition will occur to the initial plan, with small
>> changes. The updated plan is included at the end of this mail.
>>
>> According to this plan, BLAKE2B will be enabled on 2017-11-21. This
>> means that starting at this time, all new and updated DIST entries will
>> use BLAKE2B+SHA512. Old DIST entries will still use the current hash set
>> until updated.
>>
>> The developers are required to upgrade to a package manager supporting
>> this hash. That is:
>>
>> a. Portage 2.3.5 when using py3.6+,
>>
>> b. Portage 2.3.13 + pyblake2 installed manually,
>>
>> c. Portage 2.3.13-r1 that includes the pyblake2 dep.
>>
>> Modern (and old) Portage will refuse to update Manifests if it does not
>> support the necessary hashes. However, Portage versions between 2.3.5
>> and 2.3.13 inclusively will create Manifests missing BLAKE2B hash rather
>> than failing when no hash provider is present. Those Manifests will be
>> rejected by the git hook.
>>
>> Users will not be affected noticeably as the SHA512 hash continues being
>> used for compatibility.
>>
>>
>> That said, I'd like to request developers not to start proactively
>> converting all old Manifest entries to the new set immediately,
>> and instead give some time for things to settle down.
>>
>>
>>
>> The updated plan
>> 
>>
>> Already done:
>>
>> - revbumped Portage with pyblake2 dep and started stabilizing it,
>>
>> - added git update hook to reject invalid Manifest entries.
>>
>> 2017-11-21 (T+7d):
>>
>> - manifest-hashes = BLAKE2B SHA512
>>
>> 2018-02-14 (T+3m):
>>
>> - manifest-required-hashes = BLAKE2B
>>
>> 2018-05-14 (T+6m):
>>
>> - last rite fetch-restricted packages that do not use BLAKE2B.
>>
>> The final removal of SHA512 will be decided by the Council separately.
>>
> 
> Does the existence of a decision mean I would need to contact the
> trustees if I feel the changes have not been adequately justified?
> 
> Respectfully,
>     R0b0t1

No, if you think there is an issue with the Council decision, you should
speak with the Council.  Moreover... The Council is responsible for
technical decisions within Gentoo.  Unless it violates the Social
Contract, I cannot see how the Trustees should be involved here.  They
have empowered the Council to make technical decisions as they see fit.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Last-rites: media-sound/qtmpc

[NP-Hardass]

On 09/25/2017 08:12 PM, Andreas Sturmlechner wrote:
> Am Dienstag, 26. September 2017 02:01:45 CEST schrieb NP-Hardass:
>> Can you try sending your last-rites as independent compositions going
>> going forward and see if that resolves the issue?
> 
> Yes, definitely. I've just been slacking with my email setup(s) since my
> laptop has died.
> 

Thanks ^_^

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Last-rites: media-sound/qtmpc

[NP-Hardass]

On 09/25/2017 07:31 PM, Andreas Sturmlechner wrote:
> # Andreas Sturmlechner <ast...@gentoo.org> (26 Sep 2017)
> # Requires dead Qt 4. Dead upstream. Use media-sound/cantata
> # instead, which originally started as a QtMPC fork but is
> # much more advanced. Masked for removal in 30 days.
> media-sound/qtmpc
> 
> 
Not sure if it is just me, but when you fire off these messages as you
are doing (as replies to others), they are coming across as submessages
in the threads of previous ones instead of independent ones, and
additionally, I'm not seeing any of them in gentoo-dev-announce.  Can
you try sending your last-rites as independent compositions going
forward and see if that resolves the issue?

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[NP-Hardass]

On 07/07/2017 04:38 PM, James Le Cuirot wrote:
> On Fri, 7 Jul 2017 12:48:04 -0400
> NP-Hardass <np-hard...@gentoo.org> wrote:
> 
>> There is actually a huge functional difference between the two that you
>> are missing here.  A meta package defines its dependencies in full
>> dependency syntax.  This means you can specify versions, USE flag
>> dependencies, make packages dependent on USE flags, etc.  A package set
>> is just a list of packages (potentially constrained by version.  TTBOMK,
>> there is no inclusion of any USE flag functionality in sets.
>> Additionally, let's say you have a more complicated dependency like || (
>> A B ),  I don't think there is a way to describe that in a package set
>> at all.
> 
> Actually you can specify basic USE dependencies in sets. You can also
> specify SLOTs. For example, this is valid.
> 
> media-libs/tiff:3[abi_x86_32,jpeg,zlib,-cxx]
> 

Didn't realize that.  Good to know.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[NP-Hardass]

On 07/07/2017 01:05 PM, William L. Thomson Jr. wrote:
> On Fri, 7 Jul 2017 12:48:04 -0400
> NP-Hardass <np-hard...@gentoo.org> wrote:
>>
>> There is actually a huge functional difference between the two that
>> you are missing here.  A meta package defines its dependencies in full
>> dependency syntax.  This means you can specify versions, USE flag
>> dependencies, make packages dependent on USE flags, etc.  A package
>> set is just a list of packages (potentially constrained by version.
>> TTBOMK, there is no inclusion of any USE flag functionality in sets.
>> Additionally, let's say you have a more complicated dependency like
>> || ( A B ),  I don't think there is a way to describe that in a
>> package set at all.
> 
> All valid points, but there maybe times when such is not needed.
> 
> You cannot really do any of that easily via a profile either. You just
> have packages file in a profile. You can use the other stuff, but I am
> talking about sets. Just as packages are listed in a packages file in a
> profile. Being able to list a package set, vs those same packages.
> There is no difference there.
> 

Yeah, but I'm not wild about the prospect of handling some packages via
one method, and others via another.  Could you imagine if half of your
@system packages were broken up into subsets, and half were left as is?
The lack of uniformity would unnecessarily complicate things IMO.

>> I'm not sure I see the merit in pushing for package sets in the bulk
>> of cases for this reason.  Maybe there is some scenario where package
>> sets are a better option, but you haven't enumerated what that might
>> be (and I'm not really interested in brainstorming until I come up
>> with one, so I'll wait for one frmo someone else)
> 
> Not sure I need to show a case example of where sets are better than
> meta packages. Its more I want to use sets and I would like to be able
> to include those package sets in a profile.
>  

Then why are we in a topic comparing metas and sets? :P  Sounds like the
best thing is to change this whole topic into an RFC for profile-enabled
sets and file a bug report feature requesting it after getting feedback.

>> Of course, my sets knowledge is a little limited compared to some
>> people, so if something I've said about package sets is incorrect,
>> please feel free to correct it.
> 
> You cannot remove all packages ( short of dep clean ) or re-emerge all
> packages from a meta ebuild easily. You can from a set.

This is two-tiered in both cases anyway, no?
Meta:
# Remove meta
emerge --depclean meta
# Remove all packages in the meta and their pulled in deps
emerge --depclean
Set:
# Remove set
emerge --depclean @set
# clean up all deps pulled in from the set
emerge --depclean

> 
> Sets do have their uses. I think they are not used much for a variety
> of reasons, but likely could be used more.
> 

Sure, but when the thread is "Sets vs Metas" it makes it hard to simply
"make a case for using one more than currently" since instead, you are
inviting a comparison argument, which, as I've said, I think fails to
convince.  Like I said, if your goal is simply to propose enabling
further use of sets, let's work on that, rather than get distracted with
a whole separate issue.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[NP-Hardass]

On 07/07/2017 12:32 PM, William L. Thomson Jr. wrote:
> I have been playing with some package sets and I like the concept of
> sets quite a lot. However there is one big drawback. You cannot use a
> package set in a profile. Or at least I do not think you can. I have
> looked into it a bit and does not seem like it is possible.
> 
> I know I can create a meta ebuild and use it like a package set. I
> think it would be useful to have package sets be able to be used in a
> profile like meta ebuilds. It would likely reduce the need or use of
> meta packages. Not sure if there is any benefit to that approach over a
> set.
> 
> I think sets have benefits over meta packages. This was the most
> comprehensive document on sets, benefits, uses, etc. Other than the
> general docs on the wiki.
> https://makuro.wordpress.com/2010/12/12/intro-to-portage-sets/
> 
> I  would really like to be able to use package sets in profiles. I
> think of use and benefit to others as well.
> 

There is actually a huge functional difference between the two that you
are missing here.  A meta package defines its dependencies in full
dependency syntax.  This means you can specify versions, USE flag
dependencies, make packages dependent on USE flags, etc.  A package set
is just a list of packages (potentially constrained by version.  TTBOMK,
there is no inclusion of any USE flag functionality in sets.
Additionally, let's say you have a more complicated dependency like || (
A B ),  I don't think there is a way to describe that in a package set
at all.

I'm not sure I see the merit in pushing for package sets in the bulk of
cases for this reason.  Maybe there is some scenario where package sets
are a better option, but you haven't enumerated what that might be (and
I'm not really interested in brainstorming until I come up with one, so
I'll wait for one frmo someone else)

Of course, my sets knowledge is a little limited compared to some
people, so if something I've said about package sets is incorrect,
please feel free to correct it.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News item: app-emulation/wine split and slotting

[NP-Hardass]

On 04/10/2017 02:17 PM, Michał Górny wrote:
> On pon, 2017-04-10 at 13:52 -0400, NP-Hardass wrote:
>> On 04/10/2017 01:31 PM, Michał Górny wrote:
>>> So, the whole idea is that you can install vanilla and e.g. staging
>>> side-by-side?
>>
>> That's 50% of it.  The other 50% is that since Windows applications
>> often are better supported in one version or another, you can also have
>> multiple versions installed side by side (=wine-vanilla-2.1 and
>> =wine-vanilla-2.2 for example)
>>>
>>> Is 'any' always called 'any'? Does it mean that I can have installed
>>> e.g. 'any[staging]' and 'staging', and both would be the same thing?
>>>
>>
>> Right.  We were sort of at a loss for the best way to signify to the
>> user that any is for them to do whatever they want with (even if it is
>> redundant).  Giving it the -any suffix was our best idea XD  That said,
>> the virtual places -any in priority last, so the usually more or less
>> has to consciously decide to use it (which would for the most part avoid
>> accidental redundancy)  The two primary uses of any *should* be using
>> multiple patchsets simultaneously (any[d3d9,staging])  and using any to
>> slightly alter flags from any of the others (example in the news item
>> given as using one audio system in -vanilla (gstreamer) and another in
>> -any (pulseaudio))
> 
> Honestly? I don't like that. I can see your point but I feel like it's
> pretty much having app-emulation/wine1, /wine2, /wine3... whose only
> purpose would be to allow having different USE flag sets.
Yes and no.  This goes back to the discussion a couple of weeks ago
(your thread actually "How to deal with package forks"[1]) about
separating out packages for large external patchsets.   This falls under
your category 2.  Previously it was 2B, and this change pushes it to 2A.
Snippet:
> 2. large patch sets / continuously rebased forks -- where the particular
> set of changes is usually applied to mainline or regularly rebased
> against mainline but without full separation (kernel patchsets, bitcoin
> patches);
[...]
> 
> The second group (patch sets) is more unclear. AFAICS some people argue
> that packages with major patch sets applied should be distinguished by
> separate package names. Others see that applying them via USE flags is
> easier.
> 
> Separate packages are used e.g. for different kernel patch sets. This
> has the following advantages:
> 
> 2a1. more clear distinction between base and patched version,
> 
> 2a2. cleaner when patch sets imply major changes, e.g. when some
> of the USE flags apply to patched version only,
> 
> 2a3. the packages can be bumped independently, without worrying that
> the patch set has not been updated yet.
> 
> A single package with USE flags is used e.g. for openssl (hpn patch
> set), bitcoincore (ljr patch set). This has the following advantages:
> 
> 2b1. available patches are cleanly exposed via USE flags,
> 
> 2b2. multiple patch sets can be combined in a single package,
> 
> 2b3. usually there is less work for the package maintainer.

In this case, Wine-Staging and Ixit's Gallium Nine both package
separately and often prefer to be packaged in distros separately.
Staging is a very large patchset, and Gallium Nine is a regularly
rebased but without full separation patchset.  Currently, Sarnex
generates our d3d9 patchset for us.  The package split isn't arbitrary,
it's only along large independent patchsets (effectively separate
upstreams).

> 
> While of course there's really no reason to technically force all
> variants to have the same USE flags, I'm against encouraging users to
> fiddle with that more than necessary. That's an easy way to get them
> confused a lot. Just imagine that the flags set for app-emu/wine now you
> have to set for 4 packages consistently, and remember to update them or
> switching between variants is going to result in an accidental different
> build.
> 
I can't speak for other users, but on the existing packaging, apart from
the patchset specific flags, I almost never touch the defaults on the
other flags.  Most of the flags that I know users care about are either
set by profile or are related to the one of the patchsets.
> Plus, IMHO the '-any' name is just weird. What are you going to do when
> you introduce a third patch set? Will you add four more ebuilds to cover
> all the bases? ;-)
> 
Internally, we had a discussion about this.  No, we aren't going to make
2^N packages.  Just one per large independent patchset, and one that the
user can use at their discretion if they are a power user (either as a
2B type package or as they so choose changing other sets of flags if
they want).  So if a new up and coming pat

Re: [gentoo-dev] News item: app-emulation/wine split and slotting

[NP-Hardass]

On 04/10/2017 01:31 PM, Michał Górny wrote:
> So, the whole idea is that you can install vanilla and e.g. staging
> side-by-side?

That's 50% of it.  The other 50% is that since Windows applications
often are better supported in one version or another, you can also have
multiple versions installed side by side (=wine-vanilla-2.1 and
=wine-vanilla-2.2 for example)
> 
> Is 'any' always called 'any'? Does it mean that I can have installed
> e.g. 'any[staging]' and 'staging', and both would be the same thing?
> 
Right.  We were sort of at a loss for the best way to signify to the
user that any is for them to do whatever they want with (even if it is
redundant).  Giving it the -any suffix was our best idea XD  That said,
the virtual places -any in priority last, so the usually more or less
has to consciously decide to use it (which would for the most part avoid
accidental redundancy)  The two primary uses of any *should* be using
multiple patchsets simultaneously (any[d3d9,staging])  and using any to
slightly alter flags from any of the others (example in the news item
given as using one audio system in -vanilla (gstreamer) and another in
-any (pulseaudio))

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News item: app-emulation/wine split and slotting

[NP-Hardass]

Posted

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] News item: app-emulation/wine split and slotting

[NP-Hardass]

Plan is to move the packages into the repo as masked shortly after final
approval of the news item.  At that point, any testers would be greatly
appreciated.

The split is a little confusing for those new to the concept and there
have already been several internal revisions to help convey the purpose
of the multiple new packages.  If you don't think it is clear, please
let me know any suggestions you might have on the wording.



Title: app-emulation/wine split and slotting
Author: NP-Hardass <np-hard...@gentoo.org>
Content-Type: text/plain
Posted: 2017-03-27
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-emulation/wine:0

Starting with Wine 2.0, Wine in Gentoo is transitioning away from its
traditional packaging and toward a new, split and slotted, Wine.

As many Wine users know, there are often regressions or an application
works better on one version of wine than another.  Going forward,
packaging in Gentoo will allow simultaneous installation of multiple
versions of Wine.

Additionally, to expedite vanilla releases as well as permit multiple
configurations for each Wine installation, the major patchsets have
been split out into separate packages.

Going forward, app-emulation/wine will transition to:
app-emulation/wine-vanilla: upstream Wine with no external patchsets
 (like if the old packaging forced USE="-staging -d3d9")
app-emulation/wine-staging: Wine with Wine-Staging's patchset
 (like if the old packaging forced USE="+staging -d3d9")
app-emulation/wine-d3d9: Wine with Ixit's Gallium Nine patchset
 (like if the old packaging forced USE="-staging +d3d9")
app-emulation/wine-any: Wine with any of the patchsets or flags
 (exactly like the old packaging regarding USE flags)

wine-any exists to allow the user to build any combination that they'd
like (like the old packaging).  This means the user could use wine-any
to use both Wine-Staging and Gallium Nine.  Alternatively, the user
could use wine-any to try out another configuration from other
packages.  For example, the user could build wine-vanilla without
PulseAudio, and could build wine-any with PulseAudio.  The sky is the
limit on how a user may choose to use app-emulation/wine-any.

Users may opt for any specific package, or may emerge virtual/wine,
which is provided for dependency resolution.
Maintainers: Please note, app-emulation/wine will be dropped, so
please use virtual/wine going forward.

Users may call each version specifically, or may call a symlink based
on their installed patchset, for example wine-2.1, wine-staging-2.2,
or wine-d3d9.

Symlinks for wine are managed with app-eselect/eselect-wine.
# eselect wine set wine-vanilla-2.0
/usr/bin/wine -> /usr/bin/wine-vanilla-2.0
# eselect wine set --staging wine-staging-2.4
/usr/bin/wine-staging -> /usr/bin/wine-staging-2.4



-- 
NP-Hardass
Title: app-emulation/wine split and slotting
Author: NP-Hardass <np-hard...@gentoo.org>
Content-Type: text/plain
Posted: 2017-03-27
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-emulation/wine:0

Starting with Wine 2.0, Wine in Gentoo is transitioning away from its
traditional packaging and toward a new, split and slotted, Wine.

As many Wine users know, there are often regressions or an application
works better on one version of wine than another.  Going forward, 
packaging in Gentoo will allow simultaneous installation of multiple
versions of Wine.

Additionally, to expedite vanilla releases as well as permit multiple
configurations for each Wine installation, the major patchsets have
been split out into separate packages.

Going forward, app-emulation/wine will transition to:
app-emulation/wine-vanilla: upstream Wine with no external patchsets
 (like if the old packaging forced USE="-staging -d3d9")
app-emulation/wine-staging: Wine with Wine-Staging's patchset
 (like if the old packaging forced USE="+staging -d3d9")
app-emulation/wine-d3d9: Wine with Ixit's Gallium Nine patchset
 (like if the old packaging forced USE="-staging +d3d9")
app-emulation/wine-any: Wine with any of the patchsets or flags
 (exactly like the old packaging regarding USE flags)

wine-any exists to allow the user to build any combination that they'd
like (like the old packaging).  This means the user could use wine-any
to use both Wine-Staging and Gallium Nine.  Alternatively, the user
could use wine-any to try out another configuration from other
packages.  For example, the user could build wine-vanilla without
PulseAudio, and could build wine-any with PulseAudio.  The sky is the
limit on how a user may choose to use app-emulation/wine-any.

Users may opt for any specific package, or may emerge virtual/wine,
which is provided for dependency resolution.
Maintainers: Please note, app-emulation/wine will be dropped, so
please use virtual/wine going forward.

Users may call each

[gentoo-dev] Last rites: app-emulation/crossover-office-bin app-emulation/crossover-office-pro-bin

[NP-Hardass]

# NP-Hardass <np-hard...@gentoo.org> (03 Apr 2017)
# Masked for removal in 30 days. Unable to generate new
# hashes for the manifest, per Bug #612720, Bug #612718
# Upstream has also deprecated these in favor of
# app-emulation/crossover-bin
app-emulation/crossover-office-bin
app-emulation/crossover-office-pro-bin

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New Virtual: virtual/wine

[NP-Hardass]

On 03/27/2017 08:55 PM, Ulrich Mueller wrote:
>>>>>> On Mon, 27 Mar 2017, NP-Hardass  wrote:
> 
>> This is part of the usual for discussing new virtuals before
>> addition. I'm reaching the final stages of prep for migrating from
>> app-emulation/wine to several packages, one for each major patchset
>> that we support. This will enable us to get releases out quicker.
>> In addition, with the new packaging, we'll be supporting slotting,
>> so users can choose to support specific apps with specific wine
>> versions or patchsets simultaneously. More specifics on that to come
>> in an email about a news item.
> 
> The empty HOMEPAGE, SRC_URI, LICENSE, and DEPEND assignments should be
> omitted.
> 
> Ulrich
> 

Updated on the wine-a-holics overlay where we are testing it all out.
Thanks.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] New Virtual: virtual/wine

[NP-Hardass]

This is part of the usual for discussing new virtuals before addition.

I'm reaching the final stages of prep for migrating from
app-emulation/wine to several packages, one for each major patchset that
we support. This will enable us to get releases out quicker.  In
addition, with the new packaging, we'll be supporting slotting, so users
can choose to support specific apps with specific wine versions or
patchsets simultaneously.  More specifics on that to come in an email
about a news item.

I'm not planning on immediately switching over, but rather masking for
maybe a month or so before releasing to the public at large.

-- 
NP-Hardass
# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

EAPI=6

DESCRIPTION="Virtual for WINE that supports multiple variants and slotting"
HOMEPAGE=""
SRC_URI=""

LICENSE=""
SLOT="0"
KEYWORDS="~amd64 ~x86"
IUSE="staging d3d9"

DEPEND=""
# Note, the ordering here is intentional, to take advantage of the short-circuit
# logic of portage, to enforce wine-vanilla as default for new users.  The idea
# behind this is that some USE flags may pull in 3rd-party patchsets, so default
# of vanilla prevents that.
RDEPEND="
staging? ( || (
app-emulation/wine-staging[staging]
app-emulation/wine-any[staging]
) )
d3d9? ( || (
app-emulation/wine-d3d9[d3d9]
app-emulation/wine-any[d3d9]
) )
|| (
app-emulation/wine-vanilla
app-emulation/wine-staging
app-emulation/wine-d3d9
app-emulation/wine-any
)
!app-emulation/wine:0"


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Printer drivers and net-print

[NP-Hardass]

On 02/23/2017 03:58 PM, Andrew Savchenko wrote:
> On Thu, 23 Feb 2017 18:50:45 +0100 Ulrich Mueller wrote:
>>>>>>> On Thu, 23 Feb 2017, Andrew Savchenko wrote:
>>
>>>> https://projects.gentoo.org/pms/6/pms.html#x1-180003.1.1 "Category Names"
>>
>>> I don't see a requirement here, only note on most common pattern:
>>
>>> ``Note: A hyphen is not required because of the virtual category.
>>> Usually, however, category names will contain a hyphen.''
>>
>> It is a note on what is the exclusive pattern, with the single
>> exception of the virtual category. I believe that we shouldn't break
>> that pattern.
> 
> I'm fine with this approach, but could PMS be updated to contain
> more clear statement to avoid misunderstanding? E.g.:
> ``all category names must contain a single hyphen with a
> special exception for "virtual"''
> 
> Best regards,
> Andrew Savchenko
> 

Might be best that this not be a PMS thing, but a Gentoo-specific
recommendation for developers conveyed via the Devmanual.  That's
typically the place where Gentoo specifics are added in, like "New
virtuals shouldn't be added without posting on the Gentoo mailing list,"
etc.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] REQUIRED_USE, global USE flags, user-friendliness...

[NP-Hardass]

On 01/27/2017 12:25 PM, Michael Orlitzky wrote:
> Forked from the gdbm/berkdb thread, wall of text ensues...
> 
> 
> On 01/27/2017 03:32 AM, Fabian Groffen wrote:
>>
>> You mention REQUIRED_USE should be used sparingly, I think I see your
>> reasoning, but if so, then why did we add it in the first place?
> 
> There are a few conflicting interests at play. Before REQUIRED_USE, we
> would have a bunch of checks in pkg_pretend() to test if the user's
> configuration was invalid. If it was, we could output a nice explanation
> and tell him to try again. But, bash code in pkg_pretend can't be
> understood by the package manager, and requires execution to determine
> if a package can be installed. So we got REQUIRED_USE, which fixes those
> problems, and introduces a new one: no one knows WTF to do when portage
> outputs a REQUIRED_USE error. Now you get what looks like a core dump of
> the dependency graph instead of "this package only uses one database, so
> pick either mysql or sqlite."
> 
> Both approaches have another problem: USE flag constraints on packages
> simply don't work with global USE flags. Global USE flags don't work
> that well to begin with, since the same flag means different things to
> each package (and the fact that they're global means "enable foo" is all
> we get for documentation). Regardless, when you have 100 flags enabled
> globally and start installing thousands of packages with USE
> constraints, you're eventually going to get to a point where everything
> has conflicting requirements and you need to switch to package.use to
> sort it all out.
> 
> Both pkg_pretend and REQUIRED_USE have that problem and try to solve it
> in different ways. If you don't care about machine-readability, then in
> pkg_pretend you could try to choose "the best" of two conflicting flags
> and just silently go with it. There are a lot of problems with that,
> like what happens if you need to add a conditional dependency on those
> flags (you can't change DEPEND in pkg_pretend). With REQUIRED_USE, you
> instead need to set IUSE defaults to get it to do something without user
> interaction, but the tricks that you can do with IUSE don't solve every
> REQUIRED_USE conflict. In the harder cases, you can try to figure out
> what to do on behalf of the user in the ebuild, but then you're right
> back to the same set of problems that you had with pkg_pretend, because
> the decision is being made in code and not in metadata/flags.
> 
> I think a slow migration away from global USE flags is the only way out
> of the jam. We get better USE flag docs for free, and no REQUIRED_USE
> conflicts that the user didn't cause himself. We could probably also get
> rid of a lot of IUSE defaults that serve only to undo various profile
> defaults. It would be annoying at first, but once a few critical profile
> defaults are moved into package.use, better.
> 

I might be wrong, but my suspicion is that those that advocate for
pkg_pretend over REQUIRED_USE tend to do so because of the blocking
nature of REQUIRED_USE's current implementation rather than the
construct of describing USE flag inter-dependencies itself.

So, personally, I think that we should be discussing ways of adding
interactivity to the package manager for resolution of REQUIRED_USE
conflicts rather than discussing ways to work around or remove it.  It's
a good construct, we should take advantage of it, and work to make it
more user friendly.

My initial feeling is having flags, one for interactive handling, one
for current behavior.  Interactive has two modes, like --autounmask and
--autounmask-write (and could even reuse these if possible), which does
something similar to how Debian's apt handles dependency conflicts by
calculating the alternatives and prompting the user to select a numbered
option.  So the autounmask equivalent displays the changes to the config
files and the autounmask-write equivalent writes them to the appropriate
config files.  This is just a general idea that I just came up with
right now, so I haven't put too much thought into it.  It is mostly
meant to get solutions for interactive handling discussed on the ML.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Fwd: Cron <gmirror@dipper> /usr/local/bin/pidlock -s rsync-gen /bin/bash /usr/local/bin/mastermirror/rsync-gen.sh

[NP-Hardass]

On 01/26/2017 06:48 PM, Doug Freed wrote:
> This is the email I get when a Manifest is missing DIST entries; it's
> more verbose than it needs to be, but I'd rather have more than less.
> In this particular case, the developer that made the bad commit likely
> had something they were working on in sys-cluster/torque added to the
> git index (ie, they did git add), and then needed to make an unrelated
> change, and didn't stash their changes beforehand.  You should always
> check 'git status' output before running repoman commit and/or git
> commit.  It's probably best to check before you start on a change, and
> then you can 'git stash -u' right away (the -u includes untracked
> files, which is useful if your in progress change is adding something
> new), and then after you've committed the change you wanted to get
> done right away, you can 'git stash pop' to get back to the state you
> were in before.
> 
> This particular issue has already been fixed, but I'll be forwarding
> all these emails to the list from now on (I have to do that manually,
> because there are some that aren't anybody's fault, and I don't need
> to spam you about those).
> 
> -Doug
> 
> 
> -- Forwarded message --
> From: (Cron Daemon) <gmir...@gentoo.org>
> Date: Thu, Jan 26, 2017 at 5:39 PM
> Subject: Cron <gmirror@dipper> /usr/local/bin/pidlock -s rsync-gen
> /bin/bash /usr/local/bin/mastermirror/rsync-gen.sh
> To: infra-gmir...@gentoo.org
> 
> 
> [ERROR/ForkPoolWorker-7] sys-cluster/torque is missing DIST entries!
> Traceback (most recent call last):
>   File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
> 23, in _open_file
> encoding=_encodings['fs'], errors='strict'), 'rb')
> FileNotFoundError: [Errno 2] No such file or directory:
> b'/var/empty/torque-6.1.0.tar.gz'
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "/usr/local/bin/mastermirror/thicken-manifests.py", line 122,
> in maybe_thicken_manifest
> manifest.create(assumeDistHashesAlways=True)
>   File "/usr/lib64/python3.4/site-packages/portage/manifest.py", line
> 506, in create
> self.fhashdict["DIST"][f] = perform_multiple_checksums(fname, self.hashes)
>   File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
> 426, in perform_multiple_checksums
> rVal[x] = perform_checksum(filename, x, calc_prelink)[0]
>   File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
> 390, in perform_checksum
> myhash, mysize = hashfunc_map[hashname](myfilename)
>   File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
> 52, in __call__
> with _open_file(filename) as f:
>   File "/usr/lib64/python3.4/site-packages/portage/checksum.py", line
> 31, in _open_file
> raise portage.exception.FileNotFound(filename)
> portage.exception.FileNotFound: b'/var/empty/torque-6.1.0.tar.gz'
> 
> !!! A file listed in the Manifest could not be found:
> /var/tmp/gmirror-rsync/gentoo-x86-stage/sys-cluster/torque/torque-6.0.1.ebuild
> /usr/local/bin/mastermirror/rsync-gen.sh: A Manifest has a failure!
> /var/tmp/gmirror-rsync/logs/regen/regen-run-20170126-2238.log.validate:
> 
> RepoMan scours the neighborhood...
>   digest.missing [fatal]1
>
> /var/tmp/gmirror-rsync/gentoo-x86-stage/sys-cluster/torque::torque-6.1.0.tar.gz
>   digest.unused 1
>   file.size 69
>   manifest.bad [fatal]  1
>sys-cluster/torque/Manifest
> Please fix these important QA issues first.
> RepoMan sez: "Make your QA payment on time and you'll never see the
> likes of me."
> 

While increasing QA is a laudable goal, I'm not sure spamming the list
every time you detect a QA issue is the right way to proceed with
improving QA.  I'm much rather you adopt a strategy similar to mgorny's
QA tool, and email the dev responsible for the commit that they broke
the repo.   Find a package with an issue, extract the last commit on
that directory, get the committer, and send them the email.  In all
likelihood, these kinds of errors aren't intentional, and public shaming
isn't really necessary in this case.  Simply notifying the developer so
that they can rectify the issue should be sufficient, unless I'm missing
something.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News item review: python-exec 2.3 reclaims python* symlinks

[NP-Hardass]

On 01/21/2017 04:49 AM, Michał Górny wrote:
> Please review the following news item. It was requested by users.
> Preferably I'd like to commit it today.
> 
>  --
> 
> Title: python-exec 2.3 reclaims python* symlinks
> Author: Michał Górny <mgo...@gentoo.org>
> Content-Type: text/plain
> Posted: 2017-01-21
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed:  Display-If-Installed:  
> The new versions of python-exec (2.3 and newer) are reclaiming multiple
> Python-related symlinks in /usr/bin, most notably /usr/bin/python*. This
> may result in your package manager reporting file collisions.
> 
> The respective symlinks were previously either unowned and created
> dynamically by app-eselect/eselect-python, or installed by it. From now
> on, all Python-related symlinks are installed and handled
> by python-exec. This ensures that they respect the python-exec
> configuration files and variables consistently with regular Python
> packages, and improves their reliability.
> 
> If you are using FEATURES=collision-protect, Portage will reject
> the upgrade. If this is the case, please temporarily switch to
> FEATURES=protect-owned for the upgrade.
> 
> If you are using FEATURES=protect-owned, Portage will verbosely warn
> about the file collisions but will proceed with the upgrade once
> determining no replaced files are owned. Please disregard the warning.
> 
> The potentially colliding files are:
> 
>  * /usr/bin/2to3
>  * /usr/bin/pydoc
>  * /usr/bin/python
>  * /usr/bin/python2
>  * /usr/bin/python3
>  * /usr/bin/python-config
> 
> For more information on python-exec, please see:
> https://wiki.gentoo.org/wiki/Project:Python/python-exec
> 
> 


Personally, I'd like to see an explicit, one liner on how to remediate
in the case of collision-protect since I think it is default for several
profiles.  Additionally, it'd be unwise to disable collision-protect for
more than just the affected packages.  Something like

If you are using FEATURES=collision-protect, Portage will reject the
upgrade.  If this is the case, please temporarily switch to
FEATURES=protect-owned for the upgrade, like with:
FEATURES=protect-owned emerge -1 '=python-exec-2.3'

Or similar.  this way, the user is only going to be disabling
collision-protect for this one package, lest it cause issues like if the
user edits their make.conf and them emerges @world

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last-rites: www-plugins/pipelight

[NP-Hardass]

# NP-Hardass <np-hard...@gentoo.org> (19 Jan 2017)
# Upstream has discontinued Pipelight and Firefox is in the process
# of removing NPAPI support (which Pipelight relies upon), making
# this obsolete.
# Masked for removal in 30 days.
www-plugins/pipelight


-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Lastrites: dev-ada/cbind, net-dialup/dtrace, net-nds/lat, app-pda/jpilot-mail, net-dialup/drdsl, dev-util/insight, app-laptop/configure-trackpoint, x11-misc/lxmed, dev-util/ketchup, m

[NP-Hardass]

On 10/29/2016 02:30 PM, Kristian Fiskerstrand wrote:
> On 10/29/2016 07:59 PM, NP-Hardass wrote:
>> On 10/08/2016 07:57 AM, Pacho Ramos wrote:
>>> # Fails to build (#515294), nothing needs it, relies on obsolete
>>> capi4kutils. 
>>>
>>
>> For all the packages being removed due to capi4kutils, how many were
>> investigated with net-libs/libcapi?  For WINE, we transitioned to using
>> libcapi instead of capi4kutils, and I don't see why some of those
>> couldn't as well, provided the capi4kutils is the only reason why those
>> are being treecleaned.
>>
> 
> Someone needs to take over responsibility for the packages
> (maintainership) and fixing the issues then. If not, they should be removed.
> 

I'm only talking about the packages that have no other issues and are
only being treecleaned because of this dependency.  Honestly, I don't
care about any of those packages.  I only brought this up because
sometimes it is better to only treeclean when appropriate, and if
switching from one dep to another (which should have been virtual'd)
resolves it, it might not still meet the conditions for tree cleaning.
We don't normally tree clean packages simply because they are old or
don't have a maintainer.

So, I will reiterate my one and only point, for those that are only
being removed due to the removal of capi4kutils, how many are still
worthy of being treecleaned after swapping out that dep?

If you feel that is too high a maintenance burden, fine, remove them
all.  I'm merely proposing it be looked at since otherwise we are
potentially removing packages that don't have to or shouldn't be removed.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Lastrites: dev-ada/cbind, net-dialup/dtrace, net-nds/lat, app-pda/jpilot-mail, net-dialup/drdsl, dev-util/insight, app-laptop/configure-trackpoint, x11-misc/lxmed, dev-util/ketchup, m

[NP-Hardass]

On 10/08/2016 07:57 AM, Pacho Ramos wrote:
> # Fails to build (#515294), nothing needs it, relies on obsolete
> capi4kutils. 
> 

For all the packages being removed due to capi4kutils, how many were
investigated with net-libs/libcapi?  For WINE, we transitioned to using
libcapi instead of capi4kutils, and I don't see why some of those
couldn't as well, provided the capi4kutils is the only reason why those
are being treecleaned.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] GLEP RFC: Third-party contributions

[NP-Hardass]

On 10/27/2016 05:00 AM, Ulrich Mueller wrote:
>>>>>> On Thu, 27 Oct 2016, Michał Górny wrote:
> 
>>> So, it is o.k. if you mention github in the Motivation section (but
>>> not five times!). However, github or pull requests should be mentioned
>>> neither in the Specification or the Rationale.
> 
>> Why not in the rationale? It is the most straightforward way of
>> explaining why it's made optional like this.
> 
> I just don't see the need there. The sentence:
> 
> "Due to the non-obligatory nature of GitHub, they may be requested by
> the maintainers to use other contribution channels."
> 
> could be replaced by:
> 
> "Contributors using an unofficial channel may be requested by the
> maintainers to use other contribution channels."
> 
> [BTW, is there a decent way to send diffs for a Mediawiki document?]
> 
> Ulrich
> 

IIRC, you could use USE="mediawiki" on dev-vcs/git and then use git to
interface with mediawiki

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] x11-misc/bumblebee and x11-misc/virtualgl up for grabs

[NP-Hardass]

On 10/18/2016 03:32 PM, Pacho Ramos wrote:
> I don't have much interest on this packages anymore and, also, my local
> setup has not the ability to check their functionality, hence, feel
> free to grab them
> 
> Thanks
> 

I'll take this if no one else wants it.  Happy to take a co-maintainer
if someone else wants that.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Package up for grabs: games-strategy/freeorion

[NP-Hardass]

On 10/16/2016 03:15 PM, Thomas Kahle wrote:
> Hi,
> 
> games-strategy/freeorion is a space empire and galactic conquest
> game inspired by Master of Orion (though not a clone):
> http://www.freeorion.org
> 
> I cannot maintain it anymore, the main reason being that I don't
> have a gentoo machine with a screen attached to it at the moment.
> 
> FreeOrion has a dedicated community (also in Gentoo) that does
> research on bugs and is generally helpful.  Upstream is also
> helpful and produces patches quickly.  They use github.
> 
> Open tasks are:
> 
> - remove games.eclass and EAPI=6 bump: I've done some work in
>   this direction, but I'm not finished.
> 
> - bump to 0.4.6: https://bugs.gentoo.org/show_bug.cgi?id=596680
> 
> The bump is the only open bug.  Please just take it or e-mail me
> (or both) if you are interested.
> 
> Cheers,
> Thomas
> 
> 

I'll take this if no one else wants it.  Happy to take a co-maintainer
if someone else wants that.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Package file name requirement for binary ebuilds

[NP-Hardass]

On 10/17/2016 11:09 AM, Michał Górny wrote:
> On Mon, 17 Oct 2016 14:20:19 +0200
> Ulrich Mueller <u...@gentoo.org> wrote:
> 
>>>>>>> On Mon, 17 Oct 2016, M J Everitt wrote:  
>>
>>> On 17/10/16 08:41, William L. Thomson Jr. wrote:  
>>>> To be clear I would suggest at MOST 3, -bin, -ebin, and -sbin.
>>>> NO more.  
>>
>>> I don't see what problem you are trying to solve. Gentoo is a
>>> source-based distro .. any binaries are a last-resort or most
>>> certainly should be. Having a policy may be useful, but I see no
>>> proposition on this thread yet?  
>>
>> How about the following? I believe it is more or less the current
>> practice:
>>
>> "Gentoo usually builds its packages from source. Exceptionally,
>> a binary package can be provided instead (e.g., if upstream doesn't
>> provide a source) or in addition. Such packages should still follow
>> normal naming conventions and don't need any special suffix.
> 
> I think this contradicts the next paragraph. The 'or in addition' is
> followed by a statement that it doesn't need any special suffix.
> 
>> If a binary package is provided in addition to its source-based
>> equivalent, the name of the former should be suffixed with '-bin'
>> for distinction."
> 
> I think this could collide with Chrome vs Chromium. One could call
> Chromium a 'source-based equivalent' of Chrome, and therefore require
> the '-bin' suffix even though the names do not collide.
> 
> That said, I think I've seen a package somewhere using USE flags to
> switch between source and binary version. Such a policy would require
> it to change (and I approve that).
> 
I think Chrome/Chromium is a special case as upstream calls their binary
and source based releases by different names.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: /etc/init.d/modules loading modules defined in files

[NP-Hardass]

On 08/16/2016 07:20 PM, William Hubbs wrote:
> All,
> 
> I have received a request to implement a feature in OpenRC to allow
> multiple software packages to drop files in a directory, /etc/modules.d
> for example, which would define modules the /etc/init.d/modules script
> would load.
> 
> The design I'm thinking of would not change the use of
> /etc/conf.d/modules, but the entries from the files would be added to
> the appropriate module lists after the ones listed there.
> 
> I'll write more about the design as I get closer to formulating the
> details, but at this point I just want to know what others thinkabout
> this feature.
> 
> Thanks,
> 
> William
> 

Just a side note on how I currently take advantage of the modules
initscript:

I have several symlinks, one for each set of modules that I want to
control.  Then I create a corresponding conf.d based off of the modules
conf.d.  So, for example, /etc/init.d/vbox-modules->/etc/init.d/modules
just controls the vbox modules.  This gives me fine control over module
sets without having to worry about all of them at once.  I can have
certain sets of modules start in different runlevels, and I can
independently load and unload sets of modules when necessary.

If you do end up switching to some system that reads a directory, I'd
like to see something that if the name of the initscript isn't modules,
it sources just the corresponding file, rather than the whole dir.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Asking for permission to update packages from LINGUAS to L10N

[NP-Hardass]

On 06/23/2016 05:04 PM, Ulrich Mueller wrote:
> I have created tracker bug https://bugs.gentoo.org/586734 for the
> LINGUAS to L10N conversion, and started to file bugs for individual
> packages. (Starting with lightweight stuff like metapackages, so users
> won't spend too much time with rebuilding if they don't get their L10N
> configuration immediately right.)
> 
> However, it looks like filing bugs for all affected packages is going
> to be tedious. Therefore I am asking for permission to update ebuilds
> for the easy cases directly, e.g. when the change is only a simple
> renaming from linguas_* to l10n_*.
> 
> Please speak up if you don't want your packages to be touched and
> prefer bugs to be filed for them.
> 
> Ulrich
> 

I was going through my packages to make sure that I was compliant with
this change, and found that I was not.  The l10n eclass makes use of the
LINGUAS USE_EXPAND and isn't covered in the tracker bug.  I attempted to
read through the old thread to see if someone mentioned that eclass, but
I must have missed it if someone mentioned it.  Are we EOL'ing that
eclass, or keeping it (update or revbump)?

Looks to me like we can't edit that eclass in place, so if we are to
keep it, we should probably revbump it, update the -r1 to L10N, and add
a deprecation warning to the old eclass to help maintainers migrate over.

Any opinions?  I'd be happy work on the revbump for the eclass if we
decide to go that route.  CC'ing yngwin since it is his eclass.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Empty project: Desktop

[NP-Hardass]

On 08/07/2016 10:37 AM, Pacho Ramos wrote:
> El dom, 07-08-2016 a las 09:07 -0400, NP-Hardass escribió:
>>  [...]
>> Well, that's easily remedied with an alias for the project that
>> contains
>> all the subprojects, no?
>>
> 
> But I don't know if the projects will like to behave in that way...
> because freedesktop-bugs was behaving exactly in that way and, during
> the transition, it was agreed to stop using that and simply CC the
> right projects when needed :/
> 
> From my point of view we should simply kill that "Desktop" project as
> it serves no purpose and CC the relevant projects when needed, as I
> don't recall many cases of the old freedesktop-bugs behaving in the way
> you are suggesting (involving *all* desktop related projects in the bug
> reports). On the other hand it was ending up with most people under the
> subprojects simply ignoring the bug reports assigned to freedesktop-
> bugs
> 

Well, if no other DEs want it, I say go for it.  Your description of the
old way was before my time working on MATE, I think.  Where does that
place the DEs going forward? Subprojects of The root node, or something
else?

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Empty project: Desktop

[NP-Hardass]

On 08/07/2016 06:34 AM, Pacho Ramos wrote:
> El sáb, 06-08-2016 a las 10:29 -0400, NP-Hardass escribió:
>> On 08/06/2016 04:31 AM, Pacho Ramos wrote:
>>>
>>> Now https://wiki.gentoo.org/wiki/Project:Desktop
>>>
>>> Well, it seems that it's only "containing" other subprojects... but
>>> I
>>> am unsure if we really need it. Anyway, he is now empty
>>>
>>>
>>>
>>
>> I think it makes sense to keep desktop environments in a logical
>> grouping.  There isn't a need for an overarching control structure
>> right
>> now, but if there needs to be coordination of efforts, I think
>> keeping
>> it in its current structure allows that to happen more easily than if
>> we
>> didn't have all the DEs in a project together.
>>
> 
> Well, in the past (when herds existed) that was handled by freedesktop-
> bugs project... but now it's different:
> https://wiki.gentoo.org/wiki/Project:Freedesktop
> 
> Anyway, the current desktop project won't either fulfill your
> suggestion as, instead of being a general alias for all the projects
> under it (like freedesktop-bugs herd was), it will simply end up with
> nobody listening as nobody is a member of it :/
> 

Well, that's easily remedied with an alias for the project that contains
all the subprojects, no?

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: app-admin/mate-system-tools, mate-extra/mate-calc, mate-extra/mate-dialogs

[NP-Hardass]

# NP-Hardass <np-hard...@gentoo.org> (6 Aug 2016)
# Masked for removal in 14 days.
# Upstream migrated from mate-calc to gnome's
# calculator (gnome-extra/gnome-calculator)
mate-extra/mate-calc

# NP-Hardass <np-hard...@gentoo.org> (6 Aug 2016)
# Masked for removal in 14 days.
# Upstream migrated from mate-dialogs to gnome's
# zenity (gnome-extra/zenity)
mate-extra/mate-dialogs

# NP-Hardass <np-hard...@gentoo.org> (6 Aug 2016)
# Masked for removal in 14 days.
# Upstream dropped support for this package, in part due
# to gnome dropping support for gnome-system-tools.
app-admin/mate-system-tools


-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Empty project: Desktop

[NP-Hardass]

On 08/06/2016 04:31 AM, Pacho Ramos wrote:
> Now https://wiki.gentoo.org/wiki/Project:Desktop
> 
> Well, it seems that it's only "containing" other subprojects... but I
> am unsure if we really need it. Anyway, he is now empty
> 
> 
> 

I think it makes sense to keep desktop environments in a logical
grouping.  There isn't a need for an overarching control structure right
now, but if there needs to be coordination of efforts, I think keeping
it in its current structure allows that to happen more easily than if we
didn't have all the DEs in a project together.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Patch for nvidia-drivers 367.35-r1 for kernels > 4.7.0

[NP-Hardass]

On 08/05/2016 02:34 PM, R0b0t1 wrote:
> On Aug 5, 2016 1:23 PM, "Natanael Olaiz" <nol...@gmail.com
> <mailto:nol...@gmail.com>> wrote:
>>
>> I applied the attached patch unconditionally locally, and it seems to
> work.
>> Which is correct way to apply the patch or not depending on the kernel
> version?
>>
> 
> See ebuild, there is a patch phase. Shove it in proper directory. Will
> need local overlay.
> 

if you are editing the ebuild in a local repo, put your patch in the
files/ directory.  If you want to conditionally patch for kernel 4.7,
you can test this with "kernel_is" from the linux-info eclass. In that
conditional block, epatch "${FILESDIR}/nameofyourfile.patch".

Alternatively, use https://wiki.gentoo.org/wiki//etc/portage/patches to
guide you on adding the patch to the proper place to have the ebuild
automatically patch (without need for an local repo) for you
(unconditionally wrt kernel version)

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[NP-Hardass]

This is the first draft of a news item describing a packaging change for
OpenAFS so that we no longer require the DEBUG_RODATA be turned off.
Given the security implications of the previous setting of having
CONFIG_DEBUG_RODATA=n, we thought it prudent to ensure that OpenAFS
users get notice of the change in a manner that they are not likely to
miss (unlike a message in a phase that can be missed/hidden/squelched).


Title: OpenAFS no longer needs kernel option DEBUG_RODATA
Author: NP-Hardass <np-hard...@gentoo.org>
Author: Andrew Savchenko <birc...@gentoo.org>
Content-Type: text/plain
Posted: 2016-07-23
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2
Display-If-Keyword: amd64
Display-If-Keyword: ~amd64-linux
Display-If-Keyword: ~sparc
Display-If-Keyword: x86
Display-If-Keyword: ~x86-linux

As a result of bug #127084 [1], it was determined that OpenAFS's kernel
module required that the kernel's data structures be read-write
(CONFIG_DEBUG_RODATA=n).  Upon reviewing the latest version of OpenAFS
with Linux kernels 3.4-4.4, it has been determined that this condition
is no longer necessary to ensure that OpenAFS builds and loads into the
kernel.

Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no longer
forced in the ebuild. Considering the security implications of having
CONFIG_DEBUG_RODATA turned off, it is highly advised that you adjust your
kernel config accordingly.  Please note that the default setting for
CONFIG_DEBUG_RODATA is "y" and unless you have another reason for keeping
it disabled, we highly recommend that you re-enable CONFIG_DEBUG_RODATA.

[1] https://bugs.gentoo.org/show_bug.cgi?id=127084


-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] why is the security team running around p.masking packages

[NP-Hardass]

On 07/05/2016 10:43 PM, Aaron Bauman wrote:
> On Wednesday, July 6, 2016 9:00:12 AM JST, Anthony G. Basile wrote:
>> On 7/4/16 11:26 PM, Aaron Bauman wrote:
>>
>>> Finally, that does not dissolve the developer of providing usable,
>>> substantiated, and verifiable information regarding the
>>> vulnerabilities.  The idea that a developer gets to choose whether or
>>> not they do so should not be considered.  Anthony's verbiage on Freenode
>>> was very frank, in that if he chose to do so he would.  We ask for
>>> all ...
>>
>> 1) In bug #473770 upstream gave sufficient information.  I stated so in
>> comments #1 and #2 with links.  You ignored this fact and proceeded to
>> p.mask in comment #3.  This CVE should never have been filed.  Its junk.
>>
>> 2) Bug #459274 is not a security bug.  A CVE request was filed by Ago
>> which, as far as I can tell, went no where.  The log file in question
>> does not disclose much more than one could obtain with just ps and
>> netstat.  I fixed a related issue with access.log in bug #459274.
> 
> That CVE request was not from Ago.  It was from the respective OSS ML
> referenced in the URL field of the bug report.  Not to mention, you as a
> maintainer were able to discover another issue with that package and fix
> it.
> 
>>
>> 3) My point on IRC is that you are acting on junk CVEs and I question
>> your judgment.  You can't produce "substantiated and verifiable
>> information" on junk.  Your above paragraph eclipses that side of my
>> argument and strawmans me.
>>
> 
> Why is this so difficult?  All of the follow up information you gave,
> after the p.mask and inquiry from Alex, is exactly what we need from the
> maintainers.  If the CVE is junk, which often happens, then the
> verifiable and substantiating information is perfectly acceptable from
> the maintainer. No one here is challenging your ability to provide such
> information, but given the multitude of security related bugs we need
> cooperation from the maintainers.  We are not familiar with every
> package in the tree, but we do our best to ensure any potential
> vulnerability is mitigated.  Again, you are the only developer who has
> had an issue with this.  As previously mentioned, a p.mask is not the
> end of the road, it is just an obligation to ensure the user is warned
> of longstanding security issues.  If they choose to unmask it then so be
> it.
> 
>> I personally would like to see only QA oversee any forced p.maskings and
>> have the security team pass that task over to QA for review.  By forced
>> I mean without the cooperation of the maintainer.
>>
> 
> Again, no one else has had an issue with this except you.  The one who
> doesn't want to cooperate.  I apologized for not pinging an active
> developer, but you cannot reciprocate the professionalism here and work
> with us.  Why can't you just work the issue like you did following the
> p.mask and we can move on?  Inevitably proving the point of why the
> p.mask is an option.  Look at the myriad of security bugs and you will
> see such examples of developers working together in order to validate,
> mitigate, and close these bugs.  Sometimes this process highlights the
> reality that CVE's are not perfect in their descriptions or assessments.  
> -Aaron
> 

I think it is a little bit of a stretch to say that he's the only one to
have an issue.  Now, I've spoken with the parties involved, so my issue
is resolved, but I had a package of mine bumped in the name of security
without being pinged/consulted at all.  I'm not attempting to point
blame at anyone, but merely show that there are others who have been
affected by security workflow sometimes going around the maintainer.  I
don't think there should be any harm in acknowledging that, and striving
to make sure it doesn't happen in the future, where possible.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] why is the security team running around p.masking packages

[NP-Hardass]

probably like sunrise and
> such, headed towards deprecation and the chopping block.
> 
> 
> Thanks,
> James
> 
> 

Here's a solution that handles that doesn't require fancy git knowledge
and uses Gentoo infrastructure:

1) Navigate to https://gitweb.gentoo.org/repo/gentoo.git (or any other
gentoo repo)
2) Click "Tree"
3) Navigate to the level ABOVE the one you are interested in, for
example, if you want app-misc/foobar, navigate into app-misc.
4) To the right of your desired entry, click "Log"
5) This will display the history of the package, allowing you to browse
it at any time, (you in particular want the one before the ebuild was
removed) (Click your desired commit)
6) Click the name of the category/package on the "Tree" line to view the
tree at that point in time. ie,
tree02d93ae662fb1a813380775612e35e819d67e303
/app-accessibility/SphinxTrain (you would click
"app-accessibility/SphinxTrain"
7) View and download your desired files by clicking on "Plain" on the right

Protips:
*You can view the log of any package (removed or not) with:
https://gitweb.gentoo.org/repo/gentoo.git/log//

*You can view files as of last commit before removal of any package with:
https://gitweb.gentoo.org/repo/gentoo.git/tree//?id=

* If you don't know the last commit before removal, juts load up the
removal commit and copy the commit hash of the "Parent" link to get the
commit before that

Tada! Attic restored ^_~


-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

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

[NP-Hardass]

Here's a diff of the changes based on feedback from this ML, followed by
the full eclasses.

Once again, thanks for all the feedback.

-- 
NP-Hardass


diff --git a/eclass/mate-desktop.org.eclass b/eclass/mate-desktop.org.eclass
index 5f92c4f..c57528d 100644
--- a/eclass/mate-desktop.org.eclass
+++ b/eclass/mate-desktop.org.eclass
@@ -12,22 +12,16 @@
 # Provide a default SRC_URI and EGIT_REPO_URI for MATE packages as well as
 # exporting some useful values like the MATE_BRANCH

-# Old EAPIs are banned.
-case "${EAPI:-0}" in
-   5|6) ;;
-   *) die "EAPI=${EAPI} is not supported" ;;
-esac
+# EAPIs < 6 are banned.
+if [[ "${EAPI:-0}" != "6" ]]; then
+   die "EAPI=${EAPI:-0} is not supported"
+fi

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

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

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

 # Set SRC_URI or EGIT_REPO_URI based on whether live
 if [[ ${PV} ==  ]]; then
@@ -72,6 +62,3 @@ fi

 # Set HOMEPAGE for all ebuilds
 HOMEPAGE="http://mate-desktop.org;
-
-# Set default SLOT for all ebuilds
-SLOT="0"
diff --git a/eclass/mate.eclass b/eclass/mate.eclass
index a0209bf..074ed8d 100644
--- a/eclass/mate.eclass
+++ b/eclass/mate.eclass
@@ -15,10 +15,9 @@
 # fact that MATE is a GNOME fork. For additional functions, see
gnome2-utils.eclass.

 # Check EAPI only
-case "${EAPI:-0}" in
-   5|6) ;;
-   *) die "EAPI=${EAPI} is not supported" ;;
-esac
+if [[ "${EAPI:-0}" != "6" ]]; then
+   die "EAPI=${EAPI:-0} is not supported"
+fi

 # Inherit happens below after declaration of GNOME2_LA_PUNT

@@ -33,20 +32,19 @@ GNOME2_LA_PUNT=${MATE_LA_PUNT:-""}

 inherit gnome2 autotools mate-desktop.org

-case "${EAPI:-0}" in
-   5|6)
-   EXPORT_FUNCTIONS src_prepare src_configure src_install 
pkg_preinst
pkg_postinst pkg_postrm
-   ;;
-   *) die "EAPI=${EAPI} is not supported" ;;
-esac
+if [[ "${EAPI:-0}" == "6" ]]; then
+   EXPORT_FUNCTIONS src_prepare src_configure src_install pkg_preinst
pkg_postinst pkg_postrm
+fi

 # Autotools requires our MATE m4 files
 DEPEND=">=mate-base/mate-common-${MATE_BRANCH}"

-# @FUNCTION: python_cond_func_wrap
+# @FUNCTION: mate_py_cond_func_wrap
 # @DESCRIPTION: Wraps a function for conditional python use, to run for
each
 # python implementation in the build directory.
-python_cond_func_wrap() {
+# This function should only be used if the ebuild also inherits the
+# python-r1 eclass
+mate_py_cond_func_wrap() {
if use python; then
python_foreach_impl run_in_build_dir "$@"
else
@@ -60,7 +58,7 @@ python_cond_func_wrap() {
 # - true: will always run eautoreconf
 # - false: will default to automatic detect
 # - If it is not set, it will default to false
-FORCE_AUTORECONF=${FORCE_AUTORECONF:-""}
+: ${MATE_FORCE_AUTORECONF:="false"}

 # @FUNCTION: ematedocize
 # @DESCRIPTION: A wrapper around mate-doc-common
@@ -85,8 +83,8 @@ want_mate_doc() {
 mate_src_prepare() {
debug-print-function ${FUNCNAME} "$@"

-   local force_autoreconf=${FORCE_AUTORECONF:-false}
-   [[ ${PV} ==  ]] && force_autoreconf=true
+   local force_autoreconf=${MATE_FORCE_AUTORECONF}
+   [[ ${PV} ==  ]] && force_autoreconf="true"

gen_chksum() {
find '(' -name 'Makefile.am' \
@@ -99,8 +97,8 @@ mate_src_prepare() {

gnome2_src_prepare "$@"

-   if ${force_autoreconf} || [[ ${chksum} != $(gen_chksum) ]]; then
-   [[ want_mate_doc ]] && ematedocize
+   if [[ "${force_autoreconf}" == "true" ]] || [[ ${chksum} !=
$(gen_chksum) ]]; then
+   want_mate_doc && ematedocize
eautoreconf
fi
 }



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


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

# @ECLASS: mate-desktop.org.eclass
# @MAINTAINER:
# m...@gentoo.org
# @AUTHOR:
# Authors: NP-Hardass <np-hard...@gentoo.org> based upon the gnome.org
eclass.
# @BLURB: Helper eclass for mate-desktop.org hosted archives

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

[NP-Hardass]

On 06/10/2016 09:33 AM, Michał Górny wrote:
> On Thu, 9 Jun 2016 08:19:43 -0400
> NP-Hardass <np-hard...@gentoo.org> wrote:
> 
>> # Ensure availibility of xz-utils on old EAPIs
>> if [[ "${EAPI:-0}" -lt "6" ]]; then
>>  DEPEND="app-arch/xz-utils"
>> fi
> 
> One more thing. What is the rationale for this? I've tried hard, and I
> can't find anything EAPI-conditional about dependency on xz-utils.
> 

There was a light discussion last time I posted this which resulted in
the suggestion that it be included with EAPI 5.  There were a lot of
mixed opinions, and a lot of doubts one way or the other.  Should be
moot now though, as I think I'm going to follow through on perfinion's
suggestion starting with EAPI 6 only.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

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

[NP-Hardass]

On 06/09/2016 11:54 PM, Jason Zaman wrote:
> On Thu, Jun 09, 2016 at 08:19:43AM -0400, NP-Hardass wrote:
>> # Old EAPIs are banned.
>> case "${EAPI:-0}" in
>>  5|6) ;;
>>  *) die "EAPI=${EAPI} is not supported" ;;
>> esac
> 
> How reasonable would it be to ban EAPI5 as well? This is a new eclass so
> it may be better to just take the time to go to EAPI6 directly and not
> have to migrate 5->6 later on.
> 
> 
Would be quite reasonable.  I thought since all the existing MATE
ebuilds are EAPI 5 or 6, it'd be wise to support both, but I've only
actually used (and probably will only use) the eclass with EAPI6 ebuilds.
>> # @FUNCTION: python_cond_func_wrap
>> # @DESCRIPTION: Wraps a function for conditional python use, to run for each
>> # python implementation in the build directory.
>> python_cond_func_wrap() {
>>  if use python; then
>>  python_foreach_impl run_in_build_dir "$@"
>>  else
>>  $@
>>  fi
>> }
> 
> I dont see where you inherited the python eclasses? You also probably
> need to use use_if_iuse (from eutils.eclass) instead since it seems like
> python might not be in all the ebuilds. Afaik, you're not allowed to
> call use foo if foo is not in IUSE already
I forgot to include a comment in the ebuild, but the intention was that
the eclass would not inherit python, by design, those wanting to use
that should inherit python themselves.  Although, if I should check that
explicitly, I am unaware of how to do so, and would appreciate advice
from someone, if it is possible. I am aware of INHERITED, but the PMS
says it shouldn't be exported to ebuilds, so I'm unsure if/how it could
be used.

My hope was that since this is used several times (though, not too
many), that I could move this logic into the eclass, but if it would be
more appropriate to just keep that in each of those ebuilds, I can do
that too.
> 
> Also I'm not sure if having functions start with python_ could lead to
> conflicts later on with the python eclasses?
Yeah, I should probably adjust the namespace
> 
> Other than these minor things, look good!
> -- Jason
> 
> 
Thanks for taking the time to look it over and review.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

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

[NP-Hardass]

On 06/10/2016 06:43 AM, Michał Górny wrote:
> Dnia 9 czerwca 2016 14:19:43 CEST, NP-Hardass <np-hard...@gentoo.org> 
> napisał(a):
>> Greetings all,
>>
>> Sorry for the delay, had lots of recurrent hardware issues the last
>> month or so.
>> I will be adding this to the MATE project repo after I get your
>> feedback, and then into Gentoo repo after I've had some users test out
>> the new packages/eclass.
>>
>> Just a reminder/summary:
>> There are 40-50 ebuilds in the MATE desktop environment, with a fair
>> bit
>> of overlap in the ebuild code, so I thought it best to create an eclass
>> to handle that.  MATE is a fork of GNOME 2 so I used the gnome.org
>> eclass as a reference for the mate-desktop.org eclass.  Additionally,
>> there is much in MATE that is still very much in line with the gnome2
>> eclass.  Rather than having to edit 40-50 ebuilds if we become
>> divergent, I thought it more purdent to just create a separete mate_*
>> namespace. For functions that are currently equivalent, my phase
>> functions are stubs to the gnome2 phase functions.
>>
>>
>> Thanks for taking the time to look these over and give your feedback.
>> (Also, apologies for the thrown together email, I was having trouble
>> getting git-send working to the mailing list)
>>
>> --
>> NP-Hardass
>>
>> ###
>> mate-desktop.org.eclass
>> ###
>>
>>
>> # Copyright 1999-2016 Gentoo Foundation
>> # Distributed under the terms of the GNU General Public License v2
>> # $Id$
>>
>> # @ECLASS: mate-desktop.org.eclass
>> # @MAINTAINER:
>> # m...@gentoo.org
>> # @AUTHOR:
>> # Authors: NP-Hardass <np-hard...@gentoo.org> based upon the gnome.org
>> eclass.
>> # @BLURB: Helper eclass for mate-desktop.org hosted archives
>> # @DESCRIPTION:
>> # Provide a default SRC_URI and EGIT_REPO_URI for MATE packages as well
>> as
>> # exporting some useful values like the MATE_BRANCH
>>
>> # Old EAPIs are banned.
>> case "${EAPI:-0}" in
>>  5|6) ;;
>>  *) die "EAPI=${EAPI} is not supported" ;;
>> esac
>>
>> if [[ ${PV} ==  ]]; then
>>  inherit git-r3
>> else
>>  inherit versionator
>> fi
>>
>> # Ensure availibility of xz-utils on old EAPIs
>> if [[ "${EAPI:-0}" -lt "6" ]]; then
> 
> EAPI is not a number and must not be treated like a number.
> 
>>  DEPEND="app-arch/xz-utils"
>> fi
>>
>> # @ECLASS-VARIABLE: MATE_TARBALL_SUFFIX
>> # @INTERNAL
>> # @DESCRIPTION:
>> # All projects hosted on mate-desktop.org provide tarballs as tar.xz.
>> # Undefined in live ebuilds.
>> [[ ${PV} !=  ]] && : ${MATE_TARBALL_SUFFIX:="xz"}
> 
> You should ask upstream to supply .tar.lz instead, so they don't harm their 
> users.
> 
I can ask, but I don't think I understand what you mean by "harm their
users."
>>
>> # @ECLASS-VARIABLE: MATE_DESKTOP_ORG_PN
>> # @DESCRIPTION:
>> # Name of the package as hosted on mate-desktop.org.
>> # Leave unset if package name matches PN.
>> : ${MATE_DESKTOP_ORG_PN:=$PN}
>>
>> # @ECLASS-VARIABLE: MATE_DESKTOP_ORG_PV
>> # @DESCRIPTION:
>> # Package version string as listed on mate-desktop.org.
>> # Leave unset if package version string matches PV.
>> : ${MATE_DESKTOP_ORG_PV:=$PV}
>>
>> # @ECLASS-VARIABLE: MATE_BRANCH
>> # @DESCRIPTION:
>> # Major and minor numbers of the version number, unless live.
>> # If live ebuild, will be set to ''.
>> if [[ ${PV} ==  ]]; then
>>  : ${MATE_BRANCH:=}
>> else
>>  : ${MATE_BRANCH:=$(get_version_component_range 1-2)}
>> fi
> 
> Unless I'm missing something, the 1-2 range will return  in live version 
> as well. Unless you are trying to avoid the inherit in the live ebuild -- 
> then I don't think it's worth the extra code.
> 
I will double check and reply again if it is different, but I believe
the concern had been that if there was a major change in a , and I
temporarily revbumped the  to -r1, the 1-2 range would return
-r1 rather then the expected .
>>
>> # Set SRC_URI or EGIT_REPO_URI based on whether live
>> if [[ ${PV} ==  ]]; then
>>  EGIT_REPO_URI="
>>  https://github.

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

[NP-Hardass]

Greetings all,

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

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


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

--
NP-Hardass

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


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

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

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

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

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

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

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

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

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

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

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

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

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


###
mate.eclass
###


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

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

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

# Inherit happens below after declaration of GNOME2_LA_PUNT

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

inh

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

[NP-Hardass]

On 06/09/2016 01:03 AM, Daniel Campbell wrote:
[...]
> Proxy-maint team: do you guys feel that your project and/or process are
> a suitable starting point to becoming a proper Gentoo developer?
As with everything, it depends on the individual.  One can certainly cut
their teeth and learn/contribute a lot through proxy maint, but at the
same time, they could just do the bare minimum to keep their package
updated.  The idea behind the project is to facility user contributions.
 Part of that includes ensuring proper QA and writing good, well formed
ebuilds.  This certainly provides the opportunity to get an individual
moving toward developership, but obviously, once again, depends on the
individual.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Default DOCS for einstalldocs and HACKING file

[NP-Hardass]

On 06/08/2016 02:40 AM, Michał Górny wrote:
> On Tue, 7 Jun 2016 18:50:05 -0400
> NP-Hardass <np-hard...@gentoo.org> wrote:
> 
>> From what I've seen, HACKING is a fairly common doc in FOSS projects.
>> It doesn't seem to have been included in the default DOCS for
>> einstalldocs in EAPI6.  While going through the MATE packages, I noticed
>> that we have quite a few packages that include HACKING in DOCS, so I
>> cannot delete the DOCS array and take advantage of the automagic doc
>> detection feature of einstalldocs.
>>
>> Does anyone know why we omitted this file from the default DOCS?  A
>> quick grep of the main repo shows ~370 ebuilds with HACKING listed.   Is
>> this file no longer considered worthy of being included by default in
>> our installed docs?  If so, looking for advice on whether it is worth
>> keeping or dropping that file from my packages?
> 
> File a Future EAPI bug asking to include it in EAPI 7. I don't see
> a reason to omit it by default.
> 

Done. Thanks for the suggestion.

https://bugs.gentoo.org/show_bug.cgi?id=585428 in case anyone is interested.
-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Default DOCS for einstalldocs and HACKING file

[NP-Hardass]

From what I've seen, HACKING is a fairly common doc in FOSS projects.
It doesn't seem to have been included in the default DOCS for
einstalldocs in EAPI6.  While going through the MATE packages, I noticed
that we have quite a few packages that include HACKING in DOCS, so I
cannot delete the DOCS array and take advantage of the automagic doc
detection feature of einstalldocs.

Does anyone know why we omitted this file from the default DOCS?  A
quick grep of the main repo shows ~370 ebuilds with HACKING listed.   Is
this file no longer considered worthy of being included by default in
our installed docs?  If so, looking for advice on whether it is worth
keeping or dropping that file from my packages?

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[NP-Hardass]

On 05/30/2016 04:46 PM, Joakim Tjernlund wrote:
> 
> NP, there are 2 patches floating on the MATE ml that move the dependency on 
> sys-power/upower-pm-utils
> consolekit(suspend/resume is handled by consolekit instead). Wold you be 
> interested to
> add those to gentoo MATE?
> 
>   Jocke
> 

I'm not terribly fond of the idea of grabbing random patches that bypass
upstream.  Would make more sense IMO to convince upstream to make that
toggleable either at runtime by a dconf setting or at compile time via a
configure flag.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

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

[NP-Hardass]

On 06/02/2016 05:21 PM, Rich Freeman wrote:

On Thu, Jun 2, 2016 at 4:46 PM, Michał Górny <mgo...@gentoo.org> wrote:


We understand that some people have goals like 'I want Qt everywhere,
I hate GTK+ so much I'd rather not be able to do anything than have
GTK+ on my system'. We respect them. But we're no longer going to
optimize Gentoo for those people.



++

I think this is the right direction to take.  Packages should try to
use the appropriate libraries by default (assuming they support more
than one), so the plasma user gets apps linked to qt5, and so on.  The
user shouldn't have to set USE flags to get basic behavior like this -
maybe they just pick a profile.

If a plasma user installs a package that only supports gtk, then it
pulls in gtk.

Users shouldn't need a laundry list of global or per-package USE
settings if they don't really care which libraries they need.  This
reasonable default behavior also shouldn't result in every single
package pulling in every possible optional dependency as well.  It
should just use the "right" one.

If somebody wants to set USE=-* and micromanage every package, well,
that will always work on Gentoo.  However, that should not be the use
case we optimize for.



So, at this juncture, is it worth considering a proper abstraction for 
"suggests" and "optional" and/or "preferred" (for USE and *DEPEND) 
rather than (or in addition to) USE="gui"?


--
NP-Hardass

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

[NP-Hardass]

On 06/01/2016 12:52 PM, Ian Stakenvicius wrote:
> On 01/06/16 11:19 AM, NP-Hardass wrote:
>> On 06/01/2016 10:29 AM, Mart Raudsepp wrote:
>>> Hello,
>>>
>>> So here's something more simple wrt GUI USE flags.
>>>
>>> Global USE=gui for
>>> gui - enable an optional graphics user interface or extra GUI tool
>>>
>>> Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
>>> of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
>>> available in only one toolkit version. So hence feature based flag, not
>>> dependency-based.
>>>
>> I know that it was previously mentioned that there was discussion about
>> this long ago, but I'm not familiar with those discussions. Is someone
>> more familiar with those discussions able to bring up the talking points?
>>
>> One issue that springs to mind though is, let's say a pkg supports only
>> qt4 for a gui, you'd have the gui flag. Upstream adds qt5 support.  Do
>> you keep the gui flag and make qt4 and qt5 dependent on it, or do you
>> remove the gui flag?  I feel like the latter might lead to confusion,
>> while the former suggests that the flag should be used more generally
>> than just one toolkit/version being available.
> 
> This would be the:
> 
>>> There are some other things in the ideas pipeline for when there are
>>> multiple toolkit choices, but that's something for a different thread,
>>> a different day and more controversial.
> 
> ...portion. :)
> 
> 
Ah :)

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

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

[NP-Hardass]

On 06/01/2016 12:21 PM, Michał Górny wrote:
> On Wed, 01 Jun 2016 17:29:55 +0300
> Mart Raudsepp <l...@gentoo.org> wrote:
> 
>> Hello,
>>
>> So here's something more simple wrt GUI USE flags.
>>
>> Global USE=gui for
>> gui - enable an optional graphics user interface or extra GUI tool
>>
>> (wording improvements welcome, once it's in principle agreed; but no
>> point in bikeshed painting description wording till it is)
> 
> How about:
> 
> gui - Enable an optional graphics user interface. If multiple variants
> of the GUI are available, additional flags may provide a more
> fine-grained choice of them.
> 
This resolves the question in my previous post.  So, if using the
premise that it'd apply for all gui selection, and specific gui
libs/flags are dependent on the gui flag via REQUIRED_USE or another
means, then that SGTM.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

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

[NP-Hardass]

On 06/01/2016 10:29 AM, Mart Raudsepp wrote:
> Hello,
> 
> So here's something more simple wrt GUI USE flags.
> 
> Global USE=gui for
> gui - enable an optional graphics user interface or extra GUI tool
> 
> Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
> of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
> available in only one toolkit version. So hence feature based flag, not
> dependency-based.
> 
I know that it was previously mentioned that there was discussion about
this long ago, but I'm not familiar with those discussions. Is someone
more familiar with those discussions able to bring up the talking points?

One issue that springs to mind though is, let's say a pkg supports only
qt4 for a gui, you'd have the gui flag. Upstream adds qt5 support.  Do
you keep the gui flag and make qt4 and qt5 dependent on it, or do you
remove the gui flag?  I feel like the latter might lead to confusion,
while the former suggests that the flag should be used more generally
than just one toolkit/version being available.
> 
> Mart
> 

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[NP-Hardass]

On 05/27/2016 06:05 PM, Daniel Campbell wrote:
> On 05/27/2016 02:45 PM, NP-Hardass wrote:
>> Not on hand, but as the MATE maintainer, I can tell you that starting
>> with MATE-1.14, two packages are gtk3 only, and starting with 1.16, four
>> more are.
>>

> 
> Aha, thanks for offering that info. Which ones if you don't mind?
> 
in 1.14 x11-misc/mozo and mate-extra/mate-system-monitor.  Don't have
the 1.16 ones handy as I haven't been able to work on it the last week
(more hw issues)

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[NP-Hardass]

On 05/27/2016 02:57 PM, Daniel Campbell wrote:
> As far as I'm concerned, if any package I maintain offers both gtk2 and
> gtk3 support, it would be irresponsible for me to *not* offer that
> choice. Gentoo is about flexibility and giving power to the user. Choice
> is a central part of that, and basically *the* reason I switched to
> Gentoo or bothered to become a developer.

+1

> You also mentioned that Mate and XFCE won't be supporting GTK2. Got any
> links there?

Not on hand, but as the MATE maintainer, I can tell you that starting
with MATE-1.14, two packages are gtk3 only, and starting with 1.16, four
more are.

> Just my two cents.
> 
> ~zlg
> 

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[NP-Hardass]

On 05/27/2016 11:40 AM, William Hubbs wrote:
> On Fri, May 27, 2016 at 05:21:06PM +0300, Mart Raudsepp wrote:
>> Hello,
>>
>> Despite it being 2016 and gtk2 pretty much dead, buried and forgotten
>> upstream, many applications still support only gtk2, have subtle issues
>> with their gtk3 port, or support both, with some of our userbase
>> clinging to gtk2 for dubious political or aesthetical reasons.
>>
>> For the latter cases, despite GNOME teams policy and strong preference
>> on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's
>> working as good as gtk2), some cases exist where the maintainers want
>> to provide such choice. In some cases it is understandable for a short
>> while during transition, e.g firefox. In other cases, it is purely for
>> the sake of providing the choice of working with a deprecated toolkit,
>> apparently.
>>
>> My highly biased essay aside, we need to finally globally agree on what
>> we do in this situation. If we allow this choice at all, only for
>> special cases, or widespread. And if this choice is provided, how do we
>> name the USE flag.
> 
> (qa hat in place)
> 
> There is a qa policy about this. All packages in the tree should
> move away from the non-versioned gtk use flag to versioned use flags,
> like the ones the qt team uses [1] [2].
> 
> This seems to be the best compromise. It allows the maintainers of the
> packages to decide which toolkit they want to support. If there is too
> much work involved in maintaining a package with dual support, don't do
> the work, just make it support the appropriate toolkit version.
> 
> I have not seen any reason why something like this couldn't work. After
> all, it seems to work for the qt team.
> 
> William
> 
> [1]
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#gtk.2Fgtk2.2Fgtk3_USE_flag_situation
> [2]
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#GTK_flag_situation
> 

Explicit gtk version flags is fine by me:
REQUIRED_USE=" || ( gtk2 gtk3 ) ^^ ( gtk2 gtk3 ) ?? ( gtk2 gtk3 )"

I think an unversioned gtk flag semantically makes and simplifies some
ebuild logic in cases where gtk support is completely optional.
DEPEND="
gtk? (
cat/foo
cat/gorp[gtk2=,gtk3=]
gtk2? (
cat/bar:2
cat/baz[gtk2]
x11-misc/gtk:2
)
gtk3? (
cat/bar:3
x11-misc/gtk:3
)
)
"

So, in summary, I'm content to move away from unversioned gtk flags in
all cases except when using it to describe "optional gtk support" which
is then backed up with versioned gtk flags.

Also, regardless of the decision, I'd be happy to help refactor the tree
to conform with the decision.
-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[NP-Hardass]

On 05/27/2016 10:21 AM, Mart Raudsepp wrote:
> Hello,
> 
> Despite it being 2016 and gtk2 pretty much dead, buried and forgotten
> upstream, many applications still support only gtk2, have subtle issues
> with their gtk3 port, or support both, with some of our userbase
> clinging to gtk2 for dubious political or aesthetical reasons.
> 
> For the latter cases, despite GNOME teams policy and strong preference
> on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's
> working as good as gtk2), some cases exist where the maintainers want
> to provide such choice. In some cases it is understandable for a short
> while during transition, e.g firefox. In other cases, it is purely for
> the sake of providing the choice of working with a deprecated toolkit,
> apparently.
> 
> My highly biased essay aside, we need to finally globally agree on what
> we do in this situation. If we allow this choice at all, only for
> special cases, or widespread. And if this choice is provided, how do we
> name the USE flag.
> 
I don't see the benefit of forcing people off of gtk2 to gtk3 when gtk2
is working just fine.  gtk2 is entrenched, and will take a while to
migrate apps from.  A parallel, why don't we just drop python2.7?  It's
old, superseded, and plenty of things support python3.x.  I disagree
with this logic.  In my opinion, we should remove support for them when
it seems that it has been dropped by a majority of packages or unfixed
security issues make it not worth keeping around.  I don't think we are
anywhere near that point.

[...]

> Thoughts? Agreements? Suggestions?
> I'm particularly interested in QA opinion here. I believe WilliamH
> wanted to spearhead this from their side.
> 
> 
> Regards,
> Mart Raudsepp
> Gentoo developer, GNOME team
> 

Flag specific comments to follow in WilliamH's reply.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature

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

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/13/2016 12:19 PM, Alexis Ballier wrote:
> On Wed, 13 Apr 2016 08:55:56 -0400 NP-Hardass
> <np-hard...@gentoo.org> wrote: [...]
>> The idea was partly due to consistency.  Rather than calling
>> mate_this gnome2_that, it'd provide one namespace.  Additionally
>> as mentioned in my initial email, since GNOME and MATE aren't
>> always in synch, if the gnome2 eclass chooses to change
>> something, and it's better that mate eclass stays with what we
>> have, all I have to do is fill in the stub, and all ebuilds
>> retain their current implementation.  Otherwise, I'd have to mass
>> edit all ebuilds to replace the offending gnome2_ with mate_.
> 
> yep, makes sense
> 
>> Furthermore, there was a discussion a long time ago about how 
>> functions shouldn't be called without an explicit inherit.  That
>> means that even if the mate eclass uses gnome2, if I opt to call
>> gnome2 directly in the ebuild, I have to explicitly inherit it
>> (which mostly defeats the purpose of inheriting it in the mate
>> eclass).
> 
> nah, this isnt true in your case: you can define mate.eclass' API
> to always include gnome2.eclass, making it ok to use gnome2
> functions by inheriting only mate.eclass. this means you can never
> drop gnome2.eclass from mate.eclass though, which may not be
> desired
> 
I'm unfamiliar with this.  Do you have a reference that I can look at?
> 
>> This has an added bonus, which is that the gnome2 eclass inherits
>> gnome.org, so I have to make sure to re-inherit mate-desktop.org
>> whenever gnome2 is (re)inherited to prevent all of variables like
>> SRC_URI from  being overwritten.  Hope that I'm conveying that
>> logic adequately.
> 
> ok, maybe you could add a comment that no ebuild should inherit
> both gnome2 & mate eclasses then
> 


- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXDnIUAAoJEBzZQR2yrxj7WLgP/0JoEMUrbc3DjYP2SVpUM5F1
slgblQuY+2ElDpoDIoSU+GY3aSv7kv1WnH8gPRPTOYsW1XSmjXwSVbAeh0s7g8fR
779Kl3aKxHQiaNmSv4wCoBTUO3AXQrC168C13h3PebVnPVUg1df/pILbfR9vAkhR
VLL/9A3WVBLb980gywJpiEPWZC7pBIAWdD6jHdhGW9u75k4Q/Ro6jUN+NQYjexr5
S0q0CTkxJw3nJA/K+VxnLltyUoJ7i7V3MoQM4hxebTDxev6ni3rahAK7XU00Itgi
r8nAOlBbporrl2pnX/xm6HEZm14oRPo8z9Cm7Te6t7eZODtzIZlnRJkqxVVHPRWN
dhO9m8u9FpkpTsTWE2eXX9Xqwx1WLXNWxjrkiGV7urEFLI66x05pMm+JLAoyEMB1
i1ep8DuXOcTaZPQbiPOoSEcdi79pJ9kClwyRyzVCPca/Pz0n23N/OqSNVa2FTCLT
BZ5YByFO9iG90qSqCmbbjygjo51yhQJn3WqS1Kmk8N9Pdj314VQI8anWesL8Q6Ua
j9+QtIrmZ727DiLELrox/RvZ5nkr2UuO931k3iCeNSTLmhlPBSrNlQIzFL2snwp3
Y0RGgI0QUSc3l/BOP/aPhPTvPgk8JH1zjPRR5tvAPgAMoOU9JcjLDtZA2puNhp+B
UchoZyvlfnF+7rOWzcLB
=kgsm
-END PGP SIGNATURE-

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

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/13/2016 05:32 AM, Alexis Ballier wrote:
> On Mon, 11 Apr 2016 22:04:10 -0400 NP-Hardass
> <np-hard...@gentoo.org> wrote:
> 
>> # Inherit happens below after declaration of GNOME2_LA_PUNT
>> 
>> # @ECLASS-VARIABLE: MATE_LA_PUNT # @DESCRIPTION: # Available
>> values for MATE_LA_PUNT: # - "no": will not clean any .la files #
>> - "yes": will run prune_libtool_files --modules # - If it is not
>> set, it will run prune_libtool_files # MATE_LA_PUNT is a stub to
>> GNOME2_LA_PUNT GNOME2_LA_PUNT=${MATE_LA_PUNT:-""}
> 
> 
> any reason for the indirection instead of using directly 
> GNOME2_LA_PUNT ?
> 
> [...]
>> # @FUNCTION: mate_src_configure # @DESCRIPTION: # MATE specific
>> configure handling # Stub to gnome2_src_configure() 
>> mate_src_configure() { gnome2_src_configure }
>> 
>> # @FUNCTION: mate_src_install # @DESCRIPTION: # MATE specific
>> install. Stub to gnome2_src_install mate_src_install() { 
>> gnome2_src_install }
>> 
>> # @FUNCTION: mate_pkg_preinst # @DESCRIPTION: # Finds Icons,
>> GConf and GSettings schemas for later handling in pkg_postinst #
>> Stub to gnome2_pkg_preinst mate_pkg_preinst() { 
>> gnome2_pkg_preinst }
>> 
>> # @FUNCTION: mate_pkg_postinst # @DESCRIPTION: # Handle
>> scrollkeeper, GConf, GSettings, Icons, desktop and mime #
>> database updates. # Stub to gnome2_pkg_postinst 
>> mate_pkg_postinst() { gnome2_pkg_postinst }
>> 
>> # @FUNCTION: mate_pkg_postrm # @DESCRIPTION: # Handle
>> scrollkeeper, GSettings, Icons, desktop and mime database 
>> updates. # Stub to gnome2_pkg_postrm mate_pkg_postrm() { 
>> gnome2_pkg_postrm }
> 
> and here too, why not rely on gnome2.eclass exported functions (or
> say gnome2.eclass api is part of mate.eclass api)?
> 

The idea was partly due to consistency.  Rather than calling mate_this
gnome2_that, it'd provide one namespace.  Additionally as mentioned in
my initial email, since GNOME and MATE aren't always in synch, if the
gnome2 eclass chooses to change something, and it's better that mate
eclass stays with what we have, all I have to do is fill in the stub,
and all ebuilds retain their current implementation.  Otherwise, I'd
have to mass edit all ebuilds to replace the offending gnome2_ with
mate_.  Furthermore, there was a discussion a long time ago about how
functions shouldn't be called without an explicit inherit.  That means
that even if the mate eclass uses gnome2, if I opt to call gnome2
directly in the ebuild, I have to explicitly inherit it (which mostly
defeats the purpose of inheriting it in the mate eclass).  This has an
added bonus, which is that the gnome2 eclass inherits gnome.org, so I
have to make sure to re-inherit mate-desktop.org whenever gnome2 is
(re)inherited to prevent all of variables like SRC_URI from  being
overwritten.  Hope that I'm conveying that logic adequately.

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXDkHcAAoJEBzZQR2yrxj7s9kQAJIsWD8bIEd6A16ZMCCIbz6M
Usu+JmQGshQjgKyjntkhjWQ3O7pY0IG6yEFbaXOLrt2pDJ3qoabSq2AiEMlJLJ1v
s467fVuEFv4+u50Bza4o2SdD5FD50tnGUOOYLbP8HMHWdOw6qB9o2RbVr+6TU6Ug
KHfErHRAL1TlBKN/MLMFWKC0v+0fBsKcdQeszLvdQwX0Zf2V3/Fw99HhxsdNVYs8
x/xSD2vdh0yA1+CbLx6q/fWKnBWNTIyRvqdtQNyq7BNUwq/46ZjKufksO+hUEBCv
Ai7nxPbOtYvhigRYEYqoSdAmoWxPOgamZGB50P1yiRAyFRI7bPQ5YhQCDflINLLG
59nytNwrZ7xvUKJBdwCeFTjMbG98s1WeFJbbNPDxcWvi9YGuTIa8QHDZt3k9adhH
QSpWeBXDYgWX1Fb+3RQ4J0+gf3uzwNJfMSMkwENJF/FnlDY+MV62XscCuPV4tH5j
39niyqFEmu0v8IWjPdyFY5luyoud+Wxc7+DiFQwh2YamoVV6rwlwtIJVDYaSiHEK
vJqyUvku6egfxzjhmUuKgPdwCXgOuAtTxmv1Yo4vdCP+GGYrINzTZg9V1ez/xAW+
hyUDXZnbqBAS7PDtVkotucB7+kwZV3O43BJ/DyJcDj/kCt309zAViKCMJmO+TWWU
UoFkyP7MGcjxTnY0lyY3
=MC7/
-END PGP SIGNATURE-

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

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/12/2016 02:42 PM, Pacho Ramos wrote:
> Hi!
> 
> El lun, 11-04-2016 a las 22:04 -0400, NP-Hardass escribió:
>> [...] # @FUNCTION: ematedocize # @DESCRIPTION: A wrapper around
>> mate-doc-common ematedocize() { ebegin "Running mate-doc-common
>> --copy" mate-doc-common --copy || die eend $? }
>> 
> 
> Have you think in reporting this to autotools.eclass maintainers to
> add the needed logic to autotools.eclass as done for all the other
> stuff like gnome-doc, intltool...

I hadn't, though, that would make things much easier  I'll reach out
to them and inquire.  Thanks for the suggestion.

> 
>> # @FUNCTION: mate_src_prepare # @DESCRIPTION: # Call
>> gnome2_src_prepare to handle environment setup and patching, 
>> then # call eautoreconf if necessary mate_src_prepare() { 
>> debug-print-function ${FUNCNAME} "$@"
>> 
>> local force_autoreconf=${FORCE_AUTORECONF:-false} [[ ${PV} ==
>>  ]] && force_autoreconf=true
>> 
>> gen_chksum() { find '(' -name 'Makefile.am' \ -o -name
>> 'configure.ac' \ -o -name 'configure.in' ')' \ -exec cksum + |
>> sort -k2 }
>> 
>> local chksum=$(gen_chksum)
>> 
>> gnome2_src_prepare
>> 
>> if ${force_autoreconf} || [[ ${chksum} != $(gen_chksum) ]]; then 
>> eautoreconf ematedocize fi }
>> 
> 
> I wonder if maybe this handling of "automatic eautoreconf" should
> be moved to a more general eclass as there are some consumers that
> are reimplementing this different times :/
> 
> In the past we could rely on autotools-utils.eclass for this, but
> now, it looks like it needs to be redone in several other eclasses
> (for example, xorg one)
> 
> But it's only a question/opinion, I am not blocking your change or 
> similar ;)
> 

I don't have my heart set in keeping it MATE specific.  I just assumed
that since the old eclass autotools-utils was banned without
deprecation and had no successor that I was on my own.  Moreover,
since EAPI 6 forces eapply_user, we have no idea whether a user is
going to choose to patch the autotools build system, requiring an
eautoreconf, so, unfortunately, I think automatic detection of when to
eautoreconf is a necessity.

Does anyone else agree that this is a necessity for autotools based
ebuilds in EAPI 6, and if so, any suggestions on were to put it so
that it can be reused as much as possible?

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXDVJiAAoJEBzZQR2yrxj7+XcQAIW54FgL3DMRxnjvOdaUJfT6
HSY0zFIX+Z9LXPRgpg8HS74pqs9E4KV8hjbAjlIF1Na3QBjfisViQzbyB6AIYhqg
JjfJxgcCK/j0kDWx9AXZJIuBhmoKZMzklde0cqDpcAk2ugdq+AxUu+zvhn7tgbTP
8CF1N1137NIvW0zSUuEima87r8oFWkgWXyGEy93O9++KM1t9QTStOdSb84tqfuhN
iYgYe2qWVGfhYQ1InIQ9OJyazf+b112+WWuUfp9IpmhT5WeoFkXk8hfNE8dYl0G2
FnwiEYpAOMhiOeWrI0QkZ8lnwyunxmlfvmxTygtjK4a8c8HPC3sGmzwJ6Bo74kwk
uLPVsh4ZcWmVnadgKJ/uI/NLc0BREqZQbOYaLDhgHYvoizzeXeisb0H8P6VmtOIN
xI4HOFrfAn5biiBaQiVjilGJCByhMXpnJuINO+dA/ruCGyX/AEmhl+DrSxo27WmO
1q4kO6vie8mqHvk8vvolnQLaULh9xMBsntCf6tzsTpv3Fnb4paeYr+aVOJVNbFxL
hwzkQoV2OJg05uFRkRaq/q6rupbSNoia5+J54GOcwO0+nYxRpQCK/g+7wRdfRlFo
9jmDztDOSqoPOzwnUnHUwPwFDWcCCG5vJYh3wqyW22UZSeEwPfIRxxwKNYf03nn/
SoGl+TI8E8PJHEP/BlYz
=L6YE
-END PGP SIGNATURE-

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

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/12/2016 02:44 PM, Pacho Ramos wrote:
> El lun, 11-04-2016 a las 20:14 -0400, NP-Hardass escribió:
>> [...] # @ECLASS-VARIABLE: MATE_TARBALL_SUFFIX # @INTERNAL #
>> @DESCRIPTION: # All projects hosted on mate-desktop.org provide
>> tarballs as tar.xz. # Undefined in live ebuilds. [[ ${PV} != 
>> ]] && : ${MATE_TARBALL_SUFFIX:="xz"}
>> 
> 
> If you are going to support eapi <6 you will probably need to do: 
> DEPEND="${DEPEND} app-arch/xz-utils"
> 
> as in gnome.org.eclass to ensure the needed dep is pulled in :)
> 

We briefly discussed this in #gentoo-dev yesterday.  I'm not positive
about when that statement is required and when it is not.  The PMS has
a statement that the ebuild should ensure that that xz-utils and tar
are available (as it stipulates with each and every other
archive/compression format, including tar.gz and tar.bz2).  Also
mentioned in the discussion was that because xz-utils is and has been
in @system for quite some time, for the purposes of unpack, there is
no need to DEPEND on it.
I'm quite curious where you got the EAPI 6 boundary for explicitly
depending on xz-utils from though.   Perhaps we overlooked something
when investigating it the other day.

Thanks for the feedback!

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXDVARAAoJEBzZQR2yrxj7iooP/1IAVFkKr1bOtujy6g3steVm
tOWPfI9eEiDIcWOf4lBb4p/nv5AvjMTatilT6QiFnEOLhq/ZaWsOHMKE4qmQHz0U
+u762ejODK2ouR8foPmKtD04ZBkVtYmJ5N6OqWuuQ86LxLhzBsoctLPkPFZu6N//
8UWVsKo5IjNF3oTu3YfQge2Fclp4EDmN2uN9PF3PgmCvPRTrc6/5PhYkPiFYQsyf
313Cy9I2XY+ZhHHKaGawPye1QzY22L9Uvd2d3WatePvtRtS+O3rJXEL8rqk8f4sB
LSud/G+Z5fW1159rGKpUnXDwrBY1A0/j6VS5pe/Fwl4z9qKPmcEo9HcJsxvsMixW
PXZaqfAuYZYaAxcvoJbBPvNn2z+pTLoHJksCasH0ROn3wkDLAWYpokPoCJsa3NcF
JC7k9rRdTjQiRfbUppcDushZ2oGRGxOb1a4oKnNxldaazUhP6ukDR1oqmfmnd1+p
PUt07yR6AhonjmNByO8MPGaNeSDdSSJhYvwCkTRbTcN6jYDkKJOMDcEZIKQmqect
J+bVg7wI7FmI0uUzg7QIIeGrvAemMxEEWHMqxtiKfA6PcZjGJB2x7AFLZkOVho7U
nm758/BgCpryanha36IVzapTN+26lZ9ZTmxyn7kghHoWMThv6m1KuLYsl7GTo/hl
qTVllQPg+iAYvrXadWp6
=+uhR
-END PGP SIGNATURE-

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

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/11/2016 08:14 PM, NP-Hardass wrote:
> On 04/11/2016 01:09 AM, NP-Hardass wrote:
>> Greetings all,
> 
>> As all potential new eclasses are supposed to be discussed here,
>> I thought I'd file a message and see if anyone had anything to 
>> contribute on the matter.
> 
>> I'm in the midst of a major version bump for the entirety of the 
>> MATE desktop environment, consisting of 40-50 packages.  There is
>> a huge amount of repetition in my ebuilds, and a lot of things
>> are formulaic (SRC_URI, HOMEPAGE, EGIT_REPO_URI, inherits,
>> src_prepare, etc).  As such, I think that moving all of that to
>> an eclass would greatly simplify my life and my ebuilds, so I
>> thought I'd look into creating an eclass.
> 
>> Any opinions either way?   Thanks in advance.
> 
> 
> 
> 
> A little background, MATE is a fork of GNOME, so there are many
> things in common, however, the two aren't always in sync.  As such,
> there is often code reuse, but not always.  For example, GNOME has
> deprecated GNOME_DEBUG macros whereas MATE has not done so yet.
> 
> Attached are two eclasses mate-desktop.org.eclass and mate.eclass.
> 
> mate-desktop.org.eclass mimics the gnome.org eclass.  It defines a 
> couple of useful variables, as well as sets SRC_URI or
> EGIT_REPO_URI for a live ebuild.
> 
> mate.eclass is supposed to parallel gnome2.eclass.  A couple of
> notes: mate-desktop.org.eclass is necessary to override all of the
> defaults in gnome.org.eclass which are not applicable to MATE. The
> src_prepare function is borrowed from autotools-utils.  With EAPI
> 6, if any user is capable of modifying the build system via
> eapply_user, I'd like to be able to detect and regenerate the build
> system accordingly. Additionally, upstream does not supply
> Makefiles or configure scripts for live ebuilds, so I always have
> to run eautoreconf in those cases. Stubs: Well, you will probably
> notice that I have stubs to the gnome2 remaining functions.  This
> was done for several reasons.  1) in the event that the gnome2
> eclass goes in a different direction than MATE, it's easy to switch
> our own implementation, and 2) if I don't and I have reference to
> the gnome2 eclass, I have to explicitly inherit it in all ebuilds,
> which somewhat defeats the point the indirection gained by having
> the mate eclass.   I'd have to inherit gnome2 mate mate-desktop.org
> in every ebuild to ensure that everything is inherited properly.
> It's a little bit messy, but still doable.  But for the previous
> reason, built in independence from the gnome eclass if needed, it
> seems much easier to me to stub out gnome2 in the meantime .
> 
> 
Added new function to wrap around a MATE autotools function
mate-doc-common and add it to src_prepare

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXDFeaAAoJEBzZQR2yrxj7LIgP+QGFJ+xdigWpxSDIIqabwozT
qL6hwvAQVHe3gBjGvs3FPOo+FJgzteQE4pRhhkU+g+Zgs9z1f7NIQQZbMwfVrHg+
KYKdufL4Wd2rF/X1qAf5EOqToBxZxpEYH0rPlfirOE4WA0HC5Gke0fwppeu6L8S3
7+N68ZdPKYnJ55+FZAiQCuy9QX3gDHsKhSpd1P4q5+Fi6D+qGYFalOlhhtW6qiOR
Rv41/xEabUha4V9H7YG5j+rROL5mSFchIT6wzx5dDTwQKS2dTclcqEbuS/k45E44
aemZFfb6l8Ymg+o28sCidPlOYyVaF5j7VbIAHNwEN4DNlbbpOJKAE5wTc6zrAyv5
zRVmmlxMlJvwr26faQsKgEGcVTWenmyCDeguSwgDetv1oQrzHtkI9lJMoUdRW39S
5nNp3mA2isUVmQIZRidAnPIJwLWBo7pmRZ67leCuK1UXGvGQWFDKXzPcRShTZRYb
nnE5VamFBlZtfpAnuoLYhNf9i21GJ/SJMxEwWNutdhf343qogfOk+Q7cKuYATEwm
OP499WmH7WNNjMnQiiyj9fC3epXslHN9ibYNoq1tf1Q3s5wIvzJ0ivcD9HZxxERv
usYALHiK1YZrjGpy3Tm1+pt44jwCRt+hVBL+2fpez3ZOpPqRjW24KCnM1ZHILbx4
CSPRFgrQnPUMI4/r6Ew9
=JV4I
-END PGP SIGNATURE-
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

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

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

# Inherit happens below after declaration of GNOME2_LA_PUNT

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

inherit autotools gnome2 mate-desktop.org

case

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

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/11/2016 01:09 AM, NP-Hardass wrote:
> Greetings all,
> 
> As all potential new eclasses are supposed to be discussed here, I 
> thought I'd file a message and see if anyone had anything to 
> contribute on the matter.
> 
> I'm in the midst of a major version bump for the entirety of the
> MATE desktop environment, consisting of 40-50 packages.  There is a
> huge amount of repetition in my ebuilds, and a lot of things are
> formulaic (SRC_URI, HOMEPAGE, EGIT_REPO_URI, inherits, src_prepare,
> etc).  As such, I think that moving all of that to an eclass would
> greatly simplify my life and my ebuilds, so I thought I'd look into
> creating an eclass.
> 
> Any opinions either way?   Thanks in advance.
> 
> 
> 

A little background, MATE is a fork of GNOME, so there are many things
in common, however, the two aren't always in sync.  As such, there is
often code reuse, but not always.  For example, GNOME has deprecated
GNOME_DEBUG macros whereas MATE has not done so yet.

Attached are two eclasses mate-desktop.org.eclass and mate.eclass.

mate-desktop.org.eclass mimics the gnome.org eclass.  It defines a
couple of useful variables, as well as sets SRC_URI or EGIT_REPO_URI
for a live ebuild.

mate.eclass is supposed to parallel gnome2.eclass.  A couple of notes:
mate-desktop.org.eclass is necessary to override all of the defaults
in gnome.org.eclass which are not applicable to MATE. The src_prepare
function is borrowed from autotools-utils.  With EAPI 6, if any user
is capable of modifying the build system via eapply_user, I'd like to
be able to detect and regenerate the build system accordingly.
Additionally, upstream does not supply Makefiles or configure scripts
for live ebuilds, so I always have to run eautoreconf in those cases.
Stubs: Well, you will probably notice that I have stubs to the gnome2
remaining functions.  This was done for several reasons.  1) in the
event that the gnome2 eclass goes in a different direction than MATE,
it's easy to switch our own implementation, and 2) if I don't and I
have reference to the gnome2 eclass, I have to explicitly inherit it
in all ebuilds, which somewhat defeats the point the indirection
gained by having the mate eclass.   I'd have to inherit gnome2 mate
mate-desktop.org in every ebuild to ensure that everything is
inherited properly.  It's a little bit messy, but still doable.  But
for the previous reason, built in independence from the gnome eclass
if needed, it seems much easier to me to stub out gnome2 in the meantime
.

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXDD34AAoJEBzZQR2yrxj7ELkQAJK78s2tNt67XR7fgIYWZkTa
a52MsFdW5e14yqKZAmKZqIde3zRo65BAoa15BVscM2o9iH1CtJolbrq0i603OBej
RGt5RkgOqmUYg8lU/z1fyX7PLzm3ukTBSNQ0Y5m5jofo2sbg4WMFiaaQkmvChnQd
TA5dI+nMzz8gfQJvXoorj+JZziOikH4i8lsge2QKP7IUDe16fjUO8VM8J+5v4uk+
XXeIPFq3PXoHeGW9jLo9jibapntDlPOStoalY5dRIkIZSpe124TfVhCSOMeuWtRB
VzvvaW+D2MFL9NU2WcsQtU8H71CY/bZl3qPiA9n6OcFowIyVXBP9W7lhpcBmWbYx
HIsI8UEXriuMJPhiZ/mzkEKaXohElcvbolvQigejGCxzJVQ1fxpoHINXaN/KCEQ8
fxsKeLCM/toPuFcqjru1znZb05cLm1UAcN15YK3ldrcJNGY9tPxHj09dt74eIWor
49HZeFSftef637vFA+3NEN9aVVRyd9O9Fc+wK8FI7ki3O2br4SoOw122NUfjFWoB
4xguWOJjspcbxobzK7nzrKhTYLDhh+oymTj4TLmmzvTo3zgBgYhbVJNP5HoycfPB
nZBzYZIht0bl/BbdGvdOyDVacLG+X7QlWKcx/bUmcrv3rih59D8XrtzlVhOavvhW
RZ4Wo+feNwXrLN9aOfcL
=GGgO
-END PGP SIGNATURE-
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

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

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

# Inherit happens below after declaration of GNOME2_LA_PUNT

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

inherit autotools gnome2 mate-desktop.org

case "${EAPI:-0}" in
5|6)
EXPORT_FUNCTIONS src_prepare src_configure src_install 
pkg_preinst pkg_postinst pkg_postrm
;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

# Autotools requires our MATE m4 files
DEPEND=">=mate-base/mate-common-${MATE_BRANCH}"


# Wrapper function for handling 

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

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Greetings all,

As all potential new eclasses are supposed to be discussed here, I
thought I'd file a message and see if anyone had anything to
contribute on the matter.

I'm in the midst of a major version bump for the entirety of the MATE
desktop environment, consisting of 40-50 packages.  There is a huge
amount of repetition in my ebuilds, and a lot of things are formulaic
(SRC_URI, HOMEPAGE, EGIT_REPO_URI, inherits, src_prepare, etc).  As
such, I think that moving all of that to an eclass would greatly
simplify my life and my ebuilds, so I thought I'd look into creating
an eclass.

Any opinions either way?   Thanks in advance.


- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXCzGLAAoJEBzZQR2yrxj7knsP/AyP3yREWCEuw/k2IbAw987y
QM78PN1u1IYA1YtP1IDFyOd91aGuIqwtURdoY6zq7ExBA8/5nftMHalgz5kfUyFn
lXhe5ZYsnFUAMIJHrsdECFdRbK7RfYYraEZSRyPs4kZJjUrg4PLiFuJIy8ITzq5p
Ul7hD8pFIEMpgEmWly/cJ5G7Eatl8A8OgJW9LAYOxDDFdNX1xvzP0VQhRE9lBE7u
SiVPI+iTwH5yIM4KDpKPGvsCOR82ijj661IMFa/sJdZdwWPmtf8LRQb12CMk/Yjr
YheUgamZ88KC4zd55mLotZGi7g71Lof7IRByzOO5VsWRpW5h9vm+ivVLLI72fj9W
88lmmvJ6f/Pw1w8WXeX/D8wN4PE6veD8Y/O/P3czIi1zXQM+IRZhJmoxpCiQng93
fXdLd2h0o2ntx1qsubIHU/fiakz8RZtsO0zQbYdrvC+YV2+IJTuKfco8YyWgiNul
PsWuVCcM8cjVVIbk10Ny93MLEkhM2DvUsu35imFfJzIU1eCFo9PtD3YEOzqStNuB
uNeOZi5PAhWllJCVgNkO2a0hXpA/N24a0TUh5CFS2y/rZ7BH3ydGVg8D0nkwx4dV
2f6/ydR2cNmLckPVdfrXljFgE8vDLrobZaBWvyxbQqyslLbb684Js5KjH9T1fgPt
7ibouuaYZ80U+FiL4mtu
=/7NT
-END PGP SIGNATURE-

[gentoo-dev] GitHub GPG Signature Verification

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Greetings all,

As of yesterday, GitHub now supports GPG signature verification [1].
As a result, when viewed through the GitHub mirror, all commits now
have a widget that displays whether the GPG signature has been
verified (via GitHub).  To help facilitate this, it is highly
recommend that all developers who use GitHub update their accounts to
include their GPG public key [2] so that their commits can register as
verified, where applicable.

Just a disclaimer, I'm not endorsing the use of GitHub, nor advocating
for it, simply indicating a new feature which it would be nice to see
Gentoo developers on GitHub taking advantage of.

- -- 
NP-Hardass

[1] https://github.com/blog/2144-gpg-signature-verification
[2] https://github.com/settings/keys
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXBUzdAAoJEBzZQR2yrxj7IWsQALU1drSsPdV02PJVExz3xuVL
gVB+8D6srxF9A2tlE6hBSPQCYkX9H0lHvt81WLOhKrIGxaNJJuwXlMKlQascpIer
+OeLwA/5Nhn3MukOQrQGEUEP9EKaj8DqpoeqEzoshQHrdoj3thrxPoYjntRl+Ceq
GH9gctvPyHAVXbZlKQ+T6yKOVlwLWeDNUkQAjW9hUbu+t33lO51PjqTto7tdj1yh
lo12J4xu0lShBduJPomjrv9DH+rZm5dh4fC68d0wSVX+fdScLcVvgDJoxB3jsAHU
IQs7iL0DToLQ2lkBMz0aZdwj8LRL0vGjipSGikvS+R9zxS/5elu2WvbGjrAOv51u
nXpA3iQmo90k1VIm9VpU+2DxfPxqB0jIpc+91umKvGOlb4ySECc4C9OGn+jQXKwY
fW/T/3zCik2dLmS02hUaZd5IbbnZhaRy7Y2VF17IdddP6V5SLvVahv431ezkmFR/
91PzD6ji5+Xti+dagVEWqoW6r7xUM9MBX113gicrT/3A/gSBW3DFtc/iDjjp+ABd
HwI4mfCxEIl2p8y1YYfI3jgddMxcZpkaiQ/Av26PvUfNCN/lK3gbxiCMfuEcJZ5z
gzFULA3r2Qf3Vz/8diQjf8lRLt2vjz7NDDcT0s7PE+xXJ/I2DmjAP9f8NJZ4sZ/X
4uOd3r3sHkh9BcCKGCv1
=TanJ
-END PGP SIGNATURE-

Re: [gentoo-dev] [PATCH v1 1/3] general-concepts/herds-and-projects: update per GLEP 67 #572144 #549490

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/04/2016 12:34 AM, Göktürk Yüksek wrote:
> +sufficient for adding or removing a developer. Note that
> different +projects have different requirements and procedures for
> recruiting +developers, which may require prior arrangements to be
> made before +modifying the member list.
I'm not particularly fond of this statement.  The implication is that
most projects require permission, whereas I believe that the opposite
is true.  To the best of my knowledge, most projects are open, and
ones that have special requirements almost always list them explicitly
on their project pages.  As far as I know, the only exception to this
is new developers, as they are noobs and thus project lead approval is
a slight quality control. I'd rather see it worded more like:

Seasoned developers, generally speaking, can join any project at their
leisure, however, some projects explicitly list restrictions or
requirements to join such as training, apprenticing, or approval of
the project lead.  When in doubt, consulting the project/lead prior to
joining a project.

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXAfRPAAoJEBzZQR2yrxj7ER0P/1CGUdUBNaGNV6BmawohnbIs
U6OsqSGOM1VJk6KjG+wZkhi+BdbNfTrv/3ynrE39fJO1XqmOrBRSJ5PBIpQZHoHP
N6IfiZgUHvGpdFr8nmLrEBNSP9VUZ56UJYS468hWObUOehp1V4TZDfKWAoi1SA5k
RwAZUu0L69I6I06wodnP1yBuIk56sPmCUdwGC0oOmQnEyPdIsQ934VYnRg2yfXqg
8fFaoXdPYOX/Au+dEDGyEWVRd73XRyMEFkt3IVvewph1X/nQ63ArbYsiNvTh/tnO
XLz0M5Tk726ONRRflvb2A5K6fC+/s3wQBGWThLJcuA45MOr470EBsnAy0Ii1ZuD3
WtRT1h57pBO4HEZ1WQfgfAfNRXgp4E8hiCY5Rgd0CcI/Z/QzLrZG49oFaWiTfd7I
wfIWZ0oyrYtL9UiXBU8ArDjQmQRqbS4iATMeXvfHLFUAYjXrySwdlTEa/lK7OVWE
8WAL2SR/UUrzn097NuT2Sj270a9ShmW9rdM6hl9gnRlwbO4+K2KwXHh1FK3sx60g
MOAgy0jxVaNWqjwrXEocXbziQIqofmRa47mcjJ1/ipH+gWZfoYt6gICIziIkCJxH
GaCURYGwFdGvfVLdDsKaopVcJ31XbQZHckYSrJcRqtLd2QCTRV19R/FYORDiTJU2
LTyD0d43Kh5E6Ob7PA6b
=50RB
-END PGP SIGNATURE-

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

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/11/2016 07:59 AM, Rich Freeman wrote:
> On Wed, Feb 10, 2016 at 10:46 PM, Daniel Campbell <z...@gentoo.org>
> wrote:
>> 
>> On 02/10/2016 06:51 PM, Rich Freeman wrote:
>>> 
>>> Ditto for stuff like 32-bit support for half the libraries on
>>> your system when you're using something like wine.  Just don't
>>> set the flag except explicitly if you actually need it
>>> somewhere, and it will get pulled in where it is needed, and go
>>> away when it is no longer needed.
>>> 
>> 
>> re multilib, under what configuration does abi_x86_32 get set on
>> its own? With a blank ABI_X86 variable in make.conf? Every 32-bit
>> package I've ever pulled in has needed that flag set, and I've
>> had to manually set it until blockers are resolved. I've not set
>> -abi_x86_32 globally or anything like that.
> 
> We're talking about a proposed portage feature which hasn't been 
> written yet.  None of the behavior described in this thread
> happens today.  Right now all those abi_x86_32 flags are set
> explicitly, which is why my package.use file is about 10x larger
> than it used to be. I'm contemplating splitting out the 32-bit
> stuff into a separate file and just nuking it every 6-months and
> allowing portage to re-create it to try to keep it somewhat
> manageable.
> 
> And that is the inspiration for this.  The current design mixes
> true user preferences with stuff added by auto-unmask needed just
> to fulfill dependencies.  Users should be easily able to prioritize
> the one above the other.  Indeed, maybe I have a few 32-bit
> library preferences which are explicit and now if I go to nuke then
> every six months I have to keep track of which ones are which.
> 
> With the proposed lazy use flags then for the most part 32-bit
> support would be automagic for most users.
> 

Just a slightly OT side note...
I split mine off into a separate file (using a directory for package.use
).
I proposed a feature a while back,
https://bugs.gentoo.org/show_bug.cgi?id=534548, where all use flags
are stored in /etc/portage/package.use/${USE_EXPAND}  to help with
management.
Yet another feature similar to lazy eval of use flags is another bug I
created a while back, recommended and conditional use flags
https://bugs.gentoo.org/show_bug.cgi?id=539124.

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWvJKXAAoJEBzZQR2yrxj7AA0QAJitT6khf7R9ShDTMOuv7BWG
H6APtpLWQCOVmsHo/5muDE/YTytIe+d7OIf4lvjXOegA9NcskZd3PFCuE0ixORhE
bo6q2eO+sgEgJA4pkWUoxbovm7esM6AHnsnKb63EymfwJz2GReTkgkgZiG4c4o3y
60twObyNzDmfsKoVGZWUL5Z4kk3WrgRq78Dtg50fsOlGgAKw27LObf2OIzMqFcWt
w0zHLu48dffae3vQ8Y1RpG/hGP/GFw/Czb/9XhU+BVvZrwtLjH/4hmEWRwUve+g6
6tpxUuiOi3VByxj4OklRxyxhlZypA2rmGu4WS3dzsw87tmJ5nZ9ASRsO5uKQ61wP
YskaGYyVn8v/26zL1Mw+XBsw3OFU1O5tHhaQazVW2fdv0vhnOOS+t4HUH2DKM2xV
Yo4OAX0sWHKpCZwiRE6Wi4JUHLHxF2+wlHx9+XKR9q5M1ErmMyG+ovPXBFhiZ2mH
6kCkh59HiL67Z8wplM/51rQA6dj2cgPZ9MosNCIRX+szpjsJN6sLxuGykIJAUVUU
0MVS/N+PgwMSSXtAZIE4Kd28qqoqYbw+qFQ3hqxBp9D8WzQf4c6HysAGDI7PAJeM
hKbmfE6qnn27py1Vm+FvL0rGpfsMRdSmcbT3QGh/XCgKLl/VE64ALwYNGgaeJ0iJ
WHRYXZf2dwABaCx248SA
=kznA
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: Automatic Bug Assignment

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/06/2016 04:43 AM, Duncan wrote:
> Talking about which, I've toyed with asking for bug-assignment
> privileges for awhile, but haven't known who to ask, or if the
> privilege model is fine grained enough to give me that without
> giving me stuff I probably shouldn't have.

Currently, there exists one method, the editbugs privilege.
Basically, a developer sets their Bugzilla to watch the user's and the
developer is responsible for making sure the privilege is not abused.
 As it is right now, it's an all or nothing priv (as far as editing is
concerned, still restricted by ACLs out of private bugs, etc)
https://bugs.gentoo.org/show_bug.cgi?id=editbugs

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWtcHuAAoJEBzZQR2yrxj7msMP/A1QtPS0saGRovQJZgwk5GTW
vNLxOsqd7w3jwel5sDcnsar9BARj04PdbYmF2baPg8N6rfFmJ+nD47olvym0maI/
JgEVJNiy2H1gJfR7Hz3UGDPeiYUnuQTpFe+fpIRU6yfqTGEIOt96wPX9bhKbp8+y
qbkaDfjmFLtvCQDPevvu/UuZHRZWBVvE4yrifOqHoAPeyD13qb3+1+yQdMLFCLxc
ZiC25qsHyRuPamzIgPK3CMBHaegGzRmuZ7bhhs90jndyc5OvSaE4E/dsO3PrG69f
vacCMY2WTRtbugyVTKKOzoROAd0PWYMvlFQvjJHG6ZQgswd2rlkaYkd4zzL1h2xl
l+ToDbZpL3/S9mBjjwObJ3rCGnU8HMdIFy9TRfeJpELdXj9P/6dczhgcsT6Fy3Wl
KFSREh7SGPLqc9A4Uddx++uJq/TTcvBRgddc26GEaXbrAra6BfaYqd8mswDCCIM1
H5CE4I0KlISsI2LUpMtRh0RxoqMJ7XwKxyflLvsTM2SkMb9naipriuFJGZZZsApB
6NAuZWhtqtvqa9PT9QdLK5mm1K/XYKqZRZPDzAAs70zcoCEPKqhczPIP3D/e1IHq
I/h54ns7OjINRXsY99mGx9ZUSYvKGgD5voxkfQD+sNeBf7HTPAbzyy5+8ZY0juKB
xdzySoZX2Vyik7ArQr6Y
=iHA4
-END PGP SIGNATURE-

Re: [gentoo-dev] Automatic Bug Assignment

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/05/2016 03:47 PM, Rich Freeman wrote:
> On Fri, Feb 5, 2016 at 1:27 PM, Kent Fredric
> <kentfred...@gmail.com> wrote:
>> On 6 February 2016 at 07:19, Rich Freeman <ri...@gentoo.org>
>> wrote:
>>> 'd be all for automated bug assignment.  Usually when this
>>> comes up a bunch of hero bug wranglers step up and say it isn't
>>> needed, because we have hero bug wranglers.  As long as people
>>> keep stepping up to do that I'm not going to tell them that
>>> they can't.  However, if the bug queue ever does go out of
>>> control I'd be all for just auto-assigning them.  If they
>>> rarely get assigned to the wrong people, then they can just
>>> reassign them.  And nothing stops us from having a bugzilla
>>> query for "new bugs filed in last 24h" for people who want to
>>> take a quick look at recent bugs for trends or to help clean
>>> them up across projects.
>> 
>> 
>> Hm, or alternatively, you could have a scheme where things
>> defaulted in the bug queue, and were auto-assigned where possible
>> after no feedback for a time, or maybe it would be defaulted only
>> when the queue is over a certain size.
>> 
> 
> That was my thought around having a query for bugs filed in the
> last 24h.  Basically they'd be auto-assigned, but people could
> choose to review recent bugs to see if any were mis-assigned, and
> no action is necessary if they're OK.
> 
> The main problem I see with auto-assignment is that some asignees
> end up being black holes for bugs.  If two active devs get their
> bugs crossed it isn't a big deal since they'll just reassign them
> to each other.  If an active dev gets their bug assigned to an
> inactive dev, they might never hear about it.
> 

As an alternative to bug assignment, which does carry the risk of
"black holes," what about automatic bug CC'ing?  That gives the likely
party the heads up, and if they don't take it, wranglers take over and
determine what to do with it.  This gives us some degree of automation
(automatic notification, but not sorting), and leaves in the space for
the wranglers, who I believe are important to getting things where
they need to be effectively.

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWtb6SAAoJEBzZQR2yrxj7n6IQAIcEmhkIUUie4u6DsodgCRSc
qnP5cqR9C/0EyXZwQwbntX6Zh18MoFS9/VqQt9kHwFiuqsJaNoxZVMaofM58dwq+
BZN5kq4qVO3TI9gp3D4Y4PlzjnYvOg7eiEPRyHy02ZTvJ/Hjhq4wC2VhIKoTF3EF
L5NKqWebwOre62xCHWeCM0EJGrTj/j/ggSrTjMMrpF/iRJM880IA4j+Nqr3CwLkB
jH7uM2b2fgjDiyztwKdk90yspax/CBBG0F/XGyuj2bO4BaCCHFD8xDj8lLALkneJ
D/ihRjNMkgHW6gHRXhrUfABPFEGULadpXKFt/G7RWi0hcn5fjuoRpaoA8k0z/8wl
YxhQFPdTtfgiQhiL2q5wogSzwXbiliWQDeonBnboC+CKqxByEumOYi05jXgGbBx7
mPUcdjKmePbbM4SW/WPbr57HTdMZ2G70EFlg5UNGNN4phvX7T2tz3fiCRLqiO1nm
UTbykpwACnVTcWmNFgWD11xg4oISr8kxcoql86bwFJdT3fVGedLNwOE3f6YRryZC
mxt/PbqVHiVuFsZTgLHC/NdV52DD9QQhBDaBxZnQKazPDaqVbNyM6fbwf54xDRbZ
fO+ZrKix2n+n+aE8bUBmJQ66v8+upBKOSzIu741bW4eKAYdF8+9iJKRVKEhT6Mx2
efg+xYoIkEtrJTKTdKNG
=iylA
-END PGP SIGNATURE-

Re: [gentoo-dev] [PATCH v3 00/21] devmanual: update the docs for post git-migration

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/03/2016 08:10 PM, Daniel Campbell wrote:
> On 02/03/2016 04:57 PM, gokt...@binghamton.edu wrote:
>> From: Gokturk Yuksek <gokt...@binghamton.edu>
> 
>> Hi,
> 
>> This is the third iteration of the patch series that attempts to
>>  update the devmanual for the git migration.
> 
>> The updates included in the third revision are: - Added a new 
>> subsection called "Git Commit Message Format" based on the
>> commit message format included in the Gentoo Git Workflow wiki
>> and the feedback provided on this mailing list. - Based on the
>> discussion wrt how well git deals with compressed patches, I've
>> decided to remove "because git does not play well with binary
>> files".  It's a policy we have been following for years
>> irrespective of how git deals with them. - Rewrote the subsection
>> on "Removing a package" so it does not use 'git commit -m'.
>> Rewrote the example and added the corresponding commit message as
>> an example. - The subsection "User-submitted Ebuilds" is modified
>> to mention the use of git style tags in commit messages and a
>> reference to the commit message format policy section has been
>> added.
> 
>> You can review the changes on Github for your own convenience: 
>> https://github.com/gktrk/devmanual.gentoo.org/compare/master...gktrk:
devmanual-git-migration-v3
>
>>  If you want to see the diff between v2 and v3, you can clone the
>>  Github repo and check the diff between the branches 
>> "devmanual-git-migration-v2" and "devmanual-git-migration-v3".
> 
>> The HTML version of the devmanual with the proposed changes can
>> be found at: http://devmanual.qui-gon.org/
> 
>> Gokturk Yuksek (19): general-concepts/manifest: drop the use of 
>> "CVS keyword expansion" #558642 general-concepts/mirrors: 
>> substitute "CVS" with "the git tree" #558642
>> general-concepts/tree: substitute "CVS" with "git" #558642
>> general-concepts/tree: replace the mention of ChangeLog #558642
>> ebuild-writing/misc-files: replace the code for cvs commit with
>> git #558642 ebuild-writing/user-submitted: do not put user
>> information in ChangeLog #558642
>> appendices/editor-configuration/emacs: remove the CVS related
>> setting #558642 ebuild-maintenance: rewrite the text on adding
>> binary files to the tree #558642 ebuild-maintenance: rewrite the
>> subsection on commit policy for git #558642 ebuild-maintenance: 
>> rewrite the subsection on upgrading ebuilds for git #558642 
>> ebuild-maintenance: rewrite the subsection on moving ebuilds for 
>> git #558642 ebuild-maintenance: rewrite the subsection on
>> removing ebuilds for git #558642 ebuild-maintenance: rewrite the
>> subsection on removing packages for git #558642
>> ebuild-maintenance: replace "cvs commit" with "git commit"
>> #558642 general-concepts/git-to-rsync/diagram: update the
>> description for git #558642
>> general-concepts/git-to-rsync/diagram: update the description for
>> git #558642 general-concepts/tree: remove the reference to the
>> ChangeLog #485314 ebuid-maintenance: add a new section called
>> "Git Commit Message Format" #558642 
>> ebuild-writing/user-submitted: mention git style tags in commit 
>> messages #558642
> 
>> Michael Orlitzky (2): ebuild-writing/misc-files: remove
>> ChangeLog section #485314 tools-reference: remove the echangelog
>> page #485314
> 
>> appendices/editor-configuration/emacs/text.xml |   4 +- 
>> ebuild-maintenance/text.xml| 281 
>> +++--
>> ebuild-writing/common-mistakes/text.xml |   2 +-
>> ebuild-writing/misc-files/changelog/text.xml   | 111 --
>> ebuild-writing/misc-files/metadata/text.xml|  16 +- 
>> ebuild-writing/misc-files/text.xml |   1 - 
>> ebuild-writing/user-submitted/text.xml |  14 +- 
>> general-concepts/git-to-rsync/diagram.svg  |   2 +- 
>> general-concepts/manifest/text.xml |   4 +- 
>> general-concepts/mirrors/diagram.svg   |   2 +- 
>> general-concepts/mirrors/text.xml  |   2 +- 
>> general-concepts/tree/text.xml |   5 +- 
>> tools-reference/echangelog/text.xml|  32 --- 
>> tools-reference/text.xml   |   1 - 14 files 
>> changed, 247 insertions(+), 230 deletions(-) delete mode 100644 
>> ebuild-writing/misc-files/changelog/text.xml delete mode 10

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

[NP-Hardass]

I'm not claiming that this is a new problem or that it will be orders of 
magnitude worse. Merely that it brings the issue back into the forefront and 
that we could benefit from official policies and (in some cases renewed) 
efforts to reduce their impact. An official policy/action is not likely to make 
an impact than an ad hoc, unofficial one, IMO.

On January 19, 2016 5:51:27 PM EST, "Michał Górny" <mgo...@gentoo.org> wrote:
>On Tue, 19 Jan 2016 00:44:49 -0500
>NP-Hardass <np-hard...@gentoo.org> 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.
>
>Oh, and just to be clear, this isn't going to be some kind of huge
>growth. Right now I can count 380 new maintainer-needed packages, from
>which some will most likely be mapped. I would estimate the final
>outcome to around 300 packages, maybe less.
>
>Now compare that to the current 1212 maintainer-needed packages.
>
>-- 
>Best regards,
>Michał Górny
><http://dev.gentoo.org/~mgorny/>

-- 
NP-Hardass

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

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWnc1RAAoJEBzZQR2yrxj7WMYQALdOH13N+N0hCuDrCKcFwhp1
GjosbY2ZQsqVL8WX46K8I+Kr9EV/JD1LWfB5S24YMANFgk+iAHJUlDebKmbIOUek
JiT1eRG8LrIJE3VWfMtJxMfPxzkYEPf+Ew3DXBADekhtWbIb3Ha9hWYGgD/gZ2UN
vY0xDBU2oXuJjoSTYwfdbVXG950CgiEfI+QtaeHaMihdqR/ZB7WcHXx788EnnXeA
Q9M3JtNbRyLL7UI7XeVzxN7A+ODhN3highYXELdImHR5fZh2T7sm1Limvev5lgaU
uiugUMnFbDISqiWLSPFbTaJBwrl0tyqa9hjYnhP9LLj8zIXLe/PN+8hQ7Et8aq8w
hRUr6ntm++4HFD2TKySZ4So09yntb+xapeFIM4UjTvN6Tfy2gUyTnpzDdsAlBoHt
zhExBzidA+g1syCY5LrMkndP+8iKDDbUlPkMtfldf2XBMXu5jFBfUXKoZRFC9P27
XOqneJHcBEjocjvcmnu4BeUz0+Nu3jRpQuGj35hNLTsFyG7Dh9Qw1eJ0mDnCm2PZ
YrWWw2Z7nJGKsStwI3Ox6HIeXHuiFGup4XfveC0jE/ggZcK+E9jrkXDbwc9sOPYg
WRMsgCHFHke1YgPhOxHA1RSE0bZv5j9CYkJx8piif8c0p1HkPUj93r3zgpycfSRi
35R7+OKBC4AQeIIoCBXI
=5UdF
-END PGP SIGNATURE-

Re: [gentoo-dev] [PATCH 05/16] ebuild-writing/misc-files: replace the code for cvs commit with git #558642

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Several reasons for discouraging -m.  Here are two (there may be others)
:
Firstly, with repoman commit, -m prepends "category/pkgname:" which is
the style required as per the git workflow wiki.
Additionally, for both repoman commit and git commit opening in an
editor allows the user to make sure the first line is under 80 chars
and enables the user to more easily conform to the desired format by
having additional information on lines >=3

On 01/17/2016 05:22 PM, Göktürk Yüksek wrote:
> Manuel Rüger:
>> On 17.01.2016 08:55, Gokturk Yuksek wrote:
>>> Replace "cvs commit" with the equivalent "git add && git
>>> commit" version.
>>> 
>>> X-Gentoo-Bug-URL:
>>> https://bugs.gentoo.org/show_bug.cgi?id=558642 Signed-off-by:
>>> Gokturk Yuksek <gokt...@binghamton.edu>
>>> 
>>> diff --git a/ebuild-writing/misc-files/metadata/text.xml 
>>> b/ebuild-writing/misc-files/metadata/text.xml index 
>>> e506b1c..a8beacc 100644 --- 
>>> a/ebuild-writing/misc-files/metadata/text.xml +++ 
>>> b/ebuild-writing/misc-files/metadata/text.xml @@ -532,7 +532,8
>>> @@ is currently:  xmllint --noout --valid metadata.xml 
>>> glep31check metadata.xml -cvs commit -m "Adding category 
>>> metadata.xml for my-category" metadata.xml +git add
>>> metadata.xml +git commit --gpg-sign -m "Adding category
>>> metadata.xml for my-category" 
>>> 
>>> 
>>> 
> 
>> Can we discourage to use "-m" and prefer to open up an editor 
>> instead?
> 
> I think the purpose of "-m" is only to illustrate the example of 
> adding a category with a proper message rather than suggesting a 
> workflow. Note that the section for committing packages suggests 
> "repoman commit" which opens up an editor by default.
> 
> Is there a particular reason why we should discourage the use of
> "-m"?
> 
>> Cheers,
> 
>> Manuel
> 
> 
> 

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWnCFkAAoJEBzZQR2yrxj7p54P/2gBHfvyEJx59VrMSUZm/ZZi
fzQcOeOjRHWtI1Uz1f15J2eVjq0qQ+B8Wddczsq9Xj70sb8Bgd42B87Im+qo8AmD
2DJVkAveOEOd8UTz6BOkRqksYc2EDHLMv9Nu4ZukAdM56NwNQEfE2du9N/sOVr1D
LAuni26JD2nhIGc749qwUX46gijGEww5gOwNEtMlSS59XeLuYnWSDacxKj19zApM
Zx8HfHlysILT8EkM0HZ73fKEcAfT7ZKbgq2rKlPv4FwogprNcj/IWasD5o9d2d7b
0zFLExdBMGVHGHDc1hu8M8ofFB0B0cRa+3QEJX3hvSxPOqmRtb8E3GAu20JtPJ69
UVivK7CT1qQIaLuIlGC95Ny06ZRLKp5mNQ1Del6pDDJHjs3b2O3P1wTTNH/RuE5V
MZGKQpLojpmNTepOiBbOxfKJjvDhoQ5yzJ7qw0q4K23awRPj5j/5plKt8kwznySH
EBNLqRl8E+Q1BJ91wNJZVtXtOhc0Lu+03cEJ95D1f55sOUdStnjBaMiZAKP3gswa
YWdaRsONtuCx6BEhILdd0lVOnCIz75YwW8Le3DyitLO3Klf9WA2EeYAYmWmiLpas
L6Z7SU1I0M//gJFq1JdeEAZGNoVoVQJBVQ04tM+9VMxijmGdArzdRmye41J+60ZR
ctBkIkyPn5mlmrOp/Qxo
=pg/V
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] Wine Project

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 31 Dec 2015 21:29:11 -0500
Andrew Udvare <audv...@gmail.com> wrote:

> > On 2015-12-31, at 17:03, NP-Hardass <np-hard...@gentoo.org> wrote:
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > Mostly just a formality...
> > 
> > Firing off an email RFC for the Wine Project[1].  The only purpose
> > of this project is to maintain Wine and Wine related packages,
> > taking over the place of the former Wine herd.  
> 
> Just saying, since Wine updates relatively infrequently compared to
> bugs reported for newer apps, I would love to see more support for
> the patched Wine versions somehow.
> 
> https://github.com/wine-compholio/wine-patched in particular.
> 
> Andrew
> 
> 

Hi Andrew,

We have wine upstream pushed updates almost biweekly.  In addition,
wine-patched is wine with the staging patchset already applied.  We
currently have that available to users via the "staging" use flag.

If you have any other ideas of something that we might be missing, feel
free to let us know.

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWheWCAAoJEBzZQR2yrxj7ql0QAJVMBEhJmTvRkGXGzf8wbbCj
h/ri4r7Pb0IuVa+kcCzSLjS6JC3jOPa59pMe7kffKsSbI96YU+bfGoZj0jzctryp
bRQ1GFFLU7Ndpfnz7ax1XrnVlxytEbJ37G4aAME8CIteXwFi85pjctU+oCz4LFVb
FVVzKyniomk4M8u9NiTFCu8BuKm/hAuGAIHE+9WjWd+u2ousMG/GsSd2X9iZt6Ue
31SXRHFJ+GvfmyHXSw9QfWI/USfq8wMQ+cJ3GSVT0rW45DY8oNY2mi4U8O5NZ1I3
6ryTeM0M23Agc9xp2NX3HoXly2/lghaArZ2M5I9T/IscdPQnHLpOCqN1ZJx/aRAh
oOoKxDTopeMPNGKpW4jz6IICNekL/e3azNakwUcvmQW5/KV4XMxFiZwJTIp9fOz5
OdH705vrFN3dkPueqGYnmmm/p5wY1M2m9yawIQjtb0nx3kbhCC9H7HiatV7zDn9l
xBibI8TZ/hiWpobzbbjcOdMSAnHjk7jr3S6XLmcKhOfP72XY4dDrfcBscr5b6ysX
AULyrd4I6hr2agaAS7IU0iKGpmAeUqGUnOfHBoZQXMM+m07nSWtLdReql0F2rar/
teFCqcsPBxbsQSLWtSTsYsFYQ8Z7UHD6WeWnofvrUsiVyATazi2KL3Sdk7Sdjik+
nh2tgv7QDxMjw4AgbwVZ
=E/nt
-END PGP SIGNATURE-

[gentoo-dev] [RFC] Wine Project

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mostly just a formality...

Firing off an email RFC for the Wine Project[1].  The only purpose of
this project is to maintain Wine and Wine related packages, taking over
the place of the former Wine herd.

- -- 
NP-Hardass

[1] https://wiki.gentoo.org/wiki/Project:Wine
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWhaYtAAoJEBzZQR2yrxj7sl8P+gKHkv2qTf2uNnw7dzBnuoDY
K9TnUzb7qeEGUIfkPrkPLsWk3RgRUrmX/vLgK/sKRXn4dVhyKJm2Q2BXsZ/u6NeM
eGHHh7EqyOhtw+YvSdUUHg7plY4ekGe/adJ7h84P4NAxpcc8rDc3vQtGLC8VCYSj
x5nH3ReYih55Lz/JFptTZ6LpYRayvgegJ97yHI/2wfdOR20EnKTahImDMYwXTWlw
Y/3VjhVvqEavGizYHIDNLYJXk2UT86mZWwho5BkpCtuhFC0nBd975VITR+Si3P41
aXg5O7YcBWfwxBVmy9IYNpTT4NI1Irmikxlg0Nf5aKpnK4ttsyQPeu8apx+0Xahe
nfUWzp84KdjNXnDgYpLDqkHY/RfiGecA3XCRPPVyQwhc0txUYGH36rGlkQRtcmcd
yuE5TmoM84WWUogaS7x1PIF4c3irOfUv+Z6ecYkbI6632WJI/gG+cjE45egPHnaM
J5FfBVQds1AvtC6CpOT8UzZLfS4XjBoxLskiK6QMPmJsDGRAV3lyzMW5PJc+A+dA
guO1bb6cFfrlXkKCIHqmV4n2FKwJH9PqOZCVt3S9mzrZ7E9/VyxLJoyI2DdAyTtp
vgtrFr7cxlcuQn+0jwj4X+YnbLAbVlrb0y3XovtJ6mzli2kk3m62fvE/thPdA5zR
MJhfbeYm/fYoqps2eHtD
=8n+m
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] 3dprint Project

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/01/2016 12:03 AM, Amy Winston wrote:
> Another formality ...
> 
> RFC email for the 3dprint Project.The purpose of this project is
> to maintain 3dprint related packages, taking over the place of the
> former 3dprint herd.
> 
> https://wiki.gentoo.org/wiki/Project:3dprint
> 
> 
> 
> 

Glad to see it, even if your email is in the same style as my email
from earlier. :)

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWhgk9AAoJEBzZQR2yrxj7w7EP/iDQQpmlM8Tdmv/stl86WQg6
9wwanklQ+LK2xsjlI1F/e+kbnNBGxpqWh+ZYyW2dydqrwHPVeTGNtKiVMmali1nM
kJc7ow/pNdDPIgLKf7unxPGeRRdFC0t2AOFyyOYCG4D6krBzKRXhFYOA0VICW5a1
/V3kaeOdMs8I709fzSlYRuk48DwPAwO43rFUiS/jjiD3oCVqzELjNSbgHrHwrMIE
xLTfxjte81fnFg6rg/s1se1/YEbznbg2bbl3XZuHRqkgX4WNqZXvuG7iWWYcEyIk
ZtnYWNClzxIxYhf73nyNfHwc8aP/Bm/AG/V//Gk6n5pU/Ufx9t9R1vzhZLIRxmfT
6Cp2Gu4cbiw07cKne/WK3BIKecXzvthwnybGA7fwul7IXR8YJ+EY67799w61CTia
5ZxAzKMmvZWeVCs+/4yaHafDwMbYsJCCx6wiiSX60evkvarTulDalX5uh27GC+2D
USIcR/OkQBNbLBqyckEKk/RTjTUDzzitTKG8LgV476+HW2APIjUOGEHMKGoNs3X8
sRkVDzz6VFJmZOUcq7/mI3Z7hYVtRhTFu1G9ezfL/uWTQxZlBY8LHPZwW+yOFyBO
7UKS4p8sYqNu0/r6lc+ra/8klpPcPVmysjot3w2z7jC68iVTU2tw8O0+XVjtviYz
aaShhRcpt6utAFGyeA60
=Anaq
-END PGP SIGNATURE-

Re: [gentoo-portage-dev] [PATCH] Add .git dir to excluded dirs in default PORTAGE_RSYNC_OPTS

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

My apologies for the ambiguity.  I didn't realize there was a bug on
bugzilla regarding the original incident.
https://bugs.gentoo.org/show_bug.cgi?id=567074
The .git directory was pushed out over rsync, portage refused to sync
via rsync once it had a .git dir, and so rsync was broken for users for
a period of time.  So this is effectively a user-side remeditation to
reinforce the already taken server-side remediation.

On Mon, 14 Dec 2015 14:15:08 +0100
Alexander Berntsen <berna...@gentoo.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 14/12/15 04:08, NP-Hardass wrote:
> > like those that we recently experienced.  
> I don't know what this is in reference too, so it should be explained
> better.
> 
> I have no real objects on the patch, but defer the ACK to Brian. Could
> you have a look, please?
> - -- 
> Alexander
> berna...@gentoo.org
> https://secure.plaimi.net/~alexander
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQIcBAEBCgAGBQJWbsDbAAoJENQqWdRUGk8BgygP/39NehkpCmrQ2iMPkmkZS2Le
> HS81r1PoCoklIdlOtwzjNT7G1Tw2UCCxaE4BLXw8Mh56OroESHc4DOKNKfFwE/TZ
> Oeesz3sxMrKdqbM3q60HM6nKoeJYB0XOcBkOJ1chuMUB509BCRDwAraEnS2QtA9/
> athwFcMIuGx8nO4wYQTxFSeeoNKewbi7jA+SnPXjtrLaSRvlL/KS8HBrWqtWAsUt
> tXUyZhSRGA/cIfIGPuIGQonhc9H/n1Wh9HmqtmiK/A0UoNC0yA6JToVCbC7KUT7O
> Hf52lkWfU+MW3T5IThFKOMjUQRacK85onW51ux0hOxelkOn+l8acyReizfz1E+uj
> rYGwmGnb5ytV42PmX7XjmMPXWezO/KnTzOuqZ7+OSPzu4wazYLjFr7Wg1szAzJa8
> y/SjDtnH1gZ0OGeGDBbWLdw8vlb9NqzeQGXzLL1ZSqvmo5ZgQCRA+StCi6B4iNWD
> +G3hATa9x20aHZJRoMMGqzutY/mHta2zWrBBsFpH10MuULS1wkQrqWCJKWDa0Bdo
> 9BQF0SFvvFiDp2EeT4KbOynYYqrliyhFa+FhiSbA56tHTtWVor+wmHzHO25lazAQ
> 5Rni+ZVUNbRaukkRJ3hmVQa1f9osnHazGX3C6MQaqw3m/3DlGWOCt3CuN34R88lO
> Q7lAJhbYs8ZgSPb4xcQX
> =QPRz
> -END PGP SIGNATURE-
> 



- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWbuXcAAoJEBzZQR2yrxj7hA4QALKXniqx4Va0YnBJizZn36D9
MJZbj9qsldrO/9/n4Vnrxnbk1cAAXl9XQJgjDI8b/CYVoS5H7BAW8ZnFlbrgfAYd
0a+IWeHixhpuHwqiRoxv9nS8wB3pUh/hV7ICzzIIdy7GznwmluoIm0AonAhlmXGR
qq5M6HmcJmz/bWKrI6GbaxCU1FaNdH0rhgTwEmwqZizTzEpbPtvCa7hezC5rQayQ
GJYnd6xRUTekx06/s9h7JGxDnbUkZ/IwSgUNS8mtoO6tl8QMsgHOK4QZwtQG/pdQ
h8QAOtl9HWkvRS6kr1ex5FfMi/M0V/iQuy5+lWiUuMQqi/UwLljDbtr9m1O9uxur
gcRK71WauUbRCwltUf2m3f8U90FqlvfcQ9ngex5FkP09iSD66XHpaRL4zByZuk5r
RvC1dFwo3X+TsolKpzlztYvKnCd5ap2Enb5jf5W83pEgxUtd6hRcAjK80vpn+ODq
YGlIMX3cvmW3MRmcoKbTeCqn3XN8OXLNZaEXWxyTU/b5lRXnzpUwxr6It0GK+bY3
yzPWV2TKtS3KHgsgFoC3IYtRfQpCs4pBVoKMGpKFLhDqss+1gpm3UQkeKwAlFcec
L0Fv3UpRc7De2FhX0qXPIuzINoHT6I8DPW32VAChH/Lk6jLju+//y7pX3Nv4mtof
dh5wtaiF7/PnOxVwxZ95
=ahBl
-END PGP SIGNATURE-

[gentoo-portage-dev] [PATCH] Add .git dir to excluded dirs in default PORTAGE_RSYNC_OPTS

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Based off of git master at Mon Dec 14 02:36:31 UTC 2015, commit
7cbd04cd62c8f13ed41e07ff8bc9b7e5d5ac700b


- - From b49fba5c16a931d3ab041446dd8aeba4d2403260 Mon Sep 17 00:00:00 2001
From: NP-Hardass <np-hard...@gentoo.org>
Date: Sun, 13 Dec 2015 21:20:39 -0500
Subject: [PATCH] Add .git dir to excluded dirs in default PORTAGE_RSYNC_OPTS

Adding the .git dir to the default exclude dirs should have no ill side
effects as rsync is not allowed when .git dirs are present and should,
on the user's side prevent future potential sync issues like those that
we recently experienced.
- - ---
 cnf/make.globals | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cnf/make.globals b/cnf/make.globals
index 82d8cc1..836bb5c 100644
- - --- a/cnf/make.globals
+++ b/cnf/make.globals
@@ -92,7 +92,7 @@ PORTAGE_RSYNC_RETRIES="-1"
 # Number of seconds rsync will wait before timing out.
 #RSYNC_TIMEOUT="180"
 
- - -PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times 
--omit-dir-times --compress --force --whole-file --delete --stats 
--human-readable --timeout=180 --exclude=/distfiles --exclude=/local 
--exclude=/packages"
+PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times 
--omit-dir-times --compress --force --whole-file --delete --stats 
--human-readable --timeout=180 --exclude=/distfiles --exclude=/local 
--exclude=/packages --exclude=/.git"
 
 # The number of days after the last `emerge --sync` that a warning
 # message should be produced.
- - -- 
2.6.4


- - -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWbjLHAAoJEBzZQR2yrxj7/v0P/3NAxycwWB+EyLmTRTJI3whL
VLlN+oW3Pvw+PInnv23o/cMlfH3i8wNgi6syaWj+z6guasN0vC3pGJ9XCTo7SJW5
BKUEL8tzbQFa8W5k0nK9IkCOrEvqartBep9KLu8vj2SUQ4xRcEWk/uBksczJ+13g
CzP3kDdJmKGWZHER8+viwQ6tVNKxJW41SwQG5pz4emfADyceQnu/iy9SlRk8PsOD
LfHbuoZTv6YejuA8sDj09vRiNGfEwjuDTqBvjUziHdDg8J9is+vtmj04dqf05ZBR
PrEpoPo5FulGMzQjfF7dgyTpzM5pHBkxvPwM2U3HupnV1H5xixpXkNMEYQ6V3zK+
Max5LbOpzMzHdAx7+gYSRHC4pUa6FTy9lvEqgBfgDG7niq82HADltEruoFT0PRzX
ggRqxGJtRStrwHJDBGRNGdmOelmzI5FCC1497GdlOIvRdiRxvmIdlConVvWD5cii
FbaZsTxrV36NRUXCvR8G9hHLjJUPAjXMU3Ri+huCn0KjDN705envnBhF0LbJ3bvj
jRA/5KDLJcwPMOneEMp5Vb4SQJtC7n3OG1oxaqdQoZ4pu61i0LVdoEe5JpuHtKkM
g0PL7S+J8AA1eBTIlcYnsuwDt1QeAPq5eyHnQfBwF2ptKmRjNz3dPf4VNzM+ZYcW
xZDbhRKNifiWTq6Ee0Ee
=1vMD
-END PGP SIGNATURE-
From b49fba5c16a931d3ab041446dd8aeba4d2403260 Mon Sep 17 00:00:00 2001
From: NP-Hardass <np-hard...@gentoo.org>
Date: Sun, 13 Dec 2015 21:20:39 -0500
Subject: [PATCH] Add .git dir to excluded dirs in default PORTAGE_RSYNC_OPTS

Adding the .git dir to the default exclude dirs should have no ill side
effects as rsync is not allowed when .git dirs are present and should,
on the user's side prevent future potential sync issues like those that
we recently experienced.
---
 cnf/make.globals | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cnf/make.globals b/cnf/make.globals
index 82d8cc1..836bb5c 100644
--- a/cnf/make.globals
+++ b/cnf/make.globals
@@ -92,7 +92,7 @@ PORTAGE_RSYNC_RETRIES="-1"
 # Number of seconds rsync will wait before timing out.
 #RSYNC_TIMEOUT="180"
 
-PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
+PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
 
 # The number of days after the last `emerge --sync` that a warning
 # message should be produced.
-- 
2.6.4

Re: [gentoo-dev] [EAPI 7] The future goals for PORTDIR, ECLASSDIR and... LICENSEDIR?

[NP-Hardass]

;[2]:https://bugs.gentoo.org/show_bug.cgi?id=341653
>[3]:https://bugs.gentoo.org/show_bug.cgi?id=566402
>[4]:https://bugs.gentoo.org/show_bug.cgi?id=566416
>[5]:https://bugs.gentoo.org/show_bug.cgi?id=373351
>[6]:https://bugs.gentoo.org/show_bug.cgi?id=566424
>[7]:https://bugs.gentoo.org/show_bug.cgi?id=373349
>[8]:https://bugs.gentoo.org/show_bug.cgi?id=416739
>
>-- 
>Best regards,
>Michał Górny
><http://dev.gentoo.org/~mgorny/>

-- 
NP-Hardass

Re: [gentoo-dev] EAPI 6 portage is out!

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 17 Nov 2015 23:09:34 +0100
Michał Górny <mgo...@gentoo.org> wrote:

> Fellow Developers!
> 
> I have the pleasure to announce that portage-2.2.25 has just been
> committed and it comes with complete EAPI 6 support. This effectively
> means that from this moment forward Gentoo developers are permitted to
> commit EAPI 6 ebuilds to ~arch.
> 
> Some quick notes:
> 
> 1. Remember that you can't stabilize ebuilds using EAPI 6. Therefore,
> if you go for EAPI 6, you ebuild may be forced to stay ~arch for quite
> a while.
> 
> 2. The Portage implementation needs more testing and can be buggy.
> Write ebuilds according to the spec, not Portage behavior or they will
> fail.
> 
> 2a. It just occurred to me that Portage does not fail when eapply_user
> is not called. This is a bug, so make sure to call it or
> default_src_prepare.
> 
> 3. EAPI 6 is not a drop-in replacement for EAPI 5. Study it to use it
> efficiently. Use it as an opportunity to improve the API of your
> eclasses.
> 
> 4. I've written an extensive guide [1] with some explanations
> and rationale for many of the features. Consider it a must-read.
> 
> 4a. We need someone to update the devmanual.
> 
> [1]:https://blogs.gentoo.org/mgorny/2015/11/13/the-ultimate-guide-to-eapi-6/
> 

I just read your guide.   What's the recommended manner to upgrade an
ebuild from the autotools-utils eclass?  General advice would be
preferred, but I'm specifically looking at app-emulation/wine.

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWS9JkAAoJEBzZQR2yrxj7ckQQAIUSzSkOOv+b6ukMkx4xtTCV
DsjanXXgRy68zKxhLAWn03j6qWXiM2KYaTD6Mnj8anV63+NjfL46Yke9GHZTtjGu
tP1du8fmD1e0RNk0XjetaacEY00LU6EqxmRlFn0SmeGCFraCew5mrkTJToKFhDA8
95Oab1hvvfrZzLVnZC5AW+YEeJySfCaHRFrvqC3o8fLvbeun+d3sN7n/i5PYvIed
1VnJkW2cuLixcLgJTxXJ4E4/xUcJpL7kCwPh0IJABir3EgtCIgqLnVD2TUPPDjAd
mOogB+v1f3D5hZk7w+tLbQ8OY2OpCbOk6h/0JiWvAWnOqC8JYkOxxAUgWPfWgIFr
5pRsMSfZO1N0D3VxB71PIfgAsPp8PKv8sLdlJWJkGhHFm7M0zyQ6ElpbRgFq0Xx6
awWYDFpVp8qdXN1zkxD14S68WHPGaD5QCJAnIbL9XMFY+03GQuJJxI66vJjpBCo+
3Q/skdDX/TGhj/M+jehB50IsSHiIstsiXpLtdew9htf89pkJZkt6A4KYd4/M9YC3
C7HX5np2pZgTSc/N2J6/0AST0k0n7l+PseDAyKWMO0ShdMv+oKtxmaW51qIupVoJ
e4ybFLsQd0h3KdP5e6YmOtWv0AYaMczChcFlqLHLWUrAxD622PsESqLX8qigTC1W
65FwvabVNa+WgDgxhzNC
=pWAw
-END PGP SIGNATURE-

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

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 12 Oct 2015 23:49:11 +0200
"Andreas K. Huettel"  wrote:

> There seems to be some general confusion about specific package SLOTs
> and their meaning, since there can be several naming schemes applied
> and documentation is either non-existent or is inside the ebuild via
> comments.
> Because of that it should be part of metadata.xml.
> 
> An example use case for media-libs/libpng would be:
> 
> For building against. This is the only slot
> that provides headers and command line tools.
> For binary compatibility, provides
> libpng12.so.0. For binary compatibility,
> provides libpng15.so.15. Represent ABI compatibility
> for libpng.so. 
> 
> For packages like x11-libs/wxGTK one could write:
> 
> Major versions.
> 
> ---
>  metadata.dtd | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/metadata.dtd b/metadata.dtd
> index ff2649c..4b29f3b 100644
> --- a/metadata.dtd
> +++ b/metadata.dtd
> @@ -5,7 +5,7 @@
>  
>  
>  
> - ( (herd|maintainer|natural-name|longdescription|use|upstream)* )>
> + ( (herd|maintainer|natural-name|longdescription|slots|use|upstream)*
> )>   @@ -20,6 +20,15 @@
>
>
>  
> +  
> +  
> +
> +
> +  
> +  
> +
> +
> +
>
> @@ -79,6 +88,7 @@
>language "C" or "en", which is equivalent -->
>
>
> +  
>
>  
>  

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

[NP-Hardass]

erring to, but between the sheer
quantity (flooding) and the way I perceived some of the messages to be
formulated, it all seemed rather abrasive in nature.  Of course this
was my own viewpoint on how things appeared, and I can't say whether
that is what Ian or others perceived as well.

Obviously, the goal of the project, which is an admirable one, is to
provide reviews of commits and improve the quality of submissions both
current and future.  It's my opinion that the means under which it has
proceeded thus far undermine the end goal.  I'd love to see commentary
on commits, but I am not sure that I think that the gentoo-dev list is
appropriate.  I'd much rather see it happen on the gentoo-commits list.

Additionally, as mentioned by many others in this thread on all sides
of the issue, the goal is to provide feedback and improve both
users(whether they be end users or developers) and their submissions.
I'd just like to state that those providing feedback should be mindful
that how they provide that feedback is sometimes as important as the
feedback itself.  I think care should be taken to be as friendly and
approachable as possible.  Though some might disagree, I agree with the
saying "you can catch more flies with honey than vinegar."

Just my two cents of course.  Hopefully it'll help guide this new
project toward a great future.

--NP-Hardass

Re: [gentoo-dev] symlinks in the tree

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

In my wine-a-holics overlay, I used symlinks.  I found that
occassionally, git would act up and replace the symlink with the linked
file when committing.  I never found out how or why, but for this
reason alone, I highly recommend against it.

Regarding the comment about regular and live versions, I'd also
recommend against this for the simple reason that sometimes something
changes upstream before a release comes out, and it adds an additional
complication of worrying about edits to the live version changing a
versioned ebuild.

- --NP-Hardass

On Sat, 12 Sep 2015 15:12:08 +0200
"Justin Lecher (jlec)" <j...@gentoo.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi,
> 
> I would like to discuss the pro and cons of usage of symlinks in the
> tree, which are possible now as we aren't bound to CVS anymore
> 
> We have quite a number of ebuilds already in the tree defining
> functionality for both, regular version and live versions. These are
> typical candidates. Same for different package versions with the same
> ebuild.
> 
> What is your opinion on making heavy use of symlinks here?
> 
> Personally I would ban symlinks and duplicated code. One ebuild for
> one version. And in case you like to propagate changes over several
> ebuilds, just use tools like meld.
> 
> A drawback is that tools like sed break symlinks and write back a
> plain files.
> 
> And last, we have potential breakages if people don't give enough care
> when doing stabilizations and removal of version.
> 
> nevertheless, we would slim the tree and reduce work when changing
> things like HOMEPAGE.
> 
> So please discuss this matter.
> 
> Justin
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0
> 
> iQJ8BAEBCgBmBQJV9CSoXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
> OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiIZ0P/0q6jSuGZzZ4lDiu87GIYMiC
> ndRzHsR/OGT9paB01pkoQogOt9+AMKdNd434n2to+HbuNf7Le5cWP7MBAdD/ydzV
> H+5zE98Mu9h8IXTRvuxv6eTSRPFsnnDPuMAS+28D7WwDBcmOhl4we/hRyfq0+JFw
> s5XojNlrk7YZLynZs8SHcgqq5CbaKbjLMsVSTnVXKeA1NcaB0lPFjI0JraCqW4xS
> BgIA2MrrR5XM2imvmBInanwJZ+VOVvHD1jxTlfUQeF7qJusTY5fTnVncvnIo72Fh
> E2Rz/+vrWFe+CvQV63IpgbtC2oYP5OMidnfZSQynRbGsK9w3rm25cXOlyXjLA98O
> sv/wNHvVk3+SIvIviN3yDjOOG5q1zeW33UtZfz5iKu3E7dUGw6B2a/qjC9m9lIQH
> GGDu7csYnW8aSLiEJPGsJsduTqw/+G5p8DWMGuHss6xu6DyZKJPRxgd4VlDkLIiE
> ZCgoHCGhQX3LDEOlzh7+j01A1AOO4SfTZqqDch8f6jiLYmx0dw4Rcz6Lth+cAzn+
> fjTdq8A1P5umV8NiwGZtx8GtPoEWRpEV0zuhZHWXjvFSIxpn2TBUi+pETo421wXH
> 9QDQD5Q/9Wf/Wckyb86+OEhwBGoPXib2sF1BOTWONXHECvQ5xuqXy2Ux34HJHbou
> Que3NfC4OiQKXSJv1jae
> =K93a
> -END PGP SIGNATURE-
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV9PKMAAoJEBzZQR2yrxj7498P/3ITnQ3Ji8MaPGbv3AWK52SN
hccXU3Bjyq7I/A+1H/ZYzmBRtLkANczeCcqOBQTIr2p7s3lFfnvRVAfrpyRsmo1s
ix9Pmf/9ixDZ+dHUxliARiYNZHWNtisxCF5ehmo8+q/F5efLslrjKNf81X9xDpaL
Haz5ywWUfVRXWZwWjgc5dSLfqauPYZSE9B3NzOgjKnRT9OeYT/5dMHf6rgkPi2jT
O2NeYI2zKL93hspxM4ot1QBhlmKAw2ArjDMoV5UkjpvKa/4FKXu8h34dgwZH0AYJ
2WlIMXREUt1iR+FYQ+hUEzOsEO7HgSlz7wfn0Z7SJUFObhXTzIlMLjm5wbVbjsVx
rzz/XEXJlU8OFjy5h2MfoFWn0I46ysgFtie7OaRl/Rq3jqLg6irLAmwgiqJbLgCa
qcwUt3EhbWqSr5NlHdxCHfjnOwYsTrd+cX0FEhMNW2pFO8oBXa4Xz+x4PiZAz07M
RyRftQucd2JbY+TE2nS51HzJYN8157ZkPJ1SnNN38Nftd0oD0XJ9UmeYhO45Gc6W
wRpX75af1dUhgs3nh6CpnYCXuWe8Aa08vf2WWTpw72QdcurI3cSrYcjScDXbF4Yw
hthsaaP+rwDCFacFdY24Rglg01Q45mWq23mylVwnmMUtG3qvE0Nhu3ZIBtqx+j5O
gsujfaXNV5U/jsnCWDMf
=8n1u
-END PGP SIGNATURE-

Re: [gentoo-dev] useflag policies

[NP-Hardass]

^^ has the pleasant side effect of being easier to read, as a user. The user 
receives a message saying at-most-one-of instead of some convoluted other 
expression that they don't understand. 

I am all for the use of ^^ add the default for this reason.

Additionally, ?? has the same effect of being easy to understand as the 
description in the error message is in plain English.

--
NP-Hardass

On August 2, 2015 12:34:51 PM EDT, Ben de Groot yng...@gentoo.org wrote:
Recently some team members of the Qt project have adopted these ebuild
policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies

I have an issue with the policy adopted under Requires one of two Qt
versions. In my opinion, in the case where a package offers a choice
between qt4 or qt5, we should express this in explicit useflags and a
REQUIRED_USE=^^ ( qt4 qt5 ). This offers the user the clearest
choice.

Other developers state that users are not interested in such
implementation
details, or that forced choice through REQUIRED_USE is too much of a
hassle. This results in current ebuilds such as quassel to not make it
clear that qt4 is an option.

This goes against the principle of least surprise, as well as against
QA
recommendations. I would like to hear specifically from QA about how we
should proceed, but comments from the wider developer community are
also
welcome.

-- 
Cheers,

Ben | yngwin
Gentoo developer

-- 
NP-Hardass

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

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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
 
 
 

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

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.

- --
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVqqqhAAoJEBzZQR2yrxj7sAMP/3SJK47oukM/sNMiq7X4Wwv9
h7iZka4bDjUBH95FupbkMTAY25Vyyt+SqXlUEBXTohT3LNPelPvBd9ZRJyOTld8k
ewwv+CQfxhG+NTPE4ca0nGV2W0W7ADv1j4T5sauyjfjbHd3c5sPk2q5nad/Wlve7
WEIJyNi0Vyo/wiC531BIDXWcKVrYoC+K1q/Fy94cbv96pxzfnAR47m56k9qfm+P3
B3oBEFR87Yt9GQxTiWEpR3JtrXMLLhMQf3uel0P4muNuKZh0FNV+ySOAdmzeNr3a
1RatQQeJ1D9ogYjZlEfz02JX5SO/7JIZK8VG/pdqzMaLPCcgxl3PQyUvXnbxayzf
mmY1H7MHF7wSKJiQ4hv4RdjYt1ni3fB1nlW6mHI77ytOKpjFqBlv56QTvuPdsL1M
uDg/30sZcrPpoLdlpbsmpZPBhTmL+rRa2HjmTO6vJdIAI6pH3THu4LuCW31syau1
LGLVgxqVkX2bQM+twRD+WscBiZHRyzT2Px0+o55QS7gBNes8IhpWduMIF6RXa85S
wuxK4Pz/TRXT8xPsYRtTJasYeCCNjNp57Hb6r1v0Q85CehzbYbznPOlOVHTdCm58
p0aRxFsTZFOcYz/bdoNaQKrAG6AF7253LoIftRtZVMbu8iYFJqO+4sezC6Xd+wmW
lg82A0tpzPagqGJ2c0m3
=8+ux
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] News item about mysql client and server packages

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/17/2015 01:56 PM, Brian Evans wrote:
 Title: MySQL client libraries and server packaging changes Author:
 Brian Evans grkni...@gentoo.org Content-Type: text/plain Posted:
 2015-07-17 Revision: 1 News-Item-Format: 1.0 Display-If-Installed:
 virtual/mysql
 
 The future of the mysql packages is changing.
 
 First off, a new virtual is being introduced,
 virtual/libmysqlclient. virtual/mysql will represent the server and
 tools while virtual/libmysqlclient will represent the shared and
 static libraries.
 
 Developers and ebuild writers should reference
 virtual/libmysqlclient when linking against the libraries as the
 package will keep the subslot the same as the soversion for easy
 rebuilds.  This is getting more difficult in the current virtual
 situation as MySQL and MariaDB start to diverge versions and
 features.  The old method could force users to mask new versions or
 delay the posting of one server package which advances the
 soversion until the others catch up.
 
 As for the server packages themselves, the minimal USE is being 
 replaced. The new USE flags are client-libs, +server, and +tools. 
 The server and tools flags are on by default to signify the
 primary purpose of those builds.
 
 The primary provider for libraries will be a new package 
 dev-db/mysql-connector-c.  A tinderbox run did not turn up any
 issues, but packagers are permitted to block any provider of 
 virtual/libmysqlclient that does not work correctly.  A comment in
 the ebuild would be helpful to track this.  The server packages can
 still provide libraries if the client-libs USE is enabled.
 

It's my understanding that news items are geared to end users,
however, this may be incorrect.  Assuming that is the case, apart from
notifying the users about the USE flag changes, the bulk of this news
item is geared toward devs and package maintainers.  As such, I feel
like the user relevant content might go unnoticed as they skim and see
it is primarily maintainer related.

Apologies for the weird mail issue.  I got rid of the cron plugin, but
it is still acting up, so I'm switching back to claws mail from
thunderbird.

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJVqUO4AAoJEBzZQR2yrxj7KxEP/jJgo0HPs3t3cTaThswt8/eV
gJGWyaelKeQNQ34QrI4YxnLsZgQHNdAqo0qsbvpxKMNW1wZUHIhfZH4g562h8sJi
7eUilmn1TZdbQu/gOqV3Z3AECpyxc/SVZMTkOdfbBrDkoAmZpNYp1Jmr+rx01THs
ZqmXcD+JkO3p6KOAXbnU2v5Gv74AKLXCwaKslUf9ewMH2iYcDnSivo4nmfNZCAsi
t7bYYpEjb0Y2pjUDwAYyELsGABRN2nSircYiXVeGxpnuYJF3/0xLySrPAWEySPHE
ucMaCB5fnz/vpSVzRciAQhFb0w/y1zHBlGa82aYPRl++cmaw53HvF88TfmAzRdJ6
iD9BdER1KpM1wERUhypstENmAxvLYxHdT7P/+vId+D5cFmIiN1N9JM61yg/4A2+Q
ScGeQuCZkme+qqvvybD4KjVsP9fN+Oj2kMhKpLsVbnmLbxbM+rnAkgChxbEy3wzf
Z0HM0HviwKSWqjN7E9Eanc2UKYpuujODd8/++cvnVRkrGJqjfDO39Pgi4nSVoCis
+QzsFhr5Mi0k96naBNY5fFgDoSvFy/qJyN62NJEL0dFo4UxhJ4j7ul72+viQsGD9
eIuopVZVHSm4qnwkUwrwUdln9HRMSKI4t5iWOZZBxbTjBEyzc98Kv3fLFmN394SZ
mmqkBb2xkQPtS6cnU/eR
=xZEh
-END PGP SIGNATURE-

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

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/16/2015 09:25 PM, Kent Fredric wrote:
 On 17 July 2015 at 13:13, NP-Hardass np-hard...@gentoo.org
 wrote:
 Additionally, I feel that a signature is a means of acknowledging
 that a package has been looked over, and that developer has
 stated that they approve of the existing state
 
 
 That much is somewhat implied by a developer owning a commit.
 Because in git, single commits span multiple files.
 
 There's GIT_COMMITER and GIT_AUTHOR values in every commit.
 
 And a Signature is a digital proof that  Joe Bloggs didn't forge
 a commit, label it NP-Hardass and push it on to some server
 pretending to be NP-Hardass.
 
 It might sound like a rubber stamping, but its no more rubber
 stamped than our current workflow where signature generation is
 automatic and having a signed manifest doesn't in fact mean it
 *has* been looked at, its only signing who touched it last.
 
 For NSA to break a Manifest, they'd need to update an entry and
 resign it, and then we could later work out who signed what
 manifests if we had any problem
 

Yeah, I understand that a signed manifest doesn't mean it's been
looked at.  My logic was that signing and keys is pretty prolific at
this point, so a signed manifest implied the package has been touched
(and hopefully looked at) by a dev more recently, and those that
aren't signed probably haven't been touched in a longer amount of time.

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJVqHLQAAoJEBzZQR2yrxj7a7YQAIlHbIcNl2FVwNOGR5ERegc+
RlqmOheNx654aM02Hcd44asTuug9Zy6cJ5k/LSGJEiqupg6EaDS7jnQAfqu+k6Lg
6JSPnfD0qUr5nrwNDvhUEH5LfVNHsKqCN9XyWvdy3Z0l+vKnyoWVCrINrTMEGCAf
IkVnuAXXzo83YnJwtcczxbXsLfMpvnJK12Au9sa0H75y01Vqxw6gWvQeEww/fUl4
7L3WQCiGJnW5tI7vMVhDq9vpYFaB+VIQekLge3nf5sx6PfDBS4XHqwnUHD/wnj+i
nqvjMDuyVfbc4NkDh9gW9Nk994VGu/iFBgepwT54khcuYnIVGVnad1Br69yLosDU
5DGUff1UKCQDjl8Cv88yuCf8y7zTjema3Rg09T0XqsmBWuhacw2zqESplPdlYsNj
NfDCpcpr71tCP7qhy6y05O58p/ZKQDTp66OeoCghEEiYN89jjIGqT5tdWenDXJ3a
j+MewMSzampvy5LTg3T0rQvirlq9rC1EXxQ+NmqXkVw2EK64HzcjM+kVyevvYuCK
2wiqEA4MAodd1LcW2gCNJ/nQ765OQjtMasEb8H/W9DryayzDLICUc3QdENXB5dMb
x7bS+Ft4TbE/xXyR28MhkYXHO50qeWzlLRjueS9bSdoEPbTfe62JNBv8GvyFFxS4
aYvU5QXAjHeXSECERZdU
=tWk3
-END PGP SIGNATURE-

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

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/16/2015 09:25 PM, Brian Dolbec wrote:
 On Thu, 16 Jul 2015 21:13:09 -0400 NP-Hardass
 np-hard...@gentoo.org wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 Not sure if this has been covered in some of the rather long
 chains of late, but I was thinking about GPG signing, and how the
 proposed workflow requires every developer to sign their commits.
 Currently, it's advised that every manifest be signed.  As far as
 I know, there are a number that are not.  When a manifest is
 signed, the author is saving a state, and providing a means to
 check it has not changed.
 
 Additionally, I feel that a signature is a means of acknowledging
 that a package has been looked over, and that developer has
 stated that they approve of the existing state.  I'm not sure if
 others agree with that sentiment, but if anyone does, my question
 is, how does the conversion process to git handle these packages,
 where the manifests are not signed.  Is there an intention to
 blanket cover all packages when we switch to git?  Will these
 packages be copied over directly and still maintain their
 unsigned manifest (I think this is unlikely as I read that there
 would be a switch to thin manifests, requiring regeneration)? If
 the community doesn't view the signature of the manifest as I
 just described, then a blanket signing would be fine.
 
 Would appreciate your thoughts either way, as I could be
 overthinking the issue :P
 
 - -- NP-Hardass
 
 
 No, with the git working tree, we will switch to thin manifests and
 the entire commit will be signed.  Not only that, but the push to
 the main server will also be signed (a push may contain commits
 signed by a different person that the person pushing).
 
 For the regular rsync tree, Full manifests will be regenerated as 
 needed and signed by a common infra supplied gpg key.  So for
 general users, it will be easy to verify without having all gentoo
 devs gpg keys.  That will be different for users of the git tree.
 
 
 

Ah ha. so, with thin manifests, we as devs don't sign the manifest, me
sign the commit.

The infra key for the user facing tree makes sense.  Thanks for
filling me in.  So, will infra  be using that key to do the initial
commit to the repo?

Are there plans to the make the repo, w/ metadata and signed by infra,
available to end users as a rsync alternative?

And my apologies to all for the multiple messages.  My cron plugin for
my email client is wonking.

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJVqHEbAAoJEBzZQR2yrxj7jVMQALWoMkXzxapjYlBaGtOk5eyd
XQQuWH6m4U+9DrzQRJEeaCivIJmzXHPAVU6Rd40gBGqlSTMoJKm2pIMkxGvDLLd7
zIwuPolamQhFM0vhkUOidfgBqvCbFJV5rFTKtIPXg28JivoY7omi4/oANd0V8L7A
YRik152d2cFW+rdITLhgf3JNky99yOy4NR3SYB/dQY+E8D+5RaCXjy/EqjNqbsin
To+/far3d5e2/Z7dDlfyuhYyG6dwbFl8vY7RN+eERH68GTqj2bjy2EL0T9FAVwWI
O9i4T1sRIneYVfd3MEoLwkPHjhfDOmP/zLloFaqT9AUtiVlVf9vMy5dKXHva1OTe
cmNicf66YBsSD2J6mMRHE4N7iTn8tpI5W7+WpXa2gyEeqWwDwbENxNU1IHlZ0Ys7
cHpfhkx63oWwvDQX3XKjl1fUjoVEoJ/6HhHNWboLaAxJ/XUcZCAGNEaF9NVtE0FN
VUFmU7ZU1GLkk+MAKxpwdMqa9+LJ+Sr+4/NzF1ceE54yoq0ks+PfafyMybseOptK
bKbiAQ4/GvDB3Tpw4S2QuqYZ3pT/enxYET3v8YxVPE6Hw79RYeaMtEEnm0Niy29k
CHUT6T0Ul3IfS6LQZtEwC40Izs/usM+HH2XuYP3OfkBLgK8LUhEUcVNiC6B6frUD
M6d04xGeSvDVMo9vBoYb
=Fufx
-END PGP SIGNATURE-

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

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Not sure if this has been covered in some of the rather long chains of
late, but I was thinking about GPG signing, and how the proposed
workflow requires every developer to sign their commits.  Currently,
it's advised that every manifest be signed.  As far as I know, there
are a number that are not.  When a manifest is signed, the author is
saving a state, and providing a means to check it has not changed.

Additionally, I feel that a signature is a means of acknowledging that
a package has been looked over, and that developer has stated that
they approve of the existing state.  I'm not sure if others agree with
that sentiment, but if anyone does, my question is, how does the
conversion process to git handle these packages, where the manifests
are not signed.  Is there an intention to blanket cover all packages
when we switch to git?  Will these packages be copied over directly
and still maintain their unsigned manifest (I think this is unlikely
as I read that there would be a switch to thin manifests, requiring
regeneration)? If the community doesn't view the signature of the
manifest as I just described, then a blanket signing would be fine.

Would appreciate your thoughts either way, as I could be overthinking
the issue :P

- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJVqFalAAoJEBzZQR2yrxj7g3YP/3HkK57mPQp2xzcpwUlPHXkM
NAXaxO9UBRp2fNFc78Ja//xa8OUL0IDhsjI69uw2QRFILkgOjLo5n91d+KHuXFBc
y8BGJ9lkhYgyCy+uztYsKJwUnfINfURv/hFTKPemgO8FVhBHUqyP7Mbz9cck/92p
M+Wh12SrMqbTVRAc9ev5aho5hX2WG9fI0ikmX9WqkXo6UuQbc02VD4FdpkYaDhp4
ZzdpwUUGexMgZHgUahLCYTi0WbCCenUFupxGVfYYN7xTz539zbtER2LepfN6vGTw
H/mELsg5fU7GbB7LM7XhDyLBgXcwc3zg5L9bRdbWIEVH/YpOaL0ttSX6MLEc3g7/
26aotDjVGNJYcCcM+/GLSv761/MV9FdDe/ZfQSsY51rd1Uv9MjKLnfZf4MjqZ5x6
Fj2Jj7HvdfLdC+MmVNMzXWpkGpyZHoCcy+aES+dBweX3Qhcow4vtj+IKUKRu7R7l
toBWPe9vFNYdlb2ODphyD3lLyGcTElBOf/K6UBcv9lDrg0L5g4spOpMJ7PK1uCh5
nonkYAP+Rs4+hyWBlre9jqhH/SZFw7EioBVEXahiUvGExKgZHB33AzS74a+8AUqo
knHec0KafArlnE0TS71ZaPhrzWZbMSxiynacZAtT20VrKLsbunRuvTGEmoNZawy4
FMPMLKTKFQkI/Ps2K7Oa
=0QTd
-END PGP SIGNATURE-

Re: [gentoo-dev] Git workflow

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 05 Jul 2015 21:35:23 +0200
hasufell hasuf...@gentoo.org wrote:
 https://wiki.gentoo.org/wiki/Gentoo_git_workflow#naming_convention
 

Ah ha!  I must have missed that the last time that I read that wiki
article.  Thanks for the link hasufell.

- --
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVmYgOAAoJEBzZQR2yrxj7DJYP/0Bj9eyo1zKRewCfV/VheHi4
ECMTkw0aVsYWCAELfTOZnUh8+jxE7GoE61DYy4xAgC2YjxI8dQhCKhpiK+8LUePy
0YNk7W8u4szNcj47V7/D7+DTebK7ARLQKwxTekKMNMMUmw9XU1wudjmdv1EPKS4h
kzDDiswz4BFo5Tllb96FTAoh9uD2M1mpj6B0M0y2svxqp/aBDY6hfiDNMdY64QKc
nxkK+Nu7cwaJPJoYyTINVqYrz5W5aaVGTL2EwtL37p+VBfP+K5ygSI3kN/Exo0BP
KkrUP+4JAu3G+g/GJqSgVJGmNiKcLG+DvsaTlJBKrcRDpuN9lJnMn5SV3HoMF1iM
wEScrzdSgoPUsx1v1r+BidQVlRrS7D0T6r/1rWN3mX2F43AvBCztTJn/sEfG6zyf
nRVlckMDKwLof5aeSmPqzpLx6XMqcT5cC+ivehZ9WVgZmfyCh01bNJdf+FsnILrS
6BG3ui61CSbR/0aTTTig0pcoB8Fa0WfzSRFRf1JZsxOewU8OFlx2QNyabi9fUd+n
SyJqxgE77J8ZaFPcha4oXhUMvda8IaKE3ISjqdw4cIVtLxILLFMXYIPDg+NAp01P
dxZNEV81YF0+D5e6ktel1qA/5SlHGJf7iA7oqsqkz9nkBDhNlZ1KYDrDLoBlzTPK
XptZ/bIIeZipRxyQILTX
=rNhp
-END PGP SIGNATURE-

Re: [gentoo-dev] Git workflow

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On July 5, 2015 2:57:14 PM EDT, William Hubbs willi...@gentoo.org
wrote:
If you are working on a topic branch to make your changes, which has
not
been published, just rebase that branch on master, then merge it to
master, and no one knows any different.

William


Speaking of which... Will there be some sort of standard or policy
regarding branch names?

- --
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVmX7KAAoJEBzZQR2yrxj7jJ4P/0DBoOxsAo9PDRXlglylBaPy
QX3LbQVKPs6910FGN7HXNFBHvYSAmbV8twrd0LchCDcjVnx8jZcuBymC1uVvEbpu
A9dCpZTDnnzoSSn8idWkvd8T1Zi5xmON34czPm4G+FvI+vBeJtYS/2cO80e/JvXa
vlpDBW6DKDxhJoBeTzxsdKk5kVFbK0ULSoKl8cx7zp+Q0R498dqDOy07/qJBCDJm
BwUZQNkUSHNy2tBz0yu6r9xJB0Utfso462SEkLVluM7dpM4o2N4ADqo24gzybYPC
x246bDqPhQ8xNQeL4TiTqv+WkdWcZqSP8saOu5l2njQfuW3bL7QIxhHBPJ21uRMn
L4RWpgHm10utnCglp8ZYeVC+CVaa/XS9ZJJEtbD1ftqPSO98yrip/y4j512b0X+h
7awBJk8g1BsZ3Ilwm67R3DqDVAnUBV2hyz84aN7/CzDAgqyh48y7ROSw3i/QkRh4
33c9gol00BGNFL1fc8kj4LdY+D/7WVAG7ysYklf64GVtSCMs2ibIrgfz5myswKgo
2VBQEaAIQTx7wa4mfd3KOL9ry1VQmoRR+vxv9OrExPVp4xU/wTpgkG8mZ1w2TZqv
IJf52JOQ1tJzTDWV/9HmtBuGH8QIG7M48V0mJvhEw0sutkYeKxTDMvVkM0+YaGIB
Or5Qo4Pi1bRcNOleG5c1
=yOlr
-END PGP SIGNATURE-

Re: [gentoo-dev] Git workflow

[NP-Hardass]

On July 4, 2015 2:17:41 PM EDT, C Bergström cbergst...@pathscale.com wrote:
I realize that this is subject to lots of different opinions and that
my input doesn't carry much weight - At least I thought it's a topic
that should be brought up (again?)
-
To start I hate git.. I have used it for years now and the
multitude of ways that are possible to accomplish nearly the same
thing are *annoying* at best.. With that rant out of the way on to the
point..
-
I super don't like merge workflows.

Just a short note, the last time I read the git workflow on the wiki [0], 
rebase of one's commit is suggested with fallback to merge if unable to rebase.

1) merge commits are confusing at best and normal tools don't
display and work with them as you'd always expect

It's a GUI, but dev-util/meld provides a pretty nice interface for git merges.


2) merge commits lead to multiple parents, which breaks a clean and
simple to follow linear history
-

What I personally prefer is a rebase workflow.
The downsides
1) Requires to you rebase before pushing. Which can be slightly more
work than just a lazy resolution of the conflicting merge commit
(depending on if you flatten your commits)

2) May not be the most popular git work-flow.

3) Due to #2 from above - may have detractors and or less people who
are familiar with it.
--
I'm of the mindset that if you're going to keep something under
revision - the history should be clear and clean. Linear is the only
way to fly for that. For those using cvs or svn - that's what they'll
be familiar with and probably expect to find in a git log. You can
start with forcing rebase and keep a clean history - if one day it
proves too problematic  you can switch over to merging - the other
way isn't really possible to do cleanly, depending on your tools..

Thanks for the minute

-- 
NP-Hardass

[0] https://wiki.gentoo.org/wiki/Gentoo_git_workflow

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

[NP-Hardass]

On July 4, 2015 1:49:20 PM EDT, Peter Stuge pe...@stuge.se wrote: 

NP-Hardass wrote:
 I am unfamiliar with how other big projects that use code review
 systems. Do they generally make (almost) everyone participate,

In coreboot, which admittedly isn't such a big project, my impression
is that the introduction of Gerrit has lead to increased
participation. Previously patches and review went across the mailing
list, and many simply filtered the whole list into a folder.


 or do they typically restrict review to a certain class of users?

Hm, why would that end up happening? I'm not saying it can't, just
that I don't understand why it would. What do you have in mind?


//Peter

Well, it was just proposed earlier in the thread that it could be used for 
non-devs (primarily/only), hence two classes of users, those subjected to 
review and those not.

An alternative is a situation where all users, developer and non developer 
alike require review with the review requirements different between the two, 
e.g. devs need one signoff, non devs need two.

Additionally, for certain aspects, a hybrid of those two might be useful. A 
project or herd accepts direct commits to its packages from its members and has 
code review for non members (with the number of signoffs dependent on the 
group/content.

-- 
NP-Hardass

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

[NP-Hardass]

I am unfamiliar with how other big projects that use code review systems. Do 
they generally make (almost) everyone participate, or do they typically 
restrict review to a certain class of users?

--
NP-Hardass

On July 4, 2015 4:14:14 AM EDT, Manuel Rüger mr...@gentoo.org wrote:
On 03.07.2015 22:22, Robin H. Johnson wrote:
 (Breaking the thread, because I believe this topic needs further
 discussion).
 
 On Fri, Jul 03, 2015 at 03:39:31PM +0200, Manuel Rüger wrote:
 Are there still any plans to use a code review system like gerrit
that
 will avoid merges, rebases etc. to the tree by just accepting and
 serializing patches?
 Merges are a fact of life, they will be happening.
 This was included on:
 https://wiki.gentoo.org/wiki/Gentoo_git_workflow
 
 Rebases of already published commits must be avoided.
 
 But beyond that, the general discussion was that a code review system
 was not in the immediate future...
 
 If the merge workflow becomes too problematic due to the high rate of
 change, then we can revisit those systems, to take advantage of their
 auto-merging functionality, but probably only in combination with the
QA
 testsuites.
 

Using a Code Review System and allowing direct commits are not mutually
exclusive.
If infra has got time to set it up, this could be an option in addition
to direct commits for developers and we could make it obligatory (e.g.
for the first month) for new developers.

It would also allow proxied maintainers to commit to the tree more
easily, as it will require just an additional ack by the proxy
maintainer.

Manuel

-- 
NP-Hardass

Re: [gentoo-dev] Git Migration: launch plan schedule (2015/Aug/08-09)

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 3 Jul 2015 11:19:13 -0500
William Hubbs willi...@gentoo.org wrote:

 On Fri, Jul 03, 2015 at 06:34:41AM +, Robin H. Johnson wrote:
  On Thu, Jul 02, 2015 at 09:46:18PM -0400, Brian Evans wrote:
   Does this mean that
   https://wiki.gentoo.org/wiki/Gentoo_git_workflow is no longer
   draft or needs work or another document is meant to display the
   new flow?
  It does cover most of the things needed.
  
  It could use some revision regarding gkeys, and I'd like to also
  mandate signed pushes in addition to signed commits.
 
 A push doesn't create any data, it just uploads it to the repo, so how
 do you sign a push?
 
 William
 

Oh, you said push specifically, instead of commit.  My apologies.  I'm
unaware of a means to do this.  I guess you could theoretically sign
and commit a list of the pushed commit hashes.

- --
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVlrnuAAoJEBzZQR2yrxj73C0P/003J46FmqXNYIk3cVoktvCj
hJ74J9DcAC7ZvqJjAeASdWN83AWlUNFQQeA6eSkmtJXOot7VfrfVw/ZlWReEcq1p
ZMFhUdawTDcfeH5fBx0vJLeLkyWHBIYoMBQchSzQpugEt7X378C1BL4ttrWYpOu1
Z494tvZVvZ9+hN17IT+A3wejsfWkDT2oFECXjZJuZQXR7b3qlUVZJsKAxrpZThBX
ciifiy/84sHRx6fXpU7RtqsYJXLt8dAjppPDH7ci2sh+YjJqL1nj58QZprdlvNc/
R2EupWfphv7sKdN3/yPpT5RWjERKJqYkt15UzZceLEMjhpMxW2b3Rfcz4CE+MXS2
e1/MgvoMoJI7/7x9cg8bykkYa6NmTdQ7nXtqP9s/cADtPho7mllA+FVW7aH8CE46
LG2s0AsIWAV0rR1H+d77O2bhknczlPKgKDEO+sFwy+Y7I/2V37nEkSZR8LqWVmse
RKPmxjimX0iSEUIiaX5LPR48hmkosSvIHkmwO7XIK5NCtIoMOjBXyIenYQi67+fs
PV1+ZgBxWufn1BEDXDQc8TN9IvvRpRvv2O5lKYZ096pLon9ZVB/O0BscGjk7HeL0
JCpZ4fJ6d3o/4xlsmX9n++X1zbdJyMvrHBL6mZa6wcZPMMe1L0w2/zFo8sG8mKpD
Ag/E/1m/6OXzsJCJOAbE
=1FB0
-END PGP SIGNATURE-