[389-devel] 389 DS nightly 2020-09-05 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/09/05/report-389-ds-base-1.4.4.4-20200904gite8f0692.fc32.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

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

[John M. Harris Jr]

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

That's an interesting choice. Isn't it a bit of a waste to put all of the 
resources into Pagure for so long, only to jump over to GitLab?

-- 
John M. Harris, Jr.

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

Re: fedbot spamming in #fedora

[Germano Massullo]

Il 19/07/20 19:41, Kevin Fenzi ha scritto:
> On Fri, Jul 17, 2020 at 05:34:13PM +0200, Germano Massullo wrote:
>> Is it necessary to have in #fedora IRC channel, fedbot spamming 48 times
>> per day about Fedora respins update?
>>
>> [16:51]  *** F32-20200715 updated lives available:
>> https://tinyurl.com/Live-respins2 Built by the Fedora Respin Sig more
>> info #fedora-respins ***
> Copying jbwilla on this for comment.
>
> kevin
Any news?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F32 ppc64le build failure: ImportError: /lib64/libgomp.so.1: cannot allocate memory in static TLS block

[Elliott Sales de Andrade]

On Fri, 4 Sep 2020 at 18:03, Ankur Sinha  wrote:
>
> Hello folks,
>
> I'm seeing this error that causes a test failure on F32 for a noarch
> python package. It builds in mock on my x86_64 here, but on koji it gets
> a ppc64le builder and fails with this error. It's built fine on F33 and
> rawhide. Would anyone know what may be causing this?
>

I'm pretty sure this is this wx+NumPy+Pillow bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=1738752

which as you say is fixed on Fedora 33.

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

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

Re: F32 ppc64le build failure: ImportError: /lib64/libgomp.so.1: cannot allocate memory in static TLS block

[Jerry James]

On Fri, Sep 4, 2020 at 4:03 PM Ankur Sinha  wrote:
> I'm seeing this error that causes a test failure on F32 for a noarch
> python package. It builds in mock on my x86_64 here, but on koji it gets
> a ppc64le builder and fails with this error. It's built fine on F33 and
> rawhide. Would anyone know what may be causing this?

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91938, particularly
comment 4.  As a workaround, try adding this to your %check script:

export LD_PRELOAD=%{_libdir}/libgomp.so.1

It sure would be nice if the gcc and glibc developers would put their
heads together and figure out how to make this go away permanently.
-- 
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

[EPEL-devel] EPEL-6 is End of Life in 2020-11

[Troy Dawson]

EPEL 6 is End Of Life (EOL) on November 2020.
EPEL 6 will be moved to archives in December 2020.

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

[EPEL-devel] Re: Continuing playground discussion

[Troy Dawson]

On Fri, Sep 4, 2020 at 7:18 AM Troy Dawson  wrote:
> Step 1 - Approve plan via Steering Committee.
> Step 1a - Documents and communication
> -- No releng needed.
> -- Should be done along the whole way
> Step 2 - Update fedpkg and remove all package.cfg from epel8.
> -- Can be done by a proven packagers, no releng needed.
> Step 3 - Change the inheritance in koji so it inherits from epel8
> -- releng work
> --- I don't know how easy / hard this will be for releng
> Step 4 - Untag all the things that are "older" in playground
> -- currently that is a releng process.  There is no way for a
> maintainer to retire their package from playground.
> -- This needs to happen some time (3 months?) after step 2 is
> finished.  A time that we can see that people have manually built
> their package in playground, versus the automatic builds.  So that the
> "older" packages are obvious.
> -- If we do this as a huge batch, it should be a fairly simple (though
> long) step for releng.
> Step 5 - Send a daily report
> -- Is this similar to what we send for EPEL6,7,8 ?
> --- If this is true, I'm in favor of it.  If not, then please explain more.
> -- I have no idea about the work involved for this.
>

This plan has been approved by the Fedora Steering Committee.
Thus Step 1 has been accomplished.
  Ya!!!
We will start steps 1a and 2 next week.
Step 4 - We will determine what "older" means, but right now I think
Paul has the right idea that anything with the same NVR is both epel8
and epel8-playground is considered "older", or non-automated.

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

F32 ppc64le build failure: ImportError: /lib64/libgomp.so.1: cannot allocate memory in static TLS block

[Ankur Sinha]

Hello folks,

I'm seeing this error that causes a test failure on F32 for a noarch
python package. It builds in mock on my x86_64 here, but on koji it gets
a ppc64le builder and fails with this error. It's built fine on F33 and
rawhide. Would anyone know what may be causing this?

This is the build URL:
https://koji.fedoraproject.org/koji/taskinfo?taskID=50777398

This is the failure:


