Deepin Desktop Environment v20 coming to Rawhide with packages license changed

[Robin Lee]

* Upstream original release notes:
https://www.deepin.org/en/2020/09/11/deepin-20-innovation-is-ongoing/
* Versions of packages are actually sychronised with Arch Linux, not
directly with Deepin upstream.
* There are new packages released upstream but not packaged in Fedora.
We lack human power.
* The packages have been built with Qt 5.15.2
* Packit is deployed to maintain rpm packing stuff. And major number
of the specfiles has been merged upstream.
* dtkcore and dtkwidget license is changing to LGPLv3+
* dtkcore, dtkwidget and dtkwm so name versions bump to 5.

-robin
___
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

Re: Flatpak and __pycache__

[Kalev Lember]

On 11/29/20 17:55, Miro Hrončok wrote:

Here's a draft PR that should fix the Python 3 case:

https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/113

The Python 2 case is IMHO not worth it. It doesn't have __pycache__ or 
%pycached.


It might be a good idea to call %py_byte_compile in the spec files of 
flatpaked Python 2 RPMs if the bytecache is desired.




Sounds like a good plan to me. Thanks!

I replied in the PR as well.

--
Kalev
___
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

Fedora-Cloud-33-20201130.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-33-20201129.0):

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

Passed openQA tests: 6/7 (x86_64), 6/7 (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

[Test-Announce] 2020-11-30 @ 16:00 UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2020-11-30
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

We didn't meet for a few weeks, and this is the last slot before lots
of folks will be away over December, so let's have a meeting tomorrow.
Sorry for the short notice, I forgot to send this out Friday night.

I recall telling someone I'd put something on the agenda for this
meeting, but I can't remember who or what it was. Please, if you
remember, let me know and we'll work it in. Sorry about that!

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 34 status and Changes
3. IRC vs. Matrix?
4. Test Day / community event status
5. Open floor
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-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/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Adam Williamson]

On Mon, 2020-11-30 at 00:24 +0100, Dan Čermák wrote:
> Neal Gompa  writes:
> 
> > Richard Brown from openSUSE also informed me that it's technically
> > possible to do some level of audio subsystem QA using OpenQA, but I'm
> > not sure how to do it. Perhaps that's another avenue we can pursue to
> > improve integration testing coverage?
> 
> While it is technically possible to do audio testing in openQA, it is
> not really used a lot. The main reason is that the current
> implementation is rather brittle (albeit pretty clever): it converts the
> audio signal to an image (afaik it plots the intensity) and does its
> usual needle comparison. Unfortunately this does not work that well in
> practice and the one of the few audio tests that openSUSE has in openQA
> is a constant source of trouble, while catching very few bugs [1].
> 
> But even if openQA had a very reliable way to test audio, I'm afraid it
> wouldn't really help us out too much here. openQA is realistically only
> going to be able to cover your basic use cases, but it's not going to be
> able to test all the special audio setups that all the people who are
> into audio have at home (as that would require their hardware &
> software). So openQA would only test what the PipeWire devs are probably
> testing already anyway and it would not provide a whole lot of
> additional interesting test cases.
> 
> Now, this does not mean that we shouldn't test audio in Fedora's openQA
> (we don't atm), as that is still a valuable regression test. But we
> won't be able to cover a lot of the more interesting use cases where I
> would expect [2] that most of current the bugs are. Those will only get
> found by running this on real world hardware by folks that have their
> working setups.

Yeah, I looked into it before and this is basically why I didn't bother
implementing it; it doesn't buy us much more than we're getting
naturally from human testing anyway.
-- 
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

Re: s390x only buildroot problem

[Richard Shaw]

Pull request submitted:

https://src.fedoraproject.org/rpms/gstreamer1-plugins-bad-free/pull-request/6

Thanks,
Richard
___
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

Re: s390x only buildroot problem

[Richard Shaw]

Ok, missed some references to capital V, Vulkan. Got those fixed and have a
successful build:

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

Should I commit?

Thanks,
Richard
___
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

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Dan Čermák]

"Wim Taymans"  writes:

> So, the current sentiment is:
>
> * provide an easy way to test in f33, either copr or with regular packages.
>- rawhide is a not a good place to get good testing anyway
> * encourage people to test. Provide instructions on how to do this and how to
>leave feedback.
> * Carry this over to f34, probably with just the packages/easier switch.

Yeah, I have the feeling that we should give this a good round of
testing for a whole release cycle at least before we PipeWire the
default. Especially if we make it simple to switch between PulseAudio &
PipeWire, we'll give the developers much more usage data than from a few
test days.

> * propose permanent switch for f35
>   - it gets at least full cycle of testing (f34 + part of f33)
> * re-evaluate situation for f35 beta freeze to make a default switch.
>
> Although a bit slower than expected, I guess more testing is good. It sounds
> like an acceptable plan to me.
> I'm not sure how it works, if spinoffs can/want to make an earlier
> switch?

Hm, I don't see a technical reason why a certain edition of Fedora
couldn't ship with PipeWire by default earlier. Albeit I don't think
that jumping ahead of the rest of the distro would reflect very well on
the project, unless you call it "Fedora PipeWire Edition".


Cheers,

