Re: Attempt to update ispc

2019-01-29 Thread Luya Tshimbalanga
On 2019-01-29 12:26 p.m., Luya Tshimbalanga wrote:
> Contacting upstream about the issue, a suggestion is use the built-in
> script alloy.py to manually build llvm instead of using the stock model
> i.e. llvm-devel.
>
> https://github.com/ispc/ispc/issues/1413#issuecomment-458654316
>
> Any feedback?
>
>
> Luya
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Added spec file with suggested alloy.py script.


Luya

%global with_snapshot 0
%global commit e338aaaebcf0193e194b13267bc69e7a0ec4fa4d
%global shortcommit %(c=%{commit}; echo ${c:0:7})

Name:		ispc
Version:	1.10.0
%if %{with_snapshot}
Release:	0.5.git.20190102.%{shortcommit}%{?dist}
%else
Release:	2%{?dist}
%endif
Summary:	C-based SPMD programming language compiler

License:	BSD
URL:		https://ispc.github.io/
%if %{with_snapshot}
Source0:	https://github.com/%{name}/%{name}/archive/%{commit}/%{name}-%{shortcommit}.tar.gz
%else
Source0:	https://github.com/%{name}/%{name}/archive/v%{version}/%{name}-%{version}.tar.gz
%endif
BuildRequires:	bison
BuildRequires:	cmake
BuildRequires:	clang
BuildRequires:	doxygen
BuildRequires:	flex 
BuildRequires:	gcc-c++
BuildRequires:	llvm-devel
BuildRequires:	ncurses-devel
Requires:	python2
BuildRequires:	/usr/bin/pathfix.py
BuildRequires:	/usr/bin/python2
ExclusiveArch:	%{arm} %{ix86} x86_64
# Hardcoded path from 32-bit glibc-devel needed to build
# See https://github.com/ispc/ispc/wiki/Building-ispc:-Linux-and-Mac-OS-X
%ifarch x86_64
BuildRequires:	/usr/lib/crt1.o
%endif
BuildRequires:	zlib-devel


# Set verbose compilation and remove -Werror on Makefile
Patch:		0002-Remove-uses-of-LLVM-dump-functions-and-verbose-makefile.patch

%description
A compiler for a variant of the C programming language, with extensions for
"single program, multiple data" (SPMD) programming.

%prep
%if %{with_snapshot}
%autosetup -p1 -n %{name}-%{commit}
%else
%autosetup -p1 -n %{name}-%{version}
%endif

sed -i 's|set(CMAKE_C_COMPILER "clang")|set(CMAKE_C_COMPILER "gcc")|g' CMakeLists.txt
sed -i 's|set(CMAKE_CXX_COMPILER "clang++")|set(CMAKE_CXX_COMPILER "g++")|g' CMakeLists.txt

# Fix all Python shebangs recursively in .
pathfix.py -pni "%{__python2} %{py2_shbang_opts}" .

# Manual build llvm
allow.py -b

%build
# Disable test otherwise build fails
%cmake -DISPC_INCLUDE_TESTS=OFF \
	-DCMAKE_BUILD_TYPE=release \
	.
%make_build gcc OPT="%{optflags} -fPIC" LDFLAGS="%{__global_ldflags} -fPIC"
%install
install -Dpm 0755 %{name} %{buildroot}%{_bindir}/%{name}

%files
%license LICENSE.txt
%{_bindir}/%{name}

%changelog
* Sat Jan 19 2019 Luya Tshimbalanga  - 1.10.0-2
- Patch for Makefile and remove llvm dump

* Sat Jan 19 2019 Luya Tshimbalanga  - 1.10.0-1
- Update to 1.10.0

* Wed Dec 26 2018 Luya Tshimbalanga  - 1.9.3-0.5.git.20190102.e338aaa
- Git snasphot 20190102

* Wed Dec 26 2018 Luya Tshimbalanga  - 1.9.3-0.4.git.20181220.1e4bfb7
- Git snasphot 20181220

* Tue Nov 06 2018 Luya Tshimbalanga  - 1.9.3-0.3.git.20181106.3d846b
- Git snasphot 1.9.3

* Fri Jul 13 2018 Fedora Release Engineering  - 1.9.3-0.3.git.20180222.07fe054
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild

* Thu Mar 15 2018 Iryna Shcherbina  - 1.9.3-0.2.git.20180222.07fe054
- Update Python 2 dependency declarations to new packaging standards
  (See https://fedoraproject.org/wikiComponents/FinalizingFedoraSwitchtoPython3)

* Sat Mar 03 2018 Luya Tshimbalanga  - 1.9.3-0.1.git.20180222.07fe054 
- Update to 1.9.3 git snapshot
- Use new guideline versioning semantique for snapshot

* Fri Mar 02 2018 Luya Tshimbalanga  - 1.9.2-1
- Update to 1.9.2

* Wed Feb 07 2018 Fedora Release Engineering  - 1.9.1-18.git.20171023.6dc0ccc
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

* Tue Oct 24 2017 Tom Stellard  - 1.9.1-17.git.20171023.6dc0ccc
- Rebase to more current snapshot for LLVM 5.0 support.

* Wed Aug 02 2017 Fedora Release Engineering  - 1.9.1-16.git.20170324.a618ad4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild

* Wed Jul 26 2017 Fedora Release Engineering  - 1.9.1-15.git.20170324.a618ad4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild

* Thu May 25 2017 Peter Robinson  1.9.1-14.git.20170324.a618ad4
- Rebuild clang/llvm-4

* Mon May 15 2017 Fedora Release Engineering  - 1.9.1-13.git.20170324.a618ad4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_27_Mass_Rebuild

* Fri Mar 24 2017 Igor Gnatenko  - 1.9.1-12.git.20170324.a618ad4
- Update to git snapshot which support LLVM4

* Thu Mar 16 2017 Luya Tshimbalanga  - 1.9.1-11
- Rebuild for llvm 3.9

* Fri Feb 10 2017 Fedora Release Engineering  - 1.9.1-10
- Rebuilt for 

Re: F30 Self-Contained Change proposal: Bash 5.0

2019-01-29 Thread Neal Gompa
On Tue, Jan 29, 2019 at 11:05 PM Matthew Miller
 wrote:
>
> On Tue, Jan 29, 2019 at 02:43:39AM -0500, Siteshwar Vashisht wrote:
> > I agree that it would be much safer to target it for Fedora 31. I have no
> > objection if we change target release.
>
> What about building it as a module, with Bash 4 as the default stream for
> F30 and a plan to switch that to 5 for F31?
>

Please don't do that. You'll basically break the distribution for all
third-party packagers. Modules are not supported by anyone at all, and
it's too difficult to integrate as it currently stands (and I'm
actually trying because of the impending doom that is RHEL 8).



-- 
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: MongoDB Removal

2019-01-29 Thread Neal Gompa
On Tue, Jan 29, 2019 at 5:33 PM John Harris  wrote:
>
> On Tuesday, January 29, 2019 5:29:58 AM EST Ben Cotton wrote:
> > Fedora has determined that the Server Side Public Licensev1 (SSPL) is
> > not a Free Software License.
>
> For what reason is SSPL considered non-free? As I see, it's essentially a GPL
> incompatible AGPL license.
>

It restricts fields of endeavor and how you can use it. That conflicts
with freedom 0 of the Free Software Definition. In addition, no one is
sure it's actually possible to comply with the SSPL as worded, since
it attempts to convert the licensing of everything that's part of the
running system, including things not directly linked to it.

Cf. 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IQIOBOGWJ247JGKX2WD6N27TZNZZNM6C/




--
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

2019-01-29 Thread updates
The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  46  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b7556983e8   
tomcat-7.0.92-1.el6
  42  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a0ddb153b8   
game-music-emu-0.6.2-1.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-17b388679b   
nagios-4.4.3-1.el6


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

qpid-proton-0.26.0-1.el6

Details about builds:



 qpid-proton-0.26.0-1.el6 (FEDORA-EPEL-2019-901a19ccd9)
 A high performance, lightweight messaging library

Update Information:

This update requires rebuilding rhpkg because this package is using unsupported
API, see https://bugzilla.redhat.com/show_bug.cgi?id=131. Upstream has been
reworking python-proton to allow them to maintain it better going forward (in a
number of ways). One thing that has been tightened up is which symbols get
exported from which modules. This is so that we can reimplement/remove modules
without affecting users that don't really use these modules.  SSLDomain is not
meant to imported from proton.reactor, but from proton.  Please update that line
to "from proton import SSLDomain".

ChangeLog:

* Mon Jan  7 2019 Irina Boverman  - 0.26.0-1
- Rebased to 0.26.0


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


[389-devel] 389 DS nightly 2019-01-30 - 92% PASS

2019-01-29 Thread vashirov
https://fedorapeople.org/groups/389ds/ci/nightly/2019/01/30/report-389-ds-base-1.4.0.20-1.fc29.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org


[Bug 1667714] perl-Module-CoreList-5.20190120 is available

2019-01-29 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1667714

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Module-CoreList-5.2019 |perl-Module-CoreList-5.2019
   |0120-1.fc30 |0120-1.fc30
   |perl-Module-CoreList-5.2019 |perl-Module-CoreList-5.2019
   |0120-1.fc28 |0120-1.fc28
   ||perl-Module-CoreList-5.2019
   ||0120-1.fc29



--- Comment #7 from Fedora Update System  ---
perl-Module-CoreList-5.20190120-1.fc29 has been pushed to the Fedora 29 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1667713] perl-CPAN-Perl-Releases-3.88 is available

2019-01-29 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1667713

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-CPAN-Perl-Releases-3.8 |perl-CPAN-Perl-Releases-3.8
   |8-1.fc30|8-1.fc30
   |perl-CPAN-Perl-Releases-3.8 |perl-CPAN-Perl-Releases-3.8
   |8-1.fc28|8-1.fc28
   ||perl-CPAN-Perl-Releases-3.8
   ||8-1.fc29



--- Comment #6 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.88-1.fc29 has been pushed to the Fedora 29 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1667714] perl-Module-CoreList-5.20190120 is available

2019-01-29 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1667714

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Module-CoreList-5.2019 |perl-Module-CoreList-5.2019
   |0120-1.fc30 |0120-1.fc30
   ||perl-Module-CoreList-5.2019
   ||0120-1.fc28
 Resolution|--- |ERRATA
Last Closed||2019-01-30 01:32:16



--- Comment #6 from Fedora Update System  ---
perl-Module-CoreList-5.20190120-1.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1667713] perl-CPAN-Perl-Releases-3.88 is available

2019-01-29 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1667713

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-CPAN-Perl-Releases-3.8 |perl-CPAN-Perl-Releases-3.8
   |8-1.fc30|8-1.fc30
   ||perl-CPAN-Perl-Releases-3.8
   ||8-1.fc28
 Resolution|--- |ERRATA
Last Closed||2019-01-30 01:32:15



--- Comment #5 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.88-1.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1670644] New: perl-Ouch-0.0501 is available

2019-01-29 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1670644

Bug ID: 1670644
   Summary: perl-Ouch-0.0501 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Ouch
  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
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.0501
Current version/release in rawhide: 0.0500-5.fc29
URL: http://search.cpan.org/dist/Ouch/

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/3183/

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: MongoDB Removal

2019-01-29 Thread Till Maas
On Tue, Jan 29, 2019 at 04:23:48PM +0100, Miro Hrončok wrote:

> My understanding is that not only we will not able to test those, but there
> will be no point of shipping them at all. What am I missing?

It is very likely that the packages can still be used to access MongoDB
instances that run on other systems.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: MongoDB Removal

2019-01-29 Thread John Harris
On Tuesday, January 29, 2019 4:21:54 PM EST Chris Murphy wrote:
> It's not free for everyone all of the time.

