date:20200325

On Wed, Mar 25, 2020 at 9:24 PM Jerry James  wrote:
> You'll want to view this with a fixed-width font.

Thank you, gmail, for completely destroying my formatting work.  Oh
well, you can probably tell what I was trying to do.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Coq build issues in F32

On Wed, Mar 25, 2020 at 4:58 PM Jerry James  wrote:
> Either I got lucky when I launched the Rawhide build, or something is
> fundamentally different between F32 and Rawhide.  Clearly something
> nondeterministic is at work.  I have been unable to reproduce this
> failure in mock so far, but will keep trying.

I did a scratch build in Rawhide, just to see if this morning's
successful build was a fluke.  It succeeded on all architectures:

https://koji.fedoraproject.org/koji/taskinfo?taskID=42770190

So far, 2 out of 2 Rawhide builds succeeded, and 3 out of 3 F32 builds
ended with either a segfault or a bad instruction on at least 1
architecture.  Here are the side-by-side differences in the packages
in the aarch64 buildroots (since aarch64 was one of the failing
architectures on my last attempt), Rawhide on the left, F32 on the
right.  You'll want to view this with a fixed-width font.

adwaita-cursor-theme-3.36.0-1.fc33.noarch
adwaita-cursor-theme-3.36.0-1.fc32.noarch
adwaita-icon-theme-3.36.0-1.fc33.noarch
adwaita-icon-theme-3.36.0-1.fc32.noarch
annobin-9.12-3.fc33.aarch64
annobin-9.06-4.fc32.aarch64
at-spi2-atk-2.34.2-1.fc33.aarch64
at-spi2-atk-2.34.2-1.fc32.aarch64
at-spi2-atk-devel-2.34.2-1.fc33.aarch64
at-spi2-atk-devel-2.34.2-1.fc32.aarch64
at-spi2-core-2.36.0-1.fc33.aarch64
at-spi2-core-2.36.0-1.fc32.aarch64
at-spi2-core-devel-2.36.0-1.fc33.aarch64
at-spi2-core-devel-2.36.0-1.fc32.aarch64
audit-libs-3.0-0.19.20191104git1c2f876.fc33.aarch64
audit-libs-3.0-0.18.20191104git1c2f876.fc32.aarch64
avahi-libs-0.8-2.fc33.aarch64
avahi-libs-0.7-23.fc32.aarch64
binutils-2.34-2.fc33.aarch64
binutils-2.34-2.fc32.aarch64
binutils-gold-2.34-2.fc33.aarch64
binutils-gold-2.34-2.fc32.aarch64
cmake-filesystem-3.17.0-1.fc33.aarch64
cmake-filesystem-3.16.4-1.fc32.aarch64
coreutils-8.32-3.fc33.aarch64
coreutils-8.31-10.fc32.aarch64
coreutils-common-8.32-3.fc33.aarch64
coreutils-common-8.31-10.fc32.aarch64
cpp-10.0.1-0.9.fc33.aarch64
cpp-10.0.1-0.9.fc32.aarch64
crypto-policies-20200312-1.git3ae59d2.fc33.noarch
crypto-policies-20191128-5.gitcd267a5.fc32.noarch
cryptsetup-libs-2.3.1-1.fc33.aarch64
cryptsetup-libs-2.3.0-1.fc32.aarch64
curl-7.69.0-2.fc33.aarch64
curl-7.69.1-1.fc32.aarch64
cyrus-sasl-lib-2.1.27-4.fc33.aarch64
cyrus-sasl-lib-2.1.27-3.fc32.aarch64
dbus-1:1.12.16-5.fc33.aarch64
dbus-1:1.12.16-4.fc32.aarch64
dbus-broker-22-1.fc33.aarch64
dbus-broker-22-1.fc32.aarch64
dbus-common-1:1.12.16-5.fc33.noarch
dbus-common-1:1.12.16-4.fc32.noarch
dbus-devel-1:1.12.16-5.fc33.aarch64
dbus-devel-1:1.12.16-4.fc32.aarch64
dbus-libs-1:1.12.16-5.fc33.aarch64
dbus-libs-1:1.12.16-4.fc32.aarch64
dejavu-sans-fonts-2.37-7.fc33.noarch
dejavu-sans-fonts-2.37-7.fc32.noarch
fedora-gpg-keys-33-0.3.noarch
fedora-gpg-keys-32-0.7.noarch
fedora-release-33-0.3.noarch
fedora-release-32-0.8.noarch
fedora-release-common-33-0.3.noarch
fedora-release-common-32-0.8.noarch
fedora-repos-33-0.3.noarch
fedora-repos-32-0.7.noarch
fedora-repos-rawhide-33-0.3.noarch
file-5.38-3.fc33.aarch64
file-5.38-2.fc32.aarch64
file-libs-5.38-3.fc33.aarch64
file-libs-5.38-2.fc32.aarch64
fontconfig-2.13.92-8.fc33.aarch64
fontconfig-2.13.92-8.fc32.aarch64
fontconfig-devel-2.13.92-8.fc33.aarch64
fontconfig-devel-2.13.92-8.fc32.aarch64
fonts-filesystem-2.0.3-1.fc33.noarch
fonts-filesystem-2.0.3-1.fc32.noarch
fonts-srpm-macros-2.0.3-1.fc33.noarch
fonts-srpm-macros-2.0.3-1.fc32.noarch
fribidi-1.0.9-1.fc33.aarch64
fribidi-1.0.9-1.fc32.aarch64
fribidi-devel-1.0.9-1.fc33.aarch64
fribidi-devel-1.0.9-1.fc32.aarch64
gcc-10.0.1-0.9.fc33.aarch64
gcc-10.0.1-0.9.fc32.aarch64
gdb-minimal-9.1-4.fc33.aarch64
gdb-minimal-9.1-3.fc32.aarch64
ghostscript-9.50-1.fc33.aarch64
ghostscript-9.50-1.fc32.aarch64
ghostscript-core-9.50-1.fc33.aarch64
ghostscript-core-9.50-1.fc32.aarch64
ghostscript-tools-fonts-9.50-1.fc33.aarch64
ghostscript-tools-fonts-9.50-1.fc32.aarch64
ghostscript-tools-printing-9.50-1.fc33.aarch64
ghostscript-tools-printing-9.50-1.fc32.aarch64
glib-networking-2.64.0-1.fc33.aarch64
glib-networking-2.64.0-1.fc32.aarch64
glib2-2.64.1-1.fc33.aarch64
glib2-2.64.1-1.fc32.aarch64
glib2-devel-2.64.1-1.fc33.aarch64
glib2-devel-2.64.1-1.fc32.aarch64
glibc-2.31.9000-4.fc33.aarch64
glibc-2.31-1.fc32.aarch64
glibc-common-2.31.9000-4.fc33.aarch64
glibc-common-2.31-1.fc32.aarch64
glibc-devel-2.31.9000-4.fc33.aarch64
glibc-devel-2.31-1.fc32.aarch64
glibc-headers-2.31.9000-4.fc33.aarch64
glibc-headers-2.31-1.fc32.aarch64
glibc-minimal-langpack-2.31.9000-4.fc33.aarch64
glibc-minimal-langpack-2.31-1.fc32.aarch64
gmp-1:6.2.0-1.fc33.aarch64
gmp-1:6.1.2-13.fc32.aarch64
google-droid-sans-fonts-20200215-3.fc33.noarch
google-droid-sans-fonts-20200215-3.fc32.noarch
google-roboto-slab-fonts-1.100263-0.12.20150923git.fc33.noarch
google-roboto-slab-fonts-1.100263-0.11.20150923git.fc32.noarch
groff-base-1.22.3-24.fc33.aarch64
groff-base-1.22.3-21.fc32.aarch64
gsettings-desktop-schemas-3.36.0-1.fc33.aarch64
gsettings-desktop-schemas-3.36.0-1.fc32.aarch64
gtk-update-icon-cache-3.24.14-1.fc33.aarch64

Re: Coq build issues in F32

On Wed, Mar 25, 2020 at 8:57 PM Paul Dufresne via devel
 wrote:
> ... yeah, I know, might have no link at all with your Coq build... I
> don't know.

Maybe ... but that sure is suspicious.  I recall hearing that OpenJDK
is also suffering from weird segfaults.  H.

Thanks for the input, Paul.  I'll keep investigating.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Coq build issues in F32

2020-03-25 Thread Paul Dufresne via devel

Le Wed, 25 Mar 2020 16:58:33 -0600,
Jerry James  a écrit :
> Either I got lucky when I launched the Rawhide build, or something is
> fundamentally different between F32 and Rawhide.  Clearly something
> nondeterministic is at work.  I have been unable to reproduce this
> failure in mock so far, but will keep trying.
> 
> If anybody has any ideas, I am all ears.  Thank you,

Well... It ring a bell for me, because I kind of seeing what seems to
be weird bugs in F32... I am kind of suspecting a gcc bug giving some
weird things... but I am not a developer, know a bit of assembler but
not enough to make the link between C code and assembler.

Anyway, one hour a go, I got a segment violation error while doing
updates with dnfdragora... and it seems that the code just jump to a
low address outside of the program:
rh bug #1817269

The other bug that make me suspect something might be wrong with gcc
was a bug that make a segment violation (seems to access a bit lower
address than a .png font file) in a game package that have not been
updated in many years as far as I know:
rh bug #1816471
but in that case, frankly the C code seems a bit hard for me to take
time to try to understand it.

What puzzle me in this case, is why a very old code would have stop to
work... that's why I came to the idea that maybe this is the generated
code itself that changed.

... yeah, I know, might have no link at all with your Coq build... I
don't know.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1814917] perl-Net-GitHub-0.99 is available

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Net-GitHub-0.98 is |perl-Net-GitHub-0.99 is
   |available   |available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 0.99
Current version/release in rawhide: 0.97-1.fc33
URL: http://search.cpan.org/dist/Net-GitHub/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/3150/

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

[Bug 1817266] New: perl-Log-Any-Adapter-Callback-0.101 is available

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

Bug ID: 1817266
   Summary: perl-Log-Any-Adapter-Callback-0.101 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Log-Any-Adapter-Callback
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.101
Current version/release in rawhide: 0.100-3.fc33
URL: https://metacpan.org/release/Log-Any-Adapter-Callback

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/17925/

-- 
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: Help needed to get dependencies in EPEL 8 for pagure

On Sat, Mar 21, 2020 at 3:41 AM Neal Gompa  wrote:
>
> On Sat, Feb 22, 2020 at 11:57 PM Neal Gompa  wrote:
> >
> > On Sat, Feb 8, 2020 at 9:59 PM Neal Gompa  wrote:
> > >
> > > Hey all,
> > >
> > > I've been trying to get Pagure into EPEL 8 for a couple of months now
> > > so that we can upgrade our Pagure instances to RHEL 8[1].
> > >
> > > Thankfully, most of Pagure's dependencies *are* now present in EPEL 8,
> > > so there's only a few that need to be added.
> > >
> >
> > So, an update: after this most recent push, most of Pagure's
> > dependencies are now in EPEL 8.
> >
> > We're still missing celery...
> >
>
> Celery is now in EPEL 8, so we're good here now!
>
> >
> > And we're still missing pygit2...
> >
> > > * python-pygit2: pwalter
> > ...
> > > A note here: RHEL 8 ships libgit2 0.26.8, so we need pygit2 0.26.x.
>
> And now pygit2 is the only remaining missing dependency! We're nearly
> to the finish line!
>

And now it's all done, with Pagure 5.9.0 landing in EPEL 8:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a504acc25e

Thanks to everyone who helped make this happen!



-- 
真実はいつも一つ！/ 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: Help needed to get dependencies in EPEL 8 for pagure

On Sat, Mar 21, 2020 at 3:41 AM Neal Gompa  wrote:
>
> On Sat, Feb 22, 2020 at 11:57 PM Neal Gompa  wrote:
> >
> > On Sat, Feb 8, 2020 at 9:59 PM Neal Gompa  wrote:
> > >
> > > Hey all,
> > >
> > > I've been trying to get Pagure into EPEL 8 for a couple of months now
> > > so that we can upgrade our Pagure instances to RHEL 8[1].
> > >
> > > Thankfully, most of Pagure's dependencies *are* now present in EPEL 8,
> > > so there's only a few that need to be added.
> > >
> >
> > So, an update: after this most recent push, most of Pagure's
> > dependencies are now in EPEL 8.
> >
> > We're still missing celery...
> >
>
> Celery is now in EPEL 8, so we're good here now!
>
> >
> > And we're still missing pygit2...
> >
> > > * python-pygit2: pwalter
> > ...
> > > A note here: RHEL 8 ships libgit2 0.26.8, so we need pygit2 0.26.x.
>
> And now pygit2 is the only remaining missing dependency! We're nearly
> to the finish line!
>

And now it's all done, with Pagure 5.9.0 landing in EPEL 8:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a504acc25e

Thanks to everyone who helped make this happen!



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

Re: Pagure for EL8 (EPEL8)

On Sat, Mar 21, 2020 at 3:42 AM Neal Gompa  wrote:
>
> On Sat, Feb 22, 2020 at 11:50 PM Neal Gompa  wrote:
> >
> > On Mon, Nov 18, 2019 at 1:16 PM Neal Gompa  wrote:
> > >
> > > On Mon, Nov 18, 2019 at 11:18 AM Kevin Fenzi  wrote:
> > > >
> > > > On Sat, Nov 16, 2019 at 05:37:16PM -0500, Neal Gompa wrote:
> > > > > I've done an early build locally to determine what's needed to make
> > > > > this possible. The following report from DNF indicates the missing
> > > > > packages that need to be added to EPEL 8 before I can introduce Pagure
> > > > > into EPEL8:
> > > > >
> > > > >  Problem 1: conflicting requests
> > > > >   - nothing provides python3-jenkins needed by 
> > > > > pagure-ci-5.8-1.el8.noarch
> > > > >  Problem 2: conflicting requests
> > > > >   - nothing provides gitolite3 needed by pagure-5.8-1.el8.noarch
> > > > >   - nothing provides python3.6dist(binaryornot) needed by
> > > > > pagure-5.8-1.el8.noarch
> > > > >   - nothing provides python3.6dist(celery) needed by 
> > > > > pagure-5.8-1.el8.noarch
> > > > >   - nothing provides python3.6dist(flask-wtf) needed by 
> > > > > pagure-5.8-1.el8.noarch
> > > > >   - nothing provides python3.6dist(redis) needed by 
> > > > > pagure-5.8-1.el8.noarch
> > > > >   - nothing provides python3.6dist(straight.plugin) needed by
> > > > > pagure-5.8-1.el8.noarch
> > > > >   - nothing provides python3.6dist(wtforms) needed by 
> > > > > pagure-5.8-1.el8.noarch
> > > > >   - nothing provides python3.6dist(pygit2) >= 0.26.0 needed by
> > > > > pagure-5.8-1.el8.noarch
> > > > >  Problem 3: conflicting requests
> > > > >   - nothing provides python3-trololio needed by 
> > > > > pagure-ev-5.8-1.el8.noarch
> > > > >
> > > > > One of the reasons I'd like to have this done sooner rather than later
> > > > > is so that we can drop Python 2 support from Pagure with version 6.0.
> > > > > I think it's quite reasonable to say that version 6.0 isn't going to
> > > > > happen until we can get our Pagure servers running on EL8 using Python
> > > > > 3.
> > > > >
> > > > > So now, I need some help making this happen. I already own trololio,
> > > > > and I'm going to make that available in EPEL 8 ASAP. Can anyone help
> > > > > with some of the other dependencies here?
> > > >
> > > > Can you give a list with maintainers? I'm not sure off hand how many of
> > > > those are maintained by me/infra-sig, but any I can I would be happy to
> > > > add in. There's a few that are in testing I think already...
> > > >
> > >
> > > Sure, here's a list so far (package: maintainer):
> > >
> > > * gitolite3: limb
> > > * python-jenkins: cottsay
> > > * python-binaryornot: pingou
> > > * python-celery: bowlofeggs
> > > * python-flask-wtf: pingou
> > > * python-redis: kevin
> > > * python-straight-plugin: pingou
> > > * python-wtforms: kumarpraveen
> > > * python-pygit2: pwalter
> > > * python-trololio: ngompa
> > >
> > > I've already got trololio going:
> > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6c443851dd
> > >
> >
> > So an update on this...
> >
> > We're now only missing two dependencies:
> >
> > * python-celery: abompard
> > * python-pygit2: pwalter
> >
> > The rest of them are now in EPEL 8.
> >
>
> We're now only missing python-pygit2, as celery just landed in EPEL 8.
>

And now it's all done, with Pagure 5.9.0 landing in EPEL 8:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a504acc25e

Thanks to everyone who helped make this happen!


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

Coq build issues in F32

I've been talking to Richard Jones about this privately, and he
suggested that a message to fedora-devel could be helpful.

I've been talking for weeks about updating the entire coq stack,
badgering people into swapping reviews with me, etc.  Today I finally
had all the bits in place to do the updates.  I built the whole stack
for Rawhide with no issues.

The same builds need to happen for F32, where parts of the stack
currently have broken deps.  But I can't get coq to build
successfully, even though it did in Rawhide.  It went like this:

Attempt 1: the x86_64 build segfaulted while running "bin/coqc -coqlib . -q
-native-compiler yes   theories/FSets/FMapFullAVL.v", where coqc is a
binary built from the coq sources.  Coq is a theorem prover.  The coqc
run is essentially checking that a series of proof steps indeed prove
a theorem.  The "-native-compiler yes" part means that the OCaml
compiler will be invoked to generate native code for parts of this
process.

I was puzzled by the segfault.  I decided to see if the segfault is
deterministic, so I launched...

Attempt 2: the x86_64 build succeeded.  The s390x build failed with an
illegal instruction error while running *the same command*.

Attempt 3: The s390x build again failed with an illegal instruction
error while running the same command, and aarch64 segfaulted while
running the same command.  All other arches succeeded.  I saved the
URL for this one:

https://koji.fedoraproject.org/koji/taskinfo?taskID=42768075

Either I got lucky when I launched the Rawhide build, or something is
fundamentally different between F32 and Rawhide.  Clearly something
nondeterministic is at work.  I have been unable to reproduce this
failure in mock so far, but will keep trying.

If anybody has any ideas, I am all ears.  Thank you,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Pinging spin or labs maintainers in failed composes tickets


On 25. 03. 20 21:51, Mohan Boddu wrote:

Hi all,

As discussed in the spins list [1], we are adding the ability to ping
maintainers of spins or labs in compose failure tickets [2]. I made a
list of maintainers [3] from the existing kickstart files, please
create PR's to fedora-kickstarts repo [4] if any changes are needed to
the list.

We are hoping that it will be very helpful to all the spins, labs and
any other variant maintainers to get notified if they image build
failed and provides an easy way to find and debug the issue.


This sounds great. How would I add myself for the Python Classroom Lab? E.g. 
what should I call the TOML section for that?


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

