[gentoo-dev] Re: Changing order of default virtual/udev provider

[Duncan]

Francesco Riosa posted on Mon, 15 Feb 2016 13:13:37 +0100 as excerpted:

> Neither this is totally true, or put another way, everybody which is NOT
> using systemd is using eudev (or some form of static /dev).
> So obviously this is totally relevant for people that don't use systemd.

Not really true either, as there remain various distros using busybox's 
mdev, etc.  However, it's /possibly/ true that most/all distros using 
udev-devmgr-dropin functionality, but not systemd, are switching to 
eudev.  I'm not in a position to know on that, beyond the enumerated list 
of those using eudev that was posted earlier in the thread.

> Also, why, why people using systemd ARE interested in this thread?
> You should not be interested at all.

Because many of those who are using systemd, including me, are never-the-
less interested in preserving an alternative init system, both for those 
who choose to use something other than systemd, and because we value an 
environment where the choice remains available, believing that choice is 
healthy and ultimately strengthens most players including the dominant 
player, systemd in this case.

In my particular case, I was one of the few users actually running and 
testing the openrc- live package for many years, and that testing 
resulted in a number of bugs being reported and fixed before they hit 
actual ~arch release users.  I stand on that openrc gentoo-bugs record, 
and while I'm now a systemd user, I still care about a viable and healthy 
openrc project and ecosystem, including stand-alone udev, because while I 
am *currently* a systemd user, I know well how time and real-life 
occasionally throw unpredictable curveballs, and for all I know, I may 
well end up back on openrc in a few years, myself.  And if not me, than 
someone else I'm trying to help on some mailing list or whatever.  As 
such, it's very much in my own interest to make sure openrc and its 
ecosystem (including standalone udev-replacements) remains as viable and 
healthy as possible.

As it happens, that was actually one of my big worries about switching to 
systemd, myself, since I /was/ one of the only openrc-live testers for 
some time, and I was a bit concerned about the possibility of nobody else 
actually running it and catching/filing those early pre-release bugs.  
But I did a bugsy search on openrc-, and it turned out in the last 
year or two before I switched to systemd, others had begun filing 
openrc- bugs as well, and I was no longer the only filer popping up 
in the bug searches.  So it was that a big worry about the effects of my 
switch on others still using openrc was put to rest, and I could 
personally switch secure in the knowledge that others had filled my role 
as openrc-live tester and bug-filer. =:^)

And it's with all that in mind that I've participated in this thread, 
seriously believing that eudev is in fact the most logical and viable 
default for stand-alone udev-drop-in functionality, tho I'd definitely 
rest a bit easier if the documentation were better and if it wasn't so 
much a primarily one-man project.

-- 
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] Re: RFC: intel-sdp-r1.eclass

[Martin Vaeth]

Justin Lecher (jlec)  wrote:
>>> [[ -n ${_INTEL_PV4} ]] && _INTEL_PV+="${_INTEL_PV4}-"
>>> [[ -n ${_INTEL_PV1} ]] && _INTEL_PV+="${_INTEL_PV1}"
>>> [[ -n ${_INTEL_PV2} ]] && _INTEL_PV+=".${_INTEL_PV2}"
>>> [[ -n ${_INTEL_PV3} ]] && _INTEL_PV+=".${_INTEL_PV3}"
>>> [[ -n ${_INTEL_PV4} ]] && _INTEL_PV+="-${_INTEL_PV4}"
>>
>> Now, this is crazy ;-). I don't see immediately how to improve that,
>> but I suggest you thought about that.
>
> [...] So there is no sanity other then reshuffling.

You could put the logic into the string:

_INTEL_PV+="${_INTEL_PV4}${_INTEL_PV4:+-}${_INTEL_PV1}"
_INTEL_PV+="${_INTEL_PV2:+.}${_INTEL_PV2}"
_INTEL_PV+="${_INTEL_PV3:+.}${_INTEL_PV3}"
_INTEL_PV+="${_INTEL_PV4:+-}${_INTEL_PV4}"

Re: [gentoo-dev] libressl: proposing a new project and calling for help

[Kristian Fiskerstrand]

On 02/15/2016 01:20 PM, Dirkjan Ochtman wrote:
> On Sun, Feb 14, 2016 at 10:38 PM, Anthony G. Basile 
>  wrote:
>> We discussed the state of libressl today in the council. 
>> Proceeding forward with that work, I'm going to propose a new 
>> project and getting together a team.  Much of the work has 
>> already done by hasufell and what remain is just following 
>> through on his plan.
> 
> Is "his plan" detailed anywhere? In other words, what does it mean 
> to sign up for this project? :)
> 

https://github.com/gentoo/libressl/wiki/Transition-plan#fixing-unstable-arch-ebuilds



-- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: intel-sdp-r1.eclass

[Michał Górny]

On Mon, 15 Feb 2016 15:41:58 +0100
"Justin Lecher (jlec)"  wrote:

> On 15/02/16 15:35, Michał Górny wrote:
> > On Mon, 15 Feb 2016 14:37:41 +0100
> > "Justin Lecher (jlec)"  wrote:
> >   
> >> On 15/02/16 13:59, Michał Górny wrote:  
> >>> On Mon, 15 Feb 2016 09:16:53 +0100
> >>> "Justin Lecher (jlec)"  wrote:
> >>> 
>  # @ECLASS-VARIABLE: INTEL_SUBDIR
>  # @DEFAULT_UNSET
>  # @DESCRIPTION:
>  # The package sub-directory where it will end-up in /opt/intel
>  # To find out its value, you have to do a raw install from the Intel tar 
>  ball
> >>>
> >>> To be honest, I find this kinda terrible. There's a huge block of docs
> >>> which makes me feel small and confused. Maybe it'd useful to give some
> >>> semi-complete example on top (in global doc)?
> >>
> >> That makes definitely make sense. We will add one.
> >>
> >> Although nobody other then the maintainer of this eclass will ever use it. 
> >>  
> > 
> > Remember that maintainers can change. It's better to have good then
> > have new maintainers figure out all stuff over again.
> >   
>  # e.g. CLI_install/rpm/intel-vtune-amplifier-xe-cli
>  : ${INTEL_BIN_RPMS:=()}
> >>>
> >>> $ : ${foo:=()}
> >>> $ declare -p foo
> >>> declare -- foo="()"
> >>>
> >>> In other words, it doesn't work the way you expect it to.
> >>
> >> I already wondered about this. Is there any way to force a variable to
> >> be an array in bash? Or define it as an empty array?  
> > 
> > Look at e.g. python-utils-r1.
> > 
> > To check for array:
> > 
> >   if [[ $(declare -p foo) != "declare -a"* ]]; then
> > ...
> >   fi
> > 
> > To default to empty, simple (yet a bit imperfect) way:
> > 
> >   [[ ${foo[@]} }] || foo=()  
> 
> And what about the default assignment for the man page?

Have no clue. I think someone mentioned some hack somewhere. Or maybe
we could finally fix eclass-manpages script to handle this.

> >>> Err, this is not code, you know.
> >>
> >> This is needed for nice formatting. Otherwise there is no line break  
> > 
> > Add an empty line between the two. That should do it correctly, without
> > code blocks in devmanual.  
> 
> That will introduce an empty line between the two points.

Which is quite correct. And in any case, it's definitely not worse than
what you're causing now:

https://devmanual.gentoo.org/eclass-reference/intel-sdp.eclass/index.html

> >>> Wouldn't you be able to collapse that into one loop?
> >>
> >> no, because the first has ${INTEL_X86}.rpm as suffeix and the later has
> >> ${INTEL_X86}.rpm.  
> > 
> > Er... am I reading wrong, or did you just type the same thing twice?  
> 
> right, it should be ${INTEL_X86}.rpm vs noarch.rpm

Well, I think you still could handle this with some extra code
and conditionals, at least reduced code duplication.

-- 
Best regards,
Michał Górny



pgpGHuwi5LopO.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

On 15 Feb 2016 13:13, Francesco Riosa wrote:
> Also, why, why people using systemd ARE interested in this thread?
> You should not be interested at all.

in case you're directing at me, i do not use systemd anywhere
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] RFC: intel-sdp-r1.eclass

[Justin Lecher (jlec)]

On 15/02/16 15:35, Michał Górny wrote:
> On Mon, 15 Feb 2016 14:37:41 +0100
> "Justin Lecher (jlec)"  wrote:
> 
>> On 15/02/16 13:59, Michał Górny wrote:
>>> On Mon, 15 Feb 2016 09:16:53 +0100
>>> "Justin Lecher (jlec)"  wrote:
>>>   
 # @ECLASS-VARIABLE: INTEL_SUBDIR
 # @DEFAULT_UNSET
 # @DESCRIPTION:
 # The package sub-directory where it will end-up in /opt/intel
 # To find out its value, you have to do a raw install from the Intel tar 
 ball  
>>>
>>> To be honest, I find this kinda terrible. There's a huge block of docs
>>> which makes me feel small and confused. Maybe it'd useful to give some
>>> semi-complete example on top (in global doc)?  
>>
>> That makes definitely make sense. We will add one.
>>
>> Although nobody other then the maintainer of this eclass will ever use it.
> 
> Remember that maintainers can change. It's better to have good then
> have new maintainers figure out all stuff over again.
> 
 # e.g. CLI_install/rpm/intel-vtune-amplifier-xe-cli
 : ${INTEL_BIN_RPMS:=()}  
>>>
>>> $ : ${foo:=()}
>>> $ declare -p foo
>>> declare -- foo="()"
>>>
>>> In other words, it doesn't work the way you expect it to.  
>>
>> I already wondered about this. Is there any way to force a variable to
>> be an array in bash? Or define it as an empty array?
> 
> Look at e.g. python-utils-r1.
> 
> To check for array:
> 
>   if [[ $(declare -p foo) != "declare -a"* ]]; then
> ...
>   fi
> 
> To default to empty, simple (yet a bit imperfect) way:
> 
>   [[ ${foo[@]} }] || foo=()

And what about the default assignment for the man page?

> 
 # @ECLASS-VARIABLE: INTEL_SINGLE_ARCH
 # @DESCRIPTION:
 # Unset, if only the multilib package will be provided by intel
 : ${INTEL_SINGLE_ARCH:=true}  
>>>
>>> This is really weird. It sounds like I'm supposed to do:
>>>
>>>   inherit intel-sdp-r1
>>>   unset INTEL_SINGLE_ARCH
>>>
>>> I suggest you used positive logic instead.  
>>
>> The wording is wrong. Setting it to anything but "true" like
>> "INTEL_SINGLE_ARCH=false" works. We will fix the wording.
> 
> I still think positive logic is better. That is, a variable which
> defaults to, say, unset, and changes behavior if it becomes set to
> non-empty value.

we will look into that.

> 
 _isdp_big-warning() {
debug-print-function ${FUNCNAME} "${@}"

case ${1} in
pre-check )
echo ""  
>>>
>>> Don't mix echo with ewarn.  
>>
>> Why?
> 
> Because they won't go through the same output channels.
> 

 comp_full="${ED}/${INTEL_SDP_DIR}/linux/bin/${arch}/${comp}"  
>>>
>>> Double slash imminent (ED has one).  
>>
>> Always? Per definition?
> 
> Yes, sadly. i wanted to change this but it's unlikely to go since it
> makes EAPI migration hard. If you really want to cover both cases, you
> can always do ${foo%/}/bar.
> 
 # @CODE  
>>>
>>> Err, this is not code, you know.  
>>
>> This is needed for nice formatting. Otherwise there is no line break
> 
> Add an empty line between the two. That should do it correctly, without
> code blocks in devmanual.

