Re: [gentoo-dev] Looking for Perl help verifying old Gentoo elections
> On Fri, 03 Aug 2018, Michał Górny wrote: > Firstly, there is a result mismatch for council-201206 election. > More specifically, the countify results are: > [["dberkholz"], ["grobian"], ["chainsaw"], ["scarabeus"], ["ulm"], > ["betelgeuse"], ...] > While devotee considers ulm and betelgeuse tied: > [["dberkholz"], ["grobian"], ["chainsaw"], ["scarabeus"], > ["betelgeuse", "ulm"], ...] I haven't checked any of the perl code, but the online voting calculator at https://www.cse.wustl.edu/~legrand/rbvote/calc.html agrees with the countify ranking. Ulrich
[gentoo-dev] News item review: OpenSSH LDAP support
Hello everyone, please review the following news item. The 'xx'-es will be replaced with the publication date. --- Title: OpenSSH LDAP support Author: Thomas Deutschmann Posted: 2018-08-xx Revision: 1 News-Item-Format: 2.0 Display-If-Installed: net-misc/openssh When your sshd authenticates against LDAP, you have to migrate your current setup to a new one using sshd's "AuthorizedKeysCommand" option and use a wrapper provided by packages like the new sys-auth/ssh-ldap-pubkey because beginning with net-misc/openssh-7.7_p1, deprecated OpenSSH-LPK patch set no longer applies. We have created a short migration guide in the Wiki [1] for more details. [1] https://wiki.gentoo.org/wiki/SSH/LDAP_migration --- sys-auth/ssh-ldap-pubkey isn't yet available in Gentoo repository. We will publish together with the merge of PR 9400 [1]. See also: = [1] https://github.com/gentoo/gentoo/pull/9400 -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Looking for Perl help verifying old Gentoo elections
W dniu pią, 03.08.2018 o godzinie 18∶28 +0300, użytkownik Andrew Savchenko napisał: > On Fri, 03 Aug 2018 17:00:51 +0200 Michał Górny wrote: > > Hi, everyone. > > > > Inspired by Robin, I've started working on scripts to verify old Gentoo > > election results. Since our election mechanism is apparently the same > > as used by Debian, it seemed an obvious choice to use the Debian tooling > > (devotee) to verify our results. > > As far as I know it is not the same. While we both use Condorcet > method, Gentoo allows several nominees with the same rank, while > Debian does not. > They actually do: > Voters may rank options equally. [1] [1]:https://www.debian.org/devel/constitution.en.html A.6 -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Looking for Perl help verifying old Gentoo elections
On Fri, 03 Aug 2018 17:00:51 +0200 Michał Górny wrote: > Hi, everyone. > > Inspired by Robin, I've started working on scripts to verify old Gentoo > election results. Since our election mechanism is apparently the same > as used by Debian, it seemed an obvious choice to use the Debian tooling > (devotee) to verify our results. As far as I know it is not the same. While we both use Condorcet method, Gentoo allows several nominees with the same rank, while Debian does not. Best regards, Andrew Savchenko pgpKGpagYe9H7.pgp Description: PGP signature
[gentoo-dev] Looking for Perl help verifying old Gentoo elections
Hi, everyone. Inspired by Robin, I've started working on scripts to verify old Gentoo election results. Since our election mechanism is apparently the same as used by Debian, it seemed an obvious choice to use the Debian tooling (devotee) to verify our results. I've been able to successfully 'convert' our elections to a minimal set of files needed to get devotee running, and wrap it via loop-script to get full election results (apparently devotee only finds the top winner while we want the complete ranked list) [1]. I've been able to successfully verify most of the Gentoo elections using that. However, I've hit two problems. Firstly, there is a result mismatch for council-201206 election. More specifically, the countify results are: [["dberkholz"], ["grobian"], ["chainsaw"], ["scarabeus"], ["ulm"], ["betelgeuse"], ...] While devotee considers ulm and betelgeuse tied: [["dberkholz"], ["grobian"], ["chainsaw"], ["scarabeus"], ["betelgeuse", "ulm"], ...] Secondly, a number of elections fail midway. More specifically, devotee doesn't output any winners at some stage. This specifically applies to: council-201706 (fails after tamiko) council2005 (fails after Koon) council200906 (fails after lu_zero) metastructure2005 (fails after Oldschool-small) That said, devotee outputs a lot of perl warnings and the code [2] doesn't seem to have been updated for a while now. Both issues seem to happen around 'weakest defeat' removal, so the bug might be there. I'd really appreciate if someone enjoying Perl code could help me figure out what's wrong -- and more specifically, whether it's some 'bad Perl' issue, disjoint algorithm or something entirely different. Quick tip on using: # note: current version of Perl seems to be buggy # I had to do: cpan install Math::BigInt git clone https://github.com/mgorny/election-compare.git cd election-compare git submodule init git submodule update ./run-countify.py -v council-201206 2>countify-out.txt ./run-devotee.py -v council-201206 2>devotee-out.txt Then the *-out.txt files contain complete output from tools ran. TIA. [1]:https://github.com/mgorny/election-compare [2]:https://vote.debian.org/~secretary/devotee.git/ -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Cross compilation tracker bug
I have opened a tracker bug for cross compilation issues: https://bugs.gentoo.org/662714 Bugs on packages that fail to build with crossdev and patches for those bugs are more than welcome. :) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] multilib: allow specifying the subtype of library in get_libname
On Fri, Aug 03, 2018 at 09:13:35AM +0200, Fabian Groffen wrote:
> Just wondering, we have get_libname, get_modname, shouldn't we just
> introduce get_linklibname or something instead of trying to overload
> get_libname?
>
> The implementation of get_linklibname could be to just call get_libname
> for anything but mingw of course.
Actually that's a pretty good idea... Possibly with a warning to migrate
to the proper one in later eapis. Also, runtime libraries are a bit fun
too. for say, libFLAC(get_libname 8) on linux, you'd get libFLAC.so.8,
but on mingw-w64, you'd want libFLAC-8.dll on a mingw-w64 build.
>
> Fabian
>
> On 03-08-2018 00:09:41 -0500, Marty E. Plummer wrote:
> > Signed-off-by: Marty E. Plummer
> > ---
> >
> > On mingw-w64 (and perhaps cygwin and mingw.org), there are two forms of
> > non-static libraries. Standard *.dll libraries are for runtime and are
> > loaded from %PATH% on windows systems, and are typically stored in
> > either /bin or /usr/bin on mingw-w64 cross-toolchain filesystems. Import
> > libraries, *.dll.a, are used when linking and live in the ''normal''
> > libdirs, eg, /lib, /usr/lib and so on.
> >
> > A number of ebuilds which otherwise work on mingw-w64 crossdev
> > toolchains exhibit failure due to usage of get_libname not being able to
> > specify which of the two types are required.
> >
> > For example, sys-libs/ncurses, uses the following snippet of code:
> > ln -sf libncurses$(get_libname)
> > "${ED}"/usr/$(get_libdir)/libcurses$(get_libname) || die
> > in order to create a 'libcurses.so -> libncurses.so' symlink.
> >
> > However, on a crossdev-built mingw-w64 toolchain, one will end up with a
> > broken 'libcurses.dll -> libncurses.dll' symlink, which should properly
> > be a 'libcurses.dll.a -> libncurses.dll.a' symlink, as the symlink here
> > is provided to allow linking with -lcurses instead of -lncurses.
> >
> > eclass/multilib.eclass | 52 ++
> > 1 file changed, 48 insertions(+), 4 deletions(-)
> >
> > diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
> > index 350b6f949d1..6a99f5977ec 100644
> > --- a/eclass/multilib.eclass
> > +++ b/eclass/multilib.eclass
> > @@ -239,26 +239,70 @@ get_exeext() {
> > }
> >
> > # @FUNCTION: get_libname
> > -# @USAGE: [version]
> > +# @USAGE: --link|--run [version]
> > # @DESCRIPTION:
> > # Returns libname with proper suffix {.so,.dylib,.dll,etc} and optionally
> > # supplied version for the current platform identified by CHOST.
> > #
> > +# If '--link' argument is passed, the linktime library's suffix is
> > returned,
> > +# as in the file that must exist to let `gcc -lfoo foo.c -o foo` to work.
> > +# If '--run' argument is passed, the runtime library's suffix is returned.
> > +#
> > +# In most unix-like platforms the two are identical, however on mingw-w64
> > the
> > +# linktime library has the suffix of '.dll.a' and the runtime library
> > '.dll'.
> > +#
> > # Example:
> > # get_libname ${PV}
> > # Returns: .so.${PV} (ELF) || .${PV}.dylib (MACH) || ...
> > +# get_libname --link
> > +# Returns: .so (ELF) || .dylib (MACH) || .dll.a (PE32) || ...
> > get_libname() {
> > - local libname
> > - local ver=$1
> > + local libtype="undefined"
> > + local libname opt ver
> > + for opt; do
> > + case "${opt}" in
> > + --link)
> > + libtype="link"
> > + shift
> > + ;;
> > + --run)
> > + libtype="run"
> > + shift
> > + ;;
> > + *)
> > + ;;
> > + esac
> > + done
> > + ver="$1"
> > + # general unixy types
> > case ${CHOST} in
> > *-cygwin*) libname="dll.a";; # import lib
> > - mingw*|*-mingw*) libname="dll";;
> > *-darwin*) libname="dylib";;
> > *-mint*) libname="irrelevant";;
> > hppa*-hpux*) libname="sl";;
> > *) libname="so";;
> > esac
> >
> > + # wierd mingw-w64 stuff, maybe even cygwin
> > + case ${CHOST} in
> > + mingw*|*-mingw*)
> > + case ${libtype} in
> > + link)
> > + libname="dll.a" # import library
> > + ;;
> > + run)
> > + libname="dll" # runtime library
> > + ;;
> > + undefined)
> > + eerror "please specify either --link or
> > --run to get_libname"
> > + eerror "for mingw builds, as there are
> > two types of libraries"
> > + eerror "on this platform"
> > + die
> > +
Re: [gentoo-dev] [PATCH] multilib: allow specifying the subtype of library in get_libname
Just wondering, we have get_libname, get_modname, shouldn't we just
introduce get_linklibname or something instead of trying to overload
get_libname?
The implementation of get_linklibname could be to just call get_libname
for anything but mingw of course.
Fabian
On 03-08-2018 00:09:41 -0500, Marty E. Plummer wrote:
> Signed-off-by: Marty E. Plummer
> ---
>
> On mingw-w64 (and perhaps cygwin and mingw.org), there are two forms of
> non-static libraries. Standard *.dll libraries are for runtime and are
> loaded from %PATH% on windows systems, and are typically stored in
> either /bin or /usr/bin on mingw-w64 cross-toolchain filesystems. Import
> libraries, *.dll.a, are used when linking and live in the ''normal''
> libdirs, eg, /lib, /usr/lib and so on.
>
> A number of ebuilds which otherwise work on mingw-w64 crossdev
> toolchains exhibit failure due to usage of get_libname not being able to
> specify which of the two types are required.
>
> For example, sys-libs/ncurses, uses the following snippet of code:
> ln -sf libncurses$(get_libname)
> "${ED}"/usr/$(get_libdir)/libcurses$(get_libname) || die
> in order to create a 'libcurses.so -> libncurses.so' symlink.
>
> However, on a crossdev-built mingw-w64 toolchain, one will end up with a
> broken 'libcurses.dll -> libncurses.dll' symlink, which should properly
> be a 'libcurses.dll.a -> libncurses.dll.a' symlink, as the symlink here
> is provided to allow linking with -lcurses instead of -lncurses.
>
> eclass/multilib.eclass | 52 ++
> 1 file changed, 48 insertions(+), 4 deletions(-)
>
> diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
> index 350b6f949d1..6a99f5977ec 100644
> --- a/eclass/multilib.eclass
> +++ b/eclass/multilib.eclass
> @@ -239,26 +239,70 @@ get_exeext() {
> }
>
> # @FUNCTION: get_libname
> -# @USAGE: [version]
> +# @USAGE: --link|--run [version]
> # @DESCRIPTION:
> # Returns libname with proper suffix {.so,.dylib,.dll,etc} and optionally
> # supplied version for the current platform identified by CHOST.
> #
> +# If '--link' argument is passed, the linktime library's suffix is returned,
> +# as in the file that must exist to let `gcc -lfoo foo.c -o foo` to work.
> +# If '--run' argument is passed, the runtime library's suffix is returned.
> +#
> +# In most unix-like platforms the two are identical, however on mingw-w64 the
> +# linktime library has the suffix of '.dll.a' and the runtime library '.dll'.
> +#
> # Example:
> # get_libname ${PV}
> # Returns: .so.${PV} (ELF) || .${PV}.dylib (MACH) || ...
> +# get_libname --link
> +# Returns: .so (ELF) || .dylib (MACH) || .dll.a (PE32) || ...
> get_libname() {
> - local libname
> - local ver=$1
> + local libtype="undefined"
> + local libname opt ver
> + for opt; do
> + case "${opt}" in
> + --link)
> + libtype="link"
> + shift
> + ;;
> + --run)
> + libtype="run"
> + shift
> + ;;
> + *)
> + ;;
> + esac
> + done
> + ver="$1"
> + # general unixy types
> case ${CHOST} in
> *-cygwin*) libname="dll.a";; # import lib
> - mingw*|*-mingw*) libname="dll";;
> *-darwin*) libname="dylib";;
> *-mint*) libname="irrelevant";;
> hppa*-hpux*) libname="sl";;
> *) libname="so";;
> esac
>
> + # wierd mingw-w64 stuff, maybe even cygwin
> + case ${CHOST} in
> + mingw*|*-mingw*)
> + case ${libtype} in
> + link)
> + libname="dll.a" # import library
> + ;;
> + run)
> + libname="dll" # runtime library
> + ;;
> + undefined)
> + eerror "please specify either --link or
> --run to get_libname"
> + eerror "for mingw builds, as there are
> two types of libraries"
> + eerror "on this platform"
> + die
> + ;;
> + esac
> + ;;
> + esac
> +
> if [[ -z $* ]] ; then
> echo ".${libname}"
> else
> --
> 2.18.0
>
>
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] multilib: allow specifying the subtype of library in get_libname
On Fri, Aug 03, 2018 at 08:25:28AM +0200, Michał Górny wrote:
> W dniu pią, 03.08.2018 o godzinie 00∶09 -0500, użytkownik Marty E.
> Plummer napisał:
> > Signed-off-by: Marty E. Plummer
> > ---
> >
> > On mingw-w64 (and perhaps cygwin and mingw.org), there are two forms of
> > non-static libraries. Standard *.dll libraries are for runtime and are
> > loaded from %PATH% on windows systems, and are typically stored in
> > either /bin or /usr/bin on mingw-w64 cross-toolchain filesystems. Import
> > libraries, *.dll.a, are used when linking and live in the ''normal''
> > libdirs, eg, /lib, /usr/lib and so on.
> >
> > A number of ebuilds which otherwise work on mingw-w64 crossdev
> > toolchains exhibit failure due to usage of get_libname not being able to
> > specify which of the two types are required.
> >
> > For example, sys-libs/ncurses, uses the following snippet of code:
> > ln -sf libncurses$(get_libname)
> > "${ED}"/usr/$(get_libdir)/libcurses$(get_libname) || die
> > in order to create a 'libcurses.so -> libncurses.so' symlink.
> >
> > However, on a crossdev-built mingw-w64 toolchain, one will end up with a
> > broken 'libcurses.dll -> libncurses.dll' symlink, which should properly
> > be a 'libcurses.dll.a -> libncurses.dll.a' symlink, as the symlink here
> > is provided to allow linking with -lcurses instead of -lncurses.
> >
> > eclass/multilib.eclass | 52 ++
> > 1 file changed, 48 insertions(+), 4 deletions(-)
> >
> > diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
> > index 350b6f949d1..6a99f5977ec 100644
> > --- a/eclass/multilib.eclass
> > +++ b/eclass/multilib.eclass
> > @@ -239,26 +239,70 @@ get_exeext() {
> > }
> >
> > # @FUNCTION: get_libname
> > -# @USAGE: [version]
> > +# @USAGE: --link|--run [version]
>
> It's optional, so it should go into square brackets.
>
True, it's optional for most platforms, but should be explicit on
ebuilds which are relevant to the 'wierd' ones.
> > # @DESCRIPTION:
> > # Returns libname with proper suffix {.so,.dylib,.dll,etc} and optionally
> > # supplied version for the current platform identified by CHOST.
> > #
> > +# If '--link' argument is passed, the linktime library's suffix is
> > returned,
> > +# as in the file that must exist to let `gcc -lfoo foo.c -o foo` to work.
> > +# If '--run' argument is passed, the runtime library's suffix is returned.
>
> '...as the first argument'. If order matters, make sure to explicitly
> specify that.
>
Yeah, that will need to go first because of the arg parse code I used.
Will add that.
> > +#
> > +# In most unix-like platforms the two are identical, however on mingw-w64
> > the
> > +# linktime library has the suffix of '.dll.a' and the runtime library
> > '.dll'.
>
> Also, you want to explicitly specify what happens if neither is passed.
>
The intent is that for every ebuild which makes sense for
windows/cygwin/etc it has to be passed, and in which case it errors out
for the weirdos like me to file a bug/patch/pr to get the correct
behavior. For instance, I'm highly doubting anyone is going to be able
to use sys-cluster/gasnet on windows or the like, so it can stay as is,
but other libraries are going to have hella issue based on the
difference between a dll and dll.a, and should be specified.
> > +#
> > # Example:
> > # get_libname ${PV}
> > # Returns: .so.${PV} (ELF) || .${PV}.dylib (MACH) || ...
> > +# get_libname --link
> > +# Returns: .so (ELF) || .dylib (MACH) || .dll.a (PE32) || ...
> > get_libname() {
> > - local libname
> > - local ver=$1
> > + local libtype="undefined"
> > + local libname opt ver
> > + for opt; do
> > + case "${opt}" in
> > + --link)
> > + libtype="link"
> > + shift
> > + ;;
> > + --run)
> > + libtype="run"
> > + shift
> > + ;;
> > + *)
> > + ;;
> > + esac
> > + done
> > + ver="$1"
>
> + # general unixy types
> > case ${CHOST} in
> > *-cygwin*) libname="dll.a";; # import lib
> > - mingw*|*-mingw*) libname="dll";;
> > *-darwin*) libname="dylib";;
> > *-mint*) libname="irrelevant";;
> > hppa*-hpux*) libname="sl";;
> > *) libname="so";;
> > esac
> >
> > + # wierd mingw-w64 stuff, maybe even cygwin
> > + case ${CHOST} in
> > + mingw*|*-mingw*)
> > + case ${libtype} in
> > + link)
> > + libname="dll.a" # import library
> > + ;;
> > + run)
> > + libname="dll" # runtime library
> > + ;;
> > +
Re: [gentoo-dev] [PATCH] multilib: allow specifying the subtype of library in get_libname
W dniu pią, 03.08.2018 o godzinie 00∶09 -0500, użytkownik Marty E.
Plummer napisał:
> Signed-off-by: Marty E. Plummer
> ---
>
> On mingw-w64 (and perhaps cygwin and mingw.org), there are two forms of
> non-static libraries. Standard *.dll libraries are for runtime and are
> loaded from %PATH% on windows systems, and are typically stored in
> either /bin or /usr/bin on mingw-w64 cross-toolchain filesystems. Import
> libraries, *.dll.a, are used when linking and live in the ''normal''
> libdirs, eg, /lib, /usr/lib and so on.
>
> A number of ebuilds which otherwise work on mingw-w64 crossdev
> toolchains exhibit failure due to usage of get_libname not being able to
> specify which of the two types are required.
>
> For example, sys-libs/ncurses, uses the following snippet of code:
> ln -sf libncurses$(get_libname)
> "${ED}"/usr/$(get_libdir)/libcurses$(get_libname) || die
> in order to create a 'libcurses.so -> libncurses.so' symlink.
>
> However, on a crossdev-built mingw-w64 toolchain, one will end up with a
> broken 'libcurses.dll -> libncurses.dll' symlink, which should properly
> be a 'libcurses.dll.a -> libncurses.dll.a' symlink, as the symlink here
> is provided to allow linking with -lcurses instead of -lncurses.
>
> eclass/multilib.eclass | 52 ++
> 1 file changed, 48 insertions(+), 4 deletions(-)
>
> diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
> index 350b6f949d1..6a99f5977ec 100644
> --- a/eclass/multilib.eclass
> +++ b/eclass/multilib.eclass
> @@ -239,26 +239,70 @@ get_exeext() {
> }
>
> # @FUNCTION: get_libname
> -# @USAGE: [version]
> +# @USAGE: --link|--run [version]
It's optional, so it should go into square brackets.
> # @DESCRIPTION:
> # Returns libname with proper suffix {.so,.dylib,.dll,etc} and optionally
> # supplied version for the current platform identified by CHOST.
> #
> +# If '--link' argument is passed, the linktime library's suffix is returned,
> +# as in the file that must exist to let `gcc -lfoo foo.c -o foo` to work.
> +# If '--run' argument is passed, the runtime library's suffix is returned.
'...as the first argument'. If order matters, make sure to explicitly
specify that.
> +#
> +# In most unix-like platforms the two are identical, however on mingw-w64 the
> +# linktime library has the suffix of '.dll.a' and the runtime library '.dll'.
Also, you want to explicitly specify what happens if neither is passed.
> +#
> # Example:
> # get_libname ${PV}
> # Returns: .so.${PV} (ELF) || .${PV}.dylib (MACH) || ...
> +# get_libname --link
> +# Returns: .so (ELF) || .dylib (MACH) || .dll.a (PE32) || ...
> get_libname() {
> - local libname
> - local ver=$1
> + local libtype="undefined"
> + local libname opt ver
> + for opt; do
> + case "${opt}" in
> + --link)
> + libtype="link"
> + shift
> + ;;
> + --run)
> + libtype="run"
> + shift
> + ;;
> + *)
> + ;;
> + esac
> + done
> + ver="$1"
+ # general unixy types
> case ${CHOST} in
> *-cygwin*) libname="dll.a";; # import lib
> - mingw*|*-mingw*) libname="dll";;
> *-darwin*) libname="dylib";;
> *-mint*) libname="irrelevant";;
> hppa*-hpux*) libname="sl";;
> *) libname="so";;
> esac
>
> + # wierd mingw-w64 stuff, maybe even cygwin
> + case ${CHOST} in
> + mingw*|*-mingw*)
> + case ${libtype} in
> + link)
> + libname="dll.a" # import library
> + ;;
> + run)
> + libname="dll" # runtime library
> + ;;
> + undefined)
> + eerror "please specify either --link or
> --run to get_libname"
> + eerror "for mingw builds, as there are
> two types of libraries"
> + eerror "on this platform"
> + die
> + ;;
> + esac
> + ;;
> + esac
> +
> if [[ -z $* ]] ; then
> echo ".${libname}"
> else
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