Dan


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

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Dan Čermák]

Neal Gompa  writes:

> Richard Brown from openSUSE also informed me that it's technically
> possible to do some level of audio subsystem QA using OpenQA, but I'm
> not sure how to do it. Perhaps that's another avenue we can pursue to
> improve integration testing coverage?

While it is technically possible to do audio testing in openQA, it is
not really used a lot. The main reason is that the current
implementation is rather brittle (albeit pretty clever): it converts the
audio signal to an image (afaik it plots the intensity) and does its
usual needle comparison. Unfortunately this does not work that well in
practice and the one of the few audio tests that openSUSE has in openQA
is a constant source of trouble, while catching very few bugs [1].

But even if openQA had a very reliable way to test audio, I'm afraid it
wouldn't really help us out too much here. openQA is realistically only
going to be able to cover your basic use cases, but it's not going to be
able to test all the special audio setups that all the people who are
into audio have at home (as that would require their hardware &
software). So openQA would only test what the PipeWire devs are probably
testing already anyway and it would not provide a whole lot of
additional interesting test cases.

Now, this does not mean that we shouldn't test audio in Fedora's openQA
(we don't atm), as that is still a valuable regression test. But we
won't be able to cover a lot of the more interesting use cases where I
would expect [2] that most of current the bugs are. Those will only get
found by running this on real world hardware by folks that have their
working setups.


Cheers,

Dan

Footnotes:
[1]  I've heard this only, take this with a pinch of salt.

[2]  emphasis on _expect_, not _know_. I really have no insight in the
 maturity of PiperWire.


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

Re: s390x only buildroot problem

[Richard Shaw]

Correction, I had a leftover character from a previous attempt... New
scratch build:

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

Thanks,
Richard

>
___
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

Re: s390x only buildroot problem

[Richard Shaw]

On Sun, Nov 29, 2020 at 2:55 PM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> On Sunday, 29 November 2020 at 21:36, Richard Shaw wrote:
> > On Sun, Nov 29, 2020 at 12:43 PM Rex Dieter  wrote:
> >
> > > Richard Shaw wrote:
> > >
> > > Other packages are (still) affected, including:
> > >
> > > vulkan-loader
> > >
> > > (and anything else that depends on it, including:
> > > gstreamer1-plugins-bad-free
> > >
> >
> > For the hell of it I added a conditional for s390x BR: vulcan and kicked
> > off a scratch build to see if it's optional.
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=56407778
>
> ...
> gst-libs/gst/vulkan/meson.build:146:2: ERROR: Problem encountered: vulkan
> plugin enabled, but vulkan.h not found
> ...
>
> I guess you need to disable vulkan plugin on s390x.
>

I've got a scratch build started that does just that. I can use pp rights
to do it but I feel it's a pretty invasive change to a package I don't
maintain.

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

Thanks,
Richard

$ fedpkg diff
diff --git a/gstreamer1-plugins-bad-free.spec
b/gstreamer1-plugins-bad-free.spec
index e60e4db..16fc69a 100644
--- a/gstreamer1-plugins-bad-free.spec
+++ b/gstreamer1-plugins-bad-free.spec
@@ -83,8 +83,10 @@ BuildRequires:  gtk3-devel >= 3.4
 BuildRequires:  bluez-libs-devel >= 5.0
 BuildRequires:  libwebp-devel
 BuildRequires:  mesa-libEGL-devel
+%ifnarch s390x
 BuildRequires:  vulkan-devel
 #BuildRequires:  mesa-vulkan-devel
+%endif
 BuildRequires:  webrtc-audio-processing-devel
 BuildRequires:  libaom-devel
 BuildRequires:  libmicrodns-devel
@@ -268,7 +270,10 @@ aren't tested well enough, or the code is not of good
enough quality.
 -D libde265=disabled -D musepack=disabled -D openni2=disabled \
 -D sctp=disabled -D svthevcenc=disabled -D voaacenc=disabled \
 -D zxing=disabled -D wpe=disabled -D x11=disabled \
--D openh264=disabled
+-D openh264=disabled  \
+%ifarch s390x
+-D vulkan=disabled}
+%endif

 %meson_build

@@ -370,7 +375,9 @@ rm $RPM_BUILD_ROOT%{_bindir}/playout
 %{_libdir}/libgstsctp-%{majorminor}.so.*
 %{_libdir}/libgsttranscoder-%{majorminor}.so.*
 %{_libdir}/libgsturidownloader-%{majorminor}.so.*
+%ifnarch s390x
 %{_libdir}/libgstvulkan-%{majorminor}.so.*
+%endif
 %{_libdir}/libgstwebrtc-%{majorminor}.so.*
 %if 0%{?fedora} || 0%{?rhel} > 7
 %{_libdir}/libgstwayland-%{majorminor}.so.*
@@ -486,7 +493,9 @@ rm $RPM_BUILD_ROOT%{_bindir}/playout
 %{_libdir}/gstreamer-%{majorminor}/libgstsoundtouch.so
 %{_libdir}/gstreamer-%{majorminor}/libgstsrt.so
 %{_libdir}/gstreamer-%{majorminor}/libgstsrtp.so
+%ifnarch s390x
 %{_libdir}/gstreamer-%{majorminor}/libgstvulkan.so
+%endif
 %if 0%{?fedora} || 0%{?rhel} > 7
 %{_libdir}/gstreamer-%{majorminor}/libgstwaylandsink.so
 %endif
@@ -571,7 +580,9 @@ rm $RPM_BUILD_ROOT%{_bindir}/playout
 %{_libdir}/libgstsctp-%{majorminor}.so
 %{_libdir}/libgsttranscoder-%{majorminor}.so
 %{_libdir}/libgsturidownloader-%{majorminor}.so
+%ifnarch s390x
 %{_libdir}/libgstvulkan-%{majorminor}.so
+%endif
 %{_libdir}/libgstwebrtc-%{majorminor}.so
 %if 0%{?fedora} || 0%{?rhel} > 7
 %{_libdir}/libgstwayland-%{majorminor}.so
@@ -589,7 +600,9 @@ rm $RPM_BUILD_ROOT%{_bindir}/playout
 %{_includedir}/gstreamer-%{majorminor}/gst/sctp
 %{_includedir}/gstreamer-%{majorminor}/gst/transcoder
 %{_includedir}/gstreamer-%{majorminor}/gst/uridownloader
+%ifnarch s390x
 %{_includedir}/gstreamer-%{majorminor}/gst/vulkan/
+%endif
 %{_includedir}/gstreamer-%{majorminor}/gst/webrtc/

 # pkg-config files
@@ -603,8 +616,10 @@ rm $RPM_BUILD_ROOT%{_bindir}/playout
 %{_libdir}/pkgconfig/gstreamer-sctp-%{majorminor}.pc
 %{_libdir}/pkgconfig/gstreamer-transcoder-%{majorminor}.pc
 %{_libdir}/pkgconfig/gstreamer-webrtc-%{majorminor}.pc
+%ifnarch s390x
 %{_libdir}/pkgconfig/gstreamer-vulkan-%{majorminor}.pc
 %{_libdir}/pkgconfig/gstreamer-vulkan-wayland-%{majorminor}.pc
+%endif


 %changelog
___
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

Re: s390x only buildroot problem

[Dominik 'Rathann' Mierzejewski]

On Sunday, 29 November 2020 at 21:36, Richard Shaw wrote:
> On Sun, Nov 29, 2020 at 12:43 PM Rex Dieter  wrote:
> 
> > Richard Shaw wrote:
> >
> > Other packages are (still) affected, including:
> >
> > vulkan-loader
> >
> > (and anything else that depends on it, including:
> > gstreamer1-plugins-bad-free
> >
> 
> For the hell of it I added a conditional for s390x BR: vulcan and kicked
> off a scratch build to see if it's optional.
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=56407778

...
gst-libs/gst/vulkan/meson.build:146:2: ERROR: Problem encountered: vulkan 
plugin enabled, but vulkan.h not found
...

I guess you need to disable vulkan plugin on s390x.

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

Re: s390x only buildroot problem

[Richard Shaw]

On Sun, Nov 29, 2020 at 12:43 PM Rex Dieter  wrote:

> Richard Shaw wrote:
>
> Other packages are (still) affected, including:
>
> vulkan-loader
>
> (and anything else that depends on it, including:
> gstreamer1-plugins-bad-free
>

For the hell of it I added a conditional for s390x BR: vulcan and kicked
off a scratch build to see if it's optional.

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

Thanks,
Richard
___
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

Re: s390x only buildroot problem

[Rex Dieter]

Richard Shaw wrote:

> Never mind, it has been reported and "fixed" it just needs to propagate to
> the builders I suppose.

Only part of it is fixed (worked-around): qt5-qtbase

Other packages are (still) affected, including:

vulkan-loader

(and anything else that depends on it, including:
gstreamer1-plugins-bad-free

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

The root cause is this commit, that dropped provding vulkan driver pkgs for 
s390:

https://src.fedoraproject.org/rpms/mesa/c/26ef46f507559d980e1e91f20e66463d5503bf3e

-- Rex

___
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

Re: s390x only buildroot problem

[Richard Shaw]

On Sun, Nov 29, 2020 at 10:07 AM José Abílio Matos  wrote:

> On Sunday, November 29, 2020 3:20:34 PM WET Richard Shaw wrote:
>
> > Never mind, it has been reported and "fixed" it just needs to propagate
> to
>
> > the builders I suppose.
>
>
> I am also in that queue. :-)
>
> Thank you for letting us know that the problem is fixed.
>

Well I HOPE it is fixed, the bug is closed...

https://bugzilla.redhat.com/1902449

Thanks,
Richard
___
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

Re: Flatpak and __pycache__

[Miro Hrončok]

On 11/29/20 3:22 PM, Kalev Lember wrote:

Can do. However, one question: When we find code in /app/lib(64)/pythonX.Y, 
do
we bytecompile with /usr/bin/pythonX.Y or /app/bin/pythonX.Y?


Awesome, thanks!

It depends: for python2.7 (gimp flatpak) we use python2.7 re-built for /app 
prefix (so it's bundled with the app's flatpak), but for regular python3 we just 
use the /usr-installed one that's part of the flatpak runtime (the runtime uses 
/usr prefix and app flatpaks use /app prefix).



Here's a draft PR that should fix the Python 3 case:

https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/113

The Python 2 case is IMHO not worth it. It doesn't have __pycache__ or 
%pycached.

It might be a good idea to call %py_byte_compile in the spec files of flatpaked 
Python 2 RPMs if the bytecache is desired.


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

Re: Flatpak and __pycache__

[Miro Hrončok]

On 11/29/20 3:22 PM, Kalev Lember wrote:

 >  > for python_libdir in `find "$RPM_BUILD_ROOT" -type d|grep -E
 > "/usr/lib(64)?/python[0-9]\.[0-9]$"`;
 >
 > ... which should use prefix instead of hardcoding /usr (or alternatively
scan
 > both /usr and /app).

Can do. However, one question: When we find code in /app/lib(64)/pythonX.Y, 
do
we bytecompile with /usr/bin/pythonX.Y or /app/bin/pythonX.Y?


Awesome, thanks!

It depends: for python2.7 (gimp flatpak) we use python2.7 re-built for /app 
prefix (so it's bundled with the app's flatpak), but for regular python3 we just 
use the /usr-installed one that's part of the flatpak runtime (the runtime uses 
/usr prefix and app flatpaks use /app prefix).


Would it be possible to just use %__python2 and %__python3 macros for 
byte-compiling? These are always set correctly by the flatpak macros, no matter 
if the interpreter is in /app or /usr.


Not in the way this is currently done, no. The script detects a 
Python-version-specific path and uses that Python version.


E.g. even if %__python3 is set to /usr/bin/pypy3, when the script fins files in 
/usr/lib(64)/python3.9, it compiles them with python3.9.


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

Re: s390x only buildroot problem

[José Abílio Matos]

On Sunday, November 29, 2020 3:20:34 PM WET Richard Shaw wrote:
> Never mind, it has been reported and "fixed" it just needs to propagate to
> the builders I suppose.
> 
> Thanks,
> Richard

I am also in that queue. :-)

