Re: [gentoo-portage-dev] [PATCH] sync: always pass -q to git-update-index

[Zac Medico]

On 11/02/2016 05:17 PM, Zac Medico wrote:
> On 11/02/2016 02:09 PM, Mike Gilbert wrote:
>> The -q option allows git-update-index to succeed even if there are
>> locally modified files present.
>>
>> X-Gentoo-Bug-URL: https://bugs.gentoo.org/552814#c58
>> ---
>>  pym/portage/sync/modules/git/git.py | 5 +
>>  1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/pym/portage/sync/modules/git/git.py 
>> b/pym/portage/sync/modules/git/git.py
>> index dc94ec9..3db6dc1 100644
>> --- a/pym/portage/sync/modules/git/git.py
>> +++ b/pym/portage/sync/modules/git/git.py
>> @@ -118,10 +118,7 @@ class GitSync(NewBase):
>>  if exitcode == os.EX_OK and self.repo.sync_depth is not None:
>>  # update-index --refresh is needed on some filesystems
>>  # (e.g. with overlayfs on squashfs)
>> -update_index_cmd = [self.bin_command, 'update-index']
>> -if quiet: # -q needs to go first
>> -update_index_cmd.append('-q')
>> -update_index_cmd.append('--refresh')
>> +update_index_cmd = [self.bin_command, 'update-index', 
>> '-q', '--refresh']
>>  
>>  exitcode = subprocess.call(update_index_cmd,
>>  cwd=portage._unicode_encode(self.repo.location))
>>
> 
> LGTM.
> 
> I just checked the man page, and this behavior is documented there:
> 
> -q
>  Quiet. If --refresh finds that the index needs an update, the default
> behavior is to error out. This option makes git update-index continue
> anyway.
> 

Actually we should probably add --unmerged, as suggested numerous times
by Martin Väth.
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] [PATCH] sync: always pass -q to git-update-index

[Zac Medico]

On 11/02/2016 02:09 PM, Mike Gilbert wrote:
> The -q option allows git-update-index to succeed even if there are
> locally modified files present.
> 
> X-Gentoo-Bug-URL: https://bugs.gentoo.org/552814#c58
> ---
>  pym/portage/sync/modules/git/git.py | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/pym/portage/sync/modules/git/git.py 
> b/pym/portage/sync/modules/git/git.py
> index dc94ec9..3db6dc1 100644
> --- a/pym/portage/sync/modules/git/git.py
> +++ b/pym/portage/sync/modules/git/git.py
> @@ -118,10 +118,7 @@ class GitSync(NewBase):
>   if exitcode == os.EX_OK and self.repo.sync_depth is not None:
>   # update-index --refresh is needed on some filesystems
>   # (e.g. with overlayfs on squashfs)
> - update_index_cmd = [self.bin_command, 'update-index']
> - if quiet: # -q needs to go first
> - update_index_cmd.append('-q')
> - update_index_cmd.append('--refresh')
> + update_index_cmd = [self.bin_command, 'update-index', 
> '-q', '--refresh']
>  
>   exitcode = subprocess.call(update_index_cmd,
>   cwd=portage._unicode_encode(self.repo.location))
> 

LGTM.

I just checked the man page, and this behavior is documented there:

-q
 Quiet. If --refresh finds that the index needs an update, the default
behavior is to error out. This option makes git update-index continue
anyway.
-- 
Thanks,
Zac

[gentoo-dev] [PATCH 2/2] cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530

[Maciej Mrozowski]

From: Maciej Mrozowski 

---
 eclass/cmake-utils.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 88d2163..23cc094 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -525,13 +525,13 @@ enable_cmake-utils_src_configure() {
 
local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
cat > ${toolchain_file} <<- _EOF_ || die
-   SET (CMAKE_C_COMPILER $(tc-getCC))
-   SET (CMAKE_CXX_COMPILER $(tc-getCXX))
-   SET (CMAKE_Fortran_COMPILER $(tc-getFC))
SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive 
manager" FORCE)
SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE FILEPATH 
"Archive index generator" FORCE)
_EOF_
 
+   # Bug 542530, export those instead of setting paths in toolchain file
+   local -x CC=$(tc-getCC) CXX=$(tc-getCXX) FC=$(tc-getFC)
+
if tc-is-cross-compiler; then
local sysname
case "${KERNEL:-linux}" in
-- 
2.7.3

[gentoo-dev] [PATCH 1/2] cmake-utils.eclass: CMake argument passing rework - clean build_rules and toolchain_file files from unrelated stuff (pass to CMake directly) - move some invariant CMake option

[Maciej Mrozowski]

From: Maciej Mrozowski 

---
 eclass/cmake-utils.eclass | 54 ++-
 1 file changed, 21 insertions(+), 33 deletions(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 393ee28..88d2163 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -517,13 +517,10 @@ enable_cmake-utils_src_configure() {
includes=""
fi
cat > "${build_rules}" <<- _EOF_ || die
-   SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive 
manager" FORCE)
SET (CMAKE_ASM_COMPILE_OBJECT "  
${includes} ${CFLAGS}  -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)
-   SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE FILEPATH 
"Archive index generator" FORCE)
-   SET (PKG_CONFIG_EXECUTABLE $(type -P $(tc-getPKG_CONFIG)) CACHE 
FILEPATH "pkg-config executable" FORCE)
_EOF_
 
local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
@@ -531,6 +528,8 @@ enable_cmake-utils_src_configure() {
SET (CMAKE_C_COMPILER $(tc-getCC))
SET (CMAKE_CXX_COMPILER $(tc-getCXX))
SET (CMAKE_Fortran_COMPILER $(tc-getFC))
+   SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive 
manager" FORCE)
+   SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE FILEPATH 
"Archive index generator" FORCE)
_EOF_
 
if tc-is-cross-compiler; then
@@ -571,32 +570,29 @@ enable_cmake-utils_src_configure() {
# in Prefix we need rpath and must ensure cmake gets 
our default linker path
# right ... except for Darwin hosts
IF (NOT APPLE)
-   SET (CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
-   SET (CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH 
"${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/usr/$(get_libdir);${EPREFIX}/$(get_libdir)"
-   CACHE STRING "" FORCE)
-
+   SET (CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
+   SET (CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH 
"${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/usr/$(get_libdir);${EPREFIX}/$(get_libdir)"
 CACHE STRING "" FORCE)
ELSE ()
-
-   SET(CMAKE_PREFIX_PATH "${EPREFIX}${PREFIX}" CACHE 
STRING "" FORCE)
-   SET(CMAKE_SKIP_BUILD_RPATH OFF CACHE BOOL "" FORCE)
-   SET(CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
-   SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE CACHE BOOL "")
-   SET(CMAKE_INSTALL_RPATH 
"${EPREFIX}${PREFIX}/lib;${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/usr/$(get_libdir);${EPREFIX}/$(get_libdir)"
 CACHE STRING "" FORCE)
-   SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE CACHE BOOL 
"" FORCE)
-   SET(CMAKE_INSTALL_NAME_DIR "${EPREFIX}${PREFIX}/lib" 
CACHE STRING "" FORCE)
-
+   SET(CMAKE_PREFIX_PATH "${EPREFIX}${PREFIX}" 
CACHE STRING "" FORCE)
+   SET(CMAKE_SKIP_BUILD_RPATH OFF CACHE BOOL "" 
FORCE)
+   SET(CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
+   SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE CACHE 
BOOL "")
+   SET(CMAKE_INSTALL_RPATH 
"${EPREFIX}${PREFIX}/lib;${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/usr/$(get_libdir);${EPREFIX}/$(get_libdir)"
 CACHE STRING "" FORCE)
+   SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE 
CACHE BOOL "" FORCE)
+   SET(CMAKE_INSTALL_NAME_DIR 
"${EPREFIX}${PREFIX}/lib" CACHE STRING "" FORCE)
ENDIF (NOT APPLE)
_EOF_
fi
 
# Common configure parameters (invariants)
-   local common_config=${BUILD_DIR}/gentoo_common_config.cmake
local libdir=$(get_libdir)
-   cat > "${common_config}" <<- _EOF_ || die
-   SET (LIB_SUFFIX ${libdir/lib} CACHE STRING "library path 
suffix" FORCE)
-   SET (CMAKE_INSTALL_LIBDIR ${libdir} CACHE PATH "Output 
directory for libraries")
-   _EOF_
-   [[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo 'SET 
(CMAKE_COLOR_MAKEFILE OFF CACHE BOOL "pretty colors during make" FORCE)' >> 
"${common_config}"
+   local cmakeargs=(
+   -DLIB_SUFFIX="${libdir/lib}"
+   

[gentoo-dev] [PATCH 0/2] cmake-utils small rework + bug 542530

[Maciej Mrozowski]

From: Maciej Mrozowski 

Bummer, let me start it properly again, this time sending to reachable address.

Maciej Mrozowski (2):
  cmake-utils.eclass: CMake argument passing rework - clean
build_rules and toolchain_file files from unrelated stuff (pass to
CMake directly) - move some invariant CMake options actually to
invariants parts - eliminate common_config (pass to CMake
directly) for better transparency
  cmake-utils.eclass: export compilers to environment instead of setting
in toolchain file, bug 542530

 eclass/cmake-utils.eclass | 60 +++
 1 file changed, 24 insertions(+), 36 deletions(-)

-- 
2.7.3

[gentoo-dev] Re: [PATCH 2/2] cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530

[Maciej Mrozowski]

On środa, 2 listopada 2016 04:00:06 CET Maciej Mrozowski wrote:
> ---
>  eclass/cmake-utils.eclass | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index 88d2163..f7eac26 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -525,13 +525,13 @@ enable_cmake-utils_src_configure() {
> 
>   local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
>   cat > ${toolchain_file} <<- _EOF_ || die
> - SET (CMAKE_C_COMPILER $(tc-getCC))
> - SET (CMAKE_CXX_COMPILER $(tc-getCXX))
> - SET (CMAKE_Fortran_COMPILER $(tc-getFC))
>   SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive
> manager" FORCE)
>   SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE FILEPATH 
> "Archive
> index generator" FORCE)
>   _EOF_
> 
> + # Bug 542530, export those instead of setting paths in toolchain file
> + tc-export CC CXX FC
> +
>   if tc-is-cross-compiler; then
>   local sysname
>   case "${KERNEL:-linux}" in

mgorny commented to use local instead:

local -x CC=$(tc-getCC)
...

If no other comments, I'll apply this and commit patches somewhere around next 
weekend. Would be nice if someone using some exotic prefix tried this (should 
work though, we feed various cross-compilers to cmake via env this way at 
work).

-- 
regards
MM

signature.asc
Description: This is a digitally signed message part.

[gentoo-portage-dev] [PATCH] sync: always pass -q to git-update-index

[Mike Gilbert]

The -q option allows git-update-index to succeed even if there are
locally modified files present.

X-Gentoo-Bug-URL: https://bugs.gentoo.org/552814#c58
---
 pym/portage/sync/modules/git/git.py | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/pym/portage/sync/modules/git/git.py 
b/pym/portage/sync/modules/git/git.py
index dc94ec9..3db6dc1 100644
--- a/pym/portage/sync/modules/git/git.py
+++ b/pym/portage/sync/modules/git/git.py
@@ -118,10 +118,7 @@ class GitSync(NewBase):
if exitcode == os.EX_OK and self.repo.sync_depth is not None:
# update-index --refresh is needed on some filesystems
# (e.g. with overlayfs on squashfs)
-   update_index_cmd = [self.bin_command, 'update-index']
-   if quiet: # -q needs to go first
-   update_index_cmd.append('-q')
-   update_index_cmd.append('--refresh')
+   update_index_cmd = [self.bin_command, 'update-index', 
'-q', '--refresh']
 
exitcode = subprocess.call(update_index_cmd,
cwd=portage._unicode_encode(self.repo.location))
-- 
2.10.2

Re: [gentoo-dev] newsitem: important fstab and localmount update, round 4

[William Hubbs]

On Wed, Nov 02, 2016 at 12:07:56PM +0300, Denis Lisov wrote:
> > The recommended solution is to convert fstab from using
> > "/dev/disk/by-*" to the LABEL=, UUID=, or PARTUUID= syntax.
> 
> Is there any specific reason to mention these three but not PARTLABEL=
> used for GPT (maybe not only GPT) partition labels?
 
The newsitem is just meant to be a description of the
change you need to make and refers you to the man pages for more
information. However, I can mention that tag as well.

William


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] Problems and limitations of the current version dependency specs

[William L. Thomson Jr.]

On Tuesday, November 1, 2016 1:31:55 AM EDT Michał Górny wrote:
>
> 1. How often do you find '~' useful? Do you think there should be
> additional operators that ignore revision part?

IMHO, this one should be a requirement anytime a project/package is split 
between multiple ebuilds. This is common for Java projects, where parts are 
built in pieces, and packaged on their own.

The rationale is if you are splitting up a package from a single source/
release version. All dependencies should be using the same version, beyond the 
same slot. I do not think upstreams will want to work or handle bugs that 
result from mixing versions of stuff. Nor should there even be potential for 
such issue by mixing versions.

I went so far as to make it a recommendation for Gentoo Java, but really 
should be expanded as a general rule, requirement vs recommendation.

https://wiki.gentoo.org/wiki/Java_Developer_Guide#Versions

This does come with additional overhead, as you cannot just bump a piece of a 
package without doing all. It also makes the order of bumping and removal a 
bit more complex as well. There can also be some issues when it comes to doing 
system updates, if not doing world. May have blockers with different versions 
being pulled in vs installed on system.

Regardless of the negatives, I think the positives are justified.

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Gentoo-specific breakage when building dev-lisp/gcl

[grozin]

On Tue, 1 Nov 2016, Zac Medico wrote:

Does FEATURES="-sandbox -usersandox" help?

Yes.

I've filed the bug #598752 about this problem.

Thanks,
Andrey

Re: [gentoo-dev] newsitem: important fstab and localmount update, round 4

[Denis Lisov]

> The recommended solution is to convert fstab from using
> "/dev/disk/by-*" to the LABEL=, UUID=, or PARTUUID= syntax.

Is there any specific reason to mention these three but not PARTLABEL=
used for GPT (maybe not only GPT) partition labels?

On Wed, Nov 2, 2016 at 12:13 AM, William Hubbs  wrote:
>

Re: [gentoo-dev] [RFC] Problems and limitations of the current version dependency specs

[Sergei Trofimovich]

On Wed, 2 Nov 2016 07:43:04 +0100
Michał Górny  wrote:

> On Tue, 1 Nov 2016 23:09:25 +
> Sergei Trofimovich  wrote:
> 
> > On Tue, 1 Nov 2016 14:16:18 +0100
> > Michał Górny  wrote:
> >   
> > > However, while at it I should
> > > point out that the spec doesn't really cover pure-DEPEND :=, so there
> > > is no guarantee that Haskell := operators will work at all.
> > 
> > Yeah. It settled mostly because DEPEND="$RDEPEND + foo" is idiomatic
> > at least in non ':=' world and no tools complained about ':=' in DEPEND.  
> 
> No, it's allowed because of DEPEND=$RDEPEND.

I'm guessing (again) I should read it as "syntax-wise they are defined by the
same grammar".

> However, DEPEND without RDEPEND is not guaranteed to do anything useful.

I'm not aware of any haskell ebuilds that set ':=' only in DEPEND but not
propagate it to RDEPEND.

Crude hack
gentoo/metadata/md5-cache $ for f in */*; do if egrep -q '^DEPEND=.*:=' $f; 
then if ! egrep -q '^RDEPEND=.*:=' $f; then echo $f; fi; fi; done
reports a few unrelated packages.

-- 

  Sergei


pgphFCQ8W7m9L.pgp
Description: Цифровая подпись OpenPGP

Re: [gentoo-dev] [RFC] Problems and limitations of the current version dependency specs

[Daniel Campbell]

On 10/31/2016 05:31 PM, Michał Górny wrote:
> Hello, everyone.

Answering inline to help context.

> 
> I would like to work on a major version depedencny specification
> improvements as part of the next EAPI. For this reason, I'd like to
> first gather some research on how developers are using the current
> system, what they find efficient and what they find cumbersome.
> 
> Therefore, I would like to ask the following questions:
> 
> 1. How often do you find '~' useful? Do you think there should be
> additional operators that ignore revision part?

I've never really used it. After reading the devmanual on it, it seems
like it's redundant compared to *.

> 
> 2. How often do you find '=...*' wildcard syntax useful? To what
> purpose do you use it? Do you find its behavior confusing [1]?

It was confusing until I read your footnote. Obviously, I had to know it
back when I was applying, but it seems counter intuitive. Could we
instead make ~ take on the _pre _r behavior and let * be a more
intuitive option to match ranged deps without slotting?

> 
> 3. Do you sometimes find yourself using '<'/'<=' specs that
> accidentally match _pre/_rc/... versions?

Nope.

> 
> 4. What are the common tasks that you find unnecessarily complex /
> lengthy with the current version specifications?

Maybe I'm not writing enough ebuilds, but slot dependencies are a bit
complex for me. I have a hard time deciding whether to use := or :*, or
even if a slotted dependency is necessary. Every ebuild I end up having
peer-reviewed has a slot dep mistake that I end up fixing, and it's one
of the things that makes me ask for review before committing something.

> 
> 5. Do you find any other parts of the current version dependency
> specifications confusing?
> 
> Please just list the problems and your feeling about the current system
> now, not solutions. We will focus on the solutions in a next thread
> once we determine what the problems are.
> 
> Thanks in advance for your input.
> 
> 
> [1]. Few less-known facts about =...*:
> 
> a. it does NOT do string pattern matching but allows any version
> components following (i.e. 1.1* does not match 1.11),
> 
> b. it matches any version components, including _pre/_p/_rc/...
> suffixes (i.e. 1.1* matches 1.1_rc1).
> 

Maybe it could be covered in the devmanual (or elsewhere?) on
discovering "real" dependencies. Some projects just tell you what they
use without specifying version numbers or ranges. ldd may be useful
there, but that will only show you what it linked to when you built it.
If it's a "smart" build system it detects dependencies anyway. We don't
want that behavior, though.

I think, personally, if I knew more about nailing down dep versions and
handling slot dependencies, I'd feel a bit more confident writing new
ebuilds or taking on maintenance of others. Most of the syntax is
legible and understandable. Superficially, I understand slot
dependencies, but manipulating them in an older ebuild is different than
a fresh ebuild you're looking to bring to the main tree.

Thanks for bringing up the discussion.

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



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Problems and limitations of the current version dependency specs

[Michał Górny]

On Tue, 1 Nov 2016 23:09:25 +
Sergei Trofimovich  wrote:

> On Tue, 1 Nov 2016 14:16:18 +0100
> Michał Górny  wrote:
> 
> > However, while at it I should
> > point out that the spec doesn't really cover pure-DEPEND :=, so there
> > is no guarantee that Haskell := operators will work at all.  
> 
> Yeah. It settled mostly because DEPEND="$RDEPEND + foo" is idiomatic
> at least in non ':=' world and no tools complained about ':=' in DEPEND.

No, it's allowed because of DEPEND=$RDEPEND. However, DEPEND without
RDEPEND is not guaranteed to do anything useful.

-- 
Best regards,
Michał Górny



pgpMTNBN34ush.pgp
Description: OpenPGP digital signature