date:20220629

No missing expected images.

Failed openQA tests: 1/15 (aarch64)

Old failures (same test failed in Fedora-IoT-36-20220624.0):

ID: 1311180 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1311180

Passed openQA tests: 15/15 (x86_64), 14/15 (aarch64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.04 to 0.16
Previous test data: https://openqa.fedoraproject.org/tests/1305736#downloads
Current test data: https://openqa.fedoraproject.org/tests/1311137#downloads

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.37 to 0.23
Previous test data: https://openqa.fedoraproject.org/tests/1305751#downloads
Current test data: https://openqa.fedoraproject.org/tests/1311166#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fix aarch64 build on embree

2022-06-29 Thread Luya Tshimbalanga


On 2022-06-29 01:24, Peter Robinson wrote:

On Wed, Jun 29, 2022 at 3:15 AM Luya Tshimbalanga
  wrote:

Hello team,

What is the way to disable `-mss2 for aarch64 build in embree?

I think you mean msse2, the build should be using the distro default C
flags for builds so it shouldn't be an issue, if you fix the build to
use the proper distro flags the problem should go away. Details in the
docs:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags

Which is strange as the used flag is `%{optflags} -Wl,--as-needed`as 
listed on the attached spec file.


Extract:

export CXXFLAGS="%{optflags} -Wl,--as-needed"

The issue currently affects the new version of embree.



--


Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
%global __cmake_in_source_build 1

%global		with_snapshot	0
%global		with_examples	0
#%%global		prerelease	beta
#%%global		commit		40b9aca2668f443cae6bfbfa7cc5a354f1087011
#%%global		shortcommit	%%(c=%%{commit}; echo ${c:0:7})
%ifarch x86_64 aarch64
%bcond_without  ispc
%else
%bcond_with ispc
%endif

Name:		embree
Version:	3.13.4
Release:	%autorelease
Summary:	Collection of high-performance ray tracing kernels

License:	ASL 2.0
URL:		https://embree.github.io
%if %{with_snapshot}
Source:		https://github.com/%{name}/%{name}/archive/%{commit}/%{name}-%{commit}.tar.gz#/%{name}-%{version}-%{shortcommit}.tar.gz
%else
Source:		https://github.com/%{name}/%{name}/archive/v%{version}%{?prerelease:%{-prerelease}.0}.tar.gz#/%{name}-%{version}%{?prerelease:-%{prerelease}.0}.tar.gz
%endif

BuildRequires:	cmake
BuildRequires:	gcc-c++
BuildRequires:	giflib-devel
%if %{with ispc} 
BuildRequires:	ispc
%endif
BuildRequires:	pkgconfig(glut)
BuildRequires:	pkgconfig(glfw3)
BuildRequires:	pkgconfig(xmu)
# Optional dependencies needed for examples
%if %{with_examples}
BuildRequires:	pkgconfig(libjpeg)
BuildRequires:	pkgconfig(libopenjp2)
BuildRequires:	pkgconfig(libpng)
BuildRequires:	pkgconfig(libtiff-4)
BuildRequires:	pkgconfig(OpenImageIO)
%endif
BuildRequires:	pkgconfig(tbb)

# Exclude architectures failing to support SSE2 and up
ExcludeArch:	armv7hl i686 ppc64le s390x

%description
A collection of high-performance ray tracing kernels intended to graphics 
application engineers that want to improve the performance of their application.

%package	devel
Summary:	Development files for %{name}
Requires:	%{name}%{?_isa} = %{version}-%{release}

%description	devel
The %{name}-devel package contains libraries and header files for
 applications that use %{name}.

%if %{with_examples}
%package	examples
Summary:	Example of application using %{name}
Requires:	%{name}%{?_isa} = %{version}-%{release}

%description	examples
The %{name}-examples package contains sample binaries using %{name}.
%endif

%prep
%if %{with_snapshot}
%autosetup -n %{name}-%{commit}
%else 
%autosetup -n %{name}-%{version}%{?prerelease:-%{prerelease}.0}
%endif

%build
export CXXFLAGS="%{optflags} -Wl,--as-needed"
%cmake \
	-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_CXX_STANDARD=17 \
	-DCMAKE_INSTALL_LIBDIR=%{_libdir} \
	-DCMAKE_INSTALL_PREFIX=%{_prefix} \
	-DEMBREE_COMPACT_POLYS=ON \
	-DEMBREE_IGNORE_CMAKE_CXX_FLAGS=OFF \
%if %{with ispc}
-DEMBREE_ISPC_SUPPORT=ON \
%else
-DEMBREE_ISPC_SUPPORT=OFF \
%endif
-DEMBREE_MAX_ISA=DEFAULT \
	-DEMBREE_TUTORIALS=OFF 
%cmake_build

%install
%cmake_install

# Relocate doc files
mv %{buildroot}%{_docdir}/%{name}3 %{buildroot}%{_docdir}/%{name}
rm %{buildroot}%{_docdir}/%{name}/LICENSE.txt

%files
%license LICENSE.txt
%doc README.md CHANGELOG.md readme.pdf third-party-programs-TBB.txt third-party-programs.txt
%{_libdir}/lib%{name}3.so.3
%{_libdir}/lib%{name}3.so.3.*
%{_mandir}/man3/*

%files devel
%{_libdir}/lib%{name}3.so
%{_includedir}/%{name}3/
%{_libdir}/cmake/%{name}-%{version}/

%if %{with_examples}
%files examples
%{_bindir}/%{name}3/*
%endif

%changelog
%autochangelog
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fix aarch64 build on embree

2022-06-29 Thread Luya Tshimbalanga



On 2022-06-29 02:05, Petr Pisar wrote:

V Tue, Jun 28, 2022 at 07:08:31PM -0700, Luya Tshimbalanga napsal(a):

Hello team,

What is the way to disable `-mss2 for aarch64 build in embree?

Spec file:
https://src.fedoraproject.org/rpms/embree/blob/rawhide/f/embree.spec

Scratch build result:
https://koji.fedoraproject.org/koji/taskinfo?taskID=88867571


Are you sure your scratch build corresponds to the linked spec file?

The spec file reads:

 %ifarch x86_64
 -DEMBREE_MAX_ISA=SSE4.2 \
 %else
 -DEMBREE_MAX_ISA=NONE \
 %endif

but the build.log shows:

 + /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON 
-DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr 
-DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 
-DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share 
-DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_BUILD_TYPE=Release 
-DCMAKE_CXX_STANDARD=17 -DCMAKE_INSTALL_LIBDIR=/usr/lib64 
-DCMAKE_INSTALL_PREFIX=/usr -DEMBREE_COMPACT_POLYS=ON 
-DEMBREE_IGNORE_CMAKE_CXX_FLAGS=OFF -DEMBREE_ISPC_SUPPORT=ON 
-DEMBREE_MAX_ISA=DEFAULT -DEMBREE_TUTORIALS=OFF

There is -DEMBREE_MAX_ISA=DEFAULT instead of -DEMBREE_MAX_ISA=NONE.
My bad, I should attach the updated spec file yet to get pushed in the 
repository. Here is below.

Morover, I'm not sure whether upstream supports a generic AArch64. README.md
reads:

 Embree requires at least an x86 CPU with support for
 SSE2 or an Apple M1 CPU.

-- Petr




--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
%global __cmake_in_source_build 1

%global		with_snapshot	0
%global		with_examples	0
#%%global		prerelease	beta
#%%global		commit		40b9aca2668f443cae6bfbfa7cc5a354f1087011
#%%global		shortcommit	%%(c=%%{commit}; echo ${c:0:7})
%ifarch x86_64 aarch64
%bcond_without  ispc
%else
%bcond_with ispc
%endif

Name:		embree
Version:	3.13.4
Release:	%autorelease
Summary:	Collection of high-performance ray tracing kernels

License:	ASL 2.0
URL:		https://embree.github.io
%if %{with_snapshot}
Source:		https://github.com/%{name}/%{name}/archive/%{commit}/%{name}-%{commit}.tar.gz#/%{name}-%{version}-%{shortcommit}.tar.gz
%else
Source:		https://github.com/%{name}/%{name}/archive/v%{version}%{?prerelease:%{-prerelease}.0}.tar.gz#/%{name}-%{version}%{?prerelease:-%{prerelease}.0}.tar.gz
%endif

BuildRequires:	cmake
BuildRequires:	gcc-c++
BuildRequires:	giflib-devel
%if %{with ispc} 
BuildRequires:	ispc
%endif
BuildRequires:	pkgconfig(glut)
BuildRequires:	pkgconfig(glfw3)
BuildRequires:	pkgconfig(xmu)
# Optional dependencies needed for examples
%if %{with_examples}
BuildRequires:	pkgconfig(libjpeg)
BuildRequires:	pkgconfig(libopenjp2)
BuildRequires:	pkgconfig(libpng)
BuildRequires:	pkgconfig(libtiff-4)
BuildRequires:	pkgconfig(OpenImageIO)
%endif
BuildRequires:	pkgconfig(tbb)

# Exclude architectures failing to support SSE2 and up
ExcludeArch:	armv7hl i686 ppc64le s390x

%description
A collection of high-performance ray tracing kernels intended to graphics 
application engineers that want to improve the performance of their application.

%package	devel
Summary:	Development files for %{name}
Requires:	%{name}%{?_isa} = %{version}-%{release}

%description	devel
The %{name}-devel package contains libraries and header files for
 applications that use %{name}.

%if %{with_examples}
%package	examples
Summary:	Example of application using %{name}
Requires:	%{name}%{?_isa} = %{version}-%{release}

%description	examples
The %{name}-examples package contains sample binaries using %{name}.
%endif

%prep
%if %{with_snapshot}
%autosetup -n %{name}-%{commit}
%else 
%autosetup -n %{name}-%{version}%{?prerelease:-%{prerelease}.0}
%endif

%build
export CXXFLAGS="%{optflags} -Wl,--as-needed"
%cmake \
	-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_CXX_STANDARD=17 \
	-DCMAKE_INSTALL_LIBDIR=%{_libdir} \
	-DCMAKE_INSTALL_PREFIX=%{_prefix} \
	-DEMBREE_COMPACT_POLYS=ON \
	-DEMBREE_IGNORE_CMAKE_CXX_FLAGS=OFF \
%if %{with ispc}
-DEMBREE_ISPC_SUPPORT=ON \
%else
-DEMBREE_ISPC_SUPPORT=OFF \
%endif
-DEMBREE_MAX_ISA=DEFAULT \
	-DEMBREE_TUTORIALS=OFF 
%cmake_build

%install
%cmake_install

# Relocate doc files
mv %{buildroot}%{_docdir}/%{name}3 %{buildroot}%{_docdir}/%{name}
rm %{buildroot}%{_docdir}/%{name}/LICENSE.txt

%files
%license LICENSE.txt
%doc README.md CHANGELOG.md readme.pdf third-party-programs-TBB.txt third-party-programs.txt
%{_libdir}/lib%{name}3.so.3
%{_libdir}/lib%{name}3.so.3.*
%{_mandir}/man3/*

%files devel
%{_libdir}/lib%{name}3.so
%{_includedir}/%{name}3/
%{_libdir}/cmake/%{name}-%{version}/

%if %{with_examples}
%files examples
%{_bindir}/%{name}3/*
%endif

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

Re: Fix aarch64 build on embree

2022-06-29 Thread Luya Tshimbalanga



On 2022-06-29 01:56, Peter Robinson wrote:

Hello team,

What is the way to disable `-mss2 for aarch64 build in embree?

I think you mean msse2, the build should be using the distro default C
flags for builds so it shouldn't be an issue, if you fix the build to
use the proper distro flags the problem should go away. Details in the
docs:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags


Spec file:https://src.fedoraproject.org/rpms/embree/blob/rawhide/f/embree.spec

Scratch build 
result:https://koji.fedoraproject.org/koji/taskinfo?taskID=88867571

Completely not the right way to fix it, you're note actually supposed
to be overwriting the SSE levels set by the base project else it won't
run on older x86 devices either, but the below worked for me on a
scratch build. The aarch64 arch sets NEON by default so if you were
using the proper defaults you'd actually have gott hat anyway.

diff --git a/embree.spec b/embree.spec
index b2e6d8e..a9e8c91 100644
--- a/embree.spec
+++ b/embree.spec
@@ -92,6 +92,9 @@ export CXXFLAGS="%{optflags} -Wl,--as-needed"
  -DEMBREE_MAX_ISA=SSE4.2 \
  %else
  -DEMBREE_MAX_ISA=NONE \
+%endif
+%ifarch aarch64
+-DEMBREE_MAX_ISA=NEON \
  %endif
 -DEMBREE_TUTORIALS=OFF
  %cmake_build


I figured out that line hence the use of -DEMBREE_MAX_ISA=DEFAULT` as a 
more elegant approach. Unfortunately, the build failed for aarch64 in 
this version compared to its predecessor 3.13.2.




--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unresponsive maintainer: Alex Chernyakhovsky

2022-06-29 Thread Michel Alexandre Salim

On Wed, 2022-06-29 at 20:09 +0200, Vitaly Zaitsev via devel wrote:
> On 29/06/2022 18:47, Robbie Harwood wrote:
> > I don't see how you got there.  Nowhere does it say that the
> > maintainer(s) are removed - just that one is added, and made
> > contact for
> > EPEL bugs.
> 
> Newly added EPEL maintainers can make any changes to Fedora branches.
> I 
> don't like that.
> 
Rest assured, they cannot. The escalation process specifically
documents granting the newly added maintainers collaborator access only
on epel* branches.

We actually made sure collaborator support is properly working before
we document this policy.

Best regards,

-- 
Michel Alexandre Salim
identities:
https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unresponsive maintainer: Alex Chernyakhovsky

2022-06-29 Thread Carl George

If you're happy with the current version 1.0.49 from rawhide being
branched for epel9, then the stalled process would be a good fit.
With collaborator permissions on epel* branches, you can request the
epel9 branch, merge commits from rawhide to epel9, create builds, and
create bodhi updates.

If you're interested in helping with the long term maintenance of the
package, to include getting it updated to the latest version (perhaps
before building it for epel9 so that package can start on the latest
version), then it's worth considering the unresponsive maintainer
process.

On Wed, Jun 29, 2022 at 3:51 PM Chris Adams  wrote:
>
> Jumping in on this... I opened BZ 2095512 a few weeks ago about getting
> pure-ftpd for EPEL 9, with a follow-up a week ago.  There's already an
> EPEL 8 branch, so I guess that maintainer was notified (or do all get
> notified)?
>
> Looking at src.fedoraproject.org, it doesn't look like any of the
> maintainers have been active in a bit, and the only pure-ftpd changes in
> a while have been rebuilds and such.  There's been a couple of new
> upstream releases (one just last week), noted in BZ 2026153, with no
> update to the Fedora or EPEL packages... wondering if any of the
> maintainers are still active.
>
> What's the correct approach here?  I'd need to look at the package to
> see if I'd be interested in taking it on (my BZ request so far was just
> to ask for the existing maintainers to branch it).
>
> --
> Chris Adams 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Carl George
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unresponsive maintainer: Alex Chernyakhovsky

2022-06-29 Thread Chris Adams

Jumping in on this... I opened BZ 2095512 a few weeks ago about getting
pure-ftpd for EPEL 9, with a follow-up a week ago.  There's already an
EPEL 8 branch, so I guess that maintainer was notified (or do all get
notified)?

Looking at src.fedoraproject.org, it doesn't look like any of the
maintainers have been active in a bit, and the only pure-ftpd changes in
a while have been rebuilds and such.  There's been a couple of new
upstream releases (one just last week), noted in BZ 2026153, with no
update to the Fedora or EPEL packages... wondering if any of the
maintainers are still active.

What's the correct approach here?  I'd need to look at the package to
see if I'd be interested in taking it on (my BZ request so far was just
to ask for the existing maintainers to branch it).

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unresponsive maintainer: Alex Chernyakhovsky

2022-06-29 Thread Carl George

On Wed, Jun 29, 2022 at 2:30 PM Vitaly Zaitsev via devel
 wrote:
>
> On 29/06/2022 21:06, Stephen Smoogen wrote:
> > Maintainers are custodians and do not own the package.
>
> This becomes true with the new EPEL policy. I think it should be
> revisited to follow Fedora's non-responsive maintainer procedure with an
> explicit FESCo approval on a case-by-case basis.

It was true before the EPEL stalled policy.  Fedora is all of our
distribution.  No one owns packages, we maintain them.

Requiring FESCo sign off for this on every package would significantly
hamper EPEL growth.  We're not going to do that.

The origin of this policy is that the full unresponsive maintainer
process is overkill for getting a package added to EPEL.  Maintainer1
shouldn't have to suggest that all of maintainer2's packages be
orphaned or assigned to themselves in order to be added as a
collaborator on an EPEL branch.

If you don't like the policy, then you can avoid it simply by handling
EPEL branch requests promptly (faster than 3 weeks).

>
> --
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

-- 
Carl George
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unresponsive maintainer: Alex Chernyakhovsky

2022-06-29 Thread Neal Gompa

On Wed, Jun 29, 2022 at 2:09 PM Vitaly Zaitsev via devel
 wrote:
>
> On 29/06/2022 18:47, Robbie Harwood wrote:
> > I don't see how you got there.  Nowhere does it say that the
> > maintainer(s) are removed - just that one is added, and made contact for
> > EPEL bugs.
>
> Newly added EPEL maintainers can make any changes to Fedora branches. I
> don't like that.
>

They cannot unless they have some other way to get the access already.
EPEL maintainers are added as collaborators on epel branches only
through this policy.



-- 
真実はいつも一つ！/ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unresponsive maintainer: Alex Chernyakhovsky

2022-06-29 Thread Carl George

On Wed, Jun 29, 2022 at 1:09 PM Vitaly Zaitsev via devel
 wrote:
>
> On 29/06/2022 18:47, Robbie Harwood wrote:
> > I don't see how you got there.  Nowhere does it say that the
> > maintainer(s) are removed - just that one is added, and made contact for
> > EPEL bugs.
>
> Newly added EPEL maintainers can make any changes to Fedora branches. I
> don't like that.

This is false.  The EPEL stalled process results in the new maintainer
being added as a collaborator on branches matching the epel* pattern.

>
> --
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Carl George
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

2022-06-29 Thread Daan De Meyer via devel

Given the recent benchmarks from Phoronix 
(https://www.phoronix.com/scan.php?page=article&item=fedora-frame-pointer&num=1)
 on the proposal that showed some surprising results, we went and tried to 
reproduce some of the benchmarks to make sure they were actually making sense.

The first one we looked at is the redis benchmark from 
https://www.phoronix.com/scan.php?page=article&item=fedora-frame-pointer&num=5. 
We were unable to reproduce the results from the Phoronix article.

Redis GET: 
https://user-images.githubusercontent.com/9395011/176536797-7424d40f-7140-46f8-89d3-7b555aa4cd13.png
Redis SET: 
https://user-images.githubusercontent.com/9395011/176536624-eeb5f85c-a63b-4987-8b3b-2b3607be0cf8.png

Instead, we only saw differences from 0%-2% between Redis compiled with frame 
pointers and Redis compiled without frame pointers. These benchmarks were done 
using the phoronix-test-suite in exactly the same way as documented in the 
phoronix article.

The other one we've looked at is the Botan AES-256 benchmark 
(https://www.phoronix.com/scan.php?page=article&item=fedora-frame-pointer&num=2).
 Initially, we were able to reproduce the results of this benchmark when 
setting CXXFLAGS="-fno-omit-frame-pointer". However, what we found here, is 
that due to the way Botan's custom build system works, when the CXXFLAGS 
environment variable is set to enable -fno-omit-frame-pointer, the botan binary 
is built in debug mode without optimizations whereas when CXXFLAGS is unset, 
the botan binary is build in release mode (-O3). This explains the huge 
difference in performance in the botan AES-256 benchmark.

When making sure both binaries are built in release mode by setting 
CXXFLAGS="-O2" and CXXFLAGS="-O2 -fno-omit-frame-pointer" respectively, we get 
the following results :

Without frame pointers:

AES-256 encrypt buffer size 1024 bytes: 5410.085 MiB/sec 0.42 cycles/byte 
(2705.04 MiB in 500.00 ms)
AES-256 decrypt buffer size 1024 bytes: 5407.610 MiB/sec 0.42 cycles/byte 
(2703.81 MiB in 500.00 ms)

With frame pointers:

AES-256 encrypt buffer size 1024 bytes: 5359.241 MiB/sec 0.42 cycles/byte 
(2679.62 MiB in 500.00 ms)
AES-256 decrypt buffer size 1024 bytes: 5404.226 MiB/sec 0.42 cycles/byte 
(2702.11 MiB in 500.00 ms)

Which shows a smaller than 1% slowdown between the binary built with frame 
pointers and the binary built without frame pointers.

Supposedly, the Phoronix benchmark was also built with "-O2" in both 
configurations but given that we saw very similar results to what was in the 
phoronix benchmark result when building Botan in debug mode, we assume that's 
what happened with the AES Botan benchmark.

We haven't yet dived deeper into the other benchmarks, but we expect that the 
benchmarks showing significant differences might suffer from similar issues, 
where the huge differences are not caused by the inclusion of frame pointers, 
but other unrelated issues such as the botan case where setting CXXFLAGS causes 
binaries to be built in debug mode unless an explicit optimization mode is set.

These benchmarks were done on an Amazon EC2 instance running Fedora 36 Cloud 
edition. The full details as reported by phoronix-test-suite can be found here: 
https://user-images.githubusercontent.com/9395011/176538700-c82974fa-fbb5-4146-be96-d6db1ce7dfb0.png
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Claim delve

2022-06-29 Thread Alejandro Saez Morollon

(I know, it took a while)

I just submitted it for review:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2102388
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Stalled EPEL Request Policy (was Unresponsive maintainer: Alex Chernyakhovsky)

2022-06-29 Thread Maxwell G via devel

On Wednesday, June 29, 2022 1:24:07 PM CDT Maxwell G via devel wrote:
> On Wednesday, June 29, 2022 1:09:07 PM CDT Vitaly Zaitsev via devel wrote:
> > Newly added EPEL maintainers can make any changes to Fedora branches. I
> > don't like that.
> 
> I'm a bit confused. You say this sounds like a "package hijack attempt," but
> then you also say you don't like that it only allows access to epel*
> branches.
Ah, I misread "can make any changes" as "can't make any changes," as 
maintainers added through this process are only given collaborator access to 
epel* branches. That explains why I was confused...

-- 
Thanks,

Maxwell G (@gotmax23)
Pronouns: He/Him/His

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Stalled EPEL Request Policy (was Unresponsive maintainer: Alex Chernyakhovsky)


On 29/06/2022 21:23, zebo...@gmail.com wrote:
What do you mean it is not possible? Isn't the new "collaborator" role 
exactly for this?


Yes, didn't know about it. My bad. Thanks for the info.


Collaborator: A user or a group with this level of access can do everything 
what a user/group with ticket access can do + it can commit to some branches in 
the project. These branches are defined here using their name or a pattern and 
needs to be comma separated.
If the new co-maintainers are added as collaborators with an epel* mask, 
I'm fine with that.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unresponsive maintainer: Alex Chernyakhovsky


On 29/06/2022 21:06, Stephen Smoogen wrote:

Maintainers are custodians and do not own the package.


This becomes true with the new EPEL policy. I think it should be 
revisited to follow Fedora's non-responsive maintainer procedure with an 
explicit FESCo approval on a case-by-case basis.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: libsoup 3: Part One (System-Wide Change)

2022-06-29 Thread Demi Marie Obenour

On 6/29/22 15:14, Chuck Anderson wrote:
> On Wed, Jun 29, 2022 at 11:49:51PM +0530, Vipul Siddharth wrote:
>> Fedora 37 as a compatibility library. Because libsoup is a sensitive
>> network-facing HTTP library written in an unsafe language and where
>> CVEs may have disastrous impact, it is not safe to leave libsoup 2
>> hanging around indefinitely, but we are not yet ready to remove it
>> altogether. We will propose removing libsoup 2 (and all applications
>> and libraries that still depend on it) for Fedora 39 in a separate
>> change proposal.
> 
> Why are we using a "network-facing HTTP library written in an unsafe
> language"?  Shouldn't we take this opportunity to move to a safer HTTP
> library?  Or is libsoup 3 safe(r) than libsoup 2?

I absolutely agree.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Stalled EPEL Request Policy (was Unresponsive maintainer: Alex Chernyakhovsky)

2022-06-29 Thread zebob . m

On 6/29/22 8:45 PM, Vitaly Zaitsev via devel  
wrote:

On 29/06/2022 20:24, Maxwell G wrote:
> I'm a bit confused. You say this sounds like a "package hijack attempt," but
> then you also say you don't like that it only allows access to epel* branches.

It is not possible to restrict access to only selected branches. EPEL maintainers can commit 
to Fedora branches and vice versa.

Thus, the newly added EPEL maintainers can do Fedora updates, and Fedora package maintainer 
can't prevent this. That's why I called this a "package hijack attempt".

What do you mean it is not possible? Isn't the new "collaborator" role exactly 
for this?

Best regards,

Ribert-André Mauchin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unresponsive maintainer: Alex Chernyakhovsky


On 29/06/2022 20:58, Miro Hrončok wrote:

No, it isn't. It's great ;)


Why? I doubt fighting maintainers is a good thing for Fedora.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: libsoup 3: Part One (System-Wide Change)

2022-06-29 Thread Michael Catanzaro

On Wed, Jun 29 2022 at 03:14:06 PM -0400, Chuck Anderson  
wrote:

Why are we using a "network-facing HTTP library written in an unsafe
language"?  Shouldn't we take this opportunity to move to a safer HTTP
library?  Or is libsoup 3 safe(r) than libsoup 2?


Not aware of any plausible alternatives besides libcurl, which has the 
same problem.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: libsoup 3: Part One (System-Wide Change)

2022-06-29 Thread Chuck Anderson

On Wed, Jun 29, 2022 at 11:49:51PM +0530, Vipul Siddharth wrote:
> Fedora 37 as a compatibility library. Because libsoup is a sensitive
> network-facing HTTP library written in an unsafe language and where
> CVEs may have disastrous impact, it is not safe to leave libsoup 2
> hanging around indefinitely, but we are not yet ready to remove it
> altogether. We will propose removing libsoup 2 (and all applications
> and libraries that still depend on it) for Fedora 39 in a separate
> change proposal.

Why are we using a "network-facing HTTP library written in an unsafe
language"?  Shouldn't we take this opportunity to move to a safer HTTP
library?  Or is libsoup 3 safe(r) than libsoup 2?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unresponsive maintainer: Alex Chernyakhovsky

2022-06-29 Thread Michel Alexandre Salim

Hi Robbie,

On Wed, 2022-06-29 at 12:02 -0400, Robbie Harwood wrote:
> In this case, because no one needinfo'd the maintainer, the EPEL
> policy
> can be slower (two weeks compared to the minimum ten days for
> nonresponsive).  Also, a literal reading of the EPEL policy says that
> the same person needs to needinfo as opened the bug, so if that's the
> case, then it would have been three weeks (because I didn't open
> either
> bug), unless I ask one of them to needinfo.  I'm not sure if that's
> intended?
> 
I'm not sure that's intended. I'm involved in drafting that policy, and
personally would not mind escalating a bug initially opened by someone
else.

Thanks for pointing out that the language is a bit unclear, we can
probably iterate on this.

Best regards,

-- 
Michel Alexandre Salim
identities:
https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unresponsive maintainer: Alex Chernyakhovsky

2022-06-29 Thread Stephen Smoogen

On Wed, 29 Jun 2022 at 14:52, Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 29/06/2022 20:32, Stephen Smoogen wrote:
> > Yes, they can. So can a lot of other people and things in Fedora.
>
> Only proven-packagers in limited situations or people who have been
> granted access by the package owner.
>
> > This isn't other distros where a package maintainer is a defacto
> dictator of the package they put into the OS. There is a give and take in
> what can happen with a package.
>
> But it is. The package owner has full control over the package and can
> add or remove co-maintainers as they see fit.
>
>
I believe the term 'package owner' was killed several years ago in Fedora.
Maintainers are custodians and do not own the package.


> But now we see that someone can add other people to co-maintainers. This
> is terrible.
>
>



-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unresponsive maintainer: Alex Chernyakhovsky


On 29. 06. 22 20:50, Vitaly Zaitsev via devel wrote:

On 29/06/2022 20:32, Stephen Smoogen wrote:

Yes, they can. So can a lot of other people and things in Fedora.


Only proven-packagers in limited situations or people who have been granted 
access by the package owner.


This isn't other distros where a package maintainer is a defacto dictator of 
the package they put into the OS. There is a give and take in what can happen 
with a package.


But it is. The package owner has full control over the package and can add or 
remove co-maintainers as they see fit.


But now we see that someone can add other people to co-maintainers. This is 
terrible.


No, it isn't. It's great ;)

--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unresponsive maintainer: Alex Chernyakhovsky


On 29/06/2022 20:32, Stephen Smoogen wrote:

Yes, they can. So can a lot of other people and things in Fedora.


Only proven-packagers in limited situations or people who have been 
granted access by the package owner.



This isn't other distros where a package maintainer is a defacto dictator of 
the package they put into the OS. There is a give and take in what can happen 
with a package.


But it is. The package owner has full control over the package and can 
add or remove co-maintainers as they see fit.


But now we see that someone can add other people to co-maintainers. This 
is terrible.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaning my packages

2022-06-29 Thread Francisco J . Tsao Santín via devel

On Wed, 29 Jun 2022, František Šumšal wrote:

> I'll gladly take over reptyr.
> 
Ok, it's yours now :-) Thanks!

-- 
Francisco J. Tsao Santín
http://gattaca.es
1024D/71CF4D62  42 F1 53 35 EF 98 98 8A FC 6C 56 B3 4C A7 7D FB
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Stalled EPEL Request Policy (was Unresponsive maintainer: Alex Chernyakhovsky)


On 29/06/2022 20:24, Maxwell G wrote:

I'm a bit confused. You say this sounds like a "package hijack attempt," but
then you also say you don't like that it only allows access to epel* branches.


It is not possible to restrict access to only selected branches. EPEL 
maintainers can commit to Fedora branches and vice versa.


Thus, the newly added EPEL maintainers can do Fedora updates, and Fedora 
package maintainer can't prevent this. That's why I called this a 
"package hijack attempt".


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)


On 29/06/2022 20:25, Michael Catanzaro wrote:

GNOME Software already has a hidden setting for this:


Yes and it should be configured to "['RPM', 'flatpak']" for all 
non-ostree Fedora variants (Workstation, Spins).


When the Flathub filtering is removed, most Fedora packages will be 
silently replaced by Flatpaks, some of them very low quality (DEB 
rebuids) because the Flathub versions are always greater than in Fedora.


It defaults to Flatpaks because they are sandboxed and are much safer than unsandboxed applications. 


- https://github.com/search?q=org%3Aflathub+filesystem%3Dhome&type=code
- https://github.com/search?q=org%3Aflathub+filesystem%3Dhost&type=code


However, I believe Flatpaks built from Fedora RPMs should take precedence over 
Flatpaks built from Flathub.


Fedora Flatpaks are almost dead. Let's check this page:
https://bodhi.fedoraproject.org/releases/

Fedora 36: 22867 (RPMs) vs. 104 (Flatpaks).
Fedora 35: 29801 (RPMs) vs. 104 (Flatpaks).
Fedora 34: 35742 (RPMs) vs. 92 (Flatpaks).

Flathub should only be preferred when there is no Fedora Flatpak available. 


I don't see it in the proposal.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unresponsive maintainer: Alex Chernyakhovsky

2022-06-29 Thread Stephen Smoogen

On Wed, 29 Jun 2022 at 14:10, Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 29/06/2022 18:47, Robbie Harwood wrote:
> > I don't see how you got there.  Nowhere does it say that the
> > maintainer(s) are removed - just that one is added, and made contact for
> > EPEL bugs.
>
> Newly added EPEL maintainers can make any changes to Fedora branches. I
> don't like that.
>
>
Yes, they can. So can a lot of other people and things in Fedora. This
isn't other distros where a package maintainer is a defacto dictator of the
package they put into the OS. There is a give and take in what can happen
with a package.


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-29 Thread Maxwell G via devel

On Wednesday, June 29, 2022 11:49:07 AM CDT Miro Hrončok wrote:
> Now you are mixing the two kinda together in a weird way. The change is
> called "deprecation" but is in fact "incomplete retirement".
I agree. There seems to be a recent trend of Changes confusing the difference 
between deprecations and removals. If something is being removed, even 
partially, it is a removal, not a deprecation. As other commenters have 
mentioned, in the Fedora context[1], deprecating a package entails adding 
`Provides: deprecated()` and submitting a Change proposal before doing so if 
it's not a leaf package.

[1]: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/

-- 
Thanks,

Maxwell G (@gotmax23)
Pronouns: He/Him/His

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Firefox Langpacks Subpackage (System-Wide Change)


On 29/06/2022 19:00, Vipul Siddharth wrote:

Firefox langpacks, which have been bundled in the Fedora firefox base
package until now, will be moved to a firefox-langpacks subpackage.


+1. It might be better to split it even more: firefox-langpack-%{lang} 
and depend on the system-wide language (just like spelling dictionaries).


Users will be able to install only the required locales.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

2022-06-29 Thread Michael Catanzaro

On Wed, Jun 29 2022 at 08:06:28 PM +0200, Vitaly Zaitsev via devel 
 wrote:

1. GNOME Software need to be patched to prefer RPMs over Flatpaks for
non-ostree Fedora variants, because it will replace Fedora packages 
with

Flatpaks. I think "Fedora RPM > Fedora Flatpak > Flathub Flatpak" for
Fedora Workstation and "Fedora Flatpak > Flathub Flatpak > Fedora RPM"
for Silverblue/Kinoite will be better.


GNOME Software already has a hidden setting for this:

https://gitlab.gnome.org/GNOME/gnome-software/-/blob/0709681441daf6b182a062d24c543174346b36d8/data/org.gnome.software.gschema.xml#L137

It defaults to Flatpaks because they are sandboxed and are much safer 
than unsandboxed applications.


However, I believe Flatpaks built from Fedora RPMs should take 
precedence over Flatpaks built from Flathub. Flathub should only be 
preferred when there is no Fedora Flatpak available.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Stalled EPEL Request Policy (was Unresponsive maintainer: Alex Chernyakhovsky)

2022-06-29 Thread Maxwell G via devel

On Wednesday, June 29, 2022 1:09:07 PM CDT Vitaly Zaitsev via devel wrote:
> On 29/06/2022 18:47, Robbie Harwood wrote:
> > I don't see how you got there.  Nowhere does it say that the
> > maintainer(s) are removed - just that one is added, and made contact for
> > EPEL bugs.
> 
> Newly added EPEL maintainers can make any changes to Fedora branches. I
> don't like that.

I'm a bit confused. You say this sounds like a "package hijack attempt," but 
then you also say you don't like that it only allows access to epel* branches.

-- 
Thanks,

Maxwell G (@gotmax23)
Pronouns: He/Him/His

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F37 Change Proposal: libsoup 3: Part One (System-Wide Change)

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
libsoup 3 is a new API version of libsoup that provides support for
HTTP/2. Unfortunately, it is incompatible with libsoup 2. To avoid
misbehavior, applications will crash on startup if linked to both
libsoup 2 and libsoup 3 at the same time. Because many libraries
depend on libsoup, and applications have limited control over which
libsoup they link to transitively, this transition will be tricky and
requires attention from all Fedora packages that depend on libsoup,
even if only indirectly.

== Owner ==
* Name: [[User:catanzaro| Michael Catanzaro]]
* Email: 


== Detailed Description ==
libsoup 3 was introduced in Fedora 36, but nothing actually uses it
yet. For Fedora 37 and GNOME 43, many GNOME applications and libraries
will switch from libsoup 2 to libsoup 3. libsoup 2 will remain in
Fedora 37 as a compatibility library. Because libsoup is a sensitive
network-facing HTTP library written in an unsafe language and where
CVEs may have disastrous impact, it is not safe to leave libsoup 2
hanging around indefinitely, but we are not yet ready to remove it
altogether. We will propose removing libsoup 2 (and all applications
and libraries that still depend on it) for Fedora 39 in a separate
change proposal.

For Fedora 37 and Fedora 38, we propose a transition period where both
libsoup 2 and libsoup 3 will coexist. Applications can switch to
libsoup 3 without significant impact on the rest of the distribution,
but libraries switching to libsoup 3 are very disruptive. Libraries
have a few options:

* Recommended: provide a new API version for libsoup 3. This gives
applications that depend on your library a transition period to switch
from libsoup 2 to libsoup 3. Applications will bump to your new API
version at the same time they transition to libsoup 3. If the
application does not directly depend on libsoup and does not depend on
libsoup via any other libraries, then this can be done at any time.
Example: webkit2gtk-4.0 is the libsoup 2 version of WebKitGTK's GTK 3
API, while webkit2gtk-4.1 is the libsoup 3 version. Currently only
webkit2gtk-4.0 is available in Fedora (via the webkit2gtk3 package),
but webkit2gtk-4.1 will be made available as part of this change
(package name TBD).
* Not recommended: provide a build option to toggle between libsoup 2
and libsoup 3, while retaining the same API version. All applications
that depend on your library must port to libsoup 3 at exactly the same
time. Unfortunately, many GNOME libraries have selected this approach,
and building these libraries with libsoup 3 enabled will be required
for GNOME 43. Known affected libraries will include geocode-glib,
libgweather, librest-1.0, and libosinfo.
* Require libsoup 3 unconditionally. This option is suitable only for
libraries used by very few applications.

Because many GNOME libraries have adopted the second approach,
applications that depend on these libraries, whether directly or
indirectly, must take action immediately or they will crash on
startup. This is far from ideal. This transition is unlikely to go
smoothly, but if we work together and coordinate with our fellow
package maintainers, we should be OK.


== Benefit to Fedora ==

Transitioning to libsoup 3 adds support for HTTP/2 and allows Fedora
to continue packaging the latest versions of GNOME. If we do not
transition to libsoup 3, then we will be unable to update certain
GNOME packages to the latest version.


== Scope ==

* Proposal owners: The proposal owner is working upstream to ensure
GNOME 43 is buildable without conflicts between packages that require
libsoup 2 dependencies vs. libsoup 3 dependencies. The proposal owner
will also package webkit2gtk-4.1 for Fedora 37. Because this is a
large transition that will require the efforts of dozens of
developers, the proposal owner can offer only limited help with
individual Fedora packages.

* Other developers: Check your applications and libraries for direct
or indirect dependencies on libsoup using ldd. You must assess each
situation individually to decide the best course of action. If you're
not sure where a dependency on libsoup comes from, use the lddtree
tool from the pax-utils package. If you wind up stuck in an impossible
situation where your software depends on both libsoup 2 and libsoup 3
simultaneously, ask other packagers for help to resolve the situation.
We will need to work together to solve these issues.

* Release engineering: [https://pagure.io/releng/issue/10859 #10859]
* Policies and guidelines: No policy changes required
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: No alignment with current objectives


== Upgrade/compatibility impact ==

If applications do not link to both libsoup 2 and libsoup 3,

Re: Orphaning my packages

2022-06-29 Thread František Šumšal


Hey,

On 6/29/22 16:56, Francisco J. Tsao Santín via devel wrote:

Hello, I've been maintaining some packages, but I can't at this time
continue taking care of them. So, next Sunday I'll orphan them if nobody
ask me the transfer:

* ascii
* netmask
* ez-pine-gpg
* python-meld3
* gpart
* python-sysv_ipc
* reptyr


I'll gladly take over reptyr.


Cheers,

--
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaning my packages

2022-06-29 Thread Francisco J . Tsao Santín via devel

On Wed, 29 Jun 2022, Gwyn Ciesla wrote:

> Actually, ignore that.
> 

Yes, I forgot to clarify that python-meld3 is being retired because it
has been fully integrated in supervisor. But it is still an independent
package in EPEL 7 and 8.

-- 
Francisco J. Tsao Santín
http://gattaca.es
1024D/71CF4D62  42 F1 53 35 EF 98 98 8A FC 6C 56 B3 4C A7 7D FB
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unresponsive maintainer: Alex Chernyakhovsky


On 29/06/2022 18:47, Robbie Harwood wrote:

I don't see how you got there.  Nowhere does it say that the
maintainer(s) are removed - just that one is added, and made contact for
EPEL bugs.


Newly added EPEL maintainers can make any changes to Fedora branches. I 
don't like that.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

On 29/06/2022 19:34, Vipul Siddharth wrote:

The flatpak remote for Flathub will have no filtering, making all the
Flathub content available in GNOME Software and via the flatpak
commandline.

Strongly -1, because Flatpaks have higher priority over RPMs in Gnome
Software.

1. GNOME Software need to be patched to prefer RPMs over Flatpaks for
non-ostree Fedora variants, because it will replace Fedora packages with
Flatpaks. I think "Fedora RPM > Fedora Flatpak > Flathub Flatpak" for
Fedora Workstation and "Fedora Flatpak > Flathub Flatpak > Fedora RPM"
for Silverblue/Kinoite will be better.

2. Fedora shouldn't rely on low-quality third-party repository. A lot of
Flathub packages even doesn't built from sources on trusted infra:
Firefox, OBS Studio, Blender, Element, Signal, etc. They just repackage
DEBs or static binaries:

-
https://github.com/flathub/org.signal.Signal/blob/master/org.signal.Signal.yaml#L62-L65
-
https://github.com/flathub/im.riot.Riot/blob/master/im.riot.Riot.yaml#L98-L103
-
https://github.com/flathub/org.blender.Blender/blob/master/org.blender.Blender.json#L143-L145

Firefox and OBS Studio even uploaded as a pre-built ostree blob.

3. "Sandboxing" is the biggest lie. A lot of apps have
--filesystem={home,host} in manifests:

- https://github.com/search?q=org%3Aflathub+filesystem%3Dhome&type=code
- https://github.com/search?q=org%3Aflathub+filesystem%3Dhost&type=code

--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure

Fedora Flatpaks: fedmod has been retired

2022-06-29 Thread Artur Frenszek-Iwicki

I wanted to try building a Fedora Flatpak, so I headed over to the docs and 
started with the tutorial.
https://docs.fedoraproject.org/en-US/flatpak/tutorial/

The first step instructed me to install some packaging tools:
$ dnf install flatpak-module-tools fedmod

DNF complained that it could not find "fedmod".
I checked in dist-git and it looks like it has been retired over 6 months ago.
https://src.fedoraproject.org/rpms/fedmod

So my question is... what's up with that?
Looking at the tutorial, I get the impression that fedmod was just a helper tool
and isn't strictly required to build a Fedora Flatpak. If that's the case,
I'd appreciate it if someone knowledgeable can update the docs.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==

The flatpak remote for Flathub will have no filtering, making all the
Flathub content available in GNOME Software and via the flatpak
commandline.


== Owner ==

* Name: Workstation WG
* Email: mcla...@redhat.com


== Detailed Description ==

Fedora includes a flatpak repo definition for Flathub in the
fedora-flathub-remote package. So far, this remote
was filtered by an allowlist that only made a limited subset of
software from Flathub available. We've been told
that it is ok for us to remove the filtering and make all of Flathub available.

The filtering mechanism itself will still be there, and it will be
possible for us to reinstate a filter via a package
update, should the need arise in the future.

The Flathub remote is available to users who opt-in to enabling
third-party software repositories in either GNOME Initial Setup or
GNOME Software. Users who do not opt in will not see anything from
Flathub.

In case of overlaps, GNOME Software will prefer Fedora flatpaks over
Flathub flatpaks. It is always possible for the user to manually
select a different source for individual applications.


== Feedback ==

This change proposal has previously been discussed here:
https://pagure.io/fedora-workstation/issue/300


== Benefit to Fedora ==

More software will be easily available to Fedora users.

Additionally, the filtered Flathub has not been popular with users.
Users have been confused and displeased that our Flathub remote
contains only a small subset of Flathub, rather than the full Flathub.
Dropping the filter will resolve this criticism.


== Scope ==

* Proposal owners: Remove the allowlist in
/usr/share/flatpak/fedora-flathub.filter, or replace it with one that
allows everything
* Other developers: GNOME Software developers: Verify that the
priorities between repos and packaging formats work out as desired
* Release engineering:  No work needed
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives:


== Upgrade/compatibility impact ==

Existing Fedora installations with a configured Fedora Flathub remote
will pick up the new, permissive filter.


== How To Test ==

When third-party software is not enabled in GNOME Initial Setup or
GNOME Software, search results from Flathub should not appear in GNOME
Software.
When third-party software is enabled in GNOME Initial Setup or GNOME
Software, search results from Flathub should appear.


== User Experience ==

When opening GNOME Software, all the applications that are available
on Flathub will show up in search results.


== Dependencies ==

No dependencies.


== Contingency Plan ==

* Contingency mechanism: Reinstate the filtering we had in Fedora 36
* Contingency deadline: Beta
* Blocks release? No


== Documentation ==

* [https://pagure.io/fedora-third-party/blob/main/f/doc/fedora-third-party.1.md
fedora-third-party]
* [https://github.com/flathub/flathub/wiki Flathub wiki]
* [https://fedoramagazine.org/comparison-of-fedora-flatpaks-and-flathub-remotes/
Comparison of Fedora Flatpaks and Flathub remotes]


== Release Notes ==

The Fedora Flathub remote now exposes all content from Flathub,
instead of only a small subset. Flathub is not enabled by default. To
enable software from Flathub, turn on third-party software in GNOME
Initial Setup or GNOME Software.

-- 
Vipul Siddharth
He/His/Him
FPgM team member
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F37 Change Proposal: IBus 1.5.27 (System-Wide change)

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==

In IBus 1.5.27, `ibus restart` subcommand will be enhanced to be able
to restart ibus-daemon in GNOME desktop, `ibus im-module` subcommand
will be added to get internal gtk-im-module value in an GTK instance,
ibus-setup will provides custom themes for the IBus candidate window.


== Owner ==
* Name: [[User:Fujiwara|Takao Fujiwara]]
* Email: fujiwara [at] redhat [dot] com


== Detailed Description ==

* `ibus restart` subcommand will be enhanced to be able to restart
ibus-daemon via systemd for GNOME desktop. ibus-daemon is launched via
systemd in GNOME desktop. `ibus restart` will restart ibus-daemon with
systemd at first and with an IBus API directly at second and it also
provides `--help` option to get other option arguments for the
subcommand and `--type=direct` and `--type=systemd` subcommands are
available.
* `ibus im-module` subcommand will be added to get an internal
gtk-im-module value from an instance of an GTK instance. Some users
would fail to setup IBus and this subcommand will help them to check
whether "ibus" is set to the gtk-im-module in the actual process.
* ibus-setup will provides custom themes in the "Advanced" tab for
IBus candidate window. IBus candidate window is composed by GTK and If
the current desktop is composed by GTK likes GNOME, the desktop
provides a utility to customize the themes. But if not, this feature
is useful for the users.


== Benefit to Fedora ==

Users can restart ibus-daemon with `ibus restart`. When users install
new IBus engines, ibus-daemon has to be restarted to load the new
engine lists, If users might encounter a bug, users would like to
restart ibus-daemon. IM developers also sometimes restart ibus-daemon
to debug IBus or the engines. `ibus im-module` subcommand is also
useful when a users failed to setup IBus. Providing IBus custom themes
is useful for Plasma desktop which theme utility does not change GTK
themes.


== Scope ==

* Proposal owners: ibus
* Other developers: NONE
* Release engineering:
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives:


== Upgrade/compatibility impact ==

`ibus restart` should not have any regressions in any desktops.


== How To Test ==

* IBus restart
** Log into GNOME desktop session
** Run `ibus restart` and then ibus-daemon PID is changed.

* IBus im-module
** Run `ibus im-module` and get "ibus"

* IBus custom theme
** Log into Plasma desktop session
** Run ibus-setup and configure IM engines in "Input Method" tab, who
can show the candidate window likes ibus-libpinyin, ibus-anthy.
** Run ibus-setup and configure custom themes in "Advanced" tab and
confirme the theme of the candidate window is changed.


== User Experience ==

`ibus restart` command line interface is available to restart the
input method features and ibus-setup provides custom themes for ithe
appearance of the input method candidate window.


== Dependencies ==

`ibus restart --type=systemd` requires systemd.
`ibus im-module` subcommand requires gtk4 or gtk3 or gtk2.

== Contingency Plan ==

* Contingency mechanism: Revert the change to IBus.
* Contingency deadline: Beta release
* Blocks release? No


== Documentation ==

TBD

== Release Notes ==

TBD

--
Vipul Siddharth
He/His/Him
FPgM team member
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F37 Change Proposal: Firefox Langpacks Subpackage (System-Wide Change)

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This
proposal will only be implemented if approved by the Fedora
Engineering Steering Committee.


== Summary ==
Firefox langpacks, which have been bundled in the Fedora firefox base
package until now, will be moved to a firefox-langpacks subpackage.


== Owner ==

* Name: [[User:Petersen| Jens Petersen]]
* Email: 
* Name: [[User:Stransky| Martin Stransky]]
* Email: 


== Detailed Description ==

The firefox packages carries many langpacks containing translations
and other localization data for different countries and languages.
This Change will move them to a separate subpackage pulled in as a
weak dependency by the base package.


== Feedback ==

Initial discussion: https://bugzilla.redhat.com/show_bug.cgi?id=2035178


== Benefit to Fedora ==

This makes Fedora a little more modular: going forward it will be
possible to install firefox without having to have all the langpacks
installed too.


== Scope ==

* Proposal owners:
** Update Rawhide firefox to add the langpacks subpackage
([https://src.fedoraproject.org/rpms/firefox/pull-request/43 PR])

* Other developers: none

* Release engineering: [https://pagure.io/releng/issue/10858 #10858]

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==

When upgrading to Fedora 37, firefox's new weak dependency will pull
in the firefox-langpacks subpackage,
so users should not experience any change by default.


== How To Test ==

* install firefox and check that firefox-langpacks gets pulled in
* test that firefox's langpacks are functioning normally
* test upgrade from F36 to F37 and ensure that the firefox-langpacks
subpackage gets installed.


== User Experience ==

Users will have a new firefox-langpacks subpackage installed by default.
If they don't require localization they can remove it and benefit from
lighter firefox updates
and save about 50MB of diskspace.


== Dependencies ==

None


== Contingency Plan ==

* Contingency mechanism: proposal owners will revert firefox.spec to
not subpackage langpacks
* Contingency deadline: before final freeze
* Blocks release? No


== Documentation ==

None


== Release Notes ==

Firefox's langpacks have been moved to a subpackage for greater
install flexibility.

-- 
Vipul Siddharth
He/His/Him
FPgM team member
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaning my packages

2022-06-29 Thread Gwyn Ciesla via devel

Actually, ignore that.



-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie


Sent with Proton Mail secure email.

--- Original Message ---
On Wednesday, June 29th, 2022 at 11:50 AM, Gwyn Ciesla  
wrote:


> I'll take python-meld3 if no one else speaks for it.
> 

> 

> 

> --
> Gwyn Ciesla
> she/her/hers
> 
> in your fear, seek only peace
> in your fear, seek only love
> -d. bowie
> 

> 

> Sent with Proton Mail secure email.
> 

> --- Original Message ---
> On Wednesday, June 29th, 2022 at 9:56 AM, Francisco J. Tsao Santín via devel 
> devel@lists.fedoraproject.org wrote:
> 

> 

> 

> > Hello, I've been maintaining some packages, but I can't at this time
> > continue taking care of them. So, next Sunday I'll orphan them if nobody
> > ask me the transfer:
> > 

> > * ascii
> > * netmask
> > * ez-pine-gpg
> > * python-meld3
> > * gpart
> > * python-sysv_ipc
> > * reptyr
> > * supervisor
> > 

> > --
> > Francisco J. Tsao Santín
> > http://gattaca.es
> > 1024D/71CF4D62 42 F1 53 35 EF 98 98 8A FC 6C 56 B3 4C A7 7D FB
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructure

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaning my packages

2022-06-29 Thread Gwyn Ciesla via devel

I'll take python-meld3 if no one else speaks for it.



-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie


Sent with Proton Mail secure email.

--- Original Message ---
On Wednesday, June 29th, 2022 at 9:56 AM, Francisco J. Tsao Santín via devel 
 wrote:


> Hello, I've been maintaining some packages, but I can't at this time
> continue taking care of them. So, next Sunday I'll orphan them if nobody
> ask me the transfer:
> 

> * ascii
> * netmask
> * ez-pine-gpg
> * python-meld3
> * gpart
> * python-sysv_ipc
> * reptyr
> * supervisor
> 

> --
> Francisco J. Tsao Santín
> http://gattaca.es
> 1024D/71CF4D62 42 F1 53 35 EF 98 98 8A FC 6C 56 B3 4C A7 7D FB
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

On 29. 06. 22 17:45, Dmitry Belyavskiy wrote:

Dear Miro,

On Wed, Jun 29, 2022 at 5:27 PM Miro Hrončok > wrote:

On 29. 06. 22 17:11, Dmitry Belyavskiy wrote:
 > Dear colleagues,
 >
 > If I correctly follow the discussion, the biggest show-stopper is Python
2.*,
 > which has some incomplete patches to deal with OpenSSL 3.0.

We would also need it in for Python 3.6 and pypys.

Are RHEL 9 patches for Python 3 series relevant in this case?

Not at all. RHEL 9 is python3.9 and that runs on OpenSSL 3 in both RHEL 9 and 
all supported Fedoras.

 > If we assist you in moving these patches forward, can we get rid of the
devel
 > package and leave the compat package only for 3rd-party packages?

Please don't remove the devel package if you aim for deprecation. As other
have
said, removing the devel package is essentially retirement, not deprecation.

OK, it's not a problem to deprecate the package in the sense of 
https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/ 

But we still want to get rid of it.

Right. But it makes sense to say:

Fedora 37: openssl1.1 is deprecated
Fedora XY: openssl1.1 is retired

Now you are mixing the two kinda together in a weird way. The change is called 
"deprecation" but is in fact "incomplete retirement".

See e.g.:

Deprecation: https://fedoraproject.org/wiki/Changes/DeprecateNose
Retirement: https://fedoraproject.org/wiki/Changes/RetirePython3.7

 > I don't think that the community really requires support for this
package for 7
 > years after its upstream sunset.

OpenSSL 3 was introduced in Fedora 36, that has *just* been released this
year.
This is a change proposal for Fedora 37, that is half a year after, not 7
years :/

Well, speaking about 7 years, I mean the idea to support the compat package 
synchronously with RHEL 8.

Now I understand what you mean but I still don't understand what is the biggest 
trouble. You do maintain this in RHEL 8, don't you?

I'd like to retire this package not later than, well, a release after OpenSSL 
1.1.1 EOL.

Is that happening on some known schedule or is it an event that will eventually 
happen but we don't know when?

--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unresponsive maintainer: Alex Chernyakhovsky

2022-06-29 Thread Robbie Harwood

Vitaly Zaitsev via devel  writes:

> On 29/06/2022 01:18, Maxwell G via devel wrote:
>
>> You might also be interested in the Stalled EPEL Requests
>> policy[1]. This would've allowed you to get permissions to branch the
>> package for EPEL without going through the non-responsive maintainer
>> process.
>
> This policy looks like a package hijack attempt.

I don't see how you got there.  Nowhere does it say that the
maintainer(s) are removed - just that one is added, and made contact for
EPEL bugs.

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-29 Thread Fabio Valentini

On Wed, Jun 29, 2022 at 5:46 PM Dmitry Belyavskiy  wrote:
>
> On Wed, Jun 29, 2022 at 5:27 PM Miro Hrončok  wrote:
>>
>> Please don't remove the devel package if you aim for deprecation. As other 
>> have
>> said, removing the devel package is essentially retirement, not deprecation.
>
> OK, it's not a problem to deprecate the package in the sense of  
> https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/

I agree with Miro.If you want to ensure no new packages start
depending on openssl1.1, then adding "Provides: deprecated()" (to both
the openssl1.1 and openssl1.1-devel packages) is exactly what you
want. fedora-review includes a check that prints a warning when a
package depends on something that has "Provides: deprecated()", so no
new packages should ever be added to Fedora that depend on something
that is deprecated.

Removing a (sub-)package is not a "deprecation", because it already
breaks dependent packages, and *does not* give any advance warning to
affected people, which a deprecation is supposed to provide.

> But we still want to get rid of it.

I understand this goal, but starting with a deprecation means that
this will be a two-step process:

1) deprecate openssl1.1 and openssl1.1 packages (adding "Provides:
deprecated()" to them): this ensures no new packages depend on them
(fine to do that for Fedora 37)
2) once no Fedora packages (only third-party binaries) depend on
openssl1.1, you *can* drop openssl1.1-devel (too early in Fedora 37,
target 38 or 39 instead?, see EOL dates listed below)

Dropping openssl1.1-devel (and keeping openssl1.1) *before* all
official Fedora components have been ported to openssl 3 is
essentially making them hang by the thinnest of threads - the packages
will fail to build, but still be *installable* - if only for so long.

These packages will also start to fail to install after any soname
bump (or another similar change) in their dependency trees - because
they won't be able to be rebuilt for that (unrelated) change, because
openssl1.1-devel is gone. It will also block any critical / security
updates for affected packages, which is certainly not what we want.

So, please, don't remove the openssl1.1-devel package while there's
still Fedora packages that depend on it. I assume openssl1.1 itself
will be kept for some time, to provide support for third-party
applications that require it? So keeping the -devel package around
does not create any additional work for you, but it will make life for
maintainers of dependent packages much easier, until they can switch
their packages to OpenSSL 3.

>> > I don't think that the community really requires support for this package 
>> > for 7
>> > years after its upstream sunset.
>>
>> OpenSSL 3 was introduced in Fedora 36, that has *just* been released this 
>> year.
>> This is a change proposal for Fedora 37, that is half a year after, not 7 
>> years :/
>
>
> Well, speaking about 7 years, I mean the idea to support the compat package 
> synchronously with RHEL 8.
> I'd like to retire this package not later than, well, a release after OpenSSL 
> 1.1.1 EOL.

According to the OpenSSL website
(https://www.openssl.org/policies/releasestrat.html) OpenSSL 1.1.1
will be supported until 2023-09-11.
Fedora 37 will be EOL at around 2023-11-14
(https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html),
so OpenSSL 1.1.1 will still be officially supported for most of its
lifecycle - I don't see why it already needs to be removed in Fedora
37.

This alignment of EOL dates make me wonder whether the removal of
openssl1.1(-devel) should be targeted at Fedora 38 (more than half its
supported lifetime is after OpenSSL 1.1.1 is EOL) or Fedora 39
(released after OpenSSL 1.1.1 is EOL) instead, but Fedora 37 seems too
early for a *removal*, but officially deprecating it in Fedora 37
sounds very reasonable to me.

Fabop
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unresponsive maintainer: Alex Chernyakhovsky


On 29/06/2022 01:18, Maxwell G via devel wrote:

You might also be interested in the Stalled EPEL Requests policy[1]. This
would've allowed you to get permissions to branch the package for EPEL without
going through the non-responsive maintainer process.


This policy looks like a package hijack attempt.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unresponsive maintainer: Alex Chernyakhovsky

2022-06-29 Thread Robbie Harwood

Maxwell G via devel  writes:

> On Tuesday, June 28, 2022 4:30:14 PM CDT Robbie Harwood wrote:
>> I have started the responsive maintainer process due to lack of contact
>> through bugzilla mail.  Specifically, this is about an epel9 branch,
>> which has been repeatedly requested since March (including an offer to
>> maintain the branch) in
>> https://bugzilla.redhat.com/show_bug.cgi?id=2091582 and
>> https://bugzilla.redhat.com/show_bug.cgi?id=2059757 .
>
> You might also be interested in the Stalled EPEL Requests
> policy[1]. This would've allowed you to get permissions to branch the
> package for EPEL without going through the non-responsive maintainer
> process. Of course, if after a certain amount of time, a maintainer is
> deemed completely non-responsive, you should go through the respective
> process. The Stalled EPEL Requests policy is just intended to provide
> a more expedient way to get a package branched for EPEL.
>
> [1]: https://docs.fedoraproject.org/en-US/epel/epel-policy/
> #stalled_epel_requests

Thanks, I didn't know about that.  Hopefully I'll never have to use it,
but good to know.

In this case, because no one needinfo'd the maintainer, the EPEL policy
can be slower (two weeks compared to the minimum ten days for
nonresponsive).  Also, a literal reading of the EPEL policy says that
the same person needs to needinfo as opened the bug, so if that's the
case, then it would have been three weeks (because I didn't open either
bug), unless I ask one of them to needinfo.  I'm not sure if that's
intended?

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-29 Thread Dmitry Belyavskiy

Dear Miro,

On Wed, Jun 29, 2022 at 5:27 PM Miro Hrončok  wrote:

> On 29. 06. 22 17:11, Dmitry Belyavskiy wrote:
> > Dear colleagues,
> >
> > If I correctly follow the discussion, the biggest show-stopper is Python
> 2.*,
> > which has some incomplete patches to deal with OpenSSL 3.0.
>
> We would also need it in for Python 3.6 and pypys.
>

Are RHEL 9 patches for Python 3 series relevant in this case?

> If we assist you in moving these patches forward, can we get rid of the
> devel
> > package and leave the compat package only for 3rd-party packages?
>
> Please don't remove the devel package if you aim for deprecation. As other
> have
> said, removing the devel package is essentially retirement, not
> deprecation.
>

OK, it's not a problem to deprecate the package in the sense of
https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/
But we still want to get rid of it.

> I don't think that the community really requires support for this package
> for 7
> > years after its upstream sunset.
>
> OpenSSL 3 was introduced in Fedora 36, that has *just* been released this
> year.
> This is a change proposal for Fedora 37, that is half a year after, not 7
> years :/
>

Well, speaking about 7 years, I mean the idea to support the compat package
synchronously with RHEL 8.
I'd like to retire this package not later than, well, a release after
OpenSSL 1.1.1 EOL.

-- 
Dmitry Belyavskiy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Rawhide-20220629.n.0 compose check report

Missing expected images:

Minimal raw-xz armhfp

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 11/233 (x86_64), 34/163 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20220628.n.0):

ID: 1309372 Test: x86_64 Server-dvd-iso install_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1309372
ID: 1309471 Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1309471
ID: 1309510 Test: aarch64 Minimal-raw_xz-raw.xz 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/1309510
ID: 1309513 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/1309513
ID: 1309521 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/1309521
ID: 1309522 Test: aarch64 Server-dvd-iso 
install_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1309522
ID: 1309525 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1309525
ID: 1309528 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/1309528
ID: 1309537 Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/1309537
ID: 1309546 Test: aarch64 Server-dvd-iso server_remote_logging_server@uefi
URL: https://openqa.fedoraproject.org/tests/1309546
ID: 1309547 Test: aarch64 Server-dvd-iso 
server_role_deploy_database_server@uefi
URL: https://openqa.fedoraproject.org/tests/1309547
ID: 1309553 Test: aarch64 Server-dvd-iso server_database_client@uefi
URL: https://openqa.fedoraproject.org/tests/1309553
ID: 1309555 Test: aarch64 Server-dvd-iso server_remote_logging_client@uefi
URL: https://openqa.fedoraproject.org/tests/1309555
ID: 1309589 Test: aarch64 Cloud_Base-qcow2-qcow2 base_selinux@uefi
URL: https://openqa.fedoraproject.org/tests/1309589
ID: 1309590 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1309590
ID: 1309622 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1309622
ID: 1309623 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1309623
ID: 1309630 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1309630
ID: 1309723 Test: aarch64 universal install_mirrorlist_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1309723
ID: 1309729 Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1309729
ID: 1309731 Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1309731
ID: 1309736 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1309736
ID: 1309758 Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/1309758
ID: 1309760 Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/1309760
ID: 1310549 Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1310549
ID: 1310550 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/1310550
ID: 1310551 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/1310551
ID: 1310552 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/1310552
ID: 1310553 Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/1310553
ID: 1310554 Test: aarch64 Server-dvd-iso install_updates_nfs@uefi
URL: https://openqa.fedoraproject.org/tests/1310554
ID: 1310556 Test: aarch64 Server-dvd-iso 
install_repository_nfs_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1310556
ID: 1310557 Test: aarch64 Server-dvd-iso 
install_repository_nfsiso_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1310557

Old failures (same test failed in Fedora-Rawhide-20220628.n.0):

ID: 1309443 Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1309443
ID: 1309459 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1309459
ID: 1309475 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1309475
ID: 1309479 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1309479
ID: 1309483 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1309483

Re: Fedora CI runs tests on the wrong branch?

2022-06-29 Thread Adam Williamson

On Wed, 2022-06-29 at 14:49 +0200, Ewoud Kohl van Wijngaarden wrote:
> Hello everyone,
> 
> I've been taking a look at adding tests to the Puppet package. Initially 
> this worked well when I added it to Rawhide[1] and it did what I 
> expected.
> 
> Now I'm trying to add the same tests to the epel9 branch[2]. It should 
> be noted that epel9 is exactly the same as rawhide now (same git commit 
> sha) and I think this causes a problem. If you look at the epel9 pr[2] 
> you can see the test results for the rawhide pr[1]. You also see a new 
> scratch build, but no new dist-git test job. That is incorrect to me.
> 
> Is this a known problem/limitation of Pagure/Fedora CI or did I 
> misconfigure something?

There is a dedicated mailing list for CI, c...@lists.fp.o . It might be a
good idea to send this there instead/as well.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)


On 29. 06. 22 17:11, Dmitry Belyavskiy wrote:

Dear colleagues,

If I correctly follow the discussion, the biggest show-stopper is Python 2.*, 
which has some incomplete patches to deal with OpenSSL 3.0.


We would also need it in for Python 3.6 and pypys.

If we assist you in moving these patches forward, can we get rid of the devel 
package and leave the compat package only for 3rd-party packages?


Please don't remove the devel package if you aim for deprecation. As other have 
said, removing the devel package is essentially retirement, not deprecation.


I don't think that the community really requires support for this package for 7 
years after its upstream sunset.


OpenSSL 3 was introduced in Fedora 36, that has *just* been released this year. 
This is a change proposal for Fedora 37, that is half a year after, not 7 years :/


--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)

2022-06-29 Thread Dmitry Belyavskiy

Dear colleagues,

If I correctly follow the discussion, the biggest show-stopper is Python
2.*, which has some incomplete patches to deal with OpenSSL 3.0.
If we assist you in moving these patches forward, can we get rid of the
devel package and leave the compat package only for 3rd-party packages?

I don't think that the community really requires support for this package
for 7 years after its upstream sunset.

Many thanks!

On Tue, Jun 28, 2022 at 4:06 PM Miro Hrončok  wrote:

> On 27. 06. 22 13:27, Richard W.M. Jones wrote:
> > ==
> > FAIL: test_openssl_version (test.test_ssl.BasicSocketTests)
> > --
> > Traceback (most recent call last):
> >File "/home/rjones/d/cpython-2.7/Lib/test/test_ssl.py", line 382, in
> test_openssl_version
> >  (s, t))
> > AssertionError: ('OpenSSL 3.0.3 3 May 2022', (3, 0, 0, 3, 0))
>
> Might be https://github.com/python/cpython/issues/90272
>
> --
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
Dmitry Belyavskiy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Orphaning my packages

2022-06-29 Thread Francisco J . Tsao Santín via devel

Hello, I've been maintaining some packages, but I can't at this time
continue taking care of them. So, next Sunday I'll orphan them if nobody
ask me the transfer:

* ascii
* netmask
* ez-pine-gpg
* python-meld3
* gpart
* python-sysv_ipc
* reptyr
* supervisor

-- 
Francisco J. Tsao Santín
http://gattaca.es
1024D/71CF4D62  42 F1 53 35 EF 98 98 8A FC 6C 56 B3 4C A7 7D FB
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora CI runs tests on the wrong branch?

2022-06-29 Thread Ewoud Kohl van Wijngaarden


Hello everyone,

I've been taking a look at adding tests to the Puppet package. Initially 
this worked well when I added it to Rawhide[1] and it did what I 
expected.


Now I'm trying to add the same tests to the epel9 branch[2]. It should 
be noted that epel9 is exactly the same as rawhide now (same git commit 
sha) and I think this causes a problem. If you look at the epel9 pr[2] 
you can see the test results for the rawhide pr[1]. You also see a new 
scratch build, but no new dist-git test job. That is incorrect to me.


Is this a known problem/limitation of Pagure/Fedora CI or did I 
misconfigure something?


Regards,
Ewoud

[1]: https://src.fedoraproject.org/rpms/puppet/pull-request/17
[2]: https://src.fedoraproject.org/rpms/puppet/pull-request/18
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: release-monitoring.org 1.4.0 is now live


On 22. 06. 22 17:36, Michal Konecny wrote:

* Add Python (PEP 440) versioning scheme


Hey Michal,
I'm glad this has landed.

Is there a way to automatically update all the PyPI sourced packages to use 
this?

--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora rawhide compose report: 20220629.n.0 changes

2022-06-29 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20220628.n.0
NEW: Fedora-Rawhide-20220629.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:2
Upgraded packages:   240
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:494.29 KiB
Size of upgraded packages:   2.78 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -97.38 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: perl-Judy-0.41-25.fc37
Summary: Library for creating and accessing dynamic arrays
RPMs:perl-Judy
Size:328.23 KiB

Package: smc-meera-fonts-7.0.3-5.fc36
Summary: Open Type Fonts for Malayalam script
RPMs:smc-meera-fonts
Size:166.06 KiB


= UPGRADED PACKAGES =
Package:  ansible-collection-chocolatey-chocolatey-1.3.0-1.fc37
Old package:  ansible-collection-chocolatey-chocolatey-1.2.0-1.fc37
Summary:  Ansible collection for Chocolatey
RPMs: ansible-collection-chocolatey-chocolatey
Size: 48.42 KiB
Size change:  5.20 KiB
Changelog:
  * Wed Jun 29 2022 Orion Poplawski  - 1.3.0-1
  - Update to 1.3.0


Package:  bluedevil-5.25.2-1.fc37
Old package:  bluedevil-5.25.1-1.fc37
Summary:  Bluetooth stack for KDE
RPMs: bluedevil
Size: 1.76 MiB
Size change:  509 B
Changelog:
  * Tue Jun 28 2022 Marc Deop  - 5.25.2-1
  - 5.25.2


Package:  breeze-gtk-5.25.2-1.fc37
Old package:  breeze-gtk-5.25.1-1.fc37
Summary:  Breeze widget theme for GTK
RPMs: breeze-gtk breeze-gtk-common breeze-gtk-gtk2 breeze-gtk-gtk3 
breeze-gtk-gtk4
Size: 322.38 KiB
Size change:  -315 B
Changelog:
  * Tue Jun 28 2022 Marc Deop  - 5.25.2-1
  - 5.25.2


Package:  butane-0.15.0-2.fc37
Old package:  butane-0.15.0-1.fc37
Summary:  Butane config transpiler
RPMs: butane butane-redistributable
Size: 32.19 MiB
Size change:  2.87 MiB
Changelog:
  * Mon Jun 27 2022 Benjamin Gilbert  - 0.15.0-2
  - Add macOS aarch64 binary to -redistributable


Package:  cffconvert-2.0.0-3.fc37
Old package:  cffconvert-2.0.0-2.fc37
Summary:  Command line program to validate and convert CITATION.cff files
RPMs: cffconvert
Size: 133.98 KiB
Size change:  103 B
Changelog:
  * Tue Jun 28 2022 Benjamin A. Beasley  - 2.0.0-3
  - Allow jsonschema 4.x (fix RHBZ#2101851)


Package:  curl-7.84.0-1.fc37
Old package:  curl-7.83.1-1.fc37
Summary:  A utility for getting files from remote servers (FTP, HTTP, and 
others)
RPMs: curl curl-minimal libcurl libcurl-devel libcurl-minimal
Size: 8.80 MiB
Size change:  114.95 KiB
Changelog:
  * Mon Jun 27 2022 Kamil Dudka  - 7.84.0-1
  - new upstream release, which fixes the following vulnerabilities
  CVE-2022-32207 - Unpreserved file permissions
  CVE-2022-32205 - Set-Cookie denial of service
  CVE-2022-32206 - HTTP compression denial of service
  CVE-2022-32208 - FTP-KRB bad message verification


Package:  cutter-re-2.1.0-1.fc37
Old package:  cutter-re-2.0.4-3.fc36
Summary:  GUI for Rizin reverse engineering framework
RPMs: cutter-re cutter-re-devel
Size: 7.54 MiB
Size change:  50.62 KiB
Changelog:
  * Tue Jun 28 2022 Riccardo Schirone  - 2.1.0-1
  - Rebase to version 2.1.0 which uses Rizin 0.4.0


Package:  easyeffects-6.2.6-1.fc37
Old package:  easyeffects-6.2.5-1.fc37
Summary:  Audio effects for PipeWire applications
RPMs: easyeffects
Size: 3.39 MiB
Size change:  92.89 KiB
Changelog:
  * Mon Jun 27 2022 Vasiliy N. Glazov  - 6.2.6-1
  - Update to 6.2.6


Package:  exim-4.96-1.fc37
Old package:  exim-4.95-4.fc37
Summary:  The exim mail transfer agent
RPMs: exim exim-clamav exim-greylist exim-mon exim-mysql exim-pgsql
Size: 6.30 MiB
Size change:  40.30 KiB
Changelog:
  * Tue Jun 28 2022 Jaroslav ??karvada  - 4.96-1
  - New version
Resolves: rhbz#2101104


Package:  flacon-9.1.0-1.fc37
Old package:  flacon-9.0.0-1.fc37
Summary:  Audio File Encoder
RPMs: flacon
Size: 6.19 MiB
Size change:  83.02 KiB
Changelog:
  * Tue Jun 28 2022 Vasiliy N. Glazov  - 9.1.0-1
  - Update to 9.1.0


Package:  gajim-1.4.5-1.fc37
Old package:  gajim-1.4.4-1.fc37
Summary:  Jabber client written in PyGTK
RPMs: gajim
Size: 6.85 MiB
Size change:  407.98 KiB
Changelog:
  * Mon Jun 27 2022 Michael Kuhn  - 1.4.5-1
  - Update to 1.4.5


Package:  glib2-2.73.1-2.fc37
Old package:  glib2-2.73.1-1.fc37
Summary:  A library of handy utility functions
RPMs: glib2 glib2-devel glib2-doc glib2-static glib2-tests
Size: 35.04 MiB
Size change:  294 B
Changelog:
  * Tue Jun 28 2022 Adam Williamson  2.73.1-2
  - Backport PR #2784 to fix `weak_locations != NULL` crashes


Package:  grub2-breeze-theme-5.25.2-1.fc37
Old package:  grub2-breeze-theme-5.25.1-1.fc37
Summary:  Breeze theme for GRUB

Re: Can we start changing License to SPDX now?

2022-06-29 Thread Petr Pisar

V Wed, Jun 29, 2022 at 10:17:48AM +0200, Bob Mauchin napsal(a):
> Weren't there a proposal for a macro allowing to use both Spottags and SPDX
> so we could merge --ff-only to the old branches? Not being able to do that
> is a PITA.
> 
SPDX is allowed in all Fedora branches
.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Self Introduction: Patrick Cullen

2022-06-29 Thread Patrick Cullen

Hey all,


I work at Meta on the team dealing with all things time distribution
related (NTP and PTP) and including the OCP Time Appliance Project.


I'll be actively supporting and updating open-source software including
github.com/facebookincubator/ntp, github.com/facebookincubator/ptp,
github.com/Orolia2s/oscillatord and related dependencies.


I work with Alexander and Davide on these projects, all of which are pretty
active at the moment.


Regards,


Patrick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package proposal: google-drive-ocamlfuse

2022-06-29 Thread Sérgio Basto

On Wed, 2022-06-29 at 10:26 +0200, Marián Konček wrote:
> I recently discovered this project: 
> https://github.com/astrada/google-drive-ocamlfuse
> 
> Supposedly it makes it possible to mount google drive as a filesystem
> using fuse.
> 
> I wanted to try to package it myself, but ocaml seems a bit esoteric
> and 
> we are currently missing at least 5 dependencies in Fedora.
> 
> Nevertheless I think this package would be useful for many people.
> 
> Would anyone (perhaps someone who maintains other ocaml packages) be 
> willing to package this?


I did it in copr 
https://copr.fedorainfracloud.org/coprs/sergiomb/google-drive-ocamlfuse/

you got the spec here
https://github.com/sergiomb2/google-drive-ocamlfuse


feel free to use and to add to Fedora 

Best regards,


> -- 
> Marián Konček
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fix aarch64 build on embree

2022-06-29 Thread Peter Robinson

On Wed, Jun 29, 2022 at 10:06 AM Petr Pisar  wrote:
>
> V Tue, Jun 28, 2022 at 07:08:31PM -0700, Luya Tshimbalanga napsal(a):
> > Hello team,
> >
> > What is the way to disable `-mss2 for aarch64 build in embree?
> >
> > Spec file:
> > https://src.fedoraproject.org/rpms/embree/blob/rawhide/f/embree.spec
> >
> > Scratch build result:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=88867571
> >
> Are you sure your scratch build corresponds to the linked spec file?
>
> The spec file reads:
>
> %ifarch x86_64
> -DEMBREE_MAX_ISA=SSE4.2 \
> %else
> -DEMBREE_MAX_ISA=NONE \
> %endif
>
> but the build.log shows:
>
> + /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG 
> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG 
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG 
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF 
> -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include 
> -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc 
> -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 
> -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_BUILD_TYPE=Release 
> -DCMAKE_CXX_STANDARD=17 -DCMAKE_INSTALL_LIBDIR=/usr/lib64 
> -DCMAKE_INSTALL_PREFIX=/usr -DEMBREE_COMPACT_POLYS=ON 
> -DEMBREE_IGNORE_CMAKE_CXX_FLAGS=OFF -DEMBREE_ISPC_SUPPORT=ON 
> -DEMBREE_MAX_ISA=DEFAULT -DEMBREE_TUTORIALS=OFF
>
> There is -DEMBREE_MAX_ISA=DEFAULT instead of -DEMBREE_MAX_ISA=NONE.
>
> Morover, I'm not sure whether upstream supports a generic AArch64. README.md
> reads:
>
> Embree requires at least an x86 CPU with support for
> SSE2 or an Apple M1 CPU.

The CMake file just specifies NEON so I suspect it's just generic but
has only been tested on M1 Mac
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-35-20220629.0 compose check report

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-35-20220628.0):

ID: 1309357 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1309357
ID: 1309361 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1309361

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Grafana license change from ASL 2.0 to AGPLv3

2022-06-29 Thread Andreas Gerstmayr


On 28.06.22 18:11, Tomasz Torcz wrote:

On Tue, Jun 28, 2022 at 05:16:14PM +0200, Andreas Gerstmayr wrote:

I plan to submit a Grafana 8.5.6 rebase to Fedora rawhide in the coming
days.


   Why not to v9?



Mainly because I had the v8 rebase 98% ready since a few months, but due 
to vacation and other work commitments didn't get the time for a final 
test and build+push to Rawhide.


You're right, as v9 is already released upstream, it makes sense to skip 
v8. I'll work on a v9 rebase shortly and test if a v7 -> v9 upgrade is 
supported.



Cheers,
Andreas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fix aarch64 build on embree

2022-06-29 Thread Petr Pisar

V Tue, Jun 28, 2022 at 07:08:31PM -0700, Luya Tshimbalanga napsal(a):
> Hello team,
> 
> What is the way to disable `-mss2 for aarch64 build in embree?
> 
> Spec file:
> https://src.fedoraproject.org/rpms/embree/blob/rawhide/f/embree.spec
> 
> Scratch build result:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=88867571
> 
Are you sure your scratch build corresponds to the linked spec file?

The spec file reads:

%ifarch x86_64
-DEMBREE_MAX_ISA=SSE4.2 \
%else
-DEMBREE_MAX_ISA=NONE \
%endif

but the build.log shows:

+ /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON 
-DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr 
-DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 
-DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share 
-DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_BUILD_TYPE=Release 
-DCMAKE_CXX_STANDARD=17 -DCMAKE_INSTALL_LIBDIR=/usr/lib64 
-DCMAKE_INSTALL_PREFIX=/usr -DEMBREE_COMPACT_POLYS=ON 
-DEMBREE_IGNORE_CMAKE_CXX_FLAGS=OFF -DEMBREE_ISPC_SUPPORT=ON 
-DEMBREE_MAX_ISA=DEFAULT -DEMBREE_TUTORIALS=OFF

There is -DEMBREE_MAX_ISA=DEFAULT instead of -DEMBREE_MAX_ISA=NONE.

Morover, I'm not sure whether upstream supports a generic AArch64. README.md
reads:

Embree requires at least an x86 CPU with support for
SSE2 or an Apple M1 CPU.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fix aarch64 build on embree

2022-06-29 Thread Peter Robinson

> > Hello team,
> >
> > What is the way to disable `-mss2 for aarch64 build in embree?
>
> I think you mean msse2, the build should be using the distro default C
> flags for builds so it shouldn't be an issue, if you fix the build to
> use the proper distro flags the problem should go away. Details in the
> docs:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags
>
> > Spec file: 
> > https://src.fedoraproject.org/rpms/embree/blob/rawhide/f/embree.spec
> >
> > Scratch build result: 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=88867571

Completely not the right way to fix it, you're note actually supposed
to be overwriting the SSE levels set by the base project else it won't
run on older x86 devices either, but the below worked for me on a
scratch build. The aarch64 arch sets NEON by default so if you were
using the proper defaults you'd actually have gott hat anyway.

diff --git a/embree.spec b/embree.spec
index b2e6d8e..a9e8c91 100644
--- a/embree.spec
+++ b/embree.spec
@@ -92,6 +92,9 @@ export CXXFLAGS="%{optflags} -Wl,--as-needed"
 -DEMBREE_MAX_ISA=SSE4.2 \
 %else
 -DEMBREE_MAX_ISA=NONE \
+%endif
+%ifarch aarch64
+-DEMBREE_MAX_ISA=NEON \
 %endif
-DEMBREE_TUTORIALS=OFF
 %cmake_build
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package proposal: google-drive-ocamlfuse

2022-06-29 Thread Alexander Sosedkin

Quoting Marián Konček (2022-06-29 10:26:13)
> I recently discovered this project:
> https://github.com/astrada/google-drive-ocamlfuse
>
> Supposedly it makes it possible to mount google drive as a filesystem
> using fuse.

Not to devalue the request, but this requirement alone
should be covered by an already packaged rclone (https://rclone.org).

> I wanted to try to package it myself, but ocaml seems a bit esoteric and
> we are currently missing at least 5 dependencies in Fedora.
>
> Nevertheless I think this package would be useful for many people.
>
> Would anyone (perhaps someone who maintains other ocaml packages) be
> willing to package this?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

mujs license change from AGPLv3+ to ISC

2022-06-29 Thread Alain Vigne

As a new maintainer for this package [1], considering the upstream files
[2], I changed the License: field to ISC.

Regards.
[1] https://src.fedoraproject.org/rpms/mujs
[2] https://mujs.com/
-- 
Alain V.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Package proposal: google-drive-ocamlfuse

2022-06-29 Thread Marián Konček

I recently discovered this project: 
https://github.com/astrada/google-drive-ocamlfuse


Supposedly it makes it possible to mount google drive as a filesystem 
using fuse.


I wanted to try to package it myself, but ocaml seems a bit esoteric and 
we are currently missing at least 5 dependencies in Fedora.


Nevertheless I think this package would be useful for many people.

Would anyone (perhaps someone who maintains other ocaml packages) be 
willing to package this?


--
Marián Konček
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fix aarch64 build on embree

2022-06-29 Thread Peter Robinson

On Wed, Jun 29, 2022 at 3:15 AM Luya Tshimbalanga
 wrote:
>
> Hello team,
>
> What is the way to disable `-mss2 for aarch64 build in embree?

I think you mean msse2, the build should be using the distro default C
flags for builds so it shouldn't be an issue, if you fix the build to
use the proper distro flags the problem should go away. Details in the
docs:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags

> Spec file: 
> https://src.fedoraproject.org/rpms/embree/blob/rawhide/f/embree.spec
>
> Scratch build result: 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=88867571
>
>
> Thanks in advance.
>
> --
> Luya Tshimbalanga
> Fedora Design Team
> Fedora Design Suite maintainer
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Can we start changing License to SPDX now?

2022-06-29 Thread Bob Mauchin

On Wed, 29 Jun 2022, 09:48 Zbigniew Jędrzejewski-Szmek, 
wrote:

> On Wed, Jun 29, 2022 at 08:54:37AM +0200, Petr Pisar wrote:
> > > #2799 F38 Change proposal: SPDX License Phase 1
> > > APPROVED (+5,0,-0)
> >
> > Do I understand it correctly that we can change License tags in our spec
> files
> > to SPDX syntax right now?
> >
> > Or should we wait until updating
> >  to SPDX
> > identifiers?
>
> That's my understanding. The plan is to not treat the wiki as the
> authoritative source, but instead to generate a Docs page from a table
> in fedora-license-data.rpm. If the license is listed in
> /usr/share/fedora-license-data/licenses/fedora-licenses.json as
> approved:yes,
> then this should be enough. The plan is to rework the wiki too, but that'll
> likely take more time.
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure


Weren't there a proposal for a macro allowing to use both Spottags and SPDX
so we could merge --ff-only to the old branches? Not being able to do that
is a PITA.

Have a great day everyone!

Robert-André

>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-36-20220629.0 compose check report