Thank you for letting us know that the problem is fixed.
-- 
José Abílio___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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

Re: Exchange: libnss-mysql -> libnss-maria

[Tom Hughes via devel]

On 29/11/2020 15:08, Marius Schwarz wrote:

Am 29.11.20 um 15:29 schrieb Tom Hughes via devel:

On 29/11/2020 13:29, Marius Schwarz wrote:

as i just got informed, libnss-maria does support TLS/SSL connections 
to DB servers and is a replacement for the normal libnss-mysql, which 
does not support encrypted connections. The libnss-mysql package is 
unchanged for years now and is based on age old code from early 200x


I don't know if it makes a difference but the  Fedora libnss-mysql is
actually built against the mariadb client library.


You need options to set SSL key/certfiles for authentication against the 
db, but libnss-mysql does not offer such options.


Well if you want to do certificate authentication of the client
then you would need those but there's nothing to stop it doing
the same level of SSL as a typical https connection without
any of that - it would just validate the server certificate
against the system root certificate store.

I don't know offhand if the mysql/mariadb client libraries
will do that without prompting but it's certainly possible.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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

Re: s390x only buildroot problem

[Richard Shaw]

Never mind, it has been reported and "fixed" it just needs to propagate to
the builders I suppose.

Thanks,
Richard

