Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

[R0b0t1]

On Sat, Sep 9, 2017 at 3:58 AM, Kent Fredric  wrote:
> On Fri, 8 Sep 2017 20:33:49 -0500
> R0b0t1  wrote:
>
>> In any case it is my understanding that the issue is that simple. It's
>> the reason torrents and magnet links exist, and why there are no legal
>> claims possible against websites which host magnet links.
>
> The entire court case against PirateBay was based on that.
>
> And the court case was won against PirateBay
>
> https://en.wikipedia.org/wiki/The_Pirate_Bay_trial#Trial_and_courtroom_charges
>
>> The court found that the defendants were all guilty of accessory to
>> crime against copyright law, strengthened by the commercial and
>> organized nature of the activity.
>

This was normal torrents, not magnet links? Was the complaint retried
against someone else who was hosting a magnet link website?

I suspect the links in ebuilds are more like torrent files, in which
case I think it makes sense to wait to be contacted to remove the
links. Otherwise, lots of other precautions should be taken, such as
disclaiming liability for acts of terrorism perpetrated using Gentoo.

Re: [gentoo-dev] Appropriate location to publish experimental stages for Alt

[Johnson Steward]

Actually it's tougher than it seems to be as I've only succeeded a few
times in successfully
building such a system and tons of efforts to reproduce it failed
(probably because of failing
to take down __exactly__ what I did to make it the first time :/).

I'm still trying to get things right (trying to grab the idea of the
differences between stage[1-4],
and trying to reproduce the build stably). I've CC'ed this thread to
gentoo-...@lists.gentoo.org,
hope that helps.

2017-09-10 7:10 GMT+08:00 Robin H. Johnson :
> On Sat, Sep 09, 2017 at 11:51:27PM +0800, Johnson Steward wrote:
>> I've been messing with Gentoo FreeBSD these days and, finally, got to the
>> current latest version available. As upgrading is really a tiring process
>> (lots and lots and lots of bootstrapping the tool chain and bunches of
>> blocks in the current stages), I'm thinking of sharing my currently working
>> system as a staged for further testing for those who are interested.
> Find a developer on the Gentoo/FreeBSD team ideally, and get the content
> over to Infra.
> Goes to woodpecker:/space/experimental-local/bsd/freebsd/ which will
> mirror out to http://distfiles.gentoo.org/experimental/bsd/freebsd/
>
> Should ideally be all of stage[1234], including CONTENTS and DIGESTS
> files.
>
> --
> Robin Hugh Johnson
> Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer
> E-Mail   : robb...@gentoo.org
> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
> GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

Re: [gentoo-dev] Appropriate location to publish experimental stages for Alt

[Robin H. Johnson]

On Sat, Sep 09, 2017 at 11:51:27PM +0800, Johnson Steward wrote:
> I've been messing with Gentoo FreeBSD these days and, finally, got to the
> current latest version available. As upgrading is really a tiring process
> (lots and lots and lots of bootstrapping the tool chain and bunches of
> blocks in the current stages), I'm thinking of sharing my currently working
> system as a staged for further testing for those who are interested.
Find a developer on the Gentoo/FreeBSD team ideally, and get the content
over to Infra.
Goes to woodpecker:/space/experimental-local/bsd/freebsd/ which will
mirror out to http://distfiles.gentoo.org/experimental/bsd/freebsd/

Should ideally be all of stage[1234], including CONTENTS and DIGESTS
files.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] New eclass vim-runtime

[Aric Belsito]

Hi Patrice,

No problem, thanks for looking at it. I'll get on the #gentoo-vim IRC
channel to discuss things.

I don't have any issues with the review, but I'm debating whether it's a
better idea to use a USE_EXPAND for vim implementations or maybe a
virtual?, and then iterate through those and install to the appropriate
runtime directories -- this was just the simplest and least destructive
implementation I could think of to get the packages in app-vim working
on neovim. (and make it easy to replace
`insinto /usr/share/vim/vimfiles` with `insinto $(vimfiles_directory)`
for packages that include vim syntax.)

