date:20200908

[Bug 1876925] perl-PPIx-Regexp-0.074 is available

2020-09-08 Thread bugzilla

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org

[EPEL-devel] proposal: EPEL 8 Next

2020-09-08 Thread Carl George

Howdy folks,

A large part of my day job is working on CentOS Stream.  Naturally I would
like it to be successful and have wide adoption.  I know that EPEL will play
a big role in this success.  EPEL is extremely popular.  Many users consider
RHEL and CentOS unusable without it.

The problem we are facing is that EPEL 8 cannot be 100% compatible with
RHEL/CentOS 8 and CentOS 8 Stream at the same time.  It is not uncommon for
RHEL to ship library soname changes in minor releases.  In the RHEL 8 cycle,
those changes are showing up in CentOS 8 Stream first.  EPEL 8 builds
against the latest RHEL 8 release.  This can result in EPEL 8 packages that
are uninstallable on CentOS 8 Stream due to the library differences.  One
prominent example we have already seen is llvm-libs, which has increased its
library soname in every RHEL 8 minor release so far.  Another increase is
planned for RHEL 8.3, which has already been released in CentOS 8 Stream.
There are likely other incompatibilities that haven't been noticed yet.  I
expect this problem to grow worse as RHEL development continues and more
packages are added to EPEL 8.  This situation is hurting the adoption of
CentOS Stream.

To solve this problem, I am proposing that we create a new repository called
EPEL 8 Next.

- built against CentOS 8 Stream
- opt-in for packagers (must request epel8-next dist-git branch)
- opt-in for users (part of epel-release but disabled by default)
- used *with* epel8, not *instead of*

This will provide EPEL packagers a place where they can update their
packages when necessary to be compatible with CentOS 8 Stream.  These
packages would also be useful for RHEL 8 users during the gap between a RHEL
minor release and the equivalent CentOS 8 Linux rebuild.  In theory this
repository should also be directly consumable by RHEL 8 Beta releases.
Similar to RHEL itself, breaking changes could be permitted in epel8-next in
preparation for delivering them to epel8 around the time of the next RHEL
minor release.

This proposal may sound similar to epel8-playground.  However, that was
still built against RHEL 8, so it didn't solve the compatibility issue with
CentOS 8 Stream.  This proposal does draw on lessons learned from the
playground experiment.

- no automatic builds via packages.cfg
- opt-in rather than opt-out
- layering on top of epel8, rather than duplicating content

I first suggested this idea at the last EPEL Steering Committee meeting, and
we plan to discuss it again during the next one.  Please share your thoughts
on this proposal.

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

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

2020-09-08 Thread Tom Seewald

Has anyone compiled a (non-exhaustive) list of known issues that are specific 
to KDE Plasma with Wayland? Are there currently any issues that would  block 
Wayland from becoming the default if they aren't resolved in time for F34?
___
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

Release rpkg-1.61 and fedpkg-1.39

2020-09-08 Thread Ondrej Nosek

Hi all,

a new version rpkg-1.61 together with fedpkg-1.39 are released containing
both features and bugfixes. Some bugfixes were released earlier as patches.
Currently, Fedora 32, epel7, epel8 and rawhide packages are in the testing
repository, feel free to try these waiting distributions in Bodhi. I will
update Fedora 33 and Fedora 31 packages later today because previous
updates are going to stable very soon and I do not want to obsolete them
now.
Version for epel6 won't be released.

Changelog (web documentation):
https://docs.pagure.org/rpkg/releases/1.61.html
https://docs.pagure.org/fedpkg/releases/1.39.html

Updates:
https://bodhi.fedoraproject.org/updates/?builds=rpkg-1.61-1.el8=rpkg-1.61-1.el7=rpkg-1.61-1.fc31=rpkg-1.61-1.fc32=rpkg-1.61-1.fc33=rpkg-1.61-1.fc34=fedpkg-1.39-1.fc34

Alternative link:
https://bodhi.fedoraproject.org/updates/?packages=rpkg=1

rpkg is also available from PyPI.

Thanks to all contributors.

Regards
___
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-08 Thread Erich Eickmeyer


Hi all

On Tue, Sep 8, 2020 at 08:56, Erich Eickmeyer 
 wrote:

Hi Ben,

On 9/8/2020 8:28 AM, Ben Cotton wrote:
 



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

== Feedback ==

 Is Wayland ready? 
Wayland has been used by default for Fedora Workstation (which uses
GNOME) since Fedora 25. And while it was somewhat immature initially,
today it is a very rock-solid experience on virtually everything
Fedora Workstation runs on. The change in Fedora 25 kickstarted the
drive to get everything working on Wayland, and the Workstation team
succeeded beyond their wildest dreams. Firefox has been 
Wayland-native

by default since Fedora 31 as well.

On the KDE side, serious work into supporting Wayland started shortly
after GNOME switched to Wayland by default. Unlike GNOME, KDE has a
much broader stack in its toolkit, and it has taken longer to get to 
a

usable state. With the Plasma 5.20 release, the Wayland protocol for
screencasting as well as middle-click paste finally are supported,
completing the required feature set for switching to Wayland by
default.

 What about NVIDIA? 
Plasma, in fact, ''does'' support NVIDIA GPUs with the proprietary
driver on Wayland. It needs to be manually activated, which will be
taken care of by the kwin-wayland-nvidia package. So the
expectation is that all major GPUs will work just fine.

 Why not keep using X11? 
The fact of the matter is, Xorg is in
[
"hard maintenance mode"] per [[User:Uraeus|Christian Schaller]] and
development on it has basically stopped beyond the most critical of
fixes. Combined with the rapid maturation of the Wayland session in
KDE Plasma, this is the best time to make the switch and push things
over the edge for the KDE ecosystem in the same way that Fedora
Workstation did for the GNOME ecosystem.

== Benefit to Fedora ==
Fedora has long been a leader in advancing the adoption of the 
Wayland

protocol as part of the overall strategy to improve the Linux
graphical software stack. Much of the quality of Wayland for GNOME 
can
be attributed to the work done by the Fedora Workstation WG as part 
of

advancing the GNOME platform. It is now the KDE SIG's turn to do the
same for the KDE platform. By making this change, we are helping push
the adoption forward for newer, more streamlined, and overall more
actively developed graphics technology for the KDE ecosystem.

== Scope ==
* Proposal owners:
** Modify {{package|kwin}} to switch to Wayland
*** Split out /usr/bin/kwin_x11 to the
kwin-x11 subpackage.
*** Make {{package|kwin}} require kwin-wayland and
recommend kwin-x11
*** Add kwin-wayland-nvidia subpackage which contains
/usr/lib/environment.d/10-kwin-wayland-nvidia.conf to 
set
$KWIN_DRM_USE_EGL_STREAMS to 1. This 
package

will have have a Supplements dependency (kwin-wayland and
kmod-nvidia).
** Modify {{package|plasma-workspace}} to switch to Wayland
*** Rename /usr/share/xsessions/plasma.desktop to
/usr/share/xsessions/plasma-xorg.desktop, subpackage it
out as plasma-workspace-xorg, and have it require
kwin-x11
*** Rename 
/usr/share/wayland-sessions/plasmawayland.desktop

to /usr/share/wayland-sessions/plasma.desktop
*** Make {{package|plasma-workspace}} require
plasma-workspace-wayland and recommend
plasma-workspace-xorg
** Modify @kde-desktop comps group for Fedora 34 to
include plasma-workspace-xorg for the media.

* Other developers: N/A (not applicable for this Change)
* Release engineering: [ #9741]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A (not applicable for this Change)

== Upgrade/compatibility impact ==
Systems using certain (very old) graphics hardware or graphics 
drivers
(matrox, etc.) may have problems running

[389-devel] Re: 389-ds Migration to GitHub - [2020-09-12 - 2020-09-13]

2020-09-08 Thread William Brown



> On 9 Sep 2020, at 04:21, Simon Pichugin  wrote:
> 
> Hi team,
> for the last couple of weeks, I was working on the migration tool that will 
> allow us to switch 389-ds project to GitHub.
> 
> It will be done through the weekend 2020-09-12 - 2020-09-13.
> 
> I was testing it on a custom repo for some time but, please, review the code, 
> if you would like to:
> https://github.com/droideck/patogith/
> 
> I will open the example 389-ds-base [migrated] repo tomorrow when my final 
> run will finish.

Great, please post a link when done, I'd be happy to look through it. 

> 
> I've managed to disable Github notifications but there are two more things 
> that should be taken into the account:
> 
> 1. Pagure notifications - as Viktor has suggested, probably, we can ask 
> Pierre-Yves Chibon  to do this for us at Friday.
> 
> 2. Bugzilla notifications. It may be that it's not possible to disable it for 
> everyone involved. In that case, it will be one time thing that will spam you 
> with 3000 emails. :) But I hope not.

I love emails!


In general though, great work here Simon. This is a really huge task, so thanks 
for undertaking it. 


—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/389-devel@lists.fedoraproject.org

The Future of the Java Stack (also regarding ELN and RHEL)

2020-09-08 Thread Fabio Valentini

Hi everybody,

So, after some recent FESCo decisions (no default module streams in
fedora, new Module Policy for fedora and ELN modules), it's time to
ask this question again:

What's the future of the Java Stack in fedora, and by extension, in
ELN (and possibly RHEL)?

For the past ~18 months, the Stewardship SIG has picked up the pieces
that were left after the failed attempt of "modularizing" the Java
stack, and now the "re-founded" Java SIG has taken over this effort.
We've been maintaining the core part of the Java stack (about 200
packages) - first trying to keep it from imploding, and lately, trying
to keep it working and up-to-date (also, Java 11 by default, yay).

However! This has mostly been a one-man-show, with regular
contributions by Mat Booth (whos thankless task is maintaining the
Eclipse stack) and the Dogtag PKI team (thanks guys!), who have lately
been busy doing other things (fixing blocker bugs for F33 and RHEL
8.3).

Looking at the Java packages I own, most of them also wind up in ELN,
so I assume that they're going to end up in RHEL at some point. And
here I'm asking myself the question: Who's going to maintain those 200
Java packages? Because I have seen *zero* people from Red Hat
interacting with the Java stack in fedora in any substantial way in
the past year - and by that I mean more than one commit to a package
they didn't own or sending one PR on src.fp.org.

While working through the *massive* backlog of issues and neglected
package updates in the Java stack, I also went through with multiple
non-responsive maintainer processes, and almost nobody from the
original people who maintained Java packages in fedora are left. Some
of those were Red Hat employees, but are apparently no longer, or have
moved on to work on different things.

Not even the Java modules (javapackages-tools, maven, ant, ...) seem
to be in better shape - none of them have been touched in the last 10
months, except for automated mass rebuild commits. They are now pretty
out of sync with mainstream fedora, and they still only target the
"oldstable" fedora 31 platform. Since javapackages-tools:20190x and
maven:3.5 are also no longer default streams, they are unused (?), and
seem to have been abandoned.

