Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[M. J. Everitt]

On 05/11/16 04:45, Kent Fredric wrote:
> On Fri, 4 Nov 2016 23:09:07 -0400
> Mike Gilbert  wrote:
>
>> On Fri, Nov 4, 2016 at 9:36 PM, Jonas Stein  wrote:
>>  [...]  
>>>  
>>  [...]  
>>> Yes, that is a good idea.
>>>
>>> cat googlecode-shutdown.txt | cut -f1 -d":" | xargs equery meta -mH |
>>> grep "\@" | sort | uniq | sed "s/@/__/g"
>>>
>>> I prefer to protect the list at least by substitution. It will not help
>>> much, but makes me happier ;-)  
>> Let me know which of the packages I maintain, and I will attempt to
>> update them. I have touched too many packages over the last few years
>> to know them on site.
>>
>> Your sorted list of obfuscated emails does not help at all.
>>
> ( curl http://dev.gentoo.org/~jstein/googlecode-shutdown.txt |  cut -f1 -d":" 
> | while IFS="" read -r arg; do echo -n "$arg: " ; equery meta -mH $arg 
> 2>/dev/null | tr "\n" " "; echo ; done ) | tee /tmp/package_owners.txt
>
> sed 's/:\s*$/: maintainer-needed/;s/\@//g' < /tmp/package_owners.txt > 
> /tmp/owners_obfu.txt
>
> cut -d" " -f 2-  < /tmp/owners_obfu.txt | tr " " "\n" | grep "^\w" | sort | 
> uniq -c | sort -n -k 1  > /tmp/owner_histogram.txt
> ( Attached )
>
> sort -k 2 < /tmp/owners_obfu.txt > /tmp/packages_by_owner.txt
> ( Attached )
>
> grep floppym /tmp/packages_by_owner.txt
> # dev-util/open-vcdiff-0.8.3: floppymgentoo.org 
> # sys-fs/fuse-exfat-1.0.1: floppymgentoo.org base-systemgentoo.org 
> # net-misc/ps3mediaserver-1.82.0: floppymgentoo.org vapiergentoo.org 
>
> tail -n 5 /tmp/owner_historgram.txt
> # 25 javagentoo.org
> # 38 pythongentoo.org
> # 43 proxy-maintgentoo.org
> # 56 maintainer-needed
> # 60 cjkgentoo.org
>
>
Kent+++

I'll have a look-see at the maintainer-needed@ set and see how bad it is.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[Kent Fredric]

On Fri, 4 Nov 2016 23:09:07 -0400
Mike Gilbert  wrote:

> On Fri, Nov 4, 2016 at 9:36 PM, Jonas Stein  wrote:
>  [...]  
> >  
>  [...]  
> >
> > Yes, that is a good idea.
> >
> > cat googlecode-shutdown.txt | cut -f1 -d":" | xargs equery meta -mH |
> > grep "\@" | sort | uniq | sed "s/@/__/g"
> >
> > I prefer to protect the list at least by substitution. It will not help
> > much, but makes me happier ;-)  
> 
> Let me know which of the packages I maintain, and I will attempt to
> update them. I have touched too many packages over the last few years
> to know them on site.
> 
> Your sorted list of obfuscated emails does not help at all.
> 

( curl http://dev.gentoo.org/~jstein/googlecode-shutdown.txt |  cut -f1 -d":" | 
while IFS="" read -r arg; do echo -n "$arg: " ; equery meta -mH $arg 
2>/dev/null | tr "\n" " "; echo ; done ) | tee /tmp/package_owners.txt

sed 's/:\s*$/: maintainer-needed/;s/\@//g' < /tmp/package_owners.txt > 
/tmp/owners_obfu.txt

cut -d" " -f 2-  < /tmp/owners_obfu.txt | tr " " "\n" | grep "^\w" | sort | 
uniq -c | sort -n -k 1  > /tmp/owner_histogram.txt
( Attached )

sort -k 2 < /tmp/owners_obfu.txt > /tmp/packages_by_owner.txt
( Attached )

grep floppym /tmp/packages_by_owner.txt
# dev-util/open-vcdiff-0.8.3: floppymgentoo.org 
# sys-fs/fuse-exfat-1.0.1: floppymgentoo.org base-systemgentoo.org 
# net-misc/ps3mediaserver-1.82.0: floppymgentoo.org vapiergentoo.org 

tail -n 5 /tmp/owner_historgram.txt
# 25 javagentoo.org
# 38 pythongentoo.org
# 43 proxy-maintgentoo.org
# 56 maintainer-needed
# 60 cjkgentoo.org


