Re: Deprecated net-tools? Mass bug filing?

[Stephen John Smoogen]

On 16 May 2017 at 18:29, James Hogarth  wrote:
> Hi,
>
> It was pointed out on IRC to me tonight that there are actually a
> reasonable number of packages that still depend on net-tools[0].
>
> This has been deprecated for a long time now and we really should
> strive to have everything use iproute2 instead so that there is no
> longer a need to keep the deprecated package about, other than if
> someone explicitly really wants netstat or ifconfig for some reason.
>
> Is the best way to handle this a mass bug filing?
>
> If we can at least start cutting down this list in the FC27 cycle I
> think it would be a worthy effort.
>
> James
>
>
> [0] package list:
> sudo dnf repoquery --alldeps --whatrequires net-tools

> gnome-nettool-0:3.8.1-9.fc26.x86_64

I think the name says it all there :)

> redhat-lsb-supplemental-0:4.1-34.fc26.x86_64

That might be a hard and fast not going to happen unless the LSB is
modernized not to require ifconfig etc.


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Making swatchbooker run

[Luya Tshimbalanga]

Any suggestion to symlink to the 64bit flavour?

Luya
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Deprecated net-tools? Mass bug filing?

[James Hogarth]

Hi,

It was pointed out on IRC to me tonight that there are actually a
reasonable number of packages that still depend on net-tools[0].

This has been deprecated for a long time now and we really should
strive to have everything use iproute2 instead so that there is no
longer a need to keep the deprecated package about, other than if
someone explicitly really wants netstat or ifconfig for some reason.

Is the best way to handle this a mass bug filing?

If we can at least start cutting down this list in the FC27 cycle I
think it would be a worthy effort.

James


[0] package list:
sudo dnf repoquery --alldeps --whatrequires net-tools
WALinuxAgent-0:2.0.18-2.fc26.noarch
beakerlib-0:1.15-2.fc26.noarch
chkrootkit-0:0.52-1.fc26.x86_64
cloud-init-0:0.7.9-4.fc26.noarch
cloud-init-0:0.7.9-5.fc26.noarch
ctdb-2:4.6.3-0.fc26.x86_64
facter-0:2.4.3-1.fc23.x86_64
gnome-nettool-0:3.8.1-9.fc26.x86_64
inxi-0:2.3.8-2.fc26.noarch
iodine-server-0:0.7.0-7.fc26.x86_64
mariadb-server-3:10.1.21-3.fc26.x86_64
mediatomb-0:0.12.1-40.fc26.20120403gitb66dc1.x86_64
open-vm-tools-0:10.1.5-4.fc26.i686
open-vm-tools-0:10.1.5-4.fc26.x86_64
openslp-server-0:2.0.0-12.fc26.x86_64
openwsman-server-0:2.6.3-2.git4391e5c.fc26.i686
openwsman-server-0:2.6.3-2.git4391e5c.fc26.x86_64
peervpn-0:0.044-1.fc25.x86_64
pki-server-0:10.3.5-12.fc26.noarch
psad-0:2.4.3-4.fc26.x86_64
redhat-lsb-supplemental-0:4.1-34.fc26.x86_64
resource-agents-0:4.0.1-1.fc26.1.x86_64
synce-connector-0:0.15.2-13.fc24.i686
synce-connector-0:0.15.2-13.fc24.x86_64
systemtap-runtime-java-0:3.1-3.fc26.x86_64
testcloud-0:0.1.11-1.fc26.noarch
tunir-0:0.17.1-1.fc26.noarch
tunir-0:0.17.2-1.fc26.noarch
vpnc-script-0:20140805-5.gitdf5808b.fc26.noarch
wicd-common-0:1.7.4-2.fc26.noarch
wifi-radar-0:2.0.s10-4.fc26.noarch
wlassistant-0:0.5.7-25.fc26.x86_64
x2goserver-0:4.0.1.20-2.fc26.x86_64
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finding conflicts in /usr/bin

[Rex Dieter]

Przemek Klosowski wrote:

>>> While this should probably be considered a bug that needs to be fixed,
>> https://bugzilla.redhat.com/show_bug.cgi?id=1451463
> And Frank Ch. Eigler closed it, explaining that:
>> It turns out that this is a deliberate decision.  As
>> outlined within the .spec file, the -devel subrpm is for building
>> systemtap modules (running pass 1..4); the -client subrpm is for being
>> able to build
>> systemtap modules -remotely-.  Both those tasks happen to be performed by
>> the same binary.
> One could create a sub-subpackage that both subpackages depend on, but
> it's getting to be silly. Is there no other option to handle this in RPM?