On Sat, Sep 09, 2017 at 10:32:56PM +0200, Patrice Clement wrote:
> Hi Aric
> 
> Thanks a lot for your patch.
> 
> We ran a quick survey the other day and found out the Gentoo Vim team is
> basically just radhermit and myself at the moment. Please bear with us if it
> takes some time to get back to you with clear answers.
> 
> I have reviewed your code over at:
> https://github.com/lluixhi/gentoo/commit/cf191a3df28b16a479c1670ce4a6c1dcdbe8846b
> 
> Please have a look at my reviews and let me know.
> 
> I have recently joined the #gentoo-vim IRC channel. Feel free to drop in and
> talk to me and/or other people in the channel. IRC is in my opinion easier to
> discuss and talk about code and you'll get feedback quicker than over email.
> 
> Cheers
> 
> Friday 08 Sep 2017 15:27:24, Aric Belsito wrote :
> > This is really messy at the moment because I'm not sure whether the vim
> > team is interested, and I didn't want to put in the effort if it's just
> > going to be rejected, but I'm posting what I have here to start some
> > kind of discussion.
> > 
> > At the moment functions/other things need to be described, among other
> > issues. I have not yet tested to see if everything is still working with
> > vim, though I believe it works with neovim.
> > 
> > I'm also adding a patch file for vim-plugin.eclass, vim-doc.eclass and
> > vim-spell.eclass
> > 
> > I have a bug open on the bugtracker as well:
> > https://bugs.gentoo.org/612644
> > 
> > -- 
> > Aric Belsito
> 
> > From 08411b7ade20df1138c28b9a70679b7acf350f87 Mon Sep 17 00:00:00 2001
> > From: Aric Belsito 
> > Date: Tue, 5 Sep 2017 14:21:08 -0700
> > Subject: [PATCH] vim-runtime.eclass: new eclass
> > 
> > Gentoo-Bug: https://bugs.gentoo.org/612644
> > ---
> >  eclass/vim-doc.eclass | 40 
> >  eclass/vim-plugin.eclass  | 31 +--
> >  eclass/vim-spell.eclass   |  8 ++--
> >  4 files changed, 39 insertions(+), 40 deletions(-)
> >  create mode 100644 eclass/vim-runtime.eclass
> > 
> > diff --git a/eclass/vim-doc.eclass b/eclass/vim-doc.eclass
> > index 5f281eba25f2..c4fa9ed22a44 100644
> > --- a/eclass/vim-doc.eclass
> > +++ b/eclass/vim-doc.eclass
> > @@ -1,4 +1,4 @@
> > -# Copyright 1999-2011 Gentoo Foundation
> > +# Copyright 1999-2017 Gentoo Foundation
> >  # Distributed under the terms of the GNU General Public License v2
> >  #
> >  # This eclass is used by vim.eclass and vim-plugin.eclass to update
> > @@ -10,22 +10,28 @@
> >  # DEPEND in vim-plugin or by whatever version of vim is being
> >  # installed by the eclass.
> >  
> > +inherit vim-runtime
> > +
> > +run_helptags() {
> > +   # Update tags; need a vim binary for this
> > +   if [[ -n "$1" ]]; then
> > +   einfo "Updating documentation tags in $2"
> > +   DISPLAY= $1 -u NONE -n \
> > +   '+set nobackup nomore' \
> > +   "+helptags $2/doc" \
> > +   '+qa!' /dev/null
> > +   fi
> > +}
> >  
> >  update_vim_helptags() {
> > has "${EAPI:-0}" 0 1 2 && ! use prefix && EROOT="${ROOT}"
> > local vimfiles vim d s
> >  
> > # This is where vim plugins are installed
> > -   vimfiles="${EROOT}"/usr/share/vim/vimfiles
> > +   vimfiles="${EPREFIX}$(vimfiles_directory)"
> >  
> > if [[ $PN != vim-core ]]; then
> > -   # Find a suitable vim binary for updating tags :helptags
> > -   vim=$(type -P vim 2>/dev/null)
> > -   [[ -z "$vim" ]] && vim=$(type -P gvim 2>/dev/null)
> > -   [[ -z "$vim" ]] && vim=$(type -P kvim 2>/dev/null)
> > -   if [[ -z "$vim" ]]; then
> > -   ewarn "No suitable vim binary to rebuild documentation 
> > tags"
> > -   fi
> > +   vim="$(vim_binary)"
> > fi
> >  
> > # Make vim not try to connect to X. See :help gui-x11-start
> > @@ -59,14 +65,16 @@ update_vim_helptags() {
> > fi
> >  
> > # Update tags; need a vim binary for this
> > -   if [[ -n "$vim" ]]; then
> > -   einfo "Updating documentation tags in $d"
> > -   DISPLAY= $vim -u NONE -U NONE -T xterm -X -n -f \
> > -   '+set nobackup nomore' \
> > -   "+helptags $d/doc" \
> > -   '+qa!' /dev/null
> > -   fi
> > +   

Re: [gentoo-dev] Server hardaware give away (misc archs)

[Robin H. Johnson]

On Sat, Sep 09, 2017 at 08:25:17AM -0700, Rich Freeman wrote:
> Obviously there can be a balance.  If the hardware is Foundation owned
For the developers that haven't been around a long time, I'd like to
bring up what happened when zwelch forked Zynot from Gentoo.
zwelch personally owned several systems that were hosted at OSL, for
Gentoo development use. The fork was not amicable, and he took the
systems with him.

What has been done since then, is that the Foundation generally owns the
assets it pays for. Some of the assets even have a 'Property of Gentoo
Foundation' sticker on it. If a developer still has Foundation assets in
their possession when they leave Gentoo, and those assets still have
meaningful value (it could be dead or of no further use), the Foundation
will pay to ship them back to another developer or somewhere useful to
the Foundation.

> On the other hand, if the costs are reasonably low there might not be
> much risk in making some small payments to cover specific activities
> that are likely to benefit Gentoo when the person receiving the
> payments already has a history of doing work for Gentoo.  We print out
> stickers and CDs and hand those out at conferences and we don't ask
> what the recipients do with them.  Not every expenditure has to be
> 100% airtight.
The Foundation has already covered embedded systems and parts for
developers. Here's a quick snippet of the past bugs covering those, for
cases where the hardware does NOT live at OSL:
98733(chriswhite, video card), 
255274(armin76, parts for sh embedded system), 
284517(darkside, ppc embedded system), 
343975(darkside, hdd for arm system)
373241(mattst88, parts for mips system) 
417399(shipping hardware from darkside to blueness)
474774(mattst88, parts for alpha system)

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH] eapi7-ver.eclass: 'Early adopter' version of EAPI 7 version manip

[Kent Fredric]

On Sat, 09 Sep 2017 17:54:52 +0200
Michał Górny  wrote:

> I'm not sure if there's a serious proposal behind all this but I suppose
> it's all just perl-specific insanity that is of no value to everyone
> else.

Yeah, some of the stuff I suggested there are generalisations, because
it doesn't make sense to suggest such a feature and have it be
*excusively* for Perl usage.

Pretty much 100% of our usage would be just the 3-position + truncate form.

So:

  $(ver_fixlen $(ver_3float ${PV}) 3)

Or something would be most of it.

We'd probably just keep doing what we're doing with hard-normalization
+ hard-version-maps, mostly because its more obvious what is going on.

But we do have people who keep wanting something that maps $PV to
upstream, and the existing tools to do that aren't /quite/ ideal.

NB: Above, the simplified tools are:

 ver_fixlen $version $length  

 - ensure everything after first '.' are numbers 
 - make sure there are at most $length characters after '.'
 - if characters over $length limit are not '0', error.
 - truncate extraneous 0's beyond $length limit
 - if the remaining number of digits after the '.' is less than $length, 0-pad


 ver_3float $version

 - assume every group after the first '.' are the range 0-999
 - expand every group to 3 digits , so 0 == 000, 1 == 001, 10 == 010, etc.
 - concatenate all minor groups 
 - emit ${first}.${minor_groups}

I think those two would be all perl people might have a use for.

( Again, wouldn't be something we'd deploy at volume in
perl-module.eclass, would only be for the people who wanted to
simplify their own custom maintenance outside the perl herd )

I really only suggested these sorts of things because I figured "its
going to be in an EAPI? maybe the implementation might be in python?,
doing this sort of thing in python might actually be viable, whereas
its a terrible nightmare to do this kind of string manipulation in bash"

Though I figure its possible to in bash, I'm just not insane enough to
try (yet, getting there)


pgplA2oBvXjL8.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Appropriate location to publish experimental stages for Alt

[R0b0t1]

On Saturday, September 9, 2017, Johnson Steward  wrote:
> Hello,
> I've been messing with Gentoo FreeBSD these days and, finally, got to the
current latest version available. As upgrading is really a tiring process
(lots and lots and lots of bootstrapping the tool chain and bunches of
blocks in the current stages), I'm thinking of sharing my currently working
system as a staged for further testing for those who are interested.
> Yet I can't come up with an appropriate location for the stage4 to be
hosted. 1.4GB is obviously too large for a pastebin even if
bzip2-compressed, and consumer-level cloud storage providers like Google
Drive or OneDrive will create unnecessary chaos when trying to actually
install the system (virtually impossible to interact with that
JavaScript-based system within the FreeBSD livecd), and I don't have an
account for Google Cloud Storage or AWS either.
> Is there a suitable location to host such a stage? I'm currently not a
Gentoo developer, yet I really want my work to benefit the Gentoo FreeBSD
community.
> Thanks,
>
> Johnson Steward

Contact desult...@gentoo.org.

Thank you for your work. There's still lots of things that are harder than
they should be.

Cheers,
R0b0t1

Re: [gentoo-dev] [PATCH] eapi7-ver.eclass: 'Early adopter' version of EAPI 7 version manip

[Michał Górny]

W dniu nie, 10.09.2017 o godzinie 03∶05 +1200, użytkownik Kent Fredric
napisał:
> On Fri,  8 Sep 2017 13:19:23 +0200
> Michał Górny  wrote:
> 
> > a. getting wider review and some real-life testing before
> > the specification is set in stone, and
> 
> Any thoughts on a function that would represent a dotted-decimal style version
> as a floating point string?
> 
> eg: 
> 
>   ver_float 0.1.0-> 0.001
>   ver_float 0.10.0   -> 0.010
>   ver_float 0.100.0  -> 0.100
> 
> That's of course *the most* generic example I can offer, but seeing
> this sort of transformation is commonly needed in the world of perl, I
> thought maybe now is a good time to mention something.
> 
> Sadly, its just the sort of idea that if done wrong, would be no use.
> 
> For instance, sometimes you want:
> 
>ver_float 0.1.0  -> 0.0010
> 
> Or
> 
>ver_float 0.1.1  -> 0.001001
> 
> The two key things here is to know: 
> 
> 1. How many digits each position represents
> 2. The maximum number of digits to represent
> 
> So, some ideas in that regard are:
> 
>ver_float ${INPUT} ${PRECISION}  
> 
> Where the values per position are fixed, so:
> 
> ver_float 0.1 3   -> 0.001
> ver_float 0.1 2   -> INVALD  # fidelity loss by truncation
> ver_float 0.10 2  -> 0.01# permitted because there's no fidelity loss 
> by truncation
> ver_float 0.100 1 -> 0.1 # permitted because there's no fidelity loss 
> by truncation
> ver_float 0.100 2 -> 0.10
> ver_float 0.100 3 -> 0.100
> ver_float 0.101 1 -> INVALID # fidelity loss by truncation
> 
> ver_float 0.1 5   -> 0.00100
> ver_float 0.1.1 5 -> INVALID, need 6 digits to represent 0.1.1 
> 
> ver_float 0.1.1 6 -> 0.001001
> 
> 
> Or say, 
> 
> ver_float ${INPUT} ${PATTERN}
> 
> Where "pattern" is a string like 3-3-3 indicating how to map digits to numbers
> 
>  ver_float 0.1  3-> 0.001
>  ver_float 0.1  2-> 0.01 
>  ver_float 0.1  1-> 0.1
>  ver_float 0.1.13-> # INVALID, no map for '.1'
>  ver_float 0.1.13-3  -> 0.001001
>  ver_float 0.1.10   3-3  -> 0.001010  
>  ver_float 0.1.10   2-2  -> 0.0110
>  ver_float 0.10.10  2-2  -> 0.1010
>  ver_float 0.100.10 2-2  -> # INVALID, can't map "100" into 2 characters
> 
> Though I suspect you'd want both features ...
> 
>  ver_float ${INPUT} ${PATTERN} ${TRUNCATION_LENGTH}
> 
> Because we do need packages where 
> 
>  0.123.10 means 0.1231 
> 
> Either way, much of this is probably a time wasting bad idea.
> 
> But I thought I'd just 
> 
> ( •_•)
> 
> ( •_•)>⌐■-■
> 
> (⌐■_■)
> 
> Float it by you.
> 

I'm not sure if there's a serious proposal behind all this but I suppose
it's all just perl-specific insanity that is of no value to everyone
else.

-- 
Best regards,
Michał Górny

[gentoo-dev] Appropriate location to publish experimental stages for Alt

[Johnson Steward]

Hello,

I've been messing with Gentoo FreeBSD these days and, finally, got to the
current latest version available. As upgrading is really a tiring process
(lots and lots and lots of bootstrapping the tool chain and bunches of
blocks in the current stages), I'm thinking of sharing my currently working
system as a staged for further testing for those who are interested.

Yet I can't come up with an appropriate location for the stage4 to be
hosted. 1.4GB is obviously too large for a pastebin even if
bzip2-compressed, and consumer-level cloud storage providers like Google
Drive or OneDrive will create unnecessary chaos when trying to actually
install the system (virtually impossible to interact with that
JavaScript-based system within the FreeBSD livecd), and I don't have an
account for Google Cloud Storage or AWS either.

Is there a suitable location to host such a stage? I'm currently not a
Gentoo developer, yet I really want my work to benefit the Gentoo FreeBSD
community.

Thanks,

Johnson Steward

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

[Michael Palimaka]

# Michael Palimaka  (09 Sep 2017)
# Requires dead Qt 4. Dead upstream.
# Masked for removal in 30 days.
app-text/kding

Re: [gentoo-dev] Server hardaware give away (misc archs)

[Rich Freeman]

On Sat, Sep 9, 2017 at 7:51 AM, Johnson Steward  wrote:
> Well, I guess the owner of the machines may want them to be under personal
> possession, be taken care of personally and, hopefully, extend the love he
> has with them even though he had to part with them. Sentiment towards old
> friends, you know :)
>