dev-libs/liblouis-2.5.3: accessibilitygentoo.org 
app-accessibility/emacspeak-39.0-r2: accessibilitygentoo.org 
gnu-emacsgentoo.org 
dev-python/platinfo-0.15.0-r1: aidecoegentoo.org pythongentoo.org 
sci-mathematics/geogebra-4.1.120.0: amynkagentoo.org 
x11-misc/tint2-0.11-r2: amynkagentoo.org 
media-libs/lib3ds-1.3.0-r1: amynkagentoo.org gamesgentoo.org 
3dprintgentoo.org 
media-libs/lib3ds-2.0.0_rc1: amynkagentoo.org gamesgentoo.org 
3dprintgentoo.org 
dev-python/ipaddr-2.1.10-r1: andreis.vinogradovsgmail.com 
maksbotangentoo.org proxy-maintgentoo.org pythongentoo.org 
net-misc/linux-eoip-0.5: andreis.vinogradovsgmail.com 
pinkbytegentoo.org proxy-maintgentoo.org 
games-misc/fortune-mod-gentoo-ru-0.25: andreis.vinogradovsgmail.com 
proxy-maintgentoo.org 
games-misc/fortune-mod-gentoo-ru-0.26: andreis.vinogradovsgmail.com 
proxy-maintgentoo.org 
dev-util/plan9port-20140306: andy753421gmail.com bluenessgentoo.org 
proxy-maintgentoo.org 
dev-util/plan9port-20140306-r1: andy753421gmail.com bluenessgentoo.org 
proxy-maintgentoo.org 
dev-util/plan9port-20140306-r2: andy753421gmail.com bluenessgentoo.org 
proxy-maintgentoo.org 
app-i18n/fcitx-anthy-0.1.1: arfrever.ftagmail.com cjkgentoo.org 
app-i18n/fcitx-chewing-0.2.0: arfrever.ftagmail.com cjkgentoo.org 
app-i18n/fcitx-cloudpinyin-0.3.1: arfrever.ftagmail.com cjkgentoo.org 
app-i18n/fcitx-configtool-0.4.6: arfrever.ftagmail.com cjkgentoo.org 
app-i18n/fcitx-hangul-0.2.1: arfrever.ftagmail.com cjkgentoo.org 
app-i18n/fcitx-libpinyin-0.2.1: arfrever.ftagmail.com cjkgentoo.org 
app-i18n/fcitx-sunpinyin-0.4.0: arfrever.ftagmail.com cjkgentoo.org 
app-i18n/fcitx-table-extra-0.3.3: arfrever.ftagmail.com cjkgentoo.org 
app-i18n/fcitx-unikey-0.2.0: arfrever.ftagmail.com cjkgentoo.org 
app-i18n/mozc-1.10.1390.102-r1: arfrever.ftagmail.com cjkgentoo.org 
app-i18n/mozc-1.13.1651.102: arfrever.ftagmail.com cjkgentoo.org 
app-i18n/mozc-2.16.2037.102: arfrever.ftagmail.com cjkgentoo.org 
app-i18n/fcitx-rime-0.2.0: arfrever.ftagmail.com dlangentoo.org 
cjkgentoo.org 
net-libs/serf-1.3.8: arfrever.ftagmail.com proxy-maintgentoo.org 
net-libs/serf-1.3.8-r1: arfrever.ftagmail.com proxy-maintgentoo.org 
dev-games/aseprite-0.9.5-r1: azamat.hackimovgmail.com 
proxy-maintgentoo.org 
sys-apps/mtree-1.0.1: base-systemgentoo.org 
sys-apps/mtree-1.0: base-systemgentoo.org 
net-libs/pacparser-1.3.1: bicataligentoo.org 
net-proxy/torsocks-1.2-r2: bluenessgentoo.org 
dev-libs/leveldb-1.10.0-r1: bugsbergstroem.nu patrickgentoo.org 
proxy-maintgentoo.org 
dev-libs/leveldb-1.11.0-r1: bugsbergstroem.nu patrickgentoo.org 
proxy-maintgentoo.org 
dev-libs/leveldb-1.12.0-r1: bugsbergstroem.nu patrickgentoo.org 
proxy-maintgentoo.org 
dev-libs/leveldb-1.13.0-r1: bugsbergstroem.nu patrickgentoo.org 
proxy-maintgentoo.org 
dev-libs/leveldb-1.14.0: bugsbergstroem.nu patrickgentoo.org 
proxy-maintgentoo.org 
dev-libs/leveldb-1.15.0: bugsbergstroem.nu patrickgentoo.org 
proxy-maintgentoo.org 
dev-libs/leveldb-1.15.0-r1: bugsbergstroem.nu patrickgentoo.org 
proxy-maintgentoo.org 
dev-libs/leveldb-1.9.0-r5: bugsbergstroem.nu patrickgentoo.org 
proxy-maintgentoo.org 
dev-libs/leveldb-1.9.0-r6: bugsbergstroem.nu patrickgentoo.org 
proxy-maintgentoo.org 
net-misc/openr2-1.3.0: chainsawgentoo.org 
app-benchmarks/i7z-0.27.2: chewigentoo.org 
dev-libs/re2-0_p20130115: chromiumgentoo.org 
dev-libs/re2-0_p20130115-r1: 

Re: [gentoo-dev] newsitem: important fstab update

[Christopher Head]

On Thu, 27 Oct 2016 10:25:39 -0400
Rich Freeman  wrote:

> It would be nice if standards like USB incorporated some kind of GUID.
> I ended up having to write a udev rule for a pl2303 RS232 adapter to
> tie it to a specific USB port precisely so that I could have more than
> one and know which one talked to which device.
> 
> I'd argue that the udev network interface names were a better (if
> painful to transition to) solution to a problem created by somebody
> else.  Being able to use wildcards in configuration files is probably
> an adequate solution for those who are using a single device.
> 

You mean like a device serial number? Which is totally part of the USB
standard, but many devices don’t bother to include one because they
would have to be serially programmed in the factory? If your device has
a serial number, you can generally see it as a udev attribute and use
it to set up meaningful persistent names for multiple
otherwise-identical devices.
-- 
Christopher Head


pgphi7PNcCbPu.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[Mike Gilbert]

On Fri, Nov 4, 2016 at 9:36 PM, Jonas Stein  wrote:
>>> If you maintain one of these packages, please fix the SRC_URI and
>>> HOMEPAGE variables.
>
>> It would probably be better if the output included the maintainer.
>
> Yes, that is a good idea.
>
> cat googlecode-shutdown.txt | cut -f1 -d":" | xargs equery meta -mH |
> grep "\@" | sort | uniq | sed "s/@/__/g"
>
> I prefer to protect the list at least by substitution. It will not help
> much, but makes me happier ;-)

Let me know which of the packages I maintain, and I will attempt to
update them. I have touched too many packages over the last few years
to know them on site.

Your sorted list of obfuscated emails does not help at all.

Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[Jonas Stein]

>> If you maintain one of these packages, please fix the SRC_URI and
>> HOMEPAGE variables.

> It would probably be better if the output included the maintainer.

Yes, that is a good idea.

cat googlecode-shutdown.txt | cut -f1 -d":" | xargs equery meta -mH |
grep "\@" | sort | uniq | sed "s/@/__/g"

I prefer to protect the list at least by substitution. It will not help
much, but makes me happier ;-)

Best,
Jonas

=

