Re: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

[Mikhail Gavrilov]

# authselect apply-changes
[error] [/etc/authselect/nsswitch.conf] has unexpected content!
[error] Unexpected changes to the configuration were detected.
[error] Refusing to activate profile unless those changes are removed or 
overwrite is requested.
Some unexpected changes to the configuration were detected. Use 'select' 
command instead.

# cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad

# ls -l /etc | grep resolv
lrwxrwxrwx.  1 root root39 Sep 10 10:56 resolv.conf -> 
../run/systemd/resolve/stub-resolv.conf
-rw-r--r--.  1 root root76 Aug 11 06:15 resolv.conf.orig-with-nm

And after creating a fresh VPN connection via NetworkManager name
resolving not working again.

# ping git.sbis.ru
ping: git.sbis.ru: Name or service not known

$ resolvectl domain
Global:
Link 2 (enp5s0): ~.
Link 3 (wlp4s0):
Link 4 (virbr0):
Link 5 (virbr0-nic):
Link 7 (vpn0):
___
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: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

[Mikhail Gavrilov]

# authselect apply-changes
[error] [/etc/authselect/nsswitch.conf] has unexpected content!
[error] Unexpected changes to the configuration were detected.
[error] Refusing to activate profile unless those changes are removed
or overwrite is requested.
Some unexpected changes to the configuration were detected. Use
'select' command instead.

# ls -l /etc | grep resolv
lrwxrwxrwx.  1 root root39 Sep 10 10:56 resolv.conf ->
../run/systemd/resolve/stub-resolv.conf
-rw-r--r--.  1 root root76 Aug 11 06:15 resolv.conf.orig-with-nm

# cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad


And after creating a fresh VPN connection via NetworkManager name
resolving not working again.

# ping git.sbis.ru
ping: git.sbis.ru: Name or service not known

$ resolvectl domain
Global:
Link 2 (enp5s0): ~.
Link 3 (wlp4s0):
Link 4 (virbr0):
Link 5 (virbr0-nic):
Link 7 (vpn0):


--
Best Regards,
Mike Gavrilov.


nsswitch.conf
Description: Binary data
___
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)

[John M. Harris Jr]

On Tuesday, September 8, 2020 8:28:20 AM MST 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. I

Schedule for Thursday's FPC Meeting (2020-09-10 16:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2020-09-10 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2020-09-10 09:00 PDT  US/Pacific
2020-09-10 12:00 EDT  --> US/Eastern <--
2020-09-10 16:00 UTC  UTC   
2020-09-10 17:00 BST  Europe/London 
2020-09-10 18:00 CEST Europe/Berlin 
2020-09-10 18:00 CEST Europe/Paris  
2020-09-10 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2020-09-11 00:00 HKT  Asia/Hong_Kong
2020-09-11 00:00 +08  Asia/Singapore
2020-09-11 01:00 JST  Asia/Tokyo
2020-09-11 02:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

= Followup Issues =

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

#topic #909 Suggest that linting/measuring-coverage is not for %check
.fpc 909
https://pagure.io/packaging-committee/issue/909

= Followup Pull Requests =

#topic #pr-814 Add SELinux Independent Policy Guidelines.
https://pagure.io/packaging-committee/pull-request/814

#topic #pr-947 Deprecate Old Style Dependency Generators.
https://pagure.io/packaging-committee/pull-request/947

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * Bring it up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Fabio Valentini]

On Thu, Sep 10, 2020 at 12:43 AM Alexander Scheel  wrote:
>
> On Wed, Sep 9, 2020 at 6:27 PM Jerry James  wrote:

(snip)

> > For those who are willing to help out, is
> > https://pagure.io/java-maint-sig/issues the place to go to figure out
> > what needs to be done?  Is there any kind of TODO list or wishlist
> > elsewhere?

Yeah, those are the high-level tasks I'm tracking.

There's also a kanban board for individual, smaller tasks:
https://teams.fedoraproject.org/project/java-package-maintainer-sig/kanban

And if you're feeling old-fashioned, this is a custom bugzilla search
for SIG bugs:
https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&classification=Fedora&email1=java-maint-sig%40lists.fedoraproject.org&emailassigned_to1=1&emailcc1=1&emailtype1=equals&product=Fedora&query_format=advanced

> That has a good list for current issues. Many friendly folks also hang
> out in #fedora-java, where you can feel free to ask questions or lend
> a hand if you are looking for something more immediate.
>
> The old Stewardship SIG pages also had some interesting data:
>
> https://fedora-stewardship.github.io/overview/
>
> I'm not sure if Fabio has migrated the backlog anywhere.

I did not. The data was largely maintained manually, and it was too
big a time sink to keep around.
I see the kanban board as a replacement for the backlog.

> > You've mentioned having some kind of script that rebuilds the Java
> > world to check for issues relating to package updates.  Is that
> > available to the public?  How long does it take to run (and on what
> > hardware do you run it)?
>
> This isn't a real integration test of any sort. We rebuild PRs
> (manually-triggered) and most all dependent packages in COPR and see
> if the world builds fine. You can find the script in the old
> Stewardship SIG repo:
>
> https://github.com/fedora-stewardship/fedora-stewardship.github.io/blob/master/scripts/review_pr.py

I intend to also push the scripts to the java-maint-sig pagure repo eventually.
I just haven't gotten around to do that yet.

Fabio

> There is also:
>
>
> HTH,
> Alex
>
> > Speaking of helping out, if anybody wants mockito 3.x in Fedora, here
> > is a pull request to do just that:
> > https://src.fedoraproject.org/rpms/mockito/pull-request/2
> > --
> > Jerry James
> > http://www.jamezone.org/
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Miro Hrončok]

On 10. 09. 20 0:25, Jerry James wrote:

For those who are willing to help out, is
https://pagure.io/java-maint-sig/issues  the place to go to figure out
what needs to be done?  Is there any kind of TODO list or wishlist
elsewhere?


There is also:

https://packager.fedorainfracloud.org/java-maint-sig

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

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

[Alexander Scheel]

On Wed, Sep 9, 2020 at 6:27 PM Jerry James  wrote:
>
> On Tue, Sep 8, 2020 at 4:19 PM Fabio Valentini  wrote:
> > 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).
>
> For those who are willing to help out, is
> https://pagure.io/java-maint-sig/issues the place to go to figure out
> what needs to be done?  Is there any kind of TODO list or wishlist
> elsewhere?

That has a good list for current issues. Many friendly folks also hang
out in #fedora-java, where you can feel free to ask questions or lend
a hand if you are looking for something more immediate.

The old Stewardship SIG pages also had some interesting data:

https://fedora-stewardship.github.io/overview/

I'm not sure if Fabio has migrated the backlog anywhere.

> You've mentioned having some kind of script that rebuilds the Java
> world to check for issues relating to package updates.  Is that
> available to the public?  How long does it take to run (and on what
> hardware do you run it)?