So. Who is actually maintaining the Java stack in RHEL? I can't tell.
Who is maintaining the core build tools (xmvn, maven, ant, etc.)? Why
are they not - or no longer - contributing to fedora packages or
interacting with fedora maintainers? Does Red Hat no longer care about
all their Java products [1]? Can we please increase the bus / lottery
factor (= 1) for Java package maintenance in fedora?

Fabio / decathorpe

PS: I'm not talking about the JDK packages here. They're in good
hands, as far as I can tell.

[1]: JBoss / WildFly were among the first things to be retired during
the modularity calamity, because nobody cared. But what about the
shiny new thing, Quarkus? Will it ever be packaged for fedora?
___
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-08 Thread Michel Alexandre Salim

Hi Dhanesh,

On Mon, 2020-09-07 at 11:13 +0530, Dhanesh B. Sabane wrote:
> Hello folks!
> 
> I've been away from all Fedora activities for quite some time and I
> don't see a return anytime soon. There are 6 Python packages which
> are
> maintained by me and I'd like to hand them over. Following is the
> list
> of packages:
> 
> https://src.fedoraproject.org/user/dhanesh95/projects
> 
I'll take python-lupa

Thanks for your work over the years, and hope you at least remain a
user,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2


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: noarch packages only for some architecture composes

2020-09-08 Thread Michel Alexandre Salim

On Mon, 2020-09-07 at 13:15 +0200, Fabio Valentini wrote:
> On Mon, Sep 7, 2020 at 1:02 PM Florian Weimer 
> wrote:
> > Is it possible to include a noarch package only in some of the
> > composes?
> > 
...
> I don't think this is possible, and since I consider this to be a
> bug,
> I reported this a while ago:
> 
> koji#1843: noarch packages getting copied to repos explicitly
> excluded
> in ExclusiveArch
> https://pagure.io/koji/issue/1843
> 
Huh, yeah, this seems to contradict what the packaging guidelines say:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_arch_specific_runtime_and_build_time_dependencies

I accidentally am relying on this bug for emacs-slime: it is noarch and
should work on all platforms, but the tests currently rely on SBCL so I
added an exclusivearch matching SBCL's (to prevent build-time roulette
of builds failing if the wrong arch is picked).

If this bug is fixed, we'd then have no solution for this "package
should work the same everywhere, but can only be tested on some
platforms"... (I doubt it affects many packages though)

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2


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

2020-09-08 Thread Matthew Miller

On Tue, Sep 08, 2020 at 01:35:11PM -0700, stan via devel wrote:
> Does it now have support for custom keymappings?  That is, does it have
> a way to set a user keymap as the default? X has a very mature system
> for setting this, so I can have my custom keymapping everywhere except
> in editing the grub menu.  I've thought about buying a programmable
> ergonomic keyboard so this would no longer be an issue, but my current
> setup works.  Will it now work in Wayland?

It probably will not. Everything related to this is different, and there's
nothing as easy or as nice. You will probably want to select the X session
rather than the proposed new default.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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-08 Thread stan via devel

On Tue, 8 Sep 2020 11:28:20 -0400
Ben Cotton  wrote:

>  Is Wayland ready? 
> Wayland has been used by default for Fedora Workstation (which uses
> GNOME) since Fedora 25. And while it was somewhat immature initially,
> today it is a very rock-solid experience on virtually everything
> Fedora Workstation runs on.

Does it now have support for custom keymappings?  That is, does it have
a way to set a user keymap as the default? X has a very mature system
for setting this, so I can have my custom keymapping everywhere except
in editing the grub menu.  I've thought about buying a programmable
ergonomic keyboard so this would no longer be an issue, but my current
setup works.  Will it now work in Wayland?

Does it allow booting from multiuser?  Is there something equivalent to
startx so I can start it on the virtual console of my choice?

Or are these obsolete concepts in Wayland?
___
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

[EPEL-devel] Re: kde-connect has incorrect dependencies (Centos 8 Stream)

2020-09-08 Thread Troy Dawson

Thank you.
Looks like the kirigami2 stuff isn't just an EPEL problem, same thing
happens in the latest Fedora Rawhide.
I'm filing a bug and getting the kirigami2 stuff fixed.
As for why your phone isn't seen, I don't know.  I don't use
kdeconnect.  You might get more help with that on the fedora kde
mailing list.

On Tue, Sep 8, 2020 at 11:58 AM Jason Oppel  wrote:
>
> "kde-connect" is the name of the package that has the missing dependencies. 
> kdeconnect-app is the name of the application you can run to get the errors I 
> described earlier in the thread. Thank you for following up!
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://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/epel-devel@lists.fedoraproject.org
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: kde-connect has incorrect dependencies (Centos 8 Stream)

2020-09-08 Thread Jason Oppel

"kde-connect" is the name of the package that has the missing dependencies. 
kdeconnect-app is the name of the application you can run to get the errors I 
described earlier in the thread. Thank you for following up!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/epel-devel@lists.fedoraproject.org

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

2020-09-08 Thread Neal Gompa

On Tue, Sep 8, 2020 at 12:57 PM Silvia Sánchez  wrote:
>
> Yes, I don't see KDE Wayland sufficiently mature to actually work as a 
> default.  It needs more work and testing.
>
> On Tue, 8 Sep 2020 at 18:33, Robert-André Mauchin  wrote:
>>
>> Please no, KWin Wayland makes my system crash as soon as I connect my second
>> screen, and does not support essential functions like Kwin scripting, make
>> Yakuake look terrible and the whole stuff feels buggy as hell.
>> Every time I used it thes past years, it felt buggy and in an unfinished
>> state, it was like being the tester of an alpha version.
>>

A lot of work has gone into solidifying the experience upstream, and
I'm currently running Plasma 5.18.5 on F32 (on Intel GPU system) and
Plasma 5.19.5 on F33 (on NVIDIA GPU system) and things are working
pretty well so far. The plan is to do the switch in Rawhide early and
work with KDE upstream to knock out the remaining issues to offer a
solid experience with the Plasma release we ship with Fedora 34 GA.
Based on the timelines, we're probably looking at 5.22 for F34 GA, but
I want to make the switch as part of importing the 5.20 beta next week
and give feedback ASAP.

The problem with the current situation is that if we *don't* do this,
there's no pressure to push things forward upstream and get everything
*working*. Doing this will force focus and priority to get everything
working. This strategy was employed to get GNOME Wayland in good shape
and we're in a better place now than GNOME was when the switch was
made in Fedora 25.

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

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

2020-09-08 Thread James Cassell



On Tue, Sep 8, 2020, at 11:28 AM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
> 
> == Summary ==
> Remove support for SELinux runtime disable so that the LSM hooks can
> be hardened via read-only-after-initialization protections.
> 
> Migrate users to using ''selinux=0'' if they want to disable SELinux.
> 

I like the proposal. A few thoughts and questions, though:

1. I think systems with SELINUX=disabled without selinux=0 should hard fail 
very loudly. I've found certain real-time use cases require SELinux to be 
disabled to meet the real time guarantees. (Permissive doesn't help because 
it's a timing issue, not permission issue.)

2. Does this affect resetting the root password with init=/bin/bash and using 
`/sbin/load_policy -i` to avoid a relabel?

3. Generally, forcing things to be cmdline options would benefit from a generic 
way to configure and manage them, such as using drop-in snippets. Ideally this 
would work the same way across BIOS and UEFI systems. It's difficult to 
programmatically manipulate GRUB_CMDLINE_LINUX, which is the current standard 
configuration method.

Thanks for putting the security-enhancing proposal forward!

V/r,
James Cassell


> == Owner ==
> * Name: [[User:plautrba| Petr Lautrbach]]
> * Email: plaut...@redhat.com
> * Name: [[User:omos| Ondrej Mosnacek]]
> * Email: omosn...@redhat.com
> 
> 
> == Detailed Description ==
> Support for SELinux runtime disable via ''/etc/selinux/config'' was
> originally developed to make it easier for Linux distributions to
> support architectures where adding parameters to the kernel command
> line was difficult.
> Unfortunately, supporting runtime disable meant we had to make some
> security trade-offs when it comes to the kernel LSM hooks.
> 
> Marking the kernel LSM hooks as read only provides some very nice
> security benefits, but it does mean that we can no longer disable
> SELinux at runtime.
> Toggling between enforcing and permissive mode while booted will
> remain unaffected and it will still be possible to disable SELinux by
> adding ''selinux=0'' to the kernel command line via the boot loader
> (GRUB).
> 
> System with ''SELINUX=disabled'' in ''/etc/selinux/config'' will come
> up with ''/sys/fs/selinuxfs'' unmounted,
> userspace will detect SELinux as disabled. Internally SELinux will be
> enabled but not initialized so that there will be no SELinux checks
> applied.
> 
> NOTE: Runtime disable is considered deprecated by upstream, and using
> it will become increasingly painful (e.g. sleeping/blocking) through
> future kernel releases until eventually it is removed completely.
> Current kernel reports the following message during runtime disable:
> ''SELinux:  Runtime disable is deprecated, use selinux=0 on the kernel
> cmdline''
> 
> Additional info:
> 
> * https://lwn.net/Articles/666550
> * 
> https://lore.kernel.org/selinux/159110207843.57260.5661475689740939480.stgit@chester/
> * 
> https://lore.kernel.org/selinux/157836784986.560897.13893922675143903084.stgit@chester/#t
> 
> == Benefit to Fedora ==
> Marking the LSM hooks as read-only provides extra security hardening
> against certain attacks, e.g. in case an attacker gains ability to
> write to random kernel memory locations, with support for disable
> SELinux runtime (''CONFIG_SECURITY_SELINUX_DISABLE=y'') they have a
> bigger chance to turn off (parts of) SELinux permission checking.
> 
> == Scope ==
> * Proposal owners:
> ** Make sure the kernel is built with
> ''CONFIG_SECURITY_SELINUX_DISABLE'' disabled.
> ** Make sure the relevant documentation is updated in a way that
> ''selinux=0'' on kernel command line is the preferred way to disable
> SELinux.
> *** 
> https://docs.fedoraproject.org/en-US/quick-docs/changing-selinux-states-and-modes/
> *** ''selinux(8)'' man page
> ** Make sure [https://github.com/rhinstaller/anaconda/ the installer]
> uses the kernel command line instead of ''/etc/selinux/config'' to
> disable SELinux.
> ** Optional: 
> [https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/facts/system/selinux.py
> ''selinux'' Ansible module] should warn that SELinux needs to be
> disabled using ''selinux=0''.
> ** Optional: [https://github.com/linux-system-roles/selinux
> linux-system-roles.selinux] should disable SELinux using
> ''selinux=0''.
> 
> * Other developers: N/A
> * Release engineering: https://pagure.io/releng/issue/9742
> * Policies and guidelines: N/A
> * Trademark approval: N/A (not needed for this Change)
> 
> 
> == Upgrade/compatibility impact ==
> Users should not be directly affected by this change.
> 
> == How To Test ==
> # Install a kernel built with ''CONFIG_SECURITY_SELINUX_DISABLE''
> disabled, e.g. from
> https://copr.fedorainfracloud.org/coprs/omos/drop-selinux-disable/.
> # Confirm that SELinux is disabled when ''selinux=0'' is used on
> kernel command line.
> # Confirm that userspace considers SELinux disabled when
> ''SELINUX=disabled'' is used

[389-devel] 389-ds Migration to GitHub - [2020-09-12 - 2020-09-13]

2020-09-08 Thread Simon Pichugin

Hi team,
for the last couple of weeks, I was working on the migration tool that will
allow us to switch 389-ds project to GitHub.

It will be done through the weekend 2020-09-12 - 2020-09-13.

I was testing it on a custom repo for some time but, please, review the
code, if you would like to:
https://github.com/droideck/patogith/

I will open the example 389-ds-base [migrated] repo tomorrow when my final
run will finish.

I've managed to disable Github notifications but there are two more things
that should be taken into the account:

1. Pagure notifications - as Viktor has suggested, probably, we can ask
Pierre-Yves Chibon  to do this for us at Friday.

2. Bugzilla notifications. It may be that it's not possible to disable it
for everyone involved. In that case, it will be one time thing that will
spam you with 3000 emails. :) But I hope not.

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

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

2020-09-08 Thread Silvia Sánchez

Yes, I don't see KDE Wayland sufficiently mature to actually work as a
default.  It needs more work and testing.




On Tue, 8 Sep 2020 at 18:33, Robert-André Mauchin  wrote:

> On Tuesday, 8 September 2020 17:28:20 CEST 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.
> >
> > == Feedback ==
> >
> >  Is Wayland ready? 
> > Wayland has been used by default for Fedora Workstation (which uses
> > GNOME) since Fedora 25. And while it was somewhat immature initially,
> > today it is a very rock-solid experience on virtually everything
> > Fedora Workstation runs on. The change in Fedora 25 kickstarted the
> > drive to get everything working on Wayland, and the Workstation team
> > succeeded beyond their wildest dreams. Firefox has been Wayland-native
> > by default since Fedora 31 as well.
> >
> > On the KDE side, serious work into supporting Wayland started shortly
> > after GNOME switched to Wayland by default. Unlike GNOME, KDE has a
> > much broader stack in its toolkit, and it has taken longer to get to a
> > usable state. With the Plasma 5.20 release, the Wayland protocol for
> > screencasting as well as middle-click paste finally are supported,
> > completing the required feature set for switching to Wayland by
> > default.
> >
> >  What about NVIDIA? 
> > Plasma, in fact, ''does'' support NVIDIA GPUs with the proprietary
> > driver on Wayland. It needs to be manually activated, which will be
> > taken care of by the kwin-wayland-nvidia package. So the
> > expectation is that all major GPUs will work just fine.
> >
> >  Why not keep using X11? 
> > The fact of the matter is, Xorg is in
> > [
> https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation
> > -31/
>  "hard maintenance mode"] per [[User:Uraeus|Christian Schaller]] and
> > development on it has basically stopped beyond the most critical of
> fixes.
> > Combined with the rapid maturation of the Wayland session in KDE Plasma,
> > this is the best time to make the switch and push things over the edge
> for
> > the KDE ecosystem in the same way that Fedora
> > Workstation did for the GNOME ecosystem.
> >
> > == Benefit to Fedora ==
> > Fedora has long been a leader in advancing the adoption of the Wayland
> > protocol as part of the overall strategy to improve the Linux
> > graphical software stack. Much of the quality of Wayland for GNOME can
> > be attributed to the work done by the Fedora Workstation WG as part of
> > advancing the GNOME platform. It is now the KDE SIG's turn to do the
> > same for the KDE platform. By making this change, we are helping push
> > the adoption forward for newer, more streamlined, and overall more
> > actively developed graphics technology for the KDE ecosystem.
> >
> > == Scope ==
> > * Proposal owners:
> > ** Modify {{package|kwin}} to switch to Wayland
> > *** Split out /usr/bin/kwin_x11 to the
> > kwin-x11 subpackage.
> > *** Make {{package|kwin}} require kwin-wayland and
> > recommend kwin-x11
> > *** Add kwin-wayland-nvidia subpackage which contains
> > /usr/lib/environment.d/10-kwin-wayland-nvidia.conf to set
> > $KWIN_DRM_USE_EGL_STREAMS to 1. This package
> > will have have a Supplements dependency (kwin-wayland and
> > kmod-nvidia).
> > ** Modify {{package|plasma-workspace}} to switch to Wayland
> > *** Rename /usr/share/xsessions/plasma.desktop to
> > /usr/share/xsessions/plasma-xorg.desktop, subpackage it
> > out as plasma-workspace-xorg, and have it require
> > kwin-x11
> > *** Rename /usr/share/wayland-sessions/plasmawayland.desktop
> > to /usr/share/wayland-sessions/plasma.desktop
> > *** Make {{package|plasma-workspace}} require
> > plasma-workspace-wayland and recommend
> > plasma-workspace-xorg
> > ** Modify @kde-desktop comps group for Fedora 34 to
> > include plasma-workspace-xorg for the media.
> >
> > * Other developers: N/A (not applicable for this Change)
> > * Release engineering: [https://pagure.io/releng/issue/9741

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

2020-09-08 Thread Robert-André Mauchin

On Tuesday, 8 September 2020 17:28:20 CEST 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.
> 
> == Feedback ==
> 
>  Is Wayland ready? 
> Wayland has been used by default for Fedora Workstation (which uses
> GNOME) since Fedora 25. And while it was somewhat immature initially,
> today it is a very rock-solid experience on virtually everything
> Fedora Workstation runs on. The change in Fedora 25 kickstarted the
> drive to get everything working on Wayland, and the Workstation team
> succeeded beyond their wildest dreams. Firefox has been Wayland-native
> by default since Fedora 31 as well.
> 
> On the KDE side, serious work into supporting Wayland started shortly
> after GNOME switched to Wayland by default. Unlike GNOME, KDE has a
> much broader stack in its toolkit, and it has taken longer to get to a
> usable state. With the Plasma 5.20 release, the Wayland protocol for
> screencasting as well as middle-click paste finally are supported,
> completing the required feature set for switching to Wayland by
> default.
> 
>  What about NVIDIA? 
> Plasma, in fact, ''does'' support NVIDIA GPUs with the proprietary
> driver on Wayland. It needs to be manually activated, which will be
> taken care of by the kwin-wayland-nvidia package. So the
> expectation is that all major GPUs will work just fine.
> 
>  Why not keep using X11? 
> The fact of the matter is, Xorg is in
> [https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation
> -31/
 "hard maintenance mode"] per [[User:Uraeus|Christian Schaller]] and
> development on it has basically stopped beyond the most critical of fixes.
> Combined with the rapid maturation of the Wayland session in KDE Plasma,
> this is the best time to make the switch and push things over the edge for
> the KDE ecosystem in the same way that Fedora
> Workstation did for the GNOME ecosystem.
> 
> == Benefit to Fedora ==
> Fedora has long been a leader in advancing the adoption of the Wayland
> protocol as part of the overall strategy to improve the Linux
> graphical software stack. Much of the quality of Wayland for GNOME can
> be attributed to the work done by the Fedora Workstation WG as part of
> advancing the GNOME platform. It is now the KDE SIG's turn to do the
> same for the KDE platform. By making this change, we are helping push
> the adoption forward for newer, more streamlined, and overall more
> actively developed graphics technology for the KDE ecosystem.
> 
> == Scope ==
> * Proposal owners:
> ** Modify {{package|kwin}} to switch to Wayland
> *** Split out /usr/bin/kwin_x11 to the
> kwin-x11 subpackage.
> *** Make {{package|kwin}} require kwin-wayland and
> recommend kwin-x11
> *** Add kwin-wayland-nvidia subpackage which contains
> /usr/lib/environment.d/10-kwin-wayland-nvidia.conf to set
> $KWIN_DRM_USE_EGL_STREAMS to 1. This package
> will have have a Supplements dependency (kwin-wayland and
> kmod-nvidia).
> ** Modify {{package|plasma-workspace}} to switch to Wayland
> *** Rename /usr/share/xsessions/plasma.desktop to
> /usr/share/xsessions/plasma-xorg.desktop, subpackage it
> out as plasma-workspace-xorg, and have it require
> kwin-x11
> *** Rename /usr/share/wayland-sessions/plasmawayland.desktop
> to /usr/share/wayland-sessions/plasma.desktop
> *** Make {{package|plasma-workspace}} require
> plasma-workspace-wayland and recommend
> plasma-workspace-xorg
> ** Modify @kde-desktop comps group for Fedora 34 to
> include plasma-workspace-xorg for the media.
> 
> * Other developers: N/A (not applicable for this Change)
> * Release engineering: [https://pagure.io/releng/issue/9741 #9741]
> * Policies and guidelines: N/A (not needed for this Change)
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives: N/A (not applicable for this Change)
> 
> == Upgrade/compatibility impact ==
> Systems using certain (very old) graphics hardware or graphics drivers
> (matrox, etc.) may have problems running the Wayland session. In

CPE Quarterly Feedback Survey Results

2020-09-08 Thread Ant Carroll

Hey folks,

I want to thank everyone that took the time to complete the survey for us.
Even more so for those of you that left comments to help give us extra info
and context, this is invaluable. The flip side is, it takes a little time
to work through and that's what we're doing right now.

A few pieces we can acknowledge off the bat though:

- Mediums of communication were overwhelmingly positive for weekly email
lists and blog posts. 76% for the emails and 46% for blog posts
respectively We're discussing how to improve these even further at the
moment as well as tweak the PO office hours and wind down the Taiga boards
as these were significantly less popular. 14% for the PO office hours and
1% for the Taiga boards.

- Transparency of decisions and communications. You want more of the former
and streamlining on the latter. We hear you and will aim to deliver this
alongside the first point above.

- Overall (82%+ reponses) you feel we did a good job since April of this
year. We appreciate the level of confidence you've shown in us and our
desire is to continuously improve this with your feedback.

Cheers,

Ant
-- 

Ant Carroll

Associate Manager, Software Engineering

Red Hat Waterford 

Communications House

Cork Road, Waterford City

ancar...@redhat.com
M: +353876213163 IM: ancarrol
@redhatjobs    redhatjobs
 @redhatjobs


___
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-08 Thread Neal Gompa

On Tue, Sep 8, 2020 at 11:56 AM Erich Eickmeyer
 wrote:
>
> Hi Ben,
>
> On 9/8/2020 8:28 AM, 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.
> >
> > == Feedback ==
> >
> >  Is Wayland ready? 
> > Wayland has been used by default for Fedora Workstation (which uses
> > GNOME) since Fedora 25. And while it was somewhat immature initially,
> > today it is a very rock-solid experience on virtually everything
> > Fedora Workstation runs on. The change in Fedora 25 kickstarted the
> > drive to get everything working on Wayland, and the Workstation team
> > succeeded beyond their wildest dreams. Firefox has been Wayland-native
> > by default since Fedora 31 as well.
> >
> > On the KDE side, serious work into supporting Wayland started shortly
> > after GNOME switched to Wayland by default. Unlike GNOME, KDE has a
> > much broader stack in its toolkit, and it has taken longer to get to a
> > usable state. With the Plasma 5.20 release, the Wayland protocol for
> > screencasting as well as middle-click paste finally are supported,
> > completing the required feature set for switching to Wayland by
> > default.
> >
> >  What about NVIDIA? 
> > Plasma, in fact, ''does'' support NVIDIA GPUs with the proprietary
> > driver on Wayland. It needs to be manually activated, which will be
> > taken care of by the kwin-wayland-nvidia package. So the
> > expectation is that all major GPUs will work just fine.
> >
> >  Why not keep using X11? 
> > The fact of the matter is, Xorg is in
> > [https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/
> > "hard maintenance mode"] per [[User:Uraeus|Christian Schaller]] and
> > development on it has basically stopped beyond the most critical of
> > fixes. Combined with the rapid maturation of the Wayland session in
> > KDE Plasma, this is the best time to make the switch and push things
> > over the edge for the KDE ecosystem in the same way that Fedora
> > Workstation did for the GNOME ecosystem.
> >
> > == Benefit to Fedora ==
> > Fedora has long been a leader in advancing the adoption of the Wayland
> > protocol as part of the overall strategy to improve the Linux
> > graphical software stack. Much of the quality of Wayland for GNOME can
> > be attributed to the work done by the Fedora Workstation WG as part of
> > advancing the GNOME platform. It is now the KDE SIG's turn to do the
> > same for the KDE platform. By making this change, we are helping push
> > the adoption forward for newer, more streamlined, and overall more
> > actively developed graphics technology for the KDE ecosystem.
> >
> > == Scope ==
> > * Proposal owners:
> > ** Modify {{package|kwin}} to switch to Wayland
> > *** Split out /usr/bin/kwin_x11 to the
> > kwin-x11 subpackage.
> > *** Make {{package|kwin}} require kwin-wayland and
> > recommend kwin-x11
> > *** Add kwin-wayland-nvidia subpackage which contains
> > /usr/lib/environment.d/10-kwin-wayland-nvidia.conf to set
> > $KWIN_DRM_USE_EGL_STREAMS to 1. This package
> > will have have a Supplements dependency (kwin-wayland and
> > kmod-nvidia).
> > ** Modify {{package|plasma-workspace}} to switch to Wayland
> > *** Rename /usr/share/xsessions/plasma.desktop to
> > /usr/share/xsessions/plasma-xorg.desktop, subpackage it
> > out as plasma-workspace-xorg, and have it require
> > kwin-x11
> > *** Rename /usr/share/wayland-sessions/plasmawayland.desktop
> > to /usr/share/wayland-sessions/plasma.desktop
> > *** Make {{package|plasma-workspace}} require
> > plasma-workspace-wayland and recommend
> > plasma-workspace-xorg
> > ** Modify @kde-desktop comps group for Fedora 34 to
> > include plasma-workspace-xorg for the media.
> >
> > * Other developers: N/A (not applicable for this Change)
> > * Release engineering: [https://pagure.io/releng/issue/9741 #9741]
> > * Policies and guidelines: N/A (not needed for this Change)
> > * Trademark approval: N/A (not needed for this Change)
> > *

[EPEL-devel] Re: kde-connect has incorrect dependencies (Centos 8 Stream)

2020-09-08 Thread Troy Dawson

On Tue, Sep 8, 2020 at 8:49 AM Jason Oppel  wrote:
>
> The kde-connect package is missing kf5-kirigami and kf5-kirigami2 as 
> dependencies.
>
> Steps to reproduce:
> Without KDE installed (running XFCE),  performing a "dnf install 
> kdeconnect-app". Everything installs just fine. However, when you try to 
> execute the kdeconnect-app, you receive the following errors:
>
> "QQmlApplicationEngine failed to load component
> qrc:/qml/main.qml:24 module "org.kde.kirigami" is not installed
> kf5-kirigami"
>
> The above error is corrected by doing "dnf install kf5-kirigami".
>
> After resolving that error another error pops up when trying to run the 
> kdeconnect-app.
> "QQmlApplicationEngine failed to load component
> qrc:/qml/main.qml:24 module "org.kde.kirigami" version 2.0 is not installed
> kf5-kirigami"
>
> The above error is corrected by doing "dnf install kf5-kirigami2". The app 
> now starts cleanly. That said, KDE Connect still doesn't see my phone for 
> some reason. I haven't figured out why that part of of the app isn't working 
> at the moment.
>
> Thanks,
> Jason

Where are you getting "kdeconnect-app" from?
When I do
  dnf install kdeconnect-app
I get
  No match for argument: kdeconnect-app

Are you meaning just kdeconnect ?

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

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

2020-09-08 Thread Erich Eickmeyer


Hi Ben,

On 9/8/2020 8:28 AM, 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.

== Feedback ==

 Is Wayland ready? 
Wayland has been used by default for Fedora Workstation (which uses
GNOME) since Fedora 25. And while it was somewhat immature initially,
today it is a very rock-solid experience on virtually everything
Fedora Workstation runs on. The change in Fedora 25 kickstarted the
drive to get everything working on Wayland, and the Workstation team
succeeded beyond their wildest dreams. Firefox has been Wayland-native
by default since Fedora 31 as well.

On the KDE side, serious work into supporting Wayland started shortly
after GNOME switched to Wayland by default. Unlike GNOME, KDE has a
much broader stack in its toolkit, and it has taken longer to get to a
usable state. With the Plasma 5.20 release, the Wayland protocol for
screencasting as well as middle-click paste finally are supported,
completing the required feature set for switching to Wayland by
default.

 What about NVIDIA? 
Plasma, in fact, ''does'' support NVIDIA GPUs with the proprietary
driver on Wayland. It needs to be manually activated, which will be
taken care of by the kwin-wayland-nvidia package. So the
expectation is that all major GPUs will work just fine.

 Why not keep using X11? 
The fact of the matter is, Xorg is in
[https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/
"hard maintenance mode"] per [[User:Uraeus|Christian Schaller]] and
development on it has basically stopped beyond the most critical of
fixes. Combined with the rapid maturation of the Wayland session in
KDE Plasma, this is the best time to make the switch and push things
over the edge for the KDE ecosystem in the same way that Fedora
Workstation did for the GNOME ecosystem.

== Benefit to Fedora ==
Fedora has long been a leader in advancing the adoption of the Wayland
protocol as part of the overall strategy to improve the Linux
graphical software stack. Much of the quality of Wayland for GNOME can
be attributed to the work done by the Fedora Workstation WG as part of
advancing the GNOME platform. It is now the KDE SIG's turn to do the
same for the KDE platform. By making this change, we are helping push
the adoption forward for newer, more streamlined, and overall more
actively developed graphics technology for the KDE ecosystem.

== Scope ==
* Proposal owners:
** Modify {{package|kwin}} to switch to Wayland
*** Split out /usr/bin/kwin_x11 to the
kwin-x11 subpackage.
*** Make {{package|kwin}} require kwin-wayland and
recommend kwin-x11
*** Add kwin-wayland-nvidia subpackage which contains
/usr/lib/environment.d/10-kwin-wayland-nvidia.conf to set
$KWIN_DRM_USE_EGL_STREAMS to 1. This package
will have have a Supplements dependency (kwin-wayland and
kmod-nvidia).
** Modify {{package|plasma-workspace}} to switch to Wayland
*** Rename /usr/share/xsessions/plasma.desktop to
/usr/share/xsessions/plasma-xorg.desktop, subpackage it
out as plasma-workspace-xorg, and have it require
kwin-x11
*** Rename /usr/share/wayland-sessions/plasmawayland.desktop
to /usr/share/wayland-sessions/plasma.desktop
*** Make {{package|plasma-workspace}} require
plasma-workspace-wayland and recommend
plasma-workspace-xorg
** Modify @kde-desktop comps group for Fedora 34 to
include plasma-workspace-xorg for the media.

* Other developers: N/A (not applicable for this Change)
* Release engineering: [https://pagure.io/releng/issue/9741 #9741]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A (not applicable for this Change)

== Upgrade/compatibility impact ==
Systems using certain (very old) graphics hardware or graphics drivers
(matrox, etc.) may have problems running the Wayland session. In these
(rare) cases, users may have to configure SDDM to use X11.

== How To Test ==
Log into a KDE Plasma desktop. Do any activity you would normally do
in your daily desktop use: launching applications, configuring

[EPEL-devel] Proposed EPEL Playground Documentation

2020-09-08 Thread Troy Dawson

Note1: Not everything has been implemented yet.  package.cfg is still
in the epel repos.  fedpkg has not been updated.  This documentation
will go out when those changes are implemented.

Note2: This is a proposal.  It can be changed.  If there is something
in there you do not want or think should be re-worded, please say so.

===
# EPEL PLAYGROUND

We have added an additional set of channels for EPEL-8 called
playground. It is meant to be sort of like Fedora Rawhide so that
packagers can work on versions of software which are too fast moving
or will have large API changes from what they are putting in the
regular channel.

Packages in epel8-playground are primarily to be used in the following manner:
 * To test out some new version of the package that might not be stable yet.
 * To test out some new packaging of the package
 * To test a major version change of the package that they want to
land at the next epel8 minor release.
 * To build a package that will never be stable enough for epel8, but
still could be useful to some.

## Consumers / End Users
Consumers should be aware that packages in EPEL8-playground are there
without any Service Level Expectations. You may want to only cherry
pick packages from there as needed.

EPEL8-playground is not a full EPEL release.  It only has those
packages that developers and maintainers are "playing" around with.
Because of this, you should not expect to enable only epel-playground
and get everything you need.  It is expected that you have regular
epel enabled whenever you enable epel-playground.

## Developers / Maintainers
epel8-playground builds are NOT automatically built when you build in
epel8.  This is a change from the original vision. #(Remove this
sentence after a few years)
You must use the epel8-playground branch and build from there, just
like you would any other Fedora / EPEL build area.

Packages in epel-playground will never be automatically put into
regular epel.  That is the responsibility of the package maintainer.

It is recommended that if a maintainer plans to bring a package that
has a large change from epel-playground to regular epel, they do it at
minor RHEL releases (ie, 8.3, 8.4).   Since end users will be
upgrading and paying more attention than usual at those times, it’s a
great chance to do larger changes.  Be sure to announce those major
changes well in advance on epel-devel and epel-announce.

EPEL Playground has traits similar to Fedora Rawhide.
 * Built packages do not need to tagged with override to get into the
epel8-playground build repository.  They will be put in the next time
the build repository is refreshed.  This is usually within 15 to 60
minutes.
  * The main epel8-playground repository is built once a day, just
like Fedora Rawhide.  Thus built packages are usually available in
epel8-playground the day after they are built.

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

[Bug 1870745] EPEL8 Branch Request: perl-DBIx-Class

2020-09-08 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1870745
Bug 1870745 depends on bug 1870763, which changed state.

Bug 1870763 Summary: EPEL8 Branch Request: perl-SQL-Translator
https://bugzilla.redhat.com/show_bug.cgi?id=1870763

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org

[Bug 1870763] EPEL8 Branch Request: perl-SQL-Translator

2020-09-08 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1870763
Bug 1870763 depends on bug 1870771, which changed state.

Bug 1870771 Summary: EPEL8 Branch Request: perl-Graph
https://bugzilla.redhat.com/show_bug.cgi?id=1870771

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org

[Bug 1870751] EPEL8 Branch Request: perl-Class-Unload

2020-09-08 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2020-09-08 15:51:17



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2020-9b6e480672 has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org

[Bug 1870763] EPEL8 Branch Request: perl-SQL-Translator

2020-09-08 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-SQL-Translator-1.61-3.
   ||el8
 Resolution|--- |ERRATA
Last Closed||2020-09-08 15:51:20



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2020-690eeb694b has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org

[Bug 1870745] EPEL8 Branch Request: perl-DBIx-Class

2020-09-08 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1870745
Bug 1870745 depends on bug 1870751, which changed state.

Bug 1870751 Summary: EPEL8 Branch Request: perl-Class-Unload
https://bugzilla.redhat.com/show_bug.cgi?id=1870751

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org

[Bug 1870771] EPEL8 Branch Request: perl-Graph

2020-09-08 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Graph-0.97.04-15.el8
 Resolution|--- |ERRATA
Last Closed||2020-09-08 15:51:14



--- Comment #6 from Fedora Update System  ---
FEDORA-EPEL-2020-2f405ef4b2 has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org

[EPEL-devel] kde-connect has incorrect dependencies (Centos 8 Stream)

2020-09-08 Thread Jason Oppel

The kde-connect package is missing kf5-kirigami and kf5-kirigami2 as 
dependencies.

Steps to reproduce:
Without KDE installed (running XFCE),  performing a "dnf install 
kdeconnect-app". Everything installs just fine. However, when you try to 
execute the kdeconnect-app, you receive the following errors:

"QQmlApplicationEngine failed to load component
qrc:/qml/main.qml:24 module "org.kde.kirigami" is not installed
kf5-kirigami"

The above error is corrected by doing "dnf install kf5-kirigami".

After resolving that error another error pops up when trying to run the 
kdeconnect-app.
"QQmlApplicationEngine failed to load component
qrc:/qml/main.qml:24 module "org.kde.kirigami" version 2.0 is not installed
kf5-kirigami"

The above error is corrected by doing "dnf install kf5-kirigami2". The app now 
starts cleanly. That said, KDE Connect still doesn't see my phone for some 
reason. I haven't figured out why that part of of the app isn't working at the 
moment.

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

[EPEL-devel] Re: Audacious dependency issue no gnome-icon-theme available to install (Centos 8 Stream)

2020-09-08 Thread Carl George

The audacious maintainer is aware and it is being tracked in this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1783816

On Tue, Sep 8, 2020 at 10:35 AM Jason Oppel  wrote:
>
> Whenever I try to "dnf install audacious", I get the following error:
> Error:
>  Problem: conflicting requests
>   - nothing provides gnome-icon-theme needed by audacious-3.10.1-3.el8.x86_64
> (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to 
> use not only best candidate packages)
>
> Could someone either add gnome-icon-theme or remove audiacious from the repo 
> until gnome-icon-theme can be added?
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://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/epel-devel@lists.fedoraproject.org



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

[EPEL-devel] Re: Continuing playground discussion

2020-09-08 Thread Troy Dawson

On Sun, Sep 6, 2020 at 2:01 PM Kevin Fenzi  wrote:
>
> On Fri, Sep 04, 2020 at 07:18:31AM -0700, Troy Dawson wrote:
> ...snipp
> > I think Step 5 is a very important step (if I'm understanding it
> > correctly).  Because it will give us a good idea about how many people
> > are utilizing playground.
>
> well, no, it will just make it more visible when packages in playground
> change.
>
> For usage, thats another thing... we should look at the new dnf counting
> that fedora is doing and see if we can use that with at least epel8...
> but thats another seperate project I guess.

Sorry, I wasn't clear.
By "utilizing playground" I meant developers / maintainers.
If we see that no, or very few packages are built in playground after
we go manual, then, maybe it isn't worth the effort for epel9.
If we see that a decent amount of packages are manually built in
playground, then we will know it's worth the effort for epel9.
I realize that package changes will probably come in waves.  So I
don't expect the steady stream we have in regular epel8.  But we
should have enough time to gauge how well the maintainers are using
it.

As for end users, ya.  As much as I wish we could find out ... I like
that we care enough about privacy that we can't find out.
Troy
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/epel-devel@lists.fedoraproject.org

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

2020-09-08 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 755  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
 495  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b   
bubblewrap-0.3.3-2.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-89ad58d02c   
golang-1.15-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-49c5f31e92   
python-pip-epel-8.1.2-14.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-864bc6779e   
chromium-85.0.4183.83-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-83bdeb2965   
ansible-2.9.13-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0a324e529d   
drupal7-7.72-1.el7


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

mbedtls-2.7.17-1.el7
php-phpseclib-2.0.29-1.el7
python-idstools-0.6.4-1.el7

Details about builds:



 mbedtls-2.7.17-1.el7 (FEDORA-EPEL-2020-f9a03b)
 Light-weight cryptographic and SSL/TLS library

Update Information:

- Update to 2.7.17

ChangeLog:

* Tue Sep  8 2020 Morten Stevens  - 2.7.17-1
- Update to 2.7.17

References:

  [ 1 ] Bug #1875047 - CVE-2020-16150 mbedtls: local side channel attack on 
classical CBC decryption in (D)TLS
https://bugzilla.redhat.com/show_bug.cgi?id=1875047




 php-phpseclib-2.0.29-1.el7 (FEDORA-EPEL-2020-ac52687ea5)
 PHP Secure Communications Library

Update Information:

**Version 2.0.29** - 2020-09-07  - SFTP: add enableDatePreservation() /
disableDatePreservation() (#1496) - SFTP: uploads on low speed networks could
get in infinite loop (#1507) - SSH2: when building algo list look at if crypto
engine is set (#1500) - X509: really looong base64 encoded strings broke
extractBER() (#1486)

ChangeLog:

* Tue Sep  8 2020 Remi Collet  - 2.0.29-1
- update to 2.0.29




 python-idstools-0.6.4-1.el7 (FEDORA-EPEL-2020-d9c3980de9)
 Snort and Suricata Rule and Event Utilities

Update Information:

New upstream release

ChangeLog:

* Mon Sep  7 2020 Marcin Dulak  - 0.6.4-1
- New upstream release

References:

  [ 1 ] Bug #1863715 - python-idstools-0.6.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1863715


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

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

2020-09-08 Thread updates

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1af9888c22   
golang-1.15-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-972f57ea6d   
drupal7-7.72-1.el6


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

mbedtls-2.7.17-1.el6
php-phpseclib-2.0.29-1.el6

Details about builds:



 mbedtls-2.7.17-1.el6 (FEDORA-EPEL-2020-b425525e83)
 Light-weight cryptographic and SSL/TLS library

Update Information:

- Update to 2.7.17

ChangeLog:

* Tue Sep  8 2020 Morten Stevens  - 2.7.17-1
- Update to 2.7.17

References:

  [ 1 ] Bug #1875047 - CVE-2020-16150 mbedtls: local side channel attack on 
classical CBC decryption in (D)TLS
https://bugzilla.redhat.com/show_bug.cgi?id=1875047




 php-phpseclib-2.0.29-1.el6 (FEDORA-EPEL-2020-8a6e53864f)
 PHP Secure Communications Library

Update Information:

**Version 2.0.29** - 2020-09-07  - SFTP: add enableDatePreservation() /
disableDatePreservation() (#1496) - SFTP: uploads on low speed networks could
get in infinite loop (#1507) - SSH2: when building algo list look at if crypto
engine is set (#1500) - X509: really looong base64 encoded strings broke
extractBER() (#1486)

ChangeLog:

* Tue Sep  8 2020 Remi Collet  - 2.0.29-1
- update to 2.0.29


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

[EPEL-devel] Audacious dependency issue no gnome-icon-theme available to install (Centos 8 Stream)

2020-09-08 Thread Jason Oppel

Whenever I try to "dnf install audacious", I get the following error:
Error: 
 Problem: conflicting requests
  - nothing provides gnome-icon-theme needed by audacious-3.10.1-3.el8.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use 
not only best candidate packages)

Could someone either add gnome-icon-theme or remove audiacious from the repo 
until gnome-icon-theme can be added?
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/epel-devel@lists.fedoraproject.org

F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

2020-09-08 Thread Ben Cotton

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.

== Feedback ==

 Is Wayland ready? 
Wayland has been used by default for Fedora Workstation (which uses
GNOME) since Fedora 25. And while it was somewhat immature initially,
today it is a very rock-solid experience on virtually everything
Fedora Workstation runs on. The change in Fedora 25 kickstarted the
drive to get everything working on Wayland, and the Workstation team
succeeded beyond their wildest dreams. Firefox has been Wayland-native
by default since Fedora 31 as well.

On the KDE side, serious work into supporting Wayland started shortly
after GNOME switched to Wayland by default. Unlike GNOME, KDE has a
much broader stack in its toolkit, and it has taken longer to get to a
usable state. With the Plasma 5.20 release, the Wayland protocol for
screencasting as well as middle-click paste finally are supported,
completing the required feature set for switching to Wayland by
default.

 What about NVIDIA? 
Plasma, in fact, ''does'' support NVIDIA GPUs with the proprietary
driver on Wayland. It needs to be manually activated, which will be
taken care of by the kwin-wayland-nvidia package. So the
expectation is that all major GPUs will work just fine.

 Why not keep using X11? 
The fact of the matter is, Xorg is in
[https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/
"hard maintenance mode"] per [[User:Uraeus|Christian Schaller]] and
development on it has basically stopped beyond the most critical of
fixes. Combined with the rapid maturation of the Wayland session in
KDE Plasma, this is the best time to make the switch and push things
over the edge for the KDE ecosystem in the same way that Fedora
Workstation did for the GNOME ecosystem.

== Benefit to Fedora ==
Fedora has long been a leader in advancing the adoption of the Wayland
protocol as part of the overall strategy to improve the Linux
graphical software stack. Much of the quality of Wayland for GNOME can
be attributed to the work done by the Fedora Workstation WG as part of
advancing the GNOME platform. It is now the KDE SIG's turn to do the
same for the KDE platform. By making this change, we are helping push
the adoption forward for newer, more streamlined, and overall more
actively developed graphics technology for the KDE ecosystem.

== Scope ==
* Proposal owners:
** Modify {{package|kwin}} to switch to Wayland
*** Split out /usr/bin/kwin_x11 to the
kwin-x11 subpackage.
*** Make {{package|kwin}} require kwin-wayland and
recommend kwin-x11
*** Add kwin-wayland-nvidia subpackage which contains
/usr/lib/environment.d/10-kwin-wayland-nvidia.conf to set
$KWIN_DRM_USE_EGL_STREAMS to 1. This package
will have have a Supplements dependency (kwin-wayland and
kmod-nvidia).
** Modify {{package|plasma-workspace}} to switch to Wayland
*** Rename /usr/share/xsessions/plasma.desktop to
/usr/share/xsessions/plasma-xorg.desktop, subpackage it
out as plasma-workspace-xorg, and have it require
kwin-x11
*** Rename /usr/share/wayland-sessions/plasmawayland.desktop
to /usr/share/wayland-sessions/plasma.desktop
*** Make {{package|plasma-workspace}} require
plasma-workspace-wayland and recommend
plasma-workspace-xorg
** Modify @kde-desktop comps group for Fedora 34 to
include plasma-workspace-xorg for the media.

* Other developers: N/A (not applicable for this Change)
* Release engineering: [https://pagure.io/releng/issue/9741 #9741]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A (not applicable for this Change)

== Upgrade/compatibility impact ==
Systems using certain (very old) graphics hardware or graphics drivers
(matrox, etc.) may have problems running the Wayland session. In these
(rare) cases, users may have to configure SDDM to use X11.

== How To Test ==
Log into a KDE Plasma desktop. Do any activity you would normally do
in your daily desktop use: launching applications, configuring
displays, etc. Things should work the same way under

F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

2020-09-08 Thread Ben Cotton

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

== Summary ==
Remove support for SELinux runtime disable so that the LSM hooks can
be hardened via read-only-after-initialization protections.

Migrate users to using ''selinux=0'' if they want to disable SELinux.

== Owner ==
* Name: [[User:plautrba| Petr Lautrbach]]
* Email: plaut...@redhat.com
* Name: [[User:omos| Ondrej Mosnacek]]
* Email: omosn...@redhat.com


== Detailed Description ==
Support for SELinux runtime disable via ''/etc/selinux/config'' was
originally developed to make it easier for Linux distributions to
support architectures where adding parameters to the kernel command
line was difficult.
Unfortunately, supporting runtime disable meant we had to make some
security trade-offs when it comes to the kernel LSM hooks.

Marking the kernel LSM hooks as read only provides some very nice
security benefits, but it does mean that we can no longer disable
SELinux at runtime.
Toggling between enforcing and permissive mode while booted will
remain unaffected and it will still be possible to disable SELinux by
adding ''selinux=0'' to the kernel command line via the boot loader
(GRUB).

System with ''SELINUX=disabled'' in ''/etc/selinux/config'' will come
up with ''/sys/fs/selinuxfs'' unmounted,
userspace will detect SELinux as disabled. Internally SELinux will be
enabled but not initialized so that there will be no SELinux checks
applied.

NOTE: Runtime disable is considered deprecated by upstream, and using
it will become increasingly painful (e.g. sleeping/blocking) through
future kernel releases until eventually it is removed completely.
Current kernel reports the following message during runtime disable:
''SELinux:  Runtime disable is deprecated, use selinux=0 on the kernel
cmdline''

Additional info:

* https://lwn.net/Articles/666550
* 
https://lore.kernel.org/selinux/159110207843.57260.5661475689740939480.stgit@chester/
* 
https://lore.kernel.org/selinux/157836784986.560897.13893922675143903084.stgit@chester/#t

== Benefit to Fedora ==
Marking the LSM hooks as read-only provides extra security hardening
against certain attacks, e.g. in case an attacker gains ability to
write to random kernel memory locations, with support for disable
SELinux runtime (''CONFIG_SECURITY_SELINUX_DISABLE=y'') they have a
bigger chance to turn off (parts of) SELinux permission checking.

== Scope ==
* Proposal owners:
** Make sure the kernel is built with
''CONFIG_SECURITY_SELINUX_DISABLE'' disabled.
** Make sure the relevant documentation is updated in a way that
''selinux=0'' on kernel command line is the preferred way to disable
SELinux.
*** 
https://docs.fedoraproject.org/en-US/quick-docs/changing-selinux-states-and-modes/
*** ''selinux(8)'' man page
** Make sure [https://github.com/rhinstaller/anaconda/ the installer]
uses the kernel command line instead of ''/etc/selinux/config'' to
disable SELinux.
** Optional: 
[https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/facts/system/selinux.py
''selinux'' Ansible module] should warn that SELinux needs to be
disabled using ''selinux=0''.
** Optional: [https://github.com/linux-system-roles/selinux
linux-system-roles.selinux] should disable SELinux using
''selinux=0''.

* Other developers: N/A
* Release engineering: https://pagure.io/releng/issue/9742
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
Users should not be directly affected by this change.

== How To Test ==
# Install a kernel built with ''CONFIG_SECURITY_SELINUX_DISABLE''
disabled, e.g. from
https://copr.fedorainfracloud.org/coprs/omos/drop-selinux-disable/.
# Confirm that SELinux is disabled when ''selinux=0'' is used on
kernel command line.
# Confirm that userspace considers SELinux disabled when
''SELINUX=disabled'' is used in ''/etc/selinux/config''.
# Confirm that userspace considers SELinux disabled when there is no
''/etc/selinux/config''.
# Confirm that the system works as expected in all previous cases.

== User Experience ==
There's no visible change for users with SELinux enabled.

Users with ''SELINUX=disabled'' in ''/etc/selinux/config'' and without
''selinux=0'' on kernel command line might notice that `ps Z` command
uses ''kernel'' domain for processes, while with ''selinux=0'' `ps Z`
prints '-'.
These users will also be able to load SELinux policy after boot.

== Dependencies ==
Upstream kernel SELinux subsystem waits for this change in order to
remove CONFIG_SECURITY_SELINUX_DISABLE functionality -
https://lore.kernel.org/selinux/157836784986.560897.13893922675143903084.stgit@chester/#t

== Contingency Plan ==
* Contingency mechanism:  Revert the kernel build option change and
build kernel with ''CONFIG_SECURITY_SELINUX_DISABLE=y''
* Contingency deadline: Beta freeze
* Blocks release? No


== Documentation ==
TBD

== Release Notes ==
TBD

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS

F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

2020-09-08 Thread Ben Cotton

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.

== Feedback ==

 Is Wayland ready? 
Wayland has been used by default for Fedora Workstation (which uses
GNOME) since Fedora 25. And while it was somewhat immature initially,
today it is a very rock-solid experience on virtually everything
Fedora Workstation runs on. The change in Fedora 25 kickstarted the
drive to get everything working on Wayland, and the Workstation team
succeeded beyond their wildest dreams. Firefox has been Wayland-native
by default since Fedora 31 as well.

On the KDE side, serious work into supporting Wayland started shortly
after GNOME switched to Wayland by default. Unlike GNOME, KDE has a
much broader stack in its toolkit, and it has taken longer to get to a
usable state. With the Plasma 5.20 release, the Wayland protocol for
screencasting as well as middle-click paste finally are supported,
completing the required feature set for switching to Wayland by
default.

 What about NVIDIA? 
Plasma, in fact, ''does'' support NVIDIA GPUs with the proprietary
driver on Wayland. It needs to be manually activated, which will be
taken care of by the kwin-wayland-nvidia package. So the
expectation is that all major GPUs will work just fine.

 Why not keep using X11? 
The fact of the matter is, Xorg is in
[https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/
"hard maintenance mode"] per [[User:Uraeus|Christian Schaller]] and
development on it has basically stopped beyond the most critical of
fixes. Combined with the rapid maturation of the Wayland session in
KDE Plasma, this is the best time to make the switch and push things
over the edge for the KDE ecosystem in the same way that Fedora
Workstation did for the GNOME ecosystem.

== Benefit to Fedora ==
Fedora has long been a leader in advancing the adoption of the Wayland
protocol as part of the overall strategy to improve the Linux
graphical software stack. Much of the quality of Wayland for GNOME can
be attributed to the work done by the Fedora Workstation WG as part of
advancing the GNOME platform. It is now the KDE SIG's turn to do the
same for the KDE platform. By making this change, we are helping push
the adoption forward for newer, more streamlined, and overall more
actively developed graphics technology for the KDE ecosystem.

== Scope ==
* Proposal owners:
** Modify {{package|kwin}} to switch to Wayland
*** Split out /usr/bin/kwin_x11 to the
kwin-x11 subpackage.
*** Make {{package|kwin}} require kwin-wayland and
recommend kwin-x11
*** Add kwin-wayland-nvidia subpackage which contains
/usr/lib/environment.d/10-kwin-wayland-nvidia.conf to set
$KWIN_DRM_USE_EGL_STREAMS to 1. This package
will have have a Supplements dependency (kwin-wayland and
kmod-nvidia).
** Modify {{package|plasma-workspace}} to switch to Wayland
*** Rename /usr/share/xsessions/plasma.desktop to
/usr/share/xsessions/plasma-xorg.desktop, subpackage it
out as plasma-workspace-xorg, and have it require
kwin-x11
*** Rename /usr/share/wayland-sessions/plasmawayland.desktop
to /usr/share/wayland-sessions/plasma.desktop
*** Make {{package|plasma-workspace}} require
plasma-workspace-wayland and recommend
plasma-workspace-xorg
** Modify @kde-desktop comps group for Fedora 34 to
include plasma-workspace-xorg for the media.

* Other developers: N/A (not applicable for this Change)
* Release engineering: [https://pagure.io/releng/issue/9741 #9741]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A (not applicable for this Change)

== Upgrade/compatibility impact ==
Systems using certain (very old) graphics hardware or graphics drivers
(matrox, etc.) may have problems running the Wayland session. In these
(rare) cases, users may have to configure SDDM to use X11.

== How To Test ==
Log into a KDE Plasma desktop. Do any activity you would normally do
in your daily desktop use: launching applications, configuring
displays, etc. Things should work the same way under

F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

2020-09-08 Thread Ben Cotton

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

== Summary ==
Remove support for SELinux runtime disable so that the LSM hooks can
be hardened via read-only-after-initialization protections.

Migrate users to using ''selinux=0'' if they want to disable SELinux.

== Owner ==
* Name: [[User:plautrba| Petr Lautrbach]]
* Email: plaut...@redhat.com
* Name: [[User:omos| Ondrej Mosnacek]]
* Email: omosn...@redhat.com


== Detailed Description ==
Support for SELinux runtime disable via ''/etc/selinux/config'' was
originally developed to make it easier for Linux distributions to
support architectures where adding parameters to the kernel command
line was difficult.
Unfortunately, supporting runtime disable meant we had to make some
security trade-offs when it comes to the kernel LSM hooks.

Marking the kernel LSM hooks as read only provides some very nice
security benefits, but it does mean that we can no longer disable
SELinux at runtime.
Toggling between enforcing and permissive mode while booted will
remain unaffected and it will still be possible to disable SELinux by
adding ''selinux=0'' to the kernel command line via the boot loader
(GRUB).

System with ''SELINUX=disabled'' in ''/etc/selinux/config'' will come
up with ''/sys/fs/selinuxfs'' unmounted,
userspace will detect SELinux as disabled. Internally SELinux will be
enabled but not initialized so that there will be no SELinux checks
applied.

NOTE: Runtime disable is considered deprecated by upstream, and using
it will become increasingly painful (e.g. sleeping/blocking) through
future kernel releases until eventually it is removed completely.
Current kernel reports the following message during runtime disable:
''SELinux:  Runtime disable is deprecated, use selinux=0 on the kernel
cmdline''

Additional info:

* https://lwn.net/Articles/666550
* 
https://lore.kernel.org/selinux/159110207843.57260.5661475689740939480.stgit@chester/
* 
https://lore.kernel.org/selinux/157836784986.560897.13893922675143903084.stgit@chester/#t

== Benefit to Fedora ==
Marking the LSM hooks as read-only provides extra security hardening
against certain attacks, e.g. in case an attacker gains ability to
write to random kernel memory locations, with support for disable
SELinux runtime (''CONFIG_SECURITY_SELINUX_DISABLE=y'') they have a
bigger chance to turn off (parts of) SELinux permission checking.

== Scope ==
* Proposal owners:
** Make sure the kernel is built with
''CONFIG_SECURITY_SELINUX_DISABLE'' disabled.
** Make sure the relevant documentation is updated in a way that
''selinux=0'' on kernel command line is the preferred way to disable
SELinux.
*** 
https://docs.fedoraproject.org/en-US/quick-docs/changing-selinux-states-and-modes/
*** ''selinux(8)'' man page
** Make sure [https://github.com/rhinstaller/anaconda/ the installer]
uses the kernel command line instead of ''/etc/selinux/config'' to
disable SELinux.
** Optional: 
[https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/facts/system/selinux.py
''selinux'' Ansible module] should warn that SELinux needs to be
disabled using ''selinux=0''.
** Optional: [https://github.com/linux-system-roles/selinux
linux-system-roles.selinux] should disable SELinux using
''selinux=0''.

* Other developers: N/A
* Release engineering: https://pagure.io/releng/issue/9742
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
Users should not be directly affected by this change.

== How To Test ==
# Install a kernel built with ''CONFIG_SECURITY_SELINUX_DISABLE''
disabled, e.g. from
https://copr.fedorainfracloud.org/coprs/omos/drop-selinux-disable/.
# Confirm that SELinux is disabled when ''selinux=0'' is used on
kernel command line.
# Confirm that userspace considers SELinux disabled when
''SELINUX=disabled'' is used in ''/etc/selinux/config''.
# Confirm that userspace considers SELinux disabled when there is no
''/etc/selinux/config''.
# Confirm that the system works as expected in all previous cases.

== User Experience ==
There's no visible change for users with SELinux enabled.

Users with ''SELINUX=disabled'' in ''/etc/selinux/config'' and without
''selinux=0'' on kernel command line might notice that `ps Z` command
uses ''kernel'' domain for processes, while with ''selinux=0'' `ps Z`
prints '-'.
These users will also be able to load SELinux policy after boot.

== Dependencies ==
Upstream kernel SELinux subsystem waits for this change in order to
remove CONFIG_SECURITY_SELINUX_DISABLE functionality -
https://lore.kernel.org/selinux/157836784986.560897.13893922675143903084.stgit@chester/#t

== Contingency Plan ==
* Contingency mechanism:  Revert the kernel build option change and
build kernel with ''CONFIG_SECURITY_SELINUX_DISABLE=y''
* Contingency deadline: Beta freeze
* Blocks release? No


== Documentation ==
TBD

== Release Notes ==
TBD

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS

Fedora-IoT-33-20200908.0 compose check report

2020-09-08 Thread Fedora compose checker

No missing expected images.

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

New soft failures (same test not soft failed in Fedora-IoT-33-20200907.0):

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

Passed openQA tests: 15/16 (x86_64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.38 to 0.18
Previous test data: https://openqa.fedoraproject.org/tests/657524#downloads
Current test data: https://openqa.fedoraproject.org/tests/658770#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-20200908.n.0 compose check report

2020-09-08 Thread Fedora compose checker

No missing expected images.

Failed openQA tests: 8/181 (x86_64)

New failures (same test not failed in Fedora-33-20200907.n.0):

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

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

ID: 658444  Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/658444
ID: 658446  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/658446
ID: 658475  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/658475
ID: 658480  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/658480
ID: 658501  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/658501
ID: 658523  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/658523
ID: 658542  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/658542

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-20200907.n.0):

ID: 658371  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/658371
ID: 658390  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/658390
ID: 658417  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/658417
ID: 658430  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/658430
ID: 658450  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/658450
ID: 658453  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/658453
ID: 658467  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/658467
ID: 658479  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/658479
ID: 658504  Test: x86_64 universal upgrade_2_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/658504

Passed openQA tests: 164/181 (x86_64)

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

ID: 658370  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/658370
ID: 658416  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/658416
ID: 658452  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/658452

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
Used swap changed from 30 MiB to 24 MiB
System load changed from 0.57 to 0.88
Previous test data: https://openqa.fedoraproject.org/tests/657264#downloads
Current test data: https://openqa.fedoraproject.org/tests/658414#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
System load changed from 1.65 to 1.13
Previous test data: https://openqa.fedoraproject.org/tests/657283#downloads
Current test data: https://openqa.fedoraproject.org/tests/658433#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
Used swap changed from 10 MiB to 14 MiB
System load changed from 1.10 to 1.31
Average CPU usage changed from 10.47142857 to 32.77142857
Previous test data: https://openqa.fedoraproject.org/tests/657284#downloads
Current test data: https://openqa.fedoraproject.org/tests/658434#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default_upload: 
Used swap changed from 25 MiB to 21 MiB
System load changed from 0.40 to 0.56
Previous test data: https://openqa.fedoraproject.org/tests/657300#downloads
Current test data: https://openqa.fedoraproject.org/tests/658450#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default@uefi: 
Used swap changed from 25 MiB to 22 MiB
Average CPU usage changed from 0.8333 to 11.00476190
Previous test data: https://openqa.fedoraproject.org/tests/657303#downloads
Current test data: https://openqa.fedoraproject.org/tests/658453#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
Used swap changed from 8 MiB to 20 MiB
System load changed from 1.21 to 1.50
Average CPU usage changed from 26.96190476 to 49.31904762
Previous test data: https://openqa.fedoraproject.org/tests/657344#downloads
Current test data: https://openqa.fedoraproject.org/tests/658494#downloads


-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose

[Bug 1876925] New: perl-PPIx-Regexp-0.074 is available

2020-09-08 Thread bugzilla

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

Bug ID: 1876925
   Summary: perl-PPIx-Regexp-0.074 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-PPIx-Regexp
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.074
Current version/release in rawhide: 0.073-1.fc33
URL: http://search.cpan.org/dist/PPIx-Regexp/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


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


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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org

Fedora 33 compose report: 20200908.n.0 changes

2020-09-08 Thread Fedora Rawhide Report

OLD: Fedora-33-20200907.n.0
NEW: Fedora-33-20200908.n.0

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

Size of added packages:  0 B
Size of dropped packages:175.35 KiB
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: Mate raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Mate-armhfp-33-20200907.n.0-sda.raw.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: python-nistats-0.0.1-0.5b0.fc32
Summary: Modeling and Statistical analysis of fMRI data in Python
RPMs:python-nistats-doc python3-nistats
Size:175.35 KiB


= 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

question about ELN builds of glusterfs and ceph?

2020-09-08 Thread Kaleb Keithley

I confess I'm a bit ignorant about how the ELN builds are going to be used.
Especially the ELN builds of glusterfs and ceph.

That aside—

Red Hat ships GlusterFS and Ceph (RHGS and RHCS respectively) as products,
and generally speaking glusterfs and ceph packages are not included in
RHEL; at least they haven't been so far. There are special builds of RHGS
in the RHEL base that are a subset of the RHGS product packages. And I'm
not sure what, if any, subset of RHCS product packages are provided in the
RHEL base.

And at RHEL 8.0 (actually before 8.0) there were issues with RHEL 8 having
inherited the Fedora glusterfs packages into the RHEL base which conflicted
with what the product team was going to be providing — incorrect version,
no subset, etc.

I'd like to avoid a repeat of those issues. I hope the people working on
ELN are coordinating with RHGS and RHCS product teams to avoid a
recurrence of them.

--

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

Blocker Review discussion tickets -- now available

2020-09-08 Thread Kamil Paral

Hello everyone,

I'd like to announce a new project of the QA team and an extension of the
BlockerBugs App [1]. The blocker and freeze exception proposals can now not
only be discussed during regular blocker review meetings [2], but also at
any time through discussion tickets hosted on Pagure [3]. So even if you
don't have time to participate in the meeting, you can still participate
and vote in those discussion tickets.

This will be mostly interesting to people who participated in blocker
review meetings in the past, but we hope we can attract new participants
this way. It is also very useful for package maintainers and developers,
because they can now easily provide feedback regarding a proposed blocker
or a freeze exception without attending a meeting at a particular time or
diluting a technical discussion in Bugzilla.

To participate, open the BlockerBugs App for a particular milestone (e.g.
F33 Beta [4]) and you'll see "Vote!" and "Discuss" links for
proposed/accepted blockers and freeze exceptions. Follow the links to see
tickets where you can express your opinion (which should ideally reflect
our release criteria [5]). You can vote according to the guide present at
[3], please read it carefully. A bot is following each ticket, updating the
voting summary, and accepting certain commands. Watching the Pagure repo
[3] also gives you the option to get notified about every new proposed
blocker/freeze exception.

We've been using these discussions for a week or two now (I apologize for a
late announcement) and so far our existing practice seems to be to vote for
proposals throughout the week using these discussion tickets, close those
which we can easily get enough votes and agree on, and discuss the
remainder during the next blocker review meeting. So the regular blocker
review meeting hasn't been replaced, but we use the discussion tickets to
cut down on the meeting length. We're still trying to figure out the best
approach to take here, so nothing is set in stone. The voting functionality
itself is also still in development, we'll try to provide new features and
improve the experience based on your feedback.

I'll be happy to answer questions, if there are any.
Thanks,
Kamil
Fedora QA

PS: Development credits go to Lukas Brabec, Frantisek Zatloukal, Tim Flink,
Josef Skladanka and Adam Williamson.

[1] https://qa.fedoraproject.org/blockerbugs/
[2] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[3] https://pagure.io/fedora-qa/blocker-review
[4] https://qa.fedoraproject.org/blockerbugs/milestone/33/beta/buglist
[5] https://fedoraproject.org/wiki/Fedora_Release_Criteria
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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-announce@lists.fedoraproject.org

Orphaned packages looking for new maintainers

2020-09-08 Thread Miro Hrončok


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

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

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-09-07.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains, see https://packager.fedorainfracloud.org/
For all orphaned packages, see https://packager.fedorainfracloud.org/orphan

Package  (co)maintainers   Status Change

apache-commons-dbcp   mizdebsk, orphan 3 weeks ago
container-exception-loggerabrt-sig, ekulik, mmarusak,  2 weeks ago
  msuchy, orphan
dbus-java orphan   4 weeks ago
emacs-magit   orphan, petersen 0 weeks ago
fedora-icon-theme orphan   0 weeks ago
freight   orphan   0 weeks ago
fst   orphan   4 weeks ago
geronimo-parent-poms  jjelen, mizdebsk, orphan 2 weeks ago
golang-github-mholt-  orphan   1 weeks ago
certmagic-0.9
joda-time mizdebsk, orphan 3 weeks ago
js-jquery-iframe-transportorphan   4 weeks ago
js-jquery-knoborphan   4 weeks ago
js-jquery-qrcode  orphan   4 weeks ago
js-tag-it orphan   4 weeks ago
jvnet-parent  mizdebsk, orphan 2 weeks ago
libmatthew-java   orphan   4 weeks ago
liquibase awood, orphan4 weeks ago
man-pages-de  orphan, romal4 weeks ago
marble-widget orphan, rdieter  1 weeks ago
mozilla-iot-gateway-addon-nodeorphan   4 weeks ago
mozilla-iot-gateway-addon-orphan   4 weeks ago
python
nodejs-babel-code-frame   orphan   0 weeks ago
nodejs-base   orphan   0 weeks ago
nodejs-bcrypt nodejs-sig, orphan   0 weeks ago
nodejs-body-parserorphan   0 weeks ago
nodejs-bufferutil nodejs-sig, orphan   0 weeks ago
nodejs-cache-base orphan   0 weeks ago
nodejs-call-matcher   orphan   0 weeks ago
nodejs-core-util-is   nodejs-sig, orphan   5 weeks ago
nodejs-cross-spawnnodejs-sig, orphan   0 weeks ago
nodejs-cross-spawn-async  nodejs-sig, orphan   0 weeks ago
nodejs-css-stringify  nodejs-sig, orphan, patches  2 weeks ago
nodejs-css-tree   orphan   2 weeks ago
nodejs-doctrine   galileo, nodejs-sig, orphan, 0 weeks ago
  vjancik
nodejs-duplexer   nodejs-sig, orphan   5 weeks ago
nodejs-duplexify  nodejs-sig, orphan   5 weeks ago
nodejs-end-of-stream  nodejs-sig, orphan   5 weeks ago
nodejs-espower-location-  orphan   2 weeks ago
detector
nodejs-esrecurse  nodejs-sig, orphan   0 weeks ago
nodejs-faucet orphan   0 weeks ago
nodejs-from   nodejs-sig, orphan   5 weeks ago
nodejs-fs-dot-notify  orphan   0 weeks ago
nodejs-gauge  nodejs-sig, orphan   0 weeks ago
nodejs-global-prefix  nodejs-sig, orphan   0 weeks ago
nodejs-grunt  nodejs-sig, orphan, patches, 2 weeks ago
  piotrp
nodejs-grunt-legacy-util  nodejs-sig, orphan, patches, 0 weeks ago

Fedora-Cloud-31-20200908.0 compose check report

2020-09-08 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

libxls SONAME change

2020-09-08 Thread Elliott Sales de Andrade

Hi,

The latest libxls 1.6.0 changes ABI, but accidentally did not update
SONAME. I have not yet updated, but will do so once upstream fixes the
SONAME, which I hope will happen within a week's time for this
notice's purposes.

As far as I am aware, the only package dependencies are R-readxl,
which I maintain already and will rebuild as part of the update.

-- 
Elliott
___
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: /etc/localtime is not a symlink on koji?

2020-09-08 Thread Elliott Sales de Andrade

On Tue, 8 Sep 2020 at 04:52, Petr Pisar  wrote:
>
> On Tue, Sep 08, 2020 at 04:00:14AM -0400, Elliott Sales de Andrade wrote:
> > I'm debugging an issue in  a FTBFS, which appears caused by unexpected
> > warnings during a build [1]. These warnings come from R and complain
> > that /etc/localtime is not a symlink.
> >
> > According to `man 5 localtime` [2], /etc/localtime cannot be a normal
> > file or hard link.
> > Is this something wrong in koji, or its builders?
> >
> > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=50987042
> > [2] https://www.freedesktop.org/software/systemd/man/localtime.html
>
> I hit this issue many years ago and tzdata maintainer claimed
>  that it was a fault
> of a mock tool. (Mock tool is used when building a package in Koji). I asked
> a maintainer of mock to fix it
>  and he "fixed" it by not
> creating /etc/localtime at all. In the mean time I implemented a work around
> in one of mine affected packages and has not seen any issue like that. (Except
> of a user who complained that the Fedora package survives longer before
> reporting an error than an upstream's code.)
>
> What's your issue now? Is /etc/localtime a normal file again, or is the error
> message wrong and the file is missing completely?

I debugged it a little with ls -l/cat /etc/localtime, and it
definitely exists, but is a regular file. Confusingly, this only
causes a problem on koji, not in local mock, even though manually
running similar code as the test appears to trigger the same warning
as on koji.

Looking at the R source code for Sys.timezone(), I've found that it
checks the TZ envvar before timedatectl & /etc/localtime, so setting
TZ works around the problem for me (and also silences timedatectl's
warnings.)

Since I have a workaround now and it doesn't reproduce on local mock,
I won't bother spamming koji with debug attempts.

>
> -- Petr

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

[Bug 1876823] perl-Text-Table-Tiny-1.01 is available

2020-09-08 Thread bugzilla

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



Latest upstream release: 1.01
Current version/release in rawhide: 1.00-1.fc33
URL: http://search.cpan.org/dist/Text-Table-Tiny/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


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


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


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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org

Fedora-Cloud-32-20200908.0 compose check report

2020-09-08 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)

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

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

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

[Bug 1876823] New: perl-Text-Table-Tiny-1.01 is available

2020-09-08 Thread bugzilla

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

Bug ID: 1876823
   Summary: perl-Text-Table-Tiny-1.01 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Text-Table-Tiny
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org

Re: /etc/localtime is not a symlink on koji?

2020-09-08 Thread Petr Pisar

On Tue, Sep 08, 2020 at 04:00:14AM -0400, Elliott Sales de Andrade wrote:
> I'm debugging an issue in  a FTBFS, which appears caused by unexpected
> warnings during a build [1]. These warnings come from R and complain
> that /etc/localtime is not a symlink.
> 
> According to `man 5 localtime` [2], /etc/localtime cannot be a normal
> file or hard link.
> Is this something wrong in koji, or its builders?
> 
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=50987042
> [2] https://www.freedesktop.org/software/systemd/man/localtime.html

I hit this issue many years ago and tzdata maintainer claimed
 that it was a fault
of a mock tool. (Mock tool is used when building a package in Koji). I asked
a maintainer of mock to fix it
 and he "fixed" it by not
creating /etc/localtime at all. In the mean time I implemented a work around
in one of mine affected packages and has not seen any issue like that. (Except
of a user who complained that the Fedora package survives longer before
reporting an error than an upstream's code.)

What's your issue now? Is /etc/localtime a normal file again, or is the error
message wrong and the file is missing completely?

-- Petr

signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

/etc/localtime is not a symlink on koji?

2020-09-08 Thread Elliott Sales de Andrade

Hi,
I'm debugging an issue in  a FTBFS, which appears caused by unexpected
warnings during a build [1]. These warnings come from R and complain
that /etc/localtime is not a symlink.

According to `man 5 localtime` [2], /etc/localtime cannot be a normal
file or hard link.
Is this something wrong in koji, or its builders?

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=50987042
[2] https://www.freedesktop.org/software/systemd/man/localtime.html
-- 
Elliott
___
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: Release criteria proposal: first boot experience

2020-09-08 Thread John M. Harris Jr

On Monday, September 7, 2020 7:25:49 AM MST Martin Kolman wrote:
> On Tue, 2020-09-01 at 19:15 -0700, John M. Harris Jr wrote:
> 
> > On Tuesday, September 1, 2020 1:22:26 PM MST Michael Catanzaro wrote:
> > 
> > > Hi,
> > > 
> > > We currently have a bug where the Online Accounts page in initial setup
> > > 
> > > is nonfunctional. [1] This doesn't violate any current release 
> > > criterion, but surely we don't want to release with a broken initial 
> > > setup experience. So let's add a new requirement for that. How about 
> > > something like:
> > > 
> > > "If an initial setup utility is run or intended to be run after the 
> > > first boot of the installed system, then it must start successfully and
> > > 
> > > each page or panel of the initial setup utility should withstand a 
> > > basic functionality test."
> > > 
> > > OK that's pretty basic, but it gets the point across. I think this can 
> > > be a final requirement, not necessarily important enough to be a beta 
> > > requirement. Bikeshed away!
> > > 
> > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1870476
> > 
> > 
> > I would like to report a bug with the first boot experience:
> > 
> > Upon installing a new GNOME system, I'm accosted with a dialog asking me 
> > questions about the system I just finished configuring in Anaconda. Is
> > there  something in Anaconda I'm missing to disable this behavior, or do
> > I have to write my own kickstart to fix that?
> 
> You can use the "fistboot --disable" command if you are installing via
> kickstart:
> https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#firstboot 
> That should disable all post installation setup tools (Initial Setup, Gnome
> Initial Setup).

I'm aware, I use kickstarts for the RHEL systems I deploy at work, but was 
hoping there'd be some option in the GUI for the graphical variants. It gets 
very annoying very quickly. ;)

Thank you.

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

55 matches

Mail list logo