other option is the status quo, where a common file is shared among > 1 
subpkg (which is acceptable, not particularly a bug per-se).

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Making swatchbooker run

[Björn 'besser82' Esser]

Am 16.05.2017 um 20:58 schrieb Luya Tshimbalanga:

python2-lcms2 just landed in the repository

https://koji.fedoraproject.org/koji/packageinfo?packageID=24206

Attempting to run swatcbooker resulted his error:

$ swatchbooker
Traceback (most recent call last):
   File "/usr/share/swatchbooker/swatchbooker.pyw", line 27, in 
 from sbcommon import *
   File "/usr/share/swatchbooker/sbcommon.py", line 27, in 
 from swatchbook import *
   File "/usr/lib/python2.7/site-packages/swatchbook/__init__.py", line
26, in 
 from color import *
   File "/usr/lib/python2.7/site-packages/swatchbook/color.py", line 22,
in 
 from lcms2 import *
   File "/usr/lib/python2.7/site-packages/swatchbook/lcms2.py", line 601,
in 
 _libs["lcms2"] = load_library("lcms2")
   File "/usr/lib/python2.7/site-packages/swatchbook/lcms2.py", line 350,
in load_library
 return self.load(path)
   File "/usr/lib/python2.7/site-packages/swatchbook/lcms2.py", line 366,
in load
 raise ImportError(e)
ImportError: /lib/liblcms2.so.2.0.8: wrong ELF class: ELFCLASS32

python2-lcm2 was supposed to resolve the issue but it seems no effect,
what will be missing piece to properly bind lcms2 using python2-lcms2 or
a better approach?

Current swatchbooker spec:

https://src.fedoraproject.org/cgit/rpms/swatchbooker.git/tree/swatchbooker.spec


Thanks in advance



It looks like you are having python2-lcm in 32-bit flavour installed on 
a 64-bit machine…

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Making swatchbooker run

[Luya Tshimbalanga]

python2-lcms2 just landed in the repository

https://koji.fedoraproject.org/koji/packageinfo?packageID=24206

Attempting to run swatcbooker resulted his error:

$ swatchbooker
Traceback (most recent call last):
  File "/usr/share/swatchbooker/swatchbooker.pyw", line 27, in 
from sbcommon import *
  File "/usr/share/swatchbooker/sbcommon.py", line 27, in 
from swatchbook import *
  File "/usr/lib/python2.7/site-packages/swatchbook/__init__.py", line
26, in 
from color import *
  File "/usr/lib/python2.7/site-packages/swatchbook/color.py", line 22,
in 
from lcms2 import *
  File "/usr/lib/python2.7/site-packages/swatchbook/lcms2.py", line 601,
in 
_libs["lcms2"] = load_library("lcms2")
  File "/usr/lib/python2.7/site-packages/swatchbook/lcms2.py", line 350,
in load_library
return self.load(path)
  File "/usr/lib/python2.7/site-packages/swatchbook/lcms2.py", line 366,
in load
raise ImportError(e)
ImportError: /lib/liblcms2.so.2.0.8: wrong ELF class: ELFCLASS32

python2-lcm2 was supposed to resolve the issue but it seems no effect,
what will be missing piece to properly bind lcms2 using python2-lcms2 or
a better approach?

Current swatchbooker spec:

https://src.fedoraproject.org/cgit/rpms/swatchbooker.git/tree/swatchbooker.spec


Thanks in advance

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

libdrm 2.4.80 Mesa 17.1.0 Wine-Stage 2.8 on Fedora 25

[Andreas Benzler]

Hello Guys,

I build successfully:

libdrm 2.4.80 Mesa 17.1.0 Wine-Stage 2.8

and use it daily.

https://copr.fedorainfracloud.org/coprs/andybe/


Sincerely

AndyBe
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finding conflicts in /usr/bin

[Przemek Klosowski]

On 05/16/2017 01:14 PM, Przemek Klosowski wrote:


This sender failed our fraud detection checks and may not be who they appear to be. 
Learn about spoofing    Feedback 


On 05/13/2017 02:55 AM, Emmanuel Seyman wrote:

* Przemek Klosowski [12/05/2017 16:27] :