This isn't a real integration test of any sort. We rebuild PRs
(manually-triggered) and most all dependent packages in COPR and see
if the world builds fine. You can find the script in the old
Stewardship SIG repo:

https://github.com/fedora-stewardship/fedora-stewardship.github.io/blob/master/scripts/review_pr.py

There is also:


HTH,
Alex

> Speaking of helping out, if anybody wants mockito 3.x in Fedora, here
> is a pull request to do just that:
> https://src.fedoraproject.org/rpms/mockito/pull-request/2
> --
> Jerry James
> http://www.jamezone.org/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Jerry James]

On Tue, Sep 8, 2020 at 4:19 PM Fabio Valentini  wrote:
> 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).

For those who are willing to help out, is
https://pagure.io/java-maint-sig/issues the place to go to figure out
what needs to be done?  Is there any kind of TODO list or wishlist
elsewhere?

You've mentioned having some kind of script that rebuilds the Java
world to check for issues relating to package updates.  Is that
available to the public?  How long does it take to run (and on what
hardware do you run it)?

Speaking of helping out, if anybody wants mockito 3.x in Fedora, here
is a pull request to do just that:
https://src.fedoraproject.org/rpms/mockito/pull-request/2
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [ELN] Update obsoleted for weird reasons

[Miro Hrončok]

On 09. 09. 20 23:20, Troy Dawson wrote:

It was a bit of a race condition.
The automatic eln rebuilder got stuck, I'm not positive of the reason.
But when it was restarted, it went through all of the package builds
that it had missed, and built them.
I'm not positive why, but if you look at the start times of the
builds, python3.9-3.9.0~rc1-1.eln103 was started AFTER
python3.9-3.9.0~rc1-2.eln103.  By one minute.


python3.9-3.9.0~rc1-1.eln103:
Started Fri, 14 Aug 2020 03:55:13 UTC
Completed   Fri, 14 Aug 2020 05:50:57 UTC

python3.9-3.9.0~rc1-2.eln103:
Started Fri, 14 Aug 2020 03:54:54 UTC
Completed   Fri, 14 Aug 2020 06:12:13 UTC

Indeed, started first, even the buildID is lower.
I somehow missed that, in the original email I claim that:


however there is no "more recent" (more recently started or more recently
completed) build of python3.9 in Koji


And that was incorrect. Sorry about that.


Since ...rc1-2 was started before ...rc1-1, bodhi assumed that the one
that started it's build last, was supposed to be the one that gets
merged.
Anyway, bodhi was just doing it's job, and it did it correctly.
I think we need to look at our automation and when it get's stuck,
make sure the backed up builds it does are in build order.


Right, that should do it. Considering the builds would not wait for each other 
to be visible in the buildroot anyway (unless the automation is that clever), 
even skipping the older builds in such situation might work (and save some 
resources).



Side note.  I've manually tagged the new one into ELN.


Thanks.

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

Re: [ELN] Update obsoleted for weird reasons

[Troy Dawson]

On Wed, Sep 9, 2020 at 2:19 PM Troy Dawson  wrote:
>
> On Wed, Sep 9, 2020 at 1:34 PM Kevin Fenzi  wrote:
> >
> > On Wed, Sep 09, 2020 at 08:07:24PM +0200, Miro Hrončok wrote:
> > > Hello.
> > >
> > > I've noticed at https://src.fedoraproject.org/rpms/python3.9 that the 
> > > latest
> > > ELN release of python3.9 is behind Fedora.
> > >
> > > I've assumed the build has failed, but it succeeded:
> > >
> > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1592756
> > >
> > > Except it it not tagged to eln.
> > >
> > > I've located the bodhi update:
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-8e33e741d8
> > >
> > > It is "obsoleted" with "This update cannot be pushed to stable. These 
> > > builds
> > > python3.9-3.9.0~rc1-2.eln103 have a more recent build in koji's eln tag."
> > >
> > > I've checked the koji's eln tag and it has python3.9-3.9.0~rc1-1.eln103 
> > > now.
> > >
> > > Maybe some different build was tagged when the update was created (no idea
> > > how to tell). If it was the Fedora build, it indeed has higher
> > > version-release if that's what meant by "more recent" -- however there is 
> > > no
> > > "more recent" (more recently started or more recently completed) build of
> > > python3.9 in Koji.
> > >
> > > This does not show anything suspicious:
> > >
> > >   $ koji list-history --package=python3.9 | grep eln
> > >
> > > Is this expected? Should the update be edited and pushed again? Or should
> > > the build be tagged manually? Am I expected to deal with that, as the
> > > package maintainer?
> > >
> > > This particular build only fixes a minor user-facing issue and does not
> > > affect builds of dependent packages so we can "leave it be" and wait for 
> > > the
> > > next build, however that might not always be the case.
> >
> > I guess this is a bug, but What I think happened is:
> >
> > f33 python3.9 finished:
> > Thu Aug 13 20:40:05 2020 python3.9-3.9.0~rc1-2.fc33 tagged into f33 by 
> > bodhi [still active]
> > ( eln was inheriting from f33-build at the time )
> >
> > Then, the eln build finished:
> > Thu Aug 13 23:12:34 2020 python3.9-3.9.0~rc1-2.eln103 tagged into 
> > eln-updates-candidate
> > by bpeck/jenkins-continuous-infra.apps.ci.centos.org
> >
> > but at this point bodhi looks and sees... hey f33 which we inherit
> > from already has a build of this version, so lets not push this to
> > stable.
> >
> > I think bodhi needs to be a bit smarter about checking for "more recent
> > builds". Possibly not looking at inheritence?
> >
> > I could be wrong, but thats what it seems like from a quick glance...
> >
>
> It was a bit of a race condition.
> The automatic eln rebuilder got stuck, I'm not positive of the reason.
> But when it was restarted, it went through all of the package builds
> that it had missed, and built them.
> I'm not positive why, but if you look at the start times of the
> builds, python3.9-3.9.0~rc1-1.eln103 was started AFTER
> python3.9-3.9.0~rc1-2.eln103.  By one minute.
>
> Since ...rc1-2 was started before ...rc1-1, bodhi assumed that the one
> that started it's build last, was supposed to be the one that gets
> merged.
> Anyway, bodhi was just doing it's job, and it did it correctly.
> I think we need to look at our automation and when it get's stuck,
> make sure the backed up builds it does are in build order.
>
> Troy

Side note.  I've manually tagged the new one into ELN.

Troy
___
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: [ELN] Update obsoleted for weird reasons

[Troy Dawson]

