Re: Is there a Qt5 rebuild in progress?

2020-09-13 Thread Jan Grulich

Hi,

all qt5-* packages + all the packages using private API which needed rebuild 
were build in a side tag and tagged once the update was complete to make sure I 
don't break anything. Is this still an issue?

Regards,
Jan

Dne 11. 09. 20 v 22:10 Miro Hrončok napsal(a):

Hello,

dozens of my packages suddenly fail to resolve build dependencies with things 
like the ones below.

Is there a Qt5 rebuild in progress?

This build seem to be tagged in a side tag and also in f34:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1608618

Is that on purpose?



Problem: package qt5-qtscript-devel-5.14.2-4.fc33.x86_64 requires 
qt5-qtscript(x86-64) = 5.14.2-4.fc33, but none of the providers can be installed
- package qt5-qtscript-devel-5.14.2-4.fc33.x86_64 requires 
libQt5Script.so.5()(64bit), but none of the providers can be installed
- package qt5-qtscript-devel-5.14.2-4.fc33.x86_64 requires 
libQt5ScriptTools.so.5()(64bit), but none of the providers can be installed
- conflicting requests
- nothing provides libQt5Core.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtscript-5.14.2-4.fc33.x86_64
- nothing provides libQt5Widgets.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtscript-5.14.2-4.fc33.x86_64
- nothing provides qt5-qtbase(x86-64) = 5.14.2 needed by 
qt5-qtscript-5.14.2-4.fc33.x86_64
Problem: package qt5-qtxmlpatterns-devel-5.14.2-3.fc33.x86_64 requires 
qt5-qtxmlpatterns(x86-64) = 5.14.2-3.fc33, but none of the providers can be 
installed
- package qt5-qtxmlpatterns-devel-5.14.2-3.fc33.x86_64 requires 
libQt5XmlPatterns.so.5()(64bit), but none of the providers can be installed
- package qt5-qtxmlpatterns-devel-5.14.2-3.fc33.x86_64 requires 
libQt5XmlPatterns.so.5(Qt_5)(64bit), but none of the providers can be installed
- conflicting requests
- nothing provides libQt5Core.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtxmlpatterns-5.14.2-3.fc33.x86_64
- nothing provides libQt5Qml.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtxmlpatterns-5.14.2-3.fc33.x86_64
- nothing provides qt5-qtbase(x86-64) = 5.14.2 needed by 
qt5-qtxmlpatterns-5.14.2-3.fc33.x86_64

Problem: conflicting requests
- nothing provides libQt5Gui.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qttools-devel-5.14.2-3.fc33.x86_64
Problem: package pcl-devel-1.11.0-4.fc33.x86_64 requires vtk-devel, but none of 
the providers can be installed
- package vtk-devel-8.2.0-23.fc34.x86_64 requires cmake(Qt5UiPlugin), but none 
of the providers can be installed
- conflicting requests
- nothing provides libQt5Gui.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qttools-devel-5.14.2-3.fc33.x86_64
Problem: package qt5-qtsvg-devel-5.14.2-3.fc33.x86_64 requires 
qt5-qtsvg(x86-64) = 5.14.2-3.fc33, but none of the providers can be installed
- package qt5-qtsvg-devel-5.14.2-3.fc33.x86_64 requires 
libQt5Svg.so.5()(64bit), but none of the providers can be installed
- conflicting requests
- nothing provides libQt5Gui.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtsvg-5.14.2-3.fc33.x86_64
- nothing provides libQt5Core.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtsvg-5.14.2-3.fc33.x86_64
- nothing provides libQt5Widgets.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtsvg-5.14.2-3.fc33.x86_64
- nothing provides qt5-qtbase(x86-64) = 5.14.2 needed by 
qt5-qtsvg-5.14.2-3.fc33.x86_64
Problem: package qt5-qttools-static-5.14.2-3.fc33.x86_64 requires 
qt5-qttools-devel(x86-64) = 5.14.2-3.fc33, but none of the providers can be 
installed
- conflicting requests
- nothing provides libQt5Gui.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qttools-devel-5.14.2-3.fc33.x86_64
Problem: package qt5-qtxmlpatterns-devel-5.14.2-3.fc33.x86_64 requires 
qt5-qtxmlpatterns(x86-64) = 5.14.2-3.fc33, but none of the providers can be 
installed
- package qt5-qtxmlpatterns-devel-5.14.2-3.fc33.x86_64 requires 
libQt5XmlPatterns.so.5()(64bit), but none of the providers can be installed
- package qt5-qtxmlpatterns-devel-5.14.2-3.fc33.x86_64 requires 
libQt5XmlPatterns.so.5(Qt_5)(64bit), but none of the providers can be installed
- conflicting requests
- nothing provides libQt5Core.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtxmlpatterns-5.14.2-3.fc33.x86_64
- nothing provides libQt5Qml.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtxmlpatterns-5.14.2-3.fc33.x86_64
- nothing provides qt5-qtbase(x86-64) = 5.14.2 needed by 
qt5-qtxmlpatterns-5.14.2-3.fc33.x86_64

