Re: [gentoo-user] [SUSPECTED SPAM] ICEWM 1.4.x crashes after migration to profile 17.0

[Jalus Bilieyich]

Any logs, any other information you can give us? Help us help you.

On 01/26/2018 07:00 AM, Walter Dnes wrote:
>   So I just "upgraded" to profile 17.0 on on 32-bit Gentoo.  By sheer
> co-incidence "time emerge -e world" did 541 packages, and took...
> 
> real541m40.408s
> user607m12.164s
> sys 216m2.437s
> 
>   Anyhow, both the current x11-wm/icewm-1.4.2 and x11-wm/icewm-1.4.0
> crash back to the text console when I click the mouse pointer on the
> menu bar at the bottom.  I've dropped back to x11-wm/icewm-1.3.12, which
> works OK.  As a precaution, I've copied the ebuild into a local overlay.
> Nothing relevant on bugzilla.  Any ideas?
> 

[gentoo-user] Re: how to support a package going out of tree

[Nikos Chantziaras]

On 26/01/18 13:13, Raffaele Belardi wrote:

One of my son's favourite games (hedgewars) is going out of tree due to 
dependency on
deprecated QT4.

I already have a local overlay with a modified hedgewars ebuild which adds 
support for a
non-standard USE flag but I suppose this will not be sufficient to continue 
using/building
the game. Once the dependencies will go out of tree also there will be little 
chance to
rebuild the game if necessary, right?.


This game is being ported to Qt 5:

https://issues.hedgewars.org/show_bug.cgi?id=159

[gentoo-user] Re: Opinions on DVR/PVR backend?

[Grant Edwards]

On 2018-01-26, taii...@gmx.com  wrote:

> So you know the RPI is not open source as the RPI foundation doesn't
> provide firmware sources.

Yes, I'm aware of that.

[...]

> I would consider purchasing another device, of which legitimately
> open source low power ARM devices are a dime a dozen (vs the high
> performance realm where POWER's TALOS 2 or rare developer boards are
> the only choice)

The problem with purchasing less common but more "open" boards is that
it tends to be a lot more work to get things running on them.

I don't get particularly upset if a cheap, throw-away board like the
RP3 uses closed-source firmware -- all the underlying chips are
closed-source designs also.[*] As long as that firmware is part of a
driver that provides a standardized, open, documented API, I'm happy.

If the board/firmware/driver becomes unavailable, the open-source
applications and libraries can always be moved to a different
board/firmware/driver combination that implements that same
standardized API.

[*] Sure, you can run low-performance, high-cost "open-source HW"
designs by combining open-source VHDL cores and compiling a SOC
design into an FPGA, but the FPGAs and all the tools used to
compile the VHDL are closed source.

-- 
Grant Edwards   grant.b.edwardsYow! My NOSE is NUMB!
  at   
  gmail.com

Re: [gentoo-user] Opinions on DVR/PVR backend?

[taii...@gmx.com]

So you know the RPI is not open source as the RPI foundation doesn't 
provide firmware sources.
Proprietary firmware is required to boot and fully use the device as the 
RPI foundation only cares about open source when it is convenient to them.