3dprint__gentoo.org
accessibility__gentoo.org
aidecoe__gentoo.org
amynka__gentoo.org
andreis.vinogradovs__gmail.com
andy753421__gmail.com
arfrever.fta__gmail.com
azamat.hackimov__gmail.com
base-system__gentoo.org
bicatali__gentoo.org
blueness__gentoo.org
chainsaw__gentoo.org
chewi__gentoo.org
chromium__gentoo.org
chutzpah__gentoo.org
cjk__gentoo.org
cluster__gentoo.org
cpp__gentoo.org
crypto__gentoo.org
desktop-misc__gentoo.org
dev-zero__gentoo.org
dirk.vdb__gmail.com
dlan__gentoo.org
dominik.kriegner+gentoo__gmail.com
dotnet__gentoo.org
DuPol__gmx.de
embedded__gentoo.org
ercpe__gentoo.org
floppym__gentoo.org
fonts__gentoo.org
forensics__gentoo.org
freedesktop-bugs__gentoo.org
games__gentoo.org
gienah__gentoo.org
givi-zurabovich__mail.ru
gnu-emacs__gentoo.org
god__politeia.in
graphics__gentoo.org
grozin__gentoo.org
hanno__gentoo.org
haskell__gentoo.org
hwoarang__gentoo.org
hypnos75__gmail.com
idl0r__gentoo.org
ikelos__gentoo.org
java__gentoo.org
jlec__gentoo.org
johu__gentoo.org
jstein__gentoo.org
kde__gentoo.org
kensington__gentoo.org
leechcraft__gentoo.org
maksbotan__gentoo.org
matthias__dsx.at
media-video__gentoo.org
mgorny__gentoo.org
ml__gentoo.org
monsieurp__gentoo.org
mrueg__gentoo.org
mysql-bugs__gentoo.org
naota__gentoo.org
net-mail__gentoo.org
netmon__gentoo.org
nikoli__gmx.us
nils__nils-andresen.de
office__gentoo.org
oleg__kaa.org.ua
ottxor__gentoo.org
pacho__gentoo.org
patrick__gentoo.org
perl__gentoo.org
phajdan.jr__gentoo.org
php-bugs__gentoo.org
pinkbyte__gentoo.org
polynomial-c__gentoo.org
proaudio__gentoo.org
prometheanfire__gentoo.org
proxy-maint__gentoo.org
python__gentoo.org
qt__gentoo.org
radhermit__gentoo.org
rafaelmartins__gentoo.org
rhill__gentoo.org
rini17__gmail.com
robbat2__gentoo.org
sautier.louis__gmail.com
scheme__gentoo.org
sci-biology__gentoo.org
sci-chemistry__gentoo.org
sci__gentoo.org
sci-mathematics__gentoo.org
sergio.rodriguez.inclan__gmail.com
shell-tools__gentoo.org
slawomir.nizio__sabayon.org
slis__gentoo.org
slyfox__gentoo.org
sound__gentoo.org
spiderx__spiderx.dp.ua
tcltk__gentoo.org
tex__gentoo.org
tomboy64__sina.cn
tomka__gentoo.org
vapier__gentoo.org
vikraman__gentoo.org
vim__gentoo.org
virtualization__gentoo.org
volkris__gmail.com
web-apps__gentoo.org
williamh__gentoo.org
xfce__gentoo.org
xmw__gentoo.org
zerochaos__gentoo.org
ziapannocchia__gmail.com
zlg__gentoo.org

Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[M. J. Everitt]

On 05/11/16 01:20, Rich Freeman wrote:
> On Fri, Nov 4, 2016 at 8:30 PM, M. J. Everitt  wrote:
>> Apologies, getting ahead of myself here .. there must be a portage
>> utility, but I've forgotten which one interrogates metadata .. I'll
>> defer to a more authoritative source ...
>>
> There might be a command line utility if you're doing things the shell way.
>
> But, from that python script I linked the relevant part is:
>
> from portage.xml.metadata import MetaDataXML
>
> metxml = path+"/"+category+"/"+pkgname+"/metadata.xml"
> maints=[]
> try:
>   pkg_md = MetaDataXML(metxml,"/usr/portage/metadata/herds.xml")
>   for maint in pkg_md.maintainers():
>   maints.append(maint.email)
> except IOError: pass
>
> Just feed that api call with a metadata.xml.  Hopefuly it works with
> the projects.xml syntax as herds.xml is of course defunct.I'd
> check the portage API docs as there might be some improvements there.
>
> The portage api is actually fairly powerful and far superior to a lot
> of stuff that gets done with grep.  It just needs a bit of time
> getting used to it since there aren't a lot of docs/examples/etc
> floating around.  The script that came out of was designed to find
> packages that depend on packages that expose subslots but which don't
> define slot operator deps.  Granted, not everything in that list
> should be using them, and by now I imagine it is almost entirely false
> positives, but it shows the sort of thing you can do with a couple of
> lines of python that would be an incredible pain to do any other way.
> I believe paludis also exposes some APIs that probably could also be
> used.
>
Bit beyond my python-fu .. but I get where you're going with that. If I
wasn't banging my head against cups/hplip, I might give it a shot ... :P !!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[Jonas Stein]

> Apologies, getting ahead of myself here .. there must be a portage
> utility, but I've forgotten which one interrogates metadata .. I'll
> defer to a more authoritative source ...

You can try to fetch the maintainers per package with
equery meta -mH foo/bar

Best,

-- 
Jonas

Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[Rich Freeman]

On Fri, Nov 4, 2016 at 8:30 PM, M. J. Everitt  wrote:
> Apologies, getting ahead of myself here .. there must be a portage
> utility, but I've forgotten which one interrogates metadata .. I'll
> defer to a more authoritative source ...
>

There might be a command line utility if you're doing things the shell way.

But, from that python script I linked the relevant part is:

from portage.xml.metadata import MetaDataXML

metxml = path+"/"+category+"/"+pkgname+"/metadata.xml"
maints=[]
try:
  pkg_md = MetaDataXML(metxml,"/usr/portage/metadata/herds.xml")
  for maint in pkg_md.maintainers():
  maints.append(maint.email)
except IOError: pass

Just feed that api call with a metadata.xml.  Hopefuly it works with
the projects.xml syntax as herds.xml is of course defunct.I'd
check the portage API docs as there might be some improvements there.

The portage api is actually fairly powerful and far superior to a lot
of stuff that gets done with grep.  It just needs a bit of time
getting used to it since there aren't a lot of docs/examples/etc
floating around.  The script that came out of was designed to find
packages that depend on packages that expose subslots but which don't
define slot operator deps.  Granted, not everything in that list
should be using them, and by now I imagine it is almost entirely false
positives, but it shows the sort of thing you can do with a couple of
lines of python that would be an incredible pain to do any other way.
I believe paludis also exposes some APIs that probably could also be
used.

-- 
Rich

Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[M. J. Everitt]

On 05/11/16 00:23, M. J. Everitt wrote:
> On 05/11/16 00:20, Rich Freeman wrote:
>> On Fri, Nov 4, 2016 at 7:54 PM, Jonas Stein  wrote:
>>> If you maintain one of these packages, please fix the SRC_URI and
>>> HOMEPAGE variables.
>>>
>> It would probably be better if the output included the maintainer.
>> Hopefully this isn't using anything deprecated, but you should be able
>> to steal from this:
>> https://github.com/rich0/finddepslotops/blob/master/finddepslotops.py
>>
>> Somebody else might have something more up-to-date to use.
>>
> Yeah that's not the best qgrep output for this target ... ;P
>
Apologies, getting ahead of myself here .. there must be a portage
utility, but I've forgotten which one interrogates metadata .. I'll
defer to a more authoritative source ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[M. J. Everitt]

