Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On 10/13/14 1:38 AM, viv...@gmail.com wrote: have you considered to stabilize gcc:4.9 instead possibly 4.9.2 ? I'm not really suggesting to do so, but seem that most of the problems of 4.9.1 are the same of 4.8.3 so maybe it's worth considering. Il 11/10/2014 13:57, Paweł Hajdan, Jr. ha scritto: We'll really need gcc-4.8 in stable within 6-12 weeks from now. Chromium starts making heavy use of C++11 language features, see http://chromium-cpp.appspot.com/ . I don't realistically see us being able to just patch chromium to work around that. for 4.9.2 the 6-12 week window could be a problem Yeah, I don't think we can go straight to 4.9 without the latter spending time in ~arch, and for now it's still hard masked. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
I can spend some time with the tinderbox on 4.9 but the maintainers will have to accept that the logs will be linked and not attached. (This being the main reason why I stopped bothering unless people asked me explicitly, given how many times someone closed my bugs with NEEDINFO because the logs were not attached.) Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 18 October 2014 08:51, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 10/13/14 1:38 AM, viv...@gmail.com wrote: have you considered to stabilize gcc:4.9 instead possibly 4.9.2 ? I'm not really suggesting to do so, but seem that most of the problems of 4.9.1 are the same of 4.8.3 so maybe it's worth considering. Il 11/10/2014 13:57, Paweł Hajdan, Jr. ha scritto: We'll really need gcc-4.8 in stable within 6-12 weeks from now. Chromium starts making heavy use of C++11 language features, see http://chromium-cpp.appspot.com/ . I don't realistically see us being able to just patch chromium to work around that. for 4.9.2 the 6-12 week window could be a problem Yeah, I don't think we can go straight to 4.9 without the latter spending time in ~arch, and for now it's still hard masked. Paweł
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On Sun Oct 12 01:27:38 2014 Anthony G. Basile bluen...@gentoo.org wrote: On 10/11/14 16:28, Rich Freeman wrote: On Sat, Oct 11, 2014 at 4:07 PM, M. Ziebell ziebell_ma...@posteo.de wrote: But if anyone would ask me to stabilize gcc-4.8 I would say amd64 ok. If there is general consensus that this is going to be a stable target it might make sense to start running mixed stable+gcc-4.8 systems as widely as possible for feedback. -- Rich Looking at the following two trackers: #461954 - GCC 4.8 porting #516152 - sys-devel/gcc-4.8.? stabilization I would say the following still should be fixed: snip #500944 - =media-libs/x264-0.0.20111220 segmentation faults during initialization of x264 encoder in x264_cqm_init () from /usr/lib/libx264.so.120 Most likely already fixed in current stable x264-0.0.20140308 #500966 - =net-libs/webkit-gtk-2.2.4 USE=-webgl - ./.libs/libwebkitgtk-1.0.so: undefined reference to `_ZN3JSC21GenericTypedArrayViewINS_14Float32AdaptorEE6createEj' Not a blocker for gcc-4.8 stabilization - I can reproduce this bug with gcc-4.7. #513386 - net-libs/webkit-gtk-2.4.3 - ./.libs/libwebkitgtk-3.0.so: undefined reference to `_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17' Maybe documentation + news item would be enough? -- Alexander Tsoy
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
El sáb, 18-10-2014 a las 12:35 +0100, Diego Elio Pettenò escribió: I can spend some time with the tinderbox on 4.9 but the maintainers will have to accept that the logs will be linked and not attached. (This being the main reason why I stopped bothering unless people asked me explicitly, given how many times someone closed my bugs with NEEDINFO because the logs were not attached.) Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ What is the main reason for not being able to attach them to the bugs (as normally is done with other bug reports not related with tinderbox)? Wouldn't be possible to, once they are stored on your amazon webservice account, use wget to download them and attach them using pybugz for example?
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
If you write the code for that, be my guest. But the code is in Ruby and does not open the bug directly (only links to a pre-filled bug form). When I wrote it, Python was definitely not among my strong languages. While I can probably write it now, I don't have the time. As I said I'm happy to volunteer my time to run the tinderbox and file the bugs. But I won't do so if all I'm going to get back is bitching. It seems a fair proposal to me. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 18 October 2014 12:59, Pacho Ramos pa...@gentoo.org wrote: El sáb, 18-10-2014 a las 12:35 +0100, Diego Elio Pettenò escribió: I can spend some time with the tinderbox on 4.9 but the maintainers will have to accept that the logs will be linked and not attached. (This being the main reason why I stopped bothering unless people asked me explicitly, given how many times someone closed my bugs with NEEDINFO because the logs were not attached.) Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ What is the main reason for not being able to attach them to the bugs (as normally is done with other bug reports not related with tinderbox)? Wouldn't be possible to, once they are stored on your amazon webservice account, use wget to download them and attach them using pybugz for example?
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On 10/18/14 07:56, Alexander Tsoy wrote: On Sun Oct 12 01:27:38 2014 Anthony G. Basile bluen...@gentoo.org wrote: On 10/11/14 16:28, Rich Freeman wrote: On Sat, Oct 11, 2014 at 4:07 PM, M. Ziebell ziebell_ma...@posteo.de wrote: But if anyone would ask me to stabilize gcc-4.8 I would say amd64 ok. If there is general consensus that this is going to be a stable target it might make sense to start running mixed stable+gcc-4.8 systems as widely as possible for feedback. -- Rich Looking at the following two trackers: #461954 - GCC 4.8 porting #516152 - sys-devel/gcc-4.8.? stabilization I would say the following still should be fixed: snip #500944 - =media-libs/x264-0.0.20111220 segmentation faults during initialization of x264 encoder in x264_cqm_init () from /usr/lib/libx264.so.120 Most likely already fixed in current stable x264-0.0.20140308 Can someone check. #500966 - =net-libs/webkit-gtk-2.2.4 USE=-webgl - ./.libs/libwebkitgtk-1.0.so: undefined reference to `_ZN3JSC21GenericTypedArrayViewINS_14Float32AdaptorEE6createEj' Not a blocker for gcc-4.8 stabilization - I can reproduce this bug with gcc-4.7. Yeah. I thought this was some c++11 thing but it isn't. #513386 - net-libs/webkit-gtk-2.4.3 - ./.libs/libwebkitgtk-3.0.so: undefined reference to `_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17' Maybe documentation + news item would be enough? I think that's the way to go here --- a news item. The story with c++11 is that gcc-4.8 can do c++11 but doesn't default to it. The fedora folks basically said just don't use it yet. We can't stop users from adding -std=c++11 to their flags, but at least we can warn them. I looked into writing some eclass function which could test if a library is_c++11_abi() but this turns out to be harder than one might think. You'd have to specifically go through a list of ABI changes something along the lines of what's listed here [1]. So the next step is 1) I'll write a news item regarding gcc-4.8 stabilization and the c++11 problem, 2) we start the stabilization of =sys-devel/gcc-4.8.3 =dev-libs/cloog-0.18.1 =dev-libs/isl-0.12.2, then 3) we work at dealing with the abi issue for when/if it becomes the default. Ref [1] https://gcc.gnu.org/wiki/Cxx11AbiCompatibility -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
El sáb, 18-10-2014 a las 14:15 +0100, Diego Elio Pettenò escribió: If you write the code for that, be my guest. But the code is in Ruby and does not open the bug directly (only links to a pre-filled bug form). When I wrote it, Python was definitely not among my strong languages. While I can probably write it now, I don't have the time. As I said I'm happy to volunteer my time to run the tinderbox and file the bugs. But I won't do so if all I'm going to get back is bitching. It seems a fair proposal to me. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ What do you use to open the bug reports? Maybe could be easily be done at that step :| (or even run some small script after the bug if filled simply re-fetching the file from amazon and attaching to the bug it's being processed)
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
All the stack is at https://github.com/gentoo/tboxanalysis The opening of the bug report is done by a piece of meatware called me. The UI displays a link that I can click to pre-fill the bug report. The rest of the information is filled in manually and submitted. Also remember that the linked logs might be too big for Bugzilla to attach uncompressed... and some of them even compressed. I take it that at least one person (you) will object at me keeping the process as is, so for the moment I won't be wasting my time on this. Call me back if you find a way to fix that without requiring more of my time. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ On 18 October 2014 17:55, Pacho Ramos pa...@gentoo.org wrote: El sáb, 18-10-2014 a las 14:15 +0100, Diego Elio Pettenò escribió: If you write the code for that, be my guest. But the code is in Ruby and does not open the bug directly (only links to a pre-filled bug form). When I wrote it, Python was definitely not among my strong languages. While I can probably write it now, I don't have the time. As I said I'm happy to volunteer my time to run the tinderbox and file the bugs. But I won't do so if all I'm going to get back is bitching. It seems a fair proposal to me. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ What do you use to open the bug reports? Maybe could be easily be done at that step :| (or even run some small script after the bug if filled simply re-fetching the file from amazon and attaching to the bug it's being processed)
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On 10/18/2014 01:00 PM, Diego Elio Pettenò wrote: All the stack is at https://github.com/gentoo/tboxanalysis The opening of the bug report is done by a piece of meatware called me. The UI displays a link that I can click to pre-fill the bug report. The rest of the information is filled in manually and submitted. Also remember that the linked logs might be too big for Bugzilla to attach uncompressed... and some of them even compressed. I take it that at least one person (you) will object at me keeping the process as is, so for the moment I won't be wasting my time on this. Call me back if you find a way to fix that without requiring more of my time. Perhaps a stupid question, but: why is it a problem if the logs are linked rather than attached?
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
El sáb, 18-10-2014 a las 18:00 +0100, Diego Elio Pettenò escribió: All the stack is at https://github.com/gentoo/tboxanalysis The opening of the bug report is done by a piece of meatware called me. The UI displays a link that I can click to pre-fill the bug report. The rest of the information is filled in manually and submitted. Also remember that the linked logs might be too big for Bugzilla to attach uncompressed... and some of them even compressed. I take it that at least one person (you) will object at me keeping the process as is, so for the moment I won't be wasting my time on this. Call me back if you find a way to fix that without requiring more of my time. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ No, I don't object at all :), I never closed a bug because of this, but was only trying to reach a way we could make all people happy (I don't mind at all having attachments in amazon as long as they are available or attachments) Of course, if no dev has any problems (like me) with having them either on amazon or attached, no action is required... but per your comments looks like there were people having problems with that approach, then, I thought if maybe some tweaks (or simply use an additional script for the only purpose or attaching the files) could finally fix this arguments for the future ;)
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
El sáb, 18-10-2014 a las 13:19 -0400, Michael Orlitzky escribió: On 10/18/2014 01:00 PM, Diego Elio Pettenò wrote: All the stack is at https://github.com/gentoo/tboxanalysis The opening of the bug report is done by a piece of meatware called me. The UI displays a link that I can click to pre-fill the bug report. The rest of the information is filled in manually and submitted. Also remember that the linked logs might be too big for Bugzilla to attach uncompressed... and some of them even compressed. I take it that at least one person (you) will object at me keeping the process as is, so for the moment I won't be wasting my time on this. Call me back if you find a way to fix that without requiring more of my time. Perhaps a stupid question, but: why is it a problem if the logs are linked rather than attached? Supposedly we always must attach files to bug reports to ensure they are kept forever with that bug reports instead of relying on external resources that could disappear in the future (or far future). If I don't misremember, flameeyes was paying for having that logs kept in that amazon resource for a long long time... but some people were stricter applying this rule and asked him to attach the file instead... leading to the bug being closed as NEEDINFO and...
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On 10/18/2014 01:34 PM, Pacho Ramos wrote: Supposedly we always must attach files to bug reports to ensure they are kept forever with that bug reports instead of relying on external resources that could disappear in the future (or far future). If I don't misremember, flameeyes was paying for having that logs kept in that amazon resource for a long long time... but some people were stricter applying this rule and asked him to attach the file instead... leading to the bug being closed as NEEDINFO and... Dude... what? If this is what's holding up a tinderbox run, add me to the bug template as a CC and I'll personally download and attach every log to bugzilla. If at some point we all decide this is super silly and embarrassing, perhaps we can eliminate that step.
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
El sáb, 18-10-2014 a las 14:03 -0400, Michael Orlitzky escribió: On 10/18/2014 01:34 PM, Pacho Ramos wrote: Supposedly we always must attach files to bug reports to ensure they are kept forever with that bug reports instead of relying on external resources that could disappear in the future (or far future). If I don't misremember, flameeyes was paying for having that logs kept in that amazon resource for a long long time... but some people were stricter applying this rule and asked him to attach the file instead... leading to the bug being closed as NEEDINFO and... Dude... what? If this is what's holding up a tinderbox run, add me to the bug template as a CC and I'll personally download and attach every log to bugzilla. If at some point we all decide this is super silly and embarrassing, perhaps we can eliminate that step. I am also willing to help doing that if nothing better can be done
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On 18 October 2014 19:03, Michael Orlitzky m...@gentoo.org wrote: Dude... what? If this is what's holding up a tinderbox run, add me to the bug template as a CC and I'll personally download and attach every log to bugzilla. If at some point we all decide this is super silly and embarrassing, perhaps we can eliminate that step. Yeah this is essenially why I stopped spending time on tinderboxing, especially as the someone kept closing bugs that eh wouldn't have looked at anyway. Indeed, for context, the main rule about attaching logs is to avoid people filing bugs and referencing pastebin that can break in even just a week. And the complains I got are of the like of what if you decide to stop paying amazon? — that would more be the case if I end up having some more health issues and be unable to pay, as the $2/month (less now, thanks to Amazon slashing prices earlier this year) is not something I feel. Especially in comparison to the $600/month the tinderbox *hardware* costs me to host. If there is the interest, I'll start prop it up for gcc-4.9 testing even tonight. It'll take a couple of weeks to go all through it. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-portage-dev] Re: [PATCH] emerge --search: use description index
This updated patch adds --search-index y | n . I'll be maintaining
this patch in the following branch:
https://github.com/zmedico/portage/tree/bug_525718
From 2aca92f664fd2ff669b77b38a49b06fafbc66b8d Mon Sep 17 00:00:00 2001
From: Zac Medico zmed...@gentoo.org
Date: Fri, 17 Oct 2014 17:38:59 -0700
Subject: [PATCH] emerge --search: use description index
This adds an egencache --update-pkg-desc-index action which generates
a plain-text index of package names, versions, and descriptions. The
index can then be used to optimize emerge --search / --searchdesc
actions. If the package description index is missing from a particular
repository, then all metadata for that repository is obtained using the
normal pordbapi.aux_get method.
Searching of installed packages is optimized to take advantage of
vardbdbapi._aux_cache, which is backed by vardb_metadata.pickle.
See the IndexedVardb docstring some more details.
For users that would like to modify ebuilds in a repository without
running egencache afterwards, the new emerge --search-index y | n
option can be used to get non-indexed search. Alternatively, the user
could simply remove the stale index file, in order to disable the
search index for a particular repository.
X-Gentoo-Bug: 525718
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=525718
---
bin/egencache | 43 ++-
man/egencache.1| 4 +
man/emerge.1 | 8 ++
man/portage.5 | 6 ++
pym/_emerge/actions.py | 3 +-
pym/_emerge/main.py| 5 ++
pym/_emerge/search.py | 198 +
7 files changed, 250 insertions(+), 17 deletions(-)
diff --git a/bin/egencache b/bin/egencache
index e366058..90d5e68 100755
--- a/bin/egencache
+++ b/bin/egencache
@@ -57,7 +57,7 @@ from portage.util._async.run_main_scheduler import
run_main_scheduler
from portage.util._eventloop.global_event_loop import global_event_loop
from portage import cpv_getkey
from portage.dep import Atom, isjustname
-from portage.versions import pkgsplit, vercmp
+from portage.versions import pkgsplit, vercmp, _pkg_str
try:
from xml.etree import ElementTree
@@ -91,6 +91,9 @@ def parse_args(args):
actions.add_argument(--update-changelogs,
action=store_true,
help=update the ChangeLog files from SCM logs)
+ actions.add_argument(--update-pkg-desc-index,
+ action=store_true,
+ help=update package description index)
actions.add_argument(--update-manifests,
action=store_true,
help=update manifests)
@@ -451,6 +454,35 @@ class GenCache(object):
if hasattr(trg_cache, '_prune_empty_dirs'):
trg_cache._prune_empty_dirs()
+class GenPkgDescIndex(object):
+ def __init__(self, portdb, output_file):
+ self.returncode = os.EX_OK
+ self._portdb = portdb
+ self._output_file = output_file
+
+ def run(self):
+
+ portage.util.ensure_dirs(os.path.dirname(self._output_file))
+ f = portage.util.atomic_ofstream(self._output_file,
+ encoding=_encodings[repo.content])
+
+ portdb = self._portdb
+ for cp in portdb.cp_all():
+ pkgs = portdb.cp_list(cp)
+ if not pkgs:
+ continue
+ desc, = portdb.aux_get(pkgs[-1], [DESCRIPTION])
+
+ if len(pkgs) == 1:
+ output = %s: %s\n % (pkgs[0], desc)
+ else:
+ output = %s,%s: %s\n % (pkgs[0],
+ ,.join(_pkg_str(cpv).version
+ for cpv in pkgs[1:]), desc)
+ f.write(output)
+
+ f.close()
+
class GenUseLocalDesc(object):
def __init__(self, portdb, output=None,
preserve_comments=False):
@@ -893,7 +925,8 @@ def egencache_main(args):
local_config=False, env=env)
if not (options.update or options.update_use_local_desc or
- options.update_changelogs or options.update_manifests):
+ options.update_changelogs or options.update_manifests or
+ options.update_pkg_desc_index):
parser.error('No action specified')
return 1
@@ -1057,6 +1090,12 @@ def egencache_main(args):
else:
ret.append(scheduler.returncode)
+ if options.update_pkg_desc_index:
+ gen_index = GenPkgDescIndex(portdb, os.path.join(
+ repo_config.location, metadata, pkg_desc_index))
+ gen_index.run()
+ ret.append(gen_index.returncode)
+
if options.update_use_local_desc:
gen_desc =