The obvious issue is that the Foundation could spend a lot of money on
shipping/parts/etc for something like this and then the person who
owns the device could decide the next day to not use it for Gentoo.

Obviously there can be a balance.  If the hardware is Foundation owned
and hosted by Infra then it seems pretty obvious that Gentoo should
just foot the bills (and can of course solicit donations to help with
this).  This is basically what already happens with a lot of Infra's
gear, though some of that is also donated so that somebody else is
generously footing the bills.  The Foundation has a planned budget for
these kinds of expenditures and it is largely administered by Infra
(we're not waiting for Trustee meetings to go replacing failed RAID
drives and such).  Pretty much any serious organization handles
routine spending in this way.

On the other hand, if the costs are reasonably low there might not be
much risk in making some small payments to cover specific activities
that are likely to benefit Gentoo when the person receiving the
payments already has a history of doing work for Gentoo.  We print out
stickers and CDs and hand those out at conferences and we don't ask
what the recipients do with them.  Not every expenditure has to be
100% airtight.

I just wouldn't expect the Foundation to pay somebody $2k to buy
hardware for what amounts to their own personal use.

In any case, as was already done you should just submit a bug and ask,
and the trustees can figure out where to draw the line.

-- 
Rich

Re: [gentoo-dev] [PATCH] eapi7-ver.eclass: 'Early adopter' version of EAPI 7 version manip