That will introduce an empty line between the two points.

> 
#maybe use nullglob or [[ $(echo ${dir/*lic) != 
 "${dir}/*lic" ]]
[[ $( ls "${dir}"/*lic 2>/dev/null ) ]]; ret=$?  
>>>
>>> Maybe you should use something sane indeed.
> 
> Maybe file_exists from eutils could help here btw.
> 
>>> Wouldn't you be able to collapse that into one loop?  
>>
>> no, because the first has ${INTEL_X86}.rpm as suffeix and the later has
>> ${INTEL_X86}.rpm.
> 
> Er... am I reading wrong, or did you just type the same thing twice?

right, it should be ${INTEL_X86}.rpm vs noarch.rpm

> 
einfo "Unpacking ${rb}"
rpm2tar -O ${r} | tar xvf - | sed -e \
"s:^\.:${EROOT#/}:g" > /dev/null; assert 
 "unpacking ${r} failed"  
>>>
>>> What's the deal with this sed?  
>>
>> Good question, but it was there since always and probably the original
>> author had good reasons for it. We will look into it and comment the code.
> 
> Didn't it change in the past? As I see it, tar here outputs file names,
> sed edits them and then you discard them to /dev/null. In this case,
> sed doesn't return any specific exit code so it seems to be a complete
> no-op.
> 
> Maybe originally it verbosely output the extracted files.
> 
 EXPORT_FUNCTIONS pkg_setup src_unpack src_install pkg_postinst pkg_postrm 
 pkg_pretend  
>>>
>>> We usually do this on top, and it's better to do it outside guards so
>>> that order from inherit is always respected.  
>>
>> we will move it up. I don't get your second comment. Do you mean the
>> case someone does
>>
>> inherit intel-sdp-r1 some-other-eclass intel-sdp
>>
>> ?
> 
> Rather something unlikely like:
> 
>   inherit foo bar intel-sdp-r1
> 
> where foo inherits 

Re: [gentoo-dev] RFC: intel-sdp-r1.eclass

[Michał Górny]

On Mon, 15 Feb 2016 14:37:41 +0100
"Justin Lecher (jlec)"  wrote:

> On 15/02/16 13:59, Michał Górny wrote:
> > On Mon, 15 Feb 2016 09:16:53 +0100
> > "Justin Lecher (jlec)"  wrote:
> >   
> >> # @ECLASS-VARIABLE: INTEL_SUBDIR
> >> # @DEFAULT_UNSET
> >> # @DESCRIPTION:
> >> # The package sub-directory where it will end-up in /opt/intel
> >> # To find out its value, you have to do a raw install from the Intel tar 
> >> ball  
> > 
> > To be honest, I find this kinda terrible. There's a huge block of docs
> > which makes me feel small and confused. Maybe it'd useful to give some
> > semi-complete example on top (in global doc)?  
> 
> That makes definitely make sense. We will add one.
> 
> Although nobody other then the maintainer of this eclass will ever use it.

Remember that maintainers can change. It's better to have good then
have new maintainers figure out all stuff over again.

> >> # e.g. CLI_install/rpm/intel-vtune-amplifier-xe-cli
> >> : ${INTEL_BIN_RPMS:=()}  
> > 
> > $ : ${foo:=()}
> > $ declare -p foo
> > declare -- foo="()"
> > 
> > In other words, it doesn't work the way you expect it to.  
> 
> I already wondered about this. Is there any way to force a variable to
> be an array in bash? Or define it as an empty array?

Look at e.g. python-utils-r1.

To check for array:

  if [[ $(declare -p foo) != "declare -a"* ]]; then
...
  fi

To default to empty, simple (yet a bit imperfect) way:

  [[ ${foo[@]} }] || foo=()

> >> # @ECLASS-VARIABLE: INTEL_SINGLE_ARCH
> >> # @DESCRIPTION:
> >> # Unset, if only the multilib package will be provided by intel
> >> : ${INTEL_SINGLE_ARCH:=true}  
> > 
> > This is really weird. It sounds like I'm supposed to do:
> > 
> >   inherit intel-sdp-r1
> >   unset INTEL_SINGLE_ARCH
> > 
> > I suggest you used positive logic instead.  
> 
> The wording is wrong. Setting it to anything but "true" like
> "INTEL_SINGLE_ARCH=false" works. We will fix the wording.

I still think positive logic is better. That is, a variable which
defaults to, say, unset, and changes behavior if it becomes set to
non-empty value.

> >> _isdp_big-warning() {
> >>debug-print-function ${FUNCNAME} "${@}"
> >>
> >>case ${1} in
> >>pre-check )
> >>echo ""  
> > 
> > Don't mix echo with ewarn.  
> 
> Why?

Because they won't go through the same output channels.

> >>
> >> comp_full="${ED}/${INTEL_SDP_DIR}/linux/bin/${arch}/${comp}"  
> > 
> > Double slash imminent (ED has one).  
> 
> Always? Per definition?

Yes, sadly. i wanted to change this but it's unlikely to go since it
makes EAPI migration hard. If you really want to cover both cases, you
can always do ${foo%/}/bar.

> >> # @CODE  
> > 
> > Err, this is not code, you know.  
> 
> This is needed for nice formatting. Otherwise there is no line break

Add an empty line between the two. That should do it correctly, without
code blocks in devmanual.

> >>#maybe use nullglob or [[ $(echo ${dir/*lic) != 
> >> "${dir}/*lic" ]]
> >>[[ $( ls "${dir}"/*lic 2>/dev/null ) ]]; ret=$?  
> > 
> > Maybe you should use something sane indeed.

Maybe file_exists from eutils could help here btw.

> > Wouldn't you be able to collapse that into one loop?  
> 
> no, because the first has ${INTEL_X86}.rpm as suffeix and the later has
> ${INTEL_X86}.rpm.

Er... am I reading wrong, or did you just type the same thing twice?

> >>einfo "Unpacking ${rb}"
> >>rpm2tar -O ${r} | tar xvf - | sed -e \
> >>"s:^\.:${EROOT#/}:g" > /dev/null; assert 
> >> "unpacking ${r} failed"  
> > 
> > What's the deal with this sed?  
> 
> Good question, but it was there since always and probably the original
> author had good reasons for it. We will look into it and comment the code.

Didn't it change in the past? As I see it, tar here outputs file names,
sed edits them and then you discard them to /dev/null. In this case,
sed doesn't return any specific exit code so it seems to be a complete
no-op.

Maybe originally it verbosely output the extracted files.

> >> EXPORT_FUNCTIONS pkg_setup src_unpack src_install pkg_postinst pkg_postrm 
> >> pkg_pretend  
> > 
> > We usually do this on top, and it's better to do it outside guards so
> > that order from inherit is always respected.  
> 
> we will move it up. I don't get your second comment. Do you mean the
> case someone does
> 
> inherit intel-sdp-r1 some-other-eclass intel-sdp
> 
> ?

Rather something unlikely like:

  inherit foo bar intel-sdp-r1

where foo inherits intel-sdp-r1, and therefore the exports occur before
bar, and bar takes over even though intel-sdp-r1 is explicitly
listed last.

-- 
Best regards,
Michał Górny



pgphcHLAeH1_H.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: intel-sdp-r1.eclass

[Justin Lecher (jlec)]

On 15/02/16 13:59, Michał Górny wrote:
> On Mon, 15 Feb 2016 09:16:53 +0100
> "Justin Lecher (jlec)"  wrote:
> 
>> # Copyright 1999-2016 Gentoo Foundation
>> # Distributed under the terms of the GNU General Public License v2
>> # $Id$
>>
>> # @ECLASS: intel-sdp-r1.eclass
>> # @MAINTAINER:
>> # Justin Lecher 
>> # David Seifert 
>> # Sci Team 
>> # @BLURB: Handling of Intel's Software Development Products package 
>> management
>>
>> if [[ ! ${_INTEL_SDP_R1_ECLASS_} ]]; then
>>
>> case "${EAPI:-0}" in
> 
> :-0 is meaningless here.
> 
>>  6) ;;
>>  *) die "EAPI=${EAPI} is not supported" ;;
> 
> If at all, it could be helpful here.

We had that before, will fix it.

> 
>> esac
>>
>> # @ECLASS-VARIABLE: INTEL_DID
>> # @DEFAULT_UNSET
>> # @DESCRIPTION:
>> # The package download ID from Intel.
>> # To find out its value, see the links to download in
>> # https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
>> #
>> # e.g. 8365
>> #
>> # Must be defined before inheriting the eclass
>>
>> # @ECLASS-VARIABLE: INTEL_DPN
>> # @DEFAULT_UNSET
>> # @DESCRIPTION:
>> # The package name to download from Intel.
>> # To find out its value, see the links to download in
>> # https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
>> #
>> # e.g. parallel_studio_xe
>> #
>> # Must be defined before inheriting the eclass
>>
>> # @ECLASS-VARIABLE: INTEL_DPV
>> # @DEFAULT_UNSET
>> # @DESCRIPTION:
>> # The package download version from Intel.
>> # To find out its value, see the links to download in
>> # https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
>> #
>> # e.g. 2016_update1
>> #
>> # Must be defined before inheriting the eclass
>>
>> # @ECLASS-VARIABLE: INTEL_TARX
>> # @DESCRIPTION:
>> # The package extention.
> 
> Extension. Or if you're not on Windows, then 'suffix'.

Fair enough.

> 
>> # To find out its value, see the links to download in
>> # https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
>> #
>> # e.g. tar.gz
>> #
>> # Must be defined before inheriting the eclass
>> : ${INTEL_TARX:=tgz}
>>
>> # @ECLASS-VARIABLE: INTEL_SUBDIR
>> # @DEFAULT_UNSET
>> # @DESCRIPTION:
>> # The package sub-directory where it will end-up in /opt/intel
>> # To find out its value, you have to do a raw install from the Intel tar ball
> 
> To be honest, I find this kinda terrible. There's a huge block of docs
> which makes me feel small and confused. Maybe it'd useful to give some
> semi-complete example on top (in global doc)?

That makes definitely make sense. We will add one.

Although nobody other then the maintainer of this eclass will ever use it.

> 
>> # @ECLASS-VARIABLE: INTEL_SKIP_LICENSE
>> # @DEFAULT_UNSET
>> # @DESCRIPTION:
>> # Possibility to skip the mandatory check for licenses. Only set this if 
>> there
>> # is really no fix.
>>
>> # @ECLASS-VARIABLE: INTEL_RPMS_DIR
>> # @DESCRIPTION:
>> # Main subdirectory which contains the rpms to extract.
>> : ${INTEL_RPMS_DIR:=rpm}
>>
>> # @ECLASS-VARIABLE: INTEL_X86
>> # @DESCRIPTION:
>> # 32bit arch in rpm names
>> #
>> # e.g. i486
>> : ${INTEL_X86:=i486}
>>
>> # @ECLASS-VARIABLE: INTEL_BIN_RPMS
>> # @DESCRIPTION:
>> # Functional name of rpm without any version/arch tag
>> # Has to be a bash array
>> #
>> # e.g. ("icc-l-all-devel")
>> #
>> # if the rpm is located in a directory other than INTEL_RPMS_DIR you can
>> # specify the full path
>> #
>> # e.g. CLI_install/rpm/intel-vtune-amplifier-xe-cli
>> : ${INTEL_BIN_RPMS:=()}
> 
> $ : ${foo:=()}
> $ declare -p foo
> declare -- foo="()"
> 
> In other words, it doesn't work the way you expect it to.

I already wondered about this. Is there any way to force a variable to
be an array in bash? Or define it as an empty array?

> 
>> # @ECLASS-VARIABLE: INTEL_AMD64_RPMS
>> # @DESCRIPTION:
>> # AMD64 single arch rpms. Same syntax as INTEL_BIN_RPMS
>> # Has to be a bash array
>> : ${INTEL_AMD64_RPMS:=()}
>>
>> # @ECLASS-VARIABLE: INTEL_X86_RPMS
>> # @DESCRIPTION:
>> # X86 single arch rpms. Same syntax as INTEL_BIN_RPMS
>> # Has to be a bash array
>> : ${INTEL_X86_RPMS:=()}
>>
>> # @ECLASS-VARIABLE: INTEL_DAT_RPMS
>> # @DESCRIPTION:
>> # Functional name of rpm of common data which are arch free
>> # without any version tag
>> # Has to be a bash array
>> #
>> # e.g. ("openmp-l-all-devel")
>> #
>> # if the rpm is located in a directory different to INTEL_RPMS_DIR you can
>> # specify the full path
>> #
>> # e.g. CLI_install/rpm/intel-vtune-amplifier-xe-cli-common
>> : ${INTEL_DAT_RPMS:=()}
>>
>> # @ECLASS-VARIABLE: INTEL_SINGLE_ARCH
>> # @DESCRIPTION:
>> # Unset, if only the multilib package will be provided by intel
>> : ${INTEL_SINGLE_ARCH:=true}
> 
> This is really weird. It sounds like I'm supposed to do:
> 
>   inherit intel-sdp-r1
>   unset INTEL_SINGLE_ARCH
> 
> I suggest you used positive logic instead.

The wording is wrong. Setting it to anything but "true" like
"INTEL_SINGLE_ARCH=false" works. We will fix the wording.

> 
>> 

Re: [gentoo-dev] RFC: intel-sdp-r1.eclass

[Michał Górny]

On Mon, 15 Feb 2016 09:16:53 +0100
"Justin Lecher (jlec)"  wrote:

> # Copyright 1999-2016 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Id$
> 
> # @ECLASS: intel-sdp-r1.eclass
> # @MAINTAINER:
> # Justin Lecher 
> # David Seifert 
> # Sci Team 
> # @BLURB: Handling of Intel's Software Development Products package management
> 
> if [[ ! ${_INTEL_SDP_R1_ECLASS_} ]]; then
> 
> case "${EAPI:-0}" in

:-0 is meaningless here.

>   6) ;;
>   *) die "EAPI=${EAPI} is not supported" ;;

If at all, it could be helpful here.

> esac
> 
> # @ECLASS-VARIABLE: INTEL_DID
> # @DEFAULT_UNSET
> # @DESCRIPTION:
> # The package download ID from Intel.
> # To find out its value, see the links to download in
> # https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
> #
> # e.g. 8365
> #
> # Must be defined before inheriting the eclass
> 
> # @ECLASS-VARIABLE: INTEL_DPN
> # @DEFAULT_UNSET
> # @DESCRIPTION:
> # The package name to download from Intel.
> # To find out its value, see the links to download in
> # https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
> #
> # e.g. parallel_studio_xe
> #
> # Must be defined before inheriting the eclass
> 
> # @ECLASS-VARIABLE: INTEL_DPV
> # @DEFAULT_UNSET
> # @DESCRIPTION:
> # The package download version from Intel.
> # To find out its value, see the links to download in
> # https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
> #
> # e.g. 2016_update1
> #
> # Must be defined before inheriting the eclass
> 
> # @ECLASS-VARIABLE: INTEL_TARX
> # @DESCRIPTION:
> # The package extention.

Extension. Or if you're not on Windows, then 'suffix'.

> # To find out its value, see the links to download in
> # https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
> #
> # e.g. tar.gz
> #
> # Must be defined before inheriting the eclass
> : ${INTEL_TARX:=tgz}
> 
> # @ECLASS-VARIABLE: INTEL_SUBDIR
> # @DEFAULT_UNSET
> # @DESCRIPTION:
> # The package sub-directory where it will end-up in /opt/intel
> # To find out its value, you have to do a raw install from the Intel tar ball

To be honest, I find this kinda terrible. There's a huge block of docs
which makes me feel small and confused. Maybe it'd useful to give some
semi-complete example on top (in global doc)?

> # @ECLASS-VARIABLE: INTEL_SKIP_LICENSE
> # @DEFAULT_UNSET
> # @DESCRIPTION:
> # Possibility to skip the mandatory check for licenses. Only set this if there
> # is really no fix.
> 
> # @ECLASS-VARIABLE: INTEL_RPMS_DIR
> # @DESCRIPTION:
> # Main subdirectory which contains the rpms to extract.
> : ${INTEL_RPMS_DIR:=rpm}
> 
> # @ECLASS-VARIABLE: INTEL_X86
> # @DESCRIPTION:
> # 32bit arch in rpm names
> #
> # e.g. i486
> : ${INTEL_X86:=i486}
> 
> # @ECLASS-VARIABLE: INTEL_BIN_RPMS
> # @DESCRIPTION:
> # Functional name of rpm without any version/arch tag
> # Has to be a bash array
> #
> # e.g. ("icc-l-all-devel")
> #
> # if the rpm is located in a directory other than INTEL_RPMS_DIR you can
> # specify the full path
> #
> # e.g. CLI_install/rpm/intel-vtune-amplifier-xe-cli
> : ${INTEL_BIN_RPMS:=()}

$ : ${foo:=()}
$ declare -p foo
declare -- foo="()"

In other words, it doesn't work the way you expect it to.

> # @ECLASS-VARIABLE: INTEL_AMD64_RPMS
> # @DESCRIPTION:
> # AMD64 single arch rpms. Same syntax as INTEL_BIN_RPMS
> # Has to be a bash array
> : ${INTEL_AMD64_RPMS:=()}
> 
> # @ECLASS-VARIABLE: INTEL_X86_RPMS
> # @DESCRIPTION:
> # X86 single arch rpms. Same syntax as INTEL_BIN_RPMS
> # Has to be a bash array
> : ${INTEL_X86_RPMS:=()}
> 
> # @ECLASS-VARIABLE: INTEL_DAT_RPMS
> # @DESCRIPTION:
> # Functional name of rpm of common data which are arch free
> # without any version tag
> # Has to be a bash array
> #
> # e.g. ("openmp-l-all-devel")
> #
> # if the rpm is located in a directory different to INTEL_RPMS_DIR you can
> # specify the full path
> #
> # e.g. CLI_install/rpm/intel-vtune-amplifier-xe-cli-common
> : ${INTEL_DAT_RPMS:=()}
> 
> # @ECLASS-VARIABLE: INTEL_SINGLE_ARCH
> # @DESCRIPTION:
> # Unset, if only the multilib package will be provided by intel
> : ${INTEL_SINGLE_ARCH:=true}

This is really weird. It sounds like I'm supposed to do:

  inherit intel-sdp-r1
  unset INTEL_SINGLE_ARCH

I suggest you used positive logic instead.

> MULTILIB_COMPAT=( abi_x86_{32,64} )
> 
> inherit check-reqs eutils multilib-build versionator
> 
> _INTEL_PV1=$(get_version_component_range 1)
> _INTEL_PV2=$(get_version_component_range 2)
> _INTEL_PV3=$(get_version_component_range 3)
> _INTEL_PV4=$(get_version_component_range 4)

I'm pretty sure there's a better way than calling the same function
four times. For example:

  _INTEL_PV=( $(get_version_components) )

Plus, please reduce the environment pollution. Either unset all those
variables when no longer needed, or preferably create a function for
setting globals and make them local.

> _INTEL_PV=""
> [[ -n ${_INTEL_PV4} ]] && 

Re: [gentoo-dev] libressl: proposing a new project and calling for help

[Dirkjan Ochtman]

On Sun, Feb 14, 2016 at 10:38 PM, Anthony G. Basile  wrote:
> We discussed the state of libressl today in the council.  Proceeding
> forward with that work, I'm going to propose a new project and getting
> together a team.  Much of the work has already done by hasufell and what
> remain is just following through on his plan.

Is "his plan" detailed anywhere? In other words, what does it mean to
sign up for this project? :)

Cheers,

Dirkjan

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Francesco Riosa]

2016-02-14 21:23 GMT+01:00 Mike Frysinger :

> On 14 Feb 2016 11:41, Brian Dolbec wrote:
> > On Sun, 14 Feb 2016 11:00:30 -0500 Rich Freeman wrote:
> > > On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer wrote:
> > > > If, for any reason, eudev should be abandoned - we can just change
> > > > the virtual back. One-line change.
> > >
> > > Which is precisely the corresponding argument for not switching the
> > > default to eudev in the first place.
> >
> > OH, my, this is looking more like you are being paid by systemd peeps...
>
> honestly ?  cut the crap man.
>
> > You are just refusing to acknowledge these simple facts.
> >
> > systemd.:  irrelevant to this decision
> >
> > standalone systemd-udev.:  Vehemently unsupported, support for its
> >capability to exist is planned to be punted
> >in the future.
> >
> > eudev...:  fully functional, actively developed,
> >and fully supported, mature project, been
> >around for years.
>
> udev: it's the default in every major distro that everyone tests and
> develops against.
>

This is NOT true, major distro use systemd, NOT udev as we use it.


>
> eudev: no one of any relevance outside of Gentoo runs it.
>

Neither this is totally true, or put another way, everybody which is NOT
using systemd is using eudev (or some form of static /dev).
So obviously this is totally relevant for people that don't use systemd.

Also, why, why people using systemd ARE interested in this thread?
You should not be interested at all.


>
> > Oh and here is one final piece that should blow your reason away
> >
> > https://github.com/gentoo/eudev   <== NOTICE that it's upstream is
> > within our gentoo domain.
>
> irrelevant.  any Gentoo dev can create any repo in that namespace even
> when they shouldn't.  the fact that eudev is in there does *not* mean
> the whole Gentoo project has signed on to it, or that it's some sort
> of "banner" project.  it means at least one Gentoo dev decided to do X
> and our project system doesn't require project consensus before X can
> proceed.  do not conflate these.
> -mike
>

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Mon, Feb 15, 2016 at 4:29 AM, Alexis Ballier  wrote:
> On Sun, 14 Feb 2016 19:34:52 -0600
> William Hubbs  wrote:
>
>> And, as for right now, udev-229 is in the tree, so udev can still be
>> extracted and run standalone from systemd.
>
> and even with that, I don't think there is anything preventing using
> systemd-udev from an openrc boot, is it ? (ie, have systemd installed
> but booting with openrc)
>

Correct, you can uninstall sys-fs/(e)udev and install
sys-apps/systemd, then boot with openrc, and udev will work just fine.

-- 
Rich

Re: [gentoo-dev] libressl: proposing a new project and calling for help

[Andreas K. Hüttel]

On Sunday 14 February 2016 22:38:19 Anthony G. Basile wrote:
> Hi everyone,
> 
> We discussed the state of libressl today in the council.  Proceeding
> forward with that work, I'm going to propose a new project and getting
> together a team.  Much of the work has already done by hasufell and what
> remain is just following through on his plan.
> 
> Before I put up a project page, can I ask who is interested in this?

I'd gladly take part, though sadly my Gentoo time is pretty much approaching 
zero these days. But maybe that will improve some day.

-- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Lars Wendler]

On Sun, 14 Feb 2016 13:10:07 +0100 Patrick Lauer wrote:

>On 02/09/2016 01:17 PM, Rich Freeman wrote:
>> On Tue, Feb 9, 2016 at 3:43 AM, Kent Fredric 
>> wrote: 
>>> And a lot of Gentoo is surprisingly simple: Like our use of bash
>>> scripts for recipies to build things, like using rsync to
>>> deploy/relay not just those recipies, but security notices and
>>> news items, which are themselves reasonably simple formats.  
>> Well, one thing about Gentoo that certainly isn't simple is our
>> init.d scripts.
>>
>> Compare this:
>> http://pastebin.com/sSDtpF4t  
>More stable link:
>https://gitweb.gentoo.org/proj/apache.git/tree/2.4/init/apache2.initd
>>
>> With this:
>> http://pastebin.com/Lfn8r7qP  
>More stable link:
>https://gitweb.gentoo.org/repo/gentoo.git/tree/www-servers/apache/files/apache2.2.service
>> Systemd does the job in 10% of the code (and half of it is a
>> comment), and doesn't implement its own service polling and killer
>> script during shutdown independently for every service (not that
>> every init.d script even does this - most of them will just leave
>> orphans behind, and systemd will catch orphans that even the lengthy
>> init.d script for apache misses).
>>  
>Right, that's a bad comparison.
>
>The equivalent OpenRC init script is:
>
>```
>#!/sbin/runscript
>command="/usr/sbin/apache2"
>command_args="${APACHE2_OPTS}"
>description_reload="A graceful restart advises the children to exit
>after the current request and reloads the configuration."
>
>stop() {
>$command $APACHE2_OPTS -k graceful-stop
>}
>reload() {
>$command $APACHE2_OPTS -k graceful
>}
>```
>So that's almost exactly the same (modulo braces and newlines). There's
>no equivalent for PrivateTmp, and we ignore the extra data in
>/etc/tmpfiles.d (for creating runtime dirs). Which is bad, but that's
>another rant ;)
>
>Just that the current initscript does a lot more, and ... uhm ... why
>is the systemd unit sourcing /etc/conf.d/apache2 ?

Becasue I don't give a damn about systemd and nobody cared to send
patches yet.

>(Oh, and dependencies, but those just slow down startup )
>
>So if you compile the equivalent naive init script there's not much
>difference, and the initial argument falls on its face and disappears.
>
>I'm getting tired of having this argument :)
>

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpcf9zp1NjJS.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/15/2016 01:29 AM, Alexis Ballier wrote:
> On Sun, 14 Feb 2016 19:34:52 -0600 William Hubbs
>  wrote:
> 
>> On Sun, Feb 14, 2016 at 03:50:38PM -0500, Mike Frysinger wrote:
>>> On 14 Feb 2016 15:47, Anthony G. Basile wrote:
 On 2/14/16 3:34 PM, Mike Frysinger wrote:
> the bring up of the daemon itself is not nearly as
> important as the runtime interaction of people using
> libudev or rules being executed.
 
 correct and i've been careful with libudev.
 
 anyhow, can we divert this away from udev/eudev.  mike what
 do you recommend as the future of openrc once systemd-udev
 can no longer be extracted.
>>> 
>>> if/when systemd-udev can't be extract anymore, then sys-fs/udev
>>> is dead, and this whole thread is fairly moot. -mike
>> 
>> +1.
>> 
>> And, as for right now, udev-229 is in the tree, so udev can still
>> be extracted and run standalone from systemd.
> 
> and even with that, I don't think there is anything preventing
> using systemd-udev from an openrc boot, is it ? (ie, have systemd
> installed but booting with openrc)
> 
systemd blocks both udev and eudev, since it includes systemd-udev. I
don't know enough to tell you if the udev that ships with systemd is
separated enough to act as a daemon with OpenRC, but package-wise it's
a blocker.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWwaIEAAoJEAEkDpRQOeFwDskP/0nwCQh71phL6Nc6F3EkTnzU
JLIP3QOpqKXdtDYXJ/jG9+w746CKC3K/lR7IHuqvrWMVETXblwERbF9XGwUWMvmO
nzFZ/K9pbNSQ+CiCqBGbs0HrXcXXjeosCf/sgl3FX3JIBgFordCS4t/WQMtmUbwF
i2unx4BzAp+H0lJ8CuhmQj4cqTu3jaZkM+eRoXxniBM1ELZ3TZIYWu4T4OdjrCyb
f77CNdm9sQTHFFhkYHf4unIdfwcfcin+x6vWYLmuQrBbuoqh9On4qAuQLjoZjjDk
JlhUhHgVX5OzGCd8vW6aD7FJNmMLLONKmhpv8aZZrhUda3QPzMuzjZFtYFwxrn1N
81YOROGyWL5TK/cVzpUjU7qmYIkGv/NXMrv42zOxmUINQnX7h0ny2SWnJ1jboJZb
isq2INnolrTTEV158eI1ij4usrxdLiDjKwCRoAVZP6eHWlKb/g2bFX5TjKrwiLfI
exS8r+aWLVj2ytEZIm6Uf0UNdGjTC5MQSHCxz5d0zx0/KHsz6COIiPZHdcvXfPME
dXuYVsmkdE/+4nFSvUPZ7w+eV0jFZB2C1X+at3l4I6a4itLxK/Sp/ydDXmAvlItQ
zTdQORHbu3BW+dvbuTwafZVCVsiZQKUtWZexGGkgeyKjxm3svGyT4UVPE5euk5M4
yUH3T+1z6Z3LYGM/We4M
=EuL7
-END PGP SIGNATURE-

[gentoo-dev] RFC: intel-sdp-r1.eclass

[Justin Lecher (jlec)]

Hi everyone,

We (actually mostly soap) rewrote parts of the intel-sdp.eclass and
decided to revbump it. Please review our changes.

Changes are:

* Move from EAPI=5 to 6
* Adopt to changed packaging layout
* Use ABI_ instead of multilib
* Drop eclipse support
* Require all RPM lists to be arrays
* Don't record in installation db


Thanks,

Justin
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

# @ECLASS: intel-sdp-r1.eclass
# @MAINTAINER:
# Justin Lecher 
# David Seifert 
# Sci Team 
# @BLURB: Handling of Intel's Software Development Products package management

if [[ ! ${_INTEL_SDP_R1_ECLASS_} ]]; then

case "${EAPI:-0}" in
6) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac

# @ECLASS-VARIABLE: INTEL_DID
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package download ID from Intel.
# To find out its value, see the links to download in
# https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
#
# e.g. 8365
#
# Must be defined before inheriting the eclass

# @ECLASS-VARIABLE: INTEL_DPN
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package name to download from Intel.
# To find out its value, see the links to download in
# https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
#
# e.g. parallel_studio_xe
#
# Must be defined before inheriting the eclass

# @ECLASS-VARIABLE: INTEL_DPV
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package download version from Intel.
# To find out its value, see the links to download in
# https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
#
# e.g. 2016_update1
#
# Must be defined before inheriting the eclass

# @ECLASS-VARIABLE: INTEL_TARX
# @DESCRIPTION:
# The package extention.
# To find out its value, see the links to download in
# https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
#
# e.g. tar.gz
#
# Must be defined before inheriting the eclass
: ${INTEL_TARX:=tgz}

# @ECLASS-VARIABLE: INTEL_SUBDIR
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package sub-directory where it will end-up in /opt/intel
# To find out its value, you have to do a raw install from the Intel tar ball

# @ECLASS-VARIABLE: INTEL_SKIP_LICENSE
# @DEFAULT_UNSET
# @DESCRIPTION:
# Possibility to skip the mandatory check for licenses. Only set this if there
# is really no fix.

# @ECLASS-VARIABLE: INTEL_RPMS_DIR
# @DESCRIPTION:
# Main subdirectory which contains the rpms to extract.
: ${INTEL_RPMS_DIR:=rpm}

# @ECLASS-VARIABLE: INTEL_X86
# @DESCRIPTION:
# 32bit arch in rpm names
#
# e.g. i486
: ${INTEL_X86:=i486}

# @ECLASS-VARIABLE: INTEL_BIN_RPMS
# @DESCRIPTION:
# Functional name of rpm without any version/arch tag
# Has to be a bash array
#
# e.g. ("icc-l-all-devel")
#
# if the rpm is located in a directory other than INTEL_RPMS_DIR you can
# specify the full path
#
# e.g. CLI_install/rpm/intel-vtune-amplifier-xe-cli
: ${INTEL_BIN_RPMS:=()}

# @ECLASS-VARIABLE: INTEL_AMD64_RPMS
# @DESCRIPTION:
# AMD64 single arch rpms. Same syntax as INTEL_BIN_RPMS
# Has to be a bash array
: ${INTEL_AMD64_RPMS:=()}

# @ECLASS-VARIABLE: INTEL_X86_RPMS
# @DESCRIPTION:
# X86 single arch rpms. Same syntax as INTEL_BIN_RPMS
# Has to be a bash array
: ${INTEL_X86_RPMS:=()}

# @ECLASS-VARIABLE: INTEL_DAT_RPMS
# @DESCRIPTION:
# Functional name of rpm of common data which are arch free
# without any version tag
# Has to be a bash array
#
# e.g. ("openmp-l-all-devel")
#
# if the rpm is located in a directory different to INTEL_RPMS_DIR you can
# specify the full path
#
# e.g. CLI_install/rpm/intel-vtune-amplifier-xe-cli-common
: ${INTEL_DAT_RPMS:=()}

# @ECLASS-VARIABLE: INTEL_SINGLE_ARCH
# @DESCRIPTION:
# Unset, if only the multilib package will be provided by intel
: ${INTEL_SINGLE_ARCH:=true}

MULTILIB_COMPAT=( abi_x86_{32,64} )

inherit check-reqs eutils multilib-build versionator

_INTEL_PV1=$(get_version_component_range 1)
_INTEL_PV2=$(get_version_component_range 2)
_INTEL_PV3=$(get_version_component_range 3)
_INTEL_PV4=$(get_version_component_range 4)
_INTEL_PV=""
[[ -n ${_INTEL_PV4} ]] && _INTEL_PV+="${_INTEL_PV4}-"
[[ -n ${_INTEL_PV1} ]] && _INTEL_PV+="${_INTEL_PV1}"
[[ -n ${_INTEL_PV2} ]] && _INTEL_PV+=".${_INTEL_PV2}"
[[ -n ${_INTEL_PV3} ]] && _INTEL_PV+=".${_INTEL_PV3}"
[[ -n ${_INTEL_PV4} ]] && _INTEL_PV+="-${_INTEL_PV4}"

_INTEL_URI="http://registrationcenter-download.intel.com/akdlm/irc_nas/${INTEL_DID}/${INTEL_DPN};

if [ ${INTEL_SINGLE_ARCH} == true ]; then
SRC_URI="
abi_x86_32? ( ${_INTEL_URI}_${INTEL_DPV}_ia32.${INTEL_TARX} )
abi_x86_64? ( ${_INTEL_URI}_${INTEL_DPV}_intel64.${INTEL_TARX} 
)"
else
SRC_URI="${_INTEL_URI}_${INTEL_DPV}.${INTEL_TARX}"
fi

LICENSE="Intel-SDP"
# Future work, #394411
#SLOT="${_INTEL_PV1}.${_INTEL_PV2}"
SLOT="0"

RESTRICT="mirror"

RDEPEND=""
DEPEND="app-arch/rpm2targz"

_INTEL_SDP_YEAR=${INTEL_DPV}
_INTEL_SDP_YEAR=${_INTEL_SDP_YEAR%_sp*}
_INTEL_SDP_YEAR=${_INTEL_SDP_YEAR%_update*}

#