Under what circumstances is it non-free? I agree that it's overreaching 
(attempting to claim software that is not part of it as being the same 
software), however I don't see circumstances under which it would be non-free.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: MongoDB Removal

2019-01-29 Thread Chris Murphy
On Tue, Jan 29, 2019 at 1:07 PM John Harris  wrote:

> For what reason is SSPL considered non-free? As I see, it's essentially a GPL
> incompatible AGPL license.

https://opensource.org/LicenseReview122018
http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003875.html

It's not free for everyone all of the time.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: MongoDB Removal

2019-01-29 Thread Jason L Tibbitts III
> "JH" == John Harris  writes:

JH> For what reason is SSPL considered non-free? As I see, it's
JH> essentially a GPL incompatible AGPL license.

It's been pretty well covered throughout this whole debacle, but here's
the most recent announcement from Fedora Legal:

https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/IQIOBOGWJ247JGKX2WD6N27TZNZZNM6C/

This information is also included in the Licensing section of the Fedora
wiki: https://fedoraproject.org/wiki/Licensing/SSPL

- J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Attempt to update ispc

2019-01-29 Thread Luya Tshimbalanga
Contacting upstream about the issue, a suggestion is use the built-in
script alloy.py to manually build llvm instead of using the stock model
i.e. llvm-devel.

https://github.com/ispc/ispc/issues/1413#issuecomment-458654316

Any feedback?


Luya

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Server Side Public License (SSPL) v1

2019-01-29 Thread John Harris
How exactly is SSPLv1 "aggressively discriminatory towards people of a 
specific class"? How exactly did you determine that the purpose was to spread 
FUD, and what do you describe as "commercial users"?

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Boost 1.69 update with soname bumps in rawhide/F30

2019-01-29 Thread Jonathan Wakely

On 29/01/19 18:49 +, José Abílio Matos wrote:

On Friday, 25 January 2019 15.57.53 WET Jonathan Wakely wrote:


I've done local builds of most of them, and 130+ build OK. Any that
fail I'll create bugzilla FTBFS reports for.


FWIW lyx fails but a patch has already been committed upstream to solve the
issue.

The short version is to remove the offending line.

The longer version is
https://www.lyx.org/trac/changeset/3a123b90af838b08680471d87170c38e56787df9/
lyxgit


Thanks! Do you want me to apply that patch for rawhide and rebuild it?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: MongoDB Removal

2019-01-29 Thread John Harris
On Tuesday, January 29, 2019 5:29:58 AM EST Ben Cotton wrote:
> Fedora has determined that the Server Side Public Licensev1 (SSPL) is
> not a Free Software License.

For what reason is SSPL considered non-free? As I see, it's essentially a GPL 
incompatible AGPL license.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: python-pep8 is orphaned

2019-01-29 Thread Matthias Runge
On Tue, Jan 29, 2019 at 08:40:51AM +0100, Miro Hrončok wrote:
> On 29. 01. 19 5:07, iliana weller wrote:
> > Hello,
> > 
> > I've orphaned python-pep8. pep8 was renamed to pycodestyle in 2016; it
> > received its last release in 2017. It should be removed from Fedora in a
> > future release.
> > 
> > I unfortunately don't have time to proceed with the full retirement
> > process myself. If somebody would like to pick it up:
> > https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package
> > 
> > $ dnf repoquery --whatrequires python2-pep8
> > python2-autopep8-0:1.2.4-9.fc29.noarch
> > python2-pytest-pep8-0:1.0.6-15.fc29.noarch
> > python2-spyder-0:3.3.1-3.fc29.noarch
> > $ dnf repoquery --whatrequires python3-pep8
> > python3-autopep8-0:1.2.4-9.fc29.noarch
> > python3-hacking-0:1.1.0-3.fc29.noarch
> > python3-pytest-pep8-0:1.0.6-15.fc29.noarch
> > python3-spyder-0:3.3.1-3.fc29.noarch
> > 
> > See also https://bugzilla.redhat.com/show_bug.cgi?id=1667200's dependent
> > bugs.
> 
> I would like to see the package retired.
> 
> python-autopep8, python-pytest-pep8, spyder, python-hacking:
> 
> Would you mind switching to pycodestyle?

autopep8 now uses pycodestyle. I should update autopep8 over the
next few days.

For hacking, it looks like I missed the commit, which dropped the
requirement for pep8, pyflakes, and mccabe. I'll update as well.

Matthias
-- 
Matthias Runge 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: python-pep8 is orphaned

2019-01-29 Thread Miro Hrončok

On 29. 01. 19 5:07, iliana weller wrote:

Hello,

I've orphaned python-pep8. pep8 was renamed to pycodestyle in 2016; it
received its last release in 2017. It should be removed from Fedora in a
future release.

I unfortunately don't have time to proceed with the full retirement
process myself. If somebody would like to pick it up:
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package

$ dnf repoquery --whatrequires python2-pep8
python2-autopep8-0:1.2.4-9.fc29.noarch
python2-pytest-pep8-0:1.0.6-15.fc29.noarch
python2-spyder-0:3.3.1-3.fc29.noarch
$ dnf repoquery --whatrequires python3-pep8
python3-autopep8-0:1.2.4-9.fc29.noarch
python3-hacking-0:1.1.0-3.fc29.noarch
python3-pytest-pep8-0:1.0.6-15.fc29.noarch
python3-spyder-0:3.3.1-3.fc29.noarch

See also https://bugzilla.redhat.com/show_bug.cgi?id=1667200's dependent
bugs.


I would like to see the package retired.

python-autopep8, python-pytest-pep8, spyder, python-hacking:

Would you mind switching to pycodestyle?

$ dnf repoquery  --repo=rawhide-source --whatrequires pythonX-pep8
(simplified)
cachedir
genbackupdata
imgbased
ovirt-guest-agent
pylast
python-actdiag
python-autobahn
python-blockdiag
python-bloom
python-cliapp
python-f5-icontrol-rest
python-nwdiag
python-os-win
python-ryu
python-seqdiag
python-shortuuid
python-terminaltables
python-ttystatus
python-txaio
syslog-ng

Would you mind switching to pycodestyle or stop linting code on build time?

--
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: Retire YUM 3

2019-01-29 Thread Stephen John Smoogen
On Tue, 29 Jan 2019 at 05:42, Matthew Miller 
wrote:

> On Mon, Jan 28, 2019 at 06:41:26PM +0100, Miro Hrončok wrote:
> > >This feels more like system-wide change…
> > >Especially since you say that some extra packages will be retired.
> >
> > A very limited set. The distro as a whole should not be impacted by this.
> >
> > The retired packages are legacy cruft. And the important stuff that
> > needs to be updated needs some motivation like this.
>
> "This change needs to motivate other important stuff that we don't have
> direct control over to change" seems like *exactly* the reason we ask for
> system-wide changes to be filed earlier.
>
>
>
This is like the 4th system wide change this release which is coming in as
a Self-Contained. Each time the developer thinks it is self-contained
because it is just one  little thing, but on regards it turns into being a
system-wide change. However because the two deadlines are one after the
other, it means that this change is pushed out another 6 months where the
3-4 weeks between System-Wide and Self-Contained doesn't seem very long.
Can we either:

1) Move System-Wide and Self-Contained proposal deadlines to be the same
date and allow FESCO/etc determine if the proposal needs to be moved to SW
or SC then?
2) Move Self-Contained deadline BEFORE System-Wide so that  if it is
really  System-Wide move it to the correct category?
3) Add a re-evaluate deadline after the first two? This allows us to get an
idea that "oh wait this is going to really mess things up and we need to
push this out one release?" or other items

At the moment, I think pushing out removal of yum3 for Fedora31 doesn't
make sense if there isn't enough python2 for it to be useful in Fedora30.
However I also think this is a system-wide change because a lot of tools
need time to test that they REALLY do support not having yum3 in them.


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Boost 1.69 update with soname bumps in rawhide/F30

2019-01-29 Thread José Abílio Matos
On Friday, 25 January 2019 15.57.53 WET Jonathan Wakely wrote:
> 
> I've done local builds of most of them, and 130+ build OK. Any that
> fail I'll create bugzilla FTBFS reports for.

FWIW lyx fails but a patch has already been committed upstream to solve the 
issue.

The short version is to remove the offending line.

The longer version is
https://www.lyx.org/trac/changeset/3a123b90af838b08680471d87170c38e56787df9/
lyxgit
-- 
José Abílio

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: Retire YUM 3

2019-01-29 Thread Miro Hrončok

On 29. 01. 19 19:04, John Harris wrote:

On Monday, January 28, 2019 12:27:19 PM EST Ben Cotton wrote:

Remove packages from the distribution:
* createrepo
* yum
* yum-langpacks
* yum-utils
* yum-metadata-parser
* yum-updatesd
* python-urlgrabber


Are there already `dnf` equivalents to `createrepo` and `yum-utils`?


AFAIK createrepo_c for createrepo and dnf itself for yum-utils.


--
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


system-config-kickstart -- stay or go?

2019-01-29 Thread David Cantrell
The system-config-kickstart package in Fedora is on a very low
maintenance status at the moment.  It is not really promoted much as a
tool that people should use, however I know some people still use it (or
at least did).

But now we are at a cross roads.  system-config-kickstart needs to move
to Python 3.x which is going to be required by pykickstart soon.
Currently system-config-kickstart is all in Python 2.x.  Given the
near-deprecation state of the software, I propose one of the following
options:

1) Mark system-config-kickstart as obsolete in rawhide and remove it.
It can then slowly fade away in the remaining supported releases
branches it exists in.

2) Someone in the community who wants to keep it around volunteers to
take over both ownership of the package and upstream maintainership.
This individual would port system-config-kickstart to at least Python
3.x and continue maintaining it as long as people want it around.

Thoughts?

-- 
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: Retire YUM 3

2019-01-29 Thread John Harris
On Monday, January 28, 2019 12:27:19 PM EST Ben Cotton wrote:
> Remove packages from the distribution:
> * createrepo
> * yum
> * yum-langpacks
> * yum-utils
> * yum-metadata-parser
> * yum-updatesd
> * python-urlgrabber

Are there already `dnf` equivalents to `createrepo` and `yum-utils`?

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Co

2019-01-29 Thread smooge
Dear all,

You are kindly invited to the meeting:
   EPEL Steering Co on 2019-01-30 from 18:00:00 to 19:00:00 GMT
   At freenode@fedora-meeting

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting. Agenda is in the 
https://infinote.fedoraproject.org/cgit/infinote/tree/epel-meeting-next 


Source: https://apps.fedoraproject.org/calendar/meeting/9364/

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


Re: Attempt to update ispc

2019-01-29 Thread Luya Tshimbalanga
Here is. Filed the bug to upstream:

https://github.com/ispc/ispc/issues/1413


Luya

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Attempt to update ispc

2019-01-29 Thread Fabio Valentini
On Tue, Jan 29, 2019 at 6:03 PM Luya Tshimbalanga
 wrote:
>
> -BEGIN PGP MESSAGE-
> Charset: UTF-8

I guess the encrypted garble garble below happened by accident - you
might want to send your message again without encrypting it.

Fabio