>
___
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

Re: Exchange: libnss-mysql -> libnss-maria

[Marius Schwarz]

Am 29.11.20 um 15:29 schrieb Tom Hughes via devel:

On 29/11/2020 13:29, Marius Schwarz wrote:

as i just got informed, libnss-maria does support TLS/SSL connections 
to DB servers and is a replacement for the normal libnss-mysql, which 
does not support encrypted connections. The libnss-mysql package is 
unchanged for years now and is based on age old code from early 200x


I don't know if it makes a difference but the  Fedora libnss-mysql is
actually built against the mariadb client library.



You need options to set SSL key/certfiles for authentication against the 
db, but libnss-mysql does not offer such options.


best regards,
Marius
___
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

s390x only buildroot problem

[Richard Shaw]

I'm trying to build PySide2 for Rawhide but keep hitting this, and it only
happens on s390x:

DEBUG util.py:634:  Error:
DEBUG util.py:634:   Problem 1: package
qt5-qtbase-devel-5.15.2-3.fc34.s390x requires pkgconfig(vulkan), but
none of the providers can be installed
DEBUG util.py:634:- package
vulkan-loader-devel-1.2.154.1-1.fc34.s390x requires
vulkan-loader(s390-64) = 1.2.154.1-1.fc34, but none of the providers
can be installed
DEBUG util.py:634:- package
vulkan-loader-devel-1.2.154.1-1.fc34.s390x requires
libvulkan.so.1()(64bit), but none of the providers can be installed
DEBUG util.py:634:- conflicting requests
DEBUG util.py:634:- nothing provides mesa-vulkan-drivers(s390-64)
needed by vulkan-loader-1.2.154.1-1.fc34.s390x
DEBUG util.py:634:   Problem 2: package
qt5-qtbase-devel-5.15.2-3.fc34.s390x requires pkgconfig(vulkan), but
none of the providers can be installed
DEBUG util.py:634:- package qt5-qt3d-devel-5.15.2-2.fc34.s390x
requires pkgconfig(Qt5Core), but none of the providers can be
installed
DEBUG util.py:634:- package qt5-qt3d-devel-5.15.2-2.fc34.s390x
requires qt5-qtbase-devel(s390-64), but none of the providers can be
installed
DEBUG util.py:634:- package qt5-qt3d-devel-5.15.2-2.fc34.s390x
requires pkgconfig(Qt5Gui), but none of the providers can be installed
DEBUG util.py:634:- package qt5-qt3d-devel-5.15.2-2.fc34.s390x
requires pkgconfig(Qt5Network), but none of the providers can be
installed
DEBUG util.py:634:- package
vulkan-loader-devel-1.2.154.1-1.fc34.s390x requires
vulkan-loader(s390-64) = 1.2.154.1-1.fc34, but none of the providers
can be installed
DEBUG util.py:634:- package
vulkan-loader-devel-1.2.154.1-1.fc34.s390x requires
libvulkan.so.1()(64bit), but none of the providers can be installed
DEBUG util.py:634:- conflicting requests
DEBUG util.py:634:- nothing provides mesa-vulkan-drivers(s390-64)
needed by vulkan-loader-1.2.154.1-1.fc34.s390x
DEBUG util.py:634:   Problem 3: package
qt5-qtbase-devel-5.15.2-3.fc34.s390x requires pkgconfig(vulkan), but
none of the providers can be installed
DEBUG util.py:634:- package qt5-qtcharts-devel-5.15.2-2.fc34.s390x
requires pkgconfig(Qt5Core), but none of the providers can be
installed
DEBUG util.py:634:- package qt5-qtcharts-devel-5.15.2-2.fc34.s390x
requires qt5-qtbase-devel(s390-64), but none of the providers can be
installed
DEBUG util.py:634:- package qt5-qtcharts-devel-5.15.2-2.fc34.s390x
requires pkgconfig(Qt5Gui), but none of the providers can be installed
DEBUG util.py:634:- package qt5-qtcharts-devel-5.15.2-2.fc34.s390x
requires pkgconfig(Qt5Widgets), but none of the providers can be
installed
DEBUG util.py:634:- package
vulkan-loader-devel-1.2.154.1-1.fc34.s390x requires
vulkan-loader(s390-64) = 1.2.154.1-1.fc34, but none of the providers
can be installed
DEBUG util.py:634:- package
vulkan-loader-devel-1.2.154.1-1.fc34.s390x requires
libvulkan.so.1()(64bit), but none of the providers can be installed
DEBUG util.py:634:- conflicting requests
DEBUG util.py:634:- nothing provides mesa-vulkan-drivers(s390-64)
needed by vulkan-loader-1.2.154.1-1.fc34.s390x
DEBUG util.py:634:   Problem 4: package
qt5-qtbase-devel-5.15.2-3.fc34.s390x requires pkgconfig(vulkan), but
none of the providers can be installed
DEBUG util.py:634:- package
qt5-qtdatavis3d-devel-5.15.2-2.fc34.s390x requires pkgconfig(Qt5Core),
but none of the providers can be installed
DEBUG util.py:634:- package
qt5-qtdatavis3d-devel-5.15.2-2.fc34.s390x requires
qt5-qtbase-devel(s390-64), but none of the providers can be installed
DEBUG util.py:634:- package
qt5-qtdatavis3d-devel-5.15.2-2.fc34.s390x requires pkgconfig(Qt5Gui),
but none of the providers can be installed
DEBUG util.py:634:- package
vulkan-loader-devel-1.2.154.1-1.fc34.s390x requires
vulkan-loader(s390-64) = 1.2.154.1-1.fc34, but none of the providers
can be installed
DEBUG util.py:634:- package
vulkan-loader-devel-1.2.154.1-1.fc34.s390x requires
libvulkan.so.1()(64bit), but none of the providers can be installed
DEBUG util.py:634:- conflicting requests
DEBUG util.py:634:- nothing provides mesa-vulkan-drivers(s390-64)
needed by vulkan-loader-1.2.154.1-1.fc34.s390x
DEBUG util.py:634:   Problem 5: package
qt5-qtbase-devel-5.15.2-3.fc34.s390x requires pkgconfig(vulkan), but
none of the providers can be installed
DEBUG util.py:634:- package qt5-qttools-devel-5.15.2-2.fc34.s390x
requires pkgconfig(Qt5Core), but none of the providers can be
installed
DEBUG util.py:634:- package qt5-qttools-devel-5.15.2-2.fc34.s390x
requires qt5-qtbase-devel(s390-64), but none of the providers can be
installed
DEBUG util.py:634:- package qt5-qttools-devel-5.15.2-2.fc34.s390x
requires pkgconfig(Qt5Gui), but none of the providers can be installed
DEBUG util.py:634:- package qt5-qttools-devel-5.15.2-2.fc34.s390x
requires pkgconfig(Qt5Widgets), but none of the providers can be
installed
DEBUG util.py:634:- package qt5

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

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp
Xfce raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
4 of 43 required tests failed, 1 result missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 21/180 (x86_64), 20/109 (aarch64)

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

