Re: [gentoo-user] gambas-3.10.0 installed from jorgicio overlay can't run

[R0b0t1]

On Sat, Dec 9, 2017 at 1:04 AM, Kruglov Sergey  wrote:
> Hi!
>
> I installed the 'gambas-3.10.0' from the overlay 'jorgicio'
> (http://data.gpo.zugaina.org/jorgicio/dev-lang/gambas/)
> And I can't run it. In /usr/bin/gambas3 there is a link to 'gambas3.gambas'
> and 'gambas3.gambas' not found.
> Maybe somebody already fix it?
>

I found https://forums.gentoo.org/viewtopic-t-1046778-start-0.html. It
may or may not be what you are looking for, it seems someone
recommends installing from source and avoiding the overlay. Typically
for small projects this is decent advice. Most overlays are not very
high quality, mainly due to the sole maintainer finding other things
to do.

If you can figure out what the executable name is supposed to be, you
can find where it is with `find` or `locate`. You may have to build it
from source in your $HOME to figure out what it's called.

Cheers,
 R0b0t1

[gentoo-user] gambas-3.10.0 installed from jorgicio overlay can't run

[Kruglov Sergey]

Hi!

I installed the 'gambas-3.10.0' from the overlay 'jorgicio' 
(http://data.gpo.zugaina.org/jorgicio/dev-lang/gambas/)
And I can't run it. In /usr/bin/gambas3 there is a link to 'gambas3.gambas' and 
'gambas3.gambas' not found.
Maybe somebody already fix it?

Re: [gentoo-user] switch to profile 17.0 complete, completely painless

[Marc Joliet]

Am Mittwoch, 6. Dezember 2017, 08:00:40 CET schrieb Raffaele Belardi:
> One (~x86) LXDE system completed the switch with no problem, the other
> (~amd64) built all except two packaged (sdlmame and torcs) which did not
> build with gcc-7.2 even before the switch to 17.0.
> 
> Gentoo devs and arch testers did a good job as usual.
> 
> I'll do the switch on the Gnome system in the next days but up to now I can
> say that the switch to 17.0 is a _lot_ less painful than switching major
> compiler version.
> 
> raffaele

I'll add my support for this, the migration was almost completely painless on 
all three of my systems.  There were only a few exceptions:

- I hit the aforementioned cdrdao failure (which I opted to solve via USE 
flag).

- On my laptop I hit the ICU incompatibility with qtwebengine because I had 
firefox install with USE="system-icu" (which was masked at some point in the 
13.0 profiles, which is why I didn't hit this until now), so I unset the USE 
flag again, but that caused some post-migration emerging, which was annoying, 
but not horrible.

- On my desktop rust failed for some reason (almost at the end, of course, 
when building rustdoc), but simply emerging it again afterwards worked.

- On my desktop I also hit the mupen64plus-ui-console build failure.

Note that all of these have open bugs (except for the rust one, but I expect 
that simply came from an inconsistency due to the unfinished "emerge -e 
@world", or a random bitflip, or something similarly ephemeral).

(Oh, and libsidplay failed because its maintainer is apparently too busy to 
fix its incompatibility with app-shells/dash, but that had nothing to do with 
the migration per se.)

I'll also add -- not because I was worried about it but because the 
possibility was mentioned in another thread -- that I can't say I'm noticing 
any performance hits, even on my 11 year old Athlon64 X2.  (IIUC, per the GCC 
manual, PIC and PIE only affect startup time, not runtime, so this result 
should be expected.)

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] net-wireless/blueman-2.1_alpha2 blocked by net-wireless/gnome-bluetooth - is it necessary?

[Alexey Eschenko]

Except that fact that I didn't unmasked it.

# fgrep -rni blueman /etc/portage
/etc/portage/package.use/blueman:1:#net-wireless/blueman

But I understand other possible reasons.

On 12/08/2017 07:37 PM, Alan McKinnon wrote:

On 08/12/2017 15:22, Alexey Eschenko wrote:

It can be the issue. But older version (2.0.4) which is currently
installed works fine and has no conflicts.

It's quite strange.


On 12/08/2017 03:39 PM, Vadim A. Misbakh-Soloviov wrote:

Is it really necessary to block one package when another installed?

Most of the time, the reason to make packages to block each other is
collisions (if they they contain files (like binaries or libraries)
with same
install paths).

Although, I can't guarantee that it was the case here.

I've noticed that Gnome Team makes some decisions, that doesn't looks
logical
for a few times already.



It's not at all strange; it's quite ordinary actually.

Keeping in mind that I do not use these packages, or gnome, look at the
available blueman packages:

# eix net-wireless/blueman
* net-wireless/blueman
  Available versions:  (~)2.0.3 (~)2.0.4 [M](~)2.1_alpha1 **
{appindicator network nls policykit pulseaudio thunar
PYTHON_SINGLE_TARGET="python2_7 python3_4 python3_5 python3_6"
PYTHON_TARGETS="python2_7 python3_4 python3_5 python3_6"}

2.1 is still in an alpha state, and it is p.masked:

/var/portage/profiles/package.mask:
# Michał Górny  (26 Jan 2017)
# Pre-release, masked for testing. Major changes since 2.0.4,
# including dropped support for BlueZ 4.

It is not unreasonable to conclude that blueman-2.1 intends to add
features that conflict with gnome-bluetooth and they can't co-exist. As
Vadim said, file collisions are often the underlying cause.

You unmasked an alpha package, clearly tagged as "for testing". Nothing
add abut the result you got at all.





--
Kind regards,
Alexey Eschenko
https://skobk.in/

Re: [gentoo-user] preparing for profile switch -- major problem

[John Covici]

On Fri, 08 Dec 2017 11:42:16 -0500,
Alan McKinnon wrote:
> 
> On 07/12/2017 17:46, John Covici wrote:
> > On Thu, 07 Dec 2017 09:37:56 -0500,
> > Alan McKinnon wrote:
> >>
> >> On 07/12/2017 07:44, John Covici wrote:
> >>> Hi. In preparing for the profile switch and the emerge -e world, I
> >>> have run into a serious problem with perl.  I think I saw on this list
> >>> where perl 5.26 was going to have problems -- maybe until it is
> >>> stabilized -- but if I mask it off,  I get the following:
> >>
> >> Unmask the latest perl and update world with the old profile
> >>
> >> This will go smoothly as the perl team did an excellent job making sure
> >> everything perl-ish in the tree works in concert with everything else.
> >> However I do recall that trying to do it with a partial world update
> >> didn't work - too many affected packages, so trying just perl + deps did
> >> not work. Rather do a normal world update.
> >>
> >> Once done, then switch your profile to 17.0 and do the giant emerge -e
> >> world that requires.
> >>
> >> tl;dr
> >>
> >> the news message about perl might make you think the sky will fall on
> >> your head and all your kittens will die, this is actually not true.
> >>
> >> The v5.26 updates mostly had to do with perl's search path for perl
> >> modules. Just like how we've frowned on having "." in the shell PATH for
> >> decades, perl now implemented something like that for modules too. The
> >> possible problem anticipated is that modules would now break if a
> >> modules could not find another module it needs. But this really only
> >> applied to modules outside the perl distribution itself. And the Gentoo
> >> perl team dealt with all that already
> >>
> >> It's widely discussed all over the internet in all the usual places, you
> >> are only affected if one of more of these applies:
> >>
> >> - you write perl modules yourself (solution: update your own code)
> >> - you use many ancient cpan modules that no-one touched for yonks
> >> (solution: maybe use currently supported modules instead)
> >> - you heavily rely on a third party perl app that might not have been
> >> updated - musicbrainz and radiator come to mind as examples (solution:
> >> harass your app vendor)
> >>
> >> -- 
> >> Alan McKinnon
> >> alan.mckin...@gmail.com
> >>
> >>
> > 
> > So, I have already switched to the new profile, should I switch back,
> > do a regular world update, or do the world update with the new profile
> > -- I am compiling gcc as I write, although its not finished yet, I can
> > interrupt it if necessary.
> > 
> 
> 
> No, I don't think you should revert the profile change. I understood
> from your mail than you had not done that yet, and typed accordingly.
> 
> I think Michael is on the right track with backtrack - set it to
> something very high like 1000, see if that gets to a solution.


I did switch back, but the only way I could do a "successful" update
was to mask off 5.26 and then it skipped the update and would have
been successful.  If I switch to the new profile, I can do nothing as
far as perl goes.  I will show the output of just trying to emerge
below, it seems there were many many packages still requiring 5.24.
This is with the new profile and backtrack set to 500.

 instances within a single package slot have been pulled
 !!! into the dependency graph, resulting in a slot conflict:

dev-lang/perl:0

  (dev-lang/perl-5.26.1-r1:0/5.26::gentoo, ebuild scheduled for merge)
  pulled in by
  =dev-lang/perl-5.26* required by
  (virtual/perl-ExtUtils-Manifest-1.700.0-r4:0/0::gentoo, installed)
  ^  ^
 dev-lang/perl (Argument)
(and 13 more with the same problems)

  (dev-lang/perl-5.24.3:0/5.24::gentoo, installed) pulled in by
  =dev-lang/perl-5.24* required by
  (virtual/perl-Term-ANSIColor-4.40.0-r1:0/0::gentoo, installed)
 ^  ^
dev-lang/perl:0/5.24= required by
  (dev-perl/XML-Twig-3.520.0:0/0::gentoo, installed)
  
   (and 260 more with the same problems)

NOTE: Use the '--verbose-conflicts' option to display parents omitted
above

It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously.  If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.




-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

Re: [gentoo-user] preparing for profile switch -- major problem

[Alan McKinnon]

On 07/12/2017 17:46, John Covici wrote:
> On Thu, 07 Dec 2017 09:37:56 -0500,
> Alan McKinnon wrote:
>>
>> On 07/12/2017 07:44, John Covici wrote:
>>> Hi. In preparing for the profile switch and the emerge -e world, I
>>> have run into a serious problem with perl.  I think I saw on this list
>>> where perl 5.26 was going to have problems -- maybe until it is
>>> stabilized -- but if I mask it off,  I get the following:
>>
>> Unmask the latest perl and update world with the old profile
>>
>> This will go smoothly as the perl team did an excellent job making sure
>> everything perl-ish in the tree works in concert with everything else.
>> However I do recall that trying to do it with a partial world update
>> didn't work - too many affected packages, so trying just perl + deps did
>> not work. Rather do a normal world update.
>>
>> Once done, then switch your profile to 17.0 and do the giant emerge -e
>> world that requires.
>>
>> tl;dr
>>
>> the news message about perl might make you think the sky will fall on
>> your head and all your kittens will die, this is actually not true.
>>
>> The v5.26 updates mostly had to do with perl's search path for perl
>> modules. Just like how we've frowned on having "." in the shell PATH for
>> decades, perl now implemented something like that for modules too. The
>> possible problem anticipated is that modules would now break if a
>> modules could not find another module it needs. But this really only
>> applied to modules outside the perl distribution itself. And the Gentoo
>> perl team dealt with all that already
>>
>> It's widely discussed all over the internet in all the usual places, you
>> are only affected if one of more of these applies:
>>
>> - you write perl modules yourself (solution: update your own code)
>> - you use many ancient cpan modules that no-one touched for yonks
>> (solution: maybe use currently supported modules instead)
>> - you heavily rely on a third party perl app that might not have been
>> updated - musicbrainz and radiator come to mind as examples (solution:
>> harass your app vendor)
>>
>> -- 
>> Alan McKinnon
>> alan.mckin...@gmail.com
>>
>>
> 
> So, I have already switched to the new profile, should I switch back,
> do a regular world update, or do the world update with the new profile
> -- I am compiling gcc as I write, although its not finished yet, I can
> interrupt it if necessary.
> 


No, I don't think you should revert the profile change. I understood
from your mail than you had not done that yet, and typed accordingly.

I think Michael is on the right track with backtrack - set it to
something very high like 1000, see if that gets to a solution.


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] net-wireless/blueman-2.1_alpha2 blocked by net-wireless/gnome-bluetooth - is it necessary?

[Alan McKinnon]

On 08/12/2017 15:22, Alexey Eschenko wrote:
> It can be the issue. But older version (2.0.4) which is currently
> installed works fine and has no conflicts.
> 
> It's quite strange.
> 
> 
> On 12/08/2017 03:39 PM, Vadim A. Misbakh-Soloviov wrote:
>>> Is it really necessary to block one package when another installed?
>> Most of the time, the reason to make packages to block each other is
>> collisions (if they they contain files (like binaries or libraries)
>> with same
>> install paths).
>>
>> Although, I can't guarantee that it was the case here.
>>
>> I've noticed that Gnome Team makes some decisions, that doesn't looks
>> logical
>> for a few times already.
>>
> 


It's not at all strange; it's quite ordinary actually.

Keeping in mind that I do not use these packages, or gnome, look at the
available blueman packages:

# eix net-wireless/blueman
* net-wireless/blueman
 Available versions:  (~)2.0.3 (~)2.0.4 [M](~)2.1_alpha1 **
{appindicator network nls policykit pulseaudio thunar
PYTHON_SINGLE_TARGET="python2_7 python3_4 python3_5 python3_6"
PYTHON_TARGETS="python2_7 python3_4 python3_5 python3_6"}

2.1 is still in an alpha state, and it is p.masked:

/var/portage/profiles/package.mask:
# Michał Górny  (26 Jan 2017)
# Pre-release, masked for testing. Major changes since 2.0.4,
# including dropped support for BlueZ 4.

It is not unreasonable to conclude that blueman-2.1 intends to add
features that conflict with gnome-bluetooth and they can't co-exist. As
Vadim said, file collisions are often the underlying cause.

You unmasked an alpha package, clearly tagged as "for testing". Nothing
add abut the result you got at all.



-- 
Alan McKinnon
alan.mckin...@gmail.com

[gentoo-user] Re: Puzzled with duration of chromium emerge under profile 17.0

[Grant Edwards]

On 2017-12-06, Mick  wrote:
> On Wednesday, 6 December 2017 21:01:25 GMT Grant Edwards wrote:
>> On 2017-12-06, Mick  wrote:
>> > I discovered that building Chromium with gcc-6.4.0 is taking an
>> > inordinately> 
>> > longer time on a laptop with 1st gen i7 and 4G of RAM, e.g.:
> [snip ...]
>
>> Did the CPU throttling stuff somehow get broken when you updated to
>> gcc-6.4.0?
[...]
> Hmm ... I have not changed anything related to CPU throttling I can remember. 
>  
> Which reminds me, perhaps I should 'make clean' my kernel now that I have 
> switched to gcc-6.4.0?

Shouldn't need to.  I think my throttling got broken when I updated
kernels.

> i7z shows turbo mode kicks in too and hyperthreading is on (attached).  Under 
> turbo it jumps up to 2.8GHz.  So cpu throttling is probably not the cause of 
> my problem, unless it throttles more now than it used to do before?  :-/

If throttling were broken it would be pretty obvious: when you do 'cat
/proc/cpuinfo' in the middle of an emerge, it would show 500MHz (or
whatever) as the core frequency.  [It still took me half a day to
find out that's what was wrong.]

-- 
Grant Edwards   grant.b.edwardsYow! I want to dress you
  at   up as TALLULAH BANKHEAD and
  gmail.comcover you with VASELINE and
   WHEAT THINS ...

Re: [gentoo-user] Update is blocked by ots previous version...?

[tuxic]

On 12/08 08:18, Neil Bothwick wrote:
> On Fri, 8 Dec 2017 03:36:11 +0100, tu...@posteo.de wrote:
> 
> > | WARNING: One or more updates/rebuilds have been skipped due to a
> > | dependency conflict:
> > | 
> > | app-emulation/containerd:0
> > | 
> > |   (app-emulation/containerd-1.0.0:0/0::gentoo, ebuild scheduled for
> > | merge) conflicts with ~app-emulation/containerd-1.0.0_beta2_p20171019
> > | required by (app-emulation/docker-17.11.0:0/0::gentoo, installed)
> > | ^ ^  
> > 
> > 
> > I removed containerd yesterday and installed it again only to get the
> > same error this morning again.
> > 
> > Any away around this?
> 
> There is an update to containerd available but docker depends
> specifically on the older version. So portage is telling you it is not
> updating containerd as this may break docker. It may be worth filing a
> bug against docker if it should work with containerd-1.0.0.
> 
> 
> -- 
> Neil Bothwick
> 
> This man is depriving a village somewhere of an idiot


Hi Neil,

ok...I see...thanks a lot for the explanation!

Cheers
Meino

[gentoo-user] app-misc/screen-4.6.2 fails

[tuxic]

Hi,

while updateing app-misc/screen-4.6.2
I got this:

config.status: creating doc/Makefile
config.status: creating config.h
config.status: executing default commands

Now please check the pathnames in the Makefile and in the user
configuration section in config.h.
Then type 'make' to make screen. Good luck.

>>> Source configured.
>>> Compiling source in 
>>> /var/tmp/portage/app-misc/screen-4.6.2/work/screen-4.6.2 ...
make -j6 comm.h term.h 
AWK=gawk CC="x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -D_GNU_SOURCE" 
srcdir=. sh ./comm.sh
AWK=gawk srcdir=. sh ./term.sh
make -j6 osdef.h 
CPP="x86_64-pc-linux-gnu-gcc -E -DMAXWIN=100 -DNONETHACK 
-DETCSCREENRC='"/etc/screenrc"' 
-DSCREENENCODINGS='"/usr/share/screen/utf8encodings"'" srcdir=. sh ./osdef.sh
make -j6 -C doc screen.info 
make: Entering directory 
'/var/tmp/portage/app-misc/screen-4.6.2/work/screen-4.6.2/doc'
makeinfo ./screen.texinfo -o screen.info
./screen.texinfo:3220: `@end' expected `deffn', but saw `example'
./screen.texinfo:3220: unmatched `@end example'
./screen.texinfo:3222: unmatched `@end deffn'
make: *** [Makefile:31: screen.info] Error 1
make: Leaving directory 
'/var/tmp/portage/app-misc/screen-4.6.2/work/screen-4.6.2/doc'
 * ERROR: app-misc/screen-4.6.2::gentoo failed (compile phase):
 *   emake failed

It looks like a certain texinfo file of this version has a problem.
I am no texinfo expert at all but looking at that file I dont see any
problem.

Does anyone else the problem?
What may trigger it?

My texinfon installation:

[I] sys-apps/texinfo
 Available versions:  6.1 6.3 (~)6.4 (~)6.5 {nls static}
 Installed versions:  6.5(05:06:45 AM 12/07/2017)(nls -static)
 Homepage:https://www.gnu.org/software/texinfo/
 Description: The GNU info program and utilities


Cheers
Meino

[gentoo-user] Re: Again, emerge -e @world related questions...

[Melleus]

I had moved to v 17.0 profile mostly painless, though it was a time
consuming event. But I got one point anyway. Python in my system was
updated from 3.4 to 3.5 and after 3.4 was removed with depclean, the
option for v 3.4 in eselect python remains. It looks a bit weird to me
when I can choose with eselect the version of python that is not
currently present in the system. Is this intended behavior?

Re: [gentoo-user] net-wireless/blueman-2.1_alpha2 blocked by net-wireless/gnome-bluetooth - is it necessary?

[Alexey Eschenko]

It can be the issue. But older version (2.0.4) which is currently 
installed works fine and has no conflicts.


It's quite strange.


On 12/08/2017 03:39 PM, Vadim A. Misbakh-Soloviov wrote:

Is it really necessary to block one package when another installed?

Most of the time, the reason to make packages to block each other is
collisions (if they they contain files (like binaries or libraries) with same
install paths).

Although, I can't guarantee that it was the case here.

I've noticed that Gnome Team makes some decisions, that doesn't looks logical
for a few times already.



--
Kind regards,
Alexey Eschenko
https://skobk.in/

Re: [gentoo-user] Package version bump policy

[Alexey Eschenko]

It's "This is not a final release, and it does have known issues, 
including a crash bug". But it can be used with PHP 7.2 to start 
upgrading applications.


Ok, I'll create the issue in the Bugzilla and let the maintainer decide.


On 12/08/2017 03:51 PM, Michael Orlitzky wrote:

On 12/08/2017 07:06 AM, Alexey Eschenko wrote:

Hi guys.

Some time ago PHP 7.2 was released. To start working with it I was
needed XDebug and it was released in "alpha" version: https://xdebug.org/

Is there any policy against version bumps for "alpha" versions or I can
create the issue about dev-php/xdebug bump in the Bugzilla?


It's up to the maintainer... we have no policy against it, but you don't
want to commit broken/untested packages to the tree obviously.

If the xdebug alpha is "we added php-7.2 support but haven't tested it
yet", then feel free to submit a normal version bump. On the other hand,
if it's "this new alpha version happens to support php-7.2 but also has
new features that might eat your server," then it would be better to add
it alongside a package.mask entry that says "masked for testing" or
something like that.



--
Kind regards,
Alexey Eschenko
https://skobk.in/

Re: [gentoo-user] Package version bump policy

[Michael Orlitzky]

On 12/08/2017 07:06 AM, Alexey Eschenko wrote:
> Hi guys.
> 
> Some time ago PHP 7.2 was released. To start working with it I was 
> needed XDebug and it was released in "alpha" version: https://xdebug.org/
> 
> Is there any policy against version bumps for "alpha" versions or I can 
> create the issue about dev-php/xdebug bump in the Bugzilla?
> 

It's up to the maintainer... we have no policy against it, but you don't
want to commit broken/untested packages to the tree obviously.

If the xdebug alpha is "we added php-7.2 support but haven't tested it
yet", then feel free to submit a normal version bump. On the other hand,
if it's "this new alpha version happens to support php-7.2 but also has
new features that might eat your server," then it would be better to add
it alongside a package.mask entry that says "masked for testing" or
something like that.

Re: [gentoo-user] net-wireless/blueman-2.1_alpha2 blocked by net-wireless/gnome-bluetooth - is it necessary?

[Vadim A. Misbakh-Soloviov]

> Is it really necessary to block one package when another installed?

Most of the time, the reason to make packages to block each other is 
collisions (if they they contain files (like binaries or libraries) with same 
install paths).

Although, I can't guarantee that it was the case here.

I've noticed that Gnome Team makes some decisions, that doesn't looks logical 
for a few times already.

[gentoo-user] net-wireless/blueman-2.1_alpha2 blocked by net-wireless/gnome-bluetooth - is it necessary?

[Alexey Eschenko]

After last portage package tree update I've got this conflict:

[ebuild U ] net-wireless/blueman-2.1_alpha2 [2.0.4] USE="nls 
policykit pulseaudio -appindicator -network (-thunar%)" 
PYTHON_SINGLE_TARGET="python3_4 -python3_5 -python3_6% (-python2_7%)" 
PYTHON_TARGETS="python3_4 python3_5 -python3_6% (-python2_7%*)"
[blocks B ] net-wireless/gnome-bluetooth 
("net-wireless/gnome-bluetooth" is blocking 
net-wireless/blueman-2.1_alpha2)


 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (net-wireless/gnome-bluetooth-3.20.1:2/13::gentoo, installed) pulled 
in by
    >=net-wireless/gnome-bluetooth-3.18.2:2/13= required by 
(gnome-base/gnome-control-center-3.24.3:2/2::gentoo, installed)
    >=net-wireless/gnome-bluetooth-3.18.2:= required by 
(gnome-base/gnome-control-center-3.24.3:2/2::gentoo, installed)
    >=net-wireless/gnome-bluetooth-3.9[introspection] required by 
(gnome-base/gnome-shell-3.24.3:0/0::gentoo, installed)


I have a reason for using blueman and gnome-bluetooth at the same time. 
gnome-bluetooth is a part of Gnome environment which provides small set 
of basic options. blueman is more advanced and makes me able to switch 
device profiles or change some setting which gnome-bluetooth can not.


Is it really necessary to block one package when another installed?

--
Kind regards,
Alexey Eschenko
https://skobk.in/

[gentoo-user] Package version bump policy

[Alexey Eschenko]

Hi guys.

Some time ago PHP 7.2 was released. To start working with it I was 
needed XDebug and it was released in "alpha" version: https://xdebug.org/


Is there any policy against version bumps for "alpha" versions or I can 
create the issue about dev-php/xdebug bump in the Bugzilla?


--
Kind regards,
Alexey Eschenko
https://skobk.in/

Re: [gentoo-user] wine update blocked by winetricks and playonlinux

[Arve Barsnes]

On 8 December 2017 at 10:28, Alarig Le Lay  wrote:

> Hi,
>
> I tried to update my system to reflect the splitting described in
> https://www.gentoo.org/support/news-items/2017-04-10-
> split-and-slotted-wine.html
>
> But, I have three conflicts :
>
> [blocks B  ] app-emulation/wine:0 ("app-emulation/wine:0" is hard
> blocking app-emulation/wine-mono-4.6.4, app-eselect/eselect-wine-1.2.2,
> app-emulation/wine-gecko-2.47-r1)
> [blocks B  ] app-emulation/wine:0 ("app-emulation/wine:0" is hard
> blocking app-emulation/wine-desktop-common-20150204)
> [blocks B  ] app-emulation/wine:0 ("app-emulation/wine:0" is blocking
> virtual/wine-0-r5, app-emulation/wine-vanilla-2.0.3)
>
> And, if I try to uninstall wine in order to update the rest of my
> system, I see that wine is a dependence of
> app-emulation/playonlinux-4.2.12 and app-emulation/winetricks-20170823
>
> airmure ~ # emerge -vac app-emulation/wine
>
> Calculating dependencies... done!
>   app-emulation/wine-2.0 pulled in by:
> app-emulation/playonlinux-4.2.12 requires app-emulation/wine
> app-emulation/winetricks-20170823 requires app-emulation/wine
>

Both of those depend on either the old app-emulation/wine OR the new
virtual/wine, so you should be fine just emerge -C app-emulation/wine and
install your chosen flavour(s) of the new split version.

Arve

[gentoo-user] wine update blocked by winetricks and playonlinux

[Alarig Le Lay]

Hi,

I tried to update my system to reflect the splitting described in
https://www.gentoo.org/support/news-items/2017-04-10-split-and-slotted-wine.html

But, I have three conflicts :

[blocks B  ] app-emulation/wine:0 ("app-emulation/wine:0" is hard blocking 
app-emulation/wine-mono-4.6.4, app-eselect/eselect-wine-1.2.2, 
app-emulation/wine-gecko-2.47-r1)
[blocks B  ] app-emulation/wine:0 ("app-emulation/wine:0" is hard blocking 
app-emulation/wine-desktop-common-20150204)
[blocks B  ] app-emulation/wine:0 ("app-emulation/wine:0" is blocking 
virtual/wine-0-r5, app-emulation/wine-vanilla-2.0.3)

And, if I try to uninstall wine in order to update the rest of my
system, I see that wine is a dependence of
app-emulation/playonlinux-4.2.12 and app-emulation/winetricks-20170823 

airmure ~ # emerge -vac app-emulation/wine

Calculating dependencies... done!
  app-emulation/wine-2.0 pulled in by:
app-emulation/playonlinux-4.2.12 requires app-emulation/wine
app-emulation/winetricks-20170823 requires app-emulation/wine

My plan is to modify those ebuild myself, but I’m wondering how to test
it if I want to submit this patch via bugzilla.

Thanks in advance for your inputs,
-- 
alarig


signature.asc
Description: PGP signature

Re: [gentoo-user] Update is blocked by ots previous version...?

[Neil Bothwick]

On Fri, 8 Dec 2017 03:36:11 +0100, tu...@posteo.de wrote:

> | WARNING: One or more updates/rebuilds have been skipped due to a
> | dependency conflict:
> | 
> | app-emulation/containerd:0
> | 
> |   (app-emulation/containerd-1.0.0:0/0::gentoo, ebuild scheduled for
> | merge) conflicts with ~app-emulation/containerd-1.0.0_beta2_p20171019
> | required by (app-emulation/docker-17.11.0:0/0::gentoo, installed)
> | ^ ^  
> 
> 
> I removed containerd yesterday and installed it again only to get the
> same error this morning again.
> 
> Any away around this?

There is an update to containerd available but docker depends
specifically on the older version. So portage is telling you it is not
updating containerd as this may break docker. It may be worth filing a
bug against docker if it should work with containerd-1.0.0.


-- 
Neil Bothwick

This man is depriving a village somewhere of an idiot


pgpvpBQuyGEAh.pgp
Description: OpenPGP digital signature