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

[Ulrich Mueller]

> On Wed, 16 May 2018, Paweł Hajdan, wrote:

> I'm wondering: if the main goal would be more code sharing between
> ebuilds, would something like
> 
> (essentially per-package eclasses) be an option?

eblits!
/me hides


pgpSQ9fZWtBSG.pgp
Description: PGP signature

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

[Paweł Hajdan , Jr .]

On 12/05/2018 14:20, Gerion Entrup wrote:
> 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 )
> ```
> 
> and the filename without version:
> //.ebuild

I'm wondering: if the main goal would be more code sharing between
ebuilds, would something like

(essentially per-package eclasses) be an option?

Paweł



signature.asc
Description: OpenPGP digital signature

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

[Martin Vaeth]

R0b0t1  wrote:
> On Tue, May 15, 2018 at 11:15 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>>
>> AFAIK symlinks aren't allowed in the gentoo tree [...]
>>
>> Tho perhaps that can be reevaluated. [...]
>
> Cygwin and MSYS(2) are currently mostly supported by Prefix [...]

For rsync users, the non-symlink policy is not necessary:
They could simply pass the option --copy-links to get a working
tree (of course, correspondingly longer).

For git users (essential for overlays!), I do not know a simple way.
It might be possible to set up appropriate git hooks, but that
might be tricky: The hooks would need to apply before the files
are actually checked out, and it might become even more tricky if
one does not want that subsequent git commands do consider the
transformation as a local modification.

For git perhaps an opposite approach might be easier: One could
provide hooks which every git user is supposed to use which manage
symlinks and/or copies.
More precisely, these hooks should have a symlink and a non-symlink
mode (depending on whether the underlying (file)system can generate
symlinks which can easily and quickly be detected), and the tree
would need to contain a symlinks.dat file with a list of symlinks,
and a .gitignore containing the symlinks.
During checkout, the hooks should simply generate the corresponding
symlinks/files (depending on symlinks.dat) according to the stored
list of symlinks.
During checkin in symlink mode, these hooks automatically update
symlinks.dat and .gitignore so that most developers simply can
use/modify symlinks transparently.
During checkin in non-symlink mode the hook does nothing:
Developers who checkin on filesystems without symlink have to update
these 2 files manually, of course, when they want to
create/remove/rename a symlink. Maybe one could provide
corresponding helper scripts for those developers with
non-symlink-aware filesystems if necessary.

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