The only one I could see that is really provided by multiple packages is
/usr/bin/stap* : they seem to be provided by both systemtap-client and
systemtap-devel.
WHAT'S UP WITH THAT?

While this should probably be considered a bug that needs to be fixed,

https://bugzilla.redhat.com/show_bug.cgi?id=1451463

And Frank Ch. Eigler closed it, explaining that:

It turns out that this is a deliberate decision.  As
outlined within the .spec file, the -devel subrpm is for building systemtap
modules (running pass 1..4); the -client subrpm is for being able to build
systemtap modules -remotely-.  Both those tasks happen to be performed by the
same binary.
One could create a sub-subpackage that both subpackages depend on, but 
it's getting to be silly. Is there no other option to handle this in RPM?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Finding conflicts in /usr/bin

[Przemek Klosowski]

On 05/13/2017 02:55 AM, Emmanuel Seyman wrote:

* Przemek Klosowski [12/05/2017 16:27] :

The only one I could see that is really provided by multiple packages is
/usr/bin/stap* : they seem to be provided by both systemtap-client and
systemtap-devel.
WHAT'S UP WITH THAT?

While this should probably be considered a bug that needs to be fixed,

https://bugzilla.redhat.com/show_bug.cgi?id=1451463

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 26 Beta Freeze

[Mohan Boddu]

Hi all,

Today is an important day on the Fedora 26 schedule[1], with two
 significant cut-offs.

Today is the Beta freeze[2]. This means that only packages which fix
accepted blocker or freeze exception bugs[3][4] will be marked as 'stable'
and included in the Beta composes. Other builds will remain in
updates-testing until the Beta release is approved, at which point the Beta
freeze is lifted and packages can move to 'stable' as usual until the Final
freeze.

Finally, Today is the '100% code complete deadline' Change Checkpoint[5],
meaning that Fedora 26 Changes must now be code complete, meaning all the
code required to enable to the new change is finished. The level of code
completeness is reflected as tracker bug state ON_QA. The change does not
have to be fully tested by this deadline'.

Regards

Mohan Boddu

[1] https://fedoraproject.org/wiki/Releases/26/Schedule
[2] https://fedoraproject.org/wiki/Milestone_freezes
[3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[5] https://fedoraproject.org/wiki/Changes/Policy
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[David Sommerseth]

On 16/05/17 14:20, Stephen Gallagher wrote:
>> apparently *designed* with philosophy much like that of systemd. It's
>> supposed to be a unified set of tools replacing a lot of already
>> existing functionality, and adding some useful features.
>> Unfortunately, its unifying multiple service and multiple host
>> authentication doesn't seem to have become popular: Most folks I've
>> seen using Kerberos and LDAP, which sssd was designed to integrate,
>> have simply ignored sssd and gone straight to the more multi-platform
>> supported Samba.
>
> Just a reminder: anecdotes do not equal rigorous data :)
> 
> SSSD is in extremely wide use around the world and is the preferred
> LDAP/Kerberos client option in all of the major Linux distributions.

Just to backup this a bit further.  Those integrating with AD, will also
most likely take advantage of LDAP/Kerberos as well.  Kerberos is the
only authentication scheme I know of which also enables a truly working
SSO solution, which tackles the full stack from localhost login to
various network services.

In addition, SSSD provides a possibility to cache authentication details
so you can have laptops fully integrated with an LDAP/Kerberos
environment, provide a centralized password policy and yet be able to do
local authentication if the LDAP/Kerberos backends are unavailable.

And then there is the support for OTP based authentication, which it
also seems to be handled quite well regardless if you are online or not.

From my perspective, SSSD solves more issues than what nscd is capable
of, at least to how I've learnt to know nscd.  And my experience with
computers enrolled into a FreeIPA managed network have overall just been
a wonderful and easy experience.


-- 
kind regards,

David Sommerseth



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Stephen Gallagher]

On 05/16/2017 07:04 AM, Nico Kadel-Garcia wrote:
> On Mon, May 15, 2017 at 11:37 AM, Stephen Gallagher  
> wrote:
>>
>>
>> On 05/15/2017 11:30 AM, Jakub Hrozek wrote:
>>> On Mon, May 15, 2017 at 05:22:14PM +0200, Tomas Mraz wrote:
> 
 The questions still hold for the consistency between passwd and shadow
 and also for the systemd module present.