=== FAILURES ===
_ test_bitmap __
@pytest.mark.piltest
def test_bitmap():
>
>   from PIL import Image
tests/test_bitmap.py:19:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
import atexit
import builtins
import io
import logging
import math
import numbers
import os
import struct
import sys
import tempfile
import warnings
from collections.abc import Callable, MutableMapping
from pathlib import Path
>
# VERSION was removed in Pillow 6.0.0.
# PILLOW_VERSION was removed in Pillow 7.0.0.
# Use __version__ instead.
from . import ImageMode, TiffTags, UnidentifiedImageError, __version__, 
_plugins
from ._binary import i8, i32le
from ._util import deferred_error, isPath
>
logger = logging.getLogger(__name__)
>
>
class DecompressionBombWarning(RuntimeWarning):
pass
>
>
class DecompressionBombError(Exception):
pass
>
>
# Limit to around a quarter gigabyte for a 24 bit (3 bpp) image
MAX_IMAGE_PIXELS = int(1024 * 1024 * 1024 // 4 // 3)
>
>
try:
# If the _imaging C module is not present, Pillow will not load.
# Note that other modules should not refer to _imaging directly;
# import Image and use the Image.core variable instead.
# Also note that Image.core is not a publicly documented interface,
# and should be considered private and subject to change.
>   from . import _imaging as core
E   ImportError: /lib64/libgomp.so.1: cannot allocate memory in static TLS 
block
/usr/lib64/python3.8/site-packages/PIL/Image.py:69: ImportError
_ test_bitmap_asImage __
@pytest.mark.piltest
def test_bitmap_asImage():
>   from PIL import Image
tests/test_bitmap.py:49:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
import atexit
import builtins
import io
import logging
import math
import numbers
import os
import struct
import sys
import tempfile
import warnings
from collections.abc import Callable, MutableMapping
from pathlib import Path
>
# VERSION was removed in Pillow 6.0.0.
# PILLOW_VERSION was removed in Pillow 7.0.0.
# Use __version__ instead.
from . import ImageMode, TiffTags, UnidentifiedImageError, __version__, 
_plugins
from ._binary import i8, i32le
from ._util import deferred_error, isPath
>
logger = logging.getLogger(__name__)
>
>
class DecompressionBombWarning(RuntimeWarning):
pass
>
>
class DecompressionBombError(Exception):
pass
>
>
# Limit to around a quarter gigabyte for a 24 bit (3 bpp) image
MAX_IMAGE_PIXELS = int(1024 * 1024 * 1024 // 4 // 3)
>
>
try:
# If the _imaging C module is not present, Pillow will not load.
# Note that other modules should not refer to _imaging directly;
# import Image and use the Image.core variable instead.
# Also note that Image.core is not a publicly documented interface,
# and should be considered private and subject to change.
>   from . import _imaging as core
E   ImportError: /lib64/libgomp.so.1: cannot allocate memory in static TLS 
block
/usr/lib64/python3.8/site-packages/PIL/Image.py:69: ImportError

-- 
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: Fedora 33 blocker status

[Ben Cotton]

The Go/No-Go meeting is Thursday!

Action summary


Accepted blockers
-
1. libreport — abrt-server errors when processing zstd compressed core
dumps produced by systemd-246~rc1-1.fc33 — POST
ACTION: msuchy to get retrace server back in service

2. sddm — login stuck when changing users repeatedly (log out, log in
a different one) — NEW
ACTION: sddm maintainers to diagnose issue and fix or pass the buck as
appropriate
NEEDINFO: mbriza, rdieter

3. distribution — Everything boot x86_64 image exceeds maximum size — ASSIGNED
ACTION: none. Fixing Server boot should fix this, too

4. distribution — Server boot x86_64 image exceeds maximum size — NEW
ACTION: Server WG to determine whether or not to remove packages or
increase size limit.

5. distribution — Release-blocking Fedora 33 images have Fedora 32
backgrounds — NEW
ACTION: kde-settings maintainers to update package to use new
backgrounds (BZ 1872054)

6. pki-core — FreeIPA server upgrade from Fedora 32 or Fedora 31 fails
with java.lang.UnsupportedClassVersionError —  ASSIGNED
ACTION: pki-core maintainers to package an update which includes the upstream PR

7. libpreport — bugs can't be reported: "No matching actions found for
this event" — NEW
ACTION: abrt maintainers to diagnose and fix issue

8. NetworkManager-openconnect — systemd-resolved.service not work with
DNS server placed behind VPN (openconnect) — ASSIGNED
ACTION: NetworkManager-openconnect maintainers to add integration for
systemd-resolved.

9. anaconda — Booting Server DVD then selecting a mirrorlist
repository does not work — MODIFIED
ACTION: anaconda maintainers to package anaconda-33.25.3 update

10. kernel — 5.8.3-300.fc33.aarch64 kernel panic on boot (X-Gene PMU) — VERIFIED
ACTION: none!

Proposed blockers
-

1. gnome-initial-setup — g-i-s fails to completely launch following
clean install, opens in a tiny non-resizeable window instead — NEW
ACTION: QA to test on bare metal to see if scope is limited to VMs
while upstream hopefully gets us a fix

2. kernel — dasbus.error.DBusError: cannot initialize a disk that has
partitions — NEW
ACTION: kernel maintainers to diagnose issue, QA to try to find a
reliable reproducer

Bug-by-bug detail
=

Accepted blockers
-
1. libreport — https://bugzilla.redhat.com/show_bug.cgi?id=1860616 — POST
abrt-server errors when processing zstd compressed core dumps produced
by systemd-246~rc1-1.fc33

FEDORA-2020-59e144acee contains a potential fix, but appears to
introduce a new blocker (BZ 1873029). It may be moot until the retrace
server is brought back online. The infra team has provisioned a basic
instance, which msuchy is working to get ready for use.

2. sddm — https://bugzilla.redhat.com/show_bug.cgi?id=1861700 — NEW
login stuck when changing users repeatedly (log out, log in a different one)

User processes linger after logout which blocks logging in when
another user has logged in between the two sessions. Or when the
second user logs back in. Or when a single user logs in repeatedly.
Using KillUserProcesses=Yes helps the first problem, but raises on of
its own. It appears to be a race condition of some kind as the
behavior is not fully consistent.

3. distribtution — https://bugzilla.redhat.com/show_bug.cgi?id=1849430
— ASSIGNED
Everything boot x86_64 image exceeds maximum size

Latest compose does not significantly shrink the image size. Given the
similar nature of the overages, I believe fixing the Server image
size, which sgallagh is working on, will fix this as well.

4. distribtution — https://bugzilla.redhat.com/show_bug.cgi?id=1849431
— ASSIGNED
Server boot x86_64 image exceeds maximum size

We need to slim it down by ~14 MB.

5. distribution — https://bugzilla.redhat.com/show_bug.cgi?id=1869892 — ASSIGNED
Release-blocking Fedora 33 images have Fedora 32 backgrounds

Backgrounds package has been created, but KDE Plasma needs to be
explicitly updated to use it. BZ 1872054 open for this.

6. pki-core — https://bugzilla.redhat.com/show_bug.cgi?id=1871990 — ASSIGNED
FreeIPA server upgrade from Fedora 32 or Fedora 31 fails with
java.lang.UnsupportedClassVersionError

/etc/sysconfig/tomcat.conf needs to be changed to point to JDK 11 on
upgrade. Upstream PR contains a potential fix:
https://github.com/dogtagpki/pki/pull/532

7. libreport — https://bugzilla.redhat.com/show_bug.cgi?id=1873029 — NEW
bugs can't be reported: "No matching actions found for this event"

No crashes can be reported. abrt shows "no matching event" error
message. This appears to be introduced by the fix for 1860616.

8. NetworkManager-openconnect —
https://bugzilla.redhat.com/show_bug.cgi?id=1863041 — NEW
systemd-resolved.service not work with DNS server placed behind VPN
(openconnect)

When connected to an OpenConnect VPN, host name resolution fails.
Openconnect needs to push server information to systemd-resolved.
Upstream vpnc-script added support for systemd-resolved in 2016, so
it's not clear 

[EPEL-devel] Seeking maintainer for perl-Sys-SigAction

[Mike Ely]

Unfortunately this package has fallen behind a few versions in EPEL7 and is 
absent in EPEL8. BZ 1807857 has been open since February requesting the package 
for EPEL8 and it appears nobody has taken this up. I'm not in a position to be 
able to maintain this package outside work hours for family reasons, so I'm 
here to ask if anyone in this community would be willing to pick this up. 
Thanks!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[Bug 1807857] please build perl-Sys-SigAction on EPEL8

[bugzilla]

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

Mike Ely  changed:

   What|Removed |Added

 CC||mike@sonic.com



--- Comment #2 from Mike Ely  ---
Please?


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

Claiming ownership of retired package: bygfoot

[Tom Stellard]

Hi,

I would like to claim ownership of the retired package bygfoot.  Since it has 
been retired for more than 8 weeks, I've submitted a new review request here: 
https://bugzilla.redhat.com/show_bug.cgi?id=1875972.

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

Fedora-IoT-34-20200904.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

Failed openQA tests: 2/16 (x86_64)

Old failures (same test failed in Fedora-IoT-34-20200903.0):

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

Passed openQA tests: 14/16 (x86_64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.29 to 0.16
Previous test data: https://openqa.fedoraproject.org/tests/654505#downloads
Current test data: https://openqa.fedoraproject.org/tests/655570#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Release criteria proposal: first boot experience

[Adam Williamson]

On Fri, 2020-09-04 at 11:16 -0700, Adam Williamson wrote:
> On Fri, 2020-09-04 at 12:12 -0500, Michael Catanzaro wrote:
> > On Wed, Sep 2, 2020 at 12:57 pm, Kamil Paral  wrote:
> > > Overall I find the criterion reasonable and useful and I'm +1 to 
> > > incorporating it. Its current phrasing seems fine to me.
> > 
> > So how does the process of adding the new criterion work? I guess we 
> > should leave the weekend for additional comment, in case anybody wants 
> > to suggest improvements, but it'd be nice to get this incorporated into 
> > the release criteria and repropose the gnome-initial-setup bug.
> 
> To be honest it's something we've never had the roundtuits to write up
> in a nice clean policy. The convention is basically: once a draft has
> been up for a while (say, a week or two, depending on urgency) without
> significant objections, you just go ahead and add it to the wiki. i.e.
> it's a fuzzy consensus system. :)

Oh, sorry, bit more detail - you should also send a mailing list reply
to say "I reckon this is ready to go and no-one objected, so I'm adding
it to the wiki now", and have the wiki edit message link to the mailing
list thread. Just so things can easily be tracked back. If it's not too
much trouble, please also add a "References" footnote to the criterion
following the pattern used by other criteria - at least linking to the
mailing list discussion with some dates, and with a "Test case:" entry,
which can point to
https://fedoraproject.org/wiki/QA:Testcase_base_initial_setup , as that
does actually already say "Other functions of the initial setup utility
should complete without errors, crashes or freezes, and should achieve
the results they claim".

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

[EPEL-devel] Re: Continuing playground discussion

[Troy Dawson]

On Fri, Sep 4, 2020 at 11:18 AM Paul Howarth  wrote:
>
> On Fri, 4 Sep 2020 07:18:31 -0700
> Troy Dawson  wrote:
> > Step 4 - Untag all the things that are "older" in playground
> > -- currently that is a releng process.  There is no way for a
> > maintainer to retire their package from playground.
> > -- This needs to happen some time (3 months?) after step 2 is
> > finished.  A time that we can see that people have manually built
> > their package in playground, versus the automatic builds.  So that the
> > "older" packages are obvious.
>
> Isn't it likely that builds with the same NEVR (apart from the
> disttag) in playground as in EPEL-8 proper are automatic builds rather
> than manual ones?
>
> That would certainly reflect my own usage, where almost all of my
> packages would be the same, but my manual build of proftpd is different.
>

Good point.
Check and see if they have the same NVR, except el8 is epel8.playground.
I like that better.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Continuing playground discussion

[Paul Howarth]

On Fri, 4 Sep 2020 07:18:31 -0700
Troy Dawson  wrote:
> Step 4 - Untag all the things that are "older" in playground
> -- currently that is a releng process.  There is no way for a
> maintainer to retire their package from playground.
> -- This needs to happen some time (3 months?) after step 2 is
> finished.  A time that we can see that people have manually built
> their package in playground, versus the automatic builds.  So that the
> "older" packages are obvious.

Isn't it likely that builds with the same NEVR (apart from the
disttag) in playground as in EPEL-8 proper are automatic builds rather
than manual ones?

That would certainly reflect my own usage, where almost all of my
packages would be the same, but my manual build of proftpd is different.

Paul.
___
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: Release criteria proposal: first boot experience

[Adam Williamson]

On Fri, 2020-09-04 at 12:12 -0500, Michael Catanzaro wrote:
> On Wed, Sep 2, 2020 at 12:57 pm, Kamil Paral  wrote:
> > Overall I find the criterion reasonable and useful and I'm +1 to 
> > incorporating it. Its current phrasing seems fine to me.
> 
> So how does the process of adding the new criterion work? I guess we 
> should leave the weekend for additional comment, in case anybody wants 
> to suggest improvements, but it'd be nice to get this incorporated into 
> the release criteria and repropose the gnome-initial-setup bug.

To be honest it's something we've never had the roundtuits to write up
in a nice clean policy. The convention is basically: once a draft has
been up for a while (say, a week or two, depending on urgency) without
significant objections, you just go ahead and add it to the wiki. i.e.
it's a fuzzy consensus system. :)

I do keep meaning to write it up a bit more formally, but never get
enough round tuits...
-- 
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: Non-responsive maintainer: tmoertel

[Robbie Harwood]

Thomas Moertel  writes:

> Hi Robbie,
>
> I'm sorry to say that I can no longer maintain emacs-magit. Please
> remove me as a maintainer.

Appreciate the response, and your past work!

Thanks,
--Robbie


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

Re: Release criteria proposal: first boot experience

[Michael Catanzaro]

On Wed, Sep 2, 2020 at 12:57 pm, Kamil Paral  wrote:
Overall I find the criterion reasonable and useful and I'm +1 to 
incorporating it. Its current phrasing seems fine to me.


So how does the process of adding the new criterion work? I guess we 
should leave the weekend for additional comment, in case anybody wants 
to suggest improvements, but it'd be nice to get this incorporated into 
the release criteria and repropose the gnome-initial-setup bug.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1875908] New: perl-Class-Tiny-1.008 is available

[bugzilla]

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

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



Latest upstream release: 1.008
Current version/release in rawhide: 1.006-14.fc33
URL: http://search.cpan.org/dist/Class-Tiny/

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


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


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


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


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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 751  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
 491  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b   
bubblewrap-0.3.3-2.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-89ad58d02c   
golang-1.15-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-49c5f31e92   
python-pip-epel-8.1.2-14.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-864bc6779e   
chromium-85.0.4183.83-1.el7


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

libudfread-1.1.0-2.el7
xl2tpd-1.3.15-1.el7

Details about builds:



 libudfread-1.1.0-2.el7 (FEDORA-EPEL-2020-930f4b4e58)
 UDF reader library

Update Information:

Initial Fedora package.

ChangeLog:


References:

  [ 1 ] Bug #1875315 - Review Request: libudfread - UDF reader library
https://bugzilla.redhat.com/show_bug.cgi?id=1875315




 xl2tpd-1.3.15-1.el7 (FEDORA-EPEL-2020-c53d91e9fe)
 Layer 2 Tunnelling Protocol Daemon (RFC 2661)

Update Information:

Resolves: rhbz#1761700 xl2tpd-1.3.15 is available

ChangeLog:

* Thu Sep  3 2020 Paul Wouters  - 1.3.15-1
- Resolves: rhbz#1761700 xl2tpd-1.3.15 is available
- Resolves: rhbz#1875262 Unsupported options 'crtscts' and 'lock' in 
/etc/ppp/options.xl2tpd
- Resolves: rhbz#1869420 xl2tpd.service:8: PIDFile= references a path below 
legacy directory /var/run/

References:

  [ 1 ] Bug #1761700 - xl2tpd-1.3.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1761700
  [ 2 ] Bug #1869420 - /usr/lib/systemd/system/xl2tpd.service:8: PIDFile= 