On Wed, Sep 9, 2020 at 1:34 PM Kevin Fenzi  wrote:
>
> On Wed, Sep 09, 2020 at 08:07:24PM +0200, Miro Hrončok wrote:
> > Hello.
> >
> > I've noticed at https://src.fedoraproject.org/rpms/python3.9 that the latest
> > ELN release of python3.9 is behind Fedora.
> >
> > I've assumed the build has failed, but it succeeded:
> >
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=1592756
> >
> > Except it it not tagged to eln.
> >
> > I've located the bodhi update:
> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-8e33e741d8
> >
> > It is "obsoleted" with "This update cannot be pushed to stable. These builds
> > python3.9-3.9.0~rc1-2.eln103 have a more recent build in koji's eln tag."
> >
> > I've checked the koji's eln tag and it has python3.9-3.9.0~rc1-1.eln103 now.
> >
> > Maybe some different build was tagged when the update was created (no idea
> > how to tell). If it was the Fedora build, it indeed has higher
> > version-release if that's what meant by "more recent" -- however there is no
> > "more recent" (more recently started or more recently completed) build of
> > python3.9 in Koji.
> >
> > This does not show anything suspicious:
> >
> >   $ koji list-history --package=python3.9 | grep eln
> >
> > Is this expected? Should the update be edited and pushed again? Or should
> > the build be tagged manually? Am I expected to deal with that, as the
> > package maintainer?
> >
> > This particular build only fixes a minor user-facing issue and does not
> > affect builds of dependent packages so we can "leave it be" and wait for the
> > next build, however that might not always be the case.
>
> I guess this is a bug, but What I think happened is:
>
> f33 python3.9 finished:
> Thu Aug 13 20:40:05 2020 python3.9-3.9.0~rc1-2.fc33 tagged into f33 by bodhi 
> [still active]
> ( eln was inheriting from f33-build at the time )
>
> Then, the eln build finished:
> Thu Aug 13 23:12:34 2020 python3.9-3.9.0~rc1-2.eln103 tagged into 
> eln-updates-candidate
> by bpeck/jenkins-continuous-infra.apps.ci.centos.org
>
> but at this point bodhi looks and sees... hey f33 which we inherit
> from already has a build of this version, so lets not push this to
> stable.
>
> I think bodhi needs to be a bit smarter about checking for "more recent
> builds". Possibly not looking at inheritence?
>
> I could be wrong, but thats what it seems like from a quick glance...
>

It was a bit of a race condition.
The automatic eln rebuilder got stuck, I'm not positive of the reason.
But when it was restarted, it went through all of the package builds
that it had missed, and built them.
I'm not positive why, but if you look at the start times of the
builds, python3.9-3.9.0~rc1-1.eln103 was started AFTER
python3.9-3.9.0~rc1-2.eln103.  By one minute.

Since ...rc1-2 was started before ...rc1-1, bodhi assumed that the one
that started it's build last, was supposed to be the one that gets
merged.
Anyway, bodhi was just doing it's job, and it did it correctly.
I think we need to look at our automation and when it get's stuck,
make sure the backed up builds it does are in build order.

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

Orca - Fedora Freedom and Independence for the Blind

[alciregi]

Hello.
Could someone involved in this topic have a look to this post on Ask
Fedora?




Thanks,
A.
___
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: [ELN] Update obsoleted for weird reasons

[Kevin Fenzi]

On Wed, Sep 09, 2020 at 08:07:24PM +0200, Miro Hrončok wrote:
> Hello.
> 
> I've noticed at https://src.fedoraproject.org/rpms/python3.9 that the latest
> ELN release of python3.9 is behind Fedora.
> 
> I've assumed the build has failed, but it succeeded:
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1592756
> 
> Except it it not tagged to eln.
> 
> I've located the bodhi update:
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-8e33e741d8
> 
> It is "obsoleted" with "This update cannot be pushed to stable. These builds
> python3.9-3.9.0~rc1-2.eln103 have a more recent build in koji's eln tag."
> 
> I've checked the koji's eln tag and it has python3.9-3.9.0~rc1-1.eln103 now.
> 
> Maybe some different build was tagged when the update was created (no idea
> how to tell). If it was the Fedora build, it indeed has higher
> version-release if that's what meant by "more recent" -- however there is no
> "more recent" (more recently started or more recently completed) build of
> python3.9 in Koji.
> 
> This does not show anything suspicious:
> 
>   $ koji list-history --package=python3.9 | grep eln
> 
> Is this expected? Should the update be edited and pushed again? Or should
> the build be tagged manually? Am I expected to deal with that, as the
> package maintainer?
> 
> This particular build only fixes a minor user-facing issue and does not
> affect builds of dependent packages so we can "leave it be" and wait for the
> next build, however that might not always be the case.

I guess this is a bug, but What I think happened is: 

f33 python3.9 finished: 
Thu Aug 13 20:40:05 2020 python3.9-3.9.0~rc1-2.fc33 tagged into f33 by bodhi 
[still active]
( eln was inheriting from f33-build at the time )

Then, the eln build finished: 
Thu Aug 13 23:12:34 2020 python3.9-3.9.0~rc1-2.eln103 tagged into 
eln-updates-candidate
by bpeck/jenkins-continuous-infra.apps.ci.centos.org

but at this point bodhi looks and sees... hey f33 which we inherit
from already has a build of this version, so lets not push this to
stable. 

I think bodhi needs to be a bit smarter about checking for "more recent
builds". Possibly not looking at inheritence?

I could be wrong, but thats what it seems like from a quick glance... 

kevin


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

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

[Ben Cotton]

Due to outstanding unresolved blockers, there is no release candidate
for Fedora 33 Beta yet. I am cancelling tomorrow's Go/No-Go meeting.
The Release Readiness meeting *will be held* as scheduled[1]. Please
update the Release Readiness wiki page[2] with your team's readiness
if appropriate. We will use that to keep the Release Readiness meeting
short and focused.

The Fedora 33 Beta Go/No-Go meeting[3] will be held at 1700 UTC on
Thursday 17 September in #fedora-meeting-1. We will target the Beta
target date #1 milestone. The release schedule[5] has been updated
accordingly. This change does not impact the final release date.

 Help is wanted with any of the outstanding blockers.

[1] https://apps.fedoraproject.org/calendar/meeting/9805/
[2] https://fedoraproject.org/wiki/Release_Readiness
[3] https://apps.fedoraproject.org/calendar/meeting/9808/
[4] https://qa.fedoraproject.org/blockerbugs/milestone/33/beta/buglist
[5] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

[Michael Catanzaro]

On Wed, Sep 9, 2020 at 2:08 pm, Michael Catanzaro 
 wrote:

Then, fix /etc/resolv.conf:

# rm /etc/resolv.conf
# ln -s ../run/systemd/resolve/stub-resolv.conf


Sigh, sorry. Fixed instructions:

# rm /etc/resolv.conf
# ln -s ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

It should look like this:

# ls -l /etc | grep resolv
lrwxrwxrwx. 1 root root 39 Sep 9 14:13 resolv.conf -> 
../run/systemd/resolve/stub-resolv.conf


(Unless you intentionally want to configure DNS differently and are OK 
with having a non-default setup.)


Michael

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

Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

[Michael Catanzaro]

Hi,

I've you've installed or upgraded to Fedora 33 (or to rawhide) prior to 
today, your /etc/nsswitch and /etc/resolv.conf are probably in a broken 
state that requires manual intervention to resolve. This has caused 
breakage for mDNS and VPN users [1][2][3]. Apologies for this breakage. 
Anyone installing with current nightly images or upgrading as of today 
should be OK, so users installing F33 beta or upgrading from F32 to F33 
beta will be unaffected.


