Re: Please stop re-adding gtk-update-icon-cache scriptlets (for Fedora)

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2018-01-19 at 07:53 +0100, Alexander Ploumistos wrote:
> Hello Igor,
> 
> On Thu, Jan 18, 2018 at 8:17 PM, Igor Gnatenko
>  wrote:
> > I'm working on removing all this cruft from all our packages (and creating
> > conditionals for all packages which have epel branch).
> 
> Should the scriptlets be removed only in rawhide, or can I apply the
> changes in F26 and F27?

They can be removed for all supported Fedora.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpho4YACgkQaVcUvRu8
X0wGJA/+Lty3qbuqGdk5Fs7nqTtxTIbhHRxDgWMme754jb18TDWcfK//cZMLmmY0
GtLjtyOAGoycGlGuyDkKmRaFfOrukTkXbNdT3/lW6UMh/P0+Fe0JiunZReOWg/e3
2n9P7tONDlXQx1Hwe0h1e3qPkg3xa5Qe2RriMyHz/WQCJsond+kEmWHivW8keD1M
0ZaufWjpUNopfMZwoa0aVhPYsDJH1Dqrj8JU/p33gdqLbEVtebMSjaTB5iCHqzrB
oVTqhOaOwhdmBub4OQdaPzFSdSm/RCzjaM1M5reQlHcs3nbS4c8g7U0hhDbbcKDn
wpR8tBMNsKsoHjZYUj2S0dbmj+RHNj6YIUdClFgGNJ2uazM3+7C/CJZNODqYFO84
TDpU72cQcu/rJRAbY0GVdl8xRQNhOLO6wb5V9zHSMPei+Ri8ywe/SghrRxqne/Aj
xO3QcA4Ox0MdMpHdASJGoHrEO7+zGalLwXv7uki73L6/pA43E2xKzdnMMzQOsaGn
Wn8J03Y5WT1Oy9ofpzP+M4Oa4Wmqf2jTkvrU4YvG01u8eqd+n74m3hROcCXJXkwD
NbpWWOrCsWPbnCUoFa/hqLsDaX2Et72DfWcw7uyj6MYnMed/4p7uw6lK5nmvBPHR
aIuK3y6/lYsrlvDyIFONkezaMk3VrYGPWhljm3AiE/WeDXjgSD0=
=DUS1
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal to remove NetworkManager from Core group

[Thomas Haller]

On Thu, 2018-01-18 at 09:28 +0100, David Demelier wrote:
> Hello all,
> 
> Since systemd-networkd is a mature network system daemon nowadays,
> NetworkManager can be avoided in many cases where people do not need
> desktop features.
> 
> I propose to remove NetworkManager from the “Core” group and mark it
> as
> optional or eventually move it into a dedicated group. Perhaps
> “Common
> NetworkManager Submodules”?
> 
> What do you think?
> 

Hi,


the message doesn't give much motivation beside "can be avoided in many
cases". I would be intrested in your exact criticism.

NetworkManager aims to be a viable solution for nearly all use cases,
and it is (arguably) the only real solution for many. This is the
reason, why I believe NetworkManager by default is the best choice.

NetworkManager cannot be better suited then systemd-netword in every
possible scenario. That's because systemd-networkd is well done and
works stellar in scenarios for which it is intended. But from that it
doesn't logically follow that systemd-networkd is a better fit to use
by default. At least not today and not unless it supports "crazy"
features like:
 - connect to Wi-Fi (without resorting to configuring
   wpa-supplicant files)
 - connect bluetooth or WWan (with reasonable effort)
 - GUI integration
 - VPN support
 - allow non-root users to connect to a network.
 - NetworkManager aims to provide a de-facto standard networking API 
   on D-Bus that other components can use. For example GUIs, Cockpit,
   ansible (still needs improvements), FleetCommander.
Of course, all these features could be provided by networkd too. But
that is a lot of work and years down the road, if ever.

One day networkd probaly will get a D-Bus API, as people are free to
invest work whereever the choose -- of course. But that brings a push
to extend GUIs to handle these backends. The client tools for
networking are already not as great as they could be, mostly due to
lacking man power. The awesome programmer who adds D-Bus API to
networkd won't likely be around to integrate it with client tools. In
the end, this just creates more work when there is already not enough
man power.

I am a NetworkManager developer and don't have objective views. But the
prospect of fragmenting the area more is not appealing to me. We have
NetworkManager, systemd-networkd, ConnMan, wicked, wicd (unmaintained),
and possibly more. You may bet on any of the other tools to catch up
fast and become more awesome the NetworkManager. But let me point out
that NetworkManager is here today and very willing to improve and make
*your* usecase work better.


best,
Thomas

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Please stop re-adding gtk-update-icon-cache scriptlets (for Fedora)

[Alexander Ploumistos]

Hello Igor,

On Thu, Jan 18, 2018 at 8:17 PM, Igor Gnatenko
 wrote:
> I'm working on removing all this cruft from all our packages (and creating
> conditionals for all packages which have epel branch).

Should the scriptlets be removed only in rawhide, or can I apply the
changes in F26 and F27?

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

[389-devel] Please review: cli release prep

[William Brown]

https://pagure.io/389-ds-base/issue/49544

https://pagure.io/389-ds-base/issue/raw/files/fa6bdb774b723acb36c638720
6f5cbb640d1ed9234790700bbc1bdd60fbb0651-0001-Ticket-49544-cli-release-
preperation.patch


-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: libcdio soname bump in rawhide

[Nicolas Chauvet]

2018-01-18 22:25 GMT+01:00 Adrian Reber :
> libcdio upstream released the 2.0 version a few weeks ago and I will
> updated rawhide to the latest libcdio version. It comes with a new
> soname and I will also rebuild all dependencies.

Hi Adrian,

Can you wait a week at least ? We are in the middle of a rebuild in
third part side that might need more time to land.
We won't be able to rebuild the packages in time there.

Thx

-- 
-

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

Re: [Fedora-packaging] Re: RFC: Dropping %{?_isa} hack

[Michael Cronenworth]

On 01/18/2018 06:41 PM, Kevin Kofler wrote:

By the way, is that even still needed? A lot of Windows software is now
native Win64. Is a 64-bit-only WINE really still not workable?


Yes. Yes. There are cases where the 64-bit binary doesn't run and the 32-bit one 
does. There are cases where the software is 32-bit only and no longer supported but 
still needed to export data.


Until Microsoft decides to abandon 32-bit we will still need it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Dropping %{?_isa} hack

[Michael Schwendt]

On Thu, 18 Jan 2018 20:07:27 -0600, Rex Dieter wrote:

> I can 
> dnf install .i686
> 
> and I see no 64bit packages pulled in.

With F27,

  dnf install wine.i686

really pulls in various x86_64 alongside their i686 builds.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Dropping %{?_isa} hack

[Rex Dieter]

Igor Gnatenko wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256

> 
> Does anybody know why we are still using %{?_isa} thing?

To ensure arch's match between subpkgs.

> DNF/libsolv forcefully install 64bit package for any 32bit package in
> transaction. So it is not possible to get 32bit package without 64bit
> counterpart.

I can 
dnf install .i686

and I see no 64bit packages pulled in.

> So then what's the reason of using %{?_isa}? Just some old cruft from yum
> era? Can we drop it? Thoughts?

See above, imo, no, not wise to drop it.

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

Re: [Fedora-packaging] Re: RFC: Dropping %{?_isa} hack

[Kevin Kofler]

Igor Gnatenko wrote:
> Yeah, requiring 32bit package from 64bit one (aka wine) is
> different case (it doesn't really use %{?_isa}) and is valid one.

By the way, is that even still needed? A lot of Windows software is now 
native Win64. Is a 64-bit-only WINE really still not workable?

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

[Bug 1536232] perl-Coro-Multicore-0.03 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
hotness's scratch build of perl-Coro-Multicore-0.03-1.el7.src.rpm for rawhide
failed http://koji.fedoraproject.org/koji/taskinfo?taskID=24281485

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1535735] perl-MongoDB-v1.8.1 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-MongoDB-1.8.1-1.fc27 has been pushed to the Fedora 27 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-4d0ca370cb

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1529277] perl-Locale-SubCountry-2.04 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-Locale-SubCountry-2.04-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-d1df30ae83

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1511913] perl-Crypt-OpenSSL-X509-1.808 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Crypt-OpenSSL-X509-1.808-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-f60dccf200

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1536234] New: perl-BDB-1.92 is available

[bugzilla]

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

Bug ID: 1536234
   Summary: perl-BDB-1.92 is available
   Product: Fedora
   Version: rawhide
 Component: perl-BDB
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: carl@george.computer, jples...@redhat.com,
kwiz...@gmail.com, perl-devel@lists.fedoraproject.org



Latest upstream release: 1.92
Current version/release in rawhide: 1.91-9.fc27
URL: http://search.cpan.org/dist/BDB/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/6715/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1536232] perl-Coro-Multicore-0.03 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1383090
  --> https://bugzilla.redhat.com/attachment.cgi?id=1383090=edit