ID: 731554  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/731554
ID: 731583  Test: x86_64 Everything-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/731583
ID: 731586  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/731586
ID: 731645  Test: aarch64 Server-dvd-iso 
install_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/731645
ID: 731660  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/731660
ID: 731663  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_replica@uefi
URL: https://openqa.fedoraproject.org/tests/731663
ID: 731669  Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/731669
ID: 731673  Test: aarch64 Server-dvd-iso server_cockpit_default@uefi
URL: https://openqa.fedoraproject.org/tests/731673
ID: 731674  Test: aarch64 Server-dvd-iso base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/731674
ID: 731677  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/731677
ID: 731678  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/731678
ID: 731802  Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/731802

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

ID: 731557  Test: x86_64 Server-dvd-iso server_cockpit_default **GATING**
URL: https://openqa.fedoraproject.org/tests/731557
ID: 731564  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/731564
ID: 731565  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/731565
ID: 731572  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/731572
ID: 731576  Test: x86_64 Server-dvd-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/731576
ID: 731579  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/731579
ID: 731580  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/731580
ID: 731597  Test: x86_64 Workstation-live-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/731597
ID: 731598  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/731598
ID: 731603  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/731603
ID: 731605  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/731605
ID: 731616  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/731616
ID: 731619  Test: x86_64 KDE-live-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/731619
ID: 731620  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/731620
ID: 731632  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/731632
ID: 731639  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud **GATING**
URL: https://openqa.fedoraproject.org/tests/731639
ID: 731646  Test: aarch64 Server-dvd-iso install_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/731646
ID: 731684  Test: aarch64 Server-raw_xz-raw.xz 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/731684
ID: 731687  Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/731687
ID: 731702  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/731702
ID: 731769  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/731769
ID: 731792  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/731792
ID: 731796  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/731796
ID: 731816  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/731816
ID: 731825  

