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

[Robbie Harwood]

Mikolaj Izdebski  writes:

> On Thu, Sep 10, 2020 at 3:46 PM Alexander Scheel  wrote:
>>
>> Hi Joe,
>>
>> On Thu, Sep 10, 2020 at 8:52 AM Joe Orton  wrote:
>> >
>> > Hi all,
>> >
>> > I'm writing as the Red Hat engineering manager responsible for Maven and
>> > Ant in RHEL, and on behalf of Mikolaj Izdebski and Marian Koncek from my
>> > team.  I want to give a broad response to some of the points here:
>> >
>> > 1.  The team has two missions in Fedora:
>> >
>> > a) We deliver, maintain and support Ant and Maven in Fedora. Our aim is
>> > to provide developers with the most popular Java build systems which are
>> > reviewed, tested, and updated through the release lifecycle.
>> >
>> > b) We design, develop and document tooling that enables anyone to
>> > package Java software with a simple, efficient and scalable process. We
>> > are also active members of Java SIG, collaborating on complex changes
>> > and guiding new contributors.
>> >
>> > 2.  We are committed to maintaining the Ant and Maven modules in
>> > Fedora.  We have always expected to make them available as default
>> > streams and in the buildroot so they can be available and consumed by
>> > non-modular packages, but we completely respect the decisions of FESCo
>> > to disallow default streams and of other contributors to adopt and
>> > maintain the non-modular packages.  We are not going to promise to
>> > commit time and resources to maintain the non-modular packages.
>>
>> As a reminder (as in my RHEL devel-list reply): there are no default
>> module streams in Fedora. There is also no Ursa Major/Prime, so were
>> they to exist, there would still be no way for non-modular packages to
>> use them.
>
> There are default module streams in Fedora 31.

Fedora 31 is most likely EOL in about two months.  I really hope you're
not targeting your future development against it.

Thanks,
--Robbie


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

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

[Mario Torre]

I think there's a difference between libraries and applications though.

I for one think that not having Eclipse packaged in Fedora/RHEL etc.. would
be a big loss, the same goes for Mission Control which we maintain

On Wed, Sep 9, 2020 at 5:00 PM Aleksandar Kurtakov 
wrote:
>
>
>
> 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



-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH https://www.redhat.com;9704 A60C B4BE A8B8 0F30
9205 5D7E 4952 3F65 7898
___
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)

[Ben Cotton]

On Thu, Sep 10, 2020 at 10:54 AM Vitaly Zaitsev via devel
 wrote:
>
> On 10.09.2020 16:10, Aleksandar Kurtakov wrote:
> > Flatpak is way better suited for our use case and in addition gives us
> > access to a way bigger install base.
>
> Flathub is a third-party repository and not related to Fedora at all.
>
Flat*hub* is third party, but we have first-party flatpaks at
registry.fedoraproject.org. The flatpak package adds it as a remote
via /usr/lib/systemd/system/flatpak-add-fedora-repos.service

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
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 Thu, Sep 10, 2020 at 9:36 am, Kamil Paral  wrote:
On Thu, Sep 10, 2020 at 8:54 AM Mikhail Gavrilov 
 wrote:

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


I see the same error.


I'm a bit concerned that two different people are seeing this. I don't 
think we have any scriptlets tha writes to /etc/nsswitch.conf or 
/etc/authselect/nsswitch.conf on its own. But maybe, for non-live 
installs, that could happen if the systemd RPM gets installed before 
the authselect RPM? Then systemd would think /etc/nsswitch.conf is not 
managed by authselect. Hm


Anyway, if you can find a way to get to this state from a clean 
install, without touching those files manually, then please do report a 
bug. That shouldn't be happening.


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

[Robbie Harwood]

Ondrej Mosnacek  writes:

> James Cassell wrote:
>> Ben Cotton wrote:
>>
>>> https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
>>>
>>> == Summary ==
>>> Remove support for SELinux runtime disable so that the LSM hooks can
>>> be hardened via read-only-after-initialization protections.
>>>
>>> Migrate users to using ''selinux=0'' if they want to disable SELinux.
>>
>> I like the proposal. A few thoughts and questions, though:
>>
>> 1. I think systems with SELINUX=disabled without selinux=0 should
>> hard fail very loudly.
>
> That's an interesting opinion... It would be easier and more direct to
> do it that way, but we are worried that users would complain that
> their SELINUX=disabled setup is suddenly broken and they need to mess
> with the bootloader to get a working system again. (I don't know that
> much about real-time systems, so feel free to correct/enlighten me
> here.) That's why we try to make sure that things keep working
> more-or-less the same as before.

Please correct me if I'm wrong, but *aren't* those systems broken?  That
is, if an admin sets selinux=disabled on a system after this change has
(hypothetically) gone through, won't they have a system in which selinux
isn't disabled?  Or is there going to be migration logic in perpetuity?

Thanks,
--Robbie


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

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

[Neal Gompa]

On Thu, Sep 10, 2020 at 1:30 PM Daniel P. Berrangé  wrote:
>
> On Thu, Sep 10, 2020 at 04:03:46PM +0200, Petr Pisar wrote:
> > On Thu, Sep 10, 2020 at 02:35:13PM +0100, Daniel P. Berrangé wrote:
> > > On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote:
> > >
> > > > 4.  The benefit we want to preserve from modules is to maintain packages
> > > > with varying expectation of quality, specifically separating the
> > > > build-time-only vs runtime dependencies.  e.g. in that case that a web
> > > > server like Eclipse Jetty is required as a dep for testing another
> > > > component during the build, we want to be able to use and build that
> > > > component, without being indefinitely on the hook for security errata.
> > > > (The build dependency tree is particularly complex for Maven and
> > > > involves many examples of packages with frequent and high severity
> > > > vulnerabilies)
> > >
> > > What are you doing different in terms of supporting deps in the module
> > > that reduces the security errata burden, compared to non-modular builds ?
> > >
> > > It feels like if we have some policy that is creating unsustainable
> > > maint burden wrt non-modular packaging, we should re-examine this
> > > policy rather than trying to workaround it by going modular, which
> > > creates a different kind of maint burden.
> > >
> > In non-modular Fedora all packages that we have in Fedora build system 
> > (Koji)
> > are tagged into Fedora repositories and made available to all users on their
> > computers for any purpose. That implies that all packages in Fedora build 
> > system
> > must be fully supported including addressing all security issues.
> >
> > In modular Fedora that's (effectively) not true. Packages that only exist
> > for the sake of building other packages (i.e. build-only dependencies) can 
> > be
> > retained in the Fedora build system and never left it. That means those
> > packages are never made available to Fedora users and thus a service level 
> > for
> > them is significantly lower. E.g. no security fixes, not bug fixes, no
> > integration, not tests, no API/ABI stability. The only requirement is that
> > they can be built and used for building other packages.
>
> So conceptually, one way we can solve this problem by implementing a way
> to mark certain non-modular RPMs as "build root only" packages and thus
> composing them into a separate "build root" yum repo, that is not enabled
> by default except in the build system.
>

This is an anti-feature and I personally will not support any effort
to offer this in Fedora. That is just one step removed from not
shipping it at all to people, and I don't want it to be easy for us to
make that kind of decision.

It *barely* makes sense in RHEL and CentOS and has massively screwed
up things for CentOS SIGs (which are, with the exception of the Virt
SIG, all Red Hat teams) by making it impossible for the *projects* to
build their stuff on CentOS.

> Modularity is being used because it is the only solution that is available
> today, not because it is a good/desired solution.
>

Whether modularity is a good or bad solution is beside the point. The
problem here is that there is effectively zero official work in Fedora
by the numerous Java teams at Red Hat. With how much Red Hat is
involved in the Java ecosystem, Fedora should be a freaking paradise
for Java users and developers. It's almost the worst experience by a
fair margin due to lack of development and improvement in the tooling
and infrastructure to support the Java ecosystem.

Even *Rust* is a better experience than Java, and Rust is mostly
managed by Igor (with tiny bits from me, Josh, and a few others).




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

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

[Fabio Valentini]

On Thu, Sep 10, 2020 at 4:23 PM Mikolaj Izdebski  wrote:
>
> On Thu, Sep 10, 2020 at 3:29 PM Dominik 'Rathann' Mierzejewski
>  wrote:
> >
> > On Thursday, 10 September 2020 at 14:50, Joe Orton wrote:
> > [...]
> > > 1.  The team has two missions in Fedora:
> > >
> > > a) We deliver, maintain and support Ant and Maven in Fedora. Our aim
> > > is to provide developers with the most popular Java build systems
> > > which are reviewed, tested, and updated through the release
> > > lifecycle.

You deliver Ant and Maven to nobody. The modules are essentially
unused and / or useless.

> > > b) We design, develop and document tooling that enables anyone to
> > > package Java software with a simple, efficient and scalable process.
> > > We are also active members of Java SIG, collaborating on complex
> > > changes and guiding new contributors.

I don't know which Java SIG you're talking about, because in the past
two years, I've seen none of this.

> > > 2.  We are committed to maintaining the Ant and Maven modules in
> > > Fedora.  We have always expected to make them available as default
> > > streams and in the buildroot so they can be available and consumed by
> > > non-modular packages, but we completely respect the decisions of FESCo
> > > to disallow default streams and of other contributors to adopt and
> > > maintain the non-modular packages.  We are not going to promise to
> > > commit time and resources to maintain the non-modular packages.

So, you respect FESCo decisions but you choose to ignore the
consequences? m'kay.

> > Points 1b and 2 mean that nobody can consume your packages for
> > maintaining non-modular Java packages, which raises the bar for
> > maintaining Java packages considerably.
>
> Javapackages is the main project that provides Java packaging tooling.
> I am maintaining it both upstream [1] and in Fedora, also as ursine
> package [2].

It's also the *only* non-modular package you still maintain.
However, the only changes you made in the past two years were 1)
enabling xmvn-javadoc upon my request and 2) switching the default
Java to OpenJDK 11 opon Jiri Vanek's request ...

> > [...]
> > > 4.  The benefit we want to preserve from modules is to maintain
> > > packages with varying expectation of quality, specifically separating
> > > the build-time-only vs runtime dependencies.  e.g. in that case that a
> > > web server like Eclipse Jetty is required as a dep for testing another
> > > component during the build, we want to be able to use and build that
> > > component, without being indefinitely on the hook for security
> > > errata.  (The build dependency tree is particularly complex for Maven
> > > and involves many examples of packages with frequent and high severity
> > > vulnerabilies)

This is one of the *worst* aspects of Modularity - being able to
"hide" implementation details from re-use by others.
I would not see this as a benefit, but as a big issue when it comes to
the bigger distribution and collaboration context.

> > On one hand, that's understandable, but you're effectively maintaining
> > those packages anyway. And I don't see any reason why you couldn't do
> > that in the traditional non-modular way, which makes it easier for
> > others to step in and co-maintain. I'm not sure what you mean by
> > "indefinitely on the hook for security errata". Can you elaborate?
>
> All Fedora packages shipped to users are expected to be high-quality
> and well maintained, which may impose a very significant burden on
> maintainers.
> But for build-only packages (packages are used only during build, not
> shipped to users), many of package maintainer responsibilities [3] can
> be reduced to almost nothing. For example "manage security issues"
> means triaging them and fixing only very small subset of them (since
> user can't install the packages, most of vulnerabilities are not
> exploitable), "deal with reported bugs" means closing them NOTABUG as
> users can't possibly install the package in a "supported" way,  "track
> dependency issues" duty is reduced as nothing non-modular can depend
> on the package, and so on.

Well, I can't even tell where (or if) you've been working on this
stuff at all for the past 10 months.
I find no commits in the modules/javapackages-tools module, nor in
javapackages-tools-201902 branches, nor in the maven-3.6 branches more
recently than 10 months ago.
The most recent builds I can find for you and mkoncek are still in 2019 (!).

So please tell me, am I imagining things, or have you actually not
contributed anything to fedora packages in the last 10 months?

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

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

[Daniel P . Berrangé]

On Thu, Sep 10, 2020 at 04:03:46PM +0200, Petr Pisar wrote:
> On Thu, Sep 10, 2020 at 02:35:13PM +0100, Daniel P. Berrangé wrote:
> > On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote:
> > 
> > > 4.  The benefit we want to preserve from modules is to maintain packages 
> > > with varying expectation of quality, specifically separating the 
> > > build-time-only vs runtime dependencies.  e.g. in that case that a web 
> > > server like Eclipse Jetty is required as a dep for testing another 
> > > component during the build, we want to be able to use and build that 
> > > component, without being indefinitely on the hook for security errata.  
> > > (The build dependency tree is particularly complex for Maven and 
> > > involves many examples of packages with frequent and high severity 
> > > vulnerabilies)
> > 
> > What are you doing different in terms of supporting deps in the module
> > that reduces the security errata burden, compared to non-modular builds ?
> > 
> > It feels like if we have some policy that is creating unsustainable
> > maint burden wrt non-modular packaging, we should re-examine this
> > policy rather than trying to workaround it by going modular, which
> > creates a different kind of maint burden.
> > 
> In non-modular Fedora all packages that we have in Fedora build system (Koji)
> are tagged into Fedora repositories and made available to all users on their
> computers for any purpose. That implies that all packages in Fedora build 
> system
> must be fully supported including addressing all security issues.
> 
> In modular Fedora that's (effectively) not true. Packages that only exist
> for the sake of building other packages (i.e. build-only dependencies) can be
> retained in the Fedora build system and never left it. That means those
> packages are never made available to Fedora users and thus a service level for
> them is significantly lower. E.g. no security fixes, not bug fixes, no
> integration, not tests, no API/ABI stability. The only requirement is that
> they can be built and used for building other packages.

So conceptually, one way we can solve this problem by implementing a way
to mark certain non-modular RPMs as "build root only" packages and thus
composing them into a separate "build root" yum repo, that is not enabled
by default except in the build system.

Modularity is being used because it is the only solution that is available
today, not because it is a good/desired solution.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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]

Ben,

Can Fedora first-party flatpaks be built from unsigned, untrusted
content outside of the Fedora Repos? Or can they only be built from
content otherwise already present in Fedora? Just curious what
benefits a first-party flatpak has versus an upstream one.

AFAIK, the last Fedora Container docs said that all Container content
must be pulled from Fedora Repos, and therefore was left holding a
bunch of RPMs anyways.


- A

On Thu, Sep 10, 2020 at 11:38 AM Ben Cotton  wrote:
>
> On Thu, Sep 10, 2020 at 10:54 AM Vitaly Zaitsev via devel
>  wrote:
> >
> > On 10.09.2020 16:10, Aleksandar Kurtakov wrote:
> > > Flatpak is way better suited for our use case and in addition gives us
> > > access to a way bigger install base.
> >
> > Flathub is a third-party repository and not related to Fedora at all.
> >
> Flat*hub* is third party, but we have first-party flatpaks at
> registry.fedoraproject.org. The flatpak package adds it as a remote
> via /usr/lib/systemd/system/flatpak-add-fedora-repos.service
>
> --
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> 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)

[Ondrej Mosnacek]

On Thu, Sep 10, 2020 at 5:27 PM Silvia Sánchez  wrote:
> Ondrej,
>
> You need to install Kwin Wayland and another package that will provide the 
> backend.

It seems all the necessary packages were pulled in as dependencies via
plasma-workspace-wayland.

$ sudo dnf info --installed *wayland* | grep Name
Name : kf5-kwayland
Name : kwayland-integration
Name : kwin-wayland
Name : libwayland-client
Name : libwayland-client
Name : libwayland-cursor
Name : libwayland-cursor
Name : libwayland-egl
Name : libwayland-egl
Name : libwayland-server
Name : libwayland-server
Name : plasma-workspace-wayland
Name : qt5-qtwayland
Name : qt5-qtwayland-devel
Name : xorg-x11-server-Xwayland

Looking at the available but not installed packages that match
*wayland* I don't see any that would be relevant.