[Kent Fredric]

On Fri,  8 Sep 2017 13:19:23 +0200
Michał Górny  wrote:

> a. getting wider review and some real-life testing before
> the specification is set in stone, and

Any thoughts on a function that would represent a dotted-decimal style version
as a floating point string?

eg: 

  ver_float 0.1.0-> 0.001
  ver_float 0.10.0   -> 0.010
  ver_float 0.100.0  -> 0.100

That's of course *the most* generic example I can offer, but seeing
this sort of transformation is commonly needed in the world of perl, I
thought maybe now is a good time to mention something.

Sadly, its just the sort of idea that if done wrong, would be no use.

For instance, sometimes you want:

   ver_float 0.1.0  -> 0.0010

Or

   ver_float 0.1.1  -> 0.001001

The two key things here is to know: 

1. How many digits each position represents
2. The maximum number of digits to represent

So, some ideas in that regard are:

   ver_float ${INPUT} ${PRECISION}  

Where the values per position are fixed, so:

ver_float 0.1 3   -> 0.001
ver_float 0.1 2   -> INVALD  # fidelity loss by truncation
ver_float 0.10 2  -> 0.01# permitted because there's no fidelity loss 
by truncation
ver_float 0.100 1 -> 0.1 # permitted because there's no fidelity loss 
by truncation
ver_float 0.100 2 -> 0.10
ver_float 0.100 3 -> 0.100
ver_float 0.101 1 -> INVALID # fidelity loss by truncation