references a path below legacy directory /var/run/
https://bugzilla.redhat.com/show_bug.cgi?id=1869420
  [ 3 ] Bug #1875262 - Unsupported options 'crtscts' and 'lock' in 
/etc/ppp/options.xl2tpd
https://bugzilla.redhat.com/show_bug.cgi?id=1875262


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

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  23  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c2936180ed   
ansible-2.9.12-1.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-96c4037065   
ark-19.12.2-3.el8
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2390c71f9c   
chromium-85.0.4183.83-1.el8


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

dnsperf-2.3.4-3.el8
getdns-1.6.0-3.el8
libudfread-1.1.0-2.el8
python-aiosmb-0.2.26-1.el8
python-coronavirus-1.1.1-1.el8
python-cssselect2-0.3.0-6.el8
python-discord-1.4.1-1.el8
python-tinycss2-1.0.2-8.el8
stress-ng-0.11.19-1.el8
stubby-0.3.1-0.5.20200318git7939e965.el8
xl2tpd-1.3.15-1.el8

Details about builds:



 dnsperf-2.3.4-3.el8 (FEDORA-EPEL-2020-be423b974a)
 Benchmarking authorative and recursing DNS servers

Update Information:

New build for EPEL8, dnsperf and resperf tools. They measure performance of
domain name servers (DNS), both authoritative and recursive.

ChangeLog:





 getdns-1.6.0-3.el8 (FEDORA-EPEL-2020-537cfb7d8f)
 Modern asynchronous API to the DNS

Update Information:

Getdns and stubby build for EPEL8.

ChangeLog:


References:

  [ 1 ] Bug #1785721 - getdns-1.6.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1785721
  [ 2 ] Bug #1874285 - Please build an EPEL 8 build for getdns and getdns-stubby
https://bugzilla.redhat.com/show_bug.cgi?id=1874285




 libudfread-1.1.0-2.el8 (FEDORA-EPEL-2020-201dd37f38)
 UDF reader library

Update Information:

Initial Fedora package.

ChangeLog:


References:

  [ 1 ] Bug #1875315 - Review Request: libudfread - UDF reader library
https://bugzilla.redhat.com/show_bug.cgi?id=1875315




 python-aiosmb-0.2.26-1.el8 (FEDORA-EPEL-2020-752beb67f6)
 Asynchronous SMB protocol implementation

Update Information:

Update to latest upstream release 0.2.26

ChangeLog:





 python-coronavirus-1.1.1-1.el8 (FEDORA-EPEL-2020-e4f591495b)
 Python client for getting Corona virus info

Update Information:

Initial package for Fedora

ChangeLog:





 python-cssselect2-0.3.0-6.el8 (FEDORA-EPEL-2020-7009b5495b)
 CSS selectors for Python ElementTree

Update Information:

Build for EPEL8

ChangeLog:


References:

  [ 1 ] Bug #1874665 - Please build python-tinycss2 for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1874665
  [ 2 ] Bug #1874669 - Please build python-cssselect2 for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1874669




 python-discord-1.4.1-1.el8 (FEDORA-EPEL-2020-1bf142dd2a)
 Python wrapper for the Discord API

Update Information:

Initial 

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

[Aoife Moloney]

Good Morning folks,

As you likely remember, a little while ago now, was announced the decision to
move dist-git to a gitlab instance. This decision was the results of different
factors which included a wish for Red Hat to have a consistent tooling and
experience across the different distribution it works on or with, meaning:
RHEL, CentOS-Stream, CentOS Linux and Fedora.

Since then, a number of technical requirements needed to use gitlab in Fedora,
were gathered and a ticket was opened at gitlab to track them [1] but up until
now the progress on the Fedora side has been fairly slow. This is mostly due to
the feedback from Fedora that followed this decision, leading to a focus on the
first two distributions in the list above.

However, in order to progress the evaluation of gitlab, we have organized an
"Ask Me Anything" (AMA) session with the gitlab folks on Thursday September 10th
2020, at 13:30 UTC on #fedora-meeting-1 on irc.freenode.net.
The idea is to have an open floor for anyone in the community to discuss with
GitLab the technical merits that GitLab has, as well as the requirements we, the
Fedora community, have.

In order for this session to be productive, we believe that it may be wise to
start gathering questions to GitLab early on, so they can also look into them
and prepare their answers (I'm sure we all prefer to have actual answers rather
than: "hm, I don't know, let me check and I'll get back to you on this"). Of
course, we will still be able to ask question at the last minute or even during
the session.
Gathering them as early as possible is just a way for GitLab to see what
interests us, who may be the right persons to attend this session and overall to
make this hour as productive as possible.


So there are two ways for you to submit your questions to the GitLab folks on a
potential deployment of GitLab as a front-end to our dist-git (ie:
src.fedoraproject.org):

- A public hackmd document:
https://hackmd.io/RW8HahOeR7OJPON1dwuo3w#
Underneath each questions you will also be able to vote (simply add a ``+1`` to
the ``Votes:`` line), the most popular questions will be asked first.
Since this document is public, please be mindful of what previous
people entered.

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

The questions that we will not have time for, or cant be answered during the
session, will be answered afterward. The AMA minutes will be sent in the CPE
weekly mail, the hackmd will be updated and and summary published on
the community
blog.


Looking forward to the discussion,

Aoife


[1] https://gitlab.com/gitlab-org/gitlab/-/issues/217350


-- 
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
___
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

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

[Aoife Moloney]

Good Morning folks,

As you likely remember, a little while ago now, was announced the decision to
move dist-git to a gitlab instance. This decision was the results of different
factors which included a wish for Red Hat to have a consistent tooling and
experience across the different distribution it works on or with, meaning:
RHEL, CentOS-Stream, CentOS Linux and Fedora.

Since then, a number of technical requirements needed to use gitlab in Fedora,
were gathered and a ticket was opened at gitlab to track them [1] but up until
now the progress on the Fedora side has been fairly slow. This is mostly due to
the feedback from Fedora that followed this decision, leading to a focus on the
first two distributions in the list above.

However, in order to progress the evaluation of gitlab, we have organized an
"Ask Me Anything" (AMA) session with the gitlab folks on Thursday September 10th
2020, at 13:30 UTC on #fedora-meeting-1 on irc.freenode.net.
The idea is to have an open floor for anyone in the community to discuss with
GitLab the technical merits that GitLab has, as well as the requirements we, the
Fedora community, have.

In order for this session to be productive, we believe that it may be wise to
start gathering questions to GitLab early on, so they can also look into them
and prepare their answers (I'm sure we all prefer to have actual answers rather
than: "hm, I don't know, let me check and I'll get back to you on this"). Of
course, we will still be able to ask question at the last minute or even during
the session.
Gathering them as early as possible is just a way for GitLab to see what
interests us, who may be the right persons to attend this session and overall to
make this hour as productive as possible.


So there are two ways for you to submit your questions to the GitLab folks on a
potential deployment of GitLab as a front-end to our dist-git (ie:
src.fedoraproject.org):

- A public hackmd document:
https://hackmd.io/RW8HahOeR7OJPON1dwuo3w#
Underneath each questions you will also be able to vote (simply add a ``+1`` to
the ``Votes:`` line), the most popular questions will be asked first.
Since this document is public, please be mindful of what previous
people entered.

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

The questions that we will not have time for, or cant be answered during the
session, will be answered afterward. The AMA minutes will be sent in the CPE
weekly mail, the hackmd will be updated and and summary published on
the community
blog.


Looking forward to the discussion,

Aoife


[1] https://gitlab.com/gitlab-org/gitlab/-/issues/217350


-- 
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
___
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

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

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 9/181 (x86_64)

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

ID: 655448  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/655448
ID: 655510  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/655510

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

ID: 655405  Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/655405
ID: 655407  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/655407
ID: 655436  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/655436
ID: 655441  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/655441
ID: 655462  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/655462
ID: 655484  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/655484
ID: 655503  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/655503

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

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

ID: 655332  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/655332
ID: 655351  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/655351
ID: 655378  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/655378
ID: 655391  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/655391
ID: 655411  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/655411
ID: 655414  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/655414
ID: 655428  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/655428
ID: 655440  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/655440
ID: 655465  Test: x86_64 universal upgrade_2_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/655465

Passed openQA tests: 163/181 (x86_64)

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

ID: 655330  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/655330
ID: 655331  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/655331
ID: 655372  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/655372
ID: 655373  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/655373
ID: 655431  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/655431
ID: 655435  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/655435
ID: 655464  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/655464
ID: 655472  Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/655472
ID: 655504  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/655504

Installed system changes in test x86_64 Server-boot-iso install_default: 
Mount / contents changed to 87.63588716% of previous size
1 services(s) removed since previous compose: getty@tty6.service
Previous test data: https://openqa.fedoraproject.org/tests/653725#downloads
Current test data: https://openqa.fedoraproject.org/tests/655330#downloads

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
Mount / contents changed to 89.08928315% of previous size
1 services(s) removed since previous compose: getty@tty6.service
Previous test data: https://openqa.fedoraproject.org/tests/653726#downloads
Current test data: https://openqa.fedoraproject.org/tests/655331#downloads

Installed system changes in test x86_64 Everything-boot-iso install_default: 
Mount / contents changed to 85.45238087% of previous size
Mount /home contents changed to 85.45238087% of previous size
2 packages(s) removed since previous compose: gpg-pubkey, tar
1 services(s) removed since previous compose: getty@tty6.service
Previous test data: https://openqa.fedoraproject.org/tests/653767#downloads
Current test data: https://openqa.fedoraproject.org/tests/655372#downloads

Installed system changes in test x86_64 Everything-boot-iso 
install_default@uefi: 
Mount / contents changed to 85.33294231% 

[EPEL-devel] Re: Continuing playground discussion

[Troy Dawson]

On Wed, Sep 2, 2020 at 2:08 PM Kevin Fenzi  wrote:
> I think playground might be fixable/made of use without too much work...
> * adjust fedpkg to stop requesting playground branches always/only
> request them on explicit ask
> * change the inheritence in koji so it inherits from epel8
> * untag all the things that are "older" in playground
> * add more docs about what it is and how it works
> * perhaps make it send a daily report for each compose
>

When you start listing the actual steps, I think you are correct.
Changing playground to do what we want, is only a little bit more work
than it would to drop it.

If you don't mind, I'd like to go through those steps in a little more
detail, and in order that they need to be done.