To fix /etc/nsswitch.conf, edit the hosts line in 
/etc/authselect/user-nsswitch.conf to look like this:


hosts:  files mdns4_minimal [NOTFOUND=return] resolve 
[!UNAVAIL=return] myhostname dns


Then run:

# authselect apply-changes

Then, fix /etc/resolv.conf:

# rm /etc/resolv.conf
# ln -s ../run/systemd/resolve/stub-resolv.conf

And restart NetworkManager:

# systemctl restart NetworkManager.service

Michael

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1873856
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1867830
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1863041

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

[Christoph Karl]

Hello!

Me having this issue also.
But only in firefox and thunderbird, other appls seems to work.

Do you have a link, bugzilla or so?

Thank you

Best Regrads
Christoph

Am 09.09.20 um 16:51 schrieb Vitaly Zaitsev via devel:

On 08.09.2020 17:28, Ben Cotton wrote:

Change the default session selection in SDDM to prefer the
Wayland-based KDE Plasma Desktop session over the X11-based one.


KDE Plasma from F32 on Wayland has a major issue with broken keyboard
layout indicator. This issue need to be fixed first before making it
default.


___
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

[ELN] Update obsoleted for weird reasons

[Miro Hrončok]

Hello.

I've noticed at https://src.fedoraproject.org/rpms/python3.9 that the latest ELN 
release of python3.9 is behind Fedora.


I've assumed the build has failed, but it succeeded:

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

Except it it not tagged to eln.

I've located the bodhi update:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-8e33e741d8

It is "obsoleted" with "This update cannot be pushed to stable. These builds 
python3.9-3.9.0~rc1-2.eln103 have a more recent build in koji's eln tag."


I've checked the koji's eln tag and it has python3.9-3.9.0~rc1-1.eln103 now.

Maybe some different build was tagged when the update was created (no idea how 
to tell). If it was the Fedora build, it indeed has higher version-release if 
that's what meant by "more recent" -- however there is no "more recent" (more 
recently started or more recently completed) build of python3.9 in Koji.


This does not show anything suspicious:

  $ koji list-history --package=python3.9 | grep eln

Is this expected? Should the update be edited and pushed again? Or should the 
build be tagged manually? Am I expected to deal with that, as the package 
maintainer?


This particular build only fixes a minor user-facing issue and does not affect 
builds of dependent packages so we can "leave it be" and wait for the next 
build, however that might not always be the case.


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

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

[Tom Seewald]

> KDE
> spin is a blocker edition, so its default installation must pass our
> release criterias.
> https://fedoraproject.org/wiki/Fedora_Release_Criteria
Right, but have there been any investigations to see if those release criteria 
are fulfilled on Plasma + Wayland? If it doesn't currently meet all criteria, 
what are the known blockers?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Aleksandar Kurtakov]

On Wed, Sep 9, 2020 at 5:33 PM Stephen John Smoogen 
wrote:

>
>
> On Wed, 9 Sep 2020 at 09:37, Björn Persson  wrote:
>
>> Guido Aulisi wrote:
>> > IMHO we could package only the JDK and let the user use Java software
>> directly from upstream.
>> > Usually upstream means Apache, which is a trusted source, and Java
>> users are smart enough to manage the Java packages.
>> > I usuali do so when using maven, hadoop, tomcat, etc.
>> > I think this solution could be valid for any other language, like php,
>> python: packaging only the base language and anything that is not available
>> in executable formats.
>>
>> And how well does that scale?
>>
>>
> It doesn't scale.. but neither does having all those packages owned and
> looked at by 1 person. Either people need to start helping or this is the
> future. People have instead spent the last decade usually saying 'I need
> this but have no idea how to maintain it so you can't get rid of it.' That
> has led to the point where the people who were trying to do this made it
> into modules to make their lives easier and when that made other people's
> lives harder.. deciding that it was an unwinnable game so why participate
> any longer.
>

Couldn't agree more!!! From big proponent of RPM packaging I went to the
"meh, who cares" group - because I see more and more things coming our way
for maintenance so the choice in front of us is "work on upstream Eclipse"
or "keep Eclipse RPM packages". One can easily guess what wins.


>
> The cost of free packages is eternal vigilance on their maintenance.
>
>
>
>> As a sysadmin I don't normally need to know what language each program
>> is written in. I use language-specific tools only on programs I'm
>> developing, not on programs I merely use. Should I periodically run
>> cpan to check for Perl program updates, pip to check for Python program
>> updates, npm to check for Javascript program updates, gem to check for
>> Ruby program updates, and so on and so forth? And then manually check a
>> bunch of individual upstream websites for updates to programs that
>> aren't in those language-specific repositories either? No way! I run
>> "yum update" and get *all* the updates for my system.
>>
>> Björn Persson
>> ___
>> 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
>>
>
>
> --
> Stephen J Smoogen.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://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
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-IoT-33-20200909.0 compose check report

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

Old soft failures (same test soft failed in Fedora-IoT-33-20200908.0):

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

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.18 to 0.06
Previous test data: https://openqa.fedoraproject.org/tests/658770#downloads
Current test data: https://openqa.fedoraproject.org/tests/660210#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Vitaly Zaitsev via devel]

On 08.09.2020 17:28, Ben Cotton wrote:
> Change the default session selection in SDDM to prefer the
> Wayland-based KDE Plasma Desktop session over the X11-based one.

KDE Plasma from F32 on Wayland has a major issue with broken keyboard
layout indicator. This issue need to be fixed first before making it
default.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Summary/Minutes from today's FESCo Meeting (2020-09-09)

[Zbigniew Jędrzejewski-Szmek]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-09-09/fesco.2020-09-09-14.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-09-09/fesco.2020-09-09-14.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-09-09/fesco.2020-09-09-14.00.log.html

Meeting summary
---
* init process  (zbyszek, 14:00:28)

* #2470 F34 Self-Contained Change: Reduce installation media size by
  improving the compression ratio of SquashFS filesystem  (zbyszek,
  14:02:05)
  * AGREED: REJECTED (0, 0, -8)  (zbyszek, 14:13:52)

* Next week's chair  (zbyszek, 14:13:59)
  * ACTION: cverna will chair next meeting  (zbyszek, 14:15:15)

* Open Floor  (zbyszek, 14:15:21)
  * https://qa.fedoraproject.org/blockerbugs/milestone/33/beta/buglist
(zbyszek, 14:18:45)

Meeting ended at 14:21:28 UTC.

Action Items

* cverna will chair next meeting
___
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)

[Neal Becker]

On Wed, Sep 9, 2020 at 10:33 AM Dominique Martinet 
wrote:

> Neal Becker wrote on Wed, Sep 09, 2020:
> > I have tested kde/wayland on F32 but have hit a roadblock.  We are all
> > working from home and need to share screens.  Using google chrome, on X11
> > when I try to share an app window (which is my usual choice) there are no
> > problems, but on wayland only some of the windows are given as choices to
> > share.  I haven'tfound any particular pattern to which windows are
> > listed (is it just from certain desktops?)  I believe this isn't
> > chrome specific (have to retest).
>
> I haven't tested but you can probaly only share other Xwayland windows
> (chrome still runs on Xwayland last I checked)
>
> The wayland-native way of sharing app windows is xdg-desktop-portal
> which has a kde implementation:
> https://invent.kde.org/plasma/xdg-desktop-portal-kde
> https://koji.fedoraproject.org/koji/packageinfo?packageID=24326
>
> Do you have xdg-desktop-portal-kde installed?
>
>
rpm -q xdg-desktop-portal-kde
xdg-desktop-portal-kde-5.19.5-1.fc32.x86_64

I tested firefox also, using google meet.  On firefox, no windows are
available to choose for sharing when run under wayland.  All the windows
show as expected
running firefox on plasma/X11.  That's a bit different than chrome but
seems to be some bug common between them.

>
>

-- 
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Dominique Martinet]

Neal Becker wrote on Wed, Sep 09, 2020:
> I have tested kde/wayland on F32 but have hit a roadblock.  We are all
> working from home and need to share screens.  Using google chrome, on X11
> when I try to share an app window (which is my usual choice) there are no
> problems, but on wayland only some of the windows are given as choices to
> share.  I haven'tfound any particular pattern to which windows are
> listed (is it just from certain desktops?)  I believe this isn't
> chrome specific (have to retest).

I haven't tested but you can probaly only share other Xwayland windows
(chrome still runs on Xwayland last I checked)

The wayland-native way of sharing app windows is xdg-desktop-portal
which has a kde implementation:
https://invent.kde.org/plasma/xdg-desktop-portal-kde
https://koji.fedoraproject.org/koji/packageinfo?packageID=24326

Do you have xdg-desktop-portal-kde installed?

> Where can I report this issue?

Now that also needs to be supported by whatever videoconferencing
software you use (in this case chrome); you might want to try firefox
just to see if it's better...

So to sum it up:
 - if this works on FF but not chrome, it's a chrome bug
 - if this works on e.g. gnome with either browsers but not plasma, it's
a kde bug


Good luck (?)
-- 
Dominique
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Stephen John Smoogen]

On Wed, 9 Sep 2020 at 09:37, Björn Persson  wrote:

> Guido Aulisi wrote:
> > IMHO we could package only the JDK and let the user use Java software
> directly from upstream.
> > Usually upstream means Apache, which is a trusted source, and Java users
> are smart enough to manage the Java packages.
> > I usuali do so when using maven, hadoop, tomcat, etc.
> > I think this solution could be valid for any other language, like php,
> python: packaging only the base language and anything that is not available
> in executable formats.
>
> And how well does that scale?
>
>
It doesn't scale.. but neither does having all those packages owned and
looked at by 1 person. Either people need to start helping or this is the
future. People have instead spent the last decade usually saying 'I need
this but have no idea how to maintain it so you can't get rid of it.' That
has led to the point where the people who were trying to do this made it
into modules to make their lives easier and when that made other people's
lives harder.. deciding that it was an unwinnable game so why participate
any longer.

The cost of free packages is eternal vigilance on their maintenance.



> As a sysadmin I don't normally need to know what language each program
> is written in. I use language-specific tools only on programs I'm
> developing, not on programs I merely use. Should I periodically run
> cpan to check for Perl program updates, pip to check for Python program
> updates, npm to check for Javascript program updates, gem to check for
> Ruby program updates, and so on and so forth? And then manually check a
> bunch of individual upstream websites for updates to programs that
> aren't in those language-specific repositories either? No way! I run
> "yum update" and get *all* the updates for my system.
>
> Björn Persson
> ___
> 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
>


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

[Neal Gompa]

On Wed, Sep 9, 2020 at 10:09 AM Neal Becker  wrote:
>
> I have tested kde/wayland on F32 but have hit a roadblock.  We are all 
> working from home and need to share screens.  Using google chrome, on X11 
> when I
> try to share an app window (which is my usual choice) there are no problems, 
> but on wayland only some of the windows are given as choices to share.  I 
> haven't
> found any particular pattern to which windows are listed (is it just from 
> certain desktops?)  I believe this isn't chrome specific (have to retest).
>
> Where can I report this issue?
>

Try here: 
https://bugs.kde.org/enter_bug.cgi?product=kwin&component=wayland-generic



-- 
真実はいつも一つ！/ 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

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

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 9/181 (x86_64)

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

ID: 659717  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/659717
ID: 659792  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/659792

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

ID: 659791  Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/659791
ID: 659793  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/659793
ID: 659822  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/659822
ID: 659827  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/659827
ID: 659848  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/659848
ID: 659870  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/659870
ID: 659889  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/659889

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

ID: 659718  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/659718
ID: 659737  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/659737
ID: 659764  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/659764
ID: 659777  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/659777
ID: 659797  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/659797
ID: 659800  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/659800
ID: 659814  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/659814
ID: 659826  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/659826
ID: 659851  Test: x86_64 universal upgrade_2_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/659851

Passed openQA tests: 163/181 (x86_64)

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

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

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

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
Used swap changed from 37 MiB to 28 MiB
Previous test data: https://openqa.fedoraproject.org/tests/658416#downloads
Current test data: https://openqa.fedoraproject.org/tests/659763#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
Used swap changed from 11 MiB to 8 MiB
System load changed from 1.13 to 1.47
Previous test data: https://openqa.fedoraproject.org/tests/658433#downloads
Current test data: https://openqa.fedoraproject.org/tests/659780#downloads

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

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.56 to 0.35
Previous test data: https://openqa.fedoraproject.org/tests/658450#downloads
Current test data: https://openqa.fedoraproject.org/tests/659797#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default@uefi: 
Mount /run/user/979 appeared since previous compose
Used swap changed from 22 MiB to 27 MiB
2 services(s) added since previous compose: user-runtime-dir@979.service, 
user@979.service
System load changed from 0.40 to 0.21
Previous test data: https://openqa.fedoraproject.org/tests/658453#downloads
Current test data: https://openqa.fedoraproject.org/tests/659800#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
Used swap changed from 20 MiB to 2 MiB
System load changed from 1.50 to 1.07
Average CPU usage changed from 49.31904762 to 34.24761905
Previous test data: https://openqa.fedor

Re: Removing a branch created by mistake

[Guido Aulisi]

Il giorno mer, 09/09/2020 alle 15.57 +0200, Jun Aruga ha scritto:
> On Wed, Sep 9, 2020 at 3:28 PM Mikolaj Izdebski 
> wrote:
> > On Wed, Sep 9, 2020 at 3:15 PM Jun Aruga  wrote:
> > > Yesterday I created the "wip/2.7" branch on modules/ruby dist-git
> > > repository by mistake. ;-<
> > > https://src.fedoraproject.org/modules/ruby/branches
> > > 
> > > I remember the current rule is we can not remove the branch we
> > > created, right?
> > 
> > The branch can be removed as long as commits in the branch are
> > reachable from another branch.
> > See https://pagure.io/fesco/issue/2340#comment-628281
> 
> OH! Great news for people who created a wrong branch like me!
> Thanks.