Re: Exchange: libnss-mysql -> libnss-maria

[Tom Hughes via devel]

On 29/11/2020 13:29, Marius Schwarz wrote:

as i just got informed, libnss-maria does support TLS/SSL connections to 
DB servers and is a replacement for the normal libnss-mysql, which does 
not support encrypted connections. The libnss-mysql package is unchanged 
for years now and is based on age old code from early 200x


I don't know if it makes a difference but the  Fedora libnss-mysql is
actually built against the mariadb client library.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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

Re: Flatpak and __pycache__

[Kalev Lember]

On Sun, Nov 29, 2020 at 3:00 PM Miro Hrončok  wrote:

> On 11/29/20 7:35 AM, Kalev Lember wrote:
> > On Sun, Nov 29, 2020 at 1:55 AM Miro Hrončok  > > wrote:
> >
> > On 11/28/20 10:06 PM, Ville-Pekka Vainio wrote:
> >  > Hi,
> >  >
> >  > I'm slowly working on reviving the Finnish spell-checking stack.
> When
> >  > working on the libvoikko package, I noticed the Python module now
> has
> >  > this in the file list:
> >  >
> >  > %if ! 0%{?flatpak}
> >  > %{python3_sitelib}/__pycache__/*
> >  > %endif
> >  >
> >  > Git blame takes me to this commit:
> >  >
> >
> https://src.fedoraproject.org/rpms/libvoikko/c/e1b9941462b82f208b814fc2f6e7f369bcda11a0?branch=master
> > <
> https://src.fedoraproject.org/rpms/libvoikko/c/e1b9941462b82f208b814fc2f6e7f369bcda11a0?branch=master
> >
> >  >
> >  > Apparently Flatpak could not handle __pycache__ stuff about six
> months ago.
> >  >
> >  > According to the packaging guidelines I should be using something
> like
> >  >
> >  > %pycached %{python3_sitelib}/%{name}.py
> >  >
> >  > This macro is defined in /usr/lib/rpm/macros.d/macros.python3 and
> it
> >  > seems like it does not take the Flatpak issue into account.
> >  > Should I just leave those lines as they are? Should the %pycached
> >  > macro be improved?
> >
> > You should be able to use the %pycached macro and if that breaks
> flatpaks, we
> > should amend that macro to support that instead of adding `%if !
> 0%{?flatpak}`
> > to individual spec files. The idea behind this macro is to be able
> to do
> > changes
> > in one place.
> >
> > However, it would help to know the reason why flatpaks don't have
> bytecode
> > caches. This is the first time I've seen this mentioned. It will
> require other
> > code to be adapted as well, for example %pyproject_save_files.
> >
> >
> > I believe this is because flatpaks are installed into /app, but the
> python
> > bytecode compiler only does it for /usr.
> >
> > brp-python-bytecompile has:
> >
> >  > for python_libdir in `find "$RPM_BUILD_ROOT" -type d|grep -E
> > "/usr/lib(64)?/python[0-9]\.[0-9]$"`;
> >
> > ... which should use prefix instead of hardcoding /usr (or alternatively
> scan
> > both /usr and /app).
>
> Can do. However, one question: When we find code in
> /app/lib(64)/pythonX.Y, do
> we bytecompile with /usr/bin/pythonX.Y or /app/bin/pythonX.Y?
>

Awesome, thanks!

It depends: for python2.7 (gimp flatpak) we use python2.7 re-built for /app
prefix (so it's bundled with the app's flatpak), but for regular python3 we
just use the /usr-installed one that's part of the flatpak runtime (the
runtime uses /usr prefix and app flatpaks use /app prefix).

Would it be possible to just use %__python2 and %__python3 macros for
byte-compiling? These are always set correctly by the flatpak macros, no
matter if the interpreter is in /app or /usr.

Kalev
___
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

Fedora-IoT-34-20201129.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 6/16 (x86_64), 8/15 (aarch64)

New failures (same test not failed in Fedora-IoT-34-20201128.0):

ID: 731839  Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_overlay
URL: https://openqa.fedoraproject.org/tests/731839
ID: 731864  Test: aarch64 IoT-dvd_ostree-iso base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/731864
ID: 731865  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/731865
ID: 731866  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/731866

Old failures (same test failed in Fedora-IoT-34-20201128.0):

ID: 731836  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/731836
ID: 731843  Test: x86_64 IoT-dvd_ostree-iso podman
URL: https://openqa.fedoraproject.org/tests/731843
ID: 731844  Test: x86_64 IoT-dvd_ostree-iso podman_client
URL: https://openqa.fedoraproject.org/tests/731844
ID: 731845  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/731845
ID: 731850  Test: x86_64 IoT-dvd_ostree-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/731850
ID: 731852  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/731852
ID: 731857  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/731857
ID: 731858  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/731858
ID: 731859  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/731859
ID: 731862  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/731862

Passed openQA tests: 7/15 (aarch64), 10/16 (x86_64)

New passes (same test not passed in Fedora-IoT-34-20201128.0):

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

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.31 to 0.19
Previous test data: https://openqa.fedoraproject.org/tests/730941#downloads
Current test data: https://openqa.fedoraproject.org/tests/731838#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

Re: Flatpak and __pycache__

[Miro Hrončok]

On 11/29/20 7:35 AM, Kalev Lember wrote:
On Sun, Nov 29, 2020 at 1:55 AM Miro Hrončok > wrote:


On 11/28/20 10:06 PM, Ville-Pekka Vainio wrote:
 > Hi,
 >
 > I'm slowly working on reviving the Finnish spell-checking stack. When
 > working on the libvoikko package, I noticed the Python module now has
 > this in the file list:
 >
 > %if ! 0%{?flatpak}
 > %{python3_sitelib}/__pycache__/*
 > %endif
 >
 > Git blame takes me to this commit:
 >

https://src.fedoraproject.org/rpms/libvoikko/c/e1b9941462b82f208b814fc2f6e7f369bcda11a0?branch=master


 >
 > Apparently Flatpak could not handle __pycache__ stuff about six months 
ago.
 >
 > According to the packaging guidelines I should be using something like
 >
 > %pycached %{python3_sitelib}/%{name}.py
 >
 > This macro is defined in /usr/lib/rpm/macros.d/macros.python3 and it
 > seems like it does not take the Flatpak issue into account.
 > Should I just leave those lines as they are? Should the %pycached
 > macro be improved?

You should be able to use the %pycached macro and if that breaks flatpaks, 
we
should amend that macro to support that instead of adding `%if ! 
0%{?flatpak}`
to individual spec files. The idea behind this macro is to be able to do
changes
in one place.

However, it would help to know the reason why flatpaks don't have bytecode
caches. This is the first time I've seen this mentioned. It will require 
other
code to be adapted as well, for example %pyproject_save_files.


I believe this is because flatpaks are installed into /app, but the python 
bytecode compiler only does it for /usr.


brp-python-bytecompile has:

 > for python_libdir in `find "$RPM_BUILD_ROOT" -type d|grep -E 
"/usr/lib(64)?/python[0-9]\.[0-9]$"`;


... which should use prefix instead of hardcoding /usr (or alternatively scan 
both /usr and /app).


Can do. However, one question: When we find code in /app/lib(64)/pythonX.Y, do 
we bytecompile with /usr/bin/pythonX.Y or /app/bin/pythonX.Y?


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

Exchange: libnss-mysql -> libnss-maria

[Marius Schwarz]

Hi,

as i just got informed, libnss-maria does support TLS/SSL connections to 
DB servers and is a replacement for the normal libnss-mysql, which does 
not support encrypted connections. The libnss-mysql package is unchanged 
for years now and is based on age old code from early 200x


As libnss-mysql  is used in PAM authentication an encrypted connection 
is vital for enterprise setups.


Normally, people use LDAP for remote auth on desktops, but been there, a 
mysql setup is so much easier to maintain and setup IMHO.


I suggest to test the new version and exchange it asap, if it's stable, 
has equal functionality and passed a code audit.


Projectlink:

https://github.com/istana/libnss-maria

___
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

[Test-Announce] Fedora-IoT 34 RC 20201129.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora-IoT 34 RC 20201129.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/34iot

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_34_RC_20201129.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_34_RC_20201129.0_General

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-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/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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

Fedora rawhide compose report: 20201129.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20201128.n.0
NEW: Fedora-Rawhide-20201129.n.0

= SUMMARY =
Added images:2
Dropped images:  5
Added packages:  0
Dropped packages:0
Upgraded packages:   65
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   1.06 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20201129.n.0.iso
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20201129.n.0.iso

= DROPPED IMAGES =
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20201128.n.0.iso
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20201128.n.0.s390x.raw.xz
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20201128.n.0.iso
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20201128.n.0.s390x.qcow2
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20201128.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  R-cli-2.2.0-1.fc34
Old package:  R-cli-2.1.0-1.fc34
Summary:  Helpers for Developing Command Line Interfaces
RPMs: R-cli
Size: 460.45 KiB
Size change:  36.65 KiB
Changelog:
  * Sat Nov 28 2020 Elliott Sales de Andrade  - 
2.2.0-1
  - Update to latest version (#1899946)
  - Rename check conditional to bootstrap


Package:  R-globals-0.14.0-1.fc34
Old package:  R-globals-0.13.1-1.fc34
Summary:  Identify Global Objects in R Expressions
RPMs: R-globals
Size: 104.76 KiB
Size change:  9.24 KiB
Changelog:
  * Sat Nov 28 2020 Elliott Sales de Andrade  - 
0.14.0-1
  - Update to latest version (#1900408)


Package:  R-gplots-3.1.1-1.fc34
Old package:  R-gplots-3.1.0-1.fc34
Summary:  Various R Programming Tools for Plotting Data
RPMs: R-gplots
Size: 623.05 KiB
Size change:  597 B
Changelog:
  * Sat Nov 28 2020 Elliott Sales de Andrade  - 
3.1.1-1
  - Update to latest version (#1902405)


Package:  R-pak-0.1.2.1-1.fc34
Old package:  R-pak-0.1.2-2.fc34
Summary:  Another Approach to Package Installation
RPMs: R-pak
Size: 415.23 KiB
Size change:  1.21 KiB
Changelog:
  * Sat Nov 28 2020 Elliott Sales de Andrade  - 
0.1.2.1-1
  - Update to latest version (#1899792)


Package:  R-pillar-1.4.7-1.fc34
Old package:  R-pillar-1.4.6-2.fc33
Summary:  Coloured Formatting for Columns
RPMs: R-pillar
Size: 193.36 KiB
Size change:  -620 B
Changelog:
  * Sat Nov 28 2020 Elliott Sales de Andrade  - 
1.4.7-1
  - Update to latest version (#1899843)
  - Rename check conditional as bootstrap


Package:  R-rlang-0.4.9-1.fc34
Old package:  R-rlang-0.4.8-1.fc34
Summary:  Functions for Base Types and Core R and 'Tidyverse' Features
RPMs: R-rlang
Size: 5.45 MiB
Size change:  -33.98 KiB
Changelog:
  * Sat Nov 28 2020 Elliott Sales de Andrade  - 
0.4.9-1
  - Update to latest version (#1901765)


Package:  YafaRay-3.5.1-4.fc34
Old package:  YafaRay-3.5.1-3.fc34.1
Summary:  A free open-source ray-tracing render engine
RPMs: YafaRay YafaRay-blender YafaRay-devel YafaRay-lib python3-YafaRay
Size: 4.50 MiB
Size change:  3.41 KiB
Changelog:
  * Sat Nov 28 2020 Luya Tshimbalanga  - 3.5.1-4
  - Rebuild for Blender 2.91


Package:  blender-1:2.91.0-2.fc34
Old package:  blender-1:2.91.0-1.fc34
Summary:  3D modeling, animation, rendering and post-production
RPMs: blender blender-fonts blender-rpm-macros
Size: 118.55 MiB
Size change:  43.79 KiB
Changelog:
  * Fri Nov 27 2020 Fedora Release Monitoring 
 - 1:2.91.0-2
  - Rebuild for embree 3.12.1


Package:  cddlib-1:0.94l-1.fc34
Old package:  cddlib-1:0.94j-6.fc33
Summary:  A library for generating all vertices in convex polyhedrons
RPMs: cddlib cddlib-devel cddlib-static cddlib-tools
Size: 4.48 MiB
Size change:  -12.28 KiB
Changelog:
  * Sat Nov 28 2020 Jerry James  - 1:0.94l-1
  - Version 0.94l


Package:  devscripts-2.20.5-1.fc34
Old package:  devscripts-2.20.4-2.fc33
Summary:  Scripts for Debian Package maintainers
RPMs: devscripts devscripts-checkbashisms
Size: 2.99 MiB
Size change:  92.51 KiB
Changelog:
  * Sat Nov 28 2020 Sandro Mani  - 2.20.5-1
  - Update to 2.20.5


Package:  drat-trim-0-0.8.20200914.d13f761.fc34
Old package:  drat-trim-0-0.7.20200605.9afad0f.fc33
Summary:  Proof checker for DIMACS proofs
RPMs: drat-trim drat-trim-devel drat-trim-tools
Size: 391.81 KiB
Size change:  18.07 KiB
Changelog:
  * Sat Nov 28 2020 Jerry James  - 0-0.8.20200914.d13f761
  - Update for proof emission from lrat-check

Fedora-Cloud-32-20201129.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-32-20201128.0):

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

Passed openQA tests: 6/7 (x86_64), 6/7 (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