Re: [gentoo-dev] Re: [RFC] multiversion ebuilds

[R0b0t1]

On Tue, May 15, 2018 at 11:15 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Mathy Vanvoorden posted on Tue, 15 May 2018 11:32:30 +0200 as excerpted:
>
>> 2018-05-12 14:20 GMT+02:00 Gerion Entrup :
>>
>> just an idea for now. But what you think about multiversion ebuilds?
>>> Technically this could be realized with the following line in the ebuild
>>> itself:
>>> ```
>>> VERSIONS=( 3.0.11 3.0.12 3.1 )
>>> ```
>>>
>>
>> I like the idea of multiversion ebuilds but why would you complicate the
>> process by putting it in a variable? Why not just use symlinks and have the
>> following:
>>
>> foobar/foobar-1.x
>> foobar/foobar-1.1.ebuild -> foobar-1.x
>> foobar/foobar-1.2.ebuild -> foobar-1.x
>> foobar/foobar-2.x
>> foobar/foobar-2.1.ebuild -> foobar-2.x
>
> AFAIK symlinks aren't allowed in the gentoo tree, with the given reason
> being that some users, particularly those with limited net access and
> thus "sneakernetting" from where they /do/ have net access, may place
> the tree on or transfer it via no-symlink-support FAT32 or similar,
> perhaps downloading it from an MS machine or the like.
>
> Of course users may use symlinks on their own copies, but they're not
> allowed in the official tree.
>
> Tho perhaps that can be reevaluated.  But while there's more connectivity
> now than over a decade ago when that policy was created, I expect there's
> still those paying by the meg or gig for net access locally, that won't
> enjoy having their sneakernet sync routine disrupted.
>

Cygwin and MSYS(2) are currently mostly supported by Prefix, so using
symlinks might kill them as well. There is some kind of symlinking
support for NTFS now but it is very primitive.

Cheers,
 R0b0t1

[gentoo-dev] Re: [RFC] multiversion ebuilds

[Duncan]

Mathy Vanvoorden posted on Tue, 15 May 2018 11:32:30 +0200 as excerpted:

> 2018-05-12 14:20 GMT+02:00 Gerion Entrup :
> 
> just an idea for now. But what you think about multiversion ebuilds?
>> Technically this could be realized with the following line in the ebuild
>> itself:
>> ```
>> VERSIONS=( 3.0.11 3.0.12 3.1 )
>> ```
>>
> 
> I like the idea of multiversion ebuilds but why would you complicate the
> process by putting it in a variable? Why not just use symlinks and have the
> following:
> 
> foobar/foobar-1.x
> foobar/foobar-1.1.ebuild -> foobar-1.x
> foobar/foobar-1.2.ebuild -> foobar-1.x
> foobar/foobar-2.x
> foobar/foobar-2.1.ebuild -> foobar-2.x

AFAIK symlinks aren't allowed in the gentoo tree, with the given reason
being that some users, particularly those with limited net access and
thus "sneakernetting" from where they /do/ have net access, may place
the tree on or transfer it via no-symlink-support FAT32 or similar,
perhaps downloading it from an MS machine or the like.

Of course users may use symlinks on their own copies, but they're not
allowed in the official tree.