Problem: package qt5-qtgamepad-devel-5.14.2-3.fc33.x86_64 requires 
libQt5Gamepad.so.5()(64bit), but none of the providers can be installed
- package qt5-qtgamepad-devel-5.14.2-3.fc33.x86_64 requires 
qt5-qtgamepad(x86-64) = 5.14.2-3.fc33, but none of the providers can be 
installed
- conflicting requests
- nothing provides libQt5Core.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtgamepad-5.14.2-3.fc33.x86_64
- nothing provides qt5-qtbase(x86-64) = 5.14.2 needed by 
qt5-qtgamepad-5.14.2-3.fc33.x86_64
Problem: package qt5-qtmultimedia-devel-5.14.2-3.fc33.

Re: [Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

2020-09-13 Thread John M. Harris Jr
On Friday, September 11, 2020 4:36:38 AM MST Björn Persson wrote:
> John M. Harris Jr wrote:
> > On Thursday, September 10, 2020 11:56:25 PM MST alcir...@posteo.net wrote:
> > > But systemd in Fedora is built to use
> > > FallbackNTPServers=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org
> > > 2.fedora.pool.ntp.org 3.fedora.pool.ntp.org
> > 
> > Sounds like a good change, which should be made for DNS as well.
> 
> So where is a global pool of volunteer-provided DNS resolvers similar
> to pool.ntp.org? I've never heard of one, and I suspect it's not
> advisable to do that with DNS.

For DNS, I'm suggesting that "FallbackDNSServers=\n" should be added to the 
configuration file. The only case where I can see no configured DNS servers 
being populated with preset DNS servers would be when DHCP is used, in which 
case, NetworkManager can be modified to include some logic for that. 
Otherwise, the system is actively acting against the interests of the user.

-- 
John M. Harris, Jr.


___
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: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

2020-09-13 Thread Kevin Kofler
Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPlasma
> 
> == Summary ==
> Change the default session selection in SDDM to prefer the
> Wayland-based KDE Plasma Desktop session over the X11-based one.
> 
> == Owner ==
> * Name: [[User:Ngompa|Neal Gompa]], [[User:Rdieter|Rex Dieter]],
> [[User:Jgrulich|Jan Grulich]]
> * Email: ngomp...@gmail.com, rdie...@gmail.com, jgrul...@redhat.com
> * Product: KDE Spin
> * Responsible WG: KDE SIG
> 
> == Detailed Description ==
> 
> With KDE Plasma 5.20, the KDE Plasma desktop environment has reached a
> point where nearly all commonly used features in the desktop and all
> major applications function in the Plasma Wayland environment on all
> major GPUs (including NVIDIA with the proprietary driver). Starting
> with Plasma 5.20 in Fedora 34, we will change the default
> configuration for Wayland and X11 Plasma sessions so that Wayland is
> preferred and used by default, while permitting the X11 session to be
> selected as the alternative desktop environment option.

I do not think that Plasma on Wayland is ready for production use at this 
time. E.g., middle-click paste support is still incomplete: interoperability 
of the feature with X11 and GTK applications is not working yet. (X11 
because the XWayland parts of the middle-click feature are not yet 
implemented in KWin-Wayland, GTK because KWin supports only the final 
standardized version of the extension whereas GTK apparently still only 
implements its own pre-standard version with a differently-named namespace.) 
I believe that there are also other open issues with Plasma on Wayland.

Kevin Kofler
___
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: The Future of the Java Stack (also regarding ELN and RHEL)

2020-09-13 Thread Kevin Kofler
Mikolaj Izdebski wrote:
> Modularity provides not only a different way of grouping or delivering
> RPM packages, but most importantly, a different way of building RPM
> packages.
> 
> You get a side tag in Koji where you can have private build-only
> dependencies that are discarded (filtered) once they are no longer
> needed, after module build is done. For build-only packages most of
> security vulnerabilities are not exploitable easily, or at all,
> therefore are low-severity, which greatly limits maintenance work
> required to address them. For example, if upstream tests are ran on an
> obsolete, 12-years old version of Tomcat, I don't need to skip tests,
> but I can package old Tomcat and run the tests. I don't need to update
> that Tomcat or fix security issues as they are not exploitable in
> buildroot - Tomcat runs in embedded mode, does not listen on the
> network etc. Not something that I could with ursine Tomcat packages -
> it would get delivered to users, and we have no control how they use
> it - we would need to fix all important user-reported bugs and CVEs as
> they are potentially exploitable.
> 
> Modularity also introduced the concept of API packages - non-API
> packages can have limited usability, with some non-important features
> removed. For example if all I need is a small part of Tomcat, I can
> reduce tomcat package to build just the tiny parts that I need, which
> don't have any dependencies. Again, not something I could do with
> ursine Tomcat package.

But unfortunately, you unilaterally turning most Java packages private this 
way is exactly what put the Java stack in the current state, where it is 
broken for most other users because the packages they need and were relying 
on are no longer available in the public repository.

Tomcat is used by many users, not just as a build dependency (but that, 
too), but also on development machines to test web applications and on test 
and production servers to deploy them.

Sure, a 12-year-old version is hopefully not what the users will need, but 
there the solution ought to be to fix the offending test suite to work with 
the current version of Tomcat (downstream if upstream refuses the fix).

> Another, more concrete example: core Ant doesn't have any dependencies
> beyond JDK. It is easy to build and maintain, yet very functional. On
> the other hand, full Ant with all the optional tasks depends on more
> than 200 Java packages. For the purpose of building all packages that
> I am interested in, core Ant with JUnit tasks (total of 3 packages) is
> sufficient. Functionalities of Ant like sending emails or image
> processing are obviously not needed in this case. If building other
> packages is the only use of Ant then it can be maintained much more
> easily (3 instead of ~250 packages). But when Ant is ursine package in
> Fedora then it should be the full Ant - we can't claim to deliver Ant
> to users while it is just part of it. Eclipse in Fedora requires full
> Ant too.

Given the last sentence (Eclipse needs full Ant), I see no realistic way 
around packaging the whole thing and not just the minimal subset.

> It's not about the workflow, it is about reducing package maintenance
> work that is required. Modularity allows us to greatly reduce the
> number of packages by patching-out non-API packages to remove unneeded
> features and it allows us to spend less time on fixing bugs in
> packages that are used merely as build dependencies and which we don't
> intend to be used by end users.

But you have to understand that, while all this reduces your workload, it 
makes everyone else's (other packagers', developer users', even end users') 
life harder.