>>> Since sssd doesn't handle the password map, being consistent there in
>>> the ordering sense (sss before files) wouldn't make much sense, because
>>> the nss module functions for the shadow map are not even implemented in
>>> nss_sss. We could even omit the sss module from that map altogether.
>>
>> The only historical reason it is there is because authconfig didn't
>> differentiate them; it made all changes to shadow identically to passwd.
>> I don't know if that's still the case, but I'm pretty sure it was when
>> we first added SSSD support to authconfig. It's not harmful, since the
>> SSSD client just immediately returns with an appropriate NSS error code
>> if it's asked for any shadow map function.
> 
> Stephen, activating *any* service you don't need and using it for work
> that cannot possibly succeed is potentially harmful to performance and
> stability of the system. It may not be notably destructive or very
> expensive, and in this case would normally be harmless. But it helps
> create another possible point of failure in a system critical
> function. The underlying problem there would seem to be one of
> authconfig activating features pointlessly in /etc/nsswitch.cnf, not
> of the sssd software itself.
> 

To clarify, having this in nsswitch.conf does *NOT* activate the SSSD service on
the system (in and of itself). And the system around it is carefully designed so
that if SSSD is not running or accessible, it immediately returns control to
glibc which then goes through the classic nss_files path.

> Tomasz's tone has been consistently rude. In this cae, he did seem to
> have a point. sssd is, in this case, re-inventing some of the wheels
> of nscd. He could have said so much more nicely. 

Yes, SSSD does reinvent nscd, because nscd did not meet the needs of a great
many people. Its caching methodology is too simplistic (it uses the exact same
approach to deal with all possible name-service maps, which means that its
decision process has to be least-common-denominator). We very much set out to
replace nscd because it didn't work well and the upstream at the time was
immovable on many of these points. While this may no longer be true, that ship
has sailed.


And Tomasz? sssd was
> apparently *designed* with philosophy much like that of systemd. It's
> supposed to be a unified set of tools replacing a lot of already
> existing functionality, and adding some useful features.
> Unfortunately, its unifying multiple service and multiple host
> authentication doesn't seem to have become popular: Most folks I've
> seen using Kerberos and LDAP, which sssd was designed to integrate,
> have simply ignored sssd and gone straight to the more multi-platform
> supported Samba.

Just a reminder: anecdotes do not equal rigorous data :)

SSSD is in extremely wide use around the world and is the preferred
LDAP/Kerberos client option in all of the major Linux distributions.


 And authconfig has never really evolved to provide
> more robust, consistent activation of localized configurations,
> settings which are overwritten without notification when authconfig is
> run. Authconfig is a fairly dangerous tool if you need to customize
> local configurations, including its inability to remove obsolete
> domains or to support multiple domains in the /etc/krb5.cnf
> configurations, and its consistent overwriting of localized
> configurations for password expiration in /etc/nsswitch.cnf.
> 

Yes, authconfig is *not* a good tool for managing centralized authentication
services and its upstream has been unable to keep up with the changing needs of
the system. That's why work is under way to replace it with more robust tools. I
think Jakub can talk more about that.


> The resulting potential for confusion would thus not really seem to be
> an sssd issue. It would seem to be an authconfig issue. Since shadow,
> and password, are distinct settings with distinct sets of attributes
> driven by sssd activation, perhaps that would be a good place to spend
> some configuration management time, rather than relying on sssd to
> reply sensibly to a request that it will never be able to fulfill.

I'm not sure what exactly you're saying here other than "don't include 'sss' in
the 'shadow' line, to which I completely agree.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Nico Kadel-Garcia]

On Mon, May 15, 2017 at 11:37 AM, Stephen Gallagher  wrote:
>
>
> On 05/15/2017 11:30 AM, Jakub Hrozek wrote:
>> On Mon, May 15, 2017 at 05:22:14PM +0200, Tomas Mraz wrote:

>>> The questions still hold for the consistency between passwd and shadow
>>> and also for the systemd module present.
>> Since sssd doesn't handle the password map, being consistent there in
>> the ordering sense (sss before files) wouldn't make much sense, because
>> the nss module functions for the shadow map are not even implemented in
>> nss_sss. We could even omit the sss module from that map altogether.
>
> The only historical reason it is there is because authconfig didn't
> differentiate them; it made all changes to shadow identically to passwd.
> I don't know if that's still the case, but I'm pretty sure it was when
> we first added SSSD support to authconfig. It's not harmful, since the
> SSSD client just immediately returns with an appropriate NSS error code
> if it's asked for any shadow map function.

