Re: [gentoo-portage-dev] Re: [gentoo-dev] [PATCH] pym/portage/news.py: let slackers copy+paste the news read command

2015-01-30 Thread Brian Dolbec
On Fri, 30 Jan 2015 00:37:30 -0800
Zac Medico zmed...@gentoo.org wrote:

 On 01/30/2015 12:14 AM, Jason Zaman wrote:
  On Thu, Jan 29, 2015 at 11:00:21PM -0800, Zac Medico wrote:
  Also, when the work read appears twice on a short line like
  that, it gives a wordy/redundant feeling.
  
  Perhaps better would be 'eselect news read' to view new items? ie.
  view instead of the second read.
 
 Yeah, that's much better.


Committed and pushed this last version.

Thank you Toralf
-- 
Brian Dolbec dolsen




Re: [gentoo-portage-dev] [PATCH] Generate soname dependency metadata (282639)

2015-01-30 Thread Anthony G. Basile

On 01/29/15 21:02, Zac Medico wrote:

+#hppa_{32,64}
+#ia_{32,64}
+#m68k_{32,64}
+#mips_{eabi32,eabi64,n32,n64,o32,o64}
+#ppc_{32,64}
+#s390_{32,64}
+#sh_{32,64}
+#sparc_{32,64}
+#x86_{32,64,x32}
+#
+# NOTES:
+#
+# * The ABIs referenced by some of the above *_32 and *_64 categories
+#   may be imaginary, but they are listed anyway, since the goal is to
+#   establish a naming convention that is as consistent and uniform as
+#   possible.
+#
+# * The Elf header's e_ident[EI_OSABI] byte is completely ignored,
+#   since OS-independence is one of the goals. The assumption is that,
+#   for given installation, we are only interested in tracking multilib
+#   ABIs for a single OS.


If you run readelf -h on (say) bash in any of our stage3's tarballs you
always get OS/ABI: UNIX - System V irrespective of arch and abi.  I
don't know what you would get on BSD, but the field is totally
irrelevant for our purposes despite the name.  As far as I can tell, it
is totally invariant across arches and abis.

You can even unpack the the stage3's on an amd64 host and run readelf
form the host on the chroot target and you'll get the elf header, so you
don't need access to native hardware.

The comment suggests that there might be some interesting information
there, but there isn't.  Maybe I'm just reading too much into it.


Well, a quick google search seems to indicate that FreeBSD uses
EI_OSABI. I was specifically thinking about FreeBSD when I wrote that
comment, because I was aware that Gentoo/FBSD was using ELF, and I just
assumed that they would have a different EI_OSABI than Linux.


Even there you'll get UNIX - System V.  I don't have a freebsd system 
ready to go, but here's what i get from my openbsd system:


# uname -a
OpenBSD obi.dis 5.6 GENERIC.MP#333 amd64
# readelf -h /bin/sh
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class: ELF64
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  EXEC (Executable file)
  Machine:   Advanced Micro Devices X86-64
  Version:   0x1
  Entry point address:   0x400260
  Start of program headers:  64 (bytes into file)
  Start of section headers:  442512 (bytes into file)
  Flags: 0x0
  Size of this header:   64 (bytes)
  Size of program headers:   56 (bytes)
  Number of program headers: 7
  Size of section headers:   64 (bytes)
  Number of section headers: 17
  Section header string table index: 16


I have *never* seen the OS/ABI be anything different.  That's what 
struck me about your comment.  Anyhow, we're far afield.


I might install freebsd later in a vm just to have one handy and check.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197



Re: [gentoo-portage-dev] [PATCH] Generate soname dependency metadata (282639)