Step 1 - Approve plan via Steering Committee.
Step 1a - Documents and communication
-- No releng needed.
-- Should be done along the whole way
Step 2 - Update fedpkg and remove all package.cfg from epel8.
-- Can be done by a proven packagers, no releng needed.
Step 3 - Change the inheritance in koji so it inherits from epel8
-- releng work
--- I don't know how easy / hard this will be for releng
Step 4 - Untag all the things that are "older" in playground
-- currently that is a releng process.  There is no way for a
maintainer to retire their package from playground.
-- This needs to happen some time (3 months?) after step 2 is
finished.  A time that we can see that people have manually built
their package in playground, versus the automatic builds.  So that the
"older" packages are obvious.
-- If we do this as a huge batch, it should be a fairly simple (though
long) step for releng.
Step 5 - Send a daily report
-- Is this similar to what we send for EPEL6,7,8 ?
--- If this is true, I'm in favor of it.  If not, then please explain more.
-- I have no idea about the work involved for this.

I think Step 5 is a very important step (if I'm understanding it
correctly).  Because it will give us a good idea about how many people
are utilizing playground.

I think Step 3, changing the inheritance is the only change in the
work involved for releng.  We would be changing the inheritance,
instead of deleting it.  I don't know how much extra work that will
be.

I have specifically avoided the -next / Stream discussion.  Not that I
don't think it's important, but because of resources.  Let's get
playground fixed up if possible.  We'll take what we learn, look at
how much resources it took, look at how much it is used, and then make
a decision.

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

Next Open NeuroFedora Meeting: 1300 UTC on Monday, 7th September

[Ankur Sinha]

Hello everyone,

Please join us at the next Open NeuroFedora team meeting next week on
Monday at 1300UTC in #fedora-neuro on IRC (Freenode). The meeting is
a public meeting, and open for everyone to attend.

https://webchat.freenode.net/?channels=#fedora-neuro

The channel is bridged to Telegram, so you can also join us there on the
@NeuroFedora group:
https://t.me/NeuroFedora

You can convert the meeting time to your local time using this command
in a terminal:
$ date --date='TZ="UTC" 1300 next Mon'

or you can use this link:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=NeuroFedora+Meeting=20200907T13=1440=1

The meeting will be chaired by @ankursinha. The agenda for the meeting
is:

- New introductions and roll call.
- Tasks from last week's meeting (nothing here this time)
- Open Pagure tickets:
  
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
- CompNeuro lab compose status check.
- Neuroscience query of the week.
- Next meeting day, and chair.
- Open floor.

We hope to see you there!

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

Fedora 33 compose report: 20200904.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-33-20200903.n.0
NEW: Fedora-33-20200904.n.0

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

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

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

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

[Bug 1875827] New: perl-Crypt-SMIME-0.26-1.fc34 FTBFS: t/dependencies.t fails: "my" variable $v masks earlier declaration in same scope at /usr/share/perl5/vendor_perl/Test/Dependencies.pm line 316.

[bugzilla]

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

Bug ID: 1875827
   Summary: perl-Crypt-SMIME-0.26-1.fc34 FTBFS: t/dependencies.t
fails: "my" variable $v masks earlier declaration in
same scope at
/usr/share/perl5/vendor_perl/Test/Dependencies.pm line
316.
   Product: Fedora
   Version: rawhide
   URL: https://koschei.fedoraproject.org/package/perl-Crypt-S
MIME?collection=f34
Status: NEW
 Component: perl-Crypt-SMIME
  Assignee: steve.tray...@cern.ch
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
steve.tray...@cern.ch, xav...@bachelot.org
Blocks: 1868278 (F34FTBFS)
  Target Milestone: ---
Classification: Fedora



perl-Crypt-SMIME-0.26-1.fc34 fails to build in Fedora 34 because a test fails:

$ perl -Ilib t/dependencies.t
"my" variable $v masks earlier declaration in same scope at
/usr/share/perl5/vendor_perl/Test/Dependencies.pm line 316.
ok 1 - META.json is present and readable
ok 2 - Required module 'XSLoader' in core (since v5.6.0) after minimum perl
v5.0.0
ok 3 - Required module 'ExtUtils::Constant'(0.23) in core (since v5.13.7) after
minimum perl v5.0.0
ok 4 - Required module 'Test::More' in core (since v5.6.2) after minimum perl
v5.0.0
not ok 5 - Declared dependency ExtUtils::CChecker used
#   Failed test 'Declared dependency ExtUtils::CChecker used'
#   at /usr/share/perl5/vendor_perl/Test/Dependencies.pm line 181.
not ok 6 - Declared dependency ExtUtils::Constant used
#   Failed test 'Declared dependency ExtUtils::Constant used'
#   at /usr/share/perl5/vendor_perl/Test/Dependencies.pm line 181.
ok 7 - Declared dependency ExtUtils::PkgConfig used
ok 8 - Declared dependency Test::Exception used
ok 9 - Declared dependency Test::More used
ok 10 - Declared dependency XSLoader used
not ok 11 - Used CORE module 'Config' in core before Perl v5.0.0 (since
v5.3.70) or explicitly required
#   Failed test 'Used CORE module 'Config' in core before Perl v5.0.0 (since
v5.3.70) or explicitly required'
#   at /usr/share/perl5/vendor_perl/Test/Dependencies.pm line 181.
ok 12
not ok 13 - Used CORE module 'ExtUtils::Manifest' in core before Perl v5.0.0
(since v5.1.0) or explicitly required
#   Failed test 'Used CORE module 'ExtUtils::Manifest' in core before Perl
v5.0.0 (since v5.1.0) or explicitly required'
#   at /usr/share/perl5/vendor_perl/Test/Dependencies.pm line 181.
ok 14 - Used non-CORE module 'ExtUtils::PkgConfig' in requirements listing
not ok 15 - Used CORE module 'File::Spec' in core before Perl v5.0.0 (since
v5.4.50) or explicitly required
#   Failed test 'Used CORE module 'File::Spec' in core before Perl v5.0.0
(since v5.4.50) or explicitly required'
#   at /usr/share/perl5/vendor_perl/Test/Dependencies.pm line 181.
not ok 16 - Used CORE module 'File::Temp' in core before Perl v5.0.0 (since
v5.6.1) or explicitly required
#   Failed test 'Used CORE module 'File::Temp' in core before Perl v5.0.0
(since v5.6.1) or explicitly required'
#   at /usr/share/perl5/vendor_perl/Test/Dependencies.pm line 181.
ok 17 - Used non-CORE module 'Test::Exception' in requirements listing
ok 18 - Used CORE module 'Test::More' in core before Perl v5.0.0 (since v5.6.2)
or explicitly required
ok 19 - Used CORE module 'XSLoader' in core before Perl v5.0.0 (since v5.6.0)
or explicitly required
ok 20
not ok 21 - Used CORE module 'warnings' in core before Perl v5.0.0 (since
v5.6.0) or explicitly required
#   Failed test 'Used CORE module 'warnings' in core before Perl v5.0.0 (since
v5.6.0) or explicitly required'
#   at /usr/share/perl5/vendor_perl/Test/Dependencies.pm line 181.
1..21

A difference between passing and failing build root is at
. This failure is triggered by
upgrading perl-Test-Dependencies from 0.24-4.fc34 to 0.28-1.fc34.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1868278
[Bug 1868278] (F34FTBFS) - Fedora 34 FTBFS Tracker
-- 
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: About the Future of Communishift

[Leigh Griffin]

On Fri, Sep 4, 2020 at 12:17 PM Neal Gompa  wrote:

> On Fri, Sep 4, 2020 at 7:10 AM clime  wrote:
> >
> > On Fri, 4 Sep 2020 at 12:59, clime  wrote:
> > >
> > > On Fri, 4 Sep 2020 at 12:48, Aoife Moloney 
> wrote:
> > > >
> > > > Good Morning Everyone,
> > > >
> > > > I wanted to share with you some information regarding the current
> > > > state and future of Communishift. The infrastructure team presented
> on
> > > > this project back in 2019 during Nest [1] [2], and since then, we
> have
> > > > deployed it, started using it and had to shut it down for
> > > > the colo-move.
> > > >
> > > > As a number of people have noted, it has not come back up yet, and
> > > > during Nest this year, we had hinted that communishift is not going
> to
> > > > come back alive looking
> > > > the same as when we shut it down, and that is unfortunately true.
> > > >
> > > > The idea for communishift was to give to anyone in the community a
> place where
> > > > they could run any application they wish to provide to the community.
> > > > This was a proper place where Joe and Jane could offer the service
> foo to the
> > > > foo SIG without engaging the infrastructure's team responsibility to
> keep the
> > > > service up and running. The infrastructure team would have been able
> to say:
> > > > "well the openshift cluster is running, so if the app isn't, talk to
> the
> > > > application maintainer, there is nothing we can do about it".
> > > >
> > > > Basically, it gave a place where we could experiment with new apps
> > > > without adding too
> > > > much work to the infrastructure team.
> > > >
> > > > However, the General Data Protection Regulation (GDPR) [3] and the
> California
> > > > Consumer Privacy Act (CCPA) [4] basically makes the Fedora
> Infrastructure team
> > > > (and thus Red Hat) responsible for the content hosted by any
> services running in
> > > > our infrastructure. In other words, the Fedora Infrastructure team
> would be
> > > > responsible to answer all GDPR/CCPA related requests and
> requirements for any
> > > > and all services running in communishift (services that the team has
> 0 knowledge
> > > > about, that's the whole goal of communishift).
> > > >
> > > > For these reasons communishift is not going to come back to life in
> the same way
> > > > it was shut down for the colo move.
> > > >
> > > > We have not given up on the original idea though (ie: providing a
> place where
> > > > community members can deploy applications without adding work on the
> > > > infrastructure team), however, as with anything involving legal,
> this is going
> > > > to be a slow process. We will share any information as soon as we
> are able.
> > > >
> > > >
> > > > We're sorry for the inconvenience this causes, we really would like
> the
> > > > situation to be different but we also appreciate these regulations
> for what they
> > > > are (protecting our personal information) so we want to respect them.
> > > >
> > > >
> > > > Hoping this clarifies the situation around communishift a bit.
> > > >
> > > > Aoife, Kevin & Pingou
> > > >   - On behalf of the Fedora Infrastructure team
> > >
> > > Hello Aoife,
> > >
> > > is it working right now so that I can deploy my community app there or
> > > currently not working at all?
> >
> > Or better...is there at least some alternative or some way to deploy a
> > community app
> > these days? Or currently none. :)
> >
>
> My read of this is that right now, there will be no way for the
> community to run applications in Fedora Infrastructure in a way that
> CPE can be divorced from it completely. That is because their goal of
> running only OpenShift and then not caring about what's inside is
> legally not possible.
>