[patch] Update to 0.03 (#1536232)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1536232] New: perl-Coro-Multicore-0.03 is available

[bugzilla]

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

Bug ID: 1536232
   Summary: perl-Coro-Multicore-0.03 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Coro-Multicore
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.03
Current version/release in rawhide: 0.02-7.fc27
URL: http://search.cpan.org/dist/Coro-Multicore/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/7655/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1047  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 809  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 391  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 289  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 121  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  58  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  22  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8d57a2487b   
monit-5.25.1-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-28611aa33f   
python-bottle-0.12.13-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-885bb5ec89   
poco-1.6.1-3.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-85e532c970   
transmission-2.92-11.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73feedd767   
wordpress-4.9.2-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-11ba3bced1   
clamav-0.99.2-18.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

awstats-7.7-1.el7
cciss_vol_status-1.12-1.el7
inxi-2.3.56-1.el7
libsodium-1.0.16-1.el7
libsodium13-1.0.5-1.el7
php-pecl-libsodium-1.0.7-1.el7
python-docopt-0.6.2-7.el7

Details about builds:



 awstats-7.7-1.el7 (FEDORA-EPEL-2018-f0f33c8487)
 Advanced Web Statistics

Update Information:

Version 7.7 - http://www.awstats.org/docs/awstats_changelog.txt




 cciss_vol_status-1.12-1.el7 (FEDORA-EPEL-2018-299b3e667b)
 Show status of logical drives attached to HP SmartArray controllers

Update Information:

update to new release

References:

  [ 1 ] Bug #1532744 - cciss_vol_status 1.12
https://bugzilla.redhat.com/show_bug.cgi?id=1532744




 inxi-2.3.56-1.el7 (FEDORA-EPEL-2018-ebcf9765e6)
 A full featured system information script

Update Information:

Update to 2.3.56.




 libsodium-1.0.16-1.el7 (FEDORA-EPEL-2018-93f737b65e)
 The Sodium crypto library

Update Information:

This is a coordinated update to bring libsodium current while still providing
the previous version via libsodium13.  See the [mailing list
post](https://lists.fedoraproject.org/archives/list/epel-
de...@lists.fedoraproject.org/thread/PA2Y33V43KI2YOW6PAHL4YWDKP4KW2CT/) for more
details.




 libsodium13-1.0.5-1.el7 (FEDORA-EPEL-2018-93f737b65e)
 Compatibility version of the Sodium crypto library

Update Information:

This is a coordinated update to bring libsodium current while still providing
the previous version via libsodium13.  See the [mailing list
post](https://lists.fedoraproject.org/archives/list/epel-
de...@lists.fedoraproject.org/thread/PA2Y33V43KI2YOW6PAHL4YWDKP4KW2CT/) for more
details.




 php-pecl-libsodium-1.0.7-1.el7 (FEDORA-EPEL-2018-93f737b65e)
 Wrapper for the Sodium cryptographic library

Update Information:

This is a coordinated update to bring libsodium current while still providing
the previous version via libsodium13.  See the [mailing list
post](https://lists.fedoraproject.org/archives/list/epel-
de...@lists.fedoraproject.org/thread/PA2Y33V43KI2YOW6PAHL4YWDKP4KW2CT/) for more
details.

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 919  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 809  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 781  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 391  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 121  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  40  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  22  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6e4ce19598   
monit-5.25.1-1.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-fde8252ab7   
python-bottle-0.12.13-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4   
rootsh-1.5.3-17.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2ba6bfc5d8   
wordpress-4.9.2-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

cciss_vol_status-1.12-1.el6
inxi-2.3.56-1.el6
python-docopt-0.6.2-7.el6

Details about builds:



 cciss_vol_status-1.12-1.el6 (FEDORA-EPEL-2018-55122b4fdc)
 Show status of logical drives attached to HP SmartArray controllers

Update Information:

update to new release

References:

  [ 1 ] Bug #1532744 - cciss_vol_status 1.12
https://bugzilla.redhat.com/show_bug.cgi?id=1532744




 inxi-2.3.56-1.el6 (FEDORA-EPEL-2018-783bce791a)
 A full featured system information script

Update Information:

Update to 2.3.56.




 python-docopt-0.6.2-7.el6 (FEDORA-EPEL-2018-63d13fb654)
 Pythonic argument parser, that will make you smile

Update Information:

- EPEL compatibility, including Python 3 build

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

[389-devel] Please review: Issue 49542 - Unpackaged files on el7 break rpm build

[Viktor Ashirov]

https://pagure.io/389-ds-base/issue/49542

https://pagure.io/389-ds-base/issue/raw/files/b86d47927141e4823eb44826374803435a69a513c45f2b5af59690e88552fc76-0001-Issue-49542-Unpackaged-files-on-el7-break-rpm-build.patch




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

Re: [Fedora-packaging] Re: RFC: Dropping %{?_isa} hack

[Dominik 'Rathann' Mierzejewski]

On Thursday, 18 January 2018 at 23:20, Igor Gnatenko wrote:
> On Thu, 2018-01-18 at 23:04 +0100, Dominik 'Rathann' Mierzejewski wrote:
> > On Thursday, 18 January 2018 at 22:50, Igor Gnatenko wrote:
> > > Hello,
> > > 
> > > Does anybody know why we are still using %{?_isa} thing?
> > > 
> > > DNF/libsolv forcefully install 64bit package for any 32bit package in
> > > transaction. So it is not possible to get 32bit package without 64bit
> > > counterpart.
> > 
> > Huh? You can't be serious. I've been keeping a 32bit-only set of wine
> > packages on my machine for quite some time and I'd be quite annoyed
> > if I suddenly had to install all corresponding 64bit ones, too.
> 
> Well, I am pretty serious. I think you just didn't notice all those 64bit
> packages because you had them already installed.
> 
> $ sudo dnf install wine
> […]
>  libatomic i686   7.2.1-6.fc28rawhide  40 k
>  libatomic x86_64 7.2.1-6.fc28rawhide  40 k
> […]

Wrong. I keep close watch on what packages I have installed. I only have
32bit wine installed at the moment, so your statement seems untrue:
$ rpm -qa wine\* |grep i686 |wc -l
3
$ rpm -qa wine\* |grep x86_64 |wc -l
0

> > When did you implement this change and for which Fedora release?
> 
> Since DNF was implemented?

Apparently it's not implemented like you described.

[...]
> > > So then what's the reason of using %{?_isa}? Just some old cruft from yum
> > > era?
> > > Can we drop it? Thoughts?
> > 
> > The reason is to ensure 64bit subpackages dependency on main package
> > won't be satisfied by a 32bit counterpart and vice-versa. This has
> > always been the case.
> 
> Except that 64bit package is always pulled in → no need for pulling 32bit
> package. Yeah, requiring 32bit package from 64bit one (aka wine) is different
> case (it doesn't really use %{?_isa}) and is valid one.

I never said anything about cross-bitness requirements. You
misunderstood. And I've just demonstrated that dnf doesn't always pull
in 64bit package when 32bit counterpart is being installed.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: RFC: Dropping %{?_isa} hack

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2018-01-18 at 16:58 -0500, Neal Gompa wrote:
> On Thu, Jan 18, 2018 at 4:50 PM, Igor Gnatenko
>  wrote:
> > 
> > Hello,
> > 
> > Does anybody know why we are still using %{?_isa} thing?
> > 
> > DNF/libsolv forcefully install 64bit package for any 32bit package in
> > transaction. So it is not possible to get 32bit package without 64bit
> > counterpart.
> > 
> > So then what's the reason of using %{?_isa}? Just some old cruft from yum
> > era?
> > Can we drop it? Thoughts?
> 
> Actually, libsolv doesn't quite do this all the time in every case.
> There were a few fixes to libsolv post 0.6.30 for handling more
> conditions of it.
> 
> It also avoids weird situations where you get arch switching with
> package splits and obsoletes...

There are flags related to coloring Obsoletes, so that should be fine.

But it seems that if I run $ sudo dnf install wine -x libatomic.x86_64, it
would happily install without it, but on next upgrade -- pull it in..

So it seems that we still need to use %{?_isa}.

Michael, can you give a hint whether we need to use it for weak deps as well?
If so -- in which parts of conditions?
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlphHlAACgkQaVcUvRu8
X0zvhw/+Pkz2uI+gN+3EZgyi4Q5IfwxBsXZSy2OARBDuI53AUjEQ5ikuBDOt9K9X
uFAk0eeY5pTe5VAvYTvomwWFeBk9rkqG2geHzpC1cn+BVN1G6MSz33vdhnEtGGmt
/qeEInfqA0H5Jwxsj3tQlpd3tdedzl3v47gXdQ4eL88C1JbgIEuk1Ik56bwJmlFK
s05c3og5XpvD9dUM4Chqhu2TLixs1hlT7uihW98MxUC4T/gcjgMikE4ZKRnpy1GT
k8P8VLhkjPW/36ud6o8BqpSgI9VUzQkYIbWDsc2tV1HaXfAt+5kDdg6ZEWP9uGQ3
KM9zAppHpscVI8d8sGbXjlaRW1UGv5aotmz46fFpQ+IHr/29JbLt8sWaGvQ2I5Ce
cuiNxk+zBqIAb73v1nYz93T5qr3mZO4GDfb+Oq2FbwcWlzuvzghwkAGpm5ycLEbw
5dfLbM5TpL0G8AyXSN1hxOrkL4Q81phCgEMZYnn0y9PrqfswYPlB0cPlWSS2GFy+
x/MREiGHiUOhma2DIe8iX7XF8k0S2x37zGn66xV8BCHrUP6iBbo3tIAVQ9+e+/V1
zJXav+UNkEdZexa1d6UuGlSNjjXEGhQDIGsr69hnZWIQNmVrCbW6abZdiJCt8KUh
CsVIuYwNcH1kdVF5MQQnJpPpwt57Zvf6inZH7TCwrEmuUQHJTk4=
=sKHb
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1535735] perl-MongoDB-v1.8.1 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-MongoDB-1.8.1-1.fc26 has been pushed to the Fedora 26 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-80f1b2526c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1529277] perl-Locale-SubCountry-2.04 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Locale-SubCountry-2.04-1.fc26 has been pushed to the Fedora 26 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-b812fa98d9

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: RFC: Dropping %{?_isa} hack

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2018-01-18 at 23:04 +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Thursday, 18 January 2018 at 22:50, Igor Gnatenko wrote:
> > Hello,
> > 
> > Does anybody know why we are still using %{?_isa} thing?
> > 
> > DNF/libsolv forcefully install 64bit package for any 32bit package in
> > transaction. So it is not possible to get 32bit package without 64bit
> > counterpart.
> 
> Huh? You can't be serious. I've been keeping a 32bit-only set of wine
> packages on my machine for quite some time and I'd be quite annoyed
> if I suddenly had to install all corresponding 64bit ones, too.

Well, I am pretty serious. I think you just didn't notice all those 64bit
packages because you had them already installed.

$ sudo dnf install wine
[…]
 libatomic i686   7.2.1-6.fc28rawhide  40 k
 libatomic x86_64 7.2.1-6.fc28rawhide  40 k
[…]

> When did you implement this change and for which Fedora release?

Since DNF was implemented?

> Could you point to its announcement?

Well, this particular thing was never discussed (at least to my knowledge).