I think there's a hook that doesn't permit git branch -d, but I never
tried myself.

Guido
Ciao


> -- 
> Jun | He - His - Him
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Neal Becker]

I have tested kde/wayland on F32 but have hit a roadblock.  We are all
working from home and need to share screens.  Using google chrome, on X11
when I
try to share an app window (which is my usual choice) there are no
problems, but on wayland only some of the windows are given as choices to
share.  I haven't
found any particular pattern to which windows are listed (is it just from
certain desktops?)  I believe this isn't chrome specific (have to retest).

Where can I report this issue?

Thanks,
Neal

On Wed, Sep 9, 2020 at 9:46 AM José Abílio Matos  wrote:

> On Wednesday, September 9, 2020 4:30:54 AM WEST Tom Seewald wrote:
>
> > Has anyone compiled a (non-exhaustive) list of known issues that are
>
> > specific to KDE Plasma with Wayland?
>
> https://community.kde.org/Plasma/Wayland_Showstoppers
>
> --
>
> José Abílio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
*Those who don't understand recursion are doomed to repeat it*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Removing a branch created by mistake

[Jun Aruga]

On Wed, Sep 9, 2020 at 3:28 PM Mikolaj Izdebski  wrote:
>
> On Wed, Sep 9, 2020 at 3:15 PM Jun Aruga  wrote:
> >
> > Yesterday I created the "wip/2.7" branch on modules/ruby dist-git
> > repository by mistake. ;-<
> > https://src.fedoraproject.org/modules/ruby/branches
> >
> > I remember the current rule is we can not remove the branch we created, 
> > right?
>
> The branch can be removed as long as commits in the branch are
> reachable from another branch.
> See https://pagure.io/fesco/issue/2340#comment-628281

OH! Great news for people who created a wrong branch like me!
Thanks.

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

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

[Emmanuel Seyman]

* Fabio Valentini [09/09/2020 00:19] :
>
>  Can we please increase the bus / lottery
> factor (= 1) for Java package maintenance in fedora?

I know that at least one distribution bases its Java stack on Fedora's.
Perhaps someonce could contact their maintainers and encourage them to
contribute to their upstream?

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

[José Abílio Matos]

On Wednesday, September 9, 2020 4:30:54 AM WEST Tom Seewald wrote:
> Has anyone compiled a (non-exhaustive) list of known issues that are
> specific to KDE Plasma with Wayland?

https://community.kde.org/Plasma/Wayland_Showstoppers
-- 
José Abílio___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Björn Persson]

Guido Aulisi wrote:
> IMHO we could package only the JDK and let the user use Java software 
> directly from upstream.
> Usually upstream means Apache, which is a trusted source, and Java users are 
> smart enough to manage the Java packages.
> I usuali do so when using maven, hadoop, tomcat, etc.
> I think this solution could be valid for any other language, like php, 
> python: packaging only the base language and anything that is not available 
> in executable formats.

And how well does that scale?

As a sysadmin I don't normally need to know what language each program
is written in. I use language-specific tools only on programs I'm
developing, not on programs I merely use. Should I periodically run
cpan to check for Perl program updates, pip to check for Python program
updates, npm to check for Javascript program updates, gem to check for
Ruby program updates, and so on and so forth? And then manually check a
bunch of individual upstream websites for updates to programs that
aren't in those language-specific repositories either? No way! I run
"yum update" and get *all* the updates for my system.

Björn Persson


pgpmHQlIfF1QL.pgp
Description: OpenPGP digital signatur
___
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: Removing a branch created by mistake

[Mikolaj Izdebski]

On Wed, Sep 9, 2020 at 3:15 PM Jun Aruga  wrote:
>
> Yesterday I created the "wip/2.7" branch on modules/ruby dist-git
> repository by mistake. ;-<
> https://src.fedoraproject.org/modules/ruby/branches
>
> I remember the current rule is we can not remove the branch we created, right?

The branch can be removed as long as commits in the branch are
reachable from another branch.
See https://pagure.io/fesco/issue/2340#comment-628281

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

Fedora 33 compose report: 20200909.n.0 changes

[Fedora Rawhide Report]

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

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

Size of added packages:  0 B
Size of dropped packages:51.68 KiB
Size of upgraded packages:   1.16 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Mate raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Mate-armhfp-33-20200909.n.0-sda.raw.xz

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: python-asynctest-0.13.0-4.fc32
Summary: Enhance the standard unittest package with asyncio libraries testing
RPMs:python3-asynctest
Size:51.68 KiB


= UPGRADED PACKAGES =
Package:  kernel-5.8.6-301.fc33
Old package:  kernel-5.8.3-300.fc33
Summary:  The Linux kernel
RPMs: kernel kernel-core kernel-debug kernel-debug-core 
kernel-debug-devel kernel-debug-modules kernel-debug-modules-extra 
kernel-debug-modules-internal kernel-devel kernel-lpae kernel-lpae-core 
kernel-lpae-devel kernel-lpae-modules kernel-lpae-modules-extra 
kernel-lpae-modules-internal kernel-modules kernel-modules-extra 
kernel-modules-internal
Size: 477.63 MiB
Size change:  46.73 KiB
Changelog:
  * Wed Aug 26 2020 Justin M. Forbes  - 5.8.4-300
  - Linux v5.8.4

  * Thu Aug 27 2020 Justin M. Forbes  - 5.8.5-300
  - Linux v5.8.5

  * Thu Sep 03 2020 Justin M. Forbes  - 5.8.6-301
  - Linux v5.8.6
  - Fix CVE-2020-14385 (rhbz 1874800 1874811)
  - Move CONFIG_USB_XHCI_PCI_RENESAS to inline (rhbz 1874300)


Package:  kernel-headers-5.8.6-300.fc33
Old package:  kernel-headers-5.8.0-1.fc33
Summary:  Header files for the Linux kernel for use by glibc
RPMs: kernel-cross-headers kernel-headers
Size: 15.67 MiB
Size change:  1.27 KiB
Changelog:
  * Fri Aug 21 2020 Justin M. Forbes  - 5.8.3-300
  - Linux v5.8.3

  * Wed Aug 26 2020 Justin M. Forbes  - 5.8.4-300
  - Linux v5.8.4

  * Thu Sep 03 2020 Justin M. Forbes  - 5.8.6-300
  - Linux v5.8.6


Package:  lxsession-0.5.5-3.fc33
Old package:  lxsession-0.5.5-2.fc33.1
Summary:  Lightweight X11 session manager
RPMs: lxpolkit lxsession lxsession-edit
Size: 1.98 MiB
Size change:  125.95 KiB
Changelog:
  * Thu Aug 27 2020 Mamoru TASAKA  - 0.5.5-3
  - Disable LTO for now for workaround (bug 1872429)


