Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum
On Saturday, 15 February 2020 3:14:55 AM AEDT Matt Turner wrote: > On Fri, Feb 14, 2020 at 12:31 AM Sam Jorna (wraeth) wrote: > > In this instance, at least two people (myself included) have drawn an > > impression that led them to voice their concern in some way (I'm unsure if > > mpagano was voicing concern or just agreeing with the general concept). > > Maybe we're the only ones. Maybe not. > > What do you think the threshold should be? If one person objects, > should ComRel cease and desist? Two? Should we have a Gentoo-wide > vote? > > I don't have the highest opinion of ComRel and I'm a member, but maybe > you could let us do our jobs? I didn't say ComRel shouldn't do their job, nor offered any opinion on ComRel whatsoever. I said people shouldn't be called out on what looks like a legitimate question, and that quote was illustrating one of the reasons why. The threshold I'm talking about would be "is this question, however it's worded, relevant to the subject." Having said that, if this is you wearing a ComRel hat telling me to mind my own business, so be it. -- Sam Jorna (wraeth) GnuPG ID: 0xD6180C26 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum
On Friday, 14 February 2020 2:21:32 PM AEDT Matt Turner wrote: > On Thu, Feb 13, 2020 at 4:12 AM Mike Pagano wrote: > > On Thu, Feb 13, 2020 at 06:46:43PM +1100, Sam Jorna (wraeth) wrote: > > > On Thursday, 13 February 2020 5:40:46 AM AEDT Matt Turner wrote: > > > > On Wed, Feb 12, 2020 at 9:59 AM William Hubbs wrote: > > > > > On Wed, Feb 12, 2020 at 06:54:19PM +1100, Sam Jorna (wraeth) wrote: > > > > > > On Monday, 10 February 2020 7:55:01 AM AEDT Michał Górny wrote: > > > > > > > On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote: > > > > > > > > Hrm, pardon my ignorance, but do 'we' really need to review > > > > > > > > 232 > > > > > > > > lines of > > > > > > > > Manifest?! > > > > > > > > > > > > > > Pardon mine but do 'we' really need to read your useless > > > > > > > comments > > > > > > > everywhere, all the time and just get irritated for no benefit > > > > > > > to > > > > > > > Gentoo? > > > > > > > > > > > > Perhaps I'm the one being ignorant here, but why are we lambasting > > > > > > someone for seeking clarification about an unusual inclusion on a > > > > > > review thread?> > > > > > > > > > > I wasn't going to say anything, but I can't let this go by without > > > > > commenting. > > > > > > > > > > Sam is correct. Maybe the tone is a bit off, (and that is > > > > > debatable), > > > > > but this definitely can be seen as a legit question, regardless of > > > > > other > > > > > things Michael has posted. > > > > > > > > Unfortunately it's not about a single issue or email. It's a > > > > consistent pattern that multiple people have asked him to rein in over > > > > a long period. :( > > > > > > Without going into specifics, veremit and I have certainly had our > > > 'differences of opinion' in the past; but I don't believe this is one > > > of those occasions. > > > > > > Calling out bad actors (not saying veremit is one, I just mean in the > > > general sense) is an unfortunate but important task, but call them out > > > on bad behaviour, not for what appears to be an impassioned but > > > otherwise unremarkable query. > > > > I agree with this 100 percent. Not judging solely on the content of the > > specific email in the thread does not allow people to grow and improve. > > Are we all to be judged on our past behavior forever with no chance to > > overcome past transgressions ? > > That's not what's going on. Maybe not; but that's what appears is going on. mpagano is absolutely correct that people need an opportunity to engage positively if they're expected to change their behaviour in a positive way. At the same time, however, chastising someone without an apparent transgression both reinforces negative behaviour (such as the subsequent mails on that sub- thread) *and* gives anyone not intimately familiar with that particular case the impression that people are ridiculed because they asked a relevant question (since there's no other context). In this instance, at least two people (myself included) have drawn an impression that led them to voice their concern in some way (I'm unsure if mpagano was voicing concern or just agreeing with the general concept). Maybe we're the only ones. Maybe not. I understand that you or others may have had a history of issues dealing with someone, perhaps to the point where even seeing their name puts a damper on your day. I'm sure there are people who feel the same about me. But let bad actors dig their own hole to fall in, even if you're certain beyond the shadow of a doubt that they're sitting in a darkened lair, twirling their moustache and saying things like "my evil plan is coming to fruition!"; because lashing out at an unrelated list post just looks like you're being an asshole. -- Sam Jorna (wraeth) GnuPG ID: 0xD6180C26 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum
On Thursday, 13 February 2020 5:40:46 AM AEDT Matt Turner wrote: > On Wed, Feb 12, 2020 at 9:59 AM William Hubbs wrote: > > On Wed, Feb 12, 2020 at 06:54:19PM +1100, Sam Jorna (wraeth) wrote: > > > On Monday, 10 February 2020 7:55:01 AM AEDT Michał Górny wrote: > > > > On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote: > > > > > Hrm, pardon my ignorance, but do 'we' really need to review 232 > > > > > lines of > > > > > Manifest?! > > > > > > > > Pardon mine but do 'we' really need to read your useless comments > > > > everywhere, all the time and just get irritated for no benefit to > > > > Gentoo? > > > > > > Perhaps I'm the one being ignorant here, but why are we lambasting > > > someone for seeking clarification about an unusual inclusion on a > > > review thread?> > > I wasn't going to say anything, but I can't let this go by without > > commenting. > > > > Sam is correct. Maybe the tone is a bit off, (and that is debatable), > > but this definitely can be seen as a legit question, regardless of other > > things Michael has posted. > > Unfortunately it's not about a single issue or email. It's a > consistent pattern that multiple people have asked him to rein in over > a long period. :( Without going into specifics, veremit and I have certainly had our 'differences of opinion' in the past; but I don't believe this is one of those occasions. Calling out bad actors (not saying veremit is one, I just mean in the general sense) is an unfortunate but important task, but call them out on bad behaviour, not for what appears to be an impassioned but otherwise unremarkable query. -- Sam Jorna (wraeth) GnuPG ID: 0xD6180C26 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum
On Monday, 10 February 2020 7:55:01 AM AEDT Michał Górny wrote: > On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote: > > Hrm, pardon my ignorance, but do 'we' really need to review 232 lines of > > Manifest?! > > Pardon mine but do 'we' really need to read your useless comments > everywhere, all the time and just get irritated for no benefit to > Gentoo? Perhaps I'm the one being ignorant here, but why are we lambasting someone for seeking clarification about an unusual inclusion on a review thread? -- Sam Jorna (wraeth) GnuPG ID: 0xD6180C26
Re: [gentoo-dev] Gentoo-dev whitelisting
On Sun, May 13, 2018 at 02:57:19PM -0400, Alec Warner wrote: >The whitelist automatically whitelists all @[2]gentoo.org addresses. I think those who have editbugs would also be good candidates for implicit whitelisting as well. -- Sam Jorna GnuPG Key: D6180C26 signature.asc Description: PGP signature
Re: [gentoo-dev] Regarding the State of PaX in the tree
On Sun, Apr 15, 2018 at 08:04:43PM -0400, Anthony G. Basile wrote: > The question then is, do we remove all this code? As thing stands, its > just lint that serves no current purpose, so removing it would clean > things up. The disadvantage is it would be a pita to ever restore it if > we ever wanted it back. While upstream doesn't provide their patch for > free, some users/companies can purchase the grsecurity patches and still > use a custom hardened-sources kernel with Gentoo. But since we haven't > been able to test the pax markings/custom patches in about a year, its > hard to say how useful that code might still be. Aside from potential breakage of pax-enabled systems due to lack of (ability to perform) testing, is there any burden to keeping it? Unless there's specific benefit to be had by removing the code, I'd be inclined to keep it in-place to facilitate Gentoo users who do subscribe to GRSecurity and use their patchset, granted with the disclaimer that we can't test. Removing the machinery to support it would just drive users to different platforms. Alternatively, perhaps someone from GRSec could help maintain it, since they would obviously be in a position to actually test. Though, I'm not sure how viable it is to have someone maintaining functionality to support a patchset that the majority of us cannot access... -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
[gentoo-dev] Package up for grabs: media-tv/tvheadend
Hi All; Due to not having as much time as I'd hoped, media-tv/tvheadend is being dropped to maintainer-needed. It has two open bugs[0,1], both of which have been reassigned. [0]: https://bugs.gentoo.org/show_bug.cgi?id=633774 [1]: https://bugs.gentoo.org/show_bug.cgi?id=639958 Thanks; -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation
On 11/08/17 03:08, William L. Thomson Jr. wrote: > Lets go down this rabbit hole. Let's not. -- Sam Jorna (wraeth) GnuPG ID: D6180C26 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation
On 10/08/17 11:42, William L. Thomson Jr. wrote:
> On Thu, 10 Aug 2017 10:50:45 +1000
> "Sam Jorna (wraeth)" wrote:
>
>> On 10/08/17 06:35, William L. Thomson Jr. wrote:
>>> FYI binpkgs have no hash. If someone did something malicious within
>>> the binhost to the binpkgs. You have no way of knowing. Yes the
>>> same can happen with ebuilds and manifest. But easy to sync portage
>>> and see if a manifest has changed.
>>
>> This isn't exactly true - see ${PKGDIR}/Packages on the binhost, which
>> is a manifest of built packages and related metadata. Granted this is
>> created by the binhost, it does exist and contains SHA1 and MD5
>> hashes, as well as package size. In that sense it's no different to
>> how a package Manifest file works within a repository.
>
> You are correct. I meant to say no verifiable hash. You can hash
> anything locally and claim it to be trustworthy. Thus mentioning
> syncing portage to compare manifest of ebuild/SRC_URI
> IMHO SRI_URI is more trustworthy than binhost, in the sense of
> verification. If you have means to verify the binhost stuff it maybe
> more trustworthy. That is left to the admin.
This is no greater risk than syncing from a potentially compromised
mirror. You would use a mirror you trust and, similarly (perhaps even
more so) you would use a binhost you trust.
It does raise the idea of some form of signing of the Packages file,
similar to gpg-signed portage snapshots, but that's moving well beyond
the scope of this thread.
--
Sam Jorna (wraeth)
GnuPG ID: D6180C26
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation
On 10/08/17 11:47, William L. Thomson Jr. wrote: > On Thu, 10 Aug 2017 11:25:34 +1000 > "Sam Jorna (wraeth)" wrote: > >> On 09/08/17 10:43, William L. Thomson Jr. wrote: >>> Also your redistributing another's package >>> in binary format which may not be legally allowed. >> >> Just to clarify, I wasn't suggesting redistributing license-encumbered >> packages. Since binary packages are managed by the system >> administrator, not Gentoo (as a distro), it remains with the >> administrator to adhere to any relevant license restrictions. Plus >> the package manager can't tell if you're distributing binaries or not. > > Sure, I was just pointing out that there maybe legal needs to prevent > such. Unless someone wants to circumvent. Their call but not default. > > The package manager knows about fetch restricted ebuilds. It should > not to re-package that stuff. IMHO Packaging a binary is not redistributing. Building binpkgs does not mean you're going to redistribute them, and even if you were, the package manager has no way of determining that aside from an --im-going-to-redist-this-package option. -- Sam Jorna (wraeth) GnuPG ID: D6180C26 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation
On 09/08/17 10:43, William L. Thomson Jr. wrote: > Also your redistributing another's package > in binary format which may not be legally allowed. Just to clarify, I wasn't suggesting redistributing license-encumbered packages. Since binary packages are managed by the system administrator, not Gentoo (as a distro), it remains with the administrator to adhere to any relevant license restrictions. Plus the package manager can't tell if you're distributing binaries or not. -- Sam Jorna (wraeth) GnuPG ID: D6180C26 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation
On 10/08/17 06:35, William L. Thomson Jr. wrote:
> FYI binpkgs have no hash. If someone did something malicious within the
> binhost to the binpkgs. You have no way of knowing. Yes the same can
> happen with ebuilds and manifest. But easy to sync portage and see if a
> manifest has changed.
This isn't exactly true - see ${PKGDIR}/Packages on the binhost, which
is a manifest of built packages and related metadata. Granted this is
created by the binhost, it does exist and contains SHA1 and MD5 hashes,
as well as package size. In that sense it's no different to how a
package Manifest file works within a repository.
--
Sam Jorna (wraeth)
GnuPG ID: D6180C26
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation
On 09/08/17 10:43, William L. Thomson Jr. wrote: > On Wed, 9 Aug 2017 10:29:40 +1000 > "Sam Jorna (wraeth)" wrote: > >> On 09/08/17 04:20, William L. Thomson Jr. wrote: >>> On Tue, 8 Aug 2017 19:32:48 +0200 >>> Kristian Fiskerstrand wrote: >>>> - You might be applying local patches through /etc/portage/patches >>>> that are distributed to all clients >>> >>> This might be the strongest reason. Though would only apply to stuff >>> like say kernel sources. Not sure what patches could be applied to a >>> binary ebuild, -bin. A patch would not effect src_install per my >>> understanding. >> >> There's also the fact that binpkgs may be manually installed exactly >> as the package manager would have installed it, rather than extracting >> whatever upstream supplies verbatim. > > What then is the benefit? If what is installed is the same from > package manager or binpkg. Also your redistributing another's package > in binary format which may not be legally allowed. The difference is that how the package manager/ebuild installs the package may be better suited to the environment than what upstream expects (such as upstreams that install through a .run file) >> This includes things like any wrappers, desktop files or symlinks >> created by the ebuild, or other such downstream-isms. > > If it was made via package manager. If it was made via quickpkg, it > maybe different than if made by package manager. Using quickpkg can create different binaries depending on your options, but otherwise it should package any installed files as recorded by the package manager - provided you use inclusive options, there should be no appreciable difference as far as I'm aware. -- Sam Jorna (wraeth) GnuPG ID: D6180C26 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation
On 09/08/17 04:20, William L. Thomson Jr. wrote: > On Tue, 8 Aug 2017 19:32:48 +0200 > Kristian Fiskerstrand wrote: >> - You might be applying local patches through /etc/portage/patches >> that are distributed to all clients > > This might be the strongest reason. Though would only apply to stuff > like say kernel sources. Not sure what patches could be applied to a > binary ebuild, -bin. A patch would not effect src_install per my > understanding. There's also the fact that binpkgs may be manually installed exactly as the package manager would have installed it, rather than extracting whatever upstream supplies verbatim. This includes things like any wrappers, desktop files or symlinks created by the ebuild, or other such downstream-isms. -- Sam Jorna (wraeth) GnuPG ID: D6180C26 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
On Thu, Aug 03, 2017 at 05:54:17PM +0200, Michał Górny wrote:
> d. no random ${PN} all over the install phase.
I think some qualification of "random ${PN} all over the install phase"
needs to be made - how random is random, are there any allowed
instances?
AFAIK with the exception of some system-wide resources (eg. themes,
icons, fonts) packages installing to locations such as /usr/share and
/usr/share/doc should install to directories named after the package (as
in after ${PN} or ${PF}). This means, when writing src_install(), that
use of those variables would be necessary. Should we always use ${PF}
instead, or are some instances of ${PN} reasonable?
--
Sam Jorna (wraeth)
GnuPG Key: D6180C26
signature.asc
Description: Digital signature
Re: [gentoo-dev] Changing PMS to Portage Manager Specification
On Tue, Aug 01, 2017 at 06:05:00PM -0400, William L. Thomson Jr. wrote: > I think Gentoo council, developers, and portage developers should > consider changing the PMS, to something like Portage Manager > Specification, or Gentoo Portage Specification. Make it Gentoo > and portage specific, and others adhere to that standard. If you have a look at the Package Manager Specification project page[1] it notes that this is how it worked previously and was decided against. Personally, given that Gentoo is a meta-distribution, it makes more sense to me to have an independent specification for things like this and have the "default" package manager essentially be the reference implementation of the specification. If there's a better way to do something than what is defined in PMS, then perhaps suggest an update to it. [1] https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Sun, Jul 30, 2017 at 10:44:58PM -0400, William L. Thomson Jr. wrote: > On Mon, 31 Jul 2017 10:28:31 +1000 > Sam Jorna wrote: > > > > Wouldn't it make more sense to make Gentoo *more* attractive to run in > > corporate environments, rather than simply saying "We're not RHEL so > > why bother"? > > No disagreement. That has always been my interest. Though has not been > others. It was in part why I became a trustee. For things like vendor > certified hardware, looking into certifications, events, and a whole > lot more. But people rather lambast, insult, and stand in the way rather > than either get out of the way or work with me. > > It surely could happen without me but has not. I am definitely not > against such happening. But it would require tremendous change and > leadership. Which I do not see ever changing. I wish things were > otherwise. > > > People do use Gentoo in production environments, both personally and > > professionally, even if it is those that have more investment in doing > > so than the average IT Joe. By removing stable, we would be reducing > > the potential arguments for the few who do want to use Gentoo in that > > sort of environment. We would be becoming more of a niche distro. > > Preaching to the choir. That is not why companies I know who ran Gentoo > are leaving or left. One told me they did not want to be in the > operating system business. Stable or not, there are fewer companies > running Gentoo that were before. Due to other reasons that are not > changing, culture, etc. > > Companies that run it today I doubt would change if stable went away. > If they left Gentoo, they have many reasons far beyond lack of a stable > branch/tree. > > > "Hey, lets try Gentoo - it's really configurable." > > "What's their stable policy? How often does it break?" > > "Stable? What's that?" > > How about no foundation. Not even a legal entity. No certifications > from vendors, nor for employees. No one to hire for official support. > There are so many things far beyond anything having to do with a stable > tree or not. Sorry, I thought this thread was about whether to keep or discontinue the separation between stable and testing branches. -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Fri, Jul 28, 2017 at 03:59:36PM -0400, William L. Thomson Jr. wrote: > On Fri, 28 Jul 2017 23:10:35 +1000 > "Sam Jorna (wraeth)" wrote: > > > On 28 July 2017 8:44:20 PM AEST, "Andreas K. Huettel" > > wrote: > > > > >That's not feasible. It would kill off any semi-professional or > > >professional > > >Gentoo use, where a minimum of stability is required. > > > > > >(Try keeping ~10 machines on stable running without automation. > > >That's already > > >quite some work. Now try the same with ~arch. Now imagine you're > > >talking about > > >100 or 1000 machines.) > > > > And further, try proposing that to management - that you'll be > > managing hosts on a platform that has no "stable" to speak of. > > The professional/management argument is silly. Most avoid Gentoo. > Most companies, want to be able to pay for support. Not to mention > certifications and such for those they hire. None of which Gentoo has > regardless of stability. Not to mention reputation... > > Those that tend to run Gentoo have their own interest in such. I have > seen many migrate from rather than to Gentoo. Large companies, who's > names we would all know. One of the few left is Meetup.com. They run > Gentoo as do some others. Seems Tivo does stuff with Gentoo, Google, > Sony, etc. Some tend to hire Gentoo devs... Wouldn't it make more sense to make Gentoo *more* attractive to run in corporate environments, rather than simply saying "We're not RHEL so why bother"? People do use Gentoo in production environments, both personally and professionally, even if it is those that have more investment in doing so than the average IT Joe. By removing stable, we would be reducing the potential arguments for the few who do want to use Gentoo in that sort of environment. We would be becoming more of a niche distro. "Hey, lets try Gentoo - it's really configurable." "What's their stable policy? How often does it break?" "Stable? What's that?" -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On 28 July 2017 8:44:20 PM AEST, "Andreas K. Huettel" wrote: >Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge: >> >> I hold a perhaps radical view: I would like to simply remove stable. >> >> I continue to feel that maintaining two worlds (stable+unstable) >> carries with it an unneccessary cost. >> > >That's not feasible. It would kill off any semi-professional or >professional >Gentoo use, where a minimum of stability is required. > >(Try keeping ~10 machines on stable running without automation. That's >already >quite some work. Now try the same with ~arch. Now imagine you're >talking about >100 or 1000 machines.) And further, try proposing that to management - that you'll be managing hosts on a platform that has no "stable" to speak of. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow
On Wed, Jul 26, 2017 at 07:05:47PM +0200, Kristian Fiskerstrand wrote: > On 07/25/2017 02:28 PM, Michael Palimaka wrote: > > Does a bug # really need to always be in the summary line? It can eat > > valuable characters and tags which are pretty popular are equally valid IMO. > > I would prefer the summary to be informative without having bug ID at > all. Summary should describe the change ,not only "fixes XXX", the bug > reference belongs in body (tags) > > -- > Kristian Fiskerstrand > OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net > fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 +1 Given the length restriction and the requirement to include category/package, adding a bug reference doesn't leave much space for a useful description. -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] News item: systemd rootprefix migration
On 14/07/17 11:32, Mike Gilbert wrote: > Please share your comments/questions on the proposed news item below. > There is no immediate action required for most users, but it seems > like a significant enough change to warrant a broadcast. > > -- > > Title: systemd rootprefix migration > Author: Mike Gilbert > Posted: 2017-07-14 > Revision: 1 > News-Item-Format: 2.0 > Display-If-Installed: >=sys-apps/systemd-234 > > Starting with the 234 release, Gentoo's sys-apps/systemd package will > be built with rootprefix=/. This means most of the included programs > and system units will be installed under /lib/systemd instead of > /usr/lib/systemd. > > This change brings Gentoo into alignment with most other distros which > still maintain a distiction between boot-critical programs in /, and > less critical programs in /usr. This also means that users with a > separate /usr filesystem will have an easier time booting if their > initramfs should become corrupt or fail. > > Symlinks are provided for /usr/lib/systemd/systemd and > /usr/lib/systemd/systemd-shutdown to avoid breaking bootloader configs > and to allow the system to be shutdown/rebooted without issue. Will these symlinks be maintained indefinitely? Would it be worth suggesting updating cmdline's to point to the new location rather than the symlink? > This change will be mostly transparent to typical users. You may notice > that system units move from /usr/lib/system/system to > /lib/system/system as you upgrade/re-install packages; this is normal. > Units will function properly from both locations. s:/lib/system:&d: > As always, if you run into problems, please report a bug. Otherwise, lgtm. -- Sam Jorna (wraeth) GnuPG ID: D6180C26 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds
On 13/07/17 00:19, William L. Thomson Jr. wrote: > It is YOUR comments that are funny, and going in a circular argument > just to be argumentative and bringing nothing useful to the discussion. > Which should be over now that bugs are filed I'm not trying to be argumentative or antagonistic, I'm trying to understand how your replacement warning differs from what's already available and adds value. >> '--depclean foo' is the user removing something they /are/ aware of >> *if it's not a dependency*. > > That does not work the same. It will not remove a package from world. $ grep apg /var/lib/portage/world app-admin/apg $ emerge -C apg * This action can remove important packages! In order to be safer, use * `emerge -pv --depclean ` to check for reverse dependencies before * removing packages. >>> Unmerging in: 5 4 3 2 1 >>> Unmerging (1 of 1) app-admin/apg-2.3.0b-r5... ... $ grep apg /var/lib/portage/world app-admin/apg $ emerge -c apg Calculating dependencies... done! >>> Calculating removal order... >>> Unmerging in: 5 4 3 2 1 >>> Unmerging (1 of 1) app-admin/apg-2.3.0b-r5... > Clearly you are having a hard time grasping this very simple concept. > I am done, reply if you like, but this thread is serious noise now... Clearly, hence why I was trying to understand what difference your proposal offered. But since we're moving on to serious things now, I guess I /am/ done with this thread. -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds
On 12/07/17 16:06, William L. Thomson Jr. wrote:
> On Wed, 12 Jul 2017 15:49:14 +1000
> "Sam Jorna (wraeth)" wrote:
>>
>> I have trouble remembering what I ate for dinner last night, let alone
>> what I may or may not have merged a week, month or year ago, or what
>> options I used when merging it.
>
> And if you used --oneshot, it is also saying you are not maintaining
> your system or ever running --depclean. Since anything you installed
> via --oneshot would be removed with --depclean.
If my concern in removing a package was whether it was a dependency, it
would make more sense to use --depclean in the first place. If I'm using
--unmerge, it's because I want the package unmerged regardless.
>>> What harm does a warning do?
>>
>> Depends on the user, which can't really be avoided, but means that
>> warnings should be clear and meaningful, otherwise they become
>> background noise.
>
> The example in the bug is as clear is it can get.
>
> !!! 'sys-devel/gcc' is a dependency of another package on your system
> or
> !!! 'sys-devel/gcc' is a package not found in system profile or world
> or
> !!! 'sys-devel/gcc' may not have been installed by you
> or
> some other message
>
>> Such as:
>>
>> emerge --unmerge dev-python/keyring
>> * This action can remove important packages! In order to be safer,
>> use
>> * `emerge -pv --depclean ` to check for reverse dependencies
>> before
>> * removing packages.
>
> Didn't you just say something about meaningful output vs noise? That is
> always outputted and ends up becoming what you are saying. Funny!
And your suggesting adding more noise to it... Funny, I know.
>>>> or may have been installed as an orphan but is now a
>>>> dependency.
>>>
>>> Now being a dependency the warning would be valid.
>>
>> "Sometimes being accurate" is not the most noble of goals.
>
> What?
>
>> So the idea is to duplicate the functionality of '--depclean
>>
>
> NO!!!
>
> emerge --depclean gcc
>
> is not the same as
>
> emerge --umerge gcc
>
> Depclean the user is cleaning things they are not aware of. Unmerge the
> user is removing something directly. They may think they do not need it.
No.
'--depclean' is the user removing things they are not aware of.
'--depclean foo' is the user removing something they /are/ aware of *if
it's not a dependency*.
'--unmerge foo' is the user explicitly removing something regardless of
whether it's a dependency.
Therefore, '--depclean foo' can be seen as a safe '--unmerge foo' which,
from what I understand, is what you're aiming for.
>> ' without actually checking to see if the package is a
>> dependency,
>
> Word it how ever. If the user did not install, they should be warned on
> removal of a package they did not install.
That's what the current warning to --unmerge says - removing packages
can break things, so please make sure this isn't a dependency and you
really want to remove this.
>> only whether it is listed in a set; or to check if it's a
>> dependency of /something/ and, if so, redirect the user to the
>> command they should be using anyway?
>
> You mean like emerge --unmerge does already that you pointed out
> above. After mentioning useful messages vs noise. Again funny!
How does replacing one warning with another warning that may or may not
be meaningful ("maybe it's a dep, maybe it isn't" as opposed to "this
can be dangerous, please make sure you know what you're doing") make it
any better?
--
Sam Jorna (wraeth)
GnuPG ID: D6180C26
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds
On 12/07/17 15:36, William L. Thomson Jr. wrote: > On Wed, 12 Jul 2017 15:19:32 +1000 > "Sam Jorna (wraeth)" wrote: > >> On 12/07/17 15:14, William L. Thomson Jr. wrote: >>> Is it in system? >>> Is it in a set? >>> Is it in world? >>> If no to all, its a dep, warn! >> >> All this says is whether the package was explicitly installed and >> recorded in world, or is a member of @system. The target package may >> or may not be a dependency, may or may not have been --oneshot'd. > > Then when the user sees the warning they can discard knowing they > merged the package with --oneshot. I have trouble remembering what I ate for dinner last night, let alone what I may or may not have merged a week, month or year ago, or what options I used when merging it. > What harm does a warning do? Depends on the user, which can't really be avoided, but means that warnings should be clear and meaningful, otherwise they become background noise. >> It may have been installed as a dependency but the requiring package >> was removed, > > Then the person failed to run --depclean and maintain their system. > Either way, did the person install the package directly? > > If the package was not installed by the user. Should they not be warned > about removing something they did not install? Such as: emerge --unmerge dev-python/keyring * This action can remove important packages! In order to be safer, use * `emerge -pv --depclean ` to check for reverse dependencies before * removing packages. >> or may have been installed as an orphan but is now a >> dependency. > > Now being a dependency the warning would be valid. "Sometimes being accurate" is not the most noble of goals. >> Assuming that if it's not in a set it must be a dependency is >> incorrect and misleading. > > Again there are various ways. There cannot be that much overhead to > check if a single package depends on one being removed. If you cannot > use simpler methods as mentioned. > > Clearly people have objections to warnings about packages users did not > install themselves > So the idea is to duplicate the functionality of '--depclean ' without actually checking to see if the package is a dependency, only whether it is listed in a set; or to check if it's a dependency of /something/ and, if so, redirect the user to the command they should be using anyway? -- Sam Jorna (wraeth) GnuPG ID: D6180C26 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds
On 12/07/17 15:14, William L. Thomson Jr. wrote: > Is it in system? > Is it in a set? > Is it in world? > If no to all, its a dep, warn! All this says is whether the package was explicitly installed and recorded in world, or is a member of @system. The target package may or may not be a dependency, may or may not have been --oneshot'd. It may have been installed as a dependency but the requiring package was removed, or may have been installed as an orphan but is now a dependency. Assuming that if it's not in a set it must be a dependency is incorrect and misleading. -- Sam Jorna (wraeth) GnuPG ID: D6180C26 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds
On 12/07/17 14:43, William L. Thomson Jr. wrote: >>> It is not the same as -C, which is remove a package directly. >>> >>> --unmerge (-C) >> Correct, --unmerge will remove a package without considering >> dependencies (give or take a few special cases). It is usually (or, at >> least, should generally be) reserved for those taking a hammer to a >> problem or with a particular desire to recover a broken system. >> >> Again, it's doing exactly what it's supposed to - removing a package >> you've told it to remove (unless it's one of the few >> almost-always-critical packages). > Yes and if you see bug. All I am saying is adding warnings when someone > goes to remove a dependency. Since a dependency IS a critical package :) > > Add warning message when -C/--unmerge a dependency like system, > profile, and set files. > https://bugs.gentoo.org/show_bug.cgi?id=624630 My point was that --unmerge is not intended to be dependency-aware. --depclean is. As far as I can tell, that is the point others have been trying to make as well, when pointing out the differences between -c and -C. -- Sam Jorna (wraeth) GnuPG ID: D6180C26 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds
On 12/07/17 10:05, William L. Thomson Jr. wrote: > I should have caught that sooner. -c does not remove a package, it just > removes its deps. > > -c == --depclean. --depclean is doing exactly what it is supposed to. If called with no arguments, it searches for any unneeded dependencies and removes them, however if called with a package as an argument, it will remove that package *if it is not a dependency of another package*. Reporting "nothing to remove" is precisely what it's supposed to do, and using --verbose will tell you what is depending on the package. To be clear, running '--depclean foo' does not remove dependencies of foo, it removes foo provided it is not a dependency. It can be seen as a dependency-aware (and thus, generally safe) --unmerge. Making --depclean _always_ give you more information should just be a case of adding --verbose to EMERGE_DEFAULT_OPTS. > It is not the same as -C, which is remove a package directly. > > --unmerge (-C) Correct, --unmerge will remove a package without considering dependencies (give or take a few special cases). It is usually (or, at least, should generally be) reserved for those taking a hammer to a problem or with a particular desire to recover a broken system. Again, it's doing exactly what it's supposed to - removing a package you've told it to remove (unless it's one of the few almost-always-critical packages). -- Sam Jorna (wraeth) GnuPG ID: D6180C26 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: taking a break from arches stabilization
On 12/07/17 03:16, William Hubbs wrote: > On Tue, Jul 11, 2017 at 11:47:32PM +1000, Michael Palimaka wrote: >> On 07/11/2017 11:06 PM, Rich Freeman wrote: >>> On Tue, Jul 11, 2017 at 8:59 AM, Michael Palimaka >>> wrote: >>>> On 07/11/2017 09:29 AM, Andrew Savchenko wrote: >>>>> >>>>> Even if such stabilization is allowed, there are unanswered >>>>> questions here: >>>>> - is following seciton 4.1 from wg recommendations is sufficient? >>>>> - should developer test each stabilization candidate on an >>>>> up-to-date stable setup? >>>> >>>> The guidelines from that document are ripped straight out of the >>>> devmanual and are a good starting point but rather generic. You can find >>>> some more detailed suggestions on things to consider while testing on >>>> the wiki: https://wiki.gentoo.org/wiki/Package_testing >>>> >>> >>> I think that in practice arch teams don't do have the stuff on that >>> wiki page. Maybe some people do, but back when I was an amd64 AT I >>> don't think anybody went testing multiple USE combinations for a >>> typical package. >> >> Everything on that page is deliberately a suggestion only, and not >> necessarily specific to stabilisation testing. >> >> In the end, we've never been able to reach any consensus on what exactly >> an arch tester should do. Personally, I think we should just switch to >> fully-automated, build-only testing for stabilistions unless the >> maintainer opts otherwise (something that largely happens in practice >> already). The main risk of breakage of a package moving from testing to >> stable is always at build time anyway. > > I would not be opposed to this. As a maintainer, I am as guilty as the > next guy of not filing stable requests or not stabilizing packages. As the next guy, I also +1 this. As is often explained in #gentoo, "stable" and "testing" for upstream have a different meaning to "stable" and "testing" for Gentoo - in fact, beyond ensuring it builds, any testing performed by a downstream distro is additional testing to what upstream have already released. I can understand the concern with automatically stabilising a package that has some flaw affecting users, but the two things i see are that upstream have already released said flawed package, and Gentoo simply doesn't have the manpower to perform comprehensive runtime testing of all packages. If a maintainer is aware of a significant issue with a package that should prevent it from being marked as stable, then a bug should be filed acting as a block to the automated stabilisation. Users aware of an issue are just as likely to file a bug as well, also preventing stabilisation of packages with some known issue. Therefore packages with known issues don't get stabilised automatically. Similarly, if the maintainer believes more comprehensive testing should be done (eg. for critical base-system packages) a note could be made somewhere of that requirement (metadata.xml?), meaning significantly reduced workload for people like ago (if the maintainer doesn't stabilise it beforehand). -- Sam Jorna (wraeth) GnuPG ID: D6180C26 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Fixing elasticsearch maintainer
On Mon, May 22, 2017 at 07:47:19AM +0200, Michał Górny wrote: > On pon, 2017-05-22 at 11:52 +1000, Sam Jorna wrote: > > On 18/05/17 02:38, Patrick Lauer wrote: > > > Since proxy-maint refuses to be removed from packages (especially since > > > they > > > were unconditionally added to all packages with a non-gentoo-dev > > > maintainer in > > > metadata) they are the de facto maintainers, and overrule everything else. > > > > Just to clarify, the Proxy Maintainers project is not required to be > > added to all packages maintained by non-Gentoo maintainers. If a Gentoo > > developer is willing to work with and proxy commits for maintainer(s) > > without commit access, Proxy Maintainers are happy to be removed. There > > are several metadata.xml's in the tree with examples, including a few > > for which you are one of the maintainers. > > > > Just to clarify, this works only if the developer and proxied maintainer > agree on the terms. It's not 'I remove proxy-maint, and now force you to > work on my terms that do not fit you because reasons'. That's why I used the phrase "work with". -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Fixing elasticsearch maintainer
On Mon, May 22, 2017 at 06:12:54AM +0200, Patrick Lauer wrote: > On 05/22/2017 03:52 AM, Sam Jorna wrote: > > On 18/05/17 02:38, Patrick Lauer wrote: > >> Since proxy-maint refuses to be removed from packages (especially since > >> they > >> were unconditionally added to all packages with a non-gentoo-dev > >> maintainer in > >> metadata) they are the de facto maintainers, and overrule everything else. > > > > Just to clarify, the Proxy Maintainers project is not required to be > > added to all packages maintained by non-Gentoo maintainers. If a Gentoo > > developer is willing to work with and proxy commits for maintainer(s) > > without commit access, Proxy Maintainers are happy to be removed. There > > are several metadata.xml's in the tree with examples, including a few > > for which you are one of the maintainers. > > > That's nice. > > Could proxy-maint as a team maybe try to agree on such things so that > everyone is on the same page? It's a tiny bit annoying when the actions > of some contradict the suggested rules of others, while appearing as a > single team to the outside ... I suspect it's likely a misunderstanding - without notification, all anyone from Proxy Maint sees is proxy-maint being removed. An E-Mail to proxy-maint@g.o explaining that you've spoken to and are taking over proxying of the package would make sure we know what's happening. -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Fixing elasticsearch maintainer
On 18/05/17 02:38, Patrick Lauer wrote: > Since proxy-maint refuses to be removed from packages (especially since they > were unconditionally added to all packages with a non-gentoo-dev maintainer in > metadata) they are the de facto maintainers, and overrule everything else. Just to clarify, the Proxy Maintainers project is not required to be added to all packages maintained by non-Gentoo maintainers. If a Gentoo developer is willing to work with and proxy commits for maintainer(s) without commit access, Proxy Maintainers are happy to be removed. There are several metadata.xml's in the tree with examples, including a few for which you are one of the maintainers. -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Guidelines for IUSE defaults
On Tue, Feb 07, 2017 at 09:11:20PM -0500, Rich Freeman wrote: > On Tue, Feb 7, 2017 at 8:24 PM, Sam Jorna wrote: > > On Tue, Feb 07, 2017 at 12:00:51PM -0500, Rich Freeman wrote: > > > >> On Tue, Feb 7, 2017 at 10:14 AM, Ian Stakenvicius wrote: > > > >> > OK, can we all decide out of this thread, that if any package is > >> > enabling critical functionality via IUSE-defaults (or rather, IUSE > >> > defaults alone), that this be addressed through package.use.force in > >> > profiles OR through removal of the flag? > >> > >> No. > > > > Can this be justified a little more? > > > > If a package is broken when a given flag is disabled, why is it not > > acceptable to not provide the flag? > > Perhaps the issue is the definition of "critical functionality." > > I may have interpreted it differently than intended. > > If setting a flag one way or the other results in a package that has > no useful purpose then I certainly agree that this shouldn't be a flag > in the first place. When certain combinations result in > non-functional packages these should be caught as well (via > REQUIRED_USE), though in really complex packages with many flags this > may sometimes be difficult to spot. > > On the other hand, I believe it should be acceptable to use IUSE > defaults to configure a package to provide an ideal experience for the > typical user of the package, or align with upstream. Non-upstream > patches that aren't related to integration are pushing it, but merely > providing an upstream-like default experience should be the goal for > anybody who doesn't override this one way or the other. > > My brevity wasn't intended to be rude. I've just posted extensively > enough in this thread and didn't want to just re-iterate my previous > emails, and so so above for clarity. Ah, this makes sense to me - IUSE defaults being a kind of soft "new to Gentoo" or "minimal effort for common usage" setup, REQUIRED_USE to prevent bad combinations, and package.use.force for known breakages with individual flags. Thanks for the clarification. -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Guidelines for IUSE defaults
On Tue, Feb 07, 2017 at 12:00:51PM -0500, Rich Freeman wrote: > On Tue, Feb 7, 2017 at 10:14 AM, Ian Stakenvicius wrote: > > On 07/02/17 08:27 AM, Michael Orlitzky wrote: > >> > >> The thread wasn't about discouraging IUSE defaults, rather to decide > >> when they are appropriate. You cannot omit "pkginternal" from USE_ORDER, > >> because you will break all of the packages whose defaults are either > >> critical to the package, or prevent a REQUIRED_USE conflict. > >> > > > > OK, can we all decide out of this thread, that if any package is > > enabling critical functionality via IUSE-defaults (or rather, IUSE > > defaults alone), that this be addressed through package.use.force in > > profiles OR through removal of the flag? > > No. Can this be justified a little more? If a package is broken when a given flag is disabled, why is it not acceptable to not provide the flag? If the flag is still provided for the sake of user choice, why is it unacceptable to force it through package.use.force allowing the majority of users to not need to worry, and letting advanced users break their egg in their quest for an omelette? How is this different (for example, not pointing fingers) from dev-lang/python[threads] being forced because it's broken without it (therefore critical functionality)? Disclaimer: not trying to be argumentative, just trying understand the arguments. :) -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Guidelines for IUSE defaults
On Thu, Feb 02, 2017 at 09:26:20PM -0500, Michael Orlitzky wrote: > On 02/02/2017 09:22 PM, Sam Jorna wrote: > > > > Also, how would this work with local USE flags as opposed to global > > flags? Would they be acceptable to have IUSE defaults? > > > > Exactly the same way as global flags: drop an entry in the desktop > profile's package.use. I can understand the reasoning behind using this, but it seems unnecessarily laborious to do so - as I said, it would mean playing around with profiles whenever changing a package for which flags are defaulted. Perhaps some standardisation of what warrants an IUSE default could help, otherwise you might end up with the same situation, just relocated into the profiles namespace instead of the package. Having said that, I'm not strongly opposed, just trying to sound out pros/cons/gotcha's. -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Guidelines for IUSE defaults
On Thu, Feb 02, 2017 at 09:06:33PM -0500, Michael Orlitzky wrote: > On 02/02/2017 09:00 PM, Sam Jorna wrote: > > > > Consider: a new user, coming from Ubuntu or Fedora or Windows, starts > > building their system. They start installing packages they want, only to > > find that half of the package isn't there because no USE flags were > > enabled. They have to enable these flags for almost every package they > > want because there's no defaults, you must manually specify anything > > that's not a direct dependency or forced by profile. > > Desktop profile!! We have a desktop profile!!! Why is the base > profile a better location for new-user-with-a-desktop defaults than the > **desktop** profile? > > I'm going crazy. I give up. That would also mean two commits when adding or removing a package with any defaults - one for profiles/, one for the package itself - as well as when flags change for a given package. Also, how would this work with local USE flags as opposed to global flags? Would they be acceptable to have IUSE defaults? -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Guidelines for IUSE defaults
On Thu, Feb 02, 2017 at 09:11:26AM -0500, Michael Orlitzky wrote: > IUSE defaults are used in a few different ways: > > 1 To ensure that critical functionality is enabled. > > * Example: force the "unix" module for apache. Why provide a flag for something that is required anyway? And if it's a case of "you *really* should have this, but if you want to break it, here's how", then why not put it in package.use.force instead? An IUSE default for this doesn't make sense. > 2 To avoid an unsatisfied REQUIRED_USE by default. > > * Example: having a non-empty RUBY_TARGETS by default. This seems reasonable - two mutually exclusive options, of which one is preferred. That being said, I do see it as akin to 3 and 4. > 3 To make Gentoo defaults the upstream defaults. > > * Example: right now the defaults for dev-lang/php build > you a "normal" PHP installation. > > 4 To make the default build agree with the maintainer's personal > preferences. > The way I see it, IUSE defaults are provided by the maintainer as a way to offer a package with "what you probably would want enabled" to facilitate users who either aren't interested in ricing their system or aren't experienced enough with Gentoo to tweak all the flags. Consider: a new user, coming from Ubuntu or Fedora or Windows, starts building their system. They start installing packages they want, only to find that half of the package isn't there because no USE flags were enabled. They have to enable these flags for almost every package they want because there's no defaults, you must manually specify anything that's not a direct dependency or forced by profile. Conversely, users who want a minimal system are ones who are much more likely to inspect emerge's output before committing to a build. They are likely more willing to tweak the flags to have the system provide only the things they want. Often they'll have USE="-*", accepting that they'll probably have to enabled a bunch of things to get their desired functionality. IUSE defaults are a convenience for those either inexperienced with Gentoo or uncaring of cruft. Certainly maintainers should put some forethought into which flags they default to enabled, but I see the end goal as helping the users who need the help most (not to discount more advanced users, but they are more likely to *want* to tweak than one for whom this is their first CLI). That's my two cents, at least. -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)
On Tue, Jan 17, 2017 at 04:45:39AM -0800, Daniel Campbell wrote: > On 01/06/2017 12:46 PM, William L. Thomson Jr. wrote: > > On Friday, January 6, 2017 9:14:54 AM EST Alec Warner wrote: > >> > >> The nice thing about ::graveyard or similar is that its a clear demarcation > >> between maintained (in tree) and unmaintained (graveyard.) It also means > >> that people doing actual maintenance work can basically ignore the > >> graveyard as a matter of policy. The ebuilds are archived there (for users) > >> but since they are unmaintained they may not work correctly. > > > > This is what the Java team used to do. There was a java-graveyard-overlay. > > I > > do not believe any package ever moved there came back into the tree. It did > > result in a pretty messed up overlay, but makes it a user problem. > > > > At the same time, something could always be restored from VC. Not like > > removal > > is removing all history and traces. Thus not sure such overlay is really > > even > > beneficial. Using it could cause lots of problems if they just care about 1 > > package or a few. > > > > There's a nice trick around that, actually: let's assume the overlay is > called "foo-overlay". > > In package.mask: > > */*::foo-overlay > > will mask all packages in the overlay. You can then add packages to > package.unmask: > > pkg-cat/foobar::foo-overlay > > That should alleviate most issues, though it can make dependencies a > PITA if those deps are also in the overlay. In that case, emerge should > yell at you and suggest adding lines to package.unmask. Another option would be to set the priority of the overlay to -1001 (one less than gentoo.git) and explicitly emerge the package from the overlay: emerge -a pkg-cat/foobar::foo-overlay Dependencies will by default be drawn from gentoo.git (if it has equal or better version(s)), and overlay-only dependencies won't need to be explicitly unmasked. You may end up with gentoo.git-provided packages coming from the overlay if they have newer versions, though when talking about graveyard, that shouldn't be an issue. -- Sam Jorna (wraeth) GPG ID: 0xD6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Stats: Gentoo developer commit timeline
On Mon, Jan 16, 2017 at 10:35:30AM +0100, Michał Górny wrote: > Just a quick side project we've done a while ago. It's a timeline of > developer commit activity [1]. Code for data processing in [2]. I did > the data, Amynka prepared a nice JS to graph it. Nice work! Thanks, both mgorny and Amynka! -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-12-18 23:59 UTC
On Sun, Dec 18, 2016 at 07:23:25PM -0500, Michael Orlitzky wrote: > On 12/18/2016 07:05 PM, Robin H. Johnson wrote: > > > > Additions: > > ... > > dev-php/ca-bundle 20161124-07:43 mjo 7597666 > > dev-php/cli-prompt20161124-07:21 mjo d3bd351 > > dev-php/composer 20161124-08:09 mjo d273046 > > dev-php/fedora-autoloader 20161123-15:49 mjo 38e69d1 > > dev-php/jsonlint 20161124-07:29 mjo 033f5d3 > > dev-php/json-schema 20161124-07:24 mjo 79a2aeb > > dev-php/phar-utils20161124-07:18 mjo ea07d00 > > dev-php/psr-log 20161123-15:55 mjo 6c369a5 > > dev-php/semver20161124-07:40 mjo 0bccd72 > > dev-php/spdx-licenses 20161124-07:33 mjo a780206 > > dev-php/symfony-config20161124-07:50 mjo d10d7e2 > > dev-php/symfony-console 20161124-08:03 mjo bc36d09 > > dev-php/symfony-dependency-injection 20161124-07:57 mjo 9963181 > > dev-php/symfony-event-dispatcher 20161124-07:59 mjo 2283ea2 > > dev-php/symfony-filesystem20161123-18:29 mjo bdc6673 > > dev-php/symfony-finder20161123-18:53 mjo 57de338 > > dev-php/symfony-process 20161123-18:15 mjo a7733e1 > > dev-php/symfony-yaml 20161124-07:54 mjo e751ace > > > These were all added by a user, Guillaume Seren. I only merged the pull > request. We recently had a thread, "Please retain authorship of > contributed patches," in light of which it might be cool if we could get > the author's name listed above rather than the committer (when the > author is not a developer). +1 I imagine it shouldn't be too hard to get the Author attribute of a given commit rather than Committer. -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device
On Mon, Dec 12, 2016 at 02:35:28PM +1100, Sam Jorna wrote: > On Mon, Dec 12, 2016 at 09:34:21AM +0700, gro...@gentoo.org wrote: > > On Sun, 11 Dec 2016, Kristian Fiskerstrand wrote: > > > On 12/11/2016 03:13 PM, gro...@gentoo.org wrote: > > >> gpg: signing failed: Inappropriate ioctl for device > > > this might indicate a want for export GPG_TTY=$(tty) > > I don't understand what has really happened. I removed my last commit, an > > attempt to commit it again failed with gpg: signing failed. Then I logged > > out of the box on which I have the git tree (I log in this box via ssh), > > and logged in again. After that the commit succeeded. > > I was also getting some odd issues with commit signing, though it seemed > to settle for me when I switched to pinentry-curses (since I use > awesome), so I figured it was probably a local issue. Perhaps there's a > wider problem here? If anyone else is getting this, it seems to be resolved by exporting GPG_TTY=$(tty) either immediately before attempting to sign or in your shell ~/.*rc file. -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device
On Mon, Dec 12, 2016 at 09:34:21AM +0700, gro...@gentoo.org wrote: > On Sun, 11 Dec 2016, Kristian Fiskerstrand wrote: > > On 12/11/2016 03:13 PM, gro...@gentoo.org wrote: > >> gpg: signing failed: Inappropriate ioctl for device > > this might indicate a want for export GPG_TTY=$(tty) > I don't understand what has really happened. I removed my last commit, an > attempt to commit it again failed with gpg: signing failed. Then I logged > out of the box on which I have the git tree (I log in this box via ssh), > and logged in again. After that the commit succeeded. I was also getting some odd issues with commit signing, though it seemed to settle for me when I switched to pinentry-curses (since I use awesome), so I figured it was probably a local issue. Perhaps there's a wider problem here? -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Cross Post due to technical component - Thanks for all the fish
On Tue, Dec 06, 2016 at 09:37:55PM -0500, james wrote: > >> I subscribe on 6/23/2016:: > >> > >> From:: gentoo-proxy-maint+h...@lists.gentoo.org > >> > > > > This is the correct address and as it noted, you should get a > > confirmation/welcome email when you've successfully subscribed. Did you > > get this? > > YES, back on 6/23/2016 It never functioned correctly for me. > I think everyone switched to the new list, which I never heard about. > > > And here is the reply:: > > gentoo-proxy-maint+confsub-nomail-75dc5ad5188e6314-garftd=verizon@lists.gentoo.org > > on 6/23/2016 10:21am > > > > So do I need to apply again, or an I on the list? I went (nomail) cause > at the time reading via gmane.org was working. Perhaps I should just > change the status to receive the mails? I can test post, if that is > helpful? I can see you've posted something to the list just now. If you need to reconfigure your settings so it mails you, send a mail to gentoo-proxy-maint+h...@lists.gentoo.org to see [0]options. [0] https://www.gentoo.org/get-involved/mailing-lists/instructions.html -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Cross Post due to technical component - Thanks for all the fish
On Tue, Dec 06, 2016 at 09:44:12PM -0500, james wrote: > On 12/06/2016 09:09 PM, M. J. Everitt wrote: > > >> James > >> > > With the creation of the Mentors project > > (https://wiki.gentoo.org/wiki/Project:Mentors) a bit of clarification > > has occurred to help prospective developers outside the IRC and/or > > proxy-maintainers project). > > Am I to understand that the 'Mentors' are a pathway to gaining > gentoo-dev status (still the same requirements) but I do not have to use > IRC to communicate with whomever? In order to become a Gentoo developer you do need a mentor[0]. If instead you're only looking to proxy-maintain a package(s), you can work either through the Proxy Maintainers project or directly with a developer (if they're the maintainer). > If so; Halaluyah! and count me in. I hate irc, with a passion, just so > you know. How you communicate with your mentor is up to you and your mentor. Going through the recruitment [0]process does require a review session which, as far as I know, is only held on IRC, but otherwise it's up to you to organise what medium you use. > > The Recruiters project page contains links > > to the current quizzes (linked therein). > > > > hth. > > > > On this page, the string 'quiz' occurs (3) times. I find no links to the > current quizes? > > Did I miss something? The links to the quizzes are [1]here. [0] https://wiki.gentoo.org/wiki/Project:Recruiters#What_does_the_recruitment_process_involve.3F [1] https://wiki.gentoo.org/wiki/Project:Recruiters#Current_quizzes -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Cross Post due to technical component - Thanks for all the fish
On Wed, Dec 07, 2016 at 01:17:54PM +1100, Sam Jorna wrote: > have a look at the new [0]Mentors project, or even send a mail to -dev I forgot the link, sorry: [0] https://wiki.gentoo.org/wiki/Project:Mentors -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Cross Post due to technical component - Thanks for all the fish
On Tue, Dec 06, 2016 at 08:59:11PM -0500, james wrote: > On 12/06/2016 07:29 PM, Robin H. Johnson wrote: > > On Tue, Dec 06, 2016 at 01:13:12PM -0500, james wrote: > >> A while back, we we were promised an email channel for gentoo-proxy > >> folks that did not get on well with IRC. It never materialized, > > The mail alias proxy-ma...@gentoo.org (same alias as proxy-maintainers@) > > has 22 people on it. It was created 2013/09/26. > > > > The list gentoo-proxy-ma...@lists.gentoo.org was created 2016/05/29. > > I don't see much usage of it, nobody has emailed since August. > > https://archives.gentoo.org/gentoo-proxy-maint/ > > > > The request for it was filed and tracked here: > > https://bugs.gentoo.org/show_bug.cgi?id=581370 > > > > How exactly is that never materialized? > > > > > I subscribe on 6/23/2016:: > > From:: gentoo-proxy-maint+h...@lists.gentoo.org > This is the correct address and as it noted, you should get a confirmation/welcome email when you've successfully subscribed. Did you get this? Keep in mind, also, that as Robin noted above, the list has been very quiet and will remain that way until people start using it. > So I just now sent email to : > proxy-maint+subscr...@gentoo.org This is not the mailing list address, but the alias for the Proxy Maintainers project - you can't subscribe to this. That being said, I couldn't see this email in my client. > NO answer on this attempt. ON this page:: > https://www.gentoo.org/get-involved/mailing-lists/all-lists.html The gentoo-proxy-maint mailing list was indeed missing from that list and has just been added thanks to Robin. > Oh yea, I emailed those quizes timely to one of the devs I was working > with, and got no answer. (sorry, not going to identify that dev). So I > prefer to answer the latest quizes; you guys can figure out who I > should send those to. It's unfortunate that this happened. As for whom to send your quizzes to, they would go to your mentor. If you don't have a mentor, try approaching a developer with whom you've been working and see if they will be able to. Alternatively, you can have a look at the new [0]Mentors project, or even send a mail to -dev asking for one. I look forward to having another contributor among the ranks. :) -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] RFC: Proposal for addition of distribution variables
On Sun, Dec 04, 2016 at 09:13:23PM -0600, A. Wilcox wrote: > to read over it. (Would it be more desirable to have all changes in a > single large commit, or one commit per package?) I'd think this is one of those cases best suited to a branch and merge commit - best of both worlds. But that's just my two cents. :) -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Please retain authorship of contributed patches
On Wed, Nov 30, 2016 at 09:23:56PM +, Andrey Utkin wrote: > The difference between my submission and final variant by Matthew is big > in number of lines, but is trivial in content as you can see below, so I > don't believe that Matthew has written his variant from scratch on his > own (he hasn't given any note on tickets on bugs.g.o or github), it > seems more like intentional swapping and amending original lines > retaining identical outcome. > > Not that authorship of one or two commits is so crucial for me, or that > I'm the most ambitious wannabe-contributor. Hell, there's not much of > code at all in the ebuild - it's trivial; but also not much is needed > here to give credit. I have contributed to quite some FOSS projects, and > have run into theft of my patches a couple of times, and it never was by > pure accident. Though I wasn't involved in these commits, I have seen how easy and accidental it is to lose authorship information on a commit. That being said, finding where to draw the line on authorship can be difficult. I'm not sure how many others are aware of this, but I'll mention it just in case: provided it's done before pushing commits, the commit metadata and message can be amended locally with git commit --amend --author="Joe Smith " This will update the Author tag but leave the Committer tag untouched (and will allow fixing any problems with the commit message itself). Amending commits that are not the tip of your local clone will probably need an interactive rebase though (but I could be wrong about that). -- Sam Jorna (wraeth) GPG ID: 0xD6180C26 signature.asc Description: Digital signature
Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)
On 09/06/16 15:31, NP-Hardass wrote: > 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. I'd also like to expand on this a little further to point out that we have recently enacted a policy to help track/list what a given contributor actually contributes to through the use of bugs[0,1] which could be beneficial to someone's application to the recruiters. Note that this isn't intended as a replacement for the recruitment process. That being said, there are still a lot of bugs and PR's to be done, so we would welcome any new members wishing to help facilitate user contributions! [0] https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Managing_Requests [1] https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Maintainer_Bugs_and_Maintainership_Requests Cheers; -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: OpenPGP digital signature
Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)
On 09/06/16 09:08, Andreas K. Huettel wrote: > >> This could lead to a future where the Gentoo tree is largely >> superseded. Every user would just have their own repository, where >> they could pick and choose packages from other users. The Gentoo tree >> would just focus on a high-quality repository of the basic/core things >> that everybody needs. Gentoo devs would spend most of their time >> maintaining curated small and useful repositories. > > [...] > >> The final step is the most difficult (but then again we might never >> get so far). It is two-fold. First we make the core/base repository. >> Then we identify important subsets that can be logically separated >> into repositories, and do this. > > > Sigh. Every 2 years somebody else comes up with the same silly idea. > > 1) Who defines what everybody needs? > 2) How do you enforce security and/or qa requirements on the rest? > 3) Will you allow non-core dependencies? What guarantees are made there? > 4) How do you make sure that different split-out repos actually work together? > 5) "logically separated subsets" means either "loss of functionality" or > "impossible to do" > > Independent of how many magic tools you whip up this will be a significant > step down in functionality and quality, and a big step towards a big > unmanageable steaming pile of cr... Even excepting the significant technical issues such as dependencies and security issues, even something as simple as versioning, if interpreted differently between users, could prove difficult to overcome. Not to mention SLOTting... -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] The future of the Sunrise project
On 07/06/16 19:29, Anthony G. Basile wrote: > Its time to retire the project. Put out a last call for anyone to adopt > it. If not, then freeze commits but leave the repo open as an archive. > Anyone who wants to scavenge ebuilds from it can do so. This seems reasonable - it allows packages that people want actively maintained to be picked up, and still leaves the rest available in the overlay outside of gentoo.git so they don't cause any major dramas. -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Lastrites: sci-geosciences/qlandkartegt{,-garmindev}
# Sam Jorna (24 May 2016) # Deprecated in favour of sci-geosciences/qmapshack. # See bugs 561788 and 582262 # Masked for removal in 30 days. sci-geosciences/qlandkartegt sci-geosciences/qlandkartegt-garmindev -- Sam Jorna GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] new developers' keyword requests
On Sat, May 21, 2016 at 10:09:04AM +0800, Ian Delaney wrote: > On Fri, 20 May 2016 16:00:02 +0200 > Jeroen Roovers wrote: > > > On Thu, 19 May 2016 18:36:22 -0700 > > Daniel Campbell wrote: > > > > > To make sure I understand what you're getting at, are you saying > > > some devs get on board and then request to add keywords to packages > > > that they already maintain? If said arches are already supported in > > > Gentoo I see little problem with that, especially if they intend on > > > being part of the arch testing team for that arch or have access to > > > the hardware. > > > > I am not talking about adding architecture keywords to profiles/. > > I am talking about adding architecture keywords to ebuilds. > > > > > > Regards, > > jer > > > > Firstly I think previous replies have been de-railed on talking about > new alternate arches, which personally I think is the last thing we > need. If there is any confusion it is because the term keyword, like > most terms in I.T. gets pushed and pulled and stretched until it breaks. > To my understanding, KEYWORDS are arches. But being told to 'keyword' a > package could mean perhaps, well, Hu knows. I don't know of any other usages of "KEYWORDS" within Gentoo - to my knowledge the only definition is a list of which architectures a package is known to work or not work on, and an indication of the level of testing and expected usability on that architecture. Is there some other definition that I'm missing? > Supporting users doing just this lately, I have come across this a few > times. Users and new devs are expected to be very ignorant of minor > arches, and despite having docs already informing them that they are > short staffed and have enough to do, the practicalities of how and why > to keyword request or not are still veiled in mystery. Users want to > keyword according to what they see supported upstream just because > they can. They appear to need it made manually clear to them that there > are qualifiers and conditions for putting something up for keywording. > These also I believe are as much as mystery to users as they are to > devs. Appropriate use of KEYWORDS is actually covered in the Developer quizzes, so I would have instead expected new developers to be more acutely aware of the fact that keywording on minor arches should be generally reserved for an as-needed basis. > How to establish a level of desire form userland to have gentoo > support the arch in the package?? > How to establish sane rationale for it being put up for stable?? > The last I heard was along the lines of, well, only put it up if it has > already been put up in the past.(someone in the past had a check list?) > > If anyone, the members of the arch teams might have some insights based > upon first hand dealing with packages and their categories. Frankly, > how you can expect or achieve users and new devs to assess these is > more the issue, and I do not see there is any obvious path of becoming > informed of the interest of an invisible audience; userland As far as I know, users (as in non-maintainers - those out "in the wild") can file keyword request bugs and it's up to the maintainer to then determine relevancy and CC appropriate arch teams; and Bugzilla has a voting feature[0] allowing users to indicate the strength of community demand by voting on those bugs (which I have seen done previously). [0] https://bugs.gentoo.org/page.cgi?id=fields.html#votes -- Sam Jorna GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Proposal for enhancement to PMS/EAPI7+
On Wed, May 18, 2016 at 05:44:28PM +1200, Kent Fredric wrote: > On 18 May 2016 at 17:40, Ulrich Mueller wrote: > > Only two lines. Do you think this is untidy? > > > It only becomes untidy where you don't already have a src_install. > > Then it becomes 4 lines. > > 4 lines of which 3 are redundant and simply re-codify existing behaviour. Unless you define DOCS and include the default documents, which is an additional 78 characters on one line (excluding any potential globbing, and assuming all default files are wanted). -- Sam Jorna GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] NEW: split portage/repoman releases now in the tree
On Sun, May 15, 2016 at 06:39:22PM -0700, Brian Dolbec wrote: > > portage-2.3.0_rc1 and repoman-2.3.0_rc1 are now in the tree. > I want to thank the following people for their help and contributions > to make these releases: > > Zac Medico > Alexander Bernsten > Dirkjan Ochtman for the base xml re-write code > Michal Gorny for the metadata.xsd changes > Göktürk Yüksek for the metadata.xml test ebuilds > patches. > Mike Gilbert for all the testing on the rewite code, > and a number of gen-b0rk repo test ebuilds. > > Coacher for the recent testing, bug reports and patches. > And anyone else I missed ;) Thank you to everyone involved! :) -- Sam Jorna GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run
On Wed, May 04, 2016 at 10:57:44AM +0200, Kristian Fiskerstrand wrote:
> On 05/04/2016 10:52 AM, Sam Jorna wrote:
> > On Wed, May 04, 2016 at 10:00:05AM +0200, Ulrich Mueller wrote:
> >>>>>>> On Wed, 4 May 2016, Austin English wrote:
> >>
> >>>> Your list of affected packages obtained with "git grep" in the
> >>>> Portage tree will not be complete, since the command won't catch
> >>>> any init scripts installed from elsewhere. You should look for the
> >>>> set of installed files instead.
> >>
> >>> How is that relevant here at all? I'm cleaning up portage installed
> >>> init scripts, [...]
> >>
> >> You are cleaning up only those init scripts that are installed from
> >> FILESDIR, but you will miss the ones that are installed from a file
> >> in SRC_URI.
> >
> > Perhaps an alternate way to do it would be to have a QA check look at
> > any files installed to ${D}etc/init.d/ and throw a warning if their
> > shebang is "#!/sbin/runscript"
> >
>
> A repoman check is a much saner approach, I'm not convinced there is
> sufficient need for this change to begin with, in particular to start
> touching a wide range of packages. Breaking backwards compatibility in
> any way should have a darn good reason, and I haven't seen one yet
I'm not arguing for or against it in general, just in terms of technical
implementation.
That being said, a repoman check would only catch those distributed in
${FILESDIR} as well. My thinking with the above was to also identify
those installed from distfiles to be handled accordingly.
--
Sam Jorna (wraeth)
GnuPG Key: D6180C26
signature.asc
Description: Digital signature
Re: [gentoo-dev] Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run
On Wed, May 04, 2016 at 10:00:05AM +0200, Ulrich Mueller wrote:
> >>>>> On Wed, 4 May 2016, Austin English wrote:
>
> >> Your list of affected packages obtained with "git grep" in the
> >> Portage tree will not be complete, since the command won't catch
> >> any init scripts installed from elsewhere. You should look for the
> >> set of installed files instead.
>
> > How is that relevant here at all? I'm cleaning up portage installed
> > init scripts, [...]
>
> You are cleaning up only those init scripts that are installed from
> FILESDIR, but you will miss the ones that are installed from a file
> in SRC_URI.
Perhaps an alternate way to do it would be to have a QA check look at
any files installed to ${D}etc/init.d/ and throw a warning if their
shebang is "#!/sbin/runscript"
--
Sam Jorna (wraeth)
GnuPG Key: D6180C26
signature.asc
Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-games/mygui/
On Wed, Apr 20, 2016 at 08:57:52AM +0200, Michał Górny wrote: > Just FYI, we're talking about upstream maintainer elements which do not take > part in bug assignment. Ah, yes, I missed that; though it may have been done as something related to that - just putting it out there. Cheers; -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-games/mygui/
On Wed, Apr 20, 2016 at 02:52:24PM +1000, Sam Jorna wrote: > On Mon, Apr 18, 2016 at 05:47:43PM +0200, Michał Górny wrote: > > On Mon, 18 Apr 2016 08:13:34 + (UTC) > > "Patrice Clement" wrote: > > > > > commit: 4f2477ca1ab07969bae57e7b47e8b7a5ba9a6050 > > > Author: Patrice Clement gentoo org> > > > AuthorDate: Mon Apr 18 06:35:31 2016 + > > > Commit: Patrice Clement gentoo org> > > > CommitDate: Mon Apr 18 07:58:13 2016 + > > > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4f2477ca > > ... > > > > - CC on bugs > > > > You're discarding important information here. This also has been > > covered in the GLEP. The suggested solution is to copy the person into > > downstream maintainers with appropriate explanatory description (like > > 'upstream developer wishing to be CC-ed on bugs'). > > Just an FYI: > Members of the Proxy Maintainers project decided that the inclusion of the > element was superfluous and that the ordering of /> > elements was sufficient for determining bug assignment/CC'ing based on the > bug-wranglers policy[0] (which does not explicitly mention ). Forgot the reference (which I probably don't need anyway) but: 0: https://wiki.gentoo.org/wiki/Project:Bug-wranglers#Assigning_bug_reports -- Sam Jorna GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-games/mygui/
On Mon, Apr 18, 2016 at 05:47:43PM +0200, Michał Górny wrote: > On Mon, 18 Apr 2016 08:13:34 + (UTC) > "Patrice Clement" wrote: > > > commit: 4f2477ca1ab07969bae57e7b47e8b7a5ba9a6050 > > Author: Patrice Clement gentoo org> > > AuthorDate: Mon Apr 18 06:35:31 2016 + > > Commit: Patrice Clement gentoo org> > > CommitDate: Mon Apr 18 07:58:13 2016 + > > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4f2477ca ... > > - CC on bugs > > You're discarding important information here. This also has been > covered in the GLEP. The suggested solution is to copy the person into > downstream maintainers with appropriate explanatory description (like > 'upstream developer wishing to be CC-ed on bugs'). Just an FYI: Members of the Proxy Maintainers project decided that the inclusion of the element was superfluous and that the ordering of elements was sufficient for determining bug assignment/CC'ing based on the bug-wranglers policy[0] (which does not explicitly mention ). -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