> > So then what's the reason of using %{?_isa}? Just some old cruft from yum
> > era?
> > Can we drop it? Thoughts?
> 
> The reason is to ensure 64bit subpackages dependency on main package
> won't be satisfied by a 32bit counterpart and vice-versa. This has
> always been the case.

Except that 64bit package is always pulled in → no need for pulling 32bit
package. Yeah, requiring 32bit package from 64bit one (aka wine) is different
case (it doesn't really use %{?_isa}) and is valid one.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlphHZMACgkQaVcUvRu8
X0zBEA/8CbVquwlPiekTezShpDdALFizZnXVBQmymMPAyGt83o7uA4e+CUI3bfup
IEKERY38jsCy1rZOyOWRQU99PNmEtOCHcHQcnWnfbWu3Q1c+fav71U8ZCielBxnA
4zTPENH72n4Y14j7WAaYk3gtsm0xuYl981AFf9Uro1eYw3WDaOzsj+IQ2+EzPtv2
FZ/nk9bxgDbjtgzR2fDAW0F8nBF5t8BpJYPkuFBr/XH/E1A8y9AZFmbcqCENnERY
Iv7RPnbgq5y0C+/6pUtyPpxgX6G8pjTRST4pTSUIg4PkhB16VLOV0kz2vpNMyDg4
VciDF4XZCGP2EcU1TYg3sSrewsjzGU0Ec2bQdPIXXKkZGqTi5WgJ2SLGZtHx2ge5
6vkh0pgc06v8BWioi2D2K/j1u6zxGettw1U5/2z9fn9qY/8ZDQeyV7YHtfcsPX/F
wsX/752yFzvTy8YUOkhIkxBrgM+a9EWuB8+egnCGicLKkrIvRB6D+OYTynTQKTJA
G1f1Z9q2kQvHQ/s57enfFAIOOstYY0AifayzlVHqNtzjuvprliHrRilyIZgmXSEH
50IUB7X0+smz9hSlpED4DEXQikBKb03G2uEivj3wgPcznfNYk1M2hPsiy9N3qYPG
n5q/OcbjDrM3GXTf++QHlB0NAD43EtACgm46L/DhXfcSJtpnuLs=
=/s7a
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Orphaned perl-IPTables-ChainMgr and perl-IPTables-Parse

[Dominik 'Rathann' Mierzejewski]

On Thursday, 18 January 2018 at 15:06, Robert-André Mauchin wrote:
> On jeudi 18 janvier 2018 14:31:17 CET Miloslav Trmac wrote:
> > Hello,
> > I have orphaned perl-IPTables-ChainMgr and perl-IPTables-Parse .
> > Mirek
> 
> I need perl-IPTables-ChainMgr for a package that is currently being reviewed 
> (Ravada [1]), can you transfer the ownership of both to me (fas: eclipseo)?

Please add me as co-maintainer, they're dependencies of one of my
packages, too.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Dropping %{?_isa} hack

[Dominik 'Rathann' Mierzejewski]

On Thursday, 18 January 2018 at 22:50, Igor Gnatenko wrote:
> Hello,
> 
> Does anybody know why we are still using %{?_isa} thing?
> 
> DNF/libsolv forcefully install 64bit package for any 32bit package in
> transaction. So it is not possible to get 32bit package without 64bit
> counterpart.

Huh? You can't be serious. I've been keeping a 32bit-only set of wine
packages on my machine for quite some time and I'd be quite annoyed
if I suddenly had to install all corresponding 64bit ones, too.

When did you implement this change and for which Fedora release?
Could you point to its announcement?

> So then what's the reason of using %{?_isa}? Just some old cruft from yum era?
> Can we drop it? Thoughts?

The reason is to ensure 64bit subpackages dependency on main package
won't be satisfied by a 32bit counterpart and vice-versa. This has
always been the case.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] RFC: Dropping %{?_isa} hack

[Neal Gompa]

On Thu, Jan 18, 2018 at 4:50 PM, Igor Gnatenko
 wrote:
>
> Hello,
>
> Does anybody know why we are still using %{?_isa} thing?
>
> DNF/libsolv forcefully install 64bit package for any 32bit package in
> transaction. So it is not possible to get 32bit package without 64bit
> counterpart.
>
> So then what's the reason of using %{?_isa}? Just some old cruft from yum era?
> Can we drop it? Thoughts?

Actually, libsolv doesn't quite do this all the time in every case.
There were a few fixes to libsolv post 0.6.30 for handling more
conditions of it.

It also avoids weird situations where you get arch switching with
package splits and obsoletes...

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

RFC: Dropping %{?_isa} hack

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

Does anybody know why we are still using %{?_isa} thing?

DNF/libsolv forcefully install 64bit package for any 32bit package in
transaction. So it is not possible to get 32bit package without 64bit
counterpart.

So then what's the reason of using %{?_isa}? Just some old cruft from yum era?
Can we drop it? Thoughts?
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlphFsEACgkQaVcUvRu8
X0yk2Q//WT0Xn+kV+HgnM10a1jD9/c4gtjaDNRFrxhs3oPx0J6kEC/IeAWNjLgE0
1+iJwE6bcz40Ee9SLmHnRVqzDmWpBVwm57lN8jid9DE/yiTe3SyKqk//ysTIFFgG
mvll4BqtxDC2fXpJSlgdq62tI2cvD5qHRlTmi7HRy+Do+G57nRDuTpQdVqTbRpDt
inL8ICAb4zhyrjlr0Sc5AQSy6uHNd8opDlrTSaOKR0+jSrXTbHZ17R40F0S53xQg
Qeb13nl7AqNC3WsVtPvdWgSRcjFsDtvakVipmgzOywxr+Q56iG0LaUBA57Wmixtz
yoa2KckuvRNbSFltGlqa4bHR71A/PbVy3JaHI+PzkJWL1UcSSji8vVGTmB4rwiai
xe8YlkyfU0VDbpnW3mcqXrZ2gApt6YyZdRHSvbVSi05My7J7jPlS6Qf8Xx7aqSQq
pN6cZhp796fPy53i0TKUf5UWE5pdLfhxFc0D8NGIzwF9U3U00GM43dzDk6PSGzlo
4d8U4K6CteScJWCO+xafGkCU3VGaMu7YnJDLzn5d1XD/7azpyG7zfa2a28wGHuGj
FoNoGIQG/exk3HADECSg7ITe5yCMm8PUbP1ZSrRKHzoYVeCAwRafMn6C6KTwfIUc
NTrb2Jt3Io7d1qJdxoNT5c3jJPftO9aOh23oPyfLLacygImWD6k=
=Vudn
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

libcdio soname bump in rawhide

[Adrian Reber]

libcdio upstream released the 2.0 version a few weeks ago and I will
updated rawhide to the latest libcdio version. It comes with a new
soname and I will also rebuild all dependencies.

Adrian


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

Re: Pulling in rpmfusion appstream data with weak dependencies?

[Matthew Miller]

On Thu, Jan 18, 2018 at 09:38:13PM +0100, Nicolas Chauvet wrote:
> >> Recommends: (other-repo-appstream if (PackageKit or gnome-software))
> 
> I wondered that too at one point. But It would lead to a race. The dnf
> .repo files would not be installed yet, and then the
> rpmfusion-*appdata couldn't be found.

Oh yeah, good point. :-/

> Maybe it will work on the next dnf transaction ? If someone could test ?

Well, if you make a new version of the -release package every day
:)

-- 
Matthew Miller

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

Re: Status of SWDB (Unified database for DNF)

[Greg Evenden]

will it be ready by F29? or are would it be best to look at pulling it into F30 
instead ? 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pulling in rpmfusion appstream data with weak dependencies?

[Nicolas Chauvet]

2018-01-18 20:21 GMT+01:00 Neal Gompa :
> On Thu, Jan 18, 2018 at 2:19 PM, Matthew Miller
>  wrote:
>> On Thu, Jan 18, 2018 at 01:02:49PM -0600, Dennis Gilmore wrote:
>>> The only way to really do this would be to make rpmfusion-release
>>> require it. However that will mean users have to download and install
>>> two packages to make it all work. That may break things for people who
>>> intentionally remove gnome-software and PackageKit
>>
>> Does DNF process new Recommends? The -release package could Recommend
>> it rather than Require it. In fact, couldn't it even do:
>>
>> Recommends: (other-repo-appstream if (PackageKit or gnome-software))

I wondered that too at one point. But It would lead to a race. The dnf
.repo files would not be installed yet, and then the
rpmfusion-*appdata couldn't be found.
Maybe it will work on the next dnf transaction ? If someone could test ?


-- 
-

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

Re: Pulling in rpmfusion appstream data with weak dependencies?

[Nicolas Chauvet]

2018-01-18 20:02 GMT+01:00 Dennis Gilmore :
> The only way to really do this would be to make rpmfusion-release
> require it. However that will mean users have to download and install
> two packages to make it all work. That may break things for people who
> intentionally remove gnome-software and PackageKit

That would indeed not scale for cases where appdata are not relevant
(others spins, server, headless multimedia, etc).
I would like to avoid such miss-design where we would need to split
into rpmfusion-*-release-workstation or other products. It would just
move the problem without fixing it.

At which point it would be just easier to add the complementary
appdata packages to install along the rpmfusion-*-release packages
from our "Configuration" page.

One other method is to use Groups. The rpmfusion*-appdata files could
be added to the appropriate comps group. That way it will be a matter
to update the group after the releases packages are installed.
This is similar than what can be done for multimedia with a "dnf
groupupdate Multimedia". It would need to be updated manually (which I
beleive was done automatically with earlier release but it's not the
point anymore).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pulling in rpmfusion appstream data with weak dependencies?

[Matthew Miller]