As far as I can see from this and earlier threads, the packages you maintain 
are, in their current form, entirely useless for several potential users.

Personally, I use Java for my day job, but I'm pretty much left using only 
OpenJDK from packages. The libraries, we have always bundled JARs ourselves. 
NetBeans, I used to use the Fedora package, but it was discontinued years 
ago, so I had to switch to the upstream binaries. And now what you have been 
doing to Tomcat lately means I am going to have to work with the upstream 
JARs there too.

Kevin Kofler
___
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: F32 -> F33 upgrade

2020-09-13 Thread Miro Hrončok

On 13. 09. 20 14:10, Marcin Juszkiewicz wrote:


I assume that there will be a proper thread for testing such upgrade
some time after Beta point but I had some time today I checked will it
work.

On my system it looks like deja-dup/duply/duplicity have a problem with
dependencies:

snip


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

--
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: F32 -> F33 upgrade

2020-09-13 Thread Samuel Sieb

On 9/13/20 5:10 AM, Marcin Juszkiewicz wrote:

On my system it looks like deja-dup/duply/duplicity have a problem with
dependencies:

[root@puchatek ~]# LANGUAGE=C dnf distrosync --releasever 33


The officially recommended method is "dnf system-upgrade".  I often need 
to add "--allowerasing" to that as well.
However, that won't fix this issue.  The build history for 
python-google-api-core appears to be a little messed up:

https://koji.fedoraproject.org/koji/packageinfo?packageID=31409
___
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: [EPEL-devel] Re: Proposing an EPEL packaging SIG