2015-01-30 Thread Brian Dolbec
On Thu, 29 Jan 2015 22:01:51 -0800
Zac Medico zmed...@gentoo.org wrote:

 On 01/29/2015 09:00 PM, Michał Górny wrote:
  Dnia 2015-01-26, o godz. 19:16:28
  Zac Medico zmed...@gentoo.org napisał(a):
  +from ...util.elf.constants import (
  
  Please do not use relative imports. Almost all code is using
  absolute imports so if we're going to change that, we should get a
  proper discussion first.
 
 Well, is anyone else here opposed to using relative imports? They are
 supported since python 2.5, and I don't see anything wrong with them.
 


I'm not a fan of relative imports myself.  I've had trouble with them
when I did try using them. Plus I've found it harder to make changes to
code and search for the imports which may need changing.




 
  +def decode_uint32_le(data):
  +  
  +  Decode an unsigned 32-bit integer with little-endian
  encoding. +
  +  @param data: string of bytes of length 4
  +  @type data: bytes
  +  @rtype: int
  +  @return: unsigned integer value of the decoded data
  +  
  +  return (
  +  ord(data[0:1]) +
  +  (ord(data[1:2])  8) +
  +  (ord(data[2:3])  16) +
  +  (ord(data[3:4])  24)
  +  )
  
  How about using the struct module instead of reinventing the wheel?
 
 Well the versions that I wrote seem a lot more readable to me than
 they would be if written using things like struct.unpack_from(L,
 data)[0]. Either way is fine with me, though. Google seems to show
 some issues with struct import failing for broken python
 installations, but that should not be an issue in practice.

broken python is not reliable then anyway...

I think I like the struct idea better.

-- 
Brian Dolbec dolsen




Re: [gentoo-portage-dev] portage sync changes, fixes

2015-01-30 Thread Brian Dolbec
On Thu, 29 Jan 2015 11:45:18 -0800
Brian Dolbec dol...@gentoo.org wrote:

 
 From mgorny's recent suggestions and bug report...
 Plus  a final pyflakes cleanup.
 
 

pushed with suggested change for has_bin

-- 
Brian Dolbec dolsen




[gentoo-portage-dev] [PATCH v2] Generate soname dependency metadata (282639)

2015-01-30 Thread Zac Medico
Generate soname dependency metadata for binary and installed packages,
in the form of PROVIDES and REQUIRES metadata. It is useful to generate
PROVIDES and REQUIRES metadata now, so that it will be available
when dependency resolver support is added in the future. Note that
slot-operator dependencies will not be able to serve as a substitute
for soname dependencies for the forseeable future, because system
dependencies are frequently unspecified (according to Gentoo policy).

The PROVIDES/REQUIRES system is very similar to the automatic Requires
and Provides system which is supported by RPM. The PROVIDES/REQUIRES
metadata is generated automatically from the ELF files that are
installed by a package. The PROVIDES/REQUIRES syntax is described in
the /var/db/pkg section of the portage(5) man page. REQUIRES_EXCLUDE
and PROVIDES_EXCLUDE ebuild variables allow for filtering of the
sonames that are saved in REQUIRES and PROVIDES (see the ebuild(5) man
page for details).

The /var/db/pkg NEEDED.ELF.2 format now includes an additional field
which indicates the multilib category, as discussed in bug #534206. The
multilib category is used to categorize the sonames that are listed in
PROVIDES/REQUIRES metadata, since sonames need to be resolved
separately for each multilib category. The complete list of supported
multilib categories is documented in the comments of the
portage.dep.soname.multilib_category module.

X-Gentoo-Bug: 282639
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=282639
---
PATCH v2 includes the following changes:
* no relative imports
* NeededEntry.__str__ now uses ;.join
* portage.util.elf.constants refers to elf.h from elfutils
* EM_ALPHA uses correct 0x9026 value (tested with gentoo stage3)
* portage.util.endian.decode uses struct.unpack_from

 bin/ebuild.sh   |   2 +-
 bin/phase-functions.sh  |   2 +-
 man/ebuild.5|  12 +++
 man/portage.5   |  25 +
 pym/_emerge/Package.py  |   3 +-
 pym/portage/dbapi/bintree.py|   5 +-
 pym/portage/dbapi/vartree.py|   1 +
 pym/portage/dep/soname/__init__.py  |   2 +
 pym/portage/dep/soname/multilib_category.py | 112 +++
 pym/portage/package/ebuild/doebuild.py  |  86 --
 pym/portage/util/_dyn_libs/LinkageMapELF.py |  61 ++---
 pym/portage/util/_dyn_libs/NeededEntry.py   |  82 +
 pym/portage/util/_dyn_libs/soname_deps.py   | 136 
 pym/portage/util/elf/__init__.py|   2 +
 pym/portage/util/elf/constants.py   |  39 
 pym/portage/util/elf/header.py  |  62 +
 pym/portage/util/endian/__init__.py |   2 +
 pym/portage/util/endian/decode.py   |  48 ++
 18 files changed, 655 insertions(+), 27 deletions(-)
 create mode 100644 pym/portage/dep/soname/__init__.py
 create mode 100644 pym/portage/dep/soname/multilib_category.py
 create mode 100644 pym/portage/util/_dyn_libs/NeededEntry.py
 create mode 100644 pym/portage/util/_dyn_libs/soname_deps.py
 create mode 100644 pym/portage/util/elf/__init__.py
 create mode 100644 pym/portage/util/elf/constants.py
 create mode 100644 pym/portage/util/elf/header.py
 create mode 100644 pym/portage/util/endian/__init__.py
 create mode 100644 pym/portage/util/endian/decode.py

diff --git a/bin/ebuild.sh b/bin/ebuild.sh
index e6f9cb9..b6b3723 100755
--- a/bin/ebuild.sh
+++ b/bin/ebuild.sh
@@ -578,7 +578,7 @@ if ! has $EBUILD_PHASE clean cleanrm ; then
# interaction begins.
unset EAPI DEPEND RDEPEND PDEPEND HDEPEND INHERITED IUSE 
REQUIRED_USE \
ECLASS E_IUSE E_REQUIRED_USE E_DEPEND E_RDEPEND 
E_PDEPEND \
-   E_HDEPEND
+   E_HDEPEND PROVIDES_EXCLUDE REQUIRES_EXCLUDE
 
if [[ $PORTAGE_DEBUG != 1 || ${-/x/} != $- ]] ; then
source $EBUILD || die error sourcing ebuild
diff --git a/bin/phase-functions.sh b/bin/phase-functions.sh
index aec86fd..def2080 100644
--- a/bin/phase-functions.sh
+++ b/bin/phase-functions.sh
@@ -580,7 +580,7 @@ __dyn_install() {
for f in ASFLAGS CBUILD CC CFLAGS CHOST CTARGET CXX \
CXXFLAGS EXTRA_ECONF EXTRA_EINSTALL EXTRA_MAKE \
LDFLAGS LIBCFLAGS LIBCXXFLAGS QA_CONFIGURE_OPTIONS \
-   QA_DESKTOP_FILE ; do
+   QA_DESKTOP_FILE PROVIDES_EXCLUDE REQUIRES_EXCLUDE ; do
x=$(echo -n ${!f})
[[ -n $x ]]  echo $x  $f
done
diff --git a/man/ebuild.5 b/man/ebuild.5
index b587264..c2cbe4b 100644
--- a/man/ebuild.5
+++ b/man/ebuild.5
@@ -480,6 +480,12 @@ source source\-build which is scheduled for merge
 .TE
 .RE
 .TP
+.B PROVIDES_EXCLUDE\fR = \fI[space delimited list of fnmatch patterns]\fR

[gentoo-portage-dev] Re: [gentoo-dev] [PATCH] pym/portage/news.py: let slackers copy+paste the news read command

2015-01-30 Thread Zac Medico
On 01/30/2015 12:14 AM, Jason Zaman wrote:
 On Thu, Jan 29, 2015 at 11:00:21PM -0800, Zac Medico wrote:
 Also, when the work read appears twice on a short line like that, it
 gives a wordy/redundant feeling.
 
 Perhaps better would be 'eselect news read' to view new items? ie.
 view instead of the second read.

Yeah, that's much better.
-- 
Thanks,
Zac



[gentoo-portage-dev] Re: [gentoo-dev] [PATCH] pym/portage/news.py: let slackers copy+paste the news read command

2015-01-30 Thread Duncan
Zac Medico posted on Fri, 30 Jan 2015 00:37:30 -0800 as excerpted:

 On 01/30/2015 12:14 AM, Jason Zaman wrote:
 On Thu, Jan 29, 2015 at 11:00:21PM -0800, Zac Medico wrote:
 Also, when the work read appears twice on a short line like that, it
 gives a wordy/redundant feeling.
 
 Perhaps better would be 'eselect news read' to view new items? ie.
 view instead of the second read.
 
 Yeah, that's much better.

View works, or I was going to suggest see, which I'm still partial to 
over view:

'eselect news read' to see news items.

(And FWIW, select/paste vs. type, depends on my mood and the pointing 
device I'm using.  I used to select/paste quite a bit with a trackball, 
depending on mood, but I'm using a touchpad without physical buttons as 
my primary pointing device now, and it's more trouble there, so I'd type 
it as long as the command is short or can be tab-completed, and only 
select/paste for long ones or those with arbitrary and hard to remember 
options, possibly even switching pointing devices to do it if I'm not 
running X and thus don't have the 20-gesture-button programmed 
flexibility of a well configured xf86-input-mtrack.  An text-console 
evdev-based mtrack driver to parallel the X driver would sure be nice!)

-- 
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