On Thu, Jan 18, 2018 at 08:47:49PM +0100, Igor Gnatenko wrote:
> > > > Recommends: (other-repo-appstream if (PackageKit or gnome-software))
> > Thanks -- I thought so but was too lazy to check at the moment. So the
> > above should do it, right?
> Recommends are not different from Supplements. They still have same
> behavior as Ankur mentioned. We need to fix this rather than trying
> to workaround it (also given that proposed workaround won't work).

Maybe I don't understand what you're saying. The problem Ankur
mentioned is because he's trying to make one package supplement
another, and that is only processed if that other package is updated.
But here, putting it in the release package would make that release
package be updated (by tautology -- an update is an update), and so the
Recommends would be processed when people get that update. And if
PackageKit or gnome-software is installed, they'd get the
other-repo-appstream package pulled in too, right? (I guess that could
also be "Recommends: other-repo-appstream if appstream".)

Sure, it'd be semantically nicer to have other-repo-appstream have a
supplements relationship with the fedora appstream package in the
package directly, but I don't think that having the release package
recommend it is semantically wrong, either, so I don't think it's right
to call this a "workaround", exactly. It's a different way to do the
same thing which, hey, should work, right?


-- 
Matthew Miller

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

Schedule for Friday's FESCo Meeting (2018-01-19)

[Adam Miller]

Following is the list of topics that will be discussed in the
FESCo meeting Friday at 16:00UTC in #fedora-meeting on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2018-01-19 16:00 UTC'


Links to all issues below can be found at:
https://pagure.io/fesco/report/meeting_agenda

= New business =

= New business =

#topic #1767 F28 Self Contained Changes
.fesco 1767
https://pagure.io/fesco/issue/1767

#topic #1803 F28 System Wide Change: Reduce Initial Setup Redundancy
.fesco 1803
https://pagure.io/fesco/issue/1803

#topic #1814 F28 System Wide Change: Anaconda Modularization
.fesco 1814
https://pagure.io/fesco/issue/1814

#topic #1815 F28 System Wide Change: Make authselect default tool
instead of authconfig
.fesco 1815
https://pagure.io/fesco/issue/1815

#topic #1816 F28 System Wide Change: Glibc collation update and sync with cldr
.fesco 1816
https://pagure.io/fesco/issue/1816

#topic #1817 F28 System Wide Change: golang 1.10
.fesco 1817
https://pagure.io/fesco/issue/1817

#topic #1818 F28 System Wide Change: Kerberos in Python modernization
.fesco 1818
https://pagure.io/fesco/issue/1818

#topic #1819 F28 System Wide Change: Removal of Sun RPC Interfaces from glibc
.fesco 1819
https://pagure.io/fesco/issue/1819

#topic #1822 F28 System Wide Change: AArch64 Server Promotion
.fesco 1822
https://pagure.io/fesco/issue/1822

#topic #1823 F28 System Wide Change: mpfr-4.0.0
.fesco 1823
https://pagure.io/fesco/issue/1823

#topic #1824 F28 System Wide Change: Binutils version 2.29.1
.fesco 1824
https://pagure.io/fesco/issue/1824

#topic #1825 F28 System Wide Change: Add-On Modularity
.fesco 1825
https://pagure.io/fesco/issue/1825

#topic #1826 F28 System Wide Change: Boost 1.66 upgrade
.fesco 1826
https://pagure.io/fesco/issue/1826

#topic #1827 F28 System Wide Change: GCC8
.fesco 1827
https://pagure.io/fesco/issue/1827

#topic #1828 F28 System Wide Change: The GNU C Library version 2.27
.fesco 1828
https://pagure.io/fesco/issue/1828

#topic #1829 F28 System Wide Change: The GNU C Library version 2.27
.fesco 1829
https://pagure.io/fesco/issue/1829

#topic #1830 F28 System Wide Change: NIS switching to new libnsl to support IPv6
.fesco 1830
https://pagure.io/fesco/issue/1830

#topic #1831 F28 System Wide Change: OpenLDAP defaults to use only
Shared System Certificates
.fesco 1831
https://pagure.io/fesco/issue/1831

#topic #1832 F28 System Wide Change: OpenLDAP without Non-threaded Libraries
.fesco 1832
https://pagure.io/fesco/issue/1832

#topic #1833 F28 System Wide Change: Replace glibc's libcrypt with libxcrypt
.fesco 1833
https://pagure.io/fesco/issue/1833

#topic #1834 F28 System Wide Change: Rename "nobody" user
.fesco 1834
https://pagure.io/fesco/issue/1834

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Please stop re-adding gtk-update-icon-cache scriptlets (for Fedora)

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2018-01-18 at 19:45 +, Sérgio Basto wrote:
> On Thu, 2018-01-18 at 20:17 +0100, Igor Gnatenko wrote:
> > Hello,
> > 
> > I'm working on removing all this cruft from all our packages (and
> > creating
> > conditionals for all packages which have epel branch).
> > Unfortunately some maintainers adding them back with conditionals
> > like:
> > %if 0%{?fedora} < 28 || 0%{?rhel} < 8
> > 
> > 1. Those scriptlets are not needed since ~ F24 era
> > 2. You might not know, but 0%{?rhel} on Fedora evaluates to "0" which
> > is "< 8",
> > so those scriptlets are active.
> > 
> > Also forgive me if your package had some EL* specific conditions and
> > I removed
> > scriptlets (because there was no epel* branch) -- please use
> > %if 0%{?rhel} && 0%{?rhel} <= 7
> > 
> > for them.
> 
> Hello , 
> BTW I have some questions on how exactly we should deal with EPEL 7 and
> 6, from old wiki page [1] desktop-database and  mimeinfo  have been
> removed and Icon cache too ?  IMHO these info should still be in wiki
> and not deleted, maybe also should explain the status on EPEL versions 
> ... 

It now lives on separate page: https://fedoraproject.org/wiki/EPEL:Packaging?rd
=Packaging:EPEL#Scriptlets

> Maybe more correct scriptlet is: 
> %if 0%{?fedora} < 25 && 0%{?rhel} < 8

1. F24 is EOL for long time, absolutely no need to include that in scriptlets.
2. Leaving just %if 0%{?rhel} < 8 is wrong because essentially it is %if 0 < 8,
you need to use %if 0%{?rhel} && 0%{?rhel} < 8 instead.

> And about appdata how exclude it from EPEL 6 ? 
> 
> %if 0%{?rhel} > 6 || 0%{?fedora} ? 

To be honest, I prefer using %if ! (0%{?rhel} && 0%{?rhel} <= 6), because
everything except RHEL6 supports metainfo/appdata (not rhel7+ and fedora).
There are people using same specs (from Fedora), for example in Mageia. I don't
think that we should make their life more complicated. Even if you don't care
about them, it's not big deal to write "forward looking conditional" I think.

> I'd like that we have some "official" scriptlets for that. 
> 
> Best regards and thanks.
> 
> [1]
> https://fedoraproject.org/w/index.php?title=Packaging:Scriptlets=468484
> #mimeinfo

Obviously, I can't force you to do it this way, but I think that this is good
practice.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpg/asACgkQaVcUvRu8
X0yATA/+L4qZSvuM4lNxtrpquhToYtcYjOtuYCqiHRVZyZkNRuCHin4plEzS/dTw
mECQmKKmOChtZQi1JsJPwiCgy8NwAurI8Mdfxh3LD9hRVBwzWga6idh4w5wRBbK4
lPjmSfTBmuRhVr8yn0hpPhpiFaQLyfFC/nClQ2BLzL97i/LSfAT6O6qR5z8a37uP
luD9HJ1wjTryCGYUPvz3KLMGrylz/ftu7jwwMhwf7HcA8Rr5wR2ZoRXxOjTuEdUR
bmgMaxgijv+DH/whwDc34RXk6xyMWdSuPgS4gh4Kv6mnxX3K6POAGoOrxysJyYsW
ZG70+cV8gooQYL3dp8BvPdDAfKJDncSFS46GYp0nOmlNvk2qVK98x4740uVpV5vo
NxmoVd0EfLaiTD/jTtQdPND44s+R8nB8a/GNId7xBTp7GOfJhKRndwsQj01qgy00
Mw3iApsoTb13N1PqoJnt/hUFe45hTHXuYJWCtSM3dEJBe+bmbFQSMI5Kw9jM5aWg
i7hJRaop4ygvPjidIDG2688XI+h4BLS1JDPfoq030bA1zvJbs4VtndlPa17NlHgb
sO8YsLzTiA/QSouIfyORVKeCLD5cwS34B/ma3MuaFSmDCB9LPdpuZwsXBtbocKht
oSDDfb3GPzcSmFam8r4UwJPxSqXrwsp/Ow3W27R1sbtjdss2ADY=
=8zON
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pulling in rpmfusion appstream data with weak dependencies?

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2018-01-18 at 14:34 -0500, Matthew Miller wrote:
> On Thu, Jan 18, 2018 at 02:21:35PM -0500, Neal Gompa wrote:
> > > Does DNF process new Recommends? The -release package could Recommend
> > > it rather than Require it. In fact, couldn't it even do:
> > > Recommends: (other-repo-appstream if (PackageKit or gnome-software))
> > 
> > It does.
> 
> Thanks -- I thought so but was too lazy to check at the moment. So the
> above should do it, right?

Recommends are not different from Supplements. They still have same behavior as
Ankur mentioned. We need to fix this rather than trying to workaround it (also
given that proposed workaround won't work).
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpg+eUACgkQaVcUvRu8
X0wzBg/9E6sdraG5Sjtqlh/Nz6gi9jvZOHvs9UIGPEzZYZBafuotZ7leRAPfiTGr
6LC5303zt8YF+e+QFj2PPbkovqZxrheySDMvmSE+ihFG8g5WVYrUgJZ7RmfUuJxs
e5vqWwhy3HaEcbq4IlkMuU5GdVsC/y0i0H8B3CbEzFuEiWIeFyqn4R/1973rWjd8
6u+fDfxxFi8I4xxapFMkItkWdJ7XuZckI7lc5aT/WPcVJSSfMpo2gXbZdbCrIvtN
sIhYTa+y0eJ/qJis+beJe9i50FDkeT/OBiPo24OcaOaVkvCPxRoC/5i8XIgs5gTa
LB0MUFwcMw07Sy3yCghgD2Vi9RMp9/AFtgBhdbaWbJXAvgZUM+Xj3e6CzdMoh5gR
KN0HWW9BjH3KPa5UQSDE/93p+3jtAvD0iHFlscJfcbk7umtsd9qqUaUDeZztEbvD
sZpAq3HIBvRw8W1Qg4qzs8uZUoG8ERjq8Gj24TvmzueAclelROdwVzgCTVB6y6c2
5mnyvbGO4ZFZAwygPC1ic0OqbO3U8ZPtzcW3AzorlgBOR48PEl1jcWzk3KUdggqb
+J2xvXBiFUCJkEc/cv6rGHVwQSZISqy21hFqymRyICj9yAU+bWXykxOKTHsaSZe9
Eis2xd3a6/toXx4VQkOAV6a94Q8G+jWVpX0l19DVFLMfl7oZ6WQ=
=aInv
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Please stop re-adding gtk-update-icon-cache scriptlets (for Fedora)

[Sérgio Basto]

On Thu, 2018-01-18 at 20:17 +0100, Igor Gnatenko wrote:
> Hello,
> 
> I'm working on removing all this cruft from all our packages (and
> creating
> conditionals for all packages which have epel branch).