Package:  nodejs-packaging-25-1.module_f33+10093+9fff376b
Old package:  nodejs-packaging-23-4.module_f33+9662+0b377b41
Summary:  RPM Macros and Utilities for Node.js Packaging
RPMs: nodejs-packaging
Size: 19.87 KiB
Size change:  214 B
Changelog:
  * Tue Sep 01 2020 Stephen Gallagher  - 24-1
  - Check node_modules_prod for bundled dependencies

  * Wed Sep 02 2020 Stephen Gallagher  - 25-1
  - Fix incorrect bundled library detection for Requires


Package:  nss-mdns-0.14.1-9.fc33
Old package:  nss-mdns-0.14.1-8.fc33
Summary:  glibc plugin for .local name resolution
RPMs: nss-mdns
Size: 276.16 KiB
Size change:  1.44 KiB
Changelog:
  * Wed Sep 02 2020 Zbigniew J??drzejewski-Szmek  - 0.14.1-9
  - Place 'mdns4_minimal' in /etc/nsswitch.conf after 'files' in 
/etc/nsswitch.conf,
so that it ends up before 'resolve' (#1867830)


Package:  qemu-2:5.1.0-5.fc33
Old package:  qemu-2:5.1.0-2.fc33
Summary:  QEMU is a FAST! processor emulator
RPMs: ivshmem-tools qemu qemu-audio-alsa qemu-audio-oss qemu-audio-pa 
qemu-audio-sdl qemu-block-curl qemu-block-dmg qemu-block-gluster 
qemu-block-iscsi qemu-block-nfs qemu-block-rbd qemu-block-ssh qemu-char-baum 
qemu-common qemu-device-display-qxl qemu-device-usb-redirect 
qemu-device-usb-smartcard qemu-guest-agent qemu-img qemu-kvm qemu-kvm-core 
qemu-system-aarch64 qemu-system-aarch64-core qemu-system-alpha 
qemu-system-alpha-core qemu-system-arm qemu-system-arm-core qemu-system-avr 
qemu-system-avr-core qemu-system-cris qemu-system-cris-core qemu-system-hppa 
qemu-system-hppa-core qemu-system-lm32 qemu-system-lm32-core qemu-system-m68k 
qemu-system-m68k-core qemu-system-microblaze qemu-system-microblaze-core 
qemu-system-mips qemu-system-mips-core qemu-system-moxie qemu-system-moxie-core 
qemu-system-nios2 qemu-system-nios2-core qemu-system-or1k qemu-system-or1k-core 
qemu-system-ppc qemu-system-ppc-core qemu-system-riscv qemu-system-riscv-core 
qemu-system-rx qemu-system-rx-core qemu-system-s390x qemu-system-s390x-core 
qemu-system-sh4 qemu-system-sh4-core qemu-system-sparc qemu-system-sparc-core 
qemu-system-tricore qemu-system-tricore-core qemu-system-unicore32 
qemu-system-unicore32-core qemu-system-x86 qemu-system-x86-core 
qemu-system-xtensa qemu-system-xtensa-core qemu-ui-curses qemu-ui-gtk 
qemu-ui-sdl qemu-ui-spice-app qemu-user qemu-user-binfmt qemu-user-static
Size: 626.78 MiB
Size change:  2.48 MiB
Changelog:
  * Tue Aug 1

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

[Julen Landa Alustiza]

20/9/9 05:30(e)an, Tom Seewald igorleak idatzi zuen:
> 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?
KDE spin is a blocker edition, so its default installation must pass our
release criterias.
https://fedoraproject.org/wiki/Fedora_Release_Criteria

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

-- 
Julen Landa Alustiza 
___
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

Removing a branch created by mistake

[Jun Aruga]

Yesterday I created the "wip/2.7" branch on modules/ruby dist-git
repository by mistake. ;-<
https://src.fedoraproject.org/modules/ruby/branches

I remember the current rule is we can not remove the branch we created, right?

Jun

-- 
Jun | He - His - Him
___
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?

[Miroslav Suchý]

Dne 08. 09. 20 v 10:51 Petr Pisar napsal(a):
>> 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.
> 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

The problem does not exists in default Mock installation because it use 
--isolation=nspawn and systemd-nspawn takes care
of creating /etc/localtime (as symlink to /usr/share/zoneinfo/*)

When you run Mock with --isolation=simple - this is what Koji does - then you 
can reproduce it.
The problem is that the file /etc/localtime is - on normal system - handled by 
systemd. And systemd is not present in
default chroot.

I created
  https://github.com/rpm-software-management/mock/pull/625
hopefully it should fix this issue.


-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys



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

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

[stan via devel]

On Tue, 8 Sep 2020 17:48:30 -0400
Matthew Miller  wrote:

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

Thanks for the info.
___
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: Gitlab Ask Me Anything - Sept 10th, 13:30 UTC

[Julen Landa Alustiza]

Hi,

> 
> That's my bad, I reviewed this and that looked good to me, but yeah
> maybe the wording could have been better even though CPE is part of
> Fedora afaik.
>  
> 
Yep, CPE is part of Fedora, but Fedora is not part of CPE, and has its
own change decission process. So my statement continues being valid:
Fedora did not decide anything, partly because there is no any proposal
to change anything yet.


-- 
Julen Landa Alustiza 
___
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: Gitlab Ask Me Anything - Sept 10th, 13:30 UTC

[Clement Verna]

On Wed, 9 Sep 2020 at 10:30, Julen Landa Alustiza 
wrote:

>
>
> 20/9/4 17:27(e)an, Aoife Moloney igorleak idatzi zuen:
>
> >
> > - A discussion on forum.gitlab.com at:
> >
> https://forum.gitlab.com/t/fedora-migration-to-gitlab-ask-me-anything-ama-thursday-september-10-2020/41971
> >
>
> Er, The Tell me more part on that post says: "On March 27, 2020, Fedora
> announced its decision to use GitLab as its git-forge (see announcement
> here 11). This announcement was met with mixed reactions because it
> meant a move away from Pagure, Fedora’s current home-grown git-forge tool."
>
> This is not true. CPE made (an announced) its decision, not Fedora.
> Fedora does not have yet a system wide change process to even discuss it.
>

That's my bad, I reviewed this and that looked good to me, but yeah maybe
the wording could have been better even though CPE is part of Fedora afaik.


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

Fedora-Cloud-31-20200909.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

[Peter Boy]

> Am 09.09.2020 um 11:28 schrieb Guido Aulisi :
> IMHO we could package only the JDK and let the user use Java software 
> directly from upstream.
> Usually upstream means Apache, which is a trusted source, and Java users are 
> smart enough to manage the Java packages.
> I usuali do so when using maven, hadoop, tomcat, etc.

Sorry, I think you negligently underestimate the importance of Java packages. 
Even for a 'simple' Tomcat you need system management infrastructure, log file 
management, consistency with other programs and libraries, update management 
and much more. Neither a download of an Apache Binary nor maven can help.

Maven is great if you need libraries for development, and perhaps for updating 
individual libraries in a running system. 

We urgently need a solution for the listed problems. So in short Manpower.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-32-20200909.0 compose check report

[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-20200908.0):

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

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

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

[Guido Aulisi]

Hi,

> Il giorno 9 set 2020, alle ore 00:19, Fabio Valentini  
> ha scritto:
> 
> 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)?

… snip

IMHO we could package only the JDK and let the user use Java software directly 
from upstream.
Usually upstream means Apache, which is a trusted source, and Java users are 
smart enough to manage the Java packages.
I usuali do so when using maven, hadoop, tomcat, etc.
I think this solution could be valid for any other language, like php, python: 
packaging only the base language and anything that is not available in 
executable formats.

This is my personal opinion, your effort in supporting such huge Java stack has 
always been appreciated, also because I find it difficult packaging Java 
software.

Ciao

Guido
FAS: tartina
___
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

Schedule for Wednesday's FESCo Meeting (2020-09-09)

[Zbigniew Jędrzejewski-Szmek]

Following is the list of topics that will be discussed in the
FESCo meeting Wednesday at 14:00UTC in #fedora-meeting-2 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2020-09-09 14:00 UTC'


Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

#2416 Update 3rd party repo policy
https://pagure.io/fesco/issue/2416
APPROVED (+6, 0, 0)

= Followups =

= New business =

#2470 F34 Self-Contained Change: Reduce installation media size by
  improving the compression ratio of SquashFS filesystem
https://pagure.io/fesco/issue/2470

= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 
___
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: Orphaned packages looking for new maintainers

[Michal Fabik]

On 9/7/20 9:57 AM, Miro Hrončok wrote:

container-exception-logger abrt-sig, ekulik, mmarusak,  2 weeks ago
  msuchy, orphan
satyr abrt-sig, ekulik, mgrabovs, 2 weeks ago
parent



Hi, I'm taking these two.

--
Michal Fabík
Associate Software Engineer
Red Hat - Core Services - ABRT
___
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: Gitlab Ask Me Anything - Sept 10th, 13:30 UTC

[Julen Landa Alustiza]

20/9/4 17:27(e)an, Aoife Moloney igorleak idatzi zuen:

> 
> - A discussion on forum.gitlab.com at:
> https://forum.gitlab.com/t/fedora-migration-to-gitlab-ask-me-anything-ama-thursday-september-10-2020/41971
> 

Er, The Tell me more part on that post says: "On March 27, 2020, Fedora
announced its decision to use GitLab as its git-forge (see announcement
here 11). This announcement was met with mixed reactions because it
meant a move away from Pagure, Fedora’s current home-grown git-forge tool."

This is not true. CPE made (an announced) its decision, not Fedora.
Fedora does not have yet a system wide change process to even discuss it.

-- 
Julen Landa Alustiza 
___
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)

[José Abílio Matos]

On Tuesday, September 8, 2020 5:32:30 PM WEST 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.

The main issue I have with wayland on kde is the support for the second 
screen. In the previous laptop it did not detect the second screen while with 
laptop the second screen is detected and show but I can not see its content.

FWIW in both cases gnome on wayland had not these issues.

If this issues are fixed I will gladly change, there are several features that 
I like there like the support for per screen scale multiplier.
-- 
José Abílio___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Vít Ondruch]

Generally, I would appreciate if the proposal was more readable to
casual Fedora user/developer. I don't think there is clearly described
the current state and what is going to be changed. Also, there is a lot
of unclear terminology, e.g. I don't have idea what are "LSM hooks".
"Migrate users to using ''selinux=0''" probably refers to kernel command
line, but why it is not mentioned in the summary.


Thanks


Vít


Dne 08. 09. 20 v 17:28 Ben Cotton napsal(a):
> 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 ''se

Re: Gitlab Ask Me Anything - Sept 10th, 13:30 UTC

[Pierre-Yves Chibon]

On Fri, Sep 04, 2020 at 04:27:55PM +0100, Aoife Moloney wrote:
> Good Morning folks,
> 
> As you likely remember, a little while ago now, was announced the decision to
> move dist-git to a gitlab instance. This decision was the results of different
> factors which included a wish for Red Hat to have a consistent tooling and
> experience across the different distribution it works on or with, meaning:
> RHEL, CentOS-Stream, CentOS Linux and Fedora.
> 
> Since then, a number of technical requirements needed to use gitlab in Fedora,
> were gathered and a ticket was opened at gitlab to track them [1] but up until
> now the progress on the Fedora side has been fairly slow. This is mostly due 
> to
> the feedback from Fedora that followed this decision, leading to a focus on 
> the
> first two distributions in the list above.
> 
> However, in order to progress the evaluation of gitlab, we have organized an
> "Ask Me Anything" (AMA) session with the gitlab folks on Thursday September 
> 10th
> 2020, at 13:30 UTC on #fedora-meeting-1 on irc.freenode.net.
> The idea is to have an open floor for anyone in the community to discuss with
> GitLab the technical merits that GitLab has, as well as the requirements we, 
> the
> Fedora community, have.
> 
> In order for this session to be productive, we believe that it may be wise to
> start gathering questions to GitLab early on, so they can also look into them
> and prepare their answers (I'm sure we all prefer to have actual answers 
> rather
> than: "hm, I don't know, let me check and I'll get back to you on this"). Of
> course, we will still be able to ask question at the last minute or even 
> during
> the session.
> Gathering them as early as possible is just a way for GitLab to see what
> interests us, who may be the right persons to attend this session and overall 
> to
> make this hour as productive as possible.
> 
> 
> So there are two ways for you to submit your questions to the GitLab folks on 
> a
> potential deployment of GitLab as a front-end to our dist-git (ie:
> src.fedoraproject.org):
> 
> - A public hackmd document:
> https://hackmd.io/RW8HahOeR7OJPON1dwuo3w#
> Underneath each questions you will also be able to vote (simply add a ``+1`` 
> to
> the ``Votes:`` line), the most popular questions will be asked first.
> Since this document is public, please be mindful of what previous
> people entered.
> 
> - A discussion on forum.gitlab.com at:
> https://forum.gitlab.com/t/fedora-migration-to-gitlab-ask-me-anything-ama-thursday-september-10-2020/41971


Reminder: This is tomorrow, if you have questions you would like to ask, please
add them today! :)

Also, feel free to vote on the questions you would like to see answered first so
we can start with them during the AMA.



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

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 08 September 2020 at 23:55, Michel Alexandre Salim wrote:
> 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)

One solution would be to name the main package "slime" and make it
archful and have it produce only one noarch subpackage called
"emacs-slime" (%package -n emacs-slime). See utf8cpp for an example
of how it can be done:
https://src.fedoraproject.org/rpms/utf8cpp/blob/master/f/utf8cpp.spec
utf8cpp is a header-only devel package, but I wanted to run its
testsuite on all arches.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org