2020-09-13 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Sep 11, 2020 at 03:50:58PM -0700, Michel Alexandre Salim wrote:
> We discussed the proposal a bit at today's EPEL SC meeting; here's a
> revised proposal taking into account the suggestions from the meeting
> and earlier in this list.
> 
> ## The SIG
> - bstinson pointed out that epel-wranglers was started to address the
> same issue, we can resurrect that
> - we want to limit the access to epel* branches only, not all branches,
> as suggested both here and at the meeting. Any change the epel-
> wranglers want to make to the Rawhide branch can be done as a PR
>   - the EPEL branch will likely diverge from master over time anyway
> - the collaborator permission (available since August, yay) can be used
> for such granular access
>   - nirik pointed out that collaborators can't yet request new
> branches, if the proposal is approved we can work on making the `fedpkg
> request-branch` flow support this
>   - carlwgeorge suggested getting the group up and running first, and
> working on automation later
> 
> ## Workflow
> - no objection that I recall to having epel-wranglers automatically get
> access if the Fedora maintainers do not respond (so we can circumvent
> needing to do a non-responsive maintainer request)
>   - we probably won't have this automated at the beginning, see above
> - down the line, epel-wranglers need to decide on what to do with
> releases they no longer want to support (e.g. when everyone involved
> only cares about epel10 and epel9 and there's a CVE affecting epel8).
> the normal orphan process probably works - we announce the package is
> being orphaned by the group on epel-devel

+1 for the proposal. The group-maintenance approach is being used more
and more, and it seems good to use that also for EPEL. I'd be happy to
give access to any and all epel branches on my packages to the SIG.

Zbyszek

> Let's continue discussing the proposal in this thread, as suggested
> during the meeting.
> 
> Thanks all,
___
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


Claiming Ownership of a Retired Package: catimg

2020-09-13 Thread K. de Jong via devel
Hi,


As per the wiki [1], I'm announcing that I want to take over the
package catimg. The package was orphaned because the current maintainer
doesn't have time anymore. The upstream project is still active and I'm
in contact with the developer.

Since the package is already retired, the review process needs to be
restarted, I already filed a bug report for it [2].


Kind regards,
Kees


[1] 
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1878514


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


Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

2020-09-13 Thread Alexey Avramov
> If you actually tried to use the memory it says in MemAvailable, you
> may very well already get bad side effects as the kernel needs to
> reclaim memory used for other purposes (file caches, mmap'ed
> executables, heap, …). Depending on the workload, this may already
> cause the system to start thrashing.

memavaild[1] is yet another tool to improve responsiveness during heavy 
swapping. How it works: slices are swapped out when MemAvailable is low by 
reducing memory.max (values change dynamically). Effects: performance increases 
in tasks that requires heavy swapping, especially in io-bound tasks. At the 
same time, tasks are performed at less io and memory pressure. It may be used 
out of the box with any DE.

With combination of prelockd and memavaild GUI remains responsive with high 
memory and io pressure (pressure=85[2] with system and swap on HDD, I taked 
screenshot, GUI was not freezed). This proves that high memory pressure (by 
PSI) does not always correspond to system hang (psi-monitor uses mem 
pressure=10 as a thigger, for example).

[1] https://github.com/hakavlad/memavaild
[2] https://ibb.co/hKGy0bZ
___
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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

2020-09-13 Thread Alexey Avramov
> So with
> applications started, you might get higher.

I think we should protect only basic GUI. On computers with 16G+ RAM locking 1G 
memory with apps should not be a problem if it helps to improve responsiveness.

> Was that with or without swap?

It was without swap, but with swap it has the same effect (faster killer coming 
and system reclaiming) + responsiveness was improved during heavy swapping.

> I feel that uresourced is just nicer conceptually.
> So uresourced is
> going to be ineffective for KDE for the time being.

However, the advantage of prelockd is that may be used on old systems with any 
DE and any file system and an init. On Debian 9 Mate locking 150-200M takes 
very good effect. On Fedora with LXDE 200M is also good value.
___
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: unscribe Fedora

2020-09-13 Thread Peter Robinson
Hi Virginia,

I filed a ticket with our infrastructure team to have that sorted out
for you, it should happen this week.

The ticket can be found here for reference:
https://pagure.io/fedora-infrastructure/issue/9315

Regards,
Peter

On Sun, Sep 13, 2020 at 4:24 PM Thomas Gilliard  wrote:
>
> Thomas Gilliard passed away July 26,2020.  Please unscribe him from all
> e-mails.
>
> Thank You, Virginia Gilliard, wife
> ___
> 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
___
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


unscribe Fedora

2020-09-13 Thread Thomas Gilliard
Thomas Gilliard passed away July 26,2020.  Please unscribe him from all 
e-mails.


Thank You, Virginia Gilliard, wife
___
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-20200913.0 compose check report

2020-09-13 Thread Fedora compose checker
Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

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

ID: 664326  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/664326

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


Fedora-33-20200913.n.0 compose check report

2020-09-13 Thread Fedora compose checker
No missing expected images.

Failed openQA tests: 1/181 (x86_64)

Old failures (same test failed in Fedora-33-20200912.n.0):

ID: 664220  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/664220

Soft failed openQA tests: 9/181 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-33-20200912.n.0):

ID: 664164  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/664164
ID: 664191  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/664191
ID: 664204  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/664204
ID: 664224  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/664224
ID: 664227  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/664227
ID: 664241  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/664241
ID: 664254  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/664254
ID: 664275  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/664275
ID: 664324  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/664324

Passed openQA tests: 171/181 (x86_64)

New passes (same test not passed in Fedora-33-20200912.n.0):