> Unfortunately some maintainers adding them back with conditionals
> like:
> %if 0%{?fedora} < 28 || 0%{?rhel} < 8
> 
> 1. Those scriptlets are not needed since ~ F24 era
> 2. You might not know, but 0%{?rhel} on Fedora evaluates to "0" which
> is "< 8",
> so those scriptlets are active.
> 
> Also forgive me if your package had some EL* specific conditions and
> I removed
> scriptlets (because there was no epel* branch) -- please use
> %if 0%{?rhel} && 0%{?rhel} <= 7
> 
> for them.

Hello , 
BTW I have some questions on how exactly we should deal with EPEL 7 and
6, from old wiki page [1] desktop-database and  mimeinfo  have been
removed and Icon cache too ?  IMHO these info should still be in wiki
and not deleted, maybe also should explain the status on EPEL versions 
... 

Maybe more correct scriptlet is: 
%if 0%{?fedora} < 25 && 0%{?rhel} < 8

And about appdata how exclude it from EPEL 6 ? 

%if 0%{?rhel} > 6 || 0%{?fedora} ? 

I'd like that we have some "official" scriptlets for that. 

Best regards and thanks.

[1]
https://fedoraproject.org/w/index.php?title=Packaging:Scriptlets=468484#mimeinfo

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pulling in rpmfusion appstream data with weak dependencies?

[Matthew Miller]

On Thu, Jan 18, 2018 at 02:21:35PM -0500, Neal Gompa wrote:
> > Does DNF process new Recommends? The -release package could Recommend
> > it rather than Require it. In fact, couldn't it even do:
> > Recommends: (other-repo-appstream if (PackageKit or gnome-software))
> It does.

Thanks -- I thought so but was too lazy to check at the moment. So the
above should do it, right?

-- 
Matthew Miller

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

Building Fedora modules on EL [was Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly]

[Matthew Miller]

On Thu, Jan 18, 2018 at 02:09:26PM -0500, Josh Boyer wrote:
> > Given that Python 2 is going EOL in about two years, I don't think we
> > want it in EPEL proper. If we do provide it, it should be in a module.
> You're referring to EPEL > 7, right? 

For Python, yes.

>   Also, that last part is kind of
> a leap in assumption.  Perhaps it's because I'm not up to speed on
> EPEL plans, but do we have timelines for when/if modules will be
> created for and available for EPEL?

It's the plan of record that by default, all modules will be built
across all available buildroots. I'm not sure if that means EPEL7 will
be an available option for technical reasons, but I hope so. This will
possibly require a modular-capable DNF in EPEL proper or in a side-repo
of some sort -- TBD. But if that works, we'll start having modular
content for EL right along with the F28 release.

If not, it'll have to wait for the "higher than 7" RHEL release, but
should be able to enable module building for that pretty quickly once
the target OS is available.

I know that many of us Fedora packagers stay away from EPEL, but at
least for me, that's largely because I'm not confident about committing
to the long lifecycle, because to keep packages stable I'd have to
diverge from Fedora, and because rpm abilities lag so much.

With modules, the first two concerns are handled (because I can
maintain my modules with whatever commitments I feel comfortable with,
even with an EL target). And at least initially the RPM/DNF functionality
should be on par with modern Fedora.

-- 
Matthew Miller

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

Re: Pulling in rpmfusion appstream data with weak dependencies?

[Neal Gompa]

On Thu, Jan 18, 2018 at 2:19 PM, Matthew Miller
 wrote:
> On Thu, Jan 18, 2018 at 01:02:49PM -0600, Dennis Gilmore wrote:
>> The only way to really do this would be to make rpmfusion-release
>> require it. However that will mean users have to download and install
>> two packages to make it all work. That may break things for people who
>> intentionally remove gnome-software and PackageKit
>
> Does DNF process new Recommends? The -release package could Recommend
> it rather than Require it. In fact, couldn't it even do:
>
> Recommends: (other-repo-appstream if (PackageKit or gnome-software))
>

It does.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pulling in rpmfusion appstream data with weak dependencies?

[Matthew Miller]

On Thu, Jan 18, 2018 at 01:02:49PM -0600, Dennis Gilmore wrote:
> The only way to really do this would be to make rpmfusion-release
> require it. However that will mean users have to download and install
> two packages to make it all work. That may break things for people who
> intentionally remove gnome-software and PackageKit 

Does DNF process new Recommends? The -release package could Recommend
it rather than Require it. In fact, couldn't it even do:

Recommends: (other-repo-appstream if (PackageKit or gnome-software))


-- 
Matthew Miller

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

Please stop re-adding gtk-update-icon-cache scriptlets (for Fedora)

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

I'm working on removing all this cruft from all our packages (and creating
conditionals for all packages which have epel branch).

Unfortunately some maintainers adding them back with conditionals like:
%if 0%{?fedora} < 28 || 0%{?rhel} < 8

1. Those scriptlets are not needed since ~ F24 era
2. You might not know, but 0%{?rhel} on Fedora evaluates to "0" which is "< 8",
so those scriptlets are active.

Also forgive me if your package had some EL* specific conditions and I removed
scriptlets (because there was no epel* branch) -- please use
%if 0%{?rhel} && 0%{?rhel} <= 7

for them.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpg8tMACgkQaVcUvRu8
X0zKKBAAtP//zuHBUcVcG8Wy/9he/+od1wjsLlO+Fs29YiXAB7YsHk0f3dM0FM71
o76tFWFy4G0ZuQw3trDkcXKxf2aTDRUAzgvh7JFUPo4tM3SJYcjYixWsxYTsKAb6
murTQQGMeyv2H3YYdudMKGXBBnjgcg1hYwi8c42IKR4Zlt1qxHgNde6F2NGmddWF
tGl8P8ZrXdQ/IJYIvodGM79Ch6d5FEH/nPWNOqsKqHRuxbW/pOvD/UDA8ZWw7JNx
anSOte/LnEwbTkyFZgNJlR8bK5xa7kNwPaOJmSRGtkN9vAMu5+bjnQ33fvMcNlw/
BQl7PZXj/WIbtRECh3PYVtgWVU7DU2zt5sB9wjYN41zuWJcvb3dzPvf7qNUuV+ST
uBJl/XUrM1r6K0h9jJzuApwM/nP7/syVv75Fp6E6yHIrfl28W9elpopcB2E3XGSx
paJOm+SzEurEwYTDGUDnTabl/WQ48PRKAf9H6BXntfbcRXyFoNbfo2rp8BZ8GGvy
lKgNLrsqW4qCGabmTup/WmDF09R4PyVIkp94Z3UtuOtnwoct2/iDLiY0JhrmaN3e
f9TIbBSapZD81We6w75IJrQVVQWAewQJ61FvEM7/n6Q+jqulrassgfjERwXkcHHI
6/T2GQsUl1nMTJS2UaHXhLC8eFENXZNiKmjhuNydyuhkFm0ygv0=
=2zPE
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

[Josh Boyer]

On Thu, Jan 18, 2018 at 1:45 PM, Matthew Miller
 wrote:
> On Thu, Jan 18, 2018 at 07:32:07PM +0100, Miro Hrončok wrote:
>> Once there is a new EPEL version out there, it is very likely both
>> pythons will be available there as well.
>
> Given that Python 2 is going EOL in about two years, I don't think we
> want it in EPEL proper. If we do provide it, it should be in a module.

You're referring to EPEL > 7, right?  Also, that last part is kind of
a leap in assumption.  Perhaps it's because I'm not up to speed on
EPEL plans, but do we have timelines for when/if modules will be
created for and available for EPEL?

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

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

[Stephen John Smoogen]

On 18 January 2018 at 13:45, Matthew Miller  wrote:
> On Thu, Jan 18, 2018 at 07:32:07PM +0100, Miro Hrončok wrote:
>> Once there is a new EPEL version out there, it is very likely both
>> pythons will be available there as well.
>
> Given that Python 2 is going EOL in about two years, I don't think we
> want it in EPEL proper. If we do provide it, it should be in a module.
>

It has been requested by multiple people to go into EPEL proper. I
honestly don't expect any uptake on modules in EPEL land until
RHEL-8.2 in the same way that other Fedora items from 18 weren't
wanted by people until it had 'solidified' in RHEL-7.3. Modules are
something which is landing in the distro just now and we aren't
shipping a working distro that Enterprise people can say "Oh that
would be useful".. at the moment they will just reply "That's horse
pucky" because it is the default answer to vendor software until
proven otherwise.

Modules will get used, but I expect that the majority of initial users
will just want what they had before.. with just newer versions. My
current idea is to have python27 from RHEL-7 for as long as RHEL-7 is
around. It would either sit in /usr/bin or /opt/epel depending on what
is easier for developers. It is the standard issue with the
innovator's dilemna. The audience we know we have wants things like
they had because they have already sunk costs in it. We have to find
the new audience that wants the innovation versus expecting the
existing one to use it OR that the new one will come to us.

> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: Pulling in rpmfusion appstream data with weak dependencies?

[Dennis Gilmore]

The only way to really do this would be to make rpmfusion-release
require it. However that will mean users have to download and install
two packages to make it all work. That may break things for people who
intentionally remove gnome-software and PackageKit 

Dennis