> My experience wasn't the best, several apps crashed, effects stuttered or 
> were very slow, even typing felt slower.  But at least my desktop looked 
> normal.
> One comment:  the logging out issue is not because of Wayland.  I have the 
> same with Xorg, and there are several bug reports pointing to the same issue.

Oh, thanks for the info! So I guess the only Wayland issue for me so
far is the messed up resolution/screen settings. Once I get past that
I'll probably see the "normal" known issues, too :)

>
> Kind regards,
> Lailah
>
>
>
> On Thu, 10 Sep 2020 at 12:24, Ondrej Mosnacek  wrote:
>>
>> On Tue, Sep 8, 2020 at 5:30 PM 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.
>>
>> So yesterday I tried to log in to the KDE Plasma + Wayland session on
>> my laptop (F32) and the experience was unfortunately quite horrible...
>>
>> 1. When I logged out of the X session, switched to Wayland on the
>> login screen, and logged in, I only got a black screen. After I
>> rebooted, I managed to login to the Wayland session (I have automatic
>> login after boot enabled), but...
>> 2. The desktop was all squeezed into a small 1024x786 rectangle in the
>> upper left corner of the screen (my screen is 1920x1080). So I opened
>> system settings to change the resolution, but...
>> 3. The screen settings were showing "manufacturer_TODO" and
>> "model_TODO" as the name of the screen and the only resolution offered
>> was 1024x786.
>> 4. The window layout of my KDE session was not preserved (I think even
>> the distribution of windows to activities was lost). But I probably
>> shouldn't expect this to work...
>> 5. Logging out of the Wayland session gave me just a black screen with
>> blinking cursor, no login screen.
>>
>> Reading the other posts in this thread it seems I'm the only one
>> experiencing such serious breakage (maybe except 4., which is
>> understandable), so I'm wondering if I did something wrong... I simply
>> installed plasma-workspace-wayland, logged out, and then logged 

GNOME 3.37.92 megaupdate landing in testing and tracker3 coming

[Kalev Lember]

Hi all,

Just a quick heads up that the 3.37.92 megaupdate is all lined up and
queued to F33 updates-testing:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-7f57486c95

This is likely not going to be pushed through the beta freeze, so next
week I'll prepare a final .0 release to replace/obsolete the .92 bodhi
update.

I'll talk to QA and see how they feel about pulling the .92 update
through the beta freeze now that the beta is delayed anyway, but I think
the base scenario is that we ship beta without this.

The megaupdate also includes new parallel installable tracker3 and
tracker3-miners packages. The naming here was difficult but in the end
we ended up keeping tracker 2 in the existing 'tracker' package and
creating a new 'tracker3' package that's parallel installable with the
old one. This makes it easy to port packages over one by one. In F34
perhaps we can drop tracker 2 and get rid of the separate tracker3
package; let's see how fast app porting goes.

In default Fedora Workstation, we'll have both 'tracker' and 'tracker3'
installed by default, but only tracker3 FS miners are going to be
started at session login; tracker 2 miners are autostarted when an app
requires them. Everything in the default install is ported to tracker3,
with the exception of gnome-photos where the upstream port didn't get
ready in time.

(I've cross posted this to devel and desktop lists both.)

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

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

[Michael Catanzaro]

On Thu, Sep 10, 2020 at 9:24 am, Vít Ondruch  
wrote:

Hi Michael,

Could you please provide more details? This is content of my 
nsswitch.conf:



~~~

$ grep mdns4_minimal /etc/authselect/user-nsswitch.conf
hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
~~~


How that happened? From what version of what package it happened? Why
should I do some changes manually and they are not handled 
automatically?


You're completely missing resolved from your hosts line, so you'll get 
legacy name resolution behavior via nss-dns (which is what Ubuntu does).


There were multiple different bugs here, so it's a bit hard to keep 
track of them all. systemd package was being too cautious about 
deleting /etc/resolv.conf, so some users wound up with /etc/resolv.conf 
managed by NetworkManager even though systemd is running, which was not 
what I had intended. Plus we originally planned for resolved to handle 
mDNS resolution instead of avahi, but we discovered that it doesn't 
work as expected. We have hacky scripts in the systemd and nss-mdns 
packages to manage the hosts line, plus it's managed by authselect 
itself. They all have to agree on expected configuration and it's all a 
bit fragile. The systemd package script is careful to only touch this 
line if the order matches the previous Fedora default configuration, so 
we have to choose between automatically reordering the nss modules to 
fix this for users of F33 pre-beta, vs. clobbering intentional 
configuration changes for users who actually wanted the hosts line to 
be different. If this had reached stable releases, then we'd really 
have to do that clobbering, but it didn't, so seems best to be more 
conservative here. These scripts would not be needed if we could add 
systemd nss modules and nss-mdns to the nsswitch.conf provided by the 
glibc package.


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

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

[Chris Murphy]

On Thu, Sep 10, 2020 at 9:23 AM Michael Catanzaro  wrote:
>
>
> On Thu, Sep 10, 2020 at 11:09 am, Mikhail Gavrilov
>  wrote:
> > # 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.
>
> Did you edit /etc/nsswitch.conf or /etc/authselect/nsswitch.conf
> manually without using authselect? If so, that was your mistake. But if
> not, and if you can figure out how to reproduce this condition from a
> fresh install, then it must be a Fedora bug that needs to be reported.

# dnf provides /etc/authselect/nsswitch.conf
Error: No Matches found

# dnf provides /etc/nsswitch.conf
glibc-2.32-1.fc33.x86_64 : The GNU libc libraries

I made the huge mistake of hand editing /etc/nsswitch.conf while
testing some of this, and that change instantly metastasized. I could
not undo it. Reinstalling glibc didn't fix it. And it busted
networking in a way I couldn't fix without a rollback of system root
to two weeks prior.

Regardless of how or why these files can get messed up, that it isn't
easily repairable or resettable to defaults is a much bigger risk than
any bugs. Of course the user should not be stubborn (cmurf raises
hand, points at himself), and there should be no bugs, but they're
still gonna happen! Even a 9 step reset recipe is better than just
being screwed.

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

Review swap

[Jerry James]

Version 2.7.1 of ocaml-dune is out, with a bug fix that I want.
However, upstream has started unbundling other projects.  They were
bundled in the first place so that dune could be built with nothing
more than the OCaml compiler.  However, upstream has now unbundled
csexp, and has hinted that more unbundling is to come in future
versions.

This is awkward, because csexp uses dune as its build system, thereby
creating a circular dependency.  Fortunately, csexp is a very small,
simple library, so I have taken a stab and building it without dune:

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

Who would like to swap reviews?
-- 
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: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[Ondrej Mosnacek]

On Thu, Sep 10, 2020 at 12:58 PM Neal Becker  wrote:
> Might be interesting to try logging in as a new user to see if some older kde 
> settings are messing things up.

That's definitely possible... However this is a single-user machine
and I don't really feel like creating a new user :)

If I find some time I'll try it on my other laptop and/or dig deeper...

>
> On Thu, Sep 10, 2020 at 6:24 AM Ondrej Mosnacek  wrote:
>>
>> On Tue, Sep 8, 2020 at 5:30 PM 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.
>>
>> So yesterday I tried to log in to the KDE Plasma + Wayland session on
>> my laptop (F32) and the experience was unfortunately quite horrible...
>>
>> 1. When I logged out of the X session, switched to Wayland on the
>> login screen, and logged in, I only got a black screen. After I
>> rebooted, I managed to login to the Wayland session (I have automatic
>> login after boot enabled), but...
>> 2. The desktop was all squeezed into a small 1024x786 rectangle in the
>> upper left corner of the screen (my screen is 1920x1080). So I opened
>> system settings to change the resolution, but...
>> 3. The screen settings were showing "manufacturer_TODO" and
>> "model_TODO" as the name of the screen and the only resolution offered
>> was 1024x786.
>> 4. The window layout of my KDE session was not preserved (I think even
>> the distribution of windows to activities was lost). But I probably
>> shouldn't expect this to work...
>> 5. Logging out of the Wayland session gave me just a black screen with
>> blinking cursor, no login screen.
>>
>> Reading the other posts in this thread it seems I'm the only one
>> experiencing such serious breakage (maybe except 4., which is
>> understandable), so I'm wondering if I did something wrong... I simply
>> installed plasma-workspace-wayland, logged out, and then logged in
>> selecting "Plasma (Wayland) (Wayland)" from the session dropdown.
>>
>> --
>> Ondrej Mosnacek
>> Software Engineer, Platform Security - SELinux kernel
>> Red Hat, Inc.
>> ___
>> 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: 
> 

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

[Zdenek Kabelac]

Dne 10. 09. 20 v 17:53 Michael Catanzaro napsal(a):

On Thu, Sep 10, 2020 at 9:36 am, Kamil Paral  wrote:
On Thu, Sep 10, 2020 at 8:54 AM Mikhail Gavrilov 
 wrote:

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


I see the same error.


I'm a bit concerned that two different people are seeing this. I don't think 


Well count me as 3rd. - I've seen this to happen on upgrade from fc32 rawhide
to fc34 rawhide.

It's been basically horrible experience reported here:

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

so I've originally accounted zero length nsswitch.conf issue to this problem,
but it most like relates to this thread (and yeah - it took me a while
to figure out how to make networking DNS running properly again,
but nothing compered with restoration of crashed DNF transaction...

Regards

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

[Christopher Engelhard]

On 10.09.20 17:53, Michael Catanzaro wrote:
> I'm a bit concerned that two different people are seeing this. I don't
> think we have any scriptlets tha writes to /etc/nsswitch.conf or
> /etc/authselect/nsswitch.conf on its own. But maybe, for non-live
> installs, that could happen if the systemd RPM gets installed before the
> authselect RPM? Then systemd would think /etc/nsswitch.conf is not
> managed by authselect. Hm
> 
> Anyway, if you can find a way to get to this state from a clean install,
> without touching those files manually, then please do report a bug. That
> shouldn't be happening.

I have this same issue on a system that was installed as F33 rawhide &
is now F34 rawhide. I never touched those files, nor did I do anything
that should have caused anything else to change them.

I'll file a bug - would this be against authselect or  systemd?

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

[Matthew Miller]

On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote:
> maintain the non-modular packages.  We are not going to promise to 
> commit time and resources to maintain the non-modular packages.

Joe, here's a part I hope you can help me understand better. Modularity
isn't an entirely new packaging technology. It's simply a layer on top of
RPM. Modules are made out of RPMs, and by design, their specfiles are
exactly the same as RPMs which happen to be grouped into modules.

I understand that it's nice to have exactly one workflow, but it doesn't
seem like it's actually all that much extra effort on top of what you
already have to do to maintain the module to make a non-modular build. Is
this something where triggering the non-modular builds in the same way you
build the module would make a difference?

Or is there something else that I'm not seeing?

-- 
Matthew Miller

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

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

[Neal Gompa]

On Thu, Sep 10, 2020 at 2:04 PM Daniel P. Berrangé  wrote:
>
> On Thu, Sep 10, 2020 at 01:37:41PM -0400, Neal Gompa wrote:
> > On Thu, Sep 10, 2020 at 1:30 PM Daniel P. Berrangé  
> > wrote:
> > >
> > > On Thu, Sep 10, 2020 at 04:03:46PM +0200, Petr Pisar wrote:
> > > > On Thu, Sep 10, 2020 at 02:35:13PM +0100, Daniel P. Berrangé wrote:
> > > > > On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote:
> > > > >
> > > > > > 4.  The benefit we want to preserve from modules is to maintain 
> > > > > > packages
> > > > > > with varying expectation of quality, specifically separating the
> > > > > > build-time-only vs runtime dependencies.  e.g. in that case that a 
> > > > > > web
> > > > > > server like Eclipse Jetty is required as a dep for testing another
> > > > > > component during the build, we want to be able to use and build that
> > > > > > component, without being indefinitely on the hook for security 
> > > > > > errata.
> > > > > > (The build dependency tree is particularly complex for Maven and
> > > > > > involves many examples of packages with frequent and high severity
> > > > > > vulnerabilies)
> > > > >
> > > > > What are you doing different in terms of supporting deps in the module
> > > > > that reduces the security errata burden, compared to non-modular 
> > > > > builds ?
> > > > >
> > > > > It feels like if we have some policy that is creating unsustainable
> > > > > maint burden wrt non-modular packaging, we should re-examine this
> > > > > policy rather than trying to workaround it by going modular, which
> > > > > creates a different kind of maint burden.
> > > > >
> > > > In non-modular Fedora all packages that we have in Fedora build system 
> > > > (Koji)
> > > > are tagged into Fedora repositories and made available to all users on 
> > > > their
> > > > computers for any purpose. That implies that all packages in Fedora 
> > > > build system
> > > > must be fully supported including addressing all security issues.
> > > >
> > > > In modular Fedora that's (effectively) not true. Packages that only 
> > > > exist
> > > > for the sake of building other packages (i.e. build-only dependencies) 
> > > > can be
> > > > retained in the Fedora build system and never left it. That means those
> > > > packages are never made available to Fedora users and thus a service 
> > > > level for
> > > > them is significantly lower. E.g. no security fixes, not bug fixes, no
> > > > integration, not tests, no API/ABI stability. The only requirement is 
> > > > that
> > > > they can be built and used for building other packages.
> > >
> > > So conceptually, one way we can solve this problem by implementing a way
> > > to mark certain non-modular RPMs as "build root only" packages and thus
> > > composing them into a separate "build root" yum repo, that is not enabled
> > > by default except in the build system.
> > >
> >
> > This is an anti-feature and I personally will not support any effort
> > to offer this in Fedora. That is just one step removed from not
> > shipping it at all to people, and I don't want it to be easy for us to
> > make that kind of decision.
>
> We already have this feature in Fedora via Modularity. If it is unacceptable
> for Fedora, we shouldn't do it in modules either, while if it is acceptable,
> then we should allow it for non-modular content.

It's not allowed there either. You are not supposed to do that, *period*.


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

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

[Christopher]

On Thu, Sep 10, 2020 at 11:08 AM Aleksandar Kurtakov
 wrote:
>
>
>
> On Thu, Sep 10, 2020 at 5:54 PM Vitaly Zaitsev via devel 
>  wrote:
>>
>> On 10.09.2020 16:10, Aleksandar Kurtakov wrote:
>> > Flatpak is way better suited for our use case and in addition gives us
>> > access to a way bigger install base.
>>
>> Flathub is a third-party repository and not related to Fedora at all.
>>
>>
>> > And the involvement on Java packaging in Fedora is so low that we 
>> > literally have to maintain whole other stacks including jetty, lucene and 
>> > etc. - not feasible work in any way.
>>
>> Fedora Modularity team destroyed the entire Java stack in Fedora after
>> moving ant/maven to modules.
>
>
> As I've been involved in ant/maven packaging for a decade or so I would dare 
> to say that this is not the truth. It just exposed the fact that less and 
> less people were actively maintaining things as most of the people that used 
> to do it moved on to other things and the number of new people that joined is 
> quite low. So the burden on people left is bigger and bigger.

I am a relative newcomer to RPM packaging. I became a packager because
I was a long-time Fedora user, and wanted to distribute my Java
packages in Fedora. I began packaging, and slowly began taking over a
few related packages, until the entire stack fell out from under me
because of modularity. Had it been kept alive non-modular, I'd have
been able to encourage others to participate (I had already recruited
one other from $dayjob to help comaintain Java packages and was in the
process of recruiting more when modularity became a thing), and I
would have been able to participate more and more. However, because
everything fell apart, I was not able to do that.

So, from my perspective, it did both: it exposed that less and less
people were actively maintaining things *and* it destroyed the entire
Java stack by making it *harder* for newcomers like me to actively
maintain things that were becoming out of date. As an Apache Software
Foundation member, I really appreciate their "community first"
mindset. One of their driving principles is that having a good
community enables code to get better... prioritizing code or
technologies does not necessary enable community. I feel like Fedora's
modularity efforts, while good intentioned, from a technology
perspectve, were a net negative in terms of community because it
raised the bar to participation and prioritized a design over the
effects on the community.

As mentioned elsewhere in this thread, I also see the modular versions
of Maven/Ant as being worthless (to me). I used to use the non-modular
Maven RPM for my development, but now that it is modular only, I find
that it's actually better to just download the binaries directly from
Apache, because the experience is better than using modules. They are
more up-to-date, break less often, and it requires me to do fewer
steps to keep up-to-date. The convenience of using the stable RPM in
non-modular Fedora is now gone for me, as soon as it became a module.

I wish I could say that modularity didn't have a negative impact...
and that it was a complete success, and that all fault (especially
that pertaining to the Java stack) is elsewhere, but I can't honestly
say I believe that. It would merely be wishful thinking on my part.

>
>>
>>
>> I think FESCo should completely forbid modules without packaged
>> non-modular versions.
>>
>>
>> --
>> 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
>
>
>
> --
> 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
___
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)

[Daniel P . Berrangé]

On Thu, Sep 10, 2020 at 01:37:41PM -0400, Neal Gompa wrote:
> On Thu, Sep 10, 2020 at 1:30 PM Daniel P. Berrangé  
> wrote:
> >
> > On Thu, Sep 10, 2020 at 04:03:46PM +0200, Petr Pisar wrote:
> > > On Thu, Sep 10, 2020 at 02:35:13PM +0100, Daniel P. Berrangé wrote:
> > > > On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote:
> > > >
> > > > > 4.  The benefit we want to preserve from modules is to maintain 
> > > > > packages
> > > > > with varying expectation of quality, specifically separating the
> > > > > build-time-only vs runtime dependencies.  e.g. in that case that a web
> > > > > server like Eclipse Jetty is required as a dep for testing another
> > > > > component during the build, we want to be able to use and build that
> > > > > component, without being indefinitely on the hook for security errata.
> > > > > (The build dependency tree is particularly complex for Maven and
> > > > > involves many examples of packages with frequent and high severity
> > > > > vulnerabilies)
> > > >
> > > > What are you doing different in terms of supporting deps in the module
> > > > that reduces the security errata burden, compared to non-modular builds 
> > > > ?
> > > >
> > > > It feels like if we have some policy that is creating unsustainable
> > > > maint burden wrt non-modular packaging, we should re-examine this
> > > > policy rather than trying to workaround it by going modular, which
> > > > creates a different kind of maint burden.
> > > >
> > > In non-modular Fedora all packages that we have in Fedora build system 
> > > (Koji)
> > > are tagged into Fedora repositories and made available to all users on 
> > > their
> > > computers for any purpose. That implies that all packages in Fedora build 
> > > system
> > > must be fully supported including addressing all security issues.
> > >
> > > In modular Fedora that's (effectively) not true. Packages that only exist
> > > for the sake of building other packages (i.e. build-only dependencies) 
> > > can be
> > > retained in the Fedora build system and never left it. That means those
> > > packages are never made available to Fedora users and thus a service 
> > > level for
> > > them is significantly lower. E.g. no security fixes, not bug fixes, no
> > > integration, not tests, no API/ABI stability. The only requirement is that
> > > they can be built and used for building other packages.
> >
> > So conceptually, one way we can solve this problem by implementing a way
> > to mark certain non-modular RPMs as "build root only" packages and thus
> > composing them into a separate "build root" yum repo, that is not enabled
> > by default except in the build system.
> >
> 
> This is an anti-feature and I personally will not support any effort
> to offer this in Fedora. That is just one step removed from not
> shipping it at all to people, and I don't want it to be easy for us to
> make that kind of decision.

We already have this feature in Fedora via Modularity. If it is unacceptable
for Fedora, we shouldn't do it in modules either, while if it is acceptable,
then we should allow it for non-modular content. 

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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

Subject: Self Introduction: Micah Shennum

[Micah Shennum]

Hello,

I have been using Fedora for a long time (circa 24), and have been
providing feedback to bodhi / updates-testing for a while now. I was
looking for a way to get more involved, and was surprised at how fairly
straight forward creating rpm packages seems when looking into locally
bumping electrum's version. I am a software engineer in my day job
(though this side of things is strictly personal).

--Micah Shennum




0x2732DBEC0BE2336C.asc
Description: application/pgp-keys
___
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: Subject: Self Introduction: Micah Shennum

[Jerry James]

On Thu, Sep 10, 2020 at 7:51 PM Micah Shennum  wrote:
> I have been using Fedora for a long time (circa 24), and have been
> providing feedback to bodhi / updates-testing for a while now. I was
> looking for a way to get more involved, and was surprised at how fairly
> straight forward creating rpm packages seems when looking into locally
> bumping electrum's version. I am a software engineer in my day job
> (though this side of things is strictly personal).

Welcome, Micah!  There are a lot of fiddly little rules to remember
when working with rpm packages, but that shouldn't be anything new for
a software engineer. :-)
-- 
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: The Future of the Java Stack (also regarding ELN and RHEL)

