Re: [e-users] e17 turns off my LCD
When I feel like enjoying compiles I just pick a 10 kg popcorn carn, 50 cold beers and fire up emerge chromium on my tv. Better done on sunday morning. Jokes aside, I don't want to blame anyone, but as Alan McKinnon said above, that is supposed to be the responsibility of the one that makes the ebuild. Otherwise, I'd just use LFS and keep the pieces myself. Anyway, I repeat this came from an unofficial ebuild, though on the other side the official one didn't even work (portage has only e17, which turns my screen off). So I am not sure what to do about this, I guess the most sane way of fixing this in Gentoo would be to first add e18, then you have to wait for it to be stabilized (one month minimum), in the way, make the necessary changes and, either remove the xcb USE flag or mask it hard so that only those really interested and capable of dealing with that can use it. At least until (if) the xcb support stabilizes. I have to investigate the status of this, though. Also, I will try to contact whomever made the enlightenment unofficial overlay, and let him or her know about this thread. 2014-02-12 8:26 GMT+01:00 David Seikel onef...@gmail.com: On Wed, 12 Feb 2014 08:49:16 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Wed, 12 Feb 2014 02:46:45 +1000 David Seikel onef...@gmail.com said: On Wed, 12 Feb 2014 00:41:40 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Tue, 11 Feb 2014 15:27:43 +0200 Alan McKinnon alan.mckin...@gmail.com said: On 11/02/2014 10:28, Mick wrote: On Monday 10 Feb 2014 13:27:00 Jesús J. Guerrero Botella wrote: Well, I don't have any problem with using whatever is suggested upstream. The thing with USE flags is that they can be set globally, and when an ebuild has an USE flag to enable or disable a given feature you are supposed to be able to use that, that is, unless the ebuild has an ewarn about it or the USE is masked. I try to make use of the documentation when available, however this time I neglected to do so, mostly because a hard lock is not something that's usually documented and partly because, to start with, I didn't even know where to start looking. I'm going from memory here but recall that when I tried to emerge efl portage warned me about having xcb set. So I unset it and off it went completing the emerge. From efl-1.8.5.ebuild (in part): REQUIRED_USE= X? ( !xcb ) USE=X xcb is enabled by default in the desktop profile so you will get that warning and are forced to disable one of them when emerging efl for the first time. For other profiles USE=xcb is usually off, so enabling it produces the same error message. Most folks would think long and hard before setting USE=-X. Perhaps the enlightenment herd can add an elog to clarify that not only must one choose between X|xcb, but that xcb is completely unsupported upstream so YMMV, break, both halves, keep + kittens = eaten efl 1.9 has a big paragraph that configure blurts out about this... and it sleeps for 10sec do make you notice the pause and display... Which might be entirely useless if it's an automated build that logs the output instead of showing it to the user. Though I suspect a 10 second pause during the build of a complex system wont be noticed. Hell, I automate my EFL builds AND don't watch them. B-) we could do shutdown -h now. that'd get attention. :) Nah, wont do anything if it's not being built as root. Just play I'm a loser (Beatles or Beck, your choice) at full volume. B-) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users -- Jesús Guerrero Botella -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ enlightenment-users mailing list
Re: [e-users] e17 turns off my LCD
On Wed, Feb 12, 2014 at 08:53:37AM +0900, Carsten Haitzler wrote: On Tue, 11 Feb 2014 22:45:30 +0200 Alan McKinnon alan.mckin...@gmail.com said: On 11/02/2014 17:41, Carsten Haitzler (The Rasterman) wrote: On Tue, 11 Feb 2014 15:27:43 +0200 Alan McKinnon alan.mckin...@gmail.com said: On 11/02/2014 10:28, Mick wrote: On Monday 10 Feb 2014 13:27:00 Jesús J. Guerrero Botella wrote: Well, I don't have any problem with using whatever is suggested upstream. The thing with USE flags is that they can be set globally, and when an ebuild has an USE flag to enable or disable a given feature you are supposed to be able to use that, that is, unless the ebuild has an ewarn about it or the USE is masked. I try to make use of the documentation when available, however this time I neglected to do so, mostly because a hard lock is not something that's usually documented and partly because, to start with, I didn't even know where to start looking. I'm going from memory here but recall that when I tried to emerge efl portage warned me about having xcb set. So I unset it and off it went completing the emerge. From efl-1.8.5.ebuild (in part): REQUIRED_USE= X? ( !xcb ) USE=X xcb is enabled by default in the desktop profile so you will get that warning and are forced to disable one of them when emerging efl for the first time. For other profiles USE=xcb is usually off, so enabling it produces the same error message. Most folks would think long and hard before setting USE=-X. Perhaps the enlightenment herd can add an elog to clarify that not only must one choose between X|xcb, but that xcb is completely unsupported upstream so YMMV, break, both halves, keep + kittens = eaten efl 1.9 has a big paragraph that configure blurts out about this... and it sleeps for 10sec do make you notice the pause and display... Your average Gentoo user won't see that message - we tend to set the build up then walk away and let the build framework do it's thing. The packager ought to see it as by rights they are supposed to eyeball stuff before declaring it fit for consumption. Can I make a suggestion? configurable options for efl and e tend to fall into two camps - solid, stable, supported stuff; and everything else that's there for who knows what reason. Xcb looks and feels like a moribund option that went in when someone worked on it, and is sorta still there. Why not just rip all that other stuff out of main? As you say, no-one important runs it or tests it. Leave it in a testing/dev branch by all means so someone up for the job can check it out and work on it. Reason being, when I see this: $ ./configure --help=short ... --with-x11=xlib|xcb|none X11 method to use: xlib, xcb or none then I expect all offered options to work as intended and be release quality. If I want to play with badass unsupported magic, I don't expect you to ship it, I do expect to do the heavy lifting myself of fetching diffs and patching first. Happily, it looks like a lot of the strange option that were in efl-17 are now gone already, so thank you for that. and that then leads to insane/major bitrot once it goes into a branch. xcb works for 99% of stuff... until you start bringing opengl into things. then it gets tricky. how about gentoo stop offering every --enable/disable feature on the planet just because it can? that's my suggestion. i think i'll ADD another option you have to pass and make configure fail without it. that'll break the ebuilds and i'm super happy about that. :) Because I build embedded gentoo systems sometimes and have actually used xcb as described above. I agree that xcb should be disabled by default with a very strongly worded warning. Warnings are grouped and displayed at the end of a build so you don't have to sit there watching your screen. I will go one step further and submit a patch to implement both of these steps tonight. Austin Morgan -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e17 turns off my LCD
On Wed, 12 Feb 2014 08:42:13 -0600 Austin Morgan admor...@morgancomputers.net wrote: On Wed, Feb 12, 2014 at 08:53:37AM +0900, Carsten Haitzler wrote: On Tue, 11 Feb 2014 22:45:30 +0200 Alan McKinnon alan.mckin...@gmail.com said: On 11/02/2014 17:41, Carsten Haitzler (The Rasterman) wrote: On Tue, 11 Feb 2014 15:27:43 +0200 Alan McKinnon alan.mckin...@gmail.com said: On 11/02/2014 10:28, Mick wrote: On Monday 10 Feb 2014 13:27:00 Jesús J. Guerrero Botella wrote: Well, I don't have any problem with using whatever is suggested upstream. The thing with USE flags is that they can be set globally, and when an ebuild has an USE flag to enable or disable a given feature you are supposed to be able to use that, that is, unless the ebuild has an ewarn about it or the USE is masked. I try to make use of the documentation when available, however this time I neglected to do so, mostly because a hard lock is not something that's usually documented and partly because, to start with, I didn't even know where to start looking. I'm going from memory here but recall that when I tried to emerge efl portage warned me about having xcb set. So I unset it and off it went completing the emerge. From efl-1.8.5.ebuild (in part): REQUIRED_USE= X? ( !xcb ) USE=X xcb is enabled by default in the desktop profile so you will get that warning and are forced to disable one of them when emerging efl for the first time. For other profiles USE=xcb is usually off, so enabling it produces the same error message. Most folks would think long and hard before setting USE=-X. Perhaps the enlightenment herd can add an elog to clarify that not only must one choose between X|xcb, but that xcb is completely unsupported upstream so YMMV, break, both halves, keep + kittens = eaten efl 1.9 has a big paragraph that configure blurts out about this... and it sleeps for 10sec do make you notice the pause and display... Your average Gentoo user won't see that message - we tend to set the build up then walk away and let the build framework do it's thing. The packager ought to see it as by rights they are supposed to eyeball stuff before declaring it fit for consumption. Can I make a suggestion? configurable options for efl and e tend to fall into two camps - solid, stable, supported stuff; and everything else that's there for who knows what reason. Xcb looks and feels like a moribund option that went in when someone worked on it, and is sorta still there. Why not just rip all that other stuff out of main? As you say, no-one important runs it or tests it. Leave it in a testing/dev branch by all means so someone up for the job can check it out and work on it. Reason being, when I see this: $ ./configure --help=short ... --with-x11=xlib|xcb|none X11 method to use: xlib, xcb or none then I expect all offered options to work as intended and be release quality. If I want to play with badass unsupported magic, I don't expect you to ship it, I do expect to do the heavy lifting myself of fetching diffs and patching first. Happily, it looks like a lot of the strange option that were in efl-17 are now gone already, so thank you for that. and that then leads to insane/major bitrot once it goes into a branch. xcb works for 99% of stuff... until you start bringing opengl into things. then it gets tricky. how about gentoo stop offering every --enable/disable feature on the planet just because it can? that's my suggestion. i think i'll ADD another option you have to pass and make configure fail without it. that'll break the ebuilds and i'm super happy about that. :) Because I build embedded gentoo systems sometimes and have actually used xcb as described above. I agree that xcb should be disabled by default with a very strongly worded warning. Warnings are grouped and displayed at the end of a build so you don't have to sit there watching your screen. I will go one step further and submit a patch to implement both of these steps tonight. Have a look, I think Raster did that already. B-) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net
Re: [e-users] e17 turns off my LCD
On Wed, 12 Feb 2014 08:42:13 -0600 Austin Morgan admor...@morgancomputers.net said: On Wed, Feb 12, 2014 at 08:53:37AM +0900, Carsten Haitzler wrote: On Tue, 11 Feb 2014 22:45:30 +0200 Alan McKinnon alan.mckin...@gmail.com said: On 11/02/2014 17:41, Carsten Haitzler (The Rasterman) wrote: On Tue, 11 Feb 2014 15:27:43 +0200 Alan McKinnon alan.mckin...@gmail.com said: On 11/02/2014 10:28, Mick wrote: On Monday 10 Feb 2014 13:27:00 Jesús J. Guerrero Botella wrote: Well, I don't have any problem with using whatever is suggested upstream. The thing with USE flags is that they can be set globally, and when an ebuild has an USE flag to enable or disable a given feature you are supposed to be able to use that, that is, unless the ebuild has an ewarn about it or the USE is masked. I try to make use of the documentation when available, however this time I neglected to do so, mostly because a hard lock is not something that's usually documented and partly because, to start with, I didn't even know where to start looking. I'm going from memory here but recall that when I tried to emerge efl portage warned me about having xcb set. So I unset it and off it went completing the emerge. From efl-1.8.5.ebuild (in part): REQUIRED_USE= X? ( !xcb ) USE=X xcb is enabled by default in the desktop profile so you will get that warning and are forced to disable one of them when emerging efl for the first time. For other profiles USE=xcb is usually off, so enabling it produces the same error message. Most folks would think long and hard before setting USE=-X. Perhaps the enlightenment herd can add an elog to clarify that not only must one choose between X|xcb, but that xcb is completely unsupported upstream so YMMV, break, both halves, keep + kittens = eaten efl 1.9 has a big paragraph that configure blurts out about this... and it sleeps for 10sec do make you notice the pause and display... Your average Gentoo user won't see that message - we tend to set the build up then walk away and let the build framework do it's thing. The packager ought to see it as by rights they are supposed to eyeball stuff before declaring it fit for consumption. Can I make a suggestion? configurable options for efl and e tend to fall into two camps - solid, stable, supported stuff; and everything else that's there for who knows what reason. Xcb looks and feels like a moribund option that went in when someone worked on it, and is sorta still there. Why not just rip all that other stuff out of main? As you say, no-one important runs it or tests it. Leave it in a testing/dev branch by all means so someone up for the job can check it out and work on it. Reason being, when I see this: $ ./configure --help=short ... --with-x11=xlib|xcb|none X11 method to use: xlib, xcb or none then I expect all offered options to work as intended and be release quality. If I want to play with badass unsupported magic, I don't expect you to ship it, I do expect to do the heavy lifting myself of fetching diffs and patching first. Happily, it looks like a lot of the strange option that were in efl-17 are now gone already, so thank you for that. and that then leads to insane/major bitrot once it goes into a branch. xcb works for 99% of stuff... until you start bringing opengl into things. then it gets tricky. how about gentoo stop offering every --enable/disable feature on the planet just because it can? that's my suggestion. i think i'll ADD another option you have to pass and make configure fail without it. that'll break the ebuilds and i'm super happy about that. :) Because I build embedded gentoo systems sometimes and have actually used xcb as described above. I agree that xcb should be disabled by default with a very strongly worded warning. Warnings are grouped and displayed at the end of a build so you don't have to sit there watching your screen. I will go one step further and submit a patch to implement both of these steps tonight. i did it already. see configure.ac - any option we deem as not healthy i've added a warning blob to at the end summarising everything configure doesn't like, and it fails... unless you then ALSO add: --enable-i-really-know-what-i-am-doing-and-that-this-will-probably-break-things-and-i-will-fix-them-myself-and-send-patches-aaa it still has a 10 second pause here even if you do provide this option. so you CAN configure things the way you want, but i've added a loud warning siren with an extra safety lock you ALSO have to unlock. that aaa at the end we'll keep swizzling about each efl release to ensure that upgrades that go through a build system that enables things that are dangerous break and need to be