Tho perhaps that can be reevaluated.  But while there's more connectivity
now than over a decade ago when that policy was created, I expect there's
still those paying by the meg or gig for net access locally, that won't
enjoy having their sneakernet sync routine disrupted.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Last rites: net-misc/asterisk-g729, sci-libs/coinhsl, some games-*/* (BLAKE2B)

[Michał Górny]

# Michał Górny  (15 May 2018)
# Distfile missing BLAKE2B hash.  The package is fetch-restricted,
# the sources can apparently by only obtained by buying it, or filing
# an academic license request and having it approved.  Please provide
# the updated hash if you have the matching distfile.
# Bug #642908.  Removal in 30 days.
sci-libs/coinhsl

# Michał Górny  (15 May 2018)
# Remaining fetch-restricted game packages missing BLAKE2B hashes.
# Please provide updated hashes if you have the matching distfiles.
# Bug #642876.  Removal in 30 days.
games-action/shadowgrounds-bin
games-action/shadowgrounds-survivor-bin
games-action/trine2
games-misc/dont-starve
games-puzzle/larry
games-rpg/avadon
games-rpg/bastion
games-rpg/penumbra-collection
games-rpg/wasteland2

# Michał Górny  (15 May 2018)
# All current versions are unfetchable.  No maintainer activity
# since 2014.  Bug #600962.  Removal in 30 days.
net-misc/asterisk-g729

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] News item review: Python 3.6 to become the default target

[Michał Górny]

W dniu wto, 15.05.2018 o godzinie 22∶51 +0200, użytkownik Francisco Blas
Izquierdo Riera (klondike) napisał:
> Hi Michał,
> 
> El 15/05/18 a las 08:20, Michał Górny escribió:
> > If you are still using Python 3.4, please consider switching to a newer
> > version as it is reaching its end-of-life.  The end-of-life dates
> > for the currently used versions are:
> > 
> >   Python 3.42019-03-16
> >   Python 2.72020-01-01
> >   Python 3.52020-09-13 [1]
> 
> 
> Keep in mind that this bit is quite useless unless you also display the
> news item if dev-lang/python:3.4 is installed.

I was wondering about extending the item to all Python versions
but figured out this is just a minor note that doesn't really justify
displaying the whole item.

On the other hand, people who are still on 3.4 may be interested
in migrating to 3.6 after all.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] News item review: Python 3.6 to become the default target

[Francisco Blas Izquierdo Riera (klondike)]

Hi Michał,

El 15/05/18 a las 08:20, Michał Górny escribió:
> If you are still using Python 3.4, please consider switching to a newer
> version as it is reaching its end-of-life.  The end-of-life dates
> for the currently used versions are:
>
>   Python 3.42019-03-16
>   Python 2.72020-01-01
>   Python 3.52020-09-13 [1]


Keep in mind that this bit is quite useless unless you also display the
news item if dev-lang/python:3.4 is installed.

Also you may want to break the paragraph before "The end-of-lie dates..."




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Openstack Summit MeetUp: dinner planning for Wednesday?

[Brian Dolbec]

On Mon, 14 May 2018 22:49:26 +
"Robin H. Johnson"  wrote:

> On Sun, May 13, 2018 at 01:11:30PM -0700, Jack Morgan wrote:
> > Gentoo,
> > 
> > I will be attending the Openstack Summit in Vancouver, BC. The
> > conference is May 21-24th. I would like to organize a Gentoo meetup
> > for those attending or living in the area. I personally will be
> > there from May 20th - 26th.
> > 
> > Please reply if you are interested in meeting and which
> > day(s)/time(s) you are available. I'm looking forward to it!  
> I'm Vancouver-local, and will ALSO be attending the summit.
> 
> Available for events during the daytime during the conference, and
> also evenings of Monday & Wednesday. I am NOT available on the
> evenings.
> 
> As a note, Monday is a (provincial) public holiday in Vancouver, and
> you may find a lot of restaurants closed (more than the ones that are
> usually closed Mondays).
> 
> Unless there are specific objections, let's try to plan the meetup for
> Wednesday evening based on the above?
> 
> I can help to arrange a dinner outing Wednesday evening. If you're
> interested, privately email me. Please include a mention of specific
> dietary requirements if any.
> 

I am also local to Vancouver, but won't be at the event.  Wednesday
works better for me too. My daughter has ball games Tuesday and
Thursday.

-- 
Brian Dolbec 



pgphPm7lUDY8d.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Python 3.5 -> 3.6 switch

[Matthew Thode]

On 18-05-15 07:38:36, Michał Górny wrote:
> Hi, everyone.
> 
> In no less than 30 days, we will be switching the default Python targets
> from CPython 3.5 to 3.6.  The new values will be:
> 
>   PYTHON_TARGETS="python2_7 python3_6"
>   PYTHON_SINGLE_TARGET="python3_6"
> 
> If you haven't ported your package to Python 3.6, please look into doing
> it now.  Helpful lists:
> 
>  packages missing python3.6 support:
>   list:  https://qa-reports.gentoo.org/output/gpyutils/35-to-36.txt
>   graph: https://qa-reports.gentoo.org/output/gpyutils/35-to-36.svg
> 
>  packages needing stabilization:
>   l https://qa-reports.gentoo.org/output/gpyutils/35-to-36-stablereq.txt
>   g https://qa-reports.gentoo.org/output/gpyutils/35-to-36-stablereq.svg
> 
> At the same time, I'd like to remind you that Python 3.4 reaches end-of-
> life in March 2019.  For more details, see [1].
> 
> I'll submit a news item for users for review today.  The switch will be
> postponed to account for its publication.
> 
> [1]:https://devguide.python.org/#status-of-python-branches
> 

lol, when it gets to nova.

The state for openstack is that upstream currently only tests on 3.5.
They are just starting to test on 3.6 with the stable release with that
testing probably going to occur for the 2019.1 release.  Until then,
most of openstack will be mainly on python 3.6.  That said, there are
not expected to be any problems with openstack on py36, so moving over
sooner may make sense (I was hoping that py36 would be in the rocky
release).

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] multiversion ebuilds

[Mathy Vanvoorden]

2018-05-12 14:20 GMT+02:00 Gerion Entrup :

just an idea for now. But what you think about multiversion ebuilds?
> Technically this could be realized with the following line in the ebuild
> itself:
> ```
> VERSIONS=( 3.0.11 3.0.12 3.1 )
> ```
>

I like the idea of multiversion ebuilds but why would you complicate the
process by putting it in a variable? Why not just use symlinks and have the
following:

foobar/foobar-1.x
foobar/foobar-1.1.ebuild -> foobar-1.x
foobar/foobar-1.2.ebuild -> foobar-1.x
foobar/foobar-2.x
foobar/foobar-2.1.ebuild -> foobar-2.x

It would result in the same outcome but it seems to me that a lot less work
(almost none?) is needed to implement it.

Benefits compared to your suggestion:
* you don't need to add the extra VERSIONS variable and related logic
* you don't need the set of rules
* you can have multiple multiversioned ebuilds per package

I'm not sure if adding the foobar-1.x file is allowed by portage.

You would still need logic like this for the keywording:

```
> if [[ ${PV} == "3.1" ]] ; then
> KEYWORDS="~amd64 ~x86"
> else
> KEYWORDS="amd64 x86"
> fi
> ```
>

br,
Mathy

[gentoo-dev] News item review: Python 3.6 to become the default target

[Michał Górny]

Hello, everyone.

Please review the following news item. The 'xx'-es will be replaced with
the publication date, making the deadline appropriately pub + 1 month.

---
Title: Python 3.6 to become the default target
Author: Michał Górny 
Posted: 2018-05-xx
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: dev-lang/python:3.5

On 2018-06-xx, Python 3.6 will replace Python 3.5 in the default Python
targets for Gentoo systems.  The new default targets will be:

PYTHON_TARGETS="python2_7 python3_6"
PYTHON_SINGLE_TARGET="python3_6"

If you have not overriden the value of those variables on your system,
then your package manager will want to use the new targets immediately.
In order to prevent dependency conflicts, please clean stray packages
and rebuild/upgrade all packages with USE flag changes after the change,
e.g.:

emerge --depclean
emerge -1vUD @world
emerge --depclean

Please note that upgrading dependencies in place may cause some
of the package dependencies to be temporarily missing.  While this
should not affect scripts that are already fully loaded, it may cause
ImportErrors while starting Python scripts or loading additional
modules (only scripts running Python 3.5 are affected).

In order to improve stability of the upgrade, you may choose to
temporarily enable both targets, i.e. set in /etc/portage/make.conf
or its equivalent:

PYTHON_TARGETS="python2_7 python3_5 python3_6"
PYTHON_SINGLE_TARGET="python3_5"

This will cause the dependencies to include both Python 3.5 and 3.6
support on the next system upgrade.  Once all packages are updated,
you can restart your scripts, remove the custom setting and run another
upgrade to remove support for Python 3.5.

If you would like to postpone the switch to Python 3.6, you can copy
the current value of PYTHON_TARGETS and/or PYTHON_SINGLE_TARGET
to /etc/portage/make.conf or its equivalent:

PYTHON_TARGETS="python2_7 python3_5"
PYTHON_SINGLE_TARGET="python3_5"

If you would like to migrate your systems earlier, you can do the same
with the new value.

If you are still using Python 3.4, please consider switching to a newer
version as it is reaching its end-of-life.  The end-of-life dates
for the currently used versions are:

  Python 3.42019-03-16
  Python 2.72020-01-01
  Python 3.52020-09-13 [1]

[1]:https://devguide.python.org/#status-of-python-branches

-- 
Best regards,
Michał Górny