On 05/11/16 00:20, Rich Freeman wrote:
> On Fri, Nov 4, 2016 at 7:54 PM, Jonas Stein  wrote:
>> If you maintain one of these packages, please fix the SRC_URI and
>> HOMEPAGE variables.
>>
> It would probably be better if the output included the maintainer.
> Hopefully this isn't using anything deprecated, but you should be able
> to steal from this:
> https://github.com/rich0/finddepslotops/blob/master/finddepslotops.py
>
> Somebody else might have something more up-to-date to use.
>
Yeah that's not the best qgrep output for this target ... ;P



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[Rich Freeman]

On Fri, Nov 4, 2016 at 7:54 PM, Jonas Stein  wrote:
>
> If you maintain one of these packages, please fix the SRC_URI and
> HOMEPAGE variables.
>

It would probably be better if the output included the maintainer.
Hopefully this isn't using anything deprecated, but you should be able
to steal from this:
https://github.com/rich0/finddepslotops/blob/master/finddepslotops.py

Somebody else might have something more up-to-date to use.

-- 
Rich

[gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[Jonas Stein]

Dear all,

Google announced in 2015 to close the "Google Code" repositories [1].

They will provide the repositories in read only state till end of 2016.

Today we have still 524 ebuilds with SRC_URI=*googlecode* in the tree
[2] and should get these fixed before end of 2016.

If you maintain one of these packages, please fix the SRC_URI and
HOMEPAGE variables.

We have also a wiki page [3] and thanks to Andreas Huettel we can
monitor our daily effort in a plot [4].

[1]
http://google-opensource.blogspot.de/2015/03/farewell-to-google-code.html
[2] http://dev.gentoo.org/~jstein/googlecode-shutdown.txt
[3] https://wiki.gentoo.org/wiki/Shutdown_of_google_code
[4] http://www.akhuettel.de/~huettel/plots/googlecode.php

-- 
Best,
Jonas

Re: [gentoo-portage-dev] portage-2.3.2 stable request?

[Zac Medico]

On 11/04/2016 03:55 PM, Zac Medico wrote:
> On 11/04/2016 03:47 PM, Brian Dolbec wrote:
>> On Fri, 4 Nov 2016 13:53:02 -0700
>> Zac Medico  wrote:
>>
>>> On 11/04/2016 01:43 PM, Michał Górny wrote:
 On Fri, 4 Nov 2016 13:19:39 -0700
 Zac Medico  wrote:
   
> On 11/04/2016 01:14 PM, Brian Dolbec wrote:  
>> On Thu, 3 Nov 2016 15:55:23 -0700
>> Zac Medico  wrote:
>> 
>>> In about a week, portage-2.3.2 will be eligible for a stable
>>> request.
>>>
>>> The only potential problem that I've noticed is the complaint
>>> about changes from bug 552814 causing issues for people using
>>> git sync with overlay filesystems, but setting sync-depth = 0
>>> gives those users a workaround. There's also bug 597838, about
>>> the sync-depth setting being ineffective, but I only know of a
>>> couple of people that have been able to reproduce that.
>>>
>>> So, do we want to do a stable request portage-2.3.2 when the time
>>> comes?
>>
>> I'm not sure.  Do we -r1 it adding a patch or two and ask it be
>> stabled? 
>
> There are just 4 commits since 2.3.2, and they all look good.
> Maybe we should just cut a 2.3.3 release and wait another 30 days
> (we also need to stabilize app-crypt/gkeys since it's needed by
> emerge-webrsync now).  

 Wouldn't it be better to have a really working version of gkeys
 before it's stabilized? Like one that could be used without having
 to create custom configuration files and/or run it as root?  
>>>
>>> Well, gkeys stabilization is not really mandatory, since
>>> emerge-webrsync has a --insecure option.
>>
>> Why don't I/we work on whatever changes are needed to merge the
>> meta-manifest code to both portage and gkeys.  I'll push out another
>> release.  I also had some initial code that added gkeys use to verify
>> the pkg Manifest file, but I don't know if that is needed still, the
>> meta-manifest system will need to run a verify at the end of the sync.
>>
>> We'll have to poke Robin some more to get some new infra keys setup.
>>
>> If I have to, maybe I'll create some ansible scripts to run the dev
>> seeds update on vulture, transfer it to my system to push --sign to
>> api.g.o or break down and get Kristian to help me get key forwarding
>> better setup so I can do it from vulture.
> 
> Sounds good, but I think we should cut a portage 2.3.3 release before we
> make any more changes. Maybe do a release branch that includes
> everything except the emerge-webrsync change.

Let's just revert the emerge-webrsync patch, so we can tag a 2.3.3
release on the master branch.
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] portage-2.3.2 stable request?

[Zac Medico]

On 11/04/2016 03:47 PM, Brian Dolbec wrote:
> On Fri, 4 Nov 2016 13:53:02 -0700
> Zac Medico  wrote:
> 
>> On 11/04/2016 01:43 PM, Michał Górny wrote:
>>> On Fri, 4 Nov 2016 13:19:39 -0700
>>> Zac Medico  wrote:
>>>   
 On 11/04/2016 01:14 PM, Brian Dolbec wrote:  
> On Thu, 3 Nov 2016 15:55:23 -0700
> Zac Medico  wrote:
> 
>> In about a week, portage-2.3.2 will be eligible for a stable
>> request.
>>
>> The only potential problem that I've noticed is the complaint
>> about changes from bug 552814 causing issues for people using
>> git sync with overlay filesystems, but setting sync-depth = 0
>> gives those users a workaround. There's also bug 597838, about
>> the sync-depth setting being ineffective, but I only know of a
>> couple of people that have been able to reproduce that.
>>
>> So, do we want to do a stable request portage-2.3.2 when the time
>> comes?
>
> I'm not sure.  Do we -r1 it adding a patch or two and ask it be
> stabled? 

 There are just 4 commits since 2.3.2, and they all look good.
 Maybe we should just cut a 2.3.3 release and wait another 30 days
 (we also need to stabilize app-crypt/gkeys since it's needed by
 emerge-webrsync now).  
>>>
>>> Wouldn't it be better to have a really working version of gkeys
>>> before it's stabilized? Like one that could be used without having
>>> to create custom configuration files and/or run it as root?  
>>
>> Well, gkeys stabilization is not really mandatory, since
>> emerge-webrsync has a --insecure option.
> 
> Why don't I/we work on whatever changes are needed to merge the
> meta-manifest code to both portage and gkeys.  I'll push out another
> release.  I also had some initial code that added gkeys use to verify
> the pkg Manifest file, but I don't know if that is needed still, the
> meta-manifest system will need to run a verify at the end of the sync.
> 
> We'll have to poke Robin some more to get some new infra keys setup.
> 
> If I have to, maybe I'll create some ansible scripts to run the dev
> seeds update on vulture, transfer it to my system to push --sign to
> api.g.o or break down and get Kristian to help me get key forwarding
> better setup so I can do it from vulture.

