Re: [gentoo-user] kernel guys sent me back here
I was referred back to my distro supplier for a kernel crash. Isn't that a kernel problem? https://bugzilla.kernel.org/show_bug.cgi?id=62981 The first thing for any crash is logs. And btw ... don't go to the Linux kernel if you're running any Gentoo sys-kernel/* source. Only if you get your source from kernel.org. OK, I'll file a Gentoo bug against sys-kernel/hardened-sources. I thought my logs weren't helpful in this case but I'll check again next time it crashes. I thought having a vmcore file would be a great way to help diagnose the problem but I guess not? - Grant
Re: [gentoo-user] app-text/poppler-0.24.3 fails to build
On Wed, Nov 06, 2013 at 08:01:18AM +0100, Norman Rieß wrote: Hello, poppler fails to build for me and i don't know why. Does someone got an idea about this? [ 97%] Building CXX object qt4/src/CMakeFiles/poppler-qt4.dir/ArthurOutputDev.cc.o cd /var/tmp/portage/app-text/poppler-0.24.3/work/poppler-0.24.3_build/qt4/src /usr/bin/x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H=1 -Dpoppler_qt4_EXPORTS -DNDEBUG -Wall -Wcast-align -fno-exceptions -fno-check-new -fno-common -ansi -Wnon-virtual-dtor -Woverloaded-virtual -O2 -pipe -fPIC -I/var/tmp/portage/app-text/poppler-0.24.3/work/poppler-0.24.3 -I/var/tmp/portage/app-text/poppler-0.24.3/work/poppler-0.24.3/fofi -I/var/tmp/portage/app-text/poppler-0.24.3/work/poppler-0.24.3/goo -I/var/tmp/portage/app-text/poppler-0.24.3/work/poppler-0.24.3/poppler -I/var/tmp/portage/app-text/poppler-0.24.3/work/poppler-0.24.3_build -I/var/tmp/portage/app-text/poppler-0.24.3/work/poppler-0.24.3_build/poppler -I/var/tmp/portage/app-text/poppler-0.24.3/work/poppler-0.24.3/qt4/src -I/var/tmp/portage/app-text/poppler-0.24.3/work/poppler-0.24.3_build/qt4/src -I/usr/include/freetype2 -I/usr/include/qt4-o CMakeFiles/poppler-qt4.dir/ArthurOutputDev.cc.o -c /var/tmp/portage/app-text/poppler-0.24.3/work/poppler-0.24.3/qt4/src/ArthurOutputDev.cc Traceback (most recent call last): Traceback (most recent call last): File /usr/bin/g-ir-scanner, line 46, in module File /usr/bin/g-ir-scanner, line 46, in module sys.exit(scanner_main(sys.argv)) File /usr/lib64/gobject-introspection/giscanner/scannermain.py, line 404, in scanner_main sys.exit(scanner_main(sys.argv)) File /usr/lib64/gobject-introspection/giscanner/scannermain.py, line 404, in scanner_main transformer = create_transformer(namespace, options) transformer = create_transformer(namespace, options) File /usr/lib64/gobject-introspection/giscanner/scannermain.py, line 297, in create_transformer File /usr/lib64/gobject-introspection/giscanner/scannermain.py, line 297, in create_transformer transformer.register_include(include_obj) File /usr/lib64/gobject-introspection/giscanner/transformer.py, line 131, in register_include transformer.register_include(include_obj) File /usr/lib64/gobject-introspection/giscanner/transformer.py, line 131, in register_include self._parse_include(filename) self._parse_include(filename) File /usr/lib64/gobject-introspection/giscanner/transformer.py, line 203, in _parse_include File /usr/lib64/gobject-introspection/giscanner/transformer.py, line 203, in _parse_include parser.parse(filename) File /usr/lib64/gobject-introspection/giscanner/girparser.py, line 60, in parse parser.parse(filename) File /usr/lib64/gobject-introspection/giscanner/girparser.py, line 60, in parse tree = parse(filename) File string, line 62, in parse tree = parse(filename) File string, line 62, in parse File string, line 38, in parse File string, line 38, in parse cElementTree.ParseError: syntax error: line 1, column 0 cElementTree.ParseError: syntax error: line 1, column 0 make[2]: *** [glib/Poppler-0.18.gir] Fehler 1 make[2]: Leaving directory `/var/tmp/portage/app-text/poppler-0.24.3/work/poppler-0.24.3_build' make[1]: *** [glib/CMakeFiles/gir-typelibs.dir/all] Fehler 2 make[1]: *** Warte auf noch nicht beendete Prozesse... make[2]: *** [glib/Poppler-0.18.gir] Fehler 1 make[2]: Leaving directory `/var/tmp/portage/app-text/poppler-0.24.3/work/poppler-0.24.3_build' make[1]: *** [glib/CMakeFiles/gir-girs.dir/all] Fehler 2 Linking CXX shared library libpoppler-qt4.so cd /var/tmp/portage/app-text/poppler-0.24.3/work/poppler-0.24.3_build/qt4/src /usr/bin/cmake -E cmake_link_script CMakeFiles/poppler-qt4.dir/link.txt --verbose=1 /usr/bin/x86_64-pc-linux-gnu-g++ -fPIC -Wall -Wcast-align -fno-exceptions -fno-check-new -fno-common -ansi -Wnon-virtual-dtor -Woverloaded-virtual -O2 -pipe -Wl,-O1 -Wl,--as-needed -Wl,--as-needed -shared -Wl,-soname,libpoppler-qt4.so.4 -o libpoppler-qt4.so.4.3.0 CMakeFiles/poppler-qt4.dir/poppler-annotation.cc.o CMakeFiles/poppler-qt4.dir/poppler-document.cc.o CMakeFiles/poppler-qt4.dir/poppler-embeddedfile.cc.o CMakeFiles/poppler-qt4.dir/poppler-fontinfo.cc.o CMakeFiles/poppler-qt4.dir/poppler-form.cc.o CMakeFiles/poppler-qt4.dir/poppler-link.cc.o CMakeFiles/poppler-qt4.dir/poppler-link-extractor.cc.o CMakeFiles/poppler-qt4.dir/poppler-movie.cc.o CMakeFiles/poppler-qt4.dir/poppler-optcontent.cc.o CMakeFiles/poppler-qt4.dir/poppler-page.cc.o CMakeFiles/poppler-qt4.dir/poppler-base-converter.cc.o CMakeFiles/poppler-qt4.dir/poppler-pdf-converter.cc.o CMakeFiles/poppler-qt4.dir/poppler-private.cc.o CMakeFiles/poppler-qt4.dir/poppler-ps-converter.cc.o CMakeFiles/poppler-qt4.dir/poppler-qiodeviceoutstream.cc.o CMakeFiles/poppler-qt4.dir/poppler-sound.cc.o CMakeFiles/poppler-qt4.dir/poppler-textbox.cc.o
Re: [gentoo-user] Re: do subslots improve user-experience?
Am Tue, 05 Nov 2013 16:44:43 +0200 schrieb Alan McKinnon alan.mckin...@gmail.com: On 05/11/2013 14:11, Marc Joliet wrote: Am Tue, 05 Nov 2013 12:14:59 +0200 schrieb Alan McKinnon alan.mckin...@gmail.com: On 05/11/2013 11:52, Martin Vaeth wrote: Alan McKinnon alan.mckin...@gmail.com wrote: You know what? I'm not convinced. What I'm seeing is a rather large towering edifice of complexity to deal with a problem that is not the general case. I find it funny that perhaps you did not realize that you repeated the main argument *in favour of subslots* on the dev mailing list: It seems to me that you didn't read the whole post fully, and have cherry-picked a part that you think bolsters your position. It does not. So I will repeat myself in a different way. I've run emerge -e world with the result of correcting something perhaps 2 or 3 times in 8 years. Let's assume that in the absence of portage being able to detect those nasty errors, that this is reasonably representative of the actual incidence of actual errors I encountered. Let's then be generous and triple it. In effect subslots appear to fix something for me about once a year. Is my logic^Wguess flawed in any way? For *you*! You are not everyone, although I'm sure you already know that ;) . See my Haskell example below for when subslots fix something more often. So now we have a rather large complex system that deals with what is essentially a minor problem that occurs say once a year. I completely understand the problem sub-slots is trying to solve. I'm just wondering if the methodology you are using to do it is valid, and if it does not become the cure that is worse than the disease. Consider for a moment the maintenance burden imposed on ebuild maintainers, and how sub-slot notation is essentially added by humans deploying human brains. And remember that humans are notoriously bad at using mathematically correct solutions (they ... err ... forget to do stuff). sub-slots, whilst quite likely mathematically correct, has all the hallmarks to me of SOMETHING THAT IS GOING TO FAIL DUE TO HUMANS. And humans seldom do those things that they should do . If this were not so, php would never have been written (just an arb random example) I predict once a week fallout from sub-slots induced bugs that was intended to fix once a year problem. Do you now see why I'm not convinced this is a real-world solution? I think I see your point, but what is the worst that can happen if somebody gets a subslot wrong? Since too *many* rebuilds aren't all too terrible (a waste of time for sure, and potentially annoying, but it won't outright break anything), I suppose the worst case is too *few* automatic rebuilds, right? So to me it sounds like you want to throw out the feature altogether because it won't *always* catch everything. Or what potential bugs are you thinking about that aren't useless rebuilds? I don't remember any from this thread, but of course I could have missed something. I too see your viewpoint, as you see mine. There's nothing wrong with your logic within the narrow domain of making the code that implements this specific feature (subslots) work correctly per spec. Background: I'm a Linux sysadmin by day at an ISP. I constantly have to contend with Devs and Devops writing bespoke code to implement business rules. Because I sit three feet back from the problem, I can almost always see the flaws with the solution. I can't give much details unfortunately, my employer owns the code. But I get to be very very good at spotting code that runs per spec, but is very brittle in the real world. I look for tells like this: For clarification: my background is very different and lies in science and engineering, which has its own (overlapping) set of programming problems, some of them probably (hopefully? (for you I mean)) of a more basic nature than what you have to deal with. One word: MATLAB. The only thing I'll say about it is that it's the only programming language I know whose usage can make me aggressive (and I like POSIX Shell, which at worst irritates me, so I think that's saying something). At least I was able to choose the language used for my master's thesis myself (Python, of course). - is the dev trying to get code deployed that is not fully tested? - is the dev trying to ignore or minimize the real world effect on other systems? - can the dev show that someone else (not him) can actually maintain it, configure it and understand it? - Can every single person in his team rattle off the primary salient points of the code without thinking much? - Did the team who write the code write a doc on how to configure it, and how to deal with possible failures they anticipate? - If someone else (like eg me) gets this wrong and I make mistakes while deploying, how will I know I've made a mistake? Do I
[gentoo-user] Re: do subslots improve user-experience?
Marc Joliet mar...@gmx.de wrote: One of those questions stands out to me right now: the one on understandable error messages. As some recent posts to this ML demonstrate, it seems to be one area where portage is visibly falling (staying?) behind right now. They remind me of the type of error message gcc/g++ spit out, actually. In both cases, it is technically very cumbersome to get good error messages. In fact, it would need alone more work in programming than to do the actual job (and it would slow down execution time drastically even if no errors arise). Concerning portage, the situation is apparently this (I am guessing this only from the outputs which are posted): When portage detects that it cannot resolve something after backtracking, it dies. Then all non-resolved conflicts are spit out - often these are some that *could* be resolved. So instead of dying, portage would need to try to continue to resolve anyway partially as far as it could and only then die. This would mean that branches cannot be cut, so the runtime would probably increase tremendously. Moreover, the result might be even more confusing if there is some strange branch in which slightly more resolving is possible.
Re: [gentoo-user] Re: do subslots improve user-experience?
On 06/11/2013 09:46, Martin Vaeth wrote: Alan McKinnon alan.mckin...@gmail.com wrote: You don't have to keep explaining subslots to me But not every reader knows the details - this is not a private conversation. Then please start your own thread on the matter and describe it all in the OP rather than replying to me in public answering a question I did not ask. Thank you -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Fwd: re: mouse pointer not consistent [net-misc/rdesktop-1.7.1] [mystery solved]
Original Message Subject:re: mouse pointer not consistent [net-misc/rdesktop-1.7.1] Date: Fri, 25 Oct 2013 22:49:04 +0300 From: Alexander Kapshuk alexander.kaps...@gmail.com To: gentoo-user@lists.gentoo.org When running [net-misc/rdesktop-1.7.1], I've noticed that the mouse pointer is sometimes shaped like a capital letter 'I', like when a mouse pointer is over a string of characters. Sorry, not sure what the proper name for the character is. While at other times, it is a proper mouse pointer, shaped like an arrow. Is it possible to have the proper mouse pointer displayed at all times? Thanks. Turns out I was barking up the wrong tree. It wasn't rdesktop's fault at all. The situation I described above happened when being connected to a Windows server 2012. The mouse pointer is now behaving properly with the 'Enable pointer shadow' option, found in the mouse properties in Control Panel, disabled. Thought I'd let the list know.
Re: [gentoo-user] Re: do subslots improve user-experience?
On 06/11/2013 14:54, Martin Vaeth wrote: Marc Joliet mar...@gmx.de wrote: One of those questions stands out to me right now: the one on understandable error messages. As some recent posts to this ML demonstrate, it seems to be one area where portage is visibly falling (staying?) behind right now. They remind me of the type of error message gcc/g++ spit out, actually. In both cases, it is technically very cumbersome to get good error messages. In fact, it would need alone more work in programming than to do the actual job (and it would slow down execution time drastically even if no errors arise). Concerning portage, the situation is apparently this (I am guessing this only from the outputs which are posted): When portage detects that it cannot resolve something after backtracking, it dies. Then all non-resolved conflicts are spit out - often these are some that *could* be resolved. So instead of dying, portage would need to try to continue to resolve anyway partially as far as it could and only then die. This would mean that branches cannot be cut, so the runtime would probably increase tremendously. Moreover, the result might be even more confusing if there is some strange branch in which slightly more resolving is possible. That by itself is good info. The conflict that portage couldn't resolve, is it the first one in the printed list, or the last? This helps tell us what bits we can ignore at least until the next emerge run -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Qt blocking @world update
On Sat, Nov 02, 2013 at 11:02:27PM +0100, Alex Schuster wrote: Hi there! My @world update did not go well. It was much worse some while ago, so I just did an emerge -e @world, after manually removing stuff from /var/lib/portage/world until I got no complaints any more. I had to remove kde-misc/publictransport and kde-misc/plasma-emergelog for that. After most was done, it stopped after one package failed to build, and was unable to resume due to blockers. emerge --resume gives this: weird portage # emerge -aj --resume These are the packages that would be merged, in order: [...] !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-qt/qtgui:4 (dev-qt/qtgui-4.8.5-r1::gentoo, installed) pulled in by =dev-qt/qtgui-4.8.5:4[accessibility,dbus(+)] required by (kde-base/libkworkspace-4.11.2::gentoo, installed) ~dev-qt/qtgui-4.8.5[aqua=,debug=,egl=,qt3support=] required by (dev-qt/qtopengl-4.8.5::gentoo, installed) (and 283 more with the same problems) (dev-qt/qtgui-4.8.4-r1::gentoo, ebuild scheduled for merge) pulled in by =dev-qt/qtgui-4.7.4:4[accessibility,dbus] required by (kde-misc/fsrunner-0.7.5::kde, installed) =dev-qt/qtgui-4.7.4:4[accessibility,dbus] required by (media-sound/kid3-2.2.1::kde, installed) ~dev-qt/qtgui-4.8.4[accessibility=,aqua=,debug=,qt3support] required by (dev-qt/qt3support-4.8.4::gentoo, ebuild scheduled for merge) (and 1 more with the same problems) [...] Any enlightenment would be very much appreciated. I just don't know how to get my system back working. ATM, KDE is mostly at version 4.11.2-r1, but some KDE packages still need to be updated. So, it does not work right now, unknown protocol file and such errors. I, too, had been having qt blocking qt, and I had no idea what was causing it. I guess I caused it myself because I updated qt with --nodeps (long story, kde 4.11.2 needs akonadi-server 1.10.3 which needed the then keyworded qt 4.8.5). Both 4.8.4 and 4.8.5 were stable by the end, but still something caused to pull in both, just as in your output. Yesterday I wanted to clean up emerge output so I can ask about it here. So I updated everything except qt (without --nodeps). And now world update is clean again. -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me with any Facebook service. Yesterday we stood at the abyss. Today we are one step further. signature.asc Description: Digital signature
[gentoo-user] Re: do subslots improve user-experience?
Alan McKinnon alan.mckin...@gmail.com wrote: On 06/11/2013 09:46, Martin Vaeth wrote: Alan McKinnon alan.mckin...@gmail.com wrote: You don't have to keep explaining subslots to me But not every reader knows the details - this is not a private conversation. Then please [...] describe it all in the OP rather than replying to me in public answering a question I did not ask. Then do not make strange claims like mumbling about an tremendous increase of complexity for developers which just call for a clarification of the actual truth. If you really know all the details about subslots, it is rather strange that you make such claims.
[gentoo-user] Re: do subslots improve user-experience?
Alan McKinnon alan.mckin...@gmail.com wrote: On 06/11/2013 14:54, Martin Vaeth wrote: (I am guessing this only from the outputs which are posted): When portage detects that it cannot resolve something after backtracking, it dies. That by itself is good info. The conflict that portage couldn't resolve, is it the first one in the printed list, or the last? I never looked at the algorithm, it is only a guess from the output. So I do no know the answer, and it does not matter, because every conflict which portage detects might be related to the actual cause or not: The algorithm with branch-cutting did not resolve the conflict, so every inconsistency which is left might or might not be related to the real obstacle which the user wants to remove. Most likely this obstacle is higher in the tree than the place where the conflict occurs (otherwise portage could resolve it or make a suggestion how to resolve it). In my experience, something related with the actual obstacle occurs rather late in the output or not at all.
