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

2017-12-10 Thread Alexey Eschenko
Hi. Thank you for your attention. Try to remove the blocker in blueman, see if files collide or notHow can I remove the blocker in blueman? AFAIK it's not like adding package constraint to the package.unmask or something like that. I have no experience with writing ebuilds though.But I can check "equery f" for one package and then remove it, install another and check the same for it and then look for repeating file paths. Will it be enough? 09.12.2017, 17:08, "Mart Raudsepp" :On R, 2017-12-08 at 19:39 +0700, 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.There was a blocker in blueman against gnome-bluetooth due to a filecollision with gnome-bluetooth. This was removed with 2.0-r1, back inOct 2015, as blueman upstream solved it.To me it looks like the change didn't make it to the live ebuild andthen eventually sometime after 2.0.3 a bump was made via copying from, not the latest version, thus reinstating the blocker, possibly byaccident. Or maybe on purpose, but I don't see an explanation for it inlogs.Try to remove the blocker in blueman, see if files collide or not, andif not file a bug against blueman, possibly with info that it mighthave been accidental reintroduction due to..., etc.  I've noticed that Gnome Team makes some decisions, that doesn't looks logical  for a few times already.Something not looking logical for you doesn't mean there isn't soundlogic. In this case, it's not us who have a blocker possibly wronglyreintroduced here.Best,Mart RaudseppGentoo GNOME team lead 

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

2017-12-09 Thread Mart Raudsepp
On R, 2017-12-08 at 19:39 +0700, 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.

There was a blocker in blueman against gnome-bluetooth due to a file
collision with gnome-bluetooth. This was removed with 2.0-r1, back in
Oct 2015, as blueman upstream solved it.
To me it looks like the change didn't make it to the live ebuild and
then eventually sometime after 2.0.3 a bump was made via copying from
, not the latest version, thus reinstating the blocker, possibly by
accident. Or maybe on purpose, but I don't see an explanation for it in
logs.
Try to remove the blocker in blueman, see if files collide or not, and
if not file a bug against blueman, possibly with info that it might
have been accidental reintroduction due to..., etc.

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

Something not looking logical for you doesn't mean there isn't sound
logic. In this case, it's not us who have a blocker possibly wrongly
reintroduced here.


Best,
Mart Raudsepp
Gentoo GNOME team lead



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

2017-12-09 Thread Alan McKinnon
On 09/12/2017 02:47, Alexey Eschenko wrote:
> Except that fact that I didn't unmasked it.

You must have had a tree checkout slightly newer than mine. I just
synced here and see that the mask has now been removed.

It's quite unusual to unmask an alpha version, maybe raise it on b.g.o ?

For the rest, that's just how blockers go unfortunately. There is no
easy way for the maintainer to communicate to you at emerge time *why*
the blocker is there, you just see the effect that it *is* there.

It's proper to block package B if new version of package A provides the
same features and they collide. But portage is stuck with nowhere to go
if you happen to have package B in world.

>> # 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.
>>
>>
>>
> 


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




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

2017-12-08 Thread 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] net-wireless/blueman-2.1_alpha2 blocked by net-wireless/gnome-bluetooth - is it necessary?

2017-12-08 Thread 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




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

2017-12-08 Thread 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] net-wireless/blueman-2.1_alpha2 blocked by net-wireless/gnome-bluetooth - is it necessary?

2017-12-08 Thread 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?

2017-12-08 Thread 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/