Sounds good, but I think we should cut a portage 2.3.3 release before we
make any more changes. Maybe do a release branch that includes
everything except the emerge-webrsync change.
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] portage-2.3.2 stable request?

[Brian Dolbec]

On Fri, 4 Nov 2016 13:53:02 -0700
Zac Medico  wrote:

> On 11/04/2016 01:43 PM, Michał Górny wrote:
> > On Fri, 4 Nov 2016 13:19:39 -0700
> > Zac Medico  wrote:
> >   
> >> On 11/04/2016 01:14 PM, Brian Dolbec wrote:  
> >>> On Thu, 3 Nov 2016 15:55:23 -0700
> >>> Zac Medico  wrote:
> >>> 
>  In about a week, portage-2.3.2 will be eligible for a stable
>  request.
> 
>  The only potential problem that I've noticed is the complaint
>  about changes from bug 552814 causing issues for people using
>  git sync with overlay filesystems, but setting sync-depth = 0
>  gives those users a workaround. There's also bug 597838, about
>  the sync-depth setting being ineffective, but I only know of a
>  couple of people that have been able to reproduce that.
> 
>  So, do we want to do a stable request portage-2.3.2 when the time
>  comes?
> >>>
> >>> I'm not sure.  Do we -r1 it adding a patch or two and ask it be
> >>> stabled? 
> >>
> >> There are just 4 commits since 2.3.2, and they all look good.
> >> Maybe we should just cut a 2.3.3 release and wait another 30 days
> >> (we also need to stabilize app-crypt/gkeys since it's needed by
> >> emerge-webrsync now).  
> > 
> > Wouldn't it be better to have a really working version of gkeys
> > before it's stabilized? Like one that could be used without having
> > to create custom configuration files and/or run it as root?  
> 
> Well, gkeys stabilization is not really mandatory, since
> emerge-webrsync has a --insecure option.

Why don't I/we work on whatever changes are needed to merge the
meta-manifest code to both portage and gkeys.  I'll push out another
release.  I also had some initial code that added gkeys use to verify
the pkg Manifest file, but I don't know if that is needed still, the
meta-manifest system will need to run a verify at the end of the sync.

We'll have to poke Robin some more to get some new infra keys setup.

If I have to, maybe I'll create some ansible scripts to run the dev
seeds update on vulture, transfer it to my system to push --sign to
api.g.o or break down and get Kristian to help me get key forwarding
better setup so I can do it from vulture.
-- 
Brian Dolbec 

Re: [gentoo-dev] [PATCH 2/2] cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530

[Maciej Mrozowski]

On piątek, 4 listopada 2016 20:58:23 CET James Le Cuirot wrote:
> On Fri, 4 Nov 2016 13:37:42 +0100
> 
> Alexis Ballier  wrote:
> > On Fri, 4 Nov 2016 12:33:37 +
> > 
> > James Le Cuirot  wrote:
> > > On Fri, 4 Nov 2016 13:20:16 +0100
> > > 
> > > Alexis Ballier  wrote:
> > > > On Thu,  3 Nov 2016 00:52:17 +0100
> > > > 
> > > > Maciej Mrozowski  wrote:
> > > > > From: Maciej Mrozowski 
> > > > > 
> > > > > ---
> > > > > 
> > > > >  eclass/cmake-utils.eclass | 6 +++---
> > > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > > 
> > > > > diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> > > > > index 88d2163..23cc094 100644
> > > > > --- a/eclass/cmake-utils.eclass
> > > > > +++ b/eclass/cmake-utils.eclass
> > > > > @@ -525,13 +525,13 @@ enable_cmake-utils_src_configure() {
> > > > > 
> > > > >   local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
> > > > >   cat > ${toolchain_file} <<- _EOF_ || die
> > > > > 
> > > > > - SET (CMAKE_C_COMPILER $(tc-getCC))
> > > > > - SET (CMAKE_CXX_COMPILER $(tc-getCXX))
> > > > > - SET (CMAKE_Fortran_COMPILER $(tc-getFC))
> > > > > 
> > > > >   SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE
> > > > > 
> > > > > FILEPATH
> > > > 
> > > > Have you tested cross compiling ?
> > > > IIRC toolchain file is used *before* getting those vars from env and
> > > > is used to determine system & compiler type. Without this you get
> > > > bugs like #503216
> > > 
> > > I was dubious (since I filed that bug) but I briefly tested by
> > > cross-compiling media-libs/openal and it worked. I didn't think to
> > > try older CMake versions though. The behaviour might have changed.
> > 
> > could you please send me (in private) build logs with & without the
> > changes please ?
> > 
> > (dont have easy access to a x compile setup atm)
> 
> I diff'd the logs (needed MAKEOPTS="-j1") and they were practically
> identical, save for the expected change in configure arguments. I also
> tested with CMake 2.8 and that worked too. To further convince myself,
> I took the current eclass and loosely reversed the change we made for
> bug #503216. It failed with CMake 3.6 in exactly the same way it failed
> back then. I am therefore happy for this to proceed. Would you agree?

Env way w/ CMake is used (without toolchain file) where I work for a couple of 
years with quite a bunch of exotic cross-compilers so I never doubted it would 
work (with toolchain file lacking CMAKE__COMPILER variable).
The only thing surprised me here was CMake handling CC/CXX var multi-param 
abuse acceptably.

-- 
regards
MM

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-portage-dev] portage-2.3.2 stable request?

[Zac Medico]

On 11/04/2016 01:43 PM, Michał Górny wrote:
> On Fri, 4 Nov 2016 13:19:39 -0700
> Zac Medico  wrote:
> 
>> On 11/04/2016 01:14 PM, Brian Dolbec wrote:
>>> On Thu, 3 Nov 2016 15:55:23 -0700
>>> Zac Medico  wrote:
>>>   
 In about a week, portage-2.3.2 will be eligible for a stable request.

 The only potential problem that I've noticed is the complaint about
 changes from bug 552814 causing issues for people using git sync with
 overlay filesystems, but setting sync-depth = 0 gives those users a
 workaround. There's also bug 597838, about the sync-depth setting
 being ineffective, but I only know of a couple of people that have
 been able to reproduce that.

 So, do we want to do a stable request portage-2.3.2 when the time
 comes?  
>>>
>>> I'm not sure.  Do we -r1 it adding a patch or two and ask it be stabled?
>>>   
>>
>> There are just 4 commits since 2.3.2, and they all look good. Maybe we
>> should just cut a 2.3.3 release and wait another 30 days (we also need
>> to stabilize app-crypt/gkeys since it's needed by emerge-webrsync now).
> 
> Wouldn't it be better to have a really working version of gkeys before
> it's stabilized? Like one that could be used without having to create
> custom configuration files and/or run it as root?

Well, gkeys stabilization is not really mandatory, since emerge-webrsync
has a --insecure option.
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] portage-2.3.2 stable request?

[Michał Górny]

On Fri, 4 Nov 2016 13:19:39 -0700
Zac Medico  wrote:

> On 11/04/2016 01:14 PM, Brian Dolbec wrote:
> > On Thu, 3 Nov 2016 15:55:23 -0700
> > Zac Medico  wrote:
> >   
> >> In about a week, portage-2.3.2 will be eligible for a stable request.
> >>
> >> The only potential problem that I've noticed is the complaint about
> >> changes from bug 552814 causing issues for people using git sync with
> >> overlay filesystems, but setting sync-depth = 0 gives those users a
> >> workaround. There's also bug 597838, about the sync-depth setting
> >> being ineffective, but I only know of a couple of people that have
> >> been able to reproduce that.
> >>
> >> So, do we want to do a stable request portage-2.3.2 when the time
> >> comes?  
> > 
> > I'm not sure.  Do we -r1 it adding a patch or two and ask it be stabled?
> >   
> 
> There are just 4 commits since 2.3.2, and they all look good. Maybe we
> should just cut a 2.3.3 release and wait another 30 days (we also need
> to stabilize app-crypt/gkeys since it's needed by emerge-webrsync now).

Wouldn't it be better to have a really working version of gkeys before
it's stabilized? Like one that could be used without having to create
custom configuration files and/or run it as root?

-- 
Best regards,
Michał Górny



pgpVR3redBmlG.pgp
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] portage-2.3.2 stable request?

[Zac Medico]

On 11/04/2016 01:14 PM, Brian Dolbec wrote:
> On Thu, 3 Nov 2016 15:55:23 -0700
> Zac Medico  wrote:
> 
>> In about a week, portage-2.3.2 will be eligible for a stable request.
>>
>> The only potential problem that I've noticed is the complaint about
>> changes from bug 552814 causing issues for people using git sync with
>> overlay filesystems, but setting sync-depth = 0 gives those users a
>> workaround. There's also bug 597838, about the sync-depth setting
>> being ineffective, but I only know of a couple of people that have
>> been able to reproduce that.
>>
>> So, do we want to do a stable request portage-2.3.2 when the time
>> comes?
> 
> I'm not sure.  Do we -r1 it adding a patch or two and ask it be stabled?
> 

There are just 4 commits since 2.3.2, and they all look good. Maybe we
should just cut a 2.3.3 release and wait another 30 days (we also need
to stabilize app-crypt/gkeys since it's needed by emerge-webrsync now).
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] portage-2.3.2 stable request?

[Brian Dolbec]

On Thu, 3 Nov 2016 15:55:23 -0700
Zac Medico  wrote:

> In about a week, portage-2.3.2 will be eligible for a stable request.
> 
> The only potential problem that I've noticed is the complaint about
> changes from bug 552814 causing issues for people using git sync with
> overlay filesystems, but setting sync-depth = 0 gives those users a
> workaround. There's also bug 597838, about the sync-depth setting
> being ineffective, but I only know of a couple of people that have
> been able to reproduce that.
> 
> So, do we want to do a stable request portage-2.3.2 when the time
> comes?

I'm not sure.  Do we -r1 it adding a patch or two and ask it be stabled?

-- 
Brian Dolbec 

[gentoo-dev] Re: [PATCH 1/2] cmake-utils.eclass: CMake argument passing rework - clean build_rules and toolchain_file files from unrelated stuff (pass to CMake directly) - move some invariant CMake op

[Michael Palimaka]

