t;> 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
fi
> RDEPEND=""
> IUSE="${VIRTUALX_REQUIRED}"
> + [[ ${VIRTUALX_REQUIRED} == test ]] &&
> + RESTRICT+=" !test? ( test )"
> ;;
> esac
>
>
Is there a better way to add
r
> arches
> # who intentionally use different kernel and userland compilers can be
> # introduced - Jason Wever , 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
tand 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
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 packa
during the review phase.
>
> Ulrich
>
Fixed.
--
NP-Hardass
signature.asc
Description: OpenPGP digital signature
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
> [...
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
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
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
eing 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
dhat.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
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
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'
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
On 07/07/2017 04:38 PM, James Le Cuirot wrote:
> On Fri, 7 Jul 2017 12:48:04 -0400
> NP-Hardass 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
On 07/07/2017 01:05 PM, William L. Thomson Jr. wrote:
> On Fri, 7 Jul 2017 12:48:04 -0400
> NP-Hardass wrote:
>>
>> There is actually a huge functional difference between the two that
>> you are missing here. A meta package defines its dependencies in full
>> depe
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,
p
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%
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 -vanill
Posted
--
NP-Hardass
signature.asc
Description: OpenPGP digital signature
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
Content-Type: text/plain
Posted: 2017-03-27
Revision: 1
News-Item-Format: 2.0
Display-If-Inst
# NP-Hardass (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
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/
th 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="
gory 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'
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
ith
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
sing 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-p
# NP-Hardass (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
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 th
nstead 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
cent 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
y to take a co-maintainer
if someone else wants that.
--
NP-Hardass
signature.asc
Description: OpenPGP digital signature
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
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
t 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 t
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
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 kno
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
# NP-Hardass (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 (6 Aug 2016)
# Masked for removal in 14 days.
# Upstream migrated from mate-dialogs to gnome's
# zen
se 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 proj
matically patch (without need for an local repo) for you
(unconditionally wrt kernel version)
--
NP-Hardass
signature.asc
Description: OpenPGP digital signature
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
Author: Andrew Savchenko
Content-Type: text/plain
Posted: 2016-07-23
Revision: 1
News-Item-Format
nk 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
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-accessi
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.e
On 06/10/2016 09:33 AM, Michał Górny wrote:
> On Thu, 9 Jun 2016 08:19:43 -0400
> NP-Hardass wrote:
>
>> # Ensure availibility of xz-utils on old EAPIs
>> if [[ "${EAPI:-0}" -lt "6" ]]; then
>> DEPEND="app-arch/xz-utils"
>> fi
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
On 06/10/2016 06:43 AM, Michał Górny wrote:
> Dnia 9 czerwca 2016 14:19:43 CEST, NP-Hardass
> 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 proje
s 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.e
es 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
On 06/08/2016 02:40 AM, Michał Górny wrote:
> On Tue, 7 Jun 2016 18:50:05 -0400
> NP-Hardass 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
ult 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
t;
> 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.
wever, 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
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
&g
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
ake 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
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.
>>
>
> A
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
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
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
-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
> wrote: [...]
>> The idea was partly due to consistency. Rather than calling
>> mate_this gnome2_that, it'd provide one namespa
-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
> wrote:
>
>> # Inherit happens below after declaration of GNOME2_LA_PUNT
>>
>> # @ECLASS-VARIABLE: MATE_LA_PUNT # @DESCRIP
-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 &qu
-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
-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
-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.
>
ilds, 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/5n
ing 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: Gnu
oject 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-
nto 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
ll 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
vNLxOsqd7w3j
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
t
ncepts/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
ikely to make
an impact than an ad hoc, unofficial one, IMO.
On January 19, 2016 5:51:27 PM EST, "Michał Górny" wrote:
>On Tue, 19 Jan 2016 00:44:49 -0500
>NP-Hardass wrote:
>
>> With all of the unclaimed herds and unclaimed packages within them, I
>> started to wo
ents 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
iQIcBAEBCAAGBQJWnc1RAA
mple 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
erd.
>
> 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, 31 Dec 2015 21:29:11 -0500
Andrew Udvare wrote:
> > On 2015-12-31, at 17:03, NP-Hardass wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Mostly just a formality...
> >
-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
too.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
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
DsjanXXgRy68zKxhLAWn03j6qWXiM2KYaTD
-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
rent 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
.
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.
-
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 wrote:
>Recently some team members of the Qt project have adopted these ebuild
>policies: https://wiki.gentoo.org/wiki/Project:
n 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 SIG
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
-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
> wrote:
>> Additionally, I feel that a signature is a means of acknowledging
>> that a package has been looked over, and that developer has
&
-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
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>
>> Not sure if this has been covered in some of the rather long
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/3HkK57mP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sun, 05 Jul 2015 21:35:23 +0200
hasufell 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-H
.
>
>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
QX3LbQVKPs6910FGN7HXNFBHvYSAmbV8twrd0LchCDcjVn
nd 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
On July 4, 2015 1:49:20 PM EDT, Peter Stuge 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 projec
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" wrote:
>On 03.07.2015 2
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
hJ74J9DcAC7ZvqJjAeASdWN83AWlUNFQQeA6eSkmtJXOot
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
>
Repoman may need to be adjusted. Git commit has support for a &
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, 3 Jul 2015 01:37:26 -0700
"Daniel Campbell (zlg)" wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 07/02/2015 12:40 PM, NP-Hardass wrote:
> > Greetings all,
> >
> > Looking for som
1 - 100 of 105 matches
Mail list logo