[Bug 1815682] perl-Module-CoreList-5.20200320 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-88b16e03ec has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-88b16e03ec`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-88b16e03ec

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.

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

[389-devel] Reminder: please review: PR 50982 - Revise UI branding

2020-03-25 Thread Mark Reynolds



On 3/24/20 12:14 PM, Mark Reynolds wrote:

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


--

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

[389-devel] please review: PR 50983 - Fix memory leaks with indirect COS searches

2020-03-25 Thread Mark Reynolds


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

--

389 Directory Server Development Team
___
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

Pinging spin or labs maintainers in failed composes tickets

2020-03-25 Thread Mohan Boddu

Hi all,

As discussed in the spins list [1], we are adding the ability to ping
maintainers of spins or labs in compose failure tickets [2]. I made a
list of maintainers [3] from the existing kickstart files, please
create PR's to fedora-kickstarts repo [4] if any changes are needed to
the list.

We are hoping that it will be very helpful to all the spins, labs and
any other variant maintainers to get notified if they image build
failed and provides an easy way to find and debug the issue.

Thanks,
Mohan Boddu
Fedora Release Engineering.

[1] 
https://lists.fedoraproject.org/archives/list/sp...@lists.fedoraproject.org/thread/K5VFSTEBBQUGNBFPBDTEQJ6HWESTLMWG/
[2] https://pagure.io/releng/failed-composes/issues
[3] https://pagure.io/fedora-kickstarts/blob/master/f/maintainers.toml
[4] https://pagure.io/fedora-kickstarts/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Thursday's FPC Meeting (2020-03-26 16:00 UTC)

2020-03-25 Thread James Antill

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

 Local time information (via. uitime):

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


 Links to all tickets below can be found at: 

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

= Followups =

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

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

= Pull Requests =

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

#topic #pr-938 Add Package Review Process page 
https://pagure.io/packaging-committee/pull-request/938

= Open Floor = 

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

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

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

2020-03-25 Thread Justin Forbes

On Wed, Mar 25, 2020 at 1:00 PM Nicolas Mailhot via devel
 wrote:
>
> Le mercredi 25 mars 2020 à 17:33 +0100, Aleksandra Fedorova a écrit :
>
> > My point was to highlight that ELN is not a "stable edition" like
> > Fedora Server. ELN is Rawhide, its quality is no better than Rawhide
> > quality, its stability is Rawhide stability, its target audience is
> > Rawhide audience.
>
> Ok, then if I may play the devil’s advocate. Why is it not Rawhide? Are
> @rh fixes so valueless you wouldn’t want them in Fedora itself? Are
> community contributors so scary it is not possible to find
> accocmodations with them?
>

I don't see this as the case at all. I think the point here is all of
those fixes have to be put in through rawhide. One major reason on why
it is not rawhide is because it won't run on the average Fedora
system. Remember that conversation about build flags last year? AVX2
and similar minimum baselines? Enterprise doesn't have to run on 10
year old hardware. They can set new baselines for every release. Once
they are set, that version will support those baselines for years, but
the next version may not support the same baseline.  Fedora does
support older systems, and as you might recall from that thread, it
seems a good 70% of current Fedora systems would not support such new
baselines.  ELN is rawhide, or at least a subset of rawhide, but the
build flags are optimized for a different type of system.

> I *think* ELN comes from good intentions. Just like modularity came
> from good intentions. Just like Centos stream came from good
> intentions. That beind said, good intentions are not enough for a
> proposal to succeed.
>
> The core problem (root cause in ITIL speak) is that years of EL
> balkanization Centos and RHEL side, with little Fedora involvment, and
> a dearth of clear upstream/downstream  ground rules, completely tore
> down the upstream to downstream packaging pipeline. And that
> modularity, didn’t make the situation any better. Which leaves EL with
> a huge upstream problem.
>
> Fedora itself has no such problem, except for the experimental not-
> quite-releases Adam ranted about a few days ago. Rawhide → stable →
> stable - 1. KISS and effective (as long as you do not get into EPEL
> land, but that’s not due to the Fedora part of the equation). That’s
> why the *community*, by and large, has been thoroughly unimpressed by
> the attempts to convert Fedora into the same hodgepole of ill-defined
> overlapping package fiefdoms/streams.
>
> So, before we go full charge ahead on technical solutions, without
> considering the social challenges (that did not work so well before),
> could those proposals come with a clear package lifecycle graph, from
> Rawhide to Fedora to ELN to stream to EPEL to whatever? And answer the
> following questions:
>
> 1. I want  available on my own non-production system
> (and the systems of my friends), at what point of the lifecycle graph
> should I contribute? ( end user)
>
> 2. I want  available on my own production system (that I
> maintain without @rh help), at what point of the lifecycle graph should
> I contribute? ( work user)
>
> 3. I want  available on my own production system, but I
> don’t want to maintain it myself, and @rh does not include  software> in RHEL/Centos, where should I contract the packaging work
> (I’m not a software house but I’m rich enough to sponsor the packaging
> of a few pieces). ( corp user)
>
> 4. I want my own  to be distributed widely, at what
> point of the lifecycle graph can I help advancing things?  software> creator)
>
> You can add other reasons to do community packaging work in Fedora if I
> missed one.
>
> The point is, *community* work, need to be rewarded one way or another.
> And the only thing you can reward community work with, is shipping the
> result of this work somewhere. So, all those new proposals, without
> clear commitments on shipping the result somewhere the contributor can
> make use of it, are quite disturbing.
>

I think there can be multiple wins here for Fedora. RHEL developers
paying more attention to Fedora should work out well.  For users who
have capable systems, there may be some advantage to running a hybrid
Rawhide/ELN system.  This can be done without having releases and
installable media. It just takes a bit of additional dnf configuration
(I am assuming the priority option still works on repositories).  At
least the theory was performance would be better with the higher
baseline. Now, none of this does anything to support Fedora stable
releases yet, but it does give us a place to test and see if such an
effort would be worthwhile.

> A picture is worth a thousand words. Please draw us what you are
> attempting to achieve. That will make it so much easier for everyone
> here to understand it.
>
> And you can say “it’s only for @rh employees”. But that’s giving up on
> making Fedora work as a community project.
>
> Regards,
>
> --
> Nicolas Mailhot
>

[EPEL-devel] Re: Default bookmarks under RHEL8

2020-03-25 Thread Leon Fauster


Am 25.03.20 um 19:32 schrieb Dmitry Butskoy:

Stephen John Smoogen wrote:



On Wed, 25 Mar 2020 at 14:10, Dmitry Butskoy > wrote:


    Could anybody answer please which package provides:
    > /usr/share/bookmarks/default-bookmarks.html
    under RHEL8 ?


I don't see anything providing it in EL8


Then I don't understand how Firefox is built under EL8, since it has 
"BuildRequires: system-bookmarks", but EL8 do not have such a package...


Maybe some third-party repo ar build time?




If you need it, make a request:

https://lists.centos.org/pipermail/centos-devel/2020-March/036644.html

after this process the package would be in the "Devel" repo:

# dnf config-manager --enable Devel

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

2020-03-25 Thread James Cassell


On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote:
> 
> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
> > Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
> >>
[snip]
> >> We can come up with guidelines, for example:
> >>
> >> 1) Try to find a way to resolve the issue without any conditionals first.
> >>
> >> There should be a reason why package X needs a dependency Y in Fedora
> >> and there should be a reason why it is a required dependency and not a
> >> recommended one. So why in that case downstream wants it differently?
> >> The first approach is just to talk through it. I can assume cases
> >> where downstream adds a dependency, as well as Fedora package removing
> >> them.
> >>
> >> Note that bloated dependency trees is a common problem for all binary
> >> distributions, it is not an "EL-thing" and we can work on that
> >> together.
> >>
> >> Nicolas has pointed out to another reason why we would get
> >> EL-conditionals: the outdated rpm stack in RHEL. But we don't have
> >> this problem with ELN, as we are building Rawhide, and rpm stack is
> >> going to be the Rawhide rpm stack as well.
> >>
> >> 2) Minimize and isolate the conditional, and track the reason.
> >>
> >> As ELN SIG we need to have a place where we collect known reasons for
> >> such conditionals. The overall goal is to reduce this set, not to grow
> >> indefinitely. As Stephen said we expect it to be about couple of
> >> hundred packages. We will be able to track each one of them. (We have
> >> rpminspect to run package diffs for us).
> >>
> >> 3) In complex cases - bring it to community and FESCo.
> >>
> >> We don't know what those complex cases might be, one of the goals is
> >> to find them. So we keep it as an option to bring individual case to a
> >> wider audience. To ask for help and to decide on it.
> >>
> > It seems there are missing real life examples of what we sometimes do in
> > RHEL, so please see attached patch. This patch is coming from RHEL
> > version of the espeak-ng. Now somebody tell me what it does for what
> > purpose and which scenario from the above three should be applied here.
> >
> >
> > Vít
> >
> 
> And here is another example for the curious.
> 

Both of these examples have to do with docs generation and trying to reduce 
dependencies for that process. "Process the man page using kramdown and remove 
the ronn dependency."

(So you don't have to open the attachments yourself.)

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

[Bug 1817204] New: perl-Search-Elasticsearch-6.80 is available

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

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



Latest upstream release: 6.80
Current version/release in rawhide: 6.00-8.fc32
URL: http://search.cpan.org/dist/Search-Elasticsearch/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/10543/

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

[EPEL-devel] Re: Default bookmarks under RHEL8

2020-03-25 Thread Yaakov Selkowitz

On Wed, 2020-03-25 at 21:32 +0300, Dmitry Butskoy wrote:
> Stephen John Smoogen wrote:
> > 
> > On Wed, 25 Mar 2020 at 14:10, Dmitry Butskoy  > > wrote:
> > 
> > Could anybody answer please which package provides:
> > > /usr/share/bookmarks/default-bookmarks.html
> > under RHEL8 ?
> > 
> > I don't see anything providing it in EL8
> 
> Then I don't understand how Firefox is built under EL8, since it has 
> "BuildRequires: system-bookmarks", but EL8 do not have such a package...

The package is not shipped, but (like others in RHEL8 not shipped in
CodeReady Builder) exists internally to fulfill the BuildRequires.

> Maybe some third-party repo ar build time?

RHEL packages are not built with third-party dependencies.

-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

Le mercredi 25 mars 2020 à 14:19 -0400, Neal Gompa a écrit :
> On Wed, Mar 25, 2020 at 2:16 PM Miro Hrončok 
> wrote:
> > On 25. 03. 20 19:10, Stephen Gallagher wrote:
> > > In general, very few packages should even need conditionalizing
> > > at
> > > all; that's why I've been saying that this discussion is
> > > premature.
> > 
> > Most of the Python packages we maintain in RHEL would need
> > conditionalizing to
> > disable (part of) tests or docs.
> > 
> 
> Disabling regeneration of documentation I get, but why would you
> disable running the tests? That stuff is important to ensure the
> packages aren't broken as you maintain them, patch them, etc.

Unfortunately, a lot of upstream testing code is poorly written and
maintained, and will do all kinds of horrors: using legally uncumbered
deps, attempting to reconfigure the system as root (because
containers), testing downstream users (creating dependency loops),
testing things you configured away, testing things that were removed
from the main code long ago (but their usnit tests lingers), requiring
a deep dependency tree to test trivial things, etc

Sometimes the only reason it “works” upstream is that upstream stopped
maintaining it and the same unchanging config is tested in a loop all
year round to feed lots of meaningless green lines to hosting service
and the author’s PHB.

As a result, the test suite may be more hassle to package and maintain
than the software it tests (and, with little to show for all this
bother).

Regards,
 

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


On 25. 03. 20 19:19, Neal Gompa wrote:

On Wed, Mar 25, 2020 at 2:16 PM Miro Hrončok  wrote:

On 25. 03. 20 19:10, Stephen Gallagher wrote:

In general, very few packages should even need conditionalizing at
all; that's why I've been saying that this discussion is premature.

Most of the Python packages we maintain in RHEL would need conditionalizing to
disable (part of) tests or docs.


Disabling regeneration of documentation I get, but why would you
disable running the tests? That stuff is important to ensure the
packages aren't broken as you maintain them, patch them, etc.


Mostly because there are missing test dependencies. That's why we disable (some) 
tests. For example I have packages that cannot be tested in RHEL buildroot, but 
I test them locally by building them in EPEL mock --with tests. If even EPEL 
isn't enough, I install packages from PyPI via pip to my mock buidroot and than 
build with %check enabled but without the problematic test BuildRequires.


Take for example python-pip (snippet from rawhide, added notes):

%if %{with tests}
BuildRequires:  python%{python3_pkgversion}-mock  # PowerTools
BuildRequires:  python%{python3_pkgversion}-pytest  # AppStream
BuildRequires:  python%{python3_pkgversion}-pretend  # EPEL
BuildRequires:  python%{python3_pkgversion}-freezegun  # EPEL
BuildRequires:  python%{python3_pkgversion}-scripttest  # missing
BuildRequires:  python%{python3_pkgversion}-virtualenv  # AppStream
BuildRequires:  python%{python3_pkgversion}-werkzeug  # AppStream
BuildRequires:  python%{python3_pkgversion}-pyyaml  # BaseOS
%endif

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

2020-03-25 Thread Robbie Harwood

Neal Gompa  writes:

> Miro Hrončok  wrote:
>> Stephen Gallagher wrote:
>>
>>> In general, very few packages should even need conditionalizing at
>>> all; that's why I've been saying that this discussion is premature.
>>
>> Most of the Python packages we maintain in RHEL would need conditionalizing 
>> to
>> disable (part of) tests or docs.
>>
>
> Disabling regeneration of documentation I get, but why would you
> disable running the tests? That stuff is important to ensure the
> packages aren't broken as you maintain them, patch them, etc.

Typically because test dependencies aren't included in the
distribution.  They don't get ignored, but they're not run at RPM build
time.

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

Fedora-32-20200325.n.0 compose check report

No missing expected images.

Failed openQA tests: 3/171 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-32-20200324.n.0):

ID: 556197  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/556197
ID: 556260  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/556260

Old failures (same test failed in Fedora-32-20200324.n.0):

ID: 556181  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/556181
ID: 556194  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/556194

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

Old soft failures (same test soft failed in Fedora-32-20200324.n.0):

ID: 556115  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/556115
ID: 556116  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/556116
ID: 556120  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/556120
ID: 556124  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/556124
ID: 556127  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/556127
ID: 556128  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/556128
ID: 556150  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/556150
ID: 556173  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/556173
ID: 556175  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/556175
ID: 556207  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/556207
ID: 556229  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/556229
ID: 556239  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/556239
ID: 556248  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/556248
ID: 556257  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/556257
ID: 556273  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/556273
ID: 556281  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/556281
ID: 556282  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/556282
ID: 556285  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/556285
ID: 556287  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/556287

Passed openQA tests: 140/171 (x86_64)

New passes (same test not passed in Fedora-32-20200324.n.0):

ID: 556153  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/556153
ID: 556160  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/556160
ID: 556220  Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/556220

Skipped non-gating openQA tests: 10 of 173

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
1 packages(s) added since previous compose: alsa-sof-firmware
1 packages(s) removed since previous compose: systemd-bootchart
1 services(s) added since previous compose: systemd-vconsole-setup.service
Previous test data: https://openqa.fedoraproject.org/tests/555271#downloads
Current test data: https://openqa.fedoraproject.org/tests/556115#downloads

Installed system changes in test x86_64 Server-boot-iso install_default: 
1 packages(s) added since previous compose: alsa-sof-firmware
1 packages(s) removed since previous compose: systemd-bootchart
1 services(s) added since previous compose: systemd-vconsole-setup.service
Previous test data: https://openqa.fedoraproject.org/tests/555272#downloads
Current test data: https://openqa.fedoraproject.org/tests/556116#downloads

Installed system changes in test x86_64 Everything-boot-iso 
install_default@uefi: 
1 packages(s) removed since previous compose: systemd-bootchart
1 services(s) added since previous compose: systemd-vconsole-setup.service
Previous test data: https://openqa.fedoraproject.org/tests/555313#downloads
Current test data: https://openqa.fedoraproject.org/tests/556157#downloads

Installed system changes in test x86_64 Everything-boot-iso install_default: 
1 packages(s) removed since previous compose: systemd-bootchart
1 services(s)

[EPEL-devel] Re: Default bookmarks under RHEL8

2020-03-25 Thread Dmitry Butskoy


Stephen John Smoogen wrote:



On Wed, 25 Mar 2020 at 14:10, Dmitry Butskoy > wrote:


Could anybody answer please which package provides:
> /usr/share/bookmarks/default-bookmarks.html
under RHEL8 ?


I don't see anything providing it in EL8


Then I don't understand how Firefox is built under EL8, since it has 
"BuildRequires: system-bookmarks", but EL8 do not have such a package...


Maybe some third-party repo ar build time?


~buc
___
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: Default bookmarks under RHEL8

2020-03-25 Thread Stephen John Smoogen

On Wed, 25 Mar 2020 at 14:10, Dmitry Butskoy  wrote:

> Could anybody answer please which package provides:
> > /usr/share/bookmarks/default-bookmarks.html
> under RHEL8 ?
>
>
I don't see anything providing it in EL8


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


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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


On 25. 03. 20 18:45, Stephen Gallagher wrote:

Indeed, she recommended that the ideal situation is for us to avoid
conditionals where possible and instead use Recommends: for things
that are not strict requirements. This would benefit Fedora as well,
since people could trim their installs down to their needs.



Technical problem: No BuildRecommends.


Legal problem:

Currently, "broken recommends" (i.e. recommending stuff that isn't in Fedora) is 
forbidden in Fedora for legal reasons:


https://pagure.io/packaging-committee/issue/914#comment-607130

It is also forbidden to recommend something that used to be in Fedora 31 but got 
removed in Fedora 32, from a Fedora 32 package:


https://pagure.io/packaging-committee/issue/914#comment-607154

As far as I understand this, it means it is also forbidden to recommend a 
"Fedora only" package from ELN. Because ELN is a different version than rawhide.


Whether it is allowed to recommend a non-RHEL package from a RHEL package, that 
I don't know, but I assume the same logic applies.



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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

On Wed, Mar 25, 2020 at 2:16 PM Miro Hrončok  wrote:
>
> On 25. 03. 20 19:10, Stephen Gallagher wrote:
> > In general, very few packages should even need conditionalizing at
> > all; that's why I've been saying that this discussion is premature.
>
> Most of the Python packages we maintain in RHEL would need conditionalizing to
> disable (part of) tests or docs.
>

Disabling regeneration of documentation I get, but why would you
disable running the tests? That stuff is important to ensure the
packages aren't broken as you maintain them, patch them, etc.



-- 
真実はいつも一つ！/ 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: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


On 25. 03. 20 19:10, Stephen Gallagher wrote:

In general, very few packages should even need conditionalizing at
all; that's why I've been saying that this discussion is premature.


Most of the Python packages we maintain in RHEL would need conditionalizing to 
disable (part of) tests or docs.


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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

On Wed, Mar 25, 2020 at 2:00 PM Nicolas Mailhot via devel
 wrote:
>
> Le mercredi 25 mars 2020 à 17:33 +0100, Aleksandra Fedorova a écrit :
>
> > My point was to highlight that ELN is not a "stable edition" like
> > Fedora Server. ELN is Rawhide, its quality is no better than Rawhide
> > quality, its stability is Rawhide stability, its target audience is
> > Rawhide audience.
>
> Ok, then if I may play the devil’s advocate. Why is it not Rawhide? Are
> @rh fixes so valueless you wouldn’t want them in Fedora itself? Are
> community contributors so scary it is not possible to find
> accocmodations with them?

Any and all fixes that can apply to Fedora will be applied to Fedora
without conditionals. Period. There are changes that RHEL might make
that Fedora would not like. A fairly common one is to carry
pre-generated documentation instead of rebuilding it in the rpmbuild
so as to avoid having to BuildRequires: the doc tools. Another example
is that RHEL might want to configure the package to build only stable
features where Fedora might also want to enable experimental features.

In general, very few packages should even need conditionalizing at
all; that's why I've been saying that this discussion is premature.

>
> I *think* ELN comes from good intentions. Just like modularity came
> from good intentions. Just like Centos stream came from good
> intentions. That beind said, good intentions are not enough for a
> proposal to succeed.
>
> The core problem (root cause in ITIL speak) is that years of EL
> balkanization Centos and RHEL side, with little Fedora involvment, and
> a dearth of clear upstream/downstream  ground rules, completely tore
> down the upstream to downstream packaging pipeline. And that
> modularity, didn’t make the situation any better. Which leaves EL with
> a huge upstream problem.
>

While I disagree with the hyperbole, I agree that the
upstream-downstream pipeline has become less clear. This is intended
specifically to improve on that.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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] Default bookmarks under RHEL8

2020-03-25 Thread Dmitry Butskoy


Could anybody answer please which package provides:

/usr/share/bookmarks/default-bookmarks.html

under RHEL8 ?


~buc

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

Le mercredi 25 mars 2020 à 17:33 +0100, Aleksandra Fedorova a écrit :

> My point was to highlight that ELN is not a "stable edition" like
> Fedora Server. ELN is Rawhide, its quality is no better than Rawhide
> quality, its stability is Rawhide stability, its target audience is
> Rawhide audience.

Ok, then if I may play the devil’s advocate. Why is it not Rawhide? Are
@rh fixes so valueless you wouldn’t want them in Fedora itself? Are
community contributors so scary it is not possible to find
accocmodations with them?

I *think* ELN comes from good intentions. Just like modularity came
from good intentions. Just like Centos stream came from good
intentions. That beind said, good intentions are not enough for a
proposal to succeed.

The core problem (root cause in ITIL speak) is that years of EL
balkanization Centos and RHEL side, with little Fedora involvment, and
a dearth of clear upstream/downstream ground rules, completely tore
down the upstream to downstream packaging pipeline. And that
modularity, didn’t make the situation any better. Which leaves EL with
a huge upstream problem.

Fedora itself has no such problem, except for the experimental not-
quite-releases Adam ranted about a few days ago. Rawhide → stable →
stable - 1. KISS and effective (as long as you do not get into EPEL
land, but that’s not due to the Fedora part of the equation). That’s
why the *community*, by and large, has been thoroughly unimpressed by
the attempts to convert Fedora into the same hodgepole of ill-defined
overlapping package fiefdoms/streams.

So, before we go full charge ahead on technical solutions, without
considering the social challenges (that did not work so well before),
could those proposals come with a clear package lifecycle graph, from
Rawhide to Fedora to ELN to stream to EPEL to whatever? And answer the
following questions:

1. I want available on my own non-production system
(and the systems of my friends), at what point of the lifecycle graph
should I contribute? ( end user)

2. I want available on my own production system (that I
maintain without @rh help), at what point of the lifecycle graph should
I contribute? ( work user)

3. I want available on my own production system, but I
don’t want to maintain it myself, and @rh does not include in RHEL/Centos, where should I contract the packaging work
(I’m not a software house but I’m rich enough to sponsor the packaging
of a few pieces). ( corp user)

4. I want my own to be distributed widely, at what
point of the lifecycle graph can I help advancing things? creator)

You can add other reasons to do community packaging work in Fedora if I
missed one.

The point is, *community* work, need to be rewarded one way or another.
And the only thing you can reward community work with, is shipping the
result of this work somewhere. So, all those new proposals, without
clear commitments on shipping the result somewhere the contributor can
make use of it, are quite disturbing.

A picture is worth a thousand words. Please draw us what you are
attempting to achieve. That will make it so much easier for everyone
here to understand it.

And you can say “it’s only for @rh employees”. But that’s giving up on
making Fedora work as a community project.

Regards,

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

Fedora 32 compose report: 20200325.n.0 changes

2020-03-25 Thread Fedora Branched Report

OLD: Fedora-32-20200324.n.0
NEW: Fedora-32-20200325.n.0

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

Size of added packages:  23.29 MiB
Size of dropped packages:439.92 KiB
Size of upgraded packages:   2.12 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: golang-github-jsonnet-bundler-0.3.1-1.fc32
Summary: A jsonnet package manager
RPMs:golang-github-jsonnet-bundler golang-github-jsonnet-bundler-devel
Size:13.60 MiB

Package: micropipenv-0.1.4-1.fc32
Summary: A simple wrapper around pip to support Pipenv and Poetry files
RPMs:micropipenv
Size:42.90 KiB

Package: multimarkdown-6.5.1-4.fc32
Summary: Lightweight markup processor to produce HTML, LaTeX, and more
RPMs:multimarkdown
Size:9.36 MiB

Package: usbguard-notifier-0.0.5-1.fc32
Summary: A tool for detecting usbguard policy and device presence changes
RPMs:usbguard-notifier
Size:292.39 KiB


= DROPPED PACKAGES =
Package: alltray-0.71b-18.fc31
Summary: Dock any application in the tray
RPMs:alltray
Size:439.92 KiB


= UPGRADED PACKAGES =
Package:  NetworkManager-1:1.22.10-1.fc32
Old package:  NetworkManager-1:1.22.8-1.fc32
Summary:  Network connection manager and user applications
RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth 
NetworkManager-cloud-setup NetworkManager-config-connectivity-fedora 
NetworkManager-config-server NetworkManager-dispatcher-routing-rules 
NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs 
NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi 
NetworkManager-wwan
Size: 27.18 MiB
Size change:  94 B
Changelog:
  * Sat Feb 22 2020 Adam Williamson  - 1:1.22.8-2
  - Rebuild for new ppp

  * Thu Mar 12 2020 Thomas Haller  - 0.1.9-1
  - Update to version 0.1.8 with lots of fixes and additional modules
https://github.com/freeipa/ansible-freeipa/releases/tag/v0.1.9


Package:  blivet-gui-2.1.12-3.fc32
Old package:  blivet-gui-2.1.12-1.fc32
Summary:  Tool for data storage configuration
RPMs: blivet-gui blivet-gui-runtime
Size: 301.66 KiB
Size change:  210 B
Changelog:
  * Wed Mar 11 2020 Vojtech Trefny  - 2.1.12-2
  - Fix setting attributes for proxy objects (#1810855)

  * Thu Mar 12 2020 Vojtech Trefny  - 2.1.12-3
  - Fix TypeError in remote_method (#1812734)


Package:  bluez-5.54-1.fc32
Old package:  bluez-5.53-2.fc32
Summary:  Bluetooth utilities
RPMs: bluez bluez-cups bluez-hid2hci bluez-libs bluez-libs-devel 
bluez-mesh bluez-obexd
Size: 11.05 MiB
Size change:  60.52 KiB
Changelog:
  * Sun Mar 15 2020 Peter Robinson  - 5.54-1
  - bluez 5.54


Package:  copr-cli-1.86-1.fc32
Old package:  copr-cli-1.85-1.fc32
Summary:  Command line interface for COPR
RPMs: copr-cli
Size: 59.41 KiB
Size change:  2.99 KiB
Changelog:
  * Wed Mar 18 2020 Pavel Raiskup  1.86-1
  - add script to list package build order in copr or koji
  - fix `copr mock-config` to use `dnf.conf/yum.conf` automatically


Package:  corectrl-1.0.8-1.fc32
Old package:  corectrl-1.0.7-2.fc32
Summary:  Friendly hardware control
RPMs: corectrl
Size: 5.56 MiB
Size change:  60.71 KiB
Changelog:
  * Tue Jan 28 2020 Fedora Release Engineering  - 
1.0.7-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild

  * Mon Mar 16 2020 Artem Polishchuk  - 1.0.8-1
  - Update to 1.0.8


Package:  dracut-050-26.git20200316.fc32
Old package:  dracut-049-27.git20181204.fc32.2
Summary:  Initramfs generator using udev
RPMs: dracut dracut-caps dracut-config-generic dracut-config-rescue 
dracut-live dracut-network dracut-squash dracut-tools
Size: 2.21 MiB
Size change:  58.84 KiB
Changelog:
  * Wed Mar 04 2020 Harald Hoyer  - 050-1
  - version 050

  * Tue Mar 10 2020 Adam Williamson  - 050-2
  - Backport fix for pre-trigger stage early exit from upstream (#1811070)

  * Fri Mar 13 2020 Harald Hoyer  - 050-25.git20200313
  - network-manager: ensure that nm-run.sh is executed for rd.neednet

  * Mon Mar 16 2020 Harald Hoyer  - 050-26.git20200316
  - fixed `--tmpdir` mishandling


Package:  ephemeral-6.3.1-1.fc32
Old package:  ephemeral-6.3.0-1.fc32
Summary:  Private-by-default, always-incognito browser
RPMs: ephemeral
Size: 598.42 KiB
Size change:  -99.43 KiB
Changelog:
  * Mon Mar 23 2020 Artem Polishchuk  - 6.3.1-1
  - Update to 6.3.1
  - Enable LTO
  - Clean SVG icon dupes


Package:  fontconfig-2.13.92-8.fc32
Old package:  fontconfig-2.13.92-7.fc32
Summary:  Font configuration and customization library
RPMs: fontconfig fontconfig-devel fontconfig-devel-doc
Size: 2.48 MiB
Size change:  -1.25 KiB

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

On Wed, Mar 25, 2020 at 1:32 PM David Tardon  wrote:
...
 > And yes, it means that people are going to be _bothered_, and
> > _pressured_ on figuring out the best way to collaborate. But isn't it
> > our job?
>
> No, that's not what your proposal implies. Instead, people are going to
> be bothered and pressured to accept the _only_ way to collaborate: put
> conditionals into their spec.

I think you are making a bit of a straw-man argument here. Aleksandra
didn't say at any time that only conditionals would be accepted.
(Indeed, she recommended that the ideal situation is for us to avoid
conditionals where possible and instead use Recommends: for things
that are not strict requirements. This would benefit Fedora as well,
since people could trim their installs down to their needs.)

> > And again, if you make it easier for downstream to work with Fedora,
> > you give downstream the reasons to bring their resources. Things like
> > quality assurance and help with bug triage and bug fixes, things like
> > cross-project feature development. This is a two-way collaboration
> > effort.
>
> Do you suggest that RH maintainers, who have mostly their hands full
> maintaining _their_ packages, are going to start maintaining _more_
> packages? I find that highly unlikely.
>

No, she didn't say that at all. She said that maintainers who are
already doing this work internally to Red Hat would have an
opportunity (and encouragement from their employer) to move that work
to Fedora instead, so that the wider community can take advantage.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-32-20200325.0 compose check report

No missing expected images.

Passed openQA tests: 8/8 (x86_64)

New passes (same test not passed in Fedora-IoT-32-20200324.0):

ID: 556495  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/556495
ID: 556496  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/556496

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
1 services(s) removed since previous compose: getty@tty6.service
System load changed from 0.05 to 0.16
Previous test data: https://openqa.fedoraproject.org/tests/58#downloads
Current test data: https://openqa.fedoraproject.org/tests/556495#downloads

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
1 services(s) removed since previous compose: getty@tty6.service
System load changed from 0.03 to 0.21
Previous test data: https://openqa.fedoraproject.org/tests/59#downloads
Current test data: https://openqa.fedoraproject.org/tests/556496#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: F32 selinux denials

2020-03-25 Thread Zdenek Pytela

On Wed, Mar 25, 2020 at 6:30 PM Adam Williamson 
wrote:

> On Wed, 2020-03-25 at 18:17 +0100, Zdenek Pytela wrote:
> >
> > > SELinux is preventing pcscd from using the sys_nice capability.
> > >
> > > SELinux is preventing accounts-daemon from using the sys_nice
> > > capability.
> > >
> > Denials like this are under investigation, most likely they are harmless
> > and can be safely ignored.
>
> I'd appreciate it if you would do something about them, though, as they
> cause the openQA tests that check for AVCs to *always* trigger. This
> makes it harder to identify when a *new* AVC shows up.
>
> I could set up a 'whitelist' system for that test but I'd really prefer
> not to have to...
>
Adam,

definitely they need to be addressed before GA, if possible in the update
following the current one.

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


-- 

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

links to koji builds in src.fp.o

I recently noticed that the commit list in dist-git shows the number
of successful/failed/cancelled builds from a given commit [e.g. 1,2].
I haven't seen this announced, but this is super cool and useful!
A thousand thanks to whoever made this happen.

Zbyszek

[1] https://src.fedoraproject.org/rpms/pdf-stapler/commits/f32
[2] 
https://src.fedoraproject.org/rpms/pdf-stapler/c/2ec3059dbafd666a0988585ae4208da47fc869e9
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

2020-03-25 Thread David Tardon

On Wed, 2020-03-25 at 13:09 +0100, Aleksandra Fedorova wrote:
> On Wed, Mar 25, 2020 at 12:48 PM Miro Hrončok 
> wrote:
> > On 25. 03. 20 12:37, Fabio Valentini wrote:
> > > > So let's assume for the sake of the argument, that Python is
> > > > broken in ELN and
> > > > the Python maintainers don't want 0%{?rhel}/0%{?eln}
> > > > conditionals in their spec
> > > > files. Now all 3600+ Python packages will fail to build in ELN
> > > > because of this
> > > > and the feedback provided in bodhi will be moot. What will
> > > > happen then?
> > > What about using an additional "eln" branch in dist-git?
> > > 
> > > - For most packages, the master branch should be able to be
> > > merged
> > > into eln regularly (or even automatically, triggered by master
> > > commits).
> > > - For the packages that need "unacceptable in master"
> > > adjustments, an
> > > automatic rebase on top of new master commits could be attempted,
> > > and
> > > if that fails, human intervention is necessary anyway.
> > 
> > Yes, that makes sense to me. Especially with automation (bacause
> > without it, the
> > branch would simply get stalled, you cannot rebase all Fedora
> > packages manually
> > at this scale).
> 
> As I mentioned in the previous mail, branching goes against the
> purpose of the effort.
> 
> What we like to achieve is to create a continuous flow from Fedora
> Rawhide through branched Fedora all the way to downstream, which is
> sometimes CentOS and sometimes EPEL.
> 
> Doing this with branches is going to be much harder. When you update
> package with conditionals you do need to care about the effect on
> various ifs, but you do need to change the package only once at one
> place. And then the tree of branches which we create from Fedora
> Rawhide will get this change automatically with no effort.
> 
> Of course not ifs are equal. It may require some refactoring on the
> code side to make the ifs cleaner. I know kernel people did that with
> a kernel package to reorganize patches which are applied.
> 
> But this is exactly the work we are looking for: the negotiation
> between downstream maintainers and Fedora maintainers to make things
> work together. We already have branching, it is easier as it allow us
> not to talk to each other, but it doesn't solve anything.
> 
> And yes, it means that people are going to be _bothered_, and
> _pressured_ on figuring out the best way to collaborate. But isn't it
> our job?

No, that's not what your proposal implies. Instead, people are going to
be bothered and pressured to accept the _only_ way to collaborate: put
conditionals into their spec.

> And again, if you make it easier for downstream to work with Fedora,
> you give downstream the reasons to bring their resources. Things like
> quality assurance and help with bug triage and bug fixes, things like
> cross-project feature development. This is a two-way collaboration
> effort.

Do you suggest that RH maintainers, who have mostly their hands full
maintaining _their_ packages, are going to start maintaining _more_
packages? I find that highly unlikely.

D.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 selinux denials

2020-03-25 Thread Adam Williamson

On Wed, 2020-03-25 at 18:17 +0100, Zdenek Pytela wrote:
> 
> > SELinux is preventing pcscd from using the sys_nice capability.
> > 
> > SELinux is preventing accounts-daemon from using the sys_nice
> > capability.
> > 
> Denials like this are under investigation, most likely they are harmless
> and can be safely ignored.

I'd appreciate it if you would do something about them, though, as they
cause the openQA tests that check for AVCs to *always* trigger. This
makes it harder to identify when a *new* AVC shows up.

I could set up a 'whitelist' system for that test but I'd really prefer
not to have to...
-- 
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: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
>> On Wed, Mar 25, 2020 at 3:10 PM Miro Hrončok  wrote:
>>> On 25. 03. 20 14:06, Aleksandra Fedorova wrote:
>> By contributing to Fedora Rawhide sources and consuming them as ELN
>> repositories for testing purposes.
> The change proposal literally says "There is no user-facing part in this 
> change.
> No ELN artifacts are going to be shipped to the end-user."
>
> As a contributor, how do I consume the content if I cannot consume the 
> content?
> As I understand it, the "end-user" and "user-facing" terms must have 
> different
> meanings in this context, right? What is this meaning?
 Looks like terminology issue. For me user is a person who uses
 released Fedora, like Fedora 31 Workstation, on their laptop, or
 Fedora 32 IoT edition on their Raspberry Pi, or a minimalistic Fedora
 for Fedora server.
 Basically anyone who needs Fedora to solve their own problems, which
 are not related to development of the distribution.

 Fedora Rawhide is not a user-facing branch in Fedora, because it's
 purpose is to develop Fedora, not something else.
 Same with ELN. It is not a Fedora Server edition, there is no reason
 to ever use it on a server. It is a rebuild of Fedora Rawhide, and
 it's purpose is the development of Fedora, and help others to
 contribute to that development.

 So it is facing contributors, not users.

 Different types of contributors though.
>>> I consider rawhide users our users and I assume many other do consider them 
>>> our
>>> users as well. I consider upstream projects who run their CI on Fedora our
>>> users. You are not incorrect that this is a terminology issue, however I 
>>> think
>>> this is a different mindset issue. Please do consider rawhide users and 
>>> upstream
>>> projects our users when designing things.
>> You are misinterpreting what I said. And it is a terminology issue.
>>
>> You somehow assume that if we call people users - we care about them,
>> and if we call them contributors, they are _just_ contributors, so we
>> don't.
>> This is not what I have said, and please don't put such a mindset on me.
>>
>> The difference between users and contributors is not how you treat
>> them, but a level of knowledge about Fedora internals which is
>> expected from them.
>> Using rawhide on your workstation is possible, but you need to learn
>> first what rawhide is and you need to make an educated choice to use
>> it.
>> Same with ELN.
>>
>> It does not have impact on Fedora Workstation user experience. My
>> grandma, who is Fedora user since Fedora 8, will not see this change
>> on her laptop and she doesn't need to be informed about it.
>>
>>> For example, there is a point to run an ELN on a server - e.g. to run a 
>>> buildbot
>>> worker on it for some CI tests.
>> I think this is not the server Neil meant.
>> My point was to highlight that ELN is not a "stable edition" like
>> Fedora Server. ELN is Rawhide, its quality is no better than Rawhide
>> quality, its stability is Rawhide stability, its target audience is
>> Rawhide audience.
>>
> I'd rather discuss this here and only come to FPC for approval of new 
> guidelines
> when ready. The FPC members who are likely to discuss this are already
> discussing this here. Why spitting the discussion into two places?
 Sorry, my understanding of why we need RelEng and FPC tickets was
 completely the opposite. Mailing list discussion about the Change is
 generic, and gets side-tracked to one side or the other and digging
 through it to get the pieces which are relevant to FPC topic is
 harder. While ticket has a fixed topic, discussion associated to it
 and the outcome of that discussion. I don't see how you can prevent
 people from discussing the topic in the ticket and move it to the
 mailing list.

 If you see FPC ticket as a "request to vote" only, why do we need it
 then? Can't we just invite FPC representative to vote on a FESCo
 ticket?
>>> We could, but there are existing workflows based on the committees using 
>>> their
>>> own ticketing tracker to do the voting.
>> Ok.
>>
> This is all nice only as long as you prefer conditionals over branching. 
> For a
> Fedora maintainer who doesn't, this is just "unnecessary cruft" in the 
> spec file.
 It is not really about personal preferences. These are two different
 approaches with different purposes, different results and different
 requirements.
 There are consequences on choosing one other the other.
>>> Yes. That's what I've been saying since the beginning. Choosing %ifs over
>>> branches has consequences. Choosing branches over %ifs has consequences. Not
>>> being able to choose has consequences.
>>>
 Branching means forking Fedora Rawhide into something else. Which

Re: F32 selinux denials

2020-03-25 Thread Zdenek Pytela

On Wed, Mar 25, 2020 at 4:49 PM Nathanael D. Noblet 
wrote:

> Hello,
>
>   I upgraded to F32 yesterday and everything seems to have gone
> smoothly except I'm getting many selinux denials (I'm in permissive so
> functionality is ok at the moment). What should I report them against?
> I've done a relabel to try to resolve them.
>
Hi,

They should be reported for the selinux-policy component. No need this time
though, answers inline.


> A sample of the most common:
>
> SELinux is preventing /usr/lib/systemd/systemd-journald from read
> access on the lnk_file /run/user/1000/systemd/units/invocation:dbus-:
> 1.2-org.fedoraproject.Setroubleshootd@1.service.
>
This one will be fixed with the next selinux-package update, probably
tomorrow.


> SELinux is preventing pcscd from using the sys_nice capability.
>
> SELinux is preventing accounts-daemon from using the sys_nice
> capability.
>
Denials like this are under investigation, most likely they are harmless
and can be safely ignored.

Cheers,

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


-- 

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


On 25. 03. 20 17:33, Aleksandra Fedorova wrote:

I consider rawhide users our users and I assume many other do consider them our
users as well. I consider upstream projects who run their CI on Fedora our
users. You are not incorrect that this is a terminology issue, however I think
this is a different mindset issue. Please do consider rawhide users and upstream
projects our users when designing things.


You are misinterpreting what I said. And it is a terminology issue.


Let's agree on that.


You somehow assume that if we call people users - we care about them,
and if we call them contributors, they are _just_ contributors, so we
don't.
This is not what I have said, and please don't put such a mindset on me.

The difference between users and contributors is not how you treat
them, but a level of knowledge about Fedora internals which is
expected from them.
Using rawhide on your workstation is possible, but you need to learn
first what rawhide is and you need to make an educated choice to use
it.
Same with ELN.


This also applies to e.g. "Fedora Workstation". Using "Fedora Workstation" on 
your workstation is possible, but you need to learn first what "Fedora 
Workstation" is and you need to make an educated choice to use it. (unless 
somebody else makes this choice instead and they install it for you, which also 
applies to rawhide or ELN.)



It does not have impact on Fedora Workstation user experience. My
grandma, who is Fedora user since Fedora 8, will not see this change
on her laptop and she doesn't need to be informed about it.


Neither does your grandma need to be notified about most of the other changes in 
Fedora just in order to be able to use it.


Never mind. **I see what you mean.** After all those words I understand what you 
meant by the statement. However when reading just the change proposal, the 
statement doesn't make sense to me. And if it so complicated to explain, maybe 
it makes sense to stop saying there will be no user deliverables and rephrase 
it? Say that users of rawhide or Fedora (pre)releases will not be affected. And 
say how can ELN users consume it (for their CI or for their mock).



For example, there is a point to run an ELN on a server - e.g. to run a buildbot
worker on it for some CI tests.


I think this is not the server Neil meant.
My point was to highlight that ELN is not a "stable edition" like
Fedora Server. ELN is Rawhide, its quality is no better than Rawhide
quality, its stability is Rawhide stability, its target audience is
Rawhide audience.


I get what you **mean**. However I think that "Fedora Server" and "rawhide" are 
not comparable or contradicting terms. You can have Fedora Server while having 
rawhide. You cannot say "Fedora Server is a stable edition, unlike rawhide".


I don't want to argue about our terminology anymore. I understand what you are 
saying in your emails, but I didn't understand what the change proposal is 
saying (and I think neither will all others).



This is all nice only as long as you prefer conditionals over branching. For a
Fedora maintainer who doesn't, this is just "unnecessary cruft" in the spec 
file.


It is not really about personal preferences. These are two different
approaches with different purposes, different results and different
requirements.
There are consequences on choosing one other the other.


Yes. That's what I've been saying since the beginning. Choosing %ifs over
branches has consequences. Choosing branches over %ifs has consequences. Not
being able to choose has consequences.


Branching means forking Fedora Rawhide into something else. Which
eventually will lead to new downstream tree which will ignore the rest
of Fedora and just use the fork instead. It can be done, but I think
it will damage Fedora as a project.


Not if we do automation that constantly keeps them in sync. Is that hard? Most
likely. But it doesn't put additional burden to the community maintainers.


It removes community maintainer from the conversation about what
downstream is doing. While we want to give community member a voice in
that conversation.


I don't see how.


It also cuts community maintainer from the help of downstream, as
downstream will be developing a fork.


This boils down to terminology (again). What you call a fork is a separate 
branch. In my eyes a branch with a bcond switched is no more "fork" than a %if 
in one branch. Consider this:



Case A:

there is just master branch. it has:

  %if 0%{?rhel} && (! 0%{?epel})
  %bcond_with tests
  %else
  %bcond_without tests
  %endif

Case B:

there are 2 branches. master has:

  %bcond_without tests

eln has:

  %bcond_with tests

But their content is otherwise identical. How is Case B more fork-ish than Case 
A?



We can not fully implement it in the planning phase. It is not a
generic question with generic answer. It needs to be decided on a
package level. And decision maybe different for each package and for
each case.

We can come up with guidelines...

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
> On Wed, Mar 25, 2020 at 3:10 PM Miro Hrončok  wrote:
>> On 25. 03. 20 14:06, Aleksandra Fedorova wrote:
> By contributing to Fedora Rawhide sources and consuming them as ELN
> repositories for testing purposes.
 The change proposal literally says "There is no user-facing part in this 
 change.
 No ELN artifacts are going to be shipped to the end-user."

 As a contributor, how do I consume the content if I cannot consume the 
 content?
 As I understand it, the "end-user" and "user-facing" terms must have 
 different
 meanings in this context, right? What is this meaning?
>>> Looks like terminology issue. For me user is a person who uses
>>> released Fedora, like Fedora 31 Workstation, on their laptop, or
>>> Fedora 32 IoT edition on their Raspberry Pi, or a minimalistic Fedora
>>> for Fedora server.
>>> Basically anyone who needs Fedora to solve their own problems, which
>>> are not related to development of the distribution.
>>>
>>> Fedora Rawhide is not a user-facing branch in Fedora, because it's
>>> purpose is to develop Fedora, not something else.
>>> Same with ELN. It is not a Fedora Server edition, there is no reason
>>> to ever use it on a server. It is a rebuild of Fedora Rawhide, and
>>> it's purpose is the development of Fedora, and help others to
>>> contribute to that development.
>>>
>>> So it is facing contributors, not users.
>>>
>>> Different types of contributors though.
>> I consider rawhide users our users and I assume many other do consider them 
>> our
>> users as well. I consider upstream projects who run their CI on Fedora our
>> users. You are not incorrect that this is a terminology issue, however I 
>> think
>> this is a different mindset issue. Please do consider rawhide users and 
>> upstream
>> projects our users when designing things.
> You are misinterpreting what I said. And it is a terminology issue.
>
> You somehow assume that if we call people users - we care about them,
> and if we call them contributors, they are _just_ contributors, so we
> don't.
> This is not what I have said, and please don't put such a mindset on me.
>
> The difference between users and contributors is not how you treat
> them, but a level of knowledge about Fedora internals which is
> expected from them.
> Using rawhide on your workstation is possible, but you need to learn
> first what rawhide is and you need to make an educated choice to use
> it.
> Same with ELN.
>
> It does not have impact on Fedora Workstation user experience. My
> grandma, who is Fedora user since Fedora 8, will not see this change
> on her laptop and she doesn't need to be informed about it.
>
>> For example, there is a point to run an ELN on a server - e.g. to run a 
>> buildbot
>> worker on it for some CI tests.
> I think this is not the server Neil meant.
> My point was to highlight that ELN is not a "stable edition" like
> Fedora Server. ELN is Rawhide, its quality is no better than Rawhide
> quality, its stability is Rawhide stability, its target audience is
> Rawhide audience.
>
 I'd rather discuss this here and only come to FPC for approval of new 
 guidelines
 when ready. The FPC members who are likely to discuss this are already
 discussing this here. Why spitting the discussion into two places?
>>> Sorry, my understanding of why we need RelEng and FPC tickets was
>>> completely the opposite. Mailing list discussion about the Change is
>>> generic, and gets side-tracked to one side or the other and digging
>>> through it to get the pieces which are relevant to FPC topic is
>>> harder. While ticket has a fixed topic, discussion associated to it
>>> and the outcome of that discussion. I don't see how you can prevent
>>> people from discussing the topic in the ticket and move it to the
>>> mailing list.
>>>
>>> If you see FPC ticket as a "request to vote" only, why do we need it
>>> then? Can't we just invite FPC representative to vote on a FESCo
>>> ticket?
>> We could, but there are existing workflows based on the committees using 
>> their
>> own ticketing tracker to do the voting.
> Ok.
>
 This is all nice only as long as you prefer conditionals over branching. 
 For a
 Fedora maintainer who doesn't, this is just "unnecessary cruft" in the 
 spec file.
>>> It is not really about personal preferences. These are two different
>>> approaches with different purposes, different results and different
>>> requirements.
>>> There are consequences on choosing one other the other.
>> Yes. That's what I've been saying since the beginning. Choosing %ifs over
>> branches has consequences. Choosing branches over %ifs has consequences. Not
>> being able to choose has consequences.
>>
>>> Branching means forking Fedora Rawhide into something else. Which
>>> eventually will lead to new downstream tree which will ignore the rest
>>> of Fedora and just use the fork instead. It can be done, but I think

[Bug 1661251] Fails due to uninitialised value

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

Fedora Admin XMLRPC Client  changed:

   What|Removed |Added

   Assignee|extras-orphan@fedoraproject |ppi...@redhat.com
   |.org|



--- Comment #2 from Fedora Admin XMLRPC Client  
---
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

-- 
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: F32 selinux denials

2020-03-25 Thread Ankur Sinha

On Wed, Mar 25, 2020 09:48:05 -0600, Nathanael D. Noblet wrote:
> Hello,
> 
>   I upgraded to F32 yesterday and everything seems to have gone
> smoothly except I'm getting many selinux denials (I'm in permissive so
> functionality is ok at the moment). What should I report them against?
> I've done a relabel to try to resolve them.
> 
> A sample of the most common:
> 
> SELinux is preventing /usr/lib/systemd/systemd-journald from read
> access on the lnk_file /run/user/1000/systemd/units/invocation:dbus-:
> 1.2-org.fedoraproject.Setroubleshootd@1.service.
> 
> SELinux is preventing pcscd from using the sys_nice capability.
> 
> SELinux is preventing accounts-daemon from using the sys_nice
> capability.

I find it easiest to install `setroubleshoot` and report bugs using it.
If they're already reported, it will add you to the bug etc.

-- 
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 System-Wide Change proposal: ELN Buildroot and Compose

On Wed, Mar 25, 2020 at 3:10 PM Miro Hrončok  wrote:
>
> On 25. 03. 20 14:06, Aleksandra Fedorova wrote:
> >>> By contributing to Fedora Rawhide sources and consuming them as ELN
> >>> repositories for testing purposes.
> >>
> >> The change proposal literally says "There is no user-facing part in this 
> >> change.
> >> No ELN artifacts are going to be shipped to the end-user."
> >>
> >> As a contributor, how do I consume the content if I cannot consume the 
> >> content?
> >> As I understand it, the "end-user" and "user-facing" terms must have 
> >> different
> >> meanings in this context, right? What is this meaning?
> >
> > Looks like terminology issue. For me user is a person who uses
> > released Fedora, like Fedora 31 Workstation, on their laptop, or
> > Fedora 32 IoT edition on their Raspberry Pi, or a minimalistic Fedora
> > for Fedora server.
> > Basically anyone who needs Fedora to solve their own problems, which
> > are not related to development of the distribution.
> >
> > Fedora Rawhide is not a user-facing branch in Fedora, because it's
> > purpose is to develop Fedora, not something else.
> > Same with ELN. It is not a Fedora Server edition, there is no reason
> > to ever use it on a server. It is a rebuild of Fedora Rawhide, and
> > it's purpose is the development of Fedora, and help others to
> > contribute to that development.
> >
> > So it is facing contributors, not users.
> >
> > Different types of contributors though.
>
> I consider rawhide users our users and I assume many other do consider them 
> our
> users as well. I consider upstream projects who run their CI on Fedora our
> users. You are not incorrect that this is a terminology issue, however I think
> this is a different mindset issue. Please do consider rawhide users and 
> upstream
> projects our users when designing things.

You are misinterpreting what I said. And it is a terminology issue.

You somehow assume that if we call people users - we care about them,
and if we call them contributors, they are _just_ contributors, so we
don't.
This is not what I have said, and please don't put such a mindset on me.

The difference between users and contributors is not how you treat
them, but a level of knowledge about Fedora internals which is
expected from them.
Using rawhide on your workstation is possible, but you need to learn
first what rawhide is and you need to make an educated choice to use
it.
Same with ELN.

It does not have impact on Fedora Workstation user experience. My
grandma, who is Fedora user since Fedora 8, will not see this change
on her laptop and she doesn't need to be informed about it.

> For example, there is a point to run an ELN on a server - e.g. to run a 
> buildbot
> worker on it for some CI tests.

I think this is not the server Neil meant.
My point was to highlight that ELN is not a "stable edition" like
Fedora Server. ELN is Rawhide, its quality is no better than Rawhide
quality, its stability is Rawhide stability, its target audience is
Rawhide audience.

>
> >> I'd rather discuss this here and only come to FPC for approval of new 
> >> guidelines
> >> when ready. The FPC members who are likely to discuss this are already
> >> discussing this here. Why spitting the discussion into two places?
> >
> > Sorry, my understanding of why we need RelEng and FPC tickets was
> > completely the opposite. Mailing list discussion about the Change is
> > generic, and gets side-tracked to one side or the other and digging
> > through it to get the pieces which are relevant to FPC topic is
> > harder. While ticket has a fixed topic, discussion associated to it
> > and the outcome of that discussion. I don't see how you can prevent
> > people from discussing the topic in the ticket and move it to the
> > mailing list.
> >
> > If you see FPC ticket as a "request to vote" only, why do we need it
> > then? Can't we just invite FPC representative to vote on a FESCo
> > ticket?
>
> We could, but there are existing workflows based on the committees using their
> own ticketing tracker to do the voting.

Ok.

>
> >> This is all nice only as long as you prefer conditionals over branching. 
> >> For a
> >> Fedora maintainer who doesn't, this is just "unnecessary cruft" in the 
> >> spec file.
> >
> > It is not really about personal preferences. These are two different
> > approaches with different purposes, different results and different
> > requirements.
> > There are consequences on choosing one other the other.
>
> Yes. That's what I've been saying since the beginning. Choosing %ifs over
> branches has consequences. Choosing branches over %ifs has consequences. Not
> being able to choose has consequences.
>
> > Branching means forking Fedora Rawhide into something else. Which
> > eventually will lead to new downstream tree which will ignore the rest
> > of Fedora and just use the fork instead. It can be done, but I think
> > it will damage Fedora as a project.
>
> Not if we do automation that constantly keeps them in

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


On 25. 03. 20 16:47, Stephen Gallagher wrote:

I think we managed to miss a few key points in the Change Proposal
which is directly resulting in a bit of the confusion here.


Reading the rest of you e-mail I must agree that this is what happened. Would 
you mind putting the change back to incomplete state and resend it once more for 
feedback once this is addressed?



The first and most important of these is that ELN will*not*  be
building the complete Fedora package set. We're going to be building a
selected subset of packages (derived from packages in RHEL 8 and
EPEL). Our current expectation is that we are going to be looking at
fewer than 2500 source packages. We are still working up the initial
list of these and we will update the Change Proposal with it (as well
as providing a fedora-devel post breaking down the known owners).


Glad to hear that.


Second, from this reduced subset, we expect that the overwhelming
majority of the maintainers are Red Hat employees that already work on
RHEL. With this in mind, we think that the level of concern about how
this will affect non-Red Hat contributors is premature. We will reach
out directly to those non-Red Hat contributors we identify.


As a Red employee if I need to diverge a RHEL package from Fedora, I prefer to 
use branches as well. And I know for a fact I am not alone in this. Please don't 
forget to identify and reach out to Red Hat contributors as well, not just the 
non-Red Hat contributors.



Finally, of the set of packages that we're going to be including, we
anticipate around 200-300 of them will have distro conditionals that
need investigation (with fewer needing actual modification). The ELN
SIG will be doing this initial investigation and will provide guidance
(and/or PRs) to affected packagers.


My concerns still remain, although I am now not so scared that this will 
alienate the community. Now the concern is more personal (= previously I was 
worried that everybody will be encouraged to use the conditionals, while now I'm 
mostly concerned they I will be encouraged to use the conditionals).


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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

2020-03-25 Thread Robbie Harwood

Nicolas Mailhot via devel  writes:

> Le mercredi 25 mars 2020 à 13:09 +0100, Aleksandra Fedorova a écrit :
>> Miro Hrončok  wrote:
>>
>> As I mentioned in the previous mail, branching goes against the
>> purpose of the effort.
>> 
>> What we like to achieve is to create a continuous flow from Fedora
>> Rawhide through branched Fedora all the way to downstream, which is
>> sometimes CentOS and sometimes EPEL.
>
> Then please work with @rh engineering to get an up-to-date packaging
> stack in EL (that means, latest stable Fedora rpm and latest stable
> Fedora packaging macros, and all the other things that make packager
> work less a shore).
>
> A huge amount of EL ifdefs is directly caused by the staleness of the
> packaging stack in EL. That’s why so much Fedora stuff never makes it
> in EPEL. Most people Fedora side do not want to deal with the utter
> clustefuck of trying to push complex up to date software to EL using
> inadequate obsolete tooling.
>
> No amount of clever ifdefing is going to mitigate this tooling
> staleness. No amount of poking is going to convince people that *do*
> *not* *want* *to* *deal* *with* *el* *braindamage* to accept
> braindamage side-effects in their own Fedora specs. That’s trying to
> put lipstick on a pig.

This is not "being excellent to each other".  Let's keep in mind that we
are all here for the same reason (Fedora), and that this makes us
colleagues - including the people who make EL.

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: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


Dne 25. 03. 20 v 16:47 Stephen Gallagher napsal(a):
> Starting a new sub-thread.
>
> On Tue, Mar 24, 2020 at 5:33 AM Aleksandra Fedorova  
> wrote:
>> As Ben is on PTO, I'd like to present the System-Wide Change
>>
>> https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>>
>> == Summary ==
>>
>> The goal of the ELN project is to continuously build Fedora Rawhide
>> packages and composes in the way which resembles the CentOS and RHEL
>> build process and to provide a feedback loop for Fedora maintainers on
>> the status of those builds.
> I think we managed to miss a few key points in the Change Proposal
> which is directly resulting in a bit of the confusion here.
>
> The first and most important of these is that ELN will *not* be
> building the complete Fedora package set. We're going to be building a
> selected subset of packages (derived from packages in RHEL 8 and
> EPEL). Our current expectation is that we are going to be looking at
> fewer than 2500 source packages. We are still working up the initial
> list of these and we will update the Change Proposal with it (as well
> as providing a fedora-devel post breaking down the known owners).


I assume that for the beginning we are talking about the RHEL8 BaseOS
and CRB components and as soon as you figure out modules, then this will
apply to AppStream as well (although not everything in AppStream are
modules)?


Vít


>
> Second, from this reduced subset, we expect that the overwhelming
> majority of the maintainers are Red Hat employees that already work on
> RHEL. With this in mind, we think that the level of concern about how
> this will affect non-Red Hat contributors is premature. We will reach
> out directly to those non-Red Hat contributors we identify.
>
> Finally, of the set of packages that we're going to be including, we
> anticipate around 200-300 of them will have distro conditionals that
> need investigation (with fewer needing actual modification). The ELN
> SIG will be doing this initial investigation and will provide guidance
> (and/or PRs) to affected packagers.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


Dne 25. 03. 20 v 15:02 Zbigniew Jędrzejewski-Szmek napsal(a):
> On Wed, Mar 25, 2020 at 02:06:59PM +0100, Aleksandra Fedorova wrote:
>> Hi, Miro,
>>
>> On Wed, Mar 25, 2020 at 1:28 PM Miro Hrončok  wrote:
>>> On 25. 03. 20 12:49, Aleksandra Fedorova wrote:
 I think that not having eln-branch is very important part of the
 concept as we don't want to fork Fedora. By using conditionals in spec
 files we do create variants of the rpm, but at list we get them
 automatically synced with the upstream sources. So whenever you update
 the package in Rawhide, ELN binary package is updated too.

 Conditionals create problems indeed, we should use them carefully. I
 would prefer if instead of conditionals we find ways how to make
 Fedora packages more flexible, change from Requires to Suggests for
 example, or split into subpackages.
 But in this case I think conditionals are a much better choice than
 branching, as when done once, they require less maintenance on their
 way to downstream.
>>> Sure They are good for downstream. RHEL clearly benefits from this.
>>> But they impose additional cognitive overhead on the community maintainers 
>>> in
>>> Fedora.
>>>
>>>
 We add conditional in Rawhide, we inherit it in branched Fedora, we
 consume it in CentOS Stream, we get it in EPEL. All of it happens
 automatically once we have the ELN compatibility in Rawhide.
>>> This is all nice only as long as you prefer conditionals over branching. 
>>> For a
>>> Fedora maintainer who doesn't, this is just "unnecessary cruft" in the spec 
>>> file.
>> It is not really about personal preferences. These are two different
>> approaches with different purposes, different results and different
>> requirements.
>> There are consequences on choosing one other the other.
>>
>> Branching means forking Fedora Rawhide into something else. Which
>> eventually will lead to new downstream tree which will ignore the rest
>> of Fedora and just use the fork instead. It can be done, but I think
>> it will damage Fedora as a project.


Just FTR, there is `git symbolic-ref` [1], which means that the "branch"
won't need to be necessarily branch, if the content of master and
rawhide is the same. In that case, you don't even need any
synchronization. Given this, it would be easy to track how many packages
are vanilla Rawhide packages and which are modified and need special
attention.

But this is of course just implementation detail.


Vít


[1] https://git-scm.com/docs/git-symbolic-ref


> IMO, that significantly overstates the difference between the two.
> In particular, branching is exactly what happens every six months when
> we start a new release, and yes, it is possible for the branches to
> diverge, but no, it is also possible to keep the branches synchronized
> and actually for many packages this is what happens.
> For any specific package, whether the branches are similar or divergent
> depends on the situation of the package and maintainer choices.
>
> Also, a side note: with the planned changes to do away with changelogs
> and release tags in .spec, branches have the potential to become identical
> (i.e. we would still have branches, to know what to build where, but they
> would point to the same commit).
>
> Heavy ifdeffery in spec files is something of a past. Different
> maintainers have different preferences, but I think it is fair to
> say that we have moved significantly in the direction of simplified
> spec files and less conditionals.
>
> I think you shouldn't discount the separate branch approach just yet.
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

F32 selinux denials

2020-03-25 Thread Nathanael D. Noblet

Hello,

  I upgraded to F32 yesterday and everything seems to have gone
smoothly except I'm getting many selinux denials (I'm in permissive so
functionality is ok at the moment). What should I report them against?
I've done a relabel to try to resolve them.

A sample of the most common:

SELinux is preventing /usr/lib/systemd/systemd-journald from read
access on the lnk_file /run/user/1000/systemd/units/invocation:dbus-:
1.2-org.fedoraproject.Setroubleshootd@1.service.

SELinux is preventing pcscd from using the sys_nice capability.

SELinux is preventing accounts-daemon from using the sys_nice
capability.

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

Starting a new sub-thread.

On Tue, Mar 24, 2020 at 5:33 AM Aleksandra Fedorova  wrote:
>
> As Ben is on PTO, I'd like to present the System-Wide Change
>
> https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>
> == Summary ==
>
> The goal of the ELN project is to continuously build Fedora Rawhide
> packages and composes in the way which resembles the CentOS and RHEL
> build process and to provide a feedback loop for Fedora maintainers on
> the status of those builds.

I think we managed to miss a few key points in the Change Proposal
which is directly resulting in a bit of the confusion here.

The first and most important of these is that ELN will *not* be
building the complete Fedora package set. We're going to be building a
selected subset of packages (derived from packages in RHEL 8 and
EPEL). Our current expectation is that we are going to be looking at
fewer than 2500 source packages. We are still working up the initial
list of these and we will update the Change Proposal with it (as well
as providing a fedora-devel post breaking down the known owners).

Second, from this reduced subset, we expect that the overwhelming
majority of the maintainers are Red Hat employees that already work on
RHEL. With this in mind, we think that the level of concern about how
this will affect non-Red Hat contributors is premature. We will reach
out directly to those non-Red Hat contributors we identify.

Finally, of the set of packages that we're going to be including, we
anticipate around 200-300 of them will have distro conditionals that
need investigation (with fewer needing actual modification). The ELN
SIG will be doing this initial investigation and will provide guidance
(and/or PRs) to affected packagers.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


Dne 25. 03. 20 v 15:19 Troy Dawson napsal(a):
> On Wed, Mar 25, 2020 at 6:15 AM Nicolas Mailhot via devel
>  wrote:
>> Le mercredi 25 mars 2020 à 13:09 +0100, Aleksandra Fedorova a écrit :
>>> On Wed, Mar 25, 2020 at 12:48 PM Miro Hrončok 
>>> wrote:
>>> As I mentioned in the previous mail, branching goes against the
>>> purpose of the effort.
>>>
>>> What we like to achieve is to create a continuous flow from Fedora
>>> Rawhide through branched Fedora all the way to downstream, which is
>>> sometimes CentOS and sometimes EPEL.
>> Then please work with @rh engineering to get an up-to-date packaging
>> stack in EL (that means, latest stable Fedora rpm and latest stable
>> Fedora packaging macros, and all the other things that make packager
>> work less a shore).
>>
>> A huge amount of EL ifdefs is directly caused by the staleness of the
>> packaging stack in EL. That’s why so much Fedora stuff never makes it
>> in EPEL. Most people Fedora side do not want to deal with the utter
>> clustefuck of trying to push complex up to date software to EL using
>> inadequate obsolete tooling.
>>
>> No amount of clever ifdefing is going to mitigate this tooling
>> staleness. No amount of poking is going to convince people that *do*
>> *not* *want* *to* *deal* *with* *el* *braindamage* to accept
>> braindamage side-effects in their own Fedora specs. That’s trying to
>> put lipstick on a pig.
>>
>> We’ve been saying that to @rh representatives for years now. rpm and
>> its ajuncts is the heart of community packaging. Packaging is done by
>> packagers. Packaging is not done by people that loath packaging (and
>> are continuously surprised their own packaging tools for people not
>> interested in packaging do not see mass packager adoption).
>>
>> rpm state in EL prevents most downstreaming. Please focus efforts
>> there.
>>
>> I don’t see how you will get any community adhesion in fixing
>> downstream problems, if all your solutions are downstream focused,
>> without caring about the people you want to enroll.
>>
> RHELN (currently RHEL9) is supposed to look like rawhide up to
> whatever the cutover point is. So, up until that point, you shouldn't
> be putting RHEL conditionals in, unless you do so for EPEL packages.
>
> There are exceptions to this, such as the kernel, glibc, firefox, and
> a handful of others. But those are the exceptions.
>
> After the cutover date, then again, RHELN (in the next case it will be
> RHEL10) should be looking like whatever is in rawhide, so you still
> shouldn't need RHEL conditionals in, unless you do so for EPEL package
> builds.
>
> This ELN proposal has nothing to do with older RHEL releases or EPEL.
>
> Troy


I agree with Nicolas and Troy here. IMO the eln branch is essential for
the success of this change. Every conditional prevents innovation in
Fedora, because nobody knows what is the impact. Even if the CI provides
feedback, that the specific change does not work in ELN, it might result
in not updated package, because everybody will be afraid to touch it.
That is much worse situation then if the package fails to build in ELN.


Vít


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

Re: Heads up: OpenSSL-1.1.1e coming to Rawhide

2020-03-25 Thread Jun Aruga

> The list of (likely) affected packages is growing:
>
> https://koschei.fedoraproject.org/affected-by/openssl-libs?epoch1=1=1.1.1d=7.fc33=1=1.1.1e=1.fc33=f33

It's a useful list! Thanks.
Note rubygem-puma is added to the list too.

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

Le mercredi 25 mars 2020 à 07:19 -0700, Troy Dawson a écrit :
> On Wed, Mar 25, 2020 at 6:15 AM Nicolas Mailhot via devel
>  wrote:
> > 
> > rpm state in EL prevents most downstreaming. Please focus efforts
> > there.
> > 
> > I don’t see how you will get any community adhesion in fixing
> > downstream problems, if all your solutions are downstream focused,
> > without caring about the people you want to enroll.
> > 
> 
> RHELN (currently RHEL9) is supposed to look like rawhide up to
> whatever the cutover point is. So, up until that point, you shouldn't
> be putting RHEL conditionals in, unless you do so for EPEL packages.
> 
> There are exceptions to this, such as the kernel, glibc, firefox, and
> a handful of others. But those are the exceptions.
> 
> After the cutover date, then again, RHELN (in the next case it will
> be RHEL10) should be looking like whatever is in rawhide, 

That would basically mean that ELN is a rh-only thing, since the result
does not get exposed to others before cutover. Do I understand things
correctly?

If that is true, why would any non-rh Fedora packager care about the
complexity that comes with ELN?

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


Dne 25. 03. 20 v 16:19 Vít Ondruch napsal(a):
> Dne 25. 03. 20 v 11:23 Miro Hrončok napsal(a):
>> On 25. 03. 20 10:26, Vít Ondruch wrote:
>>> I think that the level of involvement of the other maintainers is the
>>> same as what we always did for RHEL. Did RHEL maintainers bothered some
>>> Fedora maintainers with some conditionals and what not? Probably. I
>>> don't see that should be different. The only difference probably is that
>>> that won't be one time effort once in every 3 years, but the flow of
>>> requests will be continuous, but hopefully smaller.
>> Well, not exactly. The RHEL maintainer can try to "bother" the Fedora
>> maintainer with rhel conditionals and when that Fedora maintainer says
>> no, the RHEL maintainer adjust the spec in RHEL only. In many cases
>> that can even be the same person. Assume I want to do something
>> differently in RHEL and Fedora -- I just push the change in RHEL.
>>
>> While there is no way to adjust a spec in ELN only (if I understand
>> the plan correctly). Assume I want to do something differently in ELN
>> and Fedora -- I need to use the conditionals.
>>
>>> Actually, this brings interesting question. It seems to me, that it
>>> would be helpful if RHEL maintainers had blank approval to access the
>>> ELN packages.
>> What are ELN packages? From the proposal, it seems it is all Fedora
>> packages. Or did I get that wrong? Do you propose that RHEL
>> maintainers are automatically provenpackagers (I don't think you do,
>> but I am not sure)?
>
> I assume that there will be "ELN" branch, the same way we have fxx or
> epel branches. Is my assumption wrong? Dunno.


Reading other parts of the thread, it seems I was wrong :( The branching
is not considered ATM, but I still think that is mistake.


Vít


>
>
>>
>> In the ideal world, the RHEL maintainer of "foo" should be at least a
>> comaintainer of "foo" in Fedora, not somebody with "blank approval to
>> access". It is sad that in some cases, the RHEL maintainers are not
>> involved in the corresponding Fedora packages until RHEL N+1 is in
>> progress where they'd just like to dump changes and leave for another
>> few years.
>>
>> But even if the RHEL maintainer is an active and/or primary maintainer
>> of the Fedora package, they don't necessarily want to push %if
>> 0%{?rhel} conditionals to rawhide just to support ELN. What shall they
>> do?
>>
> Yes, right, I am in that boat as I sad on different place :) and again,
> since this is not explicitly mentioned in the proposal, I assume that is
> is something to consider.
>
>
> Vít
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20200325.n.0 changes

2020-03-25 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20200324.n.0
NEW: Fedora-Rawhide-20200325.n.0

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  14
Dropped packages:21
Upgraded packages:   96
Downgraded packages: 0

Size of added packages:  6.78 MiB
Size of dropped packages:1.66 MiB
Size of upgraded packages:   7.67 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20200325.n.0.iso

= DROPPED IMAGES =
Image: SoaS live x86_64
Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20200324.n.0.iso

= ADDED PACKAGES =
Package: chordpro-0.974.1-5.fc33
Summary: Print songbooks (lyrics + chords)
RPMs:chordpro
Size:81.75 KiB

Package: fixedptc-0-6.20200228hgb8acfec.fc33
Summary: Fixed point math header only library for C
RPMs:fixedptc-devel
Size:12.93 KiB

Package: mkdocs-1.1-4.fc33
Summary: Python tool to create HTML documentation from markdown sources
RPMs:mkdocs mkdocs-docs
Size:4.55 MiB

Package: python-ailment-8.20.1.7-1.fc33
Summary: The angr intermediate language
RPMs:python3-ailment
Size:37.27 KiB

Package: python-aiorestapi-0.1.1-1.fc33
Summary: Rapid rest resources for aiohttp
RPMs:python3-aiorestapi
Size:15.14 KiB

Package: python-pytest-ordering-0.6-2.fc33
Summary: Plugin to run your pytest tests in a specific order
RPMs:python-pytest-ordering-doc python3-pytest-ordering
Size:153.22 KiB

Package: python-pytest-subtests-0.3.0-1.fc33
Summary: Support for unittest subTest() and subtests fixture
RPMs:python3-pytest-subtests
Size:16.51 KiB

Package: python-restfly-1.1.1-1.fc33
Summary: A library to make API wrappers creation easier
RPMs:python3-restfly
Size:31.69 KiB

Package: python-sphobjinv-2.0.1-1.fc33
Summary: Sphinx objects.inv inspection/manipulation tool
RPMs:python3-sphobjinv
Size:50.24 KiB

Package: python-stdio-mgr-1.0.1-1.fc33
Summary: Context manager for mocking/wrapping stdin/stdout/stderr
RPMs:python3-stdio-mgr
Size:16.39 KiB

Package: restview-2.9.2-1.fc33
Summary: ReStructuredText viewer
RPMs:python3-restview restview
Size:66.37 KiB

Package: rtl-wmbus-0-4.20191213git6a04c45.fc33
Summary: Software defined receiver for wireless M-Bus with RTL-SDR
RPMs:rtl-wmbus
Size:102.60 KiB

Package: rust-xkbcommon-0.4.0-2.fc33
Summary: Rust bindings and wrappers for libxkbcommon
RPMs:rust-xkbcommon+default-devel rust-xkbcommon+memmap-devel 
rust-xkbcommon+wayland-devel rust-xkbcommon+x11-devel rust-xkbcommon+xcb-devel 
rust-xkbcommon-devel
Size:91.18 KiB

Package: wmbusmeters-0.9.28-1.fc33
Summary: Read the wireless mbus protocol to acquire utility meter readings
RPMs:wmbusmeters
Size:1.57 MiB


= DROPPED PACKAGES =
Package: alltray-0.71b-18.fc31
Summary: Dock any application in the tray
RPMs:alltray
Size:439.92 KiB

Package: perl-CPAN-Reporter-1.2018-11.fc32
Summary: Adds CPAN Testers reporting to CPAN.pm
RPMs:perl-CPAN-Reporter
Size:83.04 KiB

Package: perl-Compress-LZ4-0.25-11.fc32
Summary: Perl interface to the LZ4 compression library
RPMs:perl-Compress-LZ4
Size:109.23 KiB

Package: perl-Compress-Snappy-0.24-15.fc32
Summary: Perl interface to Google's Snappy (de)compressor
RPMs:perl-Compress-Snappy
Size:104.44 KiB

Package: perl-Crypt-ECB-2.21-11.fc32
Summary: Encrypt Data using ECB Mode
RPMs:perl-Crypt-ECB
Size:29.82 KiB

Package: perl-Crypt-PBKDF2-0.161520-11.fc32
Summary: PBKDF2 password hashing algorithm
RPMs:perl-Crypt-PBKDF2
Size:36.26 KiB

Package: perl-Crypt-PWSafe3-1.22-11.fc32
Summary: Read and write Passwordsafe v3 files
RPMs:perl-Crypt-PWSafe3
Size:53.48 KiB

Package: perl-Crypt-Random-Seed-0.03-15.fc32
Summary: Simple method to get strong randomness
RPMs:perl-Crypt-Random-Seed
Size:34.37 KiB

Package: perl-Crypt-Random-TESHA2-0.01-15.fc32
Summary: Random numbers using timer/schedule entropy
RPMs:perl-Crypt-Random-TESHA2
Size:31.95 KiB

Package: perl-Crypt-SaltedHash-0.09-17.fc32
Summary: Perl interface to functions that assist in working with salted hashes
RPMs:perl-Crypt-SaltedHash
Size:25.56 KiB

Package: perl-Date-Easter-1.22-15.fc32
Summary: Calculates Easter for any given year
RPMs:perl-Date-Easter
Size:16.95 KiB

Package: perl-Digest-Bcrypt-1.209-10.fc32
Summary: Perl interface to the bcrypt digest algorithm
RPMs:perl-Digest-Bcrypt
Size:25.41 KiB

Package: perl-Digest-PBKDF2-0.013-8.fc32
Summary: Digest module using the PBKDF2 algorithm
RPMs:perl-Digest-PBKDF2
Size:18.63 KiB

Package: perl-Image-SubImageFind-0.03-22.fc32
Summary: Perl extension for locating a sub-image within an image
RPMs:perl-Image-SubImageFind
Size:174.55 KiB

Package: perl-Module-Data-0.013-10.fc32
Summary: Introspect context information about modules

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


Dne 25. 03. 20 v 11:23 Miro Hrončok napsal(a):
> On 25. 03. 20 10:26, Vít Ondruch wrote:
>> I think that the level of involvement of the other maintainers is the
>> same as what we always did for RHEL. Did RHEL maintainers bothered some
>> Fedora maintainers with some conditionals and what not? Probably. I
>> don't see that should be different. The only difference probably is that
>> that won't be one time effort once in every 3 years, but the flow of
>> requests will be continuous, but hopefully smaller.
>
> Well, not exactly. The RHEL maintainer can try to "bother" the Fedora
> maintainer with rhel conditionals and when that Fedora maintainer says
> no, the RHEL maintainer adjust the spec in RHEL only. In many cases
> that can even be the same person. Assume I want to do something
> differently in RHEL and Fedora -- I just push the change in RHEL.
>
> While there is no way to adjust a spec in ELN only (if I understand
> the plan correctly). Assume I want to do something differently in ELN
> and Fedora -- I need to use the conditionals.
>
>> Actually, this brings interesting question. It seems to me, that it
>> would be helpful if RHEL maintainers had blank approval to access the
>> ELN packages.
>
> What are ELN packages? From the proposal, it seems it is all Fedora
> packages. Or did I get that wrong? Do you propose that RHEL
> maintainers are automatically provenpackagers (I don't think you do,
> but I am not sure)?


I assume that there will be "ELN" branch, the same way we have fxx or
epel branches. Is my assumption wrong? Dunno.


>
>
> In the ideal world, the RHEL maintainer of "foo" should be at least a
> comaintainer of "foo" in Fedora, not somebody with "blank approval to
> access". It is sad that in some cases, the RHEL maintainers are not
> involved in the corresponding Fedora packages until RHEL N+1 is in
> progress where they'd just like to dump changes and leave for another
> few years.
>
> But even if the RHEL maintainer is an active and/or primary maintainer
> of the Fedora package, they don't necessarily want to push %if
> 0%{?rhel} conditionals to rawhide just to support ELN. What shall they
> do?
>

Yes, right, I am in that boat as I sad on different place :) and again,
since this is not explicitly mentioned in the proposal, I assume that is
is something to consider.


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1817061] perl-Gnome2-Vte is missing in Fedora V32?

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

Petr Pisar  changed:

   What|Removed |Added

 Status|CLOSED  |ASSIGNED
 Resolution|NOTABUG |---
   Keywords||Reopened



--- Comment #2 from Petr Pisar  ---
It seems that vte package was not removed at the end. I will read
perl-Gnome2-Vte.

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

2020-03-25 Thread Dan Horák

On Wed, 25 Mar 2020 15:59:55 +0100
Miro Hrončok  wrote:

> On 25. 03. 20 15:50, Fabio Valentini wrote:
> >>> Branching means forking Fedora Rawhide into something else. Which
> >>> eventually will lead to new downstream tree which will ignore the
> >>> rest of Fedora and just use the fork instead. It can be done, but
> >>> I think it will damage Fedora as a project.
> > (snip)
> > 
> >> Not if we do automation that constantly keeps them in sync. Is
> >> that hard? Most likely. But it doesn't put additional burden to
> >> the community maintainers.
> > I don't even think this needs to be hard.
> > 
> > 1. For packages where no modifications are necessary, just merge
> > master into eln whenever master changes
> > 2. For packages where modifications are necessary, either
> >  - push changes into master, when those changes are acceptable
> > (particularly small changes), and proceed with case 1.
> >  - keep "bigger" changes unacceptable for master/rawhide in eln
> > and rebase those on rawhide whenever master changes
> > 
> > Given that the number of packages that need such "big" modifications
> > are expected to be small, this approach should scale very well.
> 
> The branch can even be optional. For packages that don't need
> modifications (or prefer %if conditionals), ELN could build directly
> from master.

and when a branch will be required, it will come with an assigned
maintainer, so the community maintainer can still focus on regular
Fedora branches only.


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

Re: Intent to retire why

On Tue, Mar 10, 2020 at 4:12 PM Jerry James  wrote:
> I announced last summer that I was going to retire the why package,
> due to its upstream abandoning it, but then was able to keep it
> working, so kept it for Fedora 31.  I am just a handful of package
> reviews away from updating coq and frama-c to their latest upstream
> versions.  With these updates, the why package is broken again.
> Rather than spend more time trying to keep abandonware working in
> Fedora, I intend to retire the why package in both Rawhide and F32.
> If somebody wants to try to keep it working, let me know in the next
> week.

Two weeks later... This is going to happen today.  I have also
discovered that the gappalib-coq package, which is a dependency of
why, is not needed by the latest version of anything in the coq stack,
and indeed FTBFS with the latest version of coq.  Furthermore, the
gappa package is only needed to support gappalib-coq.  Therefore, I
intend to retire 3 packages later today:

gappa
gappalib-coq
why

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


On 25. 03. 20 15:50, Fabio Valentini wrote:

Branching means forking Fedora Rawhide into something else. Which
eventually will lead to new downstream tree which will ignore the rest
of Fedora and just use the fork instead. It can be done, but I think
it will damage Fedora as a project.

(snip)


Not if we do automation that constantly keeps them in sync. Is that hard? Most
likely. But it doesn't put additional burden to the community maintainers.

I don't even think this needs to be hard.

1. For packages where no modifications are necessary, just merge
master into eln whenever master changes
2. For packages where modifications are necessary, either
 - push changes into master, when those changes are acceptable
(particularly small changes), and proceed with case 1.
 - keep "bigger" changes unacceptable for master/rawhide in eln and
rebase those on rawhide whenever master changes

Given that the number of packages that need such "big" modifications
are expected to be small, this approach should scale very well.


The branch can even be optional. For packages that don't need modifications (or 
prefer %if conditionals), ELN could build directly from master.


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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

2020-03-25 Thread Fabio Valentini

On Wed, Mar 25, 2020 at 3:23 PM Miro Hrončok  wrote:
>
> On 25. 03. 20 14:06, Aleksandra Fedorova wrote:
> >>> By contributing to Fedora Rawhide sources and consuming them as ELN
> >>> repositories for testing purposes.
> >>
> >> The change proposal literally says "There is no user-facing part in this 
> >> change.
> >> No ELN artifacts are going to be shipped to the end-user."
> >>
> >> As a contributor, how do I consume the content if I cannot consume the 
> >> content?
> >> As I understand it, the "end-user" and "user-facing" terms must have 
> >> different
> >> meanings in this context, right? What is this meaning?
> >
> > Looks like terminology issue. For me user is a person who uses
> > released Fedora, like Fedora 31 Workstation, on their laptop, or
> > Fedora 32 IoT edition on their Raspberry Pi, or a minimalistic Fedora
> > for Fedora server.
> > Basically anyone who needs Fedora to solve their own problems, which
> > are not related to development of the distribution.
> >
> > Fedora Rawhide is not a user-facing branch in Fedora, because it's
> > purpose is to develop Fedora, not something else.
> > Same with ELN. It is not a Fedora Server edition, there is no reason
> > to ever use it on a server. It is a rebuild of Fedora Rawhide, and
> > it's purpose is the development of Fedora, and help others to
> > contribute to that development.
> >
> > So it is facing contributors, not users.
> >
> > Different types of contributors though.
>
> I consider rawhide users our users and I assume many other do consider them 
> our
> users as well. I consider upstream projects who run their CI on Fedora our
> users. You are not incorrect that this is a terminology issue, however I think
> this is a different mindset issue. Please do consider rawhide users and 
> upstream
> projects our users when designing things.
>
> For example, there is a point to run an ELN on a server - e.g. to run a 
> buildbot
> worker on it for some CI tests.
>
>
>
> >> I'd rather discuss this here and only come to FPC for approval of new 
> >> guidelines
> >> when ready. The FPC members who are likely to discuss this are already
> >> discussing this here. Why spitting the discussion into two places?
> >
> > Sorry, my understanding of why we need RelEng and FPC tickets was
> > completely the opposite. Mailing list discussion about the Change is
> > generic, and gets side-tracked to one side or the other and digging
> > through it to get the pieces which are relevant to FPC topic is
> > harder. While ticket has a fixed topic, discussion associated to it
> > and the outcome of that discussion. I don't see how you can prevent
> > people from discussing the topic in the ticket and move it to the
> > mailing list.
> >
> > If you see FPC ticket as a "request to vote" only, why do we need it
> > then? Can't we just invite FPC representative to vote on a FESCo
> > ticket?
>
> We could, but there are existing workflows based on the committees using their
> own ticketing tracker to do the voting.
>
>
>
> >> This is all nice only as long as you prefer conditionals over branching. 
> >> For a
> >> Fedora maintainer who doesn't, this is just "unnecessary cruft" in the 
> >> spec file.
> >
> > It is not really about personal preferences. These are two different
> > approaches with different purposes, different results and different
> > requirements.
> > There are consequences on choosing one other the other.
>
> Yes. That's what I've been saying since the beginning. Choosing %ifs over
> branches has consequences. Choosing branches over %ifs has consequences. Not
> being able to choose has consequences.
>
> > Branching means forking Fedora Rawhide into something else. Which
> > eventually will lead to new downstream tree which will ignore the rest
> > of Fedora and just use the fork instead. It can be done, but I think
> > it will damage Fedora as a project.

(snip)

> Not if we do automation that constantly keeps them in sync. Is that hard? Most
> likely. But it doesn't put additional burden to the community maintainers.

I don't even think this needs to be hard.

1. For packages where no modifications are necessary, just merge
master into eln whenever master changes
2. For packages where modifications are necessary, either
- push changes into master, when those changes are acceptable
(particularly small changes), and proceed with case 1.
- keep "bigger" changes unacceptable for master/rawhide in eln and
rebase those on rawhide whenever master changes

Given that the number of packages that need such "big" modifications
are expected to be small, this approach should scale very well.

> >>> Yes, there is a risk that it won't work. And we have a very clean
> >>> contingency plan for it: we shutdown the whole thing.
> >>> It will be unfortunate, but it is an option.
> >>
> >> What is to stop us saying "stop acting like we can stop doing this now and 
> >> start
> >> over at this point" when we realize this is hurting the Fedora community, 
> >>

[Bug 1817061] perl-Gnome2-Vte is missing in Fedora V32?

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |NOTABUG
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-03-25 14:48:46



--- Comment #1 from Petr Pisar  ---
perl-Gnome2-Vte is a wrapper for a Gtk2 vte library. That library in 2.91
version switched from Gtk2 to Gtk3 and vte package was scheduled for removal
from Fedora
.
Therefore I also removed perl-Gnome2-Vte was removed from the distribution.

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


On 25. 03. 20 15:10, Miro Hrončok wrote:

== User Experience ==

There is no user-facing part in this change. No ELN artifacts are
going to be shipped to the end-user.


As a packager debugging a problem in ELN, how do I consume it?


It is described in "How to Test" section.


Those sections contradict each other in that case.


As I explained before users and contributors are different. ELN
packages are not to be used at home. These are developer tools.


I use developer tools at home. Plenty of Fedora users are developers. Plenty of 
Fedora developers are Fedora users. I don't understand your terminology at all. 
Saying "we are not going to ship this to users" sounds alienating


I seem to have lost the rest of the paragraph. Sorry about that.

Saying "we are not going to ship this to users" sounds alienating even if our 
intentions are not even close to that. Can we maybe not say that this way? Can 
we instead describe how to consume ELN in the user experience section?


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

[rpms/perl] PR #2: Set macros subpackage noarch

2020-03-25 Thread Petr Pisar


ppisar commented on the pull-request: `Set macros subpackage noarch` that you 
are following:
``
Thank you for the patch. I will apply it when doing the next perl build.
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl/pull-request/2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1816754] perl-Config-IniFiles-3.000003 is available

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

Tom "spot" Callaway  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-03-25 14:34:24



--- Comment #3 from Tom "spot" Callaway  ---
In rawhide.

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

2020-03-25 Thread Troy Dawson

On Wed, Mar 25, 2020 at 6:15 AM Nicolas Mailhot via devel
 wrote:
>
> Le mercredi 25 mars 2020 à 13:09 +0100, Aleksandra Fedorova a écrit :
> > On Wed, Mar 25, 2020 at 12:48 PM Miro Hrončok 
> > wrote:
> > As I mentioned in the previous mail, branching goes against the
> > purpose of the effort.
> >
> > What we like to achieve is to create a continuous flow from Fedora
> > Rawhide through branched Fedora all the way to downstream, which is
> > sometimes CentOS and sometimes EPEL.
>
> Then please work with @rh engineering to get an up-to-date packaging
> stack in EL (that means, latest stable Fedora rpm and latest stable
> Fedora packaging macros, and all the other things that make packager
> work less a shore).
>
> A huge amount of EL ifdefs is directly caused by the staleness of the
> packaging stack in EL. That’s why so much Fedora stuff never makes it
> in EPEL. Most people Fedora side do not want to deal with the utter
> clustefuck of trying to push complex up to date software to EL using
> inadequate obsolete tooling.
>
> No amount of clever ifdefing is going to mitigate this tooling
> staleness. No amount of poking is going to convince people that *do*
> *not* *want* *to* *deal* *with* *el* *braindamage* to accept
> braindamage side-effects in their own Fedora specs. That’s trying to
> put lipstick on a pig.
>
> We’ve been saying that to @rh representatives for years now. rpm and
> its ajuncts is the heart of community packaging. Packaging is done by
> packagers. Packaging is not done by people that loath packaging (and
> are continuously surprised their own packaging tools for people not
> interested in packaging do not see mass packager adoption).
>
> rpm state in EL prevents most downstreaming. Please focus efforts
> there.
>
> I don’t see how you will get any community adhesion in fixing
> downstream problems, if all your solutions are downstream focused,
> without caring about the people you want to enroll.
>

RHELN (currently RHEL9) is supposed to look like rawhide up to
whatever the cutover point is. So, up until that point, you shouldn't
be putting RHEL conditionals in, unless you do so for EPEL packages.

There are exceptions to this, such as the kernel, glibc, firefox, and
a handful of others. But those are the exceptions.

After the cutover date, then again, RHELN (in the next case it will be
RHEL10) should be looking like whatever is in rawhide, so you still
shouldn't need RHEL conditionals in, unless you do so for EPEL package
builds.

This ELN proposal has nothing to do with older RHEL releases or EPEL.

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

Re: GSoC 2020 | Improving Network Linux System Role

2020-03-25 Thread Till Maas

Hi Naman,

Thank you for your interest. Please take a look at:
https://github.com/linux-system-roles/network/wiki

Thank you
Till

Am Mi., 25. März 2020 um 04:36 Uhr schrieb Naman Dhingra
:
>
> Hello there,
> Hope this email finds you well!
>
> This is in with reference to the project idea of improving the N/W Linux 
> System Role shared on GSoC 2020.
> I would like to tell you that I really liked this idea of how we're trying to 
> uniformly handle the configurations for Network-Scripts and NetworkManager. 
> Moreover the thought to automate it via Ansible is a very good fit on a whole.
>
> Telling a bit about me, I'm a final year B.Tech CSE student, being Red Hat 
> Certified Specialist in Ansible Automation and some other tools, so I do have 
> the knowledge about the power of Ansible tool and how everything in it goes 
> on.
>
> I would really appreciate if you can share some more info. about this so that 
> I can prepare a proposal for it and submit.
>
> Looking forward to hearing from you.
>
> Thanks and regards,
> Naman
> ___
> Fedora Summer Coding community mailing list -- 
> summer-cod...@lists.fedoraproject.org
> To unsubscribe send an email to summer-coding-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/summer-cod...@lists.fedoraproject.org



-- 
Till Maas
He/His/Him
Associate Manager, Software Engineering
NetworkManager, Nmstate, Ansible RHEL Networking System Role

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill,
Thomas Savage
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


On 25. 03. 20 14:06, Aleksandra Fedorova wrote:

By contributing to Fedora Rawhide sources and consuming them as ELN
repositories for testing purposes.


The change proposal literally says "There is no user-facing part in this change.
No ELN artifacts are going to be shipped to the end-user."

As a contributor, how do I consume the content if I cannot consume the content?
As I understand it, the "end-user" and "user-facing" terms must have different
meanings in this context, right? What is this meaning?


Looks like terminology issue. For me user is a person who uses
released Fedora, like Fedora 31 Workstation, on their laptop, or
Fedora 32 IoT edition on their Raspberry Pi, or a minimalistic Fedora
for Fedora server.
Basically anyone who needs Fedora to solve their own problems, which
are not related to development of the distribution.

Fedora Rawhide is not a user-facing branch in Fedora, because it's
purpose is to develop Fedora, not something else.
Same with ELN. It is not a Fedora Server edition, there is no reason
to ever use it on a server. It is a rebuild of Fedora Rawhide, and
it's purpose is the development of Fedora, and help others to
contribute to that development.

So it is facing contributors, not users.

Different types of contributors though.


I consider rawhide users our users and I assume many other do consider them our 
users as well. I consider upstream projects who run their CI on Fedora our 
users. You are not incorrect that this is a terminology issue, however I think 
this is a different mindset issue. Please do consider rawhide users and upstream 
projects our users when designing things.


For example, there is a point to run an ELN on a server - e.g. to run a buildbot 
worker on it for some CI tests.





I'd rather discuss this here and only come to FPC for approval of new guidelines
when ready. The FPC members who are likely to discuss this are already
discussing this here. Why spitting the discussion into two places?


Sorry, my understanding of why we need RelEng and FPC tickets was
completely the opposite. Mailing list discussion about the Change is
generic, and gets side-tracked to one side or the other and digging
through it to get the pieces which are relevant to FPC topic is
harder. While ticket has a fixed topic, discussion associated to it
and the outcome of that discussion. I don't see how you can prevent
people from discussing the topic in the ticket and move it to the
mailing list.

If you see FPC ticket as a "request to vote" only, why do we need it
then? Can't we just invite FPC representative to vote on a FESCo
ticket?


We could, but there are existing workflows based on the committees using their 
own ticketing tracker to do the voting.





This is all nice only as long as you prefer conditionals over branching. For a
Fedora maintainer who doesn't, this is just "unnecessary cruft" in the spec 
file.


It is not really about personal preferences. These are two different
approaches with different purposes, different results and different
requirements.
There are consequences on choosing one other the other.


Yes. That's what I've been saying since the beginning. Choosing %ifs over 
branches has consequences. Choosing branches over %ifs has consequences. Not 
being able to choose has consequences.



Branching means forking Fedora Rawhide into something else. Which
eventually will lead to new downstream tree which will ignore the rest
of Fedora and just use the fork instead. It can be done, but I think
it will damage Fedora as a project.


Not if we do automation that constantly keeps them in sync. Is that hard? Most 
likely. But it doesn't put additional burden to the community maintainers.





Yes, there is a risk that it won't work. And we have a very clean
contingency plan for it: we shutdown the whole thing.
It will be unfortunate, but it is an option.


What is to stop us saying "stop acting like we can stop doing this now and start
over at this point" when we realize this is hurting the Fedora community, but we
need to ship next RHEL? (Sspeaking from experience. Things like this were said.)


I don't understand your question. Nothing ever stops anyone from
saying anything. But it is FESCo and Fedora Council who have the
decision power.


Correct. I just want to avoid us repeating the same mistakes over and over 
again. I am afraid this change has a potential to alienate community 
contributors and I would like us to consider the problem before we start doing 
it and before RHEL is depending on it and before everybody will just repeat "we 
cannot change this, because we have this in RHEL already".


So can we please not rush this and try to figure things ad hoc, but dedicate 
some more time to planning things? Especially I'd appreciate if the "how do we 
make this work without %if spaghetti everywhere" aspect is considered.



But if you look at the change you'll see that it has no blocking
features whatsoever. We are not changing how Fedora is built

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

On Wed, Mar 25, 2020 at 02:06:59PM +0100, Aleksandra Fedorova wrote:
> Hi, Miro,
> 
> On Wed, Mar 25, 2020 at 1:28 PM Miro Hrončok  wrote:
> >
> > On 25. 03. 20 12:49, Aleksandra Fedorova wrote:
> > > Going back to the questions. See comments inline.
> >
> > Thanks.
> >
> > >>> The goal of the ELN project is to continuously build Fedora Rawhide
> > >>> packages and composes in the way which resembles the CentOS and RHEL
> > >>> build process and to provide a feedback loop for Fedora maintainers on
> > >>> the status of those builds.
> > >>
> > >> Form a Fedora POV, this doesn't state what's being "changed" at all.
> > >> I would appreciate if it actually said something about the ELN Buildroot 
> > >> and
> > >> Compose.
> > >
> > > It says that we are going to continuously build el-like compose. We
> > > are adding new pieces of infrastructure to make that happen.
> > > This is an infrastructure change, which doesn't change Fedora content.
> >
> > It will eventually change Fedora sources. But even with "this doesn't change
> > anything" argument, I find the current summary confusing a bit without 
> > reading
> > the rest of the proposal. Can a second sentence like "A new buildroot will 
> > be
> > added Koji that will automatically build packages from master but it have a
> > different set of macros and config." be added?
> >
> > >>> ELN is an evolution of the request for an alternate buildroot for
> > >>> newer x86_64 processors. The reasoning behind that new buildroot was
> > >>> that we expected that the next major release of RHEL would likely drop
> > >>> support for older hardware and therefore could take advantage of
> > >>> enhancements and processor extensions available for newer hardware. As
> > >>> plans for this proceeded, they expanded into a desire to do more than
> > >>> just test out the processor architecture. Instead, we want to have a
> > >>> complete alternative compose of Fedora Rawhide that resembles the way
> > >>> that Red Hat and CentOS builds their packages. The idea being that
> > >>> Fedora developers and third-party vendors who rely on Red Hat
> > >>> Enterprise Linux have a place where they can directly contribute to
> > >>> what will eventually become the next RHEL.
> > >>
> > >> I don't understand from the rest of the change how do they contribute to 
> > >> ELN.
> > >
> > > By contributing to Fedora Rawhide sources and consuming them as ELN
> > > repositories for testing purposes.
> >
> > The change proposal literally says "There is no user-facing part in this 
> > change.
> > No ELN artifacts are going to be shipped to the end-user."
> >
> > As a contributor, how do I consume the content if I cannot consume the 
> > content?
> > As I understand it, the "end-user" and "user-facing" terms must have 
> > different
> > meanings in this context, right? What is this meaning?
> 
> Looks like terminology issue. For me user is a person who uses
> released Fedora, like Fedora 31 Workstation, on their laptop, or
> Fedora 32 IoT edition on their Raspberry Pi, or a minimalistic Fedora
> for Fedora server.
> Basically anyone who needs Fedora to solve their own problems, which
> are not related to development of the distribution.
> 
> Fedora Rawhide is not a user-facing branch in Fedora, because it's
> purpose is to develop Fedora, not something else.
> Same with ELN. It is not a Fedora Server edition, there is no reason
> to ever use it on a server. It is a rebuild of Fedora Rawhide, and
> it's purpose is the development of Fedora, and help others to
> contribute to that development.
> 
> So it is facing contributors, not users.
> 
> Different types of contributors though.

OK, we should be on the same page wrt. to the meaning of "end-user".

But what about developers: if one wanted to use eln for the purposes
for which they currently use rawhide, how would they go about it?
(In particular: running rawhide on their personal computer to find
bugs early, compiling upstream projects on rawhide for compatibility
testing, using rawhide when doing new packages, running rawhide just
to have everything newest).

> > >>> ELN (Enterprise Linux Next) is going to be that place. What we want to
> > >>> do is establish a set of RPM conditionals that can be used for the set
> > >>> of packages that may need to be built differently for a RHEL-like
> > >>> target as compared to a Fedora one. (For example, we may want to skip
> > >>> regenerating documentation during package-build and instead use
> > >>> pre-built docs from the tarball or SRPM.)
> > >>
> > >> What set of RPM conditionals? This is more clear from the FPC ticket:
> > >>
> > >> https://pagure.io/packaging-committee/issue/955
> > >>
> > >> But even there, it seem that any new conditionals will be discouraged, 
> > >> so what
> > >> are the new conditionals this change is talking about?
> > >
> > > As a nitpick, it doesn't say _new_ conditionals there. As we don't
> > > want to branch Fedora Rawhide we need a possibility for certain
> > >

[Bug 1817061] New: perl-Gnome2-Vte is missing in Fedora V32?

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

Bug ID: 1817061
   Summary: perl-Gnome2-Vte is missing in Fedora V32?
   Product: Fedora
   Version: 32
Status: NEW
 Component: perl-Gnome2-Vte
  Assignee: ppi...@redhat.com
  Reporter: r...@idp.it
QA Contact: extras...@fedoraproject.org
CC: berra...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



perl-Gnome2-Vte is missing in Fedora V32?

nothing provides perl-Gnome2-Vte needed by pacmanager-4.5.5.7-15.fc32.noarch

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

Fedora-IoT-33-20200325.0 compose check report

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

Passed openQA tests: 8/8 (x86_64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
Mount /run contents changed to 147.1454880% of previous size
Used mem changed from 167 MiB to 145 MiB
Peak task count changed from 115 to 102
Previous test data: https://openqa.fedoraproject.org/tests/554445#downloads
Current test data: https://openqa.fedoraproject.org/tests/556107#downloads

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
Used mem changed from 167 MiB to 145 MiB
Peak task count changed from 115 to 102
Previous test data: https://openqa.fedoraproject.org/tests/554446#downloads
Current test data: https://openqa.fedoraproject.org/tests/556108#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

No missing expected images.

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 9/171 (x86_64), 1/2 (arm)

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

ID: 556027  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/556027
ID: 556037  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/556037
ID: 556073  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/556073
ID: 556079  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/556079
ID: 556105  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/556105

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

ID: 555964  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/555964
ID: 556000  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/556000
ID: 556013  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/556013
ID: 556024  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/556024
ID: 556084  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/556084

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

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

ID: 556067  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/556067
ID: 556104  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/556104

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

ID: 555934  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/555934
ID: 555935  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/555935
ID: 555939  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/555939
ID: 555943  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/555943
ID: 555946  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/555946
ID: 555947  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/555947
ID: 555969  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/555969
ID: 555992  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/555992
ID: 555994  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/555994
ID: 556026  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/556026
ID: 556048  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/556048
ID: 556058  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/556058
ID: 556076  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/556076
ID: 556092  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/556092
ID: 556100  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/556100
ID: 556101  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/556101
ID: 556106  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/556106

Passed openQA tests: 143/171 (x86_64)

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

ID: 556010  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/556010
ID: 556012  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/556012
ID: 556096  Test: x86_64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/556096

Skipped non-gating openQA tests: 1 of 173

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
Used mem changed from 219 MiB to 191 MiB
1 packages(s) added since previous compose: alsa-sof-firmware
Peak task count changed from 162 to 133
Previous test data: https://openqa.fedoraproject.org/tests/554995#downloads
Current test data: https://openqa.fedoraproject.org/tests/555934#downloads

Installed system changes in test x86_64 Server-boot-iso install_default: 
Used mem changed from 216 MiB to 190 MiB
1 packages(s) added since previous compose: alsa-sof-firmware
Peak task count changed

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote:
> This includes:
> 
> * buildroot configuration, rpm macro and compile flags,
> * comps files and the compose content,
> * compose itself and the pipeline which builds it.
[...]

The discussion so far was mostly about *mechanisms*, i.e. how
inheritance will be set up, if there will be macros, etc.

In the discussion of conditionals vs. branches and how many changes
will be necessary and how likely packagers are to accept the patches,
it was hard to reach a conclusion because we don't know what type
of changes will be introduced, i.e. what *policy* will be implemented
using those newly available mechanisms.

What kind of changes from Fedora are planned in eln:
- making the package look like what will be in next rhel?
- some kind of experimentation with compile settings, for example to
  change amd64 baseline requirements?
- ???

I understand that a full answer cannot be given at this time, but if
we knew the general plan, we could judge more easily the amount of
changes, the burden on packagers, and maybe even the amount of build
failures.

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

[389-devel] Reminder: please review: PR 50959 - RFE - set db home directory to /dev/shm/dirsrv by default

2020-03-25 Thread Mark Reynolds



On 3/16/20 12:48 PM, Mark Reynolds wrote:

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


--

389 Directory Server Development Team
___
389-devel mailing list -- 389-de...@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-de...@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

Le mercredi 25 mars 2020 à 13:09 +0100, Aleksandra Fedorova a écrit :
> On Wed, Mar 25, 2020 at 12:48 PM Miro Hrončok 
> wrote:
> As I mentioned in the previous mail, branching goes against the
> purpose of the effort.
> 
> What we like to achieve is to create a continuous flow from Fedora
> Rawhide through branched Fedora all the way to downstream, which is
> sometimes CentOS and sometimes EPEL.

Then please work with @rh engineering to get an up-to-date packaging
stack in EL (that means, latest stable Fedora rpm and latest stable
Fedora packaging macros, and all the other things that make packager
work less a shore).

A huge amount of EL ifdefs is directly caused by the staleness of the
packaging stack in EL. That’s why so much Fedora stuff never makes it
in EPEL. Most people Fedora side do not want to deal with the utter
clustefuck of trying to push complex up to date software to EL using
inadequate obsolete tooling.

No amount of clever ifdefing is going to mitigate this tooling
staleness. No amount of poking is going to convince people that *do*
*not* *want* *to* *deal* *with* *el* *braindamage* to accept
braindamage side-effects in their own Fedora specs. That’s trying to
put lipstick on a pig.

We’ve been saying that to @rh representatives for years now. rpm and
its ajuncts is the heart of community packaging. Packaging is done by
packagers. Packaging is not done by people that loath packaging (and
are continuously surprised their own packaging tools for people not
interested in packaging do not see mass packager adoption).

rpm state in EL prevents most downstreaming. Please focus efforts
there.

I don’t see how you will get any community adhesion in fixing
downstream problems, if all your solutions are downstream focused,
without caring about the people you want to enroll.

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

Hi, Miro,

On Wed, Mar 25, 2020 at 1:28 PM Miro Hrončok  wrote:
>
> On 25. 03. 20 12:49, Aleksandra Fedorova wrote:
> > Going back to the questions. See comments inline.
>
> Thanks.
>
> >>> The goal of the ELN project is to continuously build Fedora Rawhide
> >>> packages and composes in the way which resembles the CentOS and RHEL
> >>> build process and to provide a feedback loop for Fedora maintainers on
> >>> the status of those builds.
> >>
> >> Form a Fedora POV, this doesn't state what's being "changed" at all.
> >> I would appreciate if it actually said something about the ELN Buildroot 
> >> and
> >> Compose.
> >
> > It says that we are going to continuously build el-like compose. We
> > are adding new pieces of infrastructure to make that happen.
> > This is an infrastructure change, which doesn't change Fedora content.
>
> It will eventually change Fedora sources. But even with "this doesn't change
> anything" argument, I find the current summary confusing a bit without reading
> the rest of the proposal. Can a second sentence like "A new buildroot will be
> added Koji that will automatically build packages from master but it have a
> different set of macros and config." be added?
>
> >>> ELN is an evolution of the request for an alternate buildroot for
> >>> newer x86_64 processors. The reasoning behind that new buildroot was
> >>> that we expected that the next major release of RHEL would likely drop
> >>> support for older hardware and therefore could take advantage of
> >>> enhancements and processor extensions available for newer hardware. As
> >>> plans for this proceeded, they expanded into a desire to do more than
> >>> just test out the processor architecture. Instead, we want to have a
> >>> complete alternative compose of Fedora Rawhide that resembles the way
> >>> that Red Hat and CentOS builds their packages. The idea being that
> >>> Fedora developers and third-party vendors who rely on Red Hat
> >>> Enterprise Linux have a place where they can directly contribute to
> >>> what will eventually become the next RHEL.
> >>
> >> I don't understand from the rest of the change how do they contribute to 
> >> ELN.
> >
> > By contributing to Fedora Rawhide sources and consuming them as ELN
> > repositories for testing purposes.
>
> The change proposal literally says "There is no user-facing part in this 
> change.
> No ELN artifacts are going to be shipped to the end-user."
>
> As a contributor, how do I consume the content if I cannot consume the 
> content?
> As I understand it, the "end-user" and "user-facing" terms must have different
> meanings in this context, right? What is this meaning?

Looks like terminology issue. For me user is a person who uses
released Fedora, like Fedora 31 Workstation, on their laptop, or
Fedora 32 IoT edition on their Raspberry Pi, or a minimalistic Fedora
for Fedora server.
Basically anyone who needs Fedora to solve their own problems, which
are not related to development of the distribution.

Fedora Rawhide is not a user-facing branch in Fedora, because it's
purpose is to develop Fedora, not something else.
Same with ELN. It is not a Fedora Server edition, there is no reason
to ever use it on a server. It is a rebuild of Fedora Rawhide, and
it's purpose is the development of Fedora, and help others to
contribute to that development.

So it is facing contributors, not users.

Different types of contributors though.

> >>> ELN (Enterprise Linux Next) is going to be that place. What we want to
> >>> do is establish a set of RPM conditionals that can be used for the set
> >>> of packages that may need to be built differently for a RHEL-like
> >>> target as compared to a Fedora one. (For example, we may want to skip
> >>> regenerating documentation during package-build and instead use
> >>> pre-built docs from the tarball or SRPM.)
> >>
> >> What set of RPM conditionals? This is more clear from the FPC ticket:
> >>
> >> https://pagure.io/packaging-committee/issue/955
> >>
> >> But even there, it seem that any new conditionals will be discouraged, so 
> >> what
> >> are the new conditionals this change is talking about?
> >
> > As a nitpick, it doesn't say _new_ conditionals there. As we don't
> > want to branch Fedora Rawhide we need a possibility for certain
> > package to be built differently in the ELN environment.
>
> The ticket says the "new" conditionals (with %{eln}) will be discouraged.
> Hence the means to achieve the goal will be the "old" conditionals (with
> %{rhel}/%{fedora}). Correct?
>
> > For that we need rpm conditionals based on disttag.
>
> This might be a terminology dispute and bike shedding, but I still don't
> understand what does "conditionals based on disttag" means. I've asked for an
> example in the FPC ticket and apparently the conditionals are not to be based 
> on
> disttag. I think a very thorough decision should be maade regarding the
> conditionals and dist tag:
>
>   - should %{fedora} be defined at all?
>   - should %{eln}

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

On Wed, Mar 25, 2020 at 8:29 AM Miro Hrončok  wrote:
> >> Will there be a way to opt-out packages (or stacks of them) from ELN if 
> >> they are
> >> not interesting for RHEL?
> >
> > We want to start with a subset of packages at the beginning (basic
> > buildroot packages, system-level packages and so on) and see if it can
> > grow beyond EL-subset later.
> > I think we should cover EPEL packages too, so it already goes further
> > than just RHEL.
>
> So this is already the plan (only have some packages)? I have not understood
> that from the proposal at all.

This was left out of the proposal because we hadn't come to a firm
decision on it yet (it's still somewhat fluid). ELN SIG members are
agreed that this will *not* be "every package in Fedora", but there's
still some disagreement about which specific subset it will be. As
Aleksandra says, it will likely be more than just RHEL BaseOS, but by
how much is an open question.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


On 25. 03. 20 12:49, Aleksandra Fedorova wrote:

Going back to the questions. See comments inline.


Thanks.


The goal of the ELN project is to continuously build Fedora Rawhide
packages and composes in the way which resembles the CentOS and RHEL
build process and to provide a feedback loop for Fedora maintainers on
the status of those builds.


Form a Fedora POV, this doesn't state what's being "changed" at all.
I would appreciate if it actually said something about the ELN Buildroot and
Compose.


It says that we are going to continuously build el-like compose. We
are adding new pieces of infrastructure to make that happen.
This is an infrastructure change, which doesn't change Fedora content.


It will eventually change Fedora sources. But even with "this doesn't change 
anything" argument, I find the current summary confusing a bit without reading 
the rest of the proposal. Can a second sentence like "A new buildroot will be 
added Koji that will automatically build packages from master but it have a 
different set of macros and config." be added?



ELN is an evolution of the request for an alternate buildroot for
newer x86_64 processors. The reasoning behind that new buildroot was
that we expected that the next major release of RHEL would likely drop
support for older hardware and therefore could take advantage of
enhancements and processor extensions available for newer hardware. As
plans for this proceeded, they expanded into a desire to do more than
just test out the processor architecture. Instead, we want to have a
complete alternative compose of Fedora Rawhide that resembles the way
that Red Hat and CentOS builds their packages. The idea being that
Fedora developers and third-party vendors who rely on Red Hat
Enterprise Linux have a place where they can directly contribute to
what will eventually become the next RHEL.


I don't understand from the rest of the change how do they contribute to ELN.


By contributing to Fedora Rawhide sources and consuming them as ELN
repositories for testing purposes.


The change proposal literally says "There is no user-facing part in this change. 
No ELN artifacts are going to be shipped to the end-user."


As a contributor, how do I consume the content if I cannot consume the content? 
As I understand it, the "end-user" and "user-facing" terms must have different 
meanings in this context, right? What is this meaning?



ELN (Enterprise Linux Next) is going to be that place. What we want to
do is establish a set of RPM conditionals that can be used for the set
of packages that may need to be built differently for a RHEL-like
target as compared to a Fedora one. (For example, we may want to skip
regenerating documentation during package-build and instead use
pre-built docs from the tarball or SRPM.)


What set of RPM conditionals? This is more clear from the FPC ticket:

https://pagure.io/packaging-committee/issue/955

But even there, it seem that any new conditionals will be discouraged, so what
are the new conditionals this change is talking about?


As a nitpick, it doesn't say _new_ conditionals there. As we don't
want to branch Fedora Rawhide we need a possibility for certain
package to be built differently in the ELN environment.


The ticket says the "new" conditionals (with %{eln}) will be discouraged.
Hence the means to achieve the goal will be the "old" conditionals (with 
%{rhel}/%{fedora}). Correct?



For that we need rpm conditionals based on disttag.


This might be a terminology dispute and bike shedding, but I still don't 
understand what does "conditionals based on disttag" means. I've asked for an 
example in the FPC ticket and apparently the conditionals are not to be based on 
disttag. I think a very thorough decision should be maade regarding the 
conditionals and dist tag:


 - should %{fedora} be defined at all?
 - should %{eln} be versioned?
 - should the dist tag be versioned? (see Neal's point with the Koji nevr check)

We can surely do it in the FPC ticket, but people are not gonna find that 
discussion there.



This is a chicken and egg problem, to be honest. To figure out the
details we need FPC and others contribution, but then to start talking
to FPC we need a Change Proposal so that you get the idea what are we
trying to achieve and why.


As a member of the FPC I don't think you need to involve FPC at all at this 
point other than getting feedback. And I don't see a chicken and egg problem in 
here - you have the proposal and we are discussing it.



... Some unknown number of packages that rely on `if !
0%{?fedora}` will require manual intervention.


And many other cases, see the FPC ticket.


Let's discuss it in the ticket then?


I'd rather discuss this here and only come to FPC for approval of new guidelines 
when ready. The FPC members who are likely to discuss this are already 
discussing this here. Why spitting the discussion into two places?


However, if you prefer to discuss this in the FPC ticket, sure. There is

[Bug 1817021] New: Upgrade perl-Type-Tiny to 1.010001

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

Bug ID: 1817021
   Summary: Upgrade perl-Type-Tiny to 1.010001
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Type-Tiny
  Assignee: rc040...@freenet.de
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 1.01 version. Upstream released 1.010001. When you
have free time, please upgrade it.

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

On Wed, Mar 25, 2020 at 12:48 PM Miro Hrončok  wrote:
>
> On 25. 03. 20 12:37, Fabio Valentini wrote:
> >> So let's assume for the sake of the argument, that Python is broken in ELN 
> >> and
> >> the Python maintainers don't want 0%{?rhel}/0%{?eln} conditionals in their 
> >> spec
> >> files. Now all 3600+ Python packages will fail to build in ELN because of 
> >> this
> >> and the feedback provided in bodhi will be moot. What will happen then?
> > What about using an additional "eln" branch in dist-git?
> >
> > - For most packages, the master branch should be able to be merged
> > into eln regularly (or even automatically, triggered by master
> > commits).
> > - For the packages that need "unacceptable in master" adjustments, an
> > automatic rebase on top of new master commits could be attempted, and
> > if that fails, human intervention is necessary anyway.
>
> Yes, that makes sense to me. Especially with automation (bacause without it, 
> the
> branch would simply get stalled, you cannot rebase all Fedora packages 
> manually
> at this scale).

As I mentioned in the previous mail, branching goes against the
purpose of the effort.

What we like to achieve is to create a continuous flow from Fedora
Rawhide through branched Fedora all the way to downstream, which is
sometimes CentOS and sometimes EPEL.

Doing this with branches is going to be much harder. When you update
package with conditionals you do need to care about the effect on
various ifs, but you do need to change the package only once at one
place. And then the tree of branches which we create from Fedora
Rawhide will get this change automatically with no effort.

Of course not ifs are equal. It may require some refactoring on the
code side to make the ifs cleaner. I know kernel people did that with
a kernel package to reorganize patches which are applied.

But this is exactly the work we are looking for: the negotiation
between downstream maintainers and Fedora maintainers to make things
work together. We already have branching, it is easier as it allow us
not to talk to each other, but it doesn't solve anything.

And yes, it means that people are going to be _bothered_, and
_pressured_ on figuring out the best way to collaborate. But isn't it
our job?

And again, if you make it easier for downstream to work with Fedora,
you give downstream the reasons to bring their resources. Things like
quality assurance and help with bug triage and bug fixes, things like
cross-project feature development. This is a two-way collaboration
effort.

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

-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1817015] New: Upgrade perl-File-Slurp to 9999.30

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

Bug ID: 1817015
   Summary: Upgrade perl-File-Slurp to .30
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-File-Slurp
  Assignee: rc040...@freenet.de
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: lxt...@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers .29 version. Upstream released .30. When you
have free time, please upgrade it.

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

Going back to the questions. See comments inline.

On Tue, Mar 24, 2020 at 3:17 PM Miro Hrončok  wrote:
>
> On 24. 03. 20 10:32, Aleksandra Fedorova wrote:
> > As Ben is on PTO, I'd like to present the System-Wide Change
> >
> > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> >
> > == Summary ==
> >
> > The goal of the ELN project is to continuously build Fedora Rawhide
> > packages and composes in the way which resembles the CentOS and RHEL
> > build process and to provide a feedback loop for Fedora maintainers on
> > the status of those builds.
>
> Form a Fedora POV, this doesn't state what's being "changed" at all.
> I would appreciate if it actually said something about the ELN Buildroot and
> Compose.

It says that we are going to continuously build el-like compose. We
are adding new pieces of infrastructure to make that happen.
This is an infrastructure change, which doesn't change Fedora content.

> > ELN is an evolution of the request for an alternate buildroot for
> > newer x86_64 processors. The reasoning behind that new buildroot was
> > that we expected that the next major release of RHEL would likely drop
> > support for older hardware and therefore could take advantage of
> > enhancements and processor extensions available for newer hardware. As
> > plans for this proceeded, they expanded into a desire to do more than
> > just test out the processor architecture. Instead, we want to have a
> > complete alternative compose of Fedora Rawhide that resembles the way
> > that Red Hat and CentOS builds their packages. The idea being that
> > Fedora developers and third-party vendors who rely on Red Hat
> > Enterprise Linux have a place where they can directly contribute to
> > what will eventually become the next RHEL.
>
> I don't understand from the rest of the change how do they contribute to ELN.

By contributing to Fedora Rawhide sources and consuming them as ELN
repositories for testing purposes. But also by contributing directly
to ELN compose configuration.

> > ELN (Enterprise Linux Next) is going to be that place. What we want to
> > do is establish a set of RPM conditionals that can be used for the set
> > of packages that may need to be built differently for a RHEL-like
> > target as compared to a Fedora one. (For example, we may want to skip
> > regenerating documentation during package-build and instead use
> > pre-built docs from the tarball or SRPM.)
>
> What set of RPM conditionals? This is more clear from the FPC ticket:
>
> https://pagure.io/packaging-committee/issue/955
>
> But even there, it seem that any new conditionals will be discouraged, so what
> are the new conditionals this change is talking about?

As a nitpick, it doesn't say _new_ conditionals there. As we don't
want to branch Fedora Rawhide we need a possibility for certain
package to be built differently in the ELN environment. For that we
need rpm conditionals based on disttag.

This is a chicken and egg problem, to be honest. To figure out the
details we need FPC and others contribution, but then to start talking
to FPC we need a Change Proposal so that you get the idea what are we
trying to achieve and why.

> > This includes:
> >
> > * buildroot configuration, rpm macro and compile flags,
> > * comps files and the compose content,
> > * compose itself and the pipeline which builds it.
>
> Where are those rpm macros and compile flags be defined if this builds from
> master? Will there be an alternative branch for (and only for)
> redhat-rpm-config, or will redhat-rpm-config be full of such new conditionals?
> Are the maintainers of redhat-rpm-config on board?
>
> > ... Some unknown number of packages that rely on `if !
> > 0%{?fedora}` will require manual intervention.
>
> And many other cases, see the FPC ticket.

Let's discuss it in the ticket then?

> > * CentOS Stream, EPEL and RHEL
> > ** We are going to build Fedora packages into a compose similar to the
> > multi-repo structure of CentOS and RHEL.
>
> This lacks any details in the description.

I am not sure what kind of details you expect.

Will it help if I add a link to CentOS compose? Like this one
http://mirror.centos.org/centos/8.1.1911/

>
> > ** The feedback pipelines built for the project will allow downstream
> > developers to open up their work and bring it closer to Fedora. In
> > particular, it will enable projects like OpenShift to do their work in
> > Fedora.
>
> I don't understand how. Do you have more details?

For third-parties who develop services and tools for CentOS and RHEL
it is important to have development environment which is close to what
they will achieve in the released version.
Fedora Rawhide is the future RHEL, but as it is packed differently it
is harder to rely on it, when you plan the future of your third-party
service.

ELN compose is a preview of what may happen if we take current Fedora
Rawhide and try to make CentOS/RHEL out of it, like right now. It is a
preview of issues we are going to have as

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


On 25. 03. 20 12:37, Fabio Valentini wrote:

So let's assume for the sake of the argument, that Python is broken in ELN and
the Python maintainers don't want 0%{?rhel}/0%{?eln} conditionals in their spec
files. Now all 3600+ Python packages will fail to build in ELN because of this
and the feedback provided in bodhi will be moot. What will happen then?

What about using an additional "eln" branch in dist-git?

- For most packages, the master branch should be able to be merged
into eln regularly (or even automatically, triggered by master
commits).
- For the packages that need "unacceptable in master" adjustments, an
automatic rebase on top of new master commits could be attempted, and
if that fails, human intervention is necessary anyway.


Yes, that makes sense to me. Especially with automation (bacause without it, the 
branch would simply get stalled, you cannot rebase all Fedora packages manually 
at this scale).


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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

2020-03-25 Thread Fabio Valentini

On Wed, Mar 25, 2020 at 11:47 AM Miro Hrončok  wrote:
>
> On 24. 03. 20 19:55, Aleksandra Fedorova wrote:
> > On Tue, Mar 24, 2020 at 6:01 PM Miro Hrončok  wrote:
> >> On 24. 03. 20 16:23, Aleksandra Fedorova wrote:
> >>> I think your approach to assessment of the Change is not fair.
> >>
> >> Ouch. It's just that reading the proposal raises all of those questions. 
> >> Sorry
> >> if that's not fair.
> >
> > Sorry if that sounded offensive. I didn't really mean it. And I am not
> > against asking questions, please do.
> >
> > I do think that not all questions need to be answered now. Not all an
> > be answered and not all should. So I was trying to propose splitting
> > it up into what needs to be decided now, and why. And what can be left
> > later.
> >
> > But going too meta probably was a wrong move by me here. So let's get
> > back to the actual questions.
>
> Thank You, Aleksandra.
>
> >> The main risk I see is that this will generate a need for mass pushing 
> >> various
> >> conditionals all over Fedora. And while some maintainers like those, some 
> >> don't.
> >> And I'm afraid this is not fair to them, if we approve this without 
> >> knowing.
> >
> > Do you have a suggestion, how to make it clear that there will be no
> > enforcement?
>
> It should describe how do the ELN/RHEL maintainers achieve changes over Fedora
> (if needed) other than %if 0%{?rhel} conditionals in case the Fedora 
> maintainers
> don't want those. If the conditionals are the only way to achieve the goal,
> there will either be "enforcement" or there will be "breakage".
>
> > We've put it in the proposal that we are going to provide feedback in
> > terms of test results visible on the bodhi page using Rawhide Gating.
> > There are no plans to make gating on that test mandatory, as we leave
> > it to package maintainers to configure gating in general.

(snip)

> So let's assume for the sake of the argument, that Python is broken in ELN and
> the Python maintainers don't want 0%{?rhel}/0%{?eln} conditionals in their 
> spec
> files. Now all 3600+ Python packages will fail to build in ELN because of this
> and the feedback provided in bodhi will be moot. What will happen then?

What about using an additional "eln" branch in dist-git?

- For most packages, the master branch should be able to be merged
into eln regularly (or even automatically, triggered by master
commits).
- For the packages that need "unacceptable in master" adjustments, an
automatic rebase on top of new master commits could be attempted, and
if that fails, human intervention is necessary anyway.

Fabio

> > We may also propose pull requests with changes to some packages when
> > we'd like to suggest a fix for the dependency or adjust compile flags.
>
> Adding the conditionals? What happens if the maintainer says "I don't like
> conditionals in my spec files, please, maintian this in ELN separately 
> please"?
> If that is not possible two things can happen: More pressure to accept the 
> Pull
> Request ("it is just a simple %if and it will fix 3600 packages..."), or even
> provenpackagers pushing changes. (The other way is to keep ELN broken, but 
> that
> defies the purpose of ELN.)
>
> Side note: I realize perfectly that package maintainer should not be absolute
> dictators and that they don't "own" their package, but that they are rather
> "stewards" (in fact, I argue we should make this more clear). However changes
> like this can create unmaintainable %if spaghetti (we've been there with the
> Python 2 -> 3 transition) and hence I think the person who primarily needs to
> maintain the package has something to say about whether they want a certain
> packaging idiom in "their" specs.
>
> >> The change should at least describe what level of involvement is required 
> >> from
> >> other contributors. It it is "no involvement needed" and "we will not 
> >> bother you
> >> with conditionals" than I see no risk for Fedora (distro) (but I see a 
> >> huge risk
> >> for the ELN project, because it will be unable to fix itself).
> >
> > The answer here is that we _may_ bother you with conditionals, but we
> > don't know yet how often it may happen.
> > Do you want us to keep track on usage of %{eln} in spec files? I think
> > this is doable.
>
> Stephen made it clear that the usage of %{?eln} will be very rare. What I 
> worry
> is added overhead with %{?rhel}/%{?fedora} conditionals. Keeping track won't
> help -- hundreds (thousands?) of packages already use those and hundreds
> (thousands?) don't. What I worry about is that this will become the only way 
> to
> achieve things.
>
> >>> 2) how it is going to work
> >>> This goes to design docs and implementation. We will definitely take
> >>> all comments from the mailing thread into account. As soon as we
> >>> figure out the place where we track the effort (most likely, Taiga) we
> >>> will transfer it all there. But we would like to postpone making
> >>> decisions on those topics. Because things may change

Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

Le mercredi 25 mars 2020 à 11:28 +0100, Iñaki Ucar a écrit :
> On Wed, 25 Mar 2020 at 01:14, Gavin Simpson
> wrote:

Hi,

> Adding de...@lists.fp.o to CC. A workaround is to avoid using PS
> fonts for symbols.

PS fonts are dead mid-term everywhere, and already forbidden in new
Fedora font packages (because we are somewhat leading edge, but not as
much as people think)
https://docs.fedoraproject.org/en-US//packaging-guidelines/FontsPolicy/#_font_file_formats

PS font users need to switch to OpenType fonts or work with their
prefered font upstream to convert in modern well supported formats
(font format wars have endend last millenium, even before the browser
wars ended, it’s long past time to deprecate the losers).

That’s normal IT format obsolescence.

That being said, that’s not what is happening here.

R brought this all on itself by hardcoding a Windows-only “Symbol” font
family name in its default conf. Linux systems are UTF-8 by default for
~20 years now, they don’t need the forcing of magic font families to
handle symbols not present in the 8-bit legacy Windows encodings.

The actual effect of this conf is not the selection of font files with
special and unusual symbols. It is to priorize fonts that match the
"Symbol" magic name. And those fonts are few and crumbling on Linux
systems, because no one has needed to bother with them since Linux
switched to UTF-8 last millenium.

Just stop using “Symbol” in R and things will work a lot better.
Alternatively, prepare to maintain the “Symbol” aliasing stack in
fontconfig (and fight with wine for it), because *no* *one* *else*
*cares* about this legacy Windows-specific stuff.

Fontconfig upstream already told this to R users in its own issue
tracker.

Regards,

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


On 24. 03. 20 19:55, Aleksandra Fedorova wrote:

On Tue, Mar 24, 2020 at 6:01 PM Miro Hrončok  wrote:

On 24. 03. 20 16:23, Aleksandra Fedorova wrote:

I think your approach to assessment of the Change is not fair.


Ouch. It's just that reading the proposal raises all of those questions. Sorry
if that's not fair.


Sorry if that sounded offensive. I didn't really mean it. And I am not
against asking questions, please do.

I do think that not all questions need to be answered now. Not all an
be answered and not all should. So I was trying to propose splitting
it up into what needs to be decided now, and why. And what can be left
later.

But going too meta probably was a wrong move by me here. So let's get
back to the actual questions.


Thank You, Aleksandra.


The main risk I see is that this will generate a need for mass pushing various
conditionals all over Fedora. And while some maintainers like those, some don't.
And I'm afraid this is not fair to them, if we approve this without knowing.


Do you have a suggestion, how to make it clear that there will be no
enforcement?


It should describe how do the ELN/RHEL maintainers achieve changes over Fedora 
(if needed) other than %if 0%{?rhel} conditionals in case the Fedora maintainers 
don't want those. If the conditionals are the only way to achieve the goal, 
there will either be "enforcement" or there will be "breakage".



We've put it in the proposal that we are going to provide feedback in
terms of test results visible on the bodhi page using Rawhide Gating.
There are no plans to make gating on that test mandatory, as we leave
it to package maintainers to configure gating in general.


So let's assume for the sake of the argument, that Python is broken in ELN and 
the Python maintainers don't want 0%{?rhel}/0%{?eln} conditionals in their spec 
files. Now all 3600+ Python packages will fail to build in ELN because of this 
and the feedback provided in bodhi will be moot. What will happen then?



We may also propose pull requests with changes to some packages when
we'd like to suggest a fix for the dependency or adjust compile flags.


Adding the conditionals? What happens if the maintainer says "I don't like 
conditionals in my spec files, please, maintian this in ELN separately please"?
If that is not possible two things can happen: More pressure to accept the Pull 
Request ("it is just a simple %if and it will fix 3600 packages..."), or even 
provenpackagers pushing changes. (The other way is to keep ELN broken, but that 
defies the purpose of ELN.)


Side note: I realize perfectly that package maintainer should not be absolute 
dictators and that they don't "own" their package, but that they are rather 
"stewards" (in fact, I argue we should make this more clear). However changes 
like this can create unmaintainable %if spaghetti (we've been there with the 
Python 2 -> 3 transition) and hence I think the person who primarily needs to 
maintain the package has something to say about whether they want a certain 
packaging idiom in "their" specs.



The change should at least describe what level of involvement is required from
other contributors. It it is "no involvement needed" and "we will not bother you
with conditionals" than I see no risk for Fedora (distro) (but I see a huge risk
for the ELN project, because it will be unable to fix itself).


The answer here is that we _may_ bother you with conditionals, but we
don't know yet how often it may happen.
Do you want us to keep track on usage of %{eln} in spec files? I think
this is doable.


Stephen made it clear that the usage of %{?eln} will be very rare. What I worry 
is added overhead with %{?rhel}/%{?fedora} conditionals. Keeping track won't 
help -- hundreds (thousands?) of packages already use those and hundreds 
(thousands?) don't. What I worry about is that this will become the only way to 
achieve things.



2) how it is going to work
This goes to design docs and implementation. We will definitely take
all comments from the mailing thread into account. As soon as we
figure out the place where we track the effort (most likely, Taiga) we
will transfer it all there. But we would like to postpone making
decisions on those topics. Because things may change while we are
working on them. And it should be ok to change them, as soon as we
keep the boundaries.


I don't see a reason to postpone this discussion. It may affect critical design
decisions. And we have seen in the past that postponing some problems for later
(e.g. upgrade path or switching streams in Modularity) can lead to a serious
design issues that are very hard to fix later.


I wasn't proposing to postpone the conversation. I suggested to split
it into two groups.


OK, sorry for misunderstanding what you say. I don't know how to classify my 
feedback to this two groups (I don't really feel the need either), but feel free 
to do that when you triage it.



And for first group to add a question on "why should we know the
answer

Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

2020-03-25 Thread Iñaki Ucar

Just for de...@lists.fp.o

The problem reported in the previous email (enclosed below) not only
happens because pango switched to HarfBuzz, but also because by
default fontconfig prefers a PS font for symbols, so I'd say this is a
system-wide problem. But not sure where's the proper place/package to
fix this. Should I CC the fonts lists?

Iñaki

On Wed, 25 Mar 2020 at 11:28, Iñaki Ucar  wrote:
>
> On Wed, 25 Mar 2020 at 01:14, Gavin Simpson  wrote:
> >
> > Dear list
> >
> > On Fedora 31 the pango library has recently updated to version >= 1.44
> > and in doing so has switched to using the HarfBuzz library (from
> > FreeType) and dropped Adobe Type 1 font support. This causes problems
> > with plotmath as all bar one of the glyphs doesn't render (see
> > attached PNG image if it makes it through the list filters - if not I
> > have shared a copy via my google drive:
> > https://drive.google.com/file/d/1llFqKHD7LFKzQbVuq6sibY1UizRn7xxS/view?usp=sharing
> > )
> >
> > I'm not the only person who has come across this, e.g.
> > https://stackoverflow.com/q/60656445/429846 and the resulting reported
> > bug on the RedHat Bugzilla:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1815128
> >
> > Beyond switching to  `type = 'Xlib'`, has anyone worked around this
> > issue on a Fedora 31 or later system?
>
> Adding de...@lists.fp.o to CC. A workaround is to avoid using PS fonts
> for symbols. If you run the following, you'll see
>
> $ fc-match Symbol
> StandardSymbolsPS.t1: "Standard Symbols PS" "Regular"
>
> So let's change this. Install a TTF symbol font, such as Symbola:
>
> $ sudo dnf install gdouros-symbola-fonts
>
> Then add the following to /etc/fonts/local.conf (system-wide) or
> ~/.fonts.conf (just for your user):
>
> 
> 
>  Symbol
>  
>Symbola
>  
> 
> 
>
> Now you should see this:
>
> $ fc-match Symbol
> Symbola.ttf: "Symbola" "Regular"
>
> and symbols should render correctly.
>
> Iñaki



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

Fedora-Cloud-31-20200325.0 compose check report

No missing expected images.

Passed openQA tests: 1/1 (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: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

2020-03-25 Thread Iñaki Ucar

On Wed, 25 Mar 2020 at 01:14, Gavin Simpson  wrote:
>
> Dear list
>
> On Fedora 31 the pango library has recently updated to version >= 1.44
> and in doing so has switched to using the HarfBuzz library (from
> FreeType) and dropped Adobe Type 1 font support. This causes problems
> with plotmath as all bar one of the glyphs doesn't render (see
> attached PNG image if it makes it through the list filters - if not I
> have shared a copy via my google drive:
> https://drive.google.com/file/d/1llFqKHD7LFKzQbVuq6sibY1UizRn7xxS/view?usp=sharing
> )
>
> I'm not the only person who has come across this, e.g.
> https://stackoverflow.com/q/60656445/429846 and the resulting reported
> bug on the RedHat Bugzilla:
> https://bugzilla.redhat.com/show_bug.cgi?id=1815128
>
> Beyond switching to  `type = 'Xlib'`, has anyone worked around this
> issue on a Fedora 31 or later system?

Adding de...@lists.fp.o to CC. A workaround is to avoid using PS fonts
for symbols. If you run the following, you'll see

$ fc-match Symbol
StandardSymbolsPS.t1: "Standard Symbols PS" "Regular"

So let's change this. Install a TTF symbol font, such as Symbola:

$ sudo dnf install gdouros-symbola-fonts

Then add the following to /etc/fonts/local.conf (system-wide) or
~/.fonts.conf (just for your user):



 Symbol
 
   Symbola
 



Now you should see this:

$ fc-match Symbol
Symbola.ttf: "Symbola" "Regular"

and symbols should render correctly.

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose

On Wed, Mar 25, 2020 at 09:06:06AM +0100, Petr Pisar wrote:
> On Tue, Mar 24, 2020 at 07:55:12PM -0700, John M. Harris Jr wrote:
> > On Tuesday, March 24, 2020 5:25:30 AM MST Petr Pisar wrote:
> > > On Tue, Mar 24, 2020 at 12:13:57PM +, Tom Hughes via devel wrote:
> > > > I thought the above was saying there were fundamental architectural
> > > > differences in the way the builds worked, rather than just that people
> > > > might choose to make different choices in the spec file.
> > > 
> > > RHEL supports building non-modular RPM packages on top of modules. While
> > > Fedora forbids it. Probably this is not a fundamental difference, but a 
> > > big
> > > one.
> > > 
> > > I believe the proposed change covers it in the pungi configuration.
> > > 
> > > -- Petr
> > 
> > In that case, it looks like this change could potentially fix RHEL if it 
> > goes 
> > through? Or are you saying it'd try to force that policy onto Fedora?
> > 
> I'm saying that the change descibes that ELN will have a separate pungi and
> tagging configurations. And because tagging default module streams into a 
> build
> root is based on them, it can allow having default streams in ELN without
> forcing that policy onto Fedora. Whether it will be so or not is up to the
> implementation the change owners will choose. So far we heard that the
> implementation is unclear.

It sounds like tagging default module streams into the build root
would be _technically_ possible. But OTOH, I understood that the
intent is to rebuild packages from rawhide on the fly, and having
module streams in the build root would cause noticeable changes in
the availability and versions of build dependencies, and would
make following rawhide with automatic rebuilds much harder.

I'm just speculating of course, a clarification from the Change
owners would be welcome.

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose


On 25. 03. 20 10:26, Vít Ondruch wrote:

I think that the level of involvement of the other maintainers is the
same as what we always did for RHEL. Did RHEL maintainers bothered some
Fedora maintainers with some conditionals and what not? Probably. I
don't see that should be different. The only difference probably is that
that won't be one time effort once in every 3 years, but the flow of
requests will be continuous, but hopefully smaller.


Well, not exactly. The RHEL maintainer can try to "bother" the Fedora maintainer 
with rhel conditionals and when that Fedora maintainer says no, the RHEL 
maintainer adjust the spec in RHEL only. In many cases that can even be the same 
person. Assume I want to do something differently in RHEL and Fedora -- I just 
push the change in RHEL.


While there is no way to adjust a spec in ELN only (if I understand the plan 
correctly). Assume I want to do something differently in ELN and Fedora -- I 
need to use the conditionals.



Actually, this brings interesting question. It seems to me, that it
would be helpful if RHEL maintainers had blank approval to access the
ELN packages.


What are ELN packages? From the proposal, it seems it is all Fedora packages. Or 
did I get that wrong? Do you propose that RHEL maintainers are automatically 
provenpackagers (I don't think you do, but I am not sure)?


In the ideal world, the RHEL maintainer of "foo" should be at least a 
comaintainer of "foo" in Fedora, not somebody with "blank approval to access". 
It is sad that in some cases, the RHEL maintainers are not involved in the 
corresponding Fedora packages until RHEL N+1 is in progress where they'd just 
like to dump changes and leave for another few years.


But even if the RHEL maintainer is an active and/or primary maintainer of the 
Fedora package, they don't necessarily want to push %if 0%{?rhel} conditionals 
to rawhide just to support ELN. What shall they do?


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

Re: Self-introduction: chrissie

On Wed, Mar 25, 2020 at 10:05:21AM +, Christine Caulfield wrote:
> Hi,
> 
> I'm Chrissie Caulfield, I've worked at Red Hat or over 15 years now,
> pretty much always in clustering. Before that I worked on VAX/VMS
> systems - more clustering, though I did have a spell in between when I
> wrote software-for-industry and was porting-supremo for Tarantella
> (back-end stuff only) for a while.
> 
> I've been writing C for 30 years or so, current upstream projects are
> corosync, kronosnet and libqb. Currently learning Rust too - for home
> project only at the moment.
> 
> I currently package libqb for RHEL and used to package cman for RHEL 5 &
> 6. I've been asked by my boss to look at taking over packaging of libqb
> when the current maintainer leaves Red Hat at the end of April.

Welcome!

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

Self-introduction: chrissie

2020-03-25 Thread Christine Caulfield

Hi,

I'm Chrissie Caulfield, I've worked at Red Hat or over 15 years now,
pretty much always in clustering. Before that I worked on VAX/VMS
systems - more clustering, though I did have a spell in between when I
wrote software-for-industry and was porting-supremo for Tarantella
(back-end stuff only) for a while.

I've been writing C for 30 years or so, current upstream projects are
corosync, kronosnet and libqb. Currently learning Rust too - for home
project only at the moment.

I currently package libqb for RHEL and used to package cman for RHEL 5 &
6. I've been asked by my boss to look at taking over packaging of libqb
when the current maintainer leaves Red Hat at the end of April.

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

Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose