Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]
By the way, any help for maintaining the libc++ stack is very welcome; as you can see from the age of the current snapshots, it's been some time I've not been playing with it. Some notes: - why not adding a clang subprofile ? there's one for amd64-fbsd; I had been able to build a complete stage 3 without too much trouble. There's probably nothing bsd specific there, so moving generic code from there to profiles/features should work. - it'd be worth fixing/improving libunwind support, esp. as you write here on the clang 'spec' parts; I don't remember if there were other issues, but it was a bit pointless if we can't get rid of libgcc_s because of clang (maybe there were even symbol collisions?) - libcxxabi is probably the new way to go instead of libcxxrt; last time I checked there was a chicken and egg problem: libcxxabi needed clang + libc++ to build, so bootstrapping the stack was a bit painful. - there are a few todos in libcxx ebuild (mainly libsupc++ support, but the same could apply to libcxxabi) - it'd be interesting to have stand-alone ebuilds for gcc's crt files; or better, find BSD-like alternatives Alexis.
Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]
Alexis Ballier wrote: - why not adding a clang subprofile ? there's one for amd64-fbsd; I had been able to build a complete stage 3 without too much trouble. There's probably nothing bsd specific there, so moving generic code from there to profiles/features should work. I'd try to test that at some point. //Peter
Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]
Does clang compile glibc already? At the last GNU Cauldron the speaker said that clang fails because of:[1] - nested functions - VLAIS How did you avoid that problem? Marco [1] http://www.youtube.ca/watch?v=mmiDwKgn6Holist=PLOGTP9W1DX5U53pPxtWdKkyiqe3GAn6Nd Am Mon, 27 Oct 2014 11:20:00 +0100 schrieb Peter Stuge pe...@stuge.se: Alexis Ballier wrote: - why not adding a clang subprofile ? there's one for amd64-fbsd; I had been able to build a complete stage 3 without too much trouble. There's probably nothing bsd specific there, so moving generic code from there to profiles/features should work. I'd try to test that at some point. //Peter signature.asc Description: PGP signature
Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]
On Mon, 27 Oct 2014 12:07:25 +0100 M. Ziebell ziebell_ma...@posteo.de wrote: Does clang compile glibc already? At the last GNU Cauldron the speaker said that clang fails because of:[1] - nested functions - VLAIS How did you avoid that problem? by using freebsd's libc :) only problem I can recall is openssl which has been fixed recently afaik
Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]
Am Mon, 27 Oct 2014 12:10:51 +0100 schrieb Alexis Ballier aball...@gentoo.org: On Mon, 27 Oct 2014 12:07:25 +0100 M. Ziebell ziebell_ma...@posteo.de wrote: Does clang compile glibc already? At the last GNU Cauldron the speaker said that clang fails because of:[1] - nested functions - VLAIS How did you avoid that problem? by using freebsd's libc :) only problem I can recall is openssl which has been fixed recently afaik So glibic is a show stopper or we talk about switching the libc too? signature.asc Description: PGP signature
Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]
On Mon, 27 Oct 2014 12:29:40 +0100 M. Ziebell ziebell_ma...@posteo.de wrote: Am Mon, 27 Oct 2014 12:10:51 +0100 schrieb Alexis Ballier aball...@gentoo.org: On Mon, 27 Oct 2014 12:07:25 +0100 M. Ziebell ziebell_ma...@posteo.de wrote: Does clang compile glibc already? At the last GNU Cauldron the speaker said that clang fails because of:[1] - nested functions - VLAIS How did you avoid that problem? by using freebsd's libc :) only problem I can recall is openssl which has been fixed recently afaik So glibic is a show stopper or we talk about switching the libc too? it is, but you are the one talking about glibc, I was talking about gentoo/freebsd :)
Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]
Am 27. Oct 2014, 11:14 schrieb Alexis Ballier aball...@gentoo.org:
By the way, any help for maintaining the libc++ stack is very welcome;
as you can see from the age of the current snapshots, it's been some
time I've not been playing with it.
Some notes:
- why not adding a clang subprofile ? there's one for amd64-fbsd; I had
been able to build a complete stage 3 without too much trouble.
There's probably nothing bsd specific there, so moving
generic code from there to profiles/features should work.
Yes, it looks fairly generic. This is definitely worth a try.
- it'd be worth fixing/improving libunwind support, esp. as you write
here on the clang 'spec' parts; I don't remember if there were other
issues, but it was a bit pointless if we can't get rid of libgcc_s
because of clang (maybe there were even symbol collisions?)
- libcxxabi is probably the new way to go instead of libcxxrt; last
time I checked there was a chicken and egg problem: libcxxabi needed
clang + libc++ to build, so bootstrapping the stack was a bit
painful.
The Toolchain behavior on GNU/Linux is fairly tailored to using gcc at
the moment (just grep for gcc_ on
tools/clang/lib/Driver/{Tools|Toolchain}.cpp).
In order to really pull off a clang/libc++ toolchain independent of gcc
assistance would involve quite a bunch of (preferably upstream) work...
- there are a few todos in libcxx ebuild (mainly libsupc++ support, but
the same could apply to libcxxabi)
- it'd be interesting to have stand-alone ebuilds for gcc's crt files;
or better, find BSD-like alternatives
Alexis.
Best,
Matthias
Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]
Am 27. Oct 2014, 12:07 schrieb M. Ziebell ziebell_ma...@posteo.de: Does clang compile glibc already? At the last GNU Cauldron the speaker said that clang fails because of:[1] - nested functions - VLAIS How did you avoid that problem? Even without this issues there remains the fact that glibc is quite closely coupled to gcc's support libraries (e.g. $ grep dlopen.*gcc_ **/*.c, or pthread's usage of support libraries...). And this is something that won't change anytime soon. After all, glibc is part of the GNU eco system and as such it is perfectly valid to depend on respective compiler.
Re: [gentoo-dev] Clang toolchain
- libcxxabi is probably the new way to go instead of libcxxrt; last time I checked there was a chicken and egg problem: libcxxabi needed clang + libc++ to build, so bootstrapping the stack was a bit painful. I give libcxxabi a try. Does anybody has a bit insight in the current status of the llvm's bundled libunwind in libcxxabi, i.e. is it trivially portable? If yes, this might clean up the dependency chain quite a bit. Best, Matthias
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-roguelike/stone-soup: stone-soup-0.14.1.ebuild stone-soup-0.15.1-r1.ebuild stone-soup-0.15.1.ebuild stone-soup-0.13.2.ebuild stone-soup-0.1
Patrick Lauer (patrick): patrick 14/10/27 02:58:21 Modified: stone-soup-0.14.1.ebuild stone-soup-0.15.1-r1.ebuild stone-soup-0.15.1.ebuild stone-soup-0.13.2.ebuild stone-soup-0.14.2.ebuild ChangeLog Log: Shorten description for repoman happy Users have been complaining about not finding this game since it's upstream naming is somewhat divergent. It can be called crawl or stone-soup or so. In order to avoid confusion I have added the full name Dungeon Crawl Stone Soup in the description. Now people are able to still find it if they do something like: eix -S crawl I want to keep the over-long description unless we have some sort of ebuild aliases.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-nds/openldap/files: openldap-2.4.40-db-6.patch
On Mon, Oct 27, 2014 at 09:04:19PM +, Howard Chu wrote: Robin H. Johnson (robbat2) wrote: robbat2 14/10/27 19:15:09 Removed: openldap-2.4.40-db-6.patch Log: Upstream OpenLDAP nixes bdb6 functionality. Not entirely accurate. We didn't nix all of BDB 6 - you can still use BDB 6.0.19, which was the last release before the license change. 6.0.19 isn't in our tree. It didn't pass it's own testsuite when I tried it, so I didn't ship it. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
[gentoo-dev] last rites: mail-filter/spamassassin-fuzzyocr
# Andreas K. Huettel dilfri...@gentoo.org (27 Oct 2014) # Multiple QA issues (#344187, #319433, #317575, #174466) # no upstream releases for a long time. # Masked for removal in 30 days mail-filter/spamassassin-fuzzyocr (ack'ed by chutzpah) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-roguelike/stone-soup: stone-soup-0.14.1.ebuild stone-soup-0.15.1-r1.ebuild stone-soup-0.15.1.ebuild stone-soup-0.13.2.ebuild stone-soup
On Mon, 27 Oct 2014 19:58:15 + hasufell hasuf...@gentoo.org wrote: I want to keep the over-long description unless we have some sort of ebuild aliases. longdescription / jer
[gentoo-portage-dev] [PATCH] depgraph: fix bug #526160
This fixes _dep_check_composite_db to mask packages that aren't the
highest visible match, but only if an update is desirable. This causes
desirable updates to get pulled in for cases like bug #526160. The
included unit test simulates the virtual/pypy update that triggered
the bug.
X-Gentoo-Bug: 526160
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=526160
---
This updated patch fixes the new logic so that it only applies to
virtual packages, since that's the only case where it is currently
needed.
pym/_emerge/depgraph.py | 24 +
pym/portage/tests/resolver/test_virtual_slot.py | 66 +
2 files changed, 90 insertions(+)
diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index 5180db5..78b9236 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -527,6 +527,8 @@ class depgraph(object):
self._event_loop = (portage._internal_caller and
global_event_loop() or EventLoop(main=False))
+ self._select_atoms_parent = None
+
self.query = UserQuery(myopts).query
def _load_vdb(self):
@@ -4062,11 +4064,13 @@ class depgraph(object):
self._dynamic_config._autounmask = False
# backup state for restoration, in case of recursive
# calls to this method
+ backup_parent = self._select_atoms_parent
backup_state = mytrees.copy()
try:
# clear state from previous call, in case this
# call is recursive (we have a backup, that we
# will use to restore it later)
+ self._select_atoms_parent = None
mytrees.pop(pkg_use_enabled, None)
mytrees.pop(parent, None)
mytrees.pop(atom_graph, None)
@@ -4074,6 +4078,7 @@ class depgraph(object):
mytrees[pkg_use_enabled] =
self._pkg_use_enabled
if parent is not None:
+ self._select_atoms_parent = parent
mytrees[parent] = parent
mytrees[atom_graph] = atom_graph
if priority is not None:
@@ -4085,6 +4090,7 @@ class depgraph(object):
finally:
# restore state
self._dynamic_config._autounmask =
_autounmask_backup
+ self._select_atoms_parent = backup_parent
mytrees.pop(pkg_use_enabled, None)
mytrees.pop(parent, None)
mytrees.pop(atom_graph, None)
@@ -8529,6 +8535,24 @@ class _dep_check_composite_db(dbapi):
elif not
self._depgraph._equiv_ebuild_visible(pkg):
return False
+ if pkg.cp.startswith(virtual/):
+ # Force virtual updates to be pulled in when appropriate
+ # for bug #526160.
+ want_update = False
+ if self._depgraph._select_atoms_parent is not None:
+ want_update = \
+ self._depgraph._want_update_pkg(
+ self._depgraph._select_atoms_parent,
pkg)
+
+ if want_update:
+ for new_child in
self._depgraph._iter_similar_available(
+ pkg, next(iter(atom_set))):
+ if not
self._depgraph._virt_deps_visible(
+ new_child, ignore_use=True):
+ continue
+ if pkg new_child:
+ return False
+
in_graph =
next(self._depgraph._dynamic_config._package_tracker.match(
self._root, pkg.slot_atom, installed=False), None)
diff --git a/pym/portage/tests/resolver/test_virtual_slot.py
b/pym/portage/tests/resolver/test_virtual_slot.py
index 1b19d77..2e5ca7f 100644
--- a/pym/portage/tests/resolver/test_virtual_slot.py
+++ b/pym/portage/tests/resolver/test_virtual_slot.py
@@ -92,6 +92,72 @@ class VirtualSlotResolverTestCase(TestCase):
finally:
playground.cleanup()
+ def testVirtualSubslotUpdate(self):
+
+ ebuilds = {
+ virtual/pypy-2.3.1 : {
+ EAPI: 5,
+ SLOT: 0/2.3,
+ RDEPEND: || (
Re: [gentoo-portage-dev] [PATCH] CONFIG_PROTECT: handle non-existent files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 LGTM, Zac. Go ahead and push. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlRN+lcACgkQRtClrXBQc7X2JgD/TW1qvYbXw3Rv+2wqloFiyQ/B oezRTpqmwNHBcTqhUDsA/0JxZlhZTWlqPiB8ezR1mTbB0ciX2DZBMFgY3R09nhRE =8wlT -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH] bin/bashrc-functions.sh: remove portageq function
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sure. Go ahead and push, Zac. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlRN+04ACgkQRtClrXBQc7Ud1AEAk3axfG6tjx6KW8BtmaAa9MNX VH/nYUSYe1wbjo4PtqMBAIvfuQoPnwLvUqx5ScLchbaaB/CGTnC0+m6oaMhwjgef =92kQ -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH] depgraph: fix bug #526160
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27/10/14 08:33, Zac Medico wrote: + if not self._depgraph._virt_deps_visible( + new_child, ignore_use=True): + continue + if pkg new_child: + return False Seems needlessly bit obscure when you could just if self.depgraph._virt_deps_visible(new_child, ignore_use=True) and pkg new_child or some variant thereof. But it's a minor qualm. Otherwise LGTM, go ahead push. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlROALYACgkQRtClrXBQc7WY4QEAgp2lH+WOHmAcGBoxVIfr0cGc mYc5xIpc17eu4OxvPUIBAIaMsRyieA9OZSq7mUQL27of9zrirjH0PGPMjSuxZQxB =1fXi -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH] depgraph: fix bug #526160
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27/10/14 09:22, Alexander Berntsen wrote: On 27/10/14 08:33, Zac Medico wrote: +if not self._depgraph._virt_deps_visible( + new_child, ignore_use=True): + continue + if pkg new_child: + return False Seems needlessly bit obscure when you could just if self.depgraph._virt_deps_visible(new_child, ignore_use=True) and pkg new_child or some variant thereof. But it's a minor qualm. Otherwise LGTM, go ahead push. Thunderbird fucked up wrapping. I am referring to this part: On 27/10/14 08:33, Zac Medico wrote: + for new_child in self._depgraph._iter_similar_available( + pkg, next(iter(atom_set))): + if not self._depgraph._virt_deps_visible( + new_child, ignore_use=True): + continue + if pkg new_child: + return False - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlROAP4ACgkQRtClrXBQc7XIhAD8CStcQaeCbFzibcHf0CAHN/71 xyUKhSWcoky/LUt0gB8A/2WC8wwngghQjbhwEJ0WFryygLmvvTdhGBl2K7/9Xq7Q =Diyd -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH] depgraph: fix bug #526160
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I give up. You'll figure it out. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlROARcACgkQRtClrXBQc7X90AD/XqL9YziqEAQEILESp48jD+HJ Px+/5flPE74lV/oZ25wA/08ZujUDso/kNB3Q8ApydhX8hoOIr0uL9G+VFZ0MVQdq =rlDo -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH] depgraph: fix bug #526160
On 10/27/2014 01:22 AM, Alexander Berntsen wrote: On 27/10/14 08:33, Zac Medico wrote: +if not self._depgraph._virt_deps_visible( + new_child, ignore_use=True): + continue + if pkg new_child: + return False Seems needlessly bit obscure when you could just if self.depgraph._virt_deps_visible(new_child, ignore_use=True) and pkg new_child or some variant thereof. But it's a minor qualm. I prefer not to group them into a single expression because they are separate heuristics. At some point in the future, we may find that we need to adjust one or both heuristics, add more heuristics, or remove some heuristics. Keeping the heuristics as separate expressions makes it easier to do such modifications. It also provides emphasis to the reader that these are separate heuristics. Otherwise LGTM, go ahead push. Thanks, it's pushed: https://github.com/gentoo/portage/commit/d3be49fe6827aa1974856dffe6d5a1aca80a7bed -- Thanks, Zac
[gentoo-portage-dev] Re: [PATCH 1/3] bin/misc-functions.sh: Introduce eqalog and eqawarnlog functions.
On 27/10/14 07:05, Zac Medico wrote: On 10/26/2014 12:31 PM, Michael Palimaka wrote: On 26/10/14 07:57, Zac Medico wrote: On 10/25/2014 01:32 PM, Zac Medico wrote: On 10/25/2014 01:26 PM, Michał Górny wrote: Dnia 2014-10-25, o godz. 12:53:15 Zac Medico zmed...@gentoo.org napisał(a): These functions are internals, so they need to be prefixed with __ like __eqalog and __eqawarnlog. eqawarnlog shouldn't be internal since we support adding QA checks in repositories. In fact, I am planning to move some Gentoo-specific QA checks out of portage code. It's a PMS thing. If it's not in PMS and the package manager provides it, it's supposed to be prefixed. Note that we could have unprefixed aliases inside misc-functions.sh, since misc-functions.sh env is never saved. I've sent updated patches based on the last feedback. Should I send a new one with the aliases, and if so, should the portage checks use the alias or real function? Considering Michał's plan to expose these functions to QA checks in repositories, it would make sense to go ahead and add expose the aliases in misc-functions.sh now. On the other hand, it makes sense to use the prefixed versions in all internal portage code, for consistency. So, I'd probably just wait until later to add the unprefixed versions. I don't have a strong opinion though. The new patch set that you posted looks good to me. That's fine, we can just add the alias when Michał's GLEP is finalised then.
Re: [gentoo-portage-dev] Re: [PATCH 1/3] bin/misc-functions.sh: Introduce eqalog and eqawarnlog functions.
On 10/27/2014 06:15 AM, Michael Palimaka wrote:
On 27/10/14 07:05, Zac Medico wrote:
On 10/26/2014 12:31 PM, Michael Palimaka wrote:
I've sent updated patches based on the last feedback. Should I send a
new one with the aliases, and if so, should the portage checks use the
alias or real function?
Considering Michał's plan to expose these functions to QA checks in
repositories, it would make sense to go ahead and add expose the aliases
in misc-functions.sh now. On the other hand, it makes sense to use the
prefixed versions in all internal portage code, for consistency. So, I'd
probably just wait until later to add the unprefixed versions. I don't
have a strong opinion though. The new patch set that you posted looks
good to me.
That's fine, we can just add the alias when Michał's GLEP is finalised then.
I've pushed your patches:
https://github.com/gentoo/portage/commit/ab43c1944f0cb6bf43d5b40cceb2e8186645d347
https://github.com/gentoo/portage/commit/5c54f2b18112b779d5dcba30837b34aac74739e9
https://github.com/gentoo/portage/commit/01e148aac631a0d1c78968dea96ebd9ed94e5918
In the first patch, I wrapped lines inside __eqalog.
In the last patch, I did some trivial fixups for quoting and globbing:
diff --git a/bin/install-qa-check.d/90world-writable
b/bin/install-qa-check.d/90world-writable
index 4d5f4ab..490aaee 100644
--- a/bin/install-qa-check.d/90world-writable
+++ b/bin/install-qa-check.d/90world-writable
@@ -3,16 +3,17 @@
world_writable_check() {
# Now we look for all world writable files.
local unsafe_files=$(find ${ED} -type f -perm -2 | sed -e
s:^${ED}:/:)
- local OLDIFS x
+ local OLDIFS x prev_shopts=$-
OLDIFS=$IFS
IFS=$'\n'
+ set -f
if [[ -n ${unsafe_files} ]] ; then
eqawarn QA Security Notice: world writable file(s):
for x in $unsafe_files ; do
- __eqawarnlog world-writable $x
+ __eqawarnlog world-writable $x
done
eqawarn This may or may not be a security problem, most of the
time it is one.
@@ -25,12 +26,13 @@ world_writable_check() {
eqawarn QA Notice: Unsafe files detected (set*id and world
writable)
for x in $unsafe_files ; do
- __eqawarnlog world-writable-setid $x
+ __eqawarnlog world-writable-setid $x
done
die Unsafe files found in \${D}. Portage will not install
them.
fi
IFS=OLDIFS
+ [[ ${prev_shopts} == *f* ]] || set +f
}
world_writable_check
--
Thanks,
Zac
[gentoo-portage-dev] [PATCH 3/3] CONFIG_PROTECT: protect symlinks, bug #485598
Users may not want some symlinks to get clobbered, so protect them with CONFIG_PROTECT. Changes were required in the dblink.mergeme method and the new_protect_filename function. The changes to dblink.mergeme do 3 things: * Move the bulk of config protection logic from dblink.mergeme to a new dblink._protect method. The new method only returns 3 variables, which makes it easier to understand how config protection interacts with the dblink.mergeme code that uses those variables. This is important, since dblink.mergeme has so many variables. * Initialize more variables at the beginning of dblink.mergeme, since those variables are used by the dblink._protect method. * Use the variables returned from dblink._protect to trigger appropriate behavior later in dblink.mergeme. The new_protect_filename changes are required since this function compares the new file to old ._cfg* files that may already exist, in order to avoid creating duplicate ._cfg* files. In these comparisons, it needs to handle symlinks differently from regular files. The unit tests demonstrate operation in many different scenarios, including: * regular file replaces regular file * regular file replaces symlink * regular file replaces directory * symlink replaces symlink * symlink replaces regular file * symlink replaces directory * directory replaces regular file * directory replaces symlink X-Gentoo-Bug: 485598 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=485598 --- This updated patch only adds to the commit message in order to provide some information that may be helpful to reviewers of the patch. There are no changes to the code. pym/portage/dbapi/vartree.py| 255 - pym/portage/tests/emerge/test_config_protect.py | 292 pym/portage/util/__init__.py| 35 ++- 3 files changed, 463 insertions(+), 119 deletions(-) create mode 100644 pym/portage/tests/emerge/test_config_protect.py diff --git a/pym/portage/dbapi/vartree.py b/pym/portage/dbapi/vartree.py index e21135a..219ca16 100644 --- a/pym/portage/dbapi/vartree.py +++ b/pym/portage/dbapi/vartree.py @@ -4461,21 +4461,17 @@ class dblink(object): # stat file once, test using S_* macros many times (faster that way) mystat = os.lstat(mysrc) mymode = mystat[stat.ST_MODE] - # handy variables; mydest is the target object on the live filesystems; - # mysrc is the source object in the temporary install dir - try: - mydstat = os.lstat(mydest) - mydmode = mydstat.st_mode - except OSError as e: - if e.errno != errno.ENOENT: - raise - del e - #dest file doesn't exist - mydstat = None - mydmode = None + mymd5 = None + myto = None - if stat.S_ISLNK(mymode): - # we are merging a symbolic link + if sys.hexversion = 0x303: + mymtime = mystat.st_mtime_ns + else: + mymtime = mystat[stat.ST_MTIME] + + if stat.S_ISREG(mymode): + mymd5 = perform_md5(mysrc, calc_prelink=calc_prelink) + elif stat.S_ISLNK(mymode): # The file name of mysrc and the actual file that it points to # will have earlier been forcefully converted to the 'merge' # encoding if necessary, but the content of the symbolic link @@ -4495,6 +4491,69 @@ class dblink(object): os.unlink(mysrc) os.symlink(myto, mysrc) + mymd5 = portage.checksum._new_md5( + _unicode_encode(myto)).hexdigest() + + protected = False + if stat.S_ISLNK(mymode) or stat.S_ISREG(mymode): + protected = self.isprotected(mydest) + + if stat.S_ISREG(mymode) and \ + mystat.st_size == 0 and \ + os.path.basename(mydest).startswith(.keep): + protected = False + + destmd5 = None + mydest_link = None + # handy variables; mydest is the target object on the live filesystems; + # mysrc is the source object in the temporary install dir
[gentoo-portage-dev] [PATCH] dep_zapdeps: handle circular deps with --onlydeps
This fixes a case with --onlydeps were dep_zapdeps would pull in an
avoidable direct circular dependency on an onlydeps node. The logic
changes only apply to --onlydeps, so there's no chance of regressions
for cases when --onlydeps is not enabled.
X-Gentoo-Bug: 524916
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=524916
---
pym/portage/dep/dep_check.py | 9 ++--
.../tests/resolver/test_onlydeps_circular.py | 49 ++
2 files changed, 53 insertions(+), 5 deletions(-)
create mode 100644 pym/portage/tests/resolver/test_onlydeps_circular.py
diff --git a/pym/portage/dep/dep_check.py b/pym/portage/dep/dep_check.py
index 4386b5e..5dbe283 100644
--- a/pym/portage/dep/dep_check.py
+++ b/pym/portage/dep/dep_check.py
@@ -429,11 +429,10 @@ def dep_zapdeps(unreduced, reduced, myroot,
use_binaries=0, trees=None):
all_in_graph = False
break
circular_atom = None
- if all_in_graph:
- if parent is None or priority is None:
- pass
- elif priority.buildtime and \
- not (priority.satisfied or
priority.optional):
+ if not (parent is None or priority is None) and
\
+ (parent.onlydeps or
+ (all_in_graph and priority.buildtime
and \
+ not (priority.satisfied or
priority.optional))):
# Check if the atom would
result in a direct circular
# dependency and try to avoid
that if it seems likely
# to be unresolvable. This is
only relevant for
diff --git a/pym/portage/tests/resolver/test_onlydeps_circular.py
b/pym/portage/tests/resolver/test_onlydeps_circular.py
new file mode 100644
index 000..f7cd0a2
--- /dev/null
+++ b/pym/portage/tests/resolver/test_onlydeps_circular.py
@@ -0,0 +1,49 @@
+# Copyright 2014 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+from portage.tests import TestCase
+from portage.tests.resolver.ResolverPlayground import ResolverPlayground,
ResolverPlaygroundTestCase
+
+class OnlydepsTestCase(TestCase):
+
+ def testOnlydeps(self):
+ ebuilds = {
+ app-misc/A-1: {
+ EAPI: 5,
+ SLOT: 1,
+ DEPEND: || ( app-misc/B app-misc/A:1 )
+ },
+ app-misc/A-2: {
+ EAPI: 5,
+ SLOT: 2,
+ },
+ app-misc/B-0: {
+ EAPI: 5,
+ }
+ }
+
+ installed = {
+ app-misc/A-2: {
+ EAPI: 5,
+ SLOT: 2,
+ }
+ }
+
+ test_cases = (
+ # bug 524916 - direct circular dep should not pull
+ # in an onlydeps node when possible
+ ResolverPlaygroundTestCase(
+ [app-misc/A:1],
+ success = True,
+ options = { --onlydeps: True },
+ mergelist = [app-misc/B-0]),
+ )
+
+ playground = ResolverPlayground(ebuilds=ebuilds,
+ installed=installed, debug=False)
+ try:
+ for test_case in test_cases:
+ playground.run_TestCase(test_case)
+ self.assertEqual(test_case.test_success, True,
test_case.fail_msg)
+ finally:
+ playground.cleanup()
--
2.0.4
[gentoo-portage-dev] [PATCH 1/3] etc-update: symlink support for bug #485598
This includes numerous logic adjustments that are needed to support
protected symlinks. The show_diff function now supports arbitrary
file types. For example, a diff between two symlinks looks like this:
-SYM: /foo/bar - baz
+SYM: /foo/bar - blah
X-Gentoo-Bug: 485598
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=485598
---
This updated patch fixes show_diff to handle files that don't exist. These
are displayed as /dev/null.
bin/etc-update | 95 +-
1 file changed, 87 insertions(+), 8 deletions(-)
diff --git a/bin/etc-update b/bin/etc-update
index 7ac6f0b..1d78e96 100755
--- a/bin/etc-update
+++ b/bin/etc-update
@@ -51,11 +51,15 @@ do_mv_ln() {
local src=${@:$(( $# - 1 )):1}
local dst=${@:$(( $# - 0 )):1}
- if [[ -L ${dst} ]] ; then #330221
+ if [[ ! -L ${src} -L ${dst} ]] ; then #330221
local lfile=$(readlink ${dst})
[[ ${lfile} == /* ]] || lfile=${dst%/*}/${lfile}
echo Target is a symlink; replacing ${lfile}
dst=${lfile}
+ elif [[ -d ${dst} ! -L ${dst} ]] ; then
+ # If ${dst} is a directory, do not move the file
+ # inside of it if this fails.
+ rmdir ${dst} || return
fi
mv ${opts[@]} ${src} ${dst}
@@ -115,6 +119,24 @@ scan() {
continue 2
fi
done
+ if [[ -L ${file} ]] ; then
+ if [[ -L ${live_file} \
+ $(readlink ${live_file}) ==
$(readlink ${file}) ]]
+ then
+ rm -f ${file}
+ continue
+ fi
+ if [[ ${ofile:10} != ${rfile:10} ]] ||
+ [[ ${opath} != ${rpath} ]]
+ then
+ : $(( ++count ))
+ echo ${live_file}
${TMP}/files/${count}
+ fi
+ echo ${cfg_file} ${TMP}/files/${count}
+ ofile=${rfile}
+ opath=${rpath}
+ continue
+ fi
if [[ ! -f ${file} ]] ; then
${QUIET} || echo Skipping non-file ${file} ...
continue
@@ -124,7 +146,9 @@ scan() {
[[ ${opath} != ${rpath} ]]
then
MATCHES=0
- if [[ ${eu_automerge} == yes ]] ; then
+ if ! [[ -f ${cfg_file} -f ${live_file} ]] ;
then
+ MATCHES=0
+ elif [[ ${eu_automerge} == yes ]] ; then
if [[ ! -e ${cfg_file} || ! -e
${live_file} ]] ; then
MATCHES=0
else
@@ -377,17 +401,50 @@ do_file() {
show_diff() {
clear
- local file1=$1 file2=$2
+ local file1=$1 file2=$2 files=($1 $2) \
+ diff_files=() file i tmpdir
+
+ if [[ -L ${file1} ! -L ${file2}
+ -f ${file1} -f ${file2} ]] ; then
+ # If a regular file replaces a symlink to a regular file, then
+ # show the diff between the regular files (bug #330221).
+ diff_files=(${file1} ${file2})
+ else
+ for i in 0 1 ; do
+ if [[ ! -L ${files[$i]} -f ${files[$i]} ]] ; then
+ diff_files[$i]=${files[$i]}
+ continue
+ fi
+ [[ -n ${tmpdir} ]] || \
+ tmpdir=$(mktemp -d ${TMP}/symdiff-XXX)
+ diff_files[$i]=${tmpdir}/${i}
+ if [[ ! -L ${files[$i]} ! -e ${files[$i]} ]] ; then
+ echo /dev/null ${diff_files[$i]}
+ elif [[ -L ${files[$i]} ]] ; then
+ echo SYM: ${file1} - $(readlink
${files[$i]}) \
+ ${diff_files[$i]}
+ elif [[ -d ${files[$i]} ]] ; then
+ echo DIR: ${file1} ${diff_files[$i]}
+ elif [[ -p ${files[$i]} ]] ; then
+ echo FIF: ${file1} ${diff_files[$i]}
+ else
+ echo DEV: ${file1} ${diff_files[$i]}
+ fi
+ done
+ fi
+
if [[ ${using_editor} == 0 ]] ; then
(
[gentoo-portage-dev] [PATCH 2/3] dispatch-conf: symlink support for bug #485598
This includes numerous logic adjustments that are needed to support
protected symlinks. The new diff_mixed function is used for diffs
between arbitrary file types. For example, a diff between two symlinks
looks like this:
-SYM: /foo/bar - baz
+SYM: /foo/bar - blah
X-Gentoo-Bug: 485598
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=485598
---
This updated patch fixes diff_mixed to handle files that don't exist. These
are displayed as /dev/null. Also, I renamed diffstatusoutput_symlink to
diffstatusoutput_mixed, since it works with mixed file types. Thanks to
Mike Gilbert flop...@gentoo.org for reporting the issue with files that
don't exist.
bin/dispatch-conf| 40 ++--
pym/portage/dispatch_conf.py | 142 ---
2 files changed, 144 insertions(+), 38 deletions(-)
diff --git a/bin/dispatch-conf b/bin/dispatch-conf
index 6d2ae94..80dafd6 100755
--- a/bin/dispatch-conf
+++ b/bin/dispatch-conf
@@ -15,15 +15,15 @@ from __future__ import print_function
from stat import ST_GID, ST_MODE, ST_UID
from random import random
-import atexit, re, shutil, stat, sys
+import atexit, io, re, functools, shutil, sys
from os import path as osp
if osp.isfile(osp.join(osp.dirname(osp.dirname(osp.realpath(__file__))),
.portage_not_installed)):
sys.path.insert(0,
osp.join(osp.dirname(osp.dirname(osp.realpath(__file__))), pym))
import portage
portage._internal_caller = True
from portage import os
-from portage import _unicode_decode
-from portage.dispatch_conf import diffstatusoutput
+from portage import _encodings, _unicode_decode
+from portage.dispatch_conf import diffstatusoutput, diff_mixed
from portage.process import find_binary, spawn
FIND_EXTANT_CONFIGS = find '%s' %s -name '._cfg_%s' ! -name '.*~' !
-iname '.*.bak' -print
@@ -72,6 +72,11 @@ def cmd_var_is_valid(cmd):
return find_binary(cmd[0]) is not None
+def diff(file1, file2):
+return diff_mixed(
+functools.partial(diffstatusoutput, DIFF_CONTENTS),
+file1, file2)
+
class dispatch:
options = {}
@@ -89,8 +94,6 @@ class dispatch:
or not os.path.exists(self.options[log-file]):
open(self.options[log-file], 'w').close() # Truncate it
os.chmod(self.options[log-file], 0o600)
-else:
-self.options[log-file] = /dev/null
pager = self.options.get(pager)
if pager is None or not cmd_var_is_valid(pager):
@@ -148,9 +151,6 @@ class dispatch:
portage.util.shlex_split(
portage.settings.get('CONFIG_PROTECT_MASK', '')))
-def diff(file1, file2):
-return diffstatusoutput(DIFF_CONTENTS, file1, file2)
-
#
# Remove new configs identical to current
# and
@@ -166,7 +166,7 @@ class dispatch:
mrgfail = portage.dispatch_conf.rcs_archive(archive,
conf['current'], conf['new'], mrgconf)
else:
mrgfail = portage.dispatch_conf.file_archive(archive,
conf['current'], conf['new'], mrgconf)
-if os.path.exists(archive + '.dist'):
+if os.path.lexists(archive + '.dist'):
unmodified = len(diff(conf['current'], archive + '.dist')[1])
== 0
else:
unmodified = 0
@@ -181,7 +181,7 @@ class dispatch:
if newconf == mrgconf and \
self.options.get('ignore-previously-merged') != 'yes' and \
-os.path.exists(archive+'.dist') and \
+os.path.lexists(archive+'.dist') and \
len(diff(archive+'.dist', conf['new'])[1]) == 0:
# The current update is identical to the archived .dist
# version that has previously been merged.
@@ -254,6 +254,11 @@ class dispatch:
valid_input = qhtnmlezu
+def diff_pager(file1, file2):
+cmd = self.options['diff'] % (file1, file2)
+cmd += pager
+spawn_shell(cmd)
+
for conf in confs:
count = count + 1
@@ -266,14 +271,10 @@ class dispatch:
while 1:
clear_screen()
if show_new_diff:
-cmd = self.options['diff'] % (conf['new'], mrgconf)
-cmd += pager
-spawn_shell(cmd)
+diff_mixed(diff_pager, conf['new'], mrgconf)
show_new_diff = 0
else:
-cmd = self.options['diff'] % (conf['current'], newconf)
-cmd += pager
-spawn_shell(cmd)
+diff_mixed(diff_pager, conf['current'], newconf)
print()
print(' (%i of %i) -- %s' % (count, len(confs), conf
['current']))
@@ -357,7 +358,12 @@ class dispatch:
def replace (self, newconf, curconf):
Replace current config with the new/merged version. Also logs
the diff