That's correct and as a team we are not setup for handling GDPR requests
like other teams in Red Hat. In many ways this regulation is punitive to
teams / companies who have not set themselves up with it in mind. Other
teams in Red Hat are setup for this and we are trying to work with them to
provide the relevant functionality, just divorced from the CPE team from a
workload perspective.

>
> Consequently, when the OpenShift cluster returns (if it even does, I
> am unsure that it will, since running multiple OpenShift clusters
> doesn't make sense anymore), it will require a vetting process of some
> kind (that has yet to be created) to ensure that CPE is comfortable
> with partial responsibility of the application, since they need to
> care about the data it stores.
>

Legally we have to have agreements with the service owners and still be on
the hook as the overall owner of it, it's messy and complicated but you are
correct, there is a path forward through vetting and good processes.

>
> So, I guess... wait and see?
>

Finger crossing helps :)

>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 

Re: About the Future of Communishift

[Tomasz Torcz]

On Fri, Sep 04, 2020 at 02:08:02PM +0200, Pierre-Yves Chibon wrote:
> 
> >   I don't really expect an answer. From my experience, it's impossible
> > to get straight, yes/no, binary answer from lawyers.
> 
> Thus the slow process :(
> The goal of the email was to inform about the current situation as we saw the
> topic raised in a few places lately.

  Of course, thank Aoife for that information!  It is much better to
have news, even unfortunate ones, than to be kept in the dark.
  This update was appreciated.


-- 
Tomasz TorczOnly gods can safely risk perfection,
to...@pipebreaker.pl it's a dangerous thing for a man.  — Alia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: About the Future of Communishift

[Mauricio Tavares]

On Fri, Sep 4, 2020 at 7:48 AM Tomasz Torcz  wrote:
>
> On Fri, Sep 04, 2020 at 07:16:02AM -0400, Neal Gompa wrote:
> > On Fri, Sep 4, 2020 at 7:10 AM clime  wrote:
> > >
> > > On Fri, 4 Sep 2020 at 12:59, clime  wrote:
> > > >
> > > > On Fri, 4 Sep 2020 at 12:48, Aoife Moloney  wrote:
> > > > >
> > > > > However, the General Data Protection Regulation (GDPR) [3] and the 
> > > > > California
> > > > > Consumer Privacy Act (CCPA) [4] basically makes the Fedora 
> > > > > Infrastructure team
> > > > > (and thus Red Hat) responsible for the content hosted by any services 
> > > > > running in
> > > > > our infrastructure. In other words, the Fedora Infrastructure team 
> > > > > would be
> > > > > responsible to answer all GDPR/CCPA related requests and requirements 
> > > > > for any
> > > > > and all services running in communishift (services that the team has 
> > > > > 0 knowledge
> > > > > about, that's the whole goal of communishift).
> > >
> >
> > My read of this is that right now, there will be no way for the
> > community to run applications in Fedora Infrastructure in a way that
> > CPE can be divorced from it completely. That is because their goal of
> > running only OpenShift and then not caring about what's inside is
> > legally not possible.
>
>
>   Hmm. But how, for example, cloud providers are able to provide
> infrastructure without taking responsibility for what's hosted?

  I think that has to do with service agreements between the
provider and its customers, and the expectation that if provider is
made aware of a violation of one of its customers, it will cooperate
with (say EU) . Otherwise, the provider would have to be scanning the
contents of every single of its customers at all the times, which then
can in itself become a GDPR violation.

Take google for example: as I type this reply it is highlighting what
it considers to be spelling and grammatical errors as I type. That
means it is reading everything I am typing right now and probably
storing it somewhere to (at very least) improve its algorithm, and
more. If I have a file in google drive, chances are it is being
scanned. This is fundamentally different than just hosting the data
and not interfering with customer besides ensuring said customer is
not hogging the resources.

> I don't think GCP is handling any GPDR/CCPA requests for clients' stuff…
>   I don't really expect an answer. From my experience, it's impossible
> to get straight, yes/no, binary answer from lawyers.
>
  Also the wording on GDPR's regulations is intentionally vague.
CCPA is but an American/Californian response to GDPR but not as aimed
at protecting the individual since

1. The CCPA applies to any business which does business in California
(including data brokers), that satisfies at least one of the
thresholds :
1.1 Has annual gross revenues in excess of $25 million;
1.2. Buys, receives, or sells the personal information of 50,000 or
more consumers or households; or
1.3. Earns more than half of its annual revenue from selling
consumers' personal information.
1.4. Provides an opt-OUT *right* for sales of personal information
versus opt-IN *necessity* for GDPR


> --
> Tomasz TorczOnly gods can safely risk perfection,
> to...@pipebreaker.pl it's a dangerous thing for a man.  — Alia
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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: About the Future of Communishift

[Pierre-Yves Chibon]

On Fri, Sep 04, 2020 at 01:47:58PM +0200, Tomasz Torcz wrote:
> On Fri, Sep 04, 2020 at 07:16:02AM -0400, Neal Gompa wrote:
> > On Fri, Sep 4, 2020 at 7:10 AM clime  wrote:
> > >
> > > On Fri, 4 Sep 2020 at 12:59, clime  wrote:
> > > >
> > > > On Fri, 4 Sep 2020 at 12:48, Aoife Moloney  wrote:
> > > > >
> > > > > However, the General Data Protection Regulation (GDPR) [3] and the 
> > > > > California
> > > > > Consumer Privacy Act (CCPA) [4] basically makes the Fedora 
> > > > > Infrastructure team
> > > > > (and thus Red Hat) responsible for the content hosted by any services 
> > > > > running in
> > > > > our infrastructure. In other words, the Fedora Infrastructure team 
> > > > > would be
> > > > > responsible to answer all GDPR/CCPA related requests and requirements 
> > > > > for any
> > > > > and all services running in communishift (services that the team has 
> > > > > 0 knowledge
> > > > > about, that's the whole goal of communishift).
> > >
> > 
> > My read of this is that right now, there will be no way for the
> > community to run applications in Fedora Infrastructure in a way that
> > CPE can be divorced from it completely. That is because their goal of
> > running only OpenShift and then not caring about what's inside is
> > legally not possible.
> 
>  
>   Hmm. But how, for example, cloud providers are able to provide
> infrastructure without taking responsibility for what's hosted?
> I don't think GCP is handling any GPDR/CCPA requests for clients' stuff…

This is definitely one of the question we have and are looking into.

>   I don't really expect an answer. From my experience, it's impossible
> to get straight, yes/no, binary answer from lawyers.

Thus the slow process :(
The goal of the email was to inform about the current situation as we saw the
topic raised in a few places lately.

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: About the Future of Communishift

[Tomasz Torcz]

On Fri, Sep 04, 2020 at 07:16:02AM -0400, Neal Gompa wrote:
> On Fri, Sep 4, 2020 at 7:10 AM clime  wrote:
> >
> > On Fri, 4 Sep 2020 at 12:59, clime  wrote:
> > >
> > > On Fri, 4 Sep 2020 at 12:48, Aoife Moloney  wrote:
> > > >
> > > > However, the General Data Protection Regulation (GDPR) [3] and the 
> > > > California
> > > > Consumer Privacy Act (CCPA) [4] basically makes the Fedora 
> > > > Infrastructure team
> > > > (and thus Red Hat) responsible for the content hosted by any services 
> > > > running in
> > > > our infrastructure. In other words, the Fedora Infrastructure team 
> > > > would be
> > > > responsible to answer all GDPR/CCPA related requests and requirements 
> > > > for any
> > > > and all services running in communishift (services that the team has 0 
> > > > knowledge
> > > > about, that's the whole goal of communishift).
> >
> 
> My read of this is that right now, there will be no way for the
> community to run applications in Fedora Infrastructure in a way that
> CPE can be divorced from it completely. That is because their goal of
> running only OpenShift and then not caring about what's inside is
> legally not possible.

 
  Hmm. But how, for example, cloud providers are able to provide
infrastructure without taking responsibility for what's hosted?
I don't think GCP is handling any GPDR/CCPA requests for clients' stuff…
  I don't really expect an answer. From my experience, it's impossible
to get straight, yes/no, binary answer from lawyers.

-- 
Tomasz TorczOnly gods can safely risk perfection,
to...@pipebreaker.pl it's a dangerous thing for a man.  — Alia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: About the Future of Communishift

[Petr Pisar]

On Fri, Sep 04, 2020 at 11:13:19AM +0100, Aoife Moloney wrote:
> However, the General Data Protection Regulation (GDPR) [3] and the California
> Consumer Privacy Act (CCPA) [4] basically makes the Fedora Infrastructure team
> (and thus Red Hat) responsible for the content hosted by any services running 
> in
> our infrastructure. In other words, the Fedora Infrastructure team would be
> responsible to answer all GDPR/CCPA related requests and requirements for any
> and all services running in communishift (services that the team has 0 
> knowledge
> about, that's the whole goal of communishift).
> 
Is Fedora Project going to shut down ? Or what's
the key difference between hosting data and hosting applications from GDPR and
CCPA point of view?

I'm not a lawyer, I but I think your interpretation of GDPR is somewhat
exagarated. Otherwise everybody would close his cloud services, and that's not
what I can observe.

-- Petr


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

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

[Fedora compose checker]

No missing expected images.

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

Failed openQA tests: 11/181 (x86_64)

New failures (same test not failed in Fedora-Rawhide-20200902.n.1):

ID: 654693  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/654693
ID: 654695  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/654695
ID: 654763  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/654763
ID: 654790  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/654790
ID: 654825  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/654825

Old failures (same test failed in Fedora-Rawhide-20200902.n.1):

ID: 654722  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/654722
ID: 654730  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/654730
ID: 654751  Test: x86_64 universal install_mirrorlist_graphical **GATING**
URL: https://openqa.fedoraproject.org/tests/654751
ID: 654756  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/654756
ID: 654791  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/654791
ID: 654818  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/654818

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

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

ID: 654706  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/654706

Old soft failures (same test soft failed in Fedora-Rawhide-20200902.n.1):

ID: 654647  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/654647
ID: 654666  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/654666
ID: 654668  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/654668
ID: 654726  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/654726
ID: 654729  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/654729
ID: 654743  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/654743
ID: 654765  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/654765
ID: 654772  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/654772
ID: 654773  Test: x86_64 universal upgrade_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/654773
ID: 654777  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/654777
ID: 654799  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/654799

Passed openQA tests: 158/181 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20200902.n.1):

ID: 654690  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/654690
ID: 654691  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/654691
ID: 654694  Test: x86_64 Workstation-live-iso release_identification
URL: https://openqa.fedoraproject.org/tests/654694
ID: 654696  Test: x86_64 Workstation-live-iso base_reboot_unmount
URL: https://openqa.fedoraproject.org/tests/654696
ID: 654697  Test: x86_64 Workstation-live-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/654697
ID: 654698  Test: x86_64 Workstation-live-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/654698
ID: 654699  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/654699
ID: 654700  Test: x86_64 Workstation-live-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/654700
ID: 654701  Test: x86_64 Workstation-live-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/654701
ID: 654702  Test: x86_64 Workstation-live-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/654702
ID: 654703  Test: x86_64 Workstation-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/654703
ID: 654704  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/654704
ID: 654705  Test: x86_64 Workstation-live-iso desktop_browser

Re: About the Future of Communishift

[Neal Gompa]

On Fri, Sep 4, 2020 at 7:10 AM clime  wrote:
>
> On Fri, 4 Sep 2020 at 12:59, clime  wrote:
> >
> > On Fri, 4 Sep 2020 at 12:48, Aoife Moloney  wrote:
> > >
> > > Good Morning Everyone,
> > >
> > > I wanted to share with you some information regarding the current
> > > state and future of Communishift. The infrastructure team presented on
> > > this project back in 2019 during Nest [1] [2], and since then, we have
> > > deployed it, started using it and had to shut it down for
> > > the colo-move.
> > >
> > > As a number of people have noted, it has not come back up yet, and
> > > during Nest this year, we had hinted that communishift is not going to
> > > come back alive looking
> > > the same as when we shut it down, and that is unfortunately true.
> > >
> > > The idea for communishift was to give to anyone in the community a place 
> > > where
> > > they could run any application they wish to provide to the community.
> > > This was a proper place where Joe and Jane could offer the service foo to 
> > > the
> > > foo SIG without engaging the infrastructure's team responsibility to keep 
> > > the
> > > service up and running. The infrastructure team would have been able to 
> > > say:
> > > "well the openshift cluster is running, so if the app isn't, talk to the
> > > application maintainer, there is nothing we can do about it".
> > >
> > > Basically, it gave a place where we could experiment with new apps
> > > without adding too
> > > much work to the infrastructure team.
> > >
> > > However, the General Data Protection Regulation (GDPR) [3] and the 
> > > California
> > > Consumer Privacy Act (CCPA) [4] basically makes the Fedora Infrastructure 
> > > team
> > > (and thus Red Hat) responsible for the content hosted by any services 
> > > running in
> > > our infrastructure. In other words, the Fedora Infrastructure team would 
> > > be
> > > responsible to answer all GDPR/CCPA related requests and requirements for 
> > > any
> > > and all services running in communishift (services that the team has 0 
> > > knowledge
> > > about, that's the whole goal of communishift).
> > >
> > > For these reasons communishift is not going to come back to life in the 
> > > same way
> > > it was shut down for the colo move.
> > >
> > > We have not given up on the original idea though (ie: providing a place 
> > > where
> > > community members can deploy applications without adding work on the
> > > infrastructure team), however, as with anything involving legal, this is 
> > > going
> > > to be a slow process. We will share any information as soon as we are 
> > > able.
> > >
> > >
> > > We're sorry for the inconvenience this causes, we really would like the
> > > situation to be different but we also appreciate these regulations for 
> > > what they
> > > are (protecting our personal information) so we want to respect them.
> > >
> > >
> > > Hoping this clarifies the situation around communishift a bit.
> > >
> > > Aoife, Kevin & Pingou
> > >   - On behalf of the Fedora Infrastructure team
> >
> > Hello Aoife,
> >
> > is it working right now so that I can deploy my community app there or
> > currently not working at all?
>
> Or better...is there at least some alternative or some way to deploy a
> community app
> these days? Or currently none. :)
>

My read of this is that right now, there will be no way for the
community to run applications in Fedora Infrastructure in a way that
CPE can be divorced from it completely. That is because their goal of
running only OpenShift and then not caring about what's inside is
legally not possible.

Consequently, when the OpenShift cluster returns (if it even does, I
am unsure that it will, since running multiple OpenShift clusters
doesn't make sense anymore), it will require a vetting process of some
kind (that has yet to be created) to ensure that CPE is comfortable
with partial responsibility of the application, since they need to
care about the data it stores.

So, I guess... wait and see?



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

Re: About the Future of Communishift

[clime]

On Fri, 4 Sep 2020 at 12:59, clime  wrote:
>
> On Fri, 4 Sep 2020 at 12:48, Aoife Moloney  wrote:
> >
> > Good Morning Everyone,
> >
> > I wanted to share with you some information regarding the current
> > state and future of Communishift. The infrastructure team presented on
> > this project back in 2019 during Nest [1] [2], and since then, we have
> > deployed it, started using it and had to shut it down for
> > the colo-move.
> >
> > As a number of people have noted, it has not come back up yet, and
> > during Nest this year, we had hinted that communishift is not going to
> > come back alive looking
> > the same as when we shut it down, and that is unfortunately true.
> >
> > The idea for communishift was to give to anyone in the community a place 
> > where
> > they could run any application they wish to provide to the community.
> > This was a proper place where Joe and Jane could offer the service foo to 
> > the
> > foo SIG without engaging the infrastructure's team responsibility to keep 
> > the
> > service up and running. The infrastructure team would have been able to say:
> > "well the openshift cluster is running, so if the app isn't, talk to the
> > application maintainer, there is nothing we can do about it".
> >
> > Basically, it gave a place where we could experiment with new apps
> > without adding too
> > much work to the infrastructure team.
> >
> > However, the General Data Protection Regulation (GDPR) [3] and the 
> > California
> > Consumer Privacy Act (CCPA) [4] basically makes the Fedora Infrastructure 
> > team
> > (and thus Red Hat) responsible for the content hosted by any services 
> > running in
> > our infrastructure. In other words, the Fedora Infrastructure team would be
> > responsible to answer all GDPR/CCPA related requests and requirements for 
> > any
> > and all services running in communishift (services that the team has 0 
> > knowledge
> > about, that's the whole goal of communishift).
> >
> > For these reasons communishift is not going to come back to life in the 
> > same way
> > it was shut down for the colo move.
> >
> > We have not given up on the original idea though (ie: providing a place 
> > where
> > community members can deploy applications without adding work on the
> > infrastructure team), however, as with anything involving legal, this is 
> > going
> > to be a slow process. We will share any information as soon as we are able.
> >
> >
> > We're sorry for the inconvenience this causes, we really would like the
> > situation to be different but we also appreciate these regulations for what 
> > they
> > are (protecting our personal information) so we want to respect them.
> >
> >
> > Hoping this clarifies the situation around communishift a bit.
> >
> > Aoife, Kevin & Pingou
> >   - On behalf of the Fedora Infrastructure team
>
> Hello Aoife,
>
> is it working right now so that I can deploy my community app there or
> currently not working at all?

Or better...is there at least some alternative or some way to deploy a
community app
these days? Or currently none. :)

Thank you for the answer
clime

>
> Thank you
> clime
>
> >
> >
> > [1] https://fedoraproject.org/wiki/Infrastructue/Communishift
> > [2] 
> > https://www.youtube.com/watch?v=phCHilTEQb4=PL0x39xti0_64C75dRUuwlXlfYRgjgdEP4=8=0s
> > [3] https://gdpr-info.eu/
> > [4] https://www.oag.ca.gov/privacy/ccpa
> >
> > [4] https://www.oag.ca.gov/privacy/ccpa
> >
> > --
> > Aoife Moloney
> > Product Owner
> > Community Platform Engineering Team
> > Red Hat EMEA
> > Communications House
> > Cork Road
> > Waterford
> > ___
> > 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

Fedora rawhide compose report: 20200904.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200902.n.1
NEW: Fedora-Rawhide-20200904.n.0

= SUMMARY =
Added images:0
Dropped images:  8
Added packages:  23
Dropped packages:1
Upgraded packages:   295
Downgraded packages: 0

Size of added packages:  1.51 GiB
Size of dropped packages:457.39 KiB
Size of upgraded packages:   10.34 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20200902.n.1.s390x.tar.xz
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200902.n.1.s390x.qcow2
Image: Cloud_Base vmdk s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200902.n.1.s390x.vmdk
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200902.n.1.s390x.raw.xz
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20200902.n.1.iso
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20200902.n.1.s390x.tar.xz
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20200902.n.1.iso
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20200902.n.1.iso

= ADDED PACKAGES =
Package: R-waldo-0.2.0-1.fc34
Summary: Find Differences Between R Objects
RPMs:R-waldo
Size:78.68 KiB

Package: community-mysql-8.0.21-11.module_f34+10057+ef1f99aa
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:1.10 GiB

Package: cyrus-timezones-20200903-1.20200903git4f795aeb.fc34
Summary: Timezone information for the Cyrus IMAP Server
RPMs:cyrus-timezones cyrus-timezones-devel
Size:1.02 MiB

Package: directory-maven-plugin-0.3.1-1.module_f34+10061+b833aff1
Summary: Establish locations for files in multi-module builds
RPMs:directory-maven-plugin directory-maven-plugin-javadoc
Size:287.38 KiB

Package: ee4j-parent-1.0.1-1.module_f34+10061+b833aff1
Summary: Parent POM file for Eclipse Enterprise for Java projects
RPMs:ee4j-parent
Size:10.38 KiB

Package: fcitx5-kkc-0-0.1.20200904git7c6d0b5.fc34
Summary: Libkkc input method support for Fcitx5
RPMs:fcitx5-kkc
Size:574.42 KiB

Package: fuse-btfs-2.22-2.fc34
Summary: FUSE filesystem Bittorrent
RPMs:fuse-btfs
Size:324.87 KiB

Package: ghc-aeson-yaml-1.0.6.0-2.fc34
Summary: Output any Aeson value as YAML (pure Haskell library)
RPMs:ghc-aeson-yaml ghc-aeson-yaml-devel ghc-aeson-yaml-doc 
ghc-aeson-yaml-prof
Size:569.12 KiB

Package: ghc-ghc-lib-parser-8.10.2.20200808-1.fc34
Summary: The GHC API, decoupled from GHC versions
RPMs:ghc-ghc-lib-parser ghc-ghc-lib-parser-devel ghc-ghc-lib-parser-doc 
ghc-ghc-lib-parser-prof
Size:147.23 MiB

Package: ghc-http-streams-0.8.7.2-1.fc34
Summary: An HTTP client using io-streams
RPMs:ghc-http-streams ghc-http-streams-devel ghc-http-streams-doc 
ghc-http-streams-prof
Size:1.77 MiB

Package: ghc-language-docker-9.1.1-1.fc34
Summary: Dockerfile parser, pretty-printer and embedded DSL
RPMs:ghc-language-docker ghc-language-docker-devel ghc-language-docker-doc 
ghc-language-docker-prof
Size:9.27 MiB

Package: golang-github-git-lfs-gitobj-2-2.0.0-1.fc34
Summary: Gitobj reads and writes Git objects
RPMs:golang-github-git-lfs-gitobj-2-devel
Size:57.43 KiB

Package: golang-github-openprinting-goipp-1.0.0-1.fc34
Summary: IPP core protocol in pure Go (RFC 8010)
RPMs:golang-github-openprinting-goipp-devel
Size:36.14 KiB

Package: golang-github-xlzd-gotp-0-0.1.20200903gitc8557ba.fc34
Summary: Golang OTP(One-Time Password) Library
RPMs:golang-github-xlzd-gotp-devel
Size:14.69 KiB

Package: grammalecte-1.12.2-1.fc34
Summary: French grammar checker
RPMs:libreoffice-grammalecte python3-grammalecte
Size:12.81 MiB

Package: hadolint-1.18.0-1.fc34
Summary: Dockerfile linter, validate inline bash
RPMs:ghc-hadolint ghc-hadolint-devel ghc-hadolint-doc ghc-hadolint-prof 
hadolint
Size:30.99 MiB

Package: javamail-1.6.5-2.module_f34+10061+b833aff1
Summary: Java Mail API
RPMs:javamail
Size:684.48 KiB

Package: jmc-8.0.0-7.20200303.module_f34+10061+b833aff1
Summary: JDK Mission Control is a profiling and diagnostics tool
RPMs:jmc
Size:206.14 MiB

Package: jmc-core-8.0.0-2.20200303.module_f34+10061+b833aff1
Summary: Core API for JDK Mission Control
RPMs:jmc-core jmc-core-javadoc
Size:2.52 MiB

Package: owasp-java-encoder-1.2.2-3.module_f34+10061+b833aff1
Summary: Collection of high-performance low-overhead contextual encoders
RPMs:owasp-java-encoder owasp-java-encoder-javadoc
Size:347.88 KiB

Package: python-btlewrap-0.0.10-1

Re: About the Future of Communishift

[clime]

On Fri, 4 Sep 2020 at 12:48, Aoife Moloney  wrote:
>
> Good Morning Everyone,
>
> I wanted to share with you some information regarding the current
> state and future of Communishift. The infrastructure team presented on
> this project back in 2019 during Nest [1] [2], and since then, we have
> deployed it, started using it and had to shut it down for
> the colo-move.
>
> As a number of people have noted, it has not come back up yet, and
> during Nest this year, we had hinted that communishift is not going to
> come back alive looking
> the same as when we shut it down, and that is unfortunately true.
>
> The idea for communishift was to give to anyone in the community a place where
> they could run any application they wish to provide to the community.
> This was a proper place where Joe and Jane could offer the service foo to the
> foo SIG without engaging the infrastructure's team responsibility to keep the
> service up and running. The infrastructure team would have been able to say:
> "well the openshift cluster is running, so if the app isn't, talk to the
> application maintainer, there is nothing we can do about it".
>
> Basically, it gave a place where we could experiment with new apps
> without adding too
> much work to the infrastructure team.
>
> However, the General Data Protection Regulation (GDPR) [3] and the California
> Consumer Privacy Act (CCPA) [4] basically makes the Fedora Infrastructure team
> (and thus Red Hat) responsible for the content hosted by any services running 
> in
> our infrastructure. In other words, the Fedora Infrastructure team would be
> responsible to answer all GDPR/CCPA related requests and requirements for any
> and all services running in communishift (services that the team has 0 
> knowledge
> about, that's the whole goal of communishift).
>
> For these reasons communishift is not going to come back to life in the same 
> way
> it was shut down for the colo move.
>
> We have not given up on the original idea though (ie: providing a place where
> community members can deploy applications without adding work on the
> infrastructure team), however, as with anything involving legal, this is going
> to be a slow process. We will share any information as soon as we are able.
>
>
> We're sorry for the inconvenience this causes, we really would like the
> situation to be different but we also appreciate these regulations for what 
> they
> are (protecting our personal information) so we want to respect them.
>
>
> Hoping this clarifies the situation around communishift a bit.
>
> Aoife, Kevin & Pingou
>   - On behalf of the Fedora Infrastructure team

Hello Aoife,

is it working right now so that I can deploy my community app there or
currently not working at all?

Thank you
clime

>
>
> [1] https://fedoraproject.org/wiki/Infrastructue/Communishift
> [2] 
> https://www.youtube.com/watch?v=phCHilTEQb4=PL0x39xti0_64C75dRUuwlXlfYRgjgdEP4=8=0s
> [3] https://gdpr-info.eu/
> [4] https://www.oag.ca.gov/privacy/ccpa
>
> [4] https://www.oag.ca.gov/privacy/ccpa
>
> --
> Aoife Moloney
> Product Owner
> Community Platform Engineering Team
> Red Hat EMEA
> Communications House
> Cork Road
> Waterford
> ___
> 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

About the Future of Communishift

[Aoife Moloney]

Good Morning Everyone,

I wanted to share with you some information regarding the current
state and future of Communishift. The infrastructure team presented on
this project back in 2019 during Nest [1] [2], and since then, we have
deployed it, started using it and had to shut it down for
the colo-move.

As a number of people have noted, it has not come back up yet, and
during Nest this year, we had hinted that communishift is not going to
come back alive looking
the same as when we shut it down, and that is unfortunately true.

The idea for communishift was to give to anyone in the community a place where
they could run any application they wish to provide to the community.
This was a proper place where Joe and Jane could offer the service foo to the
foo SIG without engaging the infrastructure's team responsibility to keep the
service up and running. The infrastructure team would have been able to say:
"well the openshift cluster is running, so if the app isn't, talk to the
application maintainer, there is nothing we can do about it".

Basically, it gave a place where we could experiment with new apps
without adding too
much work to the infrastructure team.

However, the General Data Protection Regulation (GDPR) [3] and the California
Consumer Privacy Act (CCPA) [4] basically makes the Fedora Infrastructure team
(and thus Red Hat) responsible for the content hosted by any services running in
our infrastructure. In other words, the Fedora Infrastructure team would be
responsible to answer all GDPR/CCPA related requests and requirements for any
and all services running in communishift (services that the team has 0 knowledge
about, that's the whole goal of communishift).

For these reasons communishift is not going to come back to life in the same way
it was shut down for the colo move.

We have not given up on the original idea though (ie: providing a place where
community members can deploy applications without adding work on the
infrastructure team), however, as with anything involving legal, this is going
to be a slow process. We will share any information as soon as we are able.


We're sorry for the inconvenience this causes, we really would like the
situation to be different but we also appreciate these regulations for what they
are (protecting our personal information) so we want to respect them.


Hoping this clarifies the situation around communishift a bit.

Aoife, Kevin & Pingou
  - On behalf of the Fedora Infrastructure team


[1] https://fedoraproject.org/wiki/Infrastructue/Communishift
[2] 
https://www.youtube.com/watch?v=phCHilTEQb4=PL0x39xti0_64C75dRUuwlXlfYRgjgdEP4=8=0s
[3] https://gdpr-info.eu/
[4] https://www.oag.ca.gov/privacy/ccpa

[4] https://www.oag.ca.gov/privacy/ccpa

-- 
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
___
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

About the Future of Communishift

[Aoife Moloney]

Good Morning Everyone,

I wanted to share with you some information regarding the current
state and future of Communishift. The infrastructure team presented on
this project back in 2019 during Nest [1] [2], and since then, we have
deployed it, started using it and had to shut it down for
the colo-move.

As a number of people have noted, it has not come back up yet, and
during Nest this year, we had hinted that communishift is not going to
come back alive looking
the same as when we shut it down, and that is unfortunately true.

The idea for communishift was to give to anyone in the community a place where
they could run any application they wish to provide to the community.
This was a proper place where Joe and Jane could offer the service foo to the
foo SIG without engaging the infrastructure's team responsibility to keep the
service up and running. The infrastructure team would have been able to say:
"well the openshift cluster is running, so if the app isn't, talk to the
application maintainer, there is nothing we can do about it".

Basically, it gave a place where we could experiment with new apps
without adding too
much work to the infrastructure team.

However, the General Data Protection Regulation (GDPR) [3] and the California
Consumer Privacy Act (CCPA) [4] basically makes the Fedora Infrastructure team
(and thus Red Hat) responsible for the content hosted by any services running in
our infrastructure. In other words, the Fedora Infrastructure team would be
responsible to answer all GDPR/CCPA related requests and requirements for any
and all services running in communishift (services that the team has 0 knowledge
about, that's the whole goal of communishift).

For these reasons communishift is not going to come back to life in the same way
it was shut down for the colo move.

We have not given up on the original idea though (ie: providing a place where
community members can deploy applications without adding work on the
infrastructure team), however, as with anything involving legal, this is going
to be a slow process. We will share any information as soon as we are able.


We're sorry for the inconvenience this causes, we really would like the
situation to be different but we also appreciate these regulations for what they
are (protecting our personal information) so we want to respect them.


Hoping this clarifies the situation around communishift a bit.

Aoife, Kevin & Pingou
  - On behalf of the Fedora Infrastructure team


[1] https://fedoraproject.org/wiki/Infrastructue/Communishift
[2] 
https://www.youtube.com/watch?v=phCHilTEQb4=PL0x39xti0_64C75dRUuwlXlfYRgjgdEP4=8=0s
[3] https://gdpr-info.eu/
[4] https://www.oag.ca.gov/privacy/ccpa

[4] https://www.oag.ca.gov/privacy/ccpa

-- 
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
___
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

Fedora-Cloud-31-20200904.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Re: Is s390 (32-bit) relevant for Fedora alt arch ?

[Dominik 'Rathann' Mierzejewski]

On Friday, 04 September 2020 at 11:00, Daniel P. Berrangé wrote:
> I'm looking at cleaning up some parts of the QEMU spec and we have
> conditionals in there testing for s390 arch (aka 32-bit). IIRC it
> was previously a secondary arch, at least back in the Fedora 22-ish
> timeframe. I'm not seeing it listed in the alternative arch list
> currently though:
> 
>   https://fedoraproject.org/wiki/Architectures
> 
> Am I right in concluding that 's390' does not need to be considered in
> RPM spec files now, and thus we can purge any 's390' arch checks ?

Looking at qemu.spec, are you talking about this one?
https://src.fedoraproject.org/rpms/qemu/blob/master/f/qemu.spec#_1005
Does it also happen on armv7hl and i686? I guess not.

The rest if %ifarch s390 can be dropped as far as I can tell.

You can also drop ppc, ppc64 and mips64, too. For example, here:
https://src.fedoraproject.org/rpms/qemu/blob/master/f/qemu.spec#_1201

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

Re: New segfault with flexiblas/openblaso

[Iñaki Ucar]

On Fri, 4 Sep 2020 at 11:16, Susi Lehtola
 wrote:
>
> On Fri, 4 Sep 2020 10:57:13 +0200
> Iñaki Ucar  wrote:
> > Hi,
> >
> > Strange... Let me bring this upstream to see whether this is
> > flexiblas' or openblas' fault. In the meanwhile, exporting
> > FLEXIBLAS=netlib before the tests makes use of the reference
> > implementation, so everything should be slower but safer. And if this
> > starts happening in the wild, we can change to openblas-serial with a
> > quick update of FlexiBLAS.
>
> ... which would lead to a horrendous regression in performance, utterly
> ruining parallellization.
>
> If this happens, there is no alternative but to resort to the
> contingency plan of the FlexiBLAS as BLAS/LAPACK manager: undo all
> changes and rebuild all packages so that they work again as intended.

If this is a bug in FlexiBLAS, by experience I'm sure it will be fixed
soon. If not, then it's a bug in openblaso, which should be also
tracked down and fixed; otherwise, would you link packages back to
openblaso knowing it's faulty?

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 segfault with flexiblas/openblaso

[Susi Lehtola]

On Fri, 4 Sep 2020 10:57:13 +0200
Iñaki Ucar  wrote:
> Hi,
> 
> Strange... Let me bring this upstream to see whether this is
> flexiblas' or openblas' fault. In the meanwhile, exporting
> FLEXIBLAS=netlib before the tests makes use of the reference
> implementation, so everything should be slower but safer. And if this
> starts happening in the wild, we can change to openblas-serial with a
> quick update of FlexiBLAS.

... which would lead to a horrendous regression in performance, utterly
ruining parallellization.

If this happens, there is no alternative but to resort to the
contingency plan of the FlexiBLAS as BLAS/LAPACK manager: undo all
changes and rebuild all packages so that they work again as intended.
-- 
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-32-20200904.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

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

Re: Is s390 (32-bit) relevant for Fedora alt arch ?

[Dan Horák]

On Fri, 4 Sep 2020 10:00:11 +0100
Daniel P. Berrangé  wrote:

> I'm looking at cleaning up some parts of the QEMU spec and we have
> conditionals in there testing for s390 arch (aka 32-bit). IIRC it
> was previously a secondary arch, at least back in the Fedora 22-ish
> timeframe. I'm not seeing it listed in the alternative arch list
> currently though:
> 
>   https://fedoraproject.org/wiki/Architectures
> 
> Am I right in concluding that 's390' does not need to be considered in
> RPM spec files now, and thus we can purge any 's390' arch checks ?

that's correct, Fedora doesn't support s390 (32-bit) in any way for
some time, seems F-25 was the last with s390 support.


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

Is s390 (32-bit) relevant for Fedora alt arch ?

[Daniel P . Berrangé]

I'm looking at cleaning up some parts of the QEMU spec and we have
conditionals in there testing for s390 arch (aka 32-bit). IIRC it
was previously a secondary arch, at least back in the Fedora 22-ish
timeframe. I'm not seeing it listed in the alternative arch list
currently though:

  https://fedoraproject.org/wiki/Architectures

Am I right in concluding that 's390' does not need to be considered in
RPM spec files now, and thus we can purge any 's390' arch checks ?

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New segfault with flexiblas/openblaso

[Iñaki Ucar]

Hi,

Strange... Let me bring this upstream to see whether this is
flexiblas' or openblas' fault. In the meanwhile, exporting
FLEXIBLAS=netlib before the tests makes use of the reference
implementation, so everything should be slower but safer. And if this
starts happening in the wild, we can change to openblas-serial with a
quick update of FlexiBLAS.

Iñaki

On Fri, 4 Sep 2020 at 05:50, Orion Poplawski  wrote:
>
> It looks like with the flexiblas enabled octave, octave-statistics now
> has a segfault in one of its tests:
>
> https://koschei.fedoraproject.org/package/octave-statistics?collection=f34
>
>canoncorr.m .
> RPM build errors:
> /var/tmp/rpm-tmp.PZIGXq: line 33: 915255 Segmentation fault  (core
> dumped)
>
> Looks like flexiblas defaults to the openmp version of openblas.  If I
> switch to the serial version, the segfault goes away:
>
> FLEXIBLAS=/lib64/libopenblas.so octave -H -q --no-window-system
> --no-site-file --eval
> 'pkg("local_list",fullfile("/home/orion/rpmbuild/BUILDROOT/octave-statistics-1.4.1-6.fc34.x86_64/usr/share/octave","octave_packages"));pkg("load","statistics");test("/home/orion/rpmbuild/BUILDROOT/octave-statistics-1.4.1-6.fc34.x86_64/usr/share/octave/packages/statistics-1.4.1/canoncorr.m");'
> OpenJDK 64-Bit Server VM warning: Archived non-system classes are
> disabled because the java.system.class.loader property is specified
> (value = "org.octave.OctClassLoader"). To use archived non-system
> classes, this property must be not be set
> PASSES 7 out of 7 tests
>
>
> FLEXIBLAS=/lib64/libopenblaso.so octave -H -q --no-window-system
> --no-site-file --eval
> 'pkg("local_list",fullfile("/home/orion/rpmbuild/BUILDROOT/octave-statistics-1.4.1-6.fc34.x86_64/usr/share/octave","octave_packages"));pkg("load","statistics");test("/home/orion/rpmbuild/BUILDROOT/octave-statistics-1.4.1-6.fc34.x86_64/usr/share/octave/packages/statistics-1.4.1/canoncorr.m");'
> OpenJDK 64-Bit Server VM warning: Archived non-system classes are
> disabled because the java.system.class.loader property is specified
> (value = "org.octave.OctClassLoader"). To use archived non-system
> classes, this property must be not be set
> Segmentation fault (core dumped)
>
>
> Thread 1 "octave-cli-5.2." received signal SIGSEGV, Segmentation fault.
> 0x70f1eb19 in dsyrk_thread_UT (args=0x7fff8db0, range_m=0x0,
> range_n=0x0, sa=0x7fffb4d31000, sb=0x7fffb4e31000, mypos=0) at
> level3_syrk_threaded.c:508
> 508 int CNAME(blas_arg_t *args, BLASLONG *range_m, BLASLONG
> *range_n, FLOAT *sa, FLOAT *sb, BLASLONG mypos){
> (gdb) bt
> #0  0x70f1eb19 in dsyrk_thread_UT (args=0x7fff8db0,
> range_m=0x0, range_n=0x0, sa=0x7fffb4d31000, sb=0x7fffb4e31000, mypos=0)
> at level3_syrk_threaded.c:508
> #1  0x70e2152f in dsyrk_ (UPLO=, TRANS= out>, N=, K=, alpha=,
> a=, ldA=0x7fff8ef0, beta=0x7fff8f20,
> c=0x55f1faa0,
>  ldC=0x7fff8ed8) at syrk.c:370
> #2  0x767ac436 in _Z5xgemmRK6MatrixS1_15blas_trans_typeS2_
> (a=..., b=..., transa=blas_trans, transb=blas_no_trans) at
> liboctave/array/Array.h:582
> #3  0x775336ee in oct_binop_trans_mul (a1=..., a2=...) at
> libinterp/octave-value/ov-re-mat.cc:145
> #4  0x7781ab44 in do_binary_op (ti=...,
> op=octave_value::op_herm_mul, v1=..., v2=...) at
> libinterp/octave-value/ov.cc:2407
>
>
> (gdb) list
> 503 #endif
> 504
> 505   return 0;
> 506 }
> 507
> 508 int CNAME(blas_arg_t *args, BLASLONG *range_m, BLASLONG
> *range_n, FLOAT *sa, FLOAT *sb, BLASLONG mypos){
> 509
> 510   blas_arg_t newarg;
> 511
> 512 #ifndef USE_ALLOC_HEAP
> (gdb) up
> #1  0x70e2152f in dsyrk_ (UPLO=, TRANS= out>, N=, K=, alpha=,
> a=, ldA=0x7fff8ef0, beta=0x7fff8f20,
> c=0x55f1faa0,
>  ldC=0x7fff8ed8) at syrk.c:370
> 370 (syrk[4 | (uplo << 1) | trans ])(, NULL, NULL, sa, sb, 0);
> (gdb) up
> #2  0x767ac436 in _Z5xgemmRK6MatrixS1_15blas_trans_typeS2_
> (a=..., b=..., transa=blas_trans, transb=blas_no_trans) at
> liboctave/array/Array.h:582
> 582   const T * data (void) const { return slice_data; }
> (gdb) print a
> $1 = (const class Matrix &) @0x7fff9020: { =
> {> = {> = {_vptr.Array = 0x77f95750
> , dimensions = {rep = 0x55f04180}, rep =
> 0x55f45dc0,
>  slice_data = 0x55f07200, slice_len = 20},  fields>}, }, }
> (gdb) print b
> $2 = (const class Matrix &) @0x7fff8ff0: { =
> {> = {> = {_vptr.Array = 0x77f95750
> , dimensions = {rep = 0x55f04180}, rep =
> 0x55f45dc0,
>  slice_data = 0x55f07200, slice_len = 20},  fields>}, }, }
>
>
> I'm not quite sure where to start here...
>
> Orion
>
>
> --
> 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/
>


-- 
Iñaki Úcar

Re: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)

[Kamil Paral]

On Fri, Sep 4, 2020 at 6:17 AM John Reiser  wrote:

> On 2020-09-01 at 12:13 UTC, Kamil Paral wrote:
> [[snip]]
> >  I'd like to ... hugely speed up the installation instead
> [[snip]]
>
> Zstd is faster than xz at de-compression, but a much larger speed
> improvement
> would be to parallelize and pipeline "rpm --install".  This would benefit
> both install and the creation of 'mock' build environments.
>

Yes, but that's not what this enhancement is about. Also it would have no
effect on Live image installation. Let's not distract this discussion with
independent topics, rather let's discuss this particular proposal.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org