On 04/11/16 11:55, Maciej Mrozowski wrote:
> On czwartek, 3 listopada 2016 07:31:10 CET Michał Górny wrote:
>> On Thu,  3 Nov 2016 00:52:16 +0100
>>
>> Maciej Mrozowski  wrote:
>>> From: Maciej Mrozowski 
>>>
>>> ---
>>>
>>>  eclass/cmake-utils.eclass | 54
>>>  ++- 1 file changed, 21
>>>  insertions(+), 33 deletions(-)
>>>
>>> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
>>> index 393ee28..88d2163 100644
>>> --- a/eclass/cmake-utils.eclass
>>> +++ b/eclass/cmake-utils.eclass
>>> @@ -517,13 +517,10 @@ enable_cmake-utils_src_configure() {
>>>
>>> includes=""
>>> 
>>> fi
>>> cat > "${build_rules}" <<- _EOF_ || die
>>>
>>> -   SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive 
> manager"
>>> FORCE)> 
>>> SET (CMAKE_ASM_COMPILE_OBJECT "  $
> {includes}
>>> ${CFLAGS}  -o  -c " CACHE STRING "ASM 
> compile
>>> command" FORCE) SET (CMAKE_C_COMPILE_OBJECT "
>>>  ${includes} ${CPPFLAGS}  -o  -c 
> "
>>> CACHE STRING "C compile command" FORCE) SET 
> (CMAKE_CXX_COMPILE_OBJECT
>>> "  ${includes} ${CPPFLAGS}  
> -o
>>>  -c " CACHE STRING "C++ compile command" FORCE) 
> SET
>>> (CMAKE_Fortran_COMPILE_OBJECT " 
> 
>>> ${includes} ${FCFLAGS}  -o  -c " CACHE 
> STRING
>>> "Fortran compile command" FORCE)> 
>>> -   SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE FILEPATH 
> "Archive
>>> index generator" FORCE) -   SET (PKG_CONFIG_EXECUTABLE $(type -P
>>> $(tc-getPKG_CONFIG)) CACHE FILEPATH "pkg-config executable" FORCE)> 
>>> _EOF_
>>> 
>>> local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
>>>
>>> @@ -531,6 +528,8 @@ enable_cmake-utils_src_configure() {
>>>
>>> SET (CMAKE_C_COMPILER $(tc-getCC))
>>> SET (CMAKE_CXX_COMPILER $(tc-getCXX))
>>> SET (CMAKE_Fortran_COMPILER $(tc-getFC))
>>>
>>> +   SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive 
> manager"
>>> FORCE) +SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE 
>>> FILEPATH
>>> "Archive index generator" FORCE)> 
>>> _EOF_
>>> 
>>> if tc-is-cross-compiler; then
>>>
>>> @@ -571,32 +570,29 @@ enable_cmake-utils_src_configure() {
>>>
>>> # in Prefix we need rpath and must ensure cmake gets 
>>> our 
> default
>>> linker path # right ... except for Darwin hosts
>>> IF (NOT APPLE)
>>>
>>> -   SET (CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
>>> -   SET (CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH
>>> "${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/u
>>> sr/$(get_libdir);${EPREFIX}/$(get_libdir)" -CACHE 
>>> STRING "" 
> FORCE)
>>> -
>>> +   SET (CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
>>> +   SET (CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH
>>> "${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/u
>>> sr/$(get_libdir);${EPREFIX}/$(get_libdir)" CACHE STRING "" FORCE)> 
>>> ELSE ()
>>>
>>> -
>>> -   SET(CMAKE_PREFIX_PATH "${EPREFIX}${PREFIX}" CACHE 
>>> STRING "" 
> FORCE)
>>> -   SET(CMAKE_SKIP_BUILD_RPATH OFF CACHE BOOL "" FORCE)
>>> -   SET(CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
>>> -   SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE CACHE BOOL "")
>>> -   SET(CMAKE_INSTALL_RPATH
>>> "${EPREFIX}${PREFIX}/lib;${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/$
>>> {CHOST}/lib;${EPREFIX}/usr/$(get_libdir);${EPREFIX}/$(get_libdir)" CACHE
>>> STRING "" FORCE) -  SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH 
> TRUE CACHE
>>> BOOL "" FORCE) -SET(CMAKE_INSTALL_NAME_DIR "${EPREFIX}$
> {PREFIX}/lib"
>>> CACHE STRING "" FORCE) -
>>> +   SET(CMAKE_PREFIX_PATH "${EPREFIX}${PREFIX}" 
>>> CACHE 
> STRING "" FORCE)
>>> +   SET(CMAKE_SKIP_BUILD_RPATH OFF CACHE BOOL "" 
>>> FORCE)
>>> +   SET(CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
>>> +   SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE CACHE 
>>> BOOL "")
>>> +   SET(CMAKE_INSTALL_RPATH
>>> "${EPREFIX}${PREFIX}/lib;${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/$
>>> {CHOST}/lib;${EPREFIX}/usr/$(get_libdir);${EPREFIX}/$(get_libdir)" CACHE
>>> STRING "" FORCE) +  
>>> SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH 
> TRUE CACHE
>>> BOOL "" FORCE) +SET(CMAKE_INSTALL_NAME_DIR 
>>> "${EPREFIX}$
> {PREFIX}/lib"
>>> CACHE STRING "" FORCE)> 
>>> ENDIF (NOT APPLE)
>>> 
>>> _EOF_
>>> 
>>> fi
>>> 
>>> # Common configure parameters (invariants)
>>>

Re: [gentoo-dev] [PATCH 2/2] cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530

[Alexis Ballier]

On Fri, 4 Nov 2016 12:33:37 +
James Le Cuirot  wrote:

> On Fri, 4 Nov 2016 13:20:16 +0100
> Alexis Ballier  wrote:
> 
> > On Thu,  3 Nov 2016 00:52:17 +0100
> > Maciej Mrozowski  wrote:
> >   
> > > From: Maciej Mrozowski 
> > > 
> > > ---
> > >  eclass/cmake-utils.eclass | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> > > index 88d2163..23cc094 100644
> > > --- a/eclass/cmake-utils.eclass
> > > +++ b/eclass/cmake-utils.eclass
> > > @@ -525,13 +525,13 @@ enable_cmake-utils_src_configure() {
> > >  
> > >   local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
> > >   cat > ${toolchain_file} <<- _EOF_ || die
> > > - SET (CMAKE_C_COMPILER $(tc-getCC))
> > > - SET (CMAKE_CXX_COMPILER $(tc-getCXX))
> > > - SET (CMAKE_Fortran_COMPILER $(tc-getFC))
> > >   SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE
> > > FILEPATH
> > 
> > 
> > Have you tested cross compiling ?
> > IIRC toolchain file is used *before* getting those vars from env and
> > is used to determine system & compiler type. Without this you get
> > bugs like #503216  
> 
> I was dubious (since I filed that bug) but I briefly tested by
> cross-compiling media-libs/openal and it worked. I didn't think to try
> older CMake versions though. The behaviour might have changed.
> 

could you please send me (in private) build logs with & without the
changes please ?

(dont have easy access to a x compile setup atm)

Re: [gentoo-dev] [PATCH 2/2] cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530

[James Le Cuirot]

On Fri, 4 Nov 2016 13:20:16 +0100
Alexis Ballier  wrote:

> On Thu,  3 Nov 2016 00:52:17 +0100
> Maciej Mrozowski  wrote:
> 
> > From: Maciej Mrozowski 
> > 
> > ---
> >  eclass/cmake-utils.eclass | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> > index 88d2163..23cc094 100644
> > --- a/eclass/cmake-utils.eclass
> > +++ b/eclass/cmake-utils.eclass
> > @@ -525,13 +525,13 @@ enable_cmake-utils_src_configure() {
> >  
> > local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
> > cat > ${toolchain_file} <<- _EOF_ || die
> > -   SET (CMAKE_C_COMPILER $(tc-getCC))
> > -   SET (CMAKE_CXX_COMPILER $(tc-getCXX))
> > -   SET (CMAKE_Fortran_COMPILER $(tc-getFC))
> > SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE
> > FILEPATH  
> 
> 
> Have you tested cross compiling ?
> IIRC toolchain file is used *before* getting those vars from env and
> is used to determine system & compiler type. Without this you get
> bugs like #503216

I was dubious (since I filed that bug) but I briefly tested by
cross-compiling media-libs/openal and it worked. I didn't think to try
older CMake versions though. The behaviour might have changed.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] [PATCH 2/2] cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530

[Alexis Ballier]

On Thu,  3 Nov 2016 00:52:17 +0100
Maciej Mrozowski  wrote:

> From: Maciej Mrozowski 
> 
> ---
>  eclass/cmake-utils.eclass | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index 88d2163..23cc094 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -525,13 +525,13 @@ enable_cmake-utils_src_configure() {
>  
>   local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
>   cat > ${toolchain_file} <<- _EOF_ || die
> - SET (CMAKE_C_COMPILER $(tc-getCC))
> - SET (CMAKE_CXX_COMPILER $(tc-getCXX))
> - SET (CMAKE_Fortran_COMPILER $(tc-getFC))
>   SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH


Have you tested cross compiling ?
IIRC toolchain file is used *before* getting those vars from env and is
used to determine system & compiler type. Without this you get bugs like
#503216

Re: [gentoo-dev] Revisiting version-related tree policies

[Kent Fredric]

On Fri, 4 Nov 2016 10:24:28 +0100
Ulrich Mueller  wrote:

> I would assume  to be high enough, even if you use multiples of
> 100 to label the slot. Or do you expect having more than 100 slots for
> Perl?

Well, the desire is for the -r (or similar) part correspond to
something representative of which version of Perl the virtual is an
"underwriter" for.

So it would naturally start at one of the following:

 522, 524, 526
 5022, 5024, 5026

And then you realise upstream are getting crazy and you'll need a
seperate virtual only for 5.22.1, so you'll need

 -r5221

But that's only enough for a prefix for the identifier ... so you'll want 
-r52210, -r52211, 

and at this point, it very much is getting into the weeds of confusing.

Granted I'm still at "worry about things that aren't actually a problem yet" 
stage.

Mostly because we're not yet employing this technique until we're sure
its going to be a good idea, and the only place we've *kinda* needed
such a solution is virtual/perl-Test-Simple
( https://bugs.gentoo.org/show_bug.cgi?id=584238#c11 )

The problem however is reduced as follows:

1. Slots are not appropriate, because they can't be concurrently installed
2. versions must indicate an upgrade path to coerce portage to install
   and remove things as needed
3. versions on the virtual themselves must correlate with upstream,
   because we use the virtuals to ensure "X version of Y exists somehow"

and the /desire/ is to have an -r scheme that we could consider
making automated one day.

There's just not a lot of wiggle room, because most of PV is "upstreams
version", and the '-r' part is really the only part we can have some
flexibility with.




pgp2wxLp58yzJ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Revisiting version-related tree policies

[Ulrich Mueller]

> On Fri, 4 Nov 2016, Kent Fredric wrote:

>> 1. Revision number must be no longer than :
>> 1a. to make <=X-r reliable,
>> 1b. to prevent pathological uses of revision as date.

> I think most the arguments you've made for this stem from subjective
> and social problems, not technical ones.

Exactly. That's why this is not intended for PMS but for the
devmanual. Developer time is one of our most valuable resources.

> I'd hate to be artificially limiting the utility of what can be done
> with "-r" versions just because *some* of those versions *may* be
> confusing for humans.

> I could just as easily argue that using -r200 and -r300 is
> "confusing", and that 1.2r-300 "could be a problem" and maybe we
> should abolish -r'vs entirely.

> The -r200 and -r300 were also not just arbitrary numbers, but they
> followed the slot version, and so the "-r" suffix was itself not
> purely a "X < Y", but also conveyed data about what it was for, and
> served as a predictable anti-collision mechanism ( due to the whole
> 2-slots-cant-have-identical-versions deal )

I think nobody is arguing against using r200 etc. for special
purposes.

> And as you know I was considering a similar strategy to be able
> to have several variations of the same perl virtual for upgrade
> reasons, but that would predictably have a much wider variety of
> '-r ' prefixes to represent the wider variety of significant Perl
> versions.

I would assume  to be high enough, even if you use multiples of
100 to label the slot. Or do you expect having more than 100 slots for
Perl?

Ulrich


pgpNzqA8Yentt.pgp
Description: PGP signature

Re: [gentoo-dev] Revisiting version-related tree policies

[Ulrich Mueller]

> On Fri, 4 Nov 2016, Kristian Fiskerstrand wrote:

> On 11/03/2016 05:11 PM, Michał Górny wrote:
>> == Policy changes? ==
>> I think that the following new policies could make sense:
>> 
>> 1. Revision number must be no longer than :

> You likely mean "no higher than ", longer than would give large
> values

The wording would be similar to "no longer than 4 digits".

>> 1a. to make <=X-r reliable,
>> 1b. to prevent pathological uses of revision as date.

> Given revision in most cases is incremental (except for some -r100,
> -r200) cases, some structure here is likely good. I take it we're
> talking about devmanual changes in this case for policy?

Yes, it would be purely devmanual/tree policy. PMS will still mandate
that the package manager can handle arbitrary long versions.

Looks like using multiples of 100 is best practice if there is
the same PV in different slots. Not sure if we should codify that
somewhere. (If nobody contradicts, this message could be used as
future policy reference, though. :)

Ulrich


pgplaCg2C9bC_.pgp
Description: PGP signature

Re: [gentoo-dev] Revisiting version-related tree policies

[Kent Fredric]

On Thu, 3 Nov 2016 17:11:22 +0100
Michał Górny  wrote:

> 1. Revision number must be no longer than :
> 1a. to make <=X-r reliable,
> 1b. to prevent pathological uses of revision as date.

I think most the arguments you've made for this stem from subjective
and social problems, not technical ones.

I'd hate to be artificially limiting the utility of what can be done
with "-r" versions just because *some* of those versions *may* be
confusing for humans.

I could just as easily argue that using -r200 and -r300 is "confusing",
and that 1.2r-300 "could be a problem" and maybe we should abolish
-r'vs entirely.

The -r200 and -r300 were also not just arbitrary numbers, but they
followed the slot version, and so the "-r" suffix was itself not purely
a "X < Y", but also conveyed data about what it was for, and served as
a predictable anti-collision mechanism ( due to the whole
2-slots-cant-have-identical-versions deal )

And as you know I was considering a similar strategy to be able to have
several variations of the same perl virtual for upgrade reasons, but
that would predictably have a much wider variety of '-r ' prefixes to
represent the wider variety of significant Perl versions. 



> 2. I think we could use a policy to make >=X_alpha reliable. However,
> I have no clue how to word it without making it weird and artificially
> restricting valid version numbers.



pgpxetCnBlBeS.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Revisiting version-related tree policies

[Kristian Fiskerstrand]

On 11/03/2016 05:11 PM, Michał Górny wrote:
> == Policy changes? ==
> I think that the following new policies could make sense:
> 
> 1. Revision number must be no longer than :

You likely mean "no higher than ", longer than would give large values

> 1a. to make <=X-r reliable,
> 1b. to prevent pathological uses of revision as date.

Given revision in most cases is incremental (except for some -r100,
-r200) cases, some structure here is likely good. I take it we're
talking about devmanual changes in this case for policy?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: kde-misc/networkmanagement

[Johannes Huber]

# Johannes Huber  (04 Nov 2016)
# Masked for reomval in 30 days. Superseded by kde-plasma/plasma-nm.
# Only support for deprecated Plasma 4. Exported to kde-sunset overlay.
kde-misc/networkmanagement

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID FDF4F788


signature.asc
Description: This is a digitally signed message part.