El mar, 16-01-2018 a las 18:08 +, Ankur Sinha escribió:
> Hello,
> 
> We're generating appstream data for rpmfusion packages nowadays to
> enable users to install packages from there using gnome-software and
> friends too.
> 
> Is there a way to automatically pull in the rpmfusion appstream data
> packages? We looked at weak dependencies, specifically backward
> dependencies. So, we added:
> 
> Supplements:appstream-data
> 
> to the rpmfusion appstream data spec files. However, based on my
> understanding of how these things work, this implies that the
> rpmfusion
> appstream data packages are pulled into a transaction only if the
> fedora
> appstream data package is being installed or updated too. Is that
> right?
> 
> If it is, is there a way to pull in rpmfusion appstream data if
> fedora
> appstream data is already installed on the system, and not part of
> the
> current transaction? Any suggestions on how this should be done?
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

[Matthew Miller]

On Thu, Jan 18, 2018 at 07:32:07PM +0100, Miro Hrončok wrote:
> Once there is a new EPEL version out there, it is very likely both
> pythons will be available there as well.

Given that Python 2 is going EOL in about two years, I don't think we
want it in EPEL proper. If we do provide it, it should be in a module.

-- 
Matthew Miller

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

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

[Miro Hrončok]

On 18.1.2018 19:16, Stephen Gallagher wrote:



On Thu, Jan 18, 2018 at 12:12 PM Petr Viktorin > wrote:


On 01/17/2018 12:38 PM, Richard W.M. Jones wrote:
 > On Thu, Jan 11, 2018 at 01:02:32PM -0800, Troy Dawson wrote:
 >> Hello,
 >> Python3 will be in the next major RHEL release.  I don't mean RHEL
 >> 7.6, but with numbers higher than 7.
 >> There are many, many packages with something like the following
 >>
 >>    if 0%{?fedora}
 >>     %define with_python3 1
 >>    %endif
 >>
 >> If you have something like that, please change it to something
like this.
 >>
 >>    if 0%{?fedora} || 0%{?rhel} > 7
 >>     %define with_python3 1
 >>    %endif
 >
 > I'll say it once again, but why can't we just have
 > %{python2_available} and %{python3_available} macros defined in the
 > base system?

Mostly because we can't change RHEL.

So, how about %{python2_missing} and %{python3_available}? Is that too
ugly and inconsistent?



We don't need to change RHEL. We just need to add %{python2_available} 
to the epel-srpm-macros package. Or am I missing something? Yes, this 
will only work for packages built against EPEL 7 and not for third-party 
build-systems, but that's not something we have to care about, is it?


Well there's python3 and python2 available in all EPEL versions and all 
Fedora versions.


Once there is a new EPEL version out there, it is very likely both 
pythons will be available there as well.


What am I missing?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: libsodium upgrade for EPEL7

[Carl George]

Thanks for the feedback Neal.  I have submitted the update.

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-93f737b65e
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Writing Documentation for Fedora - Docs FAD

[Brian Exelbierd]

We are looking for interested people who are willing to write docs in person 
for one week. You don't have to be an existing docs team member to participate. 
It helps if you're familiar with AsciiDoc, but if you're not, it's easy to 
learn.

You'll hang out with other people interested in making Fedora documentation the 
best in the world. Fun will be had, but mostly it will be the sort of fun which 
involves sitting in a small room intensely focused on writing and editing. If 
that's *your* idea of a good time, this will be a good experience for you.

You can find details about the FAD, including the goals here: 
https://fedoraproject.org/wiki/FAD_Documentation_2018

The Fedora Council has approved funding and we will make selections based on 
the ability to the person asking and within our approved travel budget.  
https://pagure.io/Fedora-Council/tickets/issue/174

Interested?  Open a Pagure ticket in the Fedora Docs tracker here: 
https://pagure.io/fedora-docs

Please include:

- Your Name/FAS
- Why you want to come and what your background in writing (of any kind) is.
- Any specific areas of interest
- Location you will travel from

We will start picking people ASAP.

Thanks,

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

Re: Proposal to remove NetworkManager from Core group

[Stephen John Smoogen]

On 18 January 2018 at 03:28, David Demelier  wrote:
> Hello all,
>
> Since systemd-networkd is a mature network system daemon nowadays,
> NetworkManager can be avoided in many cases where people do not need
> desktop features.
>
> I propose to remove NetworkManager from the “Core” group and mark it as
> optional or eventually move it into a dedicated group. Perhaps “Common
> NetworkManager Submodules”?
>
> What do you think?
>

If you are looking for a change in Fedora 28, then that train has left
the station as this would be a large change. For a Fedora 29 change it
is possible to look at if a lot of code is written to allow all the
existing systems to 'upgrade' smoothly and a user can configure their
system cleanly with it. That is a lot of work and would need to land
in 7-9 months to be seen as a viable attempt. That means you need to
start working on this for probably Fedora 30.