[Mikolaj Izdebski]

On Thu, Sep 10, 2020 at 7:31 PM Daniel P. Berrangé  wrote:
>
> On Thu, Sep 10, 2020 at 04:03:46PM +0200, Petr Pisar wrote:
> > On Thu, Sep 10, 2020 at 02:35:13PM +0100, Daniel P. Berrangé wrote:
> > > On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote:
> > >
> > > > 4.  The benefit we want to preserve from modules is to maintain packages
> > > > with varying expectation of quality, specifically separating the
> > > > build-time-only vs runtime dependencies.  e.g. in that case that a web
> > > > server like Eclipse Jetty is required as a dep for testing another
> > > > component during the build, we want to be able to use and build that
> > > > component, without being indefinitely on the hook for security errata.
> > > > (The build dependency tree is particularly complex for Maven and
> > > > involves many examples of packages with frequent and high severity
> > > > vulnerabilies)
> > >
> > > What are you doing different in terms of supporting deps in the module
> > > that reduces the security errata burden, compared to non-modular builds ?
> > >
> > > It feels like if we have some policy that is creating unsustainable
> > > maint burden wrt non-modular packaging, we should re-examine this
> > > policy rather than trying to workaround it by going modular, which
> > > creates a different kind of maint burden.
> > >
> > In non-modular Fedora all packages that we have in Fedora build system 
> > (Koji)
> > are tagged into Fedora repositories and made available to all users on their
> > computers for any purpose. That implies that all packages in Fedora build 
> > system
> > must be fully supported including addressing all security issues.
> >
> > In modular Fedora that's (effectively) not true. Packages that only exist
> > for the sake of building other packages (i.e. build-only dependencies) can 
> > be
> > retained in the Fedora build system and never left it. That means those
> > packages are never made available to Fedora users and thus a service level 
> > for
> > them is significantly lower. E.g. no security fixes, not bug fixes, no
> > integration, not tests, no API/ABI stability. The only requirement is that
> > they can be built and used for building other packages.
>
> So conceptually, one way we can solve this problem by implementing a way
> to mark certain non-modular RPMs as "build root only" packages and thus
> composing them into a separate "build root" yum repo, that is not enabled
> by default except in the build system.

Yes. This can also be achieved with on-demand side tags that are
already implemented: "build-only" packages are built in a sidetag and
untagged before sidetag is merged. They never appear in release tags
and they are not shipped to users. Builds can be reproduced locally in
mock with configs generated by "koji mock-config" command.

> Modularity is being used because it is the only solution that is available
> today, not because it is a good/desired solution.

Right. Modularity is definitely not the best solution, and IMHO it
definitely has worse user experience compared to ursine packages.
Modularity is used because it was the only solution available at the
moment the decision (to modularize Maven and Ant) was made. Since then
an alternative solution was developed, but we haven't decided to
switch back to ursine packages yet, although we are considering that.

>
> Regards,
> Daniel
> --
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
> ___
> 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: Fedora 33 System-Wide Change proposal: systemd-resolved

[Chris Murphy]

This is just a data point:

F31 Workstation clean installed (Live ISO), then updated to current
F31, then upgraded to F33 (no interim F32).

/etc/nsswitch.conf
hosts:  files mdns4_minimal [NOTFOUND=return] resolve
[!UNAVAIL=return] myhostname dns

And
lrwxrwxrwx. 1 root root39 Sep 10 19:42 resolv.conf ->
../run/systemd/resolve/stub-resolv.conf


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

[Adam Williamson]

On Thu, 2020-09-10 at 22:19 +0200, Mikolaj Izdebski wrote:
> > 
> > So conceptually, one way we can solve this problem by implementing a way
> > to mark certain non-modular RPMs as "build root only" packages and thus
> > composing them into a separate "build root" yum repo, that is not enabled
> > by default except in the build system.
> 
> Yes. This can also be achieved with on-demand side tags that are
> already implemented: "build-only" packages are built in a sidetag and
> untagged before sidetag is merged. They never appear in release tags
> and they are not shipped to users. Builds can be reproduced locally in
> mock with configs generated by "koji mock-config" command.

I have to say I agree with Neal that for Fedora this is an anti-feature
and should not be done.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: GNOME 3.37.92 megaupdate landing in testing and tracker3 coming

[Adam Williamson]

On Thu, 2020-09-10 at 20:49 +0200, Kalev Lember wrote:
> Hi all,
> 
> Just a quick heads up that the 3.37.92 megaupdate is all lined up and
> queued to F33 updates-testing:
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-7f57486c95

For the record, this currently fails openQA tests because the gnome-
shell it contains depends on the gnome-settings-daemon from a separate
update. This is Officially Bad, but I understand the specific situation
here (the other update is an FE fix) and it's reasonable.

Once the FE fix goes stable - it'd be good if someone else could test
and +1 it, I did already - I can re-trigger the tests on the mega-
update and those failures should go away.

> This is likely not going to be pushed through the beta freeze, so next
> week I'll prepare a final .0 release to replace/obsolete the .92 bodhi
> update.
> 
> I'll talk to QA and see how they feel about pulling the .92 update
> through the beta freeze now that the beta is delayed anyway, but I think
> the base scenario is that we ship beta without this.

Yeah. We slipped a week, but we still only have one week from now till
the *next* go/no-go date and there's a lot of stuff going on already,
so personally my instinct is to leave this bit alone. That's just me
personally, though, it's totally fine to propose this as an FE if you
want and see what other folks think.

I'll test the update locally and see how it goes. Thanks.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Fedora compose checker]

No missing expected images.

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

Failed openQA tests: 6/181 (x86_64)

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

ID: 661712  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/661712
ID: 661743  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/661743
ID: 661783  Test: x86_64 universal install_repository_http_variation 
**GATING**
URL: https://openqa.fedoraproject.org/tests/661783

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

ID: 661744  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/661744
ID: 661752  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/661752
ID: 661813  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/661813

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

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

ID: 661778  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/661778

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

ID: 661688  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/661688
ID: 661748  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/661748
ID: 661751  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/661751
ID: 661765  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/661765
ID: 661799  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/661799
ID: 661848  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/661848

Passed openQA tests: 153/181 (x86_64)

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

ID: 661699  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/661699
ID: 661704  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/661704
ID: 661773  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/661773
ID: 661785  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/661785
ID: 661787  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/661787
ID: 661794  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/661794
ID: 661795  Test: x86_64 universal upgrade_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/661795
ID: 661821  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/661821
ID: 661840  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/661840
ID: 661847  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/661847

Skipped gating openQA tests: 4/181 (x86_64)

New skipped gating tests (same test not skipped in Fedora-Rawhide-20200907.n.0):

ID: 661719  Test: x86_64 Workstation-live-iso base_system_logging **GATING**
URL: https://openqa.fedoraproject.org/tests/661719
ID: 661720  Test: x86_64 Workstation-live-iso base_update_cli **GATING**
URL: https://openqa.fedoraproject.org/tests/661720
ID: 661724  Test: x86_64 Workstation-live-iso desktop_terminal **GATING**
URL: https://openqa.fedoraproject.org/tests/661724
ID: 661727  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/661727

Skipped non-gating openQA tests: 11 of 181

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
8 packages(s) added since previous compose: bubblewrap, flashrom, fwupd, 
libftdi, libgcab1, libjcat, libsmbios, libxmlb
1 packages(s) removed since previous compose: dbxtool
1 services(s) removed since previous compose: dbxtool.service
System load changed from 0.10 to 0.23
Previous test data: https://openqa.fedoraproject.org/tests/657034#downloads
Current test data: https://openqa.fedoraproject.org/tests/661677#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
Used swap changed from 41 MiB to 19 MiB
4 packages(s) added since previous compose: libtracker-sparql3, 
pipewire-gstreamer, tracker3, tracker3-miners
1 packages(s) removed since previous 

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

[John M. Harris Jr]

On Thursday, September 10, 2020 1:36:18 AM MST alcir...@posteo.net wrote:
> On Thu, 2020-09-10 at 01:02 -0700, John M. Harris Jr wrote:
> 
> > 
> > 
> > A quick reminder that we're about to release with the system
> > configured to use 
> > Google DNS when no DNS servers are configured. If privacy is valued
> > at all, 
> > this needs to be addressed before release.
> 
> 
> 
> These DNS addresses are bundled upstream in systemd. And they are used
> in the event of a misconfiguration of your network settings, isn't it?
> However they are easily customizable in /etc/systemd/resolved.conf
> (FallbackDNS option)
> 
> And for the records: https://github.com/systemd/systemd/issues/8782
> 
> The same thing is true for system time and date (systemd default to
> Google NTP servers). But as far as I can see it is already addressed
> here
> https://src.fedoraproject.org/rpms/systemd/blob/master/f/systemd.spec#_329

Regardless of Lennart's personal views, this is something that definitely 
merits some attention, and perhaps to be fixed before go-live. They're used 
whenever there are no configured DNS servers, not in the event of 
misconfiguration. Perhaps we should update /etc/systemd/resolved.conf to 
include "FallbackDNS=" system-wide? That would fix this behavior, for sure, 
and prevent the privacy issue for our users.

Why in the world would systemd have anything to do with NTP? We still use 
ntpd, do we not? Checking my system.. Nope, but it's chronyd. Still not 
systemd.

Also, looks like systemd is adding itself as a user and group database? This 
is probably a bug. Right?

https://src.fedoraproject.org/rpms/systemd/blob/master/f/systemd.spec#_655

-- 
John M. Harris, Jr.

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

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

[John M. Harris Jr]

On Thursday, September 10, 2020 4:27:30 AM MST alcir...@posteo.net wrote:
> On Thu, 2020-09-10 at 12:06 +0200, Eugene Syromiatnikov wrote:
> 
> > > 
> > > These DNS addresses are bundled upstream in systemd. And they are
> > > used
> > > in the event of a misconfiguration of your network settings, isn't
> > > it?
> > > However they are easily customizable in /etc/systemd/resolved.conf
> > > (FallbackDNS option)
> > 
> > 
> > It's about the distribution's default setting, not a configuration
> > possibility.
> 
> 
> "Which servers are used (or any at all) as a fallback is a compile-time
> as well as a runtime option. If you don't like the upstream defaults,
> then please work with downstream to pick different options or make the
> choices locally in your configuration files."
> 
> As a concerned user, you can configure the FallbackDNS option in
> /etc/systemd/resolved.conf and put whatever DNS you prefer. Google and
> so on will never be contacted.
> 
> Obviously the distribution can put different DNS in systemd at compile
> time, or provide a default resolved.conf file where FallbackDNS is
> uncommented and filled.

It's important to note that this is also a major change in behavior. 
Currently, when no DNS servers are configured, your system will only perform 
local lookup, and will not look at an external DNS server.

-- 
John M. Harris, Jr.

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

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

[Michael Catanzaro]

On Thu, Sep 10, 2020 at 8:02 pm, Christopher Engelhard  
wrote:

I'll file a bug - would this be against authselect or  systemd?