> hQEMAyZZ5X4GTmHqAQgA3r4Bs+wCUHFsVqpIPN5v0tFnaioogOKYTrDgA9MTKzzV
> GuEEdfFctzFOZw9eAiu7lIYZn41Ajpx7pGDjgxXJYsnhBKmL/n5BLrQ+hlG4FYcM
> LcT/O5DQjwgndjwsx9QlsHoCrk12lMCcGZLPX+w0Gjc1d8uMofQ3F9iZpr71zq99
> 6FF/hmpEghytBTnqL/0BPMu2tJOpdcVxeO8hYzFZoM/906GjLJMqOFXSa9Szlxib
> weoQg667E7i0J3p/GS0r5hU8g35M0pTjvHHlwh30lhQad/BBH6ry7Y/8J37Sh6XL
> whdSLi7xZMEOnV7RuBbiFjwF4FruHYvNi8Ph2JvLtNLqASL7zJZbPjgZh1VeUxbL
> lnQoJbcyiFM+hBxLCqJvnlzatMiwya63GqbEQwTOyU+kHFWoNSgQTtz3kwcSnahq
> q+A0ILXxLt5Sz0tKHRw7C7DwNFqrAj9Pr5MSbllm1AkLu+dAa5AW3CCdohz20iEH
> g+TaVMJjiPhyPaaWjrSkPl1Qbkd/Amy9jisHSBSQVWigviQjphkuFGDzLJByiWQe
> HCS5y4tx3q9ZTmT3RugU/Y4cm9IHHmODfI+B4fHMWubFVlos8i7Eu0lC4tWAo9nL
> MCrJkhJidFZguutfYwGS+/oznV8CkB3MiRkooH77FfLpLMwCtEiMoSSTsHDMVrFZ
> FqqsZXCDa8bZB+A5kb2eQLHDjAv6Y0Uv4l+oxxuz7AaAzgoCKHDe/2zFY/ZPguoV
> aM5CW+W4bKlDLKK3XzmtYqQYxcQcFWwHWDbrbunWFuS9/RlCcW6W4x9ARXkGY+26
> X4483yHxNA9kG+DyDqA3vvNUEgDcTPHe3rOr/ViUvFZZWnsfd7y+fO/wpVJNFywn
> xrzwmpjSI75z/n5kp22ckokm0sJz2NNX+N8ZRRWmsDyve8OgmS2wd61CGPoJ0cY3
> zRh4MJL+2Ly/u7BBocOxBdrlf0gSgBxBGmOQHAcbSgAYultgw4BWgs5UXr1OaEvx
> dFXWbNyfrWpwubl8f96fujQKgV64xi73Y9obSq6AjmWajKWnZFRSph+rV6CkoZqO
> FvUOPlFAbZmuaRb+9mU/8b8u3AhY1Xh8e50g5IW+Hqt8gw/Dz4vWPhaddJlc5o8A
> LR5O3v+CcJq1y+BzJ1GBymrUkuPJCxjRO/RctQbtTopUqMdiGx8jTy7y0mESFvAD
> Ojjc2W0gN9cfP6itGeB/27aeynRP/xSXw8xvg1bN+JW0fqnFidGdsrHahX5nPYRw
> MmVJsUyaIZbQSyD7TUbqzl30eIjPM92XNCXA7Jy+1Zi0lvdPDRvgQW3L0DijQVqu
> fhjvKPELPD+/L4kKDoJhSlaFSAyrd/pWfr2oKXJ8tiRqFShalFv/i2+fmxf18hqb
> AZMHqb3zDFFUQLopk4wf/668HHZVRxzyq4uUshEDAp36Eubtdrc8hMzmv2XfoxuM
> bs41OChDVTzdiekq+vj0hjftUNI/zMdFLYV3LilfI4e0XVF87uBzu6zFNZtjhxQN
> PBf05oA6dd3IaEgiomZOs3XLpZ8L1VjZhPo8EuJBvfgBz6jkGJKIt3vr9Ju2+t3a
> SJs/zIUC1tBcDtU5ZVBV9N2cfmpat6ISqaifB67afJN3APq+h3ZHgzaGc0QrGLW1
> QQY3t4+vdjt+a+Tx3HW+RYwa2IHclZk/L0yA4oa0yj3DRc6s53E3ZSQ4ZxD4jjkI
> KumR7OQ2NsV6zp4iCPgDT9dbO2z5hCkU1B9rAohTc0pqvFeXMlP3O8LOHbv/0j+Z
> rvvPvzuJlXlW0wfF+QEiD0SgNhCdcoeuiC74V4LIKsm1CF6+QRI/QcVH+xFZPJi0
> VorJ+I7BtsklvqmXS6Yc05ujJLvYyaWZhof3fwPf+40IV7BqKdZ9j9o4fa0LOgQD
> wzWw3FgMAL/WDFuPyzu7RZMxwQwqpxDffo/rCUfB61wZ+CAUCipX4kgugl6ZPRIs
> oVs4O4XW9eDaboBuQe/XfWZ3dEFVjIYQ17LMgu2tsMAShAMhtgZD+Giq4dUmKsHv
> D+pM2OPAeON+HF6sOAseocgShprB0t2NQzdnNT+FtW3+H/sw1VY7NoyW1pheC1KS
> aPbygQTcIkj0zDX9pZoCbGa3XkPqflqnViWSMZY8Ap7v4QcZnBWzAkQ8yFdovUtE
> XQ3CRrPX4aMvFL4GHg2CQRpCLCuz7Qab0WUP4v6v0/FvOP+poDKxZdahVreed1DZ
> LSiih/piAz1GG3imiIr20uxRgyBWo7Kt0jL6JthYszWGerkgwQeH8wAlfG5fQWZp
> gUZzaywXQ7EWD9HpA69IeNhblBxrxpTJEya15WORLZtk/1qk47c0cQfgkS+1Rd1e
> wSxs/IZyV+voAkTbHIWG7QCSHIP/ifg/Q/vHe6LBJN/ATqkvryqQDS/Lr32jbRP4
> 3sg2UroeWoYFjsb+2XjxyTWNXiFJ1RE2uQNnO7el5K58w+ROhJd120XQV6kAULaV
> Dswb7M6l/9qbcOQyC1kGz4axc3QeNVdlFSUcyMTmNN8tMXHMNwgpeWeRqiNNc7/j
> zVELKN42l3VP0bDFVEwK0elbU2IFqE8EMuOmVRlldDB8RmO0oqrtTwZVZb7CCLE8
> 7SHqLkIzAnXGASl9
> =a/zz
> -END PGP MESSAGE-
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Attempt to update ispc

2019-01-29 Thread Luya Tshimbalanga
-BEGIN PGP MESSAGE-
Charset: UTF-8

hQEMAyZZ5X4GTmHqAQgA3r4Bs+wCUHFsVqpIPN5v0tFnaioogOKYTrDgA9MTKzzV
GuEEdfFctzFOZw9eAiu7lIYZn41Ajpx7pGDjgxXJYsnhBKmL/n5BLrQ+hlG4FYcM
LcT/O5DQjwgndjwsx9QlsHoCrk12lMCcGZLPX+w0Gjc1d8uMofQ3F9iZpr71zq99
6FF/hmpEghytBTnqL/0BPMu2tJOpdcVxeO8hYzFZoM/906GjLJMqOFXSa9Szlxib
weoQg667E7i0J3p/GS0r5hU8g35M0pTjvHHlwh30lhQad/BBH6ry7Y/8J37Sh6XL
whdSLi7xZMEOnV7RuBbiFjwF4FruHYvNi8Ph2JvLtNLqASL7zJZbPjgZh1VeUxbL
lnQoJbcyiFM+hBxLCqJvnlzatMiwya63GqbEQwTOyU+kHFWoNSgQTtz3kwcSnahq
q+A0ILXxLt5Sz0tKHRw7C7DwNFqrAj9Pr5MSbllm1AkLu+dAa5AW3CCdohz20iEH
g+TaVMJjiPhyPaaWjrSkPl1Qbkd/Amy9jisHSBSQVWigviQjphkuFGDzLJByiWQe
HCS5y4tx3q9ZTmT3RugU/Y4cm9IHHmODfI+B4fHMWubFVlos8i7Eu0lC4tWAo9nL
MCrJkhJidFZguutfYwGS+/oznV8CkB3MiRkooH77FfLpLMwCtEiMoSSTsHDMVrFZ
FqqsZXCDa8bZB+A5kb2eQLHDjAv6Y0Uv4l+oxxuz7AaAzgoCKHDe/2zFY/ZPguoV
aM5CW+W4bKlDLKK3XzmtYqQYxcQcFWwHWDbrbunWFuS9/RlCcW6W4x9ARXkGY+26
X4483yHxNA9kG+DyDqA3vvNUEgDcTPHe3rOr/ViUvFZZWnsfd7y+fO/wpVJNFywn
xrzwmpjSI75z/n5kp22ckokm0sJz2NNX+N8ZRRWmsDyve8OgmS2wd61CGPoJ0cY3
zRh4MJL+2Ly/u7BBocOxBdrlf0gSgBxBGmOQHAcbSgAYultgw4BWgs5UXr1OaEvx
dFXWbNyfrWpwubl8f96fujQKgV64xi73Y9obSq6AjmWajKWnZFRSph+rV6CkoZqO
FvUOPlFAbZmuaRb+9mU/8b8u3AhY1Xh8e50g5IW+Hqt8gw/Dz4vWPhaddJlc5o8A
LR5O3v+CcJq1y+BzJ1GBymrUkuPJCxjRO/RctQbtTopUqMdiGx8jTy7y0mESFvAD
Ojjc2W0gN9cfP6itGeB/27aeynRP/xSXw8xvg1bN+JW0fqnFidGdsrHahX5nPYRw
MmVJsUyaIZbQSyD7TUbqzl30eIjPM92XNCXA7Jy+1Zi0lvdPDRvgQW3L0DijQVqu
fhjvKPELPD+/L4kKDoJhSlaFSAyrd/pWfr2oKXJ8tiRqFShalFv/i2+fmxf18hqb
AZMHqb3zDFFUQLopk4wf/668HHZVRxzyq4uUshEDAp36Eubtdrc8hMzmv2XfoxuM
bs41OChDVTzdiekq+vj0hjftUNI/zMdFLYV3LilfI4e0XVF87uBzu6zFNZtjhxQN
PBf05oA6dd3IaEgiomZOs3XLpZ8L1VjZhPo8EuJBvfgBz6jkGJKIt3vr9Ju2+t3a
SJs/zIUC1tBcDtU5ZVBV9N2cfmpat6ISqaifB67afJN3APq+h3ZHgzaGc0QrGLW1
QQY3t4+vdjt+a+Tx3HW+RYwa2IHclZk/L0yA4oa0yj3DRc6s53E3ZSQ4ZxD4jjkI
KumR7OQ2NsV6zp4iCPgDT9dbO2z5hCkU1B9rAohTc0pqvFeXMlP3O8LOHbv/0j+Z
rvvPvzuJlXlW0wfF+QEiD0SgNhCdcoeuiC74V4LIKsm1CF6+QRI/QcVH+xFZPJi0
VorJ+I7BtsklvqmXS6Yc05ujJLvYyaWZhof3fwPf+40IV7BqKdZ9j9o4fa0LOgQD
wzWw3FgMAL/WDFuPyzu7RZMxwQwqpxDffo/rCUfB61wZ+CAUCipX4kgugl6ZPRIs
oVs4O4XW9eDaboBuQe/XfWZ3dEFVjIYQ17LMgu2tsMAShAMhtgZD+Giq4dUmKsHv
D+pM2OPAeON+HF6sOAseocgShprB0t2NQzdnNT+FtW3+H/sw1VY7NoyW1pheC1KS
aPbygQTcIkj0zDX9pZoCbGa3XkPqflqnViWSMZY8Ap7v4QcZnBWzAkQ8yFdovUtE
XQ3CRrPX4aMvFL4GHg2CQRpCLCuz7Qab0WUP4v6v0/FvOP+poDKxZdahVreed1DZ
LSiih/piAz1GG3imiIr20uxRgyBWo7Kt0jL6JthYszWGerkgwQeH8wAlfG5fQWZp
gUZzaywXQ7EWD9HpA69IeNhblBxrxpTJEya15WORLZtk/1qk47c0cQfgkS+1Rd1e
wSxs/IZyV+voAkTbHIWG7QCSHIP/ifg/Q/vHe6LBJN/ATqkvryqQDS/Lr32jbRP4
3sg2UroeWoYFjsb+2XjxyTWNXiFJ1RE2uQNnO7el5K58w+ROhJd120XQV6kAULaV
Dswb7M6l/9qbcOQyC1kGz4axc3QeNVdlFSUcyMTmNN8tMXHMNwgpeWeRqiNNc7/j
zVELKN42l3VP0bDFVEwK0elbU2IFqE8EMuOmVRlldDB8RmO0oqrtTwZVZb7CCLE8
7SHqLkIzAnXGASl9
=a/zz
-END PGP MESSAGE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Removal of Python 2 from the Xfce spin

