[gentoo-dev] Re: [PATCH] cmake-utils.eclass: Extend ASM rules to ASM-ATT
On 02/25/2018 08:06 PM, Michał Górny wrote:
> Some CMake projects use ASM-ATT rather than ASM, so extend our rule
> overrides to that.
>
> Bug: https://bugs.gentoo.org/625844
> ---
> eclass/cmake-utils.eclass | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index b9f69a824b14..ef3f3c2607f8 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -516,6 +516,7 @@ cmake-utils_src_configure() {
> fi
> cat > "${build_rules}" <<- _EOF_ || die
> SET (CMAKE_ASM_COMPILE_OBJECT "
> ${includes} ${CPPFLAGS} -o -c " CACHE STRING "ASM
> compile command" FORCE)
> + SET (CMAKE_ASM-ATT_COMPILE_OBJECT "
> ${includes} ${CPPFLAGS} -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)
> @@ -531,6 +532,7 @@ cmake-utils_src_configure() {
> local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
> cat > ${toolchain_file} <<- _EOF_ || die
> SET (CMAKE_ASM_COMPILER "${myCC/ /;}")
> + SET (CMAKE_ASM-ATT_COMPILER "${myCC/ /;}")
> SET (CMAKE_C_COMPILER "${myCC/ /;}")
> SET (CMAKE_CXX_COMPILER "${myCXX/ /;}")
> SET (CMAKE_Fortran_COMPILER "${myFC/ /;}")
> @@ -609,6 +611,7 @@ cmake-utils_src_configure() {
> if [[ ${CMAKE_BUILD_TYPE} != Gentoo && ${EAPI} != 5 ]]; then
> cat >> ${common_config} <<- _EOF_ || die
> SET (CMAKE_ASM_FLAGS_${CMAKE_BUILD_TYPE^^} "" CACHE
> STRING "")
> + SET (CMAKE_ASM-ATT_FLAGS_${CMAKE_BUILD_TYPE^^} "" CACHE
> STRING "")
> SET (CMAKE_C_FLAGS_${CMAKE_BUILD_TYPE^^} "" CACHE
> STRING "")
> SET (CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE^^} "" CACHE
> STRING "")
> SET (CMAKE_Fortran_FLAGS_${CMAKE_BUILD_TYPE^^} "" CACHE
> STRING "")
>
LGTM
[gentoo-dev] Re: [PATCH] cmake-utils.eclass: Override CMAKE_INSTALL_{INFO,MAN}DIR
On 03/02/2018 02:40 AM, Michał Górny wrote:
> Provide an explicit override for CMAKE_INSTALL_INFODIR
> and CMAKE_INSTALL_MANDIR to force Gentoo standards for those locations.
> This is needed for Gentoo/FreeBSD where CMake defaults to /usr/info
> and /usr/man; while PMS specifies /usr/share/info and /usr/share/man
> via econf & do* helpers.
> ---
> eclass/cmake-utils.eclass | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index b9f69a824b14..636927d66491 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -602,6 +602,8 @@ cmake-utils_src_configure() {
> SET (CMAKE_GENTOO_BUILD ON CACHE BOOL "Indicate Gentoo package
> build")
> SET (LIB_SUFFIX ${libdir/lib} CACHE STRING "library path
> suffix" FORCE)
> SET (CMAKE_INSTALL_LIBDIR ${libdir} CACHE PATH "Output
> directory for libraries")
> + set (CMAKE_INSTALL_INFODIR "${EPREFIX}/usr/share/info" CACHE
> PATH "")
> + set (CMAKE_INSTALL_MANDIR "${EPREFIX}/usr/share/man" CACHE PATH
> "")
> _EOF_
> [[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo 'SET
> (CMAKE_COLOR_MAKEFILE OFF CACHE BOOL "pretty colors during make" FORCE)' >>
> "${common_config}"
>
>
There was some discussion in the past about adding these (and some
others), but at that time it was postponed until EAPI 7 due to concerns
about breaking existing packages. What do you think about the risk?
Re: [gentoo-dev] Re: [PATCH] cmake-utils.eclass: Override CMAKE_INSTALL_{INFO,MAN}DIR
W dniu pią, 02.03.2018 o godzinie 19∶53 +1100, użytkownik Michael
Palimaka napisał:
> On 03/02/2018 02:40 AM, Michał Górny wrote:
> > Provide an explicit override for CMAKE_INSTALL_INFODIR
> > and CMAKE_INSTALL_MANDIR to force Gentoo standards for those locations.
> > This is needed for Gentoo/FreeBSD where CMake defaults to /usr/info
> > and /usr/man; while PMS specifies /usr/share/info and /usr/share/man
> > via econf & do* helpers.
> > ---
> > eclass/cmake-utils.eclass | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> > index b9f69a824b14..636927d66491 100644
> > --- a/eclass/cmake-utils.eclass
> > +++ b/eclass/cmake-utils.eclass
> > @@ -602,6 +602,8 @@ cmake-utils_src_configure() {
> > SET (CMAKE_GENTOO_BUILD ON CACHE BOOL "Indicate Gentoo package
> > build")
> > SET (LIB_SUFFIX ${libdir/lib} CACHE STRING "library path
> > suffix" FORCE)
> > SET (CMAKE_INSTALL_LIBDIR ${libdir} CACHE PATH "Output
> > directory for libraries")
> > + set (CMAKE_INSTALL_INFODIR "${EPREFIX}/usr/share/info" CACHE
> > PATH "")
> > + set (CMAKE_INSTALL_MANDIR "${EPREFIX}/usr/share/man" CACHE PATH
> > "")
> > _EOF_
> > [[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo 'SET
> > (CMAKE_COLOR_MAKEFILE OFF CACHE BOOL "pretty colors during make" FORCE)' >>
> > "${common_config}"
> >
> >
>
> There was some discussion in the past about adding these (and some
> others), but at that time it was postponed until EAPI 7 due to concerns
> about breaking existing packages. What do you think about the risk?
>
I think any real-life breakage is unlikely. GNUInstallDirs are not that
popular, and when they are used we can rather expect upstream to be
sane-ish enough not to redefine them with an incompatible meaning.
Then, even if upstream did something crazy that could be affected
by this, it's just documentation, so we shouldn't expect any major
damage.
--
Best regards,
Michał Górny
[gentoo-dev] Re: Make it easier to check upper bounds with repoman.
crocket posted on Thu, 01 Mar 2018 21:15:24 +0900 as excerpted: > https://github.com/gentoo-haskell/gentoo-haskell/issues/669 led me to > https://bugs.gentoo.org/555266 > > In other words, since repoman doesn't warn a repository manager about > upper bound violations, the manager often breaks dependencies. > It is often a problem with haskell overlay. > > Do developers oppose https://bugs.gentoo.org/555266 ? > What do you think of the issue? No apparent opposition, just not sufficient interest or need (at least since 2015, when the bug was filed) from those with the necessary coding skills to push it up in priority enough to get a patch for repoman. There has simply always been something else with a higher priority. Apparently haskell is most affected, but presumably nobody with the haskell team has either the repoman familiarity or the time to get it, prioritized high enough based on the severity of the problem to actually do something about it. So the problem remains... -- 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] Reliability test for hard drives and SSD
Hi there! Good news for all interested in hardware compatibility and reliability. I've started a new project to estimate reliability of hard drives and SSD in real-life conditions based on the SMART data reports collected by Linux users in the Linux-Hardware.org database since 2014. The initial data (SMART reports), analysis methods and results are publicly shared in a new github repository: https://github.com/linuxhw/SMART. Everyone can contribute to the report by uploading probes of their computers by the hw-probe tool! The primary aim of the project is to find drives with longest "power on hours" and minimal number of errors. The following formula is used to measure reliability: Power_On_Hours / (1 + Number_Of_Errors), i.e. time to the first error/between errors. Please be careful when reading the results table. Pay attention not only to the rating, but also to the number of checked model samples. If rating is low, then look at the number of power-on days and number of errors occurred. New drive models will appear at the end of the rating table and will move to the top in the case of long error-free operation. Thanks to ROSA, Gentoo, openSUSE, Arch, Fedora, Ubuntu, Debian, Mint users and others who had made this work possible by contribution to the database!
[gentoo-dev] Packages up for grabs due to retirement
Hi, due to my retirement, the following packages need a new maintainer: dev-java/boilerpipe dev-libs/grok dev-python/cfgio dev-python/disqus-python dev-python/django-openid-auth dev-python/django-opensearch dev-python/django-otp dev-python/django-otp-yubikey dev-python/django-phonenumber-field dev-python/django-two-factor-auth dev-python/ipcalc dev-python/pSQL dev-python/phonenumbers dev-python/py2neo dev-python/requests-oauthlib dev-python/shortuuid dev-python/twilio dev-python/twython dev-python/yubiotp net-analyzer/nagios-check_linux_bonding net-misc/openvpn-auth-ldap sci-biology/picard openvpn-auth-ldap, grok and django-two-factor-auth have open bugs: https://bugs.gentoo.org/buglist.cgi?email1=ercpe%40gentoo.org&emailassigned_to1=1&emailtype1=equals&query_format=advanced&resolution=--- Regards, Johann signature.asc Description: OpenPGP digital signature