I would start with authselect, even if it might turn out to be a 
systemd RPM issue.


That said, it would be really helpful if someone could find a way to 
reproduce this, since otherwise we won't know how to fix whatever has 
gone wrong.


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

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

[Zbigniew Jędrzejewski-Szmek]

On Thu, Sep 10, 2020 at 12:12:05PM -0400, Robbie Harwood wrote:
> Mikolaj Izdebski  writes:
> > On Thu, Sep 10, 2020 at 3:46 PM Alexander Scheel  wrote:
> >> Hi Joe,
> >> On Thu, Sep 10, 2020 at 8:52 AM Joe Orton  wrote:
> >> > I'm writing as the Red Hat engineering manager responsible for Maven and
> >> > Ant in RHEL, and on behalf of Mikolaj Izdebski and Marian Koncek from my
> >> > team.  I want to give a broad response to some of the points here:
> >> >
> >> > 1.  The team has two missions in Fedora:
> >> >
> >> > a) We deliver, maintain and support Ant and Maven in Fedora. Our aim is
> >> > to provide developers with the most popular Java build systems which are
> >> > reviewed, tested, and updated through the release lifecycle.
> >> >
> >> > b) We design, develop and document tooling that enables anyone to
> >> > package Java software with a simple, efficient and scalable process. We
> >> > are also active members of Java SIG, collaborating on complex changes
> >> > and guiding new contributors.
> >> >
> >> > 2.  We are committed to maintaining the Ant and Maven modules in
> >> > Fedora.  We have always expected to make them available as default
> >> > streams and in the buildroot so they can be available and consumed by
> >> > non-modular packages, but we completely respect the decisions of FESCo
> >> > to disallow default streams and of other contributors to adopt and
> >> > maintain the non-modular packages.  We are not going to promise to
> >> > commit time and resources to maintain the non-modular packages.
> >>
> >> As a reminder (as in my RHEL devel-list reply): there are no default
> >> module streams in Fedora. There is also no Ursa Major/Prime, so were
> >> they to exist, there would still be no way for non-modular packages to
> >> use them.
> >
> > There are default module streams in Fedora 31.
> 
> Fedora 31 is most likely EOL in about two months.  I really hope you're
> not targeting your future development against it.

This exchange summarizes the situation nicely.

Modularity can be considered an over-complicated hyped-through-the-roof
bundling mechanism.

For a long time Fedora has very strongly discouraged bundling in the sense of
subsumming one package into another to have a custom build of a dependency.

The disapproval of bundling is not because it doesn't work: it does, and in
fact with some crappy libraries it's the least bad solution. The disapproval
is motivated by the fact that bundling doesn't scale and that it subtracts from
the ecosystem. Instead of us all cooperating and each bugfix helping all
users of a given dependency, a maintainer of a bundled library is only helping
themselves and their package.

Bundling is not inherently bad: currently the policy even allows it as
a workaround if using the system-wide package is not feasible. It is a
pragmatic choice to allow it as a last resort. But the effect of bundling
on other packages must be minimized any conflicts or confusion with the
system version avoided.

With Modularity, we threw this accumulated wisdom away.
In two ways: by encouraging private^Wbuild-only dependencies and by
letting bundled^Wmodularized rpms shadow normal rpms.

For Maven packaging the appeal of Modularity is clearly the privatization of
the dependency tree, which obviously undercuts the ecosystem of packages.

The Java ecosystem collapsed so quickly because it was already weak
— hundreds of packages on the shoulders of one person. But even in a stronger
ecosystem, with enough packages modularized, the packaging ecosystem of
mutual cooperation would collapse.

For some other modules, the appeal is the overriding of package deps, which
means that the modular rpms don't have to worry about getting it deps precisely
declared, at the cost of breaking the deps declared in other packages.

If there wasn't Modularity and instead Maven would bundle it's deps into
one huge srpm, the effect on the ecosystem would be the same. As with
bundling, Modularization gives short-term relief at a very high long-term
cost. We should avoid modularization like we avoid bundling.

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

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

[Neal Gompa]

On Thu, Sep 10, 2020 at 9:34 PM John M. Harris Jr  wrote:
>
> On Thursday, September 10, 2020 1:36:18 AM MST alcir...@posteo.net wrote:
> > On Thu, 2020-09-10 at 01:02 -0700, John M. Harris Jr wrote:
> >
> > >
> > >
> > > A quick reminder that we're about to release with the system
> > > configured to use
> > > Google DNS when no DNS servers are configured. If privacy is valued
> > > at all,
> > > this needs to be addressed before release.
> >
> >
> >
> > These DNS addresses are bundled upstream in systemd. And they are used
> > in the event of a misconfiguration of your network settings, isn't it?
> > However they are easily customizable in /etc/systemd/resolved.conf
> > (FallbackDNS option)
> >
> > And for the records: https://github.com/systemd/systemd/issues/8782
> >
> > The same thing is true for system time and date (systemd default to
> > Google NTP servers). But as far as I can see it is already addressed
> > here
> > https://src.fedoraproject.org/rpms/systemd/blob/master/f/systemd.spec#_329
>
> Regardless of Lennart's personal views, this is something that definitely
> merits some attention, and perhaps to be fixed before go-live. They're used
> whenever there are no configured DNS servers, not in the event of
> misconfiguration. Perhaps we should update /etc/systemd/resolved.conf to
> include "FallbackDNS=" system-wide? That would fix this behavior, for sure,
> and prevent the privacy issue for our users.
>

I'd rather have fallback DNS than no DNS by default.

> Why in the world would systemd have anything to do with NTP? We still use
> ntpd, do we not? Checking my system.. Nope, but it's chronyd. Still not
> systemd.
>

timesyncd is a simple NTP client for minimal Linux systems. We don't
use it, because chronyd is miles better.

> Also, looks like systemd is adding itself as a user and group database? This
> is probably a bug. Right?
>
> https://src.fedoraproject.org/rpms/systemd/blob/master/f/systemd.spec#_655
>

No. nss-systemd has been a thing for many years. It was added so that
DynamicUsers= functionality for systemd units would work.




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

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

[John M. Harris Jr]

On Thursday, September 10, 2020 4:42:24 AM MST Zbigniew Jędrzejewski-Szmek 
wrote:
> On Thu, Sep 10, 2020 at 01:27:30PM +0200, alcir...@posteo.net wrote:
> 
> > On Thu, 2020-09-10 at 12:06 +0200, Eugene Syromiatnikov wrote:
> > 
> > > > 
> > > > These DNS addresses are bundled upstream in systemd. And they are
> > > > used
> > > > in the event of a misconfiguration of your network settings, isn't
> > > > it?
> > > > However they are easily customizable in /etc/systemd/resolved.conf
> > > > (FallbackDNS option)
> > > 
> > > 
> > > It's about the distribution's default setting, not a configuration
> > > possibility.
> > 
> > 
> > "Which servers are used (or any at all) as a fallback is a compile-time
> > as well as a runtime option. If you don't like the upstream defaults,
> > then please work with downstream to pick different options or make the
> > choices locally in your configuration files."
> > 
> > As a concerned user, you can configure the FallbackDNS option in
> > /etc/systemd/resolved.conf and put whatever DNS you prefer. Google and
> > so on will never be contacted.
> > 
> > Obviously the distribution can put different DNS in systemd at compile
> > time, or provide a default resolved.conf file where FallbackDNS is
> > uncommented and filled.
> 
> 
> Exactly. With my maintainer hat on: this is a non-issue. We consider
> current defaults (a working fallback configuration out of the box that
> has a very minor information leak) better than the proposed (a non-working
> fallback configuration). If you need to, provide the trivial two-line
> dropin file to override this locally.

Zbyszek,

I'm definitely not suggesting something that is "non-working". That said, not 
having any DNS servers configured indicates that remote lookup should not be 
used, not that a random DNS server should be picked by the resolver itself. 
When there are no DNS servers, the expected behavior is that no external 
servers are used for lookup.

-- 
John M. Harris, Jr.

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

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

[Stephen John Smoogen]

On Thu, 10 Sep 2020 at 13:31, Daniel P. Berrangé 
wrote:

> On Thu, Sep 10, 2020 at 04:03:46PM +0200, Petr Pisar wrote:
> > On Thu, Sep 10, 2020 at 02:35:13PM +0100, Daniel P. Berrangé wrote:
> > > On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote:
> > >
> > > > 4.  The benefit we want to preserve from modules is to maintain
> packages
> > > > with varying expectation of quality, specifically separating the
> > > > build-time-only vs runtime dependencies.  e.g. in that case that a
> web
> > > > server like Eclipse Jetty is required as a dep for testing another
> > > > component during the build, we want to be able to use and build that
> > > > component, without being indefinitely on the hook for security
> errata.
> > > > (The build dependency tree is particularly complex for Maven and
> > > > involves many examples of packages with frequent and high severity
> > > > vulnerabilies)
> > >
> > > What are you doing different in terms of supporting deps in the module
> > > that reduces the security errata burden, compared to non-modular
> builds ?
> > >
> > > It feels like if we have some policy that is creating unsustainable
> > > maint burden wrt non-modular packaging, we should re-examine this
> > > policy rather than trying to workaround it by going modular, which
> > > creates a different kind of maint burden.
> > >
> > In non-modular Fedora all packages that we have in Fedora build system
> (Koji)
> > are tagged into Fedora repositories and made available to all users on
> their
> > computers for any purpose. That implies that all packages in Fedora
> build system
> > must be fully supported including addressing all security issues.
> >
> > In modular Fedora that's (effectively) not true. Packages that only exist
> > for the sake of building other packages (i.e. build-only dependencies)
> can be
> > retained in the Fedora build system and never left it. That means those
> > packages are never made available to Fedora users and thus a service
> level for
> > them is significantly lower. E.g. no security fixes, not bug fixes, no
> > integration, not tests, no API/ABI stability. The only requirement is
> that
> > they can be built and used for building other packages.
>
> So conceptually, one way we can solve this problem by implementing a way
> to mark certain non-modular RPMs as "build root only" packages and thus
> composing them into a separate "build root" yum repo, that is not enabled
> by default except in the build system.
>
>
The problem is that you may need differing packages for your 'build-root'.
This means that someone has to determine if your buildroot only has
foobar-1.2-3 or foobar-2.3-4 which are neither wanted to be in the
buildroot but unison-2.1 needs one and unison-2.2 needs the other. [Or some
toolkit where to get to the next version you need to compile a version
before the one you have with different yacc/etc and then need the next
version to finish the build.]

The more fundamental problem is that everyone assumes that if it lives in
the buildroot only.. it magically doesn't have any bugs which can cause
problems with a package being compiled by it. Instead it is now a package
which no one can easily inspect to see that XYZ app is dumping core because
your buildroot only yacc is a recycled road apple.



> Modularity is being used because it is the only solution that is available
> today, not because it is a good/desired solution.
>
> Regards,
> Daniel
> --
> |: https://berrange.com  -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-
> https://www.instagram.com/dberrange :|
> ___
> 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: The Future of the Java Stack (also regarding ELN and RHEL)

[Guido Aulisi]

> Il giorno 10 set 2020, alle ore 16:53, Vitaly Zaitsev via devel 
>  ha scritto:
> 
> On 10.09.2020 16:10, Aleksandar Kurtakov wrote:
>> Flatpak is way better suited for our use case and in addition gives us
>> access to a way bigger install base.
> 
> Flathub is a third-party repository and not related to Fedora at all.
> 
>> And the involvement on Java packaging in Fedora is so low that we literally 
>> have to maintain whole other stacks including jetty, lucene and etc. - not 
>> feasible work in any way.
> 
> Fedora Modularity team destroyed the entire Java stack in Fedora after
> moving ant/maven to modules.
> 
> I think FESCo should completely forbid modules without packaged
> non-modular versions.

I totally agree

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


Ciao
Guido
___
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: [Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[Zbigniew Jędrzejewski-Szmek]

On Thu, Sep 10, 2020 at 06:37:56PM -0700, John M. Harris Jr wrote:
> On Thursday, September 10, 2020 4:42:24 AM MST Zbigniew Jędrzejewski-Szmek 
> wrote:
> > On Thu, Sep 10, 2020 at 01:27:30PM +0200, alcir...@posteo.net wrote:
> > 
> > > On Thu, 2020-09-10 at 12:06 +0200, Eugene Syromiatnikov wrote:
> > > 
> > > > > 
> > > > > These DNS addresses are bundled upstream in systemd. And they are
> > > > > used
> > > > > in the event of a misconfiguration of your network settings, isn't
> > > > > it?
> > > > > However they are easily customizable in /etc/systemd/resolved.conf
> > > > > (FallbackDNS option)
> > > > 
> > > > 
> > > > It's about the distribution's default setting, not a configuration
> > > > possibility.
> > > 
> > > 
> > > "Which servers are used (or any at all) as a fallback is a compile-time
> > > as well as a runtime option. If you don't like the upstream defaults,
> > > then please work with downstream to pick different options or make the
> > > choices locally in your configuration files."
> > > 
> > > As a concerned user, you can configure the FallbackDNS option in
> > > /etc/systemd/resolved.conf and put whatever DNS you prefer. Google and
> > > so on will never be contacted.
> > > 
> > > Obviously the distribution can put different DNS in systemd at compile
> > > time, or provide a default resolved.conf file where FallbackDNS is
> > > uncommented and filled.
> > 
> > 
> > Exactly. With my maintainer hat on: this is a non-issue. We consider
> > current defaults (a working fallback configuration out of the box that
> > has a very minor information leak) better than the proposed (a non-working
> > fallback configuration). If you need to, provide the trivial two-line
> > dropin file to override this locally.
> 
> Zbyszek,
> 
> I'm definitely not suggesting something that is "non-working". That said, not 
> having any DNS servers configured indicates that remote lookup should not be 
> used, not that a random DNS server should be picked by the resolver itself. 
> When there are no DNS servers, the expected behavior is that no external 
> servers are used for lookup.

There are no environments where remote lookup SHOULD NOT not be used. There
are remote environments where it MUST NOT be used, and environments where it
is expected to work. For the former, just emptying /etc/resolv.conf is a halfway
measure that doesn't do enough so strong filtering with namespaces or routing
must be provided anyway. In the second case, we want to have working networking
(even if your local crappy dns router forgets to attach a dns server to the
dhcp lease or such).

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

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

[Neal Becker]

Might be interesting to try logging in as a new user to see if some older
kde settings are messing things up.

On Thu, Sep 10, 2020 at 6:24 AM Ondrej Mosnacek  wrote:

> On Tue, Sep 8, 2020 at 5:30 PM 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.
>
> So yesterday I tried to log in to the KDE Plasma + Wayland session on
> my laptop (F32) and the experience was unfortunately quite horrible...
>
> 1. When I logged out of the X session, switched to Wayland on the
> login screen, and logged in, I only got a black screen. After I
> rebooted, I managed to login to the Wayland session (I have automatic
> login after boot enabled), but...
> 2. The desktop was all squeezed into a small 1024x786 rectangle in the
> upper left corner of the screen (my screen is 1920x1080). So I opened
> system settings to change the resolution, but...
> 3. The screen settings were showing "manufacturer_TODO" and
> "model_TODO" as the name of the screen and the only resolution offered
> was 1024x786.
> 4. The window layout of my KDE session was not preserved (I think even
> the distribution of windows to activities was lost). But I probably
> shouldn't expect this to work...
> 5. Logging out of the Wayland session gave me just a black screen with
> blinking cursor, no login screen.
>
> Reading the other posts in this thread it seems I'm the only one
> experiencing such serious breakage (maybe except 4., which is
> understandable), so I'm wondering if I did something wrong... I simply
> installed plasma-workspace-wayland, logged out, and then logged in
> selecting "Plasma (Wayland) (Wayland)" from the session dropdown.
>
> --
> Ondrej Mosnacek
> Software Engineer, Platform Security - SELinux kernel
> Red Hat, Inc.
> ___
> 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: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Ondrej Mosnacek]