ver_float 0.1 5   -> 0.00100
ver_float 0.1.1 5 -> INVALID, need 6 digits to represent 0.1.1 

ver_float 0.1.1 6 -> 0.001001


Or say, 

ver_float ${INPUT} ${PATTERN}

Where "pattern" is a string like 3-3-3 indicating how to map digits to numbers

 ver_float 0.1  3-> 0.001
 ver_float 0.1  2-> 0.01 
 ver_float 0.1  1-> 0.1
 ver_float 0.1.13-> # INVALID, no map for '.1'
 ver_float 0.1.13-3  -> 0.001001
 ver_float 0.1.10   3-3  -> 0.001010  
 ver_float 0.1.10   2-2  -> 0.0110
 ver_float 0.10.10  2-2  -> 0.1010
 ver_float 0.100.10 2-2  -> # INVALID, can't map "100" into 2 characters

Though I suspect you'd want both features ...

 ver_float ${INPUT} ${PATTERN} ${TRUNCATION_LENGTH}

Because we do need packages where 

 0.123.10 means 0.1231 

Either way, much of this is probably a time wasting bad idea.

But I thought I'd just 

( •_•)

( •_•)>⌐■-■

(⌐■_■)

Float it by you.












pgpP52i6KANoq.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Server hardaware give away (misc archs)