Stephen, activating *any* service you don't need and using it for work
that cannot possibly succeed is potentially harmful to performance and
stability of the system. It may not be notably destructive or very
expensive, and in this case would normally be harmless. But it helps
create another possible point of failure in a system critical
function. The underlying problem there would seem to be one of
authconfig activating features pointlessly in /etc/nsswitch.cnf, not
of the sssd software itself.

Tomasz's tone has been consistently rude. In this cae, he did seem to
have a point. sssd is, in this case, re-inventing some of the wheels
of nscd. He could have said so much more nicely.  And Tomasz? sssd was
apparently *designed* with philosophy much like that of systemd. It's
supposed to be a unified set of tools replacing a lot of already
existing functionality, and adding some useful features.
Unfortunately, its unifying multiple service and multiple host
authentication doesn't seem to have become popular: Most folks I've
seen using Kerberos and LDAP, which sssd was designed to integrate,
have simply ignored sssd and gone straight to the more multi-platform
supported Samba. And authconfig has never really evolved to provide
more robust, consistent activation of localized configurations,
settings which are overwritten without notification when authconfig is
run. Authconfig is a fairly dangerous tool if you need to customize
local configurations, including its inability to remove obsolete
domains or to support multiple domains in the /etc/krb5.cnf
configurations, and its consistent overwriting of localized
configurations for password expiration in /etc/nsswitch.cnf.

The resulting potential for confusion would thus not really seem to be
an sssd issue. It would seem to be an authconfig issue. Since shadow,
and password, are distinct settings with distinct sets of attributes
driven by sssd activation, perhaps that would be a good place to spend
some configuration management time, rather than relying on sssd to
reply sensibly to a request that it will never be able to fulfill.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenVPN v2.4.2 with two important fixes

[David Sommerseth]

On 12/05/17 13:59, Jonathan Wakely wrote:
> On 11/05/17 16:59 +0200, David Sommerseth wrote:
>>
>> Hi,
>>
>> Just making a little noise here, as the upstream OpenVPN community have
>> released v2.4.2 which fixes to critical authenticated remote DoS
>> vulnerabilities.
>>
>> 
>>
>> (the site is being hammered right now, so patience is needed ;-))
>>
>> I have already sent the updates to EPEL 6, EPEL7 and F-25.
>>
>> Next in the pipe is F-26 and Rawhide, but that have the challenges
>> around OpenSSL 1.1 vs mbedtls - and I plan to test out compat-openssl
>> with compat-pkcs11-helper.
> 
> Will F24 get an update to 2.3.15?
> 
> The current 2.3.14 version seems to have the same issues as 2.4.1 in
> F25 does.

Just prepared this update:



-- 
kind regards,

David Sommerseth



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Review swap: keepassxc - Cross-platform password manager

[Germano Massullo]

Review request has been taken
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: mp3 encoding now ok

[James Hogarth]

On 15 May 2017 at 23:31, Peter Robinson  wrote:
> On Mon, May 15, 2017 at 10:35 PM, James Hogarth  
> wrote:
>>
>>
>> On 15 May 2017 5:15 pm, "Tom Callaway"  wrote:
>>
>> On 05/04/2017 09:09 AM, Jon Ciesla wrote:
>>>
>>>
>>> On Thu, May 4, 2017 at 8:07 AM, Christian Schaller >> > wrote:
>>>
>>> Hi, not sure why Spot hasn't chimed in, but yes this
>>> has been run through legal. Tom and I where on the same
>>> email thread with the laywers.
>>>
>>> I'm assuming it's because he's at RH Summit.  He looked blissfully busy
>>> in the pic I saw, and I assume this has contributed. :)
>>
>> Yes. I've been traveling almost non-stop for a month, so I'm behind on a
>> lot of things. I was involved here, though, much credit is due to
>> Christian and his team for a lot of hard work behind the scenes.
>>
>>
>> The reddit thread and the comments on the Fedora Magazine discussing this
>> had quite a few people highlighting AC3 as no longer being encumbered as
>> well.
>>
>> Is there anything you can share with us on that area too?
>
> a52dec has been packaged in mainline Fedora since late March:
> https://koji.fedoraproject.org/koji/packageinfo?packageID=23992


I missed that news.

Thanks for the pointer - I'll go reply to the relevant comments shortly :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org