ID: 664253  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/664253
ID: 664278  Test: x86_64 universal upgrade_2_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/664278

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
System load changed from 1.51 to 1.20
Average CPU usage changed from 39.43809524 to 26.4
Previous test data: https://openqa.fedoraproject.org/tests/663622#downloads
Current test data: https://openqa.fedoraproject.org/tests/664188#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
Used swap changed from 35 MiB to 27 MiB
System load changed from 1.62 to 0.86
Previous test data: https://openqa.fedoraproject.org/tests/663624#downloads
Current test data: https://openqa.fedoraproject.org/tests/664190#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
System load changed from 1.03 to 1.19
Previous test data: https://openqa.fedoraproject.org/tests/663641#downloads
Current test data: https://openqa.fedoraproject.org/tests/664207#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
System load changed from 1.10 to 0.81
Average CPU usage changed from 27.00952381 to 14.86190476
Previous test data: https://openqa.fedoraproject.org/tests/663642#downloads
Current test data: https://openqa.fedoraproject.org/tests/664208#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default_upload: 
Used mem changed from 736 MiB to 822 MiB
Used swap changed from 28 MiB to 23 MiB
System load changed from 0.49 to 0.70
Previous test data: https://openqa.fedoraproject.org/tests/663658#downloads
Current test data: https://openqa.fedoraproject.org/tests/664224#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default@uefi: 
Used swap changed from 22 MiB to 25 MiB
System load changed from 0.37 to 0.23
Previous test data: https://openqa.fedoraproject.org/tests/663661#downloads
Current test data: https://openqa.fedoraproject.org/tests/664227#downloads

Installed system changes in test x86_64 universal install_package_set_minimal: 
System load changed from 0.08 to 0.24
Previous test data: https://openqa.fedoraproject.org/tests/663749#downloads
Current test data: https://openqa.fedoraproject.org/tests/664315#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


Fedora 33 compose report: 20200913.n.0 changes

2020-09-13 Thread Fedora Rawhide Report
OLD: Fedora-33-20200912.n.0
NEW: Fedora-33-20200913.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

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

Size change of upgraded packages:   0 B
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-33-20200912.n.0.ppc64le.tar.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
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


F32 -> F33 upgrade

2020-09-13 Thread Marcin Juszkiewicz

I assume that there will be a proper thread for testing such upgrade
some time after Beta point but I had some time today I checked will it
work.

On my system it looks like deja-dup/duply/duplicity have a problem with
dependencies:

[root@puchatek ~]# LANGUAGE=C dnf distrosync --releasever 33 
Last metadata expiration check: 0:18:13 ago on nie, 13 wrz 2020, 13:50:13.
Error: 

Problem 1: problem with installed package 
python3-google-api-client-1:1.6.7-11.fc32.noarch
  - python3-google-api-client-1:1.6.7-11.fc32.noarch does not belong to a 
distupgrade repository
  - nothing provides python3-google-api-core >= 1.18.0 needed by 
python3-google-api-client-1:1.10.0-2.fc33.noarch

Problem 2: package duplicity-0.8.15-2.fc33.x86_64 requires python3-PyDrive, but 
none of the providers can be installed
  - problem with installed package duplicity-0.8.15-2.fc32.x86_64
  - package python3-PyDrive-1.3.1-13.fc33.noarch requires 
python3.9dist(google-api-python-client) >= 1.2, but none of the providers can 
be installed
  - python3-PyDrive-1.3.1-12.fc32.noarch does not belong to a distupgrade 
repository
  - duplicity-0.8.15-2.fc32.x86_64 does not belong to a distupgrade repository
  - nothing provides python3-google-api-core >= 1.18.0 needed by 
python3-google-api-client-1:1.10.0-2.fc33.noarch

Problem 3: problem with installed package python3-PyDrive-1.3.1-12.fc32.noarch
  - package python3-PyDrive-1.3.1-12.fc32.noarch requires python(abi) = 3.8, 
but none of the providers can be installed
  - package python3-PyDrive-1.3.1-13.fc33.noarch requires 
python3.9dist(google-api-python-client) >= 1.2, but none of the providers can 
be installed
  - python3-3.8.5-5.fc32.x86_64 does not belong to a distupgrade repository
  - nothing provides python3-google-api-core >= 1.18.0 needed by 
python3-google-api-client-1:1.10.0-2.fc33.noarch

Problem 4: package duply-2.2.2-2.fc33.noarch requires duplicity, but none of 
the providers can be installed
  - package duplicity-0.8.15-2.fc33.x86_64 requires python3-PyDrive, but none 
of the providers can be installed
  - package duplicity-0.8.15-2.fc32.x86_64 requires python(abi) = 3.8, but none 
of the providers can be installed
  - package python3-PyDrive-1.3.1-12.fc32.noarch requires 