On Thu, Sep 10, 2020 at 11:18 AM Florian Weimer  wrote:
> * Ben Cotton:
>
> > https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
> >
> > == Summary ==
> > Remove support for SELinux runtime disable so that the LSM hooks can
> > be hardened via read-only-after-initialization protections.
> >
> > Migrate users to using ''selinux=0'' if they want to disable SELinux.
> >
> > == Owner ==
> > * Name: [[User:plautrba| Petr Lautrbach]]
> > * Email: plaut...@redhat.com
> > * Name: [[User:omos| Ondrej Mosnacek]]
> > * Email: omosn...@redhat.com
> >
> >
> > == Detailed Description ==
> > Support for SELinux runtime disable via ''/etc/selinux/config'' was
> > originally developed to make it easier for Linux distributions to
> > support architectures where adding parameters to the kernel command
> > line was difficult.
> > Unfortunately, supporting runtime disable meant we had to make some
> > security trade-offs when it comes to the kernel LSM hooks.
> >
> > Marking the kernel LSM hooks as read only provides some very nice
> > security benefits, but it does mean that we can no longer disable
> > SELinux at runtime.
>
> Could the static_call framework be used instead for this?
>
>   

AFAIK the static_call framework is about mitigating the performance
impact of indirect calls (basically function pointers), while this
proposal is about allowing the security hook function pointers to be
marked read-only after all built-in kernel modules have been
initialized (IOW after the hook lists have been set up based on the
kernel cmdline), which means an attacker wouldn't be able to
neutralize the hooks by overwriting the function pointers.

So unless I misunderstand something, these are two orthogonal
solutions to different problems - you would still have the possibility
to overwrite the hook calls after (only) converting to static_call and
also this proposal doesn't solve the indirect-call performance
problem.

BTW, there has been an RFC patch for switching LSM hooks to use
static_call, but the result is quite ugly-looking code, unfortunately:
https://lore.kernel.org/linux-security-module/20200820164753.3256899-1-jackm...@chromium.org/

-- 
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
___
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)

[Ondrej Mosnacek]

On Thu, Sep 10, 2020 at 11:18 AM Tom Hughes via devel
 wrote:
> On 10/09/2020 09:44, Richard Hughes wrote:
> > On Tue, 8 Sep 2020 at 16:29, Ben Cotton  wrote:
> >> 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.
> >
> > Speaking from personal experience, I've wasted days over the last
> > decade trying to debug a locally installed system service that was not
> > working where there were no messages in any of the logs (e.g. no AVCs)
> > -- and turning off selinux at runtime magically fixed the problem.
>
> Some selinux rules are marked to not generate AVCs...

Yes, these are called "dontaudit" rules. They are used for when the
impact of a failed access check doesn't prevent the application from
functioning and we don't want to allow that access vector (e.g. when
the application just checks to see if it can do some privileged
operation and if not, it continues with some fallback). Unfortunately,
it can happen sometimes that such a rule hides some denial that
actually does break something.

They can be temporarily disabled by running `semodule -DB` and then
re-enabled again with `semodule -B`.

>
> > Whilst I'm of course in favour of fixing the lockdown issue, would it
> > also be fair to say that any selinux regression not triggering an AVC
> > (which is fixed using selinux=0) would block this kind of proposal?
>
> Did "setenforce 0" also fix it?

If the issue is in (or rather hidden by) the dontaudit rules, then
"setenforce 0" should indeed make it work as well.

--
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
___
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-20200910.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: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Neal Gompa]

On Thu, Sep 10, 2020 at 7:33 AM Richard Hughes  wrote:
>
> On Thu, 10 Sep 2020 at 10:17, Tom Hughes  wrote:
> > > Speaking from personal experience, I've wasted days over the last
> > > decade trying to debug a locally installed system service that was not
> > > working where there were no messages in any of the logs (e.g. no AVCs)
> > > -- and turning off selinux at runtime magically fixed the problem.
> >
> > Some selinux rules are marked to not generate AVCs...
>
> Why!? There's sometimes no log output anywhere obvious that a syscall
> or something was blocked. It's the reason I turn off selinux on my
> work development machine, and I've often wasted *hours* of my life on
> code "doing something impossible" over the last decade until a neuron
> at the back of my brain remembers "you've not yet turned off selinux"
> and then when I "sudo setenforce 0" it works, and I can't actually
> file a bug as there's no indication of what selinux actually blocked
> or why.
>

Because Red Hat customers put the SELinux policy developers into
no-win situations: they complain about AVC denials that don't actually
significantly break anything in *their* app and often just disable
SELinux in those scenarios. Red Hat wants customers to use it and not
freak out all the time, so these kinds of things get added because it
is very hard to come up with the right rules for all cases and there's
not enough time to work on that.

(I know for a fact that more than a few dontaudit rules were the
result of those kinds of conversations, because I witnessed them)




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

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

[Mikhail Gavrilov]

From here https://bugzilla.redhat.com/show_bug.cgi?id=1863041#c46 I have 
expected what newly-created connection would work properly without manually 
changing ipv4.dns-search to ~. on the specific VPN connection.
___
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)

[Richard Hughes]

On Thu, 10 Sep 2020 at 10:17, Tom Hughes  wrote:
> > Speaking from personal experience, I've wasted days over the last
> > decade trying to debug a locally installed system service that was not
> > working where there were no messages in any of the logs (e.g. no AVCs)
> > -- and turning off selinux at runtime magically fixed the problem.
>
> Some selinux rules are marked to not generate AVCs...

Why!? There's sometimes no log output anywhere obvious that a syscall
or something was blocked. It's the reason I turn off selinux on my
work development machine, and I've often wasted *hours* of my life on
code "doing something impossible" over the last decade until a neuron
at the back of my brain remembers "you've not yet turned off selinux"
and then when I "sudo setenforce 0" it works, and I can't actually
file a bug as there's no indication of what selinux actually blocked
or why.

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

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

[Eugene Syromiatnikov]

On Thu, Sep 10, 2020 at 10:36:18AM +0200, alcir...@posteo.net wrote:
> On Thu, 2020-09-10 at 01:02 -0700, John M. Harris Jr wrote:
> > 
> > 
> > A quick reminder that we're about to release with the system
> > configured to use 
> > Google DNS when no DNS servers are configured. If privacy is valued
> > at all, 
> > this needs to be addressed before release.
> 
> 
> These DNS addresses are bundled upstream in systemd. And they are used
> in the event of a misconfiguration of your network settings, isn't it?
> However they are easily customizable in /etc/systemd/resolved.conf
> (FallbackDNS option)

It's about the distribution's default setting, not a configuration possibility.

> And for the records: https://github.com/systemd/systemd/issues/8782
> 
> The same thing is true for system time and date (systemd default to
> Google NTP servers). But as far as I can see it is already addressed
> here
> https://src.fedoraproject.org/rpms/systemd/blob/master/f/systemd.spec#_329

I believe that it is the point of the John's e-mail: this issue is still
*not* addressed in Fedora.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Ondrej Mosnacek]

On Tue, Sep 8, 2020 at 5:30 PM 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.

So yesterday I tried to log in to the KDE Plasma + Wayland session on
my laptop (F32) and the experience was unfortunately quite horrible...

1. When I logged out of the X session, switched to Wayland on the
login screen, and logged in, I only got a black screen. After I
rebooted, I managed to login to the Wayland session (I have automatic
login after boot enabled), but...
2. The desktop was all squeezed into a small 1024x786 rectangle in the
upper left corner of the screen (my screen is 1920x1080). So I opened
system settings to change the resolution, but...
3. The screen settings were showing "manufacturer_TODO" and
"model_TODO" as the name of the screen and the only resolution offered
was 1024x786.
4. The window layout of my KDE session was not preserved (I think even
the distribution of windows to activities was lost). But I probably
shouldn't expect this to work...
5. Logging out of the Wayland session gave me just a black screen with
blinking cursor, no login screen.

Reading the other posts in this thread it seems I'm the only one
experiencing such serious breakage (maybe except 4., which is
understandable), so I'm wondering if I did something wrong... I simply
installed plasma-workspace-wayland, logged out, and then logged in
selecting "Plasma (Wayland) (Wayland)" from the session dropdown.

--
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
___
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: [Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[alciregi]

On Thu, 2020-09-10 at 12:06 +0200, Eugene Syromiatnikov wrote:
> > 
> > These DNS addresses are bundled upstream in systemd. And they are
> > used
> > in the event of a misconfiguration of your network settings, isn't
> > it?
> > However they are easily customizable in /etc/systemd/resolved.conf
> > (FallbackDNS option)
> 
> It's about the distribution's default setting, not a configuration
> possibility.

"Which servers are used (or any at all) as a fallback is a compile-time
as well as a runtime option. If you don't like the upstream defaults,
then please work with downstream to pick different options or make the
choices locally in your configuration files."

As a concerned user, you can configure the FallbackDNS option in
/etc/systemd/resolved.conf and put whatever DNS you prefer. Google and
so on will never be contacted.

Obviously the distribution can put different DNS in systemd at compile
time, or provide a default resolved.conf file where FallbackDNS is
uncommented and filled.


Ciao,
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: [Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[Zbigniew Jędrzejewski-Szmek]

On Thu, Sep 10, 2020 at 01:27:30PM +0200, alcir...@posteo.net wrote:
> On Thu, 2020-09-10 at 12:06 +0200, Eugene Syromiatnikov wrote:
> > > 
> > > These DNS addresses are bundled upstream in systemd. And they are
> > > used
> > > in the event of a misconfiguration of your network settings, isn't
> > > it?
> > > However they are easily customizable in /etc/systemd/resolved.conf
> > > (FallbackDNS option)
> > 
> > It's about the distribution's default setting, not a configuration
> > possibility.
> 
> "Which servers are used (or any at all) as a fallback is a compile-time
> as well as a runtime option. If you don't like the upstream defaults,
> then please work with downstream to pick different options or make the
> choices locally in your configuration files."
> 
> As a concerned user, you can configure the FallbackDNS option in
> /etc/systemd/resolved.conf and put whatever DNS you prefer. Google and
> so on will never be contacted.
> 
> Obviously the distribution can put different DNS in systemd at compile
> time, or provide a default resolved.conf file where FallbackDNS is
> uncommented and filled.

Exactly. With my maintainer hat on: this is a non-issue. We consider
current defaults (a working fallback configuration out of the box that
has a very minor information leak) better than the proposed (a non-working
fallback configuration). If you need to, provide the trivial two-line dropin
file to override this locally.

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

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. 

Fedora-Cloud-32-20200910.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-20200909.0):

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

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: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

[Vít Ondruch]

Hi Michael,

Could you please provide more details? This is content of my nsswitch.conf:


~~~

$ grep mdns4_minimal /etc/authselect/user-nsswitch.conf
hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
~~~


How that happened? From what version of what package it happened? Why
should I do some changes manually and they are not handled automatically?


Thx


Vít


Dne 09. 09. 20 v 21:08 Michael Catanzaro napsal(a):
> 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
___
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)

[Tom Hughes via devel]

On 10/09/2020 09:44, Richard Hughes wrote:

On Tue, 8 Sep 2020 at 16:29, Ben Cotton  wrote:

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.


Speaking from personal experience, I've wasted days over the last
decade trying to debug a locally installed system service that was not
working where there were no messages in any of the logs (e.g. no AVCs)
-- and turning off selinux at runtime magically fixed the problem.


Some selinux rules are marked to not generate AVCs...


Whilst I'm of course in favour of fixing the lockdown issue, would it
also be fair to say that any selinux regression not triggering an AVC
(which is fixed using selinux=0) would block this kind of proposal?


Did "setenforce 0" also fix it?

Tom

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

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

[John M. Harris Jr]

On Wednesday, September 9, 2020 12:43:28 PM MST Ben Cotton wrote:
> 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

A quick reminder that we're about to release with the system configured to use 
Google DNS when no DNS servers are configured. If privacy is valued at all, 
this needs to be addressed before release.

-- 
John M. Harris, Jr.

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

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

[Thomas Haller]

On Thu, 2020-09-10 at 06:53 +, Mikhail Gavrilov wrote:
> 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):


Hi,


there isn't much information provided here, so I can only guess what's
wrong.