2019-01-29 Thread Miro Hrončok

On 09. 01. 19 9:34, Miro Hrončok wrote:
Hi, we've successfully removed Python 2 from default Workstation installation 
years ago, today I'd like to see if we could do it in Xfce Spin as well.


For those not in the picture: Python 2 ill EOL in 11 months, 22 days [0].
We are trying to get rid of it as much as possible in Fedora [1][2].

Eliminating Python 2 from our defualt installations is an important step here.

Today, if I try to uninstall python2 from Xfce spin (rawhide), this is what gets 
removed as dependent:


Here's an update:


  NetworkManager-openconnect-gnome


openconnect removed python2 dependency \o/


  blueberry


still uses python2, Kevin, any chance you've checked why?
Should I take a look?


  gnumeric


The Python 2 bits are only needed for Python 2 extensions, moved to a separate 
subpackage.



  python2-catfish


catfish now runs on python 3 \o/


  system-config-keyboard


shall be removed form comps and replaced by xfce4-xkb-plugin


  system-config-users


??? still looking for a solution ???

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org


Re: Fixing Wireguard spec file

2019-01-29 Thread Germano Massullo
Il giorno mar 29 gen 2019 alle ore 17:39 Nicolas Chauvet
 ha scritto:
> There is a wireguard package maintained by Robert-André Mauchin on RPM
> Fusion that at least... works.

Ah I did not know that, thank you
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[SELinux] xdp_socket in Rawhide

2019-01-29 Thread Lukas Vrabec
Hi All,

I created new selinux-policy build with support new class: xdp_socket

https://koji.fedoraproject.org/koji/taskinfo?taskID=32331044

I don't expect any big troubles in rawhide, it passed my basic testing,
but if you'll face any AVC where there will be class xdp_socket, please
let me know ASAP.

Thanks,
Lukas.

-- 
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fixing Wireguard spec file

2019-01-29 Thread Nicolas Chauvet
Le mar. 29 janv. 2019 à 16:33, Germano Massullo
 a écrit :
>
> This [1] is the Wireguard spec file from upstream Copr repo [2].
> Wireguard will be included in kernel 5.0, but meanwhile we are using it as 
> dkms.
There is a wireguard package maintained by Robert-André Mauchin on RPM
Fusion that at least... works.

-- 
-

Nicolas (kwizart)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[Modularity] Team IRC meeting minutes (2019-01-29)

2019-01-29 Thread Nils Philippsen

#fedora-meeting-3: Weekly Meeting of the Modularity Team



Meeting started by nils at 15:00:03 UTC.

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-3/2019-01-29/modularity.2019-01-29-15.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-3/2019-01-29/modularity.2019-01-29-15.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-3/2019-01-29/modularity.2019-01-29-15.00.log.html


Meeting summary
---
* Roll Call  (nils, 15:00:03)

* Agenda  (nils, 15:01:22)
  * #112 Discussion: Module lifecycles  (nils, 15:01:22)
  * #115 Discussion: Stream branch ownership for packages & modules
(nils, 15:01:22)

* #112 Discussion: Module lifecycles  (nils, 15:02:57)
  * LINK: https://pagure.io/modularity/issue/112   (nils, 15:02:57)
  * LINK: https://pagure.io/fesco/issue/2027   (nils, 15:02:57)
  * stalled because people were on conferences etc., still ongoing
(nils, 15:07:51)

* #115 Discussion: Stream branch ownership for packages & modules
  (nils, 15:09:11)
  * LINK: https://pagure.io/modularity/issue/115   (nils, 15:09:11)
  * LINK: https://pagure.io/fesco/issue/2028   (nils, 15:09:14)
  * also stalled because people were on conferences etc., still ongoing
(nils, 15:11:53)
  * ACTION: contyk updates the tickets  (nils, 15:12:09)

Meeting ended at 15:14:28 UTC.




Action Items

* contyk updates the tickets




Action Items, by person
---
* contyk
  * contyk updates the tickets
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* nils (31)
* contyk (11)
* zodbot (10)
* langdon (3)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-- 
Nils Philippsen"Those who would give up Essential Liberty to
Software Engineer   purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: Retire YUM 3

2019-01-29 Thread Adam Jackson
On Mon, 2019-01-28 at 12:27 -0500, Ben Cotton wrote:

> == Detailed Description ==
> Remove packages from the distribution:
> * createrepo
> * yum
> * yum-langpacks
> * yum-utils
> * yum-metadata-parser
> * yum-updatesd
> * python-urlgrabber
> 
> All these packages should no longer be used and all software using
> them should be migrated to DNF.

I have a couple of older OSes I often need to do builds for in mock,
which OSes use yum natively. Unfortunately pyrpkg doesn't have any way
to invoke mock with --dnf, so when mock attempts to construct the
chroot it tries to use yum to do it. With this change (or indeed
already on my F29 machine without yum installed) I would no longer be
able to use fedpkg to build for those OSes.

Obviously I can work around this by invoking mock manually with an
appropriate config file, but it would be pleasant if pyrpkg was fixed
as well.

- ajax
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: MongoDB Removal

2019-01-29 Thread Richard Shaw
On Tue, Jan 29, 2019 at 9:29 AM Richard Shaw  wrote:

> On Tue, Jan 29, 2019 at 4:32 AM Ben Cotton  wrote:
>
>> https://fedoraproject.org/wiki/Changes/MongoDB_Removal
>>
>> == Summary ==
>> Fedora has determined that the Server Side Public Licensev1 (SSPL) is
>> not a Free Software License. Therefore, we need to drop MongoDB from
>> Fedora.
>
>
> I only recently got the Ubiquiti Unifi controller into the RPM Fusion
> non-free repository...
>
> Can it be moved to RPM Fusion? Of course that means that the dependencies
> will have to move as well...
>

(Sorry, hit tab-space and gmail send the message!)

Richard

>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: MongoDB Removal

2019-01-29 Thread Richard Shaw
On Tue, Jan 29, 2019 at 4:32 AM Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/MongoDB_Removal
>
> == Summary ==
> Fedora has determined that the Server Side Public Licensev1 (SSPL) is
> not a Free Software License. Therefore, we need to drop MongoDB from
> Fedora.


I only recently got the Ubiquiti Unifi controller into the RPM Fusion
non-free repository...

Can it be moved to RPM Fusion? Of course
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Fixing Wireguard spec file

2019-01-29 Thread Germano Massullo
This [1] is the Wireguard spec file from upstream Copr repo [2].
Wireguard will be included in kernel 5.0, but meanwhile we are using it as dkms.

The only problem is that at every Wireguard upgrade, a manual action
is required.
For example now that I have installed 0.0.20190123, I have to remove the old
/var/lib/dkms/wireguard/0.0.20181218/
folder in order to let
# dkms autoinstall
work.
Otherwise I will get a
===
# dkms status
Error! Could not locate dkms.conf file.
File: /var/lib/dkms/wireguard/0.0.20181218/source/dkms.conf does not exist.
===
and wg-quick service unable to start.

Do you have any idea about how the Wireguard spec file could be fixed
in order to avoid this action having to be runned at every package
update?

Thank you

[1]: 
https://copr-be.cloud.fedoraproject.org/results/jdoss/wireguard/fedora-29-x86_64/00839061-wireguard-dkms/wireguard-dkms.spec
[2]: https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: MongoDB Removal

2019-01-29 Thread Miro Hrončok

On 29. 01. 19 16:17, Honza Horak wrote:

On 1/29/19 11:57 AM, Vít Ondruch wrote:


Dne 29. 01. 19 v 11:39 Miro Hrončok napsal(a):

On 29. 01. 19 11:29, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/MongoDB_Removal

== Summary ==
Fedora has determined that the Server Side Public Licensev1 (SSPL) is
not a Free Software License. Therefore, we need to drop MongoDB from
Fedora.


While I'm in favor of the removal, I don't think this is entirely true.

It should read:


Therefore, we need to drop MongoDB from Fedora or never update it

again.

Never updating it would bring security issues, hence we decided to

remove it.


Other developers: N/A (not a System Wide Change)


This is not true. This page needs to list all dependent packages on
Mongo and all dependent packages on Mongo connectors (such as
python-pymongo).



Yes, right. There is rubygem-mongo and rubygem-mongoid and they will
become FTBFS without MongoDB. The test suite could be disabled, but this
will be unfortunate, because historically it helped to uncover issues on
some of our arches.


While I see the value of tests, I personally don't consider just the testing 
purposes to be a good enough reason to keep unmaintained mongodb-server in 
Fedora, and don't see any other option here.


Do you see any viable solution here, Vit?


My understanding is that not only we will not able to test those, but there will 
be no point of shipping them at all. 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: MongoDB Removal

2019-01-29 Thread Florian Weimer
* Honza Horak:

>> Yes, right. There is rubygem-mongo and rubygem-mongoid and they will
>> become FTBFS without MongoDB. The test suite could be disabled, but this
>> will be unfortunate, because historically it helped to uncover issues on
>> some of our arches.
>
> While I see the value of tests, I personally don't consider just the
> testing purposes to be a good enough reason to keep unmaintained
> mongodb-server in Fedora, and don't see any other option here.

Maybe we could keep it as a buildroot-only package (similar to glibc32)
and filter it from the composes?

On the other hand, it would set a bad precedent.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: MongoDB Removal

2019-01-29 Thread Honza Horak

On 1/29/19 11:57 AM, Vít Ondruch wrote:


Dne 29. 01. 19 v 11:39 Miro Hrončok napsal(a):

On 29. 01. 19 11:29, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/MongoDB_Removal

== Summary ==
Fedora has determined that the Server Side Public Licensev1 (SSPL) is
not a Free Software License. Therefore, we need to drop MongoDB from
Fedora.


While I'm in favor of the removal, I don't think this is entirely true.

It should read:


Therefore, we need to drop MongoDB from Fedora or never update it

again.

Never updating it would bring security issues, hence we decided to

remove it.


Other developers: N/A (not a System Wide Change)


This is not true. This page needs to list all dependent packages on
Mongo and all dependent packages on Mongo connectors (such as
python-pymongo).



Yes, right. There is rubygem-mongo and rubygem-mongoid and they will
become FTBFS without MongoDB. The test suite could be disabled, but this
will be unfortunate, because historically it helped to uncover issues on
some of our arches.


While I see the value of tests, I personally don't consider just the 
testing purposes to be a good enough reason to keep unmaintained 
mongodb-server in Fedora, and don't see any other option here.


Do you see any viable solution here, Vit?

Honza


Vít




The change should explain if other packagers are expected to remove
the functionality from their packages or if the change owners will do
that.

If we just remove Mongo, it will cause broken deps.

Also, do we plan to move Mongo to the famous other repo (I assume
nonfree section)?


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Boost 1.69 update with soname bumps in rawhide/F30

2019-01-29 Thread Miro Hrončok

On 29. 01. 19 15:44, Jonathan Wakely wrote:

On 29/01/19 14:59 +0100, Miro Hrončok wrote:

On 25. 01. 19 16:57, Jonathan Wakely wrote:

With enormous thanks to Denis Arnaud for doing the actual boost.spec
rebase, we're ready to update Boost in rawhide, for this change:
https://fedoraproject.org/wiki/Changes/F30Boost169