python3.8dist(oauth2client) >= 4, but none of the providers can be installed
  - package python3-3.8.5-5.fc32.x86_64 requires python3-libs(x86-64) = 
3.8.5-5.fc32, but none of the providers can be installed
  - problem with installed package duply-2.2.2-1.fc32.noarch
  - package python3-PyDrive-1.3.1-13.fc33.noarch requires 
python3.9dist(google-api-python-client) >= 1.2, but none of the providers can 
be installed
  - python3-oauth2client-4.1.3-10.fc32.noarch does not belong to a distupgrade 
repository
  - python3-libs-3.8.5-5.fc32.x86_64 does not belong to a distupgrade repository
  - duply-2.2.2-1.fc32.noarch does not belong to a distupgrade repository
  - nothing provides python3-google-api-core >= 1.18.0 needed by 
python3-google-api-client-1:1.10.0-2.fc33.noarch

Problem 5: package deja-dup-42.2-1.fc33.x86_64 requires duplicity >= 0.6.23, 
but none of the providers can be installed
  - package duplicity-0.8.15-2.fc32.x86_64 requires python3-PyDrive, but none 
of the providers can be installed
  - package duplicity-0.8.15-2.fc33.x86_64 requires python3-PyDrive, but none 
of the providers can be installed
  - package python3-PyDrive-1.3.1-12.fc32.noarch requires python3.8dist(pyyaml) 
>= 3, but none of the providers can be installed
  - problem with installed package deja-dup-42.2-1.fc32.x86_64
  - package python3-PyDrive-1.3.1-13.fc33.noarch requires 
python3.9dist(google-api-python-client) >= 1.2, but none of the providers can 
be installed
  - python3-pyyaml-5.3.1-1.fc32.x86_64 does not belong to a distupgrade 
repository
  - deja-dup-42.2-1.fc32.x86_64 does not belong to a distupgrade repository
  - nothing provides python3-google-api-core >= 1.18.0 needed by 
python3-google-api-client-1:1.10.0-2.fc33.noarch
(try to add '--skip-broken' to skip uninstallable packages)
[root@puchatek ~]# 
___
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-20200913.n.0 compose check report

2020-09-13 Thread Fedora compose checker
No missing expected images.

Compose FAILS proposed Rawhide gating check!
3 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 18/181 (x86_64)

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

ID: 663986  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/663986
ID: 663987  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/663987
ID: 663990  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/663990
ID: 663991  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/663991
ID: 663992  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/663992
ID: 663993  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/663993
ID: 663994  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/663994
ID: 664021  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/664021
ID: 664036  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/664036
ID: 664066  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/664066
ID: 664076  Test: x86_64 universal install_blivet_resize_lvm
URL: https://openqa.fedoraproject.org/tests/664076
ID: 664087  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/664087
ID: 664109  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/664109
ID: 664128  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/664128

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

ID: 664003  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/664003
ID: 664005  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/664005
ID: 664032  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/664032
ID: 664101  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/664101

Soft failed openQA tests: 5/181 (x86_64)
(Tests completed, but using a workaround for a known bug)

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

ID: 664039  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/664039

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

ID: 663957  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/663957
ID: 663976  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/663976
ID: 664016  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/664016
ID: 664053  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/664053

Passed openQA tests: 149/181 (x86_64)

Skipped non-gating openQA tests: 9 of 181

Installed system changes in test x86_64 Everything-boot-iso install_default: 
System load changed from 0.21 to 0.07
Previous test data: https://openqa.fedoraproject.org/tests/662178#downloads
Current test data: https://openqa.fedoraproject.org/tests/663997#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
Used swap changed from 15 MiB to 21 MiB
System load changed from 0.44 to 0.33
Previous test data: https://openqa.fedoraproject.org/tests/662183#downloads
Current test data: https://openqa.fedoraproject.org/tests/664002#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
Used mem changed from 788 MiB to 905 MiB
Used swap changed from 1 MiB to 9 MiB
System load changed from 1.41 to 1.17
Previous test data: https://openqa.fedoraproject.org/tests/662200#downloads
Current test data: https://openqa.fedoraproject.org/tests/664019#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
Used mem changed from 729 MiB to 917 MiB
Used swap changed from 0 MiB to 12 MiB
System load changed from 0.97 to 1.17
Previous test data: https://openqa.fedoraproject.org/tests/662201#downloads
Current test data: https://openqa.fedoraproject.org/tests/664020#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
Used mem changed from 807 MiB to 951 MiB
System load changed from 1.02 to 1.24
Previou

Fedora rawhide compose report: 20200913.n.0 changes

2020-09-13 Thread Fedora Rawhide Report
OLD: Fedora-Rawhide-20200911.n.0
NEW: Fedora-Rawhide-20200913.n.0