[Johnson Steward]

Well, I guess the owner of the machines may want them to be under personal
possession, be taken care of personally and, hopefully, extend the love he
has with them even though he had to part with them. Sentiment towards old
friends, you know :)

Johnson Steward

2017/09/09 22:39 "William L. Thomson Jr." :

> On Sat, 9 Sep 2017 11:45:23 +0800 (HKT)
> Brendan Horan  wrote:
> >
> > Its all well and good to ask, I don't mind.
> > However systems like this need good , caring owners not a
> > "board/trust " group. I don't mean that in a disrespecting way.
> > They just need a little more attention and up keep.
>
> FYI, it becomes the responsibility of Gentoo Infra not the
> Trustees/Foundation. The board would just facilitate any financial and
> legal/customs. Once the equipment is under Gentoo control. It is handed
> off to infra. Infra maintains the server, controls where it is hosted
> at, etc. They should be able to "take care" of the equipment.
>
> I would not be concerned with Infra caring for the any hardware.
> Physical stuff would be up to the hosting provider. Making sure its not
> on fire, or other.
>
> --
> William L. Thomson Jr.
>

Re: [gentoo-dev] Server hardaware give away (misc archs)

[William L. Thomson Jr.]

On Sat, 9 Sep 2017 11:45:23 +0800 (HKT)
Brendan Horan  wrote:
> 
> Its all well and good to ask, I don't mind.
> However systems like this need good , caring owners not a
> "board/trust " group. I don't mean that in a disrespecting way.
> They just need a little more attention and up keep.

FYI, it becomes the responsibility of Gentoo Infra not the
Trustees/Foundation. The board would just facilitate any financial and
legal/customs. Once the equipment is under Gentoo control. It is handed
off to infra. Infra maintains the server, controls where it is hosted
at, etc. They should be able to "take care" of the equipment.

I would not be concerned with Infra caring for the any hardware.
Physical stuff would be up to the hosting provider. Making sure its not
on fire, or other.

-- 
William L. Thomson Jr.