As always, this changes the soname of every libboost_*.so library, so
we'll be rebuilding all the packages that link to Boost libs. These
rebuilds will happen on the f30-boost side tag, and once they're all
done everything will move to the main f30 target all at once.

IF YOU MAINTAIN A PACKAGE THAT DEPENDS ON BOOST and need to rebuild it
in the next few days, please get in touch so we can coordinate.


I assume you are aware of the planned mass rebuild, right?


Yes, but rather than have a load of new failures due to the Boost
change, I'm trying to fix packages to work with the new Boost now.

That way failures due to Boost can be dealt with early, rather than
getting mixed in with hundreds of unrelated failures in the mass
rebuild.


And that is actually awesome! I was asking because of "need to rebuild it in the 
next few days" thing. Thanks for clarifying.


--
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Boost 1.69 update with soname bumps in rawhide/F30

2019-01-29 Thread Jonathan Wakely

On 29/01/19 14:59 +0100, Miro Hrončok wrote:

On 25. 01. 19 16:57, Jonathan Wakely wrote:

With enormous thanks to Denis Arnaud for doing the actual boost.spec
rebase, we're ready to update Boost in rawhide, for this change:
https://fedoraproject.org/wiki/Changes/F30Boost169

As always, this changes the soname of every libboost_*.so library, so
we'll be rebuilding all the packages that link to Boost libs. These
rebuilds will happen on the f30-boost side tag, and once they're all
done everything will move to the main f30 target all at once.

IF YOU MAINTAIN A PACKAGE THAT DEPENDS ON BOOST and need to rebuild it
in the next few days, please get in touch so we can coordinate.


I assume you are aware of the planned mass rebuild, right?


Yes, but rather than have a load of new failures due to the Boost
change, I'm trying to fix packages to work with the new Boost now.

That way failures due to Boost can be dealt with early, rather than
getting mixed in with hundreds of unrelated failures in the mass
rebuild.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: Bash 5.0

2019-01-29 Thread Igor Gnatenko
On Tue, Jan 29, 2019 at 2:59 PM Matthew Miller  wrote:
>
> On Tue, Jan 29, 2019 at 01:28:06PM +0100, Igor Gnatenko wrote:
> > That doesn't help until there is Ursa Major or some alternative deployed.
> >
> > The reason for that is that we would need to maintain 2 copies of
> > bash, one for users and one for buildroot. I do that for libgit2 and
> > it is painful.
>
> Okay, yeah. But modules can override base, right? So what if 4 is left as
> the default in F30 and a module for 5 added, and then in F31 hopefully there
> will be ursa major¹ in place.

Only on the user' systems, not in the buildroot. At least at this moment.

> But wait also: can't the module just refer to the release-branch (base)
> dist-git? Why maintain two copies?

Well, they can. But someone needs to build it twice: once using fedpkg
build and once using fedpkg module-build from the different repo
(which always requires at least empty commit).

>
> [1] a funny name for "allowing modules in buildroot"²
>
> [2] hey, what happened to sgallagh's "hybrid" proposal where output from
> modules could just be *tagged into* base? That seemed perfect for cases
> like this.

Well, it is called UM which is stuck in the FESCo loop.

> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Boost 1.69 update with soname bumps in rawhide/F30

2019-01-29 Thread Miro Hrončok

On 25. 01. 19 16:57, Jonathan Wakely wrote:

With enormous thanks to Denis Arnaud for doing the actual boost.spec
rebase, we're ready to update Boost in rawhide, for this change:
https://fedoraproject.org/wiki/Changes/F30Boost169

As always, this changes the soname of every libboost_*.so library, so
we'll be rebuilding all the packages that link to Boost libs. These
rebuilds will happen on the f30-boost side tag, and once they're all
done everything will move to the main f30 target all at once.

IF YOU MAINTAIN A PACKAGE THAT DEPENDS ON BOOST and need to rebuild it
in the next few days, please get in touch so we can coordinate. 


I assume you are aware of the planned mass rebuild, right?

--
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Boost 1.69 update with soname bumps in rawhide/F30

2019-01-29 Thread Jonathan Wakely

On 25/01/19 15:57 +, Jonathan Wakely wrote:

With enormous thanks to Denis Arnaud for doing the actual boost.spec
rebase, we're ready to update Boost in rawhide, for this change:
https://fedoraproject.org/wiki/Changes/F30Boost169

As always, this changes the soname of every libboost_*.so library, so
we'll be rebuilding all the packages that link to Boost libs. These
rebuilds will happen on the f30-boost side tag, and once they're all
done everything will move to the main f30 target all at once.

IF YOU MAINTAIN A PACKAGE THAT DEPENDS ON BOOST and need to rebuild it
in the next few days, please get in touch so we can coordinate. It's
better to avoid me doing a rebuild in the f30-boost side tag, then
somebody else doing another rebuild in the main f30 target, and then
me having to do another build in the side tag! If you'd rather I don't
rebuild your package (e.g. so you can finish an update and then build
it yourself) please get in touch.

I've done local builds of most of them, and 130+ build OK. Any that
fail I'll create bugzilla FTBFS reports for.


The following packages fail to build due to using -Werror because of
the new -Wdeprecated-copy warning in GCC.

I refuse to waste my time fixing -Werror breakage.

Maintainers by package:
mstflint dledford honli jirka jstanley michich
qpid-cpp irina nsantos

Packages by maintainer:
dledford   mstflint
honli  mstflint
irina  qpid-cpp
jirka  mstflint
jstanley   mstflint
michichmstflint
nsantosqpid-cpp

Please don't use -Werror in your packages, it causes unnecessary pain
for proven-packagers who need to rebuild them.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: Bash 5.0

2019-01-29 Thread Matthew Miller
On Tue, Jan 29, 2019 at 01:28:06PM +0100, Igor Gnatenko wrote:
> That doesn't help until there is Ursa Major or some alternative deployed.
> 
> The reason for that is that we would need to maintain 2 copies of
> bash, one for users and one for buildroot. I do that for libgit2 and
> it is painful.

Okay, yeah. But modules can override base, right? So what if 4 is left as
the default in F30 and a module for 5 added, and then in F31 hopefully there
will be ursa major¹ in place.

But wait also: can't the module just refer to the release-branch (base)
dist-git? Why maintain two copies?


[1] a funny name for "allowing modules in buildroot"²

[2] hey, what happened to sgallagh's "hybrid" proposal where output from
modules could just be *tagged into* base? That seemed perfect for cases
like this.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


lmfit soname bump 7.0 -> 8.2

2019-01-29 Thread Miro Hrončok

lmfit will be bumped. dependent packages build fine.

https://src.fedoraproject.org/rpms/lmfit/pull-request/3

--
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [Late] F30 System-Wide Change proposal: GCC9

2019-01-29 Thread Daniel P . Berrangé
On Tue, Jan 29, 2019 at 02:12:03PM +0100, Jakub Jelinek wrote:
> On Tue, Jan 29, 2019 at 01:04:25PM +, Daniel P. Berrangé wrote:
> > The variable was already initialized right at the start. The compound
> > literal is just a short-hand for later changing the values in several
> > fields of the struct at once. This is no different to manually assigning
> > new values to each individual field one at a time. eg
> > 
> >   struct demo demo = {0};
> > 
> >   ...some code with a goto...
> > 
> >   demo = (struct demo) { .cmd = "foo" };
> 
> No, I wasn't talking about the demo variable, the warning is not about demo
> variable.  The warning is about the compound literal variable.
> That is an anonymous (when used at block scope automatic) variable, kind
> like:
>   struct demo __complit = { .cmd = "foo" };
>   demo = __complit;
> and with the goto you are crossing initialization of that variable.