1. Identify the legacy software which is looking for methods that
NetworkManager had to implement. [Yes they are from the 90's.. no they
aren't going away.]
2. Identify the methods to get them to work with systemd-network
3. Identify the various items which come up a lot for required needs.
NetworkManager had to do a TON of backfill which took many many many
releases to implement. This was because Linux gets used in a LOT of
different methods and those are still expected to work. Everything
from routing to infiniband to various failover routing, etc. [Going
over the old 2009-2015 time frame of "why can't NetworkManager be
default yet?" would be useful.]
4. Make sure there is a configuration tool which can deal with a
majority of those. It doesn't need to be 100%.. NetworkManager finally
took over when it was probably 80% coverage.
5. Realize that you are going to spend at least N releases with
NetworkManager as a copilot.
6. Deal with a lot of backlash and whipping over every little network
problem being now linked with your tool. The original NetworkManager
people were quite surprised that they would get blamed for DNS
problems in Australia causing routing problems in EU.. but it happens
a lot. They worked through that and pushed it through.

That is probably a 1000 kilometer high window of what it will take to
get it into most OS's (except for Arch).


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



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

Re: LizardFS NFS Ganesha integration with no shared library available

[Kaleb S. KEITHLEY]

On 01/18/2018 01:16 PM, Kaleb S. KEITHLEY wrote:
> On 01/18/2018 03:23 AM, Jonathan Dieter wrote:
>> (This is meant for the Fedora devel mailing list, but I've cc'd the
>> nfs-ganesha mailing list in the hopes that they might see something I'm
>> missing)
>>
>> The latest release of the LizardFS distributed filesystem includes a
>> FSAL for NFS Ganesha, allowing you to mount a LizardFS filesystem using
>> NFS (or pNFS, if you prefer).
> 
> The LizardFS FSAL is GPLv3.  NFS-Ganesha is LGPLv3+.
> 
> From a Fedora packaging standpoint is it acceptable to build a GPLv3
> plug-in for an otherwise LGPLv3+ binary?
> 
> If the licenses were reversed, I'd be reasonably confident that that
> combination is okay.
> 
> What sayeth our "I'm not a lawyer but I play one on Fedora Devel mailing
> list" legal beagles?

And yes, I've already sent a query to a Real Lawyer™

-- 

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

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

[Stephen Gallagher]

On Thu, Jan 18, 2018 at 12:12 PM Petr Viktorin  wrote:

> On 01/17/2018 12:38 PM, Richard W.M. Jones wrote:
> > On Thu, Jan 11, 2018 at 01:02:32PM -0800, Troy Dawson wrote:
> >> Hello,
> >> Python3 will be in the next major RHEL release.  I don't mean RHEL
> >> 7.6, but with numbers higher than 7.
> >> There are many, many packages with something like the following
> >>
> >>if 0%{?fedora}
> >> %define with_python3 1
> >>%endif
> >>
> >> If you have something like that, please change it to something like
> this.
> >>
> >>if 0%{?fedora} || 0%{?rhel} > 7
> >> %define with_python3 1
> >>%endif
> >
> > I'll say it once again, but why can't we just have
> > %{python2_available} and %{python3_available} macros defined in the
> > base system?
>
> Mostly because we can't change RHEL.
>
> So, how about %{python2_missing} and %{python3_available}? Is that too
> ugly and inconsistent?
>
>

We don't need to change RHEL. We just need to add %{python2_available} to
the epel-srpm-macros package. Or am I missing something? Yes, this will
only work for packages built against EPEL 7 and not for third-party
build-systems, but that's not something we have to care about, is it?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: LizardFS NFS Ganesha integration with no shared library available

[Kaleb S. KEITHLEY]

On 01/18/2018 03:23 AM, Jonathan Dieter wrote:
> (This is meant for the Fedora devel mailing list, but I've cc'd the
> nfs-ganesha mailing list in the hopes that they might see something I'm
> missing)
> 
> The latest release of the LizardFS distributed filesystem includes a
> FSAL for NFS Ganesha, allowing you to mount a LizardFS filesystem using
> NFS (or pNFS, if you prefer).

The LizardFS FSAL is GPLv3.  NFS-Ganesha is LGPLv3+.

From a Fedora packaging standpoint is it acceptable to build a GPLv3
plug-in for an otherwise LGPLv3+ binary?

If the licenses were reversed, I'd be reasonably confident that that
combination is okay.

What sayeth our "I'm not a lawyer but I play one on Fedora Devel mailing
list" legal beagles?

Thanks

-- 

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

Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly

[Petr Viktorin]

On 01/17/2018 12:38 PM, Richard W.M. Jones wrote:

On Thu, Jan 11, 2018 at 01:02:32PM -0800, Troy Dawson wrote:

Hello,
Python3 will be in the next major RHEL release.  I don't mean RHEL
7.6, but with numbers higher than 7.
There are many, many packages with something like the following

   if 0%{?fedora}
%define with_python3 1
   %endif

If you have something like that, please change it to something like this.

   if 0%{?fedora} || 0%{?rhel} > 7
%define with_python3 1
   %endif


I'll say it once again, but why can't we just have
%{python2_available} and %{python3_available} macros defined in the
base system?


Mostly because we can't change RHEL.

So, how about %{python2_missing} and %{python3_available}? Is that too 
ugly and inconsistent?



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

Re: Proposal to remove NetworkManager from Core group

[Major Hayden]

On 01/18/2018 02:28 AM, David Demelier wrote:
> Since systemd-networkd is a mature network system daemon nowadays,
> NetworkManager can be avoided in many cases where people do not need
> desktop features.
> 
> I propose to remove NetworkManager from the “Core” group and mark it as
> optional or eventually move it into a dedicated group. Perhaps “Common
> NetworkManager Submodules”?

I'd prefer to see NetworkManager still in Core and be the default network 
management system. Matthew noted some systemd-networkd shortcomings (one of 
which is the support for old ifcfg scripts) and the new "run once and quit" 
mode keeps resource usage under control.

Although I've used both many times, I find it easier to do complex networking 
in NetworkManager and it's a bit easier to control and monitor with Ansible.

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

Re: Proposal to remove NetworkManager from Core group

[Adam Williamson]

On Thu, 2018-01-18 at 09:28 +0100, David Demelier wrote:
> Hello all,
> 
> Since systemd-networkd is a mature network system daemon nowadays,
> NetworkManager can be avoided in many cases where people do not need
> desktop features.
> 
> I propose to remove NetworkManager from the “Core” group and mark it as
> optional or eventually move it into a dedicated group. Perhaps “Common
> NetworkManager Submodules”?
> 
> What do you think?

Big -1, personally.

A technical note on your proposal: you are begging the question. You
say that "NetworkManager can be avoided", but you don't provide any
explanation as to what makes NetworkManager a thing to be "avoided".
What's wrong with it, and why is systemd-networkd better?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Status of SWDB (Unified database for DNF)

[Adam Williamson]

On Thu, 2018-01-18 at 16:15 +0100, Kevin Kofler wrote:
> Pierre-Yves Chibon wrote:
> > Even if it does, it should have been advertised as a system-wide change
> > for F28 which is no longer possible.
> 
> FESCo could approve an exception.
> 
> If this really makes package updates made through PackageKit show up in DNF 
> history, IMHO, it would be worth considering at least. (But of course not if 
> it breaks things.)

The problem is kinda that it's effectively impossible to know for sure
what it breaks (it'll certainly break *something*) before deploying it.
DNF is deeply woven into the compose process, the repo generation
process, package build process...really all the bits of actually
producing the things we call Fedora, honestly. And when something's
that important, we're kinda at the "the map is the territory" stage: we
just don't have an entire Staging Fedora where we can deploy DNF 3 and
find out what's broken. We have staging instances of *some* processes,
but even those are generally not a perfect reflection of how production
behaves. And some things we just don't have a staging or test
environment for at all; we only really get to find the bugs when we
deploy it to production.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal to remove NetworkManager from Core group

[Silvia Sánchez]

Hello,

I would prefer to keep Network Manager as core. I don't see what benefits
would bring if it's removed and marked as optional.

Regards,
Silvia
FAS: Lailah


On 18 January 2018 at 13:31, Matthew Miller 
wrote:

> On Thu, Jan 18, 2018 at 09:28:30AM +0100, David Demelier wrote:
> > Since systemd-networkd is a mature network system daemon nowadays,
> > NetworkManager can be avoided in many cases where people do not need
> > desktop features.
> > I propose to remove NetworkManager from the “Core” group and mark it as
> > optional or eventually move it into a dedicated group. Perhaps “Common
> > NetworkManager Submodules”?
> > What do you think?
>
> I'm not super-excited about having multiple very different ways of
> configuring networking. We were finally on track to one path via
> NetworkManager.
>
> At the very least, I'd like to see a generator so systemd-networkd can
> read and understand basic ifcfg files, and I'd like the transition back
> and forth to be seamless if NetworkManager is installed or removed.
>
> Note that NetworkManager also now has a lightweight "run once and exit"
> mode that can be used when "desktop features" or other advanced
> functionality isn't needed. Since a lot of its development is funded by
> Red Hat for enterprise needs, NetworkManager is a lot more than just a
> desktop thing.
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Status of SWDB (Unified database for DNF)

[Eduard Cuba]

Existing code has a serious performance problem with package uninstallation
on bigger installations (a lot of transactions or a lot of packages in the
system) interfering with the system upgrade. Moreover, database scheme has
significantly changed - that would require another, relatively complex
transformation script and cause issues with rollback. In addition, SWDB API
has changed again and a lot of stuff is being moved to C++.

I definitely don't agree with cherry-picking the old version, it would
cause a big mess. Consider upstream SWDB version being a proof of concept -
it works, but it has some issues to be fixed.

On Thu, Jan 18, 2018 at 4:35 PM Neal Gompa  wrote:

> On Thu, Jan 18, 2018 at 10:15 AM, Kevin Kofler 
> wrote:
> > Pierre-Yves Chibon wrote:
> >> Even if it does, it should have been advertised as a system-wide change
> >> for F28 which is no longer possible.
> >
> > FESCo could approve an exception.
> >
> > If this really makes package updates made through PackageKit show up in
> DNF
> > history, IMHO, it would be worth considering at least. (But of course
> not if
> > it breaks things.)
> >
>
> SWDB could be cherry-picked out into the current DNF stuff. There was
> a point where it worked with the existing code before the rewrite of
> libdnf in C++ started.
>
> The DNF team could also give a better idea of when the current rewrite
> stuff will stabilize.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Status of SWDB (Unified database for DNF)

[Neal Gompa]

On Thu, Jan 18, 2018 at 10:15 AM, Kevin Kofler  wrote:
> Pierre-Yves Chibon wrote:
>> Even if it does, it should have been advertised as a system-wide change
>> for F28 which is no longer possible.
>
> FESCo could approve an exception.
>
> If this really makes package updates made through PackageKit show up in DNF
> history, IMHO, it would be worth considering at least. (But of course not if
> it breaks things.)
>

SWDB could be cherry-picked out into the current DNF stuff. There was
a point where it worked with the existing code before the rewrite of
libdnf in C++ started.

The DNF team could also give a better idea of when the current rewrite
stuff will stabilize.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Security updates and batched pushes

[Benjamin Kircher]

> On 18. Jan 2018, at 16:13, Kevin Kofler  wrote:
> 
> Am I the only one who bothers reading update notes?

Nope.

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

Re: Security updates and batched pushes

[Kevin Kofler]

Randy Barlow wrote:
> The original intent as I understood it from the thread long ago[0] was
> to reduce the number of updates that go out on non-Tuesdays, and make
> most updates happen on Tuesdays. The data that Kevin cited seems to be
> accomplishing that purpose.

But whom does this help? There are still updates going out daily, the 
repodata download cost is still there, the notifications too if you aren't 
doing client-side batching (and if you are, you don't need server-side 
batching to begin with).

The only difference I see is that some fixes take longer to reach the users 
and that the huge Tuesday (Wednesday morning for most users) pushes are a 
huge pain to go through if you want to actually check what you are updating. 
(Am I the only one who bothers reading update notes?)

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

Re: Status of SWDB (Unified database for DNF)

[Kevin Kofler]

Pierre-Yves Chibon wrote:
> Even if it does, it should have been advertised as a system-wide change
> for F28 which is no longer possible.

FESCo could approve an exception.

If this really makes package updates made through PackageKit show up in DNF 
history, IMHO, it would be worth considering at least. (But of course not if 
it breaks things.)

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

Re: Security updates and batched pushes

[Kevin Kofler]

I wrote:
> This week, there have been almost daily nonempty update pushes (listing
> only the SRPMs here, and only the updates that affected me):
> * Jan 10 (previous batch)
> * Jan 11 (not batched, gtk3 and microcode-ctl)
> * Jan 12 (not batched, kernel, dhcp, dnfdragora, hplip, webkitgtk4)
> * none on Sat Jan 13 (some updates from RPM Fusion, but those have
>   separate repodata, so they don't count)
> * Jan 14/15 (night, not batched, bluez, python-nbconvert,
>   python-qtconsole)
> * Jan 15/16 (night, not batched, llvm with all its revdeps, hplip again)
> and now today (Jan 17)'s batch includes (for me) 135 (!) binary packages
> (less if you count the SRPMs, but in the end, the binary packages are what
> really matter).

And today (Jan 18), the day after the batch, there's yet another nonempty 
push: redhat-rpm-config/nim-srpm-macros, cmake, jnr-*, python-sphinx, 
twolame moved from RPM Fusion to Fedora.

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

Re: Updates which are never pushed to stable

[Sérgio Basto]

On Sat, 2018-01-13 at 12:28 +0100, Igor Gnatenko wrote:
> Hello,
> 
> I noticed that for multiple release we have updates which stuck in
> bodhi for
> many months until distro goes EOL.
> 
> I wonder if we should just auto-unpush updates which are in testing
> in 1(?)
> month? Thoughts?

I agree with autopush packages in updates-testing, between mass branch
and final release. After GA (general availability), I think is legit 
have thing in testing. 
I wrote about this subject some years ago, I'll explain what I thought,
in phase of betas some people (like me) may enable update-testing to
test more quickly the new fixes and after release they (and I) disable
the update-testing which leaves that systems with packages that never
hit the stable. 

But dnf distro-sync fix this issue ... so maybe isn't a problem . 


> 
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Orphaned perl-IPTables-ChainMgr and perl-IPTables-Parse

[Miloslav Trmac]

Hello,
2018-01-18 15:06 GMT+01:00 Robert-André Mauchin :

> On jeudi 18 janvier 2018 14:31:17 CET Miloslav Trmac wrote:
> > I have orphaned perl-IPTables-ChainMgr and perl-IPTables-Parse .
>
> I need perl-IPTables-ChainMgr for a package that is currently being
> reviewed
> (Ravada [1]), can you transfer the ownership of both to me (fas: eclipseo)?
>

I’m afraid I have already dropped the necessary access, please file a
ticket per
https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#How_do_I_adopt_an_orphaned_package_or_unretire_a_package.3F
.
Mirek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1535735] perl-MongoDB-v1.8.1 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-MongoDB-1.8.1-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-80f1b2526c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Orphaned perl-IPTables-ChainMgr and perl-IPTables-Parse

[Robert-André Mauchin]

On jeudi 18 janvier 2018 14:31:17 CET Miloslav Trmac wrote:
> Hello,
> I have orphaned perl-IPTables-ChainMgr and perl-IPTables-Parse .
> Mirek

I need perl-IPTables-ChainMgr for a package that is currently being reviewed 
(Ravada [1]), can you transfer the ownership of both to me (fas: eclipseo)?

Thanks.


[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1535207

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

[Bug 1535735] perl-MongoDB-v1.8.1 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-MongoDB-1.8.1-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-4d0ca370cb

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: LizardFS NFS Ganesha integration with no shared library available

[Jonathan Dieter]

On Thu, 2018-01-18 at 07:34 -0500, Kaleb S. KEITHLEY wrote:
> On 01/18/2018 03:23 AM, Jonathan Dieter wrote:
> > What is the best way for me to include NFS Ganesha support in LizardFS?
> >1. Include the latest Fedora NFS Ganesha source and add a hard requires
> >   to that version in the LizardFS NFS subpackage.
> >2. Convince the LizardFS developers to try to move their FSAL into NFS
> >   Ganesha? (LizardFS has just added a client library and doesn't have
> >   a server library, so this will probably take some work)
> 
> That would be the path of least resistance. And the one I would suggest
> and highly recommend. If they've already written a FSAL it should be
> easy to add it to the nfs-ganesha source.
> 
> Depending on the license of course.

If this is both the easiest and the recommended path, then lets see if
the LizardFS developers will go for it.  The license for this code is
GPLv3.  

> >3. Convince the NFS Ganesha developers to create a library that you can
> >   compile FSAL's against?  (The last thread I saw in the NFS Ganesha
> >   devel list on this subject was six years old)
> 
> That would be a non-trivial amount of work with little benefit to the
> current FSAL developers.
> 
> It's not an unreasonable request, per se, but we have other, higher
> priorities.

I totally understand that.

> >4. ???
> > 
> > Any advice would be great, as I'd love to get this feature into
> > Fedora's release of LizardFS.
> 
> Do you have a contact for someone at LizardFS?  I looked at their web
> site and nothing popped out at me.

The main developer that I've communicated with is:
Piotr Sarna 

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

[Bug 1535735] perl-MongoDB-v1.8.1 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-MongoDB-1.8.1-1.fc28



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Orphaned perl-IPTables-ChainMgr and perl-IPTables-Parse

[Miloslav Trmac]

Hello,
I have orphaned perl-IPTables-ChainMgr and perl-IPTables-Parse .
Mirek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal to remove NetworkManager from Core group

[Matthew Miller]

On Thu, Jan 18, 2018 at 09:28:30AM +0100, David Demelier wrote:
> Since systemd-networkd is a mature network system daemon nowadays,
> NetworkManager can be avoided in many cases where people do not need
> desktop features.
> I propose to remove NetworkManager from the “Core” group and mark it as
> optional or eventually move it into a dedicated group. Perhaps “Common
> NetworkManager Submodules”?
> What do you think?

I'm not super-excited about having multiple very different ways of
configuring networking. We were finally on track to one path via
NetworkManager. 

At the very least, I'd like to see a generator so systemd-networkd can
read and understand basic ifcfg files, and I'd like the transition back
and forth to be seamless if NetworkManager is installed or removed.

Note that NetworkManager also now has a lightweight "run once and exit"
mode that can be used when "desktop features" or other advanced
functionality isn't needed. Since a lot of its development is funded by
Red Hat for enterprise needs, NetworkManager is a lot more than just a
desktop thing.

-- 
Matthew Miller

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

Re: LizardFS NFS Ganesha integration with no shared library available

[Kaleb S. KEITHLEY]

On 01/18/2018 03:23 AM, Jonathan Dieter wrote:
> (This is meant for the Fedora devel mailing list, but I've cc'd the
> nfs-ganesha mailing list in the hopes that they might see something I'm
> missing)
> 
> The latest release of the LizardFS distributed filesystem includes a
> FSAL for NFS Ganesha, allowing you to mount a LizardFS filesystem using
> NFS (or pNFS, if you prefer).
> 
> Unfortunately, NFS Ganesha doesn't provide a library to build the
> LizardFS FSAL against, so LizardFS upstream downloads the complete NFS
> Ganesha source and builds against that.
> 
> As far as I can see, all the other FSAL's are maintained and built in
> NFS Ganesha.
> 
> What is the best way for me to include NFS Ganesha support in LizardFS?
>1. Include the latest Fedora NFS Ganesha source and add a hard requires
>   to that version in the LizardFS NFS subpackage.
>2. Convince the LizardFS developers to try to move their FSAL into NFS
>   Ganesha? (LizardFS has just added a client library and doesn't have
>   a server library, so this will probably take some work)

That would be the path of least resistance. And the one I would suggest
and highly recommend. If they've already written a FSAL it should be
easy to add it to the nfs-ganesha source.

Depending on the license of course.


>3. Convince the NFS Ganesha developers to create a library that you can
>   compile FSAL's against?  (The last thread I saw in the NFS Ganesha
>   devel list on this subject was six years old)

That would be a non-trivial amount of work with little benefit to the
current FSAL developers.

It's not an unreasonable request, per se, but we have other, higher
priorities.

>4. ???
> 
> Any advice would be great, as I'd love to get this feature into
> Fedora's release of LizardFS.

Do you have a contact for someone at LizardFS?  I looked at their web
site and nothing popped out at me.

-- 

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

[Bug 1535448] perl-Data-Dump-Color-0.240 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Data-Dump-Color-0.240-
   ||1.fc28
 Resolution|--- |RAWHIDE
   Assignee|emman...@seyman.fr  |jples...@redhat.com
Last Closed||2018-01-18 07:04:25



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

openjpeg-1.x removal

[Sandro Mani]

Hi

I've had a look at what still requires openjpeg-1.x, and there are just 
a handful of packages which can be ported with relatively small effort 
to openjpeg2. These packages are:


blender: upstream patch
efl: support in currently packaged version
gstreamer1-plugins-bad-free-extras: support in currently packaged version
mtpaint: upstream support in newer version
vfrnav: trivial patch

I've gone ahead and test-builded the required changes in copr [1] and 
filed PRs:


https://src.fedoraproject.org/rpms/blender/pull-request/1
https://src.fedoraproject.org/rpms/gstreamer1-plugins-bad-free/pull-request/1
https://src.fedoraproject.org/rpms/mtpaint/pull-request/1
https://src.fedoraproject.org/rpms/vfrnav/pull-request/2 -> merged already

(I accidentally pushed the efl change directly instead of pushing to the 
fork, apologies for that!!)


In addition to the above, the last successful build of gdcm also still 
requires openjpeg-1.x, since gdcm-2.8.4-1.fc28 failed to build.


Once all these packages are updated, I'd suggest that openjpeg-1.x 
finally be removed for F28+ (debian has done it over a year ago).


Thanks
Sandro

[1] https://copr.fedorainfracloud.org/coprs/smani/opj2/builds/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1511913] perl-Crypt-OpenSSL-X509-1.808 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Crypt-OpenSSL-X509-1.808-1.fc27 has been submitted as an update to Fedora
27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f60dccf200

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1511913] perl-Crypt-OpenSSL-X509-1.808 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
 CC||jples...@redhat.com
   Fixed In Version||perl-Crypt-OpenSSL-X509-1.8
   ||08-1.fc28
   Assignee|wjhns...@hardakers.net  |jples...@redhat.com



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1392475] perl-Alien-ROOT not available on ppc64 because root is not there

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
   Fixed In Version||perl-Alien-ROOT-5.34.36.1-1
   ||0.fc28



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1392479] perl-Alien-ROOT not available on ppc64le because root is not there

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
   Fixed In Version||perl-Alien-ROOT-5.34.36.1-1
   ||0.fc28



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1529277] perl-Locale-SubCountry-2.04 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Locale-SubCountry-2.04-1.fc26 has been submitted as an update to Fedora
26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-b812fa98d9

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1529277] perl-Locale-SubCountry-2.04 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Locale-SubCountry-2.04-1.fc27 has been submitted as an update to Fedora
27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-d1df30ae83

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Status of SWDB (Unified database for DNF)