pgpHNETht1NDX.pgp
Description: OpenPGP digital signature

[gentoo-dev] Last rites: sys-process/procexp

[Michael Palimaka]

# Michael Palimaka  (09 Sep 2017)
# Requires dead Qt 4. Dead upstream. Unmaintained.
# Masked for removal in 30 days.
sys-process/procexp

Re: [gentoo-dev] rust-toolchain.eclass RFC

[Michał Górny]

W dniu sob, 09.09.2017 o godzinie 16∶06 +0200, użytkownik Dirkjan
Ochtman napisał:
> A contributor has written the following eclass:
> 
> https://bugs.gentoo.org/attachment.cgi?id=464900
> 
> This would help extending support for Rust to other arches. As I'm not
> deeply familiar with writing eclasses, I'd welcome any feedback on this
> code. The general idea seems sane to me.
> 

You/he could start by writing documentation in the eclassdoc format, so
we at least would know what we're looking at.

Also, please include the eclass code in the mail next time.

-- 
Best regards,
Michał Górny

[gentoo-dev] rust-toolchain.eclass RFC

[Dirkjan Ochtman]

A contributor has written the following eclass:

https://bugs.gentoo.org/attachment.cgi?id=464900

This would help extending support for Rust to other arches. As I'm not
deeply familiar with writing eclasses, I'd welcome any feedback on this
code. The general idea seems sane to me.

Cheers,

Dirkjan

[gentoo-dev] Last rites: x11-apps/python-whiteboard

[Michael Palimaka]

# Michael Palimaka  (09 Sep 2017)
# Requires dead Qt 4. Dead upstream. Unmaintained.
# Masked for removal in 30 days.
x11-apps/python-whiteboard

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Rich Freeman]

On Sat, Sep 9, 2017 at 3:47 AM, Michał Górny  wrote:
> W dniu pią, 08.09.2017 o godzinie 17∶19 -0400, użytkownik Rich Freeman
> napisał:
>>
>> FYI - if anybody does want to make any comments on the proposed
>> devmanual changes to implement the new tags please comment at:
>>
>> https://github.com/gentoo/devmanual.gentoo.org/pull/72
>>
>
> The footers were discussed to death in this very thread. I've heard your
> opinions. However, as far as I'm concerned (and as I've pointed out) you
> did literally *nothing* to push your ideas forward for 2+ years.
>

So, you read something from my comment that I didn't write, and
ignored the stuff I did write.

In part this is my fault, because I used sarcasm out of frustration,
and that wasn't conducive to communication.

To be clear:

I expressed my opinions earlier in the thread as you pointed out.

I have no expectation that my particular suggestion would be the one
implemented.  If I had felt THAT strongly about the implementation of
this I'd have put it on the Council agenda or something, or at least
would have discussed it in privately with you on IRC or something.
Instead, once I noticed that infra had implemented some of the tag
processing I switched to the format it appeared to be using in my
commits.

I don't expect anybody to wait for 100% consensus before doing
anything around here.  I think I've made that clear in plenty of
posts.  For significant changes there should be discussion on the
lists, and then the implementer should go forward with what they see
as the best implementation based on the feedback received.  If
somebody has a problem with it then it should be their duty to
escalate it and deal with it, not make the maintainer jump through
extra hoops.  Certainly we shouldn't be taking every change to the
Council.

My concern was entirely with the attitude expressed in your comment in
that pull request.  If you had written "I don't think we need to go
back to gentoo-dev for this one because this specific proposal was
part of what was already posted there and none of the feedback really
suggests a major problem with this" it wouldn't have bothered me,
because as the person doing the work I think you should be afforded a
bit more discretion, and this was part of your proposal.

Sometimes posting on -dev elicits opinions we disagree with from
people who haven't done any of the work.  That should neither paralyze
us, nor cause us to scoff at their suggestions.  They're just words.

-- 
Rich

Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon

[Kent Fredric]

On Fri, 8 Sep 2017 20:33:49 -0500
R0b0t1  wrote:

> In any case it is my understanding that the issue is that simple. It's
> the reason torrents and magnet links exist, and why there are no legal
> claims possible against websites which host magnet links.

The entire court case against PirateBay was based on that.

