Re: Fedora Workstation and disabled by default firewall

[Christopher]

On Thu, Aug 29, 2019 at 1:08 AM John Harris  wrote:
>
> On Wednesday, August 28, 2019 10:00:35 PM MST Christopher wrote:
> > No, the default firewalld zone affects all Fedora Workstation users,
> > because firewalld runs outside of GNOME. Just because a user uses the
> > Workstation Edition doesn't mean they're running GNOME... you can
> > still run Cinnamon, XFCE, MATE, KDE, (or no graphical environment at
> > all) using the Workstation Edition. It's just that GNOME is the
> > default. So, this isn't a GNOME-specific issue. This is a Workstation
> > Edition issue with /etc/firewalld/firewalld.conf's DefaultZone option.
>
> How is that possible? The workstation installer installs GNOME, right? Can you
> select something else in those ISOs' Anaconda config? If so, why would it
> still pull in GNOME's firewall zone?
[SNIP]

We're getting off-topic, but really quickly: Yes, you can select
advanced packaging (at least you could in the past... probably still
can). You can also use kickstart to automate installs with custom
package installations and configuration using the same Workstation
ISO, and you can also just open a new TTY (e.g. Ctrl+Alt+F3),
customize your system, and reboot without ever logging in to GNOME.

It's not "GNOME's firewall zone". As previously mentioned, it's not
pulled in by GNOME at all. Rather, it's being provided by the
firewalld RPM itself, and configured by default, based on the contents
of /etc/os-release (which is provided by the
fedora-release-workstation RPM).

The main point is that it's not GNOME-specific at all, but it is
Workstation Edition-specific.
___
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 Workstation and disabled by default firewall

[John Harris]

On Wednesday, August 28, 2019 10:00:35 PM MST Christopher wrote:
> No, the default firewalld zone affects all Fedora Workstation users,
> because firewalld runs outside of GNOME. Just because a user uses the
> Workstation Edition doesn't mean they're running GNOME... you can
> still run Cinnamon, XFCE, MATE, KDE, (or no graphical environment at
> all) using the Workstation Edition. It's just that GNOME is the
> default. So, this isn't a GNOME-specific issue. This is a Workstation
> Edition issue with /etc/firewalld/firewalld.conf's DefaultZone option.

How is that possible? The workstation installer installs GNOME, right? Can you 
select something else in those ISOs' Anaconda config? If so, why would it 
still pull in GNOME's firewall zone?

> Funny, the FedoraServer.xml file still has a description "For use in
> public areas" while FedoraWorkstation.xml does not... as if servers
> are more likely than workstations to travel to "public areas" often.

You know, laptops move between networks a lot more frequently than servers. 
The majority of those would be running GNOME spin (Workstation), KDE spin or 
another DE's spin.

> :) I know it's because the server zone was derived from the public
> zone, which has that description, but it is still amusing.

That's because servers are often public facing, but so are laptops when 
they're on unknown networks, or even on peoples' own home networks, where we 
want a decent `trusted` config.

> FWIW, I actually prefer the public zone on my Workstation installs...
> and... it's actually the default upstream. Honestly, I'd prefer we
> just stick to that across all Editions/Spins.

As would I.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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 Workstation and disabled by default firewall

[Christopher]

On Wed, Aug 28, 2019 at 11:23 PM John Harris  wrote:
>
> On Wednesday, August 28, 2019 8:13:59 PM MST Christopher wrote:
> > The default firewall config affects every user of that edition, even
> > if they never use GNOME (or even use graphical boot). So, I don't know
> > if this would be adequate.
>
> This only affects GNOME users. Workstation = GNOME Spin.

No, the default firewalld zone affects all Fedora Workstation users,
because firewalld runs outside of GNOME. Just because a user uses the
Workstation Edition doesn't mean they're running GNOME... you can
still run Cinnamon, XFCE, MATE, KDE, (or no graphical environment at
all) using the Workstation Edition. It's just that GNOME is the
default. So, this isn't a GNOME-specific issue. This is a Workstation
Edition issue with /etc/firewalld/firewalld.conf's DefaultZone option.

>
> Unless I'm mistaken, and that installer is a generic Anaconda installer, where
> users can select the end product they want installed, in which case I'd have
> to ask why in the world that config would get pulled into the resulting
> system..

The configuration is being set in the resulting system by the
firewalld.spec itself when the firewalld RPM is installed:
See 
https://src.fedoraproject.org/rpms/firewalld/blob/9ef9382b5/f/firewalld.spec#_122-136
and 
https://src.fedoraproject.org/rpms/firewalld/blob/9ef9382b5/f/firewalld.spec#_154-174
and 
https://src.fedoraproject.org/rpms/firewalld/blob/9ef9382b5/f/FedoraWorkstation.xml#_7-9

For comparison, the FedoraServer.xml is much more secure:
https://src.fedoraproject.org/rpms/firewalld/blob/9ef9382b5/f/FedoraServer.xml

Funny, the FedoraServer.xml file still has a description "For use in
public areas" while FedoraWorkstation.xml does not... as if servers
are more likely than workstations to travel to "public areas" often.
:) I know it's because the server zone was derived from the public
zone, which has that description, but it is still amusing.

FWIW, I actually prefer the public zone on my Workstation installs...
and... it's actually the default upstream. Honestly, I'd prefer we
just stick to that across all Editions/Spins.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: New release of Mock (fixes and subscription-manager support)

[Orion Poplawski]

On 8/27/19 9:08 AM, Stephen John Smoogen wrote:

On Tue, 27 Aug 2019 at 10:20, Miroslav Suchý  wrote:


Hi,
I released new version of Mock and mock-core-configs. For full release notes 
see:
   https://github.com/rpm-software-management/mock/wiki/Release-Notes-1.4.18
I just submitted packages to Bodhi.

I would like to point two things here:

1) It should fixes all those issues you reported in past days (selinux, 
rprivate, groupadd).
2) Mock now supports subscription-manager, which allows you to build packages 
for RHEL with cost-free developer license.
No need to wait for CentOS 8.

Big thanks to Pavel Raiskup who done those two things.


Note that this drops python2 support. You will need Python36 on any
system using.

Also note that mock will no longer be targeted to build on EL-7
systems sometime next spring (2020). I believe this means that mock
will no longer be supported or built in EPEL-7 as it is probably no
longer built in EPEL-6 these days. You will need to use EL-8 boxes to
build but can target EL-6/EL-7 builds. [I don't know if you can build
EL-5 but I know people need to do so still so I am not sure how to do
that.]


Well, building much of anything new in Fedora land on EL-7 seems pretty 
much impossible due to rpm changes so the useful lifetime of EL-7 for a 
Fedora and EPEL contributor is already essentially at an end.  Centos 8 
can't come fast enough...



--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: [HEADS UP] Retiring python2 and introducing python27 later this week

[Scott Talbert]

> On 27. 08. 19 22:20, Miro Hrončok wrote:
> 
> python27 build in progress.
> 
> Will retire python2 later tomorrow or on Friday (in case something is 
> terribly 
> broken I want to have some maneuvering space).

Hey Miro,

I can't rebuild python-wxpython4 with the new python27.  This is what I'm 
seeing in the logs but it seems that the root cause is that 
/usr/include/python2.7/pyconfig-64.h is missing?

[1/2] Compiling 
build/waf/2.7/gtk3/.conf_check_5549a18d8958579571e1d4f3f7111de9/test.cpp

['/usr/bin/g++', '-fPIC', '-fno-strict-aliasing', '-O2', '-g', '-fexceptions', 
'-fstack-protector-strong', '-grecord-gcc-switches', '-m64', '-mtune=generic', 
'-fasynchronous-unwind-tables', '-fstack-clash-protection', '-fcf-protection', 
'-fPIC', '-fwrapv', '-O2', '-g', '-fexceptions', '-fstack-protector-strong', 
'-grecord-gcc-switches', '-m64', '-mtune=generic', 
'-fasynchronous-unwind-tables', '-fstack-clash-protection', '-fcf-protection', 
'-fPIC', '-fwrapv', '-I/usr/include/python2.7', 
'-DPYTHONDIR="/usr/local/lib/python2.7/site-packages"', 
'-DPYTHONARCHDIR="/usr/local/lib64/python2.7/site-packages"', '-D_GNU_SOURCE', 
'-DNDEBUG', '-D_GNU_SOURCE', '../test.cpp', '-c', 
'-o/builddir/build/BUILD/python-wxpython4-4.0.6/python2/build/waf/2.7/gtk3/.conf_check_5549a18d8958579571e1d4f3f7111de9/testbuild/test.cpp.1.o']
err: In file included from /usr/include/python2.7/Python.h:8,
 from ../test.cpp:2:
/usr/include/python2.7/pyconfig.h:6:10: fatal error: pyconfig-64.h: No such 
file or directory
6 | #include "pyconfig-64.h"
  |  ^~~
compilation terminated.

from /builddir/build/BUILD/python-wxpython4-4.0.6/python2: Test does not build: 
Traceback (most recent call last):
  File 
"/builddir/build/BUILD/python-wxpython4-4.0.6/python2/bin/.waf-2.0.8-206f2b7a89029e71942a2beb9e1d/waflib/Configure.py",
 line 324, in run_build
bld.compile()
  File 
"/builddir/build/BUILD/python-wxpython4-4.0.6/python2/bin/.waf-2.0.8-206f2b7a89029e71942a2beb9e1d/waflib/Build.py",
 line 176, in compile
raise Errors.BuildError(self.producer.error)
BuildError: Build failed
 -> task in 'testprog' failed with exit status 1 (run with -v to display more 
information)

Could not build python extensions
from /builddir/build/BUILD/python-wxpython4-4.0.6/python2: The configuration 
failed
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org

Re: Fedora Workstation and disabled by default firewall

[John Harris]

On Wednesday, August 28, 2019 8:13:59 PM MST Christopher wrote:
> The default firewall config affects every user of that edition, even
> if they never use GNOME (or even use graphical boot). So, I don't know
> if this would be adequate.

This only affects GNOME users. Workstation = GNOME Spin.

Unless I'm mistaken, and that installer is a generic Anaconda installer, where 
users can select the end product they want installed, in which case I'd have 
to ask why in the world that config would get pulled into the resulting 
system..

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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 Workstation and disabled by default firewall

[Christopher]

On Wed, Aug 28, 2019 at 8:56 PM John Harris  wrote:
>
> On Wednesday, August 28, 2019 5:46:58 PM MST Christopher wrote:
> > A similar idea that would keep it separate from the installer might be
> > to offer a dialogue as a "first-boot" action, but that seems like it'd
> > be a very GNOME-specific thing, and firewalld is not specific to the
> > WM/Desktop.
>
> It might be okay to be a GNOME-specific thing, as that's the only spin of
> Fedora which is affected by this decision.
>

The default firewall config affects every user of that edition, even
if they never use GNOME (or even use graphical boot). So, I don't know
if this would be adequate.
___
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

[389-devel] 389 DS nightly 2019-08-29 - 96% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/08/29/report-389-ds-base-1.4.1.6-20190828git723b88a.fc30.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Docker releases of 389

[William Brown]

Hi all,

I've been wanting this for a long time and I think we're almost there - I'd 
like us to start offering docker images of 389 Directory Server as part of our 
upstream release process.

I have discussed this with Mark already and we both think we are reasonably 
happy with the idea and the state we're in.

-- The Technical Process and Details:

As there is significant interest within SUSE for containerised 389, as well as 
open tooling as part of build.opensuse.org, the current proposed process is:

Source Release -> OBS:network:ldap -> OBS:389-ds-container -> docker hub

Because this pipeline is automated between source to the container, and this is 
already part of my responsibility as the SUSE package manager, it's a small 
amount of effort to then mirror the container to docker hub.

I have already established an organisation on docker hub, and will be giving 
Mark access to be able to manage this as well.

https://cloud.docker.com/u/389ds/repository/list

Initially we'll name the image as:

389ds/dirsrv:1.4.rc

Once we are happy with the process, and have received some community feedback 
we'll move to:

389ds/dirsrv:1.4.1
389ds/dirsrv:1.4.2
389ds/dirsrv:1.4 # points to latest 1.4.X
389ds/dirsrv:latest # points to newest version

We would of course encourage people to use the "latest" tag.

-- Support

During the rc phase we would announce that the container support is "best 
effort" and we'll obviously work to resolve issues, but it's not suitable for 
production work loads.

Once we are happy with this for a few releases, we'll move to the same support 
levels as our normal releases - best effort community, and patch backporting as 
we normally do. For official support, contact a vendor like SUSE or Red Hat.

-- Future / Downstreams

The design of the container integration is such that we should be able to 
easily swap the suse/fedora/rhel as the base image, so downstreams should be 
able to easily adopt the dscontainer tool and have customers pivot from the 
upstream image to their vendor image quite easily. 

A future container option is to supply a tools container that has a shell + ds* 
tools, so that you can have a work flow such as:

docker run -v 389ds:/data 389ds/dirsrv:latest
docker run -i -t -v 389ds:/data 389ds/tools:latest
# shell inside of the tools container
# dsconf  

-- Testing today:

To test the image as it exists today:

docker pull 
registry.opensuse.org/home/firstyear/containers/389-ds-container:latest


Thoughts and feedback?

If there are no objects, I'll push the rc to docker hub early next week (2nd or 
3rd of Sep)

--
Sincerely,

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

Re: Fedora Workstation and disabled by default firewall

[James Cassell]

On Wed, Aug 28, 2019, at 8:59 PM, John Harris wrote:
> On Wednesday, August 28, 2019 1:35:32 PM MST Colin Walters wrote:
> > FWIW,
> > 
> > For Fedora CoreOS we don't enable a firewall by default; see
> > https://github.com/coreos/fedora-coreos-tracker/issues/26
> > 
> > (Neither for that matter does Fedora Cloud:
> >  https://pagure.io/fedora-kickstarts/blob/master/f/fedora-cloud-base.ks#_36)
> 
> Yikes! I suppose we should discuss these as well. Those are, in my opinion, 
> much more serious, as they COMPLETELY shut off the firewall. Especially for 
> what those systems are designed for, this is very concerning..
> 

This seems to be a common theme with cloud images. I believe the assumption is 
that each cloud has its own Access Control policies that serve the function of 
a firewall.

I always end up building my own cloud images with a firewall, partly for this 
reason.

I would tend to agree that Fedora Core OS should have a firewall, if only to 
well-define which ports are required; but I have not been active there.

V/r,
James Cassell
___
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: University people in Fedora: Education/University SIG

[Tim Zabel]

I think a SIG is a great start as a gathering place for other
university students. As shown in [2], it looks like a mailing list is
also one of the eventual goals :)



- Tim Zabel


On Wed, 2019-08-28 at 17:26 -0700, John Harris wrote:
> On Wednesday, August 28, 2019 9:42:15 AM MST Timothée Floure wrote:
> > Hello everyone,
> > 
> > This is a follow-up email for some "coffee discussions" we had at
> > flock a
> > few weeks ago. Sorry for the delay!
> > 
> > The Fedora community contains a lot of university students, many of
> > us
> > packaging tools for their courses and acting as first-level Linux
> > support
> > for the local student community. The problems we encounter and work
> > on are
> > not identical but share a common base: it only makes sense to
> > collaborate.
> > 
> > We found (over a few flock coffee breaks) 5-6 fedorans interested
> > in joining
> > such an initiative and are currently creating a SIG as a mean to
> > communicate. We haven't decided on anything yet, except that we
> > would like
> > to work together to make Fedora an accessible platform for student
> > and
> > courses in an university context. We expect overlapping interests
> > and
> > collaboration with others SIGs, especially if related to the
> > academic world
> > such as NeuroFedora or ML.
> > 
> > We are aware of the dormant Education SIG [1] but have yet to
> > discuss how to
> > position - or integrate - ourselve.
> > 
> > A slightly more detailed description can be found on the related
> > wiki page
> > [2]. I invite you to add your name to its members section you're
> > interested
> > to work with us. We will figure out communication and coordination
> > mediums
> > around next week.
> > 
> > [1] https://fedoraproject.org/wiki/SIGs/Education
> > [2] https://fedoraproject.org/wiki/SIGs/University
> > 
> > Cheers,
> 
> You most likely don't need a SIG for that, you could just ask for a
> separate 
> mailing list to be created for you :)
> 
> -- 
> John M. Harris, Jr. 
> Splentity
> https://splentity.com/
> 
> ___
> 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 Workstation and disabled by default firewall

[John Harris]