I would consider purchasing another device, of which legitimately open 
source low power ARM devices are a dime a dozen (vs the high performance 
realm where POWER's TALOS 2 or rare developer boards are the only choice)

Re: [gentoo-user] how to support a package going out of tree

[Neil Bothwick]

On Fri, 26 Jan 2018 15:16:09 +0100, Raffaele Belardi wrote:

> >> I already have a local overlay with a modified hedgewars ebuild which
> >> adds support for a non-standard USE flag but I suppose this will not
> >> be sufficient to continue using/building the game. Once the
> >> dependencies will go out of tree also there will be little chance to
> >> rebuild the game if necessary, right?.  
> > 
> > Right, so copy the dependencies to your overlay too. Portage will warn
> > you when they are slated for removal.  
> 
> Which I suppose means the packages listed under RDEPEND and DEPEND in
> the ebuild. Ok, should be manageable.

Yes, but you don't need to copy everything, only those that are slated to
be treecleaned.


-- 
Neil Bothwick

WinErr 042: Virus error - A virus has been activated in a dos-box. The
virus, however, requires Windows. All tasks will automatically be closed
and the virus will be activated again.


pgpewsLBQAeWE.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: Opinions on DVR/PVR backend?

[Grant Edwards]

On 2018-01-26, Rich Freeman  wrote:
> On Fri, Jan 26, 2018 at 1:40 PM, Grant Edwards
> wrote:
>>
>> Pre-transocoding from MPEG-2 TS to MPEG-4 h264 would be nice.
>
> So, that is a downside with Plex.  I don't think you get that level of
> fine-grained control.

I think there's a hook to do stuff like that.  I've stumbled a cross a
few mentions of how to configure Plex DVR to run a "post-recording"
script.  I've also seen somebody mention that you can just run a cron
job to search for new .ts files and convert them to .mp4 (or
whatever).

One of the built-in Plex DVR features is to run comskip on a recording
when it is finished, and I'm sure with the right hammer that could be
bent so that it just does transcoding.

> You can't just pick the codec and features.  You pick the target
> platform (optimize for Android, or a generic Optimize for "Mobile",
> etc), and you pick the resolution/bitrate from a list of presets.
> I'm not sure how easy it is to tweak the actual settings, though
> maybe it is possible.
>
> On MythTV the transcoder isn't exactly super-flexible either.

When I got my first HDHomeRun ATSC tuner, I didn't have a MythTV
frontend capable of playing HD MPEG-2 transport streams, so I set up
post-recording transcoding to convert the files into an SD format that
my frontend's Hauppauge PVR-350 card could play back.  By the time you
got Myth to do something like that, you felt like you'd been in the
wars...

> On either platform you could also do your own transcoding.  With
> MythTV the regular player tends to be pretty picky about how files are
> encoded (at least it used to be).  Plex will play just about anything
> you throw at it.

That makes the "cron job" approach a decent option.

>> One open question is handling of closed-captioning in ATSC recordings.
>> Results with Plex seem to be mixed.
>
> I've found captions mostly work, but I don't use them much, and I
> haven't used the DVR functionality.  I couldn't tell you how well they
> work with ATSC.

I'll have to do some experiments.  I get the impression if you disable
transcoding, then it varies depending on the frontend.

-- 
Grant Edwards   grant.b.edwardsYow! They collapsed
  at   ... like nuns in the
  gmail.comstreet ... they had no
   teen appeal!

Re: [gentoo-user] Re: Opinions on DVR/PVR backend?

[Rich Freeman]

On Fri, Jan 26, 2018 at 1:40 PM, Grant Edwards
 wrote:
>
> Pre-transocoding from MPEG-2 TS to MPEG-4 h264 would be nice.
>

So, that is a downside with Plex.  I don't think you get that level of
fine-grained control.  You can't just pick the codec and features.
You pick the target platform (optimize for Android, or a generic
Optimize for "Mobile", etc), and you pick the resolution/bitrate from
a list of presets.  I'm not sure how easy it is to tweak the actual
settings, though maybe it is possible.

On MythTV the transcoder isn't exactly super-flexible either.

On either platform you could also do your own transcoding.  With
MythTV the regular player tends to be pretty picky about how files are
encoded (at least it used to be).  Plex will play just about anything
you throw at it.

>
> One open question is handling of closed-captioning in ATSC recordings.
> Results with Plex seem to be mixed.
>

I've found captions mostly work, but I don't use them much, and I
haven't used the DVR functionality.  I couldn't tell you how well they
work with ATSC.  The bigger pain is the way they're encoded into
shows.  If they're done right you can do things like have captions
only for foreign language phrases (works great in Star Trek
Discovery).  If the subtitles aren't set up the way it expects then
you find yourself constantly turning them on/off when the show
contains extensive use of foreign/fictional languages.  I suspect the
issue is more in my source material there, though I can't vouch for
how well it works over ATSC.  With ATSC I'd think that foreign
language subtitles would be more likely to be burned in anyway.

-- 
Rich

[gentoo-user] Re: Opinions on DVR/PVR backend?

[Grant Edwards]

On 2018-01-26, Rich Freeman  wrote:
> On Fri, Jan 26, 2018 at 12:50 PM, Grant Edwards
> wrote:
>>
>> I'm guessing that Android client support is going to be better with
>> Plex than with the others.
>>
>
> I know nothing of TVheadend.  MythTV on Android has always been kludgy
> at best, though I haven't touched it in two years.
>
> Plex on Android is a thing of beauty, especially with offline sync.

That's a big plus for Plex.

> For managing shows the web interface is still better than
> Android/Roku.

That's fine -- I prefer using a web browser for that sort of thing.
One of my complaints with MythTv and SageTv was that the web UIs for
backend configuration and recording scheduling were after-thought
add-on/plug-in kludges.  My current SageTv setup lacks a web ui
completely. :/

The config/scheduling UI for TvHeadend is purely web-based.

> That's the other thing - the Plex server/clients do a good job
> negotiating codecs, with the server doing all the transcoding.  You
> can pre-transcode files if you want to in order to reduce server load,
> such as if you have many Rokus you use at the same time.

Pre-transocoding from MPEG-2 TS to MPEG-4 h264 would be nice.

> When transcoding you do get a bit more latency, especially if you
> want to seek around a lot (no issue at all if you just hit play and
> watch the show) - you end up with bufferbloat on both the server and
> the client when you transcode.

When watching recorded TV shows, I do rely heavily on "jump forward
30s" and "jump back 5s" for manually skipping commercials.

> Still, it all just works, and it is no worse than Netflix/etc.  You
> can also configure quality rules for LAN vs WAN streaming, both on
> the clients and the server.

That's cool.

One open question is handling of closed-captioning in ATSC recordings.
Results with Plex seem to be mixed.

I think I'll try out Plex DVR this weekend and see how it works with
the Roku and Android frontends.

-- 
Grant Edwards   grant.b.edwardsYow! I'm definitely not
  at   in Omaha!
  gmail.com

Re: [gentoo-user] how to support a package going out of tree

[Walter Dnes]

On Fri, Jan 26, 2018 at 12:13:32PM +0100, Raffaele Belardi wrote
> One of my son's favourite games (hedgewars) is going out of tree
> due to dependency on deprecated QT4.
> 
> I already have a local overlay with a modified hedgewars ebuild
> which adds support for a non-standard USE flag but I suppose this
> will not be sufficient to continue using/building the game. Once the
> dependencies will go out of tree also there will be little chance
> to rebuild the game if necessary, right?.

  If you're looking at long-term, I would suggest installing a separate
machine or chroot or VM, which will not be updated.  If you keep it long
enough, the main system is going to get to the point where either
hedgewars doesn't work or your regular apps don't work.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: Opinions on DVR/PVR backend?

[Rich Freeman]

On Fri, Jan 26, 2018 at 12:50 PM, Grant Edwards
 wrote:
>
> I'm guessing that Android client support is going to be better with
> Plex than with the others.
>

I know nothing of TVheadend.  MythTV on Android has always been kludgy
at best, though I haven't touched it in two years.

Plex on Android is a thing of beauty, especially with offline sync.
Progress is synced to the server and across all clients, and you can
give it a quality level and it will keep #n unwatched episodes synced
to the Android device, which get auto-updated anytime you're on wifi.
I've used it on trips where the hotel wifi is terrible and it works
great.  Maybe it takes all night while I'm asleep to sync new episodes
with heaven knows how many retries, but it still syncs, and then they
play just fine the next day or on the flight home.

For managing shows the web interface is still better than
Android/Roku.  Often I'll set up the sync rules from the web - and
then the android device will just magically do what it should
(eventually).  If I'm in a hurry I can fire up the android app and
tell it to sync right away, and it picks up the new rules.  The server
picks up the rules immediately and will have the shows transcoded
already, so it is just a matter of file transfer.

That's the other thing - the Plex server/clients do a good job
negotiating codecs, with the server doing all the transcoding.  You
can pre-transcode files if you want to in order to reduce server load,
such as if you have many Rokus you use at the same time.  When
transcoding you do get a bit more latency, especially if you want to
seek around a lot (no issue at all if you just hit play and watch the
show) - you end up with bufferbloat on both the server and the client
when you transcode.  Still, it all just works, and it is no worse than
Netflix/etc.  You can also configure quality rules for LAN vs WAN
streaming, both on the clients and the server.


-- 
Rich

[gentoo-user] Re: Opinions on DVR/PVR backend?

[Grant Edwards]

On 2018-01-26, Rich Freeman  wrote:
> On Fri, Jan 26, 2018 at 11:29 AM, Grant Edwards  
> wrote:
>
>> The main backend options seem to be MythTV, Plex, and TVHeadend.
>
> You seem to understand the pros/cons fairly well.
>
> I moved from MythTV to Plex about two years ago, but as a result of
> moving from DVR to discrete media files, which MythTV was a poor fit
> for.  The DVR service is new for Plex and I've never tried it, though
> it would be free for me to use (I have a lifetime Plex pass).  I don't
> have any tuners set up at all right now and no easy ability to watch
> LiveTV of any kind.

Live TV is not a priority at all and would be the first thing I would
give up in order to gain in other areas.

> One pain I always had with MythTV was any time where I wanted to run
> different distros on front-ends vs servers, because the protocol
> changes from time to time and upstream does not support anything
> other than all clients and servers running on the exact same build.

Yep.  You can make it work, but it takes effort.

I was never able to find an option for an acceptably small and silent
Myth fontend.  The last time I was looking into that, the Raspberry Pi
3B seemed like a decent option, but reports indicated it still took a
lot of futzing to get it work.

> The thing I like about Plex is that upstream basically tries to keep
> everything painless and "just working."

That's always good, and I'm more than happy to pay cash money for
that.

I'm guessing that Android client support is going to be better with
Plex than with the others.

> [...]
>
> Now, MythTV in general is going to be more flexible with DVR
> capabilities, since it does have a database you can poke around in,
> and more of an API/etc.  And of course it is open source so you really
> can patch whatever you want into it.

After reading through the Plex DVR wiki pages, I was pleasantly
surprised.  It had some features that MythTV has but TvHeadend and/or
SageTv lacks:

  * Minutes-before and minutes-after settings for a recording to
adjust for local TV station management decisions to skew
start-stop times.  SaveTV lacked this, and it was annoying. [The
optimal solution is repeated beatings for the people who decide to
do that.]

  * How many and which recordings to keep for each series.  [SageTv
does have this.]

> In a pure DVR world I might still be running MythTV.  I'd certainly
> evaluate Plex though.  I'm not sure how easy it is to evaluate Plex
> DVR without paying something though.

One notable feature that (I think) TvHeadend lacks is the ability to
only record series episodes that haven't been previously recorded and
watched.  Both MythTv and SageTv can do that, but I'm not sure about
Plex.

I'm still not sure how storage space management works with Plex's DVR.
AFAICT, TvHeadend doesn't provide any space management at all.

-- 
Grant Edwards   grant.b.edwardsYow! Where's th' DAFFY
  at   DUCK EXHIBIT??
  gmail.com

Re: [gentoo-user] Opinions on DVR/PVR backend?

[Rich Freeman]

On Fri, Jan 26, 2018 at 11:29 AM, Grant Edwards
 wrote:
>
> The main backend options seem to be MythTV, Plex, and TVHeadend.
>

You seem to understand the pros/cons fairly well.

I moved from MythTV to Plex about two years ago, but as a result of
moving from DVR to discrete media files, which MythTV was a poor fit
for.  The DVR service is new for Plex and I've never tried it, though
it would be free for me to use (I have a lifetime Plex pass).  I don't
have any tuners set up at all right now and no easy ability to watch
LiveTV of any kind.

One pain I always had with MythTV was any time where I wanted to run
different distros on front-ends vs servers, because the protocol
changes from time to time and upstream does not support anything other
than all clients and servers running on the exact same build.  (In
reality it is more flexible than that, but protocol version changes
are not generally announced or managed because upstream really does
want everything on one build.)  So, running a Gentoo server and a
MythBuntu front-end is a constant source of pain with the versions
never being in-sync.

The thing I like about Plex is that upstream basically tries to keep
everything painless and "just working."  They do QA testing on all
their platforms/etc, and I've never had a situation so far where my
server wouldn't talk to one of my clients.  I use a Roku client, an
android client, my android client casting to a chromecast, and the web
client.  I've messed with the windows desktop client as well.  They've
all always "just worked" with the auto-updates on all the various
platforms, and I just update my server about once a month (I think I
have that running in an Arch container on my main Gentoo box). Plex
also seems to handle media in whatever format I already have it in
fairly flexibly - I rarely have to rename files or anything like that.

Now, MythTV in general is going to be more flexible with DVR
capabilities, since it does have a database you can poke around in,
and more of an API/etc.  And of course it is open source so you really
can patch whatever you want into it.

In a pure DVR world I might still be running MythTV.  I'd certainly
evaluate Plex though.  I'm not sure how easy it is to evaluate Plex
DVR without paying something though.

-- 
Rich

[gentoo-user] Opinions on DVR/PVR backend?

[Grant Edwards]

I think it's about time to replace my SageTV DVR/PVR system, so I'm
looking for opinions and recommendations for a DVR backend to run on a
Gentoo desktop machine.

Some Background...

For many years, I ran a dedicated, combined frontend/backend MythTV
system (usually a Debian install).  Then I switched to a mac-mini
frontend booting a dedicated MythTV frontend distro from a USB flash
drive with the MythTV backend running on my general-purposed Gentoo
box.  I was never completely happy with the mac mini frontend, but it
was small and quiet and mostly worked.

After that (about 8 years ago) I switched to using the SageTV backend
on that same Gentoo box with SageTV brand custom frontend set-top
boxes.

About a year later, SageTV got bought by Google and mostly shut down.
Software continued to be updated for a few years, and EPG data was
kept flowing.  The software has since been open-sourced, but the
backend development has slowed and development/support for the set-top
boxes ended (there are some nagging set-top box problems that are
never going to get fixed). The "lifetime" free EPG data spigot for
SageTV got turned off last year.

SageTV is a large Java app with a bunch of custom libraries.  For now,
the tarball of JAR files and binaries works, but it's not a long-term
solution.  I tried building the SageTV backend under Gentoo and was
unsuccessful in an effort to produce an ebuild for it.  The build
system is a completely broken mess of shell-scripts and makes all
sorts of assumptions about development host library versions (it
requires a lot of ancient library versions).

And now...

I'm looking for opinions on a DVR backend to run on a desktop Gentoo
box.  Input is OTA ATSC via an Ethernet-connected tuner (SiliconDust
HDHomeRun).  The ideal set-top frontend would be Roku. I'd also really
like a good Android frontend.  My next choice for a set-top frontend
would probably be Kodi on Raspberry Pi 3B or Vero 4K HW.  I'm going to
pick up a RPi3 this weekend and start playing with Kodi (OSMC or
LibreELEC).

The main backend options seem to be MythTV, Plex, and TVHeadend.

 MythTV

Pros: Good feature set
  Open-source

Cons: It's a giant bloated mess that pulls in all sorts of Qt stuff
  Fragile frontend API/protocol that gets broken regularly
  Poor music player (the last time I tried it)
  Poor frontend support for Android.

 Plex

Pros: Roku frontend
  Good integration of existing media files
  Good support for Android

Cons: DVR support is new
  Closed source
  Commercial service

 TVHeadend

Pros: Lightweight
  Minimal dependencies
  Open-source
  Android frontend (I think)

Cons: Weak recording management
  Poor integration of existing media

There are minimal subscription costs for all three ($40/year for Plex,
$25/year for the others), so that's a push.

-- 
Grant Edwards   grant.b.edwardsYow! Youth of today!
  at   Join me in a mass rally
  gmail.comfor traditional mental
   attitudes!

Re: [SUSPECTED SPAM] Re: [gentoo-user] Questions about Pale Moon

[Peter Humphrey]

On Friday, 26 January 2018 13:20:04 GMT Walter Dnes wrote:
> On Wed, Jan 24, 2018 at 11:43:31AM +, Peter Humphrey wrote
> 
> > This is with gcc 4.9.4, and I get the same with gcc 6.4.0. I've only
> > just noticed that about -fPIC; haven't all those problems been fixed
> > by now?
> 
>   This may or may not be relavant.  I build Pale Moon manually for my
> home machines, using the Mozilla Firefox process.  64-bit builds worked
> fine with GCC-6.4.0 on profile 13.0.  Anything built with GCC-6.x under
> profile 17.0 segfaults in 10-15 seconds after launching Pale Moon.  A
> custom-built GCC-5.4.0 builds a stable Pale Moon.

I haven't yet managed to compile 27.7.1 at all with either GCC 6.4.0 or 
4.9.4, using the palemoon overlay via layman, on profile default/linux/
amd64/17.0/desktop/plasma. I get the loader errors I quoted on Wednesday.

I wonder whether I should try the 17.1 profile...

>   I'm currently doing a test build with GCC-6.4.0 on my 32-bit desktop,
> having just finished the migration to 17.0.  Current ICEWM 1.4.2 (and
> 1.4.0) crashes out of X to a text console when I click on the menu bar
> at the bottom.  I've dropped back to 1.3.12-r1 ...and copied the ebuild
> over to a local overlay.  I'm not liking profile 17.0 far.

-- 
Regards,
Peter.

Re: [gentoo-user] UEFI-fails to boot

[Corbin Bird]

On 01/26/2018 04:00 AM, Dan Johansson wrote:
> On 26.01.2018 02:25, Johnson Steward wrote:
>> Well, check if you have CONFIG_FB_EFI enabled in your config.
> Good idea, but sadly, nope, that was not it.
>
> KR
.
Questions that may sound strange ...
What version of Windows does your motherboard support?
Do you use any add on ( PCI / PCIe ) cards that do not support UEFI and
load a BIOS?
Have you configured a specific type of video card in the kernel?
.
The reasons why I ask this :
The UEFI driver for video changes type & version between Win 7 & Win 8.
An LSI 9211-4i ( Raid Controller / SAS  ) loads only a BIOS ... and
interferes with the Win 8 UEFI Video driver.
( It interferes enough with the Win 8 UEFI Video driver, that Win 7 will
work with it. )
It also means no console video until init is ( almost ) completed.
That is when the chosen specific video card frame buffer takes over.
.
Corbin

Re: [gentoo-user] how to support a package going out of tree

[Rich Freeman]

On Fri, Jan 26, 2018 at 9:01 AM, Neil Bothwick  wrote:
> On Fri, 26 Jan 2018 12:13:32 +0100, Raffaele Belardi wrote:
>
>> One of my son's favourite games (hedgewars) is going out of tree due to
>> dependency on deprecated QT4.
>>
>> I already have a local overlay with a modified hedgewars ebuild which
>> adds support for a non-standard USE flag but I suppose this will not be
>> sufficient to continue using/building the game. Once the dependencies
>> will go out of tree also there will be little chance to rebuild the
>> game if necessary, right?.
>
> Right, so copy the dependencies to your overlay too. Portage will warn
> you when they are slated for removal.
>

Or use an overlay that already contains them.  I haven't paid much
attention to whether somebody is maintaining a qt4 sunset overlay.

Keep in mind that qt4 is deprecated for a reason.  This will
definitely be a steadily uphill battle, and you might run into issues
you'll have to deal with yourself.

In addition to the ebuilds you might need to check to see if they use
any eclasses (which seems likely for anything like qt).  Also check
for any Gentoo-hosted patches that might go away - you'd need to host
them yourself and edit SRC_URI, or just stick them in files/.  You
should probably also save a copy of all the distfiles somewhere in
case a URL dies, as Gentoo won't be mirroring them for you.  If
upstream completely stops distributing a file you might be stuck if
you didn't save a copy.

-- 
Rich

Re: [gentoo-user] how to support a package going out of tree

[Raffaele Belardi]

Neil Bothwick wrote:
> On Fri, 26 Jan 2018 12:13:32 +0100, Raffaele Belardi wrote:
> 
>> One of my son's favourite games (hedgewars) is going out of tree due to
>> dependency on deprecated QT4.
>>
>> I already have a local overlay with a modified hedgewars ebuild which
>> adds support for a non-standard USE flag but I suppose this will not be
>> sufficient to continue using/building the game. Once the dependencies
>> will go out of tree also there will be little chance to rebuild the
>> game if necessary, right?.
> 
> Right, so copy the dependencies to your overlay too. Portage will warn
> you when they are slated for removal.

Which I suppose means the packages listed under RDEPEND and DEPEND in the 
ebuild. Ok,
should be manageable.

thanks,

raffaele

Re: [gentoo-user] how to support a package going out of tree

[Neil Bothwick]

On Fri, 26 Jan 2018 12:13:32 +0100, Raffaele Belardi wrote:

> One of my son's favourite games (hedgewars) is going out of tree due to
> dependency on deprecated QT4.
> 
> I already have a local overlay with a modified hedgewars ebuild which
> adds support for a non-standard USE flag but I suppose this will not be
> sufficient to continue using/building the game. Once the dependencies
> will go out of tree also there will be little chance to rebuild the
> game if necessary, right?.

Right, so copy the dependencies to your overlay too. Portage will warn
you when they are slated for removal.


-- 
Neil Bothwick

If you can smile when things go wrong, you have someone in mind to blame.


pgpMgzBdO0vqb.pgp
Description: OpenPGP digital signature

[SUSPECTED SPAM] Re: [gentoo-user] Questions about Pale Moon

[Walter Dnes]

On Wed, Jan 24, 2018 at 11:43:31AM +, Peter Humphrey wrote
> 
> This is with gcc 4.9.4, and I get the same with gcc 6.4.0. I've only
> just noticed that about -fPIC; haven't all those problems been fixed
> by now?

  This may or may not be relavant.  I build Pale Moon manually for my
home machines, using the Mozilla Firefox process.  64-bit builds worked
fine with GCC-6.4.0 on profile 13.0.  Anything built with GCC-6.x under
profile 17.0 segfaults in 10-15 seconds after launching Pale Moon.  A
custom-built GCC-5.4.0 builds a stable Pale Moon.

  I'm currently doing a test build with GCC-6.4.0 on my 32-bit desktop,
having just finished the migration to 17.0.  Current ICEWM 1.4.2 (and
1.4.0) crashes out of X to a text console when I click on the menu bar
at the bottom.  I've dropped back to 1.3.12-r1 ...and copied the ebuild
over to a local overlay.  I'm not liking profile 17.0 far.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

[gentoo-user] [SUSPECTED SPAM] ICEWM 1.4.x crashes after migration to profile 17.0

[Walter Dnes]

  So I just "upgraded" to profile 17.0 on on 32-bit Gentoo.  By sheer
co-incidence "time emerge -e world" did 541 packages, and took...

real541m40.408s
user607m12.164s
sys 216m2.437s

  Anyhow, both the current x11-wm/icewm-1.4.2 and x11-wm/icewm-1.4.0
crash back to the text console when I click the mouse pointer on the
menu bar at the bottom.  I've dropped back to x11-wm/icewm-1.3.12, which
works OK.  As a precaution, I've copied the ebuild into a local overlay.
Nothing relevant on bugzilla.  Any ideas?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Questions about Pale Moon

[Peter Humphrey]

On Thursday, 25 January 2018 16:23:56 GMT Mart Raudsepp wrote:
> On Wed, 2018-01-24 at 16:30 +, Peter Humphrey wrote:
> > On Tuesday, 23 January 2018 12:08:12 GMT Arve Barsnes wrote:
> > > Maybe check command line output?
> > 
> > I get eight of these: "undefined symbol: UCNV_TO_U_CALLBACK_STOP".
> > The full list is attached.
> > 
> > (pale moon:2395): Gtk-WARNING **: Error loading theme icon 'go-
> > previous' for stock: Unable to load image-loading module:
> > /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so:
> > /usr/lib64/libxml2.so.2: undefined symbol: UCNV_TO_U_CALLBACK_STOP
> 
> Your libxml2 appears broken after some ICU update and no automatic
> rebuild of libxml2 or something (maybe something failed in the rebuilds
> earlier in the queue from what portage figured has to get rebuilt after
> icu upgrade). Rebuild libxml2 and that issue probably goes away.

I don't think that's it:

$ genlop libxml2
 * dev-libs/libxml2
[...]
 Wed Dec 13 12:07:18 2017 >>> dev-libs/libxml2-2.9.4-r3
 Sun Dec 17 10:39:28 2017 >>> dev-libs/libxml2-2.9.6
 Thu Jan  4 11:21:42 2018 >>> dev-libs/libxml2-2.9.6
 Thu Jan 18 10:41:33 2018 >>> dev-libs/libxml2-2.9.7
 Tue Jan 23 15:11:28 2018 >>> dev-libs/libxml2-2.9.7

To confirm that, I've just repeated the exercise after remerging libxml2 
again, and I got the same result.

This is the official build, the one that Walter pointed me to.

-- 
Regards,
Peter.

[gentoo-user] how to support a package going out of tree

[Raffaele Belardi]

One of my son's favourite games (hedgewars) is going out of tree due to 
dependency on
deprecated QT4.

I already have a local overlay with a modified hedgewars ebuild which adds 
support for a
non-standard USE flag but I suppose this will not be sufficient to continue 
using/building
the game. Once the dependencies will go out of tree also there will be little 
chance to
rebuild the game if necessary, right?.

thanks,

raffaele

Re: [gentoo-user] UEFI-fails to boot

[Dan Johansson]

On 26.01.2018 02:25, Johnson Steward wrote:
> Well, check if you have CONFIG_FB_EFI enabled in your config.

Good idea, but sadly, nope, that was not it.

KR
-- 
Dan Johansson
***
This message is printed on 100% recycled electrons!
***

Re: [gentoo-user] UEFI-fails to boot

[Dan Johansson]

On 25.01.2018 20:21, Neil Bothwick wrote:
> On Thu, 25 Jan 2018 17:28:49 +0100, Dan Johansson wrote:
> 
>> The one thing that is not working is that I do not see ANY boot-messages
>> on the console (it just says Loading Linux  and Loading initial ramdisk
>> ...), and I do not get a login-prompt and can not switch VT.
>>
>> But as I said, I can login with ssh and can now continue with the setup,
>> the "Console" has to wait.
> 
> Does /dev/console exist on your root filesystem?

Yes.

# mount --bind / /mnt/x
# ll /mnt/x/dev/console
crw--- 1 root root 5, 1 Jan 17 03:14 /mnt/x/dev/console


-- 
Dan Johansson
***
This message is printed on 100% recycled electrons!
***