Re: [gentoo-dev] status of bugs blocking gcc-4.8.3
On 30/10/14 15:06, Jan Kundrát wrote: On Saturday, 25 October 2014 12:47:21 CEST, Luca Barbato wrote: The ABI mismatch is due the library not being versioned properly as usual? Please note that this would be a hard thing to do. This is not just a matter of calling an appropriate version of a given function; there are no guarantees about the internal layout of the data structures, etc. Furthermore, portions of C++ code might be inlined, so whenever you have a library compiled with different GCC versions, these cannot exchange any data which embed a C++11 data type inside. That's quite a bummer -- std::string and std::list have both changed in C++11 (forbidden ref-counting of std::string and O(1) size of std::list::size()). The upstream's promise is that the ABI will eventually ebcome stable when they remove the experimental label on their C++11 support. I suspect that the only solution would be a full ABI version number change at that time, though, and people want to avoid doing this because that will of course break all C++ programs out there. It would be terrific if the GCC guys provided a reasonable roadmap, because saying we support C++11 while also saying don't combine code built by 4.7 and 4.8, that's totally unsupported is a bit strange. Yes, limited time and limited manpower and what not, but it's still something which makes using all of the C++11 features a very risky business. And obviously providing libstdc++ and libstdc++11 (and matching headers) is not an option =\ _quite_ annoying indeed lu - hoping rust won't have such issues.
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On 19 October 2014 16:57, hasufell hasuf...@gentoo.org wrote: If maintainers want to NEEDINFO or WONTFIX a tinderbox bug, well, they'll be the ones picking up the pieces when the gcc upgrade moves ahead. We are all picking up the pieces. I don't get why anybody wouldn't like seeing them. I do, it's childish and uncollaborative behavior from that person closing the bugs (any1 still wondering who we are talking about?). And that behavior is tolerated. Are you saying you want to change something about it? So who wants to pick up the pieces now? Because I'm almost pissed off enough to turn down the tinderbox and give a big FU to Gentoo already. https://bugs.gentoo.org/show_bug.cgi?id=527608 Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On Fri, 31 Oct 2014 16:28:56 + Diego Elio Pettenò flamee...@flameeyes.eu wrote: So who wants to pick up the pieces now? Because I'm almost pissed off enough to turn down the tinderbox and give a big FU to Gentoo already. https://bugs.gentoo.org/show_bug.cgi?id=527608 Apparently Mr. Frysinger needs an education? jer
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On Fri, Oct 31, 2014 at 12:28 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 19 October 2014 16:57, hasufell hasuf...@gentoo.org wrote: If maintainers want to NEEDINFO or WONTFIX a tinderbox bug, well, they'll be the ones picking up the pieces when the gcc upgrade moves ahead. We are all picking up the pieces. I don't get why anybody wouldn't like seeing them. I do, it's childish and uncollaborative behavior from that person closing the bugs (any1 still wondering who we are talking about?). And that behavior is tolerated. Are you saying you want to change something about it? So who wants to pick up the pieces now? Because I'm almost pissed off enough to turn down the tinderbox and give a big FU to Gentoo already. https://bugs.gentoo.org/show_bug.cgi?id=527608 I'm not sure who owns policy around bugzilla. If nothing else I'm happy to put this on the next Council agenda. If QA or Comrel wants to step in sooner they're welcome to, but if they're looking for a policy to enforce the Council could probably provide one. Self-contained bugs in general make sense, and I'm all for finding a better solution than what the tinderbox currently supplies. However, until that solution comes along I think we're better off having tinderbox runs than not having them. If somebody took the time to systematically test my packages and the biggest issue was that I had to fetch a URL, then I'd do them the favor of fetching it and attaching the file myself, because I want to know when my stuff breaks. I can't always fix every bug as quickly as I'd like to, but I'm not going to just close them and stick my head in the sand. Why are we all here anyway? If we want to all play games I'm sure we can make life miserable for each other, but frankly I'd rather spend my time making my favorite distro better, and I can't imagine why else anybody would be wasting their time reading my emails... :) -- Rich
Re: [gentoo-dev] status of bugs blocking gcc-4.8.3
On Fri, Oct 31, 2014 at 12:25 PM, Luca Barbato lu_z...@gentoo.org wrote: lu - hoping rust won't have such issues. Funny - I first heard of this earlier this week. Biggest issue I see with rust is that it seems like it has joined the every-language-needs-its-own-package-manager club, and it seems to me that it really encourages static linking. The build system doesn't seem particularly distro-friendly, let alone source-based distro-friendly. However, I have only spent about an hour learning about rust, so I'm certainly interested if others know better. I really like the concept though. ADA has always been on my list of things I'd love to spend time on someday, and Rust seems to be a more modern take on the concept. -- Rich
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On 10/31/2014 05:58 PM, Jeroen Roovers wrote: On Fri, 31 Oct 2014 16:28:56 + Diego Elio Pettenò flamee...@flameeyes.eu wrote: So who wants to pick up the pieces now? Because I'm almost pissed off enough to turn down the tinderbox and give a big FU to Gentoo already. https://bugs.gentoo.org/show_bug.cgi?id=527608 Apparently Mr. Frysinger needs an education? Signs of his inability to collaborate in some situations have come up repeatedly on this list, be it problems with crossdev/multilib, games team and whatnot. Most of these were either ignored or had to go through a council decision. That's not really efficient and cannot work long term. Do we treat some developers differently? And does all this social status crap really improve collaboration overall?
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-nds/openldap/files: openldap-2.4.40-db-6.patch
On Wed, Oct 29, 2014 at 05:42:57AM -0400, Rich Freeman wrote: On Tue, Oct 28, 2014 at 11:37 PM, Vadim A. Misbakh-Soloviov m...@mva.name wrote: Btw, since Gentoo do not (mostly) provide packages itself, but only build instructions (ebuild), can't we just ship ebuild that patches openldap violates to force to use db6=19 with bindist USE? Can we do it legally? Sure. Will we do it? I think that depends on whether the maintainer or somebody else wants to keep up with the necessary work if upstream has dropped it. It is really up to the maintainer. Generally we try to follow upstream because we don't have the manpower to do otherwise most of the time. Upstream openldap notes that Oracle's lawyers has pursued anybody found using the AGPL3 BDB OpenLDAP together. So unless you have a commercial license [1] for BDB to escape AGPL3 in that case, you'll find yourself in a sticky situation quickly. Upstream asked me to make it harder for users to get burnt like this, and I agreed. See my comments in the original bug (bug 525110#c16), if there is a user that DOES have that Oracle license [2], I'll find a way to support them via useflag. [1] https://en.wikipedia.org/wiki/Berkeley_DB#Licensing As of July 2011, Oracle's list price for non-copyleft Berkeley DB licenses varies between 900 and 13,800 USD per processor. [2] This puts it in the same camp as the original Oracle OCI8 support we put in PHP; before oracle-instantclient-* packages were in the tree. There was demand, just non-trivial to support, as we as devs could not easily test it. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On 31 October 2014 22:38, hasufell hasuf...@gentoo.org wrote: Signs of his inability to collaborate in some situations have come up repeatedly on this list, be it problems with crossdev/multilib, games team and whatnot. Most of these were either ignored or had to go through a council decision. That's not really efficient and cannot work long term. Do we treat some developers differently? And does all this social status crap really improve collaboration overall? And we lost more than one developer in the process because of that. And guess what? After someone reaching out to me off list telling me to, essentially, work around him or swallow it, I'm more convinced than ever that either someone else (Council? QA? the Pope?) fixes this, or I'll add myself to that list. Seriously, he essentially has been ignoring me altogether *when I was voted the freaking QA lead*. (To be fair, huge thanks to Rich and Jer for their help here, it does feel good to know that at least some of the colleagues do have my back.) Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
I'm going to speak generally - this is a list and not really the best way of dealing with individuals. If you think the principles apply to you, feel free to apply them. On Fri, Oct 31, 2014 at 7:50 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: I'm more convinced than ever that either someone else (Council? QA? the Pope?) fixes this, or I'll add myself to that list. The fundamental problem here is that we're a volunteer organization, which means we're limited to the resources people offer us. Sometimes these resources are offered conditionally, and our choice can end up being take it or leave it. I do tend to agree that accepting the gift with strings can cost you more in the long term than just doing without. The problem comes when somebody in a critical position wants to take a hard stand on something. You either end up making an exception for them, relaxing policy for everybody, or risk being left in a hard place if they choose to stop contributing. Now, something that we have been trying to do is remove artificial roadblocks. For example, if somebody is standing in the way of others contributing the Council can step in and tell the others that they can go ahead and prevent anybody from interfering from them. Examples of this are somebody wants to add support for some feature to a bunch packages and assume responsibility any issues, and a maintainer wants to block them. What we can't do is force somebody to contribute. If somebody says that if we don't do multilib their way, they'll stop being the only libreoffice maintainer, and nobody else wants to maintain libreoffice, then we are left in a hard place (completely contrived scenario). We can stop people from interfering, but we can't make them contribute. So, in a case like this we certainly could prevent somebody from closing a bug, but we certainly can't force them to fix a bug. We could also block somebody from submitting tinderbox bugs without attached logs, but we can't force them to run a tinderbox. So, if there is a better way, I'm all ears for constructive suggestions. By constructive I mean that somebody who comes up with a script that automatically retrieves build logs and attaches them to bugs is being more helpful than somebody who says that somebody else should come up with such a script, and so on. That doesn't mean that we can't talk about solutions before we build them - only that it isn't helpful when we basically demand that others build them for us. -- Rich
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
Sorry for top posting. I volunteer to write something to get the logs attached to bugs. I'll do it next week. Whether it be something the tinderbox can run or something separate that will use pybugz to find bugs and then attach whatever logs are pointed to by URLs, etc, I'll figure it out. Sent from an iPhone, sorry for the HTML... On Oct 31, 2014, at 7:50 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 31 October 2014 22:38, hasufell hasuf...@gentoo.org wrote: Signs of his inability to collaborate in some situations have come up repeatedly on this list, be it problems with crossdev/multilib, games team and whatnot. Most of these were either ignored or had to go through a council decision. That's not really efficient and cannot work long term. Do we treat some developers differently? And does all this social status crap really improve collaboration overall? And we lost more than one developer in the process because of that. And guess what? After someone reaching out to me off list telling me to, essentially, work around him or swallow it, I'm more convinced than ever that either someone else (Council? QA? the Pope?) fixes this, or I'll add myself to that list. Seriously, he essentially has been ignoring me altogether *when I was voted the freaking QA lead*. (To be fair, huge thanks to Rich and Jer for their help here, it does feel good to know that at least some of the colleagues do have my back.) Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-portage-dev] [PATCH] 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 adds a diff_mixed_wrapper class which is used to simplify
diff_mixed usage.
bin/dispatch-conf| 39 ++-
pym/portage/dispatch_conf.py | 150 +--
2 files changed, 151 insertions(+), 38 deletions(-)
diff --git a/bin/dispatch-conf b/bin/dispatch-conf
index 6d2ae94..412dcdc 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_wrapper
from portage.process import find_binary, spawn
FIND_EXTANT_CONFIGS = find '%s' %s -name '._cfg_%s' ! -name '.*~' !
-iname '.*.bak' -print
@@ -72,6 +72,8 @@ def cmd_var_is_valid(cmd):
return find_binary(cmd[0]) is not None
+diff = diff_mixed_wrapper(diffstatusoutput, DIFF_CONTENTS)
+
class dispatch:
options = {}
@@ -89,8 +91,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 +148,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 +163,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 +178,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 +251,13 @@ class dispatch:
valid_input = qhtnmlezu
+def diff_pager(file1, file2):
+cmd = self.options['diff'] % (file1, file2)
+cmd += pager
+spawn_shell(cmd)
+
+diff_pager = diff_mixed_wrapper(diff_pager)
+
for conf in confs:
count = count + 1
@@ -266,14 +270,10 @@ class dispatch:
while 1:
clear_screen()
if show_new_diff:
-cmd = self.options['diff'] % (conf['new'], mrgconf)
-cmd += pager
-spawn_shell(cmd)
+diff_pager(conf['new'], mrgconf)
show_new_diff = 0
else:
-cmd = self.options['diff'] % (conf['current'], newconf)
-cmd += pager
-spawn_shell(cmd)
+diff_pager(conf['current'], newconf)
print()
print(' (%i of %i) -- %s' % (count, len(confs), conf
['current']))
@@ -357,7 +357,12 @@ class dispatch:
def replace (self, newconf, curconf):
Replace current config with the new/merged version. Also logs
the diff of what changed into the configured log file.
-os.system((DIFF_CONTENTS % (curconf, newconf)) + '' +
self.options[log-file])
+if log-file in self.options:
+status, output = diff(curconf, newconf)
+with