= SUMMARY =
Added images:6
Dropped images:  1
Added packages:  21
Dropped packages:6
Upgraded packages:   274
Downgraded packages: 1

Size of added packages:  9.48 MiB
Size of dropped packages:85.71 KiB
Size of upgraded packages:   10.24 GiB
Size of downgraded packages: 147.06 KiB

Size change of upgraded packages:   24.30 MiB
Size change of downgraded packages: -1023 B

= ADDED IMAGES =
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20200913.n.0.iso
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20200913.n.0.x86_64.vagrant-virtualbox.box
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20200913.n.0.x86_64.vagrant-libvirt.box
Image: Comp_Neuro live x86_64
Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20200913.n.0.iso
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20200913.n.0.iso
Image: Python_Classroom live x86_64
Path: 
Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20200913.n.0.iso

= DROPPED IMAGES =
Image: Games live x86_64
Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20200911.n.0.iso

= ADDED PACKAGES =
Package: R-bench-1.1.1-1.fc34~bootstrap
Summary: High Precision Timing of R Expressions
RPMs:R-bench
Size:1.66 MiB

Package: R-brio-1.1.0-1.fc34
Summary: Basic R Input Output
RPMs:R-brio
Size:208.22 KiB

Package: R-downlit-0.1.0-1.fc34
Summary: Syntax Highlighting and Automatic Linking
RPMs:R-downlit
Size:99.27 KiB

Package: R-lobstr-1.1.1-1.fc34
Summary: Visualize R Data Structures with Trees
RPMs:R-lobstr
Size:672.86 KiB

Package: dbus-parsec-0.2.0-1.fc34
Summary: DBus PARSEC interface
RPMs:dbus-parsec
Size:1.05 MiB

Package: ghc-git-lfs-1.1.0-1.fc34
Summary: Git-lfs protocol
RPMs:ghc-git-lfs ghc-git-lfs-devel ghc-git-lfs-doc ghc-git-lfs-prof
Size:4.39 MiB

Package: ghc-http-client-restricted-0.0.3-1.fc34
Summary: Restricting the servers that http-client will use
RPMs:ghc-http-client-restricted ghc-http-client-restricted-devel 
ghc-http-client-restricted-doc ghc-http-client-restricted-prof
Size:588.15 KiB

Package: jpcre2-10.32.01-1.fc34
Summary: C++ wrapper for PCRE2 library
RPMs:jpcre2-devel
Size:54.06 KiB

Package: python-aioiotprov-0.0.7-1.fc34
Summary: Library/utility to help provision various IoT devices
RPMs:python3-aioiotprov
Size:38.07 KiB

Package: python-aresponses-2.0.0-1.fc34
Summary: Asyncio testing server
RPMs:python3-aresponses
Size:21.63 KiB

Package: python-hikvision-2.0.3-1.fc34
Summary: Python interface to interact with a Hikvision camera
RPMs:python3-hikvision
Size:19.41 KiB

Package: python-pyiqvia-0.3.0-1.fc34
Summary: Python API for IQVIA data
RPMs:python3-pyiqvia
Size:17.78 KiB

Package: python-thingserver-0.2.1-1.fc34
Summary: HTTP Web Thing implementation
RPMs:python3-thingserver
Size:45.14 KiB

Package: python-typish-1.7.0-2.fc34
Summary: Python library for additional control over types
RPMs:python3-typish
Size:47.62 KiB

Package: revelation-0.5.2-3.fc34
Summary: A password manager for the GNOME desktop
RPMs:revelation
Size:326.27 KiB

Package: rust-aead-0.3.2-1.fc34
Summary: Traits for Authenticated Encryption with Associated Data (AEAD) 
algorithms
RPMs:rust-aead+alloc-devel rust-aead+blobby-devel rust-aead+default-devel 
rust-aead+dev-devel rust-aead+heapless-devel rust-aead+std-devel rust-aead-devel
Size:62.12 KiB

Package: rust-oid-0.2.0-1.fc34
Summary: Rust-native library for building, parsing, and formating Object 
Identifiers (OIDs)
RPMs:rust-oid+default-devel rust-oid+serde-devel 
rust-oid+serde_support-devel rust-oid+std-devel rust-oid+u32-devel 
rust-oid-devel
Size:48.51 KiB

Package: rust-parsec-client-0.9.0-2.fc34
Summary: Parsec Client library for the Rust ecosystem
RPMs:rust-parsec-client+default-devel 
rust-parsec-client+no-fs-permission-check-devel 
rust-parsec-client+testing-devel rust-parsec-client-devel
Size:51.14 KiB