On Wednesday, August 28, 2019 1:35:32 PM MST Colin Walters wrote:
> FWIW,
> 
> For Fedora CoreOS we don't enable a firewall by default; see
> https://github.com/coreos/fedora-coreos-tracker/issues/26
> 
> (Neither for that matter does Fedora Cloud:
>  https://pagure.io/fedora-kickstarts/blob/master/f/fedora-cloud-base.ks#_36)

Yikes! I suppose we should discuss these as well. Those are, in my opinion, 
much more serious, as they COMPLETELY shut off the firewall. Especially for 
what those systems are designed for, this is very concerning..

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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: Debates/back and forths

[Christopher]

On Wed, Aug 28, 2019 at 7:04 AM Danny Lee  wrote:
>
> Hi all,
>
> I'm new to the devel list and fedora in general, but i was wondering if
> these kind of back and forths between a few people is a frequent
> occurrence.  I came to Fedora to volunteer what little spare time I have
> to help the Fedora project in some little ways. I don't feel that should
> include wading through dozens of emailed back and forths between
> individuals who seem to have strong, immovable opinions, I just don't
> have time for that.
>
> Is there any chance there is a moderated list or discussion group about
> current project tasks and issues rather than debates about how to do
> things?  Or perhaps, a way to turn off certain threads or block certain
> posters?
>
> Thanks for your time and info you can provide.

First, welcome to Fedora!
Second, no... I don't think these are common. Long debate threads
occur probably a few times a year.

Debate can be a good thing in an open source community. Keeping it
productive can be a challenge. Any forum where people gather is likely
to have the same sort of conflicts. That said, devel@ is a *very*
active mailing list, so even if these kinds of threads didn't occur,
you're still probably going to want to find some way to filter the
list with your email client, for your own sanity. Personally, I use
GMail, where you can "mute" threads, but others have other solutions.
You'll want to find something that works for you. Most email clients
have filters.
___
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 Workstation and disabled by default firewall

[John Harris]

On Wednesday, August 28, 2019 5:46:58 PM MST Christopher wrote:
> A similar idea that would keep it separate from the installer might be
> to offer a dialogue as a "first-boot" action, but that seems like it'd
> be a very GNOME-specific thing, and firewalld is not specific to the
> WM/Desktop.

It might be okay to be a GNOME-specific thing, as that's the only spin of 
Fedora which is affected by this decision.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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 Workstation and disabled by default firewall

[John Harris]

On Wednesday, August 28, 2019 3:50:49 PM MST Chris Murphy wrote:
> A somewhat related feature that was rejected by FESCo
> https://fedoraproject.org/wiki/Changes/SecurityPolicyInTheInstaller
> https://lists.fedoraproject.org/pipermail/devel/2014-March/19.html

Security policies aren't related to the firewall, though they may include 
changes to the firewall (and blacklisting packages, etc). That's something 
much better suited for RHEL and CentOS though. Firewalls are useful 
everywhere.

> Again, hyperbole, that cannot be taken seriously, because it does not
> withstand even a little bit of scrutiny.

I must disagree, as it does stand up to scrutiny.
 
> I'm recently a member on the Workstation working group, I know the
> members on it. The reason why everyone is on it is because they care
> very much about, and respect the community immensely, and demonstrate
> it with deliberation and significant effort.

That's fantastic, and that's why we want to work with the WG to fix this issue 
with the product. We all want to make things better for the community.
 
> It's not good enough to just say things forcefully and expect that
> people will agree as if you're a hammer, and they're a nail. You have
> to work harder than you are working, if your goal really is to be
> persuasive.

Unfortunately, that doesn't change the security concerns with having a wide 
open firewall by default.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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 Workstation and disabled by default firewall

[Christopher]

On Wed, Aug 28, 2019 at 6:52 PM Chris Murphy  wrote:
>
> On Wed, Aug 28, 2019 at 12:57 PM Christopher  
> wrote:
> >
> > At the very least, it'd be nice if anaconda had an option to select
> > the default firewalld zone during installation,
>
> A somewhat related feature that was rejected by FESCo
> https://fedoraproject.org/wiki/Changes/SecurityPolicyInTheInstaller
> https://lists.fedoraproject.org/pipermail/devel/2014-March/19.html

I think the fact that the Workstation WG's proceeded with an
effectively disabled firewall after FESCo rejected the complete
disabling of it, somewhat undermines your point here about rejection
of a similar proposal being relevant to the current one.

In any case, I don't think these are that similar. I think this is
sufficiently different from that proposal. This is much more narrowly
scoped that a whole new security policy dialogue. It would be limited
to just an UI element in the existing network configuration
dialogue... in the same spirit as the familiar NetworkManager zone
selection dropdown that I recall seeing at some point (but not sure if
it's still there). It'd barely be different than adding "WPA3" as an
option to the same section of the installer (I use as an example,
because I think it's safe to assume that's the kind of installer
feature change that would be readily accepted).

>
> Neat idea. But complicates an already complicated installer. Many
> responses in that at the time, in devel@ and FESCo, were concerned
> about balancing out users even though they liked the overall idea.

Yeah, I also don't want a complicated installer. I just don't see this
disagreement going anywhere without some sort of compromise, and I
can't think of any others that will satisfy people. I think there's a
good chance this could be implemented without much complexity, though.
Thank you for giving the idea at least a little consideration, though,
and not outright dismissing it.

A similar idea that would keep it separate from the installer might be
to offer a dialogue as a "first-boot" action, but that seems like it'd
be a very GNOME-specific thing, and firewalld is not specific to the
WM/Desktop.

>
> Working group members have to make UI/Ux judgements all the time, and
> things not going the way you would have is not a good enough reason to
> impugn those making these decisions. You could have just said you
> disagree. But you went much further. You assert there is not only a
> lack of respect for the community, but that is it a complete lack. 0%.
> Not even 50/50?
>
> Again, hyperbole, that cannot be taken seriously, because it does not
> withstand even a little bit of scrutiny.
>

My statement was intended to be qualitative, not quantitative, but I
take your point. Yes, it was, in fact, hyperbole, and I apologize for
my poor word choice.

> I'm recently a member on the Workstation working group, I know the
> members on it. The reason why everyone is on it is because they care
> very much about, and respect the community immensely, and demonstrate
> it with deliberation and significant effort.

I'm sure that's true. I have no reason to doubt any of that. My
statements aren't about them as individuals... I've tried to be
careful about that, because 1) I don't think it's helpful to call out
individuals here, and 2) I don't think what I've said about the group
applies to the individuals (see
https://en.wikipedia.org/wiki/Fallacy_of_division).

>
> It's not good enough to just say things forcefully and expect that
> people will agree as if you're a hammer, and they're a nail. You have
> to work harder than you are working, if your goal really is to be
> persuasive.

I have tried to point to specific actions taken (or not taken) by the
WG that I think demonstrate the previous lack of respect I referred
to. I am not simply trying to persuade by saying things "forcefully"
(however that works). If you are not persuaded, that's fine.
___
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 Workstation and disabled by default firewall

[John Harris]

On Wednesday, August 28, 2019 12:59:17 PM MST Christopher wrote:
> Yeah, obviously that would be bad. Please don't simply dismiss a
> serious suggestion, because it would be bad in other scenarios or if
> taken to the extreme. This is one specific suggestion, not a proposal
> to accept all similar suggestions, and I'm not even convinced myself
> that this is the best possible solution. It just seemed like an idea
> worth considering, since the debate is raging on, has been raging on
> and off since 2014, and this proposal seems like it has potential to
> satisfy all parties once and for all (since it gets directly to the
> heart of the matter, eliminates user surprise, and fits naturally
> within the existing network setup portion of Anaconda).

That sounds like a great idea, with the rest of the configuration options for 
a given interface. That falls in line with where I'd expect the configuration 
option to be in the GUI in GNOME, and where it currently is in KDE. (I don't 
know if it's there in GNOME, but I think somebody earlier in the thread 
mentioned that it was removed)

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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 Workstation and disabled by default firewall

[John Harris]

On Wednesday, August 28, 2019 10:00:03 AM MST Chris Murphy wrote:
> This is hyperbole, and turning up the volume isn't going to make
> anyone go "oh, ok, now I see your point, it's hostile and we don't
> want to do that, let's change it" as if literally everyone reading
> this is some kind of moron.

I disagree. The description is a response to the earlier suggestion, that 
because something is already insecure, to a certain degree, that it should 
just be left that way.

> 
> Your position is shown to be weak if you have to use this distinctly
> non-objective tactic designed to evoke an emotional response in the
> reader. All you're doing is casually dismissing one side of a
> balancing act and then claiming the result as proof the policy should
> change. Guess what? Saying things does not make them true.

You're welcome to your opinion, but that doesn't make it so. I'm not 
dismissing anything.

> You should try to understand all of these arguments have happened
> before, and if you really want a change to happen, you need a produce
> a compelling new arguments.

See my other responses to this thread.

> Did the previous working group misunderstand something previously?

It seem so.

> Has new information come to light?

Yes, more people have realized what was done by the GNOME spin.

> Has the GUI firewall app made UI/Ux improvements that might sway the
> working group to re-evaluate?

Possibly, but that doesn't have anything to do with what needs to be done to 
provide our users with a more secure default.

> By all means shout more. And be ignored. Or do the hard work and put
> together a deliberate and compelling argument.

I have been addressing concerns as I see them. If you have a concern I have 
not addressed, please feel free to ask.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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

[389-devel] Please review 50567 and 50568

[William Brown]

https://pagure.io/389-ds-base/pull-request/50571



--
Sincerely,

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

Re: University people in Fedora: Education/University SIG

[John Harris]

On Wednesday, August 28, 2019 9:42:15 AM MST Timothée Floure wrote:
> Hello everyone,
> 
> This is a follow-up email for some "coffee discussions" we had at flock a
> few weeks ago. Sorry for the delay!
> 
> The Fedora community contains a lot of university students, many of us
> packaging tools for their courses and acting as first-level Linux support
> for the local student community. The problems we encounter and work on are
> not identical but share a common base: it only makes sense to collaborate.
> 
> We found (over a few flock coffee breaks) 5-6 fedorans interested in joining
> such an initiative and are currently creating a SIG as a mean to
> communicate. We haven't decided on anything yet, except that we would like
> to work together to make Fedora an accessible platform for student and
> courses in an university context. We expect overlapping interests and
> collaboration with others SIGs, especially if related to the academic world
> such as NeuroFedora or ML.
> 
> We are aware of the dormant Education SIG [1] but have yet to discuss how to
> position - or integrate - ourselve.
> 
> A slightly more detailed description can be found on the related wiki page
> [2]. I invite you to add your name to its members section you're interested
> to work with us. We will figure out communication and coordination mediums
> around next week.
> 
> [1] https://fedoraproject.org/wiki/SIGs/Education
> [2] https://fedoraproject.org/wiki/SIGs/University
> 
> Cheers,

You most likely don't need a SIG for that, you could just ask for a separate 
mailing list to be created for you :)

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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: Debates/back and forths

[John Harris]

On Wednesday, August 28, 2019 9:27:56 AM MST Chris Peters wrote:
> Maybe the code of conduct could politely nudge people towards *quality* over
> quantity (so that voices don't get drowned and big threads aren't so
> tiresome to keep up with)

Such a rule would make it very difficult indeed to address all concerns.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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: Debates/back and forths

[John Harris]

On Wednesday, August 28, 2019 5:09:23 AM MST Gerald B. Cox wrote:
> It's somewhat ironic that Discourse would solve this issue.  As I
> previously mentioned, I also don't like having my inbox flooded with forum
> threads that don't interest me.  The mailing list solution requires you
> setup filters or continuously delete dozens of emails.  Discourse however
> allows you to select what you want to read without needing to clean up
> afterwards.  As I also pointed out RSS would make HyperKitty a somewhat
> acceptable alternative - or as Kevin K. pointed out, you could also use
> NNTP.  I personally would rather not, but maybe that would fit your use
> case until a good solution could be implemented.
> 
> On Wed, Aug 28, 2019 at 4:42 AM Markus Larsson  wrote:
> > On 28 August 2019 13:34:54 CEST, "Dan Čermák" <
> > 
> > dan.cer...@cgc-instruments.com> wrote:
> > >Hi Danni,
> > >
> > >Danny Lee  writes:
> > >> Hi all,
> > >> 
> > >> I'm new to the devel list and fedora in general, but i was wondering
> > >
> > >if
> > >
> > >> these kind of back and forths between a few people is a frequent
> > >> occurrence.  I came to Fedora to volunteer what little spare time I
> > >
> > >have
> > >
> > >> to help the Fedora project in some little ways. I don't feel that
> > >
> > >should
> > >
> > >> include wading through dozens of emailed back and forths between
> > >> individuals who seem to have strong, immovable opinions, I just don't
> > >> 
> > >> have time for that.
> > >
> > >Welcome to the club of all the "silent" contributors!
> > >
> > >Usually I try to follow discussions if they appear relevant or
> > >interesting to me, but once they "tip over", I mark that thread as
> > >deleted and mercilessly nuke everything new that comes in.
> > >Yeah, I might miss some important information, but it's unlikely tbh
> > >once you are 20 replies deep into a thread.
> > >On the other hand: I don't want to spend all my free time reading
> > >emails.
> > >
> > >So, if you don't care about a specific topic: just ignore & delete it.
> > 
> > This is how I think most do it. Just read the interesting parts.
> > 
> > >Btw, this list is imho still pretty moderate, only the occasional
> > >controversy causes a huge thread of replies (and people manage to stay
> > >civilized and tend to bring in new arguments). There's other lists
> > >(unnamed to protect the guilty) where the signal to noise ratio is
> > >much,
> > >much worse.
> > 
> > The discourse debate and the fw debate are not the norm but the exception.
> > We see a few of those from time to time. Most threads aren't like that
> > though.
> > 
> > >> Is there any chance there is a moderated list or discussion group
> > >
> > >about
> > >
> > >> current project tasks and issues rather than debates about how to do
> > >> things?  Or perhaps, a way to turn off certain threads or block
> > >
> > >certain
> > >
> > >> posters?
> > >> 
> > >> Thanks for your time and info you can provide.

Discourse is not much different from email here. You can see the threads, and 
you choose whether or not you want to read them. If you don't want them to hit 
your inbox or notifications, you can click a button on your client to stop 
receiving future emails or notifications from that thread.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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 Workstation and disabled by default firewall

[John Harris]

On Wednesday, August 28, 2019 9:05:00 AM MST Tony Nelson wrote:
> Properly packaged Fedora software uses either the D-Bus interface
> at runtime or firewall-cmd in a scriptlet at install time to open any
> needed ports

This is not actually the case. No software, to my knowledge, makes the 
assumption that it's configured properly and ready to be open to the network, 
on installation.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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 1746533] Please build perl-Convert-TNEF for EPEL 8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-EPEL-2019-f23604e655 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f23604e655

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

Re: Fedora Workstation and disabled by default firewall

[Chris Murphy]

On Wed, Aug 28, 2019 at 12:57 PM Christopher  wrote:
>
> At the very least, it'd be nice if anaconda had an option to select
> the default firewalld zone during installation,

A somewhat related feature that was rejected by FESCo
https://fedoraproject.org/wiki/Changes/SecurityPolicyInTheInstaller
https://lists.fedoraproject.org/pipermail/devel/2014-March/19.html

Neat idea. But complicates an already complicated installer. Many
responses in that at the time, in devel@ and FESCo, were concerned
about balancing out users even though they liked the overall idea.

Working group members have to make UI/Ux judgements all the time, and
things not going the way you would have is not a good enough reason to
impugn those making these decisions. You could have just said you
disagree. But you went much further. You assert there is not only a
lack of respect for the community, but that is it a complete lack. 0%.
Not even 50/50?

Again, hyperbole, that cannot be taken seriously, because it does not
withstand even a little bit of scrutiny.

I'm recently a member on the Workstation working group, I know the
members on it. The reason why everyone is on it is because they care
very much about, and respect the community immensely, and demonstrate
it with deliberation and significant effort.

It's not good enough to just say things forcefully and expect that
people will agree as if you're a hammer, and they're a nail. You have
to work harder than you are working, if your goal really is to be
persuasive.


-- 
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: fedora-review broken?

[J. Scheurich]

> On Wed, Aug 28, 2019, 15:12 Richard Shaw  > wrote:
>
> While I'm trying to use it for a review on RPM Fusion I don't
> think the error is related...
>
> Just running fedora-review without any arguments produces this in
> the log:
>
> Traceback (most recent call last):
>   File
> "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
> line 236, in run
>     self._do_run(outfile)
>   File
> "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
> line 197, in _do_run
>     Settings.init()
>

I get similar errors when i try to use fedora-review under fedora31.
Amazingly fedora-review under fedora30 works without this problem.
This is the same fedora-review version, but maybe the problem is in the
used python scripts ?

so long
MUFTI
___
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: RPM building on s390x sometimes is very slow on F-30+

[Peter Lemenkov]

Hello All,

I've just got hit by this again - lockups on s390. Looks like I have
100% reproducer (just try to build Erlang and it will stuck
eventually).

* https://koji.fedoraproject.org/koji/taskinfo?taskID=37327589

Where should I open a ticket? Bugzilla.redhat.com or somewhere else?