And the court case was won against PirateBay

https://en.wikipedia.org/wiki/The_Pirate_Bay_trial#Trial_and_courtroom_charges

> The court found that the defendants were all guilty of accessory to
> crime against copyright law, strengthened by the commercial and
> organized nature of the activity.



pgpG_n42ZpQNE.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Michał Górny]

W dniu pią, 08.09.2017 o godzinie 17∶19 -0400, użytkownik Rich Freeman
napisał:
> On Tue, Jul 25, 2017 at 4:05 AM, Michał Górny  wrote:
> > 
> > What do you think about it? Is there anything else that needs being
> > covered?
> > 
> 
> FYI - if anybody does want to make any comments on the proposed
> devmanual changes to implement the new tags please comment at:
> 
> https://github.com/gentoo/devmanual.gentoo.org/pull/72
> 
> For that matter, if you want to even know what the proposed changes
> are you should also visit the link.
> 
> List replies seem to be discouraged.
> 
> I realize that some prefer to limit comments to media that are purely
> open source.  I guess the FOSS Linux kernel provided /dev/null still
> exists as an alternative.  Honestly, I'm not sure which of the options
> are more likely to get read.
> 

TL;DR: Rich, I would really appreciate if you stopped the flamebaits.
I understand that you think you're doing Gentoo a favor but you're not.

The footers were discussed to death in this very thread. I've heard your
opinions. However, as far as I'm concerned (and as I've pointed out) you
did literally *nothing* to push your ideas forward for 2+ years.

Since I've done all the work, I've did it my way and for the reasons
I've explained multiple times. If you disagree, them I'm sorry but
in life you don't get to have everything your way. Especially if all you
do is complain and expect others to do the work for you.

I understand that you're unhappy and since you have no valid arguments,
all you can do is try to get more people to support you and shout.
Revive the bikeshed as many times as possible, try to make a lot of
noise and block changes. Worst case, you've blocked something you didn't
like. Best case, you're finally get others so discouraged that they'll
do things your way just so that you stop.

Rich, this is not a kindergarten. It's time you learn to lose,
and accept the consequences. If you can't do that, the door out is open,
and you're free to leave anytime you want.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Re: [PATCH] toolchain-funcs: Respect host vars for tc-getBUILD* when not cross

[Michał Górny]

W dniu pią, 08.09.2017 o godzinie 23∶03 +0100, użytkownik Sergei
Trofimovich napisał:
> On Fri,  8 Sep 2017 10:33:11 +0200
> Michał Górny  wrote:
> 
> > Make tc-getBUILD* functions respect host variables (CC & co.) when
> > not cross-compiling. This removes the necessity of overriding BUILD_*
> > along with the regular variables on the systems that are not concerned
> > about cross-compilation, and does not change the behavior for those
> > which are.
> > 
> > Closes: https://bugs.gentoo.org/630282
> > ---
> >  eclass/toolchain-funcs.eclass | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> > index aeb6f7c70299..75fa638efff3 100644
> > --- a/eclass/toolchain-funcs.eclass
> > +++ b/eclass/toolchain-funcs.eclass
> > @@ -40,7 +40,13 @@ _tc-getPROG() {
> > export ${var}="${prog[*]}"
> > echo "${!var}"
> >  }
> > -tc-getBUILD_PROG() { _tc-getPROG CBUILD "BUILD_$1 $1_FOR_BUILD HOST$1" 
> > "${@:2}"; }
> > +tc-getBUILD_PROG() {
> > +   local vars="BUILD_$1 $1_FOR_BUILD HOST$1"
> > +   # respect host vars if not cross-compiling
> > +   # https://bugs.gentoo.org/630282
> > +   tc-is-cross-compiler || vars+=" $1"
> > +   _tc-getPROG CBUILD "${vars}" "${@:2}"
> > +}
> >  tc-getPROG() { _tc-getPROG CHOST "$@"; }
> >  
> >  # @FUNCTION: tc-getAR
> > -- 
> > 2.14.1
> > 
> 
> Looks good. Worth adding actual ebuild name that failed for you.
> 

No ebuild failed. Just noticed it's not respecting my CC/CXX.

-- 
Best regards,
Michał Górny