Package: rust-parsec-interface-0.20.2-2.fc34
Summary: Parsec interface library to communicate using the wire protocol
RPMs:rust-parsec-interface+arbitrary-devel 
rust-parsec-interface+default-devel rust-parsec-interface+fuzz-devel 
rust-parsec-interface+testing-devel rust-parsec-interface-devel
Size:92.81 KiB

Package: rust-universal-hash-0.4.0-1.fc34
Summary: Trait for universal hash functions
RPMs:rust-universal-hash+default-devel rust-universal-hash+std-devel 
rust-universal-hash-devel
Size:30.93 KiB

Package: rust-version-3.0.0-1.fc34
Summary: Very simple library who's job is to return the version of your crate 
if you're building with Cargo
RPMs:rust-version+def

Fedora-Cloud-31-20200913.0 compose check report

2020-09-13 Thread Fedora compose checker
No missing expected images.

Passed openQA tests: 7/7 (x86_64)
-- 
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: Looking for new Python package maintainers

2020-09-13 Thread Andy Mender
On Sat, 12 Sep 2020 at 12:16, Dhanesh B. Sabane 
wrote:

> Hey Andy!
>
> > On Mon, 7 Sep 2020 at 07:44, Dhanesh B. Sabane  >
> > wrote:
> >
> > If there are no takers, I'd like to maintain the python-blindspinner
> > package. I see there is some room to bring in its "click" dependencies.
>
> I've provided you admin access on python-blindspinner. Thank you so much
> for taking it up! :)
>
> Cheers!
>
>
Cheers! I already started working on it!
___
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-32-20200913.0 compose check report

2020-09-13 Thread Fedora compose checker
No missing expected images.

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

ID: 663954  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/663954

Passed openQA tests: 6/7 (x86_64)
-- 
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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

2020-09-13 Thread Benjamin Berg
On Sat, 2020-09-12 at 20:53 +, Alexey Avramov wrote:
> > how much memory that amounts to in the usual scenarios
> 
> 700M on F32 without any apps started.

That seems like quite a lot. I mean, we get into a similar region of
memory that EarlyOOM would be protecting with no apps started. So with
applications started, you might get higher.

> Largest file: (207.9M) /usr/lib/locale/locale-archive
> 
> Files list with its sizes: https://pastebin.com/Hpr6D3Sv
> 
> Locking even 250M-300M takes good effect. For example, demo: 
> https://www.youtube.com/watch?v=vykUrP1UvcI - no freezes with
> prelockd and freeze without prelockd

Was that with or without swap? For GNOME some executable code is JITed
javascript and we really need to protect that somehow.

250-300MiB sounds fine to me, though I do wonder how much of that is
really not needed often (e.g. library code only used at startup).

In general, I really prefer the cgroups approach taken with uresourced.
prelockd is a cool experiment and it proves that executable code being
reclaimed and refaulted is a major cause of latency.
But I feel that uresourced is just nicer conceptually. i.e. we first
segment the system into various parts, which is really simple to do
with systemd (everyone is already moving to systemd). And then we
simply ask the kernel for memory and other guarantees for important
parts of the system.

Unfortunately, while KDE is very close to using systemd for login, I
don't think it is ready yet (at least not on F33). So uresourced is
going to be ineffective for KDE for the time being.

On my F32 with a fixed uresourced[1] and increasing memory protection
to 350MiB, my GNOME session only has really minor hangs and only the
first time I do the tail /dev/zero test. This is with swap on an SSD
and EarlyOOM stopped.

Benjamin

[1] Right now there are two small issues that I will fix once beta
freeze is lifted:
 - Memory protection is ineffective due to a systemd bug which prevents
   my workaround for another issue from working …
 - MemoryMin needs to be used for OOM scenarios (rather than MemoryLow)
I'll leave the protected area at 250MiB though as that matches the
initial change request.


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


Re: Looking for new Python package maintainers

2020-09-13 Thread Dhanesh B. Sabane
Hello Michel,

On Sat, 2020-09-12 at 08:33 -0700, Michel Alexandre Salim wrote:
> 
> Thanks Dhanesh! I already have an update in testing for F33's Lua
> 5.4.
> 

Perfect! Take good care of the package while I'm gone. ;)

> 
> Great to hear! I've been in the same situation before. We are all
> volunteers (well, mostly) so of course it's fine if other things in
> life takes a priority.
> 
> You're probably already in the ambassadors and join groups?
> 

I'm already a part of Fedora Join group and have helped out there
before. Will try to continue my activity there. I'm not a part of the
ambassadors group though.

-- 
Dhanesh B. Sabane
https://dhanesh95.gitlab.io
PGP ID: 0xB69A98C9C1642329
Fingerprint: 9655 11F2 0D18 E76A 2396 D64D B69A 98C9 C164 2329
___
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