чт, 25 июл. 2019 г. в 17:44, Kevin Fenzi :
>
> On 7/25/19 3:04 AM, Peter Lemenkov wrote:
> > Hello All!
> > It started to get stuck again. Right now I'm experiencing this issue
> > with RabbitMQ for F-30 and F-31:
> >
> > * https://koji.fedoraproject.org/koji/taskinfo?taskID=36457376
> > * https://koji.fedoraproject.org/koji/taskinfo?taskID=36457345
>
> So, yeah.
>
> >   |   |-kojid,31279 /usr/sbin/kojid --fg --force-lock --verbose
> >   |   |   `-mock,31584 -tt /usr/libexec/mock/mock -r 
> > koji/f30-build-16961487-1222718 --old-chroot --no-clean --target s390x ...
> >   |   |   `-rpmbuild,32205 -bb --target s390x --nodeps 
> > /builddir/build/SPECS/rabbitmq-server.spec
> >   |   |   `-sh,32237 -e /var/tmp/rpm-tmp.GwzEQt
> >   |   |   `-make,32238 -j4 VERSION=3.7.16 V=1
> >   |   |   `-sh,32318 -c...
> >   |   |   `-make,2112 -C 
> > /builddir/build/BUILD/rabbitmq-server-3.7.16/deps/amqp10_client IS_DEP=1
> >   |   |   `-make,2237 --no-print-directory app-build
> >   |   |   `-beam.smp,2302 -sbtu -A0 -- -root 
> > /usr/lib64/erlang -progname erl -- -home /builddir -- ...
> >   |   |   |-{beam.smp},2303
> >   |   |   |-{beam.smp},2304
> >   |   |   |-erl_child_setup,2305 1024
> >   |   |   |-{beam.smp},2306
> >   |   |   |-{beam.smp},2307
> >   |   |   |-{beam.smp},2308
> >   |   |   |-{beam.smp},2309
> >   |   |   |-{beam.smp},2310
> >   |   |   |-{beam.smp},2311
> >   |   |   |-{beam.smp},2312
> >   |   |   |-{beam.smp},2313
> >   |   |   |-{beam.smp},2314
> >   |   |   |-{beam.smp},2315
> >   |   |   |-{beam.smp},2316
> >   |   |   |-{beam.smp},2317
> >   |   |   |-{beam.smp},2318
> >   |   |   |-{beam.smp},2319
> >   |   |   |-{beam.smp},2320
> >   |   |   |-{beam.smp},2321
> >   |   |   |-{beam.smp},2322
> >   |   |   |-{beam.smp},2323
> >   |   |   |-{beam.smp},2324
> >   |   |   `-{beam.smp},2325
>
> When I strace the 2302 process:
>
> strace: Process 2302 attached with 23 threads
> [pid  2324] ppoll([{fd=12, events=POLLIN|POLLRDNORM}], 1, NULL, NULL, 8
> 
> [pid  2320] futex(0x3ff58800550, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2321] futex(0x3ff58800590, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2319] futex(0x3ff58800510, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2318] futex(0x3ff588004d0, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2317] futex(0x3ff58800490, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2316] futex(0x3ff58800450, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2315] futex(0x3ff58800410, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2313] futex(0x3ff58800390, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2312] futex(0x3ff58800350, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2308] restart_syscall(<... resuming interrupted
> syscall_0xfdfc ...>  ed ...>
> [pid  2303] read(14,  
> [pid  2302] select(0, NULL, NULL, NULL, NULL 
> [pid  2309] restart_syscall(<... resuming interrupted select ...>
> 
> [pid  2323] futex(0x3ff58800610, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2322] futex(0x3ff588005d0, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2314] futex(0x3ff588003d0, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2311] futex(0x3ff58800310, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2310] futex(0x3ff588002d0, FUTEX_WAIT_PRIVATE, 4294967295, NULL
> 
> [pid  2306] restart_syscall(<... resuming interrupted
> syscall_0xfdfc ...>  ed ...>
> [pid  2304] futex(0x2aa3d9af520, FUTEX_WAIT_PRIVATE, 0, NULL  ...>
> [pid  2307] timerfd_settime(11, 0, {it_interval={tv_sec=0, tv_nsec=0},
> it_value={tv_sec=0, tv_n
> sec=0}}, NULL) = 0
> [pid  2325] epoll_wait(4,  
> [pid  2307] futex(0x3ff588001d0, FUTEX_WAKE_PRIVATE, 1) = 1
> [pid  2306] <... restart_syscall resumed>) = 0
> [pid  2307] fcntl(2, F_GETFL 
> [pid  2306] timerfd_settime(11, 0, {it_interval={tv_sec=0, tv_nsec=0},
> it_value={tv_sec=23, tv_
> 

Re: Fedora 32 Self-Contained Change proposal: Switch mingw32 toolchain to dwarf-2 exceptions

[Ben Cotton]

On Wed, Aug 28, 2019 at 4:23 PM  wrote:
>
> == Issue Link ==
> https://teams.fedoraproject.org/project/changes-tracker/issue2
>
This is incorrect. The correct link is:
https://teams.fedoraproject.org/project/changes-tracker/issue/2

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

Re: Fedora 32 Self-Contained Change proposal: Switch mingw32 toolchain to dwarf-2 exceptions

[Ben Cotton]

On Wed, Aug 28, 2019 at 4:23 PM  wrote:
>
> == Issue Link ==
> https://teams.fedoraproject.org/project/changes-tracker/issue2
>
This is incorrect. The correct link is:
https://teams.fedoraproject.org/project/changes-tracker/issue/2

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
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

Fwd: Fedora 32 Self-Contained Change proposal: Switch mingw32 toolchain to dwarf-2 exceptions

[Ben Cotton]

(Manually forwarding to devel-announce as we work out some tooling issues)

-- Forwarded message -
From: 
Date: Wed, Aug 28, 2019 at 4:23 PM
Subject: Fedora 32 Self-Contained Change proposal: Switch mingw32
toolchain to dwarf-2 exceptions
To: , 


== Issue Link ==
https://teams.fedoraproject.org/project/changes-tracker/issue2

== Summary ==
Switch the mingw32 toolchain to dwarf-2 exceptions, instead of SJLJ.

== owner ==
smani

== Detailed Description ==
# Detailed Description

The two exception modes supported by mingw32 targets are SJLJ
(currently used in Fedora, and still default upstream), and the more
recent dwarf-2. According to various sources [1][2][3], the key
differences between the two are:

SJLJ (setjmp/longjmp):

* not "zero-cost": even if an exception isn't thrown, it incurs a
minor performance penalty (~15% in exception heavy code)
* allows exceptions to traverse through e.g. windows callbacks

DWARF (DW2, dwarf-2):

* no permanent runtime overhead
* needs whole call stack to be dwarf-enabled, which means exceptions
cannot be thrown over e.g. Windows system DLLs (i.e. throwing an
exception in a system DLL callback and attempting to catch it won't
work)
* DW2 potentially generates bigger libraries. The overhead however is
not big (< 10%) for typical applications.

The main reason for switching to dwarf-2 is that rust can only be
compiled to a MinGW toolchain targeting dwarf exceptions on 32-bit
[4], and rust usage is starting to appear in some packages (i.e.
librsvg2). Switching to dwarf-2 on mingw32 would hence allow to keep
the same consistent package offering between mingw32 and mingw64,
whereas otherwise one would need to either freeze the mingw32 variants
at older versions, or remove them altogether.

* [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540782
* [2] https://sourceforge.net/p/mingw-w64/mailman/message/30532139/
* [3] 
https://wiki.qt.io/MinGW-64-bit#Exception_handling:_SJLJ.2C_DWARF.2C_and_SEH
* [4] https://github.com/rust-lang/rust/issues/12859#issuecomment-185081071


# Benefit to Fedora

Continue being able to ship the same package set on mingw32 as well as mingw64.

# Scope
## Proposal owners:
GCC for mingw32 will be built with `--disable-sjlj-exceptions
--with-dwarf2` and all `mingw-*` packages rebuilt.

## Other developers:
None

## Release engineering
Rebuild in a side-tag

# Upgrade/compatibility impact
No impact

# Contingency Plan
* Contingency mechanism: Revert to SJLJ
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No

# Documentation
None

# Release Notes
The mingw32 toolchain in Fedora 32 uses the dwarf-2 exception model
instead of SJLJ.


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

Re: Fedora-31-20190828.n.0 compose check report

[Adam Williamson]

On Wed, 2019-08-28 at 13:24 +, Fedora compose checker wrote:
> No missing expected images.
> 
> Failed openQA tests: 21/152 (x86_64), 1/2 (arm)

So most of the failures boil down, I think, to one bug: gnome-initial-
setup isn't working. We've had various incarnations of this problem in
rapid succession lately, but I've failed this latest one as
https://bugzilla.redhat.com/show_bug.cgi?id=1746563 . It's failing all
the Workstation and Silverblue default install tests, and I think it's
also causing various of the failed tests under 'universal' (all the
language tests and the Workstation upgrade tests), because they're also
failing at a point where g-i-s ought to run but isn't showing up; it
seems likely it's all the same bug.

There are a few other issues. One is that the F31 desktop backgrounds
aren't done yet, and we have some tests checking that now. The others
are some issues with module defaults:
https://bugzilla.redhat.com/show_bug.cgi?id=1746389
https://bugzilla.redhat.com/show_bug.cgi?id=1746384
and an anaconda bug that affects some of the different storage config
install tests:
https://bugzilla.redhat.com/show_bug.cgi?id=1743753
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
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

Fwd: Fedora 32 Self-Contained Change proposal: Switch mingw32 toolchain to dwarf-2 exceptions

[Ben Cotton]

(Manually forwarding to devel-announce as we work out some tooling issues)

-- Forwarded message -
From: 
Date: Wed, Aug 28, 2019 at 4:23 PM
Subject: Fedora 32 Self-Contained Change proposal: Switch mingw32
toolchain to dwarf-2 exceptions
To: , 


== Issue Link ==
https://teams.fedoraproject.org/project/changes-tracker/issue2

== Summary ==
Switch the mingw32 toolchain to dwarf-2 exceptions, instead of SJLJ.

== owner ==
smani

== Detailed Description ==
# Detailed Description

The two exception modes supported by mingw32 targets are SJLJ
(currently used in Fedora, and still default upstream), and the more
recent dwarf-2. According to various sources [1][2][3], the key
differences between the two are:

SJLJ (setjmp/longjmp):

* not "zero-cost": even if an exception isn't thrown, it incurs a
minor performance penalty (~15% in exception heavy code)
* allows exceptions to traverse through e.g. windows callbacks

DWARF (DW2, dwarf-2):

* no permanent runtime overhead
* needs whole call stack to be dwarf-enabled, which means exceptions
cannot be thrown over e.g. Windows system DLLs (i.e. throwing an
exception in a system DLL callback and attempting to catch it won't
work)
* DW2 potentially generates bigger libraries. The overhead however is
not big (< 10%) for typical applications.

The main reason for switching to dwarf-2 is that rust can only be
compiled to a MinGW toolchain targeting dwarf exceptions on 32-bit
[4], and rust usage is starting to appear in some packages (i.e.
librsvg2). Switching to dwarf-2 on mingw32 would hence allow to keep
the same consistent package offering between mingw32 and mingw64,
whereas otherwise one would need to either freeze the mingw32 variants
at older versions, or remove them altogether.

* [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540782
* [2] https://sourceforge.net/p/mingw-w64/mailman/message/30532139/
* [3] 
https://wiki.qt.io/MinGW-64-bit#Exception_handling:_SJLJ.2C_DWARF.2C_and_SEH
* [4] https://github.com/rust-lang/rust/issues/12859#issuecomment-185081071


# Benefit to Fedora

Continue being able to ship the same package set on mingw32 as well as mingw64.

# Scope
## Proposal owners:
GCC for mingw32 will be built with `--disable-sjlj-exceptions
--with-dwarf2` and all `mingw-*` packages rebuilt.

## Other developers:
None

## Release engineering
Rebuild in a side-tag

# Upgrade/compatibility impact
No impact

# Contingency Plan
* Contingency mechanism: Revert to SJLJ
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No

# Documentation
None

# Release Notes
The mingw32 toolchain in Fedora 32 uses the dwarf-2 exception model
instead of SJLJ.


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

Re: Fedora Workstation and disabled by default firewall

[Colin Walters]

FWIW,

For Fedora CoreOS we don't enable a firewall by default; see
https://github.com/coreos/fedora-coreos-tracker/issues/26

(Neither for that matter does Fedora Cloud:
 https://pagure.io/fedora-kickstarts/blob/master/f/fedora-cloud-base.ks#_36 )
___
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 Workstation and disabled by default firewall

[Dan Book]

On Wed, Aug 28, 2019 at 4:27 PM Adam Williamson 
wrote:

> That is talking about the whole idea that having a firewall enabled by
> default is not as important if there are no listening services by
> default; at that point you can make the argument that installing a
> service that listens on a port is a conscious decision to "open" that
> port.
>

And we are expecting this apparent target audience of people that don't
understand the firewall GUI to understand that installing such a service is
a conscious decision to open a port?

-Dan
___
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 Workstation and disabled by default firewall

[Adam Williamson]

On Wed, 2019-08-28 at 22:32 +0300, mcatanz...@gnome.org wrote:
> On Wed, Aug 28, 2019 at 9:56 PM, Christopher 
>  wrote:
> > 2) the Workstation WG has not only taken no action in response to the
> > FESCo statement of trust at the conclusion of our last lengthy
> > discussion on this matter, it has been explicitly stated in this
> > thread that they have never had any intention of doing anything
> > further, even though that was FESCo's clear expectation.
> 
> In January 2015, FESCo said:
> 
> """
> AGREED: FESCo trusts the Workstation WG to properly research and 
> develop a sensible firewall solution and will stay out of the way. (+5, 
> 3, -0) (sgallagh, 18:40:04)
> """
> 
> 
> 
> It reads to me like an affirmation of the work that had been done for 
> Fedora 21:
> 
> 
> 
> I don't think a reasonable person reading the thread could plausibly 
> conclude that FESCo expected further work.

Here is the actual log of the meeting that produced that conclusion:

https://meetbot-raw.fedoraproject.org/teams/fesco/fesco.2015-01-07-18.01.log.txt

It's a pretty...messy discussion. I would say there was clearly an
expectation at the start that there would be further ongoing work:


18:07:31  I don't think anyone is perfectly happy with the
current state (is that a fair statement?)
18:07:51  fair understatement, maybe even
18:08:01  I'm not sure we need to discuss solutions here tho...
18:08:10  nirik, +1
18:08:15  unless we feel that it's worth overriding the
workstation working group.
18:08:20  sgallagh: I am reasonably happy with the current
capabilities _of the firewall_ actually.  I am very much wishing for
reliable sandboxing which would replace some of the firewall uses but
is not actually a firewall.
18:08:22  which IMHO, I am -1 to
18:08:25  nirik: Well, we need to try to agree on an end-
experience, not necessarily an implementation
18:08:38  mitr, +1
18:08:41  the long term goals were mentioned in my mail to
fedora workstation, definitely not finished, but certainly on the right
path

But at the same time, there's a fairly strong vein of feeling that
FESCo shouldn't override the WG here and should basically leave the WG
to do whatever it wanted to do. I think my interpretation would be
that, as of the meeting, FESCo was willing to delegate this topic
entirely to the WG; it was *expecting* further work to happen, but it
did not *require* it, and I don't think you could say the conclusion at
the meeting was incompatible with the WG simply leaving everything as-
is.

There are a couple of other interesting notes along the way, especially
this one (for me):

18:33:08  Proposal 2) The automated tests to make sure that
nothing in Fedora is listening by default unless on a strictly
maintained whitelist are a blocker for F22.

That is talking about the whole idea that having a firewall enabled by
default is not as important if there are no listening services by
default; at that point you can make the argument that installing a
service that listens on a port is a conscious decision to "open" that
port. It seems there was an expectation around this time that testing
to ensure that this was actually the case should be automated. At the
time this was expected to happen in Taskotron, but I don't believe it
ever has.

I think we could implement this in openQA relatively easily, and check
that it's in the release criteria and validation tests. Assuming folks
still think this would be valuable, I'll file a ticket for us to work
on that.

I must also congratulate mclasen for this, given Christopher's comment
that Michael replied to:

"18:20:33 * mclasen waits for the suggestion to ask in the installer"

It took four years, but here we are ;)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
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 32 Self-Contained Change proposal: Switch mingw32 toolchain to dwarf-2 exceptions

[bcotton]

== Issue Link == 
https://teams.fedoraproject.org/project/changes-tracker/issue2

== Summary == 
Switch the mingw32 toolchain to dwarf-2 exceptions, instead of SJLJ. 

== owner == 
smani

== Detailed Description == 
# Detailed Description

The two exception modes supported by mingw32 targets are SJLJ (currently used 
in Fedora, and still default upstream), and the more recent dwarf-2. According 
to various sources [1][2][3], the key differences between the two are:

SJLJ (setjmp/longjmp):

* not "zero-cost": even if an exception isn't thrown, it incurs a minor 
performance penalty (~15% in exception heavy code)
* allows exceptions to traverse through e.g. windows callbacks

DWARF (DW2, dwarf-2):

* no permanent runtime overhead
* needs whole call stack to be dwarf-enabled, which means exceptions cannot be 
thrown over e.g. Windows system DLLs (i.e. throwing an exception in a system 
DLL callback and attempting to catch it won't work)
* DW2 potentially generates bigger libraries. The overhead however is not big 
(< 10%) for typical applications.

The main reason for switching to dwarf-2 is that rust can only be compiled to a 
MinGW toolchain targeting dwarf exceptions on 32-bit [4], and rust usage is 
starting to appear in some packages (i.e. librsvg2). Switching to dwarf-2 on 
mingw32 would hence allow to keep the same consistent package offering between 
mingw32 and mingw64, whereas otherwise one would need to either freeze the 
mingw32 variants at older versions, or remove them altogether.

* [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540782
* [2] https://sourceforge.net/p/mingw-w64/mailman/message/30532139/
* [3] 
https://wiki.qt.io/MinGW-64-bit#Exception_handling:_SJLJ.2C_DWARF.2C_and_SEH
* [4] https://github.com/rust-lang/rust/issues/12859#issuecomment-185081071


# Benefit to Fedora

Continue being able to ship the same package set on mingw32 as well as mingw64.
  
# Scope 
## Proposal owners:
GCC for mingw32 will be built with `--disable-sjlj-exceptions --with-dwarf2` 
and all `mingw-*` packages rebuilt.

## Other developers:
None

## Release engineering
Rebuild in a side-tag

# Upgrade/compatibility impact
No impact

# Contingency Plan
* Contingency mechanism: Revert to SJLJ
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No

# Documentation
None

# Release Notes
The mingw32 toolchain in Fedora 32 uses the dwarf-2 exception model instead of 
SJLJ.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Thursday's FPC Meeting (2019-08-29 16:00 UTC)

[James Antill]

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

 Local time information (via. uitime):

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


 Links to all tickets below can be found at: 

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

= Followups =

#topic #902 Cleanup & enhance spec files 
.fpc 902
https://pagure.io/packaging-committee/issue/902

#topic #904 Caret versioning 
.fpc 904
https://pagure.io/packaging-committee/issue/904

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

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

#topic #914 Automatic R runtime dependencies
.fpc 914
https://pagure.io/packaging-committee/issue/914

= Pull Requests =

#topic #894 Add rules for Cython 
https://pagure.io/packaging-committee/pull-request/894

#topic #903 Update Python guidelines for Fedora 31 
https://pagure.io/packaging-committee/pull-request/903

#topic #915 Modernize python spec file example 
https://pagure.io/packaging-committee/pull-request/915

= Open Floor = 

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

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

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

Re: Fedora Workstation and disabled by default firewall

[Christopher]

On Wed, Aug 28, 2019 at 3:33 PM  wrote:
>
> On Wed, Aug 28, 2019 at 9:56 PM, Christopher  
> wrote:
>
> 2) the Workstation WG has not only taken no action in response to the FESCo 
> statement of trust at the conclusion of our last lengthy discussion on this 
> matter, it has been explicitly stated in this thread that they have never had 
> any intention of doing anything further, even though that was FESCo's clear 
> expectation.
>
>
> In January 2015, FESCo said:
>
> """
> AGREED: FESCo trusts the Workstation WG to properly research and develop a 
> sensible firewall solution and will stay out of the way. (+5, 3, -0) 
> (sgallagh, 18:40:04)
> """
>
> https://pagure.io/fesco/issue/1372#comment-27998
>
> It reads to me like an affirmation of the work that had been done for Fedora 
> 21:
>
> http://www.hadess.net/2014/06/firewalls-and-per-network-sharing.html
>
> I don't think a reasonable person reading the thread could plausibly conclude 
> that FESCo expected further work.

I consider myself generally reasonable, and that's precisely what I
concluded, since 1) it was written in response to a request for a
change (further work) in the context of a heated debate where one side
was demanding the change, and 2) the grammatical context is all
present and future tense, and not past tense in any way. Notably, they
did not say "trusts the Workstation WG has properly researched and
developed a sensible solution". I'm a native (American-)English
speaker, and while I'll admit it's possible the phrasing could be
interpreted as an affirmation, to me it implies the work is to be
done. It is entirely possible I'm misinterpreting the intent... I'll
grant you that. We can ask for clarity or FESCo to re-consider the
matter.

>
> At the very least, it'd be nice if anaconda had an option to select
> the default firewalld zone during installation
>
>
> Imagine if Anaconda had an option for every time someone suggested it 
> should

Yeah, obviously that would be bad. Please don't simply dismiss a
serious suggestion, because it would be bad in other scenarios or if
taken to the extreme. This is one specific suggestion, not a proposal
to accept all similar suggestions, and I'm not even convinced myself
that this is the best possible solution. It just seemed like an idea
worth considering, since the debate is raging on, has been raging on
and off since 2014, and this proposal seems like it has potential to
satisfy all parties once and for all (since it gets directly to the
heart of the matter, eliminates user surprise, and fits naturally
within the existing network setup portion of Anaconda). This proposal
was an attempt to seek out a compromise. Please don't be so dismissive
of the attempt.
___
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 1744692] [RFE] EPEL8 branch of perl-XML-Entities

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-EPEL-2019-eda1e2ebc4 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-eda1e2ebc4

-- 
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] Re: Koschei enablement for EPEL 8

[Jason L Tibbitts III]

> "SJS" == Stephen John Smoogen  writes:

SJS> Can koschei be limited to a single architecture or does it need to
SJS> build against all targets? I am worried about the number of s390
SJS> builds we may be adding.

Currently it only does builds for aarch64, ppc64le and x86_64, so it
does at least know how to avoid building on everything.  In addition, it
is pretty good about not submitting jobs without plenty of idle builders
to handle them.

Back when it was first being deployed, koschei did swam the s390x
builders but that was fixed.  And these days, s390x isn't really our
slowest architecture.

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

Re: Fedora Workstation and disabled by default firewall

[mcatanzaro]

On Wed, Aug 28, 2019 at 9:56 PM, Christopher 
 wrote:

2) the Workstation WG has not only taken no action in response to the
FESCo statement of trust at the conclusion of our last lengthy
discussion on this matter, it has been explicitly stated in this
thread that they have never had any intention of doing anything
further, even though that was FESCo's clear expectation.


In January 2015, FESCo said:

"""
AGREED: FESCo trusts the Workstation WG to properly research and 
develop a sensible firewall solution and will stay out of the way. (+5, 
3, -0) (sgallagh, 18:40:04)

"""



It reads to me like an affirmation of the work that had been done for 
Fedora 21:




I don't think a reasonable person reading the thread could plausibly 
conclude that FESCo expected further work.



At the very least, it'd be nice if anaconda had an option to select
the default firewalld zone during installation


Imagine if Anaconda had an option for every time someone suggested it 
should


___
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 Workstation and disabled by default firewall

[Christopher]

On Wed, Aug 28, 2019 at 1:01 PM Chris Murphy  wrote:
>
> On Wed, Aug 28, 2019 at 9:36 AM John Harris  wrote:
>
> > Essentially disabling the firewall falls under having a "bad design for
> > everyone else". Disabling the firewall is something that could be considered
> > hostile to the user.
>
> This is hyperbole, and turning up the volume isn't going to make
> anyone go "oh, ok, now I see your point, it's hostile and we don't
> want to do that, let's change it" as if literally everyone reading
> this is some kind of moron.
>
[SNIP]

This isn't hyperbole. This is disagreement. Nobody called anybody a
moron. John simply highlighted Jiri's statement of "bad design for
everyone else" as subjective, and there are those who can see it
differently; there those of us that consider the current status quo to
be of "bad design", possibly even hostile. This is just a difference
of opinion, because "bad design" is subjective.

Because it is subjective, I don't think this is going to be solved
easily (consensus gathering is hard). Right now... from the
participants... it seems pretty split. I wish we had a way of polling
the community to get a sense of the community consensus on the matter.

For me, the biggest thing that upsets me is that:

1) it seems FESCo's previous rejection of the change proposal seems to
have been ignored in spirit, even though it wasn't technically
ignored, and
2) the Workstation WG has not only taken no action in response to the
FESCo statement of trust at the conclusion of our last lengthy
discussion on this matter, it has been explicitly stated in this
thread that they have never had any intention of doing anything
further, even though that was FESCo's clear expectation.

To me, these two facts demonstrate a complete lack of respect for the
community and its elected representatives. The appearance is that the
WG will do what it wants no matter what the community thinks (even if
the community consensus were on their side... which is still
uncertain). It also makes it appear that Fedora governance is weak...
a puppet to the whims of those who don't necessarily represent the
whole community. This seems like a very unhealthy state for Fedora to
be in right now. I'm just disappointed in how this has played out.

At the very least, it'd be nice if anaconda had an option to select
the default firewalld zone during installation, so users had a choice
to select "public - more secure, but some firewall configuration
changes may need to made to allow some applications to work" or
"trusted - more open, but may expose your computer's applications to
malicious actors on the networks you connect to" with a comment that
"you can change this later; see ". Then, you don't need to
worry about what the default is... nobody could claim surprise by the
setting. If this option existed during installation in an obvious way
during network setup, I wouldn't even care if "trusted" was selected
by default, because changing it would be simple.
___
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 1746553] New: build of perl-Time-Duration for EPEL 8

[bugzilla]

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

Bug ID: 1746553
   Summary: build of perl-Time-Duration for EPEL 8
   Product: Fedora EPEL
   Version: epel8
  Hardware: x86_64
OS: Linux
Status: NEW
 Component: perl-Time-Duration
  Assignee: lkund...@v3.sk
  Reporter: br...@tembosocial.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Hi,

I would like to ask a build of perl-Time-Duration for EPEL 8.

Would you mind requesting the branches and build them?
If you fork from src.fedoraproject.org it will build it right away, no issues.

Thank you very much.

- Breno

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

Re: fedora-review broken?

[Miro Hrončok]

On 28. 08. 19 20:09, Robert-André Mauchin wrote:

On Wednesday, 28 August 2019 19:30:28 CEST Richard Shaw wrote:

On Wed, Aug 28, 2019 at 11:53 AM Bob Mauchin  wrote:

What's the mock config file you are using? From the error it seems it's
missing config_opts['root']


  I should have posted the full command anyway so here it is:

$ fedora-review --rpm-spec -n plex-media-player-2.40.0-2.fc29.src.rpm -m
fedora-30-x86_64-rpmfusion_free

Since I'm getting an error when I just run "fedora-review --help" I didn't
attribute it to the mock config... The RPM Fusion usually just extend on
the base Fedora config including the free and/or non-free repositories on
top of it.

Thanks,
Richard


Probably a FedoraReview bug, it reads the cfg file from fedora-30-x86_64-
rpmfusion_free.cfg to search for config_opts['root'], but doesn't resolve the
include.

It seems there is a bug opened already for this issue:
https://pagure.io/FedoraReview/issue/359
The bug was introduced by me to solve another one apparently.

Until this bug is solved, I'm joining my cfg file for RPMFusion to use with
FedoraReview. Use it with -m pathtocfgfile.cfg.



Indeed: https://pagure.io/FedoraReview/issue/359

--
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: fedora-review broken?

[Robert-André Mauchin]

On Wednesday, 28 August 2019 19:30:28 CEST Richard Shaw wrote:
> On Wed, Aug 28, 2019 at 11:53 AM Bob Mauchin  wrote:
> > What's the mock config file you are using? From the error it seems it's
> > missing config_opts['root']
> 
>  I should have posted the full command anyway so here it is:
> 
> $ fedora-review --rpm-spec -n plex-media-player-2.40.0-2.fc29.src.rpm -m
> fedora-30-x86_64-rpmfusion_free
> 
> Since I'm getting an error when I just run "fedora-review --help" I didn't
> attribute it to the mock config... The RPM Fusion usually just extend on
> the base Fedora config including the free and/or non-free repositories on
> top of it.
> 
> Thanks,
> Richard

Probably a FedoraReview bug, it reads the cfg file from fedora-30-x86_64-
rpmfusion_free.cfg to search for config_opts['root'], but doesn't resolve the 
include.

It seems there is a bug opened already for this issue:
https://pagure.io/FedoraReview/issue/359
The bug was introduced by me to solve another one apparently.

Until this bug is solved, I'm joining my cfg file for RPMFusion to use with 
FedoraReview. Use it with -m pathtocfgfile.cfg.

Best regards,

Robert-André# Auto-generated by the Koji build system

config_opts['chroothome'] = '/builddir'
config_opts['use_host_resolv'] = False
config_opts['basedir'] = '/var/lib/mock'
config_opts['rpmbuild_timeout'] = 86400
config_opts['chroot_setup_cmd'] = 'install @buildsys-build pigz lbzip2'
config_opts['target_arch'] = 'x86_64'
config_opts['legal_host_arches'] = ('x86_64',)
config_opts['root'] = 'f32-candidate-x86_64_rpmfusion'
config_opts['extra_chroot_dirs'] = [ '/run/lock', ]
config_opts['package_manager'] = 'dnf'
config_opts['use_bootstrap_container'] = False
config_opts['environment']['LANG'] = 'C.UTF-8'
config_opts['releasever'] = '32'
config_opts['rpmbuild_networking'] = True
config_opts['dynamic_buildrequires'] = True
config_opts['dynamic_buildrequires_max_loops'] = 10

config_opts['plugin_conf']['root_cache_enable'] = True
config_opts['plugin_conf']['yum_cache_enable'] = True
config_opts['plugin_conf']['ccache_enable'] = True

config_opts['macros']['%_host'] = 'x86_64-koji-linux-gnu'
config_opts['macros']['%_host_cpu'] = 'x86_64'
config_opts['macros']['%vendor'] = 'Koji'
config_opts['macros']['%distribution'] = 'fc32'
config_opts['macros']['%_topdir'] = '/builddir/build'
config_opts['macros']['%_rpmfilename'] = 
'%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm'
config_opts['macros']['%packager'] = 'Koji'

config_opts['plugin_conf']['package_state_enable'] = False
config_opts['plugin_conf']['ccache_opts']['compress'] = True
config_opts['plugin_conf']['root_cache_opts']['compress_program'] = "pigz"
config_opts['macros']['%__gzip'] = '/usr/bin/pigz'
config_opts['macros']['%__bzip2'] = '/usr/bin/lbzip2'


config_opts['yum.conf'] = """
[main]
keepcache=1
debuglevel=2
reposdir=/dev/null
logfile=/var/log/yum.log
retries=20
obsoletes=1
gpgcheck=0
assumeyes=1
syslog_ident=mock
syslog_device=
install_weak_deps=0
metadata_timer_sync=8
metadata_expire=8
mdpolicy=group:primary
best=1
module_platform_id=platform:f32
fastestmirror=1
max_parallel_downloads=8

# repos

[fedora]
name=fedora
metalink=https://mirrors.fedoraproject.org/metalink?repo=rawhide=$basearch
gpgkey=file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-$releasever-primary
 file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-31-primary
gpgcheck=1
skip_if_unavailable=False

[local]
name=local
baseurl=https://kojipkgs.fedoraproject.org/repos/f32-build/latest/$basearch
skip_if_unavailable=False

[build-free]
name=build
baseurl=http://koji.rpmfusion.org/kojifiles/repos/f32-free-build/latest/$basearch

[build-nonfree]
name=build
baseurl=http://koji.rpmfusion.org/kojifiles/repos/f32-nonfree-build/latest/$basearch
"""

___
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: [HEADS UP] Retiring python2 and introducing python27 later this week

[Miro Hrončok]

On 27. 08. 19 22:20, Miro Hrončok wrote:

We are retiring python2 and introducing python27 later this week. Rawhide only.

As for now, nothing should break, except python2-debug will exist no more.

Packages (build)requiring python2 or python2-devel should continue to work for 
now. If not, let us know.


If you plan to keep a Python 2 package in Fedora 32+, talk to me, I can help you 
draft an exception request.


Will post a reply here once it is done.


python27 build in progress.

Will retire python2 later tomorrow or on Friday (in case something is terribly 
broken I want to have some maneuvering space).


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

Re: [HEADS UP] Retiring python2 and introducing python27 later this week

[Miro Hrončok]

On 27. 08. 19 22:20, Miro Hrončok wrote:

We are retiring python2 and introducing python27 later this week. Rawhide only.

As for now, nothing should break, except python2-debug will exist no more.

Packages (build)requiring python2 or python2-devel should continue to work for 
now. If not, let us know.


If you plan to keep a Python 2 package in Fedora 32+, talk to me, I can help you 
draft an exception request.


Will post a reply here once it is done.


python27 build in progress.

Will retire python2 later tomorrow or on Friday (in case something is terribly 
broken I want to have some maneuvering space).


--
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: fedora-review broken?

[Richard Shaw]

On Wed, Aug 28, 2019 at 11:53 AM Bob Mauchin  wrote:

>
>>
> What's the mock config file you are using? From the error it seems it's
> missing config_opts['root']
>

 I should have posted the full command anyway so here it is:

$ fedora-review --rpm-spec -n plex-media-player-2.40.0-2.fc29.src.rpm -m
fedora-30-x86_64-rpmfusion_free

Since I'm getting an error when I just run "fedora-review --help" I didn't
attribute it to the mock config... The RPM Fusion usually just extend on
the base Fedora config including the free and/or non-free repositories on
top of it.

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

[Bug 1744782] (RFE) EPEL8 branch of perl-Crypt-SSLeay

[bugzilla]

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



--- Comment #4 from Pat Riehecky  ---
In that case I'll migrate up to that version.

-- 
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 1746534] New: Please build perl-File-LibMagic for EPEL 8

[bugzilla]

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

Bug ID: 1746534
   Summary: Please build perl-File-LibMagic for EPEL 8
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-File-LibMagic
  Assignee: p...@city-fan.org
  Reporter: mstev...@imt-systems.com
QA Contact: extras...@fedoraproject.org
CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org,
rob.my...@gtri.gatech.edu
  Target Milestone: ---
Classification: Fedora



Description of problem:
Please build perl-File-LibMagic for EPEL 8.

Actual results:
No perl-File-LibMagic package in EPEL8

Additional info:
Please let me know if you are not interested in maintaining the package on EPEL
8 branch.

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

qd license change: BSD to LBNL BSD

[Jerry James]

I am building qd 2.3.22 in Rawhide right now.  The license has been
corrected from "BSD" to "LBNL BSD".
-- 
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

[Bug 1746533] New: Please build perl-Convert-TNEF for EPEL 8

[bugzilla]

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

Bug ID: 1746533
   Summary: Please build perl-Convert-TNEF for EPEL 8
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-Convert-TNEF
  Assignee: p...@city-fan.org
  Reporter: mstev...@imt-systems.com
QA Contact: extras...@fedoraproject.org
CC: janfr...@tanso.net, mstev...@imt-systems.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org,
st...@silug.org
  Target Milestone: ---
Classification: Fedora



Description of problem:
Please build perl-Convert-TNEF for EPEL 8.

Actual results:
No perl-Convert-TNEF package in EPEL8

Additional info:
Please let me know if you are not interested in maintaining the package on EPEL
8 branch.

-- 
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 1746531] New: Please build perl-BerkeleyDB for EPEL 8

[bugzilla]

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

Bug ID: 1746531
   Summary: Please build perl-BerkeleyDB for EPEL 8
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-BerkeleyDB
  Assignee: jples...@redhat.com
  Reporter: mstev...@imt-systems.com
QA Contact: extras...@fedoraproject.org
CC: jn...@redhat.com, jples...@redhat.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org,
st...@silug.org
  Target Milestone: ---
Classification: Fedora



Description of problem:
Please build perl-BerkeleyDB for EPEL 8.

Actual results:
No perl-BerkeleyDB package in EPEL8

Additional info:
Please let me know if you are not interested in maintaining the package on EPEL
8 branch.

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

Re: Fedora Workstation and disabled by default firewall

[Chris Murphy]

On Wed, Aug 28, 2019 at 9:36 AM John Harris  wrote:

> Essentially disabling the firewall falls under having a "bad design for
> everyone else". Disabling the firewall is something that could be considered
> hostile to the user.

This is hyperbole, and turning up the volume isn't going to make
anyone go "oh, ok, now I see your point, it's hostile and we don't
want to do that, let's change it" as if literally everyone reading
this is some kind of moron.

Your position is shown to be weak if you have to use this distinctly
non-objective tactic designed to evoke an emotional response in the
reader. All you're doing is casually dismissing one side of a
balancing act and then claiming the result as proof the policy should
change. Guess what? Saying things does not make them true.

You should try to understand all of these arguments have happened
before, and if you really want a change to happen, you need a produce
a compelling new arguments. Did the previous working group
misunderstand something previously? Has new information come to light?
Has the GUI firewall app made UI/Ux improvements that might sway the
working group to re-evaluate?

By all means shout more. And be ignored. Or do the hard work and put
together a deliberate and compelling argument.

> I fail to see how the comparison to MacOS applies here.

Tons of installations. 1% of their user base dwarfs ours. If firewall
disabled by default were so hideously flawed, there'd be a million
users getting malware, and we'd hear about it including and autopsy
report saying, effectively, Apple's crazy because their firewall would
have prevented this. But that isn't happening.

Windows is likewise a fair contra example, but I can't assess to what
degree their firewall is a security strategy that helps prevent
infections, versus reputation repair. And that is in some sense where
we are right now. Do we have examples of penetrated systems that the
firewall would have prevented? This is a real problem, a theoretical
problem that can be tested unambiguously, or is it purely
hypothetical? It's definitely a problem when people's applications
silently fail to work in weird ways and is non-obvious that the cause
is the firewall.


-- 
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: fedora-review broken?

[Bob Mauchin]

On Wed, Aug 28, 2019, 15:12 Richard Shaw  wrote:

> While I'm trying to use it for a review on RPM Fusion I don't think the
> error is related...
>
> Just running fedora-review without any arguments produces this in the log:
>
> Traceback (most recent call last):
>   File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
> line 236, in run
> self._do_run(outfile)
>   File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
> line 197, in _do_run
> Settings.init()
>   File "/usr/lib/python3.7/site-packages/FedoraReview/settings.py", line
> 417, in init
> args = parser.parse_args()
>   File "/usr/lib64/python3.7/argparse.py", line 1749, in parse_args
> args, argv = self.parse_known_args(args, namespace)
>   File "/usr/lib64/python3.7/argparse.py", line 1781, in parse_known_args
> namespace, args = self._parse_known_args(args, namespace)
>   File "/usr/lib64/python3.7/argparse.py", line 1987, in _parse_known_args
> start_index = consume_optional(start_index)
>   File "/usr/lib64/python3.7/argparse.py", line 1927, in consume_optional
> take_action(action, args, option_string)
>   File "/usr/lib64/python3.7/argparse.py", line 1855, in take_action
> action(self, namespace, argument_values, option_string)
>   File "/usr/lib64/python3.7/argparse.py", line 1038, in __call__
> parser.exit()
>   File "/usr/lib64/python3.7/argparse.py", line 2488, in exit
> _sys.exit(status)
> SystemExit: 0
>
> When I try to do the review I get:
>
> Traceback (most recent call last):
>   File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
> line 236, in run
> self._do_run(outfile)
>   File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
> line 226, in _do_run
> self._do_report(outfile)
>   File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
> line 99, in _do_report
> self._run_checks(self.bug.spec_file, self.bug.srpm_file, outfile)
>   File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
> line 117, in _run_checks
> self.checks.run_checks(output=output, writedown=not Settings.no_report)
>   File "/usr/lib/python3.7/site-packages/FedoraReview/checks.py", line
> 382, in run_checks
> run_check(name)
>   File "/usr/lib/python3.7/site-packages/FedoraReview/checks.py", line
> 357, in run_check
> check.run()
>   File
> "/usr/lib/python3.7/site-packages/FedoraReview/plugins/generic_build.py",
> line 203, in run
> Mock.build(self.srpm.filename)
>   File "/usr/lib/python3.7/site-packages/FedoraReview/mock.py", line 457,
> in build
> self.builddir_cleanup()
>   File "/usr/lib/python3.7/site-packages/FedoraReview/mock.py", line 584,
> in builddir_cleanup
> paths = glob(os.path.join(self.get_builddir("BUILD"), "*"))
>   File "/usr/lib/python3.7/site-packages/FedoraReview/mock.py", line 360,
> in get_builddir
> p = self._get_dir(os.path.join("root", self._topdir[1:]))
>   File "/usr/lib/python3.7/site-packages/FedoraReview/mock.py", line 201,
> in _get_dir
> self._get_root()
>   File "/usr/lib/python3.7/site-packages/FedoraReview/mock.py", line 186,
> in _get_root
> config = compile(content[0], path, "exec")
> IndexError: list index out of range
>
> Thanks,
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>

>

What's the mock config file you are using? From the error it seems it's
missing config_opts['root']
___
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] Fedora 31 Beta Freeze

[Gerald B. Cox]

I'm still getting these messages when I try to do "fedpkg update" for F31:

fedpkg update
Could not execute update: Could not generate update request: Cannot find
release associated with build: copyq-3.9.2-1.fc31, tags: ['f31']
A copy of the filled in template is saved as bodhi.template.last

On Wed, Aug 28, 2019 at 7:37 AM Paul Howarth  wrote:

> On Tue, 27 Aug 2019 17:52:00 -0700
> Kevin Fenzi  wrote:
>
> > On 8/27/19 4:27 AM, Miro Hrončok wrote:
> > > On 27. 08. 19 13:06, Paul Howarth wrote:
> > >> On Mon, 26 Aug 2019 20:55:18 -0400
> > >> Mohan Boddu  wrote:
> > >>
> > >>> Hi all,
> > >>>
> > >>> Today's an important day on the Fedora 31 schedule[1], with
> > >>> several significant cut-offs. First of all today is
> > >>> the Bodhi activation point [2]. That means that from now all
> > >>> Fedora 31 packages must be submitted to
> > >>> updates-testing and pass the relevant requirements[3] before they
> > >>> will be marked as 'stable' and moved to the
> > >>> fedora repository.
> > >>
> > >> I don't know if this is related but the Rawhide (f32) builds I've
> > >> done today (e.g. perl-MCE-1.846-1.fc32) don't seem to be going
> > >> through the gating process and into rawhide.
> > >>
> > >> $ koji -q list-tagged --latest f32-updates-candidate perl-MCE
> > >> perl-MCE-1.846-1.fc32 f32-updates-candidate
> > >> pghmcfc
> > >>
> > >> $ koji -q list-tagged --latest f32 perl-MCE
> > >> perl-MCE-1.845-1.fc32 f32
> > >> pghmcfc
> > >
> > > https://pagure.io/fedora-infrastructure/issue/8138
> >
> > This was fixed earlier today, sorry for not circling back and noting
> > that here.
> >
> > I think everything should be processed that was stuck, if anyone sees
> > anything amiss, please let me know here, in email or via a releng or
> > infrastructure ticket.
>
> Is it stuck again? I built perl-Path-Class-0.37-14.fc32 over three
> hours ago and still no sign of an update or tagging into f32.
>
> Paul.
> ___
> 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

University people in Fedora: Education/University SIG

[Timothée Floure]

Hello everyone,

This is a follow-up email for some "coffee discussions" we had at flock a few
weeks ago. Sorry for the delay!

The Fedora community contains a lot of university students, many of us
packaging tools for their courses and acting as first-level Linux support for
the local student community. The problems we encounter and work on are not
identical but share a common base: it only makes sense to collaborate.

We found (over a few flock coffee breaks) 5-6 fedorans interested in joining
such an initiative and are currently creating a SIG as a mean to communicate.
We haven't decided on anything yet, except that we would like to work together
to make Fedora an accessible platform for student and courses in an university
context. We expect overlapping interests and collaboration with others SIGs,
especially if related to the academic world such as NeuroFedora or ML.

We are aware of the dormant Education SIG [1] but have yet to discuss how to
position - or integrate - ourselve.

A slightly more detailed description can be found on the related wiki page [2].
I invite you to add your name to its members section you're interested to work
with us. We will figure out communication and coordination mediums around next
week.

[1] https://fedoraproject.org/wiki/SIGs/Education
[2] https://fedoraproject.org/wiki/SIGs/University

Cheers,

-- 
Timothée


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: Debates/back and forths

[Adam Williamson]

On Wed, 2019-08-28 at 07:03 -0400, Danny Lee wrote:
> Hi all,
> 
> I'm new to the devel list and fedora in general, but i was wondering if 
> these kind of back and forths between a few people is a frequent 
> occurrence.  I came to Fedora to volunteer what little spare time I have 
> to help the Fedora project in some little ways. I don't feel that should 
> include wading through dozens of emailed back and forths between 
> individuals who seem to have strong, immovable opinions, I just don't 
> have time for that.
> 
> Is there any chance there is a moderated list or discussion group about 
> current project tasks and issues rather than debates about how to do 
> things?  Or perhaps, a way to turn off certain threads or block certain 
> posters?

Agree with others that devel@ is definitely something you should filter
into a folder and read selectively. I read every mail to the list for 8
years or so but even I gave up in the end :P

To answer the second part of your question: devel@ is not usually where
most concrete 'project tasks and issues' come up at all. It's used for
a range of things, but often it is more general discussion and kinda
kicking things around than for specific planning of individual tasks.

The various groups within Fedora generally plan tasks on their own
lists and/or in some kind of issue tracker, often a Pagure project.
Getting more specific depends a bit on exactly what kind of
contribution you're interested in. Have you seen the page at
https://fedoraproject.org/wiki/Join ? It's a pretty good starting
point. If you're still having trouble finding a way in, feel free to
mail me, I can probably either help you or point you at someone else
who can :)
-- 
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: Debates/back and forths

[Chris Peters]

Open debate is essential =)

But sometimes threads get drowned by Excessive Participation (TM) from one or 
two people replying to every sub-thread and sub-sub-thread.

Eg, "Fedora Workstation and disabled by default firewall" thread has 25+ people 
and 100+ replies, but a quarter of the replies are from a single person.

Maybe the code of conduct could politely nudge people towards *quality* over 
quantity (so that voices don't get drowned and big threads aren't so tiresome 
to keep up with)

Chris
___
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: Debates/back and forths

[Tony Nelson]

On 19-08-28 07:03:00, Danny Lee wrote:

Hi all,

I'm new to the devel list and fedora in general, but i was wondering
if these kind of back and forths between a few people is a frequent
occurrence.  I came to Fedora to volunteer what little spare time I
have to help the Fedora project in some little ways. I don't feel
that should include wading through dozens of emailed back and forths
between individuals who seem to have strong, immovable opinions, I
just don't have time for that.

 ...

Perhaps you would prefer the low traffic of the Devel Announce list?

Check in the list archives first.


There were suggestions that your email provider might do mail filtering
into folders.  That is usually a function of the email client that
you use to read email, and if yours doesn't do it well, you can choose
another.  Thunderbird and Evolution come to mind (I use balsa myself,
but I don't necessarily recommend it).

--

TonyN.:'   
  '  
___
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 Workstation and disabled by default firewall

[Tony Nelson]

On 19-08-28 01:03:51, Chris Murphy wrote:
On Tue, Aug 27, 2019 at 10:26 PM Christopher  
 wrote:

>
> On Tue, Aug 27, 2019 at 9:27 PM Chris Murphy  
 wrote:

>
> > The Workstation technical specification document says in part:
>
> Where is the full technical specification document, so one can read  
it

> not in part, but in full?

https://fedoraproject.org/wiki/Workstation/Technical_Specification

The discussion and decision to not include firewall-config (GUI
configuration application for firewalld) by default, five years ago
https://lists.fedoraproject.org/archives/list/desk...@lists.fedoraproject.org/thread/QROJ6LHGT5UUMNTBXEIJTPHPI3IWGFRY/

What's changed since then? It's fine to have purposeful re-evaluation
of any requirements or specification, but someone or a group need to
look through the prior history, and clearly articulate why that
history is obsolete, and produce a compelling case why this should be
re-evaluated.

 ...

Well, they promised to be responsible and it is asserted that an open
firewall is not responsible, and they said they would develp solutions
but they opened the firewall instead, and they haven't shown an actual
example of software available through gnome-software (the only supported
way to install software on Gnome and Fedora Workstation) that needs the
firewall to be already open.  Properly packaged Fedora software uses
either the D-Bus interface at runtime or firewall-cmd in a scriptlet at
install time to open any needed ports, so an example of software that
works only because the ports are already open would be good.

Note that software needing open inbound ports will usually need ports
opened (or a service enabled) on some router, along with setup to direct
incoming connections to the correct internal IP, so it can't work OOB.
It's possible that there is some confusion here, and Gnome thinks that
outbound ports need to be opened and that that is what they have done.

I haven't needed to do anything with firewalld on my machines in the
last few years, and my zone is "public", so I'm not very familiar with
firewalld.  (I use XFCE, not Workstation.)

--

TonyN.:'   
  '  
___
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: Minimization Team Meeting notes 2019-08-28

[Adam Williamson]

On Wed, 2019-08-28 at 17:43 +0200, Adam Samalik wrote:
> Minutes:
> https://meetbot.fedoraproject.org/fedora-meeting-1/2019-08-28/minimization.2019-08-28-15.00.html
> Minutes (text):
> https://meetbot.fedoraproject.org/fedora-meeting-1/2019-08-28/minimization.2019-08-28-15.00.txt
> Log:
> https://meetbot.fedoraproject.org/fedora-meeting-1/2019-08-28/minimization.2019-08-28-15.00.log.html
> 
> 
> 
> #fedora-meeting-1: Minimization Team Meeting
> 
> 
> 
> Meeting started by asamalik at 15:00:40 UTC. The full logs are available
> at
> https://meetbot.fedoraproject.org/fedora-meeting-1/2019-08-28/minimization.2019-08-28-15.00.log.html
> .
> 
> 
> 
> Meeting summary
> ---
> * Roll call  (asamalik, 15:00:40)
> 
> * === Admin ===  (asamalik, 15:05:02)
> 
> * === Focus & what's next? ===  (asamalik, 15:09:24)
> 
> * === Open Floor ===  (asamalik, 15:38:43)

You might want to get used to using some #action's, #info's etc. to
make this a bit more useful :)
-- 
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

[Bug 1744782] (RFE) EPEL8 branch of perl-Crypt-SSLeay

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 CC|caillon+fedoraproject@gmail |
   |.com, caol...@redhat.com,   |
   |john.j5l...@gmail.com,  |
   |ka...@ucw.cz,   |
   |rhug...@redhat.com, |
   |rstr...@redhat.com, |
   |sandm...@redhat.com |



--- Comment #3 from Jitka Plesnikova  ---
Hi,

what do you use as a source for OCS Inventory? 

I looked at https://github.com/OCSInventory-NG/UnixAgent and there is written
following:

To get SSL communications working (for packages deployment or HTTPS
communications to OCS server), you need these modules:
  - Crypt::SSLeay if you use LWP prior to version 6
  - LWP::Protocol::https if you use LWP version 6 or more

RHEL 8 provides perl(LWP) = 6.34, so you should requires
per(LWP::Protocol::https) which is part of RHEL 8.

I checked the code and Crypt::SSLeay is used only with LWP < 5.83. No changes
in this code are needed.

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

Re: Minimization Objective report

[Brian (bex) Exelbierd]

This was an awesome objective update and one I hope we will see more of
from other Objectives!

regards,

bex

On Wed, Aug 28, 2019 at 10:33 AM Adam Samalik  wrote:

> This is the Minimization Objective [0] update.
>
> Status: Discovery phase
>
> == Toolbox ==
>
> The 'showme' tool got renamed to 'rpm-showme' to make it more
> discoverable. It has been also moved to a new repository of the same name
> [1].
>
> New features:
>
> * report — generates an html report [2] [3] comparing multiple
> installations
> * list — simply lists all packages of a given installation
> * size — prints the total size of all packages in a given installation
>
> See the README in the repository [1] for more details.
>
> == Feedback Pipeline ==
>
> Prototyping Feedback Pipeline — active monitoring and reporting of
> dependency changes, more info coming in a blog post.
>
> Collaborating with the IoT Objective on some initial testing of the
> Feedback Pipeline.
>
> == Use case analysis ==
>
> Looking at 'httpd', 'nginx', and 'dnf' to see what could be potentially
> minimized.
>
> == New Status page ==
>
> A new status page [4] has been created showing, well, the current status,
> and also listing all the reports (like this one).
>
> == How to get involved ==
>
> See if there is anything interesting to you on the action plan [42], or
> reach
> out with something you think is useful but is missing there. Open a ticket
> in the tracker [43] or discuss in #fedora-devel on IRC.
>
> Cheers,
> Adam
>
>
> [0] Objective: https://docs.fedoraproject.org/en-US/minimization/
> [1] rpm-showme: https://pagure.io/minimization/rpm-showme
> [2] Example report 1: https://asamalik.fedorapeople.org/showme/report.html
> [3] Example report 2:
> https://asamalik.fedorapeople.org/showme/report-sizes.html
> [4] Status page: https://docs.fedoraproject.org/en-US/minimization/status/
> [42] Action plan:
> https://docs.fedoraproject.org/en-US/minimization/action-plan/
> [43] Issue tracker: https://pagure.io/minimization/issues
>
> --
>
> Adam Šamalík
> ---
> Senior Software Engineer
> 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
>


-- 
Brian "bex" Exelbierd (he/him/his)
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
bexel...@redhat.com | b...@pobox.com
___
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

Minimization Team Meeting notes 2019-08-28

[Adam Samalik]

Minutes:
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-08-28/minimization.2019-08-28-15.00.html
Minutes (text):
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-08-28/minimization.2019-08-28-15.00.txt
Log:
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-08-28/minimization.2019-08-28-15.00.log.html



#fedora-meeting-1: Minimization Team Meeting



Meeting started by asamalik at 15:00:40 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-08-28/minimization.2019-08-28-15.00.log.html
.



Meeting summary
---
* Roll call  (asamalik, 15:00:40)

* === Admin ===  (asamalik, 15:05:02)

* === Focus & what's next? ===  (asamalik, 15:09:24)

* === Open Floor ===  (asamalik, 15:38:43)

Meeting ended at 15:41:36 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* asamalik (51)
* cverna (18)
* zbyszek (16)
* zodbot (13)
* tdawson (7)
* Guest34216 (2)
* jaruga (1)
* ignatenkobrain (0)
* salimma (0)
* feborges (0)
* pbrobinson (0)
* Son_Goku (0)
* lorbus (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-- 

Adam Šamalík
---
Senior Software Engineer
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: Fedora Workstation and disabled by default firewall

[John Harris]

On Wednesday, August 28, 2019 2:45:37 AM MST Björn Persson wrote:
> If an attacker guesses your passphrase, then it's your weak passphrase
> that allows them to break in.

No. Having it wide open to the network means it can be broken, even through 
brute force if necessary.

> (That said, I'd be in favor of tightening the default SSHD
> configuration to allow only public key authentication, as long as it
> would still be possible to gain initial access to a freshly installed
> headless server.)

That would make it hard for "our moms and dads" to use, so I'm not sure that's 
a good idea.

> I have no idea what you mean by "running local".

A program that binds either your currently configured interface(s) or all 
interfaces by default. These are not at all uncommon. Some of them are 
designed for local access only, and yet they still bind all interfaces.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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 Workstation and disabled by default firewall

[John Harris]

On Wednesday, August 28, 2019 3:33:48 AM MST Jiri Eischmann wrote:
> Adam Williamson píše v Út 27. 08. 2019 v 16:01 -0700:
> 
> > On Tue, 2019-08-27 at 15:06 +0200, Jiri Eischmann wrote:
> > 
> > > mcatanz...@gnome.org píše v Út 27. 08. 2019 v 15:07 +0300:
> > > 
> > > > On Tue, Aug 27, 2019 at 4:22 AM, John Harris <
> > > > joh...@splentity.com>
> > > > wrote:
> > > > 
> > > > > No, that is not how this works, at all. First, let's go ahead
> > > > > and
> > > > > address the 
> > > > > idea that "if the firewall blocks it, the app breaks, so it's
> > > > > the
> > > > > firewall's 
> > > > > fault": It's not. If the firewall has not been opened, that
> > > > > just
> > > > > means it 
> > > > > can't be accessed by remote systems until you EXPLICITLY open
> > > > > that
> > > > > port, with 
> > > > > the correct protocol, on your firewall. That's FINE. That's how
> > > > > it's designed 
> > > > > to work. There's nothing wrong with that.
> > > > > 
> > > > > This means that the system administrator (or owner, if this is
> > > > > some 
> > > > > individual's personal system) must allow the port to be
> > > > > accessed
> > > > > remotely, 
> > > > > before the app can be reached remotely, increasing the security
> > > > > of
> > > > > the system.
> > > > 
> > > > 
> > > > You've already lost me here. Sorry, but we do not and will not
> > > > install a firewall GUI that exposes complex technical details
> > > > like
> > > > port numbers. Expecting users to edit firewall rules to use their
> > > > apps is ridiculous and I'm not really interested in debating it.
> > > 
> > > 
> > > Yeah, when you ask users questions they're not qualified to answer,
> > > you're just creating bad design.
> > > I always imagine my mom (who BTW has been a Fedora user for years)
> > > how
> > > she'd deal with that and I can't really imagine her opening/closing
> > > firewall ports. She'd be puzzled even by "Do you trust this
> > > network?"
> > > and would probably just click "Yes" to make it go away. No
> > > additional
> > > security, just annoying UX.
> > 
> > 
> > However, Fedora Workstation is an edition. Which means it has a
> > *policy-defined* target audience. That target audience is defined
> > here:
> > https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience
> > 
> > 
> > Case 1: "Engineering/CS student"
> > Case 2: "Independent Developer"
> > Case 3: "Small Company Developer"
> > Case 4: "Developer in a Large Organization"
> > 
> > Are those people we believe do not understand the concepts associated
> > with firewalls?
> 
> 
> And the same document says:
> "While our focus is on creating a top-class developer workstation, our
> developer focus will not compromise the aforementioned goal to be a
> polished and user friendly system that appeals to a wide general
> audience."
> 
> Having a target audience in mind doesn't mean we have to make bad
> design for everyone else. In addition their preferences could be
> actually the same. Just look at macOS, it's made easy for our moms and
> dads and very popular with developers at the same time.
> 
> Jiri 
> ___
> 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

Essentially disabling the firewall falls under having a "bad design for 
everyone else". Disabling the firewall is something that could be considered 
hostile to the user.

I fail to see how the comparison to MacOS applies here. MacOS is not a FLOSS 
project, nor is it some standard. I know GNOME folks seem to think MacOS is 
great and all, to the point that they copy stuff from MacOS and throw it in, 
calling it a "feature", but this is not a feature.

If you want something that's both easy for "our moms and dads", and something 
that keeps them safe, because both are certainly possible at once, you can 
just move back to the default firewall config.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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 31 compose report: 20190828.n.0 changes

[Fedora Branched Report]

OLD: Fedora-31-20190826.n.0
NEW: Fedora-31-20190828.n.0

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  9
Dropped packages:13
Upgraded packages:   202
Downgraded packages: 1

Size of added packages:  924.23 MiB
Size of dropped packages:333.07 MiB
Size of upgraded packages:   1.93 GiB
Size of downgraded packages: 28.98 MiB

Size change of upgraded packages:   3.69 MiB
Size change of downgraded packages: -6.49 MiB

= ADDED IMAGES =
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-31-20190828.n.0.iso

= DROPPED IMAGES =
Image: Container_Minimal_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Minimal-Base-31-20190826.n.0.aarch64.tar.xz

= ADDED PACKAGES =
Package: community-mysql-8.0.17-2.module_f31+6046+54c90baf
Summary: MySQL client programs and shared libraries
RPMs:community-mysql community-mysql-common community-mysql-devel 
community-mysql-errmsg community-mysql-libs community-mysql-server 
community-mysql-test
Size:897.08 MiB

Package: liberation-circuit-1.3-2.20190824git29bc0ce0.fc31
Summary: Real-time strategy game with programmable units
RPMs:liberation-circuit liberation-circuit-data
Size:4.39 MiB

Package: nodejs-dateformat-3.0.3-1.fc29
Summary: Steven Levithan's excellent dateFormat() function for Node.js
RPMs:nodejs-dateformat
Size:14.58 KiB

Package: python-fontconfig-0.5.1-1.fc31
Summary: Python bindings for Fontconfig library
RPMs:python3-fontconfig
Size:329.18 KiB

Package: telepathy-gabble-0.18.4-7.fc29
Summary: A Jabber/XMPP connection manager
RPMs:telepathy-gabble
Size:3.70 MiB

Package: telepathy-salut-0.8.1-15.fc29
Summary: Link-local XMPP telepathy connection manager
RPMs:telepathy-salut
Size:2.28 MiB

Package: thrift-0.10.0-19.fc31
Summary: Software framework for cross-language services development
RPMs:fb303 fb303-devel perl-thrift python3-fb303 python3-thrift thrift 
thrift-devel thrift-glib thrift-qt
Size:13.21 MiB

Package: vboot-utils-20190823-1.git595108c0.fc31
Summary: Verified Boot Utility from Chromium OS
RPMs:vboot-utils
Size:1.03 MiB

Package: wimlib-1.13.1-1.fc31
Summary: Open source Windows Imaging (WIM) library
RPMs:wimlib wimlib-devel wimlib-utils
Size:2.19 MiB


= DROPPED PACKAGES =
Package: cloudtoserver-0.2-10.fc31
Summary: Tool to convert Fedora Cloud instance to Fedora Server instance
RPMs:cloudtoserver
Size:22.76 KiB

Package: cycle-0.3.1-31.fc31
Summary: Calendar program for women
RPMs:cycle
Size:57.31 KiB

Package: dogtag-pki-10.6.10-1.module_f31+3708+9758368d
Summary: Dogtag PKI Package
RPMs:dogtag-pki dogtag-pki-console-theme dogtag-pki-server-theme
Size:430.07 KiB

Package: gen-oath-safe-0.10.1-6.fc31
Summary: Script for generating HOTP/TOTP keys (and QR code)
RPMs:gen-oath-safe
Size:10.19 KiB

Package: jbrout-0.4-0.22.git20140930reva7c8fb8.fc31
Summary: Photo manager, written in python/pygtk
RPMs:jbrout
Size:190.62 KiB

Package: jss-4.5.3-1.module_f31+3708+9758368d
Summary: Java Security Services (JSS)
RPMs:jss jss-javadoc
Size:9.50 MiB

Package: ldapjdk-4.20.0-2.module_f31+3708+9758368d
Summary: LDAP SDK
RPMs:ldapjdk ldapjdk-javadoc
Size:365.58 KiB

Package: oggconvert-0.3.3-21.fc31
Summary: Convert media files to Free formats
RPMs:oggconvert
Size:82.21 KiB

Package: pki-core-10.6.10-1.module_f31+3708+9758368d
Summary: PKI Core Package
RPMs:pki-base pki-base-java pki-ca pki-console pki-javadoc pki-kra pki-ocsp 
pki-server pki-symkey pki-tks pki-tools pki-tps python3-pki
Size:16.24 MiB

Package: rootplot-2.2.2-8.fc30
Summary: Plots ROOT data with matplotlib
RPMs:python2-rootplot
Size:491.06 KiB

Package: rubygem-compass-rails-2.0.4-8.fc31
Summary: Integrate Compass into Rails 2.3 and up
RPMs:rubygem-compass-rails rubygem-compass-rails-doc
Size:280.97 KiB

Package: skychart-4.1.1-3.3925svn.module_f31+4086+95427ab0
Summary: Planetarium software for the advanced amateur astronomer
RPMs:skychart skychart-data-dso skychart-data-stars skychart-doc
Size:305.40 MiB

Package: tomcatjss-7.3.7-1.module_f31+3708+9758368d
Summary: JSS Connector for Apache Tomcat
RPMs:tomcatjss
Size:40.10 KiB


= UPGRADED PACKAGES =
Package:  R-RUnit-0.4.32-1.fc31
Old package:  R-RUnit-0.4.26-19.fc31
Summary:  R Unit test framework
RPMs: R-RUnit
Size: 296.39 KiB
Size change:  50.99 KiB
Changelog:
  * Mon Aug 26 2019 Elliott Sales de Andrade  - 
0.4.32-1
  - Update to latest version


Package:  R-timeDate-3043.102-1.fc31
Old package:  R-timeDate-3010.98-13.fc31
Summary:  Rmetrics - chronological and calendar objects
RPMs: R-timeDate
Size: 1.43 MiB
Size change:  -2.18 KiB
Changelog:
  * Mon Aug 26 2019 Elliott Sales de Andrade  - 
3043.102-1
  - Update to latest version


Package:  ack-3.1.0-1.fc31
Old package:  ack

Re: Rawhide gating: What shell be done with failed updates?

[Miro Hrončok]

On 28. 08. 19 16:18, Pierre-Yves Chibon wrote:

On Wed, Aug 28, 2019 at 03:11:33PM +0200, Miro Hrončok wrote:

On 28. 08. 19 15:05, Pierre-Yves Chibon wrote:

In this case I'd encourage to unpush update A since you know beforehand and are
not interested in ever seeing this update go through.
Do nothing is also an option, though it is less clear as what it means to other
contributors.

Makes sense. Thanks. Let's document this somewhere. Where?

Good question.
Maybe the packaging guidelines?


I don't think there is anything about updates or bodhi in there at all.


Or in the rawhide-gating docs? [1]


I guess that is better. Is there any section about test failures and
waiving? I Couldn't find one. I'd put it somewhere in there.


The FAQ mentions it:
https://docs.fedoraproject.org/en-US/rawhide-gating/faq/#_how_do_i_unblock_an_update



OK, let's put everything to FAQ and we can later reorganize that somehow when it 
gets too long.


https://pagure.io/cpe/rawhide-gating-docs/pull-request/6

--
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: [Test-Announce] Fedora 31 Beta Freeze

[Paul Howarth]

On Tue, 27 Aug 2019 17:52:00 -0700
Kevin Fenzi  wrote:

> On 8/27/19 4:27 AM, Miro Hrončok wrote:
> > On 27. 08. 19 13:06, Paul Howarth wrote:  
> >> On Mon, 26 Aug 2019 20:55:18 -0400
> >> Mohan Boddu  wrote:
> >>  
> >>> Hi all,
> >>>
> >>> Today's an important day on the Fedora 31 schedule[1], with
> >>> several significant cut-offs. First of all today is
> >>> the Bodhi activation point [2]. That means that from now all
> >>> Fedora 31 packages must be submitted to
> >>> updates-testing and pass the relevant requirements[3] before they
> >>> will be marked as 'stable' and moved to the
> >>> fedora repository.  
> >>
> >> I don't know if this is related but the Rawhide (f32) builds I've
> >> done today (e.g. perl-MCE-1.846-1.fc32) don't seem to be going
> >> through the gating process and into rawhide.
> >>
> >> $ koji -q list-tagged --latest f32-updates-candidate perl-MCE
> >> perl-MCE-1.846-1.fc32 f32-updates-candidate
> >> pghmcfc
> >>
> >> $ koji -q list-tagged --latest f32 perl-MCE
> >> perl-MCE-1.845-1.fc32 f32
> >> pghmcfc  
> > 
> > https://pagure.io/fedora-infrastructure/issue/8138  
> 
> This was fixed earlier today, sorry for not circling back and noting
> that here.
> 
> I think everything should be processed that was stuck, if anyone sees
> anything amiss, please let me know here, in email or via a releng or
> infrastructure ticket.

Is it stuck again? I built perl-Path-Class-0.37-14.fc32 over three
hours ago and still no sign of an update or tagging into f32.

Paul.
___
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: Rawhide gating: What shell be done with failed updates?

[Pierre-Yves Chibon]

On Wed, Aug 28, 2019 at 03:11:33PM +0200, Miro Hrončok wrote:
> On 28. 08. 19 15:05, Pierre-Yves Chibon wrote:
> > > > In this case I'd encourage to unpush update A since you know beforehand 
> > > > and are
> > > > not interested in ever seeing this update go through.
> > > > Do nothing is also an option, though it is less clear as what it means 
> > > > to other
> > > > contributors.
> > > Makes sense. Thanks. Let's document this somewhere. Where?
> > Good question.
> > Maybe the packaging guidelines?
> 
> I don't think there is anything about updates or bodhi in there at all.
> 
> > Or in the rawhide-gating docs? [1]
> 
> I guess that is better. Is there any section about test failures and
> waiving? I Couldn't find one. I'd put it somewhere in there.

The FAQ mentions it:
https://docs.fedoraproject.org/en-US/rawhide-gating/faq/#_how_do_i_unblock_an_update

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

[Bug 1744782] (RFE) EPEL8 branch of perl-Crypt-SSLeay

[bugzilla]

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

Pat Riehecky  changed:

   What|Removed |Added

  Flags|needinfo?(riehe...@fnal.gov |
   |)   |



--- Comment #2 from Pat Riehecky  ---
Hello,

I'm trying to get OCS Inventory built up for RHEL8.  It has a hard dependency
on perl-Crypt-SSLeay.  Do you know what is required to switch between the two?

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

Fedora-31-20190828.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 21/152 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-31-20190826.n.0):

ID: 437569  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/437569
ID: 437570  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/437570
ID: 437573  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/437573
ID: 437587  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/437587
ID: 437589  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/437589
ID: 437602  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/437602
ID: 437620  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/437620
ID: 437622  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/437622
ID: 437680  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/437680
ID: 437686  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/437686
ID: 437689  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/437689
ID: 437691  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/437691
ID: 437694  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/437694
ID: 437695  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/437695
ID: 437696  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/437696
ID: 437701  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/437701

Old failures (same test failed in Fedora-31-20190826.n.0):

ID: 437583  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/437583
ID: 437618  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/437618
ID: 437647  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/437647
ID: 437653  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/437653
ID: 437672  Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/437672
ID: 437677  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/437677

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

Old soft failures (same test soft failed in Fedora-31-20190826.n.0):

ID: 437684  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/437684
ID: 437685  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/437685

Passed openQA tests: 94/152 (x86_64)

Skipped non-gating openQA tests: 36 of 154

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
1 packages(s) added since previous compose: samba-libs
System load changed from 0.04 to 0.26
Previous test data: https://openqa.fedoraproject.org/tests/436033#downloads
Current test data: https://openqa.fedoraproject.org/tests/437553#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
1 packages(s) added since previous compose: samba-libs
Previous test data: https://openqa.fedoraproject.org/tests/436035#downloads
Current test data: https://openqa.fedoraproject.org/tests/437555#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
Used mem changed from 833 MiB to 714 MiB
4 packages(s) added since previous compose: flatpak-libs, ostree, 
ostree-libs, samba-libs
1 services(s) added since previous compose: 
dbus-:1.6-org.freedesktop.problems@0.service
  loaded active running dbus-:1.6-org.freedesktop.problems@0.service
1 services(s) removed since previous compose: 
dbus-:1.7-org.freedesktop.problems@0.service
  loaded active running dbus-:1.7-org.freedesktop.problems@0.service
System load changed from 1.46 to 0.38
Previous test data: https://openqa.fedoraproject.org/tests/436084#downloads
Current test data: https://openqa.fedoraproject.org/tests/437604#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
4 packages(s) added since previous compose: flatpak-libs, ostree, 
ostree-libs, samba-libs
System load changed from 0.61 to 1.01
Average CPU usage changed from 36.82380952 to 12.08571429

[EPEL-devel] Re: Koschei enablement for EPEL 8

[Troy Dawson]

On Wed, Aug 28, 2019 at 1:19 AM Petr Pisar  wrote:
>
> On Wed, Aug 28, 2019 at 09:15:47AM +0200, Mikolaj Izdebski wrote:
> > Fedora infrastructure has been asked [1] to enable Koschei [2] for
> > EPEL 8. Would this be useful to anyone?
>
> Yes.
>
> > If yes, which of build targets
> > (epel8-candidate, epel8-playground-candidate) should Koschei submit
> > scratch builds for?
> >
> Both? Though I have no idea if people are actually going to use
> epel8-playground-candidate.
>

I would like epel8-playground on Koschei, whether that's plain
epel8-playground or epel8-playground-candidate, whichever is correct.

Currently all of the KDE builds are only on playground, and will stay
that way until EPEL8 modularity.

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

fedora-review broken?

[Richard Shaw]

While I'm trying to use it for a review on RPM Fusion I don't think the
error is related...

Just running fedora-review without any arguments produces this in the log:

Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
line 236, in run
self._do_run(outfile)
  File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
line 197, in _do_run
Settings.init()
  File "/usr/lib/python3.7/site-packages/FedoraReview/settings.py", line
417, in init
args = parser.parse_args()
  File "/usr/lib64/python3.7/argparse.py", line 1749, in parse_args
args, argv = self.parse_known_args(args, namespace)
  File "/usr/lib64/python3.7/argparse.py", line 1781, in parse_known_args
namespace, args = self._parse_known_args(args, namespace)
  File "/usr/lib64/python3.7/argparse.py", line 1987, in _parse_known_args
start_index = consume_optional(start_index)
  File "/usr/lib64/python3.7/argparse.py", line 1927, in consume_optional
take_action(action, args, option_string)
  File "/usr/lib64/python3.7/argparse.py", line 1855, in take_action
action(self, namespace, argument_values, option_string)
  File "/usr/lib64/python3.7/argparse.py", line 1038, in __call__
parser.exit()
  File "/usr/lib64/python3.7/argparse.py", line 2488, in exit
_sys.exit(status)
SystemExit: 0

When I try to do the review I get:

Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
line 236, in run
self._do_run(outfile)
  File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
line 226, in _do_run
self._do_report(outfile)
  File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
line 99, in _do_report
self._run_checks(self.bug.spec_file, self.bug.srpm_file, outfile)
  File "/usr/lib/python3.7/site-packages/FedoraReview/review_helper.py",
line 117, in _run_checks
self.checks.run_checks(output=output, writedown=not Settings.no_report)
  File "/usr/lib/python3.7/site-packages/FedoraReview/checks.py", line 382,
in run_checks
run_check(name)
  File "/usr/lib/python3.7/site-packages/FedoraReview/checks.py", line 357,
in run_check
check.run()
  File
"/usr/lib/python3.7/site-packages/FedoraReview/plugins/generic_build.py",
line 203, in run
Mock.build(self.srpm.filename)
  File "/usr/lib/python3.7/site-packages/FedoraReview/mock.py", line 457,
in build
self.builddir_cleanup()
  File "/usr/lib/python3.7/site-packages/FedoraReview/mock.py", line 584,
in builddir_cleanup
paths = glob(os.path.join(self.get_builddir("BUILD"), "*"))
  File "/usr/lib/python3.7/site-packages/FedoraReview/mock.py", line 360,
in get_builddir
p = self._get_dir(os.path.join("root", self._topdir[1:]))
  File "/usr/lib/python3.7/site-packages/FedoraReview/mock.py", line 201,
in _get_dir
self._get_root()
  File "/usr/lib/python3.7/site-packages/FedoraReview/mock.py", line 186,
in _get_root
config = compile(content[0], path, "exec")
IndexError: list index out of range

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

Re: Rawhide gating: What shell be done with failed updates?

[Miro Hrončok]

On 28. 08. 19 15:05, Pierre-Yves Chibon wrote:

In this case I'd encourage to unpush update A since you know beforehand and are
not interested in ever seeing this update go through.
Do nothing is also an option, though it is less clear as what it means to other
contributors.

Makes sense. Thanks. Let's document this somewhere. Where?

Good question.
Maybe the packaging guidelines?


I don't think there is anything about updates or bodhi in there at all.


Or in the rawhide-gating docs? [1]


I guess that is better. Is there any section about test failures and waiving? I 
Couldn't find one. I'd put it somewhere in there.


--
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: Rawhide gating: What shell be done with failed updates?

[Pierre-Yves Chibon]

On Wed, Aug 28, 2019 at 02:47:32PM +0200, Miro Hrončok wrote:
> On 28. 08. 19 14:45, Pierre-Yves Chibon wrote:
> > On Wed, Aug 28, 2019 at 01:42:34PM +0200, Miro Hrončok wrote:
> > > On 28. 08. 19 13:24, Pierre-Yves Chibon wrote:
> > > > On Wed, Aug 28, 2019 at 12:16:09PM +0200, Miro Hrončok wrote:
> > > > > On 28. 08. 19 9:32, Clement Verna wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Tue, Aug 27, 2019, 15:35 Miro Hrončok  > > > > > > wrote:
> > > > > > 
> > > > > >   If updates in rawhide gating fail the tests, what is the 
> > > > > > procedure? Should they
> > > > > >   be unpuhsed, or left to rot forever?
> > > > > > 
> > > > > > 
> > > > > > There are a few options here, fix the package so that the tests 
> > > > > > pass,
> > > > > > disable the tests, or waive the results. If none of these are done 
> > > > > > then
> > > > > > yes the update will just stay there to rot.
> > > > > 
> > > > > I meant what to do with the broken updates that are actually broken. 
> > > > > When a
> > > > > new update is created, the older one doesn't seem to be obsoleted or
> > > > > unpushed.
> > > > 
> > > > I'm not sure I understand what you mean. What do you mean with "Broken 
> > > > updates
> > > > that are actually broken"?
> > > 
> > > I mean when I push an update A and a test T realizes update A is broken, 
> > > so
> > > I fix it and push another update B. I.e. I have no interest in waiving the
> > > failed test T in update A, because update A actually was broken.
> > > 
> > > Update B now does not obsolete update A (as you have described in the
> > > paragraph below). As a packager, should I unpush update A or just do
> > > nothing?
> > 
> > In this case I'd encourage to unpush update A since you know beforehand and 
> > are
> > not interested in ever seeing this update go through.
> > Do nothing is also an option, though it is less clear as what it means to 
> > other
> > contributors.
> 
> Makes sense. Thanks. Let's document this somewhere. Where?

Good question.
Maybe the packaging guidelines?
Or in the rawhide-gating docs? [1]


Pierre

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

[EPEL-devel] Re: Koschei enablement for EPEL 8

[Stephen John Smoogen]

On Wed, 28 Aug 2019 at 03:16, Mikolaj Izdebski  wrote:
>
> Fedora infrastructure has been asked [1] to enable Koschei [2] for
> EPEL 8. Would this be useful to anyone? If yes, which of build targets
> (epel8-candidate, epel8-playground-candidate) should Koschei submit
> scratch builds for?
>

Can koschei be limited to a single architecture or does it need to
build against all targets? I am worried about the number of s390
builds we may be adding.



> [1] https://pagure.io/fedora-infrastructure/issue/8099
> [2] https://fedoraproject.org/wiki/Koschei
> ___
> 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



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

Re: [HEADS UP] Retiring python2 and introducing python27 later this week

[Miro Hrončok]

On 28. 08. 19 14:48, Antonio Trande wrote:

`python2-reportlab` looks no longer used by other packages.
`python2-scons` is still required instead:

$ repoquery --disablerepo=* --enablerepo=fedora-source
--enablerepo=updates-source --release rawhide --whatrequires python2-scons


libffado-0:2.4.1-6.fc30.src

minicomputer-0:1.41-26.fc31.src

mypaint-0:1.2.1-20.fc30.src



So the idea is that somebody would like to keep libffado or minicomputer or 
mypaint and we would help them. That would also preserve python2-scons if needed.


I'd rather not try to keep a Python library just for the sake of the library 
itself.

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

[EPEL-devel] Re: [Fedocal] Reminder meeting : EPEL Steering Co

[Stephen John Smoogen]

On Wed, 28 Aug 2019 at 01:26, Thomas Stephen Lee  wrote:
>
> Hi All,
>
> you probably have seen this.
>
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/F6Z7KFVNHB26NXL2IROARWZQVQPT7J6O/

Thomas.

Thank you for the note. I have corrected the meeting assignment.


>
> thanks.
>
> On Tue, Aug 27, 2019 at 11:30 PM  wrote:
>>
>> Dear all,
>>
>> You are kindly invited to the meeting:
>>EPEL Steering Co on 2019-08-28 from 18:00:00 to 19:00:00 GMT
>>At freenode@fedora-meeting
>>
>> The meeting will be about:
>> This is the weekly EPEL Steering Committee Meeting. Agenda is in the 
>> https://infinote.fedoraproject.org/cgit/infinote/tree/epel-meeting-next
>>
>>
>> Source: https://apps.fedoraproject.org/calendar/meeting/9364/
>>
>> ___
>> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
>> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org



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

Re: [HEADS UP] Retiring python2 and introducing python27 later this week

[Antonio Trande]

`python2-reportlab` looks no longer used by other packages.
`python2-scons` is still required instead:

$ repoquery --disablerepo=* --enablerepo=fedora-source
--enablerepo=updates-source --release rawhide --whatrequires python2-scons


libffado-0:2.4.1-6.fc30.src

minicomputer-0:1.41-26.fc31.src

mypaint-0:1.2.1-20.fc30.src

On 28/08/19 13:08, Miro Hrončok wrote:
> On 28. 08. 19 13:02, Antonio Trande wrote:
>> I guess we need to keep `python2-reportlab` and `python2-scons`.
> For what?
> 

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x6e0331dd1699e4d7
GPG key server: https://keys.openpgp.org/



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

Re: [HEADS UP] Retiring python2 and introducing python27 later this week

[Antonio Trande]

`python2-reportlab` looks no longer used by other packages.
`python2-scons` is still required instead:

$ repoquery --disablerepo=* --enablerepo=fedora-source
--enablerepo=updates-source --release rawhide --whatrequires python2-scons


libffado-0:2.4.1-6.fc30.src

minicomputer-0:1.41-26.fc31.src

mypaint-0:1.2.1-20.fc30.src

On 28/08/19 13:08, Miro Hrončok wrote:
> On 28. 08. 19 13:02, Antonio Trande wrote:
>> I guess we need to keep `python2-reportlab` and `python2-scons`.
> For what?
> 

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x6e0331dd1699e4d7
GPG key server: https://keys.openpgp.org/



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

Re: Rawhide gating: What shell be done with failed updates?

[Miro Hrončok]

On 28. 08. 19 14:45, Pierre-Yves Chibon wrote:

On Wed, Aug 28, 2019 at 01:42:34PM +0200, Miro Hrončok wrote:

On 28. 08. 19 13:24, Pierre-Yves Chibon wrote:

On Wed, Aug 28, 2019 at 12:16:09PM +0200, Miro Hrončok wrote:

On 28. 08. 19 9:32, Clement Verna wrote:




On Tue, Aug 27, 2019, 15:35 Miro Hrončok mailto:mhron...@redhat.com>> wrote:

  If updates in rawhide gating fail the tests, what is the procedure? 
Should they
  be unpuhsed, or left to rot forever?


There are a few options here, fix the package so that the tests pass,
disable the tests, or waive the results. If none of these are done then
yes the update will just stay there to rot.


I meant what to do with the broken updates that are actually broken. When a
new update is created, the older one doesn't seem to be obsoleted or
unpushed.


I'm not sure I understand what you mean. What do you mean with "Broken updates
that are actually broken"?


I mean when I push an update A and a test T realizes update A is broken, so
I fix it and push another update B. I.e. I have no interest in waiving the
failed test T in update A, because update A actually was broken.

Update B now does not obsolete update A (as you have described in the
paragraph below). As a packager, should I unpush update A or just do
nothing?


In this case I'd encourage to unpush update A since you know beforehand and are
not interested in ever seeing this update go through.
Do nothing is also an option, though it is less clear as what it means to other
contributors.


Makes sense. Thanks. Let's document this somewhere. Where?

--
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: Rawhide gating: What shell be done with failed updates?

[Pierre-Yves Chibon]

On Wed, Aug 28, 2019 at 01:42:34PM +0200, Miro Hrončok wrote:
> On 28. 08. 19 13:24, Pierre-Yves Chibon wrote:
> > On Wed, Aug 28, 2019 at 12:16:09PM +0200, Miro Hrončok wrote:
> > > On 28. 08. 19 9:32, Clement Verna wrote:
> > > > 
> > > > 
> > > > 
> > > > On Tue, Aug 27, 2019, 15:35 Miro Hrončok  > > > > wrote:
> > > > 
> > > >  If updates in rawhide gating fail the tests, what is the 
> > > > procedure? Should they
> > > >  be unpuhsed, or left to rot forever?
> > > > 
> > > > 
> > > > There are a few options here, fix the package so that the tests pass,
> > > > disable the tests, or waive the results. If none of these are done then
> > > > yes the update will just stay there to rot.
> > > 
> > > I meant what to do with the broken updates that are actually broken. When 
> > > a
> > > new update is created, the older one doesn't seem to be obsoleted or
> > > unpushed.
> > 
> > I'm not sure I understand what you mean. What do you mean with "Broken 
> > updates
> > that are actually broken"?
> 
> I mean when I push an update A and a test T realizes update A is broken, so
> I fix it and push another update B. I.e. I have no interest in waiving the
> failed test T in update A, because update A actually was broken.
> 
> Update B now does not obsolete update A (as you have described in the
> paragraph below). As a packager, should I unpush update A or just do
> nothing?

In this case I'd encourage to unpush update A since you know beforehand and are
not interested in ever seeing this update go through.
Do nothing is also an option, though it is less clear as what it means to other
contributors.


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

Re: No longer supporting mailing lists:

[Gerald B. Cox]

Neal, while you're at it, can you find out what is going on with the RSS
support.  There was quite a bit of discussion about it - but that has been
going on for years now and nothing seems to be happening.

On Tue, Aug 27, 2019 at 11:49 AM Neal Gompa  wrote:

> On Tue, Aug 27, 2019 at 2:31 PM Emmanuel Seyman 
> wrote:
> >
> > * Pierre-Yves Chibon [26/08/2019 09:44] :
> > >
> > > Our recommended solution is to find someone that would maintain the
> mailman3
> > > stack for us.
> >
> > Does this have to be mailman3 or can it be a different mailing list
> manager?
> >
>
> Mailman 3 with the HyperKitty stuff is highly preferred. I've offered
> to the CPE team to help with the software maintenance aspects as we
> continue to self-host as well. I intend to get in touch with the RH
> OSAS group to see if they could help us with our Mailman 3 stuff, as
> they've gotten pretty good at managing those themselves for a bunch of
> communities.
>
>
> --
> 真実はいつも一つ！/ 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
>
___
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: No longer supporting mailing lists:

[Gerald B. Cox]

On Wed, Aug 28, 2019 at 1:40 AM Kevin Kofler  wrote:

> I wrote:
> >> But what about the die-hard NNTP users? You entirely ignored my post to
> >> which you are supposedly replying.
>
> Gerald B. Cox replied:
> > I believe there is a plugin for that with Discourse:
> > https://meta.discourse.org/t/sync-discourse-with-nntp/58602
>
> It would be great to get that deployed on Fedora Infrastructure.
>
> While I'm not convinced that it will work as well as for the mailing
> lists,
> it would definitely be better than nothing (i.e., the status quo).
>
>
Yeah, the issue I think with NNTP and with mailman, hyperkitty, etc. is
there appears to be a lack of innovation, development - and when it does
happen, it happens at a snails pace.  Maybe I'm wrong, but that certainly
appears to be the case from what I saw reading through feature requests,
etc.  Technologies like Discourse, etc. have a more active development
community and the popularity of older technogies is decreasing.  No, I
don't believe mail or usenet is going away anytime soon, but the feature
set is going to remain pretty static - with the new feature sets going to
things like Discourse.  I did search on knode and found that development
was discontinued - and there isn't really a plethora of nntp clients
available - as there was decades ago.  People generally have moved on.
___
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: Rawhide gating: What shell be done with failed updates?

[Kamil Paral]

On Wed, Aug 28, 2019 at 1:24 PM Pierre-Yves Chibon 
wrote:

> Is the issue about updates lingering in -testing?
>

I imagine this could cause some issues for e.g. generic tests that test
everything in -testing in one go, instead of just one particular NVR, for
performance reasons (like rpmdeplint). Or perhaps for tests that try to
push changes in some batches ("every 30 minutes create a batch of
everything proposed in -testing, test it and push to stable together). But
this is just brainstorming, it depends very much on implementation details
and particular use cases. Something to be aware of.
___
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: Debates/back and forths

[Gerald B. Cox]

It's somewhat ironic that Discourse would solve this issue.  As I
previously mentioned, I also don't like having my inbox flooded with forum
threads that don't interest me.  The mailing list solution requires you
setup filters or continuously delete dozens of emails.  Discourse however
allows you to select what you want to read without needing to clean up
afterwards.  As I also pointed out RSS would make HyperKitty a somewhat
acceptable alternative - or as Kevin K. pointed out, you could also use
NNTP.  I personally would rather not, but maybe that would fit your use
case until a good solution could be implemented.

On Wed, Aug 28, 2019 at 4:42 AM Markus Larsson  wrote:

>
>
> On 28 August 2019 13:34:54 CEST, "Dan Čermák" <
> dan.cer...@cgc-instruments.com> wrote:
> >Hi Danni,
> >
> >Danny Lee  writes:
> >
> >> Hi all,
> >>
> >> I'm new to the devel list and fedora in general, but i was wondering
> >if
> >> these kind of back and forths between a few people is a frequent
> >> occurrence.  I came to Fedora to volunteer what little spare time I
> >have
> >> to help the Fedora project in some little ways. I don't feel that
> >should
> >> include wading through dozens of emailed back and forths between
> >> individuals who seem to have strong, immovable opinions, I just don't
> >
> >> have time for that.
> >
> >Welcome to the club of all the "silent" contributors!
> >
> >Usually I try to follow discussions if they appear relevant or
> >interesting to me, but once they "tip over", I mark that thread as
> >deleted and mercilessly nuke everything new that comes in.
> >Yeah, I might miss some important information, but it's unlikely tbh
> >once you are 20 replies deep into a thread.
> >On the other hand: I don't want to spend all my free time reading
> >emails.
> >
> >So, if you don't care about a specific topic: just ignore & delete it.
>
> This is how I think most do it. Just read the interesting parts.
>
> >
> >
> >Btw, this list is imho still pretty moderate, only the occasional
> >controversy causes a huge thread of replies (and people manage to stay
> >civilized and tend to bring in new arguments). There's other lists
> >(unnamed to protect the guilty) where the signal to noise ratio is
> >much,
> >much worse.
>
> The discourse debate and the fw debate are not the norm but the exception.
> We see a few of those from time to time. Most threads aren't like that
> though.
>
> >
> >>
> >> Is there any chance there is a moderated list or discussion group
> >about
> >> current project tasks and issues rather than debates about how to do
> >> things?  Or perhaps, a way to turn off certain threads or block
> >certain
> >> posters?
> >>
> >> Thanks for your time and info you can provide.
> >> ___
> >> 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: Correct path for package bash completion file

[Miro Hrončok]

On 28. 08. 19 13:42, Guido Aulisi wrote:

Ciao,
what is the right path for package bash completion file?

Most packages put then in %sysconf/bash_completion.d
some other (and bash_completion itself) in %datadir/bash-completion/completions/

IMHO I think %sysconf should be for users and %datadir for packages
Am I correct?


Yes.

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

Correct path for package bash completion file

[Guido Aulisi]

Ciao,
what is the right path for package bash completion file?

Most packages put then in %sysconf/bash_completion.d
some other (and bash_completion itself) in %datadir/bash-completion/completions/

IMHO I think %sysconf should be for users and %datadir for packages
Am I correct?

Thanks

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: Rawhide gating: What shell be done with failed updates?

[Miro Hrončok]

On 28. 08. 19 13:24, Pierre-Yves Chibon wrote:

On Wed, Aug 28, 2019 at 12:16:09PM +0200, Miro Hrončok wrote:

On 28. 08. 19 9:32, Clement Verna wrote:




On Tue, Aug 27, 2019, 15:35 Miro Hrončok mailto:mhron...@redhat.com>> wrote:

 If updates in rawhide gating fail the tests, what is the procedure? Should 
they
 be unpuhsed, or left to rot forever?


There are a few options here, fix the package so that the tests pass,
disable the tests, or waive the results. If none of these are done then
yes the update will just stay there to rot.


I meant what to do with the broken updates that are actually broken. When a
new update is created, the older one doesn't seem to be obsoleted or
unpushed.


I'm not sure I understand what you mean. What do you mean with "Broken updates
that are actually broken"?


I mean when I push an update A and a test T realizes update A is broken, so I 
fix it and push another update B. I.e. I have no interest in waiving the failed 
test T in update A, because update A actually was broken.


Update B now does not obsolete update A (as you have described in the paragraph 
below). As a packager, should I unpush update A or just do nothing?



We did think about obsoleting updates when a newer one is created but decided
not to (if for some reasons -1's tests take longer than -2's, the outcome of
-1's tests run may still be of interest for the packager and yum/dnf will anyway
prefer the higher version).

Is the issue about updates lingering in -testing?


Yes.

--
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: Debates/back and forths

[Markus Larsson]

On 28 August 2019 13:34:54 CEST, "Dan Čermák"  
wrote:
>Hi Danni,
>
>Danny Lee  writes:
>
>> Hi all,
>>
>> I'm new to the devel list and fedora in general, but i was wondering
>if 
>> these kind of back and forths between a few people is a frequent 
>> occurrence.  I came to Fedora to volunteer what little spare time I
>have 
>> to help the Fedora project in some little ways. I don't feel that
>should 
>> include wading through dozens of emailed back and forths between 
>> individuals who seem to have strong, immovable opinions, I just don't
>
>> have time for that.
>
>Welcome to the club of all the "silent" contributors!
>
>Usually I try to follow discussions if they appear relevant or
>interesting to me, but once they "tip over", I mark that thread as
>deleted and mercilessly nuke everything new that comes in.
>Yeah, I might miss some important information, but it's unlikely tbh
>once you are 20 replies deep into a thread.
>On the other hand: I don't want to spend all my free time reading
>emails.
>
>So, if you don't care about a specific topic: just ignore & delete it.

This is how I think most do it. Just read the interesting parts.

>
>
>Btw, this list is imho still pretty moderate, only the occasional
>controversy causes a huge thread of replies (and people manage to stay
>civilized and tend to bring in new arguments). There's other lists
>(unnamed to protect the guilty) where the signal to noise ratio is
>much,
>much worse.

The discourse debate and the fw debate are not the norm but the exception. We 
see a few of those from time to time. Most threads aren't like that though.

>
>>
>> Is there any chance there is a moderated list or discussion group
>about 
>> current project tasks and issues rather than debates about how to do 
>> things?  Or perhaps, a way to turn off certain threads or block
>certain 
>> posters?
>>
>> Thanks for your time and info you can provide.
>> ___
>> 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: Debates/back and forths

[Dan Čermák]

Hi Danni,

Danny Lee  writes:

> Hi all,
>
> I'm new to the devel list and fedora in general, but i was wondering if 
> these kind of back and forths between a few people is a frequent 
> occurrence.  I came to Fedora to volunteer what little spare time I have 
> to help the Fedora project in some little ways. I don't feel that should 
> include wading through dozens of emailed back and forths between 
> individuals who seem to have strong, immovable opinions, I just don't 
> have time for that.

Welcome to the club of all the "silent" contributors!

Usually I try to follow discussions if they appear relevant or
interesting to me, but once they "tip over", I mark that thread as
deleted and mercilessly nuke everything new that comes in.
Yeah, I might miss some important information, but it's unlikely tbh
once you are 20 replies deep into a thread.
On the other hand: I don't want to spend all my free time reading
emails.

So, if you don't care about a specific topic: just ignore & delete it.


Btw, this list is imho still pretty moderate, only the occasional
controversy causes a huge thread of replies (and people manage to stay
civilized and tend to bring in new arguments). There's other lists
(unnamed to protect the guilty) where the signal to noise ratio is much,
much worse.

>
> Is there any chance there is a moderated list or discussion group about 
> current project tasks and issues rather than debates about how to do 
> things?  Or perhaps, a way to turn off certain threads or block certain 
> posters?
>
> Thanks for your time and info you can provide.
> ___
> 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


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: New release of Mock (fixes and subscription-manager support)

[Nico Kadel-Garcia]

On Wed, Aug 28, 2019 at 7:02 AM Miroslav Suchý  wrote:
>
> Dne 28. 08. 19 v 4:06 Nico Kadel-Garcia napsal(a):
> > i will point out, from experience with subscription manager, that
> > downloading RPM's from subscription-manager is unacceptably slow
> > inmost build environments. Y
>
> Really? cdn.redhat.com is handled by CDN Akamai. It should be pretty fast.
> Thou, issues happens. I recall one issue from past which was caused by bad 
> routing via L3.
> If Red Hat CDN is slow for you, then please contact Red Hat Support.
> --
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys

If you'd like laughs, look me up. I used to evaluate and in a few
cases designed hardware for Akamai, including their first bulk arrays.
In fact, I built some of their hardened Red Hat operating systems back
before RHEL and Fedora, and I was later delighted that "mock" used
some chroot tools similar to those I used for building and adapting
operating systems for world deployment. Unless Akamai has changed
quite a lot, and they may have, bulky and relatively low traffic
objects are much less likely to remain cached in the proxes at that
"last mile". And unless Red Hat is paying quite a lot to Akamai, they
may not be getting the highest available tier of service. They
wouldn't normally *need* it. RPM transfers and metadata can usually
stand somewhat slower delivery than the highest volume streaming
channels might provide.

The "mirror the RPM mirrors locally" trick goes back decades. and has
been a mainstay for "mock" performance for me. It's also really,
really useful for cluster servers of Fedora, RHEL, etc. to keep from
choking the external network to death and timing out a lot of yum
updates across a cluster. I even used to link it through "rsnapshot"
to provide date-stamped copies of rawhide, though I've not needed that
in a few years.
___
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: Rawhide gating: What shell be done with failed updates?

[Pierre-Yves Chibon]

On Wed, Aug 28, 2019 at 12:16:09PM +0200, Miro Hrončok wrote:
> On 28. 08. 19 9:32, Clement Verna wrote:
> > 
> > 
> > 
> > On Tue, Aug 27, 2019, 15:35 Miro Hrončok  > > wrote:
> > 
> > If updates in rawhide gating fail the tests, what is the procedure? 
> > Should they
> > be unpuhsed, or left to rot forever?
> > 
> > 
> > There are a few options here, fix the package so that the tests pass,
> > disable the tests, or waive the results. If none of these are done then
> > yes the update will just stay there to rot.
> 
> I meant what to do with the broken updates that are actually broken. When a
> new update is created, the older one doesn't seem to be obsoleted or
> unpushed.

I'm not sure I understand what you mean. What do you mean with "Broken updates
that are actually broken"?
We did think about obsoleting updates when a newer one is created but decided
not to (if for some reasons -1's tests take longer than -2's, the outcome of
-1's tests run may still be of interest for the packager and yum/dnf will anyway
prefer the higher version).

Is the issue about updates lingering in -testing?


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

Re: Debates/back and forths

[Ankur Sinha]

On Wed, Aug 28, 2019 07:03:00 -0400, Danny Lee wrote:
> Hi all,

Hi Danny,

Open discussion is encouraged in the community and we try not to limit
the scope of these discussions. We always learn something new from each
other. Moderation is only used when the Code of Conduct
is not followed, which rarely happens:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

The -devel list is quite general and so receives higher traffic than
most other lists. Each specific team/SIG also has their own mailing
lists or communication channels. These will be more focussed:

https://lists.fedoraproject.org/archives/

Please simply delete topics that don't interest you. You can also use
the filter functionality that your e-mail provider includes to organise
incoming e-mails as you wish---filter on the basis of keywords and so
on.

Few threads will be relevant to all subscribers---there's always a lot
happening in Fedora and we are extremely diverse (which is how we like
it). :)

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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: Debates/back and forths

[Ernestas Kulik]

On Wed, 2019-08-28 at 07:03 -0400, Danny Lee wrote:
> Hi all,
> 
> I'm new to the devel list and fedora in general, but i was wondering
> if 
> these kind of back and forths between a few people is a frequent 
> occurrence.  I came to Fedora to volunteer what little spare time I
> have 
> to help the Fedora project in some little ways. I don't feel that
> should 
> include wading through dozens of emailed back and forths between 
> individuals who seem to have strong, immovable opinions, I just
> don't 
> have time for that.
> 
> Is there any chance there is a moderated list or discussion group
> about 
> current project tasks and issues rather than debates about how to do 
> things?  Or perhaps, a way to turn off certain threads or block
> certain 
> posters?

Aren’t those just the kinds of discussions you are referring to? You
can also filter things as your email provider allows.

-- 
Ernestas Kulik
Associate Software Engineer - Base Operating Systems (Core
Services/ABRT)
Red Hat Czech, s.r.o.
___
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-20190828.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
9 of 45 required tests failed, 6 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default
MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default

Failed openQA tests: 29/152 (x86_64), 1/2 (arm)

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

ID: 437297  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/437297
ID: 437298  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/437298
ID: 437301  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/437301
ID: 437302  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/437302
ID: 437303  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/437303
ID: 437304  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/437304
ID: 437305  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/437305
ID: 437312  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/437312

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

ID: 437280  Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/437280
ID: 437281  Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/437281
ID: 437314  Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/437314
ID: 437315  Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/437315
ID: 437316  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/437316
ID: 437318  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/437318
ID: 437347  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/437347
ID: 437349  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/437349
ID: 437351  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/437351
ID: 437409  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/437409
ID: 437411  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/437411
ID: 437412  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/437412
ID: 437414  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/437414
ID: 437415  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/437415
ID: 437416  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/437416
ID: 437418  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/437418
ID: 437419  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/437419
ID: 437420  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/437420
ID: 437423  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/437423
ID: 437424  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/437424
ID: 437425  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/437425
ID: 437430  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/437430

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

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

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

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

ID: 437413  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/437413

Passed openQA tests: 101/152 (x86_64)

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

ID: 437282  Test: x86_64 Server-dvd-iso install_default_upload
URL: 

Fedora rawhide compose report: 20190828.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20190827.n.0
NEW: Fedora-Rawhide-20190828.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  7
Dropped packages:3
Upgraded packages:   116
Downgraded packages: 0

Size of added packages:  2.39 MiB
Size of dropped packages:5.19 MiB
Size of upgraded packages:   3.68 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-Rawhide-20190828.n.0.aarch64.raw.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: gnome-feeds-0.7-1.fc32
Summary: RSS/Atom feed reader for GNOME
RPMs:gnome-feeds
Size:103.02 KiB

Package: golang-github-git-lfs-ntlm-0-0.1.20190827gitc5056e7.fc32
Summary: NTLM Implementation for Go
RPMs:golang-github-git-lfs-ntlm-devel
Size:39.82 KiB

Package: mingw-portablexdr-4.9.1-21.fc32
Summary: MinGW Windows PortableXDR / RPC Library
RPMs:mingw32-portablexdr mingw32-portablexdr-static mingw64-portablexdr 
mingw64-portablexdr-static
Size:129.24 KiB

Package: mp3gain-1.6.2-2.fc32
Summary: Lossless MP3 volume adjustment tool
RPMs:mp3gain
Size:344.34 KiB

Package: python-listparser-0.18-3.fc32
Summary: Parse OPML, FOAF, and iGoogle subscription lists
RPMs:python-listparser-doc python3-listparser
Size:208.60 KiB

Package: solaar-1.0.1-1.fc32
Summary: Device manager for a wide range of Logitech devices
RPMs:solaar solaar-doc solaar-udev
Size:1.18 MiB

Package: waypipe-0.6.0-1.fc32
Summary: Wayland forwarding proxy
RPMs:waypipe
Size:411.38 KiB


= DROPPED PACKAGES =
Package: cloudtoserver-0.2-10.fc31
Summary: Tool to convert Fedora Cloud instance to Fedora Server instance
RPMs:cloudtoserver
Size:22.76 KiB

Package: cycle-0.3.1-31.fc31
Summary: Calendar program for women
RPMs:cycle
Size:57.31 KiB

Package: uniconvertor-2.0-0.19.svn362.fc31
Summary: Universal vector graphics translator
RPMs:uniconvertor
Size:5.12 MiB


= UPGRADED PACKAGES =
Package:  R-V8-2.3-1.fc32
Old package:  R-V8-2.2-3.fc31
Summary:  Embedded JavaScript Engine for R
RPMs: R-V8
Size: 1.79 MiB
Size change:  1.82 KiB
Changelog:
  * Mon Aug 26 2019 Elliott Sales de Andrade  - 2.3-1
  - Update to latest version


Package:  R-chron-2.3.54-1.fc32
Old package:  R-chron-2.3.53-4.fc31
Summary:  Chronological Objects which can Handle Dates and Times
RPMs: R-chron
Size: 1.20 MiB
Size change:  4.33 KiB
Changelog:
  * Mon Aug 26 2019 Elliott Sales de Andrade  - 
2.3.54-1
  - Update to latest version


Package:  R-pkgbuild-1.0.5-1.fc32
Old package:  R-pkgbuild-1.0.4-1.fc32
Summary:  Find Tools Needed to Build R Packages
RPMs: R-pkgbuild
Size: 137.39 KiB
Size change:  1.11 KiB
Changelog:
  * Mon Aug 26 2019 Elliott Sales de Andrade  - 
1.0.5-1
  - Update to latest version


Package:  R-progress-1.2.2-1.fc32
Old package:  R-progress-1.2.1-3.fc31
Summary:  Terminal Progress Bars
RPMs: R-progress R-progress-devel
Size: 94.15 KiB
Size change:  1.15 KiB
Changelog:
  * Mon Aug 26 2019 Elliott Sales de Andrade  - 
1.2.2-1
  - Update to latest version


Package:  R-sys-3.3-1.fc32
Old package:  R-sys-2.1-3.fc31
Summary:  Powerful and Reliable Tools for Running System Commands in R
RPMs: R-sys
Size: 323.22 KiB
Size change:  -94.39 KiB
Changelog:
  * Mon Aug 26 2019 Elliott Sales de Andrade  - 3.3-1
  - Update to latest version


Package:  R-tinytest-1.0.0-1.fc32
Old package:  R-tinytest-0.9.4-3.fc31
Summary:  Lightweight and Feature Complete Unit Testing Framework
RPMs: R-tinytest
Size: 474.56 KiB
Size change:  199.81 KiB
Changelog:
  * Mon Aug 26 2019 Elliott Sales de Andrade  - 
1.0.0-1
  - Update to latest version


Package:  R-usethis-1.5.1-1.fc32
Old package:  R-usethis-1.5.0-3.fc31
Summary:  Automate Package and Project Setup
RPMs: R-usethis
Size: 932.66 KiB
Size change:  234.80 KiB
Changelog:
  * Mon Aug 26 2019 Elliott Sales de Andrade  - 
1.5.1-1
  - Update to latest version


Package:  bind-32:9.11.10-1.fc32
Old package:  bind-32:9.11.9-4.fc32
Summary:  The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) 
server
RPMs: bind bind-chroot bind-devel bind-dlz-bdb bind-dlz-filesystem 
bind-dlz-ldap bind-dlz-mysql bind-dlz-mysqldyn bind-dlz-sqlite3 
bind-dnssec-utils bind-libs bind-libs-lite bind-license bind-lite-devel 
bind-pkcs11 bind-pkcs11-devel bind-pkcs11-libs bind-pkcs11-utils bind-sdb 
bind-sdb-chroot bind-utils python3-bind
Size: 35.68 MiB
Size change:  77.06 KiB
Changelog:
  * Tue Aug 27 2019 Petr Menk  - 32:9.11.10-1
  - Update to 9.11.10


Package:  bind-dyndb-ldap-11.1-20.fc32
Old package:  bind-dyndb-ldap-11.1-19.fc32
Summary:  LDAP back-end plug-in for BIND
RPMs: bind-dyndb-ldap

Re: New release of Mock (fixes and subscription-manager support)

[Nico Kadel-Garcia]

On Wed, Aug 28, 2019 at 5:54 AM Pavel Raiskup  wrote:
>
> On Wednesday, August 28, 2019 4:06:32 AM CEST Nico Kadel-Garcia wrote:
> > i will point out, from experience with subscription manager, that
> > downloading RPM's from subscription-manager is unacceptably slow
> > inmost build environments. You *will* want to use CentOS 8, or arrange
> > a subscription to build a local mirror with "reposync", for anything
> > like dynamic biulding of RHEL 8 based RPM's. But if it works, it saves
> > me a bunch of work in the short term.
>
> I haven't experienced some unreasonably slow downloads, and my dnf/yum
> caches work fine say by default with mock.
>
> There might be some issue, or some misconfiguration.  Take a look at
> mock's config option config_opts['plugin_conf']['yum_cache_opts']['dir'],
> and consider not --scrub'ing the caches for every build.
>
> Pavel

The problem dates back decades, certainly since RHEL was introduced.
Testing last week with my registered RHEL 8 host, CentOS mirrors wer
at least twice as fast , rather than pulling directly from Red Hat
repositories, unless the company has a local Red Hat Network setup, or
I activate and use a local mirror with reposync. And reposync is far
less than half the speed of an "rsync" against a CentOS mirror. Some
old tools of mine for just such purposes are available at
thttps://github.com/nkadel/nkadel-rsync-scripts. It's not usually that
big a deal when you're updating only a few packages, but when you're
running "mock" you can wind up pulling from the same repos *a lot*, a
local mirror really improves performance. It also reduces duplicated
bandwidth from your local mirrors if you use it for Fedora, CentOS,
and EPEL as well, which can save everyone resources.

Unless you're worried about phase lag between your local mirror and
the upstream repos, which I admit could happen with rawhide, I use it
for all my "mock" builds. That includes builds of "mock" itself, in
particular, whcn I've needed bleeding edge featues for older operating
systems.
___
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