Urgh. I would never have understood that from the warning message :-( It
is complaining about something that doesn't even exist as far as I was
concerned

> When you aren't taking address of this, the optimizers will likely optimize
> the temporary away later on, if you'd do &(struct demo) { .cmd = "foo" }
> that address could be used later on in the function, dereferenced etc.

Is it practical to get the warning supressed when code is not taking the
address of the anonymous var ?

If not then we pretty much have to abandon use of these anonymous
compound initializers for re-assigning existing variables :-(

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [Late] F30 System-Wide Change proposal: GCC9

2019-01-29 Thread Florian Weimer
* Jakub Jelinek:

> On Tue, Jan 29, 2019 at 12:51:25PM +, Daniel P. Berrangé wrote:
>> Libvirt has hit a problem with -Wjump-misses-init newly reporting bogus
>> warnings for code using anonymous struct initializers during assignments:
>> 
>>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061
>>   https://bugzilla.redhat.com/show_bug.cgi?id=1669489
>> 
>> It is quite an ununfortunate bug as it is not straightforward to workaround
>> the bogus warning by changing code, while we also don't want to disable
>> -Wjump-misses-init since it is a useful/important warning in general.
>> So we'd really like to see the regression fixed before F30 GA.
>
> That is not a false positive, you are crossing initialization of the
> compound literal.  Older GCC versions mistakenly haven't put the automatic
> variables for the compound literals into the right scope.
> Yes, in your case you are not accessing the compound literal in the cleanup:
> code, but that is exactly the same case when you get a warning for:

>   if (whatever)
> goto cleanup;
>
>   int i = 26;
>
> cleanup:
>   return 0;


I think it's more like getting a warning for this:

int i = 5;

if (whatever)
  goto cleanup;
 
i = 26;
// …
 
  cleanup:
return 0;

In fact, this results in warning, too:

i = (struct { int value; }) { 26 }.value;

As Joseph pointed out on the upstream PR, the warning refers to the
internal variable used to store the compound literal, which the
programmer did not spell out explicitly.

I'm not sure if it is possible that the skipped initialization leads to
undefined behavior, without also involving a pointer to an object that
goes out of scope.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [Late] F30 System-Wide Change proposal: GCC9

2019-01-29 Thread Jakub Jelinek
On Tue, Jan 29, 2019 at 01:04:25PM +, Daniel P. Berrangé wrote:
> The variable was already initialized right at the start. The compound
> literal is just a short-hand for later changing the values in several
> fields of the struct at once. This is no different to manually assigning
> new values to each individual field one at a time. eg
> 
>   struct demo demo = {0};
> 
>   ...some code with a goto...
> 
>   demo = (struct demo) { .cmd = "foo" };

No, I wasn't talking about the demo variable, the warning is not about demo
variable.  The warning is about the compound literal variable.
That is an anonymous (when used at block scope automatic) variable, kind
like:
  struct demo __complit = { .cmd = "foo" };
  demo = __complit;
and with the goto you are crossing initialization of that variable.
When you aren't taking address of this, the optimizers will likely optimize
the temporary away later on, if you'd do &(struct demo) { .cmd = "foo" }
that address could be used later on in the function, dereferenced etc.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: MongoDB Removal

2019-01-29 Thread Nicolas Mailhot

Le 2019-01-29 13:47, Florian Weimer a écrit :

* Nicolas Mailhot:


Le 2019-01-29 11:39, Miro Hrončok a écrit :


This is not true. This page needs to list all dependent packages on
Mongo and all dependent packages on Mongo connectors (such as
python-pymongo). The change should explain if other packagers are
expected to remove the functionality from their packages or if the
change owners will do that.


I should point out that pulp depends on mongodb. At one time pulp and
foreman were presented as the Fedora infra future in many public
forums and conferences.


Pulp 3 uses PostgreSQL and Redis:



(Note that while parts of the Redis ecosystem are no longer FLOSS, 
Redis

itself still is.)


That's nice to know but it's just the dev trunk isn't it? The latest 
release is still 2.18 with no public ETA for a complete stable 3.0, 
except for bits appearing now and then as beta version.


Nevertheless, I had missed this change, thanks a lot for pointing it 
out.



Regards,

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [Late] F30 System-Wide Change proposal: GCC9

2019-01-29 Thread Daniel P . Berrangé
On Tue, Jan 29, 2019 at 01:56:19PM +0100, Jakub Jelinek wrote:
> On Tue, Jan 29, 2019 at 12:51:25PM +, Daniel P. Berrangé wrote:
> > Libvirt has hit a problem with -Wjump-misses-init newly reporting bogus
> > warnings for code using anonymous struct initializers during assignments:
> > 
> >   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061
> >   https://bugzilla.redhat.com/show_bug.cgi?id=1669489
> > 
> > It is quite an ununfortunate bug as it is not straightforward to workaround
> > the bogus warning by changing code, while we also don't want to disable
> > -Wjump-misses-init since it is a useful/important warning in general.
> > So we'd really like to see the regression fixed before F30 GA.
> 
> That is not a false positive, you are crossing initialization of the
> compound literal.  Older GCC versions mistakenly haven't put the automatic
> variables for the compound literals into the right scope.

The variable was already initialized right at the start. The compound
literal is just a short-hand for later changing the values in several
fields of the struct at once. This is no different to manually assigning
new values to each individual field one at a time. eg

  struct demo demo = {0};

  ...some code with a goto...

  demo = (struct demo) { .cmd = "foo" };

is no different from

  struct demo demo = {0};

  ...some code with a goto...

  demo.cmd = "foo"

and neither should generate warnings about missing initializers with gotos.

> Yes, in your case you are not accessing the compound literal in the cleanup:
> code, but that is exactly the same case when you get a warning for:

Even if we were accessing the the variable in the cleanup code, it would
not be a missing initializer, as the variable was initialized at the time
it was declared before any goto.


>   if (whatever)
> goto cleanup;
> 
>   int i = 26;
> 
> cleanup:
>   return 0;

This is a completely different scenario, as it is jumping over the
declaration of the variable and its only initializer.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [Late] F30 System-Wide Change proposal: GCC9

2019-01-29 Thread Jakub Jelinek
On Tue, Jan 29, 2019 at 12:51:25PM +, Daniel P. Berrangé wrote:
> Libvirt has hit a problem with -Wjump-misses-init newly reporting bogus
> warnings for code using anonymous struct initializers during assignments:
> 
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061
>   https://bugzilla.redhat.com/show_bug.cgi?id=1669489
> 
> It is quite an ununfortunate bug as it is not straightforward to workaround
> the bogus warning by changing code, while we also don't want to disable
> -Wjump-misses-init since it is a useful/important warning in general.
> So we'd really like to see the regression fixed before F30 GA.

That is not a false positive, you are crossing initialization of the
compound literal.  Older GCC versions mistakenly haven't put the automatic
variables for the compound literals into the right scope.
Yes, in your case you are not accessing the compound literal in the cleanup:
code, but that is exactly the same case when you get a warning for:
  if (whatever)
goto cleanup;

  int i = 26;

cleanup:
  return 0;

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [Late] F30 System-Wide Change proposal: GCC9

2019-01-29 Thread Daniel P . Berrangé
On Mon, Jan 21, 2019 at 03:16:56PM -0500, Ben Cotton wrote:
> [This proposal was submitted after the deadline. I am announcing it
> for community discussion and will leave the decision on whether or not
> to grant an exception to FESCo]
> 
> https://fedoraproject.org/wiki/Changes/GCC9
> 
> == Summary ==
> Switch GCC in Fedora 30 to 9.x.y, rebuild all packages with it, or
> optionally rebuild just some packages with it and rebuild all packages
> only in Fedora 31.
> 
> == Owner ==
> * Name: [[User:jakub| Jakub Jelínek]]
> * Email: ja...@redhat.com
> 
> 
> == Detailed Description ==
> GCC 9 is currently in stage4 since January 7th, in prerelease state
> with only regression bugfixes and documentation fixes allowed.  The
> release will happen probably in the middle of April.
> rpms have been built are since today in rawhide.


> == User Experience ==
> Developers will notice a newer compiler, and might need to adjust
> their codebases acording to http://gcc.gnu.org/gcc-9/porting_to.html,
> or, if they detect a GCC bug, report it.

Libvirt has hit a problem with -Wjump-misses-init newly reporting bogus
warnings for code using anonymous struct initializers during assignments:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061
  https://bugzilla.redhat.com/show_bug.cgi?id=1669489

It is quite an ununfortunate bug as it is not straightforward to workaround
the bogus warning by changing code, while we also don't want to disable
-Wjump-misses-init since it is a useful/important warning in general.
So we'd really like to see the regression fixed before F30 GA.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: MongoDB Removal

2019-01-29 Thread Florian Weimer
* Nicolas Mailhot:

> Le 2019-01-29 11:39, Miro Hrončok a écrit :
>
>> This is not true. This page needs to list all dependent packages on
>> Mongo and all dependent packages on Mongo connectors (such as
>> python-pymongo). The change should explain if other packagers are
>> expected to remove the functionality from their packages or if the
>> change owners will do that.
>
> I should point out that pulp depends on mongodb. At one time pulp and
> foreman were presented as the Fedora infra future in many public
> forums and conferences.

Pulp 3 uses PostgreSQL and Redis:



(Note that while parts of the Redis ecosystem are no longer FLOSS, Redis
itself still is.)

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: Bash 5.0

2019-01-29 Thread Igor Gnatenko
That doesn't help until there is Ursa Major or some alternative deployed.

The reason for that is that we would need to maintain 2 copies of
bash, one for users and one for buildroot. I do that for libgit2 and
it is painful.

On Tue, Jan 29, 2019 at 11:53 AM Matthew Miller
 wrote:
>
> On Tue, Jan 29, 2019 at 02:43:39AM -0500, Siteshwar Vashisht wrote:
> > I agree that it would be much safer to target it for Fedora 31. I have no
> > objection if we change target release.
>
> What about building it as a module, with Bash 4 as the default stream for
> F30 and a plan to switch that to 5 for F31?
>
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[Bug 1670372] New: Upgrade perl-Net-SFTP-Foreign to 1.90

2019-01-29 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1670372

Bug ID: 1670372
   Summary: Upgrade perl-Net-SFTP-Foreign to 1.90
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Net-SFTP-Foreign
  Assignee: fedora...@rule.lv
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: fedora...@rule.lv, jples...@redhat.com,
perl-devel@lists.fedoraproject.org,
zonexpertconsult...@outlook.com
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 1.89 version. Upstream released 1.90. When you have free
time, please upgrade it.

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


Orphaning pl (SWI Prolog)

2019-01-29 Thread Petr Pisar
I have no interest in maintaining pl (SWI Prolog) package and thus I'm
going to orphan it.

The package is a Prolog langugage interpreter with bundled various
libraries and tools written in that language. E.g. an HTTP server or an
interface to Java virtual machine.

Upstream does a new major release roughly every year and a few bug-fix
releases during the year.

From packaging point of view there are few downs like:

Reviewing each rebase for licenses is tiresome due the size (118 MB).
Upstream does not like how it is packaged because Fedora bends it to FHS.
Fedora does not like how it is packaged because it's not bended enough.
There are occasional FTBFS when JVM reorganizes its files.
The package should be renamed to swipl to match the upstream.
The source archive is stripped down from non-free files.

The pl package has two comaintainers, mef and bagnara, who did not touch the
pacakge for last 10 years.

The package is required when building and running these source packages:

perl-Language-Prolog-Yaswi  ppisar,jplesnik Can be removed.
ppl bagnara,pcpaA subpackage can be disabled.
python-pyswip   thofmannA subpackage can be disabled.

The package builds fine now and a new 8.1 release is waiting for
packaging.

If you want to take over a maintainership of this package, let me know
and I will assign it to you. Otherwise I will orphan it next week.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Attempt to update ispc

2019-01-29 Thread Florian Weimer
* Dridi Boukelmoune:

>> I've seen this errror before. It's uusally caused by upstream accidentally 
>> overriding CFLAGS instead appending to already set CFLAGS, which breaks 
>> fedora builds. Look for something like "set *CFLAGS* (foo bar)" in 
>> CMakeLists.txt files, and change it to *append* to the already existing 
>> value (coming from fedora settings), instead of overriding it.
>
> Actually, upstream should prepend its own CFLAGS et al to give
> precedence to user-defined flags.

The ispc compiler unfortunately has a completely different command line
syntax from what we use in CFLAGS, so this is not going to work anyway.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [Late] F30 System-Wide Change proposal: GCC9

2019-01-29 Thread Jakub Jelinek
On Tue, Jan 29, 2019 at 07:07:02AM -0500, Siteshwar Vashisht wrote:
> 
> 
> - Original Message -
> > From: "Jakub Jelinek" 
> > To: "Development discussions related to Fedora" 
> > 
> > Sent: Monday, January 21, 2019 10:51:32 PM
> > Subject: Re: [Late] F30 System-Wide Change proposal: GCC9
> > 
> > The release notes are WIP, more will come when it is written, many new
> > features
> > are just not described there yet.
> 
> One of my packages broke because gcc now prints line numbers with error 
> messages. Just in case anyone else is facing similar issue.

'-fno-diagnostics-show-caret'
 By default, each diagnostic emitted includes the original source
 line and a caret '^' indicating the column.  This option suppresses
 this information.  The source line is truncated to N characters, if
 the '-fmessage-length=n' option is given.  When the output is done
 to the terminal, the width is limited to the width given by the
 'COLUMNS' environment variable or, if not set, to the terminal
 width.

'-fno-diagnostics-show-labels'
 By default, when printing source code (via
 '-fdiagnostics-show-caret'), diagnostics can label ranges of source
 code with pertinent information, such as the types of expressions:

  printf ("foo %s bar", long_i + long_j);
   ~^   ~~~
|  |
char * long int

 This option suppresses the printing of these labels (in the example
 above, the vertical bars and the "char *" and "long int" text).

'-fno-diagnostics-show-line-numbers'
 By default, when printing source code (via
 '-fdiagnostics-show-caret'), a left margin is printed, showing line
 numbers.  This option suppresses this left margin.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [Late] F30 System-Wide Change proposal: GCC9

2019-01-29 Thread Siteshwar Vashisht


- Original Message -
> From: "Jakub Jelinek" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, January 21, 2019 10:51:32 PM
> Subject: Re: [Late] F30 System-Wide Change proposal: GCC9
> 
> The release notes are WIP, more will come when it is written, many new
> features
> are just not described there yet.

One of my packages broke because gcc now prints line numbers with error 
messages. Just in case anyone else is facing similar issue.

> 
>   Jakub
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 

-- 
--
Siteshwar Vashisht
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Orphaning: xsel

2019-01-29 Thread Mikolaj Izdebski
Hi Tomas,

On Mon, Jan 28, 2019 at 2:19 PM Tomas Radej  wrote:
> I am orphaning xsel as I don't have time to maintain it. The recent gcc 
> update means xsel no longer compiles.
>
> I am not sure if it is worth maintaining xsel when xclip is packaged as well, 
> so if someone think so, please take the package.

I can take xsel. Please transfer it to me. I will fix FTBFS (caused by
-Werror -Wall, sigh).

--
Mikolaj

>
> Thank you,
>
> --
> Tomas Radej
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Orphaning glacier-cli

2019-01-29 Thread Miroslav Suchý
Hi,
I just orphaned `glacier-cli` package.

It is command line utility for AWS Glacier service. I no longer use the Glacier 
and instead I am using B2, therefore I
am not using this package at all.
It need some love: update to recent version, migrate to python3 and I do not 
want to spend my time on this.

Feel free to take it if you want to.

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Attempt to update ispc

2019-01-29 Thread Dridi Boukelmoune
> I've seen this errror before. It's uusally caused by upstream accidentally 
> overriding CFLAGS instead appending to already set CFLAGS, which breaks 
> fedora builds. Look for something like "set *CFLAGS* (foo bar)" in 
> CMakeLists.txt files, and change it to *append* to the already existing value 
> (coming from fedora settings), instead of overriding it.

Actually, upstream should prepend its own CFLAGS et al to give
precedence to user-defined flags.

Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Nonresponsive maintainer Matthias Saou

2019-01-29 Thread Matthias Saou
On Mon, 28 Jan 2019 17:51:58 +0100
Miro Hrončok  wrote:

> https://bugzilla.redhat.com/show_bug.cgi?id=1323249
> 
> Anyone knows how to reach Matthias?

Yes! That email address does actually work :-)

Sorry. Being too optimistic about what I can juggle with for way too
long now, and (family) life "happening"...

I'll look into it today, and if I don't, please move forward with
applying the nonresponsive maintainer procedure!

Matthias

-- 
Matthias Saou  ██  ██
 ██  ██
Web: http://matthias.saou.eu/  ██
Mail/XMPP:  matth...@saou.eu   ██  
   ██
GPG: 4096R/E755CC63██  ██  ██
 8D91 7E2E F048 9C9C 46AF  ██  ██  ██  ██
 21A9 7A51 7B82 E755 CC63  
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: MongoDB Removal

2019-01-29 Thread Vít Ondruch

Dne 29. 01. 19 v 11:39 Miro Hrončok napsal(a):
> On 29. 01. 19 11:29, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/MongoDB_Removal
>>
>> == Summary ==
>> Fedora has determined that the Server Side Public Licensev1 (SSPL) is
>> not a Free Software License. Therefore, we need to drop MongoDB from
>> Fedora.
>
> While I'm in favor of the removal, I don't think this is entirely true.
>
> It should read:
>
> > Therefore, we need to drop MongoDB from Fedora or never update it
> again.
> > Never updating it would bring security issues, hence we decided to
> remove it.
>
> > Other developers: N/A (not a System Wide Change)
>
> This is not true. This page needs to list all dependent packages on
> Mongo and all dependent packages on Mongo connectors (such as
> python-pymongo). 


Yes, right. There is rubygem-mongo and rubygem-mongoid and they will
become FTBFS without MongoDB. The test suite could be disabled, but this
will be unfortunate, because historically it helped to uncover issues on
some of our arches.


Vít



> The change should explain if other packagers are expected to remove
> the functionality from their packages or if the change owners will do
> that.
>
> If we just remove Mongo, it will cause broken deps.
>
> Also, do we plan to move Mongo to the famous other repo (I assume
> nonfree section)?
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Attempt to update ispc

2019-01-29 Thread Florian Weimer
* Luya Tshimbalanga:

> I managed to resolve some issue but now the problem is related to the
> hardened part:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=32324093
>
> Here is the following lines for the failure:
>
> BUILDSTDERR: /usr/bin/ld: kernels_ispc_sse2.o: relocation R_X86_64_32
> against symbol
> `RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_sse2'
> can not be used when making a PIE object; recompile with -fPIC
> BUILDSTDERR: /usr/bin/ld: kernels_ispc_sse4.o: relocation R_X86_64_32S
> against `.rodata.cst16' can not be used when making a PIE object;
> recompile with -fPIC
> BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx.o: relocation R_X86_64_32
> against symbol
> `RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_avx'
> can not be used when making a PIE object; recompile with -fPIC
> BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx2.o: relocation R_X86_64_32S
> against `.rodata.cst32' can not be used when making a PIE object;
> recompile with -fPIC
> BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx512knl.o: relocation
> R_X86_64_32 against symbol
> `RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_avx512knl'
> can not be used when making a PIE object; recompile with -fPIC
> BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx512skx.o: relocation
> R_X86_64_32 against symbol
> `RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_avx512skx'
> can not be used when making a PIE object; recompile with -fPIC
> BUILDSTDERR: /usr/bin/ld: final link failed: nonrepresentable section on
> output
> BUILDSTDERR: collect2: error: ld returned 1 exit status
> BUILDSTDERR: make[2]: ***
> [examples/deferred/CMakeFiles/deferred_shading.dir/build.make:204:
> bin/deferred_shading] Error 1
> BUILDSTDERR: make[1]: *** [CMakeFiles/Makefile2:370:
> examples/deferred/CMakeFiles/deferred_shading.dir/all] Error 2
> BUILDSTDERR: make: *** [Makefile:133: all] Error 2

I tried to build with --pic, using the attached patch, but got this:

[ 68%] Generating perfbench_ispc.h, perfbench_ispc.o, perfbench_ispc_sse2.h, 
perfbench_ispc_sse2.o, perfbench_ispc_sse4.h, perfbench_ispc_sse4.o, 
perfbench_ispc_avx.h, perfbench_ispc_avx.o, perfbench_ispc_avx2.h, 
perfbench_ispc_avx2.o, perfbench_ispc_avx512knl.h, perfbench_ispc_avx512knl.o, 
perfbench_ispc_avx512skx.h, perfbench_ispc_avx512skx.o
cd /builddir/build/BUILD/ispc-1.10.0/examples/perfbench && ../../bin/ispc 
/builddir/build/BUILD/ispc-1.10.0/examples/perfbench/perfbench.ispc --pic 
--target=sse2-i32x4,sse4-i32x4,avx1-i32x8,avx2-i32x8,avx512knl-i32x16,avx512skx-i32x16
 --arch=x86-64 -h 
/builddir/build/BUILD/ispc-1.10.0/examples/perfbench/perfbench_ispc.h -o 
/builddir/build/BUILD/ispc-1.10.0/examples/perfbench/perfbench_ispc.o
make[2]: Leaving directory '/builddir/build/BUILD/ispc-1.10.0'
BUILDSTDERR: /builddir/build/BUILD/ispc-1.10.0/src/main.cpp(353): FATAL ERROR: 
Unhandled signal sent to process; terminating.
BUILDSTDERR: ***
BUILDSTDERR: *** Please file a bug report at https://github.com/ispc/ispc/issues
BUILDSTDERR: *** (Including as much information as you can about how to 
reproduce this error).
BUILDSTDERR: *** You have apparently encountered a bug in the compiler that 
we'd like to fix!
BUILDSTDERR: ***
BUILDSTDERR: make[2]: *** 
[examples/perfbench/CMakeFiles/perfbench.dir/build.make:65: 
examples/perfbench/perfbench_ispc.h] Aborted (core dumped)

This looks like something upstream needs to investigate. 8-(

Thanks,
Florian

The examples are linked as PIE, so position-independent code is needed.
ispc only supports --pic, so use that.

diff --git a/examples/cmake/AddISPCExample.cmake 
b/examples/cmake/AddISPCExample.cmake
index dbd80e7643b9f803..a88d2e5279fad32a 100644
--- a/examples/cmake/AddISPCExample.cmake
+++ b/examples/cmake/AddISPCExample.cmake
@@ -93,7 +93,7 @@ function(add_ispc_example)
 endif()
 # ISPC command
 add_custom_command(OUTPUT ${ISPC_BUILD_OUTPUT}
-COMMAND ${ISPC_EXECUTABLE} 
${CMAKE_CURRENT_SOURCE_DIR}/${ISPC_SRC_NAME}.ispc ${example_ISPC_FLAGS} 
--target=${ISPC_TARGETS} --arch=${ISPC_ARCH}
+COMMAND ${ISPC_EXECUTABLE} 
${CMAKE_CURRENT_SOURCE_DIR}/${ISPC_SRC_NAME}.ispc ${example_ISPC_FLAGS} --pic 
--target=${ISPC_TARGETS} --arch=${ISPC_ARCH}
 -h ${ISPC_HEADER_NAME} -o ${ISPC_OBJ_NAME}
 VERBATIM
 DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/${ISPC_SRC_NAME}.ispc")
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Re: F30 Self-Contained Change proposal: MongoDB Removal

2019-01-29 Thread Nicolas Mailhot

Le 2019-01-29 11:39, Miro Hrončok a écrit :


This is not true. This page needs to list all dependent packages on
Mongo and all dependent packages on Mongo connectors (such as
python-pymongo). The change should explain if other packagers are
expected to remove the functionality from their packages or if the
change owners will do that.


I should point out that pulp depends on mongodb. At one time pulp and 
foreman were presented as the Fedora infra future in many public forums 
and conferences.


I suppose this is now over but it would be nice to have a confirmation 
on the infra bits Fedora endorses (or not). Starting with repo 
management, since any entity that wants to set up a private infra as 
clearing room before contributing to Fedora, will need one of those


Regards,

--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: MongoDB Removal

2019-01-29 Thread Miro Hrončok

On 29. 01. 19 11:29, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/MongoDB_Removal

== Summary ==
Fedora has determined that the Server Side Public Licensev1 (SSPL) is
not a Free Software License. Therefore, we need to drop MongoDB from
Fedora.


While I'm in favor of the removal, I don't think this is entirely true.

It should read:

> Therefore, we need to drop MongoDB from Fedora or never update it again.
> Never updating it would bring security issues, hence we decided to remove it.

> Other developers: N/A (not a System Wide Change)

This is not true. This page needs to list all dependent packages on Mongo and 
all dependent packages on Mongo connectors (such as python-pymongo). The change 
should explain if other packagers are expected to remove the functionality from 
their packages or if the change owners will do that.


If we just remove Mongo, it will cause broken deps.

Also, do we plan to move Mongo to the famous other repo (I assume nonfree 
section)?

--
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: Improved GRUB menu

2019-01-29 Thread Matthew Miller
On Tue, Jan 29, 2019 at 05:29:51AM -0500, Ben Cotton wrote:
> Improve the GRUB menu by only having the default boot option for each
> installed operating system in the main menu, and the other options
> into a sub-menu. This would better organize the boot options and lead
> to an easier and seamless boot experience.

+1. I often see new users asking "why are there multiple Fedora choices?", or
"which kernel should I use?"

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: Bash 5.0

2019-01-29 Thread Matthew Miller
On Tue, Jan 29, 2019 at 02:43:39AM -0500, Siteshwar Vashisht wrote:
> I agree that it would be much safer to target it for Fedora 31. I have no
> objection if we change target release.

What about building it as a module, with Bash 4 as the default stream for
F30 and a plan to switch that to 5 for F31?


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30 Self-Contained Change proposal: Retire YUM 3

2019-01-29 Thread Matthew Miller
On Mon, Jan 28, 2019 at 06:41:26PM +0100, Miro Hrončok wrote:
> >This feels more like system-wide change…
> >Especially since you say that some extra packages will be retired.
> 
> A very limited set. The distro as a whole should not be impacted by this.
> 
> The retired packages are legacy cruft. And the important stuff that
> needs to be updated needs some motivation like this.

"This change needs to motivate other important stuff that we don't have
direct control over to change" seems like *exactly* the reason we ask for
system-wide changes to be filed earlier.



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


REMINDER: Software string freeze in one week

2019-01-29 Thread Ben Cotton
This is your reminder that the software string freeze deadline is
Tuesday, 5 February 2019.

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org


F30 Self-Contained Change proposal: MongoDB Removal

2019-01-29 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/MongoDB_Removal

== Summary ==
Fedora has determined that the Server Side Public Licensev1 (SSPL) is
not a Free Software License. Therefore, we need to drop MongoDB from
Fedora.

== Owner ==
* Name: [[User:panovotn| Patrik Novotný]]

* Email: panov...@redhat.com


-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org


F30 Self-Contained Change proposal: Improved GRUB menu

2019-01-29 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/ImprovedGrubMenu

== Summary ==

Improve the GRUB menu by only having the default boot option for each
installed operating system in the main menu, and the other options
into a sub-menu. This would better organize the boot options and lead
to an easier and seamless boot experience.

== Owner ==
* Name: [[User:Javierm|Javier Martinez Canillas]]
* Email: javi...@redhat.com


== Detailed Description ==

The current GRUB menu is confusing, specially when multiple operating
systems are installed. The Fedora boot entries are added first and
then the ones for the other installed operating systems.

The main menu contains all the boot entries for Fedora but only the
default boot entry for the other operating systems, the non-default
boot entries for the other installed operating systems are placed into
a per operating system sub-menu.

An example of how the GRUB menu currently looks can be found at
[https://javierm.fedorapeople.org/grub2/menu/fedora_menu.png
https://javierm.fedorapeople.org/grub2/menu/fedora_menu.png]

This can be improved by adding a sub-menu for the Fedora non-default
boot entries, as is already the case for the other installed operating
systems. This will make the boot entries for all the operating systems
consistent.

Another improvement would be to group all the default options for the
operating systems as one section, followed by another section that
groups all the sub-menus for the non-default options.

A tentative design made by Allan Day for the improved GRUB menu can be
found at [https://wiki.gnome.org/Design/OS/BootOptions#Tentative_Design
https://wiki.gnome.org/Design/OS/BootOptions#Tentative_Design]

For Fedora, the boot option in the main menu will either be the
selected default boot entry or if no default was chosen, the latest
installed kernel. For the other installed operating systems, the boot
option in the main menu will be the latest kernel as found by GRUB's
os-prober script.

== Benefit to Fedora ==

Making the menu less confusing and with better organized boot options
will lead to a better user experience and make easier for users to
choose the operating systems to boot.

== Scope ==
* Proposal owners:
# Change GRUB to implement the changes as described in the "Detailed
Description" section.
# Make sure this is all properly documented in release-notes, etc.

* Other developers:
# Test and watch for regressions.
* Policies and guidelines:  The policies and guidelines do not need to
be updated.
* Trademark approval: No changes needed.

== Upgrade/compatibility impact ==

The changes are in the grub.cfg file generated at install time by
Anaconda. Users can manually enable this after an upgrade by executing
gru2-mkconfig to regenerate their grub.cfg file.

== How To Test ==
# Single OS test
## Install Fedora in a VM.
## On boot the default boot option is in the main menu and the other
options (e.g: rescue boot option) are in a sub-menu.
# Multi boot test
## Install Fedora on a machine which other operating system installed.
## On boot the default boot options for the operating systems are in
the main menu and the other options in sub-menus.

== User Experience ==

A simpler and easier to understand GRUB boot menu. Choosing which
operating system to boot should be simpler and involve less steps.

== Dependencies ==
None

== Contingency Plan ==
* Contingency mechanism: Revert the GRUB changes.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? None

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org


REMINDER: Software string freeze in one week

2019-01-29 Thread Ben Cotton
This is your reminder that the software string freeze deadline is
Tuesday, 5 February 2019.

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


F30 Self-Contained Change proposal: MongoDB Removal

2019-01-29 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/MongoDB_Removal

== Summary ==
Fedora has determined that the Server Side Public Licensev1 (SSPL) is
not a Free Software License. Therefore, we need to drop MongoDB from
Fedora.

== Owner ==
* Name: [[User:panovotn| Patrik Novotný]]

* Email: panov...@redhat.com


-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


F30 Self-Contained Change proposal: Improved GRUB menu

2019-01-29 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/ImprovedGrubMenu

== Summary ==

Improve the GRUB menu by only having the default boot option for each
installed operating system in the main menu, and the other options
into a sub-menu. This would better organize the boot options and lead
to an easier and seamless boot experience.

== Owner ==
* Name: [[User:Javierm|Javier Martinez Canillas]]
* Email: javi...@redhat.com


== Detailed Description ==

The current GRUB menu is confusing, specially when multiple operating
systems are installed. The Fedora boot entries are added first and
then the ones for the other installed operating systems.

The main menu contains all the boot entries for Fedora but only the
default boot entry for the other operating systems, the non-default
boot entries for the other installed operating systems are placed into
a per operating system sub-menu.

An example of how the GRUB menu currently looks can be found at
[https://javierm.fedorapeople.org/grub2/menu/fedora_menu.png
https://javierm.fedorapeople.org/grub2/menu/fedora_menu.png]

This can be improved by adding a sub-menu for the Fedora non-default
boot entries, as is already the case for the other installed operating
systems. This will make the boot entries for all the operating systems
consistent.

Another improvement would be to group all the default options for the
operating systems as one section, followed by another section that
groups all the sub-menus for the non-default options.

A tentative design made by Allan Day for the improved GRUB menu can be
found at [https://wiki.gnome.org/Design/OS/BootOptions#Tentative_Design
https://wiki.gnome.org/Design/OS/BootOptions#Tentative_Design]

For Fedora, the boot option in the main menu will either be the
selected default boot entry or if no default was chosen, the latest
installed kernel. For the other installed operating systems, the boot
option in the main menu will be the latest kernel as found by GRUB's
os-prober script.

== Benefit to Fedora ==

Making the menu less confusing and with better organized boot options
will lead to a better user experience and make easier for users to
choose the operating systems to boot.

== Scope ==
* Proposal owners:
# Change GRUB to implement the changes as described in the "Detailed
Description" section.
# Make sure this is all properly documented in release-notes, etc.

* Other developers:
# Test and watch for regressions.
* Policies and guidelines:  The policies and guidelines do not need to
be updated.
* Trademark approval: No changes needed.

== Upgrade/compatibility impact ==

The changes are in the grub.cfg file generated at install time by
Anaconda. Users can manually enable this after an upgrade by executing
gru2-mkconfig to regenerate their grub.cfg file.

== How To Test ==
# Single OS test
## Install Fedora in a VM.
## On boot the default boot option is in the main menu and the other
options (e.g: rescue boot option) are in a sub-menu.
# Multi boot test
## Install Fedora on a machine which other operating system installed.
## On boot the default boot options for the operating systems are in
the main menu and the other options in sub-menus.

== User Experience ==

A simpler and easier to understand GRUB boot menu. Choosing which
operating system to boot should be simpler and involve less steps.

== Dependencies ==
None

== Contingency Plan ==
* Contingency mechanism: Revert the GRUB changes.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? None

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Attempt to update ispc

2019-01-29 Thread Fabio Valentini
On Tue, Jan 29, 2019, 05:21 Luya Tshimbalanga  I managed to resolve some issue but now the problem is related to the
> hardened part:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=32324093
>
> Here is the following lines for the failure:
>
> BUILDSTDERR: /usr/bin/ld: kernels_ispc_sse2.o: relocation R_X86_64_32
> against symbol
>
> `RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_sse2'
> can not be used when making a PIE object; recompile with -fPIC
> BUILDSTDERR: /usr/bin/ld: kernels_ispc_sse4.o: relocation R_X86_64_32S
> against `.rodata.cst16' can not be used when making a PIE object;
> recompile with -fPIC
>

I've seen this errror before. It's uusally caused by upstream accidentally
overriding CFLAGS instead appending to already set CFLAGS, which breaks
fedora builds. Look for something like "set *CFLAGS* (foo bar)" in
CMakeLists.txt files, and change it to *append* to the already existing
value (coming from fedora settings), instead of overriding it.

Fabio

BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx.o: relocation R_X86_64_32
> against symbol
>
> `RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_avx'
> can not be used when making a PIE object; recompile with -fPIC
> BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx2.o: relocation R_X86_64_32S
> against `.rodata.cst32' can not be used when making a PIE object;
> recompile with -fPIC
> BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx512knl.o: relocation
> R_X86_64_32 against symbol
>
> `RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_avx512knl'
> can not be used when making a PIE object; recompile with -fPIC
> BUILDSTDERR: /usr/bin/ld: kernels_ispc_avx512skx.o: relocation
> R_X86_64_32 against symbol
>
> `RenderTile___uniuniREFs_5B_unInputHeader_5D_REFs_5B_unInputDataArrays_5D_uniun_3C_unT_3E_un_3C_unT_3E_un_3C_unT_3E_avx512skx'
> can not be used when making a PIE object; recompile with -fPIC
> BUILDSTDERR: /usr/bin/ld: final link failed: nonrepresentable section on
> output
> BUILDSTDERR: collect2: error: ld returned 1 exit status
> BUILDSTDERR: make[2]: ***
> [examples/deferred/CMakeFiles/deferred_shading.dir/build.make:204:
> bin/deferred_shading] Error 1
> BUILDSTDERR: make[1]: *** [CMakeFiles/Makefile2:370:
> examples/deferred/CMakeFiles/deferred_shading.dir/all] Error 2
> BUILDSTDERR: make: *** [Makefile:133: all] Error 2
>
>
>
> Luya
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Orphaned packages to be retired

2019-01-29 Thread Miro Hrončok

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

I plan to retire packages that were already announced 3 times next Monday.

Unorphan/unretire packages at https://pagure.io/releng/issues

(I still cannot unorphan packages, but rest assured that I monitor the tracker
and I'm not retiring packages that have open request for unorphaning.)

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Remarks: Some packages are falsely reported as orphaned for 60+ weeks.
The issue was reported and I won't retire them sooner than after real 6 weeks.
Sorry about that.

  Package  (co)maintainers Status Change

RunSnakeRun   orphan   2 weeks ago
autotrash frafra, orphan, robyduck 4 weeks ago
bouml orphan   6 weeks ago
bouml-doc orphan   6 weeks ago
catkinorphan, rmattes, robotics-sig,   1 weeks ago
  thofmann
dnsyo codeblock, orphan2 weeks ago
ecryptfs-simple   orphan   6 weeks ago
fasd  orphan   4 weeks ago
hoard orphan   29 weeks ago
jlibrtp   orphan   6 weeks ago
jmake orphan   6 weeks ago
labyrinth orphan   0 weeks ago
memaker   orphan   0 weeks ago
python-ceilometermiddleware   orphan   68 weeks ago
python-cookiesadamwill, orphan 4 weeks ago
python-gencpp orphan, rmattes, robotics-sig,   1 weeks ago
  thofmann
python-genlisporphan, rmattes, robotics-sig,   1 weeks ago
  thofmann
python-genmsg orphan, rmattes, robotics-sig,   1 weeks ago
  thofmann
python-genpy  orphan, rmattes, robotics-sig,   1 weeks ago
  thofmann
python-gnocchiclient  orphan   77 weeks ago
python-kafka  orphan   77 weeks ago
python-pankoclientorphan   77 weeks ago
python-pytimeparseorphan   77 weeks ago
python-ripe-atlas-cousteauorphan   4 weeks ago
python-ripe-atlas-sagan   orphan   4 weeks ago
python-socketIO-clientorphan   4 weeks ago
ripe-atlas-tools  orphan   4 weeks ago
ros-release   orphan, rmattes, robotics-sig,   1 weeks ago
  thofmann
rospack   orphan, rmattes, robotics-sig,   1 weeks ago
  thofmann
scout orphan   0 weeks ago
toothchartorphan   0 weeks ago
tristripper   orphan   6 weeks ago
unp   mstuchli, orphan, python-sig 2 weeks ago
wifi-radarblackfile, orphan4 weeks ago
winetricksekulik, orphan, raphgro, tc011 weeks ago
xword orphan   0 weeks ago

The following packages require above mentioned packages:
Depending on: catkin (4), status change: 2019-01-20 (1 weeks ago)
python-gencpp (maintained by: orphan, rmattes, robotics-sig, thofmann)
		python-gencpp-0.3.4-14.20130623git403d067.fc29.src requires catkin-devel = 
0.4.5-19.gitd4f1f24.fc29


python-genlisp (maintained by: orphan, rmattes, robotics-sig, thofmann)
		python-genlisp-0.3.3-14.20130623git8790a17.fc29.src requires catkin-devel = 
0.4.5-19.gitd4f1f24.fc29


python-genmsg (maintained by: orphan, rmattes, robotics-sig, thofmann)
		python-genmsg-0.3.10-16.20130617git95ca00d.fc28.src requires catkin-devel =