1) the VPN profile does not get the default route (has `ipv4.never-
default=yes).

2) the VPN profile does not specify any search domains, and neither
does the VPN server push any search domains.


If the VPN profile would get a default route (contrary to 1), then
NetworkManager would automatically add search domain "~.". But as that
doesn't happen, the VPN is not considered for resolving any domains.

Fix your configuration to either:

- let your VPN server announce the domains that it should use.

- explicilty configure the desired search domains on the VPN. In the
simpliest case just

 $ nmcli connection modify "$VPN_PROFILE" +ipv4.dns-search '~.'

"~." is a routeing-only search domain for everything.


That's what Beniamino already said at 
https://bugzilla.redhat.com/show_bug.cgi?id=1863041#c33



best,
Thomas


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

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

[John M. Harris Jr]

On Wednesday, September 9, 2020 4:31:57 AM MST Julen Landa Alustiza wrote:
> 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.

There is also that this is not likely a decision that would be reached by 
Fedora as a whole, if this had been put to a vote.

-- 
John M. Harris, Jr.

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

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

[Richard Hughes]

On Tue, 8 Sep 2020 at 16:29, Ben Cotton  wrote:
> 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.

Speaking from personal experience, I've wasted days over the last
decade trying to debug a locally installed system service that was not
working where there were no messages in any of the logs (e.g. no AVCs)
-- and turning off selinux at runtime magically fixed the problem.

Whilst I'm of course in favour of fixing the lockdown issue, would it
also be fair to say that any selinux regression not triggering an AVC
(which is fixed using selinux=0) would block this kind of proposal?

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

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

[Florian Weimer]

* Ben Cotton:

> https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
>
> == Summary ==
> Remove support for SELinux runtime disable so that the LSM hooks can
> be hardened via read-only-after-initialization protections.
>
> Migrate users to using ''selinux=0'' if they want to disable SELinux.
>
> == Owner ==
> * Name: [[User:plautrba| Petr Lautrbach]]
> * Email: plaut...@redhat.com
> * Name: [[User:omos| Ondrej Mosnacek]]
> * Email: omosn...@redhat.com
>
>
> == Detailed Description ==
> Support for SELinux runtime disable via ''/etc/selinux/config'' was
> originally developed to make it easier for Linux distributions to
> support architectures where adding parameters to the kernel command
> line was difficult.
> Unfortunately, supporting runtime disable meant we had to make some
> security trade-offs when it comes to the kernel LSM hooks.
>
> Marking the kernel LSM hooks as read only provides some very nice
> security benefits, but it does mean that we can no longer disable
> SELinux at runtime.

Could the static_call framework be used instead for this?

  

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
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: 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

[Kamil Paral]

On Thu, Sep 10, 2020 at 8:54 AM Mikhail Gavrilov <
mikhail.v.gavri...@gmail.com> wrote:

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

I see the same error.
___
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: [Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[alciregi]

On Thu, 2020-09-10 at 01:02 -0700, John M. Harris Jr wrote:
> 
> 
> A quick reminder that we're about to release with the system
> configured to use 
> Google DNS when no DNS servers are configured. If privacy is valued
> at all, 
> this needs to be addressed before release.


These DNS addresses are bundled upstream in systemd. And they are used
in the event of a misconfiguration of your network settings, isn't it?
However they are easily customizable in /etc/systemd/resolved.conf
(FallbackDNS option)

And for the records: https://github.com/systemd/systemd/issues/8782

The same thing is true for system time and date (systemd default to
Google NTP servers). But as far as I can see it is already addressed
here
https://src.fedoraproject.org/rpms/systemd/blob/master/f/systemd.spec#_329


Ciao,
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: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Ondrej Mosnacek]

Hi James,

On Tue, Sep 8, 2020 at 8:43 PM James Cassell
 wrote:
> On Tue, Sep 8, 2020, at 11:28 AM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
> >
> > == Summary ==
> > Remove support for SELinux runtime disable so that the LSM hooks can
> > be hardened via read-only-after-initialization protections.
> >
> > Migrate users to using ''selinux=0'' if they want to disable SELinux.
> >
>
> I like the proposal. A few thoughts and questions, though:
>
> 1. I think systems with SELINUX=disabled without selinux=0 should hard fail 
> very loudly.

That's an interesting opinion... It would be easier and more direct to
do it that way, but we are worried that users would complain that
their SELINUX=disabled setup is suddenly broken and they need to mess
with the bootloader to get a working system again. (I don't know that
much about real-time systems, so feel free to correct/enlighten me
here.) That's why we try to make sure that things keep working
more-or-less the same as before.

> I've found certain real-time use cases require SELinux to be disabled to meet 
> the real time guarantees. (Permissive doesn't help because it's a timing 
> issue, not permission issue.)

I'd argue that when going real-time, you need to use a modified kernel
anyway and in that case it should be easier to just disable
CONFIG_SECURITY_SELINUX entirely in it. But maybe there can be a
situation where you get some 3rd party real-time kernel which has
SELinux enabled but it's the only thing breaking the latency for your
use case. In that case you'd really need to get SELinux disabled
properly.

Anyway, SELinux enabled with no policy loaded should be closer to
SElinux disabled than to SELinux permissive. In that scenario the
hooks are active, but they mostly do almost nothing. There should be
very little effect on time spent in syscalls compared to SELinux fully
disabled.

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

Booting with init=/bin/bash either doesn't currently work on Fedora,
or I'm doing it wrong... Anyway, on a system without selinux=0 and
with SELINUX=enforcing or =permissive in /etc/selinux/config, it will
always be possible to load a policy if it hasn't been loaded yet. Not
sure about SELINUX=disabled, but I think it should behave the same as
before. (And with selinux=0 it obviously isn't possible neither
before, nor after this change.)

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

I agree that kernel cmdline management is a pain on Fedora/Linux, but
improving that is beyond what we (the proposal owners and our team)
can do :( This is on the shoulders of bootloader maintainers, although
I understand that refactoring GRUB/zipl to improve this would likely
be a pretty heroic endeavor...

I plan to at least add some convenience scripts to the selinux-policy
package that would do the "add/remove selinux=0 to/from
GRUB_CMDLINE_LINUX and run grub2-mkconfig" dance automatically so that
there is still some convenient way of disabling SELinux for those who
need it (at least on non-s390x systems).

>
> Thanks for putting the security-enhancing proposal forward!

And thank you for the valuable feedback!

--
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
___
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)

[Vitaly Zaitsev via devel]

On 10.09.2020 16:10, Aleksandar Kurtakov wrote:
> Flatpak is way better suited for our use case and in addition gives us
> access to a way bigger install base.

Flathub is a third-party repository and not related to Fedora at all.

> And the involvement on Java packaging in Fedora is so low that we literally 
> have to maintain whole other stacks including jetty, lucene and etc. - not 
> feasible work in any way.

Fedora Modularity team destroyed the entire Java stack in Fedora after
moving ant/maven to modules.

I think FESCo should completely forbid modules without packaged
non-modular versions.

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

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

[Vitaly Zaitsev via devel]

On 09.09.2020 20:23, Christoph Karl wrote:
> Do you have a link, bugzilla or so?

https://bugs.kde.org/show_bug.cgi?id=390079

Known KDE-Wayland issues:
https://community.kde.org/Plasma/Wayland_Showstoppers

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

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

[Aleksandar Kurtakov]

On Thu, Sep 10, 2020 at 5:54 PM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 10.09.2020 16:10, Aleksandar Kurtakov wrote:
> > Flatpak is way better suited for our use case and in addition gives us
> > access to a way bigger install base.
>
> Flathub is a third-party repository and not related to Fedora at all.
>

> > And the involvement on Java packaging in Fedora is so low that we
> literally have to maintain whole other stacks including jetty, lucene and
> etc. - not feasible work in any way.
>
> Fedora Modularity team destroyed the entire Java stack in Fedora after
> moving ant/maven to modules.
>

As I've been involved in ant/maven packaging for a decade or so I would
dare to say that this is not the truth. It just exposed the fact that less
and less people were actively maintaining things as most of the people that
used to do it moved on to other things and the number of new people that
joined is quite low. So the burden on people left is bigger and bigger.


>
> I think FESCo should completely forbid modules without packaged
> non-modular versions.
>

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


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

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

[Miro Hrončok]

On 10. 09. 20 16:53, Vitaly Zaitsev via devel wrote:

I think FESCo should completely forbid modules without packaged
non-modular versions.


It did.

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

[Tomasz Torcz]

On Thu, Sep 10, 2020 at 04:38:04PM +0200, Mikolaj Izdebski wrote:
> > >
> > > In modular Fedora that's (effectively) not true. Packages that only exist
> > > for the sake of building other packages (i.e. build-only dependencies) 
> > > can be
> > > retained in the Fedora build system and never left it. That means those
> > > packages are never made available to Fedora users and thus a service 
> > > level for
> > > them is significantly lower. E.g. no security fixes, not bug fixes, no
> > > integration, not tests, no API/ABI stability. The only requirement is that
> > > they can be built and used for building other packages.
> >
> >
> >   So, if user wants to locally rebuild the package, they won't be able to
> > do it? Because BuildRequired packages won't be available?
> 
> Modules can be built locally with "fedpkg module-build-local", which
> downloads required dependencies from Koji and installs them in mock
> chroot. These packages are not installed directly (outsides of chroot)
> on users systems.

  OK, cool, thanks for dispeling my doubts.

-- 
Tomasz Torcz“Funeral in the morning, IDE hacking
to...@pipebreaker.pl in the afternoon and evening.” - Alan Cox
___
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 Thu, Sep 10, 2020 at 11:09 am, Mikhail Gavrilov 
 wrote:

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


Did you edit /etc/nsswitch.conf or /etc/authselect/nsswitch.conf 
manually without using authselect? If so, that was your mistake. But if 
not, and if you can figure out how to reproduce this condition from a 
fresh install, then it must be a Fedora bug that needs to be reported.



# 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


Looks good.


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


If you've ensured that your /etc/nsswitch.conf contains the correct 
content, then please reopen your bug report [1] and we can continue 
debugging there.


Michael

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

[Silvia Sánchez]

Ondrej,

You need to install Kwin Wayland and another package that will provide the
backend.
My experience wasn't the best, several apps crashed, effects stuttered or
were very slow, even typing felt slower.  But at least my desktop looked
normal.
One comment:  the logging out issue is not because of Wayland.  I have the
same with Xorg, and there are several bug reports pointing to the same
issue.

Kind regards,
Lailah



On Thu, 10 Sep 2020 at 12:24, Ondrej Mosnacek  wrote:

> On Tue, Sep 8, 2020 at 5:30 PM 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.
>
> So yesterday I tried to log in to the KDE Plasma + Wayland session on
> my laptop (F32) and the experience was unfortunately quite horrible...
>
> 1. When I logged out of the X session, switched to Wayland on the
> login screen, and logged in, I only got a black screen. After I
> rebooted, I managed to login to the Wayland session (I have automatic
> login after boot enabled), but...
> 2. The desktop was all squeezed into a small 1024x786 rectangle in the
> upper left corner of the screen (my screen is 1920x1080). So I opened
> system settings to change the resolution, but...
> 3. The screen settings were showing "manufacturer_TODO" and
> "model_TODO" as the name of the screen and the only resolution offered
> was 1024x786.
> 4. The window layout of my KDE session was not preserved (I think even
> the distribution of windows to activities was lost). But I probably
> shouldn't expect this to work...
> 5. Logging out of the Wayland session gave me just a black screen with
> blinking cursor, no login screen.
>
> Reading the other posts in this thread it seems I'm the only one
> experiencing such serious breakage (maybe except 4., which is
> understandable), so I'm wondering if I did something wrong... I simply
> installed plasma-workspace-wayland, logged out, and then logged in
> selecting "Plasma (Wayland) (Wayland)" from the session dropdown.
>
> --
> Ondrej Mosnacek
> Software Engineer, Platform Security - SELinux kernel
> Red Hat, Inc.
> ___
> 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)

[Aleksandar Kurtakov]

On Thu, Sep 10, 2020 at 4:46 PM Alexander Scheel  wrote:

> Hi Joe,
>
> On Thu, Sep 10, 2020 at 8:52 AM Joe Orton  wrote:
> >
> > Hi all,
> >
> > I'm writing as the Red Hat engineering manager responsible for Maven and
> > Ant in RHEL, and on behalf of Mikolaj Izdebski and Marian Koncek from my
> > team.  I want to give a broad response to some of the points here:
> >
> > 1.  The team has two missions in Fedora:
> >
> > a) We deliver, maintain and support Ant and Maven in Fedora. Our aim is
> > to provide developers with the most popular Java build systems which are
> > reviewed, tested, and updated through the release lifecycle.
> >
> > b) We design, develop and document tooling that enables anyone to
> > package Java software with a simple, efficient and scalable process. We
> > are also active members of Java SIG, collaborating on complex changes
> > and guiding new contributors.
> >
> > 2.  We are committed to maintaining the Ant and Maven modules in
> > Fedora.  We have always expected to make them available as default
> > streams and in the buildroot so they can be available and consumed by
> > non-modular packages, but we completely respect the decisions of FESCo
> > to disallow default streams and of other contributors to adopt and
> > maintain the non-modular packages.  We are not going to promise to
> > commit time and resources to maintain the non-modular packages.
>
> As a reminder (as in my RHEL devel-list reply): there are no default
> module streams in Fedora. There is also no Ursa Major/Prime, so were
> they to exist, there would still be no way for non-modular packages to
> use them.
>
> This makes the artifacts produced here useful only to other modules.
> Non-modular packages maintained by other Red Hatters, like Eclipse and
> Dogtag PKI cannot use these artifacts. Both of these stacks have tried
> to modularize in Fedora but ultimately remained non-modular.
>

FWIW, I'm eagerly looking to stop packaging Eclipse as RPM entirely.
Flatpak is way better suited for our use case and in addition gives us
access to a way bigger install base. And the involvement on Java packaging
in Fedora is so low that we literally have to maintain whole other stacks
including jetty, lucene and etc. - not feasible work in any way.


>
> > 3.  Our efforts are currently directed mainly at minimization of the
> > dependency tree which leads to maven and ant, automating the process of
> > bootstrapping maven and updating related components, so that new
> > versions can be imported and built reproducibly and with consistent
> > quality.
> >
> > 4.  The benefit we want to preserve from modules is to maintain packages
> > with varying expectation of quality, specifically separating the
> > build-time-only vs runtime dependencies.  e.g. in that case that a web
> > server like Eclipse Jetty is required as a dep for testing another
> > component during the build, we want to be able to use and build that
> > component, without being indefinitely on the hook for security errata.
> > (The build dependency tree is particularly complex for Maven and
> > involves many examples of packages with frequent and high severity
> > vulnerabilies)
> >
> > Regards, Joe
> > ___
> > 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
>


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

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

[Petr Lautrbach]

On Thu, Sep 10, 2020 at 03:46:38PM +0200, Michal Schorm wrote:
> Does this mean, the "setenforce 0" won't work anymore?

No, setenforce will not be affected by this change.

> I use it quite a lot to examine the denials and audit2allow to
> generate updated rules which fixes my issues.
> 
> I would see the inability of such workflow as a major drawback for
> *anyone* who doesn't just consume the default configuration.
> e.g. "My database datadir should reside elsewhere"; "my container
> should access pulseaudio socket"; "I've ran the default configuration
> with my data and it crashed" ...
> 

setenforce works only in SELinux enabled system and `setenforce 0` is to put
SELinux in permissive mode (not to disable SELinux), see "SELinux states and 
modes" at 
https://docs.fedoraproject.org/en-US/quick-docs/getting-started-with-selinux/

Also it will be possible to switch between enforcing and permissive
using SELINUX=enforcing resp SELINUX=permissive in /etc/selinux/config as it is
now.

Petr


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

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

[Mikolaj Izdebski]

On Thu, Sep 10, 2020 at 3:29 PM Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Thursday, 10 September 2020 at 14:50, Joe Orton wrote:
> [...]
> > 1.  The team has two missions in Fedora:
> >
> > a) We deliver, maintain and support Ant and Maven in Fedora. Our aim
> > is to provide developers with the most popular Java build systems
> > which are reviewed, tested, and updated through the release
> > lifecycle.
> >
> > b) We design, develop and document tooling that enables anyone to
> > package Java software with a simple, efficient and scalable process.
> > We are also active members of Java SIG, collaborating on complex
> > changes and guiding new contributors.
> >
> > 2.  We are committed to maintaining the Ant and Maven modules in
> > Fedora.  We have always expected to make them available as default
> > streams and in the buildroot so they can be available and consumed by
> > non-modular packages, but we completely respect the decisions of FESCo
> > to disallow default streams and of other contributors to adopt and
> > maintain the non-modular packages.  We are not going to promise to
> > commit time and resources to maintain the non-modular packages.
>
> Points 1b and 2 mean that nobody can consume your packages for
> maintaining non-modular Java packages, which raises the bar for
> maintaining Java packages considerably.

Javapackages is the main project that provides Java packaging tooling.
I am maintaining it both upstream [1] and in Fedora, also as ursine
package [2].

> [...]
> > 4.  The benefit we want to preserve from modules is to maintain
> > packages with varying expectation of quality, specifically separating
> > the build-time-only vs runtime dependencies.  e.g. in that case that a
> > web server like Eclipse Jetty is required as a dep for testing another
> > component during the build, we want to be able to use and build that
> > component, without being indefinitely on the hook for security
> > errata.  (The build dependency tree is particularly complex for Maven
> > and involves many examples of packages with frequent and high severity
> > vulnerabilies)
>
> On one hand, that's understandable, but you're effectively maintaining
> those packages anyway. And I don't see any reason why you couldn't do
> that in the traditional non-modular way, which makes it easier for
> others to step in and co-maintain. I'm not sure what you mean by
> "indefinitely on the hook for security errata". Can you elaborate?

All Fedora packages shipped to users are expected to be high-quality
and well maintained, which may impose a very significant burden on
maintainers.
But for build-only packages (packages are used only during build, not
shipped to users), many of package maintainer responsibilities [3] can
be reduced to almost nothing. For example "manage security issues"
means triaging them and fixing only very small subset of them (since
user can't install the packages, most of vulnerabilities are not
exploitable), "deal with reported bugs" means closing them NOTABUG as
users can't possibly install the package in a "supported" way,  "track
dependency issues" duty is reduced as nothing non-modular can depend
on the package, and so on.

[1] https://github.com/fedora-java/javapackages
[2] https://src.fedoraproject.org/rpms/javapackages-tools
[3] 
https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/

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

[Mikolaj Izdebski]

On Thu, Sep 10, 2020 at 4:04 PM Petr Pisar  wrote:
>
> On Thu, Sep 10, 2020 at 02:35:13PM +0100, Daniel P. Berrangé wrote:
> > On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote:
> >
> > > 4.  The benefit we want to preserve from modules is to maintain packages
> > > with varying expectation of quality, specifically separating the
> > > build-time-only vs runtime dependencies.  e.g. in that case that a web
> > > server like Eclipse Jetty is required as a dep for testing another
> > > component during the build, we want to be able to use and build that
> > > component, without being indefinitely on the hook for security errata.
> > > (The build dependency tree is particularly complex for Maven and
> > > involves many examples of packages with frequent and high severity
> > > vulnerabilies)
> >
> > What are you doing different in terms of supporting deps in the module
> > that reduces the security errata burden, compared to non-modular builds ?
> >
> > It feels like if we have some policy that is creating unsustainable
> > maint burden wrt non-modular packaging, we should re-examine this
> > policy rather than trying to workaround it by going modular, which
> > creates a different kind of maint burden.
> >
> In non-modular Fedora all packages that we have in Fedora build system (Koji)
> are tagged into Fedora repositories and made available to all users on their
> computers for any purpose. That implies that all packages in Fedora build 
> system
> must be fully supported including addressing all security issues.
>
> In modular Fedora that's (effectively) not true. Packages that only exist
> for the sake of building other packages (i.e. build-only dependencies) can be
> retained in the Fedora build system and never left it. That means those
> packages are never made available to Fedora users and thus a service level for
> them is significantly lower. E.g. no security fixes, not bug fixes, no
> integration, not tests, no API/ABI stability. The only requirement is that
> they can be built and used for building other packages.
>
> I wrote that it was not effectively true. There is probably no such policy
> that would de jure allowed lowering the service level for the build-only
> packages. But at the same time there is nobody who could enforce it. Users do
> not have the packages, security team does know about them, they cannot break
> a compose, and they do not intefere with packages from other modules. The only
> place where they are visible is dist-git and Koji. Thus they only need to pass
> a review (a legal requirement).

+1
That is very well put, thanks Petr for explaining it in detail.

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

[Alexander Scheel]

On Thu, Sep 10, 2020 at 10:11 AM Aleksandar Kurtakov
 wrote:
>
>
>
> On Thu, Sep 10, 2020 at 4:46 PM Alexander Scheel  wrote:
>>
>> Hi Joe,
>>
>> On Thu, Sep 10, 2020 at 8:52 AM Joe Orton  wrote:
>> >
>> > Hi all,
>> >
>> > I'm writing as the Red Hat engineering manager responsible for Maven and
>> > Ant in RHEL, and on behalf of Mikolaj Izdebski and Marian Koncek from my
>> > team.  I want to give a broad response to some of the points here:
>> >
>> > 1.  The team has two missions in Fedora:
>> >
>> > a) We deliver, maintain and support Ant and Maven in Fedora. Our aim is
>> > to provide developers with the most popular Java build systems which are
>> > reviewed, tested, and updated through the release lifecycle.
>> >
>> > b) We design, develop and document tooling that enables anyone to
>> > package Java software with a simple, efficient and scalable process. We
>> > are also active members of Java SIG, collaborating on complex changes
>> > and guiding new contributors.
>> >
>> > 2.  We are committed to maintaining the Ant and Maven modules in
>> > Fedora.  We have always expected to make them available as default
>> > streams and in the buildroot so they can be available and consumed by
>> > non-modular packages, but we completely respect the decisions of FESCo
>> > to disallow default streams and of other contributors to adopt and
>> > maintain the non-modular packages.  We are not going to promise to
>> > commit time and resources to maintain the non-modular packages.
>>
>> As a reminder (as in my RHEL devel-list reply): there are no default
>> module streams in Fedora. There is also no Ursa Major/Prime, so were
>> they to exist, there would still be no way for non-modular packages to
>> use them.
>>
>> This makes the artifacts produced here useful only to other modules.
>> Non-modular packages maintained by other Red Hatters, like Eclipse and
>> Dogtag PKI cannot use these artifacts. Both of these stacks have tried
>> to modularize in Fedora but ultimately remained non-modular.
>
>
> FWIW, I'm eagerly looking to stop packaging Eclipse as RPM entirely. Flatpak 
> is way better suited for our use case and in addition gives us access to a 
> way bigger install base. And the involvement on Java packaging in Fedora is 
> so low that we literally have to maintain whole other stacks including jetty, 
> lucene and etc. - not feasible work in any way.

Mat Booth (also from the Eclipse team!) still actively helps out with
this packaging as RPMs and we thank him for his efforts while they
last. :-)

But Flatpak isn't suitable for everyone--it isn't great for servers
like Dogtag and IdM for instance. So we still need RPM packaging
around for that.

Also, does that mean Eclipse won't be in RHEL-9? So far it looks like
it is not rebuilt for ELN so it seems likely it won't be.

https://koji.fedoraproject.org/koji/packageinfo?packageID=183


- Alex

>
>>
>>
>> > 3.  Our efforts are currently directed mainly at minimization of the
>> > dependency tree which leads to maven and ant, automating the process of
>> > bootstrapping maven and updating related components, so that new
>> > versions can be imported and built reproducibly and with consistent
>> > quality.
>> >
>> > 4.  The benefit we want to preserve from modules is to maintain packages
>> > with varying expectation of quality, specifically separating the
>> > build-time-only vs runtime dependencies.  e.g. in that case that a web
>> > server like Eclipse Jetty is required as a dep for testing another
>> > component during the build, we want to be able to use and build that
>> > component, without being indefinitely on the hook for security errata.
>> > (The build dependency tree is particularly complex for Maven and
>> > involves many examples of packages with frequent and high severity
>> > vulnerabilies)
>> >
>> > Regards, Joe
>> > ___
>> > 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
>
>
>
> --
> 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 

HEADS UP: malcontent is available in rawhide

[Kalev Lember]

Hi all,

Bastien Nocera asked me to send a heads up that he has packaged up
'malcontent' library and it's available in rawhide buildroots in case
apps want to start using it. malcontent is a library that implements
parental control support.

He's not subscribed so I'm just relying the info :) Please direct any 
questions to him. Thanks!


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

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

[Tomasz Torcz]

On Thu, Sep 10, 2020 at 04:03:46PM +0200, Petr Pisar wrote:
> In non-modular Fedora all packages that we have in Fedora build system (Koji)
> are tagged into Fedora repositories and made available to all users on their
> computers for any purpose. That implies that all packages in Fedora build 
> system
> must be fully supported including addressing all security issues.
> 
> In modular Fedora that's (effectively) not true. Packages that only exist
> for the sake of building other packages (i.e. build-only dependencies) can be
> retained in the Fedora build system and never left it. That means those
> packages are never made available to Fedora users and thus a service level for
> them is significantly lower. E.g. no security fixes, not bug fixes, no
> integration, not tests, no API/ABI stability. The only requirement is that
> they can be built and used for building other packages.


  So, if user wants to locally rebuild the package, they won't be able to
do it? Because BuildRequired packages won't be available?


-- 
Tomasz Torcz“Funeral in the morning, IDE hacking
to...@pipebreaker.pl in the afternoon and evening.” - Alan Cox
___
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)

[Mikolaj Izdebski]

On Thu, Sep 10, 2020 at 3:46 PM Alexander Scheel  wrote:
>
> Hi Joe,
>
> On Thu, Sep 10, 2020 at 8:52 AM Joe Orton  wrote:
> >
> > Hi all,
> >
> > I'm writing as the Red Hat engineering manager responsible for Maven and
> > Ant in RHEL, and on behalf of Mikolaj Izdebski and Marian Koncek from my
> > team.  I want to give a broad response to some of the points here:
> >
> > 1.  The team has two missions in Fedora:
> >
> > a) We deliver, maintain and support Ant and Maven in Fedora. Our aim is
> > to provide developers with the most popular Java build systems which are
> > reviewed, tested, and updated through the release lifecycle.
> >
> > b) We design, develop and document tooling that enables anyone to
> > package Java software with a simple, efficient and scalable process. We
> > are also active members of Java SIG, collaborating on complex changes
> > and guiding new contributors.
> >
> > 2.  We are committed to maintaining the Ant and Maven modules in
> > Fedora.  We have always expected to make them available as default
> > streams and in the buildroot so they can be available and consumed by
> > non-modular packages, but we completely respect the decisions of FESCo
> > to disallow default streams and of other contributors to adopt and
> > maintain the non-modular packages.  We are not going to promise to
> > commit time and resources to maintain the non-modular packages.
>
> As a reminder (as in my RHEL devel-list reply): there are no default
> module streams in Fedora. There is also no Ursa Major/Prime, so were
> they to exist, there would still be no way for non-modular packages to
> use them.

There are default module streams in Fedora 31.

> This makes the artifacts produced here useful only to other modules.
> Non-modular packages maintained by other Red Hatters, like Eclipse and
> Dogtag PKI cannot use these artifacts. Both of these stacks have tried
> to modularize in Fedora but ultimately remained non-modular.

Our goal is to deliver Maven and Ant to end users, maintaining
dependencies of Dogtag PKI is outside of my area of interest.
End users can consume Maven and Ant from the modules, which aligns
with our mission statement.

> > 3.  Our efforts are currently directed mainly at minimization of the
> > dependency tree which leads to maven and ant, automating the process of
> > bootstrapping maven and updating related components, so that new
> > versions can be imported and built reproducibly and with consistent
> > quality.
> >
> > 4.  The benefit we want to preserve from modules is to maintain packages
> > with varying expectation of quality, specifically separating the
> > build-time-only vs runtime dependencies.  e.g. in that case that a web
> > server like Eclipse Jetty is required as a dep for testing another
> > component during the build, we want to be able to use and build that
> > component, without being indefinitely on the hook for security errata.
> > (The build dependency tree is particularly complex for Maven and
> > involves many examples of packages with frequent and high severity
> > vulnerabilies)
> >
> > Regards, Joe
> > ___
> > 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)

[Mikolaj Izdebski]

On Thu, Sep 10, 2020 at 4:35 PM Tomasz Torcz  wrote:
>
> On Thu, Sep 10, 2020 at 04:03:46PM +0200, Petr Pisar wrote:
> > In non-modular Fedora all packages that we have in Fedora build system 
> > (Koji)
> > are tagged into Fedora repositories and made available to all users on their
> > computers for any purpose. That implies that all packages in Fedora build 
> > system
> > must be fully supported including addressing all security issues.
> >
> > In modular Fedora that's (effectively) not true. Packages that only exist
> > for the sake of building other packages (i.e. build-only dependencies) can 
> > be
> > retained in the Fedora build system and never left it. That means those
> > packages are never made available to Fedora users and thus a service level 
> > for
> > them is significantly lower. E.g. no security fixes, not bug fixes, no
> > integration, not tests, no API/ABI stability. The only requirement is that
> > they can be built and used for building other packages.
>
>
>   So, if user wants to locally rebuild the package, they won't be able to
> do it? Because BuildRequired packages won't be available?

Modules can be built locally with "fedpkg module-build-local", which
downloads required dependencies from Koji and installs them in mock
chroot. These packages are not installed directly (outsides of chroot)
on users systems.


>
>
> --
> Tomasz Torcz“Funeral in the morning, IDE hacking
> to...@pipebreaker.pl in the afternoon and evening.” - Alan Cox
> ___
> 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: Remove support for SELinux runtime disable (System-Wide Change)

[Ondrej Mosnacek]

On Thu, Sep 10, 2020 at 4:05 PM Michal Schorm  wrote:
> On Thu, Sep 10, 2020 at 3:58 PM Ondrej Mosnacek  wrote:
> > On Thu, Sep 10, 2020 at 3:48 PM Michal Schorm  wrote:
> > > Does this mean, the "setenforce 0" won't work anymore?
> > No, no, don't worry, "setenforce 0" (i.e. switching SELinux to
> > "Permissive" mode) would not be affected and would work as before.
>
> That wasn't clear to me.
> Might be nice to add such a few words to the proposal.

Good point! I added a note about permissive vs. disabled to the summary:
https://fedoraproject.org/w/index.php?title=Changes%2FRemove_Support_For_SELinux_Runtime_Disable=revision=587713=587708

Thanks,

-- 
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
___
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)

[Dominik 'Rathann' Mierzejewski]

On Thursday, 10 September 2020 at 14:50, Joe Orton wrote:
[...]
> 1.  The team has two missions in Fedora:
> 
> a) We deliver, maintain and support Ant and Maven in Fedora. Our aim
> is to provide developers with the most popular Java build systems
> which are reviewed, tested, and updated through the release
> lifecycle. 
> 
> b) We design, develop and document tooling that enables anyone to
> package Java software with a simple, efficient and scalable process.
> We are also active members of Java SIG, collaborating on complex
> changes and guiding new contributors.
> 
> 2.  We are committed to maintaining the Ant and Maven modules in
> Fedora.  We have always expected to make them available as default
> streams and in the buildroot so they can be available and consumed by
> non-modular packages, but we completely respect the decisions of FESCo
> to disallow default streams and of other contributors to adopt and
> maintain the non-modular packages.  We are not going to promise to
> commit time and resources to maintain the non-modular packages.

Points 1b and 2 mean that nobody can consume your packages for
maintaining non-modular Java packages, which raises the bar for
maintaining Java packages considerably.

For example, I wanted to maintain a couple of Java packages, but I
didn't have time to (learn how to) maintain modules. This effectively
means that certain software won't be packaged for Fedora (by me). I
certainly don't have the time to maintain non-modular Ant and Maven
packages in addition to what I actually wanted to maintain. I'm pretty
sure there are quite a few people in a similar position.

[...]
> 4.  The benefit we want to preserve from modules is to maintain
> packages with varying expectation of quality, specifically separating
> the build-time-only vs runtime dependencies.  e.g. in that case that a
> web server like Eclipse Jetty is required as a dep for testing another
> component during the build, we want to be able to use and build that
> component, without being indefinitely on the hook for security
> errata.  (The build dependency tree is particularly complex for Maven
> and involves many examples of packages with frequent and high severity
> vulnerabilies)

On one hand, that's understandable, but you're effectively maintaining
those packages anyway. And I don't see any reason why you couldn't do
that in the traditional non-modular way, which makes it easier for
others to step in and co-maintain. I'm not sure what you mean by
"indefinitely on the hook for security errata". Can you elaborate?

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

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

[Alexander Scheel]

Hi Joe,

On Thu, Sep 10, 2020 at 8:52 AM Joe Orton  wrote:
>
> Hi all,
>
> I'm writing as the Red Hat engineering manager responsible for Maven and
> Ant in RHEL, and on behalf of Mikolaj Izdebski and Marian Koncek from my
> team.  I want to give a broad response to some of the points here:
>
> 1.  The team has two missions in Fedora:
>
> a) We deliver, maintain and support Ant and Maven in Fedora. Our aim is
> to provide developers with the most popular Java build systems which are
> reviewed, tested, and updated through the release lifecycle.
>
> b) We design, develop and document tooling that enables anyone to
> package Java software with a simple, efficient and scalable process. We
> are also active members of Java SIG, collaborating on complex changes
> and guiding new contributors.
>
> 2.  We are committed to maintaining the Ant and Maven modules in
> Fedora.  We have always expected to make them available as default
> streams and in the buildroot so they can be available and consumed by
> non-modular packages, but we completely respect the decisions of FESCo
> to disallow default streams and of other contributors to adopt and
> maintain the non-modular packages.  We are not going to promise to
> commit time and resources to maintain the non-modular packages.

As a reminder (as in my RHEL devel-list reply): there are no default
module streams in Fedora. There is also no Ursa Major/Prime, so were
they to exist, there would still be no way for non-modular packages to
use them.

This makes the artifacts produced here useful only to other modules.
Non-modular packages maintained by other Red Hatters, like Eclipse and
Dogtag PKI cannot use these artifacts. Both of these stacks have tried
to modularize in Fedora but ultimately remained non-modular.

> 3.  Our efforts are currently directed mainly at minimization of the
> dependency tree which leads to maven and ant, automating the process of
> bootstrapping maven and updating related components, so that new
> versions can be imported and built reproducibly and with consistent
> quality.
>
> 4.  The benefit we want to preserve from modules is to maintain packages
> with varying expectation of quality, specifically separating the
> build-time-only vs runtime dependencies.  e.g. in that case that a web
> server like Eclipse Jetty is required as a dep for testing another
> component during the build, we want to be able to use and build that
> component, without being indefinitely on the hook for security errata.
> (The build dependency tree is particularly complex for Maven and
> involves many examples of packages with frequent and high severity
> vulnerabilies)
>
> Regards, Joe
> ___
> 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: Remove support for SELinux runtime disable (System-Wide Change)

[Michal Schorm]

On Thu, Sep 10, 2020 at 3:58 PM Ondrej Mosnacek  wrote:
> On Thu, Sep 10, 2020 at 3:48 PM Michal Schorm  wrote:
> > Does this mean, the "setenforce 0" won't work anymore?
> No, no, don't worry, "setenforce 0" (i.e. switching SELinux to
> "Permissive" mode) would not be affected and would work as before.

That wasn't clear to me.
Might be nice to add such a few words to the proposal.

Thanks for clarification.

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
___
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)

[Petr Pisar]

On Thu, Sep 10, 2020 at 02:35:13PM +0100, Daniel P. Berrangé wrote:
> On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote:
> 
> > 4.  The benefit we want to preserve from modules is to maintain packages 
> > with varying expectation of quality, specifically separating the 
> > build-time-only vs runtime dependencies.  e.g. in that case that a web 
> > server like Eclipse Jetty is required as a dep for testing another 
> > component during the build, we want to be able to use and build that 
> > component, without being indefinitely on the hook for security errata.  
> > (The build dependency tree is particularly complex for Maven and 
> > involves many examples of packages with frequent and high severity 
> > vulnerabilies)
> 
> What are you doing different in terms of supporting deps in the module
> that reduces the security errata burden, compared to non-modular builds ?
> 
> It feels like if we have some policy that is creating unsustainable
> maint burden wrt non-modular packaging, we should re-examine this
> policy rather than trying to workaround it by going modular, which
> creates a different kind of maint burden.
> 
In non-modular Fedora all packages that we have in Fedora build system (Koji)
are tagged into Fedora repositories and made available to all users on their
computers for any purpose. That implies that all packages in Fedora build system
must be fully supported including addressing all security issues.

In modular Fedora that's (effectively) not true. Packages that only exist
for the sake of building other packages (i.e. build-only dependencies) can be
retained in the Fedora build system and never left it. That means those
packages are never made available to Fedora users and thus a service level for
them is significantly lower. E.g. no security fixes, not bug fixes, no
integration, not tests, no API/ABI stability. The only requirement is that
they can be built and used for building other packages.

I wrote that it was not effectively true. There is probably no such policy
that would de jure allowed lowering the service level for the build-only
packages. But at the same time there is nobody who could enforce it. Users do
not have the packages, security team does know about them, they cannot break
a compose, and they do not intefere with packages from other modules. The only
place where they are visible is dist-git and Koji. Thus they only need to pass
a review (a legal requirement).

-- Petr


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

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

[Richard Hughes]

On Thu, 10 Sep 2020 at 12:38, Neal Gompa  wrote:
> Because Red Hat customers put the SELinux policy developers into
> no-win situations: they complain about AVC denials that don't actually
> significantly break anything in *their* app

My response to that would be to ship a "AVC ignore-list" config file
in userspace alongside the customer application -- rather than just
pretending that SELinux didn't do anything at all for all apps.

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

Fedora 33 compose report: 20200910.n.0 changes

[Fedora Rawhide Report]

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

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

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

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  kde-settings-33.0-1.fc33
Old package:  kde-settings-32.2-2.fc33
Summary:  Config files for kde
RPMs: kde-settings kde-settings-plasma kde-settings-pulseaudio 
qt-settings
Size: 61.02 KiB
Size change:  385 B
Changelog:
  * Tue Sep 08 2020 Than Ngo  - 33-1
  - bump for Fedora 33
  - Fix background image (RHBZ #1872054)



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

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

[Daniel P . Berrangé]

On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote:

> 4.  The benefit we want to preserve from modules is to maintain packages 
> with varying expectation of quality, specifically separating the 
> build-time-only vs runtime dependencies.  e.g. in that case that a web 
> server like Eclipse Jetty is required as a dep for testing another 
> component during the build, we want to be able to use and build that 
> component, without being indefinitely on the hook for security errata.  
> (The build dependency tree is particularly complex for Maven and 
> involves many examples of packages with frequent and high severity 
> vulnerabilies)

What are you doing different in terms of supporting deps in the module
that reduces the security errata burden, compared to non-modular builds ?

It feels like if we have some policy that is creating unsustainable
maint burden wrt non-modular packaging, we should re-examine this
policy rather than trying to workaround it by going modular, which
creates a different kind of maint burden.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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-20200910.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 6/181 (x86_64)

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

ID: 660789  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/660789
ID: 660818  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/660818
ID: 660823  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/660823
ID: 660844  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/660844
ID: 660866  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/660866
ID: 660885  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/660885

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

ID: 660714  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/660714
ID: 660733  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/660733
ID: 660760  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/660760
ID: 660773  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/660773
ID: 660793  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/660793
ID: 660796  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/660796
ID: 660810  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/660810
ID: 660822  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/660822
ID: 660847  Test: x86_64 universal upgrade_2_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/660847

Passed openQA tests: 166/181 (x86_64)

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

ID: 660713  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/660713
ID: 660787  Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/660787
ID: 660788  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/660788

Installed system changes in test x86_64 Server-boot-iso install_default: 
System load changed from 0.07 to 0.47
Previous test data: https://openqa.fedoraproject.org/tests/659716#downloads
Current test data: https://openqa.fedoraproject.org/tests/660712#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
System load changed from 0.16 to 0.33
Previous test data: https://openqa.fedoraproject.org/tests/659728#downloads
Current test data: https://openqa.fedoraproject.org/tests/660724#downloads

Installed system changes in test x86_64 Everything-boot-iso install_default: 
System load changed from 0.08 to 0.24
Previous test data: https://openqa.fedoraproject.org/tests/659758#downloads
Current test data: https://openqa.fedoraproject.org/tests/660754#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
Used swap changed from 8 MiB to 10 MiB
1 packages(s) added since previous compose: f33-backgrounds-kde
2 packages(s) removed since previous compose: f32-backgrounds-base, 
f32-backgrounds-kde
System load changed from 1.47 to 1.59
Previous test data: https://openqa.fedoraproject.org/tests/659780#downloads
Current test data: https://openqa.fedoraproject.org/tests/660776#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
Used swap changed from 11 MiB to 9 MiB
1 packages(s) added since previous compose: f33-backgrounds-kde
2 packages(s) removed since previous compose: f32-backgrounds-base, 
f32-backgrounds-kde
System load changed from 1.07 to 0.93
Previous test data: https://openqa.fedoraproject.org/tests/659781#downloads
Current test data: https://openqa.fedoraproject.org/tests/660777#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default_upload: 
Mount /run/user/979 appeared since previous compose
Used swap changed from 19 MiB to 28 MiB
2 services(s) added since previous compose: user-runtime-dir@979.service, 
user@979.service
System load changed from 0.35 to 0.56
Previous test data: https://openqa.fedoraproject.org/tests/659797#downloads
Current test data: https://openqa.fedoraproject.org/tests/660793#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default@uefi: 
Mount /run/user/979 disappeared since previous compose
Used swap changed from 27 MiB to 22 MiB
2 services(s) 

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

[Ondrej Mosnacek]

On Thu, Sep 10, 2020 at 2:28 PM Richard Hughes  wrote:
> On Thu, 10 Sep 2020 at 12:38, Neal Gompa  wrote:
> > Because Red Hat customers put the SELinux policy developers into
> > no-win situations: they complain about AVC denials that don't actually
> > significantly break anything in *their* app
>
> My response to that would be to ship a "AVC ignore-list" config file
> in userspace alongside the customer application -- rather than just
> pretending that SELinux didn't do anything at all for all apps.

That has another disadvantage, though: all the false-positive denials
would then fill up the audit log (the frequency can be quite high),
i.e. either taking up extra space on disk or pushing out other,
potentially valuable, audit records. Not to mention the CPU cycles
wasted by the audit stack to process the records. Dontaudit by default
+ semodule -DB for debugging is IMHO the only reasonable compromise.

Anyway, this is getting off-topic w,r,t. the proposal. Please start a
new thread if you want to continue discussing dontaudit rules.

--
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
___
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)

[Ondrej Mosnacek]

On Thu, Sep 10, 2020 at 3:48 PM Michal Schorm  wrote:
> Does this mean, the "setenforce 0" won't work anymore?

No, no, don't worry, "setenforce 0" (i.e. switching SELinux to
"Permissive" mode) would not be affected and would work as before.

The proposal is only about fully disabling SELinux. Gentoo happens to
have a nice article about the different SELinux modes/states:
https://wiki.gentoo.org/wiki/SELinux/Tutorials/Permissive_versus_enforcing

-- 
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
___
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)

[Joe Orton]

Hi all,

I'm writing as the Red Hat engineering manager responsible for Maven and 
Ant in RHEL, and on behalf of Mikolaj Izdebski and Marian Koncek from my 
team.  I want to give a broad response to some of the points here:

1.  The team has two missions in Fedora:

a) We deliver, maintain and support Ant and Maven in Fedora. Our aim is 
to provide developers with the most popular Java build systems which are 
reviewed, tested, and updated through the release lifecycle. 

b) We design, develop and document tooling that enables anyone to 
package Java software with a simple, efficient and scalable process. We 
are also active members of Java SIG, collaborating on complex changes 
and guiding new contributors.

2.  We are committed to maintaining the Ant and Maven modules in 
Fedora.  We have always expected to make them available as default 
streams and in the buildroot so they can be available and consumed by 
non-modular packages, but we completely respect the decisions of FESCo 
to disallow default streams and of other contributors to adopt and 
maintain the non-modular packages.  We are not going to promise to 
commit time and resources to maintain the non-modular packages.

3.  Our efforts are currently directed mainly at minimization of the 
dependency tree which leads to maven and ant, automating the process of 
bootstrapping maven and updating related components, so that new 
versions can be imported and built reproducibly and with consistent 
quality.

4.  The benefit we want to preserve from modules is to maintain packages 
with varying expectation of quality, specifically separating the 
build-time-only vs runtime dependencies.  e.g. in that case that a web 
server like Eclipse Jetty is required as a dep for testing another 
component during the build, we want to be able to use and build that 
component, without being indefinitely on the hook for security errata.  
(The build dependency tree is particularly complex for Maven and 
involves many examples of packages with frequent and high severity 
vulnerabilies)

Regards, Joe
___
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)

[Mauricio Tavares]

On Thu, Sep 10, 2020 at 7:38 AM Neal Gompa  wrote:
>
> On Thu, Sep 10, 2020 at 7:33 AM Richard Hughes  wrote:
> >
> > On Thu, 10 Sep 2020 at 10:17, Tom Hughes  wrote:
> > > > Speaking from personal experience, I've wasted days over the last
> > > > decade trying to debug a locally installed system service that was not
> > > > working where there were no messages in any of the logs (e.g. no AVCs)
> > > > -- and turning off selinux at runtime magically fixed the problem.
> > >
> > > Some selinux rules are marked to not generate AVCs...
> >
> > Why!? There's sometimes no log output anywhere obvious that a syscall
> > or something was blocked. It's the reason I turn off selinux on my
> > work development machine, and I've often wasted *hours* of my life on
> > code "doing something impossible" over the last decade until a neuron
> > at the back of my brain remembers "you've not yet turned off selinux"
> > and then when I "sudo setenforce 0" it works, and I can't actually
> > file a bug as there's no indication of what selinux actually blocked
> > or why.
> >
>
> Because Red Hat customers put the SELinux policy developers into
> no-win situations: they complain about AVC denials that don't actually
> significantly break anything in *their* app and often just disable
> SELinux in those scenarios. Red Hat wants customers to use it and not
> freak out all the time, so these kinds of things get added because it
> is very hard to come up with the right rules for all cases and there's
> not enough time to work on that.
>
> (I know for a fact that more than a few dontaudit rules were the
> result of those kinds of conversations, because I witnessed them)
>
  Stupid question: if the audit just reports selinux barked but it
did not block, why completely block the reporting? Because customers
were freaking out about the entries in the audit log itself?
___
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)

[Petr Lautrbach]

On Wed, Sep 09, 2020 at 10:24:00AM +0200, Vít Ondruch wrote:
> 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.
> 

I've updated the page to:

- provide links which should descride LSM hooks and 
read-only-after-initialization protection.
- be more decriptive about the cuurent state and the change


https://fedoraproject.org/w/index.php?title=Changes%2FRemove_Support_For_SELinux_Runtime_Disable=revision=587708=587533

Thanks!

Petr

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

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

[Michal Schorm]

Does this mean, the "setenforce 0" won't work anymore?

I use it quite a lot to examine the denials and audit2allow to
generate updated rules which fixes my issues.

I would see the inability of such workflow as a major drawback for
*anyone* who doesn't just consume the default configuration.
e.g. "My database datadir should reside elsewhere"; "my container
should access pulseaudio socket"; "I've ran the default configuration
with my data and it crashed" ...

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1874683] perl-Locale-Codes-3.65 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Locale-Codes-3.65-1.fc |perl-Locale-Codes-3.65-1.fc
   |34  |34
   ||perl-Locale-Codes-3.65-1.fc
   ||32
 Resolution|--- |ERRATA
Last Closed||2020-09-10 17:31:15



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1872870] perl-Data-Validate-IP build for EPEL7

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Data-Validate-IP-0.27- |perl-Data-Validate-IP-0.27-
   |13.el7  |13.el7
   ||perl-Data-Validate-IP-0.27-
   ||13.el6



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-972f57ea6d   
drupal7-7.72-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b425525e83   
mbedtls-2.7.17-1.el6


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

IP2Location-8.0.9-6.el6
easy-rsa-3.0.8-1.el6

Details about builds:



 IP2Location-8.0.9-6.el6 (FEDORA-EPEL-2020-8a02de87b4)
 C library for mapping IP address to geolocation information

Update Information:

add patch to sync with upstream

ChangeLog:





 easy-rsa-3.0.8-1.el6 (FEDORA-EPEL-2020-8a0902a779)
 Simple shell based CA utility

Update Information:

3.0.8

ChangeLog:

* Thu Sep 10 2020 Gwyn Ciesla  - 3.0.8-1
- 3.0.8
* Mon Jul 27 2020 Fedora Release Engineering  - 
3.0.7-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild

References:

  [ 1 ] Bug #1877593 - easy-rsa-3.0.8 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1877593


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

[EPEL-devel] Re: Proposed EPEL Playground Documentation

[Troy Dawson]

On Wed, Sep 9, 2020 at 2:44 PM Miro Hrončok  wrote:
>
> On 08. 09. 20 17:52, Troy Dawson wrote:
> > Note1: Not everything has been implemented yet.  package.cfg is still
> > in the epel repos.  fedpkg has not been updated.  This documentation
> > will go out when those changes are implemented.
> >
> > Note2: This is a proposal.  It can be changed.  If there is something
> > in there you do not want or think should be re-worded, please say so.
>
> Is there a set of guidelines associated with epel8-playground? Such as, for 
> example:
>
> - New builds in epel8-playground should be done with higher NEVRs than builds 
> in
> epel8.
>
> - When an "experiment" in epel8-playground is finished (and either 
> "backported"
> to epel8 or abandoned), the builds should be untagged from playground, to 
> allow
> other maintainers to successfully conduct their own experiments without 
> building
> against a possibly obsolete version of your package.
>
> ...
>

Very good point.
I think that would go in the developer section.
I'll try to get an updated draft out tomorrow.
Troy
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[Bug 1831322] perl-POE-Test-Loops: please add epel8 branch

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-POE-Test-Loops-1.360-1
   ||8.el8
 Resolution|--- |ERRATA
Last Closed||2020-09-10 16:48:26



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1831322] perl-POE-Test-Loops: please add epel8 branch

[bugzilla]

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

Bug 1831324 Summary: perl-POE: please add epel8 branch
https://bugzilla.redhat.com/show_bug.cgi?id=1831324

   What|Removed |Added

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




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1831324] perl-POE: please add epel8 branch

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-POE-1.368-5.el8
 Resolution|--- |ERRATA
Last Closed||2020-09-10 16:48:28



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org