When trying to merge modular x.org and reaching the 'linuxwacom' package: ====================================================== checking for valid Xorg SDK... "xf86Version.h missing" configure: error: "Unable to find xf86Version.h under /usr/lib/Server//include and WCM_XORGSDK/xc/include" !!! ERROR: x11-misc/linuxwacom-0.6.7 failed. Call stack: ebuild.sh, line 1525: Called dyn_compile ebuild.sh, line 928: Called src_compile linuxwacom-0.6.7.ebuild, line 94: Called econf '--with-gtk=2.0' '--without-tcl' '--without-tk' '--with-xorg-sdk=/usr/lib/Server/' '--with-xlib=/usr/lib' '--disable-wacomdrv' '--enable-wacdump' '--enable-xsetwacom' '--without-xf86-sdk' ebuild.sh, line 526: Called die !!! econf failed ====================================================== I have not defined INPUT_DEVICES, so 'linuxwacom' is part of the default Xorg installation. The folder /usr/lib/Server does not exist.
Stable version won't work w/ modular X. *** This bug has been marked as a duplicate of 127864 ***
Duplicate! Haha! Before posting this, I went to http://bugs.gentoo.org and searched for "linuxwacom xf86Version.h" and got "Zarro bugs found". Your bug filing system really sucks, huh!
Oh, and resolving this bug to another duplicate is sort of ridiculous. If anyone else stumbles here, the info you want is in bug 101674: http://bugs.gentoo.org/show_bug.cgi?id=101674 (Which also has xf86version.h and linuxwacom in it's subject. That's just hilarious.)
Uhm... you need to prefix your search with ALL when searching for duplicates - as noted directly below the search box. Even better way to search for duplicates: 1/ http://bugs.gentoo.org/query.cgi - click on Advanced Search 2/ Paste the error into 'A Comment' field (configure: error: "Unable to find xf86Version.h) 3/ Select 'contains the string' from drop-down menu 4/ Optionally, put ebuild name into 'Summary' field to narrow down the search 5/ Click on 'Search' button http://tinyurl.com/ghrrb So, how about reading help on how to search in bugzilla?
> Uhm... you need to prefix your search with ALL > when searching for duplicates - > as noted directly below the search box. I wasn't looking for duplicates. I was looking for any bugs containing "xf86version.h" and "linuxwacom". > Even better way to search for duplicates: > > 1/ http://bugs.gentoo.org/query.cgi - click on Advanced Search > 2/ Paste the error into 'A Comment' field > 3/ Select 'contains the string' from drop-down menu > 4/ Optionally, put ebuild name into 'Summary' field > 5/ Click on 'Search' button Thanks! Oh, and what a horrible web interface, by the way. > So, how about reading help on how to search in bugzilla? So, how about not acting like a 14-year old? Of course that might be hard if you ARE a 14-year old, which your repeated acts of arrogance and failure to understand the simplest problem when described to you in great detail does seem to suggest.
(In reply to comment #5) > I wasn't looking for duplicates. > I was looking for any bugs containing "xf86version.h" and "linuxwacom". Of course you were. To search for closed bugs, you need to prefix your search with ALL, as noted below the search box. Read! > Oh, and what a horrible web interface, by the way. Oh, how about going to complain upstream. We didn't write bugzilla, we are using it. https://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla > > So, how about reading help on how to search in bugzilla? > > So, how about not acting like a 14-year old? How about not buspamming us with pointless rants b/c you failed to search properly? > Of course that might be hard if you ARE a 14-year old, which your repeated acts > of arrogance and failure to understand the simplest problem when described to > you in great detail does seem to suggest. > 'k tnxbye, CLOSED. I don't have any problem, you have a problem w/ using bugzilla search in even the most simple way, all adding ALL before your search terms.
> > I wasn't looking for duplicates. > > Of course you were. No.. And the bug relevant to me: http://bugs.gentoo.org/show_bug.cgi?id=101674 is not a duplicate either. It *does* have "linuxwacom" and "xf86Version.h" in both summary, description and comments. > > I was looking for any bugs containing "xf86version.h" and "linuxwacom". > > To search for closed bugs, you need to prefix your search > with ALL, as noted below the search box. Read! This is what the search box say: "When searching for duplicate bugs or using multiple search terms, affix 'ALL' to your entry" 1.) I wasn't searching for duplicates. 2.) I wasn't specifically searching for bugs matching both terms. If bugs containing just one of the terms were to be returned, I would have looked at those too. Affixing "ALL" in the context of "matching all of the multiple search terms" would therefore be wrong too. In conclusion, I've used the Gentoo bugs search engine *exactly* as the search engine has told me to. It's the search engine that's broken. > > Oh, and what a horrible web interface, by the way. > > Oh, how about going to complain upstream. > We didn't write bugzilla, we are using it. Fair enough. Have you considered switching to something else? Seems Bugzilla development is moving at a snail's pace, and there are excellent alternatives available. Some even have Bugzilla conversion scripts. > How about not buspamming us with pointless rants > b/c you failed to search properly? Pointless and unfounded accusations. Grow up.
(In reply to comment #7) > 1.) I wasn't searching for duplicates. > 2.) I wasn't specifically searching for bugs matching both terms. If bugs > containing just one of the terms were to be returned, I would have looked at > those too. Affixing "ALL" in the context of "matching all of the multiple > search terms" would therefore be wrong too. You were searching for duplicates, explained twice above, not going to waste my time any more. Closed bug = duplicate. > In conclusion, I've used the Gentoo bugs search engine *exactly* as the search > engine has told me to. It's the search engine that's broken. No, your search skills are broken. Additionally, you failed to read the instructions and my explanation and you keep on bugspamming us instead of learning how to search for bugs properly. > > > Oh, and what a horrible web interface, by the way. > > > > Oh, how about going to complain upstream. > > We didn't write bugzilla, we are using it. > > Fair enough. > Have you considered switching to something else? > Seems Bugzilla development is moving at a snail's pace, and there are excellent > alternatives available. Some even have Bugzilla conversion scripts. Care to enlighten us how to migrate 130,000 bugs database to another bug tracker? Not viable, I can ensure you. > Pointless and unfounded accusations. Grow up. We really need the feature to lock bugs. Go rant elsewhere, not interested in receiving useless bugspam into my mailbox. Read the fine manual [1] before you start to complain about how much bugzilla search sucks next time. [1] http://bugs.gentoo.org/quicksearch.html <snip> # Open vs. Resolved Bugs: By default, only open (i.e. unresolved) bugs are shown. Use +DUP as first word in your query to include duplicate bugs in your search, FIXED to search for fixed bugs only, or ALL to search all bugs, regardless of status or resolution. Searching for duplicates is recommended if you can't find an open bug directly. * +DUP,FIXED table border * ALL mouse wheel </snip> CLOSED, no reply needed whatsoever.
Try echo ACCEPT_KEYWORDS=~x86 >> /etc/make.conf You wont miss a bugfix then, in the future :)
> Try echo ACCEPT_KEYWORDS=~x86 >> /etc/make.conf Thanks :o) > Closed bug = duplicate. > You were searching for duplicates > your search skills are broken. > you failed to read the instructions If I want to search for closed items, I need to look for duplicates ? That's not documented on the search page at: http://bugs.gentoo.org/ at all. Ergo my skills are fine, it's the documentation on that page that is broken. > you keep on bugspamming us Pointless and unfounded accusations. > instead of learning how to search for bugs properly. It's a horrible interface, but I'm trying to learn. Thank you for taking the time to explain where I went wrong. > > Have you considered switching to something else? > > Seems Bugzilla development is moving at a snail's pace, and there are excellent > > alternatives available. Some even have Bugzilla conversion scripts. > > Care to enlighten us how to migrate 130,000 > bugs database to another bug tracker? A conversion script is worth a try, although it might need tweaking. The one I had in mind is for the "Trac" tracker: http://projects.edgewall.com/trac/browser/trunk/contrib/bugzilla2trac.py > We really need the feature to lock bugs. Yes, a less democratic system where Jakub Moc can litter garbage in more issues which he doesn't care enough to read and understand (but will happily leave accusations and misleading comments in) is just what we need. Nobody should have the opportunity to question the almighty words of Mr. Moc - the 14 year old dictator is always right :-). Ok, maybe that wasn't nice. Sorry, couldn't resist. Honestly, I don't fancy making personal attacks towards you at all. But with all the crappy unfounded accusations you make against my person, I do feel that it's OK to at least defend myself. > CLOSED, no reply needed whatsoever. You're right, enough of this. Sorry. I feel that the bugzilla2trac.py information is interesting enough that you might want to know about it though, so I think I'll drop this last comment in anyway..
(In reply to comment #10) > > Care to enlighten us how to migrate 130,000 > > bugs database to another bug tracker? > > A conversion script is worth a try, although it might need tweaking. > The one I had in mind is for the "Trac" tracker: > http://projects.edgewall.com/trac/browser/trunk/contrib/bugzilla2trac.py trac????? You must be damned joking, right? Well, apparently you don't have even the slightest clue what you are talking about, so please... better keep the suggestions for yourself. The above suggestion really amused me, though, I have to admin. Trac issue tracker misses about 90% of features we use currently. Ktnxbye.
