The latest XChat ebuild (2.0.4) is b0rked. After emerging it, there is no executable in /usr/bin. There is an xchat file there, but trying to chmod it fails. Despite the fact the file is listed, all commands treat the file as if there is no file at all. Hence XChat is b0rked as there is no way to launch it. I've tried emerge -C xchat && emerge xchat. No go. Reproducible: Always Steps to Reproduce: 1. ACCEPT_KEYWORDS="~x86" emerge xchat 2. Try and run xchat 3. No binaries! Expected Results: It should be launching XChat!
there's binaries for me. $ ll /usr/bin/xchat* -rwxr-xr-x 1 root root 1.2M Aug 8 17:01 /usr/bin/xchat* -rwxr-xr-x 1 root root 389K Aug 3 20:30 /usr/bin/xchat-2* xchat-2 runs version 2.0.4 just fine.
Works fine for me aswell. What errors are you getting when you try chmod? Can you also provide the output of ls -l /usr/bin/xchat*
This is what I did: emerge sync export ACCEPT_KEYWORDS="~x86" emerge -v xchat When this was done I tried to start xchat. Lo and behold, it worked great. Here's some additional information; $ type xchat-2 xchat-2 is /usr/bin/xchat-2 xchat 2.x have renamed their binaries to xchat-2 sinse it's a new major tree. Thank you for making sure that the developers get to know about the bugs that haven't left the testing tree. When a package leaves the testing tree, it've been tested and deemed as working. Not before that. There's a feature in bugzilla that's called the "search function". It's great to see if other users have filed bugs about what you're about to file a bug on. If you are curious about other discussions about this particular problems, I'd recommend the following URL's. They were found with the help of the above meantioned search function. http://bugs.gentoo.org/show_bug.cgi?id=19441 http://bugs.gentoo.org/show_bug.cgi?id=24305 http://bugs.gentoo.org/show_bug.cgi?id=26289 I wish you a pleasant day and I hope you'll file many more useful bugs.
I did some testing on this, this is what I found using `ebuild xchat-2.0.4.ebuild compile`: with +perl -tcltk +python +ssl -gtk +mmx -ipv6 +nls, there's no executable created in /var/tmp/portage/xchat-2.0.4/work/xchat-2.0.4/src/fe-text with +perl -tcltk +python +ssl +gtk +mmx -ipv6 +nls, there's an executable created in /var/tmp/portage/xchat-2.0.4/work/xchat-2.0.4/src/fe-gtk I bet it has something to do with this in the configure script: Building GTK+ Interface .... : no Building TEXT Interface .... : no I think `--enable-textfe` (it says it defaults to "no") has to be passed to configure, but I'm not sure how to do this with the econf part of the ebuild. If someone wants to take a peek at it, that would be great :)
Yeah, I reached the same conclusion. If you have -gtk in USE flag, gtk frontend is not going to be built. --- xchat-2.0.4.ebuild.ORIG 2003-08-06 11:11:15.000000000 +0900 +++ xchat-2.0.4.ebuild 2003-08-12 14:14:19.000000000 +0900 @@ -39,6 +39,7 @@ `use_enable ipv6` \ `use_enable nls` \ --program-suffix=-2 \ + --enable-textfe \ || die "Configure failed" MAKEOPTS="-j1" emake || die "Compile failed" After applying this patch text frontend will also be built by default (regardless of whether you have gtk/-gtk in USE flag), but I bet it is no longer "x"chat ;-p Rather, I suggest we disable gtk USE flag and make it DEPEND on gtk. Any comments?
I have "+gtk2 -gtk" in my use flags. I guess that's what's causing it. But isn't XChat2 a Gtk2 based application? mightymax root # ls -l /usr/bin/xchat ls: /usr/bin/xchat: No such file or directory mightymax root # emerge -s xchat Searching... [ Results for search key : xchat ] [ Applications found : 1 ] * net-irc/xchat Latest version available: 2.0.4 Latest version installed: 2.0.4 PS. Thanks for the sarcasm, Andreas.
Btw, I'm not a complete idiot, I did try and look for the 'XChat-2' binary previously... mightymax root # ls -l /usr/bin/xchat* ls: /usr/bin/xchat*: No such file or directory Like I said, the ebuild is b0rked and not producing a binary. Either that, or the gtk/gtk2 use flags are a little confused/confusing.
re: gtk/gtk2 USE flags this has been discussed many times in the forums. what you need to do is read the descriptions of the gtk/gtk2 USE variables in use.desc where you'll see: gtk - Adds support for x11-libs/gtk+ (The GIMP Toolkit) gtk2 - Use gtk+-2.0.0 over gtk+-1.2 in cases where a program supports both. Beware that gtk+-2 support can be bad. so as you can see, gtk2 is a _preference_ flag, which means that it is essentially meaningless without also using the gtk flag, you really want USE="gtk2 gtk". for those wanting gtk to be a dependency, what about the people that actually use textmode xchat2? we don't want to force them to install gtk+-2 just so that they can get their textmode irc client.
Hmm So what about those who do not _want_ to install gtk1 and only gtk2? Very careful selection of applications? I have to say that I think this should be more intuitive. If you have 'gtk2' then it should use gtk2, regarless of any -gtk. As a side note, I've had those USE flags for at least the last 4 months, probably longer. This has included multiple upgrades of XChat. I have never had this problem before.
I think this is a documentation issue... the Gtk2 description should be explicit about keeping 'gtk' so that idiots like me don't unset it.
Posted a bug: http://bugs.gentoo.org/show_bug.cgi?id=26467
This is one of the messiest bugs ever, please keep comments on topic, to the point, short and descriptive. It seems 2.0.4 now defaults to disabling the text interface, while before it was on by default. Either we turn it on by default, like it was, or go -as suggested- for gtk+ only and make that a non USE dep (would save us the other USE misuse bugs). Personally i prefer to go with the applications default and leave the disabled text fe as it is, making it accessible with a local USE flag for those who really want it. Any thoughts ?
foser, I'm slightly reluctant to recommend turning off the text frontend by default if the GTK+ 2.x toolkit is not installed. What about those who don't have GTK+ 2.x, but still want xchat? While I'm personally not one of them, I don't know how convenient an internal use-flag would be. At the minimum, perhaps the ebuild should check if gtk is a use-flag and if it isn't, print out something to the effect of "to turn on the text-frontend, you should '(insert appropriate instructions here)'". Or why not just see if gtk turned off, and if it's turned off, build the text-frontend? For those rare people that want both the GTK and text frontends, a message can be printed after installation on how to do it.
use flags are for optional extras, but with the name xchat i think people expect some GUI client. It's quite non intuitive to emerge xchat and find out you get a text frontend. Yes i assume the users of the text only frontend are a small group, i think most people are surprised to find a text frontend when they have just installed xchat.
You definately have a point. There are also better choices in text-based clients. I guess the question becomes is the maintainer (currently you, I believe) comfortable with making xchat depend on gtk+ 2.x? It would resolve a lot of the problems people have with the gtk/gtk2 USE flag (although, I think that issue needs to be addressed eventually). I personally wouldn't have a problem with that, but who knows about other people.
Why not compromise? If gtk OR gtk2 is set in the USE flags, build the gtk2 gui. If neither are set, build the ncurses GUI.
*** Bug 27040 has been marked as a duplicate of this bug. ***
there's no global USE flag for the text mode interface, so we need to decide whether to turn it on or off. personally, i find it hard to believe that people running X/Gnome etc dont have USE="gtk", and those people who have USE="-gtk gtk2" need to fix their flags (that's not an xchat being 'b0rked' problem). therefore, i think we should turn text mode interface on by default, and leave the rest to the USE flags as it is currently. acceptable ?
Seems good to me. (or control the textmode interface with the USE="ncurses" flag if it -really- is ncurses based.)
the ncurses flag sort of makes sense, most people would assume text modes gui's are ncurses, but that's not true for xchat. i'm going to go ahead and turn the text mode on by default, and leave the gtk flag situations as it always has been.
Sounds good. We should probably do something like this as well: pkg_postinst () { use gtk || use gtk2 && ewarn " You have USE=\"-gtk gtk2\". This will not give the result you expect" }
okay, fixed in portage now. thanks to all for comments on this one.
well, actually i like to do it the way i proposed, making gtk+ not optional at all and text based dependant on a local use flag. I know this isn't much according to guidelines, but in this case i think it's the best way to go.
Created attachment 16844 [details, diff] diff against xchat-2.0.4.ebuild okay, here's a patch implementing gtk on by default, but usage of the text interface allowed by local use flags. if this is ok, i'll get it in.
okay, got there in the end. this has been fixed in portage.
Let me just summarise this resolution, BUG: If I dont ask for gtk, I dont get a gtk frontend...whats up with that! SOLUTION: Make the people who have taken the time to learn portage jump through a few more hoops, and make those who havnt get what they probably wanted rather than what they asked for. Have i got this correct? If so, theres this annoying bug where if i use rm, it doesnt work, eg: $ rm --files-i-dont-want-anymore rm: unrecognised option `--files-i-dont-want-anymore' Try `rm --help' for more information. I cant be bothered to read the help or the man page..just make it do what i want, MmmKay? Please REOPEN.
have you actually tried merging the latest xchat in ~x86? you'll find that your concerns are non-existant with that version. i think sarcasm is very helpful in this case. (btw, we probably should remove gtk from IUSE in that ebuild.)
I'm looking at it now, instead of using the standard USE flags that apply, youve decided to make up a couple of new local ones that do the same, making those users who have spent the time to learn portage jump through more hoops, so that the users who havnt bothered have less chance of asking for something they dont really want. kewl. As one of the users who has taken the time to learn portage well and make it work how i like, I feel slightly patronized. im AMAZED you consider this a fix. Again, please REOPEN. Sorry if the sarcasm was offensive, i was trying to be funny, but i guess it didnt work :-)
the problem has always been that if you don't have +gtk in your USE flags then you didn't get the GUI. we've solved this by making the GUI default and a local use flag to switch the GUI off for people who want just the xchat-text interface. I consider this issue closed. Let me make this simple for you: The default behaviour now is "Install GTK interface, don't install ncurses interface." There. If you don't ask for GTK, you get GTK.
I agree with Jake. I'd rather see a warning (or perhaps a 'force me' option, like Mozilla had with Gtk2 some time ago) to notify the user that they won't get a GUI interface with -gtk in their USE flags. "The default behaviour now is "Install GTK interface, don't install ncurses interface." There. If you don't ask for GTK, you get GTK." That just doesn't make sense.
xchat tarball nowadays by default disables the text interface, we just go with the flow. The decision on this has been made, the devs who work on these things on a daily basis all agreed this was the best thing to do in this situation. I was never under the impression that everyone out there would agree. Discussing this over and over again is pointless.
"the problem has always been that if you don't have +gtk in your USE flags then you didn't get the GUI." How is this a problem? By your logic isnt the whole USE system flawed? If something has optional QT support, and I have USE="-qt" is it a bug that I dont get the QT support? Of course not, thats exactly what I requested. If you guys maintain this is a bug, then a whole lot of ebuilds, maybe portage itself, is going to have to be re-written. Foser: Im surprised about how unwilling to discuss this you are, have I hit a sore spot? Lots of packages disable features by default, or have optional features that wont be enabled without an --enable-something, therefore we should deprecate these features? Of course not, wed lose thousands of valuable features. I am CERTAIN You have made the wrong decision here. I like Spider's ideas, I like the way it used to work, im even not opossed to seperating it into net-irc/xchat with forced gtk support, and net-irc/xchat-text with no way of enabling gtk support, but the way you have chosen is WRONG.
Alistair: "I consider this issue closed. Let me make this simple for you: The default behaviour now is "Install GTK interface, don't install ncurses interface." There. If you don't ask for GTK, you get GTK." I would not be opposed to this behaviour, BUT THIS IS NOT WHAT YOU HAVE DONE. You have created two new Local USE flags, both of which have global USE flags that represent the exact same settings, and used them instead, patronizing users and assuming we dont know what we're asking for. I _DO_ know what im asking for, and appreciate not being told, is that simple enough for you? Let me try and spell this out for you: The default behaviour now is actually "Ignore the gtk USE flag, and listen to the local xchatnogtk and xchattext flags, WHICH DO EXACTLY THE SAME THING, but are TOTALLY NON-STANDARD and assume I dont know what im doing." As I am apparently unable to convince you that you have screwed up, and consider this "closed for discussion", and i am unable to REOPEN this bug, I will go ahead and open another one. Thankyou for making it simple for me, im clearly not as intelligent as you but im trying.
Actually, forget it, you can obvioulsy just go ahead and close that one as well. <sigh> I give up, you win. Thanks anyway, Simple minded Jake.