[Pierre-Yves Chibon]

On Wed, Jan 17, 2018 at 11:50:53PM -, Greg Evenden wrote:
> ohh okz.  i guess the real questrion is, will DNF3 be usable before Branching 
> point? 

Even if it does, it should have been advertised as a system-wide change for F28
which is no longer possible.
So F29 it is :)


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

[Bug 1529277] perl-Locale-SubCountry-2.04 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
   Fixed In Version||perl-Locale-SubCountry-2.04
   ||-1.fc28
   Assignee|ppi...@redhat.com   |jples...@redhat.com



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Proposal to remove NetworkManager from Core group

[David Demelier]

Hello all,

Since systemd-networkd is a mature network system daemon nowadays,
NetworkManager can be avoided in many cases where people do not need
desktop features.

I propose to remove NetworkManager from the “Core” group and mark it as
optional or eventually move it into a dedicated group. Perhaps “Common
NetworkManager Submodules”?

What do you think?

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

LizardFS NFS Ganesha integration with no shared library available

[Jonathan Dieter]

(This is meant for the Fedora devel mailing list, but I've cc'd the
nfs-ganesha mailing list in the hopes that they might see something I'm
missing)

The latest release of the LizardFS distributed filesystem includes a
FSAL for NFS Ganesha, allowing you to mount a LizardFS filesystem using
NFS (or pNFS, if you prefer).

Unfortunately, NFS Ganesha doesn't provide a library to build the
LizardFS FSAL against, so LizardFS upstream downloads the complete NFS
Ganesha source and builds against that.

As far as I can see, all the other FSAL's are maintained and built in
NFS Ganesha.

What is the best way for me to include NFS Ganesha support in LizardFS?
   1. Include the latest Fedora NFS Ganesha source and add a hard requires
  to that version in the LizardFS NFS subpackage.
   2. Convince the LizardFS developers to try to move their FSAL into NFS
  Ganesha? (LizardFS has just added a client library and doesn't have
  a server library, so this will probably take some work)
   3. Convince the NFS Ganesha developers to create a library that you can
  compile FSAL's against?  (The last thread I saw in the NFS Ganesha
  devel list on this subject was six years old)
   4. ???

Any advice would be great, as I'd love to get this feature into
